TA : Pembuatan Prosedur Incident Management Untuk Penanganan Pengaduan Pada PPTI Berdasarkan ITIL V-3.

(1)

PEMBUATAN PROSEDUR INCIDENT MANAGEMENT

UNTUK PENANGANAN PENGADUAN PADA PPTI

BERDASARKAN ITIL V-3

TUGAS AKHIR

Program Studi S1 Sistem Informasi

Oleh:

TASKHIYATUL NUFUS RIZKILLAH 11410100263

FAKULTAS TEKNOLOGI DAN INFORMATIKA

(2)

xi DAFTAR ISI

Halaman

ABSTRAK vii

KATA PENGANTAR viii

DAFTAR ISI x

DAFTAR TABEL xii

DAFTAR GAMBAR xiii

DAFTAR LAMPIRAN xiv

BAB I PENDAHULUAN 1

1.1 Latar Belakang 1

1.2 Perumusan Masalah 3

1.3 Pembatasan Masalah 3

1.4 Tujuan Penelitian 4

1.5 Manfaat Penelitian 4

1.6 Sistematika Penulisan 4

BAB II LANDASAN TEORI 6

2.1 Perencanaan Strategis SI/TI 6

2.2 Information Technology Infrastructure Library (ITIL) 6

2.3 Standard Operating Procedure (SOP) 15

2.4 Work Instruction 17

2.5 Work Record 17

2.6 Bagan Alir Sistem 17

BAB III METODE PENELITIAN 19

(3)

xii

3.1.2 Tahap Pengumpulan Data dan Informasi 20

3.2 Tahap Pembuatan Prosedur Incident Management 21

3.2.1 Identifikasi Kebutuhan Prosedur 21

3.2.2 Tahap Pembuatan Prosedur 22

3.2.3 Evaluasi 23

3.3 Tahap Akhir 24

BAB IV HASIL DAN PEMBAHASAN 25

4.1 Hasil Tahap Awal 25

4.1.1 Hasil Studi Literatur 25

4.1.2 Hasil Tahap Pengumpulan Data dan Informasi 26

4.2 Hasil Tahap Pembuatan Prosedur Incident Management 33

4.2.1 Hasil Identifikasi Kebutuhan Prosedur 33

4.2.2 Hasil Pembuatan Prosedur 50

4.2.3 Hasil Evaluasi 66

4.3 Hasil Pembahasan 69

BAB V KESIMPULAN DAN SARAN 74

5.1 Kesimpulan 74

5.2 Saran 74

DAFTAR PUSTAKA 75

(4)

1 BAB I PENDAHULUAN

1.1 Latar Belakang

Institut Bisnis dan Informatika Stikom Surabaya merupakan sebuah

perguruan tinggi yang mengembangkan dan menerapkan teknologi informasi

dalam proses pembelajaran dan pelayanan. Pemegang peranan penting yang

menentukan standarisasi arah penataan, pengembangan, penerapan, dan pelayanan

Teknologi Informasi dan Komunikasi (TIK) terdapat di Bagian Pengembangan

dan Penerapan Teknologi Informasi (PPTI).

Jenis pelayanan PPTI kepada penggunanya, antara lain sistem informasi

dan jaringan untuk semua civitas akademika di Institut Bisnis dan Informatika

Stikom Surabaya. PPTI juga menyediakan layanan penanganan pengaduan, baik

penanganan berupa wifi, proxy, maupun aplikasi dapat dilakukan pengguna

melalui website dan telepon.

Layanan penanganan pengaduan terdiri atas proses identifikasi insiden,

pencatatan insiden, prioritas insiden, penanganan insiden, mengumpulkan dan

menyimpan data detil insiden apabila insiden baru pertama kali terjadi, dan

pelaporan kepada pengguna. Proses tersebut hampir seluruhnya dipegang oleh

pihak pengembang baik jaringan atau aplikasi.

Dengan jenis layanan yang mencakup semua bagian di Institut Bisnis dan

Informatika Stikom Surabaya, tentunya tidak terlepas dari insiden yang tidak

(5)

seperti permasalahan pada sistem, jaringan terputus tiba-tiba, dan listrik padam

sehingga berdampak negatif terhadap kegiatan operasi bisnis.

Beberapa dari insiden tersebut, proses penanganan insiden yang

dilakukan hanya berdasarkan perkiraan, pengetahuan, dan pengalaman

pengembang jaringan atau aplikasi. Pencatatan kegiatan yang telah dilakukan saat

menangani hanya dilakukan oleh pihak yang menangani sehingga tidak ada histori

insiden pada Bagian PPTI, sehingga jika insiden tersebut terulang maka tidak

harus menunggu pihak yang menangani insiden diawal yang berdampak pada

lamanya penanganan insiden.

Untuk meminimalisasi insiden tersebut diharapkan dapat membuat

prosedur Incident Management terpadu, dengan tujuan untuk meminimalkan

dampak negatif terhadap operasi bisnis, sehingga dapat memastikan kemungkinan

tingkat terbaik kualitas layanan dapat dipertahankan (OGC, 2007). Langkah

tersebut berguna untuk menjamin berlangsungnya layanan dan mendefinisikan

semua konsep, teknik penting, serta persyaratan yang dibutuhkan pada setiap

kegiatan.

Pembuatan prosedur Incident Management ini menghasilkan standar,

prosedur, dan formulir yang diharapkan mampu dilaksanakan secara benar, tepat,

dan konsisten ketika atau sebelum terjadi kendala serta menyelaraskan waktu dan

kegiatan penanganan incident agar dapat memiliki waktu dan kegiatan yang

terstruktur dan selaras jika dilakukan oleh pihak yang berbeda sekalipun.

Pembuatan prosedur Incident Management ini memerlukan Framework ITIL V-3

(6)

3

Framework ITIL V-3 berfokus pada layanan operasional yang dapat

memberi masukan bagi perusahaan tentang cara menangani insiden yang terjadi,

tepat digunakan sebagai acuan untuk menyusun pola kerja yang terstruktur dalam

memberikan layanan perusahaan, dan dapat menjadi panduan pengembangan

sebuah tata laksana karena memiliki library yang terperinci yang berguna dalam

pengembangan langkah dalam prosedur. Panduan pemulihan layanan yang telah

disediakan oleh ITIL V-3 pada proses Incident Management terdapat beberapa

aktifitas seperti Incident Identification, Incident Logging, Incident Categorization,

Incident Prioritization, Initial Diagnosis, Incident Escalation, Investigasi and

Diagnosis, Resolution and Recovery, dan Incident Closure.

1.2 Perumusan Masalah

Berdasarkan latar belakang masalah yang dijelaskan di atas, maka dapat

dirumuskan permasalahan yang sedang dihadapi, adalah bagaimana membuat

prosedur Incident Management untuk penanganan pengaduan pada PPTI

berdasarkan framework ITIL V-3?

1.3 Pembatasan Masalah

Berdasarkan rumusan masalah di atas, maka batasan permasalahan dalam

penelitian ini adalah sebagai berikut:

1. Pembuatan prosedur Incident Management mengacu pada ITIL V-3 tahap

Service Operation dan proses Incident Management.

2. Pembuatan prosedur Incident Management hanya dilakukan pada layanan

penanganan pengaduan pada Bagian PPTI di Institut Bisnis dan Informatika

(7)

1.4 Tujuan Penelitian

Tujuan yang dicapai adalah menghasilkan prosedur Incident

Management berdasarkan framework ITIL V-3, yaitu berupa Standar, Prosedur,

dan Formulir. Prosedur Incident Management tersebut dapat memberikan arahan

kerja yang jelas ketika atau sebelum terjadi kendala pada proses penanganan

pengaduan, memiliki waktu dan kegiatan yang terstruktur dan selaras jika

dilakukan oleh pihak yang berbeda sekalipun, dan meminimalkan dampak negatif

terhadap operasi bisnis sehingga dapat menjalankan proses tersebut secara

terstruktur.

1.5 Manfaat Penelitian

Manfaat dari pembuatan prosedur Incident Management berdasarkan

ITIL V-3 yang dibangun adalah:

1. Memberikan arahan kerja yang jelas untuk mengembalikan layanan normal

secepat mungkin.

2. Membantu Bagian PPTI dalam menata dokumen secara terstruktur dan

selaras sehingga dapat mendukung pola kerja yang baik.

1.6 Sistematika Penulisan

Sistematika penulisan yang digunakan dalam penyusunan laporan Tugas

Akhir ini dibagi menjadi beberapa bab seperti pendahuluan, landasan teori,

metodologi penelitian, hasil dan pembahasan, serta penutup. Bab pendahuluan

menguraikan tentang latar belakang, perumusan masalah, batasan masalah, tujuan,

(8)

5

Selanjutnya pada bab landasan teori ini menguraikan tentang beberapa

teori yang berhubungan dengan permasalahan yang digunakan dalam penyusunan

Tugas Akhir. Teori-teori tersebut meliputi perencanaan strategis SI/TI,

Information Technology Infrastructure Library (ITIL), Standard Operating

Procedure (SOP), Work Instruction, Work Record, dan bagan alir sistem.

Selanjutnya pada bab metodelogi penelitian membahas mengenai

metodologi penelitian. Metodologi penelitian dalam pembuatan prosedur Incident

Management ini terdiri atas tiga tahap. Tahap pertama yaitu tahap awal dengan

melakukan studi literatur serta pengumpulan data dan informasi. Tahap kedua

yaitu tahap pembuatan prosedur Incident Management yang terdapat identifikasi

kebutuhan prosedur, pembuatan prosedur, dan evaluasi yang terdiri atas verifikasi

dan validasi. Tahap ketiga yaitu tahap akhir yang terdiri atas kesimpulan dan

saran.

Selanjutnya pada bab hasil dan pembahasan membahas mengenai hasil

dan pembahasan dari bab ketiga. Kegiatan metodologi penelitan terdiri atas hasil

tahap awal, hasil tahap pembuatan prosedur Incident Management, dan hasil

pembahasan.

Terakhir pada bab penutup ini membahas mengenai kesimpulan dan

saran. Kesimpulan dari pembuatan prosedur Incident Management dan saran

untuk pengembangan prosedur Incident Management dimasa yang mendatang,

(9)

6 BAB II

LANDASAN TEORI

2.1 Perencanaan Strategis SI/TI

Menurut Ward dan Peppard (2002), Perencanaan strategis SI/TI

merupakan proses identifikasi portofolio aplikasi SI berbasis komputer yang

mendukung organisasi dalam pelaksanaan rencana bisnis dan merealisasikan

tujuan bisnisnya. Perencanaan strategis SI/TI mempelajari pengaruh SI/TI

terhadap kinerja bisnis dan kontribusi bagi organisasi dalam memilih

langkah-langkah strategis. Selain itu, perencanaan strategis SI/TI juga menjelaskan

berbagai tools, teknik, dan kerangka kerja bagi manajemen untuk menyelaraskan

strategi SI/TI dengan strategi bisnis, bahkan mencari kesempatan baru melalui

penerapan teknologi yang inovatif.

Jadi dapat disimpulkan bahwa perencanaan strategis SI/TI sangat

diperlukan dalam upaya pengelolaan dan pemanfaatan TI untuk kepentingan

organisasi dalam mencapai tujuan bisnis dan keunggulan kompetitif. Integritas

dan keselarasan dalam proses bisnis organisasi sangat diperlukan, dengan begitu

organsasi memiliki capability, availability, reliability, serta adaptive sehingga

dapat menyelesaikan setiap transaksi dan melakukan perubahan dengan cepat dan

akurat (Suralani, 2011).

2.2 Information Technology Infrastructure Library (ITIL)

ITIL adalah suatu rangkaian konsep dan teknik pengelolaan infrastruktur,

pengembangan, serta operasi teknologi informasi (TI). ITIL memberikan deskripsi

(10)

7

yang menyeluruh yang dapat disesuaikan dengan segala jenis organisasi TI. ITIL

merupakan framework untuk mengelola infrastruktur TI pada suatu organisasi dan

bagaimana memberikan service terbaik bagi pengguna layanan TI (OGC, 2007).

Penggunaan pendekatan ITIL V-3 sebagai kerangka acuan dapat digunakan untuk

meningkatkan, memonitor, dan memastikan layanan teknologi informasi dapat

berjalan sesuai dengan visi dan misi perusahaan. Tujuan utama dari penerapan

ITIL:

1. Sebagai jembatan antara pihak manajemen dan divisi TI agar keduanya dapat

berkomunikasi lebih efektif dan efisien

2. Dapat memanfaatkan infrastruktur teknologi informasi yang ada dengan

optimal

3. Dapat memanajemen infrastruktur TI dengan baik sehingga jika terjadi

masalah dapat langsung memulihkan keadaan yang ada

ITIL V-3 terdiri atas lima bagian dan lebih menekankan pada

pengelolaan siklus hidup layanan yang disediakan oleh teknologi informasi

menurut OGC (2007). Kelima bagian tersebut adalah:

1. Service Strategy, sebuah panduan untuk menentukan strategi yang digunakan

untuk mengimplementasikan system.

2. Service Design, memberikan pandauan kepada organisasi TI untuk mendesain

dan membangun layanan TI maupun implementasi ITSM. Desain layanan

mengikuti strategi layanan dalam siklus hidup layanan. Hal ini tidak mengacu

pada layanan baru saja, tetapi juga untuk layanan lama yang sudah diperbarui.

3. Service Transition, memberikan gambaran cara sebuah kebutuhan yang

(11)

Design untuk selanjutnya secara efektif direalisasikan dalam Service

Operation.

4. Service Operation, kegiatan operasional harian untuk pengelolaan layanan TI.

Di dalamnya terdapat panduan cara mengelola layanan TI dan bertanggung

jawab untuk melaksanakan dan melakukan proses pengoptimalan biaya dan

kualitas layanan.

5. Continual Service Improvement, memberikan panduan penting dalam

menyusun serta memelihara kualitas layanan dari proses desain, transisi dan

pengoperasiannya.

Kelima siklus hidup dari ITIL V-3 di atas yang digunakan untuk

mendukung penelitian Tugas Akhir ini adalah tahap Service Operation. Kegiatan

umum pada Service Operation berisi tentang sejumlah kegiatan operasional yang

memastikan bahwa teknologi sejalan dengan tujuan layanan dan proses organisasi

secara keseluruhan. Service Operation memiliki lima proses yang saling

berkaitan, adapun lima proses tersebut meliputi:

1. Event Management, memonitor semua peristiwa yang terjadi diseluruh

infrastruktur TI.

2. Incident Management, berkonsentrasi pada pemulihan layanan tiba-tiba rusak

atau terganggu secepat mungkin, untuk meminimalkan dampak bisnis.

3. Request Fulfillment, proses penanganan permintaan pengguna sesuai standar

serta memungkinkan TI untuk memenuhi layanan untuk menyediakan akses

yang cepat dan efektif untuk standar layanan. Contohnya, permintaan untuk

(12)

9

4. Problem Management, analisis akar penyebab untuk menentukan dan

mengatasi penyebab peristiwa dan kejadian, kegiatan proaktif untuk

mencegah masalah dan insiden dimasa depan.

5. Access Management, proses pemberian pengguna resmi hak untuk

menggunakan layanan, sementara membatasi akses ke pengguna non-resmi.

Penelitian ini lebih difokuskan lagi, yaitu hanya berfokus pada proses

Incident Management. Incident merupakan gangguan yang tidak direncanakan

untuk layanan TI dan biasanya akibat dari kegagalan sistem atau error pada

infrastruktur TI yang menyebabkan atau berpotensi menjadi penyebab

terganggunya operasional (OGC, 2007). Contoh dari incident adalah:

1. Adanya aplikasi potensial menyebabkan kerusakan sistem.

2. Sistem yang down dapat menyebabkan sistem lain terganggu.

3. Jaringan komputer yang terganggu menyebabkan sistem terganggu.

Menurut OGC (2007), Incident Management itu sendiri bertujuan untuk

mengembalikan operasi layanan normal secepat mungkin “layanan operasi

normal” didefinisikan di sini sebagai layanan operasi dalam batas SLA dan

meminimalkan dampak negatif terhadap operasi bisnis, sehingga memastikan

bahwa kemungkinan tingkat terbaik kualitas layanan dipertahankan. Incident

Management memiliki beberapa proses yang harus diikuti selama pengelolaan

(13)

(14)

11

1. Incident Identification, dimulai dengan identifikasi dan yang paling umum

dilakukan adalah melalui layanan service desk dan laporan dari staf teknisi.

Fase ini bermula ketika suatu insiden terjadi dan insiden itu dapat diketahui

melalui:

a. Laporan dari pengguna melalui website perusahaan.

b. Laporan dari pengguna melalui telepon.

c. Laporan dari teknisi yang sedang melakukan perawatan peralatan

perusahaan.

2. Incident Logging, pencatatan dilakukan melalui telepon Service Desk atau

secara otomatis terdeteksi melalui peringatan acara. Semua informasi dicatat

sehingga jika insiden terulang, memiliki semua informasi yang relevan untuk

membantu. Informasi-informasi yang perlu dicatat dalam setiap insiden antara

lain:

1. Kategori insiden atau level insiden

2. Urgensi insiden

3. Dampak insiden

4. Tanggal dan waktu pencatatan

5. Nama atau pihak yang menangani insiden

6. Metode munculnya notifikasi (telepon, e-mail, langsung, dsb)

7. Nama/bagian

8. Deskripsi insiden

9. Kegiatan yang telah dilakukan dalam penanganan insiden

(15)

3. Incident Categorization, dalam membuat kategori insiden dibutuhkan sebuah

proses khusus antara pengelola TI dan pihak manajemen organisasi. Hal ini

bertujuan untuk menghasilkan kategori insiden dan prioritas penanganannya

sejalan dengan proses bisnis organisasi. Kategori insiden dapat dibuat

berdasarkan perkiraan lamanya penanganan, implikasi terhadap proses bisnis

organisasi, dan jumlah staf teknis terkait karena setiap organisasi atau

perusahaan mempunyai level kategori sendiri-sendiri dalam mengartikan

insiden yang terjadi. Langkah-langkah dalam menetapkan level kategori

antara lain:

a. Lakukan diskusi antara kepala bagian dengan pihak terkait yang

menangani.

b. Putuskan level-level kategori insiden dari top level ke lower level.

c. Analisis insiden yang sering terjadi selama periode yang telah disepakati

untuk menentukan level kategorinya.

d. Lakukan review apakah kategori yang telah ditetapakan sudah cocok atau

perlu dilakukan perubahan level kategori lagi.

4. Incident Prioritization, dapat dilakukan berdasarkan besarnya implikasi

insiden terhadap kegiatan bisnis utama organisasi, ataupun berdasarkan

lamanya penanganan insiden. Faktor-faktor yang berkontribusi dalam

penentuan level dampak antara lain:

a. Risiko terhadap keberlangsungan hidup perusahaan.

b. Jumlah kegiatan atau layanan yang terkena dampak insiden.

c. Level kehilangan finansial.

(16)

13

e. Pelanggaran terhadap peraturan dan SPMI

Perioritas insiden kemungkinan dapat berubah secara dinamis, sehingga

penyelesaian insiden yang sudah ditetapkan dalam SLA (Sevice Level

Agreement) dapat berubah sesuai dengan kondisi terbaru penanganan insiden.

5. Initial Diagnosis, wajib dilakukan terhadap insiden oleh setiap pihak yang

pertama kali berhubungan dengan insiden seperti, service desk dan staf teknis.

Namun jika pihak yang pertama kali berhubungan masih belum dapat

membantu menyelesaikan masalah secara langsung maka dapat meminta

waktu kepada pengguna untuk mencatat insiden tersebut agar diselesaikan

pihak atau bagian lain yang lebih kompeten menangani insiden tersebut.

6. Incident Escalation, adalah tindakan menaikkan level penanganan insiden.

Hal ini berkaitan erat dengan hasil diagnosa awal terhadap insiden. Jika dari

diagnosa ditemukan insiden yang tidak dapat ditangani, maka wajib

dilakukan eskalasi insiden. Terdapat dua cara atau tahapan dalam penanganan

insiden, antara lain:

1. Functional escalation: Tindakan menaikkan level penanganan kepada satu

level di atasnya. Apabila bagian administrasi tidak dapat menyelesaikan

insiden yang dikeluhkan maka secepatnya insiden tersebut dilimpahakan

kepada staf level support berikutnya sampai pada level support tertinggi.

2. Hierarchic escalation: tindakan menaikkan level penanganan melintasi

hierarki organisasi, misalnya kepada manajer IT atau manajer bisnis yang

terkait. Apabila insiden yang terjadi pada level prioritas level satu maka

harus ditangani dengan cepat oleh manajer-manajer bagian yang

(17)

7. Investigation and Diagnosis, dilakukan untuk menemukan sumber masalah

dari insiden. Dalam melakukan investigasi, setiap tindakan wajib dilaporkan

juga ke dalam formulir insiden. Hal ini berguna sebagai data historis tindakan

penanganan suatu insiden.

Berikut tindakan yang ada dalam investigasi, antara lain:

a. Menetapkan apa yang sebenarnya terjadi (kesalahan) dan informasi yang

diinginkan pengguna.

b. Memahami kronologi terjadinya insiden.

c. Mengkonfirmasi dampak yang ditimbulkan oleh insiden.

d. Mengidentifikasi berbagai kegiatan yang menyebabkan terjadinya insiden.

8. Resolution and Recovery, langkah ini merupakan tindakan yang diambil

untuk menyelesaikan suatu insiden. Langkah resolusi dapat dilakukan oleh

service desk sebagai pihak yang pertama menemukan insiden dari pengguna

dan staf teknisi yang sedang mengerjakan kegiatan konfigurasi. Pada saat

langkah penyelesaian insiden sudah ditentukan, maka perlu dilakukan testing

dan tindakan penyelesaian. Semua kegiatan dan pihak atau staf yang

berwenang menangani gangguan yang terjadi tersebut harus dicatat secara

detil sebagai histori perawatan perangkat. Tindakan-tindakan yang perlu

dilakukan antara lain:

a. Meminta dan memandu pengguna melakukan tindakan yang diperlukan

secara langsung.

b. Meminta staf ahli untuk menangani insiden secara langsung.

(18)

15

9. Incident Closure, adalah langkah yang dilakukan oleh service desk maupun

staf teknisi terkait untuk memastikan apakah insiden telah benar selesai

ditangani. Setelah penyelesaian insiden dilakukan maka perlu melakukan cek

pada hal berikut ini:

a. Closure categorization: cek dan konfirmasi bahwa inisiasi kategori insiden

yang ditetapkan adalah sudah benar atau belum benar. Dilakukan update

catatan insiden.

b. User satisfaction survey: meminta penilaian kepuasan pengguna atas

penanganan insiden yang telah dilakukan.

c. Incident documentation: memastikan bahwa semua kegiatan penanganan

insiden sudah dicatat secara lengkap.

d. Ongoing or recurring problem?: menetapkan apakah insiden benar-benar

sudah terselesaikan dan memutuskan langkah-langkah pencegahan agar

insiden tidak terjadi lagi.

e. Formal closure: membuat laporan catatan insiden secara formal.

2.3 Standard Operating Procedure (SOP)

SOP adalah sebagai dokumen yang menjabarkan aktifitas operasional

yang dilaksanakan sehari-hari, dengan tujuan agar pekerjaan tersebut dilaksanakan

secara benar, tepat, dan konsisten untuk menghasilkan produk sesuai standar yang

telah ditetapkan sebelumnya. Pada dasarnya, prosedur merupakan instruksi tertulis

yang berfungsi sebagai pedoman untuk menyelesaikan sebuah tugas rutin atau

tugas yang berulang (repetitif) dengan cara yang efektif dan efisien untuk

menghindari terjadinya variasi atau penyimpangan sehingga dapat mempengaruhi

(19)

seringkali digunakan untuk menyebut semua dokumen yang mengatur aktifitas

operasional organisasi, termasuk protokol, instruksi kerja, lembar kerja, dan lain

sebagainya (Tathagati, 2014).

Menurut Peraturan Menteri Pendidikan dan Kebudayaan Republik

Indonesia Nomor 50 tahun 2014 tentang Sistem Penjaminan Mutu Pendidikan

Tinggi, Sistem Penjaminan Mutu Internal yang selanjutnya disingkat SPMI,

adalah kegiatan sistemik penjaminan mutu pendidikan tinggi oleh setiap

perguruan tinggi secara otonom untuk mengendalikan dan meningkatkan

penyelenggaraan pendidikan tinggi secara berencana dan berkelanjutan. Dokumen

SPMI terdiri atas dokumen standar dalam SPMI, dokumen prosedur, dan

dokumen formulir yang digunakan dalam SPMI.

Dikarenakan template yang digunakan Bagian PPTI untuk pembuatan

prosedur menggunakan standar Sistem Penjaminan Mutu Internal (SPMI) maka

seluruh dokumen prosedur yang dibuat menggunakan standar tersebut. Untuk

penamaan dokumennya sendiri juga berbeda dalam SPMI, seperti Standard

Operating Procedure (SOP) berubah menjadi Standar, Instruksi Kerja berubah

menjadi Prosedur, dan Rekam Kerja berubah menjadi Formulir.

Berdasarkan penjelasan tersebut maka dibuat Prosedur pada penelitian

Tugas Akhir ini, Prosedur ini digunakan sebagai pedoman dalam menyelesaikan

tugas rutin karena dapat digunakan untuk memastikan sebuah proses dilaksanakan

(20)

17

2.4 Work Instruction

Berdasarkan prosedur yang dirancang pada proses sebelumnya, maka

penelitian Tugas Ahir ini berlanjut pada pembuatan Instruksi Kerja (IK). IK

adalah dokumen yang mengatur secara rinci dan jelas urutan suatu aktivitas dan

hanya melibatkan satu fungsi sebagai pendukung. Dalam dokumen IK biasanya

merinci langkah demi langkah urutan sebuah aktivitas yang bersifat teknis

(Tathagati, 2014).

2.5 Work Record

Penelitian Tugas Akhir ini juga memerlukan Rekam Kerja sebagai bukti

sah dengan tujuan untuk memantau pelaksanaan Prosedur dan Instruksi Kerja

yang telah dilaksanakan berjalan dengan baik atau tidak. Menurut A. Tathagati

(2014), Rekaman merupakan bukti bahwa sistem tata kerja yang tertuang dalam

prosedur dan Instruksi Kerja telah dilaksanakan. Rekaman dapat berupa formulir

yang telah diisi, lembar kerja, grafik, database, laporan, notulen rapat, persyaratan

perundangan atau perizinan terkait organisasi/perusahaan, dan bentuk-bentuk lain

yang dapat diterima oleh organisasi sebagai bukti yang sah.

2.6 Bagan Alir Sistem

Menurut Jogiyanto (2005), bagan alir sistem (system flow) merupakan

bagan yang menunjukkan arus pekerjaan secara keseluruan dari sistem, pekerjaan

yang dilakukan oleh sistem, dan urutan dari prosedur yang ada dalam sistem.

Berikut bagan alir sistem digambarkan dengan menggunakan simbol-simbol pada

(21)

Tabel 2.1 Bagan Alir Sistem

No. Simbol Nama Simbol Flowchart Fungsi

1. Dokumen Untuk menujukkan

dokumen input dan output baik untuk proses manual, mekanik atau komputer.

2. Proses Komputerisasi Menunjukkan kegiatan

dari operasi program komputer.

3. Database Untuk menyimpan data.

4. Penghubung Menunjukkan hubungan

di halaman yang sama.

5. Penghubung Halaman

Lain

Menunjukkan hubungan di halaman lain.

6. Terminator Menandakan awal/akhir

dari suatu sistem.

7. Decision Menggambarkan logika

keputusan dengan nilai true atau false.

8. Kegiatan Manual Untuk menunjukkan

pekerjaan yang dilakukan secara manual.

9. Simpanan Offline Untuk menujukkan file

non-komputer yang diarsip urut angka.

10. Alur Data Untuk menunjukkan

(22)

19 BAB III

METODE PENELITIAN

Metode penelitian merupakan tahapan yang dibutuhkan dalam Tugas

Akhir ini, agar dalam pengerjaan yang dilakukan dapat terarah dan sistematis.

Penelitian ini dilakukan melalui tiga tahap, yaitu tahap awal, tahap pembuatan

prosedur Incident Management, dan tahap akhir. Tahapan-tahapan tersebut

terdapat dalam gambar 3.1.

1. Tahap Awal

(1.1) Studi L iteratur

(1.2) Pengumpulan Data dan Informasi

Wawancara

Observasi

2. Tahap Pembuatan Prosedur Incident Management

(2.1)

Identifikasi Kebutuhan Prosedur

(2.2)

Pembuatan Prosedur

(2.3) Evaluasi

Verifikasi Prosedur

Validasi Prosedur

3. Tahap Akhir

Kesimpulan Saran

Dokumentasi

(23)

3.1 Tahap Awal

Ada dua tahapan yang digunakan dalam tahap awal, yaitu studi literatur

serta pengumpulan data dan informasi. Untuk pengumpulan data dan informasi

dibagi lagi menjadi dua, yaitu wawancara dan observasi. Berikut dua tahapan

pada tahap awal.

3.1.1 Studi Literatur

Studi Literatur dilakukan pada saat penelitian tersebut berlangsung yang

dilakukan dengan cara mencari informasi yang berkaitan dengan topik penelitian

di perpustakaan ataupun via web. Hal ini bertujuan untuk mendapatkan

pengetahuan lebih mengenai pembuatan prosedur Incident Management yang

dibuat, seperti yang dijelaskan di bawah ini:

1. Mengenai framework ITIL V-3

2. Mengenai ITIL Service Operation

3. Mengenai ITIL Incident Management

4. Mengenai Standard Operating Procedure (SOP)

3.1.2 Tahap Pengumpulan Data dan Informasi

Pengumpulan data dan informasi dilakukan untuk mendapatkan hal-hal

yang dibutuhkan dalam menyelesaikan penelitian ini. Proses pengumpulan data

dan informasi dilakukan dengan wawancara dan observasi.

Wawancara bertujuan untuk mendapatkan informasi seperti profil

perusahaan, visi, misi, business goal, struktur organisasi, tugas dan tanggung

jawab staf terkait, dan data permasalahan layanan. Kegiatan wawancara ini

(24)

21

dengan pegawai Institut Bisnis dan Informatika Stikom Surabaya pada Bagian

PPTI. Setelah melakukan wawancara maka proses selanjutnya adalah melakukan

observasi, kegiatan ini dilakukan untuk memperhatikan berlangsungnya layanan

dan berjalannya proses penanganan pengaduan saat ini.

3.2 Tahap Pembuatan Prosedur Incident Management

Ada tiga tahapan yang digunakan dalam tahap pembuatan Prosedur

Incident Management, yaitu identifikasi kebutuhan Prosedur, pembuatan

Prosedur, dan evaluasi. Untuk evaluasi dibagi lagi menjadi dua, yaitu Verifikasi

Prosedur dan Validasi Prosedur. Berikut tiga tahapan pada tahap pembuatan

Prosedur Incident Management.

3.2.1 Identifikasi Kebutuhan Prosedur

Data dan informasi dari proses wawancara dan observasi dianalisis untuk

mengetahui permasalahan yang terjadi pada Bagian PPTI. Kemudian hasil analisis

tersebut dilakukan identifikasi untuk mengetahui kebutuhan membangun sebuah

prosedur. Identifikasi yang dilakukan mengacu pada proses penanganan

pengaduan yang berlangsung saat ini dan proses Incident Management pada

Service Operation - ITIL V-3. Gambar 3.2 merupakan alur identifikasi kebutuhan

prosedur.

Proses yang harus diikuti selama pengelolaan insiden meliputi sembilan

proses Incident Management yaitu: 1) Incident Identification, 2) Incident Logging,

3) Incident Categorization, 4) Incident Prioritization, 5) Incident Diagnosis, 6)

Management Escalation, 7) Investigation and Diagnosis, 8) Resolution and

(25)

Kebutuhan PPTI Kondisi PPTI

Saat Ini Best Practice ITIL

Analisis Kebutuhan Prosedur

Kebutuhan Prosedur

Referensi

Gambar 3.2 Alur Identifikasi Kebutuhan Prosedur

3.2.2 Tahap Pembuatan Prosedur

Tahap ini merupakan tahap pembuatan Standar, Prosedur, Formulir.

Dokumen ini dibuat berdasarkan identifikasi yang telah dilakukan sebelumnya

dan didapatkan data-data yang berhubungan dengan sembilan proses untuk

mendefinisikan Incident Management. Setelah pembuatan standar, dilakukan

analisis untuk mengetahui tahap yang membutuhkan detil langkah yang

selanjutnya dibuat prosedur. Hasil dari analisis ini diketahui jumlah prosedur yang

dibuat untuk mendukung standar, sedangkan formulir disesuaikan dengan

kebutuhan standard dan prosedur. Analisis kebutuhan formulir digunakan untuk

menentukan laporan, panduan, maupun dokumen pendukung yang dibutuhkan

agar proses pengelolaan dapat berjalan dengan baik. Gambar 3.3 merupakan alur

(26)

23

Best Practice ITIL Kebutuhan Prosedur

Pembuatan Prosedur

SOP Instruksi Kerja Rekam Kerja

Menghasilkan Referensi

Gambar 3.3 Alur Pembuatan Prosedur

3.2.3 Evaluasi

Tahap evaluasi merupakan penyesuaian dari hasil pembuatan prosedur

Incident Management yang telah dibuat dengan framework ITIL V-3 untuk

kemudian diverifikasi oleh Kepala Bagian PPTI. Verifikasi menggunakan teknik

wawancara yang bertujuan untuk menyesuaikan antara langkah dan proses

operasional penanganan gangguan yang dilakukan saat ini dengan langkah dan

proses perbaikan penanganan pengaduan berdasarkan framework ITIL V-3.

Gambar 3.4 merupakan alur verifikasi Prosedur.

Tahap Verifikasi Prosedur

Input Proses Output

P

h

a

s

e

SOP Instruksi Kerja Rekam Kerja Melakukan Verifikasi Prosedur

Terverifikasi

(27)

Setelah verifikasi selanjutnya divalidasi oleh Kepala Pusat Pengawasan

dan Penjaminan Mutu. Tujuan dari pengesahan ini adalah untuk menghasilkan

kesepakatan isi prosedur yang dilakukan uji coba sudah sesuai dengan kebutuhan

sehingga dokumen prosedur dapat terdokumentasi. Gambar 3.5 merupakan alur

Validasi Prosedur.

Tahap Validasi Prosedur

Input Proses Output

P

h

a

s

e

Melakukan Validasi Prosedur

Tervalidasi

SOP Instruksi Kerja Rekam Kerja Terverifikasi

Gambar 3.5 Tahap Validasi Prosedur

3.3 Tahap Akhir

Pada tahap ini dijelaskan kesimpulan dari apa yang dikerjakan pada

proses pembuatan prosedur Incident Management. Hasil kesimpulan menyajikan

langkah dan proses yang telah diperbaiki (ditambahkan atau dikurangi) dan yang

telah disesuaikan dengan framework ITIL V-3. Saran, berisi tentang saran

perbaikan terhadap kekurangan yang ada dari prosedur Incident Management

yang telah dibuat. Terakhir dokumentasi, berupa dokumentasi prosedur Incident

(28)

25 BAB IV

HASIL DAN PEMBAHASAN

Pada Bab IV ini membahas hasil yang didapatkan dari masing-masing

metode dari tahap awal, pembuatan prosedur Incident Management, dan tahap

akhir. Terdapat perbedaan istilah dokumen dikarenakan template yang digunakan

Bagian PPTI untuk pembuatan prosedur menggunakan standar Sistem Penjaminan

Mutu Internal (SPMI) menurut Peraturan Menteri Pendidikan dan Kebudayaan

Republik Indonesia Nomor 50 tahun 2014 dan dikombinasikan dengan framework

ITIL V-3 maka seluruh dokumen prosedur yang dibuat menggunakan standar

tersebut. Untuk istilah dokumennya terdapat pada tabel 4.1.

Tabel 4.1 Perbedaan Istilah Dokumen

Sistem Tata Kerja Sistem Penjaminan Mutu Internal (SPMI)

Standard Operating Procedure (SOP) Standar Work Instruction (Instruksi Kerja) Prosedur Work Record (Rekam Kerja) Formulir

4.1 Hasil Tahap Awal

Ada dua tahapan yang digunakan dalam tahap awal, yaitu studi literatur

serta pengumpulan data dan informasi. Untuk pengumpulan data dan informasi

dibagi lagi menjadi dua, yaitu wawancara dan observasi. Berikut hasil dua tahapan

pada tahap awal.

4.1.1 Hasil Studi Literatur

Pada tahap ini membahas hasil studi literatur untuk mendapatkan

(29)

Management, dan mengenai Standard Operating Procedure (SOP) dan telah

dituangkan pada bab 2.

4.1.2 Hasil Tahap Pengumpulan Data dan Informasi

Salah satu tahap pada tahap awal adalah pengumpulan data dan informasi

yang dilakukan dengan wawancara dan observasi. Hasil wawancara dapat dilihat

pada Lampiran 1. Dalam tahap ini menghasilkan beberapa output berupa data-data

yang dibutuhkan dalam penelitian yang terkait dengan studi kasus. Berikut adalah

tabel 4.2 tentang visi, misi, dan business goal Bagian PPTI pada Institut Bisnis dan

Informatika Stikom Surabaya.

Tabel 4.2 Visi, Misi, dan Business Goal Bagian PPTI

(30)

27

Visi Misi Business Goal

4. Menyediakan sumber

daya manusia dengan kapasitas dan

kemampuan yang profesional.

Berdasarkan wawancara yang telah dilakukan, diketahui bahwa Bagian

PPTI memiliki struktur organisasi yang dapat dilihat pada gambar 4.1. Bagian PPTI

dipimpin oleh Kepala Bagian PPTI yang bertanggung jawab atas Staf atau pegawai

di bawahnya.

Kepala Bagian

Administrasi

Kasie

Pengembangan

Jaringan

Kasie

Pengembangan

Sistem Informasi

Administrasi

Jaringan

Database

Programmer

Web

Programmer

Junior

Programmer

Gambar 4.1 Struktur Organisasi Bagian PPTI

Bagian PPTI terdiri atas dua pembagian kerja yaitu pengembangan

jaringan dan pengembangan sistem informasi. Sie pengembangan jaringan

bertanggung jawab terhadap ketersediaan jaringan untuk pelaksanaan teknologi

(31)

bertanggung jawab terhadap penyediaan sistem informasi yang diperuntukkan bagi

seluruh civitas akademika. Pada tabel 4.3 berikut merupakan tugas dari kepala

bagian, pengembangan jaringan, dan pengembangan sistem informasi.

Tabel 4.3 Tugas dan tanggung jawab pada Bagian PPTI

Posisi Tugas dan Tanggung Jawab

Kepala Bagian 1. Mengoordinasikan penyusunan blue print

pengembangan Bagian PPTI dan road map pencapaiannya sesuai dengan Rencana Strategi (Renstra) Institut Bisnis dan Informatika Stikom Surabaya yang meliputi model pengelolaan dan pengembangan teknologi informasi dan sumber daya manusia (SDM).

2. Menyusun dan melaksanakan rencana proker

tahunan PPTI sebagai pedoman kerja

berdasarkan blue print dan road map PPTI

3. Menyusun dan mengendalikan anggaran tahunan

PPTI

4. Merancang dan mengoordinasi pembuatan

aplikasi untuk kebutuhan operasional internal.

5. Melakukan pemeliharaan perangkat keras

jaringan STIKOMNet dan aplikasi internal.

6. Melakukan pemeliharaan data, antara lain

melakukan proses backup dan menentukan kontrol hak akses.

7. Melakukan dokumentasi aplikasi internal dan manajemen jaringan STIKOMNet.

8. Menjalankan fungsi data-center (dokumen dijital dan data) untuk mengakomodasi seluruh kebutuhan Sekolah Tinggi.

9. Melakukan pengontrolan terhadap manajemen

jaringan.

10.Memberikan hak akses terhadap aplikasi-aplikasi yang berkaitan dengan kebutuhan akses jaringan Internet.

11.Melakukan pengontrolan terhadap koneksi

jaringan Internet.

12.Memberikan pelayanan help-desk berkaitan

dengan fasilitas aplikasi internal dan jaringan STIKOMNet.

13.Melakukan evaluasi terhadap pengembangan dan

penerapan teknologi informasi.

14.Merencanakan, memberikan masukan, serta

(32)

29

Posisi Tugas dan Tanggung Jawab

perangkat lunak untuk menjamin berlangsungnya sistem yang lebih efisien.

15.Mengevaluasi pelaksanaan proker dan anggaran

PPTI sebagai bahan pertimbangan dalam penyusunan rencana proker dan anggaran ditahun berikutnya.

Kasie Pengembangan Jaringan

1. Mendesain dan mengimplementasikan sistem

komputer jaringan dan yang akan digunakan organisasi.

2. Mengelola resource yang ada dengan sebaik-baiknya, termasuk masalah hak akses dan keamanan.

3. Mengelola user dan group yang ada, termasuk hubungan dengan masalah keamanan dan akses terhadap resources yang ada.

4. Menyediakan lingkungan kerja yang diperoleh oleh user.

5. Menjaga agar sistem jaringan dan sistem

komputer tetap dalam kondisi yang prima.

6. Menjaga agar sistem jaringan dan sistem

komputer bebas dari gangguan internal maupun eksternal.

7. Menjaga agar resources yang ada dapat

tersimpan dengan baik (melakukan backup) dan dapat dikembalikan apabila dibutuhkan.

8. Mengembalikan kondisi jaringan seperti sedia kala apabila terjadi bencana.

9. Mengembalikan kondisi resources seperti sedia kala apabila terjadi bencana.

10.Mengembalikan data user yang ada diserver seperti sedia kala apabila terjadi bencana.

11.Membantu bagian perencanaan/manajemen

untuk menentukan teknologi yg akan diterapkan organisasi.

12.Membantu dan/atau melayani user untuk

berbagai gangguan yang terjadi yang diakibatkan oleh sistem komputer maupun sistem jaringan.

13.Membantu bagian perencanaan untuk

menyediakan prosedur kerja dalam

memanfaatkan sistem komputer dan jaringan yang sesederhana mungkin bagi user.

14.Membantu bagian perencanaan untuk

menyediakan sistem komputer atau jaringan yang cukup skalabel.

(33)

Posisi Tugas dan Tanggung Jawab Kasie Pengembangan

Sistem Informasi

1. Menyusun rencana pengembangan sistem

informasi yang terintegrasi

2. Menyusun rencana sistem perekaman dan

pengamanan data dan informasi yang ada.

3. Mengkoordinir semua sistem informasi yang

dikembangkan di unit-unit kerja menuju sistem informasi yang terintegrasi.

4. Mengembangkan software yang mengolah data

menjadi informasi untuk bagian yang terkait.

5. Mendesain, membangun, mengembangkan atau

memelihara situs web organisasi.

6. Membantu melayani instalasi software aplikasi yang dikembangkan Bagian PPTI.

7. Membantu bagian lain dalam menentukan sistem

informasi apa yang dibutuhkan untuk

menyelesaikan dan mencapai tujuan mereka.

8. Melakukan pengarahan dan/atau pelatihan

penggunaan aplikasi yang masih sangat baru (sosialisasi) dengan bekerja sama dengan bagian terkait.

9. Memastikan bahwa data yang dibutuhkan selalu

tersedia bagi mereka yang membutuhkan dan melakukan tuning suapaya database berperforma baik.

10.Melakukan pemeliharaan data, antara lain

melakukan proses backup secara berkala dan menentukan kontrol hak akses.

11.Test backup atau rencana pemulihan secara teratur.

12.Back up atau memodifikasi aplikasi, web, dan data yang terkait untuk menyediakan pemulihan kerusakan.

13.Melakukan dokumentasi aplikasi baik yang

berbasis desktop maupun web.

14.Merencanakan, memberikan masukan, serta

melakukan peningkatan perangkat keras dan perangkat lunak untuk menjamin berlangsungnya sistem yang lebih efisien.

15.Melakukan evaluasi terhadap pengembangan dan

penerapan teknologi informasi.

Berdasarkan wawancara yang telah dilakukan, diketahui terdapat beberapa

permasalahan pada Bagian PPTI. Beberapa permasalahan tersebut dapat dilihat

(34)

31

Tabel 4.4 Data Permasalahan Layanan

No Insiden

(Pernah Terjadi)

Dampak PIC

1 Gangguan jaringan 1.Sistem tidak dapat

diakses/beroperasi dengan normal 2.Aplikasi tidak dapat

diakses/dijalankan 3.Website tidak dapat

diakses

Kasie

pengembangan jaringan

Listrik padam 1. Website tidak dapat

diakses

2. Proses operasional terhenti

Server down Tidak dapat menjalankan

sistem

Gangguan sistem 1. Aplikasi tidak dapat

diakses/dijalankan

2. Komputer mengalami

hang

3. Aplikasi tiba-tiba terhenti

Tabel 4.5 Perbandingan proses Incident Management ITIL V-3 dengan proses penanganan pengaduan saat ini

Incident Management ITIL Proses PPTI Keterangan

Incident Identification Ada Namun proses dilakukan langsung oleh pihak Incident Logging Ada Namun bila pengguna

(35)

Incident Management ITIL Proses PPTI Keterangan

dilakukan pencatatan sebagai histori insiden Bagian PPTI

Incident Categorization Tidak Ada Kategori dilakukan sendiri oleh pengguna saat

melakukan pelaporan di web interface

Incident Prioritization Ada Prioritas insiden dilakukan oleh pengembang

berdasarkan perkiraan, pengetahuan, dan

pengalaman masing-masing Initial Diagnosis Ada Namun dilakukan oleh pihak

administrasi jika insiden sudah pernah terjadi minimal tiga kali

Incident Escalation Ada Penanganan insiden

dilakukan oleh pengembang berdasarkan perkiraan, pengetahuan, dan

pengalaman masing-masing pengembang

Investigation and Diagnosis Tidak Ada Belum ada kegiatan

Investigation and Diagnosis Resolution and Recovery Tidak Ada Belum ada kegiatan

Resolution and Recovery

Incident Closure Ada Namun hanya laporan pada pengguna, tidak ada penilaian kepuasan pengguna,

dokumentasi lengkap, dan laporan catatan secara formal

Setelah melakukan wawancara pada tahap pengumpulan data dan

informasi, kegiatan selanjutnya adalah melakukan observasi. Observasi dilakukan

untuk melihat penanganan pengaduan yang dilakukan saat ini pada Bagian PPTI

dengan membandingkan kegiatan proses ITIL V-3 - Service Operation - Incident

(36)

33

4.2 Hasil Tahap Pembuatan Prosedur Incident Management

Ada tiga tahapan yang digunakan dalam tahap pembuatan prosedur

Incident Management, yaitu identifikasi kebutuhan menurut ITIL V-3, pembuatan

prosedur itu sendiri, dan evaluasi. Berikut tiga tahapan pada tahap pembuatan

prosedur Incident Management.

4.2.1 Hasil Identifikasi Kebutuhan Prosedur

Data dan informasi dari proses wawancara dan observasi dianalisis untuk

mengetahui permasalahan yang terjadi pada Bagian PPTI. Kemudian hasil analisis

tersebut dilakukan identifikasi untuk mengetahui kebutuhan membangun sebuah

prosedur. Identifikasi yang dilakukan mengacu pada proses penanganan pengaduan

yang berlangsung saat ini dan proses Incident Management pada Service Operation

- ITIL V-3.

Proses yang harus diikuti selama pengelolaan insiden meliputi 9 proses

Incident Management yaitu: 1) Incident Identification, 2) Incident Logging, 3)

Incident Categorization, 4) Incident Prioritization, 5) Incident Diagnosis, 6)

Management Escalation, 7) Investigation and Diagnosis, 8) Resolution and

Recovery, 9) Incident Closure. Proses analisis berdasarkan identifikasi pada

Incident Management di Service Operation - ITIL V-3 dan juga hasil analisis

kebutuhan Standar dengan ketentuan satu atau beberapa proses dalam Incident

Management memiliki keterkaitan fungsi menyelesaikan insiden yang terjadi

(37)

33

Tabel 4.6 Identifikasi Kebutuhan Standar

No Kebutuhan PPTI Kondisi PPTI Saat Ini Best Practice ITIL Analisis Kebutuhan

Dokumen

1 Membutuhkan alur

kerja dan pembagian tugas yang benar dan jelas pada proses berdampak pada user dan sejauh mungkin sumber laporan dipantau agar insiden atau potensi insiden terdeteksi dini.

Adanya alur kerja dan pembagian tugas dapat meminimalkan kesalahan pada tindakan identifikasi dan pihak yang

bertanggung jawab. Isi alur kerja tersebut tentang proses identifikasi sumber pelaporan insiden karena jika yang

diidentifikasi masalah maka sudah terdeteksi oleh user termasuk juga proses pemantauan sumber laporan di dalamnya.

Standar Identifikasi Insiden

2 Membutuhkan alur

kerja dan pembagian tugas yang benar dan jelas pada proses yang berkaitan dengan sifat insiden dicatat dan siapapun yang berhubungan dengan insiden harus melakukan pencatatan untuk dibuat rekam insiden. Penanganan insiden lebih lanjut saat

(38)

34

Dokumen pelaporan dibuatkan rekam

insiden yang terpisah.

melalui website dan

pencatatan oleh pihak yang terlibat pada insiden harus dilaporkan kembali pada a. Lakukan diskusi dengan

kepala bagian dan pihak pengembangan untuk memutuskan level kategori insiden dari top ke lower level

b. Gunakan kategori insiden yang sudah diputuskan untuk percobaan dalam jangka waktu pendek c. Analisis insiden yang sering terjadi selama periode yang telah disepakati berdasarkan rekam insiden yang telah dibuat

d. Lakukan review dan

pengulangan kegiatan

Pengkategorian berfungsi agar Bagian PPTI tidak menemui kesulitan untuk mengelompokkan insiden. Pada saat

(39)

No Kebutuhan PPTI Kondisi PPTI Saat Ini Best Practice ITIL Analisis Kebutuhan Dokumen untuk mengetahui kategori

yang telah ditetapkan sudah sesuai atau perlu dilakukan perubahan level kategori lain

Melakukan cek Service Request karena terkadang bukan insiden sehingga harus diteruskan ke proses Request Fulfilment

4 Membutuhkan alur

kerja dan pembagian tugas yang benar dan jelas pada proses

didasarkan pada urgency dan akibat yang akan

b. Jumlah kegiatan atau layanan yang terkena dampak insiden

c. Level kehilangan finansial d. Dampak terhadap reputasi

bisnis

(40)

36

Dokumen e. Pelanggaran terhadap

peraturan

Melakukan pengecekan terhadap insiden termasuk dalam major incident atau tidak dan perlu adanya kesepakatan bahwa insiden tersebut termasuk dalam major incident

5 Membutuhkan alur

kerja dan pembagian tugas yang benar dan jelas pada proses selesai saat pelapor masih terhubung berdasarkan analisis dari informasi yang telah diberikan, jika tidak terselesaikan dapat meminta waktu untuk mencatat insiden dan memberikan resolusi seperti diselesaikan pihak yang berkompeten.

Adanya alur kerja dan pembagian tugas dapat meminimalkan kesalahan pada tindakan diagnosis awal dan pertama kali insiden terjadi data detil dikumpulkan dan disimpan

6 Membutuhkan alur

kerja dan pembagian tugas yang benar dan

Penanganan insiden dilakukan oleh pengembang

Terdapat tiga kondisi penting saat penanganan:

Adanya alur kerja dan pembagian tugas dapat meminimalkan kesalahan

Standar Eskalasi Hierarki

(41)

a. Jika terdapat insiden serius maka harus ditangani dengan cepat oleh pihak yang tepat atau bersifat informasi

b. Jika proses investigasi dan diagnosis atau resolution c. Jika terjadi pertentangan

tentang kepada siapa insiden dialokasikan Melakukan rekam insiden sesuai dengan yang telah terjadi dan diperbaharui jawab, yang dihubungi dan waktu harus menghubungi, serta mencatat bukti saat penanganan.

7 Investigasi dan

diagnosis pada

a. Memastikan bahwa dalam

kasus insiden termasuk dampak pada insiden bila

Standar Investigasi dan Diagnosis

(42)

38

Dokumen dan bila insiden maka dilakukan investigasi dan

c. Konfirmasi dampak yang

ditimbulkan pada pengguna

d. Identifikasi kegiatan yang menyebabkan terjadinya insiden

e. Pencarian catatan insiden sebelumnya

f. Semua yang terlibat dalam penanganan melakukan

8 Penyelesaian dan

penanganan pada insiden yang telah ditangani

Belum ada kegiatan resolution and recovery

Ketika resolusi potensial telah diidentifikasi harus

(43)

No Kebutuhan PPTI Kondisi PPTI Saat Ini Best Practice ITIL Analisis Kebutuhan Dokumen

a. Meminta dan memandu

pengguna melakukan tindakan yang diperlukan secara langsung

b. Melakukan remote event

c. Meminta pihak yang

berkompeten untuk menangani insiden secara langsung

d. Meminta pihak ketiga untuk menangani insiden yang terjadi

e. Semua kegiatan harus dicatat secara detil

(44)

41

Setiap Standar yang dibuat memiliki tujuan berbeda untuk itu perlu

dilakukan pendefinisian untuk mengetahui masing-masing Standar yang telah

dibuat. Hasil dari deskripsi tujan masing-masing Standar dapat dilihat pada tabel

4.7.

Tabel 4.7 Hasil Deskripsi Tujuan Standar

No. Standar Deskripsi Tujuan

1 Standar Identifikasi Insiden a. Agar tindakan identifikasi insiden

yang dilakukan staf dapat konsisten dan jelas alur tugas serta tanggung jawabnya

b. Agar terhindar dari kesalahan atau keraguan menentukan langkah dan staf yang betanggung jawab dalam identifikasi insiden pada layanan sistem informasi dan jaringan

2 Standar Mencatat Insiden a. Agar tindakan pencatatan insiden

yang dilakukan staf dapat konsisten dan jelas alur tugas dan tanggung jawabnya termasuk isi dari catatan tentang insiden pada layanan sistem informasi dan jaringan baik laporan sebelum serta sesudah adanya penanganan

b. Agar terhindar dari kesalahan atau keraguan menentukan langkah dan staf yang betanggung jawab dalam pencatatan insiden pada layanan dan sistem informasi dan jaringan termasuk saat menerima laporan dari pihak yang menangani harus dibuatkan rekam insiden yang

berbeda dengan laporan dari

pengguna

3 Standar Mengkategorikan

Insiden

a. Agar tindakan kategori insiden

(45)

4 Standar Memprioritaskan

Insiden

a. Agar tindakan prioritas insiden yang dilakukan staf dapat konsisten dan jelas alur tugas serta tanggung jawabnya

b. Agar terhindar dari kesalahan atau keraguan menentukan langkah dan staf yang betanggung jawab dalam prioritas insiden pada layanan sistem informasi dan jaringan

5 Standar Diagnosis Awal a. Agar tindakan diagnosis awal

insiden yang dilakukan staf dapat konsisten dan jelas alur tugas serta tanggung jawabnya termasuk dalam pengumpulan dan penyimpanan data detil insiden pada layanan sistem informasi dan jaringan untuk menjadi solusi alternatif

b. Agar terhindar dari kesalahan atau keraguan menentukan langkah dan staf yang betanggung jawab dalam diagnosis awal insiden termasuk

dalam memberikan keputusan

tentang penyelesaian atau

pemberian resolusi pada pengguna

6 Standar Eskalasi Hierarki a. Agar tindakan eskalasi hierarki

b. Agar terhindar dari kesalahan atau keraguan menentukan langkah dan staf yang betanggung jawab dalam eskalasi insiden termasuk dalam

menentukan staf yang harus

dihubungi, waktu harus

menghubungi, serta langkah yang harus diambil untuk menangani

insiden pada layanan sistem

informasi dan jaringan

7 Standar Investigasi dan

Diagnosis

a. Agar tindakan investigasi dan

diagnosis insiden yang dilakukan staf dapat konsisten dan jelas alur tugas dan tanggung jawabnya termasuk dalam membuat rekam

insiden pada layanan sistem

informasi dan jaringan

(46)

43

staf yang betanggung jawab dalam investigasi dan diagnosis insiden termasuk memastikan, memahami kronologi, identifkasi penyebab, dan pencarian data insiden pada layanan sistem informasi dan jaringan

8 Standar Resolusi dan

Pemulihan

a. Agar tindakan resolusi dan

pemulihan yang dilakukan staf dapat konsisten dan jelas alur tugas serta tanggung jawabnya

b. Agar terhindar dari kesalahan atau keraguan menentukan langkah dan staf yang betanggung jawab dalam resolusi dan pemulihan

9 Standar Menutup Insiden a. Agar tindakan penutupan insiden

b. Agar terhindar dari kesalahan atau keraguan menentukan langkah dan staf yang betanggung jawab dalam penutupan insiden pada layanan sistem informasi dan jaringan

Setelah identifikasi kebutuhan Standar maka selanjutnya dilakukan

identifikasi kebutuhan Prosedur. Berdasarakan analisis yang telah dilakukan

diketahui bahwa terdapat Standar yang membutuhkan informasi lebih detil, seperti

telihat pada tabel 4.8.

Tabel 4.8 Identifikasi Kebutuhan Prosedur

No Standar Analisis Kebutuhan Dokumen

1 Standar Identifikasi

Insiden

2 Standar Mencatat

(47)

5 Standar Diagnosis

Awal

6 Standar Eskalasi

Hierarki

7 Standar Investigasi

dan Diagnosis

8 Standar Resolusi

dan Pemulihan

9 Standar Menutup

(48)

45

3. Prosedur membuat

laporan keseluruhan

Setiap Prosedur yang dibuat memiliki tujuan berbeda, untuk itu perlu

dilakukan pendefinisian untuk mengetahui masing-masing Prosedur yang telah

dibuat. Hasil dari deskripsi tujan masing-masing Prosedur dapat dilihat pada tabel

4.9.

Tabel 4.9 Hasil Deskripsi Tujuan Prosedur

No Prosedur Deskripsi Tujuan

1 Prosedur melakukan identifikasi

insiden

Memberikan langkah secara detil dalam melakukan identifikasi insiden

2 Prosedur mencatat data pengaduan Memberikan langkah secara detil

dalam mencatat data pengaduan

3 Prosedur melakukan diskusi untuk

penentuan level kategori

Memberikan langkah secara detil dalam melakukan identifikasi insiden

4 Prosedur melakukan percobaan

level kategori dalam jangka pendek

Memberikan langkah secara detil dalam melakukan percobaan level kategori dalam jangka pendek

5 Prosedur melakukan review pada

level hasil penentuan

Memberikan langkah secara detil dalam melakukan review pada level hasil penentuan

6 Prosedur melakukan pengulangan

kegiatan

Memberikan langkah secara detil dalam melakukan pengulangan kegiatan

7 Prosedur melakukan pengecekan

service request

Memberikan langkah secara detil dalam melakukan pengecekan service request

8 Prosedur melakukan penilaian

prioritas

Memberikan langkah secara detil dalam melakukan penilaian prioritas

9 Prosedur menentukan prioritas

penanganan insiden

Memberikan langkah secara detil dalam menentukan prioritas penanganan insiden

10 Prosedur mengecek histori insiden Memberikan langkah secara detil

dalam mengecek histori insiden

11 Prosedur menentukan diagnosis

awal

(49)

No Prosedur Deskripsi Tujuan

12 Prosedur melakukan eskalasi

hierarki

Memberikan langkah secara detil dalam melakukan eskalasi hierarki

13 Prosedur menentukan investigasi

dan diagnosis

Memberikan langkah secara detil dalam menentukan investigasi dan diagnosis

14 Prosedur menetukan resolusi dan

pemulihan

Memberikan langkah secara detil dalam menetukan resolusi dan pemulihan

15 Prosedur melakukan konfirmasi

pada dokumentasi insiden

Memberikan langkah secara detil dalam melakukan konfirmasi pada dokumentasi insiden yang telah ditetapkan

16 Prosedur menentukan kepuasan

pengguna

Memberikan langkah secara detil dalam menentukan kepuasan pengguna

17 Prosedur membuat laporan

keseluruhan

Memberikan langkah secara detil dalam membuat laporan

keseluruhan

Setelah hasil Standard dan Prosedur diperoleh berdasarakan aliran Incident

Management, selanjutnya identifikasi kebutuhan Formulir yang berguna untuk

mendukung Standar dan Prosedur, sehingga bentuk Formulir dapat berupa laporan,

surat atau panduan tertentu. Berikut hasil identifikasi kebutuhan Formulir dan

(50)

46

Tabel 4.10 Identifikasi Kebutuhan Formulir

No. Standar Prosedur Analisis Kebutuhan Dokumen

1 Standar Identifikasi

Insiden

Prosedur melakukan identifikasi insiden

Perlu adanya record tentang

identifikasi sumber laporan sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir laporan identifikasi insiden

2 Standar Mencatat

Insiden

Prosedur mencatat data pengaduan

Perlu adanya record tentang pencatatan data pengaduan sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir laporan data pengaduan

3 Standar

Perlu adanya record tentang diskusi penentuan level kategori sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

1. Formulir diskusi penentuan level kategori

2. Laporan penentuan level kategori

Prosedur melakukan percobaan level kategori dalam jangka pendek

percobaan level kategori dalam jangka pendek sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Laporan percobaan level kategori

Prosedur melakukan review pada level hasil penentuan

Perlu adanya record tentang review pada level hasil penentuan sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Laporan review level hasil penentuan

(51)

No. Standar Prosedur Analisis Kebutuhan Dokumen Prosedur melakukan

pengulangan kegiatan

pengulangan kegiatan sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir laporan pengulangan kegiatan

Prosedur melakukan pengecekan service request

pengecekan service request sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir laporan pengecekan

Perlu adanya record tentang hasil penilaian prioritas insiden sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir laporan penilaian prioritas

Prosedur menentukan prioritas penanganan insiden

Perlu adanya record tentang hasil penentuan prioritas penanganan insiden sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Laporan prioritas penanganan insiden

5 Standar Diagnosis

Awal

Prosedur mengecek histori insiden

Perlu adanya record tentang hasil pengecekan histori insiden sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Laporan histori insiden

Prosedur melaksanakan diagnosis awal

Perlu adanya record tentang hasil penentuan diagnosis awal sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir pelaksanaan diagnosis awal

(52)

48

No. Standar Prosedur Analisis Kebutuhan Dokumen

6 Standar Eskalasi

Hierarki

Prosedur melakukan eskalasi hierarki

Perlu adanya record tentang hasil eskalasi hierarki sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

1. Formulir laporan kegagalan

penanganan

2. Formulir laporan eskalasi

hierarki

7 Standar Investigasi

dan Diagnos

Prosedur menentukan investigasi dan diagnosis

Perlu adanya record tentang hasil investigation and diagnosis sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir laporan investigasi dan diagnosis

8 Standar Resolusi

dan Pemulihan

Prosedur menentukan resolusi dan pemulihan

Perlu adanya record tentang hasil menentukan resolusi dan pemulihan sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Laporan resolusi dan pemulihan

9 Standar Menutup

Insiden

Prosedur melakukan konfirmasi pada dokumentasi insiden

Perlu adanya record tentang hasil konfirmasi pada dokumentasi insiden yang telah ditetapkan sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Laporan konfirmasi pada dokumentasi insiden

Prosedur menentukan kepuasan pengguna

Perlu adanya record tentang hasil penentuan kepuasan pengguna sebagai catatan agar kegiatan tersebut

terdokumentasi secara baik dan rapi.

Formulir laporan kepuasan pengguna

Prosedur membuat laporan keseluruhan

Perlu adanya record tentang hasil pembuatan laporan keseluruhan sebagai catatan agar kegiatan tersebut terdokumentasi secara baik dan rapi.

Formulir laporan keseluruhan

(53)

4.2.2 Hasil Pembuatan Prosedur

Setelah mengidentifikasi kebutuhan prosedur yang dibuat, langkah

selanjutnya adalah membuat prosedur tersebut. Tahap pembuatan Standar dan