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

Во-первых, руководитель в контексте IDM-системы - достаточно яркий «игрок». В его задачи, в зависимости от правил конкретного бизнеса, может входить сверка и актуализация списка сотрудников, аттестация доступов, управление запросами на доступ, делегирование полномочий и другие действия, которые, порой, выходят за рамки привычных задач.

Во-вторых, в отличии от специалистов по информационной безопасности или ответственных за ресурсы (они же владельцы), руководителей значительно больше. Их вовлеченность в процесс управления доступом, даже на поверхностном уровне, заметно снижает «шумовую» активность, освобождая тем самым ресурс специалистов по ИБ.

В-третьих, руководители бывают разными, как и способы их учёта в 1IDM.

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

«Exceptio probat regulam in casibus non exceptis»

Разбирать, в таком случае, нечего. Эти обязанности берёт на себя другая роль или роли.

Начнем с простого и привычного. Большинство воспринимает руководителя как официального лидера определенной группы лиц, связанных общей целью (ой, ну что за грустные вздохи, я должен был это написать). Точнее всего характер подчиненности подобных руководителей описывает организационно-штатная структура, где в каждом родительском узле иерархического дерева может быть указан руководитель, определенный для дочерних узлов. Организационно-штатная структура также позволяет определять и уровни руководителей.

С точки зрения 1IDM, это ожидаемый, функциональный и понятный способ учёта руководителей. В самом распространенном случае руководители попадают в учет из кадрового источника в процессе обмена информацией с целевой системой. Но возможен и ручной способ ведения, где в качестве выбора руководителя можно выбрать как конкретного сотрудника, так и должность, из которой будет вычислен нужный руководитель (в момент ключевых операций).

Казалось бы, ничего лучше не придумать. Расходимся! Но в этот момент появляется руководитель, который никак не вписывается в концепцию предыдущего рассмотренного варианта. Он назначается непосредственно для конкретного сотрудника или группы сотрудников. Мы называем его функциональным руководителем (например, это может быть тимлид). На схеме он выглядит так.

Причем, как несложно понять из примера, он может существовать параллельно с линейным руководителем из организационно-штатной структуры. Более того, в разных ключевых операциях 1IDM может присутствовать логика назначения как одного, так и другого руководителя (в том числе и одновременного).

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

Дополнительные реквизиты позволяют вносить вспомогательную информацию по следующим ключевым объектам 1IDM:

Компания

Сотрудник

ОШС (Подразделение или должность)

Учётная запись

       

Право

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

Перейдем в настройки 1IDM и на одноименной вкладке добавим новый реквизит «Функциональный руководитель». При этом в качестве типа значения у нас есть множественный выбор, но, предположим, что нам будет удобно выбирать нужного руководителя из списка сотрудников. На этой же форме можно предусмотреть и дополнительные реакции на смену руководителя или его добавление.