16年3月我從上任項目經理手中接過A項目時，他斬釘截鐵對我說A項目功能已經開發完成，硬件程序也已升級并測試通過，唯一要解決的問題是如何及時推進A客戶UAT及正式上線。然而，項目進展遠不是表面描述的光鮮美好，里面布滿荊棘。

ERP名為企業資源管理規劃，它涉及了企業采購、存貨、銷售、生產及財務多業務計劃決策。我今天想要分享的是簡易版ERP在中小制造企業應用案例，談及的對象為國內某知名品牌電梯廠商A，后文簡稱A。

說到簡易，指的是我所負責的A項目功能模塊單一且標準，系統需實現合同數據登記、裝箱清單導入、裝箱嘜頭打印及條碼出入庫掃描記錄。項目的核心功能為箱子數據掃描的創建及管理，甲方所有功能中并未存在復雜業務邏輯構建，但項目最終正式上線時才發現并無想象中順利。

一、中途進入項目未把控總體規劃，實施細節關注不到位

16年3月我從上任項目經理手中接過A項目時，他斬釘截鐵對我說A項目功能已經開發完成，硬件程序也已升級并測試通過，唯一要解決的問題是如何及時推進A客戶UAT及正式上線。無獨有偶，我的主管領導在聽取前任經理工作匯報后，一度認為該項目可進入商務驗收階段，便制定了短期沖刺策略。

據悉，A項目核心內容是對客戶現有業務模式作一次技術迭代升級。我在公司熟悉了A項目業務之后，就立即開啟了定期上門實施指導模式。我認為首先要推進的事項是讓客戶將新升級系統小批量試運行起來，其次則是將配套的PDA程序測試運行，最后完善客戶提交的報表需求。看似完整的計劃卻在我上門實施第一周后變得一文不值，此刻我才清楚意識到項目進展遠不是表面描述的光鮮美好，里面布滿荊棘。概況以下幾點：

已完成功能未經業務部門復核確認，例如合同排產流程及多點操作界面未達客戶預期，導致技術員大面積返工;

PDA程序只完成新硬件對口新系統開發，而非與現行硬件對口開發，無法滿足客戶剛需;

客戶最為重視的報表無論從樣式還是數據展示均無法達到原始需求。

面對當前窘境，我只能重新規劃項目進度，制定實施細節。根據客戶反饋的需求，無法再以短平快模式推進項目，計劃更改為：

重新采集梳理業務部門需求，提交技術人員功能開發;

與業務部門做功能演示，修復需求差異并簽字確認;

提交客戶程序部署，推進小批量模擬測試;

導入原系統數據庫，新系統正式切換上線。

實施計劃推進了一年，直到17年3月才完成所有功能開發及測試驗證。

二、UAT測試不全面，正式上線業務基礎數據及技術腳本文件管控不力

17年4月項目開啟模擬試運行階段，客戶每天錄入10臺數據，流轉至合同執行部、倉儲部產品周期監控驗證。在此期間客戶提出一些BUG及優化改進項，但對于項目整體推進還算可控。整個項目模擬運行持續了兩個月，5月底時雙方一致決議6月初正式切換上線。

項目組在端午節時進駐A公司，趁員工節假期間備份并遷移15、16老版本系統數據至新系統，6月1日正式上線。一切事項都經過項目組精心布局執行，可就在切換后的第一天各種問題層出不窮，考慮上線問題太多，我便不一一列舉，謹以下典型問題闡述：

項目組技術編寫關聯第三方語句代碼錯誤，導致客戶服務器內存資源占用過多，出現系統崩潰;

成品入庫單打印時名稱、梯號、數量取不到值;

很多功能界面(如裝箱清單確認界面)狀態值不及時更新，導致界面反向操作執行不下去;

操作合同登記界面報錯，并發日志寫入異常，導致系統自動彈出多點用戶;

測試工作未能全面開展，如改造機型發運清單導入未能考慮;

正式上線運行中，業務流程變更頻繁，導致項目推進緩慢。

經5W2H分析問題根源為：

1)服務數據遷移關鍵腳本執行前未經互檢，導致數據處理錯誤;

2)項目模擬運行多停留主流程界面，未覆蓋所有業務數據及輔助界面，造成上線后系統操作受阻;

3)項目需求不明確，徒增技術返工量，影響整體實施進度

三、駐廠團隊專業素養不夠，問題響應效率偏低，項目進程受阻

為確保A項目17年6月1日正式上線，我們成立了專案項目組共四人入駐A公司，其中包括一名項目經理，一名實施人員，兩名技術人員。駐廠支持的一周時間里，整個團隊運營不和諧，處理問題專業見識欠缺，具體表現為：

1)項目組技術人員面對客戶壓力時出現一些低級失誤，比如程序路徑IIS訪問權限未設置，技術員則以為是config數據庫密碼配置問題，而直接將原數據庫密碼進行重置，導致數據庫密碼鎖定，無法解鎖導致數據遷移進度受阻;

2)對客戶現場反饋的緊急BUG項響應速度偏慢，如增加裝車發運單重置換算功能就耗時2小時，客戶認為處理效率較低;

3)項目組成員內部團結協作不充分，特別是客戶當場提出的問題頻繁出現多種回復意見;當實施負責人或技術負責人不在場的時候，未能擔當起備用角色職責;

4)項目組實施成員對業務流程不熟悉，對于客戶現場提交的需求理解不充分，導致很多問題無法及時跟進處理

四、程序版本管理紊亂，交付測試工作質量不過關

項目實施進程中經常出現已完成功能二次返工情況，如A功能測試通過提交更新后系統標記2.0版本，而后B功能修改提交更新后3.0版本時A功能發生異常。

當系統提交重大功能更新后，往往禁不起用戶多點批量測試，二次返工率居高不下。例如17年8月交付的合同登記界面切換功能，提交用戶更新后相繼出現“合同參數信息新創建無問題，二次修改參數信息則導致無法保存”、“復制新文件號后，修改參數保存文件后項目名稱、客戶名稱信息消失”、 “合同新界面更新前供應名取的文件登記處理界面值，合同新界面更新后供應商名取了合同登記表頭，導致部分入庫單供應商值為空”的問題。經程序后臺查證根本原因追溯到新老界面切換時未考慮取值變化對后續單據關聯處理，明顯反映出測試工作太粗獷，細節深度把控不夠。

項目組歷經近兩年的浴血奮戰，A項目最終驗收結案。回過頭來復盤推演，卻發現滿地盡帶坑洼處。從公司經營層面來看，3個月可以結案的項目竟然延長到了兩年周期，投入與產出極不對稱。看似簡易的功能卻頻繁出現各種問題，拋出項目進程中用戶客觀存在的需求變更外，更多的問題點應由乙方項目組歸納總結。未來企業信息化建設會越來越追求個性定制化，假若我們仍然墨守成規堅持常規ERP項目實施方案將無法滿足用戶業務需求，也會導致項目進度計劃延遲。經此一役，我還是分享以下幾個要點供大家參考：

搭建專業實施團隊，授權項目經理絕對領導力，并建立項目實施考核機制評估項目組成員工作績效;

制定程序代碼編譯、功能測試、程序更新標準作業流程，確保功能穩步更新至用戶端;

對于用戶提交的多部門復雜功能需求，決計不能由某個主管領導拍案確認，而應聯合業務部門骨干人員作原型設計方案復核，以盡量貼切客戶實際需求;

項目啟動后，根據用戶反饋意見統籌安排基礎數據導入及上線準備事項，以確保業務數據完整;

建立項目定期里程碑匯報制度，讓用戶主管領導及時掌握項目戰略方向及推進速度，防止項目指導思想偏移，確保項目按時結尾。

總之，我們在推進項目關閉時需重點把控項目總體規劃、規范項目流程、處理實施細節才能平穩快捷推進ERP上線運行。