服务中台的进阶之路（2）——设计与交付

客户世界 | 2022年8月4日 | 2022年, 客世原创 | 评论已关闭 | 866

一、服务中台的设计之路

（一）服务中台的设计原则

服务中台的设计需要把握好如下几项原则：其分为前后端的服务耦合原则、企业战略的服务支撑原则、高内聚的通用性功能。

一是前后端的服务耦合原则。服务耦合是强调服务中台是需要以接口定义的实现方式，面对前后端对服务需求的差异性，参照特定的服务实现方式加以链接。在这一过程中，不存在的对前后端影响问题，也不会影响前后端的正常运营。耦合还有一个重要作用就是对异常事件的排查以及处理，服务中台需要具备敏捷的服务风险预警能力，这一能力要具备快速、实时的特点。

二是企业战略的服务支撑原则。服务中台的设计要始终围绕企业的价值衡量模型，要确保中台所产生的服务价值与企业的战略价值是保持一致的，这样才能确保服务中台的长期健康发展。这里可以建立起一套服务中台的价值衡量模型，例如：价值导向、敏捷机制、业务洞察等为第一链接，而价值导向下的服务关联导向、敏捷机制下的业务与流程优化、业务洞察中的业务逻辑指导（紧贴核心业务板块）属于第二链接范畴。

三是高内聚的通用性功能。上一个原则上提及了两个链接范畴，如果将其进一步细化，还可以尝试形成第三链接，主要是一些辅助功能，例如：服务中台的高内聚、低耦合、统一接口机制、服务通用性功能等，确保在同类型服务价值上实施聚类，对服务间距最小的单元保障快速的耦合，将一些服务流程和业务逻辑提供内外部统一的接口调用，拓展在服务通用性上的功能，以便能够快速定义接口并满足各个不同接口的服务需求。值得一提的是，这一原则下，接口是需要加以区分的，其可分为有实体的接口范围，类似交易、算法中台的接口，而能力接口更多是指一些生态端的运营能力，例如一些开放式的ISV接口等。

（二）服务中台的设计风险点

讲完设计原则，需要对设计风险点进行探究。显然，服务中台的设计是一项系统的工程，我们不仅仅是将一些必要的原则纳入其中，还需要按照具体的设计步骤，明确服务中台的设计风险点，这样才有可能形成一套具体的实施路径。具体服务中台的设计风险点主要有应用模式、核心数据、服务接口等三个方面。

一是应用模式风险。需要明确服务中台在企业中的应用模式。这一方法主要可细分为两点，一是服务中台更多作为前端业务运营、后端业务决策的调用逻辑，其是在运营和决策需要辅助及参照时引入服务中台的相关数据或者结论，一般来说也会以场景的方式进行调用。例如：某新能源电动车企业发布新的产品，在设计某项功能是否符合消费者需求时，可以调用服务中台在这一场景下的咨询、反馈以及投诉的数据，用以决策支撑，无论是否对这项功能进行调整，都仅仅是一种参照。二是服务中台作为指引前端业务运营、后端业务决策的辅助工具逻辑，这一应用不仅仅是简单的调用模式，更多是辅助场景，如何过前一种应用是异步调用的模式，那这一种模式就是属于同步调用。同步调用需要机会点更具备实时性，甚至某种意义上的超前决策。例如：同样是新能源电动车企业发布新的产品，其服务中台可以根据客户端以往的咨询、反馈以及投诉的数据，结合行业现有的数据对比分析，面向部分受众群体采用调研、访谈、模型分析等多种方式，形成一项对新产品的功能模式建议，既具备客户视角，也具备了一定的行业、未来视角。

二是核心数据风险。要明确服务中台的核心数据，最大限度舍弃冗余数据并降低数据的复杂性。一些大型企业的服务中台在建设过程中，由于企业内外部环境的变化，区分了很多核心、非核心、新型的业务模块，这对服务中台建设就造成了很大的阻碍。例如：部分大型企业前端拥有几十种业务类型，且企业的业务类型随着市场的变化还在不断变化，如果中台进行全面对应、匹配、设计、建设，那就相当于陷入了一场“持久战”，非常被动，且容易造成“尾大不掉之势”。著名的游击作战十六字诀“敌进我退，敌驻我扰，敌疲我打，敌退我进。”可解释此问题。不得不说，这十六字诀是蕴含大智慧的。首先，要明确的是，服务中台是解决企业当下面临的核心问题，新兴业务固然重要，但并不是服务中台的核心，也不应该成为其战略指向，因为新兴业务的成功更多需要实力与机遇，二者都是服务所欠缺的，换而言之与服务的“稳扎稳打”的工作作风相违背。其次，服务中台需要集中精力奠定自身的基调，无论是积累小胜换取大胜，还是时间与空间，只有集中精力才有可能实现，才能换取企业对服务中台的长期投入。显然，这一阶段看到服务中台对企业传统业务的价值输出是最为重要的，也是能够最大限度凸显价值的。

三是服务接口风险。要避免设计非通用型服务接口，更多使用粗颗粒度的服务接口模式。前者主要是不能过早限定自身的支持和应用范围，某种意义上，服务作为成本中心在绝大多数企业的观念都是没有更改的，虽然近年来部分企业的服务部门开始倡导并提出由“成本中心”转向“利润中心”的口号，但请注意，那毕竟是“口号”，如果已经实现了，那可能就是“万众一心，提升利润率XX%”。因此，通用型的服务接口对中台来说就是降低成本的重要举措，一些服务中台的设计并不是不好，也不是不适用，而更多是在早期的设计中把接口复杂化，导致后期的更改或调优起来非常费力，不亚于再造一个，成本较高，这就无形中成了设计落地的“绊脚石”。后者更多是在设计中避免过度精细化，我们往往会觉得数据一次性导出、结论一次性导出是系统或中台产出的关键，这样也会使得颗粒度较细的场景形成了固定的服务用例，调用完成后无法形成匹配的资源，也会造成一定意义上接口的冗余。在此过程中，粗颗粒度也要形成必要的隔离，以便一些举措的变化对后端服务产生较大的内部重构风险，对服务运营端产生影响。值得一提的是，随着应用功能广泛性的扩大，还需要充分考虑服务中台接口的兼容性，这里可以更多考虑向下的兼容性，一定程度上可以避免重构带来的影响。

二、服务中台的交付之路

（一）服务中台的交付原则

服务中台的交付不仅仅是简单的框架交付，而是需要遵循必要的服务原则，在充分承载业务逻辑、业务数据、业务价值的基础上不断发展进化。在具体的原则上主要有如下三点：一是需要具备服务的松耦合原则。松耦合是一项极其重要的原则，也是面向前端业务发展的重要基础条件，松耦合需要对接口定义进行解绑，服务中台的交付不依赖于特定的服务方实现，每个接口之间需预留相互定义的接口，这样避免中台内部系统在相互切换时产生变更影响。举例说明：笔者在调研中发现，某家商业化银行在服务中台的设计中，整体的框架逻辑无论是在业务逻辑还是业务数据上均具备较强的应用价值，服务渠道便捷度、智能化水平较高。前端客户在产生服务咨询时，如涉及到自助功能，在服务窗口可实现自动推送且窗口内操作，数据也可以在服务渠道内进行透传展示，还兼顾了语义识别、功能判断、规则跳转、消息队列、信息查询等，这些均展现处理强大的数据处理能力。但是，在后续的中台数据改造中发现，接口之间存在切换不兼容、底层的实时处理能力不能持续保持、消费者的信息接口及负载均衡能力不足等，其本质还是在服务的耦合性上存在不足。

二是需要具备服务依赖原则。这一点主要体现在耦合的基础上要具备明确的价值导向，确保服务中台的理念与企业的商业理念之间保持统一与关联，需要始终坚持以便捷为导向，避免业务逻辑以及业务流程被复杂化。在服务中台领域，还需要紧贴业务需求，从前端的业务交付、业务发展规则等两个视角进行服务中台业务逻辑的设计，驱动其价值延伸。在具体的中台内部依赖上，需具备高内聚、低耦合、明接口、通用性等特征，具体来说高内聚是指同一服务类型的归类、低耦合是面向服务间的高效联动、明接口是将调用的接口模型进行逻辑转化、通用性主要是在设计上需要具备可扩展的通用类型，使之能持续满足中台系统的升级。

三是需要具备服务层次原则。我们知道，在服务过程中，不是所有的服务类型优先级都是保持一致的，不同接口之间存在实体、能力的巨大差异，接口的核心与限定要具备服务层次，这也是服务中台交付的关键。举例说明：笔者在调研中发现，在一些大型综合电商平台的服务中台中，会充分考虑到会员的需求，因而中台设计中会把针对会员的服务诉求进行拆分，类似专属客服、专属通道、专属响应、专属权益等，这是简单的前端设计。对于后端设计中，这些只是简单的透传。中台中需要单独引入一条链路服务这部分群体，这样才能形成前后统一，扩大对这部分群体的服务影响，这里就涉及到层次结构的交付，在时效响应、服务标签方面，必然会产生冲突，层级上需要设立主次关系，从接口实体维度交付上下限定的层级结构，进而避免无关的绑定产生层次异常。

（二）服务中台的交付风险点

前文提到，无论是在服务中台的设计还是交付维度，其均是存在一定风险的，这种风险有内部、有外部、有短期、也有长期。值得一提的是，风险并不是说这件事情没有办法做，对风险的分析也有利于我们进一步理清现状、纾解问题，既是解决当下，同是面向未来。

客观而言，服务中台的交付风险主要集中在如下两个方面，一是数据层面的冗余。这一点是非常常见的，因为各个企业的发展进阶过程中，服务部门一定是一个非常重要的协同载体，大家都很重视，而服务为了进一步发挥价值，也需要前推问题，这就导致服务中台在设计过程中逐步变成了加法计算器，没有适当的减法机制，导致形成大量的数据底层库，这些数据有的是远程调用模式下存在的，有的是面对服务诉求不断演变形成的，分析模式上也存在较大的差异，有的按照SQL方式、有的按照下拆数据方式、有的按照图标展示方式、有的按照渐进趋同的关系等等，这些数据增量到一定程度后就会发现整个服务中台-数据层异常庞大，看似具备了广泛的数据源以及分析工具，但忽略了我们的受众群体。服务中台到底是为谁所用？初创阶段显然是前端的敏捷交付。因此，需要定期对服务中台的冗余数据、字段进行筛查，降低前端解析的复杂度，在后端调用、接口设计等方面均可以节约大量的资源，同样也可以降低数据使用的潜在风险。

二是颗粒度层面的完整性。服务中台由不同的内聚模块而形成，有些观点会认为它属于一种虚拟组件的形式，但最终又可以独立完成服务判断的职责，故而需要对交付时的完整性进行评判。例如：以品牌手机服务为例，手机是由大量的软硬件设备组成，这里面有一部分属于业务解答内容，有一部分需要有线下的维修服务，所以我们看一些手机厂商往往是把售前服务拆成线上，而售后服务作为线下，二者之间必然有交叉。假设我们设计手机厂商的服务中台体系，如何兼顾线上线下的场景服务？首先，需要将手机服务的颗粒度进行拆解，而且采用多级场景分布机制，先聚合场景，而后以高可用性为基础条件，在业务层面上定义操作，区分操作的场景和非操作的场景，具体可以将手机厂商的智能服务作为中台的载体，如果中台定义了是操作场景，线下操作服务随之引导而上，定义具体的操作步骤以及时间。而定义了线上场景，先区分解决的实践方式，而后定义三种调用结果，分别是成功、失败、未知，第一种情况收集导出异常点，第二种情况递进新解决方案，第三种情况则需要人工介入判定，这样的一种循环方式就可以形成在手机厂商服务的定义操作层面逻辑。

作者：杜秋

本文刊载于《客户世界》2022年7月刊。