中台系统建设之“锁链”思维

0 评论 3203 浏览 24 收藏 15 分钟

编辑导语:在进行中台产品设计时,有很多思维可以借鉴,例如“屏障”思维、“锁链”思维等。在这篇文章中,作者对其中的“锁链”思维进行了详细的介绍,一起看看吧。

一、何为“锁链”思维

上上篇文章《中台系统建设之“屏障”思维》中介绍到了“屏障”思维。

“屏障”思维核心要解决的问题,是外部(上游业务、终端用户、下游业务)与中台之间的对接效率。

其中,以最关键的用户“上游业务方”与中台之间,我们搭建的“屏障”有2个:

第一个,是减少沟通节点,进而提升整体沟通效率,即形成“BP机制”的屏障。

第二个,是减少非必要沟通,让系统沉淀取代人,即形成“平台化系统”的屏障。

当时提到的平台化系统,大概有以下4种:

  1. [系统]开放平台:以域能力为颗粒度立体式介绍中台能力,从应用场景、能力描述、接入流程、技术对接、产品运营等维度信息,目的是希望上游业务用户能实现自助理解和接入,也能实现中台跨域产研之间进行横向熟悉能力。开放平台对外是读操作。
  2. [系统]规则中心:每一个模式在中台全域(包含准备、信息流、资金流、实物流、其他)实现的所有逻辑和参数声明;你可以理解为产品需求规则文档,但是是经过高度结构化之后的(结构化就是产品域-角色-交易节点-产品功能点,已经被抽象出来了,后边都是逻辑和参数)。规则中心对外是读操作。
  3. [系统]配置中心:以全域业务线为id主键,可以指引业务自助拆解需求并做预配置,指引中台审核配置的一站式平台,可通俗理解为一个需求通过配置中心,可以在很多时间内,基本无开发无测试快速完成上线。注意,配置中心中的配置项,理论上属于规则中心参数的子集,配置中心收纳配置项一定是从高频到低频的。配置中心对外是写操作。
  4. [系统]综合查询:是发挥中台基础特性“数据连通性”来做的应用产品,可以让各类用户在这个系统中做到全信息查询,不用再离散各个地方拼信息。例如查看某个订单历史、当前、未来的全部信息(包含准备、信息流、资金流、实物流等)。综合查询对外是读操作。

其中,除《开放平台》的作用是侧重于垂直能力描述之外,其他3个系统都是解决跨域之间能力/数据拼装的问题。

我把架构设计这3个系统用到的拼装思维,称之为“锁链”思维。

二、“锁链”思维的本质

说起“锁链”思维,可能并不特别高大上,它最初灵感来自于SOP。

以我们最早应用“锁链”思维所做产品《配置中心》为例,简单说下它的演化逻辑。

大家都知道,在中台范畴内,一个业务解决方案的交付,往往是需要伴随着多系统能力拼装而成的。

而在过程中,就会发现各种逻辑配置很多,很容易丢失,造成项目中的错漏现象,影响系统运行和交付。

最早时候,我们对一个需求的实现,即中台能力拼装,都是靠人的经验的。依赖产品经理对需求的理解,以及对所有系统的能力理解。

在一次又一次重复的过程中,大家逐渐发现这里面需要考虑的配置点是有一定规律的,所以就慢慢开始沉淀经验,把某一类需求所需要的准备项和配置项,列到excel来管理。

如下图(某一个需求实现的部分配置信息,excel管理):

到了后来,发现类似需求的增加是常态的,所以就逐渐把这个串联的过程,变为了线上系统。可以牵引业务方用户,按照我们的指引步骤,一个个输入他的需求信息。

这样,我们的产品人员,就减少了与业务方用户之间的线下信息沟通。

再往后,我们把配置项,全部结构化为公式和参数项,需求用户和中台人员,就可以直接在线进行填充和审核生效。又省掉了细节的沟通确认和测试回归成本。

如下图(基于业务线在线化申请与配置管理):

以上,就是我们中台平台化系统《配置中心》的演化过程。

所以,现在回过头来看,“锁链”思维的本质是什么?

我按照自己理解,做些定义:

为了实现某个复杂的目标,我们需要将多个分散的任务项全部准备好才能完成。而这个分散是不可控的,我们需要构建一条锁链将其黏连,去掉对人的依赖,从而进行低成本复用。

有3个关键原则:

  1. 这个目标是需要重复发生的,这样才值得构建锁链,否则ROI很低。
  2. “锁链”最好是系统化的,要尽可能减少人的不可靠因素,否则长此以往一定会因不断出现问题而被人不再依赖。
  3. “锁链”理论上应该都会存在一个主键信息,用来作为全局身份标识。

三、基于经验抽象沉淀“锁链”

大家可能发现了,在讲解《配置中心》时候,我们这些配置流程和配置项,都是经过一次次重复实现的过程中,慢慢积累沉淀而成的。

那我们如何将混沌的经验变为有序的锁链呢?

我的答案是:将经验信息逐层结构化提取。

接下来,我介绍下我们中台另一个产品《规则中心》。

大家都知道,转转其实有非常多种的业务模式,C2B、B2C、B2B、C2C、C2B2C、以旧换新,还有上门和门店履约方式。

每一种模式下,在中台全域实现的所有逻辑,就是这个模式的规则集合。

在上边章节中的《配置中心》,那条配置锁链,能解决掉共性比较大的系统问题。

但是对一个大模式来讲,它的规则太多太多了,并且还有所有的信息不需要经常变化,配置意义就会变得有限,但是基于对一个模式的全局理解和掌握,还是需要将所有的信息尽可能管理起来。

所以,我们发起了一个项目就是《规则中心》,第一阶段就是梳理整理各种交易模式的全部规则逻辑。

在这个过程中,我们逐渐将之前的规则信息不断结构化,抽象提取出了以下关键维度信息:

单据类型、信息类型、流向、业务域、用户角色、子域模块、功能点。

以上信息,颗粒度由粗到细,到最后一级基本就是最细的封装功能点。再往下还可以拆,但是必要性就很小,因为多一层,信息量级就会爆炸。

保持最佳结构化程度,便于人脑能高效处理。聚焦某一个功能点之后,其内部的逻辑,是可以非结构化描述处理的。

基于以上这套逻辑,我们跑了若干种业务模式,基本应该可以装得进去。随着更多模式的梳理,我想大部分的变动点,也无非就是再完善第7级功能点的增加,慢慢这个功能点并集就会趋于稳定。

同理,我们《综合查询》产品,也是基于以上经验沉淀锁链的方式打造的。

将各类用户在日常工作中遇到的各种关联查询,做成了工具,加上中台数据的集中性特点,我们就能输出基于特定主键的全域数据链查询。

如下图(以销售订单为主键的关联各类信息查询):

经验型沉淀“锁链”,有个不足的地方就在于,前面几次是有试错成本的,要接受考虑不完善带来的系统或用户问题。

但是,一旦经验比较充足,构建锁链的过程其实是没有太大问题的。而我们工作中的大多数情况,面向的90%以上都是已经比较成熟的模式,有很多的信息样本。

所以说,我们要能在这90%的场景中,构建一些锁链出来,那对于企业提效也是大功一件。

四、经验之外,构建“锁链”的方法论

经验型沉淀锁链,是基于历史经验的归纳总结。

那如果没有经验,假如是面向一个新的模式,我们又该如何构建第一条“锁链”呢?

这时候,我们就必须要正向思考了。

大家都知道,电商业务的核心本质是交易,所有的一切都是伴随着交易的进行而发生的。

  • 交易的对象是什么:商品/服务(需要商品采购、加工生产、质检、仓储、运输等环节的履约能力)。
  • 交易的主要对手是谁:提供商品/服务的卖家用户(卖家入驻、经营管理等)、购买商品/服务的买家用户(用户注册登陆、浏览、购买等)。
  • 交易的服务角色有哪些:平台方(用户经营、营销促销、售后仲裁、客服等人员)、保险(提供商品险、运费险等)、三方物流(为买卖家提供仓配服务)等。
  • 平台企业经营关注:风险控制、成本预算盈亏(财务、数据)等。

以上基本上就是交易的各类用户需求与能力。

接下来,我们将以上需求和能力,所涉及到的产品域做一些分析。我大概将其分成了5个类别(里面只是列举部分,并非全部):

  1. 准备模块:基本就是产生交易订单之前的所有准备项。例如交易对象(商品准备好)、交易对手(买卖家达到交易条件)、交易三方角色(促销、服务等规则发布和设置)。
  2. 信息流模块:以交易对手交互的单据信息为核心。包含正向订单、退款退货单(售前退、售后退)、仲裁(平台介入协调)。
  3. 资金流模块:以交易过程中的资金流转为核心。包含支付、清结算、账务、资金运营、财税合规等。
  4. 实物流模块:以交易过程中的实物流转为核心。包含供货、质检、仓储、物流、退货、换货、维修等。
  5. 其他模块:以服务交易和管理交易为核心。例如风控、客服、数据等。

那,这些将这些元素模块如何串起来呢?

我根据自己过去的产品设计经验,将其定义为3步法:

  1. 第一步:流向(流程)。信息流、资金流、实物流;以信息流为核心,关联资金和实物,串联所有分支流程。
  2. 第二步:用户(功能)。把所有用户在以上全部流向中匹配一下各自用户驱动3个流向所做的事情,抽象描述为一个个功能项。注意这个用户,是包含以上1-5所有模块中的用户,例如平台运营、仓配、三方等各种用户。
  3. 第三步:终端(交互)。将第二步中,所有用户的功能项,对应细化到**后台的**页面的**操作,就是一个个交互。

依次按照以上3个步骤来串,然后交叉比对,一步步细化,确保信息无遗漏。

本文以上经验描述,是我在电商业务体系内沉淀得出的,但内在逻辑是类似的。无非就是用户角色和信息流不同罢了,大道相通。

以上,就是我关于“锁链”这一思维在中台产品设计中的思考。希望文章对大家有所帮助。

 

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

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!