วิธีนำการปรับปรุงกระบวนการไปใช้: คู่มือปฏิบัติจริง

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

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

ช่องว่างระหว่างสิ่งที่ค้นพบกับการลงมือทำ

คุณวิเคราะห์กระบวนการแล้วและพบโอกาสที่จะพัฒนา แม้หลักฐานจะชัดเจน แต่หลักฐานเพียงอย่างเดียวไม่ได้เปลี่ยนวิธีทำงาน.

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

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

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

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

ก่อนเริ่ม: กระบวนการนี้ควรปรับปรุงหรือไม่?

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

ลองถาม 3 ข้อ:

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

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

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

ขั้นตอนที่ 1: ดึงผู้เกี่ยวข้องให้เหมาะสมเข้ามามีส่วนร่วม

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

ระบุผู้มีส่วนเกี่ยวข้องหลัก

เลือกผู้เข้าร่วมให้เหมาะกับการเปลี่ยนแปลง การปรับวิธีทำงานเล็กน้อยในทีมหนึ่งอาจต้องเชิญคนละกลุ่มกับการเปลี่ยนระบบที่ใช้ร่วมกันหรือกระบวนการที่อยู่ภายใต้ข้อกำหนด.

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

ชวนเข้าร่วมตั้งแต่เนิ่นๆ

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

การให้เข้ามามีส่วนร่วมตั้งแต่เนิ่นๆ ช่วยให้คุณ:

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

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

กำหนดผู้รับผิดชอบให้ชัดเจน

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

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

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

ขั้นตอนที่ 2: จัดลำดับความสำคัญของโอกาส

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

เลือกเกณฑ์ประเมิน

ให้คะแนนแต่ละแนวทางตามเกณฑ์ที่สะท้อนผลลัพธ์และงานที่ต้องทำ ตกลงระดับคะแนนก่อนเริ่มให้คะแนน เพื่อให้คะแนนเดียวกันมีความหมายเหมือนกันในทุกแนวคิด.

ตัวอย่างวิธีให้คะแนนที่นำไปใช้ได้จริง โดยให้คะแนนแต่ละเกณฑ์ตั้งแต่ 1 ถึง 5:

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

นำคะแนนแต่ละเกณฑ์คูณด้วยน้ำหนัก แล้วบวกผลลัพธ์เข้าด้วยกัน ตัวอย่างเช่น โอกาสหนึ่งได้คะแนนด้านคุณค่า 4 ด้านความพยายาม 3 ด้านความเสี่ยงและการย้อนกลับ 4 และด้านความสอดคล้องกับกลยุทธ์ 5 จะได้คะแนนดังนี้:

• คุณค่าที่คาดหวัง: 4 × 40% = 1.60
• ความพยายาม: 3 × 25% = 0.75
• ความเสี่ยงและการย้อนกลับ: 4 × 20% = 0.80
• ความสอดคล้องกับกลยุทธ์: 5 × 15% = 0.75
• รวม: 3.90 จาก 5

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

ใช้เมทริกซ์จัดลำดับความสำคัญ

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

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

รักษาสมดุลระหว่างงานที่เห็นผลเร็วกับการเปลี่ยนแปลงเชิงกลยุทธ์

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

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

บันทึกการตัดสินใจ

จัดทำบันทึกการตัดสินใจสั้นๆ สำหรับแต่ละโอกาส:

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

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

ขั้นตอนที่ 3: วางแผนนำไปใช้

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

กำหนดเป้าหมายและวิธีวัดผล

จดบันทึกว่าต้องการเปลี่ยนอะไร จะวัดผลอย่างไร และอะไรต้องคงเดิม โดยระบุ:

• ตัวชี้วัดเป้าหมาย: ผลลัพธ์ที่คาดว่าจะพัฒนา
• ค่าฐาน: ค่าเริ่มต้น ช่วงเวลาที่วัด และคำจำกัดความของเคส
• เป้าหมาย: ผลลัพธ์ที่ต้องการพร้อมสมมติฐานที่ใช้
• ตัวชี้วัดเฝ้าระวัง: ผลลัพธ์อื่นที่ต้องรักษาไว้ เช่น คุณภาพ การปฏิบัติตามข้อกำหนด หรือภาระงาน
• จุดวัดผล: เวลาและวิธีประเมินผลลัพธ์.

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

แจกแจงงาน ผู้รับผิดชอบ และกำหนดเวลา

แบ่งการเปลี่ยนแปลงออกเป็นงานที่มีผู้รับผิดชอบได้ สำหรับแต่ละงาน ให้บันทึก:

1. ต้องทำอะไร
2. ใครรับผิดชอบและใครอนุมัติ
3. ต้องทำอะไรให้เสร็จก่อน
4. เกี่ยวข้องกับระบบ ทีม หรือทรัพยากรใดบ้าง
5. คาดว่าจะทำงานให้เสร็จเมื่อใด
6. จะตรวจสอบว่างานเสร็จแล้วอย่างไร.

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

ระบุความเสี่ยงและแนวทางลดผลกระทบ

ลองพิจารณาว่าอะไรอาจทำให้การเปลี่ยนแปลงไม่ได้ผลหรือก่อปัญหาใหม่ เช่น:

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

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

ยืนยันความเข้าใจตรงกันและความรับผิดชอบ

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

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

ขั้นตอนที่ 4: ทดลองก่อนนำไปใช้จริง

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

สร้างแบบจำลองการเปลี่ยนแปลงที่เสนอ

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

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

ทดลองสถานการณ์สมมติ

ใช้การจำลองกระบวนการเปรียบเทียบแบบจำลองที่เสนอเข้ากับค่าฐานจาก process mining ด้วยการวิเคราะห์สถานการณ์สมมติ คุณจะทดลองสถานการณ์ที่อาจเปลี่ยนผลลัพธ์ได้ เช่น ปริมาณเคส ส่วนผสมของเคส หรือความพร้อมของทรัพยากรที่แตกต่างกัน.

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

จำลองการเปลี่ยนแปลงก่อนลงมือทำ

ตรวจสอบว่าคอขวดย้ายตำแหน่งหรือไม่

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

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

หากผลการจำลองขัดกับกรณีธุรกิจควรทำอย่างไร?

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

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

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

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

ขั้นตอนที่ 5: สื่อสารการเปลี่ยนแปลง

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

อธิบายการเปลี่ยนแปลงให้ผู้เกี่ยวข้องนำไปใช้ได้จริง:

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

ปรับเนื้อหาให้เหมาะกับผู้รับสาร ผู้บริหารอาจต้องทราบการตัดสินใจ ความเสี่ยง และตัวชี้วัด ส่วนผู้ปฏิบัติงานต้องการคำแนะนำที่ชัดเจน การฝึกอบรมเมื่อจำเป็น และช่องทางแจ้งปัญหา ผู้จัดการต้องรู้ว่าตนมีหน้าที่สนับสนุนเรื่องใดและควรยกระดับปัญหาเมื่อใด.

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

ขั้นตอนที่ 6: วัดผลและรักษาการเปลี่ยนแปลงให้ต่อเนื่อง

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

เปรียบเทียบผลกับค่าฐาน

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

ลองถามว่า:

• ตัวชี้วัดเป้าหมายเปลี่ยนไปในทิศทางที่คาดไว้หรือไม่
• ตัวชี้วัดเฝ้าระวังแย่ลงหรือไม่
• การเปลี่ยนแปลงส่งผลต่อเคสที่เกี่ยวข้องทั้งหมดหรือเพียงบางส่วน
• ผลลัพธ์ที่สังเกตได้สม่ำเสมอต่อเนื่องหรือไม่
• มีสมมติฐานหรือเงื่อนไขใดเปลี่ยนไปหลังนำไปใช้?

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

จัดให้มีการติดตามอย่างต่อเนื่อง

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

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

ทำให้เห็นผู้รับผิดชอบชัดเจน

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

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

นำโอกาสถัดไปเข้าสู่วงจรการพัฒนา

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

หากต้องการดูกรอบการพัฒนาในภาพรวม อ่านวิธีทำวงจร DMAIC ตั้งแต่ต้นจนจบ.

อะไรทำให้การปรับปรุงกระบวนการสะดุดบ่อยที่สุด?

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

เทมเพลตและเช็กลิสต์อะไรบ้างที่ช่วยให้คุณนำการเปลี่ยนแปลงไปใช้ได้?

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

เทมเพลตตารางจัดลำดับความสำคัญ

บันทึกข้อมูลต่อไปนี้สำหรับแต่ละทางเลือก:

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

เทมเพลตแผนการนำไปใช้

สร้างหนึ่งแถวสำหรับแต่ละการดำเนินการหรือการตัดสินใจ:

ก่อนเริ่มใช้งาน

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

หลังเริ่มใช้งาน

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

จากนี้ควรทำอะไรต่อ?

ตอนนี้คุณมีโอกาสที่จัดลำดับความสำคัญแล้วและมีแผนนำไปใช้ ก่อนเปลี่ยนแปลงระบบที่ใช้งานจริง ให้ทดสอบข้อเสนอเทียบกับค่าฐานจาก process mining และทบทวนว่าแบบจำลองสนับสนุนข้อสรุปใดได้บ้างและไม่ได้บ้าง.

ทดสอบการเปลี่ยนแปลงในโมเดล ไม่ใช่ในระบบจริง