У одного моего клиента внедрена коробочная версия Битрикс24. Внутренним заказчиком автоматизации выступила HR-служба.
Первоначальная постановка задачи была достаточно простой: сделать так, чтобы HR-служба не забывала поздравлять сотрудников с важными датами — днями рождения и годовщинами работы в компании.
В подготовке поздравления должны были участвовать три роли:
HR-специалист — готовит текст поздравления
дизайнер — готовит поздравительную иллюстрацию
ответственный за публикацию — размещает поздравление в Ленте новостей в нужный день.
Сначала я разобрался, как был организован процесс и почему существующий механизм не обеспечивал своевременную подготовку поздравлений.
Ранее прежний интегратор уже пытался решить эту задачу: в Битрикс24 было установлено приложение «Годовщины сотрудников» из Маркета, которое напоминало о приближающихся датах через стандартные уведомления.
Само по себе решение было рабочим. Но стандартные уведомления быстро терялись среди других сообщений Битрикс24, поэтому сотрудники не всегда возвращались к ним вовремя.
Возможности проконтролировать подготовку поздравления и его публикацию в Ленте новостей тоже не было.
Фактически действующая автоматизация заканчивалась в момент отправки напоминания. Поэтому нужна была уже не система уведомлений, а процесс, который заранее запустит подготовку поздравления и позволит контролировать её до завершения.
При этом благодаря предыдущему приложению данные по действующим сотрудникам уже были заполнены. Дата рождения хранилась в стандартном поле профиля пользователя, а дата выхода в компанию — в дополнительном поле «Первый рабочий день».
Существующая модель хранения данных решала свою задачу, поэтому переносить даты в другое хранилище только ради новой автоматизации не было смысла.
От приложения «Годовщины сотрудников» было решено отказаться, сохранив уже собранные данные и построив собственный процесс поверх существующей модели.
Почти сразу обнаружилась другая проблема. Поскольку даты хранились в профилях пользователей, сотрудники HR-службы не могли самостоятельно их изменять: для этого требовались административные права.
Приложение «Годовщины сотрудников» имело интерфейс управления этими датами, сохраняя данные в пользовательские профили. А с удалением приложения этого интерфейса не стало.
HR-служба была владельцем процесса, но управлять исходными данными, от которых этот процесс зависел, самостоятельно не могла.
Технически первоначальный запрос можно было закрыть проще: раз в сутки читать даты непосредственно из профилей пользователей и создавать задачи на подготовку поздравлений. Такой вариант автоматизировал бы запуск задач, но не решил бы проблему сопровождения исходных данных: HR-служба по-прежнему не могла бы самостоятельно управлять датами, за актуальность которых отвечала.
Таким образом, задача уже не сводилась к автоматическому созданию напоминаний. Нужно было решить сразу несколько вопросов:
дать HR-службе возможность самостоятельно сопровождать даты сотрудников без административных прав
сохранить существующую модель хранения данных, чтобы не ломать уже работающие части Битрикс24
исключить расхождения между рабочим интерфейсом HR и профилями пользователей
автоматически запускать подготовку поздравлений заранее и перевести её в контролируемые задачи
В публичной части портала я создал для HR-службы собственный реестр годовщин на базе смарт-процесса.
HR работает с датами через этот реестр без административных прав на портале, а изменения автоматически синхронизируются с профилями пользователей.
Фактически получилось два интерфейса для работы с одними и теми же данными. Профили пользователей остались основным источником данных, а смарт-процесс стал рабочим интерфейсом HR-службы.
Поскольку данные могли изменяться как в профиле пользователя, так и через HR-реестр, между ними была реализована двусторонняя синхронизация. Она закрывает основные рабочие сценарии:
принят новый сотрудник — запись автоматически появляется в HR-реестре
дата изменена администратором в профиле — изменение автоматически попадает в смарт-процесс
дата изменена HR в смарт-процессе — изменение автоматически записывается в профиль
сотрудник уволен — запись в смарт-процессе становится неактивной и перестаёт участвовать в автоматизации
сотрудника приняли повторно — существующая запись снова активируется, дубль не создаётся
запись деактивировали непосредственно в смарт-процессе — учётная запись пользователя остаётся активной. Это защищает от случайной блокировки сотрудника через HR-интерфейс
Для HR-службы я создал отдельное цифровое рабочее место и разместил в нём смарт-процесс «Годовщины сотрудников».
Для каждого сотрудника в реестре хранятся ссылка на пользователя Битрикс24, дата рождения, дата первого рабочего дня и признак активности.
Права доступа настроены так, чтобы HR мог полностью сопровождать эти данные через реестр, но при этом не получал административных прав к порталу.
Дальше требовалось связать реестр с профилями пользователей.
При создании нового пользователя обработчик события OnAfterUserAdd проверяет, входит ли он в группу «Сотрудники». Если входит — через фабрику автоматически создаётся соответствующий элемент смарт-процесса.
Для изменений профиля используется OnAfterUserUpdate. Здесь была одна техническая особенность: событие вызывается при любом изменении пользователя и передаёт только те поля, которые были изменены. Поэтому обработчику недостаточно просто взять входящие данные и записать их в реестр.
Сначала он дополнительно получает актуальное состояние пользователя, формирует полный набор нужных значений и сравнивает его с текущей записью смарт-процесса. Если различий нет — ничего не происходит. Если данные изменились — запись обновляется.
Обратное направление реализовано через OnCrmDynamicItemUpdate. Если HR меняет дату рождения или первый рабочий день в реестре, изменение автоматически попадает в профиль пользователя. При этом обработчик предварительно проверяет, действительно ли изменились нужные поля, чтобы не выполнять лишние обновления.
В обоих направлениях синхронизация выполняется только при фактическом расхождении данных. Это не только исключает лишние обновления, но и защищает от рекурсивной цепочки событий OnAfterUserUpdate → OnCrmDynamicItemUpdate → OnAfterUserUpdate: после первой синхронизации значения совпадают, поэтому следующий обработчик завершает работу без обновления.
Когда вопрос с данными был решён, можно было автоматизировать сам процесс.
Для участников процесса я создал отдельную рабочую группу «Сотрудники. Годовщины». В ней создавались все задачи по поздравлениям, поэтому в одном месте сохранялись сами задачи, обсуждения и история их выполнения.
Раз в сутки агент Битрикс24 запускает бизнес-процесс «Поставить задачу на поздравление сотрудников».
Механизм запуска и бизнес-логика разделены. Агент отвечает только за расписание, а проверка реестра и создание задач выполняются внутри бизнес-процесса. Поэтому изменение правил постановки задач не требует изменения кода агента.
Бизнес-процесс проходит по активным записям реестра и проверяет две даты: день рождения и первый рабочий день. Поскольку оба события повторяются ежегодно, при проверке учитываются только день и месяц.
Если событие наступит через семь дней, система создаёт отдельную задачу на подготовку поздравления. В ней участвуют HR-специалист, дизайнер и ответственный за публикацию. HR готовит текст, дизайнер — иллюстрацию, а ответственный в нужный день публикует готовое поздравление в Ленте новостей.
После публикации задача закрывается вручную ответственным за публикацию, так как именно он выполняет последний шаг процесса.
На этом месте как раз и проявляется главное отличие от первоначального решения. Вместо одноразового уведомления появляется полноценный объект работы: у него есть участники, срок, статус и история. Его нельзя просто прочитать и забыть. Его можно контролировать и строить аналитику.
К этому моменту основная логика уже была готова, но новый реестр оставался пустым. Данные примерно по 100 действующим сотрудникам уже находились в профилях.
Создавать записи вручную смысла не было, поэтому я разово провёл первоначальную синхронизацию. Для каждого действующего сотрудника была создана запись в смарт-процессе и перенесены имеющиеся даты.
После этого профили и реестр пришли в одно состояние, а дальше актуальность уже поддерживалась автоматически обработчиками событий.
Проект я дополнительно задокументировал: описал назначение решения, структуру смарт-процесса, обработчики, агента, бизнес-процесс и общую логику синхронизации.
Я документирую все свои решения. Документация нужна не только для передачи другому специалисту. Через полгода детали реализации забываются даже у автора, а хороший документ сильно упрощает диагностику и развитие.
Кроме того, имея документацию, делать онбординг пользователей гораздо проще.
В итоге первоначальная просьба «не забывать поздравлять сотрудников» превратилась в полноценный автоматизированный процесс: HR получил собственный интерфейс для сопровождения дат, а подготовка поздравлений стала запускаться заранее в виде контролируемых задач.
На момент написания кейса решение использовалось в компании уже около полутора лет. За это время поздравления с днями рождения и годовщинами регулярно публиковались в Ленте Битрикс24, а сама автоматизация продолжала работать без постоянного участия разработчика.
Такая схема применима не только к поздравлениям. По сути, получилась связка реестра событий, привязанных к сотрудникам и датам, и механизма, который заранее запускает необходимый процесс.
По похожей схеме можно автоматизировать процессы, связанные с окончанием испытательного срока, истечением документов, обязательным обучением и аттестациями, ежегодной оценкой сотрудников и другими кадровыми событиями.
Логика везде одна: есть событие, дата которого известна заранее; есть люди, которые должны выполнить определённые действия; и есть срок. В такой ситуации нет необходимости полагаться на память — система вполне может сама вовремя запустить нужный процесс.
В этом кейсе автоматизация началась не с выбора инструмента, а с анализа самого процесса. В результате удалось сохранить уже работающую модель данных, дать HR-службе удобный интерфейс для сопровождения кадровых дат и заменить разовое напоминание контролируемым процессом подготовки поздравлений.
Именно такой подход — сохранить работающие части системы, устранить реальные ограничения процесса и автоматизировать недостающие этапы — я считаю наиболее рациональным.