Роли в бизнес процессе пример

ИН – получает информацию о ходе и результатах подпроцесса.

Количество подпроцессов не должно превышать 7± 2.

Таблица 5 – Матрица ответственности сотрудников за выполнение бизнес-процесса

Управление бизнес-процессом (обязательно указывается наименование)

1. Подпроцесс (указать название подпроцесса)

Если руководитель лично выполняет какую-либо деятельность (кроме контроля) по выполнению подпроцесса, то в соответствующей строке указывается «УЧ». Если владелец бизнес-процесса осуществляет только контроль выполнения подпроцесса, то указывается «ИН».

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

а) доведение до всех участников бизнес-процесса информации о требованиях клиентов и нормативных документов;

б) установление целевых показателей для бизнес-процесса и соответствие этих целевых показателей с целями организации;

в) регулярный анализ хода бизнес-процесса и своевременная разработка корректирующих и предупреждающих негативные тенденции действий;

г) обеспечение всех необходимых ресурсов для выполнения работ в рамках бизнес-процесса.

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

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

Таблица 6 – Показатели качества для контроля и управления бизнес-процессом

Показатели качества выходов бизнес-процесса

Показатели качества входов бизнес-процесса

Показатели удовлетворенности клиентов

Технология управления бизнес-процессом

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

Таблица 7 – План управления бизнес-процессом

Наименование работы (задачи, задания, функции)

Владелец бизнес-процесса осуществляет контроль показателей бизнес-процесса (параметры из таблицы 6) путём сравнения полученных фактических значений показателей с плановыми значениями.

Владелец бизнес-процесса осуществляет мониторинг удовлетворенности клиента путем сравнения полученных фактических значений показателей со значениями показателей за предыдущий период.

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

Моделирование бизнес – процессов

SADT является техникой для анализа систем как множества взаимосвязанных активностей или функций. Эту технологию целесообразно использовать на ранних этапах жизненного цикла системы для понимания сущности функций и взаимосвязей в системе.

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

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

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

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

Над активностью представленной на контекстной SADT диаграмме (рисунок 1) может быть проведена декомпозиция, т.е. быть разложена на составляющие активности, которые в свою очередь также могут быть представлены в виде составляющих активностей.

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

Разработка структурно-функциональной модели объекта автоматизации

Следует различать две модели бизнес-процесса. Модель «как есть», демонстрирует ситуацию до автоматизации. В этом случае рассматривается соответствующее состояние в предметной области. Для графического документирования бизнес – процессов рекомендуется применение SADT –технологии.

Таблица 8 содержит описание подпроцессов бизнес-процесса для формализованного описания бизнес-процесса, представленного в виде SADT диаграммы.

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

Рисунок 1 — SADT-диаграмма 0-уровня, демонстрирующая функциональный (активностный) блок и интерфейсные дуги (связи)

Таблица 8 – Шаблон формы табличного описания подпроцессов бизнес-процесса (на основе технологии SADT)

Наименование операции (активности, деятельности)

(документы, данные, материалы и др.)

(документы, данные, материалы и др.)

(ответственный за операцию, механизм реализации)

При каких условиях начинается

Чем регламентируется и завершается

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

Источник: studfile.net

Примеры использования бизнес-роли

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

Пример 1. Согласование документа с использованием Бизнес-роли «Согласование».

Рассмотрим простой маршрут согласования заявки на закупку товара для нужд предприятия (рис. 1). Такая заявка может согласовываться с непосредственным руководителем инициатора заявки, экономистами, ответственным за закупку. Список согласующих лиц может меняться в зависимости от вида товара и его стоимости.

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

Рис. 1. Пример процесса с использования бизнес-роли «Согласование»

Задача «Отправка на согласование» размещается в статической или динамической зоне ответственности. Когда такая задача поступает пользователю в веб-приложении, он выбирает, кому отправить документ на согласование и определяет тип согласования (последовательное или параллельное) (рис. 2).

Рис. 2. Пример формы задачи «Отправка на согласование» в веб-приложении

Подробнее о задаче «Отправка на согласование» можно узнать в справке по модулю ECM+ — Руководство для внедрения — Маршруты документов — Операции документооборота — Отправка на согласование .

Задача «Согласование» размещается в зоне ответственности Бизнес-роль, тип бизнес-роли «Согласование». Несмотря на то, что на графической модели процесса присутствует только один элемент «Согласование», в рамках экземпляра процесса формируется столько задач, сколько пользователей указано в задаче «Отправка на согласование». При этом каждый из этих пользователь может увидеть в области Лист согласования статус согласования документа (рис. 3).

Рис. 3. Пример формы задачи «Согласование» в веб-приложении

Подробнее о задаче «Отправка на согласование» можно узнать в справке по модулю ECM+ — Руководство для внедрения — Маршруты документов — Операции документооборота — Согласование .

Пример 2. Исполнение задач по резолюции с использованием Бизнес-роли «Рассмотрение».

Рассмотрим простой маршрут обработки входящего договора подряда (рис. 4). Исполнение такого договора может потребовать привлечения различных специалистов предприятия. Список исполнителей может меняться в зависимости от предмета договора. Такой договор требует рассмотрения ответственного руководителя и распределения задач между исполнителями.

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

Рис. 4. Пример процесса с использования бизнес-роли «Рассмотрение»

Операция «Формирование задач по резолюции» может быть вынесена отдельно или активирована настройкой в рамках операции «Вынесение резолюции». Подробнее о задачах «Вынесение резолюции» и «Формирование задач» по резолюции можно узнать в справке по модулю ECM+ — Руководство для внедрения — Маршруты документов – раздел Операции документооборота .

В примере для наглядности задача «Формирование задач по резолюции» вынесена отдельным элементом. Задача «Формирование задач по резолюции» размещается в статической или динамической зоне ответственности. Когда такая задача поступает пользователю в веб-приложении, он выбирает, кому и какие задачи назначить (рис. 5).

Рис. 5. Пример формы задачи «Формирование задач по резолюции» в веб-приложении

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

Подробнее о задаче » Исполнение и контроль задач по резолюции» можно узнать в справке по модулю ECM+ — Руководство для внедрения — Маршруты документов — Операции документооборота — Исполнение и контроль задач по резолюции .

Источник: www.elma-bpm.ru

Матрица ролей и прав: техника BABOK®Guide для описания CRUD-операций при разработке ТЗ

В рамках обучения начинающих системных и бизнес-аналитиков сегодня разберем еще одну технику BABOK®Guide и ее практическое использование в разработке ТЗ и описании программных систем. Что такое матрица ролей и прав, чем она отличается от RACI-таблицы, при чем здесь CRUD-операции с данными и в каком разделе технического задания на разработку информационной системы ее размещать.

Знай свои права: что такое матрица ролей и прав, и чем она отличается от RACI-таблицы: комментарии BABOK®Guide

Матрица ответственности, которую мы разбирали здесь, вместе с другими техниками BABOK®Guide для анализа стейкхолдеров, – это отличный инструмент документирования характера вовлечения организационной единицы в бизнес-процесс. RACI – это англоязычный акроним от основных видов участия в процессе:

• Исполнитель (Responsible, R)– тот, кто выполняет задачу;
• Ответственный (Accountable, A)– тот, кто отвечает за ее выполнение задачи, выделяя ресурсы и принимая управленческие решения, т.е. владелец бизнес-процесса. Должен быть только 1 во всей RACI-таблице.
• Консультирующий (Consulted, C)– стейкхолдер со специальными знаниями или опытом, необходимыми для решения задачи, например, эксперт предметной области;
• Информируемый (Informed, I)– тот, кто должен быть в курсе о ходе и результате выполнения задачи.

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

Например, нужна интеграция имеющейся на предприятии системы электронного документооборота с внешним порталом для получения исходных данных и выгрузки отчетов. Для этого Заказчик обратился в ИТ-компанию по разработке ПО. Клиентский менеджер принял заявку и завел карточку клиента в CRM-системе, а менеджер проекта привлек аналитика и ведущего разработчика, чтобы они оценили реализуемость, а также стоимость и сроки выполнения работ. В этом кейсе аналитик будет совмещать обязанности системного и бизнес-аналитика, работая как в области проблем, так и в области решений.

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

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

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

Такая таблица, которая показывает, какими правами обладает конкретная роль на отдельные виды данных, называется матрица ролей и прав (или разрешений). Профессиональное руководство к своду знаний по бизнес-анализу BABOK®Guide упоминает эту технику как наглядный и понятный способ определение ролей с привязкой к действиям. При этом BABOK отмечает, что на высоком уровне абстракции роли и их ответственность чаще определяются в виде RACI-матрицы, а на более детальном, в частности, на уровне информационных систем и работы с конкретными артефактами – в виде таблицы CRUD-операций. Что это такое и как она используется аналитиками при разработке ТЗ и описании программных систем, мы поговорим далее.

Как использовать таблицу CRUD-операций в разработке ТЗ и описании ПО

Прежде всего разберемся с термином CRUD. Это англоязычный акроним от основных операций с данными:

Именно эти основные операции поддерживаются в любой СУБД и прикладных информационных системах. Поэтому, разрабатывая ТЗ и специфицируя требования к ПО, аналитик использует CRUD-таблицу, чтобы показать, какие операции с данными может выполнять та или иная роль. Например, в рассматриваемом кейсе матрица ролей и прав (Roles and Permissions Matrix в англоязычном оригинале BABOK) будет выглядеть так:

Также на практике встречается расширенный вариант CRUD-таблицы, где еще добавлена операция просмотра всего списка данных того или иного типа. Она обозначается английской буквой L – List, т.е. показать листинг (список). Если добавить ее к нашей таблице, можно показать, какая роль имеет право просматривать, например, перечень созданных задач или документ по проекту. Причем здесь идет речь именно о листинге как каталога файлов в директории, без просмотра их внутреннего содержания – за это отвечает операция Read.

Наличие такой таблицы пригодится при разработке и внедрении ПО при определении пользовательских прав и настройке политик управления пользователями. Таблица CRUD-операций нужна не только разработчикам, но и администраторам системы, т.к. она поддерживает принципы RBAC-модели избирательного управления доступом (Role Based Access Control).

При разработке технического задания по российским ГОСТам 34.602-89 и 19.201-78 ее можно внести в пункты, описывающие требования к системе. А если шаблоном для разработки ТЗ являются международный стандарт спецификации требований ISO IEEE 29148-2018 (2011), детальную таблицу CRUDL-операций для пользовательских ролей и разных видов данных можно вынести в приложение, где описываются модели процессов и предметной области. На более высоком уровне абстракции можно поместить матрицу ролей и прав в раздел «Общее описание», где определены классы и характеристики пользователей. Однако, в этом случае по смыслу она будет ближе к RACI-матрице, затрагивая скорее организационную, а не техническую часть.

Источник: babok-school.ru