คุยกับ AI: “วางบิล” เงื่อนไขโกลาหล
- Sathit Jittanupat
- 14 ก.พ.
- ยาว 1 นาที
วางบิล: จากปัญหาหน้างาน สู่คำถามที่ระบบไม่อยากตอบ
ผมเริ่มต้นบทสนทนานี้เหมือนคนทำงานระบบทั่วไป มีข้อมูลจริงอยู่ในมือ และมีคำถามเชิงเทคนิคอยู่ในหัว
ผมส่งรายการ “เงื่อนไขการวางบิล” ที่รวบรวมมาจากลูกค้าของกิจการแห่งหนึ่งให้ AI ดู เป็นข้อความที่ใครอยู่สายบัญชีจะอ่านแล้วเข้าใจทันที และใครอยู่สายระบบจะอ่านแล้วเริ่มปวดหัว
วางบิลทุกวันที่ 5 ของเดือน (ตรงวันหยุดเลื่อน) วางบิล 1–3 ของเดือน วางบิล 2 วันสุดท้าย วางบิล 15 และ 30 วางบิลเฉพาะ จ–ศ เวลา 08.30–17.00 วางบิลพร้อม PO ต้นฉบับ + ใบเสร็จ วางบิลทางอีเมล ตามฟอร์มลูกค้า วางบิลในระบบลูกค้าเท่านั้น วางบิลที่สำนักงานใหญ่เท่านั้น วางบิลพร้อมส่งของ วางบิลแยกครึ่งเดือน …
ผมถาม AI ว่า
“ถ้าจะออกแบบระบบ เราควรจัดการเงื่อนไขพวกนี้อย่างไรดี?”
ผมคาดหวังคำตอบแบบสถาปัตยกรรม แต่คำตอบที่ได้ กลับพาผมออกนอกกรอบนั้นทันที
AI บอกว่าสิ่งที่ผมเรียกรวม ๆ ว่า “เงื่อนไขวางบิล” จริง ๆ แล้วไม่ใช่ชุดกติกาประเภทเดียวกันเลย
บางข้อคือเรื่อง “เวลา” บางข้อคือเรื่อง “ช่องทาง” บางข้อคือเรื่อง “สถานที่” บางข้อคือเรื่อง “เอกสาร” และบางข้อ… ไม่ใช่เงื่อนไขทางระบบด้วยซ้ำ
มันคือคำสั่ง
คำสั่งที่ไม่ได้ออกแบบมาเพื่อให้ระบบเข้าใจ แต่เพื่อให้ “อีกฝ่ายหนึ่ง” ทำตาม
ตรงนั้นเองที่ผมเริ่มรู้สึกว่า ปัญหาที่เราพยายามแก้ อาจไม่ใช่ปัญหาทางเทคนิค
ผมลองเปลี่ยนมุมถามต่อว่า ถ้าใช้มาตรฐานอย่าง RRULE หรือ rule engine ทั่วไป อะไรแปลงได้ อะไรแปลงไม่ได้
AI ตอบค่อนข้างตรงไปตรงมา
กติกาเชิงเวลา → แปลงได้
กติกาที่มีเงื่อนไขวันหยุด → แปลงได้บางส่วน
กติกาที่ผูกกับเอกสาร / สถานที่ / วิธีการ → ต้อง extend
กติกาที่บอกว่า “ต้องทำแบบนี้เท่านั้น” → ไม่ใช่ rule แต่เป็นอำนาจ
มันไม่ได้บอกว่าทำไม่ได้แต่มันถามกลับว่า
“คุณแน่ใจหรือ ว่าควรเอาสิ่งนี้ไปแก้ด้วยระบบ?”
คำถามนั้นติดอยู่ในหัวผมนานกว่าที่คิด
บทสนทนาเริ่มเปลี่ยนทิศ จากการออกแบบระบบ ไปสู่คำถามว่า ใคร ควรเป็นฝ่ายแบกรับความซับซ้อนนี้
ผมถามคำถามที่ผมค้างใจมานาน
“ทำไม ERP ระดับโลก อย่าง SAP, Oracle, Dynamics ถึงไม่มีโมดูลจัดการเงื่อนไขวางบิลแบบนี้?”
AI ไม่ได้อธิบายเรื่อง feature แต่มันอธิบายเรื่อง “โลกที่ระบบเหล่านั้นถูกสร้างมาให้รองรับ”
ERP เหล่านั้นถูกออกแบบมาสำหรับองค์กรที่
เป็นผู้กำหนดเงื่อนไข
ไม่ใช่ผู้ตาม
และไม่จำเป็นต้องจดจำข้อยกเว้นจำนวนมาก
ในโลกนั้น ถ้ามีคู่ค้าที่ต้องวางบิลเฉพาะวันแปลก ๆ หรือขอเอกสารรูปแบบเฉพาะ คำถามไม่ใช่ว่า “ระบบรองรับไหม”
แต่คือ
“เรายังควรทำธุรกิจกับเขาอยู่หรือเปล่า”
ผมเริ่มมองรายการเงื่อนไขวางบิลเดิม ด้วยสายตาอีกแบบหนึ่ง
มันไม่ใช่ข้อมูลสำหรับออกแบบระบบ แต่มันคือ แผนที่ของอำนาจต่อรอง
ยิ่งองค์กรใด
ต้องจำเงื่อนไขของคนอื่นจำนวนมาก
ต้องปรับตัวตามระบบของคู่ค้า
ต้องยืดหยุ่นด้านเอกสารและเวลา
ยิ่งสะท้อนว่าองค์กรนั้น ไม่ได้เป็นฝ่ายกำหนดจังหวะของเงิน
วางบิลจึงไม่ใช่เรื่องบัญชี แต่เป็นเรื่อง “ใครควบคุมเวลา”
ใครส่งของไปก่อน ใครรอเงิน ใครแบกรับความเสี่ยงระหว่างนั้น
AI ไม่ได้บอกผมว่าวางบิลเป็นเรื่องผิด แต่มันทำให้ผมเห็นว่า
วางบิลอาจเป็น “กลยุทธ์ชั่วคราว” ขององค์กรที่ยังไม่แข็งแรงด้าน cash ยังไม่มั่นคงด้าน credit และยังเข้าไม่ถึง fund
ปัญหาไม่ใช่การใช้มัน แต่คือการใช้มันนานเกินไปโดยไม่รู้ตัว
เมื่อวางบิลกลายเป็นกิจวัตร เงื่อนไขก็เริ่มซับซ้อน ข้อยกเว้นก็เริ่มกลายเป็นมาตรฐาน และระบบก็ถูกคาดหวังให้ “รับความโกลาหลแทนมนุษย์”
ผมไม่ได้คำตอบว่า ควรสร้างระบบแบบไหนมารองรับทั้งหมดนี้
แต่ผมได้คำถามใหม่ที่หนักกว่าเดิมมาก
เรากำลังออกแบบระบบ หรือเรากำลังพยายามทำให้สถานะที่เปราะบาง ดูมีเหตุผลทางเทคนิคมากขึ้น?
และบางที เหตุผลที่ ERP ระดับโลกไม่ต้องแก้ปัญหาวางบิล อาจไม่ใช่เพราะพวกเขายังคิดไม่ถึง
แต่เพราะพวกเขา.. ไม่เคยต้องอยู่ในเกมนี้ตั้งแต่แรก
ความคิดเห็น