CC BY
439
Вестник СПбГУ. Сер. 8. 2005. Вып. 4
Н. В. Фирсова
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ И ОЦЕНКА ИХ ПРИМЕНЕНИЯ ДЛЯ ЦЕЛЕЙ РЕИНЖИНИРИНГА
В статье представлен обзор программных средств разработки и поддержания модели бизнес-процессов проблемной области. Дано определение понятий модели и самой проблемной области, перечисляются виды моделей. Вниманию читателей предлагается сравнительный анализ наиболее популярных стандартов моделирования с их классификацией с точки зрения функционального и объектно-ориентированного подходов; проводится оценка средств моделирования и вносятся рекомендации по их применению в целях комплексного реинжиниринга бизнеса.
введение
Современные рыночные механизмы функционирования российской экономики объективно вызывают необходимость формирования эффективной стратегии развития предприятий и как следствие — проведения их системной реструктуризации, позволяющей значительно повысить стоимость компании и обеспечить ее долгосрочную конкурентоспособность. Только таким образом может быть решен ключевой вопрос экономического развития — вопрос привлечения дополнительных инвестиций в предприятия, которые повлекут за собой подъем российской экономики.
Ключевой задачей системной реструктуризации выступает обеспечение финансовой эффективности и информационной прозрачности компании.
Невозможно отрицать тот факт, что сегодня постоянное улучшение финансово-хозяйственной деятельности является жизненной философией любой организации, если она хочет выжить и успешно функционировать в среднем, не говоря уже о долгосрочном, периоде. Одним из мощных средств, используемых для этих целей, является реинжиниринг бизнес-процессов (РБП).
РБП как один из передовых подходов к реструктуризации предприятий ориентирован на реализацию принципа сквозного управления по-
© Н. В. Фирсова, 2005
следовательностью операций, выполняемых взаимодействующими подразделениями организации для максимального удовлетворения запросов потребителей. Помимо этого, реинжиниринг включает другие элементы, например, правильное использование принципов управления процессами, применение методов всеобщего управления качеством (total quality management — TQM), а также современные методы мотивации и управления персоналом.
Закономерно, что РБП влечет за собой изменение архитектуры информационной системы организации. Для успешной реализации данной сравнительно новой концепции управления в виде реинжиниринговых проектов необходимо тесное взаимодействие между специалистами сферы информационных технологий и экспертами предметной области. Единственно возможным мостом для установления такого взаимодействия может стать создание моделей представления объекта (организации), позволяющих описать текущую структуру процессов (AS IS) и структуру процессов с учетом желаемых изменений (TO BE).
Иными словами, для получения адекватного проблемной области (под которой в случае реинжиниринга следует понимать прежде всего совокупность выявленных неблагополучных бизнес-процессов исследуемого предприятия, а в более общем смысле — взаимосвязанную совокупность управляемых объектов предприятия, субъектов управления, функций управления и программно-технических средств их реализации) проекта системы необходимо иметь целостное представление о ее модели, отражающее все аспекты функционирования последней. Под моделью в данном случае будем понимать систему, отражающую функционирование исследуемой проблемной области и включающую средства для визуализации, описания, проектирования и документирования архитектуры системы бизнес-процессов. Модели дают возможность оценить достоинства и недостатки существующей системы, а следовательно, создать эффективную архитектуру новой системы. Именно поэтому моделирование является одной их наиболее востребованных областей системного анализа. Бурное развитие парадигмы процессного подхода также подтверждает данный факт.
виды моделей
Единая классификация видов моделей и моделирования затруднительна в силу многозначности понятия «модель» в науке и технике. Ее можно проводить по различным основаниям: по характеру моделей (т. е. по средствам); по типу моделируемых объектов; по сферам приложения (модель в технике, в физических науках, в химии, модель психики и т. п.) и его уровням («глубине»). В связи с этим любая классификация моделей обречена на неполноту, тем более что терминология в данной области опирается не
столько на «строгие» правила, сколько на языковые, научные и практические традиции, а еще чаще определяется в рамках конкретного контекста и за его пределами никакого стандартного значения не имеет (типичный пример — термин «кибернетическое моделирование»).
Тем не менее построение полноценной карты бизнес-процессов для использования в корпоративной инфраструктуре управления и реинжиниринге требует создания нескольких видов моделей бизнес-процессов, среди которых следует выделить:
♦ Графические, в которых бизнес-процессы наглядно представляются в виде графических элементов (в основном прямоугольников и стрелок) с помощью определенной методологии.
♦ Описательные, как правило, дающие пояснения к графической и иным моделям бизнес-процессов для облегчения понимания последних руководителями и специалистами компании.
♦ Затратные, описывающие распределение затрат между работами процесса в соответствии с хорошо известной методологией функционально-стоимостного анализа процессов (которую, впрочем, было бы правильнее назвать функционально-затратным анализом, Activity-Based Costing (ABC)).
♦ Стоимостные, позволяющие оценить объем стоимости, создаваемой в бизнес-процессе, а также понять механизм ее формирования (что дает возможность значительно повысить эффективность управления совокупностью бизнес-процессов).
♦ Имитационные, благодаря которым оптимизируются операционные характеристики соответствующих процессов (например, управления складом).
Кроме того, модели могут быть разных типов: канонические, кибернетические, иерархические, сетевые, ABC-модели и др. Поэтому для выполнения вышеперечисленных требований целесообразно, создавая систему моделей, использовать их разные типы для того, чтобы более широко представить все аспекты (и структурный, и оценочный) существования проблемной области.
Так, на стадии построения модели существующего бизнеса (AS IS) и представления результатов проектирования (TO BE) заказчику наибольшую актуальность приобретает использование графических языков моделирования (графические модели выражают архитектуру системы и объясняют, что эта система будет делать; показывают, какого рода абстракции существуют в системе и какие ее части нуждаются в дальнейшем уточнении). Таким образом, структурный аспект моделей проблемной области лучше всего отражают графические методы. Оценочные, связанные с разработкой показателей эффективности системы (время выполнения процес-
са, их надежность, стоимостные затраты и т. п.) — методы стоимостного анализа процессов (например, ABC-анализ) и динамические методы имитационного моделирования. Последние наиболее глубоко представляют не только сами модели, но и достаточно полные средства для их анализа. Модели создаются в виде потоковых диаграмм, где показаны основные рабочие процедуры, используемые в компании, описаны их поведение, а также информационные и материальные потоки между ними. Впрочем, построение реальных имитационных моделей — довольно трудоемкий процесс, а их детальный анализ, выходящий за рамки простого сбора статистики по срокам и стоимостям, зачастую требует от пользователя специальной подготовки. Сегодня для преодоления этих трудностей начинают использоваться методы инженерии знаний, с помощью которых в моделях можно непосредственно представлять плохо формализуемые знания менеджеров о бизнес-процессах и рабочих процедурах.
case-cpeactba. общая характеристика и классификация
Исторически большинство консалтинговых фирм основывало свои подходы к реинжинирингу, базируясь на CASE-технологиях разработки информационных систем.
Сам термин CASE (Computer Aided Software Engineering) имеет весьма широкое толкование. Первоначально его значение ограничивалось вопросами автоматизации разработки только лишь программного обеспечения, а в настоящее время оно приобрело новый смысл и охватывает процесс разработки сложных ЭИС (экономических информационных систем) в целом. CASE-технология представляет собой совокупность методов проектирования ЭИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ЭИС и разрабатывать приложения в соответствии с информационными потребностями пользователей [Вендров, 2002, с. 33]
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла программного обеспечения (ПО) и обладающее такими основными характерными особенностями, как:
♦ мощные графические средства для описания и документирования информационных систем (ИС), обеспечивающие удобный интерфейс с разработчиком и развитие его творческих возможностей;
♦ интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
♦ использование специальным образом организованного хранилища проектных метаданных (репозитория).
Выделяют следующие типы CASE-средств:
♦ средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
♦ средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silver-run (CSA), PRO-IV (McDonnell Douglas), CASE-Лналитик (Макро-Проджект));
♦ средства проектирования баз данных (БД), обеспечивающие моделирование данных и генерацию схем баз данных для наиболее распространенных систем управления базами данных (БД). К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
♦ средства разработки приложений: 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.), и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично — в Silverrun;
♦ средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
♦ Vantage Team Builder (Westmount I-CASE);
♦ Designer/2000;
♦ Silverrun;
♦ ERwin+BPwin;
♦ S-Designor;
♦ CASE-Лналитик [Вендров, 2002, с. 34].
Большинство существующих CASE-средств основано на методах структурного (функционального) или объектно-ориентированного анализа и
проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
сравнительный анализ наиболее распространенных
инструментальных средств моделирования бизнес-процессов
Существует более 20 технологий проектирования организационно-технических систем и несколько сотен инструментов, предназначенных для автоматизации этого процесса.
Среди давно известных методов и языков моделирования бизнес-процессов можно назвать блок-схемы, ориентированные графы, сети Петри, IDEF и SADT. Сравнительно новыми считаются eEPC, ARIS, UML, SPA, BPD, BPML, XPDL, BPEL.
Под инструментальными средствами бизнес-инжиниринга и реинжиниринга следует понимать программные продукты, предназначенные для моделирования и перепроектирования бизнес-систем. Какие же задачи являются для них приоритетными? В общих чертах ответ на этот вопрос следует из самоопределений продуктов, данных авторами наиболее известных средств:
♦ Пакет ARIS ToolSet — многопользовательская среда описания и анализа рабочих процессов предприятий, поддерживающая разработку сложных гетерогенных информационных систем (ARIS, АРИС — Архитектура Интегрированных Информационных Систем) и сопровождающая весь цикл разработки (анализ — проектирование — реализация). Применение этих инструментальных средств позволяет многократно сократить длительность этапа проектирования при гарантированном уровне проектных решений. В данной среде не накладывается жестких ограничений на последовательность проработки различных аспектов деятельности и предоставляется ряд других возможностей по описанию рассматриваемого предприятия.
♦ BPwin — средство функционального моделирования, использующее стандарт IDEF0-IDEF3, и ERwin — средство концептуального моделирования БД на основе стандарта IDEF1X. Функциональная модель IDEF0 отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. IDEF0 может применяться для моделирования широкого круга систем и определения требований и функций, а затем — для разработки системы, которая удовлетворяет этим требованиям и реализует указанные функции. BPwin также работает с организационными диаграммами (organization charts), которые позволяют описать структуру предприятия и формируются на основе предварительно созданных
ролей. Кроме того, в продукте BPwin 4.0 стал возможен экспорт модели в систему имитационного моделирования Arena (Systems Modeling Corp.). Пример применения методологии функционального моделирования содержится в [Фирсова, 2004, с. 125]. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в ре-позитории данных средств. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений. Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.
♦ Rational Rose 98 — средство автоматизации этапов анализа и проектирования ПО (программного обеспечения), а также генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Дже-кобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQL Windows и ObjectPro). Основной вариант — Rational Rose/C++, позволяющий разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
Важно также отметить, что «из множества существующих на сегодняшний день методов моделирования лишь две из них получили статус официального стандарта — IDEF и UML, — а третья является стандартом де-факто ARIS» [Тельнов, 2004, с. 71].
Стандарт IDEF (Integration Definition for Function Modeling) имеет дело с функциональными моделями. Для них характерны процедурная стройность декомпозиции и наглядность представления.
В настоящий момент к семейству IDEF можно отнести следующие стандарты:
♦ IDEF0 — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
♦ IDEF1 — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
♦ IDEF1X (IDEF1 Extended) — методология построения реляционных структур. IDEF1X относится к типу методологий «Сущность — взаимосвязь» (ER — Entity — Relationship) и, как правило, применяется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
♦ IDEF2 — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);
♦ IDEF3 — методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0: каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;
♦ IDEF4 — методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым представляя возможность анализировать и оптимизировать сложные объектно-ориентированные системы;
♦ IDEF5 — методология онтологического исследования сложных систем. Применяя методологию IDEF5, онтологию системы можно описать с помощью определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент
времени. На базе этих утверждений формируются выводы о дальнейшем развитии системы и производится ее оптимизация.
Методику функционального моделирования IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teq-nique). Исторически IDEF0 как стандарт был разработан в 1981 г. в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF = ICAM DEFinition). В процессе практической реализации участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик — специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта. В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 г. стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (NIST).
Применение IDEF базируется на двух важных обстоятельствах:
1. IDEF0 позволяет решать задачи описания классификации процессов в рамках внедряемой на большинстве предприятий системы менеджмента качества.
2. IDEF0 является стандартом для функционального моделирования в ряде стран, включая США и Россию, т. е. дает возможность ее использования в качестве единого языка.
Результатом внедрения IDEF0 становится модель, состоящая из диаграмм, текста и словаря терминов, имеющих перекрестные ссылки друг на друга. Диаграммы — основной компонент модели. Все процессы и субпроцессы отражают определенные функции и представлены на диаграммах в виде прямоугольников (функции), а их взаимодействие, в свою очередь, — в виде стрелок. Стрелки показывают отношения между несколькими подфункциями, образующими более общую функцию. Модель IDEF0 начинается с представления системы как единого целого — прямоугольника с взаимодействиями, простирающимися за пределы системы. Прямоугольник, обозначающий систему как единое целое, затем подвергается детализации
на другой диаграмме; получившиеся прямоугольники соединяются стрелками-взаимодействиями. Детализация прямоугольника производится путем построения диаграммы-потомка, состоящей не менее чем из трех, но не более чем из 7-8 прямоугольников (рис. 1).
Рис. 1. Декомпозиция процессов на более детальные подпроцессы Источник: [Вендров, 2002, с. 39].
Каждая диаграмма модели показывается вместе с ее отношением к другим диаграммам путем нанесения связывающих их стрелок.
Другой современной методикой бизнес-моделирования, получившей широкое распространение в России, является ARIS (Architecture of Integrated Information Systems — проектирование интегрированных информационных систем).
В настоящее время это наиболее объемная методика, содержащая около 100 различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов деятельности организации. Часть моделей продукта ARIS используется в настроечном модуле интегрированной информационной системы SAP/R3, который применяется при внедрении системы и ее настройке на деятельность компании. В связи с большим количеством бизнес-моделей, ARIS подразделяет их на четыре группы:
1) «Оргструктура», состоящая из моделей, с помощью которых описывается организационная структура компании, а также другие элементы внутренней инфраструктуры организации;
2) «Функции», в состав которой входят модели, используемые для описания стратегических целей компании, функций и прочих элементов функциональной деятельности организации;
3) «Информация», охватывающая модели, с помощью которых описывается информация, используемая в деятельности организации;
4) «Процессы», представляющая модели для описания бизнес-процессов, а также различных взаимосвязей между структурой, функциями и информацией.
Значительным преимуществом ARIS является эргономичность и высокая степень визуализации бизнес-моделей, что делает данную методологию удобной и доступной в использовании для всех сотрудников компании, начиная от топ-менеджеров и заканчивая рядовыми работниками. В ARIS смысловое значение имеет цвет, что повышает восприимчивость и читабельность схем бизнес-моделей. Помимо большего количества моделей, по сравнению с другими средами, ARIS имеет множество различных объектов, используемых при построении бизнес-моделей, что увеличивает их аналитичность.
ARIS рассматривает предприятие как совокупность четырех взглядов: на организационную структуру, на структуру функций, на структуру данных и на структуру процессов. При этом каждый из них подразделяется еще на три подуровня: описание требований, описание спецификации, описание внедрения. Таким образом, ARIS предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-процессов предлагается использовать 85 типов моделей, каждая из которых принадлежит тому или иному аспекту.
На рис. 2 показано, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация еЕРС построена на определенных семантических правилах описания:
♦ каждая функция должна быть инициирована событием и должна завершаться событием;
♦ в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить более одной стрелки, описывающей завершение данного процесса.
Логическое «И»
Рис. 2. Пример логики описания работ в ЛКК Источник: [Репин, Елиферов, 2004, с. 172].
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Используемые при построении модели символы логики позволяют отразить ответвление и слияния бизнес-процессов.
В общем случае практика одного из лидеров консалтинга инжиниринговых технологий — компании BETEC — показала, что в проектах наиболее часто используются модели, приведенные в табл. 1.
В. В. Репин и В. Г. Елиферов в своей книге «Бизнес-процессы: Регламентация и управление» [Репин, Елиферов, 2004, с. 184] приводят различные ситуации применения нотаций1 ARIS Toolset 5.0 и BPwin 4.0 и их экспертную оценку по 5-балльной шкале (табл. 2).
1 Нотация — способ определения конструкций модели (глоссарий компании БИГ).
Таблица 1
Наиболее часто используемые на практике модели ARIS
Название модели
№ Английский вариант Русский вариант Описание и предназначение модели
1 OD — Objective diagram Диаграмма целей Модель описывает стратегические цели компании и их взаимосвязь с другими элементами организации
2 PST — Product/ Service tree Дерево продуктов и услуг Модель представляет продукты и услуги, производимые компанией, и их взаимосвязь с другими элементами организации
3 FT — Function tree Дерево функций Модель характеризует функции, выполняемые в компании, и их иерархию
4 FAD — Function allocation diagram Диаграмма окружения процесса Процессная модель описывает окружение бизнес-процесса
5 VACD — Value added chain diagram Диаграмма цепочки добавленной стоимости Процессная модель — прототип классического стандарта DFD. Применяется для описания бизнес-процессов верхнего уровня
6 PSM — Process selection matrix Матрица выбора процесса Процессная модель — прототип классического стандарта DFD. Является альтернативой модели VACD и используется для описания бизнес-процессов верхнего уровня
7 eEPC — Extended event driven Process Chain Расширенная цепочка процессов, управляемая событиями Процессная модель — прототип классического стандарта WFD. Применяется для описания бизнес-процессов нижнего уровня
8 ORG — Organizational chart Модель организационной структуры Модель описывает организационную структуру компании
9 ASTD — Application system type diagram Диаграмма типов информационных систем Модель представляет структуру информационных систем, используемых в компании
Они же приводят варианты позиционирования систем по отношению к решению задачи моделирования бизнес-процессов (рис. 3).
Таблица 2
Сравнительный анализ нотаций ARIS Toolset 5.0 и BPwin 4.0
Задача/Инструментальная среда ARIS BPwin 4.0
Toolset 5.0
Разовый проект по описанию бизнес-процессов,
например:
• описание одного бизнес-процесса с точки зрения 4 5
контроля и управления;
• описание функциональных возможностей новой 3 5
системы управления на верхнем уровне
Длительный (непрерывный) проект по описанию дея- 5 3
тельности компании с различных точек зрения (орга-
низационная структура, структура документов, боль-
шой объем базы данных процессов и т. д.)
Разработка системы автоматизации:
• описание функциональных возможностей системы; 3 3
• создание логической модели данных; 3 5
• формирование физической модели данных — BPwin +
+ ERwin +
+ Paradigm Plus
В
о
0 и
1
я
m О Я u
я
а л
а о
©
ARIS
Bpwin
Простота использования в проекте
Рис. 3. Позиционирование систем ARIS и BPwin Источник: [Репин, Елиферов, 2004, с. 185].
Объектно-ориентированные модели. Несмотря на множество преимуществ, одним из основных недостатков функциональных моделей является отображение разветвлений в процессах обработки информации и, как след-
ствие, плохая читаемость моделей при большом числе ветвлений; также может иметь место повторяемость одинаковых функций в разных процессах. Эти недостатки снимаются в объектно-ориентированных моделях, где главным структурообразующим компонентом начинает выступать класс объектов с набором функций. «В объектно-ориентированном подходе меняется сам принцип проектирования системы. Сначала выделяются классы объектов, а далее методы их обработки (функциональные процедуры)» [Тельнов, 2004, с. 74].
Графические методы моделирования проблемной области в объектно-ориентированном подходе обобщены в языке унифицированного моделирования UML. Объектно-ориентированный подход к описанию бизнес-процессов с использованием языка UML реализован в технологии Ration Unified Process и Rational Rose. Методика моделирования, являющаяся составной частью данной технологии, предусматривает построение двух моделей:
1) модели бизнес-процессов;
2) модели бизнес-анализа.
Модель бизнес-процессов описывает бизнес-процессы организации в терминах ролей и их потребностей [Вендров, 2004, с. 57].
Для каждого процесса строится модель бизнес-анализа — объектная модель, представляющая реализацию бизнес-процессса и строящаяся на основе диаграмм разных типов:
♦ диаграмм классов (как обязательная);
♦ диаграмм последовательности;
♦ диаграмм деятельности;
♦ диаграмм состояний.
На продукте Rational Rose следует остановиться более подробно. Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения так называемых бизнес-моделей, содержащаяся в дополнительном наборе рекомендаций или методике RUP, сопровождающей пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Однако некоторые авторы [Сахаров, 2003] убеждены в том, что эти диаграммы позволяют описать лишь малую часть сведений, необходимых для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги диаграмм Use Case и Activity не имеют тех смысловых типов, которые имею дуги IDEF0. Действительно, что означает стрелка, соединяющая между собой два процесса, — просто последовательность их исполнения или, например, то, что второй процесс обрабатывает некоторые (какие?) результаты деятельности первого, а может быть, наоборот, для работы первого процесса необходима некая (какая?) информация, которую подготавливает
второй процесс? Точно так же непонятно, как интерпретировать связи «процесс—состояние», «состояние—состояние» и др.
Поэтому Rational Rose допускает построение синтаксически корректных Activity-диаграмм, трудно поддающихся толкованию с позиции здравого смысла. Пример такой диаграммы приведен на рис. 4.
Рис. 4. Пример синтаксически корректной, но не поддающейся осмысленному объяснению Activity-диаграммы
Источник: [Сахаров, 2003].
Поэтому, на наш взгляд, объектно-ориентированные модели с точки зрения наглядности представления модели заказчику явно уступают функционально ориентированным и, как справедливо отмечает тот же Ю. Ф. Тельнов, «наиболее эффективны в применении на стадии программной разработки реализации системы» [Тельнов, 2004, с. 75].
Принимая во внимание то, что для успеха реализации реинжиниринговых проектов одним из ключевых требований, предъявляемых к средству моделирования, стоит назвать его практическую апробированность, автор предлагает остановиться на сравнении наиболее применяемых стандартов и нотаций. Чаще всего в работе отечественных системных аналитиков используются нотации IDEF0/IDEF3/DFD, ARIS, UML. Поэтому сравнительный анализ целесообразно провести по программным продуктам ARIS, BPwin/ERwin, Rational Rose.
Для грамотного сравнения продуктов необходимо разработать основные качественные требования, предъявляемые к программным продуктам
с позиций бизнес-реинжиниринга. Необходимо отметить, что общепринятой системы факторов качества модели предметной области на сегодняшний день не существует. Рассмотренные автором свыше 30 печатных и 100 электронных изданий позволяют сделать вывод о том, что вопросы оценки качества моделирования бизнес-процессов слабо проработаны, отсутствуют системы (в том числе автоматизированные) оценки качества, удовлетворяющие всем требованиям (учет как процесса, так и результата моделирования; наличие полной системы факторов качества и т. д.). Помимо этого, необходима научная, методическая и программная поддержка оценки качества моделирования бизнес-процессов.
Среди немногих сформулированных основных требований к модели перечисляются: полнота, гибкость, длительность разработки и реализации, структурированность, интегративность и т. д.
Обращаясь к определению реинжиниринга2 и его задаче оптимизации совокупных затрат, автор статьи предлагает свой набор требований, изложенных в табл. 3.
Таблица 3
Сравнительный анализ программных продуктов моделирования и оптимизации бизнес-процессов предприятия*
Функции, свойства, требования АЯВ ЕЯ'тп/ BPwin Яайопа1 Козе
1 2 3 4
Моделирование организационных функций и процессов + + +
Разработка технического задания + +/- +/-
Анализ (функционально-стоимостной анализ) + + +/-
Оптимизация бизнес процессов + - -
Имитационное моделирование, событийно-управляемое моделирование + +/- -
Оформление проектной документации; генерация технологических инструкций для рабочих мест + +/- +
Хранение моделей деятельности предприятий + +/- +/-
2 «Реинжиниринг есть фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность» [Хамер, Чампи, 1997].
Окончание табл. 3
1 2 3 4
Создание концептуальных и физических моделей структуры базы данных +/- + +
Стандартное представление основных бизнес-процессов (более 100 типов) + - -
Ведение библиотеки типовых бизнес-моделей + +/- +/-
Возможность групповой работы над проектом + + +
Выдача встроенных отчетов по стандарту К09000 + - -
Удобство работы по созданию моделей +/- +
Срок разработки и реализации - + -
Полнота + +/- +/-
Сложность разработки нестандартных отчетов - + -
Понятность, читаемость +/- + -
Наличие формальных процедур проверки на корректность моделей описания - + -
Оценка эффективности от собственной реализации +/- +/- +/-
Наличие программных средств для создания информационной системы и баз данных +/- + +
Разработка системы автоматизации +/- + +
Ценовые различия (3 — самое дорогостоящее ПО) 2 1 3
Примечания: + — да;
+/- — частичная реализация, требующая доработки иными инструментальными
средствами; - — нет. Выводы и рекомендации.
* Составлено по: [Рубцов; Репин, Елиферов, 2004], а также на основе собственного практического опыта, типовых описаний программных продуктов.
Проведенное исследование самых известных инструментальных средств моделирования бизнес-процессов показывает, что ни одно из них не удовлетворяет в полной мере требованиям комплексного реинжиниринга бизнес-процессов, где наиболее целесообразными в силу той же комплексности являются различные средства индустриального проектирования, поддерживающие разработку проекта на всех его стадиях и этапах.
Говорить о преимуществах той или иной методики бессмысленно, пока не определены виды, конкретные цели и границы проекта, его основные и вспомогательные задачи, масштабы преобразований. При выборе программного продукта также важно принимать во внимание стоимость не только поставки продукта, но и установки, обучения персонала, затраты на пополнение системы/базы информацией, поддержание моделей в актуальном состоянии и т. п. Так, в проектах по инжинирингу и реинжинирингу небольших организаций по численности и набору продуктов/услуг в целях регламентации и документирования выполняемых работ, а также для реинжиниринга отдельно взятых подразделений вполне подходит BPwin. В условиях ограниченности средств заказчика можно обойтись даже максимально доступными средствами программных продуктов MS Word, Excel или Visio. На крупных предприятиях, особенно в высокотехнологичных отраслях, при проведении реинжиниринга с последующим внедрением корпоративных информационных систем более предпочтителен ARIS, обладающий более расширенными возможностями.
Как правило, в проекте реинжиниринга всей совокупности бизнес-процессов предприятия речь идет не об одном, а о целой сети отдельных и взаимоувязанных проектов изменений, в связи с чем целесообразно применение различных методик моделирования для разных стадий проекта. Этому способствует и дифференциация бизнес-процессов по динамике принятия решений и специфике деятельности предприятия (производство продукта, услуг). Так, для формализации рутинных, повторяющихся процессов более подходят функционально ориентированные модели, а для динамических — объектно-ориентированные. Таким образом, актуальной задачей на сегодняшний день является интеграция различных методов, подходов, языков моделирования и возможностей отображения моделей проблемной области и организации в целом в рамках универсальной методологии с использованием единого языка программирования. В этом смысле большие надежды возлагаются на увязку нотации BPMN (The Business Process Modeling Notation) и языка моделирования BPEL (Business Process Execution Language for Web Services).
Литература
Вендров A. M. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2002. Вендров A. M. Современные методы и средства моделирования бизнес-процессов (обзор) // 7-я научно-практическая конференция «РБП-СУЗ-2004»: Сб. докладов. М.: МЭСИ, 2004. С. 57. Репин В. В., Елиферов В. Г. Бизнес-процессы: Регламентация и управление. М.: ИНФРА-М, 2004.
Рубцов С. В. Сравнительный анализ и выбор средств инструментальной поддержки организационного проектирования и реинжиниринга бизнес-процессов [Электронный ресурс]. — Режим доступа: http://or-rsv.narod.ru/Articles/Aris-IDEF.htm
Сахаров П. Rational Rose, BPwin и другие — аспект анализа бизнес-процессов [Электронный ресурс]. — Режим доступа: http://www.bcc.ru/press/articles/ rr_bpwin_others.html
Тельнов Ю. Ф. Реинжиниринг бизнес-процессов. Компонентная методология. 2-е изд., перераб. и доп. М.: Финансы и статистика, 2004.
Фирсова Н. В. Реинжиниринг бизнес-процессов сбыта с использованием методологии моделирования IDEF0 // 7-я научно-практическая конференция «РБП-СУЗ-2004»: Сб. докладов. М.: МЭСИ, 2004. С. 124-127.
Хамер М., ЧампиДж. Реинжиниринг корпорации: Манифест революции в бизнесе / Пер. с англ. СПб.: СПУ, 1997.
Статья поступила в редакцию 18 апреля 2005 г.
