ไม่กี่วันมานี้มีข้อความจากผู้ใช้ แจ้งผลกระทบจากความผิดพลาดของการคำนวณยอดสต็อคในโปรแกรม
"ตอนนี้เริ่มพบปัญหากับลูกค้าแล้วนะคะ เสนอราคาไป พอลูกค้า PO มาของไม่พอส่งค่ะ"
ในที่สุดของเราก็มาถึงจุดนี้
ดูเหมือนว่าผู้ใช้จะเพิ่มความไว้วางใจกับระบบคำนวณสต็อคแบบ real time ไม่ตรวจทานกับของจริง กรณีที่ยอดต้องการนั้นหมิ่นเหม่ใกล้เคียงกับยอดคงเหลือ ซึ่งเป็นสิ่งที่ควรและเคยกระทำทุกครั้งก่อนหน้านั้น เมื่อไว้ใจมากขึ้น จึงหวังพึ่งพาความแม่นยำของระบบมากขึ้นตาม
ยูวัล โนอาห์ แฮรารี เคยเล่าไว้ในโฮโมดิอุส จากระบบแผนที่จราจรกลายเป็นระบบนำทาง เริ่มจากบทบาทให้ข้อมูล แต่หัวใจสำคัญอยู่ที่ระดับของความไว้วางใจที่เปลี่ยนไป
...ในตอนแรกดูเหมือนว่าอัลกอริทึมของเวซทำหน้าที่เป็นแค่ผู้พยากรณ์ คุณถามคำถาม ผู้พยากรณ์ตอบ แต่มันขึ้นกับคุณที่ต้องตัดสินใจเอง อย่างไรก็ดี ถ้าผู้พยากรณ์เอาชนะความไว้วางใจของคุณ ตรรกะลำดับถัดไปคือการปรับขึ้นเป็นตัวแทน
สำหรับโปรแกมบัญชี หรือ ERP ที่ใช้งานกันทั่วไป หากมีใครสักคนถามผมว่าเราสามารถเชื่อถือการคำนวณสต็อคได้เพียงใด? คำตอบคือ ประมาณ 70–80 เปอร์เซนต์ ขึ้นอยู่กับขนาดขององค์กร จำนวนผู้ใช้ ปริมาณงาน และปัจจัยอื่นๆ เหมือนกับที่เราไม่สามารถวางใจว่าจะไม่เกิดอุบัติเหตุบนถนนที่มีรถวิ่งผ่านขวักไขว่ทุกวัน
อาจจะมีวันที่สินค้าบางตัวขายดีมากจนแย่งกันขาย สมมติว่าพนักงานสองคนกำลังรับออเดอร์จากลูกค้าในเวลาไล่เลี่ยกัน ตอนที่เช็คยอดสต็อคจากโปรแกรมแต่ละคนก็เห็นเหมือนกันว่ายังมีเหลืออยู่
หากไม่มีระบบเช็คสต็อคที่แม่นยำ ณ วินาทีก่อนยืนยันออเดอร์ ก็จะมีโอกาสหลุดรอดไปถึงขั้นตอนเบิกสินค้าจึงพบว่าเหลือไม่พอ
เมื่อปัญหาเกิดขึ้นแล้ว ความซีเรียสอาจขึ้นอยู่กับผลที่ตามมา ปฏิกิริยาของลูกค้าหรือผู้เกี่ยวข้อง หากทำให้เกิดความเสียหายใหญ่โตก็กลายเป็นเรื่องสำคัญ เหมือนกับเวลาที่ไฟฟ้าดับ อินเตอร์เน็ตใช้ไม่ได้ ผลลัพธ์ของมันอาจจะแค่ "ไม่เป็นไร" หรือ "_ิบหายแล้ว" ก็ได้
หากถามว่าแล้วทำไมไม่ออกแบบให้โปรแกรมตรวจเช็คก่อนบันทึกออเดอร์ แล้วแจ้งเตือนขึ้นมา หรือไม่ยอมให้รับออเดอร์ที่ช้ากว่า
คงต้องย้อนกลับไปว่า องค์กรนั้นมีการจัดการสต็อคจริงแม่นยำสอดคล้องกับโปรแกรมเพียงใด มิฉะนั้นจะกลายเป็นสัญญาณกันขโมยที่ดังพร่ำเพรื่อเชื่อถือไม่ได้ เช่น สินค้าจริงยังมีอยู่ แต่โปรแกรมฟ้องว่าหมดไม่ยอมให้รับออเดอร์
หากสต็อคไม่พอขายแล้วระบบไม่ยอมรับออเดอร์ อาจนำไปสู่ปัญหาการจัดการที่ซับซ้อนใหม่ เรายินยอมให้แก้ไขหรือยกเลิกออเดอร์ภายหลังได้หรือไม่ หรือควรมีระบบคิวสามารถบันทึกออเดอร์ที่รอยืนยัน การพิจารณาว่าออเดอร์ไหนควรได้รับการจัดสรรก่อน เป็นตามลำดับหรือมีข้อยกเว้นสำหรับลูกค้าชั้นดีหรือไม่ อืม.. แล้วลูกค้าชั้นดี พิจารณาจากอะไร
โชคร้ายไปกว่านั้น บางทีในช่วงปิดงบของฝ่ายบัญชี อะไรก็เกิดขึ้นได้ในวันที่ทีมขายกำลังรับออเดอร์ ขณะที่ฝ่ายบัญชีกำลังตรวจปรับปรุงรายการบันทึกสต็อคย้อนหลังเมื่อสองเดือนที่แล้ว
ตัดสต็อคควรเกิดขึ้นเมื่อใด
หากยึดถือตามหลักบัญชีก็ควรเกิดเมื่อจัดทำใบส่งสินค้าหรือใบกำกับภาษี แต่ในทางปฏิบัติควรถูกล็อคยอดหรือตัดออกตั้งแต่มีการยืนยันออเดอร์ป้องกันไม่ให้เกิดการขายซ้ำซ้อน
ดังนั้นนิยามแรกที่เราควรเข้าใจตรงกัน
ยอดสต็อคทางบัญชีไม่จำเป็นต้องเท่ากับยอดสต็อคพร้อมขาย
รับสินค้าไม่ตรงกับเอกสารทำยังไงดี
หากสั่งซื้อสินค้าไป 500 ชิ้น เมื่อได้รับจริงพบว่าขาดหายไปหรือมีสินค้าชำรุด 50 ชิ้น คุณจะทำอย่างไร
ไม่รับสินค้าทั้งล็อตได้ไหม เพราะเป็นความผิดพลาดของผู้ขาย จะดูเป็นการไร้น้ำใจต่อคู่ค้าเกินไปไหม ไหนจะมีต้นทุนในการขนส่ง เสียเวลา เสียโอกาสเราเองที่จะขายสินค้านั้นหรือไม่
หรืออาจรับสินค้านั้นไว้ก่อน ทำหลักฐานแจ้งให้ผู้ขายรับทราบ ให้ดำเนินการแก้ไขเอกสาร หรือชดเชยส่วนที่ผิดพลาดภายหลัง
ในกรณีหลังหากยึดถือตามหลักบัญชี หากรอแก้ไขเอกสารก็ยังไม่สามารถบันทึกข้อมูลจนกว่าจะได้รับเอกสารที่ถูกต้อง กลายเป็นว่าสต็อคยังไม่เข้า ไม่ถูกรับรู้ทางบัญชี ทั้งที่สินค้าจริงรอเบิกเอาไปขายได้แล้ว
หรือถ้าไม่รอแก้ไขเอกสาร แต่ทางผู้ขายจะออกใบลดหนี้หักคืนสินค้าให้ หรือส่งสินค้าเพิ่มเติมส่วนที่ขาดหรือชำรุดให้ ประเด็นอยู่ที่ "เมื่อไหร่" ระหว่างที่เรื่องยังไม่จบเราจะทำอย่างไร?
หากคิดตามหลักบัญชีก็ต้องยึดตามเอกสารใช้ตัวเลข 500 ชิ้นเข้าสต็อคไปก่อน เพราะมีมิติของการเงินบัญชีเจ้าหนี้ที่ต้องสอดคล้องกับการคำนวณต้นทุนสินค้า ทำให้เกิดช่วงเวลาที่สต็อคจริงไม่ตรงกับในโปรแกรม จนกว่าจะทางผู้ขายจะดำเนินการแก้ไขให้เรียบร้อย
มีช่วงเหลื่อมเวลาที่ยอดสต็อคทางบัญชีไม่เท่ากับยอดสต็อคที่มีอยู่จริง
ขายสินค้าไม่มีสต็อคได้หรือไม่
สินค้านำเข้าต้องใช้เวลาในการขนส่ง สินค้าที่สั่งผลิตอาจใช้เวลาหรือมีรอบผลิต ถึงแม้ยังไม่ได้เข้าสต็อค แต่ก็รู้กำหนดเวลาหรือประเมินเวลาได้
บางครั้งลูกค้าอาจสั่งซื้อสินค้าล่วงหน้า หรือกำหนดระยะเวลาให้ทะยอยส่งมอบสินค้า
สินค้าที่ไม่มีอยู่จริง ยังไม่มีในสต็อคตอนนี้ สามารถขายได้หรือไม่
ในทางปฏิบัติกระบวนการขายโดยเฉพาะเมื่อผนวกเข้ากับการตลาดใช้จินตนาการมีความยืดหยุ่นกว่าที่คิดแบบตรงไปตรงมา ไม่จำเป็นต้องยึดถือตามสต็อคที่มีในปัจจุบัน ธุรกิจหลายแห่งที่มีระบบ Supply Chain ที่ดี จึงมีกลไกจองสินค้า รับคำสั่งซื้อล่วงหน้า กลไกค้างรับ ค้างส่ง เมื่อผู้ซื้อและผู้ขายยอมรับเงื่อนไขหรือตกลงระยะเวลาในการส่งมอบได้
สต็อคที่พร้อมขายได้ทันที ไม่เท่ากับ สต็อคที่ขายได้ในอนาคต
สต็อคคงเหลือที่ขายไม่ได้
แว่นตาที่ใช้มองสต็อคทางบัญชีจับจ้องไปที่ "สิทธิครอบครอง" ไม่ใช่สิ่งที่อยู่จริงในโกดัง ตัวเลขสต็อคคงเหลือคือสินค้าที่มีคุณสมบัติเป็นทรัพย์สินของเรา หากมีอะไรไม่ถูกต้อง สำหรับนักบัญชียังมีเวลาเหลือเฟือที่จะพิจารณาปรับปรุงรับรู้ภายหลังตอนปิดบัญชี
หากสวมแว่นตาของทีมขาย ต้องการรู้ว่าตอนนี้เหลือยอดเท่าไหร่กันแน่ มีสินค้าบางประเภทที่มีตัวเลขอยู่ในสต็อค แต่ของจริงอยู่ในสภาพไม่สามารถขายได้ เช่น สินค้าชำรุด หรือตัวสินค้าจริงไม่ได้เก็บอยู่ในโกดัง ไม่สามารถหยิบไปขาย เช่น สินค้าตัวอย่างที่ให้ลูกค้ายืมเอาไปโชว์
สต็อคที่ขายได้ไม่จำเป็นต้องยึดถือตามยอดทางบัญชีและยอดจริง ณ ปัจจุบัน
Information System
เมื่อระบบสต็อคถูกคาดหวังให้ใช้เป็นส่วนหนึ่งของกระบวนการทำงาน เช่น เสนอราคา หรือรับออเดอร์จากลูกค้า เมื่อนั้นระบบสต็อคจะไม่เป็นเรื่องสามัญที่เป็นผลพลอยได้จากงานบัญชี แต่ต้องมีการออกแบบที่ละเอียดมากกว่างานบัญชี ไม่ใช่แค่เป้าหมายการคุมยอดคงเหลือสินค้าคงคลัง แต่เพื่อติดตามความเปลี่ยนแปลง
เราต้องการกลไกรับรู้สถานะย่อยของสินค้าแต่ละตัว เพื่อประกอบเป็นตัวเลขใช้งานวัตถุประสงค์อื่น
สำหรับงานขาย ต้องการรู้จำนวนสินค้าที่สามารถยืนยันกับลูกค้าว่า "พร้อมส่ง" หมายถึง ยอดคงเหลือในสต็อค ไม่รวมยอดที่ขายไม่ได้ แต่อาจรวมตัวเลขคาดการณ์สินค้าที่จะเข้ามาเพิ่มในสัปดาห์หน้าหรือสิ้นเดือนนี้
ยอดที่ขายไม่ได้ อาจหมายถึง ยอดค้างส่งที่ยืนยันออเดอร์แล้วแต่ยังไม่ได้ดำเนินการจัดส่ง ยอดสินค้าชำรุด ฯลฯ ระบบที่ดีจึงต้องออกแบบให้สามารถรับรู้ยอดเหล่านี้ได้
สำหรับงานซื้อ อาจต้องการรู้ยอดสั่งล่วงหน้า บวกยอด "พร้อมส่ง" ของฝ่ายขาย ร่วมกับเงื่อนไขของผู้ขายหรือผู้ผลิต เพื่อคาดการณ์ยอดที่เหมาะสม
Real Time
เพื่อตอบสนองความคาดหวังว่าจะไม่เกิดเหตุการณ์ "พอลูกค้า PO มาของไม่พอส่ง" ระบบนั้นต้องเป็นกลไกแบบ real time หรือพยายามทำให้ใกล้เคียงที่สุด
เป็นการเปลี่ยนพฤติกรรมจากเชื่อสิ่งที่เห็น (สต็อคจริง) มาเป็นเชื่อข้อมูลมากกว่า
ระบบนำทางจราจร อาศัยข้อมูลปัจจุบันของรถทุกคนมาประกอบรวมกัน สมมติว่ามีรถหลายคันหน่วงเวลาส่งข้อมูลช้ากว่าปัจจุบัน 10–20 นาที คุณคิดว่าระบบแผนที่นั้นจะใช้ประโยชน์ได้หรือไม่
หากมีใครสักคนตรวจรับสินค้า แล้วเก็บเอกสารไว้รอเอาไปบันทึกเข้าระบบวันรุ่งขึ้น หรือหยิบสินค้าไปก่อน แล้วเพิ่งนึกได้จึงบันทึกเบิกภายหลัง
แน่นอนว่าอาจมีโอกาสเพียง 1% ที่จะลุกลามกลายเป็นปัญหาใหญ่ แต่การให้ความสำคัญของข้อมูลไม่เท่ากันของผู้เกี่ยวข้อง เป็นดัชนีที่บอกว่าเรายังไม่พร้อมสำหรับระบบสต็อค
กระบวนการทำงานหลายอย่างที่เคยออกแบบตามวิถีบัญชี จะต้องกลับตาลปัตรไปเลย ระบบที่เป็น real time ได้จะต้องมีความเป็น automation สูง เพื่อลดความผิดพลาดจากการเหลื่อมเวลาในการรับรู้ ให้ความสำคัญกับลำดับเหตุการณ์ที่เกิดขึ้นและบันทึกข้อเท็จจริงตามเวลาจริง
กระบวนการบันทึกบัญชี กลายเป็นงานพิสูจน์ว่าข้อเท็จจริงนั้นสอดคล้องกับหลักฐานเอกสารหรือไม่ หากไม่ตรงกันก็ต้องมีวิธีแยกทดไว้ทางบัญชี ในองค์กรใหญ่อาจมีทั้งในระดับบัญชีภายในสำหรับผู้ถือหุ้นกับบัญชีภายนอกตามกฎหมาย (บวกกลับ) โดยไม่ทำให้ข้อเท็จจริงที่ใช้ในกระบวนการทำงานปั่นป่วน
บางทีความคุ้มค่าในการปรับเปลี่ยนก็เป็นปัจจัยสำคัญที่ต้องพิจารณาควบคู่กัน หากต้องการระบบสต็อคที่ดีตามคาดหวังจะต้องแลกกับอะไรบ้าง หรือว่าจริงแล้วแค่ระบบที่แค่ดีพอ โดยเราเข้าใจข้อจำกัดของมัน ไม่จำเป็นต้องดีที่สุด
Comentários