为什么每家大企业都想拥有“万能的”数据中台？

数据中台的概念从去年到今年一直很火，但中台战略的落地，伴随着巨大的资源投入。对品牌企业来说，中台战略的价值到底在哪？大数据企业又应该如何架构完整的数据中台？

数说故事创始人＆CEO徐亚波博士撰稿，分享中台火爆背后的实质以及数说故事中台的发展史。

以下为完整文章，Enjoy：

中台这个词从去年到今年真是火爆了，这背后一是有类似阿里这类互联网公司理念的强势输出助推；二是这些年中国背后的概念经济套路，每年都要找一些通用性比较强、容易从各个角度解释、似是而非的技术概念来炒作一番，其实质是对企业数字化转型焦虑的贩卖、是投资人、创业者、各路厂商和企业老板们的合谋；三是在中国这样一个国家概念出来的时候，其中一定还是有真实的需求在推动。

当前，中台概念背后的需求可能有一定泡沫，但在概念的强势拉动下，也会有一波建设潮，大潮退去后，总会有真正的好企业会出来。认识不到最后一点，泡沫来了，你也很愉快的参与进去了，可能只是一波韭菜。

概念背后的企业需求

那中台背后的真正需求是什么？中台的本质驱动力还是来自于需求端(市场和消费者)的变化和挑战，逐步传导到供应端(生产制造和供应链）需要做变革。中台概念最有意思的点是，它把可复用的业务逻辑和可沉淀的业务数据放到了一起，降低前端业务的迭代成本的同时，放大了数据驱动业务的价值；其兴起的核心原因还是大家认同了互联网式的快速业务创新迭代模式以及数据对于业务的价值。

在传统企业的数字化转型中，平台化的能力建设会是一个必经阶段，不管以什么名称。平台能力建设是一个周期长、牵涉广、讲起来很复杂的事，大家很喜欢中台这个概念的很大原因就是，它把数字化转型中涉及到的基础设施和IT架构变革、组织架构和管理模式变革、最终随之而来的业务模式变革，全都放进来了。老板和供应商都乐得简单：“喏，来碗包治百病的中台！”

大多数企业老板并不傻，相反都是身经百战精明强悍之辈，对于新概念乐得接受，但实际到了花钱阶段也还是会不停徘徊。“我们应该怎么做？”“ROI怎么样？”回答这些问题并不容易，哪怕是像数说故事这样一家技术型公司,自身的数据中台建设之路也都是经过了好几个曲折的阶段才真正能做到可用并有能力对外输出。但这件事一旦做成，对企业的转型升级会形成巨大的推动力。

数说故事与数据中台

第一阶段：数据资产化

数说故事中台建设的第一阶段，是“数据资产化”。其伊始可以追溯到2015年底到2016年初，公司的业务快速发展、前端业务对数据的需求变化多端，需要强分析应用能力，在公开可获得的互联网数据基础上去构建更丰富的商业应用场景。此时后端不同项目仅凭借技术层面复用（大家调用同一套爬虫代码）的方式已然不够，因为它只是节省了程序员写代码的时间，而数据本身作为一种资源没有得到重用——每个项目需求都有差别、为了特殊需求抓来的数据之间也无法互相比较，很难以沉淀历史数构建统一的数据质量体系来形成对行业趋势性的理解。

于是我们当时启动了第一个影响全局的项目—自建数据库，比较系统化地构建自己的数据中心，把能力以接口的形式开放出来给各个业务单元使用，而不是再以项目和客户为单位调用数据。

在此基础上，我们构建了自己的数据产品—数说聚合，以最便捷的方式把数据开放给行业内有需求的人使用。这里面碰到最大的坑就是复杂的数据治理。经历不短的研发过程，我们建立了相对完整的数据质量的保障体系，基本能做到在数据获取和处理的每个核心环节都有监控和告警、每类数据问题都有响应机制和解决方案、每个数据中心之上数据应用都有资源隔离和管控机制。

很多企业很难做成这类项目，因为数据从集中到真正变成可用的资产，前期需要太多投入又很难短期看到产出。回顾我们走过的路，也是在一种巨大期望和现实落差之间坚持过来的。数据资产化这个事很难也很费钱，但一旦做成，企业的核心商业模式会随之发生巨大改变，让我们逐步从一个技术和项目制的公司，转变成以数据为核心来构建高价值商业应用的公司。

第二阶段：工具平台化

数说中台建设的第二阶段，是“工具平台化”。数据累积到一定程度，必然会产生更多对数据的处理和建模的需求。这个阶段从2016年中我们自建数据库的雏形就开始了，为此我们做了一个重要的工具产品—数说立方。

最初，我们想给内外部的分析师提供一体化的互联网数据处理、建模以及可视化的BI工具，这个工具与市面上BI较大差异在于，我们内嵌了文本数据的清洗和建模算法。在这个阶段，可以说既是成功的，又有遗憾所在。

成功之处在于比起分析师传统使用的excel以及市面上侧重结构化数据以及可视化的各种工具，数说立方确实好用很多，到现在也还在被我司以及不少合作伙伴高频使用；遗憾之处在于从战略上，一个面临巨大规模且复杂数据处理场景的公司只有一个工具是远远不够的。数据清洗、数据建模和数据可视化，每个环节都有很复杂的应用场景，我们不得不持续往数说立方塞入更多功能，但由于设计之初没有以平台的架构出发，其开放性和可扩展性都受到很大的限制，最终的结果就是随着演化其工具的易用性越来越降低。

最终的结果是我们下决心从数说立方的思维方式跳出来，重新以平台模式重构核心数据的处理环节，由此打造了新的产品工具：数说工场、数说罗盘和数说方舟。三者分别司职于数据清洗、数据建模、数据可视化以及数据应用的灵活构建，以平台+算法的模式，让数据处理模式可以灵活扩展和持续沉淀。同时，三大产品同也能从数据角度互联互通，从服务角度互互相支持，灵活调用。

这套架构落地的最大影响是：数据应用的构建让“大中台、小前端”的模式可以真正实现。原有项目组的职能分工模式会被逐步打破，有想法的业务团队可以自由组合，直接在平台基础上去集成数据和模型，灵活构建出客户想要的数据应用。对数据企业内部而言，有数字化能力的人才可以依托数据应用的构建能力，很容易的打破原来部门之间的障碍，让数据更广泛地流通与使用。

到了这个阶段，企业也就真正需要一个CDO了，因为企业需要从业务视角横向地看，各个组织哪些场景是可以被数据驱动的、又需要什么样的数字化能力来互相协助，达成其业务目标。在这个阶段之前，所谓的CDO是只有规划没有落地能力的。

第三阶段：业务场景化

数说中台的第三个建设阶段，是“业务场景化”，对应的就是围绕企业的核心应用，以场景为出发点，重构企业业务平台，从而实现端到端的数据驱动业务。

到此为止，我们真正到了变革深水区——从IT层面来讲，原有的垂直业务系统需要根据场景被重构；从组织层面来讲，原有的职能组织模式需要根据场景需要重新组织；从业务模式角度来讲，原本根据标准流程构建的生产模式，需要围绕场景形成端到端的定制能力，并且该能力还要随着数据的积累互相驱动。这也就是业内讲的“数据业务化到业务数据化”。

听起来有些玄乎，以数说故事作为一个实际案例来讲讲。数说故事今年开始构建一个独立的商业创新部门（Data Application & Application Innovation，简称DAI），梳理企业内可能的数据应用场景，推动在内部端到端的应用场景创新。

那么，他们怎么工作呢？首先他们必须是一帮对商业场景非常熟悉的人，对外能和客户一起持续探讨某个商业需求的应用场景（如空白商业网点拓展），这些场景必然会对应到客户的业务流程，以及对数据源、数据分析维度的需求。围绕这些，DAI需要牵头推动与外部的数据源厂商合作，以及内部数据的整合，最后统一集成到我们的数据中台，再以大PM的角色来组织虚拟的团队，利用我们内部中台快速构建出客户想要的应用原型。

在实际交付过程中，DAI担任专家的角色，把内部产品工具里定制化的功能，逐步沉淀为中台组件，使得这个应用变得更完善、数据源更丰富、更具有个性化的能力，最后打造一个具有足够普适性的数据应用。这时，原本的虚拟组织就可以落地成为一个独立的事业部，未来甚至可以独立成一个公司，实行平台合作制。

如此往复循环，数说故事可以逐步成为一个平台型的组织，如果把这个平台开放出来给外部，就能构建自己的数据应用生态。到此，中台的魔力才真正呈现出来。

作为一个刚满四年且满怀雄心壮志的初创公司，数说故事刚刚开启我们自身的第三阶段建设。回顾数据资产化、工具平台化再到业务场景化，像我们这样原生的数字化企业都需要这么长周期，我觉得每家大型公司的数字化转型都至少需要个三到五年，体量过千亿的企业五到十年都不算太长。

好的平台都不是规划出来的，而是在有一个大的愿景和蓝图的基础上，通过大胆的摸索和实践，持续迭代创新出来的。云计算之于亚马逊、新零售之于阿里都是一样的道理。从这个角度，数说故事非常乐于分享自身的中台建设经验，并逐步对外开放我们的中台能力，和各种不同类型的企业一起来探讨推动大家的中台建设之路。