Konten disusun AI — bisa keliru. Baca disclaimer lengkap
Fisker Inc.
Ringkasan
Apa yang Terjadi
Fisker Inc. adalah produsen kendaraan listrik (EV) yang didirikan pada 2016 oleh desainer mobil ternama Henrik Fisker (perancang Aston Martin DB9 dan BMW Z8) bersama istrinya Geeta Gupta-Fisker. Ini sebenarnya percobaan KEDUA Henrik Fisker di dunia EV — perusahaan sebelumnya, Fisker Automotive (mobil Karma), telah bangkrut pada 2013. Fisker Inc. mengusung strategi 'asset-light': alih-alih membangun pabrik sendiri, manufaktur SUV andalannya, Fisker Ocean, dialihkan ke kontraktor Magna Steyr di Austria. Perusahaan go public lewat merger SPAC dengan Spartan Energy Acquisition Corp pada akhir 2020 (NYSE: FSR), meraup lebih dari US$1 miliar dengan nilai ekuitas pro forma sekitar US$2,9 miliar.
Masalahnya menumpuk begitu produk nyata harus dikirim. Fisker Ocean mulai dikirim pada 2023, tetapi dihantui masalah perangkat lunak dan kualitas build yang serius: NHTSA membuka empat penyelidikan terpisah (rem mendadak melemah, pengereman darurat otomatis yang keliru, risiko mobil menggelinding karena gagal masuk gigi parkir, dan pintu yang sulit dibuka). Mobil sangat bergantung pada perangkat lunak dan server cloud — bahkan ada laporan pemilik terkunci di dalam/luar mobil. Fisker membakar kas dengan kecepatan tak berkelanjutan, mencatat kerugian ~US$762 juta pada 2023, sementara hanya berhasil mengirim sekitar 11.000 unit.
Pada Maret 2024, Fisker menghentikan produksi selama enam minggu dan mencari suntikan dana, namun kemitraan dengan produsen otomotif besar (disebut-sebut Nissan) gagal — menggugurkan pendanaan ~US$350 juta yang menjadi tumpuan. Pada 17 Juni 2024, Fisker mengajukan kebangkrutan Chapter 11 di Delaware (aset US$500 juta–US$1 miliar, liabilitas US$1–10 miliar). Sekitar 11.000 pemilik Ocean ditinggalkan dengan mobil seharga US$40.000–US$70.000 yang perlahan kehilangan 'otak' perangkat lunaknya — sebagian bahkan kemudian membangun upaya open-source untuk menjaga mobil mereka tetap hidup.
Pelajaran utama Fisker: kemampuan mendesain mobil indah tidak sama dengan kemampuan memproduksi dan mendukungnya secara andal pada skala; strategi asset-light tidak menghapus risiko eksekusi rekayasa/perangkat lunak; membakar kas tanpa unit economics dan kualitas produk yang matang adalah jalan menuju kebangkrutan; dan menjual mobil yang sangat bergantung pada cloud menciptakan risiko bagi konsumen ketika perusahaan gagal.
Kronologi
Urutan Kejadian
Konteks: perusahaan EV pertama Henrik Fisker (Fisker Automotive) bangkrut
Sebelum Fisker Inc., Henrik Fisker memimpin Fisker Automotive dengan mobil sport hybrid mewah Karma. Perusahaan itu mengajukan kebangkrutan pada November 2013 setelah masalah produksi, recall, dan keuangan. Riwayat ini menjadi konteks penting: Fisker Inc. adalah percobaan EV kedua Henrik Fisker.
Fisker Inc. didirikan
Pada 2016, Henrik Fisker dan Geeta Gupta-Fisker mendirikan Fisker Inc. dengan visi membangun EV yang indah dan berkelanjutan. Strategi intinya 'asset-light': mendesain kendaraan sendiri namun mengalihkan manufaktur ke mitra kontraktor untuk menekan kebutuhan modal pabrik.
Go public via SPAC; raih >US$1 miliar, valuasi ~US$2,9 miliar
Fisker Inc. go public melalui merger dengan SPAC Spartan Energy Acquisition Corp (NYSE: FSR), meraup lebih dari US$1 miliar gross (termasuk PIPE US$500 juta @ US$10/saham) dengan nilai ekuitas pro forma sekitar US$2,9 miliar. Perusahaan juga menjalin kerangka kemitraan dengan Magna International untuk berbagi platform dan manufaktur Ocean — pilar strategi asset-light.
Pengiriman Fisker Ocean dimulai (dibuat Magna Steyr)
Fisker Ocean, SUV listrik andalannya yang diproduksi Magna Steyr di Austria, mulai dikirim ke konsumen pada 2023 dengan harga sekitar US$40.000–US$70.000. Namun, peningkatan produksi dan kualitas tidak berjalan mulus, dan masalah perangkat lunak mulai bermunculan sejak awal.
NHTSA buka penyelidikan atas masalah keselamatan Ocean
Regulator keselamatan AS (NHTSA) membuka beberapa penyelidikan atas Fisker Ocean sepanjang 2024 — mencakup keluhan hilangnya performa pengereman, pengereman darurat otomatis yang keliru, risiko mobil menggelinding (gagal masuk gigi parkir), dan masalah membuka pintu. Sebagian masalah memicu recall lewat pembaruan perangkat lunak.
Produksi dihentikan 6 minggu; peringatan kelangsungan usaha
Pada Maret 2024, Fisker mengumumkan menghentikan produksi EV selama enam minggu sambil berupaya mengamankan investasi (disebut ~US$150 juta) dari produsen otomotif besar. Perusahaan menghadapi keraguan serius atas kelangsungan usahanya (going concern) di tengah kas yang menipis cepat.
Kemitraan OEM gagal; pendanaan ~US$350 juta gugur
Negosiasi kemitraan dengan produsen otomotif besar (dilaporkan Nissan) gagal. Kegagalan ini menggugurkan suntikan dana sekitar US$350 juta yang menjadi tumpuan Fisker untuk bertahan — praktis menyegel nasib perusahaan yang sudah kehabisan napas finansial.
Fisker ajukan kebangkrutan Chapter 11
Pada 17 Juni 2024, Fisker Group Inc. mengajukan perlindungan kebangkrutan Chapter 11 di Delaware — sekitar dua minggu setelah me-recall Ocean. Aset ditaksir US$500 juta–US$1 miliar, liabilitas US$1–10 miliar. Fisker hanya berhasil mengirim sekitar 11.000 kendaraan, jauh dari ambisi awalnya, setelah membakar kas dengan kerugian ~US$762 juta pada 2023.
Recall perangkat lunak Ocean (gagal masuk gigi parkir)
Fisker (dalam proses kebangkrutan) menerbitkan recall untuk ribuan Ocean tahun model 2023–2024 guna mengatasi cacat perangkat lunak yang membuat kendaraan gagal masuk gigi parkir pada kecepatan rendah (risiko menggelinding). Recall menambahkan fungsi auto-park dan vehicle hold — menyoroti betapa mobil ini bergantung pada perangkat lunak.
Pemilik Ocean terlantar; mobil bergantung cloud mulai kehilangan dukungan
Setelah kebangkrutan, sekitar 11.000 pemilik Fisker Ocean menghadapi ketidakpastian: mobil yang sangat bergantung pada perangkat lunak dan server cloud perlahan kehilangan dukungan, fitur, dan layanan purnajual. Sebagian pemilik membentuk asosiasi dan bahkan upaya open-source untuk menjaga kendaraan mereka tetap berfungsi — ilustrasi nyata risiko 'mobil sebagai perangkat lunak' ketika pembuatnya tutup.
Aktor & Insentif
Siapa yang Terlibat
Henrik Fisker — Pendiri & CEO
Peran dalam Kasus
Memimpin strategi desain dan asset-light. Keunggulan desain tidak diimbangi eksekusi rekayasa/perangkat lunak dan disiplin keuangan yang memadai. Ini kegagalan EV keduanya — bukan kasus fraud, melainkan kegagalan eksekusi dan pendanaan pada skala.
Insentif
Desainer mobil legendaris yang ingin membuktikan visi EV indah dan berkelanjutan. Insentif: mewujudkan kebangkitan setelah kegagalan Fisker Automotive (2013), menjaga narasi dan harga saham pasca-SPAC, serta mengirim Ocean ke pasar secepat mungkin.
Geeta Gupta-Fisker — Co-founder & CFO/COO
Peran dalam Kasus
Bertanggung jawab atas keuangan dan operasi di tengah pembakaran kas yang cepat (rugi ~US$762 juta pada 2023). Ketidakmampuan mengamankan pendanaan lanjutan dan kemitraan OEM menjadi faktor langsung kebangkrutan.
Insentif
Mengelola keuangan dan operasi Fisker. Insentif: menjaga likuiditas dan menjalankan operasi agar Ocean dapat diproduksi dan dikirim.
Magna International (mitra manufaktur)
Peran dalam Kasus
Menjadi tulang punggung strategi asset-light Fisker. Ketergantungan pada pihak ketiga untuk produksi menambah kompleksitas koordinasi kualitas dan biaya — model ini tidak menghapus risiko eksekusi, hanya memindahkannya.
Insentif
Kontraktor manufaktur (Magna Steyr) yang membangun Ocean. Insentif: pendapatan dari kontrak produksi dan kemitraan platform.
Investor publik & pemegang saham (pasca-SPAC)
Peran dalam Kasus
Menanggung kerugian besar saat saham FSR runtuh menuju nol dan perusahaan bangkrut. Kasus Fisker menjadi salah satu contoh menonjol gelembung SPAC EV yang banyak berakhir mengecewakan.
Insentif
Investor ritel dan institusional tergiur gelombang EV dan reputasi Henrik Fisker. Insentif: imbal hasil dari 'EV startup' yang menjanjikan di pasar SPAC 2020–2021.
Pemilik Fisker Ocean — konsumen terlantar
Peran dalam Kasus
Sekitar 11.000 pemilik menghadapi masalah keselamatan/perangkat lunak, recall, dan — pasca-kebangkrutan — hilangnya dukungan cloud serta layanan. Mereka adalah korban nyata dari mobil yang sangat bergantung pada perangkat lunak ketika pembuatnya gagal.
Insentif
Konsumen yang membeli Ocean (US$40–70 ribu) percaya pada merek dan janji produk. Kepentingan: kendaraan andal, aman, dan didukung purnajual.
Insight untuk Founder
Pelajaran dari Kasus Ini
Mendesain Mobil ≠ Memproduksi & Mendukungnya pada Skala
Apa yang Terjadi
Henrik Fisker piawai mendesain mobil indah, tetapi Fisker Inc. gagal pada eksekusi: kualitas build bermasalah, perangkat lunak cacat, dan dukungan purnajual rapuh. Hanya ~11.000 unit terkirim sebelum bangkrut.
Polanya
Keunggulan di satu fungsi (desain) tidak menjamin keberhasilan di fungsi-fungsi sulit lainnya (rekayasa, manufaktur skala, perangkat lunak, layanan). Membangun perusahaan mobil utuh jauh lebih kompleks daripada merancang produknya.
Tanda Bahaya Dini
- Keunggulan terkonsentrasi pada satu aspek (mis. desain) saja
- Masalah kualitas dan perangkat lunak berulang sejak peluncuran
- Peningkatan produksi (ramp) tersendat
- Dukungan purnajual/layanan tidak matang
Aksi Pencegahan
- Bangun kapabilitas lintas fungsi, bukan hanya kekuatan inti
- Buktikan kualitas dan keandalan sebelum ekspansi pengiriman
- Investasikan pada rekayasa, perangkat lunak, dan layanan secara serius
- Jangan biarkan kekuatan desain menutupi kelemahan eksekusi
Asset-Light Tidak Menghapus Risiko Eksekusi
Apa yang Terjadi
Fisker mengalihkan manufaktur ke Magna untuk menekan modal, tetapi tetap gagal mengendalikan kualitas, biaya, dan koordinasi — risiko eksekusi hanya berpindah, tidak hilang.
Polanya
Model asset-light mengurangi kebutuhan modal awal, tetapi menambah ketergantungan dan kompleksitas koordinasi dengan pihak ketiga. Tanggung jawab atas kualitas dan pengalaman pelanggan tetap ada di pundak perusahaan.
Tanda Bahaya Dini
- Asumsi outsourcing menghapus risiko produksi/kualitas
- Koordinasi kompleks dengan mitra tanpa kendali penuh
- Kualitas akhir tidak dikelola ketat meski produksi dialihkan
- Ketergantungan tinggi pada satu mitra manufaktur
Aksi Pencegahan
- Pahami bahwa outsourcing memindahkan, bukan menghapus, risiko
- Jaga kendali ketat atas kualitas dan pengalaman pelanggan
- Kelola ketergantungan mitra dengan rencana cadangan
- Investasikan kapabilitas pengawasan rantai pasok/manufaktur
Membakar Kas Tanpa Unit Economics & Pendanaan yang Aman
Apa yang Terjadi
Fisker membakar kas cepat (rugi ~US$762 juta pada 2023) sambil bergantung pada pendanaan lanjutan dan kemitraan OEM yang belum pasti. Saat kemitraan gagal, ~US$350 juta gugur dan perusahaan bangkrut.
Polanya
Bergantung pada putaran pendanaan atau kemitraan masa depan yang belum terkunci, sambil terus membakar kas, adalah posisi rapuh. Satu kegagalan pendanaan bisa langsung mematikan.
Tanda Bahaya Dini
- Pembakaran kas tinggi tanpa jalur ke profitabilitas
- Kelangsungan bergantung pada pendanaan/kemitraan yang belum pasti
- Going-concern warning dari auditor
- Tidak ada rencana cadangan jika pendanaan gagal
Aksi Pencegahan
- Kunci pendanaan sebelum bergantung padanya untuk bertahan
- Kelola burn rate sesuai kepastian pendanaan
- Bangun jalur ke unit economics yang sehat sejak awal
- Siapkan skenario darurat bila pendanaan/kemitraan gagal
Mobil yang Bergantung Cloud: Risiko bagi Konsumen Saat Pembuat Gagal
Apa yang Terjadi
Fisker Ocean sangat bergantung pada perangkat lunak dan server cloud. Saat Fisker bangkrut, ~11.000 pemilik menghadapi hilangnya fitur dan dukungan — mobil mahal yang 'otaknya' memudar.
Polanya
Produk yang sangat bergantung pada layanan cloud/perangkat lunak pembuatnya menciptakan risiko keberlanjutan bagi konsumen: jika perusahaan tutup, fungsi produk dapat ikut mati. Ini tanggung jawab etis sekaligus risiko reputasi.
Tanda Bahaya Dini
- Fungsi inti produk bergantung pada server/cloud pembuat
- Tidak ada rencana kontinjensi bila perusahaan berhenti beroperasi
- Konsumen tak punya kendali atas perangkat lunak yang mereka beli
- Ketergantungan tinggi pada pembaruan/koneksi untuk fungsi dasar
Aksi Pencegahan
- Rancang produk agar fungsi inti tetap jalan tanpa cloud
- Pertimbangkan rencana kontinjensi/escrow untuk perangkat lunak
- Kurangi ketergantungan kritis pada layanan yang bisa hilang
- Pertimbangkan tanggung jawab jangka panjang kepada konsumen
Bedah Teknikal
Kacamata CTO
Fisker Ocean adalah software-defined vehicle (SDV): banyak fungsi kendaraan diatur perangkat lunak dan sebagian bergantung pada server cloud Fisker.
- Manufaktur di-outsource ke Magna Steyr (Austria), tetapi perangkat lunak dikembangkan in-house — tim software dibangun relatif dari nol sambil mengejar time-to-market.
- Infotainment berbasis Android Automotive OS pada head unit Harman; layar ini (ICC) terintegrasi dalam ke unit-unit kontrol kendaraan (rem, shifting, BMS, kunci pintu) yang saling terhubung lewat beberapa bus CAN.
- Detail arsitektur internal tak sepenuhnya dipublikasikan; bagian berlabel Inferensi adalah dugaan beralasan dari gejala publik, bukan fakta.
Akar Masalah Teknis
Kapabilitas software yang belum matang mengejar tenggat produk
Apa yang terjadi
Fisker membangun kemampuan software kendaraan relatif dari nol sambil mengejar peluncuran; hasilnya software 'belum lengkap' saat pengiriman dan bug berulang tiap rilis.
Polanya
Perusahaan hardware sering meremehkan bahwa membangun mobil modern = membangun organisasi software matang; bakat & proses rilis butuh tahunan, bukan bisa dikejar dengan tenggat.
Tanda bahaya dini
- Peluncuran molor berulang karena 'integrasi software'
- Fitur di-ship sebagian / mode dasar yang membatasi kendaraan
- Bug yang sama muncul lagi setelah rilis (regresi)
Pencegahan
- Investasi awal pada tim & kepemimpinan software, bukan afterthought
- Definisikan gerbang kualitas rilis (release gate) sebelum ship
- Kurangi cakupan fitur digital sampai fondasi stabil
Jeda panjang dari akar masalah ke perbaikan di produksi
Apa yang terjadi
Software MCU/VCU membuat kendaraan masuk failsafe mode (hilang tenaga). Akar diidentifikasi ~Feb 2024, tetapi fix baru masuk produksi seri akhir April 2024 — sementara keluhan sudah berbulan-bulan.
Polanya
Bug keselamatan pada subsistem kritikal butuh pipeline validasi + rilis yang cepat dan tepercaya. Jeda RCA-ke-produksi yang lama membuat cacat hidup berdampak ke pengguna nyata.
Tanda bahaya dini
- Keluhan pengguna atas gejala keselamatan menumpuk tanpa perbaikan
- RCA selesai tetapi rilis perbaikan tertahan berminggu-minggu
- Ketergantungan pada satu jendela rilis besar, bukan hotfix cepat
Pencegahan
- Jalur hotfix keselamatan terpisah dari rilis fitur reguler
- Uji validasi terotomasi untuk MCU/VCU (termasuk skenario winter/low-traction)
- Telemetri lapangan untuk mendeteksi failsafe lebih dini
QA & manajemen rilis OTA yang belum disiplin
Apa yang terjadi
Bug berulang tiap versi; muncul regresi antar-rilis (mis. seri 2.2.x melaporkan masalah fast-charging/key-fob baru), dan pembaruan OTA (pasca-bangkrut via pihak ketiga) dilaporkan membrick ~10% mobil.
Polanya
OTA menekan biaya recall, tetapi tanpa staged rollout, kanary, dan mekanisme rollback, satu rilis buruk bisa menyebar cepat ke seluruh armada.
Tanda bahaya dini
- Rilis baru memperbaiki satu hal, memecahkan hal lain
- Tidak ada rollout bertahap / kohort kanary
- Proses update lama & rapuh (mobil tak boleh disentuh berjam-jam)
Pencegahan
- Staged rollout + kohort kanary + auto-rollback
- Regression suite wajib lulus sebelum promosi rilis
- A/B pemantauan telemetri kesehatan armada per-versi
Kopling kritikal ke cloud tanpa rencana keberlangsungan
Apa yang terjadi
Fungsi kendaraan & diagnostik bergantung pada server Fisker. Saat perusahaan bangkrut, ~11.000 pemilik menghadapi risiko kehilangan fitur karena 'otak' mobil ada di cloud yang bisa padam.
Polanya
Produk yang fungsi intinya bergantung layanan pembuatnya menciptakan risiko keberlangsungan bagi konsumen: bila perusahaan tutup, fungsi produk ikut mati. Ini risiko teknis sekaligus etis.
Tanda bahaya dini
- Fungsi dasar/keselamatan butuh koneksi ke server pembuat
- Tidak ada mode offline/degradasi anggun
- Tidak ada rencana escrow/kontinjensi untuk software bila perusahaan bubar
Pencegahan
- Rancang agar fungsi inti tetap jalan tanpa cloud (offline-first)
- Degradasi anggun: fitur premium boleh mati, keselamatan/berkendara tidak
- Pertimbangkan escrow kode/kunci untuk kontinjensi jangka panjang
Integrasi HMI-ke-subsistem yang rapuh
Apa yang terjadi
Layar infotainment (ICC, Android Automotive) terintegrasi dalam ke unit kontrol; layar beku/menghitam/reboot berulang mengganggu kontrol berkendara, bukan sekadar hiburan.
Polanya
Inferensi: menempatkan HMI pusat sebagai jalur ke banyak fungsi kendaraan menaikkan blast radius satu bug software — kegagalan layar menyeret pengalaman/kendali inti.
Tanda bahaya dini
- Fungsi kendaraan penting hanya bisa diakses lewat satu layar
- Layar reboot saat berkendara
- Sedikit kontrol fisik cadangan (hard button)
Pencegahan
- Isolasi domain: pisahkan HMI dari fungsi keselamatan-kritikal
- Sediakan kontrol fisik cadangan untuk fungsi esensial
- Watchdog & pemulihan cepat untuk proses HMI
Keputusan Teknis & Trade-off
Membangun software kendaraan in-house sambil mengejar rilis
Konteks
Startup ingin kendali penuh atas pengalaman digital & OTA; membangun tim software (mis. Android Automotive) sendiri terasa strategis untuk diferensiasi.
Trade-off
Kendali & diferensiasi vs kematangan proses, waktu, dan bakat yang butuh bertahun-tahun dibangun.
Hasil
Software 'belum lengkap' saat kirim; bug berulang tiap rilis; peluncuran molor dan target produksi dipangkas.
Software-defined vehicle yang bergantung cloud untuk fungsi & diagnostik
Konteks
SDV memungkinkan fitur baru & perbaikan lewat OTA tanpa recall fisik — model yang dipopulerkan Tesla dan masuk akal untuk EV modern.
Trade-off
Fleksibilitas OTA & fitur konektif vs ketergantungan pada keberlangsungan server pembuat.
Hasil
Saat perusahaan bangkrut, ~11.000 pemilik menghadapi risiko kehilangan fitur karena 'otak' mobil ada di cloud yang bisa mati.
OTA sebagai kanal remediasi utama untuk cacat keselamatan
Konteks
OTA menekan biaya recall fisik dan mempercepat perbaikan — daya tarik besar bagi perusahaan yang membakar kas.
Trade-off
Kecepatan/biaya perbaikan vs risiko regresi, kebutuhan pipeline rilis matang, dan ketergantungan konektivitas.
Hasil
Banyak recall diselesaikan via OTA, tetapi muncul regresi antar-versi dan (pasca-bangkrut, via pihak ketiga) laporan pembaruan yang membrick sebagian mobil.
Android Automotive OS di head unit Harman (beli fondasi, bukan bikin dari nol)
Konteks
Memakai AAOS yang matang memangkas waktu pengembangan infotainment dan memberi fondasi yang bisa dimodifikasi.
Trade-off
Percepatan & ekosistem vs integrasi mendalam ke unit kontrol kendaraan yang tetap rumit dan jadi sumber bug HMI.
Hasil
Fondasi wajar, tetapi integrasi ICC ke subsistem kendaraan tetap rapuh — layar beku/reboot berdampak ke pengalaman berkendara.
Insight untuk CTO
Membangun mobil modern berarti membangun organisasi software matang — perlakukan software sebagai kompetensi inti sejak hari pertama, bukan pelengkap desain.
🚩 Peringatan dini
Peluncuran molor berulang karena 'integrasi software'; fitur di-ship setengah jadi.
🛡️ Pencegahan
Rekrut kepemimpinan software awal, tetapkan release gate, dan kurangi cakupan fitur digital sampai fondasi stabil.
OTA menekan biaya recall, tetapi hanya aman dengan staged rollout, kanary, dan rollback — tanpa itu, satu rilis buruk menular ke seluruh armada.
🚩 Peringatan dini
Rilis baru memperbaiki A tapi memecahkan B; tidak ada kohort kanary.
🛡️ Pencegahan
Rollout bertahap + auto-rollback + regression suite wajib lulus sebelum promosi.
Rancang degradasi anggun: fitur cloud/premium boleh mati, tetapi berkendara dan keselamatan harus tetap jalan tanpa server pembuat.
🚩 Peringatan dini
Fungsi dasar butuh koneksi server; tidak ada mode offline.
🛡️ Pencegahan
Offline-first untuk fungsi inti; pertimbangkan escrow software untuk kontinjensi bila perusahaan bubar.
Jalur hotfix keselamatan harus terpisah dan cepat — jeda berminggu-minggu dari RCA ke produksi membiarkan cacat kritikal hidup di jalan.
🚩 Peringatan dini
RCA selesai tetapi perbaikan tertahan menunggu satu rilis besar.
🛡️ Pencegahan
Pipeline hotfix terpisah, uji validasi terotomasi untuk MCU/VCU, telemetri lapangan untuk deteksi dini.
Verdict CTO
Andai jadi CTO Fisker 2–3 tahun sebelum krisis:
- Jadikan software kompetensi inti sejak awal — bangun tim & kepemimpinan software lebih dulu dari tanggal peluncuran; jangan kirim mobil dengan software 'belum lengkap'.
- Tetapkan release gate keras — kurangi cakupan fitur digital sampai fondasi stabil; lebih baik fitur sedikit tapi andal.
- Pisahkan jalur hotfix keselamatan — supaya perbaikan MCU/VCU tak menunggu berminggu-minggu di antrean rilis fitur.
- Disiplin OTA — staged rollout, kohort kanary, auto-rollback, dan regression suite wajib sebelum menyentuh armada.
- Desain untuk keberlangsungan konsumen — degradasi anggun tanpa cloud dan rencana escrow software, agar mobil tetap hidup meski perusahaan tidak.
Sumber
- Fisker's Debut EV Faces Ongoing Software Problems — Automotive News (tier 1)
- Fisker Ocean owners flagged sudden power loss and brake problems for months, internal documents show — TechCrunch (tier 1)
- Fisker's electric Ocean SUV under investigation over braking loss complaints — TechCrunch (tier 1)
- Fisker Ocean Braking Issue That Prompted NHTSA Probe Was Fixed With An OTA Update — InsideEVs (tier 2)
- Fisker recalls thousands of Ocean SUVs in U.S. and Europe due to software issues — CBT News (tier 2)
- Fisker Ocean Extreme Drivers Say This About The Software Issues — SlashGear (tier 2)
- NHTSA Closes Fisker Investigation After Rollaway Recall Issued — Carscoops (tier 2)
- One Year After Fisker's Bankruptcy, Ocean Owners Are Still Paying the Price — autoevolution (tier 2)
- Fisker went bankrupt and owners built open source car company from the ashes — Electrek (tier 2)
- Android Automotive OS (Fisker Ocean discussion) — Fisker Ocean Forum (tier 3)
- 2023-2024 Fisker Ocean Infotainment Display: Software Bugs & Failures — Go-Parts (tier 3)
Sentimen Publik
Bagaimana Publik Memandang
Sentimen mengukur persepsi publik, bukan fakta hukum. Baca metodologi untuk batasan dan bias yang diakui.
Liputan (TechCrunch, Electrek, IndustryWeek) membingkai Fisker sebagai kegagalan eksekusi EV dan contoh menonjol gelembung SPAC — menyoroti masalah perangkat lunak, kualitas build, dan pembakaran kas. Nada dominan kritis, meski mengakui desain Ocean menarik.
NHTSA membuka empat penyelidikan (rem, AEB, gagal parkir/menggelinding, pintu) dan Fisker menerbitkan beberapa recall perangkat lunak. Posisi regulator menegaskan adanya masalah keselamatan nyata pada produk.
Sekitar 11.000 pemilik Ocean menghadapi masalah keselamatan, recall, dan — pasca-kebangkrutan — hilangnya dukungan cloud/purnajual. Sentimen sangat negatif dan personal; sebagian membentuk asosiasi/upaya open-source untuk menyelamatkan mobil mereka.
Pemegang saham publik (pasca-SPAC) dan kreditor menanggung kerugian besar saat saham FSR runtuh dan perusahaan bangkrut. Fisker menjadi simbol kekecewaan investor atas gelombang SPAC EV 2020–2021.
Sebagian komunitas otomotif menghormati bakat desain Henrik Fisker dan menilai kegagalan ini soal eksekusi/pendanaan, bukan niat buruk; namun fakta ini kegagalan EV keduanya memunculkan kritik atas pola berulang. Simpati ada namun minoritas.
Percakapan daring mencampur kekecewaan pemilik, kritik atas mobil 'bergantung cloud yang ditinggalkan', dan diskusi soal risiko EV startup/SPAC. Nada mayoritas negatif, dengan sebagian apresiasi pada upaya komunitas pemilik.