สร้าง "สมองส่วนกลาง" ให้ธุรกิจ SME: บันทึกออกแบบ AI-Native ERP ด้วย SurrealDB v3
บันทึกแนวคิดและสถาปัตยกรรมเบื้องหลังการสร้าง Digital Nervous System ให้อาณาจักรธุรกิจก่อสร้าง — ไม่ใช่ ERP ที่รอรับคำสั่ง แต่เป็นสมองที่คิดและบริหารแทนเจ้าของธุรกิจ รันบน Sovereign AI infrastructure ของตัวเอง
มีศัตรูเงียบตัวหนึ่งที่กัดกินกำไรของ SME ไทยไปปีละหลายสิบเปอร์เซ็นต์ — ผมขอเรียกมันว่า "Data Chaos" ข้อมูลสำคัญกระจายอยู่ใน LINE group, กระดาษใบเปื้อนปูน, และ Excel สามเวอร์ชันที่ไม่ตรงกัน การตัดสินใจที่ควรใช้เวลา 5 นาทีต้องประชุม 2 ชั่วโมง และเมื่อเกิดความผิดพลาด ไม่มีใครรู้ว่ามันเริ่มต้นที่ตรงไหน
บทความนี้คือบันทึกการออกแบบระบบที่ผมกำลังสร้างให้กลุ่มธุรกิจหนึ่งใน จ.สกลนคร — Nature Group ที่ประกอบด้วย 3 บริษัท ได้แก่ รับสร้างบ้าน โรงงานพรีคาสท์ และวินด์เซอร์ เป้าหมายไม่ใช่การซื้อ ERP สำเร็จรูปมาใช้ แต่คือการ "สร้างสมองส่วนกลาง" ของตัวเอง ที่เรียกภายในว่าโปรเจกต์ sme and me
เป้าหมายระยะยาว 3 ปีคือสเกลจากรายได้ระดับ 100 ล้าน ไป 1,000 ล้าน โดยไม่เพิ่มพนักงานออฟฟิศแม้แต่คนเดียว เพราะเรากำลังให้ AI เป็นกระดูกสันหลังขององค์กรแทน
AI-Native ERP ต่างจาก ERP ธรรมดาอย่างไร
ERP แบบดั้งเดิมถูกออกแบบให้ "รอรับคำสั่ง" ผู้ใช้เป็นคนกรอก ระบบเป็นคนบันทึก แล้วรายงานสรุปให้ผู้บริหารดู รูปแบบนี้ใช้งานได้ดีตอนปี 2005 แต่ในปี 2026 มันเป็นคอขวดของธุรกิจ เพราะคนต้องกรอกข้อมูลซ้ำซาก และผู้บริหารต้องอ่านรายงานเองทุกเช้า
AI-Native ERP กลับด้านแนวคิดทั้งหมด — ระบบเป็นคน "คิดก่อน" แล้วถามผู้บริหารเฉพาะตอนที่ต้องตัดสินใจจริง ๆ ส่วนงานที่ตัดสินใจได้เอง (เช่น สั่งซื้อวัสดุที่ใกล้หมด) ก็ทำไปเลยโดยไม่รอ หน้าที่ของเจ้าของธุรกิจเปลี่ยนจาก "ควบคุมทุกอย่าง" เป็น "ตั้งนโยบายแล้วตรวจผลลัพธ์"
ข้อจำกัดของ ERP แบบเดิมที่เราเจอจริง
ข้อแรก — รอให้คนกรอกข้อมูลก่อน ระบบไม่รู้ว่าเกิดอะไรขึ้นที่หน้างาน ข้อสอง — เก็บข้อมูลเป็นตารางแยก ทำให้ความสัมพันธ์ระหว่างงานกันและโรงงานถูกตัดขาด ข้อสาม — UI ซับซ้อนจนพนักงานเลือกจดใส่กระดาษเพราะเปิด ERP ใช้เวลานานกว่า
Digital Nervous System: เชื่อม 3 บริษัทให้คิดเหมือนสมองเดียว
Vision หลักของระบบนี้คือการสร้าง "ระบบประสาท" ที่เชื่อมกิจกรรมทุกจุดในอาณาจักรให้รับรู้ซึ่งกันและกัน — แบบเดียวกับที่มือเราขยับแล้วสมองรู้ทันทีโดยไม่ต้องรายงาน
ตัวอย่างที่เกิดขึ้นจริงในระบบ: ปูนซีเมนต์ใกล้จะขาดที่โรงงานพรีคาสท์ → AI เห็นล่วงหน้าว่าอีก 3 วันจะไม่พอ → เช็คตารางผลิตและแผนจัดส่งหน้างานสร้างบ้านทั้งหมด → ทำ 2 อย่างพร้อมกัน คือส่งคำสั่งซื้อไปให้ Supplier แล้วแจ้งหัวหน้างานหน้าบ้านว่าต้องเลื่อนงานเทปูน 1 วัน ทั้งหมดนี้ "เด็ดดอกไม้สะเทือนถึงดวงดาว" โดยไม่ต้องประชุม
นี่คือสิ่งที่ ERP ปกติทำไม่ได้ ไม่ใช่เพราะมันโง่ แต่เพราะมันไม่ได้ออกแบบมาให้ "มอง" ข้อมูลเป็นใยแมงมุม
Tech Stack: Sovereign AI Infrastructure ที่ไม่ต้องพึ่ง Cloud ภายนอก
หัวใจของการออกแบบคือ "อธิปไตยทางเทคโนโลยี" เราไม่อยากให้ข้อมูลความลับทางการค้าของลูกค้า (ราคาต้นทุน, BOM, Supplier) วิ่งออกไปยัง Cloud ต่างประเทศตลอดเวลา ทุกชั้นของระบบจึงเลือกเครื่องมือที่รันบนเซิร์ฟเวอร์ตัวเองได้
ชั้น Frontend: TanStack Start
เลือก TanStack Start (Full-stack React framework) เพราะ 2 เหตุผล — ประสบการณ์ใช้งานแบบ Zero Latency เนื่องจากดึงข้อมูลฝั่ง server ได้โดยไม่ต้อง round-trip ไป API แยก และการจัดการ State ที่แม่นยำผ่าน TanStack Query ซึ่งเป็น library ที่ทีมเราคุ้นเคยดีอยู่แล้ว
ชั้น Database: SurrealDB v3 คือไม้ตายของระบบ
ถ้าให้ชี้เทคโนโลยีที่เปลี่ยนเกมมากที่สุดในโปรเจกต์นี้ คำตอบคือ SurrealDB v3 ที่เพิ่งเปิดตัว เพราะมันรวม 4 ความสามารถที่เราต้องใช้พร้อมกันไว้ใน engine เดียว
1) Graph Database ที่เก็บข้อมูลแบบใยแมงมุม — ทำให้เราเชื่อม BOM (Bill of Materials) ของผนังพรีคาสท์ 1 แผ่น เข้ากับ SKU ของน็อต เหล็ก ปูน Supplier และงานหน้าบ้านที่ใช้แผ่นนั้นได้ลึกหลายชั้น การคำนวณ "ขาดอะไรที่ไหน" กลายเป็น graph traversal ไม่ใช่ JOIN ที่ซ้อนกันหลายตารางอย่าง PostgreSQL
2) Spectron หรือ Agentic Memory — ฟีเจอร์ใหม่ใน v3 ที่ทำหน้าที่เป็น "ความจำระยะยาว" ให้ AI จำบริบทงานในอดีตได้อัตโนมัติ ไม่ต้องเขียน vector store + embedding pipeline แยกอีก
3) Live Queries — ระบบ push ข้อมูลแบบ real-time ทันทีที่มีการขยับสถานะในโรงงาน ไม่ต้องให้ client polling ทุก 5 วินาทีอย่างที่เคยทำ
4) WASM Extensions ที่รัน Logic ซับซ้อนภายในฐานข้อมูลด้วยภาษา Rust — เช่นการคำนวณโครงสร้างหรือตรวจ BOM ข้ามบริษัท ทำให้ไม่ต้องดึงข้อมูลออกมาคำนวณในฝั่ง API แล้วส่งกลับเข้าไปใหม่
Graph Database ไม่ได้แค่เก็บข้อมูลเร็วขึ้น แต่เปลี่ยนคำถามที่ถามได้จาก "มีอะไรบ้าง" เป็น "อะไรกระทบอะไรบ้าง" ซึ่งเป็นคำถามที่เจ้าของธุรกิจต้องการคำตอบจริง ๆ
ชั้น AI: Local LLM ที่รันในบ้านตัวเอง
เราเลือกใช้ Typhoon (LLM ภาษาไทยจาก SCB 10X) ร่วมกับ Llama-3 รันบน GPU server ของเราเอง เหตุผลง่ายมาก — ข้อมูลราคาต้นทุน BOM และ Supplier list เป็นความลับทางการค้าระดับที่ส่งออกไป OpenAI ไม่ได้
การรัน LLM ในบ้านตัวเองมีต้นทุน upfront ที่สูงขึ้น (ต้องซื้อ GPU) แต่ระยะยาวถูกกว่าการจ่ายค่า API รายเดือน และสำคัญที่สุด — ลูกค้า Enterprise ที่เราจะไปขายต่อให้เขายอมจ่ายแพงขึ้นเพื่อระบบที่ "ข้อมูลไม่ออกจากประเทศ"
ชั้น Agent: Framework เฉพาะทาง 3 ตัว
แทนที่จะสร้าง "AI ตัวใหญ่ตัวเดียวที่ทำได้ทุกอย่าง" เราแยกเป็น specialist agent หลายตัวที่คุยกันได้ โดยเริ่มจาก 3 ตัวหลัก: Procurement Agent ดูแลการจัดซื้อและคาดการณ์สต็อก, Nudge Agent ตามงานและเตือนหัวหน้างานที่หน้างานจริง, และ Auditor Agent ตรวจสอบความผิดปกติในต้นทุนและเวลา
ชั้น Infrastructure: Docker + Coolify บน Private VPS
ทั้งหมดรันบน Docker container ที่จัดการด้วย Coolify (คิดให้ง่ายคือ Vercel แบบ self-host) โดย deploy บน VPS ของ OVH และ Hetzner ต้นทุนต่อเดือนต่ำกว่า AWS เท่าตัว และ control ได้เต็ม 100%
นวัตกรรม 3 จุดที่เปลี่ยนวิธีทำงานจริง
1. JIT 2.0: จัดซื้อแบบ Predictive ไม่ใช่ Reactive
JIT (Just-In-Time) แบบดั้งเดิมเป็นการ "ตั้งรับ" — รอให้ของใกล้หมดแล้วค่อยสั่ง ปัญหาคือถ้า Supplier ส่งช้า งานก็หยุด JIT 2.0 ในระบบของเราทำตรงข้าม — AI เห็นแผนผลิต 30 วันล่วงหน้า "ระเบิด BOM" ออกมาเป็นรายการวัสดุทั้งหมด แล้วสั่งของให้ถึงตรงเวลาที่ต้องใช้พอดี
ที่น่าตื่นเต้นคือการคำนวณ BOM ผ่าน Graph Database ทำให้ระบบรู้ว่าผนังพรีคาสท์ 1 แผ่นต้องใช้น็อตกี่ตัว เหล็กกี่เส้น ปูนกี่กิโลกรัม สั่งซื้อได้แม่นยำระดับมิลลิกรัม ลด waste ไปได้เยอะในเดือนแรกที่ทดสอบ
2. AI Assertiveness Levels: บริหารคนไทยด้วย "ระดับความดุ" ของ AI
นี่คือจุดที่ท้าทายที่สุดในการออกแบบ UX สำหรับคนไทย — AI ที่พูดตรงเกินไปจะทำให้พนักงานเสียหน้าและต่อต้านระบบ แต่ AI ที่นุ่มเกินไปก็ไม่มีพลังในการเร่งงานที่ล่าช้า
เราจึงออกแบบ 3 ระดับความดุให้เลือกใช้ตามบริบท: Level 1 Supportive ใช้ภาษาดอกไม้ ช่วยเหลือพนักงานใหม่; Level 2 Analyst เน้นตัวเลขและ KPI เหมาะกับหัวหน้างาน; Level 3 Stern Auditor ภาษาเด็ดขาด แจ้งเตือนเฉพาะตอนเกิดวิกฤตและยกระดับปัญหา (escalation) เมื่อความล่าช้ากระทบกำไร
ผู้บริหารสามารถสลับระดับตามจังหวะของงานได้ — สัปดาห์ไหนงานกำลังเร่ง เปิด Level 3 ให้ AI เป็นคนเตือน ตัวผู้บริหารเองไม่ต้องเป็นคนดุลูกน้อง ลดแรงปะทะในที่ทำงานไปได้มาก
ให้ AI เป็นคนเตือน ผู้บริหารจะได้เก็บพลังใจไว้ทำเรื่องที่สำคัญกว่า — การตั้งเป้าและสร้างวิสัยทัศน์
3. Generative UI: Command Center ที่ AI เจนหน้าจอเอง
แทนที่จะสร้างเมนูและ dashboard สำเร็จรูป 40 หน้า เราใช้ Command-based Interface ผู้บริหารพิมพ์หรือพูดสั่งได้เลย เช่น "ขอดูคอขวดของสัปดาห์นี้" → AI จะสร้าง widget สรุปจุดที่งานติดขัดขึ้นมาให้เดี๋ยวนั้น
แนวคิด Generative UI ตัดปัญหาคลาสสิกของ ERP ที่ผู้ใช้งง navigation หาเมนูไม่เจอ เพราะ UI ที่เห็นทุกครั้งถูกสร้างขึ้นมาเพื่อคำถามเฉพาะนั้น ไม่ใช่ฟอร์มตายตัวที่ต้องแปลความหมายเอง
Business Model: Sovereign AI Play + Vertical SaaS
เราไม่ได้สร้างระบบนี้เพื่อใช้ในบ้านอย่างเดียว — ปลายทางคือการ productize เป็น Vertical SaaS สำหรับอุตสาหกรรมก่อสร้าง โดยมีข้อได้เปรียบทางกลยุทธ์ 3 จุดหลัก
หนึ่ง Efficiency Arbitrage — การใช้ AI แทนธุรการและฝ่ายประสานงาน ทำให้โครงสร้างต้นทุนของเราต่ำกว่าคู่แข่งที่ยังใช้คนทำทั้งหมด สอง Sovereign AI Play — ขายความเชื่อใจให้ลูกค้า Enterprise ที่ไม่อยากให้ข้อมูลรั่วไปต่างประเทศ ซึ่งตอบโจทย์ PDPA และความกังวลด้าน geopolitical ยุคนี้
สาม Data Onboarding Breakthrough — ระบบ AI ที่อ่านไฟล์ Excel เละ ๆ ของลูกค้าเก่าแล้ว clean ข้อมูลเข้าระบบใหม่ได้ในเวลาไม่ถึงนาที เป็น friction ใหญ่ที่สุดที่ทำให้ ERP รายเดิมไม่ค่อยมีใครเปลี่ยน พอเราแก้จุดนี้ได้ ลูกค้า migrate มาหาเราได้ง่ายขึ้นมาก
สรุป: We Build the Intelligence that Builds the Future
โปรเจกต์ sme and me ไม่ได้แค่เปลี่ยนวิธีบริหาร Nature Group แต่กำลังพิสูจน์สมมติฐานใหญ่ — SME จากต่างจังหวัดของไทย (สกลนคร) สามารถเป็น Deep Tech Founder ที่สร้างมาตรฐานใหม่ระดับประเทศได้ ถ้าเลือก stack เทคโนโลยีถูกและกล้าลงแรงตั้งแต่ schema ระดับรากฐาน
ต่อจากนี้เราจะเลิกบริหารด้วยความรู้สึก เปลี่ยนมาใช้สิ่งที่ผมเรียกว่า Data-Driven Intuition — สัญชาตญาณที่ผ่านการ calibrate ด้วยข้อมูลจริง และสเกลธุรกิจจาก 100 ล้านไปสู่ 1,000 ล้าน โดยมี AI เป็นกระดูกสันหลัง ไม่ใช่พนักงานออฟฟิศเพิ่มขึ้นอีก 50 คน
ถ้าบทความนี้เข้าท่าสำหรับใคร ผมตั้งใจจะเขียนภาคถัดไปเจาะลึกทีละเรื่อง เริ่มจากการออกแบบ schema ของ BOM บน SurrealDB กับการ fine-tune Typhoon ให้พูดเหมือนหัวหน้าช่างมากกว่า AI — เพราะท้ายที่สุดแล้ว ระบบที่ดีคือระบบที่คนหน้างานอยากใช้ ไม่ใช่ถูกบังคับให้ใช้