数据中台乱象：不拆“烟囱”，在开始建设的时刻，就可能会失败

上周跟一位数据中台解决方案公司老板吃饭，聊到后面，他跟我吐苦水，老有人说我们乙方公司割韭菜，我觉得很冤啊，我们不偷不抢、卖解决方案做正当生意，客户有需求，我提供解决方案，我有错吗？

那位老板说到动情处，开始抹鼻涕眼泪装惨。

我急了，就怼他，你抹鼻涕就抹吧，能不能别往我身上抹呀。

老板平复了一下情绪，接着说，你是不知道客户的情况啊，他也不懂中台，觉得概念好，有噱头，就硬要上，拦都拦不住。

我心想，你不是讨厌甲方，你是讨厌没钱的甲方。

话又说回来，这位老板说的是实情，我了解到的现状也是这样，中台解决方案市场的乱象，甲方公司要负一半的责任。

建中台的过程，就是拆“烟囱”的过程

京东的一位技术专家曾说过，“为什么要建中台？就是要拆掉‘烟囱’”。一句话就道破了中台建本质：建中台的过程，就是拆“烟囱”的过程。

做技术的都知道，系统不是规划出来的，而是根据业务的发展逐渐演化而成。就好像你养了一条鱼死了，不想土葬，只想火葬，谁知道这玩意越烤越香，然后你买了瓶啤酒。很多东西都不是你能预料的，怎么规划。

做系统，一开始以快速交付为主，就是一个个的单体应用，代码往上堆，不考虑什么高可用、架构分层。

当系统大到一定的程度，就开始拆分，做服务化，形成了一个个的微服务，这个时候系统的高可用、服务稳定性有了很大提升。

看起来已经是很好的架构了，那么有什么问题呢？

从公司的层面看，看到的就是一个个“烟囱”。

“烟囱”怎么来的？

为什么会变成那么多“烟囱”呢？从四个维度来看：

第一，“产品烟囱”。不同产品线之间的功能、定位相同。比如商品模块，商城系统有商品模块、自营系统也是商品模块、团购系统又有自己的商品模块。这些模块的功能和定位是相同的。

第二，“系统烟囱”。做开发的都有一个特点，“自己写的代码，用着才放心”，别人写的代码不愿意用，所以就会造成重复开发。其实想想，这又何必呢，把自己累成狗。不对，狗都没你这么累。

第三，“数据烟囱”。虽然数据是会使用同一个库表，但是数据的统计和定义，每个系统之间又有所不同。比如“每日订单总数”这个指标，有的按交易口径、有的按支付口径、有的按发货口径，数据统计结果就会不一样。

第四，“组织烟囱”。指的就是部门墙，有部门划分就会有部门墙，这很正常，但是如果部门墙太厚，扯皮的问题就会很严重。有时候想想，扯什么劲呢？反正20年后都要一起去跳广场舞的。

中台建设难，难在哪里？

中台建设难，并不是难在技术上，主要难在两个方面：

第一，组织。如上面的观点，建中台的过程，就是拆“烟囱”的过程。很多“烟囱”需要合并，最简单的办法就是把这两个相同产品部门合并，这就涉及到组织的变动了，如果没有高层的支持，就会很难，因为你动到别人的“地盘”了，别人会跟你拼命。

第二，思维。思维分成两个角度：服务提供方、服务调用方。

服务提供方，就需要把自己的工作范围扩大，具备“中台思维”，也就是自己提供的服务不仅是给自己用的，还要给其它团队用，要兼顾所有调用方，要做好能力的沉淀，提供好支持。

服务调用方，不能想要什么服务就自己建，要先考虑是不是已经有现成的服务可以调用，如果有就要去调用，如果不满足要求，就要去推动服务提供方完善服务，这点也是开发人员抵触的，害怕去推动，不愿去“麻烦”别人。

先有“中台思维”，才有“中台系统”

知道了问题所在，就可以针对性地寻找解决办法。

组织层面。要获得高层的支持，解决好合并组织带来的人员之间的矛盾，这些都要安排妥当。不要因为问题棘手，而选择故意躲避，问题始终存在，而且随时可能爆发。

思维层面。给技术人员宣导“中台思维”，即：服务调用方要考虑充分使用现有的服务，不要自己去写。服务提供方，要兼顾“小前台”们的需求，提供好中台服务。思维方面的支撑，建立中台系统才是事半功倍、水到渠成的事情。

写在末尾的话

总结一下：

1、建中台的过程，就是拆“烟囱”的过程。

2、“烟囱”分成：产品、系统、数据、组织四种。

3、中台建设难就难在，组织和思维两个方面，技术反而是好解决的。

4、建中台要先获得高层的支持，解决组织的问题。做好“中台思维”的全员宣贯，服务提供方和服务调用方都必须升级成“中台思维”，解决思维的问题。

5、总之就是一句话：拆系统“烟囱”容易，拆思维“烟囱”难。

很显然在目前的信息时代，借助类似于FineBI的这些工具，可以让企业加速融入企业数据分析的趋势。备受市场认可的软件其实有很多，选择时必须要结合实际的情况。一般的情况下，都建议选择市面上较主流的产品，比较容易达到好的效果，目前企业数据分析BI软件市场占有率前列的，就是帆软BI软件——FineBI。