Зависимость от поставщика: считайте стоимость выхода до подписания
Почему стоимость смены ИТ-поставщика нужно оценивать заранее, и как это влияет на выбор платформы и условия контракта.
Когда компания выбирает ИТ-платформу - облачного провайдера, ERP-систему, CRM, инфраструктурный сервис - основное внимание обычно сосредоточено на функциональности, цене и сроках внедрения. Это разумно. Но есть вопрос, который задаётся редко: что будет стоить уйти, если понадобится?
Я не имею в виду пессимизм. Зависимость от поставщика - это не проблема сама по себе. Это управляемый риск, который нужно понимать до подписания контракта, а не после того, как вы три года работали в чужой экосистеме.
Из чего складывается стоимость выхода
Стоимость выхода редко бывает только договорной - то есть штрафами и неустойками. Обычно она складывается из нескольких составляющих.
Данные. В каком формате хранятся ваши данные? Можно ли их экспортировать в стандартном виде или только в проприетарном? Сколько времени займёт полная выгрузка и в каком состоянии будут данные после миграции? Нередко компании обнаруживают, что данные формально принадлежат им, но фактически "заперты" в формате, который никто другой не читает без специальных инструментов.
Интеграции. Сколько других систем подключено к этой платформе? Каждая интеграция - это работа, которую придётся переделывать при смене поставщика. Если за три года платформа стала центральным узлом для десяти интеграций - это значительная сумма работы.
Знания и навыки. Команда обучилась работать с конкретной платформой. При переходе нужно либо переобучать людей, либо нанимать новых. Это время и деньги, которые не отражаются ни в каком контракте.
Процессы. Бизнес-процессы адаптируются под ограничения и возможности платформы. Иногда настолько плотно, что смена платформы фактически означает реорганизацию процессов.
Когда думать об этом
Лучший момент - до выбора. Не потому что нужно изначально планировать уход, а потому что понимание стоимости выхода влияет на выбор архитектуры, условия контракта и стратегию хранения данных.
Несколько конкретных мест, где это проявляется:
Форматы данных. Стандартный открытый формат против проприетарного - это разница в стоимости миграции. Это стоит обсуждать с поставщиком на этапе выбора.
Условия контракта. Право на экспорт всех данных в машиночитаемом формате по запросу - это условие, которое можно и нужно вносить в договор.
Архитектурные решения. Часть зависимостей создаётся не поставщиком, а командой разработки - когда используется специфическое API там, где можно было использовать стандартное, или когда логика приложения пишется под конкретную облачную функцию вместо переносимого кода.
Это не аргумент против специализированных решений
Хочу быть точным: зависимость от поставщика часто оправдана. Глубокая интеграция с хорошей платформой даёт реальную ценность. Вопрос не в том, чтобы её избегать, а в том, чтобы принимать её осознанно.
Разница между управляемой зависимостью и неуправляемой - в том, понимаете ли вы, во что она обходится и что нужно сделать, чтобы выйти. Если это понимание есть - зависимость это стратегический выбор. Если нет - это просто накопленный риск.
Вопросы для оценки
- В каком формате мы можем выгрузить все наши данные из этой системы?
- Сколько интеграций с другими системами будет задействовано через год, через три года?
- Что нам придётся переделать в процессах и коде при смене поставщика?
- Закреплено ли право экспорта данных в контракте?
- Есть ли альтернативный поставщик, к которому мы могли бы перейти, и что для этого потребуется?