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

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).

Полное собрание материалов по теме сетей Петри содержит «Мир сетей Петри», которое поддерживается Университетом Гамбурга по ссылке: www.informatik.uni-hamburg.de/TGI/PetriNets/.

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

4
Метод Horus

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

В данной книге мы прибегаем к методу Horus® ^ТМ[4]4
  Метод Horus®ТМ – продукт компании Horus software GmbH, Эттлинген, Германия.


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

4.1. Принципы метода Horus

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

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

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

Рис. 4.1 дает общее представление о методе Horus. Horus подразделяет разработку бизнес-процессов на четыре этапа: подготовка проекта разработки (этап 0), этап стратегии и архитектуры (этап 1) для изучения стратегических аспектов и определения архитектуры предприятия и системной архитектуры, детальный анализ бизнес-процессов (этап 2) и последующее использование модели (этап 3). Моделирование сопровождается управлением проектами, мерами по обеспечению качества и актуальной в любое время документацией.

На этапе подготовки помимо инициализации проекта происходит разработка описания проекта. При этом устанавливается, какие части организации должны быть изучены (что часто называют рамками проекта) и какие бюджет и сроки имеются в распоряжении. Также намечаются цели, которые должны быть достигнуты с проектом, анализируются и сопоставляются с бюджетом их стратегическая и экономическая выгода. Ядро Horus-моделирования составляют этапы 1 и 2, которые в последующем будут обсуждаться подробнее. Они включают в себя анализ и моделирование стратегических аспектов в тесной связи с архитектурой предприятия и системной архитектурой, а также подробное изучение бизнес-процессов. Одной из особенностей применяемых здесь сетей Петри является возможность имитационного моделирования. Имитация на практике оправдала себя как инструмент для динамического анализа и тестирования вариантов моделей «под нагрузкой». Результаты имитации могут быть визуализированы в легко понятном и удобочитаемом виде с помощью графической анимации. Когда, в каком объеме и с какой интенсивностью стоит использовать имитацию, уточняется в каждом отдельном случае, исходя из соображений затрат и пользы. Пояснения к этому приводятся в разделе 4.4.

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

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

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

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

Из этих соображений Horus-метод оснащен различными техниками для упрощения абстракции. Он включает в себя сознательные этапы работы, которые, например, на этапе анализа бизнес-процедур (см. раздел 4.3.2) начинаются с простых в объяснении конкретных сценариев использования (use cases) или бизнес-событий (business events), а затем постепенно поднимаются на более высокий уровень абстракции, то есть в целевую модель. Инструменты Horus также облегчают применение абстракции тем, что предлагают возможность привязать к каждому элементу модели конкретные примеры, то есть объекты реального мира. В конце концов, проще всего понять тип объекта «Заказ клиента», если можно одним нажатием кнопки отобразить маску заказа клиента или отсканированный документ заказа.

Могут ли мыслительные операции, протекающие во время абстракции, быть классифицированы? Характерным типом операций является обобщение (генерализация), которое ищет универсальные свойства в объектах и/ или типах объектов и формирует из них тип объектов на более высоком уровне абстракции. Обратной обобщению является специализация. Обобщенный (генерализированный) тип объектов передает свои свойства по наследству конкретным (специальным) типам объектов. Следующий тип операции – агрегация, которая собирает разные типы объектов в новый тип объектов на более высоком уровне абстракции. Противоположность агрегации – деагрегация или декомпозиция. Наконец, еще известна группировка, которая из соединения нескольких подобных типов объектов формирует новый тип объекта на более высоком уровне. Обратной операцией здесь будет разгруппировка.

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