Konten disusun AI — bisa keliru. Baca disclaimer lengkap
TSB Bank (Migrasi IT 2018)
Ringkasan
Apa yang Terjadi
TSB Bank adalah bank ritel Inggris hasil pemisahan (carve-out) dari Lloyds Banking Group — dipaksa oleh Komisi Eropa sebagai konsekuensi dana talangan negara ke Lloyds pasca krisis 2008 (proyek 'Verde') — yang diluncurkan kembali sebagai bank berdiri sendiri pada 2013 dan diakuisisi bank Spanyol Banco Sabadell senilai ~£1,7 miliar pada 2015.
Masalahnya bukan bisnis, melainkan teknologi. Setelah akuisisi, TSB masih menyewa platform IT warisan dari Lloyds dengan biaya ~£100 juta/tahun yang dijadwalkan naik. Untuk lepas dari ketergantungan itu, Sabadell membangun platform core banking baru — Proteo4UK (versi kustomisasi platform 'Proteo' milik Sabadell, dikerjakan anak usaha IT-nya, Sabis) — dan pada akhir pekan 20–22 April 2018 memigrasikan ~1,3 miliar rekaman data untuk 5,2 juta nasabah dalam satu kali pemindahan besar ('big bang').
Migrasi datanya 'berhasil', tetapi platformnya langsung tumbang. Regulator FCA mencatat ~1,9 juta nasabah terkunci dari layanan online/mobile, seluruh cabang terdampak, sebagian nasabah bahkan melihat rekening & transaksi nasabah lain, dan pembayaran kacau selama berpekan-pekan — pemulihan penuh baru tercapai Desember 2018. Penipu memanfaatkan kekacauan: serangan phishing bertema TSB melonjak 843% di Mei 2018. Total biaya pasca-migrasi mencapai £330,2 juta, TSB rugi sebelum pajak £105,4 juta di 2018 (dari untung £162,7 juta di 2017), dan ~80.000 nasabah pindah bank.
CEO Paul Pester — yang dikritik keras karena komunikasi publik yang terlalu optimistis — mundur pada September 2018. Pada Desember 2022, FCA dan PRA menjatuhkan denda gabungan £48,65 juta atas kegagalan tata kelola risiko operasional dan pengelolaan risiko outsourcing. Kasus TSB menjadi salah satu studi kasus paling dikutip di dunia tentang bahaya migrasi core banking yang dipaksakan tanpa pengujian memadai.
Catatan: ini adalah postmortem sebuah insiden operasional/IT yang sudah berujung putusan regulator, bukan tuduhan pidana; TSB kemudian pulih dan kembali untung di bawah CEO baru Debbie Crosbie.
Kronologi
Urutan Kejadian
TSB diluncurkan kembali sebagai bank mandiri (proyek 'Verde')
Lloyds Banking Group memisahkan ~631 cabang menjadi TSB Bank plc, memenuhi keputusan Komisi Eropa yang mensyaratkan divestasi sebagai konsekuensi bantuan negara ke Lloyds pasca krisis 2008. TSB tetap bergantung pada platform IT warisan Lloyds — akar masalah yang beberapa tahun kemudian mendorong migrasi bermasalah.
Banco Sabadell menuntaskan akuisisi TSB (~£1,7 miliar)
Bank Spanyol Banco Sabadell menuntaskan pengambilalihan TSB senilai ~£1,7 miliar (disepakati Maret, rampung 8 Juli 2015), memungkinkan Lloyds keluar penuh sesuai tenggat Komisi Eropa. Sabadell berencana memindahkan TSB dari platform sewaan Lloyds ke platform buatannya sendiri untuk memangkas biaya IT ~£100 juta/tahun.
Go-live 'big bang' Proteo4UK: 1,3 miliar rekaman, 5,2 juta nasabah
Pada akhir pekan 20–22 April 2018, TSB memigrasikan lebih dari 1,3 miliar rekaman data untuk ~5,2 juta nasabah dari sistem Lloyds ke platform core banking baru Proteo4UK (dibangun/dijalankan Sabis, anak usaha IT Sabadell) dalam satu kali pemindahan besar, go-live malam Minggu 22 April 2018.
Platform tumbang: ~1,9 juta nasabah terkunci, sebagian lihat rekening orang lain
Meski data berpindah, platform langsung mengalami kegagalan teknis. FCA mencatat sekitar 1,9 juta dari 5,2 juta nasabah terkunci dari layanan online/mobile; seluruh cabang terdampak; layanan cabang, telepon, online, mobile, pembayaran, dan kartu debit kacau. Sebagian nasabah bahkan melihat saldo dan transaksi milik nasabah lain. Gangguan baru pulih penuh ('business-as-usual') pada Desember 2018.
Penipuan memanfaatkan kekacauan: serangan puncak ~70x, phishing +843%
Penipu mengeksploitasi gangguan: menurut liputan atas laporan Slaughter and May, upaya penipuan sempat mencapai ~70x level normal, dan serangan phishing bertema TSB melonjak 843% di Mei 2018 dibanding April — menjadikan TSB salah satu merek bank Inggris paling banyak disalahgunakan penipu bulan itu. Kerugian fraud yang diatribusikan ke insiden ~£49,1 juta.
FCA umumkan investigasi; Pester dikritik keras di Komite Perbendaharaan
FCA mengumumkan penyelidikan atas migrasi TSB. Di depan Treasury Select Committee, CEO Paul Pester dikritik karena menyampaikan pandangan terlalu optimistis. FCA menilai TSB 'tidak terbuka dan transparan', dan Ketua Komite Nicky Morgan MP menyebutnya contoh mengejutkan seorang chief executive yang enggan menyadari skala masalah.
Temuan awal IBM dipublikasikan Komite: pengujian tak memadai
Treasury Committee mempublikasikan pemaparan IBM (yang direkrut TSB untuk membantu diagnosis). IBM menyatakan belum melihat bukti penerapan kriteria go-live yang ketat untuk membuktikan kesiapan produksi, serta menyoroti risiko dari arsitektur active-active dua pusat data dan pengujian performa yang tak cukup. TSB menyanggah bahwa pemaparan itu 'hipotesis sangat awal' yang dibuat hanya setelah beberapa hari keterlibatan.
CEO Paul Pester mundur
Paul Pester mundur dari jabatan CEO TSB di tengah gangguan yang belum sepenuhnya beres, dilaporkan membawa paket ~£1,7 juta. Ketua non-eksekutif Richard Meddings menjadi executive chairman sementara. Ketua Komite Perbendaharaan menyatakan Komite 'kehilangan kepercayaan' atas posisi Pester sebagai chief executive.
Kerugian 2018: biaya pasca-migrasi £330,2 juta, rugi £105,4 juta
Dalam laporan tahunan 2018, TSB membukukan biaya pasca-migrasi total £330,2 juta (£125,2 juta ganti rugi/remediasi + £122,4 juta sumber daya & advisory tambahan + £33,5 juta pendapatan yang direlakan), sebagian diimbangi pemulihan provisional ~£153 juta dari Sabis. Hasilnya rugi sebelum pajak statutori £105,4 juta (dibanding untung £162,7 juta di 2017); ~80.000 nasabah pindah bank.
Laporan independen Slaughter and May: platform 'tak stabil dan tak lengkap'
Kajian independen yang dipesan dewan TSB (dikerjakan firma hukum Slaughter and May) menyimpulkan TSB go-live dengan platform yang 'tidak stabil maupun lengkap'; Proteo4UK 'belum siap menopang seluruh basis nasabah TSB dan Sabis belum siap mengoperasikannya'. Kajian mengkritik pendekatan 'big bang', pengujian yang cacat, dan lemahnya uji tuntas atas kapabilitas Sabis.
FCA & PRA denda TSB £48,65 juta
FCA dan PRA menjatuhkan denda gabungan £48.650.000 (FCA £29,75 juta + PRA £18,9 juta, setelah diskon penyelesaian 30% dari ~£69,5 juta) atas kegagalan tata kelola dan pengelolaan risiko operasional — termasuk pengelolaan risiko outsourcing ke pemasok kritis Sabis — terkait migrasi IT. Regulator menyatakan TSB 'gagal mengorganisasi dan mengendalikan program migrasi IT secara memadai'. PRA juga menjatuhkan denda terpisah kepada mantan CIO TSB pada April 2023.
Aktor & Insentif
Siapa yang Terlibat
Banco Sabadell (perusahaan induk)
Peran dalam Kasus
Pemilik yang mendorong dan menetapkan strategi migrasi ke platform Proteo4UK. Keputusan strategis (bangun sendiri via Sabis, big-bang) berasal dari level grup.
Insentif
Ingin memangkas biaya sewa platform IT ke Lloyds (~£100 juta/tahun, dijadwalkan naik) dengan memindahkan TSB ke platform buatannya sendiri; sekaligus membuktikan kapabilitas teknologi grup di pasar Inggris.
Sabis (anak usaha IT Sabadell)
Peran dalam Kasus
Membangun dan menjalankan Proteo4UK. Kajian independen menyoroti Sabis merekomendasikan menguji hanya satu dari dua pusat data, dan bahwa Sabis 'belum siap mengoperasikan platform' saat go-live.
Insentif
Sebagai penyedia teknologi internal grup, terinsentif menyatakan kesiapan platform dan menyelesaikan proyek sesuai tenggat komersial Sabadell.
Paul Pester (CEO TSB)
Peran dalam Kasus
Pemimpin eksekutif TSB selama migrasi. Dikritik regulator dan parlemen karena komunikasi publik yang dinilai terlalu optimistis dan menyesatkan; mundur September 2018.
Insentif
Terinsentif menjaga kepercayaan pasar/nasabah dan menuntaskan migrasi yang menjadi tonggak strategis; tekanan reputasi untuk menampilkan proyek sebagai sukses.
Dewan Direksi TSB (termasuk chairman Richard Meddings)
Peran dalam Kasus
Menyetujui go-live. Regulator menemukan dewan gagal mengorganisasi & mengendalikan program dan mengelola risiko outsourcing secara memadai; kemudian memesan kajian independen dan mengganti kepemimpinan.
Insentif
Bertanggung jawab atas tata kelola risiko namun sangat bergantung pada asuransi/kepastian yang diberikan Sabis dan manajemen soal kesiapan platform.
IBM (konsultan pasca-insiden)
Peran dalam Kasus
Memberi pemaparan awal ke Treasury Committee yang menyoroti kurangnya bukti pengujian pada skala memadai dan risiko arsitektur active-active — dokumen yang menjadi rujukan publik penting.
Insentif
Direkrut untuk membantu menstabilkan sistem dan mendiagnosis akar masalah; terinsentif menilai secara teknis-independen.
FCA & PRA (regulator)
Peran dalam Kasus
Menyelidiki insiden dan pada Desember 2022 menjatuhkan denda gabungan £48,65 juta atas kegagalan resiliensi operasional dan pengelolaan risiko outsourcing.
Insentif
Menjaga resiliensi operasional dan perlindungan nasabah sektor keuangan Inggris; menegakkan standar tata kelola risiko IT & outsourcing.
Treasury Select Committee (parlemen Inggris)
Peran dalam Kasus
Menggelar dengar pendapat, mempublikasikan bukti tertulis (termasuk pemaparan IBM), dan menyatakan hilang kepercayaan pada kepemimpinan Pester.
Insentif
Pengawasan legislatif atas sektor keuangan dan perlindungan konsumen.
Insight untuk Founder
Pelajaran dari Kasus Ini
Migrasi 'big bang' menumpuk seluruh risiko pada satu titik waktu
Apa yang Terjadi
TSB memindahkan 1,3 miliar rekaman untuk 5,2 juta nasabah sekaligus dalam satu akhir pekan, langsung ke seluruh basis nasabah, bukan bertahap.
Polanya
Pemindahan besar sekaligus terasa 'sekali selesai' dan hemat biaya paralel-run, tetapi menghapus semua peluang belajar dari volume kecil dan tidak menyisakan jalur mundur yang realistis saat platform tak stabil.
Tanda Bahaya Dini
- Tidak ada tahap ramp-up (ambil nasabah bertahap) untuk mengamati risiko operasional.
- Rencana roll-back yang tak teruji pada skala penuh.
- Tenggat komersial (lepas dari biaya IT Lloyds) mendikte jadwal go-live, bukan kesiapan teknis.
Aksi Pencegahan
Migrasi core banking berskala besar sebaiknya bertahap/canary (pindahkan segmen kecil dulu, amati, baru perluas), dengan gerbang go/no-go berbasis metrik nyata dan jalur mundur yang benar-benar dilatih. 'Big bang' hanya untuk sistem yang risikonya benar-benar terkendali.
Kesiapan diklaim, bukan dibuktikan — pengujian jadi tumbal tenggat
Apa yang Terjadi
Platform go-live meski, menurut kajian independen, 'tidak stabil maupun lengkap'; IBM menyatakan tak melihat bukti kriteria go-live yang ketat untuk membuktikan kesiapan produksi.
Polanya
Saat tenggat komersial menekan, 'kesiapan' bergeser dari sesuatu yang diukur (uji beban, uji non-fungsional, kriteria go/no-go) menjadi sesuatu yang diasumsikan berdasarkan kepastian dari vendor/manajemen.
Tanda Bahaya Dini
- Uji performa/kapasitas tak membuktikan sistem sanggup menahan beban produksi penuh.
- Backlog defect yang masih tinggi mendekati go-live (jumlah pastinya bahkan menjadi sengketa antara kajian dan TSB).
- Tidak ada kriteria go-live objektif yang bisa memveto peluncuran.
Aksi Pencegahan
Tetapkan kriteria go/no-go yang objektif, terukur, dan mengikat SEBELUM proyek dimulai — mencakup uji beban pada skala produksi dan ambang defect. Beri wewenang veto pada fungsi yang independen dari tekanan tenggat.
Ketergantungan penuh pada vendor internal tanpa uji tuntas kapabilitas
Apa yang Terjadi
TSB menyerahkan pembangunan & operasi platform ke Sabis (anak usaha induknya) tanpa, menurut kajian, menilai secara memadai kapabilitas Sabis untuk proyek berskala & kompleksitas regulasi yang belum pernah ia kerjakan.
Polanya
Karena vendor adalah 'keluarga sendiri' (anak usaha induk), uji tuntas dan tata kelola pihak ketiga jadi longgar — padahal justru relasi intra-grup rawan konflik kepentingan dan asuransi kesiapan yang tidak diverifikasi independen.
Tanda Bahaya Dini
- Pemasok kritis tunggal tanpa alternatif atau kemampuan verifikasi independen.
- Dewan menerima kepastian kesiapan dari pihak yang punya insentif menyatakan siap.
- Konsentrasi pengetahuan (bus factor) di satu vendor grup.
Aksi Pencegahan
Perlakukan vendor intra-grup dengan disiplin uji tuntas & tata kelola outsourcing yang SAMA ketatnya dengan pihak ketiga eksternal: verifikasi kapabilitas secara independen, uji asuransi kesiapan, dan siapkan kontrol risiko outsourcing yang nyata (regulator mendenda tepat pada titik ini).
Komunikasi krisis yang terlalu optimistis memperparah kerusakan reputasi
Apa yang Terjadi
CEO menyampaikan pesan bahwa sistem sudah pulih ketika nasabah masih terkunci; regulator menilai TSB 'tidak terbuka dan transparan' dan parlemen menyebut komunikasi 'menyesatkan'.
Polanya
Dalam krisis teknis, dorongan untuk menenangkan pasar membuat pimpinan menyatakan 'sudah beres' sebelum data lapangan mendukung — yang justru meruntuhkan kredibilitas saat realitas terbongkar.
Tanda Bahaya Dini
- Klaim status ('up and running') tidak sinkron dengan pengalaman nasabah nyata.
- Pesan optimistis mendahului verifikasi metrik pemulihan.
- Pimpinan enggan mengakui skala masalah di hadapan pengawas.
Aksi Pencegahan
Komunikasi krisis harus berbasis fakta terverifikasi, kalibrasikan pesan dengan telemetri nyata (tingkat login sukses, transaksi berhasil), dan akui skala masalah lebih awal. Kredibilitas jauh lebih murah dijaga daripada dipulihkan.
Kegagalan bisa dibalikkan — tata kelola & kepemimpinan baru memulihkan
Apa yang Terjadi
Setelah pergantian kepemimpinan (Debbie Crosbie sebagai CEO baru dari 2019), stabilisasi sistem, dan remediasi nasabah, TSB kembali membukukan laba pada 2019.
Polanya
Bencana IT bukan vonis mati bagi sebuah bank; pemulihan datang dari mengakui akar masalah secara jujur (kajian independen), memperbaiki tata kelola, menstabilkan teknologi, dan mengganti insentif kepemimpinan.
Tanda Bahaya Dini
- Menutupi akar masalah alih-alih memesan kajian independen yang jujur.
- Mempertahankan pola insentif/kepemimpinan yang sama pasca-krisis.
- Menunda ganti rugi nasabah (yang justru dikritik regulator).
Aksi Pencegahan
Pasca-krisis, lakukan postmortem blameless yang jujur dan dipublikasikan, perbaiki tata kelola risiko & outsourcing, prioritaskan pemulihan kepercayaan nasabah (ganti rugi cepat), dan pastikan kepemimpinan baru punya mandat teknis yang kredibel.
Bedah Teknikal
Kacamata CTO
Bedah teknikal ini menyorot lapisan yang menjadi pusat bencana TSB 2018: migrasi core banking. Setelah diakuisisi Banco Sabadell (2015), TSB masih menumpang platform IT warisan Lloyds. Untuk lepas dari biaya sewa itu, Sabadell membangun Proteo4UK — versi kustomisasi Inggris dari platform 'Proteo' milik Sabadell — melalui anak usaha IT-nya, Sabis. Proyek ini bukan sekadar pindah data: ia sekaligus mengangkat arsitektur dari Proteo3 ke Proteo4 dan mengkustomisasinya untuk kebutuhan regulasi & produk Inggris.
Pada akhir pekan 20–22 April 2018, ~1,3 miliar rekaman untuk 5,2 juta nasabah dipindahkan sekaligus ('big bang') dan platform baru go-live malam Minggu. Data berpindah, tetapi platform langsung tumbang. Akar teknisnya berpusat pada arsitektur active-active dua pusat data yang, menurut kajian, dikonfigurasi secara tidak konsisten padahal seharusnya identik — memicu masalah pada global load balancing antar-DC — ditambah pengujian yang tak membuktikan kapasitas dan keputusan menguji hanya satu dari dua pusat data.
Catatan: analisis teknis ini disusun dengan bantuan AI dari sumber publik (kajian Slaughter and May via rilis dewan TSB, bukti IBM ke Treasury Committee, Final Notice FCA, dan liputan pers teknis). Karena kebijakan egress sesi ini memblokir fetch langsung, kutipan dirujuk dari ringkasan pencarian atas halaman-halaman itu dan bisa keliru. Analisis bersifat blameless — fokus pada sistem & proses, bukan menyalahkan engineer individu.
Akar Masalah Teknis
Inkonsistensi konfigurasi antar pusat data active-active
Apa yang terjadi
Dua pusat data yang dispesifikasikan identik ternyata berbeda konfigurasi di sejumlah area, memicu masalah global load balancing saat trafik produksi dibagi antar-DC. Ini disebut kajian sebagai penyebab utama luasnya gangguan.
Polanya
Arsitektur high-availability (active-active) hanya seaman jaminan config parity-nya. Tanpa verifikasi otomatis kesetaraan konfigurasi & uji failover pada beban penuh, redundansi berubah menjadi penggandaan titik gagal.
Tanda bahaya dini
- Tidak ada mekanisme yang membuktikan dua DC benar-benar identik (drift terdeteksi late).
- Failover/GLB tak pernah diuji pada beban produksi penuh.
- Asumsi 'seharusnya identik' menggantikan bukti 'terverifikasi identik'.
Pencegahan
Perlakukan config parity sebagai invariant yang diverifikasi otomatis (infrastructure-as-code + drift detection), dan uji failover active-active pada beban setara produksi SEBELUM go-live. Jangan pernah go-live active-active jika satu sisi belum terbukti.
Pengujian tak membuktikan kesiapan; tak ada kriteria go-live yang ketat
Apa yang terjadi
IBM menyatakan belum melihat bukti penerapan kriteria go-live yang ketat untuk membuktikan kesiapan produksi; kajian menyebut pengujian 'cacat' dan tak cukup memitigasi risiko memindahkan ~5 juta nasabah ke perangkat lunak yang sebagian besar baru.
Polanya
Di bawah tenggat komersial, 'kesiapan' bergeser dari yang diukur (uji beban, kriteria go/no-go objektif) menjadi yang diasumsikan. Gerbang peluncuran tak punya wewenang memveto.
Tanda bahaya dini
- Tidak ada exit criteria terukur yang mengikat sebelum go-live.
- Backlog defect masih tinggi mendekati peluncuran (jumlahnya bahkan jadi sengketa).
- Uji non-fungsional (beban/kapasitas) tak menghasilkan bukti kuantitatif.
Pencegahan
Definisikan kriteria go/no-go objektif & mengikat sejak awal (ambang defect, hasil uji beban skala produksi, uji DR), dengan wewenang veto pada fungsi independen dari tekanan jadwal.
Kapasitas & performa tak terbukti pada beban penuh
Apa yang terjadi
IBM menyatakan pengujian performa tidak memberi bukti kapasitas yang dibutuhkan; platform tak sanggup menahan beban produksi penuh saat seluruh 5,2 juta nasabah masuk sekaligus.
Polanya
Menguji pada lingkungan/volume yang tak merepresentasikan produksi membuat batas kapasitas tak terlihat sampai beban nyata menghantam — diperparah oleh pilihan big-bang yang mengirim beban penuh di menit pertama.
Tanda bahaya dini
- Uji beban tidak mencerminkan skala & pola trafik produksi nyata.
- Tidak ada headroom kapasitas yang terukur.
- Beban penuh dikirim sekaligus tanpa ramp bertahap untuk mengamati titik jenuh.
Pencegahan
Uji beban pada skala & profil trafik produksi (termasuk puncak), sisakan headroom kapasitas yang jelas, dan (bila mungkin) naikkan beban bertahap agar titik jenuh terlihat sebelum berdampak ke jutaan nasabah.
Konsentrasi pemasok tunggal & lemahnya tata kelola outsourcing
Apa yang terjadi
Pembangunan & operasi platform terkonsentrasi pada Sabis (anak usaha induk) tanpa uji tuntas kapabilitas memadai; regulator mendenda TSB karena gagal mengelola risiko operasional dari pengaturan outsourcing ke pemasok kritis ini.
Polanya
Vendor intra-grup terasa 'aman' sehingga disiplin tata kelola pihak ketiga dilonggarkan — padahal konsentrasi kapabilitas & pengetahuan di satu vendor (bus factor) plus konflik insentif justru menaikkan risiko sistemik.
Tanda bahaya dini
- Satu pemasok kritis tanpa alternatif atau verifikasi independen.
- Asuransi kesiapan berasal dari pihak yang berinsentif menyatakan siap.
- Dewan tak punya kontrol risiko outsourcing yang nyata & teruji.
Pencegahan
Terapkan tata kelola outsourcing yang sama ketatnya untuk vendor intra-grup: uji tuntas kapabilitas independen, klausul & kontrol risiko pihak ketiga, rencana kontinjensi bila vendor gagal, dan verifikasi kesiapan oleh pihak yang tak berkonflik kepentingan.
Tata kelola program & komunikasi status yang tak berbasis telemetri
Apa yang terjadi
Dewan menyetujui go-live berbekal asuransi kesiapan dari Sabis/manajemen; pimpinan menyampaikan sistem sudah pulih ketika jutaan nasabah masih terkunci, dan regulator menilai TSB 'tidak terbuka dan transparan'.
Polanya
Ketika keputusan go/no-go dan pesan status dipandu oleh keyakinan pimpinan/vendor alih-alih metrik operasional nyata (tingkat login sukses, transaksi berhasil), organisasi kehilangan kemampuan mengoreksi diri di saat paling kritis.
Tanda bahaya dini
- Klaim status manajemen tak sinkron dengan telemetri & pengalaman nasabah.
- Keputusan go-live berbasis asuransi verbal, bukan dashboard bukti.
- Eskalasi bad-news terhambat karena tekanan menampilkan sukses.
Pencegahan
Ikat keputusan go/no-go dan komunikasi status pada metrik operasional real-time yang disepakati; bangun budaya di mana bad news mengalir cepat ke dewan; dan pisahkan fungsi yang melaporkan kesiapan dari fungsi yang berinsentif menyatakan siap.
Keputusan Teknis & Trade-off
Cutover 'big bang' seluruh 5,2 juta nasabah dalam satu akhir pekan
Konteks
Alih-alih memindahkan nasabah bertahap, TSB memindahkan seluruh basis nasabah & 1,3 miliar rekaman sekaligus, dengan legacy dimatikan sepanjang akhir pekan.
Trade-off
Big-bang menghindari biaya & kompleksitas menjalankan dua sistem paralel serta 'menyelesaikan' migrasi sekali jalan — tetapi menumpuk seluruh risiko pada satu titik waktu, tanpa peluang belajar dari volume kecil dan tanpa jalur mundur yang realistis.
Hasil
Saat platform tak stabil, tidak ada segmen kecil untuk membatasi ledakan (blast radius); kegagalan langsung mengenai jutaan nasabah sekaligus. IBM menilai proyek sebesar ini semestinya pakai incremental customer take-on, bukan big-bang.
Arsitektur active-active dua pusat data yang seharusnya identik
Konteks
Proteo4UK dirancang berjalan aktif di dua pusat data untuk resiliensi, dengan global load balancing membagi beban di antara keduanya.
Trade-off
Active-active memberi ketersediaan tinggi bila dua sisi benar-benar identik & teruji — tetapi menuntut disiplin konfigurasi (config parity) dan pengujian failover yang ketat; setiap perbedaan kecil antar-DC menjadi bom waktu.
Hasil
Kedua pusat data ternyata dikonfigurasi tidak konsisten di sejumlah area; masalah GLB antar-DC muncul di produksi. Alih-alih menambah resiliensi, active-active yang tak dikelola justru menggandakan permukaan kegagalan.
Menguji hanya SATU dari dua pusat data (rekomendasi Sabis)
Konteks
Sabis merekomendasikan pengujian dijalankan hanya pada satu pusat data untuk menghindari gangguan layanan ATM bagi nasabah selama fase uji.
Trade-off
Menguji satu DC menghemat waktu & menghindari gangguan uji, tetapi mengorbankan bukti bahwa konfigurasi kedua DC benar-benar identik dan bahwa failover/GLB bekerja pada beban penuh.
Hasil
Kegagalan menguji pusat data kedua membuat mustahil mengidentifikasi masalah yang kemudian menyebabkan downtime — persis titik lemah yang meledak di produksi.
Membangun platform kustom via vendor internal (Sabis) tanpa uji tuntas kapabilitas memadai
Konteks
Sabadell menugaskan anak usaha IT-nya, Sabis, membangun & mengoperasikan Proteo4UK — proyek berskala & kompleksitas regulasi UK yang belum pernah dikerjakan Sabis sebelumnya.
Trade-off
Memakai vendor intra-grup memberi kontrol & keselarasan biaya, tetapi menciptakan konsentrasi pemasok tunggal (bus factor/vendor lock-in) dan melonggarkan uji tuntas karena 'keluarga sendiri'.
Hasil
Kajian menemukan TSB tak menilai kapabilitas Sabis secara memadai; dewan bergantung pada asuransi kesiapan dari pihak yang berinsentif menyatakan siap. Regulator kelak mendenda tepat pada kegagalan pengelolaan risiko outsourcing ini.
Insight untuk CTO
Migrasi core banking berskala besar menuntut go-live bertahap (canary/incremental take-on) dengan gerbang go/no-go objektif dan jalur mundur teruji. 'Big bang' menumpuk seluruh risiko pada satu menit pertama produksi.
🚩 Peringatan dini
Jadwal go-live didikte tenggat komersial (mis. lepas dari biaya sewa IT) alih-alih kesiapan; tak ada rencana memindahkan nasabah bertahap; roll-back tak pernah dilatih pada skala penuh.
🛡️ Pencegahan
Rancang migrasi sebagai deret canary bertahap dengan ambang metrik untuk lanjut/berhenti; latih roll-back sungguhan; dan beri wewenang veto go-live pada fungsi independen dari tekanan jadwal.
Active-active dua pusat data hanya menambah resiliensi bila config parity diverifikasi otomatis dan failover diuji pada beban penuh. Tanpa itu, redundansi menggandakan permukaan kegagalan.
🚩 Peringatan dini
Klaim 'dua DC identik' tanpa bukti otomatis; failover/GLB belum pernah diuji pada beban produksi; keputusan menguji hanya satu DC demi kenyamanan operasional.
🛡️ Pencegahan
Kelola infrastruktur sebagai kode dengan drift detection, jadikan config parity invariant yang diuji, dan jalankan game-day failover pada beban setara produksi sebelum go-live.
Kesiapan kapasitas harus dibuktikan dengan uji beban pada skala & profil trafik produksi — bukan diasumsikan. Angka kapasitas tanpa bukti kuantitatif adalah harapan, bukan rekayasa.
🚩 Peringatan dini
Uji performa memakai lingkungan/volume yang tak representatif; tak ada laporan headroom kapasitas; beban penuh direncanakan masuk sekaligus.
🛡️ Pencegahan
Uji beban puncak pada replika produksi, dokumentasikan headroom, dan bila memungkinkan naikkan beban bertahap agar titik jenuh terlihat lebih dulu.
Vendor intra-grup bukan pengecualian tata kelola. Konsentrasi pemasok tunggal untuk sistem kritis menuntut uji tuntas, kontrol risiko, dan rencana kontinjensi yang sama ketatnya dengan pihak ketiga eksternal.
🚩 Peringatan dini
Satu vendor mengerjakan proyek di luar rekam jejaknya; kesiapan diverifikasi oleh pihak yang berinsentif; tak ada rencana bila vendor gagal.
🛡️ Pencegahan
Uji tuntas kapabilitas vendor secara independen, tetapkan kontrol & klausul risiko outsourcing, dan siapkan kontinjensi (termasuk kemampuan verifikasi/operasi independen) untuk sistem kritis.
Keputusan go/no-go dan komunikasi krisis harus terikat pada telemetri operasional nyata, bukan keyakinan pimpinan atau asuransi vendor. Kredibilitas hancur saat 'sudah pulih' berbenturan dengan realitas nasabah.
🚩 Peringatan dini
Dashboard kesehatan tak menjadi basis keputusan; bad news tersendat naik ke dewan; pesan status mendahului bukti pemulihan.
🛡️ Pencegahan
Sepakati metrik go/no-go & status yang objektif dan real-time, dorong aliran bad-news cepat, dan pisahkan pelaporan kesiapan dari insentif menyatakan siap.
Verdict CTO
TSB 2018 adalah kegagalan eksekusi & tata kelola teknis, bukan kegagalan algoritma. Empat keputusan yang saling memperkuat — cutover big-bang, arsitektur active-active dua pusat data yang tak terverifikasi identik, keputusan menguji hanya satu pusat data, dan penyerahan penuh ke vendor internal tanpa uji tuntas — bertemu di bawah tenggat komersial dan meledak bersamaan saat 5,2 juta nasabah masuk sekaligus. Pelajaran CTO-nya klasik dan mahal (~£330 juta biaya, denda £48,65 juta): pada sistem kritis, kesiapan harus dibuktikan, bukan diasumsikan; redundansi hanya nyata bila diuji; migrasi besar harus bertahap; dan tenggat komersial tak boleh mengalahkan gerbang go/no-go berbasis bukti. Sisi terang: pemulihan TSB pasca-krisis menunjukkan bencana IT bisa dibalikkan lewat kajian jujur, perbaikan tata kelola, dan kepemimpinan baru.
Sumber
- TSB Board publishes independent review of 2018 IT Migration (Slaughter and May) — TSB Bank (tier 1)
- IBM CIO Leadership Office — Update for TSB Board (written evidence TSB0003) — UK Parliament / Treasury Committee (tier 1)
- Final Notice: TSB Bank plc — FCA (tier 1)
- TSB fined £48.65m for operational resilience failings — FCA (tier 1)
- IT failures in the financial services sector (Treasury Committee report) — UK Parliament / Treasury Committee (tier 1)
- IBM early findings on disastrous TSB core banking system migration released — Computer Weekly (tier 2)
- TSB neglected to assess capabilities of main IT provider in its failed system migration — Computer Weekly (tier 2)
- TSB testing inadequate ahead of IT migration - IBM report — Finextra (tier 2)
- What broke the bank — Increment (tier 2)
- New Software System Snags TSB's Online and Mobile Banking Customers in UK — IEEE Spectrum (tier 2)
Sentimen Publik
Bagaimana Publik Memandang
Sentimen mengukur persepsi publik, bukan fakta hukum. Baca metodologi untuk batasan dan bias yang diakui.
Liputan media Inggris (The Register, Computer Weekly, IEEE Spectrum, Finextra, ITV) didominasi nada kritis: menyoroti pendekatan 'big bang', pengujian tak memadai, dan komunikasi manajemen yang optimistis. TSB menjadi studi kasus 'cautionary tale' migrasi core banking yang paling sering dikutip.
Respons regulator & parlemen tegas: FCA menilai kegagalan 'meluas dan serius', Treasury Committee menyebut komunikasi TSB 'complacent and misleading' dan hilang kepercayaan pada CEO, dan pada 2022 FCA/PRA mendenda £48,65 juta atas kegagalan resiliensi operasional & risiko outsourcing.
Nasabah mengalami terkunci dari rekening, melihat rekening orang lain, pembayaran gagal, dan menjadi sasaran penipuan yang mengeksploitasi kekacauan. Nada dominan kemarahan, kecemasan finansial, dan hilang kepercayaan; TSB menerima lonjakan keluhan berkali lipat dari normal.
Di sisi perusahaan/industri, nada terbelah: saat krisis manajemen bersikap defensif dan berjanji nasabah 'tidak akan dirugikan', memicu skeptisisme; namun muncul narasi pemulihan positif di kalangan pengamat industri ketika TSB kembali untung di bawah CEO baru Debbie Crosbie.
Reaksi publik daring (sebagaimana dilaporkan media) sinis terhadap klaim manajemen bahwa layanan 'sudah kembali normal' padahal banyak pengguna masih bermasalah — tercermin dari framing liputan seperti 'bank back online… users disagree'.