Hybrid ERP ตอน 5: Architecture ที่อยู่กึ่งกลาง

Hybrid ERP Architecture: อยู่กึ่งกลางอย่างมีสติ

---

หลังจากผมขยับแนวคิดของ ERP จาก

Ledger → Event

คำถามถัดมาที่ผมโดนถามบ่อยมากคือ

"แล้วผู้ใช้จะเห็น event ยังไง"

เพราะในโลกของสถาปัตยกรรม

event อาจเป็น message

อาจเป็น log

อาจเป็น stream

แต่ในโลกของผู้ใช้ ERP

event มีชื่อเรียกที่ชัดเจนกว่านั้นมาก

---

สำหรับผู้ใช้ ERP, Event คือ "เอกสาร"

ผมไม่เคยบอกผู้ใช้ว่า

"คุณกำลังสร้าง event"

สิ่งที่พวกเขาเห็นคือ

เอกสาร

• ใบสั่งขาย

• ใบจัดสินค้า

• ใบส่งของ

• ใบรับคืน

• ใบปรับปรุง

แต่เบื้องหลัง

เอกสารเหล่านี้คือ

บันทึกเหตุการณ์ทางธุรกิจ ที่เกิดขึ้นจริงในขั้นตอนนั้น

---

เล่มเอกสาร = ขอบเขตของความรับผิดชอบ

สิ่งหนึ่งที่ผมตั้งใจออกแบบมากคือ

แนวคิดเรื่อง เล่มเอกสาร

หรือที่หลายคนเรียกว่า หมวดบิล

แต่สำหรับผม

เล่มเอกสารไม่ใช่แค่การจัดเลขรัน

มันคือ

การกำหนดว่า ใครมีสิทธิ์บันทึก "เหตุการณ์ประเภทไหน"

• เล่มยืนยันขาย → ฝ่ายขาย

• เล่มจัดส่ง → คลัง

• เล่มรับของ → จัดซื้อ

• เล่มบันทึกบัญชี → การเงิน

แต่ละเล่ม

คือ event type

ที่ถูกบันทึกโดยเจ้าของกระบวนการนั้นจริง ๆ

---

Document Flow คือ Event Flow ที่มนุษย์อ่านออก

จุดที่ทำให้ระบบของผมเริ่ม "พูดภาษาองค์กร" ได้

คือการออกแบบให้

เอกสารอ้างถึงเอกสารได้

• ใบจัดส่ง อ้างถึง ใบยืนยันขาย

• ใบรับคืน อ้างถึง ใบส่งของ

• ใบปรับปรุง อ้างถึง เหตุการณ์ก่อนหน้า

ทันทีที่เอกสารเชื่อมกัน

สิ่งที่เกิดขึ้นคือ

ร่องรอยของเหตุการณ์ถูกเก็บครบ โดยไม่ต้องเดา

ผู้ใช้เห็นเป็น

document flow

แต่ผมเห็นเป็น

event graph

---

ทำไมเอกสารในระบบผม "ละเอียดกว่า" เอกสารบัญชี

ระบบบัญชีแบบดั้งเดิม

ออกแบบเอกสารเพื่อ

สรุปผล

แต่ระบบ ERP ที่ผมสร้าง

ออกแบบเอกสารเพื่อ

บันทึกขั้นตอน

นั่นทำให้

• มีเอกสารมากขึ้น

• แต่แต่ละเอกสารเล็กลง

• และชัดเจนว่า "เกิดอะไรขึ้น"

บัญชีอาจสนใจแค่

ส่งของแล้ว → ลงรายได้

แต่ธุรกิจจริงสนใจว่า

• ใครจัด

• จัดเมื่อไหร่

• จัดครบไหม

• ค้างอะไรไว้

Hybrid Architecture ของผม

จึงยอมให้มีเอกสาร

ที่ไม่จำเป็นต่อบัญชี

แต่จำเป็นต่อความเข้าใจธุรกิจ

---

Hybrid ไม่ใช่ทางสายกลาง แต่คือการแบ่งบทบาท

ผมไม่ได้เลือก

Event-Driven 100%

และไม่ได้กลับไป Ledger-Driven

ผมเลือกแบบนี้แทน

• Event / Document

  ใช้บันทึก "ความจริงที่เกิดขึ้น"

• Ledger / Daily Stock

  ใช้สรุป "ความจริงในมุมที่ต้องการความนิ่ง"

ทั้งสองอ่านข้อมูลจากชุดเดียวกัน

แต่ไม่มีใครพยายามแทนที่กัน

---

เหตุผลที่ผมไม่สุดโต่ง

ผมเคยคิดจะทำ ERP แบบ event ล้วน

ไม่มีงวด

ไม่มีปิดบัญชี

แต่ผมทำงานกับโลกจริง

ที่ต้อง

• ปิดงบ

• ตรวจสอบย้อนหลัง

• อธิบายกับ auditor

Hybrid จึงไม่ใช่ทางเลือกที่ "สวย"

แต่มันคือทางเลือกที่ "อยู่ได้"

---

สถาปัตยกรรมที่ผมเชื่อในวันนี้

ERP ที่ดี

ไม่ควรบังคับให้

• ผู้ใช้คิดแบบบัญชี

• หรือบัญชีต้องตามแก้สิ่งที่หน้างานทำ

มันควรยอมรับว่า

ความจริงของธุรกิจ มีหลายจังหวะเวลา และหลายมุมมอง

เอกสารคือ event

event คือความจริง

ledger คือเรื่องเล่าที่ถูกสรุปแล้ว

---

บทเรียนจากตอนนี้

วันที่ผมเลิกถามว่า

"เอกสารนี้จะลงบัญชีอะไร"

แต่ถามว่า

"เอกสารนี้บันทึกเหตุการณ์อะไร"

ERP ของผม

เริ่มนิ่ง

และผู้ใช้เริ่มเข้าใจมันจริง ๆ

---

ตอนถัดไป

ตอนที่ 6: Design Pattern สำหรับ Hybrid ERP - สิ่งที่ผมใช้จริง และสิ่งที่ผมเลี่ยง

ผมจะเริ่มสรุปเป็น pattern ชัด ๆ

• Document-as-Event

• Flow-based Stock

• Read Model แยกจาก Write Model

• และกับดักที่ผมเคยพลาดมาแล้ว