ทุกระบบต้องมีจุดหมาย ขอบเขต และการไหลที่ชัดเจน

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

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

ทุกฝ่ายทำงานหนัก และทุกเป้าหมายก็ดูถูกต้อง

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

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

จุดหมายที่ดี ไม่ใช่คำสวย ๆ แต่ต้องช่วยให้คนตัดสินใจได้

จุดหมาย (purpose) คือคำตอบร่วมของคำถามว่า ระบบนี้มีไว้ทำอะไรให้ใคร และอะไรคือผลลัพธ์ที่องค์กรต้องรักษาไว้ แม้ในวันที่งานไม่เป็นไปตามแผน

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

จุดหมายที่ใช้ได้ต้องช่วยให้คนเลือกได้

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

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

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

EXHIBIT 2.1 · จุดหมายในฐานะเกณฑ์ตัดสิน
ที่มา: เกณฑ์ที่ต้องมีก่อนตั้งตัวชี้วัด

รูปที่ 6 — เป้าหมายสามอย่างเดิม ก่อนและหลังมีจุดหมายร่วม

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

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

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

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

ทุกฝ่ายอาจพูดถูกในขอบเขตของตน

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

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

การมองเฉพาะในรั้วของฝ่ายตนมักทำให้เราแก้จุดที่พบปัญหา แต่ไม่เห็นจุดที่สร้างปัญหา

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

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

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

งานไม่ได้มีเพียงขั้นตอน แต่มันมีการไหลที่ต้องถูกออกแบบ

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

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

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

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

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

• งานหรือวัสดุกำลังเคลื่อนจากไหนไปไหน และหยุดอยู่ที่ใด

• เวลาที่ใช้ทำงานจริงต่างจากเวลารอมากเพียงใด

• คนในแต่ละจุดต้องใช้ข้อมูลอะไรจึงเริ่มงานต่อได้

• เมื่อเกิดความผิดปกติ ใครมีสิทธิ์ตัดสินใจ และใครต้องรอ

• งานใดต้องย้อนกลับไปแก้ และอะไรเป็นสาเหตุของการย้อนกลับนั้น

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

EXHIBIT 2.2 · แผนที่ระบบจากการตามรอยงานหนึ่งชิ้น
ที่มา: วิธีพื้นฐานของ IE ก่อนจะไปถึง Value Stream Mapping

รูปที่ 7 — ห้าเรื่องที่ต้องตามรอยไปพร้อมกัน

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

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

จุดหมาย ขอบเขต และการไหล ต้องถูกออกแบบร่วมกัน

สามเรื่องนี้แยกจากกันไม่ได้

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

องค์กรจึงไม่ควรเริ่มโครงการปรับปรุงด้วยคำถามว่า “เครื่องมืออะไรเหมาะกับเรา” แต่ควรเริ่มด้วยคำถามที่เรียบง่ายกว่า

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

คำตอบของสามคำถามนี้อาจไม่แก้ปัญหาทันที แต่จะทำให้ทีมเริ่มแก้ปัญหาเดียวกัน แทนที่ต่างคนต่างเร่งงานในส่วนของตน

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

ก่อนอนุมัติโครงการปรับปรุงใด ๆ ผู้นำควรถามให้ชัดว่า

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

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

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

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