Книга Бизнес-процессы. Моделирование, внедрение, управление, страница 54 – Владимир Репин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ARIS eEPC.

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

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

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

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