Ни для кого не секрет, что госсектор живет по своим правилам. Правила эти довольно специфичны и зачастую ограничений здесь гораздо больше, чем в коммерческом секторе. Требования законодательства и штрафы за нарушения этих требований, необходимость формирования различного вида отчетов, сложившихся исторически и исполняемых по традиции, требования по размещению информации, различные рейтинги успешности и т.д. Люди заняты, люди работают, отчеты пишутся, все при деле, ни минуты свободного времени.
А лучше кому-нибудь вокруг становится?
Наглядный пример от Центра цифровой трансформации Татарстана. Недавно нам необходимо было разместить информацию в федеральной информационной системе документов и сведений, формируемых ведомством «А». У ведомства есть своя информационная система, созданная для обеспечения ее работы.
Как вы понимаете, для эффективной работы она должна интегрироваться с федеральной, автоматически обновляя информацию. К моменту запроса уже дважды настраивали интеграцию между ними, дважды выделяли средства и человеческие ресурсы. Допустим. Но когда в день Х прошло очередное обновление федеральной системы, интеграция вновь нарушилась. При этом все требования по размещению сведений сохранились, что привело к дополнительной ручной работе сотрудников.
И снова можно выделить бюджетные средства, снова разово настроить интеграцию (в третий раз за пять лет). А сколько еще таких «обновлений» пройдет в ближайшие 3-5 лет – большой вопрос.
Кейс интересный. И, безусловно, актуальный.
Так как автоматизация нашего бизнес-процесса являлась достаточно простой и часто повторяющейся, то для решения задач по бесперебойной интеграции данных нами была выбрана технология автоматизации бизнес-процессов, основанная на применении программных роботов (RPA).
Говоря простым языком, в нашем кейсе бизнес-процесс заключался в последовательном копировании сведений из пользовательского интерфейса ведомственной системы и вставки в свободные поля в пользовательском интерфейсе федеральной системы, прикреплении некоторых файлов и некоторых последовательных нажатий на кнопки.
Так как ранее у нас уже был пусть успешный, но дорогой опыт автоматизации бизнес-процессов с использованием одной из платформ RPA, то мы смогли учесть все нюансы и избежать подводных камней.
Во-первых, тогда мы не смогли уйти от необходимости привлечения программиста для реализации программного робота. Во-вторых, имели место ежегодные лицензионные платежи за использование платформы. В-третьих, когда используешь платформу, заявляется, что это почти ноу-код или лоу-код решение.
Однако в реальности оказывается, что сотрудник должен быть хорошо подкован технически, чтобы суметь разобраться в возможностях платформы, обладать соответствующим мышлением и минимальными навыками программирования. И на выходе мы получаем, что такой сотрудник уже не так далек от программиста начального уровня, и при некоторой практике таким становится.
Исходя из всего этого, решили попробовать для роботизации опенсорсные решения. В частности, на python с использованием различных библиотек для работы браузерами и документами.
Реализовали бизнес-процесс, состоящий из нескольких этапов:
1. Сотрудник ведомства – заполняет сведения в ведомственной информационной системе.
2. Робот – включается после заполнения всех обязательных полей. Переносит сведения в федеральную систему, направляет уведомление на почту сотрудника (и дублирует в тг-канал), о том, что работа начата.
3. Робот – ждет когда федеральная система отработает документ, создаст артефакт необходимый для дальнейшей работы сотрудника и даст сигнал к продолжению работы. Робот ожидает сигнала от федеральной системы.
4. Робот – получает сигнал от федеральной системы и уведомляет сотрудника ведомства о необходимости продолжить заполнение документа.
5. Сотрудник ведомства – формирует документ, прикрепляет его в ведомственную систему.
6. Робот – забирает документ и переносит его в федеральную систему. Уведомляет сотрудника о необходимости подписать документ в федеральной системе.
7. Сотрудник ведомства – подписывает документ в федеральной системе.
8. Робот – ожидает когда федеральная система выдаст артефакт о завершении процесса формирования окончательного документа. После получения артефакта уведомляет сотрудника ведомства о завершении работы над документом.
Здесь нет полного исключения действий человека, поскольку есть промежуточные этапы, когда сотрудник вносит сведения, исходя из содержания документа (роботу неоткуда взять такие сведения), и есть этап подписания документа (мы не будем делегировать такую обязанность на робота по понятным причинам).
Робот может одновременно работать с несколькими десятками документов.
Как ни странно, основные трудности лежали в области менеджмента, а не технологий. Бизнес-процесс не был унифицирован на всей территории ведомства. Ведомство распределено территориально и последовательность формирования документа везде отличалась. А так как робот настроен на определенные триггеры, то он просто не включается, если сотрудники начинают работать в другой последовательности.
Представьте себе порядка 80 человек, заполняющих документ так, как им удобно. И робота, который «говорит»: вы сначала научите каждого работе в нужной последовательности, а потом уже запускайте меня так, как хотите.
Люди – вот это основной вопрос, и их обучаемость. Технологии лишь помогают решать задачи.
На реализацию проекта ушло 60 календарных дней.
20 дней мы формировали описание самого бизнес-процесса, интервьюировали сотрудников ведомств. Еще примерно 20 дней писали код, и примерно столько же тестировали и внедряли. Мы понимаем, что это не чистое время работы, а срок, за который нам удалось выполнить все задуманное, с учетом загрузки сотрудников ведомств, отпусков и других сопутствующих трудностей.
До внедрения программных роботов на перенос сведений в федеральную систему документа определенного типа сотрудник ведомства тратил до 2 часов, с учетом времени ожидания отклика от федеральной системы. Сам перенос сведений при мгновенном отклике (что случается крайне редко) занимал до 20 минут. Легко понять, насколько сильно отвлекает человека постоянная проверка статуса документа в федеральной системе и психологическое напряжение от незавершенности работы с документом, которая по требованиям законодательства должна быть завершена в тот же, день, что и начало работы над документом.
На сегодняшний день за неделю робот на опенсорс решении обрабатывает около 50 документов. При этом его возможности значительно выше. Из неоспоримых плюсов – нет лицензионных платежей. Для технической поддержки решения нужен программист на python, которого найти и нанять гораздо легче, чем любого другого. Это значительно дешевле, чем реализация решения с использованием платформы роботизации.
С какими же подводными камнями мы можем столкнуться? Пожалуйста, пишите в комментариях.
P.S. Подробности по технической стороне вопроса.
Взаимодействие с системами осуществляется с использованием библиотек selenium, request, chrome, os, wget, beatifulsoap.
Робот использует API браузера для взаимодействия с веб-страницей. При открытии страницы, Система запрашивает содержимое HTML-кода у сервера и отображает его в браузере. Затем, с помощью методов API, Система осуществляет навигацию по странице, находит элементы и выполняет на них действия.
Для поиска элементов на странице используются различные стратегии, такие как поиск по ID, имени, классу, тегу и другим атрибутам элемента. Когда элемент найден, Система выполняет на нем различные действия, такие как клик, ввод текста, выбор из списка и т.д. Система также поддерживает работу с фреймами и окнами.
Для обеспечения безопасности, Система управляет параметрами браузера, такими как блокирование всплывающих окон, настройки прокси-сервера и другие.
В некоторых случаях Система осуществляет взаимодействие с веб-страницей посредством отправки HTTP-запросов на сервер и получения ответов.
При отправке запроса, Система передает на сервер нужные параметры, такие как заголовки (содержат информацию о типе контента, куках, авторизации и других параметрах), тело запроса (содержат данные для отправки на сервер, такие как формы или JSON-объекты) и параметры URL (содержат информацию о пути запроса, параметры запроса и другие параметры).
После отправки запроса, Система получает от сервера ответ в виде объекта Response. Этот объект содержит различную информацию о ответе, такую как статус код, заголовки, тело ответа и другие параметры. С помощью методов объекта Response Система получает нужные данные из ответа (например, извлекает JSON-объект или HTML-код страницы).
Система также поддерживает работу с сессиями, что позволяет сохранять состояние между запросами и обрабатывать куки.
Кроме того, Система поддерживает работу с прокси-серверами, SSL-сертификатами и другими параметрами безопасности. Это позволяет осуществлять безопасное взаимодействие с веб-страницей и защищать данные от несанкционированного доступа.
Система анализирует считанную информацию, расположенную на конкретном участке веб-страницы, копирует необходимые значения в собственную память. Выполнение функций осуществляется в соответствии с заранее прописанными правилами и в заранее определенной последовательности (с учетом ветвлений алгоритма).
Отправка уведомлений осуществляется на электронную почту и в мессенджер Telegram (по заранее определенным адресатам) с использованием библиотек smtplid, telethon.
