案例分析
在过去的许多年里，ERP项目实施基本上就是“作坊式”的实施，基本上没有章法，实施顾问想怎么做就怎么做，所有的知识都在脑袋里，项目做完以后，除了长了点顾问的个人经验，对于公司和其他同事而言，什么也没有留下。
但这种“作坊式”实施经过几年的项目管理理论指导，ERP软件厂商都开始注重项目实施方法论的建设，也开始强调项目实施过程中的“关键成果与里程碑检查”，项目实施文档就成了“必需品”，也提出了“项目实施文档一个不能少”的口号，算是解决了项目实施文档从无到有的过程。老高目前就处于解决了有没有的问题，但他面临的是一个新问题，那就是项目实施文档的质量问题。
许多企业在构建了项目实施方法论之后，都会有一个实施模板，模板这个东西呢，原本是想让实施顾问提高项目实施的效率，因为可以不用思考文档的结构了。还是拿业务解决方案来说，第一步先讲业务背景，第二步画个业务流程图，第三步做个流程说明，第四步做个当前流程问题解析，第五步做个建议方案（可能会有方案一、二、三），第六步再做个方案对比和建议，一个方案基本就算出来了。但实施顾问有了这样的模板之后，就突然不会思考了，为什么这么说呢？“人都是有惰性的”，这句话你不得不承认吧。那好，因为所有文档的结构都一样的，再看看内容，好像大多数客户的业务场景也差不多。找三个历史项目的业务解决方案出来，参照着Copy，一个方案就可以快速出炉，修整一下就可以给客户使用了。
这样的业务解决方案，从某个业务场景和要点来看，好像很有道理。但从整体业务解决方案来看，前后业务场景脱节，甚至出现矛盾；或者是客户的重要业务需求漏掉了，压根没有体现出来；还有就是对着某个业务场景仔细一琢磨，才发现客户的业务现状根本不是这么一回事，客户想要实现的目标也不靠谱，结果业务解决方案就这么被套成了“摆设”，客户就只是当成了参考资料来用，根本没有起到与客户明确项目范围、目标实现方法的作用。
接下的事情就会让这个项目非常惨了。因为前期的业务解决方案客户根本没有怎么进行确认，或者即便让客户确认了，也是“摆设”，客户可以在你做方案的时候听你摆布，听你一通忽悠，把方案给签了；但到了上线的时候，客户可就“秋后算账”了，一会看到这个流程跟自己的业务不相符，一会看那个功能在系统中没有提供，再看看业务流程设置得挺完美，但就是在客户这里用不起来，因为还有人家的特殊情况呢。项目到了这个时候，要让客户把系统用起来，怎么办？改吧，要不软件改配置，要不客户改流程，甚至要求改软件，一直改到双方都受不了这个折磨了，那行，大家都退一步，将就着用吧，这个系统就这样推上线了，到了最后这个系统的应用效果如何呢？基本上是实施顾问一撤，系统基本就废了，成了真正的“摆设”。
上述场景绝非笔者危言耸听，ERP项目的失败会有许多种“死法”，但这种“死法”客户真的是很冤。那我们应该如何来解决ERP项目实施过程中的文档质量问题呢？这还得对我们的项目实施文档作一个解析。
