数据治理是一项长期而繁杂的工作,很多时候大家都为如何做好数据治理而感到困惑,甚至很多时候对此失去了信心。怎么避免数据治理这些问题?
技术部门牵头,大而全的管理
数据治理当前大部分的立项都是信息技术部门,原因在于业务部门往往觉得数据治理和我没什么关系,技术部门大多是以数据中心或者大数据平台为出发点,受限于组织范围,不希望扩大到业务系统,只希望把自已负责的范围管好。
这种情况呈现出的状态,即客户遇到了数据质量的问题,也意识到要通过数据治理来解决,很多时候,客户所立的项目就叫数据治理,殊不知数据治理是一个很大的概念(这里指广义的数据治理),包括很多内容,想在一个项目里就做完是不可能的,很多人认为我们只做了元数据、数据质量、数据标准,内容不算多,但其实内容真的不少。很容易导致最后哪个也做不好,用不起来。
我们仔细分析一下客户的问题。
第一,范围不聚焦。有时候我们认为已经减少范围了,就拿元数据为例。元数据管理的类型很多种,业务元数据、技术元数据、管理元数据三大类,技术元数据又包括:表、字段、视图、存储过程、作业、数据流向关系、作业依赖关系、索引、分区等几十种技术元数据。从管理范围讲,管理系统的元数据范围又很多,包括大数据中心各层、以大数据中心的上游来源系统、下游的应用分析系统,很多公司有上百个信息系统,每个系统里上百张表,每张表两三百个字段,其中还涉及到人工梳理的工作。如此大量的元数据,里面还需要涉及到怎么管,流程、人员、工具、制度规范等。这样多的内容想一个项目都做了,而且还没讨论数据质量、数据标准的内容,怎么可能都做好,没有办法聚焦。况且就算花了很多钱,加班加点做了许多的工作,最后,所做的工作没办法短期见效,也得不到领导的认可,很难再开展二期的计划,从而失去信心。
第二、需求不明确。很多客户看似需求明确,其实是没有想清楚自已真正想解决的问题。从我们的经验看,以具体的数据问题或应用需求为出发点是比较合适的切入点,例如我们可以找数据质量问题比较突出的,反馈问题比较多的业务部门,收集数据质量问题,根据问题进行分析,最后发现导致这些问题的原因有数据标准的问题、元数据的问题、主数据的问题等,然后再根据这些问题去开展数据标准,元数据、主数据等工作。所展开的工作也是有方法的,例如梳理的数据标准范围也仅是以这次问题所涉及的信息项去做,最后这些问题得到了解决,也获得了业务部门的认可,总结经验,再逐步扩大范围。
当然,很多时候,需求并不总是清晰的,如果想不清楚需求,建议先启动一个小型的咨询项目,通过专业的团队,大家一起找到切入点,其实很多时候并不是大家没需求,只是需求是笼统的,模糊不清晰的,而单纯的请来公司做交流,企业都是抱着自已的心思来的,都是有意引导到对企业自已有利的方向中,但真正是不是适合客户自已的情况就不一定了,结果客户听了很多观点,觉得自已经搞清楚怎么弄了,其实不知道,数据治理哪能仅靠几次售前交流就都能弄清楚的呢。就像近几年为什么付费内容这么火一样,免费的不一定就好,付费了,企业可以花费时间和精力帮助客户找到真正目标,这样才不致于后续花更多的钱来交学费。
业务部门牵头,专做流程
传统数据治理很多是信息技术部牵头来做的,但是往往效果不好,于是业务部门决定牵头来做,那是不是业务牵头就会好了呢?业务部门提出,要做全生命周期的管理,业务部门决定从流程入手,开始建立流程,从需求、设计、开发、测试、上线,运维,将所有环节都用统一的流程来管理。结果导致流程超级复杂,为开发人员实际增加了很多工作量,遇到紧急需求,要求当天必须上线,于是领导一纸公文,跳过流程直接上线。最终的结果是:一方面由于增加了操作人员的工作量,另一方面领导没有见到实效,于是逐渐边缘化,最后束之高阁。
第一、全生命周期管理不是万金油。其实,做数据的全生命周期管理没错,但问题是很多时候,业务人员只是单纯的知道一个名词,对怎么做数据治理没有一个完整的认识,只是按照自已想象的去做。那么如何避免呢,是不是完全不要流程就是效率了呢?不是的,流程还是要做的,为了效率而不考虑后续的管理,会带来更大的低效。例如说上线时ETL流向关系设计信息缺失,参考码值没有维护,导致后续业务变更时,难以理解之前的设计,业务变更困难,只能重新开发。
第二、做流程不要执念线上化。其实流程工具只是手段,他并不能约束人的活动,就像我可以不走流程直接上线,流程只能是提高我们工作效率的技术工具而,因此,建议先从线下流程开始,先把流程走通,不断获得反馈,不断改进,当流程稳定下来后,再去做线上化的流程工具支撑,这样做才能真正做到务实的管理。
第三、单一部门难落地。只有业务部门或技术部门部分参与也是不行的。我们知道数据是流动的,数据的问题涉及多个部门,仅有技术部门的参与是很难推动数据治理的活动,只有让技术和业务部门都参与进来,以业务为导向,技术部门配合,才能够达成较好的结果。例如以某几个关键业务指标为切入点,针对这几个指标加工数据流向所涉及的方面去梳理,结果是这几个指标的数据质量得到了大幅提高,同时也积累了治理的经验。
完全依赖工具,唯工具论
很多公司都认为,数据治理就是买一些工具,认为工具做好了,数据治理就没问题了。结果是:一方面功能越做越多,另一方面实际上线后,功能复杂,大家使用不起来。其实这是错误的想法,数据治理本身包含很多的内容,制度规范、流程、组织、工具四项缺一不可,工具只是其中一部分内容,大家在做数据治理最容易忽视的就是组织人员,所有的活动流程、制度规范都需要人来执行、落实和推动,没有对人员的安排,后续工作很难得到保障。一方面治理推广工作没人做,流程能否坚持执行得不到保障。另一方面没有相关的数据治理培训,导致大家对数据治理的工作不重视,认为与我无关,从而导致整个数据治理项目注定会失败。建议大家在做数据治理的时候将组织人员放在第一位,有组织的存在,就会有人去思考这方面的工作,怎么去推动,持续把事情做好,以人为中心的数据治理工作,才更容易推广落地。
为了做数据标准而做标准
很多公司上来就说要做数据标准,却不知道数据标准的全面梳理,范围很大,很难以一个项目的方式都做完,而且就算是花很大精力梳理,也没办法看到效果,结果是客户只看到了一堆文档,这是最普遍的问题。
数据标准落地困难。很多客户觉得数据标准落地难,问我怎么能让业务系统改标准,其实数据标准落地有几个方法,有源系统落地、大数据中心落地、数据接口规范落地。要不要在源系统落地是取决于具体的数据标准问题,而不是泛泛的谈论落地。企业数据标准的落地,应该细化到数据标准项,再分析其必要性,涉及面、重要程度等方面,只有把这些问题都搞清楚,才能够做出改和不改的意义。例如有些字段客户编号,涉及多个系统范围广、重要程度高、影响大,因此需要针对这个标准信息项制定一个可行的数据标准落地方案,如此才具有可落地的可行性。
企业做数据治理切忌贪大求全,要做小而精。把一个具体的数据标准问题,从前到后都理清楚,真正把这一个标准项所涉及的问题都理顺,这样一个数据标准问题才能够得到真正的解决。同时也要注意优先级,因为数据标准问题很多,需要根据重要性、紧迫性来进行选择。
总结一下
◾企业做数据治理,要避免大而全,要做小而精
◾业务部门与技术部门合作,协同推进数据治理工作
◾重视数据治理组织,避免唯工具论
◾要明确需求问题,不要盲目做数据标准
(部分内容来源网络,如有侵权请联系删除)