Кастом или коробка? Что выбрать для отраслевого ПО

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

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

Почему многим бизнесам кастомный продукт кажется оправданным решением

Собственник бизнеса часто сталкивается с искажением: думает, что у него совершенно уникальная логика бизнес-процессов, и все не так, как у других. Значит, универсальное и типовое точно не подойдет! Всегда хочется изобрести велосипед с новым моторчиком. Или — того хуже — сделать продукт «как у…» (поставьте здесь название любого популярного решения), но только чтобы кнопки были другой формы. Я, конечно, утрирую, но за годы работы в IT сталкивался с разными запросами фаундеров. Типичный звучит как «хотим скопировать того-то, но только чтобы было удобно для нас».

Другой аргумент — сотрудники не хотят работать в непонятной «коробке», будет сложно и дорого их обучать, дизайн интерфейса какой-то устаревший. А вот если сделаем свое, то учтем там все что душе угодно: и специфику нашего бизнеса, и фичи интересные добавим, которые кажется, что точно должны быть, и UX/UI будет как у цифровых гигантов.

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

Два кейса про кастомное решение

Не так давно мы делали проект для одной крупной IT-компании из сегмента бизнес-тревел. Раньше для отдела поддержки использовали коробочное решение от американского сервиса Intercom. Но коробка перестает справляться, когда у тебя 500 операторов в режиме реального времени помогают людям разруливать дела с командировками: бронируют отели, покупают или меняют билеты, выстраивают логистику. А еще не забываем про риски работы с иностранными вендорами.

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

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

Не пытайтесь «допилить» коробку под себя — не создавайте монстра!

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

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

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

Почему я за то, чтобы всегда начинать с коробки

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

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

Что учесть, прежде чем идти в кастомную разработку

Если становится понятно, что без своего решения точно никак, советую держать в голове, что будет долго, дорого и иногда немного больно:

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

И все-таки: когда нужно кастомное решение?

Пройдитесь по этому чек-листу. Если все совпало, вперед в кастомную разработку!

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

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