Как понять, что пора автоматизировать

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

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

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

Зачем автоматизация, если «люди и так справляются»

Люди справляются, пока объём маленький и все в одной комнате. Автоматизация нужна, когда одинаковое действие повторяется, цена ошибки растёт, а знания живут в головах. Система не заменяет квалификацию. Она снимает перекладывание данных, напоминает о сроке, не даёт забыть шаг, показывает узкое место без совещания.

Вторая причина — скорость найма. Если процесс только в Slack, вы покупаете зависимость от конкретных людей. Третья — связанные системы: сайт прислал заявку, менеджер забыл, склад не узнал, бухгалтерия выставила не то. Интеграция здесь не «модно», а способ не собирать цепочку руками.

Для разработчика автоматизация — это события, статусы, права, идемпотентность, а не «кнопка чтобы было удобно». Для заказчика — смена дисциплины: система требует заполнять поля, которые раньше можно было пропустить. Для компании-внедренца — сначала карта as-is, потом to-be, иначе вы кодируете вчерашний хаос в дорогой интерфейс.

Где обычно лежит экономия

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

Нужно ли автоматизировать именно сейчас

Пора смотреть серьёзно, если совпало несколько признаков. Операция повторяется десятки раз в неделю. Ошибка стоит денег, репутации или срыва срока. Два и больше человека должны видеть одно состояние объекта (заявка, заказ, объект, тикет). Вы не можете за 15 минут ответить «сколько сейчас в работе и где затык». Новый человек не может выполнить процесс по короткой инструкции — только «посидит с Петром».

Ещё не пора как проект, если процесс меняется каждую неделю, вы сами не договорились, какой статус правильный, и объём крошечный. Тогда хватит регламента: один файл, один ответственный, запрет копий. Автоматизация «на вырост, вдруг станем корпорацией» почти всегда мёртвая: поля никто не заполняет.

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

Нужна ли сразу большая платформа: нет. Нужен контур на один поток. Системы управления процессом — отдельный жанр, см. разработка ПО систем управления и шире разработку ПО. CRM как частный случай — разработка CRM, если коробка ломает ваш цикл.

Короткий тест на одной встрече

1. Назовите объект учёта одним словом: заявка, заказ, объект, договор.
2. Нарисуйте 5–7 статусов, как есть сейчас, без «как хотелось бы».
3. Для каждого статуса: кто двигает, что обязательно, что считается просрочкой.
4. Посчитайте, сколько раз в неделю объект «теряется» или делается дважды.
5. Если не смогли нарисовать статусы — автоматизировать рано, сначала договоритесь.

Как начать, чтобы пилот жил

Начните с одного потока, который больнее всего. Не «оцифровать компанию». Выберите метрику пилота: время цикла, число потерь, часы на отчёт, повторные ошибки. Без метрики вы через месяц будете спорить о удобстве кнопок.

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

Порядок на 30–45 дней

1. Карта as-is на одной странице, согласованная с теми, кто делает работу, не только с директором.
2. Минимальный контур: карточка, статус, ответственный, дата следующего действия.
3. Пилот на 2–5 людях, не на всём отделе.
4. Дата отключения параллельного учёта в «своей» таблице.
5. Только потом интеграции, роботы, дашборды «для совета директоров».

ТЗ на этом этапе — сценарии и права, не роман. Шаблон мысли: как составить ТЗ. Если сомневаетесь, коробка или кастом — сначала проверьте, закрывает ли готовый сервис 80% потока. Кастом оправдан уникальными правилами и жёсткими связками, не желанием «чтобы не как у всех». Проверка гипотезы узким контуром близка к логике MVP и услуге разработки MVP.

Для разработчика: заложите роли, журнал, идемпотентные вебхуки, обработку «человек провёл статус назад». Для внедренца: не обещайте «настроим за неделю любой бизнес». Для заказчика: назначьте владельца процесса внутри, не «пусть IT внедрит, мы потом посмотрим».

Ошибки: рано, поздно и «всё сразу»

Автоматизировать хаос: разные менеджеры по-разному понимают «в работе», а вы уже рисуете воронку. Купить систему со 100 модулями «на вырост». Держать Excel и новую систему параллельно без даты cut-off — правда всегда в файле, который свежее. Не учить людей и винить софт.

Начинать с красивого дашборда, когда статусы ещё врут. Дашборд усиливает ложь. Начинать с ИИ «чтобы само». Модель не заменит правило «кто двигает статус». ИИ уместен на извлечении полей из писем и классификации, когда поток уже есть — см. AI-решения, но не как первый шаг учёта.

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

Признаки, что пилот умер

• Люди заводят карточку постфактум «для галочки».
• Руководитель не смотрит систему, только слушает планёрку.
• Поля обязательные, но заполняются «пробел» и «тест».
• Интеграции шлют дубли, никто не чистит.

Разбор постановки — ошибки заказчика. Выбор исполнителя — как выбрать подрядчика. Сопровождение после запуска — разработка и сопровождение ПО: релиз без владельца снова расползётся в чаты.

Когда автоматизировать не нужно

Не нужно, если действие штучное: сложный проект раз в квартал, каждый раз уникальный. Регламент и чек-лист сильнее системы. Не нужно, пока вы не готовы запретить серый контур. Не нужно «чтобы инвестору показать современность». Не нужно заменять управление людьми кнопками: система не научит продавать и не помирит отделы.

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

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

Следующий шаг

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

Если нужен разбор контура — Grevin, grevin.info@mail.ru, +7 993 302-62-55.