組織は、効率を高め、エラーを減らすために、作業方法の改善を常に追求しています。これには、分析と作業方法の継続的な改善が必要です。これには、 予測可能な状況での非常に構造化されたワークフローや、固定プロセスを規定できない動的な 状況 に対応するためのプロトコルが含まれる 場合があります。
CMMNは、状況の変化に応じて予測できない順序で 実行される可能性のあるさまざまなアクティビティを必要とするケースの処理に基づく作業方法をキャプチャするために使用されるグラフィック表記 です。イベント中心のアプローチとケースファイルの概念を使用して、CMMNは、構造化されていない作業や知識労働者による作業など、 BPMNでモデル化できるものの境界を拡大します 。BPMNとCMMNの組み合わせを使用すると、ユーザーははるかに幅広い作業方法をカバーできます。
BPMNに加えてCMMNが必要な理由は次のとおりです。
- 伝統的に、ビジネス情報システムの研究と実践は、よく構造化されたビジネスプロセスに焦点を合わせています。ただし、多くのビジネスプロセスはモデル化が困難です。
- これは、インシデント管理、コンサルティング、販売などの知識集約型のタスクに特に当てはまります。実際、多くの活動は、事前に計画されるのではなく、アドホックな方法で開始および実行されます。
- これは特に、知識集約型またはプロジェクトベースの活動の場合に当てはまります。これらの活動は、組織のコアコンピテンシーを表すことがよくあります。
アドホックプロセス
アドホックプロセスは、ビジネスアクティビティのセットであり、対応するアーティファクト（情報、意思決定、製品など）であり、高レベルの集約でのみ標準化できます。実際の活動の種類とその順序は、ケースごとに異なります。
アドホックプロセスの特徴は次のとおりです。
- 特定のアクティビティを予測することはできますが、プロジェクトの途中でしか利用できない情報が必要になるため、プロセスの多くは開始時に完全に指定することはできません。
- アドホックプロセスのコンテキストで次のステップが決定されないと仮定すると、それらの実行は従来のプロセスベースの情報システムでは制御できません。ほとんどの場合、知識労働者がプロセスを制御します。
- アドホックプロセスのすべての可能性を設計時に考えることは不可能のようです。そのようなプロセスモデルは複雑になり、管理が困難になります。
BPMNとCMMN
ここ数十年で、適切に構造化された日常的なプロセスのモデリングと自動化に焦点が当てられてきました。BPMNは、知識労働者が主にタスクを実行する、適切に構造化された予測可能な作業に最適です。CMMNは、実行時に意思決定と計画を行う知識労働者が積極的に関与する、予測不可能なプロセスのセクションをカバーします。
ケース管理（CM）は、2005年にvan der Aalstによって知識労働者向けのツールとして導入されました。2014年5月、OMGは、 ケース管理モデルと表記法（CMMN）と呼ばれるケース管理の標準を公開しました。その焦点は、予測不可能で、知識集約的で、構造が弱いプロセスをサポートすることにあります。ケース管理は、プロセスを記述するために制御フローを使用しないビジネスプロセステクノロジーの一種です。
ケース管理とは、ケースに関するすべての情報へのアクセスを知識労働者に提供し、ケースがどのように進展するかについての裁量と制御を知識労働者に与えることです。ケース管理それはプロセスに関するものではなく、労働者に関するものです。従来のプロセスとは対照的に、特定の目標と選択の可能性を提供することは、目標自体を達成する方法よりも重要です。
ここに、BPMNとCMMNの違いを示します。
宣言型表記 は、問題の流れをモデル化しようとはしません。彼らは望ましい結果を確立します。つまり、彼らが何をしたいのかを指定しますが、それがどのように起こるべきかは指定しません。SQLは、プログラムのフローを制御しようとしないため、宣言型プログラミングの例です。それは単にそれが何を表示したいかを述べていますが、それがどのように行われるかは述べていません。
一方、命令型表記は、問題の流れをモデル化しようとします。たとえば、JavaやC ++などの命令型プログラミング言語では、コードの実行方法をコンパイラーに指示しますが、実行したいことを明示的に指示しないコマンドを確立します。
構造化プロセスvsケースvsアドホックプロセス
設計時間と実行時間
CMMNにはシーケンスフローのモデルはありません。タスクの実行は、歩哨と呼ばれるイベントと条件に依存します。歩哨は、発生する特定のイベントの発生、またはケース内で満たされる条件をキャプチャします。エントリは、開始および終了の基準として使用されます。黒と白のひし形が基準を表していることに注意してください。
ケースには、次のように設計時と実行時の2つの異なるフェーズがあります。
設計時間
設計時のフェーズでは、ビジネスアナリストはモデリングに従事します。これには、ケースモデルの事前定義されたセグメントの一部であるタスク（計画項目）の定義と、ケースワーカーが利用できる「任意の」タスクの定義が含まれます。彼/彼女の裁量に基づいてオプションで適用されます。
実行時間
実行時フェーズでは、ケースワーカーは、計画どおりにタスクを実行し、オプションで実行時に任意のタスクをケースプランインスタンスに追加することにより、計画を実行します。
CMMN図の概要
この例は、CMMNでモデル化された紙の書き込みのプロセスを示しています。紙の執筆は集中的な知識作業であり、さまざまな方法で処理できると仮定します。次のように、この例をもう少し詳しく調べてみましょう。
- プロセスには、到達する必要のある2つのマイルストーンがあります。
- ドラフトが完了しました
- ドキュメントが完成しました
- いくつかのタスク（たとえば 、目次の作成）は、作成者の裁量に任されています。
- テキストの書き込みを使用したドラフト ステージの 準備 と グラフィックスの統合 タスクは必須です。
- このステージでは、繰り返しデコレータ（つまり ハッシュ）によってシンボル化される繰り返しルールを定義しました。
- 研究トピック は必須のタスクですが、 参照を 整理するタスク は実行時に決定されます。これは、グラフィックを作成 し て図のリストを生成するのと似てい ます。
- ドキュメントが作成される か、 期限に達すると、プロセスは終了し ます。
* OMGケース管理モデルと表記仕様から抽出
ノート
- ケースプランモデルは、「フォルダ」形状を使用して描かれています
- ケースの名前は左上の長方形で囲むことができます。
- ケースプランモデルのさまざまな要素は、ケースプランモデルの形状の境界内に描かれています。
- この図は、ケースプランモデルの例を示しています。
CMMNの基本概念
ケースの完全な動作モデルは、 ケース計画モデルに取り込まれます。特定のケースモデルの場合、ケースプランモデルは、ケースの初期計画を表すすべての要素と、ケースワーカーによる実行時計画を通じて計画のさらなる進化をサポートするすべての要素で構成されます。プランアイテムには次の4つのタイプがあります。
タスク
タスクは作業の単位です。タスクには次の3つのタイプがあります。
タスク（任意のタスク）
タスクは常にケースモデルの事前定義されたセグメントの一部です。タスクに加えて、ケースワーカーが利用できる任意のタスクがあり、オプションで彼/彼女の裁量に基づいて適用されます。任意のタスクは、破線と丸みを帯びた角を持つ長方形で表されます/任意のタスクタイプは任意である可能性があることに注意してください。
イベントリスナー
イベントは、ケースの過程で発生するものです。たとえば、ステージとタスクの有効化、アクティブ化、終了、またはマイルストーンの達成。
マイルストーン
マイルストーンは、ケースの進行状況の評価を可能にするために定義された、達成可能な目標を表します。マイルストーンに直接関連する作業はありませんが、一連のタスクの完了または主要な成果物（ケースファイルの情報）の可用性は、通常、マイルストーンの達成につながります。マイルストーンには、マイルストーンに到達したときの条件を定義する0個以上のエントリ基準が含まれる場合があります。
たとえば、準拠プロセスには、次のようにタイマーイベントリスナーとマイルストーンを使用してモデル化できるサービスレベルアグリーメント（SLA）があります。
ステージと任意のステージ
- ステージは、ケースの「フェーズ」と考えることができ、通常、いくつかのタスクをグループ化します。
- それは、ケースの計画が構築され、さらに進化することができる要素のコンテナです。
- ステージは、ケースの「エピソード」と見なされる場合があります。これらはサブケース（BPMNのサブプロセスと同様）と見なすことができ、並行して実行されます。
- ステージは、角のある長方形と、下部中央の小さなボックスに「-」記号の形をしたマーカーで表されます（「-」は拡張されたステージを示します）。
- ユーザーの裁量で、任意のステージを「オプションで」、「アドホック」にプランに追加できます。
次の図は、1つのサブステージと3つのタスクを持つ拡張ステージを示しています。
基準
基準を使用すると、タスク、ステージ、またはマイルストーンを実行できるようにするタイミング（エントリ基準）、またはケース（ケースプラン）、ステージ、またはタスクを異常終了するタイミング（終了基準）を記述できます。基準には、次の2つのオプション部分があります。
- 1つ以上のトリガーイベント（onPartsと呼ばれます）。これらは、入場基準または退場基準の評価を満たすイベントです。
文を構成する基準は次のように考えることができます。
([ on < Event 1 >[, on < Event 2 >[, . . .]] ]) AND ([ if < Boolean condition > ])
ご了承ください：
- 角かっこ（[]）は文のオプション部分を示し、山かっこ（<>）は交換するプレースホルダーです。
- onPartとifPartはどちらも 文の中でオプションですが、意味をなすためには、少なくとも1つが存在している必要があります。
エントリー基準
エントリ基準は、ステージ、タスク、またはマイルストーンを実行できるようにするために満たす必要のある条件を記述します。エントリ基準のないステージ、タスク、またはマイルストーンは、作成されるとすぐに実行できるようになります。エントリー基準は、ステージ、タスク、またはマイルストーンの境界のどこにでも配置できます。
例
以下の例では、製品の苦情とサービスの苦情の両方の段階で、苦情がそのタイプの場合にのみ実行できるため、入力基準が必要です。ほとんどの場合、2つの段階のうち1つだけが実行されますが、状況によっては、苦情が両方の段階に関係する場合があります。
終了基準
終了基準は開始基準に似ていますが、それが満たされたときにステージ、タスク、またはケース（ケース計画）での作業を停止するために使用されます。苦情処理では、ケースの終了基準を追加します。このような状況では、お客様から電話があり、苦情がキャンセルされたため、ケースの処理を停止する必要があります。このシナリオは、顧客からの電話や顧客からの手紙の音声録音などのキャンセルケースファイルアイテムを使用してモデル化されています。
ケースファイル
CMMNでは、各ケースインスタンスに単一の ケースファイル（ケースフォルダーまたは ケースのみ とも呼ばれ ます）が含まれ、ケースワーカーはそのケースファイル内のすべてのデータにアクセスできます。ケースワーカーは、十分な権限を持っている限り、ケース内でタスクを実行していなくても、ケースファイル内のデータを追加、削除、および変更できます。ケースファイル内のデータは、ケースファイルアイテムと呼ばれます。
すべてのデータとデータ構造は、 ケースファイルアイテムと呼ばれます。すべてのケースファイルアイテムは、ケースファイルに保存されます。ケースファイルアイテムは、データベース内のデータ値、データベース内の行、ドキュメント、スプレッドシート、画像、ビデオ、音声録音など、あらゆる種類のデータを表すために使用されます。基本データに加えて、ケースファイルアイテムは、ディレクトリ、フォルダ、セット、スタック、リストなどのコンテナを表すこともできます。
例
計画表
ステージまたはヒューマンタスクには、任意のアイテムが視覚化されているか（-）、視覚化されていないか（+）を示す計画テーブルを含めることができます。ユーザーが計画テーブルを「展開」すると、それに含まれる任意のアイテムがステージ内またはヒューマンタスクの外部に表示されます。ヒューマンタスクに関連する任意のアイテムの場合、計画はタスクのアクティブな状態でのみ使用できます。
