天天看点

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

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

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

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

天下没有失败的SAP项目

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

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

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

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

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

不合格的项目团队

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

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

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

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

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

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

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

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

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

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

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

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

太激进的项目计划

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

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

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

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

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

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

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

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

太复杂的项目范围

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

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

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

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

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

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

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

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

小结

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

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

延伸阅读

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

Central Procurement 采购的未来(1)

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