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

RLPD Phase 2: เวลาและลำดับความสำคัญ

โครงการ: การพัฒนาระบบดิจิทัล Royal Thai Police - ระยะที่ 2 ระยะเวลาสัญญา: 270 วัน นับจากลงนามในสัญญา อัปเดตล่าสุด: 2026-03-25


สรุปผู้บริหาร (Executive Summary)

ระยะ 2 ของ RLPD มีเป้าหมายส่งมอบระบบขั้นต่ำ 5-7 ระบบก่อนเดือนกันยายน 2026 เพื่อตอบสนองเป้าหมาย KPI ของแผนก สัญญามีระยะเวลา 270 วันโดยมีจุดชำระเงินหลัก 4 จุดเชื่อมโยงกับผลลัพธ์ที่สามารถส่งมอบได้ การประสบความสำเร็จขึ้นอยู่กับการจัดลำดับความสำคัญของระบบอย่างแยบคายตามความพยายาม ความเสี่ยง และการพึ่งพาอาศัยองค์กร


จุดชำระเงิน (Contract Milestones) และตารางการชำระเงิน (Payment Schedule)

จุดชำระเงิน วันนับจากการเริ่มต้น กิจกรรม ผลลัพธ์ที่สามารถส่งมอบได้ การชำระเงินกระตุ้น
M1 45 วัน การวิเคราะห์และออกแบบระบบ ขอบเขตข้อกำหนดสุดท้าย เอกสารสถาปัตยกรรม ข้อกำหนดการออกแบบ ชำระเงินครั้งที่ 1
M2 90 วัน (45 วันหลัง M1) การพัฒนา ซอร์สโค้ดเสร็จสมบูรณ์ Unit tests รีวิวโค้ด ชำระเงินครั้งที่ 2
M3 240 วัน UAT + เปิดใช้งานสด การทดสอบการยอมรับของผู้ใช้ การปรับใช้ในสภาพแวดล้อมการผลิต การฝึกอบรม ชำระเงินครั้งที่ 3
M4 270 วัน VA Scan + Pentest + ขั้นสุดท้าย การประเมินความเสี่ยง การทดสอบการเจาะ การลงนามขั้นสุดท้าย ชำระเงินครั้งที่ 4

บริบทเชิงกลยุทธ์ (Strategic Context)

ตัวขับเคลื่อนธุรกิจ (Business Drivers)

  • การฟื้นตัวของ KPI: คะแนนประสิทธิภาพของแผนกลดลงปีที่แล้ว ระบบต้องเปิดใช้งานก่อนวันที่ 30 กันยายน 2026 เพื่อบรรลุเป้าหมายประจำปี
  • เป้าหมายการปรับใช้: ระบบอย่างน้อย 5-7 ระบบใช้งานได้ก่อนเดือนกันยายน 2026
  • เมตริกความสำเร็จ: การส่งมอบระบบหลักตรงเวลาเพื่อช่วยให้สามารถบรรลุวัตถุประสงค์ของแผนก

หลักการจัดลำดับความสำคัญหลัก (Key Prioritization Principle)

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


การจำแนกระบบและชั้นความพยายาม (System Classification & Effort Tiers)

ชัยชนะอย่างรวดเร็ว (Quick Wins - Effort Tier: Low)

ระบบที่พิสูจน์ความสำเร็จในการส่งมอบจากระยะ 1 หรือมีความซับซ้อนน้อยที่สุด

ระบบ ชื่อไทย คำอธิบาย ความพยายาม ประสบการณ์ระยะ 1
S7 ระบบคุ้มครองพยาน ระบบจัดการคุ้มครองพยาน ต่ำ ✓ เร็วที่สุดในระยะ 1
S8 เว็บไซต์ เว็บไซต์ประจำแผนกตำรวจ ต่ำ ✓ เร็วที่สุดในระยะ 1
S9 บันทึกสาธารณะ ระบบเข้าถึงบันทึกและข้อมูลสาธารณะ ต่ำ

ความพยายามมาตรฐาน (Standard Effort - Effort Tier: Medium)

ส่วนผสมของระบบใหม่และการปรับปรุงกระบวนการ ขอบเขตและการดำเนิน สามารถคาดการณ์ได้

ระบบ ชื่อไทย คำอธิบาย ความพยายาม หมายเหตุ
S1 จัดการกรณี ระบบจัดการกรณีอาญา ปานกลาง ใหม่ในระยะ 2
S2 วิเคราะห์อาชญากรรม แพลตฟอร์มวิเคราะห์และสถิติอาชญากรรม ปานกลาง ใหม่ในระยะ 2
S3 จัดการบุคลากร ระบบจัดการบุคลากรและทรัพยากรบุคคล ปานกลาง ใหม่ในระยะ 2
S5 จัดการหลักฐาน ระบบจัดการหลักฐานดิจิทัล ปานกลาง การปรับปรุงจากระยะ 1

ความเสี่ยงสูง (High Risk - Effort Tier: High)

ระบบที่มีความท้าทายทางเทคนิคอย่างมีนัยสำคัญ ซอร์สโค้ดเดิม หรือความซับซ้อนองค์กร

ระบบ ชื่อไทย คำอธิบาย ความพยายาม ปัจจัยความเสี่ยง
S4 บริการไกล่เกลี่ย ระบบไกล่เกลี่ยและแก้ไขข้อพิพาท สูง ความพยายามมากที่สุด ขั้นตอนการทำงานที่ซับซ้อน
S6 OCIPA Compliance การจัดการและการปฏิบัติตามข้อกำหนด OCIPA สูง ปัญหาซอร์สโค้ดเดิม ความเสี่ยงด้านกฎหมาย

Wave 1: ชัยชนะอย่างรวดเร็ว (Target: เดือน 1-3)

เป้าหมาย: สร้างจังหวะและความสำเร็จในระยะเริ่มต้น ความเสี่ยงน้อยที่สุด

  • S7 - ระบบจัดการคุ้มครองพยาน
  • S8 - เว็บไซต์ประจำแผนก
  • S9 - ระบบเข้าถึงบันทึกและข้อมูลสาธารณะ

ผลลัพธ์ที่คาดหวัง: ระบบ 3 ระบบใช้งานได้ ความเชื่อมั่นของทีมได้รับการสร้างตั้ง


Wave 2: ความพยายามมาตรฐาน (Target: เดือน 3-6)

เป้าหมาย: ส่งมอบฟังก์ชันธุรกิจหลัก ส่วนผสมของระบบใหม่และปรับปรุง

  • S1 - ระบบจัดการกรณี
  • S2 - แพลตฟอร์มวิเคราะห์อาชญากรรม
  • S3 - ระบบจัดการบุคลากร
  • S5 - ระบบจัดการหลักฐาน (ปรับปรุง)

ผลลัพธ์ที่คาดหวัง: ระบบ 4 ระบบใช้งานได้ ความสามารถใหม่/ปรับปรุงแบบผสม


Wave 3: ความเสี่ยงสูง (Target: เดือน 6-9)

เป้าหมาย: ดำเนินการระบบที่มีความพยายามและความเสี่ยงสูงด้วยกระบวนการของทีมที่กำหนดไว้แล้ว

  • S4 - ระบบไกล่เกลี่ยและแก้ไขข้อพิพาท
  • S6 - การจัดการและการปฏิบัติตามข้อกำหนด OCIPA

ผลลัพธ์ที่คาดหวัง: ระบบ 2 ระบบใช้งานได้ การดำเนินเสร็จสิ้นของระยะ 2 (ทั้งหมด 7 ระบบ)


ตารางเวลาโครงการแบบลดเบา (Simplified Project Timeline - ASCII Gantt Chart)

``` RLPD Phase 2: 270-วันเวลา ────────────────────────────────────────────────────────────────────

เดือน 1-3: วิเคราะห์ และ ชัยชนะอย่างรวดเร็ว ├─ วัน 0-45: จุดชำระเงิน M1 (การวิเคราะห์และออกแบบระบบ) │ └─ ระบบทั้ง 9: ข้อกำหนด สถาปัตยกรรม ข้อมูลจำเพาะการออกแบบ ├─ Wave 1 การเตรียมการพัฒนา: │ └─ S7, S8, S9: การเตะเท้า และ การวางแผน sprint └─ กิจกรรม: ขอบเขตข้อกำหนดสุดท้าย รีวิวการออกแบบ การจัดสรรทีม

เดือน 3-6: การพัฒนา และ การปรับใช้ Wave 1 ├─ วัน 45-90: จุดชำระเงิน M2 (ระยะการพัฒนา) │ ├─ Wave 1 (S7, S8, S9): เสร็จโค้ด การทดสอบ การเตรียมการ UAT │ └─ Wave 2 (S1, S2, S3, S5): การพัฒนาอยู่ระหว่างดำเนิน ├─ Wave 1 เปิดใช้งานสด: │ └─ S7, S8, S9 → สภาพแวดล้อมการผลิต (ชัยชนะอย่างรวดเร็ว) └─ กิจกรรม: รอบ Sprint รีวิวโค้ด การทดสอบโดยอัตโนมัติ

เดือน 6-8: การปรับใช้ Wave 2 ├─ วัน 90-240: การพัฒนาต่อเนื่อง │ ├─ Wave 2 (S1, S2, S3, S5): การทดสอบ และ UAT │ └─ Wave 3 (S4, S6): การพัฒนาอยู่ระหว่างดำเนิน ├─ Wave 2 เปิดใช้งานสด: │ └─ S1, S2, S3, S5 → สภาพแวดล้อมการผลิต (ใหม่+ปรับปรุง) └─ เป้าหมาย: ระบบทั้งหมด Wave 2 เปิดใช้งานได้ก่อนสิ้นเดือนที่ 8

เดือน 8-9: Wave 3 และ วันชำระเงินตามข้อกำหนด KPI ├─ วัน 240-270: ระยะสุดท้าย และ การแข็งแรง │ ├─ จุดชำระเงิน M3 (UAT + เปิดใช้งานสด) → วัน 240 │ ├─ Wave 3 เปิดใช้งานสด: │ │ └─ S4, S6 → สภาพแวดล้อมการผลิต (ความเสี่ยงสูง) │ └─ จุดชำระเงิน M4 (VA Scan + Pentest + ขั้นสุดท้าย) → วัน 270 └─ สำคัญ: ระบบทั้ง 7 ระบบเปิดใช้งานได้ก่อนวันที่ 30 กันยายน 2026

──────────────────────────────────────────────────────────────────── ```


การพึ่งพาอาศัยระหว่างระบบ และ เหตุผลการเรียงลำดับ (System Interdependencies & Sequencing Rationale)

ทำไมลำดับนี้?

Wave 1 ก่อน: - ไม่มีการพึ่งพาอาศัยระบบอื่นในระบบอื่น - การพิสูจน์การส่งมอบจากระยะ 1 สร้างความเชื่อมั่นของทีม - ช่วยให้มีชัยชนะอย่างรวดเร็วเพื่อสร้างความเชื่อมั่นของผู้เสนอแนวทาง - IT ไม่ใช่เจ้าของหลัก → ความล่าช้าระหว่างแผนกน้อยที่สุด

Wave 2 ที่สอง: - การจัดการกรณี (S1) ให้ข้อมูลพื้นฐานสำหรับวิเคราะห์อาชญากรรม (S2) - การจัดการบุคลากร (S3) อาจส่งข้อมูลไปยังระบบอื่นๆ - ความพยายามมาตรฐานช่วยให้ดำเนินการแบบขนาน - ระบบใหม่หรือปรับปรุงทั้งหมดที่มีความซับซ้อนปานกลาง

Wave 3 สุดท้าย: - ระบบความพยายามสูงได้รับประโยชน์จากประสบการณ์ของทีมใน Waves 1 และ 2 - ความซับซ้อนของไกล่เกลี่ย (S4) ลดลงหลังจากความเข้มแข็งของทีม - ปัญหาซอร์สโค้ดเดิม OCIPA (S6) สามารถจัดการได้ด้วยกระบวนการที่กำหนดไว้ - บัฟเฟอร์เดือนสุดท้ายสำหรับระบบที่สำคัญ


กลยุทธ์การจัดสรรทรัพยากร (Resource Allocation Strategy)

Wave ระยะเวลา ทีม โฟกัส
Wave 1 เดือน 1-3 2-3 หลัก + QA ฐาน การปรับใช้อย่างรวดเร็ว
Wave 2 เดือน 3-6 3-4 + QA + สาขาพื้นฐาน ขยายขนาด กระแสขนาน
Wave 3 เดือน 6-9 4-5 + QA + สนับสนุนเต็มที่ ความท้าทายที่ซับซ้อน การแข็งแรง

วันที่สำคัญ (Critical Dates)

วันที่ เหตุการณ์ สถานะ
วัน 45 จุดชำระเงิน M1 - วิเคราะห์และออกแบบเสร็จสิ้น การชำระเงินกระตุ้น
วัน 90 จุดชำระเงิน M2 - ระยะการพัฒนาเสร็จสิ้น การชำระเงินกระตุ้น
วัน 240 จุดชำระเงิน M3 - UAT และเปิดใช้งานสดเสร็จสิ้น การชำระเงินกระตุ้น
วัน 270 จุดชำระเงิน M4 - ความปลอดภัยขั้นสุดท้าย และการลงนาม ชำระเงินสุดท้าย + สิ้นสุดสัญญา
30 กันยายน 2026 วันชำระเงินตามข้อกำหนด KPI - ระบบขั้นต่ำ 5-7 ระบบเปิดใช้งานได้ เมตริกความสำเร็จทางธุรกิจ

การบรรเทาความเสี่ยง (Risk Mitigation)

ความเสี่ยง การบรรเทา
ความล่าช้าในระบบความเสี่ยงสูง (S4, S6) ตัดสินใจเรียงลำดับสุดท้าย รับประโยชน์จากประสบการณ์ของทีม
ความล่าช้าระหว่างแผนก จัดลำดับความสำคัญระบบเจ้าของ non-IT ก่อน (Wave 1)
ปัญหาซอร์สโค้ดเดิม (S6) จัดสรรนักพัฒนาอาวุโส เริ่มการตรวจสอบด้านเทคนิคใน M1
ความกดดันวันชำระเงินตามข้อกำหนด KPI ส่งมอบระบบ 7 ระบบตรงเวลา Waves 1 และ 2 เสร็จสิ้นเมื่อสิ้นเดือนสิงหาคม
ความขัดแย้งในทรัพยากร การจัดสรรที่ชัดเจนต่อ wave ลดการสลับบริบท

คำถามปลายเปิด (Open Questions)

[OPEN] คำจำกัดความที่เป็นทางการของ "ระบบใช้งานได้" เพื่อวัตถุประสงค์ KPI คืออะไร ต้องใช้ชุดฟีเจอร์เต็ม MVP หรือการลงนามในสภาพแวดล้อมการผลิตหรือไม่

[OPEN] มีการพึ่งพาอาศัยที่ยากจะหลีกเลี่ยงระหว่างระบบที่ต้องการเรียงลำดับใหม่หรือไม่ (เช่น วิเคราะห์อาชญากรรมต้องการการจัดการกรณีเปิดใช้งานสดก่อนหรือไม่)

[OPEN] โมเดลความจุ/ทรัพยากรสำหรับการพัฒนาแบบขนานคืออะไร Wave 2 สามารถเริ่มต้นก่อนที่ Wave 1 เสร็จสิ้นได้หรือไม่

[OPEN] OCIPA (S6) ต้องการ remediation ของซอร์สโค้ดเดิมในระดับใดเพื่อตรงตามมาตรฐานความปลอดภัย/การปฏิบัติตามข้อกำหนด

[OPEN] ใครคือเจ้าของหลัก non-IT สำหรับระบบ Wave 1 พวกเขามีความพร้อมใจสำหรับการทดสอบ/UAT ตามตารางเวลาที่เสนอหรือไม่

[OPEN] มีประตูกฎหมายหรือการปฏิบัติตามข้อกำหนด (เช่น การอนุมัติสำหรับคุ้มครองพยาน OCIPA) ที่อาจส่งผลกระทบต่อเวลาแสดงแคร์หรือไม่

[OPEN] โมเดลสนับสนุนหลังเปิดใช้งานสด (เช่น 30-วันการปรับเสถียรภาพ สนับสนุนตามสัญญา) คืออะไรและมันสอดคล้องกับจุดชำระเงินของสัญญาอย่างไร


ขั้นตอนถัดไป (Next Steps)

  1. การวางแผน M1 (วัน 0-45):
  2. จบรูปแบบข้อกำหนดสำหรับระบบทั้ง 9
  3. ยืนยันการจัดสรรทรัพยากรตามลัก
  4. ตรวจสอบการพึ่งพาอาศัยและการเรียงลำดับ
  5. ตั้งค่าสาขาพื้นฐานด้านเทคนิค (Git, CI/CD, แพลตฟอร์มการทดสอบ)

  6. การเตะเท้า Wave 1 (วัน 30-45):

  7. กำหนดทีมให้กับ S7, S8, S9
  8. รีวิวการออกแบบและการอนุมัติสถาปัตยกรรม
  9. การวางแผน sprint สำหรับการพัฒนา

  10. ดำเนิน:

  11. การติดตามเวลาสัปดาห์ต่อตารางเวลา 270 วัน
  12. อัปเดตผู้เสนอแนวทางรายเดือนเกี่ยวกับความคืบหน้า wave และเส้นทาง KPI
  13. เพิ่มความสำคัญความเสี่ยงสำหรับภัยคุกคามเวลาใด ๆ

เจ้าของเอกสาร: การจัดการโครงการ ตรวจสอบล่าสุด: 2026-03-25 ตรวจสอบครั้งถัดไป: เมื่อลงนามในสัญญา