จุดสั่งซื้อ (Reorder Point) และ Safety Stock คำนวณยังไง? ข้อมูลจริงจากร้านอะไหล่ 27,000 รายการที่แจ้งเตือนสต็อกผ่าน LINE

จุดสั่งซื้อ (Reorder Point) คือ จำนวนสต็อกที่เหลือแล้วต้องสั่งของรอบใหม่ทันที เพื่อให้ของล็อตใหม่มาถึงก่อนของเดิมหมด · Safety Stock (สต็อกกันชน) คือ ของที่เก็บเผื่อไว้เกินจากที่คาดว่าจะขายระหว่างรอของ เพื่อรับวันที่ขายดีกว่าปกติหรือวันที่ซัพพลายเออร์ส่งช้า — สองตัวนี้ใช้คู่กันเสมอ เพราะจุดสั่งซื้อที่ไม่มีกันชนคือการสั่งของแบบหวังว่าทุกอย่างจะเป็นไปตามแผน

TL;DR

• สูตรพื้นฐาน: จุดสั่งซื้อ = ยอดขายเฉลี่ยต่อวัน × ระยะรอของ + Safety Stock
• ร้านอะไหล่มอเตอร์ไซค์ที่เราวางระบบให้ (Paolo Auto Car) มีสินค้า ~27,000 รหัส แต่ช่องจุดสั่งซื้อในโปรแกรมบัญชีมีค่าแค่ 4 รหัส — ไม่มีใครตั้งค่า 27,000 ช่องด้วยมือได้
• ให้ระบบคำนวณจุดสั่งซื้อจากประวัติขายทุก 15 นาที แล้วชั่วโมงแรกเจอสินค้าต่ำกว่าจุดสั่งซื้อ 3,686 รายการ — มากเกินกว่าใครจะอ่าน
• สิ่งที่ลดจำนวนแจ้งเตือนได้จริงคือยอดขายล่าสุด ไม่ใช่ระยะรอของ: ลดระยะรอของจาก 14 เหลือ 3 วัน ลดได้แค่ 11% · แจ้งเฉพาะสินค้าที่ขายได้ 10 ชิ้นขึ้นไปใน 90 วัน ลดได้ 88%
• ระบบส่งสรุปเข้า LINE ทุกเช้าเฉพาะวันที่ข้อมูลสด — วันที่ข้อมูลเก่า มันไม่ส่ง

---

สูตรคำนวณจุดสั่งซื้อและ Safety Stock

จุดสั่งซื้อ (Reorder Point)

จุดสั่งซื้อ = ยอดขายเฉลี่ยต่อวัน × ระยะรอของ (วัน) + Safety Stock

• ยอดขายเฉลี่ยต่อวัน — ยอดขายช่วงหนึ่งหารด้วยจำนวนวัน เช่น ยอดขาย 90 วัน ÷ 90
• ระยะรอของ (Lead Time) — นับจากวันที่สั่งจนของเข้าร้านพร้อมขาย ไม่ใช่แค่วันขนส่ง
• Safety Stock — กันชนสำหรับความไม่แน่นอน

Safety Stock สองแบบ

แบบวันกันชน (ใช้ง่าย — แบบที่เราใช้ในระบบจริง)

Safety Stock = ยอดขายเฉลี่ยต่อวัน × จำนวนวันกันชน
จุดสั่งซื้อ  = ยอดขายเฉลี่ยต่อวัน × (ระยะรอของ + วันกันชน)  ปัดขึ้นเป็นจำนวนเต็ม

ข้อดีคืออธิบายให้เจ้าของร้านเข้าใจได้ในประโยคเดียว: “เผื่อของไว้ขายได้อีก X วันหลังของควรจะมาถึง”

แบบตำรา (สถิติ — ใช้เมื่อมีข้อมูลขายรายวันพอ)

Safety Stock = Z × σ × √L

• σ = ส่วนเบี่ยงเบนมาตรฐานของยอดขายรายวัน
• L = ระยะรอของ (วัน)
• Z = ค่าตามระดับบริการที่ต้องการ: 90% → 1.28 · 95% → 1.65 · 99% → 2.33

ถ้าระยะรอของเองก็ไม่แน่นอน ตำราใช้ Z × √(L × σ² + d² × σL²) โดย d = ยอดขายเฉลี่ยต่อวัน และ σL = ส่วนเบี่ยงเบนมาตรฐานของระยะรอของ

ตัวอย่างคำนวณ (ตัวเลขสมมติ)

สินค้าหนึ่งตัว ขายได้ 180 ชิ้นใน 90 วัน ซัพพลายเออร์ส่งของภายใน 7 วัน

ขั้น	แบบวันกันชน (กันชน 3 วัน)	แบบตำรา (ระดับบริการ 95%)
ยอดขายเฉลี่ยต่อวัน	180 ÷ 90 = 2 ชิ้น/วัน	2 ชิ้น/วัน · σ = 1.2 ชิ้น/วัน
Safety Stock	2 × 3 = 6 ชิ้น	1.65 × 1.2 × √7 = 5.2 → 6 ชิ้น
จุดสั่งซื้อ	2 × (7 + 3) = 20 ชิ้น	2 × 7 + 6 = 20 ชิ้น

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

ถ้าวันนี้มีของเหลือ 30 ชิ้น: ของพอขายอีก 30 ÷ 2 = 15 วัน และยังไม่ต้องสั่ง (30 > 20) · พอเหลือ 20 ชิ้นเมื่อไหร่ต้องสั่งทันที

---

คำนวณเองใน Excel ได้ไหม

ได้ ถ้าสินค้าไม่เยอะและคุณยอมดึงข้อมูลใหม่ทุกครั้งที่จะดู

คอลัมน์	ใส่อะไร	ตัวอย่างสูตร
A	รหัสสินค้า
B	ยอดขาย 90 วัน	=SUMIFS(ยอดขาย, รหัส, A2, วันที่, ">="&TODAY()-90)
C	ยอดขายต่อวัน	=B2/90
D	สต็อกคงเหลือ	จากโปรแกรมบัญชี
E	จุดสั่งซื้อ	=ROUNDUP(C2*($H$1+$H$2),0) · H1 = ระยะรอของ · H2 = วันกันชน
F	ของพอขายอีกกี่วัน	=IF(C2>0, D2/C2, "")
G	สถานะ	=IF(D2<0,"ติดลบ",IF(D2<=E2,"ต้องสั่ง",""))

ต้องการกันชนแบบตำรา: ทำยอดขายรายวันของสินค้านั้นเป็นแถว แล้วใช้ =1.65*STDEV.S(ช่วงยอดขายรายวัน)*SQRT($H$1)

เมื่อไหร่ Excel ไม่พอ:

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

ทั้งสี่ข้อคือสิ่งที่เราเจอจริงในร้านด้านล่าง

---

กรณีจริง: Paolo Auto Car ร้านอะไหล่มอเตอร์ไซค์ที่มีอู่ซ่อมในตัว

อ่านเคสเต็มพร้อมสถานะของแต่ละส่วนและบทเรียนจากวันติดตั้งได้ที่ เคส Paolo Auto Car

โจทย์

Paolo Auto Car เป็นร้านอะไหล่มอเตอร์ไซค์ 1 สาขาที่มีอู่ซ่อมในตัว ขายหน้าร้านและเบิกไปซ่อมจากสต็อกเดียวกัน พนักงานรู้ตัวช้าเมื่อของใกล้หมด เจ้าของต้องการให้รู้ก่อนของหมด โดยมีเงื่อนไขสองข้อ: ไม่เปลี่ยนโปรแกรมบัญชีที่ใช้อยู่ และไม่เพิ่มงานให้พนักงาน

ขนาดข้อมูลในโปรแกรมบัญชีของร้าน (Smile Account):

	จำนวน
สินค้าในฐานข้อมูล	~27,000 รหัส
สินค้าที่เคลื่อนไหว (มีของหรือขายใน 12 เดือน)	22,940 รหัส
รายการขายในฐานปีปัจจุบัน	370,174 แถว
รายการเคลื่อนไหวสต็อก	401,820 แถว

ทำไมไม่ใช้ช่องจุดสั่งซื้อที่มีอยู่แล้วในโปรแกรมบัญชี

โปรแกรมบัญชีส่วนใหญ่มีช่อง “ค่าขั้นต่ำ” และ “จุดสั่งซื้อ” ให้อยู่แล้ว ร้านนี้ก็มี แต่ในสินค้า 27,262 รหัส ช่องค่าขั้นต่ำมีค่าแค่ 4 รหัส ช่องจุดสั่งซื้อและระยะรอของว่างทั้งหมด

นี่ไม่ใช่ความผิดของร้าน การตั้งค่า 27,000 ช่องด้วยมือ แล้วกลับมาแก้ทุกครั้งที่ยอดขายเปลี่ยน คืองานที่ไม่มีใครทำได้จริง จุดสั่งซื้อที่ใช้ได้จึงต้องคำนวณจากประวัติขายเองและอัปเดตตัวเอง

ระบบที่ทำ (อธิบายแบบไม่ใช้ศัพท์)

1. โปรแกรมเล็กบนเครื่องของร้าน อ่านข้อมูลจากโปรแกรมบัญชีทุก 15 นาที — อ่านอย่างเดียว ไม่เขียนกลับ ไม่เปิดช่องให้ใครเชื่อมเข้าเครื่องร้าน ส่งข้อมูลออกไปทางเดียวผ่านช่องทางเข้ารหัส · รอบแรกส่งสินค้าทั้งหมดใช้เวลาราว 20 วินาที รอบถัดไปส่งเฉพาะรายการที่เปลี่ยน
2. คำนวณบนคลาวด์ ตามสูตรแบบวันกันชนข้างบน:

• ยอดขายต่อวัน = ยอดขาย 90 วัน ÷ 90 (สินค้าที่ขายน้อยจนข้อมูล 90 วันบางเกินไป ใช้ 180 หรือ 365 วันแทน)
• ของพอขายอีกกี่วัน = สต็อก ÷ ยอดขายต่อวัน
• จุดสั่งซื้อ = ยอดขายต่อวัน × (ระยะรอของ + วันกันชน) ปัดขึ้น · ระยะรอของเริ่มต้น 14 วัน ปรับรายสินค้าได้ภายหลัง
• เรียงความเร่งด่วน: ติดลบ → ต่ำกว่าจุดสั่งซื้อ → ใกล้หมด → ปกติ

1. ส่งเข้ากลุ่ม LINE ของร้าน — สรุปทุกเช้า และพิมพ์ค้นสต็อกในกลุ่มได้ (รหัสอย่างน้อย 3 ตัวอักษร แสดงไม่เกิน 5 รายการ)

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

บทเรียนที่ 1: คำนวณถูก แต่แจ้งเตือนมากจนไม่มีใครอ่าน

ชั่วโมงแรกหลังติดตั้ง ระบบจัดสถานะสินค้าได้ดังนี้:

สถานะ	จำนวน
ติดลบ	547
ต่ำกว่าจุดสั่งซื้อ	3,686
ใกล้หมด	47
ปกติ	12,246

สูตรถูกต้องทุกตัว แต่ข้อความ LINE ที่มีสินค้าสามพันกว่ารายการทุกเช้า คือข้อความที่ทุกคนเลื่อนผ่าน เราจึงทดลองว่าเงื่อนไขไหนลดจำนวนแจ้งเตือนได้จริง (คำนวณกับสินค้าที่มีประวัติขาย 16,537 รายการ):

เงื่อนไข	สินค้าที่จะถูกแจ้ง	เทียบกับตั้งต้น
ระยะรอของ 14 วัน (ตั้งต้น)	4,229	—
ลดระยะรอของเหลือ 3 วัน	3,769	ลด 11%
แจ้งเฉพาะที่ขายได้ ≥ 3 ชิ้นใน 90 วัน	1,266	ลด 70%
แจ้งเฉพาะที่ขายได้ ≥ 5 ชิ้นใน 90 วัน	874	ลด 79%
แจ้งเฉพาะที่ขายได้ ≥ 10 ชิ้นใน 90 วัน	513	ลด 88%

ตัวที่คุมปริมาณแจ้งเตือนคือยอดขายล่าสุด ไม่ใช่ระยะรอของ — สินค้าส่วนใหญ่ที่ “ต่ำกว่าจุดสั่งซื้อ” เป็นของที่ขายปีละไม่กี่ชิ้น จุดสั่งซื้อของมันคือ 1 และสต็อกคือ 0 หรือ 1 การเตือนของพวกนี้ทุกวันไม่ได้ช่วยใคร ขณะที่ใน 100 อันดับสินค้าขายดี มีราว 40 รายการที่ต่ำกว่าจุดสั่งซื้อ — นี่คือรายการที่ควรถึงมือคนสั่งของจริง

บทเรียนที่ 2: ข้อมูลในโปรแกรมบัญชีไม่ได้หมายความตามชื่อคอลัมน์เสมอ

• ค่าแรงช่างถูกบันทึกเป็นรหัสสินค้า — อู่บันทึกค่าแรงเป็นสินค้า 252 รหัส ค่าแรงไม่มีสต็อก ขายไปเรื่อยๆ จึง “ติดลบ” ตลอด ในวันที่ตรวจ 171 จาก 549 รายการติดลบเป็นค่าแรง ไม่ใช่อะไหล่ · แก้ด้วยรายการยกเว้นที่ร้านยืนยันเอง
• ช่องยอดคงเหลือในบัตรสต็อกเป็น 0 ทุกแถว — ถ้าเชื่อชื่อคอลัมน์ ทุกสินค้าจะดูเหมือนหมดสต็อก ยอดที่ใช้ได้อยู่ที่ตารางสินค้า ซึ่งเราตรวจกับผลรวม “รับเข้า − จ่ายออก” ของทั้งประวัติแล้ว ตรงกันทุกรหัสยกเว้นไม่ถึง 20 รหัส
• ขายคนละหน่วยกับที่นับสต็อก — สินค้าบางตัวนับสต็อกเป็นกระป๋องแต่ขายเป็นลังละ 20 รายการขาย 90 วันราว 1.8% เป็นหน่วยที่ไม่ใช่หน่วยสต็อก น้อยก็จริง แต่ถ้าไม่แปลงหน่วย สินค้ากลุ่มนี้จะคำนวณยอดขายผิดเป็นสิบเท่า
• สต็อกติดลบต้องเห็น ไม่ใช่ซ่อน — ติดลบแปลว่าตัวเลขในระบบไม่ตรงกับของจริง ระบบจึงเรียงไว้บนสุดของสรุป ให้ร้านเลือกได้ว่าจะไปตรวจนับตัวไหน

บทเรียนที่ 3: ข้อมูลเก่าอันตรายกว่าไม่มีข้อมูล

สรุปที่บอกว่า “ของยังพอ” จากข้อมูลเมื่อวาน ทำให้คนไม่สั่งของในวันที่ควรสั่ง ระบบจึงส่งสรุปเข้า LINE เฉพาะเมื่อ:

• การดึงข้อมูลรอบล่าสุดสำเร็จ
• ข้อมูลอายุไม่เกิน 45 นาที
• ดึงหลังร้านเปิดของวันนั้น (ร้านเปิด 08:30 สรุปส่ง 09:00)

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

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

สถานะตอนนี้

	สถานะ
ดึงข้อมูลจากโปรแกรมบัญชีทุก 15 นาที	ใช้งานจริง
สรุปสต็อกทุกเช้าในกลุ่ม LINE	ใช้งานจริง
ค้นสต็อกในกลุ่ม LINE	ใช้งานจริง
แจ้งเตือนทันทีเมื่อต่ำกว่าจุดสั่งซื้อ	ปิดไว้ รอร้านอนุมัติเกณฑ์ (ตั้งใจ — ไม่อยากเปิดแบบที่แจ้งสามพันรายการ)
ถามสต็อกเป็นภาษาพูดด้วย AI	อยู่ในขอบเขตที่กำลังทำต่อ
Phase 2: อ่านบิลรับของ เบิกอะไหล่ผ่าน LINE ตอบลูกค้าใน LINE OA กระทบยอดเงินสด/เงินโอน ตรวจนับสต็อกและยอดยกมา และงานเจ้าหนี้/เบิกค่าใช้จ่าย	กำลังส่งมอบ — พัฒนาและทดสอบอยู่ ยังไม่เปิดใช้กับข้อมูลจริง (รายละเอียดใน AI Agent ตัวอย่างที่ 1)

เรายังไม่ใส่ตัวเลขอย่าง “ของขาดลดลงกี่เปอร์เซ็นต์” เพราะยังไม่ได้วัดครบรอบ ตัวเลขที่ยังไม่ได้วัดไม่ควรอยู่ในบทความ

สิ่งที่ร้านได้แล้วตอนนี้: รายการสินค้าที่ต้องสั่งเรียงตามความเร่งด่วนทุกเช้าในกลุ่ม LINE ที่ใช้อยู่แล้ว และค้นสต็อกจากมือถือในกลุ่มเดียวกันได้ — โดยที่โปรแกรมบัญชีเดิมไม่ถูกแตะ

---

ข้อจำกัดของการคำนวณจุดสั่งซื้อจากประวัติขาย

• ฤดูกาลและเทศกาล — ค่าเฉลี่ย 90 วันตามช่วงขายดีที่เพิ่งเริ่มไม่ทัน สินค้าตามฤดูต้องปรับกันชนเอง
• สินค้าใหม่ไม่มีประวัติ — ต้องตั้งจุดสั่งซื้อเองจนกว่าจะมียอดขายพอ
• ระยะรอของไม่เท่ากันทุกซัพพลายเออร์ — ค่าเริ่มต้นเดียว (เช่น 14 วัน) ใช้เริ่มได้ แต่ควรปรับรายซัพพลายเออร์หรือรายสินค้าที่ขาดบ่อย
• วันกันชนคือการตัดสินใจทางธุรกิจ — กันชนมากของไม่ขาดแต่ทุนจม กันชนน้อยทุนไม่จมแต่เสี่ยงขาด ไม่มีสูตรไหนตัดสินแทนเจ้าของร้านได้
• สินค้าที่ขายปีละ 1–2 ชิ้น — ค่าเฉลี่ยไม่มีความหมาย ใช้ “สั่งเมื่อหมด” หรือค่าขั้นต่ำคงที่ดีกว่า
• สูตรดีแค่ไหนก็พังถ้ายอดคงเหลือผิด — ถ้าสต็อกในระบบไม่ตรงของจริง ต้องตรวจนับก่อน ไม่ใช่ปรับสูตร

---

ถ้าจะทำระบบแบบนี้ให้ร้านของคุณ

ไล่สามข้อนี้ก่อนคุยกับใคร:

1. โปรแกรมที่ใช้อยู่ให้อ่านข้อมูลได้ไหม — ฐานข้อมูลแบบไหน อยู่บนเครื่องร้านหรือคลาวด์ ถ้าอ่านได้ ไม่ต้องเปลี่ยนโปรแกรม
2. ใครควรได้แจ้งเตือน และควรได้กี่รายการต่อวัน — คิดจากคนที่สั่งของจริง ไม่ใช่จากจำนวนสินค้า
3. ยอดคงเหลือในระบบเชื่อได้แค่ไหน — ถ้าติดลบเยอะ ให้วางแผนตรวจนับคู่กัน

อีกเรื่องที่ควรรู้: LINE Notify ที่หลายร้านเคยใช้ส่งแจ้งเตือนปิดบริการไปแล้ว ระบบใหม่ต้องส่งผ่าน LINE Official Account (Messaging API) ซึ่งส่งเข้ากลุ่มและตอบคำถามในกลุ่มได้ — ดูภาพรวมได้ที่ คู่มือ LINE Chatbot AI สำหรับธุรกิจไทย

---

อ่านต่อ

• ปรึกษาทำระบบ AI Solution สำหรับธุรกิจ: เริ่มยังไง งบเท่าไหร่ — ถ้าอยากรู้ว่างานแบบนี้เริ่มจากตรงไหนและใช้เวลาเท่าไร
• AI Agent คืออะไร? ต่างจาก Chatbot ยังไง + 3 ตัวอย่างจริง — ระบบสต็อกนี้คือหนึ่งในสามตัวอย่าง พร้อมส่วนที่กำลังพัฒนา (อ่านบิล · กระทบยอด)
• AI Workforce คืออะไร คู่มือสำหรับ SME ไทย — งานซ้ำๆ หลังร้านอื่นที่ให้ระบบช่วยได้
• LINE Chatbot AI: คู่มือสร้าง Chatbot ธุรกิจไทย — ช่องทางที่ทีมใช้อยู่แล้วคือช่องทางที่แจ้งเตือนได้ผลที่สุด

อยากรู้ว่าข้อมูลในโปรแกรมของร้านคุณทำแบบนี้ได้ไหม — คุยกับที่ปรึกษา AI สำหรับธุรกิจของ Hashbox (ประเมินโอกาสฟรี 30 นาที) หรือส่งรายละเอียดให้เรา

---

FAQ: คำถามที่พบบ่อยเรื่องจุดสั่งซื้อและ Safety Stock