Еще раз о моделировании бизнес-процессов

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

Продолжаем обсуждение публикации Павла Сахарова в ноябрьском номере «Директора». Приводим мнение одного из наших читателей по этой проблеме

Алексей Агапов — технический директор компании «Лаборатория НТР». Ему можно написать по электронной почте: aas@ntrlab.ru

Когда я прочел статью Павла Сахарова и попытался ему возразить, то обнаружил, что для меня не так очевиден его основной тезис, несмотря на то, что он, казалось бы, четко сформулирован. Пытался ли автор доказать, что Rational Rose как инструментальное средство менее удобно при моделировании бизнес-процессов, чем BPwin, как это явствует из заглавия его статьи? Если так, то возражать неинтересно и, более того, бессмысленно, так как выбор средства — это, вообще говоря, дело вкуса. На самом же деле многие его аргументы направлены не против Rational Rose как средства, а против нотации UML и объектно-ориентированного подхода к моделированию в целом. Спрашивается тогда, а является ли нотация UML безусловно лучше (или хуже) для целей моделирования бизнес-процессов? Является ли объектно-ориентированный метод безусловно более (или менее) подходящим для этого? Конечно, нет, все зависит от тех условий, в которых проводится моделирование, и от целей, с которыми оно проводится.

Таким образом, при выборе средств моделирования бизнес-процессов мы должны исходить из конкретной ситуации, в которой будет проводиться моделирование, причем учитывать требования, предъявляемые в этой ситуации отдельно к методу моделирования, отдельно к нотации, применяемой при моделировании, и отдельно — к выбору инструментального средства моделирования. Если при дальнейшем обсуждении придерживаться этого подхода, можно избежать многих недоразумений и недопонимания.

В аргументах, которые автор приводит в доказательство преимущества IDEF0 и BPWin, надо обратить внимание на фактические неточности, касающиеся UML и Rational Rose. Например, нельзя согласиться с такими утверждениями, как «Rational Rose не поддерживает ни одну из известных методологий моделирования», «диаграммам UML не дается никакой интерпретации», а также предложение подкрашивать стрелки на диаграммах различными цветами, чтобы имитировать различные виды входов. Можно было бы сразу сказать, что семантика UML определена в его спецификации [3], а механизмы расширения языка [4] позволяют строго определить нотацию для бизнес-моделирования [5].

Однако я бы хотел обратить внимание на положения статьи, спорность которых не столь очевидна. В качестве основного преимущества IDEF0 и BPWin перед UML и Rational Rose автор называет возможность автоматической проверки получаемой модели на корректность с точки зрения формального синтаксиса. Но является ли на самом деле формальная корректность основным требованием к модели бизнес-процессов?

Обратимся к аналогии с программированием. Любая система программирования предоставляет средства для формальной проверки синтаксиса программ. Необходимость этого очевидна — ведь программы исполняются машинами. Однако, как известно, основной проблемой при программировании является достижение не формальной, а содержательной правильности программы. Этого добиваются, делая программы понятными для людей, а не только для машин. Для этого разрабатываются новые языки программирования, имеющие все более мощные выразительные средства.

Аналогично при моделировании бизнес-процессов основным требованием является содержательная правильность модели, которая может быть достигнута только за счет ее понятности. Корректность же с точки зрения формального синтаксиса не так важна, поскольку модели предназначены для чтения прежде всего людьми, а не машинами. Для повышения понятности моделей разрабатываются новые языки моделирования, которые имеют все более развитые выразительные средства.

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

Требования к модели бизнес-процессов

Моделирование бизнес-процессов можно выполнять с применением различных подходов, методологий, нотаций и инструментальных средств — в зависимости от требований к модели в каждом конкретном случае. Чем определяются эти требования? Во многом — процессом создания системы автоматизации в целом, в рамках которого проводится моделирование предметной области. Этот процесс определяет, каким образом будет строиться, уточняться и использоваться модель.

Как правило, система создается коллективом людей. Эти люди имеют различные специальности, опыт, привычки, образование, предпочтения и личные качества. Модель бизнес-процессов строится для того, чтобы эти люди могли эффективно обмениваться знаниями и совместно принимать решения по ходу создания системы. Модель является языком общения между сторонами, участвующими в создании системы автоматизации, — заказчиками, экспертами, архитекторами и т. д. Она должна быть организована таким образом, чтобы каждая сторона, воспринимающая моделируемую систему с собственной точки зрения, могла эффективно вносить свой вклад в общее понимание предметной области. Подмножество модели, показывающее систему с той или иной точки зрения, должно быть логически замкнутым.

Процесс создания автоматизированной системы часто оказывается итеративным, поэтому модель должна допускать последовательные уточнения. В идеале модель должна строиться таким образом, чтобы при ее детализации не изменялись ранее построенные более общие элементы модели, а только добавлялись бы новые.

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

Рассмотрим теперь, как, пользуясь объектным подходом, можно построить модель, удовлетворяющую этим требованиям.

Подход к моделированию

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

При объектном подходе к моделированию одним из основных средств описания действительности являются use cases (UC, часто переводится как «варианты использования»). Однако часто под UC понимают лишь эллипс на UC-диаграмме UML. Нередко при помощи UC-диаграмм пытаются описать динамические аспекты моделируемой системы, например сценарии взаимодействия участников системы. Когда это плохо удается, говорят, что UC плохо подходят для описания процессов.

Что же такое UC? При описании какой-либо программной системы UC часто соответствует режиму или экрану пользовательского интерфейса. Чем же является UC при описании системы бизнес-процессов? В [1] UC определяется как совокупность всех вариантов поведения системы в ответ на запрос некоторого участника процесса, преследующего этим конкретную цель. UC-модель, таким образом, представляет собой систему взаимосвязанных целей участников процесса и является основой для организации всей модели описываемой системы бизнес-процессов. UC-диаграммы являются частными взглядами на UC-модель и показывают взаимосвязи между участниками процесса и их целями.

На рис. 1 в качестве примера приведена часть UC-модели, которая могла бы быть результатом моделирования работы кредитного отдела банка. Она состоит из основного UC «Воспользоваться банковским кредитом» (UC1) и связанного с ним UC «Принять решение о предоставлении кредита» (UC2). На рис. 2 показаны примеры UC-диаграмм, иллюстрирующих частные взгляды на UC-модель с точки зрения выдачи кредита и его погашения.

Как видно из рис. 1, каждый UC указывает основное действующее лицо — участника процесса, преследующего некоторую цель и инициировавшего для этого взаимодействие с системой. Например, клиент, желающий получить в банке кредит, является основным действующим лицом в UC1 «Воспользоваться банковским кредитом».

Рис. 1. Часть UC-модели кредитного отдела банка

Кроме того, UC содержит совокупность всевозможных сценариев, которые могут последовать при достижении действующим лицом своей цели. При этом единственный основной сценарий соответствует нормальному развитию событий, то есть такому, при котором не возникает никаких нештатных ситуаций. Например, в UC1 «Воспользоваться банковским кредитом» основным является сценарий, при котором банк дает положительное решение о предоставлении кредита, клиент получает кредит, а затем погашает его по установленному графику. Альтернативные сценарии начинаются так же, как и основной, но в какой-то момент развитие событий идет по другому пути. В нашем примере это может быть сценарий, при котором клиент не выплачивает очередной взнос, предусмотренный графиком погашения кредита (рис. 1, UC1, п. 2.2). При этом опять же вероятны альтернативные сценарии более низких уровней. Так, если клиент в течение льготного срока восстанавливает график погашения, то сценарий воссоединяется с основным сценарием, если же клиент не выплачивает задолженность, кредит считается просроченным и т. д.

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

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

Модель бизнес-процессов, помимо UC и действующих лиц, может содержать и другие элементы, помогающие лучше понять предметную область или обосновывать те или иные модельные решения. Описание UC1, например, ссылается на формы документов (пп. 1.1 и 1.3) и на бизнес-правила (п. 2.2.2).

Моделирование на основе UC, на мой взгляд, лучше способствует также пониманию модели бизнес-процессов людьми, которым предстоит ее читать, рецензировать и исправлять, развивать и, наконец, пользоваться ею. Цели участников бизнес-процессов являются своего рода движущей силой, и человеку, читающему модель, легко представить себе, что именно требуется сделать, чтобы достичь той или иной цели. В то же время из структуры процессов, получаемой структурными методами моделирования, бывает трудно понять, зачем применяется тот или иной процесс, а также увидеть недостатки модели или самого бизнес-процесса — нужна ли эта функция, можно ли ее заменить другой и чьи интересы это затронет.

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

Нотация представления моделей

Следуя предложенной ранее структуре, рассмотрим теперь способы представления моделей — нотации. В нотации UML для представления UC-моделей чаще всего используются UC-диаграммы, а также диаграммы деятельности и диаграммы последовательности (activity- и sequence-диаграммы соответственно). Часто возникают споры о выразительных возможностях этих диаграмм.

Пожалуй, больше всего нареканий вызывают UC-диаграммы как наименее выразительные. Однако, на мой взгляд, это происходит из-за того, что во многих учебниках по объектно-ориентированному моделированию эти диаграммы затронуты лишь вскользь, приведены лишь примитивные примеры и не объяснено, что же именно изображают эти диаграммы.

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

Для отображения последовательности действий служат диаграммы деятельности и последовательности. Первые являются разновидностью блок-схем. С их помощью в принципе можно отобразить UC целиком, включая основной и все альтернативные сценарии. Диаграммы последовательности применяются для иллюстрации какого-то отдельного сценария. Обе эти диаграммы имеют свои аналоги в структурных методах. Судить об их выразительности — это спорить о вкусах, нужно только принимать во внимание, что в UML заложены механизмы расширения, позволяющие доопределять семантику стандартных элементов диаграмм. Раскрашивать диаграммы при этом совершенно не обязательно. С помощью доопределенной семантики можно строить формальные модели, проверять их на полноту и непротиворечивость — подобно тому, как это делается для нотаций, применяемых в других методах.

Для представления сценариев, входящих в UC, можно выбирать любые другие способы. Мне кажется, что в большинстве случаев одни только диаграммы не могут ясно отобразить совокупность сценариев в сложных UC, даже если для описания одного UC использовать несколько диаграмм. Более подходящим способом представления событий, образующих UC, является не диаграмма, а структурированный текст. Пример такого текстового описания приведен на рис. 1. Подобный подход описан, в частности, в [1], а также используется в RUP [2]. Формально это можно делать не выходя за рамки UML, так как любые текстовые описания по стандарту также являются элементами языка. Тем не менее диаграммы могут применяться для иллюстрации каких-нибудь особенно важных для понимания или наиболее запутанных моментов.

Инструментальные средства

Проводить сравнение инструментальных средств, поддерживающих тот или иной подход, ту или иную нотацию, довольно трудно. Я готов согласиться с критиками Rational Rose, что это средство не является ни лучшим, ни вообще достаточным инструментом для моделирования в целом и моделирования бизнес-процессов в частности. Дело здесь, видимо, и в том, что средства, поддерживающие структурные подходы, развивались уже много лет, а объектно-ориентированные средства моделирования еще достаточно молоды. Следует сказать, однако, что принципиальных препятствий к созданию средств, осуществляющих формальную проверку UML-моделей на полноту и непротиворечивость, а также получение по моделям различных отчетов, не существует.

Удобным, на мой взгляд, способом организации как текстовых описаний UC, так и диаграмм является репозитарий — система хранения документов, позволяющая создавать гипертекстовые связи между документами. Рис. 1 и 2 показывают, как могли бы выглядеть UC и диаграммы в репозитарии. Синим цветом на этих рисунках выделены гипертекстовые ссылки, связывающие элементы модели между собой. Такая система могла бы не только организовывать и хранить элементы модели, но и строить на основе данных этой модели различные отчеты и проверять модель в соответствии с задаваемыми правилами. Существует успешный опыт организации такого репозитария на базе Lotus Notes.

Заключение

Выбор подхода к моделированию непосредственно зависит от требований к модели, от способа ее использования. Наиболее часто модель бизнес-процессов используется для поддержки совместной работы людей, участвующих в создании автоматизированной системы, для обеспечения коллективного принятия решений. Этой задаче отвечает модель, полученная при правильном применении объектно-ориентированного подхода. Однако выбор такого подхода не навязывает ни выбора какой-либо определенной нотации, ни тем более выбора инструментального средства. Тем не менее нотация UML может быть эффективно использована наряду с другими способами представления, например структурированным текстом. Что касается инструментальных средств, то тут, к сожалению, я не знаю средств объектно-ориентированного моделирования, которые были бы так же удобны в использовании, как известные средства, поддерживающие структурные методы.

Литература