Keith Kiss

先注明這是一篇隨筆性文章，以致接下來可能有的錯誤都是情有可緣的。（板磚接連而來）

接觸了不少專業領域的流程引擎提供商的產品，幾乎所有的廠家都有自帶的OC（Organization Chart）模塊。這讓不少最終用戶很欣喜，理由實在是很簡單，國內很多企業的HR系統維護不完善，此中原因是多方面的。

那么一個不完善的系統為何會影響到流程的設計呢？我們舉個例子簡單的闡述一下，了解這個原因的朋友可以跳過此節。我們都知道，公司里的每個員工都應該有個對應的職務，例如信息部門經理，市場總監等，在流程中的某個環節需要信息部門經理來審批，而HR或AD中該字段的信息沒有進行正確的維護，導致流程不知道該找誰來審批，從而出現問題。如果強行將信息部門經理張飛的名字拉入進該節點進行審批操作，那一理張飛離職，該流程就是斷檔。

上面只是一個簡單場景的描述，還有一些客觀原因造成現有的HR系統或AD信息不能參與流程設計本身。例如，公司里可能有正式的職務信息，但同時也有多個附加的職務信息，例如，關羽是銷售Office產品的銷售部門經理，同時他也是多個產品組合銷售部門的經理，例如：Office和Sharepoint等產品的組合包。后者的名稱會隨著產品功能的變化而變化的，因此在HR系統或正式名片上只有其正式職務，即銷售部門經理。但很明顯，這兩職務的權限是不一樣的，因此在流程審批時就是困難了。

那些提供了OC模塊的流程引擎廠家到了這一點，并將其產品能提供這一功能而作為較大的賣點。但這個OC將來的維護責任在誰？IT？還是HR？相信任何一個IT部門經理不愿意答案是前者。有些流程引擎產品的OC設計比較弱，并不能完全考慮到企業的復雜情況，但這一功能是基于產品包提供的，不會有靈活的變更，需要Partner進行擴展開發，這下麻煩了，且不去看廠家是否愿意公司OC的細節，光是定制開發擴展OC這一塊就是個不小的工作量，況且有些問題并不是技術在解決，而應該是政策。

有幸看到一個專業的國際流程引擎產品，其本身非常專注于流程的設計及監控本身，OC這一塊是空白。經過對該產品的大量研究發現，其必須要符合中國特色才行，所以，他也應該具有OC模塊，很興奮，他的底層數據都是開放的，而且有很強的編程操作方法。

結合上述的OC的責任問題，我在該流程引擎產品的OC設計上提出一個新的概念：Virtual OC　。同樣，引申出來的概念：Virtual Role。我們可以理解這個OC不是正式，官方的，但流程里又是必不可少的，設計時考慮到流程審批者的定位問題（即如何找到這個人），以及復雜的OC問題，Virtual Role解決了復雜的職務，角色問題。這些Virtual Role可能不同的部門有不同的理解，因此是細化到部門的Virtual OC。

還有一點要注意，名稱本身有個小小的陷井：Virtual OC，Virtual Role，顧名思義，一切都是虛擬的，維護工作由各部門自己負責，責任不在IT，而在于提出這些Virtual Role名稱的部門本身。