Оригинал: Process Automation In Harmony With RPA
Автор: Бернд Рюкер (Bernd Rücker)
На конференции Camunda Con Live 2020 компания Deutsche Telekom поделилась своим опытом автоматизации и роботизации бизнес-процессов. Я был настолько впечатлен этой историей, что мне захотелось немедленно ею поделиться. Итак, в этом посте я:
- Подробно расскажу о кейсе Deutsche Telekom, их первоначальных успехах в роботизации процессов и проистекающих из успехов проблемах.
- Опишу ключевые стратегии, такие как разделение оркестратора и бота (иначе говоря «отделение процесса от автоматизации задач») и приоритет интеграции на бэкенде над интеграцией на фронтенде (другими словами, «приоритет API перед ботами»).
Пройденный Deutsche Telekom путь представлен на слайде выше.
- На начальном этапе процессы автоматизировались при помощи RPA без привлечения ИТ-специалистов. Это позволило быстро сократить издержки, но вскоре компания столкнулась с серьезными проблемами (они называют эту стадию «сарай»).
- Затем был добавлен уровень оркестровки («прочный фундамент»).
- В итоге они стремятся уйти от 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 не стал мириться с возникшими проблемами и приступил к реализации новой стратегии, преследовавшей три основные цели:
- Разграничить уровень процесса и уровень бота. Я бы это назвал «изолировать бизнес-логику от технических деталей реализации конкретных задач, в частности, абстрагироваться от механизмов роботизации процессов».
- Внедрить новый подход к управлению процессами и консолидировать платформу: им явно хотелось уменьшить число используемых технологий.
- Перейти от 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 на пути повышения зрелости своих бизнес-процессов прошла следующие этапы:
- Изначально бизнес-процессы рождаются из работы сотрудников, выполняемой вручную — например, с помощью переписки по электронной почты или телефонных звонков — а также с помощью унаследованных систем (как в примере с проверкой телефонной линии выше).
- RPA выступает в качестве палочки-выручалочки – автоматизации, имитирующей ручные операции в автоматическом режиме. Количество ручного труда снижается, но возникают проблемы, рассмотренные выше. Для Deutsche Telekom этот период пришелся на 2015–2019 годы.
- Начиная с 2019 года, бизнес-процессы были выделены в отдельный уровень, что улучшило их визуальное восприятие и понимание и облегчило оптимизацию.
- С конца 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).
Придерживаясь такого подхода, вы сможете создать целостную и хорошо управляемую архитектуру бизнес-процессов, и у вас появится возможность быстро двигаться вперед, используя какие-то временные решения, но без наращивания технического долга.
Обсудить