3 в 1: почему LMS, ERP и CRM должны жить вместе

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

Мы пошли по-другому. Мы строим три продукта одновременно — LMS, ERP и CRM — и они делят одну базу данных. Не «интегрированы», а живут вместе. Это решение, которое вызывает у инвесторов вопросы. Я в этой статье объясняю, почему это правильно именно для сервисного бизнеса.

Сервисный бизнес — это не три отдельных контура

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

Сервисный бизнес устроен принципиально иначе. На точке химчистки мастер, клиент и операция стоят в одной комнате. Когда клиент протягивает кроссовки, происходит сразу всё: сотрудник применяет навык (LMS), создаётся заказ и резервируется химия (ERP), фиксируется визит клиента (CRM). Это одна транзакция, искусственно разделённая на три приложения только потому, что так удобно SaaS-провайдеру.

Каждый раз, когда между LMS, ERP и CRM есть API-граница — это шов. Шов рвётся, шов лагает, шов теряет данные. На заводе с этим можно жить. В сервисе — нет.

Конкретный пример: один сотрудник

Возьмём нового мастера, которого приняли на работу в SneakNFresh во вторник.

Понедельник. HR-менеджер заводит сотрудника в систему. Это карточка в ERP: ФИО, договор, ставка, точка. Одновременно эта же запись становится учеником в LMS — ему назначаются обязательные курсы: «Стандарты SneakNFresh», «Сервис на кассе», «Чистка замши».

Вторник-четверг. Мастер проходит курсы. Каждый завершённый тест поднимает его «уровень компетенций» — это поле в той же карточке. ERP видит: «уровень 1», значит можно ставить на смены и допускать к базовым операциям.

Пятница. Первая смена. ERP открывает доступ к кассе. Каждый заказ, который проходит через мастера, автоматически создаёт две вещи: транзакцию в финансах (ERP) и запись в карточке клиента (CRM). При этом CRM знает, что заказ принял этот конкретный мастер. Если клиент потом оставит отзыв «✦✦✦✦✦», бонусы пойдут именно ему.

Через месяц. Сотрудник прошёл курс «Реставрация кожи». LMS поднимает его уровень до 2. ERP автоматически расширяет список операций, на которые его можно назначить. CRM начинает предлагать его как «специалиста по коже» клиентам с премиум-обувью.

Вся эта цепочка — это один поток данных. В архитектуре с отдельными SaaS-продуктами она потребовала бы 4-5 интеграций, каждая из которых ломалась бы в первой же угловой ситуации.

Единая модель данных

Технически Кнопка устроена так. Postgres-база с общими сущностями: user, location, order, client, shift, course. Поверх — один API-слой с правами доступа по ролям. И три фронтенда: lms.knopka.tech, erp.knopka.tech, crm.knopka.tech. У каждого свой UI, свой роутинг, свой стейт. Но данные — общие.

Это даёт нам несколько вещей, которых не может дать «интегрированный набор продуктов»:

• Транзакционность. Сотрудник одной операцией завершает курс, поднимает уровень и открывает себе допуск к новой услуге. Не три API-вызова с возможной потерей на каждом — один SQL-коммит.
• Аналитика. Запрос «покажи мне выручку точки в разрезе уровня обучения сотрудников» в обычной архитектуре требует ETL-пайплайна. У нас — JOIN.
• UX. Клиент в CRM имеет ссылку «история чисток» — она тянет данные напрямую из order. Без задержки. Без рассинхронизации.

Почему так никто не делает

Делают, но не там, где мы смотрим. Salesforce делает. SAP делает. Все большие enterprise-системы делают, потому что они выросли из эпохи, когда «интеграции через API» ещё не существовали. Маленькие SaaS делают наоборот — каждый берёт свой кусок, потому что так быстрее выйти на рынок.

Сервисный бизнес сегмента 3-50 точек попал между двух стульев. SAP — слишком тяжело и дорого. Десять отдельных подписок — слишком много швов. Мы строим то, чего тут не было: единая платформа в средне-малом сегменте.

Сложности

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

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

Сервисный бизнес устроен не как чертёж — он устроен как живое существо. И софт под него должен быть таким же.