产品经理数据分析实战手册 pdf_中台产品经理实战（17）：支付中台（服务中心）实战...

在前面的章节中，我们已经对中台概念有了很多的认知，本章让我们来看如何使用我在《中台产品经理宝典》一书中提出的MSS建设模型，去完成一个中台服务中心的建设。

一、什么是服务中心？

在正式讲述建设方案之前，我们需要对一个小概念进行一个辨析：服务中心。当下如果你在网上去搜索中台，会发现中台二字前面被灌注了很多的业务属性，例如订单中台，会员中台营销中台。事实上这些都不能称之为一个中台，而只能称之为中台中的一个服务中心。

让我们正确的去理解一下这两个概念：

• 服务中心：独立解决一个业务域内的完整需求，例如订单、会员、商品，因此市面上的这些模块中台，正确的称呼应该为订单服务中心，商品服务中心与会员服务中心；
• 中台：是若干个服务中心组成的一个系统解决方案。目的是为了解决公司的整个业务沉淀，而既然是既然是公司级的业务沉淀，那么大家肯定没见过有哪个电商平台的业务是只处理订单，而不需要理会会员或不处理商品的，肯定是这三者的一个集合。

搞清楚了这两个概念后，我们就可以去进行实战建设了，接下来让我们具体来看如何打造一个支付服务中心的完整历程。

二、业务调研

根据MSS建设模型，要想去建设一个中台，首先第一步我们要对现有业务进行调研，了解现有业务的组成以及服务特征。

这里的业务调研具体分为两个步骤：

让我们来一个个看：

步骤1：业务模式调研

所谓业务模式调研，就是指调研这个公司一共向外提供哪些服务或者产品，从而清楚的知道公司是依靠哪些业务来进行盈利的，而公司所要优先沉淀的内容，其中很大一部分就是将能盈利的业务构成沉淀下来。

据此我们得出了现有支付业务的三大服务类型：

（1）代扣服务：指定应用的自动扣款，如会员自动充值；

（2）支付通道服务：为交易方提供快捷扣款，收款的服务；

（3）聚合支付：支付宝，微信，云闪付等混合扫码支付

这三类业务分别有三组不同事业线进行维护，提供技术开发，这三组事业线也被称之为前台服务部门。

步骤2：客户合作模式调研

所谓客户合作模式，其实就是对一家公司如何从客户引入以及完成客户服务交付这两个环节的流程定义，了解了这个我们就能知道公司是如何具体展开业务的。

据此现有的服务方式调研结果如下：内部完成客户合作共分为三个角色：（1）销售（2）运营（3）销售支持，而这三类角色是公司三个业务线条公用的。

角色1销售：

（1）对接客户，签订合同；

（2）OA申请开通服务；

角色2运营：

（1）开通A服务商户账户（服务密钥）+配置；

（2）开通B服务商户账户（服务密钥）+配置；

角色3销售支持：

（1）计算各用户费用加总并收款，开票；

（2）计算通道费用并支付（给银行费用）；

完整服务流程如下：

完成了这两部调研，我们其实对一家公司内部整体的业务就有了一个清晰的认知：

在梳理完成业务现状后，下一步要做的就是定位现有业务中存在问题？

在客户合作模式中下面三个问题是日常工作中痛点的：

（1）每个商户存在多个服务的接入密钥，不易管理；

（2）多个服务的收入计算没有打通：在每月给商户计算账单时，需要首先挨个计算各个服务产生的费用再由财务进行汇总得到总账单，这中间流程较长且容易出现错误；

（3）用户发生合同变动时各项服务都需要调整：此外由于商户对接了多个服务，当用户在升级套餐或需要其他额外辅助项时，用户的一个单次调整例如账期延长，需要协同多个业务线都在内部进行账期配置调整，这效率无疑是太低的；

由于客户合作支撑部门是一个公共部门，解决他们的问题就可以同时提升各前台业务线的运营效率，因此面对他们的技术服务解决，便被纳入到了中台开发之中。

三、服务标准化

要想解决上面所提到的问题，根据MSS建设模型，我们就来到了第二步，要去将现有的服务标准化。

具体来说，标准化就是按照如下两步去重新定义服务：

步骤1：拆分原产品:到最小颗粒度

我们将上一阶段的三个业务，进一步细化可以得到具体每个业务的支撑环节：

例如：支付渠道业务 = 银行支付服务 + 第三方支付服务 + 结算服务

步骤2：支持自定义组合：各服务可独立提供服务

面对上面问题中，我们每个商户存在多个服务多个接入密钥的模式，这里给出的解决方案是在公司内部为每个商户去创建全局唯一商户号，并只配发一个密钥，通过后台识别该商户账号下所配置的服务，实现一个密钥管理多个服务。

四、中台解决方案

在上一步对于具体的业务，我们在现阶段很难去进行每个业务线内部的业务调整，所以我们在这里增加了一个全局配置中心。

具体实现两个功能：

（1）全局商户号

通过全局唯一商户号作为中台中商户唯一ID，来关联各业务线的服务，从而使服务主体、结算主体都可以统一为一个商户号。取代以往商户需要开通多个服务时，要在每个业务线内去独立创建一个商户号，结算主体在公司内部出现多个的异常情况。

在有了全局商户号后，该商户所有的调用次数都可以记录在该商户号下，并以具体的服务来细分，使调用服务的同时在每个服务下记录具体在该服务中产生的费用，最终由系统自动将多个服务费用加总得到该商户的统一结算金额。

（2）协议：主协议（系统级）+补充协议（服务级）

将每个商户的服务配置升级成为服务协议，统一放在全局配置中心进行管理，据此我们将用户的一个用户服务要求拆分为了两个部分：

• 主协议：指客户与公司签订的全局服务配置，如商户服务信息/计费模式/账期天数；
• 补充协议：指各业务线内部服务配置服务，如聚合支付需要支持哪几个平台的配置。

通过此方案，我们就将商户在公司内部建立起了全局的概念，所有业务线的服务都只有一个商户，从而实现了唯一化管理。

五、中台特异性管理

看到这大家觉得这样的服务中心设计，对于中台项目来说是否可以说已经完成了？

事实上这样的设计还是有一点不足，在中台建设的过程中，我们经常会遇到的一类问题，就是业务的发展会导致新需求必须要不满足于中台的设计才能跑的通。

这样说可能大家还是不理解我继续来带大家看这个支付中心所遇到的问题。

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

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

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

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

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

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

这个代码段有它自己特殊的名称，也就称之为中台的插件，他的特征有如下两个：

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

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

具体落地到业务上来看，我们是这样实现的：

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

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

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

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

所以我们会先选用插件的模式，从而快速复用中台其他的逻辑，当新模式出现规模化特征时，我们再进行中台对应模块的开发，由插件变为中台内部的一个服务。

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

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

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

所以我们中台解决方案的2.0也就生成了：

在有了中台服务中心后，整个服务的提供方式变为：

六、完整版解决方案

总结一下在本次服务中心的建设中，我们实际上使用了这样的一个中台建设方案：也就是基础能力与配置分离的设计方法：

我们将一个商户服务拆分为了三个部分：

（1）基础能力：各个业务线所提供解决80%商户需求；

（2）协议配置：记录商户的合作方式与全局配置；

（3）插件：满足用户的个性化需求；

至此根据MSS建设模型一个完整的服务中心就搭建完毕了，全文的完整建设路径可以用一张图来概况：

可以看到MSS模型能帮助我们快速的完成中台服务中心的搭建。

对了，如果想要了解更多高阶产品经理必备的业务建模技能与更多中台建设相关内容可以看看我的新书《中台产品经理宝典》，相信会给你带来不少启发！

作者：三爷，公众号三爷茶馆/多年头部互联网公司B端PM/MBA特邀讲师/全文阅读量超10W+《中台实战》系列专栏作家/《中台产品经理宝典》一书作者