+7 (495) 646 11 75
Аутсорсинг аналитических работ в ИТ-проектах

Моделирования в среде ARIS Express

К списку публикаций
28.09.2017г.

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

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

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

Одной из распространенных на сегодняшний день методологий моделирования бизнес-процессов является методология ARIS и программный продукт семейства CASE-средств - ARIS EXPRESS, о которых подробнее поговорим в этой публикации.

Введение

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

Определения объектов, типы связей объектов даны в соответствии с методологией ARIS, и поддерживающей эту методологию инструментальной средой ARIS Express.

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

Правила моделирования (далее Правила) базируются на методологии ARIS и ориентированы на использовании принципов процессного подхода и процессного описания деятельности организации.

Процессный подход – подход к организации и анализу деятельности компании/организации, основанный на выделении и рассмотрении организации в целом как совокупности ее бизнес-процессов, каждый из которых протекает во взаимосвязи с другими бизнес-процессами компании или внешней средой.

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

Таблица 1 Перечень областей

 

ОБЛАСТЬ

ОПИСАНИЕ

 
 

Организационная
структура
преприятия


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

 
 

Структура
процессов
предприятия


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

 
 

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


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

 
 

ИТ-инфраструктура


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

 

 

Наименование объектов организовано по следующим правилам:

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

Модель должна содержать такое число объектов, которое обеспечит читаемость модели на формате листа – А4.

Термины/Определения

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

Таблица 2 Основные термины

 


ТЕРМИН

ОПРЕДЕЛЕНИЕ

 
 


1

Процессная система
управления предприятием


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

 
 


2

Цель


Конечный результат, на который направлен бизнес-процесс

 
 


3

Бизнес-процесс


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

 
 


4

Основной бизнес-процесс


Бизнес-процесс, который добавляет стоимость. Например, «Производство», «Проектирование продукта», «Логистика производства»

 
 


5

Обеспечивающий
бизнес-процесс


Бизнес-процесс, поддерживающий инфраструктуру предприятия. Например, «Управление кадрами», «Бухгалтерский учет»

 
 


6

Продукт


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

 
 


7

Функция


Предметно-ориентированное задание или действие, выполняемое над объектом, в результате которого достигается одна или нескольких целей, стоящих перед организацией/предприятием

 
 


8

Нотация


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

 

 

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

Концепция подхода к моделированию

Общие положения

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

Организационная модель (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 Правила выделения объектов для описания организационной структуры

 

ТИП И СИМВОЛ ОБЪЕКТА

ОПИСАНИЕ

ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ

 
 


Organizational
unit

Organization unit

 


Подразделение Служба, Отдел, Бюро организации/предприятия, Должность в составе
подразделения


Правила задания имени

Имя задается в соответствии с принятым в организации наименованием подразделения, в соответствии с названием штатной единицы (для должности)
Пример:
Центр развития
Отдел маркетинга и сбыта
Генеральный директор
Детализация
Каждый объект, отражающий подразделение предприятия, отображается на модели организационной структуры.

 
 


Person
Person


Сотрудник предприятия


Правила задания имени

Имя задается в соответствии с ФИО конкретного сотрудника. Фамилия задается полностью, далее указываются инициалы.
Пример:
Иванов И.В.
Заполняемые атрибуты
‘Full name’ – указывается фамилия, имя и отчество полностью.

 
 


Role
Role


Бизнес-роль


Правила задания имени

Имя должно давать представление о круге выполняемых в рамках конкретного бизнес процесса функций.
Пример:
Тестировщик

 
 


Location
Location


Локация (месторасположение)


Правила задания имени

Имя должно давать представление о месторасположении подразделения, должности.
Пример:
г. Москва

 

 

В ARIS Express типы связей между объектами устанавливаются автоматически.

Пример модели организационной структуры представлен на рисунке 1

 5

Рисунок 1 Пример модели организационной структуры

Process landscape Описание структуры процессов предприятия (цепочки добавленной стоимости - VAD)

Диаграммы цепочки добавленной стоимости (Value-Added Chain Diagram, VAD-диаграмма) используются для верхнеуровневого описания групп бизнес-процессов компании, непосредственно влияющих на выход готовой продукции.

Модель процессов «верхнего уровня» строится для того, чтобы целостно понимать структуру бизнеса Заказчика и не упустить иерархичности и взаимосвязи процессов.

Правила выделения объектов для описания структуры процессов организации/предприятия приведены в таблице 4.

Таблица 4 Правила выделения объектов для описания структуры процессов

ТИП И СИМВОЛ ОБЪЕКТА

ОПИСАНИЕ

ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ

Process

Process

Процесс/подпроцесс

Рекомендуется для отображения групп процессов, подпроцессов.
Объект соответствует группе бизнес-процессов, создающих добавленную стоимость
Правила задания имени
Название процесса/подпроцесса

 

Пример модели VAD на рисунке 2 

 7

 Рисунок 2 Пример модели VAD

Business process Описание событийной цепочки бизнес-процесса

Общие правила описания событийной цепочки бизнес-процесса

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

Перед началом описания-бизнес процесса (вне зависимости от степени детализации) необходимо узнать:

  • Кто?
  • Какое задание выполняет?
  • Когда?
  • С помощью каких инструментов?
  • С помощью каких данных (какие документы поступают на вход, какие на выходе)?
  • Кто отвечает за результат (успех или неудачу) (владелец процесса)
  • Как измерить результат (успех или неудачу) (ключевые показатели результативности)?

Правила наименования операций, шагов и событий:

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

Нотации моделирования бизнес-процессов

Выбор нотации, в которой будет осуществляться моделирование бизнес-процесса осуществляется по требованиям Заказчика. К наиболее распространенным нотациям относятся нотация eEPC и нотация BPMN, описание которых представлено ниже.

Нотация eEPC

Модель бизнес-процесса в нотации eEPC (with material flow) представляет собой направленный граф, формируемый из событий, бизнес-функций и операторов ветвления. Исполнители, документы и элементы прикладных комплексов являются окружением бизнес-функций.

Объекты графа представлены в таблице 5

Таблица 5 Объекты модели eEPC

ТИП И СИМВОЛ ОБЪЕКТА

ОПИСАНИЕ

ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ

Event

t5

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

Правила задания имени
Имя события содержит описание свершившегося действия с использованием законченной формы глагола. Кроме того, следует указать, над каким объектом было произведено действие. При этом следует отразить детали, позволяющие однозначно идентифицировать событие и представляемую им ветку процесса.
К примеру, понятным и удобным в использовании является следующее наименование события: «Расчет потребности в материалах по группе фурнитуры и химии произведен». Здесь достаточно точно указано, какого рода данные были загружены и каким образом они были получены. Подобное правило крайне важно при отражении сложных ветвящихся процессов. Такое детальное описание события позволяет легко понять, с какой веткой процесса связано событие. В подобной ситуации некорректным стало бы использование таких общих названий для указанного события, как «Потребность в материалах произведена»

Function

t5

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

Правила задания имени
Имя функции задается в форме отглагольного существительного, отражающего суть выполняемых действий. Имя также содержит упоминание объекта, над которым это действие производится.
Пример:
«Согласование предложений с Заказчиком»

Entity

t5

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

Правила задания имен
Название сущности формируется исходя из наименования используемого ресурса

Database

t5

Хранилище данных, база данных

Правила задания имен
Название соответствует предназначению хранилища данных

Document

t5

Документ

Правила задания имен
Объект соответствует любому носителю информации – документ, файл

IT system

t5

ИТ-система

Правила задания имен
Название соответствует наименованию используемой ИТ-системы

Product

t5

Продукт

Правила задания имен
Название соответствует наименованию целевого продукта процесса

Risk

t5

Риск

Правила задания имен
Название отражает суть имеющегося риска

Process interface

t5

Процессный интерфейс

Правила задания имен
Название полностью совпадает с наименованием декомопзируемого процесса

 t5

Оператор И

В случае если в начале или по завершении функции необходимо указать несколько событий, либо событие является результатом или влечет выполнение нескольких функций применяется правило. Применяются следующие операторы И, ИЛИ, Искл. ИЛИ, Сложное правило.

 t5

Оператор Искл. ИЛИ

 t5

Оператор ИЛИ

 

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

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

Моделирование процесса осуществляется сверху вниз. Элементы окружения располагаются относительно функций следующим образом (рекомендуемое размещение объектов на модели относительно блока Activity):

Обязательные элементы окружения функции(процесса):

  • Сам объект функция/бизнес-процесс/операция/шаг – в центре
  • Входящие документы – слева сверху друг под другом
  • Объекты организационная единица и роль – справа
  • Исходящие документы – справа снизу друг под другом

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

  • Место исполнения функции – справа сверху
  • Сущность, ресурс – слева
  • База данных, хранилище информации, источник информации – слева внизу

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

Пример правильного расположения представлен на рисунке 3.

 20

Рисунок 3 Пример правильного расположения объектов окружения функции

Важным также является правильное отражение ветвлений процесса. Для ветвления используются соответствующие операторы ‘AND’ (И), ‘OR’ (ИЛИ), ‘XOR’ (Исключающее ИЛИ). Одним из основных правил является ограничение на количество входящих и исходящих соединений для событий и функций – их не должно быть больше одного.

В соответствии с этим правилом ошибочными являются представленные на рисунке 4 примеры.

 Ошибки моделирования

Рисунок 4 Примеры ошибочного отображения ветвления

Для исправления подобных ошибок следует воспользоваться соответствующим логическим оператором. Пример исправления указанных выше ветвлений представлен на рисунке 5

 Ошибки моделирования

 Рисунок 5 Пример исправленных ошибок

При отражении ветвлений важным также является правильность выбора оператора (подробности см. в разделе «Правила выделения объектов») и его корректное использование. Корректное использование подразумевает необходимость отражения ветвлений таким образом, чтобы из представленной структуры модели были ясны условия, при которых процесс продолжается по каждой из веток ветвления. Для выполнения указанных правил необходимо использовать следующее ограничение – оператор ‘OR’ (ИЛИ) или ‘XOR’ (Исключающее ИЛИ) не может следовать за событием. Пример правильного и некорректного отражения подобных ветвлений представлен на рисунке 6.

6

  Рисунок 6 Пример некорректного и правильного отражения ветвления процесса на альтернативные направления

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

Кроме того, важной характеристикой каждого события является то, что оно должно представлять собой исход только одной конкретной функции. Иллюстрацию подобного примера можно увидеть на рисунке 7.

 Ошибки моделирования

 Рисунок 7 Пример использования событий в качестве исходов функций

Нотация BPMN

В модели операций определены следующие правила:

  • Модель всегда начинается со стартового события
  • Для разветвления моделей по нескольким маршрутам необходимо использовать логические операторы
  • Количество пересекающихся связей на моделях следует минимизировать
  • На моделях не должно быть объектов без связей
  • Модель должна заканчиваться завершающим событием

 Ниже в таблицах 6-8 представлены типы объектов и связей, используемых при моделировании операций.

Таблица 6. Типы объектов, используемые в модели операций

ОБЪЕКТ

СИМВОЛ В ARIS

ОПИСАНИЕ

Операция и шаги

Неавтоматизированная задача

Task1

Шаг, выполняемый исполнителем без средств автоматизации

Задача получения сообщения, информации

Task2

Объект показывает получение сообщения

Задача отправки сообщения, информации

Task3

Объект показывает отправку сообщения

Пользовательская задача

Task4

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

Автоматизированная задача

Task5

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

Служебная задача

Task6

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

Задача бизнес-правила

Task7

Шаг, технология выполнения которого зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила

События

Стартовое событие без указания типа

Task7

Объект соответствует событию, с которого начинается бизнес-процесс или операция

Промежуточное событие без указания типа

Task8

Объект соответствует событию, происходящему внутри бизнес-процесса или операции

Завершающее событие без указания типа

Task9

Объект соответствует событию, завершающему бизнес-процесс или операцию

Пул и дорожки (представляют объекты соответствующих моделей)

Пул

Task10

Представляет подразделения Заказчика, соответствующие объектам модели организационной структуры, или внешние вовлеченные стороны

Дорожка (Lane) «Роль»

Task11

Представляет объект модели соответствия ролей и организационных единиц

Логические операторы

Исключающий шлюз

Task12

При ветвлении активируется один исходящий поток. Для активации исходящего потока при слиянии ожидает завершения любой (но только одной) входящей ветви. (Логическое Исключающее ИЛИ)

Включающий шлюз

Task13

При ветвлении активируется один или более исходящих потоков. Для активации исходящего потока при слиянии ожидает завершения всех активированных входящих ветвей. (Логическое ИЛИ)

Параллельный шлюз

Task15

При ветвлении все исходящие потоки активируются одновременно. При слиянии ожидает завершения всех входящих ветвей и активирует исходящий поток. (Логическое И)

Прочие объекты

Хранилище данных

Task16

Объект соответствует базе данных и хранилищу данных

Объект данных

Task17

Объект соответствует любому носителю информации – документ, файл

Сообщение

Task18

Объект соответствует сообщению, которым обмениваются операции или шаги разных операций между пулами

Текстовое примечание

Task19

Объект соответствует текстовому комментарию

Группа объектов

Task20

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

 

Таблица 7. Типы событий, используемые в модели операций

СОБЫТИЕ

СТАРТОВОЕ

ПРОМЕЖУТОЧНОЕ ОБРАВТЫВАЮЩЕЕ

ПРОМЕЖУТОЧНОЕ ГЕНЕРИРУЮЩЕЕ

ЗАВЕРШАЮЩЕЕ

Сообщение: получение и отправка сообщений

 Task21  Task23    

Отправка сообщений

      Task25

Таймер: ожидание (таймаут) в ходе выполнения бизнес-процесса или операции

 Task22  Task24    

Ошибка: ошибка, возникшая в ходе выполнения бизнес-процесса или операции

     
t5

Остановка: немедленное прекращение бизнес-процесса или операции

      Task27

 

Таблица 8. Типы связей, используемые в модели операций


СИМВОЛ


ОПИСАНИЕ



 Task28


Поток управления. Последовательный поток управления показывает порядок, согласно которому будут выполняться операции и (или) шаги



 Task29


Поток управления по умолчанию. Используется для указания хода бизнес-процесса или операции в том случае, если условия, указанные в условном потоке или на шлюзах не исполнились


 Task30


Поток сообщений. Отображает передачу сообщений между пулами

 

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

Результатами моделирования являются модели бизнес-процессов, выполненные в стандартном формате, отражающее реально существующую или предполагаемую деятельность организации/предприятия:

  • Модель и описание бизнес-процессов «AS-IS» («как есть»), которая позволит отобразить текущее состояние и систематизировать выполняющиеся в данный момент бизнес-процессы, а также используемые информационные объекты, которыми оперируют описываемые процессы. На основе данной модели выявляются проблемные места при выполнении и взаимодействии процессов и определяется необходимость тех или иных изменений в существующей структуре
  • Модель и описание процессов «TO-BE» («как должно быть»), которая учитывает результаты, полученные на этапе моделирования процессов «AS‑IS» («как есть») и устраняет недостатки, выявленные в существующей организации процессов, описывает оптимальные варианты бизнес-процессов

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

К списку публикаций
Закрыть
Связаться с нами
Закрыть
Сообщение отправлено

Наши менеджеры свяжутся с вами в ближайшее время