ช่วงหนึ่งผมเริ่มรู้สึกว่า Management Meeting ของเรามีข้อมูลเยอะขึ้นเรื่อย ๆ แต่กลับมีเวลาสำหรับตัดสินใจน้อยลง ทุกคนเข้ามาพร้อมรายการงานของตัวเอง แล้วใช้เวลาส่วนใหญ่เล่าว่าทำอะไรไปแล้ว งานไหนเสร็จไปกี่เปอร์เซ็นต์ งานไหนกำลังรอใคร และมี task อะไรต้องตามต่อ เมื่อครบทุกคน เวลาก็แทบหมดพอดี เรารับรู้สถานะมากขึ้น แต่คำถามสำคัญอย่างงานไหนควรเร่ง งานไหนควรหยุด เรากำลังใช้คนถูกที่หรือไม่ ความเสี่ยงอะไรเริ่มใหญ่เกินกว่าทีมจะรับเอง หรือทิศทางของทั้ง portfolio ควรเปลี่ยนอย่างไร กลับถูกเลื่อนไปประชุมครั้งหน้าเสมอ
ผมไม่ได้คิดว่ารายละเอียดของ task ไม่สำคัญ ตรงกันข้าม รายละเอียดเหล่านั้นสำคัญมากจนไม่ควรรอให้ถึง Management Meeting แล้วค่อยมีคนเล่า มันควรอยู่ใน action board, project status, evidence, decision log หรือ operating memory ที่คนเกี่ยวข้องเปิดดูได้ก่อนเข้าห้อง ถ้าทุกครั้งที่อยากรู้สถานะเรายังต้องเรียกคนมาเล่า แปลว่าปัญหาอาจไม่ได้อยู่ที่การประชุมไม่พอ แต่อยู่ที่ระบบงานยังตอบสถานะตัวเองไม่ได้
เมื่อห้อง Management ต้องรับหน้าที่เป็นทั้งที่เก็บสถานะ ที่ตามงาน ที่แก้ blocker รายวัน และที่ตัดสินใจระดับบริษัท ทุกเรื่องจึงแย่งเวลาอยู่บนโต๊ะเดียวกัน Task ที่เสียงดังที่สุดหรือมีคนเล่ายาวที่สุดมักได้เวลาไป ส่วนเรื่องที่ยังไม่เกิดเหตุ แต่กำลังสะสมความเสี่ยง เช่น capacity ที่ตึงขึ้น margin ที่เริ่มไม่สมเหตุผล dependency ที่ไม่มี owner หรือระบบที่พึ่งคนคนเดียวมากเกินไป กลับไม่ได้ถูกคุย เพราะมันยังไม่มี task สีแดงให้เห็น
ต้นทุนของห้องแบบนี้ไม่ได้มีแค่เวลาประชุมยาวขึ้น แต่คือการใช้คนผิดระดับ คนที่ควรมองความเชื่อมโยงระหว่างธุรกิจ ทีม เงิน เทคโนโลยี และความเสี่ยง ถูกดึงลงมาทำหน้าที่เป็นผู้ตามสถานะ ขณะที่คนทำงานก็เรียนรู้ว่าถ้าอยากให้งานขยับ ต้องรอเอาเรื่องเข้าห้อง Management เมื่อเกิดซ้ำบ่อย ๆ Management จะกลายเป็นคอขวดโดยไม่ตั้งใจ และทีมจะเก่งขึ้นในเรื่องการรายงาน แต่ไม่ได้เก่งขึ้นในเรื่องการตัดสินใจภายในขอบเขตของตัวเอง
แยกห้องตามงานออกจากห้องตัดสินใจ
ผมเริ่มมองว่าการประชุมสองแบบนี้ควรตอบคนละคำถาม
| Operating Review | Management Meeting |
|---|---|
| ตอนนี้งานอยู่ตรงไหน | ภาพรวมธุรกิจและ portfolio กำลังไปทางไหน |
| blocker คืออะไร | เรื่องใดต้องเลือก เร่ง หยุด หรือยอมรับ trade-off |
| ใครเป็น owner และ next action คืออะไร | capacity ควรถูกย้ายไปอยู่ตรงไหน |
| หลักฐานของสถานะอยู่ที่ไหน | risk ใดใหญ่เกินกว่าทีมจะรับเอง |
| งานจะเสร็จเมื่อไร | ระบบการทำงานส่วนใดต้องถูกเปลี่ยน |
Operating Review ยังจำเป็น แต่ควรเกิดในจังหวะที่ถี่กว่าและอยู่ใกล้คนทำงานกว่า ทีมควรใช้มันเพื่อทำให้ status, owner, blocker, next action และ evidence ชัด ส่วน Management Meeting ควรเริ่มจากข้อมูลที่ผ่านการกลั่นแล้ว และหยิบ task ขึ้นมาคุยเฉพาะเมื่อ task นั้นสะท้อนสิ่งที่ใหญ่กว่า เช่น กระทบรายได้ กระทบลูกค้า ใช้ capacity มากกว่าที่คาด มี production หรือ compliance risk ต้องการการตัดสินใจข้ามทีม หรือมี trade-off ที่ทีมใดทีมหนึ่งตัดสินเองไม่ได้
เส้นแบ่งนี้ไม่ได้ตายตัว Task เล็กหนึ่งรายการอาจสมควรเข้าห้อง Management ถ้ามันเปิดให้เห็นความเสี่ยงระดับระบบ ขณะเดียวกันโครงการใหญ่ก็อาจไม่ต้องใช้เวลาในห้องเลย หากสถานะเป็นไปตามแผน ขอบเขตชัด และทีมมีอำนาจตัดสินใจต่อได้ สิ่งที่กำหนดวาระจึงไม่ควรเป็นขนาดของ task แต่เป็นผลกระทบและ decision ที่ต้องการ
อย่าเอา Activity มาใช้แทน Management Information
อีกอย่างที่ผมเริ่มระวังคือข้อมูลจำนวนมากดูเหมือนมีความคืบหน้า แต่ยังไม่ช่วยให้ Management ตัดสินใจ เช่น จำนวน task ที่ปิด จำนวนครั้งที่ประชุม จำนวนเอกสารที่สร้าง หรือจำนวนชั่วโมงที่ทีมใช้ ตัวเลขเหล่านี้อาจมีประโยชน์ในระดับ operation แต่ถ้าไม่เชื่อมกับผลลัพธ์ เราจะยังไม่รู้ว่างานดีขึ้นจริงไหม ลูกค้ารับสิ่งที่ส่งไปหรือยัง ความเสี่ยงลดลงหรือไม่ เงินขยับหรือยัง และ capacity ที่ใช้ไปคุ้มกับผลลัพธ์หรือเปล่า
ข้อมูลก่อนเข้าห้อง Management จึงควรถูกแปลงจาก activity ให้เป็นเรื่องที่ตัดสินใจได้ อย่างน้อยควรตอบว่า outcome เปลี่ยนอะไร มี evidence อะไรยืนยัน มีความเสี่ยงหรือ trade-off ตรงไหน เรื่องใดทีมตัดสินเองได้แล้ว และเรื่องใดต้องการ decision จาก Management ถ้าข้อมูลยังตอบไม่ได้ คนเตรียมข้อมูลควรกลับไปกลั่นเพิ่ม ไม่ใช่นำ task list ทั้งชุดมาให้คนในห้องช่วยกันค้นหาว่าประเด็นสำคัญซ่อนอยู่ตรงไหน
AI ช่วยลดต้นทุนส่วนนี้ได้มาก มันช่วยอ่าน status จากหลายแหล่ง ช่วยจับ source ที่ขัดกัน ช่วยแยก activity ออกจาก outcome และช่วยร่าง management pack ได้ แต่ AI ไม่ควรเป็นคนเลือกทิศทางแทน Management หน้าที่ของมันคือทำให้ข้อมูลพร้อมพอที่คนในห้องจะใช้ judgment กับเรื่องที่สำคัญจริง ไม่ใช่สร้าง slide เพิ่มอีกชุดที่ทุกคนต้องนั่งอ่านพร้อมกัน
ห้องประชุมควรจบด้วยการเลือก ไม่ใช่จบด้วยการรับทราบ
ถ้าห้อง Management ทำงานถูกระดับ ผลลัพธ์หลังประชุมไม่ควรเป็นเพียง “ทุกคนรับทราบสถานะแล้ว” แต่ควรมีการเลือกบางอย่างเกิดขึ้น เช่น สามเรื่องที่องค์กรจะให้ความสำคัญในรอบถัดไป งานที่ต้องหยุดหรือเลื่อนเพื่อคืน capacity ความเสี่ยงที่ Management ยอมรับหรือไม่ยอมรับ decision ที่ทีมรออยู่ owner ที่รับผิดชอบผลลัพธ์ และหลักฐานที่จะใช้ทบทวนว่า decision นั้นให้ผลตามที่ต้องการหรือไม่
คำถามที่ผมคิดว่ามีประโยชน์กับห้องมากกว่าการถามว่า “แต่ละทีมมีอะไรอัปเดตบ้าง” คือ:
- ถ้าเราเร่งได้เพียงสามเรื่องในรอบนี้ เราจะเลือกอะไร
- แล้วเราจะหยุดหรือเลื่อนอะไรเพื่อคืน capacity ให้สามเรื่องนั้น
- เรื่องใดดูเหมือนเดินอยู่ แต่ยังไม่เปลี่ยนผลลัพธ์ทางธุรกิจ
- ความเสี่ยงอะไรยังไม่มีใครถืออย่างแท้จริง
- มี decision อะไรที่ทีมทำต่อไม่ได้จนกว่าห้องนี้จะเลือก
- ก่อนประชุมรอบหน้า เราต้องเห็น evidence อะไรจึงจะรู้ว่าการตัดสินใจครั้งนี้ได้ผล
คำถามเหล่านี้อาจทำให้ห้องประชุมไม่สบายเท่าการอ่าน status เพราะมันบังคับให้เราเลือก และทุกการเลือกย่อมมีสิ่งที่ไม่ได้เลือก แต่ผมคิดว่านี่คือหน้าที่ของ Management การรายงานให้ครบช่วยให้เรารู้ว่าเกิดอะไรขึ้น ส่วนการจัดลำดับ ยอมรับ trade-off และจัดสรรทรัพยากร คือสิ่งที่ทำให้องค์กรขยับไปในทิศทางที่เลือก
บทความก่อนหน้านี้ผมเคยตั้งคำถามว่า เมื่อไหร่เราควรเรียกใครสักคนว่า Management และได้คำตอบสำหรับตัวเองว่า คนคนนั้นควรทำให้คุณภาพของการตัดสินใจร่วมกันดีขึ้น แต่เมื่อคิดต่อ ผมพบว่าต่อให้มีคนที่พร้อม contribute อยู่ในห้อง หากเราออกแบบห้องให้ใช้เวลาส่วนใหญ่กับการอ่าน task คนเหล่านั้นก็อาจไม่มีพื้นที่พอจะทำหน้าที่ Management จริง ๆ
ดังนั้นการยกระดับ Management ไม่ได้เริ่มจากการเปลี่ยนคนอย่างเดียว มันอาจเริ่มจากการเปลี่ยนคำถาม เปลี่ยนข้อมูลที่อนุญาตให้ขึ้นโต๊ะ และเปลี่ยนผลลัพธ์ที่เราคาดหวังจากการประชุม
รายละเอียดของงานยังต้องมี และต้องครบกว่าเดิม เพียงแต่มันควรอยู่ในระบบที่ทีมใช้ตามงานได้ทุกวัน ไม่ใช่กินเวลาส่วนใหญ่ของห้องที่มีไว้ตัดสินใจ
ถ้า Management Meeting ยังใช้เวลาส่วนใหญ่ตาม Task เราอาจไม่ได้ขาดการประชุม แต่กำลังใช้คนผิดระดับ และกำลังใช้ห้องตัดสินใจเป็น dashboard ที่แพงเกินไป