中台建设的误区有哪些?产品经理请不要再犯了

最近，我很幸运地被邀请参加一家公司对他们中间平台架构的评审。整个过程就是简单的规划每个产品线领导负责的内容的最新产品版本，配合公司的中间平台战略，宣传自己负责模块的中间平台。

但不幸的是，在这篇评论中，我听说要建设的中间平台不下十个，几乎所有负责各模块线的人都在谈论建设自己模块的中间平台。

例如，搜索中心要做搜索中心，财务中心要做财务中心，商品中心要做商品中心，等等。听到这个消息我很震惊。中场的设计完全打破了原来的中场概念。

然而，这只是一个开始。听完对整个中场架构的回顾，我只能说公司的中场战略对中场概念有三个非常大的误解。让我一个一个地谈谈。

1、中台建设的误区有哪些——服务中心=台湾中部

我要说的第一个错误是，这家公司的产品总监把服务中心的一项基本服务称为“中泰”。

所谓服务中心是指：我们从公司内部的多个业务条线中提取出一个具有相同或相似需求的服务作为公共服务，并将其开放给不同的业务条线。

例如，在电子商务中，如果我们有多种电子商务模式，那么我们对基本订单、商品和成员有共同的需求。无论我们的业务是网上购物还是自营电子商务。或集团电子商务。然后我们有三个服务中心：商品中心、订单中心和会员中心。

不同的服务中心汇聚在一起，形成我们的商务中心。因此，本文还对业务平台进行了定义：它是一个业务半成品解决方案聚合中心，由所有通过并经过可重用性验证的业务组件组成。

也就是说，一个企业内部只有一个业务平台，业务平台内部设置了不同的基础服务。任何一个基础服务都是中间局的一个服务单元，负责解决不同的业务场景。

2、中台建设的误区有哪些——跛足中期

我在这篇评论中发现的第二个错误是，这家企业只具备了重用中台解决方案的能力，没有通用的接入方案，所以可以把火车变成马拉火车的奇观。

例如，如果要在中间阶段将商品服务中心从产品线内的公共商品管理模块抽象到服务中心，那么就不仅仅是打开商品中心的读写接口。

除了多路复用，更重要的是我们提供了一套接入解决方案，这是最重要的部分。我们需要一套通用的总线机制，即建立一个快速统一的企业内部信息高速公路(类似于微服务研发的ESB总线机制)。

具体来说，应解决以下问题：

如果想要使用商品和服务的功能，业务线只需要几个接口就可以完成数据传输吗?

对接成本是否低于业务线开发的一套商品管理模块的成本?

服务中心是否提供自动适配终端功能?

开放式商品服务中心是否改善了周边功能?如商品采购数据统计、线上线下数据统计等。

因此，访问方可以通过简单的对接来拥有一整套SPU/SKU管理和数据分析功能。

也就是说，我在《中泰产品经理》一书中提出的中泰建设的另一个重要组成部分是中泰投入产出“管道”的定义。只有这样，才能称之为中泰内部的服务中心。

3、中台建设的误区有哪些——在大陆和台湾兼职建筑队

当我听到每个产品线的产品经理谈论他们的服务中心的规划时(在他们眼中，是中间阶段)。我发现有一个特别严重的问题，那就是，尽管他们意识到他们构建的模块是为公司的不同业务线团队提供服务。

但这些服务中心施工队都是现有业务团队中的兼职施工队。

例如，前台的消费电子商务业务团队负责建立公司的商品服务中心，使整个公司在采购系统、仓库系统和商场系统中只有一套SPU/SKU和后台采购分类。

以上就是《中台建设的误区有哪些?产品经理请不要再犯了》的全部内容了，可以从文章中看到，这只是一个开始。听完对整个中场架构的回顾，我只能说公司的中场战略对中场概念有三个非常大的误解，如果你想知道更多产品经理知识，可以点击下方资料下载链接。