คลังสินค้าของลูกค้ากำลังทดสอบ ERP ก่อนเปิดใช้จริง คนหนึ่งเจอว่าปุ่มใช้คำผิด อีกคนเจอว่าระบบยอมให้ส่งของเกินจำนวนในใบสั่งขายที่อนุมัติแล้ว สมมติว่าสองเรื่องนี้เข้าแชตกลุ่มเดียวกัน ทุกคนออกความเห็นได้ แต่ไม่มีใครแน่ใจว่าใครอนุมัติให้แก้ หรือใครสั่งพักการเปิดใช้ได้
ถ้าตกลงกันไว้ก่อนว่าใครตัดสินใจเรื่องไหน คนที่อยู่กับงานจะลงมือได้ทันทีในขอบเขตของตัวเอง และรู้ว่าเมื่อไรต้องส่งต่อ
ระบุคนตัดสินใจเป็นเรื่อง ๆ
ผู้จัดการโครงการช่วยตามให้แต่ละเรื่องเดินหน้า ส่วนคนที่มีอำนาจในเรื่องนั้นเป็นคนตัดสิน ในตัวอย่างนี้ การแก้ข้อความ การยอมรับว่าระบบคุมการส่งของได้ และการขยับวันที่ตกลงกับลูกค้า ใช้สิทธิ์คนละแบบ คุยบทบาทเหล่านี้กับลูกค้าก่อนเริ่มทดสอบรับมอบระบบ หรือ UAT
| เรื่องที่เจอใน UAT | ใครตัดสินใจ | ทีมต้องเตรียมอะไร |
|---|---|---|
| ชื่อปุ่มชวนเข้าใจผิด แต่ไม่กระทบการทำรายการ | หัวหน้าทีมส่งมอบอนุมัติแก้ข้อความได้ในขอบเขตที่ตกลง | ข้อความก่อนและหลังแก้ พร้อมผลทดสอบเฉพาะจุด |
| ระบบส่งของได้เกินจำนวนที่อนุมัติ | เจ้าของกระบวนการคลังฝั่งลูกค้าตัดสินว่ากติกาและวิธีแก้ใช้ได้หรือยัง ส่วนคนคุมการเปิดใช้พักขั้นตอนที่กระทบจนทดสอบผ่าน | บันทึกการทดสอบ ตัวอย่างรายการที่กระทบ วิธีควบคุมที่เสนอ และผลทดสอบซ้ำ |
| งานแก้จะทำให้ต้องเลื่อนวันที่รับปากลูกค้า | ผู้บริหารที่รับผิดชอบโครงการตัดสินใจเรื่องข้อตกลงกับลูกค้าตามอำนาจที่ได้รับ ถ้าเกินอำนาจจึงส่งต่อถึง CEO | ทางเลือก ความเสี่ยง ผลที่คาดว่าจะเกิดกับกำหนดการ และข้อเสนอของทีม |
กรณีส่งของเกิน หัวหน้าทีมส่งมอบเริ่มหาวิธีทำให้เกิดปัญหาซ้ำและเตรียมแนวทางแก้ได้เลย ถ้าไม่อยู่ก็ให้คนที่ตกลงกันไว้รับแทน ส่วนเจ้าของกระบวนการคลังเป็นคนตอบว่ากติกาที่แก้แล้วตรงกับงานจริงหรือยัง ทีมจึงเดินงานต่อได้โดยรู้ว่าใครมีสิทธิ์อนุญาตให้เปิดใช้
แนวคิดนี้มีตัวอย่างนอกงานซอฟต์แวร์ด้วย Bloom และคณะเล่าว่าในการทดลองกับบริษัททอผ้าอินเดีย ข้อมูลการจัดการที่ดีขึ้นช่วยให้เจ้าของมอบการตัดสินใจให้ผู้จัดการโรงงานได้มากขึ้น งานนั้นศึกษาโรงทอผ้า แต่ชวนให้เราถามในงาน ERP ได้ว่า คนที่อยู่ใกล้ปัญหาต้องเห็นหลักฐานอะไรจึงจะตัดสินใจได้ดี บทความ Supaket ว่าด้วยงานวิจัยของ Bloom และคณะ
ลองกับเรื่องที่กำลังรอคำตอบอยู่
หยิบงาน UAT ที่ยังค้างมาเขียนหนึ่งประโยคว่าต้องตัดสินใจอะไร ระบุคนตัดสินใจกับคนรับแทน แล้วเขียนเงื่อนไขส่งต่อที่สังเกตได้จริง เช่น ต้องเปลี่ยนวันที่รับปากลูกค้า จดว่าคนตัดสินใจต้องเห็นหลักฐานอะไรและถ้าเข้าเงื่อนไขจะติดต่อผู้บริหารโครงการทางไหน ลงผลตัดสินไว้ตรงที่คนแก้กับคนทดสอบเปิดดูได้
รอบ UAT ถัดไป เริ่มจับเวลาตอนหลักฐานครบและหยุดเมื่อบันทึกคำตัดสิน เทียบเวลารอของเรื่องที่คล้ายกัน และดูว่าต้องส่งต่อกี่ครั้งจากจำนวนเรื่องที่ต้องตัดสินใจทั้งหมดในแต่ละประเภท เปิดดูงานที่ต้องกลับมาแก้กับคำตัดสินที่ต้องกลับลำเพราะหลุดจุดควบคุมด้วย ถ้าเรื่องถึงผู้บริหารน้อยลงแต่ต้องกลับลำบ่อยขึ้น ให้ย้อนดูว่าคนตัดสินใจได้ข้อมูลพอหรือยัง และขอบเขตที่ให้กว้างไปตรงไหน