ระบบพัฒนาคุณภาพจำนวนมากกลายเป็นภาระเอกสาร มากกว่าจะช่วยพัฒนางานจริง
ทำไมระบบเดิมจึงไม่ยั่งยืน
เมื่อการพัฒนาคุณภาพแยกจากงานประจำ และวัดผลได้ยาก ระบบก็กลายเป็นพิธีกรรม
หลักการออกแบบที่เราใช้
- เชื่อมตัวชี้วัดเข้ากับงานจริง
- ทำให้การติดตามผลเป็นอัตโนมัติเท่าที่ทำได้
- ปิดวงจรด้วยการทบทวนและปรับปรุงสม่ำเสมอ
เมื่อข้อมูลไหลกลับมาที่ทีมได้เร็ว การพัฒนาคุณภาพก็กลายเป็นส่วนหนึ่งของงาน ไม่ใช่ภาระ
เริ่มจากคำถามคุณภาพ ไม่ใช่เริ่มจาก dashboard
ระบบคุณภาพที่ดีควรตอบคำถามของทีม เช่น ปัญหาเกิดตรงไหน, ตัวชี้วัดใดสะท้อนงานจริง, ต้องแก้ที่กระบวนการใด, และหลังแก้แล้วผลดีขึ้นหรือไม่ หากเริ่มจากการสร้าง dashboard โดยยังไม่รู้คำถาม ระบบมักกลายเป็นหน้าจอที่มีกราฟจำนวนมากแต่ไม่มีใครใช้ตัดสินใจ
ทีมควรแยกตัวชี้วัดเป็น 3 กลุ่ม: ตัวชี้วัดผลลัพธ์ ตัวชี้วัดกระบวนการ และตัวชี้วัดเตือนภัย ตัวชี้วัดผลลัพธ์บอกว่าคุณภาพดีขึ้นหรือไม่ ตัวชี้วัดกระบวนการบอกว่าทีมทำงานตามวิธีที่ตกลงกันหรือไม่ ส่วนตัวชี้วัดเตือนภัยช่วยให้เห็นความเสี่ยงก่อนเกิดผลเสีย
วงจรข้อมูลที่ควรมี
- เก็บข้อมูลจากงานจริงโดยลดการกรอกซ้ำ
- ตรวจคุณภาพข้อมูลก่อนนำไปสรุป
- แสดงผลให้ทีมหน้างานเข้าใจได้ภายในเวลาไม่นาน
- ผูกตัวชี้วัดกับ action, owner และ deadline
- ทบทวนผลหลังปรับปรุงและบันทึกบทเรียน
PMQA และ CQI ควรเชื่อมกับงานประจำ
ในหลายองค์กร PMQA และ CQI ถูกทำเป็นแฟ้มเอกสารหรือกิจกรรมรอบประเมิน ทั้งที่หัวใจของงานคือการเรียนรู้และปรับปรุงอย่างต่อเนื่อง ระบบข้อมูลควรช่วยให้ทีมเห็นความคืบหน้าแบบใกล้เวลาจริง และช่วยให้ผู้บริหารเห็นว่าปัญหาใดต้องการการสนับสนุนเชิงระบบ
AI สามารถช่วยสรุปแนวโน้ม จัดกลุ่มสาเหตุ และเตือนความผิดปกติได้ แต่ไม่ควรตัดสินแทนผู้รับผิดชอบคุณภาพ โดยเฉพาะเมื่อตัวชี้วัดเกี่ยวข้องกับคนไข้ ประชาชน หรือผู้รับบริการจริง
ความเสี่ยงของระบบที่ดูดีแต่ไม่ช่วยงาน
ระบบที่สวยแต่ข้อมูลช้า ระบบที่มีกราฟแต่ไม่มีเจ้าของ action และระบบที่ให้คะแนนโดยไม่อธิบายบริบท ล้วนทำให้ทีมไม่ไว้ใจข้อมูล การออกแบบจึงต้องให้ความสำคัญกับความน่าเชื่อถือของข้อมูลพอๆ กับความสวยของหน้าจอ