ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING SKRIPSI

ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING

SKRIPSI

RICKY TJOK 04 04 07 059X

UNIVERSITAS INDONESIA FAKULTAS TEKNIK DEPARTEMEN TEKNIK INDUSTRI DEPOK JULI 2008

Analisa manajemen..., Ricky Tjok, FT UI, 2008

ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING

SKRIPSI Diajukan sebagai salah satu syarat untuk memperoleh gelar Sarjana Teknik

RICKY TJOK 04 04 07 059X

DEPARTEMEN TEKNIK INDUSTRI FAKULTAS TEKNIK UNIVERSITAS INDONESIA DEPOK JULI 2008


ii

HALAMAN PERNYATAAN ORISINALITAS

Skripsi ini adalah hasil karya saya sendiri, dan semua sumber baik yang dikutip maupun dirujuk telah saya nyatakan dengan benar.

Nama NPM Tanda Tangan

: Ricky Tjok : 04 04 07 059X :

Tanggal

: 18 Juli 2008


iii

HALAMAN PENGESAHAN Skripsi ini diajukan oleh Nama NPM Program Studi Judul Skripsi

: : : : :

Ricky Tjok 040407059X Teknik Industri ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING

Telah berhasil dipertahankan di hadapan Dewan Penguji dan di terima sebagai bagian persyaratan yang diperlukan untuk memperoleh gelar Sarjana pada Program Teknik Industri Fakultas Teknik Universitas Indonesia

DEWAN PENGUJI Pembimbing

: Ir. Akhmad Hidayatno, MBT

(.....................)

Penguji

: Ir. Isti Surjandari, M.Si., M.A, Ph.D

(.....................)

Penguji

: Ir.Amar Rachman, MEIM

(.....................)

Penguji

: Ir.Yadrifil, M.Sc

(.....................)

Ditetapkan di : Depok Tanggal : 18 Juli 2008


iv

LEMBAR PERNYATAAN PERSETUJUAN PUBLIKASI TUGAS AKHIR UNTUK KEPENTINGAN AKADEMIS Sebagai sivitas akademik Universitas Indonesia, saya yang bertanda tangan di bawah ini: Nama : Ricky Tjok NPM : 040407059X Program Studi : Teknik Industri Departemen : Teknik Industri Fakultas : Teknik Jenis karya : Skripsi demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Universitas Indonesia Hak Bebas Royalti Non- Eksklusif (NonexclusiveRoyalty-Free Right) atas karya ilmiah saya yang berjudul : ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING beserta perangkat yang ada (bila diperlukan). Dengan Hak Bebas Royalti NonEkslusif ini Universitas Indonesia berhak menyimpan, mengalihmedia/formatkan, mengelola dalam bentuk pangkalan data (database), merawat, dan mempublikasikan tugas akhir saya tanpa meminta ijin dari saya selama tetap mencantumkan nama saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta. Demikian pernyataan ini saya buat dengan sebenarnya. Dibuat di : Depok Pada tanggal : 18 Juli 2008 Yang menyatakan

( Ricky Tjok )


v

UCAPAN TERIMAKASIH Puji syukur penulis ucapkan ke hadirat Tuhan Yesus Kristus, karena hanya atas kasih karunia-Nya skripsi ini dapat diselesaikan tepat pada waktunya. Pada kesempatan ini, penulis ingin menyampaikan terima kasih kepada: 1. Mama dan Papa, Maggie, Mbok, dan Ko Sen-Sen yang telah memberikan dukungan, doa, dan saran yang sangat berarti bagi penulis 2. Bapak Ir. Akhmad Hidayatno, MBT, sebagai dosen pembimbing skripsi atas segala bantuan dan pengarahannya kepada penulis. 3. Bapak Ir.Djoko Gabriel selaku pembimbing akademis selama masa studi penulis atas dukungan dan nasehatnya. 4. Seluruh dosen pengajar Departemen Teknik Industri yang telah mengajarkan berbagai ilmu kepada penulis selama masa kuliah. 5. Ibu Debby Alishinta, Ibu Dessy, Bapak Donny Salaki dan teman-teman di PT.Accenture khususnya di proyek PLN atas bantuannya untuk pengumpulan data selama skripsi. 6. Bapak Hermawan Kartajaya, selaku pimpinan di MarkPlus&Inc, serta temanteman di MarkPlus yang telah membimbing dan memberikan wawasan kepada penulis. 7. Hendry Frily, Arief Effendy, Ria Grace, Sri Dewi, Erica, Reza, Melati, Alexander Simeon, Chusnul Anwar dan semua TIUI04 sebagai sahabat yang selalu memberikan motivasi dan masukan kepada penulis serta memberikan arti persahabatan selama masa perkuliahan. Penulis menyadari bahwa skripsi ini jauh dari sempurna mengingat keterbatasan penulis. Oleh karena itu, kritik dan saran yang membangun sangat penulis harapkan. Penulis berharap bahwa skripsi ini dapat memberikan manfaat bagi semua pihak yang membacanya. Depok, 24 Juni 2008 Penulis


vi

ABSTRAK Nama : Ricky Tjok Program studi : Teknik Industri Judul : Analisa Manajemen Resiko Proyek Enterprise Resource Planning Untuk meningkatkan daya saingnya, banyak perusahaan menerapkan sistem informasi yang dinamakan dengan Enterprise Resource Planning (ERP). ERP adalah sistem informasi yang mengintegrasikan seluruh operasi bisnis dalam perusahaan, dari penjualan, keuangan, sumber daya manusia, produksi hingga distribusi dengan tujuan untuk membuat kesemua operasi tersebut berjalan dengan seefektif mungkin. Namun demikian, beberapa penilitian melaporkan banyak kasus dimana ERP gagal diterapkan dalam perusahaan. Kegagalan dari sebuah penerapan sistem ERP dapat dilihat dari dua aspek yaitu aspek organisasi dan penerapan teknikal. Aspek organisasi berhubungan dengan kebutuhan untuk melakukan perubahan proses bisnis, manajemen perubahan, pelatihan sumber daya manusia dan sebagainya. Aspek penerapan teknikal berhubungan dengan kebutuhan untuk mengintegrasikan sistem yang lama dengan sistem ERP, penentuan tingkat kustomisasi yang diperlukan untuk mencegah timbulnya masalah di masa depan, penganalisaan kesiapan infrastruktur teknologi terhadap sistem ERP dan pemilihan sistem ERP yang tepat dengan kebutuhan perusahaan. Penelitian ini bertujuan untuk memberikan rekomendasi tindakan penanganan resiko dengan menggunakan metode Australia and New Zeland Methodology AS/NZS 4360:1999. Penelitian ini meliputi membangun konteks, mengidentifikasi resiko, menganalisa dan mengevaluasi resiko, membuat perencanaan tindakan penanganan resiko, pengawasan dan pengontrolan resiko. Kata kunci: Manajemen Resiko, Risk Management, Enterprise Resource Planning

Universitas Indonesia


vii

ABSTRACT Name : Ricky Tjok Study Program : Industrial Engineering Title : Risk Management in Enterprise Resource Planning Project In order to maintain its competitiveness, many companies have implemented the information system called Enterprise Resource Planning (ERP). ERP is an information system that integrate all business functions within company, from sales, finance, human resource, production and distribution in order to make all these operations operate effectively. In reality, many research give report about failure in ERP implementation. The failure could be seen in two aspects: organizational aspect and technical aspect. Organizational aspect related with business process changes, change management, human resource development, etc. Technical aspect related with integration between legacy system and ERP, customization in ERP software, infrastructure assessment, etc. This paper is aim to give recommendation of risk handling strategy using Australia and New Zeland Methodology AS/NZS 4360:1999 framework. The scope of the research consist of extablish the risk context, identify risk, analyse risk, evaluate risk, treat risk, monitor and review risk. Keywords: Manajemen Resiko, Risk Management, Enterprise Resource Planning



viii

DAFTAR ISI HALAMAN JUDUL ................................................Error! Bookmark not defined. LEMBAR PENGESAHAN .....................................Error! Bookmark not defined. UCAPAN TERIMAKASIH ................................................................................. v LEMBAR PERNYATAAN PERSETUJUAN PUBLIKASI ....Error! Bookmark not defined. KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS ...Error! Bookmark not defined. ABSTRAK ............................................................................................................ vi ABSTRACT ......................................................................................................... vii DAFTAR ISI....................................................................................................... viii DAFTAR TABEL ................................................................................................ xi DAFTAR GAMBAR........................................................................................... xii DAFTAR LAMPIRAN ...................................................................................... xiv 1.

PENDAHULUAN.......................................................................................... 1 1.1 Latar Belakang .............................................................................................. 1 1.2 Diagram Keterkaitan Masalah ...................................................................... 4 1.3 Perumusan Masalah ...................................................................................... 4 1.4 Tujuan ........................................................................................................... 4 1.5 Manfaat Penelitian ........................................................................................ 5 1.6 Ruang Lingkup Penelitian............................................................................. 5 1.7 Metodologi Penelitian ................................................................................... 5 1.8 Sistematika Penulisan ................................................................................... 7

2.

DASAR TEORI ............................................................................................. 9 2.1 SISTEM ........................................................................................................ 9 2.1.1 Pengertian Sistem................................................................................... 9 2.1.2 Klasifikasi Sistem ................................................................................ 10 2.2 SISTEM ENTERPRISE RESOURCE PLANNING .................................. 12 2.2.1 Pengertian Sistem ERP ........................................................................ 12 2.2.2 Modul Sistem ERP............................................................................... 14 Universitas Indonesia


ix

2.2.3 Tujuan Implementasi Sistem ERP ....................................................... 16 2.2.4 Implementasi Sistem ERP.................................................................... 16 2.2.5 Evaluasi Implementasi Sistem ERP ..................................................... 20 2.2.6 Kegagalan Implementasi Sistem ERP.................................................. 20 2.3 RISIKO ....................................................................................................... 21 2.4 MANAJEMEN PROYEK........................................................................... 22 2.4.1 Karakteristik Proyek............................................................................. 22 2.4.2 Daur Hidup Proyek .............................................................................. 23 2.4.3 Manajemen Proyek .............................................................................. 25 2.5 MANAJEMEN RISIKO PROYEK ............................................................ 27 2.5.1 Manfaat Manajemen Risiko Proyek..................................................... 27 2.5.2 Proses Manajemen Risiko Proyek........................................................ 30 2.6 HOUSE OF QUALITY (HOQ) .................................................................. 62 2.6.1 Komponen HOQ .................................................................................. 63 2.6.2 Tahap-tahap Pembuatan HOQ ............................................................. 67 3.

PENGUMPULAN DAN PENGOLAHAN DATA ................................... 70 3.1

Mengidentifikasi Kesempatan dan Tujuan............................................. 71

3.2

Mengidentifikasi Resiko......................................................................... 74

3.3

Menganalisa dan Mengevaluasi Resiko ................................................. 79

3.3.1

Analisa Item Kategori Resiko Tinggi ............................................. 84

3.3.2 Analisa Item Kategori Resiko Menengah ............................................ 90 3.3.3

Analisa Item Kategori Resiko Rendah............................................ 98

3.3.4 Analisa Keseluruhan Kategori Resiko ............................................... 100 4.

ANALISIS.................................................................................................. 102 4.1

Perencanaan Tindakan Penanganan Resiko ......................................... 102

4.1.1

Pengumpulan Rekomendasi Tindakan Penanganan Melalui

Kuesioner .................................................................................................... 102 4.1.2

Pendefinisian Tanggung Jawab dan Otoritas Pengambilan

Keputusan.................................................................................................... 105 4.1.3

Peningkatan Komitmen Manajemen Level Atas Terhadap Proyek

ERP

107

4.1.4

Manajemen Perubahan Proyek ERP ............................................. 111



x

4.1.5

Analisa Kebutuhan Infrastruktur ERP .......................................... 123

4.1.6

Penyusunan Business Case ........................................................... 124

4.1.7

Perbaikan Proses Bisnis ................................................................ 128

4.1.8

Penentuan Prioritas Tindakan Penanganan Resiko ....................... 130

4.2

5.

Pengawasan dan Pengontrolan Resiko ................................................. 135

4.2.1

Identifikasi Resiko Baru................................................................ 136

4.2.2

Penilaian Ulang Resiko ................................................................. 137

KESIMPULAN.......................................................................................... 138

DAFTAR REFERENSI .................................................................................... 143



xi

DAFTAR TABEL Tabel 2.1 Skala Penilaian Probabiltas Risiko ....................................................... 42 Tabel 2.2 Skala Penilaian Dampak Risiko............................................................ 43 Tabel 2.3 Estimasi Biaya Proyek yang Dikumpulkan Selama Wawancara.......... 48 Tabel 3.1 Item Resiko Proyek ERP ...................................................................... 76 Tabel 3.2 Tabel Dampak Resiko........................................................................... 81 Tabel 3.3 Tabel Probabilitas Resiko ..................................................................... 81 Tabel 3.4 Tabel Matriks Resiko ............................................................................ 82 Tabel 3.5 Tabel Skor dan Kategori Resiko ........................................................... 82 Tabel 3.6 Peringkat Proporsi Item Kategori Resiko Tinggi.................................. 85 Tabel 3.7 Item Kategori Resiko Tinggi................................................................. 85 Tabel 3.8 Proporsi Item Kategori Resiko Menengah............................................ 90 Tabel 3.9 Item Kategori Resiko Menengah .......................................................... 91 Tabel 3.10 Peringkat Proporsi Item Kategori Resiko Rendah .............................. 98 Tabel 3.11 Item Kategori Resiko Rendah ............................................................. 98 Tabel 3.12 Persebaran Item Resiko..................................................................... 100 Tabel 4.1 Hubungan Tindakan Penanganan Resiko dan Resiko......................... 131 Tabel 4.2 Perhitungan Bobot Kepentingan AntaraTindakan Penanganan Resiko dan Resiko........................................................................................................... 133 Tabel 4.3 Prioritas Tindakan Penanganan Resiko............................................... 134 Tabel 5.1 Item Resiko Kategori Tinggi .............................................................. 139 Tabel 5.2 Item Resiko Kategori Menengah ........................................................ 140 Tabel 5.3 Item Resiko Kategori Rendah ............................................................. 141 Tabel 5.4 Strategi Penanganan Resiko................................................................ 142



xii

DAFTAR GAMBAR Gambar 1.1 Diagram Keterkaitan Masalah............................................................ 4 Gambar 1.2 Diagram Alir Metodologi Penelitian................................................... 7 Gambar 2.1 Struktur dari sistem MRP.................................................................. 13 Gambar 2.2 Integrasi sisem informasi pada sistem ERP ...................................... 14 Gambar 2.3 Proses manajemen proyek (Sumber: Project Management Institute,2004, hal.11) ........................................................................................... 27 Gambar 2.4 Proses perencanaan manajemen risiko proyek (Sumber: Project Management Institute, 2004, hal.239)................................................................... 31 Gambar 2.5 Proses perencanaan manajemen risiko.............................................. 33 Gambar 2.6 Contoh kategori risiko berdasarkan RBS (Sumber: Project Management Institute, 2004, hal.244)................................................................... 35 Gambar 2.7 Proses identifikasi risiko (Sumber: Project Management Institute, 2004, hal.246) ....................................................................................................... 37 Gambar 2.8 Proses analisis kualitatif risiko (Sumber: Project Management Institute, 2004, hal.250) ........................................................................................ 41 Gambar 2.9 Matriks probabilitas dan dampak risiko (Sumber: Office of Project Management Process Improvement, 2003, hal.24)............................................... 44 Gambar 2.10 Proses analisis kuantitatif risiko (Sumber: Project Management Institute, 2004, hal.254) ........................................................................................ 47 Gambar 2.11 Distribusi beta dan distribusi tringular (Sumber: Project Management Institute, 2004, hal.256)................................................................... 49 Gambar 2.12 Diagram pohon keputusan (Sumber: Project Management Institute,2004, hal.258) ......................................................................................... 50 Gambar 2.13 Contoh hasil simulasi biaya risiko (Sumber: Project Management Institute, 2004, hal.259) ........................................................................................ 51 Gambar 2.14 Proses perencanaan tindakan penanganan risiko (Sumber: Project Management Institute, 2004, hal.260)................................................................... 53 Gambar 2.15 Proses pengawasan dan pengontrolan risiko (Sumber: Project Management Institute, 2004, hal.265)................................................................... 57 Gambar 2.16 Struktur HOQ (Sumber : S. Bruce Han, et. al., 2001, hal.798)....... 63



xiii

Gambar 3.1 Metode Australia and New Zeland Methodology AS/NZS 4360:1999 ............................................................................................................................... 70 Gambar 3.2 Kuesioner Tahap Pertama ................................................................. 75 Gambar 3.3 Kuesioner Tahap Kedua .................................................................... 80 Gambar 3.4 Proporsi Item Kategori Resiko Tinggi .............................................. 84 Gambar 3.5 Proporsi Item Kategori Resiko Menengah ........................................ 90 Gambar 3.6 Proporsi Item Kategori Resiko Rendah............................................. 98 Gambar 3.7 Proporsi Keseluruhan Kategori Level Resiko................................. 101 Gambar 4.1 Kuesioner Rekomendasi Tindakan Penanganan Resiko ................. 103 Gambar 4.2 Flowchart Pendefinisian Tanggung Jawab dan Otoritas Pengambilan Keputusan............................................................................................................ 107 Gambar 4.3 Flowchart Pengukuran Tingkat Komitmen Karyawan dan Budaya Organisasi............................................................................................................ 111 Gambar 4.4 Flowchart Pendefinisian Strategi Manajemen Perubahan............... 116 Gambar 4.5 Flowchart Manajemen Komunikasi Implementasi ERP ................. 118 Gambar 4.6

Flowchart Pendefinisian Pelatihan Implementasi ERP ............. 122

Gambar 4.7 Flowchart Pendefinisian Business Case.......................................... 128 Gambar 4.8 Proses Pengawasan dan Pengontrolan Resiko ................................ 135 Gambar 4.9 Proses Penanganan Resiko Baru ..................................................... 136



xiv

DAFTAR LAMPIRAN

Lampiran 1 Kuesioner Tahap Pertama ....................................................... 144 Lampiran 2 Kuesioner Tahap Kedua........................................................... 149 Lampiran 3 Kuesioner Tahap Ketiga........................................................... 151 Lampiran 4 Hasil Kuesioner Tahap Kedua ................................................ 152 Lampiran 5 Hasil Kuesioner Tahap Ketiga ................................................. 153



1.

PENDAHULUAN

1.1 Latar Belakang Untuk meningkatkan daya saingnya, banyak perusahaan menerapkan sistem informasi yang dinamakan dengan Enterprise Resource Planning (ERP). ERP adalah sistem informasi yang mengintegrasikan seluruh operasi bisnis dalam perusahaan, dari penjualan, keuangan, sumber daya manusia, produksi hingga distribusi dengan tujuan untuk membuat kesemua operasi tersebut berjalan dengan seefektif mungkin (Slack et al., 2001). Dari sudut pandang teknologi informasi, sistem ERP ini dapat didefinisikan sebagai suatu perangkat lunak yang mengintegrasikan berbagai komponen modular terintegrasi dengan kecepatan aliran data yang cepat di berbagai sektor dalam sebuah perusahaan (Laughin, 1999; Watson dan Schneider, 1999). Dengan menggunakan ERP, suatu perusahaan dapat dengan mudah berbagi informasi dan hal ini berarti setiap keputusan atau aksi strategi yang dilakukan di level manapun dalam perusahaan akan secara langsung berdampak kepada seluruh level organisasi (Slack et al. 2001). Sistem informasi yang terintegrasi akan mempersingkat waktu dalam penyajian data yang akan digunakan sebagai salah satu pertimbangan dalam pengambilan keputusan atau strategi perusahaan. Hal tersebut tentunya akan meningkatkan performa dari perusahaan. Namun demikian, beberapa penilitian melaporkan banyak kasus dimana ERP gagal diterapkan dalam perusahaan (Hollanda dan Light, 1999; Ross dan Vitale, 2000; Hong dan Kim, 2002; Themistocleous et al., 2001; Allen et al., 2002; Motwani et al., 2002; Vogt, 2002; Bradley, 2003; Umble et al., 2003; Kim et al., 2005; Fallon, 2005). Kegagalan dari sebuah penerapan sistem ERP dapat dilihat dari dua aspek yaitu aspek organisasi dan penerapan teknikal. Aspek organisasi berhubungan dengan kebutuhan untuk melakukan perubahan proses bisnis, manajemen 1 Universitas Indonesia Analisa manajemen..., Ricky Tjok, FT UI, 2008

2

perubahan, pelatihan sumber daya manusia dan sebagainya. Aspek penerapan teknikal berhubungan dengan kebutuhan untuk mengintegrasikan sistem yang lama dengan sistem ERP, penentuan tingkat kustomisasi yang diperlukan untuk mencegah



timbulnya masalah di masa depan, penganalisaan kesiapan infrastruktur teknologi terhadap sistem ERP dan pemilihan sistem ERP yang tepat dengan kebutuhan perusahaan. Kegagalan perusahaan dalam melakukan pengukuran kedua aspek ini pada fase prapenerapan sistem ERP dapat berujung kepada kegagalan penerapan sistem ERP. Pada tahun 2007, PricewaterhouseCoopers (PwC) bersama dengan IT Governance Institute (ITGI) mengadakan survey global terhadap isu IT governace yang menghasilkan IT Governance Global Status Report—2008. Survei ini berfokus pada topik resiko dalam teknologi informasi. Dari survei ini, didapatkan beberapa temuan terkait dengan manajemen resiko dalam proyek TI sebagai berikut: •

30 % responden sudah menerapkan manajemen resiko dalam proyek IT, 32 % sedang menerapkan, 20% responden sedang mempertimbangkan untuk menerapkan dan 16% responden tidak mempertimbangkan untuk mengimplementasikan sama sekali

•

Dari aspek tingkat kepentingan, 47% responden melihat manajemen resiko sangatlah penting, 33% responden menilainya cukup penting, 13% responden tidak yakin, 5% menilai tidak penting untuk menerapkan manajemen resiko Dari hasil temuan survei ini, dapat dilihat bahwa manajemen resiko dalam

proyek IT sudah dianggap penting. Namun demikian, perusahaan yang sudah menerapkan manajemen resiko di dalam proyek IT nya masih tergolong rendah. Padahal, manajemen resiko memegang peranan penting dalam keberhasilan dan kegagalan dari sebuah proyek IT. Termasuk pula di dalamnya proyek ERP. Untuk

itulah,

diperlukan

sebuah

pendekatan

metodologis

untuk

menjalankan manajemen resiko dalam sebuah proyek ERP. Skripsi ini akan membahas item-item resiko yang ada di dalam sebuah proyek ERP dan rekomendasi strategi penanganan terhadap item resiko tersebut.

3 Universitas Indonesia Analisa manajemen..., Ricky Tjok, FT UI, 2008

4

1.2 Diagram Keterkaitan Masalah

Gambar 1.1 Diagram Keterkaitan Masalah

1.3 Perumusan Masalah Perusahaan yang hendak menerapkan sistem ERP perlu mengetahui itemitem resiko yang ada di dalam proyek ERP tersebut agar dapat merumuskan strategi penanganan yang tepat terhadap item resiko tersebut.

1.4 Tujuan Tujuan dari penelitian memperoleh tindakan penanganan yang tepat terhadap item-item resiko dalam proyek ERP



5

1.5 Manfaat Penelitian Hasil penelitian ini adalah berupa daftar item resiko dan strategi penanganan resiko dalam proyek ERP. Strategi penerapan yang tepat akan menambah probabilitas tingkat keberhasilan penerapan sistem ERP.

1.6 Ruang Lingkup Penelitian Ruang lingkup penelitian ini adalah sebagai berikut: 1. Penelitian meliputi identifikasi item resiko, pembobotan item resiko untuk mencari nilai dari tiap resiko, dan perumusan strategi penanganan terhadap item resiko. 2. Responden dalam penelitian ini adalah konsultan ERP dari PT.Accenture

1.7 Metodologi Penelitian Metodologi yang akan digunakan dalam penelitian ini adalah sebagai berikut: 1. Identifikasi dan merumuskan pokok permasalahan yang akan diteliti. 2. Menentukan tujuan penelitian yang akan dilakukan 3. Melakukan studi literatur untuk memperdalam dasar teori yang berkaitan dengan permasalahan, terutama untuk memperoleh informasi mengenai item resiko yang ada dalam sebuah proyek ERP. 4. Melakukan penyusunan kuesioner pertama. Kuesioner ini bertujuan untuk melengkapi item resiko yang diperoleh dari studi literatur. Responden akan menambahkan item resiko yang belum tercantum dalam kuesioner berdasarkan pengalaman responden sebagai konsultan proyek ERP. 5. Penyebaran kuesioner pertama. Penyebaran kuesioner dilakukan dengan melalui email kepada responden yang bersangkutan ataupun langsung menghubungi responden. 6. Mengumpulkan dan mengolah kuesioner yang telah diisi oleh responden. Item resiko yang ditambahkan oleh responden akan dikonfirmasi kepada responden yang bersangkutan mengenai penjelasan lebih lanjut dari item resiko tersebut. Konfirmasi diperlukan untuk menghindari adanya



6

duplikasi item resiko. Seluruh item resiko yang telah dikonfirmasi kepada responden akan menjadi dasar dalam penyusunan kuesioner kedua. 7. Melakukan penyusunan kuesioner kedua. Kuesioner ini bertujuan untuk mengetahui probabilitas terjadinya resiko serta dampak kuantitatif dari resiko-resiko yang teridentifikasi. Dalam kuesioner ini, responden diminta untuk mengisi probabilitas terjadinya suatu resiko serta dampak yang disebabkan jika resiko tersebut terjadi. 8. Penyebaran kuesioner kedua.Penyebaran kuesioner dilakukan dengan melalui email kepada responden yang bersangkutan ataupun langsung menghubungi responden. 9. Mengumpulkan dan mengolah kuesioner kedua yang telah diisi oleh responden. Hasil dari kuesioner ini adalah berupa pengelompokkan resiko berdasarkan kategori potensi resiko. 10. Melakukan penyusunan kuesioner ketiga. Kuesioner ini bertujuan untuk memperoleh rekomendasi tindakan penanganan resiko 11. Penyebaran kuesioner ketiga. Penyebaran kuesioner dilakukan dengan melalui email kepada responden yang bersangkutan ataupun langsung menghubungi responden. 12. Mengumpulkan dan mengolah kuesioner ketiga yang telah diisi oleh responden. Hasil dari kuesioner ini adalah berupa rekomendasi tindakan penanganan resiko 13. Melakukan konsultasi dan konfirmasi dengan pihak responden mengenai tindakan penanggulangan untuk mengatasi resiko pada kuesioner kedua 14. Melakukan studi literatur untuk melengkapi rekomendasi tindakan penanganan resiko 15. Menarik kesimpulan penelitian 16. Selesai



7

Pengumpulan Data

Pemahaman Pemilihan Topik Dasar Teori Penelitian

Diagram Alir Metodologi Penelitian

Mulai

Menentukan topik penelitian

Dasar teori ERP dan Manajemen Resiko

Menentukan dan mempelajari dasar teori yang dibutuhkan

Data kuesioner 1,2,3

Mengumpulkan data

Literatur penunjang: jurnal, artikel, skripsi, tesis, disertasi

Mengidentifikasi kesempatan dan tujuan

Pengolahan Data dan Analisis

Mengidentifikasi resiko

Menganalisa dan mengevaluasi resiko

Membuat perencanaan tindakan penanganan resiko

Kesimpulan

Membuat Pengawasan dan Pengontrolan Resiko

Kesimpulan

Selesai

Gambar 1.2 Diagram Alir Metodologi Penelitian 1.8 Sistematika Penulisan Secara garis besar, penelitian ini terbagi menjadi 5 bab yaitu pendahuluan, dasar teori, pengumpulan dan pengolahan data, analisis dan kesimpulan. Pendahuluan merupakan bab pembuka yang akan memaparkan latar belakang permasalahan, diagram keterkaitan masalah, perumusan masalah, tujuan penelitian, manfaat penelitian, ruang lingkup penelitian, metodologi penelitian dan sistematika penulisan.



8

Untuk mendukung proses penelitian ini, maka bab dasar teori akan menjelaskan mengenai teori-teori yang berkaitan dengan penulisan skripsi, antara lain penjelasan mengenai sistem ERP, sejarah perkembangan sistem konvensional MRP menjadi ERP, keterbatasan dan kelebihan sistem ERP, pemilihan sistem sistem ERP, evaluasi dan kegagalan sistem ERP. Selain itu, dijelaskan pula mengenai manajemen resiko. Selanjutnya adalah bab pengumpulan dan pengolahan data yang menjelaskan proses dan hasil pengumpulan data yang dilakukan serta pengolahan data tersebut yang akan dijadikan bahan pembahasan dalam penulisan penelitian ini. Setelah pengumpulan dan pengolahan data, maka akan dilakukan analisaanalisa mengenai hasil yang diperoleh beserta dengan hasil akhir dari penelitian ini. Hal ini akan dijelaskan dengan detail pada bab analisa. Langkah terakhir adalah penulisan bab kesimpulan yang merupakan pengambilan kesimpulan mengenai hasil yang telah diperoleh dari penulisan penelitian ini.



2. DASAR TEORI

2.1 SISTEM 2.1.1 Pengertian Sistem Enterprise Resource Planning (ERP) bukanlah sekedar software, tetapi lebih pada suatu sistem yang terintegrasi.1 Oleh karena itu, sebelum membahas lebih jauh mengenai sistem ERP, akan dijelaskan secara singkat mengenai sistem yang merupakan dasar untuk memahami sistem ERP lebih lanjut. Secara harfiah, perkataan sistem berasal dari bahasa Yunani yaitu ”system” yang berarti keseluruhan yang tersusun dari sekian banyak bagian. Para ahli mempunyai persepsi yang berbeda mengenai pengertian sistem itu sendiri. Jhonson, Kast dan Rosenzweight mendefinisikan sistem sebagai suatu keseluruhan yang kompleks dan terorganisir yang merupakan perpaduan hal-hal atau bagian-bagian yang lebih kecil. Shoerde dan Voinich berpendapat sistem adalah suatu perangkat dari bagian-bagian yang berhubungan, bekerja sama secara sendiri-sendiri dan bersama-sama untuk mencapai tujuan keseluruhan dalam lingkungan yang kompleks.2 Pendapat yang paling banyak diterima sebagai definisi dari sistem adalah hasil pemikiran Murdick dan Ross yang menyatakan bahwa sistem adalah seperangkat elemen yang membentuk kegiatan atau suatu prosedur pengolahan yang mencari tujuan dengan melakukan pengolahan data dalam jangka waktu tertentu untuk menghasilkan informasi dan/atau produk. Elemen-elemen ini terdiri dari input, output, mekanisme dan fungsi kontrol atau pengawasan. Perubahan elemen-elemen dalam suatu sistem dilakukan untuk mendesain dan menjadikan sistem bekerja lebih baik.3

1

Thomas F. Wallace dan Michael H. Kremzar. ERP: Making It Happen, The Implementers’ Guide to Success with EnterpriseResource Planning, John Wiley & Sons, Inc., Kanada, 2001, hal.3. 2 Yogiyanto HM, MBA, Akt, Phd. Sistem Teknologi Informasi, Penerbit Andi, Yogyakarta, 2003. hal.9. 3 Yogiyanto HM, MBA, Akt, Phd. Sistem Teknologi Informasi, hal.11. 9 Universitas Indonesia Analisa manajemen..., Ricky Tjok, FT UI, 2008

10

2.1.2 Klasifikasi Sistem Pada awalnya, sistem terbagi terbagi menjadi dua jenis yaitu sistem alamiah dan sistem buatan manusia. Suatu sistem dikatakan sebagai sistem alamiah jika interaksi antara elemen-elemen yang ada dalam sistem tersebut telah ada sebelumnya tanpa campur tangan manusia, seperti sistem tata surya dan sistem peredaran darah pada manusia. Sistem buatan manusia, sistem yang diciptaan oleh manusia, terbagi menjadi dua yakni manual dan terotomasi. Jika interaksi antara elemen-elemen yang ada berjalan secara manual, maka sistem tersebut dikatakan sistem manual. Sebaliknya, jika interaksi antara elemenelemennya dikendalikan oleh sistem komputer, maka disebut sebagai sistem terotomasi. Sistem terotomasi terbagi menjadi beberapa kategori, antara lain : 1. On-line System On-line System adalah sistem yang menerima input pada bagian dimana input tersebut didokumentasikan dan selanjutnya menghasilkan output yang berupa hasil komputasi pada area yang dibutuhkan. Sistem ini biasanya diaplikasikan pada reservasi angkutan umum, pengisian rencana studi pada beberapa perguruan tinggi, sistem perbankan, dan sebagainya. 2. Real-time System Real-time System merupakan suatu mekanisme pengawasan, dokumentasi data, pemrosesan yang sangat cepat hingga output yang dihasilkan bisa diterima dalam waktu yang relatif sama. Sistem ini biasanya diaplikasikan pada sistem airport traffic controller, Anjungan Tunai Mandiri dan sebagainya. 3. Decision Support Systems Decision Support Systems merupakan sistem yang membantu pihak manajemen perusahaan dalam pengambilan keputusan berdasarkan berbagai informasi dan kendala yang ada. 4. Strategic Planning Systems Strategic Planning Systems merupakan sistem yang memproses transaksi organisasi pada periode tertentu, mendokumentasikannya dan selanjutnya menghasilkan output berupa perencanaan-perencanaan kedepannya dengan mempertimbangkan berbagai informasi yang diterima.



11

5. Knowledge Based Systems Knowledge Based Systems merupakan sistem canggih yang menggunakan perangkat khusus dalam aplikasinya dimana sistem ini didesain sedemikian rupa agar memiliki kemampuan layaknya seorang ahli. Secara sederhana sistem memproses input untuk selanjutnya menjadi output yang dapat memberikan informasi bagi para pemakainya. Sistem yang merupakan kumpulan ide-ide dan konsep serta dapat melakukan berbagai fungsi untuk menghasilkan informasi yang berguna bagi pemakai atau manajemen dalam mengambil keputusan disebut sebagai suatu sistem informasi. Ada lima elemen dasar yang mendukung suatu sistem informasi, yaitu : 1. Perangkat keras (hardware), berupa seperangkat komputer, printer, wireless port, modem, dan sebagainya. 2. Perangkat lunak (software), berupa perangkat aplikasi pemrograman komputer. 3. File, yakni sekumpulan records atau data yang tersimpan, memiliki jenis dengan panjang elemen dan atribut yang sama, namun berbeda-beda nilai datanya. 4. Prosedur, terdiri dari serangkaian syarat-syarat dan berbagai aturan yang harus dipenuhi. 5. Personil, yakni manusia sebagai pendukung sistem tersebut; operator komputer, analisis sistem dan pemrograman. Sistem informasi banyak diterapkan perusahaan sebagai salah satu elemen dalam pengambilan keputusan oleh pihak manajemen. Suatu sistem diharapkan dapat melakukan pengolahan berbagai jenis data yang ada, selanjutnya mengolah data tersebut dengan cepat untuk menghasilkan output yang tepat, akurat dan terpercaya. Salah satu sistem yang banyak



12

digunakan dan dikelola secara terintegrasi dalam satu perusahaan adalah sistem ERP.

2.2 SISTEM ENTERPRISE RESOURCE PLANNING 2.2.1 Pengertian Sistem ERP Sistem Enterprise Resource Planning (ERP) berawal dari penemuan sistem Material Requirements Planning (MRP I) yang berkembang menjadi Manufacturing Resource Planning (MRP II) dan sekarang kita kenal dengan istilah sistem ERP. MRP I mengaplikasikan sistem perencanaan dan pengendalian produksi yang terkomputerisasi antar lini produksi. Sistem ini bertanggung jawab dalam penjadwalan seluruh kegiatan produksi yang terintegrasi, seperti mengeluarkan perintah produksi dan nota pembelian (Purchasing Order) serta memfasilitasi perubahan-perubahan yang mungkin terjadi jika dianggap perlu.4 Dalam sistem MRP, terdapat informasi mengenai proses produksi yang sedang berjalan berkenaan dengan penjadwalan dan kapasitas produksi untuk menentukan berbagai penyesuaian yang harus dilakukan jika nantinya ada perubahanperubahan pada input sistem. Pada sistem MRP, input yang masuk adalah identitas dan struktur produk, daftar bahan dan material dan informasi mengenai persediaan di gudang bahan baku. Sedangkan output dari sistem MRP adalah perintah produksi yang terencana, laporan kebutuhan dan beban kerja sumber daya yang ada, serta keadaan persediaan yang telah diproyeksikan. Untuk lebih jelasnya, bisa dilihat pada gambar 2.1 dibawah ini.

4

Roberta S. Russell dan Bernard W. Taylor III. Operation Management: Focusing on Quality and Competitiveness, Prentice Hall International, Inc., New Jersey. 1998. Universitas Indonesia


13

Gambar 2.1 Struktur dari sistem MRP5 Sistem ERP merupakan pembaharuan dari sistem MRP II yang dilengkapi dengan database manajemen yang saling berhubungan, user interfaces dan server architecture. Sistem ERP adalah suatu sistem informasi berbasis komputer yang terdiri dari beberapa elemen dengan fungsi dan tugasnya masing-masing – disebut dengan modul – yang saling terintegrasi.6 Jika ada perubahan data pada salah satu modul, maka secara otomatis akan disesuaikan pada modul yang lain. Sistem ini akan mengintegrasikan semua proses yang ada dalam suatu perusahaan, mulai dari pembelian barang, manajemen gudang, penjualan hingga pada laporan keuangan perusahaan. Sistem ERP menjamin adanya integrasi data tanpa menimbulkan redutansi data, yaitu kemungkinan terjadinya duplikasi data pada beberapa modul dan bisa mengakibatkan data tidak valid. Penerapan sistem ERP menuntut penggunaan piranti lunak khusus yang biasa disebut dengan software ERP. Software ERP didesain untuk memodelkan dan mengoptimasi proses-proses dasar pada suatu sistem dalam perusahaan. 5

Khalid Sheikh. Manufacturing Resource Planning (MRP II) with introduction to ERP, SCM and CRM, McGraw Hill, Mumbai, 2002, hal.64. 6 Khalid Sheikh. Manufacturing Resource Planning (MRP II) with introduction to ERP, SCM and CRM, hal.175. Universitas Indonesia


14

Jenisnya pun beragam, tergantung dari vendor yang mengeluarkannya. Diantaranya ada BAAN, Oracle, PeopleSoft, SAP, J.D. Edwards, dan lainnya. Gambar 2.2 menunjukkan bagaimana informasi terintegrasi dalam perusahaan dengan menggunakan sistem ERP.7

Gambar 2.2 Integrasi sisem informasi pada sistem ERP8 2.2.2 Modul Sistem ERP Secara nyata, sistem ERP memiliki ruang lingkup yang luas dan sangat fleksibel dalam penerapannya. Setiap perusahaan akan memiliki metode implementasi yang berbeda, tergantung dari perangkat, proses bisnis dan sumber daya yang ada. Oleh karena itu, sistem ERP yang diterapkan antar perusahaan biasanya dibatasi oleh modul yang digunakan. Semakin banyak modul yang dipakai sebagai bagian dari sistem ERP, maka akan semakin kompleks penerapannya. Modul-modul yang biasanya digunakan dalam aplikasi sistem ERP antara 9

lain : 7

Alexis Leon. Enterprise Resource Planning. McGraw Hill, New Delhi, 2000, hal.4. 8 Alexis Leon. Enterprise Resource Planning, hal.5. 9 Daniel E. O`Leary. Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk. Cambridge University Press, United Kingdom, 2000, hal.31-32. Universitas Indonesia


15

1. Modul AM untuk Fixed Asset Management yang berisikan rangkaian informasi yang berhubungan dengan tingkat depresiasi, nilai property, skema asuransi, dan lainnya. 2. Modul CO untuk Controlling yang berisikan sub-modul CCA (Cost Center Accounting), AP (Account Payable) dan ABC (Activity Based Costing). 3. Modul FI untuk Financial Accounting yang berisikan sub-modul GL (General Ledger), AR (Account Receivable), AP (Account Payable) dan LC (Legal Consolidation). 4. Modul HR untuk Human Resources yang berisikan sub-modul PA (Personnel Administration) dan PD (Planning and Development). 5. Modul MM untuk Material Management yang berisikan sub-modul IM (Inventory Management), IV (Invoice Verification) dan WM (Warehouse Management). 6. Modul PM untuk Plant Maintenance yang berisikan sub-modul EQM (Equipment and Technical Object), PRM (Preventive Maintenance), SMA (Service Maintenance), dan WOC (Maintenance Order Management). 7. Modul PP untuk Production Planning yang berisikan sub-modul SOP (Sales and Operation Planning), MRP (Material Requirements Planning), dan CRP (Capacity Requirements Planning). 8. Modul PS untuk Project Systems yang berisikan sub-modul PR (Project Tracking) dan BM (Budget management). 9. Modul QM untuk Quality Management yang berisikan sub-modul CA (Quality Certificates), IM (Inspection Processing) dan PT (Planning Tools). 10. Modul SD untuk sistem Sales and Distribution. Modul-modul diatas berfungsi sesuai dengan nama dan jenisnya. Namun, penggunaannya secara teknis akan sangat bergantung dengan vendor yang mengeluarkan piranti lunak yang dipakai.



16

2.2.3 Tujuan Implementasi Sistem ERP Hingga saat ini, banyak perusahaan yang menerapkan sistem ERP dan berharap akan mendapatkan banyak keuntungan. Beberapa alasan yang membuat perusahaan bersedia mereformasi sistem yang telah ada dengan sistem ERP adalah:10 1. Sistem ERP memungkinkan peningkatan performa bisnis, yakni dengan z

Mengurangi cycle time

z

Meningkatkan kemampuan proses bisnis

z

Mengurangi persediaan

z

Memenuhi pemesanan barang dengan tepat

2. Sistem ERP mendukung petumbuhan bisnis, yakni dengan z

Pembuatan lini produksi baru

z

Pencapaian konsumen potensial

3. Sistem ERP mendukung pengambilan keputusan yang fleksibel, terintegrasi dan real-time, yakni dengan meningkatkan responsiveness internal organisasi. 4. Sistem ERP mengeliminasi proses yang tidak efektif, antara lain z

Fragmentasi data dan proses

z

Perubahan yang tidak fleksibel

z

Teknologi yang kurang memadai, dan sebagainya

Selain itu sistem ERP akan memberikan nilai tambah, terutama dalam hal standarisasi

sistem

organisasi,

mengeliminasi

ketidaksimetrisan

data,

menyediakan informasi secara on-line dan real-time, serta nilai lain yang jadi keunggulannya.11

2.2.4 Implementasi Sistem ERP Sistem ERP yang berkembang di dunia industri merupakan rangkaian sistem yang terdiri dari beberapa prosedur yang kompleks. Oleh sebab itu, sistem ERP sangat menyesuaikan kondisi dari tiap-tiap perusahaan yang menerapkannya.

10

Alexis Leon. Enterprise Resource Planning, hal.6. Daniel E. O`Leary. Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, hal.7-9.

11



17

Perbedaan iklim kerja, proses bisnis, kualitas tenaga kerja dan keterbatasan sumber daya lainnya akan menjadi faktor kunci bagi perusahaan dalam melakukan pemilihan serta penyesuaian vendor dan modul ERP yang akan digunakan. Ada beberapa metode yang digunakan perusahaan untuk menjadi awal implemenasi sistem ERP, antara lain: 1. Big-Bang Metode ini mengharuskan perusahaan untuk segera meninggalkan proses bisnis konvensional yang selama ini diterapkan. Keseluruhan rangkaian dan prosedur proses bisnis diganti secara drastis dan disesuaikan dengan sistem ERP yang diterapkan. Perusahaan mencoba mengimplementasikan sistem ERP secara utuh dan terintegrasi pada seluruh area kerja, sehingga perombakan dan penyesuaian harus dilakukan di seluruh lini atau bagian perusahaan. Keunggulan metode ini terlihat dari waktu pengerjaan proyek yang akan lebih sedikit serta perusahaan cenderung lebih fokus pada implementasi sistem ERP yang berjalan. Sebaliknya, investasi dana yang dikeluarkan serta pengorbanan karyawan untuk merubah standar dan prosedur kerja akan sangat besar. 2. Franchising Pada strategi ini, perusahaan mengimplementasikan sistem ERP secara bertahap. Pada awalnya akan dilakukan uji coba pada salah satu bagian yang tidak akan berpengaruh signifikan terhadap kinerja perusahaan jika ternyata gagal diterapkan. Perusahaan cenderung menyewa pihak luar atau konsultan untuk mengembangkan bisnis proses yang ada, baru kemudian dilakukan penyesuaian pada bagian yang bersangkutan. Jika uji coba berhasil

dilakukan,

maka

perusahaan

akan

langsung

mengimplementasikan sistem ERP pada bagian-bagian lain layaknya efek domino. Metode ini sangat banyak diterapkan perusahaan-perusahaan di Indonesia. Selain faktor pengeluaran investasi yang cenderung aman, perusahaan

dapat

langsung

melihat

efek

sistem

ERP

yang

diimplementasikan secara nyata sebelum menerapkannya di seluruh perusahaan. Namun, perusahaan akan kesulitan menyesuaikan proses bisnis yang ada berkaitan dengan transformasi data pada modul-modul



18

berbeda.

Metode

inilah

yang

paling

banyak

menghasilkan

ketidakharmonisan data, jika tidak diterapkan secara tepat. 3. Slam-Dunk Jika perusahaan beranggapan melakukan perubahan drastis pada proses bisnis yang ada akan sangat beresiko kedepannya, maka dapat menggunakan

metode

Slam-Dunk.

Perusahaan

hanya

mengimplementasikan sistem ERP secara parsial, dengan menggunakan satu atau dua modul yang dianggap signifikan memberikan kontribusi positif. Sehingga, proses bisnis dan budaya kerja tidak akan banyak berubah. Untuk memudahkan memahami implementasi sistem ERP secara nyata, maka akan dijelaskan dengan menggunakan contoh konkrit di perusahaan. Penerapan sistem ERP dapat dilihat pada aspek-aspek sesuai dengan aktivitas dibawah ini:12 1. Pemesanan (Ordering) Bagian penjualan akan menerima pesanan dari retailer atau pelanggan. Selanjutnya data pesanan ini akan di-input ke dalam sistem dengan menggunakan modul yang sesuai. Sistem akan melakukan pengecekan dan kalkulasi terhadap biaya yang akan dibayarkan sekaligus perhitungan kompensasi lainnya, seperti potongan harga, pengembalian dan lainnya. Sistem juga akan melihat data historis pelanggan tersebut untuk menentukan mekanisme pembayaran yang tepat. 2. Ketersediaan (Availability) Setelah adanya input pesanan dari bagian penjualan, maka kemudian sistem akan melihat tingkat ketersediaan barang di gudang. Sistem ERP akan terasa lebih efektif, jika perusahaan memiliki produk yang terdeferensiasi dan tersebar dibeberapa gudang. Jika persediaan barang tidak dapat memenuhi jumlah permintaan, maka sistem secara otomatis akan meminta pengiriman barang dari pabrik atau gudang lainnya. 3. Produksi (Production)

12

Daniel E. O`Leary. Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, hal.36-37. Universitas Indonesia


19

Jika barang yang ada digudang berada dibawah jumlah minimumnya, maka sistem akan mengingatkan bagian gudang untuk melakukan pengiriman barang dari pabrik. Selanjutnya, modul produksi pada sistem ERP yang digunakan akan melakukan perencanaan produksi dan mengeluarkan perintah produksi untuk memenuhi permintaan tersebut. 4. Tenaga Kerja (Manpower) Ketika

melakukan

perencanaan

produksi,

sistem

juga

akan

memperhitungkan berbagai sumber daya yang ada, termasuk tenaga kerja. Sistem secara otomatis akan melakukan

pengalokasian, perhitungan

kebutuhan dan kompensasi tenaga kerja. Jika jumlah yang diproduksi melebihi jam kerja pabrik, maka sistem akan mengkalkulasi kebutuhan sekaligus merekomendasikan untuk lembur atau melakukan perekrutan tenaga kerja kontrak atau sementara. 5. Pembelian (Purchasing) Setelah proses produksi, modul Material Planning pada sistem akan mengingatkan bagian pembelian untuk melakukan pemesanan bahan baku pada pemasok. Sistem juga akan menunjukkan identitas material, jumlah dan biaya yang dibutuhkan perusahaan untuk memenuhi gudang persediaan bahan bakunya. 6. Penelusuran Pesanan (Order Tracking and More Ordering) Beberapa

perusahaan

memperbolehkan

konsumen,

retailer

atau

distributor, untuk bisa mengakses sistem ERP yang digunakan. Dengan demikian, pihak retailer atau distributor bisa melakukan pengecekan langsung mengenai status pesanan mereka dan kemudian mendapatkan pertimbangan kapan dan berapa pemesanan berikutnya. Bisa dilihat dari pemaparan diatas, bahwasanya penerapan sistem ERP meliputi keseluruhan aspek dari kegiatan operasional karyawan. Oleh karena itu, penerapan sistem ERP secara tepat semestinya akan memberikan banyak manfaat pada perusahaan.



20

2.2.5 Evaluasi Implementasi Sistem ERP Penerapan sistem ERP secara menyeluruh akan membutuhkan investasi yang sangat besar sekali, selain waktu pengerjaan yang relatif lama. Oleh karena itu, banyak sekali perusahaan yang kesulitan untuk melakukan evaluasi dan melihat sampai sejauh mana sistem ERP memberikan kontribusi positif pada perusahaan. Pada akhirnya perusahaan hanya bisa meraba-raba dan langsung menjustifikasi telah berhasil menerapkan sistem ERP tanpa melakukan perhitungan yang tepat. Dua patokan yang sering dijadikan tolak ukur keberhasilan implementasi sistem ERP adalah kontribusi moneter dan nonmoneter.13 Kontribusi secara moneter akan lebih terfokus pada aspek-aspek keuangan perusahaan.

Pihak

manajemen

akan

mengatakan

telah

berhasil

dalam

implementasi sistem ERP jika setelah pengaplikasiannya terjadi peningkatan penjualan yang berujung pada peningkatan margin keuntungan perusahaan. Sebaliknya, kontribusi non-moneter akan lebih fokus pada proses bisnis yang ada. Suatu perusahaan akan dikatakan berhasil mengimplemetasikan sistem ERP jika telah mengoptimalkan proses bisnis yang ada, seperti waktu proses yang lebih cepat, utilisasi dan produktivitas yang meningkat, ketersediaan berbagai data secara cepat dan akurat, dan sebagainya. Ada beberapa metode yang biasanya dipakai untuk melihat sampai sejauh mana sistem ERP memberikan kontibusi pada perusahaan, baik itu secara moneter maupun non-moneter. Metode tersebut adalah Key Performance Index, Balance Score Card dan Oliver Wight ABCD Checklist.

2.2.6 Kegagalan Implementasi Sistem ERP Diatas kertas, sistem ERP merupakan prosedur atau metode terbaik yang dapat diterapkan perusahaan untuk berbagai pekerjaan yang berbeda, seperti aspek keuangan, proses dan pengendalian produksi, pemeliharaan, logistik, penjualan, pembelian dan distribusi serta aspek-aspek lainnya dalam perusahaan. Untuk mendapatkan hasil yang terbaik, selain mengikuti prosedur dan standar yang ada 13

Daniel E. O`Leary, Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, hal.97. Universitas Indonesia


21

dalam pengimplementasian sistem ERP, perusahaan juga harus memiliki orangorang atau karyawan yang mampu dan mau serta memiliki komitmen untuk menjalankan sistem ERP. Jika terdapat kesenjangan antara sistem dengan tenaga kerja yang ada, maka akan dilakukan penyesuaian yang sering kali mengganggu kestabilan dan kinerja sistem yang berjalan. Dengan kata lain, sistem diatur sedemikian rupa untuk mengikuti kemauan tenaga kerja yang belum tentu efektif jika dilihat dari penerapan sistem ERP. Akibatnya, sistem akan labil dan berpotensi untuk menghasilkan masalah-masalah baru yang sebenarnya dapat dihindari. Sistem informasi yang terintegrasi pada sistem ERP berpengaruh pada kepekaan elemenelemen yang ada didalamnya. Jika terjadi kerusakan pada salah satu elemen, maka akan beakibat pada elemen-elemen yang lain dan mempengaruhi kinerja sistem secara keseluruhan. Jika hal ini terjadi, maka perusahaan dapat dikatakan gagal mengimplementasikan sistem ERP. 2.3 RISIKO Risiko memiliki definisi yang berbeda-beda sesuai dengan konteks ruang lingkupnya. Secara sederhana, risiko dapat diartikan sebagai kemungkinan untuk mengalami kerugian. Berdasarkan kamus American Heritage risiko didefinisikan sebagai kemungkinan mengalami kerugian; sebuah faktor atau elemen yang mengandung bahaya yang tidak pasti. Dengan kata lain risiko merupakan ukuran probabilitas dari suatu kejadian yang terjadi (perubahan yang tidak diinginkan) dan menimbulkan dampak dari kejadian tersebut. Risiko terdiri dari tiga komponen utama yaitu kejadia risiko (perubahan yang tidak diinginkan), probabilitas terjadinya risiko, serta dampak yang ditimbulkan. Risiko sering diidentikkan dengan probabilitas. Namun untuk penilai risiko profesional, risiko menggabungkan probabilitas negatif suatu peristiwa dengan bahayanya. Dari sisi engineering, risiko didefinisikan sebagai hasil perkalian probabilitas terjadian suatu kerjadia dengan dampak yang ditimbulkan. Berdasarkan sumbernya risiko dapat diklasifikasikan sebagai berikut: 1. Risiko finansial dan nonfinansial Risiko nonfinansial tidak memiliki akibat finansial, sedangkan risiko finansial menyebabkan kerugian finansial. Risiko finansial terdiri dari elemen



22

yaitu individu / organisasi yang membawa risiko, aset / pendapatan yang hilang karena adanya risiko finansial, sebuah peril yang menyebabkan kerugian. 2. Risiko statis dan dinamis Risiko dinamis adalah akibat dari perubahan perekonomian, yang bisa muncul karena lingkungan eksternal, yaitu perekonomian, perindustrian, pesaing dan konsumen. Perubahan ini tidak terkontrol tetapi berpotensi mendatangkan kerugian bagi perusahaan. Risiko dinamis sulit untuk dideteksi. Sedangkan risiko statis adalah kerugian yang terjadi meskipun tidak ada perubahan perekonomian. Risiko statis tidak bersumber dari masyarakat sehingga mudah diprediksi dan diatasi. 3. Risiko murni dan spekulatif Risiko spekulatif adalah kemungkinan yang membawa kepada keuntungan atau kerugian, sedangkan risiko murni terjaadi pada situasi di mana hanya ada satu kerugian atau keuntungan. 4. Risiko fundamental Risiko fundamental adalah kerugian impersonal, baik penyebab maupun akibatnya. Dia adalah kumpulan risiko yang menyebabkan fenomena politik, ekonomi, dan sosial, meskipun bisa saja hasil dari kejadian fisik. Contohnya adalah pengangguran, perang, inflasi, gempa, banjir, dll. Sedangkan risiko partikular adalah risiko yang disebabkan oleh kejadian individual, misalnya kebakaran rumah dan perampokan bank.

2.4 MANAJEMEN PROYEK 2.4.1 Karakteristik Proyek Proyek merupakan suatu kegiatan (usaha) yang bersifat sementara yang dilakukan untuk menciptakan sebuah produk, jasa atau hasil yang unik. Secara umum proyek mempunyai 3 karakteristik yaitu besifat sementara (temporary), mempunyai hasil yang unik dan progressive elaboration. Proyek bersifat sementara (temporary) menunjukkan bahwa setiap proyek mempunyai sebuah permulaan dan sebuah titik akhir yang pasti. Titik akhir akan Universitas Indonesia


23

dicapai apabila tujuan proyek telah dicapai atau proyek tersebut berakhir karena tujuan proyek tidak dapat dicapai. Temporary bukan berarti bahwa setiap proyek mempunyai durasi yang singkat, banyak proyek yang berlangsung selama beberapa tahun. Karakter temporary lebih menunjukkan bahwa adanya batasan durasi pengerjaan proyek. Sebuah proyek menciptakan hasil berupa produk, jasa atau hasil yang unik. Proyek menciptakan sebuah produk atau benda yang dapat dihitung baik berupa hasil akhir atau hasil berupa komponen item. Keunikan merupakan karakter yang paling penting dari sebuah hasil proyek. Sebagi contoh, ribuan gedung perkantoran dibangun, namun setiap gedung mempunyai fasilitas tersendiri yang unik seperti pemilik yang berbeda, desain yang berbeda, lokasi yang berbeda, kontraktor yang berbeda dan lain-lain. Progressive elaboration adalah karakteristik proyek yang menyertai konsep sementara dan unik. Karakteristik

progressive

elaboration

meenunjukkan

bahwa

proyek

dikembangkan dalam beberapa langkah dan peningkatan yang berkelanjutan.

2.4.2 Daur Hidup Proyek Semua proyek adalah unik. Oleh karena itu, setiap proyek sebaiknya didokumentasikan dengan baik untuk menunjukkan daur hidup proyek yang unik. Daur hidup proyek terdiri dari empat tahap utama yaitu penujian kelayakan, desain dan perencanaan, konstruksi, serta permulaan pemakaian dan ambil alih. 2.4.2.1 Pengujian Kelayakan Proyek Aspek pertama yang perlu diperhatikan dari sebuah proyek adalah konsep proyek yang mencakup banyak hal penting. Konsep proyek yang realistis dan masuk akal harus memenuhi beberapa kriteria berikut: 1. Proyek dapat dibangun dan didirikan secara fisik 2. Terdapat teknologi dan keahlian yang mampu menjadikan proyek dapat dilaksanakan secara konsisten 3. Mempunyai keuntungan yang diinginkan Selanjutnya untuk menciptakan konsep dasar proyek perlu



24

dikembangkan sebuah perhitungan proyek yang detail. Hal ini meliputi studi kelayakan untuk menentukan apakah konsep dasar yang telah dibuat sebelumnya memenuhi semua kriteria di atas. 2.4.2.2 Perencanaan dan Desain Tahap perencanaan dan desain dari daur hidup proyek secara umum mencakup perumusan strategi lanjutan, perencanaan dan desain pelaksanaan. Selama tahap ini parameter utama pelaksanaan proyek harus dirancang dengan baik. Tahap ini meliputi : 1. Jenis kontrak 2. Mekanisme penyelesaian proyek 3. Kebutuhan jadwal utama 4. Kebutuhan biaya utama 5. Perencanaan yang detail mencakup proses manajemen proyek seperti struktur organisasi, sumber daya, pengadaan, dan perubahan ruang lingkup Selanjutnya dilakukan penurunan parameter pelaksanaan dasar yang akan digunakan pada tahap selanjutnya. Perencanaan yang detail ini akan dapat membantu tercapainya proses implementasi yang efektif. Tujuan dari tahap perencanaan dan desain ini terhadap daur hidup proyek adalah memperkirakan kontrak dasar. 2.4.2.3 Konstruksi Tahap konstruksi daur hidup proyek merupakan pelaksanaan aktual dari ruang lingkup pekerjaan fisik proyek mulai dari penyelesaian perencanaan detail sampai konstruksi pada lokasi proyek. Tahap konstruksi terdiri dari beberapa komponen pekerjaan utama antara lain: a. Pengadaan material dan peralatan b. Pabrikasi dan pengiriman peralatan utama c. Mobilisasi d. Pekerjaan lokasi dan sosialisasi warga e. Pekerjaan pembangunan secara umum f. Penginstalan peralatan g. Pekerjaan mekanik h. Pekerjaan elektris Universitas Indonesia


25

i. Pekerjaan kontrol dan instrumental Secara teori pendefinisian tahap konstruksi secara umum memang sangat sederhana, namun pada kenyataannya tahap ini membutuhkan beberapa keputusan, tindakan, dan tugas individu untuk mencapai tujuan proyek yang telah dibuat pada tahap awal. Perlu diingat bahwa tindakan ini dilakukan bersama-sama dengan pelaksanaan konteks yang dibuat selama 2 tahap sebelumnya. Tujuan utama dari tahap ini adalah untuk mencapai penyelesaian dasar. 2.4.2.3 Permulaan Pemakaian dan Ambil Alih Tahap akhir dari daur hidup proyek adalah stratup dan turnover yang terdiri dari beberapa komponen utama seperti : a. Pengujian akhir b. Pembayaran c. Pergantian sistem d. Penutupan kontrak e. Permulaan pengoperasian dan pemeliharaan Pelaksanaan permulaan pemakaian dan penutupan secara langsung berhubungan dengan kompleksitas dari proyek yang dilaksanakan. Jika teknologi yang dilibatkan dalam proyek tertentu tidak diuji atau merupakan teknologi baru maka durasi pelaksanaan tahap ini akan semakin lama. Tujuan dari tahap ini adalah untuk penyelesaian dan penyerahan proyek.

2.4.3 Manajemen Proyek Manajemen proyek adalah pengaplikasian ilmu, keahlian, alat, dan teknik ke dalam akitivitas proyek dalam memenuhi kebutuhan proyek 8 . Manajemen proyek dilakukan melalui aplikasi dan integrasi proses perencanaan, eksekusi, pengawasan dan pengontrolan manajemen proyek. Dalam sebuah proyek dibutuhkan seorang manejer proyek. Manejer proyek adalah orang yang bertanggung jawab terhadap pencapaian tujuan proyek. Manajemen sebuah proyek mencakup : 1. Identifikasi kebutuhan proyek 2. Mengembangkan tujuan yang jelas dan dapat dicapai 3. Menyeimbangkan kualitas, jangkauan, waktu dan biaya proyek Universitas Indonesia


26

4. Menyesuaikan spesifikasi, rencana, serta pendekatan perhatian atau ekspektasi yang berbeda terhadap stakeholder yang bervariasi Manejer proyek harus selalu memperhatikan “triple constraint” dalam mengelola persaingan kebutuhan proyek yaitu waktu, biaya dan cakupan proyek. Keseimbangan ketiga faktor ini akan mempengaruhi kualitas proyek. Proyek yang berkualitas tinggi akan dapat menciptakan produk, jasa atau hasil yang diinginkan dalam cakupan, waktu dan anggaran biaya yang ditetapkan. Ketiga faktor ini mempunyai hubungan yang erat, perubahan pada salah satu faktor akan mempengaruhi hasil pada faktor lainnya. Manejer proyek juga bertanggung jawab terhadap ketidakpastian. Risiko proyek adalah sebuah kejadian atau kondisi yang tidak pasti dimana jika risiko terjadi akan menimbulkan pengaruh positif atau negatif terhadap tujuan proyek. Istilah manajemen proyek sering digunakan untuk menggambarkan sebuah pendekatan organisasi atau manejerial ke dalam pengelolaan proyek dan beberapa kegiatan yang berkelanjutan yang dapat didefinisikan ulang sebagai proyek yang dikenal dengan istilah “management by project”. Hal ini menunjukkan bahwa tidak semua aktivitas dapat atau harus diatur ke dalam proyek. Manajemen proyek terdiri dari sembilan proses utama yaitu manajemen pengintegrasian proyek, manajemen ruang lingkup proyek, manajemen waktu proyek, manajemen biaya proyek, manajemen kualitas proyek, manajemen sumber daya manusia proyek, manajemen komunikasi proyek, manajemen risiko proyek dan manajemen pengadaan proyek. Kesembilan proses ini saling berhubungan dimana setiap proses terdiri dari beberapa tahap penting seperti yang terlihat pada gambar 2.1 di bawah ini.



27

Gambar 2.3 Proses manajemen proyek (Sumber: Project Management Institute,2004, hal.11) 2.5 MANAJEMEN RISIKO PROYEK 2.5.1 Manfaat Manajemen Risiko Proyek Setiap risiko berpotensi untuk mempersulit dan menghambat penyelesaian sebuah kegiatan dan pencapaian tujuan. Risiko terdapat dalam setiap proyek, sehingga risiko tidak dapat dihilangkan sepenuhnya, namun kita dapat mengelola risiko dengan efektif untuk mengurangi dampak negatif terhadap pencapaian tujaun proyek. Dalam beberapa proyek, untuk mencapai tujuan proyek, risiko harus dikelola dan diintegrasikan ke dalam unsur pokok manajemen proyek secara keseluruhan9. Manajemen risiko adalah proses perencanaan, identifikasi, analisis, penanganan dana pengawasan risiko proyek secara sistematis. Manajemen risiko melibatkan beberapa proses, alat dan teknik yang dapat membantu manejer proyek



28

untuk memaksimalkan probabilitas dan dampak dari kejadian positif atau peluang serta meminimalisasi probabilitas dan dampak dari kejadian negatif atau ancaman. Manajemen risiko proyek akan lebih efektif jika dimulai sejak awal daur hidup proyek dan dilanjutkan selama proyek dilaksanakan14. Tujuan dari manajemen risiko adalah untuk meningkatkan probabilitas dan dampak dari kejadian yang berdampak prositif terhadap proyek serta mengurangi probabilitas dan dampak dari kejadian yang merugikan proyek. Organisasi dapat menjadi sukses jika organisasi mempunyai komitmen untuk melakukan manajemen risiko secara proaktif dan konsisten sepanjang daur hidup proyek15. Manajemen proyek harus dikembangkan dengan pengalaman yang membawa kita mencapai proses yang lebih baik seiring dengan peningkatan kompleksitas proyek16. Dengan menerapkan manajemen risiko dalam mengelola proyek maka kombinasi kedua proses ini akan dapat meningkatkan nilai tambah terhadap organisasi dan dapat meningkatkan efisiensi dari proyek itu sendiri17. Siklus hidup proyek terdiri dari beberapa tahap dan langkah yang berurutan mulai dari awal perencanaan sampai tahap penyelesaian. Selama pelaksanaan tahap-tahap tersebut sering muncul beberapa risiko yang menggangu pencapaian tujuan proyek. Oleh karena itu, identifikasi sumber risiko menjadi tugas pertama dan utama dari manejer proyek. Manajer proyek harus sensitive terhadap sumber risiko yang berpotensi membahayakan, harus mampu mengantisipasi kemungkinan terjadinya risiko dan menilai dampak mereka terhadap tujuan proyek serta untuk mengurangi dampaknya pada masa yang akan datang serta harus mampu membuat manajemen strategi penanganan risiko tersebut. Risiko proyek adalah suatu kejadian atau kondisi yang tidak pasti, jika terjadi maka akan menimbulkan dampak positif atau negatif terhadap tujuan 14

Office of Project Management Process Improvement, “Project Risk

Management Handbook” First Edition, Sacramento, 2003, p.2. 15 16 17

Project Management Institute, Op.Cit., p. 237. Roger W Stewart dan Joyce Fortune, Op.Cit., p.279. D K Kohlmeyer dan J K Visse , Po.Cit., p.79. Universitas Indonesia


29

proyek seperti waktu, biaya, cakupan atau kualitas. Sebuah risiko mungkin mempunyai satu atau lebih dari satu penyebab, dan jika risiko terjadi mungkin juga akan menimbulkan satu atau lebih banyak dampak. Kondisi risiko mencakup beberapa aspek dari lingkungan organisasi atau lingkungan proyek yang dapat menimbulkan risiko proyek seperti manajemen proyek yang kurang baik, kurangnya manajemen sistem yang terintegrasi, sejumlah proyek dilaksanakan dalam waktu yang bersamaan, ketergantungan pada pihak luar yang tidak dapat dikontrol. Terdapat hubungan yang kuat antara kuantitas dan kualitas manajemen risiko yang diterapkan dalam proyek dengan tingkat kesuksesan proyek itu sendiri dimana proyek akan lebih sukses apabila menerapkan manajemen risiko secara tepat dalam manajemen proyek. Penerapan manajemen risiko lebih awal pada proyek juga akan memberikan tingkat kesuksesan yang lebih tinggi terhadap proyek. Ada beberapa manfaat yang diperoleh melalui penerapaan manajemen risiko proyek yang bukan hanya terhadap manejer proyek melainkan juga pemasok, organisasi dan juga konsumen18. Manfaat tersebut antara lain : 1. Meningkatkan pemahaman terhadap proyek mengenai perumusan rencana yang realistis baik dalam biaya maupun jadwal proyek. 2. Meningkatkan pemahaman risiko proyek dan dampaknya yang dapat membantu meminimalisasi risiko yang akan dialokasikan ke pemasok yang lebih baik 3. Meningkatkan pemahaman dalam menentukan penggunaan jenis kontrak yang lebih tepat. 4. Membantu dalam pengambilan keputusan dan meningkatkan efektivitas dan efisiensi manajemen risiko 5. Membantu dalam pembuatan data informasi statistik berdasarkan risiko tahun lalu yang akan membantu dalam membuat model yang lebih baik pada proyek yang akan datang 6. Meningkatkan keuntungan yang diperoleh dari penerimaan risiko yang menguntungkan 18

The Association for Project Management, “Project Risk Analysis and

Management”,Buckinghamshire, 2000, p.4.



30

Melalui manajemen risiko proyek secara umum semua pihak akan diuntungkan antara lain organisasi dan senior manajemen, mitra kerja baik mitra internal maupun eksternal, serta manejer proyek yang ingin meningkatkan kualitas kerja, ketepatan waktu penyelesaian dan efektivitas biaya. Manajemen risiko proyek merupakan proses yang berkelanjutan yang dapat dimulai pada hamper semua tahap dalam daur hidup proyek. Karena efektivitas manajemen risiko akan berkurang pada saat tertentu dimana biaya yang dikeluarkan untuk risiko lebih besar dari keuntungan yang mungkin diperoleh, maka lebih menguntungkan apabila manajemen risiko mulai diterapkan sejak awal tahap perencanaan proyek atau tahap awal daur hidup proyek19.

2.5.2 Proses Manajemen Risiko Proyek Manajemen risiko proyek mencakup lima proses utama yaitu perencanaan manajemen risiko, identifikasi risiko, analisis risiko, penanganan risiko serta pengawasan dan pengontrolan risiko20. Sebagain besar proses ini selalu diperbaharui sepanjang pelaksanaan proyek. MANAK

19 20

The Association for Project Management, Ibid., p.5. Project Management Institute, Op.Cit., p.237. Universitas Indonesia


31

Gambar 2.4 Proses perencanaan manajemen risiko proyek (Sumber: Project Management Institute, 2004, hal.239) Gambar 2.4 di atas menunjukkan proses manajemen risiko secara umum yang mencakup masukan, proses dan hasil dari setiap proses. Secara umum manajemen risiko proyek dibagi dalam lima proses yaitu: 1. Perencanaan manajemen risiko, membahas mengenai keputusan tentang bagaimana melakukan pendekatan, perencanaan, dan pelaksanaan manajemen risiko pada setiap aktivitas dalam proyek.



32

2. Identifikasi risiko, menentukan risiko yang mungkin mempengaruhi proyek dan mendokumentasikan karakteristik risiko-risiko tersebut. 3. Analisis kualitatif risiko, menentukan prioritas risiko untuk selajutnya dilakukan analisis dengan mengkombinasikan probabilitas dan dampak dari risiko-risiko tersebut. 4. Analisis kuantitatif risiko, menganalisis secara kuantitatif dampak dari risiko yang teridentifikasi terhadap tujuan proyek secara keseluruhan 5. Perencanaan tindakan penanganan risiko, mengembangkan pilihan dan tindakan untuk meningkatkan kesempatan dan mengurangi ancaman terhadap tujuan proyek. 6. Pengawasan dan pengontrolan risiko, mengontrol dan mengamati risiko yang masih tersisa, mengidentifikasi risiko yang baru, melakukan tindakan penanganan, dan mengevaluasi efektivitas tindakan penanganan sepanjang daur hidup proyek. Kelima proses di atas saling berinteraksi antara proses yang satu dengan yang lain. Setiap proses dapat melibatkan satu atau beberapa orang dalam satu kelompok tergantung pada kebutuhan proyek. Setiap proses terjadi sedikitnya sekali dalam setiap proyek dan dilakukan dalam satu tahap proyek atau lebih jika proyek dibagi dalam beberapa tahap. 2.5.2.1 Perencanaan Manajemen Risiko Perencanaan yang teliti dan jelas dalam manajemen risiko dapat meningkatkan keberhasilan kelima proses lain dalam manajemen risiko proyek. Perencanaan manajemen risiko merupakan proses pengambilan keputusan mengenai bagaimana pendekatan dan melaksanakan aktivitas manajemen risiko pada sebuah proyek. Proses perencanaan manajemen risiko sangat penting untuk menjamin bahwa level, jenis dan wujud dari manajemen risiko adalah setingkat antara risiko dengan kepentingan proyek terhadap organisasi, untuk menyediakan sumber daya dan waktu yang cukup untuk aktivitas manajemen risiko, serta untuk menciptakan sebuah konsep dasar untuk melakukan evaluasi risiko. Proses perencanaan manajemen risiko seharusnya dilakukan pada awal perencanaan proyek. Gambar 2.5 di bawah ini menunjukkan proses dalam perencanaan manajemen risiko yang mencakup masukan, alat dan teknik serta hasil.



33

Gambar 2.5 Proses perencanaan manajemen risiko (Sumber: Project Management Institute, 2004, hal.242) Dalam proses perencanaan manajemen risiko proyek terdapat empat masukan yang digunakan untuk membuat perencanaan manajemen risiko yaitu ruang lingkup proyek, perencanaan manajemen proyek, faktor lingkungan perusahaan yang mencakup toleransi organisasi dan pihak yang terlibat dalam proyek akan mempengaruhi perencanaan manajemen risiko, serta proses organisasi dimana organisasi mungkin terlebih dahulu telah mendefinisikan pendekatan manajemen risiko seperti pengelompokan risiko, definisi umum dari konsep dan istilah, templet standar, peran dan tanggung jawab, level wewenang terhadap pengambilan keputusan. Dalam melakukan perencanaan manajemen risiko proyek, tim proyek dituntut untuk mengadakan rapat untuk mengembangkan perencanaan manajemen risiko. Beberapa pihak perusahaan harus dilibatkan dalam melakukan perencanaan seperti manejer proyek, anggota tim proyek dan stakeholder yang dipilih, atau pihak dalam organisasi yang bertanggung jawab untuk mengelola perencanaan risiko dan melaksanakan aktivitas dan lain-lain. Perencanaan dasar dalam melakukan aktivitas manajemen risiko dibahas dalam rapat tersebut. Elemen biaya risiko dan jadwal aktivitas juga perlu dikembangkan untuk diperhitungkan dalam anggaran dan jadwal proyek secara berturut-turut. Templet organisasi secara umum untuk pengelompokan risiko dan definisi dari istilah seperti tingkat risiko, probabilitas berdasarkan jenis risiko, dampak berdasarkan tujuan, serta matriks probabilitas - dampak perlu disesuaikan terhadap proyek yang spesifik.



34

Hasil yang diperoleh dari aktivitas perencanaan manajemen risiko ini antara lain: 1. Metodologi Mendefinisikan pendekatan, alat, dan sumber data yang mungkin digunakan untuk menerapkan manajemen risiko pada proyek. 2. Peran dan tanggung jawab Mendefinisikan pemimpin, pendukung, dan anggota tim manajemen risiko untuk setiap jenis aktivitas dalam perencanaan manajemen risiko, penugasan terhadap sebuah peran, dan mengklarifikasi tanggung jawab. 3. Anggaran Menugaskan sumber daya dan estimasi biaya yang dibutuhkan untuk manajemen risiko yang dilibatkan dalam anggaran dasar proyek. 4. Penjadwalan Mendefinisikan kapan dan seberapa sering proses manajemen dilakukan sepenjang daur hidup proyek, dan membuat aktivitas manajemen risiko yang akan dimasukkan ke dalam jadwal proyek. 5. Kategori risiko Menyediakan sebuah struktur yang menjamin sebuah proses yang sistematis dalam melakukan identifikasi risiko sehingga diperoleh tingkat detail yang konsisten dan mendukung efektivitas dan kualitas dari proses identifikasi risiko. Risk breakdown structure (RBS) seperti yang terlihat pada gambar 2.4 di bawah ini merupakan salah satu pendekatan yang biasa digunakan dalam pengelompokan risiko. Pengelompokan risiko berdasarkan proyek sebelumnya mungkin perlu disesuaikan atau diperluas dengan situasi baru sebelum pengelompokan itu digunakan pada proyek yang sedang dilaksanakan.



35

Gambar 2.6 Contoh kategori risiko berdasarkan RBS (Sumber: Project Management Institute, 2004, hal.244) 6. Definisi probabilitas dan dampak risiko risiko Kualitas dan tingkat kepercayaan dari proses analisis kualitatif risiko yang membedakan tingkat dari probabilitas dan dampak risiko perlu didefinisikan. Definisi umum dari tingkat risiko dan dampak disesuaikan dengan proyek secara individu selama proses perencanaan manajemen risiko untuk digunakan dalam proses analisis kualitatif risiko. Sebuah tingkatan risiko dengan menggunakan skala relatif yang merepresentasikan nilai probabilitas dari tingkat yang sangat jarang sampai hampir pasti dapat digunakan. Alternatif lain juga dapat dipakai dengan menggunakan angka numerik probabilitas skala umum seperti 0.1, 0.3, 0.5, 0.7, 0.9. Skala dampak menggambarkan tingkat dari dampak risiko baik dampak negatif maupun positif pada setiap tujuan proyek jika risiko terjadi. Skala dampak spesifik terhadap tujuan yang berpotensi dipengaruhi. Skala relatif untuk dampak dapat disederhanakan dengn menggunakan deskripsi seperti ”sangat rendah”, ”rendah”, ”sedang”, ”tinggi”, dan ”sangat tinggi” yang menggambarkan tingkat dampak dari yang terendah sampai yang tertinggi. Skala numerik dapat digunakan untuk menentukan nilai dampak. Universitas Indonesia


36

Nilai ini dapat bersifat linear seperti 0.1, 0.3, 0.5, 0.7, 0.9 atau non-linear seperti 0.05, 0.1, 0.2, 0.4, 0.8. Skala non-linear merepresentasikan keinginan organisasi untuk menolak ancaman dengan dampak yang tinggi sekalipun probabiltas risiko tersebut rendah. Dalam menggunakan skala non-linear sangat penting untuk mengetahui definisi dari angka tersebut dan hubungan yang satu dengan yang lain, bagaimana angka tersebut diperoleh dan pengaruh yang dimiliki terhadap setiap tujuan proyek. 7. Matriks probabilitas dan dampak Risiko diprioritaskan berdasarkan potensi implikasi risiko terhadap pencapaian tujuan proyek. Pendekatan untuk memprioritaskan risiko dapat menggunakan matriks probabilitas – dampak risiko. Kombinasi yang spesifik dari probabilitas dan dampak dari suatu risiko akan dinilai berdasarkan tingkat kepentingan seperti ”tinggi”, ”sedang”, atau ”rendah” yang berhubungan dengan tingkat kepentingan dari tindakan penanganan risiko pada tahap selanjutnya. 8. Toleransi perbaikan stakeholder Toleransi stakeholder dapat diperbaiki dalam proses perencanaan manajemen risiko yang diaplikasikan terhadap proyek yang spesifik. 9. Format laporan Mendeskripsikan isi dan format dari daftar risiko serta laporan risiko lain yang dibutuhkan. Mendefinisikan bagaimana hasil dari proses manajemen risiko didokumentasikan, dianalisis, dan dikomunikasikan. 10. Tracking Membuktikan bagaimana setiap sisi aktivitas risiko dicatat yang bermanfaat bagi proyek saat ini, kebutuhan yang akan datang. Membuktikan apakah dan bagaimana proses manajemen risiko diaudit. 2.5.2.2 Identifikasi Risiko Sebuah proyek identik dengan aktivitas dengan risiko yang tinggi. Kemampuan dalam mengidentifikasi risiko yang mungkin terjadi serta mengambil tindakan untuk menghindari risiko tersebut merupakan dua aspek utama dalam



37

mengelola proyek dengan baik21. Identifikasi risiko menentukan risiko mana yang mungkin

mempengaruhi

proyek

dan

mendokumentasikan

karakteristik

risikorisiko tersebut22. Pihak yang perlu dilibatkan dalam aktivitas identifikasi risiko antara lain manejer proyek, anggota tim proyek, tim manajemen risiko, ahli dari luar tim proyek, konsumen, dan manejer proyek yang lain, stakeholder dan ahli manajemen risiko. Identifikasi risiko merupakan sebuah proses iterasi karena risiko yang baru mungkin diketahui selama siklus hidupnya. Frekuensi iterasi dan pihak yang terlibat dalam setiap siklus berbeda dan bervariasi antara satu kasus dengan kasus yang lain. Tim proyek harus dilibatkan dalam proses sehingga mereka dapat mengembangkan dan memelihara rasa kepemilikan dan rasa tanggung jawab terhadap risiko serta tindakan penanganan risiko. Proses identifikasi risiko biasanya akan dapat mengarahkan kita kepada proses analisis kualitatitf risiko. Jika proses ini dipandu oleh manejer yang berpengalaman, proses ini juga secara langsung akan membantu kita dalam melakukan proses analisis kuantitatif risiko. Selama melakukan proses identifikasi risiko kita juga bisa sekaligus menentukan tindakan penanganan dan sebaiknya dicatat untuk selanjutnya dianalisis dan diimplementasikan pada proses perencanaan tindakan penanganan risiko. Gambar 2.7 di bawah ini menunjukkan proses identifikasi risiko mencakup masukan, alat dan teknik serta hasil dari proses identifikasi risiko.

Gambar 2.7 Proses identifikasi risiko (Sumber: Project Management Institute, 2004, hal.246) 21 22

Roger W Stewart dan Joyce Fortune, Op.Cit, p.279. Project Management Institute, Op.Cit., p. 246. Universitas Indonesia


38

Dalam tahap ini terdapat lima masukan yang bisa digunakan untuk mengidentifikasi risiko yang mungkin terjadi yaitu faktor lingkungan perusahaan, proses organisasi, ruang lingkip proyek, perencanaan manajemen risiko, dan perencanaan manajemen proyek. Masukan ini kemudian akan diolah dengan menggunakan alat dan teknik sebagai berikut: 1. Peninjauan dokumen Peninjauan yang terstruktur dapat dilakukan terhadap dokumen proyek mencakup perencanaan, asumsi, arsip proyek yang berlalu, dan informasi lain. Kualitas dari perencanaan serta konsistensi antara rencana dengan kebutuhan dan asumsi proyek dapat menjadi indikator risiko dalam proyek. 2. Teknik pengumpulan informasi Ada beberapa contoh teknik pengumpulan informasi yang dapat digunakan dalam identifikasi risiko antara lain : a. Brainstorming Tujuan brainstorming adalah untuk memperoleh daftar risiko proyek yang luas. Tim proyek biasanya melakukan brainstorming dengan sejumlah ahli di luar tim proyek. Pengelompokan risiko seperti risk breakdown structure (RBS) dapat digunakan sebagai kerangka dasar. Risiko sebaiknya diidentifikasi dan dikelompokkan berdasarkan jenis risiko dan didefinisikan dengan jelas. b. Delphi technique Delphi Technique adalah sebuah teknik untuk mencapai kesepakatan ahli. Para ahli risiko proyek sebaiknya dilibatkan dalam teknik ini. Fasilitator menggunakan kuisioner untuk mengumpulkan ide mengenai kepentingan risiko proyek. Tanggapan dirangkum dan disebarkan kembali kepada ahli untuk dikomentari dan memperoleh kesepakatan. Delphi Technique dapat membantu mengurangi bias dalam data serta menjaga supaya pihak yang tidak ahli tidak terlibat dalam proses penentuan hasil. c. Wawancara Wawancara dengan pihak tim proyek yang berpengalaman, stakeholder, dan para ahli dapat mengidentifikasi risiko. Wawancara merupakan salah satu sumber utama pengumpulan data identifikasi risiko. d. Identifikasi penyebab risiko



39

Identifikasi penyebab risiko merupakan penyelidikan ke dalam penyebab utama

dari

risiko

proyek

dengan

mempertajam

definisi

risiko

dan

mengelompokkan risiko berdasarkan penyebab. Tindakan penanganan risiko yang efektif dapat dikembangkan jika penyebab utama dari risiko diketahui. e. Analisis SWOT Dalam teknik ini dilakukan analisis proyek dari setiap perspektif SWOT mencakup kekuatan, kelemahan, kesempatan serta ancaman untuk meningkatkan cakupan pertimbangan risiko. 3. Analisis checklist Checklist identifikasi risiko dapat dikembangkan dengan menggunakan data historis dan pengalaman tahun lalu yang dapat diakumulasikan dari beberapa proyek yang sama sebelumnya serta berdasarkan beberapa sumber informasi lainnya. Tingkatan terendah dari RBS juga dapat digunakan sebagai checklist risiko. Checklist sebaiknya ditinjau ulang sampai penutupan proyek dan dilakukan perbaikan agar dapat digunakan pada proyek yang akan datang. 4. Analisis asumsi Setiap proyek disusun dan dikembangkan berdasarkan seperangkat hipotesis, skenario dan asumsi. Analisis asumsi merupakan alat yang dapat digunakan untuk mengecek validitas dari asumsi yang akan diaplikasikan terhadap proyek. Analisis asumsi dapat mengidentifikasi risiko ketidakurasian, ketidakkonsistensian atau ketidaklengkapan asumsi proyek. 5. Teknik diagram Teknik diagram risiko dapat dilakukan dengan menggunakan : a. Diagram sebab-akibat Diagram ini juga dikenal dengan diagram fishbone atau diagram Ishikawa yang dapat digunakan untuk mengidentifikasi penyebab risiko. b. Peta aliran proses Peta ini menunjukkan bagaiman setiap elemen dalam system berhubungan dan mekanisme sebab-akibat. c. Diagram keterkaitan Diagram ini merepresentasikan keterkaitan penyebab serta hubungan antara variabel dengan hasil. Di samping beberapa teknik di atas, kita juga dapat



40

melakukan identifikasi risiko berdasarkan jadwal, proses, work breakdown structure (WBS), succes-thwarting atau prompt list23. Hasil yang diperoleh dari proses identifikasi risiko ini dirangkum dalam sebuah dokumen khusus yang disebut dengan daftar risiko yang menjadi bagian dari perencanaan manajemen proyek. Dalam daftar risiko terdapat beberapa informasi penting seperti daftar item risiko yang teridentifikasi, daftar tindakan penanganan yang mungkin dilakukan, sumber risiko serta pengelompokan risiko yang telah diperbaharui.

2.5.2.3 Analisis Kualitatif Risiko Masalah yang sering muncul dalam proses manajemen risiko adalah bagaimana menentukan tingkat kepentingan dari sumber risiko yang berbeda sehingga dapat membantu kita dalam melakukan manajemen risiko dan menjamin penggunaan biaya yang efektif. Pendekatan umum untuk menilai probabilitas dan dampak risiko adalah mengidentifikasi sumber dari risiko yang akan mendapat perhatian yang lebih24. Analisis kualitatif risiko mencakup metode penentuan prioritas risiko yang teridentifikasi untuk diambil tindakan selanjutnya seperti analisis kuantitatif risiko atau perencanaan tindakan penanganan risiko25. Organisasi dapat meningkatkan efektivitas performa proyek dengan memfokuskan pada risiko dengan prioritas yang tinggi. Analisis kualitatif risiko menilai prioritas risiko yang teridentifikasi dengan menggunakan probabilitas terjadinya dan dihubungkan dengan dampakny terhadap tujuan proyek jika risiko terjadi, demikian juga dengan faktor lain seperti kerangka waktu dan toleransi risiko bedasarkan kendala biaya, jadwal, ruang lingkup dan kualitas.

23

Guy M Merrit dan Preston G Smith, “Techniques for Managing Project Risk”,

John Wiley & Son Inc, 2004, p.206. 24

S C Ward, “Assesing and Managing Important Risks” in International Journal of Project Management, vol.17, no.6, Elsevier Science Ltd, Great Britain, 1999, p.331. 25 Project Management institute., Op.Cit., p.249. Universitas Indonesia


41

Definisi dari tingkat probabilitas dan dampak risiko serta wawancara dengan ahli dapat membantu dalam memperbaiki bias yang sering muncul dalam data yang digunakan dalam proses. Evaluasi ketersediaan informasi pada risiko proyek juga dapat membantu dalam memahami penilaian kepentingan risiko terhadap proyek. Analisis kualitatif risiko sebaiknya ditinjau ulang selama daur hidup proyek untuk menyesuaikan perubahan risiko proyek yang terjadi saat ini. Analisis kualitatif risiko membutuhkan hasil yang diperoleh dari proses perencanaan manajemen risiko dan prose identifikasi risiko sebelumnya sedangkan hasil dari proses snalisis kualitatif risiko ini selanjutnya akan menuntun kita untuk melakukan analisis kuantitatif risiko atau langsung ke dalam perencanaan tindakan penanganan risiko. Gambar 2.8 di bawah ini memberikan gambaran umum dalam proses analisis kualitatif risiko.

Gambar 2.8 Proses analisis kualitatif risiko (Sumber: Project Management Institute, 2004, hal.250) Dalam melakukan analisis kualitatif risiko ada beberapa alat dan teknik yang dapat dilakukan antara lain : 1. Penilaian probabilitas dan dampak risiko Penilaian probabilitas risiko menentukan kemungkinan terjadinya setiap risiko secara spesifik. Penilaian dampak risiko menentukan potensi dampak risiko terhadap tujuan proyek seperti waktu, biaya, ruang lingkup atau kualitas mencakup dampak negatif dan positif dari setiap risiko. Risiko dapat dinilai melalui wawancara dengan pihak tertentu yang memiliki pengetahuan dan keahlian dalam manajemen risiko seperti anggota tim, atau pihak luar tim yang mempunyai pengetahuan. Penilaian ahli juga dibutuhkan karena mungkin terdapat beberapa informasi mengenai risiko dari arsip organisasi pada proyek



42

sebelumnya. Manajer proyek sering menungganakan matriks probabilitas dan dampak risiko dengan memberikan nilai pada setiap probabilitas dan dampak risiko. Setiap manajer proyek dapat merancang sebuah nilai yang berbeda dari nilai yang biasa digunakan dalam manajemen risiko proyek apabila nilai tersebut lebih cocok dengan proyek yang dilaksanakan26. Sistem penilaian seperti ini menggambarkan adanya range atau jarak dari nilai probabilitas dan dampak sesuai dengan kategorinya. Karena penilaian ini berdasarkan penilaian yang bersifat subjektif, maka sebaiknya pihak yang berhak menilai risiko adalah pihak yang mempunyai pengetahuan pengalaman dengan risiko yang teridentifikasi sebelumnya27. Penilaian hanya akan valid untuk waktu tertentu dan ditentukan dengan menggunakan kombinasi perkalian nilai probabilitas dan dampak. Tabel 2.1 di bawah ini menunjukkan skala penilaian probabiltas risiko yang dapat digunakan dalam penilaian risiko. Tabel 2.1 Skala Penilaian Probabiltas Risiko

Sumber : Patterson Fiona D dan Neailey, 2002, hal.369 Tingkat probabilitas dari setiap risiko dan dampaknya terhadap tujuan proyek dievaluasi selama wawancara dan rapat. Probabilitas dan dampak risiko dinilai berdasarkan definisi yang dijelaskan dalam perencanaan manajemen risiko pada tahap sebelumnya. Terkadang risiko dengan nilai atau tingkat probablitas dan dampak yang rendah tidak akan dinilai, tetapi akan dimasukkan ke dalam daftar risiko yang diawasi pada tahap selanjutnya. Tabel 2.2 di bawah ini adalah

26 27

Office of Project Management Process Improvement, Op.Cot., p.23. Fiona D Patterson dan Neailey, “A Risk Register Database System to Aid the

Management of Project Risk” in International Journal of Project Management, vol.20, Elsevier Science Ltd, Great Britain, 2002, p.369.



43

contoh skala penilaian dampak risiko yang biasa digunakan dalam manajemen proyek risiko.

Tabel 2.2 Skala Penilaian Dampak Risiko

Sumber : Office of Project Management Process Improvement, , 2003, hal.23 2. Matriks probabilitas dan dampak Risiko dapat diprioritaskan untuk selanjutnya digunakan dalam analisis kuantitatif atau pengambilan tindakan berdasarkan tingkat risiko. Nilai risiko ditentukan berdasarkan penilaian terhadap probabilitas dan dampak risiko. Evaluasi kepentingan setiap risiko menjadi acuan dalam menentukan prioritas perhatian risiko dengan menggunakan matriks probabilitas dan dampak risiko.



44

Pendekatan yang paling sering digunakan untuk menilai risiko adalah dengan menggunakan matriks probabilitas-dampak28. Matriks ini secara spesifik akan mengkombinasikan probabilitas dan dampak yang akan menentukan apakah suatu risiko tergolong dalam prioritas rendah, sedang atau tinggi. Organisasi dapat mendeskripsikan istilah atau nilai numerik yang dapat digunakan dalam menentukan tigkat prioritas risiko.Organisasi harus menentukan kombinasi probabilitas dan dampak yang menghasilkan klasifikasi risiko. Aturan mengenai penentuan tingkat risiko sebaiknya ditentukan oleh organisasi secara spesifik dalam tahap perencanaan manajemen risiko sesuai dengan kemauan organisasi dengan tetap memperhatikan proses organisasi. Gambar 2.9 di bawah ini merupakan salah satu contoh matriks probabilitas dan dampak risiko yang dapat digunakan dalam manajemen risiko proyek. Daerah berwarna hijau merepresentasikan risiko dengan tingkat risiko rendah, warna kuning merepresentasikan risiko dengan tingkat risiko sedang dan warna merah merepresentasikan risiko dengan tingkat risiko tinggi.

Gambar 2.9 Matriks probabilitas dan dampak risiko (Sumber: Office of Project Management Process Improvement, 2003, hal.24) 3. Penilaian kualitas data risiko

28

28 S C Ward, Op.Cit., p.332.



45

Untuk memperoleh hasil yang baik maka dalam analisis kualitatif risiko dibutuhkan data yang akurat dan tidak bias. Analisis mengenai kualitas data risiko merupakan teknik mengevaluasi tingkat kelayakan data yang digunakan dalam manajemen risiko. Proses ini meliputi pengujian tingkat akurasi, kualitas dan integritas data risiko. Untuk memperoleh data yang akurat dan berkualitas biasanya membutuhkan waktu dan sumber daya yang lebih. 4. Pengelompokan risiko Risiko proyek dapat dikategorikan berdasarkan sumber risiko dengan mengunakan RBS, aktivitas proyek yang dipengaruhi dengan menggunakan WBS, atau kategori lain. Pengelompokan risiko berdasarkan penyebab dapat menuntun kita untuk memperoleh tindakan penanganan yang efektif. 5. Penilaian prioritas risiko Beberapa risiko ada yang membutuhkan tindakan penanganan dalam waktu yang singkat sehingga risiko seperti ini juga dapat diprioritaskan untuk ditangani. Indikator prioritas dapat mencakup waktu untuk mempengaruhi tindakan penanganan, gejala, sinyal peringatan dan tingkat risiko. Melalui proses analisis kualitatif risiko ini akan diperoleh beberapa hasil yang dapat digunakan sebagai masukan pada proses selanjutnya dalam manajemen risiko proyek antara lain: 1. Daftar prioritas risiko proyek Matriks probabilitas dan dampak dapat digunakan untuk mengelompokkan risiko berdasarkan tingkat kepentingan dampak. Daftar prioritas risiko ini kemudian akan digunakan oleh manejer proyek untuk memfokuskan perhatian pada item risiko yang mempunyai dampak yang signifikan terhadap proyek. Deskripsi mengenai dasar penilaian probabilitas dan dampak risiko sebaiknya dilibatkan dalam penilaian risiko karena sangat penting bagi proyek. 2. Kategori kelompok risiko Kategori risiko dapat menggambarkan penyebab umum risiko atau bagain proyek yang membutuhkan perhatian tersendiri, dengan mengetahui konsentrasi risiko maka kita dapat meningkatkan efektivitas tindakan penanganan risiko. 3. Daftar tindakan penanganan untuk jangka waktu yang singkat



46

Pada saat melakukan identifikasi risiko, kita mungkin akan menemukan risiko yang membutuhkan penanganan darurat. Risiko yang membutuhkan penanganan darurat atau dapat ditangani dalam waktu yang dekat perlu dimasukkan ke dalam kelompok yang berbeda. 4. Daftar risiko yang membutuhkan analisis dan tindakan penanganan tambahan Beberapa risiko membutuhkan analisis tambahan yang mencakup analisis kuantitatif dan tindakan penanganan. Risiko-risiko ini dimasukkan ke dalam daftar risiko yang membutuhkan analisis dan tindakan penanganan tambahan. 5. Daftar risiko dengan prioritas rendah yang diawasi Sebagian risiko mempunyai tingkat probabilitas dan dampak yang rendah sehingga hanya mendapat prioritas penanganan yang rendah dan biasanya risiko seperti ini tidak dinilai. Risiko dengan tingkat kepentingan yang tidak dinilai ini kemudian akan dapat dimasukkan ke dalam daftar risiko yang diawasi. 6. Kecenderungan hasil analisis kualitatif risiko Karena analisis kualitatif dilakukan secara berulang-ulang selama siklus daur hidup proyek, maka kecenderungan (trend) dari sebagian risiko mungkin akan terlihat sehingga kita dapat membuat tindakan penanganan atau analisis lebih lanjut mengenai kepentingan risiko. 2.5.2.4 Analisis Kuantitatif Risiko Analisis kuantitatif risiko dapat dilakukan pada risiko yang telah diprioritaskan melalui proses analisis kualitatif risiko karena berpotensi mempengaruhi pencapain tujuan proyek. Proses analisis kuantitatif risiko menganalisis pengaruh dari risiko dan memberikan nilai numerik terhadap risiko tersebut29. Proses ini juga merepresentasikan pendekatan kuantitatif untuk pengambilan keputusan dalam ketidakpastian. Proses ini menggunakan teknik seperti simulasi monte carlo dan analisis pohon keputusan untuk : 1. Menghitung hasil yang mungkin untuk proyek serta probabilitasnya 2. Menilai probabilitas pencapaian tujuan proyek secara spesifik

29

Project Management Institute,. Op.Cit., p. 254.



47

3. Mengidentifikasi risiko yang membutuhkan perhatian khusus melalui perhitungan kontribusi (pengaruh) terhadap risiko proyek secara keseluruhan 4. Mengidentifikasi biaya, jadwal, dan target ruang lingkup proyek yang realitis dan dapat diterima 5. Menentukan keputusan manajemen proyek yang paling tepat ketika kondisi atau hasil tidak pasti. Analisis kuantitatif risiko secara umum merupakan lanjutan dari proses analisis kualitatif risiko walaupun beberapa manejer risiko yang berpengalaman langsung melakukannya setelah proses identifikasi risiko. Dalam beberapa kasus analisis kuantitatif risiko tidak dibutuhkan untuk menentukan tindakanpenanganan yang efektif. Ketersediaan dana dan waktu dan kebutuhan terhadap pernyataan kualitatif dan kuantitatif risiko dan dampaknya akan menentukan metode mana yang akan digunakan pada proyek. Analisis kuantitatif risiko sebaiknya diulang setelah perencanaan tindakan penanganan dan pengawasan dan pengontrolan risiko untuk menentukan apakah risiko proyek secara umum telah berhasil dikurangi. Beberapa kecenderungan dapat mengindikasikan kebutuhan terhadap tindakan manajemen yang digunakan sebagai masukan dalam perencanaan tindakan penanganan. Gambar 2.10 di bawah ini menunjukkan proses analisis kuantitatif risiko yang meliputi masukan, alat dan teknik serta hasil.

Gambar 2.10 Proses analisis kuantitatif risiko (Sumber: Project Management Institute, 2004, hal.254) Dalam proses analisis kuantitatif risiko terdapat beberapa alat dan teknik yang dapat digunakan antara lain : 1. Teknik pengumpulan data dan representasi



48

a. Wawancara Teknik wawancara digunakan untuk menghitung probabilitas dan dampak dari risiko terhadap tujuan proyek. Informasi yang dibutuhkan tergantung pada jenis distribusi probabilitas yang akan digunakan. Sebagai contoh, informasi akan dikelompokkan menjadi sekanario optimis (rendah), pesimis (tinggi) dan sangat mungkin terhadap beberapa distribusi yang digunakan secara umum serta rata-rata dan standar deviasi untuk yang lain. Tabel 2.3 di bawah ini merupakan contoh tiga estimasi biaya dalam suatu proyek. Keakuratan dan kebenaran dalam membuat jarak risiko merupakan bagian yang penting dari sebuah wawancara risiko karena hal ini dapat menentukan tingkat kebenaran dan keyakinan analisis. Tabel 2.3 Estimasi Biaya Proyek yang Dikumpulkan Selama Wawancara

Sumber: Project Management Institute, 2004, hal.256 b. Distribusi probabiltas Distribusi probabilitas yang berkelanjutan merepresentasikan nilai ketidakpastian, seperti durasi dari penjadawalan aktivitas dan biaya dari komponen proyek. Distribusi diskrit dapat digunakan untuk merepresentasikan kejadian ketidakpastian seperti hasil dari pengujian atau kemungkinan skenario dalam pohon keputusan. Distribusi asimetris menggambarkan bahwa kondisi data sesuai dengan data yang dikembangkan selama analisis manajemen risiko. Distribusi uniform dapat digunakan jika tidak ada nilai yang mempunyai kemungkinan yang lebih besar dibandingkan nilai yang lain yang berada pada batasan rendah dan tinggi30. Gambar 2.11 di bawah ini menunjukkan contoh distribusi berkelanjutan.

30

Ibid., p.256.



49

Gambar 2.11 Distribusi beta dan distribusi tringular (Sumber: Project Management Institute, 2004, hal.256) c. Penilaian oleh ahli Beberapa ahli dari dalam maupun dari luar anggota tim proyek dari organisasi seperti ahli keteknikan atau statistik dapat melakukan pengujian validasi data. 2. Analisis kuantitatif dan teknik pemodelan Ada beberapa teknik yang biasa dipakai dalam melakukan analisis kuantitatif risiko seperti : a. Analisis sensitivitas Analisis sensitivitas mambantu dalam menentukan risiko mana yang mempunyai dampak yang paling mempengaruhi proyek. Analisis ini dapat diperluas untuk melihat apakah ketidakpastian dari setiap elemen proyek mempengaruhi tujuan yang diuji ketika semua elemen ketidakpastian yang lain terjadi pada nilai dasarnya. Salah satu ciri khas dari analisis sensivitas adalah diagram tornado yang dapat digunakan untuk membandingkan kepentingan dari setiap variabel yang mempunyai tingkat ketidakpastian yang tinggi terhadap variabel lain yang lebih stabil31. b. Analisis expected monetary value (EMV)

31

Ibid., p.257.



50

Analisis EMV merupakan konsep statistik yang menghitung ratarata dari hasil jika melibatkan skenario yang mungkin dan tidak mungkin terjadi. Nilai EMV dari kesempatan akan dinyatakan dalam nilai positif sedangkan risiko dalam nilai negative. EMV dihitung dengan mengalikan nilai dari setiap hasil yang mungkin dengan probabilitas terjadinya lalu dijumlahkan. Bentuk umum dari analisis ini adalah analisis pohon keputusan. Pemodelan dan simulasi direkomendasikan untuk digunakan dalam analisis biaya dan jadwal risiko karena pemodelan dan simulasi lebih powerful dibandingkan analisis EMV. c. Analisis pohon keputusan Analisis pohon keputusan biasanya menggunakan sebuah diagram pohon keputusan yang mendeskripsikan sebuah kondisi di luar pertimbangan dan implikasi dari setiap pilihan yang tersedia dan scenario yang mungkin terjadi32. Penyelesaian dengan pohon keputusan memberikan nilai EMV dari setiap alternatif. Gambar 2.12 di bawah ini adalah contoh diagram pohon keputusan.

Gambar 2.12 Diagram pohon keputusan (Sumber: Project Management Institute,2004, hal.258) d. Pemodelan dan simulasi Simulasi proyek menggunakan sebuah model yang menerjemahkan risiko untuk menentukan dampak dari risiko terhadap tujuan proyek pada tingkat 32

Ibid., p.257. Universitas Indonesia


51

kedetailan tertentu33. Simulasi khususnya dilakukan dengan menggunakan teknik Monte Carlo. Dalam simulasi ini model proyek akan dihitung secara berulangulang dengan iterasi dimana nilai masukan diacak secara random dengan menggunakan sebuah fungsi distribusi probabilitas yang dipilih untuk setiap iterasi distribusi probabilitas setiap variabel. Gambar 2.13 di bawah ini menunjukkan hasil dari simulasi biaya risiko dari suatu proyek.

Gambar 2.13 Contoh hasil simulasi biaya risiko (Sumber: Project Management Institute, 2004, hal.259) Hasil dari analisis kuantitatif risiko ini adalah berupa daftar risiko yang telah diperbaharui yang mencakup beberapa komponen yaitu : 1. Analisis probabilistik proyek Estimasi dibuat berdasarkan hasil jadwal dan biaya proyek yang berpotensi, lalu mencatat kemungkinan jadwal dan biaya penyelesaian pada tingkat keyakinan tertentu. Hasil ini dinyatakan dalam distribusi kumulatif yang digunakan sebagai toleransi risiko stakeholder untuk perhitungan biaya dan waktu cadangan yang mungkin dan diizinkan. Hal ini dibutuhkan untuk menurunkan risiko sampai pada level yang dapat diterima perusahaan. Sebagai contoh, pada gambar 2.11 di atas biaya kemungkinan untuk persentil 75% adalah $9 atau sekitar 22% dari total estimasi most likely. 33

Ibid., p.258. Universitas Indonesia


52

2. Probabilitas kesuksesan biaya dan target waktu Walaupun proyek dihadapkan dengan risiko, probabilitas kesuksesan tujuan proyek dengan rencana awal dapat diestimasi dengan menggunakan hasil analisis kuantitatif risiko. Sebagai contoh, pada gambar 2.11 di atas probabilitas dari kesuksesan estimasi biaya $41 adalah sekitar 12%. 3. Daftar prioritas risiko yang dihitung Risiko yang dilibatkan ke dalam daftar ini adalah risiko yang mempunyai ancaman terbesar atau kesempatan terbesar saat ini terhadap proyek. Daftar ini mencakup risiko yang membutuhkan biaya kemungkinan yang terbesar dan risiko yang paling mempengaruhi jalur kritis proyek. 4. Kecenderungan hasil analisis kuantitatif risiko Karena analisis dilakukan secara berulang selama siklus daur hidup proyek maka kecenderungan (trend) mungkin akan dapat terlihat yang mempermudah kita dalam melakukan tindakana penanganan yang efektif. 2.5.2.5 Perencanaan Tindakan Penanganan Risiko Tahap pengembangan tindakan penanganan risiko merupakan salah satu tahap yang utama dalam proses manajemen risiko34. Kita dapat merepresentasikan sebuah model yang mengintegrasikan kegiatan, kejadian risiko, tindakan pengurangan risiko dan pengaruh risiko terhadap tujuan proyek. Melalui model tersebut akan terlihat pengaruh tindakan pengurangan beberapa risiko dan dampak lain kejadian risiko serta dapat mendukung evaluasi total frekuensi tindakan penanganan risiko terhadap proyek dalam beberapa kondisi yang berbeda-beda. Kita juga dapat membuat model yang dinyatakan dengan teknik optimasi untuk memperoleh kombinasi tindakan penanganan risiko yang efektif. Untuk mewujudkan tercapainya suatu manajemen biaya yang efektif dalam manajemen risiko maka dalam manajemen risiko bukan hanya besarnya dampak dan probabilitas dari dampak yang terjadi yang perlu diperhatikan melainkan juga

34

Ben David dan T Raz, “An Integrated for Risk Response Development in

Project Planning”, Vol.52, No.1, Operational Research Society Ltd, 2001, p.14



53

faktor lain seperti tindakan penanganan yang layak serta waktu pelaksanaan penanganan yang tersedia35. Perencanaan

tindakan

penanganan

risiko

merupakan

proses

pengembangan pilihan dan penentuan tindakan untuk meningkatkan kesempatan dan mengurangi ancaman terhadap tujuan proyek36. Dalam perencanaan tindakan penanganan risiko setiap risiko akan dibahas berdasarkan prioritasnya, diikuti dengan memasukkan sumber daya dan aktivitas ke dalam anggaran, jadwal dan rencana manajemen proyek sesuai dengan kebutuhan. Perencanaan tindakan penanganan harus disesuaikan dengan tingkat kepentingan risiko, efektivitas biaya harus dibuat secara realistis dengan konteks proyek dan disetujui oleh semua pihak yang terlibat serta mempunyai penanggung jawab. Pemilihan tindakan penanganan yang tepat dari beberapa pilihan sangat dibutuhkan. Gambar 2.14 di bawah ini menjelaskan proses dalam perencanaan tindakan penanganan risiko.

Gambar 2.14 Proses perencanaan tindakan penanganan risiko (Sumber: Project Management Institute, 2004, hal.260) Ada beberapa strategi penanganan risiko yang dapat dipilih untuk diimplementasikan terhadap risiko. Alat analisis risiko seperti analisis pohon keputusan dapat digunakan untuk memilih tindakan penanganan yang paling sesuai

untuk

selanjutnya

dikembangkan

tindakan

yang

spesifik

untuk

mengimplementasikan strategi tersebut. Strategi utama dan strategi cadangan perlu dibuat. Terdapat beberapa strategi penanganan risiko antara lain: 1. Strategi untuk risiko negatif atau ancaman

35 36

S C Ward, Op.Cit., hal.331. 36 Project Management Institute,. Op.Cit., p.260.



54

Ada tiga strategi khusus yang yang berhubungan dengan ancaman atau risiko yang mempunyai dampak negatif pada tujuan proyek jika terjadi. Strategi tersebut adalah menghindari, memindahkan atau mengurangi risiko. a. Menghindari Strategi menghindari risiko melibatkan perubahan dalam manajemen proyek untuk menghilangkan ancaman untuk melindungi tujuan proyek dari dampak risiko atau mengurangi tujuan dari risiko seperti dengan memperpanjang jadwal atau mengurangi ruang lingkup proyek. Beberapa risiko yang muncul pada awal proyek dapat dihindari dengan mengklarifikasi kebutuhan, memperoleh informasi, meningkatkan komunikasi atau melatih keahlian37. Melalui strategi ini, tim proyek mengubah rencana proyek untuk mengurangi risiko atau untuk melindungi tujuan proyek dari dampak negatif risiko. Perubahan ruang lingkup, penambahan durasi penyelesaian atau penambahan sumber daya merupakan cara menghindari terjadinya suatu risiko38. b. Memindahkan Pemindahan risiko berarti memindahkan dampak negatif risiko ke perusahaan pemasok yang lain (third party). Pemindahan risiko hanya memberikan (memindahkan) tanggung jawab kepada manajemen perusahaan lain dengan tanpa mengurangi risiko tersebut. Pemindahan risiko lebih efektif digunakan untuk menangani risiko yang berdampak besar terhadap keuangan. Pemindahan risiko hampir selalu melibatkan pembayaran kepada perusahaan yang ditugaskan mengambil risiko. Kontrak merupakan salah satu cara yang dapat digunakan untuk memindahkan tanggung jawab terhadap berbagai risiko yang spesifik kepada perusahaan lain c. Mengurangi Pengurangan risiko merupakan pengurangan probabilitas dan/atau dampak dari risiko untuk mencapai kesuksesan. Pengambilan tindakan lebih awal untuk mengurangi probabilitas dan/atau dampak risiko pada proyek sering menjadi lebih efektif dibandingkan mencoba atau mperbaiki dampak dari risiko setelah risiko itu 37 38

Ibid., p.261. Office of Project Management Process Improvement,. Op.Cit., p.12



55

terjadi. Menggunakan edikit proses yang kompleks, melakukan lebih banyak ercobaan/pengujian (test), atau memilih supplier yang mempunyai performa yang lebih stabil merupakan beberapa contoh tindakan engurangan risiko. 2. Strategi untuk risiko positif atau kesempatan Ada tiga tindakan penanganan yang disarankan berhubungan dengan isiko yang mempunyai dampak positif terhadap tujuan proyek. Strategi tersebut adalah memanfaatkan, membagi, dan meningkatkan39. a. Memanfaatkan Strategi ini mungkin dipilih untuk risiko dengan dampak positif dimana organisasi ingin memastikan bahwa kesempatan tersebut realistis. Strategi ini dilakukan untuk mengurangi ketidakpastian yang menjadi bagian dari lain dari risiko dengan mewujudkan kesempatan terjadi. Penanganan dengan memanfaatkan secara langsung meliputi penugasan sumber daya dengan bakat dan keahlian yang lebih ke dalam proyek untuk mengurangi waktu penyelesaian, atau memperoleh kualitas yang lebih baik dari rencana awal. b. Membagi Membagi risiko positif melibatkan pengalokasian kepemilikan kepada pihak ketiga yang lebih baik dalam memanfaatkan kesempatan menjadi keuntungan terhadap proyek. Tindakan strategi membagi risiko meliputi pembentukan hubungan pembagian risiko, tim, perusahaan khusus, joint venture yang dapat dibangun dengan menyatakan tujuan dari pengelolaan kesempatan. c. Meningkatkan Strategi ini memodifikasi ukuran dari kesempatan dengan meningkatkan probabilitas dan/atau dampak positif serta dengan mengidentifikasi dan memaksimalkan pemacu risiko yang berdampak positif. Memudahkan atau memperkuat penyebab kesempatan dan menargetkan secara proaktif dan memperkuat pemacu kondisi tersebut dapat meningkatkan probabilitas. Pemacu dampak juga dapat ditargetkan untuk meningkatkan kerentanan proyek terhadap kesempatan. 39

Project Management Institute,. Op.Cit., p.262. Universitas Indonesia


56

3. Strategi untuk ancaman dan kesempatan Strategi untuk ancaman dan kesempatan dilakukan dengan menerima risiko. Strategi menerima risiko diadopsi karena sangat kecil kemungkinan bahwa kita dapat mengurangi semua risiko yang terdapat pada sebuah proyek. Strategi ini menunjukkan bahwa tim proyek telah memutuskan untuk tidak mengubah rencana manajemen proyek yang berhubungan dengan risiko atau tim proyek tidak dapat mengidentifikasi strategi lain yang lebih tepat untuk menangani risiko tersebut. Strategi ini dapat bersifat pasif maupun aktif. Strategi penerimaan pasif menunjukkan bahwa tim proyek tidak melakukan tindakan penanganan, membiarkan tim proyek menghadapi risiko dan dampaknya jika risiko tersebut terjadi. Strategi yang paling umum adalah strategi penerimaan yaitu dengan membuat cadangan kemungkinan meliputi sejumlah waktu, uang atau sumber daya untuk menangani beberapa kesempatan atau ancaman. 4. Strategi penanganan khusus Beberapa strategi penanganan didesain untuk digunakan hanya jika kejadian tertentu terjadi. Bagi beberapa risiko seperti ini tim proyek disarankan untuk menggunakan strategi penanganan ini dengan membuat rencana penanganan yang hanya akan dilakukan pada kondisi tertentu. Jika hal ini dilakukan maka perlu ada peringatan untuk mengimplementasikan rencana tersebut. Kejadian yang dapat memacu penanganan cadangan seperti kehilangan kelanjutan suatu bagian yang penting atau meningkatkan prioritas dengan pemasok harus didefinisikan dan dicatat. 2.5.2.6 Pengawasan dan Pengontrolan Risiko Perencanaan tindakan penanganan

risiko

yang

dilibatkan

dalam

perencanaan manajemen proyek dilakukan selama daur hidup proyek, namun proyek juga harus tetap dikontrol dan diawasi secara berkelanjutan terhadap risiko yang baru dan perubahan risiko. Pengawasan dan pengontrolan risiko merupakan proses pengidentifikasian dan perencaan risiko yang meningkat, mengawasi risiko yang teridentifikasi, menganalisis ulang risiko yang ada, mengontrol pemacu kondisi untuk rencana cadangan, mengawasi sisa risiko dan meninjau ulang



57

pelaksanaan penanganan risiko untuk mengevaluasi efektivitasnya40. Gambar 2.15 di bawah ini menunjukkan proses pengawasan dan pengontrolan risiko.

Gambar 2.15 Proses pengawasan dan pengontrolan risiko (Sumber: Project Management Institute, 2004, hal.265) Proses pengawasan dan pengontrolan risiko membutuhkan beberapa teknik seperti analisis trend dan varian yang membutuhkan kegunaan performa data yang dihasilkan selama pelaksanaan proyek. Pengawasan dan pengontrolan risiko serta proses manajemen risiko lainnya merupakan proses yang terusmenerus selama daur hidup proyek. Tujuan lain dari proses pengawasan dan pengontrolan risiko adalah untuk menentukan apakah: a. Asumsi proyek masih valid b. Risiko yang dinilai telah berubah dari prioritas sebelumnya dengan analisis trend c. Kebijakan dan prosedur manajemen risiko yang dilakukan sudah tepat d. Cadangan kemungkinan untuk biaya dan waktu harus dimodifikasi Proses pengawasan dan pengontrolan risiko dapat melibatkan pemilihan strategi alternatif, pelaksanaan rencana cadangan, pengambilan tindakan perbaikan dan modifikasi rencana manajemen proyek. Laporan tindakan penanganan secara periodik harus dilaporkan kepada manejer proyek mengenai efektivitas perencanaan, beberapa pengaruh yang tidak diantisipasi dan beberapa perbaikan yang diperlukan untuk menangani risiko. Proses pengawasan dan pengontrolan risiko juga mencakup perbaikan proses asset organisasi meliputi 40

Ibid., p.260.



58

dokumentasi arsip proyek dan templet manajemen risiko yang dapat digunakan untuk proyek yang akan datang. Jika risiko yang tidak diantisipasi terjadi atau dampak risiko lebih besar dari yang diinginkan maka tindakan penanganan sebelumnya mungkin tidak akan sesuai lagi. Oleh karena itu, manejer proyek perlu melakukan perencanaan tambahan untuk mengontrol resiko seperti ini41. Ada beberapa masukan yang dapat digunakan untuk melakukan proses pengawasan dan pengontrolan risiko antara lain : 1. Rencana manajemen risiko Rencana ini menjadi masukan kunci yang mencakup penugasan anggota tim proyek termasuk pemilik, waktu dan sumber lain ke dalam manajemen risiko proyek. 2. Daftar risiko Daftar risiko merupakan masukan yang melibatkan risiko yang teridentifikasi dan pemilik risiko, tindakan penanganan yang disetujui, tindakan implementasi yang spesifik, gejala dan sinyal peringatan risiko, sisa risiko, daftar risiko dengan prioritas rendah dan waktu dan biaya cadangan kemungkinan. 3. Permintaan perubahan yang disetujui Permintaan perubahan yang disetujui dapat mencakup modifikasi seperti metode kerja, istilah kontrak, ruang lingkup dan jadwal. Perubahan yang disetujui dapat menghasilkan risiko atau perubahan dalam identifikasi risiko, dan perubahan lain membutuhkan analisis terhadap beberapa dampak dari risiko, rencana tindakan penanganan risiko, atau rencana manajemen risiko. Semua perubahan harus didokumentasikan secara formal. Perubahan yang didiskusikan secara

verbal

dan

tidak

didokumentasikan

tidak

perlu

diproses

dan

diimplementasikan. 4. Informasi performa kerja Informasi performa kerja yang mencakup status penyelesaian, tindakan perbaikan dan laporan performa merupakan masukan yang penting bagi pengawasan dan pengontrolan risiko. 5. Laporan kinerja 41

Office of Project Management Process Improvement,. Op.Cit., p.13.



59

Laporan kinerja memberikan informasi mengenai performa kerja proyek seperti analisis yang mungkin mempengaruhi proses-proses dalam manjemen risiko. Dalam melakukan pengawasan dan pengontrolan risiko juga dibutuhkan beberapa alat dan teknik seperti: 1. Penilaian ulang risiko Pengawasan dan pengontrolan risiko sering membutuhkan identifikasi beberapa risiko baru dan penilaian ulang risiko dengan menggunakan proses seperti yang telah dibahas di atas. Penilaian ulang harus dijadwalkan secara teratur. Manajemen risiko proyek harus menjadi sebuah item agenda dalam rapat status tim. Jumlah dan detail pengulangan yang sesuai tergantung pada bagaimana progres proyek terhadap tujuan proyek itu sendiri. Sebagai contoh, jika risiko darurat yang tidak diantisipasi dalam daftar risiko atau tidak dilibatkan dalam daftar yang diawasi atau jika dampaknya terhadap tujuan berbeda dari yang diharapakan maka tindakan penanganan yang telah direncanakan bisa menjadi tidak cocok. Oleh karena itu dibutuhkan rencana tindakan penanganan tambahan untuk mengontrol risiko. 2. Audit risiko Audit risiko berfungsi untuk menguji dan membuktikan efektivitas penanganan risiko yang berhubungan dengan risiko yang teridentifikasi dan penyebabnya serta efektivitas proses manajemen risiko. 3. Analisis trend dan varian Trend atau kecenderungan dalam pelaksanan proyek harus ditinjau ulang dengan menggunakan data hasil. Analisis nilai pendapatan dan metode lain dari varian proyek serta analisis trend juga dapat digunakan untuk mengawasi performa proyek secara keseluruhan. Hasil dari analisis ini dapat memperkirakan potensi deviasi dari target biaya dan waktu penyelesaian proyek. Deviasi dari rencana awal dapat dijadikan sebagai indikasi dampak yang berpotensi terhadap ancaman atau kesempatan. 4. Pengukuran performa teknis Pengukuran performa teknis akan membandingkan penyelesaian teknis selama pelaksanaan proyek dengan jadwal rencana manajemen proyek dari



60

pencapaian teknis. Deviasi seperti fungsionalitas yang berada di bawah dari rencana acuan dapat membantu kita dalam memperkirakan tingkat kesuksesan dalam mencapai ruang lingkup proyek. 5. Analisis cadangan Selama pelaksanaan proyek beberapa risiko mungkin terjadi dengan dampak negatif atau positif terhadap anggaran atau jadwal cadangan kemungkinan. Analisis cadangan membandingkan sejumlah cadangan kemungkinan yang masih ada akan digunakan pada sejumlah risiko yang masih tersisa pada beberapa saat dalam proyek untuk menentukan apakah cadangan yang tersisa masih sesuai. 6. Rapat status Manajemen risiko proyek dapat dijadikan sebagai item bahasan pada rapat status. Item ini mungkin memakan waktu yang lama atau singkat, tergantung pada risiko yang diidentifikasi, prioritas dan tingkat kesulitan dari tindakan penanganan. Dengan demikian manajemen risiko akan menjadi lebih mudah dari yang sering dipraktekkan dan frekuensi diskusi mengenai risiko dan dampaknya menjadi lebih mudah dan lebih akurat. Melalui proses pengawasan dan pengontrolan risiko ini kita akan memperoleh beberapa hasil yang bermanfaat bagi proses manejemn risiko selanjutnya, antara lain : 1. Daftar risiko yang telah diperbaharui Daftar risiko ini mencakup : a. Hasil penilaian ulang risiko, audit risiko, dan hasil tinjauan ulang risiko secara periodik. Hasil ini dapat berupa probabilitas, dampak, perencanaan penanganan, kepemilikan dan elemen lain dari daftar risiko yang telah diperbaharui. Hasil ini juga dapat berupa penutupan risiko yang sudah tidak dapat diaplikasikan. b. Hasil aktual risiko proyek dan penanganan risiko yang dapat membantu perencanaan risiko manejer proyek dalam organisasi yang sedang berlangsung maupun pada masa yang akan datang. Akhir dari pencatatan manajemen risiko pada proyek adalah sebuah masukan untuk proses penutupan proyek dan menjadi bagian dari dokumentasi akhir proyek. 2. Perubahan yang diinginkan



61

Implementasi rencana cadangan untuk mengubah rencana manajemen proyek dibutuhkan untuk menangani risiko. Perubahan yang diinginkan disiapkan dan dimasukkan ke dalam proses pengontrolan perubahan yang terintegrasi sebagai hasil dari proses pengawasan dan pengontrolan manajemen risiko. Perubahan yang diinginkan dan disetujui merupakan masukan dalam pengelolaan dan pengaturan pelaksanaan proyek serta proses pengawasan dan pengontrolan risiko. 3. Tindakan perbaikan yang direkomendasikan Tindakan perbaikan yang direkomendasikan mencakup rencana cadangan dan rencana perkiraan. Rencana perkiraan harus didokumentasikan dengan benar dan dimasukkan ke dalam proses pengelolaan dan pengaturan pelaksanaan proyek serta proses pengawasan dan pengontrolan pekerjaan proyek. Tindakan perbaikan yang direkomendasikan merupakan masukan untuk proses pengontrolan perubahan yang terintegrasi dalam manajemen proyek. 4. Tindakan pencegahan yang direkomendasikan Tindakan pencegahan yang direkomendasikan digunakan untuk membatu pencapaian perencanaan awal manajemen proyek. 5. Proses organisasi yang diperbaharui Keenam proses dalam manajemen risiko proyek menghasilkan informasi yang dapat digunakan untuk proyek yang akan datang dan perlu disesuaikan dengan proses asset organisasi. Templet untuk perencanaan manajemen risiko yang mencakup matriks probabilitas dampak, daftar risiko dapat diperbaharui pada akhir proyek. Data mengenai biaya dan durasi aktual aktivitas proyek dapat ditambahkan ke dalam database organisasi. Versi akhir daftar risiko dan templet perencanaan manajemen risiko, checklist dan RBS juga perlu dimasukkan ke dalam database organisasi. 6. Perencanaan manajemen proyek yang diperbaharui Jika permintaan perubahan yang disetujui mempunyai dampak terhadap proses manajemen risiko maka komponen dokumen dari rencana manajemen proyek harus diperbaiki dan diterbitkan ulang untuk menunjukkan adanya perubahan yang disetujui.



62

2.6 HOUSE OF QUALITY (HOQ) House of Quality (HOQ) merupakan matrik yang paling mendasar dari penyusunan Quality Function Deploymnet (QFD) yang bertujuan untuk menerjemahkan kebutuhan desain42. QFD merupakan sebuah metode teknis untuk mengkonversikan permintaan pelanggan ke dalam karakteristik kualitas dan untuk pengembangan perancangan produk dengan cara mengembangkan hubungan antara permintaan pelanggan dengan karakteristik produk secara sistematis43. HOQ terdiri dari 2 bagian utama, yaitu bagian horisontal yang merupakan tabel pelanggan yang berisikan informasi mengenai pelanggan serta bagian vertikal yang merupakan tabel teknis yang berisi informasi teknis sebagai respon dari keinginan pelanggan. Gambar 2.16 di bawah ini merupakan contoh HOQ.

42

M. Xie Tan dan E. Chia, “Quality Function Deployment and its Use in

Designing Information Technology Systems”, International Journal of Quality & Reliability Management, Vol. 15 No. 6, 1998, hal. 634. 43

S.F Lee dan Andrew Sai On Ko, “Building balanced scorecard with SWOT

analysis, and implementing ‘Sun Tzu’s The Art of Business Management Strategies’ on QFD methodology”, in Managerial Auditing Journal, 15/1/2, 2000, hal. 71.



63

Gambar 2.16 Struktur HOQ (Sumber : S. Bruce Han, et. al., 2001, hal.798) 2.6.1 Komponen HOQ HOQ terdiri dari enam ruang utama dimana setiap ruangnya berisi informasi mengenai produk44. Bagian-bagian tersebut antara lain: 1. Bagian kiri (Voice of customer) Bagian kiri atas dari HOQ yang berisi customer requirements. Hal ini akan dijawab dengan pertanyaan ‘Permintaan apa yang seharusnya dipuaskan, adakah beberapa keistimewaan yang pelanggan ingin dapatkan?’ 2. Bagian kanan (Competitive analysis / Penilaian Pelanggan) Degree of importance Nilai ini menunjukkan tingkat kepentingan dari customer requirements yang didapat dari hasil survey. 44

Jim Walden, “Performance Excellence: A QFD Approach”, International

Journal of Quality & Reliability Management, Vol. 20 No. 1, 2003, hal. 123.



64

Competitive evaluation Melihat bagaimana posisi tingkat kepuasan customer teerhadap produk yang dihasilkan dibandingkan dengan produk perusahaan kompetitor. Goal (Quality plan) Menunjukkan besarnya sasaran akhir posisi perusahaan yang ingin dicapai dalam rangka pemenuhan kepuasan konsumen terhadap pelayanan yang diberikan. Nilai dari sasaran ini ditentukan dengan memeprtimbangkan posisi perusahaan dibandingkan dengan perusahaan kompetitor dan kemampuan usaha perusahaan dalam usaha memenuhi kebutuhan dan keinginan konsumen. Improvement ratio (Rate of improvement) Rate of improvement merupakan nilai rasio perbandingan antara tujuan yang ingin dicapai dengan tingkat kepuasan konsumen terhadap produk / jasa perusahaan (performa perusahaan) saat ini. Sales point Sales point diberikan pada atribut yang memiliki daya jual produk yang tinggi, di mana dapat ditunjang dengan usaha promosi. Nilai sales point dibagi atas tiga kriteria pembobotan nilai sesuai dengan kemampuan atau daya jualnya, yaitu : 1 = tidak memiliki sales point 1,2 = nilai sales point medium 1,5 = nilai sales point yang tinggi Row weight Row weight merupakan besar bobot untuk tiap baris atribut konsumen yang menjadi dasar evaluasi terhadap penentuan prioritas pemenuhan kebutuhan dan keinginan konsumen. Row weight dihitung dengan rumus : RWi = IWi × SPi × IRi ..............................................(2.1) dimana : RWi = Row Weight atribut i IWi = Bobot tingkat kepentingan untuk atribut konsumen i SPi = Sales point untuk atribut konsumen i IRi = Improvement ratio atribut konsumen i Normalized row weight



65

Merupakan kontribusi dari besarnya row weight secara keseluruhan. Normalized row weight dihitung dengan rumus :

dimana : NRWi = Normalized Row Weight atribut i RWi = Row Weight atribut i ΣRW = Total Row Weight 3. Bagian atas (Voice of Organization) Technical responses (service element) Technical responses pada HOQ berbasis jasa disebut juga service element. Service element merupakan bagian dari HOQ yang mengidentifikasi karakteristik produk yang dapat diukur untuk memenuhi keinginan pelanggan. Hal ini akan dijawab dengan pertanyaan: ‘Bagaimana kebutuhan pelanggan bertemu dengan kebutuhan desain yang diperlukan?’ Direction of improvement Direction

of

improvement

digunakan

untuk

mengetahui

arah

pengembangan dari masing-masing respon teknis yang akan memberikan peningkatan

terhadap

kepuasan

pelanggan.

Terdapat

tiga

jenis

arah

pengembangan yaitu: : Konsumen menyukai bila respon teknis semakin besar : Konsumen menyukai bila respon teknis semakin kecil : Konsumen menyukai bila respon teknis pada target tertentu. 4. Bagian bawah (Design Targets / Penilaian Teknis) Perhitungan Absolute Importance dan Relative Importance Absolute dan relative importance berguna untuk membantu dalam menentukan respon teknis mana yang akan mendapatkan prioritas untuk dilaksanakan terlebih dahulu. Absolute importance adalah suatu ukuran yang menunjukkan prioritas untuk dilaksanakan dengan melihat hubungan antara technical response, customer requirements, dan tingkat kepentingan customer requirement. Absolute importance diperoleh dengan rumus : AI = Σ(normalized row weight × nilai hubungan) ....................(2.3)



66

Sedangkan relative importance adalah nilai dari absolute importance yang dinyatakan dengan persen kumulatif. Relative importance diperoleh dengan rumus :

Perhitungan Absolute Importance dan Relative Importance dilakukan setelah nilai relationship matrix ditentukan. Target Merupakan target dari karakteristik desain. Untuk HOQ bidang jasa, target dapat berupa jangka waktu terlaksananya respon teknis, anggaran pelaksanaan, atau target lainnya. Technical difficulties Merupakan bagian dari HOQ yang mengestimasi tingkat kesulitan yang dapat diantisipasi oleh perusahaan untuk menjalankan tujuan desain. Competitive evaluation Bagian ini digunakan untuk mengukur kinerja respon teknis dibandingkan dengan kemampuan perusahaan kompetitor. 5. Bagian tengah (Relationship Matrix) Relationship matrix Merupakan bagian dari HOQ yang menghubungkan antara ruang hows dan whats. Matriks ini mengaitkan hubungan respon teknis (technical requirements) dengan voice of customer. Simbol yang digunakan pada matriks hubungan ini adalah: Hubungan kuat – merupakan hubungan yang terjadi bila respon teknis berhubungan sangat erat atau sangat mempengaruhi terpenuhinya keinginan pelanggan. Dalam perhitungan bobot, hubungan kuat diberi nilai 9. Hubungan sedang – merupakan hubungan yang terjadi bila respon teknis berhubungan erat atau mempengaruhi terpenuhinya keinginan pelanggan. Dalam perhitungan bobot, hubungan sedang diberi nilai 3. Hubungan lemah – merupakan hubungan yang terjadi bila respon teknis tidak

begitu

mempengaruhi

terpenuhinya

keinginan

pelanggan.

Dalam

perhitungan bobot, hubungan lemah diberi nilai 1.



67

6. Bagian atap (Correlation Matrix) Correlation matrix Merupakan bagian atap pada HOQ yang mengidentifikasi apakah respon teknis saling mendukung atau saling mengganggu di dalam desain produk. Hubungan yang digunakan adalah: Hubungan positif kuat – hubungan yang searah, yaitu bilamana salah satu technical response mengalami peningkatan atau penurunan maka akan berdampak kuat pada peningkatan atau penurunan item lain yang terkait. Hubungan positif – hubungan yang searah, yaitu bilamana salah satu technical response mengalami peningkatan atau penurunan maka akan berdampak pada peningkatan atau penurunan item lain yang terkait. Hubungan negatif - hubungan yang tidak searah, yaitu bilamana salah satu technical response mengalami peningkatan atau penurunan maka akan berdampak pada penurunan atau peningkatan item lain yang terkait. Hubungan negatif kuat - hubungan yang tidak searah, yaitu bilamana salah satu technical response mengalami peningkatan atau penurunan maka akan berdampak kuat pada penurunan atau peningkatan item lain yang terkait. 2.6.2 Tahap-tahap Pembuatan HOQ Terdapat enam tahap utama dalam pembuatan HOQ 45, yaitu: 1. Mengevaluasi suara pelanggan (voice of customer) Tahap ini terbagi menjadi 3 langkah. Langkah pertama adalah mengembangkan kebutuhan pelanggan yang paling kritikal karena kebutuhan pelanggan merupakan penggerak di dalam QFD. Setelah diidentifikasi harus ada dasar yang rasional untuk mengevaluasi kebutuhan pelanggan mengenai apa yang akan pelanggan lakukan terhadap produk atau jasa tersebut. Ada beberapa metode yang berbeda seperti riset pasar, in depth qualitative interviews, dan concept engineering. Langkah kedua adalah mengelompokkan kebutuhan pelanggan 45

S. Bruce Han, et. al., “A conceptual QFD planning model”, in International

Journal of Quality & Reliability Management, Vol. 18 No. 8, 2001, hal. 798 – 806.



68

tersebut ke dalam 4 klasifikasi, yaitu satu dimensi, harus ada, atraktif, dan pembeda. Sedangkan langkah terakhir adalah memprioritaskan kebutuhan pelanggan sesuai dengan sudut pandang pelanggan. 2. Menganalisis persaingan Tahap ini terbagi menjadi 2 langkah yaitu membandingkan semua kebutuhan pelanggan yang dipilih dari sudut pandang pelanggan. Dalam QFD, perbandingan dilakukan dengan membandingkan perusahaan dengan competitor dalam performa kualitas pada masing-masing kebutuhan pelanggan. Informasi ini digunakan untuk menentukan kebutuhan pelanggan yang akan menghasilkan keunggulan kompetitif. Langkah kedua adalah menyusun target levels dari masing-masing kebutuhan pelanggan yang dipilih. Tagret levels tersebut yang akan menjadi pemicu dalam memilih proses pada tahap selanjutnya. 3. Menerjemahkan suara perusahaan Tahap ketiga ini bertujuan untuk menerjemahkan suara pelanggan ke dalam suara perusahaan. Suara perusahaan ini diekspresikan secara kuantitatif ke dalam bentuk kebutuhan desain. Pengembangan kebutuhan desain merupakan dasar dari proses perencanaan QFD 4. Menargetkan desain Tahap keempat ini terdiri dari 3 langkah. Langkah pertama untuk menjamin bahwa kebutuhan konsumen jelas dan tidak ambigu yang dapat menimbulkan kesalahpahaman dalam bentuk yang terukur. Salah satu tujuan utama dari langkah tersebut adalah untuk membantu tim QFD dalam menumbuhkan kepekaan terhadap kebutuhan desain yang harus dipenuhi. Sedangkan langkah kedua adalah menspesifikasikan target values dari masing58 masing kebutuhan desain. Target nilai ini kemudian dibandingkan dengan level target untuk setiap kebutuhan pelnaggan. Langkah ketiga adalah menentukan biaya proyek untuk mengubah kebutuhan desain menjadi spesifikasi target. 5. Membuat matriks hubungan Secara sederhana, hubungan antara kebutuhan pelanggan dan kebutuhan desain didefinisikan sebagai hubungan yang kuat, sedang, lemah, atau tidak ada sama sekali. Bobot kepentingan dari setiap kebutuhan desain ditentukan dari



69

persamaan berikut : Dj = Ai Rij

j , j = 1, K, m ..........................................(2.5)

dimana Dj = bobot kepentingan dari kebutuhan desain ke-j; Ai = bobot kepentingan dari kebutuhan pelanggan ke-i; Rij = nilai hubungan antara kebutuhan pelnaggan ke-i dan kebutuhan desain ke-j; n = banyaknya kebutuhan pelanggan; dan m = banyaknya kebutuhan desain 6. Membuat matriks korelasi Tahap ini terdiri dari 2 langkah yaitu membuat spesifikasi pilihan diantara kebutuhan desain. Mengidentifikasi apakah satu desain memiliki hubungan positif, negatif, atau tidak ada hubungan sama sekali (netral) dengan kebutuhan desain yang lain. Langkah kedua adalah memilih kebutuhan desain yang paling efektif dalam memenuhi kebutuhan pelanggan berdasarkan keterbatasan sumber daya

yang

dimiliki

oleh

perusahaan

dan

batasan-batasan

lainnya.



3. PENGUMPULAN DAN PENGOLAHAN DATA

Dalam manajemen resiko yang baik diperlukan suatu metode untuk dapat mengelola resiko dengan pandangan yang holistik. Salah satu metode yang banyak digunakan dalam menjalankan manajemen resiko adalah metode Australia and New Zeland Methodology AS/NZS 4360:1999. Metode ini dikembangkan oleh dua buah organisasi standardisasi dunia yaitu Standards Australia International dan Standards New Zeland. Metode yang dihasilkan dari kerja sama kedua buah organisasi ini memberikan suatu kerangka yang sistematis untuk

Mengontrol dan mengawasi

Mengkomunikasikan dan mengkonsultasikan

mengidentifikasi, menganalisa, mengevaluasi, memonitor dan memeriksa resiko.

Gambar 3.1 Metode Australia and New Zeland Methodology AS/NZS 4360:1999 Dari gambar 3.1, dapat dilihat tahapan utama manajemen resiko dimulai dari

mengidentifikasi

kesempatan

dan

tujuan,

mengidentifikasi

resiko,

menganalisa dan mengevaluasi resiko, dan membuat strategi tindakan penanganan resiko.


71

3.1

Mengidentifikasi Kesempatan dan Tujuan Dalam tahapan ini, diidentifikasi kesempatan dan tujuan apa yang

kemudian menjadi konteks bagi perusahaan dalam menjalankan manajemen resiko. Tanpa tujuan yang jelas dan eksplisit, akan sulit bagi manajemen perusahaan untuk menjalankan manajemen resiko dengan efektif. Setiap tujuan akan memiliki resiko yang berbeda. Dengan berpikir resiko dari aspek tujuan, perusahaan dapat menyusun kriteria untuk mengidentifikasi resiko. Hal ini akan membuat resiko-resiko yang teridentifikasi menjadi benarbenar relevan bagi perusahaan. Dalam tahapan mengidentifikasi kesempatan dan tujuan ini terdapat subsub tahapan yaitu membuat konteks strategi, membuat konteks organisasi, membuat konteks manajemen resiko, membuat kriteria evaluasi resiko, mendefinisikan struktur penyerahan. Tahapan mengidentifikasi kesempatan dan tujuan ini penting untuk: a. Menjamin level dari manajemen resiko adalah setingkat dengan kepentingan organisasi b. Menyiapkan sumber daya dan waktu yang cukup untuk manajemen resiko c. Menciptakan konsep dasar manajemen resiko 3.1.1

Membangun Konteks Strategi Dalam konteks strategi, analisa dilakukan terhadap bagaimana perusahaan

berhubungan dengan pihak eksternal perusahaan dan pengaruh apa yang dapat ditimbulkan dari hubungan ini. Untuk keperluan ini, perusahaan dapat melakukan analisa seperti analisa TOWS, analisa kebutuhan stakeholder, dan analisa lingkungan (PEST). Dari analisa ini, perusahaan dapat membuat: a. Pernyataan visi Dokumen tertulis yang mendefinisikan kondisi lingkungan operasional yang diinginkan dari pengimplementasian sistem ERP b. Sasaran performa



72

Kesepakatan mengenai tingkat performa yang ingin dicapai dari implementasi ERP Sebagai contoh, perusahaan memutuskan untuk menerapkan ERP setelah melihat kondisi lingkungan operasionalnya dimana para pesaing mendapatkan manfaat dari implementasi ERP. Untuk dapat tetap kompetitif (sasaran performa), perusahaan pun memutuskan untuk menerapkan ERP dalam sistemnya. Contoh lainnya, perusahaan menerapkan sistem ERP untuk dapat menghubungkan sistem internal bisnisnya dengan para pelanggan dan vendor. 3.1.2

Membangun Konteks Organisasi Dalam konteks organisasi, dilihat bagaimana tujuan dan sasaran

perusahaan mempengaruhi resiko yang harus ikut dipertimbangkan di dalam manajemen resiko. Berikut ini adalah beberapa alasan suatu perusahaan melakukan implementasi ERP: a. Meningkatkan performa bisnis b. Mendukung pertumbuhan bisnis c. Mendukung

pengambilan

keputusan

dengan

lebih

fleksibel,

terintegrasi dan real time sehingga meningkatkan waktu respon d. Mengeliminasi proses bisnis yang tidak efektif Dari identifikasi terhadap tujuan implementasi ERP ini, perusahaan dapat mengidentifikasi resiko sebagai faktor-faktor yang dapat menyebabkan tujuan implementasi ERP di atas tidak tercapai. 3.1.3

Membangun Konteks Manajemen Resiko Menurut Project Risk Management Handbook 2003, resiko dalam suatu

proyek teknologi informasi dapat digolongkan menjadi 5 buah kateogori yaitu resiko teknis, resiko manajemen proyek, resiko eksternal, resiko lingkungan dan resiko organisasi. Berikut ini adalah contoh resiko untuk masing-masing kategori a. Resiko teknis •

Desain kurang sempurna

•

Asumsi teknis yang tidak akurat dalam perencanaan



73

•

Perubahan permintaan

•

Desain yang dibuat konsultan tidak sesuai dengan standar perusahaan

b. Resiko manajemen Proyek •

Tujuan dan kebutuhan proyek tidak terdefinisikan dengan baik

•

Definisi ruang lingkup proyek tidak terdefinisikan dengan jelas

•

Jadwal, sasaran,dan biaya yang diinginkan tidak terdefinisikan dengan baik

•

Tidak adanya jaringan komunikasi dalam tim proyek

•

Kurangnya dukungan manajemen atas

c. Resiko eksternal •

Perubahan prioritas dalam program yang ada

•

Ketidakkonsistenan terhadap biaya, waktu, ruang lingkup dan kualitas

•

Perubahan pendanaan

•

Kemunculan stakeholder baru yang menyebabkan penambahan pekerjaan

d. Resiko lingkungan •

Lingkungan kerja yang berubah

e. Resiko organisasi •

Staf yang tidak berpengalaman

•

Beban kerja manajer proyek yang tidak dapat diantisipasi

Dari informasi ini, perusahaan dapat memperoleh informasi mengenai resiko apa saja yang perlu untuk dipertimbangkan dalam implementasi ERP. 3.1.4

Membuat Kriteria Evaluasi Resiko Dari tahapan membangun konteks strategi, organisasi dan manajemen

resiko, perusahaan dapat mulai untuk menetapkan kriteria evaluasi sebuah resiko. Dengan adanya kriteria ini, akan diperoleh definisi dan batasan yang jelas mengenai apa-apa saja yang menjadi resiko dalam implementasi ERP dan yang bukan. Dengan demikian, proses manajemen resiko akan mennjadi lebih efektif.



74

Suatu variabel diidentifikasi sebagai resiko dalam implementasi ERP apabila variabel tersebut memenuhi satu atau beberapa kondisi di bawah ini: a. Menyebabkan tidak tercapainya objektif atau sasaran dari implementasi ERP b. Menyebabkan keterlambatan penyelesaian proyek implementasi ERP c. Menyebabkan terjadinya over bujet biaya implementasi ERP Kriteria

evaluasi

resiko

ini

yang

kemudian

digunakan

untuk

mengidentifikasi resiko yang ada di dalam implementasi ERP.

3.2

Mengidentifikasi Resiko Dalam tahapan ini dilakukan identifikasi terhadap item resiko apa saja

yang dapat muncul di dalam implementasi ERP. Dalam mengidentifikasi resiko ini, penulis berusaha untuk mempertahankan agar resiko yang teridentifikasi ini bersifat umum terjadi dalam implementasi ERP. Hal ini dilakukan dengan harapan, hasil penelitian ini tidak hanya bermanfaat untuk suatu jenis industri tertentu saja. Untuk itu, penelitian ini lebih banyak menggunakan data-data yang berasal dari jurnal. Namun demikian, rekomendasi-rekomendasi dari praktisi konsultan ERP dari Accenture juga diharapkan dapat memperkaya analisa yang ada. Pengumpulan data untuk keperluan identifikasi resiko menggunakan metode kuesioner. Responden penelitian ini adalah para konsultan ERP dari Accenture yang telah berpengalaman menangani proyek ERP lebih dari 5 tahun. Para konsultan tersebut menduduki jabatan sebagai manajer di dalam struktur organisasi proyek ERP. Kuesioner ini bertujuan mengidentifikasi item-item resiko di dalam proyek ERP. Pada kuesioner ini, responden diminta untuk menambahkan item resiko yang belum termasuk ke dalam kuesioner.



75

ID

Risk Items

Rationale

< Reason why this risk item important to be included>

Gambar 3.2 Kuesioner Tahap Pertama Untuk penyusunan item resiko awal, penulis mengumpulkan item-item resiko yang terdapat di dalam jurnal-jurnal mengenai implementasi ERP. Dari jurnal yang berjudul Seven Keys to ERP Success (Jim Welch,Dmitry Kordysh, Strategic Finance, Sept 2007;89;3;ABI/INFORM Global pg.40), diperoleh 39 buah item resiko yang terbagi dalam 7 kategori yaitu: a. Kurangnya komitmen manajemen level atas terhadap proyek ERP b. Lemahnya proses implementasi c. Lemahnya fokus pada proses bisnis d. Tantangan adaptasi pengguna sistem e. Lemahnya dukungan organisasi f. Isu konfigurasi teknologi informasi g. Permasalahan infrastruktur Dari ketujuh kategori tersebut dapat terlihat bahwa dalam kesuksesan sebuah proyek implementasi ERP, faktor nonteknis seperti kurangnya komitmen manajemen terhadap proyek ERP turut berkontribusi terhadap gagal berhasilnya



76

proyek ERP. Jadi, tidak hanya faktor teknis seperti permasalahan infrastruktur dan teknologi informasi saja yang berpengaruh terhadap keberhasilan proyek ERP. Dari hasil pengolahan kuesioner tahap pertama ini, responden tidak memberikan tambahan item resiko. Hal ini disebabkan karena item resiko yang diajukan pada kuesioner tahap pertama sudah cukup mewakili kondisi yang terjadi dalam penerapan ERP. Berikut ini adalah daftar item resiko dalam proyek ERP yang berhasil teridentifikasi:

Tabel 3.1 Item Resiko Proyek ERP Item Resiko

ID

A1

Kurangnya komitmen manajemen level atas terhadap proyek ERP

A1-1

Pendefinisian perencanaan yang buruk untuk menghubungkan implementasi ERP dengan perubahan strategi perusahaan

A1-2

Kurangnya komitmen dari manajemen level atas dalam proyek ERP

A1-3

Kurangnya Roadmap yang kuat yang berperan memandu proses perubahan dalam organisasi selama proses implementasi berjalan

A1-4

Business case yang tidak terdefinisikan dengan baik,tidak mendorong, atau kurang cukupnya komitmen tim eksekutif untuk menjalankannya

A1-5

Pemisahan peran IT dalam kepentingan bisnis

A2

Lemahnya proses implementasi

A2-1

Gagal dalam memberikan perbaikan proses secara berkelanjutan

A2-2

Manajer

proses/pemilik

tidak

memiliki

akuntabilitas

yang

terdefinisikan dengan baik,atau tidak memiliki otoritas untuk pengambilan keputusan A2-3

Lemahnya pengambilan keputusan di antara pemilik proses dari unit bisnis yang berbeda, menghasilkan desain proses dan konfigurasi sistem yang menyimpang dari yang direncanakan



77

A2-4

Model pendanaan yang tidak efektif dan gagal menghasilkan peningkatan yang bernilai tinggi

A2-5

Pendefinisian akuntabilitas yang buruk dari integritas data master

A3

Lemahnya focus pada proses bisnis

A3-1

Gagal dalam mengimplementasikan best practices dan tidak memiliki rencana untuk mengimplementasikannya

A3-2

Tim implementasi gagal dalam memahami karakateristik sistem sehingga solusi yang dihasilkan tidak optimal

A3-3

Parameter performa dan target tidak terdefinisikan dengan baik; lemahnya hubungan antara desain proses dan business case

A3-4

Proses statis dan tidak dapat beradaptasi dengan perubahan kondisi bisnis

A3-5

Kekurangan dalam desain data master menghambat performa proses

A4

Tantangan adaptasi pengguna system

A4-1

Tidak cukupnya pelatihan

A4-2

Tidak cukupnya manajemen perubahan untuk membimbing pengguna sistem menjalankan peran dan proses yang baru

A4-3

Tidak cukupnya struktur dan sumber daya yang berperan sebagai user-support

A4-4

Tidak cukupnya dukungan dan akuntabilitas terhadap pelatihan dan manajemen pengetahuan yang berlangsung

A4-5

Rendahnya tingkat partisipasi pengguna sebelum dan sesudah fase implementasi

A5

Lemahnya dukungan organisasi

A5-1

Gagal dalam mengimplementasikan perubahan dalam definisi peran dan desain organisasi yang diperlukan untuk mencapai business case yang diharapkan

A5-2

Gagal dalam mengidentifikasi terjadinya gap talenta dalam perusahaan

A5-3

Organisasi fungsional tidak dipersiapkan dengan baik untuk



78

menggunakan sistem baru dengan efektif A5-4

Mengabaikan pentingnya pengukuran perkembangan dan performa di dalam proyek ERP

A5-5

Mengabaikan potensi komunikasi

A5-6

Tidak efektifnya peran manajemen konsultasi

A5-7

Rendahnya kapabilitas dalam manajemen proyek ERP

A6

Isu konfigurasi teknologi informasi

A6-1

Peran

dan

sistem

keamanan

yang

didefinisikan

terlalu

kaku;membatasi akses terhadap data dan penggunaan system A6-2

Sistem yang terlalu rumt dan tidak user friendly menyebabkan pengguna bekerja di luar sistem

A6-3

Data warehouse tidak diimplementasikan;menghambat efektivitas penggunaan data yang tersedia

A6-4

Sistem terlalu banyak dikustomisasi saat implementasi menyebabkan kesulitan dalam upgrade dan pemeliharaan

A6-5

Rendahnya fleksibilitas dalam aplikasi ERP yang digunakan

A6-6

Rendahnya dukungan terhadap beberapa fungsionalitas bisnis yang diperlukan

A6-7

Rendahnya parameterisasi, standardisasi, dan dokumentasi

A6-8

Penentuan pemilihan server yang tidak didasarkan kepada analisa keperluan penyimpanan data

A6-9

Terbatasnya integrasi aplikasi dan system

A6-10

Tidak berjalannya pemeliharaan pencegahan (preventive maintenance)

A7

Permasalahan infrastruktur

A7-1

Biaya operasional yang diestimasikan terlalu rendah melemahkan pencapaian business case

A7-2

Waktu respon sistem yang lambat,menghambat proses adopsi dan merusak produktivitas (sumber: penulis) Universitas Indonesia


79

3.3

Menganalisa dan Mengevaluasi Resiko Metode kuesioner kembali digunakan

untuk

menganalisa

dan

mengevaluasi resiko. Kuesioner tahap kedua ini bertujuan mendapatkan kategori resiko apakah suatu item resiko tergolong ke dalam resiko rendah, menengah atau tinggi. Untuk menentukan kategori tersebut, perlu dicari nilai resiko dari setiap item. Nilai resiko ini didapatkan dengan mengukur nilai bobot untuk tingkat dampak dan probabilitasnya. Nilai dampak adalah ukuran yang digunakan untuk mendefinisikan tingkat dampak suatu item resiko terhadap proyek ERP. Dampak resiko dilihat dari dua aspek yaitu waktu dan biaya proyek. Berikut ini adalah tabel yang memperlihatkan hubungan antara skala dalam kuesioner dengan nilai dampaknya dari perspektif waktu dan biaya.



80

Questionnaire 2 Instruction In this section,please give scoring for each risk item on the list for probability and impact score

add the <x> in the cell which you choose

From the example, it means that you see risk item "Ill defined plan for linking ERP enablement to strategic change" has low probability (rare) to happen and low impact if it happens Explanation about the Impact and Probability Scale could be seen in below tables

ID

Inadequate Executive Alignment (A1)

A1-1

Ill defined plan for linking ERP enablement to strategic change

A1-2

Top management lacks team commitment

A1-3

Lack of robust-front roadmap to guide the organization's change process

A1-4

Business case poorly defined, not compeling, or lacking adequate executive team commitment

A1-5

Separating IT from Business Affairs- Technical mind set

ID A2-1 A2-2 A2-3

Weak Post-Implementation (A2)

Impact (I) 2 4 8

16

1

Probability (P) 2 3 4 5

1

Impact (I) 2 4 8

16

1


1

Impact (I) 2 4 8

16

1


Failure to follow through and deliver continuous process improvement Process managers/owners are not appointed, their accountability is ill defined, or they lack real power to make decisions Weak decision making among process owners from different business units, resulting in diverging process designs and system configuration

A2-4

Funding model ineffective and fails to yield highest value enhancements

A2-5

Poorly defined accountability for master data integrity

ID

1

Lack of Focus on Business Process (A3)

A3-1

Failure to implement best practices during initial implementation, and no plan to get there

A3-2

Systems features poorly understood by implementation team, resulting in suboptimal solutions

A3-3

Performance metrics and targets not used or poorly defined; weak linkage between the process design and the business case

A3-4

Processes static and not adaptable to changing business conditions

A3-5

Flaws in master data design inhibit process performance

Gambar 3.3 Kuesioner Tahap Kedua



81

Tabel 3.2 Tabel Dampak Resiko Dampak (D) Tujuan

Sangat

Rendah

Sedang

Tinggi

rendah

Tinggi

1 Waktu

Sangat

2

4

8

16

Keterlambatan Keterlambatan Keterlambatan Keterlambatan

Waktu

penyelesaian penyelesaian proyek tidak proyek

<

penyelesaian 3 proyek

=


>


bulan

bulan

bulan

tahun

Peningkatan

Biaya

Biaya

Biaya

Biaya

biaya

meningkat

terpengaruh

>

signifikan Biaya

proyek tidak 5%

< meningkat 5- meningkat 10- meningkat 10%

20%

>20%

signifikan (sumber: penulis) Nilai probabilitas adalah ukuran yang digunakan untuk mendefinisikan tingkat kemungkinan terjadinya suatu item resiko. Jadi, ingin dilihat apakah suatu item resiko memiliki kemungkinan terjadi yang tinggi atau rendah. Skala yang digunakan untuk penilaian tingkat probabilitas ini dapat dilihat pada tabel berikut:

Tabel 3.3 Tabel Probabilitas Resiko Probabilitas (P) Skala

%

Level

5

91-100

Sangat Sering

4

51-90

Sering

3

21-50

Medium

2

6-20

Jarang

1

0-5

Sangat Jarang

(sumber: penulis)



1

82

Setelah

setiap

item

resiko

diberikan

nilai

bobot

dampak

dan

probabilitasnya. Nilai resiko dari suatu item resiko dapat diperoleh dengan mengalikan nilai probabilitas dengan nilai dampaknya. Setelah didapatkan nilai resiko untuk tiap-tiap item, langkah selanjutnya adalah penentuan kategori resiko untuk tiap-tiap item. Matriks penentuan kategori resiko digunakan untuk keperluan ini. Berikut ini adalah matriks yang digunakan untuk menentukan kategori suatu resiko:

Tabel 3.4 Tabel Matriks Resiko

(sumber:Office of Project Management Process Improvement, 2003, hal 24) Berikut ini adalah tabel rekapan hasil penilaian dampak dan probabilitas untuk tiap item resiko: Tabel 3.5 Tabel Skor dan Kategori Resiko Skor Kategori Resiko

ID

Skor

Resiko

Skor

Dampak Probabilitas A1-1

2.5

2.5

6.25

Menengah

A1-2

8

3.5

28

Tinggi

A1-3

6

3.5

21

Tinggi

A1-4

4

3

12

Menengah

A1-5

6

3.5

21

Tinggi

A2-1

4.5

4.5

20.25

Tinggi



83

A2-2

8

4

32

Tinggi

A2-3

8

4

32

Tinggi

A2-4

2.5

1.5

3.75

Rendah

A2-5

8

3.5

28

Tinggi

A3-1

8

2.5

20

Tinggi

A3-2

12

2

24

Tinggi

A3-3

6

3.5

21

Tinggi

A3-4

6

2.5

15

Menengah

A3-5

2.5

2

5

Rendah

A4-1

6

2.5

15

Menengah

A4-2

10

2.5

25

Tinggi

A4-3

4

3

12

Menengah

A4-4

3

3

9

Menengah

A4-5

4

3.5

14

Menengah

A5-1

2.5

2.5

6.25

Menengah

A5-2

3

2.5

7.5

Menengah

A5-3

3

2.5

7.5

Menengah

A5-4

4

3

12

Menengah

A5-5

4

3.5

14

Menengah

A5-6

6

2.5

15

Menengah

A5-7

5

3

15

Menengah

A6-1

3

2

6

Rendah

A6-2

4

2.5

10

Menengah

A6-3

3

3.5

10.5

Menengah

A6-4

8

2.5

20

Tinggi



84

A6-5

4

2.5

10

Menengah

A6-6

4

3.5

14

Menengah

A6-7

6

3.5

21

Tinggi

A6-8

6

2

12

Menengah

A6-9

3

2.5

7.5

Menengah

A6-

3

2.5

7.5

Menengah

A7-1

2.5

2

5

Rendah

A7-2

5

3.5

17.5

Tinggi

10

(sumber: penulis) Dari hasil pengolahan kuesioner tahap kedua ini, diperoleh informasi item resiko mana saja yang termasuk ke dalam kategori resiko tinggi, menengah, dan rendah. Dari total 39 buah item resiko, 14 item termasuk ke dalam kategori resiko tinggi, 21 item dengan kategori resiko menengah, dan 4 item termasuk ke dalam resiko rendah.

3.3.1

Analisa Item Kategori Resiko Tinggi Dari total 14 item yang termasuk ke dalam kategori resiko tinggi, kategori

A2 (lemahnya proses implementasi) menyumbang item terbanyak sebanyak 29%. Setelah itu berturut-turut antara lain kategori A1 (22%), A3 (21%), A6 (14%), A4 (7%), A7 (7%), dan A5 (0%).

Gambar 3.4 Proporsi Item Kategori Resiko Tinggi Universitas Indonesia


85

Tabel 3.6 Peringkat Proporsi Item Kategori Resiko Tinggi ID Item Resiko Tinggi A2


29%

A1

Kurangnya komitmen manajemen level 21% atas

A3

Lemahnya fokus pada proses bisnis

21%

A6


14%

A4


7%

A7


7%

A5


0%

(sumber: penulis) Berikut ini adalah item-item resiko yang termasuk ke dalam kategori tinggi: ID

Tabel 3.7 Item Kategori Resiko Tinggi Item Resiko

A2-2

Manajer proses/pemilik tidak memiliki akuntabilitas yang terdefinisikan dengan baik,atau tidak memiliki otoritas untuk pengambilan keputusan

A2-3

Lemahnya pengambilan keputusan di antara pemilik proses dari unit bisnis yang berbeda, menghasilkan desain proses dan konfigurasi sistem yang menyimpang dari yang direncanakan

A1-2


A2-5

Pendefinisian akuntabilitas yang buruk dari integritas data master

A4-2

Tidak

cukupnya

manajemen

perubahan

untuk

membimbing pengguna sistem menjalankan peran dan proses yang baru A3-2

Tim implementasi gagal dalam memahami karakateristik



86

sistem sehingga solusi yang dihasilkan tidak optimal A1-3

Kurangnya Roadmap yang kuat yang berperan memandu proses

perubahan

dalam

organisasi

selama

proses

implementasi berjalan A1-5


A3-3

Parameter performa dan target tidak terdefinisikan dengan baik; lemahnya hubungan antara desain proses dan business case

A6-7

Rendahnya parameterisasi, standardisasi, dan dokumentasi

A2-1

Gagal dalam memberikan perbaikan proses secara berkelanjutan

A3-1

Gagal dalam mengimplementasikan best practices dan tidak memiliki rencana untuk mengimplementasikannya

A6-4

Sistem terlalu banyak dikustomisasi saat implementasi menyebabkan kesulitan dalam upgrade dan pemeliharaan

A7-2

Waktu respon sistem yang lambat,menghambat proses adopsi dan merusak produktivitas (sumber: penulis)

3.3.1.1 Analisa Kategori Lemahnya Proses Implementasi (A2) Dari hasil pengolahan kuesioner terlihat dalam sebuah implementasi ERP faktor lemahnya proses implementasi menjadi faktor yang memiliki nilai resiko yang tinggi. Ada 4 item dari kategori ini yang termasuk ke dalam kategori resiko tinggi yaitu item A2-2, A2-3, A2-5, dan A2-1. a. Pengambilan keputusan menjadi hal yang krusial dalam menentukan keberhasilan implementasi ERP (A2-2 dan A2-3) Hal ini terlihat dari dua item resiko yang berhubungan dengan pengambilan keputusan dalam implementasi ERP yaitu A2-2 dan A2-3 yang menempati nilai resiko tertinggi dibandingkan dengan item resiko lainnya. Tidak adanya penanganan yang baik terhadap kedua item ini dapat menimbulkan resiko yang tinggi bagi keberhasilan impelementasi ERP. Lemahnya pengambilan keputusan dapat menyebabkan desain



87

proses dan konfigurasi sistem dalam implementasi ERP menjadi menyimpang dari yang direncakan. Manfaat yang diharapkan dari implementasi ERP pun menjadi tidak dapat dirasakan secara optimal. Selain itu, kedua item ini dinilai memiliki resiko tinggi dikarenakan dalam prakteknya banyak manajemen yang tidak mendefinisikan dengan baik akuntabilitas dan otoritas dari para pengambil keputusan dalam implementasi ERP. b. Pedefinisian akuntabilitas yang buruk dari integritas data master (A2-5) Data master adalah data-data utama yang terlibat di dalam sistem seperti data persediaan, bill of material. Untuk berfungsi dengan optimal, sistem ERP memerlukan data dengan tingkat integritas yang tinggi. Artinya datadata tersebut harus benar-benar lengkap dan terstruktur dengan baik. Untuk itu, sangat penting dilakukan penetapan yang jelas siapa yang bertanggung jawab menjaga akuntabilitas dan integritas dari data master tersebut. c. Gagal dalam memberikan perbaikan proses secara berkelanjutan (A2-1) Item ini dinilai memiliki resiko tinggi karena manfaat ERP paling dapat dirasakan apabila diikuti oleh perbaikan terus-menerus terhadap proses bisnis yang dimilikinya. Dengan menerapkan sistem ERP sesungguhnya kesempatan bagi perusahaan untuk mengevaluasi proses bisnis yang dimilikinya apakah sudah efektif dan efisien. Tidak adanya perbaikan proses secara berkelanjutan dapat menyebabkan investasi dalam implementasi ERP menjadi tidak sepenuhnya optimal.

3.3.1.2 Analisa Kategori Kurangnya komitmen manajemen level atas (A1) Dari kategori ini, terdapat 3 buah item resiko termasuk ke dalam kategori resiko tinggi yaitu item A1-2, A1-3, dan A1-5. a. Kurangnya komitmen manajemen level atas terhadap proyek ERP (A1-2) Tidak jarang kegagalan implementasi ERP dikarenakan kurangnya komitmen dan dukungan manajemen terhadap implementasi ERP. Komitmen ini pulalah yang akan menentukan keseriusan manajemen dalam menerapkan manajemen resiko dalam implementasi ERP.



88

b. Tidak adanya roadmap yang kuat (A1-3) Tidak adanya roadmap yang kuat dapat menyebabkan proses perubahan organisasi dalam implementasi ERP menjadi tidak berjalan dengan baik. Hal ini dapat menyebabkan ketidakjelasan arah implementasi ERP. c. Pemisahan peran IT dalam kepentingan bisnis (A1-5) Implementasi ERP tidak boleh hanya dilihat sebagai proyek TI saja. Perusahaan perlu melihat implementasi ERP sebagai enabler strategi bisnis perusahaan.

3.3.1.3 Analisa Kategori Lemahnya Fokus Pada Proses Bisnis (A3) Ada tiga item dari kategori A3 yang dapat dikategorikan sebagai resiko tinggi yaitu A3-2, A3-3, dan A3-1. a. Tim implementasi gagal dalam memahami karakateristik sistem sehingga solusi yang dihasilkan tidak optimal (A3-2) Sistem ERP adalah salah satu sistem teknologi informasi yang paling kompleks yang diterapkan dalam sebuah perusahaan. Kegagalan dalam memahami karakteristik sistem dalam perusahaan dapat menyebabkan solusi yang dihasilkan dari implementasi ERP menjadi tidak optimal. b. Parameter performa dan target tidak terdefinisikan dengan baik; lemahnya hubungan antara desain proses dan business case (A3-3) Sistem ERP memerlukan waktu yang cukup lama untuk dapat dirasakan manfaatnya. Untuk dapat mempertahankan motivasi para manajemen dan pengguna, sangat penting untuk membangun penilaian performa yang dapat memberikan informasi mengenai arah kemajuan dari implementasi ERP (Al-Mashari and Zairi, 2000a). c. Gagal dalam mengimplementasikan best practices dan tidak memiliki rencana untuk mengimplementasikannya (A3-1) Salah satu kelebihan dari pengimplementasian ERP dalam sebuah perusahaan adalah perusahaan dapat mengevaluasi dan memperbaiki proses

bisnisnya.

Perusahaan

yang

tidak

berencana

untuk

mengimplementasikan proses bisnis yang best practices tidak dapat merasakan manfaat sepenuhnya implementasi sistem ERP.



89

3.3.1.4 Analisa Kategori Isu Konfigurasi Teknologi Informasi (A6) Ada satu item dari kategori A6 yang dapat dikategorikan sebagai resiko tinggi yaitu A6-4. a. Sistem terlalu banyak dikustomisasi saat implementasi menyebabkan kesulitan dalam upgrade dan pemeliharaan (A6-4) Tingkat kustomisasi yang terlalu tinggi dalam implementasi ERP memiliki resiko yang tinggi akan timbulnya masalah di masa depan. Implementasi ERP pun akan menjadi lebih mahal. 3.3.1.5 Analisa Kategori Tantangan Adaptasi Pengguna Sistem (A4) Ada satu item dari kategori A4 yang dapat dikategorikan sebagai resiko tinggi yaitu A4-2. b. Tidak cukupnya manajemen perubahan untuk membimbing pengguna sistem menjalankan peran dan proses yang baru Salah satu tantangan terberat di dalam implementasi ERP adalah mengelola perubahan yang terjadi di dalam organisasi pascaimplementasi ERP. Banyak perusahaan yang gagal mendapatkan manfaat dari implementasi

ERP

dikarenakan

lemahnya

manajemen

perubahan.

Organisasi masih menggunakan cara kerja yang lama sekalipun sistem yang baru sudah diimplementasikan. Investasi yang dikeluarkan untuk sistem ERP pun menjadi terbuang sia-sia.

3.3.1.6 Analisa Kategori Permasalahan Infrastruktur (A7) Ada satu item dari kategori A7 yang dapat dikategorikan sebagai resiko tinggi yaitu A7-2. a. Waktu respon sistem yang lambat Permasalahan infrastruktur seperti waktu respon sistem yang lambat, jaringan yang tidak dapat mengakomodasi volume lalu lintas data dapat menghambat proses adopsi dan merusak produktivitas .



90

3.3.1.7 Analisa Kategori Lemahnya Dukungan Organisasi (A5) Tidak ada item dari kategori A5 yang dapat dikategorikan sebagai resiko tinggi. Item resiko dari kategori A5 ini lebih banyak ditemukan pada kategori resiko menengah. Hal ini mengindikasikan item resiko dalam kategori ini dipandang penting untuk diperhatikan dalam implementasi ERP, namun perusahaan pada umumnya sudah memiliki tindakan penanganan terhadap item resiko ini.

3.3.2 Analisa Item Kategori Resiko Menengah Gambar 3.5 memperlihatkan proporsi item yang memiliki kategori resiko menengah.

Gambar 3.5 Proporsi Item Kategori Resiko Menengah Tabel 3.8 memperlihatkan peringkat proporsi item kategori resiko menengah. Dari tabel ini terlihat kategori resiko lemahnya dukungan organisasi dan isu konfigurasi teknologi informasi memiliki persentase terbanyak yaitu sebesar 33%. Hal ini mengindikasikan kedua kategori tersebut dipandang memiliki tingkat resiko menengah. ID

Tabel 3.8 Proporsi Item Kategori Resiko Menengah Item Resiko Menengah

A5


33%

A6


33%

A4


19%

A1




91

A3


5%

A2


0%

A7


0%

(sumber: penulis) Berikut ini adalah item-item resiko yang termasuk ke dalam kategori menengah: ID A1-1

Tabel 3.9 Item Kategori Resiko Menengah Item Resiko Pendefinisian

perencanaan

yang

buruk

untuk

menghubungkan implementasi ERP dengan perubahan strategi perusahaan A3-4


A4-1


A5-6


A5-7


A4-5

Rendahnya tingkat partisipasi pengguna sebelum dan sesudah fase implementasi

A5-5


A6-6


A1-4

Business case yang tidak terdefinisikan dengan baik,tidak mendorong, atau kurang cukupnya komitmen tim eksekutif untuk menjalankannya

A4-3


A5-4

Mengabaikan pentingnya pengukuran perkembangan dan performa di dalam proyek ERP

A6-8

Penentuan pemilihan server yang tidak didasarkan kepada analisa keperluan penyimpanan data



92

A6-3

Data warehouse tidak diimplementasikan;menghambat efektivitas penggunaan data yang tersedia

A6-2

Sistem yang terlalu rumit dan tidak user friendly menyebabkan pengguna bekerja di luar sistem

A6-5

Rendahnya

fleksibilitas

dalam

aplikasi

ERP

yang

digunakan A4-4

Tidak cukupnya dukungan dan akuntabilitas terhadap pelatihan dan manajemen pengetahuan yang berlangsung

A5-2

Gagal dalam mengidentifikasi terjadinya gap talenta dalam perusahaan

A5-3

Organisasi fungsional tidak dipersiapkan dengan baik untuk menggunakan sistem baru dengan efektif

A6-9


A6-

Tidak berjalannya pemeliharaan pencegahan (preventive

10

maintenance)

A5-1

Gagal dalam mengimplementasikan perubahan dalam definisi peran dan desain organisasi yang diperlukan untuk mencapai business case yang diharapkan (sumber: penulis)

3.3.2.1 Analisa Kategori Lemahnya Dukungan Organisasi (A5) Ada tujuh item dari kategori A5 yang dapat dikategorikan sebagai resiko menengah yaitu A5-6, A5-7, A5-5, A5-4, A5-2, A5-3 dan A5-1 . a. Tidak efektifnya peran manajemen konsultasi (A5-6) Konsultan ERP sangat berperan dalam memberikan edukasi mengenai cara kerja sistem ERP di dalam proses bisnis perusahaa. Hal ini dikarenakan perusahaan tidak memiliki pengetahuan awal yang memadai tentang implementasi ERP. Peran konsultan akan sangat penting sepanjang berjalannya proses implementasi. Peran konsultan dalam proyek ERP antara lain:



93

•

Enabler dan information resource Æ konsultan memiliki keahlian konsultansi, pengalaman best practices, benchmarking, dsb. Keahlian ini berguna dalam menetapkan ekspetasi dan standar performa dari proyek ERP.

•

Co-InnovatorÆ konsultan berperan dalam membantu perusahaan dalam menginterpretasikan dan memberi advokasi terhadap keinginan dan kebutuhan perusahaan dengan menyediakan sistem teknologinya.

b. Rendahnya kapabilitas dalam manajemen proyek ERP (A5-7) Setiap proyek implementasi sebuah sistem menghadapi tantangan dari aspek finansial, fungsional, dan teknikal. Begitu pula dengan proyek ERP. Sistem ERP dapat dikatakan sebagai sebuah sistem bisnis yang paling kompleks yang diterapkan dalam sebuah perusahaan. Kompleksitas ini terlihat dari tingginya jumlah pengguna sistem, ukuran database, volume transaksi, dan sebagainya. Manajemen proyek dan perubahan menjadi salah satu faktor kunci kesuksesan

implementasi

ERP

(Davenport,

2000;

Mandal

and

Gunasekaran, 2003; Motwani et al. 2002). c. Mengabaikan potensi komunikasi (A5-5) Komunikasi adalah hal yang sangat kritikal dalam implementasi ERP (Falkowski et al.,1998). Kegagalan dalam manajemen perubahan dapat disebabkan oleh kurangnya komunikasi di antara pengguna sistem. Para karyawan perlu dikomunikasikan ruang lingkup, tujuan dan kegiatan dalam proses perubahan yang terjadi dalam implementasi ERP (Sumner, 1999). d. Mengabaikan pentingnya pengukuran perkembangan dan performa di dalam proyek ERP (A5-4) Sistem performa diperlukan untuk memonitor kemajuan usaha manajemen perubahan ERP (Aladwani, 2001). Pengukuran performa implementasi ERP sangat penting untuk terus memotivasi para pengguna system ERP terlibat di dalam implementasi ERP. e. Gagal dalam mengidentifikasi terjadinya gap talenta dalam perusahaan (A5-2)



94

Implementasi sistem ERP menyebabkan terjadinya perubahan cara kerja. Hal ini menuntut adanya perubahan kualifikasi dari pengguna sistem. Resiko ini sedikit banyak sudah dapat teratasi dari pelatihan yang diberikan oleh konsultan ERP. Konsultan ERP yang akan berperan untuk menyusun kualifikasi yang diperlukan dan dari informasi ini akan diberikan pelatihan untuk mengatasi terjadinya gap talenta tersebut. f. Organisasi fungsional tidak dipersiapkan dengan baik untuk menggunakan sistem baru dengan efektif (A5-3) Tidak cukupnya komunikasi dan pelatihan akan menyebabkan pengguna sistem tidak siap untuk menggunakan sistem ERP di dalam operasional pekerjaannya. g. Gagal dalam mengimplementasikan perubahan dalam definisi peran dan desain organisasi yang diperlukan untuk mencapai business case yang diharapkan (A5-1) Keberhasilan dalam implementasi ERP memerlukan perubahan peran dari para pengguna sistem. Hal ini terkait dengan perubahan cara kerja dari pemiliki proses pasca implementasi sistem ERP.

3.3.2.2 Analisa Kategori Isu Konfigurasi Teknologi Informasi (A6) Ada tujuh item dari kategori A6 yang dapat dikategorikan sebagai resiko menengah yaitu A6-6, A6-8, A6-3, A6-2, A6-5, A6-9, A6-10. a. Rendahnya dukungan terhadap beberapa fungsionalitas bisnis yang diperlukan (A6-6) Dalam memilih aplikasi sistem ERP yang akan digunakan, perusahaan perlu untuk memastikan aplikasi yang dipilih dapat mengakomodasi kebutuhan fungsionalitas bisnis perusahaan. b. Penentuan pemilihan server yang tidak didasarkan kepada analisa keperluan penyimpanan data (A6-8) Analisa keperluan penyimpanan data diperlukan untuk memastikan server yang dipilih dapat menampung lalu lintas transaksi data perusahaan. Hal ini akan mencegah terjadinya sistem tidak berjalan dengan optimal dikarenakan lemahnya dukungan infrastruktur data.



95

c. Data

warehouse

tidak

diimplementasikan;menghambat

efektivitas

penggunaan data yang tersedia (A6-3) Data warehouse dalam sistem ERP diperlukan untuk memastikan data-data yang terlibat di dalam transaksi perusahaan tersimpan dan terkoordinasi dengan baik. Hal ini juga dimaksudkan untuk menjaga data-data yang digunakan tetap berkualitas dan memiliki akurasi yang tinggi. Selain itu, dengan adanya data warehouse, akan menunjang pengguna sistem untuk menggunakan dan memanipulasi data (data mining). d. Sistem yang terlalu rumit dan tidak user friendly menyebabkan pengguna bekerja di luar sistem (A6-2) Konsultan ERP harus membuat desain user interface dari sistem ERP yang dapat memudahkan para penggunanya untuk menggunakan sistem tersebut. e. Rendahnya fleksibilitas dalam aplikasi ERP yang digunakan (A6-5) Salah satu implikasi dari implementasi sistem ERP adalah adanya pembatasan akses terhadap data-data tertentu sesuai dengan peran dari pengguna sistem. Hal ini dimaksudkan untuk menjaga integritas data yang ada. Namun demikian, terlampau rendahnya fleksibilitas dalam akses terhadap data ini dapat menyebabkan pengguna akhirnya bekerja di luar sistem ERP. Dalam hal ini, sangat penting untuk memastikan setiap pengguna memiliki akses terhadap data yang dibutuhkannya. f. Terbatasnya integrasi aplikasi dan system (A6-9) Konsultan ERP perlu untuk memastikan sistem ERP dapat terintegrasi dengan sistem lama yang sudah diimplementasikan terlebih dahulu. Mengintegrasikan sistem ERP dengan sistem TI lama perusahaan bukanlah hal yang mudah. Konsultan ERP dan manajemen perusahaan perlu untuk berdiskusi untuk memutuskan apakah tetap mempertahankan sistem TI lama dan kemudian mencoba untuk mengintegrasikannya dengan sistem ERP atau memutuskan untuk mengganti sistem TI yang lama. g. Tidak berjalannya pemeliharaan pencegahan (A6-10)



96

Pemeliharaan pencegahan (preventive maintenance) penting untuk memastikan infrastuktur TI perusahaan mampu beroperasi dengan optimal.

3.3.2.3 Analisa Kategori Tantangan Adaptasi Pengguna Sistem (A4) Ada empat item dari kategori A4 yang dapat dikategorikan sebagai resiko menengah yaitu A4-1, A4-5, A4-3, dan A4-4. a. Tidak cukupnya pelatihan (A4-1) Perubahan cara kerja yang timbul dari implementasi ERP menyebabkan diperlukannya pelatihan untuk para pengguna sistem ERP. Konsultan ERP berperan untuk memastikan pelatihan yang diberikan sudah mencukupi. b. Rendahnya tingkat partisipasi pengguna sebelum dan sesudah fase implementasi (A4-5) Sangat penting untuk melibatkan pengguna sistem di dalam fase sebelum dan sesudah implementasi. Hal ini untuk menangkap apa yang menjadi kebutuhan dari pengguna sistem. Cara ini juga dimaksudkan untuk memperoleh komitmen para pengguna sistem terhadap implementasi ERP. c. Tidak cukupnya struktur dan sumber daya yang berperan sebagai usersupport (A4-3) Perusahaan perlu memastikan tersedianya user support dan sumber daya untuk mendukung operasional harian selama implementasi berlangsung. Secara spesifik, manajemen dapat membuat help desk untuk keperluan ini. Manajemen

menyediakan

pelatihan

termasuk

pada

fase

pasca

implementasi. d. Tidak cukupnya dukungan dan akuntabilitas terhadap pelatihan dan manajemen pengetahuan yang berlangsung (A4-4) Manajemen perlu memberikan dukungan dan perhatian terhadap proses pelatihan dan manajemen pengetahuan dalam implementasi ERP.

3.3.2.4 Analisa Kategori Kurangnya Komitmen Manajemen Level Atas (A1) Ada dua item dari kategori A1 yang dapat dikategorikan sebagai resiko menengah yaitu A1-1 dan A1-4.



97

a. Pendefinisian

perencanaan

yang

buruk

untuk

menghubungkan

implementasi ERP dengan perubahan strategi perusahaan (A1-1) Tidak jarang ditemukan perusahaan yang tidak menghubungkan strategi implementasi

ERP

dengan

strategi

bisnis

perusahaan.

Hal

ini

mengakibatkan manfaat dari sistem ERP tidak dapat dirasakan dengan optimal. b. Business case yang tidak terdefinisikan dengan baik,tidak mendorong, atau kurang cukupnya komitmen tim eksekutif untuk menjalankannya (A1-4) Penyusunan business case ini bukanlah suatu hal yang mudah. Kesulitan dapat timbul dari sulitnya mengukur secara pasti nilai manfaat dari implementasi ERP.

3.3.2.5 Analisa Kategori Lemahnya Fokus Pada Proses Bisnis (A3) Ada satu item dari kategori A3 yang dapat dikategorikan sebagai resiko menengah yaitu A3-4. a. Proses statis dan tidak dapat beradaptasi dengan perubahan kondisi bisnis (A3-4) Banyak perusahaan yang tidak secara terus menerus melakukan proses perbaikan setelah proyek ERP dijalankan. Padahal perubahan kondisi bisnis menuntut perusahaan untuk beradaptasi untuk dapat terus kompetitif.

3.3.2.6 Analisa Kategori Lemahnya Proses Implementasi (A2) Tidak ada item dari kategori A2 yang dapat dikategorikan sebagai resiko menengah.

3.3.2.7 Analisa Kategori Permasalahan Infrastruktur (A7) Tidak ada item dari kategori A7 yang dapat dikategorikan sebagai resiko menengah



98

3.3.3

Analisa Item Kategori Resiko Rendah Gambar 3.6 memperlihatkan proporsi item yang memiliki kategori resiko

rendah.

Gambar 3.6 Proporsi Item Kategori Resiko Rendah Tabel 3.10 Peringkat Proporsi Item Kategori Resiko Rendah ID Item Resiko Rendah A2


25%

A3


25%

A6


25%

A7


25%

A1


A4


0%

A5


0%

(sumber: penulis) Berikut ini adalah item-item resiko yang termasuk ke dalam kategori rendah:

ID A2-4

Tabel 3.11 Item Kategori Resiko Rendah Item Resiko Model

pendanaan

yang

tidak

efektif

dan

gagal

menghasilkan peningkatan yang bernilai tinggi



99

A3-5


A6-1

Peran dan sistem keamanan yang didefinisikan terlalu kaku;membatasi akses terhadap data dan penggunaan system

A7-1

Biaya operasional yang diestimasikan terlalu rendah melemahkan pencapaian business case (sumber: penulis)

3.3.3.1 Analisa Kategori Lemahnya Proses Implementasi (A2) Ada satu item dari kategori A2 yang dapat dikategorikan sebagai resiko tinggi yaitu A2-4. a. Model pendanaan yang tidak efektif dan gagal menghasilkan peningkatan yang bernilai tinggi Model pendanaan dikategorikan sebagai resiko yang rendah karena perusahaan dalam menyusun model pendanaannya sudah melalui konsultasi dengan konsultan ERP terlebih dahulu. 3.3.3.2 Analisa Kategori Lemahnya Fokus Pada Proses Bisnis (A3) Ada satu item dari kategori A3 yang dapat dikategorikan sebagai resiko tinggi yaitu A3-5. a. Kekurangan dalam desain data master menghambat performa proses Resiko yang dapat muncul dari kurangnya desain data master sudah ditransfer menjadi tanggung jawab dari konsultan ERP. 3.3.3.3 Analisa Kategori Isu Konfigurasi Teknologi Informasi (A6) Ada satu item dari kategori A6 yang dapat dikategorikan sebagai resiko tinggi yaitu A6-1. a. Peran dan sistem keamanan yang didefinisikan terlalu kaku;membatasi akses terhadap data dan penggunaan system Perlu diperhatikan bahwa para pengguna sistem memiliki akses terhadap data yang dibutuhkannya.



100

3.3.3.4 Analisa Kategori Permasalahan Infrastruktur (A7) Ada satu item dari kategori A7 yang dapat dikategorikan sebagai resiko tinggi yaitu A7-1. a. Biaya operasional yang diestimasikan terlalu rendah melemahkan pencapaian business case Manajemen perusahaan bersama-sama dengan konsultan ERP melakukan estimasi terhadap biaya operasional yang dibutuhkan selama implementasi ERP berlangsung. 3.3.3.5 Analisa Kategori Kurangnya Komitmen Manajemen Level Atas (A1) Tidak ada item dari kategori A1 yang dapat dikategorikan sebagai resiko tinggi.

3.3.3.6 Analisa Kategori Tantangan Adaptasi Pengguna Sistem (A4) Tidak ada item dari kategori A4 yang dapat dikategorikan sebagai resiko tinggi.

3.3.3.7 Analisa Kategori Lemahnya Dukungan Organisasi (A5) Tidak ada item dari kategori A7 yang dapat dikategorikan sebagai resiko tinggi.

3.3.4 Analisa Keseluruhan Kategori Resiko Tabel 3.12 Persebaran Item Resiko ID Tinggi Menengah Rendah A1 A2 A3 A4 A5 A6 A7

3 4 3 1 0 2 1

2 0 1 4 7 7 0 (sumber: penulis)

0 1 1 0 0 1 1



101

100% 80%

1

60%

Menengah

4 3

Tinggi

40% 3

Rendah

2

20% 1 0% A1

A2

A3

A4

0 A5

A6

A7

Gambar 3.7 Proporsi Keseluruhan Kategori Level Resiko Dari grafik di atas, dapat diperoleh informasi mengenai komposisi tingkat resiko untuk tiap kategori resiko. Informasi yang dapat kita peroleh dari grafik tersebut antara lain: a. Tidak adanya item dengan kategori resiko rendah untuk kategori resiko A1, A4, dan A5 b. Tidak adanya item dengan kategori resiko menengah untuk kategori resiko A2 dan A7 c. Tidak adanya item dengan kategori resiko tinggi untuk kategori resiko A5. Semua item resiko dalam kategori A5 memiliki tingkat resiko menengah



4. ANALISIS

4.1

Perencanaan Tindakan Penanganan Resiko Dalam penanganan suatu resiko, perlu diperhatikan peringkat resiko

tersebut. Resiko dapat dikelompokkan dalam tiga kategori: tinggi, menengah dan rendah. Semakin tinggi suatu resiko semakin memerlukan perhatian khusus dan priorias penanganan. Perencanaan tindakan penangan resiko dalam penelitian ini akan diprioritaskan pada item dengan kategori resiko tinggi. Manajemen perlu menentukan strategi tindakan penanganan tiap item resiko. Secara umum, ada empat strategi utama dalam penanganan resiko: menghindari (avoidance), memindahkan resiko (transfer), mengurangi resiko (mitigate) dan menerima resiko (accept). Dalam penelitian ini, strategi penanganan resiko yang dominan adalah mengindari resiko (avoidance). Penyusunan strategi penanganan resiko dilakukan melalui pengumpulan rekomendasi tindakan penanganan melalui penyebaran kuesioner, wawancara konsultan ERP dan studi literatur jurnal.

4.1.1

Pengumpulan Rekomendasi Tindakan Penanganan Melalui Kuesioner Kuesioner untuk mendapatkan rekomendasi tindakan penanganan ini

bersifat open question. Artinya, responden dapat memberikan rekomendasi tanpa dibatasi jumlah rekomendasi. Responden dalam kuesioner ini adalah responden yang sama dengan responden pada kuesioner pertama dan kedua yaitu konsultan ERP dari Accenture. Para responden ini memberikan rekomendasi tindakan penanganan resiko

berdasarkan

pengalaman

profesional

mereka

dalam

menangani

implementasi ERP. Gambar 4.1 adalah contoh kuesioner yang digunakan untuk mendapatkan rekomendasi tindakan penanganan resiko.


103

Gambar 4.1 Kuesioner Rekomendasi Tindakan Penanganan Resiko Hasil lengkap kuesioner rekomendasi tindakan penanganan resiko dapat dilihat pada lampiran 5. Dari kuesioner ini, terlihat adanya hubungan keterkaitan antarresiko dimana. Hal ini berimplikasi pada suatu tindakan penanganan resiko dapat mengatasi lebih dari satu item resiko. Untuk itu, penulis melakukan pengelompokkan terhadap item-item resiko yang saling berkaitan dan memiliki tindakan penanganan yang sama. Dari pengelompokkan ini diperoleh 6 buah aktivitas utama tindakan penanganan resiko. Aktivitas tersebut antara lain: a. Pendefinisian tanggung jawab dan otoritas pengambilan keputusan dari para manajer dan pemilik proses yang terlibat di dalam proyek ERP Tindakan penanganan ini diperlukan menangani untuk item resiko: •

Manajer

proses/pemilik

tidak

memiliki

akuntabilitas

yang

terdefinisikan dengan baik,atau tidak memiliki otoritas untuk pengambilan keputusan (A2-2) •

Lemahnya pengambilan keputusan di antara pemilik proses dari unit bisnis yang berbeda, menghasilkan desain proses dan konfigurasi sistem yang menyimpang dari yang direncanakan (A2-3)

•

Pendefinisian akuntabilitas yang buruk dari integritas data master (A25)



104

b. Upaya peningkatan komitmen dari manajemen level atas terhadap proyek ERP Tindakan penanganan ini diperlukan menangani untuk item resiko: • Kurangnya komitmen manajemen level atas dalam proyek ERP (A1-2) c. Manajemen perubahan proyek ERP Tindakan penanganan ini diperlukan menangani untuk item resiko: •

Tidak cukupnya manajemen perubahan untuk membimbing pengguna sistem menjalankan peran dan proses yang baru (A4-2)

•

Kurangnya Roadmap yang kuat yang berperan memandu proses perubahan dalam organisasi selama proses implementasi berjalan (A13)

•

Rendahnya parameterisasi, standardisasi, dan dokumentasi (A6-7)

d. Studi kelayakan untuk memahami sistem secara lebih komprehensif Tindakan penanganan ini diperlukan menangani untuk item resiko: •

Tim implementasi gagal dalam memahami karakateristik sistem sehingga solusi yang dihasilkan tidak optimal (A3-2)

•

Waktu respon sistem yang lambat,menghambat proses adopsi dan merusak produktivitas (A7-2)

e. Penyusunan business case Tindakan penanganan ini diperlukan menangani untuk item resiko: •

Pemisahan peran IT dalam kepentingan bisnis (A1-5)

•

Parameter performa dan target tidak terdefinisikan dengan baik; lemahnya hubungan antara desain proses dan business case (A3-3)

f. Perbaikan proses yang berkelanjutan untuk mencapai best practices Tindakan penanganan ini diperlukan menangani untuk item resiko: •

Gagal dalam memberikan perbaikan proses secara berkelanjutan (A21)



105

•

Gagal dalam mengimplementasikan best practices dan tidak memiliki rencana untuk mengimplementasikannya (A3-1)

•

Sistem terlalu banyak dikustomisasi saat implementasi menyebabkan kesulitan dalam upgrade dan pemeliharaan (A6-4)

4.1.2

Pendefinisian Tanggung Jawab dan Otoritas Pengambilan Keputusan Pengambilan keputusan adalah hal yang kritis di sepanjang dan sesudah

proses implementasi proyek ERP. Banyak keputusan penting yang perlu diambil dan keputusan ini mempengaruhi keberhasilan atau kegagalan implementasi ERP. Pengambilan keputusan dalam implementasi ERP tidaklah mudah Hal ini dikarenakan kompleksnya implementasi ERP. Banyak aspek yang perlu dipertimbangkan mengingat setiap keputusan yang diambil dapat mempengaruhi berbagai unit bisnis dan fungsi. Contohnya, pemilik proses harus menentukan mempertahankan proses bisnis saat ini atau mengikuti best practices. Besarnya dampak dari sebuah keputusan tidak jarang membuat pengambil keputusan takut dalam mengambil keputusan. Mereka takut dipersalahkan oleh pihak manajemen apabila keputusan yang diambilnya menyebabkan masalah di kemudian hari. Kondisi ini

dapat menyebabkan terhambatnya proses

implementasi ERP. Contoh pengambilan keputusan penting dalam implementasi ERP adalah keputusan terkait dengan integritas data master. Data master adalah data-data utama yang terlibat di dalam sistem seperti data persediaan, bill of material, dsb. Untuk berfungsi dengan optimal, sistem ERP memerlukan data dengan tingkat integritas yang tinggi. Artinya data-data tersebut harus benar-benar lengkap dan terstruktur dengan baik. Untuk itu, sangat penting adanya penetapan yang jelas orang yang bertanggung jawab terhadap akuntabilitas dan integritas dari data master tersebut. Selain

permasalahan

kompleksitas,

tidak

efektifnya

pengambilan

keputusan juga disebabkan oleh tidak terdefinisikannya dengan baik otoritas dari pengambil keputusan. Para pemilik proses bisnis tidak mengetahui dengan jelas apa yang menjadi peran dan tanggung jawabnya. Tidak ada pendefinisian formal



106

mengenai peran dan tanggung jawab dapat menyebabkan kebingungan dalam pengambilan suatu keputusan (Dutta and Evrard, 1999). Perusahaan dapat berdiskusi dengan konsultan ERP untuk menentukan peran dan tanggung jawab yang diperlukan dalam sebuah implementasi ERP. Konsultan ERP dapat memberikan informasi mengenai keputusan apa yang perlu diambil selama implementasi berlangsung, kualifikasi apa yang dibutuhkan dari pengambil keputusan, serta otoritas apa yang diperlukan. Proses ini harus dilakukan di awal proyek supaya saat proses implementasi berlangsung tidak ada kebingungan siapa yang bertanggung jawab terhadap suatu pengambilan keputusan saat implementasi sudah berlangsung. Beberapa hal yang perlu diperhatikan manajemen adalah: •

Manjemen

perlu

memastikan

para

pengambil

keputusan

dalam

implementasi ERP memahami dengan baik proses bisnis yang menjadi tanggung jawabnya, cara kerja sistem ERP, tujuan implementasi ERP, dsb. Hal ini agar keputusan yang diambil sesuai dengan kebutuhan perusahaan. •

Manajemen perlu mendefinisikan dengan jelas prosedur pengambilan keputusan dalam implementasi ERP. Hal ini agar pengambil keputusan mengetahui dengan jelas apa yang perlu dilakukan dalam membuat suatu keputusan. Prosedur ini sekaligus menjadi alat kontrol manajemen.

•

Manajemen perlu proaktif dalam memfasilitasi proses pengambilan keputusan ini. Dukungan dapat diberikan dalam bentuk memberikan saran dan masukan apabila ditemukan pengambilan keputusan yang sulit. Manajemen juga dapat memfasilitasi pertemuan antar pemilik proses bisnis apabila pengambilan suatu keputusan melibatkan pihak lain.

•

Manajemen perlu menentukan level otoritas yang tepat dari pengambil keputusan. Pertanyaan yang seringkali muncul dalam penentuan otoritas ini adalah sejauh mana suatu otoritas diberikan kepada pengambil keputusan. Untuk hal ini, manajemen dapat mempertimbangkan faktor-faktor seperti tingkat dampak dari suatu keputusan dan ruang lingkup pengambilan keputusan. Contoh dari tingkat dampak adalah otoritas dari pengambil keputusan diberikan sebatas tidak mempengaruhi biaya proyek. Sedangkan



107

untuk contoh ruang lingkup, otoritas pengambilan keputusan dapat dibatasi hanya pada proses bisnis yang dipimpin. Gambar 4.2 adalah flowchart dari pendefinisian tanggung jawab dan otoritas pengambilan keputusan.

Gambar 4.2 Flowchart Pendefinisian Tanggung Jawab dan Otoritas Pengambilan Keputusan 4.1.3

Peningkatan Komitmen Manajemen Level Atas Terhadap Proyek ERP Dari 16 belas kriteria di dalam Oliver Wight ABCD Checklist (Oliver

Wight ABCD Checklist adalah metode pengukuran manajemen yang efektif dalam



108

industri manufaktur dan jasa untuk membandingkan performa dan kapabilitas perusahaan yang mengimplemetasikan sistem ERP), komitmen manajemen menjadi salah satu kriteria penilaian. Hal ini mengindikasikan pentingnya faktor komitmen manajemen dalam keberhasilan implementasi ERP. Beberapa alasan mengapa keterlibatan manajemen level atas begitu diperlukan: •

Manajemen level atas yang paling tahu dengan pasti bagaimana bisnis harus dijalankan.

•

Proyek ERP memerlukan keterlibatan semua departemen Untuk itu perlu manajemen level atas yang dapat menggerakkan dan memfasilitasi

•

Manajemen level atas diperlukan dalam penyediaan sumber daya untuk keperluan proyek (Holland et al., 1999) Sekalipun komitmen manajemen sangat penting, seringkali ditemukan

permasalahan di dalam proyek ERP dikarenakan kurangnya komitmen dari manajemen. Penulis meneliti setidaknya ada tiga penyebab kurangnya komitmen dari manajemen dalam implementasi ERP yaitu: a. Manajemen tidak mengerti dengan baik bentuk dukungan manajemen seperti apa yang diperlukan di dalam proyek ERP Hal ini disebabkan manajemen tidak memahami sepenuhnya cara kerja sistem ERP. Masalah ini dapat diatasi dengan cara mengadakan first cut education yaitu pelatihan yang bertujuan untuk memberikan pengetahuan secara umum mengenai sistem ERP. Dari pelatihan ini, manajemen dapat mengidentifikasi peran apa yang perlu dilakukannya di dalam implementasi ERP. Setidaknya ada empat peran manajemen yang diperlukan dalam implementasi ERP yaitu: •

Pemberdaya tim Manajemen terlibat dalam pemilihan anggota tim proyek ERP yang berpengalaman serta memahami dengan baik visi dan misi organisasi. Anggota tim yang terpilih merupakan representasi dari pihak-pihak yang terlibat di dalam proyek.

•

Penetapan pengambil keputusan Apabila anggota tim tidak dapat membuat keputusan, implementasi akan terhambat bahkan gagal..



109

•

Resolusi isu Apabila ada suatu isu permasalahan yang tidak dapat diselesaikan oleh anggota tim, manajemen harus secara proaktif membantu di dalam pengambilan keputusan (Roberts and Barrar, 1992). Untuk dapat membantu dalam memberikan masukan, tentunya pihak manajemen harus diberikan informasi yang jelas mengenai permasalahan yang terjadi berikut opsi-opsi apa yang tersedia sebagai alternatif penyelesaian permasalah tersebut.

•

Manajemen perubahan Manajemen dapat dilibatkan ke dalam sebuah steering comitee yang membantu mengawasi proses implementasi. Manajemen perlu memastikan organisasi mengerti perubahan apa yang perlu dan kapan dari implementasi ERP.

b. Manajemen mengalami demotivasi karena tidak dapat melihat manfaat dari implementasi ERP Hal ini dapat terjadi karena proyek implementasi ERP memerlukan waktu yang lama untuk dapat dirasakan manfaatnya. Dalam kondisi ini, dapat terjadi manajemen dan pihak yang terlibat dalam implementasi ERP merasa frustasi. Apalagi biaya yang dikeluarkan selama implementasi berlangsung sangatlah besar. Untuk mengatasi permasalahan ini diperlukan: •

Manajemen proyek yang baik Manajer proyek harus memastikan implementasi ERP tidak menyimpang dari jadwal dan anggaran yang direncanakan. Semakin terlambatnya penyelesaian implementasi ERP, semakin manajemen merasa jenuh dan mengalami demotivasi.

•

Pengukuran performa implementasi ERP Manajer proyek perusahaan bersama dengan pihak konsultan menetapkan target-target performa yang diharapkan dari tiap fase implementasi ERP. Dengan cara ini, para pengguna sistem ERP dapat terus dimotivasi karena dapat merasakan manfaat sistem ERP walaupun belum lengkap. Cara ini



110

juga dapat dijadikan sebagai indikator evaluasi apakah implementasi ERP sudah berjalan ke arah yang diinginkan atau tidak. c. Manajemen tidak menjadikan proyek ERP sebagai prioritas nomor satu Rendahnya komitmen dari manajemen disebabkan karena manajemen tidak melihat proyek implementasi sistem ERP sebagai prioritas nomor satu. Karyawan yang terlibat di dalam proyek ERP memiliki kesibukan dengan pekerjaan utamanya. Keberhasilan atau kegagalan dari proyek ERP tidak berpengaruh langsung terhadap penilaian performa mereka. Hal ini membuat rasa memiliki terhadap proyek implementasi sistem ERP rendah. Untuk mengatasi hal ini, dapat dilakukan dengan membuat suatu skema insentif agar para karyawan yang termotivasi untuk terlibat di dalam proyek ERP. Skema insentif ini dapat berupa pemberian bonus, peningkatan jenjang karir, pemberian pelatihan yang dapat meningkatkan kompetensi, dsb. Gambar 4.3 adalah Flowchart pengukuran tingkat komitmen karyawan dan budaya organisasi.



111

Gambar 4.3 Flowchart Pengukuran Tingkat Komitmen Karyawan dan Budaya Organisasi 4.1.4

Manajemen Perubahan Proyek ERP Salah satu tantangan terberat di dalam implementasi ERP adalah

mengelola perubahan yang terjadi di dalam organisasi pasca-implementasi ERP. Banyak perusahaan yang gagal mendapatkan manfaat dari implementasi ERP dikarenakan lemahnya manajemen perubahan. Organisasi masih menggunakan



112

cara kerja yang lama sekalipun sistem yang baru sudah diimplementasikan. Investasi yang dikeluarkan untuk sistem ERP pun menjadi terbuang sia-sia. Manajemen perubahan dalam implementasi ERP dipengaruhi juga oleh jenis strategi implementasi yang dipilih. Secara umum ada dua strategi yang dikenal di dalam proses implementasi proyek ERP yaitu strategi big bang dan incremental. Apabila pada strategi big bang proses perubahan di dalam organisasi terjadi dengan cepat, dalam strategi incremental proses perubahan terjadi lebih lambat. Dalam strategi big bang, metode ini mengharuskan perusahaan untuk segera meninggalkan proses bisnis konvensional yang selama ini diterapkan. Keseluruhan rangkaian dan prosedur proses bisnis diganti secara drastis dan disesuaikan dengan sistem ERP yang diterapkan. Perusahaan mencoba mengimplementasikan sistem ERP secara utuh dan terintegrasi pada seluruh area kerja, sehingga perombakan dan penyesuaian harus dilakukan di seluruh lini atau bagian perusahaan. Keunggulan metode ini terlihat dari waktu pengerjaan proyek yang akan lebih sedikit serta perusahaan cenderung lebih fokus pada implementasi sistem ERP yang berjalan. Sebaliknya, investasi dana yang dikeluarkan serta pengorbanan karyawan untuk merubah standar dan prosedur kerja akan sangat besar. Dalam strategi incremental, perusahaan mengimplementasikan sistem ERP secara bertahap. Pada awalnya akan dilakukan uji coba pada salah satu bagian yang tidak akan berpengaruh signifikan terhadap kinerja perusahaan jika ternyata gagal diterapkan. Perusahaan cenderung menyewa pihak luar atau konsultan untuk mengembangkan bisnis proses yang ada, baru kemudian dilakukan penyesuaian pada bagian yang bersangkutan. Jika uji coba berhasil dilakukan, maka perusahaan akan langsung mengimplementasikan sistem ERP pada bagian-bagian lain layaknya efek domino. Metode ini sangat banyak diterapkan perusahaan-perusahaan di Indonesia. Selain faktor pengeluaran investasi yang cenderung aman, perusahaan dapat langsung melihat efek sistem ERP yang diimplementasikan secara nyata sebelum menerapkannya di seluruh perusahaan. Namun, perusahaan akan kesulitan



113

menyesuaikan proses bisnis yang ada berkaitan dengan transformasi data pada modul-modul berbeda. Metode inilah yang paling banyak menghasilkan ketidakharmonisan data, jika tidak diterapkan secara tepat. Selain menentukan jenis strategi implementasi yang akan dipilih, sangat penting pula bagi perusahaan untuk mengidentifikasi faktor-faktor apa saja yang dapat menjadi sumber resistensi terhadap perubahan. Dalam penelitian jurnal berjudul Case Study: Identifying Resistance in Managing Change diidentifikasi 7 buah faktor yang dapat menjadi sumber resistensi terhadap perubahan: a. Kepentingan pribadi (Self interest) Seseorang harus dapat melihat manfaat yang didapatkannya dari suatu perubahan sebelum ia menerima dan mendukung perubahan tersebut. b. Dampak psikologis (Psychological impact) Faktor ini berhubungan dengan persepsi terhadap rasa aman terhadap pekerjaan dan kondisi status sosial seseorang dalam organisasi. c. Kuatnya kebiasaan (Tyranny of custom) Faktor kebiasaan dapat menjadi penghambat terhadap suatu perubahan. d. Faktor redistribusi (Redistributive factor) Terjadinya

redistribusi

sumber

daya

yang

mengubah

hubungan

antarinstitusi menyebabkan terjadinya resistensi terhadap perubahan. e. Efek ketidakstabilan (destabilization effect) Perubahan selalu dapat menimbulkan terjadinya ketidakstabilan yang dapat menyebabkan munculnya resistensi terhadap perubahan. f. Budaya (Culture) Perubahan dapat menimbulkan konflik dengan budaya kerja tradisional yang sudah ada sejak lama. g. Efek politik (Political effect) Resistensi dapat terjadi karena perubahan dapat mengancam nilai-nilai yang diyakini saat ini. Dalam penyusunan strategi manajemen perubahan, ada 4 tahapan utama yang perlu dilakukan perusahaan yaitu:



114

•

Perusahaan perlu melakukan terlebih dahulu pengukuran performa manajemen perubahan yang ada. Dari tahapan ini, diukur tingkat kesiapan perusahaan untuk menerima perubahan. Untuk mengukur hal ini, dapat digunakan business maturity matrix. Matriks ini menggunakan 5 faktor kunci kesuksesan dalam manajemen perubahan. Kelima faktor tersebut antara lain: •

Komitmen Meliputi pemahaman perubahan sebagai bagian dari strategi bisnis perusahaan. Adanya rasa kepemilikan yang kuat pada manajemen level atas yang ditunjukkan melalui penyediaan sumber daya yang diperlukan oleh proyek agar dapat berjalan dengan efektif dan efisien.

•

Sosial dan budaya Berhubungan dengan “manusia” sebagai salah satu elemen dalam perubahan, meliputi perilaku, sikap dan persepsi terhadap suatu perubahan

•

Komunikasi Meliputi segala isu yang berhubungan dengan komunikasi internal dan eksternal. Hal ini meliputi metode dan isi dari pesan komunikasi yang disampaikan

•

Alat bantu dan metodologi Berhubungan dengan penggunaan metodologi dalam manajemen proyek, benchmarking, pengukuran performa dan proses. Termasuk juga adalah analisa kebutuhan pengetahuan yang diperlukan agar perubahan dapat berjalan dengan efektif dan penggunaan beragam pelatihan untuk mencapai hal ini.

•

Interaksi Berhubungan dengan metode yang berhubungan dengan interaksi dalam perusahaan seperti mengelola keseimbangan antara operasi normal dengan perubahan lain yang dapat terjadi dalam perusahaan.

Dalam matriks ini, terdapat 6 level penilaian yang menggambarkan tingkat kesiapan organisasi. untuk tiap kriteria •

Pemetaan hasil pengukuran performa



115

Setelah memperoleh pengukuran menggunakan business maturity matrix, dilakukan pemetaan hasil pengukuran performa kesiapan perusahaan menghadapi perubahan menggunakan radar chart. Dalam radar chart yang sama, dipetakan juga target performa yang diinginkan dicapai dalam menjalankan manajemen perubahan. •

Identifikasi area perbaikan yang diperlukan Dari radar chart ini kemudian dapat terlihat komponen apa yang masih kurang dan memerlukan perbaikan.

•

Penetapan prioritas tindakan manajemen perubahan Tahapan terakhir adalah penetapan prioritas tindakan manajemen perubahan yang akan dilakukan oleh perusahaan.



116

Gambar 4.4 Flowchart Pendefinisian Strategi Manajemen Perubahan Setelah mendapatkan strategi manajemen perubahan, manajemen perlu pula memperhatikan hal-hal yang sangat penting di dalam mengelola manajemen perubahan yaitu komunikasi yang efektif, pelatihan, dan sistem pemonitoran sertta pengevaluasian performa implementasi sistem ERP. a. Komunikasi Komunikasi adalah hal yang sangat kritikal dalam implementasi ERP (Falkowski et al.,1998). Kegagalan dalam manajemen perubahan dapat Universitas Indonesia


117

disebabkan oleh kurangnya komunikasi di antara pengguna sistem. Para karyawan perlu dikomunikasikan ruang lingkup, tujuan dan kegiatan dalam proses perubahan yang terjadi dalam implementasi ERP (Sumner, 1999). Dari hasil konsultasi dengan konsultan ERP dari Accenture, usaha komunikasi dapat dilakukan melalui pembentukan tim journey. Tim journey ini bertugas untuk mengkomunikasikan dan mensosialisasikan perkembangan dari implementasi ERP. Cara komunikasi yang dilakukan dapat dengan menggunakan media seperti buletin, newsletter, website sampai

dengan

mengadakan

roadshow

ke

daerah

yang

akan

mengimplementasikan ERP. Komunikasi ini penting untuk menghindari kebingungan yang dapat terjadi serta kemungkinan terjadinya resistensi dari pengguna. Arahan yang jelas dan kuat dari manajemen eksekutif akan membuat karyawan memahami bahwa proyek ERP dimaksudkan untuk meningkatkan performa perusahaan. Hal ini memerlukan tingkat keterlibatan dan komitmen yang tinggi dari seluruh karyawan, tidak hanya karyawan yang berhubungan dengan teknologi informasi saja. Proses perencanaan komunikasi bertujuan untuk menentukan kebutuhan anggota tim atas komunikasi dan informasi seperti penentuan siapa yang perlu mendapatkan informasi, kapan hal tersebut diperlukan, dan bagaimana informasi tersebut diberikan. Proses perencanaan komunikasi ini meliputi pembuatan: •

Struktur kategori informasi yang digunakan untuk menganalisa metode yang digunakan untuk berbagai jenis informasi.

•

Struktur distribusi informasi yang digunakan untuk mengatur aliran berbagai jenis informasi.

•

Deskripsi dari informasi yang akan didistribusikan yang meliputi bentuk, isi, tingkat detail informasi yang akan digunakan

•

Perencanaan komunikasi, yang menunjukkan tipe komunikasi yang akan dihasilkan



118

Informasi

Identifikasi Penerima Informasi Struktur kategori informasi

Deskripsi dari informasi

Struktur distribusi informasi

Perencanaan komunikasi

Gambar 4.5 Flowchart Manajemen Komunikasi Implementasi ERP Salah satu bentuk komunikasi yang paling diperlukan di dalam implementasi ERP adalah laporan perkembangan implementasi (progress report). Progress report ini bertujuan untuk mengumpulkan dan mengkategorikan informasi sehubungan dengan perkembangan implementasi. Dari progress report ini, akan diperoleh informasi yang terkait dengan tujuan proyek. Dalam sebuah progress report terdapat: •

Laporan situasi – mendeskripsikan situasi terbaru dari proyek

•

Laporan perkembangan – mendeskripsikan aktivitas yang sedang dikerjakan oleh anggota tim proyek

•

Peramalan – memprediksi situasi di masa depan dan perkembangan proyek Dalam sebuah progress report, akan diperoleh informasi terkait dengan aktivitas, biaya dan kualitas dari proyek yang berlangsung. Selain itu,



119

sebuah progress report juga dapat menjadi salah satu sumber informasi apakah suatu proyek sudah berjalan dengan baik atau belum. Elemen-elemen utama dalam sebuah progress report antara lain: •

Guidance committee – manajer proyek menginformasikan kepada pihak yang terkait dengan proyek situasi terkini dari proyek, keputusan yang perlu diambil, dan tingkat resolusi dari masalah. Informasi yang diberikan antara lain:

•

Gambaran aktivitas terdahulu

Project timetable

Subjek permasalahan yang memerlukan resolusi atau keputusan

Permintaan modifikasi

Diskusi terbuka

Aktivitas yang disetujui untuk langkah selanjutnya

Progress report – manajer proyek akan mendistribusikan kepada semua basic shareholders. Hal ini meliputi:

•

Memorandum

Situasi terkini dari perencanaan proyek

Perencanaan aktivitas

Progress report sebaiknya diberikan setelah inspeksi perkembangan oleh manajer proyek dan timnya Inspeksi internal – inspeksi proyek dari manajer proyek yang meliputi:

Perencanaan proyek

Kondisi keuangan

Bahaya internal

Aktivitas

b. Pelatihan Setiap perubahan dalam organisasi memerlukan pelatihan dan pendidikan untuk setiap orang yang ada di dalamnya. Pelatihan ini harus menjadi prioritas pertama kali saat proyek dimulai (Roberts and Barrar, 1992). Para pengguna sistem harus mengerti bagaimana sistem yang ada akan merubah proses bisnis dan cara kerja mereka. Perubahan cara kerja ini memerlukan kerja sama semua pihak karena adanya ketergantungan



120

informasi

antarunit bisnis satu sama lain. Pelatihan harus dijalankan

selama proses implementasi berlangsung. Accenture memiliki tim change enablement (CE) yang berperan untuk memberikan pelatihan menggunakan sistem ERP. Tim CE ini akan bertugas untuk menyusun kurikulum pelatihan. Selain memberikan materi pelatihan, tim CE juga menyiapkan sumber daya pendukung seperti contohnya OLQR yaitu Online Quick Reference. OLQR adalah website yang memberikan informasi menganai cara menjalankan transaksi dalam sistem ERP, Melalui OLQR ini, pengguna dapat masuk ke dalam website dan mendapatkan informasi mengenai bagaimana menjalankan transaksi dalam sistem ERP. Dengan adanya OLQR ini, para pengguna sistem dapat kapan saja mempelajari cara transaksi menggunakan sistem ERP. Dalam salah satu proyek Accenture di sebuah BUMN, diimplementasikan 3 buah modul yaitu modul Human Resources Management, Financial Management, dan Material Management. Untuk itu, pelatihan yang diberikan sesuai dengan modul ERP yang diimplementasikannya. Berikut ini adalah contoh materi pelatihan yang diberikan permodul: •

•

Modul Human Resources Management

Personnel Administration

Organizational Management

Time Management

Payroll

Travel Management

Benefits

Compensation Management

Recruitment

Personnel Cost Planning

Personnel Development

Training and Event Management

Incident Report Management

Modul Financial Management

General



121

•

Account Payable

Account Receivable

Corporate Finance Management

Cost Controlling

Cash Management

Planning and Budgeting

Modul Material Management

Material Planning

Procurement Management

Inventory Management

Warehouse Management

Logistic Invoice Verification

Pada gambar 4.6 diperlihatkan diagram alir proses pendefinisian kebutuhan pelatihan untuk pengguna sistem ERP.



DOKUMENTASI

PEMBUATAN MANAJEMEN PELATIHAN

122

Gambar 4.6 Flowchart Pendefinisian Pelatihan Implementasi ERP

c. Sistem pengukuran performa Selain manajemen perubahan yang baik, diperlukan juga sistem pengukuran komprehensif yang dapat memberikan umpan balik terhadap usaha implementasi, mengidentifikasi terjadinya gap, dan defisiensi dari



123

performa, dan memberikan rekomendasi kegiatan apa yang harus dilakukan (Al-Mashari and Zairi, 1999b). Sistem pengukuran performa ini diperlukan untuk memonitor performa proses dibandingkan dengan sejumlah indikator untuk memastikan implementasi ERP berjalan dengan baik dan dapat mencapai hasil bisnis yang diharapkan (Stevens, 1997). Salah satu caranya adalah dengan membagi proyek ke dalam fase-fase dengan tiap fase ini memiliki target yang harus dicapai. Ada dua kriteria yang dapat digunakan dalam sistem pengukuran performa ini. Pertama, berdasarkan kriteria manajemen proyek dimana indikator yang diukur adalah waktu penyelesaian, biaya dan kualitas. Kedua, adalah berdasarkan kriteria operasional dimana indikator yang diukur adalah seberapa jauh sistem yang ada dapat meningkatkan performa bisnis seperti pengurangan lead time, inventory stock, keterlambatan, dsb. Dengan adanya sistem pengukuran performa ini, manajemen dapat dengan jelas mengetahui manfaat dari implementasi ERP. Hal ini akan semakin meningkatkan komitmen manajemen terhadap implementasi ERP.

4.1.5

Analisa Kebutuhan Infrastruktur ERP Sebelum proses implementasi dimulai, organisasi bersama dengan

konsultan ERP perlu melakukan analisa pendahuluan untuk mengidentifikasi kebutuhan infrastruktur dalam implementasi ERP. Kebutuhan infrastruktur ini meliputi kebutuhan kapasitas database organisasi untuk menampung data transaksi, proses migrasi data lama ke sistem yang baru, penentuan level kustomisasi sistem ERP, dsb. Dari hasil analisa pendahuluan ini akan diperoleh arsitektur dari implementasi ERP. Analisa pendahuluan ini akan mencegah terjadinya rekonfigurasi dari arsitektur sistem ERP (Wee, 2000). Organisasi perlu memastikan benar-benar arsitektur yang disusun ini dapat dijalankan dan dapat mengakomodasi kebutuhan organisasi. Perubahan arsitektur di saat proses implementasi berlangsung akan menimbulkan tambahan biaya dan waktu proyek.



124

Perubahan ini juga dapat menimbulkan kebingungan dari para pengguna sistem, bahkan dapat pula menimbulkan demotivasi. Untuk dapat menghasilkan arsitektur sistem yang tepat, tim implementasi ERP perlu untuk memahami dengan komprehensif sistem dan proses bisnis yang ada di dalam organisasi serta kebutuhan infrastruktur untuk menunjang implementasi ERP. Seringkali, sistem ERP tidak dapat memberikan hasil yang optimal dikarenakan kegagalan pemahaman sistem organisasi dengan baik. Tim implementasi ERP perlu mendefinisikan user requirement dalam implementasi ERP. Volare Requirement Process Model dapat digunakan untuk memperoleh dapat digunakan untuk membantu organisasi dalam mendefinisikan baik functional requirement maupun nonfunctional requirement. Dari analisa user requirement ini, organisasi dapat menyusun arsitektur implementasi ERP yang dapat memenuhi kebutuhan organisasi. Permasalahan seperti waktu respon sistem yang lambat ataupun jaringan yang tidak dapat mengakomodasi volume lalu lintas data dapat dihindari.

4.1.6

Penyusunan Business Case Salah satu kritik yang sering muncul dari investasi sebuah proyek

teknologi informasi seperti ERP adalah ketidakjelasan manfaat yang didapatkan dari investasi ini. Hal ini dapat dipahami mengingat tidak melulu manfaat dari suatu investasi berupa sesuatu yang tangible saja yang biasanya diwakilkan dengan kriteria finansial. Dapat pula manfaat yang didapatkan bersifat intangible seperti operasi yang lebih ramping. Ingat pula keberadaan teknologi informasi dapat dianalogikan sebagai sebuah infrastruktur dimana keberadaannya penting sekalipun tidak berkontribusi langsung terhadap profit. Business case merupakan pernyataan hasil atau tujuan yang hendak dicapai dari impelementasi ERP dikaitkan dengan nilai bisnis. Nilai bisnis dalam sebuah proyek teknolgi informasi seperti ERP dapat berasal dari aplikasi yang dapat membuat suatu proses bisnis dapat dijalankan dengan lebih reliable, cepat, biaya lebih sedikit, pengontrolan inventori, peningkatan pendapatan, respon yang lebih baik terhadap pasar, dan pengambilan keputusan yang lebih baik. Business case ini diperlukan untuk menjustifikasi apakah proyek implementasi ERP layak



125

untuk dijalankan atau tidak. Business case sangat bermanfaat untuk memastikan proyek ERP terkait dengan hasil bisnis yang spesifik diinginkan (Cooke & Peterson, 1998). Pendefinisian business case ini menjadi penting karena mendorong organisasi untuk tidak hanya melihat sebuah implementasi ERP sebagai proyek teknologi informasi saja. Organisasi perlu melihat implementasi ERP sebagai alat solusi bisnis perusahaan. Dengan cara pandang seperti ini, manfaat dari sistem ERP akan dapat menjadi lebih optimal (Holland et al., 1999). Organisasi yang satu dengan yang lain dapat memiliki tujuan implementasi ERP yang berbeda. Namun demikian, tujuan-tujuan tersebut haruslah dapat menunjang strategi bisnis dari organisasi. Tim implementasi ERP harus mentranslasikan strategi bisnis organisasi ke dalam strategi implementasi ERP (Mudimigh et al., 2001). Walaupun penting untuk menghubungkan strategi perusahaan dengan strategi implementasi ERP, pada kenyataannya, masih sedikit perusahaan yang benar-benar menjalankannya. Hal ini tercermin dalam laporan IT Governance Global Status Report 2008 yang dikeluarkan oleh PriceWaterHouseCoopers dan IT Governance Institute. Dalam laporan ini terungkap hanya 23% responden survei yang sudah menghubungkan strategi organisasi dengan strategi implementasi ERP, 32% sedang menjalankan, 23% mempertimbangkan untuk menjalankan, dan 20% sama sekali tidak berminat untuk menjalankan. Hal yang perlu dilakukan dalam menghubungkan antara strategi perusahaan dengan strategi implementasi ERP antara lain: a. Identifikasi strategi dan sasaran organisasi Tim implementasi harus mengidentifikasi terlebih dahulu tujuan organisasi ini sebelum mendefinisikan tujuan implementasi proyek.Tujuan organisasi dapat bersifat tangible dan intangible. Contoh tujuan yang intangible adalah pertumbuhan organisasi, tingkat kepuasan pelanggan, dsb. Tujuan yang tangible antara lain pengurangan biaya operasional, peningkatan profit perusahaan, dsb. b. Definisikan tujuan implementasi proyek



126

Dalam mengidentifikasi tujuan proyek ini, organisasi akan melihat bagaimana peran dari implementasi proyek ERP dapat menunjang strategi dan sasaran organisasi. Untuk itu, manajemen perlu terlebih dahulu memahami manfaat yang dapat diperoleh dari sebuah implementasi ERP. Tujuan dari implementasi proyek ini dapat mencakup aspek teknikal, ekonomi, dan organisasi. Dari aspek teknikal, contohnya, perusahaan ingin meremajakan infrastruktur teknologi informasi yang dimilikinya. Dari aspek ekonomi, organisasi ingin mendapatkan penghematan yang diperoleh dari pengurangan biaya inventori, dsb. Dari aspek organisasi, perusahaan ingin melakukan restrukturisasi untuk lebih merampingkan perusahaan, dsb. c. Penentuan metriks implementasi proyek Manajemen juga perlu untuk menentukan metrik-metrik yang akan digunakan untuk mengukur apakah implementasi ERP berjalan dengan tepat waktu, dalam ruang lingkup yang sudah ditetapkan,dsb. Penyusunan business case ini bukanlah suatu hal yang mudah. Kesulitan dapat timbul dari sulitnya mengukur secara pasti nilai manfaat dari implementasi ERP. Ada manfaat-manfaat sistem ERP yang sifatnya intangible sehingga sulit untuk diukur secara finansial (Lozinsky, 1999; Shtub, 1999; Willcocks and Lacity, 1998). Menurut konsultan ERP dari Accenture, penyusunan business case dapat dilakukan dengan tahap sebagai berikut: a. Identifikasi dan proyeksikan baseline Baseline merupakan kondisi organisasi saat ini yang dijadikan acuan untuk mengukur besarnya kontribusi sebuah sistem ERP. Setiap manfaat yang diperoleh dari implementasi ERP akan dibandingkan terhadap baseline ini. Dari sini, dapat dilihat apakah ada perbaikan kinerja organisasi pasca-implementasi ERP. b. Estimasikan nilai manfaat Pada tahap ini, dibuat estimasi terhadap manfaat di masa depan yang dapat direalisasikan dari suatu implementasi. Manfaat ini diukur



127

berdasarkan selisih antara kondisi baseline dengan proyeksi manfaat yang akan diperoleh dari implementasi ERP. Dalam tahapan ini, organisasi juga perlu untuk mempertimbangkan berbagai kemungkinan hasil dari beberapa skenario implementasi seperti skenario ideal (best case), skenario terburuk (worst case) dan skenario yang diharapkan (expected case). c. Lengkapi business case Lengkapi business case dengan pre-requisite atau perubahanperubahan yang diperlukan agar program implementasinya lancar dan termasuk juga identifikasi resiko-resiko yang dapat terjadi dalam proyek ERP. d. Validasi business case dengan stakeholders Lakukan konfirmasi dengan stakeholders untuk menentukan apakah tujuan dalam business case yang ingin dicapai dan asumsi-asumsi yang digunakan dalam perhitungan benefit analysis sudah benar atau tidak. Tahapan ini penting untuk menghindari terjadinya ketidaksamaan persepsi terhadap tujuan yang hendak dicapai dari implementasi ERP.



128

Gambar 4.7 Flowchart Pendefinisian Business Case

4.1.7

Perbaikan Proses Bisnis Banyak perusahaan yang tidak secara terus menerus melakukan proses

perbaikan setelah proyek ERP dijalankan. Mereka hanya menjadikan sistem ERP sebagai alat untuk mendukung dan melakukan pekerjaan operasional sehari-hari. Inisiatif untuk melakukan perbaikan proses harus datang dari pemilik proses bisnis. Inisiatif ini kemudian akan melibatkan banyak pihak mulai dari pemilik proses bisnis sampai dengan tim implementasi. Dalam implementasi ERP, ada dua kondisi yang dapat terjadi terkait dengan proses bisnis perusahaan yaitu: a. Mengubah proses bisnis yang ada untuk menyesuaikan dengan aplikasi perangkat lunak ERP yang digunakan Dengan opsi pertama ini, lebih sedikit modifikasi dalam perangkat lunak ERP dapat mengurangi kemungkinan error yang terjadi dan mendapatkan keuntungan bila melakukan pengembangan lebih lanjut (upgrade) dari versi terbaru perangkat lunak (Fui Hoon Nah et al., 2001). Namun pada



129

opsi ini implikasinya perlu dilakukan perubahan terhadap cara kerja (Dewett and Jones, 2001; Koch et al., 1999) b. Mengubah aplikasi perangkat lunak ERP agar sesuai dengan proses bisnis perusahaan Opsi yang kedua ini akan membuat durasi implementasi ERP menjadi lebih lama, dan dapat mempengaruhi stabilitas dan keakuratan aplikasi perangkat lunak serta menyulitkan untuk dilakukan upgrade (Koch et al., 1999). Namun, pada opsi ini perubahan cara kerja organisasi dapat diminimalkan. Ada kecenderungan di dalam perusahaan yang mengaplikasikan ERP resisten untuk mengubah proses bisnisnya. Perusahaan ingin melakukan otomatisasi seluruh proses bisnis yang ada ke dalam sistem. Akibatnya diperlukan level kustomisasi yang tinggi dalam implementasi ERP. Selain itu, perusahaan juga menjadi tidak dapat memperoleh manfaat dari perbaikan proses bisnis yang mengikuti best practice. Tingkat kustomisasi yang terlampau tinggi dalam implementasi ERP memiliki resiko timbulnya masalah di masa depan. Implementasi ERP pun akan menjadi lebih mahal. Menurut konsultan ERP dari Accenture lebih baik organisasi sedapat mungkin menghindari tingkat kustomisasi yang terlalu tinggi di dalam implementasi ERP. Menurut mereka, lebih menguntungkan bagi perusahaan untuk mengikuti best practices. Keuntungan yang dapat diperoleh bila menggunakan implementasi yang mengikuti best practices antara lain: •

Biaya pengembangan sistem yang lebih murah

•

Mendapat dukungan penuh dari vendor pembuat aplikasi

•

Bila suatu saat sistem ERP akan ditingkatkan (upgrade), tidak akan terlalu bermasalah

•

Integrasi fungsi atau data biasanya lebih baik karena merupakan aplikasi standar yang sudah melalui pengetesan yang ketat

Dalam beberapa kasus, kustomisasi menjadi hal yang tak dapat dihindari. Hal ini terjadi apabila ada dari proses bisnis perusahaan yang sangat kritis



130

dan menjadi competitive advantage perusahaan. Ketiadaan proses ini dapat mengganggu kelancaran jalannya kesuluruhan proses bisnis perusahaan. Dalam menentukan kustomisasi ini, pengguna proses perlu untuk berkonsultasi terlebih dahulu dengan konsultan ERP. Dari hasil diskusi ini akan diketahui dengan jelas untuk rugi dari melakukan kustomisasi. Menurut konsultan ERP Accenture, Hal-hal yang dapat menjadi penghambat saat penentuan tingkat kustomisasi proses bisnis antara lain: •

Pengguna sistem tidak mengetahui dengan jelas apa yang diinginkan dari sistem ERP. Contohnya, pada awal implementasi, pengguna menginginkan banyak fungsi yang ternyata setelah diimplementasikan fungsi ini tidak berguna dan malahan menambah proses.

•

Tim implementasi kurang memahami detail fungsional dari sistem. Contohnya, tim implementasi melakukan kustomisasi untuk suatu fungsi yang sebenarnya ada fitur standar untuk fungsi tersebut di dalam sistem. Hal ini tentunya menimbulkan tambahan biaya.

Manajemen eksekutif harus memiliki komitmen dan memimpin proyek ERP untuk mengimplementasikan best practices dan tidak hanya otomatisasi proses saja. Buat perencanaan master untuk transformasi proses yang terkait dengan implementasi ERP. Pendekatan best practices untuk setiap implementasi sistem akan meminimalkan

proses

kustomisasi

dan

biaya

operasional

dalam

peningkatan sistem. Buat suatu panduan untuk melakukan kustomisasi. Tim standardisasi ERP menentukan tingkat keseimbangan terbaik antara kegunaan (usability) dan standardisasi. Panduan implementasi ini digunakan untuk peningkatan ERP yang mencapai harmonisasi antarunit bisnis.

4.1.8

Penentuan Prioritas Tindakan Penanganan Resiko Untuk menentukan prioritas tindakan penanganan resiko, digunakan

pendekatan

sederhana

dari

House

of

Quality

(HOQ)

dimana

akan

dikuantifikasikan hubungan antara tindakan penanganan resiko dengan resiko ke dalam angka. Hubungan yang kuat dikonversikan ke dalam nilai 9, hubungan



131

yang sedang dikonversikan ke dalam nilai 3, dan hubungan yang lemah dikonversikan ke dalam nilai 1. Dalam hal ini karakteristik teknis dari sebuah HOQ direpresentasikan oleh tindakan penanganan resiko sedangkan kebutuhan pelanggan direpresentasikan oleh resiko. Berdasarkan pendekatan ini, dapat disimpulkan bahwa jika terdapat hubungan yang kuat antara tindakan penanganan resiko dengan resiko maka akan diberi nilai 9, bila sedang diberi nilai 3 dan bila lemah diberi nilai 1. Sedangkan bobot setiap resiko diperoleh dari nilai tingkat resiko yang merupakan

perkalian

antara

probabilitas

dan

dampak

resiko.

Dengan

mengkuantifikasikan hubungan ini dalam angka maka dapat dihitung bobot kepentingan dari setiap tindkakan penanganan resiko yang dapat dijadikan sebagai acuan untuk penentuan prioritas. Pada tabel 4.1 diperlihatkan hubungan antara tindakan penanganan resiko dengan resikonya. Hubungan yang kuat direpresentasikan dengan bulatan hitam, hubungan yang sedang direpresentasikan dengan bulatan putih, dan hubungan yang lemah direpresentasikan dengan segitiga. Tabel 4.1 Hubungan Tindakan Penanganan Resiko dan Resiko Nilai ID S1 S2 S3 S4 S5 S6 Resiko A1-1

6.25

A1-2

28

A1-3

21

A1-4

12

A1-5

21

A2-1

20.25

A2-2

32

A2-3

32

A2-4

3.75

A2-5

28

A3-1

20

A3-2

24

A3-3

21



132

A3-4

15

A3-5

5

A4-1

15

A4-2

25

A4-3

12

A4-4

9

A4-5

14

A5-1

6.25

A5-2

7.5

A5-3

7.5

A5-4

12

A5-5

14

A5-6

15

A5-7

15

A6-1

6

A6-2

10

A6-3

10.5

A6-4

20

A6-5

10

A6-6

14

A6-7

21

A6-8

12

A6-9

7.5

A6-10

7.5

A7-1

5

A7-2

17.5 (sumber: penulis)

Pada tabel 4.2 diperlihatkan perhitungan bobot kepentingan antara tindakan penanganan resiko dengan resikonya.



133

Tabel 4.2 Perhitungan Bobot Kepentingan AntaraTindakan Penanganan Resiko dan Resiko Nilai ID S1 S2 S3 S4 S5 S6 Resiko A1-1

6.25

0

0

0

0

18.75

0

A1-2

28

0

252

0

0

0

0

A1-3

21

0

0

189

0

0

0

A1-4

12

0

0

0

0

108

0

A1-5

21

0

0

0

0

189

0

A2-1

20.25

0

0

0

0

0

182.25

A2-2

32

288

0

0

0

0

0

A2-3

32

288

0

0

0

0

0

A2-4

3.75

0

0

0

0

3.75

0

A2-5

28

252

0

0

0

0

0

A3-1

20

0

0

0

0

0

180

A3-2

24

0

0

0

216

0

0

A3-3

21

0

0

0

0

189

0

A3-4

15

0

0

0

0

0

45

A3-5

5

0

0

0

15

0

0

A4-1

15

0

0

45

0

0

0

A4-2

25

0

0

225

0

0

0

A4-3

12

0

0

36

0

0

0

A4-4

9

0

0

0

81

0

0

A4-5

14

0

42

0

42

0

0

A5-1

6.25

0

0

18.75

0

18.75

0

A5-2

7.5

0

0

0

22.5

0

0

A5-3

7.5

0

0

0

67.5

0

0

A5-4

12

0

0

0

0

36

0

A5-5

14

0

0

126

0

0

0

A5-6

15

0

0

15

0

0

0

A5-7

15

0

0

45

0

0

0

A6-1

6

0

0

0

0

6

0



134

A6-2

10

0

0

0

30

0

0

A6-3

10.5

0

0

0

31.5

0

0

A6-4

20

0

0

0

0

0

180

A6-5

10

0

0

0

0

30

0

A6-6

14

0

0

0

126

0

0

A6-7

21

0

0

189

0

0

0

A6-8

12

0

0

0

108

0

0

A6-9

7.5

0

0

0

22.5

0

0

A6-10

7.5

0

0

0

0

0

22.5

A7-1

5

0

0

0

5

0

0

A7-2

17.5

0

0

0

157.5

0

0

828

294

888.75

924.5

599.25

609.75

Total

(sumber: penulis) Dari hasil perhitungan bobot kepentingan pada table 4.2, diperoleh daftar prioritas tindakan penanganan resiko sebagai berikut: ID S4 S3 S1 S6

Tabel 4.3 Prioritas Tindakan Penanganan Resiko Strategi Studi kelayakan untuk memahami sistem secara lebih komprehensif Manajemen Perubahan Proyek ERP

Skor 924.5 888.75

Pendefinisian tanggung jawab dan otortitas pengambilan keputusan Perbaikan proses yang berkelanjutan untuk mencapai best practices

S5

Penyusunan business case yang baik

S2

Upaya peningkatan komitmen dari manajemen level atas

828 609.75 599.25 294

(sumber: penulis) Dari informasi ini, dapat terlihat perusahaan perlu untuk memprioritaskan tindakan penanganan resiko S4 yaitu melakukan studi kelayakan untuk memahami sistem dengan komprehensif. Dari HOQ sendiri dapat terlihat dimana tindakan penanganan ini berhubungan dengan banyak item resiko.



135

Setelah itu, manajemen perubahan juga perlu untuk mendapatkan perhatian dari perusahaan. Manajemen perubahan yang baik dapat mengurangi kemungkinan timbulya resiko-resiko dalam implementasi ERP. Tindakan penanganan selanjutanya adalah pendefinisian tanggung jawab dan otortitas pengambilan keputusan, perbaikan proses yang berkelanjutan untuk mencapai best practices ,

penyusunan business case yang baik, dan upaya

peningkatan komitmen dari manajemen level atas.

4.2

Pengawasan dan Pengontrolan Resiko Dalam proses pengawasan dan pengontrolan resiko dilakukan proses

pengidentifikasian resiko baru, dan perencanaan resiko yang meningkat, mengawasi resiko yang teridentifikasi, menganalisis ulang resiko yang ada, mengontrol pemacu kondisi untuk rencana cadangan, mengawasi sisa resiko dan meninjau ulang pelaksanaan pengawasan resiko untuk dinilai efektivitasnya. Semua proses ini perlu dilakukan secara terus menerus untuk mencapai manajemen resiko yang efektif dan efisien. Gambar 4.8 di bawah ini menunjukkan proses pengawasan dan pengontrolan risiko

Gambar 4.8 Proses Pengawasan dan Pengontrolan Resiko Tujuan dari proses pengawasan dan pengontrolan risiko antara lain untuk menentukan apakah: a. Asumsi proyek masih valid



136

b. Risiko yang dinilai telah berubah dari prioritas sebelumnya dengan analisis trend c. Kebijakan dan prosedur manajemen risiko yang dilakukan sudah tepat d. Cadangan kemungkinan untuk biaya dan waktu harus dimodifikasi

4.2.1

Identifikasi Resiko Baru Selain resiko yang telah dibahas dalam penelitian ini, dapat muncul resiko-

resiko baru yang tidak diperhitungkan sebelumnya. Kemunculan resiko-resiko baru ini dapat mempengaruhi keberhasilan dan kegagalan implementasi ERP. Untuk itu, perusahaan perlu untuk terus menerus mengidentifikasi resiko-resiko baru yang dapat mengganggu impelementasi proyek ERP. Identifikasi resiko baru ini penting untuk dilakukan sepanjang daur hidup proyek implementasi ERP. Dari resiko yang teridentifikasi ini, perusahaan perlu untuk mengidentifikasi sumber resiko, dampak resiko tersebut terhadap biaya, waktu dan ruang lingkup proyek serta tindakan penanganan apa yang diperlukan untuk menangani resiko tersebut. MULAI Identifikasi item resiko yang dapat terjadi

Identifikasi sumber resiko

Tentukan dampak resiko terhadap biaya, waktu dan ruang lingkup Identifikasi tindakan penanganan yang diperlukan SELESAI

Gambar 4.9 Proses Penanganan Resiko Baru



137

4.2.2

Penilaian Ulang Resiko Penilaian ulang resiko harus dijadwalkan secara teratur. Penilaian ini

dilakukan untuk melihat apakah nilai probabilitas dan dampak dari suatu item resiko masih relevan atai tidak. Untuk memperoleh data probabilitas dan dampak yang mendekati kondisi riil, diperlukan suatu sistem pendokumetasian yang baik.



5. KESIMPULAN

Tujuan dari penelitian ini adalah untuk memperoleh tindakan penanganan resiko yang sesuai untuk resiko yang diprioritaskan.Berdasarkan tujuan dan hasil yang ingin dicapai, kesimpulan yang dapat diambil dari setiap proses pada penelitian ini adalah sebagai berikut: a. Mengidentifikasi kesempatan dan tujuan Suatu variabel diidentifikasi sebagai resiko dalam implementasi ERP apabila variabel tersebut memenuhi satu atau beberapa kondisi di bawah ini: •

Menyebabkan tidak tercapainya objektif atau sasaran dari implementasi

ERP •

Menyebabkan keterlambatan penyelesaian proyek implementasi ERP

•

Menyebabkan terjadinya over bujet biaya implementasi ERP

b. Mengidentifikasi resiko Dari tahapan ini diperoleh 39 buah item resiko yang terbagi dalam 7 kategori yaitu: •

Kurangnya komitmen manajemen level atas terhadap proyek ERP

•


•


•

Tantangan adaptasi pengguna sistem

•


•


•


c. Menganalisa dan mengevaluasi resiko Dari tahapan ini diperoleh 14 item termasuk ke dalam kategori resiko tinggi, 21 item dengan kategori resiko menengah, dan 4 item termasuk ke dalam resiko rendah.

138 Universitas Indonesia


139

Item resiko dengan kategori resiko tinggi antara lain: ID

Tabel 5.1 Item Resiko Kategori Tinggi Item Resiko Manajer proses/pemilik tidak memiliki akuntabilitas yang

A2-2

terdefinisikan dengan baik,atau tidak memiliki otoritas untuk pengambilan keputusan Lemahnya pengambilan keputusan di antara pemilik

A2-3

proses dari unit bisnis yang berbeda, menghasilkan desain proses dan konfigurasi sistem yang menyimpang dari yang direncanakan

A1-2

A2-5

Kurangnya komitmen dari manajemen level atas dalam proyek ERP Pendefinisian akuntabilitas yang buruk dari integritas data master Tidak

A4-2

cukupnya

manajemen

perubahan

untuk

membimbing pengguna sistem menjalankan peran dan proses yang baru

A3-2

Tim implementasi gagal dalam memahami karakateristik sistem sehingga solusi yang dihasilkan tidak optimal Kurangnya Roadmap yang kuat yang berperan memandu

A1-3

proses

perubahan

dalam

organisasi

selama

proses

implementasi berjalan A1-5

Pemisahan peran IT dalam kepentingan bisnis Parameter performa dan target tidak terdefinisikan dengan

A3-3

baik; lemahnya hubungan antara desain proses dan business case

A6-7 A2-1

Rendahnya parameterisasi, standardisasi, dan dokumentasi Gagal dalam memberikan perbaikan proses secara berkelanjutan



140

A3-1

A6-4

A7-2

Gagal dalam mengimplementasikan best practices dan tidak memiliki rencana untuk mengimplementasikannya Sistem terlalu banyak dikustomisasi saat implementasi menyebabkan kesulitan dalam upgrade dan pemeliharaan Waktu respon sistem yang lambat,menghambat proses adopsi dan merusak produktivitas (sumber: penulis)

Item resiko dengan kategori resiko menengah antara lain: ID

Tabel 5.2 Item Resiko Kategori Menengah Item Resiko Pendefinisian

A1-1

perencanaan

yang

buruk

untuk

menghubungkan implementasi ERP dengan perubahan strategi perusahaan

A3-4


A4-1


A5-6


A5-7


A4-5 A5-5 A6-6

Rendahnya tingkat partisipasi pengguna sebelum dan sesudah fase implementasi Mengabaikan potensi komunikasi Rendahnya dukungan terhadap beberapa fungsionalitas bisnis yang diperlukan Business case yang tidak terdefinisikan dengan baik,tidak

A1-4

mendorong, atau kurang cukupnya komitmen tim eksekutif untuk menjalankannya

A4-3

Tidak cukupnya struktur dan sumber daya yang berperan



141

sebagai user-support A5-4

A6-8

A6-3

A6-2

A6-5

A4-4

A5-2

A5-3

Mengabaikan pentingnya pengukuran perkembangan dan performa di dalam proyek ERP Penentuan pemilihan server yang tidak didasarkan kepada analisa keperluan penyimpanan data Data warehouse tidak diimplementasikan;menghambat efektivitas penggunaan data yang tersedia Sistem yang terlalu rumit dan tidak user friendly menyebabkan pengguna bekerja di luar sistem Rendahnya

fleksibilitas

dalam

aplikasi

ERP

yang

digunakan Tidak cukupnya dukungan dan akuntabilitas terhadap pelatihan dan manajemen pengetahuan yang berlangsung Gagal dalam mengidentifikasi terjadinya gap talenta dalam perusahaan Organisasi fungsional tidak dipersiapkan dengan baik untuk menggunakan sistem baru dengan efektif

A6-9


A6-

Tidak berjalannya pemeliharaan pencegahan (preventive

10

maintenance) Gagal dalam mengimplementasikan perubahan dalam

A5-1

definisi peran dan desain organisasi yang diperlukan untuk mencapai business case yang diharapkan (sumber: penulis)

Item resiko dengan kategori resiko rendah antara lain: ID

Tabel 5.3 Item Resiko Kategori Rendah Item Resiko

A2-4

Model

pendanaan

yang

tidak

efektif

dan

gagal



142

menghasilkan peningkatan yang bernilai tinggi A3-5

Kekurangan dalam desain data master menghambat performa proses Peran dan sistem keamanan yang didefinisikan terlalu

A6-1

kaku;membatasi akses terhadap data dan penggunaan system

A7-1

Biaya operasional yang diestimasikan terlalu rendah melemahkan pencapaian business case (sumber: penulis)

d. Perencanaan tindakan penanganan resiko Dari tahapan ini diperoleh 6 buah strategi tindakan penanganan resiko. Berikut ini adalah daftar strategi penanganan resiko yang diurutkan berdasarkan tingkat kepentingannya ID S4 S3 S1 S6

Tabel 5.4 Strategi Penanganan Resiko Strategi Studi kelayakan untuk memahami sistem secara lebih komprehensif

Skor 924.5

Manajemen Perubahan Proyek ERP

888.75

Pendefinisian tanggung jawab dan otortitas pengambilan keputusan Perbaikan proses yang berkelanjutan untuk mencapai best practices

S5

Penyusunan business case yang baik

S2

Upaya peningkatan komitmen dari manajemen level atas

828 609.75 599.25 294

(sumber: penulis) e. Pengawasan dan pengontrolan resiko Dalam proses pengawasan dan pengontrolan resiko dilakukan proses pengidentifikasian resiko baru dan menganalisis ulang resiko yang ada.



143

DAFTAR REFERENSI

Jim Welch,Dmitry Kordysh , “Seven Keys to ERP Success”,Strategic Finance,89;3;ABI/INFORM Global pg.40, 2007 Piotr Soja,”Examining the Conditions of ERP Implementations: Lessons Learnt from Adopters”, Business Process Management Journal vol 14 No 1, 2008 IT Governance Global Status Report 2008. IT Risk Management PriceWaterHouseCoopers, 2008 Capaldo, et al, ,”A Methodological Approach to Assess the Feasibility of ERP Implementation Strategies”, Journal of Global Information Technology Management. 2007 Mark Q Smith dan Craig Mindrum. Changing The Way You Look at Risk, Accenture Outlook, 2003 Leon, Alexis Enterprise Resource Planning. McGraw Hill: New Delhi . 2000 O`Leary, Daniel E. Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk. United Kingdom : Cambridge University Press. 2000. Sheikh, Khalid Manufacturing Resource Planning (MRP II) with introduction to ERP, SCM and CRM. Mumbai : McGraw Hill. 2002. Wallace, Thomas F. dan Michael H. Kremzar ERP: Making It Happen, The Implementers’ Guide to Success with EnterpriseResource Planning. Kanada : John Wiley & Sons, Inc. 2001. Karyn E Trader. Case Study: Identifying Resistance in Managing Change, Journal of Organizational Change Management, Vol 15 No.2, 2002 Rebecca L Bechtel dan Janice K Squires, “Tools and Techniques to Facilitate Change”, Industrial and Commercial Training Vol 33, 2001



144

Lampiran 1 Kuesioner Tahap Pertama

Questionnaire 1 Based on your professional experience in ERP Project, please add the risk item that not included yet in below risk item list and give the rationale why the new Instruction risk item important to be included. Don't forget to write down the ID code for each risk item. ID


A1-1


A1-2


A1-3


A1-4

Business case poorly defined, not compeling, or lacking adequate executive team commitment Universitas Indonesia


145

A1-5 ID A2-1 A2-2 A2-3

Separating IT from Business Affairs- Technical mind set Weak Post-Implementation (A2) Failure to follow through and deliver continuous process improvement Process managers/owners are not appointed, their accountability is ill defined, or they lack real power to make decisions Weak decision making among process owners from different business units, resulting in diverging process designs and system configuration

A2-4


A2-5


ID A3-1 A3-2 A3-3

Lack of Focus on Business Process (A3) Failure to implement best practices during initial implementation, and no plan to get there Systems features poorly understood by implementation team, resulting in suboptimal solutions Performance metrics and targets not used or poorly defined; weak linkage between the process design and the business case

A3-4


A3-5


ID A4-1 A4-2 A4-3 A4-4 A4-5 ID

End-User Adoption Challenges (A4) Inadequate initial training Inadequate change management process for moving end users to new roles and new processes Inadequate user-support structure and resources (e.g.,no specialized "Competency Center" to carry on after initial super users migrate) Lack of accountability and support for ongoing knowledge management and training Lack of user participation in pre and post implementation phase Organzational Flaws or Inadequacies (A5)

A5-1

Failure to implement changes in role definitions and organization design required to achieve the expected business case

A5-2

Failure to address talent gaps (e.g.through recruiting and/or training)



146

A5-3

Functional organizations not properly sized to use the new system effectively

A5-4

Neglecting progress and performance measurements in ERP Project

A5-5

Underestimating potential of the communication

A5-6

Ineffective management of consultant

A5-7

Lack of ERP project management capabilities

ID A6-1 A6-2 A6-3 A6-4

IT Configuration Issues (A6) Roles and security defined too rigidly; limits ability to access data and use system Too many screens and complicated menu paths for simple transactions, resulting in users operating outside the system Data warehouse not implemented; limits effectively,timely use of available data System heavily customized during install,thus handicapping upgrades and maintenance;failure to keep pace with version upgrades

A6-5

Lack of flexibility in current application

A6-6

Lack of support to some required business functionalities

A6-7

Lack of paramaterisation, standardisation and documentation

A6-8

Server's selection not based on data storage requirement analysis

A6-9

Limited integration of applications and systems

A6-10

Preventive maintenance not performed

ID

Infrastructure Shorcomings (A7)

A7-1

Operating cost initially underestimated,thus weakening original business case

A7-2

System response time is slow, hampering adoption and eroding productivity



147



148

ID

Risk Items

Rationale < Reason why this risk item important to be included>



Lampiran 2 Kuesioner Tahap Kedua

Questionnaire 2 Instruction In this section,please give scoring for each risk item on the list for probability and impact score

add the <x> in the cell which you choose

From the example, it means that you see risk item "Ill defined plan for linking ERP enablement to strategic change" has low probability (rare) to happen and low impact if it happens Explanation about the Impact and Probability Scale could be seen in below tables

ID


A1-1


A1-2


A1-3


A1-4

Business case poorly defined, not compeling, or lacking adequate executive team commitment

A1-5

Separating IT from Business Affairs- Technical mind set

ID A2-1 A2-2 A2-3

Weak Post-Implementation (A2)

Impact (I) 2 4 8

16

1


1

Impact (I) 2 4 8

16

1


1

Impact (I) 2 4 8

16

1


Failure to follow through and deliver continuous process improvement Process managers/owners are not appointed, their accountability is ill defined, or they lack real power to make decisions Weak decision making among process owners from different business units, resulting in diverging process designs and system configuration

A2-4


A2-5


ID

1

Lack of Focus on Business Process (A3)

A3-1

Failure to implement best practices during initial implementation, and no plan to get there

A3-2

Systems features poorly understood by implementation team, resulting in suboptimal solutions

A3-3

Performance metrics and targets not used or poorly defined; weak linkage between the process design and the business case

A3-4


A3-5



150

ID A4-1 A4-2 A4-3

End-User Adoption Challenges (A4)

Lack of accountability and support for ongoing knowledge management and training Lack of user participation in pre and post implementation phase Organzational Flaws or Inadequacies (A5)

A5-1

Failure to implement changes in role definitions and organization design required to achieve the expected business case

A5-2

Failure to address talent gaps (e.g.through recruiting and/or training)

A5-3

Functional organizations not properly sized to use the new system effectively

A5-4

Neglecting progress and performance measurements in ERP Project

A5-5

Underestimating potential of the communication

A5-6

Ineffective management of consultant

A5-7

Lack of ERP project management capabilities IT Configuration Issues (A6)

A6-1

Roles and security defined too rigidly; limits ability to access data and use system

A6-2

Too many screens and complicated menu paths for simple transactions, resulting in users operating outside the system

A6-3

Data warehouse not implemented; limits effectively,timely use of available data

A6-4

System heavily customized during install,thus handicapping upgrades and maintenance;failure to keep pace with version upgrades

A6-5

Lack of flexibility in current application

A6-6

Lack of support to some required business functionalities

A6-7

Lack of paramaterisation, standardisation and documentation

A6-8

Server's selection not based on data storage requirement analysis

A6-9

Limited integration of applications and systems

A6-10

Preventive maintenance not performed

ID

16

1


1

Impact (I) 2 4 8

16

1


1

Impact (I) 2 4 8

16

1


1

Impact (I) 2 4 8

16

1


Inadequate change management process for moving end users to new roles and new processes Inadequate user-support structure and resources (e.g.,no specialized "Competency Center" to carry on after initial super users migrate)

A4-5

ID

Impact (I) 2 4 8

Inadequate initial training

A4-4

ID

1

Infrastructure Shorcomings (A7)

A7-1

Operating cost initially underestimated,thus weakening original business case

A7-2

System response time is slow, hampering adoption and eroding productivity



151

Lampiran 3 Kuesioner Tahap Ketiga



152

Lampiran 4 Hasil Kuesioner Tahap Kedua



153

Lampiran 5 Hasil Kuesioner Tahap Ketiga ID

Item Resiko

Rekomendasi Tim

eksekutif

dengan

Pendefinisian perencanaan yang buruk mengartikulasikan

A1-1

untuk menghubungkan implementasi ERP perubahan dengan perubahan strategi perusahaan

rencana

dan

bagaimana

jelas

menunjukkan

perubahan

ini

mendukung strategi perusahaan Manajemen level atas harus dengan aktif

menjadi

sponsor

dan

memantau proyek ERP dari dekat dan rutin. Hal ini akan menguatkan keterlibatan proyek

karyawan

ERP

dan

dalam membuat

karyawan melihat proyek ERP sebagai

alat

pendukung

dalam

perbaikan proses bisnis

A1-2


Menjalankan rencana komunikasi yang telah didefinisikan dengan baik serta journey management seperti melakukan road show dan sosialisasi kepada manajemen level atas untuk meningkatkan komitmen Manajemen memiliki

level

atas

komitmen

harus terhadap

inisiatif yang telah dibuat dan memastikan organisasi mengerti perubahan apa yang perlu dan kapan

A1-3

Kurangnya Roadmap yang kuat yang Perlunya dibuat sebuah roadmap



154

berperan

memandu

dalam

organisasi

proses selama

perubahan yang

dapat

memastikan

proses implementasi ERP berjalan dengan

implementasi berjalan

tepat Business case yang kuat harus didefinisikan dengan jelas di awal proyek. Sepanjang berlangsungnya implementasi proyek ERP, arah kemajuan

dari

proyek

dapat

divalidasi dengan business case untuk

dilakukan

Business case yang tidak terdefinisikan penyesuaian.Business case dapat A1-4

dengan baik,tidak mendorong, atau kurang disesuaikan dengan k cukupnya komitmen tim eksekutif untuk Perusahaan melakukan benchmark menjalankannya

untuk

menetapkan

target

yang

agresif tapi dapat dicapai dengan multilevel

dashboard

menghubungkan

yang

hasil

bisnis

dengan paramater operasional yang detail.

Untuk

menjustifikasi

peluncuran proyek, sebuah business case harus Arahan yang jelas dan kuat dari manajemen membuat

eksekutif karyawan

akan

memahami

bahwa proyek ERP dimaksudkan

A1-5


untuk

meningkatkan

performa

perusahaan. Hal ini memerlukan tingkat keterlibatan dan komitmen yang tinggi dari seluruh karyawan, tidak hanya kar Manajemen business

cae

eksekutif yajg

membuat solid



dan

155

terdefinisikan

dengan

baik.

Business case sangat bermanfaat untuk memastikan proyek ERP terkait dengan hasil bisnis yang spesifik(Cooke & Peterson, 1998) Banyak perusahaan yang tidak secara terus menerus melakukan proses perbaikan setelah proyek ERP dijalankan. Mereka hanya menjadikan sistem ERP sebagai alat

untuk

mendukung

dan

melakukan pekerjaan operasioanal

A2-1

Gagal dalam memberikan perbaikan proses sehari-hari.Inisiatif secara berkelanjutan

untuk

melakukan perbaika Transisi dari unit bisnis yang begitu terdesentralisasi ke model dengan banyak proses yang terstandardisasi memerlukan ongoing governance untuk menjalankan baik inovasi operasional maupun harmonisasi proses Pengambilan keputusan adalah hal yang

kritis

sesudah Manajer proses/pemilik tidak memiliki

A2-2

akuntabilitas yang terdefinisikan dengan baik,atau tidak memiliki otoritas untuk pengambilan keputusan

di

sepanjang

proses

dan

implementasi

proyek ERP. Seringkali kurangnya keputusan menjadikan penghambat bagi pemilik proses bisnis untuk mendapatkan manfaat dari ERP. Pemilik

proses

bisnis

harus

ditentuka Pemilik proses harus akuntabilitas

memiliki

dan



otoritas

156

mendorong terciptanya hasil Oleh

karena

manajemen

fungsional Lemahnya

pengambilan

keputusan

harus

di keputusan

yang

lintas

membuat sulit

yang

antara pemilik proses dari unit bisnis yang mempengaruhi berbagai unit bisnis

A2-3

berbeda, menghasilkan desain proses dan dan

fungsi,

konfigurasi sistem yang menyimpang dari harus yang direncanakan

manajemen

secara

jelas

senior terlihat

mendorong dan mendukung cara kerja yang baru. Buat keputusan yang cepat dan memberda Kebutuhan

akan

ongoing

Model pendanaan yang tidak efektif dan governance di lingkungan pasca

A2-4

gagal menghasilkan peningkatan yang impelementasi, perusahaan perlu bernilai tinggi

untuk memandu perubahan untuk perbaikan yang berkelanjutan Beberapa master data yang dibagi ke beberapa area proses bisnis adalah sifat dari ERP. Walaupun demikian, tanpa penetapan yang jelas sebelum dimulainya proyek, akuntabilitas untuk pemeliharaan dan integritas dari data master akan

A2-5

Pendefinisian akuntabilitas yang buruk hilang. Oleh karena itu, dari integritas data master

Lakukan

standardisasi

memfokuskan kepada

untuk

pekerjaan

proyek

pengembangan

proses

bisnis dan modul perangkat lunak yang tepat yang bersama-sama memfasilitasi proses rekonsiliasi inkonsistensi data dalam seluruh system



157

Ada

kecenderungan

di

dalam

perusahaan yang mengaplikasikan ERP untuk melakukan otomatisasi proses bisnis yang ada ke dalam Gagal dalam mengimplementasikan best

A3-1

practices dan tidak memiliki rencana untuk mengimplementasikannya

sistem. Manajemen eksekutif harus memiliki komitmen dan memimpin proyek

ERP

untuk

mengimplementasikan

best

practices dan tidak hanya Buat perencanaan master untuk transformasi proses yang terkait dengan implementasi ERP Implementasi

proyek

ERP

memerlukan

keterlibatan

yang

tinggi dari pemilik proses bisnis atau pengguna pada saat proyek Tim implementasi gagal dalam memahami berlangsung untuk menjadi bagian

A3-2

karakateristik sistem sehingga solusi yang dari anggota proyek dan sumber dihasilkan tidak optimal

informasi mengenai proses bisnis yang telah ada Lakukan studi kelayakan untuk memahami sistem yang ada secara komprehensif Definisikan sebelum

Parameter performa dan target tidak

A3-3

terdefinisikan hubungan

dengan

antara

business case

baik;

desain

lemahnya

proses

dan

parameter

proyek

performa

dimulai

dan

kaitkan dengan business case dan strategi Buat

rencana

menerus

yang

perbaikan

terus-

mendefinisikan

parameter performa yang spesifik dan target untuk proses-proses yang utama, dengan fase dan milestone



158

yang tepat untuk proses perbaikan yang berjalan terhadap sasaran jangka panjang Gunakan

A3-4


pendekatan

secara

bertahap

untuk

mengimplementasikan

perubahan

yang kompleks di dalam business process reengineering Tetapkan akuntabilitas dan sumber

A3-5


daya

untuk

memelihara

data

master. Pemilik data, buka staf klerikal,

yang harus memelihara

data master Pelatihan yang didefiniskan dengan baik; tentukan pendekatan pelatihan yang

paling

kebutuhan;

tepat seperti

berdasarkan pelatihan

berdasarkan peran, audience-based

A4-1


training (Pada umumnya, pelatihan yang

dikustomisasi

lebih

baik

daripada yang standar, deng Gunakan program pelatihan multi dimensi

yang

memperlengkapi

pengguna sebelum tanggal go-live Tidak cukupnya manajemen perubahan

A4-2

untuk

membimbing

pengguna

sistem

menjalankan peran dan proses yang baru

Perbaiki metode komunikasi dan tingkatkan kualitas serta kuantitas dari proses sosialisasi peran yang baru kepada pengguna akhirs Kembangkan rencana manajemen perubahan yang sederhana dan dapat diaplikasikan untuk para pengguna



159

Gunakan teknik dan alat dalam manajemen

perubahan

untuk

menfasilitasi tambahan dari sistem, proses dan struktur yang baru diimplementasikan,ke aplikasi kerja dan

berurusan

dengan

kemungkinan terjadinya resistensi. Penyediaan

sumber

daya

pendukung kpada pengguna yang konsisten seperti membuat help

A4-3


desk khusus yang menghasilkan local super user, berikan pelatihan baik untuk pengguna baru maupun yang sudah berpengalaman dengan menyediakan pealtih yang memiliki kualifi Buat alat manajemen pengetahuan yang

akan

dipelihara

diperbaharui secara

rutin

dan untuk

menyediakan perbaikan proses dan perubahan dalam operasi bisnis sehari-hari Tidak

A4-4

cukupnya

akuntabilitas

terhadap

dukungan pelatihan

dan Lakukan

perencanaan

untuk

dan pemeliharaan aset ERP. Dukungan

manajemen pengetahuan yang berlangsung

yang berjalan meliputi tidak hanya peningkatan

sistem

dan

fungsionalitas dari perangkat lunak saja, tapi, yang paling penting adalah

perbaikan

bisnis.Dukungan

ini

proses harus

ditetapkan ke dalam s

A4-5

Rendahnya tingkat partisipasi pengguna Komunikasikan cara kerja yang



160

sebelum dan sesudah fase implementasi

baru di dalam sistem ERP pada saat fase pra dan pasca implementasi ERP Dikungan dan komitmen yang kuat dari manajemen eksekutif sangat

Gagal

A5-1

dalam

mengimplementasikan

perubahan dalam definisi peran dan desain organisasi

yang

diperlukan

untuk

mencapai business case yang diharapkan

diperlukan

untuk

mengimplementasikan

perubahan

peran dan organisasi Tingkatkan

peran

Implementasi

tradisional.

yang

sukses

memerlukan perbaikan dalam peran tradisional Tingkatkan

A5-2

kapabilitas

dan

Gagal dalam mengidentifikasi terjadinya kemampuan analisa pengguna dan gap talenta dalam perusahaan

melakukan perekrutan untuk peran yang terspesialisasi

Organisasi fungsional tidak dipersiapkan Lakukan

A5-3

penyesuaian

terhadap

dengan baik untuk menggunakan sistem deskripsi pekerjaan dan tingkat baru dengan efektif

upah Miliki sistem manajemen yang komprehensif yang menyediakan mekanisme

Mengabaikan

A5-4

pentingnya

um[an

balik

untuk

pengukuran melacak setiap usaha implementasi,

perkembangan dan performa di dalam mengidentifikasi gap yang ada dan proyek ERP

defisiensi

dalam

performa

dan

memberikan rekomendasi tindakan yang

perlu

dilakukan

dalam

berbeagai Buat rencana komunikasi yang

A5-5


terdefinisikan dengan baik Bangun strategi komunikasi formal dengan

menggunakan



berbagai

161

saluran informasi seperti focus group,

newsletter,

email,

dan

website untuk membantu karyawan mendapatkan mengenai

informasi

terbaru

perkembagan

proyek

ERP dan mendapatkan jawaban atas pertanya Bangun pendekatan yang jelas untuk memastikan proses transfer pengetahuan dan keahlian dari

A5-6

Tidak

efektifnya

peran

manajemen konsultan ke perusahaan berjalan

konsultasi

dengan lancar. Peran konsultan ada dua yaitu: (1) Memfasilitasi proses desain

awal,

(2)

memberikan

pelatihan untuk aspek teknis, k Manajer proyek dan anggota tim dari perusahaan harus kuat dan memiliki menjalankan

kapabilitas proyek.

untuk Penetapan

orang-otrang yang tepat, dengan beberapa

kriteria

seperti

:

memahami TI, memiliki sikap yang

A5-7

Rendahnya kapabilitas dalam manajemen baik, dan menguasai pengetahuan yang baik

proyek ERP

Tetapkan

manajemen

proyek

perusahaan untuk mendefinisikan berbagai peran dan tanggung jawab untuk pihak internal dan eksternal dalam proses implementasi dan menetapkan

bentuk

koordinasi

yang tepat terhadap keduanya.

A6-1

Peran

dan

sistem

keamanan

yang Pastikan pengguna memiliki akses



162

didefinisikan terlalu kaku;membatasi akses terhadap data yang diperlukannya terhadap data dan penggunaan sistem Hal ini bisa dihindari dengan melibatkan

secara

intensif

pengguna/ pemilik proses bisnis Sistem yang terlalu rumit dan tidak user dalam implementasi proyek ERP,

A6-2

friendly menyebabkan pengguna bekerja di dengan luar sistem

demikian

solusi

yang

dihasilkan akan dapat memenuhi kebutuhan

pengguna/

pemilik

proses bisnis, dan pada akhirnya mereka nyaman u Implementasikan Data warehouse, setelah implementasi sistem untuk menjalankan transaksi operasional sehari-hari. Bagaimanapun juga, direkomendasikan mendefinisikan

untuk keperluan

pelaporan diData Warehouse pada

Data A6-3

warehouse

tidak

diimplementasikan;menghambat efektivitas penggunaan data yang tersedia

awal

sebelum

sistem

untuk

transaksi dimple Fasilitasi data mining. Pengguna memiliki alat untuk menggunakan data secara offline sehingga tidak membatasi

kreativitas

memerlukan

pemrograman

khusus

untuk

atau TI

membuat

laporan.Data mining paling baik dilakukan dengan aplikasi data warehouse Sistem terlalu banyak dikustomisasi saat

A6-4

implementasi

menyebabkan

dalam upgrade dan pemeliharaan

kesulitan

Ikuti panduan untuk melakukan implementasi sestandar mungkin, dan ikuti best practice daripada Universitas Indonesia


163

mencoba untuk mengotomatisasi proses bisnis yang ada Pendekatan Best practice untuk setiap implementasi sistem akan meminimalkam proses kustomisasi dan

biaya

operasional

dalam

peningkatan system Buat

suatu

panduan

melakukan

kustomisasi.

standardisasi tingkat antara

untuk

ERP

Tim

menentukan

keseimbangan

terbaik

kegunaan (usability) dan

standardisasi.

Panduan

implementasi ini digunakan untuk peningkatan ERP yang mencapai harmonisasi antarunit bisn

A6-5

Rendahnya fleksibilitas dalam aplikasi ERP yang digunakan

Gunakan

software

berbasis

open

ERP

source

memungkinkan pengembangan

yang untuk

dilakukan aplikasi

dan

kustomisasi

A6-6


Persiapkan dan bangun organisasi pendukung pada saat implementasi proyek ERP Bangun prosedur dan metodologi

A6-7

Rendahnya parameterisasi, standardisasi, untuk membuat, memelihara dan dan dokumentasi

memperbaharui

manajemen

dokumentasi Penentuan pemilihan server yang tidak Penilaian

A6-8

didasarkan

kepada

penyimpanan data

analisa

keperluan kebutuhan

infrastruktur diperlukan

di

permulaan proyek



dan awal

164

Lakukan analisa kebutuhan data storage sebelum pemilihan server Manajer integrasi harus memiliki

A6-9

Terbatasnya integrasi aplikasi dan sistem

performa

yang

baik

dalam

impementasi proyek ERP Lakukan pemeriksaan manajemen

A6-10

Tidak

berjalannya

pemeliharaan pemeliharaan untuk memastikan

pencegahan (preventive maintenance)

performa yang optimal dari sistem ERP Perencanaan

Biaya operasional yang diestimasikan

A7-1

terlalu rendah melemahkan pencapaian

business case

kuat

infrastruktur

meliputi

kapasitas

yang

perencanaan

jaringan

untuk

mengantisipasi vlume lalu lintas data dan seberapa sering data diperbarui dalam server computer

Waktu

A7-2

respon

sistem

yang

lambat,menghambat proses adopsi dan merusak produktivitas

Definisikan kebutuhan infrastruktur di

awal

business

dan

kaitkan

dengan

case

dari

proyek

implementasi ERP



165



ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING SKRIPSI

Recommend Documents