ตัวอย่างการใช้ IoT โรงงาน ไทย 2026｜5 รูปแบบและ 5 เส้นแบ่ง

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

ทำไมตัวอย่างการใช้ IoT ในโรงงานไทยจึงเพิ่มขึ้นในปี 2026

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

เหตุผลหลักมี 3 ข้อ ได้แก่ การเปลี่ยนโครงสร้างของต้นทุนแรงงาน การเปลี่ยนทิศทางของสภาพแวดล้อมการลงทุน (BOI) และการที่เงินลงทุนเคลื่อนไหวจริงในฝั่งตลาด เราจะไล่ดูทีละข้อ

ต้นทุนแรงงาน: แนวโน้มค่าแรงขั้นต่ำ 400 บาททั่วประเทศ และการขึ้นเงินเดือน 4.64% ในบริษัทญี่ปุ่น

ค่าแรงขั้นต่ำของไทยได้ปรับขึ้นเป็นวันละ 337–400 บาทในหลายพื้นที่เมื่อเดือนมกราคม 2025 และในเดือนกรกฎาคม 2025 กรุงเทพมหานครก็ปรับให้ทุกประเภทกิจการเป็นวันละ 400 บาทเท่ากันทั้งหมด สำหรับปี 2026 มีการมองว่าการปรับให้เป็น 400 บาททั่วประเทศมีความเป็นไปได้สูง แต่ ณ ตอนนี้ยังไม่ใช่ข้อกำหนดที่สรุปแล้ว หากจะเขียนลงในเอกสารขออนุมัติ ควรใช้ถ้อยคำระดับ “มีแนวโน้มสูงว่าจะ” เท่านั้น

แต่สิ่งที่สำคัญกว่าค่าแรงขั้นต่ำคืออัตราการขึ้นเงินเดือนของบริษัทญี่ปุ่น อัตราการปรับขึ้นเงินเดือนในบริษัทญี่ปุ่นเคลื่อนไหวจาก 3.8% ในปี 2023 เป็น 4.58% ในปี 2024 และคาดว่าจะอยู่ที่ 4.64% ในปี 2025 นอกจากนี้ กลุ่มช่างเทคนิคและวิศวกรยังคงปรับขึ้นปีละ 5–8% ต่อเนื่อง

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

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

สภาพแวดล้อมการลงทุนของ BOI: 649 โครงการ 330,132 ล้านบาท และการเอียงไปทางดิจิทัล

ไตรมาสแรกของปี 2026 สำนักงานคณะกรรมการส่งเสริมการลงทุน (BOI) อนุมัติไปแล้ว 649 โครงการ มูลค่าเงินลงทุน 330,132 ล้านบาท ส่วนฐานตัวเลขคำขอรับการส่งเสริมซึ่งเป็นคนละชุดกับยอดอนุมัตินั้น มีมูลค่าเกิน 1.01 ล้านล้านบาท และมีจำนวนเกิน 600 โครงการ โดยตัวขับเคลื่อนคือกลุ่มดิจิทัลและอิเล็กทรอนิกส์ ซึ่งมีความต้องการด้าน AI อยู่เบื้องหลัง

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

ขอสรุปสิทธิประโยชน์ของ BOI เฉพาะส่วนที่เกี่ยวข้องกับการลงทุน IoT ไว้ดังนี้

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

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

ความเคลื่อนไหวฝั่งตลาด: การลงทุนสมาร์ทแฟคทอรี่ราว 54,000 ล้านเยน โต 10% กว่า (อ้างอิงจากข่าว)

สำหรับตลาดการทำโรงงานให้เป็นสมาร์ทแฟคทอรี่ในไทย ตามรายงานข่าวของ NNA ระบุว่ามีขนาดราว 54,000 ล้านเยน และคาดว่าจะขยายตัวมากกว่า 10% เมื่อเทียบกับปีก่อน อีกทั้งยังมีการรายงานว่าผู้เล่นหลักที่ลงทุนคือผู้ผลิตรถยนต์และเครื่องใช้ไฟฟ้าสัญชาติจีน (เนื่องจากเป็นบทความแบบเสียค่าสมาชิก ในที่นี้จึงอ้างเฉพาะสาระสำคัญ)

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

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

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

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

วิธีอ่านตัวอย่างการใช้ IoT ให้ถูกต้อง — อ่านด้วยชุด 4 จุด

นี่คือใจกลางของบทความนี้ ถ้าไม่เปลี่ยนวิธีอ่านตัวอย่าง ต่อให้รวบรวมตัวอย่างมาได้กี่กรณี มันก็ไม่กลายเป็นแผนของโรงงานตัวเอง

ทำไมการอ่านแบบ “เขาใส่อะไรเข้าไป” จึงทำซ้ำไม่ได้

ถ้าเอาโรงงานญี่ปุ่นในไทยที่ IoT อยู่ตัวแล้ว มาวางเทียบกับโรงงานที่หยุดอยู่แค่ PoC จะพบว่า องค์ประกอบของอุปกรณ์แทบไม่ต่างกันเลย ใช้เซนเซอร์แสงจับสถานะไฟสัญญาณ 3 สี ดึงสัญญาณจาก PLC รวบผ่าน gateway ขึ้นคลาวด์ แล้วดูผ่านแดชบอร์ด — ตราบใดที่ยังคุยกันเรื่ององค์ประกอบ ภาพของกรณีสำเร็จกับกรณีล้มเหลวจะเหมือนกันเป๊ะ

จุดที่ต่างกันมีจุดเดียว คือ ก่อนจะเริ่มวัด ได้ตัดสินใจไว้หรือยังว่า “ถ้าตัวเลขนี้ขยับ ใครจะทำอะไร”

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

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

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

ปัญหา → สิ่งที่วัด → การตัดสินใจที่เชื่อมต่อ → ตัวเลขที่เปลี่ยนไป

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

ลำดับของ 4 จุดนี้ก็มีความหมายในตัวเอง ในทางปฏิบัติ ไม่ใช่การไล่ตัดสินใจจาก 1 ไป 4 แต่ต้องตัดสิน 3 ก่อน แล้วย้อนกลับมาที่ 2

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

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

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

ถ้าเขียนใหม่ด้วยชุด 4 จุด จะออกมาหน้าตาแบบไหน

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

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

5 รูปแบบของตัวอย่างการใช้ IoT ในโรงงานไทย

ตัวอย่างการใช้ IoT ที่พูดถึงกันในโรงงานญี่ปุ่นในไทย ในทางปฏิบัติสามารถแบ่งออกได้เป็น 5 รูปแบบ ในที่นี้จะเรียบเรียงแต่ละรูปแบบตามชุด 4 จุดในหัวข้อก่อนหน้า ขอให้อ่านโดยเข้าใจว่านี่ ไม่ใช่กรณีจริงของบริษัทใดบริษัทหนึ่ง แต่เป็นการจัดกลุ่มจากองค์ประกอบที่มีการรายงานกันทั่วไป และรูปแบบที่พบบ่อยเท่าที่เราเห็นในหน้างาน ส่วนขนาดของการปรับปรุงเชิงตัวเลขนั้นแตกต่างกันมากในแต่ละบริษัท และไม่ใช่สิ่งที่ฟันธงได้

เริ่มจากภาพรวมทั้งหมดก่อน

ต่อไปจะดูรายละเอียดทีละรูปแบบ

รูปแบบ A การมองเห็นสถานะการเดินเครื่อง (เริ่มจากไฟสัญญาณ 3 สีหรือ PLC)

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

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

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

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

• ในประชุมเช้าวันรุ่งขึ้น (7:30–8:00) ตัดสินสาเหตุและผู้รับผิดชอบมาตรการของเวลาหยุด 3 อันดับแรกของเมื่อวานในที่ประชุมทันที
• รายเดือน ใช้อัตราการเดินเครื่องจริงเป็นค่าสมมติฐานของแผนการผลิตเดือนถัดไป (แทนตัวหารของแผนด้วยค่าที่วัดได้จริง)

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

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

การตัดสินใจเลือกรูปแบบนี้ ถ้ายังไม่ได้ตัดสินว่าจะเริ่มจากอะไร เลือกรูปแบบนี้ได้เกือบทุกกรณี เหตุผลมี 3 ข้อ คือ เริ่มได้โดยไม่ต้องไปยุ่งกับเครื่องเดิม อธิบายผลลัพธ์ได้ด้วยตัวเลขเดียวคือเวลาหยุดเครื่อง และรูปแบบที่ตามมาทีหลัง (B และ E) ล้วนวางอยู่บนรูปแบบนี้

รูปแบบ B การจับสัญญาณเตือนก่อนเครื่องจักรเสีย

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

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

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

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

การตัดสินใจเลือกรูปแบบนี้ ตัดสินจากว่าบีบขอบเขตการใช้งานได้หรือไม่ ถ้าระบุได้ว่าเครื่องที่ “ถ้าตัวนี้หยุด ทั้งโรงงานหยุด” มีอยู่ 1–3 เครื่อง รูปแบบนี้ก็ตั้งอยู่ได้ แต่ถ้าระบุไม่ได้แล้วขยายเป็น “ติดกับเครื่องหลักทุกตัว” ก็จะไม่คุ้มกับค่าใช้จ่ายและแรงที่ลงไป อีกอย่าง โดยพื้นฐานรูปแบบนี้ควรมาหลังรูปแบบ A การไล่ตามสัญญาณเตือนทั้งที่ยังมองไม่เห็นแม้แต่สถานะเดิน/หยุด ถือว่าสลับลำดับกัน

รูปแบบ C การทำให้ไล่ของเสียในกระบวนการได้

สิ่งที่วัด ผลการตรวจสอบ (ของดี/ของเสีย ประเภทของเสีย) เงื่อนไขกระบวนการ ณ ตอนนั้น (อุณหภูมิ ความดัน เวลา ฯลฯ) และการเชื่อมโยงกับล็อตของผลิตภัณฑ์ ข้อที่สามสำคัญที่สุด และหลุดง่ายที่สุดด้วย

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

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

อีกจุดที่สะดุดคือ ถ้ายังมีกระบวนการที่เก็บผลตรวจไว้บนกระดาษหลงเหลืออยู่แม้แต่กระบวนการเดียว การไล่ตามก็จะขาดตรงนั้น ถ้าทำเป็นข้อมูล 9 กระบวนการแต่เหลือกระดาษ 1 กระบวนการ ของเสียที่มีสาเหตุจากกระบวนการนั้นก็ไล่ไม่ได้

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

รูปแบบ D การดูไฟฟ้าและพลังงานเป็นรายกระบวนการ

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

การตัดสินใจที่เชื่อมต่อ เชื่อมกับ 3 เรื่องหลัก ได้แก่ การทบทวนค่าความต้องการพลังไฟฟ้า (demand) ตามสัญญา การเปลี่ยนช่วงเวลาเดินเครื่องของเครื่องที่สร้างพีค และการปันค่าไฟฟ้าลงในต้นทุนผลิตภัณฑ์

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

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

รูปแบบ E การมอนิเตอร์โรงงานไทยจากสำนักงานใหญ่ที่ญี่ปุ่นแบบระยะไกล

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

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

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

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

ข้อที่สาม เครือข่ายและความปลอดภัย เส้นทางการส่งข้อมูลจากฐานในไทยไปยังสำนักงานใหญ่ที่ญี่ปุ่นจะเป็นแบบใด (VPN หรือผ่านคลาวด์) ขึ้นอยู่กับนโยบายของฝ่ายสารสนเทศที่สำนักงานใหญ่ นี่คือส่วนที่ตัดสินเองในไทยฝ่ายเดียวไม่ได้ และเป็นสาเหตุคลาสสิกที่ทำให้การเริ่มงานล่าช้า การดึงฝ่าย IT ของสำนักงานใหญ่เข้ามาร่วมตั้งแต่ตอนทำแผนในไทยหรือไม่ ต่างกันได้ถึง 3 เดือน

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

5 เส้นแบ่งระหว่างกรณีที่อยู่รอดกับกรณีที่หยุดกลางทาง

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

เส้นแบ่งที่ 1 ตัดสินการตัดสินใจก่อนจะเริ่มวัดหรือไม่

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

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

เส้นแบ่งที่ 2 คนที่ดูคือพนักงานคนไทยหรือพนักงานญี่ปุ่นประจำการ

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

สิ่งที่ส่งผลอย่างเป็นรูปธรรมมี 3 ข้อ

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

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

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

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

เส้นแบ่งที่ 3 ออกแบบให้ทำข้อมูลละเอียดขึ้นภายหลังได้หรือไม่

ข้อนี้ค่อนไปทางเทคนิค แต่หนักเพราะย้อนกลับไม่ได้

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

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

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

เส้นแบ่งที่ 4 จะเข้าไปยุ่งกับเครื่องจักรเดิมแค่ไหน (งานไฟฟ้าและการยอมให้หยุดเครื่อง)

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

ในโรงงานที่ประเทศไทย มี 3 ข้อที่เป็นปัญหาเป็นพิเศษ

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

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

ใบอนุญาตงานไฟฟ้าและผู้รับเหมา ต้องจัดหาผู้รับเหมาที่มีใบอนุญาตในประเทศ ระยะเวลารอจะต่างกันไปตามว่าผู้รับเหมางานบำรุงรักษาเดิมของโรงงานทำได้หรือไม่ หรือต้องจัดหาแยกต่างหาก

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

เส้นแบ่งที่ 5 เป็นกลไกที่ไม่หายไปเมื่อพนักงานญี่ปุ่นประจำการสับเปลี่ยนหรือไม่

หน้างานที่กลับไปดูอีกทีหลังติดตั้งไป 2 ปีแล้วพบว่าไม่ได้ใช้แล้ว มักมีรูปแบบร่วมกัน คือ พนักงานญี่ปุ่นประจำการที่เป็นคนผลักดันกลับประเทศ แล้วผู้รับตำแหน่งต่อรับช่วงไม่ได้

สิ่งที่ต้องมีเพื่อไม่ให้หายไป ในทางปฏิบัติสรุปได้ 4 อย่าง

1. ตารางเวรการใช้งานที่เขียนด้วยชื่อตำแหน่ง (ไม่ใช่ชื่อบุคคล)
2. คู่มือการใช้งานภาษาไทย (พร้อมภาพหน้าจอ)
3. เวทีประชุมที่ดูตัวเลขเป็นรายเดือน (ใส่เป็นวาระในการประชุมที่มีอยู่แล้ว ไม่ตั้งใหม่)
4. ข้อมูลติดต่อของผู้ขายและศูนย์บริการ พร้อมเนื้อหาสัญญา ที่เก็บเป็นเอกสารอยู่ในประเทศ

ข้อที่ 4 หลุดง่ายที่สุด ถ้าการติดต่อสื่อสารตอนติดตั้งอยู่แต่ในอีเมลส่วนตัวของพนักงานญี่ปุ่นประจำการ ผู้รับตำแหน่งต่อจะต้องเริ่มไล่สืบใหม่ตั้งแต่ว่าทำสัญญาอะไรไว้บ้าง

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

ประเด็นเชิงปฏิบัติที่มีเฉพาะในโรงงานที่ประเทศไทย

ขอเรียบเรียงประเด็นที่คำอธิบายการนำ IoT มาใช้แบบทั่วไปไม่ได้พูดถึง แต่กลายเป็นปัญหาแน่นอนในโรงงานที่ประเทศไทย

ระบบไฟฟ้าและการสื่อสาร: Wi-Fi ในโรงงาน ฤดูฝน ฟ้าผ่า ไฟดับ

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

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

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

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

ขั้นตอนเมื่อจะใช้สิทธิประโยชน์ BOI และการยกเว้นอากรขาเข้า

ในบรรดาสิทธิประโยชน์ที่กล่าวถึงในหัวข้อก่อนหน้า สิ่งที่จะเกิดขั้นตอนดำเนินการจริงในการลงทุน IoT ส่วนใหญ่คือการยกเว้นอากรขาเข้า เซนเซอร์ gateway อุปกรณ์ edge หุ่นยนต์อุตสาหกรรม GPU ฯลฯ อาจเข้าข่าย

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

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

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

UI ภาษาไทย การจัดเวรผู้ดูแล และการส่งมอบให้พนักงานคนไทย

ขอเสริมด้านปฏิบัติของเนื้อหาที่กล่าวถึงในเส้นแบ่งที่ 2

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

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

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

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

การบำรุงรักษา: ใครในไทยเป็นคนลงมือ

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

โครงสร้างที่เป็นไปได้จริงมีดังนี้

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

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

เริ่มจากอะไรดี — 90 วันแรก

ขอแปลงเนื้อหาทั้งหมดที่ผ่านมาเป็นลำดับของการลงมือทำ โดยจัดโครงสร้างเป็น แบ่ง 90 วันออกเป็น 30 วันสามช่วง แล้วกำหนดไว้ว่าเมื่อจบแต่ละช่วงจะมีอะไรเสร็จ

อนึ่ง ในแง่ภาพรวมของตารางเวลา เกณฑ์ทั่วไปคือ สำรวจปัญหา 2–4 สัปดาห์ → PoC 1–2 เดือน → ออกแบบและพัฒนาระบบจริง 2–4 เดือน → ติดตั้ง ย้ายระบบ และอบรม 1–2 เดือน รวมทั้งหมด 6–12 เดือน ส่วน 90 วันข้างล่างนี้คือครึ่งแรกของช่วงดังกล่าว

0–30 วัน สำรวจปัญหาและตัดสิน KPI 1 ตัว

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

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

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

31–60 วัน PoC (เครื่องจักร 1–2 เครื่อง)

เกณฑ์ขนาด ระดับทั่วไปของ PoC คือระยะเวลา 1–2 เดือน ค่าใช้จ่าย 500,000–1,000,000 เยน และขอบเขตคือติดเซนเซอร์กับเครื่องจักร 1–2 เครื่อง PoC ที่เกินขอบเขตนี้ไม่ใช่ PoC แล้ว แต่กลายเป็นการติดตั้งจริงขนาดเล็กไปแล้ว

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

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

สิ่งที่ต้องตัดสินในช่วงนี้ ระหว่างช่วง PoC ต้อง ลองลงมือทำการตัดสินใจที่กำหนดไว้จริงอย่างน้อย 1 ครั้ง คือเดินกระบวนการรายงานการหยุด 3 อันดับแรกในประชุมเช้าแล้วตัดสินผู้รับผิดชอบมาตรการดูสักครั้ง ถ้าลองเดินจริงแล้วไม่ทำงาน ก็ไม่มีทางที่จะทำงานได้ในระบบจริง

61–90 วัน กำหนดเกณฑ์การตัดสิน (ขยายหรือหยุด) ไว้ล่วงหน้า

สิ่งสำคัญที่สุดคืออย่าเพิ่งมาคิดเกณฑ์นี้ในวันที่ 61 ให้เขียนไว้ตั้งแต่ช่วง 0–30 วันว่า “ถ้า PoC ออกมาแบบไหนถึงจะเดินหน้าสู่ระบบจริง และแบบไหนถึงจะหยุด”

ขอยกตัวอย่างเกณฑ์

เรื่องแนวโน้มค่าใช้จ่าย ในแง่ขนาดของการติดตั้งจริง เกณฑ์การลงทุนสำหรับ SME ที่ระดับ 1 (การมองเห็นข้อมูล) ตามแนวทางของกระทรวงเศรษฐกิจ การค้าและอุตสาหกรรมของญี่ปุ่น (METI) อยู่ที่ 3–10 ล้านเยน และโดยทั่วไปมักวางแผนมาตรฐานให้ ROI คืนทุนภายใน 3–5 ปี ตอนประเมินค่าใช้จ่ายของระบบจริงจากผลของ PoC ควรตรวจสอบสักครั้งว่าอยู่ในช่วงนี้หรือไม่ ถ้าหลุดออกไปมาก มีความเป็นไปได้สูงว่าขอบเขตขยายกว้างเกินไป หรือเก็บข้อมูลละเอียดเกินไป ส่วนวิธีแยกดูโครงสร้างของค่าใช้จ่ายนั้น เราจัดเป็น 5 ชั้นไว้ในคู่มือการนำ IoT มาใช้ในโรงงาน 2026

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

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

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

ควรหาตัวอย่างการใช้ IoT ในภาคการผลิตของไทยได้จากที่ไหน

แหล่งข้อมูลที่เปิดเผยต่อสาธารณะมีหลัก ๆ 3 แหล่ง คือ ตัวอย่างการติดตั้งที่ผู้ขายและ SIer เผยแพร่ (ส่วนใหญ่ไม่เปิดเผยชื่อบริษัท) บทความข่าวและงานสำรวจอย่าง JETRO หรือ NNA และเอกสารสัมมนาของนิคมอุตสาหกรรมหรือสมาคมในอุตสาหกรรม

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

ค่าใช้จ่ายในการนำ IoT มาใช้ที่ประเทศไทยอยู่ที่ประมาณเท่าไร

เปลี่ยนไปมากตามขนาดและขอบเขต จึงไม่มีคำตอบเดียว ในแง่เกณฑ์คร่าว ๆ มีการระบุระดับที่ขั้น PoC (ติดเซนเซอร์กับเครื่องจักร 1–2 เครื่อง ระยะเวลา 1–2 เดือน) อยู่ที่ 500,000–1,000,000 เยน และเกณฑ์การลงทุนสำหรับ SME ที่ระดับ 1 (การมองเห็นข้อมูล) ตามแนวทางของ METI อยู่ที่ 3–10 ล้านเยน ส่วน ROI โดยทั่วไปมักวางแผนมาตรฐานให้คืนทุนภายใน 3–5 ปี

สำหรับวิธีแยกโครงสร้างค่าใช้จ่าย (อุปกรณ์ การสื่อสาร คลาวด์ การพัฒนา การใช้งานและบำรุงรักษา) เพื่อประเมินราคานั้น เราแยกไว้เป็น 5 ชั้นอย่างละเอียดในคู่มือการนำ IoT มาใช้ในโรงงาน 2026 บทความนี้จะไม่ลงลึกในรายละเอียดของค่าใช้จ่าย

ถ้ามีแต่เครื่องจักรเก่า จะได้ผลแบบในตัวอย่างการใช้ IoT หรือไม่

ได้ผล หรือพูดให้ถูกกว่านั้นคือ โรงงานที่มีเครื่องเก่าเยอะกลับอธิบายผลของการมองเห็นสถานะการเดินเครื่องได้ง่ายกว่า ในหลายกรณี เพราะเครื่องใหม่มักมีบันทึก log ในตัวอยู่แล้ว จึงมีส่วนที่มองเห็นอยู่ก่อนแล้ว

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

จะติดตามสถานะการเดินเครื่องของโรงงานในไทยจากญี่ปุ่นได้หรือไม่

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

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

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

สิทธิประโยชน์ของ BOI ใช้กับการลงทุน IoT ได้หรือไม่

มีความเป็นไปได้ที่จะใช้ได้ สิ่งที่เกี่ยวข้องมากคือ การยกเว้นภาษีเงินได้นิติบุคคลเพิ่มอีก 3 ปีจากมาตรการยกระดับเทคโนโลยี (มาตรการ 10.1) การหักค่าฝึกอบรม 200% และการยกเว้นอากรขาเข้าสำหรับเซนเซอร์ IoT หุ่นยนต์อุตสาหกรรม อุปกรณ์ edge, GPU ฯลฯ ควรตรวจสอบกรอบที่ว่าการยกเว้นภาษีเงินได้นิติบุคคลมีสูงสุด 8 ปี (ใช้ร่วมกับ EEC ได้สูงสุด 15 ปี) และหลังสิ้นสุดการยกเว้นยังลดหย่อน 50% ได้อีก 5 ปี ควบคู่กันไปด้วย

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

ต้องตัดสินอะไรไว้บ้างเพื่อไม่ให้หยุดอยู่แค่ PoC

มี 3 ข้อ

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

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

ข้อที่สาม เขียนเกณฑ์เดินหน้า/หยุดไว้ก่อนเริ่ม PoC ถ้ามาคิดเกณฑ์การตัดสินหลังจบแล้ว มันจะกลายเป็น “ขอดูสถานการณ์อีกสักหน่อย” แล้วก็ค่อย ๆ หายไปเอง เกณฑ์ให้เขียนเป็นตัวเลข (อัตราข้อมูลขาดหาย อัตราการกรอก จำนวนครั้งที่ตัดสินมาตรการได้ ฯลฯ)

ทั้ง 3 ข้อนี้เขียนลงกระดาษแผ่นเดียวได้ก่อนเริ่ม PoC ถ้าเขียนไม่ได้ ก็แปลว่ายังไม่ถึงขั้นที่จะเข้าสู่ PoC ซึ่งเป็นจุดยืนที่บทความนี้ยึดมาตลอดทั้งเรื่อง

สรุป

ขอเรียบเรียงจุดที่ต้องจับให้แน่นเวลาอ่านตัวอย่างการใช้ IoT ในภาคการผลิตของไทย

• เบื้องหลังการที่การนำมาใช้เพิ่มขึ้นในปี 2026 คือ อัตราการขึ้นเงินเดือน 4.64% ในบริษัทญี่ปุ่นและการขึ้นปีละ 5–8% ของช่างเทคนิค การเอียงไปทางดิจิทัลของ BOI (ไตรมาส 1 ปี 2026 อนุมัติ 649 โครงการ 330,132 ล้านบาท) และการขยายตัวของตลาดสมาร์ทแฟคทอรี่ (ตามข่าวราว 54,000 ล้านเยน โตกว่า 10%)
• ตัวอย่างที่อ่านแบบ “เขาใส่อะไรเข้าไป” ทำซ้ำไม่ได้ ให้อ่านด้วยชุด 4 จุด คือ ปัญหา → สิ่งที่วัด → การตัดสินใจที่เชื่อมต่อ → ตัวเลขที่เปลี่ยนไป
• ในทางปฏิบัติแบ่งได้ 5 รูปแบบ คือ A การมองเห็นสถานะการเดินเครื่อง / B สัญญาณเตือนก่อนเครื่องเสีย / C การไล่ของเสียในกระบวนการ / D การดูไฟฟ้าเป็นรายกระบวนการ / E การมอนิเตอร์ระยะไกลจากสำนักงานใหญ่ ถ้ายังไม่ได้ตัดสินว่าจะเริ่มจากอะไร เลือก A ได้เลย
• เส้นแบ่งระหว่างการอยู่รอดกับการหยุดชะงักมี 5 ข้อ คือ ตัดสินการตัดสินใจไว้ก่อนหรือไม่ คนที่ดูเป็นพนักงานคนไทยหรือไม่ ทำข้อมูลให้ละเอียดขึ้นภายหลังได้หรือไม่ ตกลงขอบเขตการเข้าไปยุ่งกับเครื่องเดิมแล้วหรือยัง และเป็นรูปแบบที่ไม่หายไปเมื่อพนักงานญี่ปุ่นประจำการสับเปลี่ยนหรือไม่
• ประเด็นเฉพาะของไทยคือ สภาพแวดล้อมการสื่อสารในโรงงาน ฟ้าผ่าและไฟดับในฤดูฝน การยื่นขอสิทธิประโยชน์ BOI ล่วงหน้า UI ภาษาไทยและการจัดเวรผู้ดูแล และโครงสร้างการรับมือขั้นต้นในประเทศ
• 90 วันแรก คือ 0–30 วันสำรวจปัญหาและตัดสิน KPI 1 ตัว 31–60 วันทำ PoC (1–2 เดือน / 500,000–1,000,000 เยน / เครื่องจักร 1–2 เครื่อง) และ 61–90 วันตัดสิน โดยเขียนเกณฑ์การตัดสินไว้ตั้งแต่ช่วง 0–30 วัน

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

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