Как собственнику выбрать между своей ИТ-командой и аутсорсом

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

Автор: Авдей Мартынович, руководитель подразделения по работе с СМБ, ALP ITSM  

Я сам работаю на стороне аутсорсинга, но всегда привожу этот антипример. Вопрос «кому доверить ИТ» решается взвешиванием. Разберу, что аутсорсинг делает лучше вашей команды, что хуже и когда он вообще не нужен. Материал вышел объемным, поэтому разбил его на три статьи: в этой — выбор модели, во второй — десять вопросов подрядчику до заключения договора, в третьей — сам переход без потерь. Дальше — истории заказчиков и подрядчиков, прошедших обе модели, и выводы, которые из них следуют.

Что с 2022 года изменилось в выборе между своей ИТ-командой и аутсорсом

Еще недавно у многих работала простая схема. Свой сисадмин, к которому все ходят с компьютерными бедами, и пара договоров с интеграторами на крупные проекты. Схема треснула в 2022 году, когда радикально изменился рынок труда.

Руководитель ИТ-службы одного завода рассказывал, как у них умерла своя ИТ-служба (инсорс). Зарубежная группа поддержки объявила: через два месяца заводу нужно забрать свои серверы и обслуживаться самостоятельно. Команда ушла, а заменить ее было некем. Полгода поиска специалистов не дали результата, причем кадров не было даже в Москве, не то что в небольшом городе. Промышленному предприятию пришлось с нуля строить работу с внешними подрядчиками.

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

Что аутсорс делает лучше вашей команды

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

Обратная сторона той же медали — зашоренность своих команд. На одном из собеседований инженер рассказывал, как в одиночку собрал кластер на куче самописных скриптов. Работало криво, но работало, и человек был уверен, что иначе нельзя, пока ему не показали, что задача решается штатными средствами давно и надежно. Он столько времени потратил на изобретение велосипеда.

Внутренняя команда годами решает одни и те же проблемы привычными способами, а аутсорсер приносит практику, отработанную на многих проектах.

Ресурсы на критичную аварию. Когда инфраструктура развалилась или данные зашифровали вымогатели, сильный аутсорсер может быстро пригнать на объект несколько разнопрофильных экспертов. У собственной команды такого ресурса нет и не будет. Держать людей в штате «на случай пожара» собственнику невыгодно.

Договор вместо надежды на лояльность. Штатный сотрудник решает уволиться, отработает две недели и забудет про вашу задачу, потому что трудовое законодательство на стороне человека. С подрядчиком все держится на договорных обязательствах. Срыв сроков и повторные инциденты с доказанной виной бьют по его деньгам, а не только по репутации. Разница принципиальная: не «сделал и забыл», а «отвечает, пока работает договор».

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

Не путать с аутстаффингом. Аутстаффинг — это аренда конкретных людей подрядчика, которые работают у вас как штатные. Звучит как выход, на деле вы получаете тех же двух-трех администраторов, которых могли нанять сами, только дороже. Они болеют, уходят в отпуск и ротируются между проектами, и в аварию такая «команда» может просто не собраться. Это не аутсорсинг: ответственности за результат тут не больше, чем у собственных штатных.

Экономика узких компетенций. Дорогого узкого специалиста мало нанять. Его надо обучать, покупать курсы, удерживать. Нагрузка на такие задачи гранулированная: сегодня нужно 0,3 специалиста, в следующем месяце 0,7, потом снова 0,3. Штатному платят целую ставку, а аутсорс позволяет брать ровно столько, сколько нужно. Но заменить команду — не всегда про экономию: выгода появляется там, где нагрузка действительно дробная.

Что своя команда делает лучше

Теперь честно в другую сторону. 

Рутину свои делают быстрее. Заявку «завести сотрудника, выдать ему рабочее место» через тикеты и интегратора выполняют долго, а свой специалист в момент создания задачи сидит рядом. Мелкие аварии свои устраняют почти всегда быстрее и качественнее, потому что знают, где что лежит.

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

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

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

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

Когда аутсорс точно не ваш вариант

Неудачный переход на аутсорсинг ломается о людей и стоит дороже, чем отсутствие перехода.

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

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

Экзотическое самописное ядро. Если система держится на знаниях ветеранов и старом недокументированном коде, сначала документирование и расчистка, потом уже разговор про передачу.

Слишком крупный бизнес с целой функцией. Скажу честно, как человек с этой стороны: чем крупнее компания, тем менее очевидна выгода от полной передачи целой функции. Если объем сравним с полноценным ИТ-департаментом, цена аутсорса сойдется с ценой этого департамента, и вопрос вернется к управлению, а не к экономии.

Какой сбой критичен, решает бизнес, а не ИТ-отдел

Отдельная мысль, которую я бы вынес в рамку и повесил в каждый ИТ-отдел.

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

Приоритеты и уровни сервиса выстраиваются из бизнес-потребности, а не из прайс-листа подрядчика. Хороший пример метрики: от момента, когда менеджер взял заказ, до передачи этого заказа в производство или складскую систему должно пройти не более часа. Это метрика денег, а не ИТ. Именно такие должны попадать в договор.

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

К гибриду приходят обе стороны

Компании, прошедшие обе модели, нередко приходят к одному решению. Ни «аутсорсинг», ни «инсорсинг». Гибрид, где за каждой зоной закреплено то исполнение, которое в ней сильнее.

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

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

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

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

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

Критерий здоровья простой. Хороший подрядчик на хорошем проекте просто незаметен. Если про ИТ в компании вспоминают редко, сбои закрывают по регламенту, без эскалаций к руководству, а бизнес-метрики в норме, модель работает.

Что посчитать собственнику до выбора модели ИТ

Короткий алгоритм для собственника или ИТ-директора на этом этапе.

1. Выпишите критичные процессы и посчитайте, во что обходится час их остановки. Это главный аргумент на любых переговорах, внутренних и внешних.

2. Рассчитайте полную стоимость своей команды — зарплаты, взносы, обучение, оборудование, недозагрузку админа и риск ухода ключевого сотрудника.

3. Оцените коллектив трезво. Если команда десятилетиями росла в своих процессах, а у руководства нет ресурса на перемены, возможно, честнее усилить своих точечно, чем ломать через колено.

Если после этого вы склоняетесь к аутсорсингу или гибриду, следующий шаг — правильно выбрать подрядчика. 

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

Для этого мы используем два инструмента. IT чекап — экспресс-диагностика через интервью: две встречи по полтора часа, с собственником и с ИТ-специалистом, без доступа к серверам. Обоим задают одни и те же вопросы про резервные копии, доступы, инциденты и сроки восстановления, а риски видны там, где ответы расходятся. Через 3–5 рабочих дней у собственника отчет на несколько страниц на языке бизнеса.

ИТ-аудит глубже: с полным доступом к инфраструктуре, чтением логов, проверкой резервных копий и сканированием сети. Он нужен, когда проблема уже известна и нужна ее техническая причина. Если задача не очевидна, начинают с чекапа: он показывает, нужен ли аудит и где именно.

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