Hybrid ERP ตอน 6: Design Pattern
- Sathit Jittanupat
- 17 ม.ค.
- ยาว 1 นาที
Design Pattern สำหรับ Hybrid ERP: สิ่งที่ผมใช้จริง และสิ่งที่ผมเลี่ยง
หลังจากผมเปลี่ยนวิธีคิด
จาก ออกแบบ ERP จาก ledger
มาเป็น ออกแบบ ERP จาก event ที่ผู้ใช้เรียกว่า "เอกสาร"
คำถามที่ผมเจอบ่อยที่สุดจากทีมพัฒนาคือ
"สรุปแล้ว เราควรออกแบบระบบยังไงดี"
ผมไม่มีคำตอบสำเร็จรูป
แต่ผมมี pattern ที่ค่อย ๆ ก่อตัวขึ้นจากระบบที่ใช้งานจริง
และที่สำคัญพอ ๆ กัน
คือ anti-pattern ที่ผมไม่อยากกลับไปเจออีก
Pattern ที่ 1: Document-as-Event
เอกสารไม่ใช่ผลลัพธ์ แต่คือความจริง
ผมเลิกมองเอกสารว่าเป็น output เพื่อพิมพ์หรือส่งบัญชี
แต่เริ่มมองว่า ทุกเอกสารคือ event หนึ่งในชีวิตของธุรกิจ
เงื่อนไขสำคัญของ pattern นี้คือ
เอกสารต้อง immutable หลัง confirm
การแก้ไขคือการสร้างเอกสารใหม่
เอกสารต้องบอกได้ว่า "ใคร ทำอะไร เมื่อไหร่"
ถ้าเอกสารยังแก้ทับได้เรื่อย ๆ
มันยังไม่ใช่ event
Pattern ที่ 2: Flow-Based Stock
อย่าคุม stock ด้วยยอดรวม
แทนที่จะมี stock balance เดียว
ผมออกแบบให้ stock ถูกแยกตาม flow label
แต่ละ transaction ระบุ from-flow → to-flow
แต่ละ flow มียอดคงเหลือของตัวเอง
การย้ายสถานะ = การไหล ไม่ใช่การแก้ค่า
ผลที่ได้คือ
นิยาม "พร้อมขาย" ได้ชัด
ลด logic ซ้อนใน report
Debug ได้จากการไหล ไม่ใช่จากผลรวม
Pattern ที่ 3: Single Source of Event, Multiple Read Models
เขียนครั้งเดียว อ่านหลายแบบ
ผมยอมลงทุนกับ event ให้ชัด
แล้วปล่อยให้ระบบอื่น ๆ
"อ่านและเล่าเรื่อง" จาก event ชุดเดียวกัน
Realtime stock อ่านเพื่อความเร็ว
Daily stock อ่านเพื่อความนิ่ง
Ledger อ่านเพื่อการปิดงบ
Dashboard อ่านเพื่อการตัดสินใจ
ไม่มีใครแก้ event
ทุกคนตีความมันในบริบทของตัวเอง
Pattern ที่ 4: Event First, Accounting Later
อย่ารีบลงบัญชี
ทุกครั้งที่ผมพยายาม
map event → accounting ทันที
ผมมักจะเจอปัญหาเมื่อโลกจริงไม่ตรงตามตำรา
สิ่งที่ผมเลือกทำคือ
บันทึก event ให้ครบก่อน
ปล่อยให้ accounting เป็น consumer หนึ่ง
ยอมรับว่าบาง event อาจยังไม่ "ลงบัญชี" ทันที
บัญชีได้ความถูกต้อง
ระบบได้ความยืดหยุ่น
Pattern ที่ 5: Explicit Document Flow
ความสัมพันธ์ต้องถูกบันทึก ไม่ใช่เดา
เอกสารในระบบของผม
ไม่ควรถูกปล่อยให้ลอยเดี่ยว
ใบจัดส่ง ต้องรู้ว่าอ้างถึงใบไหน
ใบรับคืน ต้องรู้ว่าคืนจากเหตุการณ์ใด
ใบปรับปรุง ต้องรู้ว่าปรับเพราะอะไร
เมื่อเอกสารเชื่อมกัน
audit trail จะเกิดขึ้นเอง
โดยไม่ต้องสร้าง report พิเศษ
สิ่งที่ผม "เลี่ยง" อย่างตั้งใจ
Anti-pattern 1: Smart Balance Table
ตารางยอดคงเหลือที่
update หลายจุด
มี logic ซ่อน
ไม่มีที่มาที่ไป
มันเร็วในช่วงแรก
แต่จะทำให้คุณไม่รู้ว่า
ตัวเลขนั้นเกิดจากอะไร
Anti-pattern 2: Editable History
การอนุญาตให้
แก้เอกสารย้อนหลัง
เพื่อให้ตัวเลข "ดูดี"
ผมเคยทำ
และผมเสียใจทุกครั้งที่ต้อง debug
ถ้าความจริงเปลี่ยน
ให้บันทึกความจริงใหม่
อย่าลบความจริงเก่า
Anti-pattern 3: One Report to Rule Them All
รายงานเดียว
พยายามตอบทุกฝ่าย
สุดท้ายจะไม่มีใครเชื่อมัน
เพราะมันไม่พูดภาษาใครเลย
สิ่งที่ผมได้เรียนรู้จากการใช้ pattern เหล่านี้
Hybrid ERP
ไม่ใช่เรื่องของเทคโนโลยี
แต่เป็นเรื่องของ
การเคารพความจริงหลายมิติของธุรกิจ
ถ้าคุณออกแบบระบบ
ที่
เหตุการณ์ถูกบันทึกชัด
ความรับผิดชอบถูกแยก
การสรุปถูกเลื่อนเวลาอย่างมีสติ
ระบบจะไม่ต้องฉลาดมาก
แต่จะ ซื่อสัตย์ กับสิ่งที่เกิดขึ้น
ตอนถัดไป (ตอนสุดท้าย)
ตอนที่ 7: สิ่งที่ผมน่าจะรู้ตั้งแต่วันแรกที่เริ่มเขียน ERP
ผมจะสรุปซีรีส์นี้
ด้วยบทเรียนแบบไม่เทคนิค
แต่กระทบวิธีคิดของคนพัฒนาระบบระยะยาว
ความคิดเห็น