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

Разница слышна на простой офисной фразе. «У нас есть отдел закупок» — это про людей и штатное расписание. «У нас есть процесс закупки» — это про то, что любой сотрудник может ответить, где сейчас заявка на подшипники, кто её держит третий день и что произойдёт завтра. Отдел бывает почти всегда. Процесс — заметно реже.

Дальше — словарный разбор двух терминов, минимальный шаблон описания, который занимает одну страницу, и модельный расчёт того, во что обходится его отсутствие. Пример — согласование счетов на оплату, 260 счетов в месяц, четыре участника. Ставка инженера 3 000 ₽/час, полная стоимость часа сотрудника 700 ₽, по состоянию на сентябрь 2026 года.

Четыре границы, без которых автоматизировать нечего

Что это значитБизнес-процесс

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

Из четырёх границ чаще всего отсутствует владелец. Шаги обычно назвать могут все, а на вопрос «кто отвечает за то, что счёт согласован за три дня» в компании на 100 человек уверенно отвечают редко: за свои визы отвечают четверо, за срок целиком — никто. Это не бюрократическая придирка: без владельца некому принимать решение при исключении, и процесс встаёт на первом же нестандартном случае.

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

схема процессаchto-takoe-biznes-protsess-i-bpm--01
Схема границ процесса: вход, пять шагов, выход, владелец сбоку и правило завершения

Горизонтальная схема. Слева блок «Вход: счёт получен от поставщика» с подписью «260 раз в месяц». В центре цепочка из пяти пронумерованных блоков-шагов со стрелками и мелкими отметками нормативов «1 час», «1 день», «1 день», «1 день», «до 16:00». Справа блок «Выход: платёжное поручение выгружено в банк». Над цепочкой рамка «Владелец процесса: финансовый директор», под цепочкой рамка «Правило завершения: выгрузка в банк, а не факт списания». Тонкие чертёжные линии, подписи по-русски.

Четыре границы задаются до шагов, а не после — иначе спорить будут не о маршруте, а о предмете

Минимальное описание, которого хватает для сметы

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

ШагКто делаетГдеНормативЧем подтверждается
1. Приложить счёт и указать статью бюджетаСнабженецПортал заявок1 рабочий час с полученияВ карточке есть файл и статья бюджета
2. Подтвердить потребностьРуководитель подразделенияПортал заявок1 рабочий деньВиза с комментарием
3. Проверить лимит и дату платежаФинансистПортал + 1С1 рабочий деньСчёт привязан к неделе платёжного календаря
4. Согласовать сумму свыше 50 000 ₽ДиректорПортал, мобильно1 рабочий деньВиза
5. Поставить в оплатуБухгалтер1С:БухгалтерияДо 16:00 дня платежаПлатёжное поручение выгружено в банк

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

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

  • Сумма 50 000 ₽ и меньше — шаг 4 пропускается, директор счёт не видит вовсе. Так работало годами, но в регламенте это записано не было.
  • Статья «Строительство» — перед шагом 3 добавляется виза технадзора, потому что финансист не проверяет объёмы по актам.
  • Поставщик новый — перед шагом 2 добавляется проверка контрагента, это ещё один рабочий день.
  • Платёж срочный, день в день — шаги 2 и 3 идут параллельно, директор уведомляется постфактум. Отдельный маршрут, а не ускоренный обычный.
  • Предоплата свыше 300 000 ₽ — добавляется виза юриста, потому что нужен договор, а не только счёт.

Таблица шагов плюс список исключений — это одна страница и 14 часов работы, то есть 42 000 ₽. Если процесс сложнее и в нём есть параллельные ветки и ожидание внешнего события, таблицы перестаёт хватать и нужен лист со схемой; когда именно наступает этот момент и какой формат выбрать, разобрано в материале про карту процессов и нотации.

Чем BPM отличается от CRM и таск-трекера

Что это значитBPM-система

Система, которая ведёт экземпляры процесса по заранее описанному маршруту: сама передаёт объект следующему исполнителю, следит за нормативом каждого шага и поднимает эскалацию при просрочке. Бизнесу даёт ответ на вопрос «где сейчас счёт № 312 и почему четвёртый день» без обзвона четырёх человек. В смете — настройка маршрута, формы, правила исключений и отчёт по срокам. Проверочный вопрос: что система делает, когда исполнитель в отпуске.

Три системы решают три разные задачи, и подмена одной другой — самая дорогая ошибка на этапе выбора. CRM ведёт отношения с клиентом, трекер ведёт список дел, BPM ведёт маршрут объекта. В таблице — то, по чему их различают на практике.

Что сравниваемCRMТаск-трекерBPM-система
Главный объектКлиент и сделкаЗадачаЭкземпляр процесса: конкретный счёт, заявка, договор
Кто задаёт следующий шагМенеджер по своему усмотрениюАвтор задачиПравило маршрута, одинаковое для всех
Что считается просрочкойСделка без активностиЗадача с истёкшим срокомШаг, превысивший свой норматив
Что видит руководительВоронку по стадиямСписок задач по людямГде стоят все экземпляры и сколько времени
Что происходит, если человек в отпускеСделка виситЗадача виситЗамещение или эскалация по правилу
Типовой вопрос, на который отвечаетЧто с клиентом?Кто чем занят?Где счёт № 312 и почему четвёртый день?

Практический вывод из таблицы: если вам нужно, чтобы объект сам двигался дальше и кто-то узнавал о просрочке без напоминания, трекер и CRM эту задачу не закроют — в них следующий шаг всегда назначает человек. Отдельный разбор того, как такой маршрут собирается на реальном процессе и где ломается, — в статье про маршрут согласования договора.

разбор экранаchto-takoe-biznes-protsess-i-bpm--02
Карточка экземпляра процесса: счёт на третьем шаге из пяти, четвёртый день при нормативе один

Нарисованный абстрактный экран без брендов. Сверху заголовок «Счёт № 312, поставщик, 84 500 ₽». Под ним горизонтальная лента из пяти шагов, первые два отмечены как пройденные с датами, третий выделен и подписан «Финансист, 4 дня при нормативе 1 день», четвёртый и пятый бледные. Справа блок «Эскалация назначена: финансовый директор». Внизу таблица из трёх строк истории с датами и исполнителями. Тонкие чертёжные линии, подписи по-русски.

Главный экран BPM — не воронка и не список задач, а состояние одного экземпляра

Цена неописанного процесса

Теперь главное. Автоматизация процесса, который не описан, не оставляет всё как было — она ускоряет беспорядок и делает его официальным. Модельный пример на тех же 260 счетах: компания решила не тратить 42 000 ₽ на описание и запустила маршрут по рассказу на созвоне — инициатор, руководитель, финансист, директор.

Через два месяца выяснилось, что этот маршрут описывает 62 % потока. В остальных 99 счетах из 260 работали исключения, которых в системе не было: 61 счёт на суммы до 50 000 ₽ ушёл на согласование директору, который раньше их не видел, и очередь у него выросла с 40 до 101 счёта в месяц; средний срок согласования поднялся с 2,5 до 4,8 дня. Ещё 38 счетов по стройке участники начали проводить мимо системы — в мессенджере, ровно так, как делали до внедрения.

Что стоило не описывать процесс до запуска
Описание процесса до старта: интервью, таблица, согласование — 14 часов42 000 ₽ — не потрачены
Переделка маршрута после запуска: разбор исключений, правила, перенастройка — 46 часов138 000 ₽
Параллельный контур в мессенджере: 2 месяца × 38 счетов × 20 минут17 700 ₽
Рост срока согласования с 2,5 до 4,8 дня на 520 счетах за два месяцане считаем деньгами, но платежи ушли позже
Итого155 700 ₽ вместо 42 000 ₽ — в 3,7 раза дороже, плюс два месяца недоверия к системе

Обратите внимание, какая строка здесь самая дорогая. Не переделка сама по себе, а то, что на два месяца сотрудники получили подтверждение: система мешает работать, а мессенджер — помогает. Возвращать людей в систему после такого опыта дороже, чем настроить её правильно с первого раза, и в смете эта работа не появляется вовсе.

графикchto-takoe-biznes-protsess-i-bpm--03
Два столбца: описание процесса за 42 000 рублей против переделки и обходного контура на 155 700

Столбчатая диаграмма из двух столбцов. Левый низкий «Описать до старта — 42 000 ₽, 14 часов». Правый высокий составной «Не описывать — 155 700 ₽» из двух сегментов: «переделка маршрута 138 000 ₽» и «обходной контур в мессенджере 17 700 ₽». Между столбцами подпись «×3,7». Под правым столбцом мелкая пометка «плюс срок согласования 2,5 → 4,8 дня на 520 счетах». Тонкие чертёжные линии, подписи по-русски.

Сэкономленные 42 000 ₽ вернулись счётом в 3,7 раза больше — и это без учёта потери доверия

Российские платформы на 2026 год

Живой выбор по состоянию на сентябрь 2026 года: Битрикс24 — процессы внутри портала, где сотрудники уже сидят по другим поводам; Comindware — полноценный движок процессов с низкокодовой сборкой, для случаев со сложными маршрутами и большим числом исключений; Aspro.Cloud — процессы вместе с проектами и финансами в одном контуре; Pyrus — согласования и заявки с сильной мобильной частью, куда чаще всего уходят именно счета и служебные записки.

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

Три вопроса подрядчику

  1. 1Как вы фиксируете текущий процесс до начала работ? Правильный ответ описывает метод: интервью с исполнителями, выгрузка по 20–30 последним экземплярам, наблюдение. Ответ «по вашему рассказу на созвоне» гарантирует, что исключения всплывут после запуска — как в расчёте выше.
  2. 2Кто со стороны заказчика подтверждает описание и подписывает его? Должен быть назван человек и дата. Формулировка «согласуем в рабочем порядке» означает, что подтверждения не будет, а спор о том, что именно заказывали, начнётся на приёмке.
  3. 3Что считается изменением объёма работ? Найденное после старта исключение — это изменение объёма или уточнение? Ответ должен быть в договоре цифрой: столько-то маршрутов и столько-то исключений входит в цену, каждое следующее — по такой-то ставке. Как это формулируется, разобрано в разделе про существенные условия договора на внедрение.
Описание процесса — это работа заказчика, а не подрядчика

Подрядчик может собрать описание, но подтвердить его может только компания: исключения знают исполнители, а не аналитик. Если на интервью не выделили людей и не подписали результат, вы получите описание основного маршрута — то самое, которое в нашем примере покрыло 62 % потока. Два часа времени четырёх сотрудников — это дешевле, чем 138 000 ₽ переделки.

Когда BPM-система не нужна

Важное различие, которое стоит проговорить отдельно: описание процесса окупается почти всегда, а система под него — далеко не всегда. Это разные решения и разные деньги.

  • Меньше 175 экземпляров в месяц. Маршрут в готовой платформе стоит около 150 000 ₽ настройки и 12 000 ₽/мес подписки, а снимает примерно 12 минут поиска и переспрашивания на экземпляр — это 140 ₽. При 260 счетах чистая экономия 24 400 ₽/мес и окупаемость 6,1 месяца; при 100 счетах экономия 2 000 ₽/мес, и вложение не возвращается. Порог годовой окупаемости — около 175 экземпляров.
  • Процесс меняется чаще раза в квартал. Маршрут закрепляет договорённость, а если договорённость ещё ищут, вы платите за перенастройку каждые три месяца. Сначала стабилизировать процесс регламентом, потом закреплять системой — как писать такой регламент, разобрано в статье как описать регламент процесса.
  • В процессе один исполнитель. Если объект не передаётся между людьми, маршрута нет — есть последовательность действий одного человека. Здесь нужен чек-лист и напоминание, а не движок процессов за 150 000 ₽.

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

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