Feedback: Дополнение к статье о внешних системах документооборота (часть 2)

Short intro: here you can find second part of customer’s feedback on article related to using external request approval system which was published 16.02.2016 (and first part of feedback – 12.03.2016) with my comments…

Продолжаем обсуждать плюсы и минусы использования внешней системы документооборота заявок на согласование доступа при внедрении OIM. Здесь я бы хотел опубликовать вторую часть мнения заказчика, на этот раз о недостатках использования встроенной в OIM системы заявок на доступ (первая - в недостатках внешней системы документооборота, вторая - о недостатках внутренней - нет в этом мире совершенства). Исходная статья "Внешние системы документооборота заявок и OIM: за и против", первая часть мнения заказчика – "Feedback: Дополнение к статье о внешнихсистемах документооборота". 

P.s. хочется поблагодарить автора за интересный материал, который, уверен, может привести к интересным дискуссиям...

Disclaimer: Я сам не полностью согласен с некоторыми из пунктов, поэтому добавил развернутые комментарии (выделены курсивом), но, в целом, материал мне кажется заслуживающим внимания, особенно тех, кто только проектирует архитектуру IDM решения на продуктах как Oracle, так и любых других.

Итак о недостатках OIM в качестве системы-источника заявок на права доступа и системы согласования этих заявок:

1. Первым относительным недостатком можно считать то, что использование OIM в этом качестве возможно только при наличии в организации "иерархии согласования" и других четко формализованных правил. Только тогда можно построить более-менее работающий workflow согласования заявок на Роли доступа. Автоматически работающий и не требующий "ручного привода". В противном случае поддержка работы такого полуавтоматизированного согласования будет камнем висеть на шее администратора или другого выделенного сотрудника. Нет в OIM средств поддержания неформализованных или частично формализованных процессов.

Любая более-менее развитая система ДО имеет для поддержания таких процессов согласования гораздо больше средств, в том числе и для поддержания неформализованных или не полностью формализованных процессов согласования.

А для OIM, если правила согласования не формализованы или неоткуда взять информацию о согласующих,- придётся их придумывать и согласовывать именно такой подход со всеми заинтересованными подразделениями (с безопасностью, с делопроизводителями, с юристами и т.д.) прежде, чем реализовать.

>> Абсолютно согласен, процессы согласования необходимо формализовать до того момента, как они будут автоматизированы. Но не является ли это необходимым пререквизитом для любого проекта внедрения IDM?

2. Часто формализация правил согласования заявок на Роли доступа становится настоящей проблемой и единственным выходом оказывается - назначить "ответственных". Не совсем уж плохой выход для всех, кроме самих ответственных :). Вот, кстати, об ответственных (не важно каких, "назначенных" или вычисленных на основании правил или иерархии согласований).

Представьте себе, что какой-либо "Ответственный" уволился или ушёл в декрет (ну или группа ответственных оказалась пуста после реорганизации и перевода в холдинг). Что произойдёт с процессами согласования? Правильно, они "встанут". Причём именно тогда, когда на соответствующий этап согласования попадёт какая-либо заявка.

В лучшем случае (если внедренец OIM об этом позаботился), такая ситуация станет известна администратору OIM каким-либо уведомлением или попадёт в какой-либо отчёт. В этом случае пользователь, заказавший себе Роль, потеряет немного больше времени, ровно на столько, сколько потребуется администратору на то, чтобы найти замену выбышему ответственному. В худшем случае - пока сам не забеспокоится и не начнёт трясти всех с вопросом "Где заказанная мною Роль?".

А ведь такую ситуацию, можно было просчитать заранее и она бы не привела к потерям времени пользователя: вся информация у OIM есть - и об уволившихся, и о составе групп. Что мешало поставить администратора OIM в известность не тогда, когда заявка на Роль "встала", а тогда, когда была заблокирована УЗ и произошёл отзыв прав доступа у уволившегося ответственного, в том числе его исключение из "Группы согласующих..." ?

Отсутствие в OIM самоконтроля на "целостность" процессов. Это существенный недостаток именно системы и его придётся компенсировать собственными силами, что-то придумывать, дописывать и потом поддерживать / переделывать при всех дальнейших Upgrade-ах.

>> Да, в большинстве случаев OIM владеет информацией об отпусках и прочем (степень доверия к этой информации зависит от бизнес процессов внутри заказчика), ее можно и нужно использовать при делегировании и эскалации задач согласования. Напомню, что стандартная делегация происходит через механизм совместителей (в один момент времени может быть только один заместитель, что не всегда удобно) или же через BPEL процессы, где имеется широкий инструментарий на эту тему. Вопрос «почему OIM это не делает автоматически» относится к риторическим – OIM предоставляет все необходимые средства, чтобы это было реализовано, нужно об этом лишь позаботиться на этапе внедрения.

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

Отсутствие продуманных, удобных механизмов работы с множественными УЗ пользователя (для заказа новой УЗ, для заказа Ролей для УЗ, ...), с моей т.зрения ставит под вопрос объективность того самого квадрата Гартнера, т.к. это есть у многих систем "не лидеров".

>> В текущей версии OIM 11gR2PS3 имеется возможность выбора учетной записи, для которой запрашивается привилегия. В случае запроса бизнес роли учетная запись (как и привилегии, которые соответствуют этой бизнес роли) не показываются пользователю. Что имхо правильно.

4. Аналогично предыдущему недостатку можно упомянуть ещё следующий, хоть он к документообороту относится только косвенно: в OIM нет возможности учитывать различные формы сотрудничества пользователя и организации. Поясню, что я имею в виду: самое простое - один и тот же человек работает как штатный сотрудник в одном подразделении и принимается на работу как совместитель в другое подразделение.

Как "заказать" ему новую УЗ для совместителя (если такие правила в организации)? Как заказать ему дополнительные роли/права в качестве совместителя? Как сделать так, чтобы при увольнении его потом с должности совместителя, отзывались только те права доступа и блокировались только те УЗ, которые относятся именно к его форме сотрудничества  "совместитель" и не заблокировалась его Identity (глобальная УЗ пользователя в OIM) ?

В OIM не получится настроить документооборот для таких случаев, хотя я примерно себе представляю как сделать это в ВСДО (>> Внешняя система документооборота, которая обсуждалась здесь и здесь)  и даже автоматизировать с использованием API OIM при наличии глубокой интеграции. А вот средствами самого OIM такое не реализовать без риска сделать невозможным дальнейший Upgrade системы.

К сожалению, объектная модель (Entity-Relations), на которой построен OIM, довольно примитивна и не учитывает множества реалий, что приводит к большим ограничениям в вариантах её использования.

>> Проблема с совместителями действительно имеется, но она лежит большей частью  в области бизнес процессов компании, нежели в применяемом для их автоматизации продукте. Лучшей практикой по моему личному опыту является формирование отдельных учетных записей (включая доменные) для каждого отдельного организационного назначения пользователя (по сути для каждого табельного номера), этот подход не требует никаких доработок со стороны OIM.  

Любопытно, что указана примитивность модели OIM, тогда как большей частью мне приходится сталкиваться с жалобами на ее чрезмерную сложность и "навороченность".

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

+ Чехарда с используемыми системами для управления Ролями (сначала OIM, потом OIA, сейчас снова OIM) и постоянное переписывание GUI делают OIM малопривлекательным с точки зрения использования в качестве системы ДО (>> Документооборота). Всякие новые "красивости" не компенсируют наличие ошибок, тормоза и необходимость переучивания рядовых пользователей, которых всё это путает и пугает.

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

>> С замечанием про OIA согласен, действительно, в какой-то момент одна и та же функция могла быть выполнена в разных продуктах (а OIA – это технически другой продукт, пришедший с поглощением Sun Microsystems), что добавляло путаницы. Но текущее направление развития продукта – совмещение всех бизнес процессов под одним интерфейсом. Однако, этот интерфейс в определенных ситуациях действительно может отображаться медленно (в частности, мы столкнулись недавно с проблемой производительности на IE9 на тонком клиенте).

Причины медленной работы UI кроются в разном – от неоптимального наполнения данными (например, вынос в каталог 12 миллионов сущностей, которые пользователь никогда не должен запрашивать, проблема, с которой мы столкнулись в одном из заказчиков) до неадекватного соотношения нагрузка / железо. В крупных проектах, когда конечные пользователи работают с системой, создают заявки на доступ и их согласуют, необходимо проводить нагрузочное тестирование. Наши тесты, проводимые при помощи Oracle Application Testing Suite в одно из заказчиков показали приемлемую производительность (отклик в пределе 3х секунд) при одновременной работе до 400 пользователей (выше мы не тестировали,Ю а под одновременной работой считается выполнение пользователями типовых операций с логином в течении 30 секунд с небольшим случайным разбросом). Железо, на котором проводилось тестирование – конфиденциальная информация, которую я тут разместить, к сожалению, не могу.