หนึ่งในสามขององค์กรตัดสินใจไม่ซื้อซอฟต์แวร์แล้ว เพราะ AI เขียนออกมาได้

รายงาน The State of AI ปี 2026 ของ McKinsey โยนตัวเลขที่ไม่เป็นมิตรกับวงการซอฟต์แวร์อย่างมาก คือ 32% ขององค์กรเคยล้มเลิกการจัดซื้อผลิตภัณฑ์หรือฟังก์ชันซอฟต์แวร์บางอย่าง เพราะ 'ใช้ AI coding agent ทำเองก็ได้' ในกลุ่มองค์กรระดับหัวแถวด้านผลงาน สัดส่วนนี้เกือบครึ่ง เรื่องนี้หมายความว่าอย่างไรต่อวงการซอฟต์แวร์และ IT องค์กรในไทย

หัวหน้าฝ่าย IT ของบริษัทนายหน้าประกันขนาดกลางแห่งหนึ่งในไทย ต้นปีได้รับความต้องการจากหน่วยธุรกิจ พวกเขาอยากได้เครื่องมือเล็ก ๆ ที่เทียบความต่างของเงื่อนไขกรมธรรม์อัตโนมัติ กระบวนการเดิมคือหาผู้ให้บริการ ขอราคา เสนอมาราว 600,000 บาท คิว 3 เดือน

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

ไม่มีการขอราคา ไม่มีกระบวนการจัดซื้อ ไม่มี 600,000 บาทก้อนนั้น

เบื้องหลังเหตุการณ์

รายงาน The State of AI ปี 2026 ของ McKinsey เปลี่ยนกรณีแบบนี้ให้กลายเป็นตัวเลข

การสำรวจพบว่า 32% ขององค์กรเคยล้มเลิกการซื้อผลิตภัณฑ์หรือฟังก์ชันซอฟต์แวร์อย่างน้อยหนึ่งอย่าง เพราะ "สร้างเองได้ด้วยเครื่องมือ agentic coding"

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

การแยกตามอุตสาหกรรมก็ชัดเจนพอ ๆ กัน เทคโนโลยี 41% ผู้จ่ายและผู้ให้บริการด้านสุขภาพ 39% บริการวิชาชีพและพลังงาน-วัสดุ 38% สถาบันการเงิน 36% สื่อและโทรคมนาคม 34% ยาและผลิตภัณฑ์การแพทย์ 33%

อีกตัวเลขที่เกี่ยวข้อง ในองค์กรขนาดใหญ่ที่รายได้ต่อปีเกิน 1 พันล้านดอลลาร์สหรัฐ มี 40% ที่ขยาย AI agent ไปในมากกว่าหนึ่งฟังก์ชันแล้ว ปีก่อนตัวเลขนี้คือ 27%

ประเด็นสำคัญครั้งนี้

  • 32% ขององค์กรเคยล้มเลิกการจัดซื้อผลิตภัณฑ์หรือฟังก์ชันซอฟต์แวร์เพราะสร้างเองได้ด้วย AI coding agent
  • เกือบครึ่ง ขององค์กรผู้ทำผลงานสูง (กลุ่ม 6% ที่ยก EBIT ≥5% ให้ AI) มีพฤติกรรมนี้ ส่วนองค์กรอื่นอยู่ที่ 31%
  • 41% ของผู้ตอบในอุตสาหกรรมเทคโนโลยีมีพฤติกรรมนี้ สูงสุดในบรรดาอุตสาหกรรม
  • 40% ขององค์กรขนาดใหญ่ (รายได้เกิน 1 พันล้านดอลลาร์) ขยาย agent ในมากกว่าหนึ่งฟังก์ชันแล้ว ปีก่อนคือ 27%
  • ที่พูดถึงนี้ส่วนใหญ่คือ ฟังก์ชันชายขอบและเครื่องมือขนาดเล็ก ไม่ใช่การเอาการสร้างเองไปแทนระบบหลัก

วิเคราะห์ผลกระทบต่อตลาด

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

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

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

ต่อการใช้งานในองค์กร: ความหมายของเรื่องนี้ต่อ IT องค์กรในไทยคือ เกณฑ์ทางจิตใจของการตัดสินใจจัดซื้อเปลี่ยนไปแล้ว

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

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

กรอบการตัดสินที่สุขภาพดีกว่า ผมคิดว่าคือสามคำถามนี้:

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

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

ต่อนักพัฒนา: สำหรับบริษัทซอฟต์แวร์และทีม SaaS ในไทย นี่คือสัญญาณที่ต้องมองตรง ๆ

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

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

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

แนวโน้มการพัฒนาในอนาคต

สามการเปลี่ยนแปลงที่ผมคาดว่าจะเกิด

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

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

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

บทสรุปและความเห็นจาก TheAI Academy

ผมไม่คิดว่านี่แปลว่า SaaS จะตาย แต่ผมคิดว่า เกณฑ์ทางจิตใจของการซื้อซอฟต์แวร์ถูกยกสูงขึ้นอย่างถาวรแล้ว

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

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

คำแนะนำที่เป็นรูปธรรมสำหรับผู้อ่านในไทย:

หากคุณเป็นหัวหน้า IT องค์กร ผมแนะนำให้สร้างเช็กลิสต์ตัดสิน "สร้างเอง vs ซื้อ" ง่าย ๆ ใส่สามข้อคือความผันแปรตามกฎหมาย ต้นทุนความผิดพลาด และความรับผิดชอบในการบำรุงรักษาสามปีลงไป และกำหนดให้ตอนเสนอต้องตอบให้ได้ นี่กันการตัดสินตามอารมณ์แบบ "เพราะ AI เร็วเราเลยทำเอง" ได้เกือบหมด

หากคุณอยู่ในบริษัทซอฟต์แวร์ สิ่งที่ควรทำตอนนี้คือทบทวนอย่างซื่อสัตย์ว่า ในผลิตภัณฑ์ของคุณมีคุณค่ามาจากสิ่งที่ก็อปยากแค่ไหน หากคำตอบคือ "ไม่มาก" สิ่งที่ควรปรับคือกลยุทธ์ผลิตภัณฑ์ ไม่ใช่คำโฆษณา

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

แหล่งข้อมูล

เรียบเรียงจากข้อมูลสาธารณะ อ้างอิงตามรายงานทางการ บทความนี้มิได้เป็นคำแนะนำด้านการลงทุน

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

การสำรวจนี้ที่ว่า 'ล้มเลิกการจัดซื้อ' คือสร้างเองทั้งหมดหรือ?

ไม่ใช่ การสำรวจถามว่า 'เคยล้มเลิกการซื้อผลิตภัณฑ์หรือฟังก์ชันซอฟต์แวร์อย่างน้อยหนึ่งอย่างเพราะสร้างเองได้ด้วยเครื่องมือ agentic coding หรือไม่' ซึ่งมักหมายถึงฟังก์ชันชายขอบหรือเครื่องมือขนาดเล็ก ไม่ใช่เอาการสร้างเองไปแทน ERP หรือ CRM ทั้งชุด เข้าใจว่าเป็น 'ขอบเขตการจัดซื้อหดเข้ามา' จะแม่นกว่า

อุตสาหกรรมไหนชัดเจนที่สุด?

ตามการแยกตามอุตสาหกรรมของการสำรวจ เทคโนโลยีสูงสุด 41% ตามด้วยผู้จ่ายและผู้ให้บริการด้านสุขภาพ 39% บริการวิชาชีพและพลังงาน-วัสดุ 38% สถาบันการเงิน 36% สื่อและโทรคมนาคม 34% ยาและผลิตภัณฑ์การแพทย์ 33%

สร้างเองถูกกว่าจริงหรือ?

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

บริษัทซอฟต์แวร์ในไทยควรรับมืออย่างไร?

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

繁體中文版 →