[公开] FAB KPI体系：从数据到指标的映射

【摘要】同一个OEE，制造部算出来85%，设备部算出来72%，报表系统显示78%。指标打架的根源不是算法不同，而是从原始数据到指标之间的映射链路从来没有被写下来过。本文给出FAB三层KPI架构、指标字典的必填字段、数据血缘的落地方法，以及口径冲突的仲裁机制。

分类：数据工具　|　发布日期：2026-08-19　|　阅读定位：数据工程师 / 制造IT / 运营分析 / 数字化负责人

一、问题背景：三个部门算出三个OEE

去年年中的一次经营分析会上，出现了一个很尴尬的场面。总经理问上个月光刻区的OEE是多少，制造部报八十五点二，设备部报七十二点四，而大屏上的数字是七十八点九。三个数字，三份材料，都是从同一套MES数据库里取的数。会开了四十分钟，没讨论OEE高低说明什么问题，全在争谁算得对。

后来我带人把三条口径逐层拆开，结论并不复杂。制造部把计划停机全部从可用时间里扣掉了，设备部按七乘二十四小时做分母，大屏用的是半年前某个顾问配置的规则，把工程实验批的加工时间算成了非增值时间。三方各自的逻辑在自己的场景下都说得通，但没有任何一份文档写明白各自的口径是什么，于是谁也说服不了谁。

这件事暴露的问题比OEE本身严重得多。它说明我们的数据链路里存在大量隐性约定：某个字段代表什么、某种状态该归到哪一类、异常值怎么处理，这些规则都散落在个人的脚本和报表配置里，没有集中管理。人一走，规则就失传；系统一升级，口径就漂移。

解决这类问题的核心不是买一个更好的BI工具，而是建立从原始数据到指标的显式映射，并且给这套映射一个治理机制。本文讲的就是这套东西怎么搭：分几层、每层放什么、指标字典要写哪些字段、血缘怎么记录、口径冲突怎么仲裁。内容偏工程实操，不谈概念。

二、三层KPI架构：为什么必须分层

2.1 L0经营层：少而稳，一年不改

L0层是给厂长和经营会看的，数量必须控制在十二个以内。典型包括：产出片数、准时交付率、综合良率、单位成本、OEE、循环时间倍数。这一层的特点是定义必须极度稳定，一年之内不允许修改口径，因为它要支撑同比环比分析，口径一变历史数据就断了。

L0指标的另一个特点是它们大多是复合指标，由下层指标聚合而来。这就要求聚合规则本身也要固化，比如综合良率到底是各工序良率连乘，还是用出片数除以投片数直接算，两者在有返工的情况下结果不同，必须选定一种并写死。

2.2 L1部门层：可分解，半年评审一次

L1层对应到具体部门的管理动作，数量在三十到五十个之间。制造部关心WIP水位、在制品周转、瓶颈设备负载；设备部关心MTBF、MTTR、PM准时率、备件周转；质量部关心过程能力指数、异常关闭时效、客诉率；良率部门关心分层良率、缺陷密度、Top缺陷模式占比。

L1指标必须能够向上支撑L0，也就是说每一个L0指标都应该能拆解成若干L1指标的函数关系。如果某个L1指标既不能支撑L0、也不能驱动一线动作，那它大概率是历史遗留，应该在评审时砍掉。我们第一次做体系梳理时，从原有的一百四十七个指标里砍掉了六十一个，没有任何人抱怨过看不到数据。

2.3 L2作业层：可高频变化，直接连动作

L2层是给一线工程师和班组长用的，数量不限，允许各团队自建。比如某个腔体近二十四小时的颗粒趋势、某道工序的当班首件合格率、某台设备的报警频次排行。这一层的要求是与动作强绑定：看到这个数字之后，我知道下一步该做什么。如果看完不知道该干什么，这个指标就不该出现在L2看板上。

分层的最大好处是治理成本可控。L0严格管控，L1半年一评，L2放开自建但要求统一从数据服务层取数、不允许直连生产库。这样既保证了关键指标的一致性，又不至于把一线的灵活性管死。很多工厂做指标治理失败，就是因为想用同一套严格流程管住所有指标，最后一线嫌麻烦，绕开系统自己拉数据，治理形同虚设。

还有一个容易被忽略的分层维度是时间粒度。L0通常是月度，L1是周度或日度，L2可以到小时甚至分钟。粒度不同带来的一个直接问题是聚合方式：日度良率求月度良率，不能对三十个日值取算术平均，必须用当月总合格数除以总投入数，否则小批量的日子会被过度加权。这类聚合规则要在字典里逐条写死，不能依赖报表开发人员的默认理解。

分层之后还要处理一个组织问题：谁来维护哪一层。我们的分工是，L0由数据治理小组直接维护，任何变更需要厂长办公会批准；L1由各业务部门指定的指标管理员维护，变更走月度评审；L2由使用团队自行维护，只要求登记备案。这个分工把治理精力集中在最需要一致性的地方，避免了平均用力。

三、指标字典：十二个必填字段，一个都不能少

指标字典是整个体系的地基。很多工厂也有指标清单，但只写了指标名和一句话描述，这种清单解决不了任何争议。真正可用的指标字典，每个指标至少要写清楚下面十二个字段。

第一是指标编码，全厂唯一，用于系统间引用，不允许用中文名做主键。第二是中文名与英文名。第三是业务定义，用一句不含公式的自然语言说明这个指标衡量什么。第四是计算公式，必须精确到字段级别，写明分子分母各由哪些表的哪些字段构成。

第五是统计维度，说明这个指标可以按哪些维度下钻，比如按设备、按产品、按班次、按工序。第六是统计周期，是按小时、按班、按天还是按月，以及跨周期聚合时用求和还是加权平均。第七是数据源系统与表名。第八是排除规则，明确哪些数据不参与计算，这一条最容易被忽略，也最容易引发争议。

第九是目标值与阈值，包括绿黄红三档的边界。第十是指标责任人，出现异议时由谁裁定。第十一是刷新时效，说明数据延迟多久算正常。第十二是版本与生效日期，口径变更必须新增版本而不是覆盖，历史数据按当时版本口径保留。

这十二个字段里，排除规则和版本管理是最能体现成熟度的两项。以OEE为例，排除规则要回答：工程实验批算不算、设备待料算不算停机、换型时间归到哪一类、量测复测的时间怎么算。这四个问题不写清楚，两个人算出来必然不一样。我们的做法是，每个排除规则后面都附一个例子，用具体的批次号说明这种情况如何处理。

字典写完之后要做一次交叉验证，方法是找三个不同部门的人，各自按字典描述独立实现一遍计算逻辑，然后比对结果。如果三个结果不一致，说明字典描述仍有歧义，需要继续细化。我们第一轮验证时有十七个指标出现不一致，逐一修订后第二轮降到三个，第三轮清零。这个过程虽然费时，但它把所有隐性约定都逼了出来，是整个体系建设中收益最高的一步。

四、数据血缘：把映射链路显式画出来

指标字典写清楚了口径，但还不够。当某个指标数字异常时，工程师需要能快速回溯到原始数据。这就需要数据血缘，也就是从原始表字段到最终指标的完整变换链路。

图1：OEE指标的字段级数据血缘结构。异常排查沿链路自上而下下钻，平均定位时间从半天缩短到十分钟以内。

图1是我们厂OEE指标的血缘结构。从下往上看，最底层是三个源系统：设备端的状态采集、MES的工单事件、量测系统的检验结果。中间是明细层，把原始事件按设备与时间对齐，形成设备状态时序表和工单加工明细表。再往上是汇总层，按E10状态模型把时间归入六大类。最上层才是OEE以及它的三个分项：时间稼动率、性能稼动率、良品率。

把这张图画出来的直接收益是，当OEE异常时排查路径变得非常明确。数字偏低，先看三个分项哪个拖了后腿；假设是时间稼动率低，再看六大类时间分布，哪一类占比异常；定位到某一类之后，下钻到设备状态时序表，看具体是哪台设备哪个时间段。整个过程十分钟以内能完成，而在没有血缘图之前，这种排查通常要两三个人配合花半天。

血缘登记的粒度建议做到字段级。表级血缘只能告诉你这个指标用了哪几张表，字段级血缘才能告诉你改动某个字段会影响哪些指标。我们在做一次MES版本升级时，正是靠字段级血缘，提前识别出有九个指标会受到设备状态编码变更的影响，避免了升级后大面积指标失真。

血缘信息的维护是有成本的，纯靠人工登记很难持续。可行的做法是从ETL任务的SQL里自动解析出表和字段依赖，人工只补充业务语义部分。我们用开源的SQL解析库做了一个简单工具，覆盖了大约百分之八十的自动化任务，剩下百分之二十的复杂脚本仍靠人工登记，但工作量已经可以接受。

五、指标落地效果与口径仲裁机制

图2：治理前后六个维度的季度盲测评分。口径一致性与取数耗时提升最显著，自助分析能力受工具限制提升有限。

图2是体系上线前后六个指标维度的对比评分。评分方式是每季度组织一次盲测：给同一个业务问题，让三个部门各自取数回答，比较答案的一致性、取数耗时、以及能否说清口径。可以看到，口径一致性从四十二分提升到九十一分，取数耗时评分从三十五分提升到八十二分，这两项提升最明显。

相对提升较小的是指标覆盖度和自助分析能力。指标覆盖度提升有限是因为我们在治理时主动砍掉了大量冗余指标，数量减少但质量提高。自助分析能力受限于工具本身，不是治理能解决的问题，需要另外投入。

体系跑起来之后，最需要长期维护的是口径仲裁机制。指标口径的争议永远不会消失，因为业务在变。关键是要有一个明确的裁决流程，而不是每次都靠开会吵。

我们的仲裁流程分四步。第一步，提出方填写口径变更评审单，写明现行口径、建议口径、变更理由、影响的报表清单。第二步，指标责任人在三个工作日内给出初步意见。第三步，如果涉及L0指标或跨部门影响，提交数据治理小组月度会议评审。第四步，通过后新增指标版本，明确生效日期，并决定历史数据是否回溯重算。

最后一步的历史回溯是最容易出问题的环节。原则是：涉及外部披露和考核的指标，历史数据不回溯，新口径从生效日起用，报表上明确标注口径切换点；仅用于内部分析的指标，可以回溯重算，但必须保留原始版本的快照。这个原则避免了因为改口径导致过去的考核结论被推翻，减少了很多不必要的组织摩擦。

仲裁机制之外还需要一个日常的异常发现机制，否则口径漂移会在无人察觉的情况下发生。我们的做法是给每个L0和L1指标配一套自动化校验规则：数值范围校验、环比波动校验、上下层勾稽校验。勾稽校验最有用，比如各工序良率连乘应该约等于综合良率，两者偏差超过零点五个点就自动告警，这条规则帮我们抓到过三次因为ETL任务失败导致的数据缺失。

校验规则的告警要发给指标责任人而不是IT，这一点很关键。发给IT的结果通常是重跑一遍任务了事，发给业务责任人才会有人去追问为什么会出现这个偏差。我们在告警邮件里附上最近三十天的趋势图和可能的影响范围，责任人平均在半天内会给出反馈，这个响应速度是纯技术告警达不到的。

六、指标字典样例与常见口径分歧对照

下面两张表可以直接拿去用。第一张是指标字典的填写样例，展示了六个高频指标的关键字段；第二张列出实践中最容易产生分歧的口径问题以及我们采用的裁决结论。

表1：FAB指标字典填写样例（节选六个高频指标）

完整字典还应包含英文名、源表字段清单、维度列表、绿黄红阈值、刷新时效与版本号，此处受篇幅限制仅展示争议最集中的六个字段。实际模板为二十列的电子表格，配套资料包中提供。

表2：六个最高频的指标口径分歧与裁决结论

裁决结论没有绝对的对错，关键是选定之后写进指标字典并全厂执行。表中最后一列的影响指标数用于评估变更成本，超过五个的变更需要提交数据治理小组评审。

七、避坑清单与适用边界

【坑一】先买工具后定口径。很多厂的顺序反了，先上了一套BI平台，然后在平台里配指标，配到一半发现口径没定，只好边配边议，最后平台里躺着三个版本的同名指标。正确顺序是先出指标字典，再选工具落地。字典是纸面工作，成本低、迭代快，把争议在纸面上吵完，落地时会顺畅很多。

【坑二】指标数量越多越好。指标不是资产，是负债，每个指标都有维护成本。一百个指标里如果有六十个从来没人看，那这六十个指标每次系统变更都要回归测试，纯粹是浪费。建议每季度统计一次各指标的实际查看次数，连续两季度零访问的指标直接下线，需要时再恢复。

【坑三】指标责任人挂在IT部门。IT只负责实现，不应该负责定义。指标责任人必须是业务方，因为只有业务方才能判断某个口径是否符合管理意图。把责任挂给IT的直接后果是，出现争议时IT不敢裁决，只能把各方要求都实现一遍，于是同名不同义的指标越来越多。

【坑四】不做刷新时效管理。看板上显示的数字看起来是实时的，实际上可能已经是六小时前的了。这种延迟在做日常监控时会造成严重误判。每个指标都应该在看板上显示数据截止时间，并且对超时未更新的指标做显式标记，宁可显示数据异常也不要显示一个陈旧的数字。

【坑五】口径变更不留痕。改口径本身不可怕，可怕的是改完之后没人知道。所有口径变更必须留下版本记录，并且在受影响的报表上标注变更日期。我们的规则是，指标口径变更后的三十天内，所有相关报表页面顶部必须显示变更提示，三十天后才允许撤下。

适用边界方面，本文的三层架构适合中等规模以上的Fab，也就是月投片一万片以上、有独立数据团队的工厂。对于小型产线或者刚上MES的工厂，直接做三层治理成本过高，建议先把L0的十个核心指标定义清楚并保证数据准确，其余指标先允许各部门自建，等业务稳定后再逐步收拢。

需要强调的是，指标体系建设的产出不是一张漂亮的看板，而是当有人问某个数字为什么是这样时，团队能在十分钟内给出有依据的回答。这个能力才是数据治理的真正价值，看板只是它的外在表现。

七、配套资料与实战工具包

本文涉及的全部脚本、参数模板、判定表和检查清单已整理成实战工具包，拿回去改改路径和字段名就能在自己厂里跑起来，不需要从零写。

点击上方「VIP资源」下载区，免费获取以下配套资料（MES / SPC / EAP / 良率分析方向持续更新）：

FAB三层KPI字典模板（含38个常用指标的完整定义与计算口径）

OEE六大损失分类映射表（设备状态E10到OEE分子分母的逐项对应）

指标数据血缘登记表模板（源系统 / 表字段 / 转换规则 / 责任人）

指标口径变更评审单模板（含影响面分析与历史数据回溯规则）

KPI看板刷新时效性自检脚本（检测数据延迟与断档）

资料包按「可直接运行」标准整理：脚本自带示例数据，模板自带填写说明，表单自带评审要点，避免下载回去还要再花两天做适配。

────────────────────────────────────────

本文首发于博客：半导体智能制造 | MES工程师实战笔记

你在自己厂里遇到过类似情况吗？是怎么处理的？欢迎在评论区留下你的做法和踩过的坑，我会逐条回复，也会把有价值的案例补充进后续文章。

标签：FAB KPI | 指标体系 | 数据治理 | OEE | 数据血缘 | 制造数字化