摘要:要想做好数据分析工作,绝对离不开数据治理打下的良好基础。本期我们邀请团队内的资深高层数据专家,带你从管理者的视角,全面而深入地了解数据治理的问题。
最近一两个月,恰逢建党、建军各种纪念日,国内各电视台陆续推出了一系列新老抗日题材的电视剧,让观众在没有选择余地的情况下不得不重温了艰苦卓绝的八年抗战。尽管题材老套,但是换个视角来看,笔者又体会到另一番滋味,印象中有这么几个场景:
场景一:我军缴获了敌军的重炮,但是由于没有合适的炮弹,无法使用,带着又是个累赘,只能遗憾的销毁了;
场景二:几个游击队的民兵使用迫击炮,由于没受过正规训练,直接把炮推到距离目标只有两三百米的地方进行瞄准,而炮的射程其实是有好几公里,被国字头友军嘲笑只会抡大刀;
场景三:国字头部队和日本军队多为正面交战,战况往往惨烈,主力部队损失殆尽;而游击队的战法是不正面打大战,而是迂回打(且善于打)小战,不断积小胜为大胜,鼓舞军心,以战养战。
通过这些场景,笔者回忆起最近给国内金融机构做数据治理培训时与各金融机构讨论的有关数据方面的困难和问题,恰好分别可对应到以上三个场景:
1、数据质量问题
大部分机构的管理层都已认识到在现今大数据时代,数据对于企业而言非常重要,业界也有很多成熟的数据分析应用工具与模型,但是由于机构自身的数据质量和基础实在太差,导致无法有效应用,只能自己干着急。这就好比虽然有了重炮(领先的数据分析技术和工具),但是苦于自身没有合适的炮弹(高质量的数据),没办法把武器很好的利用起来。虽然当时的抗日军民也想出把弹药磨、锉至能够适用这些枪炮口径的招来(一定程度上的历史数据清理),但是这样本身存在很大的危险性,也影响武器的准度和精度,真上了战场还是可能会卡壳甚至误伤到自己,发挥不了应有的作用。举个例子来说,某金融机构的个人客户数据中,年龄最高的竟然超过一千岁,而年龄最小的还是负数,大家都开玩笑说年龄负数是否考虑了在娘胎里的时间(笑)。再有,个人客户性别信息的分布有异常,显示客户性别除了主要的三个取值(男、女、未知)外,还有其他两类无效性别的占比竟然将近20%,笔者实在难以想象性别上除了“男”、“女”,再不济是“未知”外,还有什么其他取值?(此处可能引发各位网友对第四、五种性别的不同猜测…)。其实不只是传统的金融机构或企业,即使是新兴发展起来的、具备超强数据分析和挖掘能力的互联网公司,也存在严重的数据质量问题。例如,笔者此前与一家国内领先的互联网公司进行数据治理的工作研讨时,了解到该公司存储的大量交易信息中也有许多非法的数据,如存在一些交易日期为1900年的情况,大家试想那个时候连电脑都还没有,更别提互联网以及互联网交易了。
综上,数据质量问题是普遍存在的,不论是创新的企业还是传统的企业,不论业务规模大小或管理能力强弱,都存在类似的问题,这在很大程度上制约着企业利用数据进行挖掘和应用的能力。要解决这个问题,还是要回到基础数据建设上来,就是我们之前说到的“造炮弹”,需要具备按照既定的标准和规格,造出标准口径的炮弹的能力,而这首先就要有标准化的制造规格(数据标准和规范),例如炮弹的类型(榴弹、穿甲弹等)、口径(如50mm、100mm等)、射程(3000米、5000米等),这样军工厂才能按照这些规格造出符合要求、管用的炮弹来(业务部门按既定标准进行数据采集和录入)。然而在现实工作中,很多机构却恰恰缺乏这些标准。例如,金融机构最常见的“贷款余额”,其口径是否包括了贸易融资、或票据贴现、或垫款?“存款余额”的口径是否包括了保本理财、或信用卡溢缴款等?实际上很多机构对此没有做出企业级统一、标准化的规范定义,这也导致了机构内部数出多门且互不一致,给经营管理分析和决策造成了不少困扰。
2、数据应用问题
暂时先抛开数据质量差的问题,单就如何使用数据、挖掘和创造数据价值的方面,国内金融机构和企业也面临着严峻的挑战。就像电视剧的场景一样,敌军已经配置了先进的坦克、装甲车和枪炮,我军还是小米加步枪,在敢死队冲锋和短兵相接时还抡起了大刀(印象中有许多场面是拿着大刀砍敌人装甲车…)。在当时那个年代确实是由于物资匮乏,条件太差,没办法而为之。但是在现今市场激烈竞争、技术不断发展的背景下,金融机构如果还是用老的一套方法开展业务,不给前台客户经理、中后台管理人员以及决策者配备良好的数据分析和应用工具,那么在市场竞争上就会落后人一步,就好比人家竞争对手都已经是机械化部队全副武装了,我们自己还是大刀队、敢死队,这样处处都会陷于被动。
例如,有的金融机构已经做到了通过数据分析支持精准营销、交叉营销,甚至是事件自动触发式营销,以提升客户体验和营销成功率;还有的互联网金融公司已经可做到贷款的申请、审批和放款全部通过数据模型分析和处理且无需人工干预,以提高工作效率和客户满意度。在这种竞争下,如果金融机构还是沿用老的一套靠人工方式、主观经验判断为主进行客户营销、风险管理以及经营决策,那么必然将在激烈的市场竞争下将处于劣势。而且随着未来利率市场化的不断放开,竞争形势必将更加严峻。
当然,很多机构的管理层也不是没有意识到问题的严重性,就是不知道如何入手。一个很普遍的现象就是,如果并非不得不执行的监管合规达标要求(一般都有合规的时点限制和监管检查),那么机构内部就很难行动起来。笔者此前与一些金融机构的数据主管部门领导进行研讨时,有许多人提出来外部监管机构是否可以出台明确的数据监管指引和合规达标要求,这样他们才便于立项并协调其他相关部门推进工作事项。由此可见,目前驱动这些金融机构开展数据工作的主要动力竟然还不是提升自身的数据核心竞争力,为机构业务经营和管理决策提供支持,而仍然停留在外部监管要求上,那么这显然是本末倒置了。此外,目前有许多金融机构的数据管理和统计分析能力仅在满足外部监管统计报送要求上就已经捉襟见肘了,没有精力来应对内部业务经营和发展的用数需求。这也引出了接下来的第三个问题,即:
3、实施策略和路径问题
笔者了解到如何有效推进数据工作是目前金融机构面临的普遍难题。由于数据工作涉及的范围实在太广,哪里有业务经营和管理,哪里就会产生数据,也需要用到数据,覆盖面基本包括了机构内所有的业务和管理部门。而数据主管部门仅仅作为一个平级部门,在日常工作中很难协调并推动其他部门开展数据相关工作,更别说这里面还往往伴随着一些职责与权利、成本和利益等方面的因素。
那就让我们效仿一下八路军的做法吧:既然敌军这么强大,困难这么多,那么不一定要正面对抗,可以灵活、迂回应对嘛!我军的战略原则有这么几条非常值得借鉴,比如“集中数倍优势兵力消灭敌人有生力量”,“伤其十指不如断其一指”。既然数据工作涉及的面太广,难以在短时间内完成诸多复杂的工作事项,那么就首先集中精力解决1-2个迫切的、关键的数据应用需求。比如,管理层的数据需求往往不多(领导每天关心的指标一般不超过20个,甚至更少只有几个),但是都非常重要,那么我们可以先从管理层的用数需求出发,通过高管报表和每日指标监测、决策驾驶舱等方式实现为数不多的核心指标,当然加工这些指标还需要制定明确的口径规范以及获取相关基础数据,由于范围可控所以工作难度一般不会太大,那么就可先自上而下把这些指标和数据确定下来。这么做一举两得,一方面管理层看到了数据的价值以及开展数据工作的必要性(因为他自身就是直接受益者),有助于获得领导的支持;另一方面,管理层一旦认可了这些指标和数据,就意味着企业最为核心的数据标准“立”起来了,后续就是一个推广和完善的过程。再有,还可以有针对性的选择1-2个部门满足其用数需求,部门的选择可先暂时不考虑那些处于强势地位(即有数也会用数)的部门,而建议选择那些缺数(即自身不产生数据,属于数据需求方)或缺乏应用工具支持的部门。这些部门往往存在用数困难,需要向其他部门获取所需数据(这本身就会有很多沟通和协调的成本与困难),而且没有成熟的平台和工具支持,属于机构内数据工作的“困难户”。那么,集中精力解决这些部门的用数需求,一方面部门的积极性和配合程度会更好,往往愿意协助进行数据标准制定等事项,这就有利于数据工作的推进;另一方面,这也符合我们伟大领袖毛主席提出的“农村包围城市”、“星星之火可以燎原”的战略思想。通过满足这些部门的需求,就能在机构内部形成一种声音和宣传,即原来数据主管部门不是来管理我让我干活的,而是来帮助我、服务我的,这就会逐渐使得其他部门主动来找数据主管部门进行合作,保证了数据工作范围可持续的扩大并顺利推进。久而久之,管理层、大多数部门都支持你的数据工作了,而且也已经形成一套企业级的数据管理和工作机制了,那么“包围并攻下”原来那些较为先进和成熟的城市(其他业务和管理部门)也就顺理成章了,不会遇到原来那么大的阻力。所以说,一开始数据主管部门要放低姿态,我们就是“造大炮”的后勤服务部门,业务部门才是提供“炮弹”并向敌军开炮的前线作战部队,那么我们当然是要服务好他们,而并非管理好他们。
总结一句话就是,实施策略应“以数据应用为驱动,集中精力解决用数需求”,并且要“长期规划,短期速赢,迭代推进”。
好了,聊过这几点数据问题及解决建议后,那么接下来我们还是回到基础性工作,即如何建设好数据治理体系上来。笔者将结合十多年行业数据治理工作的经验,从体系的内容框架和工作思路上给大家做个介绍,希望能够起到抛砖引玉的作用,为机构开展数据治理体系建设带来帮助。
以下是业界数据治理体系的一般性框架:
上图从数据治理体系中最顶层的管理策略,到中间层的核心管理内容,再到底层的系统和技术支撑,至上而下展现了数据治理体系的主要组成部分。出于篇幅限制以及避免太学术化,笔者将不对这些内容展开解释,而是换一种视角,回归到数据治理的本质上向大家说明主要的工作思路。
开展数据治理需要回答以下几个核心问题:
1. 有什么数据?
这是数据治理要回答的最基本的问题,但不见得每个机构都能很好的回答并应对。机构都有什么样的数据,这是开展数据治理的对象。要想了解机构有什么数据,或者说需要什么数据,那么就需要梳理数据,建立数据需求统筹和管理机制。
现实情况是许多机构的数据是分散的,各部门分别拥有并保存和使用各自的数据,但从企业级层面没有人知道到底有哪些数据,这些数据分别在哪里。也就是说,机构普遍缺乏对数据需求的统筹管理。业务部门想要数据,都自己想办法,各自为战,比如建新的系统或改造已有系统,这也是导致后续数出多门、信息孤岛的一个重要原因。因此,要想做好数据治理工作,首先要在企业级范围统筹收集和管理数据需求,这样才能从根源上解决问题。
2. 数据由谁负责?
了解机构到底有(或需要)哪些数据之后,第二个问题就自然来了,那就是这些数据归谁管?由谁负责?
目前普遍存在的一个认识上的误区是数据管理部门(大家一般认为是科技部门、信息中心等)应该对数据负责,而这也是数据治理工作难以在机构内全面推动的根本原因,即职责不清。
一般来说,机构内有这么几种角色,即数据所有者、数据采集者、数据使用者、数据管理者、数据实现者。数据所有者一般是数据主管的业务部门,对数据质量负最终责任,但同时也拥有对数据的最终解释权,是数据在企业范围内唯一的所有人;数据采集者一般也是相关业务部门或分支机构和网点,负责按照既定规范进行数据的采集和录入;数据使用者可以是任意的部门或用户;数据管理者一般是专业化的数据管理部门(如数据管理部、管理信息部等),起到统筹、协调各部门开展数据治理工作的职能;而数据实现者往往是信息科技部门,负责数据的相关系统和技术实现。
要想清晰界定数据的以上职责,就需要基于已掌握的数据需求,建立数据认责管理机制,对每个关键的数据项进行认责,这往往是开展数据治理工作中最难推动的一个环节,但也是至关重要的一个环节。如果没有厘清各部门应承担的数据相关职责并落实到日常工作中去,那么推进数据治理就将成为一句空话。
3、对数据有何要求?
完成数据的责任认定之后,就要对数据提出标准化和规范化的要求了,这就需要建立数据标准和规范。
需要澄清的一点是,制定数据标准和规范的主体并不是数据管理者,而应该是数据所有者,当然数据管理者需要发挥统筹、协调和维护管理、发布标准的职能。即在数据管理者的统筹下,数据所有者对其所负责的数据提出规范性的业务标准和定义(包括命名、业务定义、统计口径等),数据实现者在此基础上补充相应技术标准(如字段格式、编码规则等),形成企业级的统一语言。
4、如何保证数据达到要求?
有了数据要求(即数据标准)后,就需要保证在日常业务和经营管理过程中,数据能够遵循这些标准要求,这就需要建立数据质量管理机制。
数据质量管控应涵盖数据的全生命周期,包括数据的采集、处理和加工、传输和存储、应用和展现、以及销毁和退出等。在各个阶段,都可在数据标准的基础上,确定不同的质量控制规则(如采集规范、校验规则等),并按照这些质量控制规则进行数据质量监控,确保数据符合质量要求。
需要说明的一点是,由于数据所有者对数据质量负有最终责任和解释权,因此企业范围内唯一合法的数据(即主本)应由数据所有者认可并提供,其他部门仅仅是使用或调用(即副本),以此确保数据的唯一性、一致性和准确性。
5、如何进行考核评价?
最后一项就是对于数据的考核和评价了,机构应建立与其自身文化和组织架构相适应的数据考核和评价机制,这也是数据治理工作顺利推进的重要保障。
如果上述几项数据治理工作开展得好,即有清晰的数据职责分工、明确的数据标准和质量管控,那么数据评价本身就不难了,按照既定的职责分工和标准、规则执行相应评价即可。当然,每个机构的文化都各不相同,在评价方面可以有很多不同的方式和做法,没有固定的模式,好用、有效即可,各机构可自行掌握。
通过以上五个方面的工作思路说明,相信大家对于如何开展数据治理工作有了初步和高阶的了解。写到这里,笔者又想起一个电视剧场景,那就是抗日战争后期,我军积极吸纳被俘虏的或未及时撤离的日本技术专家,虽然当时仍物资紧缺、条件艰苦,但是我们宁可自己喝稀的也要给日本专家吃肉,生活上给予无微不至的照顾,弄的这些专家感激涕零死心塌地的替我们研制先进武器和弹药。因此,如果机构内部缺乏数据方面的专家,也可以聘请外部专家协助开展相关工作。笔者也借此机会给老东家打个广告:毕马威的数据服务团队精英荟萃、经验丰富,我们能够提供军事作战指挥的参谋服务(数据规划和治理咨询),攻城略地冲锋陷阵的排头兵服务(客户营销数据分析咨询),守城防御及探雷的工兵服务(风险预警数据分析咨询),军事训练的教官服务(数据分析业务和技术培训),以及思想建设的政工指导员服务(数据文化宣贯和管理培训),大家有任何需求和问题都可以随时与我们联系!
注:上述内容属于笔者个人观点,难免有不足、不恰当之处,欢迎大家批评指正。
本文为专栏文章,来自:KPMG大数据挖掘,内容观点不代表本站立场,如若转载请联系专栏作者,本文链接:https://www.afenxi.com/24582.html 。