ลูกค้าบ่นว่า "คุณภาพไม่นิ่ง" คุณเข้าใจจริงหรือเปล่า? แปลงคำร้องเรียนให้เป็นปัญหาที่จับต้องได้
ลูกค้าบ่นว่า "คุณภาพไม่นิ่ง" พนักงานบ่นว่า "พลาดบ่อย" คำพูดแบบนี้ฟังดูร้ายแรงแต่ลงมือแก้ไม่ได้สักที บทเรียนนี้สอนวิธีใช้ Problem Statement และ CTQ Tree แปลงคำร้องเรียนคลุมเครือให้กลายเป็นปัญหาที่วัดผลได้และติดตามความคืบหน้าได้จริง
ในนิคมอุตสาหกรรมอมตะซิตี้ จังหวัดระยอง มีโรงงานฉีดพลาสติกขนาดกลางแห่งหนึ่งชื่อ "ศรีระยอง พลาสติก" พนักงานไม่ถึงแปดสิบคน รับผลิตขาแขวนยึดชิ้นส่วนประตูรถยนต์รุ่น RY-220 ส่งให้ลูกค้าญี่ปุ่น "ยามาโตะ เซกิ" เช้าวันจันทร์วันหนึ่ง คุณดา หัวหน้าฝ่ายควบคุมคุณภาพ เปิดอีเมลแล้วเจอจดหมายจากฝ่ายจัดซื้อของยามาโตะ เซกิ น้ำเสียงสุภาพแต่หนักหน่วง ใจความว่า "ขาแขวนที่บริษัทท่านส่งมาระยะหลัง บางครั้งประกอบเข้าไลน์ของเราไม่ได้ คุณภาพดูเหมือนจะไม่นิ่ง กรุณาปรับปรุงโดยเร็ว"
คุณดารีบเรียกหัวหน้างาน ช่างแม่พิมพ์ และพนักงาน QC มาประชุมทันที ในห้องประชุมมีความเห็นกระจัดกระจาย ช่างแม่พิมพ์บอกว่า "อาจเป็นเพราะแม่พิมพ์ใช้มานานแล้วหลวมนิดหน่อย" หัวหน้างานบอกว่า "อาจเป็นเพราะพนักงานใหม่เซ็ตแม่พิมพ์ไม่ตรงตำแหน่ง" พนักงาน QC บอกว่า "ช่วงนี้ความชื้นของวัตถุดิบสูงกว่าปกติ อาจเกี่ยวข้องก็ได้" คุยกันเกือบชั่วโมง สุดท้ายสรุปบนกระดานไวท์บอร์ดได้แค่ประโยคเดียวว่า "ทุกคนต้องเซ็ตแม่พิมพ์และตรวจสอบให้ละเอียดขึ้น" สองสัปดาห์ต่อมา ยามาโตะ เซกิ ส่งจดหมายฉบับที่สองมา คราวนี้แนบใบตีกลับสินค้ามาด้วย
คุณดาถึงได้ตระหนักว่า ปัญหาไม่ได้อยู่ที่ทีมงานพยายามไม่พอ แต่อยู่ที่ตั้งแต่ต้นจนจบ ไม่มีใครแปล "คุณภาพไม่นิ่ง" ให้กลายเป็นปัญหาที่ลงมือแก้ได้จริง — ขาแขวนเบี้ยวไปเท่าไหร่? มิติไหน? ล็อตไหน? ส่งผลกระทบแค่ไหน? นี่คือสิ่งที่ขั้นตอนแรกของ Six Sigma คือ Define (นิยามปัญหา) ต้องทำให้ได้ก่อนจะหยิบเครื่องมือสถิติใดๆ มาใช้เลย
ทำไมเรื่องนี้ถึงสำคัญ
ในยุคที่ Six Sigma ถูกพัฒนาขึ้นที่โมโตโรลา นอกจากบิล สมิธ (Bill Smith) แล้ว ยังมีบุคคลสำคัญอีกคนหนึ่งคือ ดร. ไมเคิล แฮร์รี (Mikel Harry) วิศวกรผู้ร่วมก่อตั้งระเบียบวิธี Six Sigma แฮร์รีสังเกตมานานว่าทำไมโครงการปรับปรุงคุณภาพขององค์กรจำนวนมากถึงล้มเหลว และพบว่าส่วนใหญ่ไม่ได้ตายเพราะเครื่องมือสถิติไม่แม่นยำพอ แต่ตายตั้งแต่จุดเริ่มต้น — ทีมงานเขียนปัญหาไว้คลุมเครือจนไม่มีทางตรวจสอบได้เลยว่า "แก้เสร็จแล้วหรือยัง" แฮร์รีมักย้ำกับลูกศิษย์ว่า Problem Statement ที่เขียนคลุมเครือ ต่อให้ใส่โมเดลสถิติที่ซับซ้อนแค่ไหนตามหลัง ก็จะได้คำตอบที่คลุมเครือเหมือนเดิม นี่คือที่มาของคำพูดในวงการ Six Sigma ที่ว่า "garbage in, garbage out"
ส่วนการแปลงคำร้องเรียนให้เป็นปัญหาที่จับต้องได้ ต้องอาศัยแนวคิดของกูรูด้านคุณภาพอีกท่านหนึ่ง คือ โจเซฟ เอ็ม. จูราน (Joseph M. Juran) นักวิชาการด้านการบริหารคุณภาพชาวอเมริกัน จูรานเสนอไว้ตั้งแต่ทศวรรษ 1950 ว่า ข้อผิดพลาดที่องค์กรมักทำเวลาบริหารคุณภาพ คือให้วิศวกรตัดสินใจเองว่า "คุณภาพที่ดี" คืออะไร โดยไม่ได้ถามลูกค้าจริงๆ ว่าเขาให้ความสำคัญกับอะไร แนวคิดนี้ภายหลังถูกเรียกว่า Voice of the Customer (VOC) เครื่องมือ Six Sigma นำแนวคิดของจูรานมาจัดระบบเป็น CTQ Tree (Critical to Quality) — เริ่มจากคำพูดคลุมเครือของลูกค้า แล้วค่อยๆ แตกลงมาทีละชั้น จนถึงตัวชี้วัดที่จับต้องเป็นตัวเลขได้จริง ขั้นตอน Define ทำได้ดีหรือไม่ แทบจะเป็นตัวชี้ขาดว่าขั้น Measure กับ Analyze ที่ตามมาจะเล็งเป้าถูกจุดหรือเปล่า
เรียนคอร์สบังคับ 7 คอร์สให้จบก่อน (ตอนนี้ 0/7) เพื่อปลดล็อกคอร์สผู้จัดการทั้งหมด
ไปเรียนคอร์สบังคับสมาชิกฟรีทำแบบทดสอบ คุยกับโค้ช AI ฟังบทความสะสมประวัติการเรียนรู้ สมัครรับ 100 พอยต์ทันที
สมัครฟรี