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

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

Если верить современной науке о происхождении человека, его, то есть человека, всегда отличала от других видов жажда деятельности. Причем не просто жажда деятельности как таковой, а стремление к совершенствованию этой деятельности, стремление к развитию, привлечению в свою деятельность новых технологий. Чем занимались деловые люди в эпоху динозавров? Самый выгодный и жизненно необходимый бизнес тех времен - охота, скажем, на мамонта. Как добывать такого крупного зверя? Это бизнес-процесс, который требовал от удачливых охотников тщательной подготовки и обучения. Но как можно было обучать подрастающее поколение в те времена, когда лексические средства были еще недостаточно выразительны, а письменности не было как таковой? В этот трудный момент на помощь человеку пришло средство, потрясающее своей простотой и выразительностью - рисунок. Процесс охоты можно было нарисовать. Конечно, поначалу не обходилось и без недоразумений, таких, например, как описаны у Р. Киплинга, но казусы происходили, только пока язык рисунка еще не сформировался полностью, пока не было понятно, что есть что, как изобразить перспективу, и как воссоздать точную схему. Так рисунок стал основным средством моделирования бизнес-процессов. Шло время, бизнес-процессы становились все разнообразнее, подтверждение чему можно обнаружить на стенах храмов древней Индии, на барельефах древней Греции, уже на папирусе в Египте и т.д. Сначала рисунок изображал лишь завершившийся процесс, то есть показывал, как принято делать что-либо в соответствии с устоявшимся распорядком. Затем рисунки стали применяться и для того, чтобы показать, как можно поменять сложившуюся структуру бизнес-процессов, с тем чтобы улучшить их, то есть рисунок стал вспомогательным средством для реинжениринга бизнес-процессов. В течение довольно продолжительного времени у рисунка был только один существенный недостаток - будучи возведенным в ранг искусства, он был подвластен лишь мастерам, которые, к тому же, тратили на каждый рисунок много времени. Затем появились книги, и нужда в рисунке, как средстве моделирования отпала, рисунок стал в лучшем случае иллюстрацией к написанному. Шло время, темп человеческой деятельности экспоненциально рос, усложнялись бизнес-процессы. В двадцатом веке бизнес-процессы стали настолько сложны, что ни один человек, работающий на более или менее крупном проекте, не в состоянии представить себе работу всего предприятия в той мере, которая необходима, для создания информационной системы или для реинжениринга бизнес-процессов.

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

Существует инструмент, который поможет ответить на все эти вопросы. Это Computer Associates BPwin, версия 4.0 которого вышла в этом году. BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. Причем, поскольку модель является некоторым графическим представлением действительности, можно утверждать, что человек вернулся к своему излюбленному средству документирования бизнес-процессов - к рисунку. Но возвращение это произошло на новом уровне - целостность и непротиворечивость модели-рисунка (качества, о которых раньше не было и речи) гарантируются рядом методологий и нотаций, которым следуют создатели модели. BPwin поддерживает три таких методологии: IDEF0, DFD и IDEF3, позволяющие анализировать ваш бизнес с трех ключевых точек зрения:

• С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.
• С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
• С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.

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

IDEF0. Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

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

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

Рис 1. Пример контекстной диаграммы.

Как видно на Рис.1, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени "Отчетность"), что повышает наглядность и читаемость диаграммы.

После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис.2. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).

Рис. 2 Пример диаграммы декомпозиции

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

Всего DFD использует четыре важных элемента:

• Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами. (cм. Рис.3 - "Проверить наличие товара на складе")
• Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота . (cм. Рис.3 - "Запрос на склад")
• Внешние ссылки. Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы. . (cм. Рис.3 - "Клиент")
• Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных. (cм. Рис.3 - "Сведения о заказах")

Рис.3 Пример диаграммы DFD

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

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

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

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

Модель, выполненная в IDEF3, может содержать следующие элементы:

• Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.
• Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:
  • Связь предшествования (Precedence) - показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.
  • Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.
  • Поток объектов (Object Flow) - показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.
• Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков:
  • Перекресток слияния (Fan-in Junction) - узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.
  • Перекресток ветвления (Fan-out Junction) - узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.
• Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы.

Рис. 4 Пример диаграммы IDEF3

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

Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.

BPwin обладает удобным инструментом для навигации по уровням декомпозиции модели. Это Model Explorer (см. Рис. 5), который по организации очень похож на привычный всем проводник Windows. Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD - желтым и IDEF3 - синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу. В версии BPwin 4.0 проводник модели предлагает пользователю улучшенный интерфейс, который включает в себя новую вкладку объектов (Objects), и доработанную вкладку диаграмм (Diagrams). С помощью вкладки объектов можно методом Drag&Drop размещать объекты из словаря на любой диаграмму. С помощью вкладки диаграмм можно просматривать всю иерархию диаграмм, включая Organization Chart, Node Tree, Swim Lane, FEO, и IDEF3 Scenario, о которых речь пойдет позже.

Рис. 5 Model Explorer

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

1. Работы;
2. Стрелки;
3. Хранилища данных;
4. Внешние ссылки;
5. Перекрестки;
6. Объекты ссылок;
7. Атрибуты;
8. Центры затрат;
9. Сущности;
10. Ресурсы;
11. Роли;
12. Группы ролей;
13. Свойства, определяемые пользователем (UDP);
14. Ключевые слова UDP.

Генератор отчетов тоже претерпел существенные модификации. Теперь BPwin имеет действительно мощный инструмент отчетов Report Template Builder, с помощью которого можно легко и быстро создавать различные отчеты о вашей модели. С его помощью можно также создавать шаблоны для отчетов, которые можно будет многократно использовать впоследствии, а также преобразовывать отчеты в формат txt (.CSV), HTML или RTF.

Были улучшены и дополнены и редакторы свойств диаграмм и объектов. Теперь, помимо тех свойств, которые были доступны в предыдущих версиях, в них включены вкладки для изменения шрифтов, цветов, ролей, стиля прямоугольников работ, колонтитулов и других параметров страницы. На вкладке Header/Footer пользователь может теперь настраивать верхний и нижний колонтитулы для каждой диаграммы в отдельности. Кнопки панели инструментов автоматически перестраиваются при переходе от одной методологии к другой. Появилась возможность выделения группы объектов и последующей работы с этой группой. Еще один подарок пользователям BPwin 4.0 - поддержка визуального сравнения диаграмм. Теперь вы можете, предварительно выбрав две диаграммы, создать файл JPEG, который покажет все различия между выбранными диаграммами. И, конечно, обновлен BPwin Online Tutorial, в котором приведены полные уроки с примерами моделей, которые помогут вам быстро освоить BPwin.

Итак, что же может предложить BPwin, кроме поддержки уже рассмотренных нами трех методологий моделирования? Конечно же, этот инструмент, ставший незаменимым в консалтинговых компаниях в России и по всему миру, не останавливается на этом. В дополнение к диаграммам IDEF0, DFD и IDEF3, BPwin поддерживает еще целый ряд вспомогательных диаграмм таких как:

Диаграммы дерева узлов (Node Tree Diagram). К модели BPwin можно добавлять дерево узлов, которое показывает иерархию всех работ модели на одной диаграмме. Диаграмма дерева узлов имеет вид традиционного иерархического дерева, где верхний узел (прямоугольник) соответствует работе с контекстной диаграммы, а последующие нижние узлы представляют собой дочерние уровни декомпозиции. Можно также создать диаграмму дерева узлов лишь для некоторой части модели, тогда верхним узлом диаграммы будет та работа декомпозиции, с которой вы захотите начать.

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

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

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

Рис. 6 Пример диаграммы дерева узлов

Диаграммы только для показа (For Exposition Only {FEO} Diagram). К модели всегда можно добавить диаграмму FEO. Чаще всего это делается, для того чтобы проиллюстрировать разные сценарии развития процесса, показать модель с других точек зрения, вырезать важный кусок из сложной диаграммы (см. рис. 7), не портя при этом саму диаграмму. К любой диаграмме модели в BPwin, будь то контекстная диаграмма или одна из диаграмм декомпозиции можно добавлять произвольное число FEO диаграмм. FEO диаграммы характерны тем, что они не подлежат синтаксической проверке со стороны BPwin, поскольку, как в нашем примере, они могут являться лишь частью синтаксически правильной диаграммы.

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

Рис. 7 Пример FEO диаграммы

Диаграммы сценариев IDEF3 (IDEF3 Scenario). В BPwin 4.0 есть возможность добавлять к модели диаграммы сценариев IDEF3.

Рис. 8 Пример сценария IDEF3

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

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

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

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

Рис. 9 Пример схемы организации

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

Рис. 10 Пример Swim Lane диаграммы.

Но и описав вспомогательные диаграммы, мы далеко не исчерпали все возможности BPwin, поскольку этот продукт является не только мощным средством графического представления информации, но и инструментом ее анализа. Как уже говорилось выше, при реорганизации бизнес-процессов уже существующей системы строятся две модели: AS IS и TO BE. Модель AS IS призвана показать, как система функционирует в настоящий момент и является своего рода фотографией системы. А модель TO BE, которая строится исходя из результатов анализа модели AS IS, показывает, как система будет работать после реорганизации. Как же провести этот анализ? Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияние ее результат) и входу (объекты или информация используются нерационально) и т.д. Кроме того, BPwin содержит ряд средств, которые помогают аналитику анализировать и исправлять модель AS IS. Прежде всего, речь идет о том, что BPwin указывает на синтаксические ошибки в модели, которые могут быть вызваны неправильной организацией системы. Когда все такие ошибки будут исправлены, перед аналитиком должна встать задача оптимизации, а для корректной постановки этой задачи, как известно, необходим критерий. Здесь BPwin снова приходит аналитику на помощь, предлагая ему то, что для оптимизатора значит ничуть не меньше, чем точка опоры для Архимеда. BPwin дает аналитику метрику - стоимостной анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (User Defined Properties, UDP).

Встроенный в BPwin механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) - это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа. ABС является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации. Стоимостной анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостной анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания в функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия. С помощью стоимостного анализа можно решить такие задачи как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь).

Механизм поддержки ABC в BPwin, хотя и учитывает стоимость выполнения каждой работы, продолжительность каждой работы по времени и сколько раз необходимо выполнить работу в течение одного цикла бизнес-процесса, все же дает довольно грубые оценки и, к тому же требует, чтобы все диаграммы, для которых производится оценка были выполнены в IDEF0. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report.

И, наконец, создатели BPwin очень хорошо понимают, что один в поле не воин, даже если этот "один" - BPwin 4.0, и поэтому BPwin тесно интегрируется с рядом известных продуктов Computer Associates и других компаний. Среди этих продуктов:

• Широко известный инструмент моделирования данных ERwin (CA/Logic Works). Erwin не нуждается в рекомендациях. Для тех, кто уже работает с BPwin, отметим, что в версии BPwin 4.0 интерфейсы экспорта и импорта синхронизованы с Erwin 4.0. Кроме того, появилась возможность ассоциирования сущностей и атрибутов с хранилищами данных.
• Система управления и хранения проектов ModelMart (CA/Logic Works), которая предоставляет репозитарий для коллективной разработки моделей. ModelMart гарантирует согласованность моделей, разграничение доступа к ним, поддержку версий и много других средств, которые так важны при командной разработке моделей. Сервер приложений для программных продуктов CA ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания "компонент" модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin.
• Инструмент стоимостного анализа EasyABC (ABC Technologies).
• В BPwin 4.0 стал возможен экспорт модели в систему имитационного моделирования Arena (Systems Modeling Corp.).

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