Привет, Хабр! Меня зовут Андрей Петухов, я Senior System Analyst в МТС Диджитал. В нашей команде аналитик ориентирован на full-stack, поэтому нужно вникать и в бизнесовую, и в системную части. Сегодня расскажу об одном нашем кейсе: как мы настроили внутренний кадровый электронный документооборот при помощи наших систем и No-Code- и Low-Code-платформы, с какими проблемами столкнулись и к чему в итоге пришли.
Как мы побороли имитацию кадрового электронного документооборота
Первая версия системы Docs разрабатывалась отдельной командой. Стояла задача — в сжатые сроки создать решение, которое ускорило бы работу кадровых служб. Для этого требовалось отказаться от бумаги и сценариев, когда сотрудник очно взаимодействует с кадровой службой. Результат — получилась заявочная система, которую никак нельзя было назвать привычной для КЭДО. Дальше объясню, почему.
Плюс такой системы был в том, что сотрудники могли дистанционно подать заявление и подписать его ПЭП. Но потом им все равно приходилось идти в кадровую службу и на бумаге подписывать заявление и результирующий документ. Так что и плюсом это назвать сложно: трудозатраты не уменьшились. По сути такая система была только имитацией КЭДО. Когда ее разрабатывали, не учли требования законодательства, не применили усиленные электронные подписи, не привлекли удостоверяющий центр. Цель КЭДО — избавиться от бумаги и автоматизировать работу кадровой службы — не была достигнута.
Дальше заказчики проекта осознали, что имитации КЭДО недостаточно. Для модернизации решения привлекли новую команду — я как раз в ней состоял.
Изучив разработанную систему, мы поняли, что развивать ее дальше нецелесообразно. Из-за сжатых сроков предыдущая команда не успела докрутить технические моменты. Было много критических зависимостей: если вносили правки в одном месте, что-то ломалось в другом. Печатные формы документов генерировались FE-библиотекой прямо на UI в HTML, то есть пользователь, вбивая данные в форму, де-факто вносил изменения в HTML. Такой подход был небезопасен — например, злоумышленник мог внести вредоносный код через HTML-инъекцию.
Лего из разных систем
Мы вплотную взялись за Docs и начали исследовать: какие инструменты у нас вообще есть, можем ли мы реализовать полноценный КЭДО сами? И нашли в МТС платформы, которые можно было задействовать для наших целей.
Например, обнаружилась внутренняя платформа для электронного документооборота в разных сферах бизнеса МТС. У нее уже была реализована вся функциональность взаимодействия с Крипто-Про и удостоверяющим центром МТС. Оставалось только доработать функции подписания для соответствия Приказу Минтруда России от 20.09.2022 № 578н. Коллеги, сопровождающие платформу, быстро с этим справились.
Потом мы нашли решение для создания шаблонов документов и формирования печатных форм. С его помощью нам удалось избавиться от FE-библиотеки.
Решения нашли, а как их объединить?
Разрабатывать систему мы начали на микросервисной архитектуре. Каждый микросервис отвечал за интеграцию со своей платформой, а весь процессинг КЭДО был реализован кодом и реестрами. Первичные бизнес-требования показывали, что весь процессинг типизирован. Его достаточно единоразово выстроить — и на этом все закончится.
Вот только бизнес-заказчики динамичны, у них постоянно появляются новые идеи и хотелки. Так что мы отказались от реализации процессинга кодом и реестром. Начали искать другой способ, чтобы его можно было оперативно создавать или изменять. Как раз в этом нам помогла внутренняя Low-Code/No-Code-система Jocasta — не так давно она была разработана в МТС.
Микросервис, который должен был реализовывать процессинг кодом, стал агрегатором No-Code-сценариев. Агрегатор в определенный момент запускал сценарий Jocasta и передавал ему управление, то есть ожидал от него какого-то результата.
У нас получился такой пользовательский сценарий:
работник заполняет поля шаблона документа. Они передаются в систему генерации печатных форм. Потом работник видит печатную форму и может ее подписать;
по настроенному шаблону процесса КЭДО запускается сценарий в Jocasta. Для некоторых процессов КЭДО это могла быть даже последовательность сценариев. Выполняются определенные задачи: где-то нужно согласовать, где-то выполнить операцию, провести учет;
если предусматривается результирующий документ, сначала его подписывает работодатель, потом — сотрудник.
Пара слов о Jocasta
Как я уже сказал выше, Jocasta — это Low-Code и No-Code-система. У нее есть дизайнер, через который можно набросать разные кубики, и редактор контекста — он позволяет задать контракт для контекста, с которым будет работать сценарий.
Low-Code-инструмент в Jocasta реализован как специальный кубик под названием «функция». Когда сценарий процесса доходит до шага выполнения этого кубика, исполняется отдельно написанный код. Чтобы написать его, необязательно быть гуру-разработчиком, так что я взял эту задачу на себя. Что получается в результате: каждая отдельная функция представляет из себя маленький веб-сервис. Когда его вызываешь, выполняется одна операция. А еще в Low-Code можно для каждой функции задать свои контракты для контекста.
Плюс в Jocasta есть внешний API. Через него мы передаем данные для запуска сценария, которому они нужны, по заданным заранее контрактам. Так прогоняется весь процесс. Есть и своя отдельная витрина, мы используем ее в наших процессах. Бизнес дает нам глобальное требование: все операционисты должны работать через витрину сервиса. Поэтому мы разделили часть функциональности: один пользователь работает на нашем UI, а другой — на UI Jocasta.
Реализовать взаимодействие с витриной Jocasta, сценарием и нашей системой нам помог Low-Code. Для согласования, подписания со стороны работодателя, выполнения задач кадровыми специалистами задействована базовая функциональность витрины и сценария. А для взаимодействия с нашей системой используется кубик «функция», он исполняется при наступлении шага сценария. Например, кубик может по REST-API вызвать нашу систему, передать данные из контекста сценария. И наоборот, встать в режим ожидания, пока система не отправит определенный запрос в сценарий.
Шлифуем решение
Процессинг в КЭДО с подачей заявления, ведением учета и подписания результирующего документа мы реализовали, но это меньшая часть от потребностей бизнеса. Есть процессы КЭДО, которые могут инициироваться не со стороны пользователя, а со стороны работодателя. При этом точек входа может быть много.
Например, у нас есть отдельная система для управления отпусками работника. Бизнес-процессы в ней тоже затрагивают КЭДО, значит кадровые документы должны подписываться.
Для реализации всех этих хотелок мы разработали в системе внешний REST-API. Другие продукты могут передавать через него готовые документы или их параметры для генерации. После инициализации процесса через внешний REST-API он (по аналогии с базовым процессингом) прогонялся через No-Code/Low-Code и выдавал системе результат.
К чему мы пришли
Расскажу, чего мы достигли с нашим решением:
Нам не нужно привлекать разработчиков. Теперь мы можем реализовать в Low-Code практически любой процесс сами. Например, у бизнеса появляется идея: а давайте-ка сделаем такой кадровый документ, который будем сначала отдавать кадровому координатору на согласование, а потом отправлять сотрудникам на подпись. И мы можем выполнить эту задачу в течение дня. То есть с помощью no-code мы рисуем процесс, в Docs добавляем необходимые шаблоны и делаем все это видимым для пользователей. Получается, мы снизили трудозатраты на решение задач от бизнеса.
Мы угодили пользователю и операционистам. У пользователя есть максимально удобный интерфейс. Ему практически ничего не нужно делать, чтобы отправить или получить нужный документ. В то же время операционисты всегда пользовались витриной Jocasta, помимо задач КЭДО, у них туда поступает еще огромное количество других запросов. Теперь все свои задачи — по КЭДО и не только — они видят в одном месте. Создается единая очередь, и им удобно контролировать свою нагрузку. Это тоже позволяет оптимизировать трудозатраты. К тому же руководство может быстро смотреть статистику и принимать управленческие решения.
Мы можем составить практически любую печатную форму. Если бы мы использовали библиотеку, в которой все было сделано изначально, у нас появилось бы много ограничений. Чтобы добавлять шаблоны, нам пришлось бы привлекать разработчиков. И все это было бы сложно дебажить, так как все изменения происходили бы внутри кода.
Процессы легальны. Все документы соответствуют текущему законодательству и имеют юридическую силу. Мы выполнили свою главную задачу — заменили бумажные документы электронными.
Что дальше?
Мы смогли частично избавиться от бумаги и унифицировать процесс взаимодействия работника и работодателя. Но кадровые службы можно разгрузить еще больше: документы хоть и электронные, но изменения в учетную систему вносятся вручную, как раньше. Так что следующий наш шаг — реализация автоматического учета.
Пока на этом все. Задавайте вопросы в комментариях — постараюсь на них ответить!