Роботы внутри офиса: что можно сделать за 3 дня вместо полугода


Оригинал статьи на блоге компании КРОК
Автор: Вероника Воронова

История началась с того, что нам понадобился доступ к HR-системе для чат-бота. Чтобы последний мог искать контакты сотрудников по запросу вроде: «Найди того, кто может починить пиканиску». В корпоративной инфраструктуре это выглядит так: мы идём в отдел автоматизации и говорим, что нам нужны данные из HRMS. И получаем закономерный ответ:

— Пишите ТЗ, предоставим API и сервер интеграции через 6 месяцев.
— Парни, вы чего? Нам бы побыстрее!
— Тогда пишите ТЗ и письмо руководителю, сможем СРОЧНО уложиться за 3 месяца.

А нам надо было за 3 дня. Поэтому мы пошли другим путём: попросили кадровиков завести нам бота в список сотрудников и дать ему доступ к системе. Дальше он уже делал то, что на его месте мог бы делать человек.

В итоге старая шутка про то, что если программисты доберутся до власти, то весь парламент можно будет заменить простым bash-скриптом, оказалась не такой уж шуткой. Наши роботы, конечно, не самые оптимальные с точки зрения архитектуры на годы вперёд, но работают. Про то, что именно они делают и откуда такие сроки, я сейчас и расскажу.

Итак, первичная идея очень проста: можно взять робота, который будет имитировать действия пользователей. Например, если нам нужен доступ в HR-систему — не надо строить сервер интеграции и получать API. Нужно просто научить робота нажимать нужные кнопки и парсить ответы. Благо почти все современные интерфейсы очень и очень дружелюбны к роботам — в MS-софте везде есть теги элементов управления для альтернативного доступа, горячие клавиши или узнаваемые иконки. Мы просто учим робота нажимать нужные кнопки в нужной последовательности. Около часа уходит на автоматизацию процесса по типу макроса в Ворде или записи действия в Фотошопе, а оставшиеся 90% — это тесты и обработка исключений.

Пользователь нажимает на кнопку в интерфейсе. Затем данные собираются, и запускается робот. Кнопка как отдельный интерфейс (фронтэнд) нужна потому, что, например, чат-бот не может снять скриншот сам. Но может рассказать про кнопку, поскольку пользователь привык, что все вопросы можно адресовать чат-боту как основному интерфейсу. Чат-бот же запускает роботов.

В целом пользователь ставит задачу через один из интерфейсов. Например, делает запрос в базу данных сотрудников через чат-бота. Интерфейс передаёт консистентные данные в робота-обработчика, то есть запускает скрипт с заданными параметрами. Обработчик эмулирует пользователя и делает что-то в прикладе, затем отдаёт результат в интерфейс.

То есть:

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

Вот пример того, как робот логинится в системе и делает пропуск:

Спешу охладить пыл

Да, это очень быстро. Да, это очень дёшево в сравнении с полноценной автоматизацией через встроенное API или сервера интеграции. Но есть и куча недостатков:

  1. Робот эмулирует пользователя какой-то системы. Это значит, что ему нужно отдельное рабочее место с этой системой. То есть нужно иметь дополнительную лицензию, если лицензирование по юзерам или машинам.
  2. Робот работает гораздо быстрее человека, но через человеческие интерфейсы. То есть то, что делает человек за 8 часов, он делает условно за 4 минуты. Но это не 2 секунды, как в случае API-интеграции, — робот ждёт загрузки интерфейсов и их полной отрисовки. Это значит, что сервер робота может быть занят на массовых запросах. Нужно несколько машин = появляется оркестратор и больше лицензий на то, чтобы было несколько потоков одновременно.
  3. Робот, эмулирующий действия пользователя, чувствителен к большим апдейтам систем. Если интерфейс значительно меняется, требуется перенастройка бота (это занимает от 3 до 10 рабочих часов).
  4. Робот не может действовать от своего имени (логинится под собой), он каждый раз действует от имени конкретного пользователя.

Про последнее стоит пояснить отдельно. Например, когда мы бегали в HR-систему, возникли определённые проблемы. Нужно было пустить в систему учётку бота, имеющего такие же права, как кадровик, чтобы он пользовался HRSM, Outlook с почтой и контактами и календарями. Когда речь зашла о том, что робот будет работать в прикладе, это повергло всех в идеологический шок и ступор.

Правила просты: в Human Resource Management System указываются права каждого сотрудника. Доступы берутся оттуда. В HRMS нельзя заводить роботов, потому что она именно «Human». А данные по учёткам и контактам только там. Чтобы сотрудник работал, он должен быть человеком. В итоге для альфы мы взяли учётку разработчика и завели робота от его имени. Это автоматом означает, что мы записали все косяки робота на него же. В бете мы придумали лайфхак поинтереснее: завели контрагента (состоящего из этого робота) и пустили его с разработчиком-ответственным в систему. Тем не менее, если робот что-то не то сделает, придётся как-то его вести в суд, чтобы отвечать. А мне впаяют халатность и отсутствие надлежащей проверки контрагента.

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

Поэтому первый закон робототехники у нас такой: робот всё делает от имени человека.

Что было дальше

Мы придумали ещё с десяток применений ботам: отчётность в чат-боте, загрузка первичных документов в Телеграм для добавления в 1С, диалог по заполнению документов, отчёты о командировках, массовое создание документов для отчёта и отправка всем участникам. И так далее.

Оказалось, почти всё это можно сделать за 2 дня, что мы и доказали. С описанными выше ограничениями.

Логика такая: если всё работает, то можно оценить, сколько робот экономит времени и пользуется ли им кто-то. Если нужно сделать всё «с чувством, с толком, с расстановкой» и у заказчика очень много времени — можно, конечно, передать задачу в отдел автоматизации, и там степенные парни без спешки делают всё ровно и гладко. Поскольку интерфейсы для пользователя одни и те же, перехода он даже не замечает. Если же нужно быстро автоматизировать задачи типа печати бейджей и сертификатов (у наших девушек из event-направления это занимало по две ночи), то робот просто работает, и всё.

Эволюция такая:

  1. Прототип или не очень ответственная задача
  2. Стадия эксплуатации
  3. Ответственный сервис

А дальше родился опасный миф. Когда наши топы увидели, как это работает, — обмолвились про процесс со словами «трудозатрат ноль». Так вот, это не ноль. Да, для быстрого прототипирования всё можно сделать за два дня. Для нормальной отладки — две недели. Но потом всё работающее надо будет заменять на API-driven или что-то системное, а не эмуляцию пользователя.

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

Первое применение было у отдела обучения. Для них это была настоящая магия. Девушки загружают список участников (а бывает и 200 человек) в BPM-систему, а робот за 5–6 минут делает следующее:

  1. Заказывает пропуска на всех.
  2. Верстает бейджи по шаблону и готовит сертификаты.
  3. Считает кейтеринг (еду, кофе-брейк) на всех у известных поставщиков. В текущей реализации — у одного, потому что у нас он технически один (выбор делается до бота).
  4. Формирует раздатку и отправляет на печатать или секретарям. Предупреждает всех, кому это может быть нужно, например: охрану, инженеров зала обучения, звукооператоров и так далее.
  5. Собирает встречу и отправляет всем участникам приглашения, карту до места проведения, контакты ответственного и программу мероприятия.
  6. Напоминает всем за сутки.

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

В итоге эта часть отлично показала себя в эксплуатации. Стек технологий такой:

Самое сложное тут — это оркестратор роботов, чтобы распределить потоки. У нас большой офис, почти 2 тысячи человек. Оркестратор нужен для управления роботами, назначения им заданий, установки расписания заданий роботам, мониторинга их работы, управления очередями заданий, разделения заданий между роботами и т. д. С технической точки зрения нужна отдельная сущность — и нужен сервер терминального доступа, чтобы разные задачи шли в разные рабочие места бота. Во время тестов было много негатива из-за занятости робота — он однозадачный. Если один робот не справляется, а время выполнения задачи довольно критично, то нужно ему на помощь ставить второго робота (за доп. лицензию). Если время выполнения задания критичным НЕ является, то задание можно поставить в очередь (с использованием оркестратора), и когда робот освободится, он выполнит поставленное в очередь.

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

Обсудить в нашей группе в фейсбуке >>

Также по теме