BPM：和你以為的不一樣(上)
cactus
5則回應
分享
2008/09/11 09:58:02
在前幾篇談了些觀念性的說明，此次談談實際導入BPM前一些各位可能已經考慮到或還沒體認到的事，或者說因為領域的不同對於『常識』的認知可能不太一樣
的地方：
流程管理目標：
BPM專案的目標是要簡化介面讓員工便於使用以增進效能(如方便海外員工的單據請領、跨區簽核流程)，或是詳細收集資料以利企業分析(如ABC成本分
析、呆滯料成因分析流程)，還是要訂立SOP降低成本(如統購議價、採購比價流程)…etc，不同的目標有不同的取捨與不同的設計方式。
請先確立好流程目標並取得參與者對目標的認同與共識，之後進行規劃時才不會偏重到錯誤的重點。就如同河川整治，自是由較常淹水且對民生環境影響較大的區
段開始下手。對於不會淹水(沙漠)或是淹了水也沒影響(雨林)或是根本沒救(地層持續下陷)的地段進行河川整治，除了消化預算與增進就業率外效益相當有
限。
關於目標制定，請參考目標管理把高階目標訂為一到三個，最多不要超過五個。目標過多很容易成為需求發散的藉口或是淪為表相的口號而非真實需要的管理目
的。有明確合理的流程管理目標所實作出的BPM系統，一方面能把有限的資源花在刀口上，也較不易因為使用者不瞭解『為何而戰』而想出各種父子騎驢的藉口
來規避導入與使用系統。
比方管理階層要的是收集資料以利分析，結果一般使用者不清楚這個目標，就會不斷抱怨為何要輸入一些之前（系統or紙本）不需要填的資料甚至抵制系統(實
務上若user對策略目標的『順服性』沒那好，那就需要搭配點行政上的誘因，例如有填時所請的款通過隔天就能入帳，沒填的要下個月才能入帳…etc)。
這點其實不光是BPM系統而是所有的資訊系統在導入時都應該要有的溝通準備。（SAS的Gary Cokins說過一句挺直的話: 若沒有目標和策略，
就如同是笨蛋拿了工具，仍然還是個笨蛋。）
流程規範：
最基本的『管理』就是建立規範，使人行事有所依歸(聖經:人類最早的規範-不要吃那棵樹上的果子)。可以不認同其他企業的Best Practice，
但至少<>b自家企業內該有自己的業務流程規範（不同的功能單位自可能會有不同的流程需求，但若功能相近的部門(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內就能解決簽核組織資料的需求，那
可能就大錯特錯了（當然若只是個請假流程之類的地域性流程就沒差）。
此外，還要注意，當各業務單位用口頭說明流程『個案』時可能都還頭頭是道，但要其邏輯化並列出組織關係時那就可能費了好一番功夫還歸納不了，或是例外連
連。越是分權管理的集團企業，一般需要花更多時間來歸納流程組織邏輯。(未完，下一篇待續)
cactus
留下回應
分享
李仰哲
2009/12/17 04:00:00
需求確認一直是專案的必要步驟，商業流程管理(BPM)專案自然也不例外。但您知道BPM專案與一般的資訊系統專案在需求蒐集方面有哪些不同嗎？
就像某股市名嘴說的：「好的老師帶你上天堂，不好的老師帶你住套房」…在專案的世界裡，則有以下這麼一句話：「好的SA/key users帶你上天
堂，不好的SA/key users帶你改不完」。BPM專案尤甚如此，在筆者經手的BPM專案裡，只要企業沒有先搞清楚為何而戰？為誰而戰？…那該專
案往往都會走向失敗。
所謂的「為何而戰」是指，企業必須先確認、決定BPM專案的目標與範疇，以及理性的排定需求項目的優先順序(priority)，以及判斷哪些需求是必
要(must have)的、哪些是有了會更好(nice to have)。
至於「為誰而戰」則決定了哪些人的期望應被優先滿足，某個程度來說，其也是左右must have與nice to have的主要變因。
而且，就像筆者之前曾在BPM是Top down還是Bottom up系列文章裡面提到的：在BPM專案裡，為誰而戰是很容易就會被隱瞞或者是誤導
的。因此專案負責人必須要特別注意該點。
搞懂為誰而戰！
為誰而戰之所以這麼容易在BPM專案中失焦，與該類型專案多半涉及跨部門業務流程有關。
如果負責BPM專案的經理不是由擁有跨部門經驗、視野的中高階主管擔任，那其多半沒辦法察覺、規劃出一條更有效率的跨部門業務流程，比較常見的結局是：
依既有的紙本「圖章流」擬定跨部門業務流程。
問題來了，到底該由誰來統籌BPM專案？傳統的資訊專案幾乎都是由該系統的主要使用部門負責確認、測試系統需求，如人事系統由人事部門負責，財務系統由
財務部門主導等，但上述作法並不適用於涉及跨部門業務流程的BPM專案。
對企業來說，負責蒐集BPM專案需求的人若不具備跨部門視野，那提出來的業務流程多半只是複雜化自己熟悉的流程並且忽略、甚至是簡化其他部分，當然，該
類BPM專案的實作成果除與高階主管心中預期的成效有著極大的落差外，企業多半也沒辦法藉由該專案獲利、或者是拉升員工生產力。
簡言之，企業若能在BPM專案開始前、便找到符合資格的人來當流程需求的負責人，將能大幅拉升企業導入BPM專案的成效。那麼誰適合呢？筆者建議由平常
就已經在協調跨部門業務工作、且對公司營運狀況有一定了解與決策權限的總經理特助。
除了找到對的負責人外，筆者還常常在BPM專案中看到另外一個問題：先決定專案成員，之後再想法子分派任務給上述成員…看到這，相信有專案經驗的讀者一
定都發現問題點在哪了：上述作法與一個無包袱、合理的專案成員招募流程完全相反。
因此建議BPM專案經理先確定專案涉及的業務流程有哪些，之後再依上述流程內容找出適切的專案成員。在確認完上述方向後，接下來的工作才與一般的資訊專
案一樣，如成員們必須深入了解各部門員工的作業流程、遭遇的問題，並設法釐清該怎麼調整員工的作業流程，才能發揮BPM專案的成效。
至於怎麼做？則待筆者在下一篇文章與您分享。(未完，待續)