Диаграммы для 
описания бизнес-процессов
Сейчас мы обсудим: как графически 
изображать бизнес-процессы на диаграммах 
(рисунках), какую графическую нотацию 
выбрать, и для чего можно использовать 
созданные диаграммы.
Для наших последующих 
рассуждений важно уточнить, что 
мы говорим об описании не любых 
процессов, а именно процессов "уровня 
бизнеса", которые:
  - знакомы нашему Клиенту (конечным пользователям автоматизированной информационной системы, далее называемой Системой);
 
  - оперируют понятиями предметной области Клиента ("покупатель", "заказ", "оплата" и т.п.).
 
В "разряд" бизнес-процессов 
не попадают, в частности, процессы, 
описывающие: техническую реализацию 
Системы и взаимодействие её компонентов 
("серверов", "баз данных", 
"классов", "объектов" и т.п.).
Хочу сразу сказать, что 
текстовое и графическое представления 
не нужно рассматривать как взаимоисключающие 
альтернативы: они дополняют друг 
друга. С одной стороны, на диаграмме 
в принципе удаётся разместить существенно 
меньше информации, в т.ч. пояснений, 
чем в текстовом документе. А 
с другой стороны: графическое представление 
обладает большей наглядностью, помогая 
понять сложную логику и увидеть 
общую картину процесса.
Мы подходим к тому, что 
перед тем, как обсуждать различные 
варианты графических описаний, нужно 
определиться с целями, которые мы 
ходим достигнуть, начиная "рисовать" 
процессы.
Описание бизнес-процессов 
как один из этапов автоматизации.
Необходимость создания описаний 
бизнес-процессов может возникнуть 
в любой области человеческой 
деятельности, в том числе и 
там, где об автоматизированных системах 
только слышали. Но поскольку современный 
бизнес немыслим без его автоматизации, 
поэтому любое описание бизнес-процессов 
рано или поздно, непосредственно 
или в результате цепочки действий, 
будет отражено (воплощено, реализовано) 
в автоматизированной системе.
В настоящее время индустрия 
информационных технологий обладает множеством 
объектов в виде спецификаций, дающие 
методы описания бизнес-процессов (и 
соответствующие диаграммы), реализует 
возможность автоматизированных систем 
исполнять бизнес-процессы. Сегодня 
существуют не только коммерческие "движки 
исполнения бизнес-процессов", но и 
аналогичные продукты, распространяемые 
сообществом Open Source, что делает исполнение 
бизнес-процессов Системой доступным 
для всех. Это позволяет сократить время 
и затраты на автоматизацию и т.п..
Цели
1. Во-первых, мы хотим получить 
рисунки ("блок-схемы"...), которые 
мы сможем использовать во 
время презентаций и обсуждений, 
а также которыми мы снабдим 
(дополним) текстовые документы, 
описывающие процессы.К этим рисункам 
(диаграммам) мы предъявляем следующие 
требования:
  - Они должны достаточно подробно и точно описывать логику процесса. Настолько подробно и точно, насколько это нам нужно в каждом конкретном случае. При этом для различных сочетаний требований к "подробности и точности" мы хотим использовать одни и те же диаграммы.
 
  - Они должны быть понятны, причём одинаково, различными людьми, заинтересованными в работе с этими рисунками. В идеале, любой человек, знакомый со способом описания процесса, должен правильно понимать то, что мы изобразили.
 
2. Во-вторых, мы хотим получить 
от результата нашего труда 
нечто большее, чем просто рисунки: 
мы хотим построить "модель" 
процессов, из которой можно 
получить не только рисунки, 
но и, например, текстовые отчёты 
о составе модели и т.п. Поэтому 
для описания процесса мы уже 
используем не карандаш и бумагу 
или их компьютерный аналог: программу 
- "рисовалку" типа Adobe Photoshop, - а специальное 
"инструментальное средство моделирования". 
Традиционно под этим термином известны 
продукты ARISи BPWin.
А теперь поподробнее: так 
что же конкретно "большее" мы 
хотим получить от модели бизнес-процессов:
  - Модель должна позволять автоматически создавать отчёты о её составе (например, для оценки затрат на разработку Системы).
 
  - Она должна допускать автоматическую проверку по формальным признакам: в частности, проверку корректности использования элементов модели, логики их связей, полноты модели.
 
  - Она должна обеспечивать возможность электронного обмена моделями и диаграммами (а не только "картинками") между различными инструментальными средствами моделирования (а, следовательно, и между людьми), а также передачу их в Систему.
 
  - Она должна быть достаточно полной и строгой для автоматизированного исполнения соответствующего бизнес-процесса (проигрывания его сценариев).
 
  - Иметь обратную связь от Системы: при внесении в Систему изменений (в т.ч. уточнений), они должны автоматически отражаться в модели.
 
Без обратной связи от Системы 
модель постепенно отстаёт от того, 
что работает в Системе на самом 
деле, и поэтому модель "умирает": 
становится неактуальной, а потому 
- ненужной.