プロセスモデリング

プロセス モデルという用語は、さまざまなコンテキストで使用されます。たとえば、ビジネス プロセス モデリングでは、エンタープライズ プロセス モデルは、ビジネス プロセス モデルと呼ばれることがよくあります。

プロセス モデルは、同じ性質を持つプロセスで、モデルにまとめられます。したがって、プロセス モデルは、タイプ レベルでのプロセスの説明です。プロセス モデルはタイプ レベルにあるため、プロセスはそのインスタンス化です。同じプロセス モデルが多くのアプリケーションの開発に繰り返し使用されるため、多くのインスタンス化があります。プロセス モデルの 1 つの使用法は、実際に行われるプロセス自体とは対照的に、物事がどのように行われるべきか、どのように行われるべきか、どのように行われる可能性があるかを規定することです。プロセス モデルは、プロセスがどのようになるかを大まかに予測したものです。プロセスがどのようなものであるかは、実際のシステム開発中に決定されます。^[2]

プロセス モデルの目標は次のとおりです。

• 説明的
  • プロセス中に実際に何が起こっているかを追跡する
  • プロセスの実行方法を観察し、より効果的または効率的に実行するために必要な改善点を決定する外部観察者の視点を取り入れます。
• 規範的
  • 望ましいプロセスと、そのプロセスを実行する方法を定義します。
  • ルール、ガイドライン、および行動パターンを確立し、これに従えば望ましいプロセス パフォーマンスが実現されるようにします。ルール、ガイドライン、および行動パターンは、厳格な強制から柔軟なガイダンスまでさまざまです。
• 説明的
  • プロセスの根拠について説明します。
  • 合理的な議論に基づいて、いくつかの可能な行動方針を検討し、評価します。
  • プロセスとモデルが満たす必要のある要件の間に明示的なリンクを確立します。
  • レポート作成のためにデータを抽出できるポイントを事前に定義します。

理論的な観点から見ると、メタプロセスモデリングは、開発プロセスで何が、何について、いつ、なぜ起こるのかを説明するために必要な主要な概念を説明します。運用の観点から見ると、メタプロセスモデリングは、メソッドエンジニアとアプリケーション開発者にガイダンスを提供することを目的としています。^[1]

ビジネス プロセスをモデリングする作業は、通常、プロセスの変更や修正すべき問題の特定が必要になります。この変革には IT 部門の関与が必要な場合とそうでない場合がありますが、IT 部門の関与はビジネス プロセスをモデリングする必要性を生み出す一般的な要因です。プロセスを実践するには、変更管理プログラムが必要です。大手プラットフォーム ベンダーのテクノロジの進歩により、ビジネス プロセス モデル (BPM) が完全に実行可能 (およびラウンドトリップ エンジニアリングが可能) になるというビジョンが日々現実に近づいています。これをサポートするテクノロジには、統一モデリング言語(UML)、モデル駆動型アーキテクチャ、サービス指向アーキテクチャなどがあります。

プロセス モデリングは、エンタープライズビジネス アーキテクチャのプロセスの側面に対処し、すべてを網羅するエンタープライズアーキテクチャを実現します。エンタープライズ システム、データ、組織構造、戦略などの他の部分との関連でビジネス プロセスの関係を把握することで、変更の分析と計画の能力が向上します。実際の例としては、企業の合併と買収が挙げられます。両社のプロセスを詳細に理解することで、経営陣は重複部分を特定し、合併をスムーズに進めることができます。

プロセス モデリングは、常にビジネス プロセス リエンジニアリングと、シックス シグマに見られる継続的改善アプローチの重要な側面です。

プロセスモデルという用語が異なる定義で定義されているカバレッジには5つのタイプがあります。^[3]

• アクティビティ指向：製品定義という特定の目的のために実行される一連の関連するアクティビティ。目標を達成することを目的とした、部分的に順序付けられた一連のステップ。^[4]
• 製品指向：望ましい製品に到達するために繊細な製品変換を引き起こす一連の活動。^[5]
• 意思決定指向: 製品定義という特定の目的のために実行される一連の関連する意思決定。
• コンテキスト指向: コンテキスト内で行われた決定の影響下で連続的な製品変換を引き起こすコンテキストのシーケンス。
• 戦略指向：マルチアプローチプロセスを表すモデルを構築し、意図と戦略の概念に基づいて製品を詳細化するためのさまざまな方法を計画できるようにします。^[6]

プロセスにはさまざまな種類があります。^[2]これらの定義は「プロセスをモデル化できるさまざまな方法に対応しています」。

• 戦略プロセス
  • 物事を行うための別の方法を調査し、最終的にそれを実行するための計画を立てる
  • 多くの場合、創造的であり、人間の協力を必要とするため、代替案の生成と代替案からの選択は非常に重要な活動である。
• 戦術的プロセス
  • 計画の達成を助ける
  • 達成計画の策定よりも、実際の計画達成のために採用される戦術に関心がある
• 実装プロセス
  • 最も低レベルのプロセスである
  • 計画の実施内容と方法の詳細に直接関係している

粒度はプロセスモデルの詳細レベルを指し、提供できるガイダンス、説明、トレースの種類に影響します。粗い粒度では、これらがかなり限られたレベルの詳細に制限されますが、細かい粒度では、より詳細な機能が提供されます。必要な粒度の性質は、手元の状況によって異なります。^[2]

プロジェクト マネージャー、顧客担当者、一般管理職、トップレベル管理職、または中間管理職は、意思決定に必要な時間、予算、リソース計画の概要を把握したいため、粒度の粗いプロセス記述を必要とします。対照的に、ソフトウェア エンジニア、ユーザー、テスター、アナリスト、またはソフトウェア システム アーキテクトは、モデルの詳細から指示や、人同士の依存関係などの重要な実行依存関係が得られる、粒度の細かいプロセス モデルを好みます。

細粒度モデルの表記法は存在するが、従来のプロセスモデルのほとんどは粗粒度の記述である。プロセスモデルは、理想的には、広範囲の粒度を提供する必要がある（例：Process Weaver）。^{[2] [7]}

プロセスモデルは規範的であるが、実際には規範からの逸脱が起こる可能性があることが判明した。^{[6]そのため、システム開発方法が特定の組織状況に適合し、それによってその有用性が向上するように、方法を採用するためのフレームワークが進化した。このようなフレームワークの開発は、状況的}方法論エンジニアリングとも呼ばれる。

方法論構築アプローチは、「低」から「高」までの柔軟性スペクトルで整理することができる。^[8]

このスペクトルの「低い」端には固定された方法があり、「高い」端にはモジュール方式の構築があります。固定された方法は完全に事前に定義されており、手元の状況に合わせて調整する余地はほとんどありません。一方、モジュール方式は、特定の状況に合わせて変更および拡張できます。固定された方法を選択すると、各プロジェクトは固定された事前定義された方法のパネルから方法を選択できますが、方法内のパスを選択するには、手元の状況に適したパスを選択します。最後に、方法を選択して調整すると、各プロジェクトはさまざまなアプローチから方法を選択し、プロジェクトのニーズに合わせて調整できます。」^[9]

本稿ではプロセス モデルの品質について論じているため、プロセス モデルの品質における重要な本質としてモデリング手法の品質について詳しく説明する必要があります。品質を理解するために作成された既存のフレームワークのほとんどでは、モデリング手法の品質と、それらの手法を適用した結果としてのモデルの品質との線引きが明確にされていません。本稿では、プロセス モデリング手法の品質とプロセス モデルの品質の両方に焦点を当て、この 2 つを明確に区別します。プロセス モデリング手法の品質を理解するために、さまざまなフレームワークが開発されました。1 つの例は、品質ベースのモデリング評価フレームワーク、または Q-Me フレームワークです。これは、明確に定義された一連の品質プロパティと手順を提供し、このプロパティの客観的な評価を可能にすると主張しています。^[10] このフレームワークには、1 つのモデリング手法を使用して、1 つまたは複数のモデル タイプ内のモデル要素の統一された正式な記述を提供するという利点もあります。 ^[10] つまり、これにより、以前に定義された一連のプロパティに関して、モデリング手法の製品品質とプロセス品質の両方を評価できます。

^{[10]で議論されている}ビジネスプロセスモデリング技術に関連する品質特性は以下のとおりです。

• 表現力: 特定のモデリング手法が、あらゆる数および種類のアプリケーション ドメインのモデルを表すことができる程度。
• 任意性: 同じドメインをモデル化するときに持つ自由度
• 適合性: 特定のモデリング手法が特定の種類のアプリケーション ドメインに合わせて特別に調整されている度合い。
• 理解可能性: 参加者が作業方法やモデリング方法を理解する容易さ。
• 一貫性: モデリング方法の個々のサブモデルが全体を構成する度合い。
• 完全性。アプリケーション ドメインのすべての必要な概念がモデリングの方法で表現される度合い。
• 効率: モデリング プロセスが時間や人員などのリソースを使用する度合い。
• 有効性: モデリング プロセスが目標を達成する度合い。

Q-ME フレームワークの品質を評価します。これは、組織の動的エッセンシャル モデリング (DEMO) ビジネス モデリング手法の品質を示すために使用されます。

DEMO モデリング手法に対する Q-ME フレームワークの評価により、Q-ME の欠点が明らかになったと述べられています。その 1 つは、ビジネス モデリング手法の品質を表す定量化可能なメトリックが含まれていないため、全体的な評価でさまざまな手法の品質を比較することが難しいことです。

また、Rossiら(1996)が提案した複雑性メトリクスとして知られるモデリング技術の品質測定のための体系的なアプローチもあります。メタモデルの技術は、これらの複雑性メトリクスの計算の基礎として使用されます。Krogstieが提案した品質フレームワークと比較すると、品質測定は個々のモデルレベルではなく技術レベルに重点を置いています。^[11]

著者ら (Cardoso、Mendling、Neuman、Reijers、2006) は、複雑性の指標を使用して、設計の単純さと理解しやすさを測定しました。これは、モデルの品質特性を疑問視するのに役立つ品質指標を使用しないと、単純なプロセスが複雑で不適切な方法でモデル化される可能性があると主張したMendling らによるその後の研究によって裏付けられています。これは、理解しやすさの低下、メンテナンス コストの増加、および問題のプロセスの非効率的な実行につながる可能性があります。^[12]

モデリング技術の品質は、高品質のモデルを作成し、モデルの正確性と有用性に貢献する上で重要です。

初期のプロセスモデルは、関連する概念、利用可能な技術、特定の実装環境、プロセスの制約などの観点から、インスタンス化によって得られた実用的なプロセスでプロセスのダイナミクスを反映していました。^[13]

モデルの品質に関する研究は膨大に行われてきましたが、プロセスモデルの品質にはあまり焦点が当てられていません。プロセスモデルの品質の問題を徹底的に評価することはできませんが、実際には4つの主要なガイドラインとフレームワークがあります。それは、トップダウンの品質フレームワーク、品質の側面に関連するボトムアップのメトリクス、モデリング技術に関連する実証的調査、および実用的なガイドラインです。^[14]

HommesはWangら(1994) ^[11]の言葉を引用し、モデルの品質に関する主な特性はすべて、モデルの正確性と有用性の2つのグループに分類でき、正確性は、モデル化される現象に対するモデルの対応から、モデリングの統語規則に対するモデルの対応までの範囲であり、モデルが使用される目的とは無関係であると述べています。

一方、有用性は、モデルがそもそも構築された特定の目的に対してモデルが役立つこととして見ることができます。また、オムズは、内部の正確性（経験的、統語的、意味的品質）と外部の正確性（妥当性）をさらに区別しています。

概念モデルの品質を定義するための一般的な出発点は、構文とセマンティクスが最も頻繁に適用されるモデリング言語の言語特性を確認することです。

また、より広範なアプローチは、KrogstieがSEQUALとして知られるトップダウンの品質フレームワークを使用して行ったように、言語ではなく記号論に基づいています。^{[15] [16]}これは、モデル、知識の外部化、ドメイン、モデリング言語、および学習、行動、モデリングのアクティビティ間の関係に基づいて、いくつかの品質側面を定義します。

ただし、このフレームワークはさまざまな品質レベルを決定する方法を提供していませんが、実証的なテストでビジネスプロセスモデリングに広く使用されています^{[17] Moody}ら による以前の研究^{[18]によると}、Lindlandら(1994)がプロセスモデルの品質を評価するために提案した概念モデル品質フレームワークを使用して、3つの品質レベル^[19]が特定されました。

• 構文品質: モデルが使用されているモデリング言語の文法規則にどの程度準拠しているかを評価します。
• 意味品質: モデルがユーザーの要件を正確に表現しているかどうか
• 実用的な品質: モデルがモデリング プロセスのすべての関係者によって十分に理解されるかどうか。つまり、モデルは、解釈者がニーズを満たすためにそれを利用できるものでなければなりません。

研究から、品質フレームワークは使いやすく、プロセス モデルの品質評価に有用であることがわかりましたが、信頼性に関する制限があり、欠陥を特定するのが困難でした。これらの制限により、Krogstieによるその後の研究を通じてフレームワークが改良されました。このフレームワークは、Krogstieら (1995)によって SEQUEL フレームワークと呼ばれ、さらに 3 つの品質側面が追加されました (Krogstie と Jørgensen、2002 によってさらに改良されました)。

• 物理的品質: 外部化されたモデルが永続的であり、視聴者が理解できる状態にあるかどうか。
• 経験的品質: モデルが特定の言語に関して確立された規則に従ってモデル化されているかどうか。
• 社会的品質: これは、モデリング領域における利害関係者間の合意に関するものです。

概念品質の次元フレームワーク^[20] モデリングドメインは、問題領域を記述するために適切かつ正しいすべてのステートメントの集合であり、言語拡張は、使用されるモデリング言語の文法と語彙を与えられた場合に可能なすべてのステートメントの集合である。モデルの外部化は、問題領域の概念的表現である。

これは、問題領域について実際に作成された一連のステートメントとして定義されます。社会的アクターの解釈と技術的アクターの解釈は、それぞれ、人間のモデル ユーザーとモデルと対話するツールの両方のアクターが、問題領域の概念的表現に含まれると「考える」一連のステートメントです。

最後に、参加者の知識とは、モデリング プロセスに関与する人間のアクターが、問題領域を表すために作成する必要があると考える一連のステートメントです。これらの品質ディメンションは、後にモデルの物理的側面と社会的側面を扱う 2 つのグループに分割されました。

その後の研究で、Krogstieら^[15]は、SEQUALフレームワークの拡張によって初期のフレームワークの限界の一部が修正されたが、他の限界は残っていると述べています。特に、このフレームワークは意味品質に関する見方が静的すぎます。主にモデルを考慮し、モデリング活動を考慮しておらず、モデルをドメイン変更の促進因子として見るのではなく、これらのモデルを静的なドメインと比較しています。

また、このフレームワークの語用論的品質の定義は非常に狭く、モリスの記号論に沿って理解に焦点を当てていますが、言語学と記号論における最近の研究では、単なる理解を超えて、モデルがどのように使用され、その解釈者にどのように影響するかに焦点が当てられています。

記号論的品質フレームワークにおけるより動的な視点の必要性は、プロセス モデルを考慮するときに特に顕著です。プロセス モデルは、それ自体が問題領域でのアクションを規定したり、実行したりすることが多く、そのため、モデルの変更によって問題領域も直接変更される可能性があります。この論文では、アクティブ プロセス モデルとの関係で品質フレームワークについて説明し、これに基づいて改訂されたフレームワークを提案します。

Krogstieら（2006）によるさらなる研究では、物理的品質を以前の研究よりも狭い解釈で再定義することにより、SEQUALフレームワークをアクティブプロセスモデルに適したものに改訂しました。^[15]

使用されている他のフレームワークは、一般会計原則に基づくモデリングのガイドライン（GoM）^[21]で、6つの原則が含まれています。正確性、明瞭性は、モデルシステムの理解可能性と明示性（システムの説明）を扱います。理解可能性は、情報オブジェクトのグラフィカルな配置に関連し、したがって、モデルの理解能力をサポートします。関連性は、モデルと提示される状況に関連します。比較可能性には、2つのモデル間の意味的な比較であるモデルを比較する能力が含まれます。経済効率。設計​​プロセスで生成されたコストは、提案されたコスト削減と収益増加の使用によって少なくともカバーされる必要があります。

ほとんどの場合、組織の目的は利益の最大化であるため、原則はモデリング プロセスの境界線を定義します。最後の原則である体系的な設計は、モデリング内のさまざまなビューの間に受け入れられる差別化が必要であることを定義します。正確性、関連性、および経済効率はモデルの品質の前提条件であり、満たす必要がありますが、残りのガイドラインはオプションですが必要です。

SEQUAL と GOM の 2 つのフレームワークには、モデリングに精通していない人には使用できないという制限があります。これらは主要な品質メトリクスを提供しますが、専門家以外の人には簡単に適用できません。

プロセス モデルの品質面に関連するボトムアップ メトリックの使用は、モデリングの専門家以外のユーザーによる他の 2 つのフレームワークの使用のギャップを埋める試みですが、これは主に理論的なものであり、その使用を裏付ける実証的なテストは実行されていません。

実施された実験のほとんどは、メトリクスと品質面の関係に関するもので、これらの研究は異なる著者によって個別に行われています。Canforaらは、主にカウントメトリクス（たとえば、タスクや分割の数）とソフトウェアプロセスモデルの保守性との関係を研究しています。^[22] Cardosoは、制御フローの複雑さと知覚される複雑さの相関関係を検証しています。Mendlingらは、プロセスモデルにおけるデッドロックなどの制御フローエラーを予測するためにメトリクスを使用しています。^{[12] [23]}

結果は、モデルのサイズが大きくなると、その品質と理解度が低下する可能性があることを明らかにしています。メンドリングらによるさらなる研究では、測定基準と理解の関係を調査しています^[24]と^[25]いくつかの測定基準はその効果に関して確認されていますが、モデル作成者の個人的な要因、たとえば能力なども、モデルの理解に重要であることが明らかになっています。

実施されたいくつかの実証的調査では、プロセス モデルの品質を評価するための明確なガイドラインや方法がまだ示されていませんが、このタスクでモデラーを導くための明確なガイドライン セットが必要です。実践からそのようなガイドラインを網羅的に説明することは困難ですが、さまざまな実践者によって実用的なガイドラインが提案されています。

ガイドラインのほとんどは簡単に実践できるものではありませんが、「ラベル活動の動詞-名詞」ルールは以前に他の実践者によって提案され、経験的に分析されています。研究から。^[26]プロセスモデルの価値は、グラフィカルな構成要素の選択だけでなく、分析する必要があるテキストラベルによる注釈にも依存します。他のラベル付けスタイルよりも理解の点で優れたモデルになることがわかりました。

これまでの研究やプロセスモデルの品質を評価する方法から、プロセスモデルのサイズ、構造、モデラーの専門知識、モジュール性が全体的な理解度に影響を与えることがわかっています。^{[24] [27]}これらに基づいて、一連のガイドラインが提示されました。 ^[28] 7プロセスモデリングガイドライン（7PMG）。このガイドラインでは、動詞-オブジェクトスタイルに加えて、モデル内の要素の数、構造化モデリングの適用、プロセスモデルの分解に関するガイドラインを使用しています。ガイドラインは次のとおりです。

• G1 モデル内の要素数を最小化する
• G2 要素ごとのルーティングパスを最小化する
• G3 開始イベントと終了イベントを1つずつ使用する
• 可能な限り構造化されたG4モデル
• G5 ORルーティング要素を避ける
• G6 動詞-目的語のアクティビティラベルを使用する
• G7 50以上の要素を持つモデルを分解する

しかし、7PMG の使用には依然として制限があります。妥当性の問題 7PMG はプロセス モデルの内容に関係するものではなく、この内容が整理され表現される方法にのみ関係します。内容はそのままに、プロセス モデルのさまざまな構造を整理する方法は提案しますが、モデルに何を含める必要があるかという実用的な問題は依然として考慮されていません。2 つ目の制限は優先順位付けガイドラインに関係します。導出されたランキングは 21 人のプロセス モデラーの関与のみに依存しているため、実証的な根拠がほとんどありません。

これは、一方ではプロセスモデラーの経験をより幅広く取り入れる必要があると見なすことができますが、優先順位付けのガイドラインに到達するためにどのような代替アプローチが利用可能かという疑問も生じます^。[28]

• モデルの選択
• プロセス（科学）
• プロセスアーキテクチャ
• プロセス計算
• プロセスフロー図
• プロセスオントロジー
• プロセス仕様言語

ウィキメディア・コモンズには、プロセス図に関連するメディアがあります。

• ワークフロー パターンに関するプロセスのモデリング。リンクが壊れているようです^{[永久リンク切れ]}
• 「プロセスの抽象化レベルのプレゼンテーション: プロセス モデリングの原則」(PDF) 。2011年 7 月 14 日にオリジナル(PDF)からアーカイブされました。2008年 6 月 12 日に取得。
• アメリカ生産性品質センター（APQC）は、プロセスとパフォーマンスの改善を目的とした世界的な組織です。
• ワークフロー管理へのペトリネットの応用、WMP van der Aalst、1998 年。