Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Тренинг Владимира Репина «Business Studio 5: моделирование, анализ и регламентация бизнес-процессов»
Опрос

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

Библиотека

19.01.2011 14:25
  от автора
  Андрей Аболенцев

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

Оценки за материал: 5.00 (4)

Ролевой метод является хорошо зарекомендовавшим себя на практике методом в процессном подходе. Понятие роли естественным образом возникает при описании бизнес-процесса, определяет субъекта, его функции, права и ответственность. Практическое применение ролевого подхода в настоящее время недостаточно освещено, и данным материалом авторы стремятся восполнить этот пробел, представляя свой опыт использования ролей как инструмента для разделения функций сотрудников (согласно регламентам бизнес-процессов) и организационной структуры банка.
Андрей Аболенцев, Валентин Зонов, Сергей Игошин
Бизнес-инжиниринг Инвестиционного Банка "ВЕСТА" (Москва)

Введение

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

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

Слово роль происходит от фр. 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. Роли, отражающие названия коллегиальных органов, помещаются в отдельную папку «Комитеты».


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

    Выводы

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

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

    Оценки: 1/1
    19.01.2011 15:02
      от автора
      Репин
    Спасибо коллегам за интересную статью!

    Очень заманчиво использовать механизм ролей для описания и регламентации бизнес-процессов. Но есть несколько вопросов.
    Например, такой. Допустим, во Front-office выполняется одновременно несколько бизнес-процессов, в которых участвует роль "Операционист". Но физически загрузка в этих процессах такова, что работу выполняют разные сотрудники. Т.е. в одном процессе роль "Операциониста" играет Экономист, а в другом Ведущий экономист. Как быть в этом случае? Вводить роли "Операционист процесса 1" и "Операционист процесса 2"? ОК?! А если таких процессов 50? Сделаем матрицу соответствия... А если Ведущий ушел в отпуск? Как переназначать операции процессов? Все-таки традиционные подходы, когда для операции указывается конкретный исполнитель на должности и лица, его замещающие, имеет много "плюсов".

    В общем, предлагаю обсудить "подводные камни" такого масштабного использования механизма ролей в системе бизнес-моделирования.
    Оценки: 1/
    19.01.2011 18:38
      от автора
      yamoleev_rafik
    Владимир,

    Может всё-таки (в общем случае):
    1. между регламентами и ролями осуществлена связь "многие-ко-многим", а не так, как на схеме?
    2. между ролями и должностными инструкциями присутствуют инструкции операционные (рабочие, технологические)?
    В самом кромешном случае можно попробовать хоть каждый день "под приказ" распределять роли (из группы ролей)за сотрудниками подразделения, при условии, что группа ролей закреплена за подразделением.

    Подводные камни пока не видны. Подумать надо, присмотреться
    Оценки: /
    20.01.2011 01:05
      от автора
      Александр Чередниченко

    Допустим, во Front-office выполняется одновременно несколько бизнес-процессов, в которых участвует роль "Операционист". Но физически загрузка в этих процессах такова, что работу выполняют разные сотрудники. Т.е. в одном процессе роль "Операциониста" играет Экономист, а в другом Ведущий экономист. Как быть в этом случае? Вводить роли "Операционист процесса 1" и "Операционист процесса 2"? ОК?! А если таких процессов 50?

    1. Если физически загрузка в этих процессах такова, что работу выполняют разные сотрудники, то речь должна идти об операционном менеджменте, поскольку слово "физически" подразумевает уровень экземпляров процессов. А на этом уровне речь уже о моделировании не идет.
    2. Что Вы имеете ввиду под "в другом процессе"? Если речь идет про другой экземпляр того же процесса, то это вопрос операционного менеджмента. Если речь идет про разные процессы, к примеру кредитование и работа с пластиковыми картами, то вполне может быть, что роли будут называться по-разному. И в чем конкретно проблема, что ролей может быть 50? Наоборот, роли в данном случае решают много проблем. Простой пример - у банка может быть целый ряд типовых структур (филиал тип 1, филиал тип 2, филиал тип 3 и т.д. - в разных зависимостях, но в основном от количества человек и набора допустимых операций). Если есть процесс "Идентификация клиента", то он как правило абсолютно одинаковый что для отделения из 2-х человек, что для областного филиала. И роль там может быть одна - Менеджер. Но эта роль привязывается к разным должностям в разных типовых структурах. Т.е. - на уровне областного филиала у Операциониста может быть вообще одна роль - Менеджер (к примеру, понимаем что ролей несколько больше), а на уровне маленького отделения эта роль вообще может быть привязана к начальнику отделения. На маленьком отделении у начальника еще много может быть интересных ролей - и охранник, и кассир, и уборщик


    А если Ведущий ушел в отпуск? Как переназначать операции процессов?

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


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

    Приведу пример одного из таких "плюсов". Берем небольшое отделение банка. Простой процесс Идентификация клиента, который может выполнять и начальник отделения, и его зам, и два менеджера. Вопрос - кого мы покажем исполнителем функции - всех четверых, они выполняют функцию альтернативно. А если крупное отделение, где 50 человек могут провести процесс идентификации? 50 исполнителей привязывать к одной функции? Или 50 вариантов процесса? Или как?
    Оценки: /
    20.01.2011 03:56
      от автора
      yamoleev_rafik
    Алексей,
    Идентификация клиента - это сравнение того, что в паспорте, с тем, что перед глазами?
    Оценки: /
    20.01.2011 03:57
      от автора
      yamoleev_rafik
    Прошу, прощения, Александр,
    Идентификация клиента - это сравнение того, что в паспорте, с тем, что перед глазами?
    Оценки: /
    20.01.2011 09:36
      от автора
      Репин
    Привет, коллеги!
    1) А кто-то пробовал в должностной инструкции сотрудника писать такие фразы, типа "Исполняет роль менеджера" в "Процессе обслуживания клиента"?
    Что скажет на это юридический отдел? Что скажет судья, в случае конфликтных ситуаций? Должностные обязанности - это юридическая вещь. А что такое обязанности по бизнес-роли? Роль можно наказать материально или отдать под суд? Как вам удалось в банке обойти эти проблемы?
    Я не против ролей и их использования. Скорее, наоборот. Сами их используем. Но все-таки интересно узнать, как вы обходите эти проблемы.
    2) Если у Начальника отдела одного филиала - 5 ролей, а у другого - 10, то это означает, что бизнес развивается стихийно, плохо управляется. В нормальной ситуации должны быть определены типы филиалов разного размера под разные задачи (город, поселок и т.п.). Для каждого типового филиала должна быть четкая структура, свои процессы и четко распределенные операция процессов (функции) по сотрудникам.
    3) Пример. Есть описание процесса в котором есть роль "Менеджер". Если в филиале Начальник должен еще (за тоже время) исполнять роли охранники и т.п., то он, быстрее всего, не сможет (не успеет физически) выполнять процесс в роли "Менеджер" по требуемой процедуре. Это означает, что процессы должны быть разные в зависимости от ресурсов, которые на них выделены.
    Оценки: /
    20.01.2011 11:27
      от автора
      Дмитрий Пинаев
    >>1) А кто-то пробовал в должностной инструкции сотрудника писать такие фразы, типа "Исполняет роль менеджера" в "Процессе обслуживания клиента"?

    А зачем это вообще писать? Можно просто показать весь функционал сотрудника, собранный из ролей.
    Роль в данном случае может быть просто внутренним механизмом для моделировщика, который он не показывает наружу. (Аналогично кстати модель БП являетя механизмом для получания ДИ, но сотрудник про модель может и не знать )
    Но если нужно, можно побить этот функционал на группы, соответствующие ролям.
    Оценки: /
    20.01.2011 12:24
      от автора
      Репин
    Коллеги, убедили
    Тему ролей надо развивать и применять в случае, если используется среда моделирования, такая как Business Studio...
    Оценки: /
    20.01.2011 12:52
      от автора
      Александр Чередниченко
    Общее замечание по комментариям - это только у меня они идут как попало, не последовательно и не по датам?


    1) А кто-то пробовал в должностной инструкции сотрудника писать такие фразы, типа "Исполняет роль менеджера" в "Процессе обслуживания клиента"?
    Что скажет на это юридический отдел? Что скажет судья, в случае конфликтных ситуаций? Должностные обязанности - это юридическая вещь. А что такое обязанности по бизнес-роли? Роль можно наказать материально или отдать под суд? Как вам удалось в банке обойти эти проблемы?

    На этот вопрос ответил Дмитрий Пинаев, добавить мало что необходимо. Роли как правило в ДИ не попадают.


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

    Если филиалы одного размера, то да - - 5 ролей, а у другого - 10, это есть не хорошо. Но, речь шла как раз о размерности филиалов, как частный случай это может быть разделение по принципу город/поселок.


    Пример. Есть описание процесса в котором есть роль "Менеджер". Если в филиале Начальник должен еще (за тоже время) исполнять роли охранники и т.п., то он, быстрее всего, не сможет (не успеет физически) выполнять процесс в роли "Менеджер" по требуемой процедуре. Это означает, что процессы должны быть разные в зависимости от ресурсов, которые на них выделены.

    Опять таки, это вопрос операционного менеджмента, а не бизнес-модели. Может быть два абсолютно одинаковых филиал (по структуре, по процессам), но загрузка у людей разная, т.к. один филиал - открыт в удачном месте и наплыв клиентов большой, а другой - в неудачном. Вы можете сами понаблюдать по любому банку - кто выносит утром табличку с курсами валют В большом филиале - охранник после "воздействия" ОПЕРу (так, к примеру), а в маленьком - начальник Т.е. если делать процесс "Установить курсы валют", то набор должностей будет очень интересный


    Идентификация клиента - это сравнение того, что в паспорте, с тем, что перед глазами?

    Одна из функций процесса, безусловно. У разных банков и в разных странах по разному - зависит от внутренних процедур, законодательства, автоматизации и т.п.
    Оценки: /
    20.01.2011 14:02
      от автора
      Андрей Аболенцев
    Уважаемые коллеги, спасибо за критику.

    С некоторыми проблемами, которые обсуждаются в комментариях, мы также столкнулись на практике и на текущий момент по ним выработаны или вырабатываются решения.

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

    Оценки: /
    20.01.2011 20:42
      от автора
      Sergwizard
    Уважаемые коллеги, мы очень рады, что наша статья вызвала столь обширную полемику!
    Приятно, что есть такое место в рунете, где можно обсудить вопросы, связанные с бизнес-процесами. Отдельные слова благодарности хотели бы выразить Владимиру Репину. Именно на его книгах мы постигали азы непростого искусства моделирования, оптимизации и регламентации бизнес-процессов.
    Как уже сказал мой коллега, мы планируем цикл статей, посвященный практике применения процессного подхода в коммерческом Банке.

    С уважением, Сергей Игошин.
    Оценки: 1/
    21.01.2011 09:46
      от автора
      myy.finexpert
    К сожалению, для российских банков вопрос уже так даже и не стоИт - использовать или не использовать понятие роли при разработке ВНД. Обязательность de facto стандарта по информационной безопасности СТО БР ИББС-1.0-2010, где явно предписывается определение ролей (как минимум в области обеспечения ИБ), делает тему статьи весьма актуальной. Между тем Центральный банк планирует в самое ближайшее время дополнить свой комплекс стандартов ИБ еще и отдельными рекомендациями по определению ролей. Авторам статьи также можно рекомендовать ознакомиться с ГОСТ Р ИСО/ТС 22600-2-2009 Приложение А, где рассматриваются понятия структурных и функциональных ролей. Этот документ сейчас доступен для ознакомления на сайте Росстандарта http://protect.gost.ru.
    Оценки: /
    21.01.2011 10:13
      от автора
      Репин
    Коллеги, а почему бы не выложить СТО БР ИББС-1.0-2010 (в нужной части)и ГОСТ Р ИСО/ТС 22600-2-2009 Приложение А на FineXpert.ru? Можно будет прямо из статьи сделать ссылки на эти документы.
    Если есть, присылайте или разместите сами (при размещении лучше в закладку "Стандарты").
    Оценки: /
    21.01.2011 11:45
      от автора
      myy.finexpert
    СТО БР ИББС-1.0-2010
    http://www.cbr.ru/credit/Gubzi_docs/st-10-10.pdf

    ГОСТ Р ИСО/ТС 22600-2-2009 Приложение А
    http://protect.gost.ru/v.aspx?control=8&baseC=6&page=0&month=12&year=2010&search=ГОСТ Р ИСО/ТС 22600-2-2009&RegNum=1&DocOnPageCount=15&id=168258&pageK=14F1D76B-3114-4F7A-A2FC-AC1271558E27
    Оценки: /
    21.01.2011 11:58
      от автора
      myy.finexpert

    Для возможности использования лучше так:
    ГОСТ Р ИСО/ТС 22600-2-2009 Приложение А

    лист 1
    http://protect.gost.ru/image.ashx?page=14F1D76B-3114-4F7A-A2FC-AC1271558E27

    лист 2
    http://protect.gost.ru/image.ashx?page=DF049BAC-825D-4475-BDF7-4A294A2357C0

    лист 3
    http://protect.gost.ru/image.ashx?page=E1DA6E3D-B46B-4C08-B445-7AD9142A94A1

    лист 4
    http://protect.gost.ru/image.ashx?page=8CF83976-EAFB-4662-93A6-E5424FF84DB6

    ГОСТ Р ИСО/ТС 22600-2-2009 Приложение Б

    Лист 1
    http://protect.gost.ru/image.ashx?page=39CC4606-0F6F-4710-A921-527CB6A97C28

    Лист 2
    http://protect.gost.ru/image.ashx?page=BB7658C4-C3CE-4EC6-A56F-CF8AC652E609
    Оценки: 1/
    22.01.2011 20:00
      от автора
      Елиферов Виталий
    Добрый день, коллеги!
    1. Возможность использования ролей среди русскоязычных инструментов моделирования есть не только у Business Studio. Такой функционал есть по крайней мере у ARIS и Casewise.
    2. То что роли необходимы для нормального описания БП и тиражирования их экземпляров никто не спорит, но вот проблем юридического характера в части назначения сотрудников на смежные роли при временном отсутствии какого-либо специалиста, - я не вижу.
    а) Наверное, многие из вас писали в Должностных инструкциях "на время отсутствия руководителя исполняет его обязанности" или "В случае отсутствия данного сотрудника замещает .... /место для подписи/ (вариант: выпуск Приказа о замещении);
    б) Для четкого использования ролевого механизма нужно четко формулировать роли. Лично мне пример роли "охранник", приведенный в статье не нравится. Данное название описывает не функцию (охраняет вход, ведет фэйс-контроль и т.д.), а скорее должность. Все же должность "охранник" пишется в трудовой книжке.
    в) В примере диаграммы, имеет место аналогичное смешение ролей и должностей: "Казначей" и "Сотрудник, оформляющий документы по сделке". Например, в одной крупной российской компании, при использовании Business Studio в соглашении по моделированию для Swime Lane диаграмм стоит жесткое ограничение на использование ролей только в написании "Ответственный за ....", кроме должностей "Главбух", "Ген.директор".
    С уважением Виталий.
    Оценки: /
    22.01.2011 20:57
      от автора
      Репин
    Ого! Какие люди!
    Привет, Виталий!
    Спасибо, что зашел на "Финэксперт.ру"!
    Оценки: /
    24.01.2011 01:33
      от автора
      key
    Интересно, а с какой целью разрабатывалась модель ?
    Какие проблемы с ее помощью предполагалось решить ?
    Оценки: /
    24.01.2011 17:12
      от автора
      Дмитрий Пинаев
    >>1. Возможность использования ролей среди русскоязычных инструментов моделирования есть не только у Business Studio. Такой функционал
    есть по крайней мере у ARIS и Casewise.
    Виталий, подскажите как это увидеть в ARIS?
    В Business Studio роли позволяют агрегировать должности в одну сущность и оперировать дальше только ей. Позволяет ли такое ARIS?
    Оценки: 1/
    25.01.2011 15:15
      от автора
      o_stuv
    Хочу отметить отличный пример: "Если у Начальника отдела одного филиала - 5 ролей, а у другого - 10, то ...".
    Использование ролей дает немало преимуществ при регламентации с помощью моделей. Но это ничто в сравнении с теми преимуществами которые дает использование ролей при регламентации работы филиалов. Вместо множества организационных структур и положений о подразделениях (в Сызрани водители у АХО, а в Нижневартовске на подряде, в Новосибирске главный бухгалтер и три операциониста, а в Сыкрывкаре глав-бух и зам, и пр) мы имеем ОДНУ ЕДИНСТВЕННУЮ структуру ролей, которую спускаем по все филиалы и просим директора (или кого-то кто на это уполномочен) закрепить эту структуру за своей орг-структурой, требований к которой у нас (о боже!) нет! Кроме того - все требования к этому распределению прямо указаны в описании ролей. Кроме того - все изменения в штатной численности прямо и просто обосновываются изменениями численных показателей функций объединенных в некоторые роли. Управление организационными структурами филиалов становится прозрачным и простым. И все благодаря именно использованию единой ролевой структуры.
    Оценки: 1/
    25.01.2011 17:59
      от автора
      Репин
    Вопрос такой. Как в этом случае определять показатели эффективности процессов и KPI сотрудников? Нельзя будет рассчитать показатели эффективности, единые для всех филиалов.
    Например, у Вас в одном филиале процесс выполняет дворник, в другом - операционист. В данном примере - у дворника и операциониста разная зарплата - разная стоимость человеко-часа - будет разная эффективность процессов. Т.е. сопоставимость филиалов по показателям эффективности процессов обеспечить будет невозможно. Как в таком случае управлять?
    Оценки: 1/
    25.01.2011 22:07
      от автора
      Елиферов Виталий

    Дмитрий Пинаев
    >>1. Возможность использования ролей среди русскоязычных инструментов моделирования есть не только у Business Studio. Такой функционал
    есть по крайней мере у ARIS и Casewise.
    Виталий, подскажите как это увидеть в ARIS?
    В Business Studio роли позволяют агрегировать должности в одну сущность и оперировать дальше только ей. Позволяет ли такое ARIS?

    1. ARIS - имеет полную локализацию на русском языке.
    См. http://www.avaxhome.ws/ebooks/modelirovanie_biznesa_aris_ebook.html
    Громов, Каменнова, Шматалюк "Моделирование бизнеса. Методология ARIS" Глава 8.10, стр. 229
    2. Не понял вопроса: С какой целью нужно "агрегировать должности в одну сущность"?
    3. Стандарт СТО БР ИББС 1.0-2010 для проверки ИББС не используется. Для этого применяется СТО БР ИББС 1.2-2010 "Методика оценки соответствия информационной безопасности организаций банковской системы". Так что требования к описанию ролей и метаролей пока обязательными не являются.
    С уважением Виталий.

    Оценки: /
    26.01.2011 10:36
      от автора
      o_stuv

    >> Репин
    Вопрос такой. Как в этом случае определять показатели эффективности процессов и KPI сотрудников? Нельзя будет рассчитать показатели эффективности, единые для всех филиалов.
    Например, у Вас в одном филиале процесс выполняет дворник, в другом - операционист. В данном примере - у дворника и операциониста разная зарплата - разная стоимость человеко-часа - будет разная эффективность процессов. Т.е. сопоставимость филиалов по показателям эффективности процессов обеспечить будет невозможно. Как в таком случае управлять?

    Никаких проблем со сравнительной аналитикой как раз быть не может. Просто ВСЕ сравнения и оценки производятся в привязке именно к ролям. Все, и KPI и требования к компетентности - все крепится к ролям или к ролям через функции. К должности крепится только роль, и именно эта связка интересна только для единственной цели - внутри филиала распределить роли за должностями. Таким образом мы можем посмотреть показатель уборки территории даже не задумываясь кто именно его реализует. Таким образом достигается еще и полная идентичность набора показателей филиала (зависящая только от полноты набора исполняемых в филиале функций).
    Оценки: /
    26.01.2011 12:19
      от автора
      Репин
    Отличная идея! Остается только сотруднику вживить в голову чип, которые содержит описания ролей. А при смене ролей, просто менять это чип

    А как быть, если требования к ролям не совместимы в одном физическом сотруднике? Или совмещение этих требований приведет к тому, что такого сотрудника невозможно будет найти на рынке труда? А как быть с опытом и навыками выполнения работы человеком?
    Да, роли в модели поменяем, но живой человек не сможет соответствовать всем требованиям.
    Оценки: /
    26.01.2011 13:07
      от автора
      o_stuv
    "Кроме того - все требования к этому распределению прямо указаны в описании ролей. ". Зачем закреплять не совместимые роли? Распределение ролей за должностями - довольно интеллектуальный процесс. Хорошо что все требования к нему определены в единственной форме. Но никто не говорит что мы можем их не учитывать.
    И по поводу чипа: к роли кроме требований к компетентности вполне может иметься учебник, или программа обучения. Тогда при смене ролей может просто активироваться известная программа или выдаваться известный учебник и проводиться известные тесты. Кроме того у персоны может (а в идеале и должна!) иметься описание компетентностей этой персоны, или история обучения, и тогда при закреплении роли к какой-то должности, может приниматься во внимание обучение которое проходила эта персона ранее. Сотрудник, например, может быть раньше занимал должность исполняющую какую-то роль, затем ситуация изменилась, и теперь он (его должность) рассматривается на предмет прикрепления к той же роли - в таком случае ранее пройденное обучение является аргументом "за".
    Такой подход при моем непосредственном участии успешно применялся, именно в тесном переплетении с системой обучения, в холдинге управляющем сетью ресторанов (за структуру ролей изначально была принята организационная структура самого большого из пятидесяти ресторанов, а затем она под разные потребности эволюционировала, к каждой роли прикреплялся учебник и группа тестов которые активизировались при перераспределении ролей по должностям). А так же в мясоперерабатывающем холдинге имеющем более десяти торговых домов в регионах (в этом примере меньшую роль играла связка с системой обучения, зато активнейшим образом структура ролей была связана с системой объемных показателей, из которых рассчитывались коэффициенты занятости каждой роли, и отсюда определялись требования и рекомендации к численности штата каждого торгового дома).
    С уважением, Валентин Зонов.
    Оценки: /
    26.01.2011 15:47
      от автора
      Репин
    Спасибо, Валентин!

    Имея такой большой опыт в ресторанном бизнесе и мясопереработке, м.б. Вам написать статью по управлению бизнес-процессами в этой сфере?
    Банк - банком, а ресторанный бизнес - это совершенно другие процессы.

    Кстати, похоже что комментарии выходят уже далеко за рамки статьи. М.б. обсудить тему ролей на форуме сайта?
    Оценки: 1/
    26.01.2011 15:51
      от автора
      Елиферов Виталий

    Репин
    ...как быть, если требования к ролям не совместимы в одном физическом сотруднике? Или совмещение этих требований приведет к тому, что такого сотрудника невозможно будет найти на рынке труда? А как быть с опытом и навыками выполнения работы человеком?
    Да, роли в модели поменяем, но живой человек не сможет соответствовать всем требованиям.

    Значит придется искать 2 или 3 человека для выполнения данной работы. Это только на словах распорядитель ресурсов легко решает:"Пусть они после работы еще и полы помоют!"
    В этом случае ролевая модель дает распорядителю ресурсов обоснование необходимости увеличения штата. В Домодедове в зоне прилета рамки стоят, но постовых я там ни разу не видел, - сократили или отправили "мыть полы".
    С уважением Виталий.
    Оценки: /
    26.01.2011 19:52
      от автора
      myy.finexpert

    Елиферов Виталий
    3. Стандарт СТО БР ИББС 1.0-2010 для проверки ИББС не используется. Для этого применяется СТО БР ИББС 1.2-2010 "Методика оценки соответствия информационной безопасности организаций банковской системы". Так что требования к описанию ролей и метаролей пока обязательными не являются.



    Автор - оптимист. Открываем упомянутое им
    СТО БР ИББС 1.2-2010 и сразу попадаем в царство ролей.

    Первый групповой показатель оценки
    M1 “Обеспечение информационной безопасности при назначении и распределении ролей и обеспечении доверия к персоналу”

    Частные показатели (обязательные)
    М1.1 Определены ли в документах организации роли ее работников?
    М1.2 Формируются ли роли, связанные с выполнением деятельности по обеспечению ИБ, на основании требований разделов 7 и 8 стандарта СТО БР ИББС-1.0?
    М1.3 Персонифицированы ли роли в организации с установлением ответственности за их выполнение?
    М1.4 Зафиксирована ли документально в должностных инструкциях ответственность за выполнение ролей?

    И ниже контроль определения ролей присутствует в каждом групповом показателе. В точном соответствии с требованиями стандарта.
    Оценки: /
    26.01.2011 23:03
      от автора
      Елиферов Виталий

    myy.finexpert
    Автор - оптимист. Открываем упомянутое им
    СТО БР ИББС 1.2-2010 и сразу попадаем в царство ролей.

    Уточняю: Елиферов - хорошо информированный оптимист = пессимист.
    Повторяю еще раз:
    1. Самооценка ИББС ведется по стандарту СТО БР ИББС 1.2
    2. Стандарты СТО БР ИББС 1.0, 1.1 и 1.2 - на сегодняшний день (26.01.2011) не являются обязательными для БС России. Соответственно не являются обязательными требования по описанию ролей и метаролей.
    3. На портале ЦБ РФ с незапамятных времен висит самооценка 2-х банков по ИББС 1.2-2004 (проект).
    http://www.cbr.ru/credit/Gubzi_docs/main.asp?Prtid=Res
    С уважением Виталий.
    Оценки: /
    27.01.2011 20:17
      от автора
      myy.finexpert


    Елиферов Виталий
    2. Стандарты СТО БР ИББС 1.0, 1.1 и 1.2 - на сегодняшний день (26.01.2011) не являются обязательными для БС России. Соответственно не являются обязательными требования по описанию ролей и метаролей.


    В результате интриги вокруг исполнения требований 152-ФЗ "О персональных данных" банки сейчас массово принимают СТО БР ИББС в качесве обязательного для себя стандарта. Детали здесь не интересны, интересен результат - обязательность использования банками ролевого подхода при структурированию обязанностей и полномочий сотрудников в локальных нормативных документах.

    Более того. На обсуждении экспертов ПК3 ТК362 находится проект документа РС БР ИББС 2.5-2011 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Выделение и назначение ролей". Срок завершения обсуждения - апрель.

    Роли нам рекомендованы в обязательном порядке..
    Оценки: /
    28.01.2011 09:49
      от автора
      Елиферов Виталий

    myy.finexpert
    Роли нам рекомендованы в обязательном порядке..

    Мне нравится эта форма "обязательной рекомендации"
    Оценки: /
    16.02.2011 10:17
      от автора
      Дмитрий Пинаев
    Елиферов Виталий
    2. Не понял вопроса: С какой целью нужно "агрегировать должности в одну сущность"?

    Именно для создания Роли. Собственно статья посвящена имено этому.
    Насколько я знаю, в ARIS должность - уже роль, в нее можно включить конкретных сотрудников. Но на практике это неудобно. Гораздо удобнее подход Роль
    Оценки: /
    16.02.2011 10:20
      от автора
      Дмитрий Пинаев
    Замечательно...куда делся текст?
    продолжаем:
    Гораздо удобнее подход Роль
    Оценки: /
    16.02.2011 10:21
      от автора
      Дмитрий Пинаев
    Ага, видно часть текста система восприняла как тег...
    Гораздо удобнее подход Роль - Должности- Сотрудники. Аналитик на этапе моделироавния системы не работает с конкретными ФИО, ему удобнее работать со связкой Роль - Должности.

    Добавить комментарий

    Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
    ©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

    Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

    Регистрация
    О Портале
    Правила
    Контакты
    Новости
    Библиотека
    Энциклопедия
    Литература и сайты
    Группы
    Мои страницы
    Тесты
    Форум
    Доска объявлений