ข้ามไปที่เนื้อหา

S4 — ระบบสารสนเทศกลางไกล่เกลี่ยข้อพิพาท ระยะที่ 2 (Mediation System)

⚠️ ระบบที่มีความซับซ้อนระดับสูงสุด (Highest Complexity)

ตารางสรุปข้อมูลเบื้องต้น

หัวข้อ รายละเอียด
อ้างอิง TOR ข้อ 7.14
หน่วยงานรับผิดชอบ กองส่งเสริมการระงับข้อพิพาท (กสร.) — เจ้าภาพโครงการ Phase 2
ลักษณะการพัฒนา การปรับปรุงและรวมระบบเดิม (System Consolidation & Improvement)
สถานะโครงการ :large_blue_circle: ต่อเนื่องจาก Phase 1 — Phase 1 ปรับปรุงระบบไกล่เกลี่ยข้อพิพาทไปแล้ว (TOR Phase 1 ข้อ ๖) เฉพาะส่วนเบิกจ่ายค่าตอบแทน, Phase 2 เป็น "ระยะที่ 2" ปรับปรุงระบบงานหลักทั้งหมดเพิ่มเติม
ระดับความซับซ้อน ระดับสูงมาก (🔴 High Risk)
URL ปัจจุบัน www.emediations.rlpd.go.th
หมายเหตุ เป็นระบบที่ถือว่ามีความท้าทายที่สุดในบรรดาทั้ง 9 ระบบของ Phase 2

สถานะปัจจุบัน (Current State)

  • ปัญหาการแยกเวอร์ชัน (Version Fragmentation): ปัจจุบันมีการใช้งานระบบพร้อมกันถึง 3 รูปแบบ ส่งผลให้ข้อมูลกระจายตัว:
  • เวอร์ชัน 1 (v1): พัฒนาปี 2563 — ระบบฐานเดิมที่มีฟังก์ชันส่วนใหญ่
  • เวอร์ชัน 2 (v2): พัฒนาปี 2565 — พัฒนาแยกออกมาเพื่อแก้ปัญหาเร่งด่วนของ v1

  • เวอร์ชัน Phase 1: พัฒนาปี 2568 — โดย MFEC มุ่งเน้นเฉพาะส่วนการเบิกจ่ายค่าตอบแทน (ตาม TOR 7.14 ข้อ 6.1)

  • ผลกระทบต่อผู้ใช้งาน (User Experience Impact): ผู้ใช้งานจำเป็นต้อง สลับเวอร์ชันไปมา ด้วยตนเองเพื่อให้ครบวงจรการทำงาน (Workflow)

  • ตัวอย่าง: เริ่มบันทึกข้อมูลใน v1 เมนูที่ 4 → ดำเนินงานจนจบขั้นตอน → ต้องสลับไปใช้งาน v2 เพื่อปิดงาน

  • ประเด็นนี้ถือเป็นปัญหา UX ที่ วิกฤติที่สุด และสร้างความสับสนให้แก่เจ้าหน้าที่อย่างมาก

  • ความต้องการของผู้มีส่วนได้ส่วนเสีย (Stakeholder Expectation): กรมฯ ต้องการให้มีการรวมระบบ (Merge) ทั้งหมดเข้าด้วยกันแบบ "ยุบรวมและสร้างใหม่" (Consolidation) ให้เป็นระบบเดียวที่สมบูรณ์

รายละเอียดทางเทคนิคจาก Phase 1 (Technical Details)

รายการ ข้อมูลอ้างอิง
ขอบเขต Phase 1 เฉพาะส่วนการเบิกจ่ายค่าตอบแทนและค่าใช้จ่าย (Compensation Flow)
เทคโนโลยี (Mediator Site) PHP + CodeIgniter (Port 9008) — ยืนยันตัวตนผ่าน ThaiD
เทคโนโลยี (Officer Site) Vue.js (Port 9009)
เทคโนโลยี (API) Node.js (Port 4000)
การติดตั้ง (Deployment) Docker Containers บนเครื่อง Linux (10.136.27.124)
คะแนนความพึงพอใจ 3.4/5 (ต่ำที่สุดในกลุ่มระบบ Phase 1 — คะแนนวิทยากร 2.7/5)

ข้อมูลเซิร์ฟเวอร์ Production จากทีม Phase 1 (สำรวจ 6 เมษายน 2569)

เครื่อง IP บทบาท Stack หมายเหตุ
V1 Production 10.136.27.41 ระบบไกล่เกลี่ยเดิม (สร้างปี 2563) Windows, Apache/XAMPP, PHP 7.2 + CodeIgniter, App v9.0 emediation.rlpd.go.th
V2 Production 10.136.27.87 ระบบไกล่เกลี่ยใหม่ (สร้างปี 2565) Ubuntu 20.04, Node.js 14 + Express + Vue.js, PM2 emediations.rlpd.go.th
UAT (Phase 1) 10.136.27.124 VM UAT รวมทุกระบบ Phase 1 Ubuntu 24.04, Docker ทั้ง V1 และ V2 รัน Docker containers ร่วมกัน

📄 ดูผลสำรวจเทคนิคฉบับเต็ม: S4 Technical Reconnaissance

ข้อค้นพบสำคัญจากการสำรวจ

  • DB Schema เหมือนกัน: ตาราง cms_mediation มี ~107 คอลัมน์เหมือนกันทั้ง V1 (MEDIATE schema) และ V2 (mediate2020 DB)
  • ข้อมูลต่างกัน: V1 Production มี 12,378 cases, V2 Legacy มี 55,343 cases
  • ไม่มี Stored Procedures / Foreign Keys — business logic อยู่ในโค้ดแอปพลิเคชัน
  • 5+ codebases อยู่บนเครื่อง V2 จากนักพัฒนาต่างทีม
  • ความยากในการรวม: ระดับ 6/10 (ปานกลาง-สูง) — DB structure ง่าย แต่ code fragmentation สูง

ขั้นตอนการเบิกจ่ายใน Phase 1 (Compensation Workflow)

graph LR
    A[ผู้ไกล่เกลี่ย] -- ยื่นเอกสาร/เบิกเงิน --> B[เจ้าหน้าที่กรม]
    B -- ตรวจสอบ --> C[หัวหน้างาน]
    C --> D[ผอ.กอง]
    D --> E[รองอธิบดี]
    E --> F[อธิบดี]

⚠ ข้อควรระวัง: Phase 1 ครอบคลุมเพียงส่วนการเบิกจ่ายเท่านั้น แต่ใน Phase 2 ต้องปรับปรุงระบบงานหลักทั้งหมด (ลงทะเบียน, รับคำร้อง, กระบวนการไกล่เกลี่ยออนไลน์, รายงานสรุป) ซึ่งมีความซับซ้อนเชิงเทคนิคและกฎหมายสูงกว่ามาก

ขอบเขตความต้องการตาม TOR

  • เพิ่มเมนูและฟีเจอร์ใหม่ตามข้อกำหนดใน Phase 2 (Section 7.14)
  • ข้อสังเกตสำคัญ: ข้อกำหนด TOR มุ่งเน้นการ "เพิ่มฟังก์ชัน" (Feature Addition) แต่ความต้องการจริงหน้างานคือการ "ยกเครื่องระบบ" (System Rebuild) ซึ่งอาจส่งผลกระทบต่อกรอบเวลา 270 วัน

ปัญหาและอุปสรรคที่ตรวจพบ (Key Issues)

  1. ขั้นตอนงานไม่สอดคล้องกัน (Inconsistent User Journeys): ขั้นตอนการทำงานใน v1 และ v2 มีตรรกะที่แตกต่างกัน
  2. เมนูซ้ำซ้อน (Redundant Menus): รายการเมนูในแต่ละเวอร์ชันมีการทับซ้อนและชื่อเรียกไม่เหมือนกัน
  3. ขาดศูนย์กลางข้อมูล (No Unified Workflow): ไม่มีกระบวนการทำงานที่เป็นมาตรฐานเดียว ทำให้ผู้ใช้ไม่ทราบว่าควรใช้เวอร์ชันใดในสถานการณ์ใด
  4. ความล่าช้าในการทำงาน (UX Friction): การต้องสลับระบบบ่อยครั้งทำให้ข้อมูลสูญหายหรือผิดพลาดได้ง่าย
  5. ภาระทางเทคนิค (Technical Debt): การต้องดูแลรักษา Codebase และโครงสร้างฐานข้อมูลที่แยกจากกัน 3 ชุด

ขั้นตอนการทำงาน (Workflow)

สถานะปัจจุบัน (Fragmented Workflow): 1. ผู้ใช้เข้าสู่ระบบ Mediation กลาง 2. พบว่าฟังก์ชันที่ต้องการอยู่ใน v1 แต่บางส่วนต้องทำใน v2 3. ผู้ใช้ต้องจดจำและสลับเวอร์ชันด้วยตนเองระหว่างกระบวนการ 4. การทำงานให้เสร็จสิ้น (Closure) ต้องใช้การประมวลผลจากหลายแหล่ง

สถานะที่ต้องการ (Unified Workflow): - มีจุดเข้าใช้งานเดียว (Single Entry Point) - รวมฟังก์ชันทั้งหมดไว้ภายใต้หน้าจอเดียว (Consolidated UI) - กระบวนการทำงานไหลลื่นต่อเนื่อง (Seamless Flow) โดยไม่ต้องสลับเวอร์ชัน

จุดเชื่อมต่อระบบ (System Integration)

  • เชื่อมโยงกับระบบระงับข้อพิพาทอื่นๆ ของกระทรวงยุติธรรม
  • ความสามารถในการติดตามสถานะสำนวนข้ามระบบ (Cross-system Case Tracking)
  • ระบบรายงานสถิติการไกล่เกลี่ยเชิงวิเคราะห์

ประเด็นที่ต้องการคำชี้แจง (Open Issues)

[ประเด็นเปิด] การรวม v1 + v2 และฟีเจอร์ Phase 2 ทั้งหมด สามารถดำเนินการให้เสร็จสิ้นภายใน 270 วัน พร้อมกับระบบอื่นอีก 8 ระบบได้จริงหรือไม่?

[ประเด็นเปิด] รายการความแตกต่างของฟีเจอร์ (Feature Mapping) ระหว่าง v1 และ v2 มีรายละเอียดชัดเจนเพียงใด? (ฟังก์ชันใดควรคงไว้ ฟังก์ชันใดควรยกเลิก?)

[ตอบแล้วบางส่วน — 6 เม.ย. 2569] โครงสร้างฐานข้อมูล (Database Schema) ของทั้ง 3 ส่วนมีความแตกต่างกันอย่างไร?

คำตอบจากการสำรวจ: Schema cms_mediation เหมือนกัน ~107 columns ทั้ง V1 (MEDIATE on .149) และ V2 (mediate2020 on .43) ข้อแตกต่างหลัก:

  • MEDIATE schema (Production) มี 95 tables รวมตาราง compensation ที่ Phase 1 เพิ่ม (8 tables)
  • mediate2020 (Legacy) มี 79 tables เป็นชุดเดิม
  • ข้อมูลไม่ตรงกัน: V2 legacy มี 55K cases vs Production 12K → ต้องวิเคราะห์ data reconciliation
  • ไม่มี Stored Procedures หรือ Foreign Keys ในทุก schema → migration ง่ายขึ้น

ดูรายละเอียดเต็มที่ S4 Technical Recon

[ประเด็นเปิด] เทคโนโลยีหลัก (Tech Stack) ที่กรมฯ เลือกใช้สำหรับระบบรวมคืออะไร? (เนื่องจากปัจจุบันมีความผสมผสานระหว่าง PHP, Node.js, .NET และ Vue.js)

[ประเด็นเปิด] จะมีการประเมินทรัพยากรที่ต้องใช้จริง (Actual Effort) สำหรับการ "สร้างใหม่" เทียบกับการ "แก้ไขตาม TOR" เพื่อให้ผู้บริหารตัดสินใจเลือกแนวทางที่เหมาะสมที่สุดหรือไม่?

[ประเด็นเปิด — เพิ่ม 6 เม.ย. 2569] ข้อมูลใน mediate2020 (55,343 cases) เทียบกับ MEDIATE schema (12,378 cases) — เป็นข้อมูลชุดเดียวกันที่ย้ายมาบางส่วน หรือเป็นข้อมูลคนละชุดที่ต้อง merge?

[ประเด็นเปิด — เพิ่ม 6 เม.ย. 2569] V1 server (.41) มี MSSQL port 1433 เปิดอยู่ แต่ credentials ที่มีเข้าไม่ได้ — มีฐานข้อมูล local บน V1 ที่ต้อง migrate หรือไม่?

หมายเหตุทางเทคนิคและข้อเสนอแนะ (Technical Notes)

แนวทางแบบแบ่งระยะ (Proposed Phased Approach):

  1. ระยะสั้น (Phase 2 Commitment):
  2. ประเมินความเป็นไปได้ในการรวมเวอร์ชันภายใต้ข้อจำกัดของเวลาและงบประมาณ
  3. กรณีไม่สามารถรวมได้สมบูรณ์: ทำการแม็พเมนูอย่างละเอียดและสร้างหน้ากาก (UI Shell) ครอบเพื่อให้ผู้ใช้รู้สึกว่าเป็นระบบเดียว
  4. ซ่อนเมนูที่ซ้ำซ้อนหรือล้าสมัย (Legacy) เพื่อลดความสับสน

  5. พัฒนาฟีเจอร์ใหม่ตามข้อกำหนด TOR 7.14

  6. ระยะยาว (Future Phase):

  7. วางแผนรวม Codebase ของ v1 และ v2 เข้าด้วยกันอย่างถาวร
  8. รวมฐานข้อมูล (Consolidate Databases) ให้เป็น Single Schema
  9. ทำการทดสอบระบบ (Unified Testing) และประกันคุณภาพ (QA) เต็มรูปแบบ

มาตรการลดความเสี่ยง: - หารือกับผู้มีส่วนได้ส่วนเสียโดยเร็วที่สุดเพื่อบริหารจัดการความคาดหวัง (Expectation Management) - ขอคำยืนยันเป็นลายลักษณ์อักษรว่าขอบเขตงานคือ "การสร้างใหม่ทั้งหมด" หรือ "การเพิ่มฟังก์ชันตาม TOR" - กำหนดช่วงเวลาการทดสอบระบบร่วมกับเจ้าหน้าที่หน้างาน (Stakeholder Testing) อย่างต่อเนื่อง