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

เนื้อหาที่แท้จริงของรายงานวิจัย MIT

  • การตีความที่บิดเบือนซึ่งอินฟลูเอนเซอร์สาย AI เผยแพร่: บน X และ YouTube มีการยกคำว่า "โครงการ AI ล้มเหลว 95%" มาใช้เป็นหลักฐานว่า "AI เป็นเรื่องหลอกลวง"
  • งานวิจัยจริงเป็นการวิเคราะห์ วิธีที่องค์กรนำ AI ไปใช้และปัจจัยแห่งความสำเร็จ พร้อมยืนยันวิธีการทำงานจริงของ AI agent และแนวทางที่มีประสิทธิภาพ
  • แม้แต่นักศึกษามหาวิทยาลัยหลายคนก็อ่านแค่เวอร์ชันทวีตแล้วสรุปผิดว่า "สตาร์ตอัป AI ที่ YC พูดถึงใช้งานไม่ได้จริง"

สาเหตุเชิงโครงสร้างที่ทำให้องค์กรใช้ AI ล้มเหลว

  • ปัญหาเรื้อรังของระบบ IT ภายใน: ระบบ IT ภายในของบริษัทส่วนใหญ่มีคุณภาพต่ำ และยิ่งจ้างบริษัทที่ปรึกษาอย่าง Ernst & Young หรือ Deloitte ปัญหาก็มักยิ่งเพิ่มเป็นสองเท่า
  • แม้แต่ Apple ก็ยังพัฒนาซอฟต์แวร์พลาดได้: ต่อให้มีทั้งเงินทุนมหาศาลและเข้าถึงคนเก่งได้ไม่จำกัด Apple เองก็ยังมีบั๊กในแอปปฏิทินทุกวัน
    • เป็นตัวอย่างที่ชี้ให้เห็นว่าแม้แต่องค์กรทั่วไปหรือฝ่าย IT ก็สร้างซอฟต์แวร์ที่ดีได้ยาก
  • ความขัดแย้งทางการเมืองภายในองค์กร: เมื่อองค์กรใหญ่ต้อง deploy ซอฟต์แวร์ที่ซับซ้อน จะมีหลายทีมเข้ามาเกี่ยวข้องจนเกิด การต่อสู้ทางการเมืองและการแย่งพื้นที่รับผิดชอบ
    • ที่ปรึกษาต้องคอยประสานระหว่างทีม data science ทีมซัพพอร์ตลูกค้า ทีม IT ฯลฯ พร้อมเขียนเอกสาร requirement
    • แต่ที่ปรึกษาเหล่านี้กลับ ขาดความเชี่ยวชาญเชิงเทคนิคในการสร้างซอฟต์แวร์จริง
  • ข้อจำกัดของระบบ legacy: ระบบภายในองค์กรทั้งเก่าและแยกเป็นไซโลมากเกินไป จนต้องการทั้งความเชี่ยวชาญจากที่ปรึกษาภายนอกและความสามารถในการสร้างซอฟต์แวร์ในเวลาเดียวกัน
  • ผลลัพธ์สุดท้ายจึงมักออกมาเป็นเหมือน อูฐที่ออกแบบโดยคณะกรรมการ คือเป็นผลของการประนีประนอมที่แทบใช้งานจริงไม่ได้

ตัวอย่างสตาร์ตอัปที่ประสบความสำเร็จ

  • Tactile (เอนจินตัดสินใจทางธุรกิจ)

    • ประมวลผล KYC/AML แบบเรียลไทม์สำหรับธนาคาร: จัดการการตรวจสอบเครดิตและกฎทางธุรกิจของผู้ขอสินเชื่อในระดับหลายล้านรายการต่อวัน
    • Citibank และ JP Morgan เคยพยายามพัฒนาเอง แต่ต้องใช้เวลา 3-5 ปีและเงินหลายสิบล้านดอลลาร์
    • Tactile ให้ การตัดสินใจแบบเรียลไทม์ผ่าน REST API รองรับการเสียบปลั๊กโมเดล AI รุ่นใหม่ และสร้างได้ด้วยงบประมาณเพียงบางส่วนกับเวลาที่สั้นกว่ามาก
  • Greenlight (ระบบ AI สำหรับธนาคาร)

    • ธนาคารแห่งหนึ่งเคยว่าจ้างผู้ขายเดิมอย่าง Ernst & Young ให้สร้างระบบ AI
    • Ernst & Young พัฒนานาน 1 ปีแต่ล้มเหลวโดยสิ้นเชิง
    • จากนั้นธนาคารจึงกลับไปหา Greenlight และตอนนี้ระบบ ถูกนำไปใช้งานจริงเต็มรูปแบบแล้ว
  • ผลการวิจัย: ผู้ขายภายนอก vs การพัฒนาภายใน

    • ในโครงการที่สำรวจ 2/3 เป็นการพัฒนาเองหรือทำร่วมกับบริษัทที่ปรึกษา
    • มีเพียง 1/3 เท่านั้นที่ซื้อผลิตภัณฑ์จากผู้ขายภายนอกอย่าง Greenlight หรือ Tactile
    • เมื่อเลือกผู้ขายภายนอก อัตราความสำเร็จสูงกว่าการพัฒนาเองมาก

ทำไมสตาร์ตอัปจึงประสบความสำเร็จ

  • ปัญหาการขาดแคลน polymath: คนที่เก่งทั้งด้านผลิตภัณฑ์และวิศวกรรมพร้อมกันนั้นมีน้อยมาก
    • วิศวกรเก่ง ๆ มักโฟกัสอยู่แค่การเขียนโค้ด จน สื่อสารกับผู้ใช้เชิงโดเมน อย่างพนักงานธนาคารไม่ได้
    • ส่วนผู้เชี่ยวชาญด้านโดเมนก็มักขาดทักษะด้านการเขียนโค้ด เทคโนโลยี การออกแบบ และการส่งมอบผลิตภัณฑ์
  • กรณีของ Windsurf: ผู้นำฝ่ายขายที่ไม่มีปริญญาวิศวกรรมสามารถสร้างเครื่องมือใช้เองด้วย Windsurf
    • เรื่องแบบนี้เกิดขึ้นแล้วในองค์กรระดับ IQ 150 แต่สำหรับองค์กรส่วนใหญ่ยังเป็นไปไม่ได้
  • ช่องว่างในรูปแบบสตาร์ตอัป: ทุกกระบวนการทางธุรกิจและทุกระบบยังมีช่องว่างที่สตาร์ตอัปเข้าไปเติมเต็มได้
  • ต้องการชุดทักษะหายาก: ต้องเข้าใจ AI รุ่นใหม่ มีเซนส์ด้านผลิตภัณฑ์ และเข้าใจกระบวนการของมนุษย์ไปพร้อมกัน
  • กรณีของ Castle AI (เซิร์ฟเวอร์สินเชื่อจำนอง)

    • ความพยายามของผู้ขาย legacy ในการเพิ่ม AI: พยายามเอา AI ไปแปะทับบนระบบที่มีมาหลายสิบปีเพื่อแข่งขัน
    • ธนาคารจำเป็นต้องจัดการแข่งแบบ bake-off กับผู้ขายเดิมที่ไว้วางใจอยู่
    • หลายครั้งโซลูชันของผู้ขายเดิมมีคุณภาพต่ำมาก เป็นแค่ระดับ "เอา AI มาครอบไว้เฉย ๆ"
    • Castle AI ได้เซ็นสัญญากับธนาคารใหญ่ด้วย เซนส์ด้านผลิตภัณฑ์จากการสร้างแบบ native ตั้งแต่ต้น
    • และทำผลลัพธ์ได้สำเร็จภายใน 1 ปีหลังติดตั้งใช้งาน
  • กรณีของ Reducto (ประมวลผลเอกสาร)

    • บริษัทยักษ์ใหญ่กลุ่ม FAANG ค้นพบโดยตรงผ่าน YC Launch: หลังเข้า batch ได้เพียง 154 วันก็เซ็นสัญญากับบริษัท FAANG
    • บริษัทดังกล่าว พยายามสร้างโซลูชันภายในมาหลายปี
      • เคยลองทั้งโอเพนซอร์ส, AWS Tesseract และโซลูชัน OCR หลายแบบ แต่ไม่สำเร็จ
    • ได้สัญญามาด้วย ความยอดเยี่ยมของตัวผลิตภัณฑ์ (product excellence)
    • ระหว่างทางยังต้องแข่งขันกับทีมภายในและ นำทางการเมืองในองค์กรอย่างระมัดระวัง
      • ซึ่งเป็นความท้าทายที่ถูกรายงานใน MIT เช่นกัน
    • ปัจจุบันระบบใช้งานใน production มานานกว่า 1-2 ปีแล้ว

กลยุทธ์สู่ความสำเร็จ

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

ความตั้งใจขององค์กรในการนำ AI ไปใช้ และโอกาสของสตาร์ตอัป

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

ข้อความถึงคนที่ยังสงสัยใน AI

  • ลองทำด้วยตัวเอง

    • ถ้าเป็นวิศวกร ควร ลงทุนเวลาเพื่อใช้งานกับโปรเจกต์จริง
    • อย่าลองแค่ครั้งเดียวแล้วเจอ error เรื่องชื่อตัวแปรก่อนจะยอมแพ้
    • จะเริ่มจาก โปรเจกต์สนุก ๆ นอกงานหลัก ก็ได้
    • กรณี "Vibe Coding Dad's Night": เจ้าของบ้านที่ไม่ใช่สายเทคนิคสร้างระบบตรวจสอบค่าเช่าของผู้เช่าได้เอง
    • เป็นเครื่องมือที่ทำให้ วิศวกรระดับ 10x กลายเป็น 100x และวิศวกรระดับ 1x กลายเป็น 10x
    • ความท้าทายคือการต้องเอาชนะอารมณ์ภายในของตัวเอง
  • กรณีการบิดเบือนบทสัมภาษณ์ Andrej Karpathy

    • มีทวีตว่า: "Karpathy บอกว่า agent ถูก hype เกินจริง"
    • แต่สิ่งที่เขาพูดจริงคือ ไม่สามารถแค่ให้พรอมป์ต์กับ agent แล้วคาดหวังผลลัพธ์สมบูรณ์แบบได้ ต้องมี ข้อมูล คอนเท็กซ์ การประเมินผล และงานเครื่องมือที่ถูกต้อง
    • ความหมายที่แท้จริงคือ: นี่คือโอกาสมหาศาลของสตาร์ตอัปและนักพัฒนาซอฟต์แวร์
      • ยังมีเครื่องมือยอดเยี่ยมอีกมากมายมหาศาลที่รอให้สร้าง
    • AI เป็น เครื่องมือที่ต้องช่วยให้มันทำงานได้ดีขึ้น ไม่ใช่สิ่งมหัศจรรย์ที่จะทำงานได้เองโดยอัตโนมัติ

การสร้างระบบ AI-native ขึ้นใหม่คือโอกาส

  • ทุกระบบจำเป็นต้องถูกเขียนใหม่ทั้งหมดให้เป็น AI-native
  • ซอฟต์แวร์ต้องถูกเขียนขึ้นใหม่ทั้งหมดเพื่อให้ทำงานร่วมกับ AI ได้จริง
  • สิ่งนี้มอบ โอกาสไม่สิ้นสุดแก่ผู้ก่อตั้ง
  • "เมื่อใดก็ตามที่ลงทุนเวลาไปกับการฝึกระบบแล้ว ต้นทุนการย้ายออกจะสูงจนแทบรับไม่ไหว"
  • นี่แหละคือ moat สำหรับคนที่กังวลว่า ChatGPT wrapper จะไม่มี moat

บทสรุป: โอกาสของสตาร์ตอัป

  • การตีความผิดของฝั่งมองลบต่อ AI: บิดเบือนอัตราล้มเหลว 95% ให้กลายเป็นหลักฐานว่า AI เป็นไปไม่ได้
  • แต่ข้อความจริงคือ: การนำ AI ไปใช้นั้นยากมาก และมีเพียง 5% ที่สำเร็จ
  • อย่างไรก็ตาม อัตราการตอบรับของ YC ต่ำกว่า 1%: และผู้ก่อตั้ง 1% นั้นเองที่สร้างตัวอย่างการนำไปใช้สำเร็จในระดับท็อป 1%
  • ปัจจัยแห่งความสำเร็จ: ทักษะทางเทคนิคที่ยอดเยี่ยม + ความเป็น polymath + ความเข้าใจผู้อื่น
    • รวมถึงการเข้าใจว่าผู้บริหาร CIO ของฟินเทคมูลค่า 5 พันล้านดอลลาร์ต้องการอะไรจริง ๆ
  • จงมั่นใจว่าคุณสามารถอยู่ใน 5% นั้นได้: ถ้าเก่งจริงก็เป็นไปได้แน่นอน และมีตัวอย่างจำนวนมากใน YC

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น