การนำ IoT มาใช้ในโรงงาน 2026: แยกค่าใช้จ่าย 5 ชั้น และวิธีเริ่มติดตามเครื่องจักร

“เครื่องจักรหยุดจริงเกือบทุกวัน แต่ตัวเลขอัตราการเดินเครื่องในรายงานประจำเดือนก็ยังนิ่งอยู่ที่ราว 87% ทุกเดือน” ความรู้สึกขัดใจแบบนี้มักเป็นจุดเริ่มต้นที่ทำให้โรงงานญี่ปุ่นในไทยและ ASEAN เริ่มคิดเรื่องการนำ IoT มาใช้ในโรงงาน รายงานประจำวันยังเขียนด้วยมือ สาเหตุการหยุดเครื่องถูกสรุปเป็นบรรทัดเดียวว่า “เครื่องจักรมีปัญหา” ขณะที่สำนักงานใหญ่ถามหาหลักฐานเบื้องหลังตัวเลขอัตราการเดินเครื่อง และเมื่อขอใบเสนอราคา ตัวเลขก็กระจายกว้างมากจนไม่รู้ว่ากำลังจ่ายค่าอะไรเท่าไร

บทความนี้จะเรียงลำดับให้ชัดสามเรื่อง คือ (1) เส้นทางที่ใช้ได้จริงในการดึงข้อมูลการทำงานออกจากเครื่องจักรเดิมที่มีอยู่แล้ว (2) การแยกค่าใช้จ่ายออกเป็น 5 ชั้นเพื่ออ่านใบเสนอราคาให้เป็น และ (3) เงื่อนไขต้นทุนเฉพาะของฐานการผลิตในประเทศไทย ทั้งค่าแรง ค่าไฟ และสิทธิประโยชน์ทางภาษีตามเงื่อนไขที่ถูกต้องของปี 2026

อุปสรรคจริงของการนำ IoT มาใช้ในโรงงานคือ “วิธีดึงข้อมูลจากเครื่องจักรเดิม”

การพิจารณาโครงการ IoT มักเริ่มจากคำถามว่า “จะใช้คลาวด์ตัวไหน” หรือ “จะเลือกแดชบอร์ดโรงงานเจ้าไหน” แต่จุดที่โครงการหยุดชะงักจริงไม่ได้อยู่ที่นั่น มันหยุดตอนที่ทีมงานพยายามดึงสัญญาณออกจาก PLC ของเครื่องฉีดพลาสติกที่ติดตั้งมา 20 ปี แล้วพบว่าเครื่องนั้นไม่มีออปชันการสื่อสารติดมาตั้งแต่ต้น หรือหยุดตอนที่พบว่าสัญญาณไร้สายส่งไปไม่ถึงมุมนั้นของโรงงาน

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

ถ้าการเก็บข้อมูลถูกตัดขาดจากการตัดสินใจ โครงการจะล้มเหลว

บทวิเคราะห์ที่รวบรวมค่าใช้จ่ายและสาเหตุความล้มเหลวของการสร้างแพลตฟอร์มข้อมูล IoT ในตลาดญี่ปุ่นระบุรูปแบบความล้มเหลวไว้ 4 แบบ คือ การเก็บข้อมูลถูกตัดขาดจากการตัดสินใจ การไม่ดึงพนักงานหน้างานเข้ามาร่วม การข้ามขั้นตอนสำรวจสัญญาณเครือข่ายไร้สายก่อนออกแบบ และการผลักเรื่องความปลอดภัยไปทำทีหลัง (แหล่งข้อมูล: GXO) สามในสี่ข้อนี้ไม่เกี่ยวกับการเลือกคลาวด์หรือเลือกแดชบอร์ดเลย แปลว่าเป็นความล้มเหลวประเภทที่หลบไม่ได้ด้วยการทุ่มเวลาเลือกผลิตภัณฑ์

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

ลำดับที่ถูกต้องจึงเป็น “วิธีดึงข้อมูล → วิธีใช้ข้อมูล”

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

5 เส้นทางในการดึงข้อมูลจากเครื่องจักรเดิม: คำตอบที่ทำได้จริงของ retrofit IoT

การติดเซ็นเซอร์เพิ่มกับเครื่องจักรเดิม (retrofit) หรือการดึงข้อมูลเพิ่มโดยไม่เปลี่ยนเครื่อง สามารถจัดได้เป็น 5 เส้นทางใหญ่ ในโรงงานเดียวกัน เส้นทางที่เหมาะที่สุดของแต่ละเครื่องจะไม่เหมือนกัน ดังนั้นเคล็ดลับในทางปฏิบัติคือ อย่าตัดสินตายตัวว่า “ทุกเครื่องจะใช้วิธีเดียวกัน”

เส้นทางที่ 1: การเก็บข้อมูลจาก PLC โดยตรง

เส้นทางนี้ให้ปริมาณข้อมูลมากที่สุด และประเมินชั่วโมงงานได้ยากที่สุด รีจิสเตอร์ภายใน PLC ที่ควบคุมเครื่องจักรเก็บแทบทุกอย่างที่เราต้องการอยู่แล้ว ไม่ว่าจะเป็นสถานะเดินเครื่อง สถานะหยุด หมายเลขอลาร์ม รอบเวลา (cycle time) ตัวนับจำนวนผลิต และค่าตั้งต่าง ๆ ถ้าเครื่องมีออปชันการสื่อสารติดตั้งอยู่ ก็อ่านค่าออกมาผ่าน IoT gateway ได้ด้วยโปรโตคอลอุตสาหกรรมอย่าง Modbus TCP, PROFINET หรือ EtherNet/IP

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

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

เส้นทางที่ 2: ดึงจากไฟสัญญาณ (signal tower)

เครื่องจักรเดิมส่วนใหญ่มีไฟสัญญาณแบบซ้อนชั้นสีเขียว-เหลือง-แดงติดอยู่ เพียงติดเซ็นเซอร์แสงแบบไม่แตะต้องสายไฟ หรือวงจรตรวจจับแรงดัน เพิ่มเข้าไปที่สายชุดนี้ ก็ได้สถานะ 3 แบบคือ กำลังเดินเครื่อง / ต้องเฝ้าระวัง / หยุด โดยไม่ต้องแตะต้องตัวเครื่องจักรเลย

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

ในโรงงานที่มีสายการประกอบแบบหลายรุ่นปริมาณน้อย หรือมีเครื่องจักรใช้งานทั่วไปและเครื่องมือแบบใช้มือที่ไม่มี PLC อยู่มาก การเริ่มด้วยเส้นทางที่ 2 ให้ครบทุกเครื่องก่อน แล้วค่อยเจาะลึกด้วยเส้นทางที่ 1 เฉพาะเครื่องที่เห็นผลชัด เป็นการเดินแบบเป็นขั้นที่คุ้มค่าที่สุด

เส้นทางที่ 3: ติดเซ็นเซอร์เพิ่มจากภายนอกตัวเครื่อง

คือการติด หนีบ หรือวางเซ็นเซอร์ไว้ด้านนอกเครื่องจักร ชุดที่ใช้กันบ่อยมีดังนี้

• เซ็นเซอร์กระแสไฟแบบแคลมป์ (clamp-on CT): แค่หนีบเข้ากับสายเมนหรือสายกำลัง ก็ประเมินได้จากรูปคลื่นกระแสว่าเครื่องกำลังทำงาน เดินตัวเปล่า หรือหยุด ข้อดีใหญ่คือเริ่มระบบติดตามการทำงานของเครื่องจักรและการติดตามพลังงานไฟฟ้าได้พร้อมกันในครั้งเดียว
• เซ็นเซอร์วัดการสั่นสะเทือนและอุณหภูมิ: ติดที่มอเตอร์ ปั๊ม พัดลม และชุดเกียร์ทด เพื่อติดตามแนวโน้มการเสื่อมสภาพ เป็นประตูเข้าสู่การบำรุงรักษาเชิงคาดการณ์
• เซ็นเซอร์ตรวจจับวัตถุและเซ็นเซอร์แสง: ติดที่ทางออกชิ้นงานหรือบนสายพาน เพื่อนับจำนวนผลิตรวมทั้งของดีและของเสีย
• เซ็นเซอร์ความดันและอัตราการไหลของลม: จับปริมาณการใช้และการรั่วของลมอัด ซึ่งเชื่อมตรงไปที่การลดหน่วยการใช้พลังงานต่อชิ้น

เสน่ห์ของเส้นทางนี้คือใช้ได้ไม่ว่าเครื่องจักรจะรุ่นไหน ยี่ห้อไหน ผลิตที่ประเทศใด เครื่องจากยุค 1970 ก็ยังมีกระแสไฟไหลอยู่ ดังนั้นเซ็นเซอร์กระแสจะบอกอะไรเราได้เสมอ ส่วนจุดอ่อนคือค่าที่ได้เป็น “ค่าประเมินจากปรากฏการณ์ทางกายภาพ” จึงต้องมีช่วงเวลาวัดค่าจริงที่หน้างานเพื่อปรับค่าขีดแบ่ง (threshold) จะบอกว่ากระแสระดับไหนคือ “กำลังกัดชิ้นงาน” และระดับไหนคือ “เดินตัวเปล่า” ต้องเก็บข้อมูล 1-2 สัปดาห์ต่อเครื่องแล้วตัดสินเท่านั้น ถ้าลืมใส่ช่วงเวลานี้ลงในแผนงาน โครงการจะล่าช้าแน่นอน

เส้นทางที่ 4: ดึงทางอ้อมจากแผงควบคุม รีเลย์ และหน้าสัมผัสช่วย

เส้นทางนี้อยู่ตรงกลางระหว่างเส้นทางที่ 1 และ 2 คือการแยกสัญญาณหน้าสัมผัสของรีเลย์ช่วย โซลินอยด์วาล์ว ลิมิตสวิตช์ หรือวงจรหยุดฉุกเฉินที่อยู่ในตู้ควบคุมของเครื่องจักร ออกมาผ่านยูนิตอินพุตแบบแยกกราวด์ (isolated input) จุดแข็งคือไม่ต้องถอดรหัสโปรแกรม PLC ก็เลือกดึงเฉพาะสัญญาณที่มีความหมายชัดเจน เช่น “ปิดแม่พิมพ์เสร็จ” “นำชิ้นงานออกเสร็จ” “ประตูนิรภัยเปิด” ได้ตามจำนวนที่ต้องการ

ในโรงงานที่ประเทศไทย สายไฟที่ถูกเพิ่มเข้ามาทุกครั้งที่ปรับปรุงเครื่องจักรมักซ้อนทับกันอยู่ในตู้ควบคุม และมีไม่น้อยที่แบบวงจรกับของจริงไม่ตรงกัน ถ้าเลือกเส้นทางนี้ ควรเผื่อชั่วโมงงานไว้บนสมมติฐานว่าจะต้องวัดของจริงในตู้ร่วมกับช่างไฟฟ้าท้องถิ่นและปรับปรุงแบบวงจรไปพร้อมกัน มองอีกด้าน งานนี้ก็เป็นโอกาสดีที่จะตรวจนับสภาพจริงของตู้ควบคุมทั้งโรงงานเสียที

เส้นทางที่ 5: ให้คนป้อนข้อมูล (ออกแบบการป้อนมือไว้ตั้งแต่ต้น)

หลายคนอาจสงสัยว่า “ทำ IoT แล้วยังต้องป้อนมืออีกหรือ” แต่ในทางปฏิบัติเส้นทางนี้ขาดไม่ได้ สาเหตุการหยุดเครื่อง ลักษณะของเสีย เวลาเริ่มและเลิกการเปลี่ยนรุ่น ล็อตวัตถุดิบ และตัวผู้ปฏิบัติงาน ข้อมูลเหล่านี้ไม่มีทางออกมาจากเซ็นเซอร์ทางกายภาพได้เลย

สิ่งสำคัญคือต้องมองการป้อนมือเป็น “สิ่งที่ต้องออกแบบ” ไม่ใช่ “การยอมประนีประนอม” ในทางปฏิบัติให้แบ่งหน้าที่แบบนี้

• เวลา จำนวน และการเปลี่ยนสถานะ → ให้เครื่องเก็บ อย่าให้คนพิมพ์ ถ้าให้คนทำส่วนนี้ ความแม่นยำจะตกแน่นอน
• สาเหตุ การจัดประเภท และการวินิจฉัย → ให้คนเลือก อย่าให้พิมพ์เอง แต่ให้เลือกจากรหัสที่เตรียมไว้ล่วงหน้า 10-20 รหัส

หน้าจอบนแท็บเล็ตหรือเทอร์มินัลของระบบ Andon ต้องออกแบบบนสมมติฐานว่าแสดงเป็นภาษาไทย ลดจำนวนปุ่มให้น้อย และจบการกดหนึ่งครั้งได้ในไม่เกิน 3 วินาที ถ้าประนีประนอมกับจุดนี้ ผู้ปฏิบัติงานจะกด “รหัสบนสุดไปก่อน” ซ้ำ ๆ และข้อมูลทั้งชุดจะไร้ค่า

ตารางเปรียบเทียบ 5 เส้นทาง

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

การเก็บข้อมูลจาก PLC และการออกแบบโปรโตคอล: OPC UA, MQTT, Sparkplug B และ IoT gateway

เมื่อตัดสินใจเรื่องวิธีดึงข้อมูลได้แล้ว ขั้นถัดไปคือ “วิธีลำเลียงข้อมูล” การรู้โครงสร้างมาตรฐานของปี 2026 ไว้ก่อนช่วยลดความเสี่ยงที่จะต้องรื้อสร้างใหม่ในอีก 5 ปี

MQTT ทำหน้าที่ “ลำเลียง” ส่วน OPC UA ทำหน้าที่ “นิยามความหมาย”

การเปรียบเทียบโปรโตคอลของ IIoT สรุปตรงกันว่า MQTT และ OPC UA ไม่ใช่คู่แข่งกัน แต่ใช้ร่วมกันเป็นพื้นฐาน เพราะหน้าที่ต่างกัน MQTT เป็นโปรโตคอลสื่อสารแบบ publish/subscribe ที่เบาและเก่งเรื่องลำเลียงข้อมูลผ่านสายสัญญาณที่ไม่เสถียร ขณะที่ OPC UA เก่งเรื่องการใส่แบบจำลองข้อมูล (information model) ให้กับค่าที่ส่ง คือบอกได้ว่าค่านี้เป็นปริมาณอะไรของเครื่องจักรตัวไหน หน่วยคืออะไร

โครงสร้างมาตรฐานที่ใช้งานจริงในปี 2026 จึงเป็นสามชั้น คือ ใส่ความหมายที่ชั้นพื้นโรงงานด้วย OPC UA ลำเลียงขึ้นคลาวด์ด้วย MQTT และเชื่อมสองส่วนนี้ด้วย Sparkplug B (แหล่งข้อมูล: HiveMQ, FlowFuse) Sparkplug B คือข้อกำหนดที่วางกฎการตั้งชื่อ topic namespace การนิยามชนิดข้อมูล และการเฝ้าดูสถานะมีชีวิต/ตายของอุปกรณ์ ไว้บน MQTT การมีชั้นนี้ช่วยกันอุบัติเหตุคลาสสิกที่ว่า “ส่งข้อมูลมาถึงด้วย MQTT ได้ แต่ปลายทางอ่านไม่รู้ว่าค่านั้นหมายถึงอะไร”

PLC รุ่นเก่าที่ไม่รองรับ OPC UA ให้แปลงด้วย edge gateway

PLC ส่วนใหญ่ในโรงงานที่มีอยู่แล้วไม่รองรับ OPC UA คำตอบมาตรฐานในกรณีนี้คือ วาง edge gateway ที่รองรับ Modbus, PROFINET, EtherNet/IP (ในศัพท์ของ Sparkplug เรียกว่าโหนด Edge of Network) ไว้ฝั่งเครื่องจักร แล้วแปลงให้เป็นรูปแบบ OPC UA ก่อนส่งขึ้นชั้นบน พูดง่าย ๆ ว่าไม่ใช่การ “เปลี่ยน PLC เก่าให้เป็นของใหม่” แต่คือการ “วางกล่องล่ามหนึ่งกล่องไว้แปลภาษาของ PLC เก่า”

ผลของโครงสร้างนี้ปรากฏออกมาในรูปของการคุ้มครองเงินลงทุน เวลาเปลี่ยนเครื่องจักร สิ่งที่เปลี่ยนคือเฉพาะการเดินสายระหว่าง gateway กับเครื่องจักร ส่วนที่อยู่เหนือ gateway ทั้งหมด ได้แก่แพลตฟอร์มข้อมูล แดชบอร์ด รายงาน และการแจ้งเตือน ไม่ต้องสร้างใหม่เลย ในทางกลับกัน ถ้าตัด gateway ออกและให้เครื่องจักรส่งขึ้นคลาวด์ตรง ๆ ทุกครั้งที่เปลี่ยนเครื่องหนึ่งตัวก็จะเกิดงานพัฒนาฝั่งคลาวด์ตามมา

ใช้ Unified Namespace ลบความต่างระหว่างเครื่องเก่ากับเครื่องใหม่

การออกแบบที่ก้าวไปอีกขั้นคือการจัด Unified Namespace หรือระบบชื่อรวมศูนย์ แนวคิดคือกำหนดลำดับชั้นโรงงาน-สายการผลิต-เครื่องจักร-สัญญาณ ไว้ก่อน แล้วให้ข้อมูลทุกตัวไหลตามที่อยู่นั้น

เมื่อจัดเรียบร้อย เครื่องจักรใหม่ที่พูด OPC UA ได้เองตามธรรมชาติ และเครื่องจักรรุ่นเก่าที่ถูกบังคับให้พูดด้วย “เซ็นเซอร์ติดเพิ่ม + Modbus gateway” จะปรากฏต่อแพลตฟอร์มวิเคราะห์ในรูปของโครงสร้าง topic ชนิดข้อมูล หน่วยวัด และความละเอียดของ timestamp เดียวกัน อย่างไม่มีข้อแตกต่าง (แหล่งข้อมูล: iFactory) มองจากหน้างานเครื่องหนึ่งเป็นเครื่องรุ่นล่าสุด อีกเครื่องเป็นของอายุ 30 ปี แต่ตรรกะของแดชบอร์ดและการคำนวณ OEE จัดการทั้งสองเครื่องได้แบบเดียวกัน นี่คือกุญแจสำคัญที่ทำให้ retrofit ไม่จบลงแค่การ “แก้ขัดไปก่อน”

อย่าข้ามการสำรวจสัญญาณเครือข่ายไร้สาย

เหตุที่ “การข้ามขั้นตอนสำรวจเครือข่ายไร้สาย” ถูกจัดเป็นความล้มเหลวข้อที่สาม เพราะมันเกิดขึ้นบ่อยจริง ๆ อาคารโรงงานเป็นพื้นที่โหดสำหรับคลื่นวิทยุ เพราะรอบตัวเต็มไปด้วยเครื่องจักรโลหะ ชั้นวางโลหะ ฉากกั้นโลหะ ท่อน้ำ อินเวอร์เตอร์ และเครื่องเชื่อม Wi-Fi ที่ใช้ในสำนักงานได้ดีไม่มีปัญหา อาจเกิดการสูญหายของแพ็กเก็ตเฉพาะช่วงที่เครื่องปั๊มทำงาน ซึ่งเป็นเรื่องที่พบได้ทุกวัน

วิธีรับมือตรงไปตรงมา คือทำการสำรวจสัญญาณ (site survey) ก่อนออกแบบ และวัดทั้งขณะเครื่องจักรเดินและขณะหยุด นอกจากนี้ต้องให้ฝั่ง gateway มีบัฟเฟอร์ในเครื่อง (local buffer) ที่เก็บข้อมูลช่วงสัญญาณขาดไว้แล้วส่งต่อเมื่อกลับมาปกติ เอาแค่สองข้อนี้ก็กันปัญหาความน่าเชื่อถือพังทั้งระบบแบบที่ว่า “วันที่ข้อมูลหายไปคำนวณอัตราการเดินเครื่องไม่ได้” ได้แล้ว ส่วนเรื่องการแยกเซกเมนต์และการบริหารทรัพย์สินเมื่อเชื่อมเครือข่าย OT เข้ากับฝั่ง IT เราเรียบเรียงไว้ละเอียดในบทความมาตรการความปลอดภัย OT สำหรับโรงงาน

แยกค่าใช้จ่ายระบบ IoT โรงงานออกเป็น 5 ชั้น: รายละเอียดต้นทุนและโมเดลตามขนาด

คำถามว่า “การนำ IoT มาใช้ในโรงงานมีค่าใช้จ่ายเท่าไร” ตอบด้วยตัวเลขเดียวไม่ได้ แต่ถ้าเข้าใจว่าแบ่งเป็นชั้นแล้วจ่ายให้ชั้นไหนเท่าไร เราจะประเมินความสมเหตุสมผลของใบเสนอราคาได้ด้วยตัวเอง ส่วนนี้จะแยกเป็น 5 ชั้นโดยอ้างอิงข้อมูลราคาตลาดปี 2026

หมายเหตุสำคัญ: ตัวเลขเงินด้านล่างทั้งหมดเป็นราคาของตลาดญี่ปุ่น (ค่าอ้างอิงเรื่องระดับราคาและโครงสร้างต้นทุนของตลาดญี่ปุ่น) ในประเทศไทย ค่าจ้างวิศวกรท้องถิ่น ภาษีนำเข้าและค่าขนส่งอุปกรณ์ และชั่วโมงงานสำหรับรองรับสามภาษาไทย-ญี่ปุ่น-อังกฤษ ทำให้องค์ประกอบต้นทุนเปลี่ยนไป จึงไม่ควรนำมาทาบทับตรง ๆ ให้ใช้เป็นวัตถุดิบในการอ่าน “สัดส่วนของแต่ละชั้นและรายการย่อยภายในชั้น” เท่านั้น และเนื่องจากอัตราแลกเปลี่ยนผันผวน บทความนี้จึงไม่แปลงค่าเป็นเงินบาท

ชั้นที่ 1: เซ็นเซอร์และการดึงสัญญาณ (400,000-1,500,000 เยน)

คือชั้นที่ทำให้เส้นทางที่ 1-4 ในบทก่อนเกิดขึ้นจริงในทางกายภาพ รายละเอียดคือ ตัวเซ็นเซอร์ 100,000-500,000 เยน งานติดตั้งและเดินสาย 200,000-800,000 เยน และการทดสอบการทำงาน 100,000-200,000 เยน (แหล่งข้อมูล: GXO)

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

ชั้นที่ 2: Gateway และเครือข่าย (100,000-500,000 เยน)

ตัว IoT gateway ระดับอุตสาหกรรม 50,000-300,000 เยน และการตั้งค่าการสื่อสาร 50,000-200,000 เยน (แหล่งข้อมูล: GXO) เมื่อรวมชั้นที่ 1 กับชั้นที่ 2 เป็น “เซ็นเซอร์ + gateway” จะได้ช่วงราคา 500,000-2,000,000 เยน

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

ชั้นที่ 3: แพลตฟอร์มข้อมูล (คลาวด์หรือ on-premise, 2-8 ล้านเยน + ค่าบริการรายเดือน)

รายละเอียดของค่าก่อสร้างระบบครั้งแรกคือ การออกแบบและสร้างแพลตฟอร์ม 500,000-2,000,000 เยน การพัฒนาส่วนรับข้อมูลเข้า 500,000-2,000,000 เยน ตรรกะตรวจจับความผิดปกติ 500,000-2,000,000 เยน การออกแบบความปลอดภัย 300,000-1,000,000 เยน และการทดสอบกับเอกสาร 200,000-1,000,000 เยน นอกจากนี้ยังมีค่าบริการรายเดือน 10,000-100,000 เยน (แหล่งข้อมูล: GXO)

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

ชั้นที่ 4: การพัฒนาหน้าจอและการแจ้งเตือน (1-5 ล้านเยน)

รายละเอียดค่าพัฒนาแดชบอร์ดโรงงานคือ การออกแบบ UI/UX 200,000-800,000 เยน การพัฒนาหน้าจอ 500,000-2,500,000 เยน ฟังก์ชันรายงาน 200,000-800,000 เยน การจัดการสิทธิ์ผู้ใช้ 100,000-400,000 เยน และการรองรับหลายอุปกรณ์ 100,000-500,000 เยน (แหล่งข้อมูล: GXO) หากบวกขั้นต่ำของรายการย่อยจะได้ 1.1 ล้านเยน ซึ่งแหล่งข้อมูลปัดลงและระบุช่วงของชั้นนี้ไว้ที่ 1-5 ล้านเยน

รูปแบบคลาสสิกที่ทำให้ค่าใช้จ่ายส่วนนี้บวมคือการ “ทำทุกความต้องการของทุกแผนกให้เป็นหน้าจอ” ถ้าไล่ทำหน้าจอสำหรับผู้จัดการโรงงาน ผู้จัดการฝ่ายผลิต ฝ่ายคุณภาพ ฝ่ายซ่อมบำรุง ฝ่ายบริหาร และสำนักงานใหญ่ จำนวนหน้าจอเกิน 20 หน้าได้ง่าย ๆ ตามที่จะกล่าวในบทหลัง คำตอบที่ดีที่สุดในทางปฏิบัติคือจำกัดหน้าจอไว้ 4 ระดับตามบทบาท (หน้างาน / หัวหน้าแผนก / ผู้จัดการโรงงาน / ผู้บริหาร) เท่านั้น

ชั้นที่ 5: การดำเนินงาน (จัดข้อมูลหลัก ออกแบบรหัสสาเหตุ อบรมหน้างาน) = แยกเป็นค่าดำเนินงานรายปี

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

ตรงนี้มีข้อจัดระเบียบที่สำคัญมากทั้งในทางบัญชีและในทางการตัดสินใจ ให้บริหารชั้นที่ 5 เป็นค่าดำเนินงานรายปีแยกกรอบออกมา ไม่ใช่รวมเข้าไปในยอดเงินลงทุนเริ่มต้น เหตุผลคือเพื่อเลี่ยงการนับซ้ำ เนื้อหาหลักของชั้นที่ 5 คือชั่วโมงงานของพนักงานภายในบริษัทเอง ถ้าเอาไปบวกในยอดเงินลงทุนเริ่มต้นแล้วยังนำไปหักเป็นค่าดำเนินงานรายปีในการคำนวณ ROI อีก ก็เท่ากับนับต้นทุนก้อนเดียวกันสองครั้ง ดังนั้นช่อง “เงินลงทุนเริ่มต้น” ในตารางค่าใช้จ่ายให้ใส่เฉพาะชั้นที่ 1 ถึงชั้นที่ 4 ส่วนชั้นที่ 5 ให้ไปอยู่ในช่อง “ค่าดำเนินงานรายปี” พร้อมกับค่าบริการรายเดือนของผู้ให้บริการภายนอก (10,000-100,000 เยน/เดือน = 120,000-1,200,000 เยน/ปี)

สำหรับมูลค่าเงินของชั่วโมงงานภายในบริษัท บทความนี้ไม่ระบุจำนวนเงิน เพราะไม่มีข้อมูลราคาตลาดที่เผยแพร่ไว้ ให้คำนวณจากค่าแรงต่อชั่วโมง-คนของบริษัทท่านคูณกับชั่วโมงงานที่คาด ส่วนความรู้สึกเรื่องปริมาณงานโดยทั่วไปคือ ช่วงเริ่มระบบ ผู้รับผิดชอบ 1 คนจะใช้เวลาราว 30-50% ของงานทั้งหมดไปกับการจัดข้อมูลหลักและทบทวนรหัสสาเหตุ และหลังจากระบบเข้าที่แล้วจะเหลือประมาณไม่กี่วันต่อเดือน

ยอดเงินลงทุนเริ่มต้นรวมและโมเดลตามขนาด

ช่วงเงินลงทุนเริ่มต้นเมื่อรวมชั้นที่ 1 ถึง 4 คือ 3.5-15 ล้านเยน (0.5-2 ล้าน + 2-8 ล้าน + 1-5 ล้าน = 3.5-15 ล้าน) และมีการนำเสนอโมเดลตัวอย่างตามขนาดไว้ 3 แบบ (แหล่งข้อมูล: GXO)

ตารางนี้คุ้มค่าที่จะหารตัวเลขตรวจสอบด้วยตัวเอง 5 เครื่อง 3 ล้านเยน เท่ากับ 600,000 เยนต่อเครื่อง ส่วน 30 เครื่อง 11 ล้านเยน เท่ากับราว 367,000 เยนต่อเครื่อง จำนวนเครื่องเพิ่มขึ้น 6 เท่า แต่เงินลงทุนเพิ่มขึ้นเพียงราว 3.7 เท่า และราคาต่อเครื่องลดลงประมาณ 39% เพราะชั้นที่ 3 และชั้นที่ 4 เป็น “แพลตฟอร์มร่วม” ที่แทบไม่แปรผันตามจำนวนเครื่อง ข้อสรุปเชิงปฏิบัติที่ได้จากโครงสร้างนี้ชัดเจน คือ ถ้าตัดสินใจจะสร้างแพลตฟอร์มแล้ว การไม่จำกัดจำนวนเครื่องเป้าหมายให้แคบเกินไปจะทำให้ราคาต่อเครื่องถูกลง แต่ตามที่จะกล่าวต่อไป เฟสแรกควรจำกัดขอบเขตเพื่อเรียนรู้ ดังนั้นคำตอบที่ดีที่สุดจึงเป็น “ออกแบบแพลตฟอร์มโดยเผื่อจำนวนเครื่องทั้งหมดในอนาคต แล้วเพิ่มจำนวนการเชื่อมต่อแบบเป็นขั้น”

ทั้งนี้ ตัวเลขราว 20 ล้านเยนของกรณีทั่วทั้งโรงงานสูงเกินเพดานของช่วง 3.5-15 ล้านเยนที่กล่าวไว้ก่อนหน้า นี่ไม่ใช่ความขัดแย้งกันเอง เพราะช่วงดังกล่าวตั้งอยู่บนสมมติฐานของกรณีทั่วไประดับสายการผลิตหรือการติดตั้งบางส่วน เมื่อขยายเป้าหมายเป็นทั้งโรงงานในครั้งเดียว ชั้นที่ 1 และชั้นที่ 4 จะพอกขึ้นและทำให้ยอดทะลุเพดาน เวลาเทียบใบเสนอราคา ต้องตรวจสอบเสมอว่า “ช่วงราคานั้นตั้งอยู่บนขอบเขตการติดตั้งเท่าใด”

ระดับราคาของกรณีเริ่มจากขนาดเล็ก

ถ้าขอบเขตเป็นแบบ “เอาแค่สายการผลิตเดียวก่อน” หรือ “เอาแค่อุณหภูมิความชื้นในคลังก่อน” ตัวเลขจะเล็กลงหนึ่งหลัก มีการนำเสนอระดับราคาไว้ว่า การเฝ้าระวังอุณหภูมิและความชื้น 300,000-800,000 เยน ระบบติดตามการทำงานของเครื่องจักรพร้อมฟังก์ชันแจ้งเตือน 800,000-2,000,000 เยน และค่ารายเดือนหลักพันถึงหลักหมื่นเยน (แหล่งข้อมูล: is-prime, OPTiM) ระดับราคานี้เป็นไปได้เพราะใช้บริการคลาวด์สำเร็จรูปและยอมสละการปรับแต่งหน้าจอ

เกณฑ์ตัดสินคือ “มีเจตนาจะขยายไปสายอื่นต่อหรือไม่” ถ้าจบที่สายเดียว บริการสำเร็จรูปก็เพียงพอ แต่ถ้าคิดจะขยายทั้งโรงงานภายใน 3 ปี อย่างน้อย gateway ในชั้นที่ 2 และโครงสร้างข้อมูลควรเลือกโดยมองอนาคตไว้ด้วย

ขั้นตอนและระยะเวลาการติดตั้ง: แนวทาง 8-12 เดือนและรูปแบบความล้มเหลว 4 แบบ

ระยะเวลาของการนำ IoT มาใช้ในโรงงานมีการระบุเป็นแนวทางมาตรฐานไว้ที่ 8-12 เดือน แบ่งเป็น 5 ขั้นตอน (แหล่งข้อมูล: GXO) รายละเอียดดังนี้

1. จัดระเบียบความต้องการ: 2-4 สัปดาห์ — ตัดสินว่าต้องการปรับปรุงการตัดสินใจเรื่องใด แล้วย้อนคำนวณกลับมาว่าต้องเก็บข้อมูลรายการใด
2. PoC (การทดลองพิสูจน์): 1-2 เดือน — เก็บข้อมูลจริงกับเครื่องจักร 1-3 เครื่อง แล้ววัดความแม่นยำและชั่วโมงงานที่ใช้จริง
3. ออกแบบและพัฒนา: 2-4 เดือน — สร้างแพลตฟอร์มข้อมูลและหน้าจอ
4. ขยายและอบรม: 1-2 เดือน — ขยายไปเครื่องจักรเป้าหมาย และอบรมผู้ปฏิบัติงานกับผู้บริหารระดับต้น
5. ทำให้เสถียร: 3 เดือนขึ้นไป — ยกระดับความแม่นยำของข้อมูลและทำให้กฎการใช้งานฝังตัว

ขั้นตอนที่ถูกข้ามมากที่สุดในแผนนี้คือขั้นที่ 5 แต่ที่หน้างาน นี่คือสนามจริง รหัสสาเหตุการหยุดเครื่องที่ออกแบบรอบแรกจะใช้งานยากทุกครั้ง และต้องผ่านการทบทวน 2-3 รอบกว่าหน้างานจะเลือกได้ถูกต้อง ถ้าเข้าใจผิดว่าขั้นที่ 5 เป็น “เวลาสำรอง” แล้วตัดออกจากแผนงาน ระบบจะเริ่มใช้จริงโดยที่ความแม่นยำของข้อมูลยังไม่ขึ้น และจะจบลงในทางที่แย่ที่สุด คือ “ตัวเลขเชื่อถือไม่ได้ เลยไม่ดู”

รูปแบบความล้มเหลว 4 แบบและวิธีเลี่ยงที่เป็นรูปธรรม

① การเก็บข้อมูลถูกตัดขาดจากการตัดสินใจ วิธีเลี่ยงคือ ในขั้นจัดระเบียบความต้องการ ให้เขียนลงกระดาษแผ่นเดียวว่า “ใคร เมื่อไร ดูอะไร เพื่อตัดสินใจอะไร” ตัวอย่างเช่น “หัวหน้าแผนกผลิตดูเครื่องจักร 3 อันดับที่หยุดนานที่สุดของเมื่อวาน ทุกเช้า 8:00 น. เพื่อกำหนดลำดับความสำคัญของงานซ่อมบำรุงในวันนั้น” ข้อมูลรายการใดที่เขียนประโยคแบบนี้ไม่ได้ ในเฟสแรกอาจตัดสินใจไม่เก็บก็ได้

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

③ การข้ามขั้นตอนสำรวจเครือข่ายไร้สาย วิธีเลี่ยงเป็นไปตามบทก่อน คือสำรวจสัญญาณขณะเครื่องจักรเดินจริง และให้ gateway มีบัฟเฟอร์ในเครื่อง

④ การผลักเรื่องความปลอดภัยไปทำทีหลัง วิธีเลี่ยงคือ ในขั้นทำใบเสนอราคาของชั้นที่ 3 ต้องคงรายการออกแบบความปลอดภัยไว้เสมอ (300,000-1,000,000 เยนรวมอยู่ในรายการย่อยแล้ว) ต้นทุนการกลับไปรื้อทำการแบ่งเซกเมนต์เครือข่ายใหม่ในภายหลัง สูงกว่าต้นทุนการออกแบบตั้งแต่ต้นอย่างมาก

การมองเห็นข้อมูลในโรงงานและ OEE ประสิทธิผลโดยรวมของเครื่องจักร: เชื่อมข้อมูลไปสู่การตัดสินใจของใคร

จากนี้เข้าสู่ครึ่งหลัง คือ “วิธีใช้ข้อมูล” สิ่งแรกที่โรงงานซึ่งเก็บผลการเดินเครื่องได้แล้วควรทำ คือทำให้คำนิยามของตัวชี้วัดตรงกันทั้งองค์กร

ปัญหาที่คำว่า “อัตราการเดินเครื่อง” ถูกใช้ใน 3 ความหมายภายในบริษัทเดียวกัน

ในหลายโรงงาน คำว่าอัตราการเดินเครื่องคำเดียวถูกใช้ปนกันเพื่อหมายถึงสามสิ่งนี้

• ค่าความพร้อมใช้งาน (Availability): สัดส่วนของเวลาที่เครื่องจักรเดินจริง เทียบกับเวลาที่วางแผนให้ผลิต (ใช้ดูการสูญเสียจากการหยุดเครื่อง)
• ประสิทธิภาพการเดินเครื่อง (Performance): สัดส่วนที่ผลิตได้ตามรอบเวลาทางทฤษฎี เทียบกับเวลาที่เครื่องเดิน (ใช้ดูความเร็วที่ตกและการหยุดสั้น)
• อัตราของดี (Quality): สัดส่วนของงานดี เทียบกับจำนวนที่ผลิตทั้งหมด (ใช้ดูการสูญเสียจากของเสีย)

และผลคูณของสามตัวนี้คือ OEE ประสิทธิผลโดยรวมของเครื่องจักร

OEE = ค่าความพร้อมใช้งาน × ประสิทธิภาพการเดินเครื่อง × อัตราของดี

เพียงแบ่งสูตรนี้ให้ทุกฝ่ายเข้าใจร่วมกัน คุณภาพของรายงานจะเปลี่ยนไป การรายงานว่า “อัตราการเดินเครื่อง 87%” มีความหมายต่างกันสิ้นเชิงระหว่างการหมายถึงค่าความพร้อมใช้งานเพียงตัวเดียว กับการหมายถึง OEE ตัวอย่างเช่น เครื่องจักรที่มีค่าความพร้อมใช้งาน 95% ประสิทธิภาพการเดินเครื่อง 85% และอัตราของดี 97% จะมี OEE เท่ากับ 0.95 × 0.85 × 0.97 = ราว 78% ทั้งสามตัวดูเหมือน “พอใช้ได้” แต่ประสิทธิผลโดยรวมต่ำกว่า 80% นี่คือเหตุผลใหญ่ที่สุดที่ต้องใช้ OEE คือ มันทำให้เห็นผลคูณของการสูญเสียที่ตัวชี้วัดเดี่ยวมองไม่เห็น

ใครดูตัวชี้วัดอะไร

เมื่อนิยามตัวชี้วัดแล้ว ขั้นต่อไปคือการจัดสรร ในทางปฏิบัติการจับคู่แบบนี้ใช้งานได้

ความหมายของตารางนี้คือ “สร้างหน้าจอที่ต่างกัน 4 แบบจากข้อมูลชุดเดียวกัน” และในทางกลับกัน โดยหลักแล้วไม่จำเป็นต้องมีหน้าจอเกินกว่านี้ เราแนะนำให้กำหนด 4 กลุ่มนี้ (หน้างาน / หัวหน้าแผนก / ผู้จัดการโรงงาน / ผู้บริหาร) ไว้ก่อน เพื่อเป็นเบรกในทางปฏิบัติที่กันไม่ให้ค่าใช้จ่ายของชั้นที่ 4 บวมขึ้น

เมื่ออัตราการเดินเครื่องสูงขึ้น อะไรที่เพิ่มขึ้น

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

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

การมองเห็นเครื่องจักรหยุดสั้นและการวิเคราะห์สาเหตุการหยุดเครื่อง: การออกแบบระบบ Andon และแดชบอร์ด

สิ่งที่ทำให้โรงงานซึ่งติดตั้งระบบติดตามการทำงานของเครื่องจักรตกใจที่สุด มักเป็นภาพจริงของเครื่องจักรหยุดสั้น

ทำไมการหยุดสั้นไม่ปรากฏในรายงานประจำวัน

เครื่องจักรหยุดสั้น (chokotei) คือการหยุดช่วงสั้นระดับไม่กี่สิบวินาทีถึงไม่กี่นาทีแล้วกลับมาเดินได้ ด้วยลักษณะของมันเอง มันจึงไม่ถูกเขียนลงในรายงานประจำวัน ผู้ปฏิบัติงานแก้ชิ้นงานที่ติด กดรีเซ็ต แล้วกลับไปผลิตต่อ เพราะนั่นเป็นงานที่เกิดขึ้นเป็นปกติจนไม่ถูกรับรู้ว่าเป็น “ปัญหา” ผลคือมันไม่ปรากฏในเวลาหยุดตามรายงาน แต่ทับถมขึ้นหลายสิบครั้งต่อวัน ถ้าการหยุดครั้งละ 2 นาทีเกิดขึ้น 30 ครั้งต่อวัน ก็เท่ากับ 60 นาที และเดินเครื่อง 20 วันต่อเดือนก็เท่ากับ 20 ชั่วโมง เวลา 20 ชั่วโมงนี้ไม่ปรากฏในรายงานฉบับใดเลย

สิ่งที่ต้องมีเพื่อทำให้เห็นการหยุดสั้นคือ การบันทึกเวลาที่ไม่พึ่งพาความจำของคน ถ้ามีเส้นทางที่ 1 (สัญญาณอลาร์มและสัญญาณเดินเครื่องของ PLC) เส้นทางที่ 2 (การเปลี่ยนสถานะติดของไฟสัญญาณ) หรือเส้นทางที่ 3 (การตกของรูปคลื่นกระแสและการค้างของตัวนับจำนวนผลิต) อย่างใดอย่างหนึ่งตามที่กล่าวในครึ่งแรก ก็บันทึกอัตโนมัติได้ในระดับวินาที เฉพาะอย่างยิ่งการตัดสินแบบเส้นทางที่ 3 ที่ว่า “ตัวนับไม่เพิ่มขึ้นแม้เลยรอบเวลาทางทฤษฎีไปแล้ว” เป็นวิธีที่ใช้ได้ทั่วไปมาก เพราะตรวจจับการหยุดสั้นได้แม้ในเครื่องจักรที่ไม่มีสัญญาณให้ดึง

การออกแบบรหัสสาเหตุการหยุดเครื่องเป็นตัวกำหนดคุณภาพของการวิเคราะห์

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

1. จำกัดจำนวนไว้ 10-20 รหัส ไม่มีใครเลือกได้ถูกจากตารางรหัส 50 รายการ
2. ลำดับชั้นไม่เกิน 2 ระดับ (หมวดใหญ่ 6-8 รายการ × หมวดย่อย 2-4 รายการ) ถ้าทำเป็น 3 ระดับ เวลาป้อนจะยาวขึ้นและหน้างานจะเลิกใช้
3. เฝ้าดูสัดส่วนของ “อื่น ๆ” ถ้า “อื่น ๆ” เกิน 15% แปลว่าออกแบบระบบรหัสผิด และเป็นสัญญาณว่าต้องทบทวน
4. อย่ารวมสิ่งที่ผู้รับผิดชอบแก้ไขต่างกันไว้ในรหัสเดียวกัน ถ้ายัด “รอวัตถุดิบ” (โจทย์ของฝ่ายจัดซื้อและวางแผนการผลิต) กับ “แม่พิมพ์มีปัญหา” (โจทย์ของฝ่ายซ่อมบำรุง) ไว้ในรหัส “เกี่ยวกับการเปลี่ยนรุ่น” เดียวกัน จะไม่มีใครขับเคลื่อนอะไรได้จากผลการวิเคราะห์

เมื่อได้ระบบรหัสที่ยึดหลัก 4 ข้อนี้ เพียงดูเวลาหยุดผ่านแผนภูมิพาเรโต (กราฟแท่งเรียงจากมากไปน้อย) ก็เห็นได้ทันทีว่าพรุ่งนี้ต้องลงมือกับเรื่องอะไร ในทางกลับกัน ถ้าไม่ยึดหลัก สิ่งที่ได้จะเป็นแค่กราฟที่ไม่บอกอะไรเลยแบบ “เครื่องจักรมีปัญหา 62%”

ระบบ Andon กับแดชบอร์ด แยกกันตามคนที่ดูและตามแกนเวลา

ในการออกแบบหน้าจอสำหรับการติดตามแบบเรียลไทม์ สิ่งสำคัญคือไม่สับสนระหว่าง ระบบ Andon กับ แดชบอร์ด

ระบบ Andon คือ “การแสดงผลเพื่อให้คนขยับตัวเดี๋ยวนี้” เป็นจอขนาดใหญ่หรือไฟแสดงสถานะที่มองเห็นได้จากด้านบนของสายการผลิตหรือจากทางเดิน และต้องลดปริมาณข้อมูลให้น้อยอย่างสุดขั้ว คือบอกเพียงว่าเครื่องจักรตัวไหนกำลังหยุดอยู่ เท่านั้น ข้อกำหนดคือเข้าใจได้ในพริบตาด้วยสีและตำแหน่ง ถ้ายัดตัวเลขและกราฟเข้าไป มันก็ล้มเหลวในฐานะ Andon แล้ว เกณฑ์ตัดสินคืออ่านรู้เรื่องหรือไม่ ในระยะห่าง 5 เมตร ภายใน 3 วินาที

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

และระหว่างสองสิ่งนี้ให้วาง การแจ้งเตือน (alert) ไว้ คือการติดต่อเชิงรุกที่อ้างอิงค่าขีดแบ่ง เช่น “ถ้าเครื่องจักรตัวเดียวกันหยุดเกิน 15 นาที ให้แจ้งไปที่สมาร์ตโฟนของหัวหน้ากะ” หรือ “ถ้ามีการเลือกรหัสอื่น ๆ เกิน 20 ครั้งต่อวัน ให้แจ้งผู้ดูแลระบบ” สิ่งเดียวที่ต้องระวังในการออกแบบการแจ้งเตือนคือ ถ้าดังมากเกินไป คนจะเมินเฉย สูตรสำเร็จคือตั้งค่าเริ่มต้นให้ทื่อไว้โดยเจตนา (ตั้งค่าขีดแบ่งไว้สูง) แล้วค่อย ๆ เพิ่มความไวขึ้นตามการใช้งานจริง

กลไกที่ทำให้ระบบการมองเห็นข้อมูลฝังตัวอยู่ในโรงงานได้

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

• ประชุมเช้า (10 นาที): ตรวจสอบร่วมกันทั้งทีมถึง 3 อันดับเวลาหยุดสูงสุดของเมื่อวาน และสัดส่วนของ “อื่น ๆ”
• รายสัปดาห์ (30 นาที): ตรวจความคืบหน้าของมาตรการต่ออันดับ 1 ในแผนภูมิพาเรโต แล้วกำหนดอันดับ 1 ตัวถัดไป
• รายเดือน: รายงานแนวโน้ม OEE และแปลงเวลาเดินเครื่องที่เพิ่มขึ้นจากการปรับปรุงให้เป็นมูลค่าเงิน

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

แนวคิดเรื่อง ROI: มูลค่าความสูญเสียต่อการหยุด 1 ชั่วโมงต้องคำนวณด้วยตัวเลขของบริษัทเอง

สิ่งที่จำเป็นต่อการตัดสินใจลงทุนไม่ใช่ค่าเฉลี่ยของอุตสาหกรรม แต่เป็นตัวเลขของบริษัทตัวเอง บทนี้จะจัดตำแหน่งของข้อมูลต่างประเทศที่เผยแพร่อยู่ให้ชัด แล้วเสนอสูตรสำหรับคำนวณด้วยตัวเอง

อย่านำค่าเฉลี่ยจากต่างประเทศมาทาบทับตรง ๆ

ข้อมูลปี 2026 เกี่ยวกับต้นทุนของการหยุดเครื่องนอกแผน รายงานว่าต้นทุนเฉลี่ยของการหยุดนอกแผนในอุตสาหกรรมการผลิตอยู่ที่ ราว 260,000 ดอลลาร์สหรัฐต่อชั่วโมง แต่เอกสารเดียวกันก็แสดงด้วยว่าการกระจายของตัวเลขกว้างมาก การผลิตแบบชิ้นงานแยก (discrete) อยู่ที่ 10,000-50,000 ดอลลาร์ต่อชั่วโมง ส่วนโรงงานยานยนต์สูงสุดถึง 2.3 ล้านดอลลาร์ต่อชั่วโมง (แหล่งข้อมูล: ReliaMag, Manufacturing Lead Generation)

เมื่อวางตัวเลขสามตัวนี้เรียงกัน จะเห็นธรรมชาติของค่าเฉลี่ย 260,000 ดอลลาร์ชัดขึ้น คือ ค่าเฉลี่ยถูกดึงอย่างแรงโดยความสูญเสียมหาศาลของอุตสาหกรรมยานยนต์และอุตสาหกรรมกระบวนการต่อเนื่อง ขณะที่ค่าที่สมจริงสำหรับการผลิตแบบชิ้นงานแยก ซึ่งเป็นกลุ่มที่ฐานการผลิตญี่ปุ่นใน ASEAN ส่วนใหญ่สังกัดอยู่ น่าจะอยู่ในช่วง 10,000-50,000 ดอลลาร์ และมักเอียงไปทางขอบล่างของช่วงนั้น ถ้าคัดลอกเลข 260,000 ดอลลาร์ลงในเอกสารขออนุมัติของบริษัทตัวเอง จะมีความเสี่ยงประเมินมูลค่าผลประโยชน์สูงเกินไปหนึ่งหลัก

เช่นเดียวกัน ค่าที่รวบรวมไว้ว่าการบำรุงรักษาเชิงคาดการณ์ด้วย IoT ลดการหยุดนอกแผนได้ 35-50% และยกระดับ OEE ได้ 20-25% ค่าที่ระบุว่าโรงงานซึ่งการเฝ้าติดตามสภาพเครื่องจักรพัฒนาเต็มที่แล้วลดการเสียหายฉับพลันได้ 70-75% รวมทั้งค่าประเมินที่ว่าต้นทุนการติดตั้งเซ็นเซอร์ IoT อยู่ที่ 2,000-8,000 ดอลลาร์ต่อทรัพย์สินหนึ่งรายการ ความเสียหายที่ป้องกันได้อยู่ในระดับ 50,000-500,000 ดอลลาร์ และ ROI อยู่ที่ 12-24 เดือน — ทั้งหมดนี้เป็นการรวบรวมและการประเมินโดยผู้ให้บริการและสื่ออุตสาหกรรม (แหล่งข้อมูล: ReliaMag, L2L) ใช้อ้างอิงเพื่อดูทิศทางได้ แต่ในฐานะตัวเลขรองรับการขออนุมัติ ต้องแทนที่ด้วยค่าที่วัดจริงในบริษัทตัวเอง

สูตรคำนวณ “มูลค่าความสูญเสียต่อการหยุด 1 ชั่วโมง” ของบริษัทตัวเอง

ความสูญเสียจากการหยุด 1 ชั่วโมง คำนวณเป็นผลรวมของ 3 องค์ประกอบ

มูลค่าความสูญเสียต่อการหยุด 1 ชั่วโมง = ① กำไรที่เสียไป + ② ค่าใช้จ่ายคงที่ที่ยังไหลออกระหว่างหยุด + ③ ต้นทุนเพิ่มเติมจากการกู้คืน

① กำไรที่เสียไป = จำนวนงานดีที่ผลิตได้ต่อชั่วโมง × กำไรส่วนเพิ่มต่อชิ้น (= ราคาขาย − ต้นทุนผันแปร)
② ค่าใช้จ่ายคงที่ = จำนวนคนที่ประจำอยู่ที่สายนั้น × ค่าแรงต่อชั่วโมง-คน + ค่าไฟที่ยังใช้ระหว่างหยุด + ค่าเสื่อมราคาของเครื่องจักรต่อชั่วโมง
③ ต้นทุนเพิ่มเติม = ค่าล่วงเวลาเพื่อไล่งานคืน ค่าขนส่งเที่ยวพิเศษหรือทางอากาศ งานระหว่างทำที่ต้องทิ้ง และความเสียหายของแม่พิมพ์กับอุปกรณ์จับยึด

มีข้อควรระวังสำคัญหนึ่งข้อ ① กำไรที่เสียไป ลงบัญชีได้เฉพาะกรณีที่ผลผลิตส่วนที่เพิ่มขึ้นขายได้ ในสถานการณ์ที่คำสั่งซื้อมีเพดาน การกู้เวลาหยุดคืนมาจะนำไปสู่การลด ② เท่านั้น คือ “ค่าล่วงเวลาของวันนั้นหายไป” ถ้าบวก ① เข้าไปโดยไม่มีเงื่อนไข จะประเมินมูลค่าผลประโยชน์สูงเกินจริง ในเอกสารขออนุมัติ การเขียนแยกสองแนวทาง คือ “มูลค่าผลประโยชน์บนสมมติฐานว่ามีอุปสงค์รองรับ” และ “มูลค่าผลประโยชน์ในกรณีที่อุปสงค์ไม่โต” เป็นวิธีที่ตรงไปตรงมา และในทางปฏิบัติก็ได้รับอนุมัติง่ายกว่าด้วย

เลี่ยงการนับซ้ำในการคำนวณระยะเวลาคืนทุน

ระยะเวลาคืนทุนคำนวณด้วยสูตรนี้

ระยะเวลาคืนทุน (ปี) = เงินลงทุนเริ่มต้น (ผลรวมชั้นที่ 1-4) ÷ (มูลค่าผลประโยชน์รายปี − ค่าดำเนินงานรายปี (ชั้นที่ 5))

จุดสำคัญคือหักค่าดำเนินงานรายปีออกจากตัวส่วน และตามที่กล่าวไว้ก่อนหน้า ห้ามบวกชั้นที่ 5 เข้าไปในเงินลงทุนเริ่มต้น (ตัวเศษ) แล้วยังหักออกจากตัวส่วนอีก เพราะเป็นการนับต้นทุนก้อนเดียวกันซ้ำสองครั้ง ให้จำว่าชั้นที่ 5 ปรากฏเฉพาะฝั่งตัวส่วนเท่านั้น

เพื่อการอ้างอิง โมเดลตัวอย่างที่เผยแพร่ไว้ระบุว่า “เครื่องจักร 5 เครื่อง เงินลงทุนเริ่มต้นราว 3 ล้านเยน โดยตั้งสมมติฐานว่าหลีกเลี่ยงความสูญเสียได้ปีละ 1.5 ล้านเยน คืนทุนใน 2 ปี” (3 ล้านเยน ÷ 1.5 ล้านเยน = 2 ปี) นี่เป็นการคำนวณคืนทุนแบบง่ายที่ไม่หักค่าดำเนินงานรายปี ถ้าหักค่าดำเนินงานรายปีตามสูตรข้างต้น ระยะเวลาคืนทุนจะยาวกว่านี้ ในเอกสารขออนุมัติของบริษัทท่าน การเขียนด้วยจำนวนปีหลังหักค่าดำเนินงานแล้ว จะช่วยให้ไม่ถูกต่อว่าภายหลังว่า “ผลไม่ออกตามที่ว่าไว้”

เมื่อคำนวณด้วยค่าแรงต่อชั่วโมง-คนของประเทศไทย จะเห็นอะไร

ถ้าแทนค่าแรงต่อชั่วโมง-คนในข้อ ② ด้วยระดับจริงของประเทศไทย จะได้ข้อสรุปที่ต่างจากความรู้สึกของสำนักงานใหญ่ในญี่ปุ่น อัตราค่าจ้างขั้นต่ำของไทย ณ เดือนกรกฎาคม 2026 ยังไม่ได้ถูกทำให้เป็นอัตราเดียวทั่วประเทศ แต่แบ่งตามจังหวัดอยู่ที่ 337-400 บาทต่อวัน (ค่าเฉลี่ยทั่วประเทศราว 374 บาทต่อวัน) อัตรา 400 บาทใช้ที่กรุงเทพฯ ภูเก็ต ชลบุรี ระยอง ฉะเชิงเทรา และเกาะสมุย อัตรา 337 บาทใช้ที่นราธิวาส ปัตตานี และยะลา ส่วนเชียงใหม่แบ่งตามอำเภอ คืออำเภอเมือง 380 บาท และอำเภออื่น 357 บาท ประกาศคณะกรรมการค่าจ้างฉบับที่ 14 ซึ่งมีผลตั้งแต่ 1 กรกฎาคม 2026 คงระดับนี้ไว้ตามเดิม (แหล่งข้อมูล: EmployerRecords, Employsome)

ขอเน้นว่าตัวเลขนี้เป็นอัตราต่อวัน ไม่ใช่ต่อชั่วโมง ถ้าอ่านผิดจุดนี้ การประมาณค่าแรงต่อชั่วโมง-คนจะคลาดเคลื่อนไปเป็นหลัก สมมติว่าทำงานวันละ 8 ชั่วโมงและแปลงเป็นรายชั่วโมงอย่างง่าย จะได้ 337 ÷ 8 = ราว 42 บาทต่อชั่วโมง 400 ÷ 8 = 50 บาทต่อชั่วโมง และค่าเฉลี่ย 374 ÷ 8 = ราว 47 บาทต่อชั่วโมง ค่าแรงจริงจะสูงกว่านี้ เพราะต้องบวกเงินสมทบประกันสังคมส่วนของนายจ้าง ค่าล่วงเวลา เบี้ยเลี้ยงต่าง ๆ และค่าใช้จ่ายทางอ้อม แต่ก็ยังอยู่ในโลกที่ “ค่าแรงหนึ่งชั่วโมง-คนคือหลักสิบบาท” เหมือนเดิม

ข้อสรุปที่ได้จากตรงนี้ชัดเจน คือ ในฐานการผลิตที่ประเทศไทย การคืนทุนของการนำ IoT มาใช้ในโรงงานด้วยการลดค่าแรงเพียงอย่างเดียวเป็นเรื่องยาก สมมติว่ามีคนประจำสายการผลิต 5 คน และป้องกันการหยุด 1 ชั่วโมงได้ ผลประโยชน์ในมุมค่าแรงทางตรงก็อยู่แค่ระดับไม่กี่ร้อยบาท ในเมื่อชั้นที่ 1-4 เป็นการลงทุนระดับหลายล้านเยน การสะสมเฉพาะส่วนนี้ย่อมไม่พาไปถึงการคืนทุนในระดับปี

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

1. กำลังการผลิตที่เพิ่มขึ้นจากเวลาเดินเครื่องที่มากขึ้น (ฝั่งกำไรที่เสียไปในข้อ ① ถ้ามีคำสั่งซื้อรองรับ นี่ได้ผลที่สุด)
2. การลดต้นทุนพลังงาน (กล่าวถึงในบทถัดไป ค่าไฟฟ้าของไทยไม่ถูกเลย)
3. ราคาต่อเครื่องที่ถูกลงจากการขยายไปสายอื่น (ตามที่ตรวจสอบในบทก่อน 5 เครื่องคือ 600,000 เยนต่อเครื่อง แต่ 30 เครื่องคือราว 367,000 เยนต่อเครื่อง)

พูดอีกอย่าง ROI ของการนำ IoT มาใช้ในโรงงานสำหรับฐานการผลิตในไทย ควรประกอบขึ้นด้วยโครงเรื่องว่า “ผลิตได้มากขึ้นด้วยคนเท่าเดิมและเครื่องเท่าเดิม ผลิตด้วยพลังงานที่น้อยลง แล้วขยายไปสายอื่นด้วยต้นทุนที่ถูกลง” ไม่ใช่โครงเรื่องว่า “ลดคน”

เงื่อนไขเฉพาะของฐานการผลิตในประเทศไทย: ค่าไฟ ภาวะอุตสาหกรรม และเงื่อนไขที่ถูกต้องของสิทธิประโยชน์

ปิดท้ายด้วยการจัดระเบียบเงื่อนไขเฉพาะของประเทศไทยที่ต้องรู้แน่ ๆ เวลาพิจารณาลงทุน IoT ในไทย ส่วนนี้เป็นพื้นที่ที่ข้อมูลเก่าหมุนเวียนอยู่มาก จึงขอให้ตรวจสอบด้วยเงื่อนไขที่ถูกต้องของปี 2026

ค่าไฟฟ้า: การคืนทุนของการติดตามพลังงานต้องคำนวณด้วยอัตรานี้

ค่าไฟฟ้าของโรงงานในไทยประกอบด้วย ค่าพลังงานไฟฟ้าฐาน 3.78 บาท/kWh บวกกับค่า Ft 0.1623 บาท/kWh (อัตราที่ใช้ช่วงพฤษภาคมถึงสิงหาคม 2026) รวมกันตรง ๆ ได้ 3.9423 บาท/kWh จากนั้นยังต้องบวก VAT 7% ค่าความต้องการพลังไฟฟ้า (demand charge) และการแบ่งตามช่วงเวลา TOU (Cat 3 กิจการขนาดกลาง / Cat 4 กิจการขนาดใหญ่ แยก on-peak กับ off-peak) เข้าไปด้วย ทำให้ อัตราที่มีผลจริงอยู่ในช่วง 4.10-5.50 บาท/kWh (แหล่งข้อมูล: CAP Solar)

เวลาคำนวณมูลค่าผลประโยชน์ของการติดตามพลังงาน ต้องใช้อัตราที่มีผลจริงนี้เสมอ ถ้าคำนวณด้วยค่าพลังงานไฟฟ้าฐาน 3.78 บาทเพียงตัวเดียว จะประเมินมูลค่าผลประโยชน์ต่ำกว่าความจริงราว 8-31% (คิดจาก 3.78 เทียบกับ 4.10 และเทียบกับ 5.50) รูปแบบการคำนวณเรียบง่าย

มูลค่าที่ประหยัดได้ต่อปี (บาท) = ปริมาณไฟฟ้าที่ลดได้ต่อปี (kWh) × อัตราที่มีผลจริง (4.10-5.50 บาท/kWh)

ปริมาณ kWh ที่ลดได้จะไม่ปรากฏถ้าไม่วัดจริง ด้วยเหตุนี้เอง การเพิ่มเซ็นเซอร์กระแสเข้าไปที่ gateway ตัวเดียวกับระบบติดตามการทำงานของเครื่องจักร เพื่อวัดปริมาณไฟฟ้าแยกตามเครื่องจักรและตามช่วงเวลาก่อน จึงมีความหมาย เป้าหมายที่น่าเล็งเป็นพิเศษคือไฟฟ้าที่กินระหว่างช่วงเวลาที่ไม่ผลิต การรั่วของลมอัด และโหลดเป็นช่วง ๆ ที่กระจุกอยู่ในช่วง on-peak กรณีสัญญาแบบ TOU เพียงย้ายโหลดไปช่วง off-peak ส่วนต่างของอัตราก็ให้ผลแล้ว เมื่อข้อมูลการเดินเครื่องกับข้อมูลไฟฟ้าเรียงอยู่บนแกนเวลาเดียวกัน ข้อเท็จจริงแบบ “เครื่องนี้หยุดอยู่แต่ยังกินไฟ” จึงจะปรากฏให้เห็นเป็นครั้งแรก

ภาวะอุตสาหกรรม: อ่านจังหวะของการตัดสินใจลงทุนอย่างไร

ดัชนี PMI ภาคการผลิตของไทยเดือนเมษายน 2026 อยู่ที่ 52.7 ลดลงจาก 54.1 ของเดือนก่อนหน้าและเป็นระดับต่ำสุดตั้งแต่เดือนมกราคม แต่ยังอยู่ในโซนขยายตัวเหนือ 50 ต่อเนื่องเป็นเดือนที่ 12 พร้อมกันนั้นยังมีรายงานว่าต้นทุนปัจจัยการผลิตเพิ่มขึ้นด้วยความเร็วที่สูงที่สุดตั้งแต่เดือนกันยายน 2022 (แหล่งข้อมูล: Trading Economics)

ข้อเท็จจริงสองข้อนี้ให้นัยที่สอดคล้องกันต่อการตัดสินใจลงทุน IoT ในโรงงาน ด้านหนึ่งอุปสงค์ยังรักษาโซนขยายตัวไว้ได้ จึงเล็งผลจากการเพิ่มกำลังผลิต (การหลีกเลี่ยงกำไรที่เสียไปในข้อ ①) ได้ อีกด้านหนึ่งในช่วงที่ต้นทุนปัจจัยการผลิตกำลังขึ้น การบริหารพลังงานและอัตราของดีจะเชื่อมตรงไปที่อัตรากำไร พูดอีกอย่างคือ โครงสร้างที่เริ่ม “ระบบติดตามการทำงานของเครื่องจักร + การติดตามพลังงาน” บนแพลตฟอร์มเดียวกัน สมเหตุสมผลเป็นพิเศษในสภาพแวดล้อมปัจจุบัน

สิทธิหักรายจ่าย 200% ที่เกี่ยวข้องกับ depa: อย่าเข้าใจเงื่อนไขผิด

สิ่งที่มักถูกกล่าวถึงในฐานะสิทธิประโยชน์ทางภาษีสำหรับการลงทุนดิจิทัล คือมาตรการหักรายจ่ายได้ 200% ที่เกี่ยวข้องกับ depa (สำนักงานส่งเสริมเศรษฐกิจดิจิทัล) เงื่อนไขที่ถูกต้อง ณ ปี 2026 มีดังนี้

• ฐานทางกฎหมายคือ พระราชกฤษฎีกาฉบับที่ 802 (พ.ศ. 2569) ประกาศในราชกิจจานุเบกษาเมื่อ 6 กุมภาพันธ์ 2026 และมีผลบังคับใช้ 7 กุมภาพันธ์ 2026
• ใช้ย้อนหลังกับรายจ่ายระหว่าง 24 มิถุนายน 2025 ถึง 31 ธันวาคม 2027
• ผู้มีสิทธิคือ SME ที่มีทุนจดทะเบียนที่ชำระแล้วไม่เกิน 5 ล้านบาท และมีรายได้ต่อปีไม่เกิน 30 ล้านบาท
• เพดานการหักรายจ่ายคือ 300,000 บาทต่อรอบบัญชี
• ครอบคลุมเฉพาะซอฟต์แวร์ ฮาร์ดแวร์ สมาร์ตดีไวซ์ และบริการดิจิทัลที่ ขึ้นทะเบียนใน Thailand Digital Catalog แล้วเท่านั้น
• คอมพิวเตอร์ใช้งานทั่วไป (โน้ตบุ๊ก / เดสก์ท็อป) ไม่เข้าข่าย

(แหล่งข้อมูล: LexNova Partners, Optimum Accounting)

จุดที่ต้องระวังที่สุดคือ เงื่อนไขไม่ใช่ “ทุนจดทะเบียนที่ชำระแล้วต่ำกว่า 50 ล้านบาท” แต่เป็น “ทุนจดทะเบียนที่ชำระแล้วไม่เกิน 5 ล้านบาท และรายได้ต่อปีไม่เกิน 30 ล้านบาท” เงื่อนไขนี้เข้มมาก และ โรงงานญี่ปุ่นส่วนใหญ่ที่มีฐานการผลิตในไทยไม่เข้าเกณฑ์นี้ เพราะติดข้อกำหนดด้านทุนจดทะเบียนหรือด้านรายได้ข้อใดข้อหนึ่ง และแม้จะเข้าเกณฑ์ เพดานก็อยู่ที่ 300,000 บาทต่อรอบบัญชี ซึ่งให้ผลจำกัดเมื่อเทียบกับขนาดเงินลงทุนเริ่มต้นที่เห็นในบทก่อน จึงควรเข้าใจว่าไม่สามารถใช้ “เพราะใช้สิทธิของ depa ได้” เป็นเหตุผลหลักในการตัดสินใจลงทุน

BOI: จับเงื่อนไขของอัตราสิทธิประโยชน์ให้ถูกต้อง

สำหรับ BOI (คณะกรรมการส่งเสริมการลงทุน) มีรายงานว่านโยบายปี 2026 ต่อภาคการผลิตวางน้ำหนักไว้ที่ Industry 4.0 (โรงงานอัจฉริยะ การผลิตที่ใช้ AI และระบบอัตโนมัติ) และหมวด New S-Curve ครอบคลุมระบบอัตโนมัติกับศูนย์ข้อมูลสำหรับ AI ด้วย พร้อมเพิ่มหมวดย่อยด้าน AI และระบบอัตโนมัติ ได้แก่ การคำนวณเชิงควอนตัม หุ่นยนต์ขั้นสูง และ generative AI (แหล่งข้อมูล: Emerhub, Pertama Partners)

บนพื้นฐานนั้น สิทธิประโยชน์ที่สำคัญต่อการลงทุนปรับปรุงโรงงานเดิมคือกรอบ “Smart and Sustainable Industry” ตรงนี้ขอให้จับเงื่อนไขให้แม่น

• เพดานการยกเว้นภาษีเงินได้นิติบุคคลคือ 50% เป็นพื้นฐาน
• จะเป็น 100% เฉพาะกรณีที่นำระบบอัตโนมัติหรือหุ่นยนต์มาใช้ในสายการผลิต และจัดซื้อในสัดส่วนไม่น้อยกว่า 30% ของมูลค่าเครื่องจักรที่ปรับปรุงจากอุตสาหกรรมระบบอัตโนมัติภายในประเทศไทย เท่านั้น
• กำหนดเวลายื่นคำขอคือ สิ้นปี 2027

กล่าวคือ คำอธิบายที่ว่า “ถ้าเป็นกรอบโรงงานอัจฉริยะของ BOI ก็ได้ยกเว้น 100% โดยไม่มีเงื่อนไข” เป็นความเข้าใจที่ผิด การได้ 100% มีเงื่อนไขเป็นรูปธรรมคือสัดส่วนการจัดซื้อในประเทศไม่น้อยกว่า 30% นอกจากนี้ สถิติจำนวนคำขอของ BOI (ว่ามีการอนุมัติกี่โครงการ) กับระบบสิทธิประโยชน์แยกตามหมวด (ว่าหมวดไหนได้กี่เปอร์เซ็นต์) เป็นสองเรื่องที่แยกจากกัน จึงควรระวังไม่ให้ปนกันเวลาอธิบายภายในองค์กร

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

คำถามที่พบบ่อย (FAQ)

การนำ IoT มาใช้ในโรงงานมีค่าใช้จ่ายเท่าไร?

ตามข้อมูลราคาตลาดญี่ปุ่น เซ็นเซอร์ + gateway อยู่ที่ 0.5-2 ล้านเยน แพลตฟอร์มคลาวด์ 2-8 ล้านเยน (บวกค่ารายเดือน 10,000-100,000 เยน) และการพัฒนาแดชบอร์ด 1-5 ล้านเยน รวมเงินลงทุนเริ่มต้นอยู่ในช่วง 3.5-15 ล้านเยน (แหล่งข้อมูล: GXO) เมื่อแยกตามขนาด มีโมเดลตัวอย่างว่าเครื่องจักร 5 เครื่องราว 3 ล้านเยน 3 สายการผลิต 30 เครื่องราว 11 ล้านเยน และทั่วทั้งโรงงานราว 20 ล้านเยน ถ้าเป็นระบบติดตามการทำงานของเครื่องจักรพร้อมการแจ้งเตือนขนาดเล็กเพียงสายเดียว มีรายงานระดับราคาไว้ที่ 0.8-2 ล้านเยน และถ้าเฝ้าระวังเฉพาะอุณหภูมิความชื้นก็ 300,000-800,000 เยน ตัวเลขทั้งหมดนี้เป็นค่าอ้างอิงของตลาดญี่ปุ่น ไม่ได้แปลงเป็นเงินบาท นอกจากนี้ยังมีชั่วโมงงานภายในบริษัท เช่น การจัดข้อมูลหลัก การออกแบบรหัสสาเหตุการหยุดเครื่อง และการอบรมหน้างาน ที่เกิดขึ้นแยกในฐานะค่าดำเนินงานรายปี ถ้าไม่ตกลงให้เป็นมาตรฐานเดียวกันภายในองค์กรว่าจะนับชั่วโมงงานภายในนี้เป็นเงินลงทุนเริ่มต้นหรือค่าดำเนินงาน การคำนวณคืนทุนจะไม่ตรงกันในภายหลัง

จะทำให้เห็นเครื่องจักรหยุดสั้น (chokotei) ได้อย่างไร?

ความจำของคนหรือรายงานประจำวันที่เขียนด้วยมือจับไม่ได้เด็ดขาด สิ่งที่ต้องมีคือการบันทึกเวลาแบบอัตโนมัติ วิธีมี 3 แบบ คือ ① อ่านสัญญาณเดินเครื่องหรืออลาร์มของ PLC โดยตรง ② จับการเปลี่ยนสถานะติดของไฟสัญญาณด้วยเซ็นเซอร์แสงหรือการตรวจจับแรงดัน และ ③ ตรวจจับว่าตัวนับจำนวนผลิตไม่เพิ่มขึ้นแม้เลยรอบเวลาทางทฤษฎีไปแล้ว วิธีที่ถูกและเร็วที่สุดคือ ② เพราะได้เวลาเริ่มและเวลาสิ้นสุดการหยุดในระดับวินาทีโดยไม่ต้องแตะตัวเครื่องจักร แต่ ② ไม่บอก “สาเหตุ” ของการหยุด จึงต้องใช้ร่วมกับการให้คนทำเฉพาะการเลือกรหัสสาเหตุ การแบ่งงานให้เครื่องเก็บเวลากับจำนวน และให้คนเลือกสาเหตุกับการจัดประเภท คือคำตอบที่ดีที่สุดในทางปฏิบัติ

เครื่องจักรเก่าก็ดึงข้อมูลการทำงานได้ไหม?

ได้ เครื่องจากยุค 1970 ก็ยังมีกระแสไฟไหลในมอเตอร์ ดังนั้นเพียงหนีบเซ็นเซอร์กระแสแบบแคลมป์เข้ากับสายเมน ก็แยกได้ว่าเครื่องกำลังทำงาน เดินตัวเปล่า หรือหยุด ถ้ามีไฟสัญญาณติดอยู่ ก็ดึงสถานะจากสายชุดนั้นได้ และถ้าเข้าถึงตู้ควบคุมได้ ก็มีวิธีแยกหน้าสัมผัสของรีเลย์ช่วยออกมาผ่านยูนิตอินพุตแบบแยกกราวด์ การไม่มี PLC ไม่มีออปชันสื่อสาร ไม่มีแบบวงจร ทั้งหมดนี้ไม่ใช่อุปสรรคต่อการนำ IoT มาใช้ในโรงงาน สิ่งที่เป็นอุปสรรคจริงคือการลืมใส่ช่วงเวลาปรับค่าขีดแบ่ง (วัดจริง 1-2 สัปดาห์ต่อเครื่อง) ลงในแผนงาน โรงงานที่มีเครื่องจักรเก่ามาก ยิ่งต้องดูว่ากันช่วงเวลาวัดจริงนี้ไว้ได้หรือไม่ เพราะนั่นคือจุดตัดสินว่าจะรักษากำหนดการได้หรือไม่

การเก็บข้อมูลจาก PLC ควรเลือกโปรโตคอลอะไร?

โครงสร้างมาตรฐานของปี 2026 เป็นสามชั้น คือใช้ OPC UA ใส่ความหมายที่ชั้นพื้นโรงงาน ใช้ MQTT ลำเลียงขึ้นคลาวด์ และใช้ Sparkplug B เชื่อมสองส่วนนี้ MQTT กับ OPC UA ไม่ใช่คู่แข่งกัน แต่ใช้ร่วมกันเป็นพื้นฐาน โดย MQTT รับหน้าที่ลำเลียง และ OPC UA รับหน้าที่นิยามความหมาย (แหล่งข้อมูล: HiveMQ, FlowFuse) สำหรับ PLC รุ่นเก่าที่ไม่รองรับ OPC UA ให้วาง edge gateway ที่รองรับ Modbus, PROFINET, EtherNet/IP ไว้ฝั่งเครื่องจักร แล้วแปลงเป็นรูปแบบ OPC UA ก่อนส่งขึ้นชั้นบน ถ้าทำโครงสร้างแบบนี้ไว้ เมื่อเปลี่ยนเครื่องจักรในอนาคตก็ยังนำสิ่งที่พัฒนาไว้เหนือ gateway กลับมาใช้ต่อได้

เมื่อยกระดับอัตราการเดินเครื่องของเครื่องจักรแล้วได้อะไรเป็นรูปธรรม?

โดยแก่นแท้ได้เพียง 2 อย่าง คือผลิตได้มากขึ้นด้วยเครื่องจักรชุดเดิม (กำลังการผลิตเพิ่ม) หรือผลิตปริมาณเท่าเดิมได้ในเวลาที่สั้นลง (ลดค่าล่วงเวลาและการเดินเครื่องวันหยุด) จะได้อย่างไหนขึ้นอยู่กับว่าโรงงานนั้นติดข้อจำกัดด้านคำสั่งซื้อหรือด้านกำลังการผลิต ถ้ามีคำสั่งซื้อรองรับ เวลาเดินเครื่องที่เพิ่มขึ้นจะกลายเป็นกำไรส่วนเพิ่มที่มากขึ้นตรง ๆ แต่ถ้าอุปสงค์ไม่โต ผลประโยชน์จะจำกัดอยู่ที่การลดค่าล่วงเวลาและตัวเลขจะเล็กลง ในเอกสารขออนุมัติ การเขียนทั้งสองสถานการณ์ควบกันไปเป็นวิธีที่ใช้ได้จริง ทั้งนี้ในฐานการผลิตที่ประเทศไทย ค่าจ้างขั้นต่ำอยู่ที่ระดับ 337-400 บาทต่อวันแยกตามจังหวัด การคืนทุนด้วยการลดค่าแรงเพียงอย่างเดียวจึงเป็นเรื่องยาก และการประกอบเรื่องด้วยการเพิ่มเวลาเดินเครื่อง การลดพลังงาน และการลดราคาต่อเครื่องจากการขยายไปสายอื่น จะสมจริงกว่า

กรณีศึกษาการนำ IoT มาใช้ในอุตสาหกรรมการผลิต ใช้เป็นข้อมูลตัดสินใจของเราได้แค่ไหน?

สิ่งที่ควรอ้างอิงจากกรณีศึกษาไม่ใช่ “ตัวเลขผลลัพธ์” แต่เป็น “โครงสร้างของวิธีดึงข้อมูลและวิธีใช้ข้อมูล” อัตราผลลัพธ์ที่เผยแพร่กัน เช่นค่าที่ระบุว่าการบำรุงรักษาเชิงคาดการณ์ด้วย IoT ลดการหยุดนอกแผนได้ 35-50% และยกระดับ OEE ได้ 20-25% ส่วนใหญ่เป็นการรวบรวมและประเมินโดยผู้ให้บริการหรือสื่ออุตสาหกรรม และไม่มีอะไรรับประกันว่าประเภทอุตสาหกรรม โครงสร้างเครื่องจักร และระดับการเดินเครื่องเดิม จะตรงกับของบริษัทท่าน (แหล่งข้อมูล: ReliaMag, L2L) เช่นเดียวกัน ตัวเลขต้นทุนเฉลี่ยของการหยุดนอกแผนที่ราว 260,000 ดอลลาร์สหรัฐต่อชั่วโมง ก็เป็นค่าเฉลี่ยที่ถูกดึงโดยค่าสูงมหาศาลอย่างโรงงานยานยนต์ที่สูงสุด 2.3 ล้านดอลลาร์ต่อชั่วโมง ขณะที่การผลิตแบบชิ้นงานแยกมีการระบุช่วงไว้ที่ 10,000-50,000 ดอลลาร์ต่อชั่วโมง ให้อ่านจากกรณีศึกษาว่า “ดึงข้อมูลด้วยเส้นทางไหน” และ “ใครดูข้อมูลนั้นในการประชุมใด” แล้วคำนวณมูลค่าผลประโยชน์ใหม่ด้วยกำไรส่วนเพิ่มและค่าแรงต่อชั่วโมง-คนของบริษัทท่านเอง

ควรเริ่มจากขนาดเล็กหรือทั่วทั้งโรงงาน?

คำแนะนำคือ “ออกแบบแพลตฟอร์มโดยเผื่อทั้งโรงงาน แล้วเพิ่มจำนวนการเชื่อมต่อแบบเป็นขั้น” เหตุผลอยู่ในโครงสร้างของเงินลงทุน 5 เครื่องราว 3 ล้านเยนเท่ากับ 600,000 เยนต่อเครื่อง แต่ 30 เครื่องราว 11 ล้านเยนเท่ากับราว 367,000 เยนต่อเครื่อง เพราะแพลตฟอร์มคลาวด์และแดชบอร์ดเป็นต้นทุนร่วมที่แทบไม่แปรผันตามจำนวนเครื่อง ดังนั้นถ้าจำกัดขอบเขตแคบเกินไป ราคาต่อเครื่องจะค้างอยู่ในระดับสูง แต่ในทางกลับกัน ถ้าทำเฟสแรกให้ใหญ่ ความผิดพลาดในการออกแบบรหัสสาเหตุการหยุดเครื่องและการต้องย้อนกลับไปปรับค่าขีดแบ่ง จะลุกลามไปทุกสายการผลิต วิธีที่ตอบโจทย์สองข้อนี้พร้อมกันคือ “ออกแบบชั้นที่ 2 และชั้นที่ 3 โดยเผื่อจำนวนเครื่องในอนาคต” บวกกับ “เริ่มเชื่อมต่อและเรียนรู้การใช้งานที่สายการผลิตคอขวด 1 สายก่อน”

สรุป

สิ่งที่ตัดสินความสำเร็จหรือล้มเหลวของการนำ IoT มาใช้ในโรงงาน ไม่ใช่การเลือกผลิตภัณฑ์คลาวด์หรือแดชบอร์ด แต่เป็นสองเรื่องนี้ คือ จะดึงข้อมูลออกจากเครื่องจักรเดิมได้อย่างไร (ชั้นวัดค่า) และ จะเชื่อมข้อมูลนั้นไปสู่การตัดสินใจของใคร (ชั้นใช้งาน) วิธีดึงข้อมูลมี 5 เส้นทาง และการผสมแบบเริ่มจากไฟสัญญาณแล้วเจาะลึกเครื่องคอขวดด้วยการต่อ PLC โดยตรง ให้ความคุ้มค่าสูงที่สุด ส่วนวิธีลำเลียง โครงสร้างมาตรฐานของปี 2026 คือใส่ความหมายด้วย OPC UA ลำเลียงด้วย MQTT และเชื่อมด้วย Sparkplug B

ค่าใช้จ่ายให้เข้าใจโดยแบ่งเป็น 5 ชั้น ชั้นที่ 1 (เซ็นเซอร์และการดึงสัญญาณ) ถึงชั้นที่ 4 (การพัฒนาหน้าจอและการแจ้งเตือน) คือเงินลงทุนเริ่มต้น รวม 3.5-15 ล้านเยนตามราคาอ้างอิงของตลาดญี่ปุ่น ส่วนชั้นที่ 5 (การจัดข้อมูลหลัก การออกแบบรหัสสาเหตุการหยุดเครื่อง การอบรมหน้างาน) ให้บริหารเป็น ค่าดำเนินงานรายปีแยกกรอบออกมา ไม่ใช่เงินลงทุนเริ่มต้น ถ้าปนกันตรงนี้ การคำนวณคืนทุนจะกลายเป็นการนับซ้ำ

และ ROI ให้คำนวณด้วยตัวเลขของบริษัทเอง ไม่ใช่คัดลอกค่าเฉลี่ยจากต่างประเทศ เมื่อคำนึงว่าค่าจ้างขั้นต่ำของไทยอยู่ที่ระดับ 337-400 บาทต่อวันแยกตามจังหวัด การคืนทุนด้วยการลดค่าแรงเพียงอย่างเดียวเป็นเรื่องยาก การประกอบขึ้นจากสามเรื่อง คือการเพิ่มเวลาเดินเครื่อง การลดต้นทุนค่าไฟที่อัตราจริง 4.10-5.50 บาท/kWh และการลดราคาต่อเครื่องจากการขยายไปสายอื่น จึงเป็นการออกแบบที่สมจริง ด้านสิทธิประโยชน์ ขอให้จับเงื่อนไขให้แม่นว่า การหักรายจ่าย 200% ที่เกี่ยวข้องกับ depa จำกัดเฉพาะ SME ที่มีทุนจดทะเบียนที่ชำระแล้วไม่เกิน 5 ล้านบาทและรายได้ต่อปีไม่เกิน 30 ล้านบาท โดยมีเพดาน 300,000 บาทต่อรอบบัญชี และเพดานการยกเว้นภาษีเงินได้นิติบุคคลของกรอบ Smart and Sustainable Industry ของ BOI คือ 50% เป็นพื้นฐาน โดยการได้ 100% มีเงื่อนไขเรื่องสัดส่วนการจัดซื้อในประเทศไม่น้อยกว่า 30%

เครื่องจักรของท่านใช้เส้นทางไหนได้ ค่าใช้จ่ายจะกระจุกอยู่ที่ชั้นไหน และมูลค่าผลประโยชน์ที่ผ่านการอนุมัติได้ควรประกอบขึ้นอย่างไร สามเรื่องนี้ยังสรุปไม่ได้ถ้าไม่ได้ดูรายการเครื่องจักรและตู้ควบคุมจริง TOMAS TECH มีฐานอยู่ที่กรุงเทพฯ และให้บริการระบบบริหารการผลิตและระบบบริหารพลังงาน PEGASUS พร้อมด้วย MES, IoT, FA และ AI แก่ฐานการผลิตของผู้ประกอบการญี่ปุ่นในไทยและ ASEAN การปรึกษาในขั้นที่ยังพิจารณาอยู่ก็ไม่เป็นไร เช่น “ทิศทางภายในองค์กรยังไม่นิ่ง” หรือ “อยากรู้แค่ว่าบริษัทอื่นเริ่มลงมือจากจุดไหน” หากแจ้งโครงสร้างเครื่องจักรปัจจุบันและประเด็นที่กำลังติดขัดมาทางแบบฟอร์มติดต่อ เราจะช่วยจัดระเบียบตั้งแต่เส้นทางที่ทำได้จริงและวิธีคิดตัวเลขคร่าว ๆ ไปด้วยกัน

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

• GXO “ค่าใช้จ่ายในการพัฒนาแพลตฟอร์มข้อมูล IoT และการมองเห็นข้อมูล (ฉบับปี 2026)” https://gxo.co.jp/column/iot-data-platform-visualization-development-cost-2026
• is-prime “การเฝ้าติดตามโรงงานด้วย IoT” https://is-prime.co.jp/tech-blog/iot-factory-monitoring/
• OPTiM “คู่มือการทำโรงงานให้เป็นโรงงานอัจฉริยะ” https://www.optim.co.jp/media/cat-guide/sgp_260617-01
• ReliaMag “The Cost of Unplanned Downtime in Manufacturing” https://reliamag.com/articles/cost-unplanned-downtime-manufacturing/
• Manufacturing Lead Generation “Manufacturing Downtime Statistics” https://manufacturingleadgeneration.com/manufacturing-downtime-statistics/
• L2L “How to Improve OEE” https://www.l2l.com/blog/improve-oee
• HiveMQ “IIoT Protocols: OPC UA, MQTT and Sparkplug Comparison” https://www.hivemq.com/resources/iiot-protocols-opc-ua-mqtt-sparkplug-comparison/
• FlowFuse “OPC UA vs MQTT” https://flowfuse.com/blog/2026/01/opcua-vs-mqtt/
• iFactory “Connected Machine Architecture for Legacy and New Equipment” https://ifactoryapp.com/greenfield-consulting/connected-machine-architecture-legacy-new-equipment
• EmployerRecords “Thailand Minimum Wage” https://employerrecords.com/eor-location/thailand/minimum-wage/
• Employsome “Minimum Wage in Thailand” https://employsome.com/blog/minimum-wage-thailand/
• CAP Solar “Factory Electricity Cost in Thailand” https://capsolar.co.th/en/knowledge/factory-electricity-cost-thailand
• CAP Solar “Thailand Electricity Tariff” https://capsolar.co.th/en/knowledge/thailand-electricity-tariff
• Trading Economics “Thailand Manufacturing PMI” https://tradingeconomics.com/thailand/manufacturing-pmi
• LexNova Partners “Thailand Approves Tax Deduction” https://lexnovapartners.com/thailand-approves-tax-deduction/
• Optimum Accounting “SME 200% Tax Deduction Thailand” https://optimumacc.com/sme-200-percent-tax-deduction-thailand/
• Emerhub “Thailand’s Renewed BOI Incentives for 2026-2027” https://emerhub.com/thailand/thailands-renewed-boi-incentives-for-2026-2027/
• Pertama Partners “Thailand BOI Manufacturing” https://www.pertamapartners.com/training/funding/thailand-boi-manufacturing