โครงการ ERP จะลดเรื่องที่ต้องรอ CEO ได้อย่างไร

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

บทความก่อนหน้าเล่าการทดลองของ Bloom และคณะในโรงทอผ้าอินเดีย ผู้วิจัยพบว่าการปรับวิธีจัดการทำให้เจ้าของมีข้อมูลพอจะมอบการตัดสินใจบางเรื่องให้ผู้จัดการโรงงาน ผมจะใช้แนวคิดนั้นกับกรณีสมมติของบริษัทที่ทำซอฟต์แวร์และให้คำปรึกษา ERP โดยเริ่มช่วงที่ผู้ใช้ทดสอบรับมอบระบบ หรือ UAT ผลของโรงทอผ้ามาจากการทดลองในบริบทของเขา ส่วนตัวเลขด้านล่างใช้แสดงวิธีประเมินในโครงการ ERP บทความก่อนหน้าเรื่องการจัดการในโรงทอผ้าอินเดีย · งานวิจัยของ Bloom และคณะ ส่วน V

เก็บข้อมูลที่คนตัดสินใจต้องใช้

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

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

เขียนให้ชัดว่าใครตัดสินใจเรื่องไหน

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

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

วัดว่าเรื่องถึง CEO ลดลงและงานเดินต่อได้หรือเปล่า

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

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

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

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