Заказная разработка или готовое решение? B2B-гид по выбору

Первое различие: стандарт или преимущество?

Бухгалтерия, почта, зарплата — стандартные процессы. Тысячи компаний делают их одинаково. Готовые пакеты (SAP, QuickBooks, Workday) зрелые, безопасные, дешёвые. Писать под заказ здесь обычно расточительство.

Но ваше "конкурентное преимущество" — собственный алгоритм ценообразования, интеграция под клиента, специфический операционный поток — становится универсальным в тот момент, когда вы загоняете его в стандартный инструмент. Те 20 %, что создают реальную ценность, падают до 0 %. Здесь заказная разработка — единственный путь: использующий те же инструменты, что и конкурент, получает тот же результат.

Четыре практических вопроса

Прежде чем выбирать, ответьте на эти четыре вопроса:

1) Процесс — отраслевой стандарт или уникален для вашей компании? 2) Меняется ли модель данных с внешним миром (биллинг, интеграции)? Если да — готовое ПО или SaaS с открытым API подойдёт. 3) Изменится ли ваша бизнес-модель вокруг этого процесса в ближайшие 24 месяца? Если да — потолок конфигурации пакета вас свяжет. 4) Конкурентное преимущество скрыто в процессе? Если вы упоминаете его, объясняя "почему выбирают нас", заказная разработка обязательна.

Два и более "уникальных" ответа (уникально, скрытое преимущество) — в пользу заказной разработки. Иначе начните с пакета и мигрируйте, когда упрётесь в потолок — это самая дешёвая стратегия.

Гибридный подход: самый прагматичный выбор

В реальности большинство B2B-решений — не "всё под заказ" и не "всё готовое", а умная комбинация того и другого. Схема: стандартный слой (бухгалтерия, HR, ядро CRM, почта) работает на лучшем пакете на рынке; дифференцирующий слой (ценовой движок, клиентский портал, операционный поток, преобразование данных) собирается как заказное ПО и интегрируется с пакетами через API.

Это даёт три вещи: (1) безопасность поставщика и низкий TCO в commodity-слое, (2) полный контроль и быстрые итерации в дифференциаторе, (3) каждый слой развивается в своём темпе. На практике получается "SaaS + API + тонкий свой прикладной слой". С ростом заказной слой расширяется; пакетные слои остаются стабильны. В Setviva около 70 % клиентов стартуют гибридно — тех, кто просит чисто заказную разработку, после карты процессов часто устраивает перевод стандартных процессов тоже на пакетные инструменты.

Как правильно оценить стоимость миграции

Самая частая ошибка B2B-руководителей: сравнивать только стоимость лицензии или проекта. Настоящая цена — под водой. При переходе на пакетное ПО добавьте: миграцию и очистку данных, обучение, потерю производительности во время перехода, разработку интеграций, кастомизацию отчётности, реинжиниринг процессов. Обычно это 3–5× от лицензии. При переходе на заказное добавьте: дизайн и discovery, разработку, тестирование, обучение, поддержку и непрерывную итерацию, инфраструктуру (серверы, мониторинг, резервные копии), риск владения (кто поддержит, если команда уйдёт). Обычно это 1,5–2× от стоимости разработки.

Для честного сравнения распишите полную стоимость владения (TCO) на 24–36 месяцев и сравните оба варианта на одной шкале. В каждом коммерческом предложении Setviva мы даём эту построчную TCO сразу — чтобы решение опиралось на "реально дешёвый", а не "кажется дешёвым". Правильно посчитать стоимость миграции может быть важнее самого выбора.

Риск зависимости от поставщика: он работает в обе стороны

Каждый руководитель спрашивает «сколько это стоит сегодня», но почти никто не спрашивает «у кого будет рычаг влияния на меня через три года». В случае SaaS дорожную карту пишет поставщик, а не вы. Контракты продлеваются с повышением цен, которое может стать резким, как только инструмент прочно встроится в ваши повседневные операции; функции снимаются с поддержки или переносятся в более дорогой тариф; поставщика могут купить, а продукт — свернуть по графику, который выбирали не вы. Ничего из этого не гипотетично — это обычный жизненный цикл поставщиков ПО, и чем глубже инструмент встроен в ваши операции, тем дороже становится от него отказаться, даже если цена утроится. Это не повод избегать SaaS — для стандартных процессов это обычно по-прежнему правильный выбор, — но это значит, что сравнение по «ежемесячной плате» скрывает настоящий вопрос: сколько рычага влияния вы отдаёте стороне, чьи интересы не совпадают с вашими?

Заказная разработка разворачивает проблему зависимости внутрь. Риск теперь не в дорожной карте поставщика, а в «факторе автобуса» вашей собственной команды. Если разработчики, создавшие систему, уходят, а решения, лежащие в её основе, никогда не документировались, система незаметно превращается в чёрный ящик, к которому никто не хочет прикасаться. Оставленная без поддержки, она обрастает устаревшими зависимостями, перестаёт получать патчи безопасности, и в итоге «заказное» превращается именно в то, чего вы пытались избежать, — в хрупкую унаследованную систему. Зависимость здесь — не пункт контракта, а сконцентрированное знание, но эффект тот же: уйти без больших затрат не получится.

Решение — с первого дня рассматривать стоимость выхода как критерий выбора, причём с обеих сторон. Для SaaS перед подписанием проверьте, какие данные можно выгрузить и в каком формате, ограничивает ли контракт рост цен и насколько болезненным будет уход на практике. Для заказной разработки настаивайте, чтобы права на исходный код, доступ к инфраструктуре и актуальная документация были прописанными обязательствами по контракту, а не любезностью — и выбирайте партнёра, который пишет код для того, кто унаследует систему в будущем, а не только для демонстрации. Какой бы путь вы ни выбрали, задавайте вопрос о выходе раньше вопроса о покупке. Возможность уйти стоит больше, чем вариант, который выглядит дешевле всего сегодня.