งานอาจเคลื่อนที่ไปข้างหน้า แต่ระบบยังล้มเหลวได้ หากข้อมูลมาถึงช้า คนไม่มีสิทธิ์ตัดสินใจ หรือบทเรียนไม่ย้อนกลับไปเปลี่ยนวิธีทำงาน
โรงงานแห่งหนึ่งพบว่าสินค้าบางล็อตมีตำหนิจากวัตถุดิบที่มีคุณสมบัติไม่สม่ำเสมอ พนักงานหน้างานเห็นความผิดปกติตั้งแต่ช่วงแรกของกะ แต่ยังไม่แน่ใจว่าควรหยุดเครื่องหรือไม่ เพราะการหยุดเครื่องต้องขออนุมัติจากหัวหน้างาน
หัวหน้างานกำลังประชุม จึงยังตอบไม่ได้ เมื่อได้รับข้อมูล เขาตัดสินใจให้เดินเครื่องต่อเพื่อรอผลตรวจจากฝ่ายคุณภาพ ผลตรวจมาถึงหลายชั่วโมงต่อมาและยืนยันว่าต้องหยุดเครื่อง
เวลานั้นงานผลิตไปแล้วจำนวนมาก
หลังเหตุการณ์ ทุกฝ่ายต่างทำหน้าที่ของตน พนักงานรายงานปัญหา หัวหน้างานส่งเรื่อง ฝ่ายคุณภาพตรวจสอบ และผู้จัดการอนุมัติการแก้ไข แต่ระบบยังเสียหาย เพราะข้อมูลไปถึงคนที่ต้องใช้ช้าเกินไป และคนที่เห็นปัญหาก่อนกลับไม่มีสิทธิ์ตัดสินใจในเวลาที่มีความหมาย
งานไม่ได้หยุดเพราะคนไม่รับผิดชอบ งานหยุดช้าเพราะการไหลที่มองไม่เห็นของระบบทำงานช้าเกินไป
ข้อมูลที่ถูกต้อง แต่ไปถึงช้า ก็ยังทำให้คนตัดสินใจผิดได้
การไหลของข้อมูล (information flow) คือการเดินทางของข้อมูลที่คนต้องใช้เพื่อเริ่มงาน ตัดสินใจ แก้ความผิดปกติ และส่งต่องานให้ถูกต้อง ข้อมูลนั้นอาจเป็นคำสั่งซื้อ ข้อกำหนดของลูกค้า สถานะวัตถุดิบ แผนผลิต ผลตรวจคุณภาพ หรือสัญญาณว่าเครื่องจักรกำลังมีปัญหา
ข้อมูลที่มีประโยชน์ต้องมีอย่างน้อยสามคุณสมบัติ: ถูกต้อง ทันเวลา และไปถึงคนที่ต้องใช้
หลายองค์กรให้ความสำคัญกับความถูกต้องของข้อมูล แต่ละเลยคำถามเรื่องเวลา รายงานอาจถูกต้องครบถ้วนเมื่อมาถึงผู้จัดการในเช้าวันถัดไป แต่ไม่มีประโยชน์ต่อพนักงานที่ต้องตัดสินใจเมื่อวานตอนบ่าย ข้อมูลอาจถูกบันทึกในระบบอย่างดี แต่ถ้าคนหน้างานเปิดดูไม่ได้ หรือไม่รู้ว่าต้องดูตรงไหน ข้อมูลนั้นก็ยังไม่ช่วยให้การทำงานดีขึ้น
ปัญหาจึงไม่ใช่เพียงว่า “เรามีข้อมูลหรือไม่” แต่คือ “ใครต้องรู้อะไร เมื่อไร และจะรู้ได้อย่างไร”
เมื่อข้อมูลมาช้า คนมักสร้างคำตอบของตนเองขึ้นมาแทน เขาอาจทำตามสิ่งที่เคยทำ อาศัยความจำ ถามคนที่อยู่ใกล้ที่สุด หรือเลือกทางที่ปลอดภัยที่สุดต่อตนเอง การตัดสินใจเหล่านี้อาจพาให้งานเดินต่อได้ในระยะสั้น แต่สร้างความคลาดเคลื่อนให้ระบบมากขึ้นในระยะยาว
องค์กรจึงควรออกแบบข้อมูลจากจุดที่มีการตัดสินใจ ไม่ใช่เริ่มจากรายงานที่ผู้บริหารอยากเห็นเพียงอย่างเดียว หากพนักงานต้องตัดสินใจว่าเครื่องควรหยุดหรือเดินต่อ เขาต้องเห็นสัญญาณใด หากผู้วางแผนต้องตัดสินใจว่าจะเปลี่ยนตารางหรือไม่ เขาต้องรู้ผลกระทบต่อคำสั่งซื้อใด และหากฝ่ายขายรับงานด่วน เขาต้องเห็นกำลังการผลิตจริงของระบบ ไม่ใช่เพียงกำลังการผลิตตามแผน
สิทธิ์ตัดสินใจที่ไม่ชัด ทำให้ทุกเรื่องต้องรอ
แม้ข้อมูลจะมาถึงทันเวลา ระบบก็ยังช้าได้ หากไม่มีใครรู้ว่าใครมีสิทธิ์ตัดสินใจ
สิทธิ์ตัดสินใจ (decision rights) คือการกำหนดให้ชัดว่า ใครมีอำนาจตัดสินใจเรื่องใด ภายใต้เงื่อนไขใด และเมื่อเรื่องเกินขอบเขตนั้น ใครต้องเป็นผู้รับช่วงต่อ
องค์กรจำนวนมากมีคนที่รู้ปัญหาอยู่ใกล้ที่สุด แต่ไม่มีสิทธิ์ตัดสินใจ ขณะเดียวกัน คนที่มีสิทธิ์ตัดสินใจกลับอยู่ไกลจากปัญหาและได้รับข้อมูลช้ากว่า ผลคือเรื่องเล็กต้องไหลขึ้นไปขออนุมัติ เรื่องที่เร่งด่วนต้องรอ และผู้จัดการกลายเป็นคอขวดของระบบโดยไม่ตั้งใจ
การให้สิทธิ์ตัดสินใจหน้างานไม่ได้หมายความว่าทุกคนทำอะไรก็ได้ตามใจ มันหมายถึงการออกแบบขอบเขตที่ชัดเจน เช่น พนักงานสามารถหยุดเครื่องได้ทันทีเมื่อพบความเสี่ยงต่อความปลอดภัยหรือคุณภาพ หัวหน้างานสามารถเปลี่ยนลำดับผลิตได้ภายในเงื่อนไขที่ตกลงไว้ แต่การเปลี่ยนแผนที่กระทบลูกค้าหลายรายต้องยกระดับ (escalation) ให้ผู้รับผิดชอบที่เหมาะสมตัดสินใจ
หลักสำคัญคือ คนที่ใกล้ปัญหาควรตัดสินใจได้มากที่สุดเท่าที่ความเสี่ยงอนุญาต และเรื่องที่ต้องยกระดับควรขึ้นไปถึงคนที่มีอำนาจตัดสินใจโดยไม่สูญเสียเวลาไปกับการส่งต่อที่ไม่จำเป็น
เมื่อสิทธิ์ตัดสินใจชัด คนจะไม่ต้องคอยเดาว่าตนทำได้แค่ไหน หัวหน้าจะไม่ต้องถูกเรียกไปตอบทุกเรื่อง และผู้บริหารจะไม่ต้องใช้เวลาตัดสินใจเรื่องที่ระบบควรจัดการได้เอง
EXHIBIT 3.1 · การกระจายสิทธิ์ตัดสินใจตามความถี่
ที่มา: วิธีลดคิวหน้าจุดอนุมัติ
รูปที่ 11 — ประตูอนุมัติเดียว กับประตูที่เหลือไว้เฉพาะเรื่องใหม่
- เกิดบ่อย ผลกระทบต่ำ — ตั้งเกณฑ์ล่วงหน้า แล้วให้คนหน้างานตัดสินใจได้เอง
- เกิดบ่อย ผลกระทบสูง — ตั้งเกณฑ์ พร้อมกำหนดว่าเกินเท่าไรจึงต้องส่งต่อ
- เกิดน้อย ผลกระทบสูง — เก็บไว้ที่ผู้มีอำนาจ และยอมรับว่าจะใช้เวลานานกว่า
ให้ดูอะไร แถบแดงหายไปเพราะมีเกณฑ์ล่วงหน้า ไม่ใช่เพราะอนุมัติเร็วขึ้น
อ่านผิดบ่อย คิดว่าการกระจายอำนาจคือการลดการควบคุม ทั้งที่มันคือการควบคุมด้วยเกณฑ์แทนด้วยคน
ระบบที่ไม่เรียนรู้ จะสร้างปัญหาเดิมด้วยวิธีที่ซับซ้อนขึ้น
หลังเหตุการณ์ผ่านไป หลายองค์กรทำรายงาน สรุปสาเหตุ และกำชับให้คนระวังมากขึ้น จากนั้นก็เดินหน้าต่อ
แต่หากการเรียนรู้ไม่ได้ย้อนกลับไปเปลี่ยนเงื่อนไขของงาน ปัญหาเดิมก็มีโอกาสกลับมาในรูปแบบใหม่
วงจรป้อนกลับ (feedback) คือการที่ผลจากการทำงานย้อนกลับมาเปลี่ยนวิธีทำงาน กติกา มาตรฐาน หรือการตัดสินใจในรอบถัดไป ระบบที่มี feedback ที่ดีไม่ได้เพียงบอกว่าปัญหาเกิดขึ้นแล้ว แต่ทำให้ข้อมูลจากปัญหากลายเป็นการเปลี่ยนแปลงที่ตรวจสอบได้
ตัวอย่างเช่น หากพบวัตถุดิบผิดสเปก การเรียนรู้ที่ไม่พอคือการคัดแยกของเสียและแจ้งผู้ขาย การเรียนรู้ที่ดีกว่าคือการถามว่า สัญญาณใดควรทำให้เราตรวจพบก่อนวัตถุดิบเข้ากระบวนการ เกณฑ์รับเข้าชัดพอหรือไม่ ใครต้องเห็นผลตรวจ และเมื่อพบความผิดปกติแล้ว ใครมีสิทธิ์กักวัตถุดิบหรือหยุดการใช้ทันที
ความแตกต่างไม่ได้อยู่ที่องค์กรมีการประชุมสรุปบทเรียนหรือไม่ แต่อยู่ที่หลังการประชุม มีอะไรในระบบเปลี่ยนไปจริงหรือไม่
หากปัญหาเดิมเกิดขึ้นซ้ำ ควรมีสิ่งใดสิ่งหนึ่งเปลี่ยนไปเสมอ: ข้อมูลที่คนเห็น มาตรฐานที่คนใช้ จุดที่ระบบเตือน สิทธิ์ที่คนมี หรือเงื่อนไขที่ทำให้ความผิดพลาดเกิดขึ้นได้
EXHIBIT 3.2 · วงจรป้อนกลับชั้นเดียวและสองชั้น
ที่มา: Single-loop และ Double-loop Learning · Chris Argyris
รูปที่ 12 — วงจรที่จบที่การรับทราบ กับวงจรที่ปิดครบ
- ชั้นเดียว — แก้ของที่ผิดชิ้นนั้น แล้วกลับไปทำงานต่อ จำเป็นแต่ไม่พอ
- สองชั้น — เปลี่ยนเงื่อนไขที่ทำให้ของชิ้นนั้นผิดได้ตั้งแต่แรก
- สัญญาณว่าขาด — เรื่องเดิมถูกประชุมหลายครั้ง และทุกครั้งจบด้วยคำว่ารับทราบ
ให้ดูอะไร สิ่งที่ต่างกันคือกล่องที่สาม ไม่ใช่จำนวนการประชุม
อ่านผิดบ่อย วัดการเรียนรู้ด้วยจำนวนรายงาน แทนที่จะวัดด้วยจำนวนมาตรฐานที่เปลี่ยนไป
ผลของสิ่งที่เปลี่ยนวันนี้ อาจปรากฏเมื่อสายเกินจะแก้ทัน
ความยากของการออกแบบระบบคือ ผลของการตัดสินใจไม่ได้ปรากฏทันทีเสมอไป
การลดจุดตรวจอาจทำให้เวลานำดีขึ้นในสัปดาห์นี้ แต่ความเสี่ยงของของเสียอาจปรากฏในเดือนถัดไป การเร่งผลิตเพื่อปิดยอดสิ้นเดือนอาจทำให้ตัวเลขวันนี้ดีขึ้น แต่สร้างงานค้างและความเหนื่อยล้าให้กะถัดไป การรับคำสั่งซื้อด่วนอาจรักษาลูกค้ารายหนึ่งได้ แต่ทำให้ลูกค้าอีกหลายรายได้รับของช้าลงในภายหลัง
เวลาหน่วงระหว่างการกระทำกับผลลัพธ์ (time delay) ทำให้ผู้บริหารเข้าใจความสัมพันธ์ผิดได้ง่าย เรามักให้เครดิตกับสิ่งที่เกิดก่อนผลดีไม่นาน และโทษสิ่งที่อยู่ใกล้ผลเสียที่สุด ทั้งที่สาเหตุจริงอาจเริ่มขึ้นหลายวันหรือหลายสัปดาห์ก่อน
ระบบที่เรียนรู้จึงต้องไม่ดูเพียงผลลัพธ์ปลายทาง แต่ต้องติดตามสัญญาณระหว่างทางด้วย เช่น งานค้างที่เพิ่มขึ้น จำนวนครั้งที่แผนถูกเปลี่ยน เวลารอการอนุมัติ จำนวนเหตุการณ์ที่ต้องยกระดับ หรือความถี่ของการใช้ OT
สัญญาณเหล่านี้อาจยังไม่ใช่ปัญหาในวันนี้ แต่เป็นข้อมูลที่บอกว่าระบบกำลังเดินไปสู่ปัญหาในวันข้างหน้า
สิ่งที่ผู้นำต้องตัดสินใจ
เมื่อระบบทำงานช้าหรือเกิดปัญหาซ้ำ ผู้นำควรถามว่า
-
คนที่ต้องตัดสินใจในแต่ละจุด ได้รับข้อมูลที่ถูกต้องและทันเวลาหรือไม่
-
คนที่เห็นความผิดปกติก่อน มีสิทธิ์ตัดสินใจอะไรได้บ้าง และเรื่องใดที่ต้องยกระดับ
-
หลังปัญหาเกิดขึ้น ข้อมูลจากเหตุการณ์นั้นย้อนกลับไปเปลี่ยนมาตรฐาน กติกา หรือสัญญาณเตือนของระบบแล้วหรือยัง
-
มีผลใดของการตัดสินใจวันนี้ที่จะปรากฏช้ากว่าที่องค์กรกำลังวัดอยู่หรือไม่
งานอาจเคลื่อนผ่านหลายขั้นตอนโดยไม่หยุด แต่หากข้อมูลไหลช้า การตัดสินใจติดขัด และบทเรียนไม่ย้อนกลับไปเปลี่ยนวิธีทำงาน ระบบก็ยังเดินไปสู่ผลลัพธ์เดิมได้เสมอ