Наличие функционала «связывания» в виде списка правил существенно ускоряет процесс сопоставления нужного сотрудника с его учётной записью в той или иной целевой системе.

Суть механизма достаточно проста. Есть два списка. Один список - это список сотрудников, которые система вытянула из одного или нескольких кадровых источников. Второй - список учётных записей, которые 1IDM получила из управляемой системы. Они независимы, автономны и скучны.

Каждый из элементов этих списков обладает набором признаков, на которые правила связывания опираются при сопоставлении одного элемента списка с элементом другого списка. Волшебство (=успех) случается, когда правило, при сравнении двух элементов, распознает соответствие и фиксирует обнаруженную учётную запись за конкретным сотрудником. После того как это произошло, система связывания «теряет интерес» к элементу из списка учётных записей и продолжает работать с теми, кто еще не обрел своего собственника. Всё потому, что сотрудник всегда один, а учётных записей у него может быть много.

Приведем достаточно простой пример. В нашем списке сотрудников есть Иванов Иван Иванович (все персонажи в статье вымышлены, все совпадения случайны), а в другом списке есть учётная запись, один или несколько признаков которой явно указывают на связь с сотрудником. Это может быть ФИО, табельный номер, электронная почта в атрибутах учётной записи. Важно понимать, что если правило для одной учётной записи нашло несколько сотрудников, то фиксации не произойдет.

Однако, несмотря на возможности гибкой настройки правил за счет внутреннего языка программирования, на практике редко удается достичь гарантированной 100% связанности. Всегда есть работа для ручного связывания. Важно вовремя понять, когда процесс создания правил становится дороже ручного связывания. Если вы вручную, прямым указанием сотрудника, способны 10 учётных записей связать за 2 минуты, то стоит ли тратить даже 2 минут времени на придумывание правила, которое сможет соединить те же 10 учётных записей? Вопрос риторический.

Связано 20% учётных записей – очень плохо

Связано 40% учётных записей – плохо

Связано 60% учётных записей – неплохо Связано 80% учётных записей – восхитительно

Связано 90% учётных записей - как говорится, хорошую историю не грех и приукрасить, да?

Объективно говоря, состояние, в котором находятся атрибуты учётных записей, - это свершившийся факт, который мы должны с вами принять. Мы не можем это изменить, если у нас нет машины времени. Администраторы могли ошибаться в написании фамилии, указывать е вместо ё, не переименовывать атрибуты при смене фамилии сотрудника – перечислять можно долго. Но всё это влияет на время, качество и процент связывания.

Также существуют разные типы учётных записей, например, сервисные или технологические, в которые, как правило, никто не закладывает признаки ответственного. Это тоже добавляет работы для ручного связывания.

Но есть не только негативные варианты, встречаются и ситуации, когда для однозначного отождествления с конкретным сотрудником добавляется уникальный идентификатор сотрудника, по которому одним правилом можно достичь высокой скорости и процента связывания.

Исходя из вышеизложенного, чтобы улучшать качество связывания, специалистам 1IDM приходится тренироваться в написании правил, изучать опыт коллег, совершенствовать методы вычисления связей. Тем не менее, процесс ручного связывания избежать не удается, в том или ином случае, он будет. Даже в сложных ситуациях, дополнительный фактор, который помогает улучшить показатели связывания в боевой системе – это соответствие данных продуктивной среды и подготовительной, где правила связывания заранее формируются и проверяются. В некоторых случаях удается начать процедуру подготовки связывания задолго до развертывания продуктивного сервера, когда для управляемой системы задействуются администраторы, которые указывают признаки в тех учётных записях, которые в ходе работ в подготовительной среде были выявлены для ручного связывания.

По итогу неважно, как долго или сложно происходил сам процесс связывания. Важно то, что связывание будет завершено, а проблема с некачественными атрибутами учётных записей будет исправлена. Как это будет осуществляться, поговорим в одной из следующих статей.