Коробочные решения закрывают типовые задачи и хорошо масштабируются до определенного этапа. Но в какой момент они перестают поддерживать рост бизнеса и начинают его ограничивать? Какие преимущества и недостатки «коробки» и кастомной разработки становятся очевидны только в эксплуатации? И почему одинаковые инструменты показывают разную эффективность в компаниях с похожими бизнес-процессами?
Мы рассмотрели три кейса ИТ-руководителей, которые выбирали между типовыми и уникальными решениями в рамках проектов цифровой трансформации в своих компаниях. В статье разобрали, какими критериями нужно руководствоваться при этом выборе, а также — как применять эту логику к ИТ-ландшафту и бизнес-задачам в конкретных случаях.
Куда движется рынок
Когда мы говорим о заказной разработке, мы имеем в виду создание решения с нуля под задачи бизнеса — силами внешнего партнера, внутренней или смешанной командой.
Привычное противопоставление «кастом – дорого, коробка – быстро» больше не работает: бизнесу нужны гибкие изменения, к которым не все вендоры успевают адаптироваться. Это подтверждает рынок: согласно обзору TAdviser, внутренний рынок заказной разработки в России к 2024 году оценивался в 200–300 млрд рублей и рос на 25–28%.
По данным CNews, сегмент заказной разработки растет на 15–20% в год. Спрос растет потому, что стандартные продукты редко закрывают сложные бизнес-процессы, а импортозамещение и ИИ ускоряют потребность в решениях, точно подстроенных под бизнес.
На рынке существуют полярные подходы: от убежденных сторонников коробок до тех, кто принципиально делает ставку на заказную разработку. Одни видят в ней лишние риски, другие — единственный способ не упираться в потолок роста. Поэтому вопрос «коробка или кастом» до сих пор остается предметом споров, а не готовых ответов.
Различия хорошо видны не в абстрактных рассуждениях, а в реальных управленческих решениях, которые принимают ИТ-директора.
Три руководителя — три разных позиции
Для того, чтобы разобрать логику и критерии выбора, на которые опираются ИТ-руководители в различных отраслях и с учетом разных задач, мы пообщались с тремя экспертами:
- Екатерина Водяницкая — ИТ-эксперт с опытом создания и развития сложных ИТ-систем в ритейле и банках в роли технического директора и директора проектов. Екатерина поддерживает использование кастома в сложных и нагруженных ландшафтах.
- Александр Лебедев — CIO и CDTO, который за более чем двадцатилетний опыт реализовал свыше 40 комплексных проектов в разных отраслях: транспорт, энергетика, ЖКХ, нефтяной сектор, машиностроение. Он выступает за развитие отраслевых стандартов и против избыточной кастомизации.
- Евгений Лучников — руководитель отдела управления проектами и бизнес-приложениями из Inventive Retail Group, занимает прагматичную позицию и выбирает подход исходя из скорости и эффекта.
Позиции экспертов позволяют лучше понять, в каких случаях тот или иной подход при выборе между кастомной разработкой и готовым решением является оправданным. Начнем с ситуации, в которой заказная разработка становится осознанным и наиболее оптимальным решением.
Кастом как осознанный выбор ИТ-директора
Екатерина Водяницкая считает, что выбор между «коробкой» и кастомом всегда должен опираться на контекст и сложность задачи. Когда на рынке есть готовое решение, которое укладывается в требования бизнеса, разумно его использовать, а не «изобретать велосипед».
«Но часто в нагруженном, постоянно меняющемся ИТ-ландшафте использование «коробки» становится не преимуществом, а ограничением, которое не позволяет быстро адаптировать решение к запросам бизнес-пользователей и изменениям внешней среды. В таких случаях оправдан кастом с упором на модульность, бесшовные интеграции и гибкие доработки», — отмечает эксперт.
Екатерина приводит в пример кейс крупного ритейлера, который разработал кастомную логистическую платформу для разветвленной сети распределительных центров. Перед компанией стояла задача — обеспечить устойчивые интеграции и скорость изменений в распределенном складском контуре, где ландшафт включал устаревшую западную WMS, набор кастомных модулей и разнородные ТСД. Нагрузка достигала сотен тысяч строк операций в день. При этом бизнес готовился к внедрению роботизированных механизмов, но на старом стеке это было невозможно.
Критерии выбора в данном случае были такими: контроль архитектуры, независимость от вендора и возможность тиражировать решение без риска для стабильности операций на РЦ.
«Это крупный бизнес с большим количеством площадок, каждая со своей спецификой, и ее важно было учесть уже на этапе проектирования. Выбери мы коробочное решение — пришли бы к сопоставимым с кастомом расходам из-за объема доработок. «Коробка» быстро уперлась бы в архитектурные ограничения: монолитность и единую базу данных. В результате скорость внесения изменений и качество поддержки резко бы ухудшились».
Екатерина Водяницкая, ИТ-эксперт с опытом создания и развития сложных ИТ-систем в ритейле и банках
Решением стала разработка собственной логистической платформы с разделением архитектуры: общие сервисы централизованы, а предметные модули (управление складом, двором, транспортом, резервирование) реализованы как отдельные сервисы, которые работают на уровне конкретных объектов и учитывают их особенности.
«Мы создавали платформу для группы компаний сразу с учетом унификации процессов: выделяли общие сервисы — авторизацию, системные настройки, логи. Это обеспечило управляемость стека и позволило масштабировать решение без «пересборки» всего контура», — говорит эксперт.
В результате система перестала ограничивать операционный рост. В описанных условиях кастом стал единственным способом развивать бизнес-процессы в нужном темпе. Компания получила возможность поэтапно обновлять логистические системы без простоя РЦ, быстро расширять функциональность и развивать роботизацию.
Кастом не панацея
Иной точки зрения придерживается Александр Лебедев, сторонник отраслевых стандартов в бизнес-критичных системах. Он считает, что важно опираться на накопленный рынком опыт, не увлекаться избыточным кастомом и не воспроизводить то, что уже многократно проверено.
«В мире кастом менее распространен. В России ситуация иная: компании нередко считают бизнес-процессы уникальными и не хотят перестраивать их под «коробку», даже когда в крупных и всем известных решениях зашиты лучшие практики и опыт рынка, накопленный годами. Однако, с моей точки зрения, заказная разработка уместна, когда вы первопроходцы и делаете то, чего раньше не делал никто», — уверен эксперт.
Александр поделился кейсом, в рамках которого компания выбрала проверенную «коробку» для работы в специфической отрасли — энергосбыте. Задача проекта заключалась в том, чтобы выстроить систему работы с потребителями электроэнергии, где нужно рассчитывать многоуровневый баланс потребления ресурсов: от индивидуального уровня (квартира) через агрегированные балансы дома и теплового пункта, до баланса по всей тепломагистрали.
Объем данных внушительный — более трех миллионов лицевых счетов физических лиц и около двухсот тысяч юридических. Ошибка в методике расчетов может приводить к потерям, исчисляемым миллионами рублей, а баланс должен сходиться на каждом уровне цепочки. Требовалось, чтобы цифровое решение включало проработанную логику расчетов и возможность использовать отраслевую модель, уже заложенную в продукт.
Компания выбрала SAP IS-U — специализированное решение для энергетики, созданное на основе лучших мировых практик, которое компания взяла за основу и адаптировала. Александр Лебедев подчеркивает, что коробочное решение для бизнес-критичных процессов в любом случае требует адаптации.
В результате система позволила выстраивать корректные балансы использования энергоресурса по всей цепочке (от квартиры до тепломагистрали) и обеспечить точность в сложнейших расчетах. В сфере, где ошибка может стоить миллионы, отраслевой стандарт оказался единственным способом обеспечить точность и предсказуемость работы системы.
Не за «коробку» и не за кастом — за результат
Третий эксперт, Евгений Лучников, занимает прагматичную позицию. Выбор между «коробкой» и кастомом для него — это вопрос скорости получения бизнес-эффекта.
«Когда стоит цель создать продукт, который будет развиваться вместе с компанией, кастом — оптимальный путь. Если бизнесу нужно решение «вчера», заказная разработка может не подойти».
Евгений Лучников, руководитель отдела управления проектами и бизнес-приложениями из Inventive Retail Group
Кейс, который приводит в пример Евгений, — замена кастомной системы лояльности на готовое решение. Перед компанией стояла задача — обновить систему лояльности, созданную ранее собственными силами, так как она перестала соответствовать новым требованиям и темпам изменения бизнеса. Требовался продукт, уже проверенный рынком и временем.
Решение выбирали по следующим критериям: широкое функциональное покрытие, наличие реальных внедрений в схожих по масштабу компаниях, прозрачная стоимость владения и отсутствие инвестиций в собственную разработку.
Выходом стала смена собственной разработки на коробочную платформу лояльности. Вендор взял адаптацию решения на себя, а команда получила зрелый продукт без долгой разработки. Сам переход на новое решение получился довольно быстрым, при этом система закрыла практически все бизнес-потребности.
В результате компания получила работающую функциональность без длительной разработки и смогла развивать программу лояльности поэтапно. «Коробка» позволила сосредоточиться на стратегическом развитии. Вендор взял на себя поддержку ядра, что снизило риск «расползания» сроков и бюджета.
5 советов, которые помогут выбрать оптимальный подход
Обобщая этот опыт, ИТ-руководители выделяют несколько практических принципов, которые помогают выбрать оптимальный подход в конкретной ситуации.
1. Не автоматизируйте неэффективное
Прежде чем выбирать инструмент, критически проанализируйте бизнес-процессы: автоматизация имеет смысл там, где процесс уже выверен и создает ценность, а не воспроизводит хаос.
«Если просто переложить старую логику в новую систему, то на выходе получатся те же проблемы, только в другом виде», — считает Екатерина Водяницкая.
2. Проведите предпроектное обследование
Это ключевой этап, который помогает избежать неоправданных инвестиций и разработок. Сформулируйте проблему и желаемый эффект. Рассмотрите альтернативные способы решения задачи и отделите реальную «боль» от личных пожеланий бизнес-пользователей.
«Нужно глубоко исследовать цели бизнеса: что он хочет? Ради чего делать ИТ-проект? Ради красивой кнопки или ради результата? Не спросишь, что хочет бизнес, — ошибешься», — уверен Евгений Лучников.
3. Выравнивайте архитектуру и стек
Гибрид — не значит «зоопарк». Зафиксируйте целевую архитектуру, определите единые принципы интеграций. Ограничьте использование редких технологий, которые сложно масштабировать, и найм специалистов с уникальной экспертизой, которую нельзя переиспользовать.
«Когда технологий и решений внутри компании становится слишком много, приходится привлекать все больше разработчиков для поддержки этих технологий, а тех специалистов, которые действительно нужны, все равно не хватает», — констатирует Александр Лебедев.
4. Используйте внутреннюю экспертизу в отрасли
Вовлекайте аналитиков, которые знают бизнес-процессы изнутри. Особенно если вы выбрали создавать собственное решение.
«В кейсе, о котором я рассказала выше, ключевую роль в создании кастомной логистической платформы сыграла внутренняя экспертиза: аналитики с пятнадцатилетним опытом работы в компании идеально знали ее бизнес-процессы и понимали все ограничения. Благодаря этому решение стало максимально отвечать задачам бизнеса и сформировало возможность для его дальнейшего развития», — считает Екатерина Водяницкая.
5. Посчитайте полную стоимость владения системой
«Коробка» выглядит дешевле на этапе внедрения, но при глубокой доработке возрастает риск вендор-лока и стоимость лицензий, особенно при большом количестве пользователей. Кастомное решение требует бóльших инвестиций на входе, но в долгосрочной перспективе может дать больше контроля над затратами и развитием системы.
Сегодня рынок живет логикой «быстрых выигрышей», но этот фокус временный. Приоритеты изменчивы, и решения, удобные сегодня, могут создать ограничения завтра. Важно выбирать инструменты, которые не усложнят жизнь бизнесу через несколько лет.
Резюме
Опыт ИТ-руководителей показывает, что универсального ответа на вопрос «коробка или кастом» не существует. В одних сценариях компаниям необходим проверенный отраслевой стандарт, чтобы обеспечить предсказуемость и управляемость критичных бизнес-процессов. В других — готовое решение может быть недостаточно функциональным или сдерживать операционный рост и скорость адаптации под новые требования рынка. Тогда осознанным управленческим решением становится заказная разработка, которая позволяет сохранить гибкость, контроль архитектуры и возможность развиваться в собственном темпе.
Ключевой фактор выбора между коробочным и кастомным решением — понимание контекста: зрелости бизнес-процессов, нагрузки на систему, допустимого уровня зависимости от вендора и требований к масштабированию. На практике выигрывают команды, которые трезво оценивают ограничения текущего ИТ-ландшафта, используют коробочные решения там, где они действительно дают эффект, и выбирают кастом в зонах, где важны устойчивость и поддержка роста бизнеса в долгосрочной перспективе.