MANAJEMEN RESIKO

MPPL - Manajemen Resiko

Manajemen resiko adalah proses pengukuran atau penilaian resiko serta pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek negatif resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu.

Penyebab kegagalan rekayasa perangkat lunak adalah :

-       Perencanaan yang tidak realistik, terlalu optimis dalam perhitungan.

-       Sistem pemantauan kerja yang tidak berjalan dengan seharusnya.

-       Perubahan kebutuhan.

Ada resiko yang terlihat lebih penting dari pada resiko lainnya. Baik penting atau tidaknya resiko tergantung pada resiko tersebut, pengaruhnya pada aktivitas tertentu dan kekeritisan aktivitas tersebut.  Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan resiko atau paling tidak mendistribusikan selama pengembangan.

Resiko dalam perangkat lunak memiliki dua karakteristik :

-       Uncertainty : tidak ada resiko yang 100% pasti muncul.

-       Loss : resiko berimbas pada kehilangan.

Dan resiko memiliki tiga kategori :

-       Resiko proyek : berefek pada perencanaan proyek.

-       Resiko teknikal : berefek pada kualitas dan waktu pembuatan perangkat lunak.

-       Resiko bisnis : berefek pada nilai jual produk

Identifikasi Resiko Proyek Pembuatan Sistem Informasi PT. Yonote

No	Risiko	Jenis Risiko	Kategori (check list risiko)	Usaha yang dilakukan
1	Dokumentasi tidak detail.	Risiko yang sudah diketahui	Resiko proyek	Melakukan validasi mereview ulang.
2	Waktu pengerjaan lebih lama dari yang direncanakan	Resiko yang dapat diramalkan	Resiko proyek Resiko teknikal Resiko bisnis	Memastikan milestone dilaksanakan sesuai dengan jadwalnya, jika tidak maka setiap stakeholder yang terkait harus menerima risiko agar bisa mengembalikan sesuai jadwal, seperti lembur.
3	Server tidak kuat menangani banyaknya permintaan	Risiko yang dapat diramalkan	Resiko teknikal	Melakukan peningkatan spesifikasi server dan mendistribusikan server sehingga operasi tidak dilakukan oleh satu server.
4	User Interface (UI) yang kurang user-friendly	Risiko yang dapat diramalkan	-  Risiko teknikal	Melakukan teknik validasi UI dengan prototyping, bekerja sama dengan pengguna sebagai tester.
5	Server rusak	Risiko yang tidak diharapkan	-  Resiko proyek Resiko teknikal	Back up data dari satu server ke server lain yang merupakan replikasi server utama.
6	Terjadi hal yang tidak di inginkan pada developer saat pengerjaan.	Risiko yang tidak diharapkan	-  Resiko proyek	Mengatur waktu kerja seefektif mungkin untuk menghindari kerja berlebihan dan stress

Analisa Resiko

Penentuan probabilitas terjadinya suatu event sangatlah subyektif dan lebih berdasarkan nalar dan pengalaman. Beberapa risiko memang mudah untuk diukur, namun sangatlah sulit untuk memastikan probabilitas suatu kejadian yang sangat jarang terjadi. Sehingga, pada tahap ini sangtalah penting untuk menentukan dugaan yang terbaik supaya nantinya kita dapat memprioritaskan dengan baik dalam implementasi perencanaan manajemen risiko. Kesulitan dalam pengukuran risiko adalah menentukan kemungkinan terjadi suatu risiko karena informasi statistik tidak selalu tersedia untuk beberapa risiko tertentu. Selain itu, mengevaluasi dampak severity (kerusakan) seringkali cukup sulit untuk asset immateriil. Dampak adalah efek biaya, waktu dan kualitas yang dihasilkan suatu resiko.

Dampak	Biaya	Waktu	Kualitas
Sangat rendah	Dana mencukupi	Agak menyimpang dari target	Kualitas agak berkurang namun masih dapat digunakan
Rendah	Membutuhkan dana tambahan	Agak menyimpang dari target	Gagal untuk memenuhi janji pada stakeholder
Sedang	Membutuhkan dana tambahan	Penundaan berdampak terhadap stakeholder	Beberapa fungsi tidak dapat dimanfaatkan
Tinggi	Membutuhkan dana tambahan yang signifikan	Gagal memenuhi deadline	Gagal untuk memenuhi kebutuhan banyak stakeholder
Sangat tinggi	Membutuhkan dana tambahan yang substansial	Penundaan merusak proyek	Proyek tidak efektif dan tidak berguna

Setelah mengetahui probabilitas dan dampak dari suatu resiko, maka kita dapat mengetahui potensi suatu resiko. Untuk mengukur bobot resiko kita dapat menggunakan skala dari 1 – 5 sebagai berikut :

Skala	Probabilitas	Dampak
Sangat rendah	Hampir tidak mungkin terjadi	Dampak kecil
Rendah	Kadang terjadi	Dampak kecill pada biaya, waktu dan kualitas
Sedang	Mungkin tidak terjadi	Dampak sedang pada biaya, waktu dan kualitas
Tinggi	Sangat mungkin terjadi	Dampak substansial pada biaya, waktu dan kualitas
Sangat tinggi	Hampir pasti terjadi	Mengancam kesuksesan proyek

Setelah resiko yang dapat mempengaruhi pengembangan teridentifikasi maka diperlukan cara untuk menentukan tingkat kepentingan dari masing-masing resiko. Beberapa resiko secara relatif tidak terlalu fatal (misal resiko keterlambatan penyerahan dokumentasi) sedangkan beberapa resiko lainnya berdampak besar.  (misal resiko keterlambatan penyerahan software).  Beberapa resiko sering terjadi (salah satu anggota tim sakit sehingga tidak bisa bekerja selama beberapa hari). Sementara itu resiko lainnya jarang terjadi (misal kerusakan perangkat keras yang dapat mengakibatkan sebagian program hilang).

Pengelolaan Resiko

Terdapat beberapa cara untuk mengelola resiko yaitu sebagai berikut :

1. Risk Avoidance

Yaitu memutuskan untuk tidak melakukan aktivitas yang mengandung resiko sama sekali. Dalam memutuskan untuk melakukannya, maka harus dipertimbangkan potensial keuntungan dan potensial kerugian yang dihasilkan oleh suatu aktivitas

2.    Risk Reduction

Risk reduction atau disebut juga risk mitigation yaitu merupakan metode yang mengurangi kemungkinan terjadinya suatu resiko ataupun mengurangi dampak kerusakan yang dihasilkan oleh suatu resiko.

3.    Risk Transfer

Yaitu memindahkan resiko pada pihak lain, umumnya melalui suatu kontrak (asuransi) maupun hedging.

4.    Risk Deferral

Dampak suatu resiko tidak selalu konstan. Risk deferral meliputi menunda aspek suatu proyek hingga saat dimana probabilitas terjadinya resiko tersebut kecil.

5.     Risk Retention

Walaupun resiko tertentu dapat dihilangkan dengan cara mengurangi maupun mentransfernya, namun beberapa resiko harus tetap diterima sebagai bagian penting dari aktivitas.

Penanganan resiko:

1. High probability, high impact: resiko jenis ini umumnya dihindari ataupun ditransfer.
2. Low probability, high impact: respon paling tepat untuk tipe resiko ini adalah dihindari. Dan jika masih terjadi, maka lakukan mitigasi resiko serta kembangkan contingency plan.
3. High probability, low impact: mitigasi resiko dan kembangkan contingency plan.
4. Low probability, low impact: efek dari resiko ini dapat dikurangi, namun biayanya dapat saja melebihi dampak yang dihasilkan. Dalam kasus ini mungkin lebih baik untuk menerima efek dari resiko tersebut.

Contigency plan

Untuk resiko yang mungkin terjadi maka perlu dipersiapkan contingency plan seandainya benar-benar terjadi. Contigency plan haruslah sesuai dengan proposional terhadap dampak resiko tersebut. Dalam banyak kasus seringkali lebih efisien untuk mengalokasikan sejumlah sumber daya untuk mengurangi resiko dibandingkan mengembangkan contingency plan yang jika diimplementasikan akan lebih mahal. Namun beberapa skenario memang membutuhkan full contingency plan, tergantung pada proyeknya. Namun jangan sampai tertukar antaracontingency planning dengan re-planning normal yang memang dibutuhkan karena adanya perubahan dalam proyek yang berjalan.

Tabel resiko proyek software dan strategi mengurangi resiko :

Resiko	Teknik mengurangi resiko
Kegagalan pada personil	·        Memperkerjakan staf yang handal ·        Job matching ·        Membangun tim ·        Mengadakan pelatihan dan peningkatan karir ·        Membuat jadwal lebih awal bagi personil utama
Estimasi biaya dan waktu yang tidak realistis	·   Membuat beberapa estimasi ·   Desain untuk biaya ·   Meningkatkan pengembangan ·   Merekam dan menganalisa proyek sebelumnya ·   Standarisasi metode
Mengembangkan fungsi software yang salah	·   Evaluasi proyek ditingkatkan ·   Buat metode spesifikasi yang formal ·   Survey pengguna ·   Buat prototype ·   Buat user manual lebih awal
Mengembangkan antarmuka pengguna yang salah	·   Membuat prototype ·   Analisis tugas ·   Keterlibatan pengguna
Gold plating	·   Mengurangi kebutuhan ·   Membuat prototype ·   Analisis biaya manfaat ·   Desain biaya
Terlambat untuk mengubah kebutuhan	·   Mengubah prosedur kendali ·   Membatasi perubahan yang terlalu banyak ·   Meningkatkan prototype ·   Meningkatkan pengembangan (akibat perubahan)
Kegagalan pada komponen yang disuplai pihak eksternal	·   Melakukan benchmarking ·   Inspeksi ·   Spesifikasi formal ·   Kontrak perjanjian ·   Prosedur dan sertifikasi jaminan kualitas
Kegagalan menjalankan tugas eksternal	·   Prosedur jaminan kualitas ·   Desain / prototype yang kompetitif ·   Membangun tim ·   Kontrak insentif
Kegagalan kinerja real-time	·   Simulasi ·   Benchmarking ·   Prototipe ·   Tuning ·   Analisis teknis
Pengembangnya terlalu sulit secara teknis	·   Analisa teknis ·   Analisis biaya manfaat ·   Prototipe ·   Melatih dan mengembangkan staf

Daftar Resiko

No	Rank	Risk	Category	Root Cause	Risk Owner	Status
R5	1	Server rusak	Resiko Teknologi	Server	Stakeholder	Active
R1	2	Dokumentasi yang tidak mendetail	Struktur/Proses risiko	Developer	Developer	Active
R3	3	Waktu pengerjaan yang lebih lama dibandingkan dengan rencana pengerjaan	Struktur/Proses risiko	Developer	Developer	Active

Mitigasi

No	Risk	Risiko	Anti-Risk
1	Risk 1	Dokumentasi yang tidak mendetail	-     Melakukan penggalian kebutuhan secara maksimal -     Analisis scope lebih diperdalam -     Melakukan pengecekan dokumen secara berkala
2	Risk 2	Waktu pengerjaan yang lebih lama dibandingkan dengan rencana pengerjaan	-      Pengecekan milestone secara teratur sesuai dengantimelinenya -      Peningkatan otoritas project manager -      Peningkatan frekuensi pemantauan project -      Pemilihan project manager yang paling berpengalaman -      Meningkatkan komunikasi dan pemahaman project goals -      Peningkatan penanganan masalah dan komunikasi antar
3	Risk 3	Server tidak kuat menangani banyak pengguna	-      Memperkirakan jumlah pengguna yang akan mengakses -      Melakukan proses dengan beberapa server replikasi sehingga operasi tidak dilakukan oleh satu server saja
4	Risk 4	Desain UI yang kurang user-friendly	-      Melakukan evaluasi secara berkala ke stakeholder -      Sistem Analyst mengecek secara berkala sudahkah sesuai atau mdah digunakan oleh stakeholder
5	Risk 5	Server rusak	-      Back up data dari satu server ke server lain yang merupakan replikasi server utama
6	Risk 6	Developer sakit pada saat pengerjaan proyek	-      Peningkatan otoritas project manager -      Pengaturan waktu seefektif mungkin

Share :

Tweet

✚

Related Post