Моделирование бизнеса и CASE-технологии

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

Говорить  о преимуществе той или иной системы/нотации  бессмысленно, пока не определены тип  и рамки проекта, основные задачи, которые данные проект должен решить.

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

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

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

На  сегодняшний день наиболее распространенными в России CASE-инструментами для моделирования бизнеса являются ARIS Collaborative Suite компании IDS Scheer AG (Германия) и AllFusion Modeling Suite, в частности AllFusion Process Modeler (ранее BPwin) компании Computer Associates.

ARIS

Методология ARIS основана на разработанной профессором А.-В. Шеером теории «Архитектура интегрированных информационных систем» (ARchitecture of Integrated Information System — ARIS). Она определяет принципы моделирования практически всех аспектов деятельности организаций, что является ее коренным отличием от других методологий. Согласно терминологии, принятой в области структурного анализа, термин «архитектура» описывает типы используемых методов, их функциональные свойства и взаимоотношения между составными частями моделируемой системы [5.29].

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

В общем случае архитектура ARIS выделяет в организации такие подсистемы как:

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

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

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

Для устранения избыточности методология ARIS ограничивает число моделей до пяти типов представлений:

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

Графически  такой подход представлен на рис. 3.3.

 

Рис. 5.3.  Взаимосвязь  видов моделей ARIS (здание ARIS)

 

В рамках каждого типа представления создаются модели, отражающие ту или иную сторону исследуемой системы. Методология ARIS включает большое количество методов моделирования, в том числе известных как диаграммы Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п.

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

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

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

Нотация ARIS eEPC (extended Event Driven Process Chain) – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация eEPC построена на определенных семантических правилах описания:

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS.

Бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).

BPWin

BPWin использует следующие нотации:

• нотация IDEF0, которая была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий.
• Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур.

IDEF0 представляет собой методологию функционального моделирования, позволяющую с помощью наглядного языка представить систему (процесс) в виде набора взаимосвязанных действий, работ (Activities), которые взаимодействуют между собой на основе определенных правил (Control), с учетом потребляемых информационных, человеческих и производственных ресурсов (Mechanism), имеющих четко определенные вход (Input) и выход (Output). Наиболее часто IDEF0 используется как технология исследования и проектирования систем на логическом уровне, что обусловливает целесообразность его применения на ранних этапах разработки проекта, в качестве первого этапа изучения любой системы.  В качестве преимущества методологии IDEF0 можно отметить функциональную направленность – функции системы исследуются независимо от объектов, которые обеспечивают их выполнение.

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

Данные  методологии используются во множестве  программных  пакетов (COSMO, Design/IDEF, BPWin, Design/IDEF). Необходимо отметить, что данные методологии являются «открытыми», в отличие от «корпоративных» (ARIS, ORACLE), что возводит их в ранг методологий общего пользования и дает возможность специалистам разных уровней общаться на одном языке.

Мощным  инструментом для создания моделей. Позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов является пакет AllFusion Process Modeler (BPWin 4.1). Данный пакет обладает рядом преимуществ:

• предлагает средства для сбора всей необходимой информации о работе предприятия и ее графического изображения в виде целостной и непротиворечивой модели;
• использует открытые методологии моделирования (IDEF, DFD – Data Flow Diagrams, диаграммы потоков данных), что делает созданные с его помощью модели доступными и для понимания и анализа системным аналитикам и управленцам;
• проверяет создаваемые модели с точки зрения синтаксиса выбранной методологии, ссылочную целостность между диаграммами;
• обладает удобным инструментом для навигации по уровням декомпозиции модели (Model Explorer);
• поддерживает ряд вспомогательных диаграмм (Node Tree Diagram – диаграммы дерева узлов, FEO – презентационные диаграммы,  Diagrams Organization Charts – схемы организации   и др.);
• позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности (АВС - анализ);
• имеет возможность взаимодействия с другими программными продуктами: средствами моделирования данных (ERWin), имитационного моделирования (Arena), стоимостного анализа (EasyABC), MS Word, MS Excel, HTML.

К недостаткам данного пакета можно  отнести, то что:

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

 

 

 

Тема 4. Реализация РБП. (2 часа)

 

1. Реализация проекта по  реинжинирингу бизнес-процессов.

2. Основные  этапы проекта по РБП

 

 

1. Реализация проекта по реинжинирингу бизнес-процессов