在以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由景氣上揚時紅極一時的市場寵兒到景氣下滑時被歸咎為造成庫存惡化人人喊打的元兇。系統做的也僅是依照預設的邏輯來產生預估並向上游與工廠自動下訂單。邏輯都是建立在一定的前提下的，當前提成立，自動化可節省不少事。但是一旦前提在不知不覺中變易了，那自動化產出的成果就可能差距甚遠而造成巨大（庫存）損失了。古人說：「盡信書不如無書」，套到現代或許也可說盡信系統不如無系統吧。連下西洋棋這般有固定規則可循的事都得動用超級電腦出面還無法保證必勝不敗。變動更為無跡可尋的企業治理，以有限的資訊預算想要能造出十全十美的資訊系統就顯得不切實際了。好比股票追求的是合理的本益比，資訊系統也是。十全十美的系統固然難求，但要解決一些符合二八法則的例行事務與資料處理則還是綽綽有餘也可展現相當效益的。
沒有留言:
張貼留言