Я роботизатор, который занимается автоматизацией рутинных задач в банке. Чтобы справиться с потоком таких задач, мы начали использовать технологию RPA (robotic process automation), которая имитирует действия человека на уровне пользовательского интерфейса.

Внедрение RPA в банковской сфере не требует существенных изменений в инфраструктуре и представляет собой слой, который накладывается поверх существующих банковских приложений.

Технология RPA начала развиваться ещё в начале 2000-х. В последние годы она получила широкое распространение благодаря своим простоте внедрения и быстрому возврату инвестиций.

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

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

Несложный сценарий, несколько атомарных процессов, остаётся только запрограммировать их — и готово!

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

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

Вот об этом я и хочу рассказать.

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

Критерии отбора сценариев для RPA

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

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

Следующий определяющий фактор — это возможность алгоритмизировать данный процесс.

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

Чем наш подход в проектировании роботов отличается от стандартного?

Платформа для разработки роботов предлагает основываться на наборе лучших практик или «шаблонов», которые она предлагает. Самый популярный из них — «Robotic Enterprise Framework», или сокращённо — «ReFramework». Методов разработки на базе такой платформы может быть несколько, вот и мы разработали и внедрили свой способ написания роботов, или, если хотите, собственный «шаблон» в дополнение к существующему

Причина этого следующая. Хотя все поставщики RPA-платформ и утверждают, что роботов писать легко и это может делать даже человек, не имеющий навыков в IT, на самом деле это не совсем так. Это касается только самых простых решений. Если же необходимо роботизировать сложные и большие процессы, в которых есть много условий и ветвей, то для этого всё же нужна определённая подготовка. Есть разница в том, что строить — простой сарай на даче или дом, в котором предполагается жить. Во втором случае вам сначала нужно создать подробный план всех помещений и коммуникаций.

Ценность нашего «шаблона» именно в том, что он вынуждает разработчика, прежде чем начинать писать сложного робота, грамотно его спроектировать и составить план разработки.

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



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

В случае с ReFramework, заказы будут помещены в очередь в таком виде (Таблица 1, Схема 1):
Таблица 1


Схема 1

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

Последним действием робот инициировал выгрузку документов из 1С обратно в бэкофисную систему. Все эти действия зависят друг от друга и поэтому должны выполняться последовательно. Для того, чтобы все работало как надо, была реализована дополнительная логика, кроме того, некоторые этапы были укрупнены, что сделало робота более монолитным.

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

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

На схеме 2 показано, как выглядит очередь заказов робота кофемейкера в случае с нашим фреймворком:


Схема 2

Обе схемы в сравнении:



ReFramework взаимосвязей между отдельными шагами обычно не учитывает, если его не доработать. В сущности, мы взяли его и сделали возможность устанавливать связи между атомарными шагами.

Сам проект в фреймворке разделён на три уровня: верхний — это дизайн процесса, средний — инфраструктура, а нижний — реализация конкретных модулей робота.

Теперь, прежде чем начинать писать робота, проделывается предметная аналитическая работа, основанная на описании процесса, который даёт заказчик. И чем лучше мы спроектируем процесс на начальном этапе, чем больше детализируем, насколько продумаем, как всё разложить, тем проще будет разработка. Т. е. мы создаём план, рисуя «квадратики» в визуальном редакторе.

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

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

Связи между уровнями фреймворка

С одной стороны, все уровни работают друг с другом в связке, с другой — каждый уровень имеет свои функциональные обязанности.

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

Редактор позволяет схематично обозначить шаги процесса, и «привязать» к ним исполняемые модули. На выходе активность собирает готовую схему в json. Такой формат позволяет хранить данные о сценарии где угодно (в ассете, в элементе очереди, в базе данных и т. д). На данном уровне ничего неизвестно о реализации конкретных этапов. Cхема процесса определяет лишь последовательность и логику взаимосвязей между ними.

Инфраструктура. Функционал этого уровня стандартный и практически не требует изменений.

Можно выделить два ключевых назначения.

Первое: исполнение схемы процесса. Инфраструктуре на вход подаётся сгенерированный ранее json, который читается и выполняется в точном соответствии с тем, что там написано (что нарисовали, то и запускается, в каком порядке скомпоновали этапы процесса, в таком они и запускаются). На каждом этапе сценария происходит вызов модуля, к которому тот был привязан при проектировании схемы процесса.

Второе: инструменты и служебные функции, которые поддерживают инфраструктуру фреймворка, включая работу с очередями, обработку исключений, логирование и т. д.

Инфраструктура ничего не знает о реализации конкретных этапов и не зависит от логики сценариев процесса.

Модули. Здесь как раз реализуются основной функционал робота по взаимодействию с UI и другая логика, приводящая в конечном итоге к некоторому бизнес-результату (подготовка отчёта, проверка данных в АС и т. д.). Каждый конкретный модуль ничего не знает о том, кто его вызывает, не знает, какой модуль был обработан до него и какой будет выполняться следующим.

Достоинства нового фреймворка

Новое решение помогает лучше декомпозировать сложный проект на отдельные бизнес-модули, которые слабо зависят друг от друга (изменения в одном модуле не влияют на функционирование другого). Теперь можно распределить сложный проект между несколькими разработчиками, где каждый будет отвечать только за свой независимый модуль. И поскольку каждый модуль нацелен на выполнение одной конкретной бизнес-задачи, разработать и протестировать подобные модули могут специалисты с небольшим опытом (джуны). В итоге распределение нагрузки между опытными разработчиками и новичками может стать более сбалансированным.

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

Модули могут запускать код удалённо (через подпроцессы) или вообще вызывать сторонние сервисы. В таком случае доработка конкретного модуля/сервиса вообще не требует вмешательства в проект основного робота.

Используя визуальный редактор для планирования, легче читать проект и понимать бизнес-логику робота. Это важно как для самого разработчика, так и для специалиста, который сопровождает робота. Такой подход также существенно упрощает и упорядочивает сценарий проведения code review. Проект рассматривается как с точки зрения архитектурной логики (как декомпозирован процесс), так и с точки зрения реализации каждого модуля.

Как это работает

Давайте рассмотрим работу системы на конкретном кейсе создания робота. По запросу заказчика из филиала банка робот должен найти в SPARK информацию по клиенту — юридическому лицу и проанализировать финансовые результаты за последний год. Признак финансового результата (положительный/отрицательный) нужно внести в АС «Корпоративные Риски». Если программа получает отрицательный результат для клиента, то робот проверяет наличие у него действующих договоров в АС «Договоры». И если такие договоры имеются, то нужно оповестить всех заинтересованных лиц.

Дизайн

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



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

Модули могут быть созданы в текущем проекте и не содержать реализации либо вообще ссылаться на запуск подпроцесса в другом проекте. На этапе проектирования конкретная реализация неважна.

Готовая схема процесса выгружается в json — в нашем примере мы будем хранить json в элементе очереди.

Инфраструктура

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

На данном этапе робота уже можно запустить, а в модулях реализовать заглушку в виде логов.

Таким образом можно проверить выполнение логики процесса без конкретной реализации.

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

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

Реализация

После того как логика робота проверена, разработчик приступает к реализации каждого модуля.

Также возможно распараллеливание работ, когда модули распределяются между разработчиками.

Работа над каждым модулем ведётся в отдельной ветке системы контроля версий и по готовности вливается в мастер-ветку.

Продолжение кейса

В ходе презентации робота заказчику выясняется, что для клиентов головного офиса не требуется выполнять поиск договоров клиента и кого-либо оповещать.

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

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

Второе изменение кейса

Через три месяца после запуска робота к нам приходит заказчик и говорит, что через неделю стартует пилотный проект по переводу банка из АС «Корпоративные Риски» в АС «Риски». По плану весь банк должен быть переведён на новую систему в течение года. Каждый месяц один филиал будут отключать от старого ПО (АС «Корпоративные Риски») и переводить на новое (АС «Риски»). Робот должен работать как в старой версии, так и в новой.

С точки зрения доработок разработчику требуется создать новый дизайн процесса, в котором шаг 4 (АС «Корпоративные Риски») будет изменён на шаг 4.1 (АС «Риски»).

Далее нужно будет реализовать новый модуль по работе с АС «Риски».

Как фреймворк ускоряет работу: реальный кейс

К нам поступил заказ на разработку огромного робота по оценке качества кредитов клиентов.

Описание процесса — на 20 страницах, на вход роботу поступает 70 атрибутов.

Задача сложная, и вот почему:

• Вызов № 1 — процесс огромный и вариативный.
• Вызов № 2 — есть жёсткий дедлайн: нам дано три месяца на доступы и разработку.
• Вызов № 3 — есть жёсткий дедлайн на первичную обработку данных (10 дней).
• Вызов № 4 — объём первичной обработки: 10 000 заявок. Время на обработку одной заявки — 10 минут. (Если посмотреть на математику, то вся работа для одного робота должна занять 70 суток. Мы могли выделить 15 роботов. Иными словами, это где-то 4,7 суток бесперебойной работы, где ни один робот не должен останавливаться ни на секунду.)
• Вызов № 5 — два человека на разработку робота.

Первый месяц мы потратили на получение доступов и аналитику процессов. Весь процесс был разбит на 12 сценариев (12 схем). Изначально проектировали в Visio с консультацией методологов.

Собственно на разработку нам осталось два месяца (42 рабочих дня).

Сначала мы оценили объём работ. Подсчитали количество шагов во всех сценариях процесса — получилось почти 90, из них 30 — уникальных. Получалось где-то чуть более двух дней на разработку одного модуля (плюс сборка робота, плюс тестовые прогоны). Стало понятно, что требуется выделить двух человек на данную задачу с загрузкой на 100%.

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

Для того чтобы успеть обработать все задачи, было задействовано 15 роботов с поправками на всякие непредвиденные случаи.

В итоге робот был реализован и запущен в срок. Первичная обработка была выполнена за семь дней.

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