在中台建设历程中，在MSS模型的指导下帮助我们完成了中台服务中心的设计与建设后，下一步便进入中台实施与运营的环节。


本篇文章我们来谈谈在中台实施与运营中一个痛点问题“业务系统与中台流程冲突”。

1、目标：特异性流程接入

 

    中台建设在解决了方案设计这一难题后，需要面对的另一大难题就是特异性问题的管理，这也是我们在中台实施过程中必然会遇见的问题。


    所谓特异性问题就是不管在之前业务模型怎么抽象，在中台实施过程中一定还会发现存在由于中台系统与业务系统在功能上存在差异而无法接入的的现象，从而导致与中台的对接出现阻塞。


    例如可能是因为这个业务线当年与你介绍的时候他没有提到某个特殊流程，或者因为在中台研发的时候，业务线系统同步在发展，导致有一些新的流程把以前的流程推翻了，那这个时候就会出现特异性问题，本质上这个问题的来源属于业务的发展导致新业务场景与中台原有设计不再匹配。


    这里我想先问问此时正在阅读的你，中台系统和业务系统功能相冲突或违背，那这个时候我们应该怎么办？


    这里有几个常见的做法供你选择：

    （1）第一种做法：选择直接放弃，也就是不把该业务线的系统接入到中台中，该业务系统游离于中台体系外自己循环；

    （2）第二种做法：中台团队根据该业务的现状，去进行量身打造，由中台给你进行定制化改造，适配你现在的流程；

    （3）第三种做法：强制业务系统根据中台定义出的流程进行兼容，也就是由业务系统去按中台的流程进行开发改造。


    那这三种模式各自有什么优缺点呢？

    （1）第一种做法：由于业务特异性而放弃接入，在出现一例不接入中台的先河后，又因为中台的建设过程中是业务逆向感知的，也就是不仅没有给业务带来新的价值，反而还要占用大量的工时和工期，那这个时候业务是不买账的。导致别的业务线听到后，会说他不接入中台，我也不接入，那这样的情况下整个中台就会在企业内部被边缘化；

    （2）第二种做法：为业务线量身定制，这样做的背后存在巨大的项目风险，一般情况下需要定制往往是因为这些业务还不成熟，由于这是一个探索业务，很有可能在中台改造完成之后或者改造过程中，这个业务就被下马了。那这个时候我们的改造就浪费掉了，此外作为公司的基础服务中台，为了稳定性本身也不事宜频繁变动；

    （3）第三种做法：强制业务系统按照中台流程改造，此时中台反而成为了制约业务发展的瓶颈。

2、工具：服务中心插件

 

    所以我们解决方案是什么呢？


    在中台实施过程中一个非常好的解决特异性问题的方案就是插件，通过插件让特异性的业务部分接入到中台中。


    所谓插件也就是中台开放一些对应的接口，允许业务方去插入一个自定义的代码段，自定义代码段可以去调用我们中台的上层服务，去跳过部分场景。


    从而实现在符合现有逻辑中台逻辑的一个调用，然后在具体的业务层去替换这部分的含义，使它赋予新的业务含义，从而让他接入到中台中。


    我举个例子来说，我经历过一个新孵化的业务想要调用客服服务中心的服务，但是由于新业务中人员较少，原有的客服流程较长，且每一步都有对应的单据，导致新业务的客服工作压力巨大，此时我们就让该业务线以插件的形式接入中台，并在部分环节调用中台接口自动产生单据，这样就解决了新业务线的问题。


    可以说插件可以帮助业务线既接入中台，同时又去符合了新业务的特性，那么这就是插件带来的意义。


    假以时日等到这条业务线变得越来越健壮了之后，这个业务越来越成熟，越来越多业务线都需要该插件的功能后，我们再把这个插件拆掉，让插件升级为中台的一个能力，这样的情况下是中台最安全最节省成本的一种方式。


    那这里我们还是以一个具体的案例来看，在L电商内部是怎么使用插件解决这个问题的。

3、案例：L电商公司中台插件引入

 

    在L公司中通过商户全局商户号与全局协议，我们实现了对商户的唯一化管理，但是随着业务的发展，特别是当我们与一些头部客户合作时，头部的客户对我们提出要求，要求我们在原有账期到期后，在打款期间依旧能临时使用我们的服务。


    也就是需要我们在这段时间给予商户一个授信额度，允许在规定账期之外对我们进行赊账。


    但是这个时候，已经标准化了的整个商户管理服务和支付中心不支持这样的服务，在到达账期后，商户不进行结款，不会允许商户进行使用。


    面对这样的业务需求，我们不得不跳过中台所提供的部分功能，从而满足这位客户的个性化需求。


    当时我们有两种解法，第一种解法立即启动中台升级，在支付中心中增加授信模块，但是这样做等待时间比较长，无法及时响应客户现在的需求。


    第二种方法就是我们要去介绍的通用中台特异性管理方法，由业务线提供个性化服务的代码段来跳过中台的限制，从而既不破坏中台的要求，又能符合业务的新需求。


    根据前面的介绍我们知道这个代码段有它自己特殊的名称，也就是中台的插件，他的特征有如下两个：


    （1）符合现有逻辑的调用；

    （2）在业务层替换的该部分业务含义；



    具体落地到业务上来看，我们是这样实现的，如图所示


    （1）1.0中台中的计费不支持授信，此时我们使用插件；

    （2）调用中台还是商户预充值服务：虚拟充值金额2万，以此让中台认为该商户已经完成还款充值，此处的还款充值额度就为给商户开的授信额度；

    （3）在插件中记录2万为授信额度，在月底的商户账单中自动冲销2万元，从而实现金额的闭环。



    所以看到插件就是在满足不影响底层业务的情况下的一个绕弯，当然之所以不把这个业务单独拉出去去做，是因为目前我们只对接了一个客户。该模式的规模化特征还不明显，此时我们如果贸然的将它加入到中台中来，只用一次的需求对于中台来说，无疑是开发资源的巨大浪费。



    所以我们会先选用插件的模式，从而快速复用中台其他的逻辑，当账期需求在多个业务线都出现，成规模化需求时，再进行中台对应模块的开发，由插件变为中台内部的一个服务。



    也就是当出现多个插件使用服务时：

    （1）开始将该插件合并至中台；

    （2）由中台进行统一维护；

    

    综上我们通过插件实现了中台实施的特异性管理。