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)

## 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