从SAP顾问猝死事件谈顾问加班

今天朋友圈盛传一则消息，说是南瑞集团的一名名为牛耕耘的SAP顾问因为工作强度大，连续不分昼夜加班而猝死在工作岗位上，遗留下年迈的父母、体弱的妻子、刚满周岁的孩子和巨额的债务。我无法证实该消息的真伪，但SAP圈子里加班确实是一个常态，似乎做项目不加班反而不太正常，尤其是到项目后期，加班到深夜甚至通宵都是常有的事儿。

看着今天这种悲哀的消息，让人不禁思考：做项目频繁加班真的是正常的吗？

我个人认为，SAP项目经常要顾问加班，大概有以下几个原因：

      一、项目风险把控不过关

对项目风险的精准把控往往是一个项目经理的必修之课，可惜国内很多项目经理往往只是为了做项目而做项目，尤其是以技术出身的项目经理。

记得我之前经历过的一个项目，在上线前几天以及上线之后几天基本上每天都是疯狂在加班处理上线过程的各种问题，甚至通宵。不是未清数据没有导好就是用户那边一大堆操作的问题，同时还有各种因为主数据的问题而导致系统操作进行不下去，也不乏出现一些业务场景没有考虑进去，开发的程序各种Bug，错误。纠结原因其实还是项目质量的问题。说白了就是前期没有充分考虑到上线过程的风险，没有很清楚意识到每个环节出错会带来连锁反应，问题一大堆。

      二、糟糕的实施计划

国内不少SAP项目在指定计划的时候总是让人感觉有一种“先驰后紧”的感觉，在项目初期阶段，大家都不会加班，哪怕事情没有按计划完成也不会想着主动留下来加班，所以计划可能会有所Delay，导致到后期的时候所有人才开始紧张起来，慢慢加班也变成了一种常态。项目经理和高层对计划的Delay保持相当乐观的态度，甚至不做任何的措施补救，总以为一切都在可控范围内。这大概就是为什么做项目需要加班的原因之一。每个项目都这么过来的，导致了老顾问在认知里就认为后期得不分昼夜加班，这样的“恶俗”传承下来给新顾问，也变成了一种特有的文化。

我记得上一个ERP项目，明明到中期阶段了，连系统流程都还没梳理完成，而且蓝图都还没做报告，按计划来说已经是严重Delay了，而乙方顾问还是一周只来支持3天，对Delay的原因相当乐观。再加上甲方组织变更，团队成员也都处于茫然状态。后面上线日期推迟了两个月，似乎所有人都松了一口气，但项目组也丝毫没有处理好各种Delay问题，没有制定出有效可执行的计划来，导致新的Delay接踵而至，到后期要上线了才安排狂加班到凌晨，也依旧没能解决好各种上线切换的问题，比如判断和库存数据不准、业务场景考虑不足、开发的程序各种Bug等。

不可否认，在上线切换阶段，因为数据要导入，核算成本以及开账等原因不得不在上线前一天加班处理，而上线之后又要处理各种系统更替所带来的各种操作、体验、数据等问题，所以经常要加班。但如果项目经理或者制定项目计划的人实现考虑到了各种风险因素，制定有效可操控的项目计划并做到严密执行，针对Delay的原因进行充分分析并及时纠正，我相信加班的可能性就会降到最低。

      三、实施质量差

因为乙方顾问的项目经验问题，水准都只是处于“SAP系统”级的顾问，而不是站在业务层级或解决方案上来做项目。这些顾问往往只是配配系统，做做操作，写点开发，遇到问题和业务场景永远只是站在系统上考虑，永远只是闭门造车拍着脑袋考虑，不会去跟关键用户，不会找领导开会讨论各种待决问题。项目例会从来不开一次，而讨论会最多的永远是技术，而不是最佳方案。

实施期间的各种问题比如业务场景考虑不周，流程线没有考虑撤回退回的情况，蓝图描述不清晰或考虑不全，给出的技术方案背离高效可用的原则，开发的程序各种Bug和不稳定，与第三方系统连接过多，用户培训不到位等等都算是实施质量差的典型例子。

      四、甲方需求多变

我曾经遇到最奇葩的一个项目是甲乙双方都很认真对业务和现状做了很细致的调研，也给出了最初蓝图版本，但最后当开发需求和功能书都准备完毕之后，公司高层下达了对该组织做关闭的通知，也就是说实施范围里的这家子公司关闭了，不上线了，也是滑天下一大稽了。

不仅如此，甲方经常对内部需求往往不明确，最会说的就是：先搞出来看看再说。因此一件事儿往往因为需求多样化的原因迟迟未能确定下来。

其实，顾问加班这个话题永远都是项目管理的问题。导致顾问加班的原因远远不止以上四点，扯的多了就已经不是“加班”两件事儿的事情了，而是上升到了管理层、项目管理等高度了。

可是每个项目都是这么过来，似乎大家已经习惯了做项目加班，也很少人会认真冷静下来想一下是否真的需要如此加班？如果计划可控可执行，如果每个环节都做得相对完美，严格执行项目管理方法论，我想，不加班应该不是难事儿。而且“摒弃加班”应该是项目经理永远需要考虑的必修之课。

不管怎么说，希望类似悲剧事件不要再发生了，各位SAP顾问，保重身体要紧！