中台系统建设之“屏障”思维

3 评论 2862 浏览 7 收藏 15 分钟

编辑导读:中台系统是一个很矛盾的板块,一方面人们知道它很有用,能够降本增效;另一方面,很多公司花费了大量时间精力去做中台,却没有多大的效果。本文作者从自身工作经验出发,围绕“建立屏障”这一思维展开分析,希望对你有帮助。

备注:文中所述的中台,特指电商业务中台。

一、“屏障”思维的由来

在我之前写的一篇总结文章《我做中台这5年:转转中台发展的整体回顾》中,我将过去转转中台的发展分为了5个阶段。

其中,对第四阶段定义的关键词就是“建立屏障”。也正在这个时间点之前,我脑海中有了屏障这个思维。

回顾当时的中台内外环境,正如上边图中描述的那样。

因为中台在此之前,一直处于在能力建设和项目集中攻坚的阶段,对公司对业务我们的交付原则是先有后优,导致中台在内部建设投入的资源几乎为0。

这种现在回想起来,只想别人不想自己的做法,其实是我的一个失误。

因为问题集中爆发,不仅导致了中台内部的并发事情压力很大,同时业务对中台评价负面也让大家情绪很低。

二、定位问题与解法

面对以上状态,其实感官上我们都能知道有很多问题,但是我们还是想要比较系统化地全面定位下问题。

于是,我们开始了较大范围的内部产研访谈和外部反馈收集。

我们将问题归纳分析之后,按照以中台为中心,大概有3个大的交互角色:上游业务方、终端用户、下游业务方

接下来,我们分别展开讲解:

1. 上游业务与中台之间

1)问题:沟通成本比较高,交付质量与效率低,对接感受不太好

经过深层次的分析,我们发现沟通成本高,是因为我们面向的沟通节点太多,画了一张图:

中台面向的上游业务有很多,而中台子域也有很多。它们之间的信息往来,基本就是以上杂乱的线条。

站在业务视角,中台纵深逻辑复杂以及横向联动性强,造成每个业务需要与中台多个人进行沟通,并且可能前后反复,对接效率降低;

站在中台视角,每个子域,都会同时遇到有多个业务方与他沟通,响应质量变差,更别提能够前置去了解业务动态,做动态预留和架构设计了。

于是,就形成了整体沟通成本高,对接感受差的结局。

2)解法:中台BP机制&中台平台化系统建设

面对以上2个问题,我们找到了2个解题举措:

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

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

① 重构沟通协作节点

从业务视角来看,如何减少我的沟通节点呢?答案是一对一服务。

其实就是中台BP的概念,这个BP概念其实很多人可能一点都不陌生,公司内很多部门也基本都设置有BP角色,例如hrbp、财务bp等。

中台面向业务设置BP,应该能解决业务与中台沟通1V1。但中台与hr、财务还有一点不同,那就是对内对接成本也很高,因为中台内部各产品域其实专业跨度非常大,例如支付、财务、物流、营销等等。

所以,对业务的BP(第1重身份),有时候可能很难做到内部全局cover。那怎么办呢?只能设置项目产品负责人(第2重身份),来具体横向协作中台内部各域的产品实现。

以上BP的设置,并不代表要新增人员,而只是让人具备多重身份而已。

加上中台自身垂直方向,产品天然的岗位职责(第3重身份),一个中台PM可能最多会具备3重身份,画个图:

图中,大家能很容易看出来,业务与中台内部各域的关联关系,由之前很杂乱的状态,变为了以上较为有序的状态。

在协作中,角色职责清晰,整体对业务大体做到了1V1。

当然,这个要想完全做到很完美的状态,几乎不可能。因为对中台产品的要求太高了。

既然对业务的良好理解做到超前判断,又要对内部全域系统做到全面了解,还有对上对下的强大沟通协作能力。

下图中,大家感受下大中台产品域的分类:

能胜任以上多重身份的人才,我们称之为“业务架构师”。

不过,这个也是过去在实践中,得到的唯一最优解。我们只能不断完善和迭代,多多培养这样的人才出来。

② 系统代替人:减少成熟场景下人的参与

以上BP机制,我们解决了信息流转节点杂乱的问题。

对业务对接成本和效率来讲,确实有了很大的提升。

但是,大家对中台产品来讲,从一个需求到落地,中台所做的事情比之前应该是没有任何减少的,甚至还由于身兼多重身份变得更多了。

所以,做到节点有序和减少还不够,还需要让信息流转的次数变少和流速变快。

那怎么做呢?

在上篇公众号文章《中台规划深度解析:用户、机制、系统》中,我介绍中台平台化章节中,我提到了4个系统:

分别是:规则中心、配置中心、开放平台、综合查询,我对它们也都有详细的描述,见下图:

其实,以上系统的核心,就是将重复的事情结构化,变为系统化,然后在业务与中台之间建立漏斗。

一方面,可以让业务自助解决一些问题,这样信息就不用穿透到中台。如开放平台、规则中心、综合查询。

另一方面,通过系统化的方式,让实现一个需求的过程变得有指引有配置,速率提升。如配置中心。

当然过程中,我们还做的有后台系统统一导航、中台对接人导航等等,道理也是类似。

2. 端用户与中台之间

业务与中台之间的矛盾解决了,中台产研面对另外一类用户也会遇到难题。

因为这些用户就是我们的终端用户,即服务的线上C端买/卖家(回收会有C1卖家)和B端商家,还有一部分是线下作业人员(例如仓储物流等)。

相对业务方这一内部项目需求用户来讲,终端用户遇到问题一般都是紧急的线上问题,要求要及时响应。

1)问题:用户穿透到中台产研,没有缓冲层,造成热点严重

中台本身提供交易能力,横跨用户交易的全部生命周期。一旦遇到问题,跟中台的关联度是极大概率。

而中台本身的产品资源是稀缺的,我们有的岗位基本就是1个人,甚至半个人。

那么,就很容易会产生严重的热点问题,导致产品精力受到牵制,会关联影响其他更多的事情处理效率。

下面一张图,是之前我们质检方向一位产品的企业微信日常,大家感受一下:

一段时期内,中台各个方向的PM,基本都是以上的状态,99+的消息铺开全屏幕,天天看消息看不过来。

2)解法:引入产品运营角色,工具赋能给运营

从中台产研视角来看,如何减少咨询和干扰呢?

面向以上问题,我们找到了解题思路:

就是必须在组织层面增加节点,招聘产品运营角色,形成“缓冲区”的屏障。

产品运营角色,需要发挥2个作用:

一个是由外到内,起到收拢信息、过滤信息、转化信息的作用,提升产研处理信息的有效性;

另一个是由内到外,起到沉淀解决问题方法、宣导培训用户的作用,提升上游自助解决问题,减少问题到中台。

另外,除了解决线上问题之外,产品运营角色还会牵引各种对接sop的建立,让问题流转机制趋于更加有序。

过程中,产品需要花费一些资源,做一些小工具,赋能给运营,提升解决问题的效率。

3. 中台与下游(非生产系统,如客服、大数据、财务)之间

以上中台打交道的两类用户,其实都会比较显性,在交付上一个是“最重要”业务方,一个是“用户第一”的用户。

那其实还有一类用户,我们会较难注意到他们,因为他们属于非生产系统,一定程度上不会影响用户交易进程。

但是,他们确实也服务着公司内部很多中后台的业务用户。例如,客服、大数据、财务等。

那中台与他们之间会存在什么样的问题呢?

1)问题:中台业务数据分散,会造成下游与上游业务多点对接,成本高,数据统一性差

因为处于下游,很多时候,他们没有太多话语权,所以过程中,慢慢也就会接受了很多现状,不向上游提需求或提需求上游没空“搭理”。

你想,在上边这种中台本身都没有时间做内部建设的环境下,更不会有太多精力花在更下游的系统基建上。

以上造成最直观的结果,就是下游需要兜底中台没有封装掉的业务场景,需要一对多去进行解决问题。

画个图,大概就是这个逻辑:下游业务需要对接除中台之外,还需要跟很多业务个性化信息去做识别和交互。

那这时候,下游各个业务的实现成本,其实是比较高的。

2)解法:中台核心数据分散问题统一化

那怎么办呢?还是用我们的屏障思维来解题。

即中台数据统一化项目,将下游业务依赖的发散场景收敛到中台,由中台与下游一对一交互。即形成“数据统一化”的屏障。

画个图解释逻辑如下:

在这里,中台用框架包住了业务个性化的触点,逻辑还是个性化,只是不对下游感知了,中台变为了和下游对接的唯一触点。

到这里,我们将中台对接的3类用户,所遇到需要建立屏障的情况做了详细说明。

总结一张图,便于大家记住。

到这里,就是我过去在中台建设实践中,关于“屏障”思维的一些思考。

其实,也都不是很多东西一开始就能想到,而是遇到问题一点点去解决,后续慢慢形成的归纳总结。

见招拆招,只要一心去解决问题,就必然会有所悟、有所得。

 

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

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

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

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 中台BP的这个思路真的获益匪浅,能请教一个问题吗?如何给中台BP这个职位制定考核指标?

    来自广东 回复
    1. 具体到事情上,会看辅助对口业务一个个项目的推动和落地结果。因为bp本质是希望增加链接效率,所以也会看业务、中台内部 这上下两层的满意度反馈。

      回复
  2. 以中台为中心,大概有3个大的交互角色:上游业务方、终端用户、下游业务方。

    来自吉林 回复