Table of Contents hide
組織一直在尋求改進他們的工作方式，以提高效率並減少錯誤。這需要對其工作方法進行分析和持續改進，其中可能包括在 可預測情況下非常結構化的工作流程，以及 在無法規定固定流程的情況下應對動態 情況 的協議。
CMMN 是一種圖形符號，用於捕獲工作方法，這些工作方法基於處理需要各種活動的案例，這些活動可能會以 不可預測的順序執行以響應不斷變化的情況。使用以事件為中心的方法和案例文件的概念，CMMN 擴展了可以使用 BPMN建模的範圍，包括較少結構化的工作工作和由知識工作者驅動的工作。結合使用BPMN 和CMMN，用戶可以覆蓋更廣泛的工作方法。
以下是我們在BPMN 之外還需要CMMN 的一些原因：
- 傳統上，業務信息系統的研究和實踐側重於結構良好的業務流程。然而，許多業務流程難以建模。
- 對於事件管理、諮詢或銷售等知識密集型任務尤其如此。事實上，許多活動都是以臨時方式開始和進行的，而不是提前計劃好的。
- 對於知識密集型或基於項目的活動尤其如此，它們通常代表組織的核心競爭力。
臨時流程
Ad-hoc 流程是一組業務活動和相應的工件（例如信息、決策和產品），它們只能在高級別聚合中進行標準化。實際的活動種類及其順序因情況而異。
以下是Ad-hoc Process 的特點：
- 雖然可以預測某些活動，但大部分過程不能在一開始就完全指定，因為它需要的信息只能以某種方式進入項目。
- 如果我們假設在ad-hoc 流程的上下文中永遠不會確定下一步，那麼它們的執行就無法由經典的基於流程的信息系統控制，在大多數情況下，知識工作者控制著流程。
- 似乎不可能在設計時考慮到ad-hoc 流程的所有可能性，這樣的流程模型將變得複雜且難以管理
BPMN 與CMMN
近幾十年來，人們一直關注對結構良好的常規流程進行建模和自動化。BPMN 最適用於結構良好且高度可預測的工作，其中知識工作者主要執行任務，而CMMN 涵蓋了不太可預測的流程部分，知識工作者在運行時積極參與決策和規劃
案例管理(CM) 由van der Aalst 在2005 年作為知識工作者的工具引入。2014 年5 月，OMG 發布了 案例管理標準，稱為案例管理模型和符號(CMMN)。它的重點是支持不可預測的、知識密集型和結構薄弱的流程。案例管理是一種不使用控制流來描述流程的業務流程技術。
案例管理是通過為知識工作者提供訪問與案例相關的所有信息的權限，並賦予他們對案例發展的自由裁量權和控制權來賦予他們權力。案例管理與流程無關，與工人有關。與經典流程相比，某個目標和提供選擇的可能性比實現目標的方式本身更重要。
這裡列出了BPMN和CMMN之間的區別：
聲明式表示法 不嘗試對問題的流程進行建模；他們建立期望的結果，即指定他們想要發生的事情，而不是應該如何發生。SQL 是聲明式編程的一個示例，因為它不嘗試控製程序的流程；它只是說明了它想要顯示的內容，但沒有說明它是如何完成的。
另一方面，命令式表示法確實嘗試對問題的流程進行建模；例如，Java 或C++ 等命令式編程語言，它們建立的命令將告訴編譯器他們希望代碼如何運行，但沒有明確地告訴編譯器他們想要發生什麼。
結構化流程vs 案例vs 臨時流程
設計時間與運行時間
CMMN 中沒有序列流模型。任務的執行取決於稱為哨兵的事件和條件哨兵捕獲特定事件的發生或案例中滿足的條件。哨兵用作進入和退出標準。請注意，黑色和白色菱形代表標準。
案例有兩個不同的階段，即設計時和運行時，如下所述：
設計時間
在設可根據他/她的判斷選擇性地應用。
運行
在運行時階段，案例工作人員通過按計劃執行任務來執行計劃，並可選擇在運行時將自主任務添加到案例計劃實例。
CMMN 圖一覽
這個例子說明了用CMMN 建模的論文寫作過程。假設論文寫作是一項密集的知識工作，並且可以以不同的方式處理。讓我們進一步研究這個例子，如下所示：
- 流程有兩個必須達到的里程碑：
- 草稿完成
- 文件完成
- 幾個任務（例如 Create TOC）由作者自行決定。
- 編寫文本 和 集成圖形任務的準備草稿 階段 是強制性的。
- 這個階段定義了重複規則，用重複裝飾器（即 hash）表示。
- 雖然 研究主題 是一項強制性任務，但任務 組織參考 是在運行時決定的。它類似於 創建圖形 和 生成圖形列表。
- 當文檔創建 或 截止日期到達時，流程將完成 。
* 摘自OMG 案例管理模型和符號規範
筆記
- 使用“文件夾”形狀描繪案例計劃模型
- 案例的名稱可以包含在左上角的矩形中。
- 案例計劃模型的各種元素被描繪在案例計劃模型形狀的邊界內。
- 該圖顯示了案例計劃模型的示例。
CMMN的基本概念
案例的完整行為模型被捕獲在 案例計劃模型中。對於特定的案例模型，案例計劃模型包含代表案例初始計劃的所有元素，以及通過案例工作者的運行時計劃支持計劃進一步發展的所有元素。有四種類型的計劃項目：
任務
任務是一個工作單元。有以下三種類型的任務：
任務（全權委託）
任務始終是案例模型中預定義段的一部分。除了任務之外，案例工作者還可以使用酌情任務，可根據他/她的酌情權選擇應用。全權委託任務由帶有虛線和圓角的矩形表示/注意，任何任務類型都可以是全權委託的：
事件監聽器
事件是在案例過程中發生的事情。例如，階段和任務的啟用、激活和終止，或里程碑的實現。
里程碑
里程碑代表可實現的目標，定義為能夠評估案例的進展。沒有工作與里程碑直接相關，但完成一組任務或關鍵可交付成果（案例文件中的信息）的可用性通常會導致實現里程碑。里程碑可能有零個或多個條目標準，這些標准定義了達到里程碑時的條件。
例如，我們在合規流程中有一個服務級別協議(SLA)，可以使用計時器事件偵聽器和里程碑進行建模，如下所示。
階段和全權階段
- 階段可以被認為是一個案例中的一個“階段”，通常將許多任務分組。
- 它是一個包含元素的容器，案例計劃從中構建並可以進一步發展。
- 階段可能被認為是案例的“情節”。它們可以被視為子案例（類似於BPMN 中的子流程），它們也可以並行運行。
- 舞台由帶角的矩形和底部中心的小方框中的“-”符號形式的標記描繪（“-”表示擴展的舞台）。
- 用戶可以自行決定將任意階段添加到計劃中“可選”、“臨時”。
下圖顯示了一個擴展的Stage，其中包含一個子Stage 和三個Task。
標準
標准允許我們描述任務、階段或里程碑何時應可用於執行（進入標準），或案例（案例計劃）、階段或任務何時應異常終止（退出標準）。Criteria 有以下兩個可選部分：
- 一個或多個觸發事件（稱為onParts）。這些事件將滿足進入標准或退出標準的評估
我們可以認為形成句子的標準如下，
([ on < Event 1 >[, on < Event 2 >[, . . .]] ]) AND ([ if < Boolean condition > ])
注意：
- 其中方括號([ ]) 表示句子的可選部分，尖括號(< >) 是要替換的佔位符。
- onPart 和ifPart 在句子中都是可選的，但要使其有意義，至少其中一個必須存在。
進入標準
進入標準描述了階段、任務或里程碑必須滿足的條件才能執行。沒有進入標準的階段、任務或里程碑將在創建後立即可供執行。進入標準可以放置在階段、任務或里程碑邊界的任何位置。
例子
在下面的示例中，產品投訴和服務投訴兩個階段都需要一個條目標準，因為它們只有在投訴屬於它們的類型時才能執行。在大多數情況下，只會執行兩個階段中的一個，儘管在某些情況下，投訴可能涉及兩個階段。
退出標準
退出標準類似於進入標準，但它用於在滿足時停止在階段、任務或案例（案例計劃）上的工作。在投訴過程中，我們會為案件添加退出標準。在客戶致電並取消投訴的情況下，我們需要停止處理此案。我們通過取消案例文件項來模擬這種情況，這可能是客戶電話的錄音或客戶的來信。
案例檔案
在CMMN 中，每個案例實例都包含一個 案例文件 （也稱為 案例文件夾，或簡稱為 案例），案例工作者可以訪問該案例文件中的所有數據。案例工作者可以添加、刪除和修改案例文件中的數據，即使他們沒有執行案例中的任何任務，只要具有足夠的權限即可。案例文件中的數據稱為案例文件項。
所有數據和數據結構都稱為 案例文件項。所有案例文件項目都存儲在案例文件中。案例文件項用於表示各種數據，包括數據庫中的數據值、數據庫中的一行、文檔、電子表格、圖片、視頻、錄音等。除了基礎數據， case 文件項也可以表示容器，包括目錄、文件夾、集合、堆棧、列表等。
例子
計劃表
一個階段或一個人工任務可以有一個計劃表，指示可自由支配的項目是可視化的(-) 還是不可視化的(+)。當用戶“擴展”計劃表時，其包含的任意項在階段內或人工任務外變得可見。對於與人工任務關聯的任意項目，計劃僅在任務的活動狀態下可用。
