Структурные модели процессов организацииkm.mmf.bsu.by/courses/2016/bp/repin.pdf · магазинов магазинов Магазин как

Глава 4. Описание бизнес-процессов организации 2334.5. Структурные модели процессов организации

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

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

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

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

Для формирования структурных моделей используются со-ответствующие нотации: IDEF0, ARIS Value Added Chain, Value Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Информация о них содержится во многих публикациях, поэтому в своей книге я не стану касать-ся этого вопроса.

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

разработки системы бизнес-процессов организации по прин- —ципу «сверху вниз»;

системного описания процессов, которые необходимо авто- —матизировать (например, в ERP-системе);

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

Рассмотрим деятельность торговой компании (розничная тор-говля продуктами питания). На рис. 4.5.1 показан пример структурной

Упра

влен

ие ф

инан

сам

и

IT

Упра

влен

ие п

ерсо

нало

м

АХО

Инж

енер

но-т

ехни

ческ

ое о

бесп

ечен

ие

...

Обе

спеч

ение

дея

тель

ност

и

Упра

влен

ие

диви

зион

омУп

равл

ение

на

прав

лени

ем

Маг

азин

Упра

влен

ие

сеть

ю

Розн

ичны

е пр

одаж

и

Упра

влен

ие п

рода

жам

и: в

цел

ом, п

о ди

визи

онам

, по

напр

авле

ниям

(кус

там)

,в

отде

льно

м м

агаз

ине

Упра

влен

ие т

овар

ным

и ка

тего

риям

и

Обе

спеч

ение

пот

ребн

осте

й по

треб

ител

ей в

това

ре (а

ссор

тим

ент,

цена

, кач

еств

о)

Физ

ичес

кая

пост

авка

това

ра в

сет

ь

Ком

плек

сное

обе

спеч

ение

дея

тель

ност

и м

агаз

инов

Маг

азин

как

про

дукт

Отк

рыти

е но

вых

маг

азин

овРа

звит

ие ф

орм

атов

м

агаз

инов

Разв

итие

CTM

Упра

влен

ие

разв

итие

м

Разв

итие

биз

неса

Ком

плек

сное

раз

вити

е: ф

орм

аты

, маг

азин

ы, С

ТМ

Стра

теги

ческ

ое у

прав

лени

е

Мар

кети

нгРе

клам

а и

PR...

Опе

рати

вное

упр

авле

ние

Упра

влен

ие б

изне

сом

Упра

влен

ие а

ссор

тим

енто

м

Нас

ыщ

ение

сет

и то

варо

м

Заку

пка

това

раУп

равл

ение

пос

тавк

ой то

вара

в с

еть

Тран

спор

тная

и с

клад

ская

лог

исти

ка

Под

держ

ание

фор

мат

ов м

агаз

инов

Оф

орм

лени

еИн

фра

стру

ктур

а

Инже

нерн

ое о

бесп

ечен

ие

Рабо

та с

пос

тавщ

икам

иУп

равл

ение

това

рны

ми

запа

сам

и

Цено

обра

зова

ние

Рис.

4.5

.1. П

рим

ер с

трук

турн

ой м

одел

и то

ргов

ой к

омпа

нии*

* О

дин

из в

озм

ожны

х ва

риан

тов

пред

став

лени

я.

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

На рис. 4.5.1 видно, что в модели выделено семь групп процессов. Цель ее построения — демонстрация возможного варианта опреде-ления и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согла-сования. В дальнейшем модель используется при построении систе-мы процессов организации.

На рис. 4.5.2 та же модель, что и на рис. 4.5.1, только выполненная в стандарте IDEF0.

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

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

Вопрос пользы структурных моделей для решения задач бизнес-моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации в одной модели IDEF0 (или в другой нотации) излишне. Если соблюдать все формаль-ные правила, то в такой модели может получиться семь-восемь уров-ней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work Flow и при помощи этих описаний сформировать регламенты рабо-ты сотрудников («регламент процесса», «инструкция по выполнению

Под

держ

ание

ф

орм

атов

м

агаз

инов

USE

D A

T:AU

THO

R:D

ATE:

01.

12.2

011

WO

RKIN

GRE

ADER

D

ATE

CO

NTE

XT:

A–O

PRO

JEC

T: М

одел

ь то

ргов

ой о

рган

изац

ииRE

V: 1

9.0

2.20

12D

RAF

T

REC

OM

MEN

DED

NO

TES:

1

2 3

4

5

6 7

8

9

10PU

BLI

CAT

ION

MO

DE:

АО

Упра

влен

ие

бизн

есом

А1

Упра

влен

ие

това

рны

ми

кате

гори

ями А2

Нас

ыщ

ение

се

ти т

овар

ом

А3П

одде

ржан

ие

фор

мат

ов

маг

азин

овА4

Розн

ичны

е пр

одаж

и

А5О

бесп

ечен

ие

деят

ельн

ости А7

Разв

итие

се

ти

А6

TITL

E:

Мод

ель

торг

овой

орг

аниз

ации

NU

MB

ER:

Цел

и ак

цион

еров Цел

и, п

ланы

...

Отч

етно

сть

Това

р от

пос

тавщ

иков

ТМЦ

для

обес

пече

ния

рабо

ты м

агаз

ина

Ден

ежны

е ср

едст

ва п

отре

бите

лей

ТМЦ

, ПО

и п

роче

е

Инф

орм

ация

о

рынк

е

Ассо

ртим

ентн

ая

мат

рица

Това

р, о

тгру

жен

ный

с РЦ

Ден

ежны

е ср

едст

ва в

бан

ке

Това

р у

потр

ебит

елей

Инф

. о п

рода

жах

Инф

-ра,

ТМ

Ц, П

О, п

роче

е

Инф

раст

рукт

ура

маг

азин

а

Отч

етно

сть

Тебо

вани

я по

раз

вити

ю

фор

мат

ов

Рис.

4.5

.2. П

рим

ер с

трук

турн

ой м

одел

и пр

оцес

сов

торг

овой

ком

пани

и* . Ста

ндар

т ID

EF0

* М

одел

ь уч

ебна

я. П

одра

здел

ения

— и

спол

ните

ли п

роце

ссов

не

пока

заны

. Обр

атны

е св

язи

тож

е.

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

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

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

Итак, структурная модель процессов нужна:бизнес-аналитикам для понимания деятельности органи- —зации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work Flow — регламентируемым или автоматически исполняемым в BPMS процессам);

руководителям организации для: —

уточнения зон ответственности, целей и задач их деятель- •ности;

анализа и совершенствования архитектуры бизнеса; •

руководителям и бизнес-аналитикам при проектировании —нового бизнеса.

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

* Этот вопрос подробно обсуждался в главе 3.

238 Бизнес-процессы. Моделирование, внедрение, управление

(например, в IDEF0) — удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативно-методической документацией.

4.6. Модели процессов на операционном уровне

В этом параграфе мы рассмотрим модели процессов на операцион-ном уровне. Они отображают последовательность выполнения опе-раций процесса (подпроцессов) во времени. Их обычно называют «модели Work Flow»*.

Сейчас существует множество нотаций типа Work Flow, при по-мощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения.

4.6.1. Нотации типа Work FlowНа рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно вы-делить пять основных:

События.1.

Операторы логики (по-другому их называют: блоки решения, 2. ветвления/развилки, шлюзы/гейтвеи**).

Операции процесса.3.

Стрелки типа «Связь предшествования».4.

Стрелки типа «Поток объектов».5.

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

* Work flow — «поток работ» (англ.). ** Gateway — «ворота, шлюз» (англ.).

Глава 4. Описание бизнес-процессов организации 239продукции», «Утвержден план проекта», «Подписана накладная», «8.00 понедельника» и т. п. Как видно на рис. 4.6.1, в различных нота-циях события показаны при помощи разных условных обозначений. Особняком стоит BPMN 2.0* (см., например, [9]). В рамках этой нота-ции внутри графического элемента «Событие» могут присутствовать различные маркеры: таймер, сообщение, триггер и т. д.

Рис. 4.6.1. Основные элементы нотации Work Flow

Процедура системы Business Studio

ARIS eEPC BPMN

События

Операторы логики

Операции процесса

Стрелки типа «Связь предшествования»

Стрелки типа «Поток объектов»

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

На рис. 4.6.2 приведен пример использования операторов логи-ки при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные).

При использовании логического оператора «И» (ситуация 1) по-сле операции 1 выполняются операция 2 и операция 3.

* Business Process Model and Notation. ** За исключением BPMN.


При использовании логического оператора исключающее «ИЛИ» (ситуация 2) после операции 1 выполняется одна из двух операций — 2 или 3.

При использовании логического оператора неисключающее «ИЛИ» (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и 3.

Условные обозначения для операций процесса (задач, действий, функций) выглядят практически одинаково во всех нотациях типа Work Flow.

Рис. 4.6.2. Использование операторов логики

Ситуация 1

После выполнения операции 1 выполняются операция 2 и операция 3

Операция 1

Операция 2 Операция 3

Логический оператор «и»

«и»

Ситуация 2

После выполнения операции 1 выполняется либо операция 2, либо операция 3

Операция 1


Логический оператор исключающее «или»

«или»

Ситуация 3

После выполнения операции 1 выполняется либо операция 2, либо операция 3, либо обе операции — 2 и 3

Операция 1


Логический оператор неисключающее «или»

«или»

Глава 4. Описание бизнес-процессов организации 241Важный элемент схемы Work Flow — связи. Они представлены при

помощи стрелок определенного вида. Первый тип — стрелки «Связь предшествования». Без них построение модели типа Work Flow невоз-можно. Стрелка «Связь предшествования», связывающая две опера-ции, показывает, что вторая операция начинает выполняться только после завершения первой. Можно сказать, что стрелки «Связь пред-шествования» демонстрируют развертку процесса во времени.

Стрелки «Поток объектов» используются на схемах типа Work Flow для описания потоков документов и информации*.

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

В следующих разделах рассмотрим наиболее известные нотации моделирования.

4.6.2. Простая блок-схемаНотация «Простая блок-схема» реализована в MS Visio. На рис. 4.6.3 показаны элементы этой нотации и фрагмент соответствующей схе-мы. В полном объеме нотация применяется редко.

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

Нотация «Простая блок-схема» в самом доступном и часто ис-пользуемом варианте содержит всего несколько элементов:

процесс; —

решение; —

ручная операция (реже); —

документ; —

данные; —

стрелка (для отображения связей между объектами схемы). —

* При необходимости их можно использовать для описания потоков материальных объектов.


При помощи этой нотации можно показать потоки данных, если необходимо описывать процессы для автоматизации.

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

не именуют стрелки вообще; —

стараются присваивать стрелкам, связывающим элементы —схемы, простые и понятные названия.

На рис. 4.6.4 показан пример применения простой блок-схемы в одной из компаний. Применены все пять типов элементов. Тем не менее схема выглядит вполне читаемой и понятной пользовате-лю — сотруднику компании.

Рис. 4.6.3. Нотация «Простая блок-схема» в MS Visio

Глава 4. Описание бизнес-процессов организации 243Нотация «Простая блок-схема» часто подвергается в организа-

циях различным вариациям:изменяется смысл элемента «Решение» (его используют в ка- —честве операции процесса);

по-разному используют стрелки связей (именуют или не име- —нуют и т. п.);

по-разному используют стрелки связей в сочетании с объек- —том «Документ»;

прочее. —

Интересно, что нотация «Простая блок-схема» в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК, так как она самая простая из из-вестных.

Преимущества простой блок-схемы (с сокращенным до миниму-ма количеством элементов):

простота формирования графических схем процессов; —

интуитивная понятность схем сотрудникам (даже без специ- —ального обучения);

минимальная потребность в обучении сотрудников; —

наличие доступных инструментов для описания процессов —(MS Visio, MS Word).

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

Рис.

4.6

.4. П

рим

ер с

хем

ы в

нот

ации

«Пр

оста

я бл

ок-с

хем

а»

Нача

ло

Доне

сти

реш

ения

до

рук

овод

и тел

ей п

одра

здел

ений

Изуч

ить

инф

орм

ацию

в Б

Д «К

адры

»

Подг

отов

ить

треб

ован

ия к

пер

-со

налу

и к

руг о

бяза

ннос

тей

Подг

отов

ить

расп

оряж

ение

о п

одбо

ре

канд

идат

а ср

еди

перс

онал

а

Руко

води

тели

стр

укту

рны

х по

драз

деле

ний

Пом

ощни

к ди

рект

ора

по к

адра

мД

ирек

тор

по о

бщим

воп

роса

мСо

вет

дире

ктор

ов (С

Д)

Реш

ение

СД

по к

адро

вым

воп

роса

м

Корр

екти

ровк

и тр

ебов

аний

и

обяз

анно

стей

Расп

оряж

ение

и тр

ебов

ания

к

канд

идат

у

Согл

асов

анны

е тр

ебов

ания

к

канд

идат

у

Пред

ложе

ния

по тр

ебов

ания

м

к ка

ндид

ату и

обя

занн

остя

м

Инф

орм

ация

о в

акан

сиях

Изм

енен

ия в

шта

тном

ра

спис

ании

Реш

ение

СД

о ро

таци

и ка

дров

(т

акти

ческ

ое р

ешен

ие)

Реш

ение

СД

о но

вых в

акан

сиях

(к

адро

вая

поли

тика

)

Кадр

овы

й ре

зерв

ес

ть?

да

да

нет

нет

Есть

ко

ррек

тиро

вки?

Запр

осит

ь пр

едло

жен

ия н

а за

мещ

е-ни

е ва

кант

ных д

олж

ност

ей

Напр

авит

ь пр

едло

жен

ия

Подг

отов

ить

расп

оряж

ение

о

поис

ке к

анди

дата

вне

ком

пани

и

Напр

авит

ь пр

едло

жени

я

Подг

отов

ить

расп

оряж

ение

о

пере

воде

на

нову

ю д

олж

ност

ь

Подг

отов

ить

расп

оряж

ение

о

стаж

иров

ке

Запр

ос

Пред

ложе

ния

руко

води

теле

й

Расп

оряж

ение

о п

оиск

е ка

ндид

ата

вне

ком

пани

и

Инф

орм

ация

об

отсу

тств

ии

канд

идат

ов с

реди

пер

сона

ла

Канд

идат

уры

дл

я ра

ссм

отре

ния

Запр

ос

Канд

идат

ура

на у

твер

жде

ние

СД

Расп

оряж

ение

на

офор

мле

ние

кадр

овы

х воп

росо

в (о

пер

евод

е)

Расп

оряж

ение

на

офор

мле

ние

кадр

овы

х воп

росо

в (о

ста

жир

овке

)

Канд

идат

со

глас

ен?

Нуж

на с

таж

иров

ка?

Утве

рдит

ь ка

ндид

атур

у

Канд

идат

со

отве

тств

ует?

Есть

нов

ые

канд

идат

уры

?

да

да

да да да

нет

нет

нет

нет

нет

Коне

ц


внутренний стандарт использования этой нотации; —

внутренний стандарт формирования, хранения и актуализа- —ции файлов со схемами процессов.

Масштабное использование в компании нотации «Простая блок-схема» без современного средства моделирования неэффективно.

4.6.3. Нотация ARIS eEPC*

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

ARIS eEPC — одна из первых нотаций, получившей широкую из-вестность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации — наличие элементов типа «Событие» и опера-торов логики «И», неисключающее «ИЛИ», исключающее «ИЛИ».

В качестве примера рассмотрим процесс, представленный на рис. 4.6.5, который начинается с события «Поступил заказ кли-ента». Оно инициирует операцию «Выполнить учет заказа в систе-ме», которую проводит менеджер отдела сбыта. Для работы он ис-пользует систему учета заказов. Результат операции отображается событием «Учет заказа выполнен». После этого менеджер по сбыту осуществляет операцию «Выполнить анализ на соответствие номен-клатуре». Ее результат — два альтернативных события: «Заказ соот-ветствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса использу-ется символ логического исключающего «ИЛИ».

* ARIS — «архитектура интегрированных информационных систем». ARIS eEPC (Extended Event-driven Process Chain) — «расширенная модель цепочки процесса, управляемого событиями» (нотация для описания бизнес-процессов).

Глава 4. Описание бизнес-процессов организации 247Операция «Уведомить клиента о невозможности выполнения

заказа» может выполняться в двух случаях: если заказ не соответ-ствует номенклатуре или если производство невозможно. Для ото-бражения на схеме процесса этих вариантов используется символ логического «ИЛИ».

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

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

Следует отметить, что типичная схема в ARIS eEPC:не годится для автоматизации в системе класса BPM — (Business Process Management) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последую-щей ручной доработкой);

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

Рис. 4.6.5. Схема процесса в нотации ARIS eEPC

* ПЭО — планово-экономический отдел.

Выполнить учет заказа в системе

Согласовать заявку с ПЭО

Выполнить анализ на соот-ветствие номен-

клатуре

Поступил заказ клиента

Заказ не соответствует

номенклатуре

Заказ соответствует номенклатуре

Производство возможно

Производство не возможно

Cистема учета заказов

Менеджер отдела сбыта



Экономист ПЭО*

Номенклатура изделий

Номенклатура изделий

Производствен-ные возможности

Сопроводи-тельное письмо

Заявка клиента



Рассчитать цену, сумму и сроки

выполнения заказа

Согласовать условия поставки

с клиентом

Внести клиента в статистику

неудовлетворен-ного спроса

Уведомить клиента о невозможности

выполнения заказа

Условия выполнения заказа

согласованы

Условия выпол нения заказа

не согласованы

Конец процесса



Экономист ПЭО

Cистема учета заказов

Плановая калькуляция

на заказЗаявка клиента

Нормативы

Файл Excel


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

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

4.6.4. Нотация BPMN

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

Разработана она компанией Business Process Management Initiative и под-держивается Object Management Group после слияния организаций в 2005 году. Предыдущая версия BPMN — 1.2, последняя версия — 2.0*.

Нотация BPMN появилась относительно недавно. Она ориенти-рована на описание так называемых исполняемых процессов, то есть процессов, которые поддерживаются системами автоматизации опе-рационных процессов — BPM.

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

получение заявок клиентов; —

обработка заявки и выставление счета (процесс выполняется —по одинаковой процедуре несколькими менеджерами отдела);

* Появилась в 2012 году.

Глава 4. Описание бизнес-процессов организации 251формирование графика доставки; —

обработка ждущих (отложенных) заявок; —

контроль остатков, рассылка информационных писем клиентам; —

изменение статуса товара в базе; —

обработка отказов. —

На рис. 4.6.6 показан процесс «Обработка заявки и выставление счета клиенту», описанный в нотации BPMN. Схема рис. 4.6.6 со-держит три объекта типа Gateway, восемь — типа Event и четыре операции (действия, задачи). Как видим, процесс совсем неслож-ный, но количество условных обозначений, нужных для его описа-ния, значительно.

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

руководители готовы тратить деньги на обучение и развитие —культуры бизнес-моделирования в организации;

руководители сами готовы активно осваивать нотацию BPMN; —

предполагается активно использовать схемы процессов —в BPMN для автоматизации операционных процессов.

К сожалению, сейчас на русском языке нет книг по использова-нию нотации BPMN. Есть только статьи, презентации, материалы вебинаров. Специалисты, заинтересованные в ее изучении, вынуж-дены обращаться к англоязычным источникам. Надеюсь, что в бли-жайшей перспективе ситуация изменится к лучшему.

Рис.

4.6

.6. Ф

рагм

ент

мод

ели

проц

есса

в н

отац

ии B

PMN

2.0

Выпи

сать

сче

тСф

орм

иров

ать

нову

ю з

аявк

у на

отгр

узку

в 1

C

Ном

енкл

атур

а то

варо

в

Запр

осит

ь ут

очне

нны

е да

н-ны

е по

зая

вке

Пров

ерит

ь за

явку

на

кор

рект

ност

ь

Клиент Обработка заявки и выставление счета

Запр

ос к

лиен

ту

Есть

не

обра

бота

н-на

я за

явка

Заяв

како

ррек

тная

?

Пись

мо

клие

нту

Да

Нет

2 дн

я

Отк

аз

клие

нта

Счет

на

това

р дл

я кл

иент

а

Отв

ета

нет

Счет

кл

иент

у

Уточ

ненн

ая з

аявк

аО

тказ

Глава 4. Описание бизнес-процессов организации 2534.6.5. Нотация «Процедура» среды моделирования Business StudioСейчас одним из распространенных инструментов бизнес-мо де ли-ро вания стала среда Business Studio*. В этой системе реализованы че-тыре нотации: IDEF0, «Процесс», «Процедура», eEPC.

Нотация IDEF0 используется для построения моделей верхне-го уро вня, а «Процедура» и eEPC — для создания моделей типа Work Flow.

Рассмотрим подробнее нотацию «Процедура» (см. рис. 4.6.7), так как она наиболее проста и удобна для описания бизнес-про цес сов организации. Основные элементы нотации — это:

операция («Действие» в терминологии Business Studio); —

событие; —

блок «Решение»; —

стрелка типа «Связь предшествования»; —

стрелка типа «Поток объектов»; —

междиаграммная ссылка (МДС); —

сноска (текстовый комментарий); —

дорожки. —

Ниже привожу рекомендации по использованию нотации «Про-цедура» в организации.

Размеры используемых шрифтов, визуальный вид объектов, цве-товое кодирование могут быть реализованы в типовых настройках Business Studio. Как правило, данные настройки делаются один раз и не должны в последующем изменяться пользователями.

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

* На начало 2011 года данная система использовалась более чем в 1000 компа-ний в России и странах СНГ.


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

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

Рекомендуемое количество операций на одном листе — от 3 до 12. Если операций более 15, необходимо либо агрегировать их, либо по-пытаться разбить процесс на несколько подпроцессов.

Рис. 4.6.7. Схема процесса в нотации «Процедура» среды моделирования Business Studio

Начальник отдела Менеджер

Пример процесса

Наименование операции 1 процесса




Наименование блока «Решение»

Наименование инициирующего события

Наименование завершающего события

Наименование стрелки 7



Наим

енов

ание

стр

елки

3

1.2. Пример процесса

Блок «Решение»Стрелка типа «Поток объектов»

Операция процесса именуется глаголом или отглагольным существительным

Стрелка типа «Связь предшествования».Стрелки должны быть обязательно именованы

Событие, инициирующее процесс. Может быть несколько событий, инициирующих процесс


Междиаграммная ссылкаНаименование стрелки 10





Глава 4. Описание бизнес-процессов организации 255В рамке автоматически указывается название процесса. Исполь-

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

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

Операции процесса должны быть связаны между собой стрелками типа «Связь предшествования». Если после выполнения операции не-обходимо поставить блок «Решение», то связи операций с этим блоком также отображаются при помощи стрелок «Связь предшествования».

Если между двумя операциями на схеме представлен блок «Решение», то для моделирования передачи информации/документов из одной опе-рации в другую используют стрелки типа «Поток объектов».

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

На рис. 4.6.8 представлены варианты именования операции про-цесса в формате «глагол + существительное». Также показаны ошиб-ки, часто допускаемые при именовании операций.

Выполнить подготовку договора поставки

оборудования

Правильно

Подготовить договор на поставку


Правильно

Выполнить подготов-ку договора поставки


Неправильно — тип и размер шрифта

Подготовка договора на поставку


Неправильно — именование при помощи

существительного

Договор поставки оборудования

Неправильно — вместо термина действия — существительное (договор)

Менеджер по продажам

Неправильно — вместо термина действия —

название должности

Подготовить договор поставки оборудования с учетом наличия

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

Луны и методики расчета опускной цены с учетом коэффициента 2

Неправильно — чрезмерно длинное название

операции

Рис. 4.6.8. Именование операций процесса


Стрелки типа «Связь предшествования» показывают последо-вательность выполнения операций процесса во времени. Каждая именованная стрелка в Business Studio — объект базы и хранится в справочнике стрелок. К именованным стрелкам типа «Связь пред-шествования» можно привязывать объекты из справочника «Объек-ты деятельности» (например, бумажные или электронные докумен-ты). К неименованным стрелкам привязать объекты невозможно. На рис. 4.6.9 показаны правильные и неправильные варианты приме-нения стрелок на схеме процесса. Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам), не допускается. Стрелки необходимо именовать. Нельзя использовать короткие, абстрактные названия: «да», «договор», «поступило письмо», «информация». Они должны быть подробные, конкретные и отражать контекст того процесса, в рамках которого создаются.

Стрелки типа «Связь предшествования» желательно именовать, указывая:

название документа в именительном падеже; —

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

Стрелки типа «Поток объектов» показывают движение объектов между операциями процесса. Под объектами понимаются любые объекты из справочника «Объекты деятельности системы Business Studio». В первую очередь это бумажные/электронные документы и информация. Стрелки «Поток объектов» используются там, где не-возможно (нецелесообразно) использовать стрелки «Связь предше-ствования», например:

при использовании блока «Решение»; —

при описании межпроцессного взаимодействия при помощи —информационного потока с использованием междиаграмм-ных ссылок.

Рис.

4.6

.9. И

спол

ьзов

ание

стр

елок

тип

а «С

вязь

пре

дшес

твов

ания

»

Опе

раци

я 1

Опе

раци

я 2

Связ

ь пр

едш

еств

ован

ия

Пра

виль

но

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Согл

асов

ать

дого

вор

с кл

иент

ом

Выпо

лнен

а по

дгот

овка

пр

оект

а до

гово

ра н

а по

став

ку

обор

удов

ания

Пра

виль

но

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Согл

асов

ать

дого

вор

с кл

иент

омСо

глас

оват

ь до

гово

р с

клие

нтом

Дого

вор

Да

Непр

авил

ьно

—

слиш

ком

общ

ее,

неко

нкре

тное

наз

вани

е ст

релк

и

Непр

авил

ьно

—

слиш

ком

общ

ее,

неко

нкре

тное

наз

вани

е ст

релк

и

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Согл

асов

ать

дого

вор

с кл

иент

омСо

глас

оват

ь до

гово

р с

клие

нтом

Прое

кт д

огов

ора

на п

оста

вку

обор

удов

ания

Пра

виль

ноНе

прав

ильн

о —

ст

релк

а не

пои

мен

ован

а

Опе

раци

я 1

Опе

раци

я 1

Опе

раци

я 1

Опе

раци

я 2

Опе

раци

я 2

Опе

раци

я 2

Связ

ь пр

едш

еств

ован

ияСв

язь

пред

шес

твов

ания

Связ

ь пр

едш

еств

ован

ия

Непр

авил

ьно

—

стре

лка

не п

рикр

епле

на

к оп

ерац

ии 1

Непр

авил

ьно

—

стре

лка

не п

рикр

епле

на

к оп

ерац

ии 2

Непр

авил

ьно

—

стре

лка

не п

рикр

епле

на

к оп

ерац

иям

Непр

авил

ьно

—

нача

ло/к

онец

стр

елки

не

при

креп

лены

ни

к од

ном

у из

объ

екто

в

Опе

раци

я 1


Каждая именованная стрелка — объект базы и хранится в спра-вочнике стрелок. К именованным стрелкам можно привязывать объ-екты из справочника «Объекты деятельности» (например, бумажные или электронные документы). К неименованным стрелкам привязать объекты невозможно.

На рис. 4.6.10 показаны правильные и неправильные варианты применения стрелок на схеме процесса.

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

Стрелки необходимо обязательно именовать, но нельзя ис-пользовать короткие, абстрактные названия типа «Договор», «Письмо», «Информация». Они должны быть подробными, кон-кретными и содержать наименование или отражать суть тех до-кументов/информации, которые используются в рамках модели-руемого процесса.

Стрелки типа «Поток объектов» можно именовать, указывая на-звание документа (формулировку информационного потока) в име-нительном падеже.

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

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

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

На рис. 4.6.11 показаны правильные и неправильные варианты применения на схеме объектов типа «Событие».

Рис.

4.6

.10.

Исп

ольз

ован

ие с

трел

ок т

ипа

«Пот

ок о

бъек

тов»

Опе

раци

я 1

Опе

раци

я 2

Пото

к об

ъект

ов

Пра

виль

но

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Согл

асов

ать

дого

вор

с кл

иент

ом

Прое

кт д

огов

ора

на п

оста

вку о

бору

дова

ния

Пра

виль

но

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Согл

асов

ать

дого

вор

с кл

иент

ом

Дого

вор

Непр

авил

ьно

—

слиш

ком

общ

ее,

неко

нкре

тное

наз

вани

е ст

релк

и

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Выпо

лнит

ь по

дгот

овку

до

гово

ра п

оста

вки

обор

удов

ания

Согл

асов

ать

дого

вор

с кл

иент

омСо

глас

оват

ь до

гово

р с

клие

нтом

Выпо

лнен

а по

дгот

овка

пр

оект

а до

гово

ра н

а по

став

ку

обор

удов

ания

Непр

авил

ьно

—

стре

лка

имен

ован

а в

терм

инах

«р

езул

ьтат

дей

стви

я»,

но п

о см

ысл

у он

а пр

едст

авля

ет

собо

й по

ток

объе

ктов

Непр

авил

ьно

—

стре

лка

не п

оим

енов

ана

Опе

раци

я 1

Опе

раци

я 2

Пото

к об

ъект

ов

Непр

авил

ьно

—

стре

лка

не п

рикр

епле

на

к оп

ерац

ии 2

Непр

авил

ьно

—

нача

ло/к

онец

стр

елки

не

при

креп

лены

ни

к од

ном

у из

объ

екто

в

Опе

раци

я 1

Опе

раци

я 1

Опе

раци

я 2

Пото

к об

ъект

ов

Непр

авил

ьно

—

стре

лка

не п

рикр

епле

на

к оп

ерац

иям

Опе

раци

я 1

Опе

раци

я 2

Пото

к об

ъект

ов

Непр

авил

ьно

—

стре

лка

не п

рикр

епле

на

к оп

ерац

ии 1

Рис.

4.6

.11.

Исп

ольз

ован

ие с

обы

тий

Коне

ц пр

оцес

са п

одпи

сани

я до

гово

ра н

а по

став

ку

обор

удов

ания

Заре

гист

риро

ван

запр

ос

клие

нта

на п

оста

вку

обор

удов

ания

Потр

ебно

сть

в об

оруд

ован

ииНа

чало

про

цесс

аУт

ром

Заре

гист

риро

ван

запр

ос

клие

нта

на п

оста

вку

обор

удов

ания

Коне

ц пр

оцес

са

Непр

авил

ьно

—

абст

ракт

ная

фор

мул

иров

ка с

обы

тия

Непр

авил

ьно

— а

бстр

актн

ая ф

орм

улир

овка

соб

ыти

я и

неим

енов

анна

я ст

релк

а

Пра

виль

но

Пра

виль

ноП

рави

льно

В да

нном

слу

чае

неиз

вест

но,

чере

з ка

кое

врем

я по

ступ

ит п

исьм

о от

кли

ента

. Пр

оцес

с пр

еры

вает

ся

на н

еопр

едел

енно

е вр

емя

и ж

дет п

осту

плен

ия п

исьм

а

Отп

рави

ть те

хник

о-ко

мм

ерче

ское

пре

длож

ение

(Т

КП) к

лиен

ту

Подг

отов

ить

отве

т на

воп

росы

кли

ента

по

ТКП

ТКП

отпр

авле

но к

лиен

ту

Пост

упил

о пи

сьм

о от

кли

ента

с

вопр

осам

и по

ТКП

Пра

виль

но

Отп

рави

ть те

хник

о-ко

мм

ерче

ское

пре

длож

ение

(Т

КП) к

лиен

ту

Подг

отов

ить

отве

т на

воп

росы

кли

ента

по

ТКП

Непр

авил

ьно

—

в ра

мка

х про

цесс

а во

зник

ает

прер

ыва

ние,

кот

орое

в д

анно

м

вари

анте

схе

мы

визу

альн

о не

опи

сано

Запр

ос к

лиен

та н

а по

став

куоб

оруд

ован

ияПо

ступ

ил з

апро

с от

кли

ента

на

пос

тавк

у обо

рудо

вани

я

ТКП

для

клие

нта

Пись

мо

от к

лиен

та п

о ТК

П

ТКП

для

клие

нта

Глава 4. Описание бизнес-процессов организации 261Блок «Решение» используется на схемах процессов в качестве

логического оператора (gateway). Обратите внимание, что «Реше-ние» в Business Studio обладает всеми атрибутами класса «Процесс», но не может быть декомпозировано на следующий уровень.

Блок «Решение» именуется при помощи существительного. При-меры:

«Проверка принятого решения»; —

«Проверка применимости условий типового предложения»; —

«Сравнение величины запрашиваемой скидки с возможной»; —

«Определение соответствия классификатору…». —

На рис. 4.6.12 показаны правильные и неправильные варианты применения на схеме процесса блока «Решение».

Блок «Решение» необходимо использовать на схеме процесса при возникновении ситуации, требующей применения оператора исклю-чающего логического «ИЛИ» (рис. 4.6.12, ситуация 1). В случае при-менения блока «Решение» необходимо дополнительно использовать стрелку «Поток объектов» для описания информационного потока между операциями процесса (если он существует). Ситуация 2 некор-ректна в части именования блока «Решение» и стрелок. Ситуация 3 некорректна, так как требовалось применение блока «Решение».

Для упрощения графической схемы в Business Studio* блок «Ре-шение» не используется при возникновении ситуации, требующей применения оператора исключающего логического «ИЛИ» при объ-единении двух веток процесса (ситуация 4), а также оператора «И» (ситуация 5).

Для моделирования межпроцессного взаимодействия в Business Studio используют междиаграммные ссылки.

К ним могут быть привязаны как стрелки типа «Поток объектов», так и стрелки «Связь предшествования».

На рис. 4.6.13 показаны правильные и неправильные варианты применения на схеме процесса междиаграммных ссылок.

* В других нотациях это не так.

Рис. 4.6.12. Использование блока «Решение»

Выполнить классификацию запроса

клиента

... ...

Информация о типе запроса клиента

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

Запрос клиента на оказание услуг

Запр

ос к

лиен

та

Запрос клиента на поставку оборудования

1. Правильно

Выполнить классификацию запроса

клиента

... ...

Запрос на оборудование

Нет

Запр

ос к

лиен

та

Да

2. Неправильно — несколько ошибок: 1) не именована стрелка до «Решения»; 2) некорректное наименование «Решения»;

3) абстрактные имена у стрелок после «Решения»

4. Правильно — при слиянии потоков в ситуации, требующей применения исключающего логического «ИЛИ»,

блок «Решение» не используется

... ...

...

ТКП для клиентасогласовано

ТКП для клиентане согласовано

5. Правильно — в случае возникновения ситуации, требующей применения логического «И», блок «Решение»

не используется

... ...

Принять решение по премированию

персонала

Принято решение выдать премии

Принято решение подарить ценные подарки

3. Неправильно — не использован блок «Решение» в случае возникновения ситуации применения

исключающего логического «ИЛИ»

... ...

Выполнить классификацию запроса клиента

Запрос клиентана оказание услуг

Запрос клиента на поставку оборудования

Рис. 4.6.13. Использование междиаграммных ссылок

Правильно

Операция

Процесс...

Правильно

Операция

Процесс...

Договор на поставку оборудования

Неправильно — стрелка типа «поток объектов» не может быть именована

в терминах действия/события

Операция

Процесс...

Заключен договор на...

Неправильно — стрелка не присоединена к операции

Операция

Процесс...


Неправильно — стрелка не присоединена к ссылке

Операция

Процесс...


Неправильно — стрелка типа «Cвязь предшествования» не может быть именована

в терминах информации/документа

Операция

Процесс...


Неправильно — стрелка не присоединена к ссылке

Неправильно — стрелка не присоединена к операции

Операция

Процесс...

Операция

Процесс...





Если по смыслу модели нужно указать, что процессы обмени-ваются информацией/документами, то к междиаграммной ссылке привязывается стрелка типа «Поток объектов». Если следует указать, что процессы выполняются последовательно, то к междиаграммной ссылке привязывается стрелка типа «Связь предшествования».

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

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

Схема процесса в нотации «Процедура» при кажущейся простоте весьма информативна и удобна для описания. Можно сформулиро-вать следующие преимущества этой нотации (в случае ее использо-вания в Business Studio):

представлен минимально необходимый набор графических —элементов для описания процессов типа Work Flow (поток работ);

быстрота создания графических схем для целей регламентации; —

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

схемы процессов просты и понятны всем сотрудникам даже —без специального обучения;

Глава 4. Описание бизнес-процессов организации 265простота в обучении (нет необходимости привлекать дорого- —стоящих специалистов со стороны — обучение можно прово-дить силами сотрудников отдела организационного развития);

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

можно выгружать и редактировать схемы в MS Visio (при не- —обходимости).

Среда моделирования Business Studio позволяет быстро создавать процессную модель компании. Информацию о процессах можно вы-гружать из системы в виде регламентирующих документов в требуе-мом формате.

В этом параграфе я привел описание требований к стандартному использованию нотации «Процедура» Business Studio. Но при созда-нии корпоративного стандарта описания процессов вы можете раз-работать свои правила применения этой нотации. Хочу подчеркнуть, что не бывает идеальных нотаций и стандартов их применения. Важ-но сделать свой, понятный всем внутренний стандарт описания, опро-бовать его на практике, а затем использовать в текущей деятельности.

4.7. Информативность графических схем процессов

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


«Простая блок-схема» (с отображением движения докумен- —тов, с использованием блока «решение»);

«Простая блока-схема» (без отображения движения докумен- —тов, без использования блоков «Решение»);

«Процедура» системы Business Studio (один из возможных ва- —риантов представления);

ARIS eEPC. —

В качестве тестового примера я выбрал простой и понятный про-цесс. Результаты его описания представлены на рис. 4.7.1–4.7.5.

На рис. 4.7.1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение доку-ментов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых зависит последующий ход процесса. Такой под-ход к использованию ромбиков — весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных вы-ходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не оче-видна. Что это за объекты — операции процесса, события? Вроде бы ни то ни другое. Это, скорее, операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В ком-пьютерной программе ромбик был бы полноценной операцией срав-нения условий. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информаци-онные системы. Задумайтесь, корректно ли показывать ромбики от-дельно от операции процесса на схеме? Вместо этого можно:

описать логику принятия решения в виде последовательно- —сти операций на схеме рассматриваемого процесса;

описать логику в виде схемы шагов соответствующего под- —процесса, переходя на уровень ниже;

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

Рис. 4.7.1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)

Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день

Диспетчер Начальник отдела Менеджер по закупке

График согласован?

Блок «Решение»

Ежедневно вечером с 19.00 до 21.00


Событие

Сформировать отчет по недоставленным

товарам

Сформировать отчет по инкассации за день

Выполнить анализ отчета

Выполнить корректировку

графика доставки

Расформировать заказ

Согласовать график доставки Операция процесса

Получить информацию о согласовании графика

доставки

Сформировать/скоррек-тировать график доставки

на следующий день

Отчет по недоставленным товарам в MS Excel

Комплект отчетов

Требования по срокам передоставки

Информация по передоставкам

График доставки на следующий день

Информация о согласовании графика

доставки

Информация в электронной форме

Информация по расформированию

заказов

Стрелка предшествования

Стрелка потока документов/информации

Нужно ли выносить описание логики принятия решений из операции?

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

Да

Да

Да

Нет

Нет

Нет

Передоставка возможна?

Все заказы доставлены в срок?


Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) спо-соба использования ромбиков.

Простая блок-схема в MS Visio (с движением документов, с использованием блока «Решение»)

Плюс Минус

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

Вынос логики принятия решения за пределы 1. операции процесса (некорректно с точки зре-ния формальной декомпозиции процессов).Неудобства при документировании процесса 2. (приходится дублировать ромбики текстом при формировании текстового описания операции).Схема процесса перегружена информацией.3. Ромбики часто используются слишком фор-4. мально, без реальной необходимости

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

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

Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение»)

Плюс Минус

Простота и наглядность для исполнителя.1. На лист можно поместить больше информа-2. ции, чем в случае формата, использованного на рис. 4.7.1

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






товарам


Выполнить анализ отчета




Согласовать график доставки

Получить информацию о согласовании графика

доставки



Отчет по недоставленным товарам


Комплект отчетов(недоставленные товары, отчет по инкассации)

Информация об отсутствии замечаний по отчету

Информация по расформированию заказов

Информация по передоставкам заказов

Информация по передоставкам

Информация по расформированию

заказов

Информация для корректировки графика

Информация о согласовании графика доставки

Рис. 4.7.2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)

Событие

Операция процесса

Универсальная стрелка связи


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

На рис. 4.7.3 показана схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет не-сколько особенностей. Во-первых, блоки «Решение»* использованы нестандартным образом — не как графический элемент для отобра-жения ветвления (оператор логики, развилка, гейтвей), а как полно-ценная операция процесса, связанная с принятием решений. Исполь-зование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую инфор-мацию: описание, начало, завершение, требование к срокам и т. п.

Вторая особенность схемы процесса на рис. 4.7.3 — применение стрелок. Для отображения последовательности операций полезно ис-пользовать стрелку с одним наконечником — стрелку «Связь пред-шествования». Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок — стрелками «Связь пред-шествования», а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графиче-ских элементов на схеме процесса и при этом вывести в регламент про-цесса необходимую информацию о входящих и исходящих документах.

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

Тот факт, что название стрелки в Business Studio не зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятным и удобным для сотрудников образом. Напри-мер, к стрелке предшествования «Подготовлен комплект отчетов»

* В Business Studio ромбик обладает почти всеми атрибутами полноценного про-цесса, но не может быть декомпозирован. Это нужно иметь в виду при описании процессов в этой системе. В параграфе 4.6 я как раз не рекомендую использо-вать «Решение» как полноценную операцию.

Рис. 4.7.3. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»)







товарам





Получить информацию о согласовании




Подготовлен отчет по недоставленным заказам

Отч

ет п

о не

дост

авле

нны

м

зака

зам

Подготовлен комплект отчетов

Требуется передоставка заказов

Требуется расформирование заказов

Замечаний по отчету и пожеланий нет


Информация для корректировки графика

Информация о согласовании графика

Инф

орм

ация

по

пер

едос

тавк

ам

Один из возможных вариантов («А») использования блока «Решение».

Недостаток варианта в том, что блок «Решение» нельзя декомпозировать

Можно показать поток документов в виде отдельного типа стрелок либо привязать конкретные документы к стрелкам предшествования

Комплект отчетов (недоставленные товары, отчет по инкассации)

Можно по-разному именовать стрелки для повышения информативности схемы

Информация о расформировании заказов

Выполнить анализ отчетов


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

Плюсы и минусы графического представления процесса на рис. 4.7.3 показаны ниже.

Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»)

Плюс Минус

Простота представления.1. Акцентирование внимания исполнителя 2. на операции, связанной с принятием реше-ния/ветвлением процесса.На листе формата А4 может располагаться 3. большой объем информации

Блок «Решение» не декомпозируется.1. Неоднозначность в именовании стрелок 2. (возможны разночтения)

Обратите внимание, что в Business Studio нотация «Процедура» может использоваться по-разному.

На рис. 4.7.4 представлена схема рассматриваемого процесса, раз-работанная в нотации ARIS eEPC. Замечу, что в схему не помести-лись некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре опе-ратора логики и восемь событий. Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика.

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

* СТУ — «Современные технологии управления» (г. Самара) — разработчик Business Studio.

Рис. 4.7.4. Схема процесса в нотации ARIS eEPC (сформирована в Business Studio)

OR — неисключающее логическое «ИЛИ»; XOR — исключающее логическое «ИЛИ».


товарам

Сформировать отчет по инкассации

за день

Выполнить анализ отчетов

XOR

XOR

OR

OR




Диспетчер

Диспетчер

Менеджер по закупке

выполняет

выполняет

выполняет

выполняет

выполняет

ДиспетчерВыполнить

корректировку графика доставки

выполняет Диспетчер


выполняет Начальник отдела

Диспетчер

Комплект отчетов

График доставки на следующи день

Требованияпо передоставке

Требованияпо расформированию

заказов

Ежедневно вечером

с 19.00 до 21.00

Сформирован комплект отчетов

Необходимо расформировать

заказ

Необходима передоставка

Передоставки учтены в графике

доставок

Сформирован график доставки


Все заказы доставлены

в срок

Заказырасформированы

Отчет по недоставленным

товарам сформирован


Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Плюс Минус

При формировании схемы выдерживается 1. строгая, формальная логика процесса.Четко определены все события, возникающие 2. по ходу процесса

Сложность восприятия.1. Трудоемкость формирования схемы.2. У сотрудников должны быть специальные на-3. выки и опыт интерпретации подобных схем.Информационная избыточность.4. Занимает слишком много места, что неудобно 5. для документирования

На рис. 4.7.5 изображен тот же процесс в нотации BPMN. Как видим, этот рисунок похож на рис. 4.7.1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплош-ные линии, потоки данных — пунктирные.

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

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

трудностям при интерпретации схем рядовыми сотрудниками; —

невозможности (сложности) организации работ по описанию —процессов силами сотрудников подразделений, не прошед-ших специальное обучение;

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


товарам

Сформировать отчет по инкассации

за день

Скорректировать график доставки

Сформировать график доставки

График согласован

Задача



Проанализировать отчеты


Развилка Данные

СтопСтарт

Отчет по инкассации

за день

График доставки

Ежедневно в 19.00

да

нет

нетда

Возможна передоставка?

нет

да

Отчет по недоставленным

товарам

Требования по передоставке

Все заказы доставлены в срок?

Согласован?

Рис. 4.7.5. Схема процесса в нотации BPMN 2.0


значительному увеличению трудозатрат бизнес-аналитиков —на формирование схем;

дополнительным сложностям при документировании схем —(например, большой объем).

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

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

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

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

Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск). Описание процессов вы-полнено в среде моделирования Business Studio. На рисунке слева видно дерево процессов, в котором процессы управления структу-рированы по соответствующим контурам.

Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Business Studio, но в рамках предложенной задачи ее ис-пользование вполне адекватно.

Documents

Структурные модели процессов организацииkm.mmf.bsu.by/courses/2016/bp/repin.pdf · магазинов магазинов Магазин как