目录：

　　一、问题：业务有经营指标，中台有没有？

　　二、解法：起点看用户，过程看机制，结果看系统

　　1、起点，看用户。

　　1）业务方用户：用户描述、核心诉求、交付特点、衡量指标、建设导向、需求来源

　　2）公司内产品/研发/运营用户：同上

　　3）外部用户（C、B终端用户）：同上

　　4）团队内部产研用户：同上

　　2、过程，看机制。

　　1）项目维度的交付

　　2）需求维度的交付

　　A. 横向机制：中台平台化建设

　　B. 纵向机制：垂直能力域

　　C. 横向与纵向协同：双向牵引

　　3、结果，看系统。

　　1）系统的分类

　　2）中台的指标

　　一、问题：业务有经营指标，中台有没有？

　　之前在参加OKR汇报会时候，发现一个非常明显的现象。

　　前台业务团队的OKR，几乎都每一条都有可量化的指标。

　　例如：

　　订单业务部门，有单量、GMV、营收、NPS等指标；

　　金融、商业等营收部门，有收入指标；

　　就算履约，也有各种人效、产能、满意度等指标；

　　有指标，就代表你的OKR结构和你日常做事情的框架基本上是稳定的。

　　你需要做的就是不断让指标变得更好。

　　另外，就是除了指标之外，业务部门和履约部门，还有一个特点，就是他们都会一个集中服务的用户，这个用户可能是C、可能是B、也可能是作业人员（例如客服、仓配等）。

　　过程中，大家会对用户保持高度聚焦，并不断研究如何服务得更好。

　　那中台呢？

　　我在写OKR的时候，其实就很少能具备以上2个属性来拆解。

　　我用的最多的框架，就是分为【业务重点项目支持】、【口碑体验】、【中台内部建设】、【团队】，大概逻辑就是按照我服务的用户来划分的。

　　我可以讲解每个事情的逻辑闭环，但是从汇报效果来看，大家可能还是觉得我们在搞一个个项目，没有一条主线。

　　在日常工作中，其实也不止一次被童鞋问起以下问题：

　　例如：

　　中台面向的用户是多样化的，有时候跨度很大。那这些用户的关系是怎么样的？

　　中台大部分时间，是在做一个个项目的交付。这样做只是简单的资源换输出么？

　　中台提供了一个个不太可视化的“能力”，还有一些工具、页面。那中台的“产品”到底是什么？

　　那么，用户、项目、能力这些词汇，我们又该以一个什么样的框架来理解它们之间的关系呢？

　　而做中台，又如何从这些东西里面找到所谓的主线呢？

　　接下来，我用中台规划一张图来尝试回答下这个问题。

　　二、解法：起点看用户，过程看机制，结果看系统

　　上图，我从用户分类（起点）出发，到需求和交付实现（过程），到产品沉淀（结果），做了环节的拆解。

　　接下来，我们就分别从3个环节详细看下：

　　1、起点，看用户。

　　——洞察用户需求，才能知道我们努力方向，才有规划和路线。

　　中台的用户其实是比较多元的，每一种用户的诉求和建设路线可能不太相同，所以我们需要分类来看。

　　当前转转中台的建设思路下，我把用户大概分为4类：

　　1）业务方用户：

　　用户描述：即上游业务，对中台提需求，实现特定业务模式和能力的用户，也是最大最高优先级的用户。

　　核心诉求：能力。中台项目化结果输出的能力，和业务做的功能，一起构成了服务上游终端用户的产品形态。

　　交付特点：项目化。因为业务上游有表现层，中台更多是能力层，所以中台交付是以项目为颗粒度一次次交付。

　　衡量指标：A-业务感受，要让业务感受到中台支持的专业度和协作顺畅程度；B-项目质量，要尽可能保障项目的功能可用性、易用性、不出bug等；C-项目交付效率，中台比较复杂，涉及面也比较广，业务希望交付是高效的、及时的。

　　建设导向：项目流程化、一揽子打包（系统化+解决方案专家）。项目化交付要想保证质量和效率，流程化是非常重要的一个环节（下边会讲到）；产品需求环节，更是中台架构最困难的点，因为要业务对中台产品域一对多，所以一揽子打包解决业务问题，不让业务多点沟通，就是中台的建设导向。

　　需求来源：需求自然来自于上游业务方。为了解决业务方众多、后置等问题，目前中台实现的是业务BP机制，主动跟进业务动态和需求的逻辑在跑，效果非常好。

　　2）公司内产品/研发/运营用户：

　　用户描述：即公司内部同学，在前台产品运行之前和过程中，这些用户需要通过后台产品做配置和管理操作。

　　核心诉求：提效。本质上产品形态为管理后台类型，核心就是操作效率。

　　交付特点：工具化。产品本身不涉及逻辑或逻辑已经确定，更多就是操作工具属性。

　　衡量指标：高效、易用。工具核心就是让操作用户能够非常有预期地便捷地完成对应操作，所以高效、易用性是工具化的核心指标。

　　建设导向：去人工、场景化。管理相关工具如果不完善，那对应的补位就是产品运营或研发的手动操作，而这个就会存在很多的遗漏、准确性、操作重复等问题，所以去人工系统化是要持续坚持的；而场景化，表达意思是说，我们在考虑工具设计时候，不要仅仅考虑功能已经实现界面操作，而应该考虑用户实现何种目的，然后将相关操作集成到一个场景（优先考虑线性流程引导、checklist检查引导）。

　　需求来源：内部建设，更多时候，会随着能力交付，作为配套内部产出。规划上，整体就是各类操作后台的终端，如**运营后台，**商户后台，**管理平台等等。

　　3）外部用户（C、B终端用户）：

　　用户描述：即外部用户，跟上游业务面对的用户是一个层级，分为C、B终端用户。因为中台很多场景下，也会封装提供终端产品服务于用户（通用性较强、与业务指标弱关联的产品功能）。例如交易支付领域的交易链路（购物车、下单、收银台、订单管理、钱包优惠券等）、商家后台（入驻、营销、对账、IM等）等。

　　核心诉求：价值&体验。因为要面向终端用户，一定是满足了用户某种价值的诉求。这里面用户对产品的使用可能代表着他权益的确认，例如交易、资金、货物的交割等。体验对终端产品来讲，也一定是要考虑的因素，一方面是因为代表平台产品的“面子”，另一方面体验不好，可能会影响到功能使用，也就可能影响到价值。

　　交付特点：产品化。不同于项目用户对于能力的诉求，也不同于内部用户对于工具的诉求，终端用户感知一定是产品化的，产品化代表着更高的交付标准。

　　衡量指标：稳定、易用。中台提供的终端产品，一般都是交易链路节点相关的功能。这些功能的稳定性应该要求是第一优先级的；而易用性呢，有则可能不一定加分，但没有则一定减分。

　　建设导向：体验也是功能的一部分。对于中台，无论项目、工具还是端产品，稳定性都是打底的要求，而体验恰恰更多是中台人“不擅长”的。而经过越来越多的case发现，有时候体验不好，会影响到正常的功能使用，轻则用户操作不便捷，重则引起很多不必要的客诉。

　　需求来源：终端用户调研和反馈。这些信息，被动通道我们会关注客服online信息，主动通道会主动调研和做用户体验。

　　4）团队内部产研用户：

　　用户描述：即中台自身的成员，包含产研同学。没错，我们应该把自己也当作用户来考虑，考虑下我们的痛点和诉求。

　　核心诉求：性能。这个性能其实是广义的，不仅是响应时长、QPS、可用性等技术指标，还包含中台体系在业务对接过程中的灵活性、扩展性，以及中台在业务维度的风险预警能力。

　　交付特点：专业化。中台体系内的交付，不是面向业务方、内部产品运营、终端用户，而是面向我们自己的未来发展。内部做得好与不好，其实短期内外部可能感知不到。但是我们一定要以最专业的标准要求自己，就像建设一条99%人看不到的下水道一样。不为给别人交付，只为我们的专业信仰。

　　衡量指标：稳定安全、扩展性。稳定安全，是一切中后台的基本要求；扩展性，对中台也应该是基本要求，如果做不到，那中台就会成为中枢的瓶颈，最终失去立身之本。

　　建设导向：风险意识、架构。每次跟老板汇报时候，老板总会提到一句话，说没问题找到中台时候，其实就代表你们做的很好，找你们时候准是出现什么大问题了。这句话就能看出，中台必须在天晴的时候修房顶，把风险意识提前落实准备。架构其实对应的是复杂解耦和灵活扩展，中台时刻面对多样本，抽象后再简化应用接入。

　　需求来源：中台内部调研分析和规划。自己的痛苦只有自己知道，上游用户关注不到我们。所以，周期性挖掘团队内部每个人的反馈、复盘每一个问题，就是我们规划的原素材。

　　PS：每家中台建设路线可能不太相同，不是标准，参考逻辑即可。

　　2、过程，看机制。

　　——用机制牵引“人”沉淀“系统”，再应用“系统”。

　　以上，4类用户，指标、建设方向，以及给他们提供的产品特性，我们都已经比较清晰了。

　　那从用户需求到产品，有起点，有结果，过程到底该怎么做呢？这个也是我们本文核心要探讨的问题。

　　交付，主要分为2个环节：需求交付环节与项目实现环节。

　　对应中台来讲，项目实现反而不是问题，但需求交付才是最棘手的。为什么？

　　在这里，我引用玄难在谈阿里业务中台建设历史上的一段话，让大家感受下：

　　我们日常在中台建设中，也确认能非常感同身受。

　　接下来，我们就分别聊聊项目和需求（下边篇幅重点聊这个环节）。

　　1）项目维度的交付：

　　基于项目角度，常规的开发实现环节没什么可聊的。

　　重点，我们关注两端：需求处理和收益复盘，建立对应机制。

　　需求立项分级机制，谨慎确定优先级，确保资源花在刀刃上。

　　度量收益复盘机制，针对过程中各环节协作问题，不断总结沉淀完善流程，并且check当初立项的收益是否达到。

　　PS：因为本文重点侧重于产品层面问题，项目角度暂不详述。

　　2）需求维度的交付：

　　接着上边聊阿里玄难提的那段话。

　　中台需求确定比较复杂，这个复杂分为横向和纵向。

　　先看横向，一个需求的实现，大概率会跨域进行拼装。

　　就拿我们业务中台来说，几乎所有的中大需求，都会包含以下产品域的review。

　　① 准备模块：用户、商户、商品、促销、服务

　　② 信息流模块：订单、逆向售后、仲裁

　　③ 资金流模块：支付、清结算、对账、财税合规

　　④ 实物流模块：履约、仓配、质检、退换修

　　⑤ 其他模块：风控、客服、数据统计

　　这么多产品域拼装起来，相关有关联，相关有影响。这个确实是一个复杂的事情。

　　再看纵向，每个产品域几乎都需要极强的专业积累，有的还需要行业积累（例如财务、物流、支付）。

　　所以，纵向对外提供一个能力，是需要非常多复杂问题的思考的，只不过外部感受不到。例如拿支付为例，收单、结算，这些从交易层感知，到支付层逻辑，再到账户层记账，最后还要考虑资金，牵一发而动全身。

　　那既然，横向和纵向都很复杂，那如何破解这个难题呢？

　　我的答案是：建立系统，应用系统。注意，这里的系统，不仅仅是产品系统，更多是系统化的意思。

　　那可能有人会问？这么复杂的东西，要变为系统要到猴年马月。

　　没错，建立和应用系统，永远在路上，就是我们本章节的主题：“过程，看机制”。

　　机制是什么？

　　机制就是牵引“人”将过去的问题、经验总结变为“系统”，而再牵引“人”去应用这些“系统”。不断打磨不断沉淀，逐渐将每个人的经验变为系统（流程、规范、标准、工具、结构化归档），而逐渐不依赖个人。

　　接下来，就分别围绕上边讲到的“横向”和“纵向”机制做些讲述。

　　A. 横向机制：中台平台化建设

　　大家都知道，中台会面向很多的业务模式。那在中台能力范畴，也会逐渐积累很多稳定模式的能力，也会去设计新的模式的能力。

　　我们先把横向需求分为2个大类，这两种应对起来方法是不同的。

　　便于后续理解，先对上图中的几个名词做下解释（这里只介绍作用，辅助大家理解本文，以后有单独文章来具体讲解系统设计和实践）：

　　① [系统]规则中心：每一个模式在中台全域（包含准备、信息流、资金流、实物流、其他）实现的所有逻辑和参数声明；你可以理解为产品需求规则文档，但是是经过高度结构化之后的（结构化就是产品域-角色-交易节点-产品功能点，已经被抽象出来了，后边都是逻辑和参数）。规则中心对外是读操作。

　　② [系统]配置中心：以全域业务线为id主键，可以指引业务自助拆解需求并做预配置，指引中台审核配置的一站式平台，可通俗理解为一个需求通过配置中心，可以在很多时间内，基本无开发无测试快速完成上线。注意，配置中心中的配置项，理论上属于规则中心参数的子集，配置中心收纳配置项一定是从高频到低频的。配置中心对外是写操作。

　　③ [系统]开放平台：以域能力为颗粒度立体式介绍中台能力，从应用场景、能力描述、接入流程、技术对接、产品运营等维度信息，目的是希望上游业务用户能实现自助理解和接入，也能实现中台跨域产研之间进行横向熟悉能力。开放平台对外是读操作。

　　④ [人]解决方案专家：对上能够理解战略、理解业务，对下能够熟悉中台全域能力并具备拼装能力的专家人才。

　　⑤ [人]垂直沟通：解决方案专家熟悉各域能力的程度，更多是基于拼装串联时候横向与垂直域的接触点。那对新模式来讲，更多时候需要垂直域内做一些较为专业的评估，这时候就需要垂直沟通。

　　Ok，了解完这些名词解释之后，让我们回到文章主线。

　　按照我描述的“人牵引系统”的做法，机制运行如下：

　　① 对“已有模式”的需求实现，可以依赖系统【规则中心】、【配置中心】；

　　② 对“新模式”的需求实现，可以依赖系统【开放平台】，再加上人的能力【解决方案专家】和【垂直沟通】。

　　③ 然后等“新模式”成熟之后，把对应的【规则中心】【配置中心】能力更新到系统中，逐渐循环起来。

　　以上机制，我们经过一段时间的运作，已经初见成效，目前也在持续建设中。

　　B. 纵向机制：垂直能力域

　　在垂直能力域运行机制，其根本原理跟上述横向中台平台化建设是一样的。

　　核心就是希望沉淀系统的思维，将存量能力的应用成本变得越来越低。

　　对于增量能力，只能依赖专家的垂直域知识和经验，然后等能力稳定再代入到存量能力系统去循环。

　　C. 横向与纵向协同：双向牵引

　　横向来讲，是对垂直能力的引用和规则配置。

　　纵向来看，垂直能力有很多应用方在引用，这时候不仅仅包含横向项目，也可能都独立应用或其他非中台业务方直接引用。

　　横向和纵向，如何协同？

　　说下当前转转中台当前阶段，我对这两者关系的看法：

　　① 在中台横向项目即模式能力范围内，更多是让横向牵引纵向闭环完交付。例如【配置中心】【规则中心】，这些都是跨全域的系统。

　　② 站在垂直域视角，需要把垂直能力与模式/项目解耦。例如【开放平台】，站在能力的角度来交付，支持应用场景是全样本的，不仅仅只考虑中台范围内。

　　3、结果，看系统。

　　——逐渐用系统把人的不确定因素消除掉，变为资产。

　　1）系统的分类：

　　按照最上边，我们中台面向的4类用户，其实我们的结果“系统”也会有不同的形态。

　　上边在论证“起点”、“过程”的篇幅中，已经基本描述到了，这里稍微做下总结：

　　① 业务方用户：【配置中心】、【规则中心】、【开放平台】、【综合查询】、【其他路由】。前3个上边名词解释时候已经说明了，简单说下后两者：

　　【综合查询】系统是发挥中台基础特性“数据连通性”来做的应用产品，可以让各类用户在这个系统中做到全信息查询，不用再离散各个地方拼信息。例如查看某个订单历史、当前、未来的全部信息（包含准备、信息流、资金流、实物流等）。

　　【其他路由】更多是除了项目之外，做的信息收敛措施。例如中台有非常多的后台系统，就可以做一个导航站，便于各类用户使用；例如SOP和培训，也是希望将业务对中台，可以变为1对1的交互点。

　　② 公司内产品/研发/运营用户：【垂直-配置生效类】、【垂直-运营工具类】。前者主要是内部产研用户使用，为产品运行提供基础策略/数据配置等管理操作的，例如交易链路节点、收单清结算规则配置等；而后者主要是内部运营使用，为产品运行提供运营策略/数据配置等管理操作的，例如促销活动设置、专题设置、商户管理等。

　　③ 外部用户（C、B终端用户）：C端产品主要围绕交易上下游的终端产品，B端产品主要围绕商户经营提供终端产品。

　　④ 团队内部产研用户：为输出上游产品能力提供的一些不可见的底层能力。例如各类交易链路是上游能力，但是具备很容易拼装搭建链路的能力就是底层能力；再比如专题自助拼装系统是上游能力，但是如何实现模块化拼装且支持中台、业务多方共建模块的能力就是底层能力。

　　至此，我们已经完成了“起点-用户”、“过程-机制”、“结果-系统”的全部讲解。

　　2）中台的指标：

　　最后，让我们回到文章开头提的问题：“业务有经营指标，中台有没有？”

　　我想答案是明确的，一定是有的。只不过对于中台，我们需要按照用户分类、系统属性来拆分设置。

　　指标可能有很多，但是我们一定阶段性要聚焦，找当下最核心的矛盾，建立指标去攻破。

　　当前转转中台建设阶段，我们将【中台平台化】-【存量能力】-【配置中心】的完成质量和时间，作为了我们的北极星指标，因为我觉得它可以牵动全局去改变。

　　其他指标，根据需求，也会有单独的指标在关注。例如online的数量和处理时效指标，是对项目质量和用户客诉满意度的衡量。

　　作者：四书五经六小艺 产品能力就是解决问题的能力；产品经理就是善于解决问题并创造价值的人。