9113205412 Master Thesis 4q177

TESIS – PM147501

PERANCANGAN TATA KELOLA MANAJEMEN INSIDEN TI BERDASARKAN KERANGKA KERJA ITIL 2011 (STUDI KASUS PADA PT. BANK ABC) VALENTINO BUDI PRATOMO 9113.205.412

DOSEN PEMBIMBING Dr. Ir. R. V. HARI GINARDI, M.Sc

PROGRAM MAGISTER MANAJEMEN TEKNOLOGI BIDANG KEAHLIAN MANAJEMEN TEKNOLOGI INFORMASI PROGRAM PASCASARJANA INSTITUT TEKNOLOGI SEPULUH NOPEMBER SURABAYA 2016

THESIS – PM147501

DEG IT GOVERNANCE OF INCIDENT MANAGEMENT BASED ON ITIL 2011 FRAMEWORK (CASE STUDY ON PT. BANK ABC) VALENTINO BUDI PRATOMO 9113.205.412

SUPERVISOR Dr. Ir. R. V. HARI GINARDI, M.Sc

PROGRAM MAGISTER MANAJEMEN TEKNOLOGI BIDANG KEAHLIAN MANAJEMEN TEKNOLOGI INFORMASI PROGRAM PASCASARJANA INSTITUT TEKNOLOGI SEPULUH NOPEMBER SURABAYA 2016

KATA PENGANTAR

Puji syukur penulis ucapkan kehadirat Tuhan Yang Maha Esa atas segala anugerah-Nya serta limpahan rahmat-Nya, sehingga penulis dapat menyelesaikan laporan Tesis ini dengan sebaik-baiknya. Laporan Tesis dengan judul ”Perancangan Tata Kelola Manajemen Insiden TI Berdasarkan Kerangka Kerja ITIL 2011 (Studi Kasus pada PT Bank ABC)” ini penulis buat sebagai salah satu syarat dalam menyelesaikan Program Studi Magister Manajemen Teknologi di Institut Teknologi Sepuluh Nopember Surabaya. Dalam pelaksanaan penelitian Tesis maupun pembuatan laporan Tesis ini, penulis mendapatkan bantuan dari berbagai pihak. Oleh karena itu, penulis ingin mengucapkan terima kasih kepada: 1.

Bapak, Ibu dan kedua adik, serta keluarga tercinta yang telah memberikan

dukungan semangat dan moril, sehingga dapat terselesaikannya Tesis ini. 2.

Ibu Prof. Dr. Yulinah T, MAppSc selaku Ketua Program Studi Magister

Manajemen Teknologi (MMT), Program Pasca Sarjana, Institut Teknologi Sepuluh Nopember Surabaya. 3.

Bapak Ir. I Putu Artama Wiguna, MT, PhD selaku Sekretaris Program Studi

MMT, Institut Teknologi Sepuluh Nopember Surabaya. 4.

Bapak Prof. Dr. Ir. Joko Lianto Bulali, MSc selaku Koordinator bidang

keahlian Manajemen Teknologi Informasi (MTI) MMT, Institut Teknologi Sepuluh Nopember Surabaya. 5.

Bapak Dr. Ir. R.V. Hari Ginardi, MSc selaku Dosen Pembimbing yang telah

membimbing dan mengarahkan penulis dengan baik dan sabar. 6.

Staf Dosen yang telah memberikan ilmu bermanfaat, serta Karyawan MMT

ITS yang telah memberikan bantuan dan layanan selama ini. 7.

Bapak Audy Iwan H dan Bapak Irwan Halim selaku DC Manager PT Bank

ABC, Tbk, atas dukungan yang diberikan kepada penulis dalam menempuh perkuliahan dan penyusunan Tesis ini.

vii

8.

Rekan-rekan Group Leader & Shift Leader DC Jakarta dan Surabaya atas

dukungan informasinya. 9.

Bapak Suryanto Chandra, Andi Rahmatullah Tohir, I Putu Agus Hendra

Krisnawan, Laurentius Christian, dan Rekan-rekan Grha Asia Surabaya yang telah membantu dalam pengumpulan data dalam penelitian tesis ini. 10.

Rekan-rekan MMT MTI ITS, atas segala masukan, motivasi, bantuan dan

kebersamaannya. 11.

Pihak lain yang telah membantu hingga terselesaikannya Tesis ini, baik

secara langsung maupun tidak langsung. Penulis menyadari bahwa dalam Tesis ini masih banyak terdapat kekurangan. Oleh karena itu, penulis memohon saran dan kritik yang bersifat konstruktif dari semua pihak untuk perbaikan penulis di masa mendatang. Akhir kata, penulis mengucapkan terima kasih atas perhatiannya. Semoga Tesis ini dapat bermanfaat bagi para pembaca.

Surabaya, Januari 2016

Valentino Budi Pratomo

viii

PERANCANGAN TATA KELOLA MANAJEMEN INSIDEN TI BERDASARKAN KERANGKA KERJA ITIL 2011 (STUDI KASUS PADA PT. BANK ABC) Nama Mahasiswa NRP. Pembimbing

: Valentino Budi Pratomo : 9113.205.412 : Dr. Ir. R.V. Hari Ginardi, M.Sc

ABSTRAK Kemajuan Teknologi Informasi (TI) dalam industri perbankan menuntut setiap bank untuk tidak hanya sekedar meningkatkan inovasi, namun juga mampu untuk mengelola dan mencegah setiap permasalahan yang terjadi. Guna mendukung keberlangsungan bisnis perusahaan, PT. Bank ABC melalui divisi Group Strategic Information Technology (GSIT) diharuskan siap dan tanggap terhadap segala macam insiden yang terjadi pada layanan TI. Dengan adanya tata kelola manajemen insiden TI yang baik, bank akan dapat mengetahui, menyelesaikan dan mencegah setiap insiden TI yang akan terjadi. Untuk mendukung perancangan tata kelola manajemen insiden TI tersebut, digunakan kerangka kerja ITIL 2011 (ITIL V3 2011 Edition) sebagai acuan dalam proses maturity level assessment, hal ini dilakukan untuk memperoleh gap antara dua kondisi, yaitu tata kelola manajemen insiden TI saat ini (current) dan tata kelola manajemen insiden TI yang diharapkan kedepannya (target). Dalam penelitian ini, proses maturity level assessment dilakukan terhadap kondisi tata kelola manajemen insiden TI saat ini, dengan menyebarkan kuesioner kepada pihak yang terlibat dalam proses manajemen insiden TI, hingga kemudian didapatkan score baku. Hasil proses assessment tersebut, yaitu berupa score dari masing-masing atribut, kemudian dibandingkan dengan target score tata kelola manajemen insiden TI yang telah ditetapkan oleh pihak manajemen, yaitu sebesar 3. Dari hasil proses pembandingan tersebut, ditemukan gap atas tata kelola manajemen insiden TI yang ada, yaitu pada service operation area “Incident Management Process” terdapat nilai 1 dan 2, “Incident Management Metrics” dan “Activities in Place needed for the Success of Incident Mangement” terdapat nilai 1, serta pada “Incident Management Process Interactions” terdapat nilai 2. Dari analisa gap yang ada, diperoleh rekomendasi perbaikan dokumentasi terhadap service operation area tersebut yang dapat digunakan untuk perancangan Tata Kelola Manajemen Insiden TI berdasarkan ITIL 2011. Dengan dilakukannya penelitian ini, maka rancangan tata kelola manajemen insiden TI yang dihasilkan dapat digunakan dalam menghadapi kebutuhan manajemen insiden TI mendatang yang sesuai dengan kaidah kerangka kerja ITIL 2011.

iii

DEG IT GOVERNANCE OF INCIDENT MANAGEMENT BASED ON ITIL 2011 FRAMEWORK (CASE STUDY ON PT. BANK ABC) Student Name Student Number Supervisor

: Valentino Budi Pratomo : 9113.205.412 : Dr. Ir. R.V. Hari Ginardi, M.Sc

ABSTRACT The advancement of Information Technology (IT) in the banking industry requires each bank to not only boost innovation, but also able to manage and prevent any problems that occur. To the business continuity of the company, PT. ABC Bank through a division of Group Strategic Information Technology (GSIT) is required to prepare for and respond to all kinds of incidents that occur in IT services. With the governance of IT incident management are good, banks will be able to know, resolve and prevent any IT incident that will happen. To the design of governance incident management IT is, the ITIL 2011 framework (ITIL V3 2011 Edition) is used as a reference in the process maturity level assessment, to obtain a gap between the two conditions, namely governance incident management IT today (current) and management of IT incidents that are expected in the future (target).In this study, the process of maturity level assessment was done on the current condition of the governance of IT incident management, by distributing questionnaires to parties involved in the IT incident management process, until then obtained score.The results of the assessment process, namely in the scores of each attribute, and then compared with the target score of governance management of IT incidents that have been established by management, scored 3. From the results of the benchmarking process, found a gap on the governance of IT incident management exist, namely the service operation area "Incident Management Process" there is a value of 1 and 2, "Incident Management Metrics" and "Activities in Place needed for the Success of Incident Management," there is a value of 1, and the "Incident Management Process Interactions" there is value 2. From the analysis of the existing gap, obtained recommendations for improvements to the service operation documentation of the area that can be used to design Incident Management IT Governance based on ITIL 2011. In this study, the design of the IT incident management governance produced can be used in dealing with the incident management needs for the future in accordance with the rules of the ITIL framework in 2011.

v

DAFTAR ISI

LEMBAR PENGESAHAN ................................................................................. i ABSTRAK......................................................................................................... iii ABSTRACT ....................................................................................................... v KATA PENGANTAR ...................................................................................... vii DAFTAR ISI ..................................................................................................... ix DAFTAR GAMBAR....................................................................................... xiii DAFTAR TABEL ............................................................................................ xv DAFTAR LAMPIRAN .................................................................................. xvii BAB 1 PENDAHULUAN................................................................................... 1 1.1.

Latar Belakang..................................................................................... 1

1.2.

Perumusan Masalah ............................................................................. 3

1.3.

Batasan Masalah .................................................................................. 3

1.4.

Tujuan Penelitian ................................................................................. 4

1.5.

Manfaat Penelitian ............................................................................... 4

1.6.

Sistematika Penulisan .......................................................................... 4

BAB 2 KAJIAN PUSTAKA .............................................................................. 7 2.1.

Proses Manajemen Insiden (existing) ................................................... 7

2.2.

Tata Kelola ........................................................................................ 12

2.2.1.

Tata Kelola TI .................................................................................. 12

2.3.

Incident Management Framework ...................................................... 14

2.4.

Framework ITIL ................................................................................ 15

2.4.1.

Service Strategy ............................................................................... 17

2.4.2.

Service Design ................................................................................. 19

2.4.3.

Service Transition ............................................................................ 21

2.4.4.

Service Operation ............................................................................ 23

2.4.5.

Continual Service Improvement........................................................ 26

2.5.

Perbandingan ITIL v2 2007 dan ITIL v3 2011 ................................... 27

2.6.

Proses Manajemen Insiden (ITIL 2011) ............................................. 29

ix

2.7.

Responsibility Assignment Matrix (RAM) ........................................... 32

BAB 3 METODOLOGI PENELITIAN .......................................................... 35 3.1.

Pengumpulan Informasi dan Analisa .................................................. 36

3.2.

Penilaian Tingkat Kematangan ........................................................... 37

3.3.

Perancangan Dokumen Tata Kelola.................................................... 42

3.4.

Verifikasi Dokumen Tata Kelola ........................................................ 42

3.5.

Validasi Dokumen Tata Kelola .......................................................... 43

3.6.

Kesimpulan ........................................................................................ 43

3.7.

Rencana dan Jadwal Kerja Penelitian dan Penyusunan Tesis .............. 43

BAB 4 ANALISA DAN PEMBAHASAN........................................................ 45 4.1.

Profil PT Bank ABC .......................................................................... 45

4.1.1 Sejarah PT Bank ABC ....................................................................... 46 4.1.2 Visi, Misi, dan Tata Nilai PT Bank ABC............................................ 48 4.1.3 Struktur Organisasi PT Bank ABC ..................................................... 49 4.2.

Pengelolaan TI PT Bank ABC........................................................... 51

4.2.1 Struktur Organisasi TI ........................................................................ 51 4.2.2 Solusi Bisnis Organisasi TI ................................................................ 56 4.3.

Tata Kelola Manajemen Insiden TI .................................................... 57

4.3.1 Pengumpulan Informasi dan Analisa .................................................. 57 4.3.2 Manajemen Insiden TI Saat ini ........................................................... 58 4.3.3 Struktur Dokumen Manajemen Insiden TI Saat ini ............................. 67 4.3.4 Pengembangan Tata Kelola Manajemen Insiden ................................ 69 4.3.4.1

Penentuan Target Maturity Level ....................................................... 69

4.3.4.2

Membandingkan Current vs Target .................................................... 72

4.3.4.3

Review Dokumen Pendukung ............................................................ 75

4.3.5 Struktur Dokumen Tata Kelola Manajemen Insiden ........................... 78 BAB 5 DESAIN DOKUMEN TATA KELOLA ............................................. 81 5.1.

Verifikasi Tata Kelola Manajemen Insiden TI .................................... 81

5.2.

Validasi Tata Kelola Manajemen Insiden TI ...................................... 82

5.3.

Perubahan Tata Kelola Manajemen Insiden TI ................................... 82

5.4.

Tata Kelola Manajemen Insiden TI .................................................... 86

BAB 6 KESIMPULAN DAN SARAN ........................................................... 113

x

DAFTAR PUSTAKA ..................................................................................... 115

xi

DAFTAR GAMBAR

Gambar 2.1 Alur Manajemen Insiden TI ......................................................... 8 Gambar 2.2 Top 5 Incident Agustus 2015....................................................... 11 Gambar 2.3 Service Lifecycle framework ITIL 2011 ....................................... 16 Gambar 2.4 ITIL Service Strategy ................................................................... 18 Gambar 2.5 ITIL Service Design ..................................................................... 21 Gambar 2.6 ITIL Service Transition ................................................................ 23 Gambar 2.7 ITIL Service Operation ................................................................ 25 Gambar 2.8 ITIL Continual Service Improvement .......................................... 26 Gambar 2.9 Sub Proses Incident Management ............................................... 30 Gambar 2.10 Alur Proses Implementasi Incident Management ..................... 32 Gambar 3.1 Metodologi Penelitian................................................................. 35 Gambar 4.1 Struktur Organisasi PT Bank ABC ............................................ 51 Gambar 4.2 Posisi Strategic Information Technology Group .......................... 52 Gambar 4.3 Bagan Organisasi Group Strategic Information Technology ...... 52 Gambar 4.4 Solusi Bisnis TI GSIT .................................................................. 57 Gambar 4.5 Ketentuan Penanganan Insiden TI ............................................. 59 Gambar 4.6 Service Area Incident Management Plan ..................................... 61 Gambar 4.7 The Incident Management Process .............................................. 62 Gambar 4.8 Activities in Place Needed for the Success of Incident Mangement .......................................................................................................... 64 Gambar 4.9 Incident Management Metrics ...................................................... 65 Gambar 4.10 Incident Management Process Interactions ............................... 66

xiii

DAFTAR TABEL

Tabel 2.1 Data Statistik Insiden TI Agustus 2015 ............................................... 10 Tabel 2.2 Statistik Incident Log.......................................................................... 11 Tabel 2.3 Perbandingan Incident Management pada ITIL v2 dan ITIL v3 .......... 27 Tabel 2.4 RACI Matrix ITIL Incident Management ........................................... 33 Tabel 3.1 Pihak yang Terlibat dalam Pengumpulan Informasi dan Analisa ......... 37 Tabel 3.2 Definisi Maturity Level....................................................................... 38 Tabel 3.3 Karakteristik Maturity Level. .............................................................. 39 Tabel 3.4 Rencana dan Jadwal Penelitian dan Penyusunan Tesis ........................ 44 Tabel 4.1 Average Score Incident Management Plan ......................................... 62 Tabel 4.2 Score “Incident Management Process” .............................................. 63 Tabel 4.3 Score “Activities in Place needed for the Success of Incident Mangement” ...................................................................................... 64 Tabel 4.4 Score “Incident Management Metrics” .............................................. 65 Tabel 4.5 Score “Incident Management Process Interactions” .......................... 66 Tabel 4.6 Struktur Panduan Pengelolaan Incident............................................... 68 Tabel 4.7 Target Score “Incident Management Process” ................................... 70 Tabel 4.8 Target Score “Activities in Place needed for the Success of Incident Mangement” ...................................................................................... 71 Tabel 4.9 Target Score “Incident Management Metrics” ................................... 71 Tabel 4.10 Target Score “Incident Management Process Interactions” ............. 71 Tabel 4.11 Current vs Target “Incident Management Process” ......................... 72 Tabel 4.12 Current vs Target “Activities in Place needed for the Success of Incident Mangement” ........................................................................ 73 Tabel 4.13 Current vs Target “Incident Management Metrics”.......................... 74 Tabel 4.14 Current vs Target “Incident Management Process Interactions”...... 74 Tabel 4.15 Dokumen Pendukung “Incident Management Process” .................... 75 Tabel 4.16 Dokumen Pendukung “Activities in Place needed for the Success of Incident Mangement” ......................................................................... 77

xv

Tabel 4.17 Dokumen Pendukung “Incident Management Metrics” .................... 77 Tabel 4.18 Dokumen Pendukung “Incident Management Process Interactions” 78 Tabel 5.1 Tahapan Verifikasi Tata Kelola Manajemen Insiden TI ...................... 81 Tabel 5.2 Tata Kelola Manajemen Insiden TI (existing) ..................................... 82 Tabel 5.3 Tata Kelola Manajemen Insiden TI berdasarkan ITIL 2011 ................ 84 Tabel 5.4 Perubahan Tata Kelola Manajemen Insiden TI.................................... 85

xvi

DAFTAR LAMPIRAN

Lampiran A. Form Kuesioner Penilaian Proses Manajemen Insiden ................. 117

xvii

BAB 1 PENDAHULUAN Pada bab pendahuluan ini akan dijelaskan mengenai permasalahan yang melatar belakangi dilakukannya penelitian, perumusan masalah, pembatasan masalah, tujuan dilakukannya penelitian, manfaat yang dapat diambil, serta sistematika penulisan sebagai acuan dalam penulisan penelitian Perancangan Tata Kelola Manajemen Insiden TI berdasarkan kerangka kerja ITIL 2011 di PT Bank ABC. Adapun penjelasan pendahuluan yang dimaksud terdapat pada sub bab berikut ini: 1.

Latar Belakang

2.

Perumusan Masalah

3.

Batasan Masalah

4.

Tujuan Penelitian

5.

Manfaat Penelitian

6.

Sistematika Penulisan

Berikut ini merupakan penjelasan lebih lanjut dari sub bab di atas.

0.1. Latar Belakang Peranan Teknologi Informasi (TI) di tengah ketatnya persaingan bisnis saat ini sangat besar dirasakan oleh perusahaan. Teknologi Informasi telah menjadi bagian yang sangat penting dan strategis bagi keberlangsungan bisnis perusahaan. Dibeberapa perusahaan, peranan TI tidak lagi hanya sebagai pendukung operasional perusahaan, namun telah mampu menjadi pemicu penghasil keuntungan bagi perusahaan. Di sektor perbankan, TI dapat membantu meningkatkan nilai tambah layanan perbankan, serta mampu meningkatkan kepuasan nasabah terhadap layanan yang diberikan oleh perusahaan. Peranan TI juga telah membantu mempermudah kinerja internal secara efektif dan efisien. Sebagai perusahaan perbankan dengan jumlah nasabah yang besar, PT Bank ABC tentunya memiliki sumber daya TI yang sangat besar pula.

1

Operasional TI perbankan yang dimiliki perusahaan digunakan diseluruh operasional cabang dan pusat. Dengan kemudahan yang didapat dalam penerapan TI, operasional perbankan menjadi lebih mudah dilakukan oleh pihak internal perusahaan. Begitu pula dengan seluruh kemudahan aplikasi yang ditawarkan perusahaan kepada nasabah, baik personal maupun bisnis. Seiring dengan meningkatnya kemampuan TI dalam industri perbankan, maka sebuah organisasi TI dituntut untuk terus melakukan pendekatan untuk mengembangkan pemanfaatan sumber daya TI yang ada. Segala upaya yang dilakukan untuk mengatur dan mengelola sumber daya TI yang ada, merupakan usaha untuk menemukan cara yang tepat agar dapat memenuhi kebutuhan bisnis untuk mencapai tujuan perusahaan. Pengelolaan sumber daya TI yang dimiliki oleh PT Bank ABC dilakukan secara terpusat yang dikendalikan oleh divisi Group Strategic Information Technology (GSIT). Untuk menunjang keberlangsungan bisnis perusahaan, PT Bank ABC dituntut untuk siap dalam menghadapi segala macam kondisi dan situasi yang terjadi. Berbagai ancaman dan gangguan dapat menyerang dan mengganggu kinerja perusahaan yang telah berkembang begitu pesat saat ini. Ancaman dan gangguan tersebut dapat terjadi secara fisik maupun non-fisik, baik yang dilakukan secara disengaja maupun tidak disengaja. Tak terkecuali bagi divisi GSIT, yang bertanggung jawab terhadap operasional TI perusahaan. Segala macam ancaman dan gangguan seperti, bencana alam, gangguan kelistrikan, kegagalan sistem, baik yang telah terdata maupun tidak terdata sebelumnya, dapat menimpa operasional TI kapanpun dan dimanapun. Untuk mencegah terjadi kerugian akibat dari dampak setiap insiden TI yang dialami oleh perusahaan. PT Bank ABC, khususnya divisi GSIT, telah mempersiapkan pencegahan terhadap kemungkinan-kemungkinan yang terjadi. Pencegahan dan pengelolaan insiden TI tersebut dilakukan oleh divisi GSIT, dibawah kendali sub divisi IT Infrastructure & Operation Management (IIO). Saat ini manajemen tidak mengetahui kondisi terkini (existing) terhadap tata kelola manajemen insiden TI yang dimiliki oleh sub divisi IIO. Tata kelola

2

manajemen insiden TI tersebut tidak diketahui apakah masih mampu menangani perkembangan kebutuhan TI perusahaan hingga saat ini. Untuk menghadapi permasalahan tersebut, diperlukan sebuah tata kelola manajemen insiden yang baik dan benar sesuai dengan kerangka kerja tata kelola TI yang ada. Melalui framework ITIL 2011, maka diharapkan akan lebih fokus kepada best-practice yang dapat diimplementasikan untuk keberlangsungan layanan TI (IT Service Continuity) perusahaan. Dengan adanya tata kelola manajemen insiden TI yang baik dan benar, maka diharapkan manajemen insiden dapat lebih siap terhadap segala macam ancaman dan gangguan. Sehingga keberlangsungan layanan TI dapat terjaga, dan tentunya dapat menjaga keberlangsungan bisnis perusahaan untuk tetap pada kinerja postif. Sehingga visi perusahaan untuk menjadi pilar penting perekonomian Indonesia dapat terwujud.

0.2. Perumusan Masalah Berdasarkan uraian mengenai latar belakang permasalahan yang telah dijelaskan, maka dapat diberikan beberapa perumusan masalah, diantaranya: 1.

Bagaimana mengidentifikasi gap antara tata kelola manajemen insiden TI saat ini (existing) dengan tata kelola manajemen insiden TI yang diharapkan yang mengacu pada kerangka kerja ITIL 2011.

2.

Bagaimana merancang dokumen tata kelola manajemen insiden TI yang yang sesuai dengan kerangka kerja ITIL 2011.

0.3. Batasan Masalah Dalam melakukan penelitian tesis ini, penulis menentukan beberapa ruang lingkup yang dibahas, diantaranya: 1.

Manajemen insiden dilakukan hanya untuk insiden Teknologi Informasi terhadap divisi Group Strategic Information Technology (GSIT).

2.

Manajemen insiden dilakukan terhadap dua lokasi data center, Jakarta dan Surabaya (Disaster Recovery Center).

3

0.4. Tujuan Penelitian Berdasarkan permasalahan yang ada, maka tujuan dari dilakukannya penelitian diantaranya adalah: 1.

Untuk mengidentifikasi gap antara tata kelola manajemen insiden yang ada saat ini dengan tata kelola manajemen insiden TI yang diharapkan.

2.

Merancang tata kelola manajemen insiden sesuai dengan kerangka kerja (framework) TI yang ada, dengan menggunakan kerangka kerja ITIL 2011.

0.5. Manfaat Penelitian Penelitian ini diharapkan dapat memberikan manfaat bagi perusahaan. Manfaat penelitian yang dapat diambil oleh perusahaan, diantaranya: 1.

Dapat memberikan panduan tata kelola manajemen insiden TI yang dibutuhkan perusahaan, yang dapat digunakan sebagai acuan bagi perusahaan dalam mengelola insiden secara menyeluruh di masa yang akan datang.

2.

Membantu

meningkatkan

efektifitas

penanganan

insiden

demi

keberlangsungan layanan TI di perusahaan.

0.6. Sistematika Penulisan Dalam penyusunan tesis ini, digunakan sistematika penulisan sebagai berikut:

BAB I

PENDAHULUAN Bab ini menjelaskan latar belakang masalah tata kelola manajemen insiden TI di PT Bank ABC, serta perumusan masalah, batasan masalah, tujuan penelitian, manfaat penelitian, dan sistematika penulisan tesis ini.

BAB II

KAJIAN PUSTAKA Bab ini berisi bahan studi literatur mengenai proses manajemen insiden TI berdasarkan kerangka kerja ITIL 2011 yang digunakan dalam penyelesaian permasalahan tesis ini.

4

BAB III

METODOLOGI PENELITIAN Bab ini menjelaskan metodologi dan tahapan-tahapan yang digunakan penulis dalam menyusun tesis ini. Diantaranya pengumpulan informasi dan analisa, penilaian tingkat kematangan, perancangan dokumen tata kelola, verifikasi dokumen tata kelola, validasi dokumen tata kelola dan kesimpulan. Tahapan ini dilakukan di lingkungan IIO dari divisi GSIT PT Bank ABC.

BAB IV

ANALISA DAN PEMBAHASAN Bab ini membahas penjelasan analisa data hasil penelitian yang didapat dari perusahaan yang dikelola menggunakan framework ITIL 2011. Bab ini juga terdapat profil perusahaan, proses bisnis, struktur organisasi TI di PT Bank ABC.

BAB V

DESAIN DOKUMEN TATA KELOLA Bab ini menampilkan hasil perancangan dokumen tata kelola manajemen insiden pada divisi Group Strategic Information Technology (GSIT) di PT Bank ABC, berdasarkan framework ITIL 2011.

BAB VI

KESIMPULAN DAN SARAN Bab ini berisi kesimpulan dan saran yang didapat dari hasil penelitian yang telah dilakukan.

5

6

BAB 2 KAJIAN PUSTAKA Pada bab ini akan dijelaskan lebih lanjut mengenai kajian pustaka yang digunakan sebagai referensi dalam penelitian Perancangan Tata Kelola Manajemen Insiden TI berdasarkan kerangka kerja ITIL 2011 yang dilakukan pada divisi Group Strategic Information Technology (GSIT) di PT Bank ABC. Adapun secara garis besar, beberapa referensi yang dibahas diantaranya: 1.

Proses Manajemen Insiden (existing)

2.

Tata Kelola 2.1. Tata Kelola TI

3.

Incident Management Framework

4.

Framework ITIL 4.1. Service Strategy 4.2. Service Design 4.3. Service Transition 4.4. Service Operation 4.5. Continual Service Improvement

5.

Perbandingan ITIL v2 2007 dan ITIL v3 2011

6.

Proses Manajemen Insiden (ITIL 2011)

7.

Responsibility Assignment Matrix (RAM)

Berikut ini merupakan penjelasan lebih lanjut mengenai pustaka yang digunakan dalam penelitian ini.

2.1. Proses Manajemen Insiden (existing) Manajemen Insiden adalah sebuah proses formal yang telah disiapkan untuk diikuti oleh staff helpdesk untuk menerima dan menerjemahkan insiden sebuah masalah, kemudian untuk mendapatkan informasi yang diminta oleh atau untuk menyelesaikan permasalah yang dimiliki oleh , sampai pada akhirnya menutup insiden tersebut. (Beisse, 2014)

7

Proses manajemen insiden yang dimiliki oleh PT Bank ABC, khususnya divisi GSIT, telah digunakan dalam operasional data center hingga saat ini. Panduan mengenai proses tersebut terdapat pada dokumen Panduan Operasional Data Center, dengan bab Panduan Pengelolaan Incident. Hingga saat ini, panduan proses tersebut telah diperbaharui dengan versi terakhir yaitu versi 5 yang terbit bulan Agustus 2014. Proses manajemen insiden TI saat ini meliputi proses pengelolaan insiden, pelaporan insiden, pencatatan insiden, tindak lanjut, monitoring, dan laporan. Saat ini yang bertanggung jawab atas pengelolaan insiden TI yang berhubungan dengan operasional Data Center adalah helpdesk, system operator, shift leader, dan group leader.

Insiden Terjadi

Pelaporan insiden

Pencatatan insiden

Tindak lanjut insiden

Monitoring Insiden

Laporan

Gambar 2.1 Alur Manajemen Insiden TI

Dari Gambar 2.1 Alur Manajemen Insiden TI di atas, dapat dijelaskan bahwa saat ini proses manajemen insiden dimulai dari munculnya insiden yang terjadi pada operasional Data Center (DC). Insiden yang muncul dapat bersifat gangguan fisik maupun non fisik, serta dapat dilakukan secara di sengaja maupun tidak di sengaja oleh siapapun. Setiap terjadinya insiden tersebut, ataupun pengguna aplikasi atau sistem akan melaporkan kepada bagian helpdesk bahwa terjadi gangguan disisi aplikasi atau sistem. yang dimaksud dapat berupa staff yang berada di cabang, yaitu sebagai pelanggan dari sistem yang dikelola oleh GSIT, serta dapat pula dimaksud sebagai nasabah PT Bank ABC yang merupakan pengguna dari

8

aplikasi yang dapat diakses oleh nasabah itu sendiri. Laporan dari nasabah tersebut tidak langsung diterima oleh helpdesk, melainkan dari divisi lain sebagai call center yang merupakan bagian dari single of yang dimiliki oleh perusahaan terhadap nasabah. Disamping , terdapat pula PIC (person in charge) atau penanggung jawab aplikasi yang dapat melaporkan gangguan yang telah ditemukannya kepada helpdesk. Setelah diterima laporan bahwa terjadinya gangguan, selanjutnya yang dilakukan adalah proses pencatatan insiden yang dilakukan oleh System Operator. Proses pencatatan insiden dilakukan secara terpusat dengan menggunakan sistem terintegrasi, sehingga meminimalisir terjadi redudansi pencatatan insiden. Selanjutnya, setelah dilakukan pencatatan, maka yang dilakukan adalah proses eskalasi insiden. Proses eskalasi insiden yang dimaksud yaitu proses penyampaian/tindak lanjut insiden kepada pihak-pihak yang berkepentingan agar dilakukan penyelesaian terkait masalah yang sedang terjadi. Eskalasi yang dilakukan dapat langsung kepada PIC yang bersangkutan, maupun dilakukan sendiri oleh System Operator sesuai panduan yang telah diberikan oleh PIC. Pada proses tersebut, maka dilakukan monitoring terhadap proses penyelesaiaan insiden yang terjadi. Apabila proses penyelesaiaan insiden yang dilakukan pada proses eskalasi sebelumnya telah selesai, maka selanjutnya yang dilakukan adalah proses penutupan pelaporan insiden. Proses penutupan laporan insiden dilakukan sebagai pertanda bahwa insiden yang terjadi telah selesai dilakukan solving problem dan dinyatakan case closed. Selanjutnya dari seluruh laporan insiden yang yang telah ditutup, maka dilakukan evaluasi terhadap laporan yang pernah dibuat. Proses evaluasi dilakukan untuk menganalisa insiden yang pernah terjadi agar dikemudian hari tidak sampai terjadi kembali (proses pencegahan). Dalam setiap penyelesaian insiden, memerlukan beberapa solusi yang melibatkan berbagai unit kerja. Penyelesaian insiden tersebut terkadang membutuhkan solusi yang sangat secure dan private, mulai dari peminjaman kunci, hingga akses tertentu. Pada divisi GSIT, proses tersebut dikelola terpusat oleh sub divisi Enterprise Security. Dimana proses tersebut dilakukan secara berlapis pada tiap unit kerja. Proses ini dilakukan baik untuk kebutuhan 9

operasional, hingga kebutuhan disaster. Hanya pihak-pihak yang berkepentingan yang dapat diberikan tugas oleh masing-masing unit kerja. Pembagian tanggung jawab tersebut diberikan berbeda-beda pada tiap unit kerja / sub divisi. Berikut ini merupakan contoh data insiden yang dimiliki oleh PT. Bank ABC, Tbk yang terjadi selama sebulan. Dari data pada Tabel 2.1 dibawah ini menunjukkan bahwa total insiden TI yang terjadi selama bulan Agustus 2015 yaitu berjumlah 2044 insiden TI. Sebanyak 2038 insiden telah dinyatakan tertangani dengan baik (resolved), dimana sebanyak 958 insiden diselesaikan oleh helpdesk dan 1087 insiden ditangani oleh bagian . Selain itu terdapat 6 insiden dinyatakan berstatus open, yaitu insiden yang masih dalam proses penanganan secara parallel oleh tim terkait. Insiden yang masih memiliki status open biasanya merupakan insiden besar (major incident).

Tabel 2.1 Data Statistik Insiden TI Agustus 2015

Selain contoh data statistik pada bulan agustus 2015, juga terdapat ringkasan data statistik yang disajikan selama bulan Januari 2015 hingga Agustus 2015. Data tersebut disajikan pada Tabel 2.2 dibawah ini. Dapat dilihat bahwa insiden yang terjadi banyak terdapat pada bulan Mei 2015, dengan total 2691 insiden TI, dimana 2689 insiden TI telah dinyatakan selesai penanganannya, dan sisanya 2 insiden TI masih dalam proses penyelesaiaan (status open). Pada rentan waktu tersebut, bulan Februari hingga April 2015 tidak ditemukan insiden yang belum terselesaikan (0 insiden berstatus open).

10

Tabel 2.2 Statistik Incident Log

Berikut ini merupakan contoh data statistik 5 kategori insiden teratas yang sering terjadi pada bulan Agustus 2015. Kategori insiden Router / VSAT / MPLS berada di paling atas dengan jumlah 221 kasus insiden yang sering terjadi. Selanjutnya ada insiden Tivoli Backup sebanyak 189 kasus insiden, KOT sebanyak 126 insiden TI, BDS-IDS sebanyak 111 insiden dan terakhir Base24 ATM sebanyak 66 kasus insiden TI.

Gambar 2.2 Top 5 Incident Agustus 2015 11

2.2. Tata Kelola Dalam perspektif umum, tata kelola (governance) adalah kemampuan pemerintah (goverment) untuk membuat dan menegakkan aturan, dan untuk memberikan layanan, terlepas pemerintah tersebut apakah demokratis ataupun tidak. (Fukuyama, 2013). Secara teoritis, tata kelola adalah sebuah proses dari pemerintahan (governing). (Bevir, 2012). Hal ini terkait apa yang pemerintah lakukan sebagai seorang warga. Namun, ini juga dapat dilakukan oleh sebuah perusahaan ataupun organisasi terhadap karyawan dan anggotanya.

2.2.1. Tata Kelola TI Tata kelola TI adalah kumpulan dari manajemen, perencanaan, kebijakan penilaian kinerja, proses dan penerapan; terkait dengan hak keputusan, yang membangun kewenangan, kendali, dan ukuran kinerja terhadap investasi, perencanaan, anggaran belanja, komitmen, layanan, perubahan besar, keamanan, privasi, keberlangsungan bisnis dan sesuai dengan hukum dan kebijakan organisasi. (Selig, 2008) Definisi lain yang diadopsi dari The Organization of Economic CoOperation and Development (OECD) mengenai tata kelola perusahaan, menjelaskan bahwa tata kelola TI adalah sebuah sistem dimana TI pada perusahaan diarahkan dan dikendalikan. (Brand, 2009). Struktur tata kelola TI menjelaskan pembagian hak dan tanggung jawab diantara partisipan, seperti direksi, manajer IT dan bisnis, dan memberikan aturan dan prosedur untuk membuat keputusan pada TI. Menurut Dr Gad J Selig PMP COP (2008), tujuan dari tata kelola TI diantaranya adalah: 

Menghubungkan antara investasi dan prioritas TI lebih dekat dengan bisnis perusahaan



Mengelola, mengevaluasi, memprioritaskan, mendanai, mengukur dan memantau permintaan untuk layanan TI, dan menghasilkan pekerjaan dan penyampaian, lebih konsisten dan dengan cara teratur yang dapat mengoptimalkan bisnis 12

 Mengelola sumberdaya dan asset yang dimiliki  Menyusun dan menerangkan akuntabilitas

dan hak memutuskan

(secara jelas mendefinisikan peran dan kewenangan)  Memastikan

bahwa

penyampaian

TI

sesuai

dengan

yang

direncanakan, dianggarkan, dan sesuai dengan komitmen yang ada  Mengelola resiko besar, ancaman, perubahan dan kontijensi secara proaktif  Meningkatkan kinerja TI organisasi, penyesuaian, kematangan, pengembangan karyawan, dan inisiatif outsourcing  Meningkatkan voice of the customer (VOC), manajemen permintaan dan keseluruhan kepuasan dan tanggapan dari pelanggan  Mengelola dan berpikir secara global, namun bertindak secara lokal  Unggul dalam inovasi yang sejalan dengan fungsi TI dan bisnis Dalam penerapan tata kelola TI, ada beberapa hal mendasar yang perlu dilakukan agar dapat terlaksana dengan baik, diantaranya diperlukan dukungan dan perintah dari pimpinan teratas, adanya sumberdaya yang mendukung, dilakukan sendiri, mampu memberikan manfaat bagi organisasi, memberikan dukungan teknologi dalam inisiatif tata kelola TI. Tata kelola TI dari setiap organisasi dibebaskan sesuai dengan kebutuhan masing-masing. Dalam proses implementasinya, sebuah tata kelola TI dapat terdiri dari beragam struktur, proses, dan mekanisme rasional. Jika ketiga hal ini dikombinasikan, maka hasilnya adalah berupa kerangka kerja tata kelola TI. Dalam pengembangan tata kelola TI di berbagai organisasi, terdapat berbagai framework tata kelola TI yang dapat digunakan sebagai acuan. Framework tata kelola TI tersebut diantaranya, COBIT 5 (Control Objectives for Information and Related Technology), ITIL v3 2011 Edition (Information Technology Infrastructure Library), ISO/IEC 38500:2008, ISO 17799 / ISO 27000 series, ISO/IEC 20000, CMMI/SPICE (ISO/IEC 15504), Balanced Scorecard, dan AS 8015-2005. Untuk menunjang penelitian mengenai tata kelola manajemen insiden TI, maka digunakan ITIL v3 2011 Edition sebagai framework pendukung.

13

2.3. Incident Management Framework Manajemen insiden menyediakan proses, tools, dan konsep dalam pemulihan kualitas layanan yang cepat pada layanan tertentu. Hal ini berkaitan dengan isu-isu layanan, dan dengan layanan lainnya dan permintaan yang disimpan oleh service desk. Hal ini juga memantau kelengkapan permintaan yang dilakukan oleh service desk atau oleh pihak unit lainnya. Pada akhirnya, manajemen insiden memiliki tugas untuk menginformasikan pemohon layanan terhadap status layanan yang diminta. Tujuan utama dari proses manajemen insiden adalah untuk memulihkan layanan operasional, secepat mungkin, setelah insiden terdeteksi atau tercatat. Manajemen insiden berkontribusi terhadap penerapan manajemen layanan yang terintegrasi dengan memenuhi sasaran berikut:  Setiap insiden dan data yang dibutuhkan dicatat.  Setiap insiden berjalan dalam kumpulan standard aktivitas dan prosedur, yang bertujuan untuk meyakinkan keefektifan dan keefisiensian sebuah proses.  Setiap insiden dikategorikan dan diprioritaskan berdasarkan potensi dampak dan

tingkat

mendesaknya,

yang

berguna

untuk

menjadwalkan

penyelesaiaannya dalam cara orientasi bisnis.  Prosedur fungsional dan hierarki eskalasi telah ada untuk memastikan setiap insiden diivestigasi oleh staf yang berkompeten, baik dari internal maupun eksternal.  Level dari fungsi eskalasi yang baik memastikan bahwa seluruh insiden ditangani dengan cara yang efisien dan dan keahlian tersebut dijauhkan dari aktivitas diagnosa dan penyelesaian non-expert . Proses manajemen insiden terdapat dalam beberapa kerangka kerja (framework) yang populer di dunia. Beberapa peneliti dan perusahaan menggunakan framework ini untuk mengimplementasikannya dalam proses bisnis perusahaan. Berikut ini framework yang populer dalam proses manajemen insiden: 

ISO / IEC 20000, proses manajemen insiden terdapat pada bagian “Resolution Processes”

14



COBIT, proses manajemen insiden terdapat pada bagian “Deliver and ”



ITIL V2, proses manajemen insiden terdapat pada bagian “Service ”



ITIL V3, proses manajemen insiden terdapat pada bagian “Service Operation”

2.4. Framework ITIL Dalam penelitian ini, perancangan tata kelola manajemen insiden TI pada divisi GSIT PT Bank ABC, Tbk, menggunakan kerangka kerja (framework) ITIL 2011. Penggunaan framework ini dilakukan karena sifatnya yang best practice terhadap cara-cara pengelolaan IT untuk mencapai obyektif organisasi. ITIL atau Information Technology Infrastructure Library adalah suatu pendekatan sistematis yang berguna untuk menyampaikan kualitas dari layanan TI, yang menyediakan penjelasan secara detil dari proses-proses penting pada sebuah organisasi, termasuk mengenai prosedur, tugas, peran dan tanggungjawab (Bernard, 2012). Saat ini, perkembangan terakhir ITIL berada pada edisi 2011. ITIL 2011 pada dasarnya bukan merupakan versi baru dari perkembangan sejarah framework ITIL, melainkan merupakan versi pembaharuan dari ITIL V3 2007. Beberapa pakar menyebut ITIL 2011 dengan “ITIL” atau juga dengan “ITIL V3 2011 Edition”. (it-processmaps.com, 2015) Pada ITIL 2011, tahapan-tahapan pengelolaan manajemen TI secara garis besar sama dengan ITIL V3, yaitu terdapat 5 proses service lifecycle. Pada gambar 2.1 menunjukkan service lifecycle dari framework ITIL 2011.

15

Gambar 2.3 Service Lifecycle framework ITIL 2011

Adapun penjelasan secara garis besar terhadap 5 proses service lifecycle dari framework ITIL 2011 tersebut adalah sebagai berikut: 1. Service Strategy Proses ini ditujukan untuk menentukan strategi guna melayani pelanggan. Dimulai dari penilaian kebutuhan pelanggan dan pasar, proses service strategy menentukan layanan TI yang akan diberikan oleh perusahaan dan

kemampuan apa yang perlu dikembangkan

untuk mencapainya. Tujuan utama dari proses ini adalah untuk membuat perusahaan berpikir dan bertindak dengan menggunakan strategi. 2. Service Design Proses ini ditujukan untuk merancang layanan TI baru. Ruang lingkup proses ini termasuk

mendesain layanan baru, serta

perubahan dan perbaikan dari layanan yang telah ada sebelumnya. 3. Service Transition Proses ini ditujukan untuk membangun dan mengimplementasikan layanan TI. Service Transition juga memastikan bahwa perubahan terhadap layanan dan proses manajemen layanan dilakukan dengan cara yang terkoordinasi. 16

4. Service Operation Proses ini ditujukan untuk memastikan bahwa layanan telah tersampaikan dan dijalankan secara efektif dan efisien. Proses service operation termasuk pemenuhan permintaan , penyelesaian kegagalan layanan, perbaikan masalah, serta melaksanakan tugastugas operasional rutin. 5. Continual Service Improvement Proses ini ditujukan untuk menggunakan metode dari manajemen kualitas guna mempelajari atas kesuksesan dan kegagalan yang pernah terjadi dimasa lalu. Proses Continual Service Improvement bertujuan untuk terus meningkatkan efetifitas dan efisiensi dari layanan dan proses TI, hal ini sejalan dengan konsep dari continual improvement yang diadopsi dari ISO 20000.

2.4.1. Service Strategy Tujuan ITIL Service Strategy adalah untuk menentukan jenis layanan mana yang seharusnya diberikan kepada pelanggan ataupun pasar. Berikut ini merupakan proses-proses utama yang menjadi bagian dari service strategy. Bagan alur dari proses ini dapat dilihat pada Gambar 2.2. ITIL Service Strategy. 

Strategy Management for IT Services Proses ini ditujukan untuk menilai layanan, kemampuan dan pesaing dari penyedia layanan saat ini dan potensi pangsa pasar guna mengembangkan strategi untuk melayani pelanggan. Setelah strategi ditetapkan, Strategy Management for IT Services juga bertanggung jawab dalam memastikan pelaksanaan strategi.



Service Portfolio Management Proses ini ditujukan untuk mengelola portofolio layanan yang dimiliki. Service Portfolio Management memastikan bahwa penyedia layanan memiliki beragam layanan untuk memenuhi kebutuhan bisnis pada tingkat yang sesuai investasi.

17



Financial Management for IT Services Proses ini ditujukan untuk mengelola penganggaran, akutansi, dan pengambilan persyaratan dari penyedia layanan.



Demand Management Proses ini ditujukan untuk memahami, mengantisipasi dan mempengaruhi permintaan pelanggan terhadap layanan. Management Demand bekeja bersama Capacity Management untuk memastikan bahwa penyedia layanan mempunyai kapasitas yang cukup untuk memenuhi kebutuhan.



Business Relationship Management Proses ini bertujuan untuk menjaga hubungan baik dengan pelanggan. Business Relationship Management mengidentifikasi kebutuhanpelanggan saat ini (existing) dan pelanggan yang potensial serta memastikan bahwa layanan sesuai dengan yang dikembangkan untuk memenuhi kebutuhan tersebut.

Gambar 2.4 ITIL Service Strategy 18

2.4.2. Service Design Tujuan dari proses ini adalah untuk mendesain layanan TI baru. Service design mengidenifikasi kebutuhan layanan dan merancang layanan baru serta mengubah dan mengembangkan layanan yang telah ada sebelumnya. Berikut ini merupakan proses utama dari service design yang digambarkan pada Gambar 2.3. ITIL Service Design. 

Design Coordination Proses ini ditujukan untuk mengkoordinasikan seluruh aktivitas, proses dan sumber daya dari service design. Design Coordination memastikan konsistensi dan efektifitas desain dari layanan TI yang baru ataupun yang telah diubah, layanan sistem informasi manajemen, arsitektur, teknologi, proses, information dan metrik.



Service Catalogue Management Proses ini ditujukan untuk memastikan bahwa Service Catalogue diproduksi dan dipelihara, yang berisi informasi akurat pada seluruh layanan operasional dan hal ini dipersiapkan sebagai operasional.



Service Level Management Proses ini bertujuan untuk menegosiasikan Service Level Agreement dengan pelanggan dan untuk merancang layanan sesuai dengan target service level yang disepakati.



Risk Management Proses ini bertujuan untuk mengidentifikasi, menilai, dan mengontrol resiko.



Capacity Management Proses ini bertujuan untuk memastikan kapasitas layanan dan infrastruktur TI mampu untuk memberikan target tingkat layanan yang disepakati dengan biaya dan waktu yang efektif.



Availability Management Proses ini bertujuan untuk menentukan, menganalisa, merencanakan, mengukur dan meningkatkan seluruh aspek dari ketersediaan layanan TI.

19



IT Service Continuity Management Proses ini bertujuan untuk mengelola resiko yang serius yang dapat berdampak pada layanan TI.



Information Security Management Proses ini bertujuan memastikan kerahasiaan, integritas dan ketersediaan dari informasi organisasi, data dan layanan TI.



Compliance Management Proses ini bertujuan untuk memastikan layanan TI, proses dan sistem mematuhi kebijakan perusahaan dan persyaratan hukum.



Architecture Management Proses ini bertujuan untuk menentukan cetak biru untuk pengembangan masa depan dari teknologi, dengan mempertimbangkan strategi layanan dan teknologi baru yang tersedia.



Supplier Management Proses ini bertujuan untuk memastikan bahwa seluruh kontrak dengan supplier mendukung kebutuhan bisnis, dan seluruh supplier memenuhi komitmen kontrak mereka.

20

Gambar 2.5 ITIL Service Design

2.4.3. Service Transition Tujuan dari ITIL Service Transition adalah untuk membangun dan mengimplementasikan layanan TI. Service Transition juga memastikan bahwa perubahan pada layanan dan proses Service Management dijalankan secara terkoordinasi. Berikut ini merupakan proses utama dari Service Trasition yang tergambarkan pada Gambar 2.4 ITIL Service Transition.

21



Change Management Proses ini bertujuan untuk mengontrol siklus dari seluruh perubahan yang terjadi.



Change Evaluation Proses ini bertujuan untuk menilai perubahan mayor, seperti pengenalan layanan baru atau perubahan substansial dari layanan yang telah ada, sebelum perubahan tersebut diijinkan untuk diproses ke tahap selanjutnya.



Project Management Proses ini bertujuan untuk merencanakan dan mengkoordinasikan kebutuhan untuk implementasi dari perubahan mayor yang ada dengan biaya, waktu, kualitas yang terukur.



Application Development Bertujuan untuk membuat aplikasi dan sistem yang menyediakan kebutuhan fungsional dari layanan TI.



Release and Deployment Management Proses

ini

bertujuan

untuk

merencanakan,

menjadwalkan

dan

mengendalikan rilis dari versi percobaan dan akhir. 

Service Validation and Testing Proses ini bertujuan untuk memastikan implementasi dapat memenuhi kebutuhan dari pelanggan, dan untuk memverifikasi operasi TI dapat mendukung layanan yang baru.



Service Asset and Configuration Management Proses ini bertujuan untuk menjaga informasi mengenai konfigurasi yang dibutuhkan dalam penyampaian layanan TI.



Knowledge Management Proses ini bertujuan untuk mengumpulkan, menganalisa, menyimpan dan membagikan informasi mengenai perusahaan.

22

Gambar 2.6 ITIL Service Transition

2.4.4. Service Operation Tujuan dari ITIL Service Operation adalah untuk memastikan layanan TI tersampaikan secara efektif dan efisien. Berikut ini proses utama dari Service Operation yang dapat digambarkan pada Gambar 2.5 ITIL Service Operation.

23



Event Management Proses ini untuk memastikan CI (Configuration Item) dan layanan secara konsisten dipantau, dan untuk menyaring dan mengelompokkan Events untuk tujuan memutuskan aksi yang tepat.



Incident Management Proses ini bertujuan untuk mengelola siklus dari seluruh insiden. Tujuan utama dari manajemen insiden adalah untuk membantu mengembalikan layanan TI kepada pemiliknya secepat mungkin.



Request Fulfillment Bertujuan untuk mengisi Service Requests, dimana kasus yang sering terjadi adalah perubahan minor atau sekedar permintaan informasi.



Access Management Proses ini bertujuan untuk memberikan ijin kepada terhadap sebuah layanan, untuk mencegah akses dari yang tidak diijinkan.



Problem Management Proses ini bertujuan untuk mengelola seluruh masalah yang ada. Tujuan utamanya adalah untuk mencegah sebuah insiden muncul, dan untuk meminimalisir dampak dari munculnya insiden yang tidak dapat dicegah sebelumnya.



IT Operations Control Untuk mengelola dan memantau layanan TI dan seluruh infrastruktur yang berkaitan dengannya.



Facilities Management Untuk mengelola seluruh sumberdaya fisik dimana infrastruktur TI itu berada.



Application Management Bertanggung jawab dalam mengelola seluruh aplikasi yang terlibat.



Technical Management Menyediakan tenaga yang handal dan mendukung dalam pengelolaan infrastruktur TI.

24

Gambar 2.7 ITIL Service Operation

25

2.4.5. Continual Service Improvement Tujuan dari ITIL Continual Service Improvement adalah untuk mempelajari sistem yang baik dan tidak baik yang terjadi di masa lampau. CSI bertujuan untuk meningkatkan efektivitas dan efisien dari layanan dan proses TI. Berikut ini proses utama dari Continual Service Improvement yang dapat digambarkan pada Gambar 2.6 ITIL Continual Service Improvement.

Gambar 2.8 ITIL Continual Service Improvement



Service Review Untuk mereview layanan bisnis dan layanan infrastruktur yang manjadi bagian utama.



Process Evaluation Untuk mengevaluasi proses-proses yang terjadi.

26



Definition of CSI Initiatives Untuk

mendefinisikan inisasitif spesifik

dalam

meningkatkan

pelayanan dan proses-proses yang ada berdasarkan hasil dari service review dan process evaluation. 

Monitoring of CSI Initiatives Untuk memverifikasi jika pengembangkan inisiatif diproses sesuai rencana, dan untuk mengenalkan penilaian yang benar jika dibutuhkan.

2.5. Perbandingan ITIL v2 2007 dan ITIL v3 2011 Framework ITIL 2011 pada dasarnya mengalami sedikit perubahan. Tidak ditemukan konsep baru yang signifikan terkait dengan perubahan versi dari ITIL v2 2007 menjadi ITIL v3 2011. Terdapat sedikit proses baru yang lebih menjelaskan detail dari setiap proses yang ada. Berbeda dengan perubahan yang besar, pada ITIL 2011 terdiri dari klarifikasi dan penajaman terhadap seluruh bagian proses yang ada. Khusus pada proses manajemen insiden, pada ITIL 2011 mengalami beberapa perubahan. Pada versi sebelumnya, proses manajemen insiden dilakukan pada proses “Service ”, namun kali ini manajemen insiden dipisahkan dan ditempatkan pada proses “Service Operation”. Berikut ringkasan perubahan / penambahan yang terdapat pada subproses Incident Management:

Tabel 2.3 Perbandingan Incident Management pada ITIL v2 dan ITIL v3 Keterangan

ITIL v2 (2007 edition)

ITIL v3 (2011 edition)

Bagian dari

Service

Service Operation

Nama Proses

Service Desk and Incident Management

Incident Management

Sub-Processes

- Incident - Process Service Request - Monitoring Escalate Incident

- Incident Management - Incident Logging and Categorization - Immediate Incident

27

- Pro-actively Inform s - Immediate Incident Resolution by 1st Level - Analyse and Resolve Incident in 2nd Level - Close and Evaluate Incident - Carry out Incident Management Reporting - Maintenance of Knowledge Base Pihak yang terlibat

-

Incident Manager 1st Level 2nd Level 3rd Level

-

-

Resolution by 1st Level Incident Resolution by 2nd Level Handling of Major Incidents Incident Monitoring and Escalation Incident Closure and Evaluate Pro-Active Information Incident Management Reporting

Incident Manager 1st Level 2nd Level 3rd Level Major Incident Team

Selain perbandingan incident management antara ITIL v2 (2007 edition) dan ITIL v3 (2011 edition) diatas, juga terdapat ringkasan kesimpulan mengenai kedua versi ITIL diatas terhadap sub-proses incident management, berikut ringkasannya:  Pada dasarnya, kegiatan dan tujuan proses dari proses Manajemen Insiden memiliki kesamaan diatara ITIL v2 dan ITIL v3  ITIL v3 membedakan antara Insiden (Layanan Interupsi) dan Permintaan Layanan (permintaan standar dari pengguna, misalnya reset )  Permintaan Layanan tidak lagi dipenuhi oleh Manajemen Insiden; melainkan adanya proses baru yang disebut “Request Fulfilment”  Terdapat proses yang diperuntukkan untuk menghadap situasi darurat (“Major Incidents”)  Sebuah tampilan proses telah ditambahkan antara Event Management dan Incident Management. Kejadian yang penting saat ini dapat menyebabkan dibuatnya sebuah insiden.

28

2.6. Proses Manajemen Insiden (ITIL 2011) Yang membedakan manajemen insiden menurut ITIL V3 2011, yaitu antara Insiden (gangguan layanan) dan Permintaan Layanan (permintaan standar dari , seperti reset ). Permintaan Layanan tidak selamanya diisi oleh Incident Management; itulah kenapa terdapat proses baru yang disebut Request Fulfillment. Pada ITIL 2011, insiden (incident) didefinisikan sebagai sebuah gangguan yang tidak direncanakan terhadap layanan TI atau mengurangi kualitas dari layanan TI itu sendiri. (www.wikipedia.org) Sebuah gangguan terhadap konfigurasi yang tidak berdampak terhadap layanan juga dapat dikategorikan sebagai sebuah insiden. Panduan

untuk

Incident

Management

pada

ITIL

2011

telah

dikembangkan pada bagaimana memprioritaskan sebuah insiden. Tahapan baru telah ditambahkan pada Incident Resolution oleh 1st Level untuk menjelaskan bahwa insiden harus sesuai dengan Problem and Known Errors.

29

Gambar 2.9 Sub Proses Incident Management

Pada proses Incident Management, terdapat 9 sub-proses yang mendukung proses ini, diantaranya:  Incident Management Untuk menyediakan dan memelihara alat, proses, keterampilan dan aturan untuk penanganan insiden yang efektif dan efisien.  Incident Logging and Categorization Untuk merekam dan memprioritaskan insiden dengan ketelitian yang tepat, guna mendapatkan solusi secara cepat dan efektif.

30

 Immediate Incident Resolution by 1st Level Untuk menyelesaikan sebuah insiden (gangguan layanan) dengan waktu yang telah disetujui.  Incident Resolution by 2nd Level Untuk menyelesaikan insiden (gangguan layanan) dengan waktu yang telah disetujui.  Handling of Major Incidents Untuk menyelesaikan insiden mayor.  Incident Monitoring and Escalation Secara berlanjut memantau dan memproses status dari insiden yang berlangsung.  Incident Closure and Evaluation Untuk memberikan catatan insiden kepada kendali kualitas sebelum insiden tersebut ditutup.  Pro-active Information Untuk menginformasikan terhadap kegagalan layanan sesegera mungkin sesuai dengn yang diketahui oleh Service Desk.  Incident Management Reporting Untuk memberikan informasi insiden yang berkaitan untuk proses Service Management, dan untuk memastikan pengembangan yang potensial dari insiden-insiden sebelumnya. Berdasarkan UCISA (Universities and Colleges Information System Association - www.ucisa.ac.uk) dari Universitas Oxford, proses penilaian incident management dilakukan dengan menggunakan 4 Service Operation area, diantaranya “The Incident Management Process”, “Activities in Place needed for the Success of Incident Management”, “Incident Management Metrics”, dan “Incident Management Process Interactions”. Berikut ini merupakan gambar alur proses implementasi dari incident management yang tergambar pada Gambar 2.9.

31

Gambar 2.10 Alur Proses Implementasi Incident Management

2.7. Responsibility Assignment Matrix (RAM) Responsibility Assignment Matrix (RAM) juga dikenal sebagai RACI matrix atau ARCI matrix atau Linear Responsibility Chart (LRC). RACI menggambarkan partisipasi dari bermacam-macam peran dalam menyelesaikan sebuah pekerjaan atau tugas dalam sebuah proyek atau bisnis proses. RACI atau ARCI merupakan akronim dari 4 kunci tanggungjawab, diantaranya: Responsible, able, Consulted, Informed. Seperti yang telah dijelaskan sebelumnya, terdapat 9 sub-proses yang dimiliki oleh proses Incident Management, berikut ini adalah responsibility matrix dari sub proses yang dimaksud.

32

Helpdesk

System Operator

Shift Leader

Group Leader

DC Manager

Grup PIC

Manager Grup PIC

Tabel 2.4 RACI Matrix ITIL Incident Management

Incident Management

R

R

AR

-

-

-

-

Incident Logging and Categorization

R

AR

-

-

-

-

-

Immediate Incident Resolution by 1st Level

R

AR

-

-

-

-

-

Incident Resolution by 2nd Level

-

-

-

-

-

AR

-

Handling of Major Incidents

-

R

-

-

-

R

AR

Incident Monitoring and Escalation

-

R

AR

-

-

-

-

Incident Closure and Evaluation

R

AR

C

-

-

-

-

Pro-active Information

R

AR

C

-

-

-

-

Incident Management Reporting

-

-

R

AR

I

-

-

Sub Process

Pada penelitian ini, terdapat 7 pelaku yang terlibat secara langsung maupun tidak langsung dalam proses Incident Management, diantaranya Helpdesk, System Operator, Shift Leader, Group Leader, DC Manager, Group PIC, Manager Group PIC. Dari ketujuh pelaku tersebut, 5 diantaranya merupakan pelaku yang terlibat langsung dalam proses Incident Management yang dikelola oleh divisi IT Infrastructure and Operation Management (IIO), sedangkan 2 lainnya, yaitu Grup PIC dan Manager Grup PIC, merupakan pihak yang melakukan kerjasama dalam penanganan insiden yang terjadi pada divisi Group Strategic Information Technology (GSIT).

33

34

BAB 3 METODOLOGI PENELITIAN Pada bab ini akan dijelaskan lebih lanjut mengenai tahapan-tahapan penelitian yang akan digunakan dalam Perancangan Tata Kelola Manajemen Insiden TI berdasarkan kerangka kerja ITIL 2011 pada divisi Group Strategic Information Technology (GSIT) di PT Bank ABC. Adapun secara garis besar, tahapan-tahapan tersebut diantaranya: 1.

Pengumpulan Informasi dan Analisa

2.

Penilaian Tingkat Kematangan

3.

Perancangan Dokumen Tata Kelola

4.

Verifikasi Dokumen Tata Kelola

5.

Validasi Dokumen Tata Kelola

6.

Kesimpulan

Berikut ini merupakan gambar alur tahapan-tahapan metodologi penelitian yang digunakan dalam proses penelitian ini. Pengumpulan Informasi dan Analisa Kajian dokumen

Wawancara

Kuesioner

Observasi

Studi Literatur

Penilaian Tingkat Kematangan Current vs Target

Maturity Level Assessment

Gap Analysis ITIL 2011

Perancangan Dokumen Tata Kelola Revised existing document

Define new document

Verifikasi Dokumen Tata Kelola Membandingkan dokumen existing dan dokumen hasil perancangan

Review aktifitas dalam dokumen

Validasi Dokumen Tata Kelola Kesimpulan

Gambar 3.1 Metodologi Penelitian 35

3.1. Pengumpulan Informasi dan Analisa Pada tahap ini, dilakukan pengumpulan informasi mengenai proses manajemen insiden TI yang terdapat pada divisi GSIT. Proses pemahaman tersebut dilakukan terhadap seluruh pedoman manajemen insiden TI yang dimiliki saat ini. Apabila diperlukan, maka akan dilakukan beberapa proses analisa melalui kajian dokumen, wawancara, serta observasi. Melalui informasi yang didapat dari proses tersebut, maka diharapkan dapat membantu dalam proses pengembangan penelitian pada tahapan selanjutnya. Adapun proses yang digunakan dalam pengumpulan informasi tersebut, diantaranya: a.

Kajian dokumen Proses kajian dokumen dilakukan untuk mengetahui lebih jauh mengenai keadaan terkini pengelolaan insiden TI yang terdapat pada divisi GSIT. Dokumen yang dikaji dapat berupa dokumen kebijakan, prosedur, berita acara, dan lain sebagainya. Hal ini dilakukan agar didapatkan informasi yang tepat dan terkini mengenai proses implementasi kebijakan dan prosedur yang telah ditetapkan.

b.

Wawancara Proses wawancara dilakukan dengan tujuan untuk mendapatkan informasi lebih jauh mengenai kondisi terkini di lapangan. Sehingga didapatkan pemahaman mengenai segala suatu informasi dari yang bersangkutan.

c.

Kuesioner Proses ini dilakukan untuk memperoleh informasi terkini mengenai proses Incident Management TI yang terdapat pada divisi GSIT. Pengajuan kuesioner mengacu pada atribut-atribut yang terdapat pada proses Incident Manegement pada model Service Operation ITIL 2011. Selanjutnya hasil dari kuesioner ini akan digunakan sebagai acuan dalam proses penilaiaan tingkat kematangan (Maturity Level Assessment).

d.

Observasi Proses observasi dilakukan pada Data Center Pusat dan Disaster Recovery Center. Proses ini dilakukan untuk mengetahui seluruh alur yang terjadi dalam proses manajemen insiden TI pada masing-masing site.

36

e.

Studi Literatur Proses ini dilakukan untuk mengumpulkan informasi mengenai kerangka kerja ITIL 2011, khususnya pada proses Incident Management yang digunakan dalam mendukung penelitian. Berikut ini informasi mengenai pihak-pihak yang terlibat dalam proses

pengumpulan informasi dan analisa diantaranya adalah DC Manager, Assistant Manager, System Operator.

Tabel 3.1 Pihak yang Terlibat dalam Pengumpulan Informasi dan Analisa Pihak

Peran

DC Manager

Memberikan informasi dan akses mengenai dokumen-dokumen yang terkait dengan pengelolaan insiden TI, seperti Panduan Pengelolaan Incident

Assistant DC Manager

Memberikan informasi dan penjelasan mengenai proses-proses yang terdapat pada panduan pengelolaan incident

System Operator

Memberikan informasi aktivitas-aktivitas real dari proses pengelolaan insiden TI yang sedang terjadi

3.2. Penilaian Tingkat Kematangan Pada tahap ini, dilakukan proses penilaian tingkat kematangan (Maturity Level Assessment) terhadap Tata Kelola Manajemen Insiden TI yang terdapat pada divisi GSIT. Proses penilaian ini digunakan untuk mengukur tingkat kematangan penerapan tata kelola manajemen insiden TI yang ada, dengan mengacu pada kerangka kerja ITIL 2011. Penilaian dilakukan terhadap dua kondisi, yaitu kondisi Tata Kelola Manajemen Insiden TI saat ini (existing) dan kondisi Tata Kelola Manajemen Insiden TI di masa depan, dimana sesuai dengan kerangka kerja ITIL 2011. Berdasarkan ITIL Maturity Model yang terdapat pada ITIL Service Lifecycle, penilaian tingkat kematangan pada penelitian ini dilakukan terhadap

37

model Service Operation. Dimana proses yang digunakan yaitu Incident Management. Pada proses Incident Management tersebut, terdapat 9 sub proses yang dijabarkan melalui 42 atribut yang dibagi menjadi 4 Service Operation Area, diantaranya “The Incident Management Process”, “Activities in Place needed for the Success of Incident Management”, “Incident Management Metrics”, dan “Incident Management Process Interactions”. Setiap atribut yang ada, menyediakan indikator dan parameter dalam memberikan nilai kematangan, dimana nilai yang dimaksud berada dalam skala 1 sampai 5. Definisi proses penilaian pada ITIL 2011 pada dasarnya sejalan dengan proses definisi penilaian yang terdapat pada COBIT dan juga CMMI. (2013, Axelos). Berikut ini merupakan definisi Maturity Level yang dapat dilihat pada tabel 3.2. Tabel 3.2 Definisi Maturity Level

1

Maturity Level

Definisi

Initial

Pada level ini, proses atau fungsi yang ada bersifat ad hoc atau tidak terorganisir atau tidak terdefinisikan pada Bank.

2

Repeatable

Pada level ini, proses atau fungsi telah tersedia pada Bank. Proses atau fungsi hanya mengikuti pola yang ada.

3

Defined

Pada level ini, proses atau fungsi yang ada telah dikenali. Prosedur yang ada telah distandarisasi, didokumentasikan, dan di berikan melalui pelatihan oleh Bank.

4

Managed

Pada level ini, proses atau fungsi telah sepenuhnya dikenali dan disetujui dalam proses TI yang ada.

38

5

Pada level ini, proses atau fungsi yang ada

Optimized

telah menjadi aktifitas rutin oleh Bank. Proses atau fungsi telah terintegrasi secara automasi dengan alur kerja yang ada. Proses berkelanjutan

dari

pengembangan

telah

dilakukan oleh bank.

Pada Tabel 3.2 Definisi Maturity Level diatas, telah dijelaskan bahwa setiap proses penilaian dilakukan dengan rentang angka 1 sampai dengan 5. Dimana angka 1 didefinisikan sebagai level Initial dengan nilai terendah. “Initial” menunjukkan bahwa proses atau fungsi bersifat adhoc atau tidak teroganisir, atau tidak terdefinisikan. Kemudian skala 2 menunjukkan bahwa proses atau fungsi telah tersedia dan dilakukan mengikuti pola yang ada. Skala angka 3 mengindikasikan

bahwa

proses

atau

fungsi

telah

didokumentasikan,

distandarisasi, diberikan melalui pelatihan oleh PT Bank ABC, Tbk. Untuk skala 4 diartikan bahwa proses atau fungsi telah dikenali dan disetujui oleh perusahaan. Hingga pada skala angka 5 yang diartikan sebagai “Optimized”, dimana proses atau fungsi telah manjadi keseharian dari aktivitas Incident Management dan proses pengembangan berkelanjutan telah dilakukan pada divisi GSIT PT Bank ABC. Disamping definisi yang telah dijelaskan diatas, ITIL Maturity Model juga memiliki Maturity Level Characteristics (2013, Axelos). Beberapa karakteristik dari Maturity Level ini diturunkan dari berbagai macam sumber, termasuk juga diturunkan dari atribut-atribut umum yang terdapat pada ITIL Maturity Model diatas. Berikut ini sebagian karakteristik umum dari masingmasing Maturity Level yang ada. Tabel 3.3 Karakteristik Maturity Level.

0

Maturity Level

Karakteristik

Absense (chaos)

 Proses atau fungsi hanya terdapat sebagian atau bahkan tidak ada sama sekali  Jika proses atau fungsi hanya terdapat 39

sebagian, hal ini dipastikan tidak memiliki struktur, tanggung jawab serta tidak konsisten dalam operasionalnya. 1

Initial (reactive)

 Adanya sedikit komitmen dari manajemen  Tidak terdapat tata kelola dari proses/fungsi  Tidak ada tujuan yang terdefinisikan  Tidak adanya pro-aktivitas, bersifat reaktif.  Aktivitas tidak terkoordinasi, sedikit atau bahkan tidak konsisten  Hanya terdapat sedikit (jika ada) prosedur yang terdokumentasi.  Tidak terdapat definisi peran dari proses / fungsi  Jalannya aktivitas bergantung pada siapa yang mengambilnya.  Sedikit atau bahkan tidak ada automasi dari aktivitas yang ada.  Sedikit (jika ada) catatan performa yang disimpan  Tidak terdapat prosedur formal untuk proses pengembangan  Orang yang menjalankan peran dari proses/fungsi, hanya mendapatkan sedikit pelatihan diluar dari yang telah dipelajarinya sendiri.  Kinerja aktivitas tidak terukur.  Aktivitas bersifat teknis dibandingkan fokus pada pelanggan atau layanan.  Tidak adanya umpan balik () yang didapat dari pemangku kepentingan

2

Repeatable (active)

 Terdapat beberapa manajemen

komitmen

dari

 Aktivitas yang ada terdata  Target dan tujuan terdefinisikan  Ruang lingkup dari proses/fungsi telah didefinisikan dan disetujui  Terdapat prosedur, namun tidak sepenuhnya terdokumentasi  Prosedur biasanya diikuti, namun berbeda

40

dari orang ke orang dan juga tim ke tim  Orang yang melakukan aktivitas mempunyai kemampuan, pengalaman, kompetensi dan pengetahuan mengenai perannya.  Peran dapat dikenali, meskipun didefinisikan secara formal.

tidak

 Kinerja diukur dan dilaporkan, setidaknya ke lingkungan kecil internal.  Kinerja mulai lebih konsisten, tapi terkadang masih sedikit tidak  Beberapa proses automasi mulai digunakan untuk meningkatkan efisiensi 3

Defined (proactive)

 Komitmen manajemen jelas  Aktivitas tepat terdata, meskipun kadang, dan dalam kondisi yang tidak biasa, mungkin juga tidak memadai.  Mulai untuk focus pada operasional secara proaktif, meskipun sebagian besar pekerjaan masih bersifat reaktif.  Dokumen penting dicatat dengan versi dan dalam pengendalian perubahan  Ruang lingkup didokumentasikan

dari

proses/fungsi

 Prosedur dan instruksi kerja terdokumentasi dan diperbaharui  Kinerja terukur dengan berbagai perhitungan 4

Managed (pre-emptive)

 Proses / fungsi dan aktivitas terkait kuat dan jarang gagal dari yang telah direncanakan  Kebanyakan aktivitas yang dapat diautomasi telah dilakukan automasi  Dokumentasi dilindungi dari perubahan yang tidak diijinkan, dan disimpan secara terpusat  Aktivitas dilakukan dengan tingkat konsistensi yang tinggi dengan sedikit pengecualian  Definisi level otoritas dari masing-masing peran yang jelas dan terdokumentasi  Proses-proses saling terintegrasi  Fokus

41

pada

pelayanan

dan

pelanggan

daripada hal-hal teknis 5

Optimized

 Aktivitas dilakukan secara konsisten kepada seluruh area (lintas area) dari perusahaan  Perencanaan menjadi dasar, baik dalam bisnis dan pelayanan  Perencanaan dan aktivitas TI terintegrasi dengan perencanaan dan aktivitas bisnis perusahaan  Proses, prosedur, dan fungsi secara berkelanjutan di audit untuk efisiensi dan efektifitas  Redudansi dan ketidak-optimalan prosedur dapat teridentifikasi dan dapat dihilangkan  Kinerja data dan umpan balik dari lingkungan disimpan dan dianalisa untuk mendapatkan tren dan potensi pengembangan

3.3. Perancangan Dokumen Tata Kelola Pada tahap ini, dilakukan perancangan draft dokumen tata kelola manajemen insiden TI. Proses perancangan draft dokumen ini dilakukan berdasarkan hasil analisa penilaian tingkat kematangan (Maturity Level Assessment) terhadap tata kelola manajemen insiden TI yang telah ada sebelumnya. Draft dokumen tata kelola yang akan dibuat yaitu berupa prosedur. Berdasarkan hasil analisa penilaian tingkat kematangan, maka jika ditemukan penilaian dengan angka yang rendah, apabila diperlukan akan dibuatkan dokumen-dokumen prosedur baru terkait proses tersebut. Namun jika tidak, maka akan dilakukan perbaikan-perbaikan terhadap tata kelola manajemen insiden TI yang sesuai dengan kriteria dari ITIL 2011 dan tentu akan dikaitkan dengan kebijakan-kebijakan TI yang berlaku pada divisi GSIT PT Bank ABC, Tbk saat ini.

3.4. Verifikasi Dokumen Tata Kelola Pada tahap ini selanjutnya akan dilakukan verifikasi terhadap dokumendokumen yang telah dirancang sebelumnya. Proses verifikasi diperlukan untuk

42

menentukan apakah draft dokumen tata kelola manajemen insiden TI yang telah dirancang, telah sesuai dengan yang diinginkan oleh divisi GSIT. Proses ini akan dilakukan oleh pihak manajemen dari sub divisi IIO (IT Infrastructure & Operation Management) yang diwakilkan oleh DC (Data Center) Assistant Manager. Pihak manajemen akan melakukan review terhadap aktivitas-aktivitas dalam dokumen tata kelola, kemudian akan dibandingkan antara dokumen yang ada saat ini dengan dokumen yang sesuai dengan kerangka kerja ITIL 2011. 3.5. Validasi Dokumen Tata Kelola Pada tahap ini akan dilakukan validasi terhadap dokumen tata kelola manajemen insiden TI dengan menguji apakah tujuan dari setiap proses manajemen insiden TI yang telah disusun sesuai dengan yang diharapkan. Apabila proses validasi telah selesai, maka dokumen tata kelola dapat digunakan pada operasional manajemen insiden TI pada divisi GSIT. Proses validasi akan dilakukan dengan meminta acceptance letter dari pihak manajemen IIO yang diwakili oleh DC Manager.

3.6. Kesimpulan Pada tahapan kesimpulan ini, hasil penelitian mengenai tata kelola manajemen insiden TI disimpulkan. Seluruh kesimpulan memuat bagaimana kondisi tata kelola manajemen insiden TI pada divisi GSIT saat ini. Selain itu akan disimpulkan pula beberapa saran mengenai perancangan tata kelola manajemen insiden TI ini.

3.7. Rencana dan Jadwal Kerja Penelitian dan Penyusunan Tesis Dalam penyusunan tesis ini, direncanakan dilakukan penelitian dalam waktu 4 bulan. Untuk detil dari rencana dan jadwal kerja penelitian ini dapat dilihat pada tabel 3.4 dibawah ini.

43

Tabel 3.4 Rencana dan Jadwal Penelitian dan Penyusunan Tesis No Kegiatan 1

2

3

4 5

Bulan IV Bulan I Bulan II Bulan III 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Pengumpulan informasi dan analisa Kuesioner dan penilaian tingkat kematangan Perancangan, verifikasi dan validasi Analisis dan pembahasan Pembuatan laporan

44

BAB 4 ANALISA DAN PEMBAHASAN

Pada bab ini akan dibahas lebih lanjut mengenai analisa data hasil penelitian yang didapat dari perusahaan, yang dikelola menggunakan framework ITIL 2011. Bab ini juga terdapat profil perusahaan, proses bisnis, dan struktur organisasi TI di PT Bank ABC. Berikut secara garis besar bahasan yang dijelaskan pada bab ini, diantaranya: 1.

Profil PT Bank ABC 1.1. Sejarah PT Bank ABC 1.2. Visi, Misi dan Tata Nilai PT Bank ABC 1.3. Struktur Organisasi PT Bank ABC

2.

Pengelolaan TI PT Bank ABC 2.1. Struktur Organisasi TI 2.2. Solusi Bisnis Organisasi TI

3.

Tata Kelola Manajemen Insiden TI 3.1. Pengumpulan Informasi dan Analisa 3.2. Manajemen Insiden Saat ini 3.3. Struktur Dokumen Manajemen Insiden 3.4. Pengembangan Tata Kelola Manajemen Insiden 3.5. Struktur Dokumen Tata Kelola Manajemen Insiden

Berikut ini penjelasan lebih lanjut mengenai analisa data yang telah didapat.

4.1. Profil PT Bank ABC Berikut ini akan dijelaskan sekilas mengenai profil PT Bank ABC secara umum, diantaranya mengenai sejarah perusahaan dan struktur organisasi yang dimiliki saat ini oleh perusahaan.

45

4.1.1 Sejarah PT Bank ABC PT Bank ABC didirikan di Indonesia pada tanggal 10 Agustus 1955 dengan nama “N.V. Perseroan Dagang Dan Industrie Semarang Knitting Factory” dan mulai beroperasi di bidang perbankan sejak tanggal 21 Februari 1957 di kota Jakarta. Saat ini, PT Bank ABC memiliki 953 kantor cabang di seluruh Indonesia serta 2 kantor perwakilan luar negeri yang berlokasi di Hong Kong dan Singapura. Pada era tahun 1970an, PT Bank ABC memperkuat jaringan layanan cabang. Tahun 1977 perusahaan ini berkembang menjadi Bank Devisa. Kemudian pada tahun 1980an, sejalan dengan deregulasi sektor perbankan Indonesia, PT Bank ABC mengembangkan jaringan kantor cabang secara luas. PT Bank ABC mengembangkan berbagai produk dan layanan maupun pengembangan teknologi Informasi, khususnya penerapan online system untuk jaringan kantor cabang, dan meluncurkan salah satu produknya yaitu Tabungan Hari Depan. PT Bank ABC mengembangkan alternatif jaringan layanan melalui ATM (Anjungan Tunai Mandiri atau Automated Teller Machine) yang berkembang secara pesat. Pada tahun 1991, perusahaan ini mulai menempatkan 50 unit ATM di berbagai tempat di Jakarta. Pengembangan jaringan dan fitur ATM dilakukan secara intensif. PT Bank ABC menjalin kerja sama dengan institusi terkemuka, antara lain PT. Telekomunikasi Indonesia, Tbk untuk pembayaran tagihan telepon melalui ATM. Perusahaan juga bekerja sama dengan Citibank agar nasabah PT Bank ABC pemegang kartu kredit Citibank dapat melakukan pembayaran tagihan melalui ATM yang dimiliki oleh perusahaan. Pada tahun 1997-1998, Indonesia mengalami krisis moneter sehingga menyebabkan PT Bank ABC mengalami rush. Pada tahun 1998 PT Bank ABC menjadi Bank Taken Over (BTO) dan disertakan dalam program rekapitalisasi dan restrukturisasi yang dilaksanakan oleh Badan Penyehatan Perbankan Nasional (BPPN), yaitu suatu institusi Pemerintah. Tahun 1999, proses rekapitalisasi PT Bank ABC selesai dan sebagian besar kredit yang disalurkan oleh perusahaan dipertukarkan dengan Obligasi Pemerintah. Pemerintah Republik Indonesia melalui BPPN, menguasai 92,8% saham PT Bank ABC. Namun pada tahun 2000, BPPN melakukan divestasi 46

22,5% dari seluruh saham perusahaan melalui Penawaran Saham Publik Perdana (IPO), sehingga kepemilikan BPPN berkurang menjadi 70,3%. Kemudian tahun 2001, dilakukan Penawaran Publik Kedua (Secondary Public Offering) sebesar 10% dari total saham perusahaan. Kepemilikan BPPN atas PT Bank ABC berkurang menjadi 60,3%. Tahun 2002, FarIndo Investment (Mauritius) Limited mengambil-alih 51% total saham PT Bank ABC melalui proses tender strategic private placement. Pada tahun 2004, BPPN melakukan divestasi atas 1,4% saham perusahaan kepada investor domestik melalui penawaran terbatas. Pemerintah Republik Indonesia melalui PT. Perusahaan Pengelola Aset (PPA) melakukan divestasi seluruh sisa 5,02% saham PT Bank ABC. Tahun 2005, perusahaan memperkuat dan mengembangkan produk dan layanan, terutama perbankan elektronik dengan memperkenalkan beberapa layanan Debit, Tunai, internet banking, mobile banking, Electronic Data Capture (EDC), dan lain-lain. Perusahaan juga mengembangkan beberapa layanan khusus, seperti: layanan Prioritas dan Bisnis. PT Bank ABC mendirikan fasilitas Disaster Recovery Center (DRC) di Singapura. Kemudian, perusahaan meningkatkan kompetensi di bidang penyaluran kredit, termasuk melalui ekspansi ke bidang pembiayaan mobil melalui anak perusahaannya. Pada tahun 2007, PT Bank ABC menjadi pelopor dalam menawarkan produk kredit kepemilikan rumah dengan suku bunga tetap, yang berhasil meraih respon positif dari pasar. Kemudian perusahaan meluncurkan kartu prabayar, serta mulai menawarkan layanan Weekend Banking untuk terus membangun keunggulan di bidang perbankan transaksi. PT Bank ABC secara proaktif mengelola penyaluran kredit dan posisi likuiditas di tengah gejolak krisis global, sekaligus tetap memperkuat kompetensi utama sebagai bank transaksi. Di tahun 2009, perusahaan telah menyelesaikan pembangunan mirroring IT system guna memperkuat kelangsungan usaha dan meminimalisasi risiko operasional. Perusahaan juga membuka layanan Solitaire bagi nasabah high net-worth individual. PT Bank ABC memasuki lini bisnis baru yaitu perbankan Syariah, pembiayaan sepeda motor, asuransi dan sekuritas. Di tahun 2013, perusahaan 47

menambah kepemilikan efektif dari 25% menjadi 100% pada perusahaan asuransi umum yang dimiliki sebelumnya. Pada Desember 2013, perusahaan memperoleh persetujuan regulator atas pembelian 45% saham PT Central Santosa Finance (CSF), perusahaan pembiayaan sepeda motor. Selanjutnya pada Januari 2014, perusahaan menyelesaikan pembelian saham CSF, sehingga kepemilikan saham PT Bank ABC terhadap CSF secara efektif meningkat dari 25% menjadi 70%. PT Bank ABC memperkuat bisnis perbankan transaksi melalui pengembangan produk dan layanan yang inovatif, diantaranya aplikasi mobile banking untuk smartphone terkini, layanan penyelesaian pembayaran melalui eCommerce, dan mengembangkan konsep baru Electronic Banking Center (EBC) yang melengkapi ATM Center dengan tambahan fitur-fitur yang didukung teknologi terkini. Guna meningkatkan keandalan layanan perbankannya, PT Bank ABC telah menyelesaikan pembangunan Disaster Recovery Center (DRC) di Surabaya yang berfungsi sebagai disaster recovery backup data center yang terintegrasi dengan dua mirroring data center. DRC yang baru ini menggantikan DRC yang sebelumnya berlokasi di Singapura. Di tahun 2013, PT Bank ABC menyalurkan kredit dengan menerapkan prinsip kehati-hatian dalam menghadapi ketidakpastian kondisi ekonomi dan politik, disamping tetap mendukung nasabah dalam memenuhi kebutuhan pendanaan mereka. Pada tahun 2014, PT Bank ABC menyempurnakan Electronic Banking Center (EBC) dengan konsep dan branding baru yang dilengkapi dengan layanan video conference dan video banking. Kemudian perusaahaan memperoleh ijin untuk memberikan layanan asuransi jiwa yang beroperasi di bawah entitas anak PT Bank ABC. 4.1.2 Visi, Misi, dan Tata Nilai PT Bank ABC Dalam mengemban tugas agar tercapainya tujuan utama dari bisnis perusahaan, maka diperlukan adanya visi, misi dan tata nilai bagi perusahaan. Hal ini diperlukan agar seluruh jajaran direksi hingga karyawan dapat berjalan selaras demi mewujudkan tujuan dari bisnis perusahaan. Oleh sebab itu PT Bank ABC

48

memiliki visi, misi dan tata nilai dalam struktur perusahaan, berikut merupakan penjelasannya.

Visi Bank pilihan utama andalan masyarakat, yang berperan sebagai pilar penting perekonomian Indonesia.

Misi  Membangun institusi yang unggul di bidang penyelesaian pembayaran dan solusi keuangan bagi nasabah bisnis dan perseorangan.  Memahami beragam kebutuhan nasabah dan memberikan layanan finansial yang tepat demi tercapainya kepuasan optimal bagi nasabah.  Meningkatkan

nilai

francais

dan

nilai

stakeholder

perusahaan.

Tata Nilai  Fokus Pada Nasabah  Integritas  Kerja sama Tim  Berusaha Mencapai yang Terbaik

4.1.3 Struktur Organisasi PT Bank ABC Berikut ini merupakan struktur organisasi perusahaan secara keseluruhan, yang terdapat pada PT Bank ABC.

49

50

Gambar 4.1 Struktur Organisasi PT Bank ABC

4.2. Pengelolaan TI PT Bank ABC 4.2.1 Struktur Organisasi TI Berikut ini merupakan struktur organisasi TI yang dimiliki oleh perusahaan, secara keseluruhan dibawah kendali divisi Group Strategic Information Technology (GSIT). Pada Gambar 4.2 dapat dijelaskan posisi dari GSIT dalam perusahaan. GSIT berada langsung dibawah direksi yang membidangi masalah TI, yaitu Direktur Operasi & Teknologi Informasi. 51

Gambar 4.2 Posisi Strategic Information Technology Group

Pada Gambar 4.3 dibawah ini merupakan detail dari bagan organisasi GSIT, dimana divisi GSIT dibagi menjadi 4 bagian, diantaranya Delivery Channel & Middleware Application Management dan Core Application Management yang merupakan kelompok manajemen aplikasi, sedangkan IT Infrastructure & Operation Management dan IT Management Office merupakan sub divisi.

Gambar 4.3 Bagan Organisasi Group Strategic Information Technology

Berikut ini merupakan ruang lingkup dan tugas dari sub divisi yang menangani proses manajemen insiden TI, yaitu sub divisi IT Infrastructure and Operation Management (IIO): Ruang lingkup IT Infrastructure & Operation Management adalah sebagai berikut: 

Enterprise Networking System, antara lain: -

Data center networking 52





-

Branch networking

-

Voice networking

System Infrastructure, antara lain: -

Mainframe system

-

Mid-range system

-

Server

-

System software

-

Database system

Service Delivery, antara lain: -

Data Center Operation

-

DRC Operation

-

Solution Desk & Tape Librarian

-

DC services management

-

Facility management

-

System automation Aspek dan tugas pokok IT Infrastructure & Operation Management

terdiri dari 4 aspek, yaitu:  Aspek IT infrastructure architecture & strategy Tugas pokok, meliputi: -

Membuat dan merekomendasikan strategi, infrastruktur dan framework teknologi informasi sesuai dengan lingkup tugasnya.

-

Membuat dan mendesain standar infrastruktur sistem dan jaringan teknologi informasi.

-

Memastikan perbaikan arsitektur dan standardisasi untuk infrastructure environments termasuk seleksi networking.  Aspek IT system & networking management Tugas pokok, meliputi:

-

Melakukan pengembangan sistem dan jaringan teknologi informasi sesuai dengan strategi teknologi informasi serta memperhatikan faktor efisiensi dan efektivitas.

-

Melakukan instalasi sistem dan jaringan teknologi informasi

-

Melakukan implementasi sistem dan jaringan teknologi informasi. 53

-

Mengembangkan dan melaksanakan metode pemeliharaan yang tepat untuk seluruh sistem dan jaringan teknologi informasi.

-

Melakukan pengendalian mutu dan pengujian sistem dan jaringan teknologi informasi (system test & regression test).

-

Melakukan penyediaan dan pengelolaan atas data dan informasi.

-

Mendukung dan membantu penyelesaian permasalahan sistem dan jaringan di data center, cabang dan seluruh unit kerja.

-

Melakukan capacity planning serta system & performance review secara berkala dan melakukan perbaikan yang diperlukan.

-

Memastikan utilisasi system dan jaringan dalam batas yang wajar sehingga response time system pada memenuhi standar service level yang telah disepakati.

-

Mengevaluasi komponen sistem dan perangkat keras serta melakukan perbaikan yang diperlukan.

-

Melakukan implementasi aplikasi sistem informasi.

-

Mengimplementasikan Disaster Recovery Plan (DRP) dengan memastikan dokumentasi terkait aplikasi terpelihara dan ter-update dengan baik, memastikan personel sistem IT system & networking memahami DRP, dan memastikan IT system & networking di setiap data center memiliki versi yang sama dan selaras.  Aspek pengelolaan data center Tugas pokok, meliputi:

-

Mengoperasikan dan mengendalikan Pusat Data Komputer dan Disaster Recovery Center.

-

Memastikan Service Level Agreement (SLA) untuk seluruh pengoperasian Pusat Data Komputer dan Disaster Recovery Center sesuai dengan ketentuan yang ditetapkan.

-

Menjadi/bertindak sebagai point of solution desk.

-

Melakukan tindakan preventif untuk meminimalkan risiko atas terjadinya gangguan pada PDK.

-

Menjadi/bertindak sebagai point of untuk perubahan yang diusulkan oleh unit kerja terkait. 54

-

Mengoptimalkan kemampuan seluruh perangkat teknologi informasi di Pusat Data Komputer sehingga dapat memberikan kemampuan yang efektif dan berlangsung terus menerus.

-

Mengembangkan metoda dukungan dan pemantauan proses manajemen dan operasi PDK agar efektif dan efisien.

-

Memastikan dokumentasi terkait penerapan DRP terpelihara dan ter-update dengan baik, memastikan personel sistem data center memahami DRP, dan memastikan perangkat di setiap data center memiliki versi yang sama dan sesuai kebutuhan DRP.  Aspek IT service management Tugas pokok, meliputi:

-

Menyusun dan menetapkan obyektif service level daripada service delivery pada network, sistem dan data center.

-

Memantau defect rate daripada service level yang telah ditetapkan dan memastikan service level yang telah disepakati dan dikomunikasikan kepada atau unit bisnis dapat dipenuhi secara konsisten.

-

Melakukan koordinasi dengan unit kerja terkait di GSIT untuk memperbaiki service level.

-

Memastikan adanya service level agreement dengan pihak ketiga seperti vendor atau supplier yang kritikal atas kecepatan response (tanggap) pada saat dihubungi oleh GSIT terkait situasi krisis atau bencana.

-

Melakukan evaluasi, validasi dan audit atas kemampuan pemenuhan pihak ketiga atas service level agreement maksimal secara periodik minimal 1 tahun sekali.

-

Mengelola configuration management/asset management.

-

Memastikan tingkat kesiapan GSIT dalam menghadapi situasi krisis dan bencana pada level yang dapat diterima oleh Direksi dan unit bisnis kritikal.

-

Menerapkan

change

management

dengan

memastikan

perubahan-

perubahan pada sistem, network dan data center terdokumentasi dan terupdate dengan baik maksimal 1 tahun sekali.

55

-

Membuat laporan service level bulanan dan melaporkannya kepada pihakpihak yang berkepentingan.

-

Melakukan review terhadap setiap perubahan yang akan dilakukan di Pusat Data Komputer (PDK).

4.2.2 Solusi Bisnis Organisasi TI Divisi Group Strategic Information System (GSIT) melayani berbagai macam proses bisnis teknologi informasi di cabang, kantor pusat, hingga nasabah. Seluruh proses teknologi informasi yang dimiliki oleh PT Bank ABC dilakukan oleh divisi GSIT. Beberapa solusi bisnis dirasakan membantu oleh setiap kantor cabang dalam melaksanakan tugas operasional rutin setiap hari. Dimulai dari proses transaksi simpanan, kredit, yang seluruhnya berkaitan dengan layanan cabang yang diminta oleh nasabah, hingga layanan yang berkaitan sesama kantor cabang itu sendiri, serta layanan yang diberikan dalam mendistribusikan laporan yang dilakukan oleh kantor pusat. Disamping kemudahan yang dirasakan oleh kantor cabang, kantor pusat pun merasakan hal yang sama. Solusi bisnis seperti kemudahan jaringan komunikasi yang terpusat, hingga integrasi dengan pihak ketiga seperti Bank Indonesia dilakukan oleh kantor pusat. Di era teknologi yang semakin maju dan berkembang, solusi bisnis TI bagi nasabah tidak kalah penting diberikan oleh perusahaan sebagai penunjang kemudahan transaksi sehari-hari. Segala aplikasi layanan yang memudahkan nasabah bertransaksi selalu siap sepanjang hari selama setahun. Segala macam gangguan akan berusaha diminimalisir sedini mungkin, agar nasabah tidak merasakan gangguan tersebut. Secara garis besar, seluruh layanan TI yang diberikan oleh divisi GSIT dapat dijelaskan pada gambar 4.4 dibawah ini.

56

Group Strategic Information Technology (GSIT) (DC dan DRC)

Branch & End Computing Application

IDS

E-Channel & Payment System Application

Loan Origination

Business Process & Application Integration Social Network Application Cash Management Application Middleware Application Data Governance Management Information System Master Data Management Information Management

Data center networking Branch networking

ILS

Voice networking Mainframe system

RTGS & SKN Cardlink (Core Credit Card Application)

Mid-range system Server

Treasury

System software

Foreign Exchange & Trade Finance

Database system Data Center Operation

Fund Transfer

DRC Operation

General Ledger

Solution Desk & Tape Librarian

Corporate Application (human resources application, logistics application, dll)

IT strategy, research & development integration quality assurance demand & program management resource & knowledge management capital & expense management IT procurement & supplier management audit resolution & service level

DC services management

business relationship management

Facility management

documentation

System automation

compliance

Gambar 4.4 Solusi Bisnis TI GSIT

4.3. Tata Kelola Manajemen Insiden TI 4.3.1 Pengumpulan Informasi dan Analisa Dalam proses perancangan tata kelola manajemen insiden TI pada PT Bank ABC, proses pengumpulan informasi dan analisa awal telah dilakukan. Beberapa proses yang telah dilakukan diantaranya: a.

Kajian dokumen Kajian dokumen telah dilakukan untuk mengetahui lebih jauh mengenai keadaan terkini pengelolaan insiden TI yang terdapat pada divisi GSIT. Dokumen yang dikaji diantaranya Panduan Operasional Data Center, khususnya bab Panduan Pengelolaan Incident, serta Sistem Manajemen Mutu ISO 9001:2008 khususnya Prosedur Pengelolaan Incident.

57

b.

Wawancara Proses wawancara telah dilakukan terhadap system operator dengan tujuan untuk mendapatkan informasi lebih jauh mengenai kondisi terkini di lapangan.

c.

Kuesioner Proses ini telah dilakukan untuk memperoleh informasi terkini mengenai proses Incident Management TI yang terdapat pada divisi GSIT.

d.

Observasi Proses observasi telah dilakukan pada Data Center Pusat dan Disaster Recovery Center (DRC).

e.

Studi Literatur Proses ini telah dilakukan dalam pengumpulan informasi mengenai kerangka kerja ITIL 2011, khususnya pada proses Incident Management yang digunakan dalam mendukung penelitian.

4.3.2 Manajemen Insiden TI Saat ini Proses manajemen insiden yang dimiliki oleh PT Bank ABC, khususnya divisi GSIT, telah digunakan dalam operasional data center hingga saat ini. Panduan mengenai proses tersebut terdapat pada dokumen Panduan Operasional Data Center, dengan bab Panduan Pengelolaan Incident. Hingga saat ini, panduan proses tersebut telah diperbaharui dengan versi terakhir yaitu versi 5 yang terbit bulan Agustus 2014. Sesuai dengan ketentuan penanganan insiden TI pada Panduan Pengelolaan Incident, proses manajemen insiden TI saat ini meliputi proses penyelesaian masalah pada first level, eskalasi, pencatatan insiden, monitoring, dan penutupan insiden. Saat ini yang bertanggung jawab atas pengelolaan insiden TI yang berhubungan dengan operasional Data Center adalah helpdesk, system operator, shift leader, dan group leader.

58

First level handle insiden

Pencatatan Insiden

Insiden Terjadi

Monitoring Insiden

Menutup Insiden

Eskalasi insiden

Gambar 4.5 Ketentuan Penanganan Insiden TI

Dari gambar 4.5 Ketentuan Penanganan Insiden TI di atas, dapat dijelaskan bahwa saat ini proses manajemen insiden dimulai dari munculnya insiden yang terjadi pada operasional Data Center (DC). Insiden yang muncul dapat bersifat gangguan fisik maupun non fisik, serta dapat dilakukan secara di sengaja maupun tidak di sengaja oleh siapapun. Informasi mengenai gangguan yang dialami didapat melalui warning message pada perangkat atau pada console, serta dapat pula melalui laporan dari atau pihak call center. Setiap terjadinya insiden tersebut, ataupun pengguna aplikasi atau sistem akan melaporkan kepada bagian helpdesk bahwa terjadi gangguan disisi aplikasi atau sistem. yang dimaksud dapat berupa staff yang berada di cabang dan atau kantor pusat, yaitu sebagai pelanggan dari sistem yang dikelola oleh GSIT, serta dapat pula dimaksud sebagai nasabah PT Bank ABC yang merupakan pengguna dari aplikasi yang dapat diakses oleh nasabah itu sendiri. Laporan dari nasabah tersebut tidak langsung diterima oleh helpdesk, melainkan dari divisi lain sebagai call center yang merupakan bagian dari single of yang dimiliki oleh perusahaan terhadap nasabah. Disamping , terdapat pula PIC (person in charge) atau penanggung jawab aplikasi yang dapat melaporkan gangguan yang telah ditemukannya melalui warning message kepada helpdesk.

59

Terhadap insiden yang terjadi, hal yang selanjutnya dilakukan adalah dilakukannya problem solving oleh first level yaitu pihak System Operator. Setelah diterima laporan bahwa terjadinya gangguan, selanjutnya yang dilakukan adalah proses pencatatan insiden yang dilakukan oleh System Operator. Proses pencatatan insiden dilakukan secara terpusat dengan menggunakan sistem terintegrasi, sehingga meminimalisir terjadi redudansi pencatatan insiden. Selanjutnya, setelah dilakukan pencatatan maka yang dilakukan adalah proses eskalasi insiden. Proses eskalasi insiden yang dimaksud yaitu proses penyampaian/tindak lanjut insiden kepada pihak-pihak yang berkepentingan agar dilakukan penyelesaian terkait masalah yang sedang terjadi. Eskalasi yang dilakukan dapat langsung kepada PIC yang bersangkutan, maupun dilakukan sendiri oleh System Operator sesuai panduan yang telah diberikan oleh PIC. Pada proses tersebut, maka dilakukan monitoring terhadap proses penyelesaiaan insiden yang terjadi. Apabila proses penyelesaiaan insiden yang dilakukan pada proses eskalasi sebelumnya telah selesai, maka selanjutnya yang dilakukan adalah proses penutupan pelaporan insiden. Proses penutupan laporan insiden dilakukan sebagai pertanda bahwa insiden yang terjadi telah selesai dilakukan solving problem dan dinyatakan case closed. Selanjutnya dari seluruh laporan insiden yang yang telah ditutup, maka dilakukan evaluasi terhadap laporan yang pernah dibuat. Proses evaluasi dilakukan untuk menganalisa insiden yang pernah terjadi agar dikemudian hari tidak sampai terjadi kembali (proses pencegahan). Berdasarkan UCISA (Universities and Colleges Information System Association - www.ucisa.ac.uk) dari Universitas Oxford, proses penilaian incident management dilakukan dengan menggunakan 4 Service Operation area, diantaranya “The Incident Management Process” (A), “Activities in Place needed for the Success of Incident Management” (B), “Incident Management Metrics” (C), dan “Incident Management Process Interactions” (D). Keseluruhan proses manajemen insiden TI yang dijelaskan diatas telah terwakilkan pada atributatribut yang terdapat pada masing-masing service area. Untuk informasi lengkap mengenai masing-masing atribut tersebut dapat dilihat pada Lampiran A. Form 60

Kuesioner Penilaian Proses Manajemen Insiden. Dibawah ini merupakan hasil kuesioner proses penilaian terhadap manajemen insiden TI yang ada saat ini, menggunakan 4 service area yang dimaksud. Hasil kuesioner diperoleh dari penetapan score bersama terhadap 4 responden yang mewakili peran dari masingmasing level di data center PT Bank ABC, diantaranya Group Leader (assistant manager), Shift Leader, System Operator.

The Incident Management Process (A) 4 3 2 Incident Management Process Interactions (D)

1

Activities Needed in Place for the Success of Incident Management (B)

0

Score

Incident Management Metrics (C)

Gambar 4.6 Service Area Incident Management Plan

Terlihat pada gambar diatas, dari ke empat service area yang telah dilakukan penilaian tingkat kematangan melalui kuesioner, pada bagian “Incident Management Metrics” memiliki score paling rendah dibanding ketiga service area yang lain. Pada bagian ini, score yang didapat rata-rata dari seluruh atribut yang dijawab oleh responden yaitu 2.33. Hal ini menunjukkan bahwa secara umum masih perlu adanya perbaikan pada service area “Incident Management Metrics”. Sedangkan average score tertinggi dari ke 4 service area yang ada terdapat pada bagian “Incident Management Proces Interactions”, responden menjawab seluruh atribut yang ada dengan score rata-rata 4. Namun meskipun

61

score yang dimiliki tertinggi dibanding yang lain, masih dimungkinkan atribut didalamnya memiliki score jauh dibawah. Pada Tabel 4.1 Average Score Incident Management Plan dibawah ini menjelaskan detil angka rata-rata dari masingmasing service area yang dimaksud. Tabel 4.1 Average Score Incident Management Plan Service Operation Average score all participants, all questions

Average Score

The Incident Management Process (A) Activities Needed in Place for the Success of Incident Management (B) Incident Management Metrics (C) Incident Management Process Interactions (D)

3.407407407 2.714285714 2.333333333 4

Disamping nilai rata-rata yang didapat berdasarkan service area yang ada, pada gambar dibawah ini dijelaskan mengenai detil nilai dari masing-masing atribut yang dimiliki. Berikut ini merupakan nilai dari 27 atribut pada “Incident Management Process” (A) yang didapat dari penetapan nilai baku terhadap kondisi nyata proses di lapangan.

A26 A25 A24 A23

A27 5

A1

A2

A3 A4

4

A5

3

A6

2

A22

1

A7

A21

0

A8

A20

A9

A19 A18 A17

A10

A16 A15

A14 A13

A11 A12

Gambar 4.7 The Incident Management Process

62

Score

Meskipun area “Incident Management Process” (A) memiliki nilai ratarata diatas 3, namun pada bagian ini masih memiliki atribut yang jauh dibawah rata-rata, dimana nilai terendah terdapat pada pertanyaan atribut index A4 dan A22, dengan nilai 1. Penjelasan detil untuk nilai masing-masing atribut yang ada dapat dilihat pada Tabel 4.2 dibawah ini.

Tabel 4.2 Score “Incident Management Process” Score

Index

Incident Management Process

A1

We have defined Incident Management's Purpose, Goal and Objective We have defined Incident Management's Scope We have defined Incident Management's Value to the business We have defined Incident Management's Policies, Principles and basic concepts Timescales are agreed for all incident handling stages Incident Manager/Process Owner is in place Incident Models are defined Major Incidents are defined A Major Incident Procedure has been developed The "Incident Identification" process activity is specified The "Incident logging" process activity is specified The "Incident categorisation" process activity is specified The "Incident Prioritisation" process activity is specified The "Initial Diagnosis" process activity is specified The "Incident Escalation" process activity is specified The "Incident Identification" process activity is specified The "Investigation and Diagnosis" process activity is specified The "Resolution and recovery" process activity is specified The "Incident Closure" process activity is specified We have defined Incident Management's Triggers, Imputs, Outputs and interfaces We have defined Incident Management's Information Management reporting We have defined Incident Management's Challenges, Critical Success Factors and Risks Self-service Incident logging is in pace Incident tracking is in place Incident ownership is understood and in place Data entered into incidents at all stages is checked for completeness Incident Mangement Process review procedure is in place

A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27

4 4 2 1 2 4 2 5 4 4 4 4 3 4 4 4 4 4 4 2 5 1 3 5 3 3 3

Berikutnya merupakan service operation area “Activities in Place needed for the Success of Incident Mangement” (B). Pada bagian ini terdiri dari 7 atribut yang memiliki nilai rata-rata secara keseluruhan yaitu 2.71. Penjelasan

63

detil mengenai nilai masing-masing atribut dapat dilihat pada Gambar 4.8 dan Tabel 4.3 dibawah ini.

B1 4 3

B7

B2

2 1 0

Score

B6

B3

B5

B4

Gambar 4.8 Activities in Place Needed for the Success of Incident Mangement

Detil penjelasan mengenai nilai rata-rata untuk 7 atribut yang terdapat pada service operation area “Activities in Place needed for the Success of Incident Mangement” dapat dilihat pada tabel 4.3 dibawah ini.

Tabel 4.3 Score “Activities in Place needed for the Success of Incident Mangement” Index B1 B2 B3 B4 B5 B6 B7

Activities in Place needed for the Success of Incident Mangement The Service Desk function is defined The Service Desk is aware of their role at Tier 1/Level 1 Incident Management Tier2/Level teams are aware of their role in Incident Management Tier 3/Level teams are aware of their role In Incident Management External Suppliers are aware of their role in Incident Management Knowledge Bases are in place to Incicent Resolution at the Service Desk Workarounds are document and in the Knowledge Base

64

Score

3 4 2 2 2 3 3

Selanjutnya, service operation area “Incident Management Metrics” (C) yang terdiri dari 3 atribut. Dari ketiga atribut yang ada, terdapat nilai terendah dengan score 1. Sedangkan nilai tertinggi yaitu 3. Untuk penjelasan lebih lengkap mengenai nilai pada bagian “Incident Management Metrics” dapat dilihat pada Gambar 4.9 dan Tabel 4.4.

C1 3 2 1 0

Score

C3

C2

Gambar 4.9 Incident Management Metrics

Berikut ini merupakan nilai rata-rata dari service operation area “Incident Management Metrics”. Untuk lebih lengkapnya dapat dilihat pada Tabel 4.4 dibawah ini.

Tabel 4.4 Score “Incident Management Metrics” Index C1 C2 C3

Score

Incident Management Metrics Incident Management's KPIs and metrics are defined and in place Incident Management Reports have been identified and put in place Metrics have been defined and are in place for Major Incidents

3 3 1

Service operation area yang terakhir yaitu “Management Process Interactions” (D). Pada bagian ini terdapat 5 atribut yang perlu dijawab oleh

65

responden. Untuk lebih lengkapnya dapat dilihat pada Gambar 4.10 dan Tabel 4.5 dibawah ini.

D1 4 3 2 D5

D2

1 0

Score

D4

D3

Gambar 4.10 Incident Management Process Interactions

Pada Tabel 4.5 dibawah ini merupakan penjelasan lebih lengkap mengenai nilai rata-rata dari service operation area “Management Process Interactions”.

Tabel 4.5 Score “Incident Management Process Interactions” Index D1 D2 D3 D4 D5

Incident Management Process Interactions Service Asset and Configuation Management is in place and available to Incident Resolution The relationship between Incident Management and Probem Management is understood A Root Case Procedure is in place as Problem Management as a process does not exist yet The Incident Manager/The Incident Proess is consulted as part of Change Management (post implementation reviews) Incidents related to releases are reported to the Change/Release Manager

66

Score

3 2 2 3 4

4.3.3 Struktur Dokumen Manajemen Insiden TI Saat ini Manajemen insiden TI yang dimiliki oleh divisi GSIT saat ini terdapat pada Panduan Operasional Data Center. Proses manajemen insiden TI ini dapat ditemukan pada Bab 7 dengan judul Panduan Pengelolaan Incident. Dokumen ini terakhir diperbaharui pada versi 05 bulan Agustus 2014. Dalam pengantar dokumen ini dijelaskan bahwa panduan dokumen pengelolaan insiden yang ada saat ini digunakan untuk mengatur hal-hal yang harus dilakukan oleh System Operator agar setiap insiden yang dilaporkan khususnya yang berhubungan dengan operasional Data Center dapat ditangani dengan cepat, baik yang ditangani oleh System Operator sendiri maupun yang diekskalasi kepada unit lain. Struktur dokumen manajemen insiden TI saat ini terdiri dari 6 bagian yang dibahas, diantaranya Pengelolaan Incident, Pelaporan Incident, Pencatatan Incident, Tindak Lanjut Incident, Monitoring Incident, dan terakhir adalah Laporan Incident. Pengelolaan Incident merupakan fungsi Helpdesk yang sangat penting sebagai single point of untuk penanganan gangguan/masalah, baik di Data Center, Kantor Cabang maupun di unit kerja Kantor Pusat. Tujuan utama pengelolaan Incident adalah mengembalikan layanan yang terganggu menjadi normal kembali sesegera mungkin serta meminimalkan dampak gangguan yang terjadi terhadap layanan kepada pengguna. Pelaporan Incident diperlukan agar insiden yang berhubungan dengan operasional Data Center dapat ditindak lanjuti dengan segera untuk menjaga availability sistem dan layanan TI. Pencatatan Incident dilakukan untuk mendokumentasikan laporan Incident yang diterima oleh helpdesk. Hal ini berfungsi untuk mencatat Incident apa saja yang terjadi, berapa banyak incident yang terjadi, dan berapa lama incident diselesaikan. Tindak lanjut Incident dilakukan setelah proses pencatatan incident telah dilakukan. Proses ini dilakukan oleh helpdesk dan unit terkait sampai incident yang terjadi dapat diatasi. Terdapat 2 cara yang dilakukan dalam proses

67

tindak lanjut insiden, diantaranya insiden diselesaikan sendiri oleh helpdesk atau dilakukan ekskalasi ke unit kerja terkait. Monitoring Incident dilakukan agar proses penanganan incident dapat diatasi dengan lebih cepat, efisien dan efektif. Yang bertanggung jawab melakukan monitoring adalah helpdesk, shift leader dan group leader. Laporan Incident dilakukan untuk memberikan laporan-laporan yang terkait dengan pengelolaan insiden yang terjadi baik harian maupun bulanan. Berikut merupakan ringkasan struktur panduan pengelolaan insiden TI yang dimiliki oleh PT. Bank ABC, Tbk saat ini (existing).

Tabel 4.6 Struktur Panduan Pengelolaan Incident Bab

Isi

Pengelolaan Incident

-

Pengantar Tujuan Pengelolaan Incident Pengelola Incident Tugas dan Tanggung jawab Helpdesk Informasi Incident Ketentuan penanganan incident Kriteria incident Pencatatan Incident Database solusi Daftar Problem solver

Pelaporan Incident

-

Pengantar Penanggung jawab atas pelaporan Jenis incident yang dilaporkan Sarana pelaporan Waktu pelaporan

Pencatatan Incident

-

Pengantar Incident Management Informasi yang dicatat Prosedur pencatatan

Tindak Lanjut Incident

-

Pengantar Penanganan incident Menyelesaikan sendiri Prosedur penyelesaian incident sendiri Eskalasi dan notifikasi Akses sarana SMS

68

- Format SMS - Proses eskalasi - Proses penanganan incident oleh system operator atas petunjuk PIC - Prosedur penyampaian incident pada saat pergantian shift Monitoring Incident

-

Laporan Incident

-

Pengantar Penanggung jawab monitoring Monitoring incident Proses update Daftar Problem Solver Proses pencatatan database solusi

Pengantar Jenis laporan incident Batas waktu dan penerima laporan Incident category dan sub category Service impact Service level call management Helpdesk Threshold service level call management helpdesk - Perhitungan threshold Response Acceptable Call (RAC) - Perhitungan threshold Success Call Ratio (SCR) - Perhitungan threshold Incoming Call (IC)

4.3.4 Pengembangan Tata Kelola Manajemen Insiden 4.3.4.1 Penentuan Target Maturity Level Dalam proses penyusunan tata kelola manajemen insiden TI, pihak manajemen memutuskan bahwa nilai pada setiap atribut yang terdapat pada masing-masing service operation area ditargetkan minimal pada angka 3. Pihak manajemen berpendapat, bahwa tata kelola manajemen insiden sebaiknya terdefinisikan terlebih dahulu, sebelum melangkah jauh dalam pengelolaan data yang ada. Meskipun beberapa atribut telah lebih dahulu berada pada tahapan yang lebih maju, tidak perlu dilakukan perubahan pada tahapan yang matang tersebut. Sesuai dengan karakteristik maturity level, angka 3 menunjukkan bahwa setidaknya proses/fungsi-fungsi yang ada harus terdokumentasikan dengan baik. Sehingga komitmen manajemen terhadap proses/fungsi-fungsi yang dimaksud dapat terlihat dengan jelas. 69

Berikut ini tabel asumsi target nilai yang telah ditetapkan oleh manajemen terhadap service operation area “Incident Management Process”. Untuk lebih jelasnya dapat dilihat pada Tabel 4.7.

Tabel 4.7 Target Score “Incident Management Process” Index A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27

Minimum Target

Incident Management Process We have defined Incident Management's Purpose, Goal and Objective We have defined Incident Management's Scope We have defined Incident Management's Value to the business We have defined Incident Management's Policies, Principles and basic concepts Timescales are agreed for all incident handling stages Incident Manager/Process Owner is in place Incident Models are defined Major Incidents are defined A Major Incident Procedure has been developed The "Incident Identification" process activity is specified The "Incident logging" process activity is specified The "Incident categorisation" process activity is specified The "Incident Prioritisation" process activity is specified The "Initial Diagnosis" process activity is specified The "Incident Escalation" process activity is specified The "Incident Identification" process activity is specified The "Investigation and Diagnosis" process activity is specified The "Resolution and recovery" process activity is specified The "Incident Closure" process activity is specified We have defined Incident Management's Triggers, Imputs, Outputs and interfaces We have defined Incident Management's Information Management reporting We have defined Incident Management's Challenges, Critical Success Factors and Risks Self-service Incident logging is in pace Incident tracking is in place Incident ownership is understood and in place Data entered into incidents at all stages is checked for completeness Incident Mangement Process review procedure is in place

3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

Selanjutnya, dibawah ini merupakan tabel asumsi target nilai yang telah ditetapkan oleh manajemen terhadap service operation area “Activities in Place

70

needed for the Success of Incident Mangement”. Untuk lebih jelasnya dapat dilihat pada Tabel 4.8.

Tabel 4.8 Target Score “Activities in Place needed for the Success of Incident Mangement” Index B1 B2 B3 B4 B5 B6 B7

Activities in Place needed for the Success of Incident Mangement The Service Desk function is defined The Service Desk is aware of their role at Tier 1/Level 1 Incident Management Tier2/Level teams are aware of their role in Incident Management Tier 3/Level teams are aware of their role In Incident Management External Suppliers are aware of their role in Incident Management Knowledge Bases are in place to Incicent Resolution at the Service Desk Workarounds are document and in the Knowledge Base

Minimum Target 3 3 3 3 3 3 3

Tabel asumsi target nilai selanjutnya yang telah ditetapkan oleh manajemen yaitu terhadap service operation area “Incident Management Metrics”. Untuk lebih jelasnya dapat dilihat pada Tabel 4.9.

Tabel 4.9 Target Score “Incident Management Metrics” Index C1 C2 C3

Incident Management Metrics Incident Management's KPIs and metrics are defined and in place Incident Management Reports have been identified and put in place Metrics have been defined and are in place for Major Incidents

Minimum Target 3 3 3

Dan untuk yang terakhir, dibawah ini merupakan tabel asumsi target nilai yang telah ditetapkan oleh manajemen terhadap service operation area “Incident Management Process Interactions”. Untuk lebih jelasnya dapat dilihat pada Tabel 4.10. Tabel 4.10 Target Score “Incident Management Process Interactions” Index D1 D2

Incident Management Process Interactions Service Asset and Configuation Management is in place and available to Incident Resolution The relationship between Incident Management and Probem Management is understood

71

Minimum Target 3 3

D3 D4 D5

A Root Case Procedure is in place as Problem Management as a process does not exist yet The Incident Manager/The Incident Proess is consulted as part of Change Management (post implementation reviews) Incidents related to releases are reported to the Change/Release Manager

3 3 3

4.3.4.2 Membandingkan Current vs Target Setelah dilakukan penilaian tingkat kematangan pada manajemen insiden TI yang ada saat ini (existing), serta pihak manajemen telah menentukan target nilai yang diperlukan dalam pengembangan tata kelola manajemen insiden TI sesuai kerangka kerja ITIL 2011, maka selanjutnya dilakukan pembandingan terhadap kedua kondisi tersebut. Hal ini dimaksudkan agar ditemukan gap / jarak antara kedua kondisi tersebut. Sehingga dapat dilakukan perbaikan terhadap kekurangan yang ada. Berikut ini merupakan perbandingan terhadap service operation area “Incident Management Process” antara kondisi saat ini dan kondisi yang diharapkan oleh pihak manajemen. Dimana terdapat gap / jarak yang tidak memenuhi dari kondisi yang diharapkan, yaitu terdapat pada index A3 “We have defined Incident Management's Value to the business” dengan score 2, A4 “We have defined Incident Management's Policies, Principles and basic concepts” dengan score 1, A5 “Timescales are agreed for all incident handling stages” dengan score 2, A7 “Incident Models are defined” dengan score 2, A20 “We have defined Incident Management's Triggers, Imputs, Outputs and interfaces” dengan score 2 dan A22 “We have defined Incident Management's Challenges, Critical Success Factors and Risks” dengan score 2.5 yang tidak memenuhi target score 3. Untuk lebih jelasnya dapat dilihat pada Tabel 4.11 dibawah ini.

Tabel 4.11 Current vs Target “Incident Management Process” Index A1 A2 A3 A4 A5

Minimum Target 3 3 3 3 3

72

Score

Memenuhi

4 4 2 1 2

√ √ × × ×

A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27

4 2 5 4 4 4 4 3 4 4 4 4 4 4 2 5 1 3 5 3 3 3

3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

√ × √ √ √ √ √ √ √ √ √ √ √ √ × √ × √ √ √ √ √

Pada Tabel 4.12 dibawah ini merupakan perbandingan pada service operation area “Activities in Place needed for the Success of Incident Mangement. Dapat dilihat bahwa tidak ditemukan gap / jarak pada bagian ini.

Tabel 4.12 Current vs Target “Activities in Place needed for the Success of Incident Mangement” Index B1 B2 B3 B4 B5 B6 B7

Minimum Target 3 3 3 3 3 3 3

Score

Memenuhi

3 4 2 2 2 3 3

√ √ × × × √ √

Pada perbandingan service operation area “Incident Management Metrics” dibawah ini, terdapat gap pada kondisi saat ini yang tidak memenuhi kondisi target dari pihak manajemen, yaitu pada index C3, dimana index yang 73

dimaksud yaitu pada atribut “Metrics have been defined and are in place for Major Incidents” dengan nilai 1. Untuk lebih jelasnya dapat dilihat pada Tabel 4.13 dibawah ini.

Tabel 4.13 Current vs Target “Incident Management Metrics” Index C1 C2 C3

Minimum Target 3 3 3

Score

Memenuhi

3 3 1

√ √ ×

Perbandingan dua kondisi antara kondisi saat ini dan kondisi yang diharapkan terakhir dilakukan pada service operation area “Incident Management Process Interactions”. Pada bagian ini ditemukan gap / jarak antara dua kondisi yang ada, yaitu pada index D2 “The relationship between Incident Management and Probem Management is understood” dengan score 2 dan D3 “A Root Case Procedure is in place as Problem Management as a process does not exist yet” dengan score 2. Untuk lebih jelasnya mengenai perbandingan yang ada, dapat dilihat pada Tabel 4.14 dibawah ini.

Tabel 4.14 Current vs Target “Incident Management Process Interactions” Index D1 D2 D3 D4 D5

Minimum Target 3 3 3 3 3

Score

Memenuhi

3 2 2 3 4

√ √ √ √ √

Dari pembandingan terhadap dua kondisi pada seluruh atribut yang ada, ditemukan 3 atribut yang memiliki nilai 1, hal ini menunjukkan bahwa perlu adanya kebutuhan pembuatan prosedur baru pada divisi GSIT untuk atribut tersebut. Disamping itu juga ditemukan nilai 2 yang menunjukkan bahwa prosedur/fungsi tidak terdokumentasi dengan baik, namun telah dilakukan secara rutin dalam operasional.

74

Dapat diambil kesimpulan bahwa pada kondisi yang tidak terpenuhi antara hasil penilaian tingkat kematangan penerapan tata kelola manajemen insiden TI saat ini, dibandingkan dengan target yang telah ditetapkan oleh perusahaan, untuk nilai 1 terdapat pada service operation area “Incident Management Process” pada index A4, A22, dan service operation area “Incident Management Metrics” pada index C3. Sedangkan untuk nilai 2 ditemukan pada service operation area “Incident Management Process” pada index A3, A5, A7, dan A20, serta “Activities in Place needed for the Success of Incident Mangement” pada index B3, B4 dan B5 dan yang terakhir pada “Incident Management Process Interactions” pada index D2 dan D3. Sehingga perlu adanya revisi terhadap dokumen Prosedur Pengelolaan Incident yang ada saat ini.

4.3.4.3 Review Dokumen Pendukung Berikut ini merupakan penjelasan mengenai dokumen pendukung terkait proses assessment yang telah dilakukan terhadap dokumen yang dimiliki oleh sub divisi IIO pada divisi GSIT PT Bank ABC, Tbk. Tabel 4.15 Dokumen Pendukung “Incident Management Process” Assessment

Dokumen Pendukung

Tujuan, sasaran dan target dalam proses manajemen insiden Ruang lingkup dari proses manajemen insiden Nilai dari proses manejemen insiden terhadap bisnis Kebijakan, prinsip dan konsep-konsep dasar dari proses manajemen insiden Skala waktu yang ada telah disetujui untuk seluruh tahapan penyelesaian insiden Manajer insiden / pemilik proses tersedia Model dari insiden telah didefinisikan

Panduan Operasional DC – Bab 7, halaman 4 – Tujuan pengelolaan incident ISO 9001:2008 – Pengelolaan incident, halaman 1

Memenuhi √ Ya √ Ya

-

× Tidak

-

× Tidak

-

× Tidak

Panduan Operasional DC – Bab 7, halaman 4 – Pengelola incident

√ Ya

-

× Tidak

75

Panduan Operasional DC – Bab 7, halaman 7 – Jenis incident yang dilaporkan Panduan Operasional DC – Bab 7, Pengembangan prosedur halaman 11 – Eskalasi dan penanganan insiden besar notifikasi Panduan Operasional DC – Bab 7, Proses “Identifikasi Insiden” halaman 10 – Penanganan incident Panduan Operasional DC – Bab 7, Proses “Pencatatan Insiden” halaman 8 & 9 – Pencatatan incident Panduan Operasional DC – Bab 7, Proses “Pengelompokan halaman 21 – Incident Category & Insiden” Sub Category Panduan Operasional DC – Bab 7, Proses “Prioritas Insiden” halaman 5 – Kriteria incident Panduan Operasional DC – Bab 7, Proses “Diagnosa Awal” halaman 10 – Prosedur penyelesaian incident sendiri Panduan Operasional DC – Bab 7, Proses “Eskalasi Insiden” halaman 12-15 – Tindak Lanjut Incident Panduan Operasional DC – Bab 7, Proses “Identifikasi Insiden” halaman 10 – Penanganan incident Panduan Operasional DC – Bab 7, Proses “Investigasi dan halaman 10 – Prosedur Diagnosa” penyelesaian incident sendiri Panduan Operasional DC – Bab 7, Proses “Penyelesaian dan halaman 10 – Prosedur Pemulihan Insiden” penyelesaian incident sendiri Panduan Operasional DC – Bab 7, Proses “Penutupan Insiden” halaman 5 – Ketentuan penanganan incident Pemicu, input, output, dan tampilan dari manajemen insiden Pelaporan informasi dari Panduan Operasional DC – Bab 7, manajemen insiden halaman 20-23 – Laporan incident Tantangan, faktor penentu kesuksesan dan resiko dari manajemen insiden Panduan Operasional DC – Bab 7, Pencatatan insiden yang halaman 10 – Menyelesaikan dilakukan sendiri sendiri Panduan Operasional DC – Bab 7, Penelusuran insiden telah tersedia halaman 20 – Laporan incident Insiden besar telah didefinisikan

76

√ Ya

√ Ya √ Ya √ Ya

√ Ya √ Ya √ Ya

√ Ya √ Ya √ Ya

√ Ya

√ Ya

× Tidak √ Ya × Tidak

√ Ya √ Ya

Kepemilikan insiden dapat dimengerti Data yang diinputkan telah di cek untuk kelengkapannya Prosedur peninjauan manajemen insiden

Panduan Operasional DC – Bab 7, halaman 4 – Pengelola incident Panduan Operasional DC – Bab 7, halaman 10 – Prosedur penyelesaian incident sendiri Panduan Operasional DC – Bab 7, halaman 20 – Laporan Incident

√ Ya √ Ya √ Ya

Tabel 4.16 Dokumen Pendukung “Activities in Place needed for the Success of Incident Mangement” Assessment

Dokumen Pendukung

Fungsi Service Desk telah didefinisikan Service desk mengetahui perannya pada Manajemen Insiden di tier/level 1 Tim pada tier/level 2 telah mengetahui perannya pada Manajemen Insiden Tim pada tier/level 3 telah mengetahui perannya pada Manajemen Insiden Pihak supplier eksternal telah mengetahui perannya pada manajemen insiden Pengetahuan-pengetahuan dasar telah ada untuk mendukung penyelesaian insiden pada service desk Solusi (sementara) penyelesaian insiden telah terdokumentasi dan menjadi bagian dari pengetahuan dasar

Panduan Operasional DC – Bab 7, halaman 4 – Pengantar Panduan Operasional DC – Bab 7, halaman 4 – Tugas & tanggung jawab Helpdesk

Memenuhi √ Ya √ Ya

-

× Tidak

-

× Tidak

-

× Tidak

Panduan Operasional DC – Bab 7, halaman 6 – Database Solusi

√ Ya

Panduan Operasional DC – Bab 7, halaman 6 – Database Solusi

√ Ya

Tabel 4.17 Dokumen Pendukung “Incident Management Metrics” Assessment

Dokumen Pendukung

Memenuhi

KPI (key performance indicator) dari proses manajemen insiden telah ditentukan dan tersedia

Panduan Operasional DC – Bab 7, halaman 20 – Laporan Incident

√ Ya

77

Laporan Manajemen Insiden Panduan Operasional DC – Bab 7, telah di identifikasi dan halaman 20 – Laporan Incident tersedia Metrik telah ditentukan dan tersedia untuk insiden besar

√ Ya × Tidak

Tabel 4.18 Dokumen Pendukung “Incident Management Process Interactions” Assessment Panduan konfigurasi dan layanan asset ada dan mampu mendukung penyelesaian insiden Hubungan antara Manajemen Insiden dan Manajemen Masalah dapat dimengerti Prosedur akar masalah ada sebagai bagian dari manajemen permasalahan Manajer insiden / proses insiden diperiksa sebagai bagian dari Change Management (tinjauan setelah implementasi) Insiden yang berkaitan dengan peluncuran sebuah produk dilaporkan kepada pihak Change/Release Manager

Dokumen Pendukung

Memenuhi

Panduan Operasional DC – Bab 7, halaman 6 – Database Solusi

√ Ya

-

× Tidak

-

× Tidak

Panduan Operasional DC – Bab 7, halaman 20 – Batas Waktu dan penerima laporan

√ Ya

Panduan Operasional DC – Bab 7, halaman 20 – Batas Waktu dan penerima laporan

√ Ya

4.3.5 Struktur Dokumen Tata Kelola Manajemen Insiden Dari hasil data yang diperoleh dan dianalisa, menunjukkan bahwa sebagian besar struktur tata kelola manajemen insiden TI yang ada saat ini telah sesuai dengan kerangka kerja ITIL 2011 yang diharapkan oleh pihak manajemen. Beberapa proses tata kelola manajemen insiden TI telah tersedia dan terdokumentasi dengan baik. Berdasarkan hasil penilaian melalui kuesioner, dapat diambil kesimpulan bahwa pada kondisi yang tidak terpenuhi antara hasil penilaian tingkat 78

kematangan penerapan tata kelola manajemen insiden TI saat ini, dibandingkan dengan target yang telah ditetapkan oleh perusahaan, untuk nilai 1 terdapat pada service operation area “Incident Management Process” pada index A4, A22, dan service operation area “Incident Management Metrics” pada index C3. Sedangkan untuk nilai 2 ditemukan pada service operation area “Incident Management Process” pada index A3, A5, A7, dan A20, serta “Activities in Place needed for the Success of Incident Mangement” pada index B3, B4 dan B5 dan yang terakhir pada “Incident Management Process Interactions” pada index D2 dan D3. Sehingga perlu adanya revisi terhadap dokumen Prosedur Pengelolaan Incident yang ada saat ini. Berdasarkan analisa tersebut, ditemukan 3 atribut yang memiliki nilai 1, hal ini menunjukkan bahwa perlu adanya kebutuhan pembuatan prosedur baru pada divisi GSIT untuk atribut tersebut. Disamping itu juga ditemukan nilai 2 yang menunjukkan bahwa prosedur/fungsi tidak terdokumentasi dengan baik, namun telah dilakukan secara rutin dalam operasional. Ketidak adanya dokumen dalam

proses

review

dokumen

pendukung

dikarenakan

tidak

terdokumentasikannya segala proses yang ada dengan baik. Sehingga diperlukan adanya perbaikan terhadap dokumentasi tata kelola manajemen insiden TI yang ada saat ini. Sehingga apa yang diharapkan oleh manajemen terkait manajemen insiden TI yang baik dapat dicapai.

79

80

BAB 5 DESAIN DOKUMEN TATA KELOLA Pada bab ini akan dijelaskan mengenai contoh desain dokumen yang dilakukan perubahan terkait analisa yang telah dilakukan pada bab sebelumnya. Dokumen yang ditampilkan pada bab ini merupakan penyesuaian atas proses assessment yang telah dilakukan. Hanya pada bagian tertentu yang dilakukan perubahan terkait kurang lengkapnya persyaratan yang diinginkan oleh pihak manajemen terhadap tata kelola manajemen insiden TI berdasarkan kerangka kerja ITIL 2011. Disamping itu juga terdapat penjelasan mengenai proses verifikasi terkait penelitian serta validasi untuk penyesuaian Tata Kelola Manajemen Insiden TI yang baru berdasarkan ITIL 2011. 5.1. Verifikasi Tata Kelola Manajemen Insiden TI Pada proses verifikasi, dilakukan beberapa perbaikan terkait dengan adanya penyesuaian tata kelola manajemen insiden TI pada divisi GSIT PT Bank ABC, Tbk. Terdapat 5 tahap verifikasi yang telah dilakukan pada saat penelitian. Proses verifikasi ini diwakilkan oleh DC Assistant Manager (Group Leader). Berikut ini merupakan tahapan verifikasi yang telah dilakukan:

Tabel 5.1 Tahapan Verifikasi Tata Kelola Manajemen Insiden TI Tahap Verifikasi

Penyesuaian

Oleh

1

Sasaran Proses Manajemen Insiden

DC Assistant Manager (Group Leader)

2

Peran dan Tanggung Jawab:

DC Assistant Manager (Group Leader)

 Grup Aplikasi / PIC  Pihak Ketiga / vendor 3

Target Waktu

DC Assistant Manager (Group Leader)

4

Penentuan Prioritas

DC Assistant Manager

81

(Group Leader) 5

Penulisan

Sarana dan Eskalasi

Notifikasi DC Assistant Manager (Group Leader)

Setelah dilakukan verifikasi dari kelima tahapan verifikasi diatas, pihak manajemen berpendapat bahwa tidak diperlukan penyesuaian kembali atas dokumen yang telah dibuat. Sehingga proses verifikasi telah final dilakukan.

5.2. Validasi Tata Kelola Manajemen Insiden TI Setelah dilakukan proses verifikasi, pihak manajemen menyatakan bahwa dokumen tata kelola manajemen insiden TI berdasarkan kerangka kerja ITIL 2011 telah dapat disahkan dan dapat digunakan sebagai mana mestinya. Pada proses validasi, pihak manajemen memutuskan bahwa Tata Kelola Manajemen Insiden TI yang baru dapat efektif digunakan pada tanggal 1 Februari 2016, setelah dilakukannya sosialisasi terhadap pembaharuan prosedur tersebut.

5.3. Perubahan Tata Kelola Manajemen Insiden TI Berdasarkan hasil analisa yang telah dilakukan terhadap tata kelola manajemen insiden TI pada PT. Bank ABC, Tbk, hingga pada proses verifikasi dan validasi dokumen, terdapat perubahan tata kelola antara dokumen existing dengan dokumen yang diharapkan sesuai kerangka kerja ITIL 2011. Berikut struktur dokumen tata kelola manajemen insiden TI (existing):

Tabel 5.2 Tata Kelola Manajemen Insiden TI (existing) Bab Pengelolaan Incident

Isi -

Pengantar Tujuan Pengelolaan Incident Pengelola Incident Tugas dan Tanggung jawab Helpdesk Informasi Incident Ketentuan penanganan incident Kriteria incident Pencatatan Incident Database solusi 82

- Daftar Problem solver Pelaporan Incident

-

Pengantar Penanggung jawab atas pelaporan Jenis incident yang dilaporkan Sarana pelaporan Waktu pelaporan

Pencatatan Incident

-

Pengantar Incident Management Informasi yang dicatat Prosedur pencatatan

Tindak Lanjut Incident

-

Monitoring Incident

-

Laporan Incident

-

Pengantar Penanganan incident Menyelesaikan sendiri Prosedur penyelesaian incident sendiri Eskalasi dan notifikasi Akses sarana SMS Format SMS Proses eskalasi Proses penanganan incident oleh system operator atas petunjuk PIC - Prosedur penyampaian incident pada saat pergantian shift Pengantar Penanggung jawab monitoring Monitoring incident Proses update Daftar Problem Solver Proses pencatatan database solusi

Pengantar Jenis laporan incident Batas waktu dan penerima laporan Incident category dan sub category Service impact Service level call management Helpdesk Threshold service level call management helpdesk - Perhitungan threshold Response Acceptable Call (RAC) - Perhitungan threshold Success Call Ratio (SCR) - Perhitungan threshold Incoming Call (IC)

83

Berikut ini merupakan struktur dokumen tata kelola manajemen insiden TI yang sesuai dengan ITIL 2011:

Tabel 5.3 Tata Kelola Manajemen Insiden TI berdasarkan ITIL 2011 Bab Proses Manajemen Insiden

Isi -

Peran dan Tanggung Jawab

Tujuan Utama Definisi Proses Sasaran Nilai Bisnis Kebijakan Dasar Definisi - Dampak - Grup Aplikasi / PIC - Insiden (Incident) - Pelanggan - Prioritas (Priority) - Service Level Agreement (SLA) - Service Level Target - Solusi Penyelesaian (Resolution) - Tanggapan (Response) - Tingkat Kerugian (Severity) - Tingkat Dukungan Penyelesaian Masalah Cakupan (scope) - Pengecualian (Exclusions) Input dan Output Metrics Tantangan dan Faktor Penentu Kesuksesan

- Service Desk - Grup Aplikasi / PIC - Pihak Ketiga (vendor)

Kategori, Target Waktu, - Kategori Insiden Prioritas, dan Eskalasi - Penentuan Prioritas - Target Waktu Insiden Alur Proses

- Alur Penanganan Insiden Saat Jam Kantor - Alur Penanganan Insiden Diluar Jam Kantor

Eskalasi Insiden

-

Eskalasi Fungsional (lintas unit kerja) Notifikasi Eskalasi Sarana dan Format Penulisan Notifikasi Eskalasi Proses Eskalasi Insiden - Notifikasi dan Eskalasi Gangguan Berdampak

84

Online - Notifikasi dan Eskalasi Gangguan Tidak Berdampak Online RACI Chart

RACI Chart

Laporan Insiden

-

Jenis Laporan Insiden Batas Waktu dan Menerima laporan Service level call management Helpdesk Threshold service level call management helpdesk - Incoming Call Management Helpdesk - Perhitungan Service Level - Perhitungan threshold Response Acceptable Call (RAC) - Perhitungan threshold Success Call Ratio (SCR) - Perhitungan threshold Incoming Call (IC)

Berdasarkan hasil analisa yang telah dilakukan terhadap tata kelola manajemen insiden TI pada PT. Bank ABC, Tbk, hingga pada proses verifikasi dan validasi dokumen, terdapat perubahan tata kelola yang terjadi pada dokumen tata kelola manajemen insiden TI yang ada. Berikut perubahan yang terjadi:

Tabel 5.4 Perubahan Tata Kelola Manajemen Insiden TI Versi Dokumen 01

Revisi / Penambahan

Mulai Berlaku

01 Feb 2016 Penambahan:  Penjelasan Nilai Bisnis  Kebijakan Dasar  Target Waktu  Notifikasi Eskalasi (jenis incident)  Input dan Output  Tantangan dan Faktor Penentu Kesuksesan  Peran dan Tanggung Jawab - Service Desk - Grup Aplikasi / PIC - Pihak Ketiga (Vendor)  Metrics  Solusi Penyelesaian

85

5.4. Tata Kelola Manajemen Insiden TI

86

TATA KELOLA MANAJEMEN INSIDEN TI

No. Dokumen Versi Tanggal Efektif

Disiapkan

: ABC-IIO-IMP-01 : 1.0 : 01 Februari 2016

Nama

Jabatan

Valentino Budi Pratomo

IT Specialist

Tanda Tangan

Ditinjau Disetujui

STATUS

COPY NO

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 2 dari 25

MANAJEMEN INSIDEN TI

DAFTAR ISI

DAFTAR ISI ...................................................................................................... 2 TENTANG DOKUMEN .................................................................................... 4 BAB 1. PROSES MANAJEMEN INSIDEN .................................................... 6 1.1. Tujuan Utama ........................................................................................ 6 1.2. Definisi Proses ....................................................................................... 6 1.3. Sasaran .................................................................................................. 6 1.4. Nilai Bisnis ............................................................................................ 7 1.5. Kebijakan Dasar .................................................................................... 7 1.6. Definisi .................................................................................................. 7 1.6.1.

Dampak (Impact) ........................................................................ 7

1.6.2.

Grup Aplikasi / PIC .................................................................... 7

1.6.3.

Insiden (Incident) ........................................................................ 7

1.6.4.

Pelanggan ................................................................................... 8

1.6.5.

Prioritas (Priority) ....................................................................... 8

1.6.6.

Service Level Agreement (SLA) ................................................... 8

1.6.7.

Service Level Target.................................................................... 8

1.6.8.

Solusi Penyelesaian (Resolution) ................................................. 8

1.6.9.

Tanggapan (Response) ................................................................ 9

1.6.10.

Tingkat Kerugian (Severity) ........................................................ 9

1.6.11.

Tingkat Dukungan Penyelesaian Masalah.................................... 9

1.7. Cakupan (Scope) .................................................................................... 9 1.7.1.

Pengecualian (Exclusions) ........................................................... 9

1.8. Input dan Output ................................................................................. 10 1.9. Metrics ................................................................................................ 10 1.10.

Tantangan dan Faktor Penentu Kesuksesan ...................................... 10

BAB 2. PERAN DAN TANGGUNG JAWAB ................................................ 11 2.1. Service Desk ........................................................................................ 11 2.2. Grup Aplikasi / PIC ............................................................................. 12

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 3 dari 25

MANAJEMEN INSIDEN TI

2.3. Pihak Ketiga (Vendor) ......................................................................... 12 BAB 3. KATEGORI, TARGET WAKTU, PRIORITAS, DAN ESKALASI INSIDEN .......................................................................................................... 13 3.1. Kategori Insiden .................................................................................. 13 3.2. Penentuan Prioritas .............................................................................. 14 3.3. Target Waktu ....................................................................................... 14 BAB 4. ALUR PROSES................................................................................... 15 4.1. Alur Penanganan Insiden Saat Jam Kantor ........................................... 15 4.2. Alur Penanganan Insiden Diluar Jam Kantor........................................ 16 BAB 5. ESKALASI INSIDEN ......................................................................... 17 5.1. Eskalasi Fungsional (Lintas Unit Kerja) ............................................... 17 5.2. Notifikasi Eskalasi ............................................................................... 17 5.3. Sarana dan Format Penulisan Notifikasi Eskalasi ................................. 18 5.4. Proses Eskalasi Insiden ........................................................................ 20 5.4.1.

Notifikasi dan Eskalasi Gangguan Berdampak Online ............... 20

5.4.2.

Notifikasi dan Eskalasi Gangguan Tidak Berdampak Online ..... 21

BAB 6. RACI CHART ..................................................................................... 22 BAB 7. LAPORAN INSIDEN ......................................................................... 23 7.1. Jenis Laporan Insiden .......................................................................... 23 7.2. Batas Waktu dan Menerima Laporan ................................................... 23 7.3. Service Level Call Management Helpdesk............................................ 24 7.4. Treshold Service Level Call Management Helpdesk ............................. 24 7.5. Incoming Call Management Helpdesk.................................................. 24 7.6. Perhitungan Service Level .................................................................... 25 7.6.1.

Perhitungan Treshold Response Acceptable Call (RAC) ............ 25

7.6.2.

Perhitungan Treshold Success Call Ratio (SCR)........................ 25

7.6.3.

Perhitungan Treshold Incoming Call (IC) .................................. 25

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 4 dari 25

MANAJEMEN INSIDEN TI

TENTANG DOKUMEN Dokumen ini menjelaskan Proses Manajemen Insiden TI yang terdapat pada divisi GSIT, PT. Bank ABC, Tbk. Dokumen ini dapat digunakan sebagai panduan dalam penanganan gangguan/masalah, baik di Data Center, Kantor Cabang maupun di unit kerja Kantor Pusat.

Siapa yang dapat menggunakan dokumen ini? Dokumen ini dapat digunakan oleh:  Staff yang bertangggung jawab terhadap layanan manajemen insiden TI (Shift Leader, Group Leader)  Staff yang terkait dalam operasi dan manajemen dari proses insiden (Helpdesk, System Operator)

Ringkasan perubahan Berikut ini merupakan ringkasan perubahan pada dokumen ini.

Versi

Tanggal

Dibuat oleh

Deskripsi perubahan

1.0

01 Januari 2016

Valentino Budi P

Versi awal (ditambahkan dari dokumen lama)

Apabila terdapat perubahan yang signifikan pada dokumen ini, penulisan versi dokumen merupakan kelipatan dari 1.0. Sedangkan apabila perubahan dokumen yang terjadi hanya untuk memberikan kejelasan, pembetulan untuk kemudahan membaca dan serta tidak terdapat perubahan yang berarti atau penemuan baru, penulisan dokumen akan di tulis dalam kelipatan 0.1.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 5 dari 25

MANAJEMEN INSIDEN TI

Berikut ini urutan versi dokumen Tata Kelola Manajemen Insiden TI sesuai dengan mulai berlakunya dokumen.

Versi Dokumen 01

Mulai Berlaku

Revisi / Penambahan

01 Feb 2016 Penambahan:  Penjelasan Nilai Bisnis  Kebijakan Dasar  Target Waktu  Notifikasi Eskalasi (jenis incident)  Input dan Output  Tantangan dan Faktor Penentu Kesuksesan  Peran dan Tanggung Jawab - Service Desk - Grup Aplikasi / PIC - Pihak Ketiga (Vendor)  Metrics  Solusi Penyelesaian

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 6 dari 25

MANAJEMEN INSIDEN TI

BAB 1. PROSES MANAJEMEN INSIDEN 0.1. Tujuan Utama Tujuan utama dari adanya proses manajemen insiden adalah: 

Mengembalikan layanan yang terganggu menjadi normal kembali sesegera mungkin.



Meminimalkan dampak gangguan yang terjadi terhadap layanan kepada pengguna.

Kedua tujuan utama tersebut tentu diimbangi oleh kualitas layanan yang terukur secara teratur, dimana layanan operasi yang dimaksud terkait batas SLA yang telah ditetapkan. 0.2. Definisi Proses Proses Manajemen Insiden TI yang dimaksud yaitu pencatatan terkait kejadian apapun yang dapat mengganggu atau dapat menyebabkan gangguan terhadap layanan TI. Gangguan dapat terjadi pada komponen Data Center (aplikasi, hardware, network, infrastruktur) yang diketahui melalui Warning message pada perangkat yang terpasang atau pada console, serta dapat berupa informasi yang diberikan oleh atau pihak Call Center nasabah. 0.3. Sasaran Sasaran dari dilakukannya manajemen insiden TI adalah: 

Insiden dapat tercatat dengan baik



Insiden dapat ditelusuri dengan mudah



Status insiden dapat terlaporkan dengan baik



Insiden yang belum terselesaikan dapat termonitor dengan baik



Insiden terprioritaskan dengan baik dan dapat ditangani dengan urutan yang tepat



Solusi dan penyelesaian yang diberikan sesuai dengan SLA yang ada.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 7 dari 25

MANAJEMEN INSIDEN TI

0.4. Nilai Bisnis Proses manajemen insiden TI digunakan sebagai proses pencatatan dan pengelolaan insiden, agar segala proses gangguan/masalah yang pernah terjadi dapat tercatat dengan baik, serta meminimalisir terjadinya insiden dikemudian hari. Sehingga segala macam bentuk gangguan/masalah dapat dihindari seoptimal mungkin. 0.5. Kebijakan Dasar Tata kelola manajemen insiden TI digunakan sebagai penunjang dari Kebijakan Dasar Manajemen Risiko Penggunaan TI (KDMRPTI). 0.6. Definisi 1.6.1. Dampak (Impact) Dampak dari adanya gangguan yang terdapat pada Data Center, baik yang dialami oleh kantor cabang, nasabah, maupun unit kerja kantor pusat, digolongkan menjadi 2 jenis, yaitu: Jenis Gangguan online Data Center

Pengertian Gangguan yang berdampak Service Delivery Online Data Center, sehingga membutuhkan waktu penanganan yang cepat dan akurat Gangguan tidak online Data Gangguan yang tidak berdampak pada Service Center Delivery Online Data Center 1.6.2. Grup Aplikasi / PIC Grup Aplikasi merupakan pihak yang bertanggung jawab terhadap aplikasi yang ditangani saat terjadi gangguan/masalah. Grup aplikasi biasa disebut juga sebagai PIC (Person In Charge) Aplikasi atau service provider. Grup Aplikasi merupakan tingkatan penyelesaian masalah setelah Service Desk / Tier-1. 1.6.3. Insiden (Incident) Insiden (incident) adalah segala peristiwa atau kejadian yang menyebabkan terjadinya gangguan layanan di IT Service Delivery Management

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 8 dari 25

MANAJEMEN INSIDEN TI

dan harus segera dilakukan penanganan untuk mengembalikan ke keadaan normalnya. 1.6.4. Pelanggan Pelanggan yang dimaksud pada dokumen ini adalah pengguna jasa yang melaporkan adanya insiden kepada pihak Helpdesk. Pelanggan merupakan yang melaporkan adanya gangguan pada sistem yang ditangani, ataupun call center nasabah yang melaporkan gangguan yang diterima dari laporan beberapa nasabah yang bermasalah. 1.6.5. Prioritas (Priority) Prioritas (priority) merupakan pengembangan dari kombinasi Dampak (Impact) dan Tingkat Kerugian (Severity). Untuk penjelasan lebih lengkap mengenai prioritas dapat dilihat pada bagian “Penentuan Prioritas”. 1.6.6. Service Level Agreement (SLA) SLA adalah persetujuan antara IT Service Delivery Management dengan pelanggan terkait layanan yang diberikan agar sesuai dengan kebutuhan yang diharapkan. 1.6.7. Service Level Target Service Level Target adalah komitmen yang tertulis pada SLA. Service Level Target didasarkan pada Service Level Requirement, dan dibutuhkan untuk selalu memastikan bahwa layanan TI dapat selalu memenuhi Service Level Requirements. 1.6.8. Solusi Penyelesaian (Resolution) Proses penyelesaiaan gangguan/masalah dengan mengembalikan kondisi hingga ke keadaan normal kembali. Pada beberapa kasus, solusi yang diberikan dapat berupa solusi sementara hingga akar masalah dari insiden tersebut dapat di identifikasi dan diperbaiki.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 9 dari 25

MANAJEMEN INSIDEN TI

1.6.9. Tanggapan (Response) Waktu yang telah dihabiskan antara waktu pelaporan adanya insiden, hingga insiden tersebut ditugaskan kepada individu untuk ditangani. 1.6.10. Tingkat Kerugian (Severity) Tingkat kerugian (severity) ditentukan oleh seberapa besar dibatasi dalam melakukan pekerjaannya. Terdapat 3 jenis tingkatan: 

3 – Low – mencegah dalam melakukan sebagian dari tugasnya



2 – Medium – mencegah dalam melakukan fungsi sensitif saat kritis



1 – High – layanan atau bagian besar dari layanan tidak tersedia

Tingkat kerugian (severity) dari sebuah insiden akan digunakan dalam menentukan prioritas penyelesaian yang akan diberikan. 1.6.11. Tingkat Dukungan Penyelesaian Masalah Dalam menangani setiap masalah / gangguan yang terjadi, terdapat tingkatan yang digunakan dalam penyelesaian masalah, diantaranya: Level First Level / tier-1 Second Level / tier-2 Third Level / tier-3

Dilakukan oleh Helpdesk & System Operator Grup Aplikasi Penanggung Jawab Grup Aplikasi

0.7. Cakupan (Scope) Proses manajemen insiden TI mencakup penerimaan laporan insiden yang dapat bersumber dari call masuk ke staff call center atau system operator, maupun alert / warning message yang ditampilkan oleh monitoring tools IT Service Delivery Management. 0.7.1. Pengecualian (Exclusions) Proses pengajuan (Request fulfillment) seperti Permintaan Layanan dan Permintaan Katalog Layanan tidak ditangani dalam proses ini.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 10 dari 25

MANAJEMEN INSIDEN TI

Analisa akar masalah dari permasalahan awal dari sebuah insiden tidak ditangani oleh proses ini. Hal ini dapat mengacu pada Manajemen Masalah/Problem DC. Proses manajemen insiden TI dapat dikatakan selesai apabila layanan yang terganggu dapat berjalan normal kembali. 0.8. Input dan Output Input Insiden (verbal ataupun tertulis) Insiden (alert/warning message) Database solusi (solusi sementara) Tabel Kategori Aturan penugasan

From Pelanggan Monitoring Tools Grup Aplikasi / PIC Grup Aplikasi / PIC Grup Aplikasi / PIC

Output To Pemberitahuan ke pelanggan saat Pelanggan insiden telah ditutup Laporan Insiden Manajemen 0.9. Metrics Tujuan Metric Proses penelusuran metric Untuk menemukan insiden # jumlah insiden berdasarkan tipe, yang masih dalam proses status dan pelanggan – lihat lebih pada rentang waktu yang lengkap di bagian “Laporan” reasonable, frekuensi munculnya tipe insiden serta untuk tertentu, menentukan apakah terdapat bottlenecks. 0.10. Tantangan dan Faktor Penentu Kesuksesan 

Ditanganinya insiden sesuai batas waktu yang ditentukan



Tidak ada nya kelengahan terhadap insiden yang terjadi



Pencatatan insiden dilakukan dengan baik sesuai prosedur yang ada



Insiden yang telah selesai, dinyatakan dengan penutupan insiden yang telah dibuka sebelumnya.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk

IT Service Delivery Management

PROSEDUR Tanggal Efektif : 01 Februari 2016

No. Revisi

: 1.0

Halaman

: 11 dari 25

MANAJEMEN INSIDEN TI

BAB 2. PERAN DAN TANGGUNG JAWAB 2.1. Service Desk Service Desk bertanggung jawab atas pelaporan insiden yang terjadi di divisi GSIT. Service Desk merupakan first level / tier-1 dalam penanganan insiden. Pada divisi GSIT, peran service desk dibagi menjadi 2 bagian, yaitu: a. Helpdesk Bertanggung jawab untuk waktu pelaporan insiden selama jam kerja. b. System Operator Bertanggung jawab untuk waktu pelaporan insiden selama 24 jam. Berikut ini tugas dan tanggung jawab yang dimiliki: 

Single

Point

of



untuk

penanganan

masalah

yang

berhubungan dengan komputerisasi baik di Data Center maupun di Cabang atau unit kerja Kantor Pusat. 

Melakukan pencatatan setiap call yang masuk yang berhubungan dengan insiden yang terjadi.



Melakukan determinasi dan bertindak sebagai First Level untuk masalah di Cabang atau unit kerja Kantor Pusat dan mencatat langkah-langkah yang telah dilakukan di incident log serta mengubah status menjadi resolved.



Melakukan eskalasi masalah yang tidak dapat ditangani Helpdesk ke Second Level / Tier-2 serta memonitor hasil penanganannya.



Melakukan eskalasi dan notifikasi ke level yang lebih tinggi (Third Level – Tier 3) untuk masalah yang belum terselesaikan oleh Second Level /Tier-2 dalam kurun waktu yang telah ditentukan.



Merekapitulasi

insiden

yang

terjadi

setiap

bulannya,

serta

menginformasikan ke Problem Management Controller agar ditindak lanjuti dan didapat solusi permanen.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 12 dari 25

MANAJEMEN INSIDEN TI

2.2. Grup Aplikasi / PIC Grup Aplikasi / PIC bertanggung jawab terhadap penyelesaian insiden yang dilaporkan oleh first level /tier-1. Grup aplikasi dibagi menjadi 2 bagian, diantaranya: a. PIC Aplikasi / tier-2 Bertanggung jawab terhadap penyelesaian masalah yang dilaporkan oleh first level /tier-1. b. Penanggung Jawab Grup Aplikasi / tier-3 Bertanggung

jawab

terhadap

penyelesaian

masalah

yang

diinformasikan oleh second level /tier-2. 2.3. Pihak Ketiga (Vendor) Vendor memiliki peran sebagai penyedia solusi alternative, sebagai sarana dalam penyelesaian masalah maupun pencegahan terhadap terjadinya gangguan/masalah dikemudian hari. Vendor dihadirkan dalam rangkaian penyelesaiaan insiden atas inisiatif Grup Aplikasi.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 13 dari 25

MANAJEMEN INSIDEN TI

BAB 3. KATEGORI, TARGET WAKTU, PRIORITAS, DAN ESKALASI INSIDEN 3.1. Kategori Insiden Berikut ini merupakan daftar category dan sub category yang digunakan pada pencatatan incident dan laporan incident bulanan. Category Infrastruktur

System

Network

Automation

Application

Host to Host

Sub Category - Air Conditioner (AC) - Fire extinguisher - Cabling - Mainframe - Tandem - SUN - Blade server - Storage - MPLS - VSAT - PABX - Connect Direct - Control Product - Monitoring ECS - ATM - Phone Banking - Card Management - Internet Banking Individu - Internet Banking Bisnis - Mobile Banking - IDS - Adira - BCA Finance - Blitz - Citibank - Flexi - PLN - PBB - Prudential - PPh - Telkom

Catatan: Category dan Sub Category dapat bertambah sesuai perkembangan.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 14 dari 25

MANAJEMEN INSIDEN TI

3.2. Penentuan Prioritas Berikut ini merupakan prioritas penanganan insiden yang terdapat pada divisi GSIT: Tingkat Kerugian (Severity) 2 - Medium

1 - High

Tidak Online

3 - Low

3 - Low

2- Medium

2 - Medium

Online

Dampak (Impact)

Incident Priority

2 - Medium

2 - Medium

1 - High

Insiden yang memiliki dampak online, tidak dapat dilakukan penundaan (pending) terhadap penyelesaian gangguan/masalah. Sedangkan insiden yang tidak berdampak online, apabila PIC meminta untuk dilakukan penundaan (pending) terhadap penyelesaian, maka hal tersebut diijinkan. 3.3. Target Waktu Pelayanan manajemen insiden TI diselenggarakan selama 24 jam sehari, 7 hari seminggu, dan 365 hari setahun. Berikut ini merupakan target waktu yang digunakan dalam penyelesaian masalah yang terkait dengan prioritas. Prioritas

Target Response

Resolve

3 - Low

90% - 10 menit

90% - 1 days

2 - Medium

90% - 3.5 menit

90% - 4 hours

1 - High

95% - 1 menit

90% - 2 hours

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 15 dari 25

MANAJEMEN INSIDEN TI

BAB 4. ALUR PROSES 4.1. Alur Penanganan Insiden Saat Jam Kantor

Gambar 4.1 Alur Penanganan Insiden Saat Jam Kantor Proses Notifikasi dan Eskalasi gangguan berdampak Online Proses Notifikasi dan Eskalasi gangguan tidak berdampak Online

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 16 dari 25

MANAJEMEN INSIDEN TI

4.2. Alur Penanganan Insiden Diluar Jam Kantor

Gambar 4.2 Alur Penanganan Insiden Diluar Jam Kantor

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 17 dari 25

MANAJEMEN INSIDEN TI

BAB 5. ESKALASI INSIDEN Service Desk akan memonitor seluruh insiden dan melakukan eskalasi insiden berdasarkan petunjuk berikut ini: Priority 3 - Low 2 - Medium

1 - High

Time Limit before Escalation 1 hari 3.5 menit Jika PIC tidak dapat dihubungi selama diluar jam kantor Jika PIC dan Manager PIC tidak dapat dihubungi selama diluar jam kantor 30 menit Immediate Immediate

PIC Manager PIC Senior Manager PIC Senior Manager PIC Manager PIC Senior Manager PIC

5.1. Eskalasi Fungsional (Lintas Unit Kerja) Service desk tidak dapat melakukan eskalasi problem kepada PIC unit kerja lain, pihak PIC yang bertanggung jawab terhadap insiden yang hanya dapat menghubungi PIC unit kerja lain. Kecuali PIC yang bertanggung jawab terhadap insiden tersebut meminta service desk untuk dilakukan conference call dengan PIC unit kerja lain. Ketika service desk menerima notifikasi terkait adanya insiden, hal yang selanjutnya dilakukan adalah melakukan identifikasi dan diagnosa awal. Ini dilakukan untuk mengklasifikasikan insiden berdasarkan kelompok dan prioritasnya. Jika insiden merupakan problem yang telah diketahui solusinya, maka akan dilakukan penyelesaian problem sesuai database solusi. Jika tidak, maka akan dilakukan eskalasi kepada PIC terkait. 5.2. Notifikasi Eskalasi Insiden yang solusinya tidak terdaftar pada database solusi tidak boleh diselesaikan sendiri oleh helpdesk dan harus segera dieskalasi dan dikirimkan notifikasinya kepada unit terkait sesuai dengan nama PIC yang tercantum pada Daftar Problem Solver untuk ditindaklanjuti.

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 18 dari 25

MANAJEMEN INSIDEN TI

Berikut adalah notifikasi yang harus dilakukan berdasarkan jenis insiden yang dilaporkan. Jika jenis incident… Berdampak Online Data Center

Maka…  Kirim sms notifikasi terus menerus dengan frekuensi update status gangguan setiap 30 menit kepada:  Semua level manajemen GSIT dan unit terkait  Pejabat DPOL (Divisi Pembinaan dan Operasi Layanan)  Pejabat DPDJ (Divisi Pengembangan Dana dan Jasa)  Pejabat UBC (Unit Bisnis Kartu Kredit), bila incident terkait dengan kartu kredit.  Apabila dalam waktu 30 menit belum ada pemberitahuan bahwa status incident telah selesai dari unit terkait, maka petugas helpdesk harus segera melakukan eskalasi dan notifikasi ke pejabat unit terkait yang lebih tinggi sesuai dengan nama PIC yang tercantum dalam daftar Problem Solver. Tidak berdampak Online Data  Kirim sms notifikasi terus menerus sampai Center level Adviser GSIT/Unit kerja terkait dengan frekuensi update status gangguan setiap 60 menit.  Apabila dalam waktu 60 menit status belum ada pemberitahuan bahwa status incident telah selesai dari unit terkait, maka helpdesk harus segera melakukan eskalasi dan notifikasi ke pejabat unit terkait yang lebih tinggi sesuai dengan nama PIC yang tercantum dalam daftar Problem Solver. 5.3. Sarana dan Format Penulisan Notifikasi Eskalasi Petugas helpdesk dapat mengakses sarana SMS melalui browser dengan

alamat: http://dtisms/view. Dalam melakukan pengiriman sms notifikasi eskalasi, terdapat aturan format penulisan sms eskalasi. Hal ini dilakukan agar terjadi keseragaman pola

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 19 dari 25

MANAJEMEN INSIDEN TI

penulisan dan menghindari adanya kesalahpahaman dalam penyampaian informasi. Berikut merupakan format penulisan sms eskalasi. Jenis INFO

START

DONE

Kondisi Info incident yang telah selesai ditangani kurang dari 30 menit Info incident start yang sedang ditangani PIC dan atau lebih dari 30 menit Info incident telah selesai ditangani

NO Info incident apabila RESPON belum dapat dihubungi

PIC

ESK

Eskalasi incident yang belum selesai ditangani

PEND

Info incident yang dipending atas konfirmasi PIC

Format SMS INFO xxxx : deskripsi problem JAM: xx.xx, STAT: xxxx JAM: xx.xx. PIC: xxx INFO INC xxxx (START): deskripsi problem, STAT: xxxx. PIC: xxx ON CALL/ON SITE, JAM: xx.xx, IMP: xxxx INFO INC xxxx (DONE): deskripsi problem, STAT: xxxx. PIC: xxx ON CALL/ON SITE, JAM: xx.xx INFO INC xxxx (START): deskripsi problem, STAT: PIC blm dapat dihubungi. PIC: xxx, JAM: xx.xx, IMP: xxxx ESK INC xxxx [odate, jam]: deskripsi problem, STAT: xxxx. PIC: xxx, JAM: xx.xx [start incident], IMP: xxxx INFO INC xxxx (PEND): deskripsi problem, STAT: xxxx. PIC: xxx, JAM: xx.xx, IMP: xxxx

PT. Bank ABC, Tbk

No. Dokumen : ABC-IIO-IMP-01

IT Service Delivery Management

PROSEDUR Tanggal Efektif : 01 Februari 2016

No. Revisi

: 1.0

Halaman

: 20 dari 25

MANAJEMEN INSIDEN TI

5.4. Proses Eskalasi Insiden 5.4.1. Notifikasi dan Eskalasi Gangguan Berdampak Online

PT. Bank ABC, Tbk

No. Dokumen : ABC-IIO-IMP-01

IT Service Delivery Management

PROSEDUR Tanggal Efektif : 01 Februari 2016

No. Revisi

: 1.0

Halaman

: 21 dari 25

MANAJEMEN INSIDEN TI

5.4.2. Notifikasi dan Eskalasi Gangguan Tidak Berdampak Online

No. Dokumen : ABC-IIO-IMP-01

PT. Bank ABC, Tbk PROSEDUR Tanggal Efektif : 01 Februari 2016

IT Service Delivery Management

No. Revisi

: 1.0

Halaman

: 22 dari 25

MANAJEMEN INSIDEN TI

BAB 6. RACI CHART Berikut ini merupakan penjelasan RACI Chart dalam proses manajemen

System Operator

Shift Leader

Group Leader

Manager

Grup PIC

Incident Management

R

R

AR

-

-

-

-

Incident Logging and Categorization

R

AR

-

-

-

-

-

Immediate Incident Resolution by 1st Level

R

AR

-

-

-

-

-

Incident Resolution by 2nd Level

-

-

-

-

-

AR

-

Handling of Major Incidents

-

R

-

-

-

R

AR

Incident Monitoring and Escalation

-

R

AR

-

-

-

-

Incident Closure and Evaluation

R

AR

C

-

-

-

-

Pro-active Information

R

AR

C

-

-

-

-

Incident Management Reporting

-

-

R

AR

I

-

-

Sub Process

Manager PIC

Helpdesk

Grup

insiden TI pada divisi GSIT:

PT. Bank ABC, Tbk

No. Dokumen : ABC-IIO-IMP-01

IT Service Delivery Management

PROSEDUR Tanggal Efektif : 01 Februari 2016

No. Revisi

: 1.0

Halaman

: 23 dari 25

MANAJEMEN INSIDEN TI

BAB 7. LAPORAN INSIDEN Pada bagian ini akan dijelaskan mengenai laporan-laporan yang dibuat terkait dengan pengelolaan incident baik harian maupun bulanan. 7.1. Jenis Laporan Insiden Berikut ini merupakan jenis laporan insiden yang ada, laporan ini dapat digunakan dalam penelusuran insiden yang telah terjadi:

7.2. Batas Waktu dan Menerima Laporan Berikut ini merupakan batas waktu dan menerima laporan:

PT. Bank ABC, Tbk

No. Dokumen : ABC-IIO-IMP-01

IT Service Delivery Management

PROSEDUR Tanggal Efektif : 01 Februari 2016

No. Revisi

: 1.0

Halaman

: 24 dari 25

MANAJEMEN INSIDEN TI

7.3. Service Level Call Management Helpdesk Berikut ini Service Level Call Management Helpdesk:

7.4. Treshold Service Level Call Management Helpdesk Berikut ini threshold service level call management helpdesk:

7.5. Incoming Call Management Helpdesk Berikut ini incoming call management helpdesk:

PT. Bank ABC, Tbk

No. Dokumen : ABC-IIO-IMP-01

IT Service Delivery Management

PROSEDUR Tanggal Efektif : 01 Februari 2016

No. Revisi

: 1.0

Halaman

: 25 dari 25

MANAJEMEN INSIDEN TI

7.6. Perhitungan Service Level 7.6.1. Perhitungan Treshold Response Acceptable Call (RAC)

7.6.2. Perhitungan Treshold Success Call Ratio (SCR)

7.6.3. Perhitungan Treshold Incoming Call (IC)

BAB 6 KESIMPULAN DAN SARAN Berdasarkan hasil kegiatan penelitian yang telah dilakukan, dapat disimpulkan beberapa hal sebagai berikut: 1. Telah dilakukan Maturity Level Assessment khususnya pada layanan Incident Management dengan menggunakan kerangka kerja ITIL 2011 yang digunakan dalam studi kasus di sektor perbankan. 2. Dari hasil proses Maturity Level Assessment berdasarkan ITIL 2011, menghasilkan output berupa gap/jarak antara proses manajemen insiden yang ada saat ini (existing) dengan proses manajemen insiden yang diharapkan oleh manajemen. 3. Terdapat nilai 1 pada service operation area “Incident Management Process” pada index A4, A22, dan service operation area “Incident Management Metrics” pada index C3. Sedangkan untuk nilai 2 ditemukan pada service operation area “Incident Management Process” pada index A3, A5, A7, dan A20, serta “Activities in Place needed for the Success of Incident Mangement” pada index B3, B4 dan B5 dan yang terakhir pada “Incident Management Process Interactions” pada index D2 dan D3. 4. Telah dilakukan proses perancangan Tata Kelola Manajemen Insiden TI berdasarkan ITIL 2011, yang difokuskan pada perbaikan dari hasil proses assessment yang telah dilakukan. 5. Tata kelola manajemen insiden TI berdasarkan kerangka kerja ITIL 2011 yang telah dihasilkan, digunakan sebagai acuan dalam proses manajemen insiden TI yang ada saat ini.

Selain kesimpulan diatas, terdapat saran yang dapat dijadikan acuan sebagai pengembangan Tata Kelola Manajemen Insiden TI kedepannya, yaitu agar penelitian dapat dilakukan pula menggunakan kerangka kerja selain ITIL 2011, agar didapatkan pengelolaan manajemen insiden yang lebih variatif.

113

114

Lampiran A. Form Kuesioner Penilaian Proses Manajemen Insiden

KUESIONER PENILAIAN PROSES MANAJEMEN INSIDEN

Partisipan yang terhormat, Dengan segala kerendahan hati, peneliti memahami aktivitas padat yang sedang Bapak/Ibu lakukan. Bersama ini, perkenankanlah peneliti memohon bantuan Bapak/Ibu agar dapat memberikan inputan terhadap kuesioner dibawah ini, guna menilai tingkat kematangan tata kelola manajemen insiden TI yang ada saat ini.

Petunjuk Pengisian: Berilah tanda √ (centang) pada kolom jawaban disebelah kanan sebagai penilaian dari masing-masing atribut yang ada. Keterangan dan Skala Penilaian : 5 : Optimized

3 : Defined

4 : Managed

2 : Repeatable

1 : Initial

Nama :

Jabatan:

Jawaban Atribut

No.

5

Proses Manajemen Insiden 1

Kami telah menetapkan Tujuan, Sasaran dan Target dalam proses Manajemen Insiden We have defined Incident Management's Purpose, Goal and Objective

117

4

3

2

1

2

Kami telah menetapkan Ruang Lingkup dari proses Manajemen Insiden We have defined Incident Management's Scope

3

Kami telah menetapkan nilai dari proses Manajemen Insiden terhadap bisnis We have defined Incident Management's Value to the business

4

Kami telah menetapkan kebijakan, prinsip dan konsep-konsep dasar dari proses Manajemen Insiden We have defined Incident Management's Policies, Principles and basic concepts

5

Skala waktu yang ada telah disetujui untuk semua tahapan penyelesaian insiden Timescales are agreed for all incident handling stages

6

Manajer Insiden / pemilik proses telah ada Incident Manager/Process Owner is in place

7

Model insiden telah didefinisikan Incident Models are defined

8

Insiden besar telah didefinisikan Major Incidents are defined

9

Prosedur penanganan insiden besar telah dikembangkan A Major Incident Procedure has been developed

10

Aktivitas proses “Identifikasi Insiden” telah ditentukan The "Incident Identification" process activity is specified

11

Aktivitas proses “Pencatatan Insiden” telah ditentukan The "Incident logging" process activity is specified

12

Aktivitas proses “Pengelompokan Insiden” telah ditentukan The "Incident categorisation" process activity is specified

13

Aktivitas proses “Prioritas Insiden” telah ditentukan The "Incident Prioritisation" process activity is specified

118

14

Aktivitas proses “Diagnosa Awal” telah ditentukan The "Initial Diagnosis" process activity is specified

15

Aktivitas proses “Eskalasi Insiden” telah ditentukan The "Incident Escalation" process activity is specified

16

Aktivitas proses “Identifikasi Insiden” telah ditentukan The "Incident Identification" process activity is specified

17

Aktivitas proses “Investigasi dan Diagnosa” telah ditentukan The "Investigation and Diagnosis" process activity is specified

18

Aktivitas proses “Penyelesaian dan Pemulihan Insiden” telah ditentukan The "Resolution and recovery" process activity is specified

19

Aktivitas proses “Penutupan Insiden” telah ditentukan The "Incident Closure" process activity is specified

20

Kami telah menetapkan pemicu, input, output, dan tampilan dari Manajemen Insiden We have defined Incident Management's Triggers, Inputs, Outputs and interfaces

21

Kami telah menetapkan pelaporan manajemen informasi dari proses manajemen insiden We have defined Incident Management's Information Management reporting

22

Kami telah menetapkan tantangan, faktor penentu kesuksesan dan resiko dari manajemen insiden We have defined Incident Management's Challenges, Critical Success Factors and Risks

23

Pencatatan insiden yang dilakukan sendiri telah ada Self-service Incident logging is in place

24

Penelusuran insiden telah ada Incident tracking is in place

119

25

Kepemilikian dari insiden dapat dimengerti dan telah ada Incident ownership is understood and in place

26

Data yang diinputkan pada seluruh tahapan insiden telah dicek untuk kelengkapannya Data entered into incidents at all stages is checked for completeness

27

Prosedur peninjauan terhadap Proses Manajemen Insiden telah ada Incident Management Process review procedure is in place

Aktivitas yang dibutuhkan untuk mensukseskan manajemen insiden 1

Fungsi service desk telah ditentukan The Service Desk function is defined

2

Service desk mengetahui perannya pada Manajemen Insiden di tier/level 1 The Service Desk is aware of their role at Tier 1/Level 1 Incident Management

3

Tim pada tier/level 2 telah mengetahui perannya pada Manajemen Insiden Tier2/Level teams are aware of their role in Incident Management

4

Tim pada tier/level 3 telah mengetahui perannya pada Manajemen Insiden Tier 3/Level teams are aware of their role In Incident Management

5

Pihak supplier eksternal telah mengetahui perannya pada manajemen insiden External Suppliers are aware of their role in Incident Management

6

Pengetahuan-pengetahuan dasar telah ada untuk mendukung penyelesaian insiden pada service desk Knowledge Bases are in place to Incicent Resolution at the Service Desk

7

Solusi (sementara) penyelesaian insiden telah terdokumentasi dan menjadi bagian dari pengetahuan dasar

120

5

4

3

2

1

Workarounds are document and in the Knowledge Base

Pengukuran Manajemen Insiden 1

5

4

3

2

1

5

4

3

2

1

KPI (key performance indicator) dari proses manajemen insiden telah ditentukan dan tersedia Incident Management's KPIs and metrics are defined and in place

2

Laporan Manajemen Insiden telah di identifikasi dan tersedia Incident Management Reports have been identified and put in place

3

Metrik telah ditentukan dan tersedia untuk insiden besar Metrics have been defined and are in place for Major Incidents

Interaksi Proses Manajemen Insiden

1

Manajemen konfigurasi dan layanan asset ada dan mampu mendukung penyelesaian insiden Service Asset and Configuration Management is in place and available to Incident Resolution

2

Hubungan antara Manajemen Insiden dan Manajemen Permasalahan dapat dimengerti The relationship between Incident Management and Probem Management is understood

3

Prosedur akar penyebab ada sebagai bagian dari manajemen permasalahan terhadap sebuah proses yang belum pernah ada A Root Cause Procedure is in place as Problem Management as a process does not exist yet

4

Manajer insiden / proses insiden diperiksa sebagai bagian dari Change Management (tinjauan setelah implementasi) The Incident Manager/The Incident Process is consulted as part of Change Management (post implementation reviews)

5

Insiden yang berkaitan dengan peluncuran sebuah produk dilaporkan kepada pihak Change/Release Manager Incidents related to releases are reported to the Change/Release Manager

121

122

DAFTAR PUSTAKA

Axelos. 2015. ITIL Maturity Model. (Online) (https://www.axelos.com/best-practice-solutions/itil/itil-maturity-model, diakses tanggal 16 Oktober 2015) Beisse, F. 2014. A Guide to Computer for Help Desk and Specialists, Sixth Edition. Cengage Learning, Boston. Bernard, P. 2012. Foundations of ITIL®, 2011 Edition. Van Haren Publishing, Amersfoort Bevir, M. 2012. Governance: A Very Short Introduction. Oxford University Press, United Kingdom. Brand, K dan Boonen, H. 2003. IT Governance based on Cobit 4.1 – A Management Guide, Van Haren Publishing, Amersfoort. Fukuyama, F. 2013. “What Is Governance?.”, Center for Global Development Working Paper 314, hal 3-5. IT-Processmaps. 2015. ITIL 2011. (Online) (http://wiki.en.it-processmaps.com/index.php/ITIL_2011, diakses tanggal 22 September 2015) PT Bank ABC (2014), Sistem Manajemen Mutu ISO 9001:2008, Versi Rev00, PT Bank ABC, Jakarta. PT Bank ABC (2014), Panduan Pengelolaan Incident, Versi 05, PT Bank ABC, Jakarta. Selig, G.J. 2008. Implementing IT Governance, Van Haren Publishing, Amersfoort. Steinberg, R. 2011. ITIL® Service Operation 2011 Edition, The Stationary Office, United Kingdom. Universities and Colleges Information System Association (UCISA). 2015. Incident Management Process Assessment. (Online) (https://www.ucisa.ac.uk/~/media/Files//activities/ITIL/service_o peration/incident_management/Incident Management Process Assessment xls.ashx, diakses tanggal 16 Oktober 2015)

115

Universities and Colleges Information System Association (UCISA). 2015. ITIL – A Guide to Problem Management. (Online) (https://www.ucisa.ac.uk/~/media/Files//activities/ITIL/service_o peration/problem_management/ITIL_a guide to problem management pdf.ashx, diakses tanggal 16 Oktober 2015)

116

BIODATA PENULIS

Penulis tesis ini bernama Valentino Budi Pratomo, lahir di Surabaya, 14 Februari 1989. Telah menempuh Sekolah Dasar di SDN Sentul 2 Blitar dan lulus tahun 2001. Kemudian melanjutkan pendidikan Sekolah Menengah Pertama di SMP Negeri 1 Blitar dan lulus pada tahun 2004. Tahun 2007 lulus dari SMA Negeri 3 Blitar yang kemudian melanjutkan studi di program studi S1 Sistem Informasi di Sekolah Tinggi Manajemen Komputer dan Teknik Komputer Surabaya selesai tahun 2012. Kemudian melanjutkan studi pada akhir 2013 dengan menempuh program Pascasarjana Magister Manajemen Teknologi ITS bidang keahlian Manajemen Teknologi Informasi hingga pada tahun 2016. Karir bekerja dimulai pada 2013 di PT. BCA, Tbk sebagai IT Specialist. Penulis mengambil Judul Tesis “Perancangan Tata Kelola Manajemen Insiden TI Berdasarkan Kerangka Kerja ITIL 2011 (Studi Kasus Pada PT. Bank ABC)”.