คนทั่วไปมองวากิว A5 เป็นอาหารพรีเมียม แต่ถ้ามองจากมุมของระบบ ERP  มันคือปัญหาทางระบบที่ซับซ้อนมาก

ผมนั่งคุยกับ AI เรื่องระบบ ERP สำหรับธุรกิจสินค้าสะสมมือสองประเภท Luxury แหวนเพชร นาฬิกา ทอง เครื่องประดับหายาก

ผมตั้งคำถามกับตัวเองบ่อยขึ้นว่า  เรากำลังออกแบบ UX ให้กับ “มนุษย์”  หรือเรากำลังออกแบบ UX ให้กับ “จังหวะ” ของกระบวนการทำงานกันแน่ 

ในโลกของการออกแบบระบบ  ไม่มีใครตั้งใจสร้างข้อจำกัดให้ผู้ใช้ ข้อจำกัดจำนวนมากเกิดจากความพยายาม  “ทำให้ถูกต้อง” และ “ปลอดภัย” มากพอ โดยเฉพาะเมื่อระบบนั้นเกี่ยวข้องกับบัญชี ภาษี และกฏหมาย หนึ่งในแนวคิดที่ถูกฝังนิยามลงไปในซอฟต์แวร์ธุรกิจมาอย่างยาวนาน  คือคำว่า “สาขา” คำนี้ดูเหมือนเรียบง่าย เป็นธรรมชาติ และไม่มีอะไรให้ตั้งคำถาม แต่เมื่อพิจารณาให้ลึกลงไป เราอาจพบว่ สิ่งที่ซอฟต์แวร์จำนวนมากเรียกว่า “สาขา” ไม่ใช่สิ่งเดียวกับที่กิจการยุคใหม่กำลังใช้งานอยู่จริง Cloud เปลี่ยนสิ่งแวดล้อม

วางบิล: จากปัญหาหน้างาน สู่คำถามที่ระบบไม่อยากตอบ ผมเริ่มต้นบทสนทนานี้เหมือนคนทำงานระบบทั่วไป มีข้อมูลจริงอยู่ในมือ และมีคำถามเชิงเทคนิคอยู่ในหัว ผมส่งรายการ “เงื่อนไขการวางบิล”  ที่รวบรวมมาจากลูกค้าของกิจการแห่งหนึ่งให้ AI ดู เป็นข้อความที่ใครอยู่สายบัญชีจะอ่านแล้วเข้าใจทันที และใครอยู่สายระบบจะอ่านแล้วเริ่มปวดหัว วางบิลทุกวันที่ 5 ของเดือน (ตรงวันหยุดเลื่อน) วางบิล 1–3 ของเดือน วางบิล 2 วันสุดท้าย วางบิล 15 และ 30 วางบิลเฉพาะ จ–ศ เวลา 08.30–17.00 วางบิลพร้อม PO ต้นฉบับ + ใบ

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

"ไม่เห็นสำนักบัญชีวางระบบ ERP ให้ตัวเองใช้เลย"

สิ่งที่ผมน่าจะรู้ ตั้งแต่วันแรกที่เริ่มเขียน ERP

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

Hybrid ERP Architecture: อยู่กึ่งกลางอย่างมีสติ --- หลังจากผมขยับแนวคิดของ ERP จาก Ledger → Event คำถามถัดมาที่ผมโดนถามบ่อยมากคือ "แล้วผู้ใช้จะเห็น event ยังไง" เพราะในโลกของสถาปัตยกรรม event อาจเป็น message อาจเป็น log อาจเป็น stream แต่ในโลกของผู้ใช้ ERP event มีชื่อเรียกที่ชัดเจนกว่านั้นมาก สำหรับผู้ใช้ ERP, Event คือ "เอกสาร" ผมไม่เคยบอกผู้ใช้ว่า "คุณกำลังสร้าง event" สิ่งที่พวกเขาเห็นคือ เอกสาร ใบสั่งขาย ใบจัดสินค้า ใบส่งของ ใบรับคืน ใบปรับปรุง แต่เบื้องหลัง เอกสารเหล่าน

วันที่ผมเลิกเริ่มออกแบบ ERP จาก Ledger และหันมาเริ่มจาก Event

วันที่ผมเลิกถามว่า "ของเหลือเท่าไหร่" แล้วเริ่มถามว่า "ของอยู่ในสถานะอะไร"

วันที่ผมรู้ว่า "ตัวเลขเดียว" ไม่เคยมีอยู่จริง

ผมเคยคิดว่า Inventory Control เป็นเรื่องง่าย จนกระทั่ง ERP ตัวแรกของผมพัง

VAT เข้าใจผิดจุดเดียว งบเพี้ยนทั้งระบบ

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

ซื้อไม่เสีย VAT แต่ขายอาจต้องเสีย บทเรียน VAT ที่บัญชีพลาด

"ไม่มี VAT" คำสั้น ๆ ที่ทำให้ต้นทุนเพี้ยนทั้งงบ หากมีคำหนึ่งคำที่ผมคิดว่า "อันตรายที่สุด" ในงานบัญชีและการวางระบบ VAT คำนั้นคือคำว่า "รายการนี้ไม่มี VAT" เพราะในระบบภาษีมูลค่าเพิ่มของไทย คำว่า "ไม่มี VAT" ไม่ได้มีความหมายเดียว และความเข้าใจผิดเพียงจุดนี้ สามารถทำให้ภาษีซื้อจำนวนมาก ค่อย ๆ กลายเป็นต้นทุนในงบกำไรขาดทุน โดยที่ไม่มีใครตั้งใจให้เป็นเช่นนั้นตั้งแต่แรก "ไม่มี VAT" ในทางบัญชี แปลได้อย่างน้อยสองแบบ ในทางปฏิบัติ เมื่อทีมบัญชีหรือผู้ใช้งานระบบพูดว่า "รายการนี้ไม่มี VAT"

ทำไมบริษัทขนส่งไม่เสีย VAT แต่ร้านค้าต้องเสีย

VAT ไม่ได้ดูแค่ “รายการ” แต่ดูว่า “ใครเป็นคนทำ”