lcbp3/specs/00-overview/00-04-stakeholder-signoff-and-risk.md

# 📋 Stakeholder Sign-off & Risk Management — LCBP3-DMS v1.8.0

---

title: 'Stakeholder Sign-off Process & Risk Register'
version: 1.0.0
status: DRAFT — Awaiting Stakeholder Review
owner: Nattanin Peancharoen (Product Owner / System Architect)
last_updated: 2026-03-11
related:

- specs/01-Requirements/01-05-acceptance-criteria.md
- specs/01-Requirements/01-04-user-stories.md
- specs/00-Overview/00-06-training-plan.md
- specs/06-Decision-Records/ADR-016-security-authentication.md

---

> [!IMPORTANT]
> เอกสารนี้ต้องได้รับการ **Sign-off จากตัวแทนทุกองค์กร** ก่อนที่ระบบจะ Go-Live สู่ Production  
> การ Sign-off ถือเป็นการยืนยันว่าองค์กรรับทราบ Scope, Risks, และพร้อมรับผิดชอบ UAT ในส่วนของตน

---

## ส่วนที่ 1: Stakeholder Sign-off Process

### 1.1 วัตถุประสงค์

การ Sign-off Process ทำหน้าที่:

1. **ยืนยัน Scope** — ทุกฝ่ายเห็นชอบ Feature ที่จะส่งมอบใน MVP
2. **ยืนยัน UAT Criteria** — เห็นชอบเกณฑ์การพิจารณาว่า "ผ่าน" คืออะไร (อ้างอิง `01-05-acceptance-criteria.md`)
3. **ยืนยัน Go-Live Readiness** — แต่ละองค์กรยืนยันว่าทีมพร้อม (Training, Data, User Access)
4. **รับทราบ Risks** — รับทราบความเสี่ยงที่อาจเกิดขึ้น และ Mitigation Plan

---

### 1.2 Stakeholder Registry

| #   | Organization                       | บทบาทในโครงการ          | บทบาทในระบบ DMS             | ตัวแทน Sign-off |
| --- | ---------------------------------- | ----------------------- | --------------------------- | --------------- |
| 1   | **กทท.** (การท่าเรือแห่งประเทศไทย) | Project Owner           | System Owner, ผู้ใช้ระดับบน | TBD             |
| 2   | **สค.** (สำนักงานโครงการ)          | Project Management      | Org Admin, Document Control | TBD             |
| 3   | **TEAM** (ที่ปรึกษาออกแบบ)         | Design Consultant       | Document Control, Reviewer  | TBD             |
| 4   | **คคง.** (คณะกรรมการตรวจงาน)       | Construction Supervisor | Reviewer, Approver          | TBD             |
| 5   | **ผรม.** (ผู้รับจ้างหลัก)          | Main Contractor         | Document Control, Submitter | TBD             |
| 6   | **NAP** (ผู้พัฒนาระบบ)             | System Developer        | Superadmin, Support         | Nattanin P.     |

---

### 1.3 Sign-off Workflow

```
Phase 1: Pre-Sign-off Review (T-3 สัปดาห์ก่อน Go-Live)
┌─────────────────────────────────────────────────────────┐
│  NAP ส่งร่างเอกสารนี้ให้ตัวแทนทุกองค์กรรีวิว            │
│  + ส่ง Acceptance Criteria (01-05) ควบคู่               │
│  + นัด Review Meeting (1 ชั่วโมง) กับทุกฝ่าย             │
└─────────────────────────────────────────────────────────┘
              ↓
Phase 2: Clarification (T-2 สัปดาห์)
┌─────────────────────────────────────────────────────────┐
│  แต่ละองค์กรส่ง Comments / ข้อสงสัย กลับมา             │
│  NAP ตอบและปรับปรุงเอกสาร (ถ้าจำเป็น)                  │
│  ระบุ Open Issues และ Resolution                        │
└─────────────────────────────────────────────────────────┘
              ↓
Phase 3: UAT (T-2 ถึง T-1 สัปดาห์)
┌─────────────────────────────────────────────────────────┐
│  แต่ละองค์กรทดสอบบน Staging ตาม AC Scenarios           │
│  Internal Trainer นำทีมทำ Hands-on Scenario 1-3        │
│  บันทึก Issues ใน Bug Tracker                           │
└─────────────────────────────────────────────────────────┘
              ↓
Phase 4: Sign-off (T-1 สัปดาห์)
┌─────────────────────────────────────────────────────────┐
│  ทุก P0/P1 Issues ถูก Fix แล้ว                         │
│  P2/P3 Issues มี Workaround หรือ Timeline Fix           │
│  ตัวแทนแต่ละองค์กรลงนาม (Section 1.5)                  │
└─────────────────────────────────────────────────────────┘
              ↓
Go-Live ✅
```

---

### 1.4 Sign-off Criteria (เกณฑ์การอนุมัติ)

**ต้องผ่านทั้งหมดก่อน Sign-off:**

#### Functional Requirements

- [ ] AC-AUTH-001~005 ผ่าน (Authentication)
- [ ] AC-ADMIN-001~005 ผ่าน (User & Org Management)
- [ ] AC-CORR-001~002 ผ่าน (Correspondence Core)
- [ ] AC-RFA-001~003 ผ่าน (RFA Core)
- [ ] AC-WF-001~003 ผ่าน (Workflow Engine)
- [ ] AC-DN-001 ผ่าน (Document Number Concurrent)
- [ ] AC-STOR-001 ผ่าน (File Storage + ClamAV)

#### Security & Compliance

- [ ] AC-SEC-001~005 ผ่าน (OWASP Top 10 Security)
- [ ] AC-AUDIT-001 ผ่าน (Audit Log Coverage)
- [ ] Penetration Test ผ่าน (Pre Go-Live)

#### Performance

- [ ] AC-PERF-001 ผ่าน (Response Time < 200ms P90)
- [ ] AC-PERF-003 ผ่าน (Doc Number Concurrent Safe)

#### Operations

- [ ] AC-DATA-001 ผ่าน (Backup & DR Test)
- [ ] Monitoring Stack ทำงาน (Grafana แสดง Metrics)
- [ ] Alerting ตั้งค่าแล้ว (PagerDuty/Slack หรือ LINE)

#### Readiness

- [ ] Training ทุก Role เสร็จแล้ว (>90% Attendance)
- [ ] User Accounts ทุกองค์กรสร้างแล้ว
- [ ] Support LINE Group พร้อม
- [ ] ไม่มี Open P0/P1 Issues

---

### 1.5 🖊️ Stakeholder Sign-off Table

> **คำชี้แจง:** การลงนามในตารางนี้หมายถึง ตัวแทนองค์กรได้อ่าน รับทราบ และเห็นชอบกับ:
>
> 1. Feature Scope ของ LCBP3-DMS v1.8.0 ตามที่อธิบายใน `specs/01-Requirements/`
> 2. Acceptance Criteria ตามที่กำหนดใน `01-05-acceptance-criteria.md`
> 3. Risk Register และ Mitigation Plan ในเอกสารนี้ (ส่วนที่ 2)
> 4. ยืนยันว่าทีมงานขององค์กรได้รับการ Training และพร้อม Go-Live

| Organization | ตัวแทน      | ตำแหน่ง          | ลายมือชื่อ | วันที่ | หมายเหตุ |
| ------------ | ----------- | ---------------- | ---------- | ------ | -------- |
| **กทท.**     |             |                  |            |        |          |
| **สค.**      |             |                  |            |        |          |
| **TEAM**     |             |                  |            |        |          |
| **คคง.**     |             |                  |            |        |          |
| **ผรม.**     |             |                  |            |        |          |
| **NAP**      | Nattanin P. | System Architect |            |        |          |

**เงื่อนไข Go-Live:**

- ต้องได้รับ Sign-off จากอย่างน้อย **4 จาก 5 องค์กร** (กทท., สค., TEAM, คคง./ผรม. อย่างน้อย 1)
- กทท. **ต้องลงนาม** ในฐานะ Project Owner (Mandatory)
- หาก < 4 ลายเซ็น → ต้องนัด Emergency Review ก่อน Go-Live

---

### 1.6 Open Issues Log (Pre Sign-off)

> เพิ่ม Issues ที่พบระหว่าง UAT ที่นี่ ก่อน Sign-off

| #   | Issue                              | Priority | หน่วยงานที่พบ | Status | Resolution / Timeline |
| --- | ---------------------------------- | -------- | ------------- | ------ | --------------------- |
| —   | _ยังไม่มี Issue (UAT ยังไม่เริ่ม)_ | —        | —             | —      | —                     |

---

## ส่วนที่ 2: Risk Management

### 2.1 Risk Assessment Matrix

```
           │  ผลกระทบ (Impact)
           │  ต่ำ (1)   ปานกลาง (2)   สูง (3)   วิกฤต (4)
───────────┼────────────────────────────────────────────────
โอกาส  สูง │   🟡 M        🟠 H         🔴 C       🔴 C
เกิด   กลาง│   🟢 L        🟡 M         🟠 H       🔴 C
(Prob) ต่ำ │   🟢 L        🟢 L         🟡 M       🟠 H

🔴 C = Critical  🟠 H = High  🟡 M = Medium  🟢 L = Low
```

| Level       | Action Required                     |
| ----------- | ----------------------------------- |
| 🔴 Critical | แก้ก่อน Go-Live — Blocker           |
| 🟠 High     | ต้องมี Mitigation Plan ก่อน Go-Live |
| 🟡 Medium   | ต้องมี Contingency Plan             |
| 🟢 Low      | Monitor + Document                  |

---

### 2.2 Risk Register

#### 🔴 CRITICAL — ต้องแก้ก่อน Go-Live

---

**RISK-001: ผู้ใช้ปฏิเสธการเปลี่ยนแปลง (User Adoption Failure)**

| Attribute         | Detail                                                  |
| ----------------- | ------------------------------------------------------- |
| **Category**      | People / Change Management                              |
| **Probability**   | สูง (3) — คนที่คุ้นชิน Email มักต้านระบบใหม่            |
| **Impact**        | วิกฤต (4) — ระบบดีแค่ไหนก็ไร้ประโยชน์ถ้าคนไม่ใช้        |
| **Level**         | 🔴 Critical (3×4=12)                                    |
| **Trigger Signs** | Login Rate < 50% ในสัปดาห์แรก, Support Tickets > 30/วัน |

**Mitigation (ก่อน Go-Live):**

- Training ทุก Role ครบตาม `00-06-training-plan.md`
- Train-the-Trainer ทุกองค์กร (Internal Champion)
- Demo Session ก่อน Go-Live: แสดงว่าระบบช่วยลดงานจริง
- ผู้บริหารทุกองค์กร Endorse การใช้ระบบใหม่อย่างเป็นทางการ

**Contingency (ถ้าเกิดขึ้น):**

- Hypercare Period: เพิ่ม NAP On-site Support 1 สัปดาห์แรก
- "Buddy System": Internal Trainer นั่งข้างๆ User ใหม่ 2-3 วันแรก
- Quick Win Campaign: รางวัล/การยอมรับสำหรับ "First 10 Submitters"

**Owner:** Nattanin P. + Internal Trainers ทุกองค์กร

---

**RISK-002: Data Migration Legacy ผิดพลาดหรือล่าช้า**

| Attribute         | Detail                                                  |
| ----------------- | ------------------------------------------------------- |
| **Category**      | Technical / Data                                        |
| **Probability**   | สูง (3) — ข้อมูลเก่ามักมี Format ไม่สม่ำเสมอ            |
| **Impact**        | สูง (3) — เอกสารเก่าหาย/ผิด → ความน่าเชื่อถือระบบลดลง   |
| **Level**         | 🔴 Critical (3×3=9)                                     |
| **Trigger Signs** | Migration Error Rate > 5%, Duration > กำหนด + 2 สัปดาห์ |

**Mitigation (ก่อน Go-Live):**

- กำหนด Legacy Data Scope ที่ชัดเจน (ดู Gap 7): วันที่เริ่มต้น, ประเภทเอกสาร
- Test Migration บน Staging ก่อน (Dry Run 3 รอบ)
- Validation Script ตรวจ Record Count + Sample Check หลัง Migrate
- เก็บ Legacy System ไว้ Read-only อย่างน้อย 3 เดือน

**Contingency (ถ้าเกิดขึ้น):**

- Rollback Plan: เปิด Legacy System กลับมา Operate แบบ Parallel
- Manual Entry Team: กำหนดทีม Manual Key-in เอกสาร Critical ที่ Migrate ไม่ได้
- Timeline Extension: เลื่อน Go-Live ได้สูงสุด 4 สัปดาห์ ถ้า Migration ล้มเหลว > 20%

**Owner:** Nattanin P. (Migration Lead) + สค. (Data Provider)

---

**RISK-003: Security Breach / Unauthorized Access**

| Attribute         | Detail                                                          |
| ----------------- | --------------------------------------------------------------- |
| **Category**      | Security                                                        |
| **Probability**   | ต่ำ (1) — Internal Network, Authentication แข็ง                 |
| **Impact**        | วิกฤต (4) — ข้อมูลโครงการ Confidential รั่วไหล                  |
| **Level**         | 🟠 High (1×4=4) → **ยก Priority เพราะ Impact สูงมาก**           |
| **Trigger Signs** | Failed Login Spike, Unauthorized 403 Burst, File Access Anomaly |

**Mitigation (ก่อน Go-Live):**

- Penetration Test โดยทีมภายนอก ก่อน Go-Live
- Security Checklist `ADR-016` ผ่านทั้งหมด
- ClamAV Virus Scan ทุกไฟล์อัปโหลด
- Network Isolation: Backend ไม่ expose ตรงสู่ Internet
- JWT + CASL RBAC + Helmet.js + Rate Limiting ครบ

**Contingency (ถ้าเกิดขึ้น):**

- Incident Response Plan: ปิดระบบ + แจ้ง กทท. ภายใน 1 ชั่วโมง
- Audit Log ทุก Access → ตรวจ Forensics ได้
- Password Reset Force ทุก User ที่อาจได้รับผลกระทบ
- แจ้ง DPA (PDPA Compliance) ถ้าข้อมูลส่วนบุคคลรั่วไหล

**Owner:** Nattanin P. (Security) + กทท. IT (Infrastructure)

---

#### 🟠 HIGH — ต้องมี Mitigation Plan ก่อน Go-Live

---

**RISK-004: Infrastructure Downtime (QNAP / Docker)**

| Attribute         | Detail                                              |
| ----------------- | --------------------------------------------------- |
| **Category**      | Infrastructure / Operations                         |
| **Probability**   | กลาง (2) — Hardware ล้มเหลวได้                      |
| **Impact**        | สูง (3) — ระบบใช้งานไม่ได้ ส่งผลต่อ Deadline เอกสาร |
| **Level**         | 🟠 High (2×3=6)                                     |
| **Trigger Signs** | Uptime Alert < 99.5%, Container Crash, Disk Full    |

**Mitigation:**

- Docker Health Check + Auto-restart Policy ทุก Container
- Monitoring: Prometheus + Grafana Alerts (Slack/LINE)
- Database Backup ทุกวัน (MariaDB Dump + Volume Snapshot)
- RTO < 4 ชั่วโมง, RPO < 1 ชั่วโมง ตาม ADR-015

**Contingency:**

- ASUSTOR NAS พร้อม Rollover ถ้า QNAP ล้ม (Manual Process)
- Runbook: `specs/04-Infrastructure-OPS/` สำหรับ Common Failure Scenarios
- Emergency Contact: ทีม QNAP Support + NAP On-call

**Owner:** Nattanin P. (DevOps) + กทท. IT (Hardware)

---

**RISK-005: Workflow DSL Configuration ผิดพลาด**

| Attribute         | Detail                                                      |
| ----------------- | ----------------------------------------------------------- |
| **Category**      | Technical / Configuration                                   |
| **Probability**   | กลาง (2) — DSL ซับซ้อน, Config เยอะ                         |
| **Impact**        | สูง (3) — Workflow เดินผิด → เอกสารติดอยู่ในระบบ            |
| **Level**         | 🟠 High (2×3=6)                                             |
| **Trigger Signs** | Workflow State ไม่เปลี่ยน, User ร้องเรียนว่า Approve ไม่ได้ |

**Mitigation:**

- UAT ทดสอบ Workflow ทุก Document Type จนครบ (ตาม AC-WF-001~006)
- Force Proceed สำหรับ Document Control เป็น Safety Valve
- Workflow DSL ถูก Version Control (Git) → Rollback ได้
- Unit Test ครอบคลุม Transition ทุก State ใน DSL

**Contingency:**

- Force Proceed: Document Control ข้าม Step ที่ติดขัดได้ทันที
- Admin สามารถ Edit Workflow Definition + Force Re-evaluate ได้
- Hotfix Deploy ภายใน 24 ชั่วโมง สำหรับ Bug Priority P1

**Owner:** Nattanin P. (Workflow Dev)

---

**RISK-006: Document Number Duplication (Race Condition)**

| Attribute         | Detail                                            |
| ----------------- | ------------------------------------------------- |
| **Category**      | Technical / Data Integrity                        |
| **Probability**   | ต่ำ (1) — Redis Redlock + Optimistic Lock ป้องกัน |
| **Impact**        | วิกฤต (4) — เลขซ้ำทำให้ระบบไม่น่าเชื่อถือ         |
| **Level**         | 🟠 High (1×4=4)                                   |
| **Trigger Signs** | Duplicate Key Error ใน Document Numbering Log     |

**Mitigation:**

- Redis Redlock + DB Optimistic Locking (ADR-002)
- Two-Phase Commit (Reserve → Confirm)
- Load Test: 50 concurrent requests → Assert ไม่มี Duplicate (AC-PERF-003)
- Unique Constraint ระดับ DB เป็น Last Resort

**Contingency:**

- DB Constraint ป้องกัน Record Duplicate จาก SQL Level
- Audit Log บันทึกทุก Operation → ตรวจสอบและ Correct ได้
- Admin API: Void + Re-issue เลขที่ผิดพลาด

**Owner:** Nattanin P. (Backend Dev)

---

#### 🟡 MEDIUM — ต้องมี Contingency Plan

---

**RISK-007: Email / LINE Notification Delivery Failure**

| Attribute       | Detail                                        |
| --------------- | --------------------------------------------- |
| **Category**    | Integration                                   |
| **Probability** | กลาง (2) — Email Server / LINE API อาจมีปัญหา |
| **Impact**      | ปานกลาง (2) — User ไม่รู้มีงาน → Delay        |
| **Level**       | 🟡 Medium (2×2=4)                             |

**Mitigation:** BullMQ Retry 3 ครั้ง + Dead Letter Queue + In-App Notification Fallback

**Contingency:** ผู้ใช้ยังสามารถดู "My Tasks" บน Dashboard ได้โดยไม่ต้องรอ Notification

**Owner:** Nattanin P.

---

**RISK-008: Search Index Out of Sync (Elasticsearch)**

| Attribute       | Detail                                       |
| --------------- | -------------------------------------------- |
| **Category**    | Technical                                    |
| **Probability** | กลาง (2) — Index lag เกิดได้                 |
| **Impact**      | ปานกลาง (2) — ค้นหาไม่เห็นเอกสารใหม่ชั่วคราว |
| **Level**       | 🟡 Medium (2×2=4)                            |

**Mitigation:** Eventual Consistency — Index ทันที หลัง Document Submit (BullMQ Job)

**Contingency:** Re-index ได้โดย Admin ผ่าน API; Filter-based search ยังใช้ได้แม้ ES ล่ม

**Owner:** Nattanin P.

---

**RISK-009: Scope Creep จาก Stakeholders ระหว่าง UAT**

| Attribute       | Detail                                         |
| --------------- | ---------------------------------------------- |
| **Category**    | Project Management                             |
| **Probability** | สูง (3) — UAT มักทำให้เห็น Feature ใหม่ที่อยาก |
| **Impact**      | ปานกลาง (2) — Delay Go-Live ถ้าไม่จัดการ       |
| **Level**       | 🟡 Medium (3×2=6)                              |

**Mitigation:**

- ใช้ Acceptance Criteria (`01-05`) เป็น Scope Gate — ถ้าไม่อยู่ใน AC → Phase 2
- Change Request Process: ทุก Change Request ต้องผ่าน PO Review ก่อน Accept
- "Parking Lot" List สำหรับ Feature ที่ดีแต่ไม่ใช่ MVP

**Contingency:**

- Emergency Change: กรณีที่ Change มีผล Business Critical → PO + กทท. ตัดสิน
- Timeline Extension: ≤ 2 สัปดาห์ สำหรับ Critical Change ที่ทุกฝ่ายเห็นชอบ

**Owner:** Nattanin P. (PO)

---

**RISK-010: Third-party Service Dependency (ClamAV / Redis / Elasticsearch)**

| Attribute       | Detail                                 |
| --------------- | -------------------------------------- |
| **Category**    | Technical / Infrastructure             |
| **Probability** | ต่ำ (1) — On-Premise, ไม่ขึ้น Internet |
| **Impact**      | สูง (3) — ระบบส่วนหนึ่งหยุดทำงาน       |
| **Level**       | 🟡 Medium (1×3=3)                      |

**Mitigation:** Circuit Breaker Pattern — ถ้า Service รอง (Search, Notification) ล่ม → Core CRUD ทำงานต่อ (Graceful Degradation)

**Contingency:** Runbook สำหรับ Restart แต่ละ Container แยกกัน

**Owner:** Nattanin P.

---

#### 🟢 LOW — Monitor & Document

| Risk         | Description                                          | Owner                             |
| ------------ | ---------------------------------------------------- | --------------------------------- |
| **RISK-011** | ClamAV False Positive — ปฏิเสธไฟล์ปกติ               | Nattanin (Whitelist Update)       |
| **RISK-012** | Browser Compatibility — ระบบไม่ทำงานบน IE/Old Safari | Nattanin (Modern Browser Policy)  |
| **RISK-013** | Large File Upload Timeout (>100MB)                   | Nattanin (Nginx Timeout Config)   |
| **RISK-014** | User กรอกข้อมูลผิด Format แล้วเข้าใจผิดว่าระบบ Bug   | Training (FAQ ข้อที่พบบ่อย)       |
| **RISK-015** | Monitoring Stack (Grafana) ล่มทำให้ไม่เห็น Metrics   | Nattanin (Alert ผ่าน Uptime Kuma) |

---

### 2.3 Risk Summary Dashboard

| Risk ID      | Description               | Level               | Owner          | Status                       |
| ------------ | ------------------------- | ------------------- | -------------- | ---------------------------- |
| RISK-001     | User Adoption Failure     | 🔴 Critical         | NAP + Trainers | 🔄 Mitigating                |
| RISK-002     | Data Migration Error      | 🔴 Critical         | NAP + สค.      | 🔄 Mitigating                |
| RISK-003     | Security Breach           | 🔴 Critical→🟠 High | NAP + กทท. IT  | 🔄 Mitigating                |
| RISK-004     | Infrastructure Downtime   | 🟠 High             | NAP + กทท. IT  | 🔄 Mitigating                |
| RISK-005     | Workflow Config Error     | 🟠 High             | NAP            | ✅ AC Test Coverage          |
| RISK-006     | Doc Number Duplicate      | 🟠 High             | NAP            | ✅ Load Test + DB Constraint |
| RISK-007     | Notification Failure      | 🟡 Medium           | NAP            | ✅ BullMQ Retry + Fallback   |
| RISK-008     | ES Index Out of Sync      | 🟡 Medium           | NAP            | ✅ Eventual Consistency      |
| RISK-009     | Scope Creep               | 🟡 Medium           | NAP (PO)       | 🔄 AC as Gate                |
| RISK-010     | 3rd Party Service Failure | 🟡 Medium           | NAP            | ✅ Graceful Degradation      |
| RISK-011~015 | Low Risks (5 items)       | 🟢 Low              | NAP            | 📋 Documented                |

---

### 2.4 Risk Response Timeline

```
ปัจจุบัน → T-4 สัปดาห์ (Pre-UAT):
  ├── RISK-001: Train-the-Trainer เสร็จ
  ├── RISK-002: Migration Dry Run ครั้งที่ 1 เสร็จ
  ├── RISK-003: Penetration Test เริ่ม
  └── RISK-005: Workflow UAT เริ่ม

T-3 → T-2 สัปดาห์ (UAT):
  ├── RISK-003: PenTest Report ได้รับ + Fix
  ├── RISK-002: Migration Dry Run ครั้งที่ 2 เสร็จ
  ├── RISK-006: Load Test 50 Concurrent เสร็จ
  └── RISK-009: Scope Creep — PO ตัดสิน In/Out

T-1 สัปดาห์ (Pre Go-Live):
  ├── RISK-001: Training ครบทุก Group
  ├── RISK-004: DR Test (Backup Restore) เสร็จ
  └── Sign-off ทุกองค์กร (Section 1.5)

Go-Live:
  └── RISK-001~010: Active Monitoring (Hypercare)
```

---

## ส่วนที่ 3: Change Control Process

### 3.1 Change Request Types

| Type                | ตัวอย่าง                       | ผู้อนุมัติ              | Timeline           |
| ------------------- | ------------------------------ | ----------------------- | ------------------ |
| **Emergency Fix**   | Security Bug, System Down      | NAP PO + กทท.           | < 4 ชั่วโมง        |
| **Critical Change** | Business Rule ผิดพลาด Critical | NAP PO + 2 Stakeholders | < 2 วัน            |
| **Standard Change** | UI Improvement, Minor Feature  | NAP PO                  | Sprint (2 สัปดาห์) |
| **Phase Change**    | Feature ใหม่นอก MVP Scope      | NAP PO + ทุกองค์กร      | Phase 2 Planning   |

### 3.2 Change Request Form (Template)

```markdown
## Change Request #[CR-XXX]

**วันที่:**
**ผู้ขอ:**
**Organization:**
**Priority:** Emergency / Critical / Standard

### คำอธิบาย

[อธิบายการเปลี่ยนแปลงที่ต้องการ]

### เหตุผลธุรกิจ

[ทำไมต้องเปลี่ยน? ผลกระทบถ้าไม่เปลี่ยน?]

### Acceptance Criteria ของ Change นี้

[เกณฑ์การ "Done" ของ Change นี้]

### Impact Assessment

- ผลกระทบต่อ Features อื่น:
- ผลกระทบต่อ Timeline:
- RP&DO (Risk):

### Decision

- [ ] Approved → Sprint: \_\_\_
- [ ] Deferred → Phase: \_\_\_
- [ ] Rejected → เหตุผล: \_\_\_

**Approved by:** ******\_\_\_****** Date: ****\_\_\_****
```

---

## ส่วนที่ 4: Escalation Path

```
ปัญหา Operational ทั่วไป
  ↓ User (Internal Trainer / Org Admin)
  ↓ ไม่แก้ได้ใน 4 ชั่วโมง
NAP Support (Nattanin) — LINE / Email
  ↓ ไม่แก้ได้ใน 24 ชั่วโมง (P1) หรือ 48 ชั่วโมง (P2)
Project Management Level (สค. + กทท.)
  ↓ ไม่แก้ได้ใน 72 ชั่วโมง หรือ กระทบ Milestone
Executive Level (ผู้บริหาร กทท.)
  Decision: Emergency Fix / Rollback / Scope Change
```

---

## 📝 Document Control

- **Version:** 1.0.0 | **Status:** DRAFT — Awaiting Stakeholder Review
- **Created:** 2026-03-11 | **Owner:** Nattanin Peancharoen (PO)
- **Next Review:** T-4 สัปดาห์ก่อน Go-Live (Pre-UAT Review Meeting)
- **Classification:** Confidential — ส่งเฉพาะตัวแทนที่ Sign-off เท่านั้น

> [!NOTE]
> เมื่อได้รับลายมือชื่อครบทุกองค์กร ให้ Scan และบันทึกฉบับ PDF ไว้ใน  
> `specs/00-Overview/signed/00-04-stakeholder-signoff-SIGNED.pdf`