ITIL рекомендует формулировать требования к срокам через конкретные даты и оценку влияния на бизнес. Например, вместо «это срочно» бизнес должен указать: «изменение нужно внедрить до 15 сентября, иначе будет потеряно 100 клиентов». Такой подход устраняет субъективность и позволяет ИТ-команде спланировать загрузку. Для emergency-изменений сроки определяются критичностью инцидента: если сервис недоступен, решение нужно «до восстановления сервиса», что фиксируется в метриках времени восстановления (MTTR).

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

Культура DevOps интегрирует элементы ITIL и Lean-подходов, заимствуя из ITIL процессы управления инцидентами и проблемами, а также концепцию управления циклом мониторинга и контроля. Из Lean-методологии заимствуется принцип непрерывного улучшения, минимизация потерь и методы вроде «Пяти Почему» для анализа корневых причин. Такая интеграция позволяет DevOps не только ускорить разработку и внедрение, но и повысить надёжность и качество конечного продукта за счёт использования проверенных в других областях практик.

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

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

Удовлетворенность заказчика зависит не только от фактического качества услуг, но и от субъективного восприятия ситуации. Люди больше ориентируются на свои восприятие и эмоции, чем на объективные фактические данные. Критически важными для восприятия заказчика являются такие элементы, как компетентность сервис-провайдера, вежливость и отзывчивость сотрудников, способность четко демонстрировать достигнутые результаты. Это означает, что даже при временном отклонении от установленного уровня услуги (SLA), заказчик может остаться удовлетворен, если воспринимает сервис-провайдера как надежного и компетентного партнера. В то же время, безупречно соблюдая SLA, можно не достичь удовлетворенности заказчика, если он не видит ценности в предоставляемых услугах.

Измерение только технических параметров не обеспечивает понимания того, насколько ИТ-сервис действительно соответствует бизнес-целям. Например, в случае электронной почты технически корректной может считаться отправка письма сервером сразу после нажатия кнопки, однако если доставка занимает восемь часов, то конечный пользователь будет недоволен. Для бизнеса важен именно конечный результат — своевременная доставка писем. То же самое касается рекламы в метро: формально система работала, но сбойное окно ухудшало восприятие рекламы, что негативно сказывалось на её эффективности. Конечный результат — это то, что видят пользователи и что влияет на бизнес-процессы.

Правильный подход к разработке KPI в области управления ИТ заключается в построении логической цепочки: Назначение ⇒ ключевые практики ⇒ метрики ⇒ целевые и граничные значения ⇒ KPI. Первый этап подразумевает четкое определение назначения процесса и его роли в организации. На следующем этапе формулируются ключевые практики, необходимые для достижения этого назначения. Затем определяются метрики, которые будут отслеживать выполнение этих практик. Далее устанавливаются целевые и граничные значения для каждой метрики, и только на завершающем этапе формируются KPI на основе всей этой информации. Этот подход противопоставляется попыткам найти готовые KPI в интернете или литературе (например, на kpilibrary.com с более чем 6500 примерами), которые часто не соответствуют конкретным целям и особенностям организации. Главный принцип: KPI должны разрабатываться специально для решения конкретных задач вашей организации, а не браться из общих примеров.

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

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