睿治

智能数据治理平台

睿治作为国内功能最全的数据治理产品之一,入选IDC企业数据治理实施部署指南。同时,在IDC发布的《中国数据治理市场份额,2022》报告中,蝉联数据治理解决方案市场份额第一。

不熟悉业务可能是部分数据治理相关厂商的明显短板

时间:2022-01-23来源:蝴蝶与蓝浏览数:88

一段时间以来,与在企业中做信息化或者数据治理的同行们交流,发现选择数据治理相关的厂商(以下简称”数据厂商“)感觉挺不容易的,一个较为突出的现象是部分厂商好像不太熟悉企业的业务,而企业做数据治理或者实施数据管理类系统虽然工作的直接对象是数据,但数据来自于业务和系统,对数据的工作其最终目的也是在业务方面体现价值,所以数据类项目必然包含深度的业务内容,而现阶段所接触的部分数据厂商在企业的业务知识方面可能是存在短板的。

数据治理等工作在很多企业中也是近几年才被更重视起来的,那么从数据治理角度上开展工作,对企业来说很多想法或许也不成熟,有若干空白领域,企业一是要自己努力想清楚要做什么、做成什么样子、怎么做,二也是希望有专业数据厂商协助来梳理思路和找到方法,但厂商因为不太熟悉企业的业务,导致双方交流时,往往不能立刻明白企业说的内容,也不能给出呼应企业想法的初步建议,如果单纯的聊数据治理的知识体系和软件工具,企业不能马上明白这些知识和工具怎样应用才能解决数据和业务问题,于是企业就容易产生数据厂商不熟悉业务的感觉。

熟悉企业的业务确实也比较困难,因为各行各业、各种类型、各种规模的企业的业务和管理差异都非常大,即便是开展同类业务的企业,差异往往也很大,这给数据厂商熟悉企业的业务就带来了巨大的挑战,这是困难的基本根源之一。其中有一点或许值得关注,就是部分数据厂商也有一些企业的成功案例,但具体交流起业务时双方往往还是找不到感觉,这是为什么呢?

如果深入交流案例,可能会发现是案例中企业自身把很多事想得比较清楚,即案例企业的内部专家熟悉自己所在企业的业务,也具备一定的数据知识和能力,把业务需求到数据需求的转化这个关键性的内容自己完成了,可以把比较清晰的数据治理需求和设计告诉数据厂商,由厂商实施落地,项目就比较成功。

那么在这种数据项目中,相当于与业务密切相关的内容大部分是企业自己完成的,数据厂商完成的是后端具体的技术性内容,没有足够多的机会去深入熟悉企业的业务。一旦项目结束,企业的数据工作人员还在企业,而厂商因为只做了后端内容,还是不熟悉业务,那么虽然有这样一个成功的数据治理案例,但通过项目得到的成长很有限。

即便数据厂商有机会熟悉了一个项目的业务,但如果下一个项目的行业与此前项目不同,面对新的行业,数据厂商依旧会面对着陌生的业务。这也是某些行业领域内有领先的数据厂商,但跨行业的领先数据厂商却比较少的原因之一,比如一个熟悉电商行业的数据厂商,面对能源行业的项目可能基本要重头开始了。

成为企业的业务专家是挺不容易的,就是在企业内部,可以把自己企业的所有业务说清楚并且可以转化为信息化或者数据管理语言的专家也不太多(成长为专家需要在企业足够长的时间、需要足够多足够大的项目实践、需要足够好的学习和总结、……),更何况因项目才开始接触企业初来乍到的外部厂商呢。

就是在与业务关系相对更密切的ERP领域,沉淀数量足够多的资深业务专家有时也并不容易(比如部分国产系统厂商在此前和现在的生态下就不容易),好歹ERP类的系统本身功能就体现着业务逻辑,要用就必须要知道业务,跑通软件功能就已开始入门企业的业务了,因此熟悉企业的业务或许相对更有天然的便利性。而数据管理类系统,往往都是与业务无关的纯技术支撑类的功能,就像面前摆着一大堆各式各样的工具,但因为不懂汽车所以纵然有工具但还是不能维修汽车是类似的。

现阶段从行业内以某种角度看,数据厂商因熟悉的工具不同或许可以分为两类,一类是掌握理论工具,一类是掌握软件工具。第一类数据厂商熟悉数据治理的理论、方法论、标准、案例,如DAMA、DGI、DCMM等,主要提供数据治理的咨询服务(文档是强项);第二类则是数据产品厂商,有较为丰富和扎实的数据管理类软件产品,熟悉产品和使用。但这种情况类似于是数据治理工作全过程的两个端点,即最前端的理论和最后端的软件,而恰恰在熟悉企业的业务方面可能都缺失了一块,导致其能力与企业需求结合时往往会遇到困难。

综上,因为行业和企业的各种差异,熟悉各家企业极具个性化的业务确实非常不容易,那么对一些通用的业务内容呢?比如相对来说对企业最基本、最标准、最需要的财务数据管理领域,我谈一下遇到过的两个相关项目。

首先是几年前经历过的一个BI项目,当时同期实施的系统较多,因资源不足所以不容易每个系统都盯的非常细,后来BI出现了一个问题,BI上关于财务的若干分析主题跨年后数据都乱了,厂商团队查找问题后初步反馈是数据重复导致的,财务系统和接口都没有变化,现象比较奇怪,于是我们亲自参与问题排查,发现真正的原因是ODS层的财务记账凭证表中没有“年份”这个字段,因为凭证数据来自于SAP ERP系统,而SAP ERP系统的记账凭证是按年重新开始新的凭证编号,所以第一年凭证编号无重复,而新的一年凭证编号重新开始,在没有年份字段的情况下,两年中相同编号的凭证显得就是重复了,而且BI对应各数据层的逻辑中都没有年份条件,所以跨年后肯定出问题。而对财务数据中最基本的记账凭证数据,年份又是最基本的内容(对部分国产ERP系统的月份也是),属于财务数据的基本常识,只是因为数据厂商的工程师此前未涉及过企业的业务,无业务基础,数据只是数据,导致设计和实现时出现了这种问题。

然后是近两年的一个也涉及财务数据的项目,关于企业应用数据中台,可能也属于一言难尽的内容,本质都是数据管理的工具,只是说各种相关功能可能会以不同的身份、不同的组合出现在不同名称的系统中(比如平台、中台、……)。那么利用数据中台的数据处理能力,可能作为整合异构财务系统中财务记账凭证的工具,当时也接触了几个数据厂商的团队,把需求与厂商工程师交流后,发现这些数据治理工程师并不知道什么财务凭证,本身企业希望通过厂商获得更多的思路和解决方案,但这些工程师因为不熟悉企业的业务,数据仍旧只是数据,所以,一想到要给厂商讲什么是财务记账凭证、凭证的结构化数据是什么样的,当时心里确实有点凉。

不过当时也转而侧面去了解了几位工程师的情况,发现此前主要做的是很多ETL、数据物理模型层等等工作的,总的来说是偏技术、偏后端的,那么不熟悉数据管理过程最前端的业务内容或许也可以理解了,毕竟技术上各个领域是细分的,都是专业的,都很有深度。那么关于数据治理,其实整个工作链条是很长的,比如有做数据需求分析的、数据架构设计的、数据标准编制的、数据建模的、数据存储的、ETL的、BI代码开发的,等等很多领域,虽然都是做数据治理相关工作,但具体在细分领域上差异往往还是显著的。就像我每次强调专业化时常常举的例子,都叫厨师,一位西餐厨师与一位川菜厨师其实是两个概念;都叫医生,但并不能让牙医去做心脏手术;同理,虽然同样都是从事数据治理相关工作的专家,但一位数据存储专家,其实很难去对接用户谈业务需求的。

其实还经历过若干次与上述内容类似的情况,时不时都有些感触。数据治理,一些领先的大企业多年前就有扎实的开展工作(一是理解数据的价值因而重视,二是愿意投入大量的人员和资金,此前和现在能做到这些的企业或许也并太多),但对大部分企业来说,也是近几年才开始关注,相应的,因为此前需求少,所以提供数据治理服务的各类厂商之前也不是很多,面对现在有点井喷增长的数据治理项目,数据厂商的数量、规模、综合的专业化能力也都需要同步得到发展,后续也很希望企业与厂商通过大量的实践在数据治理领域一起成长。

成为数据治理全域专家,特别是成为熟悉企业业务的专家都需要努力,在这个过程中,或许可以从一些通用的业务内容着手,比如财务、人力资源等。

(部分内容来源网络,如有侵权请联系删除)
立即申请数据分析/数据治理产品免费试用 我要试用
customer

在线咨询