Статья в издании «Открытые системы»
Руководство покупателя RPA
Enterprise-подход к внедрению роботизации: что нужно знать компаниям о функциональности RPA-платформы и эффективной утилизации лицензии
Роботизация процессов еще не стала мейнстримом, но уже и не смотрится экзотикой: по данным исследования Deloitte, в 2020 году 42% компаний внедрили RPA, а 39% планировали начать это делать. Если посмотреть на перспективу, то в прошлом году роботизация бизнес-процессов была включена в стратегию повышения эффективности большинства компаний (64%). То есть бизнес вошел во вкус и не собирается останавливаться — очевидно, что роботы прочно займут свое место в ИТ-ландшафте предприятий.
Причина такой популярности RPA лежит на поверхности — это деньги. Роботизация в разы ускоряет рутинные процессы обработки данных, а значит, позволяет больше зарабатывать или больше экономить — и то и другое способствует росту прибыли. Кроме того, как говорится в том же отчете Deloitte, средний период окупаемости RPA-проектов составляет один год, что звучит фантастически для любого финдиректора. Поэтому многие компании, вдохновленные историями успеха первопроходцев роботизации, тоже задумываются о приобретении роботов.
Почему нельзя просто взять и купить робота
Приняв такое решение, прежде всего нужно усвоить, что RPA — это не коробка, не волшебная программа, которая ставится на компьютер каждого пользователя и начинает работать вместо него. RPA-система представляет собой сложное программное изделие, состоящее из целого ряда компонентов.
Короче говоря, RPA — это совсем не то же самое, что персональный дроид-астромеханик R2D2 Энакина Скайуокера. Это продукт уровня enterprise, к выбору которого надо подходить со всей серьезностью. Причем надо внимательно смотреть не только на технические и функциональные параметры, но и на модель лицензирования конкретного вендора, потому что может статься, что схожие по возможностям решения от разных поставщиков будут отличаться по стоимости в несколько раз. И в этом нет какого-то обмана или подвоха — просто на некоторых конфигурациях разница в лицензировании приобретает критический характер.
Однако, прежде чем погрузиться в тонкости покупки лицензий, давайте разберемся, что именно делают компоненты RPA, — это поможет вам правильно формулировать вопросы продавцу и не потратить лишнего.
Короче говоря, RPA — это совсем не то же самое, что персональный дроид-астромеханик R2D2 Энакина Скайуокера. Это продукт уровня enterprise, к выбору которого надо подходить со всей серьезностью. Причем надо внимательно смотреть не только на технические и функциональные параметры, но и на модель лицензирования конкретного вендора, потому что может статься, что схожие по возможностям решения от разных поставщиков будут отличаться по стоимости в несколько раз. И в этом нет какого-то обмана или подвоха — просто на некоторых конфигурациях разница в лицензировании приобретает критический характер.
Однако, прежде чем погрузиться в тонкости покупки лицензий, давайте разберемся, что именно делают компоненты RPA, — это поможет вам правильно формулировать вопросы продавцу и не потратить лишнего.
Из чего сделан RPA
Как правило, в состав RPA-системы входят непосредственно робот, студия для разработки программ и мастер-оркестратор, обеспечивающий управление роботами. Дополнительно могут быть и другие компоненты различного назначения, но основными являются эти три. Рассмотрим каждый из них более подробно.
Робот — это ваш цифровой сотрудник, он не устает, не ошибается, работает в режиме 24х7 и умеет получать данные из любых источников (Excel, обычные файлы, базы данных, почта, веб-сайт, ERP, CRM и вообще любые приложения, в том числе очень старые, к которым и документации нет); затем он может эти данные нужным образом обработать и отправить куда следует.
Звучит заманчиво, не правда ли? Но, в отличие от сотрудника-человека, робот не может проявлять инициативу. Он может действовать только по заранее заданной программе, которую (пока еще) должен написать человек.
В этом смысле ближе будет аналогия со станком с ЧПУ, который потенциально может выточить любую деталь, но сначала инженер должен загрузить в него требуемую программу.
Соответственно, студия — это конструктор программ для роботов, в котором доступны различные активности, а далее пользователь, как из блоков лего, собирает из них процесс. Например, можно взять список адресатов из таблицы Excel, запросить из ERP-системы отчет по каждому из них и отправить этот отчет по электронной почте. Продолжая аналогию со станками, можно сказать, что студия в RPA — это как CAD-система на заводе.
И последний компонент — мастер, или, как его еще называют, оркестратор. Когда роботов у вас становится много и нужно, чтобы они работали согласованно, вам необходима некая управляющая система — это и есть мастер. Ключевое слово здесь «согласованно»: вы можете поставить хоть сто роботов, и пусть каждый занимается своим делом. А если вы хотите ими управлять централизованно, в том числе загружать в них программы, запускать по расписанию, отслеживать результат работы и так далее, то мастер вам необходим. В общем, мастер — это как станция управления дроидами в «Звездных войнах».
Робот — это ваш цифровой сотрудник, он не устает, не ошибается, работает в режиме 24х7 и умеет получать данные из любых источников (Excel, обычные файлы, базы данных, почта, веб-сайт, ERP, CRM и вообще любые приложения, в том числе очень старые, к которым и документации нет); затем он может эти данные нужным образом обработать и отправить куда следует.
Звучит заманчиво, не правда ли? Но, в отличие от сотрудника-человека, робот не может проявлять инициативу. Он может действовать только по заранее заданной программе, которую (пока еще) должен написать человек.
В этом смысле ближе будет аналогия со станком с ЧПУ, который потенциально может выточить любую деталь, но сначала инженер должен загрузить в него требуемую программу.
Соответственно, студия — это конструктор программ для роботов, в котором доступны различные активности, а далее пользователь, как из блоков лего, собирает из них процесс. Например, можно взять список адресатов из таблицы Excel, запросить из ERP-системы отчет по каждому из них и отправить этот отчет по электронной почте. Продолжая аналогию со станками, можно сказать, что студия в RPA — это как CAD-система на заводе.
И последний компонент — мастер, или, как его еще называют, оркестратор. Когда роботов у вас становится много и нужно, чтобы они работали согласованно, вам необходима некая управляющая система — это и есть мастер. Ключевое слово здесь «согласованно»: вы можете поставить хоть сто роботов, и пусть каждый занимается своим делом. А если вы хотите ими управлять централизованно, в том числе загружать в них программы, запускать по расписанию, отслеживать результат работы и так далее, то мастер вам необходим. В общем, мастер — это как станция управления дроидами в «Звездных войнах».
Робот должен работать, а не стоять без дела
Итак, предположим, что у вас есть некая legacy-система, установленная в центральном офисе, которая получает данные из тридцати филиалов посредством когда-то разработанных коннекторов. Разработчик давно уволился, API устарел, актуальной документации на систему нет. И вдруг в какой-то момент вам понадобилось собирать из филиалов дополнительно какую-то информацию. Как быть?
Напрашивается ответ, что надо выбросить это старье и сделать современное гибкое масштабируемое решение. Стратегически это, пожалуй, правильно, только прямо сейчас на такой проект нет ни бюджета, ни времени. А новые требования — не просто «хотелка» бизнеса, а ультиматум регулятора.
То, что RPA может решить эту задачу, даже не обсуждается, это классика жанра. Но сколько это будет стоить? Ответ зависит от политики вендора. Исторически в отрасли сложилась практика, когда клиенту, покупающему робота (тот самый станок с ЧПУ), студию для разработки могут дать даже бесплатно. Неплохой вариант, чтобы начать использовать технологию. Но если вам нужно тридцать роботов, то цена уже изрядно кусается. И особенно обидно, когда дорогой робот задействован всего несколько минут в день, чтобы перебросить данные из филиала в приложение в центральном офисе.
Как поступают в таком случае на заводе, планируя закупку дорогостоящего станка? Стараются максимально загрузить его работой, чтобы повысить коэффициент использования оборудования, насколько это возможно. Российский RPA-вендор PIX Robotics предлагает подобный подход, но с учетом цифровых реалий: клиент может физически установить сколько угодно роботов, но количество лицензий рассчитывается исходя из фактической загрузки.
Скажем, если каждый из ваших тридцати роботов выполняет свою дневную норму за полчаса, то делим количество часов в сутках на суммарное время работы всех роботов и получаем
24 / (30 * 0,5) = 1,6 лицензии.
И здесь, как в школьной задаче про полтора землекопа, все-таки придется округлить до двух. Однако согласитесь, что покупать две лицензии — это гораздо лучше, чем тридцать.
В принципе эта схема похожа на привычное конкурентное лицензирование, принятое в системах электронного документооборота и в других корпоративных приложениях: вы получаете сервер (иногда даже бесплатно) и берете количество лицензий в 4–5 раз меньше числа сотрудников, полагая, что все они не будут работать одновременно.
В случае RPA роль сервера, который учитывает использование лицензий, берет на себя упомянутый выше мастер-оркестратор, а роботы выступают в роли сотрудников. А поскольку, как мы помним, робот не может сам решить, когда и что ему нужно делать, оркестратор еще занимается их включением в нужный момент и динамическим предоставлением лицензий активным в данный момент роботам. Кроме того, в мастере-оркестраторе настраиваются роли (устанавливаются права доступа для пользователей), а также ведется подробное логирование всех действий роботов, что особенно важно для служб информационной безопасности.
Напрашивается ответ, что надо выбросить это старье и сделать современное гибкое масштабируемое решение. Стратегически это, пожалуй, правильно, только прямо сейчас на такой проект нет ни бюджета, ни времени. А новые требования — не просто «хотелка» бизнеса, а ультиматум регулятора.
То, что RPA может решить эту задачу, даже не обсуждается, это классика жанра. Но сколько это будет стоить? Ответ зависит от политики вендора. Исторически в отрасли сложилась практика, когда клиенту, покупающему робота (тот самый станок с ЧПУ), студию для разработки могут дать даже бесплатно. Неплохой вариант, чтобы начать использовать технологию. Но если вам нужно тридцать роботов, то цена уже изрядно кусается. И особенно обидно, когда дорогой робот задействован всего несколько минут в день, чтобы перебросить данные из филиала в приложение в центральном офисе.
Как поступают в таком случае на заводе, планируя закупку дорогостоящего станка? Стараются максимально загрузить его работой, чтобы повысить коэффициент использования оборудования, насколько это возможно. Российский RPA-вендор PIX Robotics предлагает подобный подход, но с учетом цифровых реалий: клиент может физически установить сколько угодно роботов, но количество лицензий рассчитывается исходя из фактической загрузки.
Скажем, если каждый из ваших тридцати роботов выполняет свою дневную норму за полчаса, то делим количество часов в сутках на суммарное время работы всех роботов и получаем
24 / (30 * 0,5) = 1,6 лицензии.
И здесь, как в школьной задаче про полтора землекопа, все-таки придется округлить до двух. Однако согласитесь, что покупать две лицензии — это гораздо лучше, чем тридцать.
В принципе эта схема похожа на привычное конкурентное лицензирование, принятое в системах электронного документооборота и в других корпоративных приложениях: вы получаете сервер (иногда даже бесплатно) и берете количество лицензий в 4–5 раз меньше числа сотрудников, полагая, что все они не будут работать одновременно.
В случае RPA роль сервера, который учитывает использование лицензий, берет на себя упомянутый выше мастер-оркестратор, а роботы выступают в роли сотрудников. А поскольку, как мы помним, робот не может сам решить, когда и что ему нужно делать, оркестратор еще занимается их включением в нужный момент и динамическим предоставлением лицензий активным в данный момент роботам. Кроме того, в мастере-оркестраторе настраиваются роли (устанавливаются права доступа для пользователей), а также ведется подробное логирование всех действий роботов, что особенно важно для служб информационной безопасности.
Подведем итоги
- Выбирая платформу RPA, надо смотреть не только на функциональность и цены отдельных компонентов, но и на схему лицензирования — это может очень сильно повлиять на финальную стоимость решения.
- Планируя внедрение RPA, нужно обеспечить максимальную загрузку своих роботов, чтобы добиться высокого коэффициента утилизации лицензий.
- PIX Robotics позволяет установить столько роботов, сколько нужно по архитектурным требованиям, при этом количество лицензий рассчитывается исходя из практической потребности.
- Так как RPA сегодня — это полноценное Enterprise-решение, то и начинать роботизацию необходимо с закладывания централизованной архитектуры для обеспечения возможности управления и дальнейшего масштабирования
Источник: osp.ru
ООО "Пикс Роботикс"
ИНН: 9731050726
Территория Инновационного Центра Сколково, улица Нобеля, дом 5, Москва, 121205
E-mail: info@pixrpa.ru
Телефон: +7 (495) 215-04-81
Время работы пн-пт с 9 до 19 без перерывов.
ИНН: 9731050726
Территория Инновационного Центра Сколково, улица Нобеля, дом 5, Москва, 121205
E-mail: info@pixrpa.ru
Телефон: +7 (495) 215-04-81
Время работы пн-пт с 9 до 19 без перерывов.
© All Rights Reserved.
PIX Robotics.
PIX Robotics.
Исследования осуществляются при грантовой поддержке Фонда «Сколково»
Информация для связи
Мы не передаем информацию третьим лицам.
Данный сайт использует файлы cookie. Продолжая пользоваться сайтом, вы даёте своё согласие на сбор данных о том, как вы взаимодействуете с нашими сайтом, продуктами и услугами. Нажимая "ОК", вы соглашаетесь с использованием нами полученной информации для рекламы, аналитики и организации поддержки.
OK