Практика использования ролей для моделирования бизнес-процессов коммерческого Банка

Введение

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

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

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

Семантика. Определение

Слово роль происходит от фр. role — роль, список, свиток, из лат. rotulus — бумажный свиток (для актеров), далее из rota — колесо, из праиндоевропейского корня rot — катить (Источник — словарь М. Фасмера). Обратимся к семантике слова (заимствовано из ru.wikitionary.org).

1. Перен. деятельность, образ действий, манера держать себя. — Как изменилася Татьяна! Как твердо в роль свою вошла. А. С. Пушкин;
2. Значение, род и степень участия в каком-либо деле, предприятии, событии. — Ленин правильно указал путь борьбы рабочего класса, определил его роль, как передовой революционной силы общества, определил роль крестьянства, как союзника рабочего класса. История ВКП(б) — Ему принадлежит большая роль в этом деле. — Блестящая роль в жизни;
3. Комп. набор функций для выполнения определённого круга задач, назначаемый серверу.

Практическое использование

Обратимся к практике бизнеса. Рассмотрим цепочку образования сущности «роль» в процессном подходе к моделированию бизнес-процессов.

Рис. 1. Схема образования сущности «Роль»

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

Примеры: администратор баз данных, казначей, юрист, куратор, владелец бизнес-процесса, инициатор.

Должность и роль. Связь. Различия

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

Главный специалист Правового Управления (должность) = Главный специалист (компонента, отражающая уровень принятия решений) + Сотрудник Правового Управления (компонента, определяющая тип бизнес-подразделения)

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

Роль (определенная из бизнес-процесса) связывается посредством приказа с должностью (элементом организационной структуры) — рисунок 2. Таким образом, любая роль имеет характерное на данный момент положение в структурном разрезе бизнеса (Сотрудник Правового Управления) и место в иерархии принятия решений (Главный специалист), обеспечивающее необходимые полномочия для выполнения функций в рамках конкретного бизнес-процесса.

Рис. 2. Ролевая схема бизнес-процесса. Связь с оргструктурой (диаграмма построена в системе бизнес-моделирования Business Studio)

Рассмотрим для примера следующую схему образования функционала для некоторого сотрудника Банка (рисунок 3):

Рис. 3. Регламенты, роли и должностная инструкция

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

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

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

Все это значительно упрощает проведение изменений.

Классификация ролей

Обратим внимание, что любая роль возникает при взаимодействии субъекта и другого субъекта либо субъекта и объекта. Мы будем использовать тип взаимодействия как критерий выделения и классификации ролей. Условимся называть такие роли как бизнес-роли и метароли соответственно. Метароли необходимо идентифицировать и описывать не только в рамках составления карты бизнес-процессов, но и при определении прав доступа к любой автоматизированной банковской системе (АБС). В частности, требования по определению и фиксации метаролей при работе с АБС диктуются стандартом информационной безопасности Банка России (СТО БР ИББС-2010). Для этого удобно использовать матрицы метаролей, которые дают подробную «развертку» организационной структуры с разбивкой на ролевую и структурную компоненты (рисунок 4).

Рис. 4. Матрица фиксации метаролей

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

Приведем практический пример:

Аксиоматика по названию ролей

А1. Название роли не может совпадать с элементом или совокупностью элементов организационной структуры. Исключения составляют роли Главного бухгалтера и Председателя Правления.

Пример: УИТ (Управление информационной безопасности) — не роль.

А2. Название роли должно отражать доминирующую функцию в процессе или уровень экспертизы предметной области участника бизнес-процесса.

Пример: регистратор, администратор баз данных.

А3. Название роли должно стремиться быть инвариантным относительно перемещений между элементами организационной структуры.

Пример: охранник.

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

Пример: регистратор приказов по персоналу, регистратор приказов по основной деятельности.

А5. Если 2 роли имеют что-то общее из набора уровней экспертизы предметной области, но относятся к разным бизнес-процессам, то название ролей полностью определяется набором необходимых компетенций.

А6. Название должно иметь следующую структуру: существительное + «хвост».

А7. Количество слов в названии роли не должно превышать 4 слов, не включая предлоги, союзы и междометия.

Пример: регистратор приказов по основной деятельности.

А8. В названии роли сокращению может подвергаться только «хвост».

Пример: администратор ИБ=администратор информационной безопасности.

А9. Исключениями из пунктов А5-А7 являются названия ролей, установившиеся и принятые в бизнес-среде.

Пример: системный администратор.

Аксиоматика по структурированию множества ролей

А1. Первоначальное множество ролей формируется в виде списка.

А2. Структура множества ролей переходит от списка к дереву по достижению критического количества бизнес-ролей в списке.

А3. Формирование дерева происходит по 3 уровневому принципу, то есть каждая роль относится к одной из следующих групп, определяемых в каждом бизнес-процессе: Front-office, midle office и back-office.

А4. Роли, отражающие названия коллегиальных органов, помещаются в отдельную папку «Комитеты».

Рис. 5. Пример дерева ролей (построено в системе бизнес-моделирования Business Studio)

Выводы

Плюсы ролевого подхода:

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

Январь 2011 г.

Рекомендуемые материалы по тематике

Деловая игра «Процессный пазл»

Как сделать незаменимой систему управления бизнес-процессами в банке

Фреймворк проекта оптимизации сквозного бизнес-процесса

Итоги конкурса «BPM-проект года 2017»