ทีม Kaizen หรือ QC Circle ที่ลงมือแก้ปัญหาหน้างานจนสำเร็จ มักเจอปัญหาเดียวกันเสมอ คือทำงานดีมาตลอด 3-4 เดือน แต่พอถึงเวลาต้องเล่าให้ผู้บริหารหรือทีมอื่นฟังใน 10 นาที กลับเล่าไม่เป็นลำดับ ข้ามขั้นตอนสำคัญ หรือเน้นแต่ผลลัพธ์จนคนฟังไม่เข้าใจว่าทำไมถึงเลือกแก้ปัญหาด้วยวิธีนั้น QC Story คือคำตอบของปัญหานี้ คือโครงเรื่องมาตรฐาน 8 ขั้นตอนที่ใช้เล่าและนำเสนอผลงานปรับปรุงที่ทำเสร็จแล้วให้มีเหตุมีผล ตรวจสอบย้อนกลับได้ทุกขั้น และเป็นรูปแบบเดียวกับที่คณะกรรมการ TPM Award ใช้อ่านผลงานของแต่ละโรงงานทั่วโลก
QC Story คืออะไร
QC Story คือโครงสร้างการเล่าเรื่อง (storyline) มาตรฐานที่ใช้สรุปและนำเสนอกิจกรรมปรับปรุงคุณภาพหรือ Kaizen ที่ทีมงานดำเนินการเสร็จสิ้นแล้ว มีต้นกำเนิดจากกิจกรรม QC Circle ในญี่ปุ่นช่วงทศวรรษ 1960 ที่ต้องการวิธีให้กลุ่มย่อยหน้างานนำเสนอผลงานให้ผู้บริหารและกลุ่มอื่นเข้าใจได้ง่าย ภายหลังแนวคิดนี้ถูกนำมาใช้ในกิจกรรม Focused Improvement (FI) ของ TPM แทบทั้งหมด เพราะโครงเรื่อง 8 ขั้นตอนของ QC Story ตรงกับขั้นตอนการทำ Kaizen แบบ FI ตามแนวทาง JIPMแทบทุกขั้น ต่างกันเพียงว่า QC Story เน้นที่ "การนำเสนอผลลัพธ์" ส่วน FI 8 ขั้นตอนเน้นที่ "การลงมือทำ" เท่านั้น
สิ่งที่ต้องเข้าใจให้ชัดคือ QC Story ไม่ใช่วิธีคิดหรือวิธีแก้ปัญหา แต่เป็น "รูปแบบรายงาน" ทีมงานยังคงต้องใช้เครื่องมือคุณภาพ วิธีวิเคราะห์สาเหตุ และการตัดสินใจเลือกมาตรการตามกระบวนการปกติ เพียงแต่เมื่อถึงเวลาสรุปผลงานเป็นสไลด์หรือโปสเตอร์ ให้จัดเรียงเนื้อหาตามโครงเรื่อง 8 ขั้นตอนนี้ เพื่อให้คนอ่านที่ไม่ได้อยู่ในทีมตั้งแต่ต้น สามารถไล่ตามตรรกะได้ตั้งแต่ "ทำไมถึงเลือกเรื่องนี้" ไปจนถึง "จะทำอะไรต่อ" โดยไม่ต้องถามซ้ำระหว่างฟัง
QC Story ต่างจาก PDCA อย่างไร
คำถามที่พบบ่อยที่สุดคือ QC Story กับ PDCA (Plan-Do-Check-Act) คือเรื่องเดียวกันหรือไม่ คำตอบคือไม่ใช่คู่แข่งกัน แต่ทำหน้าที่คนละชั้น PDCA คือวงจรการทำงานที่ทีมใช้ขับเคลื่อนกิจกรรมปรับปรุงในระหว่างที่ยังลงมือทำอยู่ เป็นเข็มทิศบอกว่าตอนนี้อยู่ขั้นไหน ขั้นต่อไปควรทำอะไร ส่วน QC Story คือรูปแบบการเล่าเรื่องที่ใช้หลังจากกิจกรรมเสร็จสิ้นแล้ว เพื่อสรุปสิ่งที่ทำทั้งหมดให้อยู่ในโครงเรื่องเดียวที่คนอื่นเข้าใจง่าย พูดให้สั้นคือ PDCA เป็นกระบวนการคิดและลงมือทำ ส่วน QC Story เป็นบรรจุภัณฑ์สำหรับนำผลลัพธ์นั้นไปสื่อสารต่อ
ในสายงานที่ไลน์ผลิตเดินเครื่องอยู่แล้วและไม่ได้เริ่มจากศูนย์ หลายทีมเลือกใช้วงจร Cap-Do แทน PDCA แบบดั้งเดิม เพราะ Cap-Do เริ่มจากขั้น Check ก่อน คือไปตรวจสภาพจริงของเครื่องจักรและกระบวนการที่กำลังทำงานอยู่ ก่อนย้อนกลับไปวางแผน ไม่ว่าทีมจะใช้วงจร PDCA แบบคลาสสิกหรือ Cap-Do ในการลงมือทำงานจริง เมื่อถึงเวลาสรุปผลงานเพื่อนำเสนอ โครงเรื่อง QC Story ทั้ง 8 ขั้นตอนยังคงใช้รูปแบบเดียวกันเสมอ เพราะ QC Story ไม่ได้ผูกกับว่าทีมใช้วงจรปรับปรุงแบบใด แต่ผูกกับลำดับตรรกะของการแก้ปัญหาซึ่งเป็นสากล ไม่ว่าจะเริ่มจาก Plan หรือ Check ก่อนก็ตาม
| ประเด็นเปรียบเทียบ | PDCA (และ Cap-Do) | QC Story |
|---|---|---|
| บทบาทหลัก | วงจรการคิดและลงมือทำระหว่างกิจกรรม | โครงเรื่องสรุปผลงานหลังกิจกรรมเสร็จ |
| ช่วงเวลาที่ใช้ | ใช้ตลอดอายุโครงการ ตั้งแต่เริ่มจนจบ | ใช้ตอนเตรียมนำเสนอหรือรายงานผลงาน |
| ลักษณะโครงสร้าง | วงจรหมุนซ้ำได้หลายรอบ | โครงเรื่องเชิงเส้น 8 ขั้นตอนตามลำดับ |
| ผู้ใช้งานหลัก | ทีมงานขณะลงมือแก้ปัญหา | ทีมงานและผู้ฟัง เช่น ผู้บริหาร ทีมอื่น กรรมการตัดสิน |
| ผลลัพธ์ที่ได้ | การกระทำและการตัดสินใจในแต่ละขั้น | สไลด์หรือโปสเตอร์ที่เล่าเรื่องได้ครบถ้วน |
8 ขั้นตอนมาตรฐานของ QC Story
โครงเรื่อง QC Story แบ่งเป็น 8 ขั้นตอนเรียงตามลำดับตรรกะ แต่ละขั้นควรมีพื้นที่ของตัวเองบนสไลด์หรือโปสเตอร์อย่างชัดเจน ห้ามข้ามหรือรวบขั้นตอนเข้าด้วยกัน เพราะผู้ฟังที่ไม่ได้ร่วมทีมตั้งแต่ต้นจะตามเรื่องไม่ทัน หัวข้อถัดจากนี้ลงรายละเอียดทีละขั้นว่าควรมีเนื้อหาอะไรบนสไลด์ ข้อผิดพลาดที่พบบ่อยในขั้นนั้น และตัวอย่างเนื้อหาสั้น ๆ ประกอบความเข้าใจ
ขั้นที่ 1: เลือกหัวข้อ (Theme Selection)
ขั้นแรกของ QC Story ต้องตอบคำถามเดียวให้ชัดเจนคือทำไมทีมถึงเลือกทำเรื่องนี้ ไม่ใช่เรื่องอื่น หัวข้อที่ดีต้องเชื่อมโยงกับนโยบายบริษัทหรือ KPI ของหน่วยงานอย่างมีที่มาที่ไป ไม่ใช่เลือกเพราะสมาชิกทีมถนัดหรือเพราะทำง่ายเห็นผลไว สไลด์หรือช่องแรกของโปสเตอร์ในขั้นนี้ควรมีลำดับชั้นของนโยบายที่เชื่อมจากเป้าหมายระดับโรงงานลงมาสู่หัวข้อที่เลือก เช่น เชื่อมกับโครงสร้าง KMI-KPI-KAIของหน่วยงาน หรือเชื่อมกับผลจากCost Deploymentที่ชี้ว่าความสูญเสียใดมีมูลค่าสูงสุดในสายการผลิต จากนั้นจึงแสดงตารางเปรียบเทียบหัวข้อที่เป็นตัวเลือกหลายเรื่อง พร้อมให้คะแนนตามเกณฑ์ เพื่อแสดงว่าทีมไม่ได้เลือกหัวข้อนี้แบบสุ่ม แต่ผ่านการเทียบกับตัวเลือกอื่นมาแล้ว
ข้อผิดพลาดที่พบบ่อยที่สุดในขั้นนี้คือทีมงาน "รู้คำตอบอยู่ก่อนแล้ว" เช่น อยากติดตั้งอุปกรณ์ใหม่ชิ้นหนึ่งอยู่แล้ว จึงตั้งหัวข้อและเรื่องราวทั้งหมดย้อนกลับไปเพื่อพาไปสู่คำตอบที่ตั้งใจไว้ตั้งแต่ต้น ทำให้ขั้นวิเคราะห์สาเหตุในภายหลังกลายเป็นพิธีกรรมที่ไม่ได้ใช้ค้นหาสาเหตุจริง อีกข้อที่พบบ่อยคือเลือกหัวข้อที่ใหญ่เกินขอบเขตที่ทีมควบคุมได้ เช่น "ลด Downtime ทั้งโรงงาน" ซึ่งกว้างเกินกว่าจะวิเคราะห์สาเหตุและวัดผลได้จริงภายในรอบกิจกรรมเดียว หัวข้อที่ดีควรเจาะจงเพียงพอ เช่นเปลี่ยนจาก "ลด Downtime" เป็นลดเวลาสูญเสียจากการเปลี่ยนรุ่นของเครื่องบรรจุสาย 2ซึ่งวัดผลและควบคุมตัวแปรได้ชัดเจนกว่ามาก
| หัวข้อที่พิจารณา | เชื่อมกับ KPI องค์กร | มูลค่าความสูญเสีย/ปี | ความพร้อมของทีม | คะแนนรวม |
|---|---|---|---|---|
| ลดเวลาเปลี่ยนรุ่นเครื่องบรรจุสาย 2 | สูง | 1,240,000 บาท | สูง | 27/30 |
| ลด Minor Stop เครื่องพันฉลาก | ปานกลาง | 680,000 บาท | ปานกลาง | 19/30 |
| ลดของเสียจุดปิดผนึกซอง | สูง | 950,000 บาท | ปานกลาง | 23/30 |
| ปรับความเร็วเครื่องให้ถึงเป้า Design Speed | ปานกลาง | 410,000 บาท | ต่ำ | 14/30 |
จากตัวอย่างในตาราง ทีมเลือกหัวข้อ "ลดเวลาเปลี่ยนรุ่นเครื่องบรรจุสาย 2" เพราะได้คะแนนรวมสูงสุด ทั้งในมิติมูลค่าความสูญเสียและความพร้อมของทีมที่จะลงมือทำได้จริงภายในกรอบเวลาที่กำหนด หัวข้อนี้จะถูกใช้เป็นตัวอย่างเดินเต็มในหัวข้อถัดไปของบทความนี้ด้วย
ขั้นที่ 2: ทำความเข้าใจสภาพปัจจุบันและตั้งเป้าหมาย (Grasp Current Status and Set Target)
ขั้นนี้คือหัวใจที่ทำให้ QC Story น่าเชื่อถือหรือไม่น่าเชื่อถือ หลักการสำคัญคือทุกอย่างต้องเป็นตัวเลขจากข้อมูลจริง ไม่ใช่ความรู้สึกของทีม ก่อนจะนิยามปัญหาให้ถูกต้อง ทีมควรทบทวนนิยามของคำว่า "ปัญหา" ให้ชัดเจนก่อนว่าคือช่องว่างระหว่างสภาพที่ควรจะเป็นกับสภาพที่เป็นอยู่จริง ไม่ใช่แค่สิ่งที่รู้สึกว่าไม่โอเค สไลด์หรือช่องนี้บนโปสเตอร์ควรมีข้อมูลสภาพปัจจุบันที่ผ่านการแบ่งชั้น (stratification) แล้ว เช่น แยกตามกะ ตามเครื่องจักร ตามรุ่นสินค้า หรือตามช่วงเวลา เพื่อชี้ให้เห็นว่าปัญหากระจุกตัวอยู่ที่ไหน ตามด้วยกราฟพาเรโตแสดงว่าสาเหตุกลุ่มใดมีสัดส่วนสูงสุด และปิดท้ายด้วยเป้าหมายที่ตั้งเป็นตัวเลขชัดเจน มีหน่วยวัด มีกรอบเวลา และอ้างอิงค่ามาตรฐานหรือค่าเป้าหมายในอุตสาหกรรม เช่น เทียบกับฐานข้อมูลManufacturing KPIของเครื่องจักรประเภทเดียวกัน
ข้อผิดพลาดที่พบบ่อยที่สุดคือการตั้งเป้าหมายด้วยคำพูดกว้าง ๆ เช่น "ลดเวลาเปลี่ยนรุ่นให้เร็วขึ้น" หรือ "ทำให้เครื่องเสถียรขึ้น" ซึ่งไม่มีทางตรวจสอบในขั้นที่ 6 ได้ว่าบรรลุเป้าหมายหรือไม่ เป้าหมายที่ถูกต้องต้องระบุค่าเริ่มต้น ค่าที่ต้องการ และกรอบเวลาเสมอ เช่น "ลดเวลาเปลี่ยนรุ่นจากค่าเฉลี่ย 48 นาทีเหลือไม่เกิน 25 นาที ภายใน 12 สัปดาห์" อีกข้อผิดพลาดที่พบคือเก็บข้อมูลสภาพปัจจุบันเพียงช่วงสั้น ๆ 2-3 วันแล้วสรุปเป็นค่าเฉลี่ยทันที ทั้งที่ความผันผวนตามกะหรือฤดูกาลยังไม่ถูกนำมาพิจารณา ทำให้เป้าหมายที่ตั้งไว้คลาดเคลื่อนจากความเป็นจริงและตรวจสอบผลในขั้นหลังได้ยาก
| รายการข้อมูลสภาพปัจจุบัน | ค่าที่เก็บได้ | วิธีเก็บข้อมูล |
|---|---|---|
| เวลาเปลี่ยนรุ่นเฉลี่ย (4 สัปดาห์ย้อนหลัง) | 48.3 นาที/ครั้ง | บันทึกเวลาเริ่ม-จบจริงหน้างาน 32 ครั้ง |
| ค่าสูงสุด-ต่ำสุดของเวลาเปลี่ยนรุ่น | 71 / 33 นาที | คำนวณจากข้อมูลชุดเดียวกัน |
| สัดส่วนเวลาที่เสียกับการค้นหาอุปกรณ์ | 34% | ถ่ายวิดีโอและจับเวลาย่อยแต่ละกิจกรรม |
| เป้าหมาย (Target) | ไม่เกิน 25 นาที/ครั้ง ภายใน 12 สัปดาห์ | อ้างอิงค่าเฉลี่ยอุตสาหกรรมและ Design Capacity |
ขั้นที่ 3: วางแผนกิจกรรม (Activity Plan)
เมื่อมีเป้าหมายเป็นตัวเลขแล้ว ขั้นถัดไปคือวางแผนว่าจะไปถึงเป้าหมายนั้นด้วยกิจกรรมอะไรบ้าง ใครรับผิดชอบ และภายในกรอบเวลาใด สไลด์ในขั้นนี้มักแสดงเป็นตารางแผนกิจกรรมแบบ Gantt อย่างง่าย ระบุกิจกรรมหลักตั้งแต่การวิเคราะห์สาเหตุ ทดลองมาตรการ ตรวจสอบผล จนถึงจัดทำมาตรฐาน พร้อมชื่อผู้รับผิดชอบรายกิจกรรมและกำหนดวันแล้วเสร็จ จุดที่มักถูกมองข้ามคือแผนที่ดีควรมีคอลัมน์เปรียบเทียบ "แผน" กับ "ผลจริง" ไว้ตั้งแต่ต้น เพื่อให้เห็นว่าทีมบริหารความคลาดเคลื่อนของแผนอย่างไรระหว่างทาง ซึ่งเป็นข้อมูลที่มีค่ามากสำหรับทีมอื่นที่จะทำโครงการลักษณะเดียวกันในอนาคต
ข้อผิดพลาดที่พบบ่อยคือระบุผู้รับผิดชอบเป็น "ทีมงาน" หรือชื่อแผนกรวม ๆ โดยไม่มีชื่อบุคคลจริงกำกับ ทำให้เมื่อถึงกำหนดแล้วไม่มีใครรู้สึกเป็นเจ้าของงานนั้นจริง อีกข้อคือตั้งกรอบเวลาที่บีบแน่นเกินไปจนไม่เหลือช่วงสำหรับทบทวนหรือปรับแผน โดยเฉพาะขั้นวิเคราะห์สาเหตุที่มักใช้เวลานานกว่าที่ทีมประเมินไว้เสมอ ควรกันเวลาสำรองไว้อย่างน้อย 20-30% ของกรอบเวลารวม และเมื่อแผนคลาดเคลื่อนจริงในภายหลัง ให้บันทึกไว้ตรง ๆ บนสไลด์แทนการลบแผนเดิมทิ้งแล้วเขียนใหม่ให้ดูเหมือนไม่เคยพลาด เพราะความคลาดเคลื่อนที่มีเหตุผลรองรับคือข้อมูลที่แสดงวุฒิภาวะของทีม ไม่ใช่จุดด้อย
| กิจกรรม | ผู้รับผิดชอบ | แผน (สัปดาห์) | ผลจริง (สัปดาห์) |
|---|---|---|---|
| เก็บข้อมูลสภาพปัจจุบันและตั้งเป้าหมาย | หัวหน้าทีม + สมาชิก 2 คน | สัปดาห์ 1-2 | สัปดาห์ 1-2 |
| วิเคราะห์สาเหตุหน้างาน | ช่างเทคนิคประจำเครื่อง | สัปดาห์ 3-4 | สัปดาห์ 3-6 |
| ทดลองและดำเนินมาตรการ | วิศวกรกระบวนการ | สัปดาห์ 5-8 | สัปดาห์ 7-9 |
| ตรวจสอบผลเทียบเป้าหมาย | หัวหน้าทีม | สัปดาห์ 9-10 | สัปดาห์ 10-11 |
| จัดทำมาตรฐานและอบรม | หัวหน้าทีม + QA | สัปดาห์ 11-12 | สัปดาห์ 12-13 |
ขั้นที่ 4: วิเคราะห์สาเหตุ (Cause Analysis)
ขั้นนี้คือจุดที่ตัดสินว่า QC Story เรื่องหนึ่งมีคุณภาพจริงหรือเป็นเพียงรายงานสวยงาม หลักการข้อแรกที่ต้องยึดก่อนเปิดเครื่องมือใดเลยคือต้องไปดูสภาพจริงหน้างานก่อนเสมอ ตามหลัก3-Gen คือ Genba Genbutsu Genjitsu หรือไปสถานที่จริง ดูของจริง เข้าใจสภาพการณ์จริงทีมที่วิเคราะห์สาเหตุจากความจำหรือจากประสบการณ์เก่าโดยไม่ไปยืนดูหน้างานจริง มักตั้งสมมติฐานผิดตั้งแต่ต้น เมื่อเข้าใจสภาพจริงแล้ว จึงเลือกเครื่องมือวิเคราะห์ให้เหมาะกับลักษณะปัญหา ปัญหาที่มีสาเหตุค่อนข้างตรงไปตรงมาและเป็นเหตุการณ์เดี่ยว ใช้Why-Why Analysis หรือ 5 Whyไล่ถามทำไมต่อเนื่องจนถึงรากสาเหตุที่ลงมือแก้ได้จริง ปัญหาที่เป็นข้อมูลเชิงสถิติจากหลายเหตุการณ์ ใช้ชุดเครื่องมือในQC 7 Toolsเช่นผังก้างปลาแบ่งตามหมวด 4M ซึ่งอธิบายไว้ละเอียดใน4M Analysisร่วมกับกราฟพาเรโตและฮิสโตแกรมเพื่อยืนยันน้ำหนักของแต่ละสาเหตุด้วยข้อมูลจริง ส่วนปัญหาเรื้อรังที่แก้แล้วแก้อีกไม่หายสักที มักต้องใช้P-M Analysisซึ่งวิเคราะห์ลงไปถึงกลไกทางฟิสิกส์ของความผิดปกติ ไม่ใช่แค่ตั้งสมมติฐานตามประสบการณ์
ข้อผิดพลาดที่พบบ่อยที่สุดในขั้นนี้คือสิ่งที่เรียกว่าวิเคราะห์สาเหตุที่พูดซ้ำอาการ เช่น ปัญหาคือ "เปลี่ยนรุ่นช้า" แล้วสรุปสาเหตุว่า "เพราะขั้นตอนเปลี่ยนรุ่นใช้เวลานาน" ซึ่งเป็นประโยคเดียวกับปัญหาแค่เปลี่ยนคำ ไม่ได้ขุดลึกลงไปว่าเวลานานเพราะอะไร เช่น เพราะต้องเดินไปหยิบอุปกรณ์ที่จุดเก็บไกลจากเครื่อง หรือเพราะต้องรอช่างปรับตั้งคนเดียวที่ดูแลหลายเครื่องพร้อมกัน การวิเคราะห์ที่ตื้นเกินไปแบบนี้ทำให้มาตรการที่ตามมาในขั้นที่ 5 แก้ไม่ตรงจุด และผลลัพธ์มักไม่ยั่งยืน หากปัญหามีหลายสาเหตุที่ประกอบกันจนนำไปสู่ความเสียหายใหญ่หรือเกี่ยวข้องกับความปลอดภัย ควรขยายไปใช้FTA (Fault Tree Analysis)ที่แสดงความสัมพันธ์ของสาเหตุหลายเส้นทางเป็นแผนภาพต้นไม้ แทนการไล่เป็นเส้นตรงแบบ Why-Why เพียงอย่างเดียว
ตัวอย่างเนื้อหาสั้น ๆ ที่ควรปรากฏบนสไลด์ขั้นนี้ คือห่วงโซ่ Why-Why ที่ไล่จนถึงรากสาเหตุที่ลงมือแก้ได้จริง ไม่ใช่หยุดกลางทางเมื่อเจอคำตอบแรกที่ฟังดูสมเหตุสมผล
- ทำไมเปลี่ยนรุ่นใช้เวลานาน เพราะช่างต้องเดินไปหยิบไขควงและปลอกหกเหลี่ยมที่ตู้เก็บเครื่องมือกลางไลน์
- ทำไมต้องเดินไปหยิบทุกครั้ง เพราะไม่มีชุดเครื่องมือประจำเครื่องแต่ละจุด
- ทำไมไม่มีชุดเครื่องมือประจำเครื่อง เพราะตอนออกแบบไลน์ไม่ได้กำหนดมาตรฐานจุดเก็บเครื่องมือไว้
- ทำไมไม่ได้กำหนดมาตรฐานไว้ เพราะไม่เคยมีใครวัดเวลาที่เสียไปกับการเดินหาเครื่องมือมาก่อน จึงไม่เห็นว่าเป็นปัญหา
รากสาเหตุที่แท้จริงจึงไม่ใช่ "ช่างทำงานช้า" แต่คือ "ไม่มีมาตรฐานจุดเก็บเครื่องมือประจำเครื่อง" ซึ่งนำไปสู่มาตรการที่ตรงจุดในขั้นถัดไป ต่างจากการสรุปตื้น ๆ ที่มักโทษตัวบุคคลแทนระบบงาน
ขั้นที่ 5: พิจารณาและดำเนินมาตรการ (Countermeasure)
เมื่อได้รากสาเหตุที่แท้จริงจากขั้นที่ 4 แล้ว ขั้นนี้คือการระดมความคิดหามาตรการที่เป็นไปได้หลายทาง ไม่ใช่หยิบไอเดียแรกที่คิดออกมาลงมือทำทันที สไลด์ในขั้นนี้ควรแสดงตารางเปรียบเทียบมาตรการที่พิจารณาทั้งหมด ให้คะแนนตามเกณฑ์ เช่น ประสิทธิผลในการแก้ที่รากสาเหตุ ความเป็นไปได้ในการทำจริงภายในกรอบเวลาและงบประมาณ และผลกระทบต่อความปลอดภัยหรือคุณภาพด้านอื่น จากนั้นจึงเลือกมาตรการที่ได้คะแนนสูงสุดไปทดลองใช้ในขอบเขตเล็กก่อน เช่น 1 เครื่องหรือ 1 กะ ก่อนขยายผลเต็มรูปแบบ การทดลองในขอบเขตเล็กก่อนมีประโยชน์สำคัญคือหากผลไม่เป็นไปตามคาด ทีมจะรู้ทันทีว่าเป็นเพราะมาตรการนั้นไม่ได้ผล ไม่ใช่ปัจจัยแวดล้อมอื่นที่ปะปนมา
ข้อผิดพลาดที่พบบ่อยคือดำเนินมาตรการหลายอย่างพร้อมกันทั้งหมดในคราวเดียว โดยหวังว่าอย่างน้อยหนึ่งในนั้นจะได้ผล เมื่อผลลัพธ์ออกมาดีขึ้นจริง ทีมกลับไม่สามารถชี้ได้ว่ามาตรการใดเป็นตัวที่ทำให้เกิดผล ทำให้ขั้นจัดมาตรฐานในภายหลังทำได้ไม่ตรงจุด อีกข้อที่พบบ่อยคือมาตรการที่เลือกแก้เพียงอาการปลายทางไม่ใช่รากสาเหตุ เช่น เพิ่มจำนวนคนช่วยหาเครื่องมือแทนที่จะทำจุดเก็บเครื่องมือประจำเครื่อง วิธีนี้ให้ผลเร็วในระยะสั้นแต่ไม่ยั่งยืนและมักกลับไปเป็นปัญหาเดิมเมื่อคนที่มาช่วยถูกโยกไปงานอื่น
| มาตรการที่พิจารณา | แก้ที่รากสาเหตุ | ความเป็นไปได้ | ต้นทุน | ผลตัดสินใจ |
|---|---|---|---|---|
| จัดชุดเครื่องมือประจำเครื่องแต่ละจุด (Shadow Board) | สูง | สูง | ต่ำ | เลือกดำเนินการ |
| เพิ่มช่างเทคนิคช่วยหาเครื่องมือ | ต่ำ | สูง | ปานกลาง | ไม่เลือก เพราะแก้แค่อาการ |
| ซื้อเครื่องมือชุดใหม่ราคาแพงกว่าเดิม | ต่ำ | ปานกลาง | สูง | ไม่เลือก เพราะไม่ตรงรากสาเหตุ |
| ทำ Standard Work พร้อมจุดจอดเครื่องมือแบบเห็นภาพ | สูง | สูง | ต่ำ | เลือกดำเนินการร่วมกับข้อแรก |
ขั้นที่ 6: ตรวจสอบผล (Check Results)
ขั้นตรวจสอบผลต้องใช้วิธีเก็บข้อมูลชุดเดียวกับที่ใช้ตอนเก็บสภาพปัจจุบันในขั้นที่ 2 เท่านั้น ทั้งวิธีวัด จำนวนตัวอย่าง และเงื่อนไขการเก็บ เพื่อให้ตัวเลขก่อน-หลังเทียบกันได้อย่างเป็นธรรม สไลด์ในขั้นนี้ควรมีกราฟเปรียบเทียบค่าก่อนปรับปรุง ค่าหลังปรับปรุง และเส้นเป้าหมายที่ตั้งไว้ในขั้นที่ 2 อยู่ในภาพเดียวกัน เพื่อให้เห็นชัดว่าผลลัพธ์ไปถึงเป้าหรือไม่ และควรมีกราฟแนวโน้มต่อเนื่องหลายสัปดาห์หลังดำเนินมาตรการ ไม่ใช่จุดข้อมูลจุดเดียว เพื่อยืนยันว่าผลลัพธ์ที่ดีขึ้นนั้นคงที่จริง ไม่ใช่ความบังเอิญของช่วงเวลาที่วัด
ข้อผิดพลาดที่พบบ่อยคือเปลี่ยนเงื่อนไขการวัดระหว่างก่อนและหลังโดยไม่รู้ตัว เช่น ข้อมูลก่อนปรับปรุงเก็บจากทุกกะรวมกัน แต่ข้อมูลหลังปรับปรุงเก็บเฉพาะกะที่ทีมงานที่เก่งที่สุดทำงานอยู่ ทำให้ตัวเลขที่ดีขึ้นไม่ได้สะท้อนผลของมาตรการอย่างแท้จริง อีกข้อคือวัดผลเพียงครั้งเดียวทันทีหลังดำเนินมาตรการเสร็จแล้วประกาศความสำเร็จ โดยไม่ติดตามต่อว่าผลลัพธ์นั้นคงอยู่ได้จริงในสัปดาห์ถัดไปหรือไม่ ซึ่งเป็นช่องโหว่ที่เชื่อมโยงโดยตรงกับปัญหาผลลัพธ์ถอยกลับหลังที่จะกล่าวถึงในขั้นที่ 7
| ตัวชี้วัด | ก่อนปรับปรุง | เป้าหมาย | หลังปรับปรุง (เฉลี่ย 6 สัปดาห์) |
|---|---|---|---|
| เวลาเปลี่ยนรุ่นเฉลี่ย | 48.3 นาที | 25.0 นาที | 22.6 นาที |
| ค่าสูงสุดของเวลาเปลี่ยนรุ่น | 71 นาที | ไม่เกิน 30 นาที | 28 นาที |
| สัดส่วนเวลาเสียกับการค้นหาอุปกรณ์ | 34% | ต่ำกว่า 10% | 6% |
| จำนวนครั้งที่เปลี่ยนรุ่นเกิน 40 นาที ต่อเดือน | 9 ครั้ง | 0 ครั้ง | 0 ครั้ง |
ขั้นที่ 7: จัดมาตรฐานและป้องกันการเกิดซ้ำ (Standardize and Prevent Recurrence)
ขั้นนี้คือขั้นที่ถูกมองข้ามบ่อยที่สุด ทั้งที่เป็นขั้นที่ตัดสินว่าผลลัพธ์จะอยู่ได้ถาวรหรือถอยกลับไปเหมือนเดิม คำว่า "จัดมาตรฐาน" ในที่นี้หมายถึงการนำมาตรการที่ยืนยันผลแล้วในขั้นที่ 6 ไปฝังไว้ในระบบงานประจำวัน ไม่ใช่ปล่อยให้อยู่แค่ในความจำของทีมที่ทำโครงการ สไลด์ในขั้นนี้ควรแสดงรายการเอกสารที่ต้องปรับปรุงทั้งหมด เช่น Standard Operating Procedure ที่เกี่ยวข้อง แผ่นOPL (One-Point Lesson)สำหรับสอนพนักงานทุกกะให้เข้าใจตรงกัน checklist ตรวจสภาพประจำวัน และแผนอบรมที่ครอบคลุมพนักงานทุกกะไม่ใช่แค่กะที่ร่วมทดลองมาตรการ พร้อมทั้งกลไกตรวจสอบว่ามาตรฐานใหม่ถูกปฏิบัติตามจริงในระยะยาว เช่น เพิ่มหัวข้อนี้เข้าไปในรอบตรวจสภาพเครื่องจักรประจำสัปดาห์
ข้อผิดพลาดที่ร้ายแรงที่สุดของขั้นนี้ และเป็นสาเหตุอันดับต้น ๆ ที่ทำให้ผลงาน Kaizen ถอยกลับหลังไปเป็นสภาพเดิมภายใน 3 เดือนหลังปิดโครงการ คือทีมพอใจกับตัวเลขผลลัพธ์ในขั้นที่ 6 แล้วถือว่างานจบ โดยไม่อัปเดตเอกสารมาตรฐานหรืออบรมพนักงานกะอื่นให้ทำตามวิธีใหม่ เมื่อเวลาผ่านไป พนักงานที่ไม่รู้ที่มาก็ค่อย ๆ กลับไปทำตามความเคยชินเดิม จุดจอดเครื่องมือที่เคยจัดไว้ก็ถูกใช้เก็บของอื่นแทน ปัญหาเดิมจึงกลับมาโดยที่ไม่มีใครรู้ตัวว่าเพราะขาดการจัดมาตรฐาน ไม่ใช่เพราะมาตรการที่เลือกมาไม่ดี
| สิ่งที่ต้องจัดมาตรฐาน | รูปแบบเอกสาร/กลไก | ผู้รับผิดชอบปรับปรุง |
|---|---|---|
| ขั้นตอนเปลี่ยนรุ่นใหม่ | Standard Operating Procedure ฉบับปรับปรุง | วิศวกรกระบวนการ |
| วิธีใช้และตำแหน่งจุดจอดเครื่องมือ | OPL ติดหน้าเครื่อง | หัวหน้าทีม |
| การตรวจสภาพจุดจอดเครื่องมือ | เพิ่มหัวข้อใน Checklist ตรวจประจำสัปดาห์ | หัวหน้ากะ |
| ความเข้าใจของพนักงานทุกกะ | อบรมและประเมินความเข้าใจหลังอบรม | หัวหน้าทีม + ET |
ขั้นที่ 8: สรุปและแผนต่อไป (Reflect and Next Steps)
ขั้นสุดท้ายของ QC Story คือการสะท้อนกลับอย่างตรงไปตรงมาว่ากระบวนการทำงานของทีมเป็นอย่างไร ไม่ใช่แค่ผลลัพธ์ตัวเลขที่ได้ สไลด์ปิดท้ายควรแยกเป็นสองส่วนชัดเจน ส่วนแรกคือสิ่งที่ทีมทำได้ดีและควรทำต่อในโครงการถัดไป เช่น การไปดูหน้างานจริงก่อนวิเคราะห์สาเหตุช่วยประหยัดเวลาได้มาก ส่วนที่สองคือสิ่งที่ควรปรับปรุงในกระบวนการทำงานของทีมเอง เช่น ประเมินเวลาขั้นวิเคราะห์สาเหตุต่ำเกินไป หรือสื่อสารกับกะอื่นช้าเกินไปจนกระทบขั้นจัดมาตรฐาน ปิดท้ายด้วยหัวข้อที่ทีมจะทำต่อ อาจเป็นปัญหาที่เหลืออยู่จากเรื่องเดียวกัน หรือหัวข้อลำดับถัดไปจากตารางจัดลำดับความสำคัญที่ทำไว้ในขั้นที่ 1
ข้อผิดพลาดที่พบบ่อยคือเขียนส่วนสะท้อนกลับแบบเป็นพิธี เช่น "ทำงานได้ดี ไม่มีปัญหา ทุกคนร่วมมือกันดี" ซึ่งไม่ให้ข้อมูลอะไรที่เป็นประโยชน์กับทีมอื่นที่จะอ่านสไลด์นี้ต่อ การสะท้อนกลับที่มีค่าต้องกล้าพูดถึงสิ่งที่ไม่เป็นไปตามแผนด้วย เพราะนั่นคือความรู้ที่ป้องกันทีมอื่นไม่ให้เจอปัญหาเดิมซ้ำ อีกข้อผิดพลาดคือจบเรื่องโดยไม่ระบุหัวข้อถัดไปเลย ทำให้กิจกรรม Kaizen ของทีมหยุดชะงักหลังจบเรื่องหนึ่ง ทั้งที่ QC Story ควรเป็นวงจรต่อเนื่องที่แต่ละเรื่องจบแล้วส่งต่อพลังไปสู่หัวข้อถัดไปเสมอ
| หมวด | รายละเอียด |
|---|---|
| สิ่งที่ทำได้ดี | ไปดูสภาพหน้างานจริงก่อนวิเคราะห์สาเหตุ ทำให้พบรากสาเหตุได้เร็ว |
| สิ่งที่ต้องปรับปรุง | ประเมินเวลาขั้นวิเคราะห์สาเหตุต่ำไป 2 สัปดาห์ ควรกันเวลาสำรองมากกว่านี้ |
| ปัญหาที่ยังเหลืออยู่ | เวลาเปลี่ยนรุ่นในเครื่องรุ่นเก่าอีก 2 เครื่องยังไม่ได้ปรับปรุง |
| หัวข้อถัดไป | ลดของเสียจุดปิดผนึกซอง ซึ่งได้คะแนนอันดับสองจากตารางเลือกหัวข้อในขั้นที่ 1 |
ทำไมโครงสร้าง QC Story ถึงสำคัญ
โครงเรื่องมาตรฐาน 8 ขั้นตอนไม่ได้มีไว้เพื่อความสวยงามของสไลด์เท่านั้น แต่ทำหน้าที่สำคัญ 3 ด้าน ด้านแรกคือทำให้ตรวจสอบและทบทวนงานได้ง่าย หัวหน้างานหรือผู้บริหารที่อ่านสไลด์สามารถไล่ตามลำดับตรรกะได้ทันทีว่าจุดใดยังอ่อน เช่น เห็นทันทีว่าขั้นที่ 4 มีข้อมูลบางเบาเกินไปเมื่อเทียบกับขั้นอื่น โดยไม่ต้องเรียกทีมมาอธิบายเพิ่ม ด้านที่สองคือใช้ถ่ายทอดความรู้ข้ามทีมได้อย่างมีประสิทธิภาพ เพราะทุกทีมในโรงงานใช้โครงเรื่องเดียวกัน พนักงานใหม่ที่ไม่เคยเห็นโครงการนี้มาก่อนก็อ่านและเรียนรู้วิธีคิดได้จากสไลด์เพียงชุดเดียว ด้านที่สามคือ QC Story เป็นรูปแบบมาตรฐานที่ใช้ประกอบการพิจารณาTPM Award และ PM Prize ของ JIPMซึ่งคณะกรรมการตัดสินจะพิจารณาจากความสมบูรณ์ของโครงเรื่องทั้ง 8 ขั้นเป็นหลัก ไม่ใช่แค่ตัวเลขผลลัพธ์สุดท้ายเพียงอย่างเดียว
| ผู้ใช้งาน | ประโยชน์ที่ได้จากโครงเรื่องมาตรฐาน |
|---|---|
| ผู้บริหาร/หัวหน้างาน | ทบทวนและอนุมัติผลงานได้เร็ว เพราะรู้ล่วงหน้าว่าข้อมูลอยู่ตรงไหน |
| ทีมงานที่นำเสนอ | มีโครงร่างชัดเจนตั้งแต่ต้น ไม่ต้องออกแบบวิธีเล่าเรื่องใหม่ทุกครั้ง |
| ทีมอื่นในโรงงาน | นำโครงเรื่องไปเป็นต้นแบบเรียนรู้วิธีคิดและวิธีแก้ปัญหา |
| คณะกรรมการตัดสินรางวัล | ประเมินเปรียบเทียบผลงานหลายทีมด้วยเกณฑ์เดียวกันได้อย่างเป็นธรรม |
ตัวอย่างเดินเต็ม 1 เรื่อง: ลดเวลาเปลี่ยนรุ่น จากทฤษฎีสู่โครงเรื่องที่ใช้นำเสนอจริง
เพื่อให้เห็นภาพรวมทั้ง 8 ขั้นตอนในโครงเรื่องเดียวกัน หัวข้อนี้สรุปการลดเวลาสูญเสียจากการเปลี่ยนรุ่นที่ใช้อธิบายแต่ละขั้นตอนไปแล้วข้างต้น ให้อยู่ในตารางเดียวที่ไล่จากขั้นที่ 1 ถึงขั้นที่ 8 ตารางลักษณะนี้เหมาะสำหรับตรวจทานความครบถ้วนของโครงเรื่องก่อนขึ้นสไลด์จริง หรือใช้เป็นแบบร่างคร่าว ๆ (storyboard) ก่อนลงรายละเอียดในแต่ละหน้า ทีมที่ต้องการลดเวลาเปลี่ยนรุ่นอย่างจริงจังในระยะยาว ควรศึกษาเพิ่มเติมที่SMED หรือ Quick Changeoverซึ่งเป็นเทคนิคเฉพาะทางที่แยกงานเปลี่ยนรุ่นเป็นงานที่ทำได้ขณะเครื่องเดินกับงานที่ต้องหยุดเครื่องเท่านั้น และมักใช้ร่วมกับ QC Story เพื่อยกระดับผลลัพธ์ให้ดีขึ้นอีกในรอบถัดไป
| ขั้นตอน | สรุปเนื้อหาของเรื่องนี้ |
|---|---|
| 1. เลือกหัวข้อ | เปลี่ยนรุ่นเครื่องบรรจุสาย 2 ได้คะแนนสูงสุดจากตารางจัดลำดับ 4 หัวข้อ มูลค่าความสูญเสีย 1,240,000 บาท/ปี |
| 2. สภาพปัจจุบันและเป้าหมาย | เฉลี่ย 48.3 นาที/ครั้ง ตั้งเป้า 25 นาที/ครั้ง ภายใน 12 สัปดาห์ |
| 3. วางแผนกิจกรรม | 12 สัปดาห์ 5 กิจกรรมหลัก มีผู้รับผิดชอบรายบุคคลชัดเจน |
| 4. วิเคราะห์สาเหตุ | Why-Why 4 ชั้น พบรากสาเหตุคือไม่มีมาตรฐานจุดเก็บเครื่องมือประจำเครื่อง |
| 5. มาตรการ | ทำ Shadow Board ประจำเครื่องและ Standard Work ใหม่ ทดลองที่ 1 เครื่องก่อน |
| 6. ตรวจสอบผล | ลดเหลือ 22.6 นาทีเฉลี่ยจาก 6 สัปดาห์ ต่ำกว่าเป้าหมายที่ตั้งไว้ |
| 7. จัดมาตรฐาน | ปรับ SOP ทำ OPL เพิ่มใน Checklist ตรวจประจำสัปดาห์ อบรมครบทุกกะ |
| 8. สรุปและแผนต่อไป | ต่อยอดไปหัวข้อลดของเสียจุดปิดผนึกซองซึ่งได้คะแนนอันดับ 2 |
ข้อสังเกตสำคัญจากตัวอย่างนี้คือทุกตัวเลขในขั้นที่ 6 ย้อนกลับไปตอบเป้าหมายที่ตั้งไว้ในขั้นที่ 2 ได้ครบทุกตัว และรากสาเหตุในขั้นที่ 4 เชื่อมตรงกับมาตรการในขั้นที่ 5 แบบไม่มีช่องว่าง นี่คือลักษณะของ QC Story ที่มีตรรกะครบวงจร ต่างจากรายงานทั่วไปที่มักมีบางขั้นตอนขาดหายหรือเชื่อมกันไม่สนิท
รูปแบบการนำเสนอ: โปสเตอร์ QC Story 1 หน้า
แม้กิจกรรม QC Circle หรือ Kaizen จะนำเสนอด้วยสไลด์ในห้องประชุมได้ แต่รูปแบบดั้งเดิมและรูปแบบที่ใช้ในงานประกวดหรือติดบอร์ดหน้างานคือโปสเตอร์ขนาด A3 หรือ A2 เพียง 1 แผ่น การบีบทั้ง 8 ขั้นตอนให้อยู่ในหน้าเดียวมีประโยชน์แฝงที่สำคัญ คือบังคับให้ทีมต้องกลั่นกรองเฉพาะข้อมูลที่จำเป็นที่สุดของแต่ละขั้นจริง ๆ ต่างจากการทำสไลด์ที่มักขยายจำนวนหน้าไปเรื่อย ๆ จนล้นข้อมูล เมื่อพื้นที่มีจำกัด ทีมจึงต้องตัดสินใจว่ากราฟหรือข้อมูลใดสำคัญพอที่จะใส่ลงไป โปสเตอร์มาตรฐานมักจัดเป็นคอลัมน์เรียงจากซ้ายไปขวา ไล่ตามลำดับขั้นที่ 1 ถึงขั้นที่ 8 โดยไม่ควรสลับลำดับเพื่อความสวยงาม เพราะจะทำให้คนอ่านตามตรรกะไม่ได้ ส่วนสัดส่วนพื้นที่ของแต่ละขั้นควรสอดคล้องกับน้ำหนักเนื้อหา ไม่ใช่แบ่งเท่ากันทุกขั้น
| ขั้นตอน | สัดส่วนพื้นที่บนโปสเตอร์ (โดยประมาณ) |
|---|---|
| 1. เลือกหัวข้อ | 5-8% |
| 2. สภาพปัจจุบันและเป้าหมาย | 15-18% |
| 3. วางแผนกิจกรรม | 5-8% |
| 4. วิเคราะห์สาเหตุ | 20-25% |
| 5. มาตรการ | 12-15% |
| 6. ตรวจสอบผล | 15-18% |
| 7. จัดมาตรฐาน | 8-10% |
| 8. สรุปและแผนต่อไป | 5-8% |
สังเกตว่าขั้นที่ 4 วิเคราะห์สาเหตุ และขั้นที่ 2 สภาพปัจจุบันและเป้าหมาย ควรได้พื้นที่มากที่สุด เพราะเป็นขั้นที่ต้องแสดงหลักฐานข้อมูลละเอียดที่สุด ขณะที่ขั้นที่ 1, 3 และ 8 ใช้พื้นที่น้อยกว่าได้เพราะเป็นข้อมูลสรุปสั้น ๆ ไม่ต้องแสดงหลักฐานประกอบมาก
8 กับดักที่พบบ่อยใน QC Story
แม้แนวคิดของ QC Story จะดูตรงไปตรงมา แต่ในทางปฏิบัติมีกับดักที่พบซ้ำ ๆ อยู่เสมอ ทั้งจากทีมที่เพิ่งเริ่มทำและทีมที่ทำมานานจนเผลอทำตามความเคยชิน ตารางด้านล่างรวบรวม 8 กับดักที่พบบ่อยที่สุด พร้อมผลกระทบและวิธีป้องกัน
| กับดัก | ผลกระทบ | วิธีป้องกัน |
|---|---|---|
| ข้ามข้อมูลสภาพปัจจุบันแล้วกระโดดไปมาตรการเลย | ไม่มีหลักฐานว่าปัญหาใหญ่แค่ไหน มาตรการที่เลือกอาจไม่คุ้มค่า | เก็บข้อมูลอย่างน้อย 2-4 สัปดาห์ก่อนคิดมาตรการใด ๆ |
| ตั้งเป้าหมายไม่เป็นตัวเลข | ตรวจสอบผลในขั้นที่ 6 ไม่ได้ว่าสำเร็จจริงหรือไม่ | ทุกเป้าหมายต้องมีค่าเริ่มต้น ค่าที่ต้องการ หน่วยวัด และกรอบเวลา |
| วิเคราะห์สาเหตุแค่พูดซ้ำอาการ ไม่ได้หาสาเหตุจริง | มาตรการที่ตามมาแก้ไม่ตรงจุด ผลลัพธ์ไม่ยั่งยืน | ไล่ Why-Why จนกว่าจะเจอสิ่งที่ลงมือแก้ได้จริง ไม่ใช่คำอธิบายซ้ำปัญหา |
| ลืมขั้นจัดมาตรฐาน ทำให้ผลลัพธ์ถอยกลับหลังภายใน 3 เดือน | ผลงานที่เคยดีขึ้นค่อย ๆ กลับไปเหมือนเดิมโดยไม่มีใครรู้สาเหตุ | ระบุเอกสารและผู้รับผิดชอบจัดมาตรฐานไว้ตั้งแต่ในแผนกิจกรรมขั้นที่ 3 |
| ก็อปโครงเรื่องเก่ามาใช้ทั้งที่ความซับซ้อนของปัญหาต่างกัน | ใช้เครื่องมือวิเคราะห์ไม่เหมาะกับปัญหา เช่น ใช้ Why-Why กับปัญหาเรื้อรังที่ต้องใช้ P-M Analysis | ประเมินความซับซ้อนของปัญหาก่อนเลือกเครื่องมือ ไม่ใช่เลือกตามที่เคยใช้ครั้งก่อน |
| เลือกหัวข้อเพราะรู้คำตอบอยู่ก่อนแล้ว | ขั้นวิเคราะห์สาเหตุกลายเป็นพิธีกรรมที่ไม่ได้ใช้หาสาเหตุจริง | ให้ทีมอื่นช่วยตรวจสอบว่าหัวข้อผ่านการเปรียบเทียบตัวเลือกอย่างเป็นกลางจริงหรือไม่ |
| บันทึกข้อมูลย้อนหลังจากความจำหลังงานเสร็จ | ตัวเลขและเหตุการณ์ที่เล่าคลาดเคลื่อนจากความเป็นจริงระหว่างทาง | บันทึกข้อมูล รูปถ่าย และผลประชุมย่อยไว้ทุกสัปดาห์ระหว่างทำโครงการ ไม่ใช่เขียนตอนจบ |
| อัดข้อมูลแน่นเกินไปจนอ่านไม่ไหลลื่น | ผู้ฟังจับประเด็นหลักไม่ได้ แม้ทีมจะทำงานมาดีเพียงใด | เลือกเฉพาะกราฟและตัวเลขที่จำเป็นต่อการเล่าเรื่องในแต่ละขั้นเท่านั้น |
QC Story กับกิจกรรมกลุ่มย่อยและปัญหาที่ซับซ้อน
QC Story มีรากฐานมาจากวัฒนธรรมกิจกรรมกลุ่มย่อยซ้อนชั้นของ TPMที่แบ่งพนักงานหน้างานเป็นกลุ่มเล็ก ๆ ตามพื้นที่รับผิดชอบ แต่ละกลุ่มหมุนเวียนกันเลือกหัวข้อ Kaizen และนำเสนอผลงานให้กลุ่มอื่นฟังเป็นประจำ โครงเรื่อง 8 ขั้นตอนจึงถูกออกแบบมาให้เขียนและนำเสนอโดยสมาชิกกลุ่มย่อยเองได้ ไม่ต้องพึ่งนักเขียนมืออาชีพหรือฝ่ายประชาสัมพันธ์ ยิ่งกลุ่มย่อยฝึกเขียน QC Story บ่อยเท่าไร ทักษะการคิดอย่างเป็นระบบของสมาชิกก็ยิ่งพัฒนาเร็วเท่านั้น เพราะทุกครั้งที่ต้องเรียบเรียงงานของตัวเองให้เข้าโครงเรื่องนี้ สมาชิกจะถูกบังคับให้ทบทวนตรรกะของตัวเองไปในตัว
สำหรับปัญหาที่ซับซ้อนกว่าระดับที่กลุ่มย่อยทั่วไปรับมือไหว เช่น ความล้มเหลวที่มีหลายสาเหตุประกอบกันพร้อมกันจนเกิดอุบัติเหตุหรือความเสียหายรุนแรง โครงเรื่อง QC Story ในขั้นที่ 4 ยังใช้ได้เหมือนเดิม เพียงแต่เปลี่ยนเครื่องมือวิเคราะห์จาก Why-Why เชิงเส้นไปเป็นFTA (Fault Tree Analysis)ที่แสดงทุกเส้นทางของสาเหตุที่นำไปสู่ผลลัพธ์เดียวกันในแผนภาพเดียว ตารางด้านล่างช่วยให้ทีมเลือกเครื่องมือวิเคราะห์สาเหตุให้เหมาะกับระดับความซับซ้อนของปัญหาในขั้นที่ 4 ได้เร็วขึ้น
| ลักษณะปัญหา | เครื่องมือที่เหมาะสม |
|---|---|
| สาเหตุตรงไปตรงมา เหตุการณ์เดี่ยว | Why-Why Analysis |
| ข้อมูลสถิติจากหลายเหตุการณ์ซ้ำ | QC 7 Tools ร่วมกับผังก้างปลาแบบ 4M |
| ปัญหาเรื้อรัง แก้แล้วแก้อีกไม่หายสักที | P-M Analysis |
| หลายสาเหตุประกอบกันจนเกิดความเสียหายรุนแรงหรือกระทบความปลอดภัย | FTA (Fault Tree Analysis) |
สรุป
QC Story ไม่ใช่เอกสารที่ทำเพิ่มหลังงานเสร็จเพื่อให้ผู้บริหารเซ็นอนุมัติเท่านั้น แต่เป็นวินัยที่ทำให้ทีม Kaizen และ QC Circle คิดอย่างเป็นระบบตั้งแต่วันแรกที่เลือกหัวข้อ เพราะรู้ว่าสุดท้ายต้องเล่าเรื่องทั้งหมดให้คนอื่นเข้าใจได้ใน 8 ขั้นตอนที่ตรวจสอบย้อนกลับได้ทุกจุด โรงงานที่ฝึกให้ทุกกลุ่มย่อยเขียน QC Story อย่างมีคุณภาพสม่ำเสมอ มักพบว่าคุณภาพของการวิเคราะห์สาเหตุและความยั่งยืนของผลลัพธ์ดีขึ้นตามไปด้วย เพราะโครงเรื่องเองก็ทำหน้าที่เป็นเช็กลิสต์ที่คอยเตือนว่ายังขาดขั้นตอนใดอยู่ หากโรงงานของท่านต้องการวางระบบ Kaizen และ QC Story ให้เป็นมาตรฐานเดียวกันทั้งองค์กร ทีมที่ปรึกษาของเราพร้อมช่วยออกแบบกระบวนการและฝึกอบรมทีมงานให้เขียนโครงเรื่องได้อย่างมีคุณภาพ ดูรายละเอียดบริการที่ปรึกษา TPM