1、bpm標準三人組
本篇文章的重點是將bpmn作爲建模和自動化流程的標準。最近的兩個標準與bpmn密切相關，它們很好地補充了bpmn。這些是用於管理非結構化活動的案例管理模型和符號(CMMN)，以及用於管理決策的決策模型和符號(DMN)。
在本篇文章中，我們將概述這三個標準，然後描述它們如何相互關聯以及如何結合使用。
2、用於結構化工作流的bpmn
最初，bpmn代表業務流程建模符號。第一個版本主要由ibm的stephen a . white開發，然後在2004年由業務流程管理計劃(BPMI)發佈。從一開始，目標就是提供一種標準化的圖形化過程符號，這種符號也可以用於過程自動化。在2005年，隨着bpmn的進一步發展，object management group (OMG)接管了bpmi。omg是it界的一個重要機構。它尤其以其統一建模語言(UML)而聞名，UML是軟件設計的建模標準。bpmi與omg的合併也是bpmn全球勝利的開始，因爲它爲許多公司提供了轉換的動力。
2011年2月，omg發佈了當前版本bpmn 2.0。我們能夠參與其中。2.0版本提供了BPMN的新定義:業務流程模型和符號，因爲2.0版本不僅定義了符號，而且定義了所謂的正式元模型。2013年9月，bpmn被國際標準化組織(ISO)作爲ISO/ iec 195:2013標準發佈。
現在，您可能想知道這個神祕的bpmn在物質意義上是什麼。bpmn是一種規範。它以pdf文檔的形式存在，您可以從omg [?)的網站查閱。bpmn 1.2版本的規範文檔大約有320頁，而2.0版本已經擴展到500頁。這些文檔定義了所有bpmn符號、它們的含義以及組合它們的規則。
在1.2版本中，bpmn還沒有定義在工作流引擎中直接執行bpmn模型所需的所有技術屬性。這導致了幾次將bpmn模型(“映射”)轉換爲bpel模型的不幸嘗試(參見7.2.3節)。然而，bpmn 2.0版本使直接執行成爲可能。這是使用bpmn模型的一個重要因素。另一個重要因素是標準化，它提供了以下優勢:
-
當您不必在每次更改工具時都學習新符號時，您將變得更加獨立於某些bpm工具。今天，存在超過100個bpmn工具;其中許多是免費的。
-
您在其他公司的合作伙伴(客戶、供應商、顧問等等)很可能熟悉bpmn，因此可以快速理解您的流程模型。
-
在僱傭新員工時，更有可能的情況是，他們中的更多人已經能夠閱讀或生成您的bpmn流程模型。
-
當大學和私人公司投入時間和金錢來開發基於bpmn的附加解決方案時，這也會給你帶來好處。我們稍後將介紹的bpmn框架就是這種承諾的一個例子——如果bpmn不是一個標準，我們就永遠不會開發它。
儘管bpmn關注於業務流程，但是有一個重要的限制:有些流程不適合在bpmn中進行建模或自動化。這些是非結構化的過程;過程並不總是以可預測和可重複的方式發生。非結構化過程的一個例子是，一名醫生出現在受傷的事故現場。她不太可能通過bpmn圖來工作，但相反，她會迅速投入進來，根據她的知識和經驗做出決策，當然，也會對混亂的場景做出反應。我們可以從幾乎每個部門或行業中借鑑其他例子，儘管許多例子不那麼明顯。這就是爲什麼cmmn標準現在與bpmn一起存在。
3、用於非結構化案例處理的cmmn
cmmn是案例管理模型和符號的縮寫。omg在2014年3月發佈了cmmn版本1.0。2016年3月，omg發佈了1.1版，也就是所謂的beta版。我們預計cmmn版本1.1將被採用，沒有重大的變化，這就是爲什麼我們在這本書中描述它。
爲了幫助理解cmmn背後的動機，假設您正在主持一個設計業務流程的研討會。您有一屋子在流程中有利害關係的人，您的共同目標是提出一個bpmn流程模型。你從一個可管理的參與者圈子開始，你問他們第一個任務應該是什麼。
你的問題的答案取決於，他們告訴你，然後他們繼續用一系列的條件來刺激你。似乎您必須首先對條件的評估進行建模，並且您將使用一個包含許多可能路徑的網關。
在會議過程中，與會者還指出，經常需要回到流程中，重複之前的任務。雖然在bpmn中表示這樣的跳躍很容易，但是如果它們必須表示一半以上的任務，那麼您的模型很快就會變得像一碗意大利麪。有兩種方法可以走出困境:
-
您解釋說，他們必須以更結構化的方式開始工作，減少例外、偏差、回溯等等。這將限制他們在流程中操作時的靈活性，這可能會讓員工和客戶都感到失望。另一方面，這個過程將變得可預測、可重複，並且它將更少地依賴於控制這個過程的人的隱含知識。
-
你承認每一種情況都可能是不同的，這個過程不可能是均勻地組織起來的。您需要確保處理案例的人員有足夠的自由來利用他們的所有知識和經驗。案例處理不能表示爲bpmn流程;您需要另一種建模方法。這就是cmmn的用武之地。
cmmn標準的典型應用包括:
-
處理特殊情況，例如，客戶投訴
-
複雜的評估，例如，懷疑欺詐索賠解決
-
創造性活動，例如，設計新產品
cmmn可以對這些類型的案例處理進行可視化建模，並且這些模型可以在與cmmn兼容的案例引擎中執行。結果將在以後的文章中從用戶的角度描述的支持案例管理。
首先，cmmn圖看起來類似於bpmn圖。這並不奇怪，因爲這兩個標準都與活動有關，而且都是由omg發佈的。最顯著的區別是順序流，以後文章中我們會單獨介紹。序列流是BPMN的基本組成部分，在cmmn中完全沒有。
在cmmn中缺乏順序流揭示了基本設計的根本差異。bpmn假定了一個清晰的順序，一個基本的順序，在這個順序中任務被期望被執行。流程分支、迴流和對事件的反應的存在並不會破壞定義爲系列的流程的本質。cmmn的情況正好相反。流程序列的缺乏意味着更多的任務之間的跳躍，關於接下來發生什麼的決定留給流程的負責人，即所謂的知識工作者。在cmmn中，可能存在訂單或任務的預定義條件形式的異常，但是可以這樣說，在cmmn中，預定義條件是異常，而在bpmn中，它們是規則。
在現實世界中，整個過程很少符合完全結構化或非結構化的模式。更常見的情況是，流程中有一些結構化部分(可以在bpmn中捕獲這些部分)和一些非結構化部分(需要cmmn)。
本文會持續更新，歡迎關注，技術支持：盤古BPM