• Бизнес-процессы
• ИСО
• Бюджетирование и финансы
• Стратегическое управление

• Управление проектами
• Информационные технологии
• Модели бизнес-процессов

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

Андрей Аболенцев,  Валентин Зонов, Сергей Игошин
Бизнес-инжиниринг Инвестиционного Банка "ВЕСТА" (Москва)

Введение

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

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

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

Слово роль происходит от фр. role – роль, список, свиток, из лат. rotulus – бумажный свиток (для актеров), далее из rota – колесо, из праиндоевропейского корня rot – катить (Источник – словарь М. Фасмера). Обратимся к семантике слова (заимствовано из www.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. Роли, отражающие названия коллегиальных органов, помещаются в отдельную папку «Комитеты».

Выводы

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

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