DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration)
DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration)
DAS คือระบบ queue-management / dispatch backend เดิมของ SCCC ที่โรงงาน SRB และเป็น ระบบศูนย์กลางที่โซลูชันใหม่ต้อง integrate ด้วย RFP นิยามไว้ชัดเจนว่าเป็น "existing queue management system(DAS)" (RFP p20, FR1) และ "existing SCCC's TMS & Queue management system: DAS" (RFP p26 row7) DAS เป็น source-of-truth ของข้อมูล shipment และ truck ที่ sync มา เป็นผู้รับกิจกรรมการเช็คอิน เป็น engine ที่จัดสรรและเรียกคิว และเป็นระบบที่สร้างรายงาน/dashboard ทุก functional flow ใน RFP ยึดอยู่กับ DAS
ตัวเต็มของ "DAS" ไม่ได้ระบุไว้ที่ใดในเอกสารต้นทาง [INFERRED — น่าจะเป็น Dispatch/Allocation System หรือ dispatch-automation backend ในทำนองนั้น; extract ยังลอย ๆ ถึง "Driver/Dispatch/Delivery Automation System"] ให้ถือว่าความหมายยังไม่ได้รับการยืนยัน — ดู คำย่อและรหัสที่ยังไม่ได้นิยาม
Integration ที่นิยามไว้ 6 รายการ (RFP p33 / SUM p20)
ตาราง "Integration information with another system (if required)" ใน RFP (RFP p33) — ซึ่งคัดลอก verbatim ไว้บน deck (SUM p20) — นิยาม integration ไว้ 6 รายการ ระหว่าง actor สามตัว ได้แก่ DAS, Mobile App (แอปเช็คอินของคนขับ) และ Platform (ระบบจองคิว) ช่อง "User Case Name" จับคู่แต่ละ integration เข้ากับ UC1 (Online Check-In) และ/หรือ UC2 (Advanced Slot Booking)
| # | Integration name | Detail | UC | Sender → Receiver | Frequency |
|---|---|---|---|---|---|
| 1 | Shipment data | Create / update / delete shipment information event | 1,2 | DAS → Mobile App | Real-time |
| 2 | Data validation | Validate the data inputting from Mobile app | 1,2 | Mobile App → DAS | Real-time |
| 3 | Check-In 1 & 2 Update | Sending check-in activity to DAS for queue booking or relevant process | 1,2 | Mobile App → DAS | Real-time |
| 4 | Queue status update | Update queue status information to Mobile app | 1,2 | DAS → Mobile App | Every 30 Sec |
| 5 | Cancel event | Sending queueing cancellation transaction to DAS | 1,2 | Mobile App → DAS | Real-time |
| 6 | Booking confirmation | Sending booking detail to reserve a slot on queue management system | 2 | Platform → DAS | Real-time |
หมายเหตุเกี่ยวกับตาราง:
- Integration #4 (Queue status update) เป็นลิงก์เดียวที่ไม่ใช่ real-time — ทำงาน Every 30 Sec (ตรงกับ business logic "Queue refresh (schedule 30 sec)" บน SUM p17) บน RFP p33 ข้อความ detail ถูกตัด ("Update queue status information to") โดยฉบับบน deck (SUM p20) เติมต่อให้ครบเป็น "...to Mobile app" ซึ่งสอดคล้องกับคอลัมน์ Receiver
- Integration #6 (Booking confirmation) เป็น UC2-only และเป็น integration เดียวที่ ส่งโดย "Platform" แทนที่จะเป็น "Mobile App" — ชี้ว่า booking platform เป็นระบบที่แยกออกมาต่างหาก ดู Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor
- FR1 (RFP p20) อธิบายลิงก์โดยรวมว่า "providing mostly real-time updates" — สังเกตคำว่า "mostly" ที่กำกับ SLA แบบ real-time ไว้
จุดควบคุมสำคัญ (SUM p20)
Deck ระบุ "Critical control points" สำหรับการ integration กับ DAS ไว้สามจุด:
- Data validation ก่อนเช็คอิน (เป็นด่านกั้นระหว่าง integration #2 → #3);
- Queue status synchronization (integration #4, refresh ทุก 30 วินาที);
- Cancellation consistency (integration #5 — รักษาให้ DAS กับ app/platform สอดคล้องกันเมื่อมีการยกเลิก)
DAS ในฐานะ source-of-truth ตลอด functional requirements
ตลอดทั้ง FR matrix DAS ถูกระบุซ้ำ ๆ ว่าเป็นระบบที่:
- Sync ข้อมูล shipment และ truck ไปยังแอป — ข้อมูล shipment และ truck "synced from DAS system" (RFP p23 rows29–30; RFP p27 rows15–16); RFID No. "validated against the data synced from DAS" (RFP p22 row21); shipment ID แบบ Pick-up-mode ถูก validate "against SCCC's TMS or DAS" (RFP p22 row20)
- จัดสรรและเรียกคิว — เมื่อ check-in request สำเร็จ แอปจะ "automatically send the queue request to DAS for queue allocation" (RFP p24 row32) แล้ว "sync & receive queue data from DAS" (RFP p24 row33); แอปรับ update จาก DAS หลังคิวถูกเรียก / หลังจัดสรร (RFP p24 rows36, 39)
- ขับเคลื่อน logic การเช็คอินสองขั้น — ระบบใหม่ส่ง Check-In 1 & 2 ไปยัง DAS (integration #3) และ DAS ทำ auto-cancellation เมื่อ gate-in หายไป/ล่าช้า ("the queue will be automatically canceled from DAS", RFP p24 row38; RFP p25 row45) ดู การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In และ Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking)
- ถือ master data ของ off-site / virtual check-in — requirement group "DAS" โดยเฉพาะ (RFP p30 rows1–4) กำหนดให้ DAS เก็บข้อมูล off-site check-in request เป็น master file, บันทึก timestamp ของ virtual Check-In, log เวลาเรียกคิว off-site และ log เวลา gate-in ที่กำหนด "to arrive within XX mins after queue calling" (XX ยังไม่นิยาม — ดู Threshold เวลา tolerance / window / overdue)
- จัดเตรียมเอกสาร loading — แอป "receive loading document from DAS to display on mobile app (Per DO, Max 11 DO)" (RFP p24 row43)
- สร้างรายงานและ dashboard — ระบบใหม่ต้อง "provide queue information data to DAS for generation of report and dashboard" (RFP p25 row54) และป้อน booking data ให้ DAS เช่นกัน (RFP p30 row52) ส่วน dashboard แสดง off-site / advanced-slot นั้นจะถูก "added in DAS" (RFP p31 rows11, p32 row21)
ผลต่อด้านการค้า / ความเป็นเจ้าของ (MIN)
บันทึกการประชุมทำให้ลิงก์ DAS เป็นสิ่งที่ต้องคิดต้นทุนส่งมอบ ไม่ใช่ของที่ได้มาฟรี:
- "Vendor ต้องเสนอราคารวมทั้ง API และการปรับแต่งระบบ DAS ในข้อเสนอ" — vendor ต้องคิดราคาทั้ง API และการ customise DAS ไว้ในข้อเสนอ (MIN)
- "หาก Platform ใหม่เป็นคนละเจ้ากับระบบเดิม ต้องมีการแลกเปลี่ยนข้อมูล... อาจมีค่าใช้จ่ายเพิ่มเติม (Unforeseen Cost)" — หาก platform ใหม่เป็นคนละเจ้ากับระบบเดิม จะต้องมีการแลกเปลี่ยนข้อมูล และอาจมีต้นทุน integration ที่คาดไม่ถึง (MIN)
- เฉพาะกรณี vendor GS: GS ถือ Driver Mobile App แต่ไม่ได้ถือ Dashboard จัดการคิว ดังนั้น GS ต้องอธิบายว่าจะเชื่อมต่อกับ DAS อย่างไร (MIN) ดู Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor และ ความเป็นเจ้าของ สัญญา และค่าใช้จ่ายของการ integrate ระบบกับ DAS / platform
- "หากยังไม่ Clear เรื่อง Interface ต้องถามในช่วง RFP" — หากยังไม่ชัดเรื่อง interface ต้องสอบถามในช่วง RFP (MIN)
ประเด็นที่ยังเปิดอยู่
- ตัวเต็มของ "DAS" ยังไม่ได้รับการยืนยัน → คำย่อและรหัสที่ยังไม่ได้นิยาม
- Integration ownership, ขอบเขตสัญญา และต้นทุน (ใครสร้าง/เป็นเจ้าของลิงก์ DAS↔Platform และความเสี่ยงเรื่อง unforeseen cost) → ความเป็นเจ้าของ สัญญา และค่าใช้จ่ายของการ integrate ระบบกับ DAS / platform
- รูปแบบ API, schema และเครื่องมือ monitor interface ที่แน่ชัดไม่ได้ถูกระบุใน requirement (ระบุเพียงว่าต้องมี standard API + integration monitoring ในระดับ NFR, RFP p38 rows43–45) — เก็บไว้ใน ความต้องการด้านเทคโนโลยีการ integration (API, monitoring)