产能负荷分析怎么看，从工作中心过载追到订单和工序

先对齐范围、时间桶和单位

先写清这张负荷表要支持哪个决定。是看下周某个工作中心能否承接现有订单，找出月底前的过载，还是判断一张新订单是否值得进入详细排程。资源范围、分析时界、数据截止时间、工厂时区和负责人都要固定。

资源层级不能含糊。工作中心可能汇总多台机器或多组人员，组内资源却未必完全可替代。Microsoft 和 Oracle 的官方资料都展示了工作中心汇总与单项资源之间可能存在差异。工作中心看起来有余量，不能直接推断每台适用机器都有空位。

时间桶和单位也要一致。日负荷、周负荷和班次负荷会呈现不同问题，机器小时、人员小时、件数和重量更不能直接相加。若使用件数或重量，要保存与标准工时之间的换算来源和生效日期。

从日历算出可用产能

可用产能从资源日历开始。工作日、班次、休息、假期、维护、停机、缺勤和临时例外都会改变一个时间桶内真正能够用于计划的时间。没有配置的工作日也可能在系统里表现为零产能，不能一律用每天八小时替代。

并行资源数量、利用率设置和效率参数也会改变可用产能或排程持续时间。Microsoft 与 Oracle 的文档分别展示了这些参数怎样影响产能或排程持续时间，两家的字段与公式并不相同。公开分析应显示采用了哪些参数，不能把某个厂商的 efficiency 或 utilization 直接套到另一套系统。

日历产能仍是模型输入，不是实时设备状态。每次分析都要保留日历版本、例外来源和最后成功刷新时间。临时停机或缺勤还没有进入数据时，应把它标为未知条件，不能让页面上的余量掩盖现场已经发生的变化。

从订单工序汇总负荷

负荷来自纳入范围的订单工序。先规定哪些计划订单、确定计划订单、已下达生产订单和已开工工作进入计算，再按工艺路线汇总准备时间、加工时间、剩余数量和目标资源。Microsoft Business Central 的负荷说明提供了一种订单状态与工时口径，其他系统仍要核对自己的纳入规则。

工艺版本、工序先后、适用资源和标准工时决定负荷落到哪里。订单数量变化、替代路线或资源不同，都会改变工作中心上的能力需求。等待、搬运和外协时间是否占用内部资源，也要在第一次计算以前说清。

已报工进度尤其容易让负荷失真。已完成的工作没有冲减，会制造虚假过载；未报工却已经消耗的时间，又会制造虚假余量。缺少进度、工时或资源映射时，记录应进入待核清单，不能静默补零。

比较负荷、产能与剩余

比较时把每个数字留在同一个资源、时间桶和单位里。本文把尚未扣减订单负荷的日历能力称为可用产能，把相减后的值称为剩余产能。可用产能减去订单负荷得到剩余产能，订单负荷除以可用产能得到计划负荷率。部分产品会用 available capacity 指相减后的余额，读取现有系统字段时要先核对定义。可用产能为零时，应直接显示无可用能力，不能用普通百分比掩盖分母问题。

剩余产能为负，表示当前范围内这个资源和期间发生过载。它是需要下钻的风险信号，不是订单已经确定延期。剩余为正也只说明汇总桶里还有模型余量，不证明具体工序能满足先后关系、物料时间和可用资源。

负荷阈值由企业按资源、缓冲和计划目标确认，没有适用于所有工厂的健康百分比。计划负荷率也不等于实际设备利用率，更不能直接推出设备综合效率。实际设备利用率需要设备运行状态和周期时间。OEE 还需要开机时间、运行速度和质量数据。

可用产能

同一资源和时间桶内，由日历、班次、例外、资源数量及已声明参数形成的有效能力。

订单负荷

纳入范围的订单工序在同一单位下形成的准备、加工和其他已声明能力需求。

剩余产能

可用产能减订单负荷。负值表示当前口径过载，正值只表示汇总桶还有余额。

计划负荷率

订单负荷除以可用产能。必须同时显示分子、分母、资源、时间桶和采用的规则。

把过载追到订单和工序

过载先告诉团队哪个资源、哪个期间需要查。下一步要展开形成这段负荷的订单号、工序号、订单状态、准备与加工时间、计划开始结束时间、剩余工作和锁定状态。Microsoft 的任务清单和 SAP 的能力页面都展示了从资源负荷回到订单工序的产品级做法。

下钻以后先排除口径错误。重复订单、过期工艺、错误资源、未冲减报工、失效日历和单位换算都可能把一个数据问题画成生产瓶颈。工作中心汇总还要继续核对真正适用的机器、人员或工具，避免把不能互换的资源合并。

经过核对的过载仍只是候选瓶颈。它可能来自交期集中、准备时间、资源停机、受保护工作或某条路线的分配方式。负荷图负责缩小调查范围，根因和受影响订单要靠订单明细、工艺关系与现场事实一起确认。

用同一快照比较处理方案

确认过载以后，再分别形成处理候选。可以比较移期、替代资源、拆批、调整顺序、经批准的班次变化或外协。只有已经获得授权并写入适用日历的额外班次，才能作为候选产能进入计算。

每个候选应使用同一组订单、数据截止点和基线，只改变已经说明的一项策略或条件。随后列出原订单的日期、资源、顺序和风险怎样变化。若订单、日历、工艺和规则一起改动，团队就无法说明结果为何不同。

处理方案一定带有取舍。把一张订单移出过载桶，可能会占用另一段产能、增加换型或推迟其他承诺。软件可以整理候选与受影响订单，企业授权人仍要决定是否允许加班、外协、拆批或调整客户日期。

分开负荷视图与详细排程

日或周负荷适合定位资源压力，却没有给每道工序找到具体开始时间。Microsoft 的生产流程资料把较粗的工序排程与带具体日期、时间和资源的作业排程分开。各家产品名称不同，分析粒度的差异仍然存在。

一个周桶有余量，周一上午仍可能没有连续时段容纳某道工序。工序先后、具体资源、物料可用、换型、保护范围和其他订单都会影响实际落位。详细有限产能排程需要继续检查这些条件，不能把汇总余额直接写成订单排得下。

因此，负荷分析的交付物应是可核对的受压资源、过载期间、订单工序明细、数据缺口和处理候选。它为详细排程划定重点，不取代排程结果。需要了解工序怎样落到有限资源，可以继续阅读有限产能排程指南。

保留计划员确认与数据边界

每份结果都要显示数据截止点、时区、订单范围、日历版本、工艺版本、刷新状态、默认值和遗漏项。计划员需要知道这张表代表哪个时点，哪些现场事实已经进入，哪些仍要人工补充。没有经过核验的刷新机制，不应称为实时。

Oracle 的排程工作流把刷新、求解、复核、调整与发布分成不同动作，说明候选结果与生产记录之间可以有清楚的控制边界。这只是该产品的流程示例，不表示每套 APS 都使用同样的状态，也不证明 Kavop 已有相同写回能力。

Kavop 当前可以读取 ERP 导出、Excel、SQL、现有排产表和现场规则，生成可比较方案，并解释纳入范围的晚单、瓶颈和插单影响。第一轮保持只读，由计划员核对负荷口径、候选和剩余风险。产品支持导出，受控发布仍只覆盖部分范围，不自动写回 ERP 或 MES。