Компании постоянно покупают новые сервисы: CRM, таск-трекеры, системы учёта, облачные таблицы, конструкторы автоматизаций. На старте это выглядит логично — зачем разрабатывать что-то своё, если можно платить 20–100 долларов в месяц и получить готовый продукт?
Проблема начинается позже. Компания понимает, что половина функций ей не нужна, а действительно важный рабочий процесс всё равно приходится вести в Excel, Telegram, почте или отдельной таблице.
Мы поговорили с разработчиком о том:
Содержание
В большинстве случаев свой сервис действительно не нужен.
Если компания хочет вести сделки, хранить контакты клиентов, ставить задачи, вести бухгалтерию, управлять проектами или отправлять рассылки — то почти наверняка дешевле и быстрее использовать готовый продукт.
Разработка собственного решения становится интересной не тогда, когда компании нужна «своя CRM». Она становится интересной, когда внутри бизнеса существует повторяющийся специфический процесс, который готовые системы закрывают плохо.
Например, компания работает не просто с заказами. У каждого заказа может быть несколько этапов согласования, специфическая проверка совместимости, резервирование товара, подбор допустимых замен, несколько участников, история изменений и собственная логика статусов.
В обычной CRM всё это начинают изображать через дополнительные поля, комментарии, теги и таблицы. Формально CRM используется. Фактически настоящий бизнес-процесс существует где-то рядом с ней.
Иногда именно так и нужно сделать. Я бы вообще начинал не с разработки, а с вопроса:
можно ли решить проблему нормальной настройкой существующего инструмента?
Если можно — это почти всегда предпочтительнее.
Проблема начинается, когда CRM превращается в конструктор, которым пытаются изобразить совершенно другой тип системы.
Например, компании нужно управлять комплектацией объекта. Есть объект, помещения, спецификация, несколько версий спецификации, совместимые позиции, допустимые аналоги, остатки на складах, резерв, подтверждение замен и этапы монтажа.
Можно попытаться представить всё это как «сделку». Но в какой-то момент становится очевидно, что сделка — просто контейнер, внутрь которого пытаются запихнуть совершенно другую предметную область. И тогда каждый новый сценарий требует ещё одного поля, робота, таблицы или внешнего скрипта.
Это один из признаков. Но сам по себе костыль ещё ничего не означает. У любого бизнеса есть Excel, ручные операции и временные решения.
Гораздо важнее другое:
насколько эти костыли находятся в центре ключевого рабочего процесса.
Например, если раз в месяц менеджер вручную переносит небольшой отчёт из одной системы в другую — делать для этого отдельный продукт бессмысленно.
А если ежедневно пять сотрудников:
то здесь уже появляется хороший кандидат на автоматизацию.
Очень важна. Разработка программного продукта экономически оправдывается повторением.
Если операция выполняется один раз — проще сделать её вручную. Если она выполняется тысячу раз, даже небольшая оптимизация начинает давать эффект.
Поэтому хороший кандидат для micro-SaaS обычно выглядит примерно так:
«Каждый день сотрудники делают примерно одинаковую последовательность действий».
Например: принимают заказ, проверяют данные, сопоставляют позиции, уточняют исключения, согласовывают изменения, передают заказ дальше, отслеживают статус. При этом сами данные меняются, но логика процесса остаётся примерно одинаковой. Вот это очень важный момент.
Граница достаточно условная. Но обычно micro-SaaS — это относительно небольшой продукт, который решает одну узкую задачу очень хорошо.
Например, не «система управления компанией», а «система согласования замен товаров в заказах». Не «CRM для строительной компании», а «система подготовки и согласования комплектации объекта».
Чем уже задача, тем проще понять требования, запустить первую версию, обучить сотрудников, проверить экономический эффект и развивать продукт постепенно.
Проблемы часто начинаются именно тогда, когда компания сразу хочет создать «собственную ERP». Это огромный проект. А автоматизация одного конкретного процесса может быть вполне реалистичной задачей.
Нет. Excel — отличный инструмент. Telegram — тоже.
Проблема возникает, когда они начинают выполнять роль базы данных и системы управления процессом одновременно.
Например:
CRM → Excel → Telegram → учётная система → снова Excel → письмо клиенту.
Чем больше переходов между системами, тем выше вероятность потерять изменение, использовать старую версию, дважды внести одну информацию, забыть обновить статус, неправильно скопировать данные или не заметить изменение коллеги.
В таких процессах автоматизация часто даёт эффект не потому, что сотрудник начинает работать в десять раз быстрее. Главный эффект может быть просто в том, что появляется единая версия данных.
Очень показательные вопросы:
Если такие вопросы возникают постоянно, проблема часто не в сотрудниках. Проблема в том, что система не показывает состояние процесса.
Хорошее программное решение должно позволять открыть объект и сразу увидеть текущее состояние, ответственного, проблемные места, историю изменений и следующее действие — без поиска сообщений за последние три дня.
Не обязательно. Иногда переплата за готовый SaaS всё равно намного дешевле разработки.
Допустим, система стоит 100 долларов в месяц. Даже если компания использует только небольшую часть возможностей, это всего 1200 долларов в год. Разработка собственного продукта легко может стоить значительно больше.
Поэтому аргумент «Мы используем только 10% CRM» сам по себе слабый.
Гораздо интереснее ситуация:
«Мы используем CRM, но ключевой процесс всё равно ведём отдельно».
То есть компания одновременно платит за SaaS, ведёт Excel, использует чат, содержит дополнительные интеграции и тратит время сотрудников на ручную синхронизацию. Тогда нужно считать уже полную стоимость процесса.
Потому что автоматизация не всегда должна экономить рабочее время. Иногда она должна предотвращать ошибки.
Представим комплект оборудования из 30 позиций. Двадцать девять позиций выбраны правильно. Одна несовместима. Заказ привезли на объект, и только во время монтажа выяснилось, что элемент не подходит.
Последствия могут быть намного дороже стоимости самого товара: повторная доставка, простой монтажников, перенос сроков, возврат, повторное согласование, недовольный клиент.
Если подобные ошибки можно выявлять автоматически до оформления заказа, собственная система может быть оправдана даже при относительно небольшом количестве операций.
Конечно. Но есть интересный парадокс. Компании часто говорят: «У нас практически каждый заказ индивидуальный». После подробного разбора выясняется, что индивидуальных сценариев на самом деле десять или пятнадцать. Они просто не формализованы.
Например:
Если исключения повторяются, их можно превратить в нормальные сценарии системы. И тогда сотрудник работает не с хаосом, а с очередью конкретных ситуаций, которые требуют решения.
Можно. Но это рискованно. Пока компания сама не понимает, как должна работать, программировать этот процесс рано.
Сегодня кажется, что заказ проходит пять стадий. Через месяц выясняется, что нужно восемь. Через два месяца меняется схема работы. В итоге разработчик постоянно переделывает систему не потому, что плохо написал код, а потому что сам бизнес ещё ищет процесс.
Поэтому собственный micro-SaaS особенно хорошо подходит компаниям, где уже можно сказать:
«Мы делаем это примерно так уже год. Процесс понятен. Проблема в инструментах».
Это намного более зрелая ситуация для разработки.
Иногда в компании постепенно появляется человек, основная задача которого — переносить информацию между системами. Например:
Это очень интересный сигнал. Потому что фактически компания уже создала систему. Просто роль программного обеспечения выполняет человек.
Причём этот сотрудник может быть очень ценным именно потому, что только он понимает все нюансы процесса. И здесь появляется ещё один риск: если человек уходит, вместе с ним исчезает часть операционной логики бизнеса.
Хорошая автоматизация позволяет часть этих правил вынести из головы конкретного сотрудника в систему.
Для многих задач их вполне достаточно. Например: пришла заявка → создать контакт → отправить уведомление → записать данные в таблицу. Такую автоматизацию совершенно необязательно разрабатывать с нуля.
Но low-code-интеграции становятся сложными, когда появляется много состояний. Например:
Это уже не просто передача данных между сервисами. Это бизнес-логика. И чем больше такой логики, тем труднее поддерживать цепочку из десятков автоматизаций.
Нет. Это значит только то, что процесс стоит исследовать.
Следующий вопрос:
какую экономическую проблему должна решить система?
Очень плохая постановка:
«Хотим собственный портал».
Намного лучше:
Когда проблема сформулирована конкретно, можно обсуждать решение. Иногда окажется, что разработка вообще не нужна.
В первую очередь редкие. Если ситуация возникает несколько раз в год, проще оставить ручную обработку.
Также осторожно стоит относиться к процессам, которые:
Иногда компания хочет автоматизировать плохой процесс — то есть вместо того, чтобы убрать лишние действия, она пытается их запрограммировать. Это обычно дорогой путь. Сначала стоит спросить:
а этот этап вообще нужен?
Попытка автоматизировать всё сразу.
Допустим, компания занимается поставками. В техническое задание попадает: CRM, склад, каталог, бухгалтерия, документы, аналитика, личный кабинет, мобильное приложение, логистика, уведомления, интеграция с сайтом.
Через некоторое время проект превращается в разработку полноценной ERP. Это дорого, долго и рискованно.
Гораздо практичнее найти одно узкое место. Например:
согласование замен в заказах.
И сделать небольшой продукт вокруг него. Если система приносит пользу — расширять.
Скучным. Это хороший признак.
Не нужен огромный dashboard с двадцатью графиками. Первый продукт может содержать всего несколько вещей:
Главное — чтобы он убирал конкретную операционную проблему.
Допустим, компания поставляет сантехническое оборудование для строительных объектов. Сейчас процесс выглядит так:
Монтажник → WhatsApp → менеджер → Excel → склад → снова менеджер → монтажник.
Монтажник присылает список. Менеджер сопоставляет позиции, проверяет наличие, ищет аналоги, уточняет совместимость, собирает новый файл и отправляет его обратно. После каждого изменения появляется новая версия.
Вместо создания огромной CRM можно сделать небольшой сервис. В нём будет:
Например: «Квартира, ул. Центральная»
Санузел, кухня, котельная.
Все необходимые позиции.
Совместимость, наличие, обязательные комплектующие.
Система показывает допустимый аналог.
Монтажник или заказчик подтверждает замену.
Можно увидеть, кто изменил позицию, когда, почему и какая версия актуальна.
Вот это уже хороший пример micro-SaaS. Он не пытается заменить всю инфраструктуру компании. Он закрывает один дорогой и неудобный процесс.
Почти наверняка. И это нормально. Главное — чтобы система развивалась вокруг реальной работы, а не вокруг списка пожеланий.
Например, сначала появляется управление спецификацией. Потом становится понятно, что полезно добавить резервирование. Потом — очередь проблемных позиций. Потом — уведомления клиенту. Так продукт развивается естественно.
Если единственная причина разработки звучит примерно так:
«Хотим, чтобы всё было своё».
Собственная разработка — не преимущество сама по себе. У неё есть цена: проектировать, разрабатывать, тестировать, обновлять, делать резервные копии, следить за безопасностью, поддерживать интеграции.
Поэтому вопрос должен звучать не «Можем ли мы сделать собственный сервис?», а:
«Какую дорогую проблему он будет решать?»
Точно — редко. Но приблизительно — обязательно.
Можно посмотреть:
Например, 6 сотрудников.
Допустим, суммарно 15 часов в неделю.
Это уже даёт базовую цифру. Но нужно учитывать и другое: количество ошибок, стоимость исправления ошибки, количество задержек, влияние на скорость обработки заказов, нагрузку на менеджеров, зависимость от отдельных сотрудников.
Иногда экономия времени оказывается не самым важным фактором.
Да, и это один из самых интересных сценариев. Если компания решает специфическую проблему своей отрасли, существует вероятность, что такая же проблема есть у других компаний.
Например, сначала система создаётся для собственных процессов. Потом выясняется, что аналогично работают конкуренты, поставщики, партнёры, компании из соседнего сегмента. Тогда внутренний продукт потенциально можно превратить в самостоятельный SaaS.
Но я бы не начинал разработку сразу с такой целью. Сначала система должна доказать полезность хотя бы внутри одной компании.
Причём преимущество такого подхода в том, что продукт создаётся не из фантазии. У него уже есть реальный пользователь, реальные данные, реальный процесс и реальные исключения. Это намного лучше, чем сначала придумать SaaS, а потом искать, кому он нужен.
Я бы задал семь вопросов.
Если да — идём дальше.
Чем больше передач информации, тем интереснее задача.
Например: Excel + мессенджер + CRM + учётная система.
Это один из самых очевидных кандидатов на автоматизацию.
Если да, автоматизация потенциально ценнее.
Если исключения повторяются, их можно формализовать.
Если да, его уже можно пробовать переносить в программную систему.
Если на большинство вопросов ответ «да», процесс как минимум заслуживает анализа.
Хороший вопрос. Мне кажется, разработчик должен уметь сказать:
Если любое описание проблемы заканчивается предложением разработать собственную платформу — это тревожный сигнал.
Разработка должна быть последним инструментом, а не первым. Сначала нужно понять процесс. Потом убрать лишние действия. Потом проверить готовые решения. Потом проверить интеграции и low-code. И только если всё это не закрывает ключевую проблему, имеет смысл обсуждать собственный продукт.
Собственный небольшой сервис может быть оправдан, если одновременно выполняется несколько условий:
При этом наличие этих признаков ещё не означает, что нужно немедленно начинать разработку. Иногда правильным решением окажется настройка существующей CRM. Иногда — небольшая интеграция. Иногда — изменение самого процесса.
Но если компания годами держит ключевую операционную логику в таблицах, чатах и голове нескольких сотрудников, имеет смысл хотя бы проверить, не стал ли этот процесс достаточно зрелым для собственного небольшого продукта.
Потому что micro-SaaS — это не обязательно новый стартап и не обязательно огромная система. Иногда это просто один хорошо автоматизированный бизнес-процесс, который раньше держался на Excel, переписке и памяти сотрудников.
Нужен похожий контур — обсудим.
SaaS или собственная система · Laravel vs Битрикс и OpenCart · как выбрать Laravel-разработчика · micro SaaS для мебельных производств · B2B-портал с интеграцией 1С