Описание бизнес-процессов: как подготовить компанию к ИИ

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

Зачем нужно описание бизнес-процессов перед внедрением ИИ

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

Описание процессов решает три задачи.

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

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

Создаёт точку отсчёта. В описании есть время на процесс и метрика. Без них эффект от автоматизации потом не с чем сравнить.

Бывает и побочная польза. При описании может выясниться, что сотрудники выполняют одну задачу по-разному. Владелец процесса сможет разобрать расхождения и согласовать порядок работы ещё до внедрения ИИ.

План описания бизнес-процессов: шесть шагов

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

1. Составьте список процессов по отделам. Продажи, финансы, склад, маркетинг, HR, сервис. На этом шаге достаточно названия и ответственного.
2. Выберите 3–5 процессов для первого описания. Те, что повторяются часто и занимают много времени. Как их оценить, мы разобрали в статье автоматизация бизнес-процессов.
3. Поговорите с исполнителем. Не с руководителем, а с тем, кто делает работу каждый день. Попросите показать процесс на экране на живом примере.
4. Заполните таблицу. Один процесс — одна таблица. Шаблон ниже.
5. Проверьте с владельцем процесса. Руководитель отдела подтверждает, что так и должно быть, или правит правила.
6. Назначьте владельца и дату пересмотра. Процессы меняются. Устаревшие правила нужно сверить до настройки автоматизации.

Объём интервью и правок зависит от числа участников, развилок, исключений и расхождений в работе. Если правила неясны, понадобятся дополнительные вопросы и проверка с владельцем процесса.

Таблица описания бизнес-процесса: шаблон без BPMN

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

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

Скачать шаблон описания бизнес-процесса

Пустой шаблон в CSV содержит 12 полей из таблицы выше. Рядом с каждым можно записать фактический порядок, предлагаемое изменение, владельца и источник сведений. Заполненный условный образец показывает ту же структуру на обработке входящей заявки. Оба файла открываются в табличном редакторе; это рабочие заготовки для интервью, а не стандарт BPMN.

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

Пример: обработка входящей заявки

Пример условный, для иллюстрации шаблона.

По такой таблице можно поставить задачу на пилот: агент готовит результат по правилам и передаёт исключения человеку. Создание сделки и другие записи в системах требуют согласованных прав и проверки. Описание процесса само по себе их не даёт.

Схема обработки входящей заявки

Это пример схемы бизнес-процесса для условной заявки из таблицы выше. Он объединяет шаги и предлагаемые проверки из заполненного CSV. Это учебная схема, без заявления о соответствии BPMN. Будущий порядок и права на запись в CRM сначала утверждает владелец процесса.

Лаймовые стрелки показывают основной ход, фиолетовые полосы выделяют условия и исключения. Подписи задают переходы независимо от цвета.

Текстовая альтернатива. Менеджер читает заявку, проверяет контакт и ищет клиента в CRM. Если клиент не найден, менеджер с согласованными правами создаёт карточку и проверяет её. Если прав нет или проверка не завершена, маршрут ждёт действия уполномоченного человека на шаге 04. Для существующего клиента менеджер использует найденную карточку и проверяет её перед сделкой. Для нового обращения создаёт сделку только у проверенной карточки. При повторе использует существующую сделку по согласованному правилу; если правила нет, останавливается до решения владельца процесса. Затем записывает товар, объём и срок, назначает ответственного. После проверки данных и назначения отправляет первый ответ. Без контакта обращение ждёт уточнения и возвращается к проверке контакта. При споре о владельце назначение ждёт решения руководителя. Жалобы идут в сервис, спам в архив.

Перед утверждением пройдите четыре маршрута:

• Обычная заявка: контакт есть, клиента в CRM нет. Менеджер с согласованными правами создаёт и проверяет карточку до сделки; иначе маршрут ждёт уполномоченного человека на шаге 04. После этого можно назначить ответственного, проверить результат и отправить первый ответ.
• Повтор: найдены клиент и текущее обращение. Понятно ли, как использовать существующую сделку по согласованному правилу и остановиться до решения владельца, если правила нет?
• Нет контакта: зафиксированы неполные данные и запрос уточнения. Видно ли, что без ответа нельзя продолжить основной ход?
• Спор о владельце: например, клиент уже у менеджера, а объём требует старшего. Кто принимает решение и с какого шага продолжается работа?

В заполненном CSV краткую запись «создать или связать сделку» в поле «Шаги» уточняем так: если клиент не найден, менеджер с согласованными правами создаёт и проверяет карточку до сделки; без прав или завершённой проверки маршрут ждёт уполномоченного человека на шаге 04. Для нового обращения менеджер создаёт сделку у проверенной карточки, при повторе использует существующую сделку по согласованному правилу либо останавливается до решения владельца. Это предложение для согласования, а не утверждённая политика. В CSV этим переходам соответствуют поля «Начало», «Шаги», «Правила решений», «Исключения» и «Конец». Если для маршрута нет правила, запишите вопрос в колонку «Решение/дата/версия» до утверждения. После согласования описания можно планировать автоматизацию процесса и работу ИИ-агента.

Как разделить текущий и будущий процесс

Продолжим условный пример заявки. Описание «как сейчас» часто называют AS IS, а согласованный будущий порядок — TO BE. Названия не обязательны: важнее сохранить различие в самой таблице.

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

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

Вопросы для интервью с исполнителем

• С чего начинается ваша работа по этому процессу? Что вы видите первым?
• Покажите на последнем примере, что вы делаете шаг за шагом.
• В каких программах вы работаете? Что копируете из одной в другую?
• Где вы принимаете решение? По каким признакам?
• Какие случаи выбиваются из обычного порядка? Как часто?
• Что чаще всего идёт не так?
• Сколько раз в день вы это делаете и сколько минут уходит?

Нотации описания бизнес-процессов: BPMN, EPC, IDEF0

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

Таблица и схема передают разные подробности процесса. Схема BPMN показывает развилки и передачу работы между отделами и может содержать условия на потоках. Сложные бизнес-правила удобно дополнительно документировать текстом. Инструменты описания бизнес-процессов тоже можно выбирать по задаче: таблицы и текстовый документ для старта, редакторы схем, когда процесс сложный, BPM-системы, когда процесс автоматизируют по схеме.

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

Регламенты компании как база знаний для ИИ-агента

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

Регламенты и документы компании обычно разбросаны: часть в общей папке, часть в чатах, часть в головах. Чтобы из этого получилась база регламентов компании, с которой может работать ИИ, нужно несколько правил.

Одно место хранения. База знаний, вики или общий диск со структурой по отделам. Агента подключают к одному источнику, а не к десяти.

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

Короткие пункты и примеры. Например: «Жалобу передаём в сервисную службу». Такое условное правило проще проверить, чем абзац общих слов. Пример решения в спорном случае полезнее трёх абзацев теории.

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

Регламенты обновляются вместе с процессом. Поменяли правило — поправили документ в тот же день. Договорённости с планёрки нужно внести в доступный агенту документ и проверить, как он применяет обновлённое правило.

Система регламентов компании в таком виде становится тем, что мы называем памятью компании: общие знания о продуктах, клиентах и правилах. К этим документам могут обращаться и агент, и новый сотрудник. Владелец базы проверяет, что сведения актуальны и их хватает для ответа. Как такая база подключается к агенту, мы разбирали в статье как создать ИИ-агента.

Как ИИ помогает описать процессы по интервью и записям созвонов

ИИ помогает превратить разговор с исполнителем в черновик документа. Сбор сведений и проверка правил остаются за людьми.

1. Запишите интервью. На созвоне исполнитель показывает процесс на экране и отвечает на вопросы из списка выше. Длительность выбирайте по объёму процесса.
2. Расшифруйте запись. Используйте подходящий сервис транскрибации, затем проверьте неясные фрагменты и атрибуцию реплик по записи.
3. Попросите модель заполнить шаблон. Дайте ей расшифровку и таблицу полей. Отдельно попросите выписать правила решений, исключения и места, где рассказ противоречит сам себе.
4. Сравните несколько интервью. Если процесс делают три человека, попросите модель сопоставить расшифровки и отметить различия, затем проверьте их по записям.
5. Отдайте черновик владельцу процесса. Он правит и утверждает. Это главный шаг: модель знает, как о процессе рассказали, а не как он должен работать.

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

В записях созвонов и переписке с клиентами почти всегда есть персональные данные: имена, телефоны, адреса. Их обработку регулирует 152-ФЗ «О персональных данных». Перед тем как отдавать записи модели, решите, что можно передавать, что нужно обезличить, а что должно остаться внутри компании. Модель и место обработки выбирают по допустимым данным и условиям сервиса. Российский облачный сервис тоже получает данные вне компании. Если передача наружу запрещена, рассматривают локальную модель в согласованной инфраструктуре. О других рисках — в статье риски внедрения ИИ.

Частые ошибки при описании процессов

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

Итог

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

Если хотите пройти этот путь быстрее, начните с аудита бизнес-процессов. Мы проведём интервью с отделами, соберём карту процессов, оценим эффект в часах и рублях и покажем, что из этого стоит отдать ИИ. Дальше по этой карте можно запускать автоматизацию процессов. Или напишите нам, и мы обсудим вашу задачу на вводном созвоне.

Источники

1. Object Management Group: Business Process Model and Notation (BPMN), спецификация.
2. ARIS Community: Event-driven Process Chain (EPC).
3. Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования»: текст документа.
4. КонсультантПлюс: Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».