Почему так тяжело проектам ВРМ в России?

Человек плохо поддается математическим вычислениям — например, трудно просто определить, справа или слева он будет обходить лужу. Что уж говорить о том, как он поведет себя в ходе выполнения бизнес-процесса, да еще если будет там не один. Однако пускать на самотек распределение исполнителей не стоит.

Марина Аншина

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

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

Ролевая модель

В бизнес-информатике получила широкое распространение процессно-ролевая модель Г. Раммлера и А. Брэйча [1], предложивших изображать на диаграмме процесса дорожки, группирующие пользователей по функциям, которые те должны выполнить. Дорожкам дается имя (синоним — роль), позволяющее однозначно идентифицировать соответствующую категорию исполнителей, выполняющих назначенные им функции.

Не следует смешивать роль с функцией или группой исполнителей. Функция — это работа, которую обязуется выполнить субъект, а роль — это круг участников, которым она может быть поручена. Группа есть совокупность работников, объединенных общим признаком, — например, обладающих соответствующей квалификацией или входящих в конкретное подразделение. Поскольку группирующее свойство присуще самому субъекту, состав группы изменится при изменении субъекта или штатного состава. Роль так же можно рассматривать как группировку, где в качестве критерия отбора выступает исполняемая участниками функция. До тех пор, пока состав функций процесса не изменяется, номенклатура ролей остается неизменной.

Одна роль может объединять ряд сотрудников и много операций, а один сотрудник может быть участником нескольких ролей, при этом управление ролями и распределение участников в общем случае оказывается нетривиальной задачей. Будем разделять простую роль, которой соответствует одна функция, и составную — включающую несколько функций. Если использовать только простые роли, их количество становится равным числу операций процесса, администрирование усложняется. А если применять составные роли, возникает неоднозначность описания прав доступа, нельзя определить права к каждой операции в отдельности.

Интегрированная модель бизнес-процессов

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

Игорь Федоров

Можно представить составную роль в форме иерархии, где на нижнем уровне находятся простые роли, а на верхних — составные [2]. Участники нижнего уровня могут выполнить только свою функцию, а верхних — все нижележащие. Иерархия может строиться, во-первых, снизу вверх, путем синтеза сложных ролей из простых: например, сотрудник офиса продаж принимает заказ клиента и выдает результат — таким образом, роль «операционист» объединяет обе функции. Во-вторых, метод декомпозиции позволяет построить иерархию ролей сверху вниз. Например, операция «проверить сведения о заемщике» может включать две функции: «уточнить адрес проживания» и «проверить место работы». При синтезе критерий консолидации функций в одну роль отражает текущий способ распределения работ в компании, и, если он изменится, ролевую модель придется корректировать. Декомпозиция отражает функциональное разбиение работ, не привязанное к конкретной организационной структуре компании, выполняющей эти действия, это как бы «абсолютный» взгляд на то, из каких компонентов и операций состоят процессы компании. Можно образовать роли участников в соответствии с построенным деревом функций, и такая ролевая модель окажется инвариантна изменениям его организационной структуры.

Способы формирования ролей

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

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

Рис.1. Изменение ролевой модели вследствие изменения распределения работ
Рис.1. Изменение ролевой модели вследствие изменения распределения работ

 

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

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

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

Роль как логический слой модели процесса

Роль следует рассматривать как логический слой модели процесса: она не должна быть связана с должностью — например, руководитель и его подчиненный могут иметь право выполнить одну и ту же операцию. Роль не должна быть привязана к структурному подразделению — например, исполнить работу могут члены рабочей группы, числящиеся в разных отделах. Она не должна зависеть от территориального расположения исполнителя — например, инициировать процесс может как сотрудник территориального подразделения, так и работник центрального офиса. Роль не связана с квалификацией или иными свойствами субъекта — одну и ту же работу можно поручить сотрудникам с разным опытом.

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

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

Имя роли

Имя роли можно образовать от соответствующей ей функции, последняя обозначает работу и передается глаголом [3]. Имя роли есть название группы людей, которые выполняют эту работу, его можно образовать как отглагольное существительное или прилагательное: например, функция — «контролировать заявку», а роль — «контролер» или «контролирующий».

Однако для составной роли этот прием подходит не всегда. В некоторых случаях можно выделить главную функцию, дающую имя всей роли, и вспомогательные функции, которые в имени не используются. Например, роль «приемщик» включает две функции: принять и выдать заказы. В других ситуациях имя может перечислять функции исполнителя — например, приемщик-оценщик. Хорошо, когда имя роли отражает суть выполняемых действий, но иногда простое и короткое имя подобрать не удается и тогда можно использовать отвлеченное имя. Нужно следить, чтобы имена ролей не повторялись, в сложных проектах это может создать путаницу.

Операционные и организационные роли

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

Параметрические роли

Если обычная роль не позволяет учесть все необходимые характеристики исполнителей, применяются параметрические роли, позволяющие визуально отобразить логику выбора исполнителя в соответствии с некоторым критерием. Расщепим роль на подроли, принадлежность к которым связывается с каким-либо квалифицирующим свойством, выступающим в качестве параметра, допустимые значения последнего перечислены в некотором справочнике. Например, роль «разработчик» можно разделить на подроли в зависимости от знания сотрудником различных сред программирования — поручая задание, можно выбрать разработчика нужной квалификации.

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

Разделение и связывание обязанностей

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

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

  • статическое разделение — один пользователь не может одновременно участвовать в ролях, которые содержат взаимоисключающие функции (хотя способ обладает наглядностью и явно виден на модели, реальные ситуации требуют более сложных сценариев);
  • разделение по историческому аспекту — определяет право исполнить операцию в зависимости от того, принимал ли пользователь уже участие в этом задании;
  • простое динамическое разделение — пользователь может участвовать в нескольких ролях, которые содержат взаимоисключающие функции, но в рамках исполнения одного экземпляра процесса он может быть авторизован только в одной из них;
  • разделение на основе доступа к данным — определяет возможность исполнить операцию процесса в зависимости от прав доступа к объекту данных процесса.

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

Разделение и связывание обязанностей не могут быть отражены в ролевой модели. Иногда, чтобы смоделировать исторический аспект разделения, вводят специальную псевдороль «инициатор». Однако эта роль имеет ограниченные возможности применения, не позволяя смоделировать разделение, зависящее от данных.

Разграничение прав доступа участников к объектам системы

Каким образом ролевая модель позволяет разграничить права доступа участников бизнес-процесса к объектам системы? В ИТ ролью принято называть сотрудников, обладающих одинаковыми разрешениями для работы с объектами системы. В исполняемой модели в качестве объекта принято рассматривать операции бизнес-процесса. Таким образом, дорожка на схеме процесса санкционирует доступ к операциям, а не к данным (рис. 2). Принадлежность к роли определяет разрешение выполнить операцию, но не устанавливает права доступа к самому объекту. По аналогии, разрешение записи в некоторый файл позволяет редактировать данные, но не определяет, каким образом может быть изменен этот файл.

Место роли в модели бизнес-процесса
Рис. 2. Процессно-ролевая модель

 

Можно говорить, что субъект играет роль, роль имеет разрешение выполнить операцию, а операция определяет метод работы с объектом данных. При этом один субъект может иметь несколько ролей, а роль — включать множество субъектов; роль может иметь несколько разрешений, открывая доступ к разным операциям, а одно разрешение может принадлежать многим ролям; операция может изменять множество объектов данных, а объект  может быть изменен разными операциями. Таким образом, роль определяет права доступа к операциям, но не к данным процесса. Как следствие, пользователю невозможно делегировать права на какой-то определенный информационный объект. Для ориентации в этом множестве связей «многие ко многим» в BPMS предлагаются различные модели разграничения доступа.

Управление доступом на основе ролей (Role Based Access Control, RBAC) имеет статус национального стандарта [4]; аналогичные требования содержатся в рекомендациях Банка России [5]. Плоская модель (RBAC0) соответствует ранее рассмотренной процессно-ролевой модели. Иерархия ролей (RBAC1) определяет наследование функций и их объединения в роли. Статическое разделение обязанностей (RBAC2) подразумевает выделение взаимоисключающих функций и распределение пользователей по ролям на этапе моделирования процесса. Динамическое разделение обязанностей (RBAC3) подразумевает уточнение состава участников ролей непосредственно в ходе исполнения. Перед стартом каждой операции происходит авторизация пользователя в назначенные ему роли. При этом проверяются бизнес-правила, и если пользователь уже был авторизован в одной взаимоисключающей роли, то авторизация в другой ему будет запрещена. Кроме того, используется понятие мощности роли, определяющее максимальное количество лиц, которые могут быть авторизованы в роли в рамках одной сессии.

Модель RBAC широко используется в процессных системах. Роли находятся в иерархической связи, образуя дерево (рис. 3), а отображение пользователей на роли происходит либо статически, либо динамически, в последнем случае роли присваиваются только на соответствующую сессию.

Место роли в модели бизнес-процесса
Рис. 3. Модель RBAC

 

Модель RBAC учитывает разделение обязанностей, но игнорирует их объединение, не позволяет моделировать исторический аспект и назначение на основе доступа к общим данным. Модель не разделяет процедуры отбора и назначение исполнителей.

Для расширения возможностей RBAC и реализации динамического разделения обязанностей, используется пооперационная модель доступа (Task Based Authorization Control, TBAC), предполагающая, что для каждого шага процесса можно индивидуально определить правила отбора исполнителя. В этом случае распределение прав доступа становится динамическим и децентрализованным, а разрешения проверяются, активизируются и отменяются для каждой операции в отдельности. Это позволяет смоделировать различные политики выбора исполнителя, применяемые на предприятии.

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

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

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

***

Роль следует рассматривать как логический слой модели процесса, не привязанный к ее организационной структуре, что позволит обеспечить ее инвариантность к изменению штатного расписания. Для построения ролевой модели рекомендуется использовать иерархическую декомпозицию работ сверху вниз — полученное дерево ролей не будет зависеть от текущего способа распределения работ. Следует учитывать, что ролевая модель позволяет описать процесс отбора кандидатов, но не отображает процедуру назначения реального исполнителя. Аналитик должен учесть в модели процесса как операционные роли, выполняющие производственные задания, так и организационные роли, направленные на координацию работы исполнителей. Надо помнить, что роль определяет права доступа к операциям, но не к данным процесса и, как следствие, пользователю невозможно делегировать права на какой-то определенный информационный объект.

Игорь Федоров (IFedorov@mesi.ru) — профессор, Московский государственный университет экономики, статистики и информатики (МЭСИ).

Литература

  1. Rummler G., Brache A., Improving Performance: How to Manage the White Space in the Organization Chart. San Francisco: Jossey-Bass Publishers, 1995.
  2. Moffet J. Control Principles and Role Hierarchies // Proceedings of the 3rd ACM Workshop on Role Based Access Control (RBAC). 1998.
  3. Федоров И.Г. О терминологии процессного управления // Открытое образование. — 2013. — № 4.
  4. American National Standard Institute Inc., Role Based Access Control, ANSI INCITS 359-2004, 2004.
  5. Стандарт СТО БР ИББС-1.0-2008. Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Банк России, 2009.