Купить готовый софт или разработать свой: как выбрать бизнесу

Ко мне обратилось крупное автотранспортное предприятие: логистика, десятки маршрутов, интеграции со страховыми компаниями и 1С. Требовалось автоматизировать управление всем этим хозяйством, и компания выбирала между готовой системой и собственной разработкой. Коробочное решение выглядело привлекательнее: меньше первоначальные расходы, быстрее запуск, понятнее предложение поставщика.

Я попросил сравнить оба варианта на горизонте трех лет и учесть масштаб — больше 200 активных пользователей. После этого экономика изменилась: собственная разработка становилась выгоднее уже через 14 месяцев. В результате мы сделали ERP — систему управления ресурсами предприятия — с собственным конструктором маршрутов. Она окупилась даже быстрее расчетного срока, а применение ИИ при разработке помогло ускорить работу и сократить затраты.

Эта история хорошо показывает, почему выбирать программное обеспечение по стартовой цене опасно. В момент покупки компания видит стоимость входа, а жить ей предстоит со всей системой расходов, ограничений и зависимостей, которые возникнут после запуска.

Почему дешевый запуск может оказаться дорогим решением

В исходных оценках проблемы фигурируют две показательные цифры: 67% провальных внедрений связывают с ошибочным выбором между покупкой готового решения и созданием собственного, а среднюю стоимость такой ошибки на западном рынке оценивают в $2,4 млн. Для конкретного бизнеса последствия будут зависеть от масштаба проекта, но сама механика ошибки обычно понятна: сравнивают стоимость лицензии со стоимостью разработки, хотя это разные части будущих расходов.

У готового продукта после запуска появляются платежи за пользователей, дополнительные функции, интеграции и сопровождение. По мере роста компании может потребоваться другой тариф, а нестандартный процесс — отдельная доработка. В исходном посте я приводил оценку, что SaaS-подписки на длинном горизонте могут обходиться в 2,5–4 раза дороже первоначально заявленного ценника. Поэтому в расчете важно видеть, что именно входит в предложение и при каких условиях сумма изменится.

Собственную разработку нужно считать столь же внимательно. После выпуска системы останутся поддержка, исправления, инфраструктура, безопасность и дальнейшее развитие. Если сопоставить полную стоимость готового решения только с бюджетом написания кода, получится такое же искажение, просто в противоположную сторону.

Для меня горизонт в три года — способ вынести за скобки впечатление от первого коммерческого предложения. Нужно посмотреть, сколько пользователей будет работать в системе, какие интеграции понадобятся и как изменится нагрузка. Именно такой расчет в истории с автотранспортным предприятием позволил увидеть преимущество собственной ERP.

Когда стоит покупать, а когда — разрабатывать

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

Иная ситуация возникает, когда особенности бизнеса приходится постоянно подгонять под ограничения продукта. Если маршрутизация, расчеты, взаимодействие с партнерами и логика операций требуют многочисленных обходных решений, первоначальная простота коробки постепенно исчезает. Компания оплачивает доработки, сохраняет параллельные таблицы и продолжает вручную связывать то, что должна была объединить автоматизация.

Собственная разработка становится обоснованной, когда она поддерживает значимые для бизнеса процессы и ее преимущества подтверждаются расчетом. При этом необязательно создавать все с нуля. Можно оставить готовые инструменты для типовых задач, а собственную платформу строить вокруг тех операций, которые определяют эффективность или конкурентное преимущество компании.

Почему контроль над системой важен не меньше цены

Уход части зарубежных поставщиков сделал зависимость от программного обеспечения особенно заметной для российского бизнеса. Компания может привыкнуть к системе, встроить ее в ежедневную работу, а затем столкнуться с ограничениями поддержки, оплаты или доступа. Поэтому оценивать готовый продукт нужно вместе с условиями, на которых бизнес сможет продолжать им пользоваться.

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

Поэтому для логистики, девелопмента и производства гибридная модель может оказаться разумным компромиссом. Типовые функции закрываются готовыми продуктами, а ключевые процессы и данные остаются под контролем компании. Выбирать такую архитектуру стоит исходя из задач бизнеса, а не из стремления обязательно купить все готовое или обязательно написать все свое.

Как внутренняя разработка может стать новым бизнесом

У удачного собственного решения бывает дополнительная перспектива: проблема, которую компания решила для себя, может оказаться общей для отрасли. Тогда внутренний инструмент становится основой самостоятельного продукта. Но между работающей системой для своей команды и предложением для внешних клиентов есть отдельный путь — с проверкой спроса, поддержкой и развитием продукта.

Эту логику можно увидеть в истории Basecamp, который появился из потребностей агентства 37signals в управлении проектами и общении с клиентами. AWS вырос из опыта Amazon в создании и эксплуатации ИТ-инфраструктуры, а Trisigma стала примером развития технологического продукта «Авито» для внешнего рынка. Это разные истории, но их объединяет способность превратить накопленную компетенцию в ценность для других компаний.

Рассматривать такую возможность полезно, однако закладывать будущие продажи в оправдание любой собственной разработки я бы не стал. Сначала система должна решить задачу основного бизнеса и подтвердить свою экономику. Только после этого имеет смысл проверять, готовы ли другие компании платить за аналогичное решение.

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