Диссертация (1152223), страница 28
Текст из файла (страница 28)
Целью анализа в третьей главе станут теоретические основы моделирования бизнеспроцессов. Для достижения цели необходимо провести анализ существующих методологий моделирования, определить сущностно-содержательное представление модели бизнес-процесса,разработать онтологию моделирования бизнес-процессов верхнего уровня. Это позволит выявить важные свойства модели бизнес-процесса, сравнить выразительные способности различных языков и нотаций моделирования бизнес-процессов, разработать методы структуризациимодели бизнес-процесса, определить критерии нормального завершения бизнес-процесса.3.1Анализ существующих методологий создания исполняемой модели и системыуправления бизнес-процессами предприятийКак отмечают В.Г.
Чеботарёв и А.И. Громов, существует много определений термина«методология», что приводит к различиям в понимании этого понятия [104]. Возьмём за основуопределение, предложенное А.М. Новиковым и Д.А. Новиковым: «Методология — это учениеоб организации деятельности» [105]. Поскольку моделирование является одним из видов человеческой деятельности можно сформулировать определение: «методология моделирования естьучение об организации моделирования как вида продуктивной деятельности» [104]. Методология моделирования не должна быть привязана к одной конкретной нотации или языку, напротив, должна быть применима с разными языками и нотациями. Как отмечают А.М.
и Д.А. Новиковы, в технических науках широкое распространение получило упрощённое толкование понятия «методологии» — как общего подхода к решению задач того или иного класса [105]. Поиск в Internet по ключевым словам «методология моделирования бизнес-процессов» возвращаетмножество ссылок на методологии: ARIS, IDEF, DFD и пр. Очевидно, что в этих случаях речьидёт о правилах применении какой-то конкретной нотации, тем более что оригинальные названия соответствующих англоязычных документов содержат термины метод или техника, например, «Method ARIS» или «DFD Techniques».110Часто методологию моделирования подменяют нотацией, а это не одно и то же. Методология определяет способы моделирования, а нотация помогает зафиксировать результат.Напрашивается аналогия с музыкой, где музыкальная композиция и нотная грамота суть разныевещи. В качестве примера рассмотрим нотацию IDEF0, неразрывно связанную с методологиейSADT.
Будет ошибкой называть нотацию IDEF0 методологией или сказать, что SADT есть нотация. Модели IDEF0 принято называть функциональными, однако многие используют их дляописания процессов. Не может ли оказаться, что некоторые модели, которые мы используемдля описания бизнес-процессов в отрыве от методологии их создания, по сути, являются функциональными? Аналитики, которые при анализе процесса не опираются на соответствующуюметодологию, рискуют допустить ошибки моделирования. Отсутствие чётких и ясных методикмоделирования бизнес-процессов приводит к тому, что модель отражает субъективное видениебизнес-аналитика, а собственно процедура моделирования сродни ремеслу.
Одна из главныхзадач данного исследования — превратить моделирование в инженерную деятельность.Договоримся различать понятия метод, методика и методология. В рамках данной работытермин методология будет пониматься как система принципов, критериев, моделей, методов иприёмов, обеспечивающих выявление и выделение модели процесса, её анализ, создание визуальной многоуровневой исполняемой модели, проверку наличия в ней формальных ошибок ипроверку её соответствия требованиям пользователя.
Методология моделирования включаетследующие компоненты [105]:теоретические основы моделирования: концепции, онтология, системный анализ;логическую структуру моделирования: предмет, объект и субъект моделирования, сред-ства моделирования, методы моделирования, нотации моделирования, результаты моделирования и другие элементы логической структуры;временную структуру моделирования: фазы проекта моделирования, стадии проекта мо-делирования, этапы проекта моделирования, циклы процесса моделирования и другие элементывременной структуры. описание шагов, необходимых для получения заданного результата;характеристику моделирования: принципы, условия, нормы, особенности, рекомендациипо использованию как отдельно, так и в составе группы методик.Констатируем, в настоящее время отсутствует методология разработки исполняемой модели бизнес-процессов, что затрудняет создание процессно-ориентированных информационныхсистем на базе СУБП.
Методология моделирования подменяется нотацией, в результате модельотражает частное представление аналитика, опускает детали, важные для цели моделирования.Можно сделать вывод, что разработка методологии создания исполняемой модели бизнеспроцесса является важной и актуальной задачей.111Анализ существующих подходов к моделированию бизнес-процессовГромов А.И и Чеботарёв В.Г.
предлагают различать следующие подходы к моделированию бизнес-процессов [104]:Ориентированный на работы — главным элементом модели являются работы, преобразу-ющие или трансформирующие вход в выход: функции, операции, процессы. Соответствующиемодели получили название трансформационных или моделей потоков работ, к этому классу относятся модели в нотациях EPC, BPMN. Именно этот класс моделей станет объектом изученияв данной работе.Объектный — ориентированный на описание предметной области, выделение множестваотносительно независимых сущностей — объектов, описанию связей и коммуникаций междуними.
При этом статическая структура модели описывает объекты, а динамическая модель поведения — сообщения, которыми эти объекты обмениваются. Этот подход получил развитие вметодологии объектного программирования, к этому классу относятся модели на языке UML.Субъектно-ориентированный подход предлагает рассматривать любой бизнес-процесс спозиций взаимодействия, участвующих в нем субъектов.
При этом весь процесс разбивается надиалоги, описывающие попарное взаимодействие участников, которые обмениваются друг сдругом сообщениями и выполняют назначенные им функции [106]. Этот тип моделей находитприменение как для описания коммуникации между исполнителями внутри процесса, так и дляописания взаимодействия партнёров межпроцессного взаимодействия [68].Роле-ориентированный (Role Activity Diagram) — вариант трансформационной модели, вкоторой работы привязаны к группам пользователей, объединённых в роли.
Роль представляетсобой абстрактный элемент процесса — совокупность пользователей, выполняющий какуюлибо организационную функцию. Ролевая модель показывает степень «ответственности» запроцесс и его операции, а также взаимодействие ролей [107].Структурный метод проектирования КИС предполагает создание нескольких частныхструктурных моделей, каждая из которых описывает устройство отдельных аспектов реальности. Например, Э. Иордан, автор структурного метода, предлагает проводить моделированиепроцесса последовательно в нескольких нотациях, описывающих структуру данных, потоки работ и диаграмму состояния [108], аналогичная концепция описывается в методе структурногоанализа SADT [109].
Признавая правильность и плодотворность такого подхода, следует выделить два вопроса, без ответив на которые, нельзя определить степень применимости данногометода: 1) Насколько полно выбран набор диаграмм, с помощью которых предлагается описывать исследуемый прототип? 2) В какой степени структурная эквивалентность модели и прототипа может свидетельствовать об их функциональной эквивалентности?112Анализ существующих методологий разработки СУБПСуществующие методологии проектирования функционально ориентированных информационных систем не в полной мере применимы для разработки СУБП.
Такие системы автоматизируют набор действий, выполняемых для достижения запланированного результата. Приэтом, порядок исполнения работ не специфицируется, т.к. он контролируется исполнителем,который играет активную роль, а система играет пассивную. При проектировании функционально-ориентированной информационной системы критично выявить все функции исполнителей, однако не столь важно полностью выявить все варианты исполнения процесса, если какойлибо сценарий будет пропущен при проектировании, то исполнитель сможет исправить ситуацию в процессе работы.
Напротив, процессно-ориентированные системы играют активнуюнаправляющую роль, задают порядок и время выполнения операций, а человек грает подчинённую роль, его участие сведено к исполнению заданий, которые ему выдаёт система, поэтомукритически важно выявить и заложить в модель все возможные сценарии выполнения.Можно выделить две группы методологий разработки ИТ систем. Первая группа фокусирует внимание на номенклатуре моделей, с помощью которых создаётся описание будущей информационной системы, порядке их создания. В качестве примера укажем структурную технику анализа Йордана [110], [108] Он считает, что для описания системы необходимо использовать несколько взаимосвязанных моделей, каждая отражает определённые аспекты проектируемой системы, а вместе они образуют её полное и исчерпывающее описание.