1.1 定义
数据是由特定的环境产生的，这些环境因素包括生产者，时间，系统等， 这就造成了同一个语义的数据，会有多种不同的定义方法，这给后期进行数据汇集和整合带来障碍，因此，数据处理的前奏就是数据标准化，数据标准作为一个统一的数据共识，在企业的标准化中起到重要作用。
数据标准一般包括下面几个，为了统一本文阅读共识，列出如下：
- 基础数据标准，这个标准是针对数据原始定义，一般面向原系统数据或ODS层数据。包括业务语义，管理标准，技术规范，质量要求等。
- 指标体系，这个标准针对衍生型数据，一般面向集市层的报表等计算型数据。
- 标准代码，这个具体指数据标准中的枚举值和语义，可以作为基础数据标准的一部分，数据标准维度也是大部分来源于此。
- 标准编码，这个特指主数据治理中的实体对象数据的唯一编码和规则，比如设备唯一编码。
- 业务术语词典， 这个指企业数据定义过程中，从业务名词到物理表和字段的标准化翻译的词根和词素。
- 其他规范，包括数据库设计规范，元数据规范，模型规范等，具体可以在其他治理活动下定义，也是广义数据数据标准的一部分。
一般情况下，本文所述的数据标准落标主要指：（1）基础标准落标 （3） 标准代码落标 （5） 命名标准落标。指标体系的落标因为在数据后期，是比较容易实现的，因此不在重点讨论中。标准编码则特定于主数据治理过程中实现，不在此赘述。
数据标准的落标意义在于，企业由此开始进行数据驱动文化，开始从源头进行数据的标准化生产，加速数据的融合与统一的效率，节省大量数据应用和处理的成本。
数据标准的落标程度可以分为基本拉通型落标和全局管控型落标。
基本拉通型落标是指设计的数据元素符合数据标准的基本语义和业务规则，物理定义符合技术规范，具体数据语义可以进行无规范的衍生。 落标范围重点是核心业务系统的核心标准和交叉标准，还有数据仓库系统的。这种类型适合中小银行的上手阶段，以及没有重大系统升级机会的系统，其核心目的是减少数据融合成本，加速数据消费的效力，适合进行数据化驱动转型的企业。
全局管控型落标是指设计的数据元素符合数据标准的基本语义和业务规则，物理定义符合技术规范，具体的物理数据语义需要进行有规范的衍生，数据质量需要落地为数据库约束或者质量验核规则。 落标范围是核心业务系统和重点业务系统，以及数据仓库等衍生系统。这种适合IT能力强，数据基础好的企业。其核心目标是掌控企业全局数据，做到数据快速迭代，适合致力于打造数据快速创新型企业。
数据在落标过程中是可以进行一定程度的数据语义衍生的，比如电话号码 衍生为供应商电话。如果衍生的字段有确实的细化语义，或者其他业务要求，就需要也有一些数据标准需要定义为子类标准或者同义标准。
子类标准
当一类数据标准有进行细化的必要，并带来特定的语义和业务规则，就需要在原有标准上进行衍生。比如“电话“衍生为”手机“和“座机“，这是因为这两类衍生标准带来不同的业务属性，不同的数据格式，以及不同质量检查规则。
也有一些可以不进行标准级别的衍生，比如“姓名“，具体语义的设计可能是“客户姓名”和“供应商姓名“，这两个衍生可以不作为子类标准制定，这是因为业务语义是因为数据所在的语义环境变化，本质并没有不同。
同义词
同一类语义标准，在不同的业务口径中或者不同的人群中，会有不同的名词，比如保单号和保单代码是同一语义的名词。这时候需要将两者定义为同义词，并在每一个定义时，标注清楚使用语境。
1.4 落标难点
我国银行业的数据治理已经开展十几年，在有数据监管驱动和自身数据价值挖掘的驱动下，大部分行已经进行了数据标准框架定义和梳理，发布了各个板块的数据标准指导文件，有的甚至落实了数据标准流程和人员角色。然而数据标准的落标在大部分普通银行仍然是个不是很理想。
现在数据标准梳理和发布是比较容易的事情，各咨询厂商手里也积攒了大量各个行积累的数据标准，可以比较全面的提交给各个银行。可是落标不理想的原因我认为有这么几个问题。
- 存量数据大，积重难返
根据破窗常理，没人在乎再多一块破窗户。数据业务系统绝大部分已经建设完成，木已成舟，不标准也没法修改了。
- 开发设计规范不重视
开发团队的责任和考核点主要是系统上线，支撑业务，在开发团队的很多人看来，数据标准化的设计是一个可选项，影响上线时间才是大事。
- 标准落标不方便，影响效率
我看过很多家咨询公司的数据标准，技术规范普遍缺失。这证明标准开始就没有认真考虑落标问题，这就造成落标很不方便，先在Excel里查找，再手工拷贝，再类型翻译，。。。，确实影响效率。
- 监管与激励缺失，落与不落都一样
现在的数据结构和字典中，落标与不落标是没有量化跟踪的，这直接造成激励与认责无法落地执行。
- 人力与关注点缺失，没人管
普通银行并不像四大行那样人财雄厚，数据治理工作普遍是3-4个人兼职完成，日常被大部分其他工作排满，不可能把这项工作量化起来，也无从着手。
2. 国内外落标案例简介
为了认真的研究这个命题，我们决定调查几个国内落标的典型案例，看看我们能从中学习点什么。调查从总体看思路，细节不符之处在所难免，望读者不吝指出共同完善。
建设银行从2014年新一代项目时，开始大力度的进行彻底的和全方位的数据标准落地工程。建行师从IBM的四层模型法，通过九大银行业概念设计了企业级逻辑模型。依托于此企业级逻辑模型，打造了企业级数据字典。通过设立数据标准处和架构处，进行了流程和规范管制，进行强力度的模型和数据的落标管理。
具体请看我画的一个示意图。
（建行落标示意图）
从示意图看出，建行采用了源头控制的方法，基于建行的得天独厚的逻辑模型优势，打造了一个企业级的数据字典，由于业务系统从C模型继承开发，所以存量问题基本得到解决。
从模型开发设计阶段开始，模型团队就要根据现有标准进行落标的设计，沟通方式可以是电话或邮件，通过长期工作，效率基本不影响开发进度。缺失的标准通过标准组来进行更改和维护。
测试阶段，需要提交数据字典映射到企业级数据字典，每一个新数据项的增加都可以说明这是或者不是标准，都会记录在案。
核检阶段，现在主要是送数过程中进行检查，不通过将不能向后台送数。近期要进行上线核检，提高落标的早期检查力度。
作为Erwin的开发者，在外企的数据管理领域工作多年，对国外数据管理有较多认识，接触过很多国外银行业客户，如SunTrust，苏格兰皇家银行，citibank等。 今年5月份有幸参加了国外的EDW大会。我发现了国外确实数据发展阶段与我国有很大不同。
国外普遍比较重视数据建模工作，业务系统成熟多年，数据的修改全部由模型工具控制。会有专业的建模师和架构师来贯彻落标工作。同时，模型工具也已经标准化和全局推广了，在EDW大会上很少听到由讨论落标的话题，在他们的意识里，落标已经固化在建模过程中完成，甚至元数据管理也较少话题，因为也已经成为广泛共识。相反，他们非常多的谈的是Business Glossary， 国内却很少提及。
总结一下，国外的系统建设期，因为在建模理论和系统化设计思维方面的优势，再加上企业管理制度的方面比较成熟，银行业的数据建模工具的使用率非常高，使得数据的早期落标得到较彻底的执行。同时，早期的数据标准问题也基本到现在有了成熟的解决路径。
3. 模型驱动的标准落标方案
3.1 落标关键点剖析
根据笔者的经验与实践，数据标准的落标需要重点考虑三大问题：
问题1. 什么数据需要制定哪些标准
问题2. 什么系统落什么标准
问题3. 什么人与什么时间执行
如果这三个问题没有想清楚，基本数据标准的梳理会停留在Excel层面，标准的政策会停留在墙上，无法走入每个设计者的头脑和每个系统的每个字段。
我们先来说第一个问题，什么数据需要制定标准，首先我们回到数据标准所要解决问题的初衷，数据标准主要解决数据在共享，融合，汇集应用中的不一致问题。好的，那么我们看哪些数据会出现在这个这三个环节中，以及哪些容易出现问题。对于与一个企事业组织来说，按照价值链，一般关注三大要素：客户，产品，大运营。IBM和TD将银行业划分为九大概念数据，也是围绕客户与产品的大运营活动细分。那么有如下几类数据会在数据应用过程中，会更多出现融合和汇总的机会，需要格外注意。
| 基础通用型数据 |
国家通用标准，行业通用标准，企业基础标准等 |
| 主数据类数据 |
客户,产品,渠道等主要经营数据 |
| 类型和维度类数据 |
分类码，标准码，维度码等 |
| 报送类数据 |
报送类模型和数据 |
第二个问题和第三个问题是实际工作中非常困扰的，落标的大多数困难与此有关，因此我将其放在一起来说明。一般我将系统与数据分列如下列表
| 系统 |
落标强度 |
剖析 |
负责人 |
时机选择 |
| 核心业务系统数据 |
强 |
核心系统存储了企业经营最核心的数据，数据标准可以从核心系统定义中梳理，核心系统的数据的标准化会直接影响下游系统，数据流动链很长而系统改动难。因此尽量促成“我就是标准“这件事 |
开发团队 或 套装开发商 |
1.建设期强落标 2.维护期谨慎落标 |
| 重要业务系统数据 |
中 |
重要系统存储了核心系统的补充数据，重点是标准要与核心对齐 |
开发团队 或 套装开发商 |
1.建设期强落标 2.维护期谨慎落标 |
| 一般系统数据 |
弱 |
一般系统适合采用拉通型落标，重点在一些核心数据引用和类型类数据 |
开发团队 或 套装开发商 |
1.建设期选择重点落标 2.维护期可以不落标 |
| 报送和对外共享数据 |
强 |
遵从报送标准，和共享标准 |
报送团队 |
遵从报送和共享标准 |
| DW初始汇集层 |
强 |
一般企业落标最容易着手之处，数据需要进行模型建模，汇集落标，需要进行ETL数据处理 |
数仓团队 |
尽早进行管控型强落标 |
| DW汇总层数据 |
强 |
如果没有初始汇集层，可以在此针对具体主题进行落标，需要进行ETL数据处理。 |
数仓团队 |
全局规划后，应用开发时 |
| Mart集市与报表数据 |
强 |
主要参照落标指标体系和维度体系，汇集落标，需要进行ETL数据处理 |
报表团队 |
每一次开发时 |
|
|
|
|
|
|
总结
通过这个表格的内容，我们发现数据标准从源头落地，会减少数据的处理成本，提高数据应用的效益，缺点是对于存量系统和外购系统存在较大改动风险和成本。如果从数据的仓库层进行落标，比较容易着手处理，落标后的下游数据系统则自动统一数据标准，然而数仓层的报表应用与业务系统的报表存在口径不一致性在所难免，仍然需要源数据层进行必要调整。
无论从哪一层入手，模型的优良设计环节都是必要条件，否则整个落标过程会没有抓手，流程也不顺畅。
Datablau简介
北京数语科技有限公司（以下简称“数语科技”）成立于2016年，是专注于数据治理领域的国内自主知识产权的专业软件产品提供商，主要业务是数据治理软件产品的研发与销售。数语科技的创始团队全部来自CA erwin，天然具有世界级水准的软件产品开发能力。创始人兼CEO王琤曾任职erwin全球研发总监，拥有超过十年以上数据建模和数据管理的从业经验。CTO朱金宝曾任职erwin首席架构师，先后服务多家全球知名企业，并曾全程参与中国建设银行数据治理项目，目前全面负责Datablau软件平台的研发工作和关键项目的实施工作。
数语科技根据DAMA理论和中国国情独立研发Datablau新一代数据治理平台，平台由Datablau DDM数据建模产品和Datablau DAM数据资产管理平台两大部分组成，全部拥有软件著作权和知识产权，一站式全面满足中国企业的数据治理需求。其中数据建模产品DDM是Datablau填补国内空白的重量级产品，帮助中国客户摆脱国外产品的垄断现状。
2018年，Datablau数据治理平台通过了中国信息通信研究院严格苛刻的产品评测并获得的“最佳大数据产品”奖。
DDM（Datablau Data Modeler）是国内首创的专业建模工具，是数据治理体系的重要组成部分。数据模型是“所有系统、文档和流程中包含的所有数据的语境。是生数据的知识。”换句话说，如果没有数据模型，组织IT系统中收集和存储的所有数据都会失去意义，也就没有业务价值。
- 更多了解我们
- 官网： www.datablau.cn
