Designing Systems That Work · ภาค 1 — เห็นระบบที่กำลังสร้างผลลัพธ์อยู่จริง

บทที่ 1

ปัญหาที่เกิดซ้ำมักไม่ใช่ปัญหาของคนคนเดียว

SYSTEMS · OUTCOMES · LEGACY · LOCAL OPTIMISATION

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

ทุกฝ่ายมีคำอธิบายของตน และทุกคำอธิบายอาจจริงในส่วนของมัน

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

แต่สองสัปดาห์ต่อมา เรื่องเดิมกลับมาอีกครั้งกับลูกค้าอีกราย

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

ความพยายามของคน อาจกำลังซ่อนความล้มเหลวของระบบ

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

แต่สิ่งที่เห็นอาจเป็นเพียงจุดสุดท้ายของปัญหา

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

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

ผลลัพธ์ที่เกิดซ้ำจึงไม่ใช่เพียงข่าวร้าย มันคือร่องรอยของระบบ (systems)

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

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

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

ระบบส่วนใหญ่ไม่ได้ถูกออกแบบอย่างตั้งใจ

หลายขั้นตอนในองค์กรเริ่มต้นจากเหตุผลที่ดี

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

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

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

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

ระบบจึงไม่ได้ถูกออกแบบโดยคนคนเดียว แต่ค่อย ๆ ก่อตัวจากการตัดสินใจเล็ก ๆ ที่สะสมกัน

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

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

เมื่อทุกฝ่ายทำถูกในมุมของตน แต่ผลรวมกลับแย่ลง

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

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

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

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

นี่คือกับดักของการปรับปรุงเฉพาะจุด (local optimisation)

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

หากไม่มีจุดหมายร่วม แต่ละฝ่ายจะสร้างจุดหมายของตนเองขึ้นมาแทนเสมอ

EXHIBIT 1.1 · Local Optimisation
ที่มา: ผลรวมของส่วนที่ดีที่สุด ไม่เท่ากับส่วนรวมที่ดีที่สุด

รูปที่ 4 — สี่การตัดสินใจที่ถูกในระดับฝ่าย

รูปที่ 4 — สี่การตัดสินใจที่ถูกในระดับฝ่าย

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

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

บทบาทของผู้ออกแบบระบบ คือเลือกปัญหาที่ควรแก้ก่อน

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

คำตอบไม่ใช่การเปิดโครงการปรับปรุงทุกเรื่องพร้อมกัน

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

เครื่องมือมีบทบาทสำคัญ แต่เป็นบทบาทที่ตามมา

Value Stream Mapping ช่วยให้เราเห็นการไหล A3 ช่วยให้ทีมเห็นปัญหาเดียวกัน Lean ช่วยลดความสูญเปล่า Six Sigma ช่วยเข้าใจความผันแปร และ Theory of Constraints ช่วยให้เราเห็นจุดที่กำหนดผลลัพธ์รวมของระบบ แต่ไม่มีเครื่องมือใดตอบแทนคำถามแรกได้ว่า ปัญหาใดคุ้มค่าที่สุดที่องค์กรจะเรียนรู้และแก้ไขในตอนนี้

เครื่องมือช่วยให้เราทำสิ่งต่าง ๆ ได้ดีขึ้น

การมองระบบช่วยให้เราเลือกสิ่งที่ควรทำก่อน

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

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

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