【集思广益】数字化转型-如何更好的理解数据驱动？？？？

  今天准备继续跟大家聊下数据驱动方面的话题。。。

  对于数据驱动一定要理解为两个方面的内容，
，一个是数据驱动决策
，
，
，，这个是传统BI做的事情。。。一个是数据实时反哺业务
，，，
，数据驱动业务，
，这个是数字化转型下更加强调数据价值挖掘的重点。。。

  所以我今天谈的数据驱动，，
，更多的是在谈数据如何更好的驱动业务。。要明白数据驱动决策，
，，往往是形成了企业全局或业务域的KPI指标，，并提供各种维度分析工具，，，方便管理层发现问题，，并基于问题去改进已有的业务流程。。
。而数据驱动业务，，是通过数据加工处理建模后，，，
，形成的数据服务能力
，，
，需要在每一笔
，，，每一次业务交易中都要用到。
。

  虽然数据驱动决策和数据驱动业务，
，，，都存在底层数据存储汇总，
，
，数据的统一建模
，
，
，或者数据分析模型建设等。
。但是最大的区别就是数据服务要在业务协同中，，
，实时的使用，，，，来作为业务协同中的关键卡点，，，，或关键分析后数据的提供。。。。

  了解清楚这个后，，，
，我们再来看一些数据驱动业务的实际场景
。。

第一类
：模型支撑类数据驱动

如何理解这类数据驱动？
？

  简单来说就是我要采集集成各个业务系统源端的数据，，，，在进行数据清洗整合后，，，，还需要进行数据建模，，，特别是算法模型或分析预测模型。。
。。通过这个模型来实时的分析后预测业务。。

  1.生产质量缺陷预测

  在生产执行中，，，有一个重要场景就是缺陷预测。。。。但是对于每一次生产批次，，
，，所涉及到的原材料，，供应链，，
，，批次，，生产流水线工艺路线，，机台本身的配置参数都不同。。

  我如何基于这些配置参数快速的预测潜在可能的缺陷
？？？

  那么这个就是涉及到我首先需要基于生产历史形成的大数据进行采集整合，，，然后构建质量预测和控制模型。
。。基于这个模型我能够快速的预测缺陷分布情况等
。。

  但是这个能力不是给决策用，，，，而是在每一次生产执行中都需要实时使用这个能力
。
。。。那么我们就需要类似数据中台层提供这么一个缺陷预测的数据服务能力接口。。。我提供输入，
，，平台基于预测模型给出缺陷预测输出
。。输入和输出可能都很简单，，但是底层需要大量融合数据和算法模型，，，预测模型支撑
。。
。。

  2.电商推荐引擎

  这个例子我在讲数据驱动的时候经常讲到，，也是属于模型支撑类驱动
。。场景就是我们在电商平台浏览商品的时候，，，你会看到根据不同的时间段
，，不同类型的商品浏览，，，在浏览页面有一个你可能喜欢的商品列表都在不断的刷新。。。。

  这个就是我们经常谈到的电商基于客户画像后的动态推荐引擎
。。
。。这个也是需要采集大量的用户静态数据，，，用户动态行为数据，，用户社交数据，，，用户和商品关联数据等进行融合。
。。。基于我们的推荐引擎模型进行潜在喜好商品的预测，，，最终给出预测结果。。。

  这个底层很复杂
，，，也需要大量数据融合计算处理。。
。因此这个能力往往应该在数据中台
，，，以数据服务API接口方式提供给电商平台使用
。
。。

  这个同样道理，，，，接口的输入，，，，输出都很简单，，也需要在每一次业务，，包括到每一阶段后的操作浏览中实时调用接口。。真正的支撑当前业务流程。。

  当前浏览，
，，，个人历史画像，，，，底层产品关联都相关。
。。。不同浏览都需要动态出推荐的商品列表。
。。底层有模型，，底层采用大量数据分析计算后得出的预测模型。。。
。每次业务都是给出不同的结果。。

  3.客户信用评级

  对于客户信用评级，
，，
，传输偏数据驱动决策，，，，BI类的一个非实时结果。
。
。可能每周或每月才刷新一次。。。但是当前随着业务敏捷化和实时性要求，，
，，更加需要我们在每次业务开展的时候都能够动态的查询到客户信用评级。。。。以规避时间延迟下导致的不必要风险。。

  客户信用评级需要大量的客户静态数据，
，，，客户历史单据
，
，，客户动态数据，，，客户外部互联网采集数据等进行综合分析
。。。基于信用评级算法和模型快速的计算出客户信用等级。。

  这个事情往往也需要在数据中台做，，做好后开放为可以实时调研的数据服务API接口。。。。那么在面向客户的业务开展的时候，，，我们可以实时的调用API来获取客户信用，，，，基于不同的信用等级展开我后面写客户售前或销售策略。
。
。

  这个也是典型的数据模型驱动业务的场景。。这种数据服务需要和每一次业务流程，
，，细化到每一个业务操作协同，，同时又具备实时性访问要求。。
。对于上层应用来说也具备粗粒度特点，，，只属于输入客户编号，
，后台就返回客户信用等级
，，，，但是底层的模型计算，，，数据融合往往是很复杂的。
。

  4. 保单费率计算

  这个是保险行业常见的一个数据驱动场景。。
。即客户投保的时候快速计算保单费率，，包括推荐相关的保险条目项
。。
。

  其底层仍然是大量数据采集和计算分析，，
，涉及到类似客户的静态数据，，行为数据，，历史出险记录，
，，同类型保单的赔付情况请多类数据融合分析。。。然后再采用保险底层的的精算模型
，，，，最终得出最合适的保费测算。。。

  所以客服人员在处理每一个保单需求的时候，，都需要基于每一笔业务快速的提供合适的保单费率和投保组合。。这个不是用于决策支持
，，而是真正用于对当前业务的快速的支撑
。。。
。

第二类：数据支撑业务类数据驱动

  数据支撑简单来说就是提供整合后的共享数据给业务系统使用，
，，并不存在复杂的模型计算或预测，
，，，但是需要对原来多业务系统源数据进行整合。。
。
。

  1.技术拆分后的跨库查询数据组合提供

  在信息化发展早期的单体架构模式下，
，，实际这类场景并不突出。。。
。因为单个业务系统往往就能够提供上层业务应用功能需要的数据。。。但是在当前中台化和微服务拆分的新建设模式下，，原有的单体应用往往需要依赖底层多个业务能力中心提供的服务能力
。
。

  类似我原来谈到的供应链应用，，，，底层往往需要依赖供应商中心
，，，，物料中心，，订单中心多个微服务能力中心
。
。而是都是独立的数据库
。
。

  那么在这种场景下我需要查看一张完整的订单数据实际是相当麻烦的，，这个时候需要调用各个微服务中心多个API接口获取数据
，
，
，，然后在前台应用开发中对数据进行组合。
。。。

  但是对前台应用来说增加了复杂度
。。。对前台应用来说查询完整订单信息是很明确的业务需求，
，，不应该由于技术的拆分导致了需求变复杂。
。。。

  那么在这种情况下，，，，我们可以通过数据中台来提供订单查询数据服务能力，，，
，数据中台由于采集汇聚了所有数据，
，，，很容易通过简单的关联SQL来获取并提供完整的订单信息
。。这也是我经常说的跨微服务，，跨应用的组合关联数据提供，，可以数据中台来做，，，，可以作为实时数据服务提供。。
。

  2.数据计算加工后服务能力提供

  第二个常见的场景是业务系统往往需要一个经过数据加工和计算后的整合数据。。。类似宽表数据，，这里有计算，，，
，有数据项的扩展
。。

  类似项目管理系统需要查询所涉及到的合同的执行进度百分比
。。。
。进度百分比就是一个典型的宽表计算字段。
。。这个涉及到订单，
，合同，，，出入库，，转资，，，，验收付款等多个业务单据进行进行汇总计算
。。。
。那么这个数据加工和计算操作应该由数据中台的数据服务提供
。。。业务系统调用数据服务接口进行查询即可。。
。

  3.端到端业务监控

  对于端到端业务监控
，，，传统做法往往都是业务系统需要采集同步多个其它系统数据落地存储
，，，然后自己再加工计算。。。而新做法应该是数据中台提供实时查询的数据服务能力
。。。。

  类似采购执行跟踪，，，，实际采购执行已经在物流系统
，，
，工程建设系统，，，资产系统了。。那么这个时候执行跟踪最佳的做法应该是从数据中台一个地方查所有你需要的数据。
。。
。T+1准实时，，，基本已经满足需求。。

  括多年前我们做的企业内部的合同端到端状态跟踪系统，，，将整个合同分为了7个阶段，
，，30多个状态点。。对应每一个阶段和状态点，，，，都需要跟踪到具体的合同执行信息，，，审核信息，，接收信息，，，转资信息，，而这些信息往往来源于多个源端的业务系统。。

  那么这类信息提供最时候数据中台统一提供数据服务能力。
。

  而我们传统的做法往往是各个业务系统自己通过采集集成数据来解决这个问题。
。。这个就导致了各个业务系统又建设了一个小的BI系统的ODS库，，导致了同样的数据在多个业务系统中大量落地，，
，，导致进一步的数据不一致性和数据质量问题。。。。

第三类：数据驱动关键业务点管控

  最后一类在这里单独出来谈，，，就是数据驱动业务流程执行过程中的卡点
。。虽然叫数据驱动，，
，实际是底层形成的业务规则对业务流程执行进行控制。。

  典型的类似预算卡点
，，
，跨多数据源汇聚后形成的组合业务规则卡点。。。。

  在实际的业务单据流程执行中，，，一个业务流程是否能够向下一个阶段流转，，往往需要调研数据中台提供的规则校验类服务进行校验，，，只要校验通过后流程才能够继续朝下执行。
。

  也就是数据中台虽然采集汇聚了业务数据，，，，但是经过业务数据的加工和计算，，，，最终提供出来的是业务规则类服务接口
。。。。

  这类规则类服务接口也是在业务流程执行过程中，，根据不同的业务流程，
，，业务单据对象单独进行控制，
，需要实时计算后返回业务规则校验结果。。。业务系统本身无法做这个事的原因，，通用也是这个业务规则的计算往往涉及到采集汇聚多个业务数据加工计算才能够得出。。。。

第四类：数据驱动业务流程的执行

  在数字化时代我们很强调数据驱动，，，但是怎么样更好地理解数据驱动
。。。。我们可以简单理解一下，
，在你原来信息化时代的时候，，
，往往很多时候都首先是我们制定相应的流程规范和标准，，
，把它固化到相应的信息系统里面，，，然后是人执行相应的流程规范，，
，，执行完以后将相应的数据录入到系统，，，形成信息流，，最后信息流执行完了以后再沉淀相应的数据
，，，，最后才是通过数据去做相应的辅助的决策分析。。。

  所以说原来的线条往往是先有流程标准制度，，，
，再有人的执行，，人的执行再形成信息流
，，，，信息流最后再落地到数据，，这个是原来我们通常的一个做法。。。

  但是在数字化时代这个做法就会发生很大的一个变化。。。这个变化主要会体现在哪些地方呢
？？在数字化时代你会发现它整个的流向它是反着的。。。
。

  也就是说首先是在数字世界里面形成了相应的信息的规范和相应的数据，，
，通过数据和相应的调度规则
，，
，它自动的去产生信息流
，，然后通过信息流反向的推动人去执行。。。 比如说你简单的讲数据驱动都不太准确，
，，应该说是在数字化时代更多是数字驱动，，是数字化的世界驱动了现实中人的流程和人的作业。。。。

  举一个最最典型的例子就是我们的类似于滴滴，，曹操这一些打车平台，，，它更多的你可以看到我们实际网约车的司机，，他往往是一种被动的接受数字化平台，，给他的各种的单据，，给他的各种调度任务
，，
，他只需要去执行就可以了。。

  那对于传统供应链系统也一样的道理。。你原来往往是货物来了以后，，你自己要录一个入库单，，，然后去执行相应的提交审批操作。。。
。但是到了数字化后续的发展以后
，，你会发现你不需要去录入相应的入库单和出库单这种单据，，很可能是数字世界已经帮你形成了相应的单据，，，，你只需要按单据去执行相应的操作就可以了
。
。所以这个也是在数字化时代带来的第二个相当大的变化。。。。

  对于数据驱动业务流程
，，，可以理解为数据驱动在数字化转型下的一个终极目标
，，，这是让数据驱动走向自动化，，，智能化的关键
。。
。。

原创何明璐 转发自公众号人月聊IT