308 lines
30 KiB
Markdown
308 lines
30 KiB
Markdown
# Feature Specification: RFA Approval System Refactor (TeamBinder/InEight-Style)
|
|
|
|
**Feature Branch**: `204-rfa-approval-refactor`
|
|
**Created**: 2026-05-11
|
|
**Status**: Draft
|
|
**Input**: User description: "refactor ระบบการอนุมัติเอกสาร, RFA ให้เหมือนกับ TeamBinder หรือ InEight"
|
|
|
|
---
|
|
|
|
## Overview
|
|
|
|
ปรับปรุงระบบการอนุมัติเอกสาร RFA (Request for Approval) ให้มีความยืดหยุ่นและครบถ้วนตามมาตรฐานระดับสูงของอุตสาหกรรมก่อสร้าง (TeamBinder, InEight) รองรับการทำงานแบบ Multi-Disciplinary Review, Response Codes มาตรฐาน, และ Distribution Matrix อัตโนมัติ
|
|
|
|
---
|
|
|
|
## User Scenarios & Testing
|
|
|
|
### User Story 1 - Review Teams by Discipline (Priority: P1)
|
|
|
|
ผู้จัดการโครงการสามารถกำหนดกลุ่มผู้ตรวจสอบ (Review Teams) ตามสาขาวิชา (Disciplines) แทนการระบุรายบุคคล เพื่อให้การมอบหมายงานยืดหยุ่นและรวดเร็ว
|
|
|
|
**Why this priority**: ฟีเจอร์หลักที่แยกระบบปัจจุบันกับมาตรฐานอุตสาหกรรม - ช่วยลดเวลาในการกำหนดผู้ตรวจสอบและรองรับการเปลี่ยนแปลงบุคคลในโครงการ
|
|
|
|
**Independent Test**: สามารถทดสอบโดยสร้าง Review Team ที่มีหลาย Disciplines และส่ง RFA เข้า workflow - ระบบต้องสามารถมอบหมายให้ทุก Discipline พร้อมกันได้
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** ผู้ใช้มีสิทธิ์จัดการ Review Teams, **When** สร้าง Review Team ใหม่ชื่อ "Structural Review Team" พร้อมกำหนด Disciplines: Structural, Civil, **Then** ระบบบันทึกทีมและสามารถใช้กับ RFA ได้
|
|
2. **Given** RFA ถูกส่งเข้า workflow และใช้ Review Team ที่มี 3 Disciplines, **When** ระบบประมวลผล, **Then** สร้าง Review Tasks สำหรับแต่ละ Discipline พร้อมกัน
|
|
3. **Given** Reviewer ในทีมเปลี่ยนตำแหน่งหรือลาออก, **When** Admin อัปเดตสมาชิกใน Review Team, **Then** RFA ที่รออยู่ต้องอัปเดตผู้รับผิดชอบโดยอัตโนมัติ
|
|
|
|
---
|
|
|
|
### User Story 2 - Response Codes & Sub-Status (Priority: P1)
|
|
|
|
วิศวกรสามารถเลือก Response Code มาตรฐาน (1A, 1B, 1C, 2, 3, 4) พร้อม Sub-Status ที่บ่งบอกความหมายเฉพาะทาง เพื่อสื่อสารสถานะงานได้ชัดเจนและสอดคล้องกับมาตรฐานอุตสาหกรรม
|
|
|
|
**Why this priority**: ปรับปรุงการสื่อสารระหว่างฝ่ายต่างๆ ลดความกำกวมในการอนุมัติ และสนับสนุนการทำ Final Acceptance Certificate (FAC)
|
|
|
|
**Independent Test**: สามารถทดสอบโดยเปิดหน้าอนุมัติ RFA และตรวจสอบว่า Response Codes แสดงตาม Category ของเอกสาร - เลือก Code 1C ต้องมีการแจ้งเตือนฝ่ายสัญญา
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** RFA ประเภท Shop Drawing, **When** Reviewer เปิดหน้าอนุมัติ, **Then** แสดงเฉพาะ Response Codes ที่เกี่ยวข้องกับ Engineering/Drawings (1A-1G, 2, 3, 4)
|
|
2. **Given** Reviewer เลือก Code 1C (Change Order) หรือ 1D (Alternative), **When** บันทึกการอนุมัติ, **Then** ระบบส่งแจ้งเตือนไปยังฝ่ายสัญญา/BOQ อัตโนมัติ
|
|
3. **Given** RFA ได้รับ Code 2 (Approved as Noted), **When** ดูรายงานสถานะ, **Then** แสดงสถานะ "Approved with Minor Comments" พร้องานที่ต้องแก้ไข
|
|
|
|
---
|
|
|
|
### User Story 3 - Delegation & Proxy (Priority: P2)
|
|
|
|
ผู้ตรวจสอบสามารถมอบหมายอำนาจ (Delegate) ให้ผู้อื่นทำงานแทนเมื่อไม่อยู่หรือไม่สะดวก โดยกำหนดระยะเวลาและขอบเขตอำนาจได้
|
|
|
|
**Why this priority**: ป้องกันการคั่งค้างของ workflow เมื่อผู้ตรวจสอบไม่ว่าง รองรับการทำงานแบบ Hybrid/Remote
|
|
|
|
**Independent Test**: สามารถทดสอบโดยผู้ใช้ A ตั้งค่า Delegate ให้ผู้ใช้ B แล้วส่ง RFA มา - ผู้ใช้ B ต้องเห็นงานใน Inbox และสามารถอนุมัติแทนได้
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** ผู้ใช้ต้องการลาพักร้อน 1 สัปดาห์, **When** ตั้งค่า Delegation ให้ colleague พร้อมระบุวันที่เริ่ม-สิ้นสุด, **Then** งานที่ส่งมาระหว่างนี้ไปที่ Delegatee โดยอัตโนมัติ
|
|
2. **Given** มีงาน RFA รออยู่ใน Inbox และผู้ใช้ตั้งค่า Delegation ไว้, **When** มีการส่งงานใหม่เข้ามา, **Then** ระบบมอบหมายให้ Delegatee พร้อมแสดงว่าเป็น "Delegated from [Original User]"
|
|
3. **Given** Delegation หมดอายุ, **When** มีงานใหม่ส่งมา, **Then** งานกลับมาที่ผู้ใช้เจ้าของงานเดิม และยกเลิกสิทธิ์ Delegatee
|
|
|
|
---
|
|
|
|
### User Story 4 - Auto-Reminders & Escalation (Priority: P2)
|
|
|
|
ระบบส่งการแจ้งเตือนอัตโนมัติเมื่องานใกล้ครบกำหนด และส่งขึ้นระดับ (Escalate) เมื่อเกินกำหนด ตาม SLA ที่กำหนดไว้
|
|
|
|
**Why this priority**: ลดความล่าช้าใน workflow และปรับปรุง on-time delivery rate ของเอกสาร
|
|
|
|
**Independent Test**: สามารถทดสอบโดยสร้าง RFA ที่มี Due Date ในอีก 1 วัน และตรวจสอบว่าระบบส่ง Reminder ตามที่ตั้งค่าไว้
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** RFA มี Due Date ในอีก 2 วัน, **When** ถึงเวลา 9:00 ของวันที่ตั้งค่า Reminder, **Then** ส่งอีเมล/แจ้งเตือนไปยังผู้รับผิดชอบ
|
|
2. **Given** RFA เกินกำหนด 1 วัน, **When** ถึงเงื่อนไข Escalation, **Then** ส่งแจ้งเตือนไปยัง Manager ของผู้รับผิดชอบ พร้อมสถานะ Overdue
|
|
3. **Given** Admin ตั้งค่า Reminder Frequency เป็น "Daily" สำหรับงาน Overdue, **When** งานค้างเกินกำหนด, **Then** ส่ง Reminder ทุกวันจนกว่าจะดำเนินการ
|
|
|
|
---
|
|
|
|
### User Story 5 - Distribution Matrix (Priority: P2)
|
|
|
|
ระบบกระจายเอกสารอัตโนมัติไปยังผู้ที่เกี่ยวข้องหลังจาก RFA ได้รับการอนุมัติ ตาม Distribution Matrix ที่กำหนดไว้ตามประเภทเอกสารและ Response Code
|
|
|
|
**Why this priority**: ลด manual work ในการส่งเอกสารต่อ ป้องกันการส่งตกหล่น และสนับสนุนการทำ Transmittal อัตโนมัติ
|
|
|
|
**Independent Test**: สามารถทดสอบโดยอนุมัติ RFA ที่มี Distribution Matrix แล้วตรวจสอบว่าเอกสารถูกส่งไปยังผู้รับที่กำหนดใน Matrix โดยอัตโนมัติ
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** RFA ประเภท Shop Drawing ได้รับ Code 1A (Full Approval), **When** อนุมัติสำเร็จ, **Then** ระบบส่งเอกสารไปยัง Site Team, QS, และ Document Control ตาม Distribution Matrix
|
|
2. **Given** Distribution Matrix มีเงื่อนไข "Send only if Code = 1A, 1B, or 2", **When** RFA ได้รับ Code 3 (Rejected), **Then** ไม่ส่งเอกสารตาม Matrix (แจ้งเฉพาะผู้ส่ง)
|
|
3. **Given** Admin อัปเดต Distribution Matrix เพิ่มผู้รับใหม่, **When** RFA ถัดไปได้รับการอนุมัติ, **Then** ส่งเอกสารไปยังผู้รับใหม่ด้วย
|
|
|
|
---
|
|
|
|
### User Story 6 - Master Approval Matrix Management (Priority: P3)
|
|
|
|
ผู้ดูแลระบบสามารถจัดการ Master Approval Matrix ที่เป็นมาตรฐานขององค์กร แยกตามหมวดงานและสถานะย่อย ให้ใช้งานทั่วทั้งโครงการ
|
|
|
|
**Why this priority**: มาตรฐานการอนุมัติให้สอดคล้องกับบริษัทและอุตสาหกรรม ลดความสับสนในการใช้ Response Codes
|
|
|
|
**Independent Test**: สามารถทดสอบโดยสร้าง Master Approval Matrix ใหม่ และตรวจสอบว่า RFA แสดง Response Codes ตาม Matrix ที่กำหนด
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** Admin ต้องการสร้างมาตรฐานใหม่สำหรับโครงการก่อสร้างสะพาน, **When** สร้าง Master Approval Matrix พร้อมกำหนดหมวดงานและ Sub-status, **Then** สามารถใช้กับโครงการที่เลือกได้
|
|
2. **Given** Master Approval Matrix ถูกใช้งานในโครงการหลายแห่ง, **When** Admin แก้ไข Matrix, **Then** ระบบแสดง Warning ว่าจะมีผลกับโครงการที่ใช้งานอยู่
|
|
|
|
---
|
|
|
|
## Edge Cases
|
|
|
|
1. **Race Condition**: สอง Reviewer ในทีมเดียวกันกดอนุมัติพร้อมกัน - ระบบต้องจัดการด้วย Optimistic Locking หรือ Redlock
|
|
2. **Circular Delegation**: ผู้ใช้ A Delegate ให้ B, B Delegate ให้ C, C พยายาม Delegate ให้ A - ระบบต้องตรวจจับและป้องกัน
|
|
3. **Expired Review Task**: Review Task ค้างนานเกินกำหนดและถูก Reassign - ต้องบันทึกประวัติการเปลี่ยนแปลง
|
|
4. **Invalid Response Code**: Reviewer พยายามใช้ Response Code ที่ไม่สอดคล้องกับ Category ของเอกสาร - ระบบต้องแสดงข้อผิดพลาดและไม่บันทึก
|
|
5. **Concurrent Review**: หลาย Disciplines ต้อง Review พร้อมกัน แต่มี Discipline หนึ่งปฏิเสธ - ต้องหยุด workflow และแจ้งผู้ส่ง
|
|
|
|
---
|
|
|
|
## Requirements
|
|
|
|
### Functional Requirements
|
|
|
|
#### Review Teams & Disciplines
|
|
|
|
- **FR-001**: ระบบ MUST รองรับการสร้าง Review Teams ที่มีหลาย Disciplines
|
|
- **FR-002**: Review Teams MUST สามารถกำหนดเป็น Default ตามประเภท RFA ได้
|
|
- **FR-002.1**: เมื่อมีการส่ง Revision ใหม่ของ RFA เดิม, ระบบ MUST ดึงรายชื่อ Review Team และ Disciplines จาก Revision ล่าสุดมาเป็น Default เพื่อความต่อเนื่อง (Inherit Previous Team) แต่ผู้ส่งยังคงสามารถปรับเปลี่ยนได้หากจำเป็น
|
|
- **FR-003**: เมื่อ RFA เข้า workflow ที่ใช้ Review Team, ระบบ MUST สร้าง Review Tasks สำหรับแต่ละ Discipline พร้อมกัน (Parallel Review)
|
|
- **FR-004**: Review Tasks MUST แสดงสถานะรวม (Aggregate Status) เช่น "2 of 3 Disciplines Approved"
|
|
- **FR-004.5**: Parallel Review MUST ใช้กฎ **Lead Consolidation** - ระบบอนุญาตให้ทุก Disciplines ตรวจสอบจนครบ โดยที่ Lead Discipline จะเป็นผู้พิจารณาความเห็นจากทุกฝ่ายและเป็นผู้สรุปสถานะสุดท้าย (Final Response Code) ของ RFA นั้นๆ
|
|
- **FR-004.6**: ในระหว่าง Parallel Review, Reviewers ทุกคน MUST สามารถเห็นคอมเมนต์และสถานะเบื้องต้นของกันและกันได้ (Full Transparency) เพื่อช่วยในการประสานงานข้ามสายงาน (Cross-discipline coordination)
|
|
|
|
#### Response Codes & Master Approval Matrix
|
|
|
|
- **FR-005**: ระบบ MUST ใช้ Master Approval Matrix ตามมาตรฐานที่กำหนด
|
|
- **FR-006**: Response Codes MUST แสดงตาม Category ของเอกสาร (Engineering, Material, Contract, Testing, ESG) และระบบ MUST จำกัดตัวเลือก (Filter) ให้ทั้ง Reviewer และ Lead เห็นเฉพาะโค้ดที่อยู่ในหมวดหมู่นั้นๆ เท่านั้น
|
|
- **FR-006.1**: หาก Final Response Code มีผลกระทบต่อ Cost หรือ Schedule (ตาม Matrix), ระบบ MUST ทำการ Flag และแจ้งเตือนบน Management Dashboard ทันที เพื่อให้ฝ่ายบริหารดำเนินการต่อภายนอกระบบได้ทันท่วงที
|
|
- **FR-007**: Code 1C (Change Order), 1D (Alternative), 3 (Rejected) MUST trigger การแจ้งเตือนไปยังฝ่ายที่เกี่ยวข้องโดยอัตโนมัติ
|
|
- **FR-008**: ระบบ MUST บันทึกประวัติการเปลี่ยน Response Code (Audit Trail)
|
|
- **FR-009**: Reviewer MUST สามารถเพิ่ม Comments พร้อม Response Code ได้
|
|
|
|
#### Delegation & Proxy
|
|
|
|
- **FR-010**: ผู้ใช้ MUST สามารถตั้งค่า Delegation ได้ พร้อมกำหนดระยะเวลาเริ่มต้น-สิ้นสุด
|
|
- **FR-011**: Delegation MUST รองรับการกำหนด Scope (เฉพาะบางประเภทเอกสาร หรือทั้งหมด)
|
|
- **FR-012**: ระบบ MUST ตรวจจับและป้องกัน Circular Delegation และไม่อนุญาตให้มีการมอบหมายงานต่อ (Sub-delegation) ในระดับผู้ใช้งานปกติ (Single Level Only) ยกเว้น Admin ที่มีสิทธิ์ในการ Reassign หรืองานจัดการมอบหมายงานใหม่ได้เสมอ
|
|
- **FR-013**: เมื่อ Delegation หมดอายุ, งานใหม่ MUST กลับไปยังผู้ใช้เดิมโดยอัตโนมัติ
|
|
- **FR-014**: Delegatee MUST เห็นงานที่ได้รับมอบหมายแยกจากงานของตนเอง (Badge "Delegated")
|
|
|
|
#### Auto-Reminders & Escalation
|
|
|
|
- **FR-015**: ระบบ MUST ส่ง Reminder ตาม Schedule ที่กำหนด (1 วันก่อน Due, วัน Due, ทุกวันหลัง Due)
|
|
- **FR-016**: Escalation MUST ดำเนินการแบบลำดับชั้น (L1 -> L2) โดยที่แต่ละระดับจะมีการแจ้งเตือน 3 ครั้งก่อนจะยกระดับขึ้นไปตามเกณฑ์ที่ตั้งไว้ และเมื่อถึงระดับสูงสุด (L2) ระบบ MUST ส่งแจ้งเตือนรายวัน (Daily) จนกว่าจะมีการดำเนินการ
|
|
- **FR-016.1**: ระบบ MUST บันทึกประวัติการ Escalation และการตอบสนองของผู้บริหารใน Audit Trail
|
|
- **FR-017**: Admin MUST สามารถตั้งค่า Reminder Rules ต่อโครงการ/ประเภทเอกสารได้
|
|
- **FR-018**: ระบบ MUST บันทึกประวัติการส่ง Reminder (ส่งเมื่อไหร่, ใครได้รับ)
|
|
|
|
#### Frontend Workflow Visualization
|
|
|
|
- **FR-019.1**: Parallel Review MUST แสดงผลด้วย **Horizontal Stepper** - แถบความคืบหนันแนวนอนแสดงสถานะแต่ละ Discipline [Structural ▓▓▓░] [Civil ▓▓▓▓] [MEP ▓░░░]
|
|
- **FR-019.2**: เมื่อมี Code 3 (Rejected) จาก Discipline ใด MUST แสดง **Modal Dialog** แจ้งการ Veto พร้อมรายละเอียด Discipline ที่ reject
|
|
- **FR-019.3**: Navigation ระหว่าง Discipline details MUST ใช้ **Side Panel** layout - ซ้ายรายการ Disciplines, ขวาแสดงรายละเอียด Comments + Attachments ของ Discipline ที่เลือก
|
|
- **FR-019.4**: Project Manager MUST สามารถ **Override Veto** ได้ - บังคับผ่าน RFA แม้มี Code 3 จาก Discipline พร้อมบันทึกเหตุผล, Audit trail ว่าเป็น forced approval, และแจ้งเตือนทุก stakeholder ที่เกี่ยวข้อง
|
|
|
|
#### Distribution Matrix
|
|
|
|
- **FR-019**: Distribution Matrix MUST กำหนดผู้รับตาม: ประเภทเอกสาร + Response Code + สถานะเอกสาร และระบบ MUST อนุญาตให้ผู้สรุปผล (Lead/PM) เพิ่มผู้รับเพิ่มเติมแบบ Manual ได้ก่อนการส่งออกเฉพาะครั้งนั้นๆ
|
|
- **FR-020**: ระบบ MUST สร้าง Transmittal Records อัตโนมัติหลังการอนุมัติตาม Distribution Matrix ผ่าน BullMQ Queue (Async, ภายใน 5 นาที)
|
|
- **FR-021**: Distribution Matrix MUST รองรับเงื่อนไข "Send Only If" (เช่น Code 1A, 1B เท่านั้น)
|
|
- **FR-022**: ระบบ MUST แสดงรายงาน Distribution Status (ส่งแล้วกี่ราย, ค้างกี่ราย)
|
|
|
|
#### Integration with Existing Systems
|
|
|
|
- **FR-023**: ต้องใช้ Unified Workflow Engine (ADR-001) ที่มีอยู่แล้ว
|
|
- **FR-024**: ต้องใช้ BullMQ (ADR-008) สำหรับ Reminders และ Distribution Jobs
|
|
- **FR-025**: ต้องใช้ CASL (ADR-016) สำหรับสิทธิ์ Reviewer และ Delegation
|
|
|
|
---
|
|
|
|
### Key Entities
|
|
|
|
#### ReviewTeam
|
|
|
|
- ตัวแทนกลุ่มผู้ตรวจสอบที่จัดการตามสาขาวิชา
|
|
- Attributes: name, description, projectId, defaultForRfaTypes, isActive
|
|
- Relationships: has many ReviewTeamMember, has many ReviewTask
|
|
|
|
#### ReviewTeamMember
|
|
|
|
- สมาชิกใน Review Team พร้อม Discipline ที่รับผิดชอบ
|
|
- Attributes: teamId, userId, disciplineId, role, priorityOrder
|
|
- Relationships: belongs to ReviewTeam, belongs to User, belongs to Discipline
|
|
|
|
#### ReviewTask
|
|
|
|
- งานตรวจสอบที่สร้างเมื่อ RFA เข้า workflow
|
|
- Attributes: rfaRevisionId, teamId, disciplineId, assignedToUserId, status, dueDate, responseCode, comments
|
|
- Relationships: belongs to RfaRevision, belongs to ReviewTeam
|
|
|
|
#### ResponseCodeMatrix
|
|
|
|
- Master Approval Matrix ที่กำหนด Response Codes ตาม Category
|
|
- Attributes: code, subStatus, category, descriptionTh, descriptionEn, implications, requiresNotificationTo
|
|
- Relationships: has many ResponseCodeRule
|
|
|
|
#### ResponseCodeRule
|
|
|
|
- กฎการใช้ Response Code ตามประเภทเอกสาร
|
|
- Attributes: matrixId, documentTypeId, isEnabled, requiresComments, triggersNotification
|
|
|
|
#### Delegation
|
|
|
|
- การมอบหมายอำนาจจากผู้ใช้หนึ่งไปอีกผู้ใช้
|
|
- Attributes: delegatorId, delegateeId, startDate, endDate, scope, documentTypes, isActive
|
|
- Relationships: belongs to User (delegator), belongs to User (delegatee)
|
|
|
|
#### ReminderRule
|
|
|
|
- กฎการส่ง Reminder ตาม SLA
|
|
- Attributes: name, projectId, documentTypeId, triggerDays, reminderType, recipients, messageTemplate
|
|
- Relationships: has many ReminderSchedule
|
|
|
|
#### DistributionMatrix
|
|
|
|
- กำหนดการกระจายเอกสารหลังอนุมัติ
|
|
- Attributes: name, documentTypeId, responseCode, status, recipients, conditions, isActive
|
|
- Relationships: has many DistributionRecipient
|
|
|
|
#### DistributionRecipient
|
|
|
|
- ผู้รับเอกสารใน Distribution Matrix
|
|
- Attributes: matrixId, recipientType (USER/ORGANIZATION/TEAM), recipientId, deliveryMethod
|
|
|
|
---
|
|
|
|
## Success Criteria
|
|
|
|
### Measurable Outcomes
|
|
|
|
- **SC-001**: ผู้ใช้สามารถกำหนด Review Team ได้ในเวลาน้อยกว่า 2 นาที (เทียบกับระบบเดิมที่ต้องเลือกรายบุคคล)
|
|
- **SC-002**: Response Code ถูกใช้งานได้ถูกต้อง 95%+ ของเวลาทั้งหมด (ลดการใช้ผิดประเภท)
|
|
- **SC-003**: ลดเวลาในการอนุมัติ RFA โดยเฉลี่ย 30% จากการใช้ Parallel Review และ Response Codes ที่ชัดเจน
|
|
- **SC-004**: 0% ของเอกสารที่ค้างงานเนื่องจากผู้ตรวจสอบไม่อยู่ (ใช้ Delegation)
|
|
- **SC-005**: 100% ของเอกสารที่อนุมัติถูกกระจายตาม Distribution Matrix โดยไม่ต้อง manual intervention
|
|
- **SC-006**: On-time delivery rate ของ RFA ปรับปรุงจาก baseline เป็นอย่างน้อย 85%
|
|
- **SC-007**: ผู้ใช้พึงพอใจกับระบบอนุมัติใหม่ (NPS > 40)
|
|
|
|
---
|
|
|
|
## Clarifications
|
|
|
|
### Session 2026-05-13
|
|
|
|
- **Q1**: Parallel Review consensus model for conflicting decisions? → **A**: Lead Consolidation - Allow all disciplines to complete their review, then the Lead Discipline consolidates all comments and makes the final decision.
|
|
- **Q2**: Delegation Depth and sub-delegation rules? → **A**: Single Level Only (No sub-delegation) for regular users, but Admin retains full override power to reassign or manage delegations as needed.
|
|
- **Q3**: Manual overrides in Distribution Matrix? → **A**: Flexible Recipients - Allow Lead/PM to manually add additional recipients during the final approval step for a specific RFA.
|
|
- **Q4**: Escalation Cycle and notification frequency? → **A**: 3-Strike Escalation - Notify current escalation level 3 times before moving up to the next level (Progressive). Once the highest level (L2) is reached, send daily reminders until resolved.
|
|
- **Q5**: Transparency between Disciplines during Parallel Review? → **A**: Full Transparency - All reviewers can see each other's comments and partial results in real-time.
|
|
- **Q6**: Handling Cost/Schedule Implications from Response Codes? → **A**: Dashboard Flagging - Record the impact and notify management via dashboard/reporting without blocking the RFA flow.
|
|
- **Q7**: Review Team persistence on resubmissions? → **A**: Inherit Previous Team - Automatically default to the same team and disciplines from the previous version for continuity.
|
|
- **Q8**: Response Code visibility constraints for Reviewers? → **A**: Category Scoped - Filter the available codes based on the RFA category for both Reviewers and Leads to ensure consistency.
|
|
|
|
### Session 2026-05-11
|
|
|
|
- **Q1**: Master Approval Matrix scope and inheritance model? → **A**: Global base + Project overrides - Default Matrix inherited organization-wide, projects can override specific codes/rules as needed (Option B)
|
|
- **Q2**: Parallel Review consensus model when Disciplines have conflicting decisions? → **A**: Lead Consolidation (Updated 2026-05-13) - Formerly Majority with Veto.
|
|
- **Q3**: Escalation chain depth for overdue RFA reviews? → **A**: 2 levels - Direct manager first, then Project Manager/Director if still unresolved after additional delay (Option B)
|
|
- **Q4**: Distribution Matrix execution timing relative to approval? → **A**: Async after approval - Approval returns immediately, distribution queued via BullMQ and processed automatically within 5 minutes (Option C)
|
|
- **Q5**: Frontend pattern for displaying Parallel Review progress? → **A**: Horizontal Stepper - แถบความคืบหนันแนวนอนแสดงสถานะแต่ละ Discipline (Option A)
|
|
- **Q6**: How to display Veto/Consensus status เมื่อมีการ Reject? → **A**: Modal Dialog - Popup แจ้งเมื่อมีการ Reject พร้อมรายละเอียด Discipline ที่ระบุ (Option B)
|
|
- **Q7**: Navigation pattern between Discipline details for Reviewer? → **A**: Side Panel - ซ้ายรายการ Disciplines, ขวาแสดงรายละเอียดที่เลือก (Option D)
|
|
- **Q8**: Can a decision be overridden and by whom? → **A**: Project Manager Override - PM สามารถบังคับผ่านการตัดสินใจของ Lead ได้ พร้อมบันทึกเหตุผล และแจ้งเตือนทุก stakeholder (Option B)
|
|
|
|
---
|
|
|
|
## Assumptions
|
|
|
|
1. **ผู้ใช้มีความคุ้นเคยกับ Response Codes มาตรฐานอุตสาหกรรม** - จำเป็นต้องมี Training Material ประกอบ
|
|
2. **โครงสร้าง Discipline Master Data มีอยู่แล้ว** - ใช้จากระบบ User Management ที่มีอยู่
|
|
3. **Unified Workflow Engine (ADR-001) มีความสามารถรองรับ Parallel Tasks** - อาจต้องปรับปรุง DSL
|
|
4. **BullMQ Infrastructure พร้อมใช้งาน** - สำหรับ Reminders และ Background Jobs
|
|
|
|
---
|
|
|
|
## Dependencies
|
|
|
|
- **ADR-001**: Unified Workflow Engine (ต้องรองรับ Parallel Review Tasks)
|
|
- **ADR-008**: BullMQ Notification Strategy
|
|
- **ADR-016**: CASL Authorization (สำหรับ Reviewer สิทธิ์)
|
|
- **ADR-019**: UUID Strategy (สำหรับ Entities ใหม่)
|
|
- **ADR-021**: Workflow Context (สำหรับ Step Attachments)
|
|
- **Existing**: Discipline, User, Organization Master Data
|
|
|
|
---
|
|
|
|
## Risks & Mitigations
|
|
|
|
| Risk | Impact | Mitigation |
|
|
| :--- | :--- | :--- |
|
|
| ผู้ใช้ไม่คุ้นเคยกับ Response Codes ใหม่ | High | ทำ Training Workshop พร้อม Quick Reference Guide |
|
|
| Workflow Engine ไม่รองรับ Parallel Review | High | ประเมิน DSL ก่อนเริ่ม, อาจต้อง Refactor Engine |
|
|
| Performance ช้าจาก Complex Matrix Lookup | Medium | ทำ Caching สำหรับ Matrix และ Rules |
|
|
| Circular Delegation ซับซ้อน | Low | Validation ตั้งแต่ต้น, Limit depth ของ chain |
|