Итак, предположим, что у вас есть некая legacy-система, установленная в центральном офисе, которая получает данные из тридцати филиалов посредством когда-то разработанных коннекторов. Разработчик давно уволился, API устарел, актуальной документации на систему нет. И вдруг в какой-то момент вам понадобилось собирать из филиалов дополнительно какую-то информацию. Как быть?
Напрашивается ответ, что надо выбросить это старье и сделать современное гибкое масштабируемое решение. Стратегически это, пожалуй, правильно, только прямо сейчас на такой проект нет ни бюджета, ни времени. А новые требования — не просто «хотелка» бизнеса, а ультиматум регулятора.
То, что RPA может решить эту задачу, даже не обсуждается, это классика жанра. Но сколько это будет стоить? Ответ зависит от политики вендора. Исторически в отрасли сложилась практика, когда клиенту, покупающему робота (тот самый станок с ЧПУ), студию для разработки могут дать даже бесплатно. Неплохой вариант, чтобы начать использовать технологию. Но если вам нужно тридцать роботов, то цена уже изрядно кусается. И особенно обидно, когда дорогой робот задействован всего несколько минут в день, чтобы перебросить данные из филиала в приложение в центральном офисе.
Как поступают в таком случае на заводе, планируя закупку дорогостоящего станка? Стараются максимально загрузить его работой, чтобы повысить коэффициент использования оборудования, насколько это возможно. Российский RPA-вендор PIX Robotics предлагает подобный подход, но с учетом цифровых реалий: клиент может физически установить сколько угодно роботов, но количество лицензий рассчитывается исходя из фактической загрузки.
Скажем, если каждый из ваших тридцати роботов выполняет свою дневную норму за полчаса, то делим количество часов в сутках на суммарное время работы всех роботов и получаем
24 / (30 * 0,5) = 1,6 лицензии.
И здесь, как в школьной задаче про полтора землекопа, все-таки придется округлить до двух. Однако согласитесь, что покупать две лицензии — это гораздо лучше, чем тридцать.
В принципе эта схема похожа на привычное конкурентное лицензирование, принятое в системах электронного документооборота и в других корпоративных приложениях: вы получаете сервер (иногда даже бесплатно) и берете количество лицензий в 4–5 раз меньше числа сотрудников, полагая, что все они не будут работать одновременно.
В случае RPA роль сервера, который учитывает использование лицензий, берет на себя упомянутый выше мастер-оркестратор, а роботы выступают в роли сотрудников. А поскольку, как мы помним, робот не может сам решить, когда и что ему нужно делать, оркестратор еще занимается их включением в нужный момент и динамическим предоставлением лицензий активным в данный момент роботам. Кроме того, в мастере-оркестраторе настраиваются роли (устанавливаются права доступа для пользователей), а также ведется подробное логирование всех действий роботов, что особенно важно для служб информационной безопасности.