經歷了非常多的磨難，系統也“如約“在2017年01月01日勉強上線了。盡管我認為它還不到上線的程度，條件不具備，但上頭的指令下來和計划便是在這一天。整個上線過程從2016年3月8號開始到上線日，扣除中間荒廢無為的1個月半，實際上實施的周期只有7個月半。當然，這實施周期並不算短，但要是考慮到2016年10月1號上了OA系統，期間還有地磅系統，條碼系統上線；除此之外還有信息部各種系統要維護如一卡通，機房，電腦管理，加密系統等；還有甲方乙方兩邊項目團隊人員嚴重不足，素質不佳，每周顧問只來3天；甲方項目經理還要提防不懂技術的人背后在領導耳邊吹風等伎倆，這些諸多因素的考慮進去，其實這7個月半的時間里實際上是很短的。
按之前我上項目的經驗，藍圖匯報之后會做需求的客制開發，之后就是各種單元測試，到最后也有必經之路的集成測試。這集成測試就是針對企業各種業務模式，模擬實際上用戶作業的方式從需求源頭開始，每個部門都會處理，業務一直流轉到后續財務端開票和結算成本等，也是一次非常重要的職責明確和規模最全的業務測試。但是在KB公司，居然把這么重要的環節給漏掉了！只有讓“兼職”關鍵用戶過來模擬本部門的操作流程，僅此而已。關鍵用戶根本就不知道他做的這個東西有啥用，前后業務有啥串接，更別說對業務和ERP模塊有很清晰的認識。這些情況的出現也跟“兼職”有關！
ERP項目組並沒有召開所謂的上線切換會議，制定切換策略，包括基礎和未清數據導入計划、在制品處理、成本滾算、開賬、基礎數據缺漏補錄方案、基礎設備准備等等，還需要發布一份上線公告。上線動作是整個ERP項目的實施的最后環節，上線策略好壞決定了ERP上線期間的質量。過去的項目中對這個環節是很重視的，甚至需要跟高層做開會研究決定，列出可能出現的情況並逐一約定解決。但是在KB公司的上線里，並沒有這個環節。顧問們只是在QQ群里跟關鍵用戶互動而已，在現場只是跟信息部IT做溝通，根本沒有一份非常清晰明確的上線計划文檔，讓我覺得很吃驚。很多時候，除了我，其他IT和關鍵用戶，甚至包括甲方項目經理都摸不清楚顧問的想法。
於是乎，2016年12月31日那天信息部和顧問都留下來加班，但是關鍵用戶基本上都缺席了，特別是生產的。加上之前培訓效果並不理想，所以導致了這次上線的時候很多用戶根本就沒有辦法處理。2017年01月01日ERP算是正式上線了，但暴露的問題非常多，比如客制程序錯漏很多、生產模塊業務流程問題、報表打印問題、跟OA系統對接的問題、庫存和基礎數據不正確、APP條碼錯誤等，這些其實可以在實施周期預測得到並解決的，很遺憾，甲乙雙方均沒有效規避，特別是乙方顧問，上了這么多的系統，按道理來說經驗極其豐富了，沒想到他們如此的不上心，也可以側面說明他們能力水平並不理想。上線一周內暴露了非常多的問題，而乙方的項目經理居然不在場，也是讓我覺得完全不能接受的。雖然每天上班結束之后我都會去收集暴露的問題明細，但並沒有再開一次會來每天總結和處理問題。因為很多時候問題並不是IT和關鍵用戶可以解決的，需要上升到項目層面。比如生產模塊的玻璃換包裝的問題，木箱換裸包的業務當初顧問就是沒有考慮到，但實際上發生了這個業務的時候，顧問並沒有很盡心去補救，反而模棱兩可，給出一個讓人很難接受的方案來，根本沒有經過很嚴格的推敲和測試。很多方案的制定太隨意了，然后隨意在后台隨意修改數據，跟SAP系統的嚴謹性形成兩級對比！還有一個比較大的問題就是庫存值一直不准，因為生產連續性的特點，不可能停線，所以庫存一直在入，一直在出。所以手工帳越來越多，到最后就要每天一直在補數據。庫存值不准導致了銷售那邊出貨的問題。
開始顧問還會加班，但一周之后居然缺席了，但那個時候問題還是很多的。顧問們居然周末也放假休息了，只留下一個根本沒有帶過項目的顧問在。而上線期間里，顧問支持度也不夠，拿技術開發人員當業務顧問使喚。記得在QM辦公室，一個技術人員跟QM的關鍵用戶就打印軟件的合理性做討論。嚴格來說，項目組顧問連需求都沒有調研清楚，但那個技術顧問只會說有問題請找項目組顧問，對QM關鍵用戶提出的很多合理而明確的需求視而不見。我真心覺得，資深的技術開發顧問在業務水平上還真的遠遠不如一個關鍵用戶呢！
至今回想起來，上線過程還是挺驚心動魄的，真的一度認為它要上不去了。你或許體會不到當顧問們都缺席不在場而銷售、生產、質檢、庫存那邊問題一大堆暴露出來的絕望。這種系統上過一次就真的不能再碰了，在做SAP起家的我，對這種系統的嚴謹性深深表示鄙視！這次艱難的上線給了我很多警示，除了對顧問的挑選之外，對系統的選型也是非常的重要。