แผน ตาราง การจ่ายงาน (dispatching) การเปลี่ยนแผน สต็อก และข้อมูลหน้างาน ต้องถูกออกแบบร่วมกัน ไม่เช่นนั้นทุกคนจะตัดสินใจได้ถูกต้องเฉพาะในส่วนของตน
เช้าวันหนึ่ง ฝ่ายขายแจ้งว่าลูกค้ารายสำคัญต้องการสินค้าเร็วกว่ากำหนด ฝ่ายวางแผนจึงปรับตารางการผลิต (scheduling) ฝ่ายผลิตหยุดงานที่กำลังทำเพื่อเปลี่ยนรุ่น ฝ่ายจัดซื้อเร่งติดตามวัตถุดิบ และคลังสินค้าเตรียมพื้นที่สำหรับงานด่วน
ลูกค้าได้รับสินค้าตามที่ขอ
แต่คำสั่งซื้อเดิมสามรายการถูกเลื่อนออก งานที่ผลิตค้างอยู่ระหว่างเปลี่ยนรุ่นเพิ่มขึ้น วัตถุดิบบางส่วนกลายเป็นของที่ต้องเก็บรอ และทีมหน้างานต้องทำ OT เพื่อให้แผนเดิมกลับมาใกล้เคียงที่สุด
ไม่มีใครตัดสินใจผิดในหน้าที่ของตน ฝ่ายขายรักษาลูกค้า ฝ่ายวางแผนตอบสนองต่อคำสั่งด่วน ฝ่ายผลิตทำตามตารางใหม่ และจัดซื้อช่วยให้วัตถุดิบพร้อม
ปัญหาคือระบบไม่มีหลักร่วมว่า งานด่วนระดับใดควรเปลี่ยนแผน ใครมีสิทธิ์ตัดสินใจ และองค์กรยอมให้ผลกระทบตกกับงานอื่นได้มากเพียงใด
ทุกการตัดสินใจต้องมีเจ้าของ และต้องรู้ขอบเขตของตน
สิทธิ์ตัดสินใจ (decision rights) คือการกำหนดให้ชัดว่า ใครตัดสินใจเรื่องใดได้ ภายใต้เงื่อนไขใด และเมื่อเรื่องเกินขอบเขตนั้น ใครต้องเป็นผู้ตัดสินใจต่อ
หากสิทธิ์ไม่ชัด เรื่องเล็กจะไหลขึ้นไปรอผู้บริหาร ขณะที่เรื่องใหญ่บางเรื่องอาจถูกเปลี่ยนโดยคนที่มองเห็นผลกระทบไม่ครบ คนหน้างานจึงไม่แน่ใจว่าตนควรหยุดงานได้หรือไม่ หัวหน้างานไม่แน่ใจว่าควรเปลี่ยนลำดับงานได้เพียงใด และฝ่ายขายไม่แน่ใจว่าสัญญาอะไรกับลูกค้าได้บ้าง
การกำหนด decision rights ไม่ได้มีไว้รวมอำนาจไว้ที่คนคนเดียว แต่มีไว้กระจายการตัดสินใจให้ใกล้ปัญหาที่สุดเท่าที่ความเสี่ยงอนุญาต
ตัวอย่างเช่น หัวหน้างานอาจมีสิทธิ์สลับลำดับผลิตภายในกะ หากไม่กระทบกำหนดส่งของลูกค้ารายอื่น ฝ่ายขายอาจรับคำสั่งด่วนได้ภายใต้กำลังสำรองที่ตกลงไว้ แต่หากต้องเลื่อนคำสั่งซื้อเดิมหรือทำให้ต้องเปลี่ยนรุ่นเพิ่ม ต้องยกระดับให้ผู้ที่เห็นภาพรวมตัดสินใจ
เมื่อขอบเขตชัด การตอบสนองจะเร็วขึ้นโดยไม่ต้องแลกกับความสับสน และคนในระบบจะไม่ต้องคอยเดาว่าตนทำอะไรได้แค่ไหน
แผน ตาราง และการจ่ายงาน เป็นคนละเรื่อง
การวางแผน (planning) คือการตัดสินใจล่วงหน้าว่าองค์กรจะใช้ทรัพยากรอย่างไร เพื่อให้บรรลุผลลัพธ์ในช่วงเวลาหนึ่ง แผนช่วยให้เห็นความต้องการ กำลังการผลิต วัตถุดิบ และข้อจำกัดที่อาจขัดกัน
แต่แผนไม่ใช่ตาราง และตารางไม่ใช่การจ่ายงาน
ตารางคือการจัดลำดับและกำหนดเวลาของงานให้ละเอียดขึ้น เช่น งานใดควรเริ่มก่อน เครื่องใดควรผลิตอะไร หรือพนักงานคนใดต้องอยู่จุดใดในแต่ละกะ
การจ่ายงานคือการตัดสินใจในเวลาจริงว่า งานใดพร้อมเริ่มแล้ว งานใดควรปล่อยเข้าระบบ และเมื่อเกิดความผิดปกติ งานใดต้องเปลี่ยนลำดับหรือหยุดไว้ก่อน
เมื่อองค์กรปฏิบัติต่อสามเรื่องนี้เหมือนเป็นเรื่องเดียว แผนระยะยาวมักถูกเปลี่ยนเพราะปัญหาเฉพาะหน้ามากเกินไป ขณะเดียวกัน คนหน้างานอาจรอคำสั่งทุกเรื่อง เพราะไม่มีเกณฑ์ช่วยตัดสินใจระหว่างวัน
แผนที่ดีจึงไม่ใช่แผนที่ไม่เปลี่ยนเลย แต่เป็นแผนที่ระบุชัดว่า อะไรควรนิ่ง อะไรเปลี่ยนได้ และใครเปลี่ยนได้
EXHIBIT 15.1 · สามระดับของการทำให้แผนเกิดขึ้นจริง
ที่มา: Planning · Scheduling · Dispatching
รูปที่ 69 — ช่วงเวลาสามระดับ และทิศทางที่แผนถูกแปลงลงมา
- Planning — กำหนดภาพรวมว่าจะทำอะไรในช่วงเวลาใด ใช้ยอดรวมเป็นหลัก
- Scheduling — จัดลำดับและเวลาให้สอดคล้องกับทรัพยากรและข้อจำกัดที่มีจริง
- Dispatching — ปล่อยงานให้เริ่มทำ และต้องดูคิวกับข้อจำกัดก่อนปล่อยเสมอ
ให้ดูอะไร ลูกศรชี้ลงทางเดียว ไม่มีลูกศรจากแถวล่างชี้กลับขึ้นไป
อ่านผิดบ่อย แก้ทุกปัญหาที่แถวล่างสุด เพราะเป็นแถวที่สั่งได้เร็วที่สุด
อย่าปล่อยงานเข้าระบบมากกว่าที่ระบบทำให้เสร็จได้
เมื่อมีงานเข้ามาใหม่ องค์กรมักคิดว่าเริ่มงานเร็วที่สุดย่อมดีที่สุด แต่หากระบบมี WIP สูงอยู่แล้ว การปล่อยงานเพิ่มเข้าไปอาจทำให้งานทุกชิ้นช้าลง
การทำงานแบบผลัก (push) คือการปล่อยงานเข้ากระบวนการตามแผน คำสั่ง หรือเป้าหมายต้นน้ำ แม้ขั้นตอนถัดไปอาจยังไม่พร้อมรับ
การทำงานแบบดึง (pull) คือการให้การเริ่มงานสัมพันธ์กับความสามารถของขั้นตอนถัดไป หรือสัมพันธ์กับสิ่งที่ลูกค้าต้องการจริง เพื่อไม่ให้ WIP สะสมเกินจำเป็น
ไม่มีองค์กรใดทำงานแบบ pull ได้ทั้งหมดในทุกสถานการณ์ และการทำ push ก็ไม่ผิดเสมอไป โดยเฉพาะเมื่อมีข้อจำกัดเรื่องเวลานำหรือความผันแปรของวัตถุดิบ
แต่หลักสำคัญคือ ระบบต้องรู้ว่ากำลังปล่อยงานเข้าเร็วเกินกว่าที่จะทำให้เสร็จหรือไม่ และต้องมีเกณฑ์ชัดเจนว่าเมื่อ WIP ถึงระดับใด ควรหยุดปล่อยงานใหม่เพื่อปกป้องการส่งมอบของงานที่อยู่ในระบบแล้ว
การเริ่มงานมากขึ้นไม่ใช่ความก้าวหน้า หากงานที่เริ่มแล้วไม่มีทางเสร็จตามเวลาที่ลูกค้าต้องการ
EXHIBIT 15.2 · Push และ Pull
ที่มา: สองคำตอบของคำถามเดียวกันว่าอะไรควรเป็นสัญญาณให้เริ่มงาน
รูปที่ 70 — สัญญาณที่ใช้ปล่อยงานเข้าสู่ระบบ
- ข้อดีของ Pull — เมื่อปลายทางรับไม่ได้ สัญญาณจะย้อนกลับมาชัดเจนว่าระบบติดตรงไหน
- ที่พบจริง — องค์กรส่วนใหญ่ผสมกัน คือวางแผนแบบ Push แล้วควบคุมการปล่อยงานแบบ Pull
- คำถามที่สำคัญกว่า — จะควบคุมการปล่อยงานอย่างไรไม่ให้เกินความสามารถของระบบ
ให้ดูอะไร สัญญาณในภาพล่างมาจากปลายทาง ไม่ได้มาจากแผน
อ่านผิดบ่อย คิดว่า Pull คือการมีสต็อกน้อย ทั้งที่มันคือกติกาว่าจะปล่อยงานเมื่อไร
สต็อกไม่ได้เป็นความผิดเสมอไป แต่ต้องมีเหตุผลที่ตรวจสอบได้
สินค้าคงคลังและสต็อก (inventory) มักถูกมองว่าเป็นของเสีย เพราะมันใช้เงินและพื้นที่ แต่ในระบบที่มีความผันแปร สต็อกอาจเป็น Buffer ที่ช่วยป้องกันการขาดวัตถุดิบ การหยุดส่งมอบ หรือความเสี่ยงจากเวลานำที่ยาว
คำถามจึงไม่ใช่ว่า “สต็อกมากหรือน้อยดี” แต่คือ “สต็อกนี้กำลังปกป้องความเสี่ยงอะไร”
สต็อกวัตถุดิบสำคัญอาจจำเป็น เพราะซัพพลายเออร์มีเวลานำยาวและไม่มีแหล่งสำรอง สต็อกสินค้าสำเร็จรูปบางรายการอาจจำเป็น เพราะลูกค้าต้องการส่งมอบเร็วเกินกว่าที่องค์กรจะผลิตตามคำสั่งได้
แต่สต็อกที่เกิดจากการผลิตล็อตใหญ่เพียงเพื่อให้เครื่องจักรไม่ว่าง หรือเกิดจากการที่แผนเปลี่ยนบ่อยจนไม่มีใครมั่นใจว่าจะต้องใช้อะไรเมื่อไร เป็นสต็อกที่อาจกำลังซ่อนปัญหาแทนที่จะแก้ปัญหา
นโยบายสต็อกที่ดีต้องบอกได้ว่า รายการใดควรมีเท่าไร เพื่อป้องกันความเสี่ยงใด ใครเป็นเจ้าของการทบทวน และอะไรคือสัญญาณว่าสต็อกนั้นมากหรือน้อยเกินไป
ทุกคำตอบมีสิ่งที่ต้องแลก และการตัดสินใจที่ดีต้องทำให้สิ่งที่แลกมองเห็นได้
การแลกเปลี่ยน (trade offs) คือสิ่งที่องค์กรต้องยอมเสียหรือรับความเสี่ยงเพิ่มขึ้น เมื่อเลือกทางเลือกหนึ่งเหนืออีกทางเลือกหนึ่ง
การรับงานด่วนอาจรักษาลูกค้ารายหนึ่ง แต่กระทบลูกค้ารายอื่น การลดสต็อกอาจลดเงินทุนจม แต่เพิ่มความเสี่ยงขาดวัตถุดิบ การรักษาแผนให้คงที่อาจช่วยให้ระบบนิ่ง แต่ลดความยืดหยุ่นในการตอบสนอง
ปัญหาไม่ใช่ว่าองค์กรมี trade-offs ปัญหาคือเมื่อ trade-offs ถูกซ่อนไว้
หากฝ่ายขายเห็นเพียงยอดขาย ฝ่ายผลิตเห็นเพียงประสิทธิภาพ และฝ่ายการเงินเห็นเพียงมูลค่าสต็อก แต่ไม่มีใครเห็นผลร่วมกัน การตัดสินใจจะดูดีในรายงานของฝ่ายหนึ่ง และสร้างภาระในอีกฝ่ายหนึ่งเสมอ
ผู้นำจึงต้องทำให้สิ่งที่แลกมองเห็นก่อนตัดสินใจ ไม่ใช่เพื่อหลีกเลี่ยงการเลือก แต่เพื่อเลือกด้วยความเข้าใจว่าใครจะได้รับผลกระทบ องค์กรยอมรับความเสี่ยงใด และผลลัพธ์ใดต้องถูกปกป้องก่อน
แผนจะมีความหมาย เมื่อระบบไม่เปลี่ยนทุกวัน
องค์กรต้องมีช่วงเวลาที่แผนควรนิ่งพอให้ทุกคนเตรียมงานได้ ช่วงเวลานี้เรียกว่า time fence คือเส้นแบ่งที่กำหนดว่า ในแต่ละระยะ อะไรเปลี่ยนได้ง่าย อะไรเปลี่ยนได้แต่ต้องอนุมัติ และอะไรไม่ควรเปลี่ยนแล้ว
ตัวอย่างเช่น แผนของเดือนหน้าอาจยังปรับได้ตามยอดขายใหม่ ตารางของสัปดาห์หน้าอาจปรับได้ภายใต้ข้อจำกัดบางอย่าง แต่ตารางของกะปัจจุบันควรเปลี่ยนเฉพาะเมื่อเกิดเหตุสำคัญจริง
Time fence ไม่ได้ทำให้องค์กรแข็งตัว แต่มันปกป้องคนหน้างานจากการต้องเปลี่ยนทิศทางตามคำขอทุกครั้งที่มีคนรู้สึกเร่งด่วน
เมื่อทุกคนรู้ว่าอะไรเปลี่ยนได้และอะไรไม่ควรเปลี่ยน แผนจะเริ่มเป็นเครื่องมือสร้างความพร้อม ไม่ใช่เพียงเอกสารที่ถูกเขียนไว้เพื่อรอการแก้ไข
EXHIBIT 15.3 · Time Fence
ที่มา: ช่วงเวลาที่แผนเปลี่ยนได้ไม่เท่ากัน
รูปที่ 74 — สามเขตเวลา และกติกาการเปลี่ยนของแต่ละเขต
- เขตใกล้ — เปลี่ยนได้เฉพาะเมื่อมีผู้มีอำนาจอนุมัติและเห็นผลกระทบแล้ว
- เขตกลาง — เปลี่ยนได้เมื่อมีเหตุจำเป็น และต้องรู้ว่ากระทบงานใดบ้าง
- เขตไกล — เปลี่ยนได้ตามการคาดการณ์ เป็นเรื่องปกติของการวางแผน
ให้ดูอะไร เขตที่ใกล้วันนี้ที่สุด คือเขตที่เปลี่ยนได้ยากที่สุด
อ่านผิดบ่อย อ่านว่าเป็นการปฏิเสธลูกค้า ทั้งที่มันคือการทำให้คำสัญญาที่ให้ไปเชื่อถือได้
คนหน้างานต้องเห็นข้อมูลที่ทำให้ตัดสินใจได้
การกระจาย decision rights จะไม่เกิดผล หากคนหน้างานยังไม่มีข้อมูลที่จำเป็น
หัวหน้างานที่ต้องตัดสินใจว่าจะเปลี่ยนลำดับผลิต ควรเห็นงานค้าง กำลังการผลิต วัตถุดิบที่พร้อม และผลกระทบต่อกำหนดส่ง พนักงานที่ต้องหยุดเครื่องเมื่อพบความผิดปกติ ควรเห็นเกณฑ์คุณภาพที่ชัดและรู้ว่าเมื่อใดต้องยกระดับปัญหา
ข้อมูลที่ดีไม่ใช่ข้อมูลทุกอย่างที่ระบบเก็บได้ แต่คือข้อมูลที่เชื่อมกับการตัดสินใจที่คนคนนั้นรับผิดชอบ
เมื่อข้อมูลและสิทธิ์ตัดสินใจถูกออกแบบร่วมกัน คนหน้างานจะไม่ต้องรอคำสั่งทุกเรื่อง และผู้บริหารจะไม่ต้องกลายเป็นผู้ตัดสินใจแทนระบบในเรื่องที่ควรจัดการได้ใกล้จุดเกิด
สิ่งที่ผู้นำต้องตัดสินใจ
เมื่อแผนเปลี่ยนบ่อย งานด่วนเพิ่มขึ้น หรือ WIP สะสม ผู้นำควรถามว่า
-
ใครมีสิทธิ์เปลี่ยนแผนในแต่ละระดับ และเงื่อนไขใดทำให้ต้องยกระดับการตัดสินใจ
-
แผน ตาราง และการจ่ายงานถูกแยกบทบาทกันชัดเจนหรือไม่
-
ระบบกำลังปล่อยงานใหม่เข้าเร็วกว่าความสามารถในการทำให้เสร็จหรือไม่
-
สต็อกแต่ละรายการกำลังปกป้องความเสี่ยงอะไร หรือกำลังซ่อนปัญหาจากแผนและกระบวนการที่ไม่นิ่ง
-
เมื่อเลือกทางหนึ่ง องค์กรเห็น trade-offs ที่เกิดกับลูกค้า คนหน้างาน เวลานำ และต้นทุนรวมครบหรือไม่
-
คนที่อยู่ใกล้ปัญหามีข้อมูลและสิทธิ์พอจะตัดสินใจได้ทันเวลาหรือไม่
การตัดสินใจที่ดีไม่ใช่การตัดสินใจที่ไม่มีผลกระทบ
มันคือการตัดสินใจที่รู้ว่าอะไรต้องแลก ใครต้องรับผล และเหตุใดผลลัพธ์รวมของระบบจึงยังดีกว่าทางเลือกอื่น


