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

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

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

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

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

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

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

После устранения major-инцидента необходимо: оперативно оповестить ИТ-специалистов, чтобы они могли завершить обработку всех связанных обращений и проверить восстановление ИТ-услуг; уведомить конечных пользователей о восстановлении сервисов; провести мини-расследование (major incident review) с формированием отчета, направленного на предотвращение повторения инцидента; оценить действия по обработке инцидента и при необходимости зарегистрировать проблему, известную ошибку или новые мероприятия по улучшению ИТ-услуг (например, в рамках service improvement plan или реестра CSI).

Управление проблемами существенно влияет на сокращение времени решения инцидентов, хотя часто его значение недооценивают. Если уменьшить общее количество инцидентов путем выявления и устранения их первопричин, это приведет к снижению нагрузки на персонал поддержки. Даже при одинаковой производительности сотрудников, меньшее количество инцидентов существенно снизит среднее время их решения из-за снижения очереди. Например, при 24 инцидентах в день (при условии их одновременного поступления утром) среднее время решения возрастает до 4 часов 10 минут, а при 12 инцидентах - падает до 2 часов 10 минут. Таким образом, управление проблемами влияет на процесс косвенно, сокращая поток инцидентов, что особенно важно с учетом неравномерного распределения инцидентов в течение дня (пиковой нагрузки в определенные часы).

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