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

บันทึกการประชุมเตรียมการ (Pre-Kickoff)

โครงการ RLPD Phase 2 - สรุปข้อกำหนดและภาพรวมระบบ

วันที่: 24 มีนาคม 2026 เวลา: [ตามกำหนดการ] สถานที่: ห้องประชุมล็อบบี้ ชั้นที่ 5 อาคาร RLPD กรม IT ผู้บริหารประชุม: คุณ X (ผู้อำนวยการสำนักเทคโนโลยีสารสนเทศ) ผู้เข้าร่วม: [ทีมโครงการ ผู้มีส่วนได้ส่วนเสีย] วาระการประชุม: สรุปข้อกำหนดจาก Phase 1 และภาพรวมระบบที่เกี่ยวข้อง

1. ภาพรวมโครงการและกำหนดเวลา

ข้อกำหนดการเปิดใช้งาน (Go-Live)

  • วันเป้าหมายการเปิดใช้งาน: ก่อนวันที่ 30 กันยายน 2026
  • ระบบขั้นต่ำ: 5 ระบบต้องเปิดใช้งานภายในวันนี้
  • ระบบเป้าหมาย: 7 ระบบ (ในอุดมคติ)
  • ระบบทั้งหมดของสำนัก: 11 ระบบ (ขอบเขตของเรา: 9 ระบบ)

ตัวขับเคลื่อนทางธุรกิจ

คะแนน KPI ของสำนักลดลงในปีที่ผ่านมา การส่งมอบระบบเหล่านี้ภายในสิ้นเดือนกันยายนเป็นสิ่งสำคัญต่อการปรับปรุงประสิทธิภาพ

ขอบเขตโครงการ

  • เส้นทางวิกฤติ: การได้รับข้อกำหนดคาดว่าจะใช้เวลามากที่สุด
  • กลยุทธ์การจัดลำดับความสำคัญ: ควรจัดลำดับความสำคัญระบบที่สำนัก IT ไม่ใช่เจ้าของอันดับแรก (ระบบเหล่านี้ต้องการการประสานงานภายนอกและเวลานำที่นานขึ้น)

2. ข้อกำหนดโครงสร้างพื้นฐาน (Infrastructure) และเครือข่าย

การจัดการโดเมน

  • โดเมนหลัก: GDCC Domain (จัดการโดยสำนัก IT)
  • โดเมนย่อย: พร้อมใช้งานผ่านการร้องขอสำนัก IT

ข้อกำหนดไฟร์วอลล์

  • การไหลของข้อมูลเข้า (Inbound Traffic): ต้องแจ้งเตือน สป. (ทีมเครือข่าย/ความปลอดภัย) เพื่อขอการอนุมัติรายการอนุญาต
  • ข้อจำกัด: บางครั้งจำกัดเฉพาะ 10 Public IPs
  • ต้องมีข้อกำหนดข้อกำหนดการไหลอย่างละเอียด
  • การไหลของข้อมูลออก (Outbound Traffic): ยังไม่ได้บล็อก
  • รายการสิ่งที่ต้องทำ: แจ้งเตือน สป. ด้วยข้อกำหนดไฟร์วอลล์โดยละเอียดตั้งแต่เริ่มต้นโครงการ

สถาปัตยกรรมฐานข้อมูล

  • ระบบใหม่: ยังไม่อยู่ใน Single DB
  • สถาปัตยกรรมเป้าหมาย: ตามที่ระบุใน TOR ระบบจะรวมเข้ากับฐานข้อมูล MSSQL เดียว

การบูรณาการ SMS

  • ผู้ให้บริการ: ThaiBox
  • สำหรับ: การแจ้งเตือนและการสื่อสารของระบบ

3. ข้อกำหนดและข้อเสีย ตามระบบ

S1: ระบบการให้ความปรึกษาทางกฎหมาย (กพส.)

เจ้าของ: [เพื่อกำหนด] สแตก Technology: [เพื่อกำหนด] ข้อกำหนดหลัก: - ต้องเป็นแบบ Standalone จาก OCIPA (S6) — ไม่มีการจับคู่โดยตรง - แหล่งที่มาของข้อมูล: - Syncs FROM: "OCIPA ยื่นออนไลน์" และ "รับเรื่องร้องเรียนร้องทุกข์" (ระบบย่อยของ OCIPA) - Syncs TO: S5 (ทดแทนค่า 134/1) สำหรับการกำหนดทนายความ - เส้นทางวิกฤติ: ขึ้นอยู่กับความพร้อมของข้อมูล OCIPA (S6)

รายการสิ่งที่ต้องทำ: - [ ] กำหนดความถี่การ Sync และรูปแบบข้อมูลจากระบบแหล่งที่มา OCIPA - [ ] ชี้แจงการไหลของข้อมูลกับ S5 สำหรับการกำหนดทนายความ

S2: PJOS

เจ้าของ: [เพื่อกำหนด] สถานะ: ระบบใหม่ ระดับความกังวล: ต่ำ — ไม่ค่อยมีข้อกังวลในขั้นนี้เมื่อเทียบกับระบบอื่น ขั้นตอนต่อไป: การรวบรวมข้อกำหนดจะดำเนินการตามกำหนดเวลามาตรฐาน

S3: ระบบรายงานกิจกรรม (กสส.)

เจ้าของ: [เพื่อกำหนด] สแตก Technology: ใช้ Windows (ต้องผสานรวม Active Directory) ข้อกำหนดหลัก: - การบูรณาการ: ต้องผูกกับ RLPD Active Directory เพื่อการตรวจสอบสิทธิ์และอนุญาต - แหล่งข้อมูล: humanright_file (ต้องมีการเข้าถึงและเอกสาร) - ประวัติการใช้: ผู้รับเหมาก่อนหน้านี้มีระบบรายงานที่มีอยู่แล้ว ประเมินเพื่อนำมาใช้ซ้ำหรือสร้างใหม่

รายการสิ่งที่ต้องทำ: - [ ] ยืนยันสถานะและข้อกำหนดการบูรณาการ Active Directory - [ ] ขอการเข้าถึง humanright_file ที่มา และเอกสาร - [ ] ประเมินระบบรายงานของผู้รับเหมาก่อนหน้านี้เพื่อความเป็นไปได้ในการนำมาใช้ซ้ำ

S4: ระบบการเบี่ยงเบนข้อพิพาท (กสร.)

เจ้าของ: [เพื่อกำหนด] สถานะ: ความพยายามสูงที่สุด — ระบบที่ซับซ้อนและสำคัญที่สุด ความซับซ้อนหลัก: - สองเวอร์ชัน Live: - เวอร์ชัน 1: เปิดตัว 2563 (2020) — ยังคงใช้งานอยู่ - เวอร์ชัน 2: เปิดตัว 2565 (2022) — ยังคงใช้งานอยู่ - ผู้ใช้ต้องเปลี่ยนเวอร์ชันด้วยตนเองระหว่างเวอร์ชันสำหรับฟังก์ชันต่างๆ - คำขอของผู้มีส่วนได้ส่วนเสีย: รวมเวอร์ชันทั้งสองเข้ากับระบบเดียว - ขอบเขต TOR ปัจจุบัน: จำกัดเฉพาะ "เพิ่มเมนู" — ไม่เพียงพอสำหรับความต้องการของผู้มีส่วนได้ส่วนเสีย

การประเมินคุณวุฒิที่สำคัญ: - การศึกษาความเป็นไปได้: เป็นไปได้หรือไม่ที่จะรวม v1 และ v2 ภายในกำหนดเวลาและงบประมาณของโครงการ? - เส้นทางอื่น: หากการรวมไม่เป็นไปได้ วิธีแก้ปัญหาระดับกลางขั้นต่ำใดที่ตรงกับความต้องการของผู้มีส่วนได้ส่วนเสีย? - ความเข้ากันได้ของข้อมูล: ตรวจสอบว่าไม่มีการสูญหายของข้อมูลเมื่อหรือหากรวมฐานข้อมูล

รายการสิ่งที่ต้องทำ: - [ ] ลำดับความสำคัญ: กำหนดเวลาการประเมินความเป็นไปได้สำหรับการรวม S4 เวอร์ชัน - [ ] รับข้อกำหนดสำหรับ v1 และ v2 - [ ] สัมภาษณ์ผู้ใช้หลักเกี่ยวกับปัญหาการเปลี่ยนเวอร์ชัน - [ ] ให้คำแนะนำภายในสองสัปดาห์: การรวมเทียบกับการสนับสนุนที่แยกจากกัน

S5: ระบบทดแทนค่าสินไหม 134/1 (กพส.)

เจ้าของ: [เพื่อกำหนด] ฟังก์ชันที่สำคัญ: - ระบบลงทะเบียนทนายความฟรี - การเรียกร้องและการประมวลผลการชำระเงิน - ปลายทางการ Sync ข้อมูลจาก S1 (การกำหนดทนายความ)

ปัญหาที่ทราบ: - ปัญหาการชำระเงินซ้ำ: ระบบมีปัญหาการชำระเงินซ้ำบ่อยครั้ง — ต้องตรวจสอบสาเหตุรากที่แท้จริงและแก้ไข - การตรวจสอบใบรับรองทนายความ: ปัจจุบันมีกระบวนการ Batch ผ่าน Excel (ด้วยตนเอง ไม่ใช่แบบ Real-time) - ความเสี่ยง: ความล่าช้าในการตรวจสอบ มีแนวโน้มที่จะเกิดข้อผิดพลาด - ปรับปรุงที่จำเป็น: กระบวนการตรวจสอบแบบ Real-time หรือ Automated

รายการสิ่งที่ต้องทำ: - [ ] ตรวจสอบปัญหาการชำระเงินซ้ำ — ระบุสาเหตุรากที่แท้จริง - [ ] ประเมินความเป็นไปได้ของการตรวจสอบใบรับรองทนายความแบบ Real-time (เทียบกับกระบวนการ Batch Excel) - [ ] กำหนดรูปแบบข้อมูลสำหรับการ Sync การกำหนดทนายความจาก S1

S6: ระบบ OCIPA (สชง.)

เจ้าของ: [เพื่อกำหนด] สแตก Technology: C# .NET, IIS, MSSQL สถานะปัจจุบัน: ความเสี่ยงสูง - การจัดการโค้ดต้นฉบับ: เก็บไว้เป็นไฟล์ ไม่อยู่ในการควบคุมเวอร์ชัน Git - ปัญหาวิกฤติ: โค้ดต้นฉบับบางส่วนไม่คอมไพล์ - ต้องดำเนินการทันที: ตรวจสอบและแก้ไข - ปัญหาความสมบูรณ์ของข้อมูล: ไม่สามารถตัดสินใจเปิดการส่งสัญญาณสถานะแบบ rollback ได้ การเปลี่ยนแปลงต้องแก้ไข DB โดยตรง (ต้องการการแทรกแซงด้วยตนเอง) - ปัญหาประสิทธิภาพ: การ Query ขนาดใหญ่หมดเวลา - Scope Creep: ระบบย่อยบางระบบที่ไม่เกี่ยวข้องกับ OCIPA ถูก Parked ที่นี่และควรย้ายไป

แหล่งข้อมูลสำหรับระบบอื่น: - S1 (ระบบการให้ความปรึกษาทางกฎหมาย) Syncs FROM ระบบย่อย OCIPA: - "OCIPA ยื่นออนไลน์" - "รับเรื่องร้องเรียนร้องทุกข์"

รายการสิ่งที่ต้องทำ: - [ ] ลำดับความสำคัญ: ตรวจสอบโค้ดต้นฉบับ S6 — ระบุปัญหาการคอมไพล์และประมาณความพยายามในการแก้ไข - [ ] ตั้งค่า Git Repository และนำเข้าโค้ดต้นฉบับอย่างถูกต้อง - [ ] สร้างเอกสารกระบวนการ Rollback สถานะและสร้างใหม่เพื่ออนุญาต Rollback DB ที่เหมาะสม - [ ] วิเคราะห์ Query ขนาดใหญ่และใช้การ Optimization - [ ] ระบุระบบย่อยที่ควรลบออกจาก S6 และย้ายไป

S7: ระบบคุ้มครองพยาน (สคพ.)

เจ้าของ: [เพื่อกำหนด] ผู้รับเหมา: ผู้รับเหมาคนเดียวกับ S8 สถานะ: คาดว่าจะรวดเร็ว/เรียบง่าย ที่มา: การประเมินเชิงบวกระหว่าง Phase 1 ขั้นตอนต่อไป: กระบวนการรวบรวมข้อกำหนดและพัฒนาตามกำหนดเวลามาตรฐาน

S8: เว็บไซต์ (IT)

เจ้าของ: สำนัก IT สแตก Technology: C# .NET, IIS, CMS ตำแหน่งแหล่งที่มา: rlpd_web (ต้องมีการเข้าถึง) ข้อกำหนดหลัก: - UI/UX: เลาต์เอาต์การเลื่อนแนวตั้ง (เทียบกับการนำทางแนวนอนแบบดั้งเดิม) - ฟังก์ชัน CMS: จำเป็นต้องมีความสามารถในการแก้ไข Navbar แบบ Dynamic - ความสามารถในการเข้าถึง: ต้องสอดคล้องกับมาตรฐาน WCAG (ตามที่ระบุใน TOR 7.18.2 — Level AA)

รายการสิ่งที่ต้องทำ: - [ ] ขอการเข้าถึง rlpd_web Source Repository - [ ] ชี้แจงข้อกำหนด WCAG Level AA ที่เฉพาะเจาะจง - [ ] รับข้อกำหนด CMS สำหรับการแก้ไข Dynamic Navbar - [ ] ตรวจสอบแบบร่าง Design สำหรับเลาต์เอาต์การเลื่อนแนวตั้ง

S9: ระบบพอร์ทัล Web

เจ้าของ: [เพื่อกำหนด] สถาปัตยกรรมหลัก: - S1 Embedded: S1 (ระบบการให้ความปรึกษาทางกฎหมาย) จะถูก Embed ภายใน S9 - การบูรณาการ: ตรวจสอบการ Framing/Embedding ที่เหมาะสมโดยไม่สูญหายฟังก์ชันality

รายการสิ่งที่ต้องทำ: - [ ] กำหนดข้อกำหนด Embedding และการบูรณาการ UI/UX กับ S9 - [ ] ชี้แจงนำทาง Portal และการไหลของผู้ใช้ระหว่าง S9 และ S1 ที่ Embed

4. การเข้าถึง Infrastructure และ Security

การตั้งค่าข้อมูลประจำตัวและการเข้าถึง

เจ้าของ: คุณ X (ผู้อำนวยการสำนัก IT) รายการที่จำเป็น: - ข้อมูลประจำตัวการเข้าถึง VPN - ข้อมูลประจำตัวฐานข้อมูล (อ่าน/เขียน สภาพแวดล้อมการพัฒนา) - การเข้าถึง Source Code Repository (ระบบทั้งหมด) - ข้อมูลประจำตัว Service Account

รายการสิ่งที่ต้องทำ: - [ ] จำเป็น: ขอข้อมูลประจำตัว VPN และการพัฒนาจาก คุณ X - [ ] ขอการเข้าถึง Source Code สำหรับระบบทั้ง 9 - [ ] รับ Database Connection Strings และข้อมูลประจำตัว (สภาพแวดล้อมการพัฒนาเท่านั้น)

การประเมินความเสี่ยง (VA Scan)

หน่วยงานที่รับผิดชอบ: สกมช (องค์กรความปลอดภัย) กระบวนการ: - VA Scan ใช้เวลาประมาณ 1 เดือนจากการแจ้งเตือน - ต้องแจ้งเตือน สกมช ของความตั้งใจเร็วๆ นี้ — จำเป็นต้องตามที่ระบุใน TOR 7.23 - ทางเลือก: ติดต่อผู้ให้บริการ VA Vendor บุคคลที่สาม (หากต้องการกำหนดเวลาเร็วขึ้น) - หมายเหตุ: Penetration Testing ใช้เวลานานขึ้น อาจไม่พอดี Phase 2 Timeline

รายการสิ่งที่ต้องทำ: - [ ] แจ้งเตือน สกมช ของความตั้งใจ VA Scan และกำหนดเวลาที่คาดหวัง (ตามที่ระบุใน TOR 7.23) - [ ] ระบุและงบประมาณผู้ให้บริการ VA Vendor บุคคลที่สามที่ได้รับการรับรอง เป็นตัวเลือกสำรอง - [ ] กำหนดเวลา VA Scan สำหรับขั้นหลังการพัฒนา ก่อน Go-live

5. การตัดสินใจที่สำคัญและข้อจำกัด

กฎการจัดลำดับความสำคัญ

ระบบที่สำนัก IT ไม่ใช่เจ้าของควรจัดการเป็นอันดับแรก (วัฏจักรการประสานงานภายนอกที่นานนาน)

การตัดสินใจสถาปัตยกรรม

  • Single Database (MSSQL) วิธีการตามที่ระบุใน TOR 7.1 และ 6.4
  • สถาปัตยกรรม Micro Service + API ตามที่ระบุใน TOR 7.3
  • ระบบทั้งหมดต้องบูรณาการเข้ากับ Single DB (ระบบใหม่ยังไม่ได้โยกย้าย)

ลำดับการพึ่งพา

  1. การประเมินความเป็นไปได้ S4 (ซับซ้อนที่สุด)
  2. การตรวจสอบและแก้ไขโค้ดต้นฉบับ S6 (ความเสี่ยงสูงสุด)
  3. ยืนยันการบูรณาการ Active Directory S3
  4. การตรวจสอบปัญหาการชำระเงินซ้ำ S5
  5. การเข้าถึง Infrastructure & ตั้งค่าไฟร์วอลล์ (แทร็ก Parallel)

6. รายการค้างและความเสี่ยง

รายการ เจ้าของ สถานะ วันเป้าหมาย
ขอข้อมูลประจำตัว/VPN Khun X Khun X ค้าง โดยเร็วที่สุด
แจ้งเตือน Firewall Whitelist สป. Project Lead ค้าง ก่อน Dev Start
การศึกษาความเป็นไปได้ S4 (การรวมเวอร์ชัน) TBD ค้าง ภายใน 2 สัปดาห์
ตรวจสอบโค้ดต้นฉบับ S6 TBD ค้าง ภายใน 1 สัปดาห์
ยืนยันการบูรณาการ AD S3 TBD ค้าง ภายใน 1 สัปดาห์
แจ้งเตือน VA Scan สกมช Project Lead ค้าง ตามที่ระบุใน TOR 7.23
กำหนดเวลาประชุม Kickoff อย่างเป็นทางการ Admin ค้าง สัปดาห์ต่อไป

7. ขั้นตอนต่อไปและการติดตามผล

  1. ทันที (สัปดาห์นี้):
  2. ขอข้อมูลประจำตัวจาก Khun X
  3. กำหนดเวลาการประชุมประเมินความเป็นไปได้ S4
  4. กำหนดเจ้าของแต่ละระบบ

  5. เริ่มตรวจสอบโค้ดต้นฉบับ S6

  6. สัปดาห์ต่อไป:

  7. นำเสนอผลการตรวจสอบ S6
  8. นำเสนอคำแนะนำการประเมินความเป็นไปได้ S4
  9. แจ้งเตือน สป. (ทีมไฟร์วอลล์) ด้วยข้อกำหนดโดยละเอียด

  10. แจ้งเตือน สกมช (ทีมความปลอดภัย) ของความตั้งใจ VA Scan

  11. ภายใน 2 สัปดาห์:

  12. ยืนยันการให้สิทธิ์เข้าถึง Infrastructure ทั้งหมด
  13. ยืนยันลำดับความสำคัญของระบบตามการประเมินความเป็นไปได้
  14. กำหนดเวลาการประชุม Kickoff โครงการอย่างเป็นทางการ

บันทึกการประชุมเตรียมโดย: [ชื่อ/ตำแหน่ง] วันที่เตรียม: 24 มีนาคม 2026 배포: ทีมโครงการ ผู้มีส่วนได้ส่วนเสีย บริหารงาน RLPD