对笔者来说，由于公司的业务与产品特性，做中台很有必要。于是在中台实践之下，笔者为我们总结分享了如何建设业务中台。

这个冬天，风格外的冷，让人不寒而栗；产品经理，一种求生欲特别强的生物，不仅要考虑如何让自己度过寒冬腊月，也要帮着老板降本增效，度过这个互联网寒冬。而中台或许就成了一个不错的选择。

一、为什么要选择中台？

我负责的产品是一个订单调度管理平台，这个平台涵盖了计划、商品、订单、审批、执行和单据生命周期管理等模块，是一个产品线交织、模块冗合在一起的运营管理产品，还有各种各样的配置、规则等。

面对新业务的产生和变化调整，超出了现有产品的承载服务能力。

产品线多，产品逻辑各异，对于一个产品来讲，很难全局掌握——如果一个产品需要调整优化， 容易产生产品遗漏或者产品设计漏洞，导致生产问题。

另外，对开发测试来讲，通用的产品方案因为新业务的产生而重复性开发测试，不仅开发资源浪费严重，也会造成后期产品的运营维护压力大增。

因此，业务场景随着发展越来越多，堆砌式开发建设，产品管理越来越臃肿。

因此，优化订单管理平台结构，创新产品管理方式，迫在眉睫！

这时候，我们就会慢慢思考，我们要将订单调度管理平台做成什么样子呢？我们设定了几个大的方向：

• 能力沉淀：将过去几年来积累下的订单调度能力沉淀下来，能够支持多场景、高并发订单服务；
• 快速响应：针对越来越快的业务发展速度，能够提供现有逻辑的服用能力，快速响应新业务的需求，同时减少单据间的冲突；
• 稳定输出：提升订单服务稳定性，支持多种创单形式、提供统一创单服务接入规范，降低团队协作和系统交互成本；
• 模块化管理：针对订单管理周边服务，进行模块化管理，并支持快速迭代调整，局部调整尽可能少的影响整体产品功能。

中台解决方案就慢慢进入了我们产品的视野，中台是啥呢？简单来讲就是企业级能力复用平台，专业一点，就是一套结合互联网技术和行业特性，将企业核心能力以共享服务中心进行沉淀，形成“大中台、小前台“的组织和业务机制，供企业快速低成本的进行业务创新的企业架构。

那我们为什么要选择中台呢？

资本角度：

自从2018年以来，虽然互联网投资资本趋势不减，但投资热度有所收敛，不再盲目“追风”,资金流向更加理性和集中。

资本主要是向头部聚拢，部分尾部创业企业甚至没有获得任何新投资。

资本是逐利的，整体经济形势不是很好的情况下，可以用的钱少了，钱也不那么好赚了，也更容易花掉了；就要省吃俭用，从各个成本中心降低成本，想办法节约开发、人力和产品成本，甚至从员工福利下手，出国游变成了“新马泰（新街口、马群、泰冯路）一日游”。

不过，产品层面的中台架构，因为能够对人均效能的显著改进而受科技企业追捧。

规划调整：

公司的规模发展到一定程度，现有传统的系统架构肯定无法支撑业务的体量和复杂程度，为了新业务，而不断的调整企业级系统，不稳定的系统会造成系统的巨大使用风险，如何保证系统的稳定可用，是一个产品要思考的问题。

另外，业务发展很宽广的时候，也要考虑产品的另一个问题，就是如何让产品进行能力的积淀和输出，通过有效的产品管理和设计，让平台的各种能力（功能/产品）能够快速复用、快速组合，支持业务更快捷的探索和发展；

研发模式：

互联网前十年，企业快速发展，不计成本的堆积互联网产品和系统开发资源，烟囱建设了不少，而近两年，这种研发方式针对的业务价值和收益却寥寥无几——有些产品线花了很大的成本建设起来，业务却塌了，导致开发资源的极度浪费。

比如产品部门几十个开发，每年（只能）做几百多个需求，研发差不多每天都要加班到晚上9点左右，作为产品经理一年要开几百个会，每天18:00之后才能正经写写文档做做产品设计，和研发的下班时间差不多。

但是即便大家这么努力，产品部门的需求周期依然是特别长，整天被业务线投诉，一年下来，还没做出太多创新的成果，对新业务的响应速度还是很慢。

因此，中台架构摆脱了”烟囱式“系统建设方式所带来的种种发展桎梏，通过统一的公共技术模块抽离形成服务。再次需要该服务时通过接口调用完成，避免重复造轮子，避免研发周期拉长。

技术冲突：

还有烟囱式建立起来的产品，如果一个企业的业态较多，场景较为复杂，企业中后台产品往往并不能很好的支撑前台快速创新响应用户的需求，后台更多的是在解决企业管理效率问题，而中台才能很好的解决前台的创新问题。

大多数企业虽然已有的后台，但是要么前台根本就用不，要么不好用，要么变更速度跟不上前台的节奏，前台求变和新，中台求稳和定，依赖现有的产品架构，好像并不能很好的解决这个问题。

因此，企业有必要尽力搭建稳定可靠的中台系统，⼜要有前台系统，能够⼩而美，快速迭代。

业务发展：

这两年业务快速创新发展，业务场景越来越复杂，短平快的业务创新，不断的犯错就是节约成本。

这里不得不提supercell公司——以 2 到 5 个员工、最多不超过 7 个员工组成独立的开发团队就可以进入新游戏的开发，投入市场看看游戏是否受用户欢迎——如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，以最小资源进行不断的创新试错，却是对公司资源最大的节约，有了中台，就可以支撑他们这样去做；

时代变了：

另外就是，随着用户增长红利逐步消失，互联网市场趋于饱和，市场开始进入挖掘存量用户的阶段。用户对应用的选择变得更理性，互联网产品也从野蛮生长变成了精细化运营——

过去躺在树下摘果子的日子将一去不复返；产品也不是随便开发几个系统就能躺赢，必须精雕细琢产品方案，让产品的成本一步步压缩，却还得承担更多的职责，也就是马儿吃的少，还得干的好，干得多。

二、怎么做中台？

面对一个订单调度管理平台，现在他是一个整体，基本上没有前后台之分，一条产品线从单据开始到单据结束，由一个产品经理负责，看似产品线十分清晰，这也是在保持现有规模下比较完美，可扩展性很差，如果我们切分了前中后台，哪些产品是前台，哪些产品是中台呢？而我们的中台又是什么性质的中台呢？

从产品线来看，大概分为几条产品线：采购线、退货线、调拨线几条。

就拿采购为例，采购的需求计划、采购单据创建、采购执行作业到采购单据完结，从页面设计、订单管理逻辑到作业执行逻辑，从用户体验、人机交互到单据跟踪预警，只要是采购相关的东西都是一个产品经理负责，这算是产品线责任制，在业务逻辑简单，场景较为单一的情况下，此方案非常好用。

不过，随着业务的发展，各种各样的小产品（预售采购、生鲜采购、门店采购）出现，因为小产品的差异，而去改动一条产品线的各个入口，导致牵一发而动全身，从头改到尾，产品经理每接到一个新业务需求，可谓是苦不堪言，若是换成了一个新产品经理，丢三落四的产品方案，漏洞百出。

另外，每个产品线都会涉及用户操作页面，不同的产品经理因为风格不一样，设计出来的产品功能也会不一样，同一平台下不同的模块带给使用者的用户体验也是不同的，经常会出现业务提需求：A产品经理，你做的跟B产品经理设计的页面一样就好了。多么尴尬的需求呀！

从现有架构来看，订单调度管理平台的产品线管理是纵向剖析的，按照产品线模块去划分的，那切分了前中后台，我们要换成什么结构模块切割呢？

对于中台，现在市面上有好几种类型的中台：数据中台、业务中台、组织中台、技术中台，从产品设计及使用来看，订单调度管理平台本身是业务系统，对现有的业务需求实现信息化管理，因此，我们搭建的应该属于业务中台，即：

基于抽象复用、架构合理性和业务统一管理的视角，通过适度的业务逻辑抽象、弹性的复用功能设计，将产品管理方案进行抽象、复用和下沉，打造企业级功能服用平台。

切分前中后台

下一个问题就我们该怎么切分了，粗略统计了一下，我们大概有以下好几种设想：

• 按照技术系统结构切分前中后台；
• 按照页面与逻辑切分前中后台：
• 按照需求申请与订单调度切分前中后台：
• 按照业务场景和通用执行切分前中后台：

刚开始接触前中后台，前台的印象停留在前端的概念，那不就是页面和后台逻辑的区分嘛。

因此，我们团队进行了拆分，一个团队负责页面，与页面相关的都归属于前台产品负责，那么后台复杂的业务逻辑就是由中台负责，这样划分下来，立马矛盾就凸显出来了——

做一个业务需求，页面的前台产品画，逻辑中台产品写，前台产品不就是UI体验部了嘛。

对接同一个需求，业务被搞蒙了，产品也被搞蒙了，本来一个产品可以搞定的产品方案，结果投入了两三个人力资源，不仅不省力，还浪费资源。

因此，这样做肯定不行！

后来和技术交流后，在深入探索一下，能否按照技术系统切分去做呢？

订单调度系统有两个技术系统，A系统大概负责预测计划，B系统负责单据执行。

这样下来，前台产品负责A系统，中台产品负责B系统，这样做起产品需求是好一些。

不过怪怪的，前台产品有些需求要调整B系统的逻辑，中台产品有时候也会联动A系统，因此，产品矛盾解决了，技术矛盾越发凸显，也不是很好。

在后面又有了新的变化，因为A系统大概负责预测计划，B系统负责单据执行，那我们就按照产品类型来切分，需求端不管页面还是逻辑都是由前端产品负责，那单据执行，不管是页面还是逻辑都是由中台产品负责，这样下来，也解决了技术矛盾。

不过由我看来，这样也不是很好——并不能解决业务快速发展与系统响应较慢的矛盾问题和资源重复浪费的问题。

随着对中台的深入体会和架构师的沟通学习，逐渐对中台有了更深层次的意识和了解——

前台是一个个业务的小场景，那中台通过调度各个资源服务于前台部门，为前台业务服务；中台要做的是抽象、沉淀和整合后台资源，包装成便于前台使用的可复用、可共享的核心能力，实现后台资源到前台易用能力的简化。

其实在这个过程中，分析了现有的业务场景，针对现有的零售场景，有商超、便利店、高端店以及门店和中心仓下的各种商业场景（预售、无人货架、新鲜到家），规模不是很大。

而且公司处于探索时期，针对一种商业模式，比如说便当模式，可能要短短一个月内要上线试点，然后过了半个月，效益不好，模式试验失败，又会迅速止损下线。

要是按照传统的模式，那我们可能就是改了整套产品系统来适配这样商业模式的运作，这样的风险很大而且成本很高，因此前中后台不分家的产品管理并不能很好的支撑前台快速创新响应业务场景的需求；

慢慢的，经过切分的阵痛期和前台中台的磨合，我理解的中台慢慢清晰了起来，企业级产品管理既要求稳定，又要求快速应变，稳定和应变本来就是相悖的两件事，那中台就是这种矛盾的变速箱，将前台（车轮）与后台（发动机）的速率矛盾匹配起来，达到最佳的传动比，提升发动机的效率，降低油耗、

因此，我们的切分不是简单的系统、页面还有单据类型的区分，变成了业务小场景和抽象能力沉淀的划分，小场景中也有通用的逻辑，那我们就把它在产品管理中沉淀到中台去进行资源整合包装提供稳定的输出，转化为前台友好可重用的核心能力，我们的前台就是各类小产品场景下的前端系统，他们就像一个个用户触点，是企业与用户最直接的接触。

小场景产品快速迭代上线，中台则不断的抽象、沉淀，解决了前台与后台失速的问题，以此帮助企业不断提升用户响应。

三、我们做了哪些事？

从业务抽象到领域建模，再到架构设计，一步步搭建起订单调度管理系统的中台产品管理模式；作为中台产品，从0到1的中台建设，从骨子里都要保持中台思维，我们做了以下几件事：

业务抽象

梳理现有业务现状，将各类场景入口、单据管理和单据信息流进行对比分析，设计业务蓝图和抽象业务元素，隐藏业务细节，将业务对象进行抽象化。

中台产品在抽象化的过程中，就是做建模工程图一样，一会我要缩小公工程图看看整个房子好不好看，俯瞰全貌看看整体效果是不是在控制之中，一会我还得放大，深入局部看细节有没有画到位，看看每个细节的房屋结构是否合理。

因此，业务抽象化一定要站在一定产品架构高度，把控和规划好产品管理。落在产品功能设计，够设计易用的功能和优秀的交互体验。

中台核心产品模块规划

经过业务的调研和分析，基于上阶段输出的主题域，技术架构师按照中心的多个划分标准，进行产品模块的规划，从业务管理和产品管理的角度，总结出整体的架构设计，在覆盖现有所有业务场景基础上，整体产品架构具备易于扩展、组合，可支持动态伸缩、精准监控等目标。

抽象与整合实施，组建最小产品模块

产品功能设计是在产品模块规划设指导下，由上而下、由粗到细的抽象过程，主要是将业务抽象成果转化为产品管理方案(主要由业务场景、业务流程构成)，通过搭建最小产品模块，实现产品的模块化设计，业务能力输出就会像搭积木一样，将各个最小产品功能模块快速组合在一起，实现能力的输出。

确定了中台的整体思路后，产品经理就可以放开手脚，自主推动业务中台建设了。

产品管理切分交割

面对集合在一起的产品做前中后台拆分，在完成整体思路和细节设计后，就是产品管理的灰度切换和交割，这只是产出业务价值的开始。业务中台经过运营管理，不断沉淀和发展，循环往复，能力会逐步增强和扩展，模型会逐步调整和完善。

其实，中台方案解决了现有企业遇到的矛盾和问题，但是在实施过程中，中台也并不是完美的方案，这个过程中，也感受到了中台产品管理的弊端。

中台产品与业务渐行渐远

我做了四个月的中台搭建，最大的感触是离我们的业务人员交流的时间和频次明显降低了很多——基本上需求都是从前端产品而来，不断的梳理抽象逻辑和业务场景，根据对现有业务的理解不断的构建中台的框架。

但是这些产品管理的需求，没有业务能够深入理解，他们能做的就是我们现在的业务时什么，接下来要做什么，至于中台要怎么做，很大程度上看一个产品经理的理解和输出。

中台需求优先级不稳定

中台虽然隐藏在了前台业务场景后面，但是也会接受到业务的需求提报，但是对于业务优先级排期，我们有两大类需求：中台建设自提自解决需求和业务需求，但是每次资源排期，不确定因素会很大，可能因为业务需求紧急，而无法排期中台建设需求，导致错过了中台整合的最佳时期，后再进行变更调整，可能会用到更多的资源。

因此，中台需求很不稳定，但是我们毕竟是业务导向型产品平台，无法将两类需求提升到同一维度排定优先级，但是，中台产品一定要留点资源给一些中台基础建设。

前期建设资源占用较大，短期无明显业务价值产出

针对订单调度管理平台，初期进行中台建设，每一个需求都要占用到两个月的人天资源，整个改造下来，基本上可以做几十个大项目了，因为无业务价值产出，业务同事也无法理解，资源占用较大，受到了很大的抵触，产品经理一定要扛得住压力，量化价值指标，中台的价值效益会随着公司的发展慢慢展现出来；

四、中台经验总结

我觉得中台产品应该这么干，“任凭弱水三千，我只取一瓢饮”，虽然有弱水三千，中台产品经理眼里有一瓢水即可，对于中台产品的旧词新解，我觉得还蛮合适的，总结一下自己的经验与大家分享探讨：

中台产品一定要保留力量始终去做一些基础的、重要不紧急的事情

由于互联网公司多年来信奉的就是「唯快不破」，团队在做优先级排序时，往往会倾向于去做业务价值最明显的事情，有很多重要不紧急的工作就被压在后面，永远没有再被提起过。

但对中台产品团队需要有不同的要求——中台产品一定要保留力量始终去做一些基础的、重要不紧急的事情。

很多企业的信息建设部门停留在业务支持的程度，看起来好像甲方乙方一样，作为业务导向型产品部门，业务提出当前的业务需求，以项目制管理产品工作，业务对系统的整体架构不会过多考虑，完成了一个烟囱式项目，即项目结束，又投入了另一个项目中。

作为中台产品经理，不仅要考虑业务提出的需求，还要在项目过程中，不断的整合基础产品管理，借项目之力，一点点完善中台建设；

明显共性的功能模块尽早抽象落地

订单管理调度平台属于B端产品，很多形态的产品是具备明显共性的，可以尽早的进行抽象设计。

这样在系统架构建设的初期，就能做出正确的设计方案，不会增加太多多少研发工作量，未来还会让系统扩展更加轻松。如果建设到一定程度的平台，在进行拆分前中后台，对横踢架构调整，的确要花费很大的力气。

适度的业务逻辑抽象，不要过于多的考虑未来

中台产品设计初期，没有必要为未来不确定的事情提前做过多的布局，适度的业务逻辑抽象、弹性的复用功能设计即可，因为很有可能未来根本用不到，却会产生过度设计，造成开发资源的浪费，甚至也会让系统架构看起来非常奇怪。

业务价值和诉求导向系统抽象迭代

没有明确的收益和价值，强行采用中台理念设计，会造成业务的困惑和恐慌，可能会造成业务正常工作的不良影响，在初期阶段，可以容忍一定程度的不合理，但是中台的产品管理一定是体现了业务诉求，能够量化业务价值，才能得到业务方的支持，顺利的进行系统的抽象迭代功能。

通过这段时间的中台架构切分和搭建，希望能给企业发一张“免裁劵”，在互联网寒冬中，安稳的度过这段艰难的日子……

本文由 @产品包工头 原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议