กลุ่มผู้ใช้งาน Personas

DL เป็นหนึ่งในสอง transport type ขาออกของการ dispatch ปูนของ SCCC ที่ SRB โดยอีกตัวคือ PK (คนขับ PK (Pick-up / ลูกค้ามารับของเอง)) DL = delivery / company (own-fleet) transport — รถจัดส่งที่ SCCC เป็นผู้จัดการเอง ("รถจัดส่งของบริษัท", MIN) ตรงข้ามกับกรณีลูกค้ามารับของเอง ทั้ง deck และ RFP ไม่ได้สะกดตัวย่อแบบเต็ม แต่การขยายความนี้มีหลักฐานรองรับชัดเจน: functional row 27 ของ RFP อ้างถึง "delivery shipment (DL)" ตรง ๆ (RFP p23); kiosk ใน As-Is มีตัวเลือก "อินทรีจัดส่ง" (INSEE delivery) เทียบกับ "อินทรีรับของเอง" (SUM p6); queue board ของ DAS ที่ใช้งานจริงติด badge DL สีแดงเข้มให้กับรถ (SUM p6); และ matrix ของ booking logic ระบุ TransportType → DL | PK (SUM p19) [INFERRED ว่า "DL" ย่อมาจาก Delivery ตามตัวอักษร; ดู อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations) และ คำย่อและรหัสที่ยังไม่ได้นิยาม]

บทบาท (Role). คนขับ DL เป็นผู้ใช้หลักของ Online Check-In mobile app (Use Case #1 — "Check-In online prior arriving at SRB plant"; Actor = "Users (Driver)", RFP p16) แอปต้อง "allow customization of steps for two major logistics services: Delivery & Pick Up" โดยมี outbound logistics เป็น scope เริ่มต้น (RFP p21 row 4) คนขับจะดำเนิน flow แบบ geofenced สองขั้นคือ CI1 (mobile, off-site) → Gate-In → CI2 (ที่โรงงาน) ตาม RFP p17 ดูเพิ่มเติมที่ FR1 — Mobile Online Check-In สำหรับ driver

Identity — โมเดลแบบเข้มงวด. SUM p16 "Key Business Logic" ระบุกฎสำคัญไว้ว่า "DL Driver : Required to logon & verify identity, using unique user ID." RFP ตอกย้ำขั้นตอนการยืนยันตัวตนเฉพาะ DL นี้ไว้สามจุด: precondition ของ UC1 — "Provide an identity verification step, such as facial scanning after user arrived at plant especially for DL service" (RFP p16); business logic — "Verify the driver's identity after gate in to complete check-in 2" (RFP p17); และ functional 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)" (RFP p23) ส่วน method และ timing ที่แน่นอนยัง TBC: "Proceed after GI successfully or at GI station · Proceed before complete CI · Such as face scanning, fingerprint scanning" — ทำเครื่องหมายว่า "TBC (waiting vendor approach)" (SUM p17) ซึ่งเป็นโมเดลที่ตรงข้ามกับ PK (ที่ไม่มีการ check identity) ประเด็น method/การตัดสินใจที่ยังเปิดอยู่ถูกติดตามไว้ที่ ช่องว่างของ PK Driver Master และวิธียืนยันตัวตนคนขับ (TBC)

Account model. RFP row 59 — "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." (RFP p26) ดังนั้นคนขับที่ทำงานทั้งบทบาท DL และ PK ต้องใช้ separate account format หรือใช้ workflow ที่แยกต่างหากภายในบัญชีเดียวกัน การลงทะเบียนแบบ self-service ทำผ่าน verification workflow ที่ integrate กับ DID (RFP p26 row 57) ดูเพิ่มเติมที่ User account, registration & login (ทั้งสอง app)

ขอบเขต Shipment. ใน Delivery Mode คนขับ DL จะ ไม่ พิมพ์ shipment ID เองอย่างอิสระ — "Select from their assigned shipments, with each driver ID seeing only their assigned shipments" (RFP p22 row 20) ซึ่งต่างจาก PK ที่ป้อน shipment ID โดยตรง ข้อนี้สอดคล้องกับข้อกำหนด access-control ที่ว่า "drivers should see and operate only shipments/tasks under the specific customer" (RFP p37 row 39 — ดู การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO) ชุดฟิลด์ของ shipment / truck จะแตกต่างกันตาม material group (Bag / Bulk / clinker) และเป็นไปตาม master data ใน Master data dictionary (โค้ด dispatch/transport/weight/segment/item) พฤติกรรมการ input ข้อมูลและการ verify identity ของ DL มีรายละเอียดที่ Online Check-In — การกรอกและตรวจสอบข้อมูล (shipment / truck / identity)

MIN ยืนยันการแบ่ง DL/PK ในระดับธุรกิจไว้ว่า ระบบต้องรองรับ "ทั้งรถจัดส่งของบริษัทและรถที่ลูกค้ามารับเอง" (MIN)

PK เป็น transport type ขาออกตัวที่สอง คู่กับ DL (คนขับ DL (Delivery / รถ Company-Fleet)) PK = pick-up / customer self-collect — รถที่ลูกค้าส่งมารับปูนเอง ("อินทรีรับของเอง" ที่ kiosk ใน As-Is, SUM p6; "รถที่ลูกค้ามารับเอง", MIN) เช่นเดียวกับ DL ตัวย่อนี้ไม่ได้ถูกขยายความในเอกสารต้นทาง โดย queue board ของ DAS ติด badge PK สีเขียวให้กับรถกลุ่มนี้ (SUM p6) และ matrix ของ booking ระบุ TransportType → DL | PK (SUM p19) [INFERRED ว่า "PK" ย่อมาจาก Pick-up; ดู อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations) และ คำย่อและรหัสที่ยังไม่ได้นิยาม]

บทบาท (Role). คนขับ PK ก็เป็นผู้ใช้ Online Check-In mobile app เช่นกัน — แอปต้อง customize ขั้นตอนให้รองรับทั้ง "Delivery & Pick Up" logistics services (RFP p21 row 4) — แต่ทำงานภายใต้ โมเดล identity ที่เบากว่า DL ดูเพิ่มเติมที่ FR1 — Mobile Online Check-In สำหรับ driver

Identity — โมเดลแบบเบา / ยังไม่นิยาม. SUM p16 "Key Business Logic" ระบุกฎไว้ (ไฮไลต์สีแดงบนสไลด์) ว่า "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." ตรงนี้มีช่องว่างสองประเด็นชัดเจน: (1) ปัจจุบัน PK ไม่ต้องทำ identity verification (ต่างจาก DL ที่ต้อง logon ด้วย unique-user-ID + face/fingerprint แบบบังคับ) และ (2) แม้แต่ login / account format ของ PK ก็ยังไม่ตัดสินใจ เพราะ ปัจจุบัน SCCC ยังไม่มี PK Driver Master — ไม่มี master data ของคนขับกลุ่ม self-collect ให้ลงทะเบียนหรือใช้ authenticate ได้ นี่คือช่องว่างด้านข้อมูลในระดับ persona ที่ใหญ่ที่สุด และถูกติดตามไว้ที่ ช่องว่างของ PK Driver Master และวิธียืนยันตัวตนคนขับ (TBC)

การ input Shipment. ใน Pick up Mode คนขับ PK ทำตรงข้ามกับคนขับ DL: "Input shipment ID directly and validate it against SCCC's TMS or DAS for pick up mode" (RFP p22 row 20) — ป้อนเองโดยตรงแล้ว validate กับระบบ upstream แทนการเลือกจากรายการที่ถูก assign ไว้ล่วงหน้า รายละเอียดการ validate และพฤติกรรมของฟิลด์อยู่ที่ Online Check-In — การกรอกและตรวจสอบข้อมูล (shipment / truck / identity); ชุดฟิลด์แตกต่างกันตาม material group (Bag / Bulk / clinker) ตาม Master data dictionary (โค้ด dispatch/transport/weight/segment/item)

Account model. PK ใช้กฎ account ร่วมกับ DL: "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" (RFP p26 row 59) — แต่สำหรับ PK เรื่องนี้ขึ้นอยู่กับการแก้ปัญหา PK Driver Master ที่ยังขาดอยู่ก่อน ส่วน item ที่เกี่ยวข้องอย่าง "Workflow" — master-data table เดียวสำหรับลงทะเบียน truck ID พร้อมแยก channel ระหว่าง onsite / offsite / advanced-slot-booking — ก็ยัง "TBC (waiting vendor approach)" เช่นกัน (SUM p16) โดยติดตามแยกไว้ภายใต้เรื่องการ mastering truck-ID

MIN ยืนยัน PK ในระดับธุรกิจว่าเป็นกรณีลูกค้ามารับของเองภายใน outbound scope เดียวกับ DL ("รถที่ลูกค้ามารับเอง", MIN)

ผู้ดูแลฝั่ง Customer / Transporter คือ actor ของ Use Case #2 — Advanced Slot Booking: "Enable advanced slot booking feature on mobile or suitable platform to allow customers or transporters to preserve advanced slot for receiving cement at plant" (Actors = "Users (Customers or transporter admin)", RFP p18). SUM p16 ยืนยันกลุ่มผู้ใช้ของ Advanced Slot Booking = "Customer, transporter" และ MIN ระบุว่า "Target User คือลูกค้าและผู้ขนส่ง" กล่าวคือเป็น ผู้ใช้ฝั่งสำนักงาน/แอดมินที่ทำหน้าที่จองสล็อตล่วงหน้า ซึ่งแยกต่างหากจากคนขับรถที่อยู่หน้างาน (คนขับ DL (Delivery / รถ Company-Fleet) / คนขับ PK (Pick-up / ลูกค้ามารับของเอง)) ที่เป็นผู้ใช้งานผลของการจองนั้นต่อ ดูเพิ่มเติมที่ FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง

เงื่อนไขก่อนเริ่มใช้งาน (Preconditions) (RFP p18): ผู้ใช้ "must be registered, and required to login before processing"; "have an available quota for booking"; slot master "has been maintained and activated for each period"; และต้อง "able to manage their booking details within business condition & allowances" การลงทะเบียนจะสร้างบัญชีและ รับ customer profile มาจาก INSEE+ (RFP p30 row 56) ส่วนการ login ทำผ่าน email / mobile + password ที่ลงทะเบียนไว้ (RFP p30 row 57)

เส้นทางการจอง (Booking journey). ผู้ใช้จองสล็อตล่วงหน้าผ่าน booking website / platform (web หรือ "suitable platform", RFP p18; "Booking Website", SUM p14) — MIN: "จองล่วงหน้าได้ 3-7 วัน … สามารถจองผ่าน Web หรือ App" เมื่อจองสำเร็จจะได้รับ booking confirmation ทั้งในระบบจองและทาง email (RFP p28 row 26) ซึ่งประกอบด้วย unique booking reference no. + QR / barcode (RFP p28 rows 27–29) นอกจากนี้ booking ID ยังถูกส่งต่อไปยัง online CI mobile app ของคนขับ เพื่อให้คนขับ preview ได้ (RFP p28 row 30; RFP p20 FR2) และถูก scan/แสดงที่ Gate-In ของโรงงานเพื่อ validate การจอง (RFP p29 row 32; SUM p13-14) รายละเอียดเนื้อหาของ confirmation และการแบ่งบทบาทระหว่าง customer กับ driver อยู่ที่ Advanced Slot Booking — booking confirmation, user profile และ customer quota

Quota — บังคับใช้ต่อรายลูกค้า. การจองต้องมี quota และต้อง validate ก่อนจองเสมอ: "Validate user quota (by sold-to or ship-to or fleet per day or week)" (RFP p19); หาก quota อยู่ในสถานะ "limit or block" ผู้ใช้จะ "cannot use the feature" (RFP p19; ข้อความ error, RFP p27 row 12) โปรไฟล์ผู้ใช้แสดง quota เป็น Used / Remain / Total (RFP p27 row 9) และ quota ของลูกค้าจะถูกจัดเก็บ/คำนวณอัตโนมัติตาม configuration ของ SCCC ในระดับ Customer level / Customer ID / Product / Period (Shipment per Day, week, month) (RFP p30 row 48) MIN ยกตัวอย่างประกอบไว้ว่า "ลูกค้า A อาจจองได้ไม่เกิน 3 เที่ยวต่อสัปดาห์" ดูเพิ่มเติมที่ โมเดล Booking quota

ขอบเขตการ self-service. ลูกค้า ไม่สามารถแก้ไขรายละเอียดการจองด้วยตนเองได้ — "Customers are unable to edit any details of the booking on a self-service basis" (RFP p29 row 46) การเปลี่ยนแปลงทุกอย่างต้องผ่าน SCCC admin (ผู้ดูแล SCCC Operations / Business Admin) อย่างไรก็ตามลูกค้า สามารถยกเลิกได้ ภายใต้ policy: "Customer should have the ability to cancel their booked request … in accordance with the business cancellation policy" (RFP p29 row 34) โดยมีพารามิเตอร์ policy คือ Booking Cancellation By Customer = ≥12H ล่วงหน้า (SUM p19, ทำเครื่องหมายว่ายังไม่สรุป/แดง) รายละเอียดเหตุผลการยกเลิกและ lifecycle อยู่ที่ Advanced Slot Booking — lifecycle, notifications และ cancellation ส่วนเกณฑ์ของ policy อยู่ที่ พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)

[Note] RFP จัดให้ "customers" และ "transporter admin" เป็น actor กลุ่มเดียวกันสำหรับ UC2 และไม่ได้แจกแจงสิทธิ์ที่แตกต่างกันระหว่าง transporter กับ end-customer ไว้แยกต่างหาก อย่างไรก็ตาม quota สามารถกำหนดขอบเขตในระดับ transporter / fleet ได้เช่นเดียวกับ sold-to / ship-to (RFP p19) ดังนั้นทั้งสองกลุ่มอาจต่างกันในระดับ quota/master data แม้ว่า workflow การจองจะใช้ร่วมกัน

ผู้ดูแล SCCC operations / business admin คือผู้ใช้ภายในที่ เป็นเจ้าของ configuration และการควบคุมเชิงปฏิบัติการ ของทั้งสองฟีเจอร์ใหม่ (Online Check-In และ Advanced Slot Booking) RFP มอบหมายความรับผิดชอบด้าน slot/quota/feature-control ให้กับ "business users" / "SCCC admin" / "operations users" ซ้ำ ๆ persona นี้คือผู้มีอำนาจด้าน configuration และการจัดการ exception ที่อยู่เบื้องหลัง flow ที่หันหน้าเข้าหา customer และ driver

การเปิด/ปิดฟีเจอร์ & การกำหนดสิทธิ์ (eligibility).

• "Business users are responsible for managing available slots, booking quotas, and enabling or disabling the feature" (precondition ของ UC2, RFP p18)
• "the operations users hold the responsibility of managing the availability of slots and determining the eligibility of user groups for accessing this feature" (RFP p12)
• ตัวเลือก offsite Online Check-In จะ "activated or deactivated manually by SCCC admin" (RFP p21 row 3); ฟีเจอร์ Advanced Slot Booking เช่นกัน "manually activated or deactivated by SCCC admin" (RFP p26 row 3 ของ booking matrix)

การจัดการ Slot & slot-master (Advanced Slot Booking — ดู Advanced Slot Booking — slot status และ slot management).

• ดูแลและ activate slot master per period (precondition, RFP p18)
• "administrative feature for SCCC to manage slots and their availability manually" — เพิ่มใหม่ / แก้ไขที่มีอยู่ / ลบ slot (RFP p29 rows 38–39); ปรับ availability ตามความต้องการทางธุรกิจ (row 40); mass update from Excel (row 41); แก้ไข slot duration ด้วยตนเอง เช่น 2 hours → 3 hours per slot (row 42) ระบบจะแนะนำยอดรวมของ slot ที่เปิดเป็น guideline โดยอิงจาก Loading Type / Product SKU / Time slot (RFP p29 rows 43–44)
• Upload master data ผ่าน Excel file เข้าสู่แพลตฟอร์ม (RFP p26 row 8)

การจัดการ exception ของ booking & check-in.

• Manual booking confirmation โดย SCCC admin สำหรับกรณีปรับเป็นพิเศษ (RFP p28 row 25)
• Manual booking cancellation โดย SCCC admin สำหรับการปรับใด ๆ ที่จำเป็น (RFP p29 row 35)
• Manual cancellation of check-ins "in case of any data adjustment from DAS" โดยการอัปเดตจะสะท้อนใน mobile app (RFP p25 row 49 — ดู Online Check-In — การยกเลิก การจบรายการ ข้อมูล และ audit)

การบริหาร Quota (ดู โมเดล Booking quota, พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)).

• จัดเตรียม / ใช้ template (master file) เพื่ออัปเดต total user booking quota (RFP p27 row 11)
• ปรับ quota ลูกค้าด้วยตนเอง โดย SCCC admin (RFP p30 row 49) เพิ่มเติมจาก quota engine ที่คำนวณอัตโนมัติ (RFP p30 row 48)

Dashboard & reporting (FR3, RFP p20 — "Provide dashboard & reporting for operations team … to effectively monitor operations"; ดู FR3 — Dashboard & reporting สำหรับทีม operations).

• SCCC admin มี access to raw data for reports and analytics เพื่อให้ได้ insight ด้าน usage/performance (RFP p27 row 56; RFP p30 row 53)
• ข้อมูล queue (ฝั่ง check-in) และข้อมูล booking จะถูกป้อนเข้า DAS for report & dashboard generation (RFP p25 row 54; RFP p30 row 52)
• รายงานครอบคลุม customer booking quota report (Daily / Weekly / Monthly, RFP p30 row 54) และ advanced booking Daily & Weekly planning reports by product (RFP p30 row 55)

ปัญหาทางธุรกิจที่ persona นี้มุ่งบรรเทาถูกสรุปไว้ใน SUM p7: ปัจจุบันมี "Inefficient dispatching and resource utilization due to limited advance visibility of incoming trucks" — กล่าวคือฝ่าย operations ขาด visibility ล่วงหน้า ซึ่ง dashboard ของ booking/check-in มีไว้เพื่อเติมเต็มจุดนี้

[Note] บทบาทเชิงปฏิบัติการ ฝั่งโรงงาน — เจ้าหน้าที่ห้องควบคุม (1 คนต่อกะ) และเจ้าหน้าที่เคาน์เตอร์ที่ดูแล channel kiosk/counter แบบ As-Is — เป็น persona แยกต่างหากที่บันทึกไว้ใน เจ้าหน้าที่ Gate / Control-Room / Counter (ฝั่งโรงงาน) record นี้ครอบคลุม admin ด้าน business/configuration ที่เป็นเจ้าของ slot, quota, feature toggle, การ confirm/cancel และการทำรายงาน

เจ้าหน้าที่ gate / control-room / counter คือ บุคลากร SCCC ฝั่งโรงงาน ที่ทำงานในกระบวนการ check-in ทางกายภาพที่ SRB ในปัจจุบัน พวกเขาปรากฏเฉพาะในเนื้อหา As-Is ของ Requirement Summary deck (SUM p3-6) เท่านั้น โดย RFP ไม่ได้ระบุ functional requirement ของแอปใหม่สำหรับพวกเขาไว้อย่างชัดเจน persona นี้จึงเป็น status: stated (ถูกอธิบายในเอกสารฉบับเดียว ยังไม่ได้รับการยืนยันข้ามเอกสารว่าเป็นผู้ใช้ที่ถูกออกแบบไว้ในระบบใหม่)

ห้องควบคุม (Control room). ที่ Gate-In ห้องควบคุมมี เจ้าหน้าที่ 1 คน/กะ (1 officer per shift) ประจำ (SUM p4) คอยเฝ้าดู dashboard แบบ multi-monitor นอกจากนี้ Gate-In ยังมี automatic license-plate recognition (ALPR) พร้อม barrier gate ที่ตรวจจับป้ายทะเบียนรถอัตโนมัติและให้ผ่านด้วย green-check (SUM p4) — เป็นจุด barrier/validation จุดเดียวกับที่ To-Be นำกลับมาใช้ซ้ำสำหรับการ validate booking/off-site

เจ้าหน้าที่เคาน์เตอร์ (Counter staff). เคาน์เตอร์ดูแล channel การลงทะเบียนรับ-ส่งวัตถุดิบ: "การลงทะเบียนรับ-ส่งวัตถุดิบ ต้องนำบัตรรับ-ส่งสินค้า ยื่นที่เคาน์เตอร์" — คนขับ ยื่นบัตรรับ-ส่งสินค้าที่เคาน์เตอร์ (ต่างจากการ scan ที่ตู้ออกเอกสารอัตโนมัติซึ่งใช้สำหรับ goods receipt) (SUM p5) เจ้าหน้าที่เคาน์เตอร์ยังทำหน้าที่ manual fallback เมื่อคนขับไม่มี shipment: ใน swimlane ของ As-Is สาขา No-Shipment จะวิ่งไปที่ "Contact SCCC at Counter → Driver complete form → SCCC Verify & check in system" แล้ววนกลับเข้า flow ปกติ (SUM p3) ในเลนของ waiting-queue เจ้าหน้าที่ SCCC ยังทำหน้าที่ "remind the queue" (ประกาศคิวที่ถูกเรียก) ควบคู่กับจอแสดงคิวอีกด้วย (SUM p3, SUM p6)

ระบบที่พวกเขาใช้งาน. เจ้าหน้าที่กลุ่มนี้ทำงานกับ kiosk / counter / card-reader hardware และ DAS queue-display board ที่มีอยู่เดิม (ฮาร์ดแวร์เดิมในโรงงาน — kiosk, counter, card reader, ALPR, DAS display board) และอยู่ครอบคลุม stage ทางกายภาพทั้งหกของโรงงาน (Flow ขั้นตอนกายภาพในโรงงาน SRB (6 stages)) ส่วนเส้นทาง check-in แบบ As-Is ที่พวกเขาดูแลมีรายละเอียดที่ Swimlane การ Check-In แบบ As-Is (Kiosk / RFID-card based)

เหตุผลที่พวกเขายังเกี่ยวข้องใน To-Be. โมเดล queue แบบ multi-channel ในอนาคต ยังคงเก็บเส้นทาง walk-in ไว้: SUM p16 ระบุสี่ channel — Advanced Slot Booking, Online Mobile Check-In, Kiosk Check-In, Counter Check-In — กล่าวคือ "Walk-in" ของ As-Is ถูกแยกออกเป็น channel kiosk และ counter ที่เจ้าหน้าที่กลุ่มนี้ดูแล MIN ยืนยันว่า physical queue ยังคงอยู่: "ระบบ Physical Queue เดิม … ยังมี" พร้อม booking form สามแบบรวมถึง Walk-in ดังนั้นเจ้าหน้าที่ gate/counter/control-room ยังคงดูแล channel onsite/walk-in ต่อไปแม้หลังจาก Online Check-In + Advanced Slot Booking เริ่มใช้งาน และ channel ของพวกเขาก็เข้าร่วมในการจัดลำดับคิวข้าม channel ด้วย (Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ) ส่วน configuration และอำนาจ admin เหนือแอปใหม่อยู่กับ persona แยกต่างหากคือ ผู้ดูแล SCCC Operations / Business Admin

[Note] เนื่องจากเอกสารต้นทางอธิบายบทบาทเหล่านี้ไว้เฉพาะใน As-Is เท่านั้น ความคาดหวังของระบบใหม่ที่มีต่อพวกเขา (เช่น kiosk/counter check-in ยังต้องป้อน timestamp CI1 สำหรับการจัดลำดับ FCFS หรือไม่ หรือเจ้าหน้าที่เคาน์เตอร์จะได้ admin console หรือไม่) จึงยังไม่ถูกระบุไว้ ควรตรวจสอบเทียบกับ record ด้าน channel/priority และ scope