ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE ...lib.ui.ac.id/file?file=digital/2016-9/20249964-S50375...ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING SKRIPSI Diajukan

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 : Ricky Tjok NPM : 04 04 07 059X Tanda Tangan :

Tanggal : 18 Juli 2008


iii

HALAMAN PENGESAHAN

Skripsi ini diajukan oleh : Nama : Ricky Tjok NPM : 040407059X Program Studi : Teknik Industri Judul Skripsi : 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 (Non-exclusiveRoyalty-Free Right) atas karya ilmiah saya yang berjudul :


beserta perangkat yang ada (bila diperlukan). Dengan Hak Bebas Royalti Non-Ekslusif ini Universitas Indonesia berhak menyimpan, mengalihmedia/format-kan, 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 teman-

teman 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


Universitas Indonesia

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



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



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 Pengawasan dan Pengontrolan Resiko ................................................. 135

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

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

5. 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


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


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


Gambar 2.15 Proses pengawasan dan pengontrolan risiko (Sumber: Project


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 Universitas Indonesia

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



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.



4

1.2 Diagram Keterkaitan Masalah

Gambar 1.1 Diagram Keterkaitan Masalah

1.3 Perumusan Masalah Perusahaan yang hendak menerapkan sistem ERP perlu mengetahui item-

item 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



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



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

Diagram Alir Metodologi Penelitian

Kes

impu

lan

Pen

gola

han

Dat

a da

n A

nalis

isPe

ngum

pula

n D

ata

Pem

aham

an

Das

ar T

eori

Pem

ilihan

Top

ik

Pen

eliti

an

Data kuesioner 1,2,3

Literatur penunjang: jurnal, artikel, skripsi,

tesis, disertasi

Menentukan topik penelitian

Mengidentifikasi resiko

Menentukan dan mempelajari dasar teori yang dibutuhkan

Mengidentifikasi kesempatan dan tujuan

Mulai

Menganalisa dan mengevaluasi resiko

Dasar teori ERP dan Manajemen

Resiko

Mengumpulkan data

Selesai

Kesimpulan

Membuat perencanaan tindakan penanganan resiko

Membuat Pengawasan dan Pengontrolan Resiko

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 analisa-

analisa 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.



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 elemen-

elemennya 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 perubahan-

perubahan 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.



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.



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

lain :9

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.



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

Mengurangi cycle time

Meningkatkan kemampuan proses bisnis

Mengurangi persediaan

Memenuhi pemesanan barang dengan tepat

2. Sistem ERP mendukung petumbuhan bisnis, yakni dengan

Pembuatan lini produksi baru

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

Fragmentasi data dan proses

Perubahan yang tidak fleksibel

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. 11 Daniel E. O`Leary. Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, hal.7-9.



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.



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 non-

moneter.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.



21

dalam pengimplementasian sistem ERP, perusahaan juga harus memiliki orang-

orang 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 elemen-

elemen 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



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



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



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 Project Management Institute, Op.Cit., p. 237. 16 Roger W Stewart dan Joyce Fortune, Op.Cit., p.279. 17 D K Kohlmeyer dan J K Visse , Po.Cit., p.79.



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 The Association for Project Management, Ibid., p.5. 20 Project Management Institute, Op.Cit., p.237.



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.



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 Roger W Stewart dan Joyce Fortune, Op.Cit, p.279. 22 Project Management Institute, Op.Cit., p. 246.



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.



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 Office of Project Management Process Improvement, Op.Cot., p.23. 27 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.



51

kedetailan tertentu33. Simulasi khususnya dilakukan dengan menggunakan teknik

Monte Carlo. Dalam simulasi ini model proyek akan dihitung secara berulang-

ulang 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.



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 S C Ward, Op.Cit., hal.331. 36 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 Ibid., p.261. 38 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.



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

mengidentifikasi, menganalisa, mengevaluasi, memonitor dan memeriksa resiko.

Men

gont

rol d

an m

enga

was

i

Men

gkom

unik

asik

an d

an m

engk

onsu

ltasi

kan

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 benar-

benar relevan bagi perusahaan.

Dalam tahapan mengidentifikasi kesempatan dan tujuan ini terdapat sub-

sub 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

<Risk ID, e.g A5> <Risk item that not included yet in the above list that you think important to be included> < Reason why this risk item important to be included>

ID Risk Items Rationale

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 ID Item Resiko

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)



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

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

1 2 4 8 16 1 2 3 4 5

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

1 2 4 8 16 1 2 3 4 5

A2-1 Failure to follow through and deliver continuous process improvement

A2-2 Process managers/owners are not appointed, their accountability is ill defined, or they lack real power to make decisions

A2-3 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

1 2 4 8 16 1 2 3 4 5

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

Probability (P)

Probability (P)

ID

ID

Questionnaire 2

Weak Post-Implementation (A2) Impact (I)

Inadequate Executive Alignment (A1) Impact (I)

ID Lack of Focus on Business Process (A3) Impact (I) Probability (P)

Gambar 3.3 Kuesioner Tahap Kedua



81

Tabel 3.2 Tabel Dampak Resiko Dampak (D)

Sangat

rendah

Rendah Sedang Tinggi Sangat

Tinggi

Tujuan

1 2 4 8 16

Waktu Waktu

penyelesaian

proyek tidak

terpengaruh

signifikan

Keterlambatan

penyelesaian

proyek < 3

bulan

Keterlambatan

penyelesaian

proyek = 3

bulan

Keterlambatan

penyelesaian

proyek > 3

bulan

Keterlambatan

penyelesaian

proyek > 1

tahun

Biaya Peningkatan

biaya

proyek tidak

signifikan

Biaya

meningkat <

5%

Biaya

meningkat 5-

10%

Biaya

meningkat 10-

20%

Biaya

meningkat

>20%

(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)



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 ID

Skor

Dampak

Skor

Probabilitas

Skor

Resiko

Kategori Resiko

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-2 10 2.5 25 Tinggi


A4-4 3 3 9 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





A6-1 3 2 6 Rendah


A6-3 3 3.5 10.5 Menengah

A6-4 8 2.5 20 Tinggi



84



A6-7 6 3.5 21 Tinggi


A6-9 3 2.5 7.5 Menengah

A6-

10

3 2.5 7.5 Menengah

A7-1 2.5 2 5 Rendah

A7-2 5 3.5 17.5 Tinggi

(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



85

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

A2 Lemahnya proses implementasi 29%

A1 Kurangnya komitmen manajemen level

atas

21%

A3 Lemahnya fokus pada proses bisnis 21%

A6 Isu konfigurasi teknologi informasi 14%

A4 Tantangan adaptasi pengguna system 7%

A7 Permasalahan infrastruktur 7%

A5 Lemahnya dukungan organisasi 0%

(sumber: penulis)

Berikut ini adalah item-item resiko yang termasuk ke dalam kategori

tinggi:

Tabel 3.7 Item Kategori Resiko Tinggi ID 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 Kurangnya komitmen dari manajemen level atas dalam

proyek ERP

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


A3-3 Parameter performa dan target tidak terdefinisikan dengan

baik; lemahnya hubungan antara desain proses dan

business case


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 data-

data 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.

Tabel 3.8 Proporsi Item Kategori Resiko Menengah ID Item Resiko Menengah





atas

10%



91




(sumber: penulis)


menengah:

Tabel 3.9 Item Kategori Resiko Menengah ID Item Resiko

A1-1 Pendefinisian perencanaan yang buruk untuk

menghubungkan implementasi ERP dengan perubahan

strategi perusahaan

A3-4 Proses statis dan tidak dapat beradaptasi dengan perubahan

kondisi bisnis




A4-5 Rendahnya tingkat partisipasi pengguna sebelum dan

sesudah fase implementasi


A6-6 Rendahnya dukungan terhadap beberapa fungsionalitas

bisnis yang diperlukan

A1-4 Business case yang tidak terdefinisikan dengan baik,tidak

mendorong, atau kurang cukupnya komitmen tim eksekutif

untuk menjalankannya

A4-3 Tidak cukupnya struktur dan sumber daya yang berperan

sebagai user-support

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-

10

Tidak berjalannya pemeliharaan pencegahan (preventive

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 user-

support (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






atas

0%



(sumber: penulis)


rendah:

Tabel 3.11 Item Kategori Resiko Rendah ID Item Resiko

A2-4 Model pendanaan yang tidak efektif dan gagal

menghasilkan peningkatan yang bernilai tinggi



99

A3-5 Kekurangan dalam desain data master menghambat

performa proses

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 3 2 0A2 4 0 1A3 3 1 1A4 1 4 0A5 0 7 0A6 2 7 1A7 1 0 1

(sumber: penulis)



101

3

43

10

2

1

0%

20%

40%

60%

80%

100%

A1 A2 A3 A4 A5 A6 A7

Menengah

Tinggi

Rendah

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 (A2-

5)



104

b. Upaya peningkatan komitmen dari manajemen level atas terhadap proyek

ERP


• Kurangnya komitmen manajemen level atas dalam proyek ERP (A1-2)

c. Manajemen perubahan proyek ERP


• 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 (A1-

3)

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

d. Studi kelayakan untuk memahami sistem secara lebih komprehensif


• 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


• 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


• Gagal dalam memberikan perbaikan proses secara berkelanjutan (A2-

1)



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



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

Struktur distribusi informasi

Deskripsi dari 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.



122

PEM

BU

ATA

N M

AN

AJE

MEN

PEL

ATI

HA

ND

OK

UM

ENTA

SI

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 perubahan-

perubahan 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

ID Nilai

Resiko S1 S2 S3 S4 S5 S6

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

ID Nilai

Resiko S1 S2 S3 S4 S5 S6

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

Total 828 294 888.75 924.5 599.25 609.75

(sumber: penulis)

Dari hasil perhitungan bobot kepentingan pada table 4.2, diperoleh daftar

prioritas tindakan penanganan resiko sebagai berikut:

Tabel 4.3 Prioritas Tindakan Penanganan Resiko ID Strategi Skor

S4 Studi kelayakan untuk memahami sistem secara lebih komprehensif 924.5

S3 Manajemen Perubahan Proyek ERP 888.75

S1 Pendefinisian tanggung jawab dan otortitas pengambilan keputusan 828

S6 Perbaikan proses yang berkelanjutan untuk mencapai best practices 609.75

S5 Penyusunan business case yang baik 599.25

S2 Upaya peningkatan komitmen dari manajemen level atas 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.

Identifikasi item resiko yang dapat terjadi

MULAI

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

• Lemahnya proses implementasi

• Lemahnya fokus pada proses bisnis

• Tantangan adaptasi pengguna sistem

• Lemahnya dukungan organisasi

• Isu konfigurasi teknologi informasi

• Permasalahan infrastruktur

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.


139


Item resiko dengan kategori resiko tinggi antara lain:

Tabel 5.1 Item Resiko Kategori Tinggi ID 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 Kurangnya komitmen dari manajemen level atas dalam

proyek ERP

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

sistem sehingga solusi yang dihasilkan tidak optimal

A1-3

Kurangnya Roadmap yang kuat yang berperan memandu

proses perubahan dalam organisasi selama proses



A3-3

Parameter performa dan target tidak terdefinisikan dengan

baik; lemahnya hubungan antara desain proses dan

business case


A2-1 Gagal dalam memberikan perbaikan proses secara

berkelanjutan


140


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)

Item resiko dengan kategori resiko menengah antara lain:

Tabel 5.2 Item Resiko Kategori Menengah ID Item Resiko

A1-1

Pendefinisian perencanaan yang buruk untuk

menghubungkan implementasi ERP dengan perubahan

strategi perusahaan

A3-4 Proses statis dan tidak dapat beradaptasi dengan perubahan

kondisi bisnis




A4-5 Rendahnya tingkat partisipasi pengguna sebelum dan

sesudah fase implementasi


A6-6 Rendahnya dukungan terhadap beberapa fungsionalitas

bisnis yang diperlukan

A1-4

Business case yang tidak terdefinisikan dengan baik,tidak

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 Mengabaikan pentingnya pengukuran perkembangan dan

performa di dalam proyek ERP

A6-8 Penentuan pemilihan server yang tidak didasarkan kepada

analisa keperluan penyimpanan data

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-

10

Tidak berjalannya pemeliharaan pencegahan (preventive

maintenance)

A5-1

Gagal dalam mengimplementasikan perubahan dalam

definisi peran dan desain organisasi yang diperlukan untuk

mencapai business case yang diharapkan

(sumber: penulis)

Item resiko dengan kategori resiko rendah antara lain:

Tabel 5.3 Item Resiko Kategori Rendah ID 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

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)

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

Tabel 5.4 Strategi Penanganan Resiko ID Strategi Skor

S4 Studi kelayakan untuk memahami sistem secara lebih komprehensif 924.5

S3 Manajemen Perubahan Proyek ERP 888.75

S1 Pendefinisian tanggung jawab dan otortitas pengambilan keputusan 828

S6 Perbaikan proses yang berkelanjutan untuk mencapai best practices 609.75

S5 Penyusunan business case yang baik 599.25

S2 Upaya peningkatan komitmen dari manajemen level atas 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

Instruction

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 risk item important to be included. Don't forget to write down the ID code for each risk item.

ID Inadequate Executive Alignment (A1)






145



ID Weak Post-Implementation (A2)






ID Lack of Focus on Business Process (A3)






ID End-User Adoption Challenges (A4)

A4-1 Inadequate initial training

A4-2 Inadequate change management process for moving end users to new roles and new processes

A4-3 Inadequate user-support structure and resources (e.g.,no specialized "Competency Center" to carry on after initial super users migrate)

A4-4 Lack of accountability and support for ongoing knowledge management and training

A4-5 Lack of user participation in pre and post implementation phase

ID 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 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 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


<Risk ID, e.g A5> <Risk item that not included yet in the above list that you think important to be included> < Reason why this risk item important to be included>

ID Risk Items Rationale



Lampiran 2

Kuesioner Tahap Kedua

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

1 2 4 8 16 1 2 3 4 5






1 2 4 8 16 1 2 3 4 5






1 2 4 8 16 1 2 3 4 5






Probability (P)

Probability (P)

ID

ID

Questionnaire 2

Weak Post-Implementation (A2) Impact (I)

Inadequate Executive Alignment (A1) Impact (I)

ID Lack of Focus on Business Process (A3) Impact (I) Probability (P)


150


1 2 4 8 16 1 2 3 4 5

A4-1 Inadequate initial training

A4-2 Inadequate change management process for moving end users to new roles and new processes

A4-3 Inadequate user-support structure and resources (e.g.,no specialized "Competency Center" to carry on after initial super users migrate)

A4-4 Lack of accountability and support for ongoing knowledge management and training

A4-5 Lack of user participation in pre and post implementation phase

1 2 4 8 16 1 2 3 4 5

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

1 2 4 8 16 1 2 3 4 5

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

1 2 4 8 16 1 2 3 4 5

A7-1 Operating cost initially underestimated,thus weakening original business case

A7-2 System response time is slow, hampering adoption and eroding productivity

Probability (P)

ID End-User Adoption Challenges (A4) Impact (I) Probability (P)

Probability (P)

ID

ID IT Configuration Issues (A6) Impact (I)

Organzational Flaws or Inadequacies (A5) Impact (I)

ID Infrastructure Shorcomings (A7) Impact (I) Probability (P)


151


Lampiran 3

Kuesioner Tahap Ketiga


152


Lampiran 4

Hasil Kuesioner Tahap Kedua


153


Lampiran 5

Hasil Kuesioner Tahap Ketiga

ID Item Resiko Rekomendasi

A1-1

Pendefinisian perencanaan yang buruk

untuk menghubungkan implementasi ERP

dengan perubahan strategi perusahaan

Tim eksekutif dengan jelas

mengartikulasikan rencana

perubahan dan menunjukkan

bagaimana 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 karyawan dalam

proyek ERP dan membuat

karyawan melihat proyek ERP

sebagai alat pendukung dalam

perbaikan proses bisnis

Menjalankan rencana komunikasi

yang telah didefinisikan dengan

baik serta journey management

seperti melakukan road show dan

sosialisasi kepada manajemen level

atas untuk meningkatkan komitmen

A1-2 Kurangnya komitmen dari manajemen

level atas dalam proyek ERP

Manajemen level atas harus

memiliki komitmen 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 proses perubahan

dalam organisasi selama proses


yang dapat memastikan

implementasi ERP berjalan dengan

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

penyesuaian.Business case dapat

disesuaikan dengan k A1-4

Business case yang tidak terdefinisikan

dengan baik,tidak mendorong, atau kurang

cukupnya komitmen tim eksekutif untuk

menjalankannya

Perusahaan melakukan benchmark

untuk menetapkan target yang

agresif tapi dapat dicapai dengan

multilevel dashboard yang

menghubungkan hasil bisnis

dengan paramater operasional yang

detail. Untuk menjustifikasi

peluncuran proyek, sebuah business

case harus

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 kar

A1-5 Pemisahan peran IT dalam kepentingan

bisnis

Manajemen eksekutif membuat

business cae yajg 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

sehari-hari.Inisiatif untuk

melakukan perbaika A2-1

Gagal dalam memberikan perbaikan proses

secara berkelanjutan

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 di sepanjang dan

sesudah proses implementasi

proyek ERP. Seringkali kurangnya

keputusan menjadikan penghambat

bagi pemilik proses bisnis untuk

mendapatkan manfaat dari ERP.

Pemilik proses bisnis harus

ditentuka

A2-2

Manajer proses/pemilik tidak memiliki

akuntabilitas yang terdefinisikan dengan

baik,atau tidak memiliki otoritas untuk

pengambilan keputusan

Pemilik proses harus memiliki

akuntabilitas dan otoritas


156


mendorong terciptanya hasil

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

Oleh karena manajemen lintas

fungsional harus membuat

keputusan yang sulit yang

mempengaruhi berbagai unit bisnis

dan fungsi, manajemen senior

harus secara jelas terlihat

mendorong dan mendukung cara

kerja yang baru. Buat keputusan

yang cepat dan memberda

A2-4

Model pendanaan yang tidak efektif dan

gagal menghasilkan peningkatan yang

bernilai tinggi

Kebutuhan akan ongoing

governance di lingkungan pasca

impelementasi, perusahaan perlu

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

hilang. Oleh karena itu, A2-5

Pendefinisian akuntabilitas yang buruk

dari integritas data master Lakukan standardisasi untuk

memfokuskan pekerjaan proyek

kepada 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

sistem. Manajemen eksekutif harus

memiliki komitmen dan memimpin

proyek ERP untuk

mengimplementasikan best

practices dan tidak hanya

A3-1

Gagal dalam mengimplementasikan best

practices dan tidak memiliki rencana untuk

mengimplementasikannya

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

berlangsung untuk menjadi bagian

dari anggota proyek dan sumber

informasi mengenai proses bisnis

yang telah ada

A3-2

Tim implementasi gagal dalam memahami

karakateristik sistem sehingga solusi yang

dihasilkan tidak optimal

Lakukan studi kelayakan untuk

memahami sistem yang ada secara

komprehensif

Definisikan parameter performa

sebelum proyek dimulai dan

kaitkan dengan business case dan

strategi

A3-3

Parameter performa dan target tidak

terdefinisikan dengan baik; lemahnya

hubungan antara desain proses dan

business case

Buat rencana perbaikan terus-

menerus yang 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

A3-4 Proses statis dan tidak dapat beradaptasi

dengan perubahan kondisi bisnis

Gunakan pendekatan secara

bertahap untuk

mengimplementasikan perubahan

yang kompleks di dalam business

process reengineering

A3-5 Kekurangan dalam desain data master

menghambat performa proses

Tetapkan akuntabilitas dan sumber

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 tepat berdasarkan

kebutuhan; seperti pelatihan

berdasarkan peran, audience-based

training (Pada umumnya, pelatihan

yang dikustomisasi lebih baik

daripada yang standar, deng


Gunakan program pelatihan multi

dimensi yang memperlengkapi

pengguna sebelum tanggal go-live

Perbaiki metode komunikasi dan

tingkatkan kualitas serta kuantitas

dari proses sosialisasi peran yang

baru kepada pengguna akhirs

A4-2

Tidak cukupnya manajemen perubahan

untuk membimbing pengguna sistem

menjalankan peran dan proses yang baru

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.

A4-3 Tidak cukupnya struktur dan sumber daya

yang berperan sebagai user-support

Penyediaan sumber daya

pendukung kpada pengguna yang

konsisten seperti membuat help

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 diperbaharui dan

dipelihara secara rutin untuk

menyediakan perbaikan proses dan

perubahan dalam operasi bisnis

sehari-hari

A4-4

Tidak cukupnya dukungan dan

akuntabilitas terhadap pelatihan dan

manajemen pengetahuan yang berlangsung

Lakukan perencanaan untuk

pemeliharaan aset ERP. Dukungan

yang berjalan meliputi tidak hanya

peningkatan sistem dan

fungsionalitas dari perangkat lunak

saja, tapi, yang paling penting

adalah perbaikan proses

bisnis.Dukungan ini 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

diperlukan untuk

mengimplementasikan perubahan

peran dan organisasi A5-1

Gagal dalam mengimplementasikan

perubahan dalam definisi peran dan desain

organisasi yang diperlukan untuk

mencapai business case yang diharapkan Tingkatkan peran tradisional.

Implementasi yang sukses

memerlukan perbaikan dalam peran

tradisional

A5-2 Gagal dalam mengidentifikasi terjadinya

gap talenta dalam perusahaan

Tingkatkan kapabilitas dan

kemampuan analisa pengguna dan

melakukan perekrutan untuk peran

yang terspesialisasi

A5-3

Organisasi fungsional tidak dipersiapkan

dengan baik untuk menggunakan sistem

baru dengan efektif

Lakukan penyesuaian terhadap

deskripsi pekerjaan dan tingkat

upah

A5-4

Mengabaikan pentingnya pengukuran

perkembangan dan performa di dalam

proyek ERP

Miliki sistem manajemen yang

komprehensif yang menyediakan

mekanisme um[an balik untuk

melacak setiap usaha implementasi,

mengidentifikasi gap yang ada dan

defisiensi dalam performa dan

memberikan rekomendasi tindakan

yang perlu dilakukan dalam

berbeagai

Buat rencana komunikasi yang

terdefinisikan dengan baik A5-5 Mengabaikan potensi komunikasi

Bangun strategi komunikasi formal

dengan menggunakan berbagai


161


saluran informasi seperti focus

group, newsletter, email, dan

website untuk membantu karyawan

mendapatkan informasi terbaru

mengenai perkembagan proyek

ERP dan mendapatkan jawaban

atas pertanya

A5-6 Tidak efektifnya peran manajemen

konsultasi

Bangun pendekatan yang jelas

untuk memastikan proses transfer

pengetahuan dan keahlian dari

konsultan ke perusahaan berjalan

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 kapabilitas untuk

menjalankan proyek. Penetapan

orang-otrang yang tepat, dengan

beberapa kriteria seperti :

memahami TI, memiliki sikap yang

baik, dan menguasai pengetahuan

yang baik A5-7

Rendahnya kapabilitas dalam manajemen

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 dan penggunaan sistem

terhadap data yang diperlukannya

A6-2

Sistem yang terlalu rumit dan tidak user

friendly menyebabkan pengguna bekerja di

luar sistem

Hal ini bisa dihindari dengan

melibatkan secara intensif

pengguna/ pemilik proses bisnis

dalam implementasi proyek ERP,

dengan 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 untuk

mendefinisikan keperluan

pelaporan diData Warehouse pada

awal sebelum sistem untuk

transaksi dimple A6-3

Data warehouse tidak

diimplementasikan;menghambat

efektivitas penggunaan data yang tersedia Fasilitasi data mining. Pengguna

memiliki alat untuk menggunakan

data secara offline sehingga tidak

membatasi kreativitas atau

memerlukan pemrograman TI

khusus untuk membuat

laporan.Data mining paling baik

dilakukan dengan aplikasi data

warehouse

A6-4

Sistem terlalu banyak dikustomisasi saat

implementasi menyebabkan kesulitan

dalam upgrade dan pemeliharaan Ikuti panduan untuk melakukan

implementasi sestandar mungkin,

dan ikuti best practice daripada


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 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 bisn

A6-5 Rendahnya fleksibilitas dalam aplikasi

ERP yang digunakan

Gunakan software ERP yang

berbasis open source untuk

memungkinkan dilakukan

pengembangan aplikasi dan

kustomisasi

A6-6 Rendahnya dukungan terhadap beberapa

fungsionalitas bisnis yang diperlukan

Persiapkan dan bangun organisasi

pendukung pada saat implementasi

proyek ERP

A6-7 Rendahnya parameterisasi, standardisasi,

dan dokumentasi

Bangun prosedur dan metodologi

untuk membuat, memelihara dan

memperbaharui manajemen

dokumentasi

A6-8

Penentuan pemilihan server yang tidak

didasarkan kepada analisa keperluan

penyimpanan data

Penilaian infrastruktur dan

kebutuhan diperlukan di awal

permulaan proyek


164


Lakukan analisa kebutuhan data

storage sebelum pemilihan server

A6-9 Terbatasnya integrasi aplikasi dan sistem

Manajer integrasi harus memiliki

performa yang baik dalam

impementasi proyek ERP

A6-10 Tidak berjalannya pemeliharaan

pencegahan (preventive maintenance)

Lakukan pemeriksaan manajemen

pemeliharaan untuk memastikan

performa yang optimal dari sistem

ERP

A7-1

Biaya operasional yang diestimasikan

terlalu rendah melemahkan pencapaian

business case

Perencanaan infrastruktur yang

kuat meliputi perencanaan

kapasitas jaringan untuk

mengantisipasi vlume lalu lintas

data dan seberapa sering data

diperbarui dalam server computer

A7-2

Waktu respon sistem yang

lambat,menghambat proses adopsi dan

merusak produktivitas

Definisikan kebutuhan infrastruktur

di awal dan kaitkan dengan

business case dari proyek

implementasi ERP


165



ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE ...lib.ui.ac.id/file?file=digital/2016-9/20249964-S50375...ANALISA MANAJEMEN RESIKO PROYEK ENTERPRISE RESOURCE PLANNING SKRIPSI Diajukan

Documents