เลือกบริษัทพัฒนาระบบ ประเทศไทย ปี 2026｜ราคา เกณฑ์ตัดสิน และขั้นตอนจ้างจริง

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

ตลาดพัฒนาระบบในไทยปี 2026: อ่านตัวเลขก่อนอ่านใบเสนอราคา

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

ตลาดโตสองหลัก แปลว่าทรัพยากรนักพัฒนากำลังถูกแย่งกัน

Mordor Intelligence ประเมินว่าตลาด IT และความปลอดภัยของไทยจะมีมูลค่า 10,030 ล้านดอลลาร์สหรัฐ ในปี 2026 และเติบโตเฉลี่ยปีละ 10.26% จนแตะ 16,720 ล้านดอลลาร์สหรัฐ ในปี 2031 การเติบโตสองหลักต่อเนื่องห้าปีมีอีกด้านหนึ่งเสมอ นั่นคือการแย่งตัววิศวกรที่มีฝีมือจะรุนแรงขึ้น และคิวงานของบริษัทที่ทำงานดีจะยาวขึ้น

ขณะเดียวกัน ถ้ามองเฉพาะตลาดบริการ IT ซึ่งมีนิยามแคบกว่า Data Bridge Market Research ระบุว่าปี 2025 มีมูลค่าราว 2,500 ล้านดอลลาร์สหรัฐ และจะเติบโตเฉลี่ยเพียง 3.31% ต่อปีในช่วงปี 2025-2030 โดยแบ่งเป็น IT outsourcing ซึ่งใหญ่ที่สุดที่ 1,030 ล้านดอลลาร์สหรัฐ บริการซอฟต์แวร์ 1,130 ล้านดอลลาร์สหรัฐ (เติบโต 4.46%) และบริการดิจิทัลที่โตเร็วที่สุดถึง ราว 34%

เอาตัวเลขสองชุดนี้มาวางคู่กันจะเห็นบุคลิกของตลาดชัดขึ้น ตลาดโดยรวมซึ่งรวมฮาร์ดแวร์ ผลิตภัณฑ์ความปลอดภัย และโครงสร้างพื้นฐานคลาวด์ โตสองหลัก แต่บริการ IT แบบดั้งเดิม คือแบบที่ส่งคนมานั่งประจำและดูแลระบบเดิมไปเรื่อย ๆ กลับโตช้า ส่วนที่โตแรงคือบริการดิจิทัล ได้แก่ cloud-native การใช้ประโยชน์จากข้อมูล และงานที่เกี่ยวกับ AI

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

ภาครัฐย้ายขึ้นคลาวด์ ดันมาตรฐานของทั้งอุตสาหกรรม

ฝั่งนโยบายก็ขยับแรงเช่นกัน สำนักงานพัฒนารัฐบาลดิจิทัล (DGA) วางแนวทางให้ภาระงาน (workload) ใหม่ของภาครัฐ ย้ายขึ้นคลาวด์ 70% ภายในปี 2027 และกำหนดให้ หน่วยงานภาครัฐ 412 แห่งต้องย้ายระบบหลักอย่างน้อยหนึ่งระบบขึ้นคลาวด์ภายในเดือนธันวาคม 2026

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

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

ความเร็วในการรับ AI ของไทยอยู่อันดับ 2 ของโลก

อีกตัวเลขหนึ่งที่หลายคนอาจไม่คาดคิด รายงานของ BigGo Finance ระบุว่าสัดส่วนผู้ที่ใช้ generative AI อย่างจริงจังในไทยอยู่ที่ 12.4% ในไตรมาสแรกของปีงบประมาณ 2026 เพิ่มขึ้น 36.4% จากปีก่อน และทำให้ไทยขึ้นมาอยู่ อันดับ 2 ของโลก ในด้านความเร็วของการรับเทคโนโลยี AI

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

บริษัทพัฒนาระบบในไทยแบ่งได้เป็น 4 ประเภท

เข้าเรื่องหลัก ตัวเลือกในการจ้างพัฒนาระบบในไทยแบ่งได้ราว 4 ประเภท ไม่มีประเภทไหน “แย่” โดยตัวมันเอง ประเด็นอยู่ที่ ความเข้ากันระหว่างลักษณะงานกับลักษณะของผู้ให้บริการ ล้วน ๆ

ประเภทที่ 1: บริษัทซอฟต์แวร์ไทย

บริษัทที่คนไทยเป็นเจ้าของและบริหาร มีจำนวนมากที่สุดและมีความสามารถในการแข่งขันด้านราคาสูงที่สุด จุดแข็งที่ชัดเจนคือความเข้าใจบริบทของไทย ทั้งภาษี VAT ภาษีหัก ณ ที่จ่าย รูปแบบใบกำกับภาษี e-Tax Invoice ประกันสังคม และกฎหมายแรงงาน ซึ่งเป็นสิ่งที่ต้องเขียนลงในระบบจริง ๆ ไม่ใช่แค่เข้าใจในระดับแนวคิด อีกทั้งการสื่อสารกับผู้ใช้งานที่เป็นคนไทยทำได้โดยตรงไม่ต้องผ่านล่าม ทำให้รอบการเก็บ requirement เร็วกว่า

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

ประเภทที่ 2: ผู้ให้บริการ IT ญี่ปุ่นในไทย

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

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

ประเภทที่ 3: SI และบริษัทที่ปรึกษาระดับโลก สาขาประเทศไทย

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

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

ประเภทที่ 4: outsource พัฒนาซอฟต์แวร์ แบบ offshore

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

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

ตารางเปรียบเทียบผู้ให้บริการ 4 ประเภท

ในทางปฏิบัติ องค์กรจำนวนมากขึ้นเรื่อย ๆ เลือกไม่ฝากทุกอย่างไว้กับบริษัทเดียว แต่แบ่งตามชั้นของระบบ เช่น ระบบผลิตใช้ผู้ให้บริการที่เข้าหน้างานได้ ระบบเว็บใช้ offshore และ ERP ทั้งองค์กรใช้ SI ระดับโลก แนวทางนี้ใช้ได้ดี แต่มีเงื่อนไขว่าต้องระบุขอบเขตความรับผิดชอบตรงจุดเชื่อมต่อไว้ในสัญญาให้ชัด ไม่เช่นนั้นเวลาเกิดปัญหาจะกลายเป็นการโยนกันไปมา

เกณฑ์ตัดสิน 7 ข้อที่ควรดูก่อนดูราคา

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

เกณฑ์ที่ 1: requirement ถูกแปลกี่ทอดก่อนกลายเป็นโค้ด

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

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

เกณฑ์ที่ 2: แผนการดึงฝ่ายผู้ใช้งานเข้ามามีส่วนร่วม

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

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

เกณฑ์ที่ 3: โครงสร้างการดูแลหลังส่งมอบของจริง

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

เกณฑ์ที่ 4: ระยะทางจริงระหว่างออฟฟิศผู้ให้บริการกับโรงงาน

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

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

เกณฑ์ที่ 5: ภาษาและระดับรายละเอียดของเอกสาร

ถ้าเอกสารส่งมอบเป็นภาษาอังกฤษล้วน ทีมงานหน้างานที่ต้องใช้จริงอาจอ่านไม่ไหว ถ้าเป็นภาษาไทยล้วน ผู้บริหารหรือผู้ตรวจสอบจากบริษัทแม่ต่างชาติก็ตรวจไม่ได้

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

เกณฑ์ที่ 6: ความเข้าใจข้อกำหนดทางบัญชีและภาษีของไทย

หลายองค์กรเจ็บกับเรื่องนี้ ระบบที่ทำมาสวยแต่ออกใบกำกับภาษีไม่ตรงรูปแบบ หรือคำนวณภาษีหัก ณ ที่จ่ายไม่ครบประเภท จะสร้างงานซ่อมให้ฝ่ายบัญชีทุกสิ้นเดือน หัวข้อที่ควรถามให้เห็นตัวอย่างจริง ได้แก่ VAT ภาษีหัก ณ ที่จ่าย รูปแบบใบกำกับภาษีและ e-Tax Invoice เอกสารนำเข้า-ส่งออก และเอกสารที่เกี่ยวข้องกับสิทธิ BOI

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

เกณฑ์ที่ 7: ความง่ายในการย้ายผู้ให้บริการในอนาคต

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

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

จ้างพัฒนาระบบ ราคา: ทำไมดูแค่เรตต่อคน-เดือนถึงไม่พอ

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

เรตของประเทศรอบข้างใช้เป็นกรอบอ้างอิงได้

ข้อมูลจาก Offshore Development White Paper ฉบับปี 2025 (ข้อมูล ณ วันที่ 13 กุมภาพันธ์ 2026) รายงานเรตค่าจ้างต่อคนต่อเดือนของประเทศปลายทาง offshore หลัก ๆ ไว้ดังนี้ (หน่วย: เยนญี่ปุ่น)

รายงานฉบับเดียวกันระบุว่าเรตเฉลี่ยของโปรแกรมเมอร์ลดลงมาอยู่ที่ 340,000 เยน

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

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

แยกต้นทุนออกเป็น 3 ชั้น: ตั้งต้น ดูแล และต้นทุนแฝง

ใบเสนอราคาส่วนใหญ่เขียนเฉพาะค่าใช้จ่ายตั้งต้น แต่เมื่อมองต้นทุนการเป็นเจ้าของรวม (TCO) ในกรอบห้าปี ค่าดูแลรักษามักใหญ่กว่าค่าพัฒนาครั้งแรก การแยกต้นทุนตามตารางนี้ก่อนเปรียบเทียบจะช่วยได้มาก

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

เงื่อนไขที่ต้องทำให้เท่ากันก่อนเทียบใบเสนอราคา

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

• ขอบเขตกระบวนการทางธุรกิจที่ครอบคลุม
• จำนวนผู้ใช้งานและจำนวนผู้ใช้พร้อมกันสูงสุด
• ช่วงเวลาและปริมาณข้อมูลที่ต้องย้าย
• ขอบเขตการทดสอบ (unit / integration / UAT ใครรับผิดชอบถึงระดับไหน)
• ช่วงเวลาที่ให้บริการดูแลและนิยามของ response time
• ประเภทและภาษาของเอกสารส่งมอบ
• โควตางานแก้ไขหลังขึ้นระบบ (ชั่วโมงต่อเดือน)

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

สัญญาและกฎหมาย: จุดที่มักสะดุด

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

PDPA พัฒนาระบบ และคำถามว่าข้อมูลต้องอยู่ที่ไหน

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) บังคับใช้เต็มรูปแบบตั้งแต่เดือนมิถุนายน 2022 ข้อเท็จจริงแรกที่ควรเข้าใจให้ตรงกันคือ ประเทศไทยไม่มีข้อบังคับ data localization แบบทั่วไป กล่าวคือไม่ได้มีกฎที่บังคับทุกอุตสาหกรรมว่าข้อมูลของคนไทยต้องเก็บในประเทศไทยเท่านั้น

แต่มีข้อยกเว้นที่สำคัญ ในเดือนกันยายน 2024 สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (NCSC) ได้รับรองกฎเกณฑ์การใช้บริการคลาวด์สำหรับผู้ให้บริการโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CIIO) โดยกำหนดว่า ระบบสารสนเทศที่มีระดับผลกระทบ “สูง” ต้องวางศูนย์ข้อมูลหลักไว้ในประเทศไทย และวางข้อมูลสำรองไว้ในประเทศไทยหรือภายในภูมิภาคอาเซียน องค์กรที่อยู่ในกลุ่มพลังงาน การเงิน สาธารณสุข ขนส่ง และโทรคมนาคม ควรตรวจสอบสถานะ CIIO ของตนกับฝ่ายกฎหมายตั้งแต่เนิ่น ๆ เพราะมีผลต่อสถาปัตยกรรมของระบบโดยตรง

สำหรับการโอนข้อมูลออกนอกประเทศ กรอบหลักคือการโอนไปยังประเทศในรายชื่อที่ได้รับการรับรอง หรือใช้ ข้อสัญญามาตรฐาน (Standard Contractual Clauses: SCC) องค์กรที่ต้องส่งข้อมูลพนักงานหรือข้อมูลลูกค้าไปรวมศูนย์ที่บริษัทแม่ในต่างประเทศจึงควรจัดทำข้อตกลงโอนข้อมูลภายในกลุ่มบริษัทให้เรียบร้อย ส่วนคลาวด์ภาครัฐนั้นมีหลักการให้เก็บข้อมูลในประเทศไทย และข้อยกเว้นต้องได้รับอนุมัติจาก DGA ซึ่งเปลี่ยนสมมติฐานของโครงการที่เกี่ยวข้องกับหน่วยงานรัฐไปพอสมควร

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

ลิขสิทธิ์และความเป็นเจ้าของซอร์สโค้ด

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

อย่างน้อยที่สุด ควรทำให้ชัดในสัญญาว่า

• ขอบเขตของลิขสิทธิ์หรือสิทธิการใช้งานในสิ่งที่ส่งมอบ ได้แก่ ซอร์สโค้ด เอกสารออกแบบ และขั้นตอนการ build
• ผู้ว่าจ้างมีสิทธิว่าจ้างบุคคลที่สามมาแก้ไขระบบหรือไม่
• การจัดการกับทรัพย์สินเดิมของผู้พัฒนา (background IP) เช่น framework หรือไลบรารีภายใน และเงื่อนไขการใช้งานต่อเนื่องหากระบบพึ่งพาสิ่งเหล่านั้น
• หน้าที่ในการส่งมอบรายการไลบรารีโอเพนซอร์สพร้อมสัญญาอนุญาตของแต่ละรายการ

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

เงื่อนไขการตรวจรับและความรับผิดในความชำรุดบกพร่อง

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

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

ภาษาของสัญญาและกฎหมายที่ใช้บังคับ

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

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

BOI ซอฟต์แวร์: สิทธิประโยชน์ที่มักถูกมองข้าม

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

ยกเว้นภาษีเงินได้นิติบุคคลสูงสุด 8 ปี

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

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

ความหมายในเชิงปฏิบัติสำหรับผู้ว่าจ้าง

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

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

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

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

5 รูปแบบความล้มเหลวที่พบบ่อย และวิธีเลี่ยง

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

แบบที่ 1: ฝ่าย IT วิ่งอยู่คนเดียว ฝ่ายผู้ใช้ไม่ร่วมด้วย

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

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

แบบที่ 2: เริ่มพัฒนาทั้งที่ requirement ยังไม่นิ่ง แล้วสเปกบานปลาย

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

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

แบบที่ 3: ระบบไม่รองรับหลายสกุลเงินหรือหลายภาษา

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

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

แบบที่ 4: ยกระบบมาตรฐานจากบริษัทแม่มาใช้ทั้งดุ้น

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

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

แบบที่ 5: ไม่มีคนกลางที่เข้าใจทั้งภาษาและกระบวนการทำงาน

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

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

ขั้นตอนการจัดจ้าง: RFI → RFP → PoC → ทยอยใช้งานเป็นเฟส

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

ขั้นที่ 1: RFI เพื่อทำความรู้จักตลาด

เมื่อความต้องการยังไม่ตกผลึก ให้เริ่มจาก RFI (Request for Information) คือการโยนโจทย์ให้หลายเจ้าว่า “เรามีปัญหาแบบนี้ มีทางแก้แบบไหนบ้าง” แล้วดูว่าแต่ละเจ้าเสนอแนวทางต่างกันอย่างไร

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

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

ขั้นที่ 2: RFP เพื่อทำให้เงื่อนไขเท่ากัน

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

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

การเปิดเผยเกณฑ์การประเมินล่วงหน้าให้ผลสองอย่าง คือผู้ให้บริการเสนอได้ตรงจุดขึ้น และกระบวนการคัดเลือกภายในองค์กรอธิบายต่อผู้บริหารและผู้ตรวจสอบได้

ขั้นที่ 3: PoC เพื่อทดลองในขอบเขตเล็ก

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

• ความเร็วและความแม่นยำในการตอบคำถาม
• วิธีรายงานเมื่อเกิดเหตุนอกเหนือความคาดหมาย
• การสื่อสารกับพนักงานหน้างาน
• คุณภาพของเอกสารที่ส่งมาระหว่างทาง

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

ขั้นที่ 4: ออกแบบการเริ่มเล็กและขยายเป็นเฟส

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

จุดเริ่มต้นที่มักได้ผลดีในงานโรงงานมีดังนี้

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

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

ประเด็นเฉพาะของระบบในโรงงาน: สมมติฐานต่างจากระบบสำนักงาน

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

ระบบบริหารการผลิตต้องออกแบบบนสมมติฐานว่า “หยุดไม่ได้”

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

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

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

งาน IoT เชื่อมเครื่องจักร: ความสำเร็จ 90% อยู่ที่การสำรวจก่อนเริ่ม

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

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

เครื่องปลายทางหน้างานต้องเลือกจากสภาพแวดล้อม ไม่ใช่จากสเปก

การเลือกอุปกรณ์หน้างานด้วยความรู้สึกเดียวกับการเลือกพีซีในออฟฟิศคือความผิดพลาดคลาสสิก หน้างานโรงงานมีทั้งความร้อน ความชื้น ฝุ่น น้ำมัน การสั่นสะเทือน เสียงดัง และผู้ใช้ที่สวมถุงมือ

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

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

จุดเชื่อมต่อระหว่างเครือข่าย OT กับ IT

การเชื่อมเครือข่าย OT ที่ต่อกับเครื่องจักร เข้ากับเครือข่าย IT ที่ระบบงานทำงานอยู่ เป็นประเด็นด้านความปลอดภัยที่สำคัญที่สุด

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

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

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

สรุป: สร้างไม้บรรทัดของตัวเองก่อนเริ่มเปรียบเทียบ

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

ทบทวนสาระสำคัญอีกครั้ง ตลาด IT และความปลอดภัยของไทยจะขยายไปสู่ระดับ 10,030 ล้านดอลลาร์สหรัฐในปี 2026 ภาครัฐกำลังย้ายขึ้นคลาวด์ครั้งใหญ่ และความเร็วในการรับ AI ของไทยอยู่ในระดับต้น ๆ ของโลก ขณะที่บริการ IT แบบดั้งเดิมกลับโตช้า ผู้ให้บริการในตลาดนี้แบ่งได้เป็นบริษัทซอฟต์แวร์ไทย ผู้ให้บริการ IT ญี่ปุ่นในไทย SI ระดับโลกสาขาไทย และทีม offshore ซึ่งแต่ละแบบเหมาะกับงานคนละชนิด

ในการคัดเลือก ให้ดูเจ็ดเกณฑ์ ได้แก่ จำนวนทอดของการแปล requirement แผนการดึงฝ่ายผู้ใช้เข้ามาร่วม โครงสร้างการดูแลหลังส่งมอบของจริง ระยะทางถึงหน้างาน ภาษาของเอกสาร ความเข้าใจภาษีและแบบฟอร์มไทย และความง่ายในการย้ายผู้ให้บริการ ด้านราคา อย่าเทียบที่เรตต่อคน-เดือน แต่ให้แยกเป็นสามชั้นคือค่าตั้งต้น ค่าดูแล และต้นทุนแฝง ด้านสัญญา ให้ตรวจ PDPA กฎคลาวด์สำหรับ CIIO ความเป็นเจ้าของซอร์สโค้ด เงื่อนไขการตรวจรับ และภาษาที่ใช้บังคับ พร้อมพิจารณาว่าสิทธิ BOI ด้านซอฟต์แวร์เกี่ยวข้องกับแผนของคุณหรือไม่ จากนั้นเดินจาก RFI ไป RFP แทรก PoC แล้วค่อยขยายเป็นเฟส

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

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

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

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

จ้างพัฒนาระบบ ราคาประมาณเท่าไร

ประเทศไทยยังขาดสถิติค่าจ้างงานพัฒนาระบบที่เปิดเผยและเชื่อถือได้ จึงไม่ควรระบุตัวเลขต่อคน-เดือนเป็นค่าตายตัว ข้อมูลอ้างอิงจากประเทศรอบข้างตาม Offshore Development White Paper ฉบับปี 2025 (ข้อมูล ณ 13 กุมภาพันธ์ 2026) ระบุเรตโปรแกรมเมอร์ของเวียดนามที่ 401,000 เยน ฟิลิปปินส์ 372,000 เยน และอินเดีย 375,000 เยนต่อคนต่อเดือน เรตของไทยมักอยู่ในช่วงใกล้เคียงถึงสูงกว่าเล็กน้อย และขยับขึ้นอีกเมื่อรวมทีมประสานงานหลายภาษา อย่างไรก็ตาม ยอดรวมของโครงการถูกกำหนดโดยความแม่นยำของการประมาณชั่วโมงงานและต้นทุนแฝงมากกว่าเรตต่อหน่วย จึงควรขอใบเสนอราคาจากหลายเจ้าภายใต้เงื่อนไขเดียวกันเสมอ

ควรเลือกบริษัทซอฟต์แวร์ไทย หรือผู้ให้บริการ IT ญี่ปุ่นในไทย

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

outsource พัฒนาซอฟต์แวร์ ไปต่างประเทศ ต่างจากการจ้างทีมในไทยอย่างไร

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

สิทธิ BOI ซอฟต์แวร์ ใช้กับการรับจ้างพัฒนาระบบได้หรือไม่

BOI มีหมวด “การพัฒนาซอฟต์แวร์ แพลตฟอร์มบริการดิจิทัล และดิจิทัลคอนเทนต์” ซึ่งได้รับการยกเว้นภาษีเงินได้นิติบุคคลสูงสุด 8 ปี ครอบคลุมถึงการพัฒนาระบบที่ใช้ AI บริการคลาวด์ และการดำเนินงานศูนย์ข้อมูล วงเงินสิทธิประโยชน์ต่อปีพิจารณาจากค่าใช้จ่ายในการจ้างและฝึกอบรมบุคลากร IT สัญชาติไทยเพิ่มเติม รวมถึงค่าใช้จ่ายในการขอรับรองมาตรฐานสากลอย่าง ISO 29110 หรือ CMMI ระดับ 2 ขึ้นไป ทั้งนี้การพิจารณาให้สิทธิเป็นราย ๆ ตามแผนธุรกิจ จึงควรนำแผนไปหารือเป็นกรณีเฉพาะแทนการสรุปจากหลักการทั่วไป

PDPA พัฒนาระบบ: ต้องเก็บข้อมูลไว้ในประเทศไทยเสมอหรือไม่

ประเทศไทยไม่มีข้อบังคับ data localization แบบทั่วไป แต่ในเดือนกันยายน 2024 NCSC ได้รับรองกฎเกณฑ์การใช้คลาวด์สำหรับผู้ให้บริการโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CIIO) ซึ่งกำหนดให้ระบบสารสนเทศระดับผลกระทบ “สูง” ต้องวางศูนย์ข้อมูลหลักในประเทศไทย และวางข้อมูลสำรองในประเทศไทยหรือภายในอาเซียน ส่วนการโอนข้อมูลออกนอกประเทศใช้กรอบประเทศในรายชื่อที่ได้รับการรับรอง หรือข้อสัญญามาตรฐาน (SCC) สำหรับคลาวด์ภาครัฐมีหลักการให้เก็บในประเทศ และข้อยกเว้นต้องได้รับอนุมัติจาก DGA องค์กรควรตรวจสอบแต่เนิ่น ๆ ว่าตนเข้าข่าย CIIO หรือไม่ เพราะมีผลต่อสถาปัตยกรรมโดยตรง

อยากเริ่มทำระบบแบบเล็ก ๆ ก่อน ควรเริ่มจากตรงไหน

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

ควรจ้างบริษัทเดียวจบ หรือใช้หลายบริษัทแบ่งกันทำ

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

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

• Mordor Intelligence — Thailand IT and Security Market: https://www.mordorintelligence.com/industry-reports/thailand-it-and-security-market
• Data Bridge Market Research — Thailand IT Services Market: https://www.databridgemarketresearch.com/reports/thailand-it-services-market
• Software Association of Japan — ข้อมูลจากคณะกรรมการส่งเสริมการลงทุนแห่งประเทศไทย (BOI): https://www.saj.or.jp/NEWS/activity/government/210706_boi.html
• Cookie Information — What is the Thailand PDPA? 2026 guide: https://cookieinformation.com/blog/what-is-the-thailand-pdpa/
• Hogan Lovells — Thailand releases draft guidelines on government cloud adoption and data classification: https://www.hoganlovells.com/en/publications/thailand-releases-draft-guidelines-on-government-cloud-adoption-and-data-classification
• Offshore Development.com — เปรียบเทียบเรตค่าจ้าง 6 ประเทศ (ฉบับปี 2026): https://www.offshore-kaihatsu.com/faq/tanka.php
• BigGo Finance — ไทยขึ้นอันดับ 2 ของโลกด้านความเร็วในการรับเทคโนโลยี AI: https://finance.biggo.jp/news/ENXbs54B-PfaobXfgh3Q
• Google Cloud — Bangkok region launch: https://cloud.google.com/blog/products/infrastructure/google-cloud-launches-new-region-in-bangkok-thailand
• Yamada Consulting Group — ความท้าทายที่บริษัทต่างชาติเผชิญหลังเข้ามาลงทุนในไทย: https://www.ycg-advisory.jp/learning/oversea_28/
• Toyo Keizai Online — เหตุใดโครงการ IT จึงล้มเหลว: https://toyokeizai.net/articles/-/894218