Stock Tail, The Hi-Res Stock Control

บ้านที่อยู่มานานมักมีอาถรรพ์ หลายครั้งที่ต้องหาของอะไรสักอย่างที่นาน ๆ ใช้ มักจะหาไม่เจอ วันดีคืนดีไม่ตั้งใจหากลับเจอมันซุกอยู่ตรงนั้นแหละ

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

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

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

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

งานบัญชีต้องการบัญชีคุมสินค้าในระดับของ product code ตัวเลขสินค้าคงเหลือและมูลค่าต้นทุน ในภาพใหญ่เพื่อใช้สรุปเป็นงบการเงิน

ขณะที่งานซื้อขายและจัดส่งสินค้าต้องประสานกับคลังสินค้า ต้องรู้ lot number หรือ วันหมดอายุ (expire date) ด้วย

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

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

เมื่อเจอเหตุการณ์ไม่คาดฝันเช่น สินค้าชำรุดหรือเสียหาย จำนวนเหลือจริงไม่พอ ก็ต้องแก้ปัญหาเฉพาะหน้า เหล่านี้มีโอกาสทำให้สินค้าที่หยิบไม่ตรงกับ lot ที่สั่งเบิก

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

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

ในการออกแบบระบบให้ใช้งานจริง หางที่ต่อท้ายชื่อสินค้าคือ batch number, expire date และอะไรที่จำเป็นสำหรับคลังสินค้า ที่ต้องการระบุเพื่อใช้บริหารบัญชีคุมสินค้าในคลัง

ความพิเศษจึงอยู่ที่โปรแกรมสามารถออกรายงานเกี่ยวสินค้าได้ 2 ระดับ สินค้ารวมหางสำหรับคลังสินค้า และสินค้าที่ตัดหางออกสำหรับบัญชี ดังนั้นความคลาดเคลื่อนเมื่อซูมละเอียดระดับแยก lot จะไม่มีผลกระทบเมื่อเอามารวมกันเป็น transaction ที่ความละเอียดระดับสินค้าปกติไม่สนใจ lot

ตัวอย่าง สต็อคคลัง "สินค้า ABC" แยกคุมเป็น 2 lot

02/08/66 สินค้า ABC #[batch 1010][expire 30/06/67] | รับเข้า +100
 
04/08/66 สินค้า ABC #[batch 1010][expire 30/06/67] | เบิกออก (-40) | คงเหลือ 60

16/09/66 สินค้า ABC #[batch 1010][expire 30/06/67] | เบิกออก (-60) | คงเหลือ 0

15/09/66 สินค้า ABC #[batch 1020][expire 10/08/67] | รับเข้า +100

17/09/66 สินค้า ABC #[batch 1020][expire 10/08/67] | เบิกออก (-50) | คงเหลือ 50

ขณะที่สต็อคบัญชี เป็นรายการเคลื่อนไหวรวมของ "สินค้า ABC"

02/08/66 สินค้า ABC | รับเข้า +100 
04/08/66 สินค้า ABC | เบิกออก (-40) | คงเหลือ 60
15/09/66 สินค้า ABC | รับเข้า +100 | คงเหลือ 160
16/09/66 สินค้า ABC | เบิกออก (-60) | คงเหลือ 100
17/09/66 สินค้า ABC | เบิกออก (-50) | คงเหลือ 50

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

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

ผมเคยตั้งคำถามขึ้นมาเล่น ๆ "อะไรคือต้นทุนที่ถูกต้องของสินค้า" สำหรับนักบัญชีมักจะคิดถึง FIFO LIFO เฉลี่ย หรือซับซ้อนไปจนถึง ABC (Activity Based Costing) ในความจริงแล้วคำว่าถูกต้องเองก็ต้องถามต่อไปว่า "สำหรับใคร" ถ้าสำหรับงานบัญชีปิดงบ ก็จะมีสองมิติ เพื่อยื่นภาษีกับเพื่อสะท้อนสถานะทางการเงิน ส่วนใหญ่แล้วมักจะพยายามเลือกวิธีคำนวณเดียวกันเพื่อบรรลุวัตถุประสงค์ทั้งสองด้าน

หากเจอกับผู้บริหารที่เก่งต้นทุนกลยุทธ อาจได้เห็นงบการเงินที่ขาดทุนทางบัญชี แต่บริษัทเติบโตได้

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