На рис. 4.7.1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов – при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых зависит последующий ход процесса. Такой подход к использованию ромбиков – весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты – операции процесса, события? Вроде бы ни то ни другое. Это, скорее, операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Но на схеме процесса нужно показывать реальные объекты – процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме? Вместо этого можно:
• описать логику принятия решения в виде последовательности операций на схеме рассматриваемого процесса;
• описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
• описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.
Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) способа использования ромбиков.
1. Наглядное отображение логики выбора тех или иных выходов процесса.
2. Акцентирование внимания исполнителя на точке принятия решения/ветвление процесса в зависимости от условий
3. Схема процесса перегружена информацией.
1. Вынос логики принятия решения за пределы операции процесса (некорректно с точки зрения формальной декомпозиции процессов).
2. Неудобства при документировании процесса (приходится дублировать ромбики текстом при формировании текстового описания операции).
3. Ромбики часто используются слишком формально, без реальной необходимости
На рис. 4.7.2 приведен пример того же процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на рис. 4.7.1. Схема на рис. 4.7.2 выглядит гораздо проще: от графических элементов не рябит в глазах, а с точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, то, комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. (Еще раз замечу: не вся информация о процессе должна быть представлена на его графической схеме. При работе с объектной моделью значительная часть сведений хранится в виде атрибутов объектов в базе данных.)
Рис. 4.7.2.
Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)Плюсы и минусы графического изображения процесса в форме, представленной на рис. 4.7.2, показаны ниже.
1. Простота и наглядность для исполнителя.
2. На лист можно поместить больше информации, чем в случае формата, использованного на рис. 4.7.1
1. Логика принятия решений скрыта внутри операций процесса.
2. Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса