ข้อมูลแผนกและหัวหน้างานเปลี่ยนได้ จึงต้องเก็บวันที่มีผลและประวัติ ไม่แก้ชื่อแผนกทับแล้วทำให้รายงานปีก่อนย้ายตาม หากย้ายทีมกลางเดือน ระบบลงเวลาและเงินเดือนอาจต้องใช้นโยบายคนละช่วง
ทะเบียนพนักงานต้องมีมิติของเวลา
ข้อมูลแผนกและหัวหน้างานเปลี่ยนได้ จึงต้องเก็บวันที่มีผลและประวัติ ไม่แก้ชื่อแผนกทับแล้วทำให้รายงานปีก่อนย้ายตาม หากย้ายทีมกลางเดือน ระบบลงเวลาและเงินเดือนอาจต้องใช้นโยบายคนละช่วง
ใช้รหัสพนักงานคงที่ แยกบุคคลออกจากสถานะการจ้าง โดยเฉพาะคนกลับเข้าทำงานใหม่ ต้องตกลงว่าจะมีประวัติการจ้างหลายช่วงอย่างไร ไม่รวมวันเริ่มงานผิด
เริ่มงานหนึ่งคนมีผู้เกี่ยวข้องมากกว่า HR
ทำรายการงานของ HR หัวหน้า IT และผู้ดูแลอุปกรณ์ เช่น ตรวจเอกสาร จัดบัญชีใช้งาน ส่งมอบเครื่อง และอบรม โดยระบุวันครบกำหนดและหลักฐานจบงาน
เมื่อออกจากงาน ให้มีงานคืนทรัพย์สิน เพิกถอนสิทธิ์ และตรวจรายการค้าง การเปลี่ยนสถานะใน HR อย่างเดียวไม่ได้ยืนยันว่าบัญชีระบบอื่นถูกปิดแล้ว
สิทธิ์ข้อมูลควรตอบตามหน้าที่
| สถานการณ์ | สิ่งที่ระบบควรทำ | วิธีตรวจ |
|---|---|---|
| หัวหน้างาน | ดูข้อมูลและคำขอของทีมตามขอบเขต | ไม่เห็นเงินเดือนทั้งบริษัท |
| พนักงาน | ดูและขอแก้ข้อมูลของตน | เปิดข้อมูลผู้อื่นด้วย URL ไม่ได้ |
| HR | แก้ข้อมูลพร้อมวันที่มีผล | มีประวัติผู้แก้และค่าเดิม |
| IT | รับงานจัดการบัญชี | ไม่ต้องเห็นเอกสารบุคคลที่ไม่เกี่ยวข้อง |
ตรวจความครบของงานแทนการนับฟอร์ม
รายงานควรบอกว่าคนเริ่มงานสัปดาห์หน้าค้างอะไร คนย้ายทีมรออนุมัติใคร และคนออกยังมีสิทธิ์ระบบใดค้าง การวัดผลจึงผูกกับงานที่ปิดครบตามกำหนด
กำหนดนโยบายเก็บรักษาและลบข้อมูลร่วมกับผู้รับผิดชอบ ไม่เก็บเอกสารทุกชนิดถาวรเพียงเพราะระบบเก็บได้
เช็กลิสต์ก่อนเริ่มทำระบบ
- โครงสร้างองค์กรและประวัติตำแหน่ง
- รายการงานเริ่ม/ย้าย/ออกพร้อมเจ้าของ
- สิทธิ์ข้อมูลแต่ละบทบาทและระบบปลายทาง
- ข้อมูลที่ต้องส่งเงินเดือนพร้อมวันมีผล
คำถามที่พบบ่อย
ให้พนักงานแก้ข้อมูลตัวเองได้ไหม?
แบ่งข้อมูลแก้เองได้กับข้อมูลต้องตรวจ เช่น การเปลี่ยนช่องทางรับเงินควรมีการตรวจและประวัติอนุมัติที่ชัด
ระบบ HR ต้องเชื่อมทุกระบบทันทีไหม?
เริ่มจากจุดที่ทำข้อมูลซ้ำและมีเจ้าของพร้อม เช่น พนักงานกับลงเวลา แล้วขยายเมื่อมีการตรวจผลเชื่อมที่ชัดเจน
อ่านต่อจากแหล่งข้อมูลโดยตรง
ลิงก์ต่อไปนี้ประกอบประเด็นมาตรฐานและการเชื่อมต่อ ส่วนตัวอย่างขั้นตอนและตัวเลขในบทความใช้เพื่ออธิบายการออกแบบระบบ
ตรวจแหล่งข้อมูล: 11 ตุลาคม 2569 · สิทธิ์ API และข้อกำหนดอาจเปลี่ยนได้ ควรยืนยันก่อนเริ่มโครงการ