- 20
- กรกฎาคม
"เงินก้อนใหญ่ไม่ได้อยู่ที่โมเดล แต่อยู่ที่การ Implement: บทเรียนจากดีล 1.5 พันล้านดอลลาร์" — คำตอบสั้นที่สุดคือ เงินลงทุนก้อนใหญ่ที่สุดรอบล่าสุดของวงการ AI องค์กร ไม่ได้ไหลไปที่การสร้างโมเดลใหม่ แต่ไหลไปที่บริษัทที่รับจ้าง "เอา AI ไปติดตั้งให้ใช้งานได้จริง" เมื่อ 15 กรกฎาคม 2569 Anthropic ร่วมกับ Blackstone, Hellman & Friedman และ Goldman Sachs เปิดตัวกิจการร่วมทุนมูลค่าราว 1.5 พันล้านดอลลาร์สหรัฐ ชื่อ Ode with Anthropic เพื่อทำงานด้านการนำ AI ไปใช้ในองค์กรโดยเฉพาะ บทความนี้อธิบายว่าดีลนี้บอกอะไรกับผู้บริหารที่กำลังพิจารณาลงทุนด้าน Claude หรือ AI ตัวอื่น และทำไมบทเรียนนี้ถึงเหมือนกับสิ่งที่โครงการ ERP สอนเรามาหลายสิบปี
สรุปบรรทัดเดียว: ตลาดเพิ่งลงเงินระดับพันล้านดอลลาร์เพื่อยืนยันว่างานที่ยากและมีมูลค่าจริงในโครงการ AI องค์กร คือการเอาไปต่อกับกระบวนการทำงานจริง ไม่ใช่การเลือกว่าจะใช้โมเดลตัวไหน
ดีลที่เกิดขึ้นจริงคืออะไร
เมื่อวันที่ 15 กรกฎาคม 2569 Anthropic ร่วมกับ Blackstone และ Hellman & Friedman ประกาศเปิดตัวบริษัทใหม่ชื่อ "Ode with Anthropic" เป็นกิจการร่วมทุนมูลค่าราว 1.5 พันล้านดอลลาร์สหรัฐ โดยมี Goldman Sachs ร่วมลงขันเป็นผู้สนับสนุนหลักอีกราย และมีนักลงทุนสถาบันอื่นเข้าร่วมอีกหลายราย สิ่งที่บริษัทนี้จะทำไม่ใช่การสร้างโมเดลภาษาใหม่ ไม่ใช่การสร้างชิป และไม่ใช่การสร้างศูนย์ข้อมูล แต่คือการรับจ้างองค์กรเอาปัญญาประดิษฐ์ไปติดตั้งใช้งานจริงในกระบวนการทำงาน
บริษัทเริ่มต้นด้วยการเข้าซื้อกิจการ Fractional AI ซึ่งเป็นบริษัทที่ปรึกษาด้าน applied AI มาเป็นฐาน ทำให้มีทีมวิศวกรราว 100 คนตั้งแต่วันแรก ผู้บริหารสูงสุดคือ Chris Taylor และหัวหน้าฝ่ายเทคโนโลยีคือ Eddie Siegel ซึ่งทั้งคู่เป็นผู้ร่วมก่อตั้ง Fractional AI มาก่อน แนวทางการทำงานถูกวางไว้แบบ "Claude-first" คือใช้เทคโนโลยีของ Anthropic เป็นหลักในที่ที่ใช้ได้ แต่ยังใช้ผลิตภัณฑ์ของผู้ให้บริการรายอื่นได้เมื่อความต้องการของลูกค้าบังคับ
| หัวข้อ | รายละเอียดที่ประกาศ |
|---|---|
| ชื่อกิจการ | Ode with Anthropic (เปิดตัว 15 กรกฎาคม 2569) |
| มูลค่าดีล | ราว 1.5 พันล้านดอลลาร์สหรัฐ |
| ผู้ร่วมลงทุนหลัก | Anthropic, Blackstone, Hellman & Friedman และ Goldman Sachs |
| จุดตั้งต้น | เข้าซื้อกิจการ Fractional AI มาเป็นฐานทีม |
| กำลังคน | วิศวกรราว 100 คน ทำงานแบบ forward-deployed คือเข้าไปนั่งทำงานกับลูกค้า |
| รูปแบบธุรกิจ | บริการ AI ระดับองค์กร ดำเนินงานแบบ Claude-first แต่ใช้เครื่องมือรายอื่นได้ตามความต้องการลูกค้า |
หมายเหตุก่อนอ่านต่อ: บทความนี้อ่านดีลดังกล่าวในฐานะสัญญาณของตลาด ไม่ใช่การโฆษณาบริการของใคร บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด ไม่ได้มีความเกี่ยวข้องทางธุรกิจกับ Ode, Blackstone หรือ Goldman Sachs และไม่ได้เป็นตัวแทนที่ Anthropic แต่งตั้ง สิ่งที่เราสนใจคือข้อสรุปเชิงโครงสร้างที่ดีลนี้สะท้อนออกมา ซึ่งตรงกับสิ่งที่คนทำโครงการระบบงานองค์กรเจอมานาน
ประโยคสำคัญที่สุดในข่าวนี้
Eddie Siegel หัวหน้าฝ่ายเทคโนโลยีของ Ode ให้สัมภาษณ์ไว้ว่า การเลือกโมเดลนั้นสำคัญ แต่ไม่ใช่จุดที่แรงงานส่วนใหญ่ถูกใช้ไป และเปรียบเทียบว่าการเลือกโมเดลก็คล้ายกับการเลือกภาษาโปรแกรมตอนจะเขียนซอฟต์แวร์ชิ้นหนึ่ง
คำเปรียบเทียบนี้ตรงประเด็นมาก เพราะไม่มีใครเชื่อว่าโครงการซอฟต์แวร์จะสำเร็จเพียงเพราะเลือกภาษาโปรแกรมถูก การเลือกภาษาเป็นการตัดสินใจที่ใช้เวลาไม่กี่ชั่วโมงในโครงการที่กินเวลาหลายเดือน ส่วนที่เหลือคือการทำความเข้าใจปัญหา ออกแบบข้อมูล ต่อกับระบบเดิม ทดสอบ แก้ของที่พัง สอนคนใช้ และดูแลต่อหลังส่งมอบ
เมื่อเงินระดับพันล้านดอลลาร์ไหลไปตั้งบริษัทที่ทำเฉพาะ "ส่วนที่เหลือ" นั่นแปลว่าตลาดกำลังบอกอย่างชัดเจนว่าส่วนที่เหลือคือส่วนที่แพงและหายาก ไม่ใช่ตัวโมเดล
| งานที่ต้องทำ | ลักษณะงาน | ต้องรู้อะไร | สัดส่วนแรงงาน |
|---|---|---|---|
| เลือกโมเดล / ผู้ให้บริการ | เปรียบเทียบความสามารถ ราคา เงื่อนไขข้อมูล | ตลาดผู้ให้บริการ | ต่ำ — ตัดสินใจครั้งเดียว ทบทวนเป็นระยะ |
| เข้าใจกระบวนการจริงขององค์กร | สัมภาษณ์ผู้ใช้ เขียนขั้นตอนจริง หาข้อยกเว้นที่ไม่มีใครเขียนไว้ | ธุรกิจของลูกค้า | สูงมาก |
| เตรียมและต่อข้อมูล | ดึงข้อมูลจากระบบเดิม ทำความสะอาด กำหนดสิทธิ์การเข้าถึง | ระบบเดิม ฐานข้อมูล ความปลอดภัย | สูง |
| ต่อกับระบบงานที่ใช้อยู่ | เชื่อม API ปรับ workflow ทำจุดที่คนกดอนุมัติ | สถาปัตยกรรมระบบ | สูง |
| ทดสอบและวัดผล | กำหนดว่า "ถูกต้อง" แปลว่าอะไร วัดก่อน-หลัง ตรวจผลผิดพลาด | เกณฑ์ธุรกิจ | สูง |
| อบรมและเปลี่ยนพฤติกรรม | สอนผู้ใช้ ปรับคู่มือ ปรับตัวชี้วัดของทีม | คนและวัฒนธรรมองค์กร | สูง และมักถูกประเมินต่ำ |
| ดูแลหลังใช้งานจริง | ตามผลลัพธ์ที่เพี้ยน ปรับเมื่อกระบวนการเปลี่ยน | ทั้งหมดข้างต้น | ต่อเนื่อง ไม่มีวันจบ |
ตารางนี้ไม่ได้ระบุตัวเลขเปอร์เซ็นต์ เพราะสัดส่วนจริงต่างกันไปตามองค์กร แต่รูปทรงของมันจะเหมือนกันเสมอ คือมีงานเดียวที่อยู่บนสุดของสไลด์นำเสนอ และมีงานอีกหกอย่างที่ไม่มีใครพูดถึงตอนขายโครงการ
บทเรียนนี้ไม่ใหม่ — ERP รู้มาก่อนแล้วสามสิบปี
สำหรับคนที่ทำโครงการระบบวางแผนทรัพยากรองค์กร ข้อสรุปข้างต้นไม่ใช่ข่าว เพราะเป็นสิ่งที่วงการนี้เรียนรู้มาตั้งแต่ก่อนที่คำว่า AI จะกลับมาเป็นกระแส องค์กรสองแห่งซื้อซอฟต์แวร์ตัวเดียวกัน รุ่นเดียวกัน ราคาใกล้กัน แต่แห่งหนึ่งใช้งานได้จริงภายในหนึ่งปี ส่วนอีกแห่งกลับไปใช้ Excel ภายในหกเดือน ความต่างไม่ได้อยู่ที่ซอฟต์แวร์ เราเคยเขียนเรื่องนี้ไว้ละเอียดในบทความ ทำไมโครงการ ERP ถึงล้มเหลว และเรื่องเกณฑ์การตัดสินใจใน วิธีเลือกระบบ ERP ให้เหมาะกับองค์กร
ที่น่าสนใจคือรูปแบบความล้มเหลวของโครงการ AI ในองค์กรตอนนี้ แทบจะทับกับรูปแบบความล้มเหลวของโครงการ ERP แบบหนึ่งต่อหนึ่ง
| รูปแบบความล้มเหลวคลาสสิกของ ERP | หน้าตาเดียวกันในโครงการ AI | สาเหตุร่วม |
|---|---|---|
| ซื้อระบบก่อน แล้วค่อยคิดว่าจะใช้ทำอะไร | ซื้อสิทธิ์ใช้งาน AI ทั้งองค์กร แล้วค่อยหา use case | เริ่มจากเครื่องมือ ไม่ได้เริ่มจากปัญหา |
| ข้อมูลตั้งต้นสกปรก ทำให้รายงานไม่ตรง | ข้อมูลที่ป้อนให้ AI ไม่ครบหรือขัดกันเอง ทำให้คำตอบเชื่อไม่ได้ | ไม่มีแหล่งข้อมูลจริงเพียงแหล่งเดียว |
| ผู้ใช้ไม่ยอมเปลี่ยนวิธีทำงาน กลับไปใช้ไฟล์เดิม | พนักงานลองใช้สองสัปดาห์แล้วเลิก เพราะช้ากว่าวิธีเดิม | ไม่ได้ออกแบบให้เข้ากับงานที่ทำอยู่จริง |
| ไม่มี UAT จริงจัง ปัญหาไปโผล่ตอนขึ้นระบบ | ทดสอบเฉพาะตัวอย่างสวย ๆ ไม่เคยทดสอบเคสขอบ | ไม่ได้นิยามว่า "ผ่าน" แปลว่าอะไร |
| ผู้บริหารมองเป็นโครงการไอที ไม่ใช่โครงการธุรกิจ | มอบให้ฝ่ายไอทีทำคนเดียว เจ้าของกระบวนการไม่ร่วม | ไม่มีเจ้าภาพฝั่งธุรกิจ |
| ความรู้อยู่กับคนไม่กี่คน พอลาออกก็จบ | คนที่เขียน prompt และ workflow ลาออก ไม่มีใครดูแลต่อ | ไม่ได้ทำเอกสารส่งมอบ ดู ปัญหาความรู้หายไปกับคน |
| ผูกติดผู้ขายจนย้ายไม่ได้ | ฝังตรรกะธุรกิจไว้ในเครื่องมือของผู้ให้บริการรายเดียว | ไม่ได้แยกกระบวนการออกจากเครื่องมือ ดู Vendor Lock-in |
ข้อควรระวังด้านข้อมูล: โครงการ AI ต่างจากโครงการ ERP ทั่วไปตรงที่มักต้องส่งข้อมูลออกไปประมวลผลนอกองค์กร ก่อนเริ่มโครงการต้องตอบให้ได้ว่าข้อมูลชุดใดออกนอกได้ ชุดใดออกไม่ได้ ใครอนุมัติ และเก็บบันทึกการเข้าถึงไว้อย่างไร ประเด็นนี้ต้องตัดสินใจตั้งแต่ต้น ไม่ใช่ตอนใกล้ขึ้นระบบ เพราะถ้าตอบผิดตั้งแต่แรก การแก้ทีหลังหมายถึงรื้อทั้งงาน
Forward-Deployed Engineer คือใคร และทำไมถึงหายาก
คำที่ปรากฏซ้ำในข่าวนี้คือ forward-deployed engineer หมายถึงวิศวกรที่ไม่ได้นั่งเขียนโค้ดอยู่ที่บริษัทตัวเอง แต่เข้าไปทำงานอยู่กับลูกค้า เห็นกระบวนการจริง คุยกับผู้ใช้จริง แล้วสร้างของที่ใช้ได้กับสภาพจริง รายงานระบุว่าความต้องการคนกลุ่มนี้มีมากกว่ากำลังคนที่มีอยู่มาก และ Siegel อธิบายคุณสมบัติของคนกลุ่มนี้ว่าต้องแก้โจทย์เทคนิคที่ยากได้ พร้อมกับรับผิดชอบงานตั้งแต่ต้นจนจบด้วยตัวเอง
คนแบบนี้ในโลกของระบบงานองค์กรไม่ใช่ของใหม่เช่นกัน — คือคนที่นั่งอยู่หน้างานตอนปิดบัญชีสิ้นเดือน คนที่เข้าใจว่าทำไมใบสั่งซื้อของหน่วยงานหนึ่งต้องผ่านสามลายเซ็นแต่ของอีกหน่วยงานผ่านสองลายเซ็น และคนที่รู้ว่าเอกสารภาษีต้องออกในรูปแบบใดจึงจะผ่านการตรวจ ความรู้แบบนี้ไม่ได้อยู่ในคู่มือผลิตภัณฑ์ และไม่มีโมเดลใดรู้มาก่อนโดยไม่มีใครสอน
ข่าวดีสำหรับองค์กรไทย: ถ้าสิ่งที่มีค่าที่สุดคือความเข้าใจกระบวนการจริง องค์กรไทยก็ไม่ได้เสียเปรียบเรื่องนี้เลย เพราะกระบวนการที่ต้องเข้าใจคือกระบวนการของไทยเอง ทั้งเอกสารภาษี ระเบียบพัสดุ และขั้นตอนอนุมัติภายใน ส่วนนี้เป็นความได้เปรียบของทีมในประเทศ ไม่ใช่ข้อจำกัด
คำถามที่ควรถามผู้ขายก่อนเซ็นสัญญา
ถ้าข้อสรุปคือมูลค่าอยู่ที่การนำไปใช้จริง คำถามที่ใช้คัดผู้ขายก็ต้องเปลี่ยนตาม การถามว่า "ใช้โมเดลอะไร" ให้ข้อมูลน้อยกว่าที่คิด คำถามด้านล่างนี้ใช้ได้ทั้งกับโครงการ AI และโครงการระบบงานองค์กร
| คำถาม | สิ่งที่กำลังวัด | คำตอบที่ควรระวัง |
|---|---|---|
| ใครจะเป็นคนเข้ามานั่งทำงานกับทีมเรา และอยู่กี่วันต่อสัปดาห์ | มีคนหน้างานจริงหรือแค่ทีมขาย | "จะจัดทีมให้ภายหลัง" |
| เกณฑ์ตรวจรับ (UAT) เขียนไว้ในสัญญาอย่างไร | นิยามคำว่าสำเร็จเป็นลายลักษณ์อักษร | "ตกลงกันตอนใกล้ส่งมอบ" |
| แผนขึ้นระบบและแผนย้อนกลับเป็นอย่างไร | ความพร้อมเมื่อของพัง | ไม่มีแผนย้อนกลับ |
| ข้อมูลของเราถูกส่งไปที่ใด เก็บนานเท่าไร ใครเข้าถึงได้ | ความเสี่ยงด้านข้อมูลและการกำกับดูแล | ตอบกว้าง ๆ ว่า "ปลอดภัยครับ" |
| ถ้าเลิกใช้บริการ เราเอากระบวนการและข้อมูลออกได้อย่างไร | ระดับการผูกติดผู้ขาย | ไม่มีรูปแบบไฟล์ส่งออกที่ชัดเจน |
| วัดผลตอบแทนของโครงการด้วยตัวชี้วัดใด และวัดค่าตั้งต้นไว้แล้วหรือยัง | ความจริงจังเรื่องผลลัพธ์ ดู การวัด ROI ของการลงทุน AI | ตัวเลขประหยัดที่ไม่มีที่มา |
| ใครดูแลต่อหลังส่งมอบ และส่งมอบเอกสารอะไรบ้าง | ความยั่งยืนหลังโครงการจบ | "ดูแลให้ตามสมควร" |
แล้วเรื่องนี้เกี่ยวอะไรกับ Saeree ERP
ขอพูดตรง ๆ ว่า Saeree ERP ไม่ได้อยู่ในธุรกิจเดียวกับ Ode และไม่ได้เกี่ยวข้องกับดีลนี้ สิ่งที่เราทำคือระบบวางแผนทรัพยากรองค์กรและงานติดตั้งใช้งานจริงในองค์กรไทย ส่วนผู้ช่วยอัจฉริยะของ Saeree ERP ยังอยู่ในช่วงพัฒนาและฝึกระบบ ยังไม่ใช่ฟีเจอร์ที่ส่งมอบได้ในวันนี้
แต่ข้อสรุปของดีลนี้เป็นสิ่งที่เรายืนยันได้จากงานจริง คือคุณภาพของการนำไปใช้สำคัญกว่าตัวเลือกเทคโนโลยี ด้วยเหตุนี้ บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด จึงดำเนินงานภายใต้กรอบมาตรฐาน ISO/IEC 29110 ซึ่งกำหนดให้มีเอกสารความต้องการ แผนทดสอบ การตรวจรับโดยผู้ใช้ และแผนขึ้นระบบเป็นลายลักษณ์อักษร ไม่ใช่ข้อตกลงปากเปล่า
อีกส่วนที่สำคัญไม่แพ้กันคือความเข้าใจกระบวนการเฉพาะของไทย ทั้งรูปแบบเอกสารภาษี ขั้นตอนใบสั่งซื้อ และระเบียบการจัดซื้อจัดจ้างภาครัฐ ซึ่งเป็นรายละเอียดที่ตัดสินว่าระบบจะใช้งานได้จริงหรือไม่ องค์กรที่กำลังเริ่มพิจารณาเรื่องนี้อาจเริ่มจาก ระบบ ERP สำหรับธุรกิจขนาดกลางและเล็ก และแนวโน้มการนำ AI มาใช้กับงาน ERP ใน AI กับระบบ ERP ปี 2569
ขอบเขตที่ชัดเจน: ระบบ ERP ทำหน้าที่เป็นแหล่งข้อมูลจริงขององค์กร ส่วน AI เป็นผู้ช่วยที่ทำงานบนข้อมูลนั้น ลำดับนี้สลับกันไม่ได้ องค์กรที่ข้อมูลหลักยังกระจัดกระจายอยู่ในไฟล์รายแผนก การเพิ่ม AI เข้าไปจะได้คำตอบที่เร็วขึ้นแต่ไม่ได้ถูกต้องขึ้น
สรุป
ดีล Ode with Anthropic มูลค่าราว 1.5 พันล้านดอลลาร์สหรัฐ ไม่ได้เป็นข่าวใหญ่เพราะจำนวนเงิน แต่เพราะเงินก้อนนี้เลือกไปลงที่งานบริการ ไม่ใช่ที่ตัวเทคโนโลยี เมื่อนักลงทุนสถาบันระดับนี้ตัดสินใจแบบเดียวกันพร้อมกันหลายราย ข้อสรุปที่อยู่เบื้องหลังคือความสามารถของโมเดลไม่ใช่คอขวดอีกต่อไป คอขวดคือคนและกระบวนการที่จะพาความสามารถนั้นเข้าไปอยู่ในงานประจำวันขององค์กร
สำหรับองค์กรไทยที่กำลังตั้งงบด้าน AI ปี 2569 ข้อสรุปนี้แปลเป็นการปฏิบัติได้ตรง ๆ คือให้เวลากับการเลือกโมเดลน้อยลง และให้เวลากับสามเรื่องนี้มากขึ้น — ความสะอาดของข้อมูลตั้งต้น ความชัดเจนของเกณฑ์ตรวจรับ และคุณภาพของทีมที่จะเข้ามานั่งทำงานหน้างานจริง สามเรื่องนี้คือสิ่งที่ตัดสินว่าโครงการจะจบแบบไหน และเป็นสามเรื่องเดียวกับที่ตัดสินชะตากรรมของโครงการ ERP มาตลอด
"ซอฟต์แวร์ที่ดีกับการติดตั้งที่แย่ ให้ผลลัพธ์เท่ากับโครงการที่ล้มเหลว — ข้อนี้จริงกับ ERP มาสามสิบปี และเพิ่งมีคนจ่ายเงินพันล้านดอลลาร์เพื่อยืนยันว่ามันจริงกับ AI ด้วย"
- ทีมงาน Saeree ERP
แหล่งอ้างอิง
- TechCrunch — Anthropic, Blackstone bet the next trillion-dollar AI business is implementation, not just models (15 ก.ค. 2569)
- Business Wire — Anthropic, Blackstone, and Hellman & Friedman Introduce Ode with Anthropic, an Enterprise AI Services Firm (ประกาศทางการ)
- AIwire — รายละเอียดการเปิดตัว Ode with Anthropic
ตรวจสอบข้อมูลล่าสุดเมื่อ 20 กรกฎาคม 2569
สนใจระบบ ERP สำหรับองค์กรของคุณ?
คุยกับทีมที่ลงมือติดตั้งจริง ไม่ใช่แค่ขายซอฟต์แวร์ — บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด ทำงานภายใต้กรอบ ISO/IEC 29110 มีแผนทดสอบ ตรวจรับ และขึ้นระบบเป็นลายลักษณ์อักษร ปรึกษาฟรี ไม่มีค่าใช้จ่าย
ขอ Demo ฟรีโทร 02-347-7730 | sale@grandlinux.com
