[The Next Gen Navy Ep.19/80] ตัดเสื้อให้พอดีตัว: ปฏิบัติการลด Bias เมื่อ “กพ.ทร.” ลงมือปั้นระบบ HR ด้วย Odoo เพื่อเชื่อมโยงทั้ง ทร.(แนวคิดของ เจ้าของ Post)

---

รายงานตัวประจำวันอังคารที่ 30 ธันวาคม 2568 ส่งท้ายปีด้วยความรู้ที่เข้มข้นครับ เดินทางมาถึง ตอนที่ 19 แล้วนะครับ! ในตอนที่แล้ว (Ep.18) เราได้เปิดโลกแนวคิด “Decentralized” หรือการกระจายอำนาจให้เจ้าของงานเป็นผู้สร้างระบบเอง วันนี้เราจะมาดู “ของจริง” กันครับ

ถ้าถามว่าระบบไหนใน ทร. ที่ซับซ้อนและละเอียดอ่อนที่สุด? คำตอบคงหนีไม่พ้น “ระบบกำลังพล” ครับ เพราะเกี่ยวข้องกับสิทธิประโยชน์ ชีวิต และความก้าวหน้าของพี่น้องทหารทุกนาย ในอดีตระบบเดิม (Legacy System) อย่าง HRMISS ถูกออกแบบเป็นแบบ Bespoke Software (โปรเจกต์ที่มีความเฉพาะเจาะจงสูงมากและไม่ได้ทำมาเพื่อขยายต่อให้คนอื่น) แต่ครั้งนี้เมื่อ มี Open Source อย่างเช่น Odoo หน้าตาจะเปลี่ยนไปอย่างไร? และจะแก้ปัญหา “Data Silo” ได้หรือไม่? และลดการ Bias ต่อการพัฒนาหรือไม่ มาติดตามกันครับ

---

บทที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)

จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง

ตอนที่ 19/80: ลด Bias ในการออกแบบระบบ: ตัวอย่าง เมื่อ “กพ.ทร.” ต้องเป็นคนสร้างระบบ HR ผ่าน Odoo เอง

การที่ กพ.ทร. เป็นผู้พัฒนา Module HR เอง เปรียบเสมือนการให้ “เชฟมือหนึ่ง” เข้าครัวเลือกวัตถุดิบและปรุงอาหารเอง ย่อมรู้รสชาติที่ลูกค้าต้องการดีที่สุด ต่างจากการจ้างคนนอกทำที่มักเกิด Bias (อคติ/ความเข้าใจคลาดเคลื่อน) ดังตัวอย่างนี้ครับ:

1. ทลายกำแพง Bias: เมื่อคนนอกไม่เข้าใจ “บริบททหารเรือ”

• เหตุการณ์ (Bias ของคนนอก): โปรแกรมเมอร์ทั่วไปเข้าใจว่า “การเลื่อนตำแหน่ง” คือการเปลี่ยนชื่อตำแหน่งในระบบ จบ.
• ความจริง (Insight ของ กพ.ทร.): การเลื่อนยศของทหารเรือ มีรายละเอียดมหาศาล ทั้งการนับวันทวีคูณ, การสอบเลื่อนฐานะ, พรรค-เหล่า, และเครื่องราชอิสริยาภรณ์ ซึ่งเงื่อนไขพวกนี้ “คนนอกไม่มีวันเข้าใจลึกซึ้ง”
• ทางออก (Co-Creation): เมื่อเจ้าหน้าที่ กพ.ทร. ใช้เครื่องมือ Odoo Studio ออกแบบเอง เขาสามารถสร้าง Field ข้อมูลพิเศษ เช่น “วันทวีคูณ (ราชการชายแดน)” หรือเงื่อนไข “ต้องผ่านหลักสูตรพรรคนาวิน” ได้เองอย่างแม่นยำ โดยไม่ต้องเสียเวลาอธิบายให้โปรแกรมเมอร์ฟังแล้วทำผิดทำถูก

2. จาก Legacy (HRMISS) สู่ Integrated Data (ข้อมูลที่เชื่อมโยงกัน)

• อดีต (Silo): ระบบ HRMISS เดิม เป็นเหมือน “เกาะร้าง” เก็บประวัติกำลังพลไว้เฉยๆ ไม่เชื่อมกับใคร เวลาจะจ่ายเงินเดือน กง.ทร. ต้องมาขอไฟล์ข้อมูล หรือคีย์ใหม่เอง ทำให้เกิดปัญหา หากไม่มีการแลกเปลี่ยน API กัน
• อนาคต (Odoo Integration):
  • เมื่อ กพ.ทร. อัปเดตคำสั่งเลื่อนยศ น.ต.สมชาย เป็น น.ท.สมชาย ใน Module HR
  • ข้อมูลจะวิ่งไปที่ Module Payroll (ของกรมการเงิน) และ Module Budget (ของ สปช.ทร.) โดยอัตโนมัติ
  • ผลลัพธ์: เงินเดือนปรับขึ้นทันทีในเดือนถัดไป และงบประมาณหมวดเงินเดือนถูกตัดยอดอย่างถูกต้อง ไม่ต้องทำหนังสือแจ้งเวียนให้วุ่นวาย

3. ข้อจำกัดและหลุมพราง (The Constraints)

• กับดักข้อมูลเก่า (Data Cleansing): ข้อมูลในระบบเก่าอาจมีความผิดพลาดสะสมมานาน (Dirty Data) การจะย้ายมาบ้านใหม่ (Odoo) ต้อง “ล้างบ้าน” ให้สะอาดก่อน ไม่งั้นขยะจะตามมาด้วย
• ความคุ้นชิน (Comfort Zone): เจ้าหน้าที่บางท่านอาจคุ้นเคยกับรหัสเมนูแบบเดิม ของระบบเก่า การเปลี่ยนมาใช้ Odoo ที่เป็นหน้าจอสมัยใหม่ ต้องใช้เวลาปรับตัวและการอบรมที่เข้มข้น

4. ข้อแนะนำและข้อเสนอแนะ (Recommendations)

• Clean ก่อน Migrate: กพ.ทร. ควรถือโอกาสนี้ สังคายนาฐานข้อมูลกำลังพลทั้งระบบ ให้กำลังพลแต่ละนายช่วยยืนยันความถูกต้องของข้อมูลตนเองผ่านระบบ Self-Service ก่อนนำเข้า Odoo
• คุยกับเพื่อนบ้าน: ก่อนสร้าง Field ข้อมูล กพ.ทร. ต้องคุยกับ กง.ทร. และ พธ.ทร. ว่าเขาอยากได้ข้อมูลอะไรจากเราบ้าง เพื่อออกแบบให้ “ครั้งเดียวจบ” (Design for Integration) ไม่ใช่ทำเสร็จแล้วเพื่อนเอาไปใช้ต่อไม่ได้

---

บทสรุป

ถ้าการที่ กพ.ทร. อาสาลุกขึ้นมาเป็น “แม่ทัพ” ในการพัฒนาระบบ HR ด้วยตนเองผ่าน Odoo คือตัวอย่างที่ชัดเจนที่สุดของการลด Design Bias ครับ

ไม่มีใครรู้ปัญหาหน้างานดีเท่าคนทำ และไม่มีใครรู้ระเบียบดีเท่าเจ้าของเรื่อง การเปลี่ยนผ่านครั้งนี้จึงไม่ใช่แค่การอัปเกรดซอฟต์แวร์ แต่คือการ “เชื่อมต่อสายใย” ของข้อมูลกำลังพล ให้ไหลเวียนไปหล่อเลี้ยงส่วนอื่นๆ ของกองทัพเรือได้อย่างมีประสิทธิภาพ เปลี่ยนจากระบบที่ “ต่างคนต่างทำ” สู่ระบบที่ “เกื้อกูลกัน” อย่างแท้จริงครับ

(อ้างอิง: Odoo HR Module Documentation และ แนวทางการเชื่อมโยงข้อมูลภาครัฐ GD Catalog)

---

คำถามชวนคิด

• ท่านเคยเจอปัญหา “ยศเลื่อนแล้ว แต่เงินเดือนตกเบิกช้าหลายเดือน” หรือไม่? (ระบบใหม่จะช่วยแก้เรื่องนี้)
• ในระบบเก่า มีช่องกรอกข้อมูลไหนบ้างที่ท่านคิดว่า “มีไว้ทำไม? ไม่เห็นจำเป็น” หรือ “สิ่งที่จำเป็นดันไม่มี”?
• ท่านคิดว่าข้อมูลส่วนตัวของท่าน (เช่น เบอร์โทร, ที่อยู่) ในระบบปัจจุบัน ถูกต้องเป็นปัจจุบันหรือไม่? และอยากแก้ไขเองได้ไหม?

---

ติดตามตอนต่อไป

เมื่อหน่วยงานต่างๆ (อย่างกรมกำลังพล) เริ่มสร้างระบบของตัวเองกันอย่างคึกคัก แล้วใครจะเป็นคนคอยดูภาพรวม ไม่ให้ต่างคนต่างสร้างจนสะเปะสะปะ? ในตอนหน้า Ep.20/80 “บทบาทใหม่ของ สสท.ทร. และ ทีมพัฒนา จาก ‘ผู้สร้าง’ สู่ ‘ผู้กำกับดูแลมาตรฐาน’ (Regulator)” เราจะมาดูบทบาทใหม่ของฝ่ายไอทีส่วนกลาง ที่ต้องเปลี่ยนจากการเป็น “ช่างก่อสร้าง” มาเป็น “วิศวกรคุมงาน” ครับ! ห้ามพลาด!