BAB 2 LANDASAN TEORI 2.1 Teknologi Informasi Menurut Schwalbe

advertisement
BAB 2
LANDASAN TEORI
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.
2.1.2 Data
9
10
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.
2.1.3.1 Aktivitas Siklus Hidup Pengembangan Sistem
11
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.
4. Melakukan implementasi sistem
12
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.
13
SYSTEM INVESTIGATION
Understand problem
SYSTEM ANALYSIS
Understand solution
SYSTEMS DESIGN
Select and plan best solution
SYSTEMS IMPLEMENTATION
Place solution info effect
SYSTEMS MAINTENANCE AND REVIEW
Evaluate result of solution
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.
14
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
15
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.
2.2.2 Critical Success Factor( CSF )
16
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
17
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.
18
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.
19
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.
20
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.
21
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.
7. Technical leadership and excellence.
22
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.
23
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
24
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 :
25
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.
26
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.
27
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.
28
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.
29
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.
30
Level
Kecenderungan munculnya
Keterangan
risiko
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
31
Level
Dampak dari Kemunculan
Keterangan
Risiko
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.
32
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.
Impact
Probability
Very
Low
Medium
High
Very
Low
(2)
(3)
(4)
High
(1)
Very High
(5)
H
H
E
E
E
High (4)
M
H
H
E
E
Medium
L
M
H
E
E
Low (2)
L
L
M
H
E
Very Low
L
L
M
H
H
(5)
(3)
(1)
Tabel 2.3 Matriks Probability and Impact
(Sumber : Audittindo Education, 2006, p26)
33
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
34
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
35
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.
36
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)
37
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.
38
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
39
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
40
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.
2.3.4 Ciri – Ciri Manajemen Proyek.
41
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.
42
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.
43
Gambar 2.4 Siklus Manajemen Risiko
(Sumber :http://2.bp.blogspot.com/_99_vGxycni8/S0KuIpnPkI/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
44
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.
45
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.
46
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.
f. Menjalankan evaluasi dan pengecekan.
47
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
keseimbangan mencari jalan keluar.
berperan
untuk
memperoleh
48
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.
2.4.7 Penerapan Manajemen Risiko
49
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
50
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)
51
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
Download