【陈华讲B1第40期】SAP上线验收及再探ERP本质

对于SAP上线验收，从项目控制的角度，其实包含两个内容，一是上线，第二才是验收。

上线当然不等于验收。顾问导入期初后，把期初数据，包含科目余额、往来明细、库存批次余额等再以报表的形式打印出来，交付财务签字确认，数据没问题后，正式启用SAP系统，各部门按既定流程开始使用，这叫上线。

而验收，通常是在系统上线后，双方确定系统是否真正达成了预期的目标、是否可以转入正常售后运维的这个过程。验收往往会放在第一个月月结后，通过财务报表，可以完整的校验新系统的运行状况，还能通过整月的运行，用各部门真实的业务流转数据，来检验系统是否达成预期的目标。所以在验收的阶段，通常可以用财务报表，再加上业务蓝图中各流程的管理目标，结合起来形成一套验收文档，让各部门确认并签核，最终给出验收是否合格的意见。

项目在上线验收后，就可以转入售后的运维。实施顾问需要把整套的实施文档，包括调研记录、配置文档、会议纪要等等，全部移交售后，由售后来帮助客户进行日常的运维工作。

有些客户可能在上线验收的时候会比较犹豫，总感觉签字以后，好像实施顾问就不管他了。这其实是一种误解。在SAP的实施没有重大问题，需求都得到满足，也能达到双方预期目标的前提下，转入售后的运维是非常重要，也是对客户有利的。

因为在一个成熟的实施公司中，顾问好比冲锋陷阵的将军，一个项目结束后，会转战另一个项目。而售后的运维部门，才是能24小时响应客户问题的窗口，当客户在系统运行中，遇到比较紧急的问题时，不一定能第一时间找到顾问，但一定能第一时间找到售后。所以移交售后，让售后能知道项目的来龙去脉，能知道设计的初衷，无疑对准确、及时为客户提供帮助，是有积极作用的。

一个成功实施的SAP项目，顾问公司和客户之间，一定是一种战略合作的关系，比如我们是一家年轻的公司，但也有很多客户，伴随我们一路走了十几年，这些客户，从初上SAP时的十几个人的小团队，一直到今天在创业板，在科创板上市，市值有到上千亿的，一直在用SAP。

在这么多年一路走来，客户总会有新的需求，也总会有新的问题，实施方和客户的合作一定是长期的，一定是战略性的。不存在签了上线验收报告，理清了责任，就各回各家，老死不相往来，真的发生这种情况，那要么就是SAP上得太成功，客户完全没有新的想法，也没有任何的问题（这种概率太小）。要么就是SAP的实施让大家都很失望，但又不承认失败，只能勉强凑合着用，有问题也不再抱能解决的期许，自己绕着就走了。出现这种情况，那双方都失败了。

我一直和客户说，如果有一天，你要和我们来纠结合同的条款，要来钻研合同的字眼，那我们双方都失败了。做项目成功的标志，就是双方都满意，能彼此信任，形成长期的合作，这才叫SAP上线成功。

以上只是从项目实施控制的角度来对上线和验收做的说明。大家要注意，项目实施控制，这是项目管理的范畴。如果抛开项目管理，抛开项目成本的考量，抛开一切可能的法律上的纠纷，仅从SAP实施的效果来讨论，其实我还想说说另一层意思。

SAP的上线，仅仅是实施项目阶段的结束，同时也是更重要的一个开端。

在本课程的开始几课，我们曾经分享过，ERP到底是如何来帮助企业提升管理的。我们说ERP最重要的作用，是保证流程的有效性。当高层管理者确定了自己企业的内部管理逻辑，确定了企业要如何运作之后，把自己的意图，用流程的方式确定下来。这就是立了一个规矩，而ERP就是高层管理者用来保证这个规矩能得到切实执行和落实的一个工具。当所有的人都在同一个平台上进行工作，那他就必须要遵守这个平台的规则，否则他无法把自己的工作进行下去。

这个平台，就是ERP，ERP通过这种方式，就能保证一个企业的运作，是按照既定的规则来的，不会偏离高层管理者的意图。

所以SAP上线，其实只是意味着从上线的这一刻，企业的管理工具、企业的做事平台发生了变化，从以前的手工方式（例如纸质单据，或者EXCEL单据等），或者其它品牌的ERP工具，切换到了用SAP来作为工具进行管理，仅仅是工具发生了变化、平台发生了变化。但这个工具、这个平台起到的作用，发挥的威力，肯定不会马上在上线这一刻就能立刻凸显。

SAP实施前，我们定好了一些目标：我们通过引入SAP，要达到什么目的，要在哪些方面加强管理。带着这些目标，我们重构了我们的管理逻辑，设计了我们新的流程，然后在SAP实施中，我们利用SAP这个工具，把流程进行了固化，让流程的有效性得到了保证。

在SAP上线时，切换到了新的平台，相当于我们改变了内部的规则，为大家增加了一些约束，引入了一套新的框架。而这套规则的运作，到底能不能达成我们预想的目的，能不能真的如预期一样提升我们的管理，这往往是需要一段时间之后，才能慢慢发现的。上线也好，月结后的验收也好，其实只能验证SAP是否是按预期在运作，而通过这个运作，是否真的能提升管理，能达成目标，这个需要坚持，需要时间来验证。

SAP良好的运作不是目的，如果我们以为SAP上线后，能正常运作，就是达成目的，那就变成了为上 ERP而上ERP，毫无意义。我们必须要在SAP运作的基础上，来评估管理逻辑本身是否靠得住，能否解决我们的问题，这才是引入SAP的目的。

而是否解决了我们的问题，大概率的，并不是在上线的时候就可以显现出来，而是要坚持数周、数月，甚至坚持好几年后才能有效果。有很多企业的沉疴顽疾，并不是在工具本身，而是在企业文化、风气、各部门的做事风格、中层干部的意识、理念等等。

切换到SAP，并不能马上扭转他们的思路，也不能马上就让企业面目一新。切换到SAP，可能一开始还会让有些部门很不爽，以前很自由散懒的做事方式，可能以后会麻烦不断，但是上了SAP，枷锁架到脖子上，没办法，只能先按SAP的方式走。时间长了，养成习惯，各部门慢慢适应，自然而然做事的风格、企业的内部文化，就会变得越来越良性发展，几年以后再来回顾，可能就会惊觉，企业的面貌在不经意间发生了天翻地覆的变化。

如果认识到了这一点，有可能你就会接受我经常对客户说的一句话：SAP上线有问题是好事，如果没问题，上线就运作良好，各部门和光同尘，相安无事，反而可能是一件可怕的事情。你也有可能还会接受另一句话，那就是：我们做SAP的顾问，在设计流程、配置功能的时候，有时候会故意增加一些障碍，本来操作人员可能几秒钟就能完成的工作，我们有可能会故意让他变得很麻烦，需要好几分钟，甚至好几个小时才能完成。这句话是十年前我们SAP顾问界一个前辈大佬对客户说的，当时我听了后，深以为然。其中的滋味，各位可以自己再细细咀嚼。

上线以后，各种问题会暴露，以前一点问题也没有的，现在突然发现很乱。以前的成本都是平平稳稳，现在突然上窜下跳。这绝对不是SAP不好，这恰恰是SAP上线后显示的第一个威力：把以前掩盖的问题全部给你暴露出来，可以引起管理层的关注。你可以抱怨为什么部门间的流转会有这么多问题，而不应当去抱怨SAP出来的数字不好看，不够漂亮，你应当惊讶以前没有管这么细的时候，原来在细节上有这么多随意，留下这么多的隐患。通过暴露问题，再去解决这些问题，这难道不是在提升企业的管理水平吗？

所以上线也好，验收也好，只是项目实施的阶段性结束。要真正达到上项目的目的，还需要长时间的坚持。但是这个坚持，光靠顾问，光靠实施方是不现实的。毕竟B1的项目实施成本有限，顾问只能把理念灌输给管理层，只能帮助设计好纸上的业务蓝图，配置好系统的游戏规则，而只有企业的高层，才能真正起到让项目最终落地的作用，而不至于让系统偏离，屈从于各部门的抱怨。

要实现这一点，有两个关键的要素：

举一个真实的例子，刚好最近我们的客户发生了这么一件事情。在项目实施中，我们为这个客户建议了一个关于预付款的管理流程，在这个流程中，有两个关键的点：

大家都知道，在SAP的标准功能中，预付款申请是可以基于采购收货或者采购订单的。此外在SAP的标准逻辑中，采购通常所使用的物流许可，是不能做预付款申请的，而财务使用的财务许可，却能做预付款申请。

所以客户上线以后，首先为了节约许可，预付款申请改由财务做，然后交由出纳付款。其次他们有很多是货到付款的业务，货先到，但票未到，这时候要付款，他们就基于收货单做预付款申请，然后对供应商付款。

看起来好像也没什么问题，财务自己做的预付款，他们觉得可以自己掌控，所以财务是能接受的。而对于货到付款，基于收货才做预付申请，采购也觉得理所当然，因为这就是真实的业务，各部门都没问题。

我先来解释一下我们设计这个流程的原因，主要有以下几个关键的点：

首先是在这个流程的背后，其实隐藏着的，是对企业现金流良性运作的考量。企业有计划地对外付款，可以让企业未雨绸缪，提前安排自己的资金流转。所以预付款的提出，越早越好，在下合同的时候，如果就能让财务知道即将在几月几号，会发生一笔对外的预付，那显然对企业的良性资金安排，是有作用的。

其次货到付款，实质上也是一种预付，这种预付也是在签合同的时候就能知晓的，在系统中只要有采购合同，就应当按合同条款提出预付款申请，便于财务提前做好准备。所以实际上不应当存在基于收货的申请，只有基于合同的申请。也只有基于合同的申请，才是合法有效，并且也才能起到让财务提前做好资金准备的作用。

基于收货的预付请求，那是逼着财务马上就要按条款付钱，完全没有给财务任何准备的时间。这里也说明一个细节，在SAP中，预付款申请，是有一个要求付款日期的，我们叫到期日。所以并不存在提了申请马上财务就得付款。

财务真正要的，是可以通过系统看到在什么时间，即将付什么样的一笔款，付多少出去，这才是对财务有用的信息，并且是越早得到这个信息越好。所以预付款申请，本质上起到的，是和应付发票同样的作用，那就是可以让财务据此提前安排资金计划。

当然对于货到付款，可能有些客户会担心一个风险，那就是如果基于合同做的申请，怎么能保证货真正收到了呢？这个其实不用担心。

1

第一在系统里面，财务付款的时候，可以根据付款条款，方便地用关系印射等，能直观查看该申请是否可以真正支付了。这也是为什么要让采购提请求，财务审核和执行，而不是让财务自己给自己提申请的目的。

2

第二是SAP中也可以补充增加控制，对货到付款的条款，虽然也必须基于合同做请求，但是真正付款的时候，SAP可以自动检查对应的订单是否收货，以此来杜绝人为的疏失。

最后，为什么流程上一定坚持是由采购来提申请，财务执行呢。除了上面说的理由外，其实还基于下面几条理由：

01

第一是采购订单是由采购录入的，采购可以录入订单后，第一时间自动生成，或者手工制作申请单，尽量早的让财务有所准备。

02

第二是预付款对一个企业的现金流，有着负面的影响，我们应当控制这个比例越少越好，尽量都是后付款的模式。但是哪些供应商能谈，哪些供应商不能谈，采购才清楚，其它任何部门都没法判断。

所以我们要对采购有考核，例如一年的采购金额中，不超过百分之多少的比例是预付等，然后逐年要求采购降这个指标。这个指标应该是考核采购经理，而不是采购员，所以每一张预付款申请，我们都建议由采购生成，采购经理审批。只要采购经理同意了，财务就没有理由不同意，只需要按审批后的申请付款日期，提前准备资金即可。

所以你看，一个简单的流程，要真正达到让企业在几年后，面貌一新，有可能现在就会让各部门相当不痛快，做起来相当麻烦。而我们要妥协于部门，还是要坚持初衷？这个往往不是部门经理的层面可以理解的，是要有高层来考量，并且由高层一直来保驾护航，而不会在上线后半年、一年、数年后屈从于操作人员的抱怨，屈从于部门的反对就越走越偏。

还好这家客户，目前的结果是好的，因为他们新来的IT很坚持，引起高层的重视，出面主持了几个电话会议，也和采购、财务一起进行了详细沟通，最后确定坚持设计之初的逻辑，我衷心希望这个客户在数年以后，能体会到SAP给他们带来的巨大改变。

大家都经常听说，ERP是一把手工程，为什么是一把手工程？可以细细再思考一下。当然也有一些反例，如果某一个企业的部门级的力量太强大，也会把项目导向危险的境地。

有一个客户，是十年前的一个老客户，当年我帮他们上SAP系统的时候，企业很年青，团队很年青，老板很年青，当然顾问也很年青！但是十年后，企业发展壮大了，由一家工厂，变成了数家工厂的一个集团化企业。为了适应企业新的发展，为了上市，重新选型。在选型的时候，就出现了偏差，老板不再像第一次上项目一样，亲自出面进行评估，主持选型的总经理，也基本只是起到协调、开会的作用。具体新系统要满足什么要求，要实现什么目标，全部是各部门自己提。

而各部门提的需求，竟然还不全部是部门负责人，基于部门管理的角度提的，很大一部分是操作人员提的，全部集中在要有什么功能，要有什么操作，要如何如何便捷。然后用这些需求来评估合适的ERP软件。

这一次，客户虽然仍然选择了SAP   B1，但是实施效果，在我看来，其实并不一定会比第一次的效果更好。至少会留下很多可能在数年后再发作的隐患。因为在项目实施的沟通中，高层基本不再出面，客户方的项目经理有时候还必须要哄着操作人员往下走。我们的顾问花了大部分的时间，在构建不同的便捷功能，例如通过总公司的销售订单，一键生成各分子公司对应的销售、生产单据等，又例如一键批量生成出入库单据等等。但是很少、很少、很少有人来关注流程的逻辑，来关注改变以前的做法，来达成更好的目标。也不会再有人来听取顾问关于管理逻辑的建议，而是更多坚持了自己习惯的做法。

俗话说，外行人看热闹，内行人看门道，我想这句话用在这里最合适不过，看起来纷繁复杂的功能，一键生成的便捷，让SAP B1变得相当强大，和他们现在的做法，习惯的做法几乎一模一样，完美复刻，但是这样的系统，除了起到电子单据的作用外，还保留了多少有意义的管理理念呢？

SAP B1太强大了，强大得在我们顾问手里，可以轻松满足任何功能上的要求。所以当我们建议不同的管理人员、不同地理位置的仓库分开管理，便于盘点和考核责任人，操作部门坚持要用自己的方式来区分，只是了方便一眼看到时，如果没有高层出来决断，那我们顾问为了项目的顺利交付，只能“以勤补拙”，要什么功能给什么功能，要把B1变成什么样，就变成什么样。用客户方项目经理的话来说，只能先帮助他们操作，哄着他们接受，再来考虑如何提升管理了。

这其实就是大多数快速发展的中小企业经常会面临的问题，企业发展大了，人员多了，有了大企业的身段，但没有长大企业的脑子，还没有形成固定的管理逻辑的时候，过分依从于操作人员的七嘴八舌。这其实不是操作人员的错，而是高层人员的失职，或者高层人员的管理水平没有跟上企业的发展，没有对如何形成自己内部的管理逻辑有清醒的认识。

ERP从来就不是一个过度关注操作功能的软件。

前不久有一位同行告诉我，国外又出一些什么新的东西，有什么新的功能，可以自动完成什么工作，未来可能会代替ERP。

我不这么认为，ERP本质是一个用来管人的软件，而不是用来帮助你操作的软件。这就好比一条流水线，ERP并不是流水线上帮你快速拧螺丝的工具，ERP有可能是控制这条流水线速度的开关，它让流水线变得快还是变得慢，从来不取决于流水线的工人，而是取决于流水线的设计者。如果选用什么流水线，让工人来提要求，那会发生什么？这条流水线的效率永远不是最高的，产出的质量也永远不是最好的，但它却是对操作工人而言最舒服的。

为什么我认为ERP短时间还不能被替代？

因为ERP是用来管人的，如何管人，让一帮人集中起来像一台机器一样，朝着一个目标合力前行，这门科学还远达不到自动化，远达不到让电脑来管的程度。人越多的时候，状况越多，管理的复杂度会几何级增加。

一个企业10个人的时候，只需要一个管理者，而这个企业100个人的时候，管理者的数量并不能简单乘以10，可能会需要20个管理者。据百度资料，中国西汉的时候，大约一个官可以管8000个人，唐朝的时候，一个官可以管3000人，清朝的时候，一个官只能管900个人，现在呢？美国的官民比例是1:12，平均一个公务员对应12个人口。

这并不是因为管理效率低了，也不是因为时代在倒退、不再岁月静好。最重要的一个因素就是人口增加，管理难度就会几何级增长。所以当企业只有10个人的时候，你可能并不需要什么 ERP来帮你管理。而当企业100个人的时候，你可能就需要一个ERP软件来辅助你管理了。

所以ERP最重要的，真不是功能，而是内在的逻辑和管理理念。

就以SAP的产品为例，经常听人抱怨，说SAP针对集团用户的S4太麻烦，写个报表要开发，加个控制也不能像B1一样随心所欲，做错单据，那更是天都塌下来，要费尽周折才能调整。

是S4的技术还比不上B1吗？并不是这样，是因为S4的目标用户是成熟的大企业。大企业远比中小企业管理复杂度要高，一不留神，这头巨兽可能就会走偏，导致危险悄悄发生。所以大企业更注重风险控制，更在意规矩，所以当你在S4做错单据，你可能需要闹得全天下都知道，你才能调整，并且调整后，还会遗留一定的后果。而你为之付出的时间、麻烦，这些管理成本，是成熟大企业不在意的，他们真正在意的，是一切要按既定规则来。

B1的客户是快速发展的中小企业，中小企业和成熟的大企业不同，内在的管理逻辑还没有真正定型，并且对管理成本也更敏感，所以B1的自由度就远比S4要高，在功能上的可调配型也更灵活。但是你能因此说B1比S4更强吗？

一个用来管人的软件，并不会被多了什么便捷功能，加了什么自动标签的软件代替。

ERP真正的终结，在于不需要管人的时代的来临。当无人工厂出现，当无人供应链来临的时候，这个时候就不再需要ERP，这个时候才需拥有各种华丽功能的软件来代替了。当那个时代来临时，软件自动下单，自动出入库，自动汇报，单号永远一对一关联。

而在那个时代来临前，ERP永远需要对人进行管理，需要考核不同的岗位，让他们能发挥最大能动性，让他们主动去关注异常的处理，只要人还在，ERP就不会被替代。而只要ERP还在，ERP就永远是用来管人，而不是用来帮助人的。

所以顺便说一句，现在热推的什么RPA，我个人的观点：这只是时代的一个过渡阶段而已，可以理解为从ERP到无人工厂的控制系统演变过程中，一个小小的插曲。

更深地理解了ERP能发挥什么作用，会如何发挥作用，我们才更能理解SAP的上线，仅仅是一个开始。也更能理解在项目选型中，为什么功能永远不是最重要的。也更能鞭策自己，在项目实施中，永远要战战兢兢、如临深渊、如履薄冰。因为你把控的，是一条巨船，这条巨船会面临很多未知的异常和变数，只有顾问自己清醒，你才能把这些理念灌输给客户，你才能做出真正的优质项目。

至于功能？不重要，SAP什么都能做到，这个不是大话，也不是我狂妄，请相信我，还是那句老话：没有B1做不到的，只有顾问做不到的！