代码段|业务中台09：中台实战中的特异性问题管理 perc|inc|扎克伯格|超级计算机

编辑导读：在中台建设历程中，在MSS模型的指导下帮助我们完成了中台服务中心的设计与建设后，下一步便进入中台实施与运营的环节。“业务系统与中台流程冲突”一直是中台实施与运营中一个痛点问题，本文作者基于三种常见处理方式，浅析其中利弊，并结合具体案例与大家分享使用“服务中心插件”工具的解决方案。推荐童鞋们阅读学习～

文章插图
一、目标：特异性流程接入中台建设在解决了方案设计这一难题后，需要面对的另一大难题就是特异性问题的管理，这也是我们在中台实施过程中必然会遇见的问题。
所谓特异性问题就是不管在之前业务模型怎么抽象，在中台实施过程中一定还会发现存在由于中台系统与业务系统在功能上存在差异而无法接入的的现象，从而导致与中台的对接出现阻塞。
例如可能是因为这个业务线当年与你介绍的时候他没有提到某个特殊流程，或者因为在中台研发的时候，业务线系统同步在发展，导致有一些新的流程把以前的流程推翻了，那这个时候就会出现特异性问题，本质上这个问题的来源属于业务的发展导致新业务场景与中台原有设计不再匹配。
这里我想先问问此时正在阅读的你，中台系统和业务系统功能相冲突或违背，那这个时候我们应该怎么办？
这里有几个常见的做法供你选择：

选择直接放弃，也就是不把该业务线的系统接入到中台中，该业务系统游离于中台体系外自己循环；
中台团队根据该业务的现状，去进行量身打造，由中台给你进行定制化改造，适配你现在的流程；
强制业务系统根据中台定义出的流程进行兼容，也就是由业务系统去按中台的流程进行开发改造。

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

由于业务特异性而放弃接入，在出现一例不接入中台的先河后，又因为中台的建设过程中是业务逆向感知的，也就是不仅没有给业务带来新的价值，反而还要占用大量的工时和工期，那这个时候业务是不买账的。导致别的业务线听到后，会说他不接入中台，我也不接入，那这样的情况下整个中台就会在企业内部被边缘化；
为业务线量身定制，这样做的背后存在巨大的项目风险，一般情况下需要定制往往是因为这些业务还不成熟，由于这是一个探索业务，很有可能在中台改造完成之后或者改造过程中，这个业务就被下马了。那这个时候我们的改造就浪费掉了，此外作为公司的基础服务中台，为了稳定性本身也不事宜频繁变动；
强制业务系统按照中台流程改造，此时中台反而成为了制约业务发展的瓶颈。

二、工具：服务中心插件所以我们解决方案是什么呢？
在《中台产品经理宝典》一书的实施环节中，我提出过一个非常好的解决特异性问题的方案就是插件，通过插件让特异性的业务部分接入到中台中。
所谓插件也就是中台开放一些对应的接口，允许业务方去插入一个自定义的代码段，自定义代码段可以去调用我们中台的上层服务，去跳过部分场景。
从而实现在符合现有逻辑中台逻辑的一个调用，然后在具体的业务层去替换这部分的含义，使它赋予新的业务含义，从而让他接入到中台中。
我举个例子来说，我经历过一个新孵化的业务想要调用客服服务中心的服务，但是由于新业务中人员较少，原有的客服流程较长，且每一步都有对应的单据，导致新业务的客服工作压力巨大，此时我们就让该业务线以插件的形式接入中台，并在部分环节调用中台接口自动产生单据，这样就解决了新业务线的问题。
可以说插件可以帮助业务线既接入中台，同时又去符合了新业务的特性，那么这就是插件带来的意义。
假以时日等到这条业务线变得越来越健壮了之后，这个业务越来越成熟，越来越多业务线都需要该插件的功能后，我们再把这个插件拆掉，让插件升级为中台的一个能力，这样的情况下是中台最安全最节省成本的一种方式。
那这里我们还是以一个具体的案例来看，在L电商内部是怎么使用插件解决这个问题的。
三、案例：L电商公司中台插件引入在之前的文章中，我阐述过L公司中通过商户全局商户号与全局协议，我们实现了对商户的唯一化管理，但是随着业务的发展，特别是当我们与一些头部客户合作时，头部的客户对我们提出要求，要求我们在原有账期到期后，在打款期间依旧能临时使用我们的服务。