Диссертация (1152223), страница 65
Текст из файла (страница 65)
Эту роль могут играть все сотрудникиофиса продаж, их руководитель и какие-то сотрудники центрального офиса. Если распределение работ изменится, то потребуется поменять привязку пользователей к ролям, но не саму модель процесса. Роли соответствует группировка по функциям, которая объединяет участников,обязанность которых включает исполнение данной операции.Имя ролиМы договорились различать простую роль, которой соответствует одна функция и составную роль, которая включает несколько функций. Имя простой роли легко образовать от соот-250ветствующей функции. Последняя обозначает работу и передаётся глаголом.
Имя роли естьназвание группы людей, которые выполняют эту работу, его можно образовать как отглагольное существительное или прилагательное. Например, функция называется контролировать заявку, а соответствующая роль — контроллер или контролирующий.К сожалению, этот приём вызывает затруднения, если роль составная. В некоторых случаях в составной роли можно выделить главную функцию, которая даёт имя всей роли, и вспомогательные функции, которые в имени не используются. Например, роль «приёмщик» включаетдве функции: принять и выдать заказы.
В других — имя может перечислять функции исполнителя, например, приёмщик-оценщик есть составная роль, включающая две функции принять иоценить.Хорошо, когда имя роли отражает суть выполняемых действий, но иногда простое и короткое имя подобрать не удаётся, можно использовать абстрактное имя.Операционные и организационные ролиМы договорились различать операционные и организационные обязанности участниковпроцесса [284]. Первые направлены непосредственно на производство товаров и услуг, они связаны с выполнением сотрудником его «производственных» функций.
Например, сотрудник:«принимает заказ» от клиента, «выдаёт ему заказ». Модель процесса фиксирует, в первую очередь, именно операционные обязанности участников. Вторые косвенно, опосредованно обеспечивают достижение основного результата процесса, они заключаются в согласовании и координации взаимодействия сотрудников. Они не связаны с исполнением операционного задания, номогут маршрутизировать его вверх, вниз и поперёк иерархии сотрудников компании.
Модельпроцесса часто опускает организационные функции, но без них исполнение процесса окажетсяневозможным.Следует предусмотреть в модели роли, выполняющие организационные функции, например, контроллер, администратор и владелец процесса. Контроллер может наблюдать показателиисполнения процесса, например, время исполнения или простоя, выработку каждого из участников и т.д. Администратор может вмешиваться в ход исполнения.
Например, может случиться,что сотрудник ошибётся при вводе и отправит неправильно заполненное задание следующемуучастнику. Если он вспомнит об ошибке, у него не будет права отозвать уже отправленное задание. Он сможет только обратиться к администратору с просьбой «вернуть» ему заданий.Наконец владелец — это пользователь, наделённый самыми широкими полномочиями, она может давать разрешения на выполнение действий администратору и контроллеру.251Особенности ролевой моделиРоль не позволяет учесть некоторые характеристики исполнителей. Например, исполнители, находящиеся в одной роли, могут работать в разных территориальных подразделениях.Если один из них инициировал выполнение задания, то логично предположить, что после обработки оно вернётся именно к инициатору.
Но ролевая модель не позволяет различить исполнителей в роли.Роль включает много сотрудников, все они рассматриваются как кандидаты на исполнения задания. Что бы определить актуального исполнителя следует провести процедуру назначения и при этом следует учесть ряд ограничений, накладываемых бизнесом, которые мы рассмотрим ниже.Принципы разделения и объединения обязанностейРазделение обязанностей [283] — это концепция, используемая для предотвращения мошеннических действий. Она первоначально сформировалась как наоборот правил ИТ безопасности, позднее она стала стандартом бизнеса, который широко используется, например, в банковской деятельности. Предполагается, что существуют такие сочетания работ, где один участник неможет выполнить сам несколько критически важных операций. Их исполнение должно быть распределено между несколькими пользователями.
Например, принцип четырёх глаз предполагает,что важную операцию и последующую проверку результата должны выполнять разные участники. Соответствующие функции называются взаимоисключающими. В теории принято выделятьпять стратегий разделения обязанностей [285], на практике их можно свести к трём.Статическое разделение предполагает, что один пользователь не может одновременноучаствовать в нескольких ролях, которые содержат взаимоисключающие функции. Хотя этотспособ обладает наглядностью (явно виден на модели), реальные ситуации требуют болеесложные сценариев.Разделение на основании исторического аспекта определяет право исполнить операцию взависимости от того, принимал (не принимал) ли пользователь уже участие в этом экземплярепроцесса.Простое динамическое разделение, предполагает, что пользователь может участвовать внескольких ролях, но в рамках одного экземпляра процесса он может участвовать только в одной из них.
Можно предположить, что это один из вариантов разделения на основе исторического аспекта.Пооперационное разделение предполагает, что пользователь может участвовать в не-скольких ролях, но не уполномочен выполнять сразу операции из разных ролей. Эта стратегияэквивалентна простому динамическому разделению.252Разделение на основании доступа к данным определяет возможность исполнить операциюпроцесса в зависимости от правд доступа к объекту данных процесса.
Разделяют две интерпретации. Во-первых, чтобы предотвратить конфликты доступа к взаимно-зависимым данным,можно сопоставить возможность исполнить операцию с правом изменять данные, которыеучаствуют в этой операции. Например, можно представить себе две параллельно исполняемыеоперации, которые одновременно имеют доступ к общему объекту данных. Во-вторых, можносвязать право выполнить операцию с историческим аспектом.В некоторых случаях используется альтернативная концепция связывания обязанностей[286], которая предполагает, что есть совокупность работ, которые должны быть выполненыодним исполнителем. Часто задание возвращается тому участнику, который уже с ним работал.Например, торговый представитель инициирует запрос, логично, что бы после обработки ответвернулся именно к нему.
Чаще всего, связывание сводится к историческому аспекту исполнения бизнес-процесса. Но можно предположить связывание на основе общих данных, например,заявки по определённому профилю обрабатывает выделенный сотрудник.Разделение и объединение обязанностей не могут быть отражены в ролевой модели.
Иногда, чтобы смоделировать исторический аспект, вводят специальную псевдороль инициатор.Последняя имеет ограниченные возможности применения, не позволяя смоделировать принципчетырёх глаз или разделение, зависящее от данных. Для проверки реализации обоих принциповчасто используется матрица распределения ответственности, в которой строки соответствуютоперациям процесса, столбцы — ролям исполнителей, а знак на пересечении означает правосоответствующей роли исполнить надлежащую функцию. К сожалению, на практике вместороли часто используются соответствующие ей функции [287], из-за этого чтение и анализ матрицы становится затруднительными.Авторизация доступа в процессно-ориентированных системахАвторизация есть процедура предоставления определённому лицу или группе лиц разрешения на доступ к объектам системы.
Базовыми понятиями авторизации доступа являются:субъект, объект, разрешение. Субъект определяется как интеллектуальный агент — участникпроцесса: человек или ИТ система. Объект есть то, к чему мы хотим определить доступ: процесс, файл, объект данных. Разрешение — это права доступа, субъекта к соответствующемуобъекту. Разрешения для субъектов, работающих с разными объектами можно описать с помощью матрицы доступа, в которой строки соответствуют объектам, столбцы — субъектам, а наих пересечении расположено соответствующее разрешение. Матрицу рассматривают как наборвектор-строк или вектор-столбцов. Первые называют списком контроля доступа, он определёндля каждого из объектов в отдельности и описывает разрешения для всех субъектов, работающих с этим объектом.
Вторые называют списком полномочий пользователя, он определён длякаждого из субъектов в отдельности и описывает разрешения при работе с каждым объектом.253Ролью в ИТ принято называть круг субъектов, обладающих одинаковыми разрешениямидля работы с одним или несколькими объектами системы, как показано на рисунке 4.22-А. Впроцессно-ролевой модели в качестве объекта принято рассматривать операции процесса.