Зависимость от вендора: что должен знать каждый ITAM-специалист

Продление договора — через три месяца, но поставщик знает уже сейчас, что вы никуда не уйдете. Это и есть 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-решения. Уже скоро расскажем на реальных примерах, почему к нам уходят от других вендоров и как это происходит. Перемены — всегда непросто, но зато может быть очень полезно для отдельных процессов и компании в целом, поделимся такими кейсами. 

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