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

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

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

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

Автоматизация диктует правила

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

Однако тренды развития рынка ПО указывают на обратное. 15 лет назад 90 % задач, вплоть до создания сайта, решались разработкой с нуля. Сейчас появилось достаточно low-code и no-code (или zero-code) приложений, которые автоматизируют типовые процессы и задачи компаний. Приставка no- (или zero-) означает, что приложение базово не требует дополнительной разработки (как, например, конструктор сайтов Tilda), в то время как приставка low- говорит о том, что будет достаточно лишь минимального участия разработчиков.

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

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

Плюсы и минусы готового IT-решения

Сначала разберёмся, какими преимуществами обладает коробочное решение.

• Относительно низкая стоимость на старте. В среднем цена коробки не кусается: такое ПО заточено под массовые продажи и достигает маржинальности за счёт их объёма. Конечно, есть на рынке продукты с лицензиями за сотни тысяч и миллионы рублей в год, но это скорее исключения. Вероятнее всего, лицензия обойдётся вам в 30–40 тысяч рублей в год. Есть на рынке и варианты с бесплатной базовой версией, например Community Edition PIM-системы Pimcore.

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

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

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

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

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

• Недостаточная или избыточная функциональность. Стопроцентного совпадения потребностей бизнеса и функциональности коробки не происходит почти никогда. Могут отсутствовать важные функции, при этом фичи, которые вы не используете в работе, будут съедать ресурсы и замедлять процессы. Если простой адаптации недостаточно, придётся доработать софт в соответствии с требованиями, диктуемыми конкретными задачами. Но помните, что на практике доработка иногда оказывается такой же ресурсозатратной, как разработка с нуля.

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

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

Плюсы и минусы разработки с нуля

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

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

• Простое масштабирование. Заказывая разработку с нуля, вы думаете о развитии продукта и закладываете масштабирование уже на уровне ТЗ. По мере роста компании (продукта, направления) вы сможете добавлять новые функции без потери эффективности.

• Исключительные права на софт. Вы закрепляете за собой права на интеллектуальную собственность — новый IT-продукт — и можете использовать её по своему усмотрению, вплоть до монетизации посредством продажи или сдачи в аренду.

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

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

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

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

• корпорациям для автоматизации сложных или уникальных процессов;

• небольшим компаниям, оперирующим в узкоспециальных отраслях экономики.

Резюмируем плюсы и минусы каждого из подходов

‍

‍

Как понять, какой вариант подходит именно под ваши задачи?

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

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

Первый критерий: есть ли на рынке продукт, который полностью покрывает критичные для вас бизнес-функции?

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

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

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

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

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

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

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

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

Второй критерий: как вы планируете менять продукт и бизнес-процессы в дальнейшем?

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

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

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

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

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

Третий путь: что делать, если времени на разработку нет, а коробочное решение не подходит?

С однозначными случаями всё понятно. Но как быть, если продукт уникален, ресурсы ограниченны, а запускаться на рынке нужно как можно скорее?

Коробочное решение не подойдёт, оно для вас слишком типовое. Уникальная разработка займёт слишком много времени. Но выход есть: обратитесь к Lean-подходу к разработке.

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

А уже когда вы проверите гипотезу, можно будет в спокойном режиме совершенствовать софт и вводить новые фичи.

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

Резюмируем

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

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

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

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

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

• Если времени на разработку нет, а коробочное ПО точно не ваш вариант — вам подойдёт Lean-подход. Подумайте о том, как запустить MVP на готовых продуктах, постепенно дорабатывая его. Такой подход сэкономит время и позволит сразу приступить к тестированию гипотез и доработке софта с учётом реальных изменений как в стратегии продукта, так и на рынке в целом.

‍