# BRD (Working Draft): PMaxx Implementation ให้ลูกค้า v0.1

วันที่: 10 ส.ค. 2026 · ผู้เขียน: [ทีม] · ผู้อนุมัติ: [sponsor] · สถานะ: **Draft**
ผู้อ่าน: **ทีมทำงาน (working team)** — ใช้เปิดประชุม/อธิบายสโคปก่อน ยังไม่ใช่ฉบับส่งลูกค้า
เอกสารคู่กัน: `PMaxx-Implementation-Plan.md` (รายละเอียด workstream/task)

> ⚠️ ประเด็นกฎหมายเรื่องขายยา/telemedicine ในเอกสารนี้เป็น "รายการต้องตรวจสอบ" ไม่ใช่ข้อสรุปทางกฎหมาย ต้องยืนยันกับฝ่ายกฎหมาย + เภสัชกร/RA ของลูกค้า

---

## 1. Executive Summary
ลูกค้าต้องการซื้อ/ใช้แพลตฟอร์ม PMaxx (e-marketplace ที่พัฒนาเสร็จแล้ว) เพื่อขายสินค้าสุขภาพ/ยาออนไลน์ งานของเราคือ **implement + integration ให้ครบจนเปิดขายได้จริง** — ลงสินค้า 100 SKU, เชื่อม ERP Navision, ChillPay, Shippop และช่องทาง LINE พร้อมวางแผนเผื่อ 3 project ต่อยอด (LINE CRM, Same-day, Telemed) เป้าหมาย go-live core ภายใน ~3 เดือน

## 2. Business Problem / Opportunity
- ลูกค้ามีสินค้า + ระบบหลังบ้าน (Navision) อยู่แล้ว แต่ยัง **ไม่มีหน้าร้านออนไลน์ที่เชื่อมกับ ERP** → ขายออนไลน์ไม่ได้/ทำมือ ผิดพลาดง่าย
- ช่องทาง LINE เดิมมี 2 ทางเชื่อมที่ **ไม่ค่อย work** → เสียลูกค้า/สมัครไม่ผ่าน
- โอกาส: ต่อยอดเป็นบริการสุขภาพครบวงจร (สั่งยาด่วน + ปรึกษาแพทย์ออนไลน์) ซึ่งเป็นตลาดที่โต
- *[ทีมเติมตัวเลขจริง: มูลค่าออเดอร์/เดือนที่คาด, จำนวนลูกค้า LINE ปัจจุบัน]*

## 3. Business Objectives
| ID | เป้าหมาย (วัดได้) | Baseline | Target | กรอบเวลา |
|---|---|---|---|---|
| BR-01 | เปิดขายออนไลน์ผ่าน PMaxx เชื่อม Navision อัตโนมัติ | ยังไม่มี | order sync PMaxx↔NAV ทำงาน 100% | Go-live เดือน 3 |
| BR-02 | ความถูกต้องข้อมูล order/เงิน/สต๊อก ระหว่างระบบ | ทำมือ คลาดเคลื่อน | reconciliation ตรง ≥ 99.5%/วัน | เดือน 3 |
| BR-03 | ลูกค้าสมัคร/เข้าผ่าน LINE ได้ในทางเดียวที่เสถียร | 2 ทาง ไม่ work | สมัครสำเร็จ ≥ [95%] | เดือน 3 |
| BR-04 | รองรับต่อยอด Same-day + Telemed โดยไม่ต้องรื้อ | - | สถาปัตยกรรม/data model พร้อมต่อ | ออกแบบในเฟส core |

## 4. Scope
**In-scope (core go-live):** ลง 100 SKU · API สินค้า/สต๊อก/ราคา NAV→PMaxx · middleware order PMaxx→NAV + สถานะกลับ · ChillPay · Shippop (รวม COD) · LINE OA สมัคร/login/แจ้งเตือน · ชั้น reconciliation · config + compliance ขั้นต่ำ

**Out-of-scope (กันงานงอก — สำคัญกว่า):**
- LINE CRM เต็มรูปแบบ → project แยก
- Same-day medicine → project แยก
- Telemed → project แยก
- ปรับแต่ง/พัฒนา feature ใหม่ในตัว PMaxx เอง (ถือว่าใช้ของที่มี)
- Data migration ประวัติย้อนหลังจาก NAV (นอกจาก master data ที่จำเป็น) *[ยืนยัน]*

## 5. Stakeholders & Impact
| Stakeholder | ได้/เสียอะไร | Sign-off |
|---|---|---|
| ลูกค้า (เจ้าของธุรกิจ) | ได้ช่องทางขายออนไลน์เชื่อม ERP | ✅ |
| เภสัชกร/ทีมร้าน | workflow ใหม่ ตรวจ/จ่ายยา | รับทราบ + train |
| ทีม IT ลูกค้า (ดูแล NAV) | ต้องเปิด web service / connectivity | ✅ (จำเป็น) |
| ทีมเรา (dev/PM/data) | ส่งมอบ integration + reconciliation | — |
| ฝ่ายกฎหมาย/RA ลูกค้า | ตัดสิน SKU ที่ขายออนไลน์ได้ + PDPA | ✅ (blocker) |

## 6. Success Metrics
| Metric | Baseline | Target | วิธีวัด | เจ้าของ |
|---|---|---|---|---|
| Order sync สำเร็จ | - | ≥ 99.5% | log middleware | ทีม dev |
| Reconciliation ตรง (order/เงิน/สต๊อก) | ทำมือ | ≥ 99.5%/วัน | dashboard กระทบยอด | ทีม data |
| อัตราจ่ายเงินสำเร็จ (ChillPay) | - | ≥ [95%] | ChillPay report | ทีม dev |
| สมัครผ่าน LINE สำเร็จ | ไม่ work | ≥ [95%] | event tracking | ทีม dev |
| เวลา go-live | - | ≤ 3 เดือน | milestone | PM |

## 7. Constraints & Assumptions
- **Navision:** รุ่น/โฮสต์ยังไม่ยืนยัน (classic NAV on-prem vs Business Central) — กระทบ effort มากสุด; classic NAV ไม่มี webhook → ต้อง poll
- **Compliance (ต้องตรวจสอบ):** ใบอนุญาตขายยา, เภสัชกรจ่ายยา, กลุ่มยาที่ขายออนไลน์ได้ vs ต้องมีใบสั่ง, อย./พ.ร.บ.ยา
- **PDPA:** ข้อมูลสุขภาพเป็นข้อมูลอ่อนไหว ต้องมี consent + ป้องกันเข้ม (โดยเฉพาะ LINE CRM/Telemed)
- **Dependency ภายนอก:** NAV web service ต้องถูกเปิด, ChillPay/Shippop sandbox + สัญญา merchant พร้อม
- **สมมติฐาน:** PMaxx อาจยังไม่มี public API/module ChillPay-Shippop สำเร็จรูป → อาจต้องสร้าง connector เพิ่ม *[ยืนยัน]*

## 8. Risks (Top 5)
| ความเสี่ยง | โอกาส | ผลกระทบ | แผนรับมือ |
|---|---|---|---|
| Compliance ขายยาไม่ผ่าน → ขายบาง SKU ไม่ได้ | กลาง | สูง | ทำ compliance review ใน Phase 0 ก่อนล็อก catalog |
| NAV เป็น classic on-prem → เชื่อมยาก/ช้า | กลาง | สูง | ยืนยันรุ่นเร็ว, เผื่อเวลา connectivity 1–2 wk |
| ออเดอร์ซ้ำใน NAV | กลาง | สูง | idempotency = External Document No. |
| COD/เงินไม่ตรง (Shippop/ChillPay) | กลาง | กลาง | reconciliation dashboard ตั้งแต่วันแรก |
| LINE เดิม 2 ทางเป็น technical debt | สูง | กลาง | เลือกทางเดียว (LIFF+Messaging API) วาง schema เผื่อ CRM |

## 9. Cost-Benefit (ระดับประมาณการ)
- **ลงทุน:** ทีม implement ~3 เดือน (core) + ค่า vendor (ChillPay MDR, Shippop, LINE) *[ทีมเติมตัวเลข]*
- **ได้คืน:** เปิดขายออนไลน์เชื่อม ERP อัตโนมัติ, ลดงานมือ/ความผิดพลาด, ฐานสำหรับ Same-day/Telemed
- **คืนทุนคาด:** *[ทีมเติมตามมูลค่าออเดอร์คาด]*

---

## 10. Timeline (Core Go-live ~3 เดือน)

สมมติ classic NAV on-prem (เคสหนักสุด) · ปรับเมื่อยืนยันรุ่น NAV + ทีม

| Phase | สัปดาห์ | Milestone |
|---|---|---|
| 0 · Discovery & Compliance | 1–2 | ยืนยัน NAV/PMaxx, source of truth, กติกา SKU/PDPA, connectivity |
| 1 · Catalog 100 SKU | 2–4 | mapping NAV Item↔SKU, import + QA ครบ 100 |
| 2 · NAV product/stock/price API | 3–6 | sync สินค้า/สต๊อก/ราคา + กัน oversell |
| 3 · Order middleware + สถานะกลับ | 5–8 | order→NAV (idempotency) + shipped/invoiced กลับ |
| 4 · ChillPay + Shippop + LINE OA | 6–9 | จ่ายเงิน + จัดส่ง + COD + สมัคร/แจ้งเตือน LINE |
| 5 · Reconciliation + e-Tax + UAT | 9–11 | dashboard กระทบยอด, ใบกำกับภาษี, UAT ลูกค้า |
| 6 · Cutover + Hypercare | 11–12 | go-live + เฝ้าระวัง |

**Track ต่อยอด (หลัง core หรือขนานถ้ามีทีมพอ):** LINE CRM → Same-day → Telemed (เรียงตามนี้เพราะ Telemed ต้องพึ่ง Same-day + LINE ที่พร้อมก่อน)

---

## 11. User Journey (ฉบับเล่าได้ — ใช้เปิดประชุม/อธิบายทีม)

### Journey A — ลูกค้าซื้อยา/วิตามินทั่วไป (core go-live)
> **คุณสมหญิง** ปวดหัวอยากได้ยาสามัญ + วิตามิน เปิด LINE ร้านที่แอดไว้ กดเข้าหน้าร้าน PMaxx ผ่าน LIFF โดย**ไม่ต้องสมัครใหม่** (บัญชี LINE ผูกกับ PMaxx แล้ว) เลือกสินค้า — ระบบโชว์ราคา + สต๊อกที่ **sync มาจาก Navision** จริง กดจ่ายผ่าน **ChillPay** (QR/บัตร) สำเร็จ
>
> เบื้องหลัง: order วิ่งเข้า **middleware → สร้าง Sales Order ใน NAV** (กันซ้ำด้วย order ID) → เภสัชกรตรวจ/แพ็ก → เรียก **Shippop** ออก label + tracking → สถานะ "จัดส่งแล้ว" เด้งกลับมาที่ PMaxx และ **แจ้งเตือนทาง LINE** พร้อมเลขพัสดุ
>
> ปลายวัน: ทีม data เปิด **dashboard กระทบยอด** เห็นว่า order/เงิน/สต๊อก ระหว่าง PMaxx ↔ NAV ↔ ChillPay ↔ Shippop **ตรงกันหมด**

### Journey B — สมัคร/เข้าใช้งานผ่าน LINE OA (core go-live)
> ลูกค้าใหม่กดลิงก์ร้านใน LINE → **สมัครผ่าน LINE ทางเดียว** (แทนของเดิม 2 ทางที่พัง) → ระบบสร้าง account + ผูก LINE user id → ครั้งต่อไปเข้าได้เลยไม่ต้อง login ซ้ำ → รับแจ้งเตือนสถานะออเดอร์ผ่าน LINE

### Journey C — ops ฝั่งร้าน/เภสัชกร (core go-live)
> เภสัชกรเห็นออเดอร์ใหม่ → ตรวจว่า SKU ไหนต้องมีใบสั่งยา (ตาม flag) → ยืนยัน/แพ็ก → กดจัดส่ง (ผูก Shippop) → ระบบอัปเดต NAV + แจ้งลูกค้า ทุกอย่างอยู่ในลูปเดียว ไม่ต้องคีย์มือเข้า NAV

### Journey D — Same-day: ยาด่วนภายในวัน (project ต่อยอด — เล่าเผื่ออนาคต)
> **คุณสมชาย** ป่วยต้องได้ยาวันนี้ สั่งก่อนเวลา cut-off → เภสัชกรตรวจ/แพ็ก → ระบบเรียก **on-demand courier (Lalamove/Grab)** ไม่ใช่ Shippop → ลูกค้าเห็นคนขับวิ่งมาแบบ real-time → ได้ยาภายในไม่กี่ชั่วโมง

### Journey E — Telemed: ปรึกษาหมอ → ได้ยาส่งถึงบ้าน (project ต่อยอด — เล่าเผื่ออนาคต)
> **คุณยาย** ไม่สะดวกไปคลินิก เปิด LINE จองคิว → **วิดีโอคอลกับแพทย์** → แพทย์ออก **e-prescription** → ใบสั่งเด้งเข้าระบบร้านยา → สั่งซื้อ + จ่ายเงิน → **ส่ง Same-day** ถึงบ้าน
>
> journey นี้คือจุดที่ 3 project มาบรรจบ: **Telemed (ปรึกษา) → PMaxx (สั่ง/จ่าย) → Same-day (ส่ง)** ผ่านแกน LINE เดียว

---

## 12. Open Questions
| # | คำถาม | ใครตอบ | ภายใน |
|---|---|---|---|
| Q1 | NAV รุ่น/โฮสต์ (classic on-prem vs BC cloud) | IT ลูกค้า | Phase 0 |
| Q2 | SKU กลุ่มไหนขายออนไลน์ได้ / ต้องมี flow ใบสั่งยาไหม | กฎหมาย+เภสัชกร | Phase 0 |
| Q3 | เปิด COD ไหม | ลูกค้า | Phase 0 |
| Q4 | PMaxx มี module ChillPay/Shippop เดิม หรือ custom | ทีมเรา | Phase 0 |
| Q5 | Source of truth ต่อ entity (ราคา/สต๊อก/ลูกค้า) | ลูกค้า+เรา | Phase 0 |
| Q6 | single-merchant หรือ multi-vendor | ลูกค้า | Phase 0 |
| Q7 | ตัวเลขธุรกิจ (GMV คาด, จำนวนลูกค้า LINE) เพื่อเติม BRD | ลูกค้า | Review |