Описание и анализ бизнес-процессов
В процессе создании информационной системы для какого-либо предприятия, очень важным является правильное описание и анализ бизнес-процессов. Правильно смоделированные бизнес-процессы являются основой для успешного функционирования будущей информационной системы, а значит и самой организации.
При моделирование бизнес-процессов наиболее часто возникают следующие вопросы:
- какое программное обеспечение использовать,
- как моделировать процессы с использованием выбранного продукта,
- как проводить анализ и выявлять использованием выбранного продукта,
- какую методологию использовать для описания процессов.
В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют, так или иначе, создавать описания (модели) бизнес-процессов предприятий. Очевидно, что выбор системы в значительной мере определяет весь дальнейший ход проекта. Рациональный выбор системы возможен при понимании руководством компании, и ее специалистами нескольких аспектов:
- целей проекта;
- требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений в рамках конкретного проекта;
- возможностей CASE-систем по описанию процессов с учетом выдвинутых требований.
Говорить о преимуществе той или иной системы/нотации бессмысленно, пока не определены тип и рамки проекта, основные задачи, которые данные проект должен решить. Ниже сделана попытка провести сравнение наиболее популярных нотаций, используемых для описания бизнес-процессов, и двух систем, поддерживающих эти нотации.
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. Для каждой такой задачи существует определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы:
- какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
- в какой последовательности выполняются эти процедуры;
- какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
- кто выполняет процедуры процесса;
- какие входящие документы/информацию использует каждая процедура процесса;
- какие исходящие документы/информацию генерирует процедура процесса;
- какие ресурсы необходимы для выполнения каждой процедуры процесса;
- какая документация/условия регламентирует выполнение процедуры;
- какие параметры характеризуют выполнение процедур и процесса в целом.
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, т.к. ее можно будет подвергнуть анализу и реорганизации.
Описание нотаций
Наиболее популярными нотациями, используемыми для описания бизнес-процессов являются нотации ARIS eEPC и IDEF0, IDEF3.
ARIS eEPC
Нотация ARIS eEPC расшифровывается следующим образом: extended Event Driven Process Chain (расширенная нотация описания цепочки процесса, управляемого событиями). Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице 2.1 приводятся основные объекты, используемые в рамках нотации ARIS eEPC.
Таблица 2. 1-Основные объекты нотации ARIS eEPC
| № | Наименование | Описание | Графическое представление |
| Функция Объект | «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. | 
| |
| Событие Объект | «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций | 
| |
| Организационная единица | Объект, отражающий различные организационные звенья предприятия (например, управление или отдел) | 
| |
| Документ | Объект, отражающий реальные носители информации, например бумажный документ | 
| |
| Прикладная система | Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции | 
| |
| Кластер информации | Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных | 
| |
| Стрелка связи между объектами | Объект описывает тип отношений между другими объектами, например – активацию выполнения функции некоторым событием | 
| |
| Логическое «И» | Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
| |
| Логическое «ИЛИ» | Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
| |
| Логическое исключающее «ИЛИ» | Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса | 
|
Помимо указанных в Таблице 2.1 основных объектов, при построении диаграммы eEPC могут быть использованы многие другие объекты. Применение большого числа различных объектов, связанных различными типами связей значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC достаточно рассмотреть основные используемые типы объектов и связей. На рисунке 2.1 представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.
Рисунок 2.1- Простейшая модель eEPC
Из рисунка, представленного выше, можно увидеть, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:
- каждая функция должна быть инициирована событием и должна завершаться событием;
- в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.
Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер вместе с продуктом.
На рисунке 2.2. показано применение различных объектов ARIS при создании модели бизнес-процесса.
Рисунок 2.2- Применение различных объектов ARIS при создании модели бизнес-процесса
Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количество т.н. пользовательских атрибутов.
Из рисунка 2.2 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Пример моделей, сформированных с использованием ARIS eEPC, показаны на рисунках 2.3-2.4
Рисунок 2.3
Рисунок 2.4