Методология моделирования бизнес-процессов (стр. 1 )

2.1        Обзор методологий        1

2.1.1        История        2

2.1.2        IDEF0, IDEF3        3

2.2        Методология моделирования бизнес-процессов ARIS        14

2.2.1        Организационная диаграмма        17

2.2.2        Диаграмма целей        19

2.2.3        Дерево функций        20

2.2.4        Диаграмма цепочек добавленного качества        22

2.2.5        eEPC событийная цепочка процесса        23

2.3        Применение процессного подхода на примере модели бизнес-процесса: "БЮДЖЕТИРОВАНИЕ"        36

Обзор методологий

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

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

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

Что же такое методология моделирования процессов? Это совокупность способов отражения объектов реального мира, и связей между ними, с помощью объектов модели.

Рисунок 1. Методология (способ) описания бизнес-процесса

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

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

Методику выполнения проекта мы рассмотрим на последующих занятиях, а сейчас дадим обзор наиболее популярных и эффективных методик моделирования бизнес-процессов, и более подробно остановимся на методике моделирования ARIS.

История

Ещё в начале 90-х годов в мире было распространено несколько десятков методологий описания бизнес-процессов. Многие из них возникли в 60-е - 70-е годы, когда ещё не существовало такого интереса к процессному управлению. Данные методологии возникли из потребности в изображении (рисовании) механизмов взаимодействия различных подразделений внутри компании или взаимодействия нескольких компаний в рамках общего проекта. Любой руководитель при разговоре с подчинёнными или в раздумьях с самим собой рисует кружочки, квадратики, а между ними чёрточки, стрелочки и т. п. Это естественно, т. к. часто человек легче воспринимает рисунок, нежели текст. Также естественно, что не все сразу понимают руководящие рисунки. Исходя из этого и появилась потребность в унификации правил изображения подобных кружочков и стрелочек, стали возникать упомянутые методологии, которые ещё иногда называют нотациями.

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

В ходе естественного отбора на рынке осталось 5-6 методологий, в явном виде пригодных для описания или, точнее, моделирования бизнес-процессов. Наиболее известные: IDEF0, DFD, UML, ARIS. Некоторые из поддерживающих их программных продуктов: BPWin, Rational Rose, ARIS Toolset. Все они уже получили широкое распространение в России, но, к сожалению, только у программистов или в наиболее грамотных компаниях. Но поскольку последних становится всё больше, то, соответственно, продолжается и экспансия методологий.

IDEF0, IDEF3

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Функциональная модель IDEF0 отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Методология IDEF может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем IDEF может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур.

Основные элементы и понятия IDEF0

В основе IDEF0 лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

Верхняя сторона имеет значение “Управление” (Control); Левая сторона имеет значение “Вход” (Input); Правая сторона имеет значение “Выход” (Output); Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 2. Функциональный блок

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. Например, на рисунке (см. Рисунок 3) изображен функциональный блок “Обработать заготовку”.

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

Рисунок 3. Функциональный блок «Обработать заготовку»

Другое дело, когда технологические указания обрабатываются главным технологом и в них вносятся изменения (см. Рисунок 4). В этом случае они отображаются уже входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, исходя из которых, производятся данные изменения.

Рисунок 4. Функциональный блок «Корректировать технологические указания»

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