Переход к новой модели поддержки не всегда требует одномоментной замены всех исполнителей. У текущего подрядчика могут оставаться уникальные компетенции, незавершенный проект, лицензии или право сопровождать конкретный продукт. Одновременно часть регулярных работ можно передать новой команде, а ключевые решения оставить внутри компании.
Проблема появляется, когда разделение делают только по системам или юридическим границам. Бизнес-сервис проходит через несколько платформ, и сбой на стыке мгновенно превращается в спор «чья зона». Поэтому сначала нужно разделить ответственность за результат и типы работ, а уже потом назначать исполнителей.
Подрядчик — это способ организовать исполнение, а не единица архитектуры. Один и тот же поставщик может отлично вести узкую платформу и плохо координировать межсистемные инциденты. Другой способен закрывать сквозной сервис, но не иметь права выполнять специфическую вендорскую работу. Решение нужно принимать по обязанностям, а не по бренду участника.
Для каждой обязанности полезно определить, где должно находиться право решения. Владелец архитектуры, владелец бизнес-процесса, исполнитель изменения, первая линия и координатор критичного инцидента могут быть разными ролями. Если эта схема понятна, организационные границы перестают мешать работе.
Удобно разделить работу на пользовательскую поддержку, функциональную экспертизу, администрирование, мониторинг, интеграции, разработку, релизы, управление проблемами, управление знаниями и сервис-менеджмент. Для каждого блока фиксируются объем, критичность, необходимые доступы и зависимость от других участников.
Такой разбор часто показывает, что текущая граница контракта не совпадает с реальной работой. Например, подрядчик формально отвечает за ERP, но значительная часть времени уходит на координацию интеграций и данные. Это нужно учесть до распределения функций между командами.
Сохранять участок разумно, если у подрядчика есть уникальная экспертиза, подтвержденный стабильный процесс, специфические права или договоренности с вендором, а смена создает риск без очевидного выигрыша. Еще один аргумент — незавершенный проект, где передача в середине работы дороже и опаснее завершения текущей командой.
Но такое решение должно иметь срок и критерии пересмотра. Формулировка «оставим, потому что он давно это делает» не достаточна. Нужно понимать, какие знания останутся у заказчика, как будет работать координация и что произойдет, если позже этот участок тоже потребуется передать.
Передача оправдана, когда текущая схема не обеспечивает нужную управляемость: повторные инциденты не разбираются, SLA выполняется формально, но бизнес страдает, знания завязаны на людей, нет прозрачной отчетности, а стыки между системами остаются без владельца. Важно оценивать не только цену, но и способность новой команды закрыть эти разрывы.
Новой команде особенно логично передавать функции, которые требуют единой координации: диспетчеризация, сервис-менеджмент, мониторинг сквозных сервисов, управление проблемами, единая отчетность. Тогда даже при сохранении профильных подрядчиков у бизнеса появляется один контур управления.
Внутри обычно остаются бизнес-приоритеты, владение архитектурой, принятие критичных рисков, согласование существенных изменений и контроль бюджета. Даже при глубоком аутсорсинге кто-то со стороны заказчика должен определять, что является приемлемым результатом и в каком направлении развивается ландшафт.
Не стоит оставлять внутри операционные согласования только из-за страха потерять контроль. Если каждое типовое действие требует ручного разрешения ИТ-директора, сервис замедляется. Контроль лучше переносить в матрицу полномочий и пороги риска.
Первая модель — разделение по линиям поддержки: например, первая линия внешняя, экспертиза внутри. Вторая — по технологиям, когда разные команды ведут ERP, инфраструктуру и интеграции. Третья — по типам работ: эксплуатация одной команде, развитие другой. Четвертая - единый сервисный координатор плюс несколько профильных исполнителей.
Ни одна модель не универсальна. Для корпоративного ландшафта часто работает гибрид, где мультиплатформенное сопровождение отвечает за сквозную координацию, а отдельные специализированные задачи остаются у профильных команд.
Если сбой затрагивает две системы, пользователю все равно, какой договор формально нарушен. Нужен один владелец инцидента, который удерживает коммуникацию и движение к восстановлению. Он может не иметь технического доступа ко всем компонентам, но обязан координировать исполнителей и эскалации.
То же относится к изменениям. Если релиз одной системы требует подготовительных действий в другой, граница ответственности должна быть зафиксирована заранее: кто инициирует, кто согласует окно, кто проверяет зависимые процессы и кто принимает итог.
Несколько подрядчиков не должны создавать несколько несовместимых версий контекста. Заказчику полезно определить единый контур ITSM, общие правила идентификации сервисов, единый каталог контактов и минимальный набор знаний, доступный всем участникам в рамках роли.
Доступы при этом остаются раздельными. Общий инструмент не означает общие административные права. Каждая команда получает свои полномочия, а действия в продуктиве фиксируются так, чтобы можно было восстановить, кто и на каком основании их выполнял.
Пилот лучше проводить на нескольких сценариях: критичный инцидент на стыке систем, плановое изменение, повторяющаяся проблема и запрос бизнеса на доработку. Для каждого сценария команда заранее описывает маршрут и затем проверяет его на реальной или тестовой задаче.
Если участники начинают спорить о владельце уже во время пилота, это полезный результат: спорную границу можно исправить до масштабирования. Гораздо опаснее обнаружить ее после полного переключения.
Для каждого блока поддержки оцените критичность, уникальность экспертизы, качество текущего процесса, зависимость от других систем, стоимость перехода и необходимость единой координации. Затем назначьте один из трех режимов: оставить, передать или вести совместно в переходный период.
Матрица должна быть временной, если выбрана совместная схема. У нее должны быть критерии выхода: какие знания переданы, какие задачи завершены, какой уровень сервиса подтвержден. Иначе переходный формат легко становится постоянным и сохраняет все старые разрывы.
После распределения работ нужно измерять не только показатели каждого подрядчика, но и качество стыков. Полезно отслеживать время передачи задач между командами, число возвратов из-за неверной маршрутизации, количество инцидентов с неясным владельцем, доля изменений, где потребовалось незапланированное участие другой стороны. Эти показатели показывают, насколько хорошо работает сама схема разделения ответственности.
Раз в несколько месяцев имеет смысл пересматривать границы. Участок, который первоначально оставили старой команде из-за уникальной экспертизы, может стать готовым к передаче после документирования и обучения. И наоборот, новая зона может потребовать участия внутреннего владельца. Гибридная модель должна развиваться вместе с ландшафтом, а не превращаться в постоянный компромисс из-за исторических договоренностей.
Чем больше участников в поддержке, тем важнее единая точка сервисного управления. Она не обязана выполнять всю техническую работу, но должна держать каталог сервисов, общую очередь критичных проблем, правила эскалации и единый отчет для заказчика. Без этого каждая команда оптимизирует собственный участок, а сквозные потери остаются невидимыми.
Единое управление не отменяет договоры и ответственность профильных подрядчиков. Оно создает общий контур принятия решений: кто собирает статус, кто поднимает межподрядную эскалацию, кто следит за зависимыми изменениями и кто показывает бизнесу результат. Именно этот уровень позволяет гибридной модели оставаться управляемой.
| Область | Оставить текущему подрядчику | Передать новой команде | Оставить внутри | Критерий решения |
|---|---|---|---|---|
| Уникальная доработка | Возможно | После передачи знаний | Архитектурный контроль | Экспертиза и обратимость |
| Регулярная поддержка | Нет | Да | Контроль качества | Стабильность и масштабирование |
| Ключевые архитектурные решения | Консультация | Консультация | Да | Ответственность заказчика |
Правильное разделение поддержки не ищет «лучшего подрядчика для всего», а создает понятные границы решений и ответственности. Для оценки схемы полезно сверить ее с проектами сопровождения, а конкретную конфигурацию можно обсудить с IBS на нескольких сквозных сценариях.