【陈华讲B1第39期】项目设计中的通用理念

大家好，今天这一讲，我们来聊几个项目设计中的通用理念。这一讲，是专门给SAP B1的从业顾问们准备的，也可以说是我专门想给顾问们说的话吧。

第一个理念：做任何的项目，顾问们一定要进得去，出得来！这句话我在十几年前就对我们团队的顾问就说过。

就是你做任何一个项目的时候，必须要能真正获得客户的认同，真正融入到客户的行业，融入到客户的企业，融入到客户的管理中，只有真正理解了客户，你才能真正设计出客户真正想要的管理流程和逻辑。

在项目实施中，电脑水平、开发能力，这些统统不重要，管理理念、沟通能力，这些才是项目实施中最重要的。

先说管理理念，这个方面其实指的是顾问本身的学识和能力。你要实施的是一个ERP项目，所以你必须要有企业管理的理念和意识，如果你缺少这方面的背景，你是很难做到一个合格的项目经理的。因此你需要在两方面加强：

一个项目进得去，除了顾问本身要有一定的管理理念和学识外，还需要有强大的沟通能力。项目实施就好比驾驭一艘巨船，你需要团结各种力量，如舵手、轮机、导航等，一个团队一起形成合力，才能保证最有效率地抵达目的地。

你的目标是项目成功上线，而不是东风压倒西风，项目成功永远是双赢，而不是零和。所以不要试图去强行说服客户，而是要真正理解客户的关切，通过沟通找到最有效的方法。

另外沟通必须要注意细节，要用客户的语言来说话。例如你在培训时，不要总是说单据未清，因为客户的语言可能是未关闭，或者打开状态；又例如你要习惯把控制科目，改称往来科目等等，沟通时必须要跳出你自己的知识框架，站在客户的角度来说话。

另外在沟通中，你要随时记住你是顾问，你是来帮助客户的，你必须要有强大的自信。自信的来源，一是你事前做好了准备，做足了功能。二是在现场应对意外情况的冷静。在沟通中，当你对客户提出的某个技术细节并不太了解时，你也要能沉着地对客户说，你会下去后仔细做一下测试，然后给他一个正式的回复，而不是现场手足无措，或者心虚地说这好象可以吧，又或者这好象不行吧。如果你自己对自己都不自信，你让客户如何能相信你呢？

这个出得来，指的是当项目上线交付后，你能潇洒转身离开，而不会留下后遗症。要做到这一点，你必须要注意两点：

第一是在设计任何的方案，配置任何的模块时，你都要做足对意外的处置预案。例如操作人员如果没有按你的设想来操作，会不会导致某个报表出现问题？如果会，那么你可能就需要加控制，让操作人员想错也错不了，又或者加一张查错的报表，当出现问题时，操作人员能利用这张报表来检查可能出现的错误。

另外任何的错误，都应当有弥补的机制。例如可以进行红冲，或者取消重做，或者设计一个反向业务来回滚等等。所有的方案必须要能容错，能健壮，能纠错。只有这样，在上线后，才不会出现异常时，让客户只能找你，而你被迫要花大量的时间去检查，去修改报表或者打补丁，以兼容各式各样、意料之外的奇怪操作。

当然我所了解到的，在有些情况下，有很多实施公司恰恰是不希望客户自己处理，而是发生问题后，让他们的售后来帮助处理，好象还能给客户形成付出很多，或者很人性化的、全方位的客户关怀的印象，这样每年收取维护费，客户也觉得物有所值。这种考虑基于商务，或者公司本身的生存所采取的策略，和我们今天讨论的顾问的实施理念是不同的，不能说谁对谁错，只能说理念不同。

第二个理念：不要抱怨客户有多么不讲理，出现的任何问题，都有可能是顾问自身的问题！这个观点，听起来很极端，可能会让很多顾问不服气。正常情况下，客户和顾问的关切和目标是一致的，大家都想把项目做好，都想让系统顺利上线，如果在项目实施过程中，客户表现出不讲理，甚至不配合，那顾问就需要反思，是不是自己做错了什么。

例如在需求阶段，如果客户总会提出软件无法实现的需求，顾问不应当急着去反驳或者拒绝，如果你第一反应就是去反对他，只能说明这个顾问仍然是基于自己的软件，基于自己的交付在反对，反对的最深层次理由，或许仅仅是因为项目成本可能超出预期，或者单纯是不想给自己添加麻烦，这就违背了ERP实施所应秉承的最基本的理念，那就是说到底，上ERP是为了提升管理，而不是为了上套软件。

因此遇到客户提出软件无法实现的需求时，你需要先站在客户的角度和立场，找出隐藏在客户“需求”背后更本质的需求。因为这个时候，客户其实提的并不是一个真正的需求，而是基于他的经验和知识架构，提出的一个解决方案。

下面我们举个简单的例子来分析：例如在需求调研的时候，客户告诉你，他需要对生产收货做审批。

真正的顾问会怎么思考？

他会马上意识到，对生产收货做审批，这是他的需求吗？不对，这仅仅是客户提出的一个解决方案，他希望在软件中实现对生产收货进行把关。

所以SAP中，并没有把生产收货审批，当成一个管理上的解决方案，这恰恰是SAP的管理专家高明之处。

当顾问真正相信自己的产品，理解自己产品的逻辑后，他就可以针对客户在管理上的需求，提出基于SAP管理理念的，更为高明的解决方案。有了更好的解决方案，那客户也不会再坚持他原有的想法的。

所以如果顾问觉得，客户总是提出不合理的需求，那往往就是顾问的问题，顾问没有真正理解客户，没有真正站在客户管理的高度来思考，甚到顾问完全没有理解SAP的管理理念，需要再好好修炼自己的内功。

还有一种现象，是在我们一个偏技术的顾问身上总是会发生的。这个顾问技术很强，遇到所有的问题，他都可以很轻松的用技术、用开发来解决。但他最多的抱怨就是客户太善变了，本来说好的一个方案，邮件也确认了，所有部门都认同了，事后还是会变，想变就变，太不讲理了，搞得他做得很累，还得不到认同。

确实，这个顾问很辛苦，加班到凌晨两点是很常见的事，我非常喜欢他的勤劳，但是我很憎恨他的技术，因为在我看来，他做得这么累，客户总是会变需求，并不是客户的问题，也不是客户不讲理，恰恰是因为他的技术太强，制约了他往真正的顾问方向去转变和发展。

客户为什么会变需求？

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

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

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

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

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

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

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

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

为什么要重组业务流程？

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

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

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

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

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

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

1

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

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

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

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

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

2

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

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