มีเยอะใช่ว่าจะดี... ทำไมระบบหลังบ้านคลินิกถึงล้มไม่เป็นท่า ทั้งที่โปรแกรมที่ใช้อยู่ก็มีฟีเจอร์ครบ ?

คำตอบสั้นสำหรับผู้บริหาร: โครงการระบบคลินิกล้มเหลวเมื่อเป้าหมายไม่ผูกผลลัพธ์ Process และข้อมูลไม่พร้อม ผู้ใช้ไม่มีส่วนร่วม ขอบเขตกว้างเกิน และไม่มีผู้บริหารเป็นเจ้าของการตัดสินใจ

ก่อนลงรายละเอียด ลองเริ่มจากภาพหน้างาน

ระบบเปิดตรงเวลา ผ่านการทดสอบ และไม่มีบั๊กร้ายแรง แต่ทีมยังใช้ไฟล์เดิม ผู้บริหารจึงสรุปว่าคนไม่ยอมเปลี่ยน ทั้งที่โครงการไม่เคยนิยามงานที่จะเลิกทำ

การเลือกซอฟต์แวร์ไม่ใช่การหาตัวที่มีทุกอย่าง แต่เป็นการลดความไม่แน่นอนก่อนผูกธุรกิจเข้ากับระบบ ผู้บริหารต้องเปลี่ยนคำโฆษณาให้กลายเป็นหลักฐานจากเหตุการณ์จริง ค่าใช้จ่ายจริง และความรับผิดชอบที่ระบุได้ ดังนั้นเมื่อทบทวน “โครงการระบบคลินิกล้มเหลว” ให้ระบุเจ้าของ ข้อยกเว้น และหลักฐานที่ใช้ตรวจผลลัพธ์ไว้พร้อมกัน

ลองดูหนึ่งสถานการณ์ที่ทำให้ภาพชัดขึ้น

คลินิกอาจเปิดระบบครบทุกโมดูลตามแผน แต่ฝ่ายขายยังเก็บข้อมูลในแชต การเงินยังปรับยอดปลายวัน และผู้จัดการยังขอ Excel แยก สถานะ “เปิดใช้แล้ว” จึงไม่เท่ากับ “เปลี่ยนวิธีทำงานแล้ว” ความล้มเหลวมักเริ่มจากการไม่มีเจ้าของกระบวนการและไม่มีตัวชี้วัดหลัง Go-live

โครงการระบบคลินิกล้มเหลว: ผู้บริหารควรพิจารณาอะไรบ้าง

1. Purpose

ไม่มีผลลัพธ์ธุรกิจที่วัดได้

วิธีพิสูจน์ “Purpose” คือหยิบเหตุการณ์จริงมาทดลองแล้วดูว่าทีมสองคนได้ผลลัพธ์เดียวกันหรือไม่ หากคำตอบต่างกัน ประเด็นของ โครงการระบบคลินิกล้มเหลว ยังขาดนิยามหรือจุดควบคุมที่ใช้ร่วมกัน

2. Process

นำความสับสนเดิมเข้าไปตั้งค่า

สำหรับผู้บริหาร “Process” มีคุณค่าก็ต่อเมื่อช่วยลดความคลุมเครือในการตัดสินใจ จึงควรกำหนดเจ้าของข้อมูล เวลาที่ต้องบันทึก และวิธีจัดการเมื่อเหตุการณ์ของ โครงการระบบคลินิกล้มเหลว ไม่เป็นไปตามกรณีปกติ

3. People

อบรมแต่ไม่จัดการความกลัวและภาระ

ในทางปฏิบัติ “People” ต้องถูกแปลงเป็นกติกาที่ตรวจได้สำหรับ โครงการระบบคลินิกล้มเหลว: เหตุการณ์ใดทำให้ข้อมูลเปลี่ยน ใครรับผิดชอบ และหลักฐานใดยืนยันว่าเสร็จแล้ว หากสามข้อนี้ไม่ชัด ทีมอาจทำงานครบตามหน้าที่ของตนแต่ผลรวมยังไม่ตรงกัน

4. Governance

ไม่มีเจ้าของและเกณฑ์ผ่าน

จุดที่ผู้บริหารควรถามต่อจาก “Governance” คือ สิ่งนี้เกิดขึ้นในขั้นตอนไหนและส่งผลต่อใครถัดไป สำหรับ โครงการระบบคลินิกล้มเหลว คำตอบควรอ้างกลับไปยังข้อมูลต้นทางได้ ไม่ใช่อาศัยคำอธิบายหลังเกิดปัญหา

จุดที่เรื่องนี้มักเริ่มผิดทาง

• โทษผู้ใช้เป็นอันดับแรก
• เพิ่มฟีเจอร์เพื่อแก้การใช้ต่ำ
• ประกาศสำเร็จในวัน Go-live

เปลี่ยนความเข้าใจให้เป็นแผนลงมือทำ

1. ทำ Postmortem จากหลักฐาน
2. หา Constraint สูงสุด
3. ลดขอบเขตและสร้าง Quick Win
4. ตั้งเจ้าของกับตัวชี้วัดใหม่

คำถามสุดท้ายก่อนตัดสินใจคือ ความล้มเหลวเกิดจากผลิตภัณฑ์ Process ข้อมูล หรือการบริหาร และเรามีหลักฐานอะไร

สรุปสำหรับผู้บริหาร

การยอมรับสาเหตุจริงเร็วช่วยให้โครงการฟื้นได้ดีกว่าการปกป้องแผนเดิม

ใช้หัวข้อ “โครงการระบบคลินิกล้มเหลว” เปิดการทบทวนกับทีมได้ทันที โดยนำเคสผิดปกติหนึ่งเคสมาตรวจว่าใครตัดสินใจ ใช้ข้อมูลใด และผลกระทบไปจบที่รายงานไหน ช่องว่างที่ตอบไม่ได้คือรายการปรับปรุงรอบแรก

ขั้นตอนประเมินที่มีประโยชน์คือ นำเหตุการณ์จริงเรื่อง “โครงการระบบคลินิกล้มเหลว” ไปเดินบนระบบ คุณสามารถเริ่มจาก ภาพรวม Keenix และ นัดสาธิต โดยไม่ต้องตัดสินจากรายการฟีเจอร์เพียงอย่างเดียว