Продление договора — через три месяца, но поставщик знает уже сейчас, что вы никуда не уйдете. Это и есть vendor lock-in — зависимость от вендора. С ней сталкиваются гораздо чаще, чем принято думать.
Конечно, ITAM-специалисты могут заранее заметить надвигающуюся проблему: у них на руках данные по активам и договорам с поставщиками, статистика использования и календарь продлений. Проблема в том, что зависимость от вендора изначально чаще всего не воспринимается как риск — до того момента, когда уже поздно что-либо менять. Когда риск стал очевиден, простая процедура закупки ПО на замену текущему превращается в крупный проект, который требует отдельного бюджета, ресурсов и многоэтапного плана миграции.
Это руководство поможет выявить, разложить по полочкам и взять под контроль зависимость от вендора — до того, как она начнет управлять вашим бюджетом.
Vendor lock-in — что это такое?
Зависимость от вендора возникает, когда смена поставщика перестает быть просто вопросом закупки, заставляя принять потерю данных и функциональностей, тратить много денег на уход или же выстраивать заново системы и процессы.
Задумайтесь, как может быть сложно сменить мобильного оператора, если нельзя взять с собой фотографии, купленные приложения и историю сообщений. Такие трудности способны остановить любого. Теперь представьте похожие препятствия, только в IT уровня enterprise — и в разы масштабнее.
Есть два основных типа lock-in:
Обратимый lock-in
Уйти можно — если распланировать процесс. Данные выгружаются в удобном формате, с историей действий и журналом аудита. Интеграции можно настроить заново, никаких сверхусилий. Штрафов по договору нет, придется потратить только время на работу — обычно речь о нескольких месяцах.
Жесткий lock-in
В этом случае вас фактически вынуждают остаться. Полная выгрузка данных отсутствует, стоит безумных денег или длится целую вечность. Договор делает уход коммерчески невыгодным, а продукт внедрен так глубоко, что его замена грозит рисками для бизнеса. Смена поставщика может длиться годами.
Почти у всех компаний есть оба типа зависимостей, но понять, к какой именно категории относится вендор, зачастую можно только при обсуждении продления договора. Это уже ITAM следующего уровня: вы выходите за рамки комплаенса и анализа расходов, начинаете смотреть на вендора в контексте всего предприятия.
Простая проверка: если не можете описать на одной странице, как уйти от поставщика, что при этом потеряете, какими будут финансовые расходы и сколько времени это займет — информации для уверенных переговоров у вас явно недостаточно.
Как возникает lock-in — умышленно, случайно или по согласию
Не всегда lock-in — это ловушка поставщика. Понимание того, по чьей вине возникла зависимость, определяет оптимальную тактику.
Умышленный lock-in — коммерческая стратегия
Вендоры упаковывают продукты в бандлы: отказ от одной составляющей пакета рушит скидки на все остальные. В итоге вы переплачиваете за ПО, которым не пользуетесь, ради сохранения «выгодной» цены на то, без чего не можете жить.
Пример: после слияния Broadcom и VMware клиентов массово перевели на более широкие и дорогие пакеты продуктов, почти без возможности переговоров. Или: расследование Еврокомиссии по поводу включения Teams в состав Office 365 вынудило Microsoft «вынуть» мессенджер из пакетного предложения. Все это не случайности, а целенаправленная политика.
Непреднамеренный lock-in — ответственность самих компаний
Покупаете ITSM-платформу, обвешиваете её сотней интеграций, кастомных процессов, согласований… Никто не планировал попадать в зависимость — она росла постепенно, с каждым решением, принятым во имя удобства. И вот уже уход — не просто смена инструмента, а перестройка рабочего уклада всей команды.
Взаимовыгодный lock-in — осознанная сделка
Вы выбираете одного провайдера идентификации или одну платформу для совместной работы, потому что управлять пятью разными инструментами одного типа более рискованно и трудозатратно, чем одним. Решение принять зависимость от одного продукта имеет право на жизнь — если обдумать его как следует, задокументировать и защитить себя на уровне договора.
Ключевой вопрос: кто создал зависимость? Если дело в бандлах, договоре и использовании доступа к программе как рычага давления — это вендор. Когда проблема в кастомных процессах, интеграциях или хаотичных данных — перед вами ваших же рук дело. Если же речь о стратегии с понятной ценностью — это уже осознанный выбор. Ответ подскажет, что с этим делать.
Пять оттенков lock-in
Обычно разговоры о lock-in сводятся к условиям договора. На деле же зависимость более комплексное явление. Есть минимум пять видов lock-in — и чтобы понять, как вам действовать, сначала нужно разобраться, с каким из них вы имеете дело.
1. Технический lock-in
Работа вашей инфраструктуры основана на технологиях конкретного вендора. Скрипты, интеграции, автоматизации завязаны на его API и инструментах. Новая система может совпадать по верхнеуровневому функционалу — но чтобы процессы работали «как раньше», потребуется доработка. Регуляторы в Великобритании отметили в своем исследовании рынка облачных сервисов, что несовместимость форматов данных, проприетарные утилиты и сложности мигрирования рабочих процессов — это основные препятствия к смене провайдера.
2. Lock-in на уровне данных.
Данные можно экспортировать, но нельзя взять с собой в пригодном для использования состоянии. Записи выводятся в виде «плоского» текстового файла. История изменений, журнал аудита, согласования, прикрепленные документы и взаимосвязи между объектами остаются за бортом. То, что удастся затащить в другую систему, уже не имеет большой практической пользы.
3. Коммерческий lock-in
Даже если саму технологию можно заменить, условия договора делают уход слишком дорогим. Например, многолетние обязывающие соглашения, автопродления, бандлы со скидками, которые превращаются в тыкву при изменении состава пакета. После покупки VMware компанией Broadcom европейские клиенты столкнулись с ростом цен в 8-15 раз, реструктуризацией существующих договоров и практически безальтернативным навязыванием трехлетних контрактов. Аудиты ПО также используются как сдерживающий фактор для смены вендора: они ставят вас в трудоемкую оборонительную позицию вместо изучения альтернативных вариантов.
Сложность параметров лицензирования также может быть формой lock-in. Лицензионные аудиты, безлимитные лицензионные соглашения (ULA), процессорное лицензирование, определения именованных пользователей, которые постоянно меняются, — все это не просто так. Когда нет уверенности в собственной позиции, не получится вести переговоры или заменить поставщика. Подавляющее большинство остается с нелюбимым вендором, потому что уход спровоцирует выяснение того, сколько они ему должны.
4. Операционный lock-in
Ваши команды и процессы были сформированы вокруг вендора. Переход означает переобучение персонала, переписывание инструкций и перестройку всей ежедневной работы. Программное обеспечение можно заменить достаточно легко, а вот организационные изменения — непростая задача. Так, официальные власти Мюнхена потратили пятнадцать лет на миграцию 15 000 компьютеров с Microsoft на кастомную версию Ubuntu, прежде это отменить это решение в 2017 году. Ориентировочная стоимость обратного переезда — 100 миллионов евро. Отчет Accenture выявил, что основные проблемы были организационными, а не техническими.
5. Lock-in на уровне управления и комплаенса
Ваши внутренние политики, процессы аудита и контроля построены вокруг экосистемы вендора. Процедуры контроля утверждены, логи используются как доказательства, служба безопасности одобрила поставщика. Смена ПО = повторять всё с нуля. Судебная тяжба Oracle и Rimini Street, тянувшаяся 15 лет до урегулирования в июле 2025 года, крутилась именно вокруг условий — оказывалась ли внешняя поддержка с соблюдением положений лицензионных соглашений Oracle. Если не документировать должным образом свои лицензионные права, доказать комплаенс практически невозможно.
На практике lock-in — почти всегда гибридный кейс, но один из видов зависимости обычно ведущий. Определите его — и получите более четкое понимание, какую проблему нужно решить в первую очередь.
Шестой тип зависимости: lock-in в эру AI и современных SaaS
Искусственный интеллект создает новый формат lock-in, который пока почти не контролирует большинство ITAM-команд, и развивается этот паттерн с пугающей быстротой.
Теперь зависимость связана не с лицензиями на ПО, а тем, что создает ваша команда поверх решения: библиотеки промптов, фреймворки оценки, автоматизированные рабочие процессы, выстроенные вокруг поведения и ответов конкретной модели. Все это почти никогда не документируется, практически не подлежит переносу и не принадлежит в полном смысле вашей компании.
Файн-тюнинг усугубляет ситуацию. Обучили модель на своих данных внутри среды вендора — и оставляе��е ее там. Данные, может, и унесете, а вот производительность — нет.
Есть ещё обязательства перед облачными маркетплейсами. Если основной объём средств вы тратите через AWS, Azure или GCP, у вас возникают обязательства по соглашениям, выходить из которых очень сложно. Даже сменив SaaS-инструмент, вы все равно привязаны к платформе-«подложке».
Здесь возникают классические для ITAM вопросы, только под новой вывеской: что мы построили, где это живет и что мы теряем, если вендор внезапно меняет условия, цену или саму модель? Компании-«отличники» начинают задавать эти вопросы уже сейчас — до того как зависимость станет критически сильной.
Чем нам реально грозит lock-in
Lock-in проявляется постепенно: вы соглашаетесь на очередное повышение цен, потому что уход на альтернативное решение — это слишком больно, продолжаете оплачивать неиспользуемое ПО, чтобы сохранить пакетную скидку, не запускаете проекты развития, потому что на это нет бюджета.
Проблема именно в эффекте накопления: каждая новая интеграция, автоматизация процесса или удобство для команды увеличивают стоимость потенциального перехода. Компания, откладывающая решение, не снижает затраты — она лишь откладывает их и делает еще выше.
Проблема встает особенно остро при попытках сократить расходы или повысить эффективность. Инстинктивно хочется пересмотреть условия и укрепить свою позицию. Если бюджет уже «захвачен» многолетними контрактами, эти средства попросту заблокированы — и не важно, что требуется бизнесу прямо сейчас. Нет гибкости, которая так нужна в программе сокращения затрат. Режете ��о, что можете, а не то, что действительно не нужно.
Переговорная позиция уходит в минус: если вендор знает, что вы не в силах от него отказаться — нет никакого стимула снижать стоимость или идти на уступки. Переговоры о продлении становятся формальностью, а не переговорами. В результате вы годами переплачиваете за те же самые функции.
Самый явный признак, что lock-in вам дорого обходится: есть варианты быстрее, дешевле, функциональнее, но эти альтернативы проигрывают, потому что стоимость и сложность перехода слишком велики. Новых игроков на рынке, часто более гибких и адекватных по цене, даже не рассматривают из-за тяжести этой зависимости. Действующему вендору не нужно выигрывать. Ему достаточно усложнить расставание, чтобы никто даже не пытался уйти.
Как защищаться от lock-in
До заключения контракта спросите не только, как работает продукт, но и во что встанет уход. На этапе пилота протестируйте выгрузку данных: попросите вендора экспортировать часть ваших данных и проверьте, пригодны ли они для использования, а не просто доступны для скачивания. На старте отношений с вендором, во время внедрения новой многообещающей технологии вам может быть не до этого. Своего рода обсуждение брачного договора перед свадьбой: не слишком романтично, но очень дальновидно.
Если вендор выгружает только записи, но не историю, журнал аудита, согласования или связи между объектами, он не дает вам реального выхода. Требуйте зафиксировать в письменном виде, что вы можете забрать, в каком формате и в какие сроки. Не могут ответить — считайте, что это сигнал.
Во время эксплуатации lock-in растет с каждым принятым решением во имя удобства. Каждая кастомная интеграция, автоматизация процесса, разовая настройка увеличивают стоимость отказа от услуг. Конечно, поддерживать актуальный реестр зависимостей нужно обязательно: что с чем интегрируется, кто за что отвечает, что поломается при смене поставщика. ITAM как раз и предназначен для этого — но без поддержки архитекторов, закупщиков и команд разработки платформы не обойтись. Везде, где можно, выбирайте настройку — не пользовательский код. Свой код загоняет в ловушку.
При продлении lock-in монетизируется в полной мере. В этот момент вендор превращает накопленную зависимость в свою переговорную дубинку. Gartner в своем исследовании SaaS платформ пишет, что 25% лицензий попросту не используется, при этом большинство компаний знают только о 40% своих SaaS-приложений. Бесполезные траты — ваш основной козырь. При продлении составьте точный список используемых и неиспользуемых лицензий, во сколько вам обходятся невостребованные приложения и рассмотрите хотя бы одну реальную альтернативу. Вам не обязательно готовиться к уходу — главное, чтобы вендор поверил в эту угрозу.
Во время ухода хорошо справляются с трудностями те компании, которые относятся к ситуации как плановой, а не чрезвычайной. Когда Broadcom реструктурировал лицензионную политику VMware, наиболее выгодной позиции в переговорах добились клиенты, которые четко знали, что они хотят, и задокументировали свои требования: сроки выгрузки данных, непрерывность поддержки в процессе переезда, периоды параллельной работы. Совет: включите в изначальный договор условия о помощи во время миграции.
Как внутренние процессы мешают бороться с lock-in
Приведенные выше практические рекомендации просты, в отличие от организационных реалий. В большинстве случаев зависимость от ИТ-решений сохраняется не потому, что ITAM-команды не осознают проблему. Причина в том, что конкретные люди и внутренняя политика затрудняют принятие мер.
Есть четыре часто встречающихся сценария:
1. Критика лидера. Влиятельный топ, находится в близких отношениях с вендором или принимал изначальное решение о выборе платформы. Обсуждение lock-in воспринимает как персональные нападки или подрыв репутации.
2. Гордость разработчиков. Команда внедрения не хочет знать реальную цену lock-in, ведь это означает, что принятые ими решения обернулись большими расходами.
3. Нарратив страха. «Смена технологий все поломает!» превращается в вето на изменения, которое никто не хочет оспаривать
4. Коалиция комфорта. Пользователям нравится текущий инструмент, команды не хотят страдать из-за переучивания, удобнее оставить как есть.
Наиболее эффективный способ все это преодолеть — отделить факты от решения. Проведите краткий анализ зависимости, зафиксируйте полученные результаты и представьте их в виде информации о рисках, а не рекомендаций по смене поставщика.
Одностраничную выжимку с информацией об уязвимостях, сроках и стоимости расторжения договора нормально воспримут большинство стейкхолдеров — в отличие от обсуждения, которое выглядит как атака на сделанный кем-то выбор.
Корпоративная IT-экосистема дает отпор
Проблема зависимости от поставщика — не та, с которой компания остается один на один. Сейчас появляется все больше коммерческих, законодательных и рыночных механизмов, которые нужно знать и использовать.
Сторонняя поддержка
Обслуживание стабильных продуктов — ERP, СУБД, промежуточного программного обеспечения — можно купить у третьих лиц, не у вендора. Это не столько про экономию, сколько про устранение давления «обновляйся или потеряешь поддержку», которое используют вендоры для перевода клиентов на новые, менее выгодные условия. Судебное противостояние Oracle и Rimini Street — именно об этом, ведь поддержка от сторонних поставщиков представляет собой прямую коммерческую угрозу этой модели.
Слои интероперабельности
Снижают затраты на переход к другому вендору, предотвращая формирование постоянной зависимости. Интеграционная платформа между вашими ITSM-, HR- и закупочными системами превращает смену одного инструмента в замену коннектора, а не пересборку всей операционной модели. Стандартизируйте протоколы SAML, OIDC, SCIM — чтобы управление жизненным циклом не зависело целиком от одного программного комплекса.
FinOps и SaaS-менеджмент
Предоставляют доказательную базу, которая делает вашу позицию в переговорах о продлении договора более убедительной. Зависимость от вендора процветает, когда вы не может показать, что и как именно вы используете. Данные об использовании ПО, стоимости активного пользователя и висящем мертвым грузом программном обеспечении дают законное основание сократить набор приложений, убрать из пакета ненужное или отказаться от части условий по договору. Без этой базы позиция вендора всегда будет сильнее.
Государственное регулирование
Директива ЕС о праве на ремонт, вступившая в силу в июле 2026 года, и результаты углубленного анализа рынка облачных услуг, проведенного Управлением по вопросам конкуренции и рынков Великобритании, отражают тенденцию, направленную на поддержку переносимости, совместимости и прав клиентов на отказ от услуг. Это пока еще не гарантии в закупках, но полезные ориентиры в обсуждении условий договора.
Lock-in как управляемое решение
В конечном счете, не с каждой зависимостью нужно бороться: иногда это решение, которым необходимо управлять.
Выбор одного Identity-провайдера, одной платформы управления конечными устройствами или единого поставшика облачных мощностей может быть оправданным. Разобщенность вендоров тоже имеет свои издержки: нужно управлять бОльшим количеством поставщиков, интеграций, договоров, рисков… Главное — не избегать зависимости любой ценой, а быть уверенным, что она просчитана, задокументирована и находится под контролем.
Это меняет суть работы ITAM. Основная задача — не обосновать необходимость смены вендора, а располагать необходимыми данными для принятия взвешенного, не вынужденного решения при продлении договоров, изменении условий поставщиком или намерении сократить расходы.
Начните с анализа зависимости от ваших вендоров с учетом затрат и критичности. Задайте всего три вопроса: как долго займет прекращение сотрудничества, во сколько оно обойдется и чем придется пожертвовать. Если не можете на них ответить, есть над чем работать — задокументируйте, оцените и представьте ваши изыскания. Зависимость от поставщиков — это финансовые и операционные риски, которые должны обсуждаться наравне с любыми другими.
Подведем итоги
Зависимость от вендоров никуда не денется. Переход на SaaS-модели, облачные технологии и AI формируют новые lock-in быстрее, чем компании успевают их отслеживать — и поставщики этим активно пользуются.
У ITAM есть все на руках: данные, договора, график продлений. Часто не хватает только одного — быть в переговорной во время подписания договора, а не после, когда lock-in уже захлопнулся.
Начните с анализа топ-10 вендоров по затратам. По каждому рассчитайте, сколько потратите времени и денег на уход и чем при этом придется пожертвовать. Обычно команды ITAM владеют такой информацией всего по двум-трем вендорам. Оставшиеся требуют более внимательного изучения.
А вы оценивали своих ключевых вендоров с точки зрения рисков lock-in? Что вы обнаружили и какие виды рисков оказались самыми сложными в управлении? Делитесь опытом в комментариях.
Комментарий от команды ITSM 365: почему решили поднять эту непростую тему — мы запланировали материал о смене поставщика ITSM-решения. Уже скоро расскажем на реальных примерах, почему к нам уходят от других вендоров и как э��о происходит. Перемены — всегда непросто, но зато может быть очень полезно для отдельных процессов и компании в целом, поделимся такими кейсами.
От нас, конечно, тоже уходят, так что не будем делать секрет из очевидного факта, поговорим и об этом. Напишите, о чем вам было бы интересно узнать в контексте смены вендора, постараемся отразить это в статье.
