Power BI 工业工程看板实战：从数据到管理驾驶舱

引言：看板不是为了好看，是为了少开会

先说一个真实观察。

某工厂每天早上 8:30 开生产例会，参会者 12 人，平均时长 45 分钟。会议内容的前 25 分钟，几乎全部花在"对数字"上：

• "昨天产量是 4820 还是 4790？"
• "我这边系统显示 4805，可能是报工延迟。"
• "停机时间算不算换型？上个月说不算的。"
• "设备部统计的停机是 4 小时，生产部是 6 小时。"

真正讨论"怎么办"的时间，只剩下 20 分钟。

这类问题的根源不是人不认真，而是没有一个所有人都认可的、实时的数据源。

一个合格的管理看板，能把这 25 分钟砍掉。前提是它满足三个条件：

1. 口径唯一：所有人看到的是同一个数字，定义写在哪里都查得到
2. 自动更新：不需要人工导出导入，早上打开就是最新的
3. 能下钻：看到异常能一路点下去，看到工单级、设备级的明细

Power BI 是目前做这件事性价比最高的工具。它免费（Desktop 版）、与 Excel 生态无缝、能连几乎所有数据源、学习曲线平缓。

本文讲的就是：怎么用 Power BI 把工厂的数据变成管理驾驶舱。

一、什么时候该用 Power BI，什么时候不该

1.1 先泼一盆冷水

Power BI 不是万能的。以下场景不该用：

1.2 适合用 Power BI 的场景

判断标准：如果一个报表每月要做一次以上，且每次都要重新导数据、刷新透视表，那就该用 Power BI 自动化。

1.3 与竞品对比

国内制造业的现实选择：如果企业已用 Office 365，Power BI 是最顺的。如果用国产化要求（信创），帆软 FineBI 是主流。两者概念相通，学会一个转另一个不难。

二、整体工作流

① 数据源（SQL / Excel / ERP / MES / Web API）
        ↓
② Power Query（数据获取与清洗）
   - 连接、筛选、改类型、合并、拆分、透视/逆透视
        ↓
③ 数据建模（表关系、星型模型）
        ↓
④ DAX（度量值：业务指标的计算逻辑）
        ↓
⑤ 可视化（图表、切片器、交互）
        ↓
⑥ 发布与刷新（Gateway 定时刷新）
        ↓
⑦ 权限与共享（行级安全 RLS）

时间分配的经验法则：一个 Power BI 项目里，

• 数据准备（Power Query）占 50%
• 建模 + DAX 占 25%
• 可视化占 20%
• 发布运维占 5%

新手往往把 80% 时间花在画图上，这是本末倒置。如果数据模型建对了，图表半小时就能改好；模型建错了，图表再美也是错的。

三、Power Query：数据清洗（最花时间的一步）

3.1 核心理念：记录步骤，可重复执行

Power Query 的每一步操作都会记录在"应用的步骤"面板里，形成可重复执行的 ETL（抽取-转换-加载）流程。下次刷新，所有步骤自动重跑。

这是它相对 Excel 手工操作的根本优势：一次配置，永久复用。

3.2 十类常用操作

3.3 逆透视：宽表转长表

这是 BI 建模中最重要的一个操作。

问题：业务人员习惯的 Excel 表格长这样（宽表）：

这种格式人看着舒服，但 BI 分析不了——因为"月份"是列名，无法作为筛选维度。

逆透视后（长表）：

长表可以被任意维度（产线、月份）切片，这才是 BI 需要的结构。

操作：选中要转换的列（1月、2月、3月）→ 转换 → 逆透视列 → 自动生成"属性"（月份）和"值"（产量）两列 → 重命名为"月份"和"产量"。

判断标准：如果你发现表格里有多个"看起来是同一类指标"的列（如多个月份、多个产品、多个工序），几乎都需要逆透视。

3.4 日期表（必建）

几乎所有时间智能分析都依赖一张独立的日期表（Calendar / Date Dimension）。

Power BI 不要求你建，但没有日期表，时间智能函数（同比、环比、累计、移动平均）全部失效。

用 DAX 建日期表：

日期表 =
VAR MinDate = DATE(2023, 1, 1)
VAR MaxDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(MinDate, MaxDate),
    "年",           YEAR([Date]),
    "季度",         QUARTER([Date]),
    "月",           MONTH([Date]),
    "年月",         FORMAT([Date], "YYYY-MM"),
    "年月排序",     YEAR([Date]) * 100 + MONTH([Date]),
    "日",           DAY([Date]),
    "星期几",       WEEKDAY([Date], 2),      -- 2 = 周一开始
    "星期名称",     FORMAT([Date], "dddd", "zh-CN"),
    "是否工作日",   IF(WEEKDAY([Date], 2) <= 5, 1, 0),
    "周序号",       WEEKNUM([Date], 2),
    "年周",         YEAR([Date]) & "-W" & FORMAT(WEEKNUM([Date], 2), "00")
)

建完必做三件事：

1. 标记为日期表（表工具 → 标记为日期表）
2. 与事实表建立关系（日期表[Date] → 事实表[日期]）
3. 给"年月"、"星期名称"等文本列设置排序列（列工具 → 按列排序 → 选"年月排序"），否则月份会按拼音排序（"1月, 10月, 11月, 12月, 2月…"）

第 3 点是最常见的低级错误，几乎每个新手都踩过。

3.5 数据清洗的性能原则

关键判断：如果数据源是 SQL 数据库，尽可能把工作推给 SQL（数据库擅长这个）。Power Query 只负责 SQL 不擅长的部分（合并 Excel、Web 数据、逆透视等）。

四、数据建模：星型模型

4.1 事实表与维度表

4.2 星型模型 vs 雪花模型

星型模型（推荐）：
              日期表
                 │
产品表 ─── 报工事实表 ─── 设备表
                 │
              人员表

雪花模型（不推荐）：
              日期表
                 │
产品表 ─── 报工事实表 ─── 设备表 ─── 设备类型表
                 │
              人员表 ─── 部门表 ─── 工厂表

Power BI 里推荐星型模型：维度表直接连事实表，不做多级规范化。原因是：

1. 查询性能更好（减少 JOIN 层数）
2. 用户更容易理解
3. Power BI 的引擎（VertiPaq）对星型模型优化最好

4.3 表关系的设置

常见关系场景：

4.4 建模的十个检查项

• 有独立的日期表，并已"标记为日期表"
• 日期表与所有事实表建立了关系
• 所有关系方向正确（维度 → 事实，单向）
• 没有双向关系（除非明确需要且理解后果）
• 没有未使用的列（删除）
• 数值列的数据类型正确（小数/整数/货币）
• 文本列的"按列排序"已设置（月份、星期、班次）
• 隐藏了不需要用户直接使用的字段（如 ID、排序辅助列）
• 度量值组织在文件夹里（建模 → 属性 → 显示文件夹）
• 表命名清晰（中文或英文统一，不要混合）

五、DAX：业务指标的语言

DAX（Data Analysis Expressions）是 Power BI 的公式语言。它与 Excel 公式形似，但本质不同。

5.1 两个最核心的概念

① 计算列 vs 度量值

判断规则：

• 如果这个值是用来分组/筛选的（如"是否延期"、"产量等级"）→ 计算列
• 如果这个值是用来聚合/展示的（如"总产量"、"平均良率"）→ 度量值

新手最常见的错误：把本该是度量值的东西做成计算列。后果是内存爆炸 + 结果不随筛选变化。

② 筛选上下文（Filter Context）

这是 DAX 最难也最关键的概念。

度量值的结果取决于"当前有哪些筛选在起作用"。这些筛选来自：

• 切片器（如选了"2026年8月"）
• 图表的行/列（如矩阵的行是"产线"）
• 交叉筛选（点击图表 A 的元素，会筛选图表 B）
• 筛选器面板
• DAX 内部的 CALCULATE 修改

例如同一个度量值 [总产量]，放在矩阵里按产线分行，每行显示的是"该产线在当前日期筛选下的产量"。同一个度量值，在不同位置显示不同的值——这就是筛选上下文。

5.2 基础语法

-- 简单聚合
总产量 = SUM('生产报工'[合格数])

-- 带条件的聚合
合格品数 = CALCULATE(SUM('生产报工'[数量]), '生产报工'[结果] = "合格")

-- 除法（注意防除零）
良率 = DIVIDE([合格品数], [总产量], BLANK())

-- 引用其他度量值（直接写名字，不写表名）
不良率 = 1 - [良率]

DIVIDE() vs /：

• DIVIDE(a, b) 自动处理除零，返回你指定的默认值
• a / b 除零会报错（或返回 Infinity）

永远用 DIVIDE。

5.3 CALCULATE：DAX 的灵魂

CALCULATE 是 DAX 中唯一能修改筛选上下文的函数。

CALCULATE( <表达式>, <筛选条件1>, <筛选条件2>, ... )

示例：

-- 只看 A 线的产量（忽略用户选了什么产线）
A线产量 = CALCULATE([总产量], '产线'[产线名称] = "A线")

-- 去年同期的产量
去年同期产量 = CALCULATE([总产量], SAMEPERIODLASTYEAR('日期表'[Date]))

-- 移除所有筛选（计算总计）
全厂产量 = CALCULATE([总产量], ALL('产线'))

-- 占全厂的比例
产量占比 = DIVIDE([总产量], CALCULATE([总产量], ALL('产线')))

筛选条件的写法：

5.4 迭代函数（X 函数）

SUMX、AVERAGEX、MAXX、COUNTX、RANKX 等带 X 的函数叫迭代函数，它们逐行计算然后对结果聚合。

-- 错误：先求和，再乘以单价（单价不是逐行的）
总金额 = SUM('订单'[数量]) * SUM('订单'[单价])   -- 错！

-- 正确：逐行计算 数量×单价，再求和
总金额 = SUMX('订单', '订单'[数量] * '订单'[单价])

判断规则：

• 如果计算是"先聚合再算" → 用普通聚合函数
• 如果计算是"先逐行算再聚合" → 用 X 函数

典型场景：金额计算、加权平均、按行的条件判断后聚合。

-- 加权平均单位成本
加权平均成本 =
DIVIDE(
    SUMX('库存', '库存'[数量] * '库存'[单位成本]),
    SUM('库存'[数量])
)

5.5 时间智能函数

前提：有正确配置的日期表。

示例：

-- 累计产量（年初至今）
累计产量 = TOTALYTD([总产量], '日期表'[Date])

-- 上月产量
上月产量 = CALCULATE([总产量], PREVIOUSMONTH('日期表'[Date]))

-- 环比增长率
环比 =
VAR Cur = [总产量]
VAR Prev = [上月产量]
RETURN DIVIDE(Cur - Prev, Prev, BLANK())

-- 3 个月移动平均
MA3 =
AVERAGEX(
    DATESINPERIOD('日期表'[Date], MAX('日期表'[Date]), -3, MONTH),
    [总产量]
)

VAR 的使用：VAR 定义变量，让复杂公式可读且避免重复计算。任何超过三行的 DAX 都应该用 VAR。

5.6 十五个生产管理常用度量值

以下是可以直接复制使用的模板（表名按实际替换）。

-- ① 总产量
总产量 = SUM('生产报工'[合格数量])

-- ② 不良数
不良数 = SUM('生产报工'[不良数量])

-- ③ 良率
良率 = DIVIDE([总产量], [总产量] + [不良数], BLANK())

-- ④ 计划达成率
计划达成率 = DIVIDE(SUM('工单'[实际产量]), SUM('工单'[计划产量]), BLANK())

-- ⑤ 准时交付率（OTD）
准时交付率 =
DIVIDE(
    CALCULATE(COUNTROWS('工单'), '工单'[实际完工日] <= '工单'[计划完工日]),
    COUNTROWS('工单'),
    BLANK()
)

-- ⑥ 平均工单周期（天）
平均周期天数 = AVERAGEX('工单', DATEDIFF('工单'[实际开工], '工单'[实际完工], DAY))

-- ⑦ 设备运行时间（分钟）
运行时间 = CALCULATE(SUM('设备状态'[时长分钟]), '设备状态'[状态] = "运行")

-- ⑧ 停机时间（分钟）
停机时间 = CALCULATE(SUM('设备状态'[时长分钟]), '设备状态'[状态] = "故障")

-- ⑨ 时间开动率
时间开动率 =
VAR 负荷时间 = CALCULATE(SUM('设备状态'[时长分钟]), '设备状态'[状态] <> "计划停机")
RETURN DIVIDE([运行时间], 负荷时间, BLANK())

-- ⑩ 性能开动率
性能开动率 =
VAR 理论时间 = SUMX('生产报工', '生产报工'[合格数量] * '生产报工'[标准工时秒]) / 60
RETURN DIVIDE(理论时间, [运行时间], BLANK())

-- ⑪ OEE
OEE = [时间开动率] * [性能开动率] * [良率]

-- ⑫ 平均故障间隔 MTBF（小时）
MTBF_小时 =
VAR 故障次数 = CALCULATE(COUNTROWS('停机记录'), '停机记录'[类别] = "故障")
RETURN DIVIDE([运行时间] / 60, 故障次数, BLANK())

-- ⑬ 平均修复时间 MTTR（分钟）
MTTR_分钟 =
VAR 故障次数 = CALCULATE(COUNTROWS('停机记录'), '停机记录'[类别] = "故障")
RETURN DIVIDE([停机时间], 故障次数, BLANK())

-- ⑭ 在制品数量（WIP）
WIP数量 =
CALCULATE(
    SUM('工单'[计划数量]) - SUM('工单'[已完工数量]),
    '工单'[状态] = "已下达"
)

-- ⑮ 库存周转天数
库存周转天数 =
VAR 平均库存 = AVERAGE('库存快照'[库存金额])
VAR 日均发料 = DIVIDE(SUM('出库记录'[金额]), DISTINCTCOUNT('日期表'[Date]), BLANK())
RETURN DIVIDE(平均库存, 日均发料, BLANK())

5.7 DAX 避坑

六、可视化：图表选择与避坑

6.1 图表选择决策

6.2 必须避免的图表

6.3 IE 看板的常用视觉

OEE 看板必备元素

┌─────────────────────────────────────────────────┐
│  产线: [全部▾]   日期: [2026-08▾]   班次: [全部▾]  │  ← 切片器区
├─────────────────────────────────────────────────┤
│  ┌────────┬────────┬────────┬────────┐          │
│  │  OEE   │ 时间开动 │ 性能开动 │ 合格品率 │          │  ← KPI 卡片区
│  │ 72.3%  │ 85.1%  │ 89.2%  │ 95.3%  │          │
│  │ ▼2.1pt │        │        │        │          │
│  └────────┴────────┴────────┴────────┘          │
├─────────────────────────────────────────────────┤
│  OEE 趋势（近 30 天折线，含目标线 85%）            │  ← 趋势区
├──────────────────┬──────────────────────────────┤
│  停机帕累托图     │  各设备 OEE 对比（条形）        │  ← 分析区
├──────────────────┴──────────────────────────────┤
│  工单明细表（可下钻）                              │  ← 明细区
└─────────────────────────────────────────────────┘

设计逻辑：从总览 → 趋势 → 归因 → 明细，符合"发现问题 → 分析原因 → 定位到具体对象"的思考路径。

6.4 配色与格式

6.5 交互设计

"编辑交互" 是做出专业看板的关键：默认所有视觉对象互相筛选，但有时你不希望某个卡片被筛选（比如"全厂总计"应该固定），就要手动设为"无"。

七、发布、刷新与权限

7.1 发布流程

Power BI Desktop（本地开发）
        ↓ 发布
Power BI Service（云端，app.powerbi.com）
        ↓ 配置网关
定时自动刷新
        ↓ 共享
用户通过各种终端（网页 / 手机 App / Teams）查看

7.2 网关（Gateway）

问题：Power BI Service 在云端，数据库在内网，云端连不上内网数据库。

解法：在内网一台常开的机器上安装 Power BI Gateway（数据网关），它主动连接云端，建立通道。

配置要点：

• 网关机器必须常开（一般是服务器，不是普通办公电脑）
• 用专用服务账号，不要用个人账号（人员离职会导致失效）
• 在 Power BI Service 的"数据集 → 设置 → 网关"里关联
• 数据源凭据需要重新输入一次

7.3 刷新计划

设定刷新时间的原则：

• 在数据更新完成之后（如夜班结束 + 数据同步完成 → 早上 7:00 刷新）
• 避开业务高峰
• 多次刷新错开

增量刷新：如果数据量很大，可以配置增量刷新（只刷新最近 N 天），需要 Premium 或 PPU。

7.4 行级安全（RLS）

场景：各车间主任只能看自己车间的数据。

做法：

1. 建模 → 管理角色 → 新建角色（如"车间主任"）
2. 给角色设置筛选规则（DAX 表达式）：

   -- 只能看自己车间的数据
   '产线'[车间代码] = LOOKUPVALUE(
       '用户权限表'[车间代码],
       '用户权限表'[账号], USERPRINCIPALNAME()
   )
   

3. 在 Power BI Service 里把用户加到对应角色

关键点：需要一张"用户权限表"，记录每个账号能看哪些数据。这张表可以维护在 Excel 里（放在 SharePoint）或数据库里。

7.5 共享方式

安全提醒："发布到 Web"会生成公开可访问的链接，任何人都可以通过搜索引擎找到。制造业的生产数据绝对不能这么做。

八、看板设计的七个原则

原则 1：一屏一决策

每个页面回答一个明确的问题：

不要试图在一个页面里放所有信息。 一张塞满 20 个图表的页面，等于没有页面。

原则 2：金字塔结构

上层：结论（KPI 卡片，是否达标）
中层：趋势（是偶发还是持续）
下层：归因（是什么导致的）
底层：明细（具体是哪些对象）

用户的视线从上往下，思维也是从"有没有问题"到"怎么办"。

原则 3：异常优先

看板的价值在于让用户立刻看到异常，而不是展示一堆正常数据。

做法：

• 用条件格式（红色高亮低于目标的）
• 用 KPI 视觉对象（显示与目标/上期的差异）
• 用排名（只显示最差的 Top 5）
• 设置警报（Power BI 可以在指标超阈值时发邮件）

原则 4：目标可见

没有对比就没有判断。"OEE = 72%" 是好是坏？不知道。但"OEE = 72%，目标 85%，低于目标 13 个百分点"就一目了然。

每个 KPI 都应该有目标线。目标可以来自：

• 历史最好水平
• 行业标杆
• 年度预算
• 理论值

原则 5：口径透明

看板上每个指标都应该能查到定义。做法：

• 在报告里加一个"指标定义"页面，写清楚每个指标的计算公式和数据源
• 用工具提示（Tooltip）显示简要说明
• 在指标名称旁加信息图标

这一条决定了看板能否被信任。 如果有人质疑"这个数字怎么算的"，你必须能立刻指出定义在哪里。

原则 6：口径统一

在看板上线前，必须让相关部门对指标定义达成一致并签字。

典型争议点：

• 良率：一次通过率 vs 最终良率 vs 直通率
• 停机：是否含计划停机、是否含换型
• 产量：报工数量 vs 入库数量 vs 合格数
• 时间：自然日 vs 工作日
• 交付：按订单行 vs 按订单

建议：在指标定义页写明"本看板的良率 = 一次检验合格数 / 检验总数，不含返工后合格"。

原则 7：移动端适配

很多主管是在手机上看的。Power BI Desktop 支持移动布局视图（视图 → 移动布局），可以把视觉对象拖成手机版的单列布局。

不做移动端适配的报告，在手机上打开会是一堆挤在一起的小图，基本不可用。

九、落地案例：OEE 管理驾驶舱

9.1 需求

某汽车零部件厂，3 个车间、12 条产线、200+ 台设备。需求：

• 厂长：一屏看到全厂 OEE 及趋势，能下钻到车间、产线
• 车间主任：看本车间的 OEE 三因子分解和停机帕累托
• 设备工程师：看单台设备的停机记录明细、MTBF/MTTR

9.2 数据源

9.3 数据模型

日期表 ──┬── 设备状态事实表（equip_code, status, start, end, duration_min）
         └── 报工事实表（wo_no, equip_code, good_qty, defect_qty, report_time）
         └── 停机记录表（equip_code, start, end, reason_code, duration_min）

设备维度表（equip_code, equip_name, line_code, wc_code, model）──┐
产线维度表（line_code, line_name, workshop, target_oee）          ├── 各事实表
原因代码表（reason_code, reason_name, category）                  │
产品维度表（product_code, product_name, std_time_sec）────────────┘

9.4 关键度量值

-- OEE 三因子 + OEE（见 5.6 节）

-- OEE 与目标对比
OEE_差距 = [OEE] - SELECTEDVALUE('产线'[目标OEE], 0.85)

-- OEE 状态（用于条件格式）
OEE_状态 =
SWITCH(
    TRUE(),
    [OEE] >= 0.85, "达标",
    [OEE] >= 0.70, "改善中",
    "未达标"
)

-- 停机帕累托累计占比
停机累计占比 =
VAR 当前累计 =
    CALCULATE(
        [停机时间],
        FILTER(
            ALLSELECTED('原因代码表'),
            [停机时间] >= SELECTEDVALUE('原因代码表'[该原因停机时间])
        )
    )
VAR 总计 = CALCULATE([停机时间], ALLSELECTED('原因代码表'))
RETURN DIVIDE(当前累计, 总计, BLANK())

-- 最大损失原因（用于卡片显示）
最大停机原因 =
CALCULATE(
    SELECTEDVALUE('原因代码表'[原因名称]),
    TOPN(1, ALLSELECTED('原因代码表'), [停机时间])
)

-- Top N 停机设备
最差设备 =
CALCULATE(
    SELECTEDVALUE('设备维度表'[设备名称]),
    TOPN(1, ALLSELECTED('设备维度表'), [OEE], ASC)
)

9.5 页面结构

9.6 实施效果（典型）

一个上线的 OEE 看板通常带来：

• 会议时间缩短 40%~60%（不再对数字）
• 数据口径统一（各部门不再各报各的）
• 问题响应速度提升（发现异常从"月后发现"变成"当天发现"）
• 改善方向明确（帕累托直接指出最大损失源）

但要提醒：看板本身不产生改善，它只是让问题可见。真正的改善来自后续的行动。一个没人看的看板，等于没有看板——所以上线后要推动使用（如每天的例会必须投屏看板）。

十、学习路径与常见误区

10.1 学习顺序

学习资源：

• Microsoft 官方文档（learn.microsoft.com/power-bi）— 权威且免费
• SQLBI（sqlbi.com）— DAX 领域最权威，有免费文章和 DAX Guide
• 《DAX 权威指南》（The Definitive Guide to DAX，Marco Russo & Alberto Ferrari）— DAX 圣经
• Power BI 官方示例数据集 — 边学边练

10.2 五个常见误区

10.3 与 Excel 的关系

Power BI 不会取代 Excel，两者是分工关系：

Power BI 的一个便利：分析结果可以导出到 Excel（且保持连接），业务人员熟悉的 Excel 操作依然能用。

结语：看板的终点是决策

最后一个建议：做看板之前先想清楚"看了之后要做什么决定"。

如果一个指标看与不看，行为都一样，那它就不该出现在看板上。比如"本月累计开机时长"——看了能做什么？没有行动对应。而"停机时间 Top 3 原因"就能直接指向行动（安排改善）。

好的看板是行动清单，不是数据展示墙。

衡量一个看板好不好，有一个简单的标准：每天看完看板后，能立刻说出今天要做的三件事吗？ 如果能，这个看板就成功了。

相关阅读

• Minitab 工业工程实战指南：从数据到结论的完整链路：工业工程领域出镜率最高的统计软件。本文按拿到数据后的真实使用顺序组织：数据导入清洗、图形化汇…
• 工业工程必备软件地图：从 Excel 到 FlexSim，每个阶段该学什么：按学习阶段给出 IE 的软件全景图：Excel、统计分析、仿真建模、CAD、企业系统，并给出…
• 工业工程师的 Excel 实战手册：从工时分析、过程能力到线平衡的 30 个技法：面向 IE 场景的 Excel 实操手册：连续测时数据差分还原、IQR 与 3σ 异常值剔除…
• 工业工程数据与指标看板：从指标定义、采集口径到可视化落地的完整手册：从指标定义卡 12 要素讲到看板落地：OEE 三种分母口径对照（负荷 75.45% / 计划…
• SQL 工业工程数据分析实战：从 MES 取数到指标看板：IE 日常有 60% 的时间花在等数据上。本文从真实取数场景出发，讲透 SQL 核心语法（S…