В прошлом году мы заходили в проект дистрибьютора на 42 сотрудника. Продажи жили в amoCRM, оплаты - в 1С, производство - в чатах, KPI появлялись только к пятнице после ручной сводки. Пока цифра собирается руками, руководитель управляет прошлой неделей, а не компанией.
Я бы не стал демонизировать Excel. Для команды в 5-10 человек это часто нормальный старт. Проблема начинается в тот момент, когда ответ на простой вопрос требует звонков в отделы и сверки трех версий файла.
Проблема видна по задержке ответа, а не по числу таблиц
На одном производстве заявки, закупки, деньги и загрузка жили в 7 таблицах. Еженедельный отчет собирали 3 человека, каждый тратил по 6-8 часов, а маржинальность по заказам расходилась на 10-15% из-за разных версий файла. Руководитель спрашивал, что с оплатами и отгрузками, и получал ответ только на следующий день.
Смотрите: Excel ломается не тогда, когда файлов стало много. Он перестает работать как система в тот момент, когда одна и та же цифра живет в нескольких местах и зависит от человека, который последним ее правил.
Пора выходить из таблиц, если:
- статус заказа есть в CRM, чате и файле одновременно;
- KPI считают руками раз в неделю или к закрытию месяца;
- есть один сотрудник, который «знает правильные цифры»;
- отделы спорят о данных, а не о том, что делать дальше;
- на сверку уходит больше 30 минут.
Сначала маршрут данных, потом выбор системы
Самая дорогая ошибка - покупать CRM или ERP до того, как вы описали путь данных. Кто создает заявку, кто меняет статус, где появляется счет, когда заказ уходит в работу, из чего считается просрочка и маржа. Если эта схема не собрана, вы просто переносите бардак в новый интерфейс.
Обычно хватает 5-7 сценариев. Лид - заказ, заказ - производство, счет - оплата, производство - отгрузка, сервис - закрытие. На проекте в металлообработке такая схема за 2 недели показала 4 ручных переноса одних и тех же данных между Bitrix24, 1С и внутренним кабинетом. После пересборки процесса ручные операции сократились на 60%, а запуск заказа в работу ушел с 2 дней до 4 часов.
Если у процесса нет владельца, система только быстрее покажет, где у вас дыра в управлении.
Частая ошибка - сначала купить лицензию и начать настройку. Я обычно иду в обратном порядке: сначала фиксирую статусы, владельцев этапов и одно место, где каждая цифра считается основной.
Работает не "одна большая программа", а связанный контур
Для малого и среднего бизнеса я чаще собираю не монолит, а связку систем. CRM ведет входящий поток, 1С считает документы и деньги, workflow держит статусы и согласования, BI показывает руководителю картину без ручной сборки. Если логика сложнее коробки, мы добавляем интеграционный слой на Laravel 11 или Node.js 20 + NestJS. Этого хватает в большинстве проектов.
| Подход | Когда подходит | Риск |
|---|---|---|
| Готовая CRM | порядок в лидах и сделках | упрется в нетиповые процессы |
| Учетная система или ERP | склад, закупки, себестоимость | внедрение растянется |
| BPM/workflow | сложные согласования | без правил станет еще одной системой |
| Кастомный слой на API | много интеграций и своя логика | выше стартовый бюджет |
У b2b-компании из поставок оборудования мы оставили amoCRM, учет перевели на 1С:УНФ, отчеты вывели в Metabase, а интеграции собрали через API и webhooks. За 6 недель статус заказа стал виден в одном окне, а потерянные задачи упали с 12-15 в месяц до 1-2.
Если счет = оплачен
-> заказ получает статус "к запуску"
-> создается задача в производстве
-> резервируется материал
-> KPI "оплаченные заказы в работе" обновляется
KPI нужны для раннего сигнала
Я видел десятки дашбордов, где метрик много, а пользы мало. В первом релизе достаточно 4-6 показателей: просрочки, валовая маржа, дебиторка, время цикла заказа, загрузка узкого участка. Если цифра обновляется только к пятнице, она уже опоздала.
На одном проекте мы сократили набор метрик с 27 до 5 рабочих KPI. Скорость реакции на проблемы ушла с недели до одного дня. Самым полезным оказался не оборот, а время цикла - по нему раньше всего видно, где поток начинает тормозить.
Где автоматизация срывается
У нас был неудачный проект в сервисной компании. Там решили сразу закрыть продажи, склад, финансы и заявки в одной большой системе. Через 4 месяца сотрудники все равно вели параллельные таблицы, потому что SLA не были описаны, маршруты заявок каждый отдел понимал по-своему, а ответственность пересекалась.
Мы откатились назад и пошли через пилот. Взяли один тип заявок, убрали дубли данных, обучили людей новому процессу, а не только кнопкам, и 8 недель смотрели на 5 метрик. После этого доля нарушений SLA снизилась с 18% до 4%.
Если запускать аккуратно, я делаю так:
- беру один поток или один отдел;
- фиксирую владельца процесса;
- убираю дубли, а не маскирую их интеграциями;
- даю пилоту 4-8 недель до масштабирования.
В ближайшие 6-12 месяцев выиграют не компании с самой дорогой ERP, а те, у кого руководитель видит состояние бизнеса за 5 минут без звонков и сверок. Если сейчас это невозможно, у вас уже не проблема учета, а задержка управления.
