Решение обычно приходит в виде таблицы: три вендора, оценка разработки, стоимость лицензий в одной колонке и срок запуска в другой. Кто-то уже сформировал предпочтение, и встреча существует, чтобы его подтвердить.
Чего не видит коммерческое сравнение
Таблица не лжёт — она неполна вполне определённым и дорогим образом. Цена покупки и стоимость разработки — видимые числа. Реальная цена решения «строить / покупать / интегрировать» живёт в восьми технических вопросах, которые коммерческое сравнение редко задаёт, — и самый дешёвый вариант на слайде регулярно оказывается самым дорогим в ландшафте три года спустя.
Коммерческий кейс сравнивает стоимость приобретения. Но платформенная функциональность не приобретается — она эксплуатируется: интегрируется, защищается, обновляется, мониторится, обеспечивается людьми и однажды выводится. Для купленного продукта лицензия — входной билет; цена эксплуатации — это интеграционные работы, кастомизация, застывающая в неофициальные форки, беговая дорожка обновлений и обходные решения для тех 20% требований, которым продукт почти соответствует. Для собственной разработки оценка покрывает первую версию; цена эксплуатации — каждый год владения после того, как команда запуска перешла на другое.
Ни то ни другое не аргумент в пользу противоположной стороны. Это аргумент в пользу сравнения полной стоимости эксплуатации за жизнь функциональности — которое требует технических вопросов ниже, отвеченных до решения, а не обнаруженных после.
Тест на дифференциацию
Первый вопрос фильтрует все остальные: эта функциональность делает нас другими — или просто позволяет нам работать?
Стройте то, что дифференцирует, — функциональность, чьё поведение и есть ваш продукт или ваше преимущество, где контроль над её эволюцией — сама суть. Покупайте то, что является commodity, — где быть ровно таким же, как все, нормально, а масштаб вендора выигрывает у внутренних усилий. Дорогие провалы живут в зонах путаницы: строительство commodity (внутренний инструмент, которому готовый продукт соответствует функция в функцию — минус команда сопровождения) и покупка дифференциации (ваше ключевое преимущество, теперь зависящее от плана развития и коммерческих условий вендора).
Тест честен именно там, где неудобен: большинство функциональности — commodity, и потребность, кажущаяся уникальной, часто ближе к commodity, чем выглядит на первый взгляд.
Поверхность интеграции и владение данными
Два вопроса решают, не превратится ли «купить» незаметно в «всё равно строить»:
Насколько велика поверхность интеграции? Посчитайте точки соприкосновения продукта с вашим ландшафтом — идентификация, потоки данных, процессы, отчётность. Продукт с дюжиной глубоких точек интеграции — не покупка «с полки», а проект разработки с приложенной лицензией. Инвентаризация занимает день и регулярно меняет решение.
Кто владеет данными — практически, а не контрактно? Контракт говорит, что данные ваши. Практические вопросы: в каком виде вы можете их извлечь, с какой полнотой, с какой историей, за какую цену? Система, держащая ваши данные в проприетарной форме, владеет вашими вариантами выхода независимо от того, что написано в контракте.
Lock-in и расширяемость как свойства архитектуры
Lock-in — не грех вендора, а свойство архитектуры, которым вы либо управляете, либо которое поглощаете. Его измеримая версия — цена выхода: что потребовалось бы сегодня, чтобы перенести эту функциональность в другое место — миграция данных, перестроенные интеграции, переобучение, параллельная работа? Если ответ — «мы бы реалистично никогда не ушли», этот факт принадлежит решению и переговорам, с соответствующей ценой.
Расширяемость — то же свойство, обращённое вперёд: когда ваши требования перерастут 80% продукта, что произойдёт? Продукты с настоящими API, точками расширения и поддерживаемой моделью кастомизации стареют хорошо. Продукты, где расширение требует профессиональных услуг вендора, привязывают ваш план развития к его мощностям и ценам. Для собственной разработки зеркальный вопрос — кто расширяет её на третий год, когда изначальная команда уже в другом месте.
Поверхность безопасности и соответствия
Каждый вариант несёт свою позицию безопасности, и это сравнение редко делается явным. Покупка импортирует вендора в вашу границу доверия: его модель доступа, ритм патчей, историю инцидентов, его субподрядчиков — это due diligence, а не галочка. Собственная разработка держит границу внутри, но делает вас ответственным за всё внутри неё — включая части, на которые вендор выделил бы людей. Интеграция — сборка функциональности из существующих доверенных систем — может уменьшить число новых компонентов, но сами интеграционные пути всё равно требуют явного ревью безопасности.
Для регулируемых ландшафтов один этот вопрос может решить дело до того, как обсуждается цена.
Оценочный лист
Восемь вопросов, оценённых по доказательствам до коммерческого решения:
- 1. Дифференциация — эта функциональность делает нас другими или позволяет нам работать?
- 2. Полная стоимость эксплуатации — за жизнь функциональности, а не за приобретение.
- 3. Поверхность интеграции — сколько точек соприкосновения, насколько глубоких, оценённых как инженерия.
- 4. Владение данными — практическая извлекаемость, а не контрактные заверения.
- 5. Lock-in / цена выхода — чего стоил бы уход, в числах.
- 6. Расширяемость — что происходит, когда 80% заканчиваются.
- 7. Поверхность безопасности — что входит в границу доверия, кто это патчит.
- 8. Время до функциональности — честное, включая интеграцию и внедрение, а не время до контракта.
Частый итог — не вердикт, а декомпозиция: купить commodity-ядро, построить тонкий дифференцирующий слой поверх, интегрировать остальное через собственные интерфейсы. Гибридный ответ никогда не появляется на слайде вендора, потому что его никто не продаёт, — именно поэтому в комнате до подписи нужен инженерный голос.