Роботы внутри офиса: что можно сделать за 3 дня вместо полугода
История началась с того, что нам понадобился доступ к HR-системе для чат-бота. Чтобы последний мог искать контакты сотрудников по запросу вроде: «Найди того, кто может починить пиканиску». В корпоративной инфраструктуре это выглядит так: мы идём в отдел автоматизации и говорим, что нам нужны данные из HRMS. И получаем закономерный ответ:
— Пишите ТЗ, предоставим API и сервер интеграции через 6 месяцев.
— Парни, вы чего? Нам бы побыстрее!
— Тогда пишите ТЗ и письмо руководителю, сможем СРОЧНО уложиться за 3 месяца.
А нам надо было за 3 дня. Поэтому мы пошли другим путём: попросили кадровиков завести нам бота в список сотрудников и дать ему доступ к системе. Дальше он уже делал то, что на его месте мог бы делать человек.
В итоге старая шутка про то, что если программисты доберутся до власти, то весь парламент можно будет заменить простым bash-скриптом, оказалась не такой уж шуткой. Наши роботы, конечно, не самые оптимальные с точки зрения архитектуры на годы вперёд, но работают. Про то, что именно они делают и откуда такие сроки, я сейчас и расскажу.
Итак, первичная идея очень проста: можно взять робота, который будет имитировать действия пользователей. Например, если нам нужен доступ в HR-систему — не надо строить сервер интеграции и получать API. Нужно просто научить робота нажимать нужные кнопки и парсить ответы. Благо почти все современные интерфейсы очень и очень дружелюбны к роботам — в MS-софте везде есть теги элементов управления для альтернативного доступа, горячие клавиши или узнаваемые иконки. Мы просто учим робота нажимать нужные кнопки в нужной последовательности. Около часа уходит на автоматизацию процесса по типу макроса в Ворде или записи действия в Фотошопе, а оставшиеся 90% — это тесты и обработка исключений.
Пользователь нажимает на кнопку в интерфейсе. Затем данные собираются, и запускается робот. Кнопка как отдельный интерфейс (фронтэнд) нужна потому, что, например, чат-бот не может снять скриншот сам. Но может рассказать про кнопку, поскольку пользователь привык, что все вопросы можно адресовать чат-боту как основному интерфейсу. Чат-бот же запускает роботов.
В целом пользователь ставит задачу через один из интерфейсов. Например, делает запрос в базу данных сотрудников через чат-бота. Интерфейс передаёт консистентные данные в робота-обработчика, то есть запускает скрипт с заданными параметрами. Обработчик эмулирует пользователя и делает что-то в прикладе, затем отдаёт результат в интерфейс.
То есть:
— Есть интерфейсы запуска роботов: это чат-боты, кнопки, скрипты, события и таймеры или действия других роботов.
— Есть действия роботов: это получение и преобразование данных.
— И есть вывод результата пользователю: это выгрузка обратно в интерфейс ответа чат-бота, результат в файле на почте и так далее.
Вот пример того, как робот логинится в системе и делает пропуск:
Спешу охладить пыл
Да, это очень быстро. Да, это очень дёшево в сравнении с полноценной автоматизацией через встроенное API или сервера интеграции. Но есть и куча недостатков:
- Робот эмулирует пользователя какой-то системы. Это значит, что ему нужно отдельное рабочее место с этой системой. То есть нужно иметь дополнительную лицензию, если лицензирование по юзерам или машинам.
- Робот работает гораздо быстрее человека, но через человеческие интерфейсы. То есть то, что делает человек за 8 часов, он делает условно за 4 минуты. Но это не 2 секунды, как в случае API-интеграции, — робот ждёт загрузки интерфейсов и их полной отрисовки. Это значит, что сервер робота может быть занят на массовых запросах. Нужно несколько машин = появляется оркестратор и больше лицензий на то, чтобы было несколько потоков одновременно.
- Робот, эмулирующий действия пользователя, чувствителен к большим апдейтам систем. Если интерфейс значительно меняется, требуется перенастройка бота (это занимает от 3 до 10 рабочих часов).
- Робот не может действовать от своего имени (логинится под собой), он каждый раз действует от имени конкретного пользователя.
Про последнее стоит пояснить отдельно. Например, когда мы бегали в HR-систему, возникли определённые проблемы. Нужно было пустить в систему учётку бота, имеющего такие же права, как кадровик, чтобы он пользовался HRSM, Outlook с почтой и контактами и календарями. Когда речь зашла о том, что робот будет работать в прикладе, это повергло всех в идеологический шок и ступор.
Правила просты: в Human Resource Management System указываются права каждого сотрудника. Доступы берутся оттуда. В HRMS нельзя заводить роботов, потому что она именно «Human». А данные по учёткам и контактам только там. Чтобы сотрудник работал, он должен быть человеком. В итоге для альфы мы взяли учётку разработчика и завели робота от его имени. Это автоматом означает, что мы записали все косяки робота на него же. В бете мы придумали лайфхак поинтереснее: завели контрагента (состоящего из этого робота) и пустили его с разработчиком-ответственным в систему. Тем не менее, если робот что-то не то сделает, придётся как-то его вести в суд, чтобы отвечать. А мне впаяют халатность и отсутствие надлежащей проверки контрагента.
И ещё один недостаток: да, робот может ошибаться. Наша политика — никаких непоправимых действий без того, чтобы посмотрел человек. То есть робот может подготовить все документы на командировку и заказать её сам, но последнее мы ему не разрешаем. Он кладёт все документы на сетевую шару сотруднику отдела деловых поездок, и уже тот тратит деньги компании. Потому что мы не хотим из-за какого-нибудь редкого бага отправить весь офис в две тысячи сотрудников в командировку в Анадырь и оплатить её.
Поэтому первый закон робототехники у нас такой: робот всё делает от имени человека.
Что было дальше
Мы придумали ещё с десяток применений ботам: отчётность в чат-боте, загрузка первичных документов в Телеграм для добавления в 1С, диалог по заполнению документов, отчёты о командировках, массовое создание документов для отчёта и отправка всем участникам. И так далее.
Оказалось, почти всё это можно сделать за 2 дня, что мы и доказали. С описанными выше ограничениями.
Логика такая: если всё работает, то можно оценить, сколько робот экономит времени и пользуется ли им кто-то. Если нужно сделать всё «с чувством, с толком, с расстановкой» и у заказчика очень много времени — можно, конечно, передать задачу в отдел автоматизации, и там степенные парни без спешки делают всё ровно и гладко. Поскольку интерфейсы для пользователя одни и те же, перехода он даже не замечает. Если же нужно быстро автоматизировать задачи типа печати бейджей и сертификатов (у наших девушек из event-направления это занимало по две ночи), то робот просто работает, и всё.
Эволюция такая:
1. Прототип или не очень ответственная задача
2. Стадия эксплуатации
3. Ответственный сервис
А дальше родился опасный миф. Когда наши топы увидели, как это работает, — обмолвились про процесс со словами «трудозатрат ноль». Так вот, это не ноль. Да, для быстрого прототипирования всё можно сделать за два дня. Для нормальной отладки — две недели. Но потом всё работающее надо будет заменять на API-driven или что-то системное, а не эмуляцию пользователя.
Ещё робот действует от имени кого-то. В нашем случае он действует от имени авторизованного в чат-боте пользователя. Мы не пускаем снаружи — соответственно, робот не может заказать от кого-то. Жёсткая проверка, которая зашита на всех уровнях от интерфейса до миддлэнда. Корректность введённых данных для формы проверяет сам бот. Интерфейсный бот (чат-бот) проверяет логику ввода данных (командировка не может быть раньше сегодняшней даты), а исполняющий бот (эмулятор пользователя) — целостность поступающих данных.
Первое применение было у отдела обучения. Для них это была настоящая магия. Девушки загружают список участников (а бывает и 200 человек) в BPM-систему, а робот за 5–6 минут делает следующее:
- Заказывает пропуска на всех.
- Верстает бейджи по шаблону и готовит сертификаты.
- Считает кейтеринг (еду, кофе-брейк) на всех у известных поставщиков. В текущей реализации — у одного, потому что у нас он технически один (выбор делается до бота).
- Формирует раздатку и отправляет на печатать или секретарям. Предупреждает всех, кому это может быть нужно, например: охрану, инженеров зала обучения, звукооператоров и так далее.
- Собирает встречу и отправляет всем участникам приглашения, карту до места проведения, контакты ответственного и программу мероприятия.
- Напоминает всем за сутки.
Каждая задача — это отдельный микросервис. Понятное дело, поддерживать всё это сложно, но по мере развития эти микросервисы будут уходить не на эмуляцию пользователя в терминальном сервере, а на более продвинутую автоматизацию. Это же позволит разгрузить робота, а то бывает всякое, поскольку у нас всего 4 потока:
В итоге эта часть отлично показала себя в эксплуатации. Стек технологий такой:
Самое сложное тут — это оркестратор роботов, чтобы распределить потоки. У нас большой офис, почти 2 тысячи человек. Оркестратор нужен для управления роботами, назначения им заданий, установки расписания заданий роботам, мониторинга их работы, управления очередями заданий, разделения заданий между роботами и т. д. С технической точки зрения нужна отдельная сущность — и нужен сервер терминального доступа, чтобы разные задачи шли в разные рабочие места бота. Во время тестов было много негатива из-за занятости робота — он однозадачный. Если один робот не справляется, а время выполнения задачи довольно критично, то нужно ему на помощь ставить второго робота (за доп. лицензию). Если время выполнения задания критичным НЕ является, то задание можно поставить в очередь (с использованием оркестратора), и когда робот освободится, он выполнит поставленное в очередь.
Итог — в наших разработчиков уже показывают пальцами и говорят, что это именно те люди, которые обеспечат массовое сокращение персонала. Мы немного боимся, что нас побьют, но гордимся. И пересказываем всем анекдот про правительство.
Ссылки
- Что могут чат-боты в офисе
- Что может IVR
- Моя почта — digital@croc.ru
