2009年4月1日 星期三

BPM是Top down還是Bottom-up的過程?

  隨著BPM逐漸往顯學的路上邁進,相關的研討會越來越多,許多ERP與Middleware的大廠也紛紛發表自身的BPM產品。不過以敝人參與過的部份發表會,多少難免老王賣瓜、各彈各的調。連筆者認識的一些資深業界朋友都不免因而被誤導而對BPM有了一些先入為主似是而非的理解。而一些比較客觀的文章則有些太過技術導向不易為非技術人員了解,而有些又太過企管導向不易下手落實。因此敝人試著以一系列企業在談到BPM時,較常提出的問題中選出幾個作為題目。如本次開場的「BPM是Top down還是Bottom-up的過程?」,未來會陸續談到的「BPM會不會引起內部革命」、「需要ESB/SOA才能做BPM嗎?」、「BPM如何與BI結合?」。間或穿插一些闡述性的題目如:「流程才是知識資產」等,試著以不同的方式來說明,希望能讓各位對BPM有更好的瞭解。各位有問題也歡迎留言指教,或許您的問題便是我們未來的題目。

由美食到BPM  

民以食為天;我先用做菜來比喻:

  一個主廚或許無法清楚明確的描述出他的做菜步驟,卻還是能煮出一盤盤好菜。但沒有詳細的食譜,廚房的學徒們只能在旁以觀摩強記的方式學習如何做出相仿的菜色,甚至得靠著吃「菜尾」來學味道,待時日漸久後靠著本身的努力與「慧根」才或許能慢慢磨練成為二廚,到最後出師獨當一面。因此這家餐廳能擴張的速度也就受限於學徒的資質與學習的速度。若只是本店擴大營業倒還好,至少主廚能隨時在旁試味道、看手法提點補救,因此擴編本店時所需的人力不需要具有太精湛的火候也無妨。但若是要開設分餐廳的話就不成了,靠電話是沒法試味道與傳授講不清的步驟的。因此分餐廳的大廚就得具有獨當一面火候的老手才能坐鎮,因此在資金無虞的狀況下能開設幾家分餐廳,就完全取決於能培養多少具有獨當一面的火候,又能彰顯餐廳特色口味的大廚了。

  與之恰好對比相反的則是如85℃、源士林粥品這類的連鎖店了。他擴張靠的就是標準化的作業程序,因此在需要時能快速展店擴展規模。以單一店面而言連鎖店的表現或許不如精緻小店,但以企業整體表現來看在整體經濟環境不太差的狀況下,展店快速的連鎖店就具有明顯優勢了。

  一般企業也是如此,一家公司可以在沒有明文詳細Business Process的狀況下還能經營的嚇嚇叫,營利豐厚。但在沒有明定基本SOP的情況下,要擴展企業規模就會面臨類似的困境:由內部提拔經驗能力夠的人才則人手有限不敷使用、由外部挖角過來的高手則在無法規範的狀況下最後常是各自為政、自立山頭,與總部的作風與規劃大相逕庭。除地方對總部政策的理解落實度、總部對地方狀況的掌握度、聯合作業時的成效等問題外,當某地業務突飛猛進因而需抽調人力支援的效果也不好,因為不同辦公室做法完全不同,由A辦公室調到B辦公室支援的同仁除了往外跑的業務本就難免因為風土人情不同而須調適,就連負責內部行政作業的同仁也得重新學習適應不同的做法後才能派上用場。就好比挖角來的分餐廳大廚做的菜雖好,但跟總店的風味卻明顯不同。客人上門吃不到預期的口味,對於這個招牌/品牌的信任度與忠誠度自然下降。大概就只能騙騙路過或是沒試過總店風味的呆胞了。若真如此那倒不如創個副品牌還好些,不要勉強掛同樣的招牌。

  另一種較單純不考慮分公司的狀況則一樣以做菜來比喻,可視為主廚不再撰寫完整的食譜,反之是一系列不同的標準動作,將做菜的步驟分為好幾人分工的步驟:各自負責選料採買、清洗切菜、調配香料、熱鍋等不同工作,最後再由主廚將這些材料、佐料、湯鍋、烤箱等以最短的時間匯總為美味佳餚而不用自己注意太多的枝微末節與花時間在次要步驟上。目的不再是開設分店因為最關鍵的料理動作還是只能由主廚負責,但他能將所有時間專注於處理這個非他不可的步驟即可而不用再分神於其他程序,因此提升產出的質與量。

  對應到企業的BPM則是:所有不同部門在不同階段的工作的最終目的,其實就是供決策者在需要的恰當時點能有充足的必要資訊來進行決策。而不必臨時東查西問甚至靠憑空猜測來做出決定,也不需分神於與此次決策無關的次要事項。而決策時需要哪些資訊來輔助與應先行完成哪些步驟來過濾或許會因狀況不同而不同,就如同客人點的菜不同則學徒們所需準備的材料、佐料、廚具就不同,除了主廚外又有誰能描述指派的更精確適當?

  由以上角度看,BPM的制定該是Top down還是Bottom-up的過程就應該清楚了。

「民主」型BPM?

  實務上當然也有一些例外狀況,如:一家企業所定的Business Process已明顯年久失修不合時宜,如同不少企業都有好些已沒人在遵循的【內規】,這些內規或是不合時宜或是太過繁瑣以致連主管階級都普遍受不了,反正只要老闆有蓋章,管它啥內規外規。在這種情況下既有Top down的標準已不合用,只好以Bottom-up的方式來自立救濟。另一種則像前述不會寫食譜的主廚,主廚寫不出來只好指望下面的實習廚師有沒有表達能力好點的能將觀摩所得整理歸納出來。只是在企業常見的狀況則是主管太忙,於是會以美其名為【腦力激盪】的方式將責任分散下放給下屬。最後一種則是主廚換人,在前一位主廚未留下【秘笈】情況下,只好請學徒們照往常的作法繼續,自己再由最後所組合送上的材料、佐料、廚具等來依照個人經驗猜測前人大概是怎麼料理來試圖做出一樣的美食。

  無論何種都是由下屬各自瞎子摸象以求組合出全貌,但常見問題是各部門各持己見、誇大本身部門的複雜度與重要性,結果往往大象沒拼成卻拼出了變形金剛。畢竟BPM主要效益與應處理的對象其實是涵蓋數個部門的整體business process,對於單一部門內的處理細節與例外處理等就比較不是BPM的重點而是如HR、SFA、FM、SCM等專門系統的處理範疇,且BPM供應商對於這些較特化的需求也往往不如專門系統供應商來的了解透徹(這方面BPM、BI處境倒是有些相似)。BPM的重點是讓你在專業(系統)作業時能有正確的資訊來處理,並待處理完後將完整的資訊傳承下去以利後續的處理人員/主管/系統也能有正確的資訊來作業/決策(註1)。對於缺乏跨部門工作經驗與視野的一般部門員工而言,即便在部門內表現有多優秀多聰穎,還是難掩見樹不見林的盲點。易陷於光想解決部門內的特殊狀況而忘了對企業整體而言它所主要需解決的問題是哪些。或是流於著重執行層面的便利性而忽略了政策與稽核面的考量,或是蕭規曹隨的知其然卻不知其所以然以致錯失改善的機會。因此BPM在制定時絕對是需要具有跨部門眼光與企業通盤視野與決策權的中高階主管來參與決策與制定,否則只會淪為少數部門的高價玩具卻未必能為企業整體帶來明顯效益甚至反成為拖累企業整體效率的大雜燴。

註1:看到此或許會覺得與EAI類似,一個簡單概念上的差異是BPM是由業務上的需要來看所需的資訊,只是這些資訊恰好須由不同系統來。範疇是由業務所決定。EAI則是偏向由系統觀點來看不同系統所需的資料來源傳遞。範疇是由系統需求決定。另一個說法則可將BPM比喻為一個代表信箱,使用人員統一由這個代表信箱來看到不同專業信箱轉來的資料從而得知該處理的業務有哪些。EAI則是各自有各自的專業信箱,使用人員需各自登入不同的專業信箱來得知不同信箱有哪些新的(或是沒有)待處理事項--Middleware廠商所提出的「BPM」多是屬於此類,是有商業流程的概念在其中不過比較偏向技術性EAI的面向,適合熟悉專業系統複雜操作的專業人員,但對主管階層與其他業務人員而言普遍就不夠友善了。比如所有HR系統一定都能看到員工本身的休假記錄,功能就在那,不過可不是所有員工都知道如何查。更不用提有多少業助職位的產生是因為業務不會用ERP或是SFA。

沒有留言: