Sistem Informasi Manajemen Risiko BUMN Berbasis Aplikasi sesuai PER-2/MBU/03/2023

RB 12 Desember 2025

BUMN punya dua pekerjaan sekaligus. BUMN perlu lincah mengejar target bisnis, tapi BUMN juga harus rapi menjaga tata kelola. Di titik ini, manajemen risiko bukan dokumen yang mengisi lemari, melainkan cara berpikir yang menempel ke keputusan harian.

PER-2/MBU/03/2023 mendorong arah yang jelas: BUMN perlu menjalankan manajemen risiko secara efektif, lengkap dari hulu ke hilir, dan BUMN perlu menopang proses itu dengan sistem informasi. Artinya sederhana tapi konsekuensinya besar. Kalau risiko masih hidup di spreadsheet berbeda-beda, organisasi akan sulit melihat gambaran utuh, sulit menjaga konsistensi, dan sulit membuktikan jejak keputusan ketika auditor atau pimpinan bertanya.

Artikel ini membahas cara menerjemahkan amanat tersebut menjadi desain aplikasi yang masuk akal untuk BUMN. Fokusnya edukatif. Kita bicara alur, data, dan kebiasaan kerja yang membuat sistem informasi manajemen risiko benar-benar kepakai, bukan sekadar “ada”.

Mengapa PER-2/MBU/03/2023 Menuntut Manajemen Risiko yang “Bisa Dibuktikan”

Regulasi ini tidak berhenti pada kalimat “BUMN harus punya manajemen risiko”. Regulasi juga menegaskan elemen yang membuat manajemen risiko terasa nyata: pengurusan aktif oleh Direksi dan pengawasan oleh Dewan Komisaris atau Dewan Pengawas, kecukupan kebijakan dan standar prosedur, kecukupan proses dari identifikasi sampai pelaporan yang berjalan konsisten, termasuk dukungan sistem informasi, serta sistem pengendalian intern yang menyeluruh.

Kalau kita tarik maknanya ke praktik, regulasi menagih bukti kerja, bukan sekadar niat baik. Organisasi perlu menunjukkan bahwa risiko punya pemilik, risiko punya perlakuan, dan manajemen memantau risiko secara teratur. Aplikasi membantu membentuk bukti itu karena aplikasi mengikat proses ke data.

Di sisi lain, regulator tidak meminta BUMN membangun sistem mewah. Regulator meminta BUMN membangun sistem yang membuat proses berjalan. Jadi, kuncinya bukan fitur sebanyak mungkin. Kuncinya mengurangi “ruang gelap” yang biasanya muncul di manajemen risiko, seperti perbedaan definisi, hilangnya jejak persetujuan, atau laporan yang datang terlambat.

Apa yang Dimaksud “Sistem Informasi Manajemen Risiko” dalam Praktik BUMN

Banyak organisasi menafsirkan sistem informasi manajemen risiko sebagai portal untuk input risk register. Itu baru separuh cerita. PER-2/MBU/03/2023 mendorong sistem yang sanggup memberi informasi yang akurat dan tepat waktu, lalu menghasilkan pelaporan yang memenuhi kebutuhan manajemen.

Dalam perspektif proses, sistem informasi manajemen risiko harus memfasilitasi perjalanan risiko dari “sinyal” menjadi “keputusan”. Perjalanan itu biasanya dimulai dari unit kerja yang mengenali risiko, kemudian fungsi manajemen risiko memastikan metodologi berjalan konsisten, lalu pimpinan menerima ringkasan yang jelas untuk menentukan arah. Sistem tidak perlu menggantikan diskusi. Sistem perlu menyiapkan panggung agar diskusi selalu memakai data yang sama.

Ada dua poin penting yang sering luput.

Pertama, peraturan juga memandatkan kebijakan manajemen risiko yang memuat, antara lain, risk appetite, risk tolerance, risk limit, serta taksonomi risiko. Sistem informasi harus siap menampung itu. Tanpa risk appetite dan batasannya, dashboard akan kehilangan “angka pembanding”. Risiko terlihat, tetapi organisasi tidak punya kompas untuk menilai apakah risiko masih wajar atau sudah melewati ambang.

Kedua, peraturan mendorong integrasi. Banyak BUMN beroperasi sebagai grup, memiliki anak dan cucu perusahaan, serta punya variasi proses. Sistem informasi yang baik harus memberi ruang untuk kebutuhan masing-masing entitas tanpa mengorbankan standar data. Kalau sistem tidak bisa menyatukan istilah dan struktur laporan, pimpinan grup akan kesulitan membaca portofolio risiko.

Untuk melihat gambaran praktis tentang digitalisasi tata kelola risiko lintas entitas, Anda bisa membaca konteks penerapannya di aplikasi manajemen risiko perusahaan. Di artikel ini, kita fokus pada “cara merancang” agar amanat regulasi berubah menjadi desain aplikasi yang bisa hidup.

Dari Tata Kelola ke Layar Aplikasi: Menyatukan Peran, Data, dan Ritme Kerja

Sistem informasi manajemen risiko selalu berdiri di atas tiga hal: peran, data, dan ritme.

Peran menjawab pertanyaan “siapa melakukan apa”. PER-2/MBU/03/2023 juga mengenal model tata kelola risiko tiga lini. Lini pertama berada di unit pemilik risiko yang menjalankan proses bisnis dan mengelola risiko harian. Lini kedua berada di fungsi manajemen risiko dan kepatuhan yang menjaga metodologi, memantau secara agregat, dan menyiapkan bahan laporan. Lini ketiga berada pada audit intern yang memastikan tata kelola dan pengendalian risiko berjalan efektif.

Data menjawab pertanyaan “kita menilai risiko memakai bahasa apa”. Tanpa taksonomi yang jelas, risk register akan berubah menjadi catatan bebas. Satu unit menulis “risiko operasional”, unit lain menulis “operational issue”, lalu dashboard menampilkan angka yang sulit dibandingkan.

Ritme menjawab pertanyaan “kapan organisasi bergerak”. Banyak sistem gagal bukan karena desain modulnya, tapi karena organisasi tidak mengunci ritme. Risk owner lupa meng-update, fungsi manajemen risiko menunggu, lalu laporan ke Direksi terasa mendadak. Aplikasi yang baik harus membantu ritme, misalnya lewat jadwal siklus penilaian, pengingat, dan status yang terlihat.

Contoh Desain Aplikasi: “Seperti Poster” yang Mudah Dibayangkan

Bayangkan aplikasi ini sebagai ruang kerja bersama yang memecah manajemen risiko menjadi tiga layar besar.

Layar pertama adalah beranda eksekutif. Beranda ini menampilkan peta risiko yang ringkas, tren status mitigasi, serta ringkasan KRI dalam format yang cepat dibaca. Di bagian atas, aplikasi menampilkan daftar risiko yang melewati ambang risk limit atau mendekati risk appetite. Di bagian tengah, aplikasi menunjukkan perubahan profil risiko dibanding periode sebelumnya. Di bagian bawah, aplikasi menampilkan daftar aksi mitigasi yang jatuh tempo.

Layar kedua adalah ruang kerja risk owner. Di layar ini, risk owner membuat dan memperbarui risiko. Aplikasi membantu risk owner mencatat konteks risiko, penyebab, dampak, kontrol yang sudah ada, serta rencana perlakuan. Aplikasi juga memandu risk owner memilih kategori sesuai taksonomi sehingga organisasi menjaga konsistensi.

Layar ketiga adalah ruang kerja fungsi manajemen risiko. Di sini, tim manajemen risiko memeriksa kualitas input, menjaga metodologi, dan mengelola konsolidasi untuk laporan. Sistem bisa menampilkan daftar risiko dengan data yang belum lengkap, perubahan skor yang tidak wajar, atau risiko yang menunggu validasi.

Tiga layar itu terlihat sederhana, tetapi di belakangnya ada prinsip desain yang penting.

Aplikasi perlu menyimpan jejak keputusan. Ketika risk owner mengubah skor risiko, sistem mencatat siapa mengubah, kapan, dan alasan singkatnya. Ketika atasan menyetujui perlakuan risiko, sistem menyimpan persetujuan itu sebagai bagian dari audit trail.

Aplikasi perlu mengunci definisi. Risk appetite, risk tolerance, dan risk limit tidak harus selalu berbentuk angka kompleks. Namun, sistem perlu menyimpan definisi dan ambang yang organisasi sepakati, lalu sistem perlu memakai definisi itu saat menampilkan status. Tanpa itu, lampu “merah-kuning-hijau” hanya jadi hiasan.

Aplikasi perlu menautkan risiko ke aksi. Risk register yang rapi pun tidak membantu kalau aksi mitigasi tidak jelas. Desain aplikasi harus menghubungkan risiko ke rencana kerja, PIC, target waktu, serta bukti pelaksanaan yang sederhana.

Data “Wajib” yang Membuat Sistem Terasa Berguna

Kebanyakan organisasi mencoba memasukkan terlalu banyak data sejak hari pertama. Hasilnya, pengguna lelah, lalu sistem berhenti.

Lebih aman jika organisasi menetapkan data minimum yang selalu hadir di setiap risiko. Data minimum itu sebaiknya sudah cukup untuk menampilkan eksposur risiko secara konsisten, menampilkan penyebab dan dampak secara jelas, serta mengaitkan indikator atau sinyal dini yang organisasi pantau.

Pada level grup, aplikasi juga harus mampu menyajikan agregasi. Sistem harus bisa menjawab pertanyaan sederhana: risiko mana yang paling memengaruhi tujuan strategis, unit mana yang paling sering terlambat menutup mitigasi, dan indikator apa yang mulai bergerak ke arah tidak sehat.

Saat tim ingin menguatkan pemantauan, organisasi bisa mengembangkan modul KRI dan early warning. Anda bisa mengaitkan kebutuhan itu dengan desain Risk Dashboard yang menekankan visualisasi, monitoring, dan profiling risiko.

Satu Contoh Siklus: Dari Temuan Unit Kerja sampai Eskalasi ke Pimpinan

Misalkan sebuah unit operasional melihat pola keterlambatan pengadaan material yang mulai mengganggu target produksi. Risk owner membuka aplikasi, lalu risk owner mencatat risikonya, memilih kategori sesuai taksonomi, dan menuliskan penyebab yang paling masuk akal dalam konteks unitnya.

Aplikasi meminta risk owner menentukan tingkat dampak sesuai kriteria yang perusahaan pakai. Risk owner kemudian menilai kemungkinan terjadinya, lalu sistem menampilkan tingkat risiko awal.

Fungsi manajemen risiko menerima notifikasi bahwa ada risiko baru. Tim memeriksa apakah deskripsi sudah jelas, apakah kategori sudah tepat, dan apakah penilaian mengikuti metodologi. Ketika tim melihat perbedaan tafsir, tim mengarahkan revisi, bukan menghukum.

Risk owner lalu menyusun perlakuan risiko. Risk owner memilih aksi yang realistis, menetapkan PIC, dan menetapkan target waktu. Ketika target melewati tenggat, sistem menyalakan peringatan, lalu sistem meminta risk owner memberi alasan serta rencana tindak lanjut.

Di beranda eksekutif, Direksi melihat risiko tersebut muncul sebagai risiko yang mendekati ambang, terutama jika indikator pendukung ikut naik. Direksi tidak perlu membaca detail yang panjang. Direksi cukup melihat ringkasan, tren, dan status mitigasi. Ketika risiko menembus batas, Direksi dapat meminta eskalasi dan memutuskan perubahan prioritas.

Siklus ini terlihat “biasa”, tetapi sistem membuat dua hal penting: organisasi menjaga konsistensi penilaian, dan organisasi punya bukti yang rapi tentang siapa mengambil tindakan apa.

Implementasi di BUMN: Tahap Demi Tahap Tanpa Membebani Pengguna

Banyak proyek aplikasi manajemen risiko gagal karena tim langsung melompat ke pengembangan fitur. Padahal, tahap paling menentukan justru tahap penyelarasan.

Pada kick-off, tim perlu menyelaraskan mandat PER-2/MBU/03/2023 dengan kondisi internal. Tim perlu menyepakati ruang lingkup awal, misalnya mulai dari risk register dan monitoring, lalu berkembang ke KRI, dashboard, dan integrasi.

Setelah itu, tim menyusun kebutuhan pengguna melalui URS atau BRD. Pada tahap ini, tim sebaiknya tidak memburu daftar fitur. Tim sebaiknya memburu alur kerja: siapa input, siapa review, siapa setuju, kapan organisasi memantau, dan format apa yang pimpinan butuhkan.

Tahap pengembangan sebaiknya berjalan iteratif. Tim membangun modul inti terlebih dahulu, lalu tim menguji bersama pengguna kunci. Tim tidak perlu menunggu semua sempurna untuk meminta masukan.

Tahap UAT berjalan seperti simulasi operasi, bukan sekadar “cek tombol”. Tim menguji kasus nyata, menguji eskalasi, menguji pelaporan, dan menguji audit trail. Di tahap ini, tim biasanya menemukan kebutuhan kecil yang dampaknya besar, seperti definisi status, log perubahan, dan cara sistem menampilkan tren.

Saat go-live, organisasi perlu menyiapkan ritme kerja. Risiko akan hidup kalau organisasi menetapkan siklus review, menetapkan jadwal update, dan menetapkan siapa yang menutup tindakan mitigasi.

Training tidak perlu terasa seperti kelas panjang. Training bisa terasa seperti onboarding aplikasi kerja: pengguna belajar mengisi satu risiko, pengguna belajar memperbarui satu aksi, pengguna belajar membaca satu dashboard. Setelah itu, pengguna akan belajar sisanya sambil bekerja.

Mengapa Sistem Bisa Gagal Walau Aplikasinya Bagus

Kegagalan paling sering muncul dari tiga sumber.

Sumber pertama adalah definisi yang tidak seragam. Jika unit memakai kriteria dampak berbeda, maka angka di dashboard akan menipu. Solusinya bukan menambah fitur, melainkan menegaskan kriteria dan menanamkannya ke sistem.

Sumber kedua adalah taksonomi yang tidak dipakai. Organisasi sering punya taksonomi di dokumen, tetapi pengguna tidak merasa taksonomi membantu. Desain aplikasi perlu memudahkan pemilihan kategori, serta memberi contoh yang sederhana.

Sumber ketiga adalah ritme yang longgar. Aplikasi akan sepi kalau organisasi tidak mengunci siklus. Pengingat otomatis membantu, tetapi pimpinan perlu menegaskan bahwa update risiko menjadi bagian dari kerja, bukan kerja tambahan.

Menutup Lingkaran: SIMR, Pengendalian Intern, dan Uji Berkala

Regulasi menempatkan sistem informasi manajemen risiko sebagai bagian dari tata kelola dan pengendalian intern. Itu berarti organisasi tidak cukup “punya aplikasi”. Organisasi perlu memastikan sistem tetap relevan, tetap akurat, dan tetap aman.

Aplikasi perlu mendukung pengujian, misalnya lewat jejak audit, pelaporan perubahan, serta kemampuan meninjau efektifitas pengendalian dari waktu ke waktu. Ketika organisasi melakukan evaluasi pengendalian intern, sistem informasi manajemen risiko akan ikut masuk dalam ruang lingkup, karena sistem ini menyuplai data untuk keputusan.

Jika Anda ingin melihat ringkasan regulasinya dari perspektif praktik, Anda bisa meninjau halaman PER-2/MBU/03/2023 sebagai pengantar.

Penutup

Sistem informasi manajemen risiko BUMN tidak perlu rumit untuk terasa kuat. Sistem perlu membuat proses berjalan, menyatukan bahasa data, dan mengunci ritme kerja. Ketika desain aplikasi mengikuti amanat PER-2/MBU/03/2023, organisasi bisa memindahkan manajemen risiko dari “dokumen tahunan” menjadi “alat navigasi” yang hidup.

Mulailah dari modul inti yang paling berguna, lalu kembangkan secara bertahap. Dengan pendekatan ini, BUMN tidak sekadar memenuhi regulasi, tetapi juga membangun kebiasaan pengambilan keputusan yang lebih tenang karena organisasi melihat risiko dengan lebih jelas.

Related posts

Pengertian SK8 dalam PERMEN 02 BUMN IT Maturity: Penilaian Tata Kelola TI BUMN Indonesia Hak Asasi Manusia & Ketenagakerjaan dalam ESG