Decision Modeling

คลังข้อมูลที่หยุดอยู่ที่ Dashboard คือต้นทุน ไม่ใช่การลงทุน

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

Infozense Decision Modeling · ผู้บริหาร · ฝ่ายปฏิบัติการ · หัวหน้าทีมข้อมูล · ~8 นาที

Dashboard ครบ แต่การตัดสินใจยังเหมือนเดิม

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

ปัญหาไม่ได้อยู่ที่ข้อมูลไม่ดี หรือ Dashboard ไม่สวย ปัญหาอยู่ที่โครงการออกแบบมาให้ จบที่รายงาน แทนที่จะ จบที่การตัดสินใจ

แนวคิดนี้ไม่ใช่เรื่องใหม่ ในวงการมีชื่อเรียกอยู่แล้ว ได้แก่ Prescriptive Analytics และ Decision Intelligence ส่วนศาสตร์ที่ใช้ตอบคำถามว่า "ควรทำอะไร" คือ Operations Research ซึ่งมีมาหลายสิบปี

แต่จากประสบการณ์ของเรา แทบไม่มีโครงการข้อมูลใดนำศาสตร์นี้เข้ามาใช้ โครงการส่วนใหญ่ดำเนินการโดยทีม IT ซึ่งมีเครื่องมือหลักคือ ETL และ Dashboard อย่างที่มีคำกล่าวว่า เมื่อมีแต่ค้อนอยู่ในมือ ทุกปัญหาก็ดูเหมือนตะปู ทุกคำถามใหม่จึงกลายเป็น Pipeline อีกเส้น และ Dashboard อีกหน้า บทความนี้ไม่ได้เสนอทฤษฎีใหม่ แต่เสนอ วิธีทำงาน

ห้าเหตุผลที่โครงการข้อมูลหยุดอยู่ที่ Dashboard

ไม่มีใครเป็นเจ้าของการตัดสินใจ Dashboard ไม่ทำให้ฝ่ายใดต้องเสี่ยง ฝ่าย IT ส่งมอบได้ ผู้บริหารเปิดดูได้ แต่ไม่มีใครต้องรับผิดชอบว่าตัวเลขบนหน้าจอเปลี่ยนการตัดสินใจเรื่องใด

ทีมยังขาดทักษะด้าน Optimization เมื่อพูดถึงทีมข้อมูล องค์กรส่วนใหญ่นึกถึง Data Engineer, Data Scientist และ Machine Learning Engineer คนในบทบาทเหล่านี้ถนัดการสร้าง Pipeline และการพยากรณ์ว่าอะไรจะเกิดขึ้น แต่ผู้บริหารถามว่า "แล้วควรทำอะไร" การตอบคำถามนี้ต้องใช้อีกศาสตร์หนึ่ง คือ Optimization ภายใต้ Constraint จริง ซึ่งเป็นศาสตร์ของ Operations Research และวิศวกรรมอุตสาหการ จากที่เราเห็น ทีมข้อมูลส่วนใหญ่ยังไม่มีคนที่ถนัดด้านนี้

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

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

แรงจูงใจทำให้ทุกฝ่ายหยุดที่ Dashboard Dashboard ขายง่าย ส่งมอบง่าย ตรวจรับง่าย ทั้งผู้ขายและผู้ซื้อจึงพอใจที่จะหยุดตรงนั้น

สาม Level ของการใช้ข้อมูล และช่องว่างที่โครงการส่วนใหญ่ติดอยู่

พีระมิดสาม Level ของการใช้ข้อมูล เรียงจากล่างขึ้นบน ได้แก่ รู้ว่าเกิดอะไรขึ้น (Descriptive), รู้ว่าเกิดขึ้นเพราะอะไร (Diagnostic), รู้ว่าควรทำอะไร (Prescriptive) โดยมีช่องเส้นประ Predictive (ไม่นับเป็น Level) คั่นระหว่าง Level 2 กับ Level 3 ซึ่งเป็นจุดที่โครงการส่วนใหญ่หยุดอยู่ Level 1 คือต้นทุน Level 2 และ Level 3 คือที่มาของผลตอบแทน ดัดแปลงจาก Analytic Ascendancy Model ของ Gartnerพีระมิดสาม Level ของการใช้ข้อมูล เรียงจากล่างขึ้นบน ได้แก่ รู้ว่าเกิดอะไรขึ้น (Descriptive), รู้ว่าเกิดขึ้นเพราะอะไร (Diagnostic), รู้ว่าควรทำอะไร (Prescriptive) โดยมีช่องเส้นประ Predictive (ไม่นับเป็น Level) คั่นระหว่าง Level 2 กับ Level 3 ซึ่งเป็นจุดที่โครงการส่วนใหญ่หยุดอยู่ Level 1 คือต้นทุน Level 2 และ Level 3 คือที่มาของผลตอบแทน ดัดแปลงจาก Analytic Ascendancy Model ของ Gartner

Level 1: รู้ว่าเกิดอะไรขึ้น (Descriptive) ตัวเลขถูกต้อง ตรงกันทุกฝ่าย และมาจากแหล่งเดียว นี่คือสิ่งที่โครงการคลังข้อมูลส่วนใหญ่ส่งมอบ และต้องทำให้ดีก่อน

Level 2: รู้ว่าเกิดขึ้นเพราะอะไร (Diagnostic) เปรียบเทียบอย่างเป็นธรรม หาจุดที่เป็นปัญหา และตรวจสอบสาเหตุแทนการเดา

ระหว่าง Level 2 กับ Level 3 ยังมีอีกขั้นหนึ่ง ซึ่ง Gartner เรียกว่า Predictive Analytics คือการพยากรณ์ว่าอะไรน่าจะเกิดขึ้น องค์กรส่วนใหญ่ลงทุนกับขั้นนี้มาก ทั้ง Data Science และ Machine Learning และจากประสบการณ์ของเรา โครงการส่วนใหญ่ก็หยุดอยู่ตรงนี้ การพยากรณ์บอกได้ว่าอะไรกำลังจะเกิดขึ้น แต่ไม่ได้บอกว่าควรทำอะไร

Level 3: รู้ว่าควรทำอะไร (Prescriptive) Optimizer เสนอทางเลือกภายใต้ Constraint จริง พร้อมบอกว่าแต่ละทางเลือกได้อะไร และต้องแลกกับอะไร

Level 1 คือต้นทุน ส่วนผลตอบแทนมาจาก Level 2 และ Level 3 ตัวอย่างต่อไปนี้แสดงว่า องค์กรขยับจาก Level 2 ไปสู่ Level 3 ได้ โดยไม่ต้องสร้าง Forecasting Model แยกต่างหาก

Dashboard เดียวกัน อ่านได้ทั้งแบบ Level 1 และ Level 2

ลองนึกภาพเครือข่ายคลินิก 45 สาขา ที่มีการมารับบริการประมาณ 850,000 ครั้งต่อปี (ข้อมูลจำลอง) ในการประชุมประจำเดือน ผู้บริหารเปิด Dashboard ผลการดำเนินงาน ซึ่งแสดงเวลารอเฉลี่ยของแต่ละสาขา และหลายสาขาขึ้นสีแดง

ใช้เพื่อดูตัวเลข (Level 1) ที่ประชุมพูดถึงสาขาสีแดง ขอให้ผู้จัดการสาขาชี้แจง แล้วตกลงว่าจะติดตามต่ออีกเดือน บางครั้งก็เลือกทางออกที่ง่ายที่สุด คือเพิ่มแพทย์ให้สาขาสีแดง ผลคือไม่มีอะไรเปลี่ยน หรือเสียเงินเพิ่มแพทย์ให้สาขาที่ปัญหาไม่ได้อยู่ที่แพทย์ เดือนถัดไปสาขาเดิมก็ยังเป็นสีแดง

ภาพจำลอง Dashboard แบบ Level 1 ของ 45 สาขาจำลอง มีตัวเลขสรุปสามช่อง ได้แก่ จำนวนครั้งที่มารับบริการต่อปี เวลารอรวมเฉลี่ย 55.7 นาที และ 10 สาขาที่เกินเป้า ถัดมาเป็นแผนภูมิแท่งเวลารอรวมเฉลี่ยรายสาขาในไตรมาสล่าสุด เรียงจากมากไปน้อย แท่งที่สูงกว่าเส้นเป้าหมาย 60 นาที (ค่าสมมติ) เป็นสีแดงรวม 10 สาขา ในจำนวนนี้เป็นสาขาขนาดใหญ่ 6 สาขา มีหมายเหตุสี่ข้อถึงสิ่งที่มุมมองนี้บอกไม่ได้ ได้แก่ไม่เทียบกับสาขาขนาดเดียวกัน เห็นไตรมาสเดียว เห็นเวลารอรวมแต่ไม่เห็นรายขั้นตอน และไม่เห็นกำลังแพทย์ ข้อมูลจำลองภาพจำลอง Dashboard แบบ Level 1 ของ 45 สาขาจำลอง มีตัวเลขสรุปสามช่อง ได้แก่ จำนวนครั้งที่มารับบริการต่อปี เวลารอรวมเฉลี่ย 55.7 นาที และ 10 สาขาที่เกินเป้า ถัดมาเป็นแผนภูมิแท่งเวลารอรวมเฉลี่ยรายสาขาในไตรมาสล่าสุด เรียงจากมากไปน้อย แท่งที่สูงกว่าเส้นเป้าหมาย 60 นาที (ค่าสมมติ) เป็นสีแดงรวม 10 สาขา ในจำนวนนี้เป็นสาขาขนาดใหญ่ 6 สาขา มีหมายเหตุสี่ข้อถึงสิ่งที่มุมมองนี้บอกไม่ได้ ได้แก่ไม่เทียบกับสาขาขนาดเดียวกัน เห็นไตรมาสเดียว เห็นเวลารอรวมแต่ไม่เห็นรายขั้นตอน และไม่เห็นกำลังแพทย์ ข้อมูลจำลอง

ใช้เพื่อหาสาเหตุ (Level 2) คลังข้อมูลต้องเพิ่มการแปลงข้อมูลอีกสี่อย่าง โดยใช้ข้อมูลเดิมทั้งหมด อย่างแรก จัดกลุ่มสาขาตามขนาด เพื่อเทียบกับสาขาที่มีขนาดใกล้เคียงกัน อย่างที่สอง เก็บประวัติรายไตรมาส เพราะสาขาที่แย่ที่สุดในไตรมาสหนึ่งมักดีขึ้นเองได้บางส่วน (Regression to the Mean) อย่างที่สาม แยกเวลารอตามขั้นตอน ตั้งแต่ลงทะเบียนจนถึงชำระเงิน อย่างที่สี่ เทียบจำนวนผู้ป่วยที่มาในแต่ละชั่วโมงกับชั่วโมงแพทย์ที่จัดไว้

ผลคือ จาก 45 สาขา มี 9 สาขาที่รอนานกว่าสาขาขนาดเดียวกันซ้ำ ๆ และอีก 3 สาขาอยู่ในกลุ่มเฝ้าระวัง (ข้อมูลจำลอง) คำว่า "ซ้ำ ๆ" มีเกณฑ์สองข้อ คือ รอนานกว่าค่ากลางของกลุ่มเกิน 10 นาที และเป็นเช่นนี้อย่างน้อย 2 จาก 4 ไตรมาสล่าสุด รายชื่อนี้ไม่ตรงกับสาขาสีแดงใน Level 1 เสียทีเดียว จาก 10 สาขาสีแดง มี 3 สาขาขนาดใหญ่ที่จริง ๆ แล้วรอนานพอ ๆ กับสาขาขนาดเดียวกัน ส่วนใน 9 สาขาที่ควรปรับปรุง มี 4 สาขาที่ไม่ได้ขึ้นสีแดง (ข้อมูลจำลอง)

ที่ประชุมเดียวกันนี้ลงมือได้ทันที ใน 9 สาขานี้ มี 3 สาขาที่ปัญหาไม่ได้อยู่ที่แพทย์ แบ่งเป็นสาขาที่ต้องทบทวนห้องยา 2 สาขา และจุดลงทะเบียน 1 สาขา โดยไม่ต้องเพิ่มแพทย์ จึงเหลือ 6 สาขาที่ปัญหาอยู่ที่การรอพบแพทย์ (ข้อมูลจำลอง) ส่วน 3 สาขาในกลุ่มเฝ้าระวังให้รอดูผลไตรมาสหน้า

มุมมอง Level 2 ของ 45 สาขาเดิม แบ่งเป็นสี่ส่วน (1) เทียบกับค่ากลางของสาขาขนาดเดียวกัน ควรปรับปรุง 9 สาขา เฝ้าระวัง 3 สาขา (2) เกิดซ้ำ สาขาที่ควรปรับปรุงรอนานกว่ากลุ่มใน 4 จาก 4 ไตรมาส 8 สาขา และ 2 จาก 4 ไตรมาส 1 สาขา ส่วนสาขาเฝ้าระวัง 3 สาขาเกินในไตรมาสล่าสุดเท่านั้น (3) ขั้นตอนที่ช้า รอพบแพทย์ 6 สาขา รอรับยา 2 สาขา ลงทะเบียน 1 สาขา (4) ตัวอย่างสาขาหนึ่งที่ชั่วโมงแพทย์ไม่พอ มีผู้ป่วยเข้ามามากกว่ากำลังแพทย์ 6 รายต่อชั่วโมงใน 8 จาก 10 ช่วงชั่วโมง สรุปสิ่งที่ต้องทำ: ควรปรับปรุง 9 สาขา ได้แก่ รอพบแพทย์ 6 สาขา ให้ตรวจสาเหตุต่อ ทบทวนห้องยา 2 สาขา ทบทวนจุดลงทะเบียน 1 สาขา ส่วนอีก 3 สาขาให้เฝ้าระวังและรอดูไตรมาสหน้า ข้อมูลจำลองมุมมอง Level 2 ของ 45 สาขาเดิม แบ่งเป็นสี่ส่วน (1) เทียบกับค่ากลางของสาขาขนาดเดียวกัน ควรปรับปรุง 9 สาขา เฝ้าระวัง 3 สาขา (2) เกิดซ้ำ สาขาที่ควรปรับปรุงรอนานกว่ากลุ่มใน 4 จาก 4 ไตรมาส 8 สาขา และ 2 จาก 4 ไตรมาส 1 สาขา ส่วนสาขาเฝ้าระวัง 3 สาขาเกินในไตรมาสล่าสุดเท่านั้น (3) ขั้นตอนที่ช้า รอพบแพทย์ 6 สาขา รอรับยา 2 สาขา ลงทะเบียน 1 สาขา (4) ตัวอย่างสาขาหนึ่งที่ชั่วโมงแพทย์ไม่พอ มีผู้ป่วยเข้ามามากกว่ากำลังแพทย์ 6 รายต่อชั่วโมงใน 8 จาก 10 ช่วงชั่วโมง สรุปสิ่งที่ต้องทำ: ควรปรับปรุง 9 สาขา ได้แก่ รอพบแพทย์ 6 สาขา ให้ตรวจสาเหตุต่อ ทบทวนห้องยา 2 สาขา ทบทวนจุดลงทะเบียน 1 สาขา ส่วนอีก 3 สาขาให้เฝ้าระวังและรอดูไตรมาสหน้า ข้อมูลจำลอง

เจาะลึก 6 สาขาที่ผู้ป่วยรอพบแพทย์นาน ก่อนสรุปว่า "แพทย์ไม่พอ" ควรถามสองคำถามที่ข้อมูลตอบได้โดยตรง

แผนภาพกระจายของ 45 สาขาจำลอง แกนนอนคือเวลารอพบแพทย์เทียบกับค่าเฉลี่ยของสาขาขนาดเดียวกัน แกนตั้งคือผู้ป่วยต่อชั่วโมงแพทย์ มีเส้นกำลังรองรับที่ 6 ราย สาขาที่ชั่วโมงแพทย์ไม่พอ 6 สาขาส่วนใหญ่อยู่เหนือเส้นนี้ (5 สาขา อีก 1 สาขาอยู่ใกล้เส้น) และรอนานกว่าค่าเฉลี่ยกลุ่มประมาณ 1.5 ถึง 2.3 เท่า ข้อมูลจำลองแผนภาพกระจายของ 45 สาขาจำลอง แกนนอนคือเวลารอพบแพทย์เทียบกับค่าเฉลี่ยของสาขาขนาดเดียวกัน แกนตั้งคือผู้ป่วยต่อชั่วโมงแพทย์ มีเส้นกำลังรองรับที่ 6 ราย สาขาที่ชั่วโมงแพทย์ไม่พอ 6 สาขาส่วนใหญ่อยู่เหนือเส้นนี้ (5 สาขา อีก 1 สาขาอยู่ใกล้เส้น) และรอนานกว่าค่าเฉลี่ยกลุ่มประมาณ 1.5 ถึง 2.3 เท่า ข้อมูลจำลอง

แพทย์ในสาขาเหล่านี้ทำงานช้ากว่าหรือไม่ ในข้อมูลจำลอง เวลาตรวจเฉลี่ยต่อรายในชั่วโมงที่มีคิวอยู่ที่ 10 นาที เท่ากับสาขาอื่น

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

ปัญหาไม่ได้อยู่ที่แพทย์ทำงานช้ากว่าสาขาอื่น แต่อยู่ที่ชั่วโมงแพทย์ไม่พอในช่วงที่ผู้ป่วยมามาก ส่วนอีก 9 สาขายังมีชั่วโมงแพทย์เหลือ (ข้อมูลจำลอง) คำตอบจึงไม่จำเป็นต้องเป็นการจ้างแพทย์เพิ่ม แต่อาจเป็นการย้ายเวร การตัดสินใจเรื่องนี้อยู่ใน Level 3

Level 3: ให้ Optimizer เสนอทางเลือก แล้วให้ผู้บริหารตัดสินใจ

คำถามที่ Dashboard ตอบไม่ได้คือ "ควรจัดเวรใหม่อย่างไร" จะตอบคำถามนี้ได้ คลังข้อมูลต้องมีข้อมูลที่แทบไม่มีองค์กรใดเก็บเข้าคลัง ได้แก่ แพทย์คนไหนว่างเมื่อไร เวรหนึ่งยาวกี่ชั่วโมง แพทย์ Part-time ทำได้กี่ชั่วโมงต่อสัปดาห์ ค่าตอบแทนแพทย์ชั่วโมงละเท่าไร และสาขาไหนอยู่ใกล้กันพอจะใช้แพทย์ร่วมกัน นอกจากนี้ต้องมี Decision Record ที่บันทึกการตัดสินใจทุกครั้ง

ก่อนเริ่มคำนวณ ผู้บริหารต้องรับรองกรอบการตัดสินใจสองส่วน คือ เป้าหมาย และ Constraint จากข้อมูลเหล่านี้ จากนั้น Optimizer เสนอการเปลี่ยนแปลงได้สามแบบ แบบแรก ปรับเวลาเวรภายในสาขาโดยใช้ชั่วโมงเท่าเดิม แบบที่สอง ย้ายเวร Part-time ไปสาขาใกล้เคียงภายในวันเดียวกัน แบบที่สาม ตัดเวรที่ไม่จำเป็นออก โดยมีเงื่อนไขว่าเมื่อคำนวณกับข้อมูลที่ใช้วางแผน ผู้ป่วยทุกสาขาต้องไม่รอนานกว่าเดิม

แผนภูมิแท่งเปรียบเทียบข้อเสนอตารางเวรกับตารางปัจจุบัน ทดสอบกับข้อมูล 4 สัปดาห์ที่ไม่ได้ใช้ในการจัดตาราง ปรับเวลาในสาขาเดิม เวลารอลดลงราว 6% ย้ายเวรข้ามสาขาเพื่อรอน้อยที่สุด ลดลงราว 15% ย้ายเวรข้ามสาขาเพื่อค่าใช้จ่ายน้อยที่สุด ลดเวร Part-time ได้ 30 เวรต่อสัปดาห์ ประมาณ 3.2 ล้านบาทต่อปี แต่เวลารอเพิ่มขึ้นราว 6% ข้อมูลจำลองแผนภูมิแท่งเปรียบเทียบข้อเสนอตารางเวรกับตารางปัจจุบัน ทดสอบกับข้อมูล 4 สัปดาห์ที่ไม่ได้ใช้ในการจัดตาราง ปรับเวลาในสาขาเดิม เวลารอลดลงราว 6% ย้ายเวรข้ามสาขาเพื่อรอน้อยที่สุด ลดลงราว 15% ย้ายเวรข้ามสาขาเพื่อค่าใช้จ่ายน้อยที่สุด ลดเวร Part-time ได้ 30 เวรต่อสัปดาห์ ประมาณ 3.2 ล้านบาทต่อปี แต่เวลารอเพิ่มขึ้นราว 6% ข้อมูลจำลอง

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

ถ้าเป้าหมายคือลดเวลารอ ในช่วงทดสอบ เวลารอเฉลี่ยลดลงประมาณ 15% โดยใช้ชั่วโมงแพทย์เท่าเดิม (ข้อมูลจำลอง)

ถ้าเป้าหมายคือลดต้นทุน ลดเวร Part-time ได้ 30 เวรต่อสัปดาห์ คิดเป็นเงินประมาณ 3.2 ล้านบาทต่อปี แต่ในช่วงทดสอบ เวลารอเฉลี่ยเพิ่มขึ้นราว 6% จาก 36.3 เป็น 38.4 นาที (ข้อมูลจำลอง)

ตารางที่ดูดีบนข้อมูลที่ใช้วางแผน ไม่ได้รับประกันว่าจะได้ผลเหมือนเดิมในสัปดาห์ต่อ ๆ ไป ผู้บริหารจึงต้องเห็นทั้งสองด้านก่อนตัดสินใจ Optimizer เสนอทางเลือก แต่ไม่ได้ตัดสินใจแทน

กฎทุกข้อมีราคา และต้นทุนลดลงแบบขั้นบันได

กฎการทำงานทุกข้อมีราคาที่ต้องจ่าย และวัดเป็นตัวเลขได้ ในข้อมูลจำลอง ถ้ากำหนดให้แพทย์อยู่สาขาเดิมและปรับได้เฉพาะเวลาเข้าเวร เวลารอจะลดลงประมาณ 6% แต่ถ้ายอมให้ย้ายเวร Part-time ไปสาขาใกล้เคียงได้ภายในวันเดียวกัน จะลดได้ประมาณ 15% ผู้บริหารจึงเห็นชัดว่ากฎแต่ละข้อ "แพง" แค่ไหน และตัดสินใจได้ว่าคุ้มที่จะคงไว้หรือไม่

ต้นทุนลดลงแบบขั้นบันได ไม่ได้ค่อย ๆ ลดลง การตัดเวรต้องตัดทีละเวรเต็ม เงินที่ประหยัดได้และเวลารอจึงขยับเป็นขั้นตามไปด้วย ตัวเลข "ประหยัดได้ 10%" ที่ไม่ระบุว่าตัดเวรไหน ใช้ตัดสินใจไม่ได้

พิสูจน์ด้วยกลุ่มควบคุม

ตัวเลขจากแบบจำลองยังไม่ใช่ผลลัพธ์ วิธีที่ถูกต้องคือทดลองตารางใหม่ในบางสาขา เทียบกับสาขาที่มีลักษณะใกล้เคียงกันซึ่งยังใช้ตารางเดิม

บันทึกการตัดสินใจทุกครั้งไว้ใน Decision Record แล้ววัดผลจริงจากคลังข้อมูลชุดเดิม ถ้าได้ผลจึงขยาย ถ้าไม่ได้ผลก็รู้เร็วและเสียน้อย

ออกแบบโครงการข้อมูลให้ไปถึงการตัดสินใจ

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

ออกแบบ Data Model ให้รองรับการตัดสินใจ เหมือนในตัวอย่างข้างต้น ให้เก็บทั้งข้อมูล Constraint ข้อมูลกำลังการให้บริการ และข้อมูลต้นทุนไว้ในคลังตั้งแต่แรก พร้อมมี Decision Record ที่บันทึกว่าใครตัดสินใจอะไร จากข้อเสนอใด

ตรวจรับโครงการจากการตัดสินใจที่ข้อมูลช่วยได้จริง ไม่ใช่จากจำนวน Dashboard เกณฑ์ตรวจรับควรระบุว่าข้อมูลจะช่วยการตัดสินใจเรื่องใด และจะวัดผลอย่างไร

จัดคนให้ครบบทบาท นอกจากวิศวกรข้อมูลและนักวิเคราะห์ ต้องมีผู้เชี่ยวชาญด้าน Optimization และผู้บริหารที่เป็นเจ้าของตัวชี้วัดอย่างชัดเจน ทุกฝ่ายทำงานเป็นวงจรเดียวกัน

วงจรการทำงานห้าขั้นตอนข้ามสี่ทีม ผู้บริหารกำหนดเป้าหมายและ Constraint จากนั้นทีมข้อมูลจัดเตรียมข้อมูล ทีม Optimization เสนอทางเลือก ฝ่ายปฏิบัติการลงมือทำและบันทึกการตัดสินใจ ผลกลับเข้าคลังข้อมูล แล้วเข้าสู่รอบถัดไปวงจรการทำงานห้าขั้นตอนข้ามสี่ทีม ผู้บริหารกำหนดเป้าหมายและ Constraint จากนั้นทีมข้อมูลจัดเตรียมข้อมูล ทีม Optimization เสนอทางเลือก ฝ่ายปฏิบัติการลงมือทำและบันทึกการตัดสินใจ ผลกลับเข้าคลังข้อมูล แล้วเข้าสู่รอบถัดไป

เลือกให้เป็น ไม่ใช่ทุกเรื่องที่คุ้มกับการทำ Optimization เรื่องที่คุ้มมีสามลักษณะ คือ ต้องตัดสินใจซ้ำเป็นประจำ มี Constraint ชัดเจน และวัดผลได้ เช่น ตารางเวร ระดับสต็อก และการจัดกำลังคน

ใช้ได้กับที่ไหนอีก

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

Constraint และเป้าหมายอาจต่างกัน แต่วิธีทำงานเหมือนกัน

ขีดจำกัดที่เราพูดตรง ๆ

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

Optimizer จะดีแค่ไหนขึ้นอยู่กับ Constraint ที่ใส่เข้าไป ถ้าข้อมูลวันว่างของแพทย์ไม่ถูกต้อง ตารางที่ได้ก็ใช้ไม่ได้

ที่สำคัญที่สุด ถ้าไม่มีใครเป็นเจ้าของการตัดสินใจ วิธีนี้ก็ช่วยอะไรไม่ได้

ข้อสรุป

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

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

คุณไม่ต้องสร้างเอง แค่กำหนดกรอบให้ชัด

Infozense ไม่ได้ขาย Solver และไม่ได้ขอให้คุณเปลี่ยนเครื่องมือที่ใช้อยู่ เราทำงานร่วมกับทีมของคุณดังนี้

  • ร่วมกำหนดกรอบการตัดสินใจที่เกิดซ้ำ ทั้งเป้าหมาย ทั้ง Constraint และสิ่งที่ยอมแลกได้ โดยผู้บริหารเป็นผู้รับรองกรอบ
  • เพิ่มข้อมูล Constraint ข้อมูลต้นทุน และ Decision Record เข้าไปในคลังข้อมูลที่มีอยู่
  • เชื่อมต่อ Solver แบบ Open-source หรือเชิงพาณิชย์ที่คุณเลือก
  • ออกแบบการทดลองกับกลุ่มควบคุม เพื่อวัดผลจริง

สิ่งที่คุณกำหนดคือการตัดสินใจ เป้าหมาย และกฎการทำงาน ไม่ใช่โค้ด

Infozense Decision Modeling

ไตรมาสที่แล้ว ข้อมูลของคุณเปลี่ยนการตัดสินใจเรื่องไหนบ้าง

เราใช้เครือข่ายคลินิกจำลอง 45 สาขาเพื่อแสดงวิธีคิดนี้ แต่องค์กรของคุณมีการตัดสินใจ มี Constraint และมีตัวเลขของตัวเอง เล่าให้เราฟังว่าองค์กรของคุณต้องตัดสินใจเรื่องใดซ้ำ ๆ แล้วเราจะร่วมกำหนดกรอบกับผู้บริหารและทีมข้อมูลของคุณ ใช้เวลา 2 ชั่วโมง ไม่มีค่าใช้จ่าย สิ่งที่คุณจะได้กลับไปคือการตัดสินใจ 3 เรื่องที่จะคุ้มค่าที่สุดเมื่อมีข้อมูลสนับสนุน และรายการข้อมูลที่คลังของคุณยังขาด

คุยกับเรา →

contact@infozense.com  |  +66-82-242-4008  |  Bangkok, Thailand