Networked Fulfillment Model

บทเรียนจากการออกแบบ ERP สำหรับ Installation Ecosystem

เมื่อการติดตั้งไม่ใช่งานของบริษัทเดียว

วันหนึ่งระหว่างการประชุมออกแบบระบบ

มีคำถามหนึ่งที่ทำให้เราต้องหยุดคิด

“ธุรกรรมหนึ่งรายการในระบบนี้ จริง ๆ แล้วมีใครเกี่ยวข้องบ้าง?”

ตอนแรกคำถามนี้ฟังดูเหมือนคำถามพื้นฐานของระบบ ERP ทั่วไป

เพราะเรามักคุ้นเคยกับธุรกรรมแบบง่าย ๆ ระหว่างสองฝ่าย

ผู้ขาย และ ผู้ซื้อ

แต่เมื่อเราเริ่มไล่ดูสิ่งที่เกิดขึ้นจริงในธุรกิจนี้

คำตอบกลับซับซ้อนกว่านั้นมาก

มีร้านค้าที่คุยกับลูกค้า

มีช่างที่ไปติดตั้ง

มีผู้จัดหาสินค้าที่ถือสต็อก

และมีลูกค้าปลายทางที่ใช้งานสินค้า

ทั้งหมดนี้เกิดขึ้นใน “เหตุการณ์เดียวกัน”

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

และนั่นคือจุดที่เราพบว่า ธุรกิจนี้ไม่ได้เป็นเพียงระบบขายสินค้า

แต่มันคือ ระบบที่ต้องประสานงานเครือข่ายของผู้คนหลายฝ่าย

---

จุดเริ่มต้นของงานติดตั้ง

ในธุรกิจที่เกี่ยวข้องกับการติดตั้ง ลูกค้ามักไม่ได้เริ่มต้นจากแบรนด์สินค้าโดยตรง

ลูกค้าเริ่มจากคนที่ให้คำแนะนำก่อน

อาจเป็น

• ร้านค้า

• showroom

• ที่ปรึกษา

• ผู้รับเหมาท้องถิ่น

คนเหล่านี้ทำหน้าที่เป็นด่านหน้าในการให้บริการกับลูกค้า

เราจึงเรียกบทบาทนี้ว่า Service Front

หากมองอย่างง่าย กระบวนการอาจดูเหมือนเป็นแบบนี้

Customer
   │
   ▼
Service Front
(ร้านค้า / ที่ปรึกษา)
   │
   ▼
Installer
(ช่างติดตั้ง)
   │
   ▼
Reseller
(ผู้จัดหาสินค้า)

แต่สิ่งที่สำคัญคือ บริษัทหนึ่งมักไม่ได้มีทุกความสามารถอยู่ในตัวเอง

ร้านค้าอาจไม่ได้มีช่างติดตั้ง ช่างติดตั้งอาจไม่ได้มีสินค้าในสต็อก ผู้จัดหาสินค้าอาจไม่เคยพบลูกค้าเลย

งานติดตั้งหนึ่งงานจึงต้องอาศัย ความร่วมมือของหลายองค์กร

---

จาก Supply Chain สู่ Network

ในระบบจัดจำหน่ายสินค้าแบบดั้งเดิม เรามักเห็นโครงสร้างที่เป็นเส้นตรง

Manufacturer → Distributor → Dealer → Customer

แต่เมื่อมีการติดตั้งเข้ามาเกี่ยวข้อง โครงสร้างนี้เริ่มเปลี่ยนไป

Service Front หนึ่งแห่งอาจทำงานร่วมกับช่างหลายทีม

Service Front
 ├ Installer A
 ├ Installer B
 └ Installer C

ในขณะเดียวกัน ช่างแต่ละทีมก็อาจซื้อสินค้าจากผู้จัดหาหลายราย

Installer B
 ├ Reseller A
 ├ Reseller B
 └ Reseller C

สิ่งที่เราเห็นจึงไม่ใช่ chain อีกต่อไป

แต่มันกลายเป็น network ของผู้ร่วมงาน

และนี่คือจุดที่ระบบ ERP แบบดั้งเดิมเริ่มมีข้อจำกัด

เพราะ ERP ส่วนใหญ่ถูกออกแบบมาสำหรับโลกที่ความสัมพันธ์เป็นเส้นตรง

---

ศูนย์กลางที่แท้จริงของธุรกิจ

เมื่อเราลองมองระบบนี้จากอีกมุมหนึ่ง คำถามสำคัญคือ

“อะไรคือศูนย์กลางของธุรกิจนี้”

คำตอบไม่ใช่สินค้า

แต่คือ เหตุการณ์การติดตั้ง

                Product (Serial)
                      │
Customer ── Installation Event ── Installer
                      │
               Service Front
                      │
                   Reseller

เหตุการณ์การติดตั้งหนึ่งครั้งเชื่อมโยงทุกฝ่ายเข้าด้วยกัน

• สินค้าที่ถูกติดตั้ง

• ช่างที่ทำงาน

• ร้านที่ดูแลลูกค้า

• ผู้จัดหาสินค้า

• ลูกค้าปลายทาง

นี่คือ multi-party transaction

ในขณะที่ ERP ส่วนใหญ่ถูกออกแบบมาสำหรับธุรกรรมระหว่างสองฝ่าย

Seller ↔ Buyer

ความแตกต่างนี้ทำให้การออกแบบระบบต้องคิดใหม่ตั้งแต่พื้นฐาน

---

Serial Number: สะพานระหว่างสินค้าและบริการ

สำหรับเจ้าของสินค้า สิ่งที่สำคัญคือการติดตามว่าสินค้าเดินทางผ่าน ecosystem อย่างไร

เครื่องมือสำคัญคือ serial number

Product
   │
   ▼
Serial Number
   │
   ▼
Reseller

เมื่อสินค้าถูกติดตั้ง serial number จะถูกเชื่อมเข้ากับ installation event

Serial Number
      │
      ▼
Installation Event
      │
      ▼
Customer

ตั้งแต่วินาทีนั้น ระบบจะสามารถตอบคำถามสำคัญได้ เช่น

• สินค้านี้ถูกจัดจำหน่ายผ่านใคร

• ใครเป็นผู้ติดตั้ง

• ลูกค้าปลายทางคือใคร

serial number จึงกลายเป็น สะพานเชื่อมระหว่างโลกของสินค้าและโลกของบริการ

---

ข้อมูลสำคัญเกิดหลังการขาย

อีกสิ่งหนึ่งที่ทำให้ระบบนี้แตกต่างจากระบบขายสินค้าทั่วไป คือข้อมูลสำคัญจำนวนมากไม่ได้เกิดขึ้นในตอนขาย

แต่มักเกิดขึ้น หลังจากการติดตั้งเสร็จแล้ว

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

Scan Serial Number
        │
        ▼
Select Installer
        │
        ▼
Select Service Front
        │
        ▼
Register Customer
        │
        ▼
Activate Warranty

นั่นหมายความว่า ระบบต้องรองรับ เหตุการณ์ทางธุรกิจหลังการขาย

ซึ่งไม่ใช่สิ่งที่ ERP แบบดั้งเดิมให้ความสำคัญมากนัก

---

Identity ที่มีสองระดับ

อีกความซับซ้อนหนึ่งคือ ผู้เล่นในระบบมีทั้ง

• ระดับบุคคล

• ระดับองค์กร

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

Organization
   │
   ├ Employee A
   ├ Employee B
   └ Employee C

เมื่อเกิด installation event ระบบอาจต้องบันทึกทั้งบุคคลและบริษัท

Installer (Person)
     │
     ▼
Installer Company

หรือ

Service Staff (Person)
     │
     ▼
Service Company

ดังนั้นระบบจึงต้องออกแบบ identity model สองชั้น

• Person

• Organization

---

บทบาทที่เปลี่ยนแปลงได้

ใน ecosystem แบบนี้ บทบาทขององค์กรไม่ได้ตายตัว

บางบริษัทอาจทำหลายบทบาทพร้อมกัน

Company A
 ├ Service Front
 ├ Installer
 └ Reseller

บางบริษัทอาจเป็นเพียงช่างติดตั้งอย่างเดียว

Company B
 └ Installer

ระบบจึงต้องรองรับ dynamic role

ไม่ใช่กำหนดประเภทองค์กรแบบตายตัวตั้งแต่ต้น

---

จาก Document-Centric สู่ Event-Centric

ERP ส่วนใหญ่ถูกออกแบบโดยมีเอกสารเป็นศูนย์กลาง

Sales Order
   ↓
Delivery
   ↓
Invoice

แต่ใน ecosystem ของการติดตั้ง สิ่งที่สำคัญที่สุดไม่ใช่เอกสาร

แต่คือ เหตุการณ์

Installation Event

เหตุการณ์นี้เป็นจุดที่เชื่อมโยงทุกอย่างในระบบ

• product

• customer

• installer

• service front

• reseller

ดังนั้นการออกแบบระบบจึงควรเริ่มจาก event model

ไม่ใช่เริ่มจากเอกสารทางธุรกิจ

---

บทเรียนจากระบบลักษณะนี้

ในตอนแรก ธุรกิจนี้อาจดูเหมือนเป็นเพียงระบบจัดจำหน่ายสินค้า

แต่เมื่อมองจากวิธีทำงานจริงในภาคสนาม เราจะพบว่า

ความท้าทายของระบบไม่ได้อยู่ที่การขายสินค้า

แต่อยู่ที่ การประสานงานของเครือข่ายผู้เล่นหลายฝ่าย

หรืออาจพูดอีกแบบหนึ่งได้ว่า

ปัญหาของระบบนี้ไม่ใช่การขายสินค้า แต่คือการทำให้เครือข่ายทำงานร่วมกันได้

เมื่อมองเห็นสิ่งนี้ การออกแบบ ERP ก็จะเปลี่ยนไป

แทนที่จะโฟกัสเพียงเอกสารการขาย ระบบต้องสามารถสะท้อน

• ความสัมพันธ์แบบ network

• ธุรกรรมที่มีหลายฝ่าย

• เหตุการณ์บริการหลังการขาย

• และการติดตามสินค้าผ่าน serial number

เมื่อระบบสะท้อนโลกของการทำงานจริงได้ครบถ้วน มันจึงจะสามารถรองรับการเติบโตของ ecosystem นี้ได้ในระยะยาว