在数字化转型的浪潮中，中台建设已成为企业提升竞争力、实现高效运营的关键策略。然而，中台落地并非易事，它需要系统化的知识体系和丰富的实践经验。本文为你精心整理了中台落地必备的35个知识点精华合集，从理论模型到实践方法，从架构设计到业务建模，全方位覆盖中台建设的核心要点。无论你是中台建设的初学者，还是正在寻求优化的从业者，这篇文章都将为你提供宝贵的参考和启发。让我们一起深入探索中台建设的奥秘，助力企业在数字化转型的道路上稳步前行。
在我的《中台产品经理：数字化转型复杂产品架构案例实战》一书中，也就是中台系列第二本著作中台案例集中，为大家总结了35个建设知识点，为了方便大家更好的阅读与回顾本书内容，我将本书的知识点与案例摘录于此，方便大家进行快速查阅。
以下内容为本书原文摘录：
书中插图 诺兰信息系统六阶段模型
该模型是由美国管理信息系统专家理查德·诺兰(Richard L.Nolan)通过对200多个公司、部门发展信息系统的实践和经验的总结，提出了著名的信息系统进化的阶段模型，即诺兰模型。通过六个阶段定义了企业应用发展的一般性规律，六个阶段分别为：初始阶段、拓展阶段、控制阶段、整合阶段、数据治理阶段和成熟阶段。
（1）业务架构（Business Architecture）
把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、考核体系、地域分布等内容。
（2）IT架构（IT Architecture）
指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括系统架构、数据架构和技术架构三部分。
所谓战略导入，就是指公司管理团队在引入战略时，需要判断当前战略是否匹配本企业，以及引入对该战略后将要为企业带来的收益定性，并定下具体收益目标。
企业组织架构形态指的是企业内部部门的层级结构，而UHM企业组织结构理论是由管理学家威廉姆森（Williamson）提出的，在该理论中将一家企业内部的组织形态划分为U型（一元结构）、H型（控股结构）和M型（多元结构）三种基本类型。
（1）事业部：指独立面向一个细分市场而运作的独立业务单元，而非具体职能部门；
（2）业务线：指事业部下各职能部门，如营销业务线、采购业务线、仓储业务线；
（3）产品线：指承载某业务线所有需求的系统集合，如会员产品线：CRM、营销系统。
书中插图 行业三分模型（SCD）
行业三分模型（SCD）指从宏观维度上可以将任意行业拆分为三类角色，这三类角色分别为：
（1）产业：具有某种同类属性的经济活动的集合体；
（2）产业链：是一个包含价值链、企业链、供需链的集合体；
（3）行业：是具有高度相似性和竞争性的企业群体。
一家企业增长的底层基本逻辑，任何企业的良性增长内核都可以划分为两种模式：
a、行业性增长（如疫情时生鲜电商整个行业增长；一般出现与新兴行业初期）；
b、结构性增长（行业没有增长，但某些品类受下游需求而高速增长（存量阶段））。
（1）业务线产品设计思路
业务线的产品研发实质等于面向单体业务的研发，过程通常是这样的，产研在单一业务线中，根据当前的业务场景展开业务流程分析，完成PRD撰写，随即进入开发环节。在这其中对于业务需求的获取与确认是唯一的，即该产品的对应业务线使用人员或者对应细分业务的目标客户，在产品设计中不需要思考产品的扩展性与兼容其他业务。本质就是将当前所面对的业务流程线上化，而如果一家企业内部拥有多个不同的业务线，这样建设后企业内部就会有一个个竖井式的产品诞生。
（2）企业级产品设计思路
中台产品的设计与研发是面向企业整体的，要求产研团队能以全局式研发出发，通过对公司内多条业务线的业务进行通盘思考，并对公司的整体发展趋势进行关注，在这基础上抽象出对整个企业是通用的能力，将通用性部分交由中台团队进行研发，而将特异性部分交由
各业务线产研团队进行研发，由业务线负责具体对应的业务客户的特殊化方案，从而有的放矢的开展中台建设。
BMM（Business Motivation Model）商业动机模型，是通过自下而上的方式，根据已发生的业务活动，推导其背后的商业战略决策，从而实现对企业商业决策演进方向分析的工具，模型的完整结构如下图所示。
书中插图 BMM商业动机模型
（1）End（企业成果）
该模块定义L电商公司最终希望达成什么样的结果，也就是企业目标。
（2）Means（行动）
该模块定义一个企业需要做什么来实现它的目标。行动定义了企业为实现其目标而决定需要做什么。
（3）Influencer（影响者）
该模块是企业发展中可能影响它决定与决策的事物。
（4）Assessment（评估）
当影响者引起重大变化时，企业对其影响进行评估，识别风险和潜在回报。可能会有多个评估，可能来自不同的利益相关者。根据 BMM 中记录的相关早期评估结果，判断推导出的企业战略/经营方针结论是否可信。
以上四个部分共同组成了BMM模型。
用户旅程指用户在企业商业活动中各部分是如何参与的，以及达成交易需要完成的环节，从而直观的看到用户在企业业务中的关键触点。用户旅程图指的是一个有方向的信息流，描述用户与企业各个接触点的联系，描述在不同业务单元的推动下最终实现用户转化。具体用户旅程图绘制框架如下图所示。
书中插图 用户旅程图框架
业务指通过提供产品和服务给客户，以获取某种价值，形成业务闭环并能够或有潜力自负盈亏（作为协同业务，成本可控即可），其完整的构成元素如下图所示。
书中插图 业务构成元素
任意业务必然存在一个核心循环，而企业通过不断推动正循环，以推动企业不断增长。
在日常的软件设计开发中，为了解决如何将需要管理的事件信息点进行无遗漏的定位，此时需要找到所有事物的信息流，并拆解出管理要素的这个过程就是业务建模。
而在业务建模中最终目标就是要得到一条完整的业务信息流，信息流的构成可以分为三个层级分别为：
（1）流程层：该业务活动中存在的参与者角色与先后交互关系，如订单审核业务活动参与角色为下单者、审核者；
（2）约束层：该业务活动中的交互规则，如订单审核活动时间只在9点至18点；
（3）实体层：该业务活动中各角色参与者交互的具体数据，如订单审核业务活动交互的数据对象为订单。
（0）信息流范围定义；（1）信息输入；（2）信息输出；（3）信息处理公式；（4）信息参与角色；
这里（1）、（2）、（4）项，其实也就是在产品工作中经常被提到的“场景”含义。
企业价值链（VCM）分析法指将一家企业内外价值增加的活动分为基本活动和支持性活动两大类，如下图。
书中插图 企业价值链（VCM）
（1）基本活动：指涉及产品的物质创造及其销售、转移买方和售后服务的能为企业带来价值的各种业务活动。基本活动常见的类型有：企业生产、销售、进料后勤、发货后勤、售后服务等；
（2）支持性活动：指辅助企业运作的基本活动，本身不产生价值，并通过提供资金投入、技术、人力资源以及各种公司范围的职能支持基本活动。支持性活常见的类型有：人事、财务、计划、组织管理等。
在基本活动和支持性活动的共同支持下构成了一个企业完整的价值链，这就是企业价值链分析。
流程的本质就是一组共同给客户创造价值的相互关联的节点活动进程，是企业价值创造的最小机制。这里可以用一个形象的图来为大家介绍流程的概念，如下图所示。
书中插图 流程定义
企业主数据指企业内一致并共享的业务主体，是各个系统间一致并共享的数据。MDM（Master Data Management）主数据管理，是在企业主数据概念之上，通过以整个企业为管理单位，保证企业内主数据始终唯一且统一，并支持不同业务任意取用的管理方式。
将企业信息流进行抽象，得到已经梳理出的信息流提取为信息节点，而凡是需要纳入中台建设的节点均称之为核心节点，在核心节点下依据不同重要级分为关键节点与非关键节点。
（1）关键节点：定义出需要要标准化的节点，以及对应节点流程；
（2）非关键节点：针对无法标准化但仍要放入中台的业务。
SOP是 Standard Operating Procedure三个单词中首字母的大写，即标准作业程序，指将某一事件的标准操作步骤和要求以统一的格式描述出来，用于指导和规范日常的工作。
管理者在设计一个业务活动的工作通常可以划分为三步：
类型1：事前控制类工作（预防性控制）:
类型2：事中控制类工作（过程控制）:
类型3：事后控制类工作（检测性控制）
应用架构就是软件体系结构描述，描述为解决使用对象（企业/组织/个人）的某个业务领域问题，而由哪些系统构成，以及各个系统的之间依赖关系。
（1）领域级公共能力层级：针对既定的业务领域，如商品/交易/会员；
（2）企业级公共能力层级：不聚焦于任一业务领域，在企业内可独立接入与使用，如权限/审批流。
在中台组件设计中，一共包含两类典型的组件：
（1）业务组件：将已经规范后的同一领域下的不同场景合并一起，提供一套全集功能承接该领域的全部需求；
（2）数据组件：规范数据存储方式与结构，构建相同业务下标准化的数据实体。
注意在组件设计中，一定要面向已经规范的业务，否则将导致组件无法复用。
不在局限于代码层面的复用，而是将一个业务场景下的完整解决方案进行抽象实现复用。在实际场景中通常为将该领域下多个功能模块进行通用化改造，并打包在一起，给前台开发者提供一站式复用。
拓展服务是一种可选配的非必须组件，用于提供领域内常见的配套服务的复用，从而让业务线在接入时不仅复用本领域的能力，还可以实现常见的接入后配套开发的复用。
共性抽取实际上就是去寻找企业内部多个相同领域业务线都使用的模块、节点、业务流程，从而将这些共用的部分提取出来，这就叫做抽取共性。
服务中心是指将某一项在公司不同事业部内相同业务线，具有相同或类似需求的服务抽取出来作为一项公共服务开放给不同的事业部。
如果将服务中心概念仔细拆解，可以得到服务中心标准构成：
“服务中心 = 组件（业务 + 数据） + 拓展服务”
产品架构图 = 层级定义 + 领域解决方案定义 + 关系定义
（1）层级定义：产品划分为哪几个层级？各层级解决什么维度的业务问题？如：企业级问题、业务线级问题，定义后根据维度由高到低的顺序得到上下层的垂直结构；
（2）领域解决方案定义：在每个层级中填充需要具体解决的业务领域的解决方案，并得到各业务领域具体承载的功能集合的纵向结构；
（3）关系定义：虽然每个层级与服务中心各自独立解决不同维度与不同领域的问题，但是各服务中心与领域之间一定会存在联系，这种联系可能是依赖，也可能是关联关系，此处需要将这些元素之间的关系表示出来。
为了应对不同标准化程度的业务类型，在中台建设中设计了三类服务中心，予以适配不同类型的建设需求。
表 服务中心分类
（1）寻找企业内共性的领域；
（2）约谈该领域的各业务方；
（3）设计统一化的该领域流程；
（4）约定各业务方运营路径；
（5）定义统一路径为该领域公司级标准流程。
结构型服务中心的设计采用SD设计公式进行，全称为Summary与Details分离化设计模式，其中Summary指信息对象摘要，Details指信息对象详情。该公式将信息对象的摘要存储在中台，将信息对象详情由业务线系统管理，实现分层级管理。
组装型服务中心设计采用最小颗粒度法进行设计，由该服务中心定义不同类型的元素，交由前台业务线进行“积木拼装”，按需实现业务线的具体需求。
中台建设所依赖的抽象业务模型是有时效性的，在建设完成后会出现中台系统与业务系统在功能或流程上出现差异而无法接入的的现象，从而导致与中台的对接出现阻塞，这就是特异性问题。
所谓插件也就是中台开放一些对应的接口，允许业务方去插入一个自定义的代码段，自定义代码段可以去调用中台的上层服务，跳过部分流程。从而实现在符合现有中台逻辑的调用，然后在具体的业务层去替换这部分的含义，使它赋予新的业务含义，从而让业务能成功接入到中台中。中台插件如下图所示。
书中插图 中台插件定义
以上为知识点合集，而关于知识点的具体应用可以去看《中台产品经理：数字化转型复杂产品架构案例实战》一书。
本文由人人都是产品经理作者【三爷茶馆】，微信公众号：【三爷茶馆】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。