1.3 Методологии моделирования
Существуют различные подходы к моделированию процессов, среди которых выделяют функциональный и объектно-ориентированный подходы (к последнему, в частности, относится методология ARIS). В функциональном подходе главным структурообразующим элементом является функция (действие), в объектно-ориентированном подходе – объект.
Сущность функционального подхода к моделированию бизнес-процессов сводится к построению схемы технологического процесса в виде последовательности операций, на входе и выходе которых отражаются объекты различной природы: материальные и информационные объекты, используемые ресурсы, организационные единицы.
Достоинство функционального подхода заключается в наглядности и понятности представления бизнес-процессов на различных уровнях абстракции, что особенно важно на стадии внедрения бизнес-процессов в подразделениях предприятия. Существенным недостатком функционального подхода является некоторая субъективность детализации операций и как следствие большая трудоемкость в адекватном построении бизнес-процессов. Пример описания бизнес-процесса на основе функционального подхода приведен на рис. 1.3.1.
Рисунок 1.3.1 Модель IDEF0
Объектно-ориентированный подход предполагает вначале выделение классов объектов, а далее определение тех действий, в которых участвуют объекты. При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются действия, и активные объекты (организационные единицы, конкретные исполнители, информационные подсистемы), которые осуществляют действия. Такой подход более объективно позволяет выделять операции над объектами, а заодно и решать задачи целесообразности существования самих объектов. Недостаток объектно-ориентированного подхода заключается в меньшей наглядности конкретных процессов для лиц, принимающих решения. Пример объектно-ориентированного моделирования бизнес-процесса приведен на рис. 1.3.2 (динамическая модель бизнес-процесса с применением технологии объектного моделирования) и 1.3.3 (бизнес-процесс заселения клиента в номер приведен в нотации языка UML – Unified Modeling Language – унифицированного языка моделирования).
В настоящее время для проведения моделирования бизнес- и информационных процессов имеется достаточно много методологий и соответствующих инструментальных средств, большинство из которых имеют узкую направленность применения. Так, методологии функционального моделирования (DFD – диаграммы потоков данных, SADT – методологии структурного проектирования процессов) ориентированы на отображение последовательности функций, в которых трудно вычленить конкретные альтернативы процессов и не видна схема взаимодействия объектов. ER-диаграммы (entity-relationship, «сущность-связь»), наоборот, отражают только обобщенную схему взаимодействия объектов без детализации последовательности выполнения функций. Методологии объектно-ориентированного подхода отражают объекты, функции и события, при которых объекты инициируют выполнение конкретных процессов; при этом теряется общая наглядность модели.
Наибольшую перспективу представляют комплексные методологии моделирования бизнес-процессов, например, ARIS Toolset, Natural Engineering Workbench.
Рисунок 1.3.2 Object Modeling Technique – OMT. Динамическая модель
Рисунок 1.3.3 UML-модель бизнес-процесса
1.3.1 CASE-средства
Решение вопросов по реорганизации деятельности предприятия имеет высокий уровень сложности, что заставляет обращаться к формализованным методам проектирования, а также средствам автоматизации выполнения проектов, т.е. к CASE-средствам (Computer Aided Software/System Engineering). Использование программного обеспечения для построения моделей позволяет избежать рутинной работы по перерисовыванию диаграмм в процессе отладки моделей. Кроме того, при создании моделей с помощью программного обеспечения используется стандартная нотация, легко создается контекстное описание моделей. Это обеспечивает взаимопонимание при работе в команде и проверку моделей экспертами.
Большинство CASE-средств основано на парадигме методология/метод/нотация/средство. Методология определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы и их последовательность, а также правила распределения и назначения методов. Метод – это систематическая процедура или техника генерации описаний компонент программного обеспечения (например, проектирование потоков и структур данных). Нотации предназначены для описания структуры системы, элементов данных, этапов обработки и включают графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки. Средства – инструментарий для поддержки и усиления методов. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме, они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов.
Использование CASE-средств открывает широкие возможности по структуризации, моделированию и оценке различных аспектов в процессе выполнения проектов по реорганизации деятельности. В настоящее на российском рынке появилось достаточно много программных инструментальных средств, с помощью которых можно строить функциональные, информационные, стоимостные и имитационные модели бизнес-процессов. Например, BPWin, ERWin, CASE-аналитик, ReThink, ABC FlowCharter, Oracle*Case, Visible Analyst Workbench, EasyCASE, Silverrun, Westmount I-CASE, PRO-IV, Design/IDEF, Easy ABC, Design/CPN, S-Designor, ARIS и т.д., с помощью которых можно решить отдельные задачи реорганизации деятельности.
Для решения многих задач совершенствования технологий работы необходимо иметь функциональную модель, включающую в себя декомпозицию функций до элементарных операций, информационное взаимодействие и управление процессом решения всех задач, а также необходимые ресурсы. Столь информативное представление модели возможно благодаря использованию CASE-средств создания функционально-информационных моделей (например, в нотации DFD-диаграмм, SADT/IDEF-технологии и т.д.).
Разработанные с использованием CASE-средств модели деятельности создают формальную основу для проведения различного рода оценок. Некоторые механизмы для оценки встроены в CASE-средства. Так, пакеты BPWin, Design/IDEF позволяют на основе применения ABC/ABM-методов провести стоимостную оценку технологий работы структурных подразделений или бизнес-процессов, выявить затратные центры и осуществить экспорт результатов из модели для последующего использования другими специализированными программными продуктами, например, MS Excel, EasyABC Plus и др.
CASE-средства позволяют также сопоставить функции, а значит, и связанные с ними информационные потоки, подразделениям, которые должны их выполнять. Для этого в SADT/IDEF0-методологии, например, предусмотрено понятие механизма. Для различных вариантов распределения функций и информационных потоков может быть оценена загрузка и связность подразделений. Количественные оценки, выполняемые с использованием CASE-средств, позволяют сравнивать варианты организационных структур, разрабатывать предложения по численности сотрудников в подразделениях, в том числе по определенным должностям.
В рамках заданной или сформированной организационной структуры появляется необходимость совершенствования документооборота. Данная задача с водится к анализу и уточнению распределения входной, выходной информации между структурными элементами и должностными лицами, ее детализация и конкретизация в документах. При этом определяется достаточность содержания и номенклатуры документов, исключается дублирование, устраняются «узкие» места документооборота. Для этого требуется наглядная и полная модель взаимосвязей входной и выходной информации в процессе выполнения функций. Основа для ее создания – разработанные функциональные (IDEF0) и информационные (IDEF1X) модели. Существующие CASE-средства позволяют интегрировать их, сопоставив каждому информационному потоку из первой модели конкретные атрибуты сущностей из второй модели. Для построения такой модели используются CASE-средства создания функционально-информационных и информационных моделей предметных областей (например, BPWin, ERWin, Design/IDEF).
Для подготовки исходных данных для автоматизации осуществляется дальнейшая детализация функциональных и информационных моделей. CASE-модели, доведенные до весьма глубокого уровня детализации, позволяют решить ряд вопросов: оценку целесообразности автоматизации тех или иных функций и выбор технических средств автоматизации. CASE-средства могут использоваться и для решения задач, возникающих в ходе текущей деятельности.
Современные CASE-средства помимо рисования моделей ориентируются на поддержание компьютерной информационной системы в течение всего жизненного цикла. Сюда включаются формулировка требований к системе, проектирование приложений и баз данных, генерация кода, тестирование, документирование, управление проектом внедрения и т.д.'
В настоящее время этот класс продуктов получил широкое развитие. Многие из них поддерживают связь с объектно-ориентированным программированием, структуру «клиент/сервер». Некоторые CASE-средства содержат аналитические инструменты, средства формирования отчетов, экранов, диаграмм.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с ограниченными возможностями, так и полномасштабные средства автоматизации компьютерной информационной системы. Обычно к CASE-средствам относят любое программное обеспечение, автоматизирующее определенную последовательность этапов жизненного цикла программного обеспечения. Такие системы предполагают наличие графического описания и документирования, интеграцию отдельных компонентов и организацию хранения моделей. / Интегрированные средства, поддерживающие полный жизненный цикл, включают следующие компоненты:
репозитарий, являющийся основой CASE-средства. Он предназначен для хранения версий проекта и его отдельных компонентов, синхронизации поступлений и контроля метаданных;
графические средства анализа и проектирования, обеспечивающие организацию декомпозиционных диаграмм;
средства разработки приложений, включая генераторы кодов;
средства конфигурации;
средства документирования;
средства тестирования;
средства управления проектом.
Таким образом, CASE-средства могут эффективно использоваться для решения широкого круга вопросов, связанных с совершенствованием деятельности организаций. Они позволяют создать единую понятийную базу предметной области, единое информационное пространство, обеспечивающие преемственность моделей различных этапов совершенствования деятельности и согласованность точек зрения.
1.3.2 Функциональные возможности продуктов ARIS, BPWin и ERWin
Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого.
Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPWin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В Model Mart так же предусмотрено администрирование базы данных.
ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией – так называемыми Соглашениями по моделированию. Разработка этих Соглашений само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%. В свою очередь, BPWin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.).
Для построения модели данных PLATINUM technology предлагает мощный и удобный инструмент – ERWin. ERWin имеет два уровня представления модели – логический и физический. Логический уровень – это абстрактный взгляд на данные, на нём данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. ERWin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога.
Считается, что для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPWin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной
1.3.3 Развитие управления бизнес-процессами на платформе XML
Процессный подход к организации управления сегодня является безальтернативным способом существенного улучшения основных показателей предприятия, повышения его конкурентоспособности и снижения издержек. Процессы, иерархические структуры, становятся предметом управления и совершенствования.
Управлять процессами – значит заставить их работать качественно, быстро, дешево. Самый эффективный процесс – самый качественный, а значит самый быстрый и самый дешевый!
Процессы мало грамотно описать, ими ещё необходимо грамотно управлять, т.е. надо знать, чем управлять в процессах, надо знать, какие знания нужны процессам, надо знать, как эти знания сохранять, развивать и создавать.
Эти задачи помогает решать класс систем – workflow. Термин workflow дословно обозначает поток работ.
Workflow-технологии начали свое развитие в начале 90-х годов и довольно быстро доказали свою эффективность, помогая компаниям автоматизировать ключевые процессы их деятельности.
Однако процессно-ориентированный подход не ограничивался только автоматизацией потоков работ. Автоматизируемые процессы должны удовлетворять постоянно изменяющимся потребностям бизнеса.
Этот момент и явился стимулом для соединения двух направлений – моделирования процессов с их автоматизацией, сформировав целостный подход к повышению эффективности деятельности, называемый Business Process Management (BPM). Русскоязычный перевод этого понятия — Управление бизнес-процессами (УБП) или Процессное управление.
При процессном подходе, работа компании представляется как цепочка взаимосвязанных шагов. Такими шагами могут быть действия сотрудника, работа автоматизированной системы. Эти шаги выполняются в соответствии с определенными правилами, существующими в компании. Логически законченная цепочка из таких шагов называется процессом.
Так как в идеологии workflow-систем заложена идея интеграции и подчинении всех автоматизируемых процессов компании задачам бизнеса, то довольно быстро производители и потребители workflow-систем пришли к необходимости выработки единых стандартов на workflow-системы.
На сегодняшний день основными организациями, устанавливающими стандарты в области workflow можно назвать Workflow Management Coalition (WfMC), Business Process Management Initiative (BMPI.ORG), Workflow And Reengineering International Association (WARIA).
BPMIю ORG – независимая организация, занимающаяся разработкой открытых спецификаций для управления e-бизнесом, а также процессами, которые охватывают многократные прикладные программы, корпоративные отделы, и деловых партнеров.
К открытым спецификациям разработанным BPMI.ORG относятся Business Process Modeling Language (BPML) и Business Process Query Language (BPQL), которые будут допускать стандарты управления е-business и вслед за ними планируется выпуск систем управления БП (BPMS). Так же и SQL когда-то допускали стандарты управление бизнес-данными, имея в распоряжении только cистемы управления ,азами данных (DBMS).
BPML – метаязык для моделирования БП, как? к примеру XML – метаязык моделирования бизнес-информации.
XML (Extensible Markup Language) – это язык разметки, описывающий целый класс объектов данных, называемых XML- документами. Этот язык используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. Т.е. сам по себе XML не содержит никаких тэгов, предназначенных для разметки, он просто определяет порядок их создания.
Процесс создания XML документа прост и требует лишь базовых знаний HTML и понимания тех задач, которые надо выполнить, используя XML в качестве языка разметки. Таким образом, у разработчиков появляется уникальная возможность определять собственные команды, позволяющие им наиболее эффективно определять данные, содержащиеся в документе. Автор документа создает его структуру, строит необходимые связи между элементами, используя те команды, которые удовлетворяют его требованиям, и добивается такого типа разметки, которое необходимо ему для выполнения операций просмотра, поиска, анализа документа.
Еще одним из очевидных достоинств XML является возможность использования его в качестве универсального языка запросов к хранилищам информации.
BPML представляет модель исполнения совместных и потоковых БП, основанный на понятии (концепции) ограниченности БП.
Структура языков такова, что сложный БП будет организован в формате, который очень хорошо обработан программной средой (или программистом). Этот БП намного труднее было бы понять бизнес-аналитикам и менеджерам, в обязанности которых входит просто разрабатывать и управлять БП.
BPML представляет бизнес-процессы как чередование потоков управления, потоков данных, и потоков событий c добавлением ортогональных возможностей для описания бизнес-правил, защитных функций, и контекстов потоков. BPML сам по себе не определяет никакой семантики прикладной программы типа специфических процессов или прикладной программы процессов в специфической области; он определяет абстрактную модель и правила написания для выражения универсальных процессов. Это позволяет использовать BPML для ряда целей, которые не ограничены только описанием БП предприятия, комплексом Web Services (WS) и многоплановым сотрудничеством.
Фундаментальная отличительная особенность BPMI-стандартов в том, что они разработаны на строгой математической основе. Поэтому программное обеспечение для исполнения БП может быть сгенерировано автоматически на основе BPML для немедленного выполнения. Язык моделирования БП (BPML) разработан BPMI.ORG, для целей стандартного описания БП на основе Pi-вычислений.
В отличие от предыдущих типов диаграмм БП, диаграмма БП BPMN была создана с ориентацией на языки исполнения БП и web-сервисы. В диаграмму были добавлены специальные обозначения (нотации), чтобы отображать события на основе сообщений и передачу сообщений между организациями.
Группа BPMI.ORG ставит своей целью разработку и продвижение инициатив в области управления БП (Business Process Management, BPM) путем создания стандартов в области проектирования БП, их оптимизации и автоматизации. Намерение BPMN состоит в том, чтобы стандартизировать нотацию моделирования БП в условиях наличия множества различных точек зрения и нотаций моделирования. При этом BPMN предоставит простое средство передачи информации о БП другим пользователям, конструкторам БП, клиентам и поставщикам.
BPMI разрабатывает, три стандарта, с целью облегчить использование BPM:
Язык моделирования БП (Business Process Modeling Language, BPML), как стандартный язык формального XML-описания БП.
Нотацию моделирования БП (Business Process Modeling Notation, BPMN), как стандарт для диаграммной визуализации БП.
Язык запросов БП (Business Process Query Language, BPQL).
BPML и BPQL лежат в основе управления БП, т.е. за ними планируется выпуск систем управления БП (BPMS). BPML способен к взаимодействию с языком выполнения БП для Web Services (BPEL4WS). BPML нужен для описания общих интерфейсов процесса, и разработан, чтобы поддерживать появляющуюся WS-защиту, WS-потоки и спецификации, WS-координацию для безопасного и надежного выполнения совместных БП внутри и между организациями.
Так же как и XML-документы обычно описываются на специфическом языке XML Schema, так и BPML описывается на этом же языке.
За последние годы очень много сделано в развитии Web Service, в области XML-ориентированных языков для BPM-систем. Языки типа BPEL4WS и BPML обеспечивают формальный механизм для BPM-систем, чтобы выделять и исполнять БП и взаимодействовать друг с другом. Ключевой элемент этих языков – это то, что они оптимизированы для управления BPM-систем. Кроме того, эти языки определяют поведение БП очень компактным и эффективным способом.
Спецификация BPMN обеспечивает графическую запись для выражения БП на примере Диаграммы БП (Business Process Diagram, BPD). Основная цель BPMN – обеспечить нотацию, которая будет легко понятной всем пользователям, от бизнес-аналитиков, которые создают начальные проекты БП, до технических разработчиков, ответственных за претворение в жизнь технологий. Таким образом, BPMN – стандартизированный мост, между анализом БП и его реализацией.
Другая цель, не менее важная, состоит в том, чтобы гарантировать, что XML-языки, разработанные для исполнения бизнес-процессов, типа BPEL4WS и BPML, можно визуализировать общей для всех нотацией.
В то время как основанные на XML языки моделирования БП, типа BPML и BPEL4WS, обеспечивают исполнение БП и способность к взаимодействию с BPM-ПО, BPMN обеспечивает легкость использования для людей, которые будут разрабатывать БП и ежедневно участвовать в управлении.
BPML обеспечивает правила написания на XML Schema для обмена описаниями через разнородные системы и инструменты средств моделирования.
Спецификация BPML предоставляет возможность отразить абстрактную модель, используя XML-синтаксис для моделирования как объектов, так и БП. BPML сам по себе не определяет никакого программного обеспечения. Он определяет абстрактную модель и правила отражения протекающих БП. Таким образом, BPML может использоваться для ряда целей, которые включают описание БП предприятия, описание Web-сервиса, а также многостороннего сотрудничества. Но эти области не ограничивают другое возможное использование BPML.
Консорциум предпринимателей, включая BEA, IBM и Microsoft, разрабатывает конкурирующий стандарт, известный как BPEL4WS или BPEL (Business Process Execution Language for Web Services ). Имея в наличие два стандарта (BPEL и BPML), вероятно, единственным компромиссом будет только то, что они оба пишутся (говорят) на одном и том же языке (XML). И есть большие ожидания в объединении этих стандартов в будущем. Языки выполнения БП организованы, выполняются и управляются в системе управления БП (BPMS, Business Process Management System).
Эти методы были успешны лишь отчасти, или сразу же терпели неудачу из-за недостатка стандартов и отсутствия законченного инструмента для контроля разработки и выполнения БП на протяжении всего их жизненного цикла. Управление процессом изменения не может быть разовым мероприятием; для этого требуется управление, контролирующее создание, архитектуру, разработку, и развертывание БП. Именно стандарты бизнес-моделирования и языков выполнения БП необходимы менеджерам для того, чтобы понять архитектуру, дизайн, и способы развертывания БП. Эта спецификация определяет нотацию и семантику Диаграммы БП (BPD) и представляет объединение лучших практических знаний всего делового сообщества, занимающегося бизнес-моделированием.
Любой инструмент, используемый для создания диаграмм BPMN, должен соответствовать формам и маркерам, определенным в этой спецификации. Семантика элементов BPMN. определяет, как графические элементы взаимодействуют друг с другом, включая условное взаимодействие, основанное на атрибутах, которые создают поведенческие разновидности элементов.
Взаимодействия БП на человеческом уровне, а не программном машинном уровне, можно добиться путем стандартизации нотации моделирования БП (BPMN). BPMN предоставляет менеджерам предприятий возможность воспринимать их внутренние бизнес-процессы в графической нотации и даёт организациям возможность сообщать друг другу эти процедуры стандартным образом. В настоящее время существует множество инструментальных средств и методологий моделирования БП. Учитывая тот факт, что человек будет уходить из одной компании в другую и то, что эти компании будут объединяться и дробиться, становится понятно, что бизнес-аналитики обязаны понимать множественные представления БП – возможно различные представления одного и того же БП, возникающие на протяжении его жизненного цикла – разработки, реализации, исполнения, контроля и анализа. Поэтому стандартная графическая нотация облегчит понимание производственных операций и бизнес транзакций в пределах и между организациями. Она также гарантирует, что предприниматели будут понимать себя и соучастников их бизнеса и дадут возможность организациям быстро адаптироваться к новым внутренним и B2B деловым обстоятельствам. Чтобы добиться этого, BPMN будет использовать традиционную нотацию составления блок-схемы для их удобочитаемости, предоставляя при этом возможность отображения их в виде исполнимых конструкций. BPMI использует опыт нотаций БП, которые предшествовали BPMN, для того, чтобы создать нотацию следующего поколения, которая объединит удобочитаемость, гибкость и расширяемость. BPMN ограничивается поддержкой только тех понятий моделирования, которые являются применимыми к БП.
Пример частного БП в нотации BPMN приведен на рис. 1.3.3.1. Здесь приведена последовательность функций от начала до конца процесса обслуживания пациента в регистратуре поликлиники.
Рисунок 1.3.3.1 Пример частного бизнес-процесса
Рисунок 1.3.3.2 Пример общего бизнес-процесса
Здесь прописан электронный процесс общения пациента с доктором с указанием выполняемых функций и событий, являющихся результатом их выполнения.
Рисунок 1.3.3.3. Пример бизнес-процесса сотрудничества
|
