前几年我在公司做数据支持,每天都被各种数据扯皮搞得头大。各个部门要个基础指标,都得我们技术重新写代码算一遍,重复干活不说,还经常出错,一出错就得找我们去“救火”。
直到后来跟着团队搭了指标管理平台,这些麻烦才算彻底解决。
这些年,越来越多的企业也意识到指标管理平台的重要性了。毫不夸张地说,一个好的指标平台,能直接提高你企业的运营效率和领导们决策的正确率。
很多人会问:直接让技术算数据给业务不就行了?为什么要专门搞个平台呢?
其实还不是那回事,我也是踩了很多坑才明白,做指标平台不是多此一举,而是帮我们省麻烦的。
就拿我之前遇到的几个问题来说吧:
简单来说,指标平台就是帮你把数据从哪来、怎么算、怎么用给梳理清楚,减少技术和业务扯皮,提高决策效率,真正实现数据驱动业务增长。
很多人一听“平台”就觉得复杂,其实拆开来看特别简单,可以借助专业化工具帮你快速搭建,省时又省力。我用的是数据智能平台FineBI,这款工具刚进行了7.0版本的升级,改为直接由指标驱动了,能用来快速构建统一的指标中心,一键做看板、分析数据、查报表,还能用AI问答辅助分析决策,非常方便好用,小白也能快速上手。
我用FineBI构建的指标平台一共分3个层级:
这是基础层,相当于把公司散在各处的数据汇总起来。
数据理清楚了,就得把指标管好,避免再出现“同名不同义”的情况。这一层的重点就是做好这4件事:
指标管好不是目的,目的是让大家能用起来。这一层就是做好用户入口和权限,让业务用得顺手。
那像上述这种能规范数据使用、赋能业务决策的指标平台是如何开发的?很简单,按照我下面讲的步骤来做,就能快速实现指标管理平台的开发落地。
开发指标管理平台之前,需要进行详细的调研准备工作,主要分为需求调研、主题域划分、总线矩阵绘制、指标信息收集四大步骤,下面我们挨个来讲。
调研相关人员对数据、报表的需求,面向业务用户展开指标需求收集时,明确五大关键点:用户、口径、关系矩阵、数据来源、可行性。
明确主题域定义、按定义划分业务领域、与关键相关人达成一致、按优先级确定后续开发的先后。
最终产出项目需要先后实现的主题域、数据目录文件夹划分方式、模型管理分组划分方式、指标管理/维度管理/业务模型文件夹划分方式。
主题域划分示例:
待确定项 | 内容 |
---|---|
主题域名称 | 销售 |
包含业务流程 | 下单、支付、发货 |
涉及系统 | OMS系统、POS系统、WMS系统 |
涉及表 | 订单主表、订单明细表、渠道维度表、时间维度表 |
核心指标 | 销售额、订单数、退款率、发货率 |
维度结构 | 渠道 > 门店 > 区域;商品 > 品类;时间(日/周/月) |
对应业务部门 | 销售部、线上电商部 |
技术落地建议 | 该主题域可独立建模,优先建设,作为数据中心初期试点 |
在进行模型设计之前,首先需要梳理总线矩阵(Bus Matrix),也就是明确业务事实、维度及它们之间的关系。
梳理总线矩阵的前提是深入理解业务场景,对于纯IT或数据开发人员来说,理解业务场景通常有两种方式:
进一步地,可以横向列出企业的主要业务过程(如下单、运输、付款等),这些将最终映射为事实表;纵向列出所有可能的分析维度(如日期、客户、产品、仓库等)。
最后,在矩阵中,标记出每个业务过程与各个维度之间的关联关系(用“X”表示),此矩阵直接决定了后续维度建模中事实表与维度表的关联关系。
总线矩阵示例:
按已经确定好的目标和主题域,进行指标的明细信息收集,需要确保指标清单表能清楚说明每个指标的用途和意义,能直接指导后续的指标创建和信息录入。
面向业务用户展开指标需求收集时,建议设计一套标准模板,一般包含下面这些信息:
1)指标名称:指标正式名称和指标曾用名(选填),这里需要确保指标语义清晰、逻辑一致。
2)指标定义:定义清晰、简洁,避免模糊不清的描述。通常涵盖统计对象、计算口径、数据来源(示例:“企业从事本行业生产经营活动所取得的营业收入”),也可以将这些内容拆分到不同字段中
3)计算规则:定义指标的计算逻辑和取数路径;公式中涉及的指标涉及从业务系统取数,明确系统名称、流程名称、字段及流程取数限定条件等,也可以将这些内容拆分到不同字段中;
4)是否能取值:现有数字化系统是否支撑取值;
5)指标owner:指标的业务方负责人,负责指标业务口径的定义和维护,让业务口径产生争论时具有决策权;
6)数据管家:指标的数据开发负责人,负责按照业务要求取数和计算指标,当收到业务变更需求时,负责和owner拉通,达成一致后才可变更指标;
再接下来,我们就可以用FineBI来进行数据表的连接、建模及指标维度的具体开发了。
通过ETL等工具,将数据处理成标准的维度表和事实表,再通过FineBI数据连接模块接入,用于后续的建模。这个阶段加工的维度表和事实表越“标准”,对企业现状和需求考虑得越全面,后续的步骤会越顺利。
已经有了规范的事实表、维度表结果后,只需要在BI数据中心里建设表间关系(关联字段、关联关系、分析方向),即可完成维度建模,为之后的指标、维度管理提供单一来源的数据。
这里构建的模型,是逻辑模型,并不会在构建时进行数据固化和计算,只有在数据校验、最终用户使用指标维度分析时,才会进行数据计算。
模型示例:
按之前收集的指标明细,在平台里定义指标计算逻辑、录入指标描述信息、反向整理命名规范和属性要求、业务方确认、录入系统并发布。
在这个过程中,要注意进行指标名称与计算逻辑唯一性的双重校验,确保系统中的不存在”同名不同义“、”同义不同名“的指标。
指标开发示例:
当指标、维度数量过多时,用户要快速找到自己需要的所有指标维度会很困难,因此可以将同一主题下的指标和维度汇总在一个集合中,打包给用户。
指标做出来不是终点,还要管好“谁能用、怎么更新”。
FineBI系统的权限分为表→指标→看板三层,使用上有查看指标元数据、在组件中查看数据、使用数据来分析、管理数据四种。
系统功能强大≠权限设计复杂,建议企业按需设计自己的权限体系,也支持与企业已有的系统流程打通,在已有的OA系统中进行指标审批流的设计。
另外,业务一直在变,指标也得跟着变。当指标上线一段时间后,要跟随业务的迭代而新增、更新或下架。
这时可以直接借助指标中心的“版本管理”、“上架审批”等功能,结合组织内部需求流程来设计。
看完我上面写的内容,相信你对指标平台的开发流程已经非常清晰了。最后还有几个关键点想跟大家分享:
其实指标管理平台的本质就是把数据管好、用好。如果你们公司也有数据扯皮的问题,不妨试试从调研需求开始,用FineBI一步步搭起来。相信我,搭好之后,你会发现“做数据”原来可以这么轻松!
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。