AIIM的BPM調查報告出爐

AIIM的BPM調查報告已於十月20日發布，完整的報告有24頁，有意者可到這由AIIM下載。對於AIIM的註冊與登入程序沒耐心的可到這看三週前上傳的宣傳版，不過它第九頁關於BPM為企業所帶來好處的數據與原版不同，大概是哪個統計參數變了，第12、14、18頁的數據依據我在原版也沒找到，應該是附錄B中所提沒公開的部份（要的話可跟AIIM的副總要，副總耶…我看就算了）。

由於整份報告涉及的層面頗多元，這先簡單把所有調查的問題與結果經簡化後列出：

1. 您對BPM的認知是?

* 50% 的回答兼具概念與工具以及持續改善三個面相
* 37% 的回答偏向企管的相關概念
* 5% 將其視為有流程的Middleware軟體

2. 您服務的企業對BPM的一般瞭解程度?

* 25% 瞭解且受重視
* 34% 勉強還算瞭解
* 14% 不知道跟workflow有啥差異
* 26% 不清楚

3. 貴企業要推導BPM的主要障礙是?

* 21% 不了解BPM
* 17% 缺少高階提倡者
* 11% 缺乏相關策略
* 11% 成本考量
* 10% 使用者的排斥

4. 貴企業的BPM成熟度是? (成熟度界定請參考摘要版第10頁的圖)

* 只有23% 企業達到level3的標準化或以上程度，只看部份部門則提高到28% 。不過48% 的企業則都還在最低階的初級階段。

5. 貴企業的BPM策略是?

* 28% 在單一部門施行
* 12% 有跨部門施行
* 16% 達到企業級規模的施行

6. 貴企業BPM專案的提案/贊助人是?

* 總裁18%
* 總經理17%
* 資訊長/技術長17%
* 庶務長10%
* 行政經理9%
* 財務長5%
* 流程長2%
* 法務經理2%
* 其他21%

7. 貴企業是否有專責單位負責BPM專案?

* 僅43% 有專責單位

8. 貴企業是否有流程管理文件？

* 19% 有獨立完整的流程文件
* 19% 則是於一般管理文件中提及流程
* 62% 完全沒有

9. 貴企業是否有流程長(Chief Process Officer)?

* 僅10% 有。

10. 貴企業一般使用者在哪使用BPM?

* 40% 限於公司內網(intranet)
* 37% 主要於公司內網(表示外網(internet)也能用可是不常用到)
* 22% 內外網使用機會差不多
* 1% 主要供外網使用

11. 貴企業期望的BPM投資回收週期是?

* 36% 1~3年
* 16% 1年內
* 15% 3~5年
* 2% 超過5年
* 32% 不清楚

12. BPM能為貴企業帶來哪些好處?
一大堆so這只列前三名:

* 76% 增進流程的效率與產能
* 75% 持續性的改善流程
* 71% 改進流程的連貫性與完整性

13. BPM對企業目標與商業成功的重要性是?

* 無比重要19%
* 顯著重要46%
* 普通重要19%
* 不太重要10%
* 完全無關2%
* 不清楚5%

14. 貴企業導入BPM時遭遇過哪些問題?

* 45% 低估了流程與組織的複雜度
* 41% 缺少對內部員工的觀念推廣/溝通
* 30% 遭遇”政治因素”(非藍綠那種政治而是企業內選邊站的那種)
* 29% 專案範疇失控
* 24% 因為缺乏制度與配套措施導致使用率偏低
* 23% 業務案例不足
* 22% 因為設計或實作的不當導致使用者接受度低
* 21% 低估了內容(content)探求與轉換的難度（應該是指要把未經邏輯化與條理化的業務know how挖掘出來並轉換為可系統化的邏輯這件事）
* 18% 超過預算
* 15% 缺乏專業顧問技巧
* 15% 不同業務領域的流程經驗無法相互利用
* 19% 沒有問題

15. 貴企業新流程上線時是否曾遭遇混亂狀況?

* 38% 不曾
* 31% 曾有小混亂
* 19% 曾有混亂
*8% 曾有顯著混亂
* 3% 慘到無法克服

16. 您認為流程負責人(非流程實作者，而是對實作出的改良流程加以管理的人)對於讓流程有效符合BPM精神的必要性是?

* 87% 必要、13% 不必要。

17. 貴企業的核心業務流程是否均有流程負責人？

* 61% 有、39% 沒有。

18. 貴企業是否有對BPM所收集到的資料進行BI分析?

* 45% 沒有
* 22% 有小部份分析
* 11% 有某種程度的分析
* 8% 有大量的分析
* 12% 不清楚有沒有
* 2% 分析啥?

另外附錄的一堆統計背景我就不列了，比較重要的大概是受訪對象48% 美國、18% 歐洲、12% 亞太區、9% 中南美、7% 加拿大、5% 非洲、2% 中東。其中44% 為跨國公司。

這其中不少東西真要討論起來都能單獨成篇的，而對於正在導入與準備導入BPM的企業而言，實用與參考度最高應該是第14點『導入BPM時遭遇過哪些問題?』。

關於近半數的受訪者表示【低估了流程與組織的複雜度】一事，關於流程複雜度會被低估最常見的兩個原因是：

*亞洲企業對於SOP的落實度往往不是很徹底甚至沒有SOP，因此分散各地的業務單位雖業務相同但每每習慣作法不同，而一般在準備期的徵詢對象多是限於地緣關係就近了解，而不會對其他地區進行太多徵詢。於是等專案開始，各地區參與後各種＂特異習慣＂便逐漸浮出檯面，而使流程不再如預想般單純並逐漸複雜化。對於習慣【地方自治】的集團而言更是明顯，因為就連總部單位也不習慣訂立統一標準，於是流程需求也就越來越分散越來越複雜。此時不光流程的建置是一大挑戰，後續的維護往往比建置更令人頭痛，這點是需要行政管理力量的介入，光想用技術能力滿足的下場就是維護會很耗費成本且辛苦。

* 另外對各業務單位而言都有不少屬於『常識』等級的知識，但對於非相關業務人員而言卻是新知。而這些在深入訪談前由外部觀察或是粗淺徵詢是看不到的。好比成語吧，對懂的人言簡意賅十分清楚，對不懂的人哪知這四個字後面的意義可是豐富得很。所以在準備期由外部可觀察到的業務流程與實際深入討論挖掘出的業務流程規則在複雜度上往往會有很大的差異。這也是為何BPM專案往往需要高階仲裁者的投入才能有較理想的成果與持續性成效。

而組織複雜度會被低估的主要原因則是：

* 實際業務單位的Report Line往往是跨地域的，如：各廠採購實際回報的主管是總公司統購主管而非當地的總經理，各地業務甚至可能得依照客戶訂單內含的產品分別回報給總公司不同產品線的Product Manager。但企業最常為人所知的組織圖則仍多是人事單位依照地域性所繪製的組織圖。基本上人事系統的最主要也是最基本功能是計算薪資，是以自然會以薪資幣別、勞工法規等地域性方式來作主要區隔方式。而AD、LDAP等系統的主要功能是帳號認證，一般作到由部門來歸帳號群組(group)大概還可以，但部門內更細的人員report line一般就不是AD、LDAP系統會涵蓋的範圍了。也就是說系統要走流程，所需要的組織資料很大的可能是不存在任何既有系統中的，甚至是只存在各業務單位主管的腦海或是作業習慣中，需要經過挖掘拼湊才能由系統呈現，尤其是越專門的業務流程發生此類狀況的可能就越高。而且通常各業務單位用口頭說明流程『個案』時可能都還頭頭是道，但要其邏輯化並列出組織關係時就可能費了好一番功夫還歸納不了或是例外連連，這類的effort可就往往比規劃初期光看人事單位組織圖所預估的來的複雜與費時許多。

而逾四成表示【缺少對內部員工的觀念推廣/溝通】，這個常見也可分幾個部份：

* 對觀念的不理解很可能使得立意良善的專案完全偏離初衷。譬如一個我喜歡舉的例子是BSC(平衡計分卡)，原本BSC的精神是先擬定企業策略目標，之後由上往下展開好過濾到底目前各部門所作的事哪些是與企業策略目標相符的，哪些是無關的，從而重新檢視該部門工作的priority與資源分配是否合理，進而將企業的資源集中在與企業策略競爭力最有關的項目上，而一些相關性低的事務則可不需花太多心思與資源進行進一步優化，甚至可考慮外包。不過如此下來可能不少部門會發現原來自己每天如此辛苦作的事竟然可能被歸類為不重要，開玩笑那還得了於是發出各種抗議甚至拒不配合。而BSC主導單位為弭平這種阻力，最偷懶的方式就是變成由下往上推，也就是各部門列出自己的部門目標後，由部門目標往上拼出處級目標、BU目標乃至企業目標。如此自然人人有獎看來皆大歡喜，可是企業目標也因此不是被灌水到數十個之譜就是變為抽象得可以包容萬物，如此自然是與BSC的本意完全不符。

* 對於BPM導入目標認識不清，缺乏明確目標的結果就是怎麼作都是父子騎驢有人罵，到底是要方便使用而簡化表單還是要詳細收集分析數據故需將表單正規化？要著重控管還是要著重效率？要嚴謹防呆還是彈性容錯？…..etc對BPM來說重點是prcoess的management，既然要manage就會被管被監控，所以自由放任度一般不比從前，user便可能因此找各種真實或是被包裝過的理由來抗拒使用系統。

* 另一個BPM的重要精神是持續性的process refine，不能自滿於舊有流程也沒有所謂完美流程，所以無論user是只想照舊規則完全不想變更，或是求好心切越牽連越多想一次到位導致流程發散無法確認都是不對的觀念。

另外三成的『政治因素』這個家家有本難念的經，不予評論。

　　近三成的【專案範疇失控】，我想這不限於BPM專案，而是各類專案通用，基本上就是得靠明確清楚的專案目標來當篩子，把必要與非必要事項的輕重緩急給釐清並加以取捨。若是不知取捨，如前面BSC的例子所提，為避免得罪人便對所有人的意見都予以考慮以求『萬全』，那結果自是包山包海越包越多最後導致失控。

　　而【缺乏制度與配套措施導致使用率偏低】，如上所述對於流程的『管理』很可能會使得原本不用被管/管不到的地方攤在陽光下，即便沒有私心因素，光是作業/操作習慣的改變便能讓許多人不願意配合。好比習慣吃燒餅油條當早餐的人，雖知吃漢堡三明治當早餐可能更營養也很可口，可是因為積習難改與個人口味等因素便不願意開始嚐試。而所謂的制度與配套措施諸如：高階主管表態不簽紙本只認電子單據、不走流程不認績效、走電子流程者可提早領款或優先book 庫存…etc也就是利用各種機制強迫/引誘使用者使用系統，讓吃慣燒餅油條的人即便不情願也只能逐漸習慣漢堡三明治。至於哪些措施可用就得看公司高層願意挺到哪種程度與企業文化而定了。

　　【業務案例不足】與【低估將業務流程轉換成系統化流程資訊的工夫】其實都與【低估了流程與組織的複雜度】相關，就不多費篇幅。

　　【因為設計或實作不當導致使用者接受度低】多是因為需求訪談時未將其他地區的相關業務負責人納入，需求確認後又未對這些負責人進行差異說明，如此對於未參與的業務人員而言自是＂設計或實作不當＂。

　　總的來說對於BPM而言由於各種業務流程的變異性與地域差異性往往較標準化程度較高的OA流程來得複雜許多，是以導入BPM的單位若以導入Wf的經驗(也就是OA流程的經驗)來導BPM，一定會在跨組織跨部門的意見統整上吃到不少非預期的苦頭。如何找到能統整意見、有彈性、有肩膀且與各意見領袖及決策者溝通良好的關鍵使用者來當『流程需求負責人』（不見得是負責專案內的所有流程，而是負責其所熟悉的業務流程），對於業務流程的推導順利與否會有很大差異。丟給技術單位閉門造車的系統建構方式，對於BPM系統而言要成功的困難度是相當高的，因為大部份技術人員的專長是與系統溝通而非與人溝通。但企業的『業務流程』往往是需要大量與業務單位溝通才能釐清的，而這樣的水磨功夫與能力通常不是企業內的技術單位能單獨承擔的。

由AIIM的一篇BPM調查談起

　　引起我注意的是這篇報導，雖然AIIM的詳細報告要到十月才會公佈，不過該篇報導提及的幾個數據還是引起了我的注意。

　　內文摘要：在本年八月AIIM針對超過三百家企業所做的調查中顯示，雖然87%的受訪企業同意BPM流程要能成功實施，明確的歸屬（ownership）是必要的。但結果顯示57%的企業並沒有負責BPM相關規劃的專責單位。至於有專責主管（CPO，Chief Process Officer）的更是只有10%。AIIM會在9月26日舉辦一場網路說明會，有興趣的到這。至於完整的書面報導，請到這登記後，十月正式出爐時將會收到通知。

　　讀完這一篇報導，讓我聯想起了另一篇報導，標題是【非技術層面問題 實施SOA失敗十大原因】。與BPM相比，SOA是技術味濃得多的東西尚且如此，若企業也僅是把BPM當作一個IT專案來推行，以為丟預算給IT去負責就行，而沒有明確定出business上的ownership，那想要BPM對企業產生顯著而持續性的效益只怕是緣木求魚。

　　其實國外一堆分享BPM成功經驗的文章都不斷重覆指出BPM能成功的關鍵前幾大因素從來不是技術。(國內的一些文章乃至論文仍將部份技術尤其是整合技術列為成功重點，個人認為這是因為對BPM成熟度的認知國內外還有落差，國內仍在努力嚐試擺脫Workflow的包袱所以還會提出一些技術門檻來過濾披著BPM外衣的Workflow。至於國外已過了這個階段所以就不需再特意提到這些技術層面的問題。)　不過對比AIIM在美國所做的調查尚且如此，國內沒有體認到BPM要成功的精隨不在技術而在流程ownership的當會更多。

　　從企管導入的觀點，BPM其實有點類似BSC，BSC的精髓是策略管理與實施，可是企業若僅是以導入資訊系統的角度來導入BSC，掛在BSC最上面幾層的公司策略目標萬年不變，那BSC就成了單純的考核工具甚至工時系統而已，雖不至完全沒有效益，但與理想相比可就差得多了。

　　BPM也是類似，若僅以導入資訊系統的角度來導入BPMS，那你得到的將只是一個電子化流程系統而非商業流程管理系統。對業務流程而言BPMS是工具而非解答，流程電子化不等於流程合理化或就是可管理的流程，這種認知對於BPM的最終成效將有重大影響。

　　你能請一流的廚房裝修師傅來將老舊廚房裝修為現代化的科技廚房，可是要能端出一流料理需要的還是廚師而不是裝修師傅。裝修師傅能使上力的是憑藉其各種不同廚房的裝修經驗來與可能一輩子待在同一個廚房的廚師討論各種可能性，從而便利與改善廚師的工作環境與效率。至於要如何煮出一盤好菜，裝修師傅耳濡目染下或許能背出幾道食譜，但要是他真的很會作菜，除非因為興趣差異那不如改行當廚師。

　　同理BPM顧問的優勢是因著輔導多家不同企業所累積的不同視角廣度與有機會以旁觀者清的邏輯化思考來提出一些企業內或許因為太過習以為常而不覺有異的新問題與方向。要比深度每個人一天都是24小時，專注於單一企業內狀況的主管絕對比外部顧問有深度。只要內部業務主管有足夠的開放心胸來接受新的視野角度，配合本身對問題的深度理解來加以過濾與內化，便很有可能會發現新機會來改善既有流程。光靠外部顧問或是技術人員，是很難有足夠深度來搔到真正的癢處。

　　而業務主管除了要有開放心胸外也要有時間與意願來進行思考與內化的工作，而這個時間與意願的來源就是ownership。當ownership明確，業務主管才會調整工作的priority來與之匹配。若是ownership不清或是認為是別人（IT）的責任，那大多數人忙既有工作都來不及了，抓來開會時臨時反應提供經驗還沒問題，少有會自己額外花時間先深入思考與準備後再與會的。同時聽取顧問意見後，回去也不見得會真的進行思考與討論，反正最方便的答案永遠是目前的現狀（as-is）如何。至於未來（to-be）可如何調整，既然變動總是跟隨著未知的風險，大多數情況下風險能不由自己承擔自然是不要強出頭的好。
　　
　　由一篇報導臨時有感而發，後續等十月詳細報告出爐後視狀況再跟各位報告吧。

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專案時，應該需要具備的一些觀念。雖然其實還能繼續往下列，不過多了也不會記得所以還是遵照重點管理的建議以不超過五點為原則，希望有所幫助。