单位 4 / 11

商业智能 (BI)、报告和指标设计

收益:

  • 能够解释商业智能层(源、ETL、数据仓库、报告)以及关键业务指标 (KPI) 的正确定义。
  • 能够使用人工智能生成指标定义、SQL 草稿和报告叙述,并提供带有真实数据的结果
  • 能够识别人工智能支持的分析输出中相关性因果关系混淆和误导性指标的风险

商业智能(BI)是一门学科,它收集组织的分散数据,为分析做好准备,并从这些数据中生成决策支持信息。对于 MIS 专业人员来说,BI 是“数据转化为决策”的层。单独的原始订单记录是没有意义的;但“本月哪些地区的成交量减少了,原因是什么?”当它成为可以回答问题的报告时,它就产生了价值。在本单元中,我们将看到 BI 的各个层次、正确的度量设计,以及人工智能在此过程中的加速器和陷阱。

BI架构一般由以下几层组成。源系统:数据产生的地方,如ERP、CRM、电子商务等。 ETL过程(英文Extract-Transform-Load):从源中提取数据(Extract)、清理并将其转换为标准结构(Transform)并加载到目标(Load)的过程。数据仓库:收集用于分析的历史且一致的数据的中央存储库。报告/可视化层:仪表板、报告和即席查询。在这个链条中,每一层的质量决定了下一层;如果源是脏的,那么报告也是脏的。

正确定义指标和 KPI

指标是测量的数值:总营业额、订单数。 KPI(关键绩效指标)是衡量绩效目标的关键指标:“每月客户流失率低于 5%”。并非每个指标都是 KPI; KPI 是与业务目标相关并触发决策的指标。

BI项目最隐蔽的问题是指标的模糊定义。 “活跃客户”是什么意思?过去 30 天或 90 天内订购的?归国人员算不算?如果两个团队对“活跃客户数量”的含义不同,则同一仪表板会显示两个不同的事实。这就是为什么每个 KPI 都应该有一个被广泛接受的一句话定义。人工智能快速生成这些定义的草稿;但由业务部门决定哪个定义是“正确的”。

提示:设计 KPI 时,写下三件事:(1) 公式(分子/分母到底是什么)、(2) 时间窗口、(3) 排除的情况。让人工智能说“将此 KPI 定义中的歧义提取为问题”揭示了隐藏的假设。

一步一步:人工智能驱动的报告生成

第 1 步——澄清问题。该报告将做出什么决定?一个具体的目标,例如“我们将决定将预算转移到哪个地区”,而不是“它应该看起来不错”。

第 2 步 — 定义指标。使用公式、窗口和例外情况编写所需的 KPI。人工智能可以生成定义草案。

第 3 步 — 生成 SQL 草稿。将架构信息提供给人工智能并生成查询草稿。但在运行查询之前请先阅读并理解该查询。

步骤 4 — 用小数据进行验证。首先在具有已知结果的小样本上运行查询;手动检查总计。 AI的SQL可能在语法上是正确的,但在逻辑上是错误的。

第 5 步——添加叙述、测试声明。人工智能可以为报告生成叙述性文本;但要证明每一个因果关系(“这就是销售额下降的原因”)。

相关性和因果性陷阱

BI 中最危险的错误是将两个共同作用的指标解释为“一个创建另一个”。相关性是指两个值一起变化;因果关系是指一个因素导致另一个因素。 “随着冰淇淋销量的增加,溺水事件增加”这句话是正确的,但冰淇淋不会导致溺水;常见原因是夏季(炎热的天气)。人工智能在制作报告叙述时可以轻松地做出因果句子; MIS 专家对这些说法作出回应,询问“还有其他解释吗?”他应该测试一下。否则,就会基于错误的理由做出错误的决定。

三个迷你案例:从数字来看

案例 1 — 未定义指标的成本。在一家电信公司,提交给董事会的“活跃用户”数量为210万,财务团队的报告为170万。区别在于,一个将 90 天算为“活跃”天,而另一个将 30 天算为“活跃”天。错误的增长率讨论了两周,直到澄清了共同的定义。一句话 KPI 定义可以避免这种混乱。

案例 2 — AI 的错误 SQL。在一家零售商处,人工智能在生成“每位客户的平均购物篮”查询时将退货行添加到总数中;结果比实际值高出 12%。 SQL 在语法上是完美的。当专家手动验证已知一天的总数时,他发现了偏差并添加了返回过滤器。

案例 3——因果关系谬误。在一家电子商务公司,仪表板显示“发送电子邮件活动的日子销售额增加了 18%”,团队即将增加活动预算。分析显示,这些活动的时间安排已经与高流量活动日(折扣期)一致。推动销售的是时间段,而不是电子邮件。如果在没有对对照组进行测试的情况下增加预算,那么这些钱就会被浪费。

弱提示/强提示

弱提示:

从该表写入销售报告 SQL。

强力提示:

您的角色:您是一位细心的 BI 分析师。根据下图编写 SQL 查询草稿。规则:- 仅使用给定的表/字段;不适合字段。- 从总计中排除返回 (status='Return')。- 时间窗口:过去 30 天。- 逐行注释查询的内容。- 建议 1 个示例行,可以在最后手动验证测试。架构:订单(id、customer_id、日期、金额、状态)客户(id、名称、细分)目的:过去 30 天按细分的净营业额。

强大的提示限制模式,强加业务规则(不包括返回),指定窗口,并请求可验证的输出。

四个可复制模板

1)KPI定义澄清:

为以下 KPI 编写完整描述:公式(分子/分母)、时间窗口、排除的案例。将定义中的任何歧义添加为问题。KPI:[名称,例如“客户流失率”]

2)SQL逻辑检查:

检查以下 SQL 查询:是否存在逻辑错误、不正确的 JOIN、缺少过滤器或重复计算的风险?为每项发现写下理由。不要更改查询,只需检查它。 SQL: [查询]

3)报告叙述+索赔控制:

根据下面的结果表写出简短的执行摘要。在每个因果关系旁边标记[需要证据],并提出替代解释。只需依赖表中的数据即可。表:[数据]

4)指标一致性检查:

在下面的两个报告中,具有相同名称的指标给出不同的值。列出了定义(时间窗口、过滤器、计算)中可能存在的差异。报告:[A][B]

比较表:好与坏的 KPI

特征

糟糕的关键绩效指标

良好的关键绩效指标

描述

“活跃客户”

“过去 30 天内完成 ≥1 个订单的客户”

与目标的结合

“损失率保持在 5% 以下”

可测量性

暧昧的

公式清晰

异常

不确定的

不包括退货

它会触发一个决定吗?

是的

常见错误

  • 未定义指标。如果使用“活跃”、“成功”、“完成”等词语而不使用公式,则每个团队的计数会有所不同。
  • 在没有验证的情况下运行 AI 的 SQL。语法上正确的查询可能逻辑上不正确;重复计算和不正确的 JOIN 很常见。
  • 混淆相关性与因果关系。认为“它随着那个而增加”意味着“这个导致那个”会导致错误的决定。
  • 虚荣指标的追求。将“总点击次数”等花哨但非决定性的指标误认为是 KPI。
  • 在没有上下文的情况下呈现数字。光是“营业额420万”是没有意义的;需要基于上个月、目标或预算的背景信息。
注意:人工智能生成的报告叙述令人信服且流畅;这恰恰放大了风险。流畅的句子可能带有错误的因果关系主张。用证据检验每个“因为”和“因此”的陈述。

总之

商业智能是将分散的数据转化为决策的层,由源、ETL、数据仓库和报告链组成。 KPI 是与业务目标相关的关键指标,具有明确定义的公式和例外情况;未定义的指标是最常见的 BI 错误。人工智能在生成 KPI 定义、SQL 草稿和报告叙述方面提供了显着的速度;但每一个 SQL 都必须在逻辑上合理,每一个数字都必须有已知数据支持,每一个因果关系都必须经过证据检验。相关性不是因果关系;流畅的叙述并不能保证准确性。

应用任务

为在线课程平台设计“完成率”KPI。 (1) 写一篇简短的描述,其中包括公式、时间窗口和例外情况(例如,取消的注册是否计算在内?)。 (2) 建立一个简单的模式(注册、课程、进度),并为该 KPI 生成具有强大提示的 SQL 草稿。 (3) 找出查询中至少一种可能的重复计算或不正确过滤的风险。 (4) 打印结论的执行摘要并标记其中的每项因果关系。 (5) 举一个相关因果陷阱的例子并解释如何测试它。

清单

  • [ ] 写有每个KPI的公式、时间窗口和例外情况。
  • [ ] 我逐行阅读并理解了AI生成的SQL。
  • [ ] 我用鲜为人知的数据手动验证了查询。
  • [ ] 我用证据检验了报告中的每一个因果关系主张。
  • [ ] 我将每个数字与基准(目标/上一时期)联系起来。
  • [ ] 我在指标定义上达成了跨团队共识。