Текст книги "Бизнес-процессы"

Динамика процедур выражается в том, что объекты в модели проходят через отдельные этапы либо действия процесса. В этом разделе мы в первую очередь рассмотрим самый простой способ это смоделировать. Здесь посредством точки, так называемого маркера, указано, где находятся объекты в конкретный момент времени. Как мы увидим, этот подход более иллюстративен, но еще не работоспособен, поэтому мы распространим его далее на 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.15 показывает пример последовательной процедуры (аналогично уже изображенной выше на рис. 3.1): действия следуют одно за другим в заданном порядке.

● Рис. 3.16 показывает пример одновременных (иногда используемых как синоним параллельных) действий: здесь отдельные действия протекают на определенном участке бок о бок. На этом участке они также хронологически не зависят друг от друга.

● Рис. 3.17 показывает пример альтернативных процедур: здесь процедура может иметь несколько потоков. Однако фактически в рамках одного экземпляра процесса будет выполняться только один из них.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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. Моделирование объектов

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

1. Структуры бизнес-объектов должны давать возможность их определения через атрибуты и отношения.

2. Изложение информации должно быть понятным для бизнес-подразделений, обеспечивая в то же время для ИТ-отдела формально точное представление положения дел, которое также может быть использовано для генераторов программного обеспечения.

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

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

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

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