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

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

Координатору релизов от менеджера процесса могут быть делегированы следующие обязанности в рамках конкретного направления: управление ресурсами, непосредственно участвующими в процессе релиза; координация деятельности практиков (пакетирования, построения, развёртывания и первичной поддержки) внутри направления; контроль соблюдения сроков и качества выполнения этапов релиза; обеспечение взаимодействия между командами, задействованными в релизе; сопровождение релиза на всех этапах — от планирования до закрытия. Такая делегация полномочий позволяет менеджеру процесса сосредоточиться на стратегических аспектах и взаимодействии с другими процессами, а координатору релизов — на оперативном управлении конкретными релизами в рамках своего направления.

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

Доступность ИТ-услуги измеряется по формуле: (время, в течение которого услуга была доступна) / (время, в течение которого услуга должна быть доступна). Однако для точного измерения необходимо определить критерии доступности и интервалы предоставления услуги. Показатель рассчитывается с использованием данных мониторинга интерфейсов, API, веб-страниц, анализа логов, end-to-end тестирования и контроля соблюдения SLA. Важно суммировать интервалы недоступности с учетом их пересечения. При отсутствии автоматизации могут использоваться менее точные методы, такие как учет длительности инцидентов, но это может привести к искажению данных.

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

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

Руководство играет ключевую роль в успешной реализации SIP. Без понимания и желания руководства искать и находить способы повышения удовлетворённости заказчиков сама идея SIP в организации не может существовать долго. Поддержка руководства необходима для обеспечения ресурсов, согласования решений и обеспечения ответственности за выполнение задач. Руководство должно организовывать или включать в повестку встречи по совершенствованию услуг обсуждение SIP, что позволит системно подходить к процессу постоянного улучшения и не допустить разрыва цикла улучшений.

Для преодоления первоначальных сложностей при внедрении CI/CD рекомендуется составить карту или чек-лист технических практик, необходимых для реализации полноценного конвейера развёртывания. Следует осознать и обсудить, какие области требуют изменений, оценить текущий уровень и определить размер необходимых изменений ('разрыв'). После этого планомерно, ритмично и в рамках выделенного времени (например, 'налога в 20%') реализовывать изменения практических подходов. Рекомендуется также заранее договориться о желаемых параметрах конвейера, например, что он должен доставлять изменения до продуктивной среды в течение 15 минут. Такой четкий ориентир поможет определить, работает конвейер эффективно или нет, избегая неопределенных формулировок вроде 'как бы работает, но не очень'.

Предлагается использовать три ключевых показателя, отражающих разные аспекты влияния простоев на бизнес: 1) Суммарное время простоев за период, отражающее общий объем недоступности; 2) Максимальный разовый простой, учитывающий критичность длительных прерываний, которые могут вызвать значительные убытки и репутационный ущерб; 3) Количество нарушений, важное для бизнес-процессов, чувствительных к частым кратковременным простоям (например, длительные вычисления, требующие перезапуска). Также упоминается альтернативный показатель - минимальная или средняя продолжительность работы без нарушений.