Концепции и языки моделирования

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

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

Основная цель — с одной стороны, представить и разъяснить процедуры на предприятии соответствующими моделями; для этого прежде всего в разделе 3.2 будут обсуждены различные точки зрения на моделирование бизнес-процессов. Цель, кроме того, подвергнуть разработанные таким образом модели тщательному анализу для определения возможностей усовершенствования. Применение сетей Петри (раздел 3.3) также дает возможность провести имитацию процедур, отраженных в процессных моделях, тем самым уже получая оценку эффективности их исполнения на предприятии. Помимо моделирования самих процедур, далее должны быть описаны и смоделированы бизнес-объекты, которые создаются, изменяются или уничтожаются в результате процессов или отдельных действий (см. раздел 3.4). Наконец, структура предприятия в целом также будет учтена при моделировании (раздел 3.5).

3.1. Введение

3.1.1. Моделирование

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

Модели преследуют различные цели. В искусстве, например, понятие модель используется в значении «образец», более или менее точно отображенный в произведении искусства. Схема вязания также служит в качестве образца, к примеру, для вязаного свитера. В информатике модели играют важную роль. Информатика строит системы для решения практических задач. В этом контексте модели представляют собой средство коммуникации в наиболее широком смысле.

Целью моделирования в информационных технологиях может быть:

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

Для моделирования различных аспектов системы существуют различные языки моделирования. Многообразие возможных вариантов простирается от формально-математических, или логических (логика высказываний или логика предикатов), нотаций через графические (как используемые здесь для описания процессов или объектов) и программные (как Java или C#) языки вплоть до разговорных речевых оборотов. В дальнейшем здесь для интересующих нас задач моделирования бизнес-процессов мы будем использовать специальную форму сетей Петри, так называемые XML-сети, так как они имеют точно определенную семантику, одновременно позволяя посредством графического представления осуществлять интуитивно понятное моделирование и точную спецификацию ключевых структур данных.

3.1.2. Имитация

Часто на практике невозможно провести желаемые испытания на реальных системах (например, как ведет себя машина в ситуации определенной ошибки? Корректно ли работают вместе отдельные компоненты? Можно ли соразмерно увеличить рабочую нагрузку, которую система может выдерживать?), будь то по соображениям стоимости или, например, потому, что метод проб и ошибок в реальности влечет за собой неприемлемые риски для окружающей среды (как испытание системы управления реально существующего летящего самолета). В подобных ситуациях помогает имитация: систематическое испытание на основе модели, так называемой имитационной модели, и заданных сценариев, которые могут быть описаны через соответствующие параметры имитационной модели.

В идеальном случае знания, полученные в результате имитации, могут быть непосредственно перенесены в реальную систему. Достоверность имитации зависит от достоверности самой модели, то есть от того, насколько хорошо модель описывает реальность. Строго говоря, имитация позволяет лишь установить невыполнение свойств модели по типу «система всегда функционирует следующим образом…», но не позволяет доказать выполнение подобных утверждений. Таким образом, имитация всегда рассматривает лишь конкретные ситуации: как ведет себя модель для заданного исходного состояния при заданных условиях внешней среды? Поскольку в зависимости от сложности имитационная модель должна абстрагироваться от определенных деталей реальной системы, результат имитации также в большей или меньшей степени отклоняется от соответствующего поведения реальной системы. Из-за сложности поэтому невозможны утверждения типа: «Модель всегда реагирует как предусмотрено». Для этого потребовалось бы в худшем случае бесконечно много запусков имитации.

Для процесса моделирования имитация представляет особый интерес, так как позволяет проиграть конкретные операции процесса, еще даже не приступая к их внедрению. Здесь также обнаруживает себя особое преимущество выбора сетей Петри как инструмента моделирования, а именно возможность выполнения имитации. Далее по ходу книги данный аспект будет проиллюстрирован; как мы увидим, Horus эффективно и результативно поддерживает имитацию процессных моделей.

3.1.3. Анализ

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

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

На практике аналитические и имитационные исследования моделей взаимно дополняют друг друга. Для некоторых особенно критических компонентов или характеристик системы целесообразен анализ, для других свойств имитация более обоснованна. Эти особенности для моделирования процессов будут показаны ниже в данной главе.

3.1.4. Мониторинг

Под мониторингом понимается контроль систем и хода процессов. Так, например, администратор баз данных следит за одной или несколькими системами баз данных в отношении их производительности. Если в процессе работы возникают «узкие места», как, например, интенсивность выполняемых за временной интервал транзакций падает ниже определенного значения, администратор может вмешаться, например увеличив таблицу блокировки.

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

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

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

3.2. Различные аспекты моделирования бизнес-процессов

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

Изучение бизнес-процессов восходит к 1993 году, когда Майкл Хаммер, в то время профессор MIT Sloan — международной бизнес-школы при Массачусетском технологическом институте (MIT Sloan School of Management), и Джеймс Чампи, юрист и бизнес-консультант, опубликовали свою знаменитую книгу «Реинжиниринг корпорации: Манифест революции в бизнесе». Уже в то время в описании, данном Publishers Weekly, говорилось:

В этом ободряющем исследовании консультанты по вопросам управления Хаммер и Чампи критикуют процедуры управления американского бизнеса и предлагают многообещающие рекомендации. «Компаниям больше не нужно и нежелательно организовывать работу согласно теории разделения труда Адама Смита», — заявляют авторы, утверждая, что рабочие места, ориентированные на выполнение конкретных задач, устаревают по мере того, как изменения в клиентских базах, конкуренция и темпы самих изменений преобразуют рынок. Постпромышленные компании должны пройти процедуру «перепроектирования», которая вынуждает начать заново, вернуться к началу, чтобы изобрести лучший способ выполнения задач. Процесс требует дальновидного лидера, использующего информационные технологии, тесно работающего с поставщиками с целью сокращения запасов, а также расширяющего полномочия сотрудников, чтобы принятие решений стало частью работы.

Таким образом, в этой книге пропагандировался отход от классической организации предприятия на основе разделения труда и переориентация на реинжиниринг бизнес-процессов (BPR), что вызвало обширную волну деятельности в этом направлении. Заметьте, что стало востребовано не только моделирование (бизнес-) процессов, но равно и их реинжиниринг, то есть их полная переработка и реструктуризация. Моделирование и управление бизнес-процессами в последующие годы стали главной целью многих предприятиях, для чего потребовались подходящие модели и инструменты. В описании бизнес-процессов используются процессные модели, которые обычно управляются графической нотацией и посредством которых делается попытка обеспечить общий «язык» не только для управляющих, директоров компаний и лиц, принимающих решения, но также и для подразделений компании.

В данной книге, как уже упоминалось, для моделирования бизнес-процессов используются сети Петри. Причины этого многообразны и объясняются в других частях книги. Основы сетей Петри в 1962 году заложил Карл Адам Петри в своей диссертации «Взаимодействие с автоматами» (нем. «Kommunikation mit Automaten»). В последующие годы они, с одной стороны, постоянно исследовались, а с другой — стали важным точным инструментом в описании процессов. Причины здесь кроются в принципиально простой применимости сетей Петри, а также в инструментальной поддержке, как, например, та, что обеспечивается системой Horus.

Литература по сетям Петри очень обширна и описывает множество различных классов сетей, предложенных и исследованных на протяжении многих лет. В применении к Horus мы ориентируемся лишь на один конкретный класс, который представляется особенно уместным для преследуемых здесь целей моделирования, — XML-сети. С ним мы познакомимся далее по ходу этой главы, хотя для лучшего понимания сначала представим основы сетей Петри в более простой форме.

Наиболее важные понятия, используемые в данном контексте:

• бизнес-процессы;
• объекты;
• организационная структура;
• роли и ресурсы.

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

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

Как простой пример, иллюстрирующий эти понятия, рассмотрим процедуру инвентаризации, представленную на рис. 3.1, где товары, которые больше не продаются, убираются из запасов предприятия. Весь процесс состоит из действий «Проверить ассортимент товаров», «Удалить товар из ассортимента» и «Известить отдел закупок о прекращении закупок товара». В рамках годовой инвентаризации происходит контроль полного ассортимента, выполняемый отделом управления продукцией как организационной единицей. Инициирует данное действие требование инвентаризации. Итогом контроля служит проверенный товарный ассортимент, из которого далее ассистент отдела управления продукцией убирает те наименования товаров, которые больше не продаются. В результате данного действия появляется список товаров для удаления из ассортимента. Теперь отдел закупок предприятия должен быть проинформирован отделом управления продажами о тех наименованиях, которые не будут больше закупаться.

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

Процесс, описанный на рис. 3.1, уже включает в себя указания на то, сотрудники каких организационных подразделений нашего предприятия должны отвечать за выполнение конкретных действий; в данном случае примерно определены только организационные единицы, как «Отдел управления продукцией», «Ассистент (Отдел управления продукцией)». В других контекстах можно развернуть это вниз вплоть до отдельных людей, если, например, важно, чтобы определенные действия должны были или могли выполняться только определенными сотрудниками, прошедшими соответствующее обучение. Процесс в конечном итоге также содержит информацию об объектах, которые задействованы как в отдельных действиях, так и в начале и в конце процесса.

Уже на таком маленьком примере можно увидеть — и вспомнить при этом снова о ситуации в компании «Бардак», описанной во вступительной главе, — что моделирование такого рода процессов имеет решающее значение для понимания хода работы предприятия. Такое моделирование осуществляется при этом согласно приведенному выше разделению по следующим направлениям (рис. 3.2):

• процессное моделирование;
• объектное моделирование;
• организационное моделирование.

При процессном моделировании охватывается последовательность всех без исключения процессов предприятия либо затрагиваемой сферы деятельности. Это могут быть различные виды процессов, как, например, критически важные для функционирования предприятия, административные или поддерживающие процессы. В процессном моделировании принципиально важен подход, служащий для каждого отдельного разработчика путеводной нитью, по которой ведется моделирование. Например, можно продвигаться «снизу вверх» («Bottom-Up»), начиная моделирование в первую очередь с отдельных действий, а затем постепенно объединяя их в более крупные единицы (подпроцессы и процессы). Но можно также, и это будет наш подход, пойти «сверху вниз» («Top-Down»), сначала получив общий вид верхнего уровня абстракции, где определяются основные бизнес-процессы компании, которые вслед за тем шаг за шагом конкретизируются. Как мы еще увидим, в целом для подхода важно в первую очередь сосредоточиться на нормальном исполнении процессов и только после этого брать к рассмотрению исключения или возможные неисправности. Методом процессного моделирования, зарекомендовавшим себя на многочисленных практических примерах, является Метод Horus, представленный в главе 4.

В процессе объектного моделирования создаются объекты либо документы, требуемые на входе или генерируемые на выходе действиями и процессами. Здесь предполагается создание диаграммы классов, описывающей, например, в нотации Унифицированного языка моделирования (UML), какие схемы либо классы объектов должны лежать в основе каких атрибутов и методов соответствующей предметной области. Однако также возможно — и это будет видно здесь в ходе дальнейшей разработки — описание структуры объектов и документов, которыми обмениваются между собой действия и подпроцессы, в нотации Расширяемого языка разметки (XML). Хотя, и принимаем во внимание преимущества использования нотации XML, однако ради ясности также применяем графическую нотацию, как та, что уже использовалась в форме объектной модели на рис. 2.3 и 2.4.

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

В дальнейшем мы увидим, что эти три аспекта моделирования: процессное, объектное и организационное — целесообразно рассматривать как единое целое и отслеживать одновременно или, по существу, параллельно, поскольку ситуация, обнаруживаемая на предприятии, в большинстве случаев соответствует изображенному на рис. 3.3: организационная структура предприятия никоим образом не проводит границы процессов, протекающих на предприятии; вместо этого процессы связывают разные части организации друг с другом разнообразными способами.

Отметим здесь лишь некоторые из тех аспектов, что могут быть приняты во внимание в ходе совместного моделирования процессов, объектов и организационных единиц: моделирование процессов сверху вниз позволяет с самого начала проекта моделирования определять его цели и стратегии. Типичная цель — как для моделирования в частности, так и для управления бизнес-процессами в целом (см. рис. 2.6) — сокращение процессов, устранение избыточности, повышение эффективности, а также достижение прозрачности. Для этого необходимы продуктивные организационные структуры, с тем чтобы процессы могли быть эффективно переработаны и одновременно адаптированы к постоянно меняющимся требованиям. Прозрачность процессов способствует дальнейшей оценке рисков, а также улучшению коммуникации между подразделениями компании внутри отдельных процедур. Чтобы узнать, достигнуты ли поставленные цели, необходимо определить показатели эффективности, которыми успешность может быть измерена. На уровне отдельного сотрудника либо подразделения как побочный продукт процесса моделирования нередко возникает карта знаний, или так называемая карта умений (Skill Map), где охвачены необходимые для отдельных индивидуумов компетенции, которыми они должны обладать либо приобрести в рамках соответствующих процессов. На этих аспектах мы подробнее остановимся в главе 4.

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

3.3. Основные конструкции для моделирования бизнес-процессов

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

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

3.3.1. Элементы процедурного моделирования

Процедурная модель в случае сетей Петри обладает простой структурированной конструкцией и состоит из трех основных элементов:

• действия, изображенные в виде прямоугольников;
• хранилища объектов (в самом широком смысле), представленные кружками;
• связи между действиями и хранилищами объектов, изображенные в виде ориентированных дуг.

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

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

Хранилища объектов в моделях процедур изображены в виде кружков. Они включают в себя объекты, причем имя хранилища объекта должно четко указывать на то, какие именно объекты здесь находятся. Благодаря этому улучшается доходчивость модели. Хранилищам объектов помимо этого может быть задана определенная емкость (capacity). Емкость дает сведения о максимальном количестве объектов, которые одновременно могут находиться в хранилище объектов. Ниже в моделях она приводится как «C = …». Также заслуживает упоминания, что для хранилища объектов могут быть определены и другие атрибуты — например, его затраты или сроки годности. Эти атрибуты влияют на выполнение действий. Далее по ходу нашего обсуждения это объясняется более подробно.

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

• Входящие связи (рис. 3.4). Действие во время его выполнения потребляет объекты из хранилищ объектов на входе.
• Выходящие связи (рис. 3.5). Действие во время его выполнения выпускает объекты и помещает их в хранилища объектов на выходе.
• Модифицирующие связи (рис. 3.6). Действие во время его выполнения изменяет объект в хранилище на другом конце линии связи.
• Считывающие связи (рис. 3.7). Действие во время его выполнения получает доступ к объектам исключительно для чтения, благодаря чему объекты нельзя ни изменить, ни удалить из хранилища объектов.

Можно также определять атрибуты для пар связь — хранилище объектов, например вероятность, с которой связь будет выполняться (возможно, после развилки). Другим атрибутом может быть число объектов, которые посредством связи потребляются или выпускаются.

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

3.3.2. Динамика в процедурных моделях

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

В качестве примера рассмотрим выдержку из процесса инвентаризации, изображенного на рис. 3.1. По завершении инвентаризации отдельные товарные позиции удаляются из ассортимента предприятия. Такой товар в этом случае появляется в виде маркера в хранилище на входе соответствующего действия и передается посредством действия в хранилище на выходе. Это показано на рис. 3.8 и 3.9.

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

В принципе, в процедурных моделях происходит не что иное, как «перекочевывание» объекта от одного действия к другому. Модели таким образом показывают возможные «траектории», по которым могут пройти объекты. Когда объекты «перекочевывают» от одного действия к другому или когда отдельное действие будет выполнено, зависит от состояний примыкающих хранилищ объектов.

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

1. Во всех хранилищах на входе действия должно быть доступно требуемое количество объектов.
2. Все хранилища на выходе действия должны быть способны принять необходимое число объектов.

Если эти условия соблюдены, действие может быть выполнено (оно может переключать или «активировать»). Затем оно берет необходимое количество объектов из каждого хранилища на входе и помещает соответствующее количество объектов в каждое хранилище на выходе.

Это очевидно для последовательных процессов, таких как недавно рассмотренные. Но что происходит, если процедура больше не выполняется строго последовательно? В этих случаях важно точно указать количество маркеров. Мы рассмотрим для начала случай простой развилки: в нем размещение онлайн-заказа должно порождать как подтверждение по электронной почте, так и сам объект заказа. Ситуация непосредственно перед выполнением этого действия изображена на рис. 3.10. В процессе выполнения действия каждое из двух хранилищ на выходе будет снабжено маркером, как показано на рис. 3.11.

Если для соответствующего хранилища объектов задана емкость, то количество объектов, одновременно находящихся в хранилище, также может быть изображено через маркеры; на рис. 3.12 это показано для емкости С = 10. В данном случае при выполнении действия из предыдущего примера «Разместить онлайн-заказ» изымается из хранилища на входе один маркер, а на выходе оба хранилища будут заняты одним маркером каждое. Объектов здесь может быть и больше, так как для всех показанных хранилищ объектов установлена верхняя граница емкости в 10 объектов.

Как здесь уже было отмечено, в ходе моделирования в Horus разработчик не должен сам отображать состояния моделей в различные моменты времени. Это берет на себя имитационная компонента Horus. Во время моделирования определяется так называемое время выполнения отдельных действий, которое имитационный компонент Horus затем использует для своих имитаций процессов.

Динамическое моделирование бизнес-процедур можно проиллюстририровать также на следующем примере. Рассмотренная на рис. 3.13 ситуация ясно отражает, что перед приемкой товара должны быть доступны как товарная накладная, так и доставленные книги. В процессе выполнения действия возникает ситуация, изображенная на рис. 3.14; согласно правилам перехода, указанным выше, теперь хранилища на выходе «Архив», «Склад» и «Отходы упаковки» все без исключения заняты маркерами.

3.3.3. Типы бизнес-процедур

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

Следующие рисунки отражают такого рода ситуации.

• Рис. 3.15 показывает пример последовательной процедуры (аналогично уже изображенной выше на рис. 3.1): действия следуют одно за другим в заданном порядке.
• Рис. 3.16 показывает пример одновременных (иногда используемых как синоним параллельных) действий: здесь отдельные действия протекают на определенном участке бок о бок. На этом участке они также хронологически не зависят друг от друга.
• Рис. 3.17 показывает пример альтернативных процедур: здесь процедура может иметь несколько потоков. Однако фактически в рамках одного экземпляра процесса будет выполняться только один из них.

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

Если процедуры разветвляются, как в случае и параллельного, и альтернативного моделирования, то отдельные процедуры могут завершаться совершенно раздельно. В большинстве случаев, однако, к более позднему моменту они должны быть снова сведены вместе. В таком случае речь идет либо о синхронизации, либо о консолидации. Иногда для выполнения действия необходимо, чтобы было доступно несколько объектов. Это иллюстрируется тем, что соответствующие хранилища объектов сводятся вместе как хранилища на входе рассматриваемого действия. В этой точке ранее независимые последовательности действий синхронизируются. Пример синхронизации показан на рис. 3.18; здесь выполнение действия «Заполнить формуляр заказа» возможно при условии, что все предполагаемые действия завершены. Помимо синхронизации, есть также консолидация. При этом после альтернативы (альтернативной процедуры) несколько действий снова сводятся вместе. Пример консолидации показан на рис. 3.19; здесь выполнено одно из альтернативно возможных действий, и затем процесс продолжается последовательно.

Для лучшего понимания синхронизации мы отсылаем читателя к упражнению 3.2 про светофор в конце этой главы.

Ранее рассмотренные сети Петри были без исключения «плоскими» в том смысле, что действия и хранилища объектов неизменно находились на одном и том же уровне абстракции. Кроме того, маркеры, использовавшиеся на позициях до настоящего времени, не обладали атрибутами или внутренней структурой. Очевидно, что оба эти аспекта не являются достаточными для моделирования реальных бизнес-процессов (см. также раздел 3.3.5): с одной стороны, бизнес-процессы нередко сложны, так что уже только для удобства чтения их подразделяют в иерархически сгруппированные подпроцессы; формально это достигается за счет декомпозиции заданной сети Петри, о чем мы поговорим в следующем подразделе. С другой стороны, перемещаемые и рассматриваемые в контексте бизнес-процессов объекты — это не отдельные биты (как простые маркеры), а счета, приказы или другие документы, которые, как и сами процессы, должны быть соответствующим образом смоделированы. Мы уже знаем из главы 2 (см. рис. 2.3), что рассмотренные здесь объекты могут быть довольно сложно структурированными и в конечном счете должны быть представлены в виде XML-документов, которые затем находят применение в XML-сетях. Моделирование объектов мы рассмотрим в разделе 3.4.

3.3.4. Декомпозиция

Далее мы опираемся на то, к чему уже обращались в главе 2 во взаимосвязи с рис. 2.1 и 2.2: декомпозицию действий (см. раздел 2.2). Как уже упоминалось, разработчик решает, насколько детально должны быть смоделированы отдельные процедуры. Степень детализации процедурной модели может, например, зависеть от того, как много исключений из стандартной процедуры или как много возможных случаев ошибок необходимо принять во внимание. Однако если в одной модели скомпоновано слишком много элементов, она перестает быть наглядной, становится сложной для прочтения и понимания. Как показано в главе 4 при знакомстве с методом Horus, моделирование, как правило, начинается с абстрактного и контурного изображения совокупных взаимосвязей процесса, которые представляются в виде так называемой модели архитектуры бизнес-процессов предприятия. Она отражает самый высокий уровень иерархии для поэтапного моделирования бизнес-процессов и относящейся к ним информации. Она определяет ключевые процессы, учитываемые в рамках проекта моделирования. Бизнес-процессы на этом уровне абстракции называются основными бизнес-процессами. Исходя из обзорной модели, построенной на стадии определения проекта, бизнес-процессы моделируются иерархически сверху вниз в разных уровнях абстракции. На верхнем уровне основных бизнес-процессов какие-либо объекты, как правило, еще не определяются.

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

Для обеспечения структурно правильной конструкции необходимо позаботиться о том, чтобы примыкающие к действию, подлежащему декомпозиции, хранилища объектов соответствовали точкам входа и выхода декомпозиции. При создании в Horus декомпозиции какого-либо действия инструмент автоматически создает в диаграмме декомпозиции копию каждого хранилища объектов, связанного с данным действием. Созданные таким образом копии графически маркируются прямоугольником вокруг значка хранилища объектов. Это показано на рис. 3.20 для действия «Разместить онлайн-заказ».

3.3.5. Хранилища объектов в сетях Петри: XML-сети

3.3.5.1. Описание процесса с помощью сетей Петри

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

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

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

3.3.5.2. Варианты сетей

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

Позициям (так как они представляют собой контейнеры) могут быть заданы индивидуальные значения емкости, определяющие максимально допустимое количество объектов в соответствующей позиции. Если значение емкости явно не указано, то предполагается неограниченная емкость позиции. Если емкость позиции равна 1, то количество объектов в этой позиции в любом состоянии процесса может составлять только 0 или 1. Таким образом, данная позиция может интерпретироваться как условие, которое выполняется (значение истинно равно 1), если маркер присутствует, и не выполняется (значение истинно равно 0) в противном случае.

В так называемых высших сетях Петри объекты в позициях могут также обладать индивидуальными свойствами. В частности, они однозначно идентифицируются с помощью ключа. В предикатных переходных сетях (Pr/T-сеть) позиции интерпретируются как типы отношений, тогда маркеры — кортежи (упорядоченные наборы фиксированной длины) соответствующего отношения. Pr/Т-сеть отображает таким образом процессы на данных реляционной базы данных. Действия в Pr/T-сетях изымают либо помещают кортежи в отношения.

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

В высших сетях Петри дуги могут быть маркированы с помощью констант, которые определяют, что только объекты с соответствующими значениями через эту дугу могут быть помещены либо изъяты. Помимо этого дуги могут быть маркированы с помощью переменных, которые, в свою очередь, могут принимать различные постоянные значения. В Pr/T-сетях дуги дополняют состоящие из переменных и констант кортежи, как маркировки, которые — аналогично языку запросов по образцу (QBE) — в качестве примера показывают, какие кортежи при срабатывании были изъяты либо помещены в упомянутые позиции.

В принципе, структура допустимых объектов в позициях высшей сети Петри может быть описана с помощью любой модели данных. В Pr/T-сетях это реляционная модель Кодда. Существуют различные представления, согласно которым объектные модели следует применять для типизации позиций. Маркеры в таком случае представляют собой сложно-структурированные объекты (то есть объекты сами могут вновь состоять из других объектов). Фильтры в качестве маркировки дуг должны быть определены в зависимости от используемой модели данных, для чего, как правило, предлагаются языки запросов соответствующей модели данных.

3.3.5.3. XML-сети

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

Позиции в XML-сети являются контейнерами для XML-документов. Структура XML-документа, допустимого («действительного») для данной позиции, может быть зафиксирована посредством Определения типа документа (DTD), то есть грамматики, либо посредством XML-схемы. Разрешенные объекты вместе должны выполнять соответствующее DTD или соответствовать спецификации XML-схемы.

XML-сеть описывает класс процессов на объектах XML. Отдельная процедура в сети Петри представляет собой конкретный экземпляр процесса. В сетях Pr/T объекты (кортежи) неделимы: в момент срабатывания они целиком изымаются из или помещаются в позиции, следовательно, параллельное выполнение нескольких действий на таком кортеже не представляется возможным (так как в каждый момент времени только одному действию разрешен доступ к кортежу). В XML-сетях объекты в позициях являются (с большой вероятностью) иерархически структурированными документами XML. Поэтому переходы могут также иметь доступ к частям документов, то есть изъять части из объектов на входных позициях и включить новые части в уже существующие объекты на выходных позициях. В частности, возможно также моделировать параллельное выполнение нескольких действий над различными частями одного и того же объекта, например, если два автора обрабатывают различные главы одного и того же документа.

Фильтры в сетях XML, дополняющие дуги, имеют иерархическую структуру, аналогичную структуре XML-документов в данной позиции. В качестве языка для описания этих фильтров есть множество различных вариантов, таких как языки XML запросов Xpath (для навигации) или XQuery. Как и в других вариантах высших сетей Петри, для описания правил изъятия объектов из позиций либо помещения их туда в XML также существует дополнительная возможность использования логических выражений в качестве маркировок переходов, сформулированных с помощью переменных из маркировок, присущих переходу дуг.

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

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

Для повышения наглядности и упрощения моделирования мы используем несколько сокращений для дуг: неориентированные дуги между двумя узлами k1 и k2 — это сокращенная форма для каждой из двух стрелок, одна из которых направлена от k1 к k2, а другая — от k2 к k1, где обе дуги маркированы одинаково. Доступ к позиции, которая соединена с переходом посредством неориентированной дуги, дается «только для чтения», то есть соотношение маркеров соответствующей позиции не изменяется при срабатывании перехода (см. рис. 3.7). Иногда на практике также используются «разветвления дуг» в качестве сокращенного обозначения для нескольких дуг, которые имеют либо общий выходной узел, либо общий целевой узел (или оба); при этом следует отметить, что подобное может привести к путанице.

3.4. Моделирование объектов

3.4.1. Требования

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

1. Структуры бизнес-объектов должны давать возможность их определения через атрибуты и отношения.
2. Изложение информации должно быть понятным для бизнес-подразделений, обеспечивая в то же время для ИТ-отдела формально точное представление положения дел, которое также может быть использовано для генераторов программного обеспечения.
3. Чтобы сделать возможным построение взаимосвязей между структурами бизнес-объектов, требуемыми для какого-то проекта, области деятельности либо целого предприятия, моделирование этих структур должно быть осуществимо независимо от конкретного бизнес-процесса.
4. С другой стороны, необходимо иметь возможность прикреплять или обобщать отдельные компоненты структур бизнес-объектов в объекты, которые должны быть обработаны на определенном этапе бизнес-процесса. Например, на этапе утверждения заказа опционально требуется только заголовок заказа с общей суммой, а не отдельные пункты заказа. При размещении заказа, однако, требуются уже заполненный заголовок заказа и отдельные пункты заказа. Таким образом, моделирование структур бизнес-объекта должно заключаться в определении простых структур в форме отдельных компонентов, таких как «Заголовок заказа» и «Пункт заказа», которые затем могут быть связаны соответствующими отношениями. Кроме того, также должна быть обеспечена возможность обобщения простых структур бизнес-объектов, таких как «Заголовок заказа» и «Пункт заказа», в совокупную структуру бизнес-объекта «Заказ».
5. Должна быть возможность на основе смоделированных структур бизнес-объектов создавать соответствующие документы XML-схемы и соотносить их с XML-сетями. Рис. 3.21 показывает моделирование структур бизнес-объектов, бизнес-процессов и соотнесение структур бизнес-объектов с бизнес-процессами на основе XML-схемы и XML-сетей.

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

3.4.2. Используемая нотация

В качестве нотации для объектного моделирования здесь будет использоваться комбинация специальных понятий из ресурсно-ориентированного моделирования (АОМ), диаграмм классов унифицированного языка моделирования (UML) и модели сущность-связь (ER) либо расширенной модели сущность-связь (EER), которые оптимально отвечают требованиям. Основой используемой здесь модели служит AOM, так как данный метод принципиально ближе всего к цели моделирования структур бизнес-объектов для XML-сетей, поскольку дает возможность описания сложных иерархических объектов. Однако терминологически описанная здесь нотация имеет некоторые отступления по отношению к АОМ. Вместо ресурсов здесь говорится об объектах, а вместо дуг — о связях отношения и наследования. Здесь мы вообще обойдемся без определений операций для объектов. В качестве расширения АОМ здесь введены три различных типа так называемых собирающих условий к определению правил согласованности между объектами и соответствующими прикрепленными к ним дугами. Для моделирования структур бизнес-объектов применительно к использованию в XML-сетях существуют следующие основные элементы.

• Элементарный объект с атрибутами (простой бизнес-объект). Элементарные объекты будут далее называться «объектами».
• Агрегация (элементарных) объектов (сложный бизнес-объект).
• Связи отношения и наследования между простыми бизнес-объектами.
• Собирающие условия для связей отношения.

3.4.2.1. Объект

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

3.4.2.2. Связи отношения и наследования между объектами

Дуги между объектами — это элементы, отображающие отношения и зависимости между объектами. Есть два типа дуг.

Связь «отношение» отображает отношение между объектами в соответствии с семантикой модели «Сущность-связь (ER)». У такой связи могут быть проставлены два обозначения, по одному на каждом конце связи для связанного объекта. Обозначения относятся к исходящему от данного объекта направлению. Существует в принципе три основных типа связей отношения между объектами: 1:1, 1: n и n: m, которые показаны через нотацию «вороньи лапки» (crow’s feet). Кроме того, для каждого конца дуги должно быть указание мощности в деталях.

Связь «наследование» отображает отношение наследования между объектами. Она снабжена описанием «является» (is a). Наследование изображается в виде простой стрелки. В направлении стрелки связь наследования означает, что исходный объект отражает специализацию целевого объекта. Прочитанная против направления стрелки, она означает, что исходный объект является обобщением целевого объекта.

Рис. 3.23 изображает связь отношение 1: n между «Клиентом» и «Счетом», соответственно маркированными через мощности на обоих концах, то есть клиент может иметь несколько счетов, однако также допускается и отсутствие счета. Во втором примере связь наследования между «Сотрудником» и «Персоной» показывает, что «Сотрудник» является «Персоной», то есть все атрибуты персоны наследуются сотрудником.

3.4.2.3. Собирающие условия для связей между объектами

Для связей отношений могут быть определены дополнительные собирающие условия. Они помещаются между объектами и связями отношения и представлены в виде соответствующего символа, прикрепляемого к объекту. Есть три типа собирающих условий, которые соответствующим образом расширяют ранее представленную семантику объектов и связей отношений.

Собирающее условие XOR является исключающим ИЛИ (OR) для присоединенных к нему связей отношений, то есть для одного экземпляра объекта допускается только один экземпляр отношения из имеющихся в присоединенных к XOR связях отношения.

Собирающее условие OR представляет собой ИЛИ (OR) с по крайней мере одним выбором. При собирающем условии OR должен быть доступен по крайней мере один экземпляр отношения. Однако могут существовать и несколько экземпляров отношений.

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

Рис. 3.24 служит примером собирающего условия XOR. В представленном примере показано, что продаваемый продукт либо изготавливается через производственный заказ, либо приобретается через заказ на закупку.

Рис. 3.25 изображает на примере собирающее условие OR. Рисунок описывает, что заказ может содержать сколь угодно много услуг или любое количество товаров. Однако заказ должен включать по крайней мере одну услугу или альтернативно один товар.

Рис. 3.26 показывает пример собирающего условия SIM. Из приведенного примера видно, что в случае заказа клиента на специфический продукт, то есть изготовленный индивидуально, также необходимо приложить соответствующий внутренний производственный заказ.

Определенные ситуации могут либо должны быть смоделированы без собирающих условий. На рис. 3.27 в первом примере изображена гибкая OR-связь, которая, в отличие от модели на рис. 3.24, допускает, что для продаваемого продукта не должны создаваться ни производственный заказ, ни заказ на закупку, поскольку продукт, например, также имеется на складе. С другой стороны, для товара на продажу также могут быть созданы и производственный заказ, и заказ на закупку. Второй пример показывает, что за одной строкой заказа должны быть закреплены один продукт и один обрабатывающий сотрудник. Оба эти экземпляра связи обязательны, однако, в отличие от собирающего условия SIM на рис. 3.26, не зависят друг от друга и относятся только к связанному объекту.

3.4.2.4. Агрегация взаимосвязанных объектов

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

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

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

Рис. 3.28 показывает моделирование агрегации «Заказ», содержащей связанные объекты «Заголовок заказа», «Поставщик», «Строка заказа», «Товар» и «Услуга». Объект «Заголовок заказа» соответственно помечен в качестве корневого объекта. Другие отношения внутри этого совокупного бизнес-объекта представлены описанными ранее связями отношений. Собирающее условие XOR для строки заказа гарантирует, что в любом случае с одной строкой заказа будет соотнесен либо один товар, либо одна услуга.

3.4.3. Простые и сложные объекты

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

1. Объекты уже являются готовыми простыми бизнес-объектами. Простой бизнес-объект включает в себя все атрибуты с типами данных, ключи и простые условия соответствующего объекта. Дуги к другим объектам, собирающие условия и принадлежность к агрегациям не рассматриваются применительно к простым бизнес-объектам.
2. Агрегации уже являются готовыми сложными бизнес-объектами. Сложный бизнес-объект содержит всю информацию, свойственную содержащимся в нем простым бизнес-объектам (п. 1), а также дуги внутри агрегации и их собирающие условия.

Рис. 3.29 показывает различие между простыми и сложными бизнес-объектами. Агрегация «Клиент» описывает сложный бизнес-объект, так как он обладает несколькими объектами, связанными посредством отношений. Объект «Счет клиента» помечен как корневой, и поэтому его ключи являются ключами всего сложного бизнес-объекта. Объект «Товар», наоборот, представляет собой простой бизнес-объект, так как он не содержит никаких других объектов. Отношения между бизнес-объектами отображаются на уровне объектов. Таким образом, «Товар» и «Клиент» могут быть соединены через связь отношения между объектами «Товар» и «Счет клиента».

3.4.4. Соотнесение объектов с XML-сетями

Бизнес-объекты могут быть соотнесены с позициями в XML-сетях в качестве маркеров. Данные структуры затем могут быть использованы переходами в областях до или после соотнесенных позиций.

Из модели данных, показанной на рис. 3.29, не только объект «Товар», но и агрегация «Клиент» могут быть использованы для соотнесения с XML-сетью. Также можно использовать, например, только один простой бизнес-объект «Счет клиента» из всего сложного бизнес-объекта.

3.5. Организационное моделирование

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

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

При проектировании организационной структуры принципиально должны быть рассмотрены два аспекта: разделение труда и его координация. Разделение труда — это подразделение отдельных организационных единиц на зоны по задачам. При этом можно проводить деление по различным функциям внутри процессных потоков (например, закупки, производство, продажи, управление и т.д.). Это называется «функциональная организация». В качестве альтернативы можно разбивать организационные единицы в соответствии с такими плоскостями, как продукты, регионы или клиенты. Тогда организация является «объектно-ориентированной». Следует отметить, что объектно-ориентированные организации часто называют «процессно-ориентированными». В этом случае сформированные единицы отвечают за выполнение задачи от начала до конца (например, выполнение проекта). В зависимости от задачи разбиение происходит вплоть до отдельных должностей (наименьшая единица организации).

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

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

При делении на организационные единицы, а также при их изображении можно выделить следующие типы:

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

Здесь мы не будем в дальнейшем их графически различать.

В организационном моделировании, как и в процессном, существует возможность для декомпозиции отдельных организационных единиц. В декомпозиции они могут быть разбиты на более мелкие единицы и таким образом отображены подробнее. Исключение здесь составляют внешние организационные единицы. Они, как правило, далее не детализируются (например, организационная единица «Клиент»). Аналогично подходу в процедурном моделировании необходимо также обратить внимание на то, чтобы уровень абстракции в рамках одной модели оставался одним и тем же. Например, на рис. 2.5 организационная единица «Управление продажами» была декомпозирована следующим образом: «Бэк-офис», «Продажи Германии», «Продажи EMEA» и «Продажи RoW».

Целью организационного моделирования является прежде всего возможность выявления и назначения ресурсов для выполнения экземпляров процесса. Под ресурсами понимают лиц или объекты организации, которые отвечают за выполнение действий. Ресурсы принимают на себя так называемые роли и закрепляются за определенными организационными единицами, поэтому и моделировать их следует во взаимосвязи со «своими» организационными единицами. Поскольку компетенции и квалификации одного ресурса часто весьма разнообразны, ресурсы порой исполняют более одной роли.

Выделяют, как правило, пять видов ресурсов:

• персонал;
• материальные средства;
• вспомогательные средства;
• базы данных;
• приложения.

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

Под ролью подразумевается профиль деятельности (или «должность»), необходимый для осуществления действий в рамках процесса. Во время выполнения этих действий ресурсы принимают на себя роли.

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

3.6. Конкретный пример

В этом разделе ранее описанные концепции и языки моделирования будут наглядно проиллюстрированы на сквозном примере. Будет смоделирован процесс от привлечения новых клиентов вплоть до поставки продукции. Для всеохватывающего и формального описания этого процесса вместе с существенными аспектами применяются модели процессные на разных уровнях иерархии, объектные и организационные. Ключевым моментом, которым отличается описанный в главе 4 метод Horus, является увязка различных концепций, что особенно заметно при детальном рассмотрении используемых XML-сетей.

Процедурная модель, изображенная на рис. 3.30, показывает процесс от привлечения клиента до поставки товара сначала с высокой степенью абстракции. Действие «Привлечение клиентов» олицетворяет непрерывные контакты с существующими и потенциальными клиентами, в идеале приводящие к пробуждению интереса к продукту. Разумеется, привлечение клиентов на практике само по себе является чрезвычайно сложным процессом, который подчиняется множеству правил и часто требует самых дорогих ресурсов. Однако в нашем конкретном примере мы намеренно хотим абстрагироваться от этой сложности, оставляя поэтому лишь одно единичное действие, при этом хорошо осознавая, что именно процессу привлечения клиентов нередко присущи интереснейшие возможности для оптимизации. При наличии интереса в конкретных продуктах из ассортимента формируется предложение и ведутся переговоры. Неудачные переговоры приводят к отклонению предложения. В случае успеха предложение принимается, если потребуется, с изменениями и дополнениями. После принятия предложения клиентом в последнем действии описываемого основного процесса «Регистрация заказа и отправка» создается заказ, и тогда отправка желаемого товара со склада может быть выполнена.

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

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

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

Схемы фильтрации (FS) в данном примере описаны с помощью псевдокода. Схема фильтрации FS1 извлекает предложения из хранилища объектов «Принятое предложение». Тем самым обеспечивается, что они находятся в состоянии «Заказано» и, следовательно, их обработка может быть продолжена. Посредством действия «Зарегистрировать заказ» к каждому выбранному предложению прикладывается заказ. В процессе регистрации заказа с помощью схемы фильтрации FS2 создаются новые заказы, в которых номер заказа генерируется, товар и клиент берутся из предложения, а статус вновь созданного заказа первоначально устанавливается как «Открыт». Схема фильтрации FS3 служит для поиска товара из заказа. Прежде чем сможет быть осуществлена отправка товара посредством действия «Отправить товар», согласно комментарию к данному действию выполняется проверка, есть ли на складе в наличии достаточно товара, чтобы отправка товара в количестве, соответствующем заказу, могла состояться. После выполнения, то есть срабатывания действия, выполняется обновление информации о наличии товара через схему фильтрации FS4, а также внесение отправок в данные по операциям клиентов посредством схемы фильтрации FS5.

Соотнесенные объекты могут быть описаны с помощью объектной модели, представленной на рис. 3.34. Из нее могут быть непосредственно созданы и использованы структуры бизнес-объектов, применяемых в XML-сетях. Например, «Предложение» и «Заказ» могут быть изображены напрямую за счет использования одноименной для каждого агрегации (сложного бизнес-объекта). Структуры бизнес-объектов «Склад» и «Доставка» таким же образом могут быть созданы через формирование сложного бизнес-объекта. Например, структура XML для «Доставки» может быть создана путем агрегации объектов «Клиент», «Доставка» и «Товар».

3.7. Упражнения для самоконтроля

Упражнение 3.1

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

Упражнение 3.2

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

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

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

Упражнение 3.3

Когда подается заявка на предоставление кредита, то она сначала тщательно проверяется. Эта проверка может привести к отклонению заявки. Вслед за этим клиент будет уведомлен об отказе, и банк сохранит копию отказа в архиве. Если заявка будет одобрена, после заключения договора клиент получит запрашиваемый кредит.

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

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

При проверке кредитной заявки далее применяются следующие бизнес-правила.

1. Если запрашиваемая сумма кредита больше двух месячных окладов, то автоматически происходит отклонение заявки.
2. Если взаимоотношения с клиентом еще недостаточно долгие, то заявка также отклоняется.

Заявки, которые не отвечают ни правилу 1, ни правилу 2, будут проверены, если у клиента в прошлом хорошая кредитная история. В противном случае (внутренний черный список) заявка также отклоняется. Кредитные заявки с суммой меньше 0,5 месячного оклада, напротив, автоматически одобряются. Если сумма меньше одного месячного оклада, уполномоченный клерк может решить, будет ли заявка удовлетворена или нет. Для сумм, превышающих месячный оклад, решение принимается Кредитным комитетом.

• Постройте модели соответствующих процедур.
• Смоделируйте подобающе структурированную форму заявки как тип объекта.
• Смоделируйте в новой информационной модели другой тип объекта «Кредитная заявка» и дополните его надлежащими атрибутами.
• Примерно опишите возможную организационную структуру предприятия.
• Определите ресурсы, соответствующие разработанной организационной модели. При этом смоделируйте как человеческие, так и технические ресурсы (материальные средства) и, кроме этого, примите во внимание расценки. Также смоделируйте надлежащие роли.
• Соотнесите соответствующие роли с действиями в процедурной модели «Заключение контракта».

Упражнение 3.4

Van der Aalst с соавторами предлагают сравнивать мощь методов моделирования (и систем управления потоками работ) на основе шаблонов потоков работ (workflow patterns). Такого рода шаблоны — абстракции от конкретных конструкций моделирования, которые встречаются на практике в различных контекстах. В частности, речь идет о следующих шаблонах.

A. Стандартные шаблоны управляющей логики/порядка вычислений (Basic Control Flow Patterns). Простые построения, которые поддерживаются почти всеми языками моделирования.

• Последовательность (Sequence). За А следует В, если А было завершено.
• Параллельное расщепление (Parallel Split). Если А завершено, то В и С могут быть запущены параллельно (В и С, таким образом, переводятся в состояние «готов к выполнению»).
• Синхронизация (Synchronization). С может быть запущено, если А и В завершены.
• Исключающий выбор (Exclusive Choice). За А в зависимости от условия следует либо В, либо С.
• Простое слияние (Simple Merge). С исполнимо, если было завершено А или В.

B. Шаблоны расширенного ветвления и синхронизации (Advanced Branching and Synchronization Patterns). Общепринятые на практике простые построения, которые, однако, не поддерживаются напрямую всеми языками моделирования.

• Множественный выбор (Multi-choice). За А следует в зависимости от условия только B, или только C, или B и С вместе.
• Синхронизирующее слияние (Synchronizing Merge). С может быть запущено, если А и В завершены, при условии что А и В были выполнены одновременно. В противном случае C может быть запущено, если только А или только В завершено, при условии что только А либо только В было выполнено. C выполняется в общей сложности только один раз.
• Множественное слияние (Multi-merge). А может быть запущено каждый раз, когда B или С завершено. В общей сложности А, таким образом, может быть запущено два раза, когда оба, как B, так и C, были активированы.
• Дискриминатор (Discriminator). X может быть запущено, если n из m непосредственно предшествовавших действий были завершены к моменту Х. X при этом выполняется в общей сложности один раз.

C. Структурные шаблоны (Structural Patterns). Общеприняты на практике, но часто не всеми языками моделирования поддерживаются. Эмуляции такого рода структур в языках, их не поддерживающих, приводят к лишенным наглядности, сложным моделям. В некоторых случаях эмуляция не представляется возможной.

• Произвольные циклы (Arbitrary Cycles). Неструктурированные циклы, похожие на GOTO в классических языках программирования, которые могут иметь несколько точек входа или выхода из цикла.
• Условное прекращение (Implicit Termination). Процесс (подпроцесс) должен быть автоматически прекращен, если никакие дальнейшие действия не могут быть выполнены.

D. Шаблоны с участием нескольких экземпляров (Patterns involving Multiple Instances). Шаблоны, как они обычно ведут себя при обработке иерархических объектов (например, заказов со строками заказа). Эти шаблоны, как правило, поддерживаются только несколькими языками моделирования непосредственно и в полном объеме.

• Несколько экземпляров без синхронизации (Multiple Instances Without Synchronization). B запускается несколько раз, параллельно в отношении различных бизнес-объектов, после того как А завершено. Синхронизация различных B не требуется.
• Несколько экземпляров с заранее известным временем разработки (Multiple Instances With a Priori Design Time Knowledge). B всегда запускается ровно n раз (согласно установке в модели), параллельно в отношении n бизнес-объектов, после того как А завершено. С запускается после того, как все В завершены.
• Множество экземпляров с заранее известным временем выполнения (Multiple Instances With a Priori Runtime Knowledge). B запускается в зависимости от А (по продолжительности) ровно n раз, параллельно в отношении n бизнес-объектов, после того как А завершено. С запускается после того, как все В завершены.
• Множество экземпляров без заранее известного времени выполнения (Multiple Instances Without a Priori Runtime Knowledge). B запускается в отношении одного бизнес-объекта после того, как А завершено. В определенных условиях может быть зафиксировано, что прежде, чем будет завершено одно В, новое B с другим бизнес-объектом должно быть выполнено параллельно. С запускается после того, как все B завершены.

E. Шаблоны на основе состояний (State-based Patterns). Выполнение одного действия зависит от состояния других действий. Непосредственно поддерживается только некоторыми языками моделирования.

• Отложенный выбор (Deferred Choice). После того как А завершено, могут быть выполнены как В, так и С. В тот момент, когда начинается выполнение B, C отключается, и наоборот. Решение о том, какое из двух действий будет выполняться, принимается извне.
• Чередующаяся параллельная маршрутизация (Interleaved Parallel Routing). Выполняются несколько действий, для которых последовательность не имеет значения. Однако в любой момент времени максимум только одно действие может находиться в обработке.
• Контрольная точка (Milestone). Действие B может только тогда быть выполнено (но не должно), когда А завершено, а C еще не завершено.

F. Шаблоны отмены (Cancellation Patterns). Прекращение действий и следующих за ними действий.

• Отмена действия (Cancel Activity). Действие, которое готово к выполнению или уже находится в процессе выполнения, отключается либо прерывается.
• Отмена кейса (Cancel Case). Весь процесс целиком и все его действия полностью отключаются либо прерываются.

Графически изобразите эти шаблоны каждый в нотации сетей Петри и обсудите следующие положения.

• В шаблонах отсутствует постановка таких задач, как, например, распределение ресурсов, обработка происшествий, обработка исключений и управление транзакциями.
• Почти все распространенные инструменты моделирования поддерживают «Стандартные шаблоны управляющей логики» (Basis Control Flow Patterns); расширенные шаблоны, напротив, поддерживаются только частично или вообще не поддерживаются.
• До приобретения инструмента моделирования следует понять, какие шаблоны общеприняты на предприятии. Это позволит избежать излишних затрат по адаптации «неправильной» системы под существующие шаблоны.

3.8. Дополнительная литература

Как уже упоминалось в главе 1, изучение бизнес-процессов, их анализа и совершенствования восходит к работам Hammer и Champy (1993). Диссертация Петри (1962) заложила краеугольный камень рассматриваемого здесь инструмента моделирования на основе сетей Петри. Современное введение в предмет можно найти у Reisig (2011).

XML-сети восходят к так называемым SGML-сетям (Standard Generalized Markup Language), рассмотренным в диссертации Weitz (1999). Они обстоятельно описаны в диссертации Lenz (2002); сравните также с Lenz и Oberweis (2003).

Модель «Сущность-Связь» берет начало в работе Chen (1976). На сегодняшний день модель является стандартом в концептуальном проектировании баз данных, см. Silberschatz с соавторами (2010). Модель АОМ, или ресурсно-ориентированное моделирование, описана в работе Daum (2003). Для знакомства с UML-моделированием см. Rosenberg и Stephens (2007) или Podeswa (2009). Взаимосвязи между моделированием процессов, данных и организации проработаны у Scheer (2000a, b), а также у Scheer с соавторами (2002).

Полное собрание материалов по теме сетей Петри содержит «Мир сетей Петри», которое поддерживается Университетом Гамбурга по ссылке: .

В качестве вводной лекции для упражнения 3.4 мы рекомендуем ознакомиться с работой Van der Aalst (2003) по шаблонам потоков работ.

Отправить