Когда говорят о внедрении ITSM-практик, чаще всего вспоминают неясность ролей, нехватку данных, слабую поддержку руководства и сложность интеграции с существующей средой… ITIL описывает роли, процессы, RACI-матрицы — и кажется, что главная сложность в том, чтобы люди начали работать по-новому.
Но в реальности есть другая проблема. Организация должна одновременно делать две вещи: быстро запускать новые услуги и не разваливать текущую поддержку. Многие ИТ-компании, внедряя цифровую и ИТ-стратегию (Digital and IT Strategy, DITS) и практики ITIL 4 параллельно, сталкиваются с дилеммой: цифровой лидер (стратег) и владелец процессов (операционист) начинают бороться за одни ресурсы и право принимать решения.
Контекст
В типичной ИТ-компании, обслуживающей внешних заказчиков, есть руководитель сервисного отдела — операционист, который выстроил практики управления, ориентируясь на рекомендации ITIL 4. Есть назначенные владельцы услуг для каждого заказчика, владелец практики для управления инцидентами, прописана RACI-матрица. Заявки перестали теряться, SLA контролируются. И есть технический директор — стратег, который видит, что рынок требует новых услуг: дашборды для заказчиков, интеграцию с их системами, предиктивный мониторинг.
Оба правы по-своему, каждый смотрит на бизнес со своей позиции. Проблема в том, что стул принятия решений у них один, а претендентов двое.
Кто платит за скорость?
При запуске пилотного проекта возникает естественная настороженность. Стратега волнует быстрый старт — через две недели, силами двух разработчиков создать MVP для нескольких заказчиков. Операционист требует соблюдения процедур: наличия владельца услуг, оценки влияния на существующие SLA, согласования изменений. Вопрос в том, чей приоритет важнее.
На первый взгляд кажется, что стратег прав, потому что он видит будущее и рыночные возможности. Но у операциониста есть KPI по соблюдению SLA, и необдуманные изменения мешают этим целям. Если новая услуга вызовет сбои, то штрафы по действующим контрактам могут превысить всю прибыль за квартал. Кроме того, операционисту лично изменения могут быть невыгодны: зачем рисковать стабильностью, если стратег получит признание за новую услугу, а он — упавшие показатели KPI?
Решение на мой взгляд может быть в разделении горизонтов деятельности. Стратег работает с прототипом на ограниченный срок, без жестких RACI, с отдельным бюджетом ошибки. После подтверждения ценности инициатива передается операционисту, который вводит ее в промышленную эксплуатацию в соответствии с подходами ITIL 4.
Зона без передачи
Некоторые инициативы стратега вообще не предполагают передачу операционисту. Это могут быть отдельные линейки услуг для новых заказчиков, которые планируется поддерживать силами самих разработчиков. Операционист просто не получает о них информации. Проблема обнаруживается в момент первого инцидента, когда заказчик обращается в сервис-деск с вопросом по новой услуге, а агенты сервис-деска ничего про нее не знают. Время решения растет, заказчик недоволен.
Операционист, выстраивавший процессы, оказывается в ситуации, когда его экспертизу проигнорировали, а у него нет инструментов управлять тем, о чем он даже не знает. А что, если добавить в RACI-матрицу каждой новой инициативы строку «Передача в операционное управление» с совместной ответственностью стратега и операциониста? Если инициатива не передается, то стратег фиксирует причину и берет на себя всю поддержку силами своей команды. Это непростое решение, но оно заставляет договариваться.
Реальность совместной работы
Когда управленческие практики выстроены, то рабочие процессы становятся устойчивыми и понятными. Инженеры принимают необходимость регистрации заявок и соблюдения SLA. Основная сложность в другом: стратегу и операционисту приходится одновременно делать две вещи: поддерживать текущую стабильность услуг и запускать новые инициативы в условиях неопределенности.
Совещания, согласования, правки RACI — все это происходит параллельно с операционной деятельностью, где заказчики ждут быстрых ответов. Именно здесь становится понятно, почему цифровая трансформация в небольших ИТ-компаниях дается непросто. Рабочая схема выглядит так: стратег запускает пилоты, часть из них передается операционисту в промышленную эксплуатацию, часть остается в зоне ответственности стратега. Главное условие, чтобы обе стороны знали, кто за что отвечает на каждом этапе.
Как готовиться к таким конфликтам
У большинства ИТ-компаний редко есть возможность потренироваться в разведении ролей стратега и операциониста. Обычно все происходит одновременно: и новые услуги надо запускать, и текущие заказчики не должны пострадать. Простые инструменты помогают зафиксировать договоренности — например, RACI-матрицы с дополнительной строкой передачи позволяют увидеть управленческие дилеммы до того, как они перерастут в полноценный конфликт.
Когда похожая ситуация возникает в компании, то она уже не выглядит неразрешимой. Достаточно четко прописать, кто за что отвечает на этапе прототипа, а кто — на этапе промышленной эксплуатации, и не забыть про точку передачи между ними.
