Использование BРwin в консалтинговых проектах

Максим Сычевский

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

   IDEF0

   DFD

   IDEF3

Функционально-стоимостной анализ (ABC-анализ)

Свойства, определяемые пользователем (User Defined Properties)

Словарь данных (Arrow data)

Организационные диаграммы

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

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

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

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

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

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

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

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

IDEF0

Первый информационный разрез — функциональность системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, обмениваясь информационными и материальными потоками с помощью людских и производственных ресурсов, потребляемых каждой работой. Посредством функционального моделирования можно провести системный анализ бизнеса, сосредоточившись на регулярно решаемых задачах или функциях, на показателях их правильного выполнения, необходимых для этого ресурсах, результатах и исходных материалах (сырье).

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

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

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

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

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

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

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

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

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

DFD

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

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

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

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

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

IDEF3

Третий информационный разрез — последовательность выполняемых работ.

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

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

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

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

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

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

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

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

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

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

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

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

Функционально-стоимостной анализ (ABC-анализ)

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

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

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

На практике при проведении крупных консалтинговых проектов мы столкнулись с проблемой, при которой использование метода АВС затруднено. Это связано с тем, что невозможно собрать полную информацию о стоимости производимых работ из-за необходимости опросить большое количество. Так, например, чтобы опросить весь персонал компании заказчика, около 9 тыс. человек, понадобилось бы примерно 6 месяцев исследований из расчета опроса 2 тыс. сотрудников с уникальными должностями и последующей консолидацией результата.

Нами был выбран другой подход, согласно которому утверждается, что 20% работ составляют 80% затрат (рис. 8).

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

Рассмотрим простой реальный пример. В процессе заключения договора на поставку ТМЦ (товарно-материальных ценностей. — Прим. ред.) в компании заказчика договор сначала отсылается поставщику на подписание, а только после этого визируется у должностных лиц внутри компании и подписывается генеральным управляющим (или его заместителем — рис. 9).

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

Однако из интервью с сотрудниками отдела закупок выяснилось, что со стороны клиента никогда не было разногласий по поводу подписания договора (или таких случаев мало). Но со стороны руководства компании к клиентам выдвигаются определенные требования. В результате договор может быть не подписан. Проанализировав стоимость этих работ по критериям «Курьерская доставка», «Распечатка», «Упаковка», консультанты обнаружили факт того, что стоимость работы по подписанию договора у клиента значительно выше стоимости работ по подписанию его руководством компании — за счет увеличенных расходов на упаковку и курьерскую доставку. Таким образом, в случае неподписания договора руководством сумма, которую теряет компания, выше, чем если бы договор подписывался у клиента в последнюю очередь.

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

Этот простой пример наглядно иллюстрирует важность применения данного анализа при проведении проектов реструктуризации компаний.

Для проведения более детального функционально-стоимостного анализа можно воспользоваться специализированными средствами, такими, например, как EasyABC, с которым у BPwin имеется двунаправленный интерфейс обмена информацией.

Свойства, определяемые пользователем (User Defined Properties)

ля того чтобы усилить значение модели, средств функционально-стоимостного анализа окажется недостаточно. Поэтому в BPwin имеется возможность внесения собственных показателей — свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP. Так, например, категория «Трудоемкость» может быть выражена количеством дней или часов, необходимость для выполнения данной работы. Каждой работе можно поставить в соответствие набор из нескольких UDP.

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

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

Наряду с предоставлением аналитику критериев оценки моделей UDP позволяет структурировать имеющуюся документацию, привязав ее к конкретным объектам диаграммы. Объекты могут быть любые — текстовые файлы, рисунки, схемы. Так, например, в качестве дополнительной документации могут выступать файлы инструкций, положений и правил, регламентирующих выполнение работ, к которым они привязаны. В частности, на рисунке показана привязка документа «Инструкция по делопроизводству» в качестве исходной документации к процессу «Запись информации в регистрационную карточку» (рис.11).

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

Словарь данных (Arrow data)

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

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

Рассмотрим пример отсутствия унификации у трех документов «Заявка на ТМЦ», «Заявка на нефтепроводные и водопроводные трубы», «Заявка на изготовление деталей, запчастей и нестандартного оборудования». При детальном их рассмотрении можно заметить, что у второго документа такие параметры, как «Наименование трубопровода», «Размер трубы», «Назначение», «% воды» и «Объем», объединяются одним показателем первого документа «Тип, марка, полная характеристика». В третьем же документе, напротив, не хватает таких параметров, как «Количество» и «Тип, марка, полная характеристика» (рис. 12).

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

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

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

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

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

Организационные диаграммы

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

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

В заключение хотелось бы отметить, что на построении модели TO BE и организационных диаграмм работа на предприятии заказчика не заканчивается. На основании информационной модели, полученной при проведении анализа в BPwin, может быть построена база данных разрабатываемой информационной системы. Для этого BPwin тесно интегрирован с другим программным продуктом Computer Associates — ERwin, основой модели которого служат параметры и атрибуты информационных потоков модели BPwin.

Все вышеперечисленные возможности BPwin делают его лидером среди недорогих CASE-инструментов, предназначенных для анализа деятельности предприятия и проектирования информационных систем в ходе выполнения консалтинговых проектов.

КомпьютерПресс 1'2002