数据产品:自助BI产品实践指南

3 评论 8317 浏览 51 收藏 14 分钟

在大数据的潮流趋势下,几乎每个企业都将数字化转型升级和数据化管理放在了公司的战略目标清单中。不可避免的,产品人的工作也被数据化席卷。然而,面对处处需要“以数据说话”的如此境遇,我们应当如何获取数据、进而分析数据呢?本位作者根据时下热点总结了一份自助BI产品实践指南,分享给正在因“数据”而苦不堪言的小伙伴们。

大数据时代,几乎每个企业都在追求数字化转型、数据化管理,上到公司管理层战略目标制定,下到一线业务同学的项目复盘汇报、甚至产品经理和开发的需求沟通,都需要数据的支撑,从过去的拍脑袋的定性决策,转向一切用数据说话的定量决策。从而,带来数据获取和分析需求爆发式的增长。

一、数据分析的主要痛点

1. 日常临时取数分析

业务团队:数据获取门槛高,一线业务人员难以直接接触数据源,业务数据获取高度依赖数据团队,数据人力、排期跟不上,数据响应周期长,影响数据使用。

数据团队:临时取数消耗数据开发精力,影响数据基建,业务不满意,出力不讨好。

2. 固化可视化报表

对于一些固定的主题式经营分析报表,需要建设可视化平台让业务直接交互式分析决策,甚至一些后台产品都需要提供数据可视化统计分析能力,例如电商平台B端的商家后台,每个报表页面都需要定制化开发,前后端、数据开发人力成本高,响应慢,一个需求至少1周开发资源,并且对于一些业务端的开发,并不具备专业的可视化开发能力,需要从0开始,学习成本高。

二、自助BI产品的破局思路

1. 自助BI产品理念

自助BI产品理念是自助,通过产品上的低代码、拖拽式、可视化能力构建,让一线业务可以接触数据,进行自助式的分析,人人都可数据分析,取数不求人。就像吃饭的时候,去吃点餐,需要厨师给你做菜,吃饭时长取决于前面排队的时长,以及单个菜品的工序复杂度,吃饭2小时,1.5小时排队吃半小时。

如果去吃自助,厨师提前把基础的高度集成的菜品原材料组装好,用户按需自取即可,可以进行二次的加工,烧、烤、蒸煮成自己喜欢的口味,吃饭时长2小时,1.5小时吃饭,0.5小时休息一下继续吃。

2. 自助BI是数据化运营的必备产品

数据分析的产品形态有定制化的可视化开发平台,用户行为分析,以及自助BI。随着数据化转型的不断深入,企业数据化管理流程和人才体系被逐步培养起来。BI产品的不断迭代和完善,已经可以逐步替代定制化开发,例如一些商业化的BI推出可视化大屏模式以及PC、移动端可视化门户的快速搭建能力。

从最终业务目标看,自助BI产品是一劳永逸的方案。遇到过一些企业,先是采购了用户行为分析的产品,业务不断发展分析场景多元化之后,单一的用户行为分析能力已经无法覆盖分析需求,还需要再次采购BI工具。

相反,如果选择自助BI产品,只是数据模型的扩展、数据分析能力的增强。虽然企业每个阶段的痛点和问题各不相同,但智能BI决策分析产品,才是决策分析类数据产品最终的归宿。

三、自助BI产品功能架构

敏捷BI工具的标配流程是数据建模、拖拽分析、可视化呈现、系统管理等功能模块,随着基础看数据的需求满足后,业务会有更多增强分析、以及从人找数到数找人的预警、推送需求。

同时,对于数据生产者,要持续降本增效,因此围绕数据血缘看板生命周期相关的数据治理流程,在自研产品中也要考虑进去。

1. BI系统架构

数据源:从系统架构层级看,BI系统最底层是数据接入层,数据源是原材料,否则工具做的再好也是巧妇难为无米之炊,要支持接入常用关系型数据库,以及数据仓库的数据源。

数据模型:数据接入后,在数据模型层,做表之间的关联、字段逻辑处理、元数据信息维护,形成模型资产,把模型主题、层级分门别类管理好,方面业务快速找到目标数据源,同时需要做好模型权限、字段、行值权限管控,技术层面要把不同数据源集成到OLAP查询引擎,提升即席查询效率。

分析层:无SQL拖拽分析,业务基于数据模型,可以直接选择维度、度量、过滤条件后,直接进行数据查询,同时封装可视化图表组件,做结果的可视化展示。对于需要固化的分析结果,可以将图表保存至Dashboard,且可以对图表系列颜色、数据标签、筛选条件等进行设置。

输出层:主要包括Dashboard输出、将看板以iframe方式嵌入其他平台、数据推送&预警,以及可视化大屏。将可视化能力直接在系统内应用或跨系统复用。

自助BI行业来说,成熟的商业化产品非常多,传统的BI分析如帆软BI、BDP、Tableau、永洪BI、亿信华辰等,云厂商阿里quickBI、网易有数、火山引擎智能数据洞察等,在产品细节功能设计的时候,可以注册账号去试用体验即可。

四、自助BI产品从0到1的踩过的一些坑

1. 数据集资产是根基

对于BI产品而言,数据集资产是根基,用户去进行自助分析的前提是,有数据可以分析。在过去从0到1做BI产品初期,最大的问题是功能有了,但是没有可以供业务去查询使用的数据资产模型,自助分析、数据可视化做的再好,也不会有业务去使用。

所以,在企业内部推动BI项目时,要联动数据资产建设者(数仓开发等),去提供可以给业务去使用的流量、订单、会员等数据模型,让用户体会到,自己取数也很简单,而且更快。

对于数据集管理模块功能设计时,需要提供全面的元数据维护、数据集分级分类检索、数据逻辑确认的能力,让用户方便地找到所需要的数据,一键申请权限,快速自助分析。

2. 自助分析要足够自助

曾经,BI项目组中,产品和研发一直围绕一个到底自助分析模块应不应该支持模型关联的问题争执不休。开发的观点是应该像QuickBI一样,将所有的建模过程在数据集创建中进行,自助分析仅做可视化配置。

而产品的观点则是,自助分析除了输出可视化配置能力外,还承担了无SQL取数的功能,很多一线的业务同学,是利用自助分析取数的。数据开发在进行数据集创建时,考虑模型的通用性,会提供一些基础的明细数据,如果只能在数据集上关联,意味着业务进行分析需要关联时,需要联系数据集负责人去改模型,这个周期就很长了。

最初上线时,把自助分析模型关联以及计算字段处理的功能做了灰度隐藏,业务部门直接找过来说,没有这个功能他们就不用了。在这里,我的观点是,自助BI产品,需要包括:自助BI分析+可视化配置能力,自助BI分析,是传统AdhocSQL 取数的低代码、无SQL版本。否则,就只是做到自助可视化,而做不到自助分析。

3. 建立自研BI产品的核心竞争力

业务发展早期为了更快的使用起来会外采商业化BI产品,毕竟自研的周期还是比较久的。当业务已经使用了商业化的产品,虽然经过业务发展以及老板的决策说,我们是时候自己搞一个BI产品了。

那么,说服业务去迁移还是比较困难的,毕竟他们已经有了很多的报表积累,没有优势,凭什么要迁移呢,即使口头上答应了老板说要全力支持,但是真正推行的时候,却因各种优先级问题迟迟推进不下去。

本质还是因为,没有形成对他们足够有吸引力的竞争优势。例如,外采BI一般是采用数据库连接的方式,进行后续分析,多数BI产品对数据全链路追踪能力是缺失的,或者仅限于系统内部的数据集、看板、图表之间的关系。

而自研产品可以具备的优势是从数据源生产加工全流程,到最终的应用,可以做到全链路的数据追踪,针对不使用的报表进行一键下线,打通系统内部的数据治理工具,做到加工过程的任务资源释放,实现降本增效。

五、BI产品的发展趋势

1. 灵活的可视化配置能力持续完善

自助BI可视化的终极目标是要完全替代定制化的可视化开发需求,围绕这一目标,需要看现有的BI产品对可视化门户快速搭建的能力、移动端可视化分析、以及大屏可视化配置的能力。

2. BI+AI智能化分析能力

传统的BI产品主要解决了用户查数据的问题,BI产品和其他定制化或者用户行为分析类的产品主要的劣势在于缺少分析思路的沉淀,需要业务人员具有分析目标和分析思路。

融入AI分析能力,可以帮助业务更高效的进行数据分析,例如当GMV指标波动异常时,利用基尼系数的算法模型,自动生成影响KPI波动的关键维度以及Top影响因素,不需要业务进行逐层分析了,一键定位。

此外,可视化图表的选择上可以利用机器学习自动推荐,这个能力百度的Sugar已经实现了的。

3. 人找数到数找人的能力构建

对于业务人员来说,他们更希望只关注业务,最好能有专门的数据分析帮他进行数据分析,告诉他有什么问题,该怎么做就可以了。基于业务设定的预警规则+智能的归因分析+IM的信息推送,当业务异常时,直接告诉业务,有问题了,哪里有问题,他该怎么做。

#专栏作家#

数据干饭人,微信号公众号:数据干饭人,人人都是产品经理专栏作家。专注数据中台产品领域,覆盖开发套件,数据资产与数据治理,BI与数据可视化,精准营销平台等数据产品。擅长大数据解决方案规划与产品方案设计。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 用户行为分析和自助BI两者不冲突,前者主要功能是做各种即时分析,就像图片中举例的神策。自助BI工具主要是在提高报表的效率,当然配置报表的时候也能做一定的分析,但即时分析还是用专门的即时分析工具好。

    回复
  2. 写的很透彻,对即将开始做BI的我很有帮助~

    来自广东 回复
  3. 大半夜读到这篇文章 满脑子都是:自助BI产品理念-自助餐,明天想吃🆘

    来自福建 回复