Кастомная разработка софта vs коробочное решение: как бизнесу сделать правильный выбор?

Опубликовано: 1.3.2023. Время на прочтение: 10 мин. Статья опубликована на Medium. Представьте, что вы открываете новое направление в бизнесе. Например, в дополнение к выпечке кексов на заказ собираетесь запустить онлайн-конструктор десертов с функцией срочной доставки.

Рынок изучен, бизнес-план составлен, и хочется скорее приступить к реализации.

Вы намерены упростить процесс оформления заказа - как для себя, так и для клиентов, - задействовав какое-нибудь автоматизирующее IT-решение. Но каким оно должно быть?

Подойдёт ли вам готовый IT-продукт с некоторыми доработками?

Или ни один из доступных вариантов в полной мере не соответствует тому, что вы хотите получить, и лучше заказать разработку собственного программного обеспечения с нуля? С такой дилеммой сталкиваются многие клиенты IT-компаний, в том числе и клиенты KT.Team. В этой статье

Андрей Путин, генеральный директор KT.Team, расскажет, как сделать выбор между кастомной разработкой ПО и приобретением готового IT-продукта.

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

Однако тренды развития рынка ПО указывают на обратное. 15 лет назад 90 % задач, вплоть до создания сайта, решались разработкой с нуля.

Сейчас появилось достаточно low-code и no-code (или zero-code) приложений, которые автоматизируют типовые процессы и задачи компаний.

Приставка no- (или zero-) означает, что приложение базово не требует дополнительной разработки (как, например, конструктор сайтов Tilda), в то время как приставка low- говорит о том, что будет достаточно лишь минимального участия разработчиков.

Писать с нуля типовой корпоративный сайт или стандартную CRM для отдела продаж - пустая трата ресурсов.

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

Создание интернет-магазина с обширным каталогом товаров выглядит более масштабной задачей.

Но готовые e-Commerce-платформы и здесь позволяют не изобретать велосипед.

Достаточно выбрать тему, кастомизировать дизайн, настроить интеграции с внешними сервисами (чаще - воспользоваться готовыми и проверенными интеграциями) - и запуститься в разы быстрее, чем при разработке с нуля.

Однако разработка с нуля - более дорогой и трудоёмкий вариант, чем приобретение готового продукта.

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

На практике стоимость разработки с нуля зачастую становится аргументом в пользу покупки готового продукта.

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

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

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

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

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

Если вам понадобится доработка второстепенных фич, это не потребует больших затрат ни временны́х, ни каких-либо других ресурсов, а готовый софт прекрасно справится со своей базовой задачей.

Чтобы провести эффективный анализ, оцените приоритетность бизнес-функций, которые должно выполнять ПО.

Некоторые компании ориентируются на процент покрытия набора нужных функций готовым решением, но даже при соотношении 90/10 неохваченной может остаться критически важная фича.

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

Она обратилась в KT.Team с проектом по внедрению готовой PIM-системы.

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

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

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

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

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

Нет смысла выбирать уже существующую платформу - её стандартная логика не даст вам никаких преимуществ перед конкурентами.

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

Продуктовым IT-компаниям, которые создают уникальный софт, стоит выбирать кастомную разработку в девяти случаях из десяти - вне зависимости от индустрии.

Так вы сможете самостоятельно управлять бэклогом и решать, как развивать продукт, делать его более клиентоориентированным и вносить изменения независимо от вендора.

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

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

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

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

Коробочное решение - идеальный вариант для стандартных задач и процессов.

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

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

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

Принимайте во внимание план и темпы внесения последующих изменений.

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

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

Если времени на разработку нет, а коробочное ПО точно не ваш вариант - вам подойдёт Lean-подход.

Подумайте о том, как запустить MVP на готовых продуктах, постепенно дорабатывая его.

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