中台建设一直是很多企业在做的事情，很多宏观上的概念及框架是无法认知到执行层面是如何做一个功能的，本文用一个功能来聊聊中台建设中，一个功能是如何诞生的。

01 中台功能“新建标准表”

1. “新建标准表”的由来

先说明一下项目背景，这项目是一个“学生健康服务平台”的健康数据信息化网络管理系统；实现各级卫生业务数据的标准化、规范化和统一化管理。

“新建项目信息”是业务操作人员进行新的体检体测项目创建时，流程节点中的一个环节（功能），是核心业务流起点的标准定义，为每一期次测试的检测项目进行标准设置；如下图

2. “新建标准表”的价值

任何一个行业都是一样的，核心业务流中一定会有相应的行业标准，而“标准表”就是业务流中的核心，对每一个检测项目的检测标准做一个定义；

那么抽取“新建标准表”这个核心节点，在业务流程中，起到什么样的作用与影响，红线部分为新旧业物流中共性的部分，明显的优化，降本提效，同时沉淀业务核心能力。

提升了工作效率；而“新建标准表”的核心价值就是即优化了原有的复杂业务流，又规范了项目检测的标准；同时也是沉淀业务核心能力的一部分。

02 功能的排异聚同

1. “各业务流”的标准

确认各项目（涉及“新建标准表” ）的业务流标准

例如下：

体检：创建科室→创建项目→创建结论（结论分两种）→创建评价→创建配置表→创建测试

项目结论中数值结论、文字结论的定义，这里用一个实际业务举例说明，如下：

学生检测A类项目（数值类型）：身高、体重、肺活量…等

在数据采集的时候，采集的相关数据，如下：

在系统中，取值范围为文本框输入，结论是根据前者取值范围进行匹配。

学生检测B类项目（文字类型）：心、头、颈、胸…等

在数据采集的时候，检测结果：心 — 早搏

取值范围在B类测试中无法用数值表达，需用文字描述，这里为下拉框，结论是根据前者选择内容进行匹配的。

体测：创建科室→创建项目→创建结论→创建评价→创建配置表→创建测试

体测评价管理中建立体检评价不区分结论类型，但属性与数值类型一样。

如下（新旧业务流的对比）图：

旧业务流中

首先创建一次测试的流程如下：

1. 创建科室：内科、外科 … 等
2. 创建检测项目：填写项目基本信息包含：项目分类选择、项目名称、描述…等
3. 结论管理（判断）：判断创建项目的结论类型（结论是指检测项目完成后，给检测结果下一个定论）分为数值结论、文字结论。
4. 评价管理：设置每一个项目的评价标准。
5. 配置管理：为每个项目配置一个标准表，内设相关测试标准、采集数据区间数值标准 … 等。
6. 创建测试：创建新一期测试；这个环节需要把前面几个节点设置过的进行分步配置。

说明：

在创建项目~评价管理，需要先判断即将设置测试项目的结论类型是文字类型，还是数值类型；这里老业务流程中，出现分支功能，必须先行设置结论后，才可以进行下面的几个节点“评价管理、配置管理、创建测试”的业务操作。

最后在配置管理的节点进行大量设置，分别选择项目、结论、标准表、评价。

新业务流中

通过上图中新业务流的展示，我们可以看到，在新业务流程中，原始业务中的部分（结论~配置）操作流程，进行了拆解重组，因为中台建设的特性，就是将重复的工作量做减法，在平台多条业务线中，皆包含标准表的业务节点，那么我们将创建项目重新组合，将标准表这个功能抽离出来，进行能力下沉。

流程中重组 “创建检测项目” 部分时，这里可以同时配置好每一个项目的属性，包含：项目分类、项目名称、描述、项目结果值类型（数值/文字结论）、是否区分（年级、年龄、性别、班级… ）、成绩区间数值输入方式（最小值包含、表达式）、等；较流程中只配置项目分类、项目名称、描述等简要信息，在进行后续的多次配置，重组后的“创建检测项目”可以减少后续分支流程配置的复杂程度，同时减少用户操作成本。

中台抽取的核心业务环节 “新建标准表” 由于流程前部分已经进行（新）检测项目相关属性的配置，在此节点，只需要对每一个项目进行标准表的创建即可，无需如旧系统中进行多个分支流程的配置。

以上例子中，两条业务场景来看，流程上并无明显差异；优化节点与抽取共性的节点才是改进的重心。

2. 各业务流的共性、差异

1）寻共性场景，确定业务流

首先，在多个业务系统的总业务流程中寻找共性场景的过程，一定要非常重视业务流程的标准，不能模糊定义，不能因为建设而建设、因为抽取共性而抽取；

因为很多时候业务场景相似，但业务流中很多节点却又有不同，无法进行抽取；业务场景的高度相似，且业务流程标准一致，方可以进行共性的抽取。

案例：在业务流中操作人员填报标准信息时，这些填报项的属性中是否存在共性？共性项抽离出来进行归类；其次确定当前抽离的功能节点与所处业务流的前后流程节点的衔接是否有影响（关联关系）；比如创建项目时，填写项目

2）各业务流中存在的共性

当我们已经确认了各个业务流的标准后，这时进行同属性流程节点的拆分，提取出共性节点连接的小流程，为下一步 “中台 – 新模块” 的定义做准备。

案例：通过上面说到的业务流程标准中可以看到，原始各个项目的业务流中的 “创建结论标准→评价管理→配置管理“ 几个流程节点为共性部分，因此进行抽取（小流程），设计中台功能 “新建标准表”。

3）各业务流中存在的差异（是否沉淀）

3.1 “业务标准”的差异

各项目中的业务标准不一样；虽然创建科室至最后的创建测试的业务流存在共性，但是流程中节点的标准却不同；

3.1.1 体检项目（文字类）中业务标准部分的信息填写由“结论名称、项目是否正常”组成。

3.1.2 体测项目中业务标准部分的信息设置由“区间数值、项目评分、结论名称、项目是否正常”组成。

3.2 能力沉淀

不单单指一个业务流，也可以是一个功能模块；这些字段归类后，形成可配置的功能点也是沉淀下来的能力。

案例：不同业务系统中的流程会有细微不同，如下几点：

测试维度不同：

• 体检：按照年龄、性别进行测试。
• 体测：按照年级、性别进行测试。

体检系统会比体测系统多出一个结论类型（文字类型）

• 体检系统：检测项目没有数值标准，以文字描述为检测后的结论；称之为文字结论。
• 体测系统：检测项目均有相对的数值标准（特例：BMI 是身高体重数值计算得来）。

体测系统会比体检系统多出一个分支业务流“加分管理（学生优秀测试可进行加分）”

• 体测系统：学生测试项目成绩超出标准取值范围，可额外给与学生进行加分操作。
• 体检系统：无加分业务

从以上三点进行总结：

（1）可沉淀部分

维度配置管理：年龄、年级、性别抽象出来的可配置模块，通用性★★★★★

项目标识（业务标准项）：通用性★★★★

• 体检项目（文字类型）：结论名称、项目是否正常
• 体检项目（数值类型）：区间数值、结论名称、项目是否正常
• 体测项目（同数值类型）：区间数值、项目评分、结论名称、项目是否正常

上文提到的“业务标准”差异，对上一级功能（创建标准表）来说这是一组同属性字段不分系统，对下一级来说，这一组字段代表业务标准项，我们通过技术层面对不同项目做相应的项目标识，进而实现业务标准不同，但抽象的功能上通用。

通用字段维护管理：通用性★★★★★

体检、体测系统中均有：项目简评、项目总评，进行抽取，抽象为“通用字段”

（2）不可沉淀部分

加分管理

• 体检项目：没有为学生加分的业务场景。
• 体测项目：根据项目成绩进行加分。

因加分管理模块并不是通用性很强的模块，且低频需求，不进行沉淀，

3. 字段的处理方式

共性字段的处理方式

所谓共性字段就是从业务角度找到共通属性，进行字段属性的抽象理解并归集在一起；因为我们建设中台就是要减少重复工作，沉淀业务能力，有共性业务、共性流程、共性功能，所以共性字段其实也是中台组成的一个元素。

先定义字段的分类，然后区分同、异属性，进行所有共性字段的归集。

案例：共性字段在多项目中属性相同是可以通用的，但字段不同；分为以下两种：

• 维度（属性相同，字段不同）：设计成可根据标识匹配的独立功能，可在“维度管理”模块中做统一设置，在后续产品业务应用时，通过标识进行灵活调用。
• 各业务通用（属性相同，字段相同）：做可配置项，可添加、维护（同系统的字典）

异性字段的处理方式

当业务标准有差异时，我们需要通过另一种形式进行关联，比如项目标识、新配置模块（剥离出）、中间件形式（概念）。

案例：在异性字段部分，我们定义了实现形式（项目标识），根据不同业务（每一个字段项）进行变化，增加或减少；比如把带有业务标准属性的字段进行归集，通过项目标识，匹配项目对应的业务标准字段有哪些，调用并进行展示。

4. 功能的呈现样式

1）功能的呈现样式的标准

1.1 由于不同系统对于字段的定义略有不同，所以在字段归类时，需要抽象理解。

例如，同为数值类型属性的体检、体测项目中，归类的字段属性一样，但调用显示的字段项，却不同，如下：

体检项目 – 项目维度包含：年龄、性别

体测项目 – 项目维度包含：年级、性别

项目维度：负责检测的人员通过学生的基础资料进行检测；体检是按照学生年龄、性别进行测试的；体测是按照学生年级、性别进行测试的。

这里把这个基础资料进行抽象理解，定义为项目维度。

1.2 一定要考虑到业务的特殊性，每一个字段项的标准的差异。

例如，新建标准表的填写项中 “区间数值” 的输入方式有两种：

最小包含值 – 肺活量 三年级 输入 “2300”

如图所示：

一年级测试数值为1700 ，二年级测试数值为2000，那么二年级测试成绩的取值范围在1700~2000之间；定义得分、评价等级。

那么在进行最小包含值填写时，三年级填写2300，默认为上一设置的数值为节点进行数据计算，2000<x≤2300 为计算标准。

表达式 – 视力 右眼 输入 “9<x≤4.5”

如图所示：表达式为标准定义，有区间值的范围限制。

1.3 通过一系列的技术方案，定义几个项目的标识，进而实现在实际业务场景中，中台部分使用灵活调配。

2）不同系统中呈现的字段

2.1 首先我们进行归类：

• 红色字段——维度：把基础信息一类抽象为维度，归集在一起，
• 蓝色字段——业务标准：把业务标准同属性的一类归集在一起
• 紫色字段——各业务通用：把各系统通用业务字段归集在一起

2.2 以下为各项目所包含的填写信息的内容（字段）

通过上图是否清晰的认知到，如何归集不同的分类，如何抽取共性字段纳入其中。

下面附一个1.0版本的界面草图

03 总结

抽取四步法：

1. 摸清业务流标准 追本溯源，一定掌握最精准的业务流标准
2. 拆解业务流共性、差异 排异聚同，多维度拆解 —— 场景、流程、细节
3. 字段的处理方式 共性、异性的不同处理方式，根据业务变化，灵活运用
4. 功能的呈现样式 不论中台如何建设，面向客户/用户时，开启小白模式

多说一句，企业产品平台化，规范标准进行中台建设，就像每个人，人到中年，综合能力素质进入磨合、沉淀阶段，如何给自己的能力磨刀，如何沉淀新纳入的能力，都需要不断打磨，共勉。

工作流及方式不是“弱水三千只取一瓢”，那么多瓢，由你来挑 ~

作者：逐流 ，微信公众号：Unique先森说产品（ID：Unique_Mr_z）

本文由 @逐流  原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议