客户为什么会变需求？

不是客户想折腾你，也不是客户故意要给你使绊，客户是使用部门，他当然希望你做的东西能一次性就好，他也不想变来变去。之所以需求会变，那一定是事先某些特殊业务场景没有想到，或者某些操作或者逻辑并没有想好。

但凡客户能将就，很凑合，客户也不想总是麻烦你来改。所以当客户的需求变化时，相信我，他也是迫不得已，这对他可能很重要，所以我们一定要改，哪怕增加项目成本，也必须去改。当然这里补一句，那种会逼着客户再掏钱出来改的做法，是销售很牛逼，不在我们讨论范围之内。

客户是使用者，客户往往并不是一个好的管理者，他上ERP，不是为了上套软件，他是希望借用SAP的理念，来提升他的管理，是希望借着实施，让顾问带着自己提升。

所以如果一开始你就任由客户提出解决方案，你只是帮他去实现的话，你的风险就会很大。因为和你沟通的，不一定是高层管理者，有可能只是中层，只是操作人员，在管理上，顾问才是专家，而你按他的解决方案去开发，必然会有很多特殊的场景或者情况考虑不到，上线后，遇到某些突然冒出来的奇怪的需求，或者操作人员有可能犯的奇怪的错误，你只能不停地去打补丁，不停去修补，最后你的方案就会漏洞百出，再也按不住，甚至只能推倒重来。

真正的顾问，不但会主动提出自己的专业的解决方案，还应该想到客户事先并没有想到的点，考虑客户事先并没有意识到的可能会发生的错误或者特殊业务，并且在你的方案中对这类场景做好预案，或者超越客户原始的诉求，给他更多。

只有这样，你能避免上线后频繁的需求变更。说到底，如果客户总是在变需求，只能说明一点，那就是你和客户，事先大家都没有想到。客户没有想到很正常，你是专家，你也没有想到，那你不觉得愧对顾问这个头衔吗？当然结果就是你也做得累，客户也不满意，何来双赢？大家都输了！

第三个理念

第三个理念，不要仅仅为了重现业务去构建流程。经常会遇到有人问我，他说陈老师，我们公司有什么什么业务，请问这个业务在系统里面怎么走？遇到这种问题，其实我很无语。因为系统并不是为了重现你的业务的，如果上系统仅仅是为了重现你之前的业务流程，仅仅是把你在线下所做的事，搬到电脑中来，那是起不到提升管理作用的。

在ERP实施的一开始，都会有一个很重要的环节，叫业务流程重组。

为什么要重组业务流程？

就是因为所有的流程，都是基于管理工具构建的管理流程。当工具变了，流程当然得变。以前用手工单据的时候，你可能需要现场一个签字，现在有系统了，如果系统本身就控管了这个环节，有可能流程就会变化，不再需要签字。如果管理工具变了，还是按以前的流程来走，轻者无法发挥新的管理工具应有的优势和效率，重者反而会让你的流程在新的管理工具下面变成拖累，对管理带来负面影响。

所以千万别再问，我有一个什么业务，想问在系统中怎么走，正确的问法是我有一个什么业务，想要管到什么，系统如何来帮我进行管理。

上面可能说得还是比较抽象，举个例子来说，如果你问我，陈老师，我们公司有大量的辅料领用，这个在系统里要怎么走？这种问法，如果你是我的客户，那没问题，我经过调研，我了解你真正想要管理什么，想要问什么，我可以帮你。但是如果你不是我的客户，你这个问法就不对，辅料领用这个业务中，你关注的到底是什么呢？如果你关注的是辅料领用是否合理，那我可能建议你在系统中引入领料单申请来辅助管理。但如果你其实关注的是辅料金额不大，但是领用量太大，带来巨大的管理成本，不值得，那可能我甚至会建议你根本不要在系统中做物料号管理，直接走费用预算管理。

并不是所有真实业务都要在系统中重现的，系统中控制的往往是关键节点，而哪怕对同一种业务，不同企业的管理重心不同，流程也会大相径庭。所以在我们为客户设计的每一个流程中，都会提炼出这个流程的目的，想要达成什么样管理目的，以方便客户理解为什么我们会为他这样来设计流程，而这些，都会在业务蓝图上以书面的方式醒目地标注出来。

第四个理念

第四个理念，流程都是互相制衡的，制少制衡力量的流程，无法生存。在所有的项目中，几乎绝大部分的流程，都是跨部门的，为什么呢，就是因为跨部门的制衡是流程有效的最佳保证。

如果某个流程，仅仅是在本部门内部，或者某岗位内部进行流转，那么这个缺少第三方监控的流程，很难保证会一直得到严格地、不折不扣的执行。其实这种也不能称为流程了，只能称为操作步骤。

所以顾问们在设计流程的时候，一定要考虑，你这个流程是有制衡力量，能保证其有效性的，如果流程中某个部门，某个岗位不作为，或者错误行事，那必然会有一个机制能发现，这样你的流程才是合理的。

举个例子来说，如果客户提出想统计现场的不良率，那么顾问想到的，不应当仅仅是在生产收货时加个性质来标识良品与不良品，因为你加了这个性质，但不能保证仓库收货的人会正确填写，甚至你都没有机制来发现他其实是在胡乱填写。

正确的做法，是应当把质量部门引入到流程中，在系统中添加一个专门的质量判定单，通过这个质量判定单来收集不良的数据，同时在系统中添加逻辑控制：当没有品质的合格判定时，仓库不允许收货，或者不允许收到超出合格判定数量的货。

这个流程看起来复杂了，但其实更有可行性，因为这张质量判定单在满足客户提出的，想统计不良率这个需求之外，还能带来更多，比如可能为质量部门提供一个数据收集工具，进而为质量部门出一些分析报表，来代替质量部门的手工报表操作。既然能代替质量部门的手工报表，能给他们带来一定的好处，那么他们就会更认真地对待系统的这个功能。

而如果仅仅是在收货上添加一个是否不良的性质字段，会有什么后果？因为缺少监控，仓库可能一开始会不小心填错一些数据，然后管理层和质量部门的手工报表核对，发现不良率好象不对，就不会再信任系统的数据。因为管理层不再信任系统的数据，那就更不会有人再来查，仓库做错的越来越多，发现好象做错了也没什么要紧，最后就胡乱做，甚至不做，这个流程彻底失效，除了增加一点汇报工作量外，一点好处也没有。

设计流程，第一是要有监控，第二是在引入第三方监控的同时，要给第三方带来一点好处。

还以上述为例，假如引入质量部门的质量判定单，却没有给质量部门带来好处，例如没有给他加上他们想要的数据，不能给他们出质量分析报表来代替他们的手工工作，质量还需要在系统外额外维护一套手工报表，那质量部门就不会严肃对待这个流程，他会认为多出来的这一步工作，是为别的部门做的，他没有什么好处，并且质量判定单汇报得正确与否都无所谓，反正他们是用手工报表汇报给管理层的，所以这张单子的正确性就会堪忧，流程也会失效。

因为篇幅的关系，今天我就仅给大家分享这几个我觉得比较重要的理念，这其实只是沧海一粟，同时也是抛砖引玉，希望大家能在项目实施的过程中，不断成长，不断积累，最终形成自己的实施理念和风格，谢谢大家！