13 октября 2025 г.
Универсальное ИТ-решение не всегда может учесть отраслевую специфику и другие особенности компании. О том, в каких случаях доработки оправданы, а когда адаптация коробочного решения приводит к не самым приятным последствиям, рассказывает Наталья Морозова, руководитель направления «Управление цепями поставок» группы компаний IBS.
Кто оказался перед выбором
После ухода западных вендоров подобрать платформу с достаточной глубиной кастомизации стало сложнее, особенно для агросектора, энергетики, строительства, непрерывных производств (нефтехимия, нефтепереработка) и других направлений, где много специфичных бизнес-процессов. Отечественные продукты пока не могут предложить готовой функциональности, подходящей для широкого спектра отраслей, причем проверенной на практике.
Крупные компании в нефтехимической и энергетической отраслях продолжают использовать тяжелые монолитные решения (например, SAP S/4HANA). Розничная торговля и FMCG, напротив, двигаются в сторону микросервисной архитектуры, выбирают платформенные решения (Optimacros, Knowledge Space) или приобретают готовый код у вендора, а затем самостоятельно интегрируют и развивают его как элемент платформы.
Иногда удается адаптировать систему под запросы бизнеса за счет конфигурации. Как показывает практика, это распространенный вариант в FMCG, где бизнес-процессы более стандартизированные. В других случаях без доработок зачастую не обойтись.
Чтобы понять, оправдана ли кастомизация, нужно ответить на ряд вопросов:
- насколько велик разрыв между требованиями бизнеса и возможностями решения;
- нет ли проблем с производительностью уже на этапе прототипа или пилотной реализации;
- удается ли придерживаться запланированных сроков без превышений более чем на несколько месяцев;
- соответствует ли бюджет ожиданиям и среднерыночной стоимости аналогичных проектов.
Если есть сомнения, возможно, стоит рассмотреть специализированные отраслевые решения или заказную разработку.
Риски при адаптации коробочного решения
Чрезмерная кастомизация может негативно влиять на архитектуру решения. Доработки часто проводятся параллельно несколькими проектными группами, поэтому не исключены проблемы с разграничением функциональных блоков и дублирование функциональности. Другие неблагоприятные архитектурные последствия — утяжеление модели данных и усложнение интеграции с другими системами. Кроме того, становится трудоемким документирование взаимосвязей настроек и объектов. На практике оно не выполняется на таком уровне, чтобы поддерживать и развивать систему после завершения проекта без вовлечения вендора или интегратора.
Следствием непродуманных доработок может стать снижение производительности. При разработке коробочной функциональности вендор учитывает архитектурные особенности решения и обеспечивает целостный подход к проектированию. Адаптированное решение со временем может лишиться целостности в архитектуре: новые требования бизнеса часто появляются спонтанно, а инкрементальная реализация изменений может негативно влиять на масштабируемость системы, смежную функциональность и в конечном счете на производительность.
Можно столкнуться со сложностями при обновлениях. Доработки, как правило, строятся вокруг базовой функциональности. При выпуске вендором новых версий продукта она меняется, и в доработанных функциях могут происходить сбои. Особенно опасно, если такие ошибки затрагивают критичные бизнес-операции. Например, приводят к простую склада или производственной линии.
Эксплуатировать глубоко кастомизированные системы непросто. Пользовательский путь в них часто оказывается непродуманным, а выполненные настройки и доработки сложны для понимания и управления.
Компании стараются избегать разрастания бюджетов при внедрении через поэтапную реализацию ключевых требований бизнеса, при этом дополнительные доработки рассматриваются отдельно.
При выборе универсальной системы может казаться, что базовой функциональности достаточно, но потом нередко выясняются нюансы, связанные со спецификой отрасли или конкретного бизнеса, которые влияют на объем проекта. По мере появления новых бизнес-требований затраты начинают непредсказуемо расти, возникают трудности с планированием финансовых потоков и оценкой ожидаемых от проекта эффектов. Снизить такие риски можно за счет использования концепции MVP в противовес попыткам делать оценки на базе простых демонстраций возможностей системы.
Особенно высокие риски кроются в интеграции. Кастомизированные и доработанные системы далеко не всегда позволяют интегрироваться по API — может потребоваться разработка специальных инструментов. Например, на одном из проектов в крупном агрохолдинге нам пришлось создать отдельный инструмент на базе SQL для трансформации данных в необходимый формат.
Не стоит забывать, что у любого коробочного решения есть предел адаптируемости, поэтому бизнесу придется подстраиваться под логику платформы. Это может быть плюсом, если внедряемая система привносит лучшие отраслевые практики и повышает зрелость внутренних процессов. Например, в сегменте интегрированного бизнес-планирования (IBP) есть решения, предлагающие типовой процесс планирования продаж и операций. В иных случаях адаптация бизнеса под «коробку» не гарантирует прирост операционной эффективности. Хорошая практика при внедрении коробочных решений — правило 20/80, когда на 80% для покрытия требований используется стандартная функциональность и только в 20% требования реализуются через доработки.
Алгоритм выбора
Цена ошибки при выборе платформы для автоматизации — снижение ROI проекта и операционной эффективности бизнеса. Хотя тендерные механизмы кажутся отработанной процедурой с понятным алгоритмом выбора, в каждом шаге есть значимые детали.
Изучая опыт других компаний, работающих в том же сегменте, нужно не только посмотреть, какие платформы они использовали для схожих задач, но и узнать, каких финансовых эффектов достигли: снизилась ли трудоемкость рутинных операций, повысилась ли маржинальность производственного процесса, выросла ли выручка. Можно организовать референсы или запросить информацию у вендоров.
При формировании технического задания, помимо описания ключевых функциональных требований, необходимо запросить оценку второстепенных требований для закладывания бюджета на доработки, указать возможный объем MVP, детально расписать нефункциональные требования к масштабируемости и производительности. Если у компании есть сомнения в том, насколько ее бизнес-процессы отличаются от стандартных, стоит выбрать путь пилотирования (MVP) для того, чтобы на практике оценить покрытие и более точно сформировать бюджет на внедрение и тиражирование решения.
Некачественное техническое задание имеет следующие признаки: искусственная ориентация на узкий класс систем (ТЗ повторяет документацию к одному из решений), расплывчатые формулировки требований, отсутствие четко измеримых бизнес-эффектов, которые необходимо получить по результатам проекта.
Составление документации по ТЗ можно поручить собственным системным или бизнес-аналитикам, но, когда техническое задание готовится внутри компании, служба с наибольшим влиянием на топ-менеджмент может продвигать свои интересы в ущерб другим направлениям. Привлечение внешнего исполнителя помогает нивелировать этот эффект. На него не давит контекст взаимодействия между подразделениями, поэтому он будет более объективен при фиксации требований.
При сборе коммерческих предложений от нескольких вендоров или интеграторов, стоит уделить внимание как тем, которые предлагают универсальные платформы, так и разработчикам отраслевых решений. Зачастую в тендерах поставщикам отводится
При выборе следует ориентироваться не только на стоимость. Предложивший наименьшую цену поставщик может недооценить объем работ, что будет нести риски для проекта. Не менее важные критерии — степень покрытия функциональных требований и наличие референсов в конкретной отрасли. В скоринг-таблицах для оценки подрядчиков также рекомендуется учитывать гибкость в вопросах расширения лицензий и объема, размер команды и финансовую благонадежность компании.
Если предлагается low-code или no-code-платформа с микросервисной архитектурой, имеет смысл уточнить, выполнялись ли на ней похожие проекты. С одной стороны, такие платформы дают широкие возможности для создания различных решений, с другой — реализация проекта может занять значительное время и нести определенные риски. Например, можно столкнуться с некорректно спроектированной архитектурой.
При наличии на рынке готового отраслевого решения, хорошо покрывающего целевые бизнес-процессы, не стоит оставлять его без внимания. Внедрение такого продукта может оказаться более быстрым и менее рискованным.
Рекомендации из опыта IBS
В начале проекта бизнес, как показывает практика, не всегда готов подробно сформулировать все требования. В таких случаях мы осознанно идем на применение спринтового подхода без формирования массивного проектного решения. Детализация требований, достаточная для проектирования всей архитектуры, обычно появляется после MVP. Еще один вариант — проведение развернутого предпроектного обследования с участием интегратора.
Кроме того, сложности могут быть связаны с недостатком у проектной команды компетенций и понимания отраслевых особенностей. В проектах с высоким уровнем отраслевой специфики, например, при внедрении интегрированного планирования, мы стремимся задействовать отраслевых экспертов-методологов. К примеру, важный вклад в проект IBS для крупного агрохолдинга вносит бизнес-архитектор с опытом работы в этой сфере, а за проект по внедрению системы автозаказа у федерального ритейлера отвечает специалист, имеющий опыт работы в торговле со стороны бизнеса.
При подготовке к тендеру ИТ-директору рекомендуется тесно поработать со спонсором проекта и руководителями служб и направлений, которых может затронуть проект, чтобы выровняться по ожидаемым бизнес-эффектам и понять потенциальный ROI помимо стандартной оценки бюджета. Спонсор проекта должен подтвердить корректную постановку целей и приоритизацию требований, обсудить возможные риски и принять совместно с ИТ-директором ответственность за выбор подхода к реализации проекта.
Источник: Наталья Морозова, руководитель направления «Управление цепями поставок» группы компаний IBS
