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

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

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

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

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

Бизнес-руководители, даже обладая минимальным знанием ИТ, могут участвовать в деловых играх, таких как Grab@Pizza, чтобы понять принципы организации современного ИТ-подразделения, научиться учитывать финансы и KPI при определении приоритетов, отрабатывать улучшение бизнес-процессов. Важные условия: мотивация команды и осознание стратегической зависимости бизнеса от ИТ-инфраструктуры.

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

В некоторых моделях, например в IBM Tivoli Unified Process, роль координатора изменений называется 'Владелец изменений'. Это создает терминологическую путаницу из-за многозначного использования слова 'Owner' в ИТ-управлении. Слово 'Owner' уже используется в других контекстах, например, в управлении конфигурацией или в бизнес-аналитике, что может привести к недопониманию при коммуникации между различными подразделениями или при использовании разных методологий. Хотя эта неоднозначность не влияет напрямую на функциональные обязанности, она может создавать сложности в обучении персонала и при переходе между различными процессными моделями

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

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