Коробка vs заказная разработка: как выбирают ИТ-директора

Коробочные решения закрывают типовые задачи и хорошо масштабируются до определенного этапа. Но в какой момент они перестают поддерживать рост бизнеса и начинают его ограничивать? Какие преимущества и недостатки «коробки» и кастомной разработки становятся очевидны только в эксплуатации? И почему одинаковые инструменты показывают разную эффективность в компаниях с похожими бизнес-процессами?

Мы рассмотрели три кейса ИТ-руководителей, которые выбирали между типовыми и уникальными решениями в рамках проектов цифровой трансформации в своих компаниях. В статье разобрали, какими критериями нужно руководствоваться при этом выборе, а также — как применять эту логику к ИТ-ландшафту и бизнес-задачам в конкретных случаях.

Когда мы говорим о заказной разработке, мы имеем в виду создание решения с нуля под задачи бизнеса — силами внешнего партнера, внутренней или смешанной командой.

Привычное противопоставление «кастом – дорого, коробка – быстро» больше не работает: бизнесу нужны гибкие изменения, к которым не все вендоры успевают адаптироваться. Это подтверждает рынок: согласно обзору TAdviser, внутренний рынок заказной разработки в России к 2024 году оценивался в 200–300 млрд рублей и рос на 25–28%.

По данным CNews, сегмент заказной разработки растет на 15–20% в год. Спрос растет потому, что стандартные продукты редко закрывают сложные бизнес-процессы, а импортозамещение и ИИ ускоряют потребность в решениях, точно подстроенных под бизнес.

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

Различия хорошо видны не в абстрактных рассуждениях, а в реальных управленческих решениях, которые принимают ИТ-директора.

Для того, чтобы разобрать логику и критерии выбора, на которые опираются ИТ-руководители в различных отраслях и с учетом разных задач, мы пообщались с тремя экспертами:

• Екатерина Водяницкая — ИТ-эксперт с опытом создания и развития сложных ИТ-систем в ритейле и банках в роли технического директора и директора проектов. Екатерина поддерживает использование кастома в сложных и нагруженных ландшафтах.
• Александр Лебедев — CIO и CDTO, который за более чем двадцатилетний опыт реализовал свыше 40 комплексных проектов в разных отраслях: транспорт, энергетика, ЖКХ, нефтяной сектор, машиностроение. Он выступает за развитие отраслевых стандартов и против избыточной кастомизации.
• Евгений Лучников — руководитель отдела управления проектами и бизнес-приложениями из Inventive Retail Group, занимает прагматичную позицию и выбирает подход исходя из скорости и эффекта.

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

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

«Но часто в нагруженном, постоянно меняющемся ИТ-ландшафте использование «коробки» становится не преимуществом, а ограничением, которое не позволяет быстро адаптировать решение к запросам бизнес-пользователей и изменениям внешней среды. В таких случаях оправдан кастом с упором на модульность, бесшовные интеграции и гибкие доработки», — отмечает эксперт.

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

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

Решением стала разработка собственной логистической платформы с разделением архитектуры: общие сервисы централизованы, а предметные модули (управление складом, двором, транспортом, резервирование) реализованы как отдельные сервисы, которые работают на уровне конкретных объектов и учитывают их особенности.

«Мы создавали платформу для группы компаний сразу с учетом унификации процессов: выделяли общие сервисы — авторизацию, системные настройки, логи. Это обеспечило управляемость стека и позволило масштабировать решение без «пересборки» всего контура», — говорит эксперт.

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

Иной точки зрения придерживается Александр Лебедев, сторонник отраслевых стандартов в бизнес-критичных системах. Он считает, что важно опираться на накопленный рынком опыт, не увлекаться избыточным кастомом и не воспроизводить то, что уже многократно проверено.

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

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

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

Компания выбрала SAP IS-U — специализированное решение для энергетики, созданное на основе лучших мировых практик, которое компания взяла за основу и адаптировала. Александр Лебедев подчеркивает, что коробочное решение для бизнес-критичных процессов в любом случае требует адаптации.

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

Третий эксперт, Евгений Лучников, занимает прагматичную позицию. Выбор между «коробкой» и кастомом для него — это вопрос скорости получения бизнес-эффекта.

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

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

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

В результате компания получила работающую функциональность без длительной разработки и смогла развивать программу лояльности поэтапно. «Коробка» позволила сосредоточиться на стратегическом развитии. Вендор взял на себя поддержку ядра, что снизило риск «расползания» сроков и бюджета. 

Обобщая этот опыт, ИТ-руководители выделяют несколько практических принципов, которые помогают выбрать оптимальный подход в конкретной ситуации.

1. Не автоматизируйте неэффективное

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

«Если просто переложить старую логику в новую систему, то на выходе получатся те же проблемы, только в другом виде», — считает Екатерина Водяницкая.

2. Проведите предпроектное обследование

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

«Нужно глубоко исследовать цели бизнеса: что он хочет? Ради чего делать ИТ-проект? Ради красивой кнопки или ради результата? Не спросишь, что хочет бизнес, — ошибешься», — уверен Евгений Лучников.

3. Выравнивайте архитектуру и стек

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

«Когда технологий и решений внутри компании становится слишком много, приходится привлекать все больше разработчиков для поддержки этих технологий, а тех специалистов, которые действительно нужны, все равно не хватает», — констатирует Александр Лебедев.

4. Используйте внутреннюю экспертизу в отрасли

Вовлекайте аналитиков, которые знают бизнес-процессы изнутри. Особенно если вы выбрали создавать собственное решение.

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

5. Посчитайте полную стоимость владения системой

«Коробка» выглядит дешевле на этапе внедрения, но при глубокой доработке возрастает риск вендор-лока и стоимость лицензий, особенно при большом количестве пользователей. Кастомное решение требует бóльших инвестиций на входе, но в долгосрочной перспективе может дать больше контроля над затратами и развитием системы.

Сегодня рынок живет логикой «быстрых выигрышей», но этот фокус временный. Приоритеты изменчивы, и решения, удобные сегодня, могут создать ограничения завтра. Важно выбирать инструменты, которые не усложнят жизнь бизнесу через несколько лет.

Опыт ИТ-руководителей показывает, что универсального ответа на вопрос «коробка или кастом» не существует. В одних сценариях компаниям необходим проверенный отраслевой стандарт, чтобы обеспечить предсказуемость и управляемость критичных бизнес-процессов. В других — готовое решение может быть недостаточно функциональным или сдерживать операционный рост и скорость адаптации под новые требования рынка. Тогда осознанным управленческим решением становится заказная разработка, которая позволяет сохранить гибкость, контроль архитектуры и возможность развиваться в собственном темпе.

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