首页 >>新闻中心

如何把握数据治理项目启动的最佳时机 2019-07-03

一、实施数据治理项目的原因

企业实施数据治理项目的原因是多样化的,根据目前国内企业数据治理现状归纳总结了一下,原因主要体现在以下三个方面:数据质量方面、数据应用方面及其它方面。

1、数据质量方面

1)数据不一致

企业早期没有进行统一规划设计,大部分信息系统是逐步迭代建设的,系统建设时间长短各异,各系统数据标准也不同。企业业务系统更关注业务层面,各个业务系统均有不同的侧重点,各类数据的属性信息设置和要求不统一。另外,由于各系统的相互独立使用,无法及时同步更新相关信息等各种原因造成各系统间的数据不一致,严重影响了各系统间的数据交互和统一识别,基础数据难以共享利用,数据的深层价值也难以体现。

2)数据不完整

由于企业信息系统的孤立使用,各个业务系统或模块按照各自的需要录入数据,没有统一的录入工具和数据出口,业务系统不需要的信息就不录,造成同样的数据在不同的系统有不同的属性信息,数据完整性无法得到保障。

3)数据不合规

没有统一的数据管理平台和数据源头,数据全生命周期管理不完整,同时企业各信息系统的数据录入环节过于简单且手工参与较多,就数据本身而言,缺少是否重复、合法、对错等校验环节,导致各个信息系统的数据不够准确,格式混乱,各类数据难以集成和统一,没有质量控制导致海量数据因质量过低而难以被利用,且没有相应的数据管理流程。

image.png

4)数据不可控

海量数据多头管理,缺少专门对数据管理进行监督和控制的组织。企业各单位和部门关注数据的角度不一样,缺少一个组织从全局的视角对数据进行管理,导致无法建立统一的数据管理标准、流程等,相应的数据管理制度、办法等无法得到落实。同时,企业基础数据质量考核体系也尚未建立,无法保障一系列数据标准、规范、制度、流程得到长效执行。

5)数据冗余

各个信息系统针对数据的标准规范不一、编码规则不一、校验标准不一,且部分业务系统针对数据的验证标准严重缺失,造成了企业顶层视角的数据出现“一物多码”、“一码多物”等现象。

2、数据应用方面

企业信息化建设到了一定程度,开始对数据进行相关的展示、分析、应用等,进一步提高数据对企业统计分析和决策支持的力度,但是由于前期没有进行顶层设计,在大量业务系统建设过程中没有同步进行数据治理,出现许多上述数据问题,导致数据质量不高,数据分析结果不准,数据应用效果不佳,无法为企业的高效经营管理提供数据支撑,此时企业考虑启动数据治理项目了。

企业用户即使知道自己业务所需要的是哪些数据,也不能便捷、自助、及时的获取数据,相反,由于没有统一的专业数据管理平台,获取数据需要导出、梳理、校验、排重、核对等漫长的过程,导致业务分析的需求难以被快速满足,而在当今大数据时代,业务追求的是针对某个业务问题的快速分析,这样漫长的需求响应时间是难以满足业务需求的。

很多大中型企业实施了商业智能(BI),即运用数据仓库技术、线上分析处理技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。而往往这些企业非常重视数据治理工作,因为数据治理、元数据管理及其中的数据标准化是实现商业智能的重要环节,如果数据不一致、数据质量达不到要求,是无法进行数据集成和整合的,也就无法进行数据分析和数据挖掘,更谈不上商业智能了,数据治理的重要性可见一斑。

3、其它方面

1)咨询规划

企业在开展信息化顶层规划设计时,咨询厂商会提出系统架构和数据架构等方面的建设内容,数据架构需求的提出预示着企业数据标准化落地专业数据管理平台的诉求应运而生,完成咨询规划设计后,可以启动数据治理项目了。

2)二次治理

有的企业在早期就已开展了数据治理工作,甚至也建设了专业的数据管理平台,但是随着时间的推移,各个系统间的交互越来越紧密,还是发现了大量的数据质量问题,借助目前的系统和手段无法得到明显改善,于是企业再次启动数据治理项目,进行二次治理。这种情况下,笔者建议企业应首先找出数据质量不高的原因所在,是管理平台功能不完善,或是数据标准执行不到位,或是数据运维体系不健全等,应从多个维度去全面评估,为后续的二次治理做好铺垫。

3)被动治理

受到上层集团领导、政府部门相关管理要求或是“大数据”“物联网”“人工智能”等前沿IT技术大环境的影响,企业被动开展数据治理工作。此时,作为企业来讲,应该冷静慎重,杜绝敷衍了事。笔者建议企业应从内部管理和业务发展的角度出发重新审视数据治理的重要性,数据治理不是简单的一蹴而就,应着重考虑数据治理成果的长效性和数据质量的持久性。

二、先上业务系统再进行数据治理的弊端

有的企业由于各种各样的原因,没有先行开展数据治理相关方面的工作,而是直接启动建设核心业务系统(如ERP、MES、PLM、SCM、CRM等),随着企业的逐渐发展,业务系统越来越臃肿,周边IT系统逐渐增多,集成逻辑愈发复杂,就会出现上文提到的各种数据问题,无法为现代企业数字化转型提供有力支撑。以ERP系统为例,先上业务系统再进行数据治理的弊端主要体现在以下几个方面。

核心业务系统实施时更多的是考虑业务的实现,忽略了数据本身的标准性和合规性,由于对基础数据治理的片面性和特定性认识,导致数据治理不彻底,产生很多“脏数据”,重码现象严重,一旦这些数据直接进入业务系统,随着系统应用逐渐深入,范围逐步扩大,对企业经营管理的影响也会越来越大。比如物资编码不规范,就会出现采购订单录入时不知该选哪个编码,仓库盘点出现账实不一、统计报表不准确等情况,业务系统的使用效果大打折扣。如果此时进行数据治理,一方面,由于基础数据牵扯的范围比较广,数据治理的工作量比较大,涉及企业的人、财、物管理,具有一定的风险;另一方面,为保证数据治理的效果,需要企业投入大量的人力和资金。比如数据标准要重新制定、数据需要清洗、系统集成架构和逻辑需要调整,笔者遇到很多企业多次反复使用“脏数据”,一物多码、一码多物的问题比较突出,导致后期数据清洗繁杂、难度大,以至于清洗周期一拖再拖,项目迟迟无法验收。所以在核心业务系统实施前进行彻底的数据治理就可以避免上述问题,减少重复劳动,提升管理效率。

很多企业使用业务系统落地各类数据编码的执行,由于业务系统缺乏对数据生成的有效监控、验证等,导致数据生成过程处于失控状态。有的业务系统上线运行前期制定了一些相关的管理制度和流程,但是长期的手工或非法执行,还是会出现书写错误、不规范等问题,最终导致重复编码无法得到有效控制,各种问题数据越积越多,不利于企业业务的高效运作。

如果核心业务系统运行一段时间后再实施数据治理,其实相当于重复一遍业务系统实施时的工作。此时需要重新规范数据标准并实现系统落地,重新进行数据清洗,重新搭建数据管理体系等,重复劳动,耗费资源。数据清洗后只能先实现重复数据的映射,然后逐步停用重复编码,导致数据冗余无法短期内消除,而且,需考虑对业务系统正常运行的影响。

三、数据治理项目启动的最佳时机

对于企业而言,有效的数据治理能推动IT部门和业务部门协作实现共同目标,促成企业各种业务功能的实现,是成功企业的“法宝”。当企业在数据管理方面存在上述问题,无法为高层领导分析决策提供基础数据支撑时,开展数据治理已经势在必行,而选择合适的时机启动数据治理项目就显得尤为重要。结合项目实施经验和标杆案例分析,笔者认为企业在核心业务系统(如ERP、MES、PLM、SCM、CRM等)上线前实施数据治理项目效果最佳。

一般来说,初始化数据的整理、数据编码及数据录入是建立核心业务系统的难点之一,正确按各类数据的编码原则进行编码定义,是数据编码具有唯一属性的重要依据。同时,数据整理与编码实施也是实现整个核心业务系统快捷运行的基础。

核心业务系统上线运行前,往往会进行统一的数据初始化工作,即把系统需要的各类数据按照系统模板的要求导入系统,保证系统的正常运行,支撑各项业务活动的开展。然而,在数据导入的过程中,经常会出现诸如数据不规范、必填项缺失、重码、非法取值等错误需要反复重新导入的情况,费时费力,增加人力成本,给业务系统的实施带来一定的影响。

如果在核心业务系统上线前开展数据治理相关工作,对企业各类核心业务实体数据的数据标准,编码规则,数据模型,标准数据库、数据管理制度、流程、工具等进行梳理和规范,实现企业内标准统一、数据同源、规范共享,并通过系统集成接口自动传输到核心业务系统,可短期内快速完成核心业务系统数据的初始化工作,缩短周期,提高效率,通过集成接口实现灵活的数据分发等操作,达到服务集中的目的,大大节省企业信息化建设投入成本。

举例企业常见的物资编码来说,核心业务系统实施厂商在对物资编码进行梳理时往往从业务系统使用的角度出发,比如常见的六角螺母,业务系统只需设置“名称-强度等级-直径”为编码属性即可,而数据治理项目的出发点是数据标准化,以及未来核心业务系统数据的应用、分析、决策等。物资数据标准化从物资分类、编码规则、描述模板、数据清洗、提报指南、维护细则、运维体系、管理制度等多个方面保证企业物资数据的准确性、唯一性和完整性,为核心业务系统物资数据的深入应用提供有力支撑。从物资数据标准化的维度分析,六角螺栓的描述模板如下表所示。

image.png

还是以ERP系统为例,系统上线前会对各类数据进行清洗,如物料、客户、供应商、银行、会计科目等,数据清洗工作繁琐、枯燥、量大,若仅仅靠人工识别整理清洗,数据质量不高,清洗周期也难以把控,而且这些基础数据进入ERP系统也会给后续的业务开展带来一定的影响。如果借用数据治理平台中专业的数据清洗工具来辅助开展清洗工作,可以实现清洗人员的合理分工,线上协作协同,减轻工作量,提高工作效率,在缩短周期的同时达到理想的数据清洗效果。清洗后,规范、标准、干净的数据进入系统可以提高ERP系统的实施效果,便于基础数据的统一管理和集中分发,进一步加强企业经营决策的数据支撑力度。另外,实施数据治理项目还可以节省ERP系统等的License数量,从而大幅节省企业资金的投入。

四、如何实施数据治理项目

数据治理是一个复杂的系统工程,涉及到企业和单位多个领域,既要做好顶层设计,又要解决好统一标准、统一流程、统一管理体系等问题,同时也要解决好数据采集、数据清洗、数据对接和应用集成等相关问题。

数据治理实施要点主要包含数据规划、制定数据标准、整理数据、搭建数据管理工具、构建运维体系及推广贯标六大部分,其中数据规划是纲领、制定数据标准是基础、整理数据是过程、搭建数据管理工具是技术手段、构建运维体系是前提,推广贯标是持续保障。

image.png

首先运用方法论并结合企业实际情况,制定数据整体实施路线图。然后确定数据范围,与业务部门共同制定数据标准,标准内容包括确定分类规范、编码结构、数据模型、属性描述等。标准制定后,按照数据标准进行数据检查、数据排重、数据编码、数据加载等,建立符合数据标准和规范的数据代码库。同时应建设数据管理工具,为数据的管理提供技术支持,实现数据查询、申请、修改、审核、发布、冻结、归档等全生命周期管理。同步建立数据管理和标准管理的运维组织、管理流程、考核机制等,保证数据标准规范得到有效执行。最后统一执行数据标准规范,扩大数据标准的应用范围,实现信息系统间的互联互通及共享利用。


 

从数据标准到数据库设计:解决基础数据标准落地的最后一公里难题

1、数据标准定义

数据是由特定的环境产生的,这些环境因素包括生产者、时间、系统等,这就造成了同一个语义的数据,会有多种不同的定义方法,给后期进行数据汇集和整合带来障碍。因此,数据处理的前奏就是数据标准化,数据标准作为一个统一的数据共识,在企业的标准化中起到重要作用。数据标准是指保障数据的内外部使用和交换的一致性和准确性的规范性约束。数据标准一般包括下面几个,为了统一本文阅读共识,列出如下:

1)基础数据标准,这个标准是针对数据原始定义,一般面向原系统数据或ODS层数据。包括业务语义、管理标准、逻辑数据模型标准、物理数据模型标准、元数据标准、公共代码标准、技术规范,质量要求等。

2)指标数据标准,一般分为基础指标标准和计算指标(又称组合指标)标准。基础指标一般不含维度信息,且具有特定业务和经济含义。计算指标通常由两个以上基础指标计算得出。这个标准针对衍生型数据,一般面向集市层的报表等计算型数据。

3)标准代码,这个具体指数据标准中的枚举值和语义,可以作为基础数据标准的一部分,数据标准维度也是大部分来源于此。

4)主数据标准,这个特指主数据治理中的实体对象数据的唯一编码和规则,比如物料主数据编码。

5)业务术语词典,这个指企业数据定义过程中,从业务名词到物理表和字段的标准化翻译的词根和词素。

6)其他规范,包括数据库设计规范、元数据规范、模型规范等,具体可以在其他治理活动下定义,也是广义数据数据标准的一部分。

一般情况下,本文所述的数据标准落标主要指:(1)基础标准落标,(3)标准代码落标,(5)命名标准落标。指标体系的落标是由于在数据后期比较容易实现,故不在重点讨论中,主数据标准编码则特定于主数据治理过程中实现,不在此赘述。

2、落标价值及意义

数据标准的落标意义在于企业由此开始进行数据驱动文化,开始从源头进行数据的标准化生产,加速数据的融合与统一的效率,节省大量数据应用和处理的成本。数据标准的落标程度可以分为基本拉通型落标和全局管控型落标。

基本拉通型落标是指设计的数据元素符合数据标准的基本语义和业务规则,物理定义符合技术规范,具体数据语义可以进行无规范的衍生。落标范围重点是核心业务系统的核心标准和交叉标准,还有数据仓库系统的。这种类型适合中小银行的上手阶段,以及没有重大系统升级机会的系统,其核心目的是减少数据融合成本,加速数据消费的效力,适合进行数据化驱动转型的企业。

全局管控型落标是指设计的数据元素符合数据标准的基本语义和业务规则,物理定义符合技术规范,具体的物理数据语义需要进行有规范的衍生,数据质量需要落地为数据库约束或者质量验核规则。落标范围是核心业务系统和重点业务系统,以及数据仓库等衍生系统。这种适合IT能力强,数据基础好的企业,其核心目标是掌控企业全局数据,做到数据快速迭代,适合致力于打造数据快速创新型企业。

3、落标过程中的衍生

数据在落标过程中是可以进行一定程度的数据语义衍生的,比如“电话号码”衍生为“供应商电话”,如果衍生的字段有确实的细化语义,或者其他业务要求,就需要也有一些数据标准需要定义为子类标准或者同义标准。

子类标准

当一类数据标准有进行细化的必要,并带来特定的语义和业务规则,就需要在原有标准上进行衍生。比如“电话“衍生为”手机“和“座机“,这是因为这两类衍生标准带来不同的业务属性,不同的数据格式,以及不同质量检查规则。

也有一些可以不进行标准级别的衍生,比如“姓名“,具体语义的设计可能是“客户姓名”和“供应商姓名“,这两个衍生可以不作为子类标准制定,这是因为业务语义是因为数据所在的语义环境变化,本质并没有不同。

同义词

同一类语义标准,在不同的业务口径中或者不同的人群中,会有不同的名词,比如保单号和保单代码是同一语义的名词。这时候需要将两者定义为同义词,并在每一个定义时,标注清楚使用语境。

4、落标难点分析

我国企事业单位的数据治理已经开展十几年,在有数据监管驱动和自身数据价值挖掘的驱动下,大部分行已经进行了数据标准框架定义和梳理,发布了各个板块的数据标准指导文件,有的甚至落实了数据标准流程和人员角色,然而数据标准的落标在大部分普通银行仍然不是很理想。现在数据标准梳理和发布是比较容易的事情,各咨询厂商手里也积攒了大量各个行积累的数据标准,可以比较全面的提交给各个银行,可是落标不理想的原因笔者认为有以下几个问题:

1)存量数据大,积重难返

根据破窗常理,没人在乎再多一块破窗户。数据业务系统绝大部分已经建设完成,木已成舟,不标准也没法修改了。

2)开发设计规范不重视

开发团队的责任和考核点主要是系统上线,支撑业务,在开发团队的很多人看来,数据标准化的设计是一个可选项,影响上线时间才是大事。

3)标准落标不方便,影响效率

很多家咨询公司的数据标准,技术规范普遍缺失。这说明标准开始就没有认真考虑落标问题,这就造成落标很不方便,先在Excel里查找,再手工拷贝,再类型翻译,确实影响效率。

4)监管与激励缺失,落与不落都一样

现在的数据结构和字典中,落标与不落标是没有量化跟踪的,这直接造成激励与认责无法落地执行。