ภาพรวม & สถานะปัจจุบัน Context

สิ่งที่ลูกค้าต้องการ

Siam City Cement Public Company Limited (SCCC / ปูนอินทรี / INSEE) โดยหน่วยงานด้านดิจิทัล INSEE Digital กำลังจัดหา vendor ผู้รับงานพัฒนาระบบที่ทำให้ มองเห็นคิวรถปูน (queue visibility), ให้ คนขับ check-in ออนไลน์ ก่อนเดินทางมาถึง และให้ ลูกค้า / ผู้ขนส่งจองสล็อตการจัดส่งล่วงหน้า ที่ โรงงานสระบุรี (SRB) (RFP p11; SUM p1) RFP วางกรอบไว้ว่า "SCCC aims to implement two features: Queuing Visibility & Online Check-In + Advanced Slot Booking for receiving cement at Saraburi plant" (RFP p11)

ตลอดเอกสารนำเสนอโครงการนี้เป็น 3 เสาหลักของ capability — (1) Queuing Visibility, (2) Online Check-In, (3) Advanced Slot Booking — โดยจับคู่ไว้ด้วยกันทั้งในชื่อ deck สรุป requirement "Queuing Visibility, Online Check-In & Advanced Booking" (SUM p1) และในหน้าปก RFP "QUEUING VISIBILITY & ONLINE CHECK-IN + ADVANCED SLOT BOOKING" (RFP p1)

สอง feature ที่ต้องส่งมอบ (ตาม RFP p11)

• Online Check-In — ทำผ่าน mobile application ที่ผู้ใช้ส่วนใหญ่เป็นคนขับ วัตถุประสงค์: ให้คนขับสามารถ เริ่มกระบวนการ check-in ออนไลน์, ดูสถานะคิวแบบ real time และรับ notification เมื่อถึงคิวของตน (RFP p11) คนขับสามารถเริ่ม online check-in ก่อนมาถึงโรงงาน SRB ภายใต้เงื่อนไขทางธุรกิจที่กำหนดไว้ล่วงหน้า เช่น ระยะทาง / geofencing (RFP p12) ดู สถานะเป้าหมาย (To-Be) — วิสัยทัศน์และประโยชน์ที่คาดหวัง
• Advanced Slot Booking — ใช้ได้บน mobile หรือ platform อื่นที่เหมาะสม เปิดให้ ลูกค้าและผู้ขนส่ง จองสล็อตที่ว่างสำหรับการสั่งปูนของตน (RFP p11) การจองสล็อต ถูกแนะนำโดย algorithm ที่กำหนดไว้ล่วงหน้า เมื่อจองสำเร็จ ผู้ใช้จะได้รับ confirmation ID หรือ slip ที่ต้องนำมาแสดงเมื่อมาถึง โรงงาน SRB ส่วน operations users เป็นผู้บริหารจัดการ slot ที่ว่างและตัดสิน eligibility ของกลุ่มผู้ใช้ (RFP p12)

ความคาดหวังแบบ cross-cutting (RFP p11)

application/system ต้องเน้น user-friendliness (ข้อมูล visualise อย่างเรียบง่าย เข้าใจได้ทันที) และต้องสามารถ: รองรับ logistics service หลายประเภท ที่ SCCC ให้บริการ, จัดการ material group หลายกลุ่ม, รองรับ queuing type ที่แตกต่างกัน, เปิดให้ ขยายขอบเขตได้ตลอด user journey ไม่ใช่แค่ขั้น check-in และ รับ-ส่งข้อมูลแบบ real time กับ platform ปัจจุบันของ SCCC — ระบบจัดการคิวเดิม DAS (ดู DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration)) ขอบเขต business process ระบุไว้ว่า "Cement dispatching for Domestic (Delivery & Pick Up logistics Service)" (RFP p12)

ที่มาของเอกสารและวันที่

• RFP "Queuing Visibility & Online Check-In + Advanced Slot Booking" ออกโดย INSEE Digital สำหรับ SCCC ลงวันที่ 19 May 2026 (RFP p1) จำนวน 58 หน้า รายละเอียด milestone การจัดซื้อจัดจ้าง กำหนดการ และเงื่อนไขอยู่ใน timeline การจัดซื้อจัดจ้าง, milestones & ระยะเวลา implementation
• Requirement Summary deck "Requirement Summary" ลงวันที่ 6 Feb 2026 (footer 6/2/2026 / 02/06/2026 วันที่เดียวกันสองรูปแบบ) (SUM p2, p4) จำนวน 21 สไลด์
• รายงานการประชุม (ภาษาไทย) ยืนยันกรอบเดียวกัน: พัฒนา Online Check-in and Advanced Slot Booking for Outbound at the Saraburi plant (MIN)

ความไม่สอดคล้องของชื่อโครงการ (flagged)

โครงการเดียวกันนี้ปรากฏ หลายชื่อ: ชื่อหน้าปก/section "Queuing Visibility & Online Check-In + Advanced Slot Booking" (RFP p1), footer ที่ปรากฏซ้ำในเอกสาร "Insee Driver Mobile" และที่ RFP p11 มี footer ตกค้างเขียนว่า "INSEE Premium Gift Management" (น่าจะเป็น copy/paste จาก template) ชื่อโครงการ / ผลิตภัณฑ์ที่เป็นทางการยังไม่ถูกกำหนดแน่ชัด — ดู ชื่อโครงการที่ไม่สอดคล้องกัน และ footer ที่หลงเหลือจาก template

[INFERRED] หมายเหตุบริบท: โครงการคิวสำหรับทีม packing / cement-dispatch นี้เข้าใจว่า แยกต่างหากจากโครงการ Access-Control / Contractor gate ของ SCCC (เป็นระบบ gate คนละตัว) การแยกนี้ไม่ได้ระบุแบบ verbatim ใน extract ที่อ่านมา และควรยืนยันกับลูกค้า

ขั้นตอน check-in ในปัจจุบัน

ปัจจุบันคนขับ ต้องมา check-in ที่โรงงาน SRB ด้วยตนเองผ่านตู้ Kiosk ("คนขับต้องมาเช็คอินที่โรงงานแบบ Physical ผ่านตู้ Kiosk") และ ไม่สามารถวางแผนล่วงหน้าได้ (MIN; SUM p3) กระบวนการ As-Is เป็นแบบ อิงบัตร RFID / ตู้ Kiosk หน้างาน ซึ่งคนขับต้องอยู่ที่ไซต์งานจริง และ ไม่มีการมองเห็นสถานะคิวจากนอกพื้นที่ (MIN; ดู ปัญหาการดำเนินงานในปัจจุบันและปัจจัยขับเคลื่อนทางธุรกิจ (business drivers))

ขั้นตอนภายในโรงงานแบ่งเป็น 6 stage หลัก: เกทอิน (Gate-In) → เช็คอิน (Check-In) → ชั่งเข้า (Weigh-In) → จ่าย/โหลด (Dispatch/Load) → ชั่งออก (Weigh-Out) → เกทเอ้าท์ (Gate-Out) (SUM p4, p5) ขอบเขตของ Online Check-In / Advanced Slot Booking โฟกัสที่ stage Gate-In และ Check-In เป็นหลัก โดย stage flow ทั้งหมดมีรายละเอียดใน Flow ขั้นตอนกายภาพในโรงงาน SRB (6 stages) และ swimlane ของขั้นตอน check-in อยู่ใน Swimlane การ Check-In แบบ As-Is (Kiosk / RFID-card based)

รายละเอียด Gate-In (stage 1) (SUM p4)

• ระบบอ่านป้ายทะเบียนอัตโนมัติ (ALPR) — ระบบอ่านป้ายทะเบียนอัตโนมัติ — ร่วมกับ barrier gate ทำหน้าที่ตรวจจับป้ายทะเบียนรถโดยอัตโนมัติ (SUM p4)
• คนขับ เป่าแอลกอฮอล์ด้วยตนเองที่ตู้จ่ายบัตรรับ-ส่งสินค้า (SUM p4)
• คนขับ รับบัตรรับ-ส่งสินค้า (บัตรรับ-ส่งสินค้า, ตัวอย่าง No.10000) ซึ่ง ใช้แทนแบบฟอร์มขอรับปูนซีเมนต์แบบกระดาษ (แบบฟอร์มขอรับปูนซีเมนต์ — ปัจจุบันเลิกใช้แล้ว) (SUM p4)
• ห้อง Control room มีเจ้าหน้าที่ประจำ 1 คน/กะ (เจ้าหน้าที่ 1 คน/กะ) (SUM p4)

ช่องทางการลงทะเบียนที่ Check-In มี 2 แบบ (SUM p5)

หลังออกบัตรแล้ว การลงทะเบียน ("การลงทะเบียนที่ตู้ออกเอกสารอัตโนมัติและเคาน์เตอร์") จะแยกเป็น 2 เส้นทางซึ่ง มาแทนแบบฟอร์มขอรับปูนซีเมนต์แบบกระดาษเดิม:

1. การลงทะเบียนรับสินค้า (การลงทะเบียนรับสินค้า) → นำบัตรไป สแกนที่ตู้ออกเอกสารอัตโนมัติ (ตู้ออกเอกสารอัตโนมัติ) (SUM p5)
2. การลงทะเบียนรับ-ส่งวัตถุดิบ (การลงทะเบียนรับ-ส่งวัตถุดิบ) → นำบัตรไป ยื่นที่เคาน์เตอร์ (เคาน์เตอร์) (SUM p5)

ฮาร์ดแวร์ที่เห็นหน้างานในปัจจุบัน ได้แก่ ตู้ออกเอกสารอัตโนมัติ (สีแดง พร้อม touchscreen + เครื่องอ่านลายนิ้วมือ + ช่องรับเอกสาร), เคาน์เตอร์ และ เครื่องอ่านบัตรรับ-ส่งสินค้า (เครื่องอ่านบัตรรับ-ส่งสินค้า) (SUM p5, p6) — รวบรวมไว้ใน ฮาร์ดแวร์เดิมในโรงงาน — kiosk, counter, card reader, ALPR, DAS display board

Wizard การลงทะเบียนบนตู้ Kiosk (SUM p6)

Wizard ของตู้ Kiosk แบบ As-Is มี 3 หน้าจอ: (1) เลือกอินทรีจัดส่ง (อินทรีจัดส่ง) หรืออินทรีรับของเอง (อินทรีรับของเอง) แล้วพิมพ์เอกสาร; (2) ยืนยันตัวตนด้วยลายนิ้วมือ + รายละเอียดรถ/คนขับ (ป้ายทะเบียน, ชื่อคนขับ, ประเภทสินค้า, น้ำหนักกฎหมาย, ประเภทรถ — รถดอก rigid หรือรถพ่วง trailer); (3) สแกน barcode ของ shipment หรือกรอกเลข shipment แล้วยืนยันรายการสินค้า (line items) (SUM p6) ข้อมูลตัวอย่าง: Shipment No. 1100010922, น้ำหนักกฎหมาย 50.50 ตัน, สินค้าอินทรีเพชร ปอร์ตแลนด์ประเภท 1

บอร์ดแสดงคิว DAS ที่ใช้อยู่เดิม (SUM p6)

บอร์ดแสดงคิว DAS แบบ real-time จะแสดงคิวที่ถูกเรียกไว้ด้านบน (เช่น กท73-2363 [DL], พย80-9168 [PK]) และ คอลัมน์แยกตามสินค้า โดยแต่ละคอลัมน์มี header, แถวย่อยสีแดง "รถทั้งหมด" (total trucks) + "Window Time" จากนั้นเป็นรายการป้ายทะเบียนที่รอ ติด badge DL (แดงเข้ม) หรือ PK (เขียว) (SUM p6) สินค้าปรากฏทั้งแบบ BAG (ถุง) และ POWDER/BULK (ผง) ยืนยันว่าระบบรองรับหลาย SKU และจัดการทั้งแบบ bag และ bulk (DL ≈ Delivery / รถของบริษัท, PK ≈ self-Pickup; ดู อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations))

ทำไมเรื่องนี้จึงสำคัญ

baseline ของ As-Is นี้ — ต้องมาหน้างานด้วยตนเอง, อิงบัตร RFID, มีการเป่าแอลกอฮอล์, มี manual counter เป็น fallback และบอร์ดคิวที่เห็นได้เฉพาะในไซต์ — คือจุดตั้งต้นที่ฟีเจอร์ To-Be แบบ online/booking ต้องเข้ามาปรับปรุง ปัญหาฝั่งคนขับ (วางแผนล่วงหน้าไม่ได้ และไม่รับรู้สถานะคิวจากนอกพื้นที่) รวมถึงตัวเลขด้าน load/safety ถูกบันทึกไว้ใน ปัญหาการดำเนินงานในปัจจุบันและปัจจัยขับเคลื่อนทางธุรกิจ (business drivers) หมายเหตุ: ขั้นตอน Confirm มีการ สแกนลายนิ้วมือแบบ "Only for DL" ในกระบวนการ As-Is (SUM p3) — ความหมายที่ชัดเจนของ DL ติดตามอยู่ใน อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations)

ทำไม SCCC จึงทำโครงการนี้ (business drivers)

สไลด์ "Current Operational Challenges" (SUM p7) สรุป pain point ของกระบวนการ As-Is ตลอด flow ของโรงงานในแถบ Gate IN »» Parking Area »» Check IN 1 »» Queuing »» Check IN 2 »» Parking Exit โดยจัดกลุ่มเป็น 3 กลุ่มปัญหาพร้อมตัวเลขเชิงปริมาณ แล้วสรุปเป็น business impact 3 ด้าน ทั้งหมดนี้คือปัจจัยขับเคลื่อนเบื้องหลังวิสัยทัศน์ใน สถานะเป้าหมาย (To-Be) — วิสัยทัศน์และประโยชน์ที่คาดหวัง

ปัญหา ❶ และ ❸ — ความปลอดภัย / ความสามารถในการรองรับ (SUM p7)

• ความหนาแน่นของรถเกินความจุลานจอดของ SCCC — "High volume of truck density in the SCCC parking area beyond the capacity" (SUM p7)
• สูงสุด 77 คัน/ชั่วโมงที่ Gate-In (No. of trucks GI) (SUM p7)
• สูงสุด 78 คนขับ/ชั่วโมงที่ Check-In (No. of drivers CI) ทำให้ คนขับแออัด ในพื้นที่ check-in ("Crowed driver in the Check-In area" [sic]) (SUM p7)
• ความเหนื่อยล้า (Fatigue) = 13% ของเคสด้านความปลอดภัยในปี 2025 (SUM p7) โดยรายงานการประชุมระบุตัวเลขเดียวกันนี้ในกรอบ อุบัติเหตุประมาณ 13% ในรอบปีที่ผ่านมามาจากความเหนื่อยล้าของคนขับ (MIN) นิยามที่แน่ชัดของตัวชี้วัดนี้ (สัดส่วนของ safety-cases เทียบกับสัดส่วนของ accidents) ควรยืนยันกับ INSEE
• กฎชั่วโมงการขับขี่ (จาก MIN): คนขับระยะไกลต้อง ขับ 4 ชั่วโมงแล้วพัก 30 นาที แต่ วางแผนการพักไม่ได้ เพราะไม่ทราบสถานะคิวของตน (MIN) ค่า threshold/tolerance ที่ได้รับผลกระทบจากเรื่องนี้ติดตามอยู่ใน Threshold เวลา tolerance / window / overdue

ปัญหา ❷ — ข้อจำกัดด้านการมองเห็นคิว (SUM p7)

"Limitation of queue visibility & flexible channel : Driver must proceed check-in activity & view queue status in the check-in area only, lack of user acknowledgement & lead to bad perception" (SUM p7) รายงานการประชุมย้ำประเด็นนี้: ปัจจุบัน ไม่มี Queue Visibility คนขับจึงไม่ทราบว่าจะถึงคิวเมื่อไรหรือต้องรอนานแค่ไหน และไม่มีการให้ข้อมูลแก่คนขับหรือลูกค้าเกี่ยวกับสถานะคิวและเวลารอ (MIN) การจัดลำดับคิวข้ามหลายช่องทาง (multi-channel queue arbitration) ที่เปิดประเด็นจากเรื่องนี้ติดตามอยู่ใน ความขัดแย้งของลำดับความสำคัญคิว และความไม่ตรงกันของจำนวน channel (3 vs 4)

baseline ของ load (SUM p7 — กราฟฝังในสไลด์ "Average No. of Shipment check in Y2025")

• ~1000 SH/DAY (≈1000 shipments ต่อวัน) (SUM p7)
• 100% Check-In — ทุก shipment ในปัจจุบันต้องมา check-in ด้วยตนเอง (SUM p7)
• 40% in Peak time — 40% ของการ check-in กระจุกตัวอยู่ในช่วง peak (SUM p7)
• ช่วง Peak ≈ 15:00–19:00 บนกราฟ demand รายวัน 24 ชั่วโมง (แกน X ชั่วโมงที่ 1–23) (SUM p7)

ตัวเลขเหล่านี้คือ baseline ด้าน load/capacity ที่ To-Be solution ต้อง size ให้รองรับได้ [INFERRED] ตัวเลข 77 คัน/ชม., 78 คนขับ/ชม., 1000 SH/DAY, 100% และ 40%-in-peak ปรากฏเฉพาะใน SUM p7 เท่านั้น (ไม่มีในรายงานการประชุม)

business impact ที่ระบุไว้ 3 ด้าน (SUM p7 "IMPACTS")

1. Safety & Compliance — ความเสี่ยงต่อ การไม่ปฏิบัติตามกฎความปลอดภัยในการขับขี่ และ โอกาสเกิดอุบัติเหตุ อันเนื่องมาจาก ข้อจำกัดในการวางแผนเวลาพักของคนขับ (SUM p7; เทียบกฎขับ 4 ชม./พัก 30 นาที ใน MIN)
2. Customer Experience — ประสบการณ์การรับสินค้าของลูกค้าที่ไม่ดี อันเกิดจากการขาดการมองเห็นคิว ส่งผลให้ มีข้อร้องเรียนซ้ำๆ และเสี่ยงสูญเสียยอดขาย (SUM p7)
3. Operational Efficiency — การ dispatch และการใช้ทรัพยากรที่ไม่มีประสิทธิภาพ เนื่องจาก มองเห็นรถที่กำลังจะเข้ามาล่วงหน้าได้จำกัด (SUM p7)

วิสัยทัศน์ To-Be

แนวคิดระดับสูง (SUM p9) คือการ เพิ่ม visibility และความยืดหยุ่นให้กระบวนการ check-in: "Driver able to proceed check in as self-service & acknowledge their queue status online via using their mobile; Customer able to select prefer available slot to receive cement at plant" (SUM p9) ซึ่งตอบโจทย์ pain point ของ As-Is ใน ปัญหาการดำเนินงานในปัจจุบันและปัจจัยขับเคลื่อนทางธุรกิจ (business drivers) โดยตรง — คือการวางแผนล่วงหน้าไม่ได้ และมองไม่เห็นสถานะคิวจากนอกพื้นที่

สอง feature ("Improvement Idea", SUM p10)

"condition" (geofence/distance) และ "booking policy" ยังไม่ถูกนิยามครบถ้วนในสไลด์นี้ และติดตามไว้เป็น constraint/open question ส่วน flow ของ To-Be มีรายละเอียดใน Flow Online Check-In แบบ To-Be (mobile แบบ geofence, CI1 → Gate-In → CI2) และ Flow Advanced Slot Booking แบบ To-Be (web booking → Gate-In validation → CI2) โดยมี functional requirement อยู่ใน FR1 — Mobile Online Check-In สำหรับ driver และ FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง

ประโยชน์ที่ระบุไว้ — การลด Cycle time (SUM p10)

มี badge ประโยชน์สีแดงปรากฏบน ทั้งสอง feature: Cycle time ↓ 30–40 mins (SUM p10) [INFERRED] ตัวเลขนี้อยู่บน SUM p10 เท่านั้น และไม่ได้ระบุซ้ำในรายงานการประชุม

ประโยชน์แยกตาม stakeholder (SUM p10)

Online Check-In

• Customer: Customer Experience ดีขึ้น, ทำล่วงหน้าได้, ยืดหยุ่นและสะดวกขึ้น
• INSEE: ปรับปรุง Service Time สำหรับการ dispatch ที่โรงงาน
• Safety: บริหารชั่วโมงพัก (rest hour), ลดความหนาแน่นของรถและความแออัดของคนขับที่โรงงาน

Advanced Slot Booking

• Customer: Customer Experience ดีขึ้น, ยืดหยุ่นในการ บริหารสล็อตของตนเองแบบ self-service มากขึ้น
• INSEE: balance demand & supply, machine utilization, resource management
• Safety: ลดความหนาแน่นของรถและความแออัดของคนขับที่โรงงาน

(typo "crowed" คงไว้ตามต้นฉบับ) ประโยชน์ "balance demand & supply" แสดงด้วยไอคอนกราฟ peak-smoothing (การปรับ utilization ให้สม่ำเสมอ) (SUM p10)

ข้อความสถานะเป้าหมาย (แบนเนอร์ verbatim)

• Online Check-In (SUM p11): "TARGET STATE : Drivers receive real-time updates and queue status to arrive punctually without unnecessary waiting on-site." ภายในรัศมีที่ยอมรับ ระบบจะ validate ตำแหน่ง GPS ของคนขับ เมื่อจองเสร็จและคิวกำลังเรียก คนขับต้องมาถึงโรงงาน SRB และ GATE IN ตรงเวลา (SUM p11)
• Advanced Slot Booking (SUM p13): "TARGET STATE : Arrivals are planned in advance to reduce uncertainty and balance demand across plant capacity effectively." ลูกค้าจองสล็อตออนไลน์ล่วงหน้าตาม booking policy (Timing / Slot availability / Cancellation allowance / Window Time) โดยมีขั้นตอน booking-validation ที่ต้องทำที่ Gate-In (SUM p13)

กรอบ To-Be ตาม RFP (RFP p11-12)

หัวข้อ "To-Be Business Functionalities and Processes" ของ RFP ระบุว่า: คนขับสามารถ เริ่มขั้นตอน online check-in ก่อนมาถึงโรงงาน SRB ภายใต้เงื่อนไขที่กำหนดไว้ล่วงหน้าและ business user เห็นชอบ เช่น ระยะทางหรือ geofencing (RFP p12, "Flow: Mobile Check-In"); และลูกค้า / transporter admin สามารถ จองสล็อตที่ว่างล่วงหน้า โดยถูกแนะนำด้วย algorithm ที่กำหนดไว้ล่วงหน้า ได้รับ confirmation ID หรือ slip ที่นำมาแสดงเมื่อมาถึง ขณะที่ operations users บริหาร slot availability และ eligibility ของกลุ่มผู้ใช้ (RFP p12, "Flow: Advanced Slot Booking") วัตถุประสงค์โดยรวม (RFP p11) คือ queue visibility แบบ real-time, online self-service check-in และการจองสล็อตล่วงหน้า โดยทั้งหมดแลกเปลี่ยนข้อมูลแบบ real time กับ platform ปัจจุบันของ SCCC (DAS)

อยู่ใน scope (SUM p10 "Improvement Idea — Scope")

กล่อง Scope สีเทาบนสไลด์ Improvement-Idea กำหนดขอบเขตไว้ (SUM p10):

• Outbound เท่านั้น
• สินค้า: Cement, Mortar, Clinker
• บรรจุภัณฑ์: Bag & Bulk
• การเคลื่อนย้าย: Delivery & Pick-Up
• ต้อง รองรับการ dispatch ของ SKU / shipment ที่แตกต่างกัน
• ต้อง รองรับทุก Shipping Condition (มีหรือไม่มี MHE = Material Handling Equipment)

รายงานการประชุมระบุ scope เดียวกันนี้ซ้ำ: โครงการพัฒนา Online Check-in and Advanced Slot Booking for Outbound ที่โรงงานสระบุรี รองรับ cement, mortar และ clinker ทั้งแบบ bag และ bulk ทั้ง รถจัดส่งของบริษัทและลูกค้ามารับเอง ครบทุก SKU ปัจจุบัน รวมถึง Shipping Condition เช่น รับเอง (self-pickup), จัดส่ง (delivery), วางพื้น (drop on ground), คนลง (manual unload) และอุปกรณ์ขนถ่ายสินค้า (MHE) (MIN) [INFERRED] MHE = Material Handling Equipment (ไม่ได้สะกดเต็มไว้บน SUM p10)

RFP ย้ำ — outbound ก่อน แล้วค่อยขยาย scale (RFP p12, p21, p26)

ขอบเขต business process ใน RFP คือ "SCCC – Cement dispatching for Domestic (Delivery & Pick Up logistics Service)" (RFP p12) ตาราง functional กำหนดให้ application ต้อง รองรับการ customize ขั้นตอนสำหรับ logistics service หลัก 2 แบบ คือ Delivery & Pick Up โดยขั้นตอน ออกแบบสำหรับ outbound logistics ก่อนในเบื้องต้น และมีศักยภาพที่จะ scale up เพิ่ม scope ในอนาคต (RFP p21 row 4; ระบุซ้ำสำหรับ Advanced Slot Booking ที่ RFP p26 row 5) ดังนั้น "outbound ก่อน แล้วขยายได้" จึงเป็นขอบเขตการออกแบบที่ระบุชัดและยืนยันข้ามเอกสาร — ไม่ใช่แค่หมายเหตุในสไลด์

อยู่นอก scope

ในตาราง booking-logic (SUM p19) ภายใต้ DispatchType เลือกเฉพาะ Outbound (สีเขียว) ส่วน Inbound และ Backhaul เป็นสีเทา (นอก scope) MarketSegment แสดง Domestic เป็น segment ที่ทำงาน (มี Border / Export อยู่ในรายการแต่ไม่ใช่โฟกัส) สอดคล้องกับ "dispatching for Domestic" บน RFP p12 master-data code ที่กำหนดขอบเขต scope — DispatchType, TransportType (DL / PK), WeightType, MarketSegment, ItemType (BG, BK, CL, BB) — รวบรวมไว้ใน Master data dictionary (โค้ด dispatch/transport/weight/segment/item) และ อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations)

ความกำกวม — ขอบเขตโรงงาน (SRB เท่านั้น vs Rayong)

ทุกสไลด์และ RFP ระบุเฉพาะ โรงงาน SRB / สระบุรี เท่านั้น อย่างไรก็ตาม Q&A ในรายงานการประชุมมีคำถามว่า "Scope รวมงานที่โรงงานระยองด้วยหรือไม่?" (scope รวมโรงงาน Rayong ด้วยหรือไม่) และคำตอบที่บันทึกไว้ — "รวมทุก SKU ทั้ง Cement ธรรมดาและ Mortar" (รวมทุก SKU ทั้ง Cement ธรรมดาและ Mortar) — ตอบในแง่ความครอบคลุม SKU แต่ ไม่ได้ยืนยันหรือปฏิเสธเรื่อง Rayong อย่างชัดเจน (MIN) นี่คือ conflict ที่ยังเปิดอยู่จริงระหว่าง "SRB เท่านั้น" ตามเอกสาร กับคำถามเชิง multi-plant ที่แฝงอยู่ในรายงานการประชุม — ติดตามใน ขอบเขตโรงงาน — เฉพาะ SRB หรือรวม Rayong และการขยายในอนาคต

ศักยภาพการขยาย scope ในอนาคต

นอกเหนือจาก scope เริ่มต้น outbound/SRB เอกสารระบุ ศักยภาพในการ scale up ซ้ำหลายครั้ง: การ customize ขั้นตอน "with the potential to scale up for additional scope in the future" (RFP p21, p26) และ "extended scope throughout the user journey, beyond just the check-in step" (RFP p11) ส่วน scalability ในวงกว้างไปยัง business unit อื่น / บริษัทในภูมิภาคของ SCCC เป็น non-functional requirement ที่ติดตามอยู่ใน Scalability การขยายระบบ และ high availability วิสัยทัศน์ To-Be ที่ขอบเขต scope เหล่านี้รองรับอยู่ใน สถานะเป้าหมาย (To-Be) — วิสัยทัศน์และประโยชน์ที่คาดหวัง