"ปัญหา" คืออะไร? นิยามปัญหาให้ถูกก่อน แล้วค่อยแก้ — กระบวนการคิดเชิงตรรกะหน้างาน

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

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

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

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

ปัญหาคืออะไร: นิยามที่สั้นที่สุดและใช้ได้จริงที่สุด

ถ้าให้เลือกประโยคเดียวที่อยากให้ทุกคนในโรงงานจำได้ ผมจะเลือกประโยคนี้

ปัญหา คือ ช่องว่างระหว่าง "สภาพที่ควรจะเป็น" กับ "สภาพจริงที่เป็นอยู่"

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

ลองเทียบสองประโยคนี้ดู

• "เครื่องอัดรุ่น A มันเสียบ่อย น่ารำคาญมาก" — นี่คือความรู้สึก ไม่มีเกณฑ์ ไม่มีตัวเลข ไม่มีจุดสิ้นสุด แก้เท่าไรก็ไม่มีวันบอกได้ว่าพอ
• "เครื่องอัดรุ่น A ควรหยุดฉุกเฉินไม่เกิน 2 ครั้งต่อเดือนตามที่เคยทำได้ในไตรมาสก่อน แต่สามเดือนหลังหยุด 9, 11 และ 8 ครั้ง ช่องว่างคือประมาณ 7 ครั้งต่อเดือน" — นี่คือปัญหา มีเกณฑ์ มีข้อมูล มีขนาดของช่องว่าง และมีเส้นชัยที่รู้ว่าเมื่อไรถือว่าจบ

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

ทำไมคนถึงข้ามขั้นนี้

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

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

ปัญหามีสองประเภท และวิธีแก้คนละแบบสิ้นเชิง

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

ประเภทที่ 1: ปัญหาแบบเบี่ยงเบนจากมาตรฐาน

คือของเดิมเคยดี แล้ววันหนึ่งแย่ลง เช่น เครื่องเคยเดินได้ 480 ชิ้นต่อชั่วโมงมาสองปี ตอนนี้เหลือ 410 หรืออัตราของเสียเคยอยู่ที่ 0.8% ตอนนี้ขึ้นมา 2.3%

ตรรกะของปัญหาประเภทนี้คือ "มีบางอย่างเปลี่ยนไป" เพราะถ้าไม่มีอะไรเปลี่ยน ผลลัพธ์ก็ควรเหมือนเดิม หน้าที่ของทีมจึงคือการตามหาสิ่งที่เปลี่ยน แล้วดึงกลับสู่สภาพเดิม เครื่องมือที่เหมาะคือการเปรียบเทียบ "ก่อน-หลัง" การไล่ไทม์ไลน์การเปลี่ยนแปลง (เปลี่ยนวัตถุดิบล็อตใหม่ เปลี่ยนคน เปลี่ยนพารามิเตอร์ ซ่อมเปลี่ยนอะไหล่ ปรับแม่พิมพ์) และWhy-Why Analysisที่ไล่ตามหลักการทำงานของเครื่อง

ประเภทที่ 2: ปัญหาแบบตั้งเป้าใหม่

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

ตรรกะประเภทนี้คือ "ไม่มีอะไรเสีย แต่ระบบปัจจุบันมีเพดาน" การไล่หาว่าอะไรเปลี่ยนจะไม่เจออะไรเลย เพราะไม่มีอะไรเปลี่ยน สิ่งที่ต้องทำคือรื้อวิธีทำงานหรือเงื่อนไขเครื่องจักรใหม่ ต้องใช้เครื่องมือแนวออกแบบ เช่น การวิเคราะห์เชิงฟิสิกส์อย่างP-M Analysis การลดเวลาเปลี่ยนรุ่น หรือการทบทวนโครงสร้างของOEEทีละองค์ประกอบว่าเพดานอยู่ตรงไหน

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

"สภาพที่ควรจะเป็น" มาจากไหนได้บ้าง

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

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

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

จับข้อเท็จจริง ไม่ใช่ความเห็น

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

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

หลักสามจริง: ไปที่จริง ดูของจริง ดูสภาพจริง

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

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

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

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

ทำปัญหาให้เป็นตัวเลข: 5W2H และการแบ่งชั้นข้อมูล

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

5W2H สำหรับพรรณนาปัญหาให้ครบมุม

• What — เกิดอะไรขึ้น ระบุอาการให้แคบที่สุด "ผิวเป็นรอยด่างขาววงกลม เส้นผ่านศูนย์กลาง 3-5 มม." ดีกว่า "ผิวไม่สวย"
• Where — เกิดที่ไหน ทั้งในโรงงาน (เครื่องไหน สายไหน) และบนชิ้นงาน (ตำแหน่งใด ฝั่งใด) ตำแหน่งบนชิ้นงานมักบอกกลไกได้ตรงกว่าอย่างอื่น
• When — เกิดเมื่อไร วันไหน เวลาใด ช่วงต้นกะหรือปลายกะ หลังเปลี่ยนรุ่นกี่นาที หลังเดินเครื่องต่อเนื่องกี่ชั่วโมง
• Who — ใครเกี่ยวข้อง ไม่ใช่เพื่อหาคนผิด แต่เพื่อดูว่าอาการผูกกับวิธีทำงานของบางคนหรือไม่ ซึ่งแปลว่ามาตรฐานยังไม่รัดกุมพอ
• Which — รุ่นไหน ล็อตไหน แม่พิมพ์ตัวไหน หัวฉีดหัวใด ยิ่งระบุได้ละเอียดยิ่งบีบขอบเขตได้เร็ว
• How — เกิดในลักษณะใด ค่อย ๆ แย่ลงหรือกระโดดทันที เกิดทุกชิ้นหรือสุ่มเกิด
• How much — ขนาดเท่าไร กี่ชิ้น กี่นาที กี่บาท ตัวเลขนี้จะกลายเป็นตัวจัดลำดับความสำคัญและเป็นตัวตั้งของCost Deployment

การแบ่งชั้นข้อมูล คือเครื่องมือบีบขอบเขตที่ถูกที่สุด

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

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

แยกอาการ ออกจากสาเหตุ ออกจากมาตรการ

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

วิธีจำที่ง่ายที่สุดคือ

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

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

เส้นแบ่งระหว่างสาเหตุที่ดีกับสาเหตุที่แย่

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

ปัญหาเรื้อรัง กับ ปัญหาเป็นครั้งคราว

อีกมิติหนึ่งที่ต้องแยกให้ออกตั้งแต่ต้น เพราะกำหนดทั้งวิธีแก้ ระยะเวลา และความคาดหวังของผู้บริหาร

ปัญหาเป็นครั้งคราว (sporadic) คือเหตุการณ์ที่เด่นชัด เกิดขึ้นแล้วสังเกตได้ทันที มักมีสาเหตุเดียวหรือไม่กี่สาเหตุ เช่น มอเตอร์ไหม้ ชิ้นส่วนหัก สายไฟขาด ของเสียกระโดดขึ้นเป็นสิบเท่าในวันเดียว ลักษณะเด่นคือ "ผิดปกติชัดเจน" และมักแก้ได้เร็วเมื่อเจอสาเหตุ

ปัญหาเรื้อรัง (chronic) คือสิ่งที่อยู่กับโรงงานมานานจนทุกคนชิน ของเสีย 1.5% ทุกเดือนไม่ว่าจะทำอะไร เครื่องหยุดจุกจิกวันละ 6-7 ครั้งครั้งละไม่ถึงนาที ลักษณะเด่นคือ "เล็กแต่ตลอดเวลา" และมักเกิดจากสาเหตุหลายตัวที่ซ้อนกันอยู่ ตัวใดตัวหนึ่งไม่พอทำให้เกิด แต่พอมารวมกันแล้วเกิด

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

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

กระบวนการคิดแปดขั้นแบบ QC Story

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

ให้สังเกตว่าขั้นที่ 1 ถึง 3 ทั้งหมดคือ "การนิยามปัญหา" ล้วน ๆ ยังไม่มีการวิเคราะห์สาเหตุใด ๆ เลย นั่นแปลว่าเกือบครึ่งของกระบวนการมาตรฐานถูกออกแบบมาให้ใช้ไปกับการตั้งโจทย์ แต่ในทางปฏิบัติผมมักเห็นทีมใช้เวลาไปกับสามขั้นแรกไม่ถึง 10% แล้วรีบกระโดดไปขั้นที่ 5

ข้อควรระวังในแต่ละขั้นที่มักถูกมองข้าม

• ขั้นที่ 1 — อย่าเลือกหัวข้อตามอารมณ์หรือตามที่ผู้บริหารเพิ่งบ่น ให้เลือกจากข้อมูล เช่น เรียงลำดับความสูญเสียตามมูลค่าเป็นเงิน แล้วเลือกจากบนสุดที่ทีมมีอำนาจแก้ได้
• ขั้นที่ 2 — ต้องเก็บข้อมูลด้วยวิธีที่จะใช้ได้อีกในขั้นที่ 7 ถ้าวัดคนละวิธีก่อนกับหลัง จะเถียงกันไม่จบว่าดีขึ้นจริงหรือไม่
• ขั้นที่ 3 — เป้าต้องมีเหตุผลรองรับ ไม่ใช่ "ลด 30%" ลอย ๆ ควรบอกได้ว่าตัวเลขนี้มาจากค่าที่เคยทำได้ จากสเปก หรือจากความต้องการธุรกิจข้อใด
• ขั้นที่ 4 — แยกให้ชัดระหว่าง "รายการสาเหตุที่เป็นไปได้" กับ "สาเหตุที่ยืนยันแล้ว" ผังก้างปลาที่เต็มไปด้วยกิ่งแต่ไม่มีการพิสูจน์ คือรายการความเห็นที่วาดสวย เครื่องมืออย่างFTAช่วยจัดตรรกะได้ แต่ก็ยังต้องพิสูจน์อยู่ดี
• ขั้นที่ 5 — ประเมินผลข้างเคียงเสมอ มาตรการที่แก้ปัญหาหนึ่งแล้วสร้างอีกปัญหาหนึ่งพบบ่อยมาก การใช้ FMEA ช่วยคาดการณ์ผลข้างเคียงก่อนลงมือทำได้ดี
• ขั้นที่ 7 — ต้องดูความยั่งยืนด้วย ไม่ใช่ดูแค่สัปดาห์แรกหลังทำ ควรติดตามอย่างน้อยสองถึงสามเดือนก่อนประกาศปิด
• ขั้นที่ 8 — ถ้าไม่ได้แก้เอกสารมาตรฐานและไม่ได้สอนคน ปัญหาจะกลับมาแน่นอนเมื่อคนเปลี่ยน การทำบทเรียนแผ่นเดียวคือวิธีถ่ายทอดที่เร็วและติดตัวคนที่สุด

กับดักที่พบบ่อยที่สุดในการนิยามปัญหา

กับดักที่ 1: สรุปสาเหตุลงที่ตัวคน

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

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

กับดักที่ 2: กระโดดไปมาตรการทันที

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

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

กับดักที่ 3: เป้าหมายกำกวม

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

กับดักที่ 4: ไม่มี baseline

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

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

กับดักที่ 5: ขอบเขตกว้างเกินจะจับ

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

กับดักที่ 6: เชื่อข้อมูลโดยไม่ตรวจวิธีเก็บ

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

สรุป: นิยามให้ถูกก่อน แล้วเครื่องมือจะทำงานให้เอง

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

1. เขียน "สภาพที่ควรจะเป็น" ให้ได้เป็นตัวเลข พร้อมบอกว่าตัวเลขนั้นมาจากแหล่งใด
2. เขียน "สภาพจริง" ให้ได้เป็นตัวเลขที่วัดมาจริง ไม่ใช่ที่จำได้
3. ระบุขนาดของช่องว่างเป็นหน่วยที่คุยกับผู้บริหารได้ ดีที่สุดคือเป็นเงิน
4. ตอบให้ได้ว่าเป็นปัญหาแบบเบี่ยงเบนจากมาตรฐานหรือแบบตั้งเป้าใหม่ และเป็นแบบเรื้อรังหรือครั้งคราว
5. แบ่งชั้นข้อมูลอย่างน้อยสองมิติ เพื่อบีบขอบเขตก่อนวิเคราะห์สาเหตุ
6. ตรวจว่าทุกบรรทัดในเอกสารอยู่ถูกช่อง คืออาการอยู่ช่องอาการ สาเหตุอยู่ช่องสาเหตุ มาตรการอยู่ช่องมาตรการ
7. ยืนยันว่ามี baseline เก็บไว้แล้ว และจะวัดผลด้วยวิธีเดียวกันหลังทำเสร็จ

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

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