Что представляет метод horus при моделировании бизнес процессов

1.3.2. Horus: Бизнес-процессы для бизнес-сообществ

В результате многолетних исследований в Институте прикладной информатики и методов формализованного описания (AIFB) Технологического института Карлсруэ (KIT) и в Исследовательском центре информатики Карлсруэ (FZI) в сотрудничестве с отраслевым партнером PROMATIS Software GmbH появилось совершенно новое поколение средств для поддержки всего жизненного цикла моделирования бизнес-процессов под названием Horus[2]. Основной целью исследования было сделать возможным участие и взаимодействие всех членов бизнес-сообщества. Здесь пришли на помощь технические возможности, ставшие доступными в контексте социализации интернета. Horus ориентирован на функционирование бизнес-сообщества, не нарушая хода его работы и обходясь при этом без специальной подготовки. Далее кратко представлены важнейшие компоненты Horus.

Данный текст является ознакомительным фрагментом.

3.1.2. Имитация

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

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

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

3.1.3. Анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● бизнес-процессы;

● объекты;

● организационная структура;

● роли и ресурсы.

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

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

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

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

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

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

● процессное моделирование;

● объектное моделирование;

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

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

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

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

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

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

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

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

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

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

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

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

● действия, изображенные в виде прямоугольников;

● хранилища объектов (в самом широком смысле), представленные кружками;

● связи между действиями и хранилищами объектов, изображенные в виде ориентированных дуг.

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

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

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

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

● Входящие связи (рис. 3.4). Действие во время его выполнения потребляет объекты из хранилищ объектов на входе.

● Выходящие связи (рис. 3.5). Действие во время его выполнения выпускает объекты и помещает их в хранилища объектов на выходе.

● Модифицирующие связи (рис. 3.6). Действие во время его выполнения изменяет объект в хранилище на другом конце линии связи.

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

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

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

1


Методология и технология коллективного проектирования бизнес-процессов с использованием Веб 2.0 Horus Social BPM Lab 1

2


Лекция 7 Что это такое и для чего все это нужно? Особенности методологии моделирования Horus Особенности программного инструмента Horus 2

3


Проблемы совершенствования бизнеса Бизнес и информационные системы – 2 разных мира… (1/2) Недостаточное соответствие информационных систем требованиям бизнеса –Информационные системы (ИС) не соответствуют изменяющимся потребностям бизнеса => снижается его эффективность –ИС не ускоряют инновационное развитие, а скорее препятствуют ему –ИС затрудняют непрерывное совершенствование бизнес-процессов –Взлет «теневых ИТ» (Shadow-IT): Excel-отчетность и аналитика, специфические приложения для подразделений предприятия, использование облачных сервисов … Недостаточное удобство использования информационных систем –Игнорирование деятельности по управлению изменениями –Бизнес-пользователи не используют систему должным образом –Работа в системе кажется слишком сложной для понимания –Информационная система не использует технические ресурсы оптимально

4


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

5


Проблемы совершенствования бизнеса Проблема адекватности ИС потребностям бизнеса Совместная работа с многочисленными несогласованными деловыми поездками, теле- и видеоконференциями Обширные программы обучения с многочисленными тренингами и консалтингом после внедрения «Ванильное внедрение» (Vanilla-Implementation) с большим количеством дорогостоящих изменений по результатам внедрения Развертывание шаблонов с огромным количеством вынужденных изменений на уровне департамента Экономичность? Производитель- ность?

6


Решение: Social BPM Lab. Концепция Члены бизнес-сообщества –взаимодействуют в социальной сети на базе Веб 2.0 для совместного определения целей, стратегий и бизнес-процессов предприятия. Участники воспринимают Social BPM Lab –как уникальный опыт командной работы, в котором они выполняют общее задание, распределяют ответственность и привносят новые идеи. Процессы групповой динамики дают неожиданные результаты, помогают преодолеть барьеры, найти компромиссы и усилить чувство солидарности в группе. Social BPM Lab усиливает креативность и готовность к компромиссам также помогают сформировать общее понимание бизнес-процессов и организационных структур.

7


Решение: Social BPM Lab. Распределение ролей в Social BPM Lab Модератор формирует архитектуру бизнес-процессов, в которой выделяются группы процессов. Участник в соответствии со своими профессиональными компетенциями и вне зависимости от территориального расположения закрепляется за определенным процессом / группой процессов. Таким образом, формируются территориально распределенные команды, отвечающие за моделирование процессов согласно их компетенции. Руководитель команды За каждой командой закрепляется руководитель, который берет на себя интегративную функцию и несет ответственность за командный результат. Менеджер по качеству В зависимости от размера проекта и начальных знаний участников вводится роль менеджера по качеству для предметной и формальной проверки созданных моделей. Эксперты по требованию Эксперты по требованию осуществляют поддержку по вопросам моделирования и использования программных инструментов.

8


Интранет Внутренние участники Social BPM Lab Руководитель команды Внешние участники Social BPM Lab (филиалы, партнеры) Интранет Интернет Эксперт по требованию Сотрудник в «домашнем офисе» Менеджер по качеству Модератор Мобильный сотрудник Инструменты: Репозиторий Social BPM Lab на основе облачных технологий Horus Business Modeler Horus Knowledge Explorer Wiki (DokuWiki) Взаимодействие в веб (вебинары, чаты) Решение: Social BPM Labs. Инфраструктура Social BPM

9


Social BPM Lab разделен на определенные фазы, длительность которых устанавливается в зависимости от общей запланированной продолжительности проекта: Подготовка Разработка бизнес-кейса, который является отправной точкой проекта и определяет границы предстоящей работы. Длительность: дня Инструктаж участников В режиме веб- конференции модератор объясняет условия и ход проведения эксперимента. Длительность: 10 – 20 мин. Коллективная работа Участники выполняют задания согласно определенным для них ролям. Длительность: 4 часа – несколько дней Завершение Модератор подводит итог эксперимента и делает обзор достигнутых результатов. Анализ результатов Сводка и документирование результатов, в том числе не выполненных работ. Анализ результатов и последующих действий. Длительность: 0,5 — 4 дня Изучение методик и инструментов В зависимости от уровня начальной подготовки участники осваивают методологию и программные инструменты Horus в форме вебинара. Длительность: 30 мин. — 2 часа. Решение: Social BPM Lab. Описание Social BPM Lab

10


Organigrams Behavior Models Object Models Roles/ Resources Business Processes Introduction to Business Process Modeling 10

11


Definition business processes are represented by so-called behavior models behavior models show what activities, when and under what conditions are executed Representation 3 major elements: Properties structured and clearly arranged construction of a complex business process landscape user-defined detailing and refinement of business process activities use of !!!ONE!!! abstraction level within one model Process Modeling for XML- Nets Connection Behavior Models

12


Simple Example Behavior Models

13


Definition depicts process task Representation by rectangles activities should be identified as dynamic actions in behavior models (use verbs for naming) Activity Behavior Models

14


Types Normal Activity OR – Inputs OR – Outputs OR – In/Outputs Activity Behavior Models

15


Activity Types Normal Activity Behavior Models

16


Activity Types OR – Inputs Behavior Models

17


Activity Types OR – Outputs Behavior Models

18


Activity Types OR – In/Outputs Behavior Models

19


Definition represents inputs (conditions) and outputs (results) of activities Representation by circle should have expressive name Properties contains process object(s) can have attributes: capacity (maximum number of objects in the object stores) storage cost storage duration Object Store Behavior Models

20


Definition connects activity with object store(s) Representation is represented as (directed) arc Properties specifies, how connected activity transforms the process objects from connected object stores consumes creates new reads updates Connection Behavior Models

21


Connection Types Input — Connection At run time activity consumes objects from the input object store. Behavior Models

22


Connection Types Output — Connection Activity creates a new object and puts it into the output object store. Behavior Models

23


Connection Types Update — Connection Activity consumes objects at run time and puts them again into the connected object store. Behavior Models

24


Connection Types Update — Connection Activity consumes objects at run time, updates them and puts them back to the connected object store. Behavior Models

25


Connection Types Read — Connection Activity only reads the business objects without making any changes. Behavior Models

26


Refinement Example Behavior Models

27


27 © 2013 Horus software GmbH Task 3 — Solution Part II — Behavior Models

28


Process Types process flows can branch and run in parallel the parallel processes can be merged Process Types Sequential Flow Parallel Flow and Synchronization Alternative Flow: Splits and Joins Independent Flow Behavior Models

29


Process Types Parallel Flow Example Activities fire in parallel and independently Behavior Models

30


Process Types Alternative Flow Example Behavior Models

31


Process Types Example Parallel Flow Synchronization Behavior Models

32


Process Types Example Splits in Alternative Flow Joins in Alternative Flow Just ONE activity will be performed. Behavior Models

33


Task 5 — Solution Behavior Models

34


Goals and Definition Goals logical structuring of information complete and correct representation of business object object models must represent real business objects realistically described Definition allows for definition of complex hierarchically structured business objects notation: objects with attributes and relations logical structuring detailed representation of static data structures covers all informative aspects relevant for a given business object Object Models

35


Used Notation Object Models

36


Object (Object Type) Representation objects are represented as rectangles with rounded corners Key Attributes Constraint Object Models

37


Attributes Definition attribute is the smallest information unit of object modeling attributes describe business objects in detail attributes define data types and domains Attribute: Data Type Attribute Types Keys Attributes Object Models

38


Task 9 — Solution Object Models

39


Relationships Representation by edges between Objects Types Relationship Inheritance Cardinalities Object Models

40


Inheritance represents an inheritance between objects Representation bears the description «is a(n) is represented by a simple arrow Interpretation The direction of the arrow signifies an inheritance edge, representing that the output object is a specialization of the target object. The target object inherits the attributes from the output object. Against the direction of the arrow means that the output object is a generalization of the target object, represents an inheritance between objects. Object Models

41


Aggregation Object Models

42


XOR — Relationship In the following example it is shown that a product, that will be later sold to the customer, can be either manufactured or procured. Object Models

43


OR — Relationship In the following example it is shown that products and services can be ordered both separately and together. Object Models

44


SIM — Relationship The following example shows that if a customer specific product is ordered, i.e. induvidual production is required, both sales order and production order will be created. Object Models

45


Task 11 — Solution Object Models

46


Business Object Interrelationship between behavior and object model Object Models

47


Organization Structure vs. Process Models Organization Models

48


Organizational Units Representation by rectangulars collors to be used for differenciation between different types of organizational units Refinement in a refinement, an organizational unit can be broken into smaller units and presented in greater detail no refinement for external organizational units Note: !!ONE!! level of detail within one model Organization Models

49


49 © 2013 Horus software GmbH Assignments Part V – Organization Models Definition correspond to hierarchical relationships between organizational units Representation by connections Relationship Types organizational assignment (solid line) functional assignment (dotted line)

50


Resources Definition resources are persons or objects of an organization which are responsible for the execution of activities Classification Responsibility internal resource external resource Resource Type: Staff, Materials, Resources. Data bank, Application Properties resources are assigned to specific organization units are depicted in resource models Organization Models

51


Roles in Behavior Model roles are assigned to activities in behavior models Organization Models

52


Interdependencies Organization Models

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

Оглавление

Архитектура и инжиниринг бизнес-систем

1. Методы моделирования
   бизнес-процессов. Современные подходы
   к моделированию бизнес-процессов.

2. Концепция проекта.
   Процесс или проект. Жизненный цикл
   проекта и процесса.

3. Корневая модель
   бизнес-процессов и ее использование.

4. Бизнес-процессы в
   стандартах ISO.

5. Инжиниринг
   бизнес-процессов и систем управления.

6. Информационные
   технологии в бизнес — инжиниринге.

7. Детальный инжиниринг
   и алгоритмизация бизнес-процессов.

8. Оргструктура
   бизнес- процесса.

9. Программные средства
   для моделирования бизнес-процессов.

10. Выделение субъекта
    и объекта управления. Прямые и обратные
    связи в процессе управления. Управленческий
    цикл.

11. Система управления
    бизнес- процессами. Типологии
    управленческого цикла.

12. Функциональные
    сферы управления. Менеджмент и сфера
    менеджмента. Управление, ориентированное
    на бизнес- процессы.

13. Детализация
    корпоративной архитектуры (КА).
    Компоненты корпоративной архитектуры.

14. Направления
    деятельности компании. Программа
    развития системы управления. Использование
    подходов системы менеджмента качества.

15. Структурное
    моделирование. Влияние результатов
    диагностики и стратегии на структуру
    «как надо».

16. Разработка
    регламентов бизнес-процессов.
    Контроллинг. Улучшение. Сравнительный
    анализ функционально и
    процессно-ориентированной организации
    управления.

17. Сущность, принципы
    и задачи мониторинга корпоративной
    архитектуры.

18. HR – инжиниринг.

19. Методы и примеры
    систем менеджмента качества.

Вопрос 1 Методы моделирования бизнес-процессов.

Бизнес-процесс
– это логичный, последовательный,
взаимосвязанный набор мероприятий,
который потребляет ресурсы, создаёт
ценность и выдаёт результат. В
международном стандарте ISO 9000:2000 принят
термин «процесс», однако в настоящее
время эти термины можно считать
синонимами. Моделирование
бизнес-процессов
– это эффективное средство поиска
путей оптимизации деятельности компании,
позволяющее определить, как компания
работает в целом и как организована
деятельность на каждом рабочем месте.
Под методологией (нотацией)
создания модели
(описания)
бизнес-процесса понимается совокупность
способов, при помощи которых объекты
реального мира и связи
между ними представляются в виде модели.
Для каждого объекта и связей характерны
ряд параметров, или атрибутов,
отражающих опредёленные характеристики
реального объекта (номер объекта,
название, описание, длительность
выполнения (для функций), стоимость и
др.).

Описание
бизнес-процессов проводится с целью
их дальнейшего анализа и реорганизации.
Целью реорганизации может быть внедрение
информационной системы, сокращение
затрат, повышение качества обслуживания
клиентов, создание должностных и рабочих
инструкций и т.п., а детальное
описание процессов само по себе не
представляет ценности.
Реинжиниринг
бизнес-процессов (англ. Business process
reengineering) — это фундаментальное
переосмысление и радикальное
перепроектирование бизнес-процессов
для достижения максимальной эффективности
производственно-хозяйственной и
финансово-экономической деятельности,
оформленное соответствующими
организационно-распорядительными и
нормативными документами. Бизнес-инжиниринг
состоит из моделирования бизнес-процессов
(разработка модели «как есть», её анализ,
разработка модели «как надо») и разработки
и реализации плана перехода к состоянию
«как надо».

Основу
многих современных методологий
моделирования бизнес-процессов составили
методология SADT (Structured Analysis and Design
Technique – метод структурного анализа и
проектирования), семейство стандартов
IDEF (Icam DEFinition, где Icam — это Integrated
Computer-Aided Manufacturing) и алгоритмические
языки. Основные типы методологий
моделирования и анализа бизнес-процессов:

• Моделирование
  бизнес-процессов (Business
  Process Modeling).
  Наиболее широко используемая методология
  описания бизнес-процессов – стандарт
  IDEF0.
  Модели в нотации IDEF0 предназначены для
  высокоуровневого описания бизнеса
  компании в функциональном
  аспекте.

• Описание потоков
  работ (Work Flow
  Modeling). Стандарт
  IDEF3
  предназначен для описания рабочих
  процессов
  и близок к алгоритмическим методам
  построения блок-схем.

• Описание потоков
  данных (Data
  Flow Modeling).
  Нотация DFD
  (Data Flow
  Diagramming),
  позволяет отразить последовательность
  работ, выполняемых по ходу процесса,
  и потоки
  информации,
  циркулирующие между этими работами.

• Прочие методологии.

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

• Основные
  бизнес-процессы (например маркетинг,
  производство, поставки и сервисное
  обслуживание продукции).

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

• Бизнес-процессы
  управления.

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

Цели
моделирования бизнес-процессов обычно
формулируются следующим образом:

• обеспечить понимание
  структуры организации и динамики
  происходящих в ней процессов;

• обеспечить понимание
  текущих проблем организации и
  возможностей их решения;

• убедиться, что
  заказчики, пользователи и разработчики
  одинаково понимают цели и задачи
  организации;

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

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

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

Этапы
описания бизнес-процессов:

• Определение целей
  описания.

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

• Описание функциональной
  структуры (действия процесса), построение
  IDEF3-диаграмм.

• Описание потоков
  (материальных, информационных,
  финансовых) процесса, построение
  DFD-диаграмм.

• Построение
  организационной структуры процесса
  (отделы, участники, ответственные).

IDEF0.
Модель состоит
из диаграмм, фрагментов текстов и
глоссария, имеющих ссылки друг на друга.
Диаграммы — главные компоненты модели,
все функции
и интерфейсы
на них представлены как блоки
и дуги.
Место соединения дуги с блоком определяет
тип интерфейса:

• Управляющая
  информация входит в блок сверху.

• Входная информация
  входит в блок слева.

• Результаты выходят
  из блока справа.

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

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

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

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

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

Типы
связей IDEF3:

• Временное
  предшествование (Temporal precedence), простая
  стрелка. Исходное действие должно
  завершиться, прежде чем конечное
  действие сможет начаться.

• Объектный поток
  (Object flow), стрелка с двойным наконечником.
  Выход исходного действия является
  входом конечного действия. Исходное
  действие должно завершиться, прежде
  чем конечное действие сможет начаться.
  Наименования потоковых связей должны
  чётко идентифицировать объект, который
  передается с их помощью.

• Нечеткое отношение
  (Relationship), пунктирная стрелка.

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

• «И», блок со знаком
  &.

• «Исключающее ИЛИ»
  («одно из»), блок со знаком Х.

• «ИЛИ», блок со
  знаком О.

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

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

DFD.
Цель такого
представления – продемонстрировать,
как каждый процесс преобразует
свои входные данные
в выходные. Может отражать не только
информационные, но и материальные
потоки.

Также,
как и в других моделях, поддерживается
декомпозиция.

Основными
компонентами диаграмм потоков данных
являются:

• внешние сущности
  (материальный объект или физическое
  лицо, являющиеся источником или
  приёмником информации, например,
  заказчики, персонал, поставщики,
  клиенты, склад);

• системы и подсистемы
  (например, подсистема по работе с
  физическими лицами);

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

• накопители данных
  (абстрактные устройства для хранения
  информации);

• потоки данных (на
  диаграмме — стрелки).

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

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

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

При
моделировании бизнес-процессов диаграммы
потоков данных (DFD) используются для
построения моделей «AS-IS» и «AS-TO-BE»,
отражая, таким образом, существующую
и предлагаемую структуру бизнес-процессов
организации.

ARIS.
В настоящее
время наблюдается тенденция интеграции
разнообразных методов моделирования,
проявляющаяся в форме создания
интегрированных средств моделирования.
Одним из таких средств является
программный продукт, носящий название
ARIS (Architecture of Integrated Information Systems), разработанный
германской фирмой IDS Scheer.

ARIS
поддерживает четыре типа моделей (и
множество видов моделей в каждом типе),
отражающих различные аспекты исследуемой
системы:

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

• функциональные
  модели, содержащие иерархию целей,
  стоящих перед аппаратом управления,
  с совокупностью деревьев функций,
  необходимых для достижения поставленных
  целей;

• информационные
  модели, отражающие структуру информации,
  необходимой для реализации всей
  совокупности функций системы;

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

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

Основная
бизнес-модель ARIS — eEPC (extended Event-driven Process
Chain, расширенная модель цепочки процессов,
управляемых событиями). Нотация ARIS eEPC
является расширением нотации IDEF3.
Бизнес-процесс в нотации eEPC представляет
собой поток последовательно выполняемых
работ (процедур, функций), расположенных
в порядке их выполнения. Реальная
длительность выполнения процедур в
eEPC визуально не отражается. Для получения
информации о реальной длительности
процессов необходимо использовать
другие инструменты описания, например,
MS Project.

Модели
в ARIS представляют собой диаграммы,
элементами которых являются разнообразные
объекты
– «функции», «события», «структурные
подразделения», «документы» и т.д.
Между объектами определённых видов
могут быть установлены связи
определённых видов («выполняет»,
«принимает решение», «должен быть
проинформирован о результатах» и т.д.).
Каждому объекту соответствует
определенный набор атрибутов, которые
позволяют ввести дополнительную
информацию о конкретном объекте.

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

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

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

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

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

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

Процессный
подход может использовать любые из
перечисленных выше средств моделирования.
Однако, в настоящее время наблюдается
тенденция интеграции разнообразных
методов моделирования и анализа систем,
проявляющаяся в форме создания
интегрированных средств моделирования.
Одним из таких средств является продукт,
носящий название ARIS — Architecture of Integrated
Information System, разработанный германской
фирмой IDS Scheer [7].

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

ARIS
поддерживает четыре типа моделей,
отражающих различные аспекты исследуемой
системы:

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

функциональные
модели, содержащие иерархию целей,
стоящих перед аппаратом управления, с
совокупностью деревьев функций,
необходимых для достижения поставленных
целей;

информационные
модели, отражающие структуру информации,
необходимой для реализации всей
совокупности функций системы;

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

Для
построения перечисленных типов моделей
используются как собственные методы
моделирования ARIS, так и различные
известные методы и языки моделирования
— ERM, UML, OMT и др.

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

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

Бизнес-процесс
в нотации eEPC представляет собой поток
последовательно выполняемых работ
(процедур, функций), расположенных в
порядке их выполнения. Реальная
длительность выполнения процедур в
eEPC визуально не отражается. Это приводит
к тому, что при создании моделей возможны
ситуации, когда на одного исполнителя
будет возложено выполнение двух задач
одновременно. Используемые при построении
модели символы логики позволяют отразить
ветвление и слияние бизнес-процесса.
Для получения информации о реальной
длительности процессов необходимо
использовать другие инструменты
описания, например графики Ганта в
системе MS Project.Ряд современных методов
моделирования бизнес-процессов основан
на использовании языка UML. Хотя UML
изначально предназначался для
моделирования систем ПО, его использование
в другой области стало возможным
благодаря наличию в UML механизмов
расширения (стереотипов).

Среди
таких методов наиболее известными
являются метод Ericsson-Penker и метод,
реализованный в технологии Rational Unified
Process (RUP).

Метод
Ericsson-Penker [23] представляет интерес прежде
всего в связи с попыткой применения
UML в рамках процессного подхода к
моделированию бизнес-процессов. Авторы
метода создали свой профиль UML для
моделирования бизнес-процессов, введя
набор стереотипов, описывающих процессы,
ресурсы, правила и цели деятельности
организации. Метод использует четыре
основные категории бизнес-модели:

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

Процессы
— виды деятельности, изменяющие состояние
ресурсов в соответствии с бизнес-правилами.

Цели
— назначение бизнес-процессов Цели
могут быть разбиты на подцели и соотнесены
с отдельными процессами.

Бизнес-правила
— условия или ограничения выполнения
процессов (функциональные, поведенческие
или структурные). Правила могут быть
определены с использованием языка OCL.

Метод
использует четыре различных представления
бизнес-модели:

концептуальное
представление — структура целей и
проблем;

представление
процессов — взаимодействие между
процессами и ресурсами (в виде набора
диаграмм деятельности);

структурное
представление — структура организации
и ресурсов (в виде диаграмм классов);

представление
поведения — поведение отдельных ресурсов
и детализация процессов (в виде диаграмм
деятельности, состояний и взаимодействия).

Методика
моделирования RUP [13] предусматривает
построение двух моделей:

модели
бизнес-процессов
(Business Use Case Model);

модели
бизнес-анализа
(Business Analysis Model).

Методика
моделирования Rational Unified Process
обладает следующими достоинствами:

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

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

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

Современные
подходы к моделированию бизнес-процессов

Рис.
2.2.1. Назначение модели бизнес-процессов

Начало
и окончание БП могут быть по-разному
определены для одной и той же ситуации.

Пример
1. Бизнес-процесс «Разработка продукта».
Начало и окончание – от требований
клиента к продукту до создания
конструкторской документации.

Пример
2. Бизнес-процесс «Закупка материальной
ценности». Начало и окончание – от
выбора поставщиков к отпуску
товарно-материальных ценностей к
производству.

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

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

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

Поэтому
модель – это описание БП на
специализированном языке или его
представление в виде таблиц, схем,
текстов. Оно помогает понять процесс,
управлять им, регламентировать и
автоматизировать его.

Вопросы,
которые интересуют пользователей при
моделировании процессов. Специалисты,
которые используют модели БП, – это
прежде всего менеджеры, руководители
и исполнители, включенные в организацию
и исполнение БП. Что их интересует,
какие главные вопросы, ответы на которые
они хотят получить при использовании
моделей БП? Модели БП помогают отвечать
на такие вопросы (рис. 2.2.2):

Рис.
2.2.2. Вопросы, которые интересуют
пользователей при моделировании
бизнес-процессов

•
Какие работы
необходимо выполнять для исполнения
процесса в целом и достижения необходимого
результата?

•
Кто и какие работы
выполняет? Каково распределение работ
между исполнителями?

•
Каков порядок,
какова последовательность выполнения
работ? Что выполняется сначала, что –
потом, что – на финише.

•
Что является
результатом каждой из работ? Если
выполняется несколько работ, которые
связаны или интегрированы в цепочку
работ, то что является выходом первой
работы и входом второй?

•
Какие ресурсы
необходимы для выполнения работ?

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

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

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

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

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

Еще
одна важная область деятельности
компании – это управление основной
деятельностью и управление обеспечивающей,
поддерживающей деятельностью. 

Рис.
2.2.3. Классификация областей деятельности
компании (пример)

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

Итак,
основные бизнес-процессы:

•
образуют добавленную
стоимость продукта (услуги);

•
создают продукт
(услуги), представляющий ценность для
клиента;

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

•
сфокусированы на
получении прибыли.

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

Поэтому
поддерживающие бизнес-процессы:

•
направлены на
предоставление необходимых внутренних
продуктов, внутренних услуг для
направлений бизнеса;

•
обеспечивают
функционирование инфраструктуры
компании.

Бизнес-процессы
развития:

•
нацелены на получение
прибыли в долгосрочной перспективе
(не создают «прибыль сегодня»);

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

Процессы
управления:

•
нацелены на управление
всеми тремя группами БП, т. е. управление
основными БП, управление поддерживающими
БП и управления БП развития.

Управление
БП развития называют еще стратегическим
управлением, т. е. стратегическое
управление – это управление БП развития.

Рис.
2.2.4. Классификация бизнес-процессов

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

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

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

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

Рис.
2.2.5. Варианты развития бизнес-процессов

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

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

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

1.1.3. О чем собственно речь

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

1.2. Языки и методы моделирования

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

1.2.1. Язык бизнес-сообщества

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

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

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

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

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

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

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

1.2.2. Методы моделирования

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

Конкретный метод работы с сетями Петри в бизнес-сообществах представлен в главе 4 этой книги.

1.3. Инструменты для бизнес-сообществ

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

1.3.1. Развитие рынка

История проектирования бизнес-процессов на основе моделей тем временем возвращает нас назад более чем на 20 лет. После первых нерешительных начинаний в области средств автоматизированной разработки программного обеспечения (Computer-aided software engineering – CASE) моделирование бизнес-процессов пережило первый расцвет в контексте внедрения стандартных бизнес-приложений (SAP, приложения Oracle, PeopleSoft, Baan и т. д.). Помимо таких высокопрофессиональных инструментов, как ADONIS, ARIS, Bonaparte, Casewise и INCOME, на рынке появлялось все больше и больше низкотехнологичных средств, получивших развитие от простых графических программ, например Visio и iGrafx. Между тем сейчас мы наблюдаем второй расцвет, движущими силами которого, несомненно, служат темы управления бизнес-процессами (Business Process Management – BPM), разработка, управляемая моделями (Model Driven Development – MDD) и сервис-ориентированная архитектура (Service Oriented Architecture – SOA). Актуальные обзоры рынка показывают, что сегодня практически каждый поставщик прикладного и межплатформенного программного обеспечения может предложить по крайней мере один инструмент моделирования процессов.

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

1.3.2. Horus: Бизнес-процессы для бизнес-сообществ

В результате многолетних исследований в Институте прикладной информатики и методов формализованного описания (AIFB) Технологического института Карлсруэ (KIT) и в Исследовательском центре информатики Карлсруэ (FZI) в сотрудничестве с отраслевым партнером PROMATIS Software GmbH появилось совершенно новое поколение средств для поддержки всего жизненного цикла моделирования бизнес-процессов под названием Horus^[2]. Основной целью исследования было сделать возможным участие и взаимодействие всех членов бизнес-сообщества. Здесь пришли на помощь технические возможности, ставшие доступными в контексте социализации интернета. Horus ориентирован на функционирование бизнес-сообщества, не нарушая хода его работы и обходясь при этом без специальной подготовки. Далее кратко представлены важнейшие компоненты Horus.

1.3.2.1. Платформа на основе сетей Петри

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

1.3.2.2. Контент и сообщество

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

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

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

1.4. Цели и структура данной книги

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

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

Глава 2 книги максимально погружает читателя к реальным условиям бизнес-среды. Здесь в доступной форме и с многочисленными практическими примерами описаны важнейшие основы инжиниринга бизнес-процессов на базе моделей. Основываясь на этом, глава 3 описывает соответствующие концепции и языки моделирования и формирует таким образом связный каркас для моделирования бизнес-процессов. Глава 4 представляет универсальный подход к проектированию бизнес-процессов на основе моделей – метод Horus. Его отправной точкой служит стратегический анализ, «встраивающий» бизнес-процессы в целостный корпоративный контекст. В главе 5 представлены конкретные примеры применения на практике. Книга завершается обзором перспектив инжиниринга бизнес-процессов в главе 6.

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

Деятельность в области бизнес-процессов, их анализа и совершенствования восходит среди прочих к работам Hammer и Champy (1993). В 1990-е эта тема, в частности, рассматривалась в связи с управлением потоком работ (Workflow Management), см. Oberweis (1996) в сравнении с Van der Aalst и Van Hee (2004). В настоящее время литература, посвященная моделированию бизнес-процессов, полна заблуждений, поэтому мы отсылаем наших читателей на данный момент только к Becker с соавторами (2011), Scheer (2000a, b), Davis (2001) и Weske (2007). Тем же, кто предпочитает сухому изложению введение в тему в форме романа, рекомендуем Grosskopf с соавторами (2009).

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

● Business Process Management Initiative BPMI (объединилась с OMG – Object Management Group в 2005 году): http://www.omg.org/.

● Business Process Modeling and Simulation Forum: http://www.12manage.com/methods_business_ simulation_modeling.html#userforum/.

● Business Process Trends: www.bptrends.com/.

● Petri Nets World: www.informatik.uni-hamburg.de/TGI/PetriNets/.

Ссылки, приведенные далее, дают примеры систем моделирования бизнес-процессов, более подробная информация по которым доступна в интернете; данный список не претендует на полноту.

● ARIS Express от фирмы Software AG: www.ariscommunity.com/aris-express/.

● bflow Toolbox (Open Source): www.bflow.org/.

● Horus от фирмы Horus software GmbH: www.horus.biz/.

● Signavio Process Editor от фирмы Signavio GmbH: https://www.signavio.com/products/process-editor/https://tap.tibco.com/storefront/trialware/tibco-business-studio-community-edition/prod15312.html.

● TIBCO Business Studio от фирмы TIBCO Software Inc.: https://www.signavio.com/products/process-editor/https://tap.tibco.com/storefront/trialware/tibco-business-studio-community-edition/prod15312.html.

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

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

2.1. Постановка задачи

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

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

2.2. Анализ и моделирование процедур

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

2.2.1. Моделирование бизнес-процедур с помощью сетей Петри

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

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

Моделирование даже относительно простого процесса продаж – задача нетривиальная: из неструктурированной базовой информации о бизнесе должны быть извлечены действия и потоки объектов, а затем отображены в виде структурированной модели. Предлагаемый Horus метод, описанный в главе 4, – это метод, проверенный на практике. Рис. 2.1 дает обзор процесса продаж, представленного в виде сети Петри. Как часто встречается на практике, процессу дается имя (чаще на английском языке), которое позволяет делать выводы о входах и выходах процесса – здесь контакт преобразуется в заказ клиента (Sales Contact-to-Order). То есть процесс начинается с контакта и включает в себя ряд мероприятий и потоков объектов, чтобы в конечном итоге сформировать заказ от клиента.

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

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