Как компании попадают в зависимость от IT-подрядчиков и почему выход обходится дорого

Автор: Владимир Белозеров, заместитель коммерческого директора KODE

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

Так возникает vendor lock-in — зависимость от поставщика.

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

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

Главная проблема vendor lock-in не в том, что компания зависит от внешних технологий. Почти любой современный бизнес от них зависит. Вопрос в другом: сохраняет ли он контроль и понимает ли заранее цену выхода.

Как появляется зависимость от подрядчика

Обычно она возникает постепенно.

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

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

Сам доступ к исходному коду здесь не спасает.

Новой команде понадобятся ещё:

1. история изменений;
2. доступы к серверам, доменам и сервисам;
3. список интеграций;
4. инструкции по запуску продукта;
5. описание обмена данными;
6. правила релизов и восстановления после ошибок.

Если всего этого нет, передача проекта превращается фактически в повторное исследование системы.

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

Коробочное решение тоже может создать зависимость

CRM, ERP, облачная платформа или другой готовый сервис часто позволяют запуститься быстрее и дешевле собственной разработки.

Но со временем компания переносит туда всё больше процессов, добавляет собственные настройки и связывает систему с другими продуктами.

Переезд становится сложнее.

Стоит насторожиться, если:

1. данные можно выгрузить только частично;
2. экспорт невозможно нормально использовать вне исходной системы;
3. API не даёт доступа ко всей нужной информации;
4. настройки нельзя воспроизвести на другой платформе;
5. стоимость лицензий растёт, но отказаться от сервиса всё сложнее;
6. компания ни разу не проверяла сценарий миграции.

Поэтому при выборе платформы недостаточно сравнить стоимость лицензий.

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

По сути, стоит задавать простой вопрос: сколько эта система будет стоить нам за несколько лет вместе с потенциальным выходом из неё?

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

Как отличить нормальную зависимость от опасной

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

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

Для этого компания должна контролировать критичные активы:

1. код и историю изменений;
2. домены и серверные аккаунты;
3. облачные сервисы;
4. данные;
5. резервные копии;
6. документацию.

Причём формального наличия документов недостаточно.

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

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

Большой продукт невозможно передать за день — и это нормально.

Проблема начинается, когда компания вообще не может заранее оценить срок, стоимость и риски такого перехода.

Как проверить, не попал ли бизнес в vendor lock-in

Полезно ответить на несколько вопросов:

1. Код, домены и критичные серверные аккаунты принадлежат компании?
2. Есть ли у сотрудников собственные доступы вместо одного общего аккаунта?
3. Сможет ли новая команда запустить продукт по документации?
4. Понятно ли описана архитектура?
5. Есть ли полный список внешних сервисов и интеграций?
6. Можно ли полностью выгрузить данные вместе с важными связями?
7. Проверяли ли эту выгрузку на практике?
8. Работает ли восстановление из резервной копии?
9. Зафиксирован ли в договоре порядок передачи проекта?
10. Сможет ли бизнес продолжить основные операции, если поставщик внезапно перестанет отвечать?

Несколько ответов «нет» ещё не означают, что подрядчика нужно срочно менять.

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

Как проверить переносимость данных

Фразы «есть экспорт» недостаточно.

Стоит попросить реальную выгрузку и посмотреть, что именно в ней сохраняется:

1. основные сущности;
2. документы;
3. история изменений;
4. даты;
5. связи между клиентами, заказами и платежами.

Лучший тест — открыть данные отдельно от исходной системы и попробовать использовать их без помощи поставщика.

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

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

Ещё до начала проекта полезно договориться:

1. кому принадлежат код, дизайн и документация;
2. на кого оформляются критичные аккаунты;
3. как создаются и проверяются резервные копии;
4. какую документацию подрядчик обязан поддерживать;
5. какие материалы он передаёт при завершении работы;
6. сколько времени занимает передача;
7. кто консультирует новую команду;
8. сколько стоит дополнительная помощь при миграции.

Юридические формулировки проверяет юрист, но техническая команда тоже должна участвовать: именно она может определить, хватит ли перечисленных материалов, чтобы действительно продолжить работу.

Контроль нужно сохранять на протяжении всего проекта

Плохая стратегия — вспомнить о передаче знаний в последнюю неделю сотрудничества.

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

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

Такой тест быстро показывает, где знания существуют только «в головах».

Что делать, если зависимость уже есть

Первое желание часто — переписать продукт или срочно сменить платформу.

Это не всегда нужно.

Сначала важно понять, что именно создаёт lock-in:

1. данные;
2. доступы;
3. инфраструктура;
4. сложные настройки;
5. договор;
6. знания конкретных специалистов.

После этого можно двигаться поэтапно.

1. Провести инвентаризацию

Собрать список кода, аккаунтов, серверов, данных, лицензий, интеграций и ответственных.

2. Вернуть критичные активы под контроль компании

Перенести код, домены и облачные сервисы в корпоративные аккаунты, настроить резервные доступы.

3. Сделать независимую копию данных

Выгрузить информацию в понятном формате и проверить восстановление.

4. Не переезжать всё сразу

Сначала переносить менее критичные функции и на них проверять процесс миграции.

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

5. Отключать старое решение только после проверки

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

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

Зачем бизнесу вообще бороться с vendor lock-in

Цель не в полной технологической независимости.

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

Задача другая — сохранить возможность выбирать.

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

Но главное — меняется переговорная позиция.

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

Поэтому лучший способ бороться с vendor lock-in — не искать полностью независимые технологии, а ещё на входе понимать, как будет выглядеть выход.