Case study · ระบบสต็อก + AI · ร้านอะไหล่มอเตอร์ไซค์และอู่ซ่อม
Paolo Auto Car: ระบบดูแลสต็อกอะไหล่ 22,940 รายการ สรุปเข้า LINE ทุกเช้า
Paolo Auto Car เป็นร้านอะไหล่มอเตอร์ไซค์ที่มีอู่ซ่อมในร้าน ใช้ Smile Account บันทึกการขายมานาน แต่ช่องจุดสั่งซื้อในระบบตั้งไว้แค่ 4 จาก 27,262 รายการ เราติดตั้งตัวอ่านข้อมูลแบบอ่านอย่างเดียวบนเครื่องของร้าน ซิงก์ทุก 15 นาที คำนวณอัตราขายและจุดสั่งซื้อให้ 22,940 รายการที่ยังเคลื่อนไหว แล้วส่งสรุปเข้ากลุ่ม LINE ของร้านทุกเช้า 09:00 พร้อมให้พิมพ์ถามสต็อกในกลุ่มได้ Phase 1 นี้ใช้งานจริงทุกวันตั้งแต่ 22 ก.ย. 2026 ส่วน Phase 2 (บิลเข้า ตอบลูกค้า กระทบยอดเงิน นับสต็อก เจ้าหนี้) กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง
ข้อมูลโปรเจกต์
| ลูกค้า | Paolo Auto Car — ร้านอะไหล่มอเตอร์ไซค์ + อู่ซ่อมในร้าน (1 สาขา · คลังเดียว 3 ตำแหน่งเก็บ) |
|---|---|
| ระบบเดิมของร้าน | Smile Account — ร้านใช้ต่อตามเดิม เราไม่เปลี่ยนและไม่เขียนข้อมูลกลับ |
| ขนาดข้อมูล | สินค้า 27,262 รายการ · ยังเคลื่อนไหว 22,940 · บรรทัดขาย 370,174 · ความเคลื่อนไหวสต็อก 401,820 |
| ช่วงเวลา | สำรวจหน้างาน 9 ก.ย. 2026 · ติดตั้ง 17 ก.ย. · สรุปเข้า LINE ทุกวันตั้งแต่ 22 ก.ย. · Phase 2 เริ่ม 24 ก.ย. (ยังดำเนินอยู่) |
| งานของ Hashbox | สำรวจฐานข้อมูล · ออกแบบระบบ · ตัวอ่านข้อมูลบนเครื่องร้าน · ระบบคำนวณบน cloud · ข้อความ LINE · ติดตั้งหน้างาน |
| สถานะ | Phase 1 ใช้งานจริง · Phase 2 กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง |
| บริการที่เกี่ยวข้อง | ที่ปรึกษา AI สำหรับธุรกิจ |
โจทย์: ข้อมูลขายมีครบ แต่ระบบไม่ได้บอกว่าต้องสั่งอะไร
ร้านบันทึกการขายและการรับสินค้าใน Smile Account มาหลายปี ข้อมูลย้อนหลังจึงมีครบ แต่ช่องที่บอกว่าควรสั่งของเมื่อไหร่ (จุดสั่งซื้อ จำนวนขั้นต่ำ ระยะเวลารอของ) ถูกตั้งไว้แค่ 4 รายการจาก 27,262 รายการ การตัดสินใจสั่งของจึงขึ้นกับความจำของคนในร้าน
อู่ซ่อมเบิกอะไหล่จากสต็อกเดียวกับหน้าร้าน และงานซ่อมถูกบันทึกเป็นการขาย ของบางตัวจึงหมดเร็วกว่าที่หน้าร้านรู้สึก ในชั่วโมงแรกที่ระบบคำนวณเสร็จ เราพบสินค้าที่ต่ำกว่าจุดสั่งซื้อ 3,686 รายการ และยอดคงเหลือติดลบ 547 รายการ
ขอบเขตงานคาดไว้ไม่เกิน 5,000 รายการ ตัวเลขจริงคือ 22,940 รายการที่ยังขายหรือมีของ — เราเจอตัวเลขนี้เพราะเข้าไปดูฐานข้อมูลจริงก่อนเขียนโค้ด
Phase 1 ทำอะไรบ้าง
เงื่อนไขที่ตั้งไว้ตั้งแต่วันแรก: อ่านข้อมูลบัญชีของร้านอย่างเดียว ไม่เปิดพอร์ตรับการเชื่อมต่อบนเครื่องร้าน และไม่ติดตั้งโปรแกรมระบบเพิ่ม
สำรวจหน้างานก่อนเขียนโค้ด (9 ก.ย.)
เปิดดูฐานข้อมูลจริงของร้าน นับตาราง และเทียบยอดคงเหลือกับความเคลื่อนไหวของสต็อก ยอดคงเหลือในตารางสินค้าตรงกับผลรวมรับเข้า−จ่ายออกทุกรายการ ยกเว้นไม่ถึง 20 รายการ จึงใช้เป็นตัวเลขหลักได้
ตัวอ่านข้อมูลบนเครื่องร้าน (ติดตั้ง 17 ก.ย.)
โปรแกรมเล็กที่ใช้ Python แบบพกพาในโฟลเดอร์เดียว อ่านด้วยคำสั่ง SELECT อย่างเดียวทุก 15 นาที และส่งเฉพาะรายการที่เปลี่ยนออกไปทาง HTTPS ฐานข้อมูลของร้านเป็นรุ่นเก่าที่รองรับการเข้ารหัสรุ่นเก่าเท่านั้น เราจึงใช้ไดรเวอร์ที่มีอยู่แล้วบนเครื่องแทนการติดตั้งตัวใหม่ การส่งครั้งแรกทั้งก้อนใช้เวลาราว 20 วินาที
คำนวณจุดสั่งซื้อจากยอดขายจริง
อัตราขายต่อวัน = ยอดขาย 90 วัน ÷ 90 (ถ้าข้อมูลน้อยใช้ 180 หรือ 365 วัน) · จุดสั่งซื้อ = อัตราขาย × ระยะรอของ 14 วัน ปัดขึ้น · เตือนล่วงหน้าเมื่อของพอขายอีกไม่เกินระยะรอของ + 7 วัน · เรียงความสำคัญ ติดลบ → ต่ำกว่าจุดสั่งซื้อ → ใกล้ถึง → ปกติ สูตรเต็มอยู่ในบทความ จุดสั่งซื้อและ Safety Stock
สรุปเข้ากลุ่ม LINE ทุกเช้า และถามสต็อกในกลุ่ม
สรุปส่งเวลา 09:00 หลังร้านเปิด 08:30 และส่งเฉพาะเมื่อข้อมูลซิงก์มาไม่เกิน 45 นาที ถ้าข้อมูลเก่ากว่านั้นระบบงดส่งแทนการส่งตัวเลขผิด พนักงานพิมพ์ชื่อหรือรหัสสินค้าอย่างน้อย 3 ตัวอักษรในกลุ่ม แล้วได้ยอดคงเหลือสูงสุด 5 รายการ ข้อความทุกฉบับถูกบันทึกก่อนส่ง จึงไม่มีข้อความซ้ำเมื่อระบบส่งใหม่
อะไรใช้งานจริงแล้ว อะไรยังไม่เปิด
ตามสถานะส่งมอบ ณ 11 ต.ค. 2026 — เราแก้ตารางนี้เมื่อแต่ละส่วนเปิดใช้กับข้อมูลจริง
| ส่วนของงาน | ทำอะไร | สถานะ |
|---|---|---|
| Phase 1 · ซิงก์และคำนวณ | อ่านสต็อกทุก 15 นาที คำนวณจุดสั่งซื้อ 22,940 รายการ | ใช้งานจริง |
| Phase 1 · สรุป LINE + ถามสต็อก | สรุปเข้ากลุ่มร้าน 09:00 และตอบคำถามสต็อกในกลุ่ม | ใช้งานจริงตั้งแต่ 22 ก.ย. 2026 |
| Phase 1 · แจ้งเตือนทันที | ส่งเตือนเมื่อสินค้าต่ำกว่าจุดสั่งซื้อระหว่างวัน | พัฒนาเสร็จ ปิดไว้รอร้านอนุมัติเกณฑ์ |
| Phase 2A · บิลเข้า | ถ่ายรูปบิลผู้ขายใน LINE → AI ร่างรายการ → พนักงานตรวจก่อนนำเข้า | กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง |
| Phase 2A · เบิกของและของทดแทน | เบิกอะไหล่ ยอดพร้อมขาย และสินค้าที่ใช้แทนกันได้ | กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง |
| Phase 2B · ตอบลูกค้าใน LINE | AI ร่างคำตอบเรื่องสินค้าและสต็อกให้ลูกค้าใน LINE OA | กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง |
| Phase 2C · กระทบยอดเงิน | จับคู่เงินสดและเงินโอนกับรายการขาย | กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง |
| Phase 2D · นับสต็อก | นับสต็อกและยอดยกมา | กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง |
| Phase 2E · เจ้าหนี้ | รายการค้างจ่าย เตรียมจ่าย และเงินทดรอง (ไม่มีการโอนเงินจากระบบ) | กำลังส่งมอบ · ยังไม่เปิดใช้กับข้อมูลจริง |
ทำไม Phase 1 ไม่ใช้ AI
ทุกตัวเลขใน Phase 1 มาจากสูตรที่ตรวจย้อนได้ เจ้าของร้านถามได้ว่า "ทำไมรายการนี้ต้องสั่ง" แล้วเราชี้ได้ว่ามาจากยอดขาย 90 วันกับระยะรอของ งานที่คำตอบต้องถูกทุกครั้งแบบนี้ สูตรธรรมดาดีกว่าโมเดลภาษา
AI อยู่ใน Phase 2 ตรงที่สูตรทำไม่ได้: อ่านรูปบิลจากผู้ขายให้เป็นรายการ และร่างคำตอบลูกค้าใน LINE ทั้งสองงานมีคนตรวจก่อนข้อมูลเข้าระบบเสมอ ดูตัวอย่างการออกแบบแบบนี้ใน AI Agent คืออะไร
5 เรื่องในฐานข้อมูลจริงที่ไม่ตรงกับที่คาดไว้
ทั้งหมดนี้เจอระหว่างสำรวจและติดตั้ง และเป็นเหตุผลที่เราไม่เริ่มงานจากข้อมูลจำลองอีก
- คอลัมน์ยอดคงเหลือในบัตรสต็อกเป็น 0 ทุกแถว — ใช้ยอดในตารางสินค้าแทน หลังเทียบกับผลรวมรับ−จ่ายแล้ว
- งานซ่อมในอู่ถูกบันทึกเป็นการขาย — สำหรับร้านนี้ยอดขายคือยอดใช้ของ จึงไม่ต้องแยกการเบิกของอู่
- ฐานข้อมูลแยกเป็นปีละชุด และปีเก่ายังมีการลงรายการหลังขึ้นปีใหม่ — ประวัติขาย 12 เดือนต้องรวมข้ามปีและตัดรายการซ้ำด้วยเลขเอกสาร
- คอลัมน์จำนวนที่แปลงหน่วยแล้วเป็น 0 ทั้งหมด — ต้องคูณหน่วยขายกับอัตราแปลงเอง (1.8% ของบรรทัดขายใช้หน่วยที่ไม่ใช่หน่วยสต็อก)
- ค่าแรงซ่อม 252 รหัสอยู่ในตารางสินค้า และเป็นที่มาของยอดติดลบ 171 จาก 549 รายการ ณ วันที่ตรวจ — ต้องแยกออกก่อนคำนวณ และยอดติดลบที่เหลือขึ้นบนสุดของสรุป ไม่ถูกซ่อน
ตัวเลขที่ตรวจได้
ยังไม่มีตัวเลขผลทางธุรกิจ เช่น ของขาดลดลงกี่เปอร์เซ็นต์ — ร้านเพิ่งใช้ระบบไม่กี่สัปดาห์ และเราจะไม่ประมาณขึ้นเอง ตัวเลขด้านล่างวัดจากระบบจริงทั้งหมด
| ตัวเลข | หมายถึง | ที่มา |
|---|---|---|
| 22,940 | สินค้าที่ระบบดูแล (ยังขายหรือมีของ จากทั้งหมด 27,262 รายการ) | ฐานข้อมูลของร้าน · สำรวจ 9 ก.ย. 2026 |
| 4 จาก 27,262 | สินค้าที่ตั้งจุดสั่งซื้อไว้ก่อนเริ่มโปรเจกต์ | ฐานข้อมูลของร้าน · สำรวจ 9 ก.ย. 2026 |
| 3,686 | สินค้าต่ำกว่าจุดสั่งซื้อในชั่วโมงแรกที่ระบบคำนวณ (ติดลบ 547 · ใกล้ถึง 47 · ปกติ 12,246) | ผลคำนวณรอบแรก วันติดตั้ง 17 ก.ย. 2026 |
| 15 นาที | รอบซิงก์สต็อกจากเครื่องร้าน (ส่งครั้งแรกทั้งก้อนราว 20 วินาที จากนั้นส่งเฉพาะที่เปลี่ยน) | บันทึกการทำงานของตัวอ่านข้อมูล วันติดตั้ง |
| 09:00 ทุกวัน | สรุปสต็อกเข้ากลุ่ม LINE ของร้าน ตั้งแต่ 22 ก.ย. 2026 | ร้านยืนยันข้อความจากข้อมูลจริง 21 ก.ย. 2026 |
สิ่งที่เราเรียนรู้จากงานนี้
- ตัวคุมจำนวนแจ้งเตือนคือยอดขายล่าสุด ไม่ใช่ระยะรอของ ลดระยะรอของจาก 14 เหลือ 3 วัน รายการที่ถูกเตือนลดจาก 4,229 เหลือแค่ 3,769 แต่ถ้านับเฉพาะของที่ขายอย่างน้อย 10 ชิ้นใน 90 วัน จะเหลือ 513 รายการ แจ้งเตือนที่เยอะเกินไปคือแจ้งเตือนที่ไม่มีใครอ่าน แจ้งเตือนทันทีจึงยังปิดไว้จนกว่าร้านเลือกเกณฑ์เอง
- ข้อมูลจำลองไม่เหมือนของจริง โค้ดที่เขียนกับข้อมูลจำลองต้องแก้หน้างานในวันติดตั้ง และสคริปต์ติดตั้งรันไม่ได้บน PowerShell รุ่นเก่าของเครื่องร้านเพราะข้อความภาษาไทย ตั้งแต่นั้นเราสำรวจฐานข้อมูลจริงก่อนเขียนทุกครั้ง
- ระบบต้องรู้ตัวว่าข้อมูลเก่า 23 ก.ย. อินเทอร์เน็ตของร้านมีปัญหา การซิงก์หยุด ระบบงดส่งสรุปเช้าและติดป้าย "ข้อมูลเก่า" ในคำตอบถามสต็อก แทนที่จะส่งตัวเลขเมื่อวานเหมือนเป็นของวันนี้
- LINE ตัดข้อความยาวทิ้งโดยไม่แจ้ง ข้อความที่ยาวเกิน 5,000 ตัวอักษรถูกตัดเงียบๆ สรุปจึงต้องแบ่งเป็นหลายข้อความ และเราเจอบั๊กแสดงตัวเลขติดลบผิดรูปแบบจากการอ่านข้อความจริงในกลุ่ม
- ไม่ทดสอบกับข้อมูลจริงของร้าน Smile ของร้านไม่มีบริษัทสำหรับทดสอบ เราจึงหยุดทดสอบการนำเข้าไฟล์ แทนที่จะลองกับบัญชีจริง นี่เป็นเหตุผลหนึ่งที่ Phase 2 ยังไม่เปิด
คำถามที่พบบ่อย
ระบบนี้ต้องเปลี่ยนโปรแกรมบัญชีไหม
ไม่ต้อง ร้านใช้ Smile Account ต่อตามเดิม ระบบอ่านข้อมูลอย่างเดียวและไม่เขียนอะไรกลับเข้าโปรแกรมบัญชี
ข้อมูลของร้านถูกส่งออกไปที่ไหน
ตัวอ่านข้อมูลส่งเฉพาะข้อมูลสินค้า ยอดคงเหลือ และยอดขายรวมต่อสินค้า ไปยังฐานข้อมูลของระบบผ่าน HTTPS ไม่ส่งข้อมูลลูกค้าของร้าน และไม่มีพอร์ตเปิดรับการเชื่อมต่อจากภายนอกบนเครื่องร้าน
Phase 1 ใช้ AI ไหม
ไม่ใช้ ทุกตัวเลขมาจากสูตรคำนวณจากยอดขายจริงที่ตรวจย้อนได้ AI อยู่ใน Phase 2 คืออ่านรูปบิลและร่างคำตอบลูกค้า ซึ่งมีคนตรวจก่อนเสมอ และยังไม่เปิดใช้กับข้อมูลจริง
จากวันสำรวจถึงวันที่ร้านใช้งานใช้เวลาเท่าไหร่
สำรวจหน้างาน 9 ก.ย. 2026 ติดตั้ง 17 ก.ย. และร้านได้สรุปเข้า LINE ทุกวันตั้งแต่ 22 ก.ย. รวมประมาณ 2 สัปดาห์
ทำแบบนี้กับโปรแกรมบัญชีอื่นได้ไหม
ได้ถ้าเข้าถึงฐานข้อมูลของโปรแกรมแบบอ่านอย่างเดียวได้ แต่แต่ละร้านบันทึกข้อมูลไม่เหมือนกัน เราจึงสำรวจฐานข้อมูลจริงก่อนเสนอขอบเขตทุกครั้ง
อ่านต่อ
ข้อมูลอยู่ในระบบเดิมแล้ว แต่ยังไม่มีใครเอามาใช้?
เล่าโจทย์ให้เราฟัง เราสำรวจระบบเดิมก่อน แล้วบอกตรงๆ ว่าทำอะไรได้และทำอะไรไม่ได้ ก่อนเสนอขอบเขต
ขอประเมินงาน AI ของธุรกิจคุณ