Выбор между коробочным продуктом и заказной разработкой решают не на уровне вкуса, а на уровне экономики и рисков. Коробка дешевле на старте и быстрее запускается. Кастом дороже, но подстраивается под ваши процессы, а не наоборот. Ошибка стоит дорого: переплата за лицензии или годы доработок чужого продукта, который так и не лёг на бизнес. Разберём, когда кастом действительно окупается.

Где коробка выигрывает

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

Граница проходит по объёму доработок. Пока вы настраиваете коробку штатными средствами – всё в порядке. Как только начинаете заказывать у вендора доработки ядра, считайте честно: их совокупная стоимость за три-пять лет нередко превышает цену собственной системы. При этом вы остаётесь в зависимости от одного поставщика – со всеми вытекающими, которые мы разбирали в материале про vendor lock-in.

Где окупается кастом

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

Для госсектора добавляется ещё один аргумент – требования по импортозамещению и включению в реестр отечественного ПО. Заказная разработка изначально проектируется под российский стек, отечественную СУБД и инфраструктуру, без зарубежных компонентов в критичных местах. Это снимает регуляторные риски, которые у иностранной коробки в 2024 году только растут.

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

Как считать решение

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

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

Вывод

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