Технологии автоматизации бизнес-процессов: пять слоёв и как выбрать свой
Разбираю пять слоёв технологий автоматизации — от простых коннекторов до ИИ-шагов внутри сценария — и показываю, как выбрать нижний слой, которого хватит под вашу задачу. Со стороны исполнителя, без обещаний «внедрим за неделю».
Зачем разбираться в слоях
«Нам нужна автоматизация» — фраза, за которой прячутся очень разные задачи. У одного человека это «перестать вручную переносить заявки из почты в CRM». У другого — «согласование договора не должно висеть неделю».
Под каждую задачу есть свой класс инструментов. Если промахнуться со слоем, получится дорого и криво: люди строят полноценную BPM-систему там, где хватило бы связки из трёх шагов. Или наоборот — пытаются удержать сложное многоэтапное согласование внутри одного сценария в конструкторе.
Дальше — пять слоёв, снизу вверх.
Слой 1. Коннекторы и интеграционные платформы
Самый доступный вход. Сервисы вроде Zapier, Make, n8n соединяют приложения по принципу «событие → действие». Пришло письмо с вложением — файл лёг в облако, строка появилась в таблице, коллега получил уведомление.
Что тут хорошо:
- запускается за вечер, без разработчика;
- результат виден сразу, откатить можно так же быстро;
- n8n ставится на свой сервер, если данные нельзя отдавать наружу.
Ограничение честное: как только в сценарии появляются ветвления, ожидание ответа от человека и контроль сроков, конструктор превращается в кашу.
Слой 2. BPM-системы
Здесь процесс описывается целиком: этапы, роли, переходы, сроки, эскалации. Заявка идёт по маршруту, система знает, у кого она сейчас, и сама подталкивает застрявшие.
BPM оправдан, когда процесс:
- проходит через несколько отделов;
- требует согласований и фиксации ответственности;
- должен быть воспроизводим и проверяем постфактум.
Цена входа выше. Процесс придётся сначала описать словами, и это самая тяжёлая часть работы. Обычно на этом шаге выясняется, что в компании нет двух человек с одинаковым представлением о том, как заявка движется на самом деле.
Слой 3. RPA
Программный робот повторяет действия человека прямо в интерфейсе: открывает окно и переносит поля туда, куда их переносил бы сотрудник. Нужен там, где у системы нет API — старая учётная программа, банк-клиент, портал госоргана.
RPA стоит воспринимать как подпорку. Она хрупкая: поменялась вёрстка или расположение кнопки — робот встал. Ставить её имеет смысл осознанно, понимая, что через год интеграцию, возможно, придётся переделывать по-нормальному.
Слой 4. Low-code платформы
Когда задача выходит за рамки связки готовых сервисов и нужен свой интерфейс — форма, реестр, карточка объекта. Low-code даёт собрать приложение из блоков, с базой и правами доступа.
Риск известный: такие системы легко расползаются. Через год у компании десяток приложений, собранных разными людьми, и никто не помнит, какое из них главное. Помогает простое правило — у каждого собранного приложения есть один владелец, записанный по имени.
Слой 5. ИИ внутри сценария
Языковые модели закрывают то, что раньше упиралось в человека: разобрать письмо в свободной форме, вытащить данные из скана, классифицировать обращение, подготовить черновик ответа. Технически это встраивается в предыдущие слои как один шаг сценария — вызов модели вместо ручной операции.
Важная оговорка из практики: модель даёт вероятностный результат. Поэтому её ставят туда, где цена ошибки низкая или где остаётся проверка человеком. Разбор входящего письма — спокойно. Списание денег по итогам такого разбора — только с подтверждением.
Как выбирать
Порядок, которым пользуюсь сам:
- Описать процесс в текущем виде, по шагам, с именами исполнителей.
- Посчитать, сколько времени он съедает в неделю. Без этой цифры любое внедрение обсуждается на эмоциях.
- Найти шаги, где человек работает передаточным звеном и перекладывает данные между окнами. Это первые кандидаты.
- Взять самый нижний слой, который закрывает задачу. Коннектор справился — до BPM подниматься незачем.
- Запустить на одном процессе и пожить с ним пару недель.
Что ломается чаще всего
- Автоматизировали процесс, который сам по себе лишний. Сначала выкидываем, потом автоматизируем.
- Нет владельца. Сценарий работает, автор ушёл, сломалось — чинить некому.
- Нет уведомления об ошибке. Робот молча падает, и три недели об этом никто не знает.
- Нет плана на случай падения. Ручной путь должен оставаться живым.
Автоматизация редко выглядит как большой проект с презентацией. Чаще это несколько скучных связок, которые снимают с людей повторяющуюся работу и продолжают жить дальше, потому что кто-то за них отвечает.