
В настоящее время в условиях жесткой конкуренции любая компания стремится повысить эффективность своей деятельности различными способами, наиболее распространенными из которых являются оптимизация и автоматизация бизнес-процессов. Для того, чтобы проанализировать как работает предприятие в целом, как оно взаимодействует с внешними организациями, как налажено взаимодействие между различными подразделениями, а также как организована деятельность на каждом отдельно взятом рабочем месте применяется моделирование бизнес-процессов.
Модель бизнес-процесса - это формализованное (графическое, табличное, текстовое, символьное) описание, отражающее реально существующую или предполагаемую деятельность предприятия.
Основной целью моделирования бизнес-процессов является повышение эффективности работы компании, при этом определяется текущее состояние бизнес процесса, правила его выполнения и взаимосвязи с другими процессами, на основании чего выявляются проблемные места и разрабатываются решения для их улучшения.
Одной из распространенных на сегодняшний день методологий моделирования бизнес-процессов является методология ARIS и программный продукт семейства CASE-средств - ARIS EXPRESS, о которых подробнее поговорим в этой публикации.
Введение
Наличие единого методологического подхода и технологии моделирования являются залогом успешности решения задач по разработке предложений по оптимизации бизнес-процессов любой организации и их дальнейшей автоматизации.
Определения объектов, типы связей объектов даны в соответствии с методологией ARIS, и поддерживающей эту методологию инструментальной средой ARIS Express.
При моделировании направлений деятельности Заказчика по методологии ARIS используются только модели, объекты, связи и атрибуты, указанные в данных Правилах моделирования.
Правила моделирования (далее Правила) базируются на методологии ARIS и ориентированы на использовании принципов процессного подхода и процессного описания деятельности организации.
Процессный подход – подход к организации и анализу деятельности компании/организации, основанный на выделении и рассмотрении организации в целом как совокупности ее бизнес-процессов, каждый из которых протекает во взаимосвязи с другими бизнес-процессами компании или внешней средой.
В Таблице 1 представлен перечень областей, охватываемых данными Правилами с указанием Описания решаемого круга задач.
Таблица 1 Перечень областей
ОБЛАСТЬ |
ОПИСАНИЕ |
||
Организационная |
|
||
Структура |
|
||
Структура |
|
||
ИТ-инфраструктура |
|
Наименование объектов организовано по следующим правилам:
- Конкретность: выбранное наименование должно однозначно и кратко определять описываемый объект и однозначно трактоваться пользователями репозитория бизнес-процессов
- Однозначность: разные по смыслу объекты должны иметь разные наименования. Необходимость создания нового объекта определяется на основе анализа уже существующих объектов
Модель должна содержать такое число объектов, которое обеспечит читаемость модели на формате листа – А4.
Термины/Определения
С целью однозначности толкований понятий в таблице 2 представлены основные определения терминов, используемых в Правилах моделирования.
Таблица 2 Основные термины
№ |
ТЕРМИН |
ОПРЕДЕЛЕНИЕ |
||
|
Процессная система |
|
||
|
Цель |
|
||
|
Бизнес-процесс |
|
||
|
Основной бизнес-процесс |
|
||
|
Обеспечивающий |
|
||
|
Продукт |
|
||
|
Функция |
|
||
|
Нотация |
|
Система условных обозначений, принятая в какой-либо области знаний или деятельности, в нашем случае, в области моделирования бизнес-процессов. Включает множество символов, используемых для представления понятий и их взаимоотношений, составляющее алфавит нотации, а также правила их применения.
Концепция подхода к моделированию
Общие положения
Основой подхода является выделение бизнес-процессов и последующая детализация (декомпозиция) комплекса моделей, отражающих различные аспекты деятельности организации.
Организационная модель (Organization chart) описывает иерархическую структуру предприятия, т.е. организационные единицы, связанные между собой коммуникационными отношениями и отчетностью.
Для моделирования процессной структуры организации/предприятия используются:
- Цепочки добавленного стоимости (value added chain diagram, VAD) в нашем случае при использовании ARIS Express это модель «Process landscape»
- Последующая детализация полученных моделей осуществляется с использованием событийных цепочек процессов (event-driven process chain, EPC with material flow) в нашем случае при использовании ARIS Express это модель «Business process»
- Для изображения на одной диаграмме событий, исполнителей, материальных и документальных потоков, сопровождающих выполнение процесса, используется модель «BPMN diagram»
Для моделирования процессной структуры ИТ организации/предприятия используются модели:
- «IT infrastructure» - возможно представить модель сетевых взаимосвязей инженерно- технического оборудования и ИТ-систем
- «System landscape» - схематическое представление взаимосвязей ИТ-систем
Детальное описание правил моделирования
Organization chart. Описание организационной структуры
Для отображения структуры организации/предприятия используется модель типа организационная схема (organizational chart), описывающая организационные единицы предприятия и их взаимоотношения (отношения руководства/подчинения).
Под организационной единицей, в дальнейшем будет пониматься исполнитель заданий, реализуемых для достижения целей деятельности организации/предприятия.
Уровень подразделений предприятия детализируется на модели организационной структуры второго уровня штатного расписания. Эта детализация отражается на модели (уровня подразделений) с использованием связи типа `is composed of`. Модель уровня штатного расписания представляет детальный уровень иерархии организационной структуры предприятия.
Для описания отдельных должностей используется тип `position`. Одна организационная единица может быть связана с несколькими должностями. Смысл соединений соответствует связям между организационными единицами.
Правила выделения объектов для описания организационной структуры приведены в таблице 3.
Таблица 3 Правила выделения объектов для описания организационной структуры
ТИП И СИМВОЛ ОБЪЕКТА |
ОПИСАНИЕ |
ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ |
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
В ARIS Express типы связей между объектами устанавливаются автоматически.
Пример модели организационной структуры представлен на рисунке 1
Рисунок 1 Пример модели организационной структуры
Process landscape Описание структуры процессов предприятия (цепочки добавленной стоимости - VAD)
Диаграммы цепочки добавленной стоимости (Value-Added Chain Diagram, VAD-диаграмма) используются для верхнеуровневого описания групп бизнес-процессов компании, непосредственно влияющих на выход готовой продукции.
Модель процессов «верхнего уровня» строится для того, чтобы целостно понимать структуру бизнеса Заказчика и не упустить иерархичности и взаимосвязи процессов.
Правила выделения объектов для описания структуры процессов организации/предприятия приведены в таблице 4.
Таблица 4 Правила выделения объектов для описания структуры процессов
ТИП И СИМВОЛ ОБЪЕКТА |
ОПИСАНИЕ |
ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ |
Process |
Процесс/подпроцесс |
Рекомендуется для отображения групп процессов, подпроцессов. |
Пример модели VAD на рисунке 2
Рисунок 2 Пример модели VAD
Business process Описание событийной цепочки бизнес-процесса
Общие правила описания событийной цепочки бизнес-процесса
Модель детального бизнес-процесса представляет собой логику реализации рассматриваемого этапа жизненного цикла процесса. Модель отражает набор действий, которые должны быть выполнены по заданным правилам для получения заданного результата. Условия выполнения действий (бизнес-функций), а также их исходы отражаются посредством событий. Иными словами, модель детального бизнес-процесса представляет собой последовательности событий и бизнес-функций, отражающих правила достижения заданного результата
Перед началом описания-бизнес процесса (вне зависимости от степени детализации) необходимо узнать:
- Кто?
- Какое задание выполняет?
- Когда?
- С помощью каких инструментов?
- С помощью каких данных (какие документы поступают на вход, какие на выходе)?
- Кто отвечает за результат (успех или неудачу) (владелец процесса)
- Как измерить результат (успех или неудачу) (ключевые показатели результативности)?
Правила наименования операций, шагов и событий:
- Название операции или шага должно включать отглагольное существительное, обозначающее действие, и существительное, описывающее объект действия (например, «утверждение отчета», «оформление платежных документов»)
- Название события должно описывать результат выполнения операции или шага (например, «сообщение отправлено»)
Нотации моделирования бизнес-процессов
Выбор нотации, в которой будет осуществляться моделирование бизнес-процесса осуществляется по требованиям Заказчика. К наиболее распространенным нотациям относятся нотация eEPC и нотация BPMN, описание которых представлено ниже.
Нотация eEPC
Модель бизнес-процесса в нотации eEPC (with material flow) представляет собой направленный граф, формируемый из событий, бизнес-функций и операторов ветвления. Исполнители, документы и элементы прикладных комплексов являются окружением бизнес-функций.
Объекты графа представлены в таблице 5
Таблица 5 Объекты модели eEPC
ТИП И СИМВОЛ ОБЪЕКТА |
ОПИСАНИЕ |
ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ |
Event |
Событие, отражающее исход выполнения одной функции и необходимость инициации другой функции |
Правила задания имени |
Function |
Бизнес-функция или действие, выполняемое для реализации некоторой операции, выполняемое при появлении заданного набора условий (событий) и направленное на получение определенного результата. |
Правила задания имени |
Entity |
Сущность (Технический ресурс (станок, оборудование), с помощью которого выполняется определенная функция; Ресурс-материал, который используется в течении процесса или любые другие реальные или абстрактные вещи, представляющие интерес в рамках задачи) |
Правила задания имен |
Database |
Хранилище данных, база данных |
Правила задания имен |
Document |
Документ |
Правила задания имен |
IT system |
ИТ-система |
Правила задания имен |
Product |
Продукт |
Правила задания имен |
Risk |
Риск |
Правила задания имен |
Process interface |
Процессный интерфейс |
Правила задания имен |
|
Оператор И |
В случае если в начале или по завершении функции необходимо указать несколько событий, либо событие является результатом или влечет выполнение нескольких функций применяется правило. Применяются следующие операторы И, ИЛИ, Искл. ИЛИ, Сложное правило. |
|
Оператор Искл. ИЛИ |
|
|
Оператор ИЛИ |
Любой процесс обязательно начинается и заканчивается событием. Если начальное событие формируется в другом процессе (не является внешним по отношению к приводимому описанию), то ему предшествует интерфейс (+гиперссылка в свойствах), ссылающийся на предшествующий процесс. И наоборот, если конечное событие запускает другой процесс, то за ним также следует интерфейс (+гиперссылка в свойствах), отражающий последующий процесс.
Выполнение каждой бизнес-функции связано с обработкой набора документов (в различных формах представления). Обязательным является то, что каждая функция должна иметь один или несколько документов на входе (информация, необходимая для выполнения бизнес-функции) и один или несколько документов на выходе (информация, создаваемая в результате выполнения бизнес-функции).
Моделирование процесса осуществляется сверху вниз. Элементы окружения располагаются относительно функций следующим образом (рекомендуемое размещение объектов на модели относительно блока Activity):
Обязательные элементы окружения функции(процесса):
- Сам объект функция/бизнес-процесс/операция/шаг – в центре
- Входящие документы – слева сверху друг под другом
- Объекты организационная единица и роль – справа
- Исходящие документы – справа снизу друг под другом
Необязательные элементы окружения функции(процесса) (добавляются в случае необходимости конкретизации либо пояснения по смыслу):
- Место исполнения функции – справа сверху
- Сущность, ресурс – слева
- База данных, хранилище информации, источник информации – слева внизу
Все указанное окружение функции (документы, исполнители) находят свое отражение вокруг выделяемой функции.
Пример правильного расположения представлен на рисунке 3.
Рисунок 3 Пример правильного расположения объектов окружения функции
Важным также является правильное отражение ветвлений процесса. Для ветвления используются соответствующие операторы ‘AND’ (И), ‘OR’ (ИЛИ), ‘XOR’ (Исключающее ИЛИ). Одним из основных правил является ограничение на количество входящих и исходящих соединений для событий и функций – их не должно быть больше одного.
В соответствии с этим правилом ошибочными являются представленные на рисунке 4 примеры.
Рисунок 4 Примеры ошибочного отображения ветвления
Для исправления подобных ошибок следует воспользоваться соответствующим логическим оператором. Пример исправления указанных выше ветвлений представлен на рисунке 5
Рисунок 5 Пример исправленных ошибок
При отражении ветвлений важным также является правильность выбора оператора (подробности см. в разделе «Правила выделения объектов») и его корректное использование. Корректное использование подразумевает необходимость отражения ветвлений таким образом, чтобы из представленной структуры модели были ясны условия, при которых процесс продолжается по каждой из веток ветвления. Для выполнения указанных правил необходимо использовать следующее ограничение – оператор ‘OR’ (ИЛИ) или ‘XOR’ (Исключающее ИЛИ) не может следовать за событием. Пример правильного и некорректного отражения подобных ветвлений представлен на рисунке 6.
Рисунок 6 Пример некорректного и правильного отражения ветвления процесса на альтернативные направления
Если процесс разветвился на параллельные ветки с использованием соответствующего оператора ветвления (ветки выполняются одновременно или альтернативно), то в точке последующего объединения этих веток необходимо использовать тот же оператор ветвления. Данное правило не является жестким, так как могут быть исключения, однако, в большинстве случаев оно соблюдается. Примером правильного ветвления и последующего соединения веток процесса является фрагмент, отраженный на рисунке 6.
Кроме того, важной характеристикой каждого события является то, что оно должно представлять собой исход только одной конкретной функции. Иллюстрацию подобного примера можно увидеть на рисунке 7.
Рисунок 7 Пример использования событий в качестве исходов функций
Нотация BPMN
В модели операций определены следующие правила:
- Модель всегда начинается со стартового события
- Для разветвления моделей по нескольким маршрутам необходимо использовать логические операторы
- Количество пересекающихся связей на моделях следует минимизировать
- На моделях не должно быть объектов без связей
- Модель должна заканчиваться завершающим событием
Ниже в таблицах 6-8 представлены типы объектов и связей, используемых при моделировании операций.
Таблица 6. Типы объектов, используемые в модели операций
ОБЪЕКТ |
СИМВОЛ В ARIS |
ОПИСАНИЕ |
Операция и шаги |
||
Неавтоматизированная задача |
![]() |
Шаг, выполняемый исполнителем без средств автоматизации |
Задача получения сообщения, информации |
![]() |
Объект показывает получение сообщения |
Задача отправки сообщения, информации |
![]() |
Объект показывает отправку сообщения |
Пользовательская задача |
![]() |
Шаг, выполняемый с использованием программного обеспечения или при содействии других людей |
Автоматизированная задача |
![]() |
Шаг, порядок выполнения операций которого описан на языке, распознаваемом программой-исполнителем. Обычно используется для задач, выполняемых автоматическими средствами |
Служебная задача |
![]() |
Шаг, предназначенный для оказания услуги, которая может являться как веб-сервисом, так и автоматизированным приложением |
Задача бизнес-правила |
![]() |
Шаг, технология выполнения которого зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила |
События |
||
Стартовое событие без указания типа |
![]() |
Объект соответствует событию, с которого начинается бизнес-процесс или операция |
Промежуточное событие без указания типа |
![]() |
Объект соответствует событию, происходящему внутри бизнес-процесса или операции |
Завершающее событие без указания типа |
![]() |
Объект соответствует событию, завершающему бизнес-процесс или операцию |
Пул и дорожки (представляют объекты соответствующих моделей) |
||
Пул |
![]() |
Представляет подразделения Заказчика, соответствующие объектам модели организационной структуры, или внешние вовлеченные стороны |
Дорожка (Lane) «Роль» |
![]() |
Представляет объект модели соответствия ролей и организационных единиц |
Логические операторы |
||
Исключающий шлюз |
![]() |
При ветвлении активируется один исходящий поток. Для активации исходящего потока при слиянии ожидает завершения любой (но только одной) входящей ветви. (Логическое Исключающее ИЛИ) |
Включающий шлюз |
![]() |
При ветвлении активируется один или более исходящих потоков. Для активации исходящего потока при слиянии ожидает завершения всех активированных входящих ветвей. (Логическое ИЛИ) |
Параллельный шлюз |
![]() |
При ветвлении все исходящие потоки активируются одновременно. При слиянии ожидает завершения всех входящих ветвей и активирует исходящий поток. (Логическое И) |
Прочие объекты |
||
Хранилище данных |
![]() |
Объект соответствует базе данных и хранилищу данных |
Объект данных |
![]() |
Объект соответствует любому носителю информации – документ, файл |
Сообщение |
![]() |
Объект соответствует сообщению, которым обмениваются операции или шаги разных операций между пулами |
Текстовое примечание |
![]() |
Объект соответствует текстовому комментарию |
Группа объектов |
![]() |
Группировка действий, не оказывающая влияние на последовательный поток. Группировка может использоваться для документирования или анализа |
Таблица 7. Типы событий, используемые в модели операций
СОБЫТИЕ |
СТАРТОВОЕ |
ПРОМЕЖУТОЧНОЕ ОБРАВТЫВАЮЩЕЕ |
ПРОМЕЖУТОЧНОЕ ГЕНЕРИРУЮЩЕЕ |
ЗАВЕРШАЮЩЕЕ |
Сообщение: получение и отправка сообщений |
![]() |
![]() |
||
Отправка сообщений |
![]() |
|||
Таймер: ожидание (таймаут) в ходе выполнения бизнес-процесса или операции |
![]() |
![]() |
||
Ошибка: ошибка, возникшая в ходе выполнения бизнес-процесса или операции |
![]() |
|||
Остановка: немедленное прекращение бизнес-процесса или операции |
![]() |
Таблица 8. Типы связей, используемые в модели операций
|
|
![]() |
|
![]() |
|
![]() |
|
Результаты моделирования бизнес-процессов
Результатами моделирования являются модели бизнес-процессов, выполненные в стандартном формате, отражающее реально существующую или предполагаемую деятельность организации/предприятия:
- Модель и описание бизнес-процессов «AS-IS» («как есть»), которая позволит отобразить текущее состояние и систематизировать выполняющиеся в данный момент бизнес-процессы, а также используемые информационные объекты, которыми оперируют описываемые процессы. На основе данной модели выявляются проблемные места при выполнении и взаимодействии процессов и определяется необходимость тех или иных изменений в существующей структуре
- Модель и описание процессов «TO-BE» («как должно быть»), которая учитывает результаты, полученные на этапе моделирования процессов «AS‑IS» («как есть») и устраняет недостатки, выявленные в существующей организации процессов, описывает оптимальные варианты бизнес-процессов
На основании моделей бизнес-процессов руководство предприятия принимает обоснованное решение по внесению изменений в существующие бизнес-процессы (оптимизация бизнес-процессов) и внедрению средств автоматизации, что позволит повысить эффективность работы как отдельных бизнес-процессов в частности, так и деятельность организации/предприятия в целом.
К списку публикаций