Интеллектуальная автоматизация: что необходимо знать бизнесу

В рамках практической конференции «Роботизация бизнес-процессов — 2020», организованной издательством «Открытые системы», состоялась дискуссия по актуальным проблемам развития рынка RPA и опыту внедрения платформ роботизации в России. В дискуссии, которую модерировала Мария Григорьева из Accenture, приняли участие Сергей Юдовский (компания ElectroNeek), Алексей Лапшин (ROBIN), Алексей Быстров (CSBI), Андрей Архипов (Kryon Systems), а также независимые эксперты Максим Яцкевич и Наталья Роменская.

RPA — хайп или необходимость?

Технология Robotic Process Automation появилась в ИТ-ландшафте предприятий в 2017 году, подняв волну ажиотажного интереса. И сегодня аналитики спорят: миновал RPA-хайп или еще нет? Мнения участников дискуссии по этому вопросу разделились. Наталья Роменская полагает, что стадия хайпа не совсем закончилась: заказчики еще находятся под влиянием «вау-эффекта» от возможностей новой технологии, однако уже начинают серьезно задумываться об экономической эффективности своих проектов, что свидетельствует о появлении более прагматического взгляда на RPA. В этом ее поддерживает Сергей Юдовский: «Хайп — это время 'несбывшихся мечт', оно заканчивается. RPA переходит в статус технологии, которую можно реально использовать».

Сергей Юдовский: «Хайп — это время 'несбывшихся мечт', оно заканчивается. RPA переходит в статус технологии, которую можно реально использовать»

Хайп миновал, считает Максим Яцкевич, обращая внимание на достаточно высокую зрелость рынка: появилось много специалистов по RPA; на рынке работает много новых вендоров, занявших свои ниши; благодаря уже выполненным проектам стали известны основные проблемы применения этой технологии: «Здорово, когда RPA есть практически в каждой компании — и в крупном бизнесе, и в среднем, и даже в малом. Поэтому сейчас это, скорее, необходимый инструмент, без которого ни одна компания не может обойтись».

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

В каком направлении будут развиваться RPA-платформы?

Несмотря на то что рынок RPA возник относительно недавно, он развивается очень динамично и уже сейчас чрезвычайно насыщен. Хотя его объем составляет всего 1,3 млрд долл. (Gartner, 2019), на нем работают более 70 поставщиков (и это если считать лишь тех, кто заметен в глобальном масштабе и попадает на радары международных аналитических агентств), а с учетом локальных игроков — гораздо больше. Чтобы преуспеть на поприще роботизации, вендорам нужно хорошенько подумать о стратегии — как отстроиться от конкурентов и найти своего заказчика.

В этой связи интересен опыт крупных международных игроков, таких как Kryon Systems. «В современном мире все чаще встречается не классическая ситуация, когда спрос рождает предложение, а наоборот — когда предложение создает спрос. Например, функциональность Process Discovery (обнаружение процессов), которая стала ключевым дифференциатором Kryon, появилась у нас пять лет назад и постепенно сформировала спрос, так что сейчас большинство вендоров вынуждены дорабатывать свои продукты в этом направлении», — считает Архипов.

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

Алексей Быстров: «Для российского рынка RPA одним из ключевых будет фактор импортозамещения»

Юдовский считает иначе: «Я не верю, что нужно делать все, что просят пользователи. Нужно понимать, какой продукт ты строишь, кто твоя ключевая аудитория. Когда у тебя бездонный кошелек, то, наверное, можно реализовать все пожелания, но лучше выбрать свой сегмент, ему служить и его радовать. И если не 100% рынка, а только 30% скажут, что ElectroNeek — хороший продукт, и от него не откажутся, это станет большим достижением. А всем все равно не угодишь».

«RPA выросла из систем автоматизации тестирования ПО, — напомнил Быстров. — Это был инструмент для программистов, причем достаточно сложный. Когда рынок стал расти, пользователи захотели получить возможность настройки роботов без программирования, ну а рост популярности концепции Low-code еще больше подстегнул эту тенденцию. Если говорить о будущем, то прежде всего мы предполагаем переход к сервисной модели и обязательную реализацию кросс-платформенности. А для российского рынка одним из ключевых будет фактор импортозамещения».

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

Интеграторы и вендоры

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

Наталья Роменская: «Заказчики начинают серьезно задумываться об экономической эффективности своих проектов»

Чтобы понять роль интеграторов в продвижении технологии роботизации процессов, Яцкевич предлагает оглянуться и вернуться в 2017 год, когда все только начиналось: «Тогда мы впервые услышали слова 'Robotic Process Automation' и увидели, как это работает. Мы сами были воодушевлены технологией, которая умеет повторять действия пользователя. Было очень важно, чтобы эту технологию несли в массы не только евангелисты, но и те, кто привык отвечать за свои обещания, — интеграторы. Первые из тех, кто вышел на этот рынок, вложили очень много сил, чтобы сейчас RPA использовали гораздо больше людей и компаний».

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

Эту мысль развивает и Юдовский, отмечая, что чем больше в России будет компаний, которые занимаются формированием услуг для конечного клиента, тем быстрее пойдет эта революция. «Это вообще печальная практика, когда люди начинают внедрять у клиентов свои продукты самостоятельно, — считает он. — По сути, они убивают будущее своей компании, потому что не вырастает пласт интеграторов, которые могут на нем заработать деньги. Мы, вендоры, даем инструмент, кирку. А они золотодобытчики». Однако сегодня Юдовский видит проблему в том, что пока нет достаточного количества интеграторов, вовлеченных в рынок RPA.

Алексей Лапшин: «Перспективы развития RPA — в более глубоком проникновении в повседневные бизнес-практики»

Отчасти с ним согласен Яцкевич: «Модель, когда вендор распространяет свою практику через партнеров, — это, конечно же, хорошая история, она более масштабируемая. Тем не менее ситуация, когда вендор сам делает интеграцию, — не самая плохая. Хуже всего, когда вендор начинает конкурировать со своими партнерами», — предостерегает эксперт.

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

Центры компетенции: за и против

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

Важность использования этого организационного механизма, хорошо зарекомендовавшего себя при освоении предприятиями других инновационных технологий, подчеркнул Лапшин, ссылаясь при этом на проект в РЖД: «Если бы проект вел исключительно интегратор, то роботы вышли бы 'золотыми'. Центр компетенции — будущее RPA. А вот кто будет с этим центром работать: партнер или собственные специалисты компании — это уже второй вопрос».

Собственным опытом создания центров компетенции поделилась Роменская. Она считает, что правильно иметь в организации собственную экспертизу: ведь если с роботами что-то случится и они перестанут работать, то придется идти заключать договор с интегратором, а это едва ли можно будет сделать быстро. Внутренний заказчик такого не потерпит. Однако очень полезно «иметь под рукой» интегратора, который возьмет определенный объем на себя, и не держать в штате много специалистов. «У нас в центре компетенции был костяк профессионалов — 8–9 человек, которые обладали глубокими знаниями по RPA. И если складывалось так, что нужно было запустить в конце квартала сразу десяток процессов, то мы обычно справлялись», — рассказала эксперт.

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

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

Сколько систем RPA нужно для счастья?

Если посмотреть на корпоративные приложения, то окажется, что крупных компаниях используется по несколько продуктов одного типа. Например, систем управления контентом предприятия (ECM) в организациях может быть 5–6, а если 2–3 — это вообще нормально. Иногда это обусловлено историей слияний и поглощений, но чаще — различием в функциональности и в типовых сценариях использования. И хотя рынок RPA находится в стадии формирования, он уже отличается значительным видовым разнообразием, поэтому заказчики стоят перед дилеммой: пытаться найти единственную платформу, которая покроет все их потребности, или подобрать для себя стек RPA-технологий от разных поставщиков.

Опираясь на международный опыт Kryon, ситуацию прокомментировал Архипов: «Мы были бы рады видеть нашу платформу единственной у заказчика, но на практике ее выбирают второй, а иногда и третьей. Мы в Россию пришли относительно поздно, и тот факт, что наш продукт берут в дополнение к решениям UiPath, Blue Prism, Automation Anywhere, говорит о том, что эти платформы не закрывают полностью весь спектр задач — например, не имеют модуля Process Discovery. Также причинами могут быть технические и лицензионные ограничения платформ, способы интеграции с приложениями и т. д. Скажем, если в продукте нет компьютерного зрения, то невозможно будет сделать робота, который берет информацию с сайтов, написанных на Flash».

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

Юдовский также относит себя к адептам мультивендорного подхода: «Во главу угла надо ставить пользователя и бизнес. Не нужно думать, что можно навязать одно решение на все случаи жизни. Если в каких-то департаментах хорошо идет продукт одного вендора, пусть приобретают его для какого-то количества задач и используют. Продукт второго вендора потребуется для других задач. «Зоопарк» из продуктов 5–6 вендоров — не самое лучшее решение, слишком много компетенций потребуется, чтобы его поддерживать». По мнению главы ElectroNeek, оптимум — это две-три платформы.

Почему RPA не всегда «взлетает»?

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

Максим Яцкевич: «Люди не готовы менять устоявшиеся годами бизнес-процессы, а внедрение RPA неизбежно ведет к переменам»

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

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

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

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

Андрей Архипов: «Мы не заменяем людей роботами — мы убираем роботов из людей, избавляем их от рутинной работы»

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

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