- чем бизнес-процесс отличается от рутинной операции и почему это меняет порядок действий;
- по каким четырём признакам выбрать процесс, с которого начинать;
- как описать процесс так, чтобы его вообще можно было автоматизировать;
- что закрывают готовые системы, а где начинается разработка;
- три ошибки внедрения, из-за которых проект не приносит результата;
- как считать эффект, кроме «мы внедрили систему».
Автоматизация бизнес-процессов почти всегда начинается не с того конца. Компания выбирает процесс, который проще описать и быстрее внедрить, — и получает аккуратно работающий участок, не влияющий на деньги. Через полгода выясняется, что заявки по-прежнему теряются, согласование договора занимает неделю, а руководитель всё так же собирает отчёт руками.
Причина в том, что выбор процесса для старта — это управленческое решение, а не техническое. Ниже — метод, по которому это решение принимается: как отличить процесс от рутины, как выбрать кандидата, где хватит коробочной системы, а где придётся разрабатывать, и как понять, что автоматизация сработала.
Что такое автоматизация бизнес-процессов и чем процесс отличается от рутины
Процесс — это цепочка шагов с передачей ответственности между людьми или отделами. Рутина — повторяющаяся операция внутри одного рабочего места. Автоматизация бизнес-процессов работает с цепочками; отдельная рутина чаще всего решается настройкой инструмента, который уже есть.
Разница практическая, а не терминологическая. Если сотрудник каждый день вручную выгружает отчёт и пересылает его в чат — это рутина. Она раздражает, съедает время, но живёт внутри одной головы и одного экрана. Такие вещи закрываются шаблоном, макросом или готовой интеграцией, и отдельный проект под них не нужен.
Процесс выглядит иначе: заявка приходит в отдел продаж, оттуда уходит на расчёт, потом на согласование, потом в производство, потом на отгрузку. У каждой передачи есть срок, ответственный и возможность потеряться. Именно в местах передачи и живут деньги — там заявка ждёт три дня, там теряется файл, там никто не понимает, у кого сейчас задача.
| Признак | Рутина | Бизнес-процесс |
|---|---|---|
| Кто участвует | один сотрудник | несколько людей или отделов |
| Где ломается | в скорости выполнения | в местах передачи между участниками |
| Что чувствует руководитель | «долго» | «непонятно, на каком этапе» |
| Чем решается | настройка инструмента, шаблон | описание процесса и система, ведущая его по шагам |
Отсюда первый практический вывод. Если основная жалоба звучит как «мы не понимаем, где сейчас заявка» или «узнаём о проблеме, когда клиент уже написал» — речь о процессе, и автоматизация бизнес-процессов уместна. Если жалоба звучит как «это делается вручную и долго» — сначала проверьте, нельзя ли закрыть задачу настройкой того, что уже куплено.
Четыре признака процесса, с которого стоит начинать
Первым автоматизируют не самый неудобный процесс, а тот, где сходятся четыре условия: он повторяется часто, у него есть измеримый результат, в нём участвует больше одного отдела и его сбой стоит денег.
Признаки работают вместе, а не по отдельности — процесс, набравший все четыре, почти наверняка окупится. Именно с такого процесса автоматизация бизнес-процессов и должна начинаться, даже если он выглядит сложнее соседних.
Частота. Процесс должен происходить регулярно: десятки раз в месяц, а лучше ежедневно. Годовая инвентаризация или ежеквартальная отчётность неудобны, но экономия на них ничтожна — вы потратите на внедрение больше, чем сэкономите за три года.
Измеримый результат. Должно быть понятно, что считать: количество заявок, срок согласования, число ошибок, процент срывов. Если результат нельзя измерить до внедрения, вы не докажете эффект и после.
Больше одного участника. Процессы внутри одного отдела редко дают заметный эффект: там люди договариваются между собой быстрее любой системы. Настоящие потери возникают на стыках — между продажами и производством, между складом и бухгалтерией, между менеджером и руководителем.
Цена сбоя. Ошибка в процессе должна стоить денег или клиента. Если сбой означает «переделаем завтра», процесс не в приоритете, каким бы раздражающим он ни был.
Порядок применения простой: выпишите пять-семь процессов компании, поставьте каждому оценку по четырём признакам и берите тот, что набрал больше. Это занимает час и заменяет долгий спор о том, что важнее.
Как описать процесс, чтобы его можно было автоматизировать
Автоматизировать можно только то, что описано в терминах ролей, событий и передач. Достаточно ответить на четыре вопроса по каждому шагу — подробная схема в нотации не нужна, пока вы не дошли до разработки.
Описание процесса пугает: кажется, что нужен аналитик, схемы в BPMN и месяц работы. На старте достаточно таблицы, которую отдел заполняет за одну встречу. По каждому шагу отвечаете на четыре вопроса:
- Что происходит — действие одним глаголом: «менеджер рассчитывает стоимость».
- Кто отвечает — конкретная роль, а не отдел. «Отдел продаж» — не ответственный, «менеджер, ведущий сделку» — ответственный.
- Что должно прийти на вход и что получится на выходе — документ, заявка, расчёт, подписанный файл.
- Когда шаг считается законченным — формальный признак, который видит система: статус изменён, файл приложен, согласование получено.
Четвёртый вопрос — самый неудобный и самый важный. Пока «шаг закончен, когда все понимают, что он закончен», процесс автоматизировать нельзя: системе нужен признак, который она способна проверить.
Отдельно отметьте точки ожидания — места, где работа стоит и ждёт человека. Практика показывает: основное время процесса уходит не на выполнение шагов, а именно на ожидание между ними. Согласование, которое «занимает неделю», обычно состоит из сорока минут работы и шести дней ожидания. Автоматизация бизнес-процессов бьёт как раз по этому — она не ускоряет мышление руководителя, но убирает время, пока задача лежит незамеченной.
Формальная нотация (BPMN и подобные) понадобится позже, когда дело дойдёт до сложной логики с ветвлениями и параллельными согласованиями. На этапе выбора и пилота она только замедляет разговор.
Что закрывают готовые системы, а где начинается разработка
Большинство типовых процессов закрывается настройкой CRM, корпоративного портала или учётной системы. Разработка нужна там, где процесс уникален, где систем несколько и они должны обмениваться данными, или где объём операций перерастает возможности коробки.
Честный ответ на вопрос «нам нужна разработка?» в половине случаев — «нет, вам нужно донастроить то, что уже есть». Ориентир такой:
| Задача | Чем закрывается | Когда коробки не хватает |
|---|---|---|
| Заявки, сделки, воронка продаж | CRM-система | нестандартный расчёт, специфика позаказного производства |
| Задачи, согласования, документы | корпоративный портал | сложные маршруты, интеграция с внешними системами |
| Складской и товарный учёт | учётная система | несколько складов и юрлиц, адресное хранение, обмен с площадками |
| Закупки и снабжение | модуль учётной системы | собственная процедура выбора поставщика, работа по 223-ФЗ |
| Отчётность руководителю | встроенные отчёты | данные лежат в трёх разных системах и не сходятся |
Задачи из второй и третьей строк чаще всего закрываются корпоративным порталом, из первой — внедрением CRM; случаи из правой колонки — это уже разработка под процессы компании.
Правая колонка — это и есть признаки того, что вы выросли из типового решения. Обратите внимание: почти все они звучат не как «нам нужно красивее», а как «наш случай не описывается стандартной моделью». Пока процесс укладывается в стандартную — настройка дешевле, быстрее и надёжнее любой разработки.
Разработка оправдана и в третьем случае: когда систем несколько и данные приходится переносить руками. Здесь речь идёт не о замене систем, а об интеграции между ними — о ней подробно разбирали в материале про интеграцию 1С с сайтом.
Пять процессов, с которых обычно начинают
Заявки, согласования, закупки, склад и отчётность. Это не универсальный список, но в них чаще всего сходятся все четыре признака из второго раздела.
Обработка заявок. Самый частый старт: заявки приходят из нескольких каналов, теряются, скорость ответа не контролируется. Закрывается CRM-системой — что она делает и когда действительно нужна, разбирали в отдельной статье про CRM-систему.
Согласования. Договоры, счета, отпуска, закупки сверх лимита. Классический пример процесса, где всё время уходит на ожидание. Маршрут с заместителями и сроками убирает главный сценарий «подписал бы, но был в отпуске» — такую систему согласования кадровых обращений мы делали в отдельном проекте.
Закупки и снабжение. Заявка от подразделения, выбор поставщика, договор, приёмка. Процесс с большим числом участников и прямым влиянием на деньги — подробности в материале про автоматизацию закупок.
Документооборот. Движение документов внутри компании и с контрагентами; отдельно разбирали в статье про автоматизацию документооборота.
Управленческая отчётность. Обычно идёт последней и не случайно: пока данные не собираются в процессе, собирать отчёт не из чего. Автоматизировать отчётность раньше учёта — самая частая перестановка шагов местами.
Три ошибки, из-за которых проект не даёт результата
Автоматизация беспорядка, внедрение без владельца процесса и запуск сразу на всю компанию. Все три видны заранее и все три обходятся дорого.
Ошибка первая: автоматизировать процесс, которого нет. Если порядок работы не описан и каждый сотрудник делает по-своему, система зафиксирует этот разнобой и сделает его обязательным. Хаос, переведённый в цифровой вид, становится дороже: раньше можно было договориться в обход, теперь нельзя. Правило простое — сначала договориться, как процесс должен идти, потом автоматизировать.
Ошибка вторая: у процесса нет владельца. Когда за внедрение отвечает ИТ-специалист или подрядчик, а не руководитель, который в этом процессе живёт, некому принимать решения о спорных шагах. Проект превращается в набор компромиссов, а после запуска никто не отвечает за то, что систему используют.
Ошибка третья: запуск сразу на всех. Компания описывает восемь процессов, внедряет их одновременно и получает сопротивление всего коллектива сразу. Пилот на одном процессе и одном подразделении даёт то, чего не даёт масштабный запуск: возможность ошибиться дёшево.
Все три ошибки объединяет одно: автоматизация бизнес-процессов воспринимается как покупка системы, а не как управленческий проект, у которого есть заказчик, границы и критерий успеха.
Отдельно стоит назвать сопротивление сотрудников — но это не ошибка внедрения, а его нормальная часть. Люди сопротивляются не системе, а прозрачности: когда каждый шаг фиксируется, становится видно, кто действительно загружен. Помогает не уговаривание, а честный ответ на вопрос «что изменится лично для меня» и снятие с человека хотя бы одной обязанности взамен.
Как считать эффект
Четыре показателя, которые компания меряет у себя до и после: длительность процесса, доля срывов срока, число ручных операций и стоимость одной итерации. Замер до внедрения обязателен — иначе доказать эффект нечем.
Универсальных процентов экономии не существует, и любые «автоматизация сокращает издержки на 30%» стоит воспринимать как рекламу, а не как ориентир. Эффект, который даёт автоматизация бизнес-процессов, считается у себя и по четырём показателям:
- Длительность процесса — календарное время от старта до завершения. Именно календарное: рабочие часы скрывают время ожидания, ради которого всё и затевается.
- Доля срывов срока — какой процент заявок или согласований вышел за норматив.
- Число ручных операций — сколько раз человек переносит данные из одной системы в другую. Каждый такой перенос — источник ошибок.
- Стоимость одной итерации — сколько человеко-часов уходит на один прогон процесса.
Замерить это нужно до старта, хотя бы грубо, на выборке в двадцать-тридцать случаев. Компании регулярно пропускают этот шаг, а потом не могут объяснить собственнику, что изменилось: ощущение «стало лучше» инвестиции не оправдывает.
Порядок действий: пилот, замер, тираж
Один процесс, одно подразделение, замер до и после, и только потом расширение. Такой путь занимает больше времени на бумаге и меньше — в реальности.
Рабочая последовательность выглядит так:
- Выписать процессы и оценить по четырём признакам — выбрать один.
- Описать его по четырём вопросам, отметив точки ожидания.
- Замерить текущее состояние по четырём показателям.
- Проверить, закрывается ли задача настройкой существующих систем.
- Запустить пилот на одном подразделении.
- Через месяц замерить снова и сравнить.
- Только после этого тиражировать на остальные подразделения и брать следующий процесс.
Шаг шестой пропускают чаще остальных — и напрасно: именно он превращает автоматизацию бизнес-процессов из статьи расходов в аргумент для следующего проекта. Когда у руководителя на руках цифры по первому процессу, разговор о втором идёт совсем иначе.
Частые вопросы
Коротко о том, что спрашивают чаще всего: с чего начинать при множестве проблемных процессов, нужна ли формальная нотация, сколько занимает внедрение и что делать с сопротивлением сотрудников.
С чего начать, если процессов много и все проблемные?
Оценить по четырём признакам из второго раздела и взять один — с наибольшей суммой. Параллельно запускать два процесса не стоит: сопротивление складывается, а внимание руководителя делится.
Нужно ли описывать процессы в BPMN?
На этапе выбора и пилота — нет, хватает таблицы по четырём вопросам. Формальная нотация нужна, когда появляется сложная логика с ветвлениями и параллельными согласованиями, и когда описание передаётся разработчикам.
Сколько занимает внедрение одного процесса?
Зависит от того, хватает ли настройки существующих систем. Настройка типового процесса в уже работающей CRM или на портале — это недели; разработка под нестандартную логику или интеграция нескольких систем — месяцы. Точный срок называется после описания процесса, а не до.
Что делать, если сотрудники саботируют новую систему?
Проверить две вещи: понимает ли человек, что изменится лично для него, и не добавили ли ему работы, ничего не убрав. Если система только фиксирует действия и ничего не упрощает, сопротивление обоснованно и техническими средствами не лечится.
Можно ли автоматизировать процесс, не меняя его?
Иногда да, но чаще нет — и это нормально. Автоматизация бизнес-процессов обнажает шаги, которые существуют по историческим причинам. Их убирают до внедрения, а не после.