数据管理质量怎样衡量

俗话讲“一波未平，一波又起”，在数据仓库的建设中，往往也是一期工程尚未了结，二期工程就开始动工了。那么，如何才能避免在一个不曾被证明可用的基础上搭建更为宏大的后期工程呢？要衡量“数据管理”的好坏需要一杆什么样的“秤”呢？

网界网：数据仓库项目一期接着一期地建，可衡量标准仍然是模糊的。——这是和圈内一些朋友交流他们所参与项目时经常听到的一点感触。

从建设进程上看，金融行业的经营分析系统也是从一期走到二期。一期主要的目标，是做数据整合和单一客户视图；二期的主要任务则是做分析应用。前者是一种后者的支撑，相当于是基础设施。可往往一期并没有被证明是可用的情况下，第二期就因为计划和各方的压力而开展起来。事实上，这里存在一个关键问题就是，如何度量第一期项目完成的好坏？

不能度量，是因为缺乏明确的项目目标。不能度量，也就无法分工细分。数据管理这种项目似乎只能作为项目大锅饭的一部分，很难作为一个单独的项目来进行，而且通常还是个吃力不讨好的部分。它通常要拿具体的应用来衡量它，比如，用来做哪些报表、哪些主题、哪些专题应用等等，来衡量后台的数据仓库是否足够强大。

在很多朋友的项目中，就存在这样的问题。衡量数据整合的效果，只能用单一客户视图这项应用来衡量。如果这点做到了，就基本上认同一期成果。即便数据整合做得确实有些缺陷，也可以放到二期再慢慢补充。实际上，如果仅仅是为了满足单一客户视图，其实根本没有必要去建数据仓库。但这样哪行呢？领导知道了，肯定又不同意，“那不行，数据仓库还是得建，要为日后打基础嘛"。这真是一件矛盾的事情，而且，一个项目最怕的一点不就是目标不明确吗？

因此，笔者就有个设想，是否能够为“数据管理”这件事建立一套度量其好坏的参考规格？此处，我更愿意将数据整合扩大一层含义叫做数据管理，它的目标是为了让企业分散的、凌乱的、异构的数据变成一种可管理状态，就像要通过ERP、CRM将企业中资源、客户变成可管理一样。后者为了能够提高资源利用率、客户服务，前者也是如此，要提高数据的利用率，从中挖掘金子。

要达到这种可管理状态，数据整合只是其中的一步，此外还有数据建模、元数据、数据质量等等，而数据整合也是一种泛称，可以是ETL，也可以是EAI、EII。当然，如果完整地考虑数据管理，可能还会包含数据安全、存储等方面，暂时那些还不在探讨范围之内。

大的行业做大项目，往往是要建立规范，其实也是在做建立标准、将目标度量化的尝试。然而，这确实是个难以平衡的事情，规定得太细了，基本上这份规范将仅供参考，因为根本不符合实际项目环境；定义得太粗放了，又失去规范的作用，大家还是各自按各自的做法。

例如电信行业经营分析规范中有个条款是规定数据源接口必须是文件接口的形式。这就是对过程的约束，做出规范当然有必要，但通过相关条款固定下来之后就基本成为一种强制性的东西。

这使得有些省分公司的项目在通过总部测试时就因为这一条不合格而未通过。其实，就这类规范本身来讲，如果已经经过证明是一种好方法时，确实可以将其推而广之。然而，在各项目建设中，总会有人怀疑这样的约束是否总是起到作用。比如以上面这个文件接口的约束为例，是在所有环境中都能适用的吗？事实是，如果省分公司数据量没到一定级别，提供综合营账系统和经营分析系统的可能就是同一家厂商，这种情况下还要做这种约束未必就是最好的方法了。

此外，这种参考规格之所以将过程和结果分开，就是要分而治之。譬如在规范中，对动态过程做规范，最好还是作为指导性的；而对静态结果定义可衡量的标准，可能更加明确一些。