“我们业务太忙！”
当你想把数据治理的失败归咎于这句话时，就要想想：业务为什么不配合？
这就像一个项目经理抱怨开发不写文档——你也得先问问自己，写这文档到底有什么用。
业务其实一直在做数据治理，只是你没看见
不少数据治理团队有个习惯，一边在抱怨业务不参与数据治理，一边对业务每天在做什么视而不见。
报表的口径是谁定的？业务自己定的。
数据质量出问题谁最急？业务最急。
他们会连夜开会、拉群、催IT改，恨不得自己动手。
这不是数据治理是什么？
只不过这种治理很原始——救火式的、短期的、问题还会反复出现。
但你知道吗？这也许已经是他们在资源有限的情况下做出的理性选择了。
数据治理团队做事前经常把组织、机制和流程挂在嘴上，似乎这么做就意味着先进，其实业务不在乎你那套流程。
他们在乎的是：这个数据能不能用，现在能不能用，出问题了能不能快速修好。
这里暴露了一个容易被忽视的事实：
数据治理从来都不是DAMA或者某个部门发明的，业务一直在做，只是他们不叫这个名字而已。
为什么有的治理项目业务抢着干
大家应该都注意到以下有意思的现象：
数据安全合规的项目，业务部门一半不敢说忙。为什么？
因为法律法规写得清清楚楚，出事了要负法律责任，绩效考核直接挂钩。
这时候你看谁还敢推诿？
老板盯着的数据问题，也从来不缺人手。
某个关键指标不准，老板在会上发了火，第二天各部门就自动开始协调了。
不需要什么数据治理委员会，一个VP的一句话就够了。
这说明什么？
不是业务真的忙，是你的事儿还不够要紧。
你觉得主数据很重要，要统一全公司的客户编码。
业务觉得呢？
现在各用各的不也挺好，非要折腾一套新标准，还得改系统、培训人员、调整流程。
短期内除了增加工作量，看不到任何好处。
换你你干吗？
三种势能，六种驱动力
我把企业数据治理的驱动力分成两类：高势能和低势能。
高势能的三种：
这三种，业务部门都会主动参与，甚至主导。
你根本不用担心他们不配合。
低势能的三种：
这三种才是真正的难题。为什么？
因为目标不清晰，责任不清晰，考核不清晰。
你告诉业务要做主数据治理，统一物料编码。
业务问你：这个项目的ROI是多少？能提升多少效率？你答不上来。
你说这是为了长远发展，为了数字化转型。
业务心里想：又是这套空话。
低势能驱动的本质是投资，投资就有风险。
连收益都算不清楚，凭什么让业务买单呢？
算不清ROI？那就算不作为的成本
我知道很多人会说：数据治理的价值本来就难以量化啊。
嗯，说得对，但我们就是要做难而正确的事情吧。
算不清楚做了有多大收益，难道也算不清楚不做有多大损失？
公司的物料编码不统一，采购、库存、工程、财务各用各的。
每年有多少人工在对账？
每次对不上要花多长时间排查？
因为数据不一致导致的采购失误，造成了多少库存积压？
把这些成本量化出来，一年下来可能就是几百万、上千万。这就是不作为的成本。
你说这也很难，总不能让我蹲在那里数吧，这就是问题的关键。
这个时候，如果你直接跟业务讲”我们要做主数据治理”，他们一定觉得是你们又在玩新概念。
你蹲点了几天，换个说法：”我能帮你省掉那X个对账的人，把钱省下来”，他们立马就懂了。
这不是包装话术，这是你根本没搞清楚业务的痛点在哪儿。
很多人说我们要做好规划，立足长远，做事情不能像业务那样短视，这句话不能说不正确。
但也要多问一句，这类规划，是基于对业务深入理解基础上做出的吗？有商业计划书吗？
不同阶段，别瞎折腾
刚起步的公司，或者规模不大的公司，不要买数据治理平台，也不要建什么数据标准体系。
一个公司，总共就100号人，五个系统，搞这么复杂干什么？
初创期的核心是活下来，数据治理的唯一标准就是：够用就行。
数据不准？
能满足80%的场景就可以了。
但有一点不能含糊：核心实体的ID和架构要规划好。客户ID、产品ID这种东西，一开始就要定规则。
否则三年后你想改，发现牵一发动全身，改不动了。
到了规模化阶段，才需要建立”议事规则”。
这时候不要指望部门经理能协调好，必须要VP或CEO级别的领导牵头成立委员会。
从最核心的数据开始，指定一个部门”认领”，出了问题就找他。
很多公司搞数据治理，最大的问题就是没人负责。每个部门都说这数据不归我管，出了问题互相推诿。
为什么？因为没有明确的”地盘归属”。
把地盘分清楚，压实责任，比建立什么精美的数据标准重要一百倍。
华为的真相
每次讨论数据治理，总有人提华为。
“你看华为做得多好，我们就应该学习华为。”
我想问：知道华为为什么能做好吗？
华为的数据治理，不是事后补救，而是内嵌在流程里的。
在华为，不遵循数据标准，流程就走不下去。
这不是额外的负担，是必要条件。
你们公司呢？
数据治理是一个单独的项目，跟业务流程是两张皮。
业务系统该怎么用还怎么用，然后你们在后面追着屁股要求整改。
人家是Governance by Design，你是Governance by Firefighting。
华为能做到这一点，是因为有强大的流程文化做支撑。
这个文化花了二十年才建立起来。
你们公司有这个基础吗？没有的话，就不能简单模仿。
没有谁能抄华为，但有些原则可以学，比如源头治理总比事后补救高效。
数据团队的两条路
面对低势能的数据治理项目，拿不到高层的持续支持怎么办？
两条路。
第一条：试点突破。
找一个业务痛点最强烈的场景，量化好”不作为成本”，做一个小范围试点。
用前后对比的数据说话，证明治理是有价值的。然后再推广。
比如你在一家电商公司，发现商品主数据一团糟，各个渠道的商品信息对不上。
不要一上来就搞全公司的主数据体系，而是先选一个品类做试点，证明统一商品信息后，客服工单量减少了30%，退货率降低了15%。
有了这个数据，再往上申请预算，就容易多了。
第二条路:借势嵌入。
主动找那些高势能的项目，把你的治理工作嵌进去。
新业务系统要上线？
把数据标准的要求写进需求文档。
老板要的报表？
趁机把相关的数据质量问题一起解决掉。
合规整改？
把主数据的规范一起做了。
这叫借力打力，分摊成本，降低阻力。
但有些数据团队，非要单独立项，单独申请预算，搞得好像数据治理是一个跟业务无关的事情。
那当然没人支持你。
结语
说到底，数据治理失败不是因为业务太忙，是因为你没搞清楚业务为什么要配合你。有一把手推动自然很好，但也许只能从0到0.5，但接下来呢？
业务驱动，始终是数据治理最好的发动机。
外部的方法论、最佳实践、工具平台，都是辅助。
最成功的数据治理项目,都是从一个具体的业务痛点开始的，有明确的收益预期，有清晰的责任人，有可量化的考核指标。
我们比较成功的一次数据治理，源于大数据变现时期跨部门核心数据的拉通，因为数据缺失多了，客户就投诉，产品部门直接把电话打爆。
那些失败的项目呢？
总是想一步到位，建立完美的体系，最后却连第一个业务场景都跑不通。
你要真想做好数据治理，先去业务部门待几个月，搞清楚他们每天在忙什么，痛点在哪儿，什么问题会让他们愿意投入资源。
当然，这对很多企业的数据治理团队是个挑战，因为组织割裂和文化惯性可能导致没有人会去业务蹲点，治理者到底是管理者还是服务者角色也是摇摆不定，更别提集中化和分布式组织的协同难题了。
你看，理想化的数据网格提出很多年了，但鲜有成功案例。
有机会下次聊聊这个话题！
暂无评论内容