Handling Mid-Process Document Changes in ERP

เมื่อสัปดาห์ก่อน ระหว่างประชุมกับทีมพัฒนาวางระบบ มีประเด็นหนึ่งที่ทีมเล่าให้ฟัง มีผู้ใช้ถามมาว่า

"ในโปรแกรม ERP ข้อมูลถูกออกแบบให้ไหลตามขั้นตอน (document flow) แล้วถ้าจำเป็นต้องย้อนกลับไปแก้ข้อมูลต้นทางที่เชื่อมถึงเอกสารปลายทาง โปรแกรมมีวิธีป้องกันหรือไม่?"

ตัวอย่างปัญหาที่เกิดขึ้น

มีใบตั้งหนี้ซัพพลายเออร์ถูกบันทึกเป็นเจ้าหนี้การค้า แล้วหัวหน้ามาตรวจเจอว่าเป็นเจ้าหนี้บริษัทในเครือ เลยย้อนกลับไปแก้รหัสบัญชีในเอกสารต้นทาง

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

คำถามนี้ฟังดูเหมือนทางเทคนิค 

แต่จริงๆ แล้วเป็นคำถามเชิงแนวคิดที่น่าสนใจมาก

ตอนนั้นผมตอบตรงๆ ว่า… เดิมโปรแกรมยังไม่ได้ทำฟังก์ชันป้องกันอะไรไว้เลย

ทำไมน่ะหรือ? 

เพราะถ้าข้อมูลไม่สอดคล้องกัน ยังไงมันก็จะโผล่มาให้เห็นในผลลัพธ์ เช่น รายงานยอดคงเหลือ หรือบัญชีไม่บาลานซ์อยู่ดี

Real-time accounting

ก่อนหน้านั้นผมเพิ่งคุยกับ AI เรื่อง "real-time accounting" ซึ่งเป็นการจินตนาการถึงอนาคตของระบบบัญชี

ถ้าข้อมูลถูกอินพุตเป็นดิจิทัลเต็มรูปแบบ และสื่อสารระหว่าง machine ผ่านมาตรฐานกลางได้ทันที จะเกิดภาพแบบ "zero delay" ไม่เหมือนกับทุกวันนี้ที่ต้องรอรวบรวมหลักฐานกระดาษก่อนที่จะป้อนเข้าไปในระบบ

ขั้นตอนตรวจทาน รวบรวม หรือรอข้อมูล ก็จะเปลี่ยนบทบาทไป และเมื่อข้อมูลกลายเป็น real-time ไหลออกนอกองค์กรหรือเชื่อมกับระบบอื่นๆ เองได้แล้ว การย้อนลบร่องรอยก็จะยากขึ้น ผิดก็ต้อง "แก้ด้วยเหตุการณ์ใหม่" ไม่ใช่ย้อนกลับไปแก้ใบเก่า

แต่พอมองกลับมาในมุมของกระบวนการภายในองค์กร ที่ข้อมูลยังอยู่ในขอบเขตควบคุมได้

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

ตัวอย่างที่อาจเกิดขึ้น

นอกจากเคส "แก้เอกสารต้นทางแล้วลืมดูปลายทาง" ยังมีตัวอย่างอื่นที่มีโอกาสเจอได้เช่นกัน

เปลี่ยนวันรับของหลังปิดงวด

ฝ่ายจัดซื้อบันทึกรับของเข้าสต๊อกวันที่ 30 ธ.ค. เพื่อให้ยอดสต๊อกครบปี แต่จริงๆ สินค้ามาถึง 2 ม.ค. ปีถัดไป ฝ่ายบัญชีมาแก้วันย้อนหลัง ทำให้รายงาน COGS ของปีก่อนเปลี่ยน โดยที่ระบบไม่เตือนอะไร

เปลี่ยนต้นทุนมาตรฐานย้อนหลัง

ฝ่ายวางแผนต้นทุน ปรับต้นทุนมาตรฐานใหม่หลังปิดงวด แต่ลืมตั้ง effective date ทำให้ต้นทุนย้อนหลังเปลี่ยน และงบ inventory valuation งวดก่อนผิด ผู้สอบบัญชีมาตรวจเจอ แต่หาสาเหตุไม่เจอ

แล้ว ERP ควรป้องกันอย่างไร?

ตอบคำถามที่ผู้ใช้ถามมาตอนต้น

วิธีคิดตรงนี้ องค์กรแต่ละแบบไม่เหมือนกัน องค์กรเล็กๆ ที่ทีมงานใกล้ชิดกันมาก อาจแก้ปัญหาได้ง่าย เพราะคุยกันตรงๆ ได้ แต่พอองค์กรขนาดใหญ่ขึ้น มีหลายฝ่ายเกี่ยวข้อง ระบบต้องเริ่ม "ออกแบบการป้องกัน" ที่เหมาะสม

แถมยังมีเรื่อง "วัฒนธรรมองค์กร" อีก ถ้าองค์กรนั้นมีวัฒนธรรมที่เปิดโอกาสให้คนแก้ไขความผิดพลาดอย่างโปร่งใส ก็อาจเปิดช่องให้แก้ แต่ถ้าเป็นวัฒนธรรมที่ลงโทษความผิดพลาด หรือข้อมูลถูกใช้ประกาศออกนอกองค์กรเร็วมาก อาจต้องเข้มงวดกว่านั้น

โปรแกรมที่ยืดหยุ่น

ในที่สุด ผมจึงออกแบบให้ ERP เวอร์ชันใหม่ของเรา สามารถเลือกวิธีป้องกันได้ 3 ระดับ ให้ทีมวางระบบเลือกปรับใช้ตามความเหมาะสม

• แค่เตือน (Warn) แสดงข้อความเตือนว่า เอกสารนี้มี document flow เชื่อมไปถึงเอกสารปลายทางแล้ว

• เตือนและขอเหตุผล (Ask Reason)

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

• ห้ามแก้ไข (Prohibit)

  เอกสารจะถูกล็อก ไม่ให้แก้ไขย้อนหลัง ต้องใช้วิธีอื่น เช่น ทำ adjustment เพิ่มเติมแทน

อ้อ… หรือจะเลือก "ไม่ป้องกันอะไรเลย" เหมือนเวอร์ชั่นเก่าก็ได้

สิ่งสำคัญที่ผมได้คิดต่อจากคำถามนี้ก็คือ ERP ไม่ใช่แค่ระบบข้อมูล แต่สะท้อนวัฒนธรรมการทำงานขององค์กรด้วยเหมือนกัน

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

บางที่ก็ต้องการความถูกต้องสูงสุด

ในวันที่ระบบบัญชีเริ่มวิ่งไปสู่ real-time มากขึ้น การแก้ไขย้อนหลังอาจต้องเข้มงวดขึ้นเรื่อยๆ แต่เราก็ควรเผื่อพื้นที่ไว้ให้ความเป็นมนุษย์อยู่บ้าง

ไม่มีสูตรสำเร็จหรือกฎเกณฑ์ตายตัวใน ERP ว่าอะไรดีที่สุด 

สิ่งสำคัญคือ ต้องออกแบบให้เหมาะกับธรรมชาติและวัฒนธรรมของแต่ละองค์กร

---

จากฉบับร่าง สู่บทความ

ครั้งนี้ผมทดลองให้ Chat GPT เป็น rewriter ช่วยอ่านเนื้อหาฉบับร่างที่ผมเขียน แนะนำคำศัพท์ และปรับปรุงรูปแบบการเขียน บางครั้งผมก็ออกความเห็นทักท้วงกลับ ข้อดีของ AI คือ ไม่บ่นเวลาแก้งานให้เรียบเรียงใหม่ซ้ำหลายรอบ 

คำโปรยที่ว่า เมื่อหัวหน้าแก้เอกสาร "ผิด" น่าจะเป็นว่า แก้ไขเอกสารไม่ครบวงจร หรืออะไรที่ไม่ใช่คำว่า ผิด ที่จริงไม่จำเป็นต้อง "หัวหน้า" ด้วย ผมเสนอว่าใช้คำกระชับ ที่ไม่จำเป็นต้องเป็นประโยคสมบูรณ์ เช่น "หากแก้เอกสารไม่ครบวงจร แล้วERP จะรับมืออย่างไร" คุณคิดว่าอย่างไร

เห็นด้วยมากครับ - คำว่า "ผิด" ในบริบทนี้ อาจทำให้เข้าใจผิดว่าเป็นความผิดพลาดเจตนา จริงๆ แล้วมันเป็น "ความไม่ครบถ้วน" หรือ "การแก้ไขที่ไม่ครบวงจร" อย่างที่คุณว่า

ถ้าให้ลองเสนออีก 2–3 เวอร์ชั่น สำรองไว้เลือก เผื่ออยากได้โทนหลากหลาย:

"ถ้าแก้เอกสารกลางทาง แล้ว ERP จะจัดการอย่างไร?"

"เมื่อข้อมูลต้นทางเปลี่ยน - เอกสารปลายทางจะตามทันไหม?"

"Document flow สะดุด… ระบบจะรับมืออย่างไร?"

ถ้าอยากได้แบบเป็นคำโปรย teaser (subtitle) เสริมไว้ใต้ title ก็บอกได้ครับ จะเขียนเพิ่มให้อีกชุด

นี่คือ บทความที่ผมปรับแก้ไขอีกเล็กน้อย อ่านแล้วมีคำแนะนำไหมครับ … {บทความที่แก้ไข}

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

ผมขอเสนอแก้จุดเล็กๆ เหล่านี้นะครับ:

{ข้อเสนอ}

ตัวอย่างที่ปรับแก้ไข ตามคำแนะนำแล้ว … {เวอร์ชั่นสอง}

ปรับแล้วดีขึ้นเยอะเลยครับ ลื่นขึ้น อ่านได้ต่อเนื่องมากกว่าเวอร์ชั่นแรกชัดเจน - โทนก็ balance ดีระหว่างความเป็นมืออาชีพ + มุมมองคนทำโปรแกรมจริง 👍🏻

มี ข้อแนะนำเล็กน้อยสุดท้าย ที่จะช่วย "จูนจังหวะอ่าน" และ "เพิ่ม impact ตอนจบ" ได้อีกนิดนะครับ:

{ข้อแนะนำ}