4.7. Информативность графических схем процессов
4.7. Информативность графических схем процессов
Одна из важнейших целей формирования графических схем процессов – их последующее использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, не обученные сложным нотациям, не имеющие навыков системного анализа. Для них очень важны простота и наглядность схем. Сложные, запутанные схемы, содержащие массу условных обозначений, плохо воспринимаются, и это затрудняет их практическое использование. Поэтому очень важен корректный выбор и использование нотации описания процессов. По каким критериям следует выбирать, как сравнивать разные нотации между собой? Рассмотрим следующие популярные нотации и попытаемся ответить на эти вопросы:
• «Простая блок-схема» (с отображением движения документов, с использованием блока «решение»);
• «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
• «Процедура» системы Business Studio (один из возможных вариантов представления);
• ARIS eEPC.
В качестве тестового примера я выбрал простой и понятный процесс. Результаты его описания представлены на рис. 4.7.1–4.7.5.
Рис. 4.7.1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)
Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день
На рис. 4.7.1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов – при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых зависит последующий ход процесса. Такой подход к использованию ромбиков – весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты – операции процесса, события? Вроде бы ни то ни другое. Это, скорее, операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Но на схеме процесса нужно показывать реальные объекты – процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме? Вместо этого можно:
• описать логику принятия решения в виде последовательности операций на схеме рассматриваемого процесса;
• описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
• описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.
Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) способа использования ромбиков.
Простая блок-схема в MS Visio (с движением документов, с использованием блока «Решение»)
Плюс
1. Наглядное отображение логики выбора тех или иных выходов процесса.
2. Акцентирование внимания исполнителя на точке принятия решения/ветвление процесса в зависимости от условий
3. Схема процесса перегружена информацией.
Минус
1. Вынос логики принятия решения за пределы операции процесса (некорректно с точки зрения формальной декомпозиции процессов).
2. Неудобства при документировании процесса (приходится дублировать ромбики текстом при формировании текстового описания операции).
3. Ромбики часто используются слишком формально, без реальной необходимости
На рис. 4.7.2 приведен пример того же процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на рис. 4.7.1. Схема на рис. 4.7.2 выглядит гораздо проще: от графических элементов не рябит в глазах, а с точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, то, комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. (Еще раз замечу: не вся информация о процессе должна быть представлена на его графической схеме. При работе с объектной моделью значительная часть сведений хранится в виде атрибутов объектов в базе данных.)
Рис. 4.7.2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)
Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день
Плюсы и минусы графического изображения процесса в форме, представленной на рис. 4.7.2, показаны ниже.
Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение»)
Плюс
1. Простота и наглядность для исполнителя.
2. На лист можно поместить больше информации, чем в случае формата, использованного на рис. 4.7.1
Минус
1. Логика принятия решений скрыта внутри операций процесса.
2. Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса
Применение схем в таком же формате, как представленный на рис. 4.7.2, удобно как для разработчиков (бизнес-аналитиков), так и для сотрудников.
На рис. 4.7.3 показана схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение»[101] использованы нестандартным образом – не как графический элемент для отображения ветвления (оператор логики, развилка, гейтвей), а как полноценная операция процесса, связанная с принятием решений. Использование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.
Рис. 4.7.3. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»)
Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день
Вторая особенность схемы процесса на рис. 4.7.3 – применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником – стрелку «Связь предшествования». Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок – стрелками «Связь предшествования», а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах.
Таким образом, не загромождая схему лишними элементами, мы можем полностью описать процесс и выгрузить в регламент всю необходимую информацию.
Тот факт, что название стрелки в Business Studio не зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, – «Сформировать отчет по инкассации за день». (Замечу, что в методологии компании СТУ[102] стрелка после операции процесса – это сущность, а не событие. После блока «Решение» можно показывать его возможные результаты.)
Плюсы и минусы графического представления процесса на рис. 4.7.3 показаны ниже.
Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»)
Плюс
1. Простота представления.
2. Акцентирование внимания исполнителя на операции, связанной с принятием решения/ветвлением процесса.
3. На листе формата А4 может располагаться большой объем информации (возможны разночтения)
Минус
1. Блок «Решение» не декомпозируется.
2. Неоднозначность в именовании стрелок
Обратите внимание, что в Business Studio нотация «Процедура» может использоваться по-разному.
На рис. 4.7.4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Замечу, что в схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий. Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика.
Рис. 4.7.4. Схема процесса в нотации ARIS eEPC (сформирована в Business Studio)
OR – неисключающее логическое «ИЛИ»; XOR – исключающее логическое «ИЛИ».
Замечу, что схема процесса в нотации ARIS eEPC занимает намного больше места, чем схемы на предыдущих рисунках. Трудоемкость ее формирования также гораздо выше.
Схема процесса в нотации ARIS eEPC (построена в Business Studio)
Плюс
1. При формировании схемы выдерживается строгая, формальная логика процесса.
2. Четко определены все события, возникающие по ходу процесса
Минус
1. Сложность восприятия.
2. Трудоемкость формирования схемы.
3. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем.
4. Информационная избыточность.
5. Занимает слишком много места, что неудобно для документирования
На рис. 4.7.5 изображен тот же процесс в нотации BPMN. Как видим, этот рисунок похож на рис. 4.7.1: в нотации BPMN задачи изображаются прямоугольниками, развилки – ромбами, данные – пиктограммой, похожей на документ. Потоки управления – сплошные линии, потоки данных – пунктирные.
Рис. 4.7.5. Схема процесса в нотации BPMN 2.0
Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: лишь один вид развилок из пяти имеющихся и один вид задач из восьми. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но и несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, это более строгая нотация: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована и на то, что ее будут читать люди, и на непосредственное исполнение специальным программным обеспечением – движком BPM-системы. В то же время, как показывает данный пример, при использовании ограниченного подмножества BPMN оказывается не сложнее привычной блок-схемы.
При описании процессов на операционном уровне нужно стремиться к простоте и понятности схем для сотрудников. Использование сложных нотаций приводит к:
• трудностям при интерпретации схем рядовыми сотрудниками;
• невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
• значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
• дополнительным сложностям при документировании схем (например, большой объем).
Нотация моделирования должна соответствовать уровню процессной культуры организации. Если сотрудники компании делают первые шаги в области описания процессов, то желательно выбрать простую, наглядную и удобную нотацию.
Данный текст является ознакомительным фрагментом.