Приходит бизнес к архитекторам и говорит: «У меня есть задачка для доработки системы. Подскажите, кто мне поможет её решить».

Архитектура отвечает: «Вы можете сходить к 1С-никам или сапёрам, и в зависимости от того, чем вы там пользуетесь, вам запилят кнопку в системе. Или можно сходить, например, к роботизаторам — там сделают робота, который автоматизирует процесс».

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

Как мы дошли до жизни такой

Мы одни из первых, кто начинал внедрять RPA еще в 2017 году. Инициатива пилотного проекта исходила от руководства: «Вот есть идея с роботами, люди говорят, что она рабочая. Посмотрите, какие эффекты можно получить от RPA».

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

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

В айтишном сообществе многие думают, что роботы — это просто скрипты, которые можно написать на Python, C# и т. д. Но если мы будем делать это скриптами, то это получится довольно-таки долго и дорого, что делает бессмысленным весь подход с RPA.

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

На тот момент времени выбирать RPA-платформу особо не приходилось. В 2017-м было доступно несколько иностранных решений, российских платформ не было совсем. Остановились на одном из лидеров рынка — UiPath. Настроили процессы, построили центр экспертизы, наладили отношения с заказчиками и всеми службами, чтобы поставить всё это на конвейер.

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

Сегодня у нас в эксплуатации — более 450 роботизированных сценариев с общей экономией более 250 FTE и 90 сотрудников в Центре компетенций по программной роботизации.

Начало

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

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

В 2019 году мы приступили к формированию и согласованию отраслевых регламентов, которые, по сути, стали методологией внедрения программных роботов для атомной отрасли. Я до сих пор считаю, что 2/3 работы при внедрении RPA, — это методология.

При выстраивании методологии мы решили следующие задачи:

1. Снижение объёма и трудоёмкости написания и согласования документации.
2. Определение и описание взаимодействия всех ролей, которые участвуют в проектах роботизации: бизнес (заказчики) — исполнители (ЦК по роботизации) — владельцы систем, с которыми работают наши роботы — информационная безопасность.
3. Выстраивание процесса поддержки выпущенных в эксплуатацию роботов.

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

Плюсы, минусы, ограничения RPA

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

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

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

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

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

Если вы уже задумались, что было бы неплохо полностью переложить все процессы на роботов, — стоит отказаться от идеи чёрно-белого мира. Не так много процессов, которые на 100 % можно переложить на алгоритмы: обычно это 50, 70 или максимум 90 % последовательных операций внутри бизнес-процесса, где не требуется творческий потенциал человека. Остальную «креативную» часть продолжают выполняют люди, и такой подход всех устраивает. Бизнес экономит время сотрудников на рутинные операции и может выполнять больший объём работы без расширения штата. Сотрудники довольны тем, что роботы забирают у них рутину и могут заниматься более интересными и важными вещами, реже сталкиваясь с переработками или необходимостью срочно исправлять ошибки.

Но есть нюансы

Пара моментов, о которых стоить знать тем, кто планирует погрузиться в мир программной роботизации.

Первый: мы часто ссылаемся на то, что RPA — это быстрый и относительно дешёвый инструмент автоматизации. Но у любой медали — две стороны. Обратная сторона — это необходимость поддержки роботов. Большая их часть взаимодействует с интерфейсами не только статичных приложений типа того же Excel, но и с корпоративными системами, различными порталами и сайтами. И делать они это будут тоже через интерфейс, потому что применять роботов вы захотите именно там, где будут проблемы с прямым взаимодействием с базами данных или API. При обновлении интерфейсов этих систем и сайтов роботы могут перестать понимать, как с ним взаимодействовать, и роботизированный процесс остановится.

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

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

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

По этой причине программная роботизация в малом бизнесе распространена несильно. Хотя на моём опыте были компании в 20–30 человек, которые вполне успешно внедряли у себя RPA и при таком штате.

Где и как мы применяем роботов: примеры

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

1. Бухгалтерия и налоговый учёт.
2. Управление персоналом.
3. Электронный документооборот.

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

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

Роботизация электронного документооборота востребована в корпорациях, где объём ЭДО сам по себе большой.

Есть наблюдение, что иногда роботы в ЭДО не несут в себе прямого экономического эффекта, но дают снижение рисков. И такое обоснование бывает достаточным для получения финансирования.

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

Как искать процессы для программной роботизации? Доверьтесь пользователю

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

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

Проблема в том, что небольшие, но необходимые процессы не лежат на поверхности. О них не знают ни исполнители, ни руководители отделов и управлений. А знают о них только сотрудники на местах, которые ежедневно выполняют эти процессы руками. Именно эти люди и знают, где необходимы роботы. И здесь у команд, которые решили заниматься внедрением RPA, есть два варианта, куда идти (про вариант не идти вообще, мы здесь не говорим).

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

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

Звучит классно, но как этого добиться?

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

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

В общем, это такая цепочка: первое — поиск процессов, далее — аналитика, третье — разработка и запуск в эксплуатацию, четвёртое — поддержка. Это то, чем занимается Центр экспертизы по программной роботизации.

В последние годы RPA пробовали многие более-менее крупные компании, но те из них, где программная роботизация процветает, можно пересчитать по пальцам. Остальные сделали 5–10 роботов, сказали себе: «Ну да, мы внедрили в RPA», и на этом закончили.

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

Теперь немного — про технину

Мы упоминали, что программных роботов пилят на специализированных платформах.
И обычно опытные разработчики их несильно приветствуют, но любят бизнес и начинающие программисты.

Какие требования стоит предъявлять к платформе?

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

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

И было бы кощунством не рассказать немного про собственную платформу — Атом.РИТА (Роботизированный Интеллектуальный Технологичный Ассистент).

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

У RPA-платформ — два основных назначения: удешевить разработку и сделать процесс поддержки роботов более управляемым. Это происходит за счёт среды разработки в виде визуального конструктора и модуля оркестрирования. От того, насколько интуитивно понятно работать с платформой, насколько она богата на встроенные механизмы взаимодействия с системами, и будут зависеть необходимые минимальные навыки разработчика. Поработав несколько лет на платформе от мирового лидера, мы знали, как нужно делать и что можно сделать лучше.

В моменте, когда в вашем ведении появляется несколько десятков роботов, возникают и вопросы по мониторингу, управлению очередями задач, хранением ресурсов (например, учёток от систем), которые используют роботы. С модуля оркестратора как раз началась разработка платформы. Когда мы начали отказываться от UiPath, то какое-то время разрабатывали роботов на коде, и было важно в первую очередь организовать централизованное управление скриптами.

Так, помимо обычного технического функционала оркестратора, Атом.РИТА научилась запускать роботов не только по расписанию, но и по событиям. А бизнес теперь может самостоятельно, залогинившись в веб-приложении, посмотреть аналитику по своим роботам.

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

Было логично зарегистрировать платформу в реестре отечественного ПО и предлагать её компаниям со сформированным центром экспертизы по RPA для миграции с уходящих иностранных вендоров. Так к пользователям Атом.РИТА присоединилась команда X5 Group. Мы помогли коллегам провести рефакторинг 150 роботизированных процессов и мигрировать роботов на нашу платформу. К нам продолжают приходить новые запросы от других компаний, что очень радует: значит, нам удалось вывести продукт внутренней разработки на внеотраслевой рынок.

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

Куда мы движемся?

Как и любой старый Центр компетенции, мы не только продолжаем роботизировать новые процессы, но и расширяем возможность применения уже разработанных роботов. Мы прощупываем разные популярные и не слишком идеи. Пока нам удалось оценить пользу применения машинного обучения в задачах классификации текста. С помощью одной модели можно избежать избыточной настройки робота для отработки сотни условий. Мы давно работаем над собственным OCR-движком, уже довели его до возможности работы с документами без чёткой структуры. Хотя это уже и отдельный продукт, но движок тесно интегрирован с Атом.РИТА. Сейчас ещё активно прощупываем историю с применением LLM-моделей вместе с программными роботами. Надеюсь, и тут в будущем будет чем поделиться!