CPAC × VMI × LPC × SCGJWD
ดูภาพเดียวเข้าใจทั้งกระบวนการ ตั้งแต่ Stock ใน Silo ไปจนถึง รถส่งปูนถึงโรงงาน โดยทุกทีมใช้ข้อมูลชุดเดียวกันใน iSupply
MESSAGE หลัก
ข้อมูลตรง · ส่งต่อง่าย
ปูนถึงทัน · รถไม่เสียเที่ยว
ข้อมูลเปลี่ยนเมื่อไร ให้แก้ใน iSupply ทันที เพื่อให้ Output ของทีมหนึ่งเป็น Input ที่เชื่อถือได้ของทีมถัดไป
AS-IS → TO-BE
ร่างเพื่อขอความเห็น · ยังไม่ Go-liveปัจจุบันมี ทีม VMI คั่นกลางระหว่าง iSupply กับ LPC และสื่อสารกับโรงงานผ่าน กลุ่ม LINE การเปลี่ยนแปลงจึงถูกทำนอกระบบ แล้วกลับมาแก้ด้วยมือ ข้อเสนอคือ ให้ iSupply ส่งถึง LPC โดยตรง โดยไม่ผ่านทีม VMI ในฐานะตัวส่งต่อ
ที่มา: สไลด์ “VMI Model | Cement replenishment in CPAC plant” · ผมจัดเรียงใหม่เป็น 5 เลน ตรงกับเลขขั้นตอน 1–7 ในสไลด์
กรอกยอดจองเทคอนกรีตทั้งหมดใน Bluenet
เช็กระดับปูนในไซโลโดยการเคาะ/ดิ่ง และกรอกใน i-Supply
ตรวจว่ารถเป่าปูนหมดแท้งค์ และยืนยันรับสินค้าผ่าน i-Supply (Auto GR)
i-Supply suggest และออก Order โดยอัตโนมัติ
บริหารรถขนส่งและจ่ายงานโดยทำ Route Optimization
จัดส่งปูนให้ถูกต้องทั้งโรงงานและไซโล scan QR และเป่าปูนที่ความดันมาตรฐาน
ตัดจ่ายปูน (โรงปูนกำหนดโดย VMI Team)
ผลคือ สถานะจริงของ Order อยู่ทั้งใน iSupply และในข้อความ LINE ทั้งสองแห่งไม่ตรงกันเสมอไป ระบบจึงถูกใช้แค่ “แนะนำ” ส่วนการตัดสินใจจริงกลับไปอยู่ในการสื่อสารด้วยมือ
กรอบ LINE/Manual ด้านบนมาจากคำอธิบายกระบวนการปัจจุบันของทีมงาน ไม่ได้อยู่ในสไลด์ต้นฉบับ
ผลสำรวจสรุปถึง 22 ก.ย. 2569 · 52 คำตอบ · 42 เคสที่มีปัญหา · 35 โรงงาน (การจัดกลุ่มเคสเป็นของผู้วิเคราะห์ ยังไม่ผ่านการยืนยันหน้างาน)
เมื่อการเปลี่ยนแปลงถูกแจ้งใน LINE แต่ระบบไม่รู้ Order ที่สร้างไว้ก็ยังเดินต่อ
โรงงานตั้ง Manual เพื่อหยุดสั่งอัตโนมัติ แต่ผลจริงไม่เป็นไปตามที่ตั้ง
ข้อมูลปลายทางที่ไม่ตรงกับความจริง ทำให้คำสั่งหลังบ้านไปไม่ถึงคนที่ต้องลงมือ
เพราะไม่เชื่อว่า Order ในระบบตรงกับงานจริง จึงกลายเป็นภาระประจำ
ข้อเสนอนี้เป็นความเห็นของผู้จัดทำเอกสาร เพื่อให้ทีมที่เกี่ยวข้องพิจารณา ยังไม่ใช่มติ
กรอก Stock / Booking และ แก้ไข-ยกเลิก Order ใน iSupply เอง ภายในเวลาตัดรอบ
คำนวณ · ออก Order/DN · รับสถานะกลับจาก LPC · แจ้งเตือน Exception อัตโนมัติ
รับ DN จากระบบโดยตรง → SO/STO → Tender → Match และ บันทึกเหตุผล Unmatched กลับใน iSupply
| งาน | AS-IS | TO-BE (ข้อเสนอ) |
|---|---|---|
| ส่งต่อ Order/DN ไป LPC | ทีม VMI | iSupply → LPC โดยตรง |
| รับเรื่องเปลี่ยน/ยกเลิกจากโรงงาน | LINE กลุ่ม VMI แล้วทีม VMI แก้ให้ | โรงงานแก้ใน iSupply เองก่อนตัดรอบ |
| ตั้งค่า Max/Min, A/B/C, master data | ทีม VMI | คงไว้ที่ทีม VMI (System owner) |
| เฝ้า Exception | ทีม VMI ด้วยมือ / รอโรงงานแจ้ง | ระบบเตือนอัตโนมัติ + ทีม VMI ติดตาม |
| กำหนดโรงปูน (Source) | ทีม VMI (ตามสไลด์) | รอยืนยัน — ใครกำหนดเมื่อไม่มี VMI ในเส้นทาง |
| LINE | ช่องทางสั่ง/ยกเลิก | แจ้งเตือนอย่างเดียว |
สาเหตุอันดับ 1 คืองานจองถูกยกเลิก (17 เคส) — ยกเลิกหลังตัดรอบต้องมีเส้นทางและเจ้าของชัดเจน
เคสหาดใหญ่ 2 (ระบบสลับกลับ Auto / ตั้ง Manual แล้วปูนยังเข้า)
เคสพัทลุง (Max สูง เหลือ 82/100 ตัน) และโคกกลอย (นับปูนถัง 3 ที่ไม่ใช้งาน)
เคสนครศรีธรรมราช 2 (OPC แต่สั่ง HB2, Level 5) และกระบี่
เคสควนขนุน (ตั๋วยังเป็นชื่อโรงงานเดิม) และเคสจัดส่งไม่ตรง Order 11 เคส
แก้เงื่อนไข 5 ข้อ ตั้งเจ้าของ Exception และเลือกโรงงานนำร่องกลุ่มเล็ก
iSupply ส่งถึง LPC เอง ทีม VMI ไม่แทรกแซง แต่บันทึกว่า “ถ้าเป็น AS-IS จะต้องแก้อะไร”
ขยายเมื่อตัวชี้วัดไม่แย่กว่า AS-IS แล้วจึงยกเลิก LINE ในฐานะช่องทางสั่ง
ตัวชี้วัดที่ใช้ตัดสิน
SCHEMA FLOW
AS-IS · ปัจจุบันทุกอย่างเดินบน 2 เส้นทางพร้อมกัน — เส้นทางข้อมูล (ใครส่งอะไรให้ใคร) และ เส้นทางปูนจริง (ปูนเดินทางจากโรงปูนไปถึง Silo) โดยมี iSupply เป็นข้อมูลกลางที่ทุกทีมเห็นตรงกัน
ตั้งค่า Silo · ตรวจ Stock เช้า · แจ้งเมื่อปูนเสี่ยงไม่พอ
Output: Stock + Silo statusป้อน Booking ให้ตรงงานจริง แก้ทันทีเมื่อเพิ่ม/ลด/เลื่อน/ยกเลิก
Output: Demand ล่าสุดจัดกลุ่ม A/B/C · คำนวณ Order · ตรวจ Exception · ออก DN
Output: Plan + DNรับ DN → ขอ SO/STO → Tender → Assign → Match
Output: สถานะรถ / เหตุผล Unmatchedรับเที่ยวใน Driver App · ไป Source · Scan ยืนยัน
Output: สถานะรับงาน/รับปูน/เดินทางจริงธุรการกิจการ (เลนข้าง) — เมื่อย้ายโรงปูน ให้ แก้ Source ใน iSupply แล้ว LPC จึงแจ้ง พขร. ต่อ · LINE ใช้แจ้งเตือนได้ แต่ไม่ใช่ข้อมูลหลัก
ข้อมูลชุดเดียวกัน · Single Source of Truth
iSupply — Stock · Booking · DN · SO/STO · Truck · Source · Scan
24 HOUR CYCLE
ระบบ Auto Order และทีมขนส่ง (LPC SCGJWD) ทำงานเป็นรอบตามเวลา — แตะรูปเพื่อขยาย
เริ่มส่ง SJWD และขอ SO/STO จาก Pre-order ที่ค้างคืนก่อนหน้า
คำนวณด้วย Stock เช้า · LPC ตรวจ Order เตรียมจัดรถรอบเช้า
งานจองแน่นอน
ลูกค้ามีโอกาสเลื่อน/ยกเลิก
งานจองไม่แน่นอน
ระบบคำนวณตามปกติแต่ ยังไม่ส่งข้อมูลไป SCGJWD จนถึง 08:00
สัดส่วน 70/20/10 อ่านจากภาพวงจรด้านบน เป็นสัดส่วนความแน่นอนของงานของแต่ละกลุ่ม ไม่ใช่เปอร์เซ็นต์ Safety stock
Stock เช้า → คำนวณ Order → จัดรถ → รับปูน → ลง Silo
ยืนยันระดับปูน ชนิดวัตถุดิบ Silo และรายการรับ–ใช้จริง
ใช้ Stock เช้า + ยอดรับวันนี้ − ยอดใช้วันนี้
เพิ่ม ลด เลื่อน ยกเลิก ต้องแก้ทันที
A 15:00 · B 16:00 · C 17:00 และหัก TMR demand
รับ DN → ขอ SO/STO ตามประเภท → Tender → Assign → Match
ตรวจ Source ใน Driver App และลงปูนถูก Silo
Est. today ending stock = Morning stock + Today confirmed inbound − Today usage
Reconcile Stock, รถที่รับแล้ว/กำลังมา และยอดใช้ก่อนออก DN
Adjusted ending stock = Est. today ending stock − TMR demand
ต้องหัก TMR demand ก่อนประเมินปริมาณเติม
Order need = max(0, Safety stock target − Available ending stock)
Safety stock = (Silo max × %Safety stock) + ปริมาณต่อเที่ยว · ดูค่าจริงในหัวข้อ ตั้งค่าระบบ
แต่ละทีมส่ง Output ที่ตรวจสอบได้ให้เจ้าของขั้นตอนถัดไป
ตั้งค่า Silo ตรวจ Stock เช้า แจ้งความเสี่ยง
Output: Stock + Silo statusดูแล Booking ให้ตรงงานจริง
Output: Demand ล่าสุดจัดกลุ่ม A/B/C คำนวณ ตรวจ Exception ออก DN
Output: Plan + DNLogistics Planning Center ขอ SO/STO จัดรถและ Match
Output: สถานะรถ / เหตุผล Unmatchedแก้ Source ใน iSupply
Output: Source ใหม่ + Audit trailรับเที่ยว ไป Source และ Scan
Output: สถานะปฏิบัติงานจริง| เหตุ | เจ้าของเริ่มแก้ | ข้อมูลร่วม |
|---|---|---|
| Stock ไม่ตรง | โรงงาน | Stock, Receipt, Usage, เวลา Sync |
| Booking เปลี่ยน | ศูนย์รับจ่าย | Demand ใหม่ + เวลาที่เปลี่ยน |
| Order ผิดปกติ | VMI | สูตร, Master, TMR, รถกำลังมา |
| DN ไม่ Match | LPC | เหตุผล, Source, Truck/slot |
| ย้ายโรงปูน | ธุรการ | Source ใหม่ใน iSupply |
“ข้อมูลเปลี่ยนเมื่อไร แก้ทันที อย่ารอถึง Cut-off”
ยืนยันความเสี่ยงก่อนเปิด Express และติดตามจน Match
ระบุ Silo ชนิดปูน Stock และเวลาคาดว่าจะหมด
เช็ก Receipt/Usage, ETA และ Silo headroom
ใส่เหตุผล ปริมาณ และเวลาที่ต้องถึง
ทวนสูตร Silo โรงปูน และ Cut-off
เฉพาะปริมาณที่จำเป็นพร้อมเหตุผล Exception
รายงาน ETA หรือเหตุผล Unmatched
แก้ครั้งเดียว ทุกทีมเห็น Source เดียวกัน
ระบุ DN, Source เดิม/ใหม่, เหตุผล และ ETA
ระบบเป็นข้อมูลหลัก; LINE ใช้แจ้งเตือน
ยืนยัน Source, slot และรถ
ให้รับ Source ใหม่ผ่านช่องทางปฏิบัติงาน
ตรวจ Driver App ก่อนเดินทาง
ยืนยันการรับ/ส่งตามขั้นตอน
เอกสารและ Transaction ต้องสอดคล้องกัน
MASTER DATA
ตรวจค่าตั้ง Silo และ Auto Order ให้ถูกต้องก่อนเปิดใช้งาน
