Рассмотреть замену внешнего ИТ-поставщика следует в следующих случаях: когда текущий поставщик не может удовлетворить возросшие требования бизнеса (например, по пропускной способности или функциональности), при систематических нарушениях условий SLA, при отсутствии альтернативных решений в рамках текущего договора, когда рыночная ситуация изменилась и появились более выгодные или надежные поставщики, при достижении технического предела возможностей текущего поставщика (например, максимальная скорость канала уже достигнута и не может быть увеличена). Также замена может быть необходима при изменении стратегических требований к ИТ-инфраструктуре или при реорганизации бизнес-процессов, требующих новых типов ИТ-услуг.

В организациях с географическим распределением матрица функций и процессов может быть использована для эффективного управления ресурсами на разных территориях. Матрица позволяет определить, какие функции участвуют в реализации каких процессов на каждой территории, и соответственно распределять ответственность. Например, начальник определенной функции на каждой из территорий будет отвечать за предоставление ресурсов, необходимых для реализации процессов на своей территории. Его оценка будет строиться на основе процессных метрик подчиненных. В то же время начальник соответствующей функции в HQ будет оцениваться по агрегированным метрикам региональных начальников. Такой подход обеспечивает единообразие управления процессами на всех территориях, позволяет сравнивать эффективность работы по регионам и своевременно выявлять проблемы. При этом все метрики должны быть приведены к сопоставимому виду (шкала от 0 до 1), что позволяет объективно сравнивать результаты различных регионов.

Для выбора подходящего владельца критичного для бизнеса процесса необходимо сначала определить степень критичности каждой обязанности владельца, используя десятибалльную шкалу, где 10 означает, что отсутствие выполнения этой обязанности может привести к серьезным проблемам. Затем следует искать человека, обладающего достаточными полномочиями и возможностями для выполнения наиболее критичных обязанностей. Для высококритичных процессов владельец должен иметь широкий охват контроля (scope of control), охватывающий все подразделения, участвующие в процессе. Если невозможно назначить высокопоставленного руководителя, необходимо создать надежные механизмы поддержки и эскалации, чтобы владелец мог оперативно получать необходимую поддержку от руководства. Также важно учитывать, что владелец должен иметь достаточно времени для выполнения обязанностей по управлению процессом, не будучи перегруженным другими обязанностями.

При проектировании архитектуры решения для автоматизации бизнес-процессов необходимо учитывать: соответствие решения бизнес-требованиям в контексте user story, технические требования к логике и интерфейсам, возможности интеграции с внешними системами, стандарты разработки компании, требования к документированию процессов и решений, а также накопленный опыт реализации аналогичных проектов. Важно также предусмотреть механизмы поддержания актуальности решения при изменении бизнес-процессов и внешней среды.

Основное различие заключается в том, что неправильные рассуждения фокусируются только на том, что повышение приоритета одной задачи позволит быстрее ее завершить ('меняем приоритет, чтобы подвинуть наверх'). Правильные рассуждения учитывают, что при этом все остальные задачи автоматически получают более низкий приоритет, и работа над ними замедляется ('меняя приоритет, остальное двигаем вниз'). Неправильный подход игнорирует последствия для других задач и заинтересованных сторон, не учитывает цену частой переброски ресурсов и приводит к системным потерям и хаосу в организации. Правильный подход предполагает фиксацию приоритетов до начала работы, отказ от их изменения в процессе и осознание влияния любого изменения приоритета на всю систему задач в целом.

Несмотря на ограничения, «доска аварий» ускоряет первичную диагностику, централизует информацию об инцидентах и помогает координировать действия команды. Она служит отправной точкой для анализа, снижая время на поиск информации о проблемах. Даже при упрощённом отображении она повышает осведомлённость персонала и может предотвратить дублирование усилий при решении инцидентов.

Важно учитывать получателя при составлении делового письма, потому что от его роли в реализации ИТ-инициативы зависит степень влияния и важность формулировок. Если получатель является лицом, принимающим решения, то текст нужно составлять более тщательно и аккуратно. Также необходимо учитывать предпочтения получателя по восприятию информации: предпочитает ли он цифры и факты, графики и диаграммы или описательную информацию. Это помогает подобрать правильную подачу информации и приложения, что повышает вероятность успешного взаимодействия и быстрого принятия решения по запросу.

Если не фиксировать решения после совещания, то на следующей встрече не придется начинать с контроля выполнения задач, что избавляет от ответственности и позволяет сосредоточиться на новых темах. Отсутствие записи решений, сроков и ответственных приводит к тому, что совещания становятся повторяющимися и бесконечными, без реального прогресса по проектам и задачам.

Основной базовый набор ключевых метрик DevOps включает: время нахождения идеи в бэклоге (пока не взяли на реализацию), время прохождения задачи от начала работы до выпуска в продуктивную среду, долю выполненных задач, которые принесли ожидаемую пользу, и предсказуемость выполнения взятых на себя задач за определенные временные периоды. К этому базовому набору можно добавить дополнительные метрики, такие как velocity, MTTR (среднее время восстановления), MTBF (среднее время наработки на отказ) и расход ресурсов на устранение дефектов и инцидентов. Однако важно не количество метрик, а то, что они дают объективную картину ситуации и помогают в принятии решений для уменьшения времени выпуска продукта (lead time).

Традиционный KPI, основанный на соблюдении сроков устранения инцидентов, имеет существенный недостаток: он не мотивирует на оперативное восстановление сервисов. Поскольку оценка считается успешной, если инцидент устранен до максимального времени восстановления (Tmax), это создает ситуацию, когда исполнители могут откладывать решение до последнего момента. При этом даже при полном соблюдении сроков бизнес может понести значительные убытки из-за длительных простоев, которые формально находятся в рамках норматива.