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

S4 — สรุปผลกระทบจากการรวมระบบ V1 + V2

วัตถุประสงค์เอกสาร: วิเคราะห์ขอบเขตงานที่เพิ่มขึ้นจากข้อสั่งการให้ "สร้างใหม่โดยรวม V1 + V2 เข้าด้วยกัน" เทียบกับสิ่งที่ TOR ระบุไว้ เพื่อใช้ประกอบการเจรจาต่อรองกับผู้ว่าจ้างหลัก

วันที่จัดทำ: 6 เมษายน 2569

อ้างอิง: TOR ข้อ 7.14, ผลสำรวจเซิร์ฟเวอร์จริง (6 เม.ย. 2569)

1. สิ่งที่ TOR กำหนดไว้ vs สิ่งที่ถูกสั่งให้ทำจริง

1.1 ขอบเขตตาม TOR ข้อ 7.14

TOR ระบุว่า S4 คือ "ปรับปรุงระบบสารสนเทศกลางสำหรับการไกล่เกลี่ยข้อพิพาท ระยะที่ 2" โดย ปรับปรุงตาม ลิงก์ www.emediations.rlpd.go.th (เครื่อง V2 เท่านั้น) ประกอบด้วย:

หมวด TOR ขอบเขต ลักษณะงาน
7.14.1 ปรับปรุงการจัดการหลักสูตรอบรมผู้ไกล่เกลี่ย แก้ไข/เพิ่มฟังก์ชัน
7.14.2 ปรับปรุงระบบขึ้นทะเบียนและจัดการข้อมูลศูนย์ไกล่เกลี่ยภาคประชาชน แก้ไข/เพิ่มฟังก์ชัน
7.14.3 ปรับปรุงระบบรับภารกิจด้านการไกล่เกลี่ย แก้ไข/เพิ่มฟังก์ชัน
7.14.4 ปรับปรุงผู้ดูแลระบบ แก้ไข/เพิ่มฟังก์ชัน

คำสำคัญใน TOR: "ปรับปรุง" (Improvement) — ไม่มีการกล่าวถึงการรวมระบบ ไม่มีการกล่าวถึง V1 และไม่มีการกล่าวถึงการย้ายข้อมูลข้ามระบบ

1.2 สิ่งที่ถูกสั่งให้ทำจริง (จากกรรมการ)

"สร้างใหม่โดยรวม V1 + V2 เข้าเป็นระบบเดียว" ซึ่งรวมถึง:

งาน ลักษณะ มีใน TOR?
วิเคราะห์ Feature ทั้งหมดของ V1 (PHP) Reverse Engineering ไม่มี
วิเคราะห์ Feature ทั้งหมดของ V2 (Node/Vue) Reverse Engineering ไม่มี
จัดทำ Feature Mapping ระหว่าง V1 vs V2 Gap Analysis ไม่มี
วิเคราะห์ข้อมูลซ้ำ/ต่างระหว่าง 2 ฐานข้อมูล Data Reconciliation ไม่มี
ย้ายข้อมูลจาก Legacy DB → Production DB Data Migration ไม่มี
พัฒนาระบบใหม่ที่รวมฟีเจอร์ทั้ง V1 + V2 Full Rebuild ไม่มี (TOR ระบุแค่ "ปรับปรุง")
ทดสอบข้อมูลหลัง Migration Data Validation ไม่มี
ปรับปรุงฟีเจอร์ตาม TOR 7.14.1-7.14.4 Feature Enhancement มี (เฉพาะส่วนนี้)

1.3 สรุปส่วนต่าง

``` งานตาม TOR (เดิม): ├── ปรับปรุง V2 (emediations.rlpd.go.th) ตามข้อ 7.14 └── เพิ่มฟังก์ชัน + แก้ไข UI/UX

งานที่ถูกสั่งเพิ่ม (นอก TOR): ├── Reverse Engineer ระบบ V1 ทั้งหมด (PHP/CodeIgniter v9.0) ├── Feature Mapping: V1 ↔ V2 (เมนูซ้ำ/ไม่ซ้ำ) ├── Data Reconciliation: 55,343 records (V2 Legacy) vs 12,378 records (V1 Prod) ├── Data Migration Scripts + Validation ├── Rebuild ระบบใหม่ที่ครอบคลุมฟีเจอร์ทั้ง 2 เวอร์ชัน └── Decommission ระบบเก่า + Cutover Plan ```

2. ความซับซ้อนทางเทคนิคในการรวม V1 + V2

2.1 Tech Stack ที่แตกต่างกันโดยสิ้นเชิง

รายการ V1 (emediation) V2 / Phase 1 (emediations)
Server OS Windows Server Ubuntu 20.04 LTS
Web Server Apache/XAMPP Apache + PM2 (Node.js)
Backend PHP 7.2 + CodeIgniter Node.js 14 + Express 4.18
Frontend Server-side render (PHP) Vue.js + CoreUI Pro (SPA)
IP 10.136.27.41 10.136.27.87
Domain emediation.rlpd.go.th emediations.rlpd.go.th
DB Location MEDIATE schema @ 10.136.27.149:3412 mediate2020 DB @ 10.136.27.43:1433
DB Version SQL Server 2022 SQL Server 2017
Source Code ไม่มี Git (อยู่บน Windows/XAMPP) GitHub (webify-th + pravarntle)
นักพัฒนาเดิม ไม่ทราบ (ก่อนปี 2563) Webify (Phase 1), pravarntle (V2 เดิม)

การรวมระบบที่ ต่าง OS, ต่างภาษา, ต่าง Framework ไม่ใช่การ "ปรับปรุง" แต่เป็นการ สร้างใหม่ทั้งหมด (Full Rebuild) โดยต้อง reverse engineer ฟีเจอร์จากระบบ PHP เดิมมาเขียนใหม่ทั้งหมด

2.2 ฐานข้อมูลที่ต้อง Migrate + Reconcile

ฐานข้อมูล เซิร์ฟเวอร์ ข้อมูลเรื่องไกล่เกลี่ย หมายเหตุ
MEDIATE schema (Production) 10.136.27.149:3412 12,378 cases V1 ใช้อยู่ปัจจุบัน
mediate2020 (Legacy) 10.136.27.43:1433 55,343 cases V2 ข้อมูลเก่าสะสม
mediate2020-NEW (Clone) 10.136.27.43:1433 10,886 cases สำเนาบน UAT

ปัญหาด้านข้อมูล:

  • ข้อมูลใน V2 Legacy มีมากกว่า V1 Production ถึง 4.5 เท่า (55K vs 12K records)
  • ไม่ทราบว่าข้อมูลทั้ง 2 ชุดเป็น ชุดเดียวกัน (subset) หรือ คนละชุด (disjoint) — ต้องวิเคราะห์ทีละ record
  • ตาราง cms_mediation มี 107 columns ซึ่งบางคอลัมน์มีข้อแตกต่าง (เช่น idcard varchar(20) vs varchar(13), binary columns ที่เพิ่มมา)
  • ผู้ใช้งาน (cms_users) มี 3,185 คน (V1) vs 2,950 คน (V2) — ต้องจับคู่ว่าคนไหนซ้ำ คนไหนไม่ซ้ำ
  • ไม่มี Foreign Keys ในทั้ง 2 ฐานข้อมูล → ต้อง validate data integrity ด้วยมือ

2.3 Codebases ที่กระจัดกระจาย

จากการสำรวจเครื่อง V2 (10.136.27.87) พบ 5+ codebases ใน /opt/nodejs/:

Codebase ผู้พัฒนา สถานะ
mediation-backend2025 Webify (Phase 1) Active — กำลังใช้งาน
mediation-frontend2025 Webify (Phase 1) Active — กำลังใช้งาน
mediation-backend pravarntle (V2 เดิม) Inactive
mediation-frontend pravarntle (V2 เดิม) Inactive
mediation-new-backend pravarntle (V2 เดิม) Inactive

นอกจากนี้ ใน mediation-backend2025 พบ copy-based versioning คือมีไฟล์: - mssqlController.js - mssqlController-20250907.js - mssqlController-20251229.js - mssqlController-20260326.js

ซึ่งแสดงว่าไม่มี Git branch management ที่ดี → ต้องใช้เวลาทำความเข้าใจโค้ดก่อนต่อยอด

2.4 ฟีเจอร์ที่ต้อง Reverse Engineer จาก V1

จากการสำรวจหน้าเว็บ V1 (emediation.rlpd.go.th) พบฟีเจอร์หลักที่ ไม่มีใน V2:

ฟีเจอร์ V1 มีใน V2? หมายเหตุ
หน้าแรก Public (ข่าว, Banner, ลิงก์) บางส่วน V1 มี UI ที่สมบูรณ์กว่า
ยื่นคำร้องไกล่เกลี่ย (Public) มี แต่ flow ต่างกัน
ติดตามสถานะคำร้อง (Public) มี
ลงทะเบียนศูนย์ไกล่เกลี่ยประจำท้องที่ ต้องตรวจสอบ
สมัครเป็นผู้ไกล่เกลี่ย (Public) มี
ระบบอบรม / Training มี
ระบบ Back-office เจ้าหน้าที่ มี (V2) ตรรกะต่างกัน
ฟอร์ม PDF (K-CoP, ใบเสร็จ, ค่าเดินทาง) ไม่มีใน V2 ต้อง reverse engineer
Online Mediation (Webex) เฉพาะ Phase 1

การ reverse engineer ระบบ V1 ที่เป็น PHP ต้องอ่านโค้ด PHP ทีละไฟล์ เนื่องจากไม่มีเอกสาร API และไม่มี Git history

3. การวิเคราะห์ผลกระทบต่อต้นทุนและระยะเวลา

3.1 ประมาณการ Effort ที่เพิ่มขึ้น

งานที่เพิ่มจากการรวม V1+V2 Man-Days (ประมาณ) หมายเหตุ
Reverse Engineer V1 (PHP) 15-20 วัน อ่านโค้ด PHP, จัดทำ feature list, จัดทำ flowchart
Feature Mapping V1 ↔ V2 5-7 วัน เปรียบเทียบเมนู, ตรรกะ, ฟอร์ม
Data Reconciliation Analysis 7-10 วัน วิเคราะห์ 55K vs 12K records, หา overlap
Data Migration Scripts 10-15 วัน เขียน script, จัดการ binary data, validate
พัฒนาฟีเจอร์ V1 ที่ไม่มีใน V2 20-30 วัน ฟอร์ม PDF, ระบบ back-office, หน้า public
Data Validation + UAT 7-10 วัน ทดสอบข้อมูลหลัง migrate
Cutover Planning 3-5 วัน แผนปิดระบบเก่า, เปลี่ยน DNS
รวม 67-97 วัน (~3-4 เดือนคน)

3.2 สิ่งที่ TOR ระบุ vs สิ่งที่เกิดขึ้นจริง

รายการ ตาม TOR สถานการณ์จริง ส่วนต่าง
ลักษณะงาน S4 ปรับปรุง (Improvement) สร้างใหม่ + รวมระบบ (Rebuild + Merge) เปลี่ยนประเภทงานทั้งหมด
ระบบที่ต้องรับมอบ V2 (emediations) ระบบเดียว V1 (emediation) + V2 (emediations) สองระบบ +1 ระบบ
ฐานข้อมูลที่เกี่ยวข้อง mediate2020 ฐานเดียว MEDIATE (.149) + mediate2020 (.43) +1 ฐานข้อมูล +1 เซิร์ฟเวอร์
Tech Stack Node.js/Vue.js ตัวเดียว PHP/CI + Node.js/Vue.js (2 stacks) +1 ภาษา
ข้อมูลที่ต้องจัดการ ~12K cases ~67K cases (12K + 55K) +55K records
Effort สำหรับ S4 ปรับปรุงฟีเจอร์ (est. ~40-60 man-days) Rebuild + Merge (est. ~107-157 man-days) +67-97 man-days

3.3 ผลกระทบต่องบประมาณ

รายการ มูลค่า
งบประมาณโครงการทั้งหมด (9 ระบบ รวม VAT) 6,700,000 บาท
ระยะเวลา 270 วัน
งบเฉลี่ยต่อระบบ (หาร 9 เท่ากัน) ~744,444 บาท
S4 ตาม TOR (Improvement) — สัดส่วนที่เหมาะสม ~12-15% ~800,000 - 1,000,000 บาท
S4 ตามที่สั่งจริง (Rebuild + Merge) — ควรเป็น ~25-30% ~1,675,000 - 2,010,000 บาท
ส่วนต่างที่เพิ่มขึ้น ~675,000 - 1,200,000 บาท

4. ข้อเสนอแนะในการเจรจาต่อรอง

ทางเลือกที่ 1: ขยายระยะเวลา (แนะนำ)

รายการ เดิม เสนอ
ระยะเวลา S4 รวมอยู่ใน 270 วัน ขยายเพิ่ม 60-90 วัน สำหรับงาน merge
งบประมาณ คงเดิม คงเดิม
เหตุผล งาน merge ไม่ได้อยู่ใน TOR เดิม ต้องใช้เวลาเพิ่ม

จุดแข็ง: ไม่ต้องเจรจาเรื่องเงิน แค่ขอเวลาเพิ่ม ซึ่งสมเหตุสมผลกว่า

ทางเลือกที่ 2: เพิ่มค่าตอบแทน

รายการ เดิม เสนอ
ระยะเวลา 270 วัน คงเดิม หรือขยายเล็กน้อย (+30 วัน)
งบเพิ่มสำหรับ S4 Merge 0 +800,000 - 1,200,000 บาท
เหตุผล เป็นงาน scope ใหม่ที่ไม่อยู่ใน TOR

ทางเลือกที่ 3: ลด Scope ระบบอื่น

รายการ เดิม เสนอ
จำนวนระบบ 9 ระบบ ส่งมอบ 7-8 ระบบตรงเวลา, ที่เหลือขยายเวลา
งบประมาณ คงเดิม คงเดิม
เหตุผล ถ้า S4 กิน effort เพิ่ม 3-4 เดือนคน ระบบอื่นจะได้รับผลกระทบ

ทางเลือกที่ 4: แบ่งเฟส (Phased Approach)

เฟส ขอบเขต ระยะเวลา
เฟส 1 (ภายใน 270 วัน) ปรับปรุง V2 ตาม TOR 7.14 + สร้าง UI Shell ครอบ V1+V2 ให้ดูเป็นระบบเดียว ตามสัญญาเดิม
เฟส 2 (หลัง 270 วัน) รวมข้อมูล + รวมโค้ดจริง + decommission V1 ต่อรองแยก

จุดแข็ง: ส่งมอบได้ตรงเวลา + ผู้ใช้รู้สึกว่าเป็นระบบเดียว + รวมจริงทีหลังอย่างมีคุณภาพ

5. ประเด็นที่ต้องใช้ในการชี้แจง

5.1 หลักฐานเชิงเทคนิค

  1. TOR ข้อ 7.14 อ้างอิงเฉพาะ www.emediations.rlpd.go.th (V2 เท่านั้น) ไม่ได้กล่าวถึง emediation.rlpd.go.th (V1) แม้แต่ครั้งเดียว

  2. TOR ใช้คำว่า "ปรับปรุง" (ข้อ 5 ลำดับที่ 4) ไม่ใช่ "พัฒนาใหม่" หรือ "รวมระบบ" — คำว่า "พัฒนา" ใช้เฉพาะกับ S1, S2, S3 ที่เป็นระบบใหม่

  3. V1 และ V2 เป็นระบบคนละ Tech Stack (PHP vs Node.js) บนคนละเครื่อง คนละ OS คนละฐานข้อมูล — การรวมเท่ากับสร้างใหม่

  4. ข้อมูลที่ต้อง migrate มี 55,343 records จากฐานข้อมูลที่อยู่คนละเซิร์ฟเวอร์ (SQL Server 2017 on .43 → SQL Server 2022 on .149) ซึ่งไม่มีระบุใน TOR

5.2 ข้อความแนะนำสำหรับการสื่อสาร

"ตาม TOR ข้อ 7.14 ระบุขอบเขตงานคือ 'ปรับปรุง' ระบบ emediations.rlpd.go.th ซึ่งเป็นระบบ V2 ที่ทำงานบน Node.js/Vue.js เพียงระบบเดียว แต่ข้อสั่งการให้รวม V1 (emediation.rlpd.go.th ที่ทำงานบน PHP/CodeIgniter บน Windows Server) เข้ามาด้วย ถือเป็นการ เปลี่ยนแปลงขอบเขตงาน (Scope Change) ที่มีผลกระทบต่อระยะเวลาและทรัพยากร เนื่องจากต้องดำเนินการเพิ่มเติมอย่างน้อย 6 ขั้นตอนที่ไม่ได้อยู่ใน TOR ได้แก่ Reverse Engineering, Feature Mapping, Data Reconciliation, Data Migration, System Rebuild และ Cutover Planning"

5.3 สิ่งที่ควรขอเป็นลายลักษณ์อักษร

  • หนังสือยืนยันการเปลี่ยนแปลงขอบเขตงาน (Change Request) จากกรรมการตรวจรับงาน ระบุว่าให้รวม V1 + V2
  • ขอบเขตที่ชัดเจน ว่าต้องรวมฟีเจอร์อะไรบ้างจาก V1 (ทั้งหมด หรือเฉพาะบางส่วน)
  • เกณฑ์การตรวจรับ สำหรับงาน Data Migration (ยอมรับข้อมูลสูญหายได้กี่ %, ข้อมูลอะไรต้อง migrate)
  • แผนการ Decommission V1 — ใครเป็นคนปิดระบบเก่า, เมื่อไหร่

6. สรุป (Executive Summary)

หัวข้อ สรุป
ขอบเขตตาม TOR ปรับปรุง V2 ระบบเดียว (emediations) — เพิ่ม/แก้ไขฟังก์ชัน
ขอบเขตที่สั่งจริง สร้างใหม่โดยรวม V1 (PHP) + V2 (Node.js) เข้าด้วยกัน
ระดับผลกระทบ สูงมาก — เปลี่ยนจาก "ปรับปรุง" เป็น "สร้างใหม่ + รวมข้อมูล"
Effort ที่เพิ่มขึ้น +67 ถึง 97 man-days (~3-4 เดือนคน)
ค่าใช้จ่ายที่เพิ่มขึ้น (ประมาณ) +675,000 - 1,200,000 บาท
ทางเลือกที่แนะนำ ทางเลือกที่ 4 (แบ่งเฟส) — ส่งมอบ TOR ตรงเวลา + รวมจริงแยกเฟส
สิ่งที่ต้องทำทันที ขอ Change Request เป็นลายลักษณ์อักษร