Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Бизнес-моделирование

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

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

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

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

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

Основными компонентами любой технологии, как известно, являются следующие:

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

В [16] предлагается такая последовательность действий по описанию и моделированию бизнес-процессов автоматизируемой предметной области:

  • 1) составляется описание существующих на предприятии процессов, выполняется построение модели процессов «Как есть» (А8 18);
  • 2) на основе определенных критериев выявляются проблемные процессы и (или) действия, или, иначе, проблемы;
  • 3) намечаются пути решения выявленных проблем, отдельно выделяются те, которые могут быть решены посредством автоматизации;
  • 4) строятся модели процессов «Как будет» (А8 ТО ВЕ), отмечаются те процессы, которые должны быть автоматизированы.

Описание существующих бизнес-процессов должно удовлетворять следующим требованиям:

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

Результатами деятельности по описанию бизнес-процессов должны являться модели бизнес-процессов автоматизируемой предметной области.

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

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

Можно утверждать, что существует некоторая достаточно общая концептуальная схема, в которую можно уложить практически любой бизнес-процесс. Наглядным примером такой схемы является следующая: «Инициация (возникновение) - развитие (становление) - существование (стадия жизни) - исчезновение (гибель)». Если говорить о процессе управления, то для него общераспространенной является схема «Планировать - делать - контролировать (проверять) - действовать», положенная в основу стандарта ГОСТ Р ИСО 9001-2001. Стандарт ИСО 9000, как и вся серия ИСО 9000, - международная разработка, ко-

торой мы обязаны Международной организации по стандартизации (ISO). Положения стандарта нашли широкое применение в России, были официально переведены на русский язык и включены в национальный стандарт с названием ГОСТ Р ИСО 9000 [8].

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

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

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

Диаграммы деятельности (Activity Diagram) унифицированного языка моделирования UML как раз и позволяют отобразить не только сам процесс, но и каркас, в который его можно уложить, позволяя создать так называемые контейнеры для составляющих процесс действий. Кроме того, действия, составляющие анализируемый процесс, могут быть классифицированы на диаграмме деятельности в соответствии с другими критериями, набор которых может зависеть как от специфики анализируемой предметной области, так и целей, преследуемых аналитиком. К наиболее общим критериям тем не менее можно отнести следующие:

  • • диапазон себестоимости/затрат на выполнение;
  • • частота выполнения/периодичность;
  • • диапазон эффективности (низкая, средняя, высокая);
  • • исполнители (задействованные подразделения, организации; пользователи, информационная система/системы).

Возможны и многие другие критерии.

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

Таблица 4.2. Возможности элементов диаграмм деятельности по представлению бизнес-процессов

Компонент описания бизнес-процесса

Элемент диаграммы деятельности (Activity

Diagram)

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

Диаграмма деятельности, основными элементами которой являются элементы Action (действие), Activity Edge (связи между элементами Action, изображающие либо передаваемые объекты либо потоки управления), Partition (отделения)

Модель бизнес-процесса (графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность)

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

Владелец бизнес-процесса (должностное лицо, которое управляет выполнением бизнес-процесса и несет ответственность за его результаты и эффективность)

Может быть изображен при помощи элемента Partition либо указан в виде текстового описания

Потребитель бизнес-процесса (тот, кто использует или потребляет результаты деятельности)

Может быть изображен при помощи элемента Partition

Дополнительные атрибуты бизнес-процесса (например, используемые ресурсы, исполняющие механизмы

И т.д.)

Могут быть изображены при помощи элементов Partition либо указаны при помощи элемента Note, прикрепляемого к необходимому элементу диаграммы деятельности

Классификация действий, составляющих бизнес-процесс, в соответствии с заданными критериями

Может быть выполнена при помощи элементов Partition

Идентификация проблемных действий

Выделение соответствующих элементов Action цветом, классификация с использованием элементов Partition

Назначение исполнителей отдельных действий в рамках бизнес-процесса

Может быть выполнено при помощи элементов Partition

Возможность задать каркас выполнения процесса

Может быть выполнено при помощи элементов Partition и StructuredActivity

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

IBM Rational Software Architect (RSA) является частью IBM Software Development Platform - набора инструментов, поддерживающих жизненный цикл разработки программных систем. RSA предназначен для построения моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Этот инструмент предоставляет возможность архитекторам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам - выполнять разработку J2EE, XML, веб-сервисов и т.д. Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемое™.

Хороший пример использования RSA для целей моделирования бизнеса приведен в [16]. Однако, если возможностей RSA, как правило, достаточно для построения моделей типа AS IS, то для построения моделей типа AS ТО BE часто их недостаточно. Дело в том, что средства RSA позволяют построить только статическую модель существующей на предприятии схемы бизнес-процессов и не позволяют промоделировать производственный (или иной) процесс в динамике. Это не позволяет получить количественные характеристики (показатели) отдельных бизнес-процессов и всего производственного цикла, а также выявить узкие места как в организации отдельных бизнес-процессов, так и в целом во всем производственном цикле.

IBM предлагает другой инструмент - WebSphere® Business Modeler (далее - Modeler), который считается лучшим в отрасли инструментом для моделирования и имитации бизнес-процессов [8]. С помощью Modeler бизнес-аналитики и другие пользователи (даже далекие от про-грамммирования) могут создавать бизнес-модели для документирования своих процессов, а затем осуществлять их имитационное моделирование, чтобы понять поведение этих процессов в динамике. Пользователи могут генерировать отчеты на основе модели процесса и по результатам имитационного моделирования.

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

Имеется возможность экспортирования разработанных моделей в такие среды, как WebSphere Integration Developer (Integration Developer), WebSphere Process Server (Process Server) и IBM FileNet P8 и хранения их в таких системах, как Rational® ClearCase и Rational Asset Repository. Модели могут быть опубликованы с помощью компонента WebSphere Business Modeler Publishing Server (Publishing Server), что позволяет авторизованным пользователям просматривать эти модели с помощью веб-браузера. Эти модели могут также быть связаны с требованиями в продукте Rational RequisitePro и повторно использованы в продукте Rational Software Architect. В версии Modeler 6.2 в дополнение к перечисленным возможностям реализован ряд важных усовершенствований [21].

В частности, реализована новая возможность, позволяющая бизнес-пользователям развертывать свои проекты для моделирования и мониторинга бизнес-процессов непосредственно на продуктах Process Server и WebSphere Business Monitor (Monitor). После того как проекты развернуты, автоматически создается новое бизнес-пространство под названием test space (пространство тестирования), в состав которого входят элементы (виджеты) для исполнения, управления и мониторинга процессов. Помимо прочего, эта новая функциональность под названием design to deploy (от проектирования до развертывания) поддерживает некоторые сценарии для рабочих процессов персонала.

Пользователи продукта Integration Developer могут вносить свой вклад в отладку проектов design to deploy. Этот сценарий под названием time to value сокращает число итераций между бизнесом и ИТ, благодаря чему ускоряется проведение процесса. ИТ-специалисты по-прежнему должны участвовать в процессе, однако объем возлагаемой на них обязательной работы может быть уменьшен, в результате чего увеличиваются возможности бизнес-пользователей и сокращается время до получения экономического эффекта.

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

 
<<   СОДЕРЖАНИЕ   >>