3种团队分组适应项目_搞砸SAP项目的3种方法

在一次上线之后，我和几位项目里的战友坐在街角的夜宵摊前，啜着啤酒啃着串，分享着各自的SAP故事。

不知什么时候开始，话题转向了各自经历的，失败的或濒临失败的项目经验。

这也进而让我想把那天聊到的一些内容写下来。

天下没有失败的SAP项目

在SAP圈子里我听说过一句话：“SAP项目上线永远是成功的”。

因为“成功的”是一个形容词，这就让每个人都有各自充分发挥的空间。你可以认为数据全部导入就算成功，也可以认为第一个订单创建就算成功，还可以认为月结完成就算成功。

但一个项目是否成功，相信每个参与了项目的人，心里都有一杆秤。

就算因为公司的压力或是团队的荣誉，其实很难在口头上承认一个项目最终其实是挺失败的，但或多或少，内心都会有自己的判断。

SAP项目里的失败，要么牵扯到人，要么牵扯到事，让我们先从人说起。

不合格的项目团队

顾问团队，一定是SAP项目里最重要的资源，以及确保项目能成功的最重要因素之一。

如果能拥有一个技术过硬，经验老道，相处融洽，彼此配合的顾问团队，那这个项目还没开始，就成功了一半。

技术过硬，经验老道，代表着自己模块里的大事小情都能从容应对，就算偶尔出现个难点，查查notes也能解决。当然，并不用项目组里的每个人都是高手，但至少每个模块能有一个独当一面的顾问，再配合一些实习顾问，项目就能成功运转下去。

现在市场上有些项目，或许是受限于成本，最资深的顾问都不超过三年经验。三年，可能才做了两个项目，接触过一两个行业，就算学习能力强，愿意加班追赶，也是很难独挑大梁，让客户满意的。

客户总是喜欢那种有着成熟、自信、一切尽在掌握的顾问，而这些气质，都得靠时间磨练。

技术不够好，就不够自信，跟客户讲话就没有底气，客户就会对顾问不买账。

另一种情况，是技术到位了，但顾问之间彼此没有配合。

足球场上，有再厉害的前锋，也得中场喂球才能有射门的机会。

顾问之间的配合，有时候会比你想象得更重要。

记得有一个国企项目，客户老总别出心裁地在大礼堂里召集全公司的人一起看SAP集成测试的报告会。每个模块的用户都要上去操作，而顾问在下面支持。偏偏其中MM顾问就是个没有太多团队精神的人，觉得其他模块的测试跟自己关系不大，给PP和SD模块用的测试物料都创建得乱七八糟，一些问题用户又没有能力当场就解决，导致现场意外不断，状况频出。

结果就是客户老总大怒，项目整风反思一个月。而这多花的一个月的时间，就源自那一点点的配合不畅。

一切问题，归根结底都是人的问题，人有问题，项目还怎么可能成功？

太激进的项目计划

不知道是不是咱们骨子里都有点好大喜功的基因一脉相传下来，就跟很多其他事情一样，我们做SAP项目也喜欢“大干快上”。原本十个月正好完成的项目，因为各种原因可能压缩到六个月就要上线。

这就像建房子，为了赶工期，一楼的水泥还没干透就着急忙慌地赶着盖二楼，这质量能好么？将来房子倒了，又该怪谁？是决策者太着急，还是项目管理者没做好计划，还是执行者没做好实施呢？

我参与过不止一个项目，都是有着最紧绷的项目计划。每一项任务都按照没有任何空间和余地的方法在安排。

系统配置给三天，集成测试给一周，用户培训给两天。这样的安排方式，让无论是顾问还是用户都只能蒙头赶路，顾不上身边的细节。

欠的债早晚是要还的，配置时疏忽的点，测试时遗漏的业务场景，培训时没有提到的关键，都会或早或晚地爆发出来。

最终，SAP系统的使用者们会觉得这是个方案不完善、细节有缺陷的系统，从而产生抵触情绪，根本不信任系统。

那你说这样的项目，就算匆匆忙忙上线了，能算成功么？

太复杂的项目范围

另一种让项目成为炸药桶的方式，就是拥有不断扩张，太过复杂的项目范围。

老子在《道德经》里告诫世人要懂得“知止”，说的就是过犹不及的道理。

而SAP项目里，无论是顾问，还是项目经理，非常重要的一点就是懂得Say No。

或许我们都碰到过，在项目范围已经锁定，蓝图已经完成，配置已经做好的情况下，客户又有了新的需求，新的想法。这不是不允许的，只是必须要非常谨慎，因为无数项目都是因为变更管理没有做好，而进入后期无法按质按量交付的尴尬境地。

有的项目经理就在这一点上做得很好，我记得曾经跟一位墨西哥来的项目经理合作。他在蓝图确定之后的大会上，就对台下大大小小用户说：“从现在开始，你们可以来向我提要求。但是，请记住，我的默认答案就是No，除非你有非常强的理由（例如法律规定）能够说服我。不然，你会得到的回答就是No”。

还有些客户是第一次搭建企业信息系统，想着一次就要做到尽善尽美，一口吃成个胖子。项目范围里塞满了各种必须的，不必须的功能。看起来咨询公司能做个大项目，可吃得多了，也容易噎着。

我有幸亲眼见证过一个有上百个顾问、大几百个世界各地用户参与，花费了上千万美元的巨型SAP项目。其中需求的复杂度超乎想象，开发的功能不计其数。最终这样一个巨无霸在几年后，因为系统太过庞杂，没有人懂得里面所有的细节，后续维护成本太高被迫停止使用。业务功能被重新拆散到多个不同的IT系统中去。

少即是多，这恐怕是很多人耗费无数金钱和努力换来的至理名言了。

小结

项目想做好，要方方面面的努力。而想搞砸，只要有一个败笔就够了。

咱们一起，有则改之，无则加勉吧。

延伸阅读

你准备好成为SAP自由顾问了吗？

Central Procurement 采购的未来（1）

做SAP顾问，需要什么样的英语水平