Битва за разработку: инвестировать в решение вендора или собрать in-house-команду?

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

В этом материале Юлия Пивоварова, операционный директор Just AI, расскажет об особенностях каждого из подходов — in-house-разработки и работы с вендором, а также прольет свет на третью концепцию, которая сейчас набирает популярность на рынке.

Для начала разберемся в понятиях.

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

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

Рассмотрим несколько критериев между привлечением вендора и in-house-разработкой.

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

На рынке есть примеры компаний, которым удалось нарастить внутреннюю экспертизу и собрать сильные команды разработчиков, — X5 Tech, СберТех, MTS AI. Но нужно учитывать, что с момента формирования команды до момента, когда она представит конкурентоспособный продукт, могут пройти годы. Безусловно, такая стратегия работает на перспективу, но не каждая компания способна годами содержать дорогостоящих технических специалистов.

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

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

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

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

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

Я выделяю восемь критериев:

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

Под более простыми инструментами подразумеваются no-code-платформы. Они становятся все более распространенными благодаря тому, что позволяют людям, не имеющим навыков программирования, создавать приложения. Эти платформы обычно используют интерфейсы drag-and-drop (способ оперирования элементами интерфейса при помощи мыши или сенсорного экрана) и готовые компоненты, позволяющие быстро и легко «собирать» решения.

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

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

Многие платформы no-code интегрируются с другими инструментами и сервисами, такими как CRM-системы, платформы автоматизации маркетинга и инструменты аналитики.

Минусы no-code-платформ. Ограниченная кастомизация. Некоторые специфичные или сложные требования к продукту не могут быть удовлетворены с помощью готовых компонентов платформы.

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

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

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

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

В рубрике «Блоги компаний» вы становитесь автором и делитесь личным опытом работы с клиентами, партнерами, рынком.

О чем можно рассказать?

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

Все подробности о формате, оформлении и возможных темах статей — в телеграм-боте @bs_community_bot.