今天朋友圈盛傳一則訊息，說是南瑞集團的一名名為牛耕耘的SAP顧問因為工作強度大，連續不分晝夜加班而猝死在工作崗位上，遺留下年邁的父母、體弱的妻子、剛滿週歲的孩子和鉅額的債務。誠然，但SAP圈子裡加班確實是一個常態，似乎做專案不加班反而不太正常，尤其是到專案後期，加班到深夜甚至通宵都是常有的事兒。
看著今天這種悲哀的訊息，讓人不禁思考：做專案頻繁加班真的是正常的嗎？
我個人認為，SAP專案經常要顧問加班，大概有以下幾個原因：
一、專案風險把控不過關
對專案風險的精準把控往往是一個專案經理的必修之課，可惜國內很多專案經理往往只是為了做專案而做專案，尤其是以技術出身的專案經理。
記得我之前經歷過的一個專案，在上線前幾天以及上線之後幾天基本上每天都是瘋狂在加班處理上線過程的各種問題，甚至通宵。不是未清資料沒有導好就是使用者那邊一大堆操作的問題，同時還有各種因為主資料的問題而導致系統操作進行不下去，也不乏出現一些業務場景沒有考慮進去，開發的程式各種Bug，錯誤。糾結原因其實還是專案質量的問題。說白了就是前期沒有充分考慮到上線過程的風險，沒有很清楚意識到每個環節出錯會帶來連鎖反應，問題一大堆。
二、糟糕的實施計劃
國內不少SAP專案在指定計劃的時候總是讓人感覺有一種“先馳後緊”的感覺，在專案初期階段，大家都不會加班，哪怕事情沒有按計劃完成也不會想著主動留下來加班，所以計劃可能會有所Delay，導致到後期的時候所有人才開始緊張起來，慢慢加班也變成了一種常態。專案經理和高層對計劃的Delay保持相當樂觀的態度，甚至不做任何的措施補救，總以為一切都在可控範圍內。這大概就是為什麼做專案需要加班的原因之一。每個專案都這麼過來的，導致了老顧問在認知裡就認為後期得不分晝夜加班，這樣的“惡俗”傳承下來給新顧問，也變成了一種特有的文化。
我記得上一個ERP專案，明明到中期階段了，連繫統流程都還沒梳理完成，而且藍圖都還沒做報告，按計劃來說已經是嚴重Delay了，而乙方顧問還是一週只來支援3天，對Delay的原因相當樂觀。再加上甲方組織變更，團隊成員也都處於茫然狀態。後面上線日期推遲了兩個月，似乎所有人都鬆了一口氣，但專案組也絲毫沒有處理好各種Delay問題，沒有制定出有效可執行的計劃來，導致新的Delay接踵而至，到後期要上線了才安排狂加班到凌晨，也依舊沒能解決好各種上線切換的問題，比如判斷和庫存資料不準、業務場景考慮不足、開發的程式各種Bug等。
不可否認，在上線切換階段，因為資料要匯入，核算成本以及開賬等原因不得不在上線前一天加班處理，而上線之後又要處理各種系統更替所帶來的各種操作、體驗、資料等問題，所以經常要加班。但如果專案經理或者制定專案計劃的人實現考慮到了各種風險因素，制定有效可操控的專案計劃並做到嚴密執行，針對Delay的原因進行充分分析並及時糾正，我相信加班的可能性就會降到最低。
三、實施質量差
因為乙方顧問的專案經驗問題，水準都只是處於“SAP系統”級的顧問，而不是站在業務層級或解決方案上來做專案。這些顧問往往只是配配系統，做做操作，寫點開發，遇到問題和業務場景永遠只是站在系統上考慮，永遠只是閉門造車拍著腦袋考慮，不會去跟關鍵使用者，不會找領導開會討論各種待決問題。專案例會從來不開一次，而討論會最多的永遠是技術，而不是最佳方案。
實施期間的各種問題比如業務場景考慮不周，流程線沒有考慮撤回退回的情況，藍圖描述不清晰或考慮不全，給出的技術方案背離高效可用的原則，開發的程式各種Bug和不穩定，與第三方系統連線過多，使用者培訓不到位等等都算是實施質量差的典型例子。
四、甲方需求多變
我曾經遇到最奇葩的一個專案是甲乙雙方都很認真對業務和現狀做了很細緻的調研，也給出了最初藍圖版本，但最後當開發需求和功能書都準備完畢之後，公司高層下達了對該組織做關閉的通知，也就是說實施範圍裡的這家子公司關閉了，不上線了，也是滑天下一大稽了。
不僅如此，甲方經常對內部需求往往不明確，最會說的就是：先搞出來看看再說。因此一件事兒往往因為需求多樣化的原因遲遲未能確定下來。
其實，顧問加班這個話題永遠都是專案管理的問題。導致顧問加班的原因遠遠不止以上四點，扯的多了就已經不是“加班”兩件事兒的事情了，而是上升到了管理層、專案管理等高度了。
可是每個專案都是這麼過來，似乎大家已經習慣了做專案加班，也很少人會認真冷靜下來想一下是否真的需要如此加班？如果計劃可控可執行，如果每個環節都做得相對完美，嚴格執行專案管理方法論，我想，不加班應該不是難事兒。而且“摒棄加班”應該是專案經理永遠需要考慮的必修之課。
不管怎麼說，希望類似悲劇事件不要再發生了，各位SAP顧問，保重身體要緊！