คำถามที่ต้อง clarify Open Q

ชื่อโครงการในเอกสารต้นทาง ไม่ตรงกันหลายแบบ — ต้องขอชื่อ canonical ของ product/project ที่ถูกต้องจาก SCCC ก่อนนำไปขึ้นปกข้อเสนอ/เอกสารส่งมอบ. ความเสี่ยงต่ำแต่เป็นสัญญาณว่า RFP ประกอบขึ้นจาก template เก่าที่นำมา reuse (ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน).

ชื่อที่พบ (verbatim)

• RFP cover (RFP p1): "QUEUING VISIBILITY & ONLINE CHECK-IN + ADVANCED SLOT BOOKING" — ใช้รูปแบบ & ... + ... และมีคำว่า "Slot" Booking ครบ. ชื่อนี้ปรากฏซ้ำในเนื้อ Purpose & Scope (RFP p4) และ Business Requirements Overview (RFP p11).
• RFP footer (เกือบทุกหน้า): "Insee Driver Mobile" — เป็นชื่อที่สี่ซึ่งต่างจากชื่อบนปกโดยสิ้นเชิง (เน้น "Driver Mobile" ซึ่งครอบคลุมเฉพาะฝั่ง Online Check-In ไม่รวม Advanced Slot Booking).
• Requirement Summary deck (SUM p1): title bar = "Queuing Visibility, Online Check-In & Advanced Booking" + subtitle "Requirement Summary". ใช้รูปแบบ , ... & ... และ ตัดคำว่า "Slot" ออก (เหลือ "Advanced Booking").

ความต่างที่ต้องเคลียร์

1. "Advanced Slot Booking" (RFP) vs "Advanced Booking" (SUM) — มีการดรอปคำว่า Slot.
2. เครื่องหมายวรรคตอน/ลำดับคำ: &...+... (RFP) vs ,...&... (SUM).
3. Footer "Insee Driver Mobile" เป็นชื่อผลิตภัณฑ์/แอปคนละชื่อกับชื่อโครงการบนปก — เป็นชื่อแอปคนขับ หรือชื่อโครงการรวม?

Stray footer (template leftover) — เอกสารปะปนกัน

• RFP p11 footer = "INSEE Premium Gift Management" (RFP p11) — หลุดมาจาก template โครงการอื่น.
• RFP p56 footer = "SMART SILO" (RFP p56) — หลุดมาจาก template โครงการอื่นอีกตัว (หน้า 57–58 กลับมาเป็น "Insee Driver Mobile").

ทั้งสอง footer ยืนยันว่า RFP ฉบับนี้ assemble ขึ้นจาก template ที่ใช้ซ้ำ ทำให้ต้องระวังว่าอาจมีเนื้อหา/ข้อกำหนดที่หลงเหลือมาจากโครงการอื่นปะปนอยู่ (cross-ref ปัญหา document-quality อื่น ๆ ใน ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน).

สิ่งที่ต้อง clarify กับลูกค้า

• ชื่อ canonical ของโครงการ/ผลิตภัณฑ์ที่จะใช้ในข้อเสนอและสัญญาคืออะไร — "Queuing Visibility, Online Check-In & Advanced Slot Booking"? หรือใช้ชื่อแบรนด์ "Insee Driver Mobile"?
• "Insee Driver Mobile" หมายถึงเฉพาะแอปคนขับ หรือเป็นชื่อรวมทั้งระบบ (รวม Advanced Slot Booking platform ด้วย)?

ตัวเลขที่ "ตัดสินใจไม่ได้" หลายตัวยังเป็น placeholder (XX / HH:MM / ±1H?) ที่ vendor ต้องผลักดันให้ SCCC กำหนดค่าให้แน่นอน — แต่ ไม่ว่าค่าจะลงตัวที่เท่าใด ทุกตัวต้องเป็น admin-configurable (RFP p20 row 1 "setting the radius and tolerance time"; RFP p34 NFR#10 "All Masters and Business Processes can be easy change with configuration only by Admin"; RFP p32 note "flexible configuration of booking conditions"). ค่าเหล่านี้กระทบ queue fairness, no-show handling และ customer experience โดยตรง — แยก master ค่าได้ที่ รัศมี Geofence สำหรับ off-site check-in และ Threshold เวลา tolerance / window / overdue.

รายการ threshold ที่ยังไม่ถูกกำหนด (พร้อมหน้า + ค่าปัจจุบัน)

หมายเหตุค่า "ที่ตัดสินแล้ว" (ไม่ใช่ open): Queue refresh = ทุก 30 วินาที (RFP p33 integration #4 "Every 30 Sec"; SUM p17 "Queue refresh (schedule 30 sec)") — ค่านี้กำหนดแล้ว ไม่นับเป็นช่องว่าง.

หมายเหตุ Booking Slot Period (1H per slot ที่ SUM p19 vs "2 hours per slot to 3 hours per slot" ที่ RFP p29 row 42) เป็นพารามิเตอร์คนละชุด → ดู พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก).

สิ่งที่ต้อง clarify

• ค่าจริงของแต่ละ threshold ข้างต้น (ทั้ง default value และช่วงที่อนุญาตให้ปรับ).
• เคลียร์ความขัดแย้ง parking-exit (30 mins ที่ SUM p17 เป็นค่าจริงหรือยังเป็นตัวอย่าง เนื่องจาก RFP ยังเขียน XX).
• ยืนยันว่า "ทุกค่าเป็น admin-configurable" ครอบคลุมทุกตัว รวมถึง geofence radius และ ±1H tolerance ด้วย.

ช่วงเวลาที่กำหนดว่า "จองล่วงหน้าได้เร็วหรือนานเพียงใด" ของ Advanced Slot Booking ยังไม่ได้ข้อสรุป โดยเฉพาะ lower bound (จองล่วงหน้าได้เร็วที่สุดเท่าใดก่อนเวลารับของ) — ค่านี้เป็นตัวกำหนดว่า product จะเป็นแบบ near-real-time booking หรือ day-ahead planning ซึ่งถือเป็นคนละ product กัน. รวมพารามิเตอร์ทั้งหมดไว้ที่ พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก).

หลักฐานที่ขัดกัน

• SUM p19 (Key Business Logic — booking matrix) ช่อง "Allow Booking Time" แสดง 2 ตัวเลือกสีแดง (= ยังไม่ได้ตัดสินใจ):
  • "Prior 2–168H?" หรือ
  • "Prior 24–168H?" (168H = 7 วัน)
• MIN (ภาพรวม Advanced Slot Booking): "ลูกค้าหรือผู้ขนส่งสามารถจองคิวล่วงหน้าได้ 3-7 วัน".
• RFP p32 (additional notes): "booking in advance within XX hours, or no minimum advance time required" — เปิดช่องให้กรณี "ไม่มี minimum advance" ได้ด้วย.

การวิเคราะห์ช่องว่าง

• Upper bound = 7 วัน (168H) สอดคล้องกันทุกแหล่ง (SUM 168H = MIN 7 วัน) ส่วนนี้ไม่มีปัญหา.
• Lower bound ขัดกันชัดเจน: 2 ชั่วโมง (SUM option A) vs 24 ชั่วโมง (SUM option B) vs 3 วัน (MIN) vs ไม่มี minimum (RFP p32).
  • หาก lower bound = 2H → ระบบต้องรองรับ near-real-time booking (จองวันนี้รับวันนี้).
  • หาก lower bound = 24H หรือ 3 วัน → เป็นแบบ day-ahead/วางแผนล่วงหน้า ซึ่ง demand-supply smoothing เป็นคนละ behavior.
  • MIN "3 วัน" ยังกว้างกว่าทั้ง 2H และ 24H ในสไลด์ และไม่ตรงกับ option ใดใน SUM p19.

สิ่งที่ต้อง clarify

• ยืนยัน minimum advance lead time ที่แท้จริง (2H / 24H / 3 วัน) และ maximum (ยืนยัน 7 วัน/168H).
• จะอนุญาต "no minimum advance" ตามที่ RFP p32 เปิดช่องไว้หรือไม่ (หากอนุญาต จะทับซ้อนกับ Online Check-In channel มากน้อยเพียงใด).
• ค่า lead-time นี้สัมพันธ์กับ Booking System Available Time = 24H (SUM p19) และ Booking Slot Period = 1H (SUM p19) อย่างไร.

มี 2 เรื่องที่ยังไม่ได้ข้อสรุปเกี่ยวกับ "การจัดลำดับคิวรวม" จากหลายช่องทาง — เป็นหัวใจของ queue-merge logic ที่ระบบใหม่ต้องสั่งให้ DAS ดำเนินการ. รายละเอียด algorithm อยู่ที่ Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ.

ประเด็น (1) — Priority conflict (advanced vs FCFS)

• RFP p17 (UC1 Business Logics): "The queue priority is the same for off-site, kiosk and check-in counter, depending on the time stamp of check-in 1 completion (FCFS – First Come First Serve or predefined logic)." → off-site/kiosk/counter อยู่ priority เดียวกัน เรียงตามเวลา CI1 เสร็จ.
• RFP p19 (UC2 Business Logics): "Queue of advanced slot booking is the 1st priority." + no-show ภายใน tolerance → cancel + เรียกคิวถัดไป.
• SUM p16 (Key Business Logic — Queue running logic & Priority): วางกรอบเป็น Advanced Slot Booking = Reserve (กันความจุไว้) ส่วน Online, Kiosk, Counter = FCFS, Depend on completed CI1 time. ตัวอย่าง slot "Customer books slot : 10.00 – 11.00 hrs. (CI2)" มีแถบแบ่งความจุระหว่าง Reserve กับ FCFS.

ความขัดแย้ง: RFP p17 ระบุว่าทุกช่อง priority เท่ากัน แต่ RFP p19 + SUM p16 ระบุว่า advanced มาก่อน (reserved). Net rule ที่น่าจะเป็น = advanced bookings outrank FCFS check-in แต่ ยังไม่ระบุชัดเจน:

• ลำดับ precedence ที่แน่นอนระหว่าง reserved กับ FCFS ภายใน slot เดียวกัน.
• สัดส่วนการแบ่งความจุ Reserve vs FCFS ภายใน 1 slot ไม่ได้ระบุเป็นตัวเลข (SUM p16 แสดงเพียงแถบ ไม่มีจำนวน) — ดู quota model ที่ โมเดล Booking quota.
• กรณี reserved slot ว่าง (no-show) → จะปล่อยให้ FCFS รับความจุนั้นทันทีหรือไม่ (RFP p19 ระบุว่า slot ถูก mark available + เรียกคิวถัดไป).

ประเด็น (2) — จำนวน channel: 3 vs 4

• MIN: "จะมีการจองคิว 3 รูปแบบ: Advanced Slot Booking, Online Check-in และ Walk-in" (ยืนยันซ้ำใน Q&A: "ยังมี จะมีการจอง 3 รูปแบบ...").
• SUM p16: ระบุ 4 channels: Advanced Slot Booking / Online Mobile Check-In / Kiosk Check-In / Counter Check-In.

→ "Walk-in" (3-channel ใน MIN) ถูกแตกเป็น Kiosk + Counter (4-channel ใน SUM p16). RFP p17 ก็กล่าวถึง "off-site, kiosk and check-in counter" สอดคล้องกับการแยก kiosk/counter. ต้องตกลง taxonomy ให้ตรงกันก่อนออกแบบ arbitration.

ประเด็นแถม — As-Is stage model ไม่ตรงกัน

โมเดล stage ของกระบวนการ As-Is ในสไลด์เองก็ไม่ตรงกัน:

• SUM p5 (process strip 6 ขั้น): เกทอิน → เช็คอิน → ชั่งเข้า → จ่าย/โหลด → ชั่งออก → เกทเอ้าท์ (Gate In → Check-In → Weigh In → Dispense/Load → Weigh Out → Gate Out).
• SUM p7 (Current Operational Challenges): Gate IN → Parking Area → Check IN 1 → Queuing → Check IN 2 → Parking Exit (มี check-in 2 จุด, ไม่มี weighing).

โมเดล CI1/CI2 (SUM p7) คือฐานของ To-Be two-stage check-in (การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In) ส่วนโมเดล 6-stage (SUM p5) คือ physical plant flow (Flow ขั้นตอนกายภาพในโรงงาน SRB (6 stages)) — ต้อง map ว่า "Check IN 1/2" อยู่ตำแหน่งใดเทียบกับการชั่งเข้า/ออก.

สิ่งที่ต้อง clarify

• precedence ที่แน่นอน + วิธีแบ่งความจุ reserved vs FCFS ภายใน slot (เป็นตัวเลข/สูตร).
• taxonomy ช่องทางสุดท้าย: 3 (Walk-in รวม) หรือ 4 (แยก Kiosk/Counter).
• map CI1/CI2 เข้ากับ 6-stage plant flow และตำแหน่งการชั่งน้ำหนัก.

ทุกสไลด์และ use case ใน RFP มุ่งไปที่ SRB (Saraburi / สระบุรี) เพียงแห่งเดียว แต่ minutes เปิดประเด็นโรงงาน Rayong (RYG) + ความต้องการ scale ไปยัง business unit อื่น — ต้องเคลียร์ว่า go-live เฟสแรกครอบคลุมกี่โรงงาน เนื่องจากกระทบ sizing, slot/quota master และจำนวน integration. ดู boundary หลักที่ ขอบเขตและขอบเขตงาน — อะไรอยู่ใน / นอก scope.

หลักฐาน

• RFP + สไลด์เกือบทั้งหมด: ระบุ "SRB plant" / "Saraburi" ตลอด (เช่น RFP p11, p16 use cases; SUM p11-14 "SRB FACTORY"). ไม่มีที่ใดกล่าวถึง Rayong นอกจาก minutes.
• SUM p10 (Improvement Idea — Scope): Outbound only; Cement, mortar, clinker; Bag & Bulk; Delivery & Pick-Up; support different SKUs/shipment; all Shipping Conditions (with or without MHE). — ระบุเฉพาะ scope สินค้า/movement ไม่ระบุชื่อโรงงานเพิ่ม (มีเพียง SRB ในเด็ค).
• MIN (Q&A):
  • Q: "Scope รวมงานที่โรงงานระยองด้วยหรือไม่?"
  • A: "รวมทุก SKU ทั้ง Cement ธรรมดาและ Mortar". → คำถามถามถึง Rayong โดยตรง แต่คำตอบ pivot ไปตอบเรื่องความครอบคลุม SKU ไม่ได้ตอบ yes/no เรื่อง Rayong ชัดเจน → ยังกำกวมว่า Rayong อยู่ใน scope go-live หรือไม่.
• RFP p35 (NFR Application Expansion & Scalability #20): "Easy to scale up or expand to other business units which are not in the current scope which able to support the number of users to 4,000 users or more (SCCC's regional company scaling)." + NFR #18 capacity ต้องรองรับ growth อย่างน้อย 3 ปี.
• ตอกย้ำ multi-entity: RFP p37 #34 "manage user access per country / company"; RFP p39 #54 training material "English and Thai, or in any other languages per SCCC's regional companies".

ความกำกวมที่ต้องเคลียร์

1. Rayong อยู่ใน initial scope (go-live) หรือเป็น phase ถัดไป? คำตอบใน minutes ไม่ชัดเจน.
2. go-live ครอบคลุมโรงงานใดบ้าง — SRB เพียงแห่งเดียว หรือ SRB + RYG?
3. expansion ไปยัง regional companies (4,000+ users) เป็น "ต้องออกแบบรองรับ" (NFR) แต่ไม่ได้ implement ในงวดนี้ — ขอยืนยันว่าอยู่นอก scope งวดนี้ใช่หรือไม่.

ผลกระทบ: จำนวนโรงงานตอน go-live เป็นตัวกำหนด sizing, จำนวน slot/quota master (per plant/sub-plant — เทียบ SUM p19 "Plant: 2", sub-plant K3/K4) และจำนวนจุด integration กับ DAS/upstream. ต้องชัดเจนก่อนตีราคา.

สอง open item ที่ SCCC mark TBC ไว้ชัดเจนบนสไลด์ และเป็นรายการที่ "รอ vendor เสนอวิธี" — ทั้งคู่เกี่ยวเนื่องกัน เพราะเป็นเรื่อง onboarding/identity ของคนขับฝั่ง PK. ดู persona ที่ คนขับ PK (Pick-up / ลูกค้ามารับของเอง) / คนขับ DL (Delivery / รถ Company-Fleet) และ login flow ที่ User account, registration & login (ทั้งสอง app).

(1) PK Driver Master ยังไม่มี → login/account format ยังไม่ได้ข้อสรุป

• SUM p16 (Key Business Logic — User):
  • "DL Driver : Required to logon & verify identity, using unique user ID"
  • "PK Driver : Not required verify the identity as of now, TBC for user login format due to currently we do not manage PK Driver Master" (บรรทัด PK พิมพ์แดง + ขีดเส้นใต้บนสไลด์) → SCCC ยังไม่มี master ของคนขับฝั่ง PK (รถลูกค้ามารับเอง) ในปัจจุบัน ⇒ รูปแบบ account/login ของ PK ยังตัดสินไม่ได้. DL ต้อง login + verify identity ส่วน PK ปัจจุบันยังไม่ต้อง.
• RFP p26 row 59 (User Login): "1 User account corresponds to 1 driver ID for both delivery & pick up mode. If the same driver ID is used for both DL & PK, implement either a separate account format or enable a distinct workflow under the same account." → ต้องออกแบบรองรับกรณีคนขับคนเดียวทำทั้ง DL และ PK.
• RFP p26 row 57: self-service registration "with a verification workflow that integrates with DID" (DID ยังไม่ได้ขยายความ — ดู คำย่อและรหัสที่ยังไม่ได้นิยาม).

(2) วิธี validate identity ของคนขับ = TBC (รอ vendor เสนอ)

• SUM p17 (Key Business Logic — Driver Identity): "Method to proceed driver's Identity validation for DL drivers" → "TBC (waiting vendor approach)" (พิมพ์แดง ขีดเส้นใต้). Requirement:
  • "Proceed after GI successfully or at GI station"
  • "Proceed before complete CI"
  • "Such as face scanning, fingerprint scanning"
• RFP p16 (UC1 preconditions/normal course): "identity verification step, such as facial scanning after user arrived at plant especially for DL service" / "Complete identity verification & input or scan RFID barcode to complete check-in 2".
• RFP p23 row 27: "For delivery shipment (DL), the application should be included as a feature to validate the driver's identity (e.g., face scanning, fingerprint scanning)".

→ method (face vs fingerprint vs อื่น), จุดที่ดำเนินการ (หลัง Gate-In หรือที่ GI station) และจังหวะ (ก่อนจบ CI) ยังเปิดให้ vendor propose.

สิ่งที่ต้อง clarify / ผลกระทบ

• รูปแบบ account/login ของ PK driver (จะสร้าง PK Driver Master ใหม่หรือใช้ identifier ใด เช่น เบอร์โทร/ทะเบียน).
• ขอบเขต identity verification ครอบคลุมเฉพาะ DL หรือจะขยายมา PK ในอนาคต.
• method biometric ที่เลือก → กระทบ hardware/SDK ที่ GI station, การ onboarding คนขับ, และ PDPA (การเก็บ/ประมวลผล biometric เป็น sensitive data).
• จุดติดตั้ง: "ที่ GI station" หมายถึงต้องมีอุปกรณ์ที่ด่าน หรือดำเนินการผ่านมือถือคนขับ.

SCCC ขอให้มี "วิธี validate เพื่อแยก truck ID ว่ามาจากช่องทางใด" แต่ mark ว่า TBC รอ vendor เสนอวิธี — นี่คือกลไกหลักที่ทำให้ DAS ทราบว่ารถคันหนึ่งมาจาก channel ใด (onsite / offsite / advanced booking) ตอน Gate-In แล้ว arbitrate คิวได้ถูกต้อง. เกี่ยวเนื่องกับ Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ และ logic ที่ระบบใหม่ต้องสั่ง DAS (Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking)).

หลักฐาน

• SUM p16 (Key Business Logic — Workflow):
  • middle: "Validate method to separate onsite / offsite / advanced slot booking truck ID"
  • right: "TBC (waiting vendor approach)" (พิมพ์แดง ขีดเส้นใต้) — "Create one master data table to register truck ID which proceed from what model (Able refresh when create / update / delete)". → แนวทางที่ SCCC เสนอ = ทำ master-data table เดียว ที่ลงทะเบียนว่า truck ID แต่ละคันมาจาก model/process ใด, refresh ได้เมื่อ create/update/delete. แต่ดีไซน์จริง vendor ต้องเป็นผู้เสนอ.

บริบทการใช้งานจริง (เหตุผลที่จำเป็น)

master นี้คือสิ่งที่ฝั่ง DAS ใช้ตอน Gate-In เพื่อจับคู่รถที่สแกนได้กับ request ที่ค้างอยู่:

• RFP p30 (DAS / Online CI rows 1–3): "Store off-site check-in request data as a master file" / "Record the virtual Check-In timestamp from off-site service" / "Log the timestamp of off-site queue calling".
• RFP p31 rows 6–9 (Online CI): "Capture the shipment or truck ID from off-site service and filter for the current date" / "Verify the truck IDs from off-site request data by comparing them with the scanned truck IDs at gate-in" / verify gate-in time & Truck ID → automated CI1 & CI2.
• RFP p31 row 14 + RFP p32 row 17 (Advanced Slot Booking): "Store booking data as a master file for each day (Booking ID, Truck ID, Shipment, Product SKU)" / "Verify the truck IDs from booking request data by comparing them with the scanned truck IDs at gate-in".

⇒ ทั้ง 3 channel (offsite check-in, advanced booking, onsite/kiosk) ต่างมี master/log ของ truck ID; ตอน Gate-In ต้องมี logic ตัดสินว่ารถคันนี้ match กับ master ตัวใด แล้วเดินทาง automated CI ตาม channel นั้น. master-table รวมที่ SUM p16 กล่าวถึงคือกลไกกลางของเรื่องนี้.

สิ่งที่ต้อง clarify / vendor ต้องเสนอ

• โครงสร้าง master-table (key, attribute "มาจาก model/process ใด", lifecycle create/update/delete/refresh).
• กติกาเมื่อ truck ID คันเดียวกัน match หลาย channel พร้อมกัน (เช่น จองล่วงหน้าไว้แต่ก็ทำ online check-in มาด้วย) → priority/resolution.
• ฝั่งใดเป็นเจ้าของ master นี้ (ระบบใหม่ หรือ DAS) — โยงกับ ownership ใน DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration).

จุดเสี่ยงเชิงพาณิชย์และเทคนิคที่ใหญ่ที่สุด (อ้างอิงจาก minutes โดยตรง). ระบบใหม่ต้อง interface กับ DAS เพื่อจองคิวและจัดสรรคิว แต่หากเจ้าของ platform ใหม่ ≠ เจ้าของ DAS การแลกเปลี่ยนข้อมูลอาจมี unforeseen cost และต้องระบุให้ชัดว่าใครรับผิดชอบส่งข้อมูล/รับภาระค่าปรับแต่ง DAS. ดูรายละเอียด DAS ที่ DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration) และเรื่อง booking platform ≠ driver app ที่ Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor.

หลักฐาน (MIN — ประเด็น Integration)

• "หาก Platform ใหม่เป็นคนละเจ้ากับระบบเดิม ต้องมีการแลกเปลี่ยนข้อมูล"
• "อาจมีค่าใช้จ่ายเพิ่มเติมในการเชื่อมต่อระบบ (Unforeseen Cost)"
• "Vendor ต้องอธิบายวิธีการบริหารจัดการข้อมูลและ Acceptability ของแต่ละ Platform"
• "สำหรับ GS: ต้องชี้แจงวิธีการเชื่อมต่อกับ DAS เนื่องจาก GS ถือ Driver Mobile App แต่ไม่ได้ถือระบบ Dashboard จัดการคิว" → vendor "GS" ถือแอปคนขับ แต่ ไม่ถือ Dashboard จัดการคิว (DAS) ⇒ ต้องอธิบายวิธีเชื่อมต่อกับ DAS.
• ข้อกำหนด vendor: "Vendor ต้องเสนอราคารวมทั้ง API และการปรับแต่งระบบ DAS ในข้อเสนอ" / "หากยังไม่ Clear เรื่อง Interface ต้องถามในช่วง RFP".
• ประเด็น Booking: "ต้องมีกลไกจัดการกรณีรถที่จอง Advanced Booking ไม่มาตามเวลา" + "ต้องชัดเจนว่าระบบไหนรับผิดชอบส่งข้อมูลอัปเดตในแต่ละกรณี" (เช่น no-show).

หลักฐาน (เอกสาร)

• SUM p20 / RFP p33 (Integration matrix): มี 6 integration ระหว่าง DAS / Mobile App / Platform — ส่วนใหญ่เป็น Real-time, queue status ทุก 30 วินาที. แถวที่ 6 "Booking confirmation: Platform → DAS" ยืนยันว่า "Platform" (booking) เป็นระบบแยกจาก "Mobile App" (driver) — โยง Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor. SUM p20 callout "Critical control points": data validation before check-in, queue status synchronization, cancellation consistency.
• RFP p34 (NFR — IP/Source code): #7 "Source Code and IP must be belonged to INDG" (กรณีเป็น custom development); #8 "source code must be store, develop and manage under INDG GitHub Code Repository during Project Execution Phase". → หาก vendor นำ product เดิมของตนมา reuse จะขัดกับเงื่อนไข IP-to-INDG อย่างไร ต้องเคลียร์ให้ชัด (โยง เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา).

สิ่งที่ต้อง clarify ก่อนตีราคา

1. DAS API พร้อมใช้งานหรือไม่ — มี API/spec ให้แล้วหรือยัง (interface spec อยู่ใน "Excel for business and interface requirement" ที่ยังไม่ได้รับ ดู เอกสารต้นทางสำคัญที่ถูกอ้างถึงแต่ยังไม่มีในมือ).
2. ใครเป็นเจ้าของ/ดูแล DAS และ ใครรับภาระค่าปรับแต่งฝั่ง DAS (DAS-side changes) — เนื่องจากอาจเป็น unforeseen cost.
3. ใครรับผิดชอบ "ส่งข้อมูลอัปเดต" ในแต่ละ scenario (เช่น no-show, cancel) — ระบบใหม่หรือ DAS.
4. สัญญา/ข้อตกลงกับเจ้าของ DAS (และเคส GS ที่ถือเฉพาะ Driver Mobile App).
5. การ reuse product เดิมของ vendor เทียบกับเงื่อนไข Source Code/IP-to-INDG + GitHub.

มีไฟล์แนบ/embedded หลายตัวที่ถูกอ้างถึงในเอกสารแต่ เรายังไม่มีตัวจริง — และเป็นไฟล์ที่ถือรายละเอียดสำคัญต่อ scoping/pricing (line-item ธุรกิจ, interface spec, booking policy, compliance guideline). ต้องขอเวอร์ชันล่าสุดจาก SCCC. หลายไฟล์ลงวันที่ 2021 ⇒ อาจเป็น legacy ที่นำมา reuse ต้องตรวจสอบว่ายัง current.

รายการเอกสารที่ขาด

RFP p58 — IV. APPENDIX (embedded OLE files)

• "Template_INDG Master Service Agree…" — Word (caption ถูกตัด) = Master Service Agreement template (เงื่อนไขสัญญา → โยง IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management / commercial terms).
• "210922_Conceptual Flow.pdf" — PDF workflow (ชื่อไฟล์ลงวันที่ 22 ก.ย. 2021).
• "20211004_RFP" — embedded package = "Excel for business and interface requirement" (ลงวันที่ 4 ต.ค. 2021) — น่าจะเป็น line-item ธุรกิจแบบละเอียด + interface spec (สำคัญที่สุดต่อการตีราคา integration; โยง Master data dictionary (โค้ด dispatch/transport/weight/segment/item) และ DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration) / ความเป็นเจ้าของ สัญญา และค่าใช้จ่ายของการ integrate ระบบกับ DAS / platform).

RFP p40 — IT Compliance Guideline (embedded PDF, binding)

• "INSEE Digital Project Application Development Guideline" (PDF icon caption ถูกตัด).
• "INSEE Digital Project Infrastructure and Security Guideline" (PDF icon caption ถูกตัด). ทั้งสองเป็น guideline binding Group-wide ที่ solution ต้อง comply (อ้างซ้ำใน NFR #1 / #26 / #33) และ vendor ต้องยื่น "official letter" ยืนยัน full compliance (RFP p40). โยง IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management.

SUM p19 — Booking quota

• "Booking Policy" Excel (green Excel icon, แนบข้าง "Booking Quota Planning" sheet) — ถือ logic การวาง quota จริง (ตัวอย่างในสไลด์ลงวันที่ 01-Aug-22, Plant 2, sub-plant K3/K4, 5 trucks/hr). โยง Master data dictionary (โค้ด dispatch/transport/weight/segment/item) (master codes) + quota model.

RFP p14 — Advanced Slot Booking flow

• "20230531_Online CL Bizflow Highlevel" PDF (attached-file icon ใต้ flow; caption ถูกตัดท้าย "(?" — ลงวันที่ 31 พ.ค. 2023) = high-level online cement-logistics business flow.

หมายเหตุ / สิ่งที่ต้อง clarify

• ไฟล์ appendix ลงวันที่ 2021 (ก่อน RFP ออก 19 พ.ค. 2026 ราว 4.5 ปี) → ขอยืนยันว่าเป็นเวอร์ชันปัจจุบันหรือมีอัปเดต.
• caption หลายไฟล์ถูกตัด (truncated/[ILLEGIBLE]) → ขอชื่อไฟล์เต็ม + ตัวไฟล์.
• ที่สำคัญที่สุดต่อ pricing คือ "20211004_RFP" (Excel business & interface requirement) และ Booking Policy Excel — ต้องได้รับก่อนตีราคา.

คำย่อ/รหัสที่ถูกใช้ในเอกสารโดย ไม่มีการนิยาม — ต้องรวบรวมส่งเป็น clarification list เพื่อป้องกันการตีความผิดตอน scoping. คำที่นิยามได้แล้วให้ย้ายไปที่ อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations); รหัส master ให้ย้ายไปที่ Master data dictionary (โค้ด dispatch/transport/weight/segment/item); ระบบต้นทางอยู่ที่ ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD.

คำย่อ — ระบบ/บทบาท

• DAS — "existing queue management system(DAS)" (RFP p20); ใช้ทั่วเอกสารแต่ ไม่เคยขยายตัวย่อ → ขอ full expansion + ขอบเขต (queue allocation backend; โยง DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration)).
• DL / PK — TransportType (SUM p19); DL ≈ Delivery (รถบริษัทจัดส่ง), PK ≈ Pick-up (ลูกค้ามารับเอง) [INFERRED จาก "อินทรีจัดส่ง"/"อินทรีรับของเอง" SUM p6 และ badge DL/PK บนจอ DAS]. ขอยืนยันความหมายให้ชัดเจน.
• DID — "verification workflow that integrates with DID" (RFP p26 row 57) — Digital ID / Driver ID? เป็นระบบ registration/verification → ขอความหมาย.
• OTM — "required modified data from OTM or other" (SUM p17) — Oracle Transportation Management? [INFERRED] (โยง ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD).
• INPLANT / INSEE+ / TMS — แหล่ง sync ข้อมูล (RFP p22 row 23 "TMS and INPLANT"; RFP p27 row 13 "TMS or INSEE+"). ต้องระบุให้ชัดว่าตัวใด authoritative สำหรับ shipment validation.
• MS AD — "sync MS AD (Account Directory)" (RFP p37 #37) = Microsoft Active Directory? [INFERRED].
• INDG — ผู้ถือ IP/Source/GitHub (RFP p34) = INSEE Digital [INFERRED].

คำย่อ — process/feature

• MHE — "all Shipping Conditions (with or without MHE)" (SUM p10) = Material Handling Equipment? [INFERRED].
• GICI — "Booking During GICI → Not Allow" (SUM p19) = Gate-In/Check-In combined? [INFERRED].
• "DL service" — "especially for DL service" (RFP p16) — บริการกลุ่ม Delivery ที่ต้อง facial verify; ขอขอบเขตให้ชัดเจน.
• "SKU (1st brand)" — queue display field (RFP p24 row 34) — "1st brand" คือ brand แรก/หลักบน DO? ยังไม่ชัดเจน.
• "predefined algorithm" — slot suggestion "suggested by a predefined algorithm" (RFP p12, RFP p19 row; SUM ไม่ระบุ) — ตัว algorithm/อินพุตธุรกิจไม่ได้นิยาม → ขอ business rule.

รหัส master (จาก SUM p19 booking matrix / quota sheet) — ดู Master data dictionary (โค้ด dispatch/transport/weight/segment/item)

• WeightType: 001 / 002 / 004 / 888 / 999 / 101 — ความหมายแต่ละรหัส?
• ItemType: BG / BK / CL / BB — BG=bag, BK=bulk, CL=clinker [INFERRED]; BB ไม่ระบุ.
• Material codes: RMX / IDUM / Quick Cast (และ BULK21–34 channel codes) — ขอ data dictionary.
• MarketSegment: Domestic / Border / Export (ระบุแล้ว แต่ขอยืนยัน scope).

Action

รวบรวมทั้งหมดเป็น clarification list เดียวส่ง SCCC; mapping ที่ยืนยันแล้วย้ายเข้า อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations) / Master data dictionary (โค้ด dispatch/transport/weight/segment/item).

ความไม่สอดคล้องใน RFP ที่ vendor ควรพิจารณา flag/ยืนยัน — ส่วนใหญ่ไม่ใช่ blocker แต่หลายข้อกระทบ scope/pricing (โดยเฉพาะ Non-Critical SLA ที่หายไป). โยงปัญหา footer/naming ที่ ชื่อโครงการที่ไม่สอดคล้องกัน และ footer ที่หลงเหลือจาก template.

รายการที่ต้องยืนยัน

1. Non-Critical SLA section หายไป / TOC ผิดพลาด — TOC (RFP p2) บรรทัด "Option 2: Non-Critical Application SLA" แสดง "Error! Bookmark not defined." แทนเลขหน้า (Word cross-ref เสีย). ในตัวเอกสารมีเพียง Option 1: Critical Application SLA (RFP p50). ⇒ section Non-Critical SLA อาจหายไปจริง. กระทบ pricing/scope ของ MA โดยตรง — หากลูกค้าจะ classify ระบบนี้เป็น non-critical แต่ไม่มี SLA tier ให้ยึด. โยง ขอบเขต Application Maintenance, SLA & กฎ change request.

2. จำนวน environment ไม่ตรงกัน — RFP p33 NFR#2 ระบุ landscape "DEV, QA/UAT and PRD" (3 ชุด) แต่ RFP p35 NFR#18 ระบุ "Minimum two system landscape: (1) development/testing, and (2) production" (2 ชุด). ⇒ 2 หรือ 3 environment? กระทบ hosting/infra cost. โยง สถาปัตยกรรมโซลูชัน การ hosting และ landscape.

3. Queue notification ระบุ "3 parts" แต่ list มี 4 bullet — RFP p24:

   • row 41: "Queue notification message will include 3 parts" → list 3 bullet (Your Queue is ready / Link to loading documents / Latest End time for entering loading area).
   • row 42: "Queue notification message will be included 3 parts" → แต่ list 4 bullet (Your Queue is ready / Latest gate-in time / disclaimer / Link to loading documents). ⇒ ทั้งสองระบุ "3 parts" แต่ row 42 มี 4 รายการ และเนื้อหา row 41 ≠ row 42. ขอ content ที่เป็น canonical.

4. Compliance scale ไม่เท่ากัน — NFR table (RFP p33-39) ใช้ "F/P/N/NA" (4 ระดับ) แต่ IT Compliance Guideline (RFP p40) และ IMC/IT-security checklist ใช้ "F/P/N" (3 ระดับ ไม่มี NA). ขอยืนยัน scale ที่ต้องกรอกในแต่ละตาราง.

5. Template-leftover footers — RFP p11 footer "INSEE Premium Gift Management", RFP p56 footer "SMART SILO" (หน้าอื่นเป็น "Insee Driver Mobile"). เป็นสัญญาณว่า RFP ประกอบขึ้นจากการ reuse template → ต้องระวังเนื้อหาที่หลงเหลือ. รายละเอียดเต็มที่ ชื่อโครงการที่ไม่สอดคล้องกัน และ footer ที่หลงเหลือจาก template.

6. Typos / numbering anomaly — มี typo ซ้ำ ๆ ทั่วเอกสาร (เช่น "trough" = through, "Validtion", "Cencel", "Sigle Sign On", "Reponse Time" RFP p50, "Outbound Weight Bride" = weighbridge RFP p31/p32) และ numbering anomaly ในกลุ่ม Application Maintenance SOW / IMC access-control (ลำดับ a)…h) แล้ววน iv./v. แล้วกลับ c)…h), จากนั้น l) → i) → j) ที่ RFP p47-49). ไม่ใช่ blocker แต่ทำให้อ่าน scope สับสน.

7. (แถม) ข้อความ integration ถูกตัด — RFP p33 integration #4 detail = "Update queue status information to" (ประโยคขาด ปลายตัด; receiver = Mobile App). + RFP p50 ไม่ระบุ % liquidated damages สำหรับ P4/SR/CR (มีแต่ P1=10%, P2&P3=5%).

สรุป

ไม่มีข้อใดเป็น hard blocker แต่ #1 (Non-Critical SLA หายไป) และ #2 (จำนวน environment) กระทบราคา/scope ⇒ ต้อง confirm ก่อนยื่นข้อเสนอ.