На курсах Cleverics мы часто задаем слушателям провокационный вопрос: «Ваши команды взаимодействуют или сотрудничают?» Вначале многие не видят разницы. Но именно в этом различии кроется ключ к переходу от формально работающих процессов ITSM к системе, которая реально создает ценность для бизнеса.
Если этот вопрос заставляет вас задуматься, значит, вы уже почувствовали ту самую трещину в фундаменте ITSM, о которой пишет Дэвид Биллуз (David Billouz). Его статья вскрывает главный парадокс современных сервисных моделей: мы можем быть идеальны в рамках своих зон ответственности, но при этом коллективно терпеть неудачу. Давайте разберемся, почему разрыв между этими двумя понятиями — это не семантика, а главный скрытый риск для бизнеса.
Многие организации вложили значительные средства в управление ИТ-услугами (ITSM). Процессы стандартизированы, соглашения об уровне услуг (SLA) определены, а за показателями производительности пристально следят с помощью панелей мониторинга. На первый взгляд кажется, что все находится под контролем: команды работают вместе, инциденты разрешаются, а услуги предоставляются. Но под этой полированной поверхностью скрывается тонкий и опасный риск: люди могут взаимодействовать, но не сотрудничать. В этом различии заключается вся разница между ITSM, который выглядит эффективным, и ITSM, который на самом деле приносит пользу бизнесу. В этой статье объясняется, почему взаимодействие без сотрудничества в ITSM — это скрытый риск.
Взаимодействие vs. сотрудничество в ITSM
Эти два термина часто используются как взаимозаменяемые, но на практике это разные миры:
- Взаимодействие (Cooperation) носит транзакционный характер. Команды передают результаты работы, обмениваются обновлениями и соблюдают установленные границы.
- Сотрудничество (Collaboration) носит преображающий характер. Оно требует совместного творчества для достижения общей цели, взаимной ответственности и ориентации на реальные результаты, а не просто на выполненные задачи.
В ITSM многие организации невольно останавливаются на взаимодействии. Каждая команда оптимизирует свою собственную производительность, но эти элементы не соединяются в единые потоки создания ценности. Каков результат? Услуги, которые хорошо управляются на бумаге, но не соответствуют тому, что на самом деле нужно бизнесу.
Почему возникает этот риск сотрудничества в ITSM?
Несколько системных факторов в совокупности создают этот риск:
- Фрагментированные ключевые показатели эффективности (KPI) и цели и ключевые результаты (OKR). Многие организации по-прежнему измеряют производительность в условиях разрозненности. Например, сервис-деск получает вознаграждение за быстрое закрытие заявок, команда по инфраструктуре — за поддержание бесперебойной работы, а команда по разработке приложений — за предоставление функционала. По отдельности эти метрики выглядят позитивно. Но вместе они создают фрагментарную картину. Заявка может быть «решена в рамках SLA». Однако, если это потребовало нескольких передач и заняло недели, клиентский опыт все равно негативный. Эта проблема признана в ITIL 4, где подчеркивается переход от метрик, ориентированных только на процесс, к метрикам, ориентированным на поток ценности.
- Близорукость среднего звена. Менеджеры среднего звена по-прежнему часто сосредотачиваются на оптимизации собственного отдела, а не всей системы. Не имея «общего представления» о стратегических целях, они непреднамеренно усиливают бункеры. Известная статья Майкла Хаммера (Michael Hammer) в Harvard Business Review «Reengineering Work: Don’t Automate, Obliterate» (1990) предупреждала об этом: организации рискуют стать эффективными в неправильных вещах. Это предупреждение столь же актуально в сегодняшней экономике цифровых услуг, как и на заре реинжиниринга процессов.
- Индивидуальные системы поощрений. Когда управление эффективностью делает акцент на индивидуальном героизме, это подрывает сотрудничество в ITSM. Например, инженер по эксплуатации, получающий вознаграждение за время безотказной работы, может сопротивляться изменениям, которые влекут за собой простои, даже если эти изменения способствуют инновациям. Или разработчик, получающий вознаграждение за предоставление функциональности, может внедрить код в продакшн, не учитывая удобство обслуживания. Оба человека добиваются успеха в своих собственных показателях, но организация проигрывает.
- Культура, ориентированная на процесс. Исторически сложилось так, что ITSM был ориентирован на процессы и унаследован от ранних фреймворков ITSM. Соблюдение технологического процесса становится первоочередной целью. Несмотря на то, что процессы необходимы, управление ими по отдельности создает ложное ощущение контроля. В результате получаются услуги, которые являются «зелеными» на дашборде, но фрагментированы на практике.
Последствия взаимодействия без сотрудничества в ITSM
Отсутствие сотрудничества в ITSM не просто замедляет работу; это также препятствует прогрессу. Это создает структурные барьеры для создания ценности:
- Потоки создания ценности не могут возникнуть. Без взаимодействия в ITSM процессы остаются изолированными. Они никогда не подключаются к сквозным потокам создания ценности, которые превращают бизнес-стратегию в достигнутые результаты.
- Неэффективная передача полномочий. Каждая команда хорошо работает в пределах своих границ, но каждый этап передачи становится точкой трения. Заявки «прыгают» между командами. Накапливаются задержки. Ответственность размывается.
- Стратегический дисбаланс. Локальная оптимизация может даже противоречить организационным приоритетам. Команда по соблюдению нормативных требований может достичь 100% соблюдения политики, но при этом вносить задержки, которые делают инновации невозможными. Или команда по инфраструктуре может достичь целевых показателей по времени безотказной работы, но блокировать изменения, инициированные бизнесом, необходимые для выхода на новые рынки.
- Подрыв доверия и морального духа. Команды демонстрируют отличные результаты на локальном уровне, но в масштабах компании это оборачивается провалом. На границах процессов процветает поиск виноватых. В итоге страдает моральный дух команды и растет текучесть кадров.
Рост DevOps
Движение DevOps является одним из самых четких ответов на этот риск. В течение многих лет команды разработчиков и эксплуатантов сотрудничали посредством формальной передачи полномочий — код разрабатывался, тестировался, а затем «перебрасывался через стену» в эксплуатацию.
Но настоящего сотрудничества не было. Разработчики не несли ответственности за бесперебойную работу, а эксплуатационные команды не были мотивированы облегчать внесение изменений.
DevOps разрушил этот барьер, внедрив совместную ответственность и общие метрики, такие как среднее время восстановления (MTTR) и частота развертываний.
Управление корпоративными услугами (ESM)
Поставщики ITSM-инструментов, ориентированных на ESM, неоднократно сообщали о том, что организации, внедряющие картирование потоков создания ценности, видят большую согласованность бизнеса.
Там, где потоки создания ценности не выстроены, инструменты ESM превращаются в дорогие процессные движки: они эффективны при передаче задач, но не способны обеспечивать достижение результатов.
Снижение рисков сотрудничества в ITSM
Отсутствие сотрудничества в ITSM не является неизбежным. Организации могут предпринять конкретные шаги для его смягчения:
- Переход к метрикам, основанным на ценности. Выйдите за рамки соблюдения SLA и разрозненных KPI. Сосредоточьтесь на общих бизнес-результатах, таких как удовлетворенность клиентов, время выхода на рынок или соотношение затрат и ценности.
- Внедрите картирование потока создания ценности. Используйте методы бережливого производства (например, Rother & Shook’s Learning to See), чтобы наглядно представить, как происходит непрерывный поток ценностей. Это способствует общему пониманию того, что влечет за собой успех.
- Создание кросс-функционального управления. Установите такие роли, как владельцы ценности, используйте совместные OKR или применяйте фреймворки, такие как планирование инкремента программы SAFe, чтобы согласовать несколько команд.
- Развивайте культуру сотрудничества. Проводите меж командные ретроспективы. Организуйте совместные воркшопы по решению проблем. Признавайте и поощряйте коллективные достижения, а не просто индивидуальный вклад.
Влияние взаимодействия без сотрудничества в ITSM
Риск взаимодействия без сотрудничества в ITSM особенно опасен тем, что он скрывается на виду. На дашбордах и в отчетах всё выглядит благополучно: SLA горят зеленым, процессы соблюдаются, команды заняты работой.
Но без сотрудничества организация остается разобщенной. Она оптимизирует отдельные части системы в ущерб целому. Сквозные потоки создания ценности не могут сформироваться. Стратегические цели остаются недостижимыми.
Подлинное сотрудничество с общими целями, общей ответственностью и совместно создаваемой ценностью — это недостающий элемент. Без него ITSM (и ESM) остаются всего лишь набором процессов. С ним же ITSM (и ESM) становятся драйвером стратегии, инноваций и конкурентного преимущества.
.
