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

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

● Элементарный объект с атрибутами (простой бизнес-объект). Элементарные объекты будут далее называться «объектами».

● Агрегация (элементарных) объектов (сложный бизнес-объект).

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

● Собирающие условия для связей отношения.

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

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

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

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

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

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

Собирающее условие 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, не зависят друг от друга и относятся только к связанному объекту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● внешние организационные единицы.

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

В организационном моделировании, как и в процессном, существует возможность для декомпозиции отдельных организационных единиц. В декомпозиции они могут быть разбиты на более мелкие единицы и таким образом отображены подробнее. Исключение здесь составляют внешние организационные единицы. Они, как правило, далее не детализируются (например, организационная единица «Клиент»). Аналогично подходу в процедурном моделировании необходимо также обратить внимание на то, чтобы уровень абстракции в рамках одной модели оставался одним и тем же. Например, на рис. 2.5 организационная единица «Управление продажами» была декомпозирована следующим образом: «Бэк-офис», «Продажи Германии», «Продажи EMEA» и «Продажи RoW»[3]3
  EMEA – от англ. Europe – Европа, Middle East – Средний Восток, Africa – Африка; RoW – от англ. rest of the world – остальной мир.


[Закрыть].

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

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

● персонал;

● материальные средства;

● вспомогательные средства;

● базы данных;

● приложения.

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

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

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

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

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

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

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

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

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

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

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