Аналитический подход к роботизации: как это работает

Cергей Ложкин, исполнительный директор компании PIX Robotics, анализирует тенденции RPA и делится секретами успешной роботизации бизнес-процессов.

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

— Насколько долгосрочен, на ваш взгляд, интерес рынка к RPA и гиперавтоматизации?

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

— Что позволяет считать RPA одной из ключевых тенденций именно цифровой трансформации, а не просто цифровизации? Можно ли с помощью RPA трансформировать бизнес?

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

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

— Всегда ли RPA — это обязательно Low Code? Какие альтернативы Low Code существуют в области RPA и могут ли они сосуществовать с подходом и технологиями Low Code?

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

Кроме того, нужно отметить, что Low Code — термин неустоявшийся, во многом маркетинговый. Едва ли кто-то даст четкое определение этого инструментария и сформулирует, чем он отличается, например, от No Code. При создании серьезного робота невозможно ограничиться только Low Code или No Code: отдельные фрагменты кода все равно придется писать вручную на одном из языков программирования.

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

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

— Могут ли пользователи, не обучаясь основам разработки, создавать эффективных и надежных RPA-ботов, не прибегая к помощи ИТ-профессионалов? Если могут, то при каких условиях?

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

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

Насколько мы видим, использование ИИ для роботизации бизнес-процессов пока скорее НИОКР, чем успешно применяемый подход. Да, в некоторых сценариях нейронные сети уже избавляют от написания рутинного кода. Безусловно, это направление будет развиваться, что позволит ускорить разработку там, где «дорожная карта» уже расчерчена. Кроме того, по нашему мнению, машинное обучение будет полезно в области анализа процессов (точнее, в Process Mining), а также везде, где есть возможность получить структурированные данные, на основе которых можно обучить нейронные сети. Однако, прежде чем эти технологии проникнут в реальную цифровизацию, пройдет, по нашим оценкам, несколько лет.

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

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

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

Для успеха RPA недостаточно просто приобрести ПО. С ним будут работать люди, а они, как правило, не особо хотят перемен в своих процессах. Значит, нужно управлять изменениями, а для этого необходимо, чтобы сложился ряд факторов. Экосистема как раз помогает эти факторы обеспечить.

— С чего лучше начать создание экосистемы RPA? К каким масштабам и к какому уровню ее зрелости следует стремиться?

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

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

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

— Насколько применимы к проектам RPA подходы Agile?

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

— Насколько необходимо изменение корпоративной культуры при реализации проектов RPA? Что именно в ней должно измениться?

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

— Какие риски являются наиболее серьезными в проектах RPA и как их можно минимизировать?

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

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

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

— Как отличить зрелую платформу от незрелой? Каковы признаки зрелой платформы роботизации?

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

— Какие основные рекомендации вы могли бы дать тем, кто сегодня приступает к роботизации своих бизнес-процессов?

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

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

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

Источник: https://www.computerworld.ru/articles/Analiticheskiy-podhod-k-robotizatsii-kak-eto-rabotaet