1. 项目背景与需求分析
在制造业生产车间中,设备故障报修和工单管理一直是影响生产效率的关键环节。传统纸质工单或电话报修方式存在响应慢、流转效率低、状态不透明等问题。我们团队为某中型制造企业开发的这套微信小程序,正是为了解决这些痛点。
这个项目的核心诉求可以归纳为三点:
- 实现设备故障的快速报修(从发现到响应控制在15分钟内)
- 全流程电子化工单流转(状态实时可查)
- 建立设备维修知识库(积累解决方案)
2. 系统架构设计
2.1 技术选型方案
前端采用微信小程序原生开发,主要考虑因素:
- 车间工人普遍使用微信,无需额外安装APP
- 原生组件对扫码、拍照等硬件功能支持更好
- 开发成本低于跨平台方案
后端技术栈:
- Spring Boot 2.7 + MyBatis Plus
- MySQL 8.0(工单主数据)
- Redis 7.0(缓存高频访问的设备信息)
- MinIO(存储故障照片/视频)
2.2 核心业务流程设计
mermaid复制graph TD
A[设备异常] --> B(扫码报修)
B --> C{自动派单?}
C -->|是| D[分配维修组]
C -->|否| E[人工调度]
D/E --> F[维修处理]
F --> G[验收确认]
G --> H[知识库归档]
3. 关键功能实现细节
3.1 极简报修流程
设计要点:
- 设备二维码扫码识别(含设备ID、位置信息)
- 故障类型选择器(预置20种常见故障)
- 多媒体采集(强制拍照+可选视频)
- 智能预判(根据故障代码推荐解决方案)
javascript复制// 小程序端报修提交代码示例
wx.scanCode({
success: (res) => {
this.setData({
deviceId: res.result.split('|')[0],
location: res.result.split('|')[1]
})
}
})
3.2 智能派单算法
基于维修组的:
- 当前任务量(加权40%)
- 专业技能匹配度(30%)
- 地理位置距离(20%)
- 历史完成评分(10%)
java复制// 派单核心逻辑
public MaintenanceGroup autoDispatch(FaultType type) {
return maintenanceGroups.stream()
.filter(g -> g.getSkills().contains(type))
.sorted(Comparator.comparing(MaintenanceGroup::getWorkload)
.thenComparing(g -> distance(g.getLocation(), faultLocation)))
.findFirst()
.orElse(null);
}
3.3 实时状态看板
采用WebSocket实现四个关键状态推送:
- 工单创建通知(所有相关维修人员)
- 工单接单提醒(报修人+主管)
- 维修进度更新(每完成一个阶段)
- 验收超时预警(24小时未验收)
4. 数据统计模块
4.1 核心指标看板
| 指标名称 | 计算方式 | 预警阈值 |
|---|---|---|
| MTTR平均修复时间 | ∑(完成时间-创建时间)/总工单数 | >4小时 |
| 重复报修率 | 相同设备7天内再报修次数 | >2次 |
| 首次修复率 | 一次维修即解决的比例 | <85% |
4.2 设备健康评分模型
$$
HealthScore = 100 - \left( \frac{\sum_{i=1}^{n} w_i \times f_i}{T} \right) \times 20
$$
其中:
- $w_i$为故障权重(1-5级)
- $f_i$为故障次数
- $T$为运行时长(月)
5. 实施效果与优化
上线三个月后的关键改进:
- 报修响应时间从平均53分钟缩短至12分钟
- 工单流转耗时降低68%
- 建立包含127个典型故障的解决方案库
遇到的典型问题及解决方案:
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| 扫码报修失败率偏高 | 车间光线干扰二维码识别 | 改用UV抗反光二维码贴纸 |
| 维修人员漏接通知 | 微信消息被折叠 | 增加短信备用通知通道 |
| 历史工单查询速度慢 | 未做分表存储 | 按季度分表+建立时间索引 |
6. 扩展功能规划
正在开发中的增强功能:
- AR远程协助(维修人员第一视角指导)
- 预测性维护(基于设备传感器数据)
- 备件库存联动(自动触发采购申请)
关键实施建议:建议企业先跑通核心报修流程,再逐步叠加智能功能。我们初期过度追求"大而全",反而导致首个版本延期2个月才上线。