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系統而言要成功的困難度是相當高的，因為大部份技術人員的專長是與系統溝通而非與人溝通。但企業的『業務流程』往往是需要大量與業務單位溝通才能釐清的，而這樣的水磨功夫與能力通常不是企業內的技術單位能單獨承擔的。
2009年4月2日 星期四
由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）可如何調整，既然變動總是跟隨著未知的風險，大多數情況下風險能不由自己承擔自然是不要強出頭的好。
由一篇報導臨時有感而發，後續等十月詳細報告出爐後視狀況再跟各位報告吧。
內文摘要：在本年八月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）可如何調整，既然變動總是跟隨著未知的風險，大多數情況下風險能不由自己承擔自然是不要強出頭的好。
由一篇報導臨時有感而發，後續等十月詳細報告出爐後視狀況再跟各位報告吧。
2009年4月1日 星期三
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專案時，應該需要具備的一些觀念。雖然其實還能繼續往下列，不過多了也不會記得所以還是遵照重點管理的建議以不超過五點為原則，希望有所幫助。
流程管理目標：
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專案時，應該需要具備的一些觀念。雖然其實還能繼續往下列，不過多了也不會記得所以還是遵照重點管理的建議以不超過五點為原則，希望有所幫助。
BPM如何與BI結合?
BPM（在此指的是Business Process Management而非早期較常被BI提及的Business Performance Management）與BI（Business Intelligence），這兩個開宗明義由名稱上便都以『Business』領頭的系統，名號雖不如車業的雙B閃亮，不過這資訊雙B彼此的關係就是本次的主題。
在某種意義上BPM與BI都可算是『非原生資料』的系統，也就是它們的主要/主檔資料應該是由其他專業系統如ERP、CRM、SCM等所管理，BPM與BI則是利用這些原生資料來產生出更高階商業行為所需要的衍生性資料。
如一個客戶下單的商業流程，可能其內的客戶資料與交貨地點來自CRM、料號與付款條件來自ERP…etc。經由交易的一連串業務流程程序最後再將確定的數量與交期回饋到MRP內產生製造排程與利潤預估等或是回饋到SCM進行購料。
BI就更明顯了，無論是哪一類的BI(BI實作上的大致範籌請看IDC的報告)都要有數據才能分析，而數據的來源則是資料倉儲。資料倉儲的來源與甘苦在杜資訊長的相關文章中已有生動描述，我就不再野人獻曝。
兩個說難聽點都得『靠別人』的系統要如何彼此結合呢？就企業的業務面上來看其實機會還真不少：
先從『BPM利用BI資料』的角度來看：一個企業的業務流程在運行中本就會有許多的【決策點】，當流程流到某個決策者時一般只能依靠手邊的既有資料來做決定。比方前述的客戶下單，業務主管大概主要是憑藉其對這個客戶的『印象』（雖然好企業不見得是好客戶）、數量、單價與成本來決定要不要同意這筆訂單。但若有BI則或許就能將資料轉為更有價值的資訊來給相關主管參考，如：業務主管可看到該商品既有不同客戶的利潤比（也許議價不同也許運輸與付款條件不同，在基層業務員層級因為所負責的客戶不同與彼此的競爭關係一般不允許看到這類資訊）與該客戶近期下單的趨勢圖甚至改/退單的頻率等…etc協助決定是否應保留庫存給更有利的交易/更好的客戶還是應該即使同業調貨也要滿足該客戶需求。而生產主管則可參照該商品價格與原料/共用料成本的近期升降趨勢等決定若原料吃緊時是要接下這單的生產還是將該共用料保留給更有利潤的產品生產之用。這些BI資訊其實都可透過BPM嵌在流程中特定簽核關卡的簽核表單之內，而且嵌入的不是單純BI平台的連結而是經過分析，在這個流程的這個管卡所需要的相關特定BI報告。
也就是一方面BPM利用BI來提升在商業流程中各階段的決策品質，另一方面BI則利用BPM來『安排演出機會』，讓BI分析出的資料能在主管需要的適當時機主動出場（顯示於電子表單上）而不致淪為空有花容月貌但卻庭院深深無人知曉的寂寞佳人，或是主管雖知道有後宮BI佳麗三千但當需要時卻不知該找哪一個BI提供岀的分析圖表才是目前需要的關鍵那一個。
再來從『BI依靠BPM資料』的角度來看：如電子流程進行中所收集的各關卡執行時間、退回件數、修正件數等可轉化分析出企業流程的可能瓶頸或無效關卡（從沒意見的橡皮圖章）所在，從而針對瓶頸進行分析改進，去化無效關卡來改善企業效能。也能由人員角度來由人員的工作量（執行件數）、無效申請（退回、撤回件數）等來分析員工可能需要的協助、分工、訓練等，提升員工表現從而間接增進企業績效。
也就是一方面BI利用BPM所收集到的資料來進行原本不易進行的商業分析，但BPM其實也藉著BI的分析能力來達到BPM的進階目標：持續的流程優化。
看到這讀者該也發現說來說去不管是哪一種的合作方式其實都不是單純的誰利用誰，較正確的說法應該是：「已先有BI再導入BPM時能合作的方式」與「已先導入BPM才導入BI時能合作的方式」但兩者的結果其實都是互利也就是能同時提升彼此的系統成效，這也就是標題之所以用『結合』這個詞的緣故了。
至於有些把BPM跟BI結合成所謂的『BPI』(指Business Process Intelligence，非Business Process Improvement也非其他BPI)，這個性質上偏向上述第二種合作方式(BI用BPM資料來分析)的升級版(國外有些調性較高者則更是將BPI推向了類似Business Process AI的領域，由於實務上與期望還有一段距離，這就先不多花篇幅討論)，有興趣的可參考這篇，也是目前大多數號稱內含BI能力的BPM廠商主要著眼的方向。不過個人認為撇開供應商的角度(目前BPM廠商對如何利用BI比較有想法，BI廠商則較少有想到連結Business Process Management的)，就企業來說第一種的合作方式或許能較快展現BPM與BI結合的成效且能讓企業對系統產生較多『快感』。
在某種意義上BPM與BI都可算是『非原生資料』的系統，也就是它們的主要/主檔資料應該是由其他專業系統如ERP、CRM、SCM等所管理，BPM與BI則是利用這些原生資料來產生出更高階商業行為所需要的衍生性資料。
如一個客戶下單的商業流程，可能其內的客戶資料與交貨地點來自CRM、料號與付款條件來自ERP…etc。經由交易的一連串業務流程程序最後再將確定的數量與交期回饋到MRP內產生製造排程與利潤預估等或是回饋到SCM進行購料。
BI就更明顯了，無論是哪一類的BI(BI實作上的大致範籌請看IDC的報告)都要有數據才能分析，而數據的來源則是資料倉儲。資料倉儲的來源與甘苦在杜資訊長的相關文章中已有生動描述，我就不再野人獻曝。
兩個說難聽點都得『靠別人』的系統要如何彼此結合呢？就企業的業務面上來看其實機會還真不少：
先從『BPM利用BI資料』的角度來看：一個企業的業務流程在運行中本就會有許多的【決策點】，當流程流到某個決策者時一般只能依靠手邊的既有資料來做決定。比方前述的客戶下單，業務主管大概主要是憑藉其對這個客戶的『印象』（雖然好企業不見得是好客戶）、數量、單價與成本來決定要不要同意這筆訂單。但若有BI則或許就能將資料轉為更有價值的資訊來給相關主管參考，如：業務主管可看到該商品既有不同客戶的利潤比（也許議價不同也許運輸與付款條件不同，在基層業務員層級因為所負責的客戶不同與彼此的競爭關係一般不允許看到這類資訊）與該客戶近期下單的趨勢圖甚至改/退單的頻率等…etc協助決定是否應保留庫存給更有利的交易/更好的客戶還是應該即使同業調貨也要滿足該客戶需求。而生產主管則可參照該商品價格與原料/共用料成本的近期升降趨勢等決定若原料吃緊時是要接下這單的生產還是將該共用料保留給更有利潤的產品生產之用。這些BI資訊其實都可透過BPM嵌在流程中特定簽核關卡的簽核表單之內，而且嵌入的不是單純BI平台的連結而是經過分析，在這個流程的這個管卡所需要的相關特定BI報告。
也就是一方面BPM利用BI來提升在商業流程中各階段的決策品質，另一方面BI則利用BPM來『安排演出機會』，讓BI分析出的資料能在主管需要的適當時機主動出場（顯示於電子表單上）而不致淪為空有花容月貌但卻庭院深深無人知曉的寂寞佳人，或是主管雖知道有後宮BI佳麗三千但當需要時卻不知該找哪一個BI提供岀的分析圖表才是目前需要的關鍵那一個。
再來從『BI依靠BPM資料』的角度來看：如電子流程進行中所收集的各關卡執行時間、退回件數、修正件數等可轉化分析出企業流程的可能瓶頸或無效關卡（從沒意見的橡皮圖章）所在，從而針對瓶頸進行分析改進，去化無效關卡來改善企業效能。也能由人員角度來由人員的工作量（執行件數）、無效申請（退回、撤回件數）等來分析員工可能需要的協助、分工、訓練等，提升員工表現從而間接增進企業績效。
也就是一方面BI利用BPM所收集到的資料來進行原本不易進行的商業分析，但BPM其實也藉著BI的分析能力來達到BPM的進階目標：持續的流程優化。
看到這讀者該也發現說來說去不管是哪一種的合作方式其實都不是單純的誰利用誰，較正確的說法應該是：「已先有BI再導入BPM時能合作的方式」與「已先導入BPM才導入BI時能合作的方式」但兩者的結果其實都是互利也就是能同時提升彼此的系統成效，這也就是標題之所以用『結合』這個詞的緣故了。
至於有些把BPM跟BI結合成所謂的『BPI』(指Business Process Intelligence，非Business Process Improvement也非其他BPI)，這個性質上偏向上述第二種合作方式(BI用BPM資料來分析)的升級版(國外有些調性較高者則更是將BPI推向了類似Business Process AI的領域，由於實務上與期望還有一段距離，這就先不多花篇幅討論)，有興趣的可參考這篇，也是目前大多數號稱內含BI能力的BPM廠商主要著眼的方向。不過個人認為撇開供應商的角度(目前BPM廠商對如何利用BI比較有想法，BI廠商則較少有想到連結Business Process Management的)，就企業來說第一種的合作方式或許能較快展現BPM與BI結合的成效且能讓企業對系統產生較多『快感』。
BPM的世界觀：從ERP-centric的BPM有何不足?
在以IT製造業著稱的台灣，經由十餘年來的推廣，ERP已然成為企業級資訊軟體的主流旗艦，由許多大專院校均可看到相關專門課程便可看出ERP受重視的程度。
也由於ERP的普及性與基礎性，使得ERP在各企業內有了一個很有利的立足點，而依據這個立足點，各ERP大廠也莫不致力於設法跨大自己的版圖。最明顯的莫如Oracle近年來連串的併購動作(筆者過去曾接觸的Siebel、PeopleSoft、BEA均先後被併，中籤率還真不低)。
而隨著BPM需求的提升，各ERP大廠自也不會放過這個商機而紛紛切入BPM市場：Oracle併購了Collaxa後推出Oracle BPEL Process Manager，SAP則是強調BPM的精神一直存在於SAP內並推出SAP Exchange Infrastructure (XI)。
綜觀各種條件，ERP廠商實在是有著相當不錯的先天條件，畢竟依據Shtub對ERP下的定義：「ERP是一個單一的資訊系統，這個資訊系統提供一個整合的資料庫及精緻的模式庫來支援組織的所有流程。」所以處理流程對ERP來說幾乎可以說是天職。只不過ERP套裝軟體雖然宣稱具有相當的彈性與強大的功能，但卻難以滿足所有企業在流程與功能上的需求，因此多數的企業在導入ERP系統時仍必須面對到底要修改ERP系統來配合企業流程還是修改企業流程來配合ERP系統的課題。
關於這點業界普遍認為企業級的套裝軟體（這裡主要指如ERP、HR、CRM等對一般使用人員有一定操作順序的系統，而不含平台類如Portal、DW、DB等）它的價值是在流程而不是技術，因為其內建的business process都是軟體公司找顧問設計出來的best practice(當套裝軟體成了變形金剛)。而依據前進國際的ERP導入經驗：該公司客戶沒有一個不經過客製化。但國內企業排得上全球五百大的寥寥無幾，「如果你是台積電或巨大機械（捷安特製造商），我們相信我們軟體應該為你大幅修改；」他說，「但如果你不是，那有多少理由相信你的流程是獨特而有價值的呢？」一旦修改過大，也就失去了導入ERP的原意 (ERP導入必然顧人怨?)。
另一派則認為套裝軟體的這些限制主要是為了方便軟體供應商能大量重複銷售之用（Customer 2.0）。這一方面是軟體供應商本身的商業考量，另一方面則是市場需求。即便如台積、聯電這般的大企業在導入時也免不了常常會問：「別家是怎麼做的？」供應商自然需要彙總出所謂Best Practice來滿足這類的諮詢需求。另一方面企業越來越沒耐心、要求速效也是因素。由大前研一著作中可窺知早期企管顧問在輔導客戶時可是得經歷對該企業相當份量的實地探訪後才會開始給出建議要採取哪些措施。而今企業則是先決定是要導入BSC(平衡計分卡)、6σ、ISO、ABC…etc後才找顧問公司來像上課一般的實施導入。連企管顧問都得順應市場標準化、模組化了，又怎能說是因為資訊公司存心不良想套Best Practice？
「到底要修改ERP系統來配合企業流程還是修改企業流程來配合ERP系統？」就我來看是個假議題，真正核心的議題應是更早一步的「該買套裝軟體還是自行開發?」或是晚一些的「該買哪一家套裝軟體？」。而不是等到購入特定ERP了才來煩惱要改多少。
就好比以情人節大餐為例，第一步要決定的是要自己在家搞燭光晚餐還是出去吃，若決定要出去吃那第二步才是決定要去哪吃、吃什麼。而非不管三七二十一先衝到了王品牛排卻硬要廚房給你搞個羊肉爐出來。當然肯不惜成本用錢砸也不見得不行啦，不過何苦呢？結果就是花了幾倍的錢請一個可能根本沒煮過羊肉爐的大廚來做羊肉爐而且原料與廚具都不對，雖是一流的大廚但那羊肉爐的滋味除了國王的新衣效應外只怕沒啥值得稱道。(不過這點業者的業務手段也需要負點責任，畢竟王品的業務不會在客戶於門外詢問羊肉爐時回應想吃啥都沒問題，先進門再說。)
前面離題拉拉雜雜談了一堆主要是要說明下面回歸主題所提的一些狀況不見得是ERP套裝軟體的問題而是目前觀察到部分導入ERP企業的現象。同樣的現象在國外或在不同企業導入ERP時不見得會發生。
首先比較明顯的是ERP的發展歷程是由MRP起家，因此先天較注重的就是如何確保有足夠的資料來支持產生一個可供信賴的MRP排程，較注重後台骨幹的事務系統角色，如：穩定、資料保存與尤其是資料運算。其傳統的操作前提也是認定凡輸入ERP的資料均為具有相當可信度的低變動性資料--資料必須要可靠才能算出可信的排程，否則工廠的排程可就天下大亂。這也是為啥直覺上一個簡單的修改訂單動作到了ERP可能就得一路迴轉好幾個程序才能達成。也因著這樣的傳統，因此ERP先天認為資料的確認是在登打入系統前就應完成的動作，故傳統上早期ERP設計的目標操作人員就不是一般人員而是專業的事務人員。
由於ERP起初是設計給專業的事務人員使用，且功能實在眾多加上由於其龐大的資料量與資料複雜度，造成了操作複雜度超出一般可直覺化操作的範圍，因此對一般使用者的接受度向來不高。最明顯就是雖然ERP本身就有相當強大與準確的各式報表，但幾乎沒有哪家企業的哪一層主管會自己進ERP看報表的（會計與資訊單位是異數），一般都是由助理或是會計、資訊單位來代勞。同理要一般主管進ERP系統進行各種查詢與審核也滿困難的。這方面ERP廠商企圖透過web化或說portal化介面的方式來改善已有一段時日，但革命顯然尚未成功。這可說為了滿足發展歷程中各種特殊的需求而陸續加入的功能太多太龐大，一方面還沒抓到sweet point，一方面捨不得放棄既有功能，有點類似在i-phone面市前的各種高階手機：功能一支比一支強，對於真正懂得如何使用的人確實十分方便，但對於大多數人而言卻是太過複雜、難以使用而無法形成足夠使用誘因。
再來則是ERP由於模組分工精細，資料龐大，各種的權限控管也因此複雜化。最傳統的控管方式就是一次登入一個模組，若要參考其他模組的資料就得跳出原模組後再重新進入新模組 (這可曾是國外EIP好一段時間的商機所在)。以流程的觀點來看所造成的不便就好比當你跟人以email聯絡時，得在第一個專用信箱發信，但當對方回信時卻是回到另一個第二信箱而你登入並於第二信箱回覆對方後，當對方再度回信卻又是回到另一個第三信箱於是你得登入並於第三信箱回覆…etc。不同的信箱(模組)專門負責收不同階段(status)的信件，而不是在單一信箱便可綜觀全局處理完所有的事。以國外專業化分工的觀點，一個專業部門的操作人員應僅負責單一專業事務故只專門處理單一信箱（模組）的工作沒啥不便。但對於分工沒到那細的企業而言，可能一人身兼幾個步驟或是需具有跨部門視野的較高階主管而言，要追蹤流程綜觀全局就相當的不便。
此外如前所述ERP先天注重的是資訊流（Data flow、Information flow）的查驗與計算。業務流程（Business flow）上的決策行為、行動計畫等並非其關注的領域。而系統上的決策行為與行動計畫就又牽扯到國內、外管理思維的不同。國外尤其是美國、西歐等國，習慣【自動化】的管理思維，也就是將邏輯交給系統管，符合規定的就系統按照SOP（標準作業程序）進行，不合規定的就直接擋掉，也不用啥主管來參與審核或是擬定行動計畫了，因此也就不用啥人工簽核與主管參與了。主管負責的是更策略性、規劃性、決策性、領導性的工作而非批准假單、訂單、採購單這些事。但在國內與東亞、南歐等地區則不是如此運作的。無法擺脫圖章文化是一個因素，還有就是對於【規則】的不信任，或是說思想比較「活」，不想被規則綁死。於是國外按規則來辦不敢接的單台灣硬是有辦法先接下後再想辦法獲利，這樣的彈性與經營模式也是台灣電子業成功的因素之ㄧ。不過為了能保持彈性，許多事就無法用系統邏輯定死，只能以人工判斷的方式來執行。而這樣的管理思維差異也使得以【自動化】為起點發展之ERP的流程概念要應用到國內就顯得不太適合。（註）
而當一家公司願意投入資源來改善以上情況，先不管較難處理的後端流程邏輯，光以直覺上應該較單純的UI介面要客製也多比一般人預期的難。主要是各家ERP都有自己獨家的特化程式語言與上段提及的權限問題及各種相依資料之防呆查驗等所造成的相互影響往往遠比一開始所能預料到的複雜得多。而且更慘的是當ERP要升級時，這些客製的部分往往不保證能正常運作。是以不少企業可都有著ERP升級比導入反花了更高成本的經驗。既便不談升級，當運行期間發生問題時，國外原廠往往是不支援的，不少原廠support網站可都明寫著：只接受能在OOB安裝(Out of box即產品最初乾淨未經客製的安裝)上重現的問題，其他問題請按照顧問標準收費。
上述這些ERP的限制是目前企業在應用ERP時可能遇到的問題，而目前ERP相關國外領導廠商所提出的BPM解決方案主要偏重解決自家模組間的流程整合與彈性調整為主，也較偏向前述自動化的面向，這個發展也是順著國外【自動化】思維的需求所產生。除上述如使用者介面等缺點外，ERP憑藉其超重量級的壓倒性優勢地位，長久以來對其本身與外部系統間的整合方案一直不是十分熱衷（由傳統ERP廠商觀點又何必費力去整合外部系統呢？用功能相仿的自家ＸＸ模組來替代該外部系統不是更好更有利？是以才會不斷的擴充新模組新功能，期望能達到所謂的Total solution），因此與外部系統的整合是另一個目前由ERP廠商所提出的BPM解決方案上著墨較少的部份。這部分隨著SOA風潮吹入ERP領域或許可有相當的改善幅度，不過至少還得等一段時日便是。
最後要提的是雖理想上一個良好的BPM系統可以：
* 補強ERP所不cover的業務流程與外部流程。
* 以流程的觀點將所有事項集中在統一的使用者介面。
* 以客製簡化的審核畫面來取代ERP過於複雜的操作頁面。
* 跨越模組限制將所需資料一次一體呈現。
不過也有其主要限制如：
* 無法違反ERP模組內的基本流程。比如ERP就是要先有訂單才能出貨，用了BPM也無法逼ERP先出貨了再補訂單。
* 難以涵蓋所有ERP複雜的檢核規則。結果就是於外部系統產生的資料不見得能完全通過ERP的檢核成功匯入ERP。解法一是輸入畫面維持於ERP輸入，待ERP檢核通過正確再將業務所需資訊傳給BPM進行業務流程。不然就是ERP廠商大發慈悲提供相對應的完整web service給外部系統先行套用相同規則檢核。
這兩點主要限制也是需要讓各位知道的，免得對於用BPM來改善ERP有著過多的期待。
註：
延續工業革命產線自動化的思維將管理也納入自動化的範圍理論上可將規範透明化、風險數據化並節省經理人的寶貴資源。不過資訊業最慘烈的案例當是SCM由景氣上揚時紅極一時的市場寵兒到景氣下滑時被歸咎為造成庫存惡化人人喊打的元兇。系統做的也僅是依照預設的邏輯來產生預估並向上游與工廠自動下訂單。邏輯都是建立在一定的前提下的，當前提成立，自動化可節省不少事。但是一旦前提在不知不覺中變易了，那自動化產出的成果就可能差距甚遠而造成巨大（庫存）損失了。古人說：「盡信書不如無書」，套到現代或許也可說盡信系統不如無系統吧。連下西洋棋這般有固定規則可循的事都得動用超級電腦出面還無法保證必勝不敗。變動更為無跡可尋的企業治理，以有限的資訊預算想要能造出十全十美的資訊系統就顯得不切實際了。好比股票追求的是合理的本益比，資訊系統也是。十全十美的系統固然難求，但要解決一些符合二八法則的例行事務與資料處理則還是綽綽有餘也可展現相當效益的。
也由於ERP的普及性與基礎性，使得ERP在各企業內有了一個很有利的立足點，而依據這個立足點，各ERP大廠也莫不致力於設法跨大自己的版圖。最明顯的莫如Oracle近年來連串的併購動作(筆者過去曾接觸的Siebel、PeopleSoft、BEA均先後被併，中籤率還真不低)。
而隨著BPM需求的提升，各ERP大廠自也不會放過這個商機而紛紛切入BPM市場：Oracle併購了Collaxa後推出Oracle BPEL Process Manager，SAP則是強調BPM的精神一直存在於SAP內並推出SAP Exchange Infrastructure (XI)。
綜觀各種條件，ERP廠商實在是有著相當不錯的先天條件，畢竟依據Shtub對ERP下的定義：「ERP是一個單一的資訊系統，這個資訊系統提供一個整合的資料庫及精緻的模式庫來支援組織的所有流程。」所以處理流程對ERP來說幾乎可以說是天職。只不過ERP套裝軟體雖然宣稱具有相當的彈性與強大的功能，但卻難以滿足所有企業在流程與功能上的需求，因此多數的企業在導入ERP系統時仍必須面對到底要修改ERP系統來配合企業流程還是修改企業流程來配合ERP系統的課題。
關於這點業界普遍認為企業級的套裝軟體（這裡主要指如ERP、HR、CRM等對一般使用人員有一定操作順序的系統，而不含平台類如Portal、DW、DB等）它的價值是在流程而不是技術，因為其內建的business process都是軟體公司找顧問設計出來的best practice(當套裝軟體成了變形金剛)。而依據前進國際的ERP導入經驗：該公司客戶沒有一個不經過客製化。但國內企業排得上全球五百大的寥寥無幾，「如果你是台積電或巨大機械（捷安特製造商），我們相信我們軟體應該為你大幅修改；」他說，「但如果你不是，那有多少理由相信你的流程是獨特而有價值的呢？」一旦修改過大，也就失去了導入ERP的原意 (ERP導入必然顧人怨?)。
另一派則認為套裝軟體的這些限制主要是為了方便軟體供應商能大量重複銷售之用（Customer 2.0）。這一方面是軟體供應商本身的商業考量，另一方面則是市場需求。即便如台積、聯電這般的大企業在導入時也免不了常常會問：「別家是怎麼做的？」供應商自然需要彙總出所謂Best Practice來滿足這類的諮詢需求。另一方面企業越來越沒耐心、要求速效也是因素。由大前研一著作中可窺知早期企管顧問在輔導客戶時可是得經歷對該企業相當份量的實地探訪後才會開始給出建議要採取哪些措施。而今企業則是先決定是要導入BSC(平衡計分卡)、6σ、ISO、ABC…etc後才找顧問公司來像上課一般的實施導入。連企管顧問都得順應市場標準化、模組化了，又怎能說是因為資訊公司存心不良想套Best Practice？
「到底要修改ERP系統來配合企業流程還是修改企業流程來配合ERP系統？」就我來看是個假議題，真正核心的議題應是更早一步的「該買套裝軟體還是自行開發?」或是晚一些的「該買哪一家套裝軟體？」。而不是等到購入特定ERP了才來煩惱要改多少。
就好比以情人節大餐為例，第一步要決定的是要自己在家搞燭光晚餐還是出去吃，若決定要出去吃那第二步才是決定要去哪吃、吃什麼。而非不管三七二十一先衝到了王品牛排卻硬要廚房給你搞個羊肉爐出來。當然肯不惜成本用錢砸也不見得不行啦，不過何苦呢？結果就是花了幾倍的錢請一個可能根本沒煮過羊肉爐的大廚來做羊肉爐而且原料與廚具都不對，雖是一流的大廚但那羊肉爐的滋味除了國王的新衣效應外只怕沒啥值得稱道。(不過這點業者的業務手段也需要負點責任，畢竟王品的業務不會在客戶於門外詢問羊肉爐時回應想吃啥都沒問題，先進門再說。)
前面離題拉拉雜雜談了一堆主要是要說明下面回歸主題所提的一些狀況不見得是ERP套裝軟體的問題而是目前觀察到部分導入ERP企業的現象。同樣的現象在國外或在不同企業導入ERP時不見得會發生。
首先比較明顯的是ERP的發展歷程是由MRP起家，因此先天較注重的就是如何確保有足夠的資料來支持產生一個可供信賴的MRP排程，較注重後台骨幹的事務系統角色，如：穩定、資料保存與尤其是資料運算。其傳統的操作前提也是認定凡輸入ERP的資料均為具有相當可信度的低變動性資料--資料必須要可靠才能算出可信的排程，否則工廠的排程可就天下大亂。這也是為啥直覺上一個簡單的修改訂單動作到了ERP可能就得一路迴轉好幾個程序才能達成。也因著這樣的傳統，因此ERP先天認為資料的確認是在登打入系統前就應完成的動作，故傳統上早期ERP設計的目標操作人員就不是一般人員而是專業的事務人員。
由於ERP起初是設計給專業的事務人員使用，且功能實在眾多加上由於其龐大的資料量與資料複雜度，造成了操作複雜度超出一般可直覺化操作的範圍，因此對一般使用者的接受度向來不高。最明顯就是雖然ERP本身就有相當強大與準確的各式報表，但幾乎沒有哪家企業的哪一層主管會自己進ERP看報表的（會計與資訊單位是異數），一般都是由助理或是會計、資訊單位來代勞。同理要一般主管進ERP系統進行各種查詢與審核也滿困難的。這方面ERP廠商企圖透過web化或說portal化介面的方式來改善已有一段時日，但革命顯然尚未成功。這可說為了滿足發展歷程中各種特殊的需求而陸續加入的功能太多太龐大，一方面還沒抓到sweet point，一方面捨不得放棄既有功能，有點類似在i-phone面市前的各種高階手機：功能一支比一支強，對於真正懂得如何使用的人確實十分方便，但對於大多數人而言卻是太過複雜、難以使用而無法形成足夠使用誘因。
再來則是ERP由於模組分工精細，資料龐大，各種的權限控管也因此複雜化。最傳統的控管方式就是一次登入一個模組，若要參考其他模組的資料就得跳出原模組後再重新進入新模組 (這可曾是國外EIP好一段時間的商機所在)。以流程的觀點來看所造成的不便就好比當你跟人以email聯絡時，得在第一個專用信箱發信，但當對方回信時卻是回到另一個第二信箱而你登入並於第二信箱回覆對方後，當對方再度回信卻又是回到另一個第三信箱於是你得登入並於第三信箱回覆…etc。不同的信箱(模組)專門負責收不同階段(status)的信件，而不是在單一信箱便可綜觀全局處理完所有的事。以國外專業化分工的觀點，一個專業部門的操作人員應僅負責單一專業事務故只專門處理單一信箱（模組）的工作沒啥不便。但對於分工沒到那細的企業而言，可能一人身兼幾個步驟或是需具有跨部門視野的較高階主管而言，要追蹤流程綜觀全局就相當的不便。
此外如前所述ERP先天注重的是資訊流（Data flow、Information flow）的查驗與計算。業務流程（Business flow）上的決策行為、行動計畫等並非其關注的領域。而系統上的決策行為與行動計畫就又牽扯到國內、外管理思維的不同。國外尤其是美國、西歐等國，習慣【自動化】的管理思維，也就是將邏輯交給系統管，符合規定的就系統按照SOP（標準作業程序）進行，不合規定的就直接擋掉，也不用啥主管來參與審核或是擬定行動計畫了，因此也就不用啥人工簽核與主管參與了。主管負責的是更策略性、規劃性、決策性、領導性的工作而非批准假單、訂單、採購單這些事。但在國內與東亞、南歐等地區則不是如此運作的。無法擺脫圖章文化是一個因素，還有就是對於【規則】的不信任，或是說思想比較「活」，不想被規則綁死。於是國外按規則來辦不敢接的單台灣硬是有辦法先接下後再想辦法獲利，這樣的彈性與經營模式也是台灣電子業成功的因素之ㄧ。不過為了能保持彈性，許多事就無法用系統邏輯定死，只能以人工判斷的方式來執行。而這樣的管理思維差異也使得以【自動化】為起點發展之ERP的流程概念要應用到國內就顯得不太適合。（註）
而當一家公司願意投入資源來改善以上情況，先不管較難處理的後端流程邏輯，光以直覺上應該較單純的UI介面要客製也多比一般人預期的難。主要是各家ERP都有自己獨家的特化程式語言與上段提及的權限問題及各種相依資料之防呆查驗等所造成的相互影響往往遠比一開始所能預料到的複雜得多。而且更慘的是當ERP要升級時，這些客製的部分往往不保證能正常運作。是以不少企業可都有著ERP升級比導入反花了更高成本的經驗。既便不談升級，當運行期間發生問題時，國外原廠往往是不支援的，不少原廠support網站可都明寫著：只接受能在OOB安裝(Out of box即產品最初乾淨未經客製的安裝)上重現的問題，其他問題請按照顧問標準收費。
上述這些ERP的限制是目前企業在應用ERP時可能遇到的問題，而目前ERP相關國外領導廠商所提出的BPM解決方案主要偏重解決自家模組間的流程整合與彈性調整為主，也較偏向前述自動化的面向，這個發展也是順著國外【自動化】思維的需求所產生。除上述如使用者介面等缺點外，ERP憑藉其超重量級的壓倒性優勢地位，長久以來對其本身與外部系統間的整合方案一直不是十分熱衷（由傳統ERP廠商觀點又何必費力去整合外部系統呢？用功能相仿的自家ＸＸ模組來替代該外部系統不是更好更有利？是以才會不斷的擴充新模組新功能，期望能達到所謂的Total solution），因此與外部系統的整合是另一個目前由ERP廠商所提出的BPM解決方案上著墨較少的部份。這部分隨著SOA風潮吹入ERP領域或許可有相當的改善幅度，不過至少還得等一段時日便是。
最後要提的是雖理想上一個良好的BPM系統可以：
* 補強ERP所不cover的業務流程與外部流程。
* 以流程的觀點將所有事項集中在統一的使用者介面。
* 以客製簡化的審核畫面來取代ERP過於複雜的操作頁面。
* 跨越模組限制將所需資料一次一體呈現。
不過也有其主要限制如：
* 無法違反ERP模組內的基本流程。比如ERP就是要先有訂單才能出貨，用了BPM也無法逼ERP先出貨了再補訂單。
* 難以涵蓋所有ERP複雜的檢核規則。結果就是於外部系統產生的資料不見得能完全通過ERP的檢核成功匯入ERP。解法一是輸入畫面維持於ERP輸入，待ERP檢核通過正確再將業務所需資訊傳給BPM進行業務流程。不然就是ERP廠商大發慈悲提供相對應的完整web service給外部系統先行套用相同規則檢核。
這兩點主要限制也是需要讓各位知道的，免得對於用BPM來改善ERP有著過多的期待。
註：
延續工業革命產線自動化的思維將管理也納入自動化的範圍理論上可將規範透明化、風險數據化並節省經理人的寶貴資源。不過資訊業最慘烈的案例當是SCM由景氣上揚時紅極一時的市場寵兒到景氣下滑時被歸咎為造成庫存惡化人人喊打的元兇。系統做的也僅是依照預設的邏輯來產生預估並向上游與工廠自動下訂單。邏輯都是建立在一定的前提下的，當前提成立，自動化可節省不少事。但是一旦前提在不知不覺中變易了，那自動化產出的成果就可能差距甚遠而造成巨大（庫存）損失了。古人說：「盡信書不如無書」，套到現代或許也可說盡信系統不如無系統吧。連下西洋棋這般有固定規則可循的事都得動用超級電腦出面還無法保證必勝不敗。變動更為無跡可尋的企業治理，以有限的資訊預算想要能造出十全十美的資訊系統就顯得不切實際了。好比股票追求的是合理的本益比，資訊系統也是。十全十美的系統固然難求，但要解決一些符合二八法則的例行事務與資料處理則還是綽綽有餘也可展現相當效益的。
需要ESB/SOA才能做BPM嗎?
要談這個題目，自然得解釋一下ESB/SOA。由於相關的專業文章非常多，在此僅簡單做個入門概念性的介紹。
先由知名度較高的SOA說起：SOA全名Service-Oriented Architecture。【S】指的是Enterprise Service（ERP、CRM、HR、MRP…etc）也就是企業資訊應用服務，【O】則跟另一個有名的【OO】(Object Oriented－物件導向)的第二個O相同，指的是以某某為主導取向的概念。非軟體背景對OO不了解的人則請參考這裡，有對於一般性Oriented用法的舉例解釋。【A】則是指設計架構，對土木而言是建築架構，對資訊而言就是系統架構。簡單合起來說就是以企業資訊應用為導向的系統架構，主要目的一是與當年OO類似：OO希望能透過物件化的程式設計來增進新軟體開發時程式元件模組化的程度。而模組化的好處一是讓不同開發人員所開發的程式仍能以較有效率的方式兜合起來，一是提升重複利用率(re-use)進而縮短新軟體開發所需的時間，最理想的狀況則是靠物件的【組裝】便可完成大部分的工作。而SOA的理想則是將【組裝】的對象由物件化程式的層次提升到了應用服務的層次，期望透過【服務導向的組裝概念】來最大化重複利用既有的系統服務而不用老是處理一些類似的重覆工作。這其實也不算新概念，LDAP就可算是一個已經相當成功普遍的Service-Oriented應用：不同的系統均可透過標準的LDAP介面來做登入認證，免除了各系統各自帳號與密碼管理的問題。SOA則是將層面拉大到將所有企業系統均納入相同的期望考量，希望所有的企業系統在其他系統有需要時均可透過類似LDAP一般明確公開的方式來直接取得所需的服務而不用每次都得大費周章的點對點EAI一番。且無論是哪一家軟體公司的產品，內部如何實作，開放出來供其他系統取用的服務均採用相同方式，而不再是SAP有RFC、Oracle用Store Procedure、IBM用MQ與其他不同的機制來做整合。好比現在您能瀏覽這篇文章，Google能搜尋到對的關鍵字文章乃是因為大家均是採用相同的html標準來互動。SOA想要架構的就是類似的【書同文、車同軌】的跨系統溝通世界。
ESB全名Enterprise Service Bus，顧名思義簡單說來就像園區的交通車，只是一般交通車是將乘客運輸到園區的不同站牌（公司/工廠）。而ESB的乘客是資訊（如:XML），站牌則是不同的Enterprise Service（ERP、CRM、HR、MRP…etc）。至於為何需要把資訊在不同系統間傳遞，為的自然就是要做EAI啦，好讓企業的資訊系統能更有效且準確的提供所應提供的服務（Service），這裡有些Java Open source相關的選擇資訊供有興趣者參考。
而ESB與SOA的關係由【Bus】與【Architecture】的差異就可感覺出企圖心的差異：ESB提供的是較具體較明確的運輸載具(公車)與路線，而SOA想解決的則是架構性的問題。好比在設計園區的交通網絡架構時，固定路線的交通車（小巴）是一種可考量的普遍選擇但卻不一定是唯一的選擇。對於特殊地區特殊需要的園區而言，或許地鐵、人員輸送帶、直升機等會是更好甚至是不得不的選擇。ESB注重的是架構一個可運行無礙的公車路線與站牌交通網。SOA則是除了交通網的建造外更要確保既有與未來要進駐之廠商需能符合這個交通網的交通相關規範。
由以上的簡介，對BPM已有些概念的人當可感覺出SOA的理想與BPM的部份理想其實相當接近：將各資訊平台均當作支援企業的資訊服務，而非單一平台大小通吃。不過在本質上則還是不同的：SOA是一種技術上的資訊架構方法論，BPM則是管理上的流程協調作業理念。
歷史事實是在沒有SOA之前，BPM產品就已經出現並成功應用。好比國光號不會因為高速公路封閉就因此停開，因為還有省道等替代道路可用，只不過走省道會比較慢比較耗油因此可能得調整票價與班次時間。同理沒有ESB/SOA也不會因而無法做BPM。沒有ESB/SOA則當BPM的流程需要跨系統傳遞時就需依靠較傳統的EAI方式來開發，而有了ESB/SOA則在跨系統部分的整合開發就會簡單與標準化的多。好比沒有統一的portlet標準前，EIP(Enterprise Information Portal)要顯示其他系統的訊息都得從頭客製（短則一週長則月餘），有了portlet後則只要把各系統提供的既有portlet掛到EIP上即可立即顯示（deploy與調整平均半小時）。不過好比宣稱有提供portlet的系統不見得剛好有提供所需顯示於EIP上資訊的portlet，比方某HR系統有提供組織圖、公司行事曆等的portlet，但卻不見得會提供員工修改個人資料、薪資查詢、獎懲查詢等的portlet，因此當有需求在EIP上顯示相關資訊時那只有兩個方法：一是走回老路用EAI的方式達到，另一種則是對HR系統客製新的所需的符合標準的portlet。若僅為解決單一一次性的需求，前者技術上使用直接抓DB或是iFrame的方式可能比用portlet快的多，但是若哪天換了portal或是其他系統也剛好需要，那就得重新review。
同理有了ESB/SOA也不代表剛好BPM所需要的service都已經打包好等人用。只不過有了SOA，BPM與各系統就有了比較一致統一的溝通方式，不管是web service或是ESB等，BPM導入廠商不用再得RFC、MQ、Store Procedure等不同介面樣樣精通才能取得不同系統的資訊，因此導入跨系統BPM時的導入障礙與溝通曲線會因此大幅降低。
最重要的是之前於BPM會不會引起內部革命中曾提過，Business Process Refine是BPM重要精神之ㄧ，而對一個跨系統的BPM而言，要能靈活的Refine可不是一件簡單的事。但在理想的SOA架構下，BPM是將所需的Service依照業務流程需要依序【組裝】起來，因此增加了Business Process Refine的彈性與應變效率，也讓BPM得以朝理想更接近。
先由知名度較高的SOA說起：SOA全名Service-Oriented Architecture。【S】指的是Enterprise Service（ERP、CRM、HR、MRP…etc）也就是企業資訊應用服務，【O】則跟另一個有名的【OO】(Object Oriented－物件導向)的第二個O相同，指的是以某某為主導取向的概念。非軟體背景對OO不了解的人則請參考這裡，有對於一般性Oriented用法的舉例解釋。【A】則是指設計架構，對土木而言是建築架構，對資訊而言就是系統架構。簡單合起來說就是以企業資訊應用為導向的系統架構，主要目的一是與當年OO類似：OO希望能透過物件化的程式設計來增進新軟體開發時程式元件模組化的程度。而模組化的好處一是讓不同開發人員所開發的程式仍能以較有效率的方式兜合起來，一是提升重複利用率(re-use)進而縮短新軟體開發所需的時間，最理想的狀況則是靠物件的【組裝】便可完成大部分的工作。而SOA的理想則是將【組裝】的對象由物件化程式的層次提升到了應用服務的層次，期望透過【服務導向的組裝概念】來最大化重複利用既有的系統服務而不用老是處理一些類似的重覆工作。這其實也不算新概念，LDAP就可算是一個已經相當成功普遍的Service-Oriented應用：不同的系統均可透過標準的LDAP介面來做登入認證，免除了各系統各自帳號與密碼管理的問題。SOA則是將層面拉大到將所有企業系統均納入相同的期望考量，希望所有的企業系統在其他系統有需要時均可透過類似LDAP一般明確公開的方式來直接取得所需的服務而不用每次都得大費周章的點對點EAI一番。且無論是哪一家軟體公司的產品，內部如何實作，開放出來供其他系統取用的服務均採用相同方式，而不再是SAP有RFC、Oracle用Store Procedure、IBM用MQ與其他不同的機制來做整合。好比現在您能瀏覽這篇文章，Google能搜尋到對的關鍵字文章乃是因為大家均是採用相同的html標準來互動。SOA想要架構的就是類似的【書同文、車同軌】的跨系統溝通世界。
ESB全名Enterprise Service Bus，顧名思義簡單說來就像園區的交通車，只是一般交通車是將乘客運輸到園區的不同站牌（公司/工廠）。而ESB的乘客是資訊（如:XML），站牌則是不同的Enterprise Service（ERP、CRM、HR、MRP…etc）。至於為何需要把資訊在不同系統間傳遞，為的自然就是要做EAI啦，好讓企業的資訊系統能更有效且準確的提供所應提供的服務（Service），這裡有些Java Open source相關的選擇資訊供有興趣者參考。
而ESB與SOA的關係由【Bus】與【Architecture】的差異就可感覺出企圖心的差異：ESB提供的是較具體較明確的運輸載具(公車)與路線，而SOA想解決的則是架構性的問題。好比在設計園區的交通網絡架構時，固定路線的交通車（小巴）是一種可考量的普遍選擇但卻不一定是唯一的選擇。對於特殊地區特殊需要的園區而言，或許地鐵、人員輸送帶、直升機等會是更好甚至是不得不的選擇。ESB注重的是架構一個可運行無礙的公車路線與站牌交通網。SOA則是除了交通網的建造外更要確保既有與未來要進駐之廠商需能符合這個交通網的交通相關規範。
由以上的簡介，對BPM已有些概念的人當可感覺出SOA的理想與BPM的部份理想其實相當接近：將各資訊平台均當作支援企業的資訊服務，而非單一平台大小通吃。不過在本質上則還是不同的：SOA是一種技術上的資訊架構方法論，BPM則是管理上的流程協調作業理念。
歷史事實是在沒有SOA之前，BPM產品就已經出現並成功應用。好比國光號不會因為高速公路封閉就因此停開，因為還有省道等替代道路可用，只不過走省道會比較慢比較耗油因此可能得調整票價與班次時間。同理沒有ESB/SOA也不會因而無法做BPM。沒有ESB/SOA則當BPM的流程需要跨系統傳遞時就需依靠較傳統的EAI方式來開發，而有了ESB/SOA則在跨系統部分的整合開發就會簡單與標準化的多。好比沒有統一的portlet標準前，EIP(Enterprise Information Portal)要顯示其他系統的訊息都得從頭客製（短則一週長則月餘），有了portlet後則只要把各系統提供的既有portlet掛到EIP上即可立即顯示（deploy與調整平均半小時）。不過好比宣稱有提供portlet的系統不見得剛好有提供所需顯示於EIP上資訊的portlet，比方某HR系統有提供組織圖、公司行事曆等的portlet，但卻不見得會提供員工修改個人資料、薪資查詢、獎懲查詢等的portlet，因此當有需求在EIP上顯示相關資訊時那只有兩個方法：一是走回老路用EAI的方式達到，另一種則是對HR系統客製新的所需的符合標準的portlet。若僅為解決單一一次性的需求，前者技術上使用直接抓DB或是iFrame的方式可能比用portlet快的多，但是若哪天換了portal或是其他系統也剛好需要，那就得重新review。
同理有了ESB/SOA也不代表剛好BPM所需要的service都已經打包好等人用。只不過有了SOA，BPM與各系統就有了比較一致統一的溝通方式，不管是web service或是ESB等，BPM導入廠商不用再得RFC、MQ、Store Procedure等不同介面樣樣精通才能取得不同系統的資訊，因此導入跨系統BPM時的導入障礙與溝通曲線會因此大幅降低。
最重要的是之前於BPM會不會引起內部革命中曾提過，Business Process Refine是BPM重要精神之ㄧ，而對一個跨系統的BPM而言，要能靈活的Refine可不是一件簡單的事。但在理想的SOA架構下，BPM是將所需的Service依照業務流程需要依序【組裝】起來，因此增加了Business Process Refine的彈性與應變效率，也讓BPM得以朝理想更接近。
BPM會不會引起內部革命?
要回答這個問題得先定義一下【「革命」】。就好比每個人對【「奇蹟】」的理解不同：有人可能覺得一定要是分開紅海或是行走於水上這般的明顯神蹟才算奇蹟，有人則可能覺得睜眼所見都是生命的奇蹟。
若以較嚴謹的方式如BPR（Business Process Reengineering）來定義，內部革命是「：＂對企業的業務流程作根本性的思考和徹底重建，目的是在成本、品質、服務和速度等方面取得顯著的改善，使企業能最大限度地適應以顧客、競爭、變化為特徵的現代企業經營環境。＂」（1993年，美國邁克爾·漢默（Michael Hammer）與詹姆斯·錢皮（James Champy）《公司重組：企業革命宣言》)則BPM可以是實施BPR的有利工具之ㄧ。比方藉由BPM的系統化來將BPR所省思出的新流程制度化：畢竟要改變大家久已習以為常的事來個徹底重建可不簡單，甚至容易遭到陽奉陰違希望日子久後能自然不了了之。但透過將之系統化到BPM上，則所有人自然不得不遵照系統化了的流程制度來走。且當有例外狀況時也能被監控分析是否為合理的彈性處理亦或是不當的抄小路，或是先藉由BPM系統資料來分析BPR所應優先下手的重點方向，與實施BPR後的成效比對分析來驗證重建效益。但對於原先沒有BPR想法的企業而言，或許不太可能會因為導入BPM而引起BPR，頂多是因以導入BPM為契機，讓平時忙碌到沒空檢視既有流程的經理人們有機會好好坐下來對企業運作流程進行跨部門的合理化檢視，從而發現既有蕭規曹隨作法有哪些不當之處，進而引發進行BPR的想法。
但此時除非重新劃定專案範疇與時程不然也不至於引發立即的BPR行動，畢竟除非當初導入BPM時便已規劃要實施BPR，不然要對「【業務流程作根本性的思考和徹底重建】「可不是個小改變，至少需實際經常參與專案決策委員會的層級得大概就再得上拉幾個層級。
就大部分的例子而言，BPM其實更重視Business Process Refine。Business Process Refine與BPR相同的是對現行既有商業流程的質疑與挑戰，不同的是採用漸進式的階段調整取代根本式的改革。甚至可以說 一個完整的BPM生命週期若是缺少了Business Process Refine的階段，那也就不算完整的BPM了。在這我就不特別吊掉書袋地的引經據典了(正確典故用法其實是[掉書袋],吊書袋是通俗的慣用)，簡單而言，缺少了Business Process Refine的階段，那用大家熟悉的workflow + EAI即可，不用特別冒出個讓人有點熟又不太熟的BPM出來了。以下嚐試以不同系統廠商的觀點來顯示出Wf（workflow）、EAI與BPM的差異：
譬如舉個例子來說明Wf（workflow）、EAI與BPM廠商的分野：一家企業的資訊需求招標，需求是【請假系統】，經費與期限可議且非價格標未訂。簡而言之，傳統Wf廠商提供的建議案會著重在表單的容易製作與修改及人工簽核流程的設定。但是當此請假流程最後要將資料匯入其他系統時，傳統的作法是流程最後一關通知打單小姐，請打單小姐手動轉key入異質系統如差勤系統、薪資系統等。在簽核流程方面也多是目前紙本如何傳遞就照著設定，不會多事調整既有流程。所以一來會出現是異質系統間資料靠手動轉key的偏高錯誤率，二來再來就是僅為紙本資訊電子化，並不會對既有流程提出太多的檢討。
至於EAI廠商的建議案可能是提出將門禁系統的資料與HR系統整合，讓HR系統內有每個員工的刷卡等資料能顯示。之後把HR內既有的請假單給拉到EIP上供員工填寫，填寫完之假單以HR系統之既有機制進行審核(status改變)，最後再將完成之資料由HR系統匯入薪資系統。資料主體是在既有系統間傳遞，解決了異質系統間資訊正確性的問題，但基本上各系統各管各的也不會有新的使用者介面出現。但是HR系統（或其他既有系統）之既有機制是否適合企業流程與HR系統既有的請假單是否易於一般使用者使用，往往就比較不是EAI廠商著墨的重點了。
BPM則是由業務角度出發；此次的業務是請假故會有一個請假單。請假單會需要哪些資料？員工基本資料由HR系統來、結餘可休天數由差勤系統來、最近缺勤狀況由門禁系統來（補請病假之類打平用），將這些異質系統的資料撈出顯示於請假單上，再提供幾個欄位如此次請假天數、事由等便完成了請假申請單。之後給主管審閱時除了以上資料外主管，可能還要有該名員工的近期休假記錄(以了解近期該員工是否有不尋常的請假狀況需要注意)，甚至員工的近期考績作為參考。可將相關資料顯示於主管專用的審核頁面上供參考，而不僅是把申請表單原樣重現。至於人事單位審核的關卡，若是之前取得資料的HR系統、差勤系統與門禁系統等的資料可信度夠高，其實相關的查核是可由系統代勞而不再需要透過HR人工比對查驗的。最後再將通過審核的資料由系統更新至差勤與薪資等系統完成歸檔。
至此為止只要把思維由系統觀點出發的EAI與Wf(尤其是由ERP所發展出來Wf最明顯)改為由業務觀點出發，技術上由與利用Wf與EAI的充分合作還是可以達到變革相同的目的。但要發揮BPM的精髓，更重要是接下來如何【管理】流程，且要管理的是業務流程而非資訊流程。流程系統是方便收集資料，如：統計假單由送出到完成更新差勤與薪資等系統平均需時多少是否符合原先預期？（常見的情況是蕭規曹隨久了，等到真的把流程圖列出，主管們才大吃ㄧ驚：怎有這多人要經手且要花費如此長的時間？換算成企業成本可是不低。）每關平均需時多久？哪些關卡是花時間偏多的地方？繼而由業務面檢討是否有需要改進的業務瓶頸存在：這那些是因單純因人力不足還是因未能充分提供資訊導致處理人員得花時間另外查找或是負責人員（主管）常跑外務而無法即時處理，甚或是橡皮圖章關卡太多等原因所致？找出問題後，從而下手改善企業流程或是表單設計，也就是Optimization。只是單以本益比而言，請假流程或許不需要搞到如此複雜也不用常常review求改善（不過實務上若認真分析企業在處理一張假單時所需耗費的時間與人力成本，可是常常會令企業主大吃ㄧ驚的高），但是其他會影響公司收益的核心業務應該就值得花費相對應的心思與時間來持續review並改善，以便持續強化企業的效率與競爭力。
放眼目前最成功的頂尖企業，莫不是在各自企業目標領域內不斷的精益求精，有的體現在成本與價格優勢上如：Wal-Mart、Dell、西北航空、鴻海，有的體現在品質精進如：Toyota、TSMC…等。，無一不是不斷的改進既有程序以求得在取在成本、品質、服務和速度等方面的提升改善，這是除壟斷與寡佔型企業以外大多數企業的宿命。BPM不是魔法棒也不是洪水猛獸而僅是一個方法、一個工具來便利企業進行企業流程的管理與精進。至於要如何來有效的使用這個方法跟工具，這有一篇文章可供參考，因篇幅有限在這我就不再繼續深入了。
若以較嚴謹的方式如BPR（Business Process Reengineering）來定義，內部革命是「：＂對企業的業務流程作根本性的思考和徹底重建，目的是在成本、品質、服務和速度等方面取得顯著的改善，使企業能最大限度地適應以顧客、競爭、變化為特徵的現代企業經營環境。＂」（1993年，美國邁克爾·漢默（Michael Hammer）與詹姆斯·錢皮（James Champy）《公司重組：企業革命宣言》)則BPM可以是實施BPR的有利工具之ㄧ。比方藉由BPM的系統化來將BPR所省思出的新流程制度化：畢竟要改變大家久已習以為常的事來個徹底重建可不簡單，甚至容易遭到陽奉陰違希望日子久後能自然不了了之。但透過將之系統化到BPM上，則所有人自然不得不遵照系統化了的流程制度來走。且當有例外狀況時也能被監控分析是否為合理的彈性處理亦或是不當的抄小路，或是先藉由BPM系統資料來分析BPR所應優先下手的重點方向，與實施BPR後的成效比對分析來驗證重建效益。但對於原先沒有BPR想法的企業而言，或許不太可能會因為導入BPM而引起BPR，頂多是因以導入BPM為契機，讓平時忙碌到沒空檢視既有流程的經理人們有機會好好坐下來對企業運作流程進行跨部門的合理化檢視，從而發現既有蕭規曹隨作法有哪些不當之處，進而引發進行BPR的想法。
但此時除非重新劃定專案範疇與時程不然也不至於引發立即的BPR行動，畢竟除非當初導入BPM時便已規劃要實施BPR，不然要對「【業務流程作根本性的思考和徹底重建】「可不是個小改變，至少需實際經常參與專案決策委員會的層級得大概就再得上拉幾個層級。
就大部分的例子而言，BPM其實更重視Business Process Refine。Business Process Refine與BPR相同的是對現行既有商業流程的質疑與挑戰，不同的是採用漸進式的階段調整取代根本式的改革。甚至可以說 一個完整的BPM生命週期若是缺少了Business Process Refine的階段，那也就不算完整的BPM了。在這我就不特別吊掉書袋地的引經據典了(正確典故用法其實是[掉書袋],吊書袋是通俗的慣用)，簡單而言，缺少了Business Process Refine的階段，那用大家熟悉的workflow + EAI即可，不用特別冒出個讓人有點熟又不太熟的BPM出來了。以下嚐試以不同系統廠商的觀點來顯示出Wf（workflow）、EAI與BPM的差異：
譬如舉個例子來說明Wf（workflow）、EAI與BPM廠商的分野：一家企業的資訊需求招標，需求是【請假系統】，經費與期限可議且非價格標未訂。簡而言之，傳統Wf廠商提供的建議案會著重在表單的容易製作與修改及人工簽核流程的設定。但是當此請假流程最後要將資料匯入其他系統時，傳統的作法是流程最後一關通知打單小姐，請打單小姐手動轉key入異質系統如差勤系統、薪資系統等。在簽核流程方面也多是目前紙本如何傳遞就照著設定，不會多事調整既有流程。所以一來會出現是異質系統間資料靠手動轉key的偏高錯誤率，二來再來就是僅為紙本資訊電子化，並不會對既有流程提出太多的檢討。
至於EAI廠商的建議案可能是提出將門禁系統的資料與HR系統整合，讓HR系統內有每個員工的刷卡等資料能顯示。之後把HR內既有的請假單給拉到EIP上供員工填寫，填寫完之假單以HR系統之既有機制進行審核(status改變)，最後再將完成之資料由HR系統匯入薪資系統。資料主體是在既有系統間傳遞，解決了異質系統間資訊正確性的問題，但基本上各系統各管各的也不會有新的使用者介面出現。但是HR系統（或其他既有系統）之既有機制是否適合企業流程與HR系統既有的請假單是否易於一般使用者使用，往往就比較不是EAI廠商著墨的重點了。
BPM則是由業務角度出發；此次的業務是請假故會有一個請假單。請假單會需要哪些資料？員工基本資料由HR系統來、結餘可休天數由差勤系統來、最近缺勤狀況由門禁系統來（補請病假之類打平用），將這些異質系統的資料撈出顯示於請假單上，再提供幾個欄位如此次請假天數、事由等便完成了請假申請單。之後給主管審閱時除了以上資料外主管，可能還要有該名員工的近期休假記錄(以了解近期該員工是否有不尋常的請假狀況需要注意)，甚至員工的近期考績作為參考。可將相關資料顯示於主管專用的審核頁面上供參考，而不僅是把申請表單原樣重現。至於人事單位審核的關卡，若是之前取得資料的HR系統、差勤系統與門禁系統等的資料可信度夠高，其實相關的查核是可由系統代勞而不再需要透過HR人工比對查驗的。最後再將通過審核的資料由系統更新至差勤與薪資等系統完成歸檔。
至此為止只要把思維由系統觀點出發的EAI與Wf(尤其是由ERP所發展出來Wf最明顯)改為由業務觀點出發，技術上由與利用Wf與EAI的充分合作還是可以達到變革相同的目的。但要發揮BPM的精髓，更重要是接下來如何【管理】流程，且要管理的是業務流程而非資訊流程。流程系統是方便收集資料，如：統計假單由送出到完成更新差勤與薪資等系統平均需時多少是否符合原先預期？（常見的情況是蕭規曹隨久了，等到真的把流程圖列出，主管們才大吃ㄧ驚：怎有這多人要經手且要花費如此長的時間？換算成企業成本可是不低。）每關平均需時多久？哪些關卡是花時間偏多的地方？繼而由業務面檢討是否有需要改進的業務瓶頸存在：這那些是因單純因人力不足還是因未能充分提供資訊導致處理人員得花時間另外查找或是負責人員（主管）常跑外務而無法即時處理，甚或是橡皮圖章關卡太多等原因所致？找出問題後，從而下手改善企業流程或是表單設計，也就是Optimization。只是單以本益比而言，請假流程或許不需要搞到如此複雜也不用常常review求改善（不過實務上若認真分析企業在處理一張假單時所需耗費的時間與人力成本，可是常常會令企業主大吃ㄧ驚的高），但是其他會影響公司收益的核心業務應該就值得花費相對應的心思與時間來持續review並改善，以便持續強化企業的效率與競爭力。
放眼目前最成功的頂尖企業，莫不是在各自企業目標領域內不斷的精益求精，有的體現在成本與價格優勢上如：Wal-Mart、Dell、西北航空、鴻海，有的體現在品質精進如：Toyota、TSMC…等。，無一不是不斷的改進既有程序以求得在取在成本、品質、服務和速度等方面的提升改善，這是除壟斷與寡佔型企業以外大多數企業的宿命。BPM不是魔法棒也不是洪水猛獸而僅是一個方法、一個工具來便利企業進行企業流程的管理與精進。至於要如何來有效的使用這個方法跟工具，這有一篇文章可供參考，因篇幅有限在這我就不再繼續深入了。
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的情況下，要擴展企業規模就會面臨類似的困境：由內部提拔經驗能力夠的人才則人手有限不敷使用、由外部挖角過來的高手則在無法規範的狀況下最後常是各自為政、自立山頭，與總部的作風與規劃大相逕庭。除地方對總部政策的理解落實度、總部對地方狀況的掌握度、聯合作業時的成效等問題外，當某地業務突飛猛進因而需抽調人力支援的效果也不好，因為不同辦公室做法完全不同，由Ａ辦公室調到Ｂ辦公室支援的同仁除了往外跑的業務本就難免因為風土人情不同而須調適，就連負責內部行政作業的同仁也得重新學習適應不同的做法後才能派上用場。就好比挖角來的分餐廳大廚做的菜雖好，但跟總店的風味卻明顯不同。客人上門吃不到預期的口味，對於這個招牌/品牌的信任度與忠誠度自然下降。大概就只能騙騙路過或是沒試過總店風味的呆胞了。若真如此那倒不如創個副品牌還好些，不要勉強掛同樣的招牌。
另一種較單純不考慮分公司的狀況則一樣以做菜來比喻，可視為主廚不再撰寫完整的食譜，反之是一系列不同的標準動作，將做菜的步驟分為好幾人分工的步驟：各自負責選料採買、清洗切菜、調配香料、熱鍋等不同工作，最後再由主廚將這些材料、佐料、湯鍋、烤箱等以最短的時間匯總為美味佳餚而不用自己注意太多的枝微末節與花時間在次要步驟上。目的不再是開設分店因為最關鍵的料理動作還是只能由主廚負責，但他能將所有時間專注於處理這個非他不可的步驟即可而不用再分神於其他程序，因此提升產出的質與量。
對應到企業的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。
由美食到BPM
民以食為天；我先用做菜來比喻：
一個主廚或許無法清楚明確的描述出他的做菜步驟，卻還是能煮出一盤盤好菜。但沒有詳細的食譜，廚房的學徒們只能在旁以觀摩強記的方式學習如何做出相仿的菜色，甚至得靠著吃「菜尾」來學味道，待時日漸久後靠著本身的努力與「慧根」才或許能慢慢磨練成為二廚，到最後出師獨當一面。因此這家餐廳能擴張的速度也就受限於學徒的資質與學習的速度。若只是本店擴大營業倒還好，至少主廚能隨時在旁試味道、看手法提點補救，因此擴編本店時所需的人力不需要具有太精湛的火候也無妨。但若是要開設分餐廳的話就不成了，靠電話是沒法試味道與傳授講不清的步驟的。因此分餐廳的大廚就得具有獨當一面火候的老手才能坐鎮，因此在資金無虞的狀況下能開設幾家分餐廳，就完全取決於能培養多少具有獨當一面的火候，又能彰顯餐廳特色口味的大廚了。
與之恰好對比相反的則是如85℃、源士林粥品這類的連鎖店了。他擴張靠的就是標準化的作業程序，因此在需要時能快速展店擴展規模。以單一店面而言連鎖店的表現或許不如精緻小店，但以企業整體表現來看在整體經濟環境不太差的狀況下，展店快速的連鎖店就具有明顯優勢了。
一般企業也是如此，一家公司可以在沒有明文詳細Business Process的狀況下還能經營的嚇嚇叫，營利豐厚。但在沒有明定基本SOP的情況下，要擴展企業規模就會面臨類似的困境：由內部提拔經驗能力夠的人才則人手有限不敷使用、由外部挖角過來的高手則在無法規範的狀況下最後常是各自為政、自立山頭，與總部的作風與規劃大相逕庭。除地方對總部政策的理解落實度、總部對地方狀況的掌握度、聯合作業時的成效等問題外，當某地業務突飛猛進因而需抽調人力支援的效果也不好，因為不同辦公室做法完全不同，由Ａ辦公室調到Ｂ辦公室支援的同仁除了往外跑的業務本就難免因為風土人情不同而須調適，就連負責內部行政作業的同仁也得重新學習適應不同的做法後才能派上用場。就好比挖角來的分餐廳大廚做的菜雖好，但跟總店的風味卻明顯不同。客人上門吃不到預期的口味，對於這個招牌/品牌的信任度與忠誠度自然下降。大概就只能騙騙路過或是沒試過總店風味的呆胞了。若真如此那倒不如創個副品牌還好些，不要勉強掛同樣的招牌。
另一種較單純不考慮分公司的狀況則一樣以做菜來比喻，可視為主廚不再撰寫完整的食譜，反之是一系列不同的標準動作，將做菜的步驟分為好幾人分工的步驟：各自負責選料採買、清洗切菜、調配香料、熱鍋等不同工作，最後再由主廚將這些材料、佐料、湯鍋、烤箱等以最短的時間匯總為美味佳餚而不用自己注意太多的枝微末節與花時間在次要步驟上。目的不再是開設分店因為最關鍵的料理動作還是只能由主廚負責，但他能將所有時間專注於處理這個非他不可的步驟即可而不用再分神於其他程序，因此提升產出的質與量。
對應到企業的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。
訂閱：
意見 (Atom)