RPA - не решение всех проблем, а только инструмент. Как им пользоваться с отдачей для бизнеса
Тема роботизации и RPA не теряет своей новизны. Роботизация, безусловно, не панацея. Технология RPA требует особого подхода, понимания цели внедрения и следования четко выстроенной бизнес-стратегии. В этой статье расскажу на примере кейсов, нужны ли вам роботы и как выбрать самого продуктивного из них.
За и против
Начну с главного вопроса, который задают выгодоприобретатели – в чём отличие от автоматизации? Что может такого сделать RPA, что не могут сделать разработчики? Ответ простой – ничего. Но есть несколько проблем, с которыми сталкиваются компании любого масштаба, что делает технологию востребованной. Первая – необходимость интеграции с Legacy-система или IT-продуктами, у которых отсутствует программная интеграция (API), сюда же попадают веб-сайты. RPA – это инструмент, который предназначен для решения специфических задач, что позволяет разработчикам не «придумывать костыли», не тратить время на изучение неизвестной для них области, а воспользоваться уже готовым продуктом, позволяющим связать воедино цепочку источников, сквозь которые проходит автоматизируемый бизнес-процесс. Второе – это простота и доступность RPA-продуктов. Хотя сотрудник без понимания основ программирования (переменные, циклы, «что-если») не сможет самостоятельно использовать продукт, для остальных это довольно простой в освоении инструмент. Компании, в которых бэклог задач для IT-подразделения расписан на год вперёд, а новые срочные задачи появляются каждую неделю, просто физически не способны поддерживать конкурентный темп без расширения штата высокооплачиваемых разработчиков. Тогда RPA со своей скоростью и доступностью позволяет закрывать задачи параллельно при затрате меньшего количества ресурсов на автоматизацию.
Второй вопрос – это применимость RPA в принципе. Надо понимать, что RPA – это своего рода нишевый инструмент, предназначенный для решения определённых задач, а не роботизации ради роботизации, просто потому что это действительно быстрее и выгоднее. Выгода здесь может сыграть злую шутку. Основное: RPA предназначен для связи нескольких систем, а не для роботизации внутри одной. Так, например, сделать обработку внутри SAP/1C гораздо выгоднее средствами самих IT-продуктов, нежели RPA. Главный фактор здесь – стабильность, ведь RPA привязан к конкретному алгоритму и мельчайшие изменения в интерфейсе программы могут привести к поломке робота, что не имеет значения для обработки или выгрузки, сделанной штатными средствами. Второе, что менее существенно, RPA в основном предназначен для автоматизации часто повторяющихся, рутинных (можно даже сказать ручных) функций: частый перенос информации из источника в систему, консолидация информации из разных ИТ-источников, распознавание и разнос информации из документов. Компании часто говорят о роботизации, например, отчёта, который делается сотрудником раз в квартал – это плохой процесс для роботизации, он не окупится.
В целом при подходе к новым технологиям следует хорошо задуматься и не попасть в сеть на волне хайпа лишь ради того, чтобы бизнес стал причастным к популярному цифровому движению. И RPA не исключение. Ожидания и надежды часто не имеют ничего общего с реальной ситуацией. Отсутствие компетенций у сотрудников, сложности в сопровождении - это лишь часть преград, которые могут стоять в процессе внедрения робота и после. Всегда можно обратиться за поддержкой к IT-интеграторам, но такой подход всегда сопряжён с более высокой стоимостью внедрения.
Что предстоит пройти при внедрении технологии
Компании приходят к RPA по-разному, но успешный путь внедрения всегда только один.
Первое, что необходимо сделать, - это подобрать правильный процесс для будущего пилота. Есть разные способы, как это сделать: пообщаться с RPA-вендором, который всегда готов помочь в анализе бизнес-процессов, привлечь бизнес-консультантов, внутренний ИТ-специалист с лёгкостью разберётся в технологии и найдёт, где применить RPA. Но наиболее продуктивно – прислушаться к жалобам сотрудников о больших объёмах неинтересной рутинной работы, ведь именно их ручной труд должен заменить RPA, делегировав исполнение этих задач роботу.
Следом идёт пилотное внедрение, где набиваются шишки: становятся понятны специфические для RPA процессы согласования доступов, безопасности и детальной алгоритмизации. Пилотный проект или Proof of Concept не всегда должен быть экономически выгодным, часто позитивный эффект от роботизации достигается за счёт эффекта масштаба. Внедрять RPA самим или с привлечением интеграторов – вопрос второй. Здесь плюсы и минусы те же, как и при внедрении любого другого продукта: разный уровень компетенций и штатных и наёмных сотрудников, сроки, стоимость и так далее.
После успешного пилота следует задуматься о масштабировании RPA в компании, куда входит не только стратегия подбора процессов для роботизации и их приоритезация, но также куда более важные вещи – как будет регламентирован процесс внесения изменений в роботов (они сильно зависят от изменений в системах, в которых они работают), как сотрудники компании будут работать в новой цифровой среде и сотрудничать с роботами, развивать ли компетенции внутри компании или продолжать пользоваться услугами подрядчика.
Советы по выбору платформы
Как было сказано выше, выбор платформы – одна из важнейших составляющих успеха роботизации в компании. Может показаться, что функционально все платформы удовлетворяют желаемым требованиям, но отдавать предпочтение стоит уже устоявшимся продуктам с действующими клиентами, и чем их больше, и чем громче их имена – тем лучше. Здесь хочу заметить, что это никак не коррелирует с ценой, стоимость взрослых RPA-платформ будет примерно на одном уровне (если не брать зарубежные, где сказываются курсы валют и НДС). Причина – в рисках. У компаний с появлением клиентов возникает ответственность на сопровождение и техническую поддержку своего продукта, его дальнейшее развитие. Это гарантирует, что компания не исчезнет с рынка, оставляя за собой необходимость повторного выбора и перехода на новую платформу, что по большей части несёт риск дополнительных затрат и времени по переводу уже роботизированных процессов на новый продукт.
Следующее, на что стоит обратить внимание – это доступность информации по продукту и его использованию, присутствие живого сообщества, занимающегося платформой и работающего на ней. Рано или поздно любая компания придёт к решению создать внутренний Центр Компетенций по RPA, и тогда многообразие доступных ресурсов для изучения и широта поддержки помогут быстрее и качественнее обучать новых сотрудников. Качество и скорость технической поддержки здесь тоже играют важную роль.
Третье – это функционал. RPA-платформы действительно в своей широте по большей части способны на решение одних и тех же задач, хотя возможно и разными способами. Однако реальность такова, что каждая из платформ в конечном счёте начинает делать уклон в сторону удобства и простоты работы с конкретным ПО, веб-ресурсами или встраивать вспомогательные инструменты, дальше упрощая и делая продукт более доступным для обычного пользователя. В нашей компании, например, присутствуют активности для создания несложных нейросетей в 3 клика, что позволяет существенно сэкономить время при решении задач, связанных с классификацией или прогнозированием, без привлечения предметных специалистов.
Дмитрий Корнев,
руководитель отдела по развитию бизнеса PIX Robotics
Начну с того, для чего необходимо развитие личного бренда ИТ-директору. Причин несколько, и все они крайне важны.
Опубликовано 23.01.2021