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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К решению, создаваемому с нуля, требования безопасности составляет заказчик, и исполнитель их учитывает при разработке продукта. Но следует иметь в виду, что для подобных доработок часто привлекаются сторонние компании, специализирующиеся на ИБ.

По нашим наблюдениям, команды, занимающиеся кастомными решениями, как правило, фокусируются на разработке самой системы, а не на том, чтобы обеспечить безболезненный и быстрый ввод системы в эксплуатацию. Исполнители не всегда уделяют достаточно внимания процессам имплементации системы. Чтобы этого избежать, убедитесь, что команда продумала этап внедрения еще в начале обсуждения проекта. В идеале к этапам roll-out и hypercare должна подключиться та же команда, что разрабатывала решение.

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

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