编辑导语：中台要解决的是什么问题？随着企业日常业务渐趋复杂，内部诉求日渐增多，此时中台的出场，一定程度上可以实现降本增效，减轻业务处理负担。不过，中台的存在有“好”也有“坏”，我们需要辩证地看待。本文便阐述了中台存在的意义和相应设计策略，不妨来看一下。

近两年来，以阿里为首的很多互联网公司，随着业务的整合，开始搭建中台，然后随着业务的发展，又开始拆分中台，由此引发了很多的争议。从最初的万人追捧，到后来的跌下神坛， 再到现在的褒贬不一，只要是关于中台的话题，总让人喋喋不休，但无论好坏，都不能否认它近年来的火爆。

中台到底有没有用，是业务发展的助推器，还是绊脚石？中台的意义和价值是什么？中台又该如何设计？本篇文章，将从供应链中台的视角，来分享一下我个人对中台的一些总结理解和中台的设计思想。

一、中台是如何形成的？

为了弄懂中台的形成规律和底层运转逻辑，我们有必要先了解一下什么是中台，先看一个故事：

X公司在天猫、京东、美团、拼多多、头条等电商平台都开店，且业务覆盖全品类商品（3C数码、电脑办公、图书影像、食品生鲜、医药保健等）。

这么多的销售渠道，每个平台的履约诉求不完全一样，每个渠道有一波业务负责运营，但后台供应链相关部门都是统一的，无论是采购，还是仓储、物流作业流程都是一样的，所有平台都共用采购、商品、仓储、库存等供应链能力，千言万语一句话，老板的需求很简单：商品库存能够共享到各个平台上同时售卖且能够从同一库房发货。

▲多平台供应链业务形态

如果只有一个业务平台，对供应链的需求只会来源于这一个业务，供应链侧各部门和系统直接为此平台做定制化需求就可以了。

但如果有多个诉求不一样的多个平台同时存在，供应链单独满足任何一方都会给其它方带来问题，但我们又不可能为每个平台搭建一套供应链的体系。

于是，为了能满足各个平台的诉求，就需要在供应链侧来适配各平台的需求，除了满足大家公共的进销存退需求，让业务接入更加简单外，还需要兼容每个平台的个性化需求，这便出现了供应链中台：为解决多业务共用供应链而生。

我们通常说的中台局限在系统层面，但实际上，系统是源自于业务的，在很多公司，中台不仅包含中台化系统，还包含中台业务部门，还是拿供应链来说明：

一，中台部门。负责将现有的供应链能力以业务的视角组装并提供给其它部门，通常的工作是作为一个统一出口对接各个外部业务方，并横向分析供应链的整体效能，从全局视角出发做供应链流程优化，让各供应链基础部门的协同更好。

二，中台系统。将现有的供应链基础能力进行组装，提供给其它业务系统接入，从系统分类上，可以分为业务中台和数据中台。业务中台主要提供供应链的业务功能，数据中台主要提供数据的集成和分析能力。

▲中台部门与中台系统

二、中台解决什么问题

中台在公司的定位，举个经典的比喻，它就如同战场上的航母和战斗机，业务是战斗机作战群，中台作为航母为之提供有利后盾和保障，让业务更加轻装上阵，免除后顾之忧。

当然，并不是所有的公司都需要中台，如果只有一个业务方向，是不存在中台一说的，但在多个平台模式下，如果需要订单、库存、仓储同时能对接多个平台业务，并同时满足各方的业务诉求，这才需要用到供应链中台能力，我们需要将底层供应链的基础能力变成中台服务，提供给各平台各业务共用，它可以是某个部门、某个人，也可以是某个流程、或系统能力。

▲中台的搭建就像造航母

在日常工作中，中台主要解决如下几方面问题：

1）底层能力的复用，降低业务与系统成本。

当多个业务都需要供应链能力时，将已有的供应链业务和支撑系统进行升级，使其能同时支持多个业务方，通过复用的方式同时降低业务成本和系统研发成本。

2）把复杂的底层能力对外简单化、透明化。

供应链本身就是一个庞大且复杂的体系，自己人尚未能完全理明白，更别说让业务来理解了，但业务又必须用到供应链的能力，如何是好？这就需要供应链中台来转化了，供应链内部可以很复杂，但通过中台转化后提供给外部业务部门时必须足够简单明了，否则就不是一个好中台。

3）将多点对接的网状结构变为单点对接，流程更清晰。

无论是中台的部门还是中台系统，都是多组织形态的，任何一个业务如果单独对接采购、仓储、配送等部门，成本都会非常高，会变成一个多对多的网状结构，而供应链中台则可以作为下游供应链部门的一个统一门面对外，将多点对接变为单点对接，流程会更加清晰，难度也自然降低了。

4）关键信息聚合。

中台建设的另一个目的是将关键的信息做聚合，而不是散落到各方，这样当需要数据时，就能够从中台直接提供，而不是从各个系统里去提取了。

三、中台的本质：沉淀+复用

说起中台，可以很复杂，复杂到涉及十多个部门，几十个系统，几百号人之间的相互协同，同时也可以很简单，简单到用两个词就够了：沉淀+复用。

1. 沉淀输入

中台需要将一些可以复用的业务、功能和数据尽可能沉淀下来，不要让每个业务自行实现，否则是极大的浪费，还会增加业务的接入成本。例如X公司有多个仓，针对商品的库存管理功能，如果A业务有，B业务也有，C业务也需要，那就应该考虑放到中台来集中实现。

但所有的能力都应该落到供应链中台吗？

当然不是，供应链中台的搭建目标并不是要替掉业务方，而是让业务能更好地开展业务，不被后端供应链所拖累，所以最佳合作方式是划清边界，一起共建，原则上只将相对稳定且比较通用的的能力落到中台，而个将性化的业务逻辑交由业务自由发挥，具体实现时可根据具体情况具体分析。

同时，中台能力的沉淀绝不可能一蹴而就，它一定是一个慢慢积累的过程，很多能力在尚未成型时更加适合放到业务侧去，等稳定成熟以后再落到中台。

2. 复用输出

随着中台沉淀的能力越来越多，就能够给业务输出更多的通用的复用能力了，包含流程层面、人力方面和系统层面。

拿X公司的采购业务来说，无论有多少个业务平台，都可以共用公司的采购的流程、采购部门的人力和采购系统，在这种情况下，采购部门充当的职能就是中台的角色，将采购的能力集中化输出，满足各方采购诉求。

▲中台的本质：沉淀与复用

中台能力的输出好坏取决于沉淀的多少，如同做蛋糕，可使用的模具越多，就能做出越多不同的图案样式，如果沉淀不够，自然就会缺东少西，业务接入也会坎坎坷坷。很多中台在搭建之初效果不好，让业务感知不好用，原因就在此。

所以，搭建供应链中台请一定多一些耐心，要相信，随着沉淀的慢慢增多，中台输出能力会越来越强，业务的接入也会变得越来越简单和顺畅，也更加愿意接入和向中台沉淀，最终形成良性飞轮效应，让中台的势能和价值发挥越来越大。

▲中台良性运转飞轮效应

四、中台的建设思路：公共沉淀+差异处理

无论是中台业务，还是中台系统，在搭建时其实都是在处理两件事：公共沉淀和差异处理。

1. 公共沉淀

针对各业务方都有相同诉求的公共能力，做到尽可能通用和完善，以便更好地提供给多方复用。沉淀的内容可以是业务和流程，也可以是系统功能，还可以是数据，总之是能够共用的，有价值的，都往中台沉淀，准没错。

2. 差异处理

业务不可能一模一样，否则就不需要多业务了，所以中台在建设时，一定会遇到差异化的处理场景，比如不同平台的差异、不同业务的差异、不同流程上的差异，以及不同的场景差异等。这就需要中台具备足够的兼容性，能够在公共沉淀的同时解决差异化问题。

▲中台的设计思路

五、中台设计：能力输出模型介绍

中台的价值体现是将复杂的底层基础能力输出为业务能快速接入的中台服务，我们将输出的过程抽象成一个通用的模型，暂且称之为“中台能力输出模型”，自下而上分为底层支撑——中台加工——能力输出三层，Support-Process-Output，简称SPO，如下图所示：

▲中台SPO能力输出模型

解释一下这个SPO模型：

1）底层支撑：这是最底层的基础服务能力，但相对专业、繁琐，外行人可能不好理解。例如基础数据、履约、仓储、配送的能力，光专业名词术语学习起来就比较费劲了，更不用说深入了解其底层逻辑了。

2）中台加工：这就是我们的中台化过程，将底层能力进行加工输出，抽象为通用的可以解决业务问题的服务，让业务可以不用关注内部细节，直接使用就行。就像插线板，我们根本不用关注其内部电路逻辑，通上电就可以供各类电器使用了（这么看，插线板就天然具备中台化属性）。

3）能力输出：这是中台服务的表现层，根据业务需求组装完成的服务工具，业务可以直接拿来使用，表现层可以是接口、消息、页面等多种形式。

其中，中台的加工过程可以分为两种形态：能力合并和能力拆分：

1. 能力合并。将多个分散的能力聚合到一起提供完整的解决方案，供业务调用。
2. 能力拆分。将一个大的能力进行拆分，拆解成一个个可以独立运作的服务单元，供业务调用。

▲中台能力合并与能力拆分

举个例子：X公司底层有多套仓储系统和多套配送系统，通过中台化能力加工以后，将所有的仓储系统抽象为标准的仓储能力输出，将配送系统抽象为标准的配送能力输出，同时将仓储和配送能力合并后输出仓+配能力，这便为业务输出了3种供应链中台能力：仓储能力、配送能力和仓+配能力，如图所示。

至于底层有多少套具体的仓储系统和配送系统，逻辑有多复杂，业务同学完全无感知。

▲仓配中台化示例

六、中台的拆合之道

最后，我们再来思考一下文章开始的那个问题，你看那中台建了又拆，拆了又建，那它到底有没有用？

关于中台的好坏，并不能一概而论，因为时不同，势不同。天下大势，分久必合，合久必分，无论是拆中台还是合中台，站在业务发展的视角，都是带着责任和使命的。

我们再看一个故事。

X公司刚成立时，只有一个自营业务，所有系统和流程都是围绕这个业务展开，但随着公司的逐渐壮大，开始在天猫、京东等多个平台开店，并且紧跟潮流玩起了线上+线下的新零售模式。

各方业务有各自的供应链诉求，前期都依附在已有的一套供应链后台系统中，但随着各方需求积压到一定的程度，这套后台系统无法再独立的支撑所有业务的个性化需求时，供应链中台就产生了，它的使命是解决各方业务的供应链复用性和业务个性化问题，与此同时，交易中台、支付中台、财务中台，基本都是以这种姿态出现的。

随着中台的打磨成型，逐渐完善，给了业务更多的赋能，让业务尝到更多甜头，业务也更加愿意接入中台和信任中台，这个阶段是业务与中台合作的蜜月期，家庭和睦、万事亨通。

随着业务继续快速奔跑，到了下一个阶段以后，现有中台的发展能力遇到瓶颈，无法再很好地匹配灵活变化的业务需求时，就到了拆分的那一天了。

这个时候，当前中台的使命已经完成，需要将更多的能力下放给业务团队，由各业务自行解决复杂度和复用性的问题。于是，业务现状又变成了各业务自己处理自己的供应链需求，仿佛回到了公司刚成立时一样，一个新的周期开始了……

▲中台的发展路线

在我看来，中台被拆分以后，并不意味着消失和废弃，而是将能量化为另一种形式来更好的支撑业务，它的思想和理念必将深入到新的业务周期里，为它的再次出现而孕育着。

所以，单纯的以拆和合来评判中台好坏并没有意义，存在即合理，可以肯定的是，中台一定是有用的，但我们不能盲目迷信，因为它并不是万能的，而且是有周期的，它的出现和拆分都是业务发展的必然结果，我们应该理性的看待，以平常心处之。

#专栏作者#

木笔，产品一俗生，深耕于供应链领域，微信公众号：供应链产品笔记

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

题图来自Pexels，基于CC0协议