KODE 
Тендеры и лиды
Информация
Vendor lock-in — это ситуация, когда компания не может быстро и безопасно сменить IT-подрядчика или платформу. Переход становится слишком дорогим, долгим или рискованным. Чтобы этого избежать, бизнес должен сам владеть кодом, данными и всеми важными аккаунтами, регулярно обновлять документацию и заранее прописать в договоре, как будет проходить передача проекта другой команде.
Автор: Владимир Белозеров, заместитель коммерческого директора KODE.
Vendor lock-in переводится как «привязка к поставщику». Компания попадает в такую зависимость, когда продукт работает, но управлять им без нынешнего подрядчика или платформы почти невозможно.
Например, бизнес решил сменить разработчика. Код ему передали, но запустить продукт новая команда не может: нет паролей от серверов, инструкции устарели, а важные настройки знает только прежний подрядчик. Другой пример: компания использует готовую CRM, но не может полностью выгрузить клиентскую базу вместе с историей заказов и связями между данными.
Сам факт работы с внешней командой или готовым сервисом не означает опасную зависимость. Проблема начинается, если компания:
не контролирует код и важные аккаунты;
не может получить все свои данные в понятном виде;
не знает, как устроен продукт;
не может подключить другую команду без помощи прежнего подрядчика;
вынуждена соглашаться на любые цены и условия, потому что сменить поставщика слишком сложно.
Такая зависимость влияет не только на IT. Она может замедлить запуск новых услуг, увеличить расходы и создать риск остановки важных процессов.
Обычно это происходит постепенно. На старте подрядчик помогает быстро собрать команду, запустить продукт и взять на себя технические задачи. Такой подход нормален. Риск появляется, когда вместе с работой компания незаметно передаёт подрядчику весь контроль.
Например, подрядчик создаёт хранилище кода в своём аккаунте, оформляет облачный сервис на себя и не описывает важные решения. Сначала это кажется мелочью: команда рядом и быстро отвечает на вопросы. Через несколько лет выясняется, что только её сотрудники знают, как выпускать обновления, где лежат резервные копии и почему некоторые части системы работают именно так.
Один доступ к коду проблему не решает. Новой команде также нужны:
история изменений;
список внешних сервисов;
доступы к серверам, доменам и рабочим аккаунтам;
понятная инструкция по запуску продукта;
описание обмена данными с другими системами;
правила выпуска обновлений и исправления ошибок.
Если этих материалов нет, передача проекта может затянуться.
Готовая CRM, ERP или другая система помогает запуститься быстрее. В ней уже есть основные функции, поддержка и понятная цена на старте. Но со временем бизнес добавляет свои настройки, подключает другие сервисы и переносит внутрь всё больше рабочих процессов.
Зависимость появляется, если:
данные можно выгрузить только частично;
выгрузка открывается только в той же системе;
не все данные доступны через API (способ обмена между программами);
важные настройки нельзя повторить на другой платформе;
стоимость лицензий растёт, а отказаться от них сложно;
компания ни разу не проверяла, как будет проходить переезд.
При выборе системы важно считать не только цену лицензии. В расходы также входят внедрение, настройка, обучение сотрудников, поддержка, серверы, обновления и возможный переезд. Общую сумму этих расходов часто называют TCO, или полной стоимостью владения. Но в самой статье проще задавать прямой вопрос: сколько система будет стоить компании за несколько лет, включая отказ от неё.
Возможность сменить сервис становится важной и для законодателей. Например, европейский Data Act действует с 12 сентября 2025 года и содержит правила, которые должны упростить переход между сервисами обработки данных. Для российских компаний этот закон обычно не является прямым требованием, но он показывает общий подход рынка: бизнесу должно быть проще забрать свои данные и сменить поставщика.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13709 тендеров
проведено за восемь лет работы нашего сайта.
Нормальная работа с поставщиком не означает, что компания обязана самостоятельно выполнять все технические задачи. Главный критерий — бизнес сохраняет контроль над продуктом и при необходимости может передать его другой команде.
Компания должна иметь доступ ко всему исходному коду и истории изменений. Серверы, домены и другие критичные аккаунты оформляются на заказчика, а данные можно полностью выгрузить и открыть в пригодном для использования формате.
Документация должна быть понятной и регулярно обновляться. В ней фиксируют устройство продукта, порядок развертывания и связи с внешними системами. Если важные знания остаются только у сотрудников подрядчика, а о некоторых интеграциях заказчик узнаёт после сбоя, возникает опасная зависимость.
Порядок передачи проекта лучше согласовать ещё в договоре: определить, какие материалы обязан передать поставщик, в какие сроки и в каком состоянии. Тогда при смене команды новый подрядчик сможет принять продукт по плану и продолжить его поддержку.
Признаки vendor lock-in появляются, когда часть кода находится только у исполнителя, критичными аккаунтами владеет поставщик, данные нельзя полностью выгрузить, документация устарела, а условия передачи проекта сформулированы неясно. В такой ситуации смена команды превращается в дорогостоящий и непредсказуемый процесс.
Большой продукт нельзя передать за один день, и это нормально. Главный вопрос в другом: может ли бизнес заранее оценить сроки и стоимость перехода, получить все нужные материалы и провести передачу без искусственных препятствий.
Ответьте на десять вопросов:
Все хранилища кода, домены и серверные аккаунты принадлежат компании?
У сотрудников есть личные доступы вместо одного общего пароля?
Может ли новая команда запустить продукт по инструкции?
Описано ли простыми словами, как устроена система?
Есть ли список всех подключённых сервисов и ответственных за них?
Можно ли полностью выгрузить данные без потери важных связей?
Проверяла ли команда, что выгрузку можно открыть и использовать?
Делает ли компания резервные копии и проверяет ли их восстановление?
Указано ли в договоре, что подрядчик передаёт после завершения работы?
Сможет ли бизнес продолжить основные операции, если поставщик внезапно перестанет отвечать?
Несколько ответов «нет» — это повод провести проверку. Важно изучить не только качество кода, но и доступы, данные, инструкции, безопасность и порядок работы команды.
Не верьте одной фразе «экспорт данных доступен». Попросите поставщика показать настоящую выгрузку. Проверьте, сохраняются ли в ней названия, даты, документы, история действий и связи между клиентами, заказами и платежами.
Лучший тест — попробовать открыть выгрузку отдельно от исходной системы. Если данные нельзя понять без помощи поставщика, полноценного выхода пока нет.
До начала работ согласуйте:
кому принадлежат код, дизайн и документы;
какие аккаунты должны быть оформлены на компанию;
как часто создаются резервные копии;
какие инструкции обязан поддерживать подрядчик;
что именно он передаёт при завершении работы;
сколько длится передача проекта новой команде;
кто отвечает на вопросы во время перехода;
сколько стоит дополнительная помощь при переезде.
Юридическую часть договора должен проверить юрист. Техническая команда должна убедиться, что перечисленных материалов действительно хватит для продолжения работы.
Не откладывайте передачу знаний до последнего дня. Компания должна с самого начала владеть основными аккаунтами, видеть ход работ и получать обновлённые инструкции вместе с каждым крупным изменением.
Полезно раз в несколько месяцев проводить простой тест: сможет ли специалист, который раньше не работал с продуктом, понять его устройство и запустить тестовую версию по документам. Такой тест быстрее показывает пробелы, чем формальная проверка количества файлов.
Не начинайте сразу переписывать всю систему. Сначала разберитесь, что именно удерживает компанию: данные, доступы, сложные настройки, договор или знания отдельных людей.
Безопасный план состоит из пяти шагов:
Проверьте текущую ситуацию. Соберите список кода, данных, серверов, лицензий, подключённых сервисов и ответственных сотрудников.
Верните важные аккаунты под контроль компании. Перенесите код, домены и облачные сервисы в корпоративные аккаунты. Настройте резервный доступ.
Сохраните данные отдельно. Сделайте полную копию в понятном формате и проверьте, что её можно восстановить.
Переезжайте по частям. Сначала переносите менее рискованные функции, сравнивайте результаты и только затем переходите к важным процессам.
Отключите старую систему после проверки. Убедитесь, что сотрудники обучены, данные совпадают, а на случай ошибки есть план возврата.
Срок перехода зависит от размера продукта, количества подключённых сервисов, состояния данных и качества инструкций. Поэтому нельзя обещать одинаковый срок всем компаниям.
Цель не в том, чтобы просто заменить одного подрядчика другим. Компания должна вернуть себе возможность выбирать и принимать решения.
После успешной передачи или переезда бизнес получает:
контроль над кодом, данными и аккаунтами;
понятную схему работы продукта;
возможность подключить другую команду;
более точную оценку сроков и стоимости изменений;
меньше риска, что важный процесс остановится из-за одного поставщика;
возможность выбирать сервис по цене и качеству, а не из страха сложного перехода.
