Анализ бизнес-процессов перед автоматизацией — как провести и что получить на выходе

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

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

Зачем анализировать, если и так понятно, как работаем

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

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

Шаг первый — границы

Анализ без границ расползается на всю компанию и не заканчивается. Поэтому до начала фиксируются три вещи.

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

Вопрос важнее, чем кажется. От него зависит, что мерить и какую детализацию брать. Анализ «вообще» дает красивую схему и ни одного решения.

Шаг второй — факты, а не рассказы

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

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

Если в компании есть системы с журналом событий, трассировку можно сделать сразу по всем случаям — это называют process mining. Для небольшого объема хватает ручного разбора десятка заказов, для тысяч нужны выгрузка и скрипт.

Шаг третий — интервью и наблюдение

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

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

Шаг четвертый — карта процесса как есть

Из фактов и интервью собирается схема AS IS. Удобнее всего дорожки — по одной на роль или отдел, шаги внутри дорожек, передачи между ними стрелками.

Для анализа перед автоматизацией полная нотация BPMN не обязательна. Она нужна, если процесс сложный и с множеством ветвлений или если схему потом будет исполнять BPM-система. В остальных случаях хватает дорожек и стрелок, которые понимает любой сотрудник.

Детализация — до уровня, где меняется исполнитель или появляется ожидание. Какие поля менеджер заполняет в форме, на этом этапе описывать рано.

Шаг пятый — замеры

Схема без цифр показывает только порядок. Для решения нужны четыре числа по каждому шагу и каждой передаче.

Если данных для замера нет, честно пишется оценка и то, как она получена. Смешать замер и оценку в одной таблице без пометок — верный способ принять решение на выдуманных цифрах.

Шаг шестой — как должно быть и что из этого автоматизировать

Схема TO BE рисуется не как идеальный процесс, а как исправленный. Сначала убирается то, что снимается без системы: лишнее согласование, передача, которая существует по привычке, подпись, которую можно заменить лимитом. Часть потерь уходит уже здесь, и бесплатно.

То, что осталось, делится на три группы.

• Код. Правила, которые записываются условиями, — маршрутизация, расчеты, проверки, уведомления.
• Модель. Разбор входа в свободной форме — писем, звонков, документов. Как делить задачи между кодом, ИИ и людьми, разобрано в статье про ИИ-автоматизацию бизнес-процессов.
• Люди. Решения с высокой ценой ошибки и редкие случаи, автоматизировать которые дороже, чем выполнять руками.

Что должно получиться на выходе

• Схема AS IS с отмеченными точками потерь и цифрами по ним.
• Список потерь, отсортированный по стоимости, а не по громкости жалоб.
• Схема TO BE и перечень изменений, которые не требуют системы.
• Требования к системе для того, что осталось, — роли, объекты, статусы, интеграции.
• Оценка эффекта по каждому пункту, хотя бы порядок величин.

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

Где помогает ИИ при анализе процессов

Две вещи реально ускоряют работу. Первая — расшифровка интервью. Разговор записывается, модель превращает его в текст и выделяет шаги, роли и исключения, а аналитик проверяет и правит вместо того, чтобы конспектировать.

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

Частые ошибки

• Описывать регламент вместо реальности. Схема получается аккуратной и бесполезной.
• Опрашивать только руководителей. Обходные пути остаются невидимыми.
• Детализировать все до кнопок. Анализ тонет в деталях и устаревает раньше, чем закончится.
• Не мерить. Без цифр приоритеты расставляются по тому, кто громче жалуется.
• Разбирать все процессы компании сразу. Один процесс за пару недель дает решение, двадцать процессов за полгода — отчет на полке.

Как выбрать первый процесс и посчитать, окупится ли его автоматизация, — в статье с чего начать автоматизацию бизнес-процессов.

Частые вопросы

Сколько занимает анализ одного процесса

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

Можно ли провести анализ своими силами

Можно, если есть человек, которому доверяют обе стороны — и руководство, и исполнители, — и у него есть время. Сложность не в методе, а в том, что своим про обходные пути рассказывают неохотно. Внешний взгляд полезен именно этим.

Нужен ли анализ, если систему уже выбрали

Да, и даже важнее. Он покажет, какие доработки понадобятся коробке и где процесс придется менять под систему. Лучше узнать это до подписания договора с вендором, а не на внедрении.

Дальше по теме