Волшебный ключик BPwin

Сергей Маклаков
В настоящее время, в условиях бурно изменяющихся экономических факторов перед управляющими предриятиями все чаще встает задача реорганизации деятельности. Целью такой реорганизации может быть реорганизация штатной структуры, внедрение новой технологии, автоматизация (внедрение новой информационной системы) и т.д. – все то, что может резко повысить эффективность работы и поможет выжить в условиях нестабильного внешнего окружения. Бессмысленно планировать изменения и улучшения, если нет понимания существующего положения дел. Поэтому, первым шагом при проведении реорганизации является описание того, как в настоящий момент работает предприятие. Это не такая простая задача, как может показаться на первый взгляд. Никто из сотрудников, включая руководителя, не может полностью и достаточно подробно описать бизнес-процессы организации. Рядовые сотрудники, возможно, хорошо представляют, что происходит на их конкретном рабочем месте, но плохо знают, как работают их коллеги и, тем более, не представляют, как работает организация в целом. Руководитель хорошо знает, как работает предприятие в общем, но не в состоянии вникнуть в особенности деятельности на каждом рабочем месте. Следовательно, для того, чтобы получить адекватное описание функциональности организации нужно аккамулировать знание многих людей в единой модели. Такая модель может помочь найти слабые места в организации бизнеса и явиться основой для оценки стоимости производства продукции или обслуживания клиентов и, затем, может служить основой для построения идеальной модели – такого конечного состояния бизнес-процессов, к которому следует перейти, чтобы добиться необходимого результата.

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

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

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

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

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

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

С появлением персональных компьютеров с графическими интерфейсами, на рынке стали предлагаться многочисленные средства, автоматизирующие построение структурных моделей (CASE- средства) . Одним из таких CASE- средств является Platinum BPwin 2.5 (До слияния Logic Works с Platinum Technology inc. выпускался под именем Logic Works BPwin). От инструментов подобного типа BPwin выгодно отличается тем, что поддерживает помимо IDEF0 методологии DFD и IDEF3 и тесно интегрируется с другими программными продуктами:

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

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных меж собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывают функции обработки информации, документы, объекты, а также сотрудников или отделы, которые участвуют в обработке информации. Синтаксис DFD включает помимо работ и стрелок дополнительные элементы: внешнюю сущность, которая служит для изображения внешних по отношению к проектируемой системе объектов, (например, клиент, отдел кадров, справочники) и хранилище данных - "склад" информационных объектов. Хранилищем данных может быть база данных, файл или архив бумажных документов. Хранилище данных – это как бы «замороженные» данные, позволяющие отобразить отсрочку в передаче объектов и информации от одной работы к другой.

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

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако, для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Перекресток – специфический для IDEF3 элемент – позволяет описать последовательность выполнения работ, очередность их запуска и завершения. С помощью диаграмм Workflow можно описывать сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции, моделируемой в методологии IDEF0. Если в одной модели необходимо осветить специфические стороны бизнес-процессов предприятия, BPwin позволяет переключиться на любой ветви модели с IDEF0 на нотацию IDEF3 или DFD и создать смешанную модель. BPwin имеет мощный инструмент навигации - Model Explorer, который позволяет представить смешанную модель в виде дерева диаграмм и существенно облегчает навигацию по модели. В версии BPwin 2.5 с помощью Model Explorer можно методом Drag&Drop переносить и копировать работы вместе со всеми соответствующими стрелками как внутри модели так и между моделями. Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF3 – синим.

Рис. 4. Представление смешанной модели в Model Explorer.

BPwin позволяет эффективно манипулировать моделями- сливать и расщеплять, документировать посредством генерации отчетов (всего 7 типов отчетов, поддерживаются запоминаемые определяемые пользователем стандартные отчеты) и т.д. BPwin в состоянии поддерживать синтаксис IDEF0, IDEF3и DFD. Частично ошибки анализируются на этапе внесения новых объектов (некоторые ошибочные элементы просто невозможно внести в диаграмму), частично – детектируются в специальном отчете - Model Consistency Report.

Обычно в целях реорганизации предприятия сначала строится функциональная модель существующей организации работы -«AS-IS» (как есть). На основе модели «AS-IS» достигается консенсус между различными единицами бизнеса по тому, «кто что сделал», и что каждая единица бизнеса добавляет в процесс. Модель «AS-IS» позволяет выяснить «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективной документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияние ее результат) и входу (объекты или информация используются нерационально) и т.д. Найденные в модели «AS-IS» недостатки можно исправить при создании модели «TO-BE» (как будет) - модели новой организации бизнес-процессов. Модель «TO-BE» нужна для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем. Как правило, строятся несколько моделей «TO-BE», из которых по какому-либо критерию выбирается наилучшая. Проблема состоит в том, что таких критериев много и непросто определить важнейший. Для того, чтобы определить качество созданной модели с точки зрения эффективности бизнес- процессов, необходима система метрики, то есть качество следует оценивать количественно.

BPwin предоставляет аналитику два инструмента для оценки модели – стоимостной анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (User Defined Properties, UDP). ABС является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации.

Рис. 5. Задание стоимости работ в диалоге Activity Cost.

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

ABC может проводиться только когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений). Эта методика включает основные понятия, такие как объект затрат (причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть стоимость объектов затрат), движитель затрат (характеристики входов и управлений работы, которые влияют на то, как выполняется и как долго длится работа) и центры затрат (центры затрат можно трактовать как статьи расхода). При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег, затем описываются центры затрат (cost centers) и, наконец для каждой работы на диаграмме декомпозиции назначаются продолжительность (duration), частота проведения данной работы в рамках общего процесса (frequency) и суммы по каждому центру затрат, то есть задается стоимость каждой работы по каждой статье расхода (рис. 5). Затраты вышестоящей работы определяется как сумма затрат дочерних работ по каждому центру затрат (режим Compute from Decompositions). Это достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Если схема выполнения более сложная, можно отказаться от подсчета и задать итоговые суммы вручную (Override Decompositions) или воспользоваться специализированным средством стоимостного анализа EasyABC. Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin - Activity Cost Report.

ABC позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Например, категория «Загрязнение окружающей среды», может объединять свойство «загрязнение воды» типа Real Number и свойство «загрязнение воздуха» типа Integer List c предварительно определенной областью значений (1, 2, 3, 4, 5). Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report.

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

Более подробно познакомиться с возможностями продукта BPwin можно на курсах, которые проводятся в Учебно-консалтинговом центр Interface Ltd.:
тел. (095)135-55-00, 135-25-19, mail@interface.ru

Координаты автора:
Учебно-консалтинговый центр Interface Ltd., тел. (095)135-55-00, 135-25-19,
mail@interface.ru

Interface Ltd.

По техническим вопросам обращайтесь к вебмастеру
Документ опубликован: 22.08.00