你好，我是徐昊。今天我们开始学习如何使用 8X Flow 建模中台系统。

在过去的几年里，有一种被称作中台的软件平台，在互联网公司中流行起来。而随着互联巨头们不停地将他们的成功与中台关联起来，越来越多的企业开始投资到中台的建设中来。

我曾见到过通过中台走向成功的企业，也同样遇到过在中台中反复挣扎的客户。那么到底什么是中台？在建模中台系统时，到底难在什么地方呢？这正是我们今天要讨论的内容。

中台到底服务了谁？

中台之所以是一个让人感到困惑的概念，主要是因为中台所服务的“前台”，并不是我们通常意义上理解的“前台”。一般当我们谈论起前台的时候，所描述的是一个软件系统。但是在大多数描述中台的上下文中，“前台”更多地指代一个具有自主性的团队，而不是承载这个团队业务的软件。

前台通常具有完备的研发与运营能力，而不同的前台则会关注不同的市场或业务。可能是在容量巨大的中国市场中，沿不同城市线级划分出的独立运营的片区；也可能是在同一城市内，不同领域下的不同产品。

比如，以某某出行为例，延不同城市划分的可能是北京的专车、上海的专车、苏州的专车这样的团队。而根据不同领域划分出来的则可能是北京的专车、北京的出租车、北京的顺风车等等。

显而易见，北京的专车和上海的专车是由不同的团队负责运营的。那么北京的专车团队在日常运营中所需要的软件系统，和上海专车团队在日常运营中所需要的软件系统会完全一样吗？可能主体的逻辑是相同的，但某些细节上可能存在差异，比如因地域原因需要集成不同的系统等等。

同样，北京的专车和北京的出租车也是由不同的团队负责运营的。那么北京的专车团队在日常运营中所需要的软件系统，和北京的出租车团队在日常运营中所需要的软件系统会完全一样吗？很可能主体的逻辑也是相同，毕竟都是出行请求和运载能力的撮合与匹配。但是某些重要组件上可能存在差异，比如对于运力的管理部分。

所以当我们明白前台指代的是这样不同的团队时，就会发现，这些团队对于软件有着高度相似但又不同的需求。他们要求高效重用，以满足业务快速扩张的需要（比如进入新的城市，或者扩展新的品类），但同时又需要高度自主自治（比如北京和苏州不同的业务环境，需要有足够的灵活性和自主性），以满足各自的需求。那么中台，就是能够满足前台对于复用和自主诉求的软件系统。

如果回到中台最开始的倡导者——阿里巴巴的“大中台小前台”战略，以及这个战略背后那令人心驰神往的 Supercell 之旅，我们或许能够更好地看明白中台是什么：一个用以支撑多个小而灵活的前台团队的软件平台。

  1. 小，首先指人员构成，无需沉重的研发能力；其次指试错成本，因小而低。
  2. 灵活，第一指对市场的响应速度；第二指流程敏捷，可以快速失败。

说句题外话，中台的首倡者，那位亿万异姓者们共同的父亲，并不是一个技术人员。怹（tān）不太可能想到用一种软件平台架构去服务不同的前台软件。更有可能的，怹看到的是一种服务于不同业务团队的业务运营模式。怹认为应对未来商业社会的一种可能的更具竞争力的模式，是通过小而灵活的前台团队，频繁而低成本地试错。而支撑这种团队结构的软件平台，就是中台。

以此为出发点，我们要去理解某一公司的中台，就需要从业务环境、组织结构、人力构成和技术架构这几个方面，去理解“高响应”“小而灵活”等概念在组织内的具体定义是什么。

而由于每个组织所处的外部竞争环境、内部组织环境、技术积累不同，每家中台的起点和目标也很可能完全不同。所以脱离这些环境去讨论中台，也就变得毫无意义起来。

所幸的是，所有这一切最终都要落脚回一个软件平台。因为再美好的构想如果无法通过软件平台去支撑，也就无法在大范围内去应用。因而我们可以从软件平台的特点出发，去寻找适用于中台的业务模式和团队结构。

效能与创新的平衡

不同于应用，软件平台是一类特殊的软件。它很少被最终用户直接使用，通常会被集成在应用之内，或是被多个应用共享。

比如操作系统就是一种最常见的软件平台。无论是台式机的 macOS、Windows，还是移动端的 iOS、Android，用户最终都不会直接去使用平台本身，而是通过不同的应用来利用平台提供的能力。

正是由于软件平台在构造之初就独立于各种“应用”，而在实际发挥作用的时候，又需要与应用整合。因此，软件平台从一开始就要平衡“效能的下限”和“创新的上限”，亦或者从更技术的角度上，我们可以称作“平台能力”（Platform Capability）和“应用自主度”（Application Automony）。

一方面，平台能力是平台提供的功能和机制。应用可直接整合某个功能，或提供某个机制去实现特定的能力。比如在手机平台上，应用可以直接打开摄像头去完成一系列的功能。也可以通过消息机制，完成不同种类的推送。这都是对平台能力的应用。

显然，平台能力越丰富，应用可以利用的也就越多，去完成某类功能的成本也就越低，因而平台能力通常被看作效能的下限。

但从另一方面来讲，平台能力又会限制应用去实现某种功能的方式。仍然回到刚才的例子里，如果应用希望实现完全不一样的通知方式，那么可能就是不被允许的，或许需要极其高昂的成本去绕过平台能力。可以说，应用利用平台能力获得的效能，是通过放弃一部分自主性来获取的，而低自主性，就会影响创新的可能。所以，应用自主度就被看作创新的上限。

说到底，软件平台需要根据平台用户对效能和创新的需求，来平衡平台能力和应用自主度。比如像操作系统、技术中间件，就是典型的高自主度平台，平台无法框定平台用户所需要的功能与场景，因而都尽可能地释放应用自主度作为平台的主要设计思路。

而数据库、搜索引擎则是高效能软件平台的代表，应用为了获得平台能力，甚至要使用特定的语言、协议与平台交互。不过高效能平台走到极致，就会出现可定制 SaaS 这种低代码环境。用户会为了获得大量的平台能力，放弃自主性。

触发了阿里巴巴中台思考的游戏引擎就是一种软件平台。游戏的核心玩法不同，因而平台需要相当的自主度。不过考虑到网络游戏的大场景，很多特定的模式又可以重复。可以说，它既不是一个纯粹的技术平台，也不完全是复用特定业务的平台。这种特性，也被后来的互联网公司制作的中台保留了。

互联网的中台

通过公开的资料与文档，我们颇能管窥阿里中台的面貌。阿里中台是基于一组共享服务完成构建的，这组共享服务包含类商品、品类、用户等模块。

在形成中台之前，这组共享服务已经被淘宝、天猫和 1688 共用。那么无论我们如何称呼这组共享服务——SOA 或者是微服务——它们实际上代表了阿里的基础业务能力。而重新组合这些基础能力，就可以支撑三个不同前台的业务的需求。

共享服务的形式给予了前台相当的自主度，而基于这组共享服务构造的中台，则为前台提供了更高的效能。

简单思考一下淘宝、天猫和 1688，这三个前台在业务上有很大的差异：个人卖家卖给个人消费者、商户卖给个人消费者、商户卖给其他商户。但其中也存在有类似的场景：订单履约、客户关系管理等等。很明显，业务的差异，使得这些场景中的具体流程并不完全相同，可是模式却十分类似。

那么我们可以说，模式的复用能够带来更高的效能，同时也能避免流程复用对前台自主度的影响，因而阿里中台通过将后台能力的复用转化为对场景中模式的复用，提高了平台效能。

类似的，另一个电商巨头京东也早早开始了中台的建设。在中台的设计上，同样是将核心业务模式中的业务能力从前台分离，并将这部分基础能力下沉到中台，并且提出了业务能力“积木化”的概念。那么通过对核心业务模式的抽象分离与下沉，京东的全域交易中台慢慢浮现出来。通过核心业务模式的复用，有效地支撑了线上线下、实物虚拟、2B2C2M 等各种形态的无界零售场景。

如果说阿里巴巴和京东都是典型的交易场景下对核心交易业务模式的复用的话，那么滴滴就是一个典型的出行场景下对出行业务模式的提取和复用的例子。

滴滴通过构建出行中台，将不同业务类型的出行业务，例如出租车、专车、快车等背后通用的出行业务模式，与具体业务进行了分离，并通过插件化、配置化等方式，实现了核心业务模式与前台具体业务的适配。

可以看到，通过构建出行中台，一个基于出行业务模式的新的业务模式诞生的速度被大大加快。从出租车业务到专车的业务上线，前后经历了 2 年的时间。但是从快车到顺风车的上线，只用了 1 个月的时间。业务模式的复用在业务快速扩展过程中展现出了极大的威力。

在上面的几个例子中，你可以看到大量 SaaS（Software as a Serivce）的影子，无论是淘宝、天猫和 1688，还是滴滴的出租车、专车、快车，是不是都可以看做某个 SaaS 平台的不同租户呢？从这个角度看，中台和 Saas 模式又有什么区别呢？

中台与 SaaS 的区别有这么两点。第一，SaaS 通常是从前端到后台的全部系统。

比如淘宝自己就是一个 SaaS 系统，我们在淘宝上开店的时候，享受的是从用户渠道、产品目录到库存管理等全部的组件和模块。而且我们还可以有自己的域名，让用户可以直接访问我们的店铺。所以从某种程度上来说，我们可以让我们的店铺看起来和平台没什么关系，作为完全独立的应用存在。

但是对于中台来说并不是这样的。我们还是以滴滴出行为例，当不同的前台团队从这个 SaaS 中开通自己的租户时，并不会出现新的出行 App，而是会在统一的主 App 中增加对应的功能，比如根据城市不同，将对应的前台团队（北京出租、北京专车等等）的服务汇总到 App 中。

那么当新的前台团队出现时，我们只是在后端增加了系统与服务，以支持新团队的运营需求，并不会新增一个完全不同的渠道与入口。如下图所示：

但如果将中台看做 SaaS 的话，那么这个 SaaS 只有后端部分。所以严格意义来说，中台的模式更接近“后端即服务”（BaaS，Backend as a Service），而不是 SaaS。

这也很好地解释了中台的“中”是怎么回事。**它既没有扩展前端，也不仅仅是简单套用后台系统，而是在已经存在的前端和后台之间，构成一套软件，以支撑前台团队的运营模式。**那么支持这种操作的平台，自然应该叫中台。

第二，中台与 SaaS 的定制化程度不同。还是拿滴滴出行来说，虽然从模式上看，无论是出租车、网约车还是专车，它们的模式都是需求跟资源的匹配。也就是乘客提出出行需求，而平台呢，根据一定的规则，从可用的资源中寻找最佳资源匹配给乘客。但是具体到运营上，差别还是非常大的。

比如派单还是抢单？积分还是考评？在不同的产品形态中，由于对资源的控制力不同，运营方式与方法也就千差万别了。就算我们硬要说中台是 SaaS 的话，那么它可能更接近一个产生 SaaS 的 SaaS，而不是直接服务于租户的 SaaS。

所以如果从这个角度理解中台的话，**那么其实不是前台团队直接使用了中台，而是使用了中台的产物：针对某种业态后台系统的 SaaS。**如下图所示：

可以看到，虽然中台与 SaaS 模式存在差异，但是我们仍能感受到它们在模式上的相似：也就是对于某种能力的复制。

我们在第 14 讲提到过，SaaS 模式是典型的复制运营模式（Replication），那么中台到底在复制什么呢？这歌时候，我们就需要看一下中台里，最适合的效能与自主性的平衡点到底在哪里。

宏流程——场景下的业务模式

如前所述，阿里、京东和滴滴中台都将效能与自主性的平衡点放置在“特定场景中的业务模式”，在保障了效能的基础上，给予前台更大的灵活性。而这种灵活性与效能的平衡，就造就了我们梦寐以求的互联网创新速度的奇迹。于是，我们称这种“特定场景中的业务模式”为宏流程。

宏流程兼具业务与技术上的含义。从业务上讲，顾名思义，宏流程是一种“宏观的流程”，它体现的不是某一个前台业务具体的业务流程，而是通过把多个类似业务模式的前台抽象过后，所提炼出的共有的底层“核心业务模式”。例如阿里巴巴、京东交易中台承载的交易业务模型，以及滴滴出行中台承载的出行业务模型。

从技术上讲，宏流程不能被前台直接使用，往往需要通过基于具体的前台业务进行配置点配置与扩展点定义之后，才能实例化，成为某个前台具体的业务流程。并且这个实例化的过程非常快速，甚至可以由前台业务人员直接通过配置台独立完成。这是宏流程技术性的一面，它是前台业务流程的模板——宏的另一个广为人知的含义。而宏流程实例化的过程，也就是我们前面讲的 SaaS 化 SaaS 的过程。

宏流程促进了从业务层面上模式的复用，也给创新带来了不同的思考。那就是如何复用已经存在并成功的业务模式，是一种更有效的创新方法。虽然这种创新方式有个不好听的名字，叫“copycat 创新”，也被戏称为“Uber for XXX”，即：将广为人知的 Uber 模式应用到不同的细分市场上去，使之成为一种新的服务。但如果被复用的模式本身就存在于企业内，那么就另当别论了。

说到底，不停地将企业成功的核心模式灌注到新的市场，让企业在扩展业务版图的同时，也能不断强化核心竞争力。这是绝大多数企业长久以来期盼的发展创新的模式。注意，不是重复，而是在不同的竞争领域复现。这是宏流程带来的思考方式的转变，也是承载宏流程的软件平台——中台让我们着迷的地方。

小结

从某种意义上来说，中台已经走过了一个技术大词（buzzword）的全生命周期：从几年前的甚嚣尘上，一众企业寄希望于通过构建中台，追赶互联网研发模式。到最近拆中台成风，好像中台马上就要被收进历史的垃圾桶了。

然而也是历史告诉我们，当我们被技术大词狂热鼓舞的时候，心里得清楚，真正希望了解这个技术的人并不多，要么应激怕掉队，要么投机想上位。只有浪潮退去，我们才能真正静下心来看看它是什么，以及怎么做。

我个人认为中台是一种源自中国市场的、特有的、基于云平台的平台架构模式，并且它的出发点完全不是技术基建，而是寻找更好的组织结构和技术架构，以支持业务快速增长和发展。

所以哪怕一时受挫，但其中闪闪发光的思考，也会不断拓展我们的认知和视野。所以哪怕今天拆中台成风，但我们还是需要学习怎么才能构造真正的中台。它肯定还是要回来的，毕竟还是很有价值的技术！

思考题

根据你所学到的建模方法，你会怎样建模宏流程？

很期待你能把自己的思考和想法分享在留言区，我会和你交流。我们下节课再见！