三数据治理之死 _数据治理

数据治理之死（三）
假设有一个公司，刚起步，老板招齐了队伍，有产品，有研发，有测试，想好了整个系统，画好了蓝图，研发照图实现，测试上线，业务在此基础上运营推广，然后挣钱盈利，整个过程自上而下，全部数据线上化，有完整的数据，业务在使用中有问题和需求就改产品，迭代上线，整个过程产生的数据都已入库，管理规范。
假设有另一个公司，一开始干工厂，卖材料或产品，建立了自己的销售网络，但没有对应的IT系统，经过多年的发展，通过项目的方式，建了OA系统、财务系统、CRM系统、SRM系统、SCM系统、NC系统等，这些各自分立的系统之间又有各种种类的相互联系，数据也是各自存储，随着规模的扩大，技术的进步，迫切需要数据化转型，把各个环境拉通，各种数据融合，建成统一的大数据系统，对公司的各种管理需求和报表报告能直观的获得，但是数据又五花八门，缺胳膊少腿，很多手工数据，没有规范和标准。
上面第一个公司类似于互联网公司，基本上不需要数据治理，可以很方便地拿到各种数据，建好数仓、或数据中台，进行数据挖掘，数据分析，以数据来驱动业务，第二个公司类似于传统制造企业，如果无法抛弃所有的IT系统重新开发（一般不会），就不得不面临数据整合的压力，所以才需要数据治理。
对于互联网公司，是先搭窝再养鸡，再收蛋的方式，窝可以搭的很好，而传统制造业是先养鸡下蛋，再搭窝，可能建了很多各种各样的窝，不统一，有的时砖造的，有的是柴禾造的，有的是泥土造的，有的甚至没窝直接蛋下到地上的。
数据治理的难度取决于制造企业的信息化程度及历史包袱有多重，如果企业做的各种IT系统有统一的技术规范、技术栈，有相应的标准，各系统之间的对接有统一的平台，业务结构不太复杂，则数据治理就容易取成成效。否则，各种系统正在照常运转，你去搞个标准，让别人按你定的标准来改，对不起，造成的生产损失谁来承担？出标准不难，难的是怎么按照标准把旧的系统改了，有时需要停机、生产停止来升级的，更不用说你要协调几乎整个公司的各大业务部门，人家的业务部门还要完成年度KPI，还有自己的IT系统升级计划，还有一大堆正在进行的项目。
对于互联网公司，它是IT驱动的，而制造业是业务驱动的，这有明显的不同。比如，在制造企业，业务说他要什么需求，IT是要想尽各种办法实现的，有时做出来的功能很奇怪，比如用户可能习惯了Excel，他让你做一张报表，这个报表里面的功能非常复杂，就像开发一个在线化的Excel一样，你要显示几十上百个字段，几万个数据，加上多行表头、冻结、下钻、排序、编辑、合并、颜色等等；有时业务要的很急，你做完了他们未必用，业务变化很快，而且业务变化时根本不会找IT商量，比如业务在销售产品时对产品渠道划分做调整，他们开个会商量一下就变了，不会考虑到对应的IT系统、BI系统也要对应调整，历史数据要不要也调整等，一个红头文件发出来，IT蒙圈了，各种忙，各种加班。
有人可能问了，为什么这些系统不在实现时就考虑到渠道变更的可能呀，或者在渠道变更后升级成可配置的，这样下次就不会大动干戈了。
事情哪有这么简单，这些系统是在业务需求提出时火急火燎的开发实现的，不是互联网那种产品详细调研、规划设计的很完善才落地的，也许一开始是有考虑渠道变更的可能的，但考虑到项目周期，业务也告诉IT说渠道在2年内是不会改变的，即使改变也将是很大的动作，会留足时间的，但是项目上线后，项目人员解散了，调走了，业务负责人也换了好几波了，等你接手时，就遇到这种坑了。

三 数据治理之死

三数据治理之死