Как описывать процессы для RPA

«Опишите процесс, и мы его автоматизируем.» Звучит просто. На практике — это момент, где многие проекты RPA спотыкаются. Бизнес описывает процесс своим языком, разработчик понимает по-своему, в итоге робот делает что-то третье.

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

Хорошее описание процесса для RPA — это баланс. Достаточно деталей, чтобы разработчик мог работать. Достаточно структуры, чтобы бизнес мог проверить. И достаточно краткости, чтобы не утонуть в бумаге. В этой статье дам шаблон, который работает на практике.

Почему стандартное описание процесса не подходит для RPA

Классические описания бизнес-процессов (BPMN-диаграммы, регламенты) создаются для людей. А люди умеют додумывать, адаптироваться, принимать решения на лету. «Проверь документ» — человек понимает, что проверять, знает контекст, может задать вопрос, если что-то непонятно.

Робот не умеет додумывать. Ему нужны точные инструкции. Не «проверь документ», а: «открой файл, найди поле "Сумма" в строке 15, сравни с полем "Итого" в строке 45, если расхождение более 0.01 тенге — пометить как ошибку». Это другой уровень детализации.

При этом слишком технические описания непонятны бизнесу. Бизнес должен уметь прочитать описание и сказать: «Да, это то, что мы делаем» или «Нет, тут неправильно». Если документ написан на языке, который бизнес не понимает — теряется контроль.

Хороший шаблон решает обе проблемы: даёт разработчику нужную детализацию и остаётся понятным для бизнеса.

Структура шаблона: из чего состоит описание

Вот из чего состоит рабочее описание процесса для RPA.

Общая информация. Название процесса, владелец со стороны бизнеса, цель автоматизации. Зачем это делаем? Какую проблему решаем? Без этого контекста разработчик будет принимать решения вслепую.

Предусловия и триггеры. Что должно произойти, чтобы процесс начался? Поступила заявка? Наступило время? Появился файл в папке? И какие условия нужны для успешного выполнения?

Входные данные. Что робот получает на входе? Файлы, записи в базе, email-сообщения? Какие поля, в каком формате? Откуда это всё берётся?

Пошаговое описание (happy path). Что робот делает, когда всё идёт по плану. Каждый шаг — конкретное действие. С указанием систем, экранов, полей. Это сердце документа.

Исключения и альтернативные пути. Что делать, если данные неполные? Система недоступна? Значение за пределами нормы? Для каждого типа исключения — конкретное действие.

Выходные данные. Что робот производит на выходе? Документы, записи в системах, уведомления? В каком формате и куда?

Метрики и SLA. Как измерять успех? Сколько транзакций в день? За какое время должна обрабатываться одна? Какой процент исключений — норма?

Доступы и системы. Куда нужен доступ? Какие права? Какие учётки использовать?

Как описывать пошаговый процесс

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

Одно действие — один шаг. Не «открыть систему и ввести данные», а «1. Открыть систему X. 2. Ввести логин в поле "Пользователь". 3. Ввести пароль в поле "Пароль". 4. Нажать кнопку "Войти".» Мелко? Да. Но робот работает именно на таком уровне.

Конкретные имена и идентификаторы. Не «открыть отчёт», а «открыть отчёт "Реестр платежей за период" (код REPORT_PAY_001) в меню "Отчёты → Финансы".» Разработчик должен однозначно найти нужный элемент.

Скриншоты. Картинка стоит тысячи слов. Снимок экрана с выделенными элементами убирает двусмысленность. «Поле "Сумма" — вот оно, красная рамка.»

Формат данных. Не «ввести дату», а «ввести дату в формате ДД.ММ.ГГГГ». Не «скопировать сумму», а «скопировать сумму в формате 12345.67 (разделитель — точка, два знака после запятой)».

Условия и ветвления. Если есть логика «если — то», описывайте явно. «Если поле "Статус" = "Согласовано", перейти к шагу 12. Если "На согласовании" — ждать и проверить через 1 час. Если "Отклонено" — отправить уведомление менеджеру.»

Как описывать исключения

Исключения — то, что забывают чаще всего. А они критичны для успеха.

Начните с вопроса: «Что может пойти не так?» Пройдитесь по каждому шагу и подумайте: какие проблемы возможны? Система не отвечает, данные неполные, значение некорректное, нет прав доступа, файл не найден...

Для каждого исключения определите: тип (техническое, бизнес), вероятность (часто/редко), действие робота. Возможные действия: повторить попытку, пропустить и продолжить, остановиться и уведомить, эскалировать человеку.

Группируйте исключения по типам. «Все ошибки доступа к системе X — повторить 3 раза с паузой 1 минута, при неуспехе — уведомить администратора.» Это проще, чем описывать каждую ошибку отдельно.

Не забывайте про бизнес-исключения. «Сумма превышает 1 000 000 тенге — отправить на ручную проверку.» Это не ошибка системы, но случай, который требует отдельной обработки.

Укажите приоритеты. Какие исключения критичны и требуют немедленной реакции? Какие можно оставить в очереди на завтра?

Пример описания шага

Покажу на примере, как должен выглядеть один шаг в хорошем описании.

Шаг 5. Создание платёжного поручения

Предусловие: Пользователь авторизован в банк-клиенте, открыт раздел «Платежи в тенге».

Действие: Нажать кнопку «Создать платёж» (верхняя панель, синяя кнопка слева). [Скриншот 5.1]

Ожидаемый результат: Открывается форма «Новое платёжное поручение» с пустыми полями.

Заполнить поля:

— «Получатель» — значение из колонки D входного файла (наименование контрагента, как есть)

— «БИН/ИИН получателя» — значение из колонки E (без пробелов)

— «Сумма» — значение из колонки G (формат: число с двумя знаками после точки)

— «Назначение платежа» — значение из колонки H (текст до 210 символов)

Исключения:

— Если БИН/ИИН не проходит валидацию (красная рамка вокруг поля) — записать ошибку в лог, пропустить платёж, перейти к следующему.

— Если сумма превышает 5 000 000 — добавить в очередь на ручное согласование, перейти к следующему.

— Если форма не открылась в течение 10 секунд — обновить страницу, повторить попытку (макс. 3 раза).

Как собирать информацию для описания

Откуда брать детали, чтобы описание было полным и точным?

Интервью с исполнителем. Сядьте рядом с человеком, который делает процесс. Попросите показать, что он делает. Задавайте вопросы: «Почему это поле? Что если здесь пусто? Бывали случаи, когда не получалось?»

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

Анализ исторических данных. Посмотрите логи, тикеты поддержки, отчёты об ошибках. Какие проблемы возникали? Это источник информации об исключениях.

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

Валидация с несколькими исполнителями. Если процесс делают несколько человек — проверьте описание со всеми. Бывает, что разные люди делают по-разному, и нужно стандартизировать.

Частые ошибки в описаниях

Чего избегать при составлении документа.

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

Пропуск «очевидных» шагов. «Авторизуйтесь и создайте документ.» А как авторизоваться? Где кнопка входа? Какие поля заполнять? Очевидное для исполнителя — не очевидно для робота.

Отсутствие информации об ожидании. «Нажмите кнопку.» А потом что? Ждать загрузки? Появится новое окно? Страница обновится? Робот должен знать, чего ждать и как понять, что можно продолжать.

Слишком общие исключения. «Если ошибка — обработать.» Как обработать? Какие ошибки? Это не описание — это пожелание.

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

Контрольный список перед передачей разработчику

Проверьте описание по этому чек-листу перед тем, как отдавать в работу.

Цель и контекст понятны? Триггер процесса определён? Входные данные описаны с форматами? Каждый шаг — конкретное действие? Скриншоты актуальные? Исключения перечислены? Выходные данные определены? Метрики и SLA указаны? Доступы и системы прописаны? Описание провалидировано с исполнителем?

Если на все вопросы «да» — можно передавать. Если есть «нет» — дорабатывать.