Eligibility Engine กำหนดเงื่อนไขและวงเงินอย่างไร?

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

Eligibility Engine ตอบคำถามใด?

ใน EWA มีสองคำถามที่มักสับสนกัน:

1. พนักงานสร้างค่าจ้างจากงานที่อนุมัติแล้วเท่าใด?
2. ณ เวลาปัจจุบัน บุคคลนั้นมีสิทธิใช้บริการหรือไม่ และรับได้ในขอบเขตใด?

คำถามแรกเป็นหน้าที่ของ Earned Wage Engine ส่วนคำถามที่สองเป็นหน้าที่ของ Eligibility Engine

การแยกสองชั้นช่วยให้ระบบไม่สับสนระหว่าง มูลค่าที่เกิดขึ้นแล้วจากการทำงาน กับ สิทธิในการใช้ฟังก์ชันทางการเงิน

พนักงานอาจมีวันทำงานที่อนุมัติแล้วแต่ยังทำเงื่อนไขโปรไฟล์ไม่ครบ ในทางกลับกัน โปรไฟล์อาจครบแต่ยังไม่มีค่าจ้างที่มีสิทธิเพียงพอ

เงื่อนไขหกกลุ่มที่ควรตรวจสอบ

Eligibility Engine ที่ดีควรจัดเงื่อนไขเป็นกลุ่มที่มีความหมายทางธุรกิจชัดเจน

กลุ่มตรวจสอบ	คำถามที่ต้องตอบ	แหล่งข้อมูล
สถานะพนักงาน	โปรไฟล์ยังใช้งานและอยู่ในขอบเขตที่ใช้ได้หรือไม่?	HRM/ERP
งานและค่าจ้างที่ได้รับ	มีค่าจ้างที่เกิดขึ้นแล้วหรือไม่?	Earned Wage Engine
นโยบายองค์กร	สถานที่ทำงานเปิดใช้นโยบายแล้วหรือไม่?	Policy/configuration
ตัวตนและบัญชี	โปรไฟล์รับเงินได้รับการยืนยันหรือไม่?	Identity/account
วงเงินการใช้งาน	คำขอปัจจุบันอยู่ในขอบเขตที่อนุญาตหรือไม่?	Policy + transaction ledger
สถานะระบบ	มีเงื่อนไขที่ต้องหยุดหรือพักคำขอหรือไม่?	Transaction/monitoring

ทุกเงื่อนไขต้องมี แหล่งข้อมูลและผู้รับผิดชอบที่ชัดเจน

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

วงเงินเป็นผลของนโยบาย ไม่ใช่ค่าจ้าง

ใน EWA “วงเงิน” ไม่ควรถูกเข้าใจว่าเป็นเงินแยกต่างหากที่มอบให้พนักงานล่วงหน้า

Earned Wage Engine จะกำหนดค่าจ้างที่เกิดขึ้นแล้วก่อน

จากนั้น Eligibility Engine สามารถใช้กฎเพื่อ จำกัดขอบเขตที่อนุญาตให้ใช้ แต่ไม่ควรสร้างมูลค่าที่สูงกว่าค่าจ้างที่มีสิทธิ

อธิบายได้ดังนี้:

มูลค่าที่ใช้ได้ ≤ ค่าจ้างที่เกิดขึ้นแล้วและมีสิทธิ

สำหรับบริการเข้าถึงค่าจ้างที่ได้รับแล้วของ Nhan Kiet สูตรพื้นฐานคือ:

ยอดที่รับได้ = (จำนวนวันทำงานที่อนุมัติ × อัตราค่าจ้างรายวัน) − ยอดที่รับแล้วในงวด − เงินสำรองตามข้อกำหนดขององค์กร

จากนั้นจึงประเมินเงื่อนไขการใช้งานอื่น

เหตุใดจึงต้องตรวจสอบอีกครั้งตอนส่งคำขอ?

สถานะ “มีสิทธิ” ที่แสดงในแอปอาจเก่าแล้ว

ระหว่างที่พนักงานเปิดหน้าจอจนถึงกดยืนยัน อาจเกิดเหตุการณ์ต่อไปนี้:

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

ดังนั้น เซิร์ฟเวอร์ต้อง ประเมินเงื่อนไขใหม่เมื่อสร้างคำขอ

หน้าจอควรแสดงข้อมูลเท่านั้น การตัดสินสุดท้ายต้องอาศัยข้อมูลล่าสุดจากเซิร์ฟเวอร์

Eligibility Engine ต่างจาก Earned Wage Engine อย่างไร?

ชั้น	คำถามหลัก	ข้อมูลสำคัญ
Earned Wage Engine	มีค่าจ้างที่เกิดขึ้นแล้วเท่าใด?	งาน อัตรา ยอดที่รับแล้ว เงินสำรอง
Eligibility Engine	บุคคลนี้ใช้บริการได้หรือไม่และในขอบเขตใด?	โปรไฟล์ นโยบาย วงเงิน บัญชี
Payment Orchestration	คำขอที่ถูกต้องจะประมวลผลธุรกรรมอย่างไร?	Transaction ID สถานะ ธนาคาร

การแยกสามชั้นทำให้แต่ละชั้นมีความรับผิดชอบชัดเจน

หากงานเปลี่ยน Earned Wage Engine คำนวณใหม่ หากนโยบายเปลี่ยน Eligibility Engine ประเมินใหม่ หากเครือข่ายธนาคารหมดเวลา Payment Orchestration จะจัดการสถานะธุรกรรม

นโยบายต้องมีเวอร์ชันและวันที่มีผล

ข้อผิดพลาดด้านการออกแบบที่พบบ่อยคือเก็บเพียง “นโยบายปัจจุบัน”

หลายเดือนต่อมา องค์กรอาจอธิบายไม่ได้ว่าทำไมธุรกรรมเก่าได้รับอนุญาต แต่ธุรกรรมคล้ายกันในเวลาอื่นกลับไม่ได้รับอนุญาต

กฎแต่ละชุดควรมี:

• รหัสเวอร์ชัน;
• วันที่และเวลามีผล;
• ขอบเขตการใช้;
• ผู้สร้าง;
• ผู้อนุมัติ;
• เหตุผลที่เปลี่ยน;
• สถานะเปิด/ปิดใช้งาน

เมื่อประเมินคำขอ ระบบควรเก็บร่องรอยของ เวอร์ชันนโยบายที่ใช้

Eligibility Engine ควรหยุดเมื่อใด?

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

ตัวอย่างเช่น:

• สถานะธุรกรรมก่อนหน้าไม่ชัดเจน;
• ข้อมูลงานต้นทางขัดแย้งกัน;
• บัญชีรับเงินไม่ถูกต้อง;
• โปรไฟล์ไม่อยู่ในสถานะใช้งาน;
• ไม่สามารถระบุเวอร์ชันนโยบายที่ใช้;
• ระบบต้นทางไม่ตอบกลับในรูปแบบที่ตรวจสอบได้

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

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

รหัสเหตุผลสำคัญไม่แพ้ผลลัพธ์

Eligibility Engine ไม่ควรคืนเพียง:

• true;
• false;
• ตัวเลขหนึ่งค่า

ควรคืน เหตุผลที่มีโครงสร้าง เช่น:

• ยังไม่มีวันทำงานที่อนุมัติ;
• โปรไฟล์ยังไม่ยืนยัน;
• ลูกค้ายังไม่เปิดใช้ฟังก์ชัน;
• คำขอเกินขอบเขตที่อนุญาต;
• มีธุรกรรมรอดำเนินการ;
• ต้องยืนยันบัญชีอีกครั้ง

รหัสเหตุผลช่วยให้:

• หน้าจออธิบายผลแก่ผู้ใช้;
• ทีมสนับสนุนค้นข้อมูล;
• ฝ่ายปฏิบัติการจำแนกข้อผิดพลาด;
• วัดสถิติ;
• ตรวจสอบการตัดสินใจ

ไม่จำเป็นต้องเปิดเผยรายละเอียดทางเทคนิคที่อ่อนไหว แต่ผู้ใช้ควรรู้ว่าต้องทำอะไรต่อ

องค์กรควรบริหาร Eligibility Engine อย่างไร?

Eligibility Engine ควรถูกมองเป็น นโยบายที่นำไปบังคับใช้ได้ ไม่ใช่เพียงโค้ดส่วนหนึ่ง

กฎสำคัญแต่ละข้อควรมี:

• เจ้าของงาน;
• แหล่งข้อมูล;
• วันที่มีผล;
• เหตุผลที่มีอยู่;
• ขอบเขต;
• วิธีจัดการข้อยกเว้น;
• ประวัติการเปลี่ยนแปลง

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

ทีมปฏิบัติการต้องทราบเหตุผลที่คำขอถูกพัก

ทีมสนับสนุนต้องมีรหัสเหตุผลที่ชัดเจนพอจะอธิบายโดยไม่ต้องเข้าถึงการตั้งค่าทางเทคนิคที่อ่อนไหว

KPI ที่ควรติดตาม

สามารถติดตาม:

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

ไม่ควรปรับ KPI ไปในทิศทาง “อนุญาตให้ทำธุรกรรมได้มากที่สุด” เป้าหมายคือ ตรงเงื่อนไข อธิบายได้ และสม่ำเสมอ

สรุป

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

ผู้เขียน: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

คำปรึกษาบริการเข้าถึงค่าจ้างที่ได้รับแล้วสำหรับองค์กร: Hotline 0937.022.655 · Email info@nhankiet.vn · บริการสำหรับองค์กร