- แม้ว่า การใช้จ่ายด้าน IT ทั่วโลกจะเพิ่มขึ้นมากกว่าสามเท่านับตั้งแต่ปี 2005 แต่ อัตราความสำเร็จของโปรเจกต์ซอฟต์แวร์ขนาดใหญ่แทบไม่ดีขึ้นเลย
- ความล้มเหลวด้าน การบริหาร การจัดการองค์กร และจริยธรรม เกิดขึ้นซ้ำแล้วซ้ำเล่าในกรณีอย่าง ระบบเงินเดือน Phoenix ของแคนาดา, Post Office Horizon ของสหราชอาณาจักร, รวมถึงระบบสวัสดิการและงานบริหารภาครัฐในสหรัฐฯ และออสเตรเลีย
- เครื่องมือ AI หรือ copilot ไม่สามารถแก้ปัญหาเหล่านี้ได้ และ การขาดจินตนาการของมนุษย์ เป้าหมายที่ไม่สมจริง และความล้มเหลวในการบริหารความเสี่ยง ยังคงเป็นสาเหตุหลัก
- ค่าใช้จ่ายในการดูแลระบบ legacy กินงบ IT ถึง 70~75% และแม้จะมีการนำ Agile·DevOps มาใช้ อัตราความล้มเหลวก็ยังสูงหากไม่มีภาวะผู้นำและการเปลี่ยนแปลงวัฒนธรรมองค์กร
- ความผิดพลาดด้านการจัดการและการหลีกเลี่ยงความรับผิดชอบ ที่เกิดซ้ำๆ ทำให้ต้นทุนทางสังคมสูงขึ้น และมีการชี้ว่า ความโปร่งใส จริยธรรม และการออกแบบระบบที่ยึดมนุษย์เป็นศูนย์กลาง คือโจทย์สำคัญที่ต้องทำให้ได้
ปัญหาซอฟต์แวร์ล้มเหลวที่ยังคงยืดเยื้อ
- ตลอด 20 ปีที่ผ่านมา การใช้จ่ายด้าน IT เพิ่มจาก 1.7 ล้านล้านดอลลาร์เป็น 5.6 ล้านล้านดอลลาร์ แต่ อัตราความสำเร็จของซอฟต์แวร์ยังคงทรงตัว
- ความล้มเหลวเกิดขึ้นโดยไม่เลือกประเทศ อุตสาหกรรม หรือรูปแบบองค์กร
- ต้นทุนทางสังคมและเศรษฐกิจของความล้มเหลวเพิ่มขึ้นอย่างต่อเนื่อง
- มีการระบุชัดถึง ข้อจำกัดของ AI ที่ไม่สามารถแก้ปัญหาด้านการบริหารจัดการได้
- AI ควบคุมความซับซ้อนของผู้มีส่วนได้ส่วนเสียจำนวนมากและปัจจัยทางการเมืองในโปรเจกต์ขนาดใหญ่ได้ยาก
- โปรเจกต์ IT เต็มไปด้วย การตัดสินใจที่ไม่สมเหตุสมผล อยู่แล้ว จึงมีกรณีให้ AI เรียนรู้ได้ไม่มากพอ
- สาเหตุของความล้มเหลวได้แก่ การขาดจินตนาการของมนุษย์ เป้าหมายไม่ชัดเจน ความล้มเหลวในการจัดการความซับซ้อน และการขาดการควบคุมความเสี่ยง
- ปัจจัยเดิมๆ ถูกทำซ้ำมาหลายทศวรรษจนเกิดภาวะ “failure déjà vu” อย่างต่อเนื่อง
ระบบเงินเดือน Phoenix ของแคนาดา
- ระบบ Phoenix มูลค่า 310 ล้านดอลลาร์แคนาดา ที่เริ่มใช้งานในปี 2016 ล้มเหลวในการพยายามรวมกฎการจ่ายเงินเดือน 80,000 รายการและข้อตกลงสหภาพแรงงาน 105 ฉบับเข้าด้วยกัน
- มีการดำเนินการแบบฝืนขั้นตอน เช่น ลดการทดสอบและขั้นตอน pilot รวมถึงตัดฟังก์ชันสำคัญออกเพื่อประหยัดงบประมาณ
- ผลลัพธ์คือในช่วง 9 ปี 70% ของพนักงาน 430,000 คนประสบปัญหาความผิดพลาดด้านเงินเดือน
- ณ เดือนมีนาคม 2025 ยังมี ข้อผิดพลาดที่ยังไม่แก้ 349,000 รายการ และมากกว่าครึ่งล่าช้าเกิน 1 ปี
- มีรายงานถึงขั้น พนักงานฆ่าตัวตาย
- ต้นทุนรวมอยู่ที่ มากกว่า 5.1 พันล้านดอลลาร์แคนาดา โดยสำนักงานตรวจเงินแผ่นดินประเมินว่าเป็น “ความล้มเหลวที่ยากจะเข้าใจของการบริหารโครงการและการกำกับดูแล”
ระบบ Post Office Horizon ของสหราชอาณาจักร
- ระบบ POS Horizon ของ Fujitsu ที่นำมาใช้ในปี 1999 ปกปิดข้อผิดพลาดภายใน และทำให้หัวหน้าสาขา 3,500 คนถูก ฟ้องร้องในข้อหาบัญชีเท็จและฉ้อโกง
- มีผู้ถูกตัดสินว่ามีความผิด 900 คน, ถูกคุมขัง 236 คน และมากกว่า 13 คนฆ่าตัวตาย
- เป็นผลจาก ความล้มเหลวด้านเทคนิค การจัดการ กฎหมาย และจริยธรรม ที่ซ้อนทับกัน
- มีทั้ง middleware ที่เต็มไปด้วยบั๊ก, การขยายขอบเขตโครงการแบบไร้การควบคุม, การทดสอบไม่เพียงพอ และกำลังคนไม่พอ
- ผู้บริหารมีท่าทีเป็นปฏิปักษ์ต่อผู้ที่ตั้งคำถาม ปกปิดหลักฐาน และพยายามปกปิดปัญหาในระดับองค์กร
- ความพยายามเปลี่ยนระบบในปี 2016 และ 2021 ก็ล้มเหลว และปัจจุบันยังคงใช้ Horizon อยู่
- ระบบใหม่มีงบประมาณ 410 ล้านปอนด์ และมีกำหนดตัดสินใจในเดือนกรกฎาคม 2026
กรณีล้มเหลวสำคัญอื่นๆ
- Minnesota MNLARS: เริ่มในปี 2016 ยกเลิกในปี 2019 ใช้งบ 100 ล้านดอลลาร์
- Modernising Business Registers ของออสเตรเลีย: งบประมาณ 480 ล้านดอลลาร์ออสเตรเลียพุ่งเป็น 2.8 พันล้านดอลลาร์ออสเตรเลีย ก่อนถูกยกเลิกในปี 2022
- ระบบทะเบียนยานยนต์ของลุยเซียนา: เมนเฟรมอายุ 50 ปีขัดข้องซ้ำ จนต้องประกาศภาวะฉุกเฉินในปี 2025
- Jaguar Land Rover: ถูกโจมตีทางไซเบอร์ในปี 2025 จนการดำเนินงานทั่วโลกหยุดชะงักนานกว่าหนึ่งเดือน ความเสียหาย 1.2~1.9 พันล้านดอลลาร์
- Lidl ERP: ระบบ ERP บน SAP มูลค่า 500 ล้านยูโรรัฐล้มเหลว ก่อนกลับไปใช้ระบบภายในของตัวเองอีกครั้งในปี 2017
- Boeing 737 Max: ข้อบกพร่องในการออกแบบ MCAS ทำให้มีผู้เสียชีวิต 346 คน ต้นทุนรวมประเมินที่ 7.4 หมื่นล้านดอลลาร์
- F-35 Block 4 upgrade: กำหนดการล่าช้า 5 ปี และต้นทุนเพิ่มจาก 10.5 พันล้านดอลลาร์เป็น 16.5 พันล้านดอลลาร์
ต้นทุนทางเศรษฐกิจของความล้มเหลว
- ในสหรัฐฯ เพียงประเทศเดียว ต้นทุนจากความล้มเหลวของซอฟต์แวร์ในปี 2022 อยู่ที่ 1.81 ล้านล้านดอลลาร์ และความล้มเหลวในการพัฒนามีมูลค่า 2.6 แสนล้านดอลลาร์
- ยอดรวมนี้ สูงกว่างบประมาณกลาโหม (7.78 แสนล้านดอลลาร์)
- ค่าใช้จ่ายในการดูแลระบบ legacy อยู่ที่ปีละ 5.2 แสนล้านดอลลาร์ คิดเป็น 70~75% ของงบ IT
- การเปลี่ยนระบบถูกเลื่อนออกไปเพราะต้นทุนเปลี่ยนสูงและเสี่ยงล้มเหลวมาก
- รายงาน NTT DATA ปี 2024: 80% ขององค์กรตอบว่าเทคโนโลยีเก่ากำลังขัดขวางนวัตกรรม
- ผู้บริหารส่วนใหญ่มองว่า โครงสร้างพื้นฐาน legacy ขัดขวางการตอบสนองต่อตลาด
ข้อจำกัดของ Agile·DevOps
- แม้แนวทางพัฒนาแบบวนรอบและค่อยเป็นค่อยไปจะแพร่หลายขึ้น แต่ อัตราความล้มเหลวยังไม่หายไป
- บางรายงานระบุว่าอัตราล้มเหลวของโปรเจกต์ Agile อยู่ที่ 65% และ DevOps อาจสูงถึง 90%
- การนำไปใช้ให้สำเร็จต้องอาศัย ภาวะผู้นำ วินัยขององค์กร การฝึกอบรม และการเปลี่ยนแปลงวัฒนธรรม
- แต่องค์กรส่วนใหญ่ไม่สามารถรักษาสิ่งเหล่านี้ได้อย่างต่อเนื่อง
ความผิดพลาดด้านการจัดการที่เกิดซ้ำและการไม่เรียนรู้
- ผู้จัดการโปรเจกต์ IT มักพูดว่า “โปรเจกต์ของเราไม่เหมือนกัน” แล้วเพิกเฉยต่อบทเรียนจากความล้มเหลวในอดีต
- รัฐบาลแคนาดาเองก็ทำซ้ำบทเรียนจากความล้มเหลวของระบบเงินเดือนครั้งแรกในปี 1995 อีกครั้งใน Phoenix
- ความล้มเหลวส่วนใหญ่ไม่ได้เกิดจากความพยายามที่แหวกแนว แต่เกิดจาก ความผิดพลาดด้านการจัดการแบบธรรมดาๆ
- มันใกล้เคียงกับ “การทำลายทางการเงิน” มากกว่า “การทำลายเชิงสร้างสรรค์”
- กรณีล้มเหลวของระบบบริหารภาครัฐที่ใช้ AI
- MiDAS ระบบเงินชดเชยการว่างงาน ของสหรัฐฯ และ Centrelink Robodebt ของออสเตรเลีย ใช้อัลกอริทึมผิดพลาดจนมีผู้คนนับแสนถูกกล่าวหาอย่างไม่เป็นธรรม
- รัฐบาลมีท่าทีไม่เต็มใจที่จะยอมรับความผิดพลาดและชดเชยความเสียหาย
ความจำเป็นของความรับผิดชอบ จริยธรรม และความโปร่งใส
- การตัดสินใจที่ไม่โปร่งใส ของระบบที่ฝัง AI อยู่ภายในก่อความกังวลเรื่องการละเมิดสิทธิของประชาชน
- สหภาพยุโรปคุ้มครอง ‘สิทธิในการได้รับคำอธิบายต่อการตัดสินใจของอัลกอริทึม’ ทางกฎหมาย
- มีการเรียกร้องทั่วโลกให้สถาปนา ความโปร่งใสและความรับผิดชอบของระบบอัตโนมัติ เป็นสิทธิมนุษยชน
- มีการถกเถียงเรื่อง กฎหมายความรับผิดของซอฟต์แวร์และระบบใบอนุญาตวิชาชีพสำหรับผู้เชี่ยวชาญ แต่ความเป็นไปได้ในการทำจริงยังต่ำ
- ทางเลือกที่เป็นจริงมากกว่าคือการเสริม ความซื่อสัตย์ของผู้บริหาร การคิดแบบตั้งคำถาม และการตัดสินใจเชิงจริยธรรม
- ต้องรับรู้ความเสี่ยงอย่างชัดเจน และระวังคำสัญญาเกินจริงจากผู้ขาย
- ย้ำว่าต้องใช้ หลักการออกแบบที่ยึดมนุษย์เป็นศูนย์กลางกับทุกระบบ IT รวมถึง AI
บทสรุป: ถึงเวลาหยุดทำผิดซ้ำแบบเดิม
- การพัฒนาซอฟต์แวร์มีธรรมชาติที่ ซับซ้อนและเปราะบาง และข้อผิดพลาดเล็กน้อยอาจนำไปสู่ผลลัพธ์ใหญ่โต
- โปรเจกต์ที่จะสำเร็จได้จำเป็นต้องมี ทรัพยากรที่เพียงพอ ภาวะผู้นำ และความรับผิดชอบ
- จำเป็นต้องคำนวณต้นทุนโดยรวมให้รวมถึง ความเสียหายทางอารมณ์และเศรษฐกิจ ที่เกิดกับผู้ใช้งานด้วย
- นับจาก “วิกฤตซอฟต์แวร์” ในปี 1968 เราก็ยังทำผิดพลาดแบบเดิมซ้ำมานานกว่า 50 ปี
- “จงทำความผิดพลาดแบบใหม่”
> “ทุกคนสามารถทำผิดพลาดได้ แต่มีเพียงคนโง่เท่านั้นที่ยืนกรานจะทำผิดพลาดเดิมของตัวเอง” - ซิเซโร นักปราศรัยแห่งโรม
5 ความคิดเห็น
ความเห็นจาก Hacker News
รู้สึกว่าแนวทางแก้ไขที่เสนอไว้ช่วงท้ายบทความยังน่าเสียดายอยู่
สำหรับผม ทางออกที่แท้จริงคือ เริ่มจากเล็ก ๆ แล้วตรวจสอบในสภาพแวดล้อมใช้งานจริง
ตัวอย่างเช่น ถ้าจะสร้างระบบเงินเดือนระดับประเทศ ก็ควรเริ่มทดสอบจากเมืองเล็ก ๆ ที่มีคนราว 50 คนก่อน จากนั้นแก้บั๊กแล้วค่อย ๆ ขยายไปสู่เมืองที่ใหญ่ขึ้น
กระบวนการพัฒนาซอฟต์แวร์ ที่ข้ามการแก้ปัญหาในขนาดเล็กแล้วไปทำระดับประเทศทีเดียวไม่มีอยู่จริง
ปริมาณธุรกรรมน้อยพอที่ถ้ามีปัญหาก็ยังปรับแก้ด้วยมือได้ และยังหลีกเลี่ยงข้อกำหนด PCI ได้ด้วย
การทดสอบแบบนี้ก่อนนำไปใช้ในร้านจริงช่วยให้เราส่งงานทันกำหนดโดยไม่เกิดอุบัติเหตุใหญ่
ถ้าปล่อยให้หน้าร้านลูกค้าตั้งแต่แรก คงเกิดความโกลาหลหนักจาก การคำนวณภาษีผิดพลาดหรือปัญหาด้านประสิทธิภาพ
การขยายแบบค่อยเป็นค่อยไปทำให้เกิดหนี้เทคนิคสะสม และสุดท้ายก็ไม่มีใครมั่นใจในแกนหลักของโค้ดเบส จนเกิด ความกลัวการเขียนใหม่
แม้จะเป็นผลิตภัณฑ์เรียบง่ายอย่าง WhatsApp ก็ยังต้องมีการออกแบบวิศวกรรมที่คำนึงถึง ความสามารถในการขยายขนาดระดับใหญ่ ตั้งแต่ต้น
ยิ่งเป็นระบบเล็กที่ประสบความสำเร็จ ก็ยิ่งมีโอกาสเกิดคนแบบนี้ขึ้นได้ง่าย และสามารถค่อย ๆ เติบโตโดยได้รับความเชื่อมั่นจากทั้งผู้ใช้และนักพัฒนา
โครงการขนาดใหญ่มีโอกาสล้มเหลวสูง ดังนั้นตาม หลักการป้องกันไว้ก่อน (Precautionary Principle) ก็ควรเริ่มจากเล็ก ๆ
ไม่ว่าโครงการไหน วงจรทำซ้ำนี้คือพื้นฐาน
คือเริ่มจากเล็ก ๆ แล้ว ทำให้เป็นโมดูลก่อนค่อยขยาย กรณีเมกะแฟกทอรีของ Tesla น่าประทับใจมาก
จากที่ศึกษาประวัติศาสตร์เทคโนโลยี ผมรู้สึกว่าอุตสาหกรรมฮาร์ดแวร์เรียนรู้จากความสำเร็จและความล้มเหลวในอดีต แต่ อุตสาหกรรมซอฟต์แวร์ไม่เป็นแบบนั้น
นักพัฒนาส่วนใหญ่ไม่ได้เรียนรู้ด้วยการรื้อดูระบบเก่า แต่ละรุ่นจึงต้องมาเจอปัญหาเดิมซ้ำอีก
ในการ retrospective ก็มักถามแค่ว่า “คราวหน้านักพัฒนาควรทำอะไรต่างออกไป” และ ผู้จัดการก็ไม่ต้องรับผิดชอบอะไรเลย
สุดท้ายปัญหาเดิมก็วนกลับมา และภาระทั้งหมดถูกผลักให้นักพัฒนา
คนรุ่นก่อนแก้ปัญหาจาก ชั้นล่างของสแตก แต่ตอนนี้กลับพยายามแก้จากชั้นบนอย่างเดียว
ผลคือเกิด หอคอยแห่ง abstraction ที่สูงขึ้นเรื่อย ๆ ใช้ทรัพยากรมากขึ้น แต่ฟังก์ชันแทบไม่ต่างเดิม
ตอนนี้เรากำลังเข้าสู่ยุคที่มีการวางซอฟต์แวร์อีกชั้นหนึ่งทับอยู่บนโมเดล AI
ทั้งประสบการณ์และบุคลิกสำคัญพอ ๆ กัน และจำเป็นต้องมี อีโก้ต่ำกับแนวคิดที่มุ่งแก้ปัญหา
คนส่วนใหญ่มักประเมินความซับซ้อนของโครงการต่ำเกินไป
ตอนเรียนปริญญาโท ผมเคยใช้เวลาหนึ่งสัปดาห์อ่านซอร์สโค้ด TinyOS เพื่อทำความเข้าใจโครงสร้าง และประสบการณ์นั้นช่วยได้มาก
ความสามารถในการทำความเข้าใจโค้ดเบสที่ไม่คุ้นเคยอย่างรวดเร็วมีประโยชน์มาก
ถ้ามีภาษาใหม่หรือเฟรมเวิร์กใหม่โผล่มาเป็นระยะ บริษัทก็จะสามารถจ้าง พนักงานใหม่ค่าแรงต่ำ เข้ามาได้เรื่อย ๆ
ผมคิดว่านี่เป็นหนึ่งในเหตุผลที่ซอฟต์แวร์ไม่ถูกปฏิบัติเหมือนวิศวกรรมแขนงอื่น
โดยพื้นฐานแล้ว นี่ไม่ใช่ปัญหาด้านการเขียนโปรแกรม แต่เป็นปัญหาเรื่อง ความไร้ความสามารถในการบริหารจัดการ
ในโครงการส่วนใหญ่ ความต้องการทางธุรกิจไม่ได้ถูกนิยามอย่างชัดเจน และทุกอย่างดำเนินไปบนพื้นฐานของ การคาดเดา
ความล้มเหลวของโครงการไอทีภาครัฐขนาดใหญ่เข้าใจได้ทันทีถ้ามองที่ โครงสร้างสัญญาและแรงจูงใจ
ปัญหาคือโครงสร้างที่พึ่งพา ที่ปรึกษาแบบคิดค่าบริการตามเวลา มากกว่าความสามารถที่แท้จริง
โครงการที่สำเร็จนั้น แก่นสำคัญไม่ใช่เทคโนโลยี แต่คือ การจัดแนวร่วมกันระหว่างองค์กร (alignment) และ ความสามารถ (competence)
ผมคิดว่าปัญหาจริงของซิลิคอนแวลลีย์คือ การเลือกปฏิบัติด้านอายุ
ประสบการณ์ถูกมองข้าม และบทเรียนจากอดีตก็ไม่ถูกนำมาสะท้อนใช้งานเลย
วงการฮาร์ดแวร์กลับเคารพมรดกเดิม พร้อมกับเดินหน้าสร้างนวัตกรรมไปด้วย
คือคนที่เรียนรู้จากความล้มเหลวในอดีตอาจกลายเป็นคนที่ไม่กล้าลองสิ่งใหม่
โครงการซอฟต์แวร์สุดท้ายแล้วล้มเหลวเพราะ ความล้มเหลวของมนุษย์
สิ่งที่สำคัญกว่ากระบวนการหรือเครื่องมือที่สมบูรณ์แบบ คือ คนที่มีแรงจูงใจและมีความรับผิดชอบ
ต้องมี ผลลัพธ์หรือบทลงโทษ (Consequences) ทางกฎหมาย ผู้คนจึงจะทำงานกันอย่างจริงจัง
เหมือนงานก่อสร้างทางกายภาพ ที่แต่ละขั้นควรมีการตรวจสอบอิสระและมีผู้รับผิดชอบชัดเจน
เพราะฉะนั้นในโลกจริงจึงต้องเดินหน้าต่อไปโดยยอมรับความเสี่ยงในระดับหนึ่ง
โครงการที่สำเร็จมักเกิดจากคนไม่กี่คนที่มี ความฉลาดทางอารมณ์และภาวะผู้นำ
สุดท้ายแล้ววิศวกรรมซอฟต์แวร์คือ ปัญหาเรื่องคน
แต่อุตสาหกรรมนี้ยังคงติดอยู่กับ การเลี่ยงความรับผิดชอบและการวิ่งตามกระแส
ปัญหาแบบนี้ไม่ใช่เรื่องเฉพาะของซอฟต์แวร์
โครงการโยธาขนาดใหญ่อย่าง Auburn Dam, Columbia River Crossing, Big Dig ก็ขึ้นชื่อเรื่องงบบานปลายเหมือนกัน
ถ้างบตั้งต้นนั้น ไม่สมจริง อยู่แล้ว มันก็อาจเป็นแค่ตัวเลขต้นทุนที่สะท้อนความจริงเท่านั้น
เพราะแบบนี้เอง แนวทาง เริ่มจากโครงการเล็กแล้วค่อย ๆ ขยาย จึงสำคัญ
ผมไม่ใช่นักพัฒนาหรือ PM แต่สนใจว่ามีกรณีความสำเร็จขนาดใหญ่แบบไหนบ้าง
เพราะผมทำงานในโรงพยาบาล ถ้าเป็น กรณีสำเร็จในสายเฮลท์แคร์ จะยิ่งดี
ผมอ่าน The Phoenix Project แล้วพอเข้าใจ แนวคิด Agile และ DevOps มากขึ้นบ้าง แต่ก็ยังนำไปใช้จริงได้ยาก
อยากเริ่มหว่านเมล็ดแห่งความสำเร็จจากโครงการเล็ก ๆ
จุดเริ่มต้นคือการทบทวนความซับซ้อนของ Multics และ Ken Thompson ลงมือ เขียน Unix เองภายใน 3 สัปดาห์
ดู บทความนี้ ประกอบ
เรื่องอย่าง Conway’s Law, ความเสี่ยงจากการพึ่งพาคนสำคัญ, ความเป็นเจ้าของที่ชัดเจน, วัฒนธรรมการทดสอบ ก็จำเป็นทั้งหมด
ที่สำคัญที่สุดคือ ต้องมีความกล้าที่จะพูดว่า “ไม่”
ส่วน healthcare.gov ก็เป็นตัวอย่างของกรณีที่ล้มเหลวก่อนแล้วค่อยปรับปรุงจนดีขึ้น
ก่อนจะโทษชุมชนไอที เราควรมองไปที่ วัฒนธรรมองค์กรที่เน้นผลประโยชน์ระยะสั้น
เรื่องความปลอดภัยและเสถียรภาพมักเป็น เป้าหมายแรกของการตัดงบ เสมอ
ผู้บริหารล้มเหลวแล้วก็ยังจากไปพร้อม golden parachute ส่วนความรับผิดชอบกลับตกค้างอยู่กับนักพัฒนา
ภาครัฐเองก็ไม่ได้ลงโทษบริษัทอย่างจริงจังต่อกรณี เหตุการณ์ความปลอดภัยที่หละหลวม
สุดท้ายก็วนกลับไปสู่ความจริงอันขมขื่นแบบ “ใช้ AI, ใช้ที่ปรึกษา, จ้างเอาต์ซอร์ส” เพื่อแก้ปัญหา
การทุ่มเงินระดับหลายล้านล้านวอนให้ AI ไม่ได้ทำให้สถานการณ์ดีขึ้น แถมจะ เลวร้ายลง ด้วยซ้ำ
ตอนนี้สังคมตะวันตกก็ไม่มั่นคงอยู่แล้ว และกำลังเอนเอียงไปทางขวาจัด
วิกฤตรอบต่อไปอาจไม่ใช่แค่การพังทางการเงิน แต่ลุกลามเป็น การล่มสลายทางสังคม ได้
มนุษยชาติควรเดินหน้าไปสู่ ความก้าวหน้าผ่านความเข้าใจ แทนที่จะต้องรอให้เกิดวิกฤต
ถ้ามีกระบวนการที่ดี มันก็ช่วยขยายผลลัพธ์ที่ดี แต่ถ้ามีกระบวนการที่แย่ มันก็จะ เร่งให้ปัญหารุนแรงขึ้น
ทิศทางเดิมยังคงเดิม มีแค่ความเร็วที่เพิ่มขึ้นเท่านั้น
ถ้ามันยังไม่ได้รับการแก้ไขมาเป็นเวลานานขนาดนี้ ปัญหาอาจไม่ใช่เรื่องเทคนิคการพัฒนาหรือหลักการพัฒนา แต่อาจเป็นปัญหาฝั่งปฏิบัติการที่รับเอาไปใช้งานมากกว่าหรือเปล่า...
กรณีอื้อฉาวของไปรษณีย์อังกฤษก็มีฉบับละครด้วย
จนถึงตอนนี้ผู้เสียหายก็ยังไม่ได้รับการชดเชย จึงยังคงเป็นประเด็นที่ดำเนินอยู่ต่อไป
กรณีในประเทศช่วงหลังที่นึกออกก็คือกรณีล้มเหลวของการสร้างระบบคอมพิวเตอร์ยุคถัดไปของ Gyeonggi Credit Guarantee Foundation
https://v.daum.net/v/20251111165048155
ประเทศอื่น ๆ ก็มีการดำเนินโครงการ SI ขนาดใหญ่มหาศาลแบบนี้เหมือนกันหรือ