ERP企业应该如何给客户提供更好的产品和服务？（一）
图片来自网络。
什么是存量客户?
最近总听到有人说存量客户这个词，所以先拿出来说一下。
难道客户还可以像钱一样存起来吗？
我觉得这个词有点一厢情愿地认为只要是购买过我们软件的客户就会继续找我们购买一样。
ERP的客户是有一些特点：
比如上一套系统的成本较高，合作一次之后，如果想要换调，代价很大，所以客户好像会被我们“绑架”。
但是不管是SAP还是国产软件，我都见过被替换的情况，所以靠沉没成本来绑架客户并认为他们一定还会进行二次购买，这并不靠谱。
又比如项目上线以后，客户一般还需要我们持续不断的进行维护，我们有非常便捷的优势可以近距离观察客户的需求，然后似乎就可以有针对性地给他推荐新的产品，实现二次销售。
但是，这个优势其实是一把双刃剑。
如果项目成功了，确实可以带来持续的产出和口碑，但是如果项目失败了，同样也会带来加倍的负面影响和差评。
正文终于开始了：
这个问题其实是一位“巴菲特”问我的，他想要致力于整合产业链，提供更多的附加值给客户，我们的目标应该是一致的，都是为了更好地提高客户满意度，不过我觉得，虽然ERP已经发展了几十年，但是核心产品和服务，其实依然还存在很大的提升空间，影响客户满意度的因素很多，核心产品和服务才是最基础的，所以我觉得我们应该先满足客户最基础的需求，然后再想附加值的事情。
ERP服务的过程是一个持续的，漫长的过程，在这个过程中，想要持续保持客户的满意度，是非常不容易的。
ERP的中低端客户我了解得不多，我重点说我比较熟悉的高端客户的服务。
ERP的高端客户服务，并不是从实施入场的项目启动才开始，而是从销售跟客户第一次接触的时候就开始了，他也不是项目验收就结束，上线后的持续维护，也是一个漫长的过程。
误区一：ERP产品和服务是分开独立的
表面上看起来，ERP厂商给高端客户提供的是产品+服务，合同也是两份，一份产品合同，一份实施合同，但是ERP的产品很特别，他不像硬件产品一样，一旦生产完毕，就很难在短时间内改变，而有的ERP产品，甚至在签合同的时候连原型都还没有，却可以在项目验收的时候就形成一套产品。
大家听得比较多的，可能是“产品即服务”，但是在高端ERP领域，我认为正好反过来，其实是“服务即产品”，能够在项目周期以内，不管用什么方法，通过流程改造、或者产品配置或者二次开发，生产出满足客户需求的产品或者方案，才是比较常见的事情。
千万不要把项目失败的责任推卸给产品，产品是最无辜的，好的产品可以被人实施得连数据都对不上，差的产品也可以通过好的项目组织（备注1）让他实现高大上的需求。
备注1：我说的项目组织包含项目团队所在公司的组织形式，而不仅仅指负责实施的项目团队本身。
我举个亲身经历的例子。
有种产品叫做BQ，外界喜欢把他叫做大数据分析。
很久以前，我在A公司的时候，这个产品的价格卖得很低，也不容易实施成功，当时我就误以为是这个产品太垃圾，所以一般也不愿意给客户推荐这个产品。
后来，我在B公司的时候，发现这里的大数据项目特别多，金额也很高，还常常都能成为项目亮点，我对这个现象感到非常奇怪，于是先去研究了一下他们的标准产品，结果是我看了第一眼就不想再看第二眼，跟A公司的标准产品比起来，B公司的产品差距非常大。是B公司的项目组织形式让B公司的标准产品实现了逆袭。
误区二：服务取决于个人
还有一个误区，就是表面上看，给客户提供服务的都是个人，那我们是不是把优秀的项目经理和顾问都挖到自己公司来，这样我们就可以提高服务水平？
短时间来看，挖几个人确实可以帮助组织解决眼前的问题，提升短期绩效水平，但是如果组织架构有问题，不能建立一套长效机制来保障客户满意度，那也并不能解决长远的问题，甚至有可能导致当时花大价钱挖过来的人才流失，也会让之前客户满意度非常高的客户最终流失。
内行的人应该都很清楚，就算你不去挖，各种岗位的人员，不管是项目经理、顾问还是开发人员，都由于各种各样的原因，可能已经在各ERP公司里面跳了好几遍，早就跳槽跳得你中有我，我中有你。
尽管有很多高管和人力资源总监都发出警告说：“我们不会任用对公司没有忠诚度，跳槽过于频繁的员工！！！”但是在面对人才异常短缺的情况下，常常又不得不做出要去对方挖人的举措。
那天，我听了一个人力资源大会的讲座，听到一位德高望重的老者对某地方政府做出严厉批评：“劳动人民是没有国籍的，哪里有适合的岗位，他们就会去哪里，储备人才的正确做法应该是为他们提供跟他们能力匹配的岗位，而不是像有的地方政府居然妄想通过一个户口，一套房子来绑住人才，这些都是愚蠢和不自信的表现！”
劳动人民如果连国籍都没有，还会有司籍吗？
那么，如何才能在人才流动频繁的情况下，还能保证项目服务质量？
还记得实施方法论吗？每家ERP公司都有，我想他的初衷应该就是为了让提供服务的人员可以在实施的过程中，按照实施方法论统一步调，在项目换人以后也不至于导致服务水平差距太多。
但是，实施方法论聚焦的仅仅是在单个项目实施过程中的步骤，能够规范的仅仅是单个项目组成员的行为准则，在ERP发展的几十年历程当中，他经历了非常久的时间，某公司的实施方法论已经改版到第九版，且已经在开始做减法，而不是在做加法。
不得不承认，在单个项目实施管理过程中，实施方法论日趋成熟，且取得了巨大的成就。
但是，从横向来看，实施方法论管不到同一时间项目交叉中人员管理的问题；从纵向来看，实施方法论管不到前端的销售和售前，也管不到项目验收以后的运维顾问，更无关服务质量的持续改进。
当然，这些本来就不是实施方法论要解决的问题，我只是觉得要保障项目服务质量，仅仅给客户呈现实施方法论，其实是远远不够的。并且，在人才流动频繁的情况下，知识和技能的同质化程度也已经超乎大家想象，想要通过展示实施方法论来赢得客户认同几乎已经不可能。
但是，在项目交叉的情况下，明确每个顾问或者项目经理最多只能参与的项目个数的规章制度，这还完全是一片空白，ERP厂商领导一味追求利润，无底线压榨顾问和项目经理等行为并没有得到任何管束，只能依靠所谓人品来自由发挥，甚至有人将此看做是项目集管理水平的先进与否，无视顾问和项目经理因为身兼太多项目而导致大幅服务质量水平下降的事实。
误区三：项目组就是项目组织
表面上看，每家ERP厂商给客户提供的项目组组织形式长得都差不多，都是项目领导，项目经理，项目顾问等等组成，并根据是否有二次开发的需求还会增加开发顾问等角色。
但是，项目组的架构差不多，角色差不多，项目成员能力水平也差不多的情况下，项目服务质量也能保持一样吗？
否！
真正影响这个项目组是否可以发挥最大绩效的根源在于项目组成员是否来源于同一个行政组织或者较少的行政组织。
如果项目成员全部都来源于同一个部门，由于完全没有部门壁垒，那整个团队就会非常好协调。
注意，我说的项目成员包含了销售、售前、项目经理、实施顾问、产品经理、测试人员、技术人员、开发人员、售后维护人员。
当所有人都在一个部门，那么沟通线路几乎就是一上一下即可，非常高效：
每增加一个部门，就会多一道部门壁垒，就会为沟通增加难度，为协调资源增加难度。
如果各个项目成员还不在同一家公司，那难度更是指数级增长。
我曾经做了一个项目，项目组成员分别来源于五家公司，经常发生一有项目成员出问题，比如请假，比如支援他们公司的其他项目去了，这种情况，就非要找到对应厂商的总裁才能搞定，项目推动难度非常之大。
未完待续。。。