Penilaian Risiko dan Mitigasi E-Government

Bab-bab sebelumnya telah menyajikan serangkaian langkah dan teknik yang dirancang
untuk membantu membangun sistem e-government yang sehat. Namun, fakta yang tidak
menyenangkan adalah bahwa sebagian besar proyek e-government gagal dalam beberapa hal,
seperti yang telah disebutkan dalam Bab 1. Oleh karena itu, sangat masuk akal apabila
melakukan semacam penilaian risiko dan mitigasi dalam siklus hidup sistem e-government
apabila hal tersebut diperlukan.

Secara umum, kami dapat mengajukan pertanyaan berikut tentang penilaian risiko dan
mitigasi:

• Mengapa? Tujuan dari manajemen risiko adalah untuk menghentikan kegagalan proyek e-
government.

• Kapan? Dengan asumsi kehidupan proyek yang khas- siklus penilaian - analisis - desain -
konstruksi - implementasi, maka biasanya Anda akan melakukan penilaian risiko yang cepat
dan kotor selama tahap penilaian, dan penilaian yang lebih rinci selama tahap analisis. Kegiatan
mitigasi risiko dapat terjadi pada titik mana pun, meskipun mungkin secara khusus difokuskan
pada analisis dan desain. Ini adalah diringkas dalam Gambar 10.1, menunjukkan bahwa bab ini
memecah pola tahap demi tahap Bab 7–9. Secara umum, semakin awal Anda menilai risiko,
semakin sulit untuk mengetahui risiko secara akurat. Tetapi semakin Anda menilai risiko,
semakin sulit melakukan apa pun tentang risiko yang diidentifikasi.

• Siapa? Tim kecil yang terdiri dari campuran pemangku kepentingan yang berbeda
adalah unit terbaik untuk menilai risiko. Semakin sedikit orang yang terlibat, semakin besar
kemungkinan Anda melewatkan risiko penting. Semakin banyak orang yang terlibat, semakin
tinggi waktu dan biaya finansial serta biaya latihan lainnya.

• Bagaimana? Sisa dari bab ini diambil dengan menjawab pertanyaan ini, dengan fokus pada
gagasan kesenjangan desain-realitas.
 penilaian
proyek

Pelaksanaan dan Analisis realitas

seterusnya saat ini

Desain dari
sistem
sistem baru
konstruksi
yang diusulkan

Figure 10.1 The place of risk assessment and mitigation in the e-government system lifecycle

10.1 PENILAIAN RISIKO MELALUI ANALISA GAP

Tidak mudah untuk menganalisis kesenjangan antara realitas saat ini dan asumsi desain dan
persyaratan sistem e-government baru yang diusulkan. Tidak ada aturan keras dan cepat yang
mengatakan 'celah ini baik-baik saja' atau 'celah ini terlalu besar'. Setiap penilaian kesenjangan
- dan, karenanya, risiko proyek - karenanya harus subjektif, dan didasarkan pada pendapat dan
pengalaman. Jika seseorang menerima subjektivitas ini, maka skala penilaian dapat digunakan,
seperti yang dijelaskan di bawah ini:

1 Dengan menggunakan masing-masing dari tujuh dimensi ITPOSMO, menganalisis dua hal.
Pertama, realitas organisasi yang berkaitan dengan dimensi yang ada saat ini pada saat analisis.
Kedua, konsepsi / persyaratan dalam desain aplikasi e-government.

2 Untuk masing-masing dimensi, berikan peringkat numerik untuk menunjukkan ukuran

kesenjangan desain-realitas pada dimensi itu. Peringkat untuk setiap celah dimensi dapat
berada di mana saja pada skala dari nol hingga sepuluh. Sebagai panduan, ilustrasi hanya
diberikan di sini untuk kesenjangan yang sesuai dengan peringkat nol, lima dan sepuluh, tetapi
semuanya angka dalam kisaran dimungkinkan. Peringkat ilustrasi:
Peringkat O 0 akan menunjukkan tidak ada perubahan antara proposal desain dan kenyataan
saat ini;

Peringkat O 5 akan mengindikasikan beberapa tingkat perubahan antara proposal desain dan
kenyataan saat ini;

Peringkat O10 akan menunjukkan perubahan yang lengkap dan radikal antara proposal desain
dan kenyataan saat ini.

3 Jadi, misalnya, mengambil dimensi pertama - informasi - 0 akan menunjukkan bahwa

informasi yang digunakan dalam aplikasi e-government persis sama dengan informasi yang
saat ini benar-benar digunakan. Peringkat 5 akan menunjukkan bahwa informasi yang
digunakan dalam aplikasi e-government agak berbeda dari informasi yang saat ini benar-benar
digunakan. Peringkat 10 akan menunjukkan bahwa informasi yang digunakan dalam aplikasi
e-government sama sekali dan sangat berbeda dari informasi yang saat ini benar-benar
digunakan. Peringkat ini akan dilakukan dengan membandingkan analisis informasi dari
kenyataan (lihat Bab 8) dengan desain informasi baru (lihat Bab 9).

Enam dimensi lain yang akan dinilai dari 0 hingga 10 adalah:

O teknologi yang digunakan oleh agensi dan klien (membandingkan persyaratan yang
terkandung dalam desain aplikasi e-government versus situasi nyata yang sekarang
diidentifikasi oleh audit sistem informasi (IS));

O proses kerja yang dilakukan dalam sistem agensi-klien (membandingkan proses yang
diperlukan untuk implementasi yang berhasil dari aplikasi e-government versus situasi nyata
sekarang);

O tujuan dan nilai-nilai yang diperlukan oleh para pemangku kepentingan utama untuk
keberhasilan implementasi aplikasi e-government versus tujuan dan nilai nyata mereka saat ini
(data ini akan diproduksi dengan membandingkan tujuan sistem baru dan imbalan / nilai-nilai
manusia baru desain sistem dengan tujuan dan nilai yang muncul dari analisis orang
sebelumnya);

O jumlah staf dan tingkat / tipe keterampilan yang dibutuhkan oleh agensi dan klien
(membandingkan persyaratan untuk keberhasilan implementasi aplikasi e-government yang
diidentifikasi oleh desain sistem manusia baru versus situasi nyata yang sekarang diidentifikasi
dalam audit IS) ;
O sistem dan struktur manajemen yang diperlukan dalam agensi (membandingkan persyaratan
untuk keberhasilan implementasi aplikasi e-government yang diidentifikasi oleh desain sistem
manusia yang baru versus situasi nyata yang sekarang diidentifikasi dalam audit IS);

O waktu dan uang yang dibutuhkan untuk mengimplementasikan dan mengoperasikan aplikasi
baru dengan sukses dibandingkan dengan waktu dan uang yang benar-benar tersedia sekarang.

Di mana diagram telah digunakan - misalnya, peta proses dari proses saat ini dan satu untuk
proses baru - mereka dapat mendukung perbandingan ini.

4 Hal paling sederhana dan paling kasar yang harus dilakukan sekarang adalah menjumlahkan
angka peringkat untuk ketujuh dimensi ITPOSMO dan menafsirkannya sesuai Tabel 10.1.

Pendekatan yang sedikit lebih terperinci adalah menyajikan skor untuk setiap dimensi individu
menggunakan tabel atau diagram yang disusun untuk menunjukkan kesenjangan dalam urutan
ukuran dari yang terbesar hingga yang terkecil. Dimensi dengan celah terbesar adalah dimensi
itu

Table 10.1 Risk Ratings and Outcomes for eGovernment Projects

Overall rating Likely outcome

57–70 The e-government project will almost certainly fail unless action is taken to close design–
reality gaps.

43–56 The e-government project may well fail unless action is taken to close design–reality gaps 29–42
The e-government might fail totally, or might well be a partial failure unless

action is taken to close design–reality gaps

15–28 The e-government project might be a partial failure unless action is taken to close design–
reality gaps

0–14 The e-government project may well succeed

harus diprioritaskan untuk tindakan jika risiko kegagalan perlu ditangani. Gagasan tentang
tindakan yang akan diambil dibahas di bawah ini.

Ketujuh skala penilaian ini dapat digunakan oleh satu individu, seperti konsultan proyek atau
manajer proyek, untuk membantu mereka dengan pemahaman dan rekomendasi mereka
sendiri. Atau, pendekatan yang lebih partisipatif dapat digunakan. Tujuh skala ini dapat
dipresentasikan kepada sekelompok pemangku kepentingan proyek utama (baik internal
maupun eksternal) di bengkel kerja yang difasilitasi. Para pemangku kepentingan
mendiskusikan dan menilai setiap dimensi. Kesenjangan desain-realitas utama yang
bermasalah diidentifikasi. Lokakarya kemudian bergerak untuk mencari cara terbaik untuk
menutup celah-celah itu. Ini mencerminkan pendekatan metode 'sistem lunak' (Bell dan Wood-
Harper, 2003). Ini sering menganjurkan pengakuan kesenjangan sebagai perubahan potensial,
yang kemudian dapat didiskusikan dalam forum partisipatif untuk mengidentifikasi mereka
yang diinginkan dan layak.

Kesenjangan desain-realitas dapat dianggap sebagai kendala atau risiko terhadap implementasi
proyek e-government: mereka memberikan gambaran tentang apa yang mungkin membuat
proyek gagal. Mereka mungkin tidak memberikan pengertian yang baik tentang apa yang
mungkin membuat proyek berhasil: driver. Driver dapat dianalisis juga, dan diilustrasikan
bersama

sisi kesenjangan / kendala / risiko menggunakan diagram medan gaya dengan driver di satu sisi
dan kendala di sisi lain. Penggerak yang kuat dapat mendorong suatu proyek ke depan
meskipun risiko / kendala (yaitu kesenjangan desain-realitas) sangat besar. Tetapi proyek
dengan driver yang lemah mungkin tergelincir oleh kesenjangan desain-kenyataan yang sangat
kecil.

Secara keseluruhan, teknik ini relatif sederhana dan cepat untuk dipahami dan dipraktikkan.
Satu keuntungan utama adalah cocok dengan situasi unik dari setiap proyek e-government
individu, daripada memaksakan konsep 'satu ukuran cocok untuk semua'.

Pada sisi negatifnya, teknik analisis kesenjangan ini mencoba menjejalkan banyak masalah ke
dalam setiap dimensi tunggal (terutama ke 'tujuan dan nilai' dan 'staf dan keterampilan'), dan
itu tidak akan berfungsi dengan baik jika ada perusahaan desain peting atau ide-ide yang
bersaing tentang apa yang dianggap sebagai 'kenyataan' (misalnya antara staf internal dan klien
eksternal). Juga tidak membuat penilaian nilai tentang realitas saat ini: kenyataan itu mungkin
sangat disfungsi, bahkan mungkin korup, sehingga Anda mungkin menginginkan desain e-
government yang sangat berbeda dari kenyataan saat ini. Tetapi analisis kesenjangan desain-
realitas hanya memberi tahu Anda tentang risiko perubahan, bukan manfaatnya (lihat juga poin
di bawah ini tentang proyek-proyek yang berisiko tinggi dan menguntungkan).