大誤會
這是一種懺悔。我們宣稱自己因傳播虛假形象而有罪。下圖所示的camunda bpmn框架在本書的前一個版本中使用過。2009年在德國投入使用，2012年在英國投入使用，獲得了巨大的成功。數百個bpmn項目使用框架的金字塔描述來進行定向。一家大型的國際軟件供應商甚至將金字塔列入其營銷材料。不幸的是，這導致了一些誤解。
上圖:從舊到新:camunda bpmn框架。
在金字塔中，我們區分了戰略、操作和技術層面。乍一看，它與camunda house類似，但是camunda house將技術級別定義爲操作流程模型中稱爲技術流程流的組件，而不是自己的級別。金字塔把操作層放在一個相當於我們現在所說的人類流程流的位置。
這種改變是必要的，因爲人們經常認爲技術級別是操作級別的細化，換句話說，技術級別只是增加了更多的細節。實際上，操作級模型(在早期框架的意義上)通常比相應的技術級模型更詳細。例如，考慮一個簡單的技術流程流，它觸發一個複雜的手動任務，然後需要一個複雜的手動流程。
出現了兩個相關的誤解。
第一種看法是，三個級別上的建模必須按照固定的順序進行，目標狀態流程必須首先在戰略級別創建，然後在操作級別創建，最後在技術級別創建。沒有必要這樣做。首先創建操作模型或技術模型通常更有意義。這樣做可以讓您在嘗試將其總結或抽象爲戰略過程模型之前，對過程參與者必須進行的工作方式有更清晰的理解。實際上，通常的做法是同時設想流程模型的技術流和人員流，例如在研討會中。
第二個誤解與嚴格的責任分離有關。我們假設只有業務方面定義戰略和操作級別，而只有it部門定義技術級別。我們發現這種假設在政治環境困難的企業中最常見，在這些企業中，it、運營和業務部門之間的合作並不理想。
我們都應該明白，即使是技術流也代表了業務模型。畢竟，它描述的是業務需求。它與經典請求文檔的區別僅僅在於技術流程預期可執行源代碼——這是bpmn的一個主要優勢。如此嚴格的責任分離的風險是，技術模型雖然符合需求，但可能對業務變得難以理解並不能令人滿意。
同樣，在人類流程的設計中不充分地使用it也是一個嚴重的問題。如果認爲您可以純粹從操作的角度定義流程，並且只有在此之後才能使技術實現與流程保持一致，那就太天真了。經驗告訴我們反覆操作決策可以而且應該受到技術現實,要麼因爲業務需要什麼技術上是不可能的(或者不可行,原因成本),或因爲技術可以提供解決方案而不是雷達定義業務需求。
總而言之，您可以說操作流程模型既屬於業務，也屬於it。作爲共享的工件，雙方應該共享其開發。
就我們處理項目的方法而言，這種想法意味着什麼?基本上，它與敏捷項目組織一致:概念與實現的嚴格分離就像經典的瀑布式開發模式一樣過時。大多數it項目在迭代開發中表現得更好，無論是在scrum中的sprint中還是在其他情況下，項目是關於過程改進還是自動化並不重要。企業和it不應該孤立地工作。
非常清楚的是:項目參與者可能需要從他們的舒適區中擺脫出來，並充分地激勵他們誠實地與“對方”一起工作。“在過去的幾年裏，我們強烈鼓勵合作的結果總是一樣的:巨大的驚訝於一個項目是多麼富有成效。”當it和業務肩並肩地在戰略和操作級別(包括技術流程)定義目標狀態流程時，技術流程可以在幾天甚至幾個小時內變爲可執行的。
正如大型保險公司lvm versicherung的thorsten schramm在我們的一次研討會上所說:
“用BPMN進行過程建模只花了幾天時間就極大地鼓舞了整個項目團隊(包括來自it和業務部門的人員)，現在第一個改進的過程已經出現了。”
托爾斯滕很好地提煉了我們的信息。有時候，研討會中的合作經驗與學習bpmn方法論一樣有意義。因此，bpmn可以協同運作，在企業內部產生積極的變化。
下篇文章我們會詳細闡述bpmn符號，歡迎關注~~~
本文會持續更新，歡迎關注，技術支持：盤古BPM