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

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

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

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

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

Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными.

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

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

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

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

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

Кроме основных видов диаграмм модель нотации IDEF0 в BPwin может включать следующие элементы:

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

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

Второй информационный разрез – потоки информации (документооборота) в системе.

Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией как внутри системы между бизнес-функциями, так и системы в целом с внешней информационной средой.

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

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

Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы – движение объектов, хранение объектов, поставка и распространение объектов.

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

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

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

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

В последней версии BPwin имеется возможность использования модели Swim Lane, основанной на нотации IDEF3, что делает диаграммы данной нотации более читабельными и понятными пользователю.

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

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

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

В качестве корпоративного стандарта построения моделей деятельности нами принят метод, при котором верхние 3-4 уровня модели строятся в нотации IDEF0, а завершающий нижний уровень – в нотации DFD. Этим достигается целостность модели без перегрузки её излишней информацией на верхних уровнях детализации.

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

После построения и верификации модели «AS-IS» аналитику необходимо провести ее качественное исследование, оптимизацию, необходимую для построения модели «TO-BE». Для того чтобы определить качество созданной модели с точки зрения эффективности бизнес – процессов, необходима система метрики, то есть качество аналитику следует оценивать количественно.

В качестве таких количественных критериев оценки в BPwin выступают стоимостные показатели работ, так называемый АВС-анализ, и пользовательские свойства процессов – UDP (User Defined Properties).