流程挖掘：從業(yè)務數(shù)據(jù)中自動發(fā)現(xiàn)端到端的流程
多級流程是一種復雜的流程，其中包含具有多對多關系的實體，例如：采購到付款（P2P）和訂單到現(xiàn)金（O2C）。傳統(tǒng)的流程挖掘技術無法解決此類復雜業(yè)務流程中存在的典型問題——數(shù)據(jù)發(fā)散和收斂問題。
您可以利用多級流程立即發(fā)現(xiàn)一個實體中的活動如何給另一個實體的流程帶來瓶頸和偏差，因此，有了多級流程，您就永遠不必擔心您為了解決了采購效率低下的問題而實施的變更會導致開票效率低下，出現(xiàn)得不償失的情況。
我們繼續(xù)來探討多級流程。
端到端業(yè)務流程通常由多個流程和應用組成。請想想 SAP 中的采購到付款流程。從請購到發(fā)票的整個過程涉及四個不同但存在關聯(lián)的流程：
- 請購
- 訂購
- 收貨
- 發(fā)票
一張發(fā)票可能與多項請購、訂購和貨物相關，因此，一個用例可以將多個請購、訂購和收貨流程實例組合到一個發(fā)票流程實例之中。
IBM Process Mining 能夠通過多級流程將這四個流程中的多個實例組合到一個用例中。 從業(yè)務角度來看，這恰好能滿足您的需求：您想要將與一張發(fā)票關聯(lián)的所有請購或訂購歸入一個用例。
接下來，我們舉一個簡單的例子。
我們通過兩份不同的請購單向一家供應商訂購了四件貨物。
采購部門負責處理這些請購單并創(chuàng)建一份訂單，每行代表一件貨物。
隨后，倉庫收到四件貨物并其登記在一張收貨單上，每行代表一件貨物。
幾天后，會計部門收到并登記發(fā)票，然后進行付款。
如果采用多級流程，這些事件均與一個用例相關聯(lián)，因為它們共用一張發(fā)票。
這樣我們就能得到正確的統(tǒng)計數(shù)據(jù)：當我們計算成本時，我們只需計算一次發(fā)票成本即可。
如果未采用多級流程，那么，每次請購都會產(chǎn)生一個用例，對應一張發(fā)票。顯然，這種統(tǒng)計方法是錯誤的，因為我們會將發(fā)票成本計算四次。
更重要的是，多級流程可創(chuàng)建一個準確的模型，我們可以從中模擬某個子流程發(fā)生的變化，并衡量這些變化對其他子流程的影響。提高請購/訂購的效率可能會導致發(fā)票環(huán)節(jié)出現(xiàn)新瓶頸，而我們可以發(fā)現(xiàn)這些瓶頸。如果未采用多級流程，我們就無法能進行這樣的檢測，因為我們只能在子流程之間建立一對一的關系。
我們來看看 IBM Process Mining 中的一個簡單示例。
我們從 SAP P2P 數(shù)據(jù)集中提取并簡化了與發(fā)票 3018000116_2018_IT10 對應的一個案例相關的多個事件。
您可以下載此 CSV 文件，然后將其加載到 IBM Process Mining 中。請確保映射以下 4 列：Req_ID, PO_ID, MatDoc_ID, and Invoice_ID to 'Process ID'。
您可以獲得該流程模型，它能夠清晰顯示正確的子流程實例數(shù)量。
在流程挖掘項目設置中，我們已經(jīng)說明，這些活動的成本為 20 美元（簡化），然后，我們可以看到成本視圖并確信有效成本準確無誤，因為我們僅計算了一次發(fā)票成本。
我們可以使用分析功能計算用例的總成本、總訂單金額和總發(fā)票金額。這樣，我們就能獲得正確的統(tǒng)計數(shù)據(jù)。
如果沒有多級流程功能會怎樣？
好，我們再來看同一個用例，假設 IBM Process Mining 不具有多級流程功能。
這樣，我們就需要添加一個 caseID 列，作為每個子流程組合的唯一識別號。如上所述，我們必須將每張發(fā)票與每個請購/訂購/貨物組合相關聯(lián)，這會導致數(shù)據(jù)重復。文件在這里。您應當創(chuàng)建一個新項目，僅映射 CaseID 字段。
模擬頻率視圖會顯示這一結果，同時出現(xiàn)四張發(fā)票，和我們預期的錯誤結果一樣。
通過查看成本視圖得到的成本不正確，因為與發(fā)票相關的每項活動都被計算了四次。
因此，儀表板會顯示錯誤的統(tǒng)計數(shù)據(jù)，因為與每張發(fā)票相關的數(shù)據(jù)都會被乘以 4。
可見，我們確實可以通過這種強大的多級流程能力正確地模擬端到端業(yè)務中涉及的多個流程。
在發(fā)現(xiàn)流程及變體，分析成本，繪制統(tǒng)計數(shù)據(jù)以及在模擬中使用數(shù)字孿生技術時均可利用多級流程能力。
了解更多IBM相關：http://cloud.51cto.com/act/ibm2021q3/cloud#p2
