การบำรุงรักษาเชิงป้องกัน: Workflow¶

วงจรชีวิตของคำขอ PM¶

คำขอ PM ไหลผ่าน 5 stage — workflow การซ่อมมาตรฐาน นำหน้าด้วย "PM Scheduled":

┌─────────────────────────────────────────────────────────────────┐
│  PM-only stage   │            Standard repair workflow          │
├──────────────────┼───────────────────────────────────────────────┤
│ PM Scheduled  →  │  Pending Review  →  In Repair  →  Awaiting   │
│  (72hr SLA)      │  (8hr SLA)         (24hr SLA)    Pickup      │
│                  │                                  (8hr SLA)   │
│                  │                                       │      │
│                  │                                       ▼      │
│                  │                              Received (done) │
└─────────────────────────────────────────────────────────────────┘

การเปลี่ยนแต่ละครั้งจะถูกบันทึกลงใน hemms.stage.transition.log เพื่อการ audit

คำอธิบายทีละ stage¶

Stage 1 — PM Scheduled¶

ใครจัดการ: BME Technician (ค่า roots_responsible_role ที่ตั้งไว้)

หมายความว่า: cron ได้สร้างคำขอตามกำหนดการของแผนแล้ว ช่างเทคนิค ยังไม่ได้รับทราบ

SLA: 72 ชั่วโมงนับจากการสร้าง หากช่างเทคนิคไม่เลื่อนคำขอ ไปข้างหน้าภายใน 3 วัน ธง SLA จะเริ่มทำงาน และคำขอจะปรากฏใน filter SLA Breached

การกระทำทั่วไป:

• ทบทวนเครื่องมือแพทย์ + ประเภทการบำรุงรักษา + คำสั่ง
• จัดกำหนดการเข้าตรวจจริง
• เลื่อนไปยัง Pending Review เมื่อรับทราบ

Stage 2 — Pending Review¶

ใครจัดการ: BME Manager

หมายความว่า: ผู้จัดการทบทวนแผนการทำงานของช่างเทคนิค ตรวจสอบ ความพร้อมของอะไหล่ และมอบหมายงานให้ช่างเทคนิค

SLA: 8 ชั่วโมง

การกระทำทั่วไป:

• มอบหมาย user_id ให้ช่างเทคนิค
• สั่งอะไหล่หากจำเป็น
• เลื่อนไปยัง In Repair

Stage 3 — In Repair¶

ใครจัดการ: BME Technician

หมายความว่า: กำลังทำงาน PM บนเครื่องมือแพทย์อยู่

SLA: 24 ชั่วโมง

การกระทำทั่วไป:

• ดำเนินงาน PM ตามคำสั่งของแผน
• บันทึกปัญหาที่พบ (อะไหล่ชำรุด, การเปลี่ยนที่แนะนำ)
• อัปเดตหมายเหตุคำขอ
• เลื่อนไปยัง Awaiting Pickup เมื่องานเสร็จ

Stage 4 — Awaiting Pickup¶

ใครจัดการ: BME Manager (ลงนามอนุมัติ)

หมายความว่า: งาน PM เสร็จแล้ว รอการยืนยันการรับจากหอผู้ป่วย

SLA: 8 ชั่วโมง

การกระทำทั่วไป:

• แจ้งหอผู้ป่วย
• ผู้จัดการลงนามอนุมัติงาน
• เลื่อนไปยัง Received เมื่อหอผู้ป่วยรับทราบ

Stage 5 — Received¶

ใครจัดการ: Ward Staff (ยืนยันการรับ)

หมายความว่า: วงจร PM เสร็จสมบูรณ์ คำขอถูกปิด

SLA: ไม่มี (stage สิ้นสุด)

ตอนนี้ audit log แสดงการเปลี่ยนทั้ง 5 ครั้งพร้อมเวลาประทับและจำนวน ชั่วโมงที่ผ่านไปต่อ stage

เกิดอะไรขึ้นหากคำขอ PM ละเมิด SLA¶

ฟิลด์ compute roots_is_sla_breached ประเมินเป็น True เมื่อ:

NOW() - roots_stage_entered_at  >  current_stage.roots_sla_hours

ไม่มีการ escalate อัตโนมัติ — แต่คุณสามารถ:

• Filter มุมมอง kanban / list ตาม SLA Breached = True
• สร้างรายงาน ที่จัดกลุ่มการละเมิดตามผู้รับผิดชอบ
• ตั้งค่า server action (Settings → Technical → Server Actions) เพื่อส่ง อีเมลหรือโพสต์หมายเหตุ chatter เมื่อธงเริ่มทำงาน

การ์ด kanban แสดง ไอคอนธงแดง พร้อมข้อความ "SLA" ข้างจุดระดับความ วิกฤตเมื่อคำขออยู่ในสถานะละเมิด

Corrective vs PM — ตรรกะการกำหนดเส้นทาง¶

การตัดสินใจออกแบบหลักของโมดูลคือการแยกงาน corrective และ PM ให้เห็นต่างกันในเชิงภาพ ในขณะที่ใช้ workflow พื้นฐานเดียวกัน:

บังคับใช้โดย:

1. การ override ค่าเริ่มต้นของ stage_id — roots_hemms_pm นิยามค่า เริ่มต้นของฟิลด์ใหม่เพื่อยกเว้น stage แบบ PM-initial ดังนั้นคำขอ corrective จะได้ "Submitted" ไม่ใช่ "PM Scheduled"
2. การ override create() — เมื่อ maintenance_plan_id อยู่ใน create vals ให้กำหนดเส้นทางไปยัง stage แบบ PM-initial อย่างชัดเจน

หลังจาก Stage 1 ทั้งสองประเภทใช้ flow 4 stage เดียวกัน (Pending Review → In Repair → Awaiting Pickup → Received)

การ audit คำขอ PM¶

ทุกคำขอ PM มีบริบทการ audit เต็มรูปแบบ:

Stage transition log¶

เปิดคำขอ → แท็บ Audit Trail → ดูการเปลี่ยนทั้งหมด:

Chatter (mail.thread)¶

การเปลี่ยน stage ทุกครั้งจะโพสต์ข้อความ chatter ด้วย:

Stage changed: PM Scheduled → Pending Review

ผู้ติดตาม (ผู้ใช้ที่ได้รับมอบหมาย, เจ้าของเครื่องมือแพทย์) จะได้รับแจ้งทาง อีเมลตามค่าเริ่มต้น (ควบคุมโดย skip_notify_follower_on_requests บนแผน)

ประวัติระดับเครื่องมือแพทย์¶

เปิด record เครื่องมือแพทย์ → แท็บ Maintenance → ดู:

• คำขอ PM ในอดีตทั้งหมดสำหรับเครื่องมือแพทย์ชิ้นนี้
• วันที่ PM ที่เสร็จล่าสุดต่อประเภท
• คำขอ PM ที่เปิดอยู่ในปัจจุบัน (ถ้ามี)

Edge cases¶

จะเกิดอะไรขึ้นหากแผนถูกลบขณะที่คำขอ PM เปิดอยู่¶

maintenance_plan.unlink() ของ OCA บล็อกการลบหากมีคำขอ PM ที่เปิดอยู่ สำหรับเครื่องมือแพทย์และประเภทนั้น คุณจะเห็น error:

The maintenance plan Calibration of equipment Vital Monitor #5 has generated a request which is not done yet. You should either set the request as done, remove its maintenance kind or delete it first.

หากต้องการลบแผน: ปิด (stage Received) หรือ unlink คำขอ PM ที่เปิดอยู่ก่อน แล้วลองใหม่

จะเกิดอะไรขึ้นหากเครื่องมือแพทย์ถูก archive¶

cron ข้ามเครื่องมือแพทย์ที่ถูก archive — ไม่มีการสร้างคำขอ PM ใหม่ คำขอ PM ที่เปิดอยู่สำหรับเครื่องมือแพทย์ที่ถูก archive จะยังคงมองเห็นได้จนกว่าจะเสร็จ

จะเกิดอะไรขึ้นหาก 2 แผนต่างกันตรงกับวันที่เดียวกันสำหรับเครื่องมือแพทย์เดียวกัน¶

cron สร้าง 2 คำขอแยกกัน — หนึ่งคำขอต่อแผน kanban แสดงทั้งสองเคียงข้างกัน

จะเกิดอะไรขึ้นหาก start_maintenance_date อยู่ในอดีต¶

cron จะตามให้ทัน — มันเดินไปข้างหน้าจาก start_maintenance_date สร้างคำขอสำหรับแต่ละช่วงเวลาที่พลาดไปจนถึง planning horizon มีประโยชน์เมื่อเพิ่มแผนให้กับเครื่องมือแพทย์รุ่นเก่า

ขั้นตอนถัดไป¶

• รายงาน — แดชบอร์ดและตัววัด SLA
• Repair Workflow — workflow 5 stage ทำงานอย่างไร สำหรับคำขอ corrective เฉพาะกิจ
• Equipment Criticality — ระดับความวิกฤตส่งผลต่อ การจัดกำหนดการ PM อย่างไร