Unit of Stock from Different Views

ข้อมูลสินค้าในระบบสต็อคเรามักใช้หลักคิดของ SKU (Stock-Keeping Unit) เป็นแกนกลาง นิยามกว้าง ๆ ของ SKU หมายถึง "สิ่งที่เหมือนกัน" สามารถนับรวมกันได้ เราจึงกำหนดใช้รหัส SKU เดียวกัน
 
แล้วนิยามของ "สิ่งที่เหมือนกัน" คืออะไรกันแน่ ในชีวิตจริงมีสิ่งของที่บางคนมองว่าเหมือนกัน แต่บางคนมองว่าแตกต่าง ขึ้นอยู่ว่าจะเลือกตัดสินจากแง่มุมไหน

นม UHT
 
ผมเติบโตมาในร้านขายของชำ ช่วยขายของ ช่วยเรียงสินค้าตั้งแต่เด็ก ได้เห็นป๋าเดินไปดูกองสินค้าที่เก็บไว้หลังร้าน ชำเลืองดูของที่อยู่หน้าร้าน แล้วสั่งสินค้ากับเซลส์ที่มารับออเดอร์ได้ เมื่อโตจึงเข้าใจภาพนั้น เจ้าของร้านเล็ก ๆ ไม่จำเป็นต้องมีระบบสต็อคที่แม่นยำ ใช้แค่ความรู้สึกผสมกับประสบการณ์
 
หากเป็นร้านใหญ่ที่มีพนักงานมาก อาจแยกหน้าที่รับผิดชอบ ผู้ขายไม่ได้สั่งซื้อ และผู้สั่งซื้อก็ไม่ได้ขาย ไม่สามารถใช้ความรู้สึกจากประสบการณ์กะเอาเอง การมีข้อมูลที่ชัดเจนประกอบการตัดสินใจจึงเป็นเรื่องสำคัญ
 
นม UHT ที่เห็นในร้านสะดวกซื้อมีทั้งแช่เย็นขายเป็นกล่องและวางขายเป็นแพ็ก ถึงแม้ว่าจะเป็นนมเหมือนกันแต่หน่วยบรรจุต่างกัน เราจะเห็นว่ามีรหัสบาร์โค้ดบนกล่องนม และบนพลาสติกหุ้มแพ็กที่ไม่เหมือนกัน จึงอนุมานได้ว่ามี SKU ตามหน่วยนับที่ขาย จึงถูกนิยามว่าเป็น "สิ่งที่ไม่เหมือนกัน" ในระบบสต็อคร้าน
 
ระบบสต็อคที่ดีของนม UHT ควรเป็นอย่างไร
 
บทบาทหน้าที่ที่แตกต่างกันทำให้ต้องการมุมมองของหน่วยนับไม่เหมือนกัน
 
หน่วยขาย
 
เพื่อขายให้ลูกค้า ย่อมคำนึงถึงหน่วยนับที่เหมาะสมสำหรับลูกค้า ดังนั้นจึงต้องออกแบบให้ขายได้ทั้งกล่องและแพ็ก(6 กล่อง)
 
หน่วยจัดเก็บ
 
เพื่อเรียงสินค้าหน้าร้าน เราสะดวกที่จะหยิบจากสต็อคหลังร้านมาเป็นแพ็กมากกว่ากล่องย่อย การเบิกและนับว่าเหลือเท่าไหร่หน่วยแพ็กน่าจะสะดวกรวดเร็วกว่าการนับกล่อง เป็นหน่วยที่อยู่ตรงกลางระหว่างกล่องที่เล็กเกินไป และลัง(6 แพ็ก) ที่ใหญ่เกินไป
 
หน่วยจัดส่ง
 
เมื่อต้องสั่งซื้อนม UHT มาเข้าร้าน หน่วยนับที่สะดวกต่อการขนส่งและตรวจรับสินค้ามักเป็นหน่วยใหญ่คือ ลัง(6 แพ็ก) ผู้ขายเองก็มักกำหนดให้สั่งซื้อเป็นลัง
 
หน่วยบัญชี
 
นอกจากนี้ยังมีงานสต็อคทางบัญชีที่ต้องคำนึงถึง มูลค่าสินค้าคงเหลือ คำนวณต้นทุนขาย รายงานสินค้าเข้า-ออก ยิ่งสินค้าตัวเดียวแต่มีหลาย SKU หากการระบบควบคุมไม่ดี ไม่สามารถบันทึกธุรกรรมได้ครบขั้นตอน และระบบบัญชีไม่ได้ออกแบบให้มีความยืดหยุ่นเพียงพอ การตรวจนับสินค้าจริงเพื่อกระทบยอดทางบัญชีจะกลายเป็นความสับสนอลหม่าน

แล้วเราควรออกแบบ SKU อย่างไรเพื่อตอบโจทย์
 
สะดวกต่อการขาย
สะดวกต่อการเบิกมาเรียงหน้าร้าน
สะดวกต่อการเช็คสต็อคหรือตรวจนับ
สะดวกต่อการสั่งเข้าสต็อค
สะดวกต่อการตรวจสอบและคำนวณต้นทุน
 
ทางเลือก
 
ผมพบว่ามีทางเลือกหลายทางในการออกแบบระบบสต็อค แต่ไม่มีสูตรสำเร็จที่ใช้ได้กับทุกคน การเลือกให้ความสำคัญหรือน้ำหนักกับกิจกรรมด้านหนึ่งมากกว่าด้านอื่น มีผลต่อการเลือกออกแบบให้กระบวนการทำงานอย่างหนึ่งสะดวกสุด โดยยอมรับความไม่สะดวกสำหรับงานด้านที่เหลือ
 
กรณีของร้านสะดวกซื้อ เราควรเน้นการออกแบบเพื่ออำนวยความสะดวกการขายหน้าร้าน เพราะเป็นกิจกรรมที่เกิดขึ้นบ่อยที่สุด เกี่ยวข้องกับคนจำนวนมาก และเป็นช่วงจังหวะเวลาคับขันที่เผชิญหน้ากับผู้ซื้อ
 
ถึงแม้ว่าการเพิ่ม SKU ให้แตกต่างกันตามขนาดบรรจุ เพิ่มภาระความยุ่งยากสำหรับงานตรวจนับ สรุปยอดคงเหลือทางบัญชี แต่ก็มีเพียงวิธีนี้เท่านั้นที่ทำให้กระบวนการขายหน้าร้านสะดวกราบรื่นผิดพลาดน้อยที่สุด
 
อย่างไรก็ตามควรคำนึงถึงผลที่ตามมาด้วย ยิ่งละเอียด ยิ่งจุกจิก ยิ่งยุ่งยาก มีโอกาสผิดพลาด ตกหล่น เช่น หากเอานมที่เป็นแพ็กไปแกะขายเป็นกล่อง จะต้องมีวิธีบันทึกเพื่อปรับสต็อคระหว่าง SKU อย่างไร มิฉะนั้นแพ็คก็จะเหลือค้าง ขณะที่กล่องติดลบ
 
หากเป็นร้านขายส่ง ที่เน้นรับออเดอร์ทางโทรศัพท์หรือทางออนไลน์มากกว่า ความคับขันในจังหวะขายจะเบากว่า ทำให้มีทางเลือกในการออกแบบมากขึ้น อาจพิจารณาเงื่อนไขทักษะของพนักงานมาประกอบ ไม่จำเป็นต้องออกแบบระบบให้สะดวกมากเท่างานขายหน้าร้าน แลกกับงานส่วนอื่นที่ยุ่งยากน้อยลง
 
คำอธิบายด้านบน เป็นการมองจากคุณสมบัติของโปรแกรมทั่วไปที่รองรับการทำงานกับสินค้าแบบพื้นฐาน ซึ่งสามารถทำได้โดยอาศัยการสับรางคอยปรับปรุงโยกสินค้าระหว่าง SKU ด้วยตัวเอง หรืออาจการแยกระบบออกจากกันไปเลย
 
งานขายหน้าร้านอาจใช้โปรแกรม POS ที่มีระบบควบคุมสต็อคในมุมมองหน่วยนับของการขาย ขณะที่งานคลังสินค้าก็อาจใช้ระบบ warehouse ที่เน้นควบคุมสต็อคในมุมมองของการจัดเก็บและตรวจนับ ออกแบบให้มีฟอร์มใบอะไรสักอย่างเป็นตัวกลาง output จากฝั่งหนึ่งกลายเป็น input ของอีกฝั่งหนึ่ง (ยอมรับความซ้ำซ้อนตรงนี้ได้) โดยไม่จำเป็นต้องใช้โปรแกรมระบบเดียวกัน แต่ก็ต้องแลกกับรอยต่อที่ไม่ราบรื่น และความยุ่งยากในการรวบรวมข้อมูลภาพรวมสำหรับผู้บริหาร 
 
ถ้าจะอ้างอิงโมเดลข้อมูลสินค้าเชิงซ้อนของโปรแกรม ERP กลางและใหญ่ ทางเลือกอื่นจะมีดังนี้
 
Products & Components สินค้าอาจมีชิ้นส่วนเสริมที่เป็นส่วนประกอบของสินค้าหลัก เมื่อขายสินค้าจะตัดสต็อคส่วนประกอบ
Bill Of Materials สินค้าที่ต้องแปรรูปจากวัตถุดิบหรือสินค้าอื่นกลายสินค้าใหม่ มักใช้กับการผลิต เมื่อผลิตสินค้าเข้าสต็อคก็จะตัดวัตถุดิบ
Unit of Measure สินค้าเดียวอาจมีหลายหน่วยนับ ขึ้นอยู่กับวัตถุประสงค์ใช้งาน จะต้องระบุสูตรการแปลงค่าหน่วยนับว่าเท่ากับเท่าไหร่ของหน่วยพื้นฐาน
Variants สินค้าเดียวมีคุณสมบัติย่อยแตกต่าง เช่น สี, ลวดลาย, ขนาด ฯลฯ
 
เราสามารถใช้ P&C โดยใช้ SKU ของหน่วยนับ "กล่อง" เป็นฐานในขั้นตอนขาย มี SKU สำหรับขาย "แพ็ก" ซึ่งมีส่วนประกอบเท่ากับ 6 กล่อง ทุกครั้งที่ขายนมแพ็ก ก็จะตัดสต็อค 6 กล่องอัตโนมัติ แล้วก็อาจมี SKU ของหน่วย "ลัง" เพื่อรับสินค้าเข้าสต็อคทีละ 36 กล่อง แต่การนับสินค้าเป็น "กล่อง" อาจทำให้งานบางอย่างไม่ค่อยสะดวกนัก เช่น มีแต่รายงานสต็อคคงเหลือ 360 กล่อง ก็ต้องคำนวณเองว่าเท่ากับของจริงที่เก็บอยู่กี่ลัง
 
บางทีอาจเลือกใช้ UOM ที่ตรงไปตรงมากว่า มีหน่วยนับกี่แบบก็กำหนดให้ครบ สามารถแปลงหน่วยไปกลับได้สะดวกด้วยโปรแกรม แต่ปัญหาอาจอยู่โปรแกรมแต่ละตัวมีฟังก์ชั่นไม่เท่ากัน ออกแบบการทำงานไม่เหมือนกัน บางโปรแกรมสามารถแยก SKU ของแต่ละหน่วยนับ แต่บางโปรแกรมก็ทำไม่ได้ ต้องใช้ SKU เดียวกัน แล้วบังคับให้เลือกหน่วยนับว่าเป็น "กล่อง" หรือ "แพ็ก" อีกทีหนึ่ง
 
ส่วนโมเดลที่เหลือนั้น พิจารณาดูแล้วไม่สามารถออกแบบให้ใช้กับกรณีของสินค้าหลายหน่วยนับได้
 
ผมอยากเรียกวิธีออกแบบโดยใช้โมเดลเหล่านี้ว่าเป็นท่ายาก เพราะยากตั้งแต่เลือกหาโปรแกรมที่รองรับ ต้องมีความรู้ความชำนาญวางแผนออกแบบระบบก่อนเริ่มใช้ (ด้วยความหวังว่า)จะสบายในระยะยาว เหมาะกับธุรกิจที่เติบโตมีปริมาณงานมากเกินกว่าจะเสียเวลาใช้ความสามารถพื้นฐาน แล้วมีภาระงานเพิ่มโดยไม่สามารถควบคุมหรือตรวจสอบได้โดยง่าย
 
ความท้าทาย
 
มีทางเลือกอีกทางหนึ่ง คือ "เลือกที่จะไม่ทำ" เมื่อผู้ประกอบการเข้าใจถึงกระบวนการออกแบบและต้นทุนในการจัดการเบื้องหลังแล้ว อาจคำนวณถึงความคุ้มค่าแล้วอาจเลือกหาจุดสมดุลสำหรับตัวเอง ไม่จำเป็นต้องทำได้ทุกอย่าง มีขายทุกแบบ โฟกัสไปที่สิ่งที่ทำได้ดีและมีความพร้อม
 
ผมตั้งใจเล่าเรื่องนี้โดยยกตัวอย่างนม UHT ที่เราคุ้นเคยกันดี ดูเผิน ๆ ก็เหมือนว่าไม่มีอะไรซับซ้อน ใคร ๆ ก็ขายได้ โปรแกรมไหนก็ใช้ได้ แต่เมื่อถึงจุด ๆ หนึ่งในสเกลใหญ่ รู้ตัวอีกทีเรื่องนั้นใหญ่เกินกว่าหนึ่งหรือสองคนดูแล ต้องการเครื่องมือหรือระบบที่ดีมาช่วย ในที่สุดก็จะพบว่ามีรายละเอียดบางอย่างที่ไม่ง่ายที่จะออกแบบ บางครั้งข้อจำกัดของตัวระบบเองจะทำให้ธุรกิจโตต่อไปไม่ได้ ยิ่งทำยิ่งเห็นแต่ภาพเบลอ ๆ มองทางข้างหน้าไม่ชัด ระบบที่เคยใช้ได้ดีตอนที่กิจการยังเล็ก อาจใช้ไม่ได้เมื่อเติบโตไปอีกระดับ