RPS minggu 14 · 2x50 menit

Manajemen Risiko Teknologi

Keusangan Teknologi dan Ketergantungan Vendor

Mata Kuliah Manajemen Teknologi · Program Studi Manajemen · FEB UNDIP

Selamat datang di pertemuan ke-13. Setelah 12 pertemuan membahas bagaimana teknologi mendukung strategi, inovasi, dan model bisnis baru, hari ini kita membalik sudut pandang: apa yang bisa membuat pilihan teknologi Boss di perusahaan justru menjadi beban. Dua risiko utama yang kita bedah adalah keusangan teknologi — ketika sistem yang tadinya unggul tiba-tiba tertinggal, seperti nasib Nokia yang gagal beradaptasi ke smartphone — dan ketergantungan vendor, ketika perusahaan terjebak pada satu penyedia teknologi sehingga sulit dan mahal untuk pindah. Bayangkan sebuah UMKM di Semarang yang seluruh kasir dan pembukuannya bergantung pada satu aplikasi kasir digital tertentu; kalau vendor itu menaikkan harga tiba-tiba, UMKM tersebut punya pilihan terbatas. Materi hari ini menyiapkan Anda untuk pertemuan terakhir, yaitu studi kasus terintegrasi manajemen teknologi perusahaan riil.

Bagian 1 dari 3

Keusangan Teknologi

Mengapa teknologi unggul hari ini bisa usang esok hari

Risiko Teknologi dalam Manajemen Strategis

Definisi Kerja

Risiko teknologi adalah kemungkinan kerugian bisnis akibat pilihan atau ketergantungan pada teknologi tertentu — bukan risiko teknis semata (server rusak), melainkan risiko manajerial jangka menengah-panjang.

Berbeda dari risiko operasional TI harian (downtime, bug)
Menyangkut keputusan investasi, kontrak, dan arah strategi
Wajib dikelola sejajar dengan risiko keuangan & pasar

Dua Fokus Pertemuan Ini

Keusangan teknologi — aset/sistem jadi tertinggal
Ketergantungan vendor — terjebak pada satu penyedia
Keduanya berakar dari keputusan roadmap & make-or-buy (P4-P5)

Keusangan Teknologi: Definisi dan Jenis

Keusangan Teknis

Teknologi tergantikan teknologi baru yang lebih unggul
Contoh: kamera film digantikan kamera digital
Kinerja lama secara objektif kalah

Keusangan Fungsional

Kebutuhan pengguna berubah, teknologi tak lagi cocok
Contoh: mesin EDC fisik vs QRIS di gerai UMKM
Teknologi masih berfungsi, tapi tak relevan lagi

Keusangan Terencana

Disengaja produsen agar konsumen membeli ulang
Contoh: dukungan software dihentikan untuk model lama
Isu etika & keberlanjutan bagi manajer

Keusangan dan Kurva-S Teknologi

Saat kurva teknologi baru melampaui kurva lama yang sudah mendatar, teknologi lama masuk fase usang secara kompetitif (lihat kembali kurva-S di Pertemuan 2).

Grafik ini menghubungkan kembali dengan kurva-S yang kita bahas di pertemuan kedua semester lalu. Setiap teknologi punya kurva pertumbuhan kinerja yang pada akhirnya mendatar karena mencapai batas fisik atau batas pasar, seperti kurva teknologi lama yang saya gambar dengan garis solid. Masalahnya muncul ketika teknologi baru, digambarkan garis putus-putus, tumbuh lebih cepat dan pada satu titik melampaui kinerja teknologi lama, itulah yang saya tandai sebagai titik keusangan. Contoh nyata adalah kurva kinerja jaringan 4G yang mendatar, sementara kurva 5G terus naik dan pada akhirnya menggeser posisi 4G sebagai standar utama konektivitas bisnis. Pelajaran manajerial di sini adalah perusahaan sering terlambat menyadari titik keusangan karena kurva lama masih terlihat "cukup baik" sampai tiba-tiba kalah telak dari pesaing yang sudah pindah lebih dulu.

Penyebab Keusangan: Internal vs Eksternal

Faktor Internal Perusahaan

Investasi R&D dan pembaruan sistem terlalu minim
Budaya organisasi resisten terhadap perubahan (lihat P8)
Keputusan manajemen menunda modernisasi demi hemat biaya jangka pendek
Ketergantungan pada satu tim/vendor internal yang enggan berubah

Faktor Eksternal Pasar

Disrupsi dari pendatang baru dengan teknologi lebih murah/cepat
Perubahan preferensi konsumen (contoh: nontunai menggeser tunai)
Regulasi baru yang mewajibkan standar teknologi berbeda
Siklus hidup komponen pendukung berakhir (vendor hardware tutup)

Penyebab keusangan bisa dipilah menjadi dua sumber. Dari sisi internal, banyak perusahaan menunda investasi pembaruan sistem karena ingin menghemat biaya jangka pendek, padahal penundaan ini justru memperbesar biaya migrasi di kemudian hari; budaya organisasi yang resisten terhadap perubahan, yang sudah kita bahas di pertemuan 8 tentang adopsi teknologi, juga memperlambat modernisasi. Dari sisi eksternal, disrupsi kompetitor baru dengan teknologi lebih murah bisa membuat sistem lama tiba-tiba tidak kompetitif, seperti yang dialami taksi konvensional saat aplikasi ojek online masuk pasar Indonesia. Regulasi juga bisa memaksa keusangan, misalnya ketika Bank Indonesia mewajibkan standar keamanan pembayaran baru sehingga sistem lama tidak lagi memenuhi syarat. Sebagai manajer, tugas Anda adalah memindai kedua sumber ini secara berkala, bukan menunggu sampai kompetitor atau regulator memaksa perubahan.

Hitung dari Nol: Kapan Sistem Lama Layak Diganti?

Langkah	Perhitungan	Nilai
1. Biaya pemeliharaan sistem lama/tahun	diberikan (ilustrasi anggaran TI)	Rp 180.000.000
2. Investasi sistem baru (one-time)	diberikan (ilustrasi harga vendor)	Rp 900.000.000
3. Penghematan operasional/tahun sistem baru	diberikan (efisiensi proses & SDM)	Rp 350.000.000
4. Payback period penggantian	900.000.000 / 350.000.000	2,57 tahun
5. Sisa umur ekonomis sistem lama (estimasi manajemen)	diberikan (usia komponen & dukungan vendor)	2 tahun

Payback Period Penggantian

2,57 tahun

Payback (2,57 th) > sisa umur ekonomis (2 th) → investasi belum sepenuhnya balik modal sebelum sistem lama benar-benar tak terdukung; perlu evaluasi ulang jadwal atau negosiasi harga.

Mari kita hitung bersama kapan penggantian sistem lama benar-benar layak secara finansial, bukan sekadar perasaan "sudah ketinggalan". Langkah pertama dan kedua adalah data yang biasanya sudah tersedia di anggaran TI perusahaan, yaitu biaya pemeliharaan sistem lama dan harga investasi sistem baru dari vendor. Langkah ketiga adalah estimasi penghematan operasional, misalnya karena proses yang tadinya manual menjadi otomatis sehingga mengurangi jam kerja staf. Pada langkah keempat kita membagi investasi dengan penghematan tahunan untuk mendapatkan payback period, hasilnya 2,57 tahun, lalu kita bandingkan dengan sisa umur ekonomis sistem lama yang hanya 2 tahun; karena payback lebih panjang dari sisa umur, keputusan yang bijak adalah bernegosiasi ulang dengan vendor atau mencari opsi investasi bertahap, bukan langsung menandatangani kontrak besar.

Coba Sendiri: EAC: Tahun Optimal Mengganti Sistem Lama

Geser investasi baru, penghematan, dan eskalasi biaya pemeliharaan lama — lihat kurva biaya tahunan bersilang dan tahun penggantian optimal bergeser.

Studi Kasus: Kodak dan Nokia

Kodak dan Kamera Digital

Kodak justru menemukan teknologi kamera digital lebih dulu (1975)
Manajemen menahan peluncuran karena takut mengganggu bisnis film
Kompetitor lebih dulu memasarkan kamera digital secara agresif
Kodak bangkrut tahun 2012 — korban keusangan yang disadari tapi diabaikan

Nokia dan Era Smartphone

Nokia dominan di ponsel fitur, lambat merespons layar sentuh & app store
Sistem operasi Symbian dianggap "cukup baik" terlalu lama
Apple & Android mengubah standar interaksi pengguna secara mendasar
Nokia kehilangan dominasi pasar dalam waktu kurang dari satu dekade

Pelajaran umum: keusangan paling berbahaya bukan yang tak terlihat, melainkan yang terlihat namun diabaikan karena bisnis lama masih menguntungkan.

Kedua kasus ini sengaja saya letakkan tanpa animasi bertahap karena Anda perlu melihat gambaran utuhnya sekaligus untuk diskusi. Kodak sebenarnya adalah contoh paling ironis karena perusahaan itu sendiri yang menemukan teknologi kamera digital, tetapi manajemen menahannya karena takut mengganggu bisnis film yang masih sangat menguntungkan saat itu. Nokia punya pola serupa: mereka mendominasi ponsel fitur dan menganggap sistem Symbian sudah cukup baik, padahal Apple dan Android sedang mengubah cara orang berinteraksi dengan ponsel lewat layar sentuh dan aplikasi. Bandingkan ini dengan kondisi Indonesia hari ini, misalnya bank yang masih nyaman dengan sistem cabang fisik padahal nasabah muda semakin beralih ke aplikasi digital seperti yang ditawarkan bank digital baru; pertanyaan diskusi untuk Anda adalah, industri apa di Indonesia yang menurut Anda sedang mengalami pola Kodak-Nokia saat ini.

Strategi Mitigasi Keusangan Teknologi

Tinjauan Roadmap Berkala

Evaluasi roadmap teknologi (P4) tiap 1-2 tahun
Bandingkan posisi kurva-S internal vs pasar
Libatkan tim luar untuk sudut pandang independen

Portofolio Teknologi Seimbang

Jangan taruh semua investasi pada satu teknologi
Sisihkan anggaran eksplorasi teknologi baru (lihat P6)
Desain sistem modular agar mudah diganti sebagian

Budaya Kewaspadaan

Dorong tim berani melaporkan sinyal disrupsi
Hindari bias "bisnis lama masih untung, jangan ganggu"
Jadikan keusangan agenda rutin rapat direksi

Untuk memitigasi keusangan, langkah pertama adalah rutin meninjau ulang roadmap teknologi yang sudah kita bahas di pertemuan 4, idealnya setiap satu sampai dua tahun, dan membandingkan posisi teknologi perusahaan dengan posisi pesaing di kurva-S. Langkah kedua adalah menjaga portofolio teknologi tetap seimbang, tidak menaruh seluruh investasi pada satu sistem monolitik, melainkan mendesain arsitektur modular sehingga satu komponen bisa diganti tanpa merombak seluruh sistem, mirip prinsip yang diterapkan banyak perusahaan fintech Indonesia saat membangun platform mereka. Langkah ketiga, yang sering diabaikan, adalah membangun budaya organisasi yang berani mengakui sinyal disrupsi sejak dini, bukan menutup mata karena bisnis lama masih menguntungkan, persis pelajaran dari kasus Kodak yang baru saja kita bahas. Ketiga strategi ini perlu berjalan bersamaan, karena roadmap yang baik tanpa budaya kewaspadaan tetap bisa gagal dieksekusi tepat waktu.

Bagian 2 dari 3

Ketergantungan Vendor

Ketika berpindah dari satu penyedia teknologi menjadi sangat mahal

Bagian kedua membahas risiko yang berbeda sifatnya dari keusangan, yaitu ketergantungan vendor atau yang biasa disebut vendor lock-in, kondisi ketika perusahaan begitu terikat pada satu penyedia teknologi sehingga berpindah ke penyedia lain menjadi sangat mahal, rumit, atau berisiko. Risiko ini sering muncul justru dari keputusan make-or-buy yang kita bahas di pertemuan 5, ketika perusahaan memilih membeli atau berlisensi teknologi dari pihak luar demi kecepatan, tanpa mempertimbangkan jalan keluarnya di masa depan. Contoh yang mungkin sudah Anda kenal adalah perusahaan yang seluruh datanya tersimpan di satu penyedia layanan cloud tertentu, atau UMKM yang seluruh sistem kasirnya bergantung pada satu aplikasi POS. Kita akan belajar mengenali bentuk-bentuk lock-in, menghitung biaya berpindah vendor, dan merancang strategi agar perusahaan tidak terjebak.

Vendor Lock-in: Definisi dan Bentuknya

Lock-in Kontraktual

Kontrak jangka panjang dengan penalti keluar tinggi
Klausul eksklusivitas atau minimum komitmen volume
Contoh: kontrak lisensi ERP 5 tahun tanpa opsi keluar dini

Lock-in Teknis

Format data/API proprietary, sulit diintegrasikan
Sistem dirancang hanya kompatibel dengan produk vendor sendiri
Contoh: perangkat keras khusus yang hanya jalan di software vendor X

Lock-in Data & SDM

Data historis terkunci di sistem vendor
Karyawan terlatih khusus satu platform, sulit beralih
Biaya migrasi data + pelatihan ulang jadi penghalang

Vendor lock-in bisa muncul dalam tiga bentuk yang perlu Anda bedakan. Lock-in kontraktual adalah yang paling mudah dikenali karena tertulis hitam di atas putih, misalnya kontrak lisensi sistem ERP selama lima tahun dengan penalti besar jika perusahaan ingin keluar lebih awal. Lock-in teknis lebih tersembunyi, terjadi ketika format data atau antarmuka pemrograman aplikasi bersifat proprietary sehingga sulit dipindahkan ke sistem lain, contohnya perangkat kasir tertentu yang hanya bisa berjalan dengan software resmi dari vendor yang sama. Lock-in data dan SDM sering paling mahal secara tersembunyi karena data transaksi bertahun-tahun tersimpan dalam format khusus vendor, ditambah karyawan yang sudah terlatih bertahun-tahun hanya menguasai satu platform sehingga migrasi berarti pelatihan ulang besar-besaran; bayangkan bagaimana repotnya sebuah toko retail nasional jika harus melatih ribuan kasir menggunakan sistem POS baru secara serentak.

Bagaimana Lock-in Terjadi: Dua Skenario

Skenario A: Kontrak ERP Jangka Panjang

Perusahaan pilih ERP tunggal demi implementasi cepat
Kontrak 5 tahun ditandatangani tanpa klausul exit yang jelas
Setelah 3 tahun, kebutuhan bisnis berubah, vendor tak mampu ikuti
Biaya pindah dinilai lebih mahal daripada bertahan — lock-in terjadi

Skenario B: Format Data Proprietary

Aplikasi akuntansi UMKM simpan data dalam format tertutup
Tidak ada fitur ekspor data penuh yang kompatibel sistem lain
Vendor naikkan harga langganan tahunan secara signifikan
UMKM bertahan karena migrasi data dianggap terlalu berisiko

Dua skenario ini saya tampilkan sekaligus, tanpa animasi bertahap, agar Anda bisa membandingkan langsung polanya. Skenario pertama menunjukkan bagaimana kontrak jangka panjang tanpa klausul keluar yang jelas bisa menjebak perusahaan besar seperti korporasi yang mengimplementasikan sistem ERP untuk seluruh operasinya. Skenario kedua justru lebih relevan bagi UMKM di Indonesia, ketika aplikasi kasir atau akuntansi digital yang tadinya membantu justru menjadi jebakan karena data transaksi bertahun-tahun tidak bisa diekspor dengan mudah ke sistem lain. Perhatikan pola yang sama di kedua skenario, yaitu keputusan awal yang terlihat rasional dan cepat, tetapi tidak mempertimbangkan jalan keluar di masa depan; inilah sebabnya negosiasi kontrak dan uji coba portabilitas data harus dilakukan sejak awal, bukan setelah masalah muncul.

Hitung dari Nol: Layakkah Pindah Vendor?

Langkah	Perhitungan	Nilai
1. Biaya migrasi data & pelatihan (one-time)	diberikan (ilustrasi proyek migrasi)	Rp 250.000.000
2. Biaya integrasi ulang sistem (one-time)	diberikan (ilustrasi konsultan TI)	Rp 150.000.000
3. Total switching cost	250.000.000 + 150.000.000	Rp 400.000.000
4. Penghematan biaya lisensi vendor baru/tahun	diberikan (selisih harga langganan)	Rp 120.000.000
5. Payback period switching	400.000.000 / 120.000.000	3,33 tahun

Payback Period Switching Vendor

3,33 tahun

Jika sisa masa kerja sama dengan vendor lama < 3,33 tahun, bertahan lebih murah; jika sisa kebutuhan sistem > 3,33 tahun (misal masih 5 tahun ke depan), pindah vendor mulai layak dipertimbangkan.

Sekarang kita hitung keputusan pindah vendor secara kuantitatif, bukan sekadar merasa kesal dengan vendor lama. Langkah pertama dan kedua menjumlahkan seluruh biaya satu kali yang harus dikeluarkan untuk migrasi, yaitu biaya migrasi data dan pelatihan ulang staf, ditambah biaya integrasi ulang sistem dengan konsultan TI, totalnya menjadi switching cost sebesar Rp 400 juta pada langkah ketiga. Langkah keempat adalah penghematan tahunan yang akan didapat dari vendor baru, misalnya karena harga lisensinya lebih kompetitif, dan langkah kelima membagi switching cost dengan penghematan tahunan tersebut sehingga didapat payback period 3,33 tahun. Artinya, jika perusahaan masih membutuhkan sistem ini lebih dari 3,33 tahun ke depan, keputusan pindah vendor mulai masuk akal secara finansial; sebaliknya jika kebutuhan sistem diperkirakan berakhir dalam waktu dekat, lebih baik bertahan dan negosiasi ulang harga dengan vendor lama.

Coba Sendiri: Kalkulator Keputusan Ganti Vendor

Ubah biaya vendor lama, vendor baru, dan biaya migrasi untuk kasus Anda sendiri, lalu bandingkan total biaya 5 tahun kedua opsi.

Studi Kasus: Migrasi Sistem di Perusahaan Indonesia

Ilustrasi: Ritel Nasional Berganti Platform Cloud

Perusahaan ritel besar sudah 6 tahun memakai satu penyedia cloud tunggal
Biaya langganan naik signifikan setiap perpanjangan kontrak tahunan
Tim TI menemukan format data toko sulit dipindahkan tanpa kehilangan riwayat transaksi
Perusahaan menegosiasikan klausul portabilitas data sebelum memutuskan tetap bertahan 2 tahun lagi sambil membangun arsitektur multi-cloud secara bertahap

Keputusan akhir sering berupa jalan tengah: tidak langsung pindah total, tetapi membangun opsi keluar secara bertahap sambil tetap beroperasi.

Studi kasus ini adalah pola umum yang sering terjadi pada perusahaan ritel nasional maupun BUMN yang sudah lama memakai satu penyedia layanan cloud. Ketika biaya langganan terus naik setiap tahun sementara tim TI menyadari data transaksi historis sulit dipindahkan tanpa kehilangan riwayat penting untuk audit, perusahaan berada di posisi sulit antara bertahan dengan biaya mahal atau migrasi dengan risiko tinggi. Solusi yang sering diambil bukan migrasi total secara mendadak, melainkan negosiasi ulang kontrak sambil membangun arsitektur yang lebih terbuka secara bertahap, misalnya menerapkan strategi multi-cloud sehingga ketergantungan pada satu vendor berkurang perlahan. Pendekatan bertahap ini penting Anda catat karena migrasi mendadak tanpa perencanaan justru bisa mengganggu operasional harian, seperti risiko gangguan transaksi kasir di ratusan gerai secara bersamaan.

Strategi Mitigasi Ketergantungan Vendor

Multi-Vendor / Dual-Sourcing

Hindari satu vendor untuk sistem yang sangat kritikal
Bangun kapabilitas paralel meski biaya awal lebih tinggi
Perkuat posisi tawar saat negosiasi kontrak

Standar Terbuka & Portabilitas Data

Pilih sistem dengan format data & API terbuka
Uji coba ekspor data penuh sebelum tanda tangan kontrak
Hindari sistem yang hanya jalan di ekosistem tertutup

Klausul Exit dalam Kontrak

Negosiasikan klausul keluar & masa transisi sejak awal
Batasi penalti keluar dalam batas wajar
Libatkan tim legal, bukan hanya tim TI, saat kontrak

Tiga strategi ini saling melengkapi dalam memitigasi ketergantungan vendor. Strategi multi-vendor atau dual-sourcing berarti perusahaan sengaja tidak menaruh seluruh sistem kritikal pada satu penyedia, meski konsekuensinya biaya operasional sedikit lebih tinggi di awal, tetapi ini memperkuat posisi tawar perusahaan saat negosiasi ulang kontrak. Strategi kedua adalah memilih sistem dengan standar terbuka dan memastikan fitur ekspor data penuh sudah diuji coba sebelum kontrak ditandatangani, bukan sekadar dijanjikan dalam presentasi penjualan vendor. Strategi ketiga sering diabaikan perusahaan Indonesia, yaitu melibatkan tim legal sejak awal proses pengadaan teknologi untuk memastikan klausul keluar dan masa transisi sudah jelas, bukan hanya menyerahkan seluruh negosiasi kepada tim TI yang biasanya fokus pada fitur teknis, bukan risiko kontraktual jangka panjang.

Coba Sendiri: Single Source vs Best-of-Breed: Trade-off Integrasi

Geser kebutuhan fitur dan toleransi biaya integrasi — lihat pilihan satu vendor tunggal atau gabungan terbaik tiap fungsi bergantian menjadi rasional.

Bagian 3 dari 3

Manajemen Risiko Teknologi Terintegrasi

Menyatukan keusangan dan ketergantungan vendor dalam satu kerangka governance

Matriks Risiko Teknologi: Kemungkinan x Dampak

Matriks ini adalah alat sederhana namun sangat berguna untuk memetakan risiko teknologi berdasarkan dua dimensi, kemungkinan terjadinya di sumbu vertikal dan dampaknya terhadap bisnis di sumbu horizontal. Kotak-kotak dengan garis tebal di pojok kanan atas adalah zona prioritas tinggi yang butuh perhatian manajemen segera, misalnya risiko vendor tunggal pada sistem inti seperti core banking atau sistem kasir utama, karena dampaknya besar dan kemungkinan masalahnya muncul juga tinggi seiring waktu. Keusangan mendadak akibat disrupsi cepat, seperti yang dialami Nokia, juga masuk zona prioritas karena meski jarang terjadi, dampaknya bisa sangat besar ketika terjadi. Sebaliknya, lock-in kontrak jangka panjang yang dampaknya sedang biasanya masih bisa dikelola dengan negosiasi ulang, bukan respons darurat. Latihan untuk Anda: coba petakan risiko teknologi perusahaan tempat Anda magang atau bekerja ke dalam matriks ini.

Coba Sendiri: Risk Register Teknologi: Skor & Re-Ranking

Ubah likelihood dan impact tiap risiko teknologi — lihat posisi di matriks lima kali lima dan peringkat prioritas mitigasi tersusun ulang.

Kerangka Mitigasi Menyeluruh

Empat Tahap Berkelanjutan

1Identifikasi — pindai sinyal keusangan & ketergantungan vendor
2Nilai — petakan ke matriks kemungkinan x dampak
3Mitigasi — jalankan strategi (roadmap, multi-vendor, klausul exit)
4Pantau — tinjau ulang berkala, bukan sekali jadi

Prinsip Kunci

Risiko teknologi tidak statis — kurva-S terus bergerak
Mitigasi murah di awal, mahal jika ditunda
Governance risiko teknologi = tanggung jawab manajemen puncak, bukan hanya tim TI

Kerangka empat tahap ini merangkum seluruh materi hari ini menjadi siklus yang berjalan terus-menerus, bukan proyek satu kali selesai. Tahap identifikasi berarti perusahaan secara rutin memindai sinyal keusangan dan ketergantungan vendor, tahap penilaian memetakannya ke matriks yang baru kita bahas, tahap mitigasi menjalankan strategi konkret seperti yang sudah kita pelajari di kedua bagian sebelumnya, dan tahap pemantauan memastikan siklus ini diulang secara berkala karena kondisi pasar dan teknologi terus berubah. Prinsip kuncinya adalah risiko teknologi bersifat dinamis, sama seperti kurva-S yang terus bergerak, sehingga mitigasi yang dilakukan lebih awal selalu lebih murah daripada menunggu krisis terjadi, persis seperti perhitungan payback period yang kita lakukan tadi. Terakhir, governance risiko teknologi seharusnya menjadi agenda manajemen puncak dan bahkan komite risiko perusahaan, bukan hanya urusan teknis tim TI, karena dampaknya menyentuh strategi bisnis secara keseluruhan.

Coba Sendiri: Berapa Rupiah Kontrol yang Layak Dibelanjakan?

Atur biaya kontrol dan efektivitasnya — lihat risiko residual menurun dan temukan titik di mana kontrol tambahan justru lebih mahal dari risikonya.

Peran Manajer dalam Governance Risiko Teknologi

Tanggung Jawab Langsung Manajer

Memastikan kontrak vendor memuat klausul exit & SLA jelas
Membentuk tim lintas fungsi TI-bisnis untuk tinjauan roadmap
Mengalokasikan anggaran mitigasi, bukan hanya anggaran operasional

Kolaborasi dengan Fungsi Lain

Legal: negosiasi kontrak & klausul keluar
Keuangan: hitung payback & TCO opsi teknologi
Komite risiko/direksi: laporan berkala status risiko teknologi

Manajer yang efektif memperlakukan risiko teknologi sama seriusnya dengan risiko keuangan — keduanya sama-sama dilaporkan ke direksi secara berkala.

Sebagai calon manajer, Anda perlu memahami bahwa mengelola risiko teknologi bukan tugas yang bisa dilimpahkan sepenuhnya kepada departemen TI. Tanggung jawab langsung manajer mencakup memastikan setiap kontrak dengan vendor teknologi memiliki klausul keluar dan tingkat layanan yang jelas, membentuk tim lintas fungsi yang menggabungkan sudut pandang bisnis dan teknis saat meninjau roadmap, serta mengalokasikan anggaran khusus untuk mitigasi risiko, bukan hanya anggaran operasional harian. Kolaborasi dengan fungsi lain juga krusial, tim legal untuk negosiasi kontrak, tim keuangan untuk menghitung payback period dan total cost of ownership seperti latihan yang sudah kita lakukan, serta komite risiko atau direksi yang perlu menerima laporan berkala. Perusahaan yang matang, misalnya emiten besar yang tercatat di BEI, biasanya sudah memasukkan risiko teknologi ke dalam laporan manajemen risiko tahunan mereka, sejajar dengan risiko keuangan dan operasional lainnya.

Latihan Mini & Menuju Pertemuan Terakhir

Instruksi Latihan Kelompok (15 menit)

Pilih satu perusahaan Indonesia yang Anda kenal (BUMN, startup, atau UMKM)
Identifikasi satu risiko keusangan teknologi dan satu risiko ketergantungan vendor yang mungkin dihadapi
Petakan keduanya ke matriks kemungkinan x dampak yang baru kita bahas
Usulkan satu strategi mitigasi konkret untuk masing-masing risiko

Persiapan Pertemuan 14: bawa hasil latihan ini sebagai bahan awal studi kasus terintegrasi strategi manajemen teknologi perusahaan riil.

Latihan mini ini adalah persiapan langsung untuk pertemuan terakhir semester. Silakan berkelompok dan pilih satu perusahaan Indonesia yang benar-benar Anda kenal, boleh BUMN, startup digital, atau bahkan UMKM keluarga, lalu identifikasi satu risiko keusangan teknologi dan satu risiko ketergantungan vendor yang realistis dihadapi perusahaan tersebut. Setelah itu petakan kedua risiko itu ke matriks kemungkinan dan dampak yang sudah kita pelajari, lalu usulkan satu strategi mitigasi konkret untuk masing-masing, bukan sekadar saran umum seperti "harus lebih inovatif". Simpan hasil diskusi kelompok Anda karena akan menjadi bahan awal studi kasus terintegrasi di pertemuan 14, di mana kita akan menganalisis strategi manajemen teknologi satu perusahaan riil secara menyeluruh dari awal hingga akhir semester. Sampai jumpa di pertemuan terakhir, dan Terima Kasih atas partisipasi aktif Anda sepanjang materi risiko teknologi hari ini.