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

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

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

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

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

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