国内的数据中台和BI软件为什么推起来比较困难？

之前接触了一些数据中台的项目，推进过程也都相对比较难，或者是很多咨询顾问文章里面提的数字化转型困难。

总结下来主要是有以下几个问题？

1）数据中台承载着数字化转型的任务，但是客户需要的不仅仅是转型需要的软件，而是一种相对整合服务、流程、数字化转型软件的一体的服务。举一个的数据中台的案例来讲，项目背景是集团型的制造业，需要进行数字化转型，首先请了麦肯锡做了咨询，据说当时做这个咨询，收费是很贵的，但是昂贵的咨询费用也不是这么轻易好拿的，签了对赌协议。麦肯锡做了咨询之后，不做转型落地，于是项目外包给外部的软件公司来做，实施过程就设计到业务指标化，指标落地，指标落地之后，客户 提了两个咨询需求：

1）指标如何落到个人，如何衡量业务的好坏，是否能给进一步做咨询，如何把BI指标落地到业务架构中，推行落地。

2）以及不同子公司的erp 系统不同，财务报表展示的内容都不相同，统计的数据也不同，是否能够做一个咨询，统一集团的财务系统。

这些问题已经远不是软件本身能够解决问题的，它设计到对业务的认识，对业务管理认识，打通跨业务部门的障碍认识，公司管理的认识，财务管理的认识。 所以数字化转型远远不是两个软件能解决。另外像麦肯锡这种咨询公司，他们卖的咨询服务一般是将好的公司的案例搬迁到其它公司，嫁接过程肯定会有一定不适应性，所以客户也会提到不落地，当然，像这种国际高端的咨询公司还承担着资源对接的服务。

从客户的角度来讲，这种需求是很合理的，数字化转型不能只体现在数据资产和BI分析，数据本身是需要带来业务的转变或者业务价值的体现。

2）数据中台中数据治理的内在构建。市面上大部分数据中台的数据治理功能，基本都包含，数据集成，数据开发，数据模型，数据规范，数据治理，数据资产，数据服务。可是单提供这些功能，远远解决不了企业的数据治理的问题。

例如：

过往的历史数据，如何在新的数据中台上展示元数据，数据地图，历史数据的迁移问题。总不能为了过去历史数据的元数据和数据地图将历史代码重新开发一遍？可以研究从代码获取元数据的方法，新上线数据中台，导数历史etl代码自动获取元数据的技术。

数据集成大部分厂家都做了各种数据库的，但是很多其它类型的数据来源，以及稳定性，正确性的监控如何保证？

数据模型构建的标准，怎么构建数据模型才可以让上层的业务使用的更好，数据模型的构建比较合理？最小的数据存储，最灵活的数据使用，最少的数据开发，最好的数据性能？这里设计到业务的理解，技术的理解之后才能构建好一个比较好的数据模型。

数据资产的目录，如何自动将数据资产以业务能够理解的形式展示，200张表获取还可以人工梳理，3000张表，10000张表，人工梳理数据资产目录就很耗时间，研究自动识别数据之间的关系，自动给数据资产进行标签化方法可以解决这个问题。

3）数据中台应对定制化需求，数据中台面对的客户在数字化进程中的层次不等，如何能够将未纳入it信息化层次的数据或者流程数据进入到数据中台也是对数据中台的一种考验，因此很多厂家在推广数据中台的同时会附带推低代码平台，帮助企业快速搭建常见的it信息化系统，在IT信息化，流程化之后，进而再将数据纳入数据中台之中会方便很多，当然还有很多数据填报系统可以解决数据来源问题，但是数据填报系统解决不了数据的正确性或者透明性问题。再比如数据质量的，一般从技术的角度可以定义完整性，唯一性，正确性，一致性，规范性，关联性等，但是从业务使用的角度，解决技术的数据质量依然无法使用，需要解决业务的数据质量才能是可以使用的数据，所以面对业务的数据质量的定义，这就要从很多方面考虑，通用性，灵活性方面考虑清洗加工程序的设计。

来源：数据研究0101

作者：ruby