ผู้บริหารกลับจากงานสัมมนาแล้วเดินมาบอก HR ว่า “บริษัท X เขาใช้ระบบ HR ตัวนี้กัน ของเราน่าจะเอาบ้าง” สามเดือนถัดมาองค์กรมีระบบใหม่ที่ทีมขายเดโมได้สวยที่สุด — ไม่ใช่ระบบที่ตรงกับงานจริงที่สุด
อีกสิบแปดเดือนถัดมา ระบบนั้นถูกใช้อยู่สองโมดูลจากแปดที่ซื้อ เงินเดือนยังทำใน Excel เหมือนเดิม และทุกคนสรุปว่า “ระบบไม่ดี” ทั้งที่ความจริงคือกระบวนการเลือกไม่มีอยู่จริงตั้งแต่ต้น
บทความนี้ให้กระบวนการเลือกระบบ HRIS ที่ไม่ผูกกับยี่ห้อใด — เช็กลิสต์ความต้องการรายโมดูล ตารางให้คะแนนเปรียบเทียบ และเช็กลิสต์ก่อนเซ็นสัญญาที่กันปัญหาที่แพงที่สุดไว้ล่วงหน้า
กระบวนการเลือก HRIS เอาไปใช้ทำอะไร
มันเปลี่ยนการตัดสินใจซื้อระบบหลักแสนถึงหลักล้านต่อปี จากการเปรียบเทียบเดโมเป็นการเปรียบเทียบกับความต้องการจริงขององค์กรตัวเอง — เดโมทุกเจ้าสวย เพราะเดโมคือฉากที่เขาซ้อมมาแล้วร้อยรอบ คำถามเดียวที่สำคัญคือระบบทำงานของคุณได้ไหม ซึ่งตอบได้ก็ต่อเมื่อคุณเขียนงานของตัวเองออกมาก่อน
และมันกันความผิดพลาดที่แพงที่สุดของโครงการประเภทนี้ — การซื้อตามองค์กรอื่น ระบบที่เหมาะกับบริษัท 5,000 คนที่มีทีม IT ยี่สิบคน มักเป็นภาระของบริษัท 600 คนที่มี IT สามคน
ขั้นตอนการเลือกระบบ HRIS
1. เขียนความต้องการจากปัญหาจริง ไม่ใช่จากโบรชัวร์
เปิดวงคุยกับคนที่ใช้จริง — เจ้าหน้าที่เงินเดือน หัวหน้ากะ พนักงานที่ต้องกดลางาน — แล้วเขียนความต้องการเป็นข้อ ๆ แยกสามระดับ: ต้องมี (ไม่มีคือตกรอบ) ควรมี และมีก็ดี
จบขั้นนี้ คุณจะได้ เอกสารความต้องการที่เป็นของคุณ ไม่ใช่สำเนาฟีเจอร์ลิสต์ของใคร
2. ล็อกขอบเขตเฟสแรกให้เล็ก
ความล้มเหลวส่วนใหญ่มาจากการขึ้นทุกโมดูลพร้อมกัน เฟสแรกที่รอดจริงคือฐานข้อมูลพนักงาน + ลงเวลา + เงินเดือน ให้เดินนิ่งก่อนสามถึงหกเดือน แล้วค่อยต่อโมดูลประเมินผลและสรรหา
จบขั้นนี้ คุณจะได้ แผนเฟสที่แต่ละก้าวเล็กพอจะสำเร็จได้จริง
3. คัดผู้ขายเหลือ 3 ราย แล้วทดสอบด้วยโจทย์ของคุณ ไม่ใช่เดโมของเขา
ส่งสถานการณ์จริงล่วงหน้าให้ทุกเจ้าทำให้ดู — เช่น “คำนวณเงินเดือนพนักงานกะที่มี OT วันหยุด 3 ชั่วโมง + ปรับเงินระหว่างเดือน” ถ้าเจ้าไหนขอเลี่ยงไปโชว์ฟีเจอร์อื่น นั่นคือคำตอบแล้ว
จบขั้นนี้ คุณจะได้ การเปรียบเทียบบนสนามเดียวกันทั้งสามเจ้า
4. ให้คะแนนด้วยตารางที่ตกลงน้ำหนักกันก่อนดูเดโม
กรรมการคือคนใช้จริงบวก IT บวกการเงิน ให้คะแนนแยกกันก่อนเปิดคุย — เหมือนหลักเดียวกับ Interview Scorecard เพราะปัญหาเดียวกัน: คนพูดก่อนลากคะแนนคนอื่น
จบขั้นนี้ คุณจะได้ ผลเลือกที่อธิบายได้ว่าทำไม ไม่ใช่ความประทับใจรวม ๆ
5. คิดต้นทุนรวม 3 ปี ไม่ใช่ราคาปีแรก
ค่าระบบรายปี + ค่าขึ้นระบบ + ค่าย้ายข้อมูล + ค่าเชื่อมต่อระบบอื่น + ค่าอบรม + ค่าใช้จ่ายเมื่อจำนวนพนักงานโต — ราคาปีแรกที่ถูกที่สุดมักไม่ใช่ต้นทุนสามปีที่ถูกที่สุด
จบขั้นนี้ คุณจะได้ ตัวเลขที่การเงินยอมรับและไม่มีเซอร์ไพรส์ปีที่สอง
6. ตรวจเช็กลิสต์ก่อนเซ็นสัญญา — โดยเฉพาะทางออก
สองข้อที่ต้องมีเป็นลายลักษณ์อักษรเสมอ: ข้อมูลเป็นของบริษัทและส่งออกได้ครบในรูปแบบเปิดเมื่อเลิกสัญญา และข้อตกลงประมวลผลข้อมูลส่วนบุคคล (DPA) ที่สอดคล้อง PDPA — ระบบ HR คือที่เก็บข้อมูลส่วนบุคคลก้อนใหญ่ที่สุดที่องค์กรฝากไว้กับคนนอก
จบขั้นนี้ คุณจะได้ สัญญาที่คิดเรื่องวันเลิกใช้ไว้ตั้งแต่วันเซ็น
เช็กลิสต์ความต้องการรายโมดูล (ตัวอย่างข้อ “ต้องมี” ของบริบทองค์กรไทย)
| โมดูล | ข้อที่ต้องทดสอบกับข้อมูลจริงก่อนตัดสิน |
|---|---|
| ฐานข้อมูลพนักงาน | รองรับโครงสร้างองค์กรหลายชั้น เก็บประวัติการเปลี่ยนตำแหน่ง/เงินเดือนย้อนหลัง กำหนดสิทธิ์เห็นข้อมูลรายฟิลด์ได้ (เงินเดือนไม่ใช่ทุกคนควรเห็น) |
| ลงเวลา | รองรับกะหมุนและกะข้ามคืน คำนวณชั่วโมง OT แยกประเภทอัตโนมัติ เชื่อมเครื่องสแกนที่มีอยู่ได้จริง (ทดสอบจริง อย่าเชื่อคำว่า “รองรับ”) |
| เงินเดือน | คำนวณภาษี ประกันสังคม กองทุนสำรองเลี้ยงชีพตามเกณฑ์ไทยและอัปเดตเมื่อกฎเปลี่ยน ออกไฟล์นำส่งธนาคารและหน่วยงานราชการ รองรับปรับเงินระหว่างงวด |
| ลางาน | นโยบายลาตามข้อบังคับของบริษัท (ไม่ใช่บังคับใช้นโยบายสำเร็จรูปของระบบ) คำนวณวันลาตามส่วนของปีแรกอัตโนมัติ อนุมัติผ่านมือถือ |
| ประเมินผล | รองรับรอบประเมินและ Calibration ตามกระบวนการของคุณ เก็บหลักฐาน/ความเห็นได้ ดึงข้อมูลออกมาวิเคราะห์ต่อได้ |
| รายงาน | ผู้ใช้สร้างรายงานเองได้โดยไม่ต้องจ้างผู้ขายทุกครั้ง ส่งออก Excel/CSV ได้ทุกตาราง มีข้อมูลพร้อมสำหรับ HR Dashboard |
ตารางให้คะแนนเปรียบเทียบ (ตัวอย่างกรอกจริง)
| เกณฑ์ | น้ำหนัก | ระบบ A | ระบบ B | ระบบ C |
|---|---|---|---|---|
| ครอบคลุมข้อ “ต้องมี” (ผ่านการทดสอบโจทย์จริง) | 35% | 4 → 1.40 | 5 → 1.75 | 3 → 1.05 |
| ความง่ายสำหรับผู้ใช้ปลายทาง (ให้คนหน้างานลองเอง) | 20% | 3 → 0.60 | 4 → 0.80 | 5 → 1.00 |
| ต้นทุนรวม 3 ปี | 20% | 4 → 0.80 | 3 → 0.60 | 5 → 1.00 |
| บริการหลังการขายในไทย + ความเร็วตอบปัญหาช่วงปิดงวด | 15% | 4 → 0.60 | 4 → 0.60 | 2 → 0.30 |
| ความมั่นคงของผู้ขายและทางออกเมื่อเลิกสัญญา | 10% | 4 → 0.40 | 4 → 0.40 | 3 → 0.30 |
| รวม | 100% | 3.80 | 4.15 | 3.65 |
สังเกตว่าระบบ C ซึ่งใช้ง่ายที่สุดและถูกที่สุด แพ้เพราะตกโจทย์ “ต้องมี” และบริการหลังการขาย — สองเกณฑ์ที่มองไม่เห็นในเดโมแต่คือชีวิตจริงของเดือนที่สิบสอง นี่คือเหตุผลที่น้ำหนักต้องถูกล็อกก่อนดูเดโม
เช็กลิสต์ก่อนเซ็นสัญญา
- ข้อมูลทั้งหมดเป็นของบริษัท ส่งออกได้ครบทุกตารางในรูปแบบเปิด (CSV/Excel) โดยไม่มีค่าใช้จ่ายเพิ่ม เมื่อเลิกสัญญา
- ข้อตกลงประมวลผลข้อมูลส่วนบุคคล (DPA) แนบสัญญา ระบุที่ตั้งเซิร์ฟเวอร์ มาตรการความปลอดภัย และหน้าที่เมื่อเกิดข้อมูลรั่ว
- SLA เป็นตัวเลข — เวลาตอบสนอง เวลากู้ระบบ และค่าปรับเมื่อไม่ถึง โดยเฉพาะช่วงวันปิดงวดเงินเดือน
- ราคาล็อกอย่างน้อย 3 ปี พร้อมสูตรราคาเมื่อพนักงานเพิ่ม — ไม่ใช่ “ค่อยคุยตอนต่อสัญญา”
- แผนขึ้นระบบระบุชื่อคนรับผิดชอบฝั่งผู้ขาย จำนวนวัน และเกณฑ์ตรวจรับรายเฟส
- การทดสอบคู่ขนาน (คำนวณเงินเดือนระบบเก่า–ใหม่พร้อมกัน) อย่างน้อย 2 งวดก่อนตัดระบบเก่า เขียนไว้ในแผนงาน
ตัวอย่างในองค์กรไทยขนาด 500–1,000 คน
บริษัทกระจายสินค้าเวชภัณฑ์แห่งหนึ่ง พนักงาน 580 คน ใช้ Excel ทำเงินเดือนและแฟ้มกระดาษเก็บประวัติมาสิบปี คุณวิชัย (HR Manager) ได้รับอนุมัติงบเลือกระบบ HRIS ครั้งแรกขององค์กร
สิ่งแรกที่เขาทำไม่ใช่นัดเดโม — เขาใช้เวลาสามสัปดาห์นั่งกับเจ้าหน้าที่เงินเดือนสองคน หัวหน้าคลังหนึ่งคน และพนักงานขับรถหนึ่งคน เขียนความต้องการได้ 74 ข้อ แยกเป็นต้องมี 28 ควรมี 31 มีก็ดี 15
ข้อ “ต้องมี” ที่คัดผู้ขายตกไปสองเจ้าตั้งแต่รอบแรกคือข้อเดียวที่ไม่มีในโบรชัวร์ไหน — พนักงานคลังและขนส่ง 340 คนไม่มีอีเมลบริษัท ระบบต้องให้คนกลุ่มนี้ดูสลิปและกดลาผ่านมือถือด้วยเบอร์โทรได้ ไม่ใช่บังคับทุกคนมีอีเมล
สามเจ้าสุดท้ายถูกทดสอบด้วยโจทย์เดียวกันหกข้อ รวมถึงโจทย์เงินเดือนกะข้ามคืนที่มี OT วันหยุด — เจ้าหนึ่งทำไม่ได้ต่อหน้ากรรมการทั้งที่โบรชัวร์เขียนว่ารองรับ
เขาขึ้นระบบสามเฟสตลอดสิบเดือน เฟสแรกแค่ฐานข้อมูล + ลงเวลา + เงินเดือน พร้อมรันคู่ขนานกับ Excel สองงวด — งวดแรกพบผลต่าง 41 รายการ ซึ่งเกือบทั้งหมดคือข้อมูลตั้งต้นผิดที่ยกมาจาก Excel ไม่ใช่ระบบคำนวณผิด นั่นคือเหตุผลที่การรันคู่ขนานอยู่ในสัญญา
สิ่งที่คุณวิชัยบอกทีมตอนปิดโครงการ — เวลาสามสัปดาห์ที่นั่งเขียน 74 ข้อตอนแรก คือสามสัปดาห์ที่คุ้มที่สุดของทั้งสิบเดือน เพราะทุกการตัดสินใจหลังจากนั้นมีเอกสารเดียวเป็นกรรมการ
ข้อผิดพลาดที่เจอบ่อย
1. เริ่มจากเดโม ไม่ใช่จากความต้องการ
ใครเริ่มจากเดโมจะจบด้วยการเปรียบเทียบว่าเจ้าไหนโชว์สวย ไม่ใช่เจ้าไหนทำงานของตัวเองได้ — เอกสารความต้องการต้องเสร็จก่อนนัดผู้ขายรายแรก
2. ตัดสินใจโดยไม่มีคนหน้างานอยู่ในกรรมการ
ระบบที่ผู้บริหารเลือกแต่เจ้าหน้าที่เงินเดือนใช้ไม่คล่อง จะถูกใช้แบบครึ่ง ๆ แล้วกลับไป Excel เงียบ ๆ ภายในปี — คนที่ต้องอยู่กับระบบวันละแปดชั่วโมงต้องมีคะแนนอยู่ในตาราง
3. ขึ้นทุกโมดูลพร้อมกัน
ความล้มเหลวรูปแบบนี้ซ้ำจนทำนายได้ — เฟสแรกให้เล็กและให้ชนะ ระบบที่เดินนิ่งสามเดือนสร้างแรงศรัทธาให้เฟสถัดไปเอง
4. ประหยัดการทดสอบคู่ขนาน
เงินเดือนผิดหนึ่งงวดทำลายความเชื่อถือของทั้งโครงการมากกว่าความล่าช้าหนึ่งเดือนหลายเท่า — สองงวดคู่ขนานคือเบี้ยประกันที่ถูกที่สุดในโครงการ
5. ลืมคิดวันเลิกใช้ตั้งแต่วันซื้อ
สัญญาที่ไม่มีข้อส่งออกข้อมูลและ DPA คือการยกข้อมูลพนักงานทั้งบริษัทไปฝากไว้โดยไม่มีกุญแจของตัวเอง — สองข้อนี้ต่อรองง่ายที่สุดตอนก่อนเซ็น และแพงที่สุดตอนจะย้ายออก
หัวข้อที่เกี่ยวข้อง
- PDPA ข้อมูลพนักงาน — เทมเพลต RoPA + ตารางระยะเวลาเก็บเอกสาร — เหตุผลที่ DPA ต้องอยู่ในสัญญา และ RoPA ต้องอัปเดตวันที่ย้ายระบบ
- ไฟล์ Excel ลงเวลา + คำนวณประกันสังคม + สลิปเงินเดือน — จุดตั้งต้นของหลายองค์กร และตัวเทียบเงาที่ดีที่สุดตอนรันคู่ขนาน
- Dashboard KPI ที่ HR ใช้จริง — 8 เมตริกที่ต้องมี — สิ่งที่โมดูลรายงานต้องเลี้ยงข้อมูลให้ได้
- HRIS (Human Resource Information System) — thaihrpro.com — นิยามและองค์ประกอบพื้นฐาน
- HR Tech Stack — thaihrpro.com — ภาพรวมว่า HRIS ต่อกับเครื่องมืออื่นอย่างไร