BPM導入小常識

　　在前幾篇談了些觀念性的說明，此次談談在實際導入BPM前一些各位可能已經考慮到或還沒體認到的事，或者說因為領域的不同對於『常識』的認知可能不太一樣：

流程管理目標：

　　BPM專案的目標是要簡化介面讓員工便於使用以增進效能(如方便海外員工的單據請領、跨區簽核流程)，或是詳細收集資料以利企業分析(如ABC成本分析、呆滯料成因分析流程)，還是要訂立SOP降低成本(如統購議價、採購比價流程)…etc，不同的目標有不同的取捨與不同的設計方式。

　　請先確立好流程目標並取得參與者對目標的認同與共識，之後進行規劃時才不會偏重到錯誤的重點。就如同河川整治，自是由較常淹水且對民生環境影響較大的區段開始下手。對於不會淹水(沙漠)或是淹了水也沒影響(雨林)或是根本沒救(地層持續下陷)的地段進行河川整治，除了消化預算與增進就業率外效益相當有限。

　　關於目標制定，請參考目標管理把高階目標訂為一到三個，最多不要超過五個。目標過多很容易成為需求發散的藉口或是淪為表相的口號而非真實需要的管理目的。有了明確合理的流程管理目標，所實作出的BPM系統一方面能把有限的資源花在刀口上，也較不易因為使用者不瞭解『為何而戰』而想出各種父子騎驢的藉口來規避導入與使用系統。比方管理階層要的是收集資料以利分析，結果一般使用者不清楚這個目標，就會不斷抱怨為何要輸入一些之前（系統or紙本）不需要填的資料甚至抵制系統(實務上若user對策略目標的『順服性』沒那好，那就需要搭配點行政上的誘因例如有填時所請的款通過隔天就能入帳，沒填的要下個月才能入帳…etc)。這點其實不光是BPM系統而是所有的資訊系統在導入時都應該要有的溝通準備。（SAS的Gary Cokins說過一句挺直的話: 若沒有目標和策略，就如同是笨蛋拿了工具，仍然還是個笨蛋。）

流程規範：

　　最基本的『管理』就是建立規範使人行事有所依歸(聖經:人類最早的規範-不要吃那棵樹上的果子)。可以不認同其他企業的Best Practice，但至少自家企業內也該有自己的業務流程規範（不同的功能單位自可能會有不同的流程需求，但若功能相近的部門(ex:不同廠區的財務)也沒有共通點，那應該有可討論改善的空間）。若是各部門/廠/BU都各說各話，那表示基本上缺乏共識與規範，也不用談啥流程管理了，頂多稱做電子化。若是如此，選用較單純的傳統workflow平台即可，不需特意採用BPMS(多了一個S代表系統「system」)。就好比沒必要為了不知哪一天才會真正成行、多少人參與、要到哪裡的團體旅遊而煩惱要買哪種車：幾個座位、高速胎還是越野胎、汽油還是瓦斯…etc。

　　改變大夥既有的習慣確實是吃力不討好的工作，但若是一開始的目標確認沒有問題，訂出與目標相合的流程規範便應是為所當為。此時高階主管間的討論與共識形成是必要的，若各單位派出參與專案人員的眼光不夠全面，對目標認識不夠清楚，便很容易淪入僅是重覆陳述as-is而對於to-be毫無主見甚至心生反抗的狀況。

　　結果系統導入工程師得花一堆額外effort來設法滿足各種不必要的差異不說，後續接手的系統維護人員也將痛苦萬分：因為每個單位所需維護與調整的狀況都每每不同。更慘的是無法達到專案當初預期的目標，之前管不到的業務流程以後還是沒法管，而被中央高階主管質疑－到此時高階主管才投入開始整個翻案也不是沒有過的事，結果就是明明可提早做的事不做而造成專案成本成倍翻揚(等於是用系統實做這種最昂貴的展現方式來將as-is的混亂性呈現給高階主管後，才開始投入to-be的統一規劃)甚或是白忙一場成為無效專案。

流程簽核組織：

　　在矩陣式組織或說功能性組織越來越普及的今天，人事單位所保有的行政組織架構常常是不敷BPM所需的。一種常見的情況是HR資料上記錄的行政組織僅包含地緣關係，但是對於BU層級的業務歸屬就不見得有正確的資料了。

　　譬如某東歐業務辦公室的sales在行政上是歸屬當地的GM，但業務上對客戶的接單、定價等卻是要直接跟台北的BU主管報告。大一點的業務辦公室各BU可能還有專屬sales(即每位sales均專門處理特定BU的業務)。但小一些的業務辦公室可能就得「共享」sales，也就是sales啥BU的產品都賣。這樣的架構無論是專屬sales還是共享sales的回報路徑，在一般人事系統或是LDAP內是不會有的，可是卻是企業在執行業務流程時的必備資料。

　　實務上各家BPMS自當有其解決的方法，在此只是提醒各位若認為只要把人事系統或是LDAP系統內的資料轉到BPMS內就能解決簽核組織資料的需求，那可能就大錯特錯了（當然若只是個請假流程之類的地域性流程就沒差）。

　　且要注意當各業務單位用口頭說明流程『個案』時可能都還頭頭是道，但要其邏輯化並列出組織關係時那就可能費了好一番功夫還歸納不了或是例外連連，越是分權管理的集團企業，一般需要花更多時間來歸納流程組織邏輯。

既有系統的開放性：

　　BPMS畢竟不是Middleware，BPM較傳統SI的優勢是能以整體業務流程的觀點來看資訊整合而非單純系統對系統的觀點。不過在整合技術上BPMS所受到的限制跟大多數SI是一樣的(若BPMS的架構不好則限制會比SI更多)，所以若企業所使用的系統是由『失傳的技藝』所架構成的封閉式系統，導入BPM專案後也不會因此『芝麻開門』。BPMS不是仙女棒(Middleware也不是)這點技術上的認知與準備是要有的(這也是許多BPM相關討論對於SOA有深刻盼望的緣故)，不切實際的期望只會導致失望。

權限觀點的不同：

　　在傳統AP如ERP，對於系統權限的控管是以帳號為標的，也就是限制每個帳號（人）能夠看到哪些資料，因為傳統AP基本上是『查找』資料的概念。要看到不同的資料就需要對該帳號的『查找』權限進行調整。(部份系統則甚至一個人得有多個不同帳號才能處理所有需處理的事物)。

而從流程觀點來看則稍有不同，基本區分為兩段：
　　
　　首先流程看的是在不同的流程階段(關卡)，該階段要處理哪些事，故需要看到(填寫)哪些內容。之後實際上誰能看到這些內容則是到流程開始運行後，才根據流程邏輯判斷是否、啥時流到該關卡，流到後誰要負責該關卡，從而賦予看到(填寫)該關卡內容的權力。

　　所以若是套用AP的觀點來看流程的權限就可能會有些不適應。比如：『只有總經理能看到某某資訊』這在傳統AP是自然不過的權限要求。可是BPM談的則是『在某階段能看到某某資訊』，至於某階段的負責人是否只可能是總經理則是靠流程設定而非權限控管。由此衍伸的問題是：當總經理不在時怎麼辦？等到總經理回來再處理是一種方式（業務停擺?），簽核代理人則是另一種常見方式。可是此時依照流程的想法，不管代理人是誰，都仍該看到『充足』的資訊才能做出正確的判斷，既然原本的負責人選定了某人做為代理人，那代理人自當能有足夠的資訊才能做好代理的工作，因此他就會看到那些在傳統觀點下『只有＂某某人＂能看的資料』。除非對代理人的期望僅是橡皮圖章等級，若真如此，不如叫資訊部直接bypass流程乾脆些。

　　以上五點是在考慮推導BPM專案時，應該需要具備的一些觀念。雖然其實還能繼續往下列，不過多了也不會記得所以還是遵照重點管理的建議以不超過五點為原則，希望有所幫助。