Роботизированная автоматизация процессов в том виде, в каком мы ее знаем сегодня, представляет собой структуру, с помощью которой можно автоматизировать крупномасштабные процессы. Самым большим преимуществом современных систем RPA является то, что их можно легко интегрировать с текущими ИТ и программными системами.
RPA можно использовать для автоматизации повторяющейся работы, основанной на процессах, с четко определенными результатами. Однако есть одна загвоздка. Если это автоматизация процессов, то почему бы нам просто не назвать ее автоматизацией процессов? Помимо маркетингового смысла использования слова «роботизация» в автоматизации процессов, тот, кто придумал этот термин, имел в виду нечто большее, чем просто автоматизация процессов.
Намерение и стремление автоматизировать рабочие процессы не новы. В традиционных системах автоматизация достигается за счет того, что разработчики программного обеспечения создают исчерпывающий список API или сценариев, чтобы охватить все заранее задуманные и возможные задачи. Однако у этого подхода был серьезный недостаток, он не был масштабируемым. В современных RPA-системах вместо написания конечного числа сценариев программные системы обучены понимать любое количество выполняемых шагов, записывая фактический процесс, а затем воспроизводя то же самое, что было записано с помощью платформы RPA. Поколение 90-х годов, которое широко использовало Excel для написания макросов для записи набора стандартных действий, а затем сохраняло их так, чтобы каждый раз при запуске этого набора процессов выполнялся сложный, но четко определенный набор процессов в определенной последовательности. Это также называлось макросом Excel. Нынешние платформы RPA работают по схожим принципам, но в гораздо большем масштабе сложности и размера с использованием передовых технологий.
Хотя это решает проблему масштаба, остается еще одна последняя проблема. Значение слова «роботизированный» связано с тем, что от процесса автоматизации, осуществляемого платформой RPA, ожидается элемент интеллекта. Этот интеллект позволяет платформе принимать автономные решения на основе
курок. Хотя триггер можно запрограммировать, это не относится к дереву решений, которое активирует триггер.
Большинство программ RPA, таких как UIPath, Blue Prism и Automation Anywhere, до сих пор выпускались с платформами, которые очень хорошо автоматизируют процессы, будучи запрограммированы на выполнение определенного набора стандартных процессов. Тем не менее, они терпят неудачу, когда дело доходит до того, чтобы сделать весь процесс разумным. Им не удается перейти от автоматических платформ к автономным.
Проиллюстрируем это примером. Предположим, что имеется сложный отчет высшего руководства, который создается путем сопоставления определенных строк данных из различных корпоративных баз данных, таких как Oracle, SAP и других. После создания отчета 500 пользователям рассылается автоматическое письмо с конкретным содержанием для каждого пользователя.
Этот процесс повторяется, поскольку необходимо создать несколько отчетов из нескольких источников данных. Это сложный процесс с огромными масштабами данных, оказывающих мультипликативное воздействие на каждый из настраиваемых отчетов, созданных для более чем 500 заинтересованных сторон, которые затем отправляются по электронной почте предполагаемым получателям.
Звучит как довольно сложный процесс, но сегодняшние RPA-платформы позволяют легко с этим справиться и повторять автоматизацию процессов с минимальными ошибками. Это не требует большой разработки на существующих платформах RPA. Как уже упоминалось, его также можно легко интегрировать в несколько платформ, упомянутых ранее. Однако в текущих реализациях по-прежнему отсутствует одна важная функция, необходимая для сертификации в качестве настоящей автономной реализации.
Возьмем в качестве примера один конкретный вариант использования, если платформа RPA должна решить, кому отправлять отчеты, на основе некоторого критического случайного содержимого отчетов, которое может быть изображением, текстом или числом, и оно может появляться в случайном порядке, платформа не сможет этого сделать. Он потерпит неудачу по той простой причине, что он не знает, как обнаруживать и решать неизвестные ситуации и решения по ним, потому что это не является частью стандартного процесса.
Точно так же многие другие варианты использования отсутствуют на текущих платформах RPA. Хотя они утверждают, что некоторые из них поддерживают ИИ, большинство из них еще не реализованы.
Основная причина такого недостатка в том, что ИИ не является ядром разработчиков автоматизации процессов. Естественно, они скептически относятся к инвестированию в эту область, и это правильно. Им будет сложно развить такую специализированную компетенцию. Таким образом, платформы RPA должны отказаться от слова Robotic, если только их платформы не являются действительно автономными.
Корпоративные клиенты RPA, которые видят реальную и крупномасштабную реализацию своих платформ автоматизации процессов, должны работать с поставщиками услуг ИИ, такими как Affine, чтобы иметь возможность добавить элемент интеллекта и настоящие автономные возможности к уже реализованной автоматизации процессов.
Здесь не следует опасаться интеграции, потому что так же, как платформы RPA могут быть легко интегрированы в существующие системы, модули ИИ также могут быть интегрированы либо в модули RPA, либо напрямую в конечные системы.
Именно тогда реализации RPA действительно станут роботизированными по своей природе.
