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

备注：文中所述的中台，特指电商业务中台。

一、“屏障”思维的由来

在我之前写的一篇总结文章《我做中台这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协议。