ห้องสมุดของ Woodyหนังสือ + ตัวคำนวณ

Designing Systems That Work · ภาค 4 — ทำให้ระบบเรียนรู้และปรับตัวได้

บทที่ 18

การปรับปรุงที่ดีเริ่มจากการเข้าใจปัญหา ไม่ใช่การรีบหาคำตอบ

CAUSE · PDCA · HYPOTHESIS TESTING · ROOT CAUSE · A3

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

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

ทีมเลือกคำตอบที่ดูเป็นไปได้ที่สุด จัดอบรมเพิ่ม และเพิ่มจุดตรวจ

ของเสียลดลงในสัปดาห์ถัดมา ทุกคนจึงสรุปว่าวิธีได้ผล

แต่หนึ่งเดือนต่อมา ปัญหาเดิมกลับมาอีกครั้ง

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

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

เหตุการณ์ไม่ใช่ปัญหา และปัญหาไม่ใช่สาเหตุ

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

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

ส่วนสาเหตุ (cause) คือเงื่อนไขหรือกลไกที่ทำให้ปัญหานั้นเกิดขึ้น

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

เครื่องจักรหยุด จึงเรียกช่างลูกค้าร้องเรียน จึงโทรขอโทษของเสียเพิ่ม จึงตรวจเข้มขึ้นส่งของช้า จึงทำ OT

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

คำถามที่ดีจึงไม่ใช่ “ใครทำผิด” หรือ “ใครจะแก้” ทันที แต่คือ “รูปแบบนี้เกิดขึ้นอย่างไร ภายใต้เงื่อนไขใด และอะไรทำให้มันกลับมาได้อีก”

การไล่หาสาเหตุต้องมีวิธี ไม่ใช่เพียงถามว่า “ทำไม” ซ้ำ ๆ

การถามว่า “ทำไม” ช่วยให้ทีมไม่หยุดอยู่ที่อาการ แต่คำถามเพียงอย่างเดียวไม่รับประกันว่าจะพบสาเหตุที่แท้จริง (root cause)

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

สาเหตุที่นำไปสู่การปรับปรุงได้ ควรมีลักษณะสำคัญสามอย่าง

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

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

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

EXHIBIT 18.1 · Fishbone Diagram
ที่มา: แผนผังก้างปลา · Kaoru Ishikawa

รูปที่ 85 — หกด้านที่ต้องกระจายความเป็นไปได้ก่อนสรุป

รูปที่ 85 — หกด้านที่ต้องกระจายความเป็นไปได้ก่อนสรุป

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

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

PDCA คือวงจรเรียนรู้ ไม่ใช่แบบฟอร์ม

วงจร PDCA (Plan–Do–Check–Act) คือวิธีทำให้การปรับปรุงเป็นการเรียนรู้ต่อเนื่อง แทนที่จะเป็นโครงการที่ทำแล้วจบ

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

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

Check คือการเปรียบเทียบสิ่งที่เกิดขึ้นจริงกับสิ่งที่คาดไว้ ถ้าผลไม่เป็นไปตามคาด ต้องถามว่า สมมติฐานผิด การดำเนินการไม่ครบ หรือมีเงื่อนไขอื่นเข้ามาเกี่ยวข้อง

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

PDCA ไม่ได้มีไว้ทำให้ทุกโครงการต้องมีเอกสารสี่ช่อง แต่มันมีไว้ป้องกันองค์กรจากการเชื่อว่าคำตอบที่เราชอบต้องถูกเสมอ

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

EXHIBIT 18.2 · PDCA
ที่มา: วงจรเรียนรู้ · W. Edwards Deming และ Walter A. Shewhart

รูปที่ 86 — สี่ขั้นของวงจร และขั้นที่ถูกข้ามบ่อยที่สุด

รูปที่ 86 — สี่ขั้นของวงจร และขั้นที่ถูกข้ามบ่อยที่สุด

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

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

A3 ทำให้ปัญหาและความคิดมองเห็นร่วมกัน

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

คุณค่าของ A3 ไม่ได้อยู่ที่กระดาษขนาดใด แต่อยู่ที่การบังคับให้ทีมเรียงลำดับความคิด

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

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

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

EXHIBIT 18.3 · A3
ที่มา: หนึ่งแผ่นที่ทำให้ความคิดมองเห็นได้ · Toyota

รูปที่ 87 — ครึ่งซ้ายคือการทำความเข้าใจ ครึ่งขวาคือการลงมือ

รูปที่ 87 — ครึ่งซ้ายคือการทำความเข้าใจ ครึ่งขวาคือการลงมือ

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

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

การทดลองที่ดี เริ่มจากการกล้ายอมรับว่าเรายังไม่รู้

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

ตัวอย่างเช่น

“เราคาดว่าเวลารอของงานเพิ่มขึ้น เพราะข้อมูลคำสั่งซื้อไม่ครบก่อนปล่อยเข้าผลิต หากกำหนดข้อมูลบังคับให้ครบก่อนรับงาน เวลารอการถามข้อมูลระหว่างผลิตควรลดลง”

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

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

และที่สำคัญ ต้องยอมรับได้ว่าผลอาจไม่เป็นไปตามที่คาด

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

สิ่งที่ผู้นำต้องตัดสินใจ

เมื่อเกิดปัญหาซ้ำ ผู้นำควรถามว่า

การปรับปรุงที่ดีไม่ได้เริ่มจากการรู้คำตอบเร็ว

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