平台型CRM把灵活度给你，配置与维护这两笔投入账要提前算清
平台型CRM把灵活度给你，配置与维护的投入账要提前算清楚
一、平台型的重心在哪
十种形态里，平台型是块头最大的一类。它的重心不在某一个具体功能上，而在「让你自己搭」这件事上。
判断一款产品是不是平台型，看一个地方就够了：它把多少东西留给你自己定义。字段、流程、权限、界面、报表，如果这些都能由企业自己配置，甚至能通过接口和自建应用往外延伸。那它就是平台型。
这类产品的假设是：企业的业务各不相同，与其做一百个预置方案，不如做一套足够灵活的基础能力，让每家企业自己长出符合自己流程的样子。这个假设在很多场景下是成立的，尤其是流程复杂、参与角色多的企业。
但假设成立不等于用起来轻松。灵活度是一把双刃剑，它把决定权交给你，同时也把搭建的工作交给你。这一点在选型时最容易被低估。
还有一点值得说明：平台型不是功能少的代名词。它的功能往往并不少，只是这些功能被设计成可组合的零件，而不是固定好的套餐。所以看它的功能清单意义不大，看它能被组合成什么才有意义。
- ● 重心不在功能多少，而在让你自己搭
还有一层分别要看清楚：可定制针对的是规则能不能改，而可用性针对的是改起来顺不顺。两件事都重要，前者决定能不能做，后者决定愿不愿意做。只满足前者的产品，往往需要专职的人来伺候。
- ● 灵活度把决定权交给你，也把活儿交给你
图1：可定制的产品，落地节奏也不一样
二、可定制到底意味着什么
「可定制」这三个字被用得很泛，实际包含的东西并不一样。
最容易的一层是改显示。摊开讲，字段名称、界面顺序、列表里显示哪几列，这些调整不需要逻辑上的改动。改完立刻生效。大部分产品都能做到这一层。
再往上一层是改流转。审批节点怎么走、什么条件下自动推进、超时之后交给谁。这些涉及业务规则的调整。这一层需要产品有流程引擎，配置起来要理解规则之间的关系。
最难的一层是改结构。新增一类业务对象、把两套流程打通、让数据在多个模块之间自动流转。这一层往往需要借助开发。做到这一层的产品，其实已经不止是客户管理工具，而是一个业务平台。
三层之间的差别很大，而销售在介绍时通常会把三层混在一起说。分辨的办法是当场让对方演示具体是哪一层。
三层之间的边界有时会模糊。同一个调整，在配置能力强的产品上只需要改几项设置。在配置能力弱的产品上却需要开发。所以判断的时候不要只问能不能改，要问改这一处需要谁动手、需要多久。
还有一个更直接的判断方式：让对方当场改一处给你看。改一个字段的填写规则、加一步审批节点、调一下列表的显示顺序，几分钟能做完的，说明配置能力是真的；要回去评估的，往往就是另一回事了。
- ● 改显示、改流转、改结构，三层难度完全不同
分层看还有一个附带的好处：预算和分工可以提前算。改显示这一层业务自己就能做，改流转这一层可能需要内部有人专门承接。改结构这一层通常要外部支持。三层各归各的投入，账就好算了。
- ● 分辨的办法是当场看对方演示哪一层
图2：流程能不能自己改，是定制程度的试金石
三、代价一：配置本身就是一项投入
可定制带来的第一项代价，是配置阶段的时间投入。
预置型的产品，上线基本就是开通账号、导入数据、培训一轮。动作相对固定。平台型不是这样，它需要先把业务规则梳理清楚，再一条一条配到系统里。梳理这一步的深浅，直接决定后面配置的质量。
这项工作最难的地方在于，它要求业务人员把自己的流程讲清楚。坦率讲，很多人平时做事靠默契，一旦要写成规则就发现有不少地方自己也说不准。这个把默契变成规则的过程，是配置阶段最耗时间的部分。
所以平台型的项目通常有一个明显的特征：前期慢，后期快。前期把规则理顺之后，后面的调整都变成改配置；前期敷衍过去，后面就会不断返工。
配置阶段的投入很难被准确预估。同样的规则，梳理得清楚和梳理得不清楚。工作量可能差出好几倍。所以预留时间时要留出富余，不要按最理想的情况排计划。
- ● 前期慢后期快，是这类项目的常态
- ● 把默契写成规则，是配置阶段最费时间的部分
图3：配置投入有多少，上线前就能估出来
四、代价二：谁来维护这套配置
第二项代价是持续维护，这一项比上线时更容易出问题。
平台型的系统上线之后，业务总会变：新增一类环节、调整一次审批、合并两个团队。这些调整如果能由企业自己完成，平台的价值才真正体现；如果每次都要等厂商，系统就会慢慢落在业务后面。
所以判断一款平台型产品，除了看能不能配，更要看配的人在企业内部有没有。常见的情况是，配置能力很足，但企业内部没有承接的人。结果又回到依赖厂商的老路上。
承接的人不一定是技术岗位。多数情况下，一位熟悉业务、愿意琢磨规则的业务骨干就够用。关键是他能不能拿到足够清晰的配置说明，以及调整之后能不能自己验证效果。
承接的人还需要一个容易被忽略的条件：他要有时间。不少企业选了平台型，也安排了业务骨干负责，但那位骨干手上还压着一堆事。配置的活儿一直往后排。安排人的时候要把时间一起安排进去，否则等于没安排。
- ● 能力再足，企业里没人承接也用不出来
- ● 承接的人不必是技术岗，业务骨干就能做
图4：扩展能力决定这套系统能走多远
五、怎么判断一款平台型产品值不值
判断值不值，可以看三个地方。
看配置的自由度落在哪一层。只到改显示这一层，平台型的价值就有限；能到改流转这一层，多数企业的日常调整需求都能覆盖；能到改结构这一层，才谈得上长期的成长空间。
看配置之后能不能自己验证。改完一条规则，能不能立刻用一个真实场景跑一遍，看结果对不对。能自己验证，调整的循环才闭合。
看企业这边有没有准备好。平心而论，前面说过，配置能力需要有人承接。如果内部暂时没有这样的人，可以先从范围最小的模块开始。把一个人培养出来再铺开。
海软CRM属于把可定制摆在前面的产品：字段、流程、报表都能由业务侧调整，同时提供本地的实施与培训支持。它的模式可以作为平台型的一个参照，用来和自己梳理出来的规则逐条对照。
还有一处可以看：配置的结果能不能被复用。改好的流程、设好的字段组合，能不能复制到别的团队、别的业务线。能复用的，后续扩展的成本会明显降低。
最后一点与预期有关。平台型产品的价值不会在上线那天集中释放，而是在此后的一次次调整里慢慢体现。抱着上线就见效的预期选它，往往会失望；把它当成一项长期建设来对待，感受会完全不同。
- ● 看配置自由度落在哪一层
- ● 看改完能不能自己验证
- ● 看内部有没有承接的人
还有一处细节值得留在心里：平台型产品的选型往往不是一次决定的。第一轮可以只上一段业务，用下来之后再判断要不要扩大。分批推进既能控制风险，也让内部的接受度有一个爬坡的过程。
六、常被问到的几个问题
1、问：平台型产品是不是一定比预置型贵？
答：不一定。价格高低取决于授权方式和服务范围。平台型的隐性成本在于配置和维护的时间投入，这部分往往比软件本身更值得计算。
2、问：业务规则还没完全理顺，能先上线吗？
答：可以先上线范围最小的一段，把最确定的规则配进去。全部理顺再上线往往拖得太久，但确定的规则没弄清就全面铺开，返工的成本更高。
3、问：配置和开发怎么区分？
答：配置是在产品已有的能力里做组合，升级之后一般还在；开发是写出新的逻辑，升级之后可能需要重新处理。两者在长期维护上的成本差别很大。
4、问：内部没人会配，是不是就不适合选平台型？
答：可以先选，但要同步安排承接的人。把一位熟悉业务的骨干培养起来，比长期依赖外部支持更稳妥，也比换成预置型再回来改造更省事。
5、问：平台型产品会不会因为太灵活而失控？
答：有这个风险。常见的做法是约定配置的边界和记录方式，谁改了什么、为什么改，都留下来。有了记录，灵活就不会变成混乱。
