Привязка к вендору: считайте стоимость выхода, а не только входа
Вопрос при выборе платформы - не только во сколько обойдётся войти. Вопрос в том, во сколько обойдётся выйти - и можете ли вы честно ответить на него до подписания договора.
Любая значимая технологическая закупка предполагает некоторую степень привязки. Вы адаптируете процессы, интегрируете системы, обучаете людей, накапливаете данные в формате вендора. Это нормально и само по себе не плохо - вопрос в том, входили ли вы в это с открытыми глазами.
В большинстве оценок вендоров, которые я вижу, фокус - на затратах на вход: лицензирование, внедрение, обучение, миграция. Стоимость выхода в анализе практически не появляется. Её считают гипотетической, слишком далёкой в будущем, или просто не считают, потому что никто не хочет начинать разговор с вендором с обсуждения расставания.
В 2016 году, когда облачное внедрение ускоряется, этот пробел в оценке обходится всё дороже. Проприетарные облачные сервисы легко внедрить и трудно покинуть. Экономика привязки становится тем, что команды руководства должны понимать явно.
Что на самом деле включают затраты на выход
Когда я прорабатываю привязку к вендору с клиентом, я стараюсь оценить затраты на выход по нескольким категориям.
Портативность данных: можно ли экспортировать данные в стандартном, пригодном для использования формате? Что исключается из экспорта? Сколько времени займёт перенос полного набора данных? Некоторые вендоры берут плату за массовый экспорт. Некоторые форматы требуют трансформации перед загрузкой в другое место.
Поверхность интеграции: каждая точка интеграции, которую вы строите к проприетарному API вендора, - это точка, которую придётся перестроить при уходе. Система с 12 нижестоящими интеграциями к специфическому API вендора имеет гораздо более высокую стоимость выхода, чем та, что использует общий стандарт вроде REST с опубликованной схемой.
Знания и процессы: насколько большая часть операционных знаний вашей команды специфична для этой платформы? Если ответ «большая часть», стоимость выхода включает переобучение или найм новых людей, что редко появляется в финансовых моделях.
Условия контракта: минимальные обязательства, условия автопродления и хранение данных после расторжения. Это поддаётся переговорам при подписании и почти не поддаётся изменению позже.
Разговор о портативности перед подписанием
Я рекомендую задать любому потенциальному вендору три конкретных вопроса перед подписанием.
Первый: как выглядит полный экспорт данных на практике - не по документации, а в части реального экспорта ожидаемого объёма данных, в каком формате и за какую стоимость?
Второй: что происходит с вашими данными после расторжения контракта и на протяжении какого времени?
Третий: есть ли функции или интеграции, которые вы планируете использовать и которые доступны только через проприетарные API этого вендора без стандартной альтернативы?
Ответы не всегда будут поводом для отказа. Но они дадут честную картину того, на что вы подписываетесь.
Сбалансированная позиция
Я не призываю избегать всех проприетарных платформ. Выигрыш в продуктивности от хорошо интегрированных облачных платформ реален. Аргумент - за пропорциональность: чем теснее вы интегрируетесь с проприетарной поверхностью вендора, тем более явной должна быть стратегия выхода.
Для базовых систем - всего, без чего бизнес genuinely не смог бы работать - стоимость выхода должна быть рассчитана и проверена тем, кто подписывает контракт. Не формально, а как реальная цифра.
Для второстепенных инструментов достаточно более лёгкого варианта этого анализа. Но «мы не думали о том, что будет, когда нам понадобится уйти» - это не то, чем эта история должна заканчиваться.