有了报表FineReport,为什么还要上FineBI?

楼主
我是社区第99661位番薯,欢迎点我头像关注我哦~
故事前言
前些日子和一位企业信息部门负责人交流,他们用报表工具有5、6个年头了,先后做了财务报表,营收分析、月营收报表,细分到200多家门店以及2000多名员工的财务数据汇总,为财务开发了多维度的查询创建窗口,可以生成周期性的结算报表。

之后又用到业务层,做了OA流程分析、BOSS驾驶舱和经营可视化大屏,可以说把FineReport的功能和场景用得很全了。而且带来的效益也很明显:
1、利用填报规范化各业务线的数据收集流程,利用帆软主数据管理帮忙打通了业务系统,就主数据整理这块,就节约了7个人力。
2、IT不再只是支撑,用人上一方面往专精技术发展,一方面主动为提升业务价值做创新。4个IT报表开发,之后分别去做了ETL和搭建数据仓库模型。3个原本不断和业务沟通需求为业务取数的,专做类似数据分析层面上的经营分析,以及给业务部门的分析培训。
3、建立了商业分析经营模型,提升门店的运营能力,如根据客流及租赁系统进行数据清洗和整合,实现客流动态监测,更好的管理销售业务;
4、对分公司(金融)进行了客户画像分析,将客户交易数额、交易频次等分级,建立VIP客户阵队,为公司拉来34个每月百万级交易的客户,直接带来超1亿的营收。
......

当初上FineReport,通过报表的中国式复杂报表、灵活参数查询、丰富的图表展示、自由的数据填报上报采集、企业级门户管理等特性解决了企业信息化的不少难题,业务的数据报表可视化展示成果也是受到了领导的不断好评。

可以说“IT+数据”,价值越发凸显,盘子也越做越大。

但是任何事过一阵就会遇到上升的瓶颈,随之而来的是销售、门店、市场、人事的业务分析需求接踵而来,企业的各数据采集模块越来越丰富,即便是有报表系统,但报表需求也如井喷。最重要的是,业务的需求越发专业和个性化,需要IT对业务场景越发了解,这种需求很费时间,沟通稍有不慎之后就是不断打回,要么改需求要么继续优化,教业务取数做报表又不现实。

问题分析
基于以上种种企业数据应用的痛点,我们需要进一步的思考。

首先,要肯定报表工具的功劳,它实实在在解决了很多数据填报上报录入、日报月报、中国式复杂报表、以及企业数据报表管理的问题,同时极大地提高了传统企业下IT部门使用SQL+代码到SQL+报表工具直接出报表模式下的报表开发效率,功不可没。

但报表只覆盖了企业部分数据应用场景,且他的上手难度对多数人,尤其是业务人员有一定门槛。

对于一些数据工作走在前列的企业来讲,有些数据问题还得靠BI来解决,比如:
  • 业务有很多分析需求,而且很多是一次性的、甚至个人的需求,沟通和配合效率很低
  • 取数分析涉及的数据量很庞大,百万及千万级以上;
  • 技术问题,需要对接hadoop之类的大数据平台,甚至需要前端报表的数据实时响应;
  • 业务部门培养分析人员需要更容易上手的工具;
......

FineBI的存在就是解决这类问题的!
I.FineReport+FineBI,两者是互补的存在!

如果你所在企业也存在着如上所述问题,那么核心问题就需要通过一款商业智能工具以满足业务人员或者企业领导的即席/自助数据分析需求。

首先FineReport作为一款报表工具,主要用于解决提升IT部门的常规/复杂报表开发效率问题;而FineBI作为一款商业智能工具,在IT信息部门分类准备好数据业务包的前提下,以满足业务人员或者企业领导的即席/自助数据分析需求。通过FineReport+FineBI的完美结合互补,轻松搞定企业IT的复杂报表&业务即席分析需求!

II.报表FineReport和BI工具FineBI的区别

1、数据引擎方面,FineReport产品是直连数据库,性能方面需要数据库的支撑;FineBI产品包含FineIndex和FineDirect两种数据引擎可供用户使用,其中FineDirect也是直连数据库,而FineIndex数据引擎是做大数据建模的,可以生成列式存储的多维数据集对传统的关系型数据库进行加速;
2、FineReport在设计报表模板时属于C/S架构,支持灵活定制各种中国式复杂报表;FineBI属于B/S架构,主要提供自助式的OLAP多维数据分析模式;
3、FineReport可以用来出固定格式的周报、月报、适合作为正式汇报材料;FineBI的使用主要面向业务人员可以自己设计报表进行分析,向自主分析得出结果,辅助企业业务决策;
4、如果把FineReport和FineBI的最终数据分析结果都比喻为一场盛宴的话,FineReport可以比喻为一桌经过精心调理和准备的满汉全席,而FineBI则可以比喻为一场可供用户进行丰富自由选择的自助餐;
5、报表系统和BI的使用对象和目的都不相同,报表系统更着重于短期的运作支持,而BI则关注长期的战略决策,甚至更着重于商业趋势和业务单元的联系而非具体的数据和精确度本身,BI并不是用来代替着眼于日常运做的报表系统的。

III.两者如何配合?

1.FineBI中FineIndex列式存储的多维数据库可以在FineReport中进行读取和使用,FineReport的拓展数据源也可以通过服务器数据集和FineBI进行共享;
2.FineReport制作的所有报表页面都可以挂载在FineBI中进行查看和使用;
3.FineBI和FineReport产品支持融合部署,所有功能都可以整合在同一个工程中进行使用(推荐FineReport整合到FineBI),同时移动端共用一个数据分析app。

典型案例
以某银行为例,下辖13家省内分行、4家省外分行,营业网点541家,员工1.4万人。全行的生产实际ODS总共的数据量20几T,单表数据量最大1亿3千万。


在上FineBI产品之前,信息科技部承担着全行内日常的数据管理以及响应各部门的报表制作需求,譬如,营运客服中心需要定期对客户进行跟踪、电话回访,信息科技部通过sql将数据库中的数据取出来,再展示成报表提供给营运客服中心的客户人员进行查询。

行内的其他业务部门,有计划财务部,公司业务部,消费金融与信用卡中心,风险管理部,营运部,对自己的业务数据有自助分析的需求,譬如计划财务部要做经营分析、资金清算,消费金融与信用卡中心要做信用卡发放的覆盖率、信用卡消费的分析,公司业务部要做增长的趋势、增长速度的分析,风险管理部有对对标上市银行的相关分析。

这些业务部门的数据指标的特性是变化快,不但要不断增加新的指标,而且已有指标的计算方式也在变化,所以需要经常调整。信息科技部并不知道哪些指标对这些于业务部门而言是重要的指标,信息科技部按照业务部门提过来的需求来做好指标,也不能完全实现业务部门需求。

上了FineBI平台之后,信息科技部给计划财务部,公司业务部,消费金融与信用卡中心,风险管理部,营运部分别开设了分析编辑用户。信息科技部将这些部门相关的数据库表加载到FineIndex数据引擎中,按照业务给每个部门的账号分配数据权限,每个业务部门可以自由地对自己的数据进行数据分析。新的模式为信息科技部只需要维护底层数据表,业务部门的科技项目经理负责向信息科技部申请需要的数据,普通的业务员可以对自己模块的数据进行自助分析,彻底改变了原有的模式。

目前全行各部门有效的分析模板300多张,各部门对自己的数据和分析模板有着绝对的自主性,同时也方便了汇报工作,譬如计财部总监给董事会汇报,以前都采用先查询报表,然后将结果粘贴到ppt汇报,现在直接使用FineBI平台,边汇报边切换指标讲解。

总行顺利推进,近期各分行也正在积极推广使用中。

写在最后
数据本身的价值其实是潜在的,而工具的作用是帮助用户更加便捷地进行数据的统计和分析,但是在这之中数据的业务闭环才是最为重要的。

除了常规FineReport的中国式复杂报表之外,还需要通过FineBI不断完善企业即席分析和数据多维可视化建设,让业务人员也能够通过BI工具从单个核心指标出发,然后进行指标拆解,进而深层次多维分析,切片切块,通过同型分析、趋势分析、对比分析等数据分析方法定位到数据中的异常点,最终通过调整决策解决业务问题。

毕竟在当今这个大数据信息化爆炸时代,只有坚持数据成为生产力的企业指导经营方针,让全员都利用好企业的数据以分析引导业务决策,才能让企业真正焕发生机,成为真正超越和引领同行业的领导者。
编辑于 2018-7-6 11:44  
分享扩散:

沙发
发表于 2018-7-6 14:33:15
好久不见,终于等到罗老师更新文章了!

左手一个FineReport,右手一个FineBI

板凳
发表于 2018-7-6 14:35:15

这里应该换成填报+查询吧
地板
发表于 2018-8-16 18:02:47
厉害了
5楼
发表于 2018-8-26 05:10:09
我爱吃大香蕉 发表于 2018-7-6 14:35
这里应该换成填报+查询吧

新造一个词:“查报”,否则填报+查询太长了
6楼
发表于 2018-12-29 11:56:55
7楼
发表于 2019-1-21 09:41:57
填报用的表单能不能让用户自定义呢?
8楼
发表于 2019-1-25 16:40:53
棒棒的,随着报表的需求,BI必将越来越普及
9楼
发表于 2019-1-25 16:41:15
厉害啦,我的BI
10楼
发表于 2019-1-25 16:41:39
传说哥 发表于 2018-7-6 14:33
好久不见,终于等到罗老师更新文章了!

左手一个FineReport,右手一个FineBI

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

本版积分规则

11回帖数 2关注人数 18105浏览人数
最后回复于:2019-1-25 16:41

返回顶部 返回列表