Excel จัดการสต๊อกได้ถึงจุดไหน — 5 สัญญาณว่าคุณเลยจุดนั้นมาแล้ว

ไฟล์ stock.xlsx ไม่เคยพังแบบมีเสียงดัง มันไม่ crash ไม่ขึ้น error สีแดง มันแค่ค่อย ๆ รายงานตัวเลขที่ผิดให้คุณฟังทุกวันอย่างสุภาพ จนวันหนึ่งคุณสั่งของเพิ่มทั้งที่ในโกดังยังกองอยู่ หรือรับออร์เดอร์ลูกค้าทั้งที่ของหมดไปแล้วสองวัน

ปัญหาไม่ได้อยู่ที่ Excel ไม่ดี Excel เป็นซอฟต์แวร์ที่ดีที่สุดตัวหนึ่งเท่าที่มนุษย์เคยสร้าง ปัญหาอยู่ที่เราเอามันไปทำงานที่มันไม่ได้ถูกออกแบบมาให้ทำ

Excel เป็นเครื่องคิดเลข ไม่ใช่ระบบบันทึกความจริง

ความต่างระหว่าง spreadsheet กับ database ไม่ได้อยู่ที่หน้าตา แต่อยู่ที่คำถามที่มันถูกสร้างมาเพื่อตอบ

• spreadsheet ตอบคำถามว่า ถ้าสมมติแบบนี้ ผลลัพธ์จะเป็นเท่าไหร่ มันเก่งเรื่องการจำลอง งบประมาณ การลองปรับตัวเลขไปมา
• database ตอบคำถามว่า ตอนนี้ความจริงคืออะไร ใครเปลี่ยนมัน เปลี่ยนเมื่อไหร่ และเปลี่ยนจากอะไรเป็นอะไร

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

เมื่อระบบไม่เก็บเหตุการณ์ คุณจะแก้ปัญหาย้อนหลังไม่ได้เลย รู้แค่ว่าตัวเลขผิด แต่ไม่มีทางรู้ว่าผิดตรงไหน

จุดตัดที่ 1 — SKU ทะลุหลักร้อย

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

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

Excel ไม่มีแนวคิดเรื่อง primary key ที่บังคับใช้ได้จริง คุณตั้งกฎในหัวว่าคอลัมน์ A ต้องไม่ซ้ำ แต่ไม่มีอะไรหยุดพนักงานจากการพิมพ์รหัสซ้ำหรือพิมพ์ผิดตัวเดียว ระบบที่ออกแบบมาสำหรับสต๊อกจะปฏิเสธการบันทึกทันที Excel จะรับไว้เงียบ ๆ แล้วปล่อยให้คุณไปเจอตอนนับสต๊อกปลายปี

จุดตัดที่สองของ SKU คือเมื่อสินค้าเริ่มมี ตัวแปรย่อย — สี ไซส์ ล็อตการผลิต วันหมดอายุ สินค้า 50 ตัวที่มี 4 สี 3 ไซส์ ไม่ใช่ 50 แถว แต่คือ 600 แถว และ Excel ไม่มีโครงสร้างแม่-ลูกให้คุณ คุณจะต้องแบนทุกอย่างให้อยู่ในตารางเดียว ซึ่งทำให้การหาว่า "เสื้อรุ่นนี้รวมทุกสีเหลือเท่าไหร่" ต้องพึ่งสูตรที่เปราะบาง

จุดตัดที่ 2 — มีคนแตะไฟล์มากกว่าหนึ่งคน

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

สมมติสต๊อกสินค้า A เหลือ 10 ชิ้น พนักงานหน้าร้านเปิดไฟล์ตอน 14:00 เห็นเลข 10 ขายไป 3 กรอกเป็น 7 กดเซฟตอน 14:20 ระหว่างนั้นคนคุมโกดังก็เปิดไฟล์เดียวกันตอน 14:05 เห็นเลข 10 เหมือนกัน ตัดของส่งออนไลน์ไป 4 กรอกเป็น 6 กดเซฟตอน 14:25

ผลลัพธ์ในไฟล์คือ 6 ความจริงในชั้นวางคือ 3

นี่เรียกว่า race condition หรือปัญหา lost update ซึ่งเป็นปัญหาคลาสสิกของระบบที่ไม่มีการล็อกข้อมูลระดับแถว ระบบฐานข้อมูลจริงจะไม่ให้เกิดเหตุการณ์นี้ เพราะมันไม่ได้บันทึกว่า "ยอดใหม่เท่ากับ 7" แต่บันทึกว่า "ลบออก 3" การลบ 3 แล้วลบ 4 จากฐาน 10 ยังไงก็ได้ 3

Excel Online กับ Google Sheets ช่วยเรื่อง co-editing ได้บางส่วน แต่ไม่ได้แก้ปัญหาเชิงตรรกะนี้ เพราะคนสองคนยังคง อ่านค่าเดิม แล้วเขียนทับด้วยค่าที่คำนวณเอง อยู่ดี

พอความคลาดเคลื่อนแบบนี้เกิดวันละครั้งสองครั้ง คูณด้วย 30 วัน คูณด้วยจำนวน SKU ที่ขายดี ตัวเลขในไฟล์กับของจริงจะห่างกันเรื่อย ๆ แบบที่หาต้นตอไม่เจอ

จุดตัดที่ 3 — ขายมากกว่าหนึ่งช่องทาง

หน้าร้าน + LINE + Shopee + Lazada + TikTok Shop คือ 5 แหล่งที่ตัดสต๊อกจากกองเดียวกัน

ถ้าไม่มีระบบกลาง สิ่งที่เกิดขึ้นคือคุณต้องตั้ง สต๊อกกันชน — เช่นมีของจริง 20 ชิ้น แต่ประกาศบน Shopee แค่ 8 บน Lazada 8 เหลืออีก 4 ไว้หน้าร้าน วิธีนี้ทำให้คุณเสียโอกาสขายทุกวัน เพราะแต่ละช่องทางเห็นของน้อยกว่าความจริงเสมอ และถ้าไม่ตั้งกันชน คุณจะโดน oversell แล้วต้องยกเลิกออร์เดอร์ ซึ่งกระทบคะแนนร้านบนแพลตฟอร์มโดยตรง

ทั้งสองทางเลือกล้วนมีต้นทุน และต้นทุนนั้นเกิดจากการที่ไม่มีแหล่งความจริงเดียว

ปัญหาที่แก้ด้วยสูตรไม่ได้ — ไม่มี audit trail

สูตร VLOOKUP ที่ซับซ้อนที่สุดในโลกก็ตอบคำถามนี้ไม่ได้ "ทำไมเมื่อวานสินค้า A เหลือ 12 วันนี้เหลือ 5 ทั้งที่ขายไปแค่ 3"

ระบบที่มี audit trail จะตอบได้ทันทีว่า มีการขาย 3 รายการ มีการปรับยอดโดยผู้ใช้ชื่อ X เวลา 16:42 จาก 9 เป็น 5 พร้อมหมายเหตุที่บังคับให้กรอก

Excel ตอบได้แค่ว่า "ตอนนี้เป็น 5" ส่วน version history ของไฟล์บอกได้แค่ว่าใครเซฟไฟล์ ไม่ได้บอกว่าเขาแก้เซลล์ไหนด้วยเหตุผลอะไร

ผลกระทบที่แท้จริงไม่ใช่เรื่องเทคนิค แต่เป็นเรื่องคน เมื่อไม่มีใครรู้ว่าใครทำอะไร ก็ไม่มีใครรับผิดชอบ และเมื่อไม่มีใครรับผิดชอบ ความระมัดระวังจะลดลงต่อเนื่อง

ของหายแบบไม่มีใครรู้ตัว

ในวงการค้าปลีกมีคำว่า shrinkage หมายถึงส่วนต่างระหว่างสต๊อกตามระบบกับสต๊อกที่นับได้จริง สาเหตุมีตั้งแต่ของเสีย ของหมดอายุ การรับของไม่ครบแต่เซ็นรับ ไปจนถึงการทุจริตภายใน

ประเด็นสำคัญไม่ใช่ว่า shrinkage เกิดขึ้นหรือไม่ — มันเกิดกับทุกร้าน ประเด็นคือ คุณตรวจจับมันได้เร็วแค่ไหน

ร้านที่ใช้ Excel มักตรวจเจอตอนนับสต๊อกใหญ่ปีละครั้ง ซึ่งสายเกินไปที่จะสืบหาสาเหตุ ส่วนร้านที่มีระบบบันทึกธุรกรรมจะเห็นความผิดปกติเป็นราย SKU ทุกสัปดาห์ แล้วโฟกัสการนับเฉพาะกลุ่มที่ผิดปกติ ซึ่งเป็นวิธีที่เรียกว่า cycle counting — นับทีละส่วนแบบหมุนเวียน แทนที่จะปิดร้านนับทั้งหมดทีเดียว

ต้นทุนที่ไม่เคยถูกบันทึกลงบัญชี

สิ่งที่ทำให้คนอยู่กับ Excel นานเกินไปคือมันดู "ฟรี" แต่ต้นทุนจริงกระจายอยู่ในที่ที่งบกำไรขาดทุนมองไม่เห็น

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

เช็กลิสต์ 6 ข้อ ถ้าตอบว่าใช่เกินสามข้อ ถึงเวลาเปลี่ยน

• 1. ต้องนับสต๊อกจริงเพื่อยืนยันก่อนสั่งของทุกครั้ง — แปลว่าคุณไม่เชื่อไฟล์ของตัวเองแล้ว
• 2. มีคนมากกว่าหนึ่งคนแก้ไฟล์เดียวกัน — race condition กำลังเกิดขึ้นแน่นอน แค่คุณยังไม่เห็น
• 3. เคยขายของที่ไม่มีแล้วต้องขอโทษลูกค้า — ต้นทุนความน่าเชื่อถือเริ่มถูกเก็บแล้ว
• 4. ตอบไม่ได้ว่าสินค้าตัวไหนขายดีที่สุดใน 30 วันล่าสุด — คุณมีข้อมูล แต่ไม่มีสารสนเทศ
• 5. ไฟล์เปิดช้าหรือค้างเวลาแก้ — โครงสร้างเริ่มเกินขีดจำกัดเชิงกายภาพแล้ว
• 6. ไม่มีทางรู้ว่าใครเป็นคนแก้ยอดล่าสุด — ไม่มี accountability ในระบบ

ผมเอาไปใช้จริงยังไง

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

พอผมเริ่มดูธุรกิจของคนรอบตัว ผมเจอว่าปัญหาเดียวกันเป๊ะเกิดกับร้านค้า SME เพียงแต่ไม่มีใครเรียกมันด้วยศัพท์นี้ เจ้าของร้านรู้สึกแค่ว่า "ตัวเลขมันเพี้ยน" แล้วก็แก้ด้วยการนับใหม่ ซึ่งเป็นการรักษาอาการ ไม่ได้รักษาสาเหตุ สาเหตุจริงคือระบบบันทึกไม่ได้เก็บเหตุการณ์ เก็บแค่ผลลัพธ์

pain ที่ทำให้ผมต้องลงมือสร้างเครื่องมือคือ ทางเลือกในตลาดมันสุดขั้วเกินไป ฝั่งหนึ่งคือ Excel ที่ฟรีแต่ไม่รองรับธุรกรรม อีกฝั่งคือระบบ ERP ที่ครบแต่แพงและต้องมีคนดูแล ร้านที่มีสินค้าสองสามร้อย SKU กับพนักงานไม่กี่คน ตกอยู่ตรงกลางที่ไม่มีอะไรพอดี ต้องทนใช้ของที่เล็กไปจนกว่าจะเจ็บพอที่จะกระโดดไปใช้ของที่ใหญ่ไป

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

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