- 数据分析
- 数据治理
- 产品解决方案
- 行业解决方案
- 案例
- 数据资产入表
- 赋能中心
- 伙伴
- 关于
时间：2023-10-27来源：互联网浏览数：67次
首先，我们要明白什么是数据标准概念，根据中国通信院的定义：数据标准，是指保障数据的内外部使用与交换的一致性和准确性的规范性约束。我们可以简单理解，数据标准，就是组织内部各个部门，各个数据相关人，共同使用的一个语言，达成的一个共识。比如一个部门内部在开会，有人说方言，有人说英语，有人说普通话，大家由于语言不一致，导致沟通费时费力。而如果制定统一的标准，比如统一使用普通话，那么沟通会顺畅很多。秦始皇统一六国之后，要求国内统一文字，货币，度量衡，本质就是制定社会的标准规范，目的是让社会能够更加高效运转。所以，对于企业来说，数据标准，为业务运营和管理决策提供相应的保障。如果没有标准，那么企业的运营管理将会混乱不堪。
很多组织在发展初期，因为数据量不足，导致数据标准缺乏整体规划，等组织发展壮大，发现各个部门的各个系统由不同厂商和商品搭建，导致数据共享困难，理解歧义，无法有效分析。组织，通常因为没有制定严格的数据标准，管理不善出现以下3种问题：
（1）数据共享难以实现由于各个系统的数据存储结构不一致，分布在多个系统的不同数据，没有统一的标准，无法关联整合和分析，影响不同系统之间的数据共享。比如一家大型企业，老部门使用老的A系统，新部门使用新的B系统，不同系统的存储结构不同，导致数据共享困难。
（2）数据名称，标准不规范，语义不清没有数据标准，不同系统对同一种数据，有不同的命名，业务含义，取值范围，容易造成同义不同名，同名不同义，让数据使用者产生误解的情况。比如同一银行的不同网点，有的系统把客户叫做用户，有的把客户叫做客户，有的把客户叫做开卡客户，指的都是同一含义，但因没有数据标准，导致有不同名称，让业务数据统计分析，部门之间沟通理解费时费力。
（3）数据理解沟通成本高数据没有统一规范和标准，对于同一数据，不同人员的理解不一致，导致沟通交流成本增加，降低企业组织内部的运转效率。比如同一家公司的北京和武汉业务部门，北京部门把消费金额超过10万的客户设定为vip客户，武汉部门把消费超过5万的设定为vip客户。两个部门对vip客户的理解不一致，也导致总部系统管理分析用户数据混乱，无法对用户进行系统归类运营。
在企业日常管理和业务发展中，我们一般会从业务，技术，管理维度去分析和拆解数据标准。
（1）业务标准规范业务标准规范，一般包括业务的定义，标准的名称，标准的分类等。比如企业的CRM系统，要判断客户是否为老客户，我们要通过用户消费金额，消费频率，消费日期等维度做判断，这个维度就是数据判断标准。对于业务人员而言，数据标准化建设，可以提升业务的规范性，提升自己的工作效率；同时，保障了数据含义的一致性，降低了沟通成本，给业务的数据分析，挖掘，信息共享提供了便利。
（2）技术标准规范技术标准规范，是从技术角度，看待数据标准包括了数据的类型，长度，格式，编码规则等。比如企业员工要在公司系统填写客户信息，那么客户的姓名，手机号这些数据，都需要设定相应类型，长度规范，如果你把姓名输入手机号框，系统就会显示错误。对于技术人员来说，有了数据标准规范，工作效率可以大幅度提升，降低系统的出错率，有助于提升数据质量。
（3）管理标准规范管理标准规范，是从管理角度，看待数据标准。比如数据标准的管理者是谁，如何增添，如何删减，访问标准条件等，都是一个数据规范要求。对于管理人员来说，数据标准建设，保证了数据的完整，准确，为数据安全，经营决策都提供了支持和保障。
国外数据标准化工作起步较早，不少国际大型企业已将数据当作企业的重要资产来对待，其中大部分企业均以数据标准为核心，确保数据标准能够融入企业的每个业务环节中。 但国内企业大多数系统的建设都是直接依据业务需求建立，并没有一个整体的规划，另外不同系统的建设厂商可能也不一样，所以不同系统之间数据的不一致性难以避免，究其根源，还是没有一套统一的数据标准来进行约束。企业在对数据的使用过程中，出现的很多数据问题，都是由于缺乏标准约束和整体规划设计造成的，如下：
数据存储结构不一致，调用多系统的数据时，由于某些数据在不同系统中数据存储结构不同，导致数据无法直接关联，影响不同系统之间的数据共享。
数据定义不一致，不同系统对数据的命名、业务含义、取值范围等定义不同，比如同名不同义、同义不同名等
数据理解不一致，不同人员对数据的理解不一致，导致在数据使用时浪费很多沟通时间。
数据来源不一致，数据存在多个来源，在数据使用时，不清楚应该取哪个系统的数据。
通过数据标准的建设，可消除数据跨系统的非一致性，从根源上解决数据定义和使用的不一致问题，为企业数据建设带来诸多好处：
数据标准的统一制定与管理，可保证数据定义和使用的一致性，促进企业级单一数据视图的形成，促进信息资源共享。
通过评估已有系统标准建设情况，可及时发现现有系统标准问题，支撑系统改造，减少数据转换，促进系统集成，提高数据质量。
数据标准可作为新建系统参考依据，为企业系统建设整体规划设计打好基础，减少系统建设工作量，保障新建系统完全符合标准。
同时，数据标准建设也为企业各类人员提供相应的支撑：
对业务人员而言，数据标准建设可提升业务规范性，保障人员对数据业务含义理解一致，支撑业务数据分析挖掘以及信息共享；
对技术人员而言，有数据标准作为支撑，可提升系统实施工作效率，保障系统建设符合规范，同时降低出错几率，提升数据质量；
对管理人员而言，数据标准建设可提供更加完整、准确的数据，更好的支撑经营决策、精细化管理。
参考：什么是数据标准？如何做好数据标准管理落地？
根据笔者的经验与实践，数据标准的落标需要重点考虑三大问题：
问题1：什么数据需要制定哪些标准？
问题2：什么系统落什么标准？
问题3：什么人与什么时间执行？
如果这三个问题没有想清楚，基本数据标准的梳理会停留在Excel层面，标准的政策会停留在墙上，无法走入每个设计者的头脑和每个系统的每个字段。
我们先来说第一个问题，什么数据需要制定标准，首先我们回到数据标准所要解决问题的初衷，数据标准主要解决数据在共享，融合，汇集应用中的不一致问题。好的，那么我们看哪些数据会出现在这个这三个环节中，以及哪些容易出现问题。对于与一个企事业组织来说，按照价值链，一般关注三大要素：客户，产品，大运营。IBM和TD将银行业划分为九大概念数据，也是围绕客户与产品的大运营活动细分。那么有如下几类数据会在数据应用过程中，会更多出现融合和汇总的机会，需要格外注意。
第二个问题和第三个问题是实际工作中非常困扰的，落标的大多数困难与此有关，因此我将其放在一起来说明。一般我将系统与数据分列如下列表：
通过这个表格的内容，我们发现数据标准从源头落地，会减少数据的处理成本，提高数据应用的效益，缺点是对于存量系统和外购系统存在较大改动风险和成本。如果从数据的仓库层进行落标，比较容易着手处理，落标后的下游数据系统则自动统一数据标准，然而数仓层的报表应用与业务系统的报表存在口径不一致性在所难免，仍然需要源数据层进行必要调整。无论从哪一层入手，模型的优良设计环节都是必要条件，否则整个落标过程会没有抓手，流程也不顺畅。
无论是原系统数据还是数仓数据，都是不同的开发团队负责，遵循软件开发标准的流程包括设计，开发，测试，上线，维护等环节，因此我们需要在这个过程中，将数据标准这个优良的炮弹，送到最前线，同时，管理团队需要参与这个过程的关键节点中，这需要企业在数据管理上提高管理和执行水平。鉴于普通银行当前的数据基础水平，数据的落标同样受到人力和财力的制约。所以一个自动化水平非常高的落标方案是非常切合我国普通银行的发展阶段的。因此，本落标方案的关键思想是在开发阶段由模型设计人员进行落标，标准管理和架构管理人员进行评审和核准，同时，自动检测能力来提高执行水平和激励环节的落地。
《自动化落标方案》
这里主要是在系统的需求设计和准备过程中，我们对数据标准需要准备好一些前提条件：
· 标准的技术规范已经准备好数据标准已经具有详细的技术规范，包括物理数据类型，可以直接应用的物理层上，并已经准备好逻辑数据类型到不同数据库的类型映射。这里数据类型在DDM中是逻辑数据类型，具备自动类型转换能力。
· 标准的主题已经准备好标准的主题其实是标准的应用范围和检索目录，对于具备条件的银行应该设计出逻辑模型，对数据标准进行业务组织。这样在落标过程中，这是重要的选择依据。
· 标准已经权威发布标准已经经过讨论，进行了公开发布，具有流程上的正式性和权威性。
数据模型是一个更好的数据字典，其向上承接业务语义，向下实现物理数据，它不但包含了数据字典，更重要的是包含了业务的主题，业务主对象，数据关系，以及数据标准的映射。所以模型及其工具的运用不但是企业数据管理是否成熟的重要标志，也是数据标准落标的重要依托。不进行模型设计和管理，落标操作则事倍功半，因为失去了管理的最佳时机。通过创新一个模型工具，在开发阶段，自动管理数据字典和模型，实现下面三个落标操作。
建立标准和数据的映射
标准落地的属性继承
一般情况下，数据字段落地标准时要引用标准中上述内容，另还包含数据的标准代码，其中强制性一致的是标准中的技术规范。
物理字段的落地衍生
对于一个标准落地的物理字段，如果语义本质是相同的，并且业务规则没有变化，不过满足系统环境，而加上特定限定环境。比如“电话”在供应商的表里叫“供应商电话”，这是一种落地衍生情况，并不需要创建一个新的标准。如前一节所示有一些则需要新的标准或新的子类标准。
建立代码的标准引用
对字段中的数据类型的引用进行标准化，坚决杜绝Comment里手工写枚举代码的情况。
标准化命名
在模型的开发基本完成后，在系统的测试阶段，我们加入模型的评审环节，这个作为系统上线的前奏，避免上线前的修改造成时间紧张等情况。模型评审前需要创建模型基线，评审包含以下几个内容：标准的落标引用模型工具应该自动提供报告，重点检查是否有重要的标准没有引用和落地，通过自动化的工具，智能发现落标的潜在问题。
自定义标准与词典的评审和转化
DDM模型工具具备自定义数据标准和词典等能力，通过与开发团队评审，提高自定义标准的转化率，完善标准库。
元数据的充足率
模型工具应该自动提供报告，列出中文名称没有填写的字段。
其他模型质量
比如检查模型主题覆盖率等。
一般情况下，系统的上线过程需要一个更加标准的流程，提交设计，文档，测试报告，升级步骤等内容，有专业的团队和流程工具来审核。在这个过程中，我们并不主张此环节进行落标的核准，因为此环节已经太晚，我推荐在评审环节完成落标工作，在此环节中，只需要提交落标和模型报告作为过审文档。模型核准环节包含以下几个工作要做：模型生产库基线与封板根据评审时建立的模型分支，建立模型的生产库基线，并进行封板操作。
模型基线报告
提供模型标准数据字典，标准落标报告，模型质量报告。
对于已经发布的模型，随着进入维护期，某些升级的情况下，可能会有徒手修改库表结构的情况发生，为了保证模型与生产库的一致，在自动检测阶段，主要负责定期发现不一致的情况，并发出预警邮件，过程如下。
在实际落标过程中，需要新增或修改标准的情况是必然出现的。因此在设计阶段或者模型评审阶段，进行变更流程。
根据银行当前的组织结构，需要有建立“标准和架构组”，至少2人编制，可以是虚拟组织结构和兼职角色。 数据架构师（1人）：由企业资深（10+年数据开发经验）数据设计人员或管理人员担任，熟悉行业数据模型和企业主流业务逻辑模型，比较熟悉各系统模型情况。主要负责模型管控，落标评审，模型质量等工作。标准管理员（1人）：由高级（5+年数据管理经验）数据标准设计和管理人员担任，比较熟悉标准和企业业务逻辑模型。主要负责标准维护，标准评审，模型质量提高等工作。
存量系统的落标是很多企业进行标准化第一障碍，前面也进行了痛点分析，那么如何解决落标问题呢？我建议遵循下面方法。
存量系统先管理好数据模型和字典，这作为未来统一数据标准的基础。
摸清模型存量系统不符标准的情况，尤其是那些标准代码，编码规则，存储格式等严重影响数据指标和拉通汇集的情况。
根据非标问题的影响程度，制定未来的落标计划，选择合适的升级版本时机，进行逐项的落标。
未落标前，可以先落标ODS层或API层，这样可以纠正后期应用的标准化问题。
企业里存在多套标准是非常有可能的，比如一个客户类型的代码，原系统一套标准，数仓一套标准，报送EAST模型可能又是一套标准，那么怎么管理这多套标准呢？
建议对标准进行有效范围的定义，以明确每套标准的用途，比如原系统的标准作为地方标准，数仓的作为中央标准，EAST模型的标准作为对外标准。建立标准之间的映射管理，做好数据拉通的依据解决。这样设计标准的维护和变更就可以重点选择哪里进行新增，以及如何进行统一等。
上一篇：数据治理实施交付流程...
下一篇：数据治理与数据基础制度建设...
