大道金服-BI自助分析应用案例

定义IT与业务配合新模式,释放数据价值!
IT部门和业务部门还能怎么配合?
IT部门不是帮忙取数的吗?
不是做报表的吗?
不是负责系统运维的吗?
而业务部门天天忙于业务,每天看看报表就好了,还能配合啥?

的确,以往我们的认知里,IT部门承担大部分甚至所有数据工作,包含企业的数据搭建治理、响应领导和业务部门的报表开发,IT部门和业务部门的联系好像只局限在IT部门提供数据、报表和系统。但是我们的合作客户,大道金服,却不局限于传统固定的IT和业务配合的模式,而是通过定义了IT和业务配合的新模式,使得企业整体数据应用效率提升了120%!


一、About 大道金服
大道金服,全称深圳前海大道金融服务有限公司,成立于2015年7月。大道金服为解决房产金融市场中的痛点而生,携手太平洋产险、众安保险及中华联合等保险公司与银行合作,为客户带来“更快、更省、更安全”的服务体验。大道金服作为连接银行和保险的金融服务提供商,主要围绕客户需求,为客户提供房产交易全流程金融咨询及操作服务。 大道金服通过创新的金融产品,让住房交易的金融服务“更快、更省、更安全”,致力于帮客户实现个人住房金融的需求,将公司打造成为中国最大的房产交易金融服务平台。


二、耗时的开发,往复的需求

过去大道金服和大多数传统企业一样,业务是需求方,而IT部门则响应业务的需求开发。大道金服的科技部扮演着类似IT角色和数据分析师的综合角色,包含产品经理、前端和后端,由产品经理作为沟通中枢来将业务部门的分析需求落地。但是有着这么两个主要问题,一直困扰着大道金服
(科技部和业务部过去的配合模式)


1、需求繁杂,开发冗长
可以看到,总部的运营部、销售部和市场部的所有报表需求都集中在科技部身上,而分公司的需求经由总部对应部门也汇总到科技部身上,“集万千宠爱于一身”,科技部疲于应付来自总部和分公司的万千需求。
另外一方面,大道金服在用的报表开发工具是开源的JASPERREPORT,开发周期长研发投入大,前端写代码成本很高,这无疑是让科技部的工作事倍功半,雪上加霜。
对于业务部门来说,排队等待需求已是惯性常态化。


2、沟通往复,耗时耗力
倘若只是技术上的开发尚可通过更高效的开发工具或者投入更多人力去解决,但比响应报表开发更累的是往往复复的沟通。科技部每完成一个业务部门的需求,就需要找数据同事对数据溯源到头一次,找业务同事对需求确认一次,要么在和业务部门沟通,要么在和业务部门沟通的路上;业务部门也不好过,快速发展的业务让分析需求总是需要动态变化,这使得让报表本身也要随之调整,业务部门也要发起一次次沟通,或者总是被打断要重复校准验收需求。大道金服是一家年轻化的公司,在人员素质相对较高的情况下,确认需求、验收需求仍然对科技部和业务部门在沟通上都带去了很大的工作量,耗时耗力。
传统的IT和业务配合模式已经远不能满足大道金服的业务发展需求,时不我待,大道金服亟需一个既能够提高报表分析效率,又能够解决往复沟通低效问题的解决方案。
“通过数据治理,数据越来越准确后,我们看准了FineBI的灵活、敏捷开发、和分析功能,希望能够快速做报表,同时可以让各个业务部门自行去分析,因此我们采购了FineBI”。


三、明确的分工,高效的分析


那FineBI到底是如何能够针对性解决这些问题的?
  • 灵活丰富易上手的拖拉拽分析
产品部、销售部、运营部、市场部的业务同事,通过FineBI的仪表板的拖拉拽功能,就可以快速完成添加计算指标、绘制图表、预警等操作,数据之间还可进行任意联动、钻取、跳转等OLAP分析操作。而这些操作,原先都需要科技部同事来进行。

(利用FineBI拖拉拽快速进行分析)

  • 业务包管理等数据集中管控分发
通过FineBI的数据连接功能将销售部、运营部、市场部日常需要的生产数据添加到平台上,再按着不同的业务条线建立相应的业务包,将各业务条线需要的数据放在对应的业务包下。业务部门也可以自行上传excel文件数据进行联合分析。
(按着公司级、部门级进行业务包的分类搭建)
现在科技部和业务部门的配合模式是怎样的?现在,科技部和业务部门现已形成了非常明确的分工,即”每次启动新的数据项目,科技部提供基础数据,销售部、运营部等业务部门自主分析“。

  • 分工明确:以最近新上了一个销售专题活动的数据项目为例。最近为促进销售业绩的提升,大道金服的销售部开展了一个专题活动。在活动之后,大家自然想要关注活动本身的效果,以及跟踪销售人员后续的业绩情况。对于这类新的数据项目,科技部只需要确认好销售部需要的字段和维度,在销售部的某个业务包中添加之前没有的数据即可;而销售部在拿到对应的数据之后,便可以基于活动、基于销售人员马上进行分析,科技部门不需要再做报表开发的事情。
(销售部同事利用FineBI跟踪销售专题活动)
不再局限于科技部的需求响应之后,业务部门自己进行分析,想怎么"玩转"数据就怎么”玩转“数据,能够完成的分析也就更多了。

  • 灵活分析:以往,运营部的业务同事需要线下整合各方数据,现在在BI平台上可以尝试着自己将数据拉出,并进行可视化分析。一来因为免去了寻找科技部同事帮忙的流程,大家可以随时随地的进行分析,二来更多的分析能够进行并且被完整地保留,业务同事可以将自己的分析也固化下来,随时查看,还可以申请挂出或者分享给对应业务同事;如果想调整下样式,或者计算一个占比,或者添加一个趋势线,也可以动态调整。
(运营部同事基于FineBI进行通过率分析)

  • 动态发布周报:集中作业部负责公司所有业务系统的操作数据审核,比如日销售订单等。在业务快速发展的时候,业务系统的数据在存储的时候经常需要发生修改(比如录入异常、客户信息异常、数据统计口径发生变化),数据异常越多则可能流程或者系统存在异常,需要进行排查。集中作业部基于此,利用FineBI的dashboard功能每周都会动态发布可视化周报,来强化显示异常数据更多的部门,进而能够督促对应业务部门对流程或者对系统进行排查。

相比于以往的固定报表,这种动态周报更能够针对性当周数据进行异常分析。
比如上周通过简道云数据修改的原因比较均衡,但是本周发现”其它修改“的修改方式占比突然增多,则可以通过拖拉拽的灵活分析进步探究发现,主要原因为系统节点操作失误;
比如发现修改信息的模块分布中“渠道经理信息”的占比非常高,则可以进步探究公司分布的占比情况,进而探究哪个分公司的数据异常更多。
(大道金服每周动态发布数据修改周报)
总结大道金服科技部和业务部门新的配合模式,是业务部门自助分析的模式。我们可以发现这种配合模式有以下特点:

1、业务部门不再排队,科技部不再忙于开发,科技部和业务部门不再往复沟通
业务部门的需求不再需要依赖于科技部才能实现,业务部门自己也能够实现报表需求,而对于科技部来说,只需前期将数据准备好,就不需要再忙于响应业务需求。而这,也让IT部门和业务部门不用再基于一张张报表而展开往复讨论沟通而浪费时间。

2、报表开发转向报表分析,数据分析效率提升
以往业务部门都只是拿来主义,想着怎么展示数据,想着怎么描述需求,而现在,业务部门则可以更加聚焦在数据本身,观察数据之间的关系。同时,由于沟通成本降低、产品易用性显著提升、业务部门人员可以自己完成分析,使得企业整体数据分析的效率也在逐渐提升。

四、大道金服自助分析数据决策系统数据解读

(大道金服自助分析数据决策系统首页)
在企业信息化建设刚起步的阶段,打造信息化系统,往往关注的是平台的访问量和报表的可视化程度。自助式BI不同于传统的报表型BI,系统的价值不再局限于关注平台的访问量,而是关注企业内部在发现业务异常后,有多少人能够在平台上利用数据解决自己的实际问题。
大道金服自助分析平台使用情况
编辑用户
查看用户
月均编辑
月均查看
保留分析主题数量
保留分析表数量
保留分析报告数量
模板导出次数
10+
500+
300+
7700+
1738
103
300
2969

  • 大道金服原来只有科技部一个部门为总部各个部门和分公司所有部门处理数据,现在通过BI平台将分析、应用数据的部门扩展到了6个,编辑用户10+个,为企业培养了大量的数据分析人才;
  • 大道金服业务部门月平均编辑模版300+次,平均每天编辑10多次,相当于每天业务自行解决了10多个即时性问题,对超过1700个组件进行过编辑,每月业务部门通过自助分析满足了610余个分析需求;
  • 大道金服业务部门通过自助分析,形成可长期浏览的分析模版100多张,平均每张模板包含组件17个,相当于至少节省了IT和业务部门1700多次的沟通,而这一数据更是在不断变大。
而这一切,相比原来全部依赖于科技部开发而言,使得大道金服对数据应用的整体效率提升了120%!

五、大道金服的帆软多系列产品使用架构

此外,不得不提到的是,大道金服也采购了帆软的FineReport用于开发复杂表,以及采购了简道云用于数据补录,和帆软生态产品强强联合。未来,大道金服的自助分析将推广应用到更多部门去,应用到分公司中去,培养更多数据分析人才,进步实现企业数据化管理。


关于FineBI

自助式BI,更关注企业内更多用户的数据问题可以自己在平台上解决自己的数据问题,更关注IT数据驱动和人的驱动并行,更关注IT部门和业务部门整体都能在数据上共同发力。
而FineBI,是新一代的大数据全自助式BI工具,以业务为中心,专注为企业提供自助式BI解决方案,致力为企业数据分析服务,通过IT集中数据管控来进行数据分发,让更多需要数据的业务自己能够没有门槛地掌握和应用数据,在推动企业实现数据化管理方面有着天然的优势。


编辑于 2020-2-13 00:13  

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

0回帖数 1关注人数 27166浏览人数
最后回复于:2020-2-13 00:00

返回顶部 返回列表