Метод Horus

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

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

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

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

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

4.1.1. Порядок применения языка моделирования

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

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

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

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

4.1.2. Принцип абстракции

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

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

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

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

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

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

4.1.3. Принцип структурирования

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

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

Далее прежде всего следует рассмотреть два наиболее важных метода структурирования, которые являются неотъемлемыми компонентами Horus Modeller и применяются в методе Horus в различных вариантах.

4.1.3.1. Ракурсы сбалансированной системы показателей

Сбалансированная система показателей (ССП) (Balansed Scorecard — BSc), введенная в 1992 году Капланом и Нортоном, стала в настоящее время излюбленным инструментом управления. Она используется для измерения эффективности компании на основе ключевых показателей эффективности бизнеса (Key Performance Indicators — KPI, или Business Performance Indicators — BPI). В отличие от классических систем измерения, которые фокусируются исключительно на финансовых показателях, особенность ССП в том, что ее показатели отражают различные ракурсы, которые также охватывают реальный производственный процесс и потенциал на будущее. Таким образом ССП решает проблему того, что сами по себе финансовые показатели дают возможность анализа только прошедшего времени, вследствие чего только ограниченно пригодны для упреждающего управления предприятием.

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

• финансы;
• клиенты;
• внутренние процессы;
• потенциал (человеческий капитал, инновация, реновация и рост).

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

4.1.3.2. Стратегия и тактика

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

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

• Стратегия.

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

• Тактика.

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

• Операционный бизнес.

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

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

Тактические вопросы стоят в центре внимания анализа бизнес-процессов (этап 2, см. раздел 4.3). Краеугольным камнем этого этапа являются бизнес-процедуры, которые формируют ядро любой тактики в сочетании с организационной структурой и бизнес-объектами. Затем сюда вплетаются тактические риски, которые представляют угрозу для тактики, и тактические ключевые показатели, которые измеряют эффективность и успех выбранной тактики. С помощью инструментария Horus к тому же могут быть смоделированы тактические цели, однако метод Horus не рекомендует их использовать, так как польза от них в рамках построения моделей в основном ограничена и вряд ли оправдывает затраты на моделирование.

4.2. Этап 1: От миссии к модели архитектуры

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

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

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

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

В рамках, заданных контекстным анализом, посредством SWOT-анализа исследуются сильные (strengths) и слабые (weaknesses) стороны, возможности (opportunities) и угрозы (threats) для предприятия. Результаты имеют решающее значение для приоритетов дальнейшей аналитической работы. Хотя SWOT-анализ не является непосредственным условием для стратегического анализа, мы тем не менее не рекомендуем отказываться от него. Он помогает избежать анализа ненужных деталей и, с другой стороны, не пренебрегать важными областями анализа с высоким потенциалом оптимизации.

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

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

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

4.2.1. Контекстный анализ

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

4.2.1.1. Анализ внешней среды

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

Рис. 4.4 показывает как пример результата анализа внешней среды контекстную модель бизнес-подразделения товаров из кожи одной торговой компании. Любопытно, что управление группой компаний здесь находится за пределами рассматриваемой системы и, следовательно, считается элементом внешней среды. Также филиалы, в определенном смысле «родственные объекты» для подразделения товаров из кожи, рассматриваются — аналогично внешним дистрибьюторам — как элементы внешней среды. Ясно, что для анализа внешней среды необходима абстракция, чтобы только действительно важные элементы внешней среды принимать во внимание, а также выполнять обобщение объектов в один универсальный объект.

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

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

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

4.2.1.2. Анализ добавленной стоимости

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

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

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

4.2.1.3. Определение целей

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

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

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

Полнота является важным фактором проверки достоверности модели целей. Поскольку полнота не может быть формально доказана, разумно говорить не о полноте, а о балансе модели целей. Модель целей тогда находится в балансе (или сбалансирована), если она учитывает все ракурсы предприятия. Поэтому мы рекомендуем уже в момент их создания ориентировать на четыре разреза, которые обсуждались в разделе 4.1.3 в контексте структурирования моделей. Этот подход возвращает нас к системе сбалансированных показателей. На рис. 4.6 общие цели «Финансы», «Клиенты», «Внутренние процессы», а также «Инновация и рост» определены и с помощью специализаций шаг за шагом раздроблены.

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

4.2.2. SWOT-анализ

Все так же следуя подходу «от внешнего к внутреннему», с контекстным анализом тесно связан анализ предприятия, первый из действительно ориентированных на управление. Он намеренно не организован в виде формального процесса, скорее во многих случаях больше похож на мозговой штурм. Лица, принимающие решения, и эксперты сначала обмениваются своими идеями по поводу сильных (strenghts) и слабых (weaknesses) сторон компании. После такого анализа внутренних факторов влияния они обращаются к внешним факторам, определяя таким образом возможности (opportunities) и угрозы, или риски (threats), для предприятия. Этот метод анализа известен как SWOT-анализ (см. комментарии к рис. 4.2).

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

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

4.2.3. Стратегический анализ

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

4.2.3.1. Определение стратегии

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

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

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

4.2.3.2. Анализ показателей эффективности

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

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

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

4.2.3.3. Анализ рисков

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

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

4.2.4. Моделирование архитектуры предприятия

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

4.2.4.1. Анализ архитектуры бизнес-процессов

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

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

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

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

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

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

4.2.4.2. Анализ стратегических бизнес-объектов

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

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

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

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

4.2.4.3. Анализ стратегических бизнес-правил

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

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

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

4.2.4.4. Анализ стратегических бизнес-единиц

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

Полная оргструктура возникает только в конце этапа анализа бизнес-процессов и тогда является производной от моделей бизнес-процедур в совокупности с другими моделями (пример организационной модели Horus см. в разделе 4.3.3, рис. 4.22).

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

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

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

4.2.5. Проектирование системной архитектуры

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

Для плана системной архитектуры Horus предусматривает модель ресурсов, которая описывает ожидаемое целевое состояние архитектуры. Модель ресурсов фокусирует внимание на компонентах для построения системной архитектуры, то есть в первую очередь на аппаратной и сетевой инфраструктуре, а также запланированных программных компонентах. Рис. 4.13 показывает в качестве примера модель системной архитектуры подразделения «Товары из кожи». Она описывает среду приложений Oracle, которая подразделяется на аппаратное обеспечение, системное программное обеспечение и компоненты прикладного ПО. Подчиненные компоненты сами могут также далее быть разложены, как это показано на примере рабочей среды. Системная архитектура уже хорошо конкретизирована, особенно то, что касается программных приложений. Это также необходимо, поскольку модель системной архитектуры закладывает основу для расчета бюджета и ROI. В отношении аппаратных средств можно исходить из прошлого опыта, так что здесь мы можем обойтись без конкретизации в смысле торговых марок.

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

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

4.3. Этап 2: Анализ бизнес-процессов

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

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

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

Анализ организационной структуры включает в себя проектирование организационной структуры с определением компетенций и зон ответственности. Наконец на основе процедур и организационной структуры определяются ключевые показатели и риски. Обе области задач: анализ ключевых показателей и анализ рисков — тесно взаимосвязаны и поэтому часто обрабатываются параллельно.

4.3.0.1. Определение стратегии моделирования

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

4.3.1. Структурный анализ

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

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

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

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

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

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

4.3.1.2. Моделирование бизнес-правил

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

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

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

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

4.3.2. Процедурный анализ

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

4.3.2.1. Процедурный анализ по методу бизнес-событий

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

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

Рис. 4.19 иллюстрирует пример анализа событий. Здесь «Запрос» интерпретируется как выходное событие, а «Заявка-потребность» и «Плановая потребность» — как входные. Исходя из «Запроса» находится действие «Создать запрос», которое через хранилище объектов «Потенциальные поставщики» ведет к действию «Определить источник поставки» и, наконец, к действию «Запланировать потребность», которое запускается посредством заявок-потребностей и рассчитанных плановых потребностей.

4.3.2.2. Процедурный анализ по методу прецедентов

Как альтернатива анализу событий процедурный анализ также предлагается по методу прецедентов. Его преимущество — ниже требования к навыкам абстрактного мышления моделировщика. Прецеденты (Use Cases) собираются и преобразуются в простые фрагменты модели. Эти фрагменты затем группируются по предметному критерию и интегрируются во взаимосвязанные процедурные модели. Интеграция происходит главным образом через совместно используемые хранилища объектов или последовательности действий.

Рис. 4.20 представляет принцип метода прецедентов. Моделируются отдельные прецеденты для обработки заявок-потребностей либо плановых потребностей. Для интеграции этих прецедентов в таком случае предлагается действие «Определить источник поставки», которое в обоих случаях происходит на основе каталога поставщиков и для каждого определяет потенциальных поставщиков. Интегрированная процедурная модель могла бы тогда выглядеть как на рис. 4.19. Ясно, что на практике центральная интеграционная структура не всегда так очевидна, как в этом примере. Идентичное содержание часто скрывается за по-разному обозначенными действиями и объектами.

4.3.2.3. Типизация хранилищ объектов и моделирование контекста объектов

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

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

4.3.2.4. Моделирование контекста бизнес-правил

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

4.3.3. Анализ организационной структуры

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

4.3.3.1. Моделирование организационной структуры

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

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

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

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

4.3.3.2. Установление связей с организационной структурой

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

4.3.3.3. Моделирование ресурсов

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

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

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

4.3.4. Анализ ключевых показателей

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

4.3.4.1. Процедурно-ориентированный анализ ключевых показателей

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

4.3.4.2. Организационно-ориентированный анализ ключевых показателей

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

Рис. 4.24 показывает в качестве примера систему ключевых показателей для подразделения «Товары из кожи». Изображенная модель ключевых показателей структурирована в соответствии с описанными выше ракурсами сбалансированной системы показателей, как это часто встречается на практике. В обиходе также и другие критерии структурирования, как, например, по различным бизнес-единицам, продуктовым линейкам, зонам ответственности, или также комбинация из различных критериев. Для объемных систем ключевых показателей в любом случае применяются обобщения либо специализации, формирующие иерархический порядок веток ключевых показателей. На примере это показано для «Рентабельности», которая представляет собой обобщение «Рентабельности продаж», «Рентабельности совокупного капитала», и «Возврата инвестиций (ROI)». «Качество» также смоделировано в виде обобщения, которое измеряется по общей сумме четырех различных показателей. Интересна здесь «Доля возвратов», которая одновременно представляет собой специализацию «Качества» и «Уровня сервиса».

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

Ключевые показатели связываются ссылками с организационными единицами. Таким образом определяется «владелец» ключевого показателя. Он несет ответственность за описание ключевого показателя и контроль его исполнения (мониторинг). Ссылки на действия в процедурной модели документируют, к каким действиям относится ключевой показатель.

4.3.5. Анализ рисков

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

4.3.5.1. Процедурно-ориентированный анализ рисков

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

4.3.5.2. Организационно-ориентированный анализ рисков

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

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

Для лучшей визуализации риски обычно группируются в форме обобщений, как в нашем случае, например, «риски несоответствия нормам», которые включают в себя риски Закона Сарбейнза — Оксли (SOX) и Good Manufacturing Practice (GMP), а также риски в силу нарушений Общепринятых принципов бухгалтерского учета (GAAP). Интересно также, что риски GAAP посредством другого обобщения одновременно также привязаны к области финансов.

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

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

4.4. Имитационное моделирование

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

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

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

4.4.1. Цикл имитационного моделирования

Имитационное моделирование в методе Horus основано на формально определенной имитации XML-сетей, описанной в разделе 3 и также в литературе. Здесь оно будет расширено возможностями для параметризации моделей (см. раздел 4.4.3) и встроено в методический подход. Имитационное моделирование по сути представляет собой повторяющийся процесс. Поэтому далеко недостаточно ввести методический этап «Имитационное моделирование», имитация скорее должна быть истолкована как циклический процесс, который затем целенаправленно вводится в методический подход.

На рис. 4.27 изображен цикл имитации, состоящий из шести шагов. Исходный пункт — это определение целей имитации в сочетании с выбранной стратегией имитации. Этот первый шаг абсолютно необходим, так как здесь прокладывается путь для издержек, возникающих в результате имитации. Так что на практике, как правило, не имеет смысла моделировать все без исключения бизнес-процессы со всеми их взаимозависимостями и вслед за этим проводить имитацию. Что такая «общая имитация» должна доказать, что продемонстрировать? Из каких результатов имитации какие выводы надлежит сделать? Вопросы такого рода должны задаваться до того, как инвестировать в имитацию. Соображения, ориентированные на пользу, быстро приведут к ограничению объема имитации только теми процедурами, которые по причине их сложности, их способности к изменению или их зависимости от внешних влияний нуждаются в более тщательном анализе. В качестве альтернативы должны быть выработаны суждения о поведении процедуры «под нагрузкой». На первом шаге дается ответ на три вопроса: что будет имитироваться, для чего и как?

В рамках имитационного моделирования в основном различные альтернативы решения сравниваются друг с другом. Поэтому сначала в области, относящейся к имитации, подготавливаются варианты моделей, которые затем посредством имитации оцениваются и сравниваются между собой. Варианты моделей часто отличаются только их параметризацией (см. раздел 4.4.3); в других случаях структурно разные модели сравниваются друг с другом. Шаг 3 включает в себя только что упомянутую параметризацию — расширенные атрибуты элементов модели, выходящие за границы представленной в разделе 3 нотации XML-сетей. Имитация в XLM-сетях предоставляет, так сказать, «семантику носителя» для исполнения гораздо более всеобъемлющих бизнес-процессов Horus. Шаг 4 охватывает затем собственно имитацию вариантов модели, которая происходит в форме интерпретации и исполнения моделей. Полученные в результате динамические данные имитации на шаге 5 анализируются и сравниваются друг с другом либо с эталонными образцами — бенчмарками (см. также раздел 4.4.5). В заключение результаты имитации визуализируются. Визуализация здесь обозначает графическую анимацию процедур, а также представление результатов анализа в форме бизнес-графиков и табличных отчетов.

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

4.4.2. Области применения

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

4.4.2.1. Этап 1: Стратегия и архитектура

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

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

4.4.2.2. Этап 2: Анализ бизнес-процессов

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

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

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

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

4.4.2.3. Этап 3: Использование

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

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

4.4.3. Создание вариантов моделей и их параметризация

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

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

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

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

4.4.3.1. Сеансы имитации

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

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

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

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

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

4.4.3.2. Действия

Действиям как активным элементам XML-сети принадлежит наибольшее значение при имитации. Они содержат в себе множество имитационных параметров, дающих основу многообразным возможностям применения имитации. Одной важной областью является Расчет затрат процесса (activity-based costing, см. раздел 4.4.4), для которого имитация обеспечивает необходимые цифры. Для этого для действий устанавливаются затраты, возникающие каждый раз при выполнении этого действия. Для затрат указываются максимальное, минимальное и среднее значения, что позволяет отобразить ожидаемый диапазон их колебаний. При выполнении действия помимо непосредственно затрат на обработку, как правило, возникают также транспортные расходы. Этот тип затрат включает расходы как на транспортировку к месту обработки и в ходе обработки (перемещение), так и на отправку на дальнейшую обработку или на склад. На практике очень распространен метод, когда для дорогостоящей транспортировки вводятся собственные действия, которые в таком случае порождают только транспортные расходы, без расходов на обработку. Как альтернатива в подобных случаях затраты на разгрузку-погрузку учитываются как затраты на обработку для действия по транспортировке.

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

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

Правило перехода для XML-сетей исходит из простой временно́й модели, в которой довольно трудно воспроизвести факты управления бизнесом, относящиеся к анализу времени и к анализу емкости. Поэтому Horus-метод расширил эту временну́ю модель для большего соответствия практическим нуждам, что нашло свое отражение в ряде параметров для исполнения, задаваемых на уровне отдельных действий. Эти параметры тем не менее не изменяют правила перехода и даже не увеличивают количество возможных срабатываний, а, напротив, ограничивают количество возможных срабатываний переходов. Это происходит в первую очередь за счет выбора допустимых для исполнения действия дней недели. Интервал исполнения, применяемый для всех выбранных дней, задает в форме времени начала и окончания временной интервал, внутри которого данное действие может быть исполнено. Однако это также означает, что выполнение действия должно полностью вписываться в заданный интервал. Если необходимо иметь возможность прерывания выполнения, то должен дополнительно быть использован специально для этого предназначенный параметр. Описанных здесь параметров для исполнения действия уже достаточно для многих вариантов практического применения, когда, например, должна быть установлена только рабочая неделя (с понедельника по пятницу) в сочетании со стандартным рабочим днем (8:00–17:00). Для более детального анализа существуют возможности, предлагаемые параметрами ролей и ресурсов.

Интересно ассоциировать результаты имитации, основанные на времени и емкостях, с соображениями о качестве результатов процесса. Для этого каждому действию можно присвоить «показатель качества» и «коэффициент ошибок». Через них как процентная ставка заданного показателя качества определяется, какие воздействия производит выполнение действия на выпускаемые объекты. В процессе исполнения действия качество может ухудшаться (<0%), оставаться неизменным (0%), а также улучшаться (>0%). Коэффициент ошибок определяет частоту повторения ошибок, производимых в ходе выполнения действия.

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

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

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

4.4.3.3. Хранилище объектов

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

Посредством параметра емкости устанавливается, какое максимальное число объектов может находиться в хранилище объектов. Само собой разумеется, можно также работать с емкостью, равной ∞. Поскольку XML-сети работают с различаемыми объектами, для бизнес-управленческих ситуаций существенно, какой именно объект каждый раз извлекается из данного хранилища объектов. По умолчанию метод Horus предусматривает стратегию FIFO (First In, First Out), при которой всегда извлекается наиболее возможно старый объект. Посредством соответствующего параметра пользователь может выбрать альтернативную стратегию изъятия: LIFO (Last In, First Out), HIFO (Highest In, First Out), LOFO (Lowest In, First Out). Данные о последовательности (первый, последний) в данном случае относятся к временным меткам хранящихся объектов, в то время как данные о размерах (высший, низший) отражают стоимость объекта.

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

4.4.3.4. Связи

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

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

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

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

• Считывание: в случаях объектов на чтение временные затраты не переносятся, чтобы позже не спровоцировать искусственного завышения времени обработки объектов.
• Вход: для входящих связей параметр устанавливает, какая часть положенных на обработку потребляемого объекта временных затрат в процессе действия переносится на него. Теоретически здесь напрашивается значение 100%, что, однако, не всегда осуществимо на практике. Подумайте о вспомогательных и производственных материалах, прекрасно отражающих время обработки и хранения, которое, однако, не должно добавляться к временным затратам объекта «конечный продукт».
• Выход: параметр временных затрат выходящей связи определяет, какая часть затраченного времени на самом деле должна быть начислена на выходной объект. В случае объектов, которые не возникают в результате обработки предшествующих объектов, но действительно создаются в ходе данного действия, этот параметр устанавливается равным 0%. Ноль процентов в этом случае означает, что выходному объекту начисляется исключительно время обработки создающего его действия.

4.4.3.5. Роли

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

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

4.4.3.6. Ресурсы

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

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

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

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

4.4.4. Имитация с учетом добавленной стоимости, затрат, времени и качества

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

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

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

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

Для последующей методологической дискуссии мы прибегнем к примеру из области производства товаров из кожи, который представлен на рис. 4.29. Рисунок показывает действие «Штамповка», в котором «Заготовка» (для простоты здесь мы абстрагируемся от возможности работать с партиями) после обработки на «Штамповочном станке» превращается в «Штампованную деталь». Сам штамповочный станок рассматривается как ресурс. Для простоты отсутствует штамповочный инструмент, чье использование на практике систематически имеет особенно большое влияние на затраты и качество и который нередко представляет собой «узкое место» емкости. Штамповочный инструмент можно было бы учитывать как в качестве ресурса, так и в качестве объекта, находящегося в накопителе объектов. Последний подход предпочтительнее, когда изготовление инструмента также имеет место в ходе исследуемого бизнес-процесса. Уже этот небольшой экскурс проясняет, что в рамках метода Horus, безусловно, достаточно степени свободы, которую моделировщик может применять для упрощения модели, но также, прежде всего, для отображения бизнес-требований максимально возможно точным и элегантным способом.

Общие затраты на действие «Штамповка» при однократном исполнении можно в таком случае упрощенно рассчитать по следующей схеме:

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

На рис. 4.29 для каждого отдельного элемента модели заданы все параметры, которые имеют отношение к стоимости, затратам, времени и качеству (за разъяснением параметров обращайтесь к разделу 4.4.3). Не проиллюстрировано размещение в хранилищах объектов конкретных объектов. Это размещение появляется на рис. 4.30. Здесь показано размещение до и после выполнения этапов имитации. В левой части рисунка дается объект в ожидании обработки с избранными атрибутами. Значения атрибутов отражают «историю» объекта, то есть речь идет, например, о затратах, которые непременно лягут на объект «в ходе его путешествия через модель бизнес-процесса». В правой части рисунка представлен произведенный после исполнения действия «Штамповка» объект «Штампованная деталь» со своими подробностями. Для простоты мы опустили различение между минимальным, максимальным и средним значениями, так что при необходимости всегда указывается среднее значение. На рисунке отсутствуют подробности объекта в хранилище объектов «Специальное обучение». Поскольку они не играют никакой роли для учета затрат и времени, без этих деталей в нашем примере можно обойтись. Причина кроется в параметрах связи между хранилищем объекта «Специальное обучение» и действием «Штамповка», которые установлены на 0% и тем самым обеспечивают, что ни затраты объекта, ни время объекта не переносятся на действие.

В дальнейшем задаются упрощенные формулы для расчета значений атрибутов объекта «Штампованная деталь» после срабатывания действия «Штамповка». Упрощение представляет собой пренебрежение мультипликаторами объектов (в примере всегда 1), а также количеством требуемых работников и ресурсов (в примере также всегда 1) и параметрами материальных и временных затрат на объект «Штампованная деталь» (здесь всегда 100%). Соответствующие параметры указываются для каждого из объектов «Заготовка» (100%) и «Специальное обучение» (0%). Расчет «накопленной в штампованной детали» добавленной стоимости происходит затем по следующей формуле:

добавленная стоимость (Штампованная деталь) = 100%-ная добавленная стоимость (Заготовка) + 0%-ная добавленная стоимость (Специальное обучение) + добавленная стоимость (Штамповка)

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

расход материала (Штампованная деталь) = 100%-ный расход материала (Заготовка) + 0%-ный расход материала (Специальное обучение)

Эта система — с учетом соотнесенных ролей и ресурсов — применяется для различных типов затрат:

затраты на персонал (Штампованная деталь) = 100%-ные затраты на персонал (Заготовка) + 0%-ные затраты на персонал (Специальное обучение) + (время обработки (Штамповка) + время транспортировки (Штамповка) + время пусконаладки (Штамповка)) × затраты (Работник)

затраты на ресурсы (Штампованная деталь) = 100%-ные затраты на ресурсы (Заготовка) + 0%-ные затраты на ресурсы (Специальное обучение) + время обработки (Штамповка) × затраты (Штамповочный станок)

затраты на обработку (Штампованная деталь) = 100%-ные затраты на обработку (Заготовка) + 0%-ные затраты на обработку (Специальное обучение) + затраты на обработку (Штамповка)

затраты на пусконаладку (Штампованная деталь) = 100%-ные затраты на пусконаладку (Заготовка) + 0%-ные затраты на пусконаладку (Специальное обучение) + затраты на пусконаладку (Штамповочный станок)

затраты на транспортировку (Штампованная деталь) = 100%-ные затраты на транспортировку (Заготовка) + 0%-ные затраты на транспортировку (Специальное обучение) + затраты на транспортировку (Штамповка)

затраты на хранение (Штампованная деталь) = 100%-ные (Затраты на хранение (Заготовка) + срок хранения (Заготовка) × переменные затраты на хранение (Заготовка)) + 0%-ные (Затраты на хранение (Специальное обучение) + срок хранения (Специальное обучение) × переменные затраты на хранение (Специальное обучение)) + затраты на транспортировку (Штамповка)

Есть одна особенность касательно срока хранения. Его всегда можно вычислить только в момент изъятия каждого объекта из хранилища объектов через формирование разницы с моментом начала хранения.

При расчете различных временных компонентов поступают аналогичным образом, как и с затратами. Только теперь 100% или 0% вытекают не из доли материальных затрат на объект, а из доли временных затрат на объект:

время обработки (Штампованная деталь) = 100%-ное время обработки (Заготовка) + 0%-ное время обработки (Специальное обучение) + время обработки (Штамповка)

время пусконаладки (Штампованная деталь) = 100%-ное время пусконаладки (Заготовка) + 0%-ное время пусконаладки (Специальное обучение) + время пусконаладки (Штамповочный станок)

время транспортировки (Штампованная деталь) = 100%-ное время транспортировки (Заготовка) + 0%-ное время транспортировки (Специальное обучение) + время транспортировки (Штамповка)

время ожидания (Штампованная деталь) = 100% (время ожидания (Заготовка) + срок хранения (Заготовка)) + 0% (время ожидания (Специальное обучение) + срок хранения (Специальное обучение))

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

Показатель качества (Штампованная деталь) = (показатель качества (Заготовка) + срок хранения (Заготовка) × изменение качества (Заготовка)) × (показатель качества (Специальное обучение) + срок хранения (Специальное обучение) × изменение качества (Специальное обучение)) × показатель качества (Штамповка) × показатель качества (Работник) × показатель качества (Штамповочный станок)

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

4.4.5. Анализ сеансов имитации

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

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

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

4.4.5.1. Анализ активаций и срабатываний переходов

Действия

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

Хранилища объектов

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

Роли и сотрудники

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

Ресурсы

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

4.4.5.2. Анализ состояний

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

Размещение объектов в хранилищах

Размещение объектов в хранилищах на протяжении времени — с особым вниманием к пикам емкости — позволяет сделать интересные заключения о загрузке и, таким образом, необходимых емкостях; будь то емкости склада или памяти или даже требуемые ресурсы, если это было смоделировано в сети в виде объектов. В большинстве случаев общее представление о размещении объектов в хранилищах используется в качестве отправной точки для детального исследования (Drill-Down) конкретных находящихся в них объектов.

4.4.5.3. Анализ объектов

Анализ стоимости и затрат

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

Анализ на основе времени

Аналогично анализу затрат предлагается также анализ временных атрибутов, которые содержат объекты. Как распределяется время на обработку, пусконаладку, транспортировку и ожидание и каковы минимальные и максимальные значения?

Анализ качества

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

4.5. Управление бизнес-процессами и их внедрение

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

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

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

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

4.5.1. Управление бизнес-процессами по методу Horus

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

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

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

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

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

4.5.2. Абстрактное внедрение бизнес-процессов

Большинство встречающихся сегодня на рынке BPM-решений ставят во главу угла исполнение бизнес-процессов. На первый взгляд это само напрашивается, ведь здесь предполагается наибольший потенциал оптимизации. Это верно прежде всего тогда, когда среда исполнения представляет собой сервис-ориентированную архитектуру. Такого рода архитектура претендует на сокращение затрат на внедрение посредством предоставления сервисов для многократного использования и их оркестровки со сквозными процессами и таким образом на достижение высокого качества результатов. С учетом этого потенциала для оптимизации на уровне бизнес-процессов также находят распространение языки моделирования, которые позволяют простое и в идеале даже двунаправленное представление бизнес-процессов в исполняемой форме. Типичный представитель — BPMN, Business Process Modeling Notation, предложенная OMG, которая прежде всего обеспечивает простую и эффективно автоматизируемую трансформацию в BPEL-процессы. Обратный обмен BPEL-структур с BPMN также может быть достигнут довольно легко, так что изменения во внедренных BPEL-процессах могут «подтягиваться» в модели BPMN. В таком контексте говорят о замкнутом цикле (Roundtrip), который намного упрощает поддержание согласованности между различными уровнями BPM-архитектуры.

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

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

Рис. 4.32 показывает взаимосвязи абстрактного внедрения по методу Horus. Ключевой является модель внедрения бизнес-процессов. Формально она представляет собой совокупность XML-сетей, образующих декомпозицию действий модели бизнес-процесса. Однако первоначально напрашивающаяся декомпозиция «сверху вниз» не приводит здесь, как правило, к цели, поскольку она помешала бы переключить перспективу с бизнес-процессов на бизнес-сервисы. Сначала в контексте проходящей через всю модель бизнес-процесса структуры требований должно быть предпринято структурирование абстрактного уровня бизнес-сервисов. Аспекты структурирования — это затраты, время, соблюдаемые стандарты (compliance), управляемость (governance), техническая осуществимость и цель максимально возможно высокой степени переиспользования. Полученная отсюда структура образует каркас для оркестровки бизнес-сервисов в модели внедрения бизнес-процессов. Как происходит такая оркестровка, будет описано в следующем разделе.

4.5.3. Оркестровка бизнес-сервисов

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

На рис. 4.33 в нижней части изображены два бизнес-сервиса «От премиум-клиента до повторного заказа» и «От возможности до клиента». Ради простоты они графически проиллюстрированы пунктирными квадратиками с указанными на интерфейсах хранилищами объектов. На рис. 4.33 (а) показано прямое соединение для хранилища объектов «Клиент»: входное хранилище объектов «Премиум-клиент» из бизнес-сервиса «От премиум-клиента до повторного заказа» подходит к выходному хранилищу объектов «Клиент» бизнес-сервиса «От возможности до клиента» и может поэтому быть объединено с ним при оркестровке. Хотя «подходит» — как и в данном примере — не обязательно означает, что элементы называются одинаково. В примере поэтому хранилище объектов «Премиум-клиент» для слияния было переименовано в «Клиент». Далее действие бизнес-сервиса «От премиум-клиента до повторного заказа» в соркестрованной модели должно быть также снабжено ограничением (например, годовой оборот > 1 млн евро), которое гарантирует, что обрабатываются на самом деле только премиум-клиенты. В завершение затем добавляется еще одно действие, которое обрабатывает не премиум-клиентов. Уже этот маленький пример показывает, что оркестровка также может быть совершенно творческим процессом.

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

4.5.4. Физическое внедрение бизнес-сервисов

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

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

4.5.4.1. Организационные регламенты

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

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

4.5.4.2. Традиционное внедрение в унаследованной среде

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

4.5.4.3. Внедрение в сервис-ориентированной архитектуре (СОА)

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

В табл. 4.1 перечислено, где модели Horus находятся в контексте внедрения сервис-ориентированной архитектуры.

4.5.4.4. Внедрение стандартного прикладного программного обеспечения

Новые технологии и парадигмы в ИТ регулярно взывают к новым моделям и подходам даже при внедрении стандартного прикладного программного обеспечения (ПО), как, например, SAP, приложения Oracle, Microsoft Dynamics или 1С: Предприятие. Для описания и внедрения такого рода ПО требуются подходы, управляемые моделями. Кроме того, можно заметить, что возрастающий рыночный спрос на сервис-ориентированные решения сам по себе подталкивает крупных производителей программного обеспечения в этом направлении. До сих пор внедрение стандартного ПО происходило в рамках классического программного инжиниринга (Software Engineering), начиная с анализа требований вплоть до ввода системы в эксплуатацию. Моделирование внедряемых бизнес-процессов в рамках анализа требований подготавливает основу для дизайна и архитектуры системы. Проблематика данного подхода при внедрении стандартного ПО заключается в отклонении специфических бизнес-процессов компании от заданных процессов стандартного прикладного ПО. Подход многослойной модели, лежащий в основе метода Horus, позволяет в зависимости от уровня абстракции представить бизнес-сервисы, то есть функциональность стандартного ПО, на различных уровнях. Модели бизнес-процесса в сочетании с моделями бизнес-сервисов, как предусмотрено по методу Horus, уменьшают сложность и позволяют гибкое управление бизнес-процессами через оркестровку бизнес-сервисов. Их можно горизонтально комбинировать в сквозные бизнес-процессы и через декомпозицию вертикально связывать друг с другом. Внедрение этих процессов может происходить на основе отраслевого стандарта BPEL, который уже используется во многих стандартных программных продуктах для системной интеграции.

4.5.5. Порталы бизнес-процессов и управление эффективностью бизнеса

В основе управления бизнес-процессами Horus лежат три принципа, которые отражены в BPM-архитектуре, но также в предоставленных в распоряжение методах и программных средствах.

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

Хотя эти принципы могут показаться очевидными, на практике их, однако, очень сложно реализовать, и нередко из-за довольно значительного сопротивления от самой заинтересованной организации. Активное участие бизнес-сообщества приводит в конце концов к эмансипации, то есть предоставлению свободы бизнес-подразделениям, и впоследствии часто к существенным претензиям к качеству и объему запрошенных ИТ-услуг. Не каждые пользователь и бизнес-подразделение действительно заинтересованы в полной прозрачности относительно своей эффективности и производительности. К тому же здесь также нельзя упускать из виду условия труда. Наконец, потребность в непрерывном улучшении бизнес-процессов часто сталкивается с бюджетными ограничениями и, к сожалению, нередко с неприятием пользователей, которые «всегда же так это делали». Эти разъяснения четко показывают, что управление бизнес-процессами требует не только методов и инструментов, но и в значительной степени эффективной подготовки и проведения организационных изменений: управление изменениями — фактор успеха № 1 в управлении бизнес-процессами!

Очень важный инструмент для управления изменениями — это порталы бизнес-процессов, через которые происходит эффективная и экономичная интеграция бизнес-сообщества. Рис. 4.34 показывает типичную структуру такого портала. Он основывается на репозитории, в котором хранятся данные моделей и связи со средой выполнения. Автоматизированные процессы обеспечивают непрерывный мониторинг бизнес-производительности и эффективную обработку эскалаций в рамках управления бизнес-процессами на основе показателей эффективности. С целью максимального удобства использования различные группы пользователей интегрируются посредством персонализации: менеджмент и сотрудники (B2E — Business-to-Employee), различные бизнес-партнеры (B2B — Business-to-Business), корпоративные и частные клиенты (B2C — Business-to-Customer) и все больше и больше государственные органы (B2G — Business-to-Government). Нужно отметить, что в областях B2B и B2G также все чаще приходится реализовывать концепции, в которых доступ к содержанию бизнес-процессов и ВРМ-портала должен быть обеспечен через внешние порталы партнера. Точно так же сегодня обычная практика — мобильные порталы, особенно на карманных компьютерах (PDA), планшетах и смартфонах.

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

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

4.6. Модели передового опыта и эталонные модели

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

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

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

Далее мы будем говорить о моделях передового опыта каждый раз тогда, когда мы подразумеваем переиспользование в целом. Для эталонных моделей, с другой стороны, мы предполагаем запланированное переиспользование. К их содержанию тогда также предъявляются особые требования, и должно быть ясно, в каком контексте и при каких условиях они могут применяться. И также должно быть указано, каким образом они параметризуются. Термин, который в связи с этим находит применение, — «база знаний». Согласно методу Horus мы говорим о базе знаний в целом тогда, когда артефакты любого вида — то есть не только модели или фрагменты модели, но также и программные блоки и т.д. — доступны для повторного использования.

Ниже показано, какие техники метод Horus предусматривает для переиспользования. Эти техники в любое время могут быть использованы для построения библиотек моделей передового опыта. И они также образуют фундамент для Баз знаний Horus™.

Метод Horus знает два типа моделей передового опыта: модели бизнес-процессов и модели бизнес-сервисов. Они возвращают нас обратно к представленной в разделе 4.5.1 концепции управления бизнес-процессами (BPM) по методу Horus: модели бизнес-процессов используются на уровне бизнес-целей и стратегий, как и на уровне собственно бизнес-процессов. Модели бизнес-сервисов создают переход к уровню бизнес-сервисов и далее вплоть до внедрения процессов.

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

4.6.1. Модели отраслевых бизнес-процессов

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

При этом метод Horus следует соображениям, которые различные отраслевые объединения уже реализовали в виде соответствующих эталонных моделей. В качестве примеров можно упомянуть расширенную карту процессов деятельности телекоммуникационной компании (Enhanced Telecom Operations Map®, сокращенно: eTOM®), поддерживаемую TeleManagement Forum, и эталонную модель операций цепочки поставок (Supply Chain Operations Reference Model, сокращенно: SCOR®), поддерживаемую Supply Chain Council. С обеими эталонными моделями мы познакомимся в разделе 5.1.4.

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

Следуя основным принципам метода Horus, модель передового опыта предлагает начать с контекстной модели, чтобы иметь возможность сделать некую расстановку в предполагаемой целевой предметной области. Затем модель архитектуры бизнес-процессов дает обзор содержащихся в модели передового опыта бизнес-процессов. Каждый из них, в свою очередь, декомпозируется в многоуровневую иерархию моделей бизнес-процессов. Модели уровня 1 описывают каждая один основной процесс. Это может быть как целое подразделение (например, зеленые биотехнологии в компании, специализирующейся на науках о жизни), так и только одна приоритетная задача, как здесь, например, «обслуживание клиентов». Уровень 2 отражает декомпозицию действий основного процесса, как в нашем примере «выездная служба». Декомпозиция часто заканчивается на уровне 3, на котором действия в большинстве случаев уже детализированы до уровня бизнес-операций, например «поставка запчастей». Такой степени декомпозиции в основном вполне достаточно, когда еще раз выясняется, что да, внедрение затем намечается в форме абстрактных бизнес-сервисов. На рисунке иллюстративно задан еще один бизнес-сервис «Заказ запчасти», чтобы пояснить переход к уровню бизнес-сервисов.

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

4.6.2. Модели бизнес-сервисов на основе передового опыта

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

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

Рис. 4.37 показывает предусматриваемую методом Horus структуру модели бизнес-сервисов на основе передового опыта. На левой стороне рисунка для расстановки уровней моделей изображены соответствующие уровни из концепции BPM метода Horus. Корень дерева моделей образует — как правило, но не обязательно, поскольку метод Horus также предусматривает атомарные бизнес-сервисы на основе передового опыта — модель композитных бизнес-сервисов, то есть такой бизнес-сервис, который образуется путем оркестровки различных базовых бизнес-сервисов. Чтобы установить связь с другими методами моделирования, композитный бизнес-сервис может также рассматриваться как бизнес-поток (business flow). На уровне 1 смоделированы базовые бизнес-сервисы. Они также могут отдельно от композитного бизнес-сервиса использоваться в рамках абстрактного внедрения бизнес-процесса. Уровень 2 предлагает обзор каждого процесса, который составляет ядро базового бизнес-сервиса. Как это происходит путем оркестровки подпроцессов, иллюстрирует уровень 3. Здесь необходимо отметить, что глубина спецификации модели передового опыта есть только результат опыта, который на практике может совершенно различаться, особенно когда обрабатываются особо простые или особо сложные и объемные сервисы.

На уровне 3, как правило, также происходит назначение ролей для определения зон ответственности. И тогда, само собой разумеется, следует смоделировать также подробные спецификации для задач конкретной роли. Это происходит на уровне 4 в форме пользовательских инструкций, специальном типе моделей бизнес-сервисов.

Применение описанной концепции представлено на рис. 4.38 на примере фрагмента профессионально внедренной модели бизнес-сервисов на основе передового опыта из управления цепочками поставок. Сначала показана модель композитного бизнес-сервиса, который иллюстрирует бизнес-поток «от Прогнозирования до Пополнения запасов» (Forecast2Replenishment). Он начинается с превращения плана продаж в прогноз («План продаж -> Прогноз», SalesPlan2Forecast) и затем в план потребности по товарным позициям («Прогноз -> План потребности», Forecast2DemandPlan), который каждый раз на повторяющейся основе обновляет текущий товарный запас. Исходя из этого непрерывно оцениваются потребности в материалах («План потребности -> Пополнение запасов», Demand2Replenishment), которые затем ведут к заказам на закупку («Заявка -> Заказ на закупку», Requisition2PurchaseOrder) или заказам на склад («Запас -> Запас», Stock2Stock).

Базовый бизнес-сервис для оценки потребности («План потребности -> Пополнение запасов», DemandPlan2Replenishment) в виде декомпозиции представлен в модели уровня 1. Приятно видеть различные типы оценки потребности, которые, конечно, в конкретных проектах во многих случаях не все нужны. Однако понятно, что, к примеру, удаление «Закупки по Канбан» намного проще осуществить, чем быть вынужденным полностью заново — так сказать, с чистого листа — моделировать его в другом проекте. Рисунок завершается моделью уровня 2 с подробностями для «Закупки по Минимакс (Min-Max)». В этой модели находятся действия, подписанные «UIN!». Это значит, что за таким действием стоит руководство к действию в зависимости от роли в форме пользовательской инструкции (User Instruction). Переход к пользовательским инструкциям в этом простом примере происходит уже на уровне 3, а не только на уровне 4.

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

Упражнение 4.1

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

— Из каких этапов состоит данный метод?

— О чем необходимо позаботиться в рамках контекстного анализа?

— Почему метод Horus начинается именно с этого?

— Что необходимо сделать на этапах 1 и 2 метода Horus?

— В чем смысл имитационного моделирования?

— Как от законченных моделей бизнес-процесса перейти к внедрению?

— Какую роль играют эталонные модели?

При необходимости обращайтесь за подсказками к рис. 4.1. Резюмируйте метод Horus собственными словами.

Упражнение 4.2

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

Упражнение 4.3

Рассмотрите еще раз упражнение 3.3 (подача и проверка заявки на кредит в банке). Примените метод Horus для этого простого примера. Пройдите при этом все этапы метода без исключения и приведите результаты каждого этапа. На этапе 2 обратите особое внимание на анализ бизнес-процедур и рисков.

Упражнение 4.4

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

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

На темы моделирования бизнес-процессов и управления бизнес-процессами существует обширная литература — как в форме книг, так и в форме многочисленных авторских работ. Методы и методологии BPM схожей с методом Horus направленности описываются, например, в работах Weske (2007), которые основываются на BPMN (вместе с вытекающими отсюда и обсуждавшимися выше ограничениями) или ARIS (Architecture of Integrated Information Systems, Архитектура интегрированных информационных систем) — в работах Sheer (2002); с последним также сравнивают, например, Seidlmeier (2006) или Lehmann (2007). ARIS также описан у Davis (2001, 2008) или у Davis & Brabander (2007). Как отмечено в разделе 4.5, хотя большинство встречающихся сегодня на рынке BPM-решений ставят во главу угла исполнение бизнес-процессов, но, как должно стать ясно из этой главы, метод Horus выходит далеко за эти пределы.

Концепция сбалансированной системы показателей берет свое начало в работах Kaplan и Norton (1992, 1993). На эту тему существует многочисленная литература, среди нее Kaplan и Norton (1996, 2000, 2008) или работа на немецком языке Kaplan и др. (1997).

Введение в SWOT-анализ представлено у Fine (2009). Vose (2008), Gottin & Doehler (2009) тщательно рассматривают тему анализа рисков. Введение в область имитационного моделирования можно найти у Ross (2006) или у Sokolowski и Banks (2009), а также у Bungartz и др. (2009).

Бизнес-правила, состоящие из событий, условий и действий, тесно связаны с правилами Событие-Условие-Действие (Event-Condition-Action, ECA), используемыми в активных базах данных; это можно найти у Garcia-Molina и др. (2008) или Silberschatz и др. (2010), или сравните Vossen (2007) или Dittrich & Gatziu (2000).

Отраслевые модели бизнес-процессов либо эталонные модели существуют для бесчисленных областей применения, среди которых торговля, см. Becker & Schuette (2004), или электронное правительство, см. Becker и др. (2009).

В интернете можно найти множество других методов и инструментов моделирования, включая следующие ссылки:

• для BPMN: ;
• Signavio Process Editor: ;
• ARIS Express: .

Отправить