KB奇遇記(9)：艱難的上線

      經歷了很是多的磨難，系統也「如約「在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起家的我，對這種系統的嚴謹性深深表示鄙視！此次艱難的上線給了我不少警示，除了對顧問的挑選以外，對系統的選型也是很是的重要。