Уход западных вендоров заставил компании и госорганы быстро искать замену. Спешка породила обратный риск: вместо одного зарубежного поставщика организация привязывается к одному отечественному – иногда жёстче, чем раньше. Российский рынок узкий, альтернатив по ряду классов ПО мало, а давление сроков подталкивает брать «всё от одного». Через два-три года это оборачивается ценником на сопровождение, который невозможно оспорить, и невозможностью сменить подрядчика без полной переделки.

Где зависимость возникает незаметно

Lock-in редко прописан в договоре прямым текстом. Он накапливается в технических решениях, которые принимают на ходу.

  • Проприетарные форматы и протоколы. Данные лежат в хранилище, которое читает только инструментарий вендора. Выгрузка есть, но без схемы и метаданных она бесполезна.
  • Закрытые расширения поверх открытого ядра. Вендор берёт PostgreSQL или Linux, добавляет собственные модули и привязка переезжает на уровень этих модулей.
  • Эксклюзивная экспертиза. Систему умеет настраивать только команда поставщика. Своих специалистов нет, на рынке их тоже не найти.
  • Сцепленный стек. СУБД, BI, ETL и прикладной слой куплены пакетом и работают только вместе. Заменить один компонент нельзя.

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

Как сохранить контроль

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

Опирайтесь на открытые стандарты на стыках систем. Если данные хранятся в PostgreSQL без проприетарных надстроек, а обмен идёт через документированные API и стандартные форматы, замена прикладного слоя перестаёт быть катастрофой. То же касается аналитики: храните сырьё и витрины в открытом формате, отделённом от конкретного BI-инструмента, – тогда миграция хранилища данных не упирается в одного поставщика.

Разделяйте критичные классы ПО между разными вендорами. Не отдавайте СУБД, инфраструктуру и прикладные системы в одни руки. Конкуренция за ваш бюджет работает только тогда, когда у поставщика есть реальная альтернатива.

Закрепляйте право на выход в контракте. Требуйте передачи исходного кода доработок, полной документации, экспорта данных со схемой и обучения вашей команды. Фиксируйте потолок роста цены на сопровождение. Эти пункты обсуждаются на входе – после внедрения переговорная позиция уже потеряна.

Развивайте внутреннюю экспертизу. Хотя бы один инженер заказчика должен понимать архитектуру системы глубже, чем на уровне пользователя. Это касается и инфраструктуры, и выбора отечественной LLM – модели и платформы тоже создают привязку через форматы весов и API.

Когда уход уже зашит в систему

Если зависимость уже сложилась, выход возможен, но требует плана. Сначала инвентаризация: какие данные, форматы и интеграции завязаны на вендора. Затем – развязка по слоям: сперва выносят данные в открытое хранилище, потом меняют прикладные компоненты. Резкий «переезд всего сразу» проваливается чаще, чем поэтапный. Надёжнее развязывать привязки по слоям: от аудита зависимостей до перевода на архитектуру, где смена любого компонента не останавливает бизнес.

Вывод

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