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

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

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

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

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

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

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

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

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

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