Гибридная модель ИТ: как совместить свою команду и аутсорсера без конфликта зон ответственности

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

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

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

Какие бывают формы гибридной модели

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

Одна и та же компания может двигаться между формами. Часто всё начинается с передачи одного направления, дальше подрядчику отдают дежурства, а через год — всю эксплуатацию.

Хороший пример того, как гибрид устроен экономически, — центр мониторинга информационной безопасности. По оценкам, приведённым в отраслевом разборе на Codeby, запуск собственного SOC обходится в 40–60 млн рублей в год, подписка у внешнего провайдера — в 3–8 млн, а гибридная схема, где провайдер закрывает первую линию, а ядро работает внутри, — в 15–30 млн. Логика та же, что и в общем ИТ: массовое исполнение снаружи, экспертиза и решения внутри.

Где возникают конфликты

Инцидент на стыке зон

Самый частый сценарий. Пользователи не могут зайти в систему учёта. Подрядчик проверил сервер — работает. Внутренний администратор проверил приложение — работает. Проблема оказывается в сетевой настройке, за которую формально не отвечает никто. Пока выясняют, система лежит.

Корень проблемы в том, что ответственность описали по компонентам, а пользователь видит сервис целиком. Каждая сторона выполняет свой SLA, а бизнес стоит.

Изменения без согласования

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

Ничьи задачи

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

Перекидывание заявок

Пользователь пишет внутреннему администратору, тот перенаправляет подрядчику, подрядчик отвечает, что это не входит в договор, и возвращает обратно. Время решения растёт, а в отчётах обеих сторон заявка закрыта вовремя.

Конкуренция вместо сотрудничества

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

Матрица ответственности

Базовый инструмент, без которого гибрид не работает. Матрица RACI описывает для каждого процесса четыре роли: кто исполняет, кто отвечает за результат, кого консультируют и кого информируют.

Ключевое правило — у каждого процесса ровно один ответственный за результат. Если отвечают двое, не отвечает никто. Исполнителей может быть несколько, ответственный — один.

Это пример, а не шаблон: распределение зависит от формы гибрида и зрелости сторон. Важно другое — матрица должна описывать процессы, а не компоненты. «Серверы — подрядчику, приложения — нам» порождает ровно тот конфликт на стыке, который описан выше. «Восстановление сервиса после инцидента — отвечает руководитель ИТ, исполняют обе стороны» — нет.

Документ получается компактным, на одну-две страницы, и пересматривается при каждом изменении формы сотрудничества.

Механика взаимодействия с подрядчиком

Единая точка входа

Все заявки поступают в одну систему, независимо от того, кто будет их исполнять. Пользователь не должен знать, какая функция передана подрядчику: он пишет в одно место, а маршрутизация происходит внутри. Общая ITSM-система с доступом обеих команд решает сразу две проблемы — перекидывание заявок становится видимым, а история работ хранится в одном месте.

Исследователи мультивендорного аутсорсинга формулируют это жёстко: без общей сервисной модели с едиными процессами, правилами эскалации и сквозными показателями локальные SLA выполняются формально, а важная для бизнеса система остаётся недоступной.

Правила эскалации

Заранее описано, что происходит, если заявка не решена в срок или затрагивает обе зоны. Кто принимает решение, кого привлекают, через сколько времени вопрос поднимается на уровень выше. Для критичных инцидентов — отдельный канал связи и дежурные контакты с обеих сторон.

Управление изменениями

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

Общая документация и доступы

Схемы, конфигурации, пароли от сервисных учётных записей и история инцидентов хранятся у компании и доступны обеим командам. Подрядчик обновляет документацию после своих изменений, внутренняя команда — после своих. Если документация живёт только в системе одной стороны, вторая работает вслепую.

Регулярные встречи и отчётность

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

Люди: как сделать так, чтобы команды работали вместе

Позиционирование подрядчика

Как внутренняя команда воспримет подрядчика, определяется в первую неделю. Если его представить как «теперь у нас будет нормальная поддержка», внутренние специалисты услышат оценку своей работы и займут оборону. Если как «берём на себя дежурства и рутину, чтобы у вас появилось время на проекты», — услышат помощь.

Внутренних специалистов стоит включать в выбор подрядчика и в формирование матрицы ответственности. Люди поддерживают то, что создавали сами.

Владелец отношений

Со стороны компании нужен один человек, который отвечает за работу с подрядчиком: ставит приоритеты, принимает работы, решает спорные вопросы. Обычно это руководитель ИТ. Без этой роли отношения распадаются на десятки частных контактов, в которых теряется общая картина.

Обмен знаниями

Подрядчик приносит опыт других компаний, внутренняя команда — знание бизнеса. Если обмена нет, каждая сторона остаётся со своей половиной. Совместные разборы крупных инцидентов, где обе команды восстанавливают картину и договариваются, что менять, — лучший способ превратить две команды в одну.

«Сильнее всего гибрид работает там, где внутренняя команда перестаёт тратить время на дежурства и заявки и начинает заниматься тем, ради чего её нанимали, — развитием. В таких проектах через полгода уже никто не вспоминает, что у подрядчика и у штата разные работодатели. Хуже всего, когда подрядчика приводят как упрёк своим. Тогда никакая матрица не поможет», — Кирилл Тимофеев, руководитель департамента информационных технологий ОБИТ.

Что зафиксировать в договоре

Договор с подрядчиком в гибридной модели сложнее, чем при полной передаче, потому что описывает не только зону исполнителя, но и точки пересечения. В нём должны быть:

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

Пункт про ничьи задачи почти всегда отсутствует в типовых договорах, а именно он снимает большую часть конфликтов. Достаточно записать, что спорную задачу распределяет руководитель ИТ заказчика в течение одного рабочего дня.

«Мы советуем тратить на матрицу ответственности и порядок изменений больше времени, чем на согласование цены. Цену относительно просто пересмотреть, а неописанные стыки превращаются в конфликты, которые портят рабочие процессы. Хорошая матрица — это две страницы, но за ними месяцы спокойной работы», — Кирилл Тимофеев, руководитель департамента информационных технологий ОБИТ.

С чего начать

Гибридная модель — это схема, в которой собственная ИТ-команда сохраняет управление, архитектуру и владение критичными системами, а внешний подрядчик берёт на себя исполнение: поддержку пользователей, администрирование, мониторинг, дежурства или отдельные направления. Задачи делятся не по компонентам инфраструктуры, а по процессам и слоям: решения внутри, исполнение снаружи. Бывает три основных формы — передача эксплуатации, усиление команды и передача отдельного направления.

Работает гибрид тогда, когда описаны стыки. Для этого нужны матрица ответственности с одним ответственным на каждый процесс, единая точка входа для заявок, общие правила эскалации и изменений, документация, доступная обеим сторонам, и регулярная сверка. Без этой механики каждая сторона формально выполняет свои обязательства, а сервис для бизнеса всё равно ломается на границе.

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

Если рассматриваете гибридную модель или уже работаете с подрядчиком, но стыки даются тяжело, приходите на бесплатную консультацию — поможем выбрать форму сотрудничества и выстроить распределение ответственности.