数据治理介绍

数据治理(Data Governance)是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发起并推行,关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程。

国际数据管理协会(DAMA)给出的定义:数据治理是对数据资产管理行使权力和控制的活动集合。

国际数据治理研究所(DGI)给出的定义:数据治理是一个通过一系列信息相关的过程来实现决策权和职责分工的系统,这些过程按照达成共识的模型来执行,该模型描述了谁(Who)能根据什么信息,在什么时间(When)和情况(Where)下,用什么方法(How),采取什么行动(What)。

数据治理的最终目标是提升数据的价值,数据治理非常必要,是企业实现数字战略的基础,它是一个管理体系,包括组织、制度、流程、工具

数据治理内容

以企业财务管理为例,会计负责管理企业的金融资产,遵守相关制度和规定,同时接受审计员的监督;审计员负责监管金融资产的管理活动。数据治理扮演的角色与审计员类似,其作用就是确保企业的数据资产得到正确有效的管理。

由于切入视角和侧重点不同,业界给出的数据治理定义已经不下几十种,到目前为止还未形成一个统一标准的定义。

ITSS WG1认为数据治理包含以下几方面内容

(1)确保信息利益相关者的需要评估,以达成一致的企业目标,这些企业目标需要通过对信息资源的获取和管理实现;

(2)确保有效助力业务的决策机制和方向;

(3)确保绩效和合规进行监督。

数据治理过程

从范围来讲,数据治理涵盖了从前端事务处理系统、后端业务数据库到终端的数据分析,从源头到终端再回到源头形成一个闭环负反馈系统(控制理论中趋稳的系统)。从目的来讲,数据治理就是要对数据的获取、处理、使用进行监管(监管就是我们在执行层面对信息系统的负反馈),而监管的职能主要通过以下五个方面的执行力来保证——发现、监督、控制、沟通、整合。

数据治理类型

应对型治理

应对型数据治理是指通过客户关系管理(CRM)等“前台”应用程序和诸如企业资源规划(ERP)等“后台”应用程序授权主数据,例如客户、产品、供应商、员工等。然后,数据移动工具将最新的或更新的主数据移动到多领域MDM系统中。它整理、匹配和合并数据,以创建或更新“黄金记录”,然后同步回原始系统、其它企业应用程序以及数据仓库或商业智能分析系统

缺点:

批量集成和应对型数据治理方法引入的时间延迟可能导致业务部门继续操作重复、不完整且不精确的主数据。因此,这会降低多领域MDM方案实现在正确的时间向正确的人员提供正确数据这一预期业务目标的能力。在期望被设定为数据将变得干净、精确且及时之后,批量集成引入的时间延迟让人感到沮丧。应对型数据治理(下游数据管理员小组负责整理、去重复、纠正和完成关键主数据)可能导致让人认为“数据治理官僚化”。

应对型数据治理还会导致最终用户将数据管理团队看作“数据质量警察”,并产生相应的官僚化和延迟以及主数据仍然不干净的负面认识。这还将使得MDM方案更难实现它的所有预期优势,并可能导致更高的数据管理总成本。此方法的风险是组织可能以“两个领域中的最差”而告终,至少部分上如此–—已在MDM方案中投资,但是只能实现一些潜在优势,即在整个企业内获得干净、精确、及时以及一致的主数据。

改进方法:

有三个方法可超越应对型数据治理。

1、用户将数据直接输入到多领域MDM系统中:用户使用界面友好的前端将数据直接输入到多领域MDM系统中,但是他们的新记录和现有记录的更新留在暂存区域或保留区域,直到数据管理员审核和认证为止。这之后MDM系统才接受插入或更新,以便进行完整的整理、匹配、合并,并将“最佳记录”发布到企业的所有其他应用程序。此方法好过将一个完全不同的应用程序(例如CRM或ERP系统)作为“录入系统”,但是它仍然会出现延迟和效率低下。尽管存在这些缺点,使用暂存区域确实解决了大部分问题,例如不用强制执行重要属性的录入或在创建前不必进行彻底搜索。此外,由于我们并不受传统应用程序或现代CRM或ERP应用程序如何处理数据录入功能的影响,通过不对应对方法进行批量数据移动,我们还大大缩短了时间安排。

2、用户输入直接传送到多领域MDM系统中的数据:在外面输入新记录或更新,但是会立即传送到MDM系统,以便自动整理、匹配和合并。异常或例外传送到数据管理员的队列,几个管理员便可支持更多最终用户。这是第一个主动方法的改进,因为我们利用MDM系统的业务规则、数据整理和匹配功能,只要求管理员查看作为整理、匹配和合并流程的例外而弹出的插入或更新。

3、用户使用特定于数据治理的前端输入数据:第三个方法是允许最终用户直接录入到多领域MDM系统中,但是应使用专为主动数据治理方法而设计的前端。可专门为最终用户数据录入设定屏幕,您可利用功能齐全的MDM系统允许的自动化、数据整理、业务规则、搜索和匹配等所有功能。因此,不必首先将数据输入到MDM系统的暂存区域中,并且您不需要系统外的单独工作流应用程序。

主动型治理

主动数据治理的第一个优势是可在源头获得主数据。具有严格的“搜索后再创建”功能和强大的业务规则,确保关键字段填充经过批准的值列表或依据第三方数据验证过,新记录的初始质量级别将非常高。

主数据管理工作通常着重于数据质量的“使它干净”或“保持它干净”方面。

如果MDM系统中的数据质量初始级别非常高,并且如果您不会通过从CRM或ERP源系统中传入不精确、不完整或不一致的数据来连续污染系统,则主数据管理的“保持它干净”方面非常容易。

主动数据治理还可有效消除新主记录的初始录入和其认证以及通过中间件发布到企业其余领域之间的所有时间延迟。由用户友好的前端支持的主动数据治理可将数据直接录入到多领域 MDM 系统中,可应用所有典型的业务规则,以整理、匹配和合并数据。当初始数据录入经过整理、匹配和合并流程后,此方法还允许数据管理员通过企业总线将更新发布到组织的其它领域。

主动数据治理方法消除了“数据治理官僚化”这一认识,因为主数据的授权已推给上游的业务用户,使数据管理员处于很少被打扰的角色,他们将不会成为诸如订单管理或出具发票等关键业务流程的瓶颈。

销售和营销均受益,因为可更迅速且经济有效地完成营销活动,在启动活动之前无需前期数据纠正。财务上也受益,因为将一次性捕获新客户需要的所有数据元素,添加新客户的流程包括提取第三方内容并计算信贷限额,然后将该信息传回ERP系统。

没有直接访问MDM系统权限的客户服务代表通常必须搜索几个系统,找到他们需要的信息,从而采取措施。当通话中的客户没有耐心时,很难提供高级别的服务。当所有信息存储在MDM系统中并可通过有效、用户友好的前端进行访问时,客户服务代表将能够访问每个客户交互需要的所有数据,并能够在需要时授权新数据。

通过使MDM成为录入系统及记录系统,您能从本质上将数据维持在“零延迟”状态,它在这种状态下适合企业中的任何预期使用场景,同步到CRM和ERP系统的数据的清洁性、精确性、时效性以及一致性应当处于最高级别。

应避免问题

关系管理

MDM应当成为不仅是主数据而且是主数据间的关系的记录系统。它成为全方位了解不同系统的数据如何互相关联的中心位置。例如,多领域MDM系统将来自订单管理系统的销售订单和应收账款中的发票关联在一起。这些关系或层次结构显示在与MDM系统数据直接交互的用户界面中。用户界面还可用于查看主数据间的关系并在MDM系统中直接编辑它们。因此,MDM还成为关系的录入系统。

历史记录

当您从诸如CRM系统等外部系统中接受新记录或更新后的记录时,可能会限制您跟踪该记录的历史记录,因为外部应用程序作出了一些限制。当MDM为录入系统和记录系统时,审计历史记录的复杂跟踪和数据的沿袭成为可能。随着时间的推移,它甚至可显示核心主记录的更改,按照各种用户和流程在动态时间视图中显示插入和更新,可跟踪和显示每个属性中的每个更改。工作流使用可配置的前端可设计和执行基本工作流功能,因此最终用户可输入新主记录。但是,这些新记录可能需要数据管理员的批准步骤,然后才能将它们完全接受到多领域MDM系统中并发布到企业的其它领域。另外一个工作流应用程序在数据管理员的任务队列中。匹配或自动合并重复记录遇到的例外传送到相应的数据管理员。高级功能允许将问题提交给相应的人员,当用户在休假时可自动重新传送给后备人员。通过直接查看特定工作流步骤和这些流程的经过时间,减少了花费在查询新记录或更改后的记录状态的时间。

安全性

用户界面应当是可配置的,并且不同的工作角色具有不同的访问和许可级别。帮助数据管理员解决差异的一些数据元素可能不适合企业中的每个人查看。此外,即使在一个工作角色内,例如数据管理员,您可能需要不同的安全性级别,同时更高级别的人员能够对更广泛的记录集执行更多操作。而且,您可能需要分离访问权限,例如德国的数据管理员不能查看法国客户记录。

使用MDM外部的CRM或ERP系统作为录入系统时,该应用程序的安全模型可能会在谁有权对哪些记录进行哪些操作方面强加一些限制。将主记录的录入和维护直接移到多领域MDM系统之后,您可更加详细地控制数据的安全性,可具体到每个属性或字段级别。

最适合领域

什么因素阻止公司采用主动数据治理方法?总的来说,问题在于它们在数据治理成熟度等级中处于什么位置。一家公司很难从成熟度模型的最左侧——它们在其中没有中央多领域MDM系统并且没有数据治理组织或流程——直接跳到该等级的最右侧,它们在其中拥有强大的数据治理流程外加最新MDM系统和集成架构。通常,随着时间的推移,组织会改进它们的数据治理方法。例如,当初始MDM系统开启并运行之后,一些预期的优势需要较长时间才能实现,或应对方法的局限性变得显而易见,您可计划以便在原始源系统中取消授权记录的功能,并将该功能直接迁移到MDM系统中。

升级公司的集成或中间件功能(例如,添加一个能处理实时更新的集成工具)之后,可切换到主动数据治理方法,或作为现有CRM或ERP系统重大升级的一部分,因为这可能是引进需要的业务流程变更的最佳时机。

何时从“应对型”迁移为“主动型”?

度量标准将推动业务案例从应对型数据治理迁移到主动数据治理。

问您自己以下问题,并尝试量化时间、精力和费用投资方面的答案:

· 吸纳一个新客户需要多长时间?

· 涉及多少个不同步骤?

· 在普通新记录被接受到多领域MDM系统之前会接触它多少次?

· 由于这些源系统的局限性,仍在源系统中创建多少个重复记录(然后在MDM系统中合并)?

· 需要多少个数据管理员支持该企业?

· 主记录是否进入了“更改,改回”循环,因为两个不同的用户组试图强制执行两个不同的业务规则集?

· 主记录的重要方面是否因源系统和MDM系统之间的“裂缝而失败”?

· 维护各个源系统和MDM系统之间的集成的流程是否成为一种负担?

· 在CRM系统中输入新记录后,必须等待才能在ERP系统中变得可用,用户是否有所抱怨?

· 是否存在数据治理的资金问题,因为它被看做是管理费用或一种官僚作风?

回答这些问题之后,应当明显看出您是否将能够迁移到更主动的数据治理方法。您可详细计划迁移流程,将它设立为一个独立的项目或将它集成到另一个相关项目中。

何时开始

一些情况要求立即开始主动数据治理,例如当您获得多个CRM系统和ERP系统,它们要求与多领域MDM系统集成,以便让它们继续充当录入系统,或当您的当前源系统非常脆弱或很难维护或修改。

在这些情况下,要忍受困难并从一开始便为主动数据治理作出计划。一些组织拥有成千上万个直接在MDM系统中授权主数据的最终用户,并且有一个数据管理员团队支持他们、发现异常、解决低质量匹配、在需要时手动合并重复记录等等。另一种应用情况是当您发现自己最终会选择主动数据治理方法 — 何必再为建立源系统到多领域MDM系统的双向集成而争论?您或许不妨直接授权最终用户来编写主数据。

元数据管理

企业级数据管理软件提供商Informatica公司认为:数据治理成功的关键在于元数据管理,即赋予数据上下文和含义的参考框架。经过有效治理的元数据可提供数据流视图、影响分析的执行能力、通用业务词汇表以及其术语和定义的可问责性,最终提供用于满足合规性的审计跟踪。元数据管理成为一项重要功能,让IT部门得以监视复杂数据集成环境中的变化,同时交付可信、安全的数据。因此,良好的元数据管理工具在全局数据治理中起到了核心作用。

作用及其管理

Informatica将数据治理定义为“在组织范围内,对流程、政策、标准、技术和人员进行职能协调和定义来将数据作为公司资产管理,从而实现对准确、一致、安全且及时的数据的可用性管理和可控增长,以此制定更好的业务决策,降低风险并改善业务流程”。

数据治理着重于交付可信、安全的信息,为制定明智的业务决策、有效的业务流程并优化利益相关方交互提供支持。因此,数据治理本身并非是结果,而仅仅是方法:即通过数据治理来支持最关键的业务目标。

定义

元数据为数据提供了一个参考框架。Forrester Research将元数据定义为“用于描述数据、内容、业务流程、服务、业务规则以及组织信息系统的支持政策或为其提供上下文的信息”。譬如,苹果公司旗下的App Store在网上销售软件应用程序。在此情况下的数据是应用程序。元数据则是关于这些应用程序的信息,包括应用程序描述、价格、用户评级、评论和开发公司。

重要性

正如某家大型银行的高管所言:“如果没有数据治理,任何元数据管理方案注定会失败。”元数据管理可作为一项重要功能,让IT部门得以管理复杂数据集成环境中的变化,同时交付可信、安全的数据。当业务利益相关方参与这一进程并接受对数据参考框架的责任,其优势将变得更有说服力。此时,企业就能将业务元数据与基层的技术元数据进行关联,为全公司范围内的协作提供词汇表和背景资料。

例如,当业务用户要求其在IT部门的搭档在报告或分析中显示“净收入”,就无需再提问“哪种净收入——财务、销售还是市场营销?”除提供其他优势外,良好的元数据管理还可通过免除此类重要问题,促进数据治理:

· 这个业务术语的含义是什么?

· 在(几个相似的)业务术语中应当使用哪一个?

· 该术语的来源是什么?

· 该数据从数据源转移到目标时是如何进行转换的?

· 由谁负责该术语的定义、记录和管理?

· 谁修改过该术语?如何及何时进行修改?

· 哪些政策和规则适用于该术语?

· 修改环境中的某一特定数据对象会对其他数据对象产生哪些影响?

· 在不对可能使用相同数据对象的其他报告和分析造成影响的前提下,需要多长时间来实施环境变更?

驱动因素

一系列公司方案推动了数据治理的进展,也由此带动了元数据管理。这些方案包括:

· 通用业务词汇表(简单的数据管理)。这种“小规模试水”方法着重于某一特定问题或业务部门的通用业务词汇表。

· 全面数据治理(或数据管理策略)。这是一种更近似由上至下的方式,通常用于涉及企业内一系列业务部门的较大规模计划,并以按多个阶段(如果不是更长时间)进行管理的计划中的多个商机为目标。

· 合规。此类方案的推动因素是为遵守国际、国家、当地或行业法规的需求。合规——通常由一个治理、风险与合规性(GRC)职能部门进行管理,显然与数据治理唇齿相依。在发现、分析和记录企业的多项内部数据治理要求的同时,还必须与适用外部法规的相关特定要求进行统筹协调。其中部分示例包括:

· 银行业:Basel II、Basel III、多德弗兰克法案(Dodd Frank)、洗钱法案

· 保险业:偿付能力监管标准II(Solvency II)

· 医疗保健:HITECH Act、HIPAA

· 一般金融服务:萨班斯—奥克斯利法案

· 元数据管理。这是更上一层楼的做法,将元数据管理和数据治理作为“最佳实践”与各个新的业务方案挂钩。该方案对业务案例和项目范围进行定义。在多家未能成功实施较大型数据治理方案的公司中,这一方法则取得了成功。

大数据与治理

几乎所有企业都面临着管理数据量、速度和种类的挑战。Hadoop/MapReduce技术在复杂数据分析能力以及按相对低廉的成本实现最大数据扩展性方面提供了一些有趣的优势。Hadoop在不久的将来取代关系性DBMS的可能性不大,这两项技术更有可能并存,因为它们各有独到之处。虽然用于管理和分析数据的技术可能不同,元数据管理和数据治理的目标应始终保持不变:为支持良好的业务决策提供可信、及时且相关的信息。不存在所谓的“大数据治理”或“大数据元数据管理”——相反,这是一个将全局企业数据治理和元数据管理活动加以扩展来包容全新数据类型和数据源的问题。

Hadoop带来的挑战之一就是元数据管理。如果没有良好的元数据管理和数据治理,Hadoop将会缺乏透明度、可审计性以及数据的标准化与重复利用能力。企业仍将需要对数据相关关键信息的可见性,例如其来源、质量和所有权,否则就必须承受Hadoop变成环境内的又一个数据孤岛的风险。在该领域涌现的HCatalog和Hive/HiveQL等新技术将使得从非结构化和半结构化数据中收集元数据变得更加简易,从而实现Hadoop上的数据沿袭。这些功能对于将Hadoop集成入总体数据集成框架,以防止大数据在企业中遭到孤立隔绝,可如同任何其他数据源一样进行治理至关重要。

数据治理方案

有关数据治理的问题并不能在企业的单一部门得到解决。这需要IT与业务部门进行协作,而且必须始终如一地进行协作,以改善数据的可靠性和质量,从而为关键业务方案提供支持,并确保遵守法规。Informatica能够提供企业级数据治理解决方案,该解决方案可以在本地或云中使用,在传统数据或大数据中均有使用案例,可以满足业务和IT部门的需求。

Informatica可提供功能齐全而又稳健可靠的数据治理解决方案,具备交付可信、安全的数据和启动成功的元数据管理方案所需的全部精确功能。Informatica Axon提供端到端智能数据治理解决方案,以整体、协作的方法将员工、流程和系统流畅融合,从而实现战略业务成果。Axon Data Governance作为协作中心,为成功实施数据治理计划提供支持。

数据治理模型

ITSS WG1发布的白皮书表明

数据治理模型包括三个框架:范围、促成因素和执行及评估。他们每个方面都包含许多组件来进行展示和描述它们是如何工作的。该框架显示数据治理内部的逻辑关系。范围展示了我们应该关注什么,促成因素展示了数据治理的推动因素,执行和评估展示了如何实现治理的方法。该DG模型可以通过三个框架帮助我们理解数据治理。

数据治理的范围包括四个层次的内容。首先,应该有一个治理要素负责管理其它管理要素,保证治理与管理的一致性。其次,下面的三个层次分别列示了需要治理的数据管理要素:

其中价值创造层列示了通过数据治理所创造的价值服务;

价值保证层描述了一个组织治理数据时重要保证服务;

基础数据服务层描述了一个数据治理的基础数据服务。

数据治理工具

数据治理工作需要使用到哪些技术和工具?

引用了国内某一数据服务厂商的数据治理工具来简述一下。

元数据管理:包括元数据采集、血缘分析、影响分析等功能

数据标准管理:包括标准定义、标准查询、标准发布等功能

数据质量管理:包括质量规则定义、质量检查、质量报告等功能

数据集成管理:包括数据处理、数据加工、数据汇集等功能

数据资产管理:包括数据资产编目、数据资产服务、数据资产审批等功能

数据安全管理:包括数据权限管理、数据脱敏、数据加密等功能

数据生命周期管理:包括数据归档、数据销毁等功能

主数据管理:包括主数据申请、主数据发布、主数据分发等功能

转自:百度百科-验证

猜你喜欢

转载自blog.csdn.net/fuhanghang/article/details/132468098