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

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

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

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

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

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

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

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

WIP-лимиты (Work in Progress Limits) оказывают значительное влияние на сокращение Time to Market, ограничивая количество задач, одновременно находящихся в работе. Это предотвращает перегрузку команды, уменьшает контекстные переключения и позволяет сосредоточиться на завершении текущих задач вместо их бесконечного запуска. Когда команда не пытается сделать всё сразу, но фокусируется на ограниченном количестве задач, циклическое время каждой задачи существенно сокращается. Например, в деловой игре 'Проект Феникс' внедрение WIP-лимитов и упорядочение потока работы позволили снизить Time to Market с 25 минут до 40 секунд - 1,5 минуты. WIP-лимиты также делают проблемы видимыми, так как перегрузка и узкие места становятся очевидными, что позволяет оперативно их устранять.

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