Proyek Perangkat Lunak Skala Besar yang Tetap Gagal Meski Sudah Menghamburkan Triliunan Dolar

• Belanja TI global telah meningkat lebih dari tiga kali lipat sejak 2005, tetapi tingkat keberhasilan proyek perangkat lunak skala besar hampir tidak membaik
• Sistem penggajian Phoenix di Kanada, Post Office Horizon di Inggris, serta sistem kesejahteraan dan administrasi di AS dan Australia menunjukkan kegagalan manajerial, organisasional, dan etis yang terus berulang
• Alat AI atau copilot tidak bisa menyelesaikan masalah ini; kurangnya imajinasi manusia, target yang tidak realistis, dan kegagalan manajemen risiko tetap menjadi penyebab utama
• Biaya pemeliharaan sistem legacy menyerap 70–75% anggaran TI, dan adopsi Agile·DevOps juga memiliki tingkat kegagalan tinggi tanpa kepemimpinan organisasi dan perubahan budaya
• Kesalahan manajemen dan penghindaran tanggung jawab yang terus berulang memperbesar biaya sosial, sehingga transparansi, etika, dan desain sistem yang berpusat pada manusia menjadi tugas penting

---

Masalah kegagalan perangkat lunak yang terus berlanjut

• Selama 20 tahun terakhir, belanja TI meningkat dari US$1,7 triliun menjadi US$5,6 triliun, tetapi tingkat keberhasilan perangkat lunak tetap stagnan
  • Kegagalan terjadi tanpa memandang negara, industri, atau bentuk organisasi
  • Biaya sosial dan ekonomi dari kegagalan terus meningkat
• Ditegaskan adanya batasan AI dalam menyelesaikan masalah manajemen
  • AI sulit mengendalikan hubungan kepentingan yang kompleks dan faktor politik dalam proyek skala besar
  • Proyek TI sudah dipenuhi pengambilan keputusan yang tidak rasional, sehingga kurang ada contoh yang layak dipelajari AI
• Penyebab kegagalan mencakup kurangnya imajinasi manusia, tujuan yang tidak jelas, kegagalan mengelola kompleksitas, dan tidak adanya kontrol risiko
  • Faktor yang sama telah berulang selama puluhan tahun, memunculkan fenomena “failure déjà vu”

Sistem penggajian Phoenix di Kanada

• Sistem Phoenix senilai CA$310 juta yang mulai beroperasi pada 2016 gagal saat mencoba mengintegrasikan 80.000 aturan penggajian dan 105 perjanjian serikat pekerja
  • Demi penghematan anggaran, dilakukan langkah berlebihan seperti mengurangi pengujian dan prosedur pilot, serta menghapus fungsi inti
• Akibatnya, selama 9 tahun 70% dari 430.000 pegawai mengalami kesalahan penggajian
  • Per Maret 2025, 349.000 kasus kesalahan belum terselesaikan, dan lebih dari separuhnya tertunda lebih dari 1 tahun
  • Bahkan dilaporkan ada kasus bunuh diri pegawai
• Total biaya mencapai lebih dari CA$5,1 miliar, dan auditor menilainya sebagai “kegagalan yang tak dapat dipahami dalam manajemen dan pengawasan proyek”

Sistem Post Office Horizon di Inggris

• Sistem POS Horizon milik Fujitsu yang diperkenalkan pada 1999 menyembunyikan kesalahan internal dan membuat 3.500 kepala cabang dituntut atas tuduhan akuntansi palsu dan penipuan
  • 900 orang divonis bersalah, 236 dipenjara, dan lebih dari 13 orang bunuh diri
• Kegagalan teknis, manajerial, hukum, dan etis bekerja secara bersamaan
  • Middleware yang penuh bug, perluasan ruang lingkup yang tidak terkendali, kurangnya pengujian, dan kekurangan personel
  • Manajemen bersikap memusuhi pihak yang mengangkat masalah, menyembunyikan bukti, dan mencoba melakukan penutupan kasus secara terorganisasi
• Upaya penggantian pada 2016 dan 2021 juga gagal, dan Horizon masih digunakan hingga kini
  • Anggaran sistem baru £410 juta, keputusan dijadwalkan pada Juli 2026

Kasus kegagalan besar lainnya

• Minnesota MNLARS: dimulai pada 2016, dibatalkan pada 2019, biaya US$100 juta
• Australia Modernising Business Registers: anggaran AU$480 juta naik menjadi AU$2,8 miliar, dibatalkan pada 2022
• Sistem registrasi kendaraan Louisiana: gangguan berulang pada mainframe berusia 50 tahun memicu deklarasi keadaan darurat pada 2025
• Jaguar Land Rover: serangan siber pada 2025 menghentikan operasi global selama lebih dari sebulan, kerugian US$1,2–1,9 miliar
• Lidl ERP: setelah ERP berbasis SAP senilai €500 juta gagal, kembali ke sistem internalnya sendiri (2017)
• Boeing 737 Max: cacat desain MCAS menewaskan 346 orang, total biaya diperkirakan US$74 miliar
• F-35 Block 4 upgrade: jadwal molor 5 tahun, biaya naik dari US$10,5 miliar menjadi US$16,5 miliar

Biaya ekonomi dari kegagalan

• Di AS, biaya kegagalan perangkat lunak pada 2022 mencapai US$1,81 triliun, dengan kegagalan pengembangan sebesar US$260 miliar
  • Total ini lebih besar daripada anggaran pertahanan (US$778 miliar)
• Biaya pemeliharaan sistem legacy mencapai US$520 miliar per tahun, menyerap 70–75% anggaran TI
  • Biaya penggantian tinggi dan risiko kegagalan besar membuat penggantian terus tertunda
• Laporan NTT DATA 2024: 80% organisasi menjawab bahwa teknologi usang menghambat inovasi
  • Mayoritas eksekutif memahami bahwa infrastruktur legacy menghambat respons terhadap pasar

Batasan Agile·DevOps

• Meski metode pengembangan iteratif dan bertahap makin luas digunakan, tingkat kegagalan tetap tinggi
  • Beberapa laporan menyebut tingkat kegagalan proyek Agile 65%, dan DevOps hingga 90%
• Implementasi yang sukses memerlukan kepemimpinan, disiplin organisasi, pelatihan, dan perubahan budaya
  • Namun sebagian besar organisasi gagal mempertahankannya

Kesalahan manajemen yang terus berulang dan minimnya pembelajaran

• Manajer proyek TI sering mengabaikan pelajaran dari kegagalan masa lalu dengan alasan “proyek kami berbeda”
  • Pemerintah Kanada mengulangi pelajaran dari kegagalan sistem penggajian pertamanya pada 1995 dalam proyek Phoenix
• Sebagian besar kegagalan berasal dari kesalahan manajemen biasa, bukan percobaan inovatif
  • Ini lebih mendekati “penghancuran finansial” daripada “creative destruction”
• Contoh kegagalan sistem administrasi berbasis AI
  • Sistem tunjangan pengangguran MiDAS di AS dan Centrelink Robodebt di Australia menuntut ratusan ribu orang secara tidak adil akibat algoritme yang keliru
  • Pemerintah bersikap pasif dalam mengakui kesalahan dan memberi kompensasi

Perlunya tanggung jawab, etika, dan transparansi

• Pengambilan keputusan yang tidak transparan dalam sistem yang mengandung AI menimbulkan kekhawatiran pelanggaran hak warga
  • Uni Eropa secara hukum menjamin ‘hak atas penjelasan untuk keputusan algoritmik’
  • Muncul kebutuhan untuk menetapkan transparansi dan akuntabilitas sistem otomatis sebagai hak asasi di tingkat global
• Ada pembahasan tentang undang-undang tanggung jawab perangkat lunak dan sistem lisensi profesional, tetapi kemungkinan penerapannya rendah
• Alternatif yang realistis adalah memperkuat kejujuran eksekutif, pola pikir skeptis, dan penilaian etis
  • Risiko perlu dikenali dengan jelas, dan klaim berlebihan dari vendor harus diwaspadai
  • Ditekankan penerapan prinsip desain berpusat pada manusia pada semua sistem TI, termasuk AI

Kesimpulan: saatnya menghentikan pengulangan kesalahan

• Pengembangan perangkat lunak pada dasarnya kompleks dan rapuh, dan kesalahan kecil bisa berujung pada dampak besar
• Untuk proyek yang sukses, sumber daya yang memadai, kepemimpinan, dan akuntabilitas adalah syarat mutlak
• Perlu perhitungan biaya yang juga mempertimbangkan kerugian emosional dan ekonomi yang dialami pengguna
• Sejak “krisis perangkat lunak” pada 1968, kesalahan yang sama telah diulang selama lebih dari 50 tahun
  • “Buatlah kesalahan yang baru”

  “Setiap orang bisa berbuat salah, tetapi hanya orang bodoh yang bersikeras pada kesalahannya sendiri” - orator Romawi Cicero

[kgun9]

Kalau selama ini tidak kunjung diperbaiki, bukankah itu bukan masalah pada teknologi atau prinsip pengembangannya, melainkan masalah di sisi operasional yang menerimanya...

[s0400615]

Skandal Kantor Pos Inggris juga sudah diangkat menjadi drama.
Sampai sekarang para korbannya masih belum menerima kompensasi, jadi kasusnya masih terus berlangsung.

[t7vonn]

Contoh terbaru di dalam negeri yang terlintas adalah kasus kegagalan pembangunan sistem komputasi generasi berikutnya milik Gyeonggi Credit Guarantee Foundation.

https://v.daum.net/v/20251111165048155

[pcj9024]

Apakah negara lain juga menjalankan proyek SI berskala sangat besar seperti itu?

[GN⁺]

Komentar Hacker News

• Saya merasa solusi yang diajukan di bagian akhir tulisan kurang memuaskan.
  Menurut saya, solusi yang sebenarnya adalah memulai dari kecil lalu memvalidasikannya di lingkungan produksi nyata.
  Misalnya, jika ingin membangun sistem penggajian tingkat nasional, seharusnya diuji dulu di kota kecil dengan sekitar 50 orang, bug diperbaiki, lalu diperluas bertahap ke kota-kota yang lebih besar.
  Tidak ada proses pengembangan perangkat lunak yang langsung melompat ke skala nasional tanpa lebih dulu menyelesaikan masalah di skala kecil.

  • Saat mengerjakan proyek penggantian sistem POS di jaringan ritel besar, kami lebih dulu melakukan deployment awal hanya ke kantin internal dan toko pembuangan stok.
    Volume transaksinya rendah, jadi kalau ada masalah masih bisa disesuaikan secara manual, dan kami juga bisa menghindari aturan PCI.
    Berkat pengujian seperti ini sebelum deployment ke toko sungguhan, kami bisa memenuhi tenggat tanpa insiden besar.
    Kalau sejak awal kami deploy ke toko pelanggan, pasti akan terjadi kekacauan besar karena kesalahan perhitungan pajak atau masalah performa.
  • Pendekatan seperti ini cocok untuk produk (Product), tetapi punya keterbatasan untuk sistem (System).
    Ekspansi bertahap menumpuk utang teknis, dan pada akhirnya tak ada lagi yang benar-benar yakin pada inti codebase sehingga tim terjebak dalam ketakutan untuk rewrite.
    Bahkan untuk produk yang sederhana seperti WhatsApp, tetap dibutuhkan desain engineering yang sejak awal mempertimbangkan skalabilitas besar.
  • Intinya adalah keberadaan satu orang yang memahami keseluruhan sistem.
    Dalam sistem kecil yang sukses, orang seperti ini lebih mudah muncul, dan ia bisa memperoleh kepercayaan dari pengguna maupun developer sehingga sistem dapat tumbuh secara bertahap.
    Karena proyek besar memiliki peluang gagal yang tinggi, kita harus memulai dari kecil sesuai prinsip kehati-hatian (Precautionary Principle).
  • Pada akhirnya yang dibutuhkan adalah kesederhanaan — Plan → Implement → Test → Repeat.
    Siklus berulang ini adalah dasar dari proyek apa pun.
  • How Big Things Get Done juga menekankan prinsip yang sama.
    Mulailah dari kecil, lalu modularisasi dan skalakan. Contoh megafactory Tesla sangat mengesankan.

• Dari mempelajari sejarah teknologi, saya merasa industri hardware belajar dari keberhasilan dan kegagalan masa lalu, tetapi industri software tidak demikian.
  Kebanyakan developer tidak membongkar sistem lama untuk belajar, dan setiap generasi akhirnya mengulang masalah yang sama.

  • Saya bekerja di perusahaan tech besar, dan setiap proyek besar selalu berakhir dengan rush kacau di menit-menit terakhir.
    Dalam retrospektif, yang selalu ditanyakan hanyalah “apa yang harus dilakukan developer secara berbeda lain kali”, sementara manajer tidak pernah memikul tanggung jawab apa pun.
    Akhirnya masalah yang sama terulang, dan bebannya dilemparkan ke developer.
  • Semakin berganti generasi, developer makin hanya bekerja di atas tech stack generasi sebelumnya.
    Generasi terdahulu menyelesaikan masalah di lapisan bawah stack, tetapi sekarang orang mencoba menyelesaikannya hanya di lapisan atas.
    Akibatnya terbentuk menara abstraksi yang makin tinggi, sumber daya yang dibutuhkan makin besar, tetapi fungsinya kurang lebih sama.
    Kini kita bahkan memasuki era penambahan satu lapisan software lagi di atas model AI.
  • Dari pengalaman lama menangani sistem besar seperti ERP, masalah utamanya bukan alat, melainkan kurangnya project manager yang kompeten.
    Pengalaman dan kepribadian sama-sama penting, dan ego rendah serta pola pikir berfokus pada pemecahan masalah itu wajib.
    Kebanyakan orang meremehkan kompleksitas proyek.
  • Banyak developer tidak pernah belajar kemampuan membaca kode.
    Saat kuliah pascasarjana, saya menghabiskan seminggu membaca source code TinyOS untuk memahami strukturnya, dan pengalaman itu sangat membantu.
    Kemampuan memahami codebase yang asing dengan cepat sangatlah berguna.
  • Cepatnya pergantian teknologi mungkin merupakan fenomena yang disengaja.
    Jika bahasa atau framework baru terus muncul secara berkala, perusahaan bisa terus merekrut pegawai junior bergaji rendah.
    Saya rasa ini salah satu alasan software tidak diperlakukan seperti bidang engineering lainnya.

• Pada dasarnya ini bukan masalah pemrograman, melainkan masalah ketidakmampuan manajemen.
  Di sebagian besar proyek, kebutuhan bisnis tidak pernah didefinisikan dengan jelas, dan semuanya berjalan berbasis perkiraan semata.

• Kegagalan proyek IT publik skala besar bisa dipahami jika melihat struktur kontrak dan insentifnya.
  Masalahnya adalah ketergantungan pada konsultan berbasis penagihan waktu alih-alih kemampuan nyata.
  Proyek yang berhasil lebih ditentukan oleh keselarasan antarorganisasi (alignment) dan kompetensi (competence) daripada teknologinya.

  • Pada akhirnya ini adalah masalah manusia dan politik, bukan software itu sendiri.
  • Kalau ada literatur atau studi kasus yang layak dijadikan rujukan, saya ingin mendapat rekomendasinya.

• Saya pikir diskriminasi usia di Silicon Valley adalah masalah nyata.
  Pengalaman diabaikan, dan pelajaran masa lalu sama sekali tidak tercermin.
  Industri hardware mengejar inovasi sambil tetap menghormati warisan pengetahuan.

  • Namun ada juga yang berpendapat bahwa “membuang pengalaman adalah bagian dari evolusi”.
    Ada sudut pandang bahwa orang yang belajar dari kegagalan masa lalu justru jadi tak mampu mencoba hal baru.

• Pada akhirnya proyek software gagal karena kegagalan manusia.
  Yang lebih penting daripada proses atau alat yang sempurna adalah orang-orang yang punya motivasi dan rasa tanggung jawab.
  Harus ada konsekuensi (Consequences) secara hukum agar orang bekerja dengan benar.
  Seperti proyek konstruksi fisik, setiap tahap perlu verifikasi independen dan penetapan tanggung jawab.

  • Tetapi kalau tanggung jawabnya terlalu besar, tak ada yang mau mengambil risiko.
    Karena itu, secara realistis kita memang harus berjalan sambil menerima tingkat risiko tertentu.
  • Berdasarkan 35 tahun pengalaman saya, penyebab kegagalan hampir selalu adalah manusia dan budaya.
    Proyek yang berhasil biasanya ditopang oleh segelintir orang dengan kecerdasan emosional dan kepemimpinan.
    Pada akhirnya software engineering adalah masalah manusia.
  • Kalau benar seorang engineer, ia seharusnya mempelajari kasus-kasus kegagalan engineering.
    Namun industri ini masih terjebak dalam penghindaran tanggung jawab dan mengejar tren.

• Masalah seperti ini bukan hanya terjadi di software.
  Proyek sipil besar seperti Auburn Dam, Columbia River Crossing, dan Big Dig juga terkenal karena pembengkakan anggaran.

  • Tetapi “97% melebihi anggaran” belum tentu berarti gagal.
    Jika anggaran awalnya tidak realistis, maka itu mungkin hanya biaya yang akhirnya menyesuaikan dengan kenyataan.
    Karena itu, pendekatan memulai dari proyek kecil lalu memperluasnya secara bertahap menjadi penting.

• Saya bukan developer maupun PM, tetapi saya penasaran dengan contoh keberhasilan berskala besar.
  Karena saya bekerja di rumah sakit, akan lebih bagus jika ada contoh sukses di bidang healthcare.
  Saya sudah membaca The Phoenix Project dan sedikit memahami pola pikir Agile dan DevOps, tetapi sulit menerapkannya dalam pekerjaan nyata.
  Saya ingin menanam benih keberhasilan dari proyek kecil.

  • Contoh keberhasilan yang paling representatif adalah Unix dan Linux.
    Itu bermula dari refleksi atas kompleksitas Multics, lalu Ken Thompson menulis Unix sendiri hanya dalam 3 minggu.
    Lihat tulisan terkait.
  • Penting untuk mendefinisikan apa itu keberhasilan — bukan sekadar tepat jadwal, melainkan nilai berkelanjutan setelah sistem beroperasi yang merupakan keberhasilan sejati.
    Conway’s Law, risiko personel kunci, kepemilikan yang jelas, dan budaya pengujian juga sangat penting.
    Di atas semuanya, dibutuhkan keberanian untuk mengatakan “tidak”.
  • Google Search dan Facebook juga merupakan kisah sukses, tetapi tidak dimulai secara raksasa sejak hari pertama seperti proyek pemerintah.
    Ada juga kasus seperti healthcare.gov yang membaik setelah lebih dulu gagal.
  • UPI di India adalah contoh keberhasilan skala besar yang nyaris sempurna.
  • Proyek Direct File di AS juga mendapat penilaian positif dari 94% penggunanya.

• Sebelum menyalahkan komunitas IT, kita perlu melihat budaya perusahaan yang berfokus pada keuntungan jangka pendek.
  Keamanan dan stabilitas selalu menjadi prioritas pertama untuk dipotong anggarannya.
  Para eksekutif bisa gagal lalu pergi dengan golden parachute, sementara tanggung jawab ditinggalkan pada developer.
  Pemerintah pun tidak menghukum insiden keamanan akibat kelalaian perusahaan dengan semestinya.
  Akhirnya realitas sinis seperti “selesaikan saja dengan AI, konsultan, atau outsourcing” terus berulang.

• Menggelontorkan triliunan won ke AI tidak akan memperbaiki keadaan, malah akan memperburuknya.

  • Jika gelembung AI pecah, akan menyusul krisis ekonomi dan kekacauan politik.
    Masyarakat Barat sudah tidak stabil dan sedang condong ke kanan ekstrem.
    Krisis berikutnya mungkin bukan sekadar keruntuhan finansial, tetapi bisa berujung pada keruntuhan sosial.
    Umat manusia seharusnya bergerak menuju kemajuan melalui pemahaman, bukan melalui krisis.
  • Tetapi AI pada dasarnya adalah penguat.
    Jika prosesnya bagus, hasilnya ikut terdorong; jika prosesnya buruk, AI akan mempercepat masalahnya.
    Pada akhirnya arahnya tetap sama, hanya kecepatannya yang bertambah.