Двенадцать примеров автоматизации бизнес-процессов по отделам: триггер, шаги, системы, решение, которое остаётся за человеком, и число для замера.
Содержание11 разделов
- Какие примеры стоит рассмотреть и насколько сложен каждый?
- Как читать каждый пример?
- Что финансы могут автоматизировать первым?
- Как автоматизация продаж выглядит на практике?
- Какие операционные процессы стоит автоматизировать?
- Что HR может автоматизировать, не теряя человеческой части?
- Как работает сортировка обращений в поддержку?
- Что может автоматизировать руководство?
- С какого примера начать?
- На каких инструментах работают эти примеры?
- Почему автоматизированные процессы ломаются позже?
Примеры автоматизации бизнес-процессов проще всего оценивать, когда каждый описан одинаково: что его запускает, что делает программа, каких систем касается, что по-прежнему решает человек и какое число доказывает, что всё сработало. Ниже двенадцать примеров, сгруппированных по отделам, от приёма счетов в финансах до еженедельного отчёта для руководства. Два взяты из наших опубликованных проектов, с измеренными результатами. Остальные описывают, как процесс обычно устроен, без выдуманных процентов. Большинству нужна платформа интеграций вроде Zapier или n8n плюс системы, которые у вас уже есть. Если нужен только короткий список, быстрее всего окупаются приём счетов, распределение заявок, приём заказов и выход нового сотрудника, потому что каждый из них выполняется часто на входных данных, которые приходят в предсказуемом виде.
Какие примеры стоит рассмотреть и насколько сложен каждый?
Столбец сложности - наша собственная оценка первого проекта в малой или средней компании. Низкая значит две-три системы со стабильными API и простыми правилами. Средняя значит правило сверки или распределения, которое сначала нужно записать. Высокая значит неструктурированные входные данные, старую систему без API или правило, о котором в компании никогда не договаривались.
| Пример | Отдел | Триггер | Типичные инструменты | Сложность |
|---|---|---|---|---|
| Приём счетов и сверка кредиторской задолженности | Финансы | Счёт приходит в общий почтовый ящик | Учётная система (Xero, QuickBooks), извлечение данных из документов, платформа интеграций | Средняя |
| Напоминания об оплате | Финансы | У счёта истёк срок оплаты | Учётная система, почта | Низкая |
| Чеки по расходам | Финансы | Отправлено фото чека | Приложение для учёта расходов, учётная система | Низкая |
| Распределение заявок и первый ответ | Продажи | Заявка из формы, с портала или из мессенджера | CRM, календарь, мессенджеры, платформа интеграций | Средняя |
| Документы для КП и договоров | Продажи | Сделка переходит на этап | CRM, шаблоны документов, электронная подпись | Низкая |
| Приём заказов и доступность | Операции | Получена бронь или заказ | Система заказов или проката, замена таблицы, мессенджеры | Высокая |
| Отгрузка и уведомления о доставке | Операции | Заказ подтверждён | Планирование, SMS или мессенджер | Средняя |
| Дозаказ товара | Операции | Остаток ниже заданного уровня | Складская система, почта поставщику | Низкая |
| Выход нового сотрудника | HR | Оффер подписан | HR-система, Google Workspace или Microsoft 365, IT-заявки | Средняя |
| Увольнение и отзыв доступов | HR | Дата ухода подтверждена | То же, что при выходе | Средняя |
| Сортировка обращений и черновик ответа | Поддержка | Пришло обращение или письмо | Хелпдеск, база знаний, языковая модель | Средняя |
| Еженедельный операционный отчёт | Руководство | Расписание (понедельник 07:00) | База данных или таблицы, BI-инструмент, почта | Низкая |
«Платформа интеграций» значит Zapier, Make, n8n или код, которым вы владеете. Какая подходит, это отдельное решение, о нём ниже; в тексте Make или Zapier посчитана цена сценария распределения заявок, похожего на тот, что описан ниже, на обеих платформах.
Как читать каждый пример?
Каждый пример ниже описан по одним и тем же пяти полям, потому что именно они решают, дойдёт ли проект до запуска.
- Триггер: событие, которое запускает работу. Если вы не можете его назвать, процесс не готов.
- Шаги: что делает программа, по порядку.
- Системы: где данные читаются и записываются.
- Что по-прежнему решает человек: шаг, который обязывает деньгами, условиями или доступом.
- Что измерять: число, которое вы снимаете до начала работ и снова после.
Четвёртое поле важнее всего. Сценарий, который молча согласует скидку или выдаёт права администратора, опасен, как бы быстро он ни работал, а наши правила, как держать человека в контуре, объясняют, где мы проводим эту границу.
Что финансы могут автоматизировать первым?
Приём счетов и сверка кредиторской задолженности. Триггер: счёт поставщика приходит в бухгалтерский ящик в PDF. Шаги: извлечь поставщика, номер счёта, дату, суммы и ссылку на заказ на закупку; найти заказ и документ о приёмке товара; сравнить все три («трёхсторонняя сверка»); отметить дубли по сочетанию поставщика и номера счёта; создать черновик счёта с приложенным документом. Системы: общий почтовый ящик, извлечение данных из документов, учётная система или ERP. Человек решает: каждый счёт, который не прошёл сверку, каждый счёт выше порога утверждения и любое изменение банковских реквизитов поставщика, потому что это известный путь мошенничества, и такое изменение никогда нельзя принимать на основании одного письма. Измерять: дни от получения до утверждённого счёта, долю счетов, прошедших без ручного вмешательства, и пойманные дубли.
На правиле сверки проекты и застревают. «Сходится» требует записанного допуска (точная сумма или отклонение в пределах заданной суммы на округление и доставку), а команда, возможно, годами применяла такой допуск на глаз и нигде его не записала.
Напоминания об оплате. Триггер: срок оплаты счёта истёк, а оплаты нет. Шаги: отправить вежливое напоминание, через заданный интервал более жёсткое, затем создать задачу для человека. Человек решает: всё, что уходит клиенту в споре или на согласованном графике платежей, поэтому сценарию нужен флаг «не напоминать», который кто-то поддерживает в актуальном виде. Измерять: средний срок погашения дебиторской задолженности (DSO) и долю счетов, оплаченных после первого напоминания.
Чеки по расходам. Триггер: сотрудник фотографирует чек. Шаги: считать продавца, дату и сумму, предложить категорию, привязать к операции по карте, отправить утверждающему. Человек решает: всё, что выходит за рамки политики. Измерять: дни от траты до сверенной записи на конец месяца.
Как автоматизация продаж выглядит на практике?
Распределение заявок и первый ответ. Это наш первый опубликованный проект, из агентства недвижимости. Триггер: заявка по конкретному объекту приходит с портала, сайта или из мессенджера. Шаги: проверить, нет ли этого человека уже под другим номером или с другого портала; проверить, что объект ещё доступен; применить правило распределения агентства; за несколько минут ответить фактами из объявления и слотами для просмотра из реального календаря назначенного агента. Системы: порталы объявлений, CRM, календари, мессенджеры. Человек решает: само правило распределения (по кругу, по специализации или по загрузке, обычно смесь) и всё, что обязывает, поскольку ответ никогда не торгуется и не называет цену вне опубликованной. Измерять: время от заявки до первого ответа, дубли контактов и заявки в нерабочее время, получившие ответ.
Полный разбор заявок агентства аккуратен с причинностью: цикл сделки сдвинулся потому, что в том же проекте исправили просмотры, документы и видимость воронки, а подготовка документов сократилась с 2 дней до 20 минут. Проект, который исправляет только первый ответ, получает хорошую цифру для заголовка и цикл сделки, который почти не меняется.
Документы для КП и договоров. Триггер: сделка в CRM доходит до этапа предложения. Шаги: заполнить утверждённый шаблон данными клиента, позициями и ценами из CRM, отправить на электронную подпись, сохранить подписанный экземпляр в сделке. Человек решает: любую цену или условие вне шаблона. Измерять: время от смены этапа до отправки документа и количество документов, исправленных после отправки.
Какие операционные процессы стоит автоматизировать?
Приём заказов и доступность. Это наш второй опубликованный проект, из компании по прокату техники. Триггер: бронь приходит по телефону, почте, через форму или мессенджер. Шаги: превратить запрос свободным текстом в структурированный заказ; проверить доступность по всем состояниям, в которых может быть единица техники; зарезервировать её в момент подтверждения; собрать договор из утверждённого шаблона; запланировать отгрузку. Системы: существующая система проката, таблица, которую она заменила, мессенджеры, графики водителей. Человек решает: скидки вне прайса, нестандартные условия, клиентов с открытым спором о повреждениях и любую бронь, после которой не остаётся запаса до следующего заказа. Измерять: время от брони до отгрузки как распределение, двойные брони и заявки, оставшиеся без ответа.
Текст о том, куда уходят четыре часа, показывает, почему в таблице у него сложность «Высокая»: у доступности оказалось семь состояний, в четырёх из которых машина стоит на площадке, но сдать её нельзя, поэтому большая часть работы ушла на моделирование данных. Языковая модель отвечала только за один шаг: чтение заявок, написанных своими словами клиента.
Отгрузка и уведомления о доставке. Триггер: заказ подтверждён. Шаги: назначить слот и водителя, отправить клиенту подтверждение, накануне отправить напоминание, сообщить о выезде. Человек решает: перестановки, когда заказ затягивается. Измерять: пропущенные или опоздавшие доставки и входящие звонки «где мой заказ».
Дозаказ товара. Триггер: остаток падает ниже точки дозаказа. Шаги: составить заказ на закупку у привычного поставщика в привычном количестве, отправить на утверждение, отправить по почте. Человек решает: точки дозаказа и любую смену поставщика. Измерять: случаи нехватки товара и запас в днях.
Что HR может автоматизировать, не теряя человеческой части?
Выход нового сотрудника. Триггер: оффер подписан в HR-системе. Шаги: создать почтовый аккаунт и стандартные членства в группах, открыть заявку на оборудование, добавить человека в зарплатную ведомость, отправить расписание первой недели, назначить обязательное обучение. Системы: HR-система, Google Workspace или Microsoft 365, IT-заявки, зарплата. Человек решает: доступы сверх стандартных для роли и само приветствие, которое должно прийти от руководителя, а не из шаблона. Измерять: дни от подписи до момента, когда работают все аккаунты, и заявки на доступ в первую неделю.
Увольнение. Триггер: подтверждена дата ухода. Шаги: запланировать отзыв доступов на последний день, передать владение файлами, собрать оборудование, остановить начисление зарплаты. Человек решает: дату и судьбу общих аккаунтов. Измерять: аккаунты, всё ещё активные после даты ухода, их должно быть ноль. Этот процесс может значить больше, чем выход нового сотрудника, потому что аккаунт, оставшийся открытым после ухода человека, это проблема безопасности.
Как работает сортировка обращений в поддержку?
Сортировка обращений и черновик ответа. Триггер: приходит письмо или обращение. Шаги: определить тип и срочность, привязать заказ или аккаунт клиента, написать черновик ответа по базе знаний, направить в нужную очередь. Системы: хелпдеск, CRM или система заказов, база знаний, языковая модель. Человек решает: отправлять ли черновик, а также каждый возврат денег, начисление или исключение. Измерять: время до первого ответа, долю черновиков, отправленных с небольшой правкой, и повторно открытые обращения.
Здесь модель делает настоящую работу, потому что обращения приходят свободным текстом. Границу всё равно держите чёткой. Модель пишет черновики и классифицирует; возвраты она не одобряет.
Что может автоматизировать руководство?
Еженедельный операционный отчёт. Триггер: расписание. Шаги: собрать числа за прошлую неделю, сравнить с позапрошлой, отправить короткую таблицу тем, кто по ней действует. Человек решает: что эти числа значат. Измерять: читает ли его кто-нибудь. Отчёт, который никто не открывает, нужно выключить, и улучшать его бесполезно.
С какого примера начать?
Выбирайте процесс, который проходит четыре фильтра. Мы сохранили их из прошлой версии этого руководства, потому что они по-прежнему верны:
| Фильтр | Проходит, когда |
|---|---|
| Затраты | Конкретный человек тратит на процесс несколько часов в неделю |
| Входные данные | Приходят в предсказуемом виде (формы, письма с вложениями, записи) |
| Результат | Его можно посчитать: распределено, сверено, написано, забронировано |
| Стабильность | Процесс не собираются в ближайшее время реорганизовать или переносить |
Потом измеряйте, прежде чем строить. В прокатной компании мы потратили неделю на подсчёт по данным систем, прежде чем что-то писать, и два из четырёх чисел, которые все считали важными, оказались неважными: среднее скрывало медленный хвост, где клиенты сдавались, а годовой объём сглаживал высокий сезон, который приносил большую часть выручки за год. Этот метод - первый этап аудита процесса до автоматизации, а расчёт окупаемости, который можно сделать самостоятельно, есть на странице стоит ли автоматизировать мой процесс.
На каких инструментах работают эти примеры?
Большинству примеров выше нужна платформа интеграций плюс системы, которые у вас уже есть. Какая платформа дешевле для конкретного примера, решает единица оплаты. Zapier считает задачу каждый раз, когда завершает единицу работы, а триггеры и опрос не считаются, поэтому сценарий с триггером и пятью действиями расходует до пяти задач за прогон. n8n считает один запуск (execution) на прогон всего сценария: «неважно, сколько в сценарии шагов». Обе страницы цен прочитаны 07.10.2026. Поэтому многошаговым примерам вроде сверки счетов или выхода нового сотрудника с ростом объёма выгоднее оплата за прогон, а двухшаговое напоминание дёшево где угодно. Расчёты с числами в тексте n8n или Zapier, а карточка Zapier в Атласе INITE хранит его цены с датой, когда их прочитали.
Если у системы нет API, пробел может закрыть экранный робот; руководство по внедрению RPA разбирает, когда это стоит затрат на поддержку. Полный набор сценариев, которые мы строим, на странице автоматизация с ИИ.
Почему автоматизированные процессы ломаются позже?
Обычно они отказывают через несколько месяцев после запуска, когда поставщик меняет макет счёта, поле в CRM переименовывают или вендор меняет свой API; эту закономерность описывает текст о том, когда интеграция меняется под тобой. Живыми их держат три привычки:
- Каждую неделю прогоняйте через сценарий реальные случаи прошлой недели. Замороженный набор тестов не дрейфует, а рабочие данные дрейфуют.
- Записывайте вход, выход и решение каждого шага. Когда что-то сломается, журнал покажет где.
- Пусть человек бессрочно проверяет случайную выборку случаев, именно случайную, а не только отмеченные, тогда падение качества проявится раньше, чем его заметят клиенты.
Каждому сценарию также нужен один конкретный владелец. Без него никто не замечает, когда доля сверок падает или напоминания перестают уходить, и автоматизация тихо деградирует, продолжая выглядеть включённой. Прежде чем принимать любую цифру, которую вендор называет для этих примеров, включая наши, прогоните её через четыре вопроса, которые ломают почти любую цифру окупаемости.
Часто задаваемые вопросы
Какой пример автоматизации бизнес-процесса типичен?
Типичный пример - приём счетов. Счёт приходит по почте, программа считывает поставщика, сумму и номер заказа на закупку, сверяет их с заказом и документом о приёмке товара и создаёт черновик счёта в учётной системе. Человек утверждает только счета, которые не сошлись или превышают порог, поэтому обычные счета никогда не ждут в чьём-то почтовом ящике.
Какие бизнес-процессы автоматизировать первыми?
Начинайте с процесса, который выполняется часто, отнимает у конкретного человека несколько часов в неделю, получает входные данные в предсказуемом виде и редко меняется. Обычно подходят распределение заявок, приём заказов, приём счетов и сортировка обращений. Прежде чем выбирать, неделю измеряйте процесс по отметкам времени в своих системах, потому что среднее скрывает медленные случаи, на которых теряются деньги.
Чем автоматизация бизнес-процессов отличается от RPA?
RPA - один из приёмов внутри автоматизации бизнес-процессов: программный робот кликает и печатает в интерфейсе так, как это делал бы человек, и это полезно, когда у старой системы нет API. Автоматизация бизнес-процессов - более широкая задача перестройки процесса, и большая её часть работает через API, вебхуки и правила, а RPA оставляют для систем, до которых больше ничем не дотянуться.
Нужен ли ИИ, чтобы автоматизировать бизнес-процесс?
Обычно для одного шага и редко для всего процесса. В проекте для проката из этого руководства доступность, цены, документы и отгрузка работали на правилах, потому что должны каждый раз давать один и тот же ответ. Языковая модель заслужила своё место на чтении заявок свободным текстом, где правило не справляется, а иначе человеку пришлось бы перепечатывать сообщение в форму.
Как измерить, сработала ли автоматизация?
Выберите число до начала работ: время от триггера до готового результата, доля случаев, где нужен человек, и количество ошибок вроде дублей или двойных броней. Возьмите исходный уровень из отметок времени в системах за весь загруженный период, сравнивайте распределение, а не среднее, и проверьте те же числа через месяц после запуска.



