同一个产量为什么对不上：先建指标口径，再做 BI 看板

对不上的数字，往往都有自己的道理

生产看板显示本班完成 900 件，仓库显示入库 850 件，销售看到的可交付数量又只有 800 件。三个数字可能分别统计了工序产出、已入库成品和满足交付条件的库存，并不一定是谁算错了。

如果直接要求所有报表使用同一个“产量”，会掩盖业务状态差异。更合适的起点，是明确每个数字回答什么问题：安排下一工序、核对库存，还是判断订单能否出货。

本文整理一套指标评审方法。核心是先确定业务含义与数据粒度，再决定图表、刷新方式和展示权限。

点击放大

指标字典至少要写清七件事

建议为每个关键指标记录业务问题、统计对象、事件粒度、计算公式、纳入与排除条件、时间归属以及责任人。对于后续会被修改的数据，还需说明重算方式和历史版本。

以“班次首次合格产量”为例，统计的是某个工序在指定班次内首次产出的合格数量，还是最终检验通过的成品数量？返工后转合格是否回改原班次？当质检结果次日才确认，报表显示的是当前最新值，还是当时已知值？这些条件都影响解释。

同一业务可以保留多个有意义的指标，但名称应反映差异。将“工序报工量”“首次合格量”“最终合格量”“成品入库量”分清，比在会议上反复争论哪个系统更准确更有帮助。

模型设计从一行代表什么开始

Microsoft 的星型模型说明区分了用于筛选和分组的维度表，以及记录观察值或事件的事实表，并强调事实数据保持一致粒度。[1] 在制造分析中，可以据此区分工序报工事件、检验事件、入库明细与班次计划。

例如，一行报工事实表示“一次工单工序报工事件”，而一行计划表示“某条产线某个班次的计划数量”。直接按产线和班次把计划连接到每条报工记录，可能使同一计划在多行重复出现；再求和就会把分母放大。

解决这类问题需要先对齐粒度：分别在适当粒度汇总，或建立不会造成重复计算的度量逻辑。不能只因为两个表有同名字段，就认为可以任意关联。

点击放大

比率通常不能直接求平均

假设产线 A 计划 100 件、完成 80 件，达成率为 80%；产线 B 计划 900 件、完成 450 件，达成率为 50%。两条产线达成率的算术平均是 65%，但按这组示例的统一计量口径，整体达成率是 (80 + 450) ÷ (100 + 900) = 53%。

前者描述两条线百分比的平均，后者描述全部计划数量的完成程度，回答的问题不同。若企业需要按产量目标看整体完成情况，应明确采用后者，而不是依赖可视化工具默认平均。

前提仍然是数量可比。如果不同产品单位差异很大，或一件产品工作量相差悬殊，是否采用数量、标准工时或其他折算单位，要由业务目标决定。不能用一套看似通用的汇总方式覆盖所有场景。

示例用于评审，不规定企业必须使用这一达成率定义。

点击放大

时间与版本会改变历史结果

报工发生时间、进入系统时间、质量判定时间和库存记账时间可能不一致。夜班跨零点时，还需要日历日期与生产班次日期的映射。接口补传后，报表应能解释为什么昨天的数值发生了变化。

建议保留业务时间与采集时间，并让关键指标说明“数据截至何时”。对需要复盘当期决策的场景，保存周期快照；对要求展示最新事实的场景，则使用约定的重算窗口，并记录修订依据。

组织归属变化也会影响历史分析。一个销售人员调换区域，或某产品转移到另一车间后，历史业绩应该按当时归属还是当前归属查看，应在指标字典和模型中明确，而不是由页面筛选偶然决定。

点击放大

看板验收应抽查明细与边界

选择几组实际业务记录，核对页面汇总能否解释到原始单据。除了正常报工，还应包括重复上报、返工、撤销、跨日补传与空计划等边界情况。

分母为零时应显示“不适用”或约定状态，避免产生无穷大；数据未更新时要与真实的零产量区分。权限测试也应覆盖明细钻取和导出，确认只能访问相应岗位允许的数据范围。

当一个数字异常时，使用者应知道口径是什么、数据到几点、可以找谁核对。做到这一点，再增加趋势、对比和预测图表，才有可靠的数据基础。