“หัวหน้าอนุมัติแล้ว” อาจยังตอบไม่ได้ว่างานพร้อมดำเนินการหรือไม่ หากข้อความอนุมัติอยู่ในแชท แต่ไฟล์ที่ทีมจะนำไปใช้ถูกแก้หลังจากนั้น คำถามที่ระบบต้องช่วยตอบคือ ใครอนุมัติอะไร ภายใต้เงื่อนไขใด และเป็นเอกสารฉบับเดียวกับที่กำลังใช้อยู่หรือไม่
ลองใช้สถานการณ์จำลองของคำขอจัดซื้อหนึ่งรายการ ผู้ขอแก้สถานที่ส่งหลังผ่านการอนุมัติ ขณะที่ฝ่ายรับงานดาวน์โหลดไฟล์เดิมไปแล้ว กรณีนี้แสดงให้เห็นว่าการย้ายปุ่มอนุมัติมาออนไลน์อย่างเดียวไม่พอ ต้องออกแบบสถานะ บทบาท และฉบับข้อมูลให้ทำงานร่วมกัน
เริ่มจากความหมายของคำว่าอนุมัติ
การตรวจเอกสารครบ การรับทราบ และการอนุมัติให้ดำเนินงานเป็นคนละหน้าที่ หากรวมเป็นปุ่ม “ตกลง” เดียวกัน ทีมจะไม่รู้ว่าต้องรอใครและใครเป็นผู้รับผิดชอบการตัดสินใจ
ผู้ขอยืนยันความต้องการ
ผู้ขอควรเห็นข้อมูลที่ต้องส่งและตรวจความครบถ้วนได้ก่อนเข้าคิว หากขาดสิ่งจำเป็น ให้ระบบบอกช่องที่ต้องแก้ชัดเจน การส่งเรื่องที่ยังไม่ครบไปให้ผู้อนุมัติทำให้คิวแน่นโดยไม่ช่วยให้งานเดินเร็วขึ้น
ผู้ตรวจยืนยันข้อมูลประกอบ
บางงานต้องมีผู้ตรวจรายการหรือเอกสารก่อนผู้อนุมัติตัดสินใจ หน้าที่นี้อาจส่งกลับให้แก้ไขได้ แต่ไม่ได้แปลว่ามีอำนาจอนุมัติแทน ควรแสดงบทบาทให้ชัดทั้งในหน้าจอและประวัติ
ผู้อนุมัติยืนยันการดำเนินการ
ผู้อนุมัติต้องเห็นข้อมูลและฉบับที่กำลังพิจารณา พร้อมเหตุผลประกอบที่จำเป็น หากกติกากำหนดลำดับหรือเงื่อนไขต่างกัน ระบบต้องเลือกเส้นทางตามข้อมูลจริง และให้คนตรวจกรณีที่เข้าเงื่อนไขไม่ได้อย่างชัดเจน
การให้ AI ช่วยสรุปหรือชี้ช่องที่ยังขาดอาจช่วยเตรียมงานได้ แต่การอนุมัติที่มีผลต่อรายการธุรกิจต้องยังเป็นการตัดสินใจของผู้มีอำนาจ ไม่ใช้คำสรุปของระบบแทนการยืนยันนั้น
ทำสถานะให้ทีมรู้ว่าต้องทำอะไรต่อ
| สถานะ | ความหมายที่ทีมควรตกลง |
|---|---|
| ฉบับร่าง | ผู้ขอยังเตรียมข้อมูลและแก้ไขได้ |
| รอตรวจข้อมูล | ผู้ตรวจต้องยืนยันความครบถ้วนก่อนส่งต่อ |
| รออนุมัติ | อยู่กับผู้มีอำนาจตามเส้นทางที่กำหนด |
| ส่งกลับแก้ไข | ผู้ขอต้องแก้ประเด็นที่ระบุแล้วส่งใหม่ |
| อนุมัติแล้ว | ฉบับที่ระบุได้รับการอนุมัติและส่งต่อได้ |
| ยกเลิกหรือไม่อนุมัติ | หยุดเส้นทางนี้พร้อมบันทึกเหตุผล |
“ส่งกลับแก้ไข” ควรต่างจาก “ไม่อนุมัติ” เพราะกรณีแรกยังมีงานที่ต้องทำต่อ ส่วนกรณีหลังอาจจบคำขอนั้นแล้ว ถ้าใช้สถานะเดียวกัน ผู้ขออาจไม่รู้ว่าควรแก้เอกสารหรือเปิดคำขอใหม่
การอนุมัติก็อาจยังไม่ใช่จุดจบของงาน ถ้าฝ่ายปฏิบัติการต้องรับช่วง ควรมีหลักฐานว่ารับเรื่องแล้วและเชื่อมไปยังงานที่ดำเนินการต่อ ไม่ควรทำให้ผู้ขอเข้าใจว่าของถูกสั่งหรือบริการเริ่มแล้วเพียงเพราะผ่านผู้อนุมัติ
เมื่อข้อมูลเปลี่ยน ต้องรู้ว่ายังใช้การอนุมัติเดิมได้หรือไม่
กลับมาที่ตัวอย่างสถานที่ส่งที่เปลี่ยนหลังอนุมัติ ทีมต้องกำหนดว่าการแก้แบบนี้มีผลต่อขอบเขตหรือค่าใช้จ่ายหรือไม่ และต้องผ่านใครอีกครั้ง ระบบไม่ควรตัดสินจากการเป็น “ข้อความสั้น ๆ” โดยไม่ดูผลทางธุรกิจ
แยกข้อมูลที่แก้ได้โดยไม่เปลี่ยนสาระ เช่น หมายเหตุภายในบางประเภท ออกจากข้อมูลที่ทำให้ต้องทบทวน เช่น ผู้รับสินค้า รายการ จำนวน หรือเงื่อนไขสำคัญ กติกานี้ต้องมาจากผู้รับผิดชอบกระบวนการ ไม่ควรให้ผู้พัฒนาสมมติเอง
เมื่อส่งแก้ไข ควรเก็บฉบับก่อนและหลัง พร้อมชี้ว่าจุดใดเปลี่ยน ผู้อนุมัติจะได้ทบทวนสิ่งที่ต่างโดยยังเปิดเอกสารเต็มได้ การอนุมัติควรผูกกับฉบับที่ตรวจจริง และฝ่ายรับงานควรเห็นว่ามีฉบับใหม่รอพิจารณาหรือฉบับเก่าถูกถอนแล้ว
ถ้าผู้อนุมัติสองคนเปิดพร้อมกัน หรือมีคนแก้ระหว่างอีกคนกำลังอ่าน การกดยืนยันต้องตรวจฉบับล่าสุดอีกครั้ง หากข้อมูลเปลี่ยน ควรให้ทบทวนก่อน ไม่บันทึกว่าคนผู้นั้นอนุมัติสิ่งที่ยังไม่เห็น
จัดการวันที่คนไม่อยู่และระบบส่งต่อไม่สำเร็จ
การมอบหมายแทนควรระบุผู้รับผิดชอบ ขอบเขต และช่วงเวลาที่ใช้ รวมถึงบันทึกว่าใครเป็นผู้ตัดสินใจจริง การค้างนานควรนำไปสู่การเตือนหรือการส่งต่อที่กำหนดไว้ ไม่ถือว่าเงียบเท่ากับอนุมัติ
ในหน้ารวมงาน ให้แยกงานรอคนตัดสินใจจากงานที่ติดปัญหาทางระบบ เช่น อนุมัติแล้วแต่ส่งเข้าระบบปลายทางไม่สำเร็จ กรณีหลังไม่ควรบังคับผู้ขอสร้างเรื่องใหม่จนเกิดรายการซ้ำ ต้องมีคนเห็นสาเหตุและดำเนินการต่อกับรายการเดิมได้
ประวัติที่มีประโยชน์ประกอบด้วยผู้กระทำ บทบาท เวลา ฉบับข้อมูล การเปลี่ยนสถานะ และเหตุผลที่เกี่ยวข้อง ควรตรวจจากมุมผู้ขอ ผู้อนุมัติ และผู้รับช่วงว่าแต่ละคนเห็นข้อมูลพอจะทำงาน แต่ไม่เกินสิทธิ์ที่ได้รับ
ก่อนรับระบบ ให้ทดสอบเส้นทางที่มีการส่งกลับ แก้หลังอนุมัติ มอบหมายแทน และส่งต่อผิดพลาดจริง ระบบควรทำให้ตามได้ว่าเรื่องค้างที่ใครและเพราะอะไร รวมถึงยืนยันได้ว่าการตัดสินใจอ้างอิงข้อมูลฉบับใด จึงจะช่วยลดความคลุมเครือที่แชทและไฟล์แยกกันสร้างไว้
ถ้ารายการที่อนุมัติแล้วต้องส่งเข้าระบบเก่า อ่านเรื่อง การเชื่อมระบบเดิมที่ไม่มี API เพื่อเลือกทางส่งต่อที่รองรับจริงและตรวจผลปลายทางได้
ให้ทีมรู้ว่าเอกสารรอใคร โดยไม่ต้องถามวนในแชท
Talvyn Labs ช่วยออกแบบและเชื่อมระบบอนุมัติเอกสารให้เห็นผู้รับผิดชอบ ลำดับอนุมัติ และประวัติการเปลี่ยนแปลง เริ่มจากคำขอหนึ่งประเภทที่ทีมตามงานยาก แล้ววางกติกากรณีแก้ไขเอกสาร ผู้อนุมัติไม่อยู่ และการส่งต่อเข้าระบบเดิมให้ครบ
คุยเรื่องระบบอนุมัติ