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

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

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

ITIL 4 предлагает решать проблему разобщенности через принцип 'Используйте целостный подход' (Think and work holistically) и через рассмотрение четырех аспектов управления ИТ-услугами. Этот принцип подразумевает необходимость понимания того, как все части организации работают вместе интегрированным образом. Вместо того чтобы фокусироваться на отдельных элементах (процессах без учета инструментов и компетенций, или наоборот), ITIL 4 предлагает рассматривать четыре взаимосвязанных аспекта: организации и люди, информация и технологии, партнеры и поставщики, потоки создания ценности и процессы. Для устранения разобщенности также необходимо формировать организационные структуры, ориентированные на сотрудничество, развивать культуру доверия и прозрачности, обеспечивать достаточные компетенции сотрудников и правильно определять взаимодействие с партнерами. Важно рассматривать процессы не изолированно, а как часть потоков создания ценности, что обеспечивает целостное преобразование входов в результаты, воспринимаемые клиентом.

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

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

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

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

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

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