Rational Rose, BPwin и другие — аспект анализа бизнес-процессов

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

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

• описание бизнес-процессов, происходящих на предприятии;
• выделение бизнес-процессов или их участков, подлежащих автоматизации.

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

В последнее время для целей анализа деятельности предприятий все большее распространение получает средство моделирования Rational Rose компании Rational Software. Подтверждение этому факту легко найти в Internet, проанализировав требования, которые формулируют различные компании к кандидатам на ИТ-вакансии. В большинстве случаев в состав требований обязательно включается знание Rational Rose и унифицированного языка моделирования (UML), на котором оно основано.

Кроме того, часто приходится слышать и читать, что UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов.

Так, на сайте компании «Интерфейс Ltd» (партнера фирмы Rational Software) приводятся следующие слова вице-президента Rational Роджера Оберга: «Rational Rose стала стандартом при разработке приложений и бизнес-моделировании.» (пресс-релиз от 03.04.2000, http://www.interface.ru/fset.asp?Url=/chapters/news.htm)

Там же среди новостей от 29 мая 2000 года опубликовано следующее сообщение: «Корпорация Rational Software объявила о выходе Rational Rose 2000е — новой версии CASE-средства визуального проектирования информационных систем, позволяющего моделировать как компоненты программного обеспечения, так и бизнес-процессы» (http://www.interface.ru/fset.asp?Url= /chapters/news.htm).

Там же опубликована статья Александра Новичкова «Эффективная разработка программного обеспечения с использованием технологий и инструментов компании Rational», в конце которой приводится рекомендация: «Есть смысл приобретать AnalystStudio для проведения бизнес-моделирования. Для данных целей набор содержит все необходимое». Напомню, что AnalystStudio — набор продуктов фирмы Rational Software, рекомендованный аналитикам и включающий в себя Rational Rose как основной продукт, и Rational Unified Process, Rational Requisite PRO, Rational ClearQuest и Rational SoDA как дополнительные.

На сайте другого партнера фирмы Rational Software, компании «АйТи», утверждается: «Rational Rose 2000 предназначено для создания сложных коммерческих приложений и корпоративных информационных систем и ориентировано на аналитиков, разработчиков архитектуры и программистов» (http://www.it-scs.ru/consult/rose2000.html).

По мнению автора, предложение использовать Rational Rose в такой неоправданно широкой области — серьезное заблуждение. Во всяком случае, на российском рынке CASE-средств давно присутствуют и успешно используются инструменты, существенно лучше реализующие потребности аналитика при описании и анализе деятельности предприятия.

Ниже приводится попытка сравнения некоторых характеристик и особенностей описания бизнес-процессов, реализованных в программном продукте Rational Rose фирмы Rational Software и продуктах, основанных на методологии IDEF0, наиболее распространенным из которых на российском рынке является BPwin корпорации Computer Associates.

Выбор для сравнения с Rational Rose продуктов, основанных на методологии IDEF0, обуславливается не желанием автора доказать, что IDEF0 не имеет достойных конкурентов. Существуют и другие методики, вполне пригодные для анализа деятельности предприятий и описания бизнес-процессов. Задачей данной статьи является обоснование точки зрения автора, что существуют CASE-средства (хотя бы одно!), подходящие для целей анализа гораздо лучше, чем Rational Rose. Выбор же IDEF0 обусловлен лишь тем, что автор давно и плодотворно работает именно с IDEF0 и поэтому хорошо знаком с возможностями этой методологии и соответствующих программных средств.

Кроме того, IDEF0 среди современных методологий выделяется своим широким применением. К 1981 году IDEF0 уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими свыше 2000 разработчиков. В настоящее время ее широко применяют также в европейской, дальневосточной и американской аэрокосмической промышленности, что существенно увеличивает эти цифры [1].

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

1. Процесс (Activity) изображается прямоугольником.
2. Стрелки слева (Input) отображают необходимые для исполнения процесса входы.
3. Стрелки справа (Output) отображают результаты исполнения процесса (выходы).
4. Стрелки снизу (Mechanism) отображают необходимые для исполнения процесса механизмы, то есть те объекты, которые собственно и исполняют данный процесс. Например: оператор, рабочий, автоматизированная система предприятия и т. п.
5. Стрелки сверху (Control) отображают объекты, диктующие правила исполнения процесса, но непосредственно для исполнения процесса не необходимые. Это могут быть статьи КЗОТ и/или инструкция по технике безопасности для процесса изготовления детали рабочим, работающим на станке, или инструкция Банка России и/или тот же КЗОТ для процесса оформления платежа банковским работником.
6. Стрелки могут разветвляться и сливаться, тем самым образуя иерархию данных.
7. При декомпозиции процесса все стрелки, входящие или исходящие из него, должны быть перенесены на диаграмму нижнего уровня и использованы при ее построении. При этом запрещены всякие новые стрелки, выходящие за пределы новой диаграммы, кроме специальных, так называемых «туннельных» стрелок.

Все перечисленные соглашения в точности реализованы в продуктах, основанных на методологии IDEF0, и являются их неотъемлемой частью (кроме того, в этих продуктах могут быть реализованы и другие нотации — IDEF3, DFD и т. п.). Выбирая такой продукт, а в нем методологию IDEF0, бизнес-аналитик берет на себя обязательства выполнять строгие соглашения выбранной методологии. Взамен он получает всего две «вещи», но такие, важность которых трудно переоценить:

• проверенную десятилетиями в различных предметных областях методологию моделирования и анализа деятельности предприятия,
• автоматизированную систему, умеющую «читать» разработанные аналитиком модели.

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

Благодаря умению «читать» разработанные аналитиком схемы – средства моделирования, основанные на IDEF0, имея описанный по этому стандарту бизнес-процесс, за считанные секунды в качестве отчета выдадут:

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

Если же IDEF0-модель разработана в системе, не поддерживающей формализмы оговоренного методологией синтаксиса и потому не умеющей «читать» модели (например, модель просто «нарисована» в MS Word), то все подобные отчеты можно получить только «вручную», что для больших моделей является очень трудоемкой работой, при исполнении которой практически невозможно избежать ошибок. Кроме того, нет никаких гарантий, что разработанная модель будет внутренне непротиворечива и корректна, так как отсутствует контроль синтаксиса.

Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения так называемых «бизнес-моделей», содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Однако автор убежден, что эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг IDEF0. По мнению автора, некие синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную и понятную систему; этим диаграммам (что, наверное, главное) не дается никакой интерпретации, объясняющей, как их применять при моделировании. Действительно, что означает, что два процесса соединены стрелкой — просто последовательность их исполнения или, например, то, что второй процесс обрабатывает некоторые (какие?) результаты деятельности первого, а может быть, наоборот, для работы первого процесса необходима некая (какая?) информация, которую подготавливает второй? Точно так же непонятно, как интерпретировать связи «процесс-состояние», «состояние-состояние» и др.

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

Пример синтаксически корректной, но не поддающейся осмысленному объяснению Activity-диаграммы

По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию. Например, чтобы имитировать три вида характерных для IDEF0 входящих в процесс стрелок — input, mechanism, control, — можно каждую из них подкрашивать своим цветом, а для того, чтобы отличить входящие документы от исходящих, можно использовать пунктирные и сплошные стрелки. Другими словами, пользователь Rational Rose вынужден разрабатывать свои формализмы для получения методики построения моделей и анализа бизнес-процессов. При этом, возможно, придется не только разрабатывать свою методику, но и отклоняться от стандартов UML. Зачем это делать, если существует апробированная и признанная во всем мире IDEF0 (а также другие вполне подходящие стандарты, средства и языки, например IDEF3), а на преимуществах стандартного подхода я здесь просто не буду останавливаться.

Даже если удастся придумать, как реализовать в Rational Rose соглашения IDEF0, или разработать свою методологию анализа бизнес-процессов, не уступающую IDEF0 и органично реализуемую в Rational Rose, то система все равно не научится «читать» разработанные модели, так как это в ней не заложено изначально, а следовательно, обработка и анализ моделей будут целиком на плечах аналитика. Или же придется разрабатывать свои процедуры выдачи отчетов, которые будут ориентированы на отсутствующие в стандартном UML (но имеющиеся в IDEF0) синтаксические соглашения. Но и это еще не все, поскольку не будет решена задача поддержки и контроля синтаксиса для разработанной пользователем методологии, и, следовательно, не будет никакой гарантии корректности разработанной модели.

Из всего вышесказанного следует только один вывод: CASE-средства, реализованные на основе методологии IDEF0 и поддерживающие ее соглашения, уже только благодаря этому имеют неоспоримые и решающие преимущества перед Rational Rose. (Аналогичную оценку преимущества перед Rational Rose можно дать и системам, основанным на стандарте IDEF3, и ряду других.) Поэтому при необходимости проведения работ, где анализ бизнес-процессов играет важнейшую роль, выбор в качестве средства моделирования продуктов фирмы Rational Software, на взгляд автора, является серьезной ошибкой.

1. Дэвид А. Маркa, Клемент Макгоуэн. Методология структурного анализа и проектирования (SADT). http://acdwp.narod.ru/ruk1.htm, http://zareg.newmail.ru/prteoria.htm