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