- ภาพรวมโดยสรุป:
- ประเด็นหลัก: ความล้มเหลวของโครงการ IT ไม่ได้เกิดจากความท้าทายทางเทคนิค แต่เกิดจาก 'ความไม่รู้โดยจงใจ' ของผู้บริหารและความหยิ่งผยองที่ปฏิเสธจะเรียนรู้จากกรณีล้มเหลวในอดีต
- ตัวเลขสำคัญ: ตลอด 20 ปีที่ผ่านมา การใช้จ่ายด้าน IT ทั่วโลกเพิ่มขึ้น 3 เท่า (5.6 ล้านล้านดอลลาร์) แต่อัตราความสำเร็จยังคงเท่าเดิม และงบประมาณถึง 75% ถูกใช้ไปกับการบำรุงรักษาระบบเลกาซีเพียงอย่างเดียว
- กรณีตัวอย่างสำคัญ: ความล้มเหลวด้านการบริหารแบบครบวงจรของระบบ Phoenix ในแคนาดา และการปกปิดที่ไร้จริยธรรมในคดี Horizon ของสหราชอาณาจักร ไม่ใช่แค่ 'ความผิดพลาด (Blunder)' แต่เป็น 'ความชั่วร้ายเชิงบริหาร (Administrative Evil)'
1. บทนำ: อัตราความล้มเหลวที่ไม่ดีขึ้นแม้มีการลงทุนมหาศาล
- ประสิทธิภาพต่อการลงทุนที่ชะงักงัน:
- นับตั้งแต่ปี 2005 การใช้จ่ายด้าน IT ทั่วโลกพุ่งจาก 1.7 ล้านล้านดอลลาร์เป็น 5.6 ล้านล้านดอลลาร์ในปี 2025 หรือเพิ่มขึ้นมากกว่า 3 เท่า
- แต่ถึงจะทุ่มงบประมาณมหาศาล อัตราความสำเร็จของโครงการซอฟต์แวร์ก็ยังไม่แสดงให้เห็นถึงการปรับปรุงอย่างชัดเจนตลอด 20 ปีที่ผ่านมา
- คำเตือนต่อภาพฝันเรื่อง AI:
- ผู้บริหารจำนวนมากคาดหวังว่าเครื่องมือ AI หรือเครื่องมือช่วยเขียนโค้ดอย่าง Copilot จะทำให้โครงการขนาดใหญ่ประสบความสำเร็จได้ แต่ผู้เขียนมองเรื่องนี้อย่างสงสัย
- AI ไม่สามารถแก้ความซับซ้อนของวิศวกรรมระบบ การแลกเปลี่ยนเชิงการเงิน และที่สำคัญที่สุดคือ 'การเมืองภายในองค์กร (Organizational Politics)' ภายในโครงการได้
- ปรากฏการณ์ความล้มเหลวที่เกิดขึ้นทั่วไป:
- ความล้มเหลวของซอฟต์แวร์เกิดขึ้นอย่างไม่เลือกทั้งประเทศ ขนาดองค์กร และไม่ว่าจะเป็นองค์กรแสวงหากำไรหรือไม่แสวงหากำไร ซึ่งชี้ว่ามันไม่ได้เป็นเพียงข้อผิดพลาดทางเทคนิค แต่มีต้นตอมาจาก 'การขาดจินตนาการของมนุษย์' และ 'เป้าหมายที่ไม่สมจริง'
2. เนื้อหา: วิเคราะห์เชิงลึกประเภทและสาเหตุของความล้มเหลว
2.1. 'ความผิดพลาด (Blunder)' ที่เกิดซ้ำและการปฏิเสธการเรียนรู้
- การแยกความต่างระหว่างความล้มเหลวกับความผิดพลาด:
- ความล้มเหลวในฐานะ 'การทำลายอย่างสร้างสรรค์ (Creative Destruction)' ที่เกิดขึ้นจากการท้าทายขีดจำกัดทางเทคนิคควรได้รับการยอมรับ
- แต่ความล้มเหลวด้าน IT ส่วนใหญ่เป็นเพียง 'ความผิดพลาดโง่ ๆ (Blunder)' ที่ทำซ้ำสาเหตุเดิมซึ่งถูกบันทึกไว้แล้วมานานหลายสิบปี เช่น การไม่มีการบริหารความเสี่ยง หรือการประเมินความซับซ้อนต่ำเกินไป
- ความหยิ่งผยองของผู้บริหาร:
- ผู้จัดการโครงการมักอ้างว่าโครงการของตน "พิเศษและไม่เหมือนใคร" และมีแนวโน้มจะเพิกเฉยต่อกรณีล้มเหลวในอดีตหรือข้อมูลที่มีอยู่
- นี่ไม่ใช่เพียงความไม่รู้ แต่คือ 'ความไม่รู้โดยจงใจ (Willful Ignorance)' ที่เลือกจะเมินสัญญาณเตือนความเสี่ยงอย่างตั้งใจ
- กับดักของระบบเลกาซี:
- องค์กรในสหรัฐฯ ใช้เงินมากกว่า 5.2 แสนล้านดอลลาร์ต่อปีไปกับการบำรุงรักษาระบบเลกาซีเพียงอย่างเดียว คิดเป็น 70~75% ของงบประมาณ IT ทั้งหมด
- เพราะกลัวการเปลี่ยนระบบแล้วล้มเหลว องค์กรจึงเลื่อนการทำให้ทันสมัยออกไป จนกว่าระบบจะพังทางกายภาพจริง ๆ (เช่น เมนเฟรมของสำนักงานยานยนต์รัฐลุยเซียนา) หรือหมดความคุ้มค่าทางต้นทุนโดยสิ้นเชิง
2.2. รายละเอียดของกรณีล้มเหลวสำคัญและผลกระทบต่อเนื่อง
- ระบบเงินเดือน Phoenix ของแคนาดา:
- การตัดสินใจผิดพลาดตั้งแต่ต้น: ขณะนำโซลูชันสำเร็จรูป (PeopleSoft) มาใช้ มีความพยายามจะปรับแต่งกฎการจ่ายเงินเดือน 80,000 ข้อและข้อตกลงแรงงานสัมพันธ์ 105 ฉบับ
- ราคาที่ต้องจ่ายจากการตัดงบ: เพื่อให้โครงการดำเนินได้ด้วยงบต่ำกว่า 60% ของงบที่ผู้ขายเสนอ จึงมีการบังคับตัดฟังก์ชันเงินเดือนหลัก ลดการทดสอบ และข้ามการทดสอบนำร่องที่จำเป็น
- ผลลัพธ์: ระบบล่มแทบจะทันทีหลังเปิดใช้งานในปี 2016 ทำให้พนักงานได้รับเงินเดือนผิดพลาดและก่อความเดือดร้อนทางการเงิน (บางกรณีถูกชี้ว่าเป็นสาเหตุของการฆ่าตัวตายของพนักงาน)
- ต้นทุน: งบเริ่มต้นอยู่ที่ 310 ล้านดอลลาร์แคนาดา แต่ค่าใช้จ่ายเพื่อกู้คืนและแก้ไขปัญหาปัจจุบันเกิน 5.1 พันล้านดอลลาร์แคนาดาแล้ว (ราว 3.6 พันล้านดอลลาร์สหรัฐ)
- คดีอื้อฉาว Horizon ของไปรษณีย์สหราชอาณาจักร:
- ข้อบกพร่องทางเทคนิค: บั๊กในมิดเดิลแวร์ของระบบที่ Fujitsu จัดหาให้ ทำให้เกิดข้อผิดพลาดด้านยอดเงินไม่ตรงกัน
- การปกปิดในระดับองค์กร: ผู้บริหารรู้ถึงข้อบกพร่องของซอฟต์แวร์แต่ปกปิดไว้ และกลับดำเนินคดีกับหัวหน้าไปรษณีย์ 3,500 คนในข้อหายักยอกและลักทรัพย์ โดยมี 900 คนถูกตัดสินว่ามีความผิดและถูกจำคุก
- ต้นทุนทางสังคม: เหยื่อต้องเผชิญการล้มละลาย การหย่าร้าง การจำคุก และการฆ่าตัวตาย จนถูกบันทึกว่าเป็นทั้งความล้มเหลวด้าน IT และความผิดพลาดทางกระบวนการยุติธรรมที่เลวร้ายที่สุดครั้งหนึ่งในประวัติศาสตร์สหราชอาณาจักร
2.3. การตัดสินใจอัตโนมัติและ 'ความชั่วร้ายเชิงบริหาร'
- ความรุนแรงของอัลกอริทึม:
- ระบบ MiDAS ของรัฐมิชิแกนในสหรัฐฯ (ตรวจจับการทุจริตเงินช่วยเหลือคนว่างงาน) และ Robodebt ของออสเตรเลีย (ตรวจจับการทุจริตสวัสดิการ) ตัดสินผลโดยพึ่งพาอัลกอริทึมล้วน ๆ โดยไม่มีการกำกับดูแลจากมนุษย์
- พลเมืองผู้บริสุทธิ์นับหมื่นถูกทำให้กลายเป็นอาชญากร แต่แม้ระบบจะพิสูจน์แล้วว่าผิดพลาด บรรดาข้าราชการก็ยังปฏิเสธการชดเชยหรือหลีกเลี่ยงความรับผิดชอบ
- ความเสี่ยงของการนำ AI มาใช้:
- 'ความชั่วร้ายเชิงบริหาร (Administrative Evil)' ลักษณะนี้จะยิ่งรุนแรงขึ้น เมื่อ AI เข้าไปแทรกซึมลึกขึ้นในโครงสร้างพื้นฐานสาธารณะ
- แม้ EU จะนำ 'สิทธิในการขอคำอธิบาย' มาใช้แล้ว แต่ทั่วโลกยังจำเป็นต้องเร่งสร้างความโปร่งใสและความรับผิดชอบต่ออัลกอริทึมอย่างเร่งด่วน
3. บทสรุป: ทางออกและภารกิจของชุมชน IT
- วิธีการ (Agile/DevOps) ไม่ใช่กุญแจสารพัดนึก:
- มีรายงานว่าอัตราความล้มเหลวของโครงการ Agile สูงได้ถึง 65% แสดงให้เห็นว่าวิธีการเองไม่ได้รับประกันความสำเร็จ หากไม่มีภาวะผู้นำที่สม่ำเสมอและวินัยในระดับองค์กร วิธีการใหม่ใด ๆ ก็ล้มเหลวได้ทั้งนั้น
- การประเมินความเสี่ยงอย่างตรงไปตรงมาและความรับผิดชอบเชิงจริยธรรม:
- ก่อนเริ่มโครงการ ต้องมีการวิเคราะห์ช่องว่าง (Gap Analysis) อย่างตรงไปตรงมาว่า "รู้อะไร และไม่รู้อะไร"
- ควรขยายแนวคิด 'AI ที่ยึดมนุษย์เป็นศูนย์กลาง (Human-centered AI)' ไปยังทุกโครงการ IT เพื่อรวมความเสียหายทางอารมณ์และการเงินที่ความล้มเหลวของระบบจะสร้างต่อผู้ใช้ปลายทางเข้าไว้ในการวิเคราะห์ต้นทุนและผลประโยชน์
- เรียกร้องให้ผู้บริหารเปลี่ยนท่าที:
- ซอฟต์แวร์นั้นเปราะบาง (Fragile) และซับซ้อนโดยธรรมชาติ ผู้บริหารจึงต้องให้ความเคารพและสนับสนุนการพัฒนาซอฟต์แวร์ ไม่ใช่แค่ในฐานะผู้ถืออำนาจงบประมาณ แต่ในฐานะผู้ที่ต้องรับผิดชอบเมื่อเกิดความล้มเหลว
- การหยุดวงจรความผิดพลาดซ้ำ ๆ เท่านั้น คือหนทางเดียวที่อุตสาหกรรม IT จะหลุดพ้นจาก 'วิกฤต (Crisis)' ได้
1 ความคิดเห็น
สรุปปฏิกิริยาในคอมเมนต์ของ Hacker News
1. การขาดกลยุทธ์การทยอยปล่อยใช้งานและการสเกล (Start Small)
2. ความไร้ความสามารถของผู้บริหารและการหลีกเลี่ยงความรับผิดชอบ (Management Issues)
3. ความต้องการที่ควบคุมไม่ได้และความซับซ้อน (Complexity & Scope Creep)
4. วัฒนธรรมนักพัฒนาและแรงจูงใจที่ผิดเพี้ยน (Developer Culture)
5. ลักษณะเฉพาะของวิศวกรรมซอฟต์แวร์ (Engineering Nature)