9 2.1 Teknologi Informasi
Menurut Schwalbe (2010, p53), proyek teknologi informasi tidak seperti proyek di industri lainnya, karena proyek teknologi informasi dapat menjadi sangat berbeda, dimana beberapa membutuhkan jumlah orang yang sedikit dalam memasang perangkat keras dan perangkat lunak yang dibutuhkan, namun juga ada beberapa yang membutuhkan jumlah orang yang banyak dalam menganalisis beberapa proses bisnis dari banyak organisasi untuk mengembangkan suatu perangkat lunak untuk memenuhi kebutuhan bisnisnya.
Jadi dapat disimpulkan teknologi informasi sebagai perangkat keras, perangkat lunak, jaringan telekomunikasi, manajemen database informasi yang digunakan di dalam sistem berbasis komputer.
2.1.1 Sistem
Dalam sebuah teknologi informasi terdapat berbagai sistem yang digunakan untuk menunjang kebutuhan perusahaan dalam menjalankan proses bisnis yang akan dilakukan.
Menurut Schwalbe (2010, p45), sistem adalah komponen yang saling berinteraksi dalam mengerjakan sesuatu dalam suatu lingkungan untuk tujuan tertentu.
Menurut Stair & Reynolds (2010), data terdiri dari bukti baku, seperti nomor pegawai, jumlah waktu bekerja selama seminggu, nomor inventori, atau sales order. Beberapa tipe data dapat mewakili bukti. Ketika bukti disusun secara bermakna, maka data tersebut dapat menjadi informasi.
Tipe – Tipe data :
Data Diwakilkan dengan
Data Alphanumeric Angka, huruf, dan karakter lainnya. Data Image graphic image and pictures.
Data Audio Suara, nada.
Data Video Gambar yang bergerak atau pictures.
2.1.3 System Development Life Cycle(SDLC)
Menurut Stair & Reynolds (2010, p496), pengembangan sistem disebut siklus hidup pengembangan sistem karena terkait dengan aktivitas yang sedang berlangsung. Setiap sistem yang dibuat merupakan bagian dari pengerjaan proyek sedangkan proyek itu sendiri memiliki batas waktu, mulai dari saat sistem tersebut diimplementasikan sampai sistem tersebut diterima. Sistem yang sedang berjalan akan dipelihara dan ditinjau.
Jika sistem membutuhkan pengembangan secara signifikan diluar ruang lingkup pemeliharaan, maka sistem tersebut akan diganti, karena munculnya teknologi baru organisasi membutuhkan perubahan secara signifikan, yang akan mendukung pada saat proses pengerjaan proyek baru dalam memenuhi semua aspek siklus yang ada dalam proyek tersebut.
Menurut Stair & Reynolds (2010, p496), Terkadang mempelajari informasi dalam fase tertentu membutuhkan perulangan ke fase sebelumnya. Siklus Hidup Pengembangan Sistem terdiri dari 5 aktivitas :
1. Melakukan investigasi terhadap sistem
Tahap pengembangan sistem, yang memiliki potensi masalah, peluang teridentifikasi dan dipertimbangkan mengingat tujuan bisnis. Hasil utama dari tahap ini adalah penetapan pengembangan proyek untuk permasalahan dalam bisnis atau peluang yang telah dibuat.
2. Melakukan analisis sistem
Tahap pengembangan sistem yang melibatkan tentang pembelajaran sistem yang ada dan proses kerja untuk mengidentifikasi kekuatan, kelemahan dan peluang yang akan digunakan untuk dikembangkan. Hasil dari tahap ini adalah daftar yang dibutuhkan dan hal yang diprioritaskan.
3. Melakukan desain sistem
Hasil utama dalam tahap ini adalah rancangan teknis yang salah satunya menggambarkan sistem baru atau menjelaskan bagaimana sistem yang sudah ada akan dirubah. Rincian dalam desain sistem terdapat sistem output, input, dan tampilan pengguna. Menetapkan perangkat keras, perangkat lunak, database, telekomunikasi, perorangan, dan prosedur komponen dan bagaimana masing – masing komponen terkait.
Dalam tahap pengembangan ini, meliputi pembuatan atau memperoleh komponen secara rinci dari berbagai sistem dalam sistem desain, menjalankan, dan melakukan pemasangan sistem baru atau diubah sesuai dalam operasi.Tugas yang paling penting adalah untuk melatih pengguna. Hasil dari sistem implementasi ini adalah penginstalan sistem informasi operasi yang memenuhi kebutuhan bisnis untuk mengembangkan bisnis.
5. Melakukan pemeliharaan dan peninjauan terhadap sistem
Tahap pengembangan sistem yang memastikan bahwa sistem beroperasi, dan untuk memodifikasi sistem, dan berjalan terus menerus untuk memenuhi kebutuhan bisnis yang selalu berubah.
Gambar 2.1 Fase – Fase Siklus SDLC (Sumber : Principles Of Information System, 2010)
2.1.3.2 Keuntungan Dan Kerugian Dari System Development Life Cycle
Menurut Stair & Reynolds (2010, p496), keuntungan dan kerugian dari System Development Life Cycle (SDLC) adalah :
a. Keuntungan :
1. Dilakukan peninjauan pada setiap akhir tahap dapat memaksimalkan kontrol manajemen.
2. Dengan melakukan pendekatan ini dapat menghasilkan kelengkapan dalam dokumentasi sistem.
SYSTEMS MAINTENANCE AND REVIEW Evaluate result of solution SYSTEMS IMPLEMENTATION
Place solution info effect SYSTEMS DESIGN Select and plan best solution
SYSTEM ANALYSIS Understand solution SYSTEM INVESTIGATION
3. Dokumentasi yang dilakukan secara formal dapat memastikan persyaratan sistem dapat ditelusuri kembali sesuai dengan kebutuhan bisnis.
4. Membuat beberapa produk setengah jadi yang masih dapat ditinjau kembali untuk melihat apakah memenuhi kebutuhan pengguna dan sesuai dengan standar.
b. Kerugian :
1. Pengguna mendapat sistem yang dapat memenuhi kebutuhan yang dipahami oleh pengembang, tapi mungkin tidak benar – benar sesuai dengan yang sebenarnya dibutuhkan.
2. Dokumentasi membutuhkan biaya yang cukup mahal dan memakan waktu yang cukup lama. Dan akan mengalami kesulitan untuk menjaga dokumentasi ini.
3. kebutuhan pengguna sering tidak tertulis atau disalahpahami.
4. Pengguna tidak mudah melakukan tinjauan terhadap produk setengah jadi dan mengevaluasi produk tersebut untuk memenuhi kebutuhan bisnis.
2.2 Proyek
Menurut Schwalbe (2010, p4), proyek adalah melakukan sesuatu untuk menciptakan produk atau jasa yang unik. Dan juga untuk pemenuhan pekerjaan dari organisasi untuk mempertahankan bisnis.
Menurut Insitute (2008, p35), proyek adalah usaha sementara yang dilakukan untuk menciptakan produk yang unik, layanan, atau hasil. Sifat sementara proyek mengindikasikan awal dan akhir yang pasti. Akhirnya dicapai ketika tujuan proyek
yang telah tercapai atau ketika proyek dihentikan karena tujuannya yang tidak dapat dicapai atau ketika proyek tersebut sudah tidak dibutuhkan.
2.2.1 Ciri – Ciri Proyek
Menurut Schwalbe (2010,p7), proyek datang dalam bentuk dan ukuran apapun, berikut beberapa ciri – ciri dalam suatu proyek :
1. Proyek memliki tujuan yang unik.
Setiap proyek harus memiliki tujuan yang unik. 2. Proyek bersifat sementara.
Setiap proyek memiliki kepastian dalam mulai nya suatu proyek dan selesainya suatu proyek.
3. Proyek dikembangkan menggunakan progressive elaboration.
4. Proyek sering didefinisikan ketika dimulai, dan selama waktu berlalu, detil spesifik dari proyek menjadi jelas.
5. Proyek membutuhkan sumber, dan sering dari area yang berbeda – beda. Sumber meliputi orang, perangkat keras, perangkat lunak, dan aset lainnya. 6. Proyek harus memiliki pelanggan dan sponsor utama.
7. Banyak proyek memiliki banyak kelompok dan pemegang saham yang tertarik, tetapi seseorang harus mengambil peran utama dari sponsorship. 8. Proyek meliputi ketidakpastian.
9. Karena setiap proyek bersifat unik, terkadang sulit dalam mendefinisikan tujuannya secara jelas, mengukur berapa lama waktu dalam menyelesaikan proyek, atau menentukan berapa biaya yang diperlukan.
Menurut Pettit dan Beresford (2009) dalam Pratuckchai & Patanapongse (2012), Critical Success Factor (CSF) adalah strategi organisasi milik perusahaan yang menarik. Pada dasarnya, CSF dapat meningkatkan efektifitas setiap organisasi yang didasarkan lebih dari satu faktor. Critical Success Factor (CSF) pertama kali muncul karena ada faktor – faktor tertentu, jika tidak tercapai akan menyebabkan kegagalan dalam organisasi.
2.2.3 Tanggung Jawab Manajer Proyek
Menurut Schwalbe (2010, p21), tanggung jawab utama seorang manajer proyek adalah harus dapat bekerja sama dengan pihak pemegang saham dalam sebuah proyek terutama terhadap sponsor dan tim proyek. Dan harus memahami mengenai 9 area pengetahuan manajemen proyek dan alat – alat yang berhubungan dengan manajemen proyek.
Menurut Insitute (2008, p56), seorang manajer proyek harus mengerti detil proyek dan mengelola perspektif proyek secara keseluruhan. Sebagai orang yang bertanggung jawab terhadap kesuksesan proyek, seorang manajer proyek bertanggung jawab terhadap segala aspek dari dalam proyek, dan tidak terbatas pada:
1. Mengembangkan rencana proyek manajemen dan komponen yang terkait. 2. Memastikan jadwal dan anggaran proyek sesuai dengan yang telah
ditentukan.
3. Mengidentifikasi, memonitor dan memberi respon terhadap risiko. 4. Menyediakan laporan proyek matriks yang akurat dan secara periodik.
Menurut Insitute (2008, p56), salah satu bagian terpenting dalam tanggung jawab manajer proyek adalah untuk memenuhi harapan dari pemegang saham. Hal ini dapat menjadi sangat sulit karena para pemegang saham seringkali mempunyai
tujuan yang berbeda. Bagian dari tanggung jawab manajer proyek adalah untuk menyeimbangkan hal tersebut dan memastikan interaksi antara tim proyek dengan para pemegang saham berlangsung secara profesional dan kooperatif.
2.2.4 Kemampuan Yang Dibutuhkan Manajer Proyek
Menurut Schwalbe (2010, p22), Seorang manajer proyek harus memiliki area kemampuan yang luas dan dapat menentukan kemampuan apa yang sesuai untuk situasi yang berbeda. Beberapa kemampuan yang perlu dimiliki oleh manajer proyek yang baik adalah pemahaman mengenai PMBOK (Project Management Body of Knowledge).
a. Pengetahuan area aplikasi, standar, dan regulasi. b. Pengetahuan lingkungan proyek.
c. Pengetahuan dan kemampuan manajemen umum. d. Kemampuan soft skill atau kemampuan human relation.
Menurut Insitute (2008, p43), banyak alat dan teknik dalam mengatur proyek dalam manajemen proyek. Pengertian dan penerapan pengetahuan, alat, dan teknik yang diketahui sebagai best practice tidak cukup menandakan bahwa manajemen proyek sudah berjalan dengan efektif. Manajemen proyek yang efektif memerlukan manajer proyek yang memiliki beberapa karakteristik sebagai berikut :
1. Knowledge, mengacu pada pemahaman manajer proyek terhadap manajemen
proyek.
2. Perfomance, mengacu pada seorang manajer proyek mampu menyelesaikan
selama menerapkan pengetahuan manajemen proyek.
3. Personal, mengacu pada tingkah laku manajer proyek ketika mengerjakan proyek atau yang berhubungan dengan aktivitas.
2.2.5 Faktor Lingkungan Organisasi.
Menurut Insitute (2008, p44), faktor lingkungan organisasi terdiri dari faktor internal dan external yang mempengaruhi kesuksesan dari proyek. Faktor lingkungan organisasi terdiri dari :
1. Budaya, struktur, dan proses organisasi. 2. Standar industri dan pemerintahan.
3. Infrastruktur (fasilitas perusahaan, perlengkapan).
4. Sumber daya manusia (kemampuan, disiplin, pengetahuan). 5. Jumlah pelatihan, kebijakan lembur, pelacakan waktu. 6. Kondisi pasar.
7. Toleransi risiko dari para pemegang saham.
8. Hubungan komunikasi yang berjalan didalam organisasi. 9. Sistem manajemen informasi proyek.
2.2.6 Faktor Pengukuran Kesuksesan Proyek.
Menurut Schwalbe (2010, p8), setiap proyek dibatasi oleh beberapa arah, yaitu pandangan, waktu, dan tujuan biaya. Pembatasan ini terkadang mengarah didalam manajemen proyek sebagai 3 pembatas. Untuk membuat proyek yang sukses, manajer proyek harus mempertimbangkan pandangan, waktu, biaya, dan keseimbangan ketiga hal tersebut sering akan membawa pada kesuksesan.
Menurut Singer (2007), ada 7 poin kunci karakteristik keberhasilan proyek : 1. A Positive relationship with an active, intelligent client
a. Hanya melakukan proyek – proyek yang batasannya sesuai dengan bisnisnya.
b. Win – win kontrak dan rencana proyek yang realistis.
c. Memiliki prosedur peningkatan yang efektif untuk kontrak yang tidak sesuai dengan masalah utama.
d. Sy syms – “seorang konsumen yang cerdas adalah pelanggan terbaik bagi
perusahaan”.
e. Membangun / memelihara hubungan baik dengan klien secara aktif dan cerdas.
f. Mencari klien yang memiliki pengalaman mengenai keberhasilan proyek. g. Klien terlibat dalam pembuat keputusan secara aktif.
2. Strong project management
a. Manajemen proyek yang kuat dimulai dengan perencanaan proyek. b. Kepemimpinan tim proyek yang efektif dengan sumber daya yang jelas
sesuai pada tempatnya.
c. Kepemimpinan teknis tidak boleh ditempatkan dalam situasi di mana mereka dipaksa untuk membuat keputusan sumber daya dan bisnis seperti perubahan keputusan mengenai biaya terkait.
3. Clear requirements, well managed
a. Segala macam fungsi, mulai dari kebutuhan non-fungsional, hambatan dan asumsi harus jelas dan didokumentasikan sesuai dengan kebutuhan ke dalam database.
b. Dalam sistem yang kompleks, persyaratan harus ditetapkan secara spesifik atau revisi.
c. Sebuah proses persyaratan perubahan secara ketat harus berada di tempat dan ditaati.
d. Sebuah persyaratan tetap dengan kepemimpinan proyek yang tepat dan representasi teknis sudah harus tersedia untuk mencapainya dilakukan perubahan proses secara ketat.
e. Selama masa garansi, melaporkan kerusakan yang ditemukan yang akan mengalami kerusakan, tidak merubah permintaan dan harus dikelola sesuai dengan proses permintaan perubahan.
f. Ketika mengerjakan proyek dengan adanya ketentuan, persyaratan kualitas (kelengkapan, ambiguitas, akurasi) sangat penting. Persyaratan mutu harus dinilai karena merupakan bagian dari proses penawaran. Peninjauan biaya dan perbaikan ikut disertakan dalam estimasi proyek.
4. Ruthless change management
a. Harus adanya pergantian manajer (peran).
b. Pada bagian awalnya harus dipelihara sepanjang siklus hidup sistem. Perubahan baiknya diajukan pada bagian awal ini.
c. Ruang lingkup dapat merambat sehingga dapat menggagalkan proyek. d. Perubahan untuk setiap elemen dalam sistem harus dilakukan dalam
perubahan proses kontrol.
e. Semua perubahan memiliki biaya masing – masing.
f. Perubahan akan menimbulkan biaya, sehingga perusahaan membutuhkan bayaran untuk mengajukan perubahan analisis dan membuat perubahan, walaupun hasilnya tidak sesuai persyaratan. Biaya untuk perubahan manajemen dimasukkan dalam estimasi waktu dan terdapat pada kontrak.
g. Meskipun semua perubahan memiliki biaya, tidak semua perubahan biaya mencerminkan tagihan. Beberapa perubahan mungkin didanai oleh anggaran darurat.
h. Melakukan suatu perubahan ditinjau di tempat.
i. Perubahan persyaratan sesuai persetujuan dan harus tepat waktu.
5. Pervasive process focus.
a. Semua proses telah didokumentasikan dan disimpan.
b. Beberapa langkah proses prosedur dimana output hasil produk dapat diaudit.
c. Tidak ada proses yang dilakukan secara pintas.
d. Akurasi dalam pengukuran adalah kunci untuk memelihara proses fokus. e. Tidak meninggalkan proses pada saat mengalami masalah.
6. Effective controls and communication. a. Mengambil inisiatif.
b. Membangun dan memelihara hubungan dan melakukan komunikasi dengan seluruh pemegang saham dalam organisasi.
c. Tetap pada pesan.
d. Memelihara status proyek yang sedang berjalan.
e. Karyawan yang tidak memadai menyebabkan masalah pada proyek. f. Terburu – buru sehingga melakukan kesalahan dan menyebabkan
pengambilan keputusan yang buruk.
a. Teknik dalam memimpin.
b. Keunggulan teknik menyebabkan produk menjadi stabil dan cocok untuk pekerjaannya.
c. Adanya risiko yang berhubungan dengan bergantung pada teknologi yang belum sepenuhnya berada pada posisi stabil.
d. Perlu adanya sebuah peningkatan proses yang berurusan dengan masalah teknis dan bukan teknis (sumber daya) yang dihadapi kepemimpinan teknis.
2.2.7 Manfaat Proyek
Menurut Anonim (2008) dalam Nadiasa, Maya, & Norken (2010), manfaat suatu proyek dapat dibedakan atas dua yaitu :
1. Tangible Benefit, yaitu manfaat yang dapat dihitung dengan uang. 2. Intangible Benefit, yaitu manfaat yang tidak dapat dihitung dengan uang.
Gambar 2.2 Gambar 2 Jenis Benefit
( Sumber : Jurnal Ilmiah Teknik Sipil Vol. 14, No. 2, Juli 2010 ).
2.3 Manajemen Proyek
Menurut Schwalbe (2010, p9), manajemen proyek adalah pengaplikasian pengetahuan, kemampuan, alat, dan teknik terhadap aktivitas proyek untuk memenuhi persyaratan atau kebutuhan dari proyek.
Manajer proyek tidak harus berjuang untuk mencapai tujuan dari pandangan, waktu, biaya dan kualitas dari proyek, mereka harus memfasilitasi keseluruhan proses untuk menemukan kebutuhan kebutuhan dan ekspetasi terhadap orang yang memberikan efek terhadap aktivitas proyek.
Menurut Insitute (2008, p68), manajemen proyek adalah usaha integratif yang mengharuskan setiap proyek dan proses produk yang akan disejajarkan tepat dan terhubung dengan proses lain untuk memudahkan koordinasi. Proyek berada dalam
organisasi dan tidak dapat beroperasi dengan sistem tertutup. Mereka membutuhkan data input dari organisasi dan memberikan kemampuan kembali ke organisasi.
2.3.1 Manajemen Waktu Proyek.
Menurut Insitute (2008, p159), manajemen waktu proyek terdiri dari proses untuk mengatur waktu penyelesaian dari proyek, dimana kegiatannya sebagai berikut:
1. Definisi aktivitas, proses mengidentifikasi aksi spesifik yang akan dijalankan untuk mengembangkan proyek sesuai kebutuhan.
2. Urutan aktivitas, proses mengidentifikasi dan mendokumentasikan hubungan antara aktivitas proyek.
3. Estimasi sumber aktivitas, proses mengestimasi tipe dan kuantitas material, orang, perlengkapan, bahan yang dibutuhkan dalam menjalankan aktivitas. 4. Estimasi durasi aktivitas, proses memperkirakan periode waktu yang
dibutuhkan dalam menyelesaikan aktivitas individu dengan sumber yang telah terestimasi.
5. Membuat skedul, proses menganalisa urutan aktivitas, durasi, kebutuhan sumber, dan jadwal kendala dalam membuat jadwal proyek.
6. Skedul kontrol, proses memantau keadaan proyek untuk melakukan pengembangan terhadap proyek dan mengatur perubahan sesuai dengan skedul utama.
2.3.2 Manajemen Risiko Proyek.
Menurut Schwalbe (2010, p428), ada enam proses utama manajemen risiko proyek yang terlibat :
1. Perencanaan Manajemen Risiko Proyek.
Pada proses ini memutuskan bagaimana pendekatan dan merencanakan kegiatan pengelolaan risiko untuk proyek. Dengan meninjau proyek pernyataan ruang lingkup, rencana pengelolaan proyek, faktor-faktor lingkungan perusahaan, dan proses organisasi aset, tim proyek bisa mendiskusikan dan menganalisis kegiatan pengelolaan risiko untuk mereka. Output utama dari proses ini adalah sebuah rencana manajemen risiko proyek.
Perencanaan menejemen risiko mendokumentasikan prosedur untuk mengelola risiko dari proyek dan bagaimana manajemen risiko tersebut dilaksanakan. Hal ini penting untuk mengklarifikasi peran dan tanggung jawab, menyediakan anggaran dan estimasi skedul untuk risiko yang berhubungan dengan proyek termasuk menaksir kecendrungan dan dampak dari risiko yang berhubungan dengan proyek.
2. Identifikasi Risiko.
Melibatkan proses pemahaman akan potensi hasil yang tidak memuaskan yang berhubungan dengan proyek. Pada proses ini penentuan risiko mungkin dapat mempengaruhi proyek dan mendokumentasikan tiap-tiap karakteristik risiko, sebelum kita mengidentifikasi risiko kita tidak dapat mengelola risiko yang ada. Dengan memahami sumber-sumber risiko yang umum, perencanaan manajemen proyek, faktor lingkungan perusahaan, manajer proyek dan tim mereka dapat mengidentifikasi risiko-risiko yang potensial.
Tim proyek dapat memulai dengan mengidentifikasi risiko dengan membaca ulang dokumentasi proyek, Informasi yang berhubungan dengan organisasi dan asumsi-asumsi yang mungkin berkaitan dengan proyek.
Identifikasi risiko juga dapat dilakukan melalui brainstorming dengan pihak-pihak yang terlibat dengan proyek dengan cara mengumpulkan ide dan solusi yang spesifik secara spontan. Cara yang lain adalah dengan wawancara untuk mengumpulkan informasi baik face to face, telepon, instant messaging discussion atau mewawancarai orang-orang yang memiliki pengalaman dalam proyek yang serupa untuk mengidentifikasi risiko-risiko yang potensial.
Selain itu dapat menggunakan checklist, analysis of assumstions, dan creation of diagram. Hasil dari proses identifikasi risiko ini adalah daftar dari risiko yang diidentifikasi dan informasi yang dibutuhkan untuk membuat Risk Register. Risk Register adalah adalah dokumentasi yang terdiri dari hasil proses manajemen risiko, biasanya dibuat dalam bentuk tabel.
Gambar 2.3 Format Risk Register (Sumber : Schwalbe, 2010, p450)
Dalam risk register, terdapat beberapa kolom, yaitu :
1. Peringkat untuk setiap risiko kejadian : Peringkat biasanya ditentukan dengan angka, dengan angka 1 sebagai peringkat tertinggi.
2. Nomor identifikasi untuk setiap risiko kejadian : Tim proyek mungkin menginginkan untuk mencari risiko kejadian secara cepat dan spesifik, oleh karena itu mereka harus mengidentifikasi setiap risiko dengan berbagai tipe dari deskripsi unik, seperti contohnya adalah nomor identifikasi.
3. Nama dari risiko kejadian : Contohnya, server yang cacat, penyelesaian pengujian yang terlambat, mengurangi biaya konsultasi, atau publikasi yang baik.
4. Deskripsi dari risiko kejadian : Karena biasanya nama dari sebuah risiko kejadian sering disingkat, hal tersebut dapat membantu untuk menyediakan deskripsi yang lebih detil. Seperti contohnya, mengurangi biaya konsultasi dapat diperluas dalam deskripsi untuk mengatakan bahwa organisasi dapat bernegosiasi agar mendapatkan biaya yang lebih rendah untuk biaya konsultasi tertentu karena konsultan sangat menikmat suasana bekerja di perusahaan di lokasi tertentu.
5. Alasan dibalik risiko kejadian yang masuk kedalam kategori: Sebagai contoh, server yang rusak dapat masuk ke dalam kategori yang lebih luas daripada teknologi atau teknologi perangkat keras.
6. Akar penyebab dari risiko : Akar penyebab dari kerusakan server dapat berarti kerusakan pasokan listrik.
7. Pemicu dari setiap risiko adalah indikator atau gejala dari risiko kejadian yang sebenarnya. Sebagai contoh, kelebihan biaya pada saat aktifitas awal dapat menjadi gejala dari estimasi biaya yang buruk. Produk gagal dapat menjadi gejala dari pemasok yang berkualitas rendah. Mendokumentasi gejala risiko potensial terhadap proyek juga membantu tim proyek untuk mengidentifikasi lebih banyak risiko potensial kejadian.
8. Respon potensial dari setiap risiko : Respon potensial yang dilakukan organisasi, dari risiko kejadian terhadap sebuah kegagalan server termasuk dalam sebuah klausa dalam kontrak dengan pemasok untuk mengganti kerusakan server dalam periode waktu tertentu dan biaya yang ternegosiasi.
9. Pemilik risiko atau orang yang bertanggung jawab terhadap risiko: Sebagai contoh, seseorang dapat bertanggung jawab dalam apapun yang berhubungan dengan risiko kejadian server dan mengelola strategi tanggapan.
10. Probabilitas dari kemunculan risiko : Terdapat probabilitas tinggi, menengah dan rendah untuk berbagai risiko kejadian yang muncul. Sebagai contoh, kerusakan server bisa saja menjadi risiko yang memiliki probabilitas rendah.
11. Dampak untuk proyek jika risiko terjadi : Terdapat dampak tinggi, menengah dan rendah terhadap kesuksesan proyek dari risiko kejadian yang muncul. Kerusakan server dalam proyek yang sukses diselesaikan tepat waktu dapat memiliki dampak yang tinggi.
12. Status dari risiko : Apakah risiko kejadian muncul? Apakah tanggapan strategi telah terpenuhi? Apakah risiko sudah tidak lagi relevan dengan proyek? Sebagai contoh, sebuah klausa kontrak mungkin telah diselesaikan untuk mengatasi risiko dari sebuah server yang rusak.
Langkah – Langkah dalam mengisi Risk Register: 1. Analisa penyebab risiko
Dalam langkah ini, dilakukan analisa terhadap faktor yang menjadi penyebab risiko menjadi prioritas
2. Analisa Gejala risiko (pemicu)
Dalam langkah ini, dilakukan analisa terhadap gejala yang terjadi ketika suatu risiko telah muncul.
3. Pengukuran probabilitas munculnya risiko
Dalam langkah ini, dilakukan analisa terhadap tingkat kecendrungan suatu risiko dapat terjadi, dimulai dari sangat jarang terjadi sampai dengan sangat sering terjadi . Tingkat tersebut akan dijelaskan pada tabel 2.1.
Level Kecenderungan munculnya risiko
Keterangan
5 Sangat sering Selalu terjadi
4 Sering Hampir selalu terjadi
3 Cukup sering Dapat terjadi
2 Jarang Mungkin terjadi
1 Sangat jarang Hampir tidak mungkin
terjadi
Tabel 2.1 Kecenderungan Munculnya Risiko (Sumber : Audittindo Education, 2006, p26)
4. Pengukuran dampak risiko
Dalam langkah ini, dilakukan analisa pengukuran dampak dari munculnya suatu risiko. Tingkat kerusakan dimulai dari yang berdampak kecil dalam keberhasilan proyek sampai dengan dampak besar yang menyebabkan kegagalan proyek. Tingkat tersebut akan dijelaskan dalam Tabel 2.2
Level Dampak dari Kemunculan Risiko
Keterangan
5 Bencana Proses bisnis mengalami kegagalan
total.
4 Mayor Mengalami gangguan yang
menyebabkan seluruh proses bisnis terhambat.
3 Moderate Mengalami gangguan sehingga
sebagian proses bisnis terhambat.
2 Minor Mengalami gangguan namun proses
bisnis tetap dapat berjalan. 1 Tidak signifikan Tidak menyebabkan gangguan terhadap
proses bisnis.
Tabel 2.2 Dampak Risiko
(Sumber : Audittindo Education, 2006, p26)
5. Identifikasi respon yang dilakukan perusahaan
Dalam langkah ini mengidentifikasi terhadap pengendalian yang telah diimplementasikan dalam perusahaan dalam menangani risiko yang muncul.
6. Identifikasi pihak yang bertanggung jawab
Dalam langkah ini mengidentifikasi terhadap pihak yang bertanggung jawab apabila risiko aktif.
3. Analisis Risiko Kualitatif.
Proses ini memprioritaskan risiko berdasarkan probabilitas dan dampak yang terjadi. Setelah mengidentifikasi risiko, tim proyek dapat menggunakan berbagai teknik dan metode untuk menentukan peringkat risiko dari keseluruhan proyek. Output utama dari proses ini adalah untuk memperbaharui risiko. Biasanya probabilias dan dampak dari risiko dikategorikan ke tingkat tinggi, sedang, ataupun rendah. Probabilitas dan dampak ini dapat dipetakan kedalam probability /impact Matriks atau chart. Dijelaskan pada gambar tabel 2.3.
Tabel 2.3 Matriks Probability and Impact (Sumber : Audittindo Education, 2006, p26) Probability Impact Very Low (1) Low (2) Medium (3) High (4) Very High (5) Very High (5) H H E E E High (4) M H H E E Medium (3) L M H E E Low (2) L L M H E Very Low (1) L L M H H
Keterangan :
L = Low risk; risiko yang dapat diterima.
M = Medium risk; memerlukan penanganan dari manajemen.
H = High risk; memerlukan perhatian dan penanganan dari manajemen senior. E = Extreme risk; memerlukan tindakan yang secepatnya
4. Analisis Risiko Kuantitatif.
Pada proses ini melibatkan proses pengukuran probabilitas dan konsekuensi dari risiko dan mengestimasikan efeknya pada tujuan proyek. Setelah mengidentifikasikan risiko, tim proyek dapat menggunakan metode dan teknik untuk mengidentifikasikan kuantitas risiko dan mengestimasikan probabilitas dalam pencapaian tujuan proyek.
5. Pengembangan Tanggapan Terhadap Risiko.
Pada proses ini tim proyek mengambil langkah-langkah untuk meningkatkan peluang dan mengurangi ancaman terhadap proyek. Hasil dari proses ini adalah perencanaan manajemen risiko proyek. Setelah risiko telah diidentifikasi dan dinilai, maka risiko-risiko tersebut harus di respon, strategi strategi yang digunakan untuk merespon risiko-risiko adalah :
a. Risk Avoidance (penghindaran risiko) berarti tidak mencoba sesuatu yang berisiko, contohnya: tim proyek memutuskan untuk melanjutkan penggunaan perangkat keras dan perangkat lunak yang spesifik karena mereka mengenali cara kerja perangkat tersebut, produk lain juga dapat digunakan jika tersedia, namun jika tim tidak mengenali
perangkat-perangkat tersebut, maka hal ini dapat menimbulkan risiko yang signifikan.
Menghindari risiko adalah salah satu cara untuk menjawab risiko yang ada, namun ini juga berdampak bahwa kita bisa kehilangan kesempatan untuk meraih keuntungan.
b. Risk Mitigation (pengurangan risiko) melibatkan metode yang
mengurangi keparahan, kerugian yang mungkin terjadi. Sebagai contoh, menggunakan teknologi yang telah teruji, memperkerjakan anggota proyek yang kompeten dan melakukan berbagai teknik analisis.
c. Risk Acceptance ( penerimaan risiko) berarti menerima risiko yang ada. Hal ini biasa dilakukan pada risiko yang kecil, biasanya terjadi karena biaya untuk mengatasi risiko yang ada jauh lebih besar dari tingkat kerugian yang dapat ditimbulkan. Contohnya tim proyek dalam meeting mengusulkan untuk membuat back up plan, jika usulan tersebut tidak disetujui oleh perusahaan, di sisi lain mereka dapat menerima fasilitas apapun yang disediakan oleh perusahaan.
d. Transfer risk, dalam hal ini konsekuensi dari risiko dan tanggung jawab dialihkan ke pihak ketiga. Misalnya: tim proyek barangkali membeli asuransi khusus dan jaminan perlindungan untuk perangkat keras spesifik yang dimiliki oleh perusahan. Jika perangkat keras
tersebut bermasalah, pihak asuransi harus menggantinya dalam periode waktu yang disepakati.
6. Pengontrolan dan Pengawasan Risiko.
Melibatkan pengawasan terhadap risiko yang diketahui, identifikasikan risiko baru, mengurangi risiko dan mengevaluasikan keefektifan dari pengurangan risiko seluruhnya dalam proses proyek. Hasil utama dari proses ini adalah tindakan yang tepat dalam mengatasi risiko dan update perencanaan manajemen risiko.
Menurut Schwalbe (2010, p462), respon risiko biasanya termasuk dalam nilai sisa identifikasi dan tambahan demikian pula rencana cadangan, seperti yang dijelaskan sebelumnya.
Risiko residual adalah risiko yang masih tersisa setelah semua strategi respon telah dilaksanakan. Sebagai contoh, meskipun produk perangkat keras yang lebih stabil telah digunakan di dalam proyek, kemungkinan masih ada sebagian yang gagal berfungsi dengan baik.
Risiko sekunder adalah akibat langsung dari penerapan respon risiko. Misalnya, dengan menggunakan perangkat keras yang lebih stabil mungkin telah menyebabkan risiko perangkat tambahan gagal berfungsi dengan baik.
2.3.3 Faktor Risiko Proyek Teknologi Informasi.
Menurut Zhang Xian Lu dan Lee Jia Pei (2008), dalam mengidentifikasi faktor risiko poyek teknologi informasi terdapat 3 level yaitu : risiko ekonomi, risiko organisasi, risiko teknologi. Dengan penjelasan sebagai berikut.
Risiko Ekonomi. 1. Risiko ukuran.
Pembagian pengukuran risiko ini dimasukkan ke dalam tiga dimensi: ukuran tim, ukuran user, dan ukuran proyek. Pengukuran risiko tim berhubungan dengan keanekaragaman manusia dalam tim. Semakin besar suatu tim tersebut, maka akan semakin sulit dan berisiko untuk menangani orang-orang yang memiliki latar belakang dan kemampuan yang berbeda-beda tersebut. Sama halnya dengan ukuran user, faktor risiko ini berhubungan dengan jumlah dan keanekaragaman dari pengguna yang terlibat dengan proyek TI. Ukuran risiko suatu proyek berkaitan dengan ketidakpastian yang muncul dari lamanya waktu implementasi proyek, jumlah departemen yang terlibat, alokasi biaya kepada proyek, dan banyaknya pemasok eksternal yang terlibat dalam proyek.
2. Risiko sumber daya.
Risiko sumber daya dihubungkan dengan ketersediaan sumber daya tersebut. Jika proyek tidak memiliki sumber daya yang cukup, maka proyek tersebut tidak akan dapat selesai tepat waktu.
Risiko Organisasi. 3. Risiko perubahan.
Terdapat 5 kemungkinan perubahan yang dapat menjadi risiko terhadap proyek TI. (1) Perubahan prosedur, yang berarti adanya perubahan pada prosedur operasional dari departemen yang disebabkan karena adanya proyek TI. (2) Perubahan keorganisasian, yang mencakup suatu tingkat perubahan pada struktur organisasi, departemen, atau yang melibatkan fungsi dalam proyek TI. (3)
Perubahan sumber daya proyek karena prioritas organisasi. (4) Perubahan tugas pengguna, yang mencakup suatu modifikasi dari tugas pengguna yang dibutuhkan oleh proyek TI. (5) Frekuensi perubahan dalam tim proyek. Yang akan mempengaruhi produktivitas dari tim dalam kaitannya untuk mendapatkan kembali kemampuan dan pengetahuan.
4. Intensitas Konflik.
Terdapat 3 macam konflik yang akan muncul di antara pengguna, sistem, dan anggota tim pengembangan. Pengguna mungkin memiliki opini yang berlawanan selama pengembangan proyek TI; sistem akan menjadi tidak sesuai antara yang satu dengan yang lainnya; konflik dapat juga terjadi antar anggota tim pengembangan dalam kaitannya dengan perbedaan latar belakang, sifat, dan metode pengembangan yang dikuasai.
5. Kompleksitas Lingkungan Kerja.
Ada beberapa risiko yang berhubungan dengan kompleksitas dalam lingkungan kerja. Yang pertama adalah ketidakjelasan batasan peranan. Kalau peranan dari anggota tim dalam proyek tidak jelas maka anggota tim tidak akan memahami tanggung jawab mereka dan membuat pimpinan tim sulit mengontrol kualitas proyek. Risiko yang kedua berhubungan dengan kerumitan tugas. Semakin rumit tugas, maka akan semakin beresiko pula proyek tersebut. Risiko yang ketiga adalah komunikasi yang tidak efektif. Apabila komunikasi diantara pengguna, anggota tim, atau manajemen puncak tidak efektif, maka proyek akan memiliki risiko yang tinggi.
6. Ketidakstabilan Lingkungan Kerja.
Ada dua risiko yang berhubungan dengan ketidakstabilan lingkungan organisasi. Risiko dapat datang dari lingkungan organisasi yang tidak stabil seperti cepatnya perubahan keinginan pelanggan dan kompetisi. Ketergantungan kepada pemasok dapat juga menyebabkan risiko ketika pemasok memegang kendali yang berlebihan, menaikkan harga, diganti, atau menjadi tidak stabil atau tidak terkendali.
7. Kurangnya Komitmen.
Kurangnya komitmen dapat meningkatkan penolakan pemakaian sistem, kesulitan mendapatkan sumber daya dan kekuatan yang diperlukkan untuk mendukung proyek. Ada tiga macam komitmen disini: (1) Kurangnya komitmen pengguna, (2) Kurangnya komitmen manajemen puncak, dan (3) Kurangnya komitmen di antara anggota tim.
Risiko Teknologi.
8. Kurangnya Keahlian.
Ada lima risiko yang berhubungan dengan kurangnya keahlian. Yang pertama, risiko dapat datang dari anggota tim yang kurang terlatih. Anggota tim harus dilatih untuk mendapatkan pengetahuan yang diperlukan untuk menyelesaikan tugas. Risiko yang kedua berhubungan dengan pengetahuan tim sistem informasi terhadap alat dan metodologi pengembangan. Risiko juga dapat muncul ketika sistem informasi tidak memiliki pengetahuan yang cukup mengenai aplikasi yang digunakan dan tugas yang dilakukan. Yang terakhir kurangnya pengetahuan pengguna dalam sistem informasi dan aplikasi dapat juga
membawa risiko. Tidak hanya tim pengembang yang tidak memerlukan pengetahuan profesional, pengguna juga. Apabila pengguna tidak memiliki pengetahuan yang cukup mereka tidak akan mengidentifikasi kebutuhan yang jelas mengenai proyek, mempertimbangkan perubahan prosedural yang perlu dibuat, atau mengumpulkan data yang akan dipergunakan dalam proyek.
9. Risiko Kepegawaian.
Ketidakcukupan atau ketidakjelasan dalam kepegawaian dapat menyebabkan risiko proyek TI. Kepegawaian yang tidak tepat berarti penempatan peran, tanggung jawab, atau persyaratan dalam tim proyek tidak tepat, sehingga performa tidak mencapai hasil yang baik. Kepegawaian yang tidak cukup berarti dalam tim tidak ada staf yang cukup untuk menjalankan tugas dan mencapai sasaran, yang dapat menyebabkan meningkatnya risiko – risiko.
10. Pembaharuan Teknologi.
Terdapat 2 risiko yang berkaitan dengan risiko ini, yaitu pembaharuan perangkat keras dan pembaharuan perangkat lunak. Dalam proyek TI melibatkan perangkat keras dan perangkat lunak yang baru, serta teknologi baru dibutuhkan untuk mendukung dalam penyelesaian masalah teknologi, oleh karena itu dibutuhkan waktu dan sumber daya yang lebih dan membawa lebih banyak risiko dibanding proyek menggunakan teknologi yang sedang dipakai.
11. Kompleksitas teknologi.
Ada 4 risiko yang berhubungan dengan kompleksitas teknologi, yaitu (1) Beberapa penghubung ke sistem yang berjalan, menghubungkan sistem yang
berjalan melibatkan banyak isu seperti bagaimana untuk mengintegrasikan dengan sistem yang sedang berjalan, bagaimana menjalankan sistem baru tanpa mempengaruhi sistem yang lama, fungsi apa saja yang tidak diubah dari sistem lama; (2) beberapa penghubung ke sistem di masa depan, proyek akan jauh lebih berisiko bila juga harus mampu menampung fleksibilitas sistem di masa depan,
karena itu artinya arsitektur dasarnya harus didesain lebih hati – hati dibandingkan proyek yang didesain hanya untuk keperluan saat ini; (3) kesulitan dalam mendefinisikan input dan output sistem, penjelasan yang jelas tentang input dan output dibutuhkan untuk menyiapkan data dan desain sistem, dan juga menyediakan pengukuran yang jelas untuk fungsi manajemen proyek; (4) banyaknya pemasok perangkat keras / perangkat lunak, jumlah pemasok perangkat keras / perangkat lunak secara langsung berhubungan dengan kerumitan dalam mengintegrasikan sistem dan menyebabkan risiko muncul.
Semakin banyak pemasok perangkat keras dan perangkat lunak, maka semakin banyak interface yang perlu untuk dikembangkan sehingga proyek akan semakin sulit dan berisiko.
12. Risiko User ( Risiko Pengguna ).
Ada 2 macam risiko yaitu keterlibatan pengguna dan sikap / perilaku pengguna. Sebuah proyek tidak akan berhasil jika pengguna tidak terlibat khusus dalam proyek tersebut. Dalam hal lain, pengguna yang memiliki pengertian dan sikap puas akan membantu proyek berjalan dengan lancar. Performa akan membawa pengaruh positif bagi keberhasilan proyek.
Menurut Fauzi (2009), ciri – ciri pokok sebuah manajemen proyek adalah : 1. Memiliki tujuan yang khusus, produk akhir atau hasil kerja akhir.
2. Jumlah biaya, sasaran jadwal serta kriteria mutu dalam proses mencapai tujuan diatas telah ditentukan.
3. Bersifat sementara, dalam arti umurnya dibatasi oleh selesainya tugas. Titik awal dan akhir ditentukan dengan jelas.
4. Nonrutin, tidak berulang-ulang. Jenis dan intensitas kegiatan berubah sepanjang proyek berlangsung.
2.3.5 Jadwal Proyek.
Menurut Schwalbe (2010, p213), manajemen waktu proyek, didefinisikan sebagai proses yang dibutuhkan untuk memastikan pemenuhan waktu dari proyek secara tepat waktu.
Terdiri dari 5 proses utama dalam manajemen waktu proyek :
1. Penentuan aktivitas, identifikasi aktivitas secara spesifik yang akan dijalankan oleh anggota proyek untuk mendapatkan hasil dari proyek.
2. Pengulangan aktivitas, identifikasi dan dokumentasi hubungan antara aktivitas proyek.
3. Perkiraan durasi aktivitas, mencakup dalam mengestimasi jumlah waktu kerja yang diperlukan untuk menyelesaikan aktivitas individu.
4. Pembangunan jadwal, mencakup dalam menganalisa pengulangan aktivitas, perkiraan durasi aktivitas dan sumber persyaratan untuk membuat jadwal proyek.
5. Kontrol penjadwalan, mencakup dalam mengkontrol dan mengatur perubahan terhadap penjadwalan proyek.
2.3.6 Fungsi Dasar Manajemen Proyek.
Menurut Schwalbe (2010, p4), popularitas dari manajemen proyek mendorong manajer dari seluruh dunia untuk memeriksa proses manajemen proyek yang dimilikinya. Banyak organisasi menyatakan beberapa keuntungan dari proyek manajemen, yaitu :
1. Kontrol finansial, fisik, dan sumber daya manusia yang lebih baik. 2. Relasi pelanggan yang lebih baik.
3. Waktu pengembangan yang lebih singkat.
4. Biaya yang lebih rendah dan produktifitas meningkat. 5. Kualitas yang lebih tinggi dan reliabilitas meningkat. 6. Tingkat keuntungan meningkat.
7. Kordinasi internal yang lebih baik.
8. Dampak positif dalam rapat tujuan strategi. 9. Moral pekerja yang lebih tinggi.
2.4 Manajemen Risiko.
Menurut Kouns & Minoli (2011, p39), Manajemen Risiko adalah suatu proses mengidentifikasi, menganalisis, dan mengukur risiko serta menentukan langkah untuk mengurangi risiko sampai tingkat dimana risiko tersebut dapat diterima.
Gambar 2.4 Siklus Manajemen Risiko
(Sumber :http://2.bp.blogspot.com/_99_vGxycni8/S0KuIpnPk-I/AAAAAAAAABY/uu43ZrKMIIc/s320/Risk+Management+Cycle.jpg)
2.4.1 Risiko
Menurut Gondodiyoto (2007,p110), risiko adalah suatu kesempatan, perusahaan dapat memperkecil risiko dengan melakukan antisipasi berupa kontrol. Namun tidak mungkin dapat sepenuhnya menghindari adanya exposure, bahkan dengan struktur pengendalian maksimal sekalipun.
Menurut Djohanputro (2008, p31), risiko memiliki beberapa pengertian yang sering digunakan.Yang paling mendasar adalah risiko bisa diartikan sebagai tingkat dimana adanya keadaan ketidakpastian dan tingkat ketidakpastiannya terukur secara
kuantitatif. Pengertian lain, risiko adalah ketidakpastian yang bisa dikuantitaskan yang dapat menyebabkan kerugian atau kehilangan.
Menurut Kouns & Minoli (2011, p33), risiko adalah kombinasi dari kesesuaian antara suatu kejadian dengan dampak atau akibatnya yang merupakan suatu nilai kerugian yang diperkirakan.
Menurut Djohanputro (2008, p33), pada prinsipnya, risiko adalah ketidakpastian hasil sebagai akibat keputusan atau situasi saat ini.
Menurut Insitute (2008, p56), risiko adalah kejadian yang tidak pasti atau kondisi yang muncul, memberikan efek terhadap salah satu tujuan proyek. Tujuan tersebut termasuk pandangan, jadwal, biaya dan kualitas. Sebuah risiko dapat memiliki satu atau lebih akibat, yang dapat muncul jika memiliki satu atau lebih dampak.
2.4.2 Langkah-Langkah Proses Pengelolaan Risiko.
Menurut Barry Boehm (2011) dalam Stern & Arias (2011), manajemen risiko membantu dalam menghindari bencana, pekerjaan berulang, dan mensimulasi situasi yang menuju kemenangan dari suatu proyek perangkat lunak.Yang berfokus pada penemuan risiko seperti yang dijelaskan pada hubungan dimana kemungkinan hasil yang tidak sesuai dengan harapan dan kerugian akibat dari hasil tersebut. Langkah – langkah pengelolaan risiko terdiri dari :
1. Identifikasi Risiko.
Langkah awal dalam manajemen risiko berkelanjutan, dan merupakan langkah awal untuk manajemen risiko yang sukses adalah menulis risiko yang ada dan memperlihatkan semuanya.
2. Analisis Risiko.
Merupakan teknik untuk analisis risiko dan dasar untuk beberapa teknik dalam mengestimasi kemungkinan dan ukuran dari kerugian.
3. Prioritas Risiko.
Langkah untuk menentukan prioritas dari risiko, untuk menentukan risiko yang harus diproses terlebih dahulu.
4. Perencanaan Manajemen Risiko.
Perencanaan manajemen risiko, berfokus untuk membangun perencanaan untuk menangani masing – masing risiko yang masuk dalam kategori tinggi yang teridentifikasi selama aktivitas sebelumnya.
5. Resolusi dan Monitoring Risiko.
Proses resolusi risiko terdiri dari implementasi teknik pengurangan risiko seperti yang ada pada perencanaan. Monitoring risiko dilakukan dengan melacak proses pengurangan risiko, dan mengaplikasikan aksi korektif yang diperlukan untuk menjaga resolusi risiko tetap sesuai dengan jalur.
2.4.3 Penilaian Risiko
Menurut Gondodiyoto (2007, p116), penilaian risiko adalah salah satu langkah kritis dalam penyusunan internal kontrol yang efektif, yaitu dalam memperkirakan ancaman yang mungkin dihadapi.
Kesimpulannya penilaian risiko bagi penulis adalah langkah efektif dalam memperkirakan ancaman yang mungkin akan dihadapi.
2.4.4 Fungsi Pokok Manajemen Risiko
Menurut Senft & Gallegos (2009), fungsi dari manajemen risiko adalah sebagai berikut:
a. Menyadari kemungkinan kerugian dengan menjadi lebih perhatian terhadap macam – macam tipe kerugian lainnya. Ini adalah fungsi dasar yang harus diutamakan dibandingkan yang lainnya.
b. Mengestimasi frekuensi dan ukuran kerugian dengan menentukan kemungkinan terjadinya melalui berbagai macam sumber.
c. Menentukan metode ekonomi terbaik untuk mengatasi risiko kerugian, baik itu secara asumsi, menghindari, jaminan diri, mengurangi bahaya, transfer, jaminan komersial, atau kombinasi dari metode – metode tersebut.
d. Pengelolaan program manajemen risiko, termasuk tugas mengenai evaluasi tetap terhadap program dan pencatatan.
Fungsi – fungsi tersebut haruslah dilaksanakan melalui langkah berikut : a. Menentukan objek.
b. Mengidentifikasi risiko. c. Mengevaluasi risiko.
d. Memikirkan alternatif dan memilih alat untuk mengatasi risiko. e. Mengimplementasi keputusan.
Dalam langkah berikut, organisasi harus mempertimbangkan peluang dan tidak boleh mengambil risiko yang melebihi kemampuan perusahaan untuk mengalami kerugian banyak ataupun sedikit. Aturan ini menunjukan bahwa manajemen risiko hanya serangkaian keputusan biaya/manfaat.
2.4.5 Upaya Penanggulangan Risiko.
Menurut Joni (2012), ada sejumlah kegiatan manajemen yang spesifik yang dapat dilakukan untuk membantu manajemen ketika mengevaluasi risiko proyek saat diputuskan di lapangan. Beberapa aktivitas tersebut adalah :
a. Jika tercatat sebuah isu penyelesaian harus dibuat atau dilakukan, manajemen risiko sering mengajak semua pihak untuk memikirkan lebih awal, kemudian menurunkan potensial dari dampak dan umumnya dapat mengurangi biaya keanggotaan.
b. Catatan awal dari pembatasan pelabuhan dapat menjadi petunjuk dini masalah kapal dalam transportasi, menggunakan sebuah kapal dapat menurunkan biaya manakala terjadi peningkatan biaya handling di pelabuhan hasilnya dapat menjadi sebuah penurunan dalam biaya untuk pemasangan baja, kontraktor pemasang baja dapat menggunakan metode rencana pemasangan manakala. Pemilik dapat menghilangkan atau menurunkan klaim atas kondisi yang tidak disebutkan atau dipertimbangkan sebagai bencana alam. Agen keuangan akan melanjutkan untuk mendapatkan pendapatan dengan pengembalian pinjaman.
c. Keseimbangan administrasi kontrak berperan untuk memperoleh keseimbangan mencari jalan keluar.
d. Pemilihan karyawan seperti halnya sebuah bentuk pembangunan fakta dan solusi pada kasus aktual dan tanggung jawab yang dapat disepakati pada sebuah perjanjian.
e. Manakala kontrak untuk jumlah borongan atau volume harga kebijaksanaan pembukuan menjadi kondusif untuk menurunkan resiko mencapai sebuah tujuan proyek.
f. Penggunaan sistem dan jadwal database umum serta jadwal tabulasi dari sumber – sumber material dapat digunakan dengan menentukan sebuah jadwal.
g. Selalu mencoba untuk mencari penyelesaian dari isu risiko dan dampaknya dari pola dan model pada manajemen yang paling bawah.
h. Menggunakan pendekatan manajemen risiko sangat efektif digunakan di lapangan.
2.4.6 Identifikasi Risiko
Menurut Insitute (2008, p312), identifikasi risiko adalah proses dalam menentukan risiko mana yang dapat memberikan efek terhadap proyek dan mendokumentasi karakteristiknya. Identifikasi risiko adalah proses yang selalu berulang – ulang karena risiko yang baru dapat berevolusi atau dapat dikenal sebagai kemajuan proyek melalui siklus hidupnya.
Proses tersebut harus melibatkan anggota tim proyek supaya mereka dapat mengembangkan dan menjaga rasa kepemilikan dan tanggung jawab untuk risiko dan risiko yang berhubungan tindakan terkait.
Menurut Komite Nasional Kebijakan Governance (2011), penerapan manajemen risiko yang baik antara lain dapat:
a. Mengurangi kejutan – kejutanyang kurang menyenangkan. Ini dapat diperoleh karena melalui penerapan manajemen risiko yang baik semua hal yang berakibat pada pencapaian sasaran perusahaan telah diidentifikasikan sebelumnya dan juga langkah perlakuan terhadap hal tersebut telah diantisipasi. Hal ini berlaku untuk peristiwa positif maupun yang negatif.
b. Meningkatkan hubungan dengan para pemangku kepentingan menjadi semakin baik. Hal ini diperoleh karena dalam menerapkan manajemen risiko wajib untuk menemukenali para pemangku kepentingan dan harapannya. Melalui komunikasi timbal balik yang cukup intens maka dapat digalang kesamaan persepsi dan kesamaan kepentingan bersama, dengan demikian dapat diperoleh hubungan yang lebih baik.
c. Meningkatkan reputasi perusahaan, karena komunikasi yang baik dengan para pemangku kepentingan dan mereka mengetahui bahwa perusahaan mampu untuk menangani risiko – risikoyang dihadapi dengan baik. Akibatnya kepercayaan pelanggan, pemasok, kreditor, komunitas bisnis serta masyarakat juga meningkat.
d. Meningkatkan efektifitas dan efisiensi manajemen, karena semua risiko yang dapat menghambat proses organisasi telah diidentifikasikan dengan baik, maka cara untuk mengatasi gangguan kelancaran proses organisasi telah
diantisipasi sebelumnya, sehingga bila gangguan tersebut memang terjadi, maka organisasi telah siap untuk menanganinya dengan baik.
e. Lebih memberikan jaminan yang wajar atas pencapaian sasaran perusahaan karena terselenggaranya manajemen yang lebih efektif dan efisien, hubungan dengan pemangku kepentingan yang semakin membaik, kemampuan menangani risiko perusahaan yang juga meningkat, termasuk risiko kepatuhan dan hukum.
2.5 Penelitian Sebelumnya
Agar penelitian lebih kompeten, maka penulis juga melakukan studi banding dengan hasil penelitian Zhang Xian Lu dan Lee Jia Pei (2008) terkait dalam pengukuran risiko proyek teknologi informasi dengan sample 3 perusahaan yang bergerak dalam bidang service oriented IT yang berada di Taiwan. Adapun risiko – risiko yang ditemukan berdasarkan pengukuran yang dilakukan adalah :
1. Level Ekonomi
Risiko proyek teknologi informasi pada level ekonomi adalah (1) Ukuran dan keragaman tim, (2) Kekurangan sumber daya teknologi, (3) Kekurangan sumber daya teknologi,
2. Level Organisasi
Risiko proyek teknologi informasi pada level organisasi adalah (1) Kekurangan rantai fleksibilitas, (2) Kekurangan proses yang mendukung, (3)
Kekurangan dukungan struktur organisasi, (4) Kekurangan respon dari organisasi, (5) Kekurangan modul dari tugas pengguna, (6) Kekurangan kemampuan pengguna, (7) Kekurangan perpaduan dan moral dalam aktivitas pengembangan servis, (8) Kekurangan spesifikasi eksekutif sebagai pemilik servis untuk setiap servis yang secara logis terhubung, (9) Kekurangan komunikasi dengan grup projek servis yang baru, (3) Kekurangan komunikasi dengan pelanggan, (10) Kekurangan pembagian informasi
3. Level Teknologi
Risiko proyek teknologi informasi pada level teknologi adalah (1) Kekurangan standarisasi pengetahuan, (2) Kekurangan modulisasi pengetahuan, (3) Pengetahuan tim SI terhadap servis dan produk yang baru kurang, (4) Pengetahuan manajerial TI menengah terhadap proses servis pelanggan kurang, (5) Keterlibatan pengguna, (6) Kekurangan pengembangan servis dan pembelajaran pasar
