Когда и почему крупным компаниям удобнее работать с аутсорсерами

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

Направление, которым я руковожу в К2Тех, занимается аутсорсингом сервисов в ИТ, так что мои примеры будут скорее из этой области, включая 15-летнюю историю развития отношений с одним из наших заказчиков. Но всё то же самое верно об аутсорсе любых других функций, практически без поправок.

От инсорса к аутсорсу: зачем?

Причины переходить от штатной команды (инсорса) к аутсорсу те же, что и при переводе инфраструктуры в облако. Только вместо вычислительных ресурсов — «трудовые массы».

Давайте освежим в памяти эти причины.

Доступ к лучшим экспертам без сверхрасходов. Отдельные эксперты — архитекторы, аналитики, безопасники, отраслевые эксперты, эксперты по регуляторике, – в проекте нужны только на несколько десятков часов, но при этом они очень дороги. И для многих компаний нет другой возможности получить к ним доступ иначе как через аутсорсинг по fractional-модели (или, говоря по-русски, на парт-тайме).

С уходом глобальных вендоров из России эта тенденция только усилилась. На рынке всё ещё преобладают специалисты, обученные работать с решениями ушедших вендоров. Поэтому когда вам надо перейти, например, с Oracle на PostgreSQL, ваш доступный рынок экспертов оказывается довольно узким. Переобучение на импортозамещающие технологии происходит медленно, на рынке — дефицит кадров, стоимость найма растёт. В итоге компаниям легче заплатить за аутсорс. А поиском и удержанием хороших кадров занимаются уже сами аутсорсинговые компании, которые готовы загрузить их работой на 100%. 

Быстрое масштабирование. Если у вас временный проект, то расширенная команда вам нужна только на период нескольких месяцев интенсивной работы. Например, после импортозамещения ОС на Astra Linux одному из наших клиентов понадобилось срочно расширить техподдержку внутренних пользователей, которым нужно было переучиться пользоваться новой ОС. При этом уже через несколько месяцев пик обращений спал, людей в поддержке нужно было уже меньше. Стандартный цикл найма сотрудников не позволяет так быстро нанимать и увольнять. Привлечение же аутсорсера позволяет срочно привлечь дополнительные руки и высвободить их, когда задача решена.

Передача аутсорсеру рисков непредвиденных кадровых расходов. Расходы, которые компании несут на сотрудников помимо зарплаты, это:

• Больничные, отпуска, выплаты при увольнении.

• Оплата повышения квалификации.

• Необходимость постоянно повышать зарплату. Зарплаты на ИТ-рынке продолжают расти, оклады штатных сотрудников приходится индексировать. С аутсорсером же компании заключают контракт на фиксированный период, и сумма выплат остаётся той же, независимо от инфляции.

Доступ к ресурсам аутсорсера. У аутсорсеров бывает налажено множество партнёрств, к которым клиент может быстро получить доступ. Некоторые из них:

• проверенные профильные сторонние эксперты и организации;

• смежные сервисы (собственная инфраструктура аутсорсера, приложения, платформы);

• поставщики и реселлеры (например, для получения скидок на компоненты, лицензии).

Почему компании отдают аутсорсеру целые команды

Когда крупные компании передают на аутсорс эксплуатацию какого-нибудь приложения, нередко из инсорса в аутсорсинг переходит и сопровождающая приложение команда. Такая практика не для всех выглядит привычно. Вроде как компании должны держаться за своих сотрудников, которых было так дорого нанять. В чём смысл?

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

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

В итоге математика этой истории такова, что с учётом агентского оверхеда в пользу аутсорсера это всё равно оказывается выгодно заказчику: на горизонте 1-2 лет расходы отбиваются.

Почему компании избегают перехода на аутсорс

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

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

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

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

В последние годы нормой стала проверка членов команды аутсорсера службой ИБ самого клиента (это помимо того, что ИБ аутсорсера тоже их проверяет).

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

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

• банки (требования регулятора, ПДн);

• производственные и энергетические предприятия (тайна производства, КИ);

• транспорт (ПДн, ГИС);

• электронная медицина (ПДн, в том числе медицинские данные);

• государственные предприятия и корпорации (ПДн, требования регулятора).

Как строятся отношения аутсорсера с заказчиком. Кейс с 15-летним стажем

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

Начало и формирование доверия. Обычно всё начинается с одного проекта, это аналог испытательного срока. Если за это время между двумя командами складывается доверие, заказчик продолжает работать с аутсорсером. 

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

Расширение. Если первый проект прошел гладко, доверие заказчика растет и он готов расширить перечень работ на аутсорсе. Работает «внутренний сарафан» (передача информации между разными отделами внутри организации). И, конечно, никто не заключает контракты на 15 лет, но они могут постоянно продлеваться и расширяться. Такой 15-летний симбиоз у нас случился с одной из крупных FMCG-компанией. Он начинался с поддержки одного бизнес-приложения для торговых представителей. По результатам заказчик захотел передать нам на аутсорс уже 10 сервисных линий, включая основную часть  инфраструктуры. Причина: после первого пробного проекта заказчик увидел, как аутсорсинг позволяет ему гибко управлять сервисом, повышать уровень SLA, расширять бизнес и при этом не ломать голову, где брать персонал, дополнительные места для сотрудников и так далее.

В итоге за 15 лет нам на поддержку переданы:

• сервисные линии

• инфраструктура

• миграция и поддержка бизнес-приложений

• проекты по импортозамещению

• переезд между облаками

• производственные системы

• корпоративные системы, CRM

Долгосрочные отношения. Если горизонт планирования аутсорсингового проекта — всего 1−2 года, то подрядчик успевает только «потушить пожары» и внедрить базовые изменения. Весь первый год уходит на то, чтобы разобраться в инфраструктуре, процессах.

При более длительных отношениях у аутсорсера появляется гораздо больше возможностей:

• Проактивность. Устранение проблем до их появления снижает объём работ для аутсорсера и стоимость поддержки для клиента. В этом ключе, к примеру, мы заранее обновили APNS-сертификат и спасли 500 пользователей от отключения почты.

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

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

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

• Прозрачность и предсказуемость процессов. Меньше бюрократии. Можно выполнять работы сразу и не ждать по 3 месяца, пока согласуют бюджеты. Растёт предсказуемость запусков.

Например, в 2024 году мы за три недели перезапустили сервис Helpdesk, который приняли от предыдущего подрядчика. Нам было легко гарантировать быстрое развёртывание сервиса: мы хорошо знали внутренние процессы, инфраструктуру, стек, ключевых людей в команде заказчика. И мы пришли к целевым показателем по SLA и KPI за 3 недели (в среднем такие проекты занимают от 3 месяцев).

Итогом длительных отношений между подрядчиком и заказчиком становится снижение числа инцидентов и проблем, стабилизация сегментов сервиса, увеличение прозрачности и управляемости процессов и инфраструктуры. Если привести общий знаменатель для нашей 15-летней истории в виде одного числа, то пусть это будет число инцидентов в месяц: 7-8 тысяч в 2017 году → 3-3.5 тысячи в 2024.

Какие детали важно учесть при выборе аутсорсера 

• Свяжитесь с клиентами аутсорсера, которого вы рассматриваете. Узнайте, как строилось взаимодействие с ним на самом деле. 

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

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

• Если в вашей организации есть специальные требования ИБ, убедитесь, что аутсорсер обладает всеми сертификациями, нужными для выполнения работ.

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