Роботизированная автоматизация процессов (RPA) — это надежное и экономичное решение для автоматизации повторяющихся цифровых процессов.

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

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

Моделирование автоматизации процессов с использованием этого подхода полезно, поскольку оно различает роли ввода данных и принятия решений, которыми люди жонглируют. Это принципиально разные роли, если смотреть с точки зрения автоматизации. Хотя цифровые процессы (синие линии), представляющие нажатия клавиш и щелчки мышью, можно автоматизировать с помощью инструментов RPA, задачи принятия решений (оранжевые круги) являются более сложными. За каждым оранжевым кругом стоит человек, обладающий интуицией, который активно учится на работе, чтобы принимать правильные решения. Успешная реализация RPA требует такой же способности «жонглировать» этими разрозненными типами задач, чтобы по-настоящему автоматизировать рабочий процесс.

Руководящие принципы и допущения

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

Наша позиция заключается в том, что обучающие системы (ML, AI и т. д.) должны быть интегрированы, чтобы справляться с капризами принятия решений, с которыми сейчас сталкиваются люди. И что важно, учитывая, что многие бизнес-процессы достаточно сложны, чтобы в обозримом будущем потребуются люди, люди также должны быть интегрированы. Если все сделано правильно, это многосистемное решение сможет заменить старое, моделируя различные роли, которые сейчас играют люди, используя наиболее подходящую систему.

Принцип 1: Ограничьте длину автоматизации

Любая организация достаточного масштаба находится под постоянным давлением окружающей среды, требующей адаптации существующих бизнес-процессов. С точки зрения автоматизации это означает, что более длительная автоматизация (состоящая из многих шагов и/или многих систем) с большей вероятностью рассинхронизируется, чем более короткая. Например, для удобства обслуживания в долгосрочной перспективе было бы лучше создать два сегмента автоматизации (D3 и D4) вместо одного более длинного сегмента.

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

Принцип 2: относитесь к автоматизации как к программному обеспечению

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

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

  • Идентифицировать | Определите цифровые процессы, которые можно автоматизировать, и ответственных лиц.
  • Разработка| Запишите автоматизацию/с.
  • Тестирование/контроль качества | Проверить качество автоматики. Можно ли использовать автоматизацию для проверки автоматизации? Другими словами, можно ли проверить автоматизацию, связанную с системными обновлениями, путем создания второй автоматизации, которая может проверить ожидаемый результат?
  • Развернуть | Каталогизируйте каждую автоматизацию, включая входы и выходы. Автоматизация должна быть обнаруживаемой и вызываемой.
  • Оценить | Отслеживайте использование автоматизации. Определите, насколько успешно автоматизация работала с течением времени (пригодность и достоверность). Определите и повторите.

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

Принцип 3: Проектируйте автоматизацию без сохранения состояния

без сохранения состояния имеет решающее значение для масштабируемых систем, поскольку позволяет выполнять параллелизм изолированно. Этот подход без сохранения состояния хорошо масштабируется и является общим для систем с высокой пропускной способностью, таких как HTTP. В следующем рабочем процессе автоматизация D1, D2 и D3 будет работать без сохранения состояния после развертывания в качестве автоматизации RPA.

При правильном выполнении цифровые сегменты D1, D2 и D3 будут автоматизированы и каталогизированы, включая их входы и выходы. Индекс автоматизации фактически представляет собой RESTful API, который будет вызываться уровнем оркестровки.

Принцип 4: Проектируйте оркестровки с отслеживанием состояния

Снова рассмотрим следующую последовательность операций, включающую цифровые и ручные подпроцессы. До RPA пользователь решил открыть программное приложение (H1), чтобы завершить первый этап цифрового процесса адаптации (D1). Затем пользователь должен решить (H2), завершить ли процесс D2, D3 или M2. В такой системе именно сотрудник отслеживает состояние, сохраняя все знания, необходимые для выбора следующего этапа процесса.

В предлагаемой системе уровень оркестровки заменит инициированные человеком точки принятия решений (H1 и H2) стратегией, опосредованной Slack. Например, вместо того, чтобы использовать старую систему для ввода данных и адаптации нового сотрудника, пользователь может открыть Slack и ввести команду с косой чертой, например «/ onboard» (правая часть диаграммы). Тогда уровень оркестрации будет владеть процессом, запрашивая у пользователя всю информацию, требуемую D1. Затем он вызовет автоматизацию D1 и приостановит ее до завершения. Наконец, оркестрация в последний раз отправляла пользователю сообщение (через Slack), чтобы выбрать, следует ли запустить автоматизацию D2 или D3 или начать ручной шаг M2.

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

Принцип 5: Формализуйте изменения

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

В этом конкретном примере поток был спроектирован так, чтобы «сбой», когда служба NLP возвращает показатель достоверности ниже 80%. Затем он направляет вызов реальному человеку в Slack для надлежащей обработки (подключиться к человеку). Наконец, он регистрирует неудачную фразу, чтобы предоставить модели обратную связь, чтобы лучше обработать ее в следующий раз, когда она произойдет.

Отдельный рабочий процесс обрабатывает событие «Низкая достоверность». Он начинается с отправки сообщения в Slack, предлагая пользователям классифицировать фразу. Как только они ответят необходимыми подробностями, категоризированный объект сворачивается обратно в исходную модель, обучая ее обрабатывать фразу (и подобные варианты). Это цикл обратной связи в реальном времени, который формализует долгосрочное обучение и устранение ошибок в реальном времени.

Вывод

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