ราคา i-Reporter 2026 เทียบต้นทุนรวม 5 ปีของ 3 รูปแบบ และเวลาคีย์ข้อมูลซ้ำที่ตัดสินการคืนทุน

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

สรุป ราคา i-Reporter ขึ้นกับ 3 รูปแบบ แต่ตัวตัดสินว่าควรลงทุนหรือไม่คือเวลาคีย์ข้อมูลซ้ำ

ขอสรุปก่อนใน 3 บรรทัด

1. ถ้าเรียงต้นทุนรวม 5 ปีที่ฐาน 5 ผู้ใช้ และไม่มีการเชื่อมต่อระบบภายนอก จากถูกไปแพงคือ ออนพรีมิส PA (1,865,500 เยน) < ออนพรีมิส SU (2,137,500 เยน) < คลาวด์ (2,365,000 เยน)
2. เมื่อบวกชุด API เชื่อมต่อระบบภายนอกเข้าไป อันดับของออนพรีมิส SU กับคลาวด์จะสลับกัน ถ้าไม่มี API ออนพรีมิส SU ถูกกว่าคลาวด์ 227,500 เยน แต่เมื่อรวม API แล้ว ออนพรีมิส SU กลับแพงกว่าคลาวด์ 237,500 เยน คิดเป็นการพลิกกลับรวม 465,000 เยน
3. ถึงอย่างนั้น ตัวที่ตัดสินว่าควรลงทุนหรือไม่ก็ยังไม่ใช่อันดับนี้ ค่าไลเซนส์รายปีของโครงสร้าง 5 ผู้ใช้ (ออนพรีมิส SU ปีละ 427,500 เยน เท่ากับประมาณ 88,900 บาท) กิน ประมาณ 92% ของผลประโยชน์รายปีในกรณีที่ลดการคีย์ข้อมูลซ้ำได้วันละ 4 ชั่วโมง (ประมาณ 96,600 บาท) ถ้าเวลาคีย์ข้อมูลซ้ำไม่มากพอ เลือกรูปแบบไหนก็ไม่คืนทุน

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

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

i-Reporter คืออะไร ผู้พัฒนาคือ CIMTOPS และข้อมูลจากญี่ปุ่นใช้ได้ถึงไหน

ตัวผลิตภัณฑ์และผู้พัฒนา

i-Reporter เป็น ระบบฟอร์มอิเล็กทรอนิกส์ที่พัฒนาและให้บริการโดยบริษัท CIMTOPS (ชิมท็อปส์ / CIMTOPS Corporation) ส่วน TOMAS TECH อยู่ในฐานะผู้ดูแลผลิตภัณฑ์ของ CIMTOPS ในประเทศไทย รับผิดชอบการสนับสนุนการนำไปใช้ในไทย การออกแบบฟอร์ม และการซัพพอร์ตในพื้นที่ ราคาทั้งหมดที่ปรากฏในบทความนี้เป็นตัวเลขที่บริษัท CIMTOPS และตัวแทนจำหน่ายในญี่ปุ่นประกาศไว้ ไม่ใช่ราคาที่เรากำหนดขึ้นเอง

คุณสมบัติพื้นฐานของตัวผลิตภัณฑ์มีดังนี้

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

สำหรับผลงานการติดตั้ง มีการเผยแพร่ว่า ณ เวลาที่แสดงบนเว็บไซต์ทางการคือมากกว่า 4,500 บริษัท และผู้ใช้มากกว่า 220,000 คน ส่วนส่วนแบ่งตลาดคือ 46.5% ในปี 2024 (เป็นตัวเลขทางการที่อ้างอิงรายงานของ Fuji Chimera Research เดือนกุมภาพันธ์ 2026)

อย่านำตัวเลขที่คนละช่วงเวลามาปนกัน

ตรงนี้ต้องระวัง ตัวเลขที่ระบุไว้ ณ เวลาของข่าวประชาสัมพันธ์เรื่องการปรับราคาเมื่อเดือนมกราคม 2026 คือ มากกว่า 4,000 บริษัท ผู้ใช้มากกว่า 210,000 คน และส่วนแบ่งตลาด 48.6% ในปี 2023 ตัวเลขบนเว็บไซต์ทางการกับตัวเลขในข่าวประชาสัมพันธ์ต่างก็เป็นตัวเลขที่เผยแพร่อย่างเป็นทางการทั้งคู่ แต่ ช่วงเวลาอ้างอิงไม่เหมือนกัน

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

ตารางราคาของญี่ปุ่นไม่ได้ใช้กับไทยได้ตรง ๆ เสมอไป

ราคาที่บทความนี้พูดถึงทั้งหมดเป็น ราคาที่ประกาศสำหรับตลาดในประเทศญี่ปุ่น สำหรับตลาดต่างประเทศมีเว็บไซต์ ireporter-global.com แยกไว้ต่างหาก และ มีหน้าภาษาไทยด้วย แต่ ราคาสำหรับตลาดต่างประเทศไม่ได้เปิดเผยไว้

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

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

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

ขั้นตอนการคัดเลือกระบบฟอร์มอิเล็กทรอนิกส์และภาพรวมของทางเลือกอื่นนอกจาก i-Reporter เราสรุปไว้ใน คู่มือการนำระบบฟอร์มอิเล็กทรอนิกส์มาใช้ 2026 ส่วนบทความนี้จะเจาะเฉพาะเรื่องราคาและการคืนทุน

จัดราคาประกาศหลังปรับเมื่อมกราคม 2026 ให้อยู่ในหน้าเดียว

ตารางเทียบก่อนและหลังปรับราคา

การปรับราคามีผลตั้งแต่วันที่ 1 มกราคม 2026 ตารางด้านล่างเป็น ราคาประกาศที่ฐาน 5 ผู้ใช้ ส่วนการจัดการเรื่องภาษีเปลี่ยนไปตามรูปแบบสัญญา จึงควรยืนยันในใบเสนอราคา

หมายเหตุ SU หมายถึงแบบสมัครใช้บริการ (จ่ายรายเดือนหรือรายปี) และ PA หมายถึงแบบแพ็กเกจซื้อขาด (จ่ายก้อนเดียว + ค่าบำรุงรักษารายปี)

สัดส่วนค่าบำรุงรักษารายปีไม่เปลี่ยนเลยทั้งก่อนและหลังปรับราคา ก่อนปรับคือ 135,000 ÷ 900,000 = 15.0% หลังปรับคือ 159,900 ÷ 1,066,000 = 15.0% โครงสร้างจึงเป็นแบบ อัตราค่าบำรุงรักษาคงเดิม แต่ค่าบำรุงรักษาขยับขึ้นตามค่าเริ่มต้นที่สูงขึ้น ส่วนอัตราการเพิ่มของค่าเริ่มต้นรวมของออนพรีมิส PA คือ 166,000 ÷ 900,000 = ประมาณ 18.4%

เหตุผลของการปรับราคาที่มีการเผยแพร่ไว้คือ ค่าดำเนินการเซิร์ฟเวอร์และต้นทุนพลังงานของดาต้าเซ็นเตอร์ที่พุ่งสูงขึ้น รวมถึงค่าซอฟต์แวร์และค่าคลาวด์จากต่างประเทศที่แพงขึ้นจากเงินเยนอ่อน ความต่างที่ว่า คลาวด์ขึ้น 12% แต่ออนพรีมิส SU คงเดิม สอดคล้องกับคำอธิบายนี้ เพราะส่วนที่ขึ้นราคาคือส่วนที่ฝั่งผู้ให้บริการเป็นคนแบกต้นทุนโครงสร้างพื้นฐานเอง

ส่วนต่างระหว่างค่ารายเดือนคูณ 12 กับค่ารายปี คือ 1 เดือน หรือ 0.6 เดือน

นี่เป็นประเด็นที่มักถูกมองข้าม เนื่องจากมีการประกาศทั้งค่ารายเดือนและค่ารายปี เราจึงคำนวณส่วนลดของการจ่ายรายปีล่วงหน้าได้

ค่ารายปีของคลาวด์ถูกหักออก พอดี 1 เดือน ส่วนออนพรีมิส SU หักออก 0.6 เดือน ข้อเท็จจริงที่อ่านได้จากราคาประกาศคือ ส่วนลดของการจ่ายรายปีล่วงหน้าฝั่งคลาวด์ให้มากกว่า

ส่วนต่างนี้ไม่เล็กเมื่อมองยาว 5 ปี ยอดจ่าย 5 ปีกรณีจ่ายรายเดือนตลอด คลาวด์คือ 55,000 + 504,000 × 5 = 2,575,000 เยน และออนพรีมิส SU คือ 450,000 × 5 = 2,250,000 เยน เมื่อเปลี่ยนไปจ่ายรายปีล่วงหน้า จะประหยัดได้ 210,000 เยนสำหรับคลาวด์ และ 112,500 เยนสำหรับออนพรีมิส SU ถ้าเลือกจ่ายรายเดือนด้วยเหตุผลด้านกระแสเงินสด นี่คือต้นทุนของการตัดสินใจนั้น

ชุด API เชื่อมต่อระบบภายนอก

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

โครงสร้างส่วนลดเป็นชุดเดียวกับตัวระบบหลัก (คลาวด์ 11 เดือน ออนพรีมิส SU 11.4 เดือน) และค่าบำรุงรักษา API ของออนพรีมิส PA ก็คือ 126,000 ÷ 840,000 = 15.0% เท่ากับอัตราค่าบำรุงรักษาของตัวหลัก

ตรงนี้คือราคาประกาศที่สำคัญที่สุดของบทความนี้ ค่ารายปีของชุด API คือคลาวด์ 363,000 เยน และออนพรีมิส SU 456,000 เยน ออนพรีมิส SU แพงกว่าปีละ 93,000 เยน และตัวเลข 93,000 เยนนี้เองที่จะไปพลิกอันดับในภายหลัง

ที่ประกาศไว้มีเพียงฐาน 5 ผู้ใช้เท่านั้น

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

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

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

เรียงลำดับด้วยต้นทุนรวม 5 ปี (กรณี 5 ผู้ใช้)

เขียนสมมติฐานไว้ก่อน

นี่คือสมมติฐานของการประมาณการด้านล่าง ถ้าเปลี่ยนตรงนี้ ข้อสรุปก็เปลี่ยนตาม

• โครงสร้าง 5 ผู้ใช้ (เป็นโครงสร้างเดียวที่มีราคาประกาศ)
• ไม่ใช้ชุด API เชื่อมต่อระบบภายนอก (กรณีใช้จะคำนวณแยกในหัวข้อถัดไป)
• จ่ายรายปีล่วงหน้า (ไม่ใช่จ่ายรายเดือน)
• ออนพรีมิสใช้เซิร์ฟเวอร์เดิมที่มีอยู่แล้ว จึงไม่รวมค่าซื้อตัวเครื่องเซิร์ฟเวอร์
• ระยะเวลา 5 ปี
• อัตราแลกเปลี่ยนใช้ 1 บาท = 4.81 เยน (ณ วันที่ 11 สิงหาคม 2026) เป็นค่าเดียวทั้งบทความ ค่าเฉลี่ยของปี 2026 อยู่ที่ประมาณ 4.96 สูงสุด 5.10 ต่ำสุด 4.84 การแปลงเป็นบาทในบทความนี้คิดที่ 4.81 ทั้งหมด

การคำนวณ

อันดับคือ ออนพรีมิส PA < ออนพรีมิส SU < คลาวด์

เมื่อหารกลับเป็นต่อเดือนจะได้ตามนี้ (หารด้วย 60 เดือน ซึ่งเท่ากับ 5 ปี)

แปลงส่วนต่างให้เป็น “ค่าดูแลเซิร์ฟเวอร์ต่อปี”

ส่วนต่างระหว่างคลาวด์กับออนพรีมิส PA คือ 2,365,000 − 1,865,500 = 499,500 เยน (ประมาณ 103,800 บาท) เมื่อหารด้วย 5 ปีจะได้ ประมาณ 20,800 บาทต่อปี หรือ ประมาณ 1,730 บาทต่อเดือน

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

ดังนั้น ถ้าการดูแลเซิร์ฟเวอร์ของบริษัทมีต้นทุนตั้งแต่ประมาณ 21,000 บาทต่อปี (ประมาณ 1,730 บาทต่อเดือน) ขึ้นไป ความได้เปรียบด้านราคาของออนพรีมิส PA จะหายไป และจำนวนเงินระดับนี้ถือว่าไม่มากเลยสำหรับการดูแลเซิร์ฟเวอร์เพียงเครื่องเดียว ซื้อเซิร์ฟเวอร์เฉพาะทางเครื่องใหม่ ติดตั้ง UPS จัดที่เก็บข้อมูลสำรอง หรือบวกชั่วโมงงานของผู้ดูแลเข้าไป เพียงข้อใดข้อหนึ่งเกิดขึ้น อันดับของต้นทุนรวม 5 ปีก็มีสิทธิ์สลับได้

อันดับจะสลับที่ปีไหน

ออนพรีมิส PA ที่มีค่าเริ่มต้นสูงย่อมเสียเปรียบในระยะสั้น เราจึงหาจำนวนปีที่ยอดจ่ายสะสมเท่ากัน

• ออนพรีมิส PA เทียบกับคลาวด์ 1,066,000 + 159,900n = 55,000 + 462,000n จะได้ n = 1,011,000 ÷ 302,100 = ประมาณ 3.3 ปี
• ออนพรีมิส PA เทียบกับออนพรีมิส SU 1,066,000 + 159,900n = 427,500n จะได้ n = 1,066,000 ÷ 267,600 = ประมาณ 4.0 ปี

แปลว่า ถ้าใช้งานไม่ถึงประมาณ 3.3 ปี คลาวด์ถูกกว่าออนพรีมิส PA และถ้าไม่ถึงประมาณ 4.0 ปี ออนพรีมิส SU ถูกกว่าออนพรีมิส PA โปรดสังเกตว่าตัวตั้งในการเทียบทั้งสองคู่คือออนพรีมิส PA ในโครงสร้างที่ไม่ใช้ API เชื่อมต่อระบบภายนอก ตัวที่ถูกที่สุดตลอดช่วงเวลานี้คือออนพรีมิส SU อย่างสม่ำเสมอ (ห่างจากคลาวด์ 227,500 เยนเมื่อครบ 5 ปี) ออนพรีมิส PA จะกลายเป็นตัวที่ถูกที่สุดก็ต่อเมื่อมั่นใจว่าจะใช้งานต่อเนื่องอย่างน้อย 4 ปีขึ้นไปเท่านั้น

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

3 เงื่อนไขที่ทำให้อันดับสลับ (ค่าเซิร์ฟเวอร์ / API เชื่อมต่อระบบภายนอก / จำนวนผู้ใช้)

อันดับในหัวข้อที่แล้วจะสลับทันทีเมื่อเงื่อนไขข้อใดข้อหนึ่งใน 3 ข้อนี้เปลี่ยนไป

เงื่อนไขที่ 1 ค่าดูแลเซิร์ฟเวอร์ของบริษัทเอง

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

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

เงื่อนไขที่ 2 API เชื่อมต่อระบบภายนอก จุดที่อันดับพลิกกลับ

ด้านล่างคือต้นทุนรวม 5 ปีในกรณีที่ต้องเชื่อมกับระบบบริหารการผลิตหรือ ERP โดยใช้สมมติฐานชุดเดียวกับหัวข้อก่อน (5 ผู้ใช้ จ่ายรายปีล่วงหน้า ใช้เซิร์ฟเวอร์เดิม ระยะเวลา 5 ปี)

อันดับเปลี่ยนเป็น ออนพรีมิส PA < คลาวด์ < ออนพรีมิส SU

ทำไมจึงเป็นเช่นนั้น ขอแยกออกมาเป็นสูตร

• ส่วนต่างค่ารายปีของตัวระบบหลัก คลาวด์ 462,000 − ออนพรีมิส SU 427,500 = SU ถูกกว่าปีละ 34,500 เยน
• ส่วนต่างค่ารายปีของ API ออนพรีมิส SU 456,000 − คลาวด์ 363,000 = SU แพงกว่าปีละ 93,000 เยน
• รวมกัน SU แพงกว่าปีละ 58,500 เยน

เนื่องจากคลาวด์มีค่าเริ่มต้น 55,000 เยน จุดที่ยอดสะสมพลิกกลับจึงอยู่ที่ 55,000 ÷ 58,500 = ประมาณ 0.94 ปี นั่นคือ พลิกกลับตั้งแต่ปีแรกแล้ว (ปีที่ 1 ออนพรีมิส SU 883,500 เยน เทียบกับคลาวด์ 880,000 เยน SU แพงกว่า 3,500 เยน)

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

ขอคำนวณจุดพลิกของออนพรีมิส PA ในกรณีที่มี API ไว้ด้วย

• ออนพรีมิส PA เทียบกับคลาวด์ (มี API) ค่าเริ่มต้น 1,906,000 + ปีละ 285,900n = 55,000 + ปีละ 825,000n จะได้ n = 1,851,000 ÷ 539,100 = ประมาณ 3.4 ปี
• ออนพรีมิส PA เทียบกับออนพรีมิส SU (มี API) n = 1,906,000 ÷ 597,600 = ประมาณ 3.2 ปี

แม้จะมี API จุดที่ PA กลายเป็นตัวถูกที่สุดก็ยังอยู่ในช่วงต้น ๆ ของปีที่ 3 ซึ่งแทบจะตำแหน่งเดียวกับกรณีไม่มี API (3.3 ปี และ 4.0 ปี) สิ่งที่การมีหรือไม่มี API เปลี่ยนจึงไม่ใช่จุดพลิกกับ PA แต่เป็นลำดับสูงต่ำระหว่างคลาวด์กับออนพรีมิส SU

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

เงื่อนไขที่ 3 จำนวนผู้ใช้

เงื่อนไขข้อนี้คำนวณไม่ได้ด้วยข้อมูลที่เปิดเผยเพียงอย่างเดียว

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

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

พูดสั้น ๆ คือ อย่านำอันดับที่ได้จากฐาน 5 ผู้ใช้ ไปใช้กับ 20 ผู้ใช้หรือ 50 ผู้ใช้ตรง ๆ เมื่อจำนวนคนเปลี่ยน คำตอบที่ถูกต้องมีทางเดียวคือขอใบเสนอราคาใหม่

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

5 ค่าใช้จ่ายที่ไม่ปรากฏในตารางราคาของญี่ปุ่น (มุมมองต้นทุนจริงของโรงงานในไทย)

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

ค่าใช้จ่ายที่ 1 การออกแบบฟอร์มและการสนับสนุนการติดตั้งใช้งาน

สมมติฐานเชิงโมเดลของบทความนี้ 250,000 ถึง 600,000 บาท (ค่ากลาง 425,000 บาท)

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

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

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

ค่าใช้จ่ายที่ 2 แท็บเล็ตและอุปกรณ์สำหรับกรอกข้อมูล

สมมติฐานเชิงโมเดลของบทความนี้ 5 เครื่อง 125,000 บาท (เครื่องละ 25,000 บาท)

เนื่องจาก i-Reporter ใช้ 1 User ID กับอุปกรณ์ได้ไม่จำกัดจำนวน จึงไม่จำเป็นต้องให้จำนวนไลเซนส์เท่ากับจำนวนเครื่อง จะใช้ไลเซนส์ 5 ผู้ใช้แล้ววางอุปกรณ์ 10 เครื่องก็ได้ จุดนี้เป็นความต่างที่สำคัญเวลานำไปเทียบกับผลิตภัณฑ์ที่คิดไลเซนส์ตามเครื่อง

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

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

ค่าใช้จ่ายที่ 3 เซิร์ฟเวอร์และโครงสร้างพื้นฐาน (กรณีเลือกออนพรีมิส)

จุดพลิกคือประมาณ 20,800 บาทต่อปี ตามที่คำนวณไว้ในหัวข้อก่อน

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

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

ค่าใช้จ่ายที่ 4 ภาษาที่ใช้ในการทำงานและการอบรม

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

โครงสร้างแบบนี้จะกลายเป็นค่าใช้จ่ายในจังหวะต่อไปนี้

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

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

ค่าใช้จ่ายที่ 5 การปรับปรุงและบำรุงรักษาฟอร์ม

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

สิ่งที่ต้องตรวจสอบไม่ใช่ตัวเงิน แต่คือโครงสร้างการทำงาน

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

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

หากกำลังพิจารณาทางเลือกที่พัฒนาเองภายในองค์กรเพื่อใส่ฟังก์ชันเฉพาะของหน้างาน แนะนำให้ดู แนวทางพัฒนาแอปพลิเคชันสำหรับโรงงาน ประกอบด้วย

วิธีคำนวณระยะเวลาคืนทุน วัดจากเวลาคีย์ข้อมูลซ้ำอย่างเดียว (เลี่ยงการนับซ้ำซ้อน)

ตรงนี้คือแก่นของบทความ

เปิดสมมติฐานทั้งหมด

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

มีสถานการณ์เปรียบเทียบเพียงชุดเดียว เราเทียบเฉพาะระหว่าง “กรอกลงกระดาษ แล้วคีย์ซ้ำลง Excel” กับ “กรอกลงแท็บเล็ต ไม่มีการคีย์ซ้ำ” เท่านั้น

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

การคำนวณมูลค่าผลประโยชน์

มูลค่าผลประโยชน์ต่อการคีย์ข้อมูลซ้ำ 1 ชั่วโมงเป็นดังนี้

130.68 บาทต่อชั่วโมง × อัตราการหายไป 0.7 = ประมาณ 91.5 บาทต่อชั่วโมง

มูลค่าผลประโยชน์ต่อปีหาได้จาก “เวลาคีย์ข้อมูลซ้ำต่อวัน × 264 วัน × 91.5”

“คีย์ข้อมูลซ้ำวันละ 8 ชั่วโมง” ไม่ได้แปลว่ามีคน 1 คนนั่งคีย์ทั้งวัน การอ่านที่ใกล้ความจริงกว่าคือ ยอดรวมของคน 3 คนที่คีย์คนละ 2 ถึง 3 ชั่วโมง กระจายอยู่ในฟอร์มหลายประเภท ให้เริ่มจากการวัดเวลารวมก้อนนี้ก่อน ถ้าไม่วัดแล้วลงมือติดตั้งเลย การถกเรื่องคืนทุนจะไม่มีฐานให้ยืน

การคำนวณค่าใช้จ่าย

เราเลือกรูปแบบ ออนพรีมิส SU 5 ผู้ใช้ ใช้เซิร์ฟเวอร์เดิม ไม่มีการเชื่อมต่อระบบภายนอก เหตุผลคือค่าเริ่มต้นเบาที่สุดและย้ายจากช่วงนำร่องไปสู่การใช้งานจริงได้ง่าย (ตามที่กล่าวไปแล้วว่าถ้าใช้เกิน 4 ปี ออนพรีมิส PA จะถูกกว่า)

ระยะเวลาคืนทุน

ระยะเวลาคืนทุน = ค่าเริ่มต้น ÷ (มูลค่าผลประโยชน์ต่อปี − ค่าใช้จ่ายรายปี)

ลองดูแถวที่คีย์ข้อมูลซ้ำวันละ 4 ชั่วโมง ระยะเวลาคืนทุนคือประมาณ 71 ปี ในทางปฏิบัติแปลว่าไม่คืนทุน

เหตุผลชัดเจน เพราะค่าไลเซนส์รายปี 88,900 บาท กินไปแล้ว 92.0% ของมูลค่าผลประโยชน์ต่อปี 96,600 บาท (88,900 ÷ 96,600 = 0.920) ผลประโยชน์สุทธิที่เหลือมีแค่ปีละ 7,700 บาท จึงต้องใช้เวลา 71 ปีกว่าจะถมค่าเริ่มต้น 550,000 บาทได้

บรรทัดนี้คือบรรทัดที่บทความนี้อยากสื่อที่สุด ต่อให้เทียบต้นทุนรวม 5 ปีของทั้ง 3 รูปแบบละเอียดแค่ไหน ในโครงการที่ตกลงมาอยู่ในแถวนี้ อันดับก็ไม่มีความหมาย ก่อนจะถกกันว่าจะเลือก 1,865,500 เยน หรือ 2,365,000 เยน ให้ตรวจสอบก่อนว่าเวลาคีย์ข้อมูลซ้ำมีมากพอหรือยัง

เวลาคีย์ข้อมูลซ้ำ ณ จุดคุ้มทุน

ถ้าตั้งเงื่อนไขว่า “ต้องคืนทุนภายใน 5 ปี” เราคำนวณย้อนกลับหาเวลาคีย์ข้อมูลซ้ำที่จำเป็นได้

ผลประโยชน์สุทธิต่อปีที่ต้องการ = ค่าเริ่มต้น ÷ 5 จากนั้นบวกค่าใช้จ่ายรายปี 88,900 เข้าไป จะได้มูลค่าผลประโยชน์ต่อปีที่ต้องการ นำไปหารด้วย 91.5 จะได้เวลาคีย์ข้อมูลซ้ำต่อปี แล้วหารด้วย 264 จะได้เวลาคีย์ข้อมูลซ้ำต่อวัน

ต่อให้กดค่าเริ่มต้นลงมาถึงขั้นต่ำ ก็ยังต้องมีการคีย์ข้อมูลซ้ำวันละ 6.8 ชั่วโมง ถ้าใช้สมมติฐานค่ากลางคือ 8.2 ชั่วโมง ซึ่งสอดคล้องกับตารางก่อนหน้าที่กรณี 8 ชั่วโมงต่อวันให้ระยะเวลาคืนทุน 5.3 ปี (เกิน 5 ปีมาเล็กน้อย)

พูดอีกอย่างคือ การทำให้คืนทุนด้วยการต่อรองลดค่าเริ่มต้นเป็นเรื่องยาก ต่อให้ตัดจากค่ากลางลงมาถึงขั้นต่ำเป็นเงิน 175,000 บาท เวลาคีย์ข้อมูลซ้ำที่ต้องการก็ลดจาก 8.2 ชั่วโมงเหลือ 6.8 ชั่วโมงเท่านั้น คานงัดที่ควรออกแรงอยู่ที่อื่น

ดังนั้นทางออกไม่ใช่ “เลือกรูปแบบที่ถูกที่สุด” แต่คือ “รวบรวมเวลาคีย์ข้อมูลซ้ำ”

ข้อสรุปเชิงปฏิบัติที่ได้จากตารางข้างบนคือ

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

เหตุผลอยู่ที่โครงสร้างค่าใช้จ่าย

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

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

ผลพลอยได้ที่ไม่ได้นำเข้าการคำนวณคืนทุน

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

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

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

ปี 2026 ไทยเตรียมยกเครื่องกฎหมายธุรกรรมทางอิเล็กทรอนิกส์ ประเด็นที่ตัดสินก่อนราคา

กำลังเกิดอะไรขึ้น

สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) ได้เปิดเผย ร่างแก้ไขกฎหมายว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ (ETA) ทั้งฉบับ และจัดรับฟังความคิดเห็นสาธารณะ ระหว่างวันที่ 12 พฤษภาคม ถึง 15 มิถุนายน 2026 ไม่ใช่การแก้ไขบางมาตรา แต่เป็น การเขียนใหม่ทั้งฉบับ คาดว่ากว่าจะถึงขั้นการพิจารณาของรัฐสภายังต้องใช้เวลาอีกไม่เกินประมาณ 1 ปี

สาระสำคัญของร่างมี 3 ข้อ

นัยสำหรับภาคการผลิต

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

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

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

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

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

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

วิธีเลือกฟอร์มชุดแรกที่จะทำเป็นดิจิทัล (4 เงื่อนไข)

นี่คือเกณฑ์คัดเลือกเชิงปฏิบัติที่ได้จากการคำนวณในบทที่ 7 เกณฑ์นี้เป็นมุมมองของเราเอง ไม่ใช่ข้อมูลปฐมภูมิ

ในเมื่อสิ่งที่ตัดสินการคืนทุนคือปริมาณรวมของเวลาคีย์ข้อมูลซ้ำ ฟอร์มที่ควรทำเป็นดิจิทัลก่อนจึงคือ “ฟอร์มที่ก่อให้เกิดเวลาคีย์ข้อมูลซ้ำมากที่สุด” ให้คัดเลือกด้วย 4 เงื่อนไขต่อไปนี้

เงื่อนไขที่ 1 หลังกรอกแล้ว มีใครนำไปคีย์ซ้ำลง Excel หรือระบบหลักหรือไม่

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

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

เงื่อนไขที่ 2 เกิดขึ้นทุกวัน หลายรอบ และหลายแผ่นหรือไม่

มูลค่าผลประโยชน์ต่อปีถูกกำหนดโดย “เวลาคีย์ข้อมูลซ้ำต่อวัน × 264 วัน” ฟอร์มที่เกิดขึ้นไม่บ่อย ต่อให้ใช้เวลาคีย์ต่อแผ่นนานแค่ไหน ก็สะสมเป็นปริมาณรวมไม่ได้

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

เงื่อนไขที่ 3 แบบฟอร์มเดียวกันถูกใช้ในหลายไลน์หรือหลายฐานการผลิตหรือไม่

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

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

เงื่อนไขที่ 4 มีงานยกเว้นน้อยและแบบฟอร์มนิ่งแล้วหรือไม่

นี่คือเหตุผลที่บทที่ 7 ตั้งอัตราการหายไปของงานคีย์ข้อมูลซ้ำไว้ที่ 70% ฟอร์มที่มีข้อยกเว้นเยอะ ต่อให้ทำดิจิทัลแล้วกระดาษก็ยังอยู่ ทำให้อัตราการหายไปลดลง

• ฟอร์มที่ต้องเขียนหมายเหตุเพิ่มด้วยลายมือเสมอ
• ฟอร์มที่แบบฟอร์มต่างกันตามลูกค้าแต่ละราย
• ฟอร์มที่ต้องมีลายเซ็นของผู้ร่วมสังเกตการณ์แบบกายภาพ

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

ตารางตรวจสอบ 4 เงื่อนไข

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

เทียบกับแนวทางอื่น (โนโค้ด / ฟอร์มในตัว MES / OCR ทั่วไป) และจุดที่ตัดสินใจต่างกัน

ขอสรุปทางเลือกอื่นนอกจาก i-Reporter และจุดที่การตัดสินใจแยกทางกัน ด้านล่างเป็นการเทียบคุณลักษณะของแต่ละแนวทาง ไม่ใช่การเทียบราคาของผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง เพราะราคาของแต่ละแนวทางต่างกันมากตามผลิตภัณฑ์ จึงสรุปเป็นตัวเลขรวมไม่ได้

จุดตัดสินใจมี 3 จุด

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

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

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

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

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

ราคา i-Reporter อยู่ที่เท่าไร

ราคาประกาศสำหรับตลาดญี่ปุ่นหลังปรับเมื่อวันที่ 1 มกราคม 2026 (ฐาน 5 ผู้ใช้) เป็นดังนี้ คลาวด์คือค่าเริ่มต้น 55,000 เยน + ค่ารายปี 462,000 เยน ออนพรีมิสแบบสมัครใช้บริการ (SU) คือค่ารายปี 427,500 เยน และออนพรีมิสแบบแพ็กเกจ (PA) คือค่าเริ่มต้น 1,066,000 เยน + ค่าบำรุงรักษารายปี 159,900 เยน

เมื่อแปลงเป็นต้นทุนรวม 5 ปีจะได้ ออนพรีมิส PA 1,865,500 เยน < ออนพรีมิส SU 2,137,500 เยน < คลาวด์ 2,365,000 เยน (ภายใต้สมมติฐานว่าไม่มี API เชื่อมต่อระบบภายนอก ใช้เซิร์ฟเวอร์เดิม และจ่ายรายปีล่วงหน้า)

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

i-Reporter ใช้ในประเทศไทยได้หรือไม่

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

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

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

ระหว่างคลาวด์กับออนพรีมิส อันไหนถูกกว่า

อันดับสลับกันได้ตามเงื่อนไข

ถ้าเทียบแบบไม่มี API เชื่อมต่อระบบภายนอก ที่ฐาน 5 ผู้ใช้ ระยะ 5 ปี ออนพรีมิส SU จะถูกกว่าคลาวด์ 227,500 เยน แต่ เมื่อเพิ่มชุด API เชื่อมต่อระบบภายนอกเข้าไป ออนพรีมิส SU จะแพงกว่าคลาวด์ 237,500 เยน ทำให้อันดับพลิกกลับ เพราะค่ารายปีของชุด API อยู่ที่คลาวด์ 363,000 เยน เทียบกับออนพรีมิส SU 456,000 เยน ต่างกันปีละ 93,000 เยน

นอกจากนี้ ออนพรีมิสแบบแพ็กเกจ (ซื้อขาด) จะกลายเป็นตัวที่ถูกที่สุดก็ต่อเมื่อใช้งานต่อเนื่องเกินประมาณ 3.3 ปีเมื่อเทียบกับคลาวด์ และเกินประมาณ 4.0 ปีเมื่อเทียบกับออนพรีมิส SU ถ้าสั้นกว่านั้นแบบสมัครใช้บริการจะถูกกว่า และเพิ่มเติมคือ ถ้าค่าดูแลเซิร์ฟเวอร์ของบริษัทเองเกินประมาณ 20,800 บาทต่อปี ความได้เปรียบด้านราคาของออนพรีมิส PA จะหายไป

ถ้าใช้ระบบฟอร์มอิเล็กทรอนิกส์แล้ว ฟอร์มกระดาษจะหมดไปทั้งหมดหรือไม่

ไม่หมดไป ในการประมาณการของบทความนี้ เราตั้งอัตราการหายไปของงานคีย์ข้อมูลซ้ำไว้ที่ 70% สาเหตุหลักของ 30% ที่เหลือมีดังนี้

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

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

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

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

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

สรุป

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

ขอเขียนแก่นสำคัญอีกครั้ง ค่าไลเซนส์รายปีของโครงสร้าง 5 ผู้ใช้ประมาณ 88,900 บาท กินไป 92% ของมูลค่าผลประโยชน์ต่อปีประมาณ 96,600 บาท ในกรณีคีย์ข้อมูลซ้ำวันละ 4 ชั่วโมง ตราบใดที่โครงสร้างนี้ยังอยู่ การเทียบราคาของ 3 รูปแบบก็ไม่ใช่คำตอบว่าควรลงทุนหรือไม่ คนที่ถือคำตอบไว้ไม่ใช่ตารางราคา แต่เป็นนาฬิกาจับเวลาที่หน้างาน

และขอย้ำว่า i-Reporter เป็น ผลิตภัณฑ์ของบริษัท CIMTOPS (ชิมท็อปส์) ส่วน TOMAS TECH อยู่ในฐานะผู้รับผิดชอบการนำไปใช้ในไทย การออกแบบฟอร์ม และการซัพพอร์ตในพื้นที่ ราคาทั้งหมดในบทความนี้อ้างอิงข้อมูลปฐมภูมิที่มีการเผยแพร่ ส่วนที่เป็นการประมาณการ เราระบุซ้ำไว้แล้วว่าเป็นสมมติฐานเชิงโมเดลสำหรับบทความนี้

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

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

แหล่งข้อมูลอ้างอิง

• เว็บไซต์ทางการของ i-Reporter (บริษัท CIMTOPS)
• ข่าวประชาสัมพันธ์เรื่องการปรับราคา i-Reporter (PR TIMES)
• ราคา i-Reporter (Next Vision)
• ข่าวประชาสัมพันธ์ของบริษัท CIMTOPS
• Thailand Set to Overhaul Its E-Transactions Framework (Tilleke & Gibbins)
• ประวัติอัตราแลกเปลี่ยน THB/JPY ปี 2026 (Exchange-Rates.org)
• i-Reporter Global (เว็บไซต์สำหรับตลาดต่างประเทศ)