จากกระดานไวท์บอร์ดสู่แดชบอร์ด: วางแผนโหลดรถขนส่งเชื่อมกับ GPS ติดตามรถแบบเรียลไทม์

ปัญหา: การจัดรถขนส่งยังตัดสินใจกันหน้ากระดานไวท์บอร์ด

เดินเข้าไปในลานโรงงานผู้ผลิตแผ่นพรีคาสต์ แผ่นพื้นสำเร็จรูป หรือชิ้นส่วนโมดูลาร์ขนาดใหญ่ส่วนใหญ่ในไทย มักจะเจอภาพเดิม ๆ คือ ดิสแพตเชอร์ยืนถือปากกาไวท์บอร์ด พร้อมความรู้ในหัวว่าใบสั่งไหนควรขึ้นรถคันไหน วิธีนี้ใช้งานได้ในวันปกติ — จนกว่าจะมีวันที่ส่งของคลาดเคลื่อน รถถูกจองซ้อนกัน หรือมีคนถามว่า "โหลดสำหรับไซต์ 14 อยู่ไหนแล้ว" แล้วคำตอบที่ตรงที่สุดคือ "น่าจะอยู่บนถนนสักที่"

ส่วนที่น่าเสียดายคือข้อมูลที่จำเป็นต่อการแก้ปัญหานี้มีอยู่แล้วในองค์กร ทีมติดตั้งหน้างานรู้ว่าต้องใช้แผ่นไหน ที่ไหน เมื่อไหร่ ทีมโรงงานรู้ว่าผลิตอะไรเสร็จพร้อมส่งแล้วบ้าง และรถขนส่งส่วนใหญ่ก็มักติดตั้ง GPS ไว้อยู่แล้วเพื่อวัตถุประสงค์ด้านประกันภัยหรือบริหารน้ำมัน สิ่งที่ขาดหายไปจริง ๆ ไม่ใช่ข้อมูล แต่คือระบบที่เชื่อม "วันที่และสถานที่ส่งของ" → "อะไรขึ้นรถคันไหน" → "รถคันนั้นอยู่ที่ไหนจริง ๆ ตอนนี้" ให้เป็นข้อมูลชุดเดียวต่อเนื่องกัน แทนที่จะเป็นข้อมูลสามชุดที่ไม่เชื่อมกัน

นี่คือช่องว่างที่ โมดูลวางแผนโหลดรถขนส่ง (Vehicle Load Planning) ที่เชื่อมกับระบบ GPS ติดตามรถแบบเรียลไทม์ ถูกออกแบบมาเพื่อปิดช่องว่างนี้

ทำไมเรื่องนี้ถึงยากกว่าการวางแผนเส้นทางทั่วไป

ซอฟต์แวร์วางแผนเส้นทางหรือจัดการฟลีตสำเร็จรูปส่วนใหญ่มักตั้งสมมติฐานว่าสินค้าเป็นกล่องมาตรฐานที่จัดเรียงง่าย แต่ผู้ผลิตแผ่นพรีคาสต์ แผ่นพื้นสำเร็จรูป หรือชิ้นงานยาวเทอะทะจะเจอข้อจำกัดที่เครื่องมือทั่วไปมักไม่รองรับ นั่นคือ ความยาวของแคร่รถมักเป็นตัวจำกัดจริง ไม่ใช่น้ำหนักบรรทุก รถอาจยังรับน้ำหนักได้อีกมาก แต่รับแผ่นเพิ่มไม่ได้เพราะไม่มีที่วาง ระบบวางแผนโหลดที่ใช้ได้จริงกับสินค้าประเภทนี้จึงต้องคิดทั้งสองมิติ คือน้ำหนักและความยาว ไม่ใช่แค่มิติเดียว

ข้อจำกัดอีกอย่างที่เครื่องมือทั่วไปมักมองข้ามคือ หน้างานจริงมีข้อยกเว้นที่ระบบไม่มีทางรู้ เช่น รถคันหนึ่งถูกจองไปงานอื่นแล้ว หรือไซต์บางแห่งมีข้อจำกัดเรื่องช่วงเวลาส่งของ เครื่องมือวางแผนโหลดที่ดิสแพตเชอร์ปรับแก้เองไม่ได้ สุดท้ายจะกลายเป็นเครื่องมือที่คนหน้างานเลี่ยงใช้

แนวทางที่เราออกแบบ

เราออกแบบโมดูลนี้ให้เป็นส่วนต่อขยายของระบบ Production Execution & Traceability System ที่มีอยู่เดิม (บนฐาน simpliMES / ERPNext) ไม่ใช่เครื่องมือแยกต่างหากที่ต้องกรอกข้อมูลซ้ำซ้อน โฟลว์การทำงานเป็นดังนี้

flowchart TD
    A["คิวใบสั่งจัดส่ง"] --> B["บอร์ดวางแผนของดิสแพตเชอร์"]
    B --> C["ระบบเสนอแผนจัดรถอัตโนมัติ"]
    C --> D["ดิสแพตเชอร์ปรับแก้"]
    D --> E["ยืนยันแผนโหลด"]
    E --> F["สร้างรายการขนส่ง"]
    F --> G["ติดตาม GPS แบบเรียลไทม์"]
    G --> H["แดชบอร์ดและ ETA"]

คิวใบสั่งจัดส่ง — ดึงวันที่ต้องส่ง สถานที่ และรหัสสินค้า/แผ่นงาน มาจากตารางงานของทีมติดตั้งโดยตรง ไม่ต้องกรอกข้อมูลซ้ำ

บอร์ดวางแผนของดิสแพตเชอร์ — มุมมองปฏิทินแบบรถต่อวัน ทำให้เห็นภาพรวมกำลังการขนส่งทั้งสัปดาห์ในหน้าจอเดียว แทนที่จะอยู่แค่ในความจำของคนคนเดียว

ระบบเสนอแผนจัดรถอัตโนมัติ — ระบบเสนอแผนการโหลดต่อคันรถ โดยจับคู่ใบสั่งกับความจุที่เหลือทั้งน้ำหนักและความยาวแคร่ สำหรับสินค้ายาวเทอะทะ ความยาวมักเป็นตัวกำหนดแผนจริง

ปรับแก้ด้วยมือ — ดิสแพตเชอร์ลากวางสลับใบสั่งระหว่างรถหรือวันได้ เพื่อรองรับข้อยกเว้นที่ระบบมองไม่เห็น ระบบเสนอ แต่คนตัดสินใจ

ยืนยันแผนโหลด — เมื่อยืนยันแล้ว ระบบจะสร้างรายการขนส่งที่ผูกกับรหัสสินค้าโดยตรง และส่งต่อเข้าสู่ระบบติดตามแบบเรียลไทม์ทันที แทนที่จะเป็นสเปรดชีตแยกที่ต้องมากระทบยอดทีหลัง

GPS ติดตามรถเข้ามาเชื่อมตรงไหน

ส่วนติดตามตำแหน่งถูกออกแบบให้ใช้ฮาร์ดแวร์ GPS ที่ฟลีตมีอยู่เดิม เป้าหมายคือซอฟต์แวร์ที่ต่อยอดจากโครงสร้าง GPS ที่มีอยู่แล้ว ไม่ใช่การลงทุนฮาร์ดแวร์ใหม่ เมื่อยืนยันแผนโหลดและสร้างรายการขนส่งแล้ว รถจะถูกติดตามโดยอัตโนมัติ:

• อัปเดตสถานะด้วย Geofencing — สถานะการจัดส่งเปลี่ยนจาก Dispatched → In Transit → Arrived โดยอัตโนมัติตามพิกัดของรถ แทนการให้คนขับหรือดิสแพตเชอร์โทรแจ้งสถานะเอง
• มองเห็น ETA สำหรับทีมติดตั้ง — ทีมหน้างานไม่ต้องรอเก้อ หรือรถไปถึงเร็วกว่ากำหนดโดยไม่มีใครรู้ตัว
• ประวัติการเดินทางครบทุกรอบ — ผูกกับแผนโหลดและรหัสสินค้าเดียวกัน ทำให้ตอบคำถามได้จริงว่าแผ่นชิ้นนี้ส่งไปไหน เมื่อไหร่

การวางแผนโหลดและติดตาม GPS ถูกออกแบบให้เขียนข้อมูลลงรายการขนส่งเดียวกันตั้งแต่ต้น เพราะถ้าสร้างเป็นสองระบบแยกกัน — ระบบวางแผน กับระบบติดตาม — สุดท้ายก็จะเจอปัญหาต้องมากระทบยอดข้อมูลเหมือนเดิม แค่เปลี่ยนรูปแบบปัญหาเท่านั้น

ข้อควรทราบเรื่องข้อมูลตำแหน่งและความเป็นส่วนตัว

เพราะระบบนี้เก็บและประมวลผลข้อมูลตำแหน่งของรถและคนขับ จึงถือเป็นข้อมูลส่วนบุคคลภายใต้ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA) การออกแบบระบบจึงต้องคำนึงถึงวัตถุประสงค์การเก็บข้อมูลที่ชัดเจน (ติดตามการขนส่งเพื่อธุรกิจ ไม่ใช่เพื่อประเมินพนักงาน) ระยะเวลาการเก็บที่เหมาะสม และสิทธิ์การเข้าถึงข้อมูลตำแหน่งที่จำกัดเฉพาะผู้เกี่ยวข้อง สำหรับผู้ผลิตที่ตั้งอยู่ในพื้นที่ระเบียงเศรษฐกิจพิเศษภาคตะวันออก (EEC) หรือได้รับการส่งเสริมจาก BOI ซึ่งมักมีโรงงานและไซต์ติดตั้งกระจายในหลายจังหวัด ระบบตรวจสอบย้อนกลับที่ผูกกับรหัสสินค้าแบบนี้ยังช่วยรองรับข้อกำหนดด้านการตรวจสอบและมาตรฐานคุณภาพที่ลูกค้ารายใหญ่หรือหน่วยงานกำกับดูแลมักขอดูย้อนหลังได้ง่ายขึ้นด้วย

สิ่งที่โมดูลนี้แทนที่ และสิ่งที่ไม่ได้แทนที่

เพื่อความชัดเจนเรื่องขอบเขต: โมดูลนี้แทนที่การตัดสินใจจัดโหลดแบบไวท์บอร์ด และการโทรแจ้งสถานะด้วยมือ ด้วยแผนที่มีโครงสร้างและตรวจสอบย้อนกลับได้ต่อรหัสสินค้า แต่ไม่ได้ตัดดิสแพตเชอร์ออกจากกระบวนการ — แผนที่ระบบเสนอเป็นจุดเริ่มต้นให้คนยืนยันหรือปรับแก้ ไม่ใช่ระบบที่จัดส่งเองโดยอัตโนมัติ และระบบยังต้องอาศัยแพลตฟอร์ม GPS เดิมของฟลีตที่มี API หรือ webhook ใช้งานได้จริง ซึ่งเป็นขั้นตอนที่ต้องตรวจสอบก่อนเริ่มพัฒนา ไม่ใช่สมมติฐานที่ตั้งไว้ล่วงหน้า

คำถามที่พบบ่อย

ต้องติดตั้งฮาร์ดแวร์ GPS ใหม่หรือไม่
ไม่จำเป็น ระบบออกแบบมาให้เชื่อมต่อกับฮาร์ดแวร์ GPS ที่ฟลีตมีอยู่เดิม โดยมีเงื่อนไขว่าแพลตฟอร์มนั้นต้องเปิด API หรือ webhook สำหรับตำแหน่งและเหตุการณ์ geofence ให้ใช้งานได้

ใครเป็นคนตัดสินใจจัดรถ ระบบหรือดิสแพตเชอร์
ระบบเสนอแผนจากน้ำหนักและความยาวแคร่ ดิสแพตเชอร์ตรวจสอบและปรับแก้ได้เสมอด้วยการลากวางสลับใบสั่งระหว่างรถหรือวัน การตัดสินใจสุดท้ายยังอยู่ที่ดิสแพตเชอร์

ใช้แบบสแตนด์อโลนได้ไหม หรือต้องมีระบบ MES เต็มรูปแบบก่อน
ออกแบบให้ใช้ได้ทั้งสองแบบ ทั้งเป็นโมดูลเสริมบนฐาน ERPNext/simpliMES ที่มีอยู่ หรือรวมอยู่ในโครงการ Production Execution & Traceability เต็มรูปแบบ ขอบเขตและระยะเวลาแบบสแตนด์อโลนขึ้นอยู่กับว่าแพลตฟอร์ม GPS ของฟลีตเปิดสิทธิ์เชื่อมต่อได้จริงหรือไม่

ประวัติการเดินทางผูกกับรหัสสินค้าแต่ละชิ้นหรือไม่
ใช่ นี่คือหัวใจของการตรวจสอบย้อนกลับ แต่ละรอบการขนส่งผูกกับแผนโหลดและรหัสสินค้า/แผ่นงานที่บรรทุกจริง ไม่ใช่แค่บันทึก "รถคันไหนวิ่งเส้นทางไหน" แบบทั่วไป

เรื่องนี้อยู่ตรงไหนในภาพรวม

โมดูลนี้ต่อยอดจากหลักการตรวจสอบย้อนกลับเดียวกับงาน Production Execution & Traceability ของเราในภาพรวม — ทุกชิ้นงานที่ผลิตควรตรวจสอบย้อนกลับได้ตลอดทางจนถึงมือผู้รับ ไม่ใช่แค่ถึงประตูโรงงาน หากทีมของคุณยังวางแผนจัดรถด้วยไวท์บอร์ด และต้องโทรตามสถานะการส่งของอยู่ นี่คือช่องว่างที่ควรปิดเป็นลำดับถัดไป

สนใจปรับใช้กับฟลีตและระบบการผลิตของคุณ ติดต่อเราได้ที่ hello@simplico.net