Flow ขั้นตอนกายภาพในโรงงาน SRB (6 stages)

เอกสารนี้อธิบายเส้นทางกายภาพที่รถบรรทุกปูนวิ่งผ่านโรงงาน SRB (Saraburi) ในสถานะ As-Is ซึ่งเป็น "ฉากหลัง" ของทั้งฟีเจอร์ Online Check-In และ Advanced Slot Booking. ในสไลด์ Requirement Summary ปรากฏ โมเดล stage สองชุดที่ไม่ตรงกัน จึงต้องระมัดระวังเมื่ออ้างอิง.

Model A — 6-stage plant strip (SUM p4-5)

แถบ 6 ช่อง (ภาพ 6 tile เรียงจากซ้ายไปขวา) แทน flow ของรถที่วิ่งผ่านโรงงาน (SUM p4, ปรากฏซ้ำบน SUM p5):

1. เกทอิน — Gate-In (ที่ SUM p4 ช่องนี้ถูกไฮไลต์/ขยายเป็นรายละเอียด)
2. เช็คอิน — Check-In (ที่ SUM p5 ช่องนี้ถูกไฮไลต์ด้วยกรอบแดง = scope ที่ระบบใหม่โฟกัส)
3. ชั่งเข้า — Weigh-In (ชั่งน้ำหนักขาเข้า / inbound weighbridge)
4. จ่าย/โหลด — Dispatch/Load (โหลดสินค้า)
5. ชั่งออก — Weigh-Out (ชั่งน้ำหนักขาออก / outbound weighbridge)
6. เกทเอ้าท์ — Gate-Out

รายละเอียด Stage 1 (เกทอิน / Gate-In) ที่ SUM p4 ขยายเป็น 4 actor/equipment column ได้แก่ พนักงานขับรถ (เป่าแอลกอฮอล์ด้วยตนเองที่ตู้จ่ายบัตร, รับบัตรรับ-ส่งสินค้า, ยกเลิกแบบฟอร์มขอรับปูนซีเมนต์), ระบบอ่านป้ายทะเบียนอัตโนมัติ (ALPR) + ไม้กั้น (barrier gate), ตู้จ่ายบัตรรับ-ส่งสินค้า (เลือกประเภทรับสินค้า: รับเอง / รับ-ส่งสินค้า), และ ห้องควบคุม (เจ้าหน้าที่ 1 คน/กะ) (SUM p4). ฮาร์ดแวร์ As-Is เหล่านี้แยกเก็บไว้ที่ ฮาร์ดแวร์เดิมในโรงงาน — kiosk, counter, card reader, ALPR, DAS display board.

Stage 2 (เช็คอิน / Check-In) คือจุดที่ระบบใหม่เข้าไปแทนที่/เสริม: As-Is ดำเนินการที่ ตู้ออกเอกสารอัตโนมัติ (scan บัตร) สำหรับการรับสินค้า และที่ เคาน์เตอร์ (ยื่นบัตร) สำหรับการรับ-ส่งวัตถุดิบ (SUM p5). รายละเอียด swimlane ของขั้น Check-In อยู่ที่ Swimlane การ Check-In แบบ As-Is (Kiosk / RFID-card based).

Model B — operational-challenges stage band (SUM p7)

หน้า "Current Operational Challenges" (SUM p7) วาด flow เป็นคนละชุด โดยใช้ chevron »»» คั่น:

Gate IN → Parking Area → Check IN 1 → Queuing → Check IN 2 → Parking Exit

โมเดลนี้มี สอง check-in step (Check IN 1 และ Check IN 2) และ ไม่มี stage ชั่งน้ำหนัก/โหลด ปรากฏเลย แต่เพิ่ม Parking Area และ Queuing เข้ามาแทน. ตัวเลข load บนหน้านี้ (Max 77 trucks/hr ที่ GI, Max 78 drivers/hr ที่ CI, 1000 SH/DAY, 100% Check-In, 40% in peak ~15:00–19:00) เป็น baseline ของ current state (SUM p7) เก็บไว้ที่ ปัญหาการดำเนินงานในปัจจุบันและปัจจัยขับเคลื่อนทางธุรกิจ (business drivers).

ความไม่ตรงกัน / สิ่งที่ต้อง reconcile

โมเดล A (Gate-In → Check-In → Weigh-In → Dispatch/Load → Weigh-Out → Gate-Out) กับโมเดล B (Gate IN → Parking Area → Check IN 1 → Queuing → Check IN 2 → Parking Exit) ไม่ line up กัน: โมเดล A มี check-in เดียว + ชั่ง/โหลด ชัดเจน ส่วนโมเดล B มี check-in สองขั้น (CI1/CI2) แต่ไม่แสดงว่าการชั่งน้ำหนัก/โหลด ไปอยู่ตรงไหนเมื่อเทียบกับ CI1/CI2. แนวคิด CI1/CI2 ที่ระบบใหม่ใช้จริงอยู่ที่ การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In. ความขัดแย้งของ stage model รวมถึงช่องทางคิว flag ไว้ที่ ความขัดแย้งของลำดับความสำคัญคิว และความไม่ตรงกันของจำนวน channel (3 vs 4).

ขอบเขตการรับรู้ของระบบใหม่: ระบบที่ลูกค้าต้องการให้โฟกัสอยู่ที่ขั้น Check-In และ queue visibility เท่านั้น ไม่ได้เข้าไปยุ่งกับกลไกการชั่งน้ำหนัก/โหลดสินค้า (SUM p5 ไฮไลต์เฉพาะช่อง Check-In; โมเดล B ก็เน้นปัญหาที่ Check IN 1/2 + Queuing).

Swimlane การ Check-In แบบ As-Is (Kiosk / RFID-card based)

BPMN swimlane ของกระบวนการ check-in ในปัจจุบันที่โรงงาน SRB ปรากฏตรงกันทั้งใน Requirement Summary (SUM p3) และ RFP (RFP p12) ภายใต้กรอบชื่อ "SCCC Cement : Check-In Process at SRB-Plant (As-Is)" เมื่อ cross-confirm แล้วทั้งสองเอกสารตรงกัน จึงกำหนดสถานะเป็น confirmed. กระบวนการนี้คือ baseline ที่ To-Be จะ replicate ไปทำบนมือถือ โดย RFP p16 ระบุ precondition ไว้ชัดเจนว่า "Replicate the necessary check in steps from kiosk check-in".

กระบวนการ As-Is เป็นแบบ RFID-card / ตู้ Kiosk physical และกำหนดให้คนขับต้องมาดำเนินการที่หน้างานจริง (สอดคล้องกับ MIN: "คนขับต้องมาเช็คอินที่โรงงานแบบ Physical ผ่านตู้ Kiosk ไม่สามารถแพลนได้ล่วงหน้า") ประกอบด้วย 3 swimlane ดังนี้:

Lane 1 — Gate In – Check In 1

1. Gate-IN (จุดเริ่มต้น) — key actions: Truck ID validation / Alcohol Testing / Receive RFID Card (SUM p3, RFP p12)
2. → decision Has Shipment ?
   • YES → Scan RFID Card
   • NO → Contact SCCC at Counter → Driver complete form → SCCC Verify & check in system → วนกลับขึ้นไปที่ Scan RFID Card (fallback แบบ manual เมื่อไม่มี shipment)
3. Scan RFID Card → Input shipment ID & Update information → Scan fingerprint (Only for DL) → decision Confirm ?
   • NO → วนกลับไป Input shipment ID & Update information (เป็นการ retry แก้ข้อมูล ไม่ใช่ hard reject)
   • YES → Complete Check In 1 (กล่อง shaded; key actions: Book Queue / Print Queue Slip)
4. จาก Complete Check In 1 ไหลต่อลงไป Lane 2

Lane 2 — Waiting Queue

• Queue Display on screen (จอ/ทีวี) → SCCC remind the queue (ประกาศเรียกคิว) → ไหลต่อลงไป Lane 3

Lane 3 — Check In 2 – Parking Exit

• Scan RFID Card → Complete Check In 2 (กล่อง shaded; key action: Print Loading Docs.) → Pass trough Parking Exit (สะกด "trough" verbatim ตามต้นฉบับ = "through") (จุดสิ้นสุด)

ข้อสังเกตเชิงวิเคราะห์

• Fingerprint = Only for DL เท่านั้น (SUM p3, RFP p12) โดย DL ในที่นี้หมายถึง delivery / รถจัดส่งของบริษัท ([INFERRED] expansion — ดู อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations)) ทิศทางนี้สอดคล้องกับ To-Be ที่ DL driver ต้อง verify identity ส่วน PK ยังไม่บังคับ (SUM p16)
• As-Is ออกเอกสารเป็นกระดาษ/งานพิมพ์: Print Queue Slip (CI1) และ Print Loading Docs. (CI2) ซึ่ง To-Be จะแปลงเป็น E-Loading Doc บนแอป
• Two-stage check-in (CI1 ที่ gate-in, CI2 ก่อน parking exit) มีอยู่แล้วใน As-Is และถูกยกแนวคิดไปใช้ต่อใน To-Be — ดู การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In
• ระบบ physical/walk-in เดิมยังคงอยู่ หลังมีระบบใหม่ (MIN Q&A: "ยังมี จะมีการจอง 3 รูปแบบคือ Advanced Slot Booking, Online Check-in และ Walk-in") As-Is นี้จึงเป็นทั้ง baseline และ fallback channel ในอนาคต ส่วน To-Be flow ที่เข้ามา replace/เสริม อยู่ที่ Flow Online Check-In แบบ To-Be (mobile แบบ geofence, CI1 → Gate-In → CI2) และ Flow Advanced Slot Booking แบบ To-Be (web booking → Gate-In validation → CI2)

Flow Online Check-In แบบ To-Be (mobile แบบ geofence, CI1 → Gate-In → CI2)

To-Be flow ของ Use Case #1 — "Check-In online prior arriving at SRB plant" (RFP p16): คนขับเริ่ม check-in ผ่านมือถือก่อนถึงโรงงานเมื่ออยู่ในรัศมีที่กำหนด แล้วมาทำ check-in 2 ให้เสร็จที่หน้างานหลัง gate-in. cross-confirm ทั้ง SUM (p11-12) + RFP (p13, p16-17, p30-31) → confirmed.

High-level 4-step (SUM p11 / RFP p13)

สองโซนคั่นด้วยเส้นประ: Within radius | SRB FACTORY

1. Check-In — Mobile Check-In within defined radius; sub-flow pill: Booking » Waiting » Queue Call » Driving; ติดป้าย "Check In 1"
2. Arrived at factory — Arrive at SRB factory by window time
3. GATE IN — GATE In process: Alcohol Check / Truck ID validation / Receive RFID / Off-site validation
4. Parking Exit — Pass through parking exit

KEY Highlights (SUM p11, RFP p13): ระบบ validate current location ของคนขับด้วย GPS จากมือถือว่าอยู่ในรัศมีที่รับได้หรือไม่; เมื่อ booking เสร็จ + คิวกำลังเรียก คนขับต้องมาถึง SRB & GATE IN on time.

Detailed swimlane (SUM p12 / RFP p13) — "SCCC Cement : Check-In Process at SRB-Plant (Mobile Check-In)"

ประกอบด้วย 3 lane:

Lane 1 — Offsite Booking (Check In1)

• Gate In ? — Yes → Onsite (fallback เข้าสู่ flow หน้างานเดิม); NO → Radius valid ? (annotate "GPS Validation")
• Radius valid ? — NO → END "Feature not available"; Yes → Has Shipment ?
• Has Shipment ? — YES → Select SH; NO → Input SH No. → SH Validation (Fail → loop กลับ Input SH No.; Pass → Update info.)
• - Update info. — note: "Depend on item type : Bag / Bulk / clinker — 1. Display SH info. & Truck Info 2. Update field by selected list"
• → Confirm Data ? (NO → loop กลับ Update info.) → Confirm CI1 ? (annotate "Display estimated time")
• Confirm CI1 ? — YES → Complete Check In 1 (key action: Book Queue at DAS); NO → Cancel Queue (path "Manual cancel")

Lane 2 — Waiting Queue

• Display queue status (Queue ID / Estimated time / Current status) → Notify when queue calling → Display latest time for gate in at plant
• Alert channels: 1. pop-up in app 2. banner at homescreen 3. pop up at lock screen; When: 1. prior queue call XX mins 2. queue call (XX = placeholder — ดู Threshold เวลา tolerance / window / overdue)
• Cancel Queue รับ path: Manual cancel, Delay (Auto Cancel), และ "Out side window time (Auto cancel)" ที่ย้อนมาจาก Lane 3

Lane 3 — Gate In – Parking Exit

• Gate-IN — key actions: Truck ID validation / Alcohol Testing / Receive RFID Card → Offsite ? (key action: "Master check")
  • NO → Onsite (fallback)
  • YES → Queue Calling ?
• Queue Calling ? — NO → "Out side window time (Auto cancel)" → Cancel Queue; YES → Ontime ?
• Ontime ? — NO → "Outside window time (Auto cancel)" → Cancel Queue; Yes → Complete Check In 2 (key action: Generate & Display E-Loading Doc)
• → Display E-Loading Doc (Inform latest time for pass through parking exit) → Pass trough Parking Exit → Ontime → Load-In (happy path จบ); delay → Cancel Queue

Business logic / rules (RFP p16-17)

• Activity sequence บังคับ: Check in 1 (Mobile) > Gate In > Check In 2 (Mobile) (RFP p17)
• Postcondition (RFP p16): หลังคนขับทำ check-in 1 บนแอป → trigger DAS เพื่อ book queue + แนะนำ estimated time ที่จะมาถึงเพื่อทำ check-in 2
• Precondition (RFP p16): enable feature เมื่อคนขับอยู่รอบ SRB (validate geofencing ของ GPS), replicate ขั้นตอนจำเป็นจาก kiosk check-in (Swimlane การ Check-In แบบ As-Is (Kiosk / RFID-card based)), interface กับ DAS, และมีขั้น identity verification เช่น facial scanning หลังถึงโรงงาน โดยเฉพาะ DL service
• คนขับ ไม่ต้องลงจากรถ เมื่อทำ online check-in ล่วงหน้าแล้ว (RFP p32; MIN: "เอกสารจะแสดงในแอปโดยคนขับไม่ต้องลงจากรถ")
• Frequency: Daily, 700–1000 transactions per day (RFP p17)
• เงื่อนไข tolerance/window/overdue: arrival นอก window time → queue rejected (เทียบกับ Gate-In timestamp); มาก่อน window → ผ่าน gate ตามปกติแล้วรอ CI2 ตอนคิวเรียก; parking-exit เกิน overdue → queue rejected/hold (RFP p17). ค่าตัวเลขทั้งหมดอยู่ที่ Threshold เวลา tolerance / window / overdue / รัศมีอยู่ที่ รัศมี Geofence สำหรับ off-site check-in

DAS-side logic ที่ flow นี้ต้องขับ (RFP p30 rows 1-4, RFP p31 rows 5-13)

DAS ต้อง store off-site check-in เป็น master file, record virtual Check-In timestamp, log timestamp ของ off-site queue calling, และ log gate-in timestamp ที่ต้องมาถึงภายใน XX mins หลังคิวเรียก (RFP p30). DAS verify gate-in time + Truck ID เพื่อ auto-trigger CI1 & CI2 (RFP p31 rows 8-9). รายละเอียดเก็บที่ Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking) และแนวคิด CI1/CI2 อยู่ที่ การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In.

ข้อสังเกต / ของที่ยังไม่นิ่ง

• Identity method ของ DL ยัง TBC (SUM p17 "waiting vendor approach": face/fingerprint scanning, ทำหลัง GI สำเร็จ หรือที่ GI station, ก่อน complete CI). ส่วน PK driver ยังไม่บังคับ verify identity เพราะ "currently we do not manage PK Driver Master" (SUM p16) → ดู ช่องว่างของ PK Driver Master และวิธียืนยันตัวตนคนขับ (TBC)
• "Off-site validation" ถูก list ใต้ GATE IN (SUM p11) ทั้งที่ logic ของ radius validation อยู่ที่ Check-In step 1 — อาจหมายถึง gate re-validate record off-site อีกครั้ง (ดู "Offsite ? / Master check" ใน Lane 3). ลำดับ key action ที่ Gate-IN ยังไม่ตรงกันข้ามสไลด์ (SUM p11 vs SUM p12 vs RFP p13)

Flow Advanced Slot Booking แบบ To-Be (web booking → Gate-In validation → CI2)

To-Be flow ของ Use Case #2 — "Advanced slot booking feature for receiving cement at SRB Plant" (RFP p18): ลูกค้า/ผู้ขนส่งจองสล็อตล่วงหน้าผ่าน web/platform, ได้ booking confirmation/ID, จากนั้นนำมายืนยันที่ gate-in เพื่อ validate การจองและทำ check-in อัตโนมัติ. cross-confirm SUM (p13-14) + RFP (p14-15, p18-19, p28-32) → confirmed.

High-level 4-step (SUM p13 / RFP p14)

สองโซนคั่นด้วยเส้นประ: OUTSIDE (Customer site / Transporter Fleet) | SRB FACTORY

1. Booking — Booking Website; sub-flow pill: Booking slot » Booking Confirm » Driving
2. Arrived at factory — Arrive at SRB factory by window time
3. GATE IN — GATE In process: Alcohol Check / Truck ID validation / Receive RFID / Booking validation
4. Parking Exit — Pass through parking exit

KEY Highlights (SUM p13, RFP p14): ลูกค้า book slot online ล่วงหน้าตาม booking policy (Timing / Slot availability / Cancellation allowance / Window Time); มี booking validation process บังคับที่ GATE-In เพื่อยืนยันว่า booking valid.

Detailed swimlane (SUM p14 / RFP p14) — "SCCC Cement : Check-In Process at SRB-Plant (Advanced Slot Booking)"

ประกอบด้วย 3 lane:

Lane 1 — Booking Slot

• User Login → Available quota ? (NO → End) → Has Shipment ? (NO → End) → Input SH No. → SH Validation (Fail → loop) → Display data (shipment info) → Select receiving date → Available slot ? (No Available → End) → Select slot → Update Info → Confirm Data ? (NO → loop) → Confirm booking ? (NO → End) → Booking confirmation (key action: Generate booking slip on each channel)
• หมายเหตุ: SUM p14 ให้น้ำหนักขั้น quota check เด่นกว่า; ส่วน RFP p14 swimlane วาด Has shipment? ก่อน quota — ลำดับ gating ระหว่างสองเอกสารต่างกันเล็กน้อย แต่ใช้ชุดเงื่อนไขเดียวกัน (quota / shipment / SH validation / slot availability / confirm)

Lane 2 — Gate In – Check In 2

• Gate In — key actions: Truck ID validation / Alcohol Testing / Receive RFID Card → Valid Booking ?
  • NO → Onsite / Kiosk (fallback เข้าสู่ walk-in/หน้างาน)
  • YES → Valid Truck ID ? → Complete Check In 1 → Complete Check In 2 (key action: Generate & Display E-Loading Doc)

Lane 3 — Parking Exit

• Display loading Doc (Inform latest time for pass through parking exit) → Pass trough Parking Exit
  • Delay → Auto cancel booking ID
  • Ontime → Load-In

Booking wizard (RFP p15) — 5 steps

หน้าจอ web "ระบบจองวันเวลาเข้ารับสินค้า": 1) กรอกข้อมูลชิปเม้นท์ → 2) เลือกวันเวลา → 3) อัพเดทข้อมูล → 4) ยืนยันการจอง → 5) การจองเสร็จสมบูรณ์. ปฏิทินมี color code: 🟩 มีคิวว่าง / 🟧 รอยืนยัน / 🟥 คิวเต็ม / hatched = disabled. ส่วน slot picker เป็น radio ทุก 30 นาที + "จำนวนคิวว่าง : N คิว".

Business logic / rules (RFP p18-19)

• Precondition: user ต้อง register + login, มี available quota, slot master ถูก maintain & activate ต่อ period, interface กับ DAS; โดย business users เป็นผู้คุม slot availability / quota / การเปิด-ปิด feature (RFP p18)
• Validate quota by sold-to or ship-to or fleet, per day or week; หาก quota limit/block → จะใช้ feature ไม่ได้ (RFP p19). โมเดล quota อยู่ที่ โมเดล Booking quota
• Slot availability เทียบกับ opened slot master ที่ predefined algorithm หรือ admin เสนอ; หาก slot ที่ต้องการไม่ว่าง → ให้เลือกอันอื่น (RFP p19)
• ต้องมาถึง + check-in ภายใน tolerance time ด้วย booking ID ที่ platform generate (RFP p19)
• Queue ของ advanced slot booking = 1st priority (RFP p19) — กลไก arbitration ข้ามช่องทางอยู่ที่ Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ
• No-show ภายใน tolerance → booking ถูก cancel, slot ถูก mark เป็น available, แล้วเรียกคิวถัดไป (RFP p19; SUM p14 "Delay → Auto cancel booking ID"). ค่าตัวเลขอยู่ที่ Threshold เวลา tolerance / window / overdue / นโยบายจองอยู่ที่ พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)

เชื่อมเข้ากับ driver app + DAS

• Booking confirmation ถูก push ไปแอป Online-CI ของคนขับ เพื่อแสดง booking reference (RFP p28 row 30: booking ref no. / QR / barcode / booked date-time slot / product / commodity / QTY / T&C). ส่วน Customer version (row 29) เพิ่ม Customer Profile. นี่คือจุดเชื่อมระหว่าง booking platform กับ driver mobile app — ดู Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor
• Gate-in validation logic ฝั่ง booking (RFP p32 rows 17-20): verify Truck ID เทียบกับ scanned gate-in ID, verify booking confirmation, แล้ว verify gate-in time + Truck ID + booking → หากผ่านและอยู่ในเวลา reserved → auto CI1 & CI2; หากผ่านแต่ก่อนเวลา reserved → auto CI1 ก่อน แล้วค่อย CI2 เมื่อถึงเวลา (RFP p32 row 20). queue จะ auto-cancel หาก gate-in timestamp หายไปภายใน reserved timeslot/ล่าช้า → ส่ง cancel ไปยัง booking platform เพื่อ mark สถานะ canceled + แจ้ง user (RFP p31 row 16). DAS integration เก็บที่ DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration)

ข้อสังเกต

• Booking ทำผ่าน web/Platform ซึ่งอาจเป็นคนละระบบ/คนละ vendor กับ driver mobile app (SUM p20 integration #6 sender = "Platform" ไม่ใช่ "Mobile App"; MIN: GS ถือ Driver Mobile App แต่ไม่ถือ dashboard คิว) → Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor
• ช่วง advance booking window (MIN: 3–7 วัน; RFP p19 matrix: Prior 2-168H? vs 24-168H? — ยังแดง/undecided) ยังไม่นิ่ง → พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก) / ช่วง lead-time การจองล่วงหน้า (Advance-booking) ยังไม่ได้ข้อสรุป

การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In

แนวคิด cross-cutting ที่ ทั้ง Online Check-In และ Advanced Slot Booking ใช้ร่วมกัน คือการแยกการ check-in ออกเป็นสองขั้น (CI1/CI2) โดยมี Gate-In คั่นกลาง. เก็บรวมไว้ที่เดียวเพื่อเลี่ยง duplicate ระหว่าง Flow Online Check-In แบบ To-Be (mobile แบบ geofence, CI1 → Gate-In → CI2) กับ Flow Advanced Slot Booking แบบ To-Be (web booking → Gate-In validation → CI2).

นิยาม CI1 / CI2

• CI1 = Check-In 1 = ขั้น off-site/mobile (สำหรับ online check-in) หรือขั้น booking (สำหรับ advanced booking) ที่ทำการ book queue ที่ DAS. DAS ฝั่งนี้ต้อง store off-site check-in request เป็น master file, record virtual Check-In timestamp, และ log timestamp ของ off-site queue calling (RFP p30 rows 1-3)
• CI2 = Check-In 2 = ขั้นที่ทำเสร็จ ที่หน้างานหลังมาถึงตรงเวลา + ผ่าน Gate-In ซึ่งจะ generate & display E-Loading Doc (RFP p16 normal course "View loading document"; SUM p12/p14 key action "Generate & Display E-Loading Doc")
• As-Is ก็มี CI1/CI2 อยู่แล้ว (CI1 ที่ gate-in, CI2 ก่อน parking exit) ดู Swimlane การ Check-In แบบ As-Is (Kiosk / RFID-card based); To-Be ยกแนวคิดเดียวกันมาทำบนมือถือ/อัตโนมัติ

Activity sequence (บังคับ)

Check In 1 (Mobile) > Gate In > Check In 2 (Mobile) (RFP p17). ลำดับนี้ strict — CI2 จะ complete ไม่ได้ถ้ายังไม่ผ่าน Gate-In และ Gate-In ต้องมาหลัง CI1 เสมอ.

Gate-In arrival logic (SUM p18 "Gate-In arrival time")

"To defined tolerance time of Gate-In arrived and next step required":

• Prior (มาก่อนเวลา) → TBC (ยังไม่สรุปวิธีจัดการ; แต่ RFP p17 ระบุว่าถ้ามาก่อน window ให้ผ่าน gate ตามปกติแล้ว รอ ให้ CI2 complete เมื่อคิวเรียก)
• Ontime → Automated CI1 & CI2 (gate-in ตรงเวลา → ระบบทำ CI1 และ CI2 อัตโนมัติ)
• Delay → Cancel Queue

DAS validation ที่ auto-trigger CI1/CI2

DAS ใช้ gate-in time + Truck ID (และ booking confirmation สำหรับ advanced booking) เป็นตัวตัดสิน:

• Online CI (RFP p31 rows 8-9): verify gate-in time & Truck ID → ผ่าน → auto CI1 & CI2; หากผ่านแต่คิวยังไม่เรียก → auto CI1 ก่อน แล้วหลังคิวเรียกค่อย auto CI2
• Advanced Booking (RFP p32 rows 19-20): verify gate-in time & Truck ID & booking confirmation → ผ่าน → auto CI1 & CI2; หากผ่านแต่ก่อนเวลา reserved → auto CI1 ก่อน, หากอยู่ในเวลา reserved → auto CI2
• Truck ID ที่ scan ตอน gate-in ถูกเทียบกับ Truck ID จาก off-site/booking request (RFP p31 row 7; RFP p32 row 17). รายละเอียด DAS logic อยู่ที่ Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking)

Tolerance / window / overdue (RFP p17, RFP p30-31, SUM p17)

• มาถึง นอก window time → queue rejected (เทียบกับ Gate-In timestamp) (RFP p17). หาก gate-in timestamp หาย/ล่าช้า → cancel queue ใน DAS + ส่ง cancel transaction ไปแอปให้ user acknowledge (RFP p31 row 5)
• DAS log เวลาที่ต้องใช้เพื่อ gate-in ภายใน XX mins หลังคิวเรียก (RFP p30 row 4 — XX = placeholder)
• Parking-exit overdue: หาก parking exit เกิน overdue time (อิง timestamp ของ Check-In 2 และ Parking Exit) → queue rejected หรือ put on hold (RFP p17); RFP p31 row 10 = validate ให้ผ่าน parking exit ภายใน XX mins หลัง complete CI2 มิฉะนั้น cancel queue ใน DAS. SUM p17 ระบุค่า Parking exits : 30 mins (highlighted) ส่วน Delayed GI (offsite) = XX mins (ยังไม่กำหนด). ค่าตัวเลขทั้งหมดรวมไว้ที่ Threshold เวลา tolerance / window / overdue

ข้อสังเกต

• "Prior → TBC" (SUM p18) เป็นช่องว่างเชิงนโยบาย: SUM ระบุ TBC แต่ RFP p17 ให้แนวทาง "ผ่าน gate ตามปกติแล้วรอ CI2" — ควร reconcile ว่า early arrival จัดการอย่างไรกันแน่
• ค่า tolerance/window/overdue เป็น configurable (RFP p20 "setting the radius and tolerance time") — ค่า default จริงยังไม่ระบุ → Threshold เวลา tolerance / window / overdue

Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ

วิธีรวมคิวจากหลายช่องทางให้กลายเป็นคิวเดียวของโรงงาน อยู่ภายใต้หัวข้อ "Queue running logic & Priority" บน SUM p16. นี่คือกลไกหัวใจที่ระบบใหม่ต้อง arbitrate ผ่าน DAS.

ช่องทางที่ป้อนคิว

SUM p16 ระบุ 4 channels:

1. Advanced Slot Booking
2. Online Mobile Check-In
3. Kiosk Check-In
4. Counter Check-In

แต่ MIN ระบุไว้ 3 รูปแบบ: "Advanced Slot Booking, Online Check-in และ Walk-in" (MIN — โดย Walk-in ดูเหมือนถูกแตกเป็น Kiosk + Counter บนสไลด์). ความไม่ตรงกันแบบ 3-vs-4 channel นี้ flag ไว้ที่ ความขัดแย้งของลำดับความสำคัญคิว และความไม่ตรงกันของจำนวน channel (3 vs 4).

Priority model (SUM p16)

ภายในหนึ่ง time slot (ตัวอย่างบนสไลด์: 10.00 – 11.00 hrs., ผูกกับ CI2) แถบคิวถูกแบ่งเป็นสองส่วน:

• Advanced Slot Booking = Reserve — กันความจุไว้ส่วนหนึ่งเป็นโควต้าจองล่วงหน้า
• Online, Kiosk, Counter = FCFS (First-Come-First-Serve), Depend on completed CI1 time — ความจุที่เหลือเสิร์ฟตามลำดับเวลาที่ทำ CI1 เสร็จ

กล่าวคือ advanced booking ถือ slot ที่ reserve ไว้ก่อน ส่วนช่องทางที่เหลือใช้ความจุที่เหลือแบบ FCFS โดยเรียงตาม timestamp ที่ CI1 complete. แนวคิด CI1/CI2 อยู่ที่ การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In.

ยืนยันจาก RFP (use-case business rules)

• RFP p17 (Use Case #1): "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-completion timestamp
• RFP p19 (Use Case #2): "Queue of advanced slot booking is the 1st priority" — advanced slot booking = อันดับ 1

เมื่อรวมกฎจากสองหน้า: advanced booking outrank กลุ่ม FCFS (online/kiosk/counter) เสมอ; ส่วนกลุ่ม FCFS เสมอกันเองและตัดสินด้วยเวลา CI1.

ความขัดแย้ง / ของที่ต้อง clarify

• 3-vs-4 channel mismatch (MIN 3 รูปแบบ vs SUM p16 4 channel) → ความขัดแย้งของลำดับความสำคัญคิว และความไม่ตรงกันของจำนวน channel (3 vs 4)
• "predefined logic" เป็นทางเลือกแทน FCFS (RFP p17) แต่ไม่ได้นิยามว่าคืออะไร — กฎ ordering จึงยังกำกวม
• สัดส่วน Reserve vs FCFS ภายใน slot ยังไม่ถูก quantify (SUM p16 ให้เพียงตัวอย่าง slot 10.00–11.00) จึงต้องนิยามว่าโควต้า reserve กินความจุเท่าไร และเหลือ FCFS เท่าไร (ผูกกับ โมเดล Booking quota)
• ระบบใหม่ ต้อง interface กับ DAS เพื่อจัดสรร/arbitrate คิวรวม (MIN: "ระบบใหม่ต้อง Interface กับระบบเดิม (DAS) ในการจัดสรรคิว"; SUM p16 priority ผูกกับ CI1/CI2 ที่ DAS เป็นเจ้าของ timestamp). DAS integration อยู่ที่ DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration); การมองเห็นคิวรวม/ต่อ SKU ที่ feed เข้า dashboard อยู่ที่ FR3 — Dashboard & reporting สำหรับทีม operations