用友T6服装产品业务部总监,一直从事企业信息化及ERP相关的实施与咨询工作,曾就职于报喜鸟集团、红蜻蜓集团等知名企业,具有多个知名服装企业ERP项目咨询及实施经验,主要进行鞋服行业信息化、ERP项目实施与运维、企业电子商务等领域的研究。
　　
　　案例场景:
　　几年前的一个秋天,ERP实施顾问小高因为刚刚完成了一个为期8个月的ERP项目,沉浸在项目成功的喜悦之中。然而让他意想不到的是一件棘手的工作即将落到他头上。公司突然让他接手一个实施到一半的ERP项目,而这个项目只有只言片语的几份简单文档。
　　这个ERP项目的实施已经完成了所有前期的项目准备工作,但就在这个节骨眼儿上,原来的项目经理离职了,留下了一大摊子事情让小高处理。ERP项目实施中的一大忌讳就是临阵换将。最让小高头疼的是:这个项目没有一份经得起推敲的文档——不但没有详细的实施计划、清晰的业务调研报告,也没有前期的业务解决方案,更别提在项目实施过程中涉及的《项目风险登记册》、《项目会议纪要》、《项目需求列表》等更详细的实施文档了。
　　当小高从公司前任ERP项目实施同事手中接过可怜的两个Word文档——总计不超过5页的实施文档时,小高难以置信地看着他问:“没有了吗?只有这些?”同事点点头,然后他又说了一句让人吐血的话:“项目实施所有的内容都在我心里记得清清楚楚呢,之前反正项目就我一个人做,要不要文档也无所谓。”结果,人去“脑”空,项目的一切都要重新摸索,不但要浪费本就紧张的时间做重复的工作,而且与客户的关系也一度紧张,而从公司层面来说,该项目也是亏了血本。
　　在接手了该项目以后,小高深深地体会到了没有实施文档的痛苦,也意识到了项目实施文档的重要性、项目实施规范的重要性。小高从文档做起,从自己做起,一步一个脚印地按照规范完成项目实施工作,必备文档一个不落地完成了。
　　经过几年的锻炼,小高变成了老高,也由实施顾问成长为一名项目经理。项目经理自然需要从项目的角度进行项目管理,而项目实施文档也是他管理项目涉及的内容。
　　但经历了几个项目之后,老高总觉得项目有些不对劲。怎么说呢?这些项目的文档,一个不少,但看文档内容,比如给客户的业务解决方案,好像所有项目都一模一样,用的是之前的项目文档或者是公司的项目实施模板,有的项目文档甚至连客户名称都没有修改过来,直接拷贝、粘贴,再用了查找—替换工具,将文档中的公司名称或者项目名称等关键词替换一下,一份业务解决方案就算完成了。这种方案看似很有份量——厚厚的一本,装订得也很美观,可内容和客户的业务相差甚远,甚至风马牛不相及的业务场景都写进来了。当客户被问到“这个方案经过你们确认了吗?和你们业务相符吗?”客户往往直接说:“这么厚的东西你们自己都看不懂,我们更看不懂,而且方案里的内容和你们后续培训的内容也不太相关,我们就当参考资料看了,觉得有用的就看,没有用的就不看。”
　　老高又郁闷了,没有文档的时候不行,有了文档的时候客户不看,还是不行,问题应该怎么解决?
　　
　　案例解析:
　　在过去的许多年里,ERP项目实施基本上是作坊式的实施——没有章法,实施顾问想怎么做就怎么做,所有的知识都在脑子里;项目做完以后,除了实施顾问长了点个人经验以外,对于公司和其他同事而言,什么都没有留下。
　　经过几年的发展,ERP厂商都开始注重项目实施方法论的建设,也开始强调项目实施过程中的“关键成果与里程碑检查”,项目实施文档就成了必需品。EPR厂商也提出了“项目实施文档一个不能少”的口号并付诸行动,这算是实现了项目实施文档从无到有的过程。老高目前就处于解决了有没有的问题,但他面临着一个新问题,那就是项目实施文档的质量问题。
　　许多企业在构建了项目实施方法论之后,都会制作一个实施模板,这原本是想让实施顾问提高项目实施的效率,因为可以不用思考文档的结构了。以业务解决方案为例,实施步骤可这么划分:第一步描述业务背景,第二步画业务流程图,第三步做流程说明,第四步做当前流程问题解析,第五步做建议方案(可能会有方案一、二、三),第六步做方案对比和建议。但实施顾问有了这样的模板之后,就突然不会思考了。为什么这么说呢?人都是有惰性的,所有文档的结构都一样,再看看内容,好像大多数客户的业务场景也差不多,因此,大多数实施顾问的做法是:找几个历史项目的业务解决方案,参照着复制,一个方案就快速出炉了,修改一下就可以给客户使用了。
　　这样的业务解决方案,从某个业务场景和要点来看,好像很有道理,但从整体业务解决方案来看,前后业务场景脱节,甚至是出现矛盾,或者是客户的重要业务需求漏掉了;还有,对着某个业务场景仔细一琢磨,才发现客户的业务现状与解决方案里的根本不是一回事。结果业务解决方案就被这么套成了摆设,客户就只把它当成参考资料来用,根本没有起到与客户明确项目范围、目标实现方法的作用。
　　接下的事情就会让这个项目变得非常惨了。因为客户根本没有确认前期的业务解决方案,或者即便客户确认了,也只是形式,客户可以在你做方案的时候听你摆布,把方案给签了,但到了上线的时候,客户可就秋后算账了。方案上线后,客户看到这个流程跟自己的业务不相符,那个功能在系统中没有提供,再看看业务流程设置得挺完美,但就是在客户这里用不起來,因为没有考虑客户的特殊情况。这时只能修改了,软件改配置,客户改流程,甚至要更换软件,一直改到双方都受不了折磨了,然后,大家各退一步,将就着用吧,这个系统就这样上线了。到了最后,基本上是实施顾问一撤,系统就废了,成了真正的摆设。
　　上述的场景绝非笔者危言耸听,导致ERP项目失败的“死法”有很多,但这种“死法”让客户很冤。那我们应该如何解决ERP项目实施过程中的文档质量问题呢?
　　告诉实施顾问如何进行思考,这只是一个方向与指引,而作为一家企业而言,还需要在机制上保障实施顾问的思考方向不偏离客户的要求。所以,还需要解决另一个问题,那就是:项目实施文档到底应该怎么管?对于这个问题可以按如下思路来做:
　　1.构建项目实施文档体系
　　在项目实施过程中,列出可供参考的文档模板、必须由客户签署的项目成果文档、可使用的过程文档、相应文档的使用方法、文档是否受控等,得到项目实施文档的清单;基于项目的过程文档和关键成果,通过成果评审得到最佳业务实践(实施案例),并通过最佳实践提炼得到项目实施的模板与指引,这是一层层抽象的过程。
　　2.制定文档管理程序
　　如是否需要评审,是否需要批准,如何发布,如何修订,如何进行标识与界定密级,如何进行贮存,如何进行传递和查阅。
　　3.制定文档模板使用规范
　　如前文所说,文档模板是必需的,这对于提高工作效率有着巨大作用,但对于如何使用这些文档的模板,应该有一个清晰的指引,“只用其形,而不用其里”,这才应该是模板的作用。
　　4.构建项目实施文档库
　　基于项目文档进行版本控制,并构建项目实施的文档库,避免出现文档太多、版本混乱导致的文档无法进行复用的问题。
　　5.构建文档评审与审批机制
　　项目实施过程中重要文档的产生不应该是实施顾问拍脑袋拍出来的结果,也不应该只是简单的复制 粘贴出来的结果,它需要项目小组成员根据客户业务实际情况进行讨论、编写,同时还需要提交给公司主管评审,只有通过评审之后方可发布给客户。只有通过这个机制,才能够保证实施顾问在使用模板的时候不是简单地复制,而是经过认真思考得到的成果,这才是真正帮助客户解决问题的成果,才能得到客户的真正认可。
　　6.使用IT系统进行支撑
　　一个项目的文档好管理,但100个项目呢?一个大型的ERP项目实施过程中,可能会产生上千个文档,没有IT系统对于文档管理制度的支撑,那是难以想象的。
　　总结上述内容:有了项目实施方法论和相应的实施工作模板,并不意味着实施顾问可以不思考了。相反,实施顾问不需要思考简单可重复的工作了,但需要更深入地思考更深层次的问题——客户的核心业务问题,而这个问题的解决对实施顾问提出了更高的要求,当然也更能够体现出实施顾问的价值。