业务系统的数据资产管理为什么这么难？

如果你做过BI或大数据，一定会接触数据资产管理的一些概念，比如元数据，数据字典，血统分析等等，但你会发现，要做好大数据平台的数据资产管理并不容易，比如数据字典的维护，为什么？

我们可以有一堆的理由，比如战略问题、业务问题、流程问题、机制问题、平台问题，人力资源问题等等，但假如这些问题都解决了，是否意味着你的数据字典就可用了呢？

也不是。

为什么呢？

因为大数据平台的数据来自于各个外部业务系统（上游系统），其数据字典的质量是受到上游系统约束的，而一般业务系统的数据资产变更规范性是比较差的，比如没有专门的数据管理系统来进行管理，究其原因主要有以下三点：

一是管理难度高，很多企业业务系统会比较多，各类系统的开发流程很多还不一样，比如来自于各个合作伙伴，要统一数据资产管理的标准非常困难，流程的复杂性导致统一数据管理平台的建设门槛也很高，商用的数据管理平台（比如元数据管理）大多是无法适应这种复杂的场景的，而大数据平台天然的集约型使得数据管理更可能成功。

二是驱动力不够，业务系统在开始建设的时候，关注的是功能的快速实现，很少有人能预见到诸如数据资产管理这种非功能性的需求，而要对已经建成的业务系统再重新梳理数据资产进行管理，则显得困难重重。

三是效益不明显，虽然大家都开始认识到数据资产管理的重要性，但重要而不紧急的事情总是很难提上日程，短期内数据资产管理的规范性跟开发的灵活性一定程度上还是冲突的，似乎从线下文档或开发人员口中获取信息也不是难事，但这个隐性的管理成本其实很高，等到系统要重构或大版本升级的时候会发现系统变得好陌生。

那么，业务系统的数据资产要不要系统化的自动管理呢？

答案是不一定，这个依赖当前业务系统的规模和成熟度，一个判定标准是当企业的IT要考虑中台战略的时候，也许数据资产管理也要提上日程，因为中台意味着沉淀和复用，而数据知识非常需要沉淀。

对于拥有大数据的企业来讲，高效使用数据的一个前提是理解数据资产的准确含义，比如背景、命名、释义及枚举值等等，而业务系统是数据产生的源头，理应承担起数据资产管理的重任，比如确保数据资产的质量，数据资产变更能自动提醒等等，其不仅要考虑自身利益，更应站在企业的全局角度看待这个问题，这也符合第一性原理，下游系统的数据资产管理管的再好，巧妇也难为无米之炊，上游垃圾进，下游也是垃圾出。

那么，业务系统的数据资产管理要怎么做呢？

除了传统的元数据管理那套理论，这里再给出三点建议：

首先，在策略层面，需要业务系统对于数据资产管理能有足够的重视，这是第一要务，大家会问投入那么大的代价去搞这个体系到底有没有价值？

的确在前期看不清的情况下，没必要毕其功于一役，因此需要找到好的场景切入点，比如存量中找个核心的系统进行试点，也可以只针对新增系统进行尝试。

其次，在方法层面，不建议采取后向的方式，比如事后补录数据字典，这种方式往往导致与生产系统的严重不一致，最终积重难返，要从数据资产产生的源头进行管控，即需要从数据库接入、开发到上线的整个流程进行管控，对于流程中涉及的任何数据资产管理的操作进行规范，比如数据库新建、建表，变更等等。

数据资产管理需要跟企业的整个数据产生流程无缝衔接，比如不按照规范进行数据资产录入变更，业务系统就不能上线，要有这种壮志断腕的决心，否则就不建议做。

下面笔者列出了业务系统数据资产管理流程的一个示意，这里涉及四个关键角色：

1、资产接入责任方：负责及时对数据源进行管理，比如新增数据库和用户，并将其接入到数据资产管理平台

2、资产开发责任方：依托数据资产管理平台按照资产管理的规范进行建表等操作，确保数据资产的质量，比如对表，字段解释清楚含义

3、资产维护责任方：负责资产上线发布管理，对数据资产管理平台与生产系统的资产进行比对，督促资产开发责任方进行资产修复

4、资产总体管理责任人方：负责整个企业数据资产的管理，包括数据资产管理平台的建设，数据资产管理规范的建立，数据资产的跟踪及质量通报、跨专业协调解决等。

最后，在系统层面，要打破专业、上下游系统的边界，构建一个企业级的数据资产管理平台，实现对各类业务系统、大数据平台及相关BI系统的数据资产的统一管理，其不仅要包括传统的元数据管理等功能，更要包括开发管理、流程管理等众多功能，从而适应企业特定的数据资产管理规范要求，一般来讲，不要奢望让企业的业务流程去适应系统，数据资产管理系统一定要与时俱进。