การพัฒนาระบบงานในโรงงาน ค่าใช้จ่าย 5 ชั้นและการเชื่อมต่อ ERP 2026

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

ขอเขียนข้อสรุปไว้ก่อน ค่าใช้จ่ายของระบบงานที่ใช้ในโรงงานไม่ได้มีศูนย์กลางอยู่ที่ค่าสร้างหน้าจอหรือแบบฟอร์ม ทั้งก้อนเงินที่ใหญ่ที่สุดและสาเหตุที่ทำให้โครงการล้มเหลว ล้วนไปตกอยู่ที่ อินเทอร์เฟซเชื่อมต่อระบบ กับระบบหลักเดิม (ERP) ระบบบริหารการผลิต และเครื่องจักรในสายการผลิต ในแบบจำลองการคำนวณช่วงหลังของบทความ ส่วนของการเชื่อมต่อนี้คิดเป็น 40.0 ถึง 64.7% ของเงินลงทุน โดยไล่ตั้งแต่กรณีที่เชื่อมต่อ 1 เส้นทางไปจนถึงกรณีที่เชื่อมต่อ 3 เส้นทาง และในบทความที่เราเคยเผยแพร่เรื่อง การแยกค่าใช้จ่ายของการนำแฮนดี้เทอร์มินัลมาใช้ ค่าพัฒนาการเชื่อมต่อก็คิดเป็นประมาณ 55.8% ของเงินลงทุนเริ่มต้น ขณะที่ตัวเครื่องแฮนดี้เทอร์มินัลเองอยู่ที่ประมาณ 26.3% คำว่า “ค่าเชื่อมต่อแพงกว่าตัวเครื่อง” จึงไม่ใช่คำเปรียบเปรย แต่เป็นตัวเลขที่วัดได้จริง

และยังมีอีกเรื่องหนึ่งที่มองข้ามไม่ได้ ณ เดือนสิงหาคม ปี ค.ศ. 2026 (พ.ศ. 2569) นั่นคือ การบำรุงรักษาหลัก (mainstream maintenance) ของ SAP ERP 6.0 (ECC 6.0) ในชุดเสริม EHP 6, 7 และ 8 จะสิ้นสุดลงในวันที่ 31 ธันวาคม ค.ศ. 2027 เมื่อมองผิวเผินเรื่องนี้ดูเหมือนเป็นเรื่องของสำนักงานใหญ่ที่ญี่ปุ่น แต่เมื่อ ERP ของสำนักงานใหญ่เปลี่ยน ระบบหน้างานของโรงงานในไทยก็จะมีคู่สนทนาที่เปลี่ยนไปด้วย สำหรับฐานการผลิตในต่างประเทศ นี่คือ การเปลี่ยนแปลงข้อกำหนดการเชื่อมต่อที่ถูกส่งมาจากภายนอก

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

ทำไมการปรึกษาเรื่องการพัฒนาระบบงานที่เริ่มจาก “จะสร้างอะไร” จึงมักล้มเหลว

ก่อนอื่นขออธิบายโครงสร้างที่ทำให้หลายโครงการเดินผิดทางตั้งแต่ 30 นาทีแรก

ฝ่ายผู้ว่าจ้างพูดด้วยภาษาของ “หน้าจอ” แต่ค่าใช้จ่ายถูกกำหนดด้วย “สายเชื่อม”

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

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

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

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

แนวโน้มการลงทุนของฝั่งญี่ปุ่นก็เอียงไปทาง “เชื่อมต่อใหม่” มากกว่า “สร้างใหม่”

เรื่องนี้ไม่ได้พูดจากความรู้สึกเพียงอย่างเดียว รายงาน “การสำรวจแนวโน้ม IT ขององค์กร ปี 2026” ของ JUAS ซึ่งจัดทำโดยมีกระทรวงเศรษฐกิจ การค้าและอุตสาหกรรมของญี่ปุ่นเป็นผู้กำกับดูแลเนื้อหารายงาน (สำรวจเดือนกันยายนถึงตุลาคม ค.ศ. 2025 และประกาศตัวเลขเบื้องต้นวันที่ 2 กุมภาพันธ์ ค.ศ. 2026) ระบุว่าสัดส่วนบริษัทที่งบประมาณ IT เพิ่มขึ้นอยู่ที่ 52.6% สิ่งที่ควรสังเกตคือลำดับของเหตุผลที่ทำให้งบเพิ่ม

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

นอกจากนี้ ค่า DI ของงบประมาณ IT ตามแผนปีงบ 2025 อยู่ที่ 43.3 จุด ซึ่งเพิ่มขึ้นต่อเนื่องเป็นปีที่ 5 ขณะที่คาดการณ์ปีงบ 2026 อยู่ที่ 39.9 จุด คือเริ่มชะลอลงเล็กน้อย ส่วนการลงทุนและค่าบริการที่เกี่ยวกับ AI เพิ่มจากแผนปีงบ 2025 ที่ 36.3% เป็นคาดการณ์ปีงบ 2026 ที่ 43.7% คือเพิ่มขึ้น 7.4 จุด อย่างไรก็ตาม เมื่อพูดถึงระบบงานของโรงงานซึ่งเป็นหัวข้อของบทความนี้ “ปัญหาที่อยากแก้ด้วยการลงทุน IT” ที่ถูกเลือกมากที่สุดคือ 34.6% ในข้อ “การเพิ่มประสิทธิภาพและความเร็วของกระบวนการทำงาน” เรื่องที่อยู่ก่อนหน้า AI จึงยังเป็นแกนหลักอยู่

ถ้าเริ่มจาก “จะสร้างอะไร” จะตัดสินใจไม่ได้ แต่ยอดเงินจะบวมขึ้นเรื่อย ๆ

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

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

ค่าใช้จ่ายของการพัฒนาระบบงานแยกออกได้เป็น 5 ชั้น

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

นิยามของทั้ง 5 ชั้น

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

และบทความนี้จะตรึงนิยามต่อไปนี้ไว้จนจบ

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

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

ใบเสนอราคาที่ไม่เขียน “การตีมูลค่าชั่วโมงงานภายใน” ของชั้นที่ 4 คือใบเสนอราคาที่อันตราย

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

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

วิธีรับมือไม่ยาก คือ เขียนจำนวนชั่วโมงงานของพนักงานภายในบริษัทพร้อมมูลค่าเป็นตัวเงินลงในชั้นที่ 4 ให้ครบเสมอ ในแบบจำลองการคำนวณช่วงหลัง เราใช้ค่าแรง 50 บาทต่อชั่วโมง (มาจากค่าจ้างขั้นต่ำรายวันฝั่งเพดานของไทยที่ 400 บาทต่อวัน หารด้วย 8 ชั่วโมง) แล้วแสดงเป็นตัวเงินให้เห็นชัดเจน

ถ้ามองยาว 5 ปี ชั้นที่ 5 กินสัดส่วนเกิน 4 ใน 10 ของยอดรวม

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

ในการคำนวณช่วงหลัง เราวางชั้นที่ 5 ไว้ที่ 15% ของเงินลงทุนต่อปี ด้วยสมมติฐานนี้ สัดส่วนของชั้นที่ 5 ในรายจ่ายรวม 5 ปีจะเป็นดังนี้

ยอดรวม 5 ปีของสถานการณ์ A = 3,600,000 + 540,000 × 5 = 6,300,000 บาท
ในจำนวนนี้เป็นชั้นที่ 5 จำนวน 2,700,000 บาท คิดเป็น 42.9% ของยอดรวม

แม้ในสถานการณ์ B ที่เงินลงทุนเท่ากับ 1 ใน 3 อัตรารายปีก็ยังเป็น 15% เท่ากัน สัดส่วนจึงออกมาเป็น 42.9% เท่ากัน มองในกรอบ 5 ปีแล้ว เงินที่จ่ายออกไปประมาณ 4 ใน 10 คือค่าใช้จ่ายหลังระบบเริ่มใช้งานจริง การเปรียบเทียบใบเสนอราคาโดยไม่ถามว่า “ค่าบำรุงรักษาปีละเท่าไร” จึงเท่ากับตัดสินใจโดยไม่ได้ดูเงิน 4 ใน 10 ของทั้งหมด

ทำไมชั้นที่ 3 คืออินเทอร์เฟซเชื่อมต่อระบบจึงกลายเป็นค่าใช้จ่ายก้อนใหญ่ที่สุด

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

สิ่งที่ ISA-95 (IEC 62264) นิยามไว้ คือ “เส้นแบ่ง” พอดี

สถาปัตยกรรม IT ของอุตสาหกรรมการผลิตมีมาตรฐานสากลอยู่ ชื่อว่า ISA-95 และมีเลขมาตรฐานสากลว่า IEC 62264 มาตรฐานนี้แบ่ง IT ของงานผลิตออกเป็น Level 0 ถึง Level 4 และนิยามโดเมนการดำเนินงาน 4 ด้าน ได้แก่ การผลิต คุณภาพ การบำรุงรักษา และสินค้าคงคลัง

• Level 4 คือ ERP ครอบคลุมการวางแผนธุรกิจ การเงิน การจัดซื้อ และการขาย
• Level 3 คือ MES หรือระบบสั่งการผลิต ครอบคลุมคำสั่งผลิต การจัดลำดับงาน การเก็บผลการผลิตจริง และการสอบย้อนกลับ
• Level 2 ลงไป คือการควบคุมและเฝ้าระวัง PLC เซนเซอร์ และแอกชูเอเตอร์

และสิ่งที่ ISA-95 กำหนดไว้เป็นหลักนั้น ไม่ใช่เนื้อในของ Level 3 และไม่ใช่เนื้อในของ Level 4 แต่คือ เส้นแบ่งระหว่าง Level 3 กับ Level 4 นั่นคืออินเทอร์เฟซ ข้อเท็จจริงที่มาตรฐานสากลอุตส่าห์เลือกทำมาตรฐานเฉพาะเส้นแบ่ง ก็เป็นเครื่องยืนยันในตัวเองว่าจุดนี้คือจุดยากของงาน

เทคโนโลยีที่รองรับการนำไปใช้งานจริงก็ถูกจัดไว้ 2 ตัว B2MML คือแบบจำลองที่ใช้ XML แทนข้อมูลที่รับส่งกันระหว่าง ERP กับ MES ส่วน OPC UA รับหน้าที่การสื่อสารแบบเรียลไทม์ระหว่างฝั่ง OT กับฝั่ง IT ส่วนที่ต้องไปดึงผลการผลิตจริงจากฝั่งเครื่องจักรนั้นทับซ้อนกับขอบเขตของ การจ้างพัฒนาโปรแกรม PLC จากภายนอก ทำให้แม้แต่ภายในบริษัทเองก็มักแยกกันคนละแผนก และจุดที่แผนกแยกกัน ก็คือจุดที่ใบเสนอราคาตกหล่นได้ง่ายเช่นกัน

เนื้อแท้ของคำว่า “เชื่อมต่อ” ไม่ใช่การสื่อสาร แต่คือการตกลงกัน

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

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

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

จึงต้องคั่นด้วยมิดเดิลแวร์ เพราะแม้ ERP เปลี่ยน สิ่งที่ต้องแก้ก็มีแค่ส่วนเชื่อมต่อ

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

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

เรื่องนี้เชื่อมตรงกับเรื่องค่าใช้จ่าย ถ้าปล่อยให้แอปพลิเคชันหน้างาน (ชั้นที่ 2) วิ่งไปอ่านตารางของ ERP โดยตรง เมื่อ ERP ถูกเปลี่ยนระบบก็จะต้องรื้อทำใหม่ลามไปถึงชั้นที่ 2 ในทางกลับกัน ถ้ารวบหน้าที่การแปลงข้อมูลไว้ที่ชั้นที่ 3 เมื่อ ERP เปลี่ยน สิ่งที่ต้องลงมือแก้ก็มีแค่ชั้นที่ 3 ถ้าเทียบกับแบบจำลองการคำนวณสถานการณ์ A ที่จะกล่าวถึงต่อไป นี่คือความต่างระหว่างการที่งานรื้อทำใหม่ลามไปถึงชั้นที่ 2 มูลค่า 1,050,000 บาท กับการปิดจบไว้ที่ส่วน ERP ในชั้นที่ 3 มูลค่า 780,000 บาท

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

ตัวเลขที่วัดได้จริงของเราเองก็บอกว่าค่าเชื่อมต่อแพงกว่าตัวเครื่อง

ในการแยกค่าใช้จ่ายของการนำแฮนดี้เทอร์มินัลมาใช้ที่เราเผยแพร่ไว้ ค่าพัฒนาการเชื่อมต่อคิดเป็นประมาณ 55.8% ของเงินลงทุนเริ่มต้น ส่วนตัวเครื่องอยู่ที่ประมาณ 26.3% แปลว่าค่าเชื่อมต่อแพงกว่าตัวเครื่องซึ่งดูเหมือนเป็นพระเอกของการซื้อครั้งนี้ถึงมากกว่า 2 เท่า แนวโน้มเดียวกันนี้ปรากฏซ้ำทั้งใน ค่าใช้จ่ายและวิธีเลือกระบบบริหารกระบวนการผลิต และ การเปรียบเทียบระบบบริหารสินค้าคงคลัง ในแบบจำลองการคำนวณช่วงหลัง สัดส่วนของอินเทอร์เฟซเชื่อมต่อระบบต่อเงินลงทุนออกมาที่ 40.0 ถึง 64.7% ตัวเลขที่วัดได้จริง 55.8% นี้จึงตกอยู่ในช่วงดังกล่าวพอดี

การสิ้นสุดการบำรุงรักษา SAP ECC 6.0 ปลายปี ค.ศ. 2027 คือเรื่องที่ตกลงมาจากภายนอกสู่ฐานการผลิตในต่างประเทศ

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

เรียบเรียงข้อเท็จจริง

เนื้อหาที่ตรงกันในบล็อกทางการของ SAP Community เรื่อง “Maintenance Timelines for SAP ERP 6.0” และแหล่งอื่นอีกหลายแหล่ง มีดังนี้

ขอเสริมเรื่องค่าใช้จ่ายของการบำรุงรักษาแบบขยายเวลา ในสัญญาแบบ ERP Private Cloud ค่าเพิ่ม 2% นี้รวมอยู่ในค่าบริการแบบสมัครสมาชิกรายงวดอยู่แล้ว หลังปี ค.ศ. 2030 ยังเหลือทางเลือกที่ต้องจ่ายเงินเพิ่มชื่อ Customer-Specific Maintenance แต่การเพิ่มฟังก์ชันและการตามการแก้ไขกฎหมายหรือกฎภาษีจะทำได้จำกัด สำหรับประเทศอย่างไทยที่อาจมีการเปลี่ยนแปลงกฎเกณฑ์ทั้งเรื่องภาษีมูลค่าเพิ่มและใบกำกับภาษีอิเล็กทรอนิกส์ ข้อที่ว่า “การตามการแก้ไขกฎหมายทำได้จำกัด” ข้อเดียวนี้จึงมีน้ำหนักมากในทางปฏิบัติ

สำหรับฐานการผลิตในต่างประเทศ นี่คือ “การเปลี่ยนข้อกำหนดการเชื่อมต่อ”

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

จะเปลี่ยนอะไรบ้างขึ้นอยู่กับเนื้อหาของการเปลี่ยนระบบ แต่อย่างน้อยสิ่งต่อไปนี้จะได้รับผลกระทบ

• วิธีการเชื่อมต่อ เช่น เปลี่ยนจาก IDoc, RFC หรือการแลกไฟล์ ไปเป็น REST API หรือการเชื่อมต่อแบบอิงเหตุการณ์
• ฟิลด์ข้อมูลและระบบรหัส เช่น จำนวนหลักของรหัสสินค้า องค์ประกอบต้นทุน และวิธีจัดโครงสร้างของโรงงานและคลังจัดเก็บ
• จังหวะการปิดรอบและกฎการลงบัญชี
• วิธียืนยันตัวตนและการให้สิทธิ

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

ความหมายในทางปฏิบัติสำหรับคนที่กำลังวางแผนพัฒนาระบบงานอยู่ตอนนี้

การตัดสินใจว่า “ยังไม่รู้ว่า ERP ของสำนักงานใหญ่จะเป็นอย่างไร ระบบหน้างานจึงขอรอไปก่อน” ดูเผิน ๆ เหมือนปลอดภัย แต่จริง ๆ แล้วแพง ตั้งแต่วันที่ 1 สิงหาคม ค.ศ. 2026 ถึงวันที่ 31 ธันวาคม ค.ศ. 2027 มีเวลา 517 วัน หรือประมาณ 17 เดือน ระหว่างที่รอ วันครบกำหนดก็ขยับเข้ามาใกล้ และทางเลือกที่เลือกได้ก็ลดลง

ทางออกที่ทำได้จริงมี 3 ทาง

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

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

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

จากนี้เป็นการเลือกวิธีสร้าง เราจะไม่เปรียบเทียบโดยเอ่ยชื่อผลิตภัณฑ์ การเปรียบเทียบผลิตภัณฑ์รายตัวขอยกให้ การเปรียบเทียบระบบบริหารการผลิต และ การเปรียบเทียบระบบจัดตารางการผลิต ส่วนตรงนี้จะเรียบเรียงเฉพาะ เกณฑ์การตัดสินใจ เท่านั้น

ทางเลือกมี 3 ประเภทดังนี้

เกณฑ์ตัดสินไม่ใช่ “สร้างได้หรือไม่” แต่คือ “เปลี่ยนได้หรือไม่”

คำถามในทางปฏิบัติที่แยก 3 ทางเลือกนี้ออกจากกันมีเพียงข้อเดียว วิธีทำงานของกระบวนการนั้น ปรับให้เข้ากับผลิตภัณฑ์ได้หรือไม่

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

สิ่งที่ต้องตรวจสอบให้ครบเมื่อเลือกส่วนเสริม

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

ดังนั้น ถ้าจะพิจารณาส่วนเสริม ให้ตรวจสอบ 3 ข้อนี้ตั้งแต่ขั้นตอนเสนอราคา

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

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

แบบจำลองการคำนวณ เปรียบเทียบสถานการณ์ A กับสถานการณ์ B บนเส้นฐานเดียวกัน

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

เงื่อนไขของโรงงานตัวอย่าง

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

จำกัดสถานการณ์ไว้เพียง 2 ชุด

• สถานการณ์ A พัฒนาขึ้นใหม่ทั้งหมดในครั้งเดียว สร้างฟังก์ชันผลการผลิตจริง สินค้าคงคลัง และการส่งของทั้งหมดพร้อมกัน และเชื่อมต่อกับ ERP แบบสองทาง
• สถานการณ์ B นำร่องโดยจำกัดขอบเขต ทำเฉพาะงานบันทึกผลการผลิตจริงเพียงงานเดียว โดยใช้ฟังก์ชันมาตรฐานของซอฟต์แวร์สำเร็จรูป และส่งเข้า ERP แบบทางเดียว

ค่าใช้จ่าย 5 ชั้นของสถานการณ์ A ที่พัฒนาขึ้นใหม่ทั้งหมดในครั้งเดียว

รายละเอียดของชั้นที่ 3 จำนวน 1,620,000 บาท มีดังนี้

รายละเอียดของชั้นที่ 4 จำนวน 450,000 บาท ก็แสดงให้เห็นเช่นกัน

ส่วนที่จ้างภายนอก ได้แก่ เครื่องมือย้ายข้อมูล การแปลงข้อมูล และการตรวจสอบ 370,000 บาท บวกกับการตีมูลค่าชั่วโมงงานภายใน 80,000 บาท เท่ากับ 450,000 บาท
ชั่วโมงงานภายใน = 1,600 ชั่วโมง คูณ 50 บาทต่อชั่วโมง = 80,000 บาท
(1,600 ชั่วโมง มาจากเจ้าหน้าที่ฝ่ายวางแผนการผลิตและจัดซื้อ 2 คน คูณ 5 เดือน คูณ 20 วัน คูณ 8 ชั่วโมง)

เทียบกับชั้นที่ 2 จำนวน 1,050,000 บาท ชั้นที่ 3 อยู่ที่ 1,620,000 บาท คิดเป็น ประมาณ 1.54 เท่า การพัฒนาขึ้นใหม่ทั้งหมดมีปริมาณของที่ต้องสร้างมาก ชั้นแอปพลิเคชันจึงใหญ่ตาม แต่ถึงอย่างนั้นการเชื่อมต่อก็ยังเป็นค่าใช้จ่ายก้อนใหญ่ที่สุดอยู่ดี

ค่าใช้จ่าย 5 ชั้นของสถานการณ์ B ที่นำร่องโดยจำกัดขอบเขต

รายละเอียดของชั้นที่ 4 จำนวน 210,000 บาท คือส่วนที่จ้างภายนอก 170,000 บาท บวกกับการตีมูลค่าชั่วโมงงานภายใน 40,000 บาท ซึ่งมาจาก 800 ชั่วโมง คูณ 50 บาทต่อชั่วโมง โดย 800 ชั่วโมงมาจากเจ้าหน้าที่ 1 คน คูณ 5 เดือน คูณ 20 วัน คูณ 8 ชั่วโมง

เงินลงทุนของสถานการณ์ A ที่ 3,600,000 บาท เท่ากับ 3.0 เท่าพอดี ของสถานการณ์ B ที่ 1,200,000 บาท ทั้งที่จำนวนฟังก์ชันที่สร้างต่างกันมากกว่านั้น แต่ยอดเงินต่างกันแค่ 3.0 เท่า เพราะแม้ในสถานการณ์ B ชั้นที่ 3 และชั้นที่ 4 ก็ไม่ได้เป็นศูนย์ เมื่อดูอัตราการลดลงรายชั้นจะเห็นความต่างชัดเจน ชั้นที่ 2 ลดลงเหลือ 31.4% ของสถานการณ์ A (330,000 หารด้วย 1,050,000) แต่ชั้นที่ 4 ลดลงเหลือถึง 46.7% (210,000 หารด้วย 450,000) คือลดได้น้อยกว่าชั้นที่ 2 มาก แม้จะจำกัดขอบเขตให้เหลือ 1 งาน ค่าใช้จ่ายก็ไม่ได้ลดลงในสัดส่วนเดียวกัน นี่คือความจริงข้อแรกที่ต้องเจอเมื่อคิดจะ “เริ่มจากเล็ก ๆ ก่อน”

เงื่อนไขของผลประโยชน์ ต้องตรึงเส้นฐานไว้เส้นเดียว

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

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

ผลประโยชน์ทุกรายการจะถูกนับในฐานะส่วนต่างจากเส้นฐานนี้เท่านั้น

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

อัตราการลดลงคือ 5,066 หารด้วย 7,180 เท่ากับ 70.6% ในโรงงานที่ยังตั้งอยู่บนกระดาษกับ Excel การลดลงระดับนี้ไม่ใช่เรื่องแปลก ส่วนวิธีดำเนินการทำใบรายงานประจำวันให้เป็นอิเล็กทรอนิกส์นั้น เราเขียนแยกไว้ใน คู่มือการนำระบบแบบฟอร์มอิเล็กทรอนิกส์มาใช้

ผลประโยชน์รายปีของสถานการณ์ A

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

ตัวเลขปีละ 18 ครั้ง ครั้งละ 80,000 บาท สต๊อก 9,000,000 บาท อัตราการบีบ 15% และอัตราต้นทุนถือครอง 20% ล้วนเป็น ค่าสมมติสำหรับแบบจำลองนี้ ถ้าจะคำนวณสำหรับบริษัทของท่านเอง ขอให้เปลี่ยนตัวเลข 4 ตัวนี้เป็นค่าจริงของท่าน เนื่องจากเงินส่วนใหญ่คือ 64.7% ของผลประโยชน์มาจากข้อ 2 ค่าจริงของข้อ 2 จึงเป็นตัวกำหนดความแม่นยำของการคำนวณเกือบทั้งหมด

ผลประโยชน์สุทธิรายปีของ A = 1,483,300 ลบ 540,000 (ค่าใช้จ่ายดำเนินงานรายปีของชั้นที่ 5) = 943,300 บาทต่อปี
ROI ต่อปีของ A = 943,300 หารด้วย 3,600,000 = 26.2%
ระยะเวลาคืนทุนของ A = 3,600,000 หารด้วย 943,300 = ประมาณ 3.8 ปี

ผลประโยชน์รายปีของสถานการณ์ B

สถานการณ์ B ทำเฉพาะงานบันทึกผลการผลิตจริงเพียงงานเดียว ขอบเขตของผลประโยชน์จึงแคบลงตาม สิ่งที่อยู่ในขอบเขตคือ 3 บรรทัดบนของตารางชั่วโมงงาน ได้แก่ ใบรายงานประจำวันบนกระดาษที่หน้างาน การคีย์ลง Excel ที่สำนักงาน และการคีย์ซ้ำเข้า ERP รวมกันเป็น 5,500 ชั่วโมง

ขออธิบายที่มาของ 3,175 ชั่วโมงในข้อ 1 ให้ชัดเจน ในสถานการณ์ A นั้น 3 บรรทัดที่อยู่ในขอบเขตถูกลดได้เต็มจำนวนคือ 4,050 ชั่วโมง (1,350 บวก 1,800 บวก 900) แต่สถานการณ์ B เป็นการเชื่อมต่อทางเดียวและทำเฉพาะการบันทึกผลการผลิตจริง งานรวมข้อมูลใน Excel และการกระทบยอดรายเดือนจึงยังคงอยู่ที่หน้างาน เราจึงกำหนดให้ลดได้ 3,175 ชั่วโมง ซึ่งเท่ากับ 78.4% ของจำนวนเต็ม แยกเป็นใบรายงานประจำวันบนกระดาษที่หน้างาน 675 ชั่วโมง (ครึ่งหนึ่งของ A) การคีย์ลง Excel ที่สำนักงาน 1,600 ชั่วโมง และการคีย์ซ้ำเข้า ERP 900 ชั่วโมง ซึ่งส่วนนี้หายไปเต็มจำนวนด้วยการเชื่อมต่อทางเดียว รวมทั้งหมดเป็น 3,175 ชั่วโมง

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

ผลประโยชน์สุทธิรายปีของ B = 638,750 ลบ 180,000 (ค่าใช้จ่ายดำเนินงานรายปีของชั้นที่ 5) = 458,750 บาทต่อปี
ROI ต่อปีของ B = 458,750 หารด้วย 1,200,000 = 38.2%
ระยะเวลาคืนทุนของ B = 1,200,000 หารด้วย 458,750 = ประมาณ 2.6 ปี

อ่านทั้ง 2 ชุดเทียบกัน

สิ่งที่อ่านได้จากตารางนี้มี 3 ข้อ

1. ระยะเวลาคืนทุนของ B สั้นกว่า 1.2 ปี คือจาก 3.8 ปี เหลือ 2.6 ปี การจำกัดขอบเขตทำให้เงินที่ลงไปกลับคืนมาเร็วกว่า
2. ยอดสุทธิสะสม 5 ปีเกือบเท่ากัน ต่างกันเพียง 22,750 บาท คิดเป็นประมาณ 2.0% ของ A ปริมาณผลประโยชน์สัมบูรณ์ของ A มากกว่าก็จริง แต่ถูกหักล้างด้วยน้ำหนักของค่าใช้จ่ายดำเนินงานและเงินลงทุน
3. ถึงอย่างนั้น เงินลงทุนของ B ยังเท่ากับ 1 ใน 3 ถ้าจุดที่ไปถึงใน 5 ปีเท่ากัน การขยับเงินก้อนที่เล็กกว่าย่อมผ่านการอนุมัติงบง่ายกว่า และถ้าล้มเหลวบาดแผลก็ตื้นกว่า

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

การวิเคราะห์ความอ่อนไหวชุดที่ 1 ค่าแรงต่อชั่วโมงจาก 50 เป็น 100 บาทต่อชั่วโมง

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

ค่าใช้จ่ายดำเนินงานรายปีของชั้นที่ 5 (A เท่ากับ 540,000 และ B เท่ากับ 180,000) เป็นมูลค่าสัญญาจ้างกับภายนอก เราจึงไม่ผูกให้ขยับตามค่าแรงต่อชั่วโมงภายในบริษัท สิ่งที่เพิ่มขึ้นในการวิเคราะห์ชุดนี้มีเพียงการตีมูลค่าชั่วโมงงานภายในของชั้นที่ 4 ส่วนมูลค่าสัญญาจ้างภายนอกไม่เปลี่ยน (ส่วนการวิเคราะห์ชุดที่ 2 ที่จะกล่าวต่อไปนั้น สิ่งที่เพิ่มคือค่าพัฒนาที่จ่ายให้ภายนอก เราจึงคำนวณชั้นที่ 5 ใหม่ที่ 15% ของเงินลงทุนด้วย) อนึ่ง ต่อให้คำนวณชั้นที่ 5 ใหม่ที่ 15% ของเงินลงทุนในกรณีนี้ด้วย จะได้ A เท่ากับ 552,000 บาท คืนทุน 3.1 ปี และ B เท่ากับ 186,000 บาท คืนทุน 2.0 ปี ข้อสรุปไม่เปลี่ยน

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

การวิเคราะห์ความอ่อนไหวชุดที่ 2 จำนวนเส้นทางการเชื่อมต่อจาก 1 เป็น 3

ตรงนี้คือส่วนที่แสดงแกนหลักของบทความออกมาเป็นตัวเลข เราใช้สถานการณ์ B เป็นฐาน แล้ว เพิ่มเฉพาะจำนวนปลายทางที่เชื่อมต่อจาก 1 เส้นทางเป็น 3 เส้นทาง โดยไม่แตะขอบเขตของแอปพลิเคชันแม้แต่น้อย สิ่งที่เพิ่มเข้ามาคือระบบบริหารการผลิตเดิม (420,000 บาท) และเครื่องจักรกับฐานข้อมูลเดิม (420,000 บาท)

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

เพียงแค่ปลายทางเพิ่มจาก 1 เส้นทางเป็น 3 เส้นทาง ระยะเวลาคืนทุนก็ยืดจาก 2.6 ปีเป็น 6.1 ปี หรือประมาณ 2.3 เท่า ทั้งที่ฟังก์ชันของแอปพลิเคชันไม่ได้เพิ่มขึ้นแม้แต่ตัวเดียว หน้าจอก็เท่าเดิม แบบฟอร์มรายงานก็เท่าเดิม สิ่งที่เพิ่มขึ้นมีเพียงจำนวนปลายทางที่ต้องเชื่อม

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

5 ข้อที่ต้องตัดสินใจลงกระดาษก่อนออกใบสั่งจ้าง

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

ข้อ 1 วันตรึงข้อกำหนด และวิธีจัดการการเปลี่ยนแปลงหลังตรึงแล้ว

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

ข้อ 2 ระดับความละเอียดของเอกสารข้อกำหนดการเชื่อมต่อ

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

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

ข้อ 3 ใครเป็นผู้เตรียมข้อมูลทดสอบ และเตรียมเสร็จเมื่อใด

ข้อมูลทดสอบมีแต่บริษัทของเราเท่านั้นที่สร้างได้ เพราะผู้รับพัฒนาระบบไม่รู้จักทั้งรหัสสินค้าและรหัสคู่ค้าของเรา ถ้าไม่ตกลงเรื่องนี้ไว้ จะเกิดภาวะชะงักที่พัฒนาเสร็จแล้วแต่เริ่มทดสอบไม่ได้

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

ข้อ 4 ใครเป็นเจ้าของข้อมูลหลัก

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

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

ข้อ 5 การส่งมอบซอร์สโค้ดและสิทธิในการแก้ไขปรับปรุง

เขียน 3 ข้อนี้ลงในสัญญา

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

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

ประเด็นที่มีผลเฉพาะเมื่อพัฒนาระบบงานในประเทศไทย

ถ้าเดินเรื่องด้วยความรู้สึกแบบเดียวกับที่ญี่ปุ่น จะมีจุดที่พลาดอยู่ 4 ข้อ 3 ข้อแรกเป็นเรื่องมาตรการภาครัฐและบุคลากร ส่วนข้อสุดท้ายเป็นเรื่องสภาพแวดล้อมการลงทุน

BOI 8.1.1 เป็นสิทธิประโยชน์ของ “ฝ่ายที่พัฒนา” ไม่ใช่ของโรงงานที่เป็นผู้ว่าจ้าง

สำนักงานคณะกรรมการส่งเสริมการลงทุน (BOI) ของไทยมีประเภทกิจการ 8.1.1 (Software / Digital Platform / Digital Content หมวด A2) อยู่ เนื้อหามีดังนี้

• ยกเว้นภาษีเงินได้นิติบุคคล สูงสุด 8 ปี
• วงเงินยกเว้นสูงสุด กำหนดจากรายจ่ายจริงในแต่ละปี
• ฐานคำนวณวงเงิน คือ เงินเดือนของบุคลากร IT สัญชาติไทยที่จ้างใหม่หลังยื่นคำขอในอัตรา 100% และ ค่าฝึกอบรมในอัตรา 200%
• เงื่อนไขคือ กระบวนการพัฒนาซอฟต์แวร์ ได้แก่ การเขียนโค้ด การทดสอบ และการนำขึ้นใช้งาน ต้อง ดำเนินการภายในประเทศไทยโดยทีม IT ที่ตั้งอยู่ในประเทศไทย
• ธุรกิจ IT และเทคโนโลยี ถือหุ้นโดยต่างชาติได้ 100% ซึ่งเป็นข้อยกเว้นของข้อจำกัดการถือหุ้นต่างชาติตามปกติ
• มีการยกเว้นอากรขาเข้าสำหรับเครื่องจักรที่นำเข้าเพื่อใช้ในโครงการ วัตถุดิบสำหรับงานวิจัยและพัฒนา และวัตถุดิบสำหรับผลิตเพื่อส่งออก

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

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

การหักรายจ่ายทางภาษี 200% ของ depa มีกำแพง 2 ด่าน เพราะกิจการ BOI ใช้ไม่ได้

ประเทศไทยยังมีอีกมาตรการหนึ่งที่สนับสนุนการลงทุนด้านดิจิทัล คือ การหักรายจ่ายทางภาษี 200% ตามพระราชกฤษฎีกาฉบับที่ 802 ซึ่งเกี่ยวข้องกับ depa หรือสำนักงานส่งเสริมเศรษฐกิจดิจิทัล แต่เงื่อนไขค่อนข้างเข้ม โรงงานสัญชาติญี่ปุ่นที่ใช้ได้จริงจึงมีจำกัด

โรงงานสัญชาติญี่ปุ่นในไทยส่วนใหญ่อยู่ภายใต้สิทธิประโยชน์ BOI ดังนั้น การที่ได้รับสิทธิประโยชน์ BOI อยู่แล้วก็ทำให้ใช้การหักรายจ่าย 200% ของ depa ไม่ได้ นี่คือกำแพงด่านแรก และต่อให้ใช้ได้ วงเงินสูงสุดก็อยู่ที่ปีละ 300,000 บาท เทียบกับเงินลงทุนของสถานการณ์ B ในบทความนี้ที่ 1,200,000 บาทแล้ว ต่อให้ใช้เต็มวงเงินก็หักรายจ่ายได้เพียงกรอบ 300,000 บาทเท่านั้น ยิ่งกว่านั้น 300,000 บาทคือ กรอบของการหักรายจ่าย ไม่ใช่จำนวนภาษีที่ลดลงจริง สิ่งที่เบาลงจริงคือกรอบนี้คูณด้วยอัตราภาษีเงินได้นิติบุคคลเท่านั้น กำแพง 2 ด่านนี้ต้องตรวจสอบให้แน่ใจก่อนเขียนลงในเอกสารขออนุมัติงบว่า “ภาระที่แท้จริงลดลงจากสิทธิประโยชน์ทางภาษี”

นอกเรื่องเล็กน้อย วันสิ้นสุดช่วงเวลาของรายจ่ายที่เข้าข่ายของ depa คือวันที่ 31 ธันวาคม ค.ศ. 2027 ซึ่งเป็นวันเดียวกันเป๊ะกับวันสิ้นสุดการบำรุงรักษาหลักของ SAP ECC 6.0 ที่กล่าวถึงก่อนหน้า แม้จะเป็นเรื่องบังเอิญ แต่การมองเห็นว่ามีกำแพงเดียวกันคือปลายปี ค.ศ. 2027 ตั้งอยู่ทั้งฝั่งมาตรการภาครัฐและฝั่งเทคโนโลยี ก็ไม่เสียหายอะไร

การเปลี่ยนงานของบุคลากร IT ในไทยและระดับค่าตัว

มีการระบุว่าประเทศไทยขาดแคลนบุคลากรด้านดิจิทัลอยู่ ประมาณ 70,000 คน ในด้านค่าจ้าง แนวโน้มการขึ้นเงินเดือนของปี ค.ศ. 2026 อยู่ที่ประมาณปีละ 4.7% ขณะที่ การเปลี่ยนงาน 1 ครั้งทำให้เงินเดือนขึ้น 15 ถึง 30%

ตัวเลข 2 ชุดนี้อยู่คนละมิติกัน จึงต้องแปลงเป็นจำนวนปีแล้วเทียบกัน การสะสมการขึ้นเงินเดือนปีละ 4.7% ให้ถึง 15% ต้องใช้เวลา ประมาณ 3.0 ปี และให้ถึง 30% ต้องใช้เวลา ประมาณ 5.7 ปี พูดอีกอย่างคือ การเปลี่ยนงาน 1 ครั้งเทียบเท่ากับ การขึ้นเงินเดือนภายในองค์กร 3 ปีถึง 6 ปี ความคุ้มค่าทางเศรษฐกิจของการที่วิศวกรเลือกเปลี่ยนงานจึงสูงมาก

เรื่องนี้ส่งผลต่อการพัฒนาระบบงานใน 3 ข้อต่อไปนี้

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

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

เศรษฐกิจไทยปี ค.ศ. 2026 การขออนุมัติงบก้อนใหญ่ครั้งเดียวผ่านยาก

ขอพูดถึงสภาพแวดล้อมภายนอกของการตัดสินใจลงทุนด้วย อัตราการเติบโตของ GDP ไทยในปี ค.ศ. 2026 นั้น ฝั่งประมาณการของภาครัฐอยู่ที่ 3.0 ถึง 3.5% ขณะที่สถาบันวิจัยเอกชนและสถาบันการเงิน ปรับลดลงมาอยู่ที่ประมาณ 1.8 ถึง 2.0% ส่วนการผลิตรถยนต์ในเดือนพฤษภาคม ค.ศ. 2026 มีรายงานว่าลดลง 11.4% เมื่อเทียบกับเดือนเดียวกันของปีก่อน ซึ่งเป็นการลดลงต่อเนื่อง 2 เดือน และการผลิตเพื่อส่งออกลดลง 25.8% ในทางกลับกัน ค่า DI ของการลงทุนในสินทรัพย์ถาวรของบริษัทสัญชาติญี่ปุ่นฟื้นกลับมาที่ บวก 1 ในครึ่งปีแรกของปี ค.ศ. 2026 ความต้องการลงทุนจึงไม่ได้หายไปเสียทีเดียว

ตัวเลขเหล่านี้เป็นข้อมูลทุติยภูมิที่อ้างอิงจากการรวบรวมของสื่อในวงการ จึงควรอ่านแบบมีช่วงกว้าง แต่ความหมายในทางปฏิบัตินั้นชัดเจน ความต้องการลงทุนไม่ได้เป็นศูนย์ แต่การขออนุมัติงบก้อนใหญ่ครั้งเดียวผ่านยาก พูดอีกอย่างคือ ในสภาพแวดล้อมของปี ค.ศ. 2026 การเริ่มด้วยสถานการณ์ B ที่ 1,200,000 บาทแล้วทำผลงานให้เห็น ย่อมทำได้จริงกว่าการดันสถานการณ์ A ที่ 3,600,000 บาทให้ผ่านในครั้งเดียว

แผน 90 วันจนถึงวันตรึงข้อกำหนดการเชื่อมต่อ

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

ก่อนอื่นขอยืนยันกำหนดเวลา จากวันที่ 1 สิงหาคม ค.ศ. 2026 ถึงวันที่ 31 ธันวาคม ค.ศ. 2027 ซึ่งเป็นวันสิ้นสุดการบำรุงรักษาหลักของ SAP ECC 6.0 มีเวลา 517 วัน หรือประมาณ 17 เดือน ถ้าใช้ 90 วันไปกับการตรึงข้อกำหนดการเชื่อมต่อ วันที่ตรึงจะเป็น วันที่ 30 ตุลาคม ค.ศ. 2026 และเหลือเวลาอีก 427 วัน หรือประมาณ 14.0 เดือน แผน 90 วันจึงไม่ขัดกับกำหนดปลายปี ค.ศ. 2027

วันที่ 1 ถึงวันที่ 30 การสำรวจปลายทางการเชื่อมต่อ

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

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

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

วันที่ 31 ถึงวันที่ 60 ร่างแรกของข้อกำหนดการเชื่อมต่อและรายการอินเทอร์เฟซ

นำการไหลของข้อมูลที่เห็นจากการสำรวจมาตัดออกเป็นหน่วยของอินเทอร์เฟซ ให้หมายเลขว่า IF-001, IF-002 แล้วไล่กรอก 6 บรรทัดที่กล่าวไปก่อนหน้า ได้แก่ ระดับอินเทอร์เฟซ ระดับฟิลด์ข้อมูล จังหวะเวลา ทิศทางและระบบต้นฉบับ กรณีผิดปกติ และปริมาณที่คาดการณ์

ในช่วงนี้มีสิ่งที่ต้องทำคู่ขนานไปด้วย 2 อย่าง

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

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

วันที่ 61 ถึงวันที่ 90 การตรึงข้อกำหนดและการขอใบเสนอราคาบนเงื่อนไขเดียวกัน

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

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

วันที่ 91 เป็นต้นไป ความสัมพันธ์ระหว่างระยะเวลาพัฒนากับกำหนดปลายปี ค.ศ. 2027

นับจากวันตรึง คือวันที่ 30 ตุลาคม ค.ศ. 2026 จะเหลือเวลาอีก 427 วัน หรือประมาณ 14.0 เดือน ความสัมพันธ์กับระยะเวลาพัฒนาเป็นดังนี้

สถานการณ์ A ยังพอลงกรอบ 14.0 เดือนได้ แต่เหลือเวลาเผื่อเพียง 2 ถึง 5 เดือน ถ้าช่วงเวลาไปทับกับการเปลี่ยนระบบ ERP ของสำนักงานใหญ่ เวลาเผื่อเท่านี้อาจรับไม่ไหว ส่วนสถานการณ์ B มีเวลาเผื่อ 8 ถึง 10 เดือน จึงรอให้แนวทางของสำนักงานใหญ่ชัดเจนก่อนแล้วค่อยตัดสินใจเรื่องรอบที่ 2 เช่น การเชื่อมต่อแบบสองทางหรือการเพิ่มปลายทางการเชื่อมต่อ ได้

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

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

ค่าใช้จ่ายพัฒนาระบบงานอยู่ที่ประมาณเท่าไร

การตอบ “ราคาตลาด” ด้วยตัวเลขเดียวจะทำให้เข้าใจผิด เพราะฟังก์ชันเท่ากันแต่ยอดเงินต่างกันได้หลายเท่าตามจำนวนและทิศทางของปลายทางที่เชื่อมต่อ ในแบบจำลองการคำนวณของบทความนี้ กรณี 1 งาน เชื่อมต่อทางเดียว 1 เส้นทาง อยู่ที่ 1,200,000 บาท ส่วนกรณีทุกฟังก์ชัน เชื่อมต่อ 3 เส้นทางโดยมีเฉพาะ ERP ที่เป็นสองทาง อยู่ที่ 3,600,000 บาท (ทั้งคู่เป็นเงินลงทุนชั้นที่ 1 ถึง 4 ที่สร้างขึ้นจากค่าสมมติ) ถ้าอยากรู้ราคาตลาด ขอให้ดูที่ สัดส่วนของชั้นที่ 3 ต่อเงินลงทุนว่าเป็นกี่เปอร์เซ็นต์ มากกว่าดูที่ยอดเงินโดยตรง ในการคำนวณของบทความนี้อยู่ที่ 40.0 ถึง 64.7% และในตัวเลขที่วัดได้จริงจากการนำแฮนดี้เทอร์มินัลมาใช้ของเราอยู่ที่ประมาณ 55.8% ถ้าเจอใบเสนอราคาที่ชั้นที่ 3 ถูกกว่าช่วงนี้มาก ขอให้สงสัยไว้ก่อนว่าสมมติฐานเรื่องปลายทางการเชื่อมต่ออาจไม่ตรงกัน

การเชื่อมต่อระบบหลักควรทำเองมากน้อยแค่ไหน

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

จ้างเฉพาะงานสนับสนุนการติดตั้งซอฟต์แวร์สำเร็จรูปได้หรือไม่

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

การพัฒนาแอปพลิเคชันงานบนแท็บเล็ตหรือสมาร์ตโฟนคิดราคาแยกหรือไม่

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

ควรจ้างอินทิเกรเตอร์ระบบสำหรับอุตสาหกรรมการผลิตสัญชาติญี่ปุ่นหรือผู้ให้บริการท้องถิ่น

อย่าตัดสินด้วยขนาดหรือภาษาเพียงอย่างเดียว สิ่งที่ต้องตัดสินคือ ใครหมุนงานของชั้นที่ 3 และชั้นที่ 4 ได้ พูดให้ชัดคือ 3 ข้อนี้ ได้แก่ คุยกับผู้ดูแล ERP ของสำนักงานใหญ่ที่ญี่ปุ่นได้โดยตรงหรือไม่ ลงรายละเอียดข้อกำหนดกับผู้รับผิดชอบหน้างานชาวไทยเป็นภาษาไทยได้หรือไม่ และเข้าถึงฝั่งเครื่องจักรได้ถึงระดับ PLC และ OPC UA หรือไม่ การหาบริษัทเดียวที่ทำได้ครบทั้ง 3 ข้อนี้ไม่ใช่เรื่องง่ายไม่ว่าจะเป็นบริษัทสัญชาติญี่ปุ่นหรือท้องถิ่น ดังนั้นถ้าจะแบ่งงานให้หลายบริษัท ขอให้ ระบุจุดแบ่งความรับผิดชอบของอินเทอร์เฟซลงในสัญญา ให้ชัดเจน รายการตรวจสอบที่เป็นรูปธรรมสำหรับการเลือกบริษัทนั้น เราเรียบเรียงไว้อย่างละเอียดใน วิธีเลือกบริษัทพัฒนาระบบในประเทศไทย

เมื่อจ้างพัฒนาระบบแล้วซอร์สโค้ดเป็นของบริษัทเราหรือไม่

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

การพัฒนาใช้เวลานานเท่าไร

ในแบบจำลองของบทความนี้ เราคาดไว้ที่ 90 วันจนถึงการตรึงข้อกำหนดการเชื่อมต่อ จากนั้นเป็นการพัฒนาอีก 4 ถึง 6 เดือนสำหรับสถานการณ์ B และ 9 ถึง 12 เดือนสำหรับสถานการณ์ A รวมแล้วประมาณ 7 ถึง 9 เดือนสำหรับ B และประมาณ 12 ถึง 15 เดือนสำหรับ A ความเข้าใจผิดที่พบบ่อยคือคิดว่าระยะเวลาพัฒนาย่นไม่ได้เพราะการเขียนโปรแกรมใช้เวลานาน แต่สิ่งที่กินเวลาจริงคือการตกลงข้อกำหนดการเชื่อมต่อและการจัดระเบียบข้อมูลหลัก ซึ่ง 2 เรื่องนี้เพิ่มคนแล้วก็ไม่ได้เร็วขึ้น ถ้าอยากย่นระยะเวลา วิธีเดียวที่ได้ผลแน่นอนไม่ใช่การเพิ่มคน แต่คือ การลดจำนวนปลายทางที่ต้องเชื่อมต่อ

สรุป

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

• แยกค่าใช้จ่ายออกเป็น 5 ชั้น โดยเงินลงทุนคือชั้นที่ 1 ถึง 4 ส่วนชั้นที่ 5 แยกเป็นค่าใช้จ่ายดำเนินงานรายปี
• ต้องเขียน การตีมูลค่าชั่วโมงงานภายในเป็นตัวเงิน ลงในชั้นที่ 4 เสมอ ใบเสนอราคาที่ไม่เขียนคือใบที่มีค่าใช้จ่ายบางส่วนอยู่นอกเอกสารขออนุมัติงบ
• ชั้นที่ 5 กินสัดส่วน 42.9% ของรายจ่ายรวมเมื่อมองยาว 5 ปี อย่าเปรียบเทียบโดยไม่ตรวจสอบยอดรายปี
• สาเหตุที่ชั้นที่ 3 คืออินเทอร์เฟซเชื่อมต่อระบบกลายเป็นค่าใช้จ่ายก้อนใหญ่ที่สุด ไม่ใช่ความยากทางเทคนิค แต่คือ ปริมาณของข้อตกลง ที่ต้องทำให้จบ สิ่งที่ ISA-95 (IEC 62264) ทำมาตรฐานไว้ก็คือเส้นแบ่งระหว่าง Level 3 กับ Level 4 นั่นเอง
• ถ้าคั่นด้วยมิดเดิลแวร์ แม้ฝั่ง ERP จะเปลี่ยน สิ่งที่ต้องอัปเดตก็มีแค่ส่วนเชื่อมต่อ ชั้นที่ 3 คือการลงทุนเพื่อรวบค่าใช้จ่ายของการเปลี่ยนแปลงในอนาคตไว้ที่จุดเดียว
• ในแบบจำลองการคำนวณ ชั้นที่ 3 คิดเป็น 40.0 ถึง 64.7% ของเงินลงทุน ซึ่งสอดคล้องกับตัวเลขที่วัดได้จริงของเราที่ประมาณ 55.8%
• ในการวิเคราะห์ความอ่อนไหว เพียงเพิ่มปลายทางการเชื่อมต่อจาก 1 เส้นทางเป็น 3 เส้นทางโดยไม่เพิ่มฟังก์ชันของแอปพลิเคชันแม้แต่ตัวเดียว ระยะเวลาคืนทุนก็ยืดจาก 2.6 ปีเป็น 6.1 ปี หรือประมาณ 2.3 เท่า
• การบำรุงรักษาหลักของ SAP ECC 6.0 ชุดเสริม EHP 6, 7 และ 8 สิ้นสุดวันที่ 31 ธันวาคม ค.ศ. 2027 สำหรับฐานการผลิตในต่างประเทศ ให้ถือเป็นการเปลี่ยนแปลงข้อกำหนดการเชื่อมต่อที่ตกลงมาจากภายนอก
• BOI 8.1.1 เป็น สิทธิประโยชน์ของผู้รับพัฒนาระบบ ไม่ใช่ของโรงงานผู้ว่าจ้าง และการหักรายจ่ายทางภาษี 200% ของ depa นั้น กิจการที่อยู่ภายใต้ BOI ใช้ไม่ได้
• สิ่งที่ทำใน 90 วันไม่ใช่การตัดสินใจเลือกผู้รับงาน แต่คือ การตรึงข้อกำหนดการเชื่อมต่อ วันตรึงคือวันที่ 30 ตุลาคม ค.ศ. 2026 และยังเหลือ 427 วันถึงปลายเดือนธันวาคม ค.ศ. 2027 จึงไม่ขัดกัน

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

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

ข้อมูลอ้างอิง

• SAP Community「Maintenance Timelines for SAP ERP 6.0」 https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/maintenance-timelines-for-sap-erp-6-0/ba-p/13524564
• Natuvion「SAP ERP 6 end of maintenance: is the deadline in 2025, 2027, or 2030?」 https://www.natuvion.com/newsroom/sap-erp-6-end-of-maintenance/
• JUAS『企業IT動向調査2026』 https://juas.or.jp/activities/research/it_trend/
• i Magazine「JUAS、企業IT動向調査2026の速報値を発表」(2026-02-02) https://www.imagazine.co.jp/juas-report-on-20260202/
• ISA「ISA-95 Standard: Enterprise-Control System Integration」 https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
• Siemens「ISA-95 framework and layers」 https://www.siemens.com/en-us/technology/isa-95-framework-layers/
• Symestic「ISA-95: The Standard for MES Architectures and ERP Integration」 https://www.symestic.com/en-us/blog/mes/isa95
• Emerhub「Thailand’s Renewed BOI Incentives for 2026 & 2027」 https://emerhub.com/thailand/thailands-renewed-boi-incentives-for-2026-2027/
• AIM Bangkok「Thailand BOI Incentives for Software, Digital Platforms, and Content Businesses」 https://aimbangkok.com/boi-incentives-software-digital-platforms-content-businesses/
• PwC「Thailand – Corporate – Tax credits and incentives」 https://taxsummaries.pwc.com/thailand/corporate/tax-credits-and-incentives
• 秋霜堂「ERP導入ガイド 中小企業が失敗しない7ステップ, 費用相場, 製品比較【2026年版】」 https://syusodo.co.jp/blog/articles/erp-introduction
• Magic Software「製造業のシステム連携はなぜ複雑化しやすいのか」 https://www.magicsoftware.com/ja/magic-blog/majisemi03/
• 暮らすアジア「タイ経済2026年見通し完全ガイド」 https://kyujin.careerlink.asia/blog/thailand-economy-outlook-2026/