ERP อาจไม่ได้อยู่ในองค์กรอีกต่อไป

Sathit Jittanupat

12 ก.ย.

ยาว 2 นาที

ช่วงหลังผมมีโอกาสฟังหัวหน้าคุยกับลูกค้าหลายราย

สิ่งหนึ่งที่เริ่มเห็นคล้าย ๆ กันคือ ธุรกิจไม่ได้ทำงานอยู่ในระบบเดียวอีกต่อไป

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

ตอนแรกผมก็คิดเพียงว่า

นี่คงเป็นเรื่องธรรมดาของ Cloud ERP

ระบบหนึ่งทำเรื่องหนึ่ง อีกระบบทำอีกเรื่องหนึ่ง แล้วก็เชื่อม API หากัน

แต่มีคำถามหนึ่งจากหัวหน้าที่ทำให้ผมต้องหยุดคิดนานกว่านั้น

“ถ้าไม่ Post GL ล่ะ?”

ERP ที่เราทำอยู่มีคุณสมบัติอย่างหนึ่งที่ในอดีตเราถือว่าเป็นจุดแข็งมาก

เมื่อเกิดรายการทางธุรกิจ ระบบสามารถสร้างรายการบัญชีและ Post GL ให้อัตโนมัติ

ขายของก็ได้บัญชี

ซื้อของก็ได้บัญชี

รับเงิน จ่ายเงิน ก็ไหลต่อไปยังบัญชี

แนวคิดนี้ฟังดูสมเหตุสมผลมาก เพราะเราอยากให้ ERP เป็นระบบที่ทำงานตั้งแต่ต้นจนจบ

แต่วันหนึ่งหัวหน้ากลับถามว่า

“ถ้าเราไม่ Post GL เลยล่ะ? ให้ ERP สร้างข้อมูลทางบัญชีออกมาเป็นชุดหนึ่ง แล้วส่งให้สำนักงานบัญชีไปทำต่อได้ไหม?”

ผมคิดว่าคำถามนี้น่าสนใจกว่าคำถามว่า “ทำ API ได้หรือไม่” มาก

เพราะในทางเทคนิค เราทำได้อยู่แล้ว

คำถามจริง ๆ คือ

ทำไมเราถึงคิดว่าต้องทำงานเดียวกันอยู่ในฐานข้อมูลเดียวกันด้วย?

สมมติว่า ERP บันทึกว่าเกิดการขายขึ้น

ERP ก็อาจสร้าง accounting representation ของรายการนั้นออกมา

แล้วส่งต่อให้สำนักงานบัญชี

จากจุดนั้น สำนักงานบัญชีก็มีชุดข้อมูลทางบัญชีของตัวเอง

เขาอาจปรับปรุง แก้ไข หรือจัดการรายการนั้นตามวิธีทำงานของเขา

ERP เองก็ยังมีข้อมูลธุรกิจของตัวเอง

สองฝั่งไม่จำเป็นต้อง Sync กันตลอดเวลา

สิ่งที่จำเป็นอาจเป็นเพียงว่า

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

จากเดิมที่เราคิดเรื่อง Integration เป็นการทำให้สองระบบมีข้อมูลสอดคล้องกันตลอดเวลา

เราอาจกำลังมองอีกแบบหนึ่งว่า

บางครั้ง สิ่งที่สองระบบต้องการไม่ใช่การ Sync แต่คือ Reference

และพอคิดแบบนี้ ผมรู้สึกว่าเรื่องมันเริ่มใหญ่กว่าการออกแบบ GL แล้ว

คนทำบัญชีจำเป็นต้องเป็น “คนในบริษัท” หรือ?

โดยธรรมชาติแล้ว ERP มักเริ่มต้นจากภาพขององค์กร

บริษัทมีฝ่ายขาย

มีฝ่ายจัดซื้อ

มีคลังสินค้า

มีฝ่ายบัญชี

มีผู้บริหาร

แต่ละคนเป็นพนักงานของบริษัท และเราก็สร้างระบบสิทธิ์ขึ้นมารองรับโครงสร้างแบบนั้น

Company → Department → Employee → Permission → Transaction

มันดูเป็นธรรมชาติมาก

เพราะ ERP ในยุคแรก ๆ ถูกสร้างขึ้นเพื่อบริหาร “Enterprise”

แต่ลองกลับมาดูธุรกิจ SME ที่เราเจอกันจริง ๆ

บริษัทจำนวนมากไม่ได้มีฝ่ายบัญชีเต็มรูปแบบ

บางแห่งมีพนักงานบัญชีคนเดียว

บางแห่งมีคนทำบัญชี แต่ให้สำนักงานบัญชีเป็นคนปิดงบ

บางแห่งแทบไม่มีฝ่ายบัญชีเลย

เหตุผลหนึ่งที่ต้องมีระบบบัญชี

อาจไม่ใช่เพราะเจ้าของอยากได้ Financial Dashboard ที่ซับซ้อน

แต่เพราะธุรกิจมีหน้าที่ต้องยื่นภาษี ต้องมีงบการเงิน

และต้องส่งข้อมูลให้คนทำบัญชีทำงานต่อ

ในกรณีแบบนี้

สำนักงานบัญชีไม่ได้เป็น “ผู้ใช้ภายนอก” ที่เราเปิดสิทธิ์ให้เข้ามาใน ERP

เขากำลังทำงานบางส่วนของธุรกิจให้เรา

ผมว่าความแตกต่างระหว่างสองประโยคนี้สำคัญทีเดียว

เพราะถ้าเราคิดว่าเขาเป็น External User

เราก็จะถามว่า

จะให้เขาเข้าถึงข้อมูลอะไรได้บ้าง?

แต่ถ้าเราคิดว่าเขาเป็น Party ที่มี Role ในกระบวนการทำงาน

คำถามอาจกลายเป็น

งานอะไรที่เขารับผิดชอบ และหลักฐานอะไรที่เขาต้องใช้ในการทำงานนั้น?

มันเป็นคำถามคนละแบบกัน

จาก Organization Boundary สู่ Work Boundary

ลองคิดต่อไปอีกนิด

คนทำบัญชีอาจไม่ได้เป็นพนักงานของบริษัท

บริษัทรับจ้างทำการตลาดก็ไม่ได้เป็นพนักงาน

บริษัทขนส่งก็ไม่ได้เป็นพนักงาน

ตัวแทนขายก็ไม่ได้เป็นพนักงาน

แต่คนเหล่านี้ล้วนเข้ามาอยู่ในกระบวนการทางธุรกิจ

บางคนทำงานก่อนที่รายการจะเข้ามาใน ERP

บางคนทำงานหลังจากรายการเกิดขึ้นแล้ว

บางคนสร้างข้อมูล

บางคนตรวจสอบ

บางคนแปลงข้อมูลไปเป็นรูปแบบอื่น

บางคนรับช่วงต่อ

ถ้าอย่างนั้น boundary ที่น่าสนใจของระบบ อาจไม่ใช่

“ใครอยู่ในบริษัท?”

แต่อาจเป็น

“ใครกำลังทำงานอะไรที่เกี่ยวข้องกับธุรกิจ?”

จากเดิมที่เรามอง

Organization → Department → Employee

เราอาจต้องเริ่มมองเป็น

Party → Relationship → Role → Work → Evidence

ผมไม่ได้หมายความว่านี่จะต้องเป็น architecture ใหม่ของ ERP ในทันที

เพียงแต่เมื่อผมลองใช้กรอบนี้มองปัญหาเดิม หลายอย่างกลับดูง่ายขึ้น

สำนักงานบัญชีไม่ต้องถูกยัดให้กลายเป็น “พนักงาน”

ระบบการตลาดไม่ต้องกลายเป็น “Module ของ ERP”

ผู้ให้บริการขนส่งไม่ต้องกลายเป็น “Sub-system ของ ERP”

แต่ละฝ่ายสามารถมีระบบของตัวเอง และรับผิดชอบงานของตัวเอง

สิ่งที่ต้องเชื่อมกัน อาจไม่ใช่ทุกอย่าง

อาจเป็นเพียงข้อมูลที่จำเป็นต่อการทำงาน

และหลักฐานที่ทำให้เราย้อนกลับไปหาต้นทางได้

ผมนึกถึง Marketplace

พอคิดมาถึงตรงนี้ ผมกลับนึกถึงระบบอย่าง Marketplace

Marketplace ไม่ได้ทำให้ร้านค้าทั้งหมดกลายเป็นพนักงานของ Marketplace

ร้านค้าเป็นของร้านค้าเอง

ลูกค้าเป็นของลูกค้าเอง

ผู้ให้บริการขนส่งก็เป็นอีกฝ่ายหนึ่ง

แต่ระบบสามารถรู้ได้ว่า

ใครเป็นใคร

กำลังทำธุรกรรมกับใคร

อยู่ในบทบาทอะไร

และเหตุการณ์ที่เกิดขึ้นในแต่ละช่วงเกี่ยวข้องกันอย่างไร

บางทีสิ่งที่ Cloud ทำให้เกิดขึ้น ไม่ใช่แค่การเอา ERP ขึ้นไปอยู่บน Internet

แต่อาจเป็นการทำให้ต้นทุนของการ “ประสานงานระหว่างคนที่ไม่ได้อยู่ในองค์กรเดียวกัน” ต่ำลงมาก

และเมื่อการประสานงานทำได้ง่ายขึ้น

คำถามเรื่อง boundary ก็อาจเปลี่ยนไปด้วย

แล้ว ERP อยู่ตรงไหน?

ผมเริ่มต้นเรื่องนี้จากคำถามง่าย ๆ ว่า

“ถ้า ERP ไม่ต้อง Post GL แล้วให้สำนักงานบัญชีรับช่วงต่อได้ไหม?”

ตอนแรกมันดูเหมือนเป็นเพียงเรื่องของ Accounting Integration

แต่พอคิดต่อ กลับกลายเป็นคำถามว่า

ถ้าบัญชีไม่จำเป็นต้องอยู่ใน ERP ทั้งหมด

Marketing ไม่จำเป็นต้องอยู่ใน ERP ทั้งหมด

Logistics ไม่จำเป็นต้องอยู่ใน ERP ทั้งหมด

และคนที่เข้ามาทำงานกับข้อมูลของธุรกิจก็ไม่จำเป็นต้องเป็นพนักงานของบริษัท

แล้วเหตุใด ERP จึงยังต้องใช้

“องค์กร”

เป็นขอบเขตหลักของตัวเอง?

ผมยังไม่มีคำตอบสำหรับเรื่องนี้

และจริง ๆ ผมก็ไม่แน่ใจว่าควรรีบหาคำตอบหรือไม่

เพราะบางทีสิ่งที่กำลังเปลี่ยน อาจไม่ใช่เพียงเทคโนโลยีของ ERP

แต่อาจเป็นความหมายของคำว่า

“ระบบของเรา”

ในโลกที่ธุรกิจหนึ่งไม่ได้ทำงานด้วย “คนของเรา” เพียงอย่างเดียวอีกต่อไป

บางที ERP ในอนาคตอาจไม่จำเป็นต้องเป็นระบบที่ทำทุกอย่างให้บริษัท

แต่อาจเป็นระบบที่รู้ว่า

ใครกำลังทำอะไรกับธุรกิจของเรา

ข้อมูลนั้นเกิดขึ้นที่ไหน

ถูกส่งต่อไปให้ใคร

และเรายังสามารถย้อนกลับไปหาหลักฐานของมันได้อย่างไร

หรือบางทีผมอาจกำลังคิดไกลเกินไปอีกแล้วก็ได้

แต่สำหรับคนทำ ERP อย่างผม

คำถามหนึ่งที่น่าจะลองถามตัวเองดูสักครั้งก็คือ

เรากำลังสร้าง ERP เพื่อบริหาร “องค์กร” หรือกำลังสร้างระบบเพื่อให้ “ธุรกิจ” สามารถทำงานได้?

สองอย่างนี้อาจเคยเป็นสิ่งเดียวกัน

แต่ไม่แน่ว่าในโลก Cloud มันอาจไม่ใช่สิ่งเดียวกันอีกต่อไป