ใช้ DeepSeek ช่วยงาน ERP ได้จริงไหม?

วิธีทดสอบ — เราทำอย่างไร?

เราใช้ DeepSeek-R1 ผ่าน API (ไม่ใช่ Chatbot บนเว็บ) ทดสอบกับ Scenario งาน ERP จริง 5 ด้านที่พบบ่อยในองค์กรไทย โดยให้คะแนนแต่ละด้าน 1-5 ดาว ตามเกณฑ์ดังนี้:

คะแนน	ความหมาย
1/5	ใช้ไม่ได้เลย ผลลัพธ์ผิดหรือไม่ตรงประเด็น
2/5	พอใช้ได้บ้าง แต่ต้องแก้มาก
3/5	ใช้เป็น Draft ได้ แต่ต้องปรับปรุง
4/5	ดีมาก แก้เล็กน้อยก็ใช้ได้
5/5	ยอดเยี่ยม ใช้ได้เลยแทบไม่ต้องแก้

เงื่อนไขการทดสอบ: Prompt ทุกข้อเป็นภาษาไทย, ข้อมูลที่ใช้เป็น Scenario จำลอง (ไม่ใช่ข้อมูลจริง), ทดสอบในเดือนมีนาคม 2569 ด้วย DeepSeek-R1 version ล่าสุด

Use Case 1: สรุปรายงานการเงินสำหรับผู้บริหาร

โจทย์

ให้ข้อมูลงบกำไรขาดทุน (P&L) 3 เดือน (ตุลาคม-ธันวาคม 2568) ของบริษัทจำลอง รวมถึงรายได้ ต้นทุนขาย ค่าใช้จ่ายดำเนินงาน กำไรสุทธิ แล้วให้ DeepSeek สรุปเป็นภาษาไทยสำหรับนำเสนอผู้บริหาร พร้อมข้อเสนอแนะ

ผลลัพธ์: 4/5

DeepSeek-R1 วิเคราะห์ตัวเลขได้ดีมาก สามารถคำนวณอัตราการเติบโต (Growth Rate), Gross Margin, Net Margin ได้ถูกต้อง และสรุปเป็นประเด็นหลัก 5 ข้อพร้อมข้อเสนอแนะที่สมเหตุสมผล เช่น ชี้ว่า ต้นทุนการผลิตเพิ่มขึ้น 8% ในเดือนธันวาคม อาจเกิดจากราคาวัตถุดิบขึ้น และแนะนำให้ทบทวน งบประมาณไตรมาสถัดไป

จุดแข็ง: วิเคราะห์ตัวเลขแม่นยำ จับ Trend ได้ดี ข้อเสนอแนะใช้ได้จริง

จุดอ่อน: ภาษาไทยมีคำแปลกปะปนบ้าง เช่น ใช้คำว่า "การเพิ่มขึ้นอย่างมีนัยสำคัญ" ซ้ำหลายครั้ง บางประโยคอ่านแล้วรู้สึกเหมือนแปลจากภาษาอังกฤษ ถ้าเปลี่ยน Prompt เป็นภาษาอังกฤษ ผลลัพธ์ดีขึ้นชัดเจน

Use Case 2: เขียน SQL Query จากคำถามภาษาไทย

โจทย์

"หายอดขายแยกตามลูกค้า เดือนมกราคม 2569 เรียงจากมากไปน้อย พร้อมแสดงจำนวน Invoice และยอดเฉลี่ยต่อ Invoice"

ผลลัพธ์: 5/5

นี่คือจุดแข็งที่สุดของ DeepSeek อย่างไม่ต้องสงสัย SQL ที่ได้ออกมา ถูกต้อง 100% โครงสร้างดี อ่านง่าย และยังมี Optimization ที่น่าประทับใจ:

SELECT
    c.name AS customer_name,
    COUNT(DISTINCT t.t_transaction_id) AS invoice_count,
    SUM(tl.linenetamt) AS total_sales,
    ROUND(
        SUM(tl.linenetamt) / NULLIF(COUNT(DISTINCT t.t_transaction_id), 0),
        2
    ) AS avg_per_invoice
FROM t_transaction t
JOIN t_transaction_line tl ON t.t_transaction_id = tl.t_transaction_id
JOIN t_customer c ON t.t_customer_id = c.t_customer_id
WHERE t.issotrx = 'Y'
    AND t.docstatus IN ('CO', 'CL')
    AND t.datetrx BETWEEN '2026-01-01' AND '2026-01-31'
GROUP BY c.name
ORDER BY total_sales DESC;

จุดแข็ง: SQL ถูก Syntax, ใช้ NULLIF ป้องกัน Division by Zero, ใช้ DISTINCT นับ Invoice ไม่ซ้ำ, Filter ด้วย docstatus เอาเฉพาะเอกสารที่ Complete — แสดงว่า DeepSeek เข้าใจโครงสร้าง ฐานข้อมูล ERP ดีมาก นอกจากนี้ยังแนะนำให้สร้าง Index บน datetrx เพื่อเพิ่มความเร็ว

ข้อสังเกต: เรื่อง Coding และ SQL เป็นจุดแข็งจริงๆ ของ DeepSeek ซึ่งสอดคล้องกับที่โมเดล DeepSeek Coder ได้รับการออกแบบมาเพื่องานนี้โดยเฉพาะ ทีม IT สามารถใช้ DeepSeek ช่วยเขียน Query เพื่อดึงข้อมูลจากระบบ ERP ได้อย่างมีประสิทธิภาพ

Use Case 3: วิเคราะห์ Stock Mismatch

โจทย์

ให้ข้อมูลสินค้า 20 รายการ ประกอบด้วย: รหัสสินค้า, ชื่อสินค้า, ยอดในระบบ ERP, ยอดนับจริง (Physical Count) แล้วให้ DeepSeek วิเคราะห์ว่ารายการไหนผิดปกติ สาเหตุที่เป็นไปได้คืออะไร และแนะนำวิธีแก้ไข

ผลลัพธ์: 4/5

DeepSeek ระบุความผิดปกติได้ทุกรายการ โดยจัดกลุ่มเป็น 3 ระดับ: ผิดปกติมาก (ส่วนต่างมากกว่า 10%), ผิดปกติปานกลาง (5-10%), และผิดปกติเล็กน้อย (น้อยกว่า 5%) จากนั้นเสนอสาเหตุที่เป็นไปได้ 5 ข้อ:

1. FIFO ไม่ตรง — ระบบตัดสต็อกตามลำดับ FIFO แต่หน้าคลังหยิบสินค้าไม่ตรงลำดับ ทำให้ ยอด FIFO ในระบบกับของจริงไม่ตรงกัน
2. ไม่ตัดสต็อกตอนเบิก — พนักงานเบิกสินค้าแต่ไม่ได้บันทึกในระบบ ทำให้ยอดในระบบสูงกว่าของจริง
3. รับของเข้าแต่ยังไม่บันทึก — สินค้าเข้า คลังสินค้าแล้วแต่ยังไม่ได้คีย์ใบรับสินค้า ยอดจริงจึงมากกว่าในระบบ
4. สินค้าเสียหาย/หมดอายุ — ของเสียหายแต่ยังไม่ได้ตัดออกจากระบบ
5. ข้อผิดพลาดจากการนับ — นับผิดหน่วย หรือนับข้ามรายการ

DeepSeek ยังแนะนำให้จัดทำ Cycle Count รายสัปดาห์สำหรับสินค้าที่ผิดปกติมาก และให้ตรวจสอบ Transaction Log ย้อนหลัง 30 วัน เพื่อหาจุดที่ยอดเริ่มไม่ตรง

จุดแข็ง: ระบุ Anomaly ได้ทุกรายการ จัดกลุ่มความรุนแรง เสนอสาเหตุครบถ้วน

จุดอ่อน: สาเหตุเป็นแบบ "ทั่วไป" ไม่ได้เฉพาะเจาะจงกับบริบทขององค์กร เช่น ไม่รู้ว่าองค์กรใช้ระบบ Barcode หรือไม่ ใช้ Bin Location หรือไม่ ซึ่งข้อมูลเหล่านี้จะช่วยให้วิเคราะห์สาเหตุได้แม่นยำกว่า

Use Case 4: ร่าง Approval Workflow จัดซื้อ

โจทย์

ออกแบบ Workflow การอนุมัติจัดซื้อ (Purchase Order) 3 ระดับ สำหรับองค์กรขนาดกลาง: หัวหน้าแผนก → ผู้จัดการฝ่าย → ผู้บริหาร โดยให้กำหนดวงเงิน เงื่อนไข และ SLA สำหรับแต่ละระดับ

ผลลัพธ์: 3/5

DeepSeek ให้โครงสร้าง Workflow ที่ ดูดีในภาพรวม:

ระดับ	ผู้อนุมัติ	วงเงิน (บาท)	SLA
ระดับ 1	หัวหน้าแผนก	ไม่เกิน 50,000	1 วันทำการ
ระดับ 2	ผู้จัดการฝ่าย	50,001 - 500,000	2 วันทำการ
ระดับ 3	กรรมการผู้จัดการ	มากกว่า 500,000	3 วันทำการ

จุดแข็ง: โครงสร้างพื้นฐานดี วงเงินสมเหตุสมผล มี SLA ชัดเจน

จุดอ่อน: ขาด Edge Cases ที่สำคัญหลายจุด ได้แก่:

• ไม่มีกรณีข้ามขั้น: ถ้าหัวหน้าแผนกลาออก หรือลาป่วย ใครอนุมัติแทน?
• ไม่มีกรณีตีกลับ: ถ้าผู้จัดการฝ่ายไม่อนุมัติ กลับไปที่ขั้นไหน? แก้แล้วส่งใหม่อย่างไร?
• ไม่มี Timeout: ถ้าผู้อนุมัติไม่ตอบภายใน SLA จะ Escalate อัตโนมัติหรือไม่?
• ไม่มีกรณีเร่งด่วน: ถ้าเป็นการจัดซื้อฉุกเฉิน มีช่องทางอนุมัติเร่งด่วนหรือไม่?
• ไม่มี Split PO: ถ้า PO เกิน 500,000 แต่แบ่งเป็น 2 ใบ ใบละ 300,000 ระบบจะจับได้หรือไม่?

สำหรับงาน Approval Workflow จริง ต้อง Review โดยผู้เชี่ยวชาญ ERP ที่เข้าใจกระบวนการขององค์กร เพราะทุกองค์กรมี Business Rule ที่แตกต่างกัน DeepSeek ให้ได้แค่ "โครง" แต่ "เนื้อ" ต้องใส่เอง

Use Case 5: ตอบคำถามพนักงานเกี่ยวกับ ERP

โจทย์

"วิธีสร้างใบสั่งซื้อ (Purchase Order) ในระบบ ERP มีขั้นตอนอย่างไร?"

ผลลัพธ์: 3/5

DeepSeek ตอบได้ กว้างและถูกต้องในหลักการ โดยให้ขั้นตอนทั่วไป 7 ขั้นตอน: เข้าสู่ระบบ → เลือกเมนู จัดซื้อ → สร้าง PO ใหม่ → เลือก Vendor → เลือกสินค้า → กำหนดจำนวนและราคา → บันทึกและส่งอนุมัติ

จุดแข็ง: หลักการถูกต้อง ครบขั้นตอน อธิบายแต่ละขั้นตอนชัดเจน

จุดอ่อน — และนี่คือปัญหาใหญ่:

• คำตอบเป็น ขั้นตอนทั่วไป ไม่ได้เฉพาะเจาะจงกับระบบ ERP ใดระบบหนึ่ง
• ไม่รู้จัก หน้าจอ (UI) ของ Saeree ERP, SAP, Oracle หรือระบบไหนเลย — ไม่สามารถบอกได้ว่า "คลิกที่เมนูไหน" หรือ "กรอกในช่องไหน"
• ไม่รู้ Business Rule เฉพาะองค์กร เช่น Vendor ต้อง Approve ก่อนใช้ได้ไหม, PO ต้องแนบเอกสารอะไรบ้าง
• ถ้าพนักงานถามคำถามแบบนี้ แล้วได้คำตอบทั่วๆ ไป ก็ ไม่ต่างจากค้น Google

ตารางสรุปผลทดสอบ DeepSeek กับงาน ERP

นี่คือผลรวมจากการทดสอบทั้ง 5 Use Cases:

Use Case	คะแนน	จุดแข็ง	จุดอ่อน
สรุปรายงานการเงิน	4/5	วิเคราะห์ตัวเลขดีมาก จับ Trend ได้	ภาษาไทยไม่สมบูรณ์ คำแปลกบ้าง
เขียน SQL Query	5/5	ถูกต้อง 100%, Optimize ดี, มี Index hint	-
วิเคราะห์ Stock Mismatch	4/5	ระบุ Anomaly ได้ทุกรายการ เสนอสาเหตุครบ	ขาด Context เฉพาะองค์กร
ร่าง Approval Workflow	3/5	โครงสร้างพื้นฐานดี วงเงินสมเหตุสมผล	ขาด Edge Cases สำคัญหลายจุด
ตอบคำถาม ERP	3/5	ตอบได้กว้าง หลักการถูก	ไม่รู้จักระบบ ERP เฉพาะ ตอบทั่วไปเกินไป

คะแนนเฉลี่ย: 3.8/5 — ถือว่า "ดี" สำหรับ AI ราคาถูก แต่ยังไม่ถึงระดับที่จะใช้ทดแทนผู้เชี่ยวชาญ ERP ได้

DeepSeek vs ChatGPT vs Claude — สำหรับงาน ERP โดยเฉพาะ

เราทดสอบ Scenario เดียวกันกับ ChatGPT (GPT-5.4) และ Claude (Opus 4.6) เพื่อเปรียบเทียบ นี่คือผลลัพธ์:

ด้าน	DeepSeek R1	ChatGPT GPT-5.4	Claude Opus 4.6
SQL / Coding	5/5	5/5	5/5
วิเคราะห์ภาษาไทย	3/5	5/5	4/5
Reasoning / วิเคราะห์เชิงลึก	4/5	5/5	5/5
ราคา	5/5 (ถูกสุด)	2/5	2/5
Data Privacy	2/5 (จีน)	4/5	4/5
Self-host ได้	5/5	-	-

สรุป: ถ้าเรื่อง ราคาสำคัญที่สุด หรือต้องการ Self-host เพื่อควบคุมข้อมูล → DeepSeek เป็นตัวเลือกที่ดี แต่ถ้าต้องการ ภาษาไทยที่ดี และ Data Privacy ระดับ Enterprise → ChatGPT หรือ Claude ยังเหนือกว่า อ่านรายละเอียดเพิ่มเติมในบทความ รายงานที่หายไป — ช่องว่างที่ AI ช่วยได้

สรุป: DeepSeek เหมาะกับงาน ERP อย่างไร?

จากการทดสอบทั้ง 5 Use Cases สรุปได้ชัดเจนว่า:

DeepSeek เหมาะเป็น "ผู้ช่วย" ไม่ใช่ "ตัวตัดสินใจ"

AI ไม่ว่าจะเป็น DeepSeek, ChatGPT หรือ Claude ยังไม่สามารถทดแทนผู้เชี่ยวชาญ ERP ได้ แต่สามารถเป็น "ผู้ช่วย" ที่ทำให้งานเร็วขึ้นได้มาก โดยเฉพาะ:

• งาน SQL และดึงข้อมูล: DeepSeek เขียน SQL ได้ยอดเยี่ยม ช่วยทีม IT ประหยัดเวลาได้มาก
• งานวิเคราะห์ตัวเลข: สรุปรายงาน จับ Trend ระบุ Anomaly ทำได้ดี — เหมาะใช้เป็น "ร่างแรก" ก่อนนำเสนอผู้บริหาร
• งานร่าง Workflow/Process: ให้โครงสร้างเบื้องต้นได้ แต่ต้องเติม Business Rule โดยผู้เชี่ยวชาญ

จุดแข็งของ DeepSeek สำหรับงาน ERP

• SQL / Coding — เก่งระดับเดียวกับ GPT-5.4 และ Claude Opus
• วิเคราะห์ข้อมูลเชิงตัวเลข — คำนวณ จับ Trend ได้แม่นยำ
• ราคาถูก — ถูกกว่า 10-50 เท่า ทำให้ SME เข้าถึงได้
• Self-host ได้ — ข้อมูลไม่ต้องออกนอกองค์กร (แต่ต้องมี GPU พอ)

จุดอ่อนของ DeepSeek สำหรับงาน ERP

• ภาษาไทย — ยังสู้ GPT และ Claude ไม่ได้ คำแปลก ประโยคเหมือนแปลจากอังกฤษ
• ไม่รู้จักระบบ ERP เฉพาะ — ตอบได้แค่หลักการทั่วไป ไม่เจาะลึกถึง UI หรือ Business Rule
• Data Privacy — ถ้าใช้ผ่าน API ข้อมูลไปจีน (แก้ได้ด้วย Self-host แต่ต้องลงทุน)
• ขาดความเข้าใจบริบท — ให้คำตอบ "ทั่วไป" ไม่เฉพาะเจาะจงกับบริบทขององค์กร

สำหรับองค์กรที่ต้องการ AI ใน ERP อย่างจริงจัง สิ่งที่ต้องการจริงๆ คือ AI ที่ Fine-tune กับข้อมูล ERP ขององค์กร + เก็บข้อมูลปลอดภัยไม่ส่งออกนอก + เข้าใจ Business Rule เฉพาะ ซึ่ง DeepSeek (หรือ AI ทั่วไป) ยังทำไม่ได้โดยตรง ต้องมีทีมพัฒนาหรือผู้เชี่ยวชาญช่วยปรับแต่ง

DeepSeek Series — ครบทั้ง 5 ตอน

AI ที่ดีที่สุดสำหรับ ERP ไม่ใช่ AI ที่เก่งที่สุด — แต่เป็น AI ที่เข้าใจบริบทขององค์กรคุณมากที่สุด

- ทีมงาน Saeree ERP

แหล่งอ้างอิง

• DeepSeek API Documentation
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning — Technical Report