中台规划深度解析:用户、机制、系统

12 评论 4751 浏览 66 收藏 26 分钟

编辑导语:中台这一概念从提出到大热,如今,已有不少企业开始组织架构的调整,搭建中台,那么如何更好的了解和规划中台呢?本篇文章中作者对中台规划进行了深度的解析,一起来学习一下。

一、问题:业务有经营指标,中台有没有?

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

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

例如:

  • 订单业务部门,有单量、GMV、营收、NPS等指标;
  • 金融、商业等营收部门,有收入指标;
  • 就算履约,也有各种人效、产能、满意度等指标;

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

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

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

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

那中台呢?

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

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

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

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

例如:

  • 中台面向的用户是多样化的,有时候跨度很大。那这些用户的关系是怎么样的?
  • 中台大部分时间,是在做一个个项目的交付。这样做只是简单的资源换输出么?
  • 中台提供了一个个不太可视化的“能力”,还有一些工具、页面。那中台的“产品”到底是什么?

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

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

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

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

中台规划深度解析:用户、机制、系统

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

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

1. 起点,看用户

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

中台规划深度解析:用户、机制、系统

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

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

1)业务方用户:

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

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

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

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

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

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

2)公司内产品/研发/运营用户:

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

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

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

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

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

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

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的数量和处理时效指标,是对项目质量和用户客诉满意度的衡量。

 

作者:减形简远,微信公众号:产品杂谈(life_pm)

本文由@减形简远 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 体系化思考和构建,学习了,谢谢~

    来自浙江 回复
  2. 连着看了博主的四篇内容,受益匪浅,感谢~

    来自上海 回复
  3. 建议名称加上电商中台,制造业,b端管理系统的中台,不是这样的。不要以偏概全,中台的含义很广。

    来自四川 回复
    1. 好的 感谢建议。

      回复
  4. 作者从用户、机制、系统这三大方面对中台规划解析得很透彻,合理。

    来自江苏 回复
  5. 中台是一个泛概念功能,啥都往里装,,结果,,眼下,很悲凉,,现在说的中台需求和实现,早已有之,只是不断变换着实现路径和新技术。工具,,,,,,

    来自四川 回复
    1. 赞同。太阳底下无新鲜事,世界上没有太多新的轮子。erp或现在很多saas的产品都是先驱,本质上就是如何提升复用性达到整体降本的目的。自己对中台概念没有执念,就是奔着以上目的看如何为企业找到最优解。

      回复
    2. 是的,,完成一个商业项目

      来自四川 回复
    3. 有道理

      回复
    4. 有道理

      回复
  6. 想法和感悟很不错,给作者点个赞

    来自浙江 回复
    1. 感谢认可。

      回复