Интеграция HR-системы с 1С, ERP и корпоративными сервисами
Как спроектировать интеграции HRTech: мастер-данные, направления обмена, идентификаторы, частота, безопасность, журнал ошибок и план тестирования.
Составьте карту систем и сущностей
Нарисуйте текущий и целевой контур. Обычно в нём участвуют 1С или другая кадрово-расчётная система, HRM, ATS, КЭДО, LMS, каталог пользователей, корпоративный портал, сервис-деск и BI. Для каждой связи укажите не название интеграции, а конкретные сущности и события.
| Сущность | Типичная мастер-система | Получатели | Событие обновления |
|---|---|---|---|
| Сотрудник и кадровый статус | Кадровая система | HRM, КЭДО, LMS, каталог, BI | Приём, перевод, изменение, увольнение |
| Оргструктура и должность | Кадровая система или HRM | Права, маршруты, отчёты | Утверждённое изменение структуры |
| Кандидат и вакансия | ATS | HRM, кадровый контур, аналитика | Оффер и подтверждённый выход |
| Отсутствие | HRM или кадровая система | Табель, календарь, планирование | Создание, согласование, отмена |
| Документ и статус подписи | КЭДО | Кадровая система, архив, отчёты | Отправка, подпись, отказ, завершение |
| Обучение и сертификат | LMS | HRM, допуски, BI | Назначение, завершение, истечение срока |
Выберите устойчивый идентификатор
ФИО, email и табельный номер могут меняться или повторяться. Для связи нужен постоянный внутренний идентификатор и таблица соответствий для систем, которые используют собственные ключи. Отдельно продумайте повторный приём, совместительство, несколько трудовых отношений и исторические записи.
Режимы обмена
| Подход | Когда подходит | Что проверить |
|---|---|---|
| API по запросу | Интерактивные операции и получение актуального состояния | Авторизация, лимиты, таймауты, версионирование |
| События и вебхуки | Быстрая реакция на изменение | Повторная доставка, порядок, подпись запроса |
| Очередь сообщений | Высокая нагрузка и независимость систем | Идемпотентность, мониторинг, мёртвые сообщения |
| Файловый обмен | Регламентные пакеты и старые системы | Формат, кодировка, шифрование, контроль полноты |
| Периодическая выгрузка | Отчётность и витрины данных | Дата среза, инкремент, история изменений |
Повтор одного сообщения не должен создавать второго сотрудника, документа или отсутствия. Для изменяющих операций используйте внешний ключ и идемпотентность. Система должна различать временную техническую ошибку и бизнес-ошибку данных, которую обязан исправить владелец.
Пример сквозного сценария
Журнал и мониторинг
Для каждой операции сохраняйте идентификатор, время, систему-источник, тип события, статус, число попыток и безопасное описание ошибки. Нельзя помещать в общий технический лог лишние персональные данные. Для поддержки нужны поиск, повтор, выгрузка и уведомления при накоплении очереди.
- дашборд успешных и ошибочных обменов;
- порог задержки и автоматическая эскалация;
- разделение технических и бизнес-ошибок;
- корреляционный идентификатор сквозного процесса;
- контроль полноты пакетной загрузки;
- регламент ручного восстановления;
- история изменения контрактов API.
Безопасность
Передавайте только необходимые поля, шифруйте канал и файлы, используйте технические учётные записи с минимальными правами, регулярно меняйте секреты и фиксируйте обращения. Тестовые контуры не должны получать полную копию продуктивных персональных данных без обоснования и защиты.
План тестирования
- Успешное создание каждой сущности.
- Повтор того же сообщения без дубля.
- Изменение и отмена операции.
- Неверное обязательное поле.
- Временно недоступная принимающая система.
- Сообщения, пришедшие не по порядку.
- Большой пакет и пиковая нагрузка.
- Смена идентификатора, email, фамилии и подразделения.
- Увольнение и отзыв доступов.
- Восстановление после перезапуска или очереди ошибок.
- Для каждой сущности назначена мастер-система.
- Используется постоянный идентификатор и таблица соответствий.
- Описаны направление, частота и событие обмена.
- Повторные запросы не создают дубли.
- Ошибки видны, классифицируются и повторяются управляемо.
- Персональные данные ограничены необходимым составом.
- Есть тестовый контур и полный набор негативных сценариев.
- Ответственность команд закреплена в регламенте.
Хорошая интеграция остаётся незаметной для пользователя, но прозрачной для сопровождения. Проектируйте её как отдельный продукт с владельцем, метриками качества, документацией и планом развития, а не как разовую техническую передачу полей.