本文来源 / 51CTO官微

讲中台之前，我想有必要先说说什么是产品实现机制的前台和后台。

所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等。用户对产品的认知与体验也由此而生。比如大家对于微信的理解就是这个前台APP给大家展示的一切。

而后台包含两个部分：

企业的内部管理服务的统称，如：内部的CRM，ERP等；

为前台提供服务能力的，如：数据压缩能力，并发等。

后台最重要的特点就是其提供的服务都是不被普通用户所感知的，就像用户不会因为应用的并发，传输速度而记住微信这个品牌。

在搞清楚了前台与后台的概念后，前后台模式的产品服务模式我们就可以用一张图来概括描述：

总的来说就是：后台提供能力与计算，前台将后台的能力进行封装以图形化的形式展示给用户，让用户能更容易的使用公司提供的服务来解决个人需求。

在厨房里，配菜小哥就是中台

实际上，中台的出现更多是因为公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。

在互联网进入日益复杂的市场环境的今天，市场中由于存在众多的竞争者，也逼迫着企业需要不断去更新产品去抢夺市场。而作为实际用户真正接触的前台业务，如：APP、小程序、网站等，必须要快速迭代新的功能才能让用户感知到。

而在这个大背景下带来的矛盾就是——以往为了支撑前台越来越多的业务，后台不断地建设庞大起来的系统，由于一直在追求稳定性而生，反而在这个时候显得越发笨重起来。这样的后台变得越来越没法去快速响应前端变化所带来的改变。原先的前后台模式的这种直接关联决定了两者的冲突不可避免。

中台解决方案到底是什么呢？让我们举个通俗的例子来说，如果将互联网公司的研发中心比作一个厨房，将研发新产品的过程比做菜的话，我们就可以很容易理解这个概念了。

首先请大家想一个问题，在一家客流量非常大的餐厅中我们要如何缩短客人的等待时间呢？

相信很多人的第一想法就是增加多名厨师，但时大多数的餐厅单纯的增加厨师这是不实际的，因为每增加一个厨师是有很高成本的，而且每天忙的就是中午和晚上这两个时间点，虽然在饭点解决了问题，但是在一天中其他的时间里，厨师人员就显得非常冗余了。

而正确的做法是先将做菜这个任务拆分，让做菜这一件事变为多个环节来思考，我们完全可以只需要增加一位配菜的小哥来代替厨师去进行前两步，这也就是现在大多数上规模餐厅的组织架构：

这样我们每一位厨师新做一道菜时没有必要一定要从买菜，洗菜，切肉这些最基础的环节开始，而是完全可以直接使用他人切好的肉片，洗好的菜下锅，唯一需要关心的就是如何在搭配调料上研究不同的创意，这完全可以大大提高厨师的做菜速度，同时在成本上我们只增加了一个人就解决了所有问题。

回到研发流程来看，买菜其实就是我们研发的后台，他们帮助我们解决最基础原料问题。厨师是我们的一个个业务前台团队，他们要做的就是根据不同地区口味烹饪出对应的菜系，而在业务多元化后洗菜，切菜，配菜都可以交给中台解决方案去完成，做菜的时候作为大厨只需要喊一句要什么材料既可，当然这里的配菜小哥就是我们的中台。

如何培养中台思维

从产品层面，中台本质上是将后台的逻辑层抽象出来的一种系统模块，其目的在于快速的支持业务发展，因此，个人认为，中台实际上是站在“快速响应需求迭代”角度的一种产品设计思维。

当系统足够庞大时，产品、业务和用户的每个需求都会涉及到多个系统关联，尤其是针对多事业部的公司，这些系统都分布在不同的事业部，所以难免会有一些问题：

1.系统复杂，无法快速拿出产品方案

2.多重对接，沟通成本巨大

3.系统间耦合性较大，牵一发而动全身

基本上因为以上问题，新的业务需求无法快速满足。当一个业务诉求牵涉到系统较多时，需要对应配合的人数太多。因此，从产品/系统角度，我们就需要考虑以中台化的思维去进行方案设计：

通用性

对于业务需求，要跳出需求看本质，理解业务方的真实需求是什么；要跳出模块看全局，理解这个需求的实现，除了对消费者、商家的价值，要看到它对平台的价值。

例如之前负责的订单导出功能，其实用户需求很简单：快速导出数据，进行业务分析，但是站在平台角度，平台富有对用户数据保护的义务，因此需要考虑从数据及用户层面做权限控制；同时也考虑到商家不仅需要导出订单，后续可能导库存、商品及其他业务数据，因此需要考虑产品的通用性，以降低后续开发的成本。作为平台型产品经理，要通盘思考整体的结构，才能做到互不牵连。

结构化

在方案设计上，要做到通用性，需要将通用能力从解决方案中抽离出来，与业务场景进行解耦，从而实现“业务场景-通用能力”系统架构。

还是拿订单导出举例，刚开始设计订单导出时，权限控制，导出任务创建，导出数据下载，订单业务耦合，其他业务接入时费事费力，还有可能对现有业务产生影响。因此才将订单导出的通用能力从业务场景中解耦出来。

标准化

将通用能力与业务场景解耦只是第一步，我们要将通用能力进行打包，形成一套标准化模版，以接口化的形式赋能到外部的业务场景，供业务场景按照标准化的形式进行接入和开发，降低其他业务导出的开发成本。

以订单导出举例，我们将“权限控制”，“创建导出任务”，“下载导出数据”封装为不同的接口，形成导出中心，提供给不同的业务场景。

可拓展

到这一步，已经形成了“单通用能力对应多业务场景”的系统架构，若业务侧有定制化需求，可从业务场景角度进行单独定制，以致于不会对其他业务场景产生影响，也提升了定制化需求的研发效率。

正在思考的数据中台

所谓数据中台，即实现数据的分层与水平解耦，沉淀公共的数据能力，笔者认为可分为三层，数据模型、数据服务与数据开发，通过数据建模实现跨域数据整合和知识沉淀，通过数据服务实现对于数据的封装和开放，快速、灵活满足上层应用的要求，通过数据开发工具满足个性化数据和应用的需要。

这个图只是John思考的一个点，如何有效的讲数据打通，主体是建立更完备的用户画像。也许我的目的就达到了。

中台是什么真的不重要

以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力，是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段，并不是⽬标本身。

中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境， 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾，提供⼀个中间层来适配前台与后台的配速问题，沉淀能⼒，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应⼒。

所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化，只是恰巧走在了了这条正确的⼤道上。

相关文章