Единый каталог сотрудников из нескольких источников: как объединить данные
Как объединить данные о сотрудниках из кадровой системы, Active Directory, АТС и других источников в едином внутреннем каталоге организации.
В крупной организации информация о сотрудниках редко находится в одной системе.
Кадровые сведения могут храниться в 1С, учётные записи — в Active Directory, телефонные номера — в АТС, а информация о кабинетах — в отдельной системе или непосредственно во внутреннем справочнике.
При этом пользователю обычно неинтересно, из какой системы получено конкретное поле.
Он хочет открыть одну карточку сотрудника и увидеть всю необходимую рабочую информацию.
Поэтому внутренний каталог может выступать единым представлением данных из нескольких корпоративных систем.
Почему данные о сотрудниках оказываются в разных системах
Каждая корпоративная система обычно решает свою задачу.
Кадровая система управляет кадровой информацией.
Active Directory отвечает за учётные записи и доступ к корпоративной инфраструктуре.
АТС управляет телефонными номерами.
Система управления помещениями может содержать информацию о кабинетах и зданиях.
Такое разделение является нормальным для крупной организации.
Проблема возникает тогда, когда пользователю приходится самостоятельно искать нужную информацию в каждой системе.
Что пользователь ожидает от единого каталога
Обычно сотруднику организации не нужно знать внутреннюю архитектуру информационных систем.
Например, ему нужно найти:
Иванов Иван Иванович
Начальник отдела закупок
Телефон: 1234
Email: ivanov@company.local
Кабинет: 301
Подразделение: Отдел закупок
Пользователь видит одну карточку.
При этом разные поля могли быть получены из разных источников.
Пример распределения данных
Источники могут быть распределены следующим образом:
| Данные | Источник |
|---|---|
| ФИО | кадровая система |
| Должность | кадровая система |
| Подразделение | кадровая система |
| Учётная запись | Active Directory |
| Внутренний телефон | АТС |
| Active Directory | |
| Кабинет | система помещений |
| Дополнительная информация | справочник |
Такой подход позволяет не создавать ещё одну систему, в которой вручную дублируются все данные организации.
Справочник как единая точка представления
В такой архитектуре внутренний каталог не обязательно должен становиться владельцем всех данных.
Его задача может заключаться в объединении информации.
Например:
Кадровая система
→ Иванов Иван Иванович
↓
АТС
→ 1234
↓
Active Directory
→ ivanov
↓
Система помещений
→ кабинет 301
↓
Единая карточка сотрудника
Пользователь получает результат без необходимости обращаться к каждой системе отдельно.
Почему нельзя просто объединить все таблицы
На первый взгляд задача может показаться простой.
Можно загрузить данные из всех источников в одну таблицу.
Однако достаточно быстро появляются проблемы.
Например, кадровая система идентифицирует сотрудника по табельному номеру, Active Directory — по логину, а АТС — по собственному идентификатору абонента.
Необходимо понять, что все эти записи относятся к одному человеку.
Сопоставление сотрудников
Для объединения данных используется механизм сопоставления.
Например:
| Источник | Идентификатор |
|---|---|
| Кадровая система | 10452 |
| Active Directory | ivanov |
| АТС | u-7821 |
| Система помещений | employee-10452 |
В справочнике эти идентификаторы могут быть связаны с одной внутренней записью сотрудника.
Почему ФИО недостаточно
Использовать ФИО в качестве основного ключа опасно.
В организации могут работать несколько сотрудников с одинаковыми именами.
Кроме того:
- фамилия может измениться;
- имя может быть указано по-разному;
- в разных системах могут использоваться разные форматы;
- могут встречаться опечатки.
Поэтому для автоматического сопоставления лучше использовать стабильные идентификаторы.
Единый внутренний идентификатор
У справочника может существовать собственный идентификатор сотрудника.
Например:
employee_id = 10452
К нему привязываются идентификаторы внешних систем.
Например:
employee_id: 10452
hr_id: 10452
ad_login: ivanov
phone_id: u-7821
room_id: employee-10452
Это позволяет независимо обновлять данные из разных источников.
Что происходит при изменении данных
Предположим, кадровая система изменила должность сотрудника.
Было:
Специалист
Стало:
Начальник отдела
При синхронизации изменяется только соответствующее поле.
Телефон из АТС и кабинет из системы помещений при этом не затрагиваются.
Независимое обновление источников
Разные системы могут обновляться с разной скоростью.
Например:
Кадровая система
→ каждый час
АТС
→ каждые 15 минут
Active Directory
→ каждые 30 минут
Система помещений
→ раз в сутки
Справочник объединяет последние успешно полученные значения.
Что делать, если один источник недоступен
Допустим, АТС временно недоступна.
Это не означает, что карточки сотрудников должны исчезнуть.
Справочник может сохранить последние корректные номера.
После восстановления связи выполняется очередная синхронизация.
Такой подход особенно важен для систем, работающих внутри корпоративной сети.
Последнее известное значение
Для каждого источника можно хранить дату последнего успешного обновления.
Например:
Телефон
Последняя синхронизация: 18.08.2026 10:15
Кабинет
Последняя синхронизация: 18.08.2026 00:30
Это помогает контролировать актуальность отдельных частей карточки.
Что делать при конфликте данных
Иногда разные системы могут содержать разные значения.
Например, в кадровой системе сотрудник относится к одному подразделению, а в Active Directory указана старая группа.
Необходимо заранее определить, какой источник имеет приоритет.
Если владельцем информации о подразделении является кадровая система, значение из неё должно считаться основным.
Матрица владельцев данных
Для каждого поля полезно определить систему-источник.
Например:
| Поле | Владелец |
|---|---|
| ФИО | кадровая система |
| Должность | кадровая система |
| Подразделение | кадровая система |
| Active Directory | |
| Телефон | АТС |
| Кабинет | система помещений |
Такая матрица помогает избежать конфликтов.
Какие данные можно редактировать вручную
Некоторые сведения могут отсутствовать во внешних системах.
Например:
- дополнительный комментарий;
- описание подразделения;
- фотография;
- дополнительный рабочий телефон;
- информация о расположении помещения.
Такие поля можно хранить непосредственно в справочнике.
При этом необходимо отличать их от данных, которые автоматически синхронизируются.
Что произойдёт с ручным изменением
Если поле является автоматическим, ручное изменение может быть перезаписано.
Например, пользователь изменил телефон сотрудника непосредственно в справочнике.
При следующем обмене АТС передала другое значение.
Автоматическая синхронизация заменит ручное изменение.
Поэтому интерфейс должен ясно показывать, какие данные управляются автоматически.
Автоматические и локальные данные
Условно карточку можно разделить на две части.
Данные из внешних систем
- ФИО;
- должность;
- подразделение;
- телефон;
- email;
- учётная запись.
Данные справочника
- описание;
- дополнительные контакты;
- сведения о помещении;
- внутренние заметки;
- другие локальные атрибуты.
Такое разделение упрощает сопровождение системы.
Что делать при удалении записи в источнике
Удаление сотрудника из одной системы не всегда означает, что его необходимо немедленно удалить из каталога.
Например, кадровая система может архивировать сотрудника.
Active Directory при этом уже отключила его учётную запись.
Справочник может перевести карточку в архив, сохранив историческую информацию.
Архивные сотрудники
Для архивных записей можно использовать отдельный статус.
Например:
Активный
Сотрудник отображается в обычном поиске.
Архивный
Сотрудник доступен только при специальных условиях.
Такой подход позволяет сохранить историю организации без загромождения основного каталога.
Подразделения также должны объединяться
Несколько источников могут содержать информацию не только о сотрудниках, но и об организационной структуре.
Например:
Кадровая система
→ подразделения
Справочник
→ структура каталога
Здесь также необходимо использовать стабильные идентификаторы.
Что делать при переименовании подразделения
Если подразделение получило новое название, не следует создавать новый объект.
Например:
Отдел снабжения
становится:
Отдел закупок
Если идентификатор остался прежним, справочник изменяет название существующего подразделения.
Связи с сотрудниками при этом сохраняются.
Несколько источников для одного объекта
Иногда один объект может иметь сведения сразу из нескольких систем.
Например, сотрудник может получать:
Кадровая система
→ должность
АТС
→ телефон
Active Directory
Система помещений
→ кабинет
Справочник объединяет эти данные в одну карточку.
Интеграция не обязательно должна быть двусторонней
Для внутреннего каталога часто достаточно одностороннего обмена.
Например:
Кадровая система
→
Оргнавигатор
Справочник получает данные, но не изменяет кадровую систему.
Такой вариант проще контролировать и безопаснее с точки зрения разграничения ответственности.
Когда может понадобиться обратный обмен
В некоторых сценариях организация может захотеть передавать изменения обратно.
Например, ответственное лицо изменило кабинет сотрудника в справочнике.
Эти данные могут быть переданы в систему помещений.
Но двусторонний обмен значительно усложняет архитектуру.
Необходимо заранее определить владельца каждого поля и правила разрешения конфликтов.
Контроль качества данных
При объединении нескольких источников особенно важна проверка качества.
Можно контролировать:
- дубли сотрудников;
- отсутствующие идентификаторы;
- неизвестные подразделения;
- несколько владельцев одного номера;
- неактуальные записи;
- конфликтующие значения.
Такие проверки позволяют обнаруживать проблемы ещё до того, как они становятся заметны пользователям.
Отчёты по качеству данных
Полезно периодически формировать отчёты.
Например:
Сотрудники без телефона: 38
Сотрудники без email: 12
Сотрудники без подразделения: 4
Дубли идентификаторов: 2
Неизвестные подразделения: 3
Такие отчёты помогают ответственным сотрудникам исправлять исходные данные.
Где выполнять объединение данных
Существует несколько подходов.
Непосредственно в справочнике
Справочник сам подключается к корпоративным системам и выполняет синхронизацию.
Это относительно простой вариант для небольшого количества источников.
Через промежуточный слой
Данные сначала поступают в интеграционный сервис.
Он выполняет:
- получение данных;
- преобразование;
- сопоставление;
- проверку;
- передачу в каталог.
Такой подход удобнее при большом количестве источников.
Что выбрать для организации
Конкретная архитектура зависит от инфраструктуры.
Если источников немного, прямые интеграции могут быть достаточными.
Если используются десятки систем, отдельный интеграционный слой может значительно упростить управление обменом.
Главное — заранее определить владельцев данных и правила сопоставления.
Локальное развёртывание
Для организаций с закрытой внутренней сетью интеграции могут выполняться внутри собственного контура.
Например:
Кадровая система
→ внутренняя сеть
→ Оргнавигатор
→ внутренний пользователь
При таком сценарии не требуется передавать корпоративные данные во внешние облачные сервисы.
Безопасность интеграций
Каждое подключение к внешней системе должно иметь минимально необходимые права.
Если справочнику требуется только чтение данных из кадровой системы, нет необходимости предоставлять ему права на изменение кадровых записей.
То же относится к АТС, Active Directory и другим источникам.
Единый каталог не означает единую базу
Важно различать эти понятия.
Единый каталог — это единая точка доступа пользователя к информации.
При этом исходные данные могут продолжать находиться в разных системах.
Это позволяет сохранить существующую корпоративную инфраструктуру и одновременно сделать информацию удобной для сотрудников.
Оргнавигатор как единая точка доступа
Оргнавигатор может объединять сведения о сотрудниках, подразделениях и помещениях из разных источников.
Кадровая система остаётся источником кадровой информации, АТС — телефонных номеров, Active Directory — учётных записей.
Пользователь при этом получает единый интерфейс поиска и просмотра организационной структуры.
Итог
В крупной организации невозможно ожидать, что вся информация о сотрудниках будет находиться в одной системе.
Гораздо практичнее определить владельцев данных и объединить информацию на уровне внутреннего каталога.
При этом ключевыми элементами становятся стабильные идентификаторы, матрица владельцев данных, правила синхронизации и контроль качества.
В результате сотруднику не нужно знать, где именно хранится нужная информация.
Он просто открывает единый каталог и получает актуальную карточку коллеги.