数据中台不是“银弹”

要不要建设数据中台，这是每个需要做数字化运营的公司必须回答的问题。数据中台所提供的功能肯定是企业需要的。那么何时开始建设数据中台，如何在开始数字化建设时就为数据中台的建设打下基础，这些问题就是我们下一步要来解答的。

本章将介绍数据中台的一些能力的表现形式、数据中台的适用场景，以及什么样的公司需要建设数据中台。

2.1　数据中台不是“银弹”

近些年来，数据中台的概念非常火热，众多厂商纷纷宣传自己推出了数据中台相关的产品或解决方案，且业界对数据中台的前景也十分看好。那么，这是否意味着数据中台就是能够解决一切问题的“银弹”？

答案当然是否定的。数据中台的成功是建立在信息化的基础上的，没有完善的信息化基础，企业就无法全面理解企业业务，更难以从中获取有用的信息。另外，数据中台提供的是对现有产品和市场的快速洞见，是对现有产品和运营的提升，也就是说，数据中台可以助力市场的开拓，开发新的商业模式，加快迭代的速度，但是最终的实现还是要依靠数据中台团队的创造力。

一般来说，拥有多个事业部、多条产品线，需要在众多产品线中形成数据共享和复用的企业，可以最大化数据中台的投入产出。在多条产品线、多个业务部门形成数据合力之后，数据的作用将得以最大化。数据中台有两大好处。

其一，在开发新产品的时候，可以重用现有的数据功能，新产品线在接入数据中台后能够快速构建上线。例如，如果某个企业已经有了一个统一的用户画像服务，那么每个新上线的系统就可以直接使用这个用户画像服务，而无须重新构建。

其二，打通后的数据能够提供额外的决策信息。例如，某个企业想要实时评估广告投放效果，但是相关数据分别存放于渠道商的网站上、自己的业务系统以及第三方的ERP和CRM中。在数据打通之前，无法实现数据联动，需要较长的时间并且要进行一些手动操作才能形成全面的业务报告。而在数据中台将数据打通后，数据联动效果得以体现，可以实时生成反馈，自动、动态地展示投放效果。

实际上，企业是否应该建设数据中台与企业规模并没有必然联系。即使是规模很小的企业也需要有正确的方法论和架构来建设自己的数字化运营体系，而数据中台正好提供了这样的方法论和架构。虽然有的企业并不需要立刻建设数据中台，但从未来数字化驱动发展的趋势来看，它们仍需要为数据中台做准备，因为大多数企业的发展轨迹是从单一业务线发展到多条业务线。需要特别注意的是，建设数据中台并不是企业的最终目的，企业也不应为了建设数据中台而建设数据中台，更不能盲目跟风。数据中台的最终目的是帮助企业实现数字化运营，成为数据驱动型企业。

事实上，数据中台的出现标志着企业管理进入新阶段。一般来说，在企业发展初期，业务相对简单、IT系统并不复杂，企业的管理相对简单，产品的完善和业务的增长是首要任务，因此企业不会太关注管理与技术架构，对数据中台的需求也不会很强烈。而当企业发展到一定阶段，企业就会逐渐开始重视研发效率，用更高的研发效率和更快的迭代速度满足用户的需求，以提升自身的竞争力，这时数据中台对于企业的重要性就会日益凸显。

随着企业及其业务的进一步发展，企业前台业务线和后台能力模块将会变得臃肿、杂乱、难以维护，这将使得企业在应对业务变更和创新时捉襟见肘。而数据中台对原有前台、后台数据能力进行的抽象、共享和复用，则避免了重复建设，复用了企业的数据能力，将后台系统中需要被前台频繁使用的数据能力抽象出来，仅需通过简单的API调用即可将这种数据能力赋予业务。这样就形成了所谓的“大中台，小前台”结构。对于大型企业来说，数据中台能够避免传统IT系统中经常出现的烟囱式架构，通过数据能力抽象，将核心数据能力集中起来，从而避免重复建设，提升组织中的人均效能。从这一角度来看，数据中台不仅是技术层面的变革，也是对整个企业业务架构的重新调整。数据中台实现了从信息化管理向精细化运营创新的转变，为企业构建科学高效的运营管理服务体系提供了可能。换言之，数据中台是企业进入更高级管理阶段的一个标志。

2.2　数据中台的核心能力

数据中台建设的核心思路是赋能业务部门，提供更好的数据能力工具，使业务部门能够通过中台提供的功能快速获取商业洞见，从而快速提供数据驱动的业务产品。因此，脱离了业务应用，数据中台的建设就是空中楼阁。我们在规划数据中台建设的时候，要有业务应用的场景，后续的迭代必须由真正的业务需求来驱动。

值得注意的是，虽然我们强调业务驱动，但是数据中台提供的整体规划和全局数据规范是必不可少的，否则一味求快，很有可能又会回到原来数据孤岛、应用孤岛的状况。

那么如何真正实现业务驱动的数据中台建设呢？下面我们介绍几种业务部门所需数据能力的常见表现形式和实现思路，以及如何获取商业洞见，如何利用实时数据报表实现精细化运营、快速决策，利用中台能力快速开发新业务，为客户提供个性化的服务，并在产品推出后快速获得反馈。

2.2.1　全局商业洞见

商业洞见一般有如下几种。

• 通过分析市场行为，发掘新的商机和产品机会。一种可能的方式是从市场调研或公开信息中爬取所需要的用户和市场行为数据进行分析，例如利用市场调研报告进行用户情感分析。虽然这可能成为数据中台的一个功能，但是在这里，我们主要侧重于从现有用户的行为里发现新的商机和产品机会。
• 通过对现有产品的表现进行评估和判断，提升其用户满意度及市场竞争力。例如，评估产品在各个细分年龄段、不同地区的用户中的表现。
• 对公司各个部门和功能的表现进行实时多维度评估，例如对每个业务部门各个维度的业绩进展、重要经营指标的实时掌握。
• 对具体业务的精准掌握，例如广告投放效果的实时评估、下级经销商的销售情况、当前库存和销售情况相结合的预测报告。

这些商业洞见都需要有大数据平台的支持。传统的BI、大数据平台、数据仓库都能够帮助我们减少创造新业务和产品过程中的不确定性。而数据中台与它们的区别在于，数据中台需要汇集全公司、全渠道、多数据源的全局信息。它不局限于某一个业务系统、某一个事业部的数据范围，必须要有全局打通、统一治理的数据。因此，有可能每个事业部都有自己的大数据平台，但是一个公司只会有一个数据中台。

不可否认，这对于一些企业有一定困难。当管理决策人员、业务部门负责人或产品经理不能获得某些数据时，他们一般会要求BI分析师生成其所需要的商业报表，而以下是经常出现的场景。

• 所需要的数据不在当前系统中。例如需要的数据没有采集，还要重新采集数据；或者需要埋点的地方没有设计好埋点，还要修改业务系统来增加新的数据点。
• 所需要数据的准确性需要很长时间来判断或处理。这一般是因为数据处理链条太长，涉及各种不同的系统。如何确认数据的准确性，如何系统性、持续性地监控数据的正确性是很重要的问题。
• 报表制作需要专业人员来完成，大家排队等待数据工程师跑数据。运营、产品、市场等各部门都要通过数据工程师获取数据，整个流程主要是沟通需求→分析数据源→升级数据采集系统→开发程序→提供结果。在这样的流程中，大数据部门很容易成为瓶颈。当然，数据需求方可能因数据获取速度慢、等不及而自己拍脑袋做决定，最终导致产品迭代效率低下。
• 报表只能看到宏观数据，在分析问题的时候作用不大。一般的报表能够让团队负责人了解宏观数据（如销售额、用户数等），这对他们有一定的帮助。然而宏观数据在分析有些问题时就无能为力了，比如为什么昨天的活跃用户数暴跌20%。这时我们需要进行更深入、更精细的分析，如按照渠道、地域等维度对数据进行分解，判断某渠道或某地域是否有大波动，并进行多维度、细粒度的下钻分析等，这样才能快速定位问题，在解决问题时有的放矢。
• 无法跨越数据孤岛去获取自己需要的数据。一些集团化企业的孤岛效应尤为明显。做大数据分析需要与不同部门沟通协调，获得审批权限，等待数据审批完成后才能统计数据，整个周期较长，而且这些数据可能因为没有统一ID而无法打通。从企业自身数据的价值角度来说，应消除部门间的数据孤岛，让数据协作更顺畅。

总的来说，建设数据中台的目的就是系统性地解决这些问题，使所有业务人员和决策者都可以快速获得他们需要的数据洞见。

实际场景，鞋类品牌百丽通过全流程化的数据改造，将一双鞋要经历的供应链、设计制造、门店决策、会员管理等流程统一纳入数据化流程，真正实现了数据驱动。例如，百丽子公司滔搏运动的一家线下门店根据惯有逻辑，认为男性流量会大于女性，因此店内的男女鞋铺货比为7∶3。而在通过搜集进店流量、顾客店内移动线路和属性并形成店铺热力图之后，却发现进店女性客流占总客流的50%以上。于是这家门店增加了30%的女鞋陈列，改动后的单店女鞋销售额增长了40%。

2.2.2　个性化服务

个性化服务是指通过对客户需求的精准分析提供针对性的产品和服务。例如，我们可以使用标签体系来精准定位一个用户群体，然后针对这些用户进行一些特定操作，比如促销活动或邮件触达等。这就是一种个性化服务，随着智能手机、移动应用、5G、IoT的普及，人们的消费习惯越来越多样化和个性化，如何整合生产系统、供应链、营销系统以快速满足用户的个性化需求成为很多企业的重要课题。

除了这种从全部用户中定位一批用户并进行特定操作之外，还有一种常见的个性化服务是基于用户画像的产品推荐。最常见的例子有Facebook、Twitter、今日头条根据每个用户的阅读历史推荐他们可能最感兴趣的文章，Amazon、淘宝、美团根据用户的购买历史来推荐他们最有可能购买的产品，Netflix、YouTube、抖音根据用户的观看历史来推荐他们最有可能观看的视频。

实际场景　可能不如前面的例子广为人知，Google和百度也可以基于用户的搜索历史提供个性化的推荐结果。搜索引擎经常会遇到一词多义的问题，例如，用户搜索“Saturn”，应该为其返回什么？Saturn可以指土星、车、电影，甚至游戏主机，如果搜索引擎对用户一无所知，那么可能就会返回一般化的相关信息；而如果搜索引擎知道这个用户最近一直在搜索购车信息，他很有可能正打算购买一辆Saturn汽车，那么就应该返回附近销售Saturn汽车的车行信息。Google开发Gmail的初衷之一就是可以通过用户的邮件对用户的兴趣有更深入的了解，从而能更精准地为用户提供搜索结果。这也是不同产品之间数据互用的例子。

除了上面提到的有关互联网、电商企业的个性化服务，其他行业也有越来越多的个性化服务需求。

• 银行业需要为用户提供定制的金融产品，如理财产品、信用卡产品。波士顿咨询公司（BCG）的一项调研发现，“22岁到49岁年龄段客户的理财需求最强烈，他们中有四分之三的人希望银行能够像他们的私人‘虚拟理财教练’。毫不意外，绝大多数客户希望银行也可以像互联网一样为他们提供个性化的体验。”
• 保险业需要为客户提供最适合的、高度可定制的保单。在《德勤2016年保险市场分析报告》中，未来场景中的第一项就是个性化的保险，其必备条件是“先进的预测分析能力，以支持复杂定价和风险管理，可获得行为、场景和其他关联数据，通过实时数字渠道在适当时刻联络客户，从而提供前瞻性建议”。这正是数据中台应该提供的能力。
• 服装行业需要根据消费者的喜好和身材数据定制衣服、鞋帽。例如，服装定制提供商衣邦人可以通过用户地区、个人数据提供特定时间节点的特定产品促销；传统鞋类零售连锁集团百丽在进行数字化转型之后，在线下门店里采集用户数据以提供更精准的产品推荐服务。

提供个性化产品推荐的系统一般需要包含如下功能组件。

（1）用户画像

对于每个用户，我们都想知道其年龄、性别、地区、行业、身体状况、收入状况、兴趣爱好、社交属性等，并能根据需求快速获取。而在传统行业里，获取用户画像是非常困难的，因为用户在线下用现金交易，交易过程中不会涉及任何个人信息。互联网企业在这方面有着先天的优势，浏览器Cookie的使用，允许像Google这样的企业在不需要创建任何用户系统的情况下收集用户的信息。在越来越多的交易转移到线上和移动端之后，企业收集用户信息的手段就会越来越多，连线下企业也逐渐开始使用类似于会员制销售的方式积累用户信息并形成用户画像。打通各个业务子系统、将分散的用户信息形成一个完整的用户画像，这是很多企业建设数据中台的一个目的。

（2）产品画像

产品画像是指产品的一些属性标签。这里的产品是指广义的产品，是用户可以消费的一个实体单位。例如，对于今日头条，每篇文章就是一个产品；对于Twitter，每条推文就是一个产品；对于电商，每个SKU就是一个产品。这些产品都必须有一些自己的标签。例如，对于Twitter的每一条推文，其主题（体育、娱乐等）就是一个标签，其作者分类（大咖、媒体人员、学生等）也是一个标签，其发出的地区、推文表现的情感都是可能的标签。一般来讲，每条广告就是一个产品，不过其标签一般是由人工设定来匹配指定用户人群的。值得注意的是，有的产品画像比较容易获得，例如SKU对应的3C产品；但有些就需要非常复杂的人工智能系统来判别，例如，精准获得视频的标签可能会成为一个单独的服务和行业。

（3）匹配服务

匹配服务一般是双向操作，一个是给定用户，找到最符合该用户画像的产品（如文章、视频、推文、广告等）；另一个是给定产品，找到最适合这个产品的用户群体并推送给他们。匹配服务的精度是很多互联网公司的核心竞争力，因为用户在产品上花的时间和精力是有限的，向用户推送一个其不感兴趣的产品相当于浪费了一次销售机会，也降低了用户的产品体验。如果每次推荐的产品（包括广告）用户都感兴趣，用户体验和销售额就都会提高。匹配服务需要使用一定的机器学习模型和行业知识图谱，而这些一般需要专门的团队来开发。

（4）反馈服务

提高匹配服务的成功率是个性化服务的关键，当然，这是建立在精准的用户画像和产品画像的基础上的。但要在数据或算法不是很完善的时候冷启动，这就要靠反馈服务了。我们推荐给用户的哪些产品用户感兴趣？哪些产品用户完全忽视？用户在我们推荐的文章或视频上停留了多长时间？为什么我们的模型精确度不高？我们在用户画像、产品画像、匹配服务中的哪一个步骤出了问题？反馈服务将这些问题的答案准确地记录下来，作为整个系统的迭代基础并持续衡量这些业务指标。

那么个性化服务与数据中台有什么关系呢？

第一，很多集团企业需要从各个部门获取和打通用户数据，这样才能形成比较全面的用户画像，以及在集团范围内推广个性化服务；

第二，用户画像服务应该以一种可重用的数据服务方式被很多部门同时使用；

第三，个性化服务的反馈和最终效果评估需要从各个部门的业务数据中统一提取。

上述功能组件都需要数据中台的支持。

2.2.3　实时数据报表

对于业务部门来讲，任何一个产品推出后他们最想知道的就是市场对产品的反馈。对于不同的行业，市场对产品的反馈形态有一些共性，也有很多行业特定的属性。例如，一般来说，产品的销售额肯定是最直接的反馈，而对于很多互联网产品来讲，用户注册数、用户活跃度、用户留存也是很重要的指标。对于线下销售，除了销售额之外，了解门店中用户的兴趣点、购买用户的细分、市场手段的触达情况也能帮助精细化管理整个销售流程。

因此，为了监控能够反映整个企业或单个产品运营情况的最重要指标，很多企业都会建设业务部门可以使用的实时业务数据报表及可视化工具。例如，一个可视化的实时看板，也就是俗称的可视化大屏，可以展示全局业务的关键指标以及实时发生的重要信息，如图2-1所示。不可否认，有不少大屏的项目是面子工程，但是一个能够显示最新核心指标、易用的可视化工具是非常重要的。

正所谓“一图胜千文”，一个好的实时数据看板可以让管理者快速掌握企业的运行状况，让一个部门、一个项目组的人员能够快速了解当前产品的运行情况，对任务及其优先级有一致的理解。在许多高科技公司，不少部门会购买专门的大显示屏，并将其悬挂于工作区域，显示本部门的一些核心指标或者产品的运行情况。大家在工作之余，一抬头就能知道公司和产品的运行状况。

在建设数据中台的同时，产品部门需要的各种数据功能在理想情况下应该可以实现无编程或者低代码配置。如果一个产品在上线之前经过数据委员会的审核，确认其数据采集规格符合要求，那么产品在上线后基本可以得到实时反馈。实时报表流程中的大部分组件可以提供可配置的SDK或界面，在应用发布的时候指定日志和数据的位置、需要采集和展示的指标，整个流水线就可以运行起来，将各种关键指标采集到最终展示它们的位置。最后显示的大屏可以以模板的方式提供基础展示，只在有特别显示需求的时候才需要定制开发。

2.2.4　共享能力开发新业务

数据中台的目的是数据能力的抽象、共享和复用，其中的共享和复用并不只是出于省钱的考虑而提出的，在很多时候它们是开发新业务的驱动力。在阿里巴巴和今日头条的案例中，我们看到它们在企业内利用现有用户数据快速落地新业务的强大能力。赋能企业内各个业务部门，帮助其快速理解现有数据，使用现有数据开阔思路、开拓新业务，是数据中台建设的一个重要目标。

实际场景：Twitter的Hack Week

Twitter每个季度或每半年会组织一次Hack Week。在这个星期，日常的项目都会被放下，员工可以自由组队，在头四天里开发出一个Web或移动应用，到星期五统一评比，从中找出比较适合公司发展的项目并将其融入现有产品中。这些应用中有很多是基于现有的用户数据或产品开发的，例如基于位置和用户兴趣的“附近的人”推荐，基于实时数据流的突发事件监测和推送，基于用户兴趣和公众热点的智能信息流等。在早期大数据平台不是很完善，很多团队需要大数据组同事手把手的指导才能实现应用原型。随着公司的发展，这项工作越来越困难。在Twitter的大数据平台比较完善之后，绝大部分Hack Week团队可以自己找到所需要的数据并根据文档使用这些数据，在四天内开发出一个完整的数据驱动型应用。（当然，完善的技术平台的支持也是必不可少的，例如在云原生的平台上，很多分布式开发的框架及应用的发布是非常容易实现的。）

经过Hack Week的锻炼之后，很多产品经理理解了整个数据体系的使用和探索方式，从而大大加快了开发新产品原型的速度。产品经理可以利用平台上提供的各种数据能力，像搭积木一样快速完成一个原型，并通过A/B测试和产品性能监控方面的框架快速推出和验证。例如，产品经理可以从大数据平台的数据流接口获取原始推文，从另一个数据流接口获取其定位信息，从一个文本分析接口获取其类型分析结果，从用户画像服务获取其作者的兴趣信息，从兴趣图谱服务获取相关的兴趣分类，然后通过实时流水线处理在附近地点有类似兴趣的用户群，并将结果推送给用户。如此复杂的流程，完全靠自己开发是非常费时费力的，但由于可以重用各种数据能力，就能以很小的代价快速完成原型。这样的迭代速度如果没有数据中台的支持，是不可想象的。

业务部门之间数据能力共享和复用的流程一定要根据企业的特定情况来制定。对于一些集团公司或者涉及较多线下业务的公司，由于业务模式差距较大，各个部门之间的数据能力共享和复用会比较复杂。例如，有线上网店、线下门店、多条业务线的企业在打通和复用数据时可能会比较困难。但是，在用户行为和业务流程越来越数字化的当下，如何实现线上线下数据的打通，赋能各个业务部门，充分发挥数据的价值，应该是每个企业必须考虑的问题。