“中台服务之道，地图引领方向。” 在中台业务建设中，随着服务能力的不断沉淀，如何让业务方高效接入、让高层理解其价值成为关键。中台服务地图应运而生，它如同指南针，为中台服务的有效开展指明路径，是实现中台与业务协同发展的重要工具。

前言

此前写过一篇《如何做好B端产品的多业务线对接》，当时对这一块问题的答案是：

1.功能标准化建设。

2.接入服务建设。

3.合理的时间管理。

距今已有一年有余，中间也快写了20多篇文章，这个过程中沉淀了一些新的想法，在我最近需要思考内部中台业务建设的时候，发现原本的文章只是从“一线视角”出发去想问题，其中仅仅考虑到“对接的人力效率优化”这个点。但是如果站在更高的视角看待这个问题时，会发现在“中台沉淀的服务能力很多时”三个未曾被考虑过的点：

1.如果中台提供的能力服务量远远大于接入方的短期接入能力时，要如何安排优先顺序接入？

2.业务方如何知道自己要接入什么能力？接入后能起到什么作用？

3.如何让高层了解到我们公司中台存在的意义以及价值？

其实这三个问题都导向了一个答案——中台服务地图构建。

什么是中台服务地图？这是一个面向中台服务使用者的指引，需要告诉使用者：

1.我们的能力有什么？能做成什么样？（What）

2.我们的能力能做成什么效果？（Why）

3.我们的能力能在业务的什么节点发挥作用？需要在什么时候接入完成？（When）

4.要如何接入与使用我们的能力？（How）

那么如何做好“中台服务地图”的建设呢？下面讲讲我的想法和思路。

服务内容整理

要想绘制好“中台服务地图”，第一步是需要清晰地知道我们的服务内容有什么，其次是知道我们的服务内容能对什么业务起到什么作用，最后才是进行服务内容整理。

第一步：盘点已有的服务内容

当我们中台能力沉淀得比较多时，我们需要先进行业务能力的盘点，先捋清楚我们中台部门手头上有什么服务内容。

首先我们要定义一下中台的服务内容，这个可以是一个系统、一个API、一个插件、一个工作流程，只要是能够直接或间接让中台成员“赋能”公司业务的内容，都可以称为“中台的服务内容”。

大部分中台部门都有内容wiki文档进行这部分服务内容的沉淀，如果wiki文档维护得好且分类清晰，那么第一步能很简单就完成。

但是如果wiki缺漏较多、内容分散，则需要从头开始盘起。很多人在这个时候肯定头很大，因为一个庞大的中台部门，其横向和纵向的服务内容量是极其庞大。

1.横向是指中台部门服务范围广，涉及到的业务面广，因此相关的功能、系统类别繁多。

2.纵向是指中台部门建设的时间跨度一定很广，必定是长达N年部门，这进一步加深盘点业务的难度。同时，由于时间跨度长，这里面会由于各种诸如“人员变动”、“架构调整”等等原因导致的历史信息断档，这导致部分信息无从查起。

（比如我们发现有一个历史运作至今的系统，但是却发现负责系统的一线产品、一线技术都离职了，想要盘点这项服务，仅凭负责人是较难回忆起其中的细节的，只能够通过查阅代码 或者 进行业务访谈 才能复原其中的细节。这无疑说明其中之“高成本”。）

虽然繁琐，但是也是有一定办法的。

1.我们可以先梳理大头的重点业务。重点业务往往是“最近存在版本迭代”、“业务关注度高”、“价值贡献突出”、“持续在使用”的服务内容，因此这些内容往往内容沉淀最齐全、相关成员最完整，梳理起来成本相对较低，而且梳理这些内容的性价比往往很高。（如果时间有限，先做这一步也行。）

2.翻阅wiki补齐信息。虽然这种情况下的wiki可信度不高，但是也能从中推理出一定的服务内容，并重新收纳和整理起来。

3.让技术从代码层面罗列系统服务项目。由于基本上所有的服务内容都会经过技术的开发与部署，因此从代码层面是能够对所有的服务内容进行溯源的。不过用此法罗列的服务内容会非常零散，最好能按系统、按业务进行一定程度的归类。

4.最后，就是让各个服务模块负责人查漏补缺了。

第二步：了解你服务的业务

中台部门是对公司的业务进行服务，并与之进行价值交换。所以我们需要了解我们服务的业务，其中包括业务形态、服务在业务中的价值、业务子模块及其流程。了解这些内容是为了清晰地进行服务归类，向业务方呈现我们的服务地图。

我们可以通过以下方式进行这方面内容的了解：

1）业务访谈：这是一种直接的调研手段，通过与业务各层角色的深入交流来收集信息。进行业务访谈时，准备一份详细的访谈大纲至关重要，以确保访谈过程中能够高效地获取所需信息。

2）轮岗实习：有时业务团队可能缺乏全局视角。为了更全面地理解业务，轮岗实习成为了一种有效的方法。亲自参与到一线工作中，可以帮助我们深入挖掘和理解业务的真实需求。

3）调研问卷：问卷调研能够快速、广泛地收集反馈，并在一定程度上量化问题，例如评估对某些功能的需求程度、系统满意度等。

首先，要对公司的业务形态进行梳理。

这个过程中，我们要了解公司是怎么通过其产品/服务与用户进行价值交换的，即“公司是怎么赚钱的”。

通过对业务模型的分析，我们可以更好地理解公司的盈利方式。

拿游戏行业举例：游戏公司开发或者运营一款游戏，为玩家群体提供内容消耗并产生情绪价值。玩家为内容进行付费，公司从中获取收益并持续运营或者打造新的游戏。

接着，我们要了解中台的服务内容在公司业务中发挥的价值。

我们需要知道我们在“公司赚钱”这件事上，起到了什么作用，以了解“公司为什么给我们发工作”。

拿游戏行业举例：按我自己的理解，我将游戏行业的业务拆解成四大模块，整体链路如下。

其中各类中台系统模块分别起到以下作用：

1.研发相关中台功能提效率增效果，使得游戏能快速抢占市场。

2.营销相关中台提供精准的玩家导流能力，把经费都花在刀刃上。

3.运营中台支撑运营业务，满足用户、业务、监管方面的需求，实现收益最大化。

4.底层支撑系统，为团队建设和其他基础业务赋能。

最后，我们要了解各个业务方的子模块和业务模块的流程。

上面仅仅是对业务进行了大类的拆分，比如游戏行业拆分成研发、营销、运营、基础支持。但是其中每个业务还可再拆分其中的业务子模块，比如运营可以拆分为客服、活动、用户等运营模块。拆分业务模块能辅助我们更好地进行服务归类，更好地在“服务地图”上进行服务内容的呈现。

业务子模块的分类方式一定程度和公司内对部门/岗位的划分相关，一般由某个部门或某几类岗位负责一个业务子模块。

但同时，一个业务子模块也有可能涵盖非常多的中台服务内容，因此我们需要再细分一层，即“按业务子模块的流程”进行划分，方便业务知道自己什么时候需要使用什么服务。

这里用“用户运营”业务作为举例。

“用户运营”业务的主流程可以分为“引流”、“筛选”、“培育”、“转化”、“维护”。我们可以按这些模块进行归类，比如将私域的活码配置、预约活动发奖等功能归在“引流”服务这一类，在业务需要的时候，能够快速从“服务地图”上找到。

第三步：服务归类

当梳理完“服务与业务的利益关系”后，我们需要进行服务内容归类。

为什么要这样做？因为如果我们按系统进行服务内容归类的话，有可能存在一些业务同时需要使用2~3个系统。所以在业务方接触我们的服务的时候，容易产生疑惑，提高其中的学习成本和使用成本。

因此为了做好服务地图，我们需要进行服务归类，让业务方能够快速知道“我们的服务内容有什么”，从而并了解这些能力的效果，并展开接入与使用步骤。

在进行服务分类的时候，个人觉得可以基于前面的“业务了解”，按以下维度分类：

1.一级类别按业务大类归类：

业务大类是从“公司业务流程”上拆解出来的类别。比如游戏行业就可拆分为“负责游戏制作的游戏研发”、“负责导入玩家的游戏营销”、“负责维持游戏运转的游戏运营”、“给公司运转提供支撑的底层支撑”。

按业务大类能够让高层清晰地了解到中台部门的服务布局，以及对公司运转的辅助作用。

2.二级类别按业务子模块归类：

业务子模块的分类方式一定程度和公司内对部门/岗位的划分相关，一般由某个部门或某几类岗位负责一个业务子模块。

按业务子模块进行服务分类，能向上清晰地呈现中台部门对不同业务模块的赋能情况。而业务的接入者往往不用关注太过于宏观的内容，通过子模块的分类方式，他们清晰地圈选出他们需要关注的内容，而不是从庞杂的资料中找到自己需要使用的能力。

3.三级分类按业务子模块流程归类：

基于“业务子模块”的流程可以进行三级分类，这一般和业务子模块的步骤节点有关。

按业务子模块流程分类，能帮助业务使用者更清晰地知道自己在什么阶段需要使用到什么样的服务内容，以提前做好接入和使用的准备。

服务地图制作

在完成服务内容整理之后，我们就完成了制作服务地图的前置任务了，这时候我们需要开始进行服务地图的制作。分为以下步骤。

第一步：地图内容整理

前文提到，服务地图需要告诉使用者以下信息：

1.我们的能力有什么？能做成什么样？（What）

2.我们的能力能做成什么效果？（Why）

3.我们的能力能在业务的什么节点发挥作用？需要在什么时候接入完成？（When）

4.要如何接入与使用我们的能力？（How）

所以第一步，我们要基于我们梳理的服务内容结构进行“What”、“Why”、“When”、“How”的内容填充。

1.What：

我们要准备一个服务内容的说明，可以从“背景”、“描述”、“服务流程”等维度对服务内容进行说明。为了更清晰地说明“What”，我们也可以准备一个demo，这个demo可以是一个测试服的链接、一个线上业务的案例。通过demo，业务方可以代入其中，让业务方亲自体验下“我们的服务是什么”。

2.Why：

我们可以从服务内容的“目的”和“作用”入手，对服务内容进行描述。但这样难免有点空洞，因此我们可以搜集并整理功能标杆案例与收益预期。

功能标杆可以尽量选取在内部有一定知名度 且效果较为突出的项目，我们需要向业务方展示我们的服务在其中作用，以及起到的量化作用，比如“代金券功能在最近的XX游戏上辅助创收1000w，拉收提升20%”。

功能标杆一方面可以进一步解释“服务能力有什么”（What），另一方可以让业务方直观地了解到服务内容的价值。如果我们选择的标杆在公司内部有一定的知名度时，业务方在看到这个标杆时，就会豁然开朗，“哦~原来是这个~”、“原来有这么个作用~”，然后就会毫不犹豫地接入我们的服务。

如果我们是一个未有“标杆”的服务内容，则可以尝试撰写“收益预期”，尝试说明接入这项服务，业务方能得到怎么样的辅助或提升。

3.When：

这个问题可以从服务内容的“起效节点”、“接入周期”、“接入节点建议”3方面撰写。

“起效节点”指服务内容在接入方的什么阶段会发挥作用，比如项目的测试期、首发期、增长期、成熟期。

“接入周期”指服务内容的使用从“发起需求”到“正式使用”的周期间隔，因为往往中台的服务内容需要一定的接入配置、测试联调成本，甚至有些项目需要接入API、SDK等内容。所以我们需要对“接入周期”进行评估，以说明其中的接入成本。

“接入节点建议”是基于“接入周期”进行的接入节点预估，考虑到接入时间成本的存在，为了避免不错过“起效节点”，往往需要提前预留大于“接入周期”的接入时间。

4.How：

关于“How”的内容，我们可以通过撰写“接入流程指引”、“技术接入说明”、“配置说明”、“使用说明”等内容来满足。

其中“接入流程指引”可以先说明能力接入的流程、相关节点的对接人、每个阶段的具体事项，用来引导业务方接入并使用我们的服务。如果是较为复杂的服务内容接入，最好由专门的人员进行辅助接入，帮忙进行能力解答和接入指引。

“技术接入说明”则是技术层面的具体描述，需要交由技术撰写，因此不展开。

“配置说明”和“使用说明”则需要手把手指引业务方在接入完成后进行能力的使用，涵盖“如何正确配置”、“如何正确使用”。

第二步：服务内容呈现

当我们准备好地图内容后，就需要考虑进行地图内容的呈现了。个人觉得，一个合格的服务地图需要包含以下内容。

1.基于服务归类的能力清单：

基于我们前面进行的服务归类，我们最多可以对服务内容分为三个等级的类别，分别是“按业务大类”、“按业务子模块”、“按业务子模块流程”。

因此，我们可以列出一个服务清单列表，里面汇总了所有的服务内容。就好像阿里云这里的“解决方案”的呈现方式，也是按三个大类别进行归类。

2.充分体现“What”、“Why”、“When”、“How”的内容呈现：

用户点开服务清单的每个内容时，我们需要对某个服务内容进行“What”、“Why”、“When”、“How”的清晰呈现与说明。

比如阿里云这里，就用图文并茂的方式充分说明了“功能是什么”、“接入的优势和作用”，然后通过“在线咨询”、“联系咨询”可以知道“如何接入”。

个人觉得充分体现“What”、“Why”、“When”、“How”的内容有以下几个特点：

1）描述清晰简洁、通俗易懂：因为服务内容大多数是技术层面的内容，但是接入方却不一定是技术。所以我们的措辞和用语尽量简洁清晰，避免使用深奥的技术语言，且最好能从业务视角出发进行描述，最终呈现的是“业务能快速看得懂的内容”。

2）内容结构清晰：需要把内容尽量按“What”、“Why”、“When”、“How”的结构呈现，避免出现一大坨文字的情况。

3）具有充分的案例说明：前文提到我们需要准备demo和标杆案例。因为具体的事物是能够快速帮助业务了解服务内容的“What”和“Why”，这能最大程度减少业务方不能理解的情况。

4）多模态呈现：我们可以不仅仅局限于文字，还以补充以图片、视频等形式，以降低理解的门槛。

3.提炼重点服务的首页：

当服务内容过多时，如果直接把过多的内容直接塞给业务方，业务方还是会一下子觉得头痛。因此我们需要设计一个“提炼重点服务”的首页。

这个首页需要对服务内容进行筛选，将高价值的、必接的、高频的服务内容提炼出来，再按一个清晰的结构进行呈现。如此，便可解决文首提到的“如果中台提供的能力服务量远远大于接入方的短期接入能力时，要如何安排优先顺序接入”问题。

比如微信小游戏的能力地图，就是按常用能力进行了汇总和梳理，接入方可以快速或者自己最需要接入的内容。

此外，首页还可以引入推荐功能，结合接入项目的类型、阶段、状态，推荐适合他们的服务内容，从而实现“需求与服务”的精准匹配，极大降低其中的对接成本，并快速发挥中台的服务价值。

后续的运营

以上步骤就基本完成了服务地图的建设，但是这并不意味着相关工作的完结。因为中台的本质是“沉淀”和“复用”，服务地图只是“沉淀”和“复用”的一种展现形，我们还需要进行后续的持续运营。

我们需要配合业务在实践中沉淀的“优质方案”，从而形成一定的服务内容沉淀，总结归纳到我们的“服务地图”中，再以此赋能到更多其他的业务上。

持续运营的动作构成了一个循环，这个循环可以称为“中台服务增长飞轮”，我们的服务地图建设和后续运营需要以构建“中台服务增长飞轮”为目的，以最大化中台系统的价值。 小结

以上便是个人针对“服务地图”构建的一些思考了。服务地图的存在，能在中台发展到一定阶段的时候，更好地向业务、向上级传达中台的能力和作用，并帮助中台部门在后续构建“中台服务增长飞轮”。