拆解失敗ERP亂局 CIO如何妙手回春？

　　案例篇

　　ERP失敗算不得稀罕事，但是找到敗因，力挽敗局，就不是一般CIO都能順順當當做下來的了。面對即將或者已經失敗的ERP項目，很多CIO會選擇遮掩下來，畢竟從選型到實施自己都是項目經理，承認項目失敗就是認定自己無能，更不消說領導面上無光，企業形象受損。

　　如何能在敗局中取勝?這家大型生產企業的ERP項目經理鐘劍自有一套。

　　發難

　　鐘劍不知道怎么走出會議室的，他下意識向15樓走去，上了4層樓就感覺氣不順，樓道安靜而氣悶，額頭上開始冒汗了。

　　“公司花費了上千萬元，投入了幾十個人的精力，為什么ERP項目拖了一個月還是無法上線，這樣一種混亂的局面是什么原因造成的?”剛剛過去的項目進度匯報會上，面對一堆問題，CEO王總責問道：“鐘經理，你們信息部在‘腳踩西瓜皮’，作為項目經理，你應該好好思考一下，明天給我一份報告，告訴我原因和解決方案!”說完摔門而去，把項目組成員扔在會議室里，大眼瞪小眼。其實，這也不能怪王總，剛剛項目階段匯報會議上，各部門反映的情況也真夠亂的：

　　銷售部門營銷平臺的數據通過接口導入ERP系統時，跨月部分產生重復;

　　生產計劃通過MPR計算出來的結果，與目前人工計算差別過大;

　　采購訂單運行項目數據無法自動帶到入庫單上，需要手工重新錄入;

　　財務報表無法正確顯示，會計科目平衡表數據是正確的，但資產負債表一直不平;

　　倉儲存貨賬與財務賬無法做到賬賬相符，存貨賬與實物賬也存在著一定的差距;

　　業務部門最終用戶在培訓操作過程中，發現操作手冊上寫的內容在系統中根本就找不到，或有出入，且相對比較簡單;

　　雖然經過單元測試，但測試的場景過于簡單，沒有涵蓋日常業務運營的全部內容;

　　在最終用戶操作培訓的過程中，很多業務部門自己上報的參培人員也沒有參與過一次ERP的相關培訓;

　　業務部門投入到項目組的關鍵用戶，大多數是本部門的骨干，但由于他們工作繁忙而沒有全力投入項目，造成關鍵時候找不到人，與其有關的關鍵問題討論時他們亦不在場的現象，使得會議一拖再拖，尤其是銷售大區和某工廠的關鍵用戶連一次最基本的ERP功能培訓都還沒有參與;

　　回溯

　　鐘劍一邊回憶著會議上的情況，一邊郁悶地轉出樓道門乘電梯回到自己位于15樓的辦公室。一年前，通過獵頭進入這家大型生產企業，經過調研、分析，在了解企業信息化發展現狀和業務特點后，他提交了公司信息化三年建設方案。然后，按部就班地著手基礎設施的建設、IT部門的團隊建設，慢慢熟悉并融入該企業。去年年底ERP系統建設列入公司重點項目計劃，這也正是鐘劍過來的動因。雖然在原來的集團公司他經歷了國外大型ERP項目實施的過程，但角色只是其中一個組的組長，負責某一小塊具體的業務流程設計和系統實現工作，沒有能夠參與項目管理的內容，所以他一直希望能夠作為項目經理全程參與和統率一次ERP項目。

　　ERP項目被正式列上議事日程后，鐘劍在進行業務需求調研后，嚴格按照ERP實施的標準方法，進行了系統選型，最后選擇了一家大型ERP系統軟件。對實施的顧問團隊，他也是一個一個簡歷看過，個別還進行了面對面的交流，可謂精心挑選。經過半年的努力，終于到了即將上線的最后時刻，但項目停滯不前，出現了上述的混亂而復雜的局面。這種局面究竟是如何產生的?鐘劍收回思緒，打開工作目錄下的ERP項目文檔，一項項內容井井有條地展現在眼前。

　　項目計劃：

　　在項目準備階段，項目計劃的編制成為甲乙雙方兩位項目經理的主要工作內容，將6個月的總體上線任務和工作內容細化到周甚至到日，并在統馭項目主計劃的同時，進行了數據計劃、項目整體培訓計劃、項目宣傳、活動計劃等內容，以確保項目計劃的周密且不遺漏。

　　“計劃沒有變化快”。由于人員投入不夠，項目雖然按著計劃在向前走，但總是存在著這樣那樣的問題，無法做到深入和完善。而最終導致系統上線推遲的最主要原因就是初期數據遲遲沒有收集整理到位。

　　項目組織：

　　項目組織的建設也是起初腦筋動得比較多的地方，公司成立了項目管理委員會，將公司主要高層都納入其中，由CEO親自擔任;管理委員會下設項目管理辦公室和監理組;接下來是技術組、業務組、數據組和開發組。其中業務組按此次上線的模塊分為五個組：銷售、采購/倉儲、物流、財務和生產，業務組長均由相關業務部門負責人擔任，再由其抽調部門骨干進入，同時信息部也在每個業務組派出一名代表。

　　起初，鐘劍一再要求業務組必須有一名業務部門的骨干力量全職參與項目組，但最終由于業務部門負責人的反對，而導致目前業務組除信息部人員外全部屬于兼職參與。經常一個討論分析會都要一變再變地變更時間，尤其到后期的跨模塊討論時更難確定會議的時間。項目組沒有一個統一的工作場所，顧問、業務組、信息部人員均在各自的辦公室辦公，只有開會時再聚到一起。由此，對項目所有工作的開展都產生了巨大的影響。

　　藍圖設計和系統實現：

　　由于前期準備工作比較充分，ERP項目啟動前已經做過一輪業務流程的調研分析，加之ERP項目剛剛進入大家的視野，在藍圖設計中現狀調研階段，大家還是比較積極地參與，很快就完成了任務。但到了未來藍圖設計時，一是由于工作忙，二是“新婚期”已過，個別部門領導不再參與流程的講座和分析，而由手下人參與，領導只看最終的匯報和文檔，并也在藍圖流程上簽字認可了，這些在當時并沒有覺得問題有多大。但到了最終用戶培訓和單元測試時，卻發現原來這些藍圖流程與老總們想的有出入，與那些部門骨干的思路也有出入，只好返工重來，還需要協調實施顧問的資源。在原本時間和人力資源比較緊張的情況下，這又浪費了不少時間，讓人苦不堪言。這也是上線時間延遲、項目計劃不能順利執行的主要原因之一。

　　系統實現，一方面是顧問按業務藍圖流程設計進行配置和二次開發，另外就是關鍵用戶熟悉系統，并進行業務場景在系統中測試運行的好時機。由于人力的投入不足，導致很多地方由顧問進行相對標準的測試就草草了事。有些測試雖然由關鍵用戶進行的，但由于系統熟練程度有限，加之大多數部門關鍵用戶沒有足夠重視，把測試當成一項工作任務來完成，應付了事，沒有完全重現業務運作時的多重組合的復雜的業務場景，相對簡單地進行了一些業務內容的測試。這就埋下了隱患。

　　數據整理和接口、報表設計：

　　數據，從一開始就提到比較高的地位，專門成立了數據小組來負責，靜態數據很快就進行了統一編碼、重新規范等工作，動態數據的模板設計和下發也進行得相對比較順利，但在業務部門卻沒有引起足夠的重視，或者沒有及時提交，或者提交上來的數據沒有完善地按模板進行填報，有些業務人員就象征性地填了一兩列數據表就上交。因此，數據的整體收集和整理工作一拖再拖。

　　另外，由于公司從建立到現在有15年，歷史遺留下來沒有解決的問題比較多，集中反映到數據上就是：賬實嚴重不符，日常在進行審計和核對時，大家只采用賬賬核對，而只有一些常用的原輔料和流動比較快的產成品在正常流轉。這也是不同業務部門在上線數據不符進行調整時，爭論得比較多的事情。

　　雖然公司其他的信息系統并不多，但由于整體行業信息化程度比較高，上下游企業之間的數據傳輸還比較頻繁，為了解決這個問題，在選型時即確定通過接口的開發來完成。這塊由于顧問公司人力投入不足，而信息部提交的開發技術人員招聘的事情也被莫名擱置了幾個月，到目前為止還沒有任何信息。

　　報表開發需求量也比較大，雖然已經開發好其中的一部分內容，但由于系統沒有真實數據，很難對其正確與否進行評估和檢查測試。

　　最終用戶培訓：

　　《最終用戶操作手冊》每個模塊在顧問的督促下，在關鍵用戶開始學習的時候就著手編制，只有少數沒有關鍵用戶投入的部門涉及到的操作流程未能完成。由于關鍵用戶對于業務的熟悉程度不同、對ERP系統的熟練程度不一，操作手冊的優劣差異很大。相對來說業務場景設計得比較全面，且能夠詳細截圖、解說的《最終用戶操作手冊》不多，這也為最終用戶的培訓帶來了問題。

　　在最初的培訓計劃中，安排的是專門的多場集中式培訓，但由于業務部門工作繁忙，關鍵用戶和最終用戶時間無法統一調配，使得培訓的方式變得五花八門：有集中進行培訓的，有單一進行培訓的，還有到最終用戶工作現場進行培訓的。

　　反思

　　王總讓鐘劍整理一份情況報告，雖然在項目推進的過程中，上述問題都已經通過項目進展通報提交給公司高層和業務部門領導，也在會議上做過匯報和總結，并提出過應對措施，但可能是沒有觸及到他們的痛處，沒有引起足夠的重視。鐘劍想，看來這一次不能再不痛不癢了，已經受到王總的責難，那就索性和盤托出，痛在一時比一直痛下去要好。

　　綜合前面的回顧和分析，項目主要存在的問題是：

　　1.人員及精力投入：業務部門沒有足夠重視，雖然項目組里掛名的都是各個部門的領導，但真正投入的時間和精力的非常有限，個別部門雖然在項目的后期有專職常駐人員，但對業務本身的熟悉程度有限。制絲車間到現在連一個人都沒有參與過，銷售部西北大區連一個兼職人員都沒有來聽過課，而工廠的財務部成本會計居然從未露過面。

　　那么，這一塊問題的解決，需要引起公司各部門領導足夠的重視，并由項目管理委員會負責人CEO王總親自發布命令，按最初項目組織的要求，抽調各部門得力骨干，全職參與到項目中來。

　　同時，需要有一個統一的辦公環境，讓項目辦公室、實施顧問、關鍵用戶坐到同一個辦公室中去，以便充分交流，也使得顧問的知識快速傳遞給關鍵用戶。

　　2.數據整理：雖然經過項目組的努力，基礎數據已經有了一定的規范，但那些日常運營的動態數據卻遲遲不能收集到位，雖然數據也都采集上來了，但數據本身是不完整的，而主要的物料數據普遍存在著財務賬和業務賬無法“賬賬相符”，更不要說業務賬和實物之間的“賬實相符”了。

　　針對上述問題，需要動員所有業務部門，重新組建一次數據收集、整理的隊伍，針對歷史遺留問題進行認真分析，能夠核對清楚的進行調賬處理，不清楚的部分先打包進入系統，待后續階段有精力時再進行解決。

　　3.業務測試場景設計：在業務測試和最終用戶手冊編寫環節，由于顧問對公司的行業熟悉程度有限，協助關鍵用戶進行的單元測試和集成測試場景設計相對簡單和標準，沒有考慮到業務的復雜變化，而關鍵用戶的精力投入有限，大部門人都把測試當成一個任務而已，沒有引起足夠的重視，只是簡單地設計并做了系統測試。而當最終用戶參與學習時，有大量沒有經過測試的業務情景出現，結果導致或者沒有辦法操作，或者問題一堆，再加上系統數據的缺失，使得業務部門最終用戶對系統產生不信任感。

　　需要組織業務骨干，收集和整理日常業務不同的場景變化，統一編輯后，進入系統進行測試，并添加到《最終用戶操作手冊》中去，為今后最終用戶的學習提取更翔實的指導。

　　4.需求變更：項目開展的前期，業務部門沒有足夠重視，在業務調研和流程梳理過程中，部門領導和關鍵業務骨干投入的精力有限，整理出來的業務流程細度和準確度不夠，而在最終用戶操作培訓時，又提出了新的業務需求，且這些需求很多會引起較大的業務流程變更。

　　對于新提出來的需求，以不阻礙業務正常運轉為前題進行篩選，關閉那些與界面、操作習慣等有關的需求，待ERP上線后再慢慢進行優化。

　　想到這里，鐘劍不由得露出了一絲苦笑，其實在項目剛開始組建，以及后來的項目實施過程中，這些問題不止一次地提過，當時王總和各業務老總應允得很好，但最終結果卻無法讓人滿意。他本想把這個項目建設成“公司級”的信息化建設項目，為自己的信息化職業生涯別上一枚金制獎章，最終，在實際項目推進過程中連“業務部門級”項目都沒有達成，而淪落為“信息部門”的建設項目。這些是他這個信息部經理無法改變的。

　　這次的分析報告如果再不點醒高管們，這個ERP項目的走勢很明顯，而自己在這家公司的職業生涯估計就走到頭了，職業生涯中的“污點”也就此留下。鐘劍希望能夠就此機會反戈一擊，一舉扭轉幾個月來的被動局面，給ERP項目成員注入強心劑，做成一個先苦后甜的好案例。

　　下定決心后，鐘劍坐下，信心滿滿地準備繼續“筆伐諸侯”……

　　分析篇

　　項目組不能做擺設――河南飯店CIO 王大龍

　　俗話說兵馬未動，糧草先行。在ERP項目實施過程中，項目組織的建立是項目正常運行的保障。通過上述案例，我們可以看到該公司的ERP項目組織是按項目管理的標準進行設計的，但在實際過程中卻沒有發揮應有的職責，從而使項目管理組織失去了應有的功效。

　　從項目管理的角度來說，項目組織的建立是項目正常運行的保障。在ERP項目實施過程中，當然也要遵循建立項目組織的原則。但是分析上述失敗案例，我們看到該公司雖然完全按照項目管理的標準來建立ERP項目組織，但是顯然只有皮毛沒有深入，失去了其應有的意義。

　　管理上要各司其職

　　首先，我們先來看一下一般ERP項目的組織和對應的職責。

　　項目指導委員會：負責組織審定項目計劃、實施方案，指導項目開展、重大問題協調與決策。

　　案例中，項目指導委員會沒有發揮應有的作用，看到的只是責難和推卸責任。

　　項目管理辦公室：具體負責項目日常組織工作，負責制訂項目計劃、實施方案，控制項目進度與質量，協調解決出現的問題;負責整體ERP項目管理與資源協調，以及關鍵實施問題的解決;負責向項目指導委員會提交各類匯報材料，負責項目各類文檔的組織與評審，驗收準備工作的組織。

　　案例中，我們無法看到資源調配和協調，由于實際權力的缺失，只有一味地讓步和等待。當然，這是目前市場上最常見的現象。

　　業務組：保證業務需求明確清晰;對未來流程以及系統方案提供建議;負責與相關部門的溝通協調;協助解決項目執行過程中的業務問題;負責流程改建與優化的具體落實;培訓最終用戶，幫助其掌握ERP系統使用;解決常見的系統應用問題;向項目組提交不能解決的系統問題;負責進行有關的應用系統配置和管理;負責相關管理制度細則的起草和監督執行;匯集并提交銷售業務和歸口審批的報表及功能性開發的需求整理并提交模塊優化及完善的新增功能需求;建立涉及管理與維護相關文檔和問題處理日志等。

　　從案例中我們可以看到，該公司的ERP項目是定位到“信息中心部門項目”的層級，業務部門對于項目是被動的參與，而不是積極主動地展開工作。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]