- 报表到底应该归谁管,OLAP or[2022-08-26]
- 银行数据治理:数据质量管理[2022-08-24]
- 如何利用大数据驱动业务增[2022-08-23]
- 数据如何助力企业降本增效?[2022-08-22]
- 部门不开放自己的数据,到底[2022-08-16]
- 云计算与数字化转型的关系,[2022-08-15]
- 信息化和数字化的核心差异[2022-08-12]
- 如何提升业务对数据团队的[2022-08-10]
- 四种类型项目管理办公室(PMO[2022-08-09]
- 企业数据到底多值钱?关注数[2022-08-08]
报表到底应该归谁管,OLAP or OLTP?
很多企业的报表质量备受业务人员诟病,要么数据不准确、不一致或不及时,有些问题是数据团队自己能解决的,无非是资源问题,如果真想解决,总是能逐步推进解决,只是一个优先级的问题。
但一旦报表优化涉及到跨部门、跨系统的协同,不可控因素就会大幅增加,特别是作为下游系统的报表,受上游系统的影响太大了,有时候不是数据团队不想解决,而是上游系统不给解决或者解决速度很慢,数据团队为了出报表,为上游系统擦屁股的事情太多。
从经验来看,报表归属OLAP团队来做管理,有天然的组织缺陷,主要体现在四个方面:
第一、业务需求管理复杂
对于业务部门来说,报表需求跟其它功能需求一样,都是为了解决一个业务问题,无论是营销问题,销售问题或是其它问题,比如业务部门希望能有个营销系统做精准营销,也希望营销后能马上看到数据,对于业务来说,这些都属于营销需求的范畴。
现实情况是,业务开发团队往往只做营销功能需求,数据管理团队则负责营销报表需求,一个业务人员会同时对着两个IT团队提需求,也许同一个事情业务还要说两遍,一遍侧重业务,一遍侧重数据,而这两个团队获得的信息往往还不一致,这带来了管理成本。
报表人员经常碰到的一个尴尬问题是:业务人员会对着CRM菜单上的某个指标说,能否帮忙统计下这个数据?但报表人员根本不知道这个菜单的指标对应着后台哪张表。
第二、报表开发效率不高
报表口径跟业务开发实现有很大的关系,为了确保统计准确,报表人员不仅要拿到数据,也要了解数据的业务生成逻辑,但这些知识往往掌握在OLTP开发人员的脑子里,报表人员找开发人员咨询口径是常有的事,但对于OLTP开发人员来讲,由于利益不相关,马上告诉答案是情分,不说或者晚点说似乎也没什么好指责的,特别是有时自己也要翻代码。
OLTP团队和OLAP团队的开发节奏也是不一致的,OLTP可能都上线了1个月了,也许报表还没开发呢,为了在上线后能看到数据,业务人员得找OLAP团队来临时取数,这都是组织割裂惹的祸。
第三、数据质量难以保障
数据质量是报表的生命线,做报表的经常骂上游的业务系统的数据质量太差,因为数据质量的六性(一致性、完整性、及时性、准确性、有效性和唯一性)大都跟源头的业务系统有着千丝万缕的关系,但上游的OLTP似乎很少去搞什么数据质量管理,下游的OLAP搞数据质量提升倒是如火如荼,无论是元数据管理,数据质量管理,数据标准管理等等,但这些活动只能解决部分的数据质量问题,但治不了上游或跨域数据质量的根。
究其根本,还是组织职能的问题,OLTP团队不会对数据质量负责,其基因里只有事务成功,即使短期内纠正了下,但马上又会恢复原样,现在企业数据治理的重点,就在于组织、机制及流程的重塑。
第四、数据无法有效采集
传统OLTP团队数据驱动的意识不高,数据架构设计的时候一般不会考虑数据采集和分析需求,以前这类问题还不严重,但数字化时代到来后,OLTP团队的转型似乎也势在必行。
比如互联网公司通过埋点来实现APP操作日志的高效采集是常规动作,但很多传统企业做APP的时候普遍缺乏埋点经验,等到要分析体验的时候才发现没有数据,但要让OLTP团队拥有数据意识不是那么容易,必须赋予实际的职能,报表就是很好的切入点。
既然报表归属OLAP团队会带来很多问题,那么全部让OLTP团队管又如何呢?
答案是也不太行。OLTP管理报表也有其劣势,特别是在需要融合多源数据的情况下,这个时候,OLTP也成为了其它OLTP系统的下游,会碰到OLAP做报表时同样的问题,那么,还不如让OLAP继续发挥数据仓库做报表的优势。
那么有没有两全其美的方法呢?
将报表分为生产型报表和分析型报表,也许我们可以找到最佳归属模式。
生产型报表的特点是占比很高,数据来源单一,以直接看数获得信息为主,虽然生成的业务逻辑可能复杂,但理解数据的门槛较低,OLTP团队更有可能做好。
分析型报表的特点是数据多源,集成难度较高,需要多维分析的技能,使用数据的门槛较高,适合放在OLAP实现。虽然数据质量也会受到OLTP上游的影响,但由于OLTP报表已经实现了大多的业务逻辑,因此OLAP团队可能会轻松很多。
当然OLTP去做报表会受到数据技术、历史习惯的挑战,但的确具有相当的合理性,数据仓库从来不是为了做简单的报表而生的,现在商业智能还没怎么弄明白,报表的职能倒全部接过来了并且越做越多,似乎背离了初心。
现实中我们也会拆分报表,但往往是按照技术能力、时间粒度来拆分的,比如实时的报表应该在OLTP生成,离线的报表在OLAP生成,Count的操作要在OLAP实现,Update的操作要在OLTP实现,但这些都不是业务驱动的思维,解决不了报表的深层次问题,生产型月报让OLTP来做似乎有些奇怪,但却是合理的。
很多公司也许已经这么做了,但大量的公司,还在机械的让OLAP团队去做一堆单系统数据来源的报表,然后投入大量的精力去跟上游系统核对数据。现在数字化如火如荼,数据技术一日千里,也许我们可以做出一些改变。
中翰软件:专注数据治理17年(http://www.jobhand.cn)
免责声明:本网站所发布的文章为本网站原创,或者是在网络搜索到的优秀文章进行的编辑整理,文章版权归原作者所有,仅供读者朋友们学习、参考。对于分享的非原创文章,有些因为无法找到真正来源,如果标错来源或者对于文章中所使用的图片、连接等所包含但不限于软件、资料等,如有侵权,请直接致电联系,说明具体的文章,后台会尽快删除。给您带来的不便,深表歉意。