Заказная разработка или коробочное решение: о чем важно помнить при выборе

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

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

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

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

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

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

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

По теме. No-code в HR: как это работает и какому бизнесу подойдет

Проблемы гибкости

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

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

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

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

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

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

Проблемы сервисной поддержки

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

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

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

По теме. No-code, low-code и стандартное программирование: чем отличаются эти подходы и какой выбрать

Проблемы дублирования функционала

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

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

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

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

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

Проблемы оперативности

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

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

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

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