Как достичь гармонии между автоматизацией и роботизацией бизнес-процессов


Оригинал: Process Automation In Harmony With RPA
Автор: Бернд Рюкер (Bernd Rücker)

На конференции Camunda Con Live 2020 компания Deutsche Telekom поделилась своим опытом автоматизации и роботизации бизнес-процессов. Я был настолько впечатлен этой историей, что мне захотелось немедленно ею поделиться. Итак, в этом посте я:

  • Подробно расскажу о кейсе Deutsche Telekom, их первоначальных успехах в роботизации процессов и проистекающих из успехов проблемах.
  • Опишу ключевые стратегии, такие как разделение оркестратора и бота (иначе говоря «отделение процесса от автоматизации задач») и приоритет интеграции на бэкенде над интеграцией на фронтенде (другими словами, «приоритет API перед ботами»).

Пройденный Deutsche Telekom путь представлен на слайде выше.

  1. На начальном этапе процессы автоматизировались при помощи RPA без привлечения ИТ-специалистов. Это позволило быстро сократить издержки, но вскоре компания столкнулась с серьезными проблемами (они называют эту стадию «сарай»).
  2. Затем был добавлен уровень оркестровки («прочный фундамент»).
  3. В итоге они стремятся уйти от RPA-ботов к вызовам API всюду где можно («трансформация»).

Теперь рассмотрим этот кейс подробнее.

Первоначальный успех с RPA

В 2015 году техник на вызове, чтобы провести диагностику телефонной линии клиента, должен был сперва с другого номера вызвать коллегу в офисе компании. Обычно ему приходилось ждать ответа от 3 до 5 минут. Техник сообщал номер телефонной линии, требующей проверки, после чего сотрудник в офисе проверял линию при помощи тестера. Для технического персонала этот процесс был малоприятным (медленным, однообразным, подверженным ошибкам), и к тому же он дорого обходился Deutsche Telekom (был трудоемким).

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

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

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

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

Катастрофа от успеха и очередные вызовы

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

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

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

Переосмысление подхода к RPA

Deutsche Telekom не стал мириться с возникшими проблемами и приступил к реализации новой стратегии, преследовавшей три основные цели:

  1. Разграничить уровень процесса и уровень бота. Я бы это назвал «изолировать бизнес-логику от технических деталей реализации конкретных задач, в частности, абстрагироваться от механизмов роботизации процессов».
  2. Внедрить новый подход к управлению процессами и консолидировать платформу: им явно хотелось уменьшить число используемых технологий.
  3. Перейти от front-end к back-end автоматизации: они хотели заменить RPA-ботов (front-end integration) вызовами API (back-end integration).

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

Выделение уровня оркестровки

Deutsche Telekom построила новую платформу (OREO), использующую Camunda в качестве процессного движка. Сквозные процессы, смоделированные в BPMN, выполнялись движком Camunda, и управляли RPA-ботами, а также задачами других типов, такими как пользовательские задачи или вызовы сервисов.

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

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

От front-end к back-end автоматизации

Боты по-прежнему сильнее подвержены сбоям, чем вызовы API, поэтому замена бота настоящим API делает автоматизацию процессов более стабильной и эффективной. Сегодня Deutsche Telekom предпочитает API-вызовы (back-end automation) RPA-ботам (front-end automation), а также реализует проекты по замене существующих ботов.

Путь Deutsche Telekom

Резюмируя вышесказанное, можно сказать, что Deutsche Telekom на пути повышения зрелости своих бизнес-процессов прошла следующие этапы:

  1. Изначально бизнес-процессы рождаются из работы сотрудников, выполняемой вручную — например, с помощью переписки по электронной почты или телефонных звонков — а также с помощью унаследованных систем (как в примере с проверкой телефонной линии выше).
  2. RPA выступает в качестве палочки-выручалочки – автоматизации, имитирующей ручные операции в автоматическом режиме. Количество ручного труда снижается, но возникают проблемы, рассмотренные выше. Для Deutsche Telekom этот период пришелся на 2015–2019 годы.
  3. Начиная с 2019 года, бизнес-процессы были выделены в отдельный уровень, что улучшило их визуальное восприятие и понимание и облегчило оптимизацию.
  4. С конца 2020 года компания не только стала отдавать предпочтение API вызовам перед ботами, но и перешла к активной замене ботов последними, стремясь сделать автоматизацию процессов более стабильной и эффективной.

Удивительная находка

Разбирая этот кейс, я обнаружил одну весьма любопытную тенденцию: оказывается, внедрение технологий RPA способствовало улучшению взаимодействия между бизнесом и ИТ внутри Deutsche Telekom. Как это произошло? Я привык считать, что бизнес старается избегать ИТ где только возможно (и поэтому RPA приходится как нельзя кстати), а с другой стороны, ИТ ненавидит RPA всей душой из-за «хрупкости» этой технологии.

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

Впечатляющие цифры

Судя по всему, такой подход работает отлично. Deutsche Telekom продвинулась существенно дальше, чем большинство европейских компаний, разработав для автоматизации и повышения эффективности бизнес-процессов свыше 2500 RPA-ботов, обрабатывающих более 40 млн успешных транзакций, каждая из которых экономит более 2 евро. Таким образом достигается ощутимая экономия, повышается качество процессов, растет удовлетворенность клиентов и сотрудников. В общей сложности в компании автоматизировали почти 500 процессов. По оценкам Deutsche Telekom, каждый евро, вложенный в автоматизацию процессов, приносит три евро. Доля автоматизации в обслуживании клиентов достигла почти 10 процентов.

Выводы

Стратегия, описанная здесь, является интересным примером для подражания:

  • Используйте BPMN для автоматизации бизнес-процессов
  • Используйте RPA для автоматизации задач в рамках процесса
  • Эти процессы могут управлять не только роботами, но и людьми или другими системами
  • Бота целесообразно использовать в качестве временного решения, если у вас есть стратегия последующей замены бота (front-end integration) на вызов API (back-end integration).

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

Обсудить