本文内容
平均修复时间（MTTR）是设备发生故障后，按规定范围统计的维修或恢复过程的平均耗时。计算时，先选取一组具有可比性且已完成的故障恢复事件，将各次耗时相加，再除以事件数量：
MTTR = 维修或恢复总耗时 ÷ 已完成事件数
明确“时间”的统计口径，与除法计算本身同样重要。更换一个零部件可能只需 40 分钟，但设备无法投入生产的时间却可能长达三小时。一份有用的报表应清楚呈现这种差异，让维修团队能够有针对性地改进流程，也让生产团队根据实际可用产能制定计划。
MTTR 有助于分析以往的故障，却无法告诉你当前这次故障何时能够修复。预计何时恢复使用，需要依据维修团队的最新评估；预期一旦变化，也需要及时更新到生产排程中。SkyPlanner 将更新后的设备可用时间纳入共享排程，让你看清客户订单受到的影响，而不必手动重排每个关联的任务队列。
首先，明确 MTTR 的计时起止点
MTTR 可指平均修理时间、平均修复时间或平均恢复时间，但这些名称并不一定代表相同的时间区间。IEC 的可信性术语将 MTTR 定义为平均恢复时间。仅统计实际维修作业时间的报表，反映的范围比同时包含等待维修人员或备件时间的报表更窄。
在本指南的制造业报表示例中，MTTR 统计的是从设备发生故障，到经确认可重新投入生产的完整历时。在设备恢复可用之前，响应延迟、诊断、等待、维修、测试及必要的放行环节均持续计时。实际维修作业时间则单独记录。
请在报表上方写明这一规则，同时注明所涵盖的设备范围和报告期。如果公司、合同或报告标准规定了其他计时区间，应遵循相应定义，并清楚标注。统计边界一致后，才能将其数值与本例进行比较。
停机三小时，实际维修作业可能只占其中一小部分
假设一台加工中心在 08:00 发生故障，到 11:00 获准重新投入生产。此次故障的记录分为以下阶段：
| 阶段 | 时间区间 | 耗时 |
|---|---|---|
| 等待维修响应 | 08:00–08:30 | 30 分钟 |
| 故障诊断 | 08:30–08:50 | 20 分钟 |
| 等待所需备件 | 08:50–09:50 | 60 分钟 |
| 动手修理 | 09:50–10:30 | 40 分钟 |
| 功能测试 | 10:30–10:40 | 10 分钟 |
| 恢复生产前必要的放行检查 | 10:40–11:00 | 20 分钟 |
| 恢复过程总历时 | 08:00–11:00 | 180 分钟 |
在本例中，单独统计的实际维修时间包括故障诊断、实际修理和功能测试：20 + 40 + 10 = 70 分钟。从故障发生到恢复可用的总历时为 180 分钟。两个数值都没有错，只是回答的问题不同。
区分这两种时间，才能找准改进方向。即使缩短了更换部件所需的 40 分钟，也无法消除等待备件的那一小时。反过来，备件供应更及时，也解决不了故障诊断困难的问题。
本例中的各个阶段依次进行，但在实际故障处理中，有些工作可能同时开展。总历时不能重复计算：两名技术人员共同工作 40 分钟，并不意味着停机 80 分钟。人工工时可用于分析维护成本，但不能与设备实际经历的时间混为一谈。
不要将无关损失计入故障事件
设备满足约定的恢复使用条件时，故障事件就已结束，而不是等到之后有人关闭工单时才结束。如果设备在 11:00 已恢复可用，但下一张订单的物料直到中午才到位，那么多出来的这一小时属于待料时间，不应再计入恢复历时。
同样，计划保养、正常换型和等待操作人员，也不能一概视为故障修复。这些损失应按各自类别记录，而不是将所有停机时间都计入 MTTR。本报表衡量的是所定义的设备故障发生后，恢复可用所需的时间，而非工厂的全部停机时间。
选取一组具有可比性的已完成恢复事件
先从一台设备入手，或选取设备本身及故障类型确实具有可比性的一组设备。更换一个小型传感器和进行一次大修，都可能符合纳入统计的条件，但如果只计算平均值、不说明各类事件的构成，就可能掩盖真正需要解决的问题。
编制月报时，一种可行的规则是纳入当月完成恢复的事件，并按每次事件的完整历时计算，即使该事件始于上个月。分母应为这些已完成事件的数量，而不是当月上报的全部故障数，也不是维护工单的所有明细行数。
每个月都应采用同一套规则，并保留原始记录。尤其要注意以下几点：
- 同一次尚未排除的故障只使用一个事件编号。出现多条报警、由多名技术人员参与，或涉及多项工单任务，并不一定意味着发生了多次恢复事件。
- 未完成的事件也要列示。月末仍未完成恢复的维修，尚无最终恢复历时。应单独列出其截至当前已持续的时间和状态，不要将其当作耗时为零的已完成维修。
- 核对时间戳。录入记录的时间不一定就是故障发生、响应或恢复的时间。如果故障发生时间未知，应明确标注实际掌握的故障发现时间，不要臆造一个更早的时间。
- 明确说明排除项。对于时间戳缺失、记录已取消以及未纳入计算的事件类别，都应作出说明。不能仅仅因为一次耗时较长的维修会拉高平均值，就将符合统计条件的事件剔除。
如果一次长时间故障尚未恢复，仅统计已完成事件的报表就可能显得格外理想。因此，平均值旁边还应列出未完成事件清单。如果改为选取报告期内发生的故障，就应持续跟踪这批事件直至恢复，并说明尚未完成的事件如何处理。不要在这两种方法之间切换而不作说明。
MTTR 计算示例
假设同一台设备在报告月份内有四次故障完成了恢复。每次事件都按上述总历时规则计时。表中另列实际维修时间，是为了说明两者的区别，而不是将其加到总历时中。
| 已完成恢复的事件 | 从故障发生到恢复可用的总历时 | 实际维修时间 |
|---|---|---|
| A | 90 分钟 | 60 分钟 |
| B：08:00–11:00 的示例 | 180 分钟 | 70 分钟 |
| C | 150 分钟 | 110 分钟 |
| D | 420 分钟 | 240 分钟 |
| 合计 | 840 分钟 | 480 分钟 |
主要指标计算如下：
按恢复总历时计算的 MTTR = 840 分钟 ÷ 4 次事件 = 210 分钟，即 3.5 小时。
单独计算的平均实际维修时间为：
480 分钟 ÷ 4 次事件 = 120 分钟，即 2 小时。
在本例中，如果只报告“MTTR：2小时”，却不注明这仅指实际维修时间，就会低估测得的恢复全程用时。而只报告3.5小时、不说明其定义，也会让读者无法确定其中包含了哪些环节。
累加时长前，先统一单位。90分钟是1.5小时，不是0.90小时。如果没有符合统计条件且已完成恢复的事件，这组数据就没有可供计算的实测平均值；应将事件数报告为零，平均值标为不可用，而不是将MTTR记为零分钟。
计算一组设备的总体结果时，应将纳入统计的各次事件时长相加，再除以这些事件的总数。各台设备的维修次数不同时，不要直接对各设备的平均值再取平均。同时保留按设备和故障类型细分的数据，避免汇总结果掩盖个别设备或某类故障的严重问题。
怎样的MTTR才算好？
判断MTTR是否理想，要看它是否反映了恢复流程的实际改善：衡量指标须有实际意义，统计口径须保持一致，改善也不能以降低恢复结果要求为代价。不存在一个以小时为单位、适用于所有生产设备和故障类型的统一目标。
应在相近条件下，将设备的表现与其自身基准比较。在把平均值下降归功于维修表现改善之前，先检查故障事件的构成、各班次人员覆盖、维护方式或报告规则是否发生了变化。即使团队表现同样出色，发生几次简单故障的月份，数据也可能比发生一次复杂故障的月份更好看。
分析平均值时，还要结合事件数、总损失时间、每次事件的时长，以及造成延误的环节。在上述四次事件的示例中，恢复全程用时从短到长依次为90、150、180和420分钟。中位数为165分钟，平均值则为210分钟。最后一次事件耗时较长，值得调查；不应为了让两个数值一致而将其删除。
MTTR本身也无法说明设备故障发生的频率。平均故障间隔时间（MTBF）衡量的是可修复设备平均每发生一次故障所对应的运行时间。频繁发生的短时故障与偶尔发生的长时故障，即使总损失时间恰好相近，也需要采取不同的改进措施。
最重要的是，3.5小时不是下一次维修的倒计时。当前故障可能需要不同的零件、专业人员或验证工作。可以用具有可比性的历史记录作为讨论参考，再请维护团队给出当前评估，并确定下次复评时间。
减少真正阻碍生产恢复的延误
在决定采取什么措施之前，先按阶段拆解耗时较长的事件。最有效的改进未必是加快现场维修操作，也可能是消除开工前的等待。
如果响应缓慢，应检查故障信息如何传达给负责人，以及班次之间如何交接处理责任。与一句笼统的“生产停了”相比，提供设备编号、观察到的故障现象和明确的升级处理路径，更有助于维护人员着手处理。
如果诊断占用的时间最多，应让相关设备资料、故障记录和专业知识更便于获取。与维护及工程团队一起复盘反复发生的故障。反复复位设备，可能缩短记录中单次停机的时长，却没有解决故障原因。
如果等待零件占用的时间最多，应查清需要什么零件、当时如何确认所需零件，以及为何无法及时取得。有针对性地改善关键备件的供应或识别方式，可能比所有零件都备库存更有效。在上述三小时的示例中，60分钟的零件等待显然值得调查，但这并不能证明某项库存政策已经有了充分依据。
如果实际修理操作耗时最长，应检查准备工作、检修部位是否便于接近、工具、作业指导以及任务所需技能。如果测试或放行是瓶颈，应协商好如何让必要人员和检查工作及时就绪。改进的方向是为恢复投产做好更充分的准备，而不是跳过验证，让计时提前结束。
为选定的措施指定负责人，并复盘后续发生的同类可比事件。既要持续关注各阶段用时，也要关注恢复全程用时。如果修理环节省下的时间只是转移成了其他等待，或者维修不彻底导致不久后再次中断，那么缩短修理环节对生产的价值就很有限。
随维修进展及时更新生产计划
改善今后的故障恢复是一项任务，保障当前对客户的交付承诺则是另一项任务。生产现场不能等到月底算出平均值，才决定接下来安排什么生产。
假设维护团队最初预计一台加工中心将在11:00恢复可用，之后的评估却将预计时间推迟到14:00。历史MTTR没有变化，但等待订单可用的产能已经变了。其中一张订单在机加工后还需要检验，而可替代的加工中心已经安排了另一位客户的生产任务。
SkyPlanner APS可将这项产能变化纳入相互联动的生产排程。将维护团队评估确认的不可用时段记录为工作中心例外。当预计恢复时间变化时，更新时间范围并重新计算。SkyPlanner的人工智能排程引擎Arcturus会根据已记录的产能，以及您配置的资源、工序依赖关系、优先级和锁定设置，为受影响且可参与排程的工序安排生产。甘特图会显示计算后的生产顺序。
按14:00恢复可用来评估：等待中的机加工任务完成后，是否仍有足够时间进行检验和交付？如果合适的替代设备可以承接某道工序，也要检查该资源上已有的生产安排。对于已经开工的任务，需要单独决定如何恢复执行；重新计算等待队列，不能代替对中断生产任务状态的确认。
这样可以减少手动重排相互依赖的任务队列的工作，并为交付决策提供更清晰的依据。维护团队负责评估当前恢复情况，您决定生产优先级。Arcturus则负责对相互关联的生产任务进行排程计算，无需您逐台设备调整任务清单。
这正是在推进维修改进的同时选择SkyPlanner的理由：设备预计可用时间一经调整，就能反映到受影响的订单和下游工序安排中。如果仍有不确定性，应约定何时再次评估这一预期，并在获得更准确信息时及时更新排程。
查看一次故障停机延长对交付的影响
有用的MTTR报告会说明衡量了什么、平均值来自哪些事件，以及应从哪里着手改进。有用的生产计划则会告诉您，在当前维修按实际进展推进期间，该如何安排生产。将这两方面的决策衔接起来，才能避免扎实的维护分析最终只留下一个孤立的月度数字。
SkyPlanner可通过其开放的REST API与任何ERP或MES集成，让相互联动的排程建立在您现有的订单和生产信息之上。
预约SkyPlanner演示，带上近期一次故障的情况、调整后的预计恢复投产时间，以及需使用该资源的客户订单。请演示人员展示哪些等待工序会调整、下游会受到什么影响，以及哪些交付承诺需要重点关注。如果您想先自行探索，可以使用演示数据试用SkyPlanner，看看产能变化如何改变排程。
Jussi Mäntylä
生产计划专家，SkyPlanner
