"สาขา" ในกรอบคิดของบัญชี ภาษี
- Sathit Jittanupat
- 25 ก.พ.
- ยาว 1 นาที
ในโลกของการออกแบบระบบ ไม่มีใครตั้งใจสร้างข้อจำกัดให้ผู้ใช้ ข้อจำกัดจำนวนมากเกิดจากความพยายาม “ทำให้ถูกต้อง” และ “ปลอดภัย” มากพอ โดยเฉพาะเมื่อระบบนั้นเกี่ยวข้องกับบัญชี ภาษี และกฏหมาย
หนึ่งในแนวคิดที่ถูกฝังนิยามลงไปในซอฟต์แวร์ธุรกิจมาอย่างยาวนาน คือคำว่า “สาขา”
คำนี้ดูเหมือนเรียบง่าย เป็นธรรมชาติ และไม่มีอะไรให้ตั้งคำถาม แต่เมื่อพิจารณาให้ลึกลงไป เราอาจพบว่ สิ่งที่ซอฟต์แวร์จำนวนมากเรียกว่า “สาขา” ไม่ใช่สิ่งเดียวกับที่กิจการยุคใหม่กำลังใช้งานอยู่จริง
Cloud เปลี่ยนสิ่งแวดล้อม
Cloud ทำให้หลายสมมติฐานเดิม “ไม่จำเป็น” อีกต่อไป
ทีมไม่ต้องอยู่ที่เดียวกัน
การควบคุมไม่ต้องอยู่ที่สถานที่
หลักฐานไม่ต้องเป็นวัตถุทางกายภาพ
การตรวจสอบไม่ต้องรอรอบเวลา
กิจการขนาดเล็กในวันนี้
เพิ่มจุดให้บริการได้โดยไม่ต้องลงทุนสูง
กระจายการทำงานตามบริบทจริง
เติบโตแบบทดลอง ไม่ใช่ขยายโครงสร้างใหญ่ทีเดียว
แต่ซอฟต์แวร์จำนวนมากยังพูดกับกิจการเหล่านี้ว่า
ถ้าคุณมีหลายสาขา ระบบจะซับซ้อนขึ้นโดยอัตโนมัติ
ทั้งที่ในเชิงเทคโนโลยี ความซับซ้อนนั้นอาจไม่จำเป็นต้องเพิ่มเลย
สาขาในกฏหมาย
คือ ความชัดเจนที่จำเป็น
..ในมุมของกฏหมาย สาขาคือสถานที่ประกอบการ เป็นจุดที่ผูกกับที่ตั้งทางกายภาพ อำนาจหน้าที่บางประการ ความรับผิดเชิงภาษีและการตรวจสอบ
กรอบนี้มีเหตุผลในบริบทของยุคที่ การทำงานต้องอยู่ ณ สถานที่เดียวกัน เอกสารเป็นกระดาษ การตรวจสอบต้อง “เดินทางไปดูของจริง”
และจนถึงวันนี้ กรอบนี้ก็ยังจำเป็น เพราะรัฐต้องการความชัดเจน ไม่ใช่ความยืดหยุ่น
เมื่อซอฟต์แวร์เลือกทางที่ปลอดภัยที่สุด
เมื่อผู้ออกแบบระบบต้องแปลงข้อกำหนดทางกฏหมายให้เป็นซอฟต์แวร์ ทางเลือกที่ปลอดภัยที่สุดคือ
ถอดแบบกรอบกฏหมายนั้นมาเป็นโครงสร้างของระบบ
ผลที่ตามมาคือ สาขา กลายเป็น entity ทางข้อมูล entity หมายถึง ขอบเขตของธุรกรรม ขอบเขตนั้น คือ ข้อจำกัดของการออกแบบ
นี่ไม่ใช่ความผิด แต่คือ ต้นทุนของความถูกต้อง
อย่างไรก็ตาม ปัญหาเริ่มเกิดขึ้นเมื่อกรอบนี้ ถูกใช้ต่อเนื่องยาวนานจนกลายเป็น “สามัญสำนึกของซอฟต์แวร์”
ซอฟต์แวร์ตีความกฏหมายแทนผู้ใช้
กฏหมายโดยทั่วไป ระบุ “สิ่งที่ต้องพิสูจน์ได้” ระบุ “ความรับผิด” ไม่ได้ระบุ “ต้องจัดระบบภายในอย่างไร”
แต่ซอฟต์แวร์จำนวนมาก แปลงข้อกำหนดเป็นโครงสร้างตายตัว ผูกวิธีทำงานเข้ากับรูปแบบเดียว ลดความเสี่ยงด้วยการลดทางเลือก
ผลลัพธ์คือ
ซอฟต์แวร์ไม่ได้แค่รองรับกฏหมาย แต่กำหนดรูปแบบองค์กรล่วงหน้า
โดยเฉพาะกับกิจการขนาดเล็ก–กลาง ที่ไม่ได้มีทรัพยากรจะ “ปรับองค์กรให้เข้ากับระบบ”
คำถามที่ Cloud ERP ควรถามตัวเอง
บทความนี้ไม่ได้เสนอให้ “เลิกใช้แนวคิดสาขา” แต่ชวนตั้งคำถามที่สำคัญกว่า
เราจำเป็นต้องผูกสาขาเข้ากับสถานที่เสมอไปหรือไม่ สาขาเป็นหน่วยของความรับผิด หรือหน่วยของการทำงาน สิ่งที่กฏหมายต้องการคือโครงสร้าง หรือคือผลลัพธ์ที่ตรวจสอบได้
ถ้า Cloud ERP เชื่อว่า transaction คือความจริง event คือหลักฐาน audit trail คือความน่าเชื่อถือ
บางที “สาขา” อาจควรถูกลดบทบาท จากแกนกลางของระบบ เหลือเพียงหนึ่งในหลายมิติของการจัดการ
จาก “ข้อจำกัด” สู่ “design choice”
ความแตกต่างสำคัญ ไม่ใช่ระบบรองรับหลายสาขาหรือไม่
แต่คือ ระบบเปิดโอกาสให้ผู้ออกแบบองค์กร นิยาม “สาขา” ในแบบที่เหมาะกับตนเองหรือไม่
ในโลกของคลาวด์ ความซับซ้อนควรเกิดจากธุรกิจ ไม่ใช่จากสมมติฐานของระบบ
และนั่นอาจเป็นความท้าทายที่แท้จริงของ Cloud ERP รุ่นถัดไป
..ไม่ใช่เรื่องเทคโนโลยี แต่คือการกล้าทบทวนกรอบความคิดที่สืบทอดกันมาอย่างยาวนาน
ความคิดเห็น