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

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

สถานะการพัฒนาล่าสุด (% ความคืบหน้า / เฟสที่ทำไปแล้ว / ของที่ค้าง): ดู แผนงาน เฟส และความคืบหน้า

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

เอกสาร Schema ฐานข้อมูล

ดูโครงสร้างฐานข้อมูล (95 ตาราง, 10 functional groups) → Database Schema — S4 Mediation

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

หัวข้อ รายละเอียด
อ้างอิง 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
Interactive Mockup rlpd-s4-emediation.pages.dev (Cloudflare Pages)

สถานะปัจจุบัน (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) ให้เป็นระบบเดียวที่สมบูรณ์

ความคืบหน้าระบบใหม่ (V3 rewrite — Phase 2, อัปเดต 8 ก.ย. 2569)

Repo: RLPDxMFEC-DevCode/emediation (NestJS + React/Vite; branch model: งานบน develop, release-merge + tag จาก main). MVP1 เสร็จและ tag v0.2.0 เมื่อ 13 ส.ค. 2569; ปัจจุบันบน UAT = v0.9.24 (8 ก.ย. 2569) — รายการ v0.2.x ด้านล่างคือประวัติช่วง ส.ค.; สรุปช่วง v0.3.x–v0.9.24 อยู่ท้ายรายการ:

  • v0.2.6 — ไฟล์แนบรูปภาพประกาศศูนย์: ประกาศศูนย์ (/centers/announcement) แนบรูป/เอกสารได้จริง เก็บใน MinIO ผ่าน shared library rlpdjs StorageModule (ตาราง cms_center_announcement_attachment migration V072, วงจร staged→claim-on-create ตามแบบหลักฐานคดี V058; ตรวจ magic bytes pdf/jpg/png, รูป ≤5MB / pdf ≤50MB)
  • v0.2.7 — ประกาศสาธารณะ: endpoint anonymous GET /api/public/center-announcements (เฉพาะสถานะเผยแพร่ ไม่มีข้อมูลเจ้าหน้าที่) + ดาวน์โหลดไฟล์แนบสาธารณะ (404 ถ้ายังไม่เผยแพร่/เป็น draft/ถูกลบ) แสดงบนพอร์ทัลประชาชน: /public/training-signup (ประเภท รับสมัคร — เพิ่มเป็นประเภทที่ 5) และ /public/news (ประเภท ทั่วไป) พร้อมรูป cover
  • v0.2.8 — logger fix (ทีม): service.name ตรงชื่อ container rlpd-emediation-be
  • v0.2.9 — สมัครอบรมออนไลน์จริง (training enrollment) — flow: เจ้าหน้าที่สร้างรุ่นอบรม → ประชาชนดู catalogue → สมัคร → กรอกข้อมูล → ตรวจสอบสถานะ (ทำ V1 ใหม่ 1:1; V2 เคย regressed ทิ้ง public self-register). migration V073 = 4 ตาราง (cms_training_topic รุ่น/offering, cms_training_register การสมัคร, cms_training_register_result(_item) คัดเลือกรอบ 2). BE: backend/src/training/ (offering CRUD + registrant list + คัดเลือก 2 รอบ, RBAC training_topic/training_register) + anonymous GET/POST /api/public/training-courses(/:id/cover) / /training-registrations(/check). ปรับปรุงจาก V1/V2: เลขบัตร ปชช. hash+mask ไม่เก็บดิบ (PDPA), checksum mod-11, โควตา/ปิดรับ/ซ้ำ ตรวจใน tx (UPDLOCK/HOLDLOCK กัน over-subscription), ALTCHA แทน captcha รูป, FE 4-step stepper + ThaID prefill + แบนเนอร์รุ่น (อัปโหลด MinIO, แนะนำ 1024×1024). เจ้าหน้าที่ 2 รอบ: qualify (ผ่าน/ไม่ผ่าน) → select/accept/announce. รวมแก้บั๊ก public-page: หน้า /public/* เคยจอเปล่าเมื่อ Keycloak init ล้มเหลว (SSO ล่ม / เบราว์เซอร์บล็อก 3rd-party iframe) — แก้ให้ render แบบ anonymous. e2e e2e:training 30/30 (รวมโควตา/ซ้ำ/ปิดรับ/checksum/ cover + 2 รอบ); security review ผ่าน (แก้ 2 LOW: quota race, LIKE escape).
  • Deploy v0.2.9 บน UAT (ยืนยัน 17 ส.ค. 2569): tag → CI build+push GHCR → CD deploy .155 อัตโนมัติ, รัน migration V073 ด้วย sa (container-env-direct) แล้วทดสอบสมัครจริงผ่าน (MRG001001001, seatsLeft 40→39).
  • v0.2.10 — ALTCHA ครบทุกฟอร์มสาธารณะ: เพิ่ม self-hosted ALTCHA proof-of-work (rlpdjs AltchaModule, ตรวจฝั่ง server ก่อน id lookup) บน /public/tracking (mediation-requests/track) และ /public/center-tracking (centers/track) — สองหน้าสุดท้ายที่ยังใช้ image captcha แบบ V1 (center-tracking เดิมไม่มี captcha เลย). ตอนนี้ ทุก ฟอร์มสาธารณะใช้ ALTCHA. ไม่มี migration. Deploy บน UAT ยืนยันแล้ว (no-altcha → 400, solved → 200 ทั้งสอง endpoint). หมายเหตุ CD: รอบนี้ GitHub API ล่มชั่วคราวตอน release ทำให้ repository_dispatch หล่น → CD ไม่ deploy อัตโนมัติ; แก้โดย re-trigger CI ผ่าน gh workflow run <ci> -f tag=<version> (build+dispatch ใหม่ ไม่ต้อง tag ใหม่). ห้าม manual docker compose up บน .155 — secret (EMEDIATION_IDCARD_HASH_SECRET, DB/MinIO) ถูก inject จาก CD ไม่มี .env บนเครื่อง; ใส่ผิดจะทำให้ hash เลขบัตรพัง.
  • v0.2.11 — Accessibility (WCAG 2.2 AA) พอร์ทัลสาธารณะ: จาก audit หน้า public entry แก้: FieldRow ผูก <label htmlFor> จริงกับ input (gen id ด้วย React.useId, clone ลง child) → ทุกฟอร์มสาธารณะมี accessible name (1.3.1/3.3.2/4.1.2 — placeholder ไม่นับเป็นชื่อ); skip link "ข้ามไปยังเนื้อหาหลัก" → #public-main ใน public shell (App.jsx, 2.4.1); หัวข้อ section หน้าแรกเป็น <h2> จริง (2.4.6); footer contrast (.5→.78 ผ่าน 4.5:1, 1.4.3) + target size ปุ่ม ≥24px (2.5.8); logo ปุ่ม header ย่อย alt="" กันชื่อซ้ำ (4.1.2). ยืนยันบน UAT (label ผูกจริง, skip link, h2 render). Follow-up: landmark nesting (<header>/<footer> อยู่ใน <main>) + สแกน screen-reader/axe/Lighthouse เต็ม. CD รอบนี้ deploy อัตโนมัติปกติ (ไม่มี GitHub outage).
  • คุณภาพ: e2e journey e2e:announcement-upload 26 checks + e2e:training 30 checks; ชุด e2e ทั้ง repo รันกับ NestJS + MSSQL จริงผ่าน DEV_AUTH_BYPASS

สรุปช่วง v0.3.x → v0.9.24 (ปลาย ส.ค. – 8 ก.ย. 2569) — ทั้งหมดอยู่บน UAT แล้ว:

  • Roadmap A–E ครบ: วงจรอบรมเต็ม (เช็คชื่อ → สอบออนไลน์ → ใบรับรอง → ประเมินวิทยากร, V074) · ค่าตอบแทนครบวงจร (เครื่องสถานะ 10 สถานะ + ใบสำคัญ 4 แบบ + bookbank/KTB Corp, Phase C V075) · CMS เว็บไซต์ + รายงานศูนย์ 8 ตระกูล + ชุดรายงาน CSV (Phase D V076) · งานอัตโนมัติรายวัน (แจ้งเตือนใกล้หมดวาระ 90/30 วัน, คิวยุติศูนย์อัตโนมัติ, สรุปผลงานศูนย์) + CR extras + พอร์ทัลสมาชิก (Phase E V077)
  • Workflow Engine ใช้จริง: กล่องงานอนุมัติ / ไทม์ไลน์ / มอบอำนาจ / audit + สายอนุมัติ 7 ลำดับขั้น (V096/V097) ครอบงานรับรองศูนย์ + ทะเบียนผู้ไกล่เกลี่ย · สิทธิ์กลางย้ายเป็น SystemCode RLPD017 (จาก RLPD015) + จำกัดขอบเขตรายจังหวัดของเจ้าหน้าที่ (province scope)
  • พอร์ทัลสมาชิก/ศูนย์: บทบาท CENTER_OWNER/CENTER_MEMBER + work-queue ผู้ไกล่เกลี่ย + แฟ้มผลงาน แนบไฟล์จริง + เบิกค่าจัดกระบวนการ v1 (/compensation/process-cost) · ลงทะเบียนศูนย์สาธารณะ 1:1 กับระบบจริง (V090) + อัปโหลดเอกสาร 5 ช่องจริง (V093)
  • เลขอ้างอิงมาตรฐานกรม 16 หลัก MED YYYY TT PP NNNNN (V100, v0.9.22) · วิซาร์ดสร้างหลักสูตร/ คลังข้อสอบแบบเต็มหน้า + สอบออนไลน์หน้าเดี่ยว + pass-lock (v0.9.23)
  • v0.9.24 (8 ก.ย. 2569): layout เอกสารจริงของ บัตร/หนังสือรับรอง ผ่าน Template Builder (V104) · แบบประเมินวิทยากรปรับแต่งได้ (V103 — เจ้าหน้าที่แก้หัวข้อ/หมวดจาก /training/eval-form) · process-cost v2 — ยื่นเบิกค่าจัดกระบวนการเปิดสายอนุมัติ Workflow wf-process-cost 7 ลำดับขั้นจริง (V101) + ตีกลับแก้ไข + ประธานศูนย์ยื่นเองจาก /mediator/center · menu-IA v2 — ยุบหมวดเมนู "ส่วนขยาย (CR / Phase-2)" เข้าหมวดเจ้าของงาน (ศกช. / ตั้งค่า) และถอดหน้า "แจ้งเตือนหมดอายุ" (/extras/expiry-alert) — การแจ้งเตือนต่ออายุอยู่บนเมนูต่ออายุของเจ้าหน้าที่ (/mediators/renewal
  • ปุ่มส่งแจ้งเตือนรายคน) และหน้าต่อทะเบียนของสมาชิก (/mediator/renewal) · search box มาตรฐานเดียว ทั้งระบบ (SearchField)

บน develop ยังไม่ tag / ยังไม่ขึ้น UAT (ณ 8 ก.ย. 2569):

  • ตำแหน่งหลักในศูนย์เป็น master data (V102 — บังคับกติกา REQ-MED-003 ที่เดิมไม่ได้ enforce) + ลิงก์ & QR เข้าสอบ บน /training/management — งานชุดนี้มี seed-row remap เป็นขั้นตอนตอน deploy (DB บน .155 apply V102 แล้ว)

UAT (ยืนยัน 16 ส.ค. 2569): stack V3 อยู่บน 10.136.27.155 (UAT Devphase2, uat-emediation.rlpd.go.th) — ไม่ใช่ .124 (นั่นคือ V1/V2 legacy). เป็น docker: rlpd-emediation-be/-web (image ghcr.io/rlpdxmfec-devcode/emediation-{be,web}:<git-tag>, CI จาก tag → GHCR → CD), rlpd-mssql (DB PSDBDEVDB schema EMEDIATION), rlpd-minio, rlpd-keycloak (realm rlpd). secrets: credentials/uat_devphase2_sso_secrets.md (ต่อ VPN ก่อน). Deploy gotchas ที่เจอตอน rollout v0.2.7: (1) container ไม่มีไฟล์ .env → npm run migrate พัง รัน node -r ts-node/register src/database/migrate.ts ตรง ๆ; (2) migration ต้องใช้ sa (app login ไม่มีสิทธิ์ DDL); (3) RBAC อ่านจาก PORTAL.AuthzPermissions (SystemCode RLPD017 — ย้ายจาก RLPD015 ตั้งแต่ V087/web_portal V064) cache 5 นาที — แก้ matrix แล้ว restart BE container; action publish ของ people_center_announcement ถูกเพิ่มเข้า source matrix แล้ว (ปิดประเด็น patch UAT ชั่วคราวเดิม).

รายละเอียดทางเทคนิคจาก 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) โดยไม่ต้องสลับเวอร์ชัน

แผนภาพระบบ (Interactive Diagrams)

แผนภาพเชิงโต้ตอบของระบบ S4 Mediation: รองรับการซูม/เลื่อน สลับโหมดมืด–สว่าง ค้นหา component และ export เป็นรูปภาพได้จากในหน้าแผนภาพ (แนะนำให้เปิดแบบเต็มจอ)

สถาปัตยกรรมระบบ (System Architecture)

เปิดแบบเต็มจอ — Architecture

ลำดับการทำงานหลัก (Main Sequence)

เปิดแบบเต็มจอ — Sequence

จุดเชื่อมต่อระบบ (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) อย่างต่อเนื่อง