现状描述
早些年的数据项目大多数是以“XXX数据质量校验”、“XXX数据分析平台”、“XXX大数据项目”等常见的名称进行立项，而近些年多以“XXX数据治理项目”进行立项，叫啥不重要，其实所做之事基本上与前面的差不多，无非就是数据采集、数据清洗、数据加工、数据质量、数据建模、数据挖掘、数据分析、数据共享、数据应用、数据展现（可视化、BI、报表、大屏），几乎都是短平快的项目，几乎也都是基于理想化的前提下进行项目实施，而最具价值的交付成果往往是“大屏”，其实项目目标也是实现了的，也算是MVP，但从长远角度考虑，还是远远不够的，后续可能会有很多推倒重来的冲动，而又会顾虑前期的“工作成果”而不停妥协。
受限于资源与成本（预算），很难有精力去考虑或沉下心规划更高、更深层次的东西，诸如：数据管理战略、数据管理框架、数据管理文化、数据管理组织、数据生命周期，及元数据管理、主数据管理、参考数据管理、数据安全管理等……学过DAMA-DMBOK2知识体系的都知道，万变不离其宗，基本市面上绝大多数与数据治理相关的产品都是基于其知识体系所构思和设计研发的，但是上一套这类系统是否就能彻底解决数据治理相关的问题了呢？
或许大家都有思考，但是基本上思考这些问题的人往往只有IT部门+外包服务厂商的人员，业务部门的人员参与较少，也缺乏强有力的“一把手”牵头，部门墙、数据孤岛、数据烟囱该存在还是存在。
现状问题
一、从数据来源方面看
有数据标准却很难执行，无数据标准则更是头疼。
大部分数据来源于外部（下级机构、平行部门、其他第三方），源头不可控，源头数据质量很难提前预判。
二、从数据处理方面看
缺乏数据处理基准、标准、原则和流程，摸着石头过河，偶尔搬起石头手滑也会砸到自己脚，这些都是常态。
数据处理过程中，通常很难提前知道数据质量的问题，大部分是做一点冒一点，发现一个反馈一个，发现问题的反馈路径和流程过于繁琐，或上游也很难在短期内改正，甚至改不了。
三、从数据使用方面看
按照既定需求提供的数据并不能达到预期的使用效果，不是数不对，就是数不准，问题根源很难找到并解决。
下游用数需求无法很好的确认，有的需求变更或新增需求的提出，现有数据无法满足，需要从多方源头重新找数。
四、从其他方面看
时间紧，任务重，相关方支持配合不到位，脏活累活很难被认可，能很快看到漂亮的成果（大屏），但很难看到漂亮的结果（数据）。
工欲善其事必先利其器，而“器”不光指“工具”或“系统”，笔者认为，数据治理类项目，人最为重要。
04
解决思路
在笔者所处角色来看，以上很多问题是一个死结，一己之力根本解不开，但笔者坚信，随着时间的沉淀，一定会有转变的，数据治理的项目也会越来越“好做”。
化繁为简，一开始不用投入那么多人员，而是组建一个小团队，先把数据一点一点梳理清楚、探查明白，而不是学着别人先做什么组织上的变革，成立什么委员会、办公室等新组织，大家都很忙，这种事情根本不现实。
实在不行，咱也学学别人，立个纯咨询项目，专业的事情交给专业的人去折腾，那么问题来了，外来的和尚真的更会念经？
从源头抓起，有很多工作根本不需要通过数据治理工作去解决，绝大多数问题都是上游系统的设计不合理或BUG造成，如果是内部数据，可以尝试从上游系统开始下手，该改设计改设计，该修BUG修BUG，总比在数据治理过程中处理要靠谱，治标不治本，成倍耗成本，毕竟上游系统肯定需要一直用，有问题也得改，倒不如前人栽树后人乘凉，都是自己人，遇事好商量。