Термин модель процесса используется в различных контекстах. Например, в моделировании бизнес-процессов модель процесса предприятия часто называют моделью бизнес-процесса .
Модели процессов — это процессы одной и той же природы, которые классифицируются вместе в модель. Таким образом, модель процесса — это описание процесса на уровне типа. Поскольку модель процесса находится на уровне типа, процесс является его инстанциацией. Одна и та же модель процесса используется многократно для разработки многих приложений и, таким образом, имеет много инстанциаций. Одним из возможных вариантов использования модели процесса является предписание того, как вещи должны/должны/могут быть выполнены в отличие от самого процесса, который на самом деле и происходит. Модель процесса — это примерное ожидание того, как будет выглядеть процесс. Каким должен быть процесс, будет определено во время фактической разработки системы. [2]
Целями модели процесса являются:
С теоретической точки зрения моделирование метапроцессов объясняет ключевые концепции, необходимые для описания того, что происходит в процессе разработки, что, когда это происходит и почему. С операционной точки зрения моделирование метапроцессов направлено на предоставление руководства для инженеров-методистов и разработчиков приложений. [1]
Деятельность по моделированию бизнес- процесса обычно предполагает необходимость изменения процессов или выявления проблем, которые необходимо исправить. Эта трансформация может потребовать или не потребовать участия ИТ, хотя это является распространенным фактором необходимости моделирования бизнес-процесса. Программы управления изменениями желательны для внедрения процессов на практике. С развитием технологий от крупных поставщиков платформ видение моделей бизнес-процессов (BPM), которые становятся полностью исполняемыми (и способны к круговой разработке), становится все ближе к реальности с каждым днем. Поддерживающие технологии включают унифицированный язык моделирования (UML), архитектуру на основе моделей и сервисно-ориентированную архитектуру .
Моделирование процессов затрагивает аспекты процессов архитектуры бизнеса предприятия , что приводит к всеобъемлющей архитектуре предприятия . Взаимосвязи бизнес-процессов в контексте остальных систем предприятия, данных, организационной структуры, стратегий и т. д. создают большие возможности для анализа и планирования изменений. Одним из реальных примеров являются корпоративные слияния и поглощения ; детальное понимание процессов в обеих компаниях позволяет руководству выявлять избыточности, что приводит к более плавному слиянию.
Моделирование процессов всегда было ключевым аспектом реинжиниринга бизнес-процессов и подходов к непрерывному совершенствованию, которые используются в Six Sigma .
Существует пять типов покрытия, в которых термин «модель процесса» определяется по-разному: [3]
Процессы могут быть разных видов. [2] Эти определения «соответствуют различным способам, которыми может быть смоделирован процесс».
Детализация относится к уровню детализации модели процесса и влияет на тип руководства, объяснения и трассировки, которые могут быть предоставлены. Грубая детализация ограничивает их довольно ограниченным уровнем детализации, тогда как мелкая детализация обеспечивает более подробные возможности. Характер необходимой детализации зависит от текущей ситуации. [2]
Менеджеры проектов, представители клиентов, генеральные, высшего или среднего звена требуют довольно грубого описания процесса, поскольку они хотят получить обзор времени, бюджета и планирования ресурсов для своих решений. Напротив, инженеры-программисты, пользователи, тестировщики, аналитики или архитекторы систем программного обеспечения предпочтут мелкозернистую модель процесса, где детали модели могут предоставить им инструкции и важные зависимости выполнения, такие как зависимости между людьми.
Хотя существуют обозначения для мелкозернистых моделей, большинство традиционных моделей процессов являются описаниями грубозернистых. Модели процессов должны, в идеале, обеспечивать широкий диапазон детализации (например, Process Weaver). [2] [7]
Было обнаружено, что хотя модели процессов были предписывающими, на практике могут происходить отклонения от предписаний. [6] Таким образом, фреймворки для принятия методов развивались таким образом, чтобы методы разработки систем соответствовали конкретным организационным ситуациям и тем самым повышали их полезность. Разработка таких фреймворков также называется ситуационной инженерией методов .
Подходы к построению методов можно организовать в диапазоне гибкости от «низкой» до «высокой». [8]
На «низком» конце этого спектра находятся жесткие методы, тогда как на «высоком» конце находятся модульные методы построения. Жесткие методы полностью предопределены и оставляют мало возможностей для адаптации их к текущей ситуации. С другой стороны, модульные методы могут быть изменены и дополнены для соответствия данной ситуации. Выбор жестких методов позволяет каждому проекту выбирать свой метод из панели жестких, предопределенных методов, тогда как выбор пути в рамках метода заключается в выборе подходящего пути для текущей ситуации. Наконец, выбор и настройка метода позволяют каждому проекту выбирать методы из разных подходов и настраивать их в соответствии с потребностями проекта». [9]
Поскольку в данной статье обсуждается качество моделей процессов, необходимо разработать качество методов моделирования как важную сущность качества моделей процессов. В большинстве существующих фреймворков, созданных для понимания качества, граница между качеством методов моделирования и качеством моделей в результате применения этих методов четко не проведена. В этом отчете основное внимание будет уделено как качеству методов моделирования процессов, так и качеству моделей процессов, чтобы четко разграничить их. Были разработаны различные фреймворки, чтобы помочь в понимании качества методов моделирования процессов, одним из примеров является фреймворк оценки моделирования на основе качества или известный как фреймворк Q-Me, который, как утверждается, предоставляет набор четко определенных свойств качества и процедур, чтобы сделать возможной объективную оценку этих свойств. [10] Этот фреймворк также имеет преимущества предоставления единообразного и формального описания элемента модели в пределах одного или разных типов моделей с использованием одного метода моделирования [10] Короче говоря, это может сделать оценку как качества продукта, так и качества процесса методов моделирования с учетом набора свойств, которые были определены ранее.
Свойства качества, которые относятся к методам моделирования бизнес-процессов, обсуждаемым в [10], следующие:
Для оценки качества фреймворка Q-ME он используется для иллюстрации качества методов бизнес-моделирования динамических основ организации (DEMO).
Утверждается, что оценка фреймворка Q-ME для методов моделирования DEMO выявила недостатки Q-ME. Одним из них является то, что он не включает количественную метрику для выражения качества метода бизнес-моделирования, что затрудняет сравнение качества различных методов в общем рейтинге.
Существует также систематический подход к измерению качества методов моделирования, известный как метрики сложности, предложенный Росси и др. (1996). Методы метамодели используются в качестве основы для вычисления этих метрик сложности. По сравнению с фреймворком качества, предложенным Крогсти , измерение качества больше фокусируется на техническом уровне, а не на уровне индивидуальной модели. [11]
Авторы (Cardoso, Mendling, Neuman и Reijers, 2006) использовали метрики сложности для измерения простоты и понятности дизайна. Это подтверждается более поздними исследованиями, проведенными Mendling et al., которые утверждали, что без использования метрик качества для помощи в оценке качественных свойств модели простой процесс может быть смоделирован сложным и неподходящим образом. Это, в свою очередь, может привести к снижению понятности, более высоким расходам на обслуживание и, возможно, неэффективному выполнению рассматриваемого процесса. [12]
Качество техники моделирования имеет важное значение для создания качественных моделей и способствует их правильности и полезности.
Самые ранние модели процессов отражали динамику процесса с помощью практического процесса, полученного путем реализации в терминах соответствующих концепций, доступных технологий, конкретных сред реализации, ограничений процесса и т. д. [13]
Было проведено огромное количество исследований по качеству моделей, но меньше внимания было уделено качеству моделей процессов. Вопросы качества моделей процессов не могут быть оценены исчерпывающе, однако на практике существуют четыре основных руководства и структуры для этого. Это: структуры качества сверху вниз, метрики снизу вверх, связанные с аспектами качества, эмпирические исследования, связанные с методами моделирования, и прагматические руководства. [14]
Хоммес цитирует Вана и др. (1994) [11] , что все основные характеристики качества моделей можно объединить в две группы, а именно: правильность и полезность модели; правильность варьируется от соответствия модели моделируемому явлению до ее соответствия синтаксическим правилам моделирования, а также она не зависит от цели, для которой используется модель.
В то время как полезность можно рассматривать как полезность модели для конкретной цели, для которой модель изначально создана. Оммес также проводит дальнейшее различие между внутренней правильностью (эмпирическое, синтаксическое и семантическое качество) и внешней правильностью (валидность).
Общей отправной точкой для определения качества концептуальной модели является рассмотрение лингвистических свойств языка моделирования, синтаксис и семантика которого применяются чаще всего.
Кроме того, более широкий подход должен основываться на семиотике, а не на лингвистике, как это сделал Крогсти, используя нисходящую структуру качества, известную как SEQUAL. [15] [16] Она определяет несколько аспектов качества, основанных на отношениях между моделью, экстернализацией знаний, доменом, языком моделирования и деятельностью по обучению, выполнению действий и моделированию.
Однако эта структура не предоставляет способов определения различных степеней качества, но широко использовалась для моделирования бизнес-процессов в проведенных эмпирических тестах [17]. Согласно предыдущему исследованию, проведенному Муди и др. [18] с использованием концептуальной структуры качества модели, предложенной Линдландом и др. (1994) для оценки качества модели процесса, были определены три уровня качества [19] :
В ходе исследования было отмечено, что структура качества оказалась простой в использовании и полезной для оценки качества моделей процессов, однако она имела ограничения в отношении надежности и трудности в выявлении дефектов. Эти ограничения привели к уточнению структуры в ходе последующих исследований, проведенных Крогсти . Эта структура называется структурой SEQUEL по Крогсти и др. 1995 (доработана далее Крогсти и Йоргенсеном, 2002), которая включала еще три аспекта качества.
Размеры концептуальной структуры качества [20] Домен моделирования — это набор всех утверждений, которые являются релевантными и правильными для описания проблемной области, Расширение языка — это набор всех утверждений, которые возможны с учетом грамматики и словаря используемых языков моделирования. Экстернализация модели — это концептуальное представление проблемной области.
Он определяется как набор утверждений о проблемной области, которые фактически сделаны. Интерпретация социального актора и интерпретация технического актора — это наборы утверждений, которые субъекты (как пользователи человеческой модели, так и инструменты, взаимодействующие с моделью) «думают», что содержит концептуальное представление проблемной области.
Наконец, Знания участников — это набор утверждений, которые, по мнению людей, участвующих в процессе моделирования, должны быть сделаны для представления проблемной области. Эти качественные измерения были позже разделены на две группы, которые имеют дело с физическими и социальными аспектами модели.
В более поздней работе Крогсти и др. [15] заявили, что хотя расширение фреймворка SEQUAL устранило некоторые ограничения исходного фреймворка, другие ограничения все же остались. В частности, фреймворк слишком статичен в своем взгляде на семантическое качество, в основном рассматривая модели, а не моделирующие действия, и сравнивая эти модели со статической областью, а не рассматривая модель как посредника для изменения области.
Кроме того, определение прагматического качества в рамках данной концепции довольно узкое и фокусируется на понимании, в соответствии с семиотикой Морриса, в то время как новейшие исследования в области лингвистики и семиотики фокусируются не только на понимании, но и на том, как модель используется и влияет на ее интерпретаторов.
Необходимость более динамичного взгляда на семиотический фреймворк качества особенно очевидна при рассмотрении моделей процессов, которые сами по себе часто предписывают или даже предписывают действия в проблемной области, поэтому изменение модели может также напрямую изменить проблемную область. В этой статье обсуждается фреймворк качества в отношении активных моделей процессов и предлагается пересмотренный фреймворк на его основе.
Дальнейшая работа Крогсти и др. (2006) направлена на пересмотр структуры SEQUAL с целью сделать ее более подходящей для моделей активных процессов путем переопределения физического качества с более узкой интерпретацией, чем в предыдущих исследованиях. [15]
Другая используемая структура — Руководящие принципы моделирования (GoM) [21], основанные на общих принципах бухгалтерского учета, включают шесть принципов: Корректность, Ясность касается понятности и явности (описание системы) систем моделей. Понятность относится к графическому расположению информационных объектов и, следовательно, поддерживает способность модели пониматься. Релевантность относится к модели и представляемой ситуации. Сопоставимость подразумевает возможность сравнивать модели, то есть семантическое сравнение между двумя моделями, Экономическая эффективность; произведенная стоимость процесса проектирования должна, по крайней мере, покрываться предлагаемым использованием сокращения расходов и увеличения доходов.
Поскольку целью организаций в большинстве случаев является максимизация прибыли, принцип определяет границу для процесса моделирования. Последний принцип — систематическое проектирование — определяет, что должно быть принятое различие между различными взглядами в моделировании. Корректность, релевантность и экономическая эффективность являются предпосылками качества моделей и должны быть выполнены, в то время как остальные руководящие принципы являются необязательными, но необходимыми.
Два фреймворка SEQUAL и GOM имеют ограничение использования, заключающееся в том, что их не могут использовать люди, некомпетентные в моделировании. Они предоставляют основные метрики качества, но не так легко применимы неспециалистами.
Использование восходящих метрик, связанных с качественными аспектами моделей процессов, является попыткой сократить разрыв в использовании двух других фреймворков неспециалистами в моделировании, однако оно в основном носит теоретический характер, и никаких эмпирических тестов в поддержку его использования не проводилось.
Большинство проведенных экспериментов касаются взаимосвязи между метриками и аспектами качества, и эти работы были выполнены по отдельности разными авторами: Канфора и др. изучают связь в основном между количественными метриками (например, числом задач или разделений и удобством обслуживания моделей процессов программного обеспечения); [22] Кардосо подтверждает корреляцию между сложностью потока управления и воспринимаемой сложностью; а Мендлинг и др. используют метрики для прогнозирования ошибок потока управления, таких как тупики в моделях процессов. [12] [23]
Результаты показывают, что увеличение размера модели, по-видимому, снижает ее качество и понятность. Дальнейшая работа Мендлинга и др. исследует связь между метриками и пониманием [24] и [25]. Хотя некоторые метрики подтверждают свое влияние, также личные факторы разработчика моделей, такие как компетентность, оказываются важными для понимания моделей.
Несколько проведенных эмпирических исследований все еще не дают четких указаний или способов оценки качества моделей процессов, но необходимо иметь четкий набор указаний, чтобы направлять разработчиков моделей в этой задаче. Прагматические указания были предложены различными практиками, хотя трудно дать исчерпывающий отчет о таких указаниях из практики.
Большинство руководств нелегко применить на практике, но правило «маркировать действия глаголом–существительным» было предложено другими практиками ранее и проанализировано эмпирически. Согласно исследованию. [26] ценность моделей процессов зависит не только от выбора графических конструкций, но и от их аннотации текстовыми метками, которые необходимо проанализировать. Было обнаружено, что это приводит к лучшим моделям с точки зрения понимания, чем альтернативные стили маркировки.
Из более ранних исследований и способов оценки качества модели процесса было видно, что размер модели процесса, ее структура, опыт разработчика и модульность влияют на ее общую понятность. [24] [27] На их основе был представлен набор рекомендаций [28] 7 рекомендаций по моделированию процессов (7PMG). В этой рекомендации используется стиль глагол-объект, а также рекомендации по количеству элементов в модели, применению структурированного моделирования и декомпозиции модели процесса. Рекомендации следующие:
7PMG все еще имеет ограничения в своем использовании: Проблема валидности 7PMG не относится к содержанию модели процесса, а только к тому, как это содержание организовано и представлено. Он предлагает способы организации различных структур модели процесса, при этом содержание остается нетронутым, но прагматический вопрос о том, что должно быть включено в модель, по-прежнему остается без внимания. Второе ограничение относится к руководству по приоритетам: полученный рейтинг имеет небольшую эмпирическую основу, поскольку он опирается только на участие 21 разработчика моделей процессов.
С одной стороны, это можно рассматривать как необходимость более широкого привлечения опыта разработчиков моделей процессов, но это также поднимает вопрос: какие альтернативные подходы могут быть доступны для выработки рекомендаций по расстановке приоритетов? [28]
