Читать книгу: «Бизнес-процессы», страница 4

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

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

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