业务中台实战

原创： 半个金俗人 

中台，最近因2019腾讯全球数字生态大会再次被大家讨论的火热。

众所周知，阿里是国内最先实施中台的企业，也是目前国内将中台运用最好的企业。随着今年产业互联网成为很多大公司追捧的方向，中台在其中所将起到的作用更是不可忽视的。

那么作为中台产品的灵魂，一个优秀的中台产品经理更是不可或缺的存在，市场上现在可以看到中台产品经理的薪资也随着产业互联网水涨船高。

笔者了解到，北京某行业头部公司，对有1-3年工作经验的中台产品经理的开的工资是20-30w/年。

那么，一个优秀的产品经理都需要有哪些能力呢？

接下来本篇文章将详细讲一下业务中台产品经理都需要哪些能力？

一、业务抽象

在业务抽象阶段，通过业务调研和业务分析，设计业务蓝图和抽象业务元素，为下一阶段的中心建模阶段准备顶层思想和业务素材。

对于中台产品，需求有以下几个特点：

1.目标用户明确，如给内部运营人员使用，还是给商家使用，通常会有明确的业务诉求；

2.产品价值更容易量化，后台产品解决的永远是效率和成本问题，比如自动化审核能减少审核时长是可量化的，客服系统一系列的指标一通率，AHT，ATT等；

3.业务方提的需求不一定是产品需求，后台产品常面对2种极端，要么用户以为所有的问题都可以靠产品解决，所以会提很多需求，要么对系统没有概念，原来不依赖系统工作也能完成。

面对这种情况，只有产品经理深入了解业务，认识到问题的本质，然后再采取策略，结合时间点、成本、产品规划等，得出是用产品策略还是业务策略解决。比如很多创业创业公司的数据都是靠excel导出再加工，而不会直接上数据可视化或监控，有的需求可能是短期需求，是否加人先过渡一阵子就可以。说到底也是对需求优先级的判断，不仅从产品出发，更多还是要有业务思维。

在面对无限的需求，产品经理做的工作就是决策、计划、执行。如何执行，需要有一套可以落地执行的方法论，根据自身的经验，总结出如第一现场、闭环反馈、数据驱动、埋点、流程思维、结构化思维等方法论，以后将陆续展开。

二、高阶设计

1. 中心规划

经过业务的调研和分析，技术架构师理解并熟悉了业务。基于上阶段输出的主题域，技术架构师按照中心的多个划分标准，进行中心的规划。

2. 0 级架构设计

业务中台的0级架构本质上是应用架构，它以中心为最小单位进行设计，因此也称为整体架构设计。

0级架构包括了功能层级的架构和技术层级的架构。

功能层级的架构需要描述业务中台在整个数字平台中所处的位置，业务中台由哪些中心组成，以及中心与应用、中心与后台的交互关系。功能层级的0级架构承接了企业的应用蓝图规划，指导企业各IT系统的职责划分和定位。

下图所示为一个企业功能层级的0级架构示意图。

功能层级的0级架构示意图

从上图中我们可以看到，企业整体功能架构从下往上分为IaaS层、PaaS层、基础组件层、数字中台层（包括业务中台和数据中台）和业务应用层。

每一层的具体功能如下：

IaaS层：完成硬件资源的虚拟化管理，为用户提供对资源的使用服务。

PaaS层：为应用软件提供部署平台和运行环境。

基础组件层：介于业务服务和技术中间件之间，提供通用的业务功能和技术功能，并解耦业务应用和技术中间件。

数字中台层：分为业务中台和数据中台，实现企业业务活动的核心机制，并通过数据中台对业务运营提供指导。

业务应用层：通过调用和组合中台能力，实现应用逻辑。

技术层级的0级架构需要说明各系统、各中心分别使用什么技术来实现，以及整个体系的技术分层，如下图所示。

技术层级的0级架构示意图

技术架构总体上分为展现层、服务层、接口系统、运营管理和运维支撑。

展现层与服务层相分离，展现层采用当下主流的前端框架，分别对移动端、PC端进行支撑。通过合理的技术搭配人性化的设计满足用户感官体验需要。

服务层的架构采用分布式的微服务架构，微服务架构去中心化加强终端的特点，让服务免去雪崩效应等容灾上的风险。同时，整体技术架构具备易于扩展、组合、部署，可支持动态伸缩、精准监控，并且可以提供灰度发布等优点。

服务层包含应用服务、中台服务、技术服务。

应用服务与中台服务都以微服务架构实现。

技术服务又分为PaaS层和IaaS层：

PaaS层通过各项基础中间件的能力向上层输送搜索引擎、分布式文件存储、分布式数据库、分布式缓存等能力；

IaaS层向用户提供基础资源服务。

运营管理通过埋点技术、A/B测试技术、大数据技术来进行数据采集分析和业务试错，并通过计算结果来指导业务工作。

运维支撑将从底层对所有服务做支撑，运维体系通过对基础设施的监控、服务升降级等措施来确保系统的容灾能力与稳定性。

3. 中台核心数据流规划

中台核心数据的规划和应用总起来说可以用四句话来概括，即确定目标、数据匹配、架构规划、业务应用。

首先要明确方向，确定要达到的效果并圈定数据应用的大致范围。

只有目标明确了，后面的工作才会有指引。如果为大数据而大数据，后面就会迷失方向，陷入数据的迷宫不能自拔。所以决策者一定要围绕行业的特点、围绕企业的实际思考问题。

在应用的方向及效果达成共识后，就要开始对数据进行梳理。

哪些数据要纳入我们分析的范畴，哪些数据是企业内部的、哪些数据是企业外部的、哪些数据需要设置埋点获取等。数据的结构和字段是否符合要求？需要实时采集还是定时采集？等等都是企业要考虑的问题。就像做菜一样，当菜品定好后，食材的选择极为关键，需要下大功夫。

当数据源的问题解决后，如何来对数据进行梳理、清洗、提炼就成为关键节点。通常我们会将数据的利用架构分为三层，即操作数据层(ODS)、公共维度模型层(CDM)和应用数据层(ADS)。通俗点讲，就是食材的一个加工烹制过程，只有经过专业的处理，这些看似庞杂纷乱的数据才能剖石见玉、焕发异彩。

有系统的分析方法和海量数据支撑，可以在许多方面给企业带来助益，甚至可以重构企业的商业模式。比如，笔者参与推进实施的茅台云商大数据项目。借助数据中台，“稳”住市场，通过反黄牛机制，减少了终端市场价格炒作、囤货居奇的现象，使真正的消费者能够买到茅台酒。未来还要“进”化市场，通过对消费者的标签分类、行为画像，发现不同类型的消费者偏好，为个性化定制酒、众筹酒做好数据积累，是营销模式的创新。

三、组件建模

1. 产品设计

产品设计是在业务顶层设计的指导下，逐层往下抽象的过程，主要是将业务调研的成果转化为产品原型和需求规格说明书（主要由业务场景、业务流程构成）。

如何做应用的原型和画出业务场景不是本节的重点，详细内容可参看相关专业书籍，这里需要强调两点：

中台产品的详细设计需要以面向中心为指导思想。不仅需要设计出应用需要实现的功能，更重要的是要将需要中心支撑的功能明确标识出来，归到中心的待实现列表里。这样技术工程师在领域建模阶段才有具体和明确的输入。

建设中台的核心目的不是为了共享，共享只是中台的特性。中台是为了完成业务的核心运行机制，为前台提供业务能力基础的系统。确立了这个原则后，产品经理才能放开手脚，自主推动中心的建设。

2. 组件模型设计

组件模型设计承接0级架构设计，是对中心内容的展开。

通过对中心功能的分析和对中心业务实体的抽象，将具有较强依赖关系的业务实体聚合为一个组件，或者将具有相同主题的业务功能聚合为一个业务组件。最后，以结构化的形式聚合这些组件，构成中心。

如何判断组件模型是否合理呢？

是否很好地支持业务流程、业务场景、复杂的业务规则是衡量组件模型优劣的标准。我们可以通过穷举边界业务场景的方法，来反证组件模型设计是否合理。

最后需要强调一点，组件是可以独立为微服务的，只要符合微服务的条件，就可以独立。

但是，在实践过程中，我们发现如果微服务承载的业务规模不大，独立带来的业务价值不高，反而会增加运维成本。

3. 1 级架构设计

组件模型设计完成后，需要将模型转化为应用架构。这里的应用架构是指中心内部的应用架构，我们称为1级架构，1级架构是以组件为最小单位设计的功能层级的架构。

1级的功能架构是必不可少的，它指导着我们的设计和开发；技术层级的1级架构可视情况而定，如果技术内容比较复杂则需要输出。

4. 关键交互图设计

前面已经完成了0级和1级的架构设计，有什么方法能证明设计是否可以满足实际业务场景的需要吗？

我们可以通过实现业务场景的动态交互图，来反向论证设计的合理性。

如何判断动态交互图是否合理呢？

根据业务逻辑是否清晰、流程是否简洁、客户交互是否高效来判断。

如果设计出的交互图不合理，那就说明0级或1级架构存在设计不合理的问题。另外，通过交互图还可以较好地将设计思想传递给开发团队。

四、开发交付

我们主张采用敏捷的方法进行开发交付，将最终目标拆解为多个小目标，逐个完成。同时，又将每个小目标拆为多个子项目，每个小团队各自负责一个子项目，所有团队并行开发，协同向前推进。

一般来说，流程包括迭代规划、需求反讲开发、持续集成交付和回顾总结调整。

五、持续运营

项目上线后，只是产出业务价值的开始。

数字中台需要在持续不断的运营中，包括业务运营、内容运营、技术运营和数据运营，不断沉淀和发展。其中，能力会逐步增强和扩展，模型会逐步调整和完善。