Ключевые ошибки ИТ-аутсорсинга: подробный разбор и как их избежать

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

Ошибки на этапе принятия решения

Самые дорогие ошибки совершаются до того, как подрядчик вообще появился. Решение принимается под давлением бюджета, а последствия бизнес видит через год.

Экономия как единственная цель

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

Передача критичных компетенций без контроля

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

Нет расчёта полной стоимости владения

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

Всё и сразу, без пилота

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

Ошибки при выборе подрядчика

Ошибки при выборе ИТ-подрядчика чаще всего сводятся к одному: компания оценивает коммерческое предложение и не проверяет, способен ли подрядчик его исполнить.

Выбор по минимальной цене

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

Кейсы не проверены

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

Ресурсная ёмкость не оценена

Небольшой провайдер может честно выполнять договор, пока у него не появится второй крупный клиент. Тогда ваши заявки встанут в очередь. Уточняйте численность инженеров по направлениям, наличие второй и третьей линии, географию выездов. Для сети с площадками в Москве и регионах важно, кто именно приедет в филиал, в какой срок и как подрядчик подключает новые точки.

Как проверять подрядчика

Перед подписанием договора стоит пройти по короткому списку:

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

Ошибки в договоре и SLA

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

Нет технического задания на сервис

Договор часто подписывают с приложением на одну страницу: «поддержка ИТ-инфраструктуры заказчика». Что именно входит в периметр, сколько рабочих мест, серверов и площадок, какие сервисы критичны, в какие часы нужна поддержка и какие каналы обращений допустимы, остаётся в устных договорённостях. Через полгода стороны по-разному помнят, о чём договаривались. Техническое задание на сервис составляется по результатам ИТ-аудита: перечень объектов обслуживания, состав работ по каждому, режим поддержки, требования к отчётности и безопасности. По нему сравниваются предложения подрядчиков, и оно же становится приложением к договору.

Размытый SLA

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

Доступность критичных сервисов обычно составляет 99,9%. Это до 8,8 часа простоя в год, и эту норму нужно понимать до подписания.

Ещё один пример из практики. Inventive Retail Group, 481 магазин в 35 городах: первая и вторая линии поддержки работали как отдельные службы, SLA не было, у магазинов было несколько точек контакта, а требования к качеству по сети не были формализованы. Решением стал единый центр поддержки пользователей и рабочих мест с регламентами по срокам и качеству и одним ответственным за каждый запрос. Скорость решения инцидентов выросла, бюджет на поддержку снизился.

Нет штрафов и эскалации

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

Нет условий выхода

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

Неясные границы ответственности

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

Нет NDA и требований к защите данных

Подрядчик получает доступ к коммерческой информации и персональным данным сотрудников и клиентов. Соглашение о конфиденциальности (NDA) и раздел о защите информации входят в договор обязательно и подписываются до выдачи первого доступа.

Ошибки в управлении отношениями

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

«Отдали и забыли»

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

Нет регулярной отчётности и встреч

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

Коммуникация через одного человека

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

Микроменеджмент вместо управления по результату

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

Подрядчик как внешний враг

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

Ошибки, связанные с безопасностью и данными

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

Избыточные права доступа

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

Нет аудита действий подрядчика

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

Неотозванные доступы

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

Нарушение 152-ФЗ

Если подрядчик получает доступ к персональным данным, компания остаётся оператором и по закону отвечает за его действия перед субъектами. Передача возможна только по поручению: в договоре должны быть перечень данных, перечень операций с ними, цели обработки, обязанность соблюдать конфиденциальность и требования к защите по статье 19 закона. С 30 мая 2025 года цена ошибки выросла: штраф за первую утечку для организации — от 3 до 15 млн рублей в зависимости от числа пострадавших, за повторную — от 1 до 3% годовой выручки, но не менее 20 и не более 500 млн рублей. Уведомить Роскомнадзор об инциденте нужно в течение 24 часов, а результаты расследования передать в течение 72 часов. Это обязанность оператора, поэтому подрядчик должен сообщать ему о любых инцидентах немедленно — такое условие должно быть в договоре. Если своей службы для этой работы нет, защиту персональных данных тоже можно передать на сопровождение, но ответственность оператора при этом остаётся за компанией.

Ошибки в документации и передаче знаний

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

Vendor lock-in: знания остаются у подрядчика

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

Нет актуальной документации

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

Нет обязательства вести документацию

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

Финансовые ошибки

Скрытые расходы ИТ-аутсорсинга редко связаны с обманом. Чаще заказчик просто не учёл статьи, которые проявляются со временем.

Работы вне периметра договора

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

Неправильная модель оплаты

Модель оплаты выбирают под характер работ, и ошибка здесь стоит дорого в обе стороны:

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

Двойные расходы в переходный период

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

Как понять, что аутсорсинг пошёл не по плану: тревожные признаки

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

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

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

Как избежать ошибок: практический алгоритм

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

1. Провести ИТ-аудит и зафиксировать цели перехода. Нужна инвентаризация инфраструктуры, список сервисов с их критичностью и понятный ответ, зачем компании аутсорсинг.
2. Определить KPI и метрики успеха: доступность, время реакции и восстановления, число инцидентов, удовлетворённость пользователей. По ним будет оцениваться и подрядчик, и сам проект.
3. Провести пилот на ограниченном участке: один регион или одно направление, например Service Desk, на один-три месяца. Пилот показывает реальную работу подрядчика лучше любой презентации.
4. Зафиксировать SLA, границы ответственности, санкции, требования безопасности и exit-условия в договоре до старта основного этапа.
5. Назначить внутреннего сервис-менеджера, который владеет процессом, принимает отчёты и отвечает за отношения с исполнителем.
6. Настроить регулярный контроль: ежемесячные отчёты по SLA, ежеквартальный пересмотр периметра, условий и документации, регулярная ревизия выданных доступов.

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

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