Диаграммы для описания бизнес-процессов

Диаграммы для  описания бизнес-процессов

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

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

• знакомы нашему Клиенту (конечным пользователям автоматизированной информационной системы, далее называемой Системой);
• оперируют понятиями предметной области Клиента ("покупатель", "заказ", "оплата" и т.п.).

В "разряд" бизнес-процессов  не попадают, в частности, процессы, описывающие: техническую реализацию Системы и взаимодействие её компонентов ("серверов", "баз данных", "классов", "объектов" и т.п.).

Хочу сразу сказать, что  текстовое и графическое представления  не нужно рассматривать как взаимоисключающие  альтернативы: они дополняют друг друга. С одной стороны, на диаграмме  в принципе удаётся разместить существенно  меньше информации, в т.ч. пояснений, чем в текстовом документе. А  с другой стороны: графическое представление  обладает большей наглядностью, помогая  понять сложную логику и увидеть  общую картину процесса.

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

Описание бизнес-процессов  как один из этапов автоматизации.

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

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

Цели

1. Во-первых, мы хотим получить  рисунки ("блок-схемы"...), которые  мы сможем использовать во  время презентаций и обсуждений, а также которыми мы снабдим  (дополним) текстовые документы,  описывающие процессы.К этим рисункам (диаграммам) мы предъявляем следующие требования:

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

2. Во-вторых, мы хотим получить  от результата нашего труда  нечто большее, чем просто рисунки:  мы хотим построить "модель" процессов, из которой можно  получить не только рисунки,  но и, например, текстовые отчёты  о составе модели и т.п. Поэтому  для описания процесса мы уже  используем не карандаш и бумагу  или их компьютерный аналог: программу  - "рисовалку" типа Adobe Photoshop, - а специальное "инструментальное средство моделирования". Традиционно под этим термином известны продукты ARISи BPWin.

А теперь поподробнее: так  что же конкретно "большее" мы хотим получить от модели бизнес-процессов:

• Модель должна позволять автоматически создавать отчёты о её составе (например, для оценки затрат на разработку Системы).
• Она должна допускать автоматическую проверку по формальным признакам: в частности, проверку корректности использования элементов модели, логики их связей, полноты модели.
• Она должна обеспечивать возможность электронного обмена моделями и диаграммами (а не только "картинками") между различными инструментальными средствами моделирования (а, следовательно, и между людьми), а также передачу их в Систему.
• Она должна быть достаточно полной и строгой для автоматизированного исполнения соответствующего бизнес-процесса (проигрывания его сценариев).
• Иметь обратную связь от Системы: при внесении в Систему изменений (в т.ч. уточнений), они должны автоматически отражаться в модели.

Без обратной связи от Системы  модель постепенно отстаёт от того, что работает в Системе на самом  деле, и поэтому модель "умирает": становится неактуальной, а потому - ненужной.