Скорость, масштабируемость, No-code: куда движутся отечественные платформы RPA

Генеральный директор Sherpa Robotics — о настоящем и будущем платформ роботизации бизнес-процессов, а также о сценариях их «правильного» применения. Технологии роботизации процессов (Robotic Process Automation, RPA) , несмотря на растущую зрелость, до сих пор вызывают много дискуссий, касающихся их эффективности и места в корпоративном ландшафте. Расстановка сил на рынке RPA за последние полтора года существенно изменилась. Там, где раньше безраздельно доминировали зарубежные системы, начали появляться отечественные решения. Одним из них является Sherpa RPA — платформа для роботизации с автоматизированным выявлением бизнес-процессов с помощью машинного обучения. Она относится к классу продуктов No-code: позволяет создавать приложения без программирования — с помощью методов буксировки (drag-and-drop) и визуального моделирования. Это максимально демократизирует возможности ее использования в компаниях. Мы поговорили с Константином Артемьевым, генеральным директором Sherpa Robotics, о настоящем и будущем платформ RPA, а также обсудили сценарии их «правильного» применения. - На конференции RPA 2021 несколько экспертов выступили с противоположными заявлениями: одни открыто признавали роботов в качестве временных, суррогатных решений, а другие призывали отказаться от восприятия RPA как «костылей». Где, с вашей точки зрения, истина? У каждого инструмента (а RPA — это именно инструмент) есть своя сфера применения. Условно говоря, молотком надо забивать гвозди, а не шурупы. Общаясь с клиентами, мы часто наблюдаем, что в крупной компании есть собственный отдел разработки, где «серьезные» программисты пишут что-то на известных языках. Казалось бы, проблемы, с которыми к нам приходят заказчики, мог бы решить их собственный ИТ-отдел. Однако на практике разработчики вечно перегружены и не успевают решать задачи, с которыми к ним приходят сотрудники отделов аналитики, логистики, закупок, бухгалтерии и т. д. В одной из компаний руководитель отдела развития честно признался в том, что очередь на разработку решений сейчас составляет около года. В этом случае RPA может быть отличным способом существенно ускорить внедрение точечных (а иногда и серьезных) систем автоматизации. Средний срок таких проектов — несколько недель. Два месяца — абсолютный максимум. Получается, что с использованием RPA внедрение систем внутренней автоматизации ускоряется в 3–10 раз. Это не только наша статистика, об аналогичных показателях говорят крупные консалтинговые агентства, а также коллеги, занимающиеся внедрением других платформ. И в этом ускорении заключается самое главное преимущество. А другие факторы — например, снижение требований к разработчикам — являются лишь дополнительным бонусом. Да, в каких-то случаях внедрение RPA может выглядеть как «костыль». А где-то перед внедрением роботов было бы неплохо выполнить оптимизацию процессов. Но иногда даже такой подход бывает оправданным как временное решение. Мы живем в очень динамичном мире, и чем оперативнее бизнес реагирует на изменения, чем быстрее может выводить на рынок новые продукты и переформатировать свои процессы, тем больше шансов на то, что он останется на плаву. Если для внедрения изменения, которое нужно немедленно, требуется полгода на разработку, это не очень хорошая ситуация. Место RPA — именно в быстром решении подобных задач и адаптации компаний к изменяющемуся внешнему миру. - Практика показывает, что применение RPA в подавляющем большинстве случаев далеко от массовости. После пилотных (зачастую успешных) проектов решения тяжело масштабируются, и часто вовсе не из-за технологических факторов. Каковы ключевые причины этого феномена? Мы видим несколько конкретных причин. Во-первых, внутренние команды разработки начинают саботировать внедрение RPA, потому что видят прямого конкурента. Во-вторых, ключевые сотрудники компании не понимают, в чем сильные и слабые стороны RPA, и не могут определиться с областями применения программных роботов. Часто для пилота выбирают совсем небольшую задачу: фактически пытаются заменить роботом какой-то процент времени работы одного сотрудника. Такой проект реализуется быстро и просто, но в этом случае стоимость работ может быть несопоставима с фактической отдачей — игра не стоит свеч. Даже для пилота нужно выбирать задачи, которыми занимаются несколько человек и тратят на них существенную часть рабочего дня. Только тогда эффект от внедрения роботов будет очевиден. - Чем характеризуется платформа, которую выгодно и удобно масштабировать? Например, вы себя позиционируете как платформу для крупного и среднего бизнеса. Можно выделить несколько ключевых свойств такой платформы. Во-первых, она должна позволять выявлять новые процессы для роботизации. При первоначальном внедрении RPA идеи о том, на каких процессах использовать эту технологию, возникают сразу. Однако после «снятия сливок» и успешного запуска первых роботов все уже не так очевидно. Поэтому платформа должна включать встроенные инструменты Process Discovery. Во-вторых, эта платформа должна позволять вести разработку на местах, силами бизнес-пользователей. Как минимум она должна быть настолько удобной и наглядной, чтобы пользователи могли при необходимости адаптировать роботов. А если сотрудник обладает алгоритмическим складом ума, то он сможет создавать роботов самостоятельно. В-третьих, платформа должна поддерживать все популярные корпоративные технологии. Не должно быть проблем с SAP, «1С», Oracle, технологиями виртуализации и т. п. Однако самое главное: выгода от использования роботов не должна уменьшаться с ростом их числа. Это настоящее проклятие для лицензионных политик многих вендоров: чем дольше компания «пылесосит» свой ландшафт в поисках процессов для роботизации, тем меньше отдача от нее. Ценообразование должно учитывать этот фактор. Мы пытаемся соответствовать всем четырем критериям. - А может ли такой платформой пользоваться малый бизнес? Насколько это возможно, удобно и выгодно? Да, у нас есть клиенты из малого бизнеса, буквально с десятком сотрудников. Во многом это обеспечивается низким порогом входа: 50 тыс. руб. за робота — это вполне подъемная цена для SMB. - Есть люди, считающие технологию Process Discovery «баловством». Почему вы делаете ставку на эту технологию? Она важна для масштабирования платформы. В любой компании есть регламенты, согласно которым должны действовать сотрудники. Однако часто оказывается, что даже при наличии четких инструкций с течением времени они перестают выполняться буквально: сотрудники на местах изобретают альтернативные способы решения задач и методы обхода возникающих проблем. Об этих неформальных процессах никто из начальства даже не подозревает. Из-за этого время решения одной и той же задачи двумя разными сотрудниками может различаться в несколько раз. Поэтому, прежде чем что-то оптимизировать, следует узнать реалии бизнес-процессов и вообще поинтересоваться, нет ли там «лишних» задач, от которых лучше избавиться. Process Dicovery — это инструмент выявления фактически сложившихся в компании процессов, а не нарисованных в теории. Только проанализировав их, можно нарисовать карту процессов и сделать их «раскадровку», которая ляжет в техническое задание для разработки роботов. Process Dicovery существенно, иногда в десятки раз, ускоряет работу аналитиков, которым иначе приходится действовать вручную. Их собственная скорость — анализ работы нескольких человек в месяц. «Вооруженный» бизнес-аналитик за месяц способен охватить работу нескольких десятков человек. - У подхода Low-code/No-code много сторонников и не меньше скептиков. В каких случаях эти решения использовать правильно, а какие признаки, наоборот, являются стоп-факторами? Если говорить о таких решениях в целом, то их эффективное применение охватывает следующие случаи: когда необходимо очень быстро создать прототип решения, которое будет работать из коробки, и сильно хочется сэкономить на разработке. То есть нужен готовый продукт здесь и сейчас. Такие решения сильно выручают: позволяют собрать «домик» из кубиков конструктора. Проблемы же возникают при масштабировании, когда стандартных возможностей платформ уже не хватает. В случае уникального дизайна или сложной бизнес-логики, нетипичной для таких продуктов, также возникнут сложности. Еще одно ограничение — большие объемы обрабатываемой информации. Если сотня и даже тысяча пользователей — не проблема, то в случае десятков тысяч пользователей требуется более серьезный инструмент. - Каковы требования к экспертам для разработки на платформах No-code? Много ли сейчас таких специалистов на рынке? Мы оцениваем российский рынок специалистов, обученных на какой-либо из платформ No-code, примерно в 10 тыс. человек. Надо признать, что основная масса специализируется не на RPA, а в какой-то из смежных областей. Главное требование — наличие алгоритмического склада ума. Этому очень тяжело научить гуманитариев, они с такими задачами в жизни не встречаются. Важно последовательно, по шагам, разложить свою задачу, декомпозировать ее и изложить в виде алгоритма — хотя бы словами, а также описать исключения из правил. Но программистом быть вовсе не обязательно. За короткое время обучаются системные администраторы, бизнес-аналитики и даже пользователи, просто хорошо владеющие Microsoft Excel — на уровне, превышающем базовые функции. К счастью, у огромного количества пользователей навыки алгоритмизации присутствуют — когда-то в жизни они с задачами подобного рода уже сталкивались. У нас есть собственная академия, подготовившая уже около сотни специалистов. Программа проста: на заочное ознакомление даем записанные ролики, затем — домашнее задание, по видеосвязи обсуждаем задания и возникающие вопросы. Двух-трех недель в таком режиме хватает для того, чтобы человек, раньше не сталкивавшийся с разработкой, начал создавать вполне полезных и применимых в бизнесе роботов. Очень выгодно работать с вузами. Сейчас на их базе создается много курсов дополнительного образования, куда приходят уже состоявшиеся специалисты, которым нужны дополнительные навыки, связанные с цифровой трансформацией. Такие люди хорошо мотивированы, жадно впитывают знания, с ними комфортно общаться. Сейчас на базе двух вузов мы открываем курсы по обучению работе с нашей платформой и делаем большую ставку на них. - Приведите пример нескольких успешных кейсов внедрения вашей платформы. Что у них общего? Заказчики очень разные, но у самых успешных проектов действительно есть общее: несколько человек выполняют одну и ту же бизнес-функцию, отнимающую более половины рабочего дня. При этом присутствует «человеческий фактор»: сотрудники совершают некоторое количество ошибок, критичных для процесса. Когда сочетаются такие обстоятельства, вопросов об экономическом эффекте даже не возникает. Один из примеров — обогащение информации о клиентах и лидах для страховой компании. Чтобы сделать хорошее коммерческое предложение или «правильный» звонок, сотрудник отдела продаж должен иметь как можно больше информации. На ее сбор в открытых источниках уходит много времени. Робот существенно сокращает это время и повышает полноту информации за счет охвата большего числа источников. Это сразу же отразилось на конверсии: эффективность звонков резко выросла. Когда речь идет не только о сокращении ручного труда сотрудников, но и о повышении качества процессов, это идеальный вариант. Другой пример — обработка большого количества сканированных документов (счетов, актов, накладных) в компании, торгующей металлопрокатом. Этим ежедневно занимались более 10 человек. Роботизация позволила освободить их рабочее время. Сотрудники были счастливы, и никто не беспокоился об увольнении, потому что эта рутина не была для них профильной деятельностью. Наконец, есть нетипичный, но очень показательный пример роботизации — ввод данных в одну из ГИС, которая изначально была не слишком удачно спроектирована: у нее отсутствует функция импорта. Организациям требуется отчитываться в этой системе о производимых товарах, и есть компании, которым ежемесячно требуется вносить несколько тысяч позиций. Ввод одной товарной позиции требует заполнения 50 полей — это около 20 минут. Робот позволил сократить время на внесение одной записи до 50 секунд. Это сэкономило огромное количество времени нескольким сотрудникам. - Политика импортозамещения ужесточается, да и расстановка сил на рынке за последние пару лет изменилась. Готовы ли крупные компании переходить на отечественные платформы роботизации, если ранее они выбирали западные? Многие клиенты готовы, и в ряде случаев этот процесс начался. Наше государство регуляторными мерами — в частности, созданием реестра отечественного ПО — сильно помогло. Это не решающий, но важный фактор для многих компаний. Кроме того, по каналам обратной связи мы получаем от клиентов информацию о том, что техническая поддержка отечественных компаний работает гораздо быстрее. Ответ на стандартный технический вопрос можно получить не за несколько недель, а за несколько часов, в течение того же рабочего дня. Наконец, поддержка других российских систем, в том числе «1С», и русского языка выполнена гораздо лучше. Если говорить о конкурентоспособности отечественных платформ RPA, то на рынке существуют как минимум три игрока, способных производить продукты, конкурирующие с ведущими западными решениями. Таким образом, даже среди российских платформ есть выбор, и это замечательно. - Куда движется рынок программных роботов? Какой вы видите индустрию через 3–5 лет? Мне кажется, что тенденция No-сode будет только усиливаться и сотрудники на местах смогут принимать все большее участие в роботизации процессов. Я вижу это как переход от формализованных инструментов разработки к менее формализованным. Уже сейчас люди могут решать многие бытовые задачи с помощью голосовых помощников. Взаимодействие при создании бизнес-решений также будет происходить с помощью естественной речи: сам инструмент будет ее преобразовывать в формальные представления, которые RPA сможет выполнять. Как сейчас «Алиса» может проложить маршрут или помочь с ежедневными делами, так и условная «Оксана» сможет проверить электронную почту, найти конкретное коммерческое предложение, подставить туда нужные реквизиты, вывести на печать и отправить бухгалтеру. Симбиоз между голосовыми помощниками, способами неформального создания алгоритмов и инструментами RPA — дело совсем недалекого будущего.