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

Более важным при внедрении процессов является формирование культуры измерения и понимания её ценности среди сотрудников, нежели формальное заполнение раздела KPI. Разработка метрик без понимания их цели и применения приведет к созданию формальных показателей, которые не будут использоваться для принятия реальных решений.

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

Совмещение управления ИТ-услугами по ITIL с управлением проектами требует четкого разделения зон ответственности и процессов. Определите четкие границы между операционной поддержкой услуг (ITIL) и проектной деятельностью (управление проектами). Установите процесс перехода от проекта к эксплуатации, чтобы обеспечить бесшовную передачу новых функциональностей в управление ИТ-услугами. Синхронизируйте планирование: бюджетирование ИТ-услуг должно учитывать как операционные расходы, так и проектные инициативы. Используйте общий инструмент управления работой, где отдельные задачи распределяются в соответствующие потоки (операционные или проектные). Создайте совместные комитеты по управлению изменениями, включающие как руководителей ИТ-услуг, так и руководителей проектов. Убедитесь, что планы непрерывности бизнеса включают как операционные, так и проектные аспекты. Внедрите модель двойного бюджета: операционный бюджет для поддержки услуг и проектный бюджет для развития. Для крупных проектов формируйте совместные команды, включающие специалистов по управлению услугами на этапе проектирования. Установите общие метрики, оценивающие как стабильность эксплуатации, так и успешность реализации проектов. Создайте четкий процесс для управления запросами на новые функциональности, который интегрирует приоритизацию бизнес-требований через Service Portfolio Management и управление требованиями в проектах.

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

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

Для сохранения мотивации команды при постоянном отклонении предложений по рефакторингу важно создать прозрачный процесс оценки и приоритизации таких задач. Следует объяснить инженерам причины отклонения конкретных предложений и предложить альтернативные пути решения технических проблем. Рекомендуется регулярно обсуждать состояние технического долга на ретроспективах и совместно определять план его уменьшения. Важно обеспечить, чтобы инженеры видели, что их профессиональное мнение учитывается, и что в долгосрочной перспективе их предложения по улучшению кодовой базы будут реализованы. Можно внедрить практику откладывания части времени (например, 10-20%) на технические улучшения, независимо от текущих бизнес-приоритетов. Организация внутренних технических хакатонов или выделение времени для экспериментов также помогает поддерживать мотивацию. Прозрачная коммуникация о том, как текущие технические ограничения влияют на бизнес-цели, поможет команде понять обоснованность приоритизации задач.

При анализе связи «Человеческий фактор» в системном подходе к ITSM следует задавать такие вопросы: насколько инструмент полезен и удобен для пользователей, учитывает ли он их особенности, привычки и пожелания, могут ли сотрудники использовать новую технологию для работы (достаточно ли у них знаний и навыков, есть ли необходимость в обучении), чем обеспечено надлежащее использование инструмента и контроль ошибок. Эти вопросы помогают оценить, насколько хорошо технологические решения учитывают поведение и потребности людей, что критически важно для успешного внедрения любых изменений в системе управления ИТ-услугами.

В ITIL4 владелец практики (Practice owner) отвечает за общее управление, развитие и стратегическое направление всей практики 'Поддержка изменений' как функциональной области, тогда как менеджер изменений (Change manager) фокусируется на оперативном управлении жизненным циклом отдельных изменений и развитии практики на тактическом уровне. Владелец практики определяет стандарты, политики и общие направленность практики на уровне организации, в то время как менеджер изменений реализует эти стандарты на практике, управляя конкретными изменениями и их внедрением. В небольших организациях эти роли могут быть объединены в одном лице.

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