Мы построили собственную IT-платформу для доставки воды. Почему готовые решения нам не подошли?

Своя CRM или готовая — что выбрать

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

Меня зовут Алексей Горбовский, я основатель Getwola. Сегодня доставка воды работает на собственной IT-платформе: клиент оформляет заказ на сайте или в приложении, система принимает оплату, назначает заказ курьеру, учитывает остатки и оборотную тару, считает мотивацию сотрудников, управляет программой лояльности, отправляет чеки и сервисные сообщения, собирает аналитику. К платформе подключены IP-телефония, платёжные системы, ОФД, «Честный знак» и сторонние сервисы. Начинали мы не с этого, а с желания доставлять воду быстрее остальных — вот как мы дошли до собственной технологии и чуть не потеряли из-за неё бизнес.

Как раньше в доставке воды принимали заказы?

Когда я анализировал рынок доставки воды, он уже был сформирован — игроков много, продукт понятный, экономика тоже примерно понятна. Возникал очевидный вопрос: зачем на таком рынке ещё одна компания?

Моя гипотеза была про сервис. Значительная часть рынка тогда всё ещё строилась вокруг телефона и колл-центра: чтобы заказать воду, клиент должен был позвонить тогда, когда компания была готова принять звонок. Колл-центр работал до 18:00 — после шести карета превращалась в тыкву. Если вода заканчивалась в пятницу вечером, а компания не работала по выходным, приходилось ждать понедельника — и не забыть позвонить, а доставку предлагали, например, «до обеда» или «после обеда».

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

Почему готовая CRM не подошла Getwola?

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

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

Как разработка превратилась в большое хозяйство?

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

У собственного ПО есть опасная особенность: если его можно менять, его хочется менять постоянно. Сначала мы автоматизировали движение заказа от клиента к водителю. Потом понадобился кабинет оператора и IP-телефония, CRM-функциональность, история заказов и работа с клиентской базой. Появилась админка для товаров, цен, акций и баннеров — правки видно на сайте и в приложении сразу, даже с телефона. Добавили программу лояльности, реферальную систему, автоматические сервисные сообщения, разные способы оплаты, чеки и интеграцию с ОФД.

Отдельно понадобился складской учёт многооборотной тары: полная бутыль уехала к клиенту, пустая вернулась — это тоже должно считаться автоматически (о том, сколько хранится бутыль и как её беречь дома, мы отдельно писали в статье «Как хранить бутыль 19 литров дома»). Затем появились дашборды с ключевыми показателями и автоматический расчёт мотивации: если зарплату оператора или водителя можно описать формулой, зачем каждый месяц считать её руками? Так бизнес-процессы постепенно превратились в код, и приложение, которое видит клиент, стало лишь небольшой видимой частью системы под капотом.

Что изменилось с «Честным знаком»?

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

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

Почему мы решили продавать платформу как SaaS?

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

Мы так и сделали. Это был поворот не туда.

Почему SaaS начал конкурировать с самой Getwola?

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

Но главный расход оказался не в деньгах. У команды разработки всегда ограниченный ресурс: если сегодня она делает функцию для будущего SaaS, значит, сегодня она не делает функцию для Getwola. Мы сознательно откладывали задачи своего бизнеса ради будущего программного продукта — план выглядел разумно, рынок с ним не согласился.

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

Почему Getwola поставила SaaS на паузу?

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

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

Своя IT-платформа или готовое решение: как решить для своего бизнеса?

За годы платформа сильно изменилась. Сегодня в ней клиентские веб- и мобильные приложения, ERP- и CRM-функциональность, приложение курьера, логистика, складской учёт, программа лояльности, автоматизация мотивации, e-commerce-инструменты, аналитика и множество интеграций. Клиент в каталоге Getwola выбирает воду WOLA или EVER (подробно о разнице — в статье «Артезианская или горная вода: в чём разница между WOLA и EVER»), а всё, что происходит после нажатия «Заказать», ведёт та самая платформа. Часть функциональности я как основатель уже даже не использую и не знаю в деталях — для системы, которая развивается около десяти лет, это, наверное, нормально.

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

Но есть исключение: если технология обслуживает не вспомогательный процесс, а саму бизнес-модель, готовый продукт может заставить компанию работать так, как умеет программа, вместо того чтобы заставить программу работать так, как нужно компании. Для нас скорость доставки изначально была не дополнительной функцией — на ней строилась идея Getwola. Это правило работает и в меньшем масштабе: например, компании, которая считает, сколько бутылей заказывать на команду каждую неделю (расчёт разобран в статье «Сколько воды нужно офису»), для учёта заявок обычно достаточно готовой CRM — автоматизировать там ради самой автоматизации незачем.

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

Частые вопросы

Своя IT-платформа или готовое решение — что выбрать бизнесу?

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

Почему Getwola не нашла готовую CRM для доставки воды?

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

Продаёт ли Getwola свою IT-платформу другим компаниям?

Несколько лет платформой по подписке пользовались около пяти партнёров из других регионов, и Getwola пробовала превратить её в полноценный SaaS-продукт. Активное развитие SaaS и масштабирование платформы как отдельного бизнеса сейчас поставлены на паузу — фокус разработки вернулся в сам сервис доставки Getwola.

Что входит в IT-платформу Getwola сегодня?

Клиентские веб- и мобильные приложения, ERP- и CRM-функциональность, приложение курьера, логистика, складской учёт с многооборотной тарой, программа лояльности, автоматизация мотивации сотрудников, e-commerce-инструменты, аналитика и интеграции с IP-телефонией, платёжными системами, ОФД и «Честным знаком».

Почему не стоит писать свою CRM просто потому, что хочется «своё»?

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