Как компании «подсаживаются» на IT-подрядчиков и коробочные решения — и почему выйти из этого почти всегда дороже, чем войти

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

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

Что такое vendor lock-in простыми словами

Vendor lock-in переводится как «привязка к поставщику». Компания попадает в такую зависимость, когда продукт работает, но управлять им без нынешнего подрядчика или платформы почти невозможно.

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

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

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

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

Почему компания становится зависимой от IT-подрядчика

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

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

Один доступ к коду проблему не решает. Новой команде также нужны:

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

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

Как готовая платформа может ограничить бизнес

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

Зависимость появляется, если:

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

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

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

Чем обычная работа с поставщиком отличается от опасной зависимости

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

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

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

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

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

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

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

Ответьте на десять вопросов:

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

Несколько ответов «нет» — это повод провести проверку. Важно изучить не только качество кода, но и доступы, данные, инструкции, безопасность и порядок работы команды. О том, как проходит такая проверка, читайте в материале об аудите IT-проекта.

Как избежать vendor lock-in до начала проекта

Как проверить, можно ли забрать данные

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

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

Что нужно записать в договоре

До начала работ согласуйте:

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

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

Как сохранить контроль во время разработки

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

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

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

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

Безопасный план состоит из пяти шагов:

1. Проверьте текущую ситуацию. Соберите список кода, данных, серверов, лицензий, подключённых сервисов и ответственных сотрудников.
2. Верните важные аккаунты под контроль компании. Перенесите код, домены и облачные сервисы в корпоративные аккаунты. Настройте резервный доступ.
3. Сохраните данные отдельно. Сделайте полную копию в понятном формате и проверьте, что её можно восстановить.
4. Переезжайте по частям. Сначала переносите менее рискованные функции, сравнивайте результаты и только затем переходите к важным процессам.
5. Отключите старую систему после проверки. Убедитесь, что сотрудники обучены, данные совпадают, а на случай ошибки есть план возврата.

Так же проходит обновление старого кода без остановки разработки: команда меняет систему постепенно, пока бизнес продолжает работать.

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

Что получает бизнес после выхода из зависимости

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

После успешной передачи или переезда бизнес получает:

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

Часто задаваемые вопросы

Что такое vendor lock-in?

Это зависимость от подрядчика или платформы, из-за которой смена поставщика становится слишком сложной, дорогой или рискованной. Частые причины — отсутствие доступов, неполная выгрузка данных и нехватка инструкций.

Как понять, что компания зависит от IT-подрядчика?

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

Почему одного кода недостаточно?

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

Сколько времени занимает смена подрядчика или платформы?

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

Что делать, если все доступы находятся у подрядчика?

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

Как не зависеть от облачного сервиса?

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

Нужно ли переписывать всю систему с нуля?

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