Chuck Roll A5 จากมุมของ ERP

คนทั่วไปมองวากิว A5 เป็นอาหารพรีเมียม

แต่ถ้ามองจากมุมของระบบ ERP  มันคือปัญหาทางระบบที่ซับซ้อนมาก

เนื้อหนึ่งชิ้นอาจต้องรู้ว่า

• มาจากจังหวัดอะไรในญี่ปุ่น

• อยู่ในกล่องหมายเลขอะไรในคลังแช่แข็ง

• น้ำหนักจริงเท่าไรตอนส่ง

• ควรถูกจัดให้ลูกค้ารายไหนก่อน

และคำถามสำคัญที่สุดคือ

เราควรออกแบบ SKU อย่างไร  เพื่อให้ Supply Chain ทั้งระบบยังทำงานได้

วันหนึ่งผมลองโยนคำถามให้ AI

“ถ้าจะเล่าเรื่อง Supply Chain ในระบบ ERP แต่ไม่อยากเริ่มจากเรื่องระบบเลย ควรเริ่มจากอะไรดี”

คำตอบกลับมาสั้นมาก

“เริ่มจากของจริง”

ผมจึงเริ่มเล่าเรื่อง Chuck Roll A5

ไม่ใช่ในฐานะเมนูอาหาร แต่ในฐานะวัตถุดิบที่ต้องเดินทางผ่าน Supply Chain

---

โลกของวากิว ที่คนทั่วไปไม่ค่อยเห็น

ธุรกิจที่ผมกำลังพูดถึง เป็นผู้นำเข้าวัตถุดิบอาหารจากญี่ปุ่น แล้วกระจายให้ร้านอาหารในประเทศไทย

ถ้ามองในภาพใหญ่ กระบวนการดูตรงไปตรงมา

• รวบรวมออเดอร์จากลูกค้าในไทย

• รวมยอดแล้วสั่งจากซัพพลายเออร์ในญี่ปุ่น

• สินค้าเข้ามาแล้วคัดแยก

• จากนั้นจัดส่งให้ลูกค้า

วงจรแบบนี้เกิดขึ้น สัปดาห์ละสองครั้ง

คำถามตามมาทันที

“ฟังดูเหมือนธุรกิจ trading ทั่วไป แล้วความยากอยู่ตรงไหน”

ตอนแรกผมก็คิดแบบนั้นเหมือนกัน

แต่พออยู่กับมันไปสักพัก ก็เริ่มเห็นว่า ธุรกิจวัตถุดิบสด โดยเฉพาะเกรดพรีเมียมแบบนี้

..ไม่ได้เรียบง่ายเลย

---

สินค้าชิ้นเดียว แต่ความหมายไม่เหมือนกัน

คำถามต่อมา

“สินค้าหลักคืออะไร”

คำตอบคือ

วากิวระดับ A5

แต่แค่คำว่าวากิวก็ยังไม่พอ

ลูกค้าบางรายต้องรู้ด้วยว่าเนื้อมาจากจังหวัดอะไรในญี่ปุ่น เช่น

• Kagoshima

• Miyazaki

• Hokkaido

คำถามต่อมาจึงเกิดขึ้นทันที

“แปลว่า specification ของสินค้า สำหรับลูกค้ากับสำหรับซัพพลายเออร์ อาจไม่เหมือนกัน”

..ใช่

สำหรับลูกค้าบางราย แค่ระบุว่า Wagyu A5 Shabu Cut หรือ Steak Cut ก็พอ

แต่สำหรับบางร้าน

จังหวัดที่มาของเนื้อ คือ specification สำคัญ

---

Chuck Roll ไม่ได้จบที่ชิ้นเดียว

คำถามยังไม่หยุด

“Chuck Roll คือสินค้าปลายทางเลยหรือ”

..ไม่

Chuck Roll เป็นเนื้อชิ้นใหญ่

เมื่อเข้ามาแล้ว มันมักถูกตัดแบ่งต่อเป็นชิ้นย่อย เช่น

• Chuck Eye สำหรับสเต็ก

• Chuck Rib สำหรับปิ้งย่าง

และตรงนี้เองที่คำถามสำคัญของ ERP โผล่ขึ้นมา

“แล้วในระบบ ERP คุณออกแบบ SKU อย่างไร”

---

คำถามที่ดูเหมือนง่าย แต่ตอบยาก

ลองคิดแบบนี้

ถ้าเราสร้าง SKU ละเอียดมาก เช่น

• Wagyu A5 Chuck Roll — Kagoshima

• Wagyu A5 Chuck Roll — Miyazaki

ข้อดีคือ traceability ชัดเจน

..แต่ข้อเสียคือ

จำนวน SKU จะเพิ่มขึ้นอย่างรวดเร็ว

และการจับคู่สินค้ากับออเดอร์จะซับซ้อนขึ้น

คำถามต่อมาจึงตามมา

“แล้วถ้าทำ SKU กว้างกว่านั้นล่ะ”

เช่น

Wagyu A5 Chuck Roll

แล้วเก็บรายละเอียดอย่างจังหวัดเป็น attribute

แนวทางนี้ลดจำนวน SKU ได้มาก

แต่ก็ทำให้การตัดสินใจตอนจัดสินค้า หรือ allocation

..ซับซ้อนขึ้นทันที

เพราะระบบต้องช่วยตอบคำถามว่า

สินค้าชิ้นไหนควรถูกใช้กับออเดอร์ไหน

นี่คือ trade-off ที่ต้องตัดสินใจตั้งแต่การออกแบบระบบ

---

โลกที่น้ำหนักไม่เคยตรงกับออเดอร์

คำถามใหม่ตามมา

“ลูกค้าสั่งสินค้าเป็นชิ้น หรือสั่งเป็นน้ำหนัก”

คำตอบคือ

..น้ำหนัก

และในโลกของเนื้อ มีความจริงอีกข้อหนึ่ง

น้ำหนักจริงมักไม่ตรงกับออเดอร์

ถ้าลูกค้าสั่ง

10 กิโลกรัม

สินค้าที่ได้จริงอาจเป็น

• 9.8 กิโลกรัม

• 10.3 กิโลกรัม

ในระบบ ERP สินค้าประเภทนี้เรียกว่า

Catch Weight Item

ซึ่งหมายความว่าระบบต้องเก็บข้อมูลสองอย่างพร้อมกัน

• จำนวนชิ้น สำหรับตรวจนับ

• น้ำหนักจริง สำหรับคำนวณราคา

รายละเอียดเล็ก ๆ แบบนี้ ทำให้ inventory management ซับซ้อนขึ้นทันที

---

การตัดสินใจที่ระบบต้องช่วยคิด

คำถามต่อมาเริ่มเข้าใกล้โลกของการปฏิบัติงาน

“ถ้าสินค้าไม่ตรง specification คุณทำอย่างไร”

สถานการณ์แบบนี้เกิดขึ้นบ่อย

• น้ำหนักไม่ตรง

• ป้ายสินค้าไม่ชัด

• สินค้าบางชิ้นถูกหยิบผิดก่อนหน้า

สุดท้ายต้องมีการตัดสินใจหน้างาน

เช่น

• ใช้เนื้อจากจังหวัดอื่นแทนได้ไหม

• ใช้เกรดที่สูงกว่าทดแทนได้หรือไม่

ในโลกของ ERP

การตัดสินใจแบบนี้ต้องถูกแปลงเป็น

allocation rule

ตัวอย่างเช่น

1. ใช้สินค้าที่ตรง specification ก่อน

2. หากไม่มี ให้ใช้สินค้าที่ใกล้เคียง

3. หากยังไม่พอ อาจใช้สินค้าที่เกรดสูงกว่า

นี่คือจุดที่ระบบเริ่มเข้ามาช่วยลดภาระการตัดสินใจของคนหน้างาน

---

ความจริงอีกชั้น: คลังแช่แข็ง

คำถามสุดท้ายมาจากเรื่องที่ดูเหมือนไม่เกี่ยวกับระบบ

“หลังจากสินค้ามาถึงแล้ว ถูกจัดส่งทันทีหรือไม่”

ไม่

การกระจายสินค้าอาจใช้เวลา 2–3 วัน หรือนานกว่านั้น

ดังนั้นสินค้าต้องถูกฝากไว้ที่ คลังแช่แข็ง

คำถามต่อมาคือ

“คลังนับสินค้าอย่างไร”

คำตอบคือ

กล่อง

ไม่ใช่ SKU ไม่ใช่น้ำหนัก

..แต่เป็น BOX

และถ้าสินค้าในกล่องไม่ได้เป็นสินค้าเดียวกัน

คลังอาจแยกพาเลตทันที

ซึ่งหมายถึง

ค่าฝากที่เพิ่มขึ้น

ดังนั้น ERP ต้องตอบคำถามสำคัญให้ได้ว่า

พรุ่งนี้ควรเบิก “กล่องหมายเลขอะไร”

เพื่อให้สามารถจัดสินค้าให้ตรงกับออเดอร์ลูกค้า

---

ความซับซ้อนที่กลายเป็นป้อมปราการ

เมื่อบทสนทนามาถึงตรงนี้ ภาพของธุรกิจเริ่มชัดขึ้น

ธุรกิจแบบนี้ไม่ได้ซับซ้อนเพราะเทคโนโลยี

แต่ซับซ้อนเพราะ ธรรมชาติของสินค้า

มันต้องจัดการพร้อมกันหลายอย่าง

• cold chain ห่วงโซ่ที่ต้องควบคุมอุณหภูมิ

• supplier network เครือข่ายผู้จัดหาสินค้า

• inventory accuracy ความแม่นยำของสต็อค

• allocation decision การเลือกสินค้าทดแทน

ถ้าระบบเหล่านี้ยังพึ่งพาความสามารถของคนเพียงไม่กี่คน

ธุรกิจก็จะขยายได้ยาก

แต่ถ้าความซับซ้อนเหล่านี้ถูกจัดการด้วยระบบที่ดี

มันจะกลายเป็น

Moat

หรือป้อมปราการทางธุรกิจ

---

มองสงครามสุกี้บุฟเฟต์ในมุมใหม่

ก่อนจะจบบทสนทนา ผมลองโยนคำถามสุดท้าย

“คุณคิดอย่างไรกับสงครามสุกี้บุฟเฟต์”

คนทั่วไปอาจมองว่าเป็น

• สงครามราคา

• สงครามการตลาด

• สงครามจำนวนสาขา

แต่ถ้ามองจากมุม Supply Chain

คำถามที่สำคัญกว่านั้นอาจเป็น

ใครมีระบบจัดการวัตถุดิบที่ดีกว่า

เพราะในท้ายที่สุด ธุรกิจที่ใช้วัตถุดิบสดจำนวนมาก

ไม่ได้แข่งกันแค่ที่หน้าร้าน

แต่แข่งกันที่

Supply Chain ที่อยู่เบื้องหลัง

และบางครั้ง

ERP ที่ออกแบบดี อาจเป็นหนึ่งในเหตุผลที่ทำให้ธุรกิจยืนระยะได้