Odoo 设备维护为什么不只是“提个工单”：MTBF、MTTR、下一次故障预测与设备责任边界讲透

先说结论

Odoo Maintenance 不是“设备版工单系统”，而是一套围绕被维护对象展开的可靠性管理模型。

从 /home/ubuntu/odoo-temp/addons/maintenance/models/maintenance.py 看，官方不是只建了一张 maintenance.request，而是把整个体系分成了三层：

• maintenance.equipment.category：设备分类与默认责任设置
• maintenance.equipment：具体设备台账
• maintenance.request：每一次维护请求

更关键的是，设备和其他可维护对象还共用了 maintenance.mixin，把这些指标沉到底层：

• maintenance_count
• maintenance_open_count
• mtbf
• mttr
• latest_failure_date
• estimated_next_failure

所以它真正想解决的问题不是“工单流转”，而是：

一台设备从上架到报修、维修、恢复，再到下一次可能出故障，这条链怎么被持续追踪。

第一层：为什么维护系统的中心不是工单，而是设备

很多人第一次接触 Maintenance，会下意识把它和 Helpdesk 对比。

但源码很清楚，核心对象其实是 maintenance.equipment，不是 maintenance.request。

设备上直接挂着：

• 所属分类
• 所有人 owner_user_id
• 供应商
• 型号与序列号
• 保修到期
• 维护团队
• 技师
• 所有关联维护记录

这表示 Odoo 的维护模块关注的是“资产状态”，不是单次服务对话。

如果你的业务重点是：

• 某台机器一年修了几次
• 哪类设备故障率高
• 哪个团队负责这类资产
• 最近一次故障后多久又坏了

那你就会发现它和 Helpdesk 完全不是一回事。

第二层：maintenance.mixin 为什么很关键

maintenance.mixin 是这套设计最有价值的地方之一。

它把维护相关的共性能力抽成了一个抽象层，包含：

• 公司归属
• 维护团队
• 技师
• 维护计数
• expected_mtbf
• mtbf
• mttr
• estimated_next_failure
• latest_failure_date

这说明官方的思路不是“只有设备能维护”，而是“任何可维护对象都可以拥有同一套可靠性指标”。

这种抽象很值得学习，因为它让业务扩展更自然：

• 今天维护的是办公设备
• 明天也可以维护机器、模具、设施
• 底层分析口径仍然统一

也就是说，维护模块并不是从工单出发，而是从可维护资产出发。

第三层：MTBF 和 MTTR 在 Odoo 里不是报表装饰

_compute_maintenance_request() 非常关键。

在这个方法里，系统会筛出：

• 纠正性维护 corrective
• 且阶段已完成 stage_id.done

然后计算：

• mttr：平均修复时长
• latest_failure_date：最近故障日期
• mtbf：平均故障间隔
• estimated_next_failure：预计下次故障时间

注意这里的思路非常工程化。

MTTR

它不是“所有工单平均关闭时间”，而是基于完成的 corrective request，按 close_date - request_date 计算。

MTBF

它也不是拍脑袋估计，而是用：

• 最近一次故障日期
• 减去设备生效日期 effective_date
• 再除以历史故障次数

这当然不是工业级最复杂算法，但已经足够表达一种明确态度：

维护不是事后记录，而是要尽量形成可预测指标。

这对于设备管理、制造现场、IT 设施运维都很有价值。

第四层：为什么分类和默认责任人这么重要

maintenance.equipment.category 上不仅有设备数量和维护数量，还有：

• technician_user_id
• equipment_properties_definition
• 当前维护数量统计

而 maintenance.equipment 在 onchange(category_id) 时，会把分类上的技师带下来。

这说明在 Odoo 的设计里，维护不是完全“报了再分派”，而是鼓励你先建立责任边界：

• 哪类设备默认归谁管
• 哪类资产有哪些属性
• 哪个团队是这类设备的默认处理方

这样做的价值很现实：

• 新设备建档更快
• 维护请求落单时少一层人工分流
• 统计能按分类汇总出故障面

所以分类在这里不是报表标签，而是组织维护流程的骨架。

第五层：为什么请求和设备必须双向关联

maintenance.request 里最关键的字段之一是 equipment_id，同时 category_id 又从设备反向 related 过来。

这意味着维护请求不是一张脱离资产的工单，而是必须落到具体设备或可维护对象上。

这样系统才能顺着请求反推出：

• 这是谁的设备
• 属于哪个公司
• 默认技师是谁
• 历史请求有多少
• 这次会不会影响可靠性指标

如果请求不挂设备，MTBF、MTTR、下次故障预测这些能力就失去基础了。

所以实施时千万别把维护模块改成“纯描述型工单”，那样会把它真正有价值的那一层削掉。

第六层：为什么有些删除会被禁止

源码里还有几处边界控制很有意思：

• 有设备或维护请求的分类不能随便删
• 设备序列号要求唯一
• 某些责任变更会自动订阅消息

这些设计的共同点是：

维护系统默认把历史连续性看得很重要。

因为一旦你允许随意删分类、改序列号、抹掉关联，后面的统计和责任链都会断。

这和纯任务协作工具的思路很不一样。

最容易误解的三个点

误区一：Maintenance = Helpdesk for equipment

只看界面可能像，但它的核心是资产可靠性，不是客服对话。

误区二：MTBF 和 MTTR 只是好看的 KPI

不是。它们直接来自维护请求历史，是系统把“过去修过什么”转成“未来大概会怎样”的关键桥梁。

误区三：设备分类只是方便筛选

也不是。分类承载了默认责任、属性定义和统计口径，是流程设计的一部分。

实战上最有价值的使用方式

如果你想把这套模块用顺，建议按这个顺序落地：

1. 先把设备分类、技师责任和属性定义好
2. 再把关键设备完整建档
3. 维护请求必须尽量绑定设备
4. 区分 corrective 和 preventive 的统计口径
5. 定期回看 MTBF、MTTR 和预计下一次故障日期

这样你得到的就不只是“工单完成率”，而是更接近设备管理者真正关心的东西：

• 哪台设备不稳定
• 修一次要多久
• 什么时候可能再坏
• 团队有没有把问题越修越稳

最后一句

Odoo Maintenance 最值得肯定的，不是它能拉个看板，而是它试图把维护这件事从“有人报修了再处理”推进到“设备可靠性可持续观察”。

这也是为什么 maintenance.mixin、maintenance.equipment 和 maintenance.request 要被设计成现在这个样子：

• 不是只记录事后动作
• 而是为持续维护和预测留数据结构

这才是它和普通工单系统真正拉开差距的地方。