«Коробка» или заказная разработка: взвешенный выбор

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

О том, на что нужно ориентироваться при принятии подобного решения, рассказала руководитель направления заказной разработки ГК «КОРУС Консалтинг» Елена Никитина.

• Первый фактор — назначение будущей системы. Если это digital-продукт, вокруг которого будет строиться бизнес, систему лучше разрабатывать с нуля. При этом важно, чтобы права на ИТ-решение принадлежали вашей компании. В таких случаях создание и поддержка продукта в идеале должны осуществляться по модели in-house — это дает вам возможность самостоятельно управлять развитием ПО и не зависеть от вендора или подрядчика. Для работы с такими системами критично важно сконцентрировать экспертизу внутри компании.

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

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

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

• Четвертый фактор — наличие и масштабы партнерской сети вендора «коробочного» решения. Желательно выбирать системы тех вендоров, чья партнерская сеть достаточно развита. В этом случае вероятность, что продукт будет регулярно обновляться и дорабатываться в соответствии с вашими запросами, гораздо выше. Если же правами на внедрение и доработку обладает только вендор, у вас возникнет сильная зависимость от него; риски потери системы кратно возрастут, а доработка решения потребует много времени.
  

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

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

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

Отметим еще несколько важных аспектов, которые следует учитывать при выборе между «коробкой» и заказной разработкой.

Готовое решение обладает строгими техническими требованиями, поэтому его внедрение иногда влечет за собой дополнительные траты. Часто бывает, что ИТ-ландшафт компании не предусматривает нужный технологический стек и не содержит ПО, необходимое для запуска продукта. Например, некоторые решения могут работать только с определенными ОС или программной платформой. Для решения этой проблемы внедряют дополнительные программы и оборудование. Это может понадобиться и при имплементации кастомного решения, но его требования способны подстраиваться под особенности уже существующих в компании ИТ-систем. Основные проблемы, которые возникают при внедрении кастомных решений, связаны с организацией взаимодействия компании с командой проекта. Например, если изначально представители заказчика не подняли вопросы о масштабируемости решения, не проработали нефункциональные требования (режим доступности, нагрузку, количество данных, способных храниться в системе), может оказаться, что возможности ИТ-инфраструктуры бизнеса или решения не позволяют использовать созданный продукт в том режиме, в котором нужно или может потребоваться бизнесу в будущем.

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