青岛网站建设公,网上做任务网站有哪些,企业网站开发哪家好,wordpress显示英文版数据治理8种方法
8种方法#xff0c;分别是#xff1a;顶层设计法、技术推动法、应用牵引法、标准先行法、监管驱动法、质量管控法、利益驱动法、项目建设法。 事先声明#xff0c;这些方法论都是向各位大佬学习来的#xff0c;也有部分是项目中实操得来的#xff0c;并非…数据治理8种方法
8种方法分别是顶层设计法、技术推动法、应用牵引法、标准先行法、监管驱动法、质量管控法、利益驱动法、项目建设法。 事先声明这些方法论都是向各位大佬学习来的也有部分是项目中实操得来的并非老彭原创。
01
顶层设计法
顾名思义顶层设计法就是先做一个数据治理顶层设计的规划然后按照规划执行即可。
做过咨询的彭友都知道顶层设计、战略咨询都会根据战略目标拆解KPI然后设立对应的支撑项目并且根据优先级别进行排序最后形成一个执行的路径。
今年做什么明年做什么先做啥后做啥都规划的清清楚楚明明白白。
之后就按图索骥就行。大致的逻辑就像下图一样 这样的好处很明显先有面再有线最后是各个点状的项目一点点的落实效果自然没的说。
但是这样的方案是非常非常奢侈的因为这种方案见效慢对组织的要求非常非常高。耐得住性子的组织很少通常都要快速见效。
基本上也只有一些政府单位和极少数的企业使用这种方式获得了数据治理的成功。
02
技术推动法
有敏感的朋友已经察觉出来了这里叫“技术推动法”而不是技术引领啥的。
其实这种方法是绝大多数企业采用的数据治理方法。要说原因么其实很简单因为数据治理项目大多是在信息部门立项和实施的。
既然是技术部门的事儿那当然是技术部门推动了。讲真我见过太多类似的事情很少有效果很好的。
《华为数据之道》里说要“业务主导”话是真没错但几乎没有做到的。原因很简单屁股决定脑袋。业务负责人的主责主业是搞业务根本不会野不可能要主动做数据治理的事情。
技术驱动的套路没啥说的就是针对数据问题从技术层面进行解决。套路就是信息系统建设的逻辑立个项做调研各种概要设计、详细设计各种开发、集成、测试、部署然后验收。 效果么一般吧。因为大多是问题导向频繁“打补丁”式的建设。到最后往往就是各种爆炸报表爆炸指标爆炸数据问题爆炸。
然后开始上指标系统、数据质量系统一个补丁贴一个补丁到最后谁都不敢动了。
归根结底就是因为数据的问题是一个系统性的技术层面的原因只是其中之一而已。造成这种现象的原因就是业务参与度不够。
在企业谁挣钱谁的话语权就大。业务自然是利润中心而技术一般都是成本中心。纯让技术去推动数据治理就像是让儿子督促爸爸戒烟一样不靠谱。
03
应用牵引法
如果说技术推动是小孩推车那么应用牵引则是壮牛拉车得心应手啊。有应用在前面牵引后面的各种事情就显得非常自然。
很多企业建数据体系都喜欢先弄一个大屏不是没有道理的。因为没有“用”的东西是没有价值的。
大屏虽然用户比较单一实用价值比较低但毕竟还是有使用场景的比单纯没有使用场景的纯技术开发建设强的不是一星半点。 以数据应用为牵引反向要求各链路的数据高质量供给促进数据治理体系的建设也是一个很好的选择。
但是这种方式做数据治理始终还是会陷入到片面、局部胜利的结果。有应用的地方数据质量就能得到治理没有应用的数据质量就没人管了。
04
标准先行法
讲真标准现行法的真实案例我只遇到过极少数的几个其中就有某部委。我当时接手做这个项目的时候把甲方情况跟彭友们分享他们都惊呆了居然有这么好的客户
甲方在建业务系统的时候把数据标准和业务系统绑定起来。所以他们在做信息化建设的时候就已经把所有的数据标准都已经建立好了。
我过去的时候发现数据治理真的就这么简单完完全全就是一个纯技术活儿不用考虑人的因素。
所有表都是按照统一的数据模型建设的所有字段中的键值都在最新发布的数据字典里甚至为某个“主数据”单独建了一套管理系统。
我过去就是按照标书里的要求建库建表开发ETL把数据收上来然后整个规则引擎按照配置结果自动计算数据质量定期出数据质量报告。 沃德天从来没有过如此丝滑的场景简直太爽了。
其实为什么有那么多的数据质量问题很简单没有标准。没有标准就没有对错自然就会乱到一塌糊涂
标准有了就能确定什么是对的什么是错的。后面的执行、监测和控制就有了依据数据质量才有保障。
05
监管驱动法
这个好理解就是强监管。
强监管通常是上级单位发政策下级单位执行。而且做不好还会有惩罚。
老彭以前了解过实在是太恐怖了一单罚上千万
银行、保险等强监管的行业就是跟着政策走的。不好好做数据治理不按照EAST、1104的要求报送数据罚单马上就来。
不要想着随便糊弄有本事就造全套的假数据假的跟真的一样的那种表间勾稽关系无误各个维度都找不到破绽的那种。
当然了在企业内部其实也可以执行这种强监管的模式但这需要“特权”。这个前提通常很难达到。
有种取巧的方法就是贯标。比如现在国家在推的DCMM贯标。嗯彭友们要过DCMM记得找老彭哈~~~
贯标有一个特别的好处就是把“贯标评级”列到组织年度目标中这样就能在企业内部形成一个巨大的“势能”形成强监管的态势。
当我们把“DCMM贯标”这根大棒挥舞起来 自然比某个部门或者某几个部门推动数据治理强太多了。
我们给某企业做DCMM贯标的时候发现技术部门早就制定并颁发了数据安全的制度、流程。但是跟大多数企业一样发完之后就成一纸空文了。业务觉得安全管控太费事了压根就不执行。
现在不一样了技术部门借着“贯标”的理由要求业务贯彻执行之前发布的制度和流程。业务虽然不情不愿但是贯标是企业级目标大家不得不做也就半推半就的推行起来了。 其实说到底监管驱动法就是在借势借上级政策要求的势借国家标准的势。用大势推动原本推不动的部门疏通原本阻力大的流程。
06
质量控制法
质量控制法其实是没有办法也算是数据管理早期的雏形。因为说起来数据管理理论体系往前追溯其实是来自于质量管理体系。
ISO9000质量管理标准体系、TQM全面质量管理体系、CMMI能力成熟度集成模型不只是软件哦都属于通用管理体系。
ISO9000后发展出ISO8000数据质量管理标准体系TQM延展出TDQM全面数据质量管理体系。而CMMI协会也在2014年推出了DMM企业数据管理能力成熟度模型。这是数据领域质量管理体系。
中国则参考CMMI等一众数据管理体系在2018年正式发布数据管理成熟度评估模型DCMM国家标准这是后话了。
与其他行业情况一样质量是绕不过去的关。不管是做业务的还是搞技术的相信各位彭友没少为数据质量的问题挠头。质量有问题数据就没法用甚至会影响错误决策。
于是迫于各种数据质量问题企业内外部才认真对待逐步解决数据质量问题。 数据质量管控很明显是问题导向。但是也不能头疼医头脚疼医脚还得有个方法论。
一般来说得有一个具体的需求包括数据质量管控目标、评估标准、判定规则等等。
然后再以阶段性的目标和需求出发从事前防范、事中监控、事后核查三方面进行质量管控对各类数据问题予以解决。
在解决的时候一般会立一个数据质量改进的专项从技术、流程、制度、机制等层面进行改进定期开展评估对数据质量问题及解决办法建立知识库便于之后遇到类似问题能快速定位和解决。
在这个过程中以数据质量问题为牵引综合使用元数据、主数据、数据标准、制度规范等各类手段“建”以致用自然就不会出现用不起来的情况了。07
利益驱动法
利益驱动法其实也很有意思。这是我偷偷观察并总结的招而且这招貌似特别好用。
其实说白了也没啥就是一招以利益共享为根本以“成就”为导向建立一个符合部分核心人员利益的目标然后推一下就行了。
具体的操作手法有很多比如成功案例法、合作致胜法、评奖法、出书法、会议法等还有互联网企业保命大法“开源法”。
不能再细说了再说就会被灭口了。
总而言之这个事呢现在就是这个情况具体的呢大家也都看得到。可能你听的不是很明白但是意思就是那么个意思只想说懂得都懂不懂的我也不多解释毕竟自己知道就好细细品吧。详细情况你们自己是很难找的网上大部分已经删除干净了所以我只能说懂得都懂。关键懂的人都是自己悟的你也不知道谁是懂的人也没法请教大家都藏着掖着生怕别人知道自己懂.........我不说了别打我脸
08
项目建设法
这个很容易理解就是弄个数据治理项目慢慢建设。
其实数据治理这件事情开展到现在也已经形成了一整套非常完善的流程了相关产品能力也已经非常全面了。
我之前参与的项目基本上覆盖了数据全流程什么数据咨询、数据采集、共享交换、数仓、数据标准、元数据、主数据、数据质量、数据可视化、数据分析等等。
目前效果比较好的是咨询和实施结合起来做。
做个咨询对数据现状进行盘点全面掌握企业未来的战略和目前的现状然后根据数据管理体系做出差距分析拟定具体执行的工作任务根据时间进度安排拆解并规划项目。 然后在实施项目中先穿透一个场景再慢慢从纵深和横向两个层面不断扩大战果建元数据、主数据、指标体系、数据质量管理体系等等不断夯实数据基建为前端数据应用提供高质量数据供给。
