Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
ISSN: 2089-9815
EVALUASI MENAJEMEN INSIDEN PT. XYZ MENGGUNAKAN GAP ANALYSIS Rachmasari Wicaya Ningdyah1, Annisah Nurlaily2, Tania Rahma3, Esti Widyapraba4, Hanim Maria Astuti5 Jurusan Sistem Informasi, Fakultas Teknologi Informatika, Institut Teknologi Sepuluh Nopember Surabaya Kampus ITS, Sukolilo, Surabaya 60111 Telp. (031) 5999944, Faks. (031) 5964965 E-mail:
[email protected],
[email protected],
[email protected],
[email protected],
[email protected]
ABSTRAKS Dalam menangani insiden yang berhubungan dengan operasional sistem sehari-hari sebuah proses bisnis diperlukan manajemen insiden. Manajemen insiden yang baik, paling tidak proses dan aktivitasnya dijalankan secara terstruktur serta didokumentasikan dengan baik sesuai dengan best practice yang diacu, salah satunya adalah Manajemen Insiden ITIL v3. Sedangakan untuk melakukan evaluasi terkait proses dan aktivitas apa yang belum dilakukan oleh sebuah instansi atau unit dalam melakukan manajemen insiden, perlu dilakukan analisis kesenjangan antara berbagai kondisi. Analisis kesenjangan yang pertama adalah antara kondisi kekinian dengan kondisi yang diharapkan, dilanjutkan dengan analisis kesenjangan kedua antara hasil analisis kesenjangan yang pertama dengan kondisi ideal bagaimana melakukan manajemen insiden. Makalah ini bertujuan ini untuk memberikan wawasan bagaimana melakukan analisis kesenjangan antar kondisi-kondisi tersebut dimana hasil yang diharapkan adalah usulan atau rekomendasi sistem untuk mengurangi kesenjangan. Kata Kunci: manajemen insiden, gap analysis, ITIL 1.
PENDAHULUAN PT. XYZ Surabaya adalah sebuah anak perusahaan transportasi BUMN yang terkemuka di Indonesia. PT. XYZ memiliki unit yang bernama unit Sistem Informasi (SI), yang memiliki tugas memastikan layanan TI terus tersedia dengan baik. Untuk masalah pengadaan perangkat TI dan segala macam peraturan serta kebijakan, merupakan wewenang dari unit SI PT. XYZ pusat yang ada di Bandung. Sehingga fungsi utama unit SI adalah untuk menjaga keberlangsungan operasional TI dari masalah-masalah yang mungkin dapat menggangu merupakan hal yang sangatlah penting. Luasnya cakupan tanggung jawab yang harus ditangani unit SI dan terbatasnya jumlah karyawan SI (hanya ada 6 karyawan yang harus menangani insiden TI di 52 kota di Jawa Timur) sudah seharusnya unit SI memiliki sebuah strategi yang baik dalam menangani insiden terkait TI yang ada. Unit SI sebaiknya memiliki sebuah cara agar semua insiden yang ada dapat ditangani dengan baik dan tidak terus terulang. Namun demikian, kondisi unit SI saat ini tidaklah seperti itu. Masih banyak insiden terkait TI, yang mayoritas tidak terlalu besar, terus menerus terulang kembali. Hal ini mengindikasikan manajemen insiden pada unit SI PT. XYZ masih belum terlalu baik, dan tentu akan menghambat tugas unit SI yang lain dalam menyelesaikan insiden atau masalah yang lebih besardan lebih penting.
Oleh karena itu, untuk dapat mengurangi beban kerja dari karyawan Unit SI menangani setiap keluhan yang berhubungan dengan TI, diperlukan manajemen insiden yang baik. Adanya manajemen insiden ditujukan untuk dapat mengelola insideninsiden yang frekuensi terjadinya terbilang sering untuk dapat segera ditangani dengan solusi terbaik agar nantinya tidak berujung menjadi masalah yang besar. Salah satu cara untuk mengetahui apakah manajemen insiden telah dilakukan dengan baik atau belum adalah dengan melakukan evaluasi menggunakan analisis kesenjangan berdasarkan suatu acuan yang merupakan best practice dari manajemen insiden. Dengan melakukan evaluasi ini, akan diketahui hal apa saja yang sudah dan belum dilakukan dalam mencapai kondisi manajemen insiden yang baik berdasarkan best practice yang diacu. Salah satu best practice yang membahas mengenai manajemen insiden adalah ITIL V3 proses Service Operation bagian Incident Management. Dalam penelitian kali ini, hal yang lebih banyak dibahas adalah aktivitas-aktivitas apa saja yang harus dilakukan untuk dapat sampai pada tahap mengusulkan perbaikan sistem, yang didalamnya mencakup aktivitas untuk menggali dan menelaah mengenai kondisi kekinian, kondisi sebenarnya yang diharapkan, serta kondisi ideal sesuai dengan yang tercantum pada framework yang diacu (IAHRQ Quality Indicators Toolkit, 2012). Dengan adanya
406
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
hal-hal ini maka bisa dilakukan analisis kesenjangan antara kondisi-kondisi yang telah digali tersebut sehingga pada akhirnya dapat digunakan untuk membuat usulan rekomendasi yang tepat. 2. STUDI LITERATUR 2.1 Studi Sebelumnya Pentingnya teknologi informasi dalam mendukung tujuan bisnis suatu organisasi semakin lama semakin meningkat. Hal ini menjadikan keselarasan antara layanan operasional TI dengan proses bisnis organisasi suatu hal yang perlu diperhatikan. Salah satu caranya untuk mengetahui seberapa besar keselarasan itu adalah dengan melakukan evaluasi yang kemudian hasilnya bisa dijadikan acuan untuk menbuat usulan perbaikan. Studi sebelumnya mengenai optimalisasi layanan operasional aplikasi SI di suatu organisasi dengan menggunanakan metode gap analysis telah membuktikan bisa menghasilkan usulan-usulan perbaikan yang dikemas dalam sebuah dokumen tata kelola yang sesuai standar acuan. (Bestrya, Pribadi, & Maria, 2014) Studi lain yang menggunakan metode serupa yakni gap analysis adalah studi mengenai pembuatan SOP Service Desk suatu organisasi (Rachmi, Susanto, & Herdiyanti, 2014) yang menghasilkan sebuah dokumen SOP terstandar serta saran-saran terkait dengan pelaksanaan SOP. Studi serupa yang membahas mengenai Service Desk dan menggunakan metode gap analysis adalah mengenai desain manajamen Service Desk layanan jaringan pemerintah daerah (Widyaningrum & Affandi, 2014) yang menghasilkan desain service desk sesuai dengan standar ITIL V3. 2.2 Evaluasi Dalam makalah (Wahyunengsih, 2013), disebutkan bahwa evaluasi merupakan penilaian yang dilaukan secara sistemik guna menentukan atau menilai kegunaan, keefektifan suatu hal yang berdasarkan suatu kriteria tertentu. Evaluasi harus memiliki tujuan yang jelas, sesuai dengan tujuan yang ditetapkan organiasasi. Ada tiga elemen utama dalam evaluasi yakni (1) kriteria/pembanding yaitu merupakan ciri ideal dari situasi yang diinginkan yang dapat dirumuskan melalui tujuan operasional, (2) bukti /kejadian adalah kenyataan yang ada yang diperoleh dari hasil penelitian, dan (3) penilaian (judgement) yang dibentuk dengan membandingkan kriteria dengan kejadian. Ada lima hal yang dapat dievaluasi dari suatu program dalam organisasi menurut (Sutjipta, 2009), yakni: 1. Kualitas: apakah program baik atau tidak baik, kualitas isi program, kegiatan pendidik, media yang digunakan, penampilan pelaksana program. 2. Kesesuaian (suitability): pemenuhan kebutuhan dan harapan peserta program. Program tidak menyulitkan atau membebani
ISSN: 2089-9815
masyarakat, sesuai dengan tingkat teknis, sosial dan ekonomis masyarakat. 3. Keefektifan : seberapa jauh tujuan tercapai. 4. Efisiensi : penggunaan sumber daya dengan baik. 5. Kegunaan (importance): kegunaan bagi pesertayang ikut terlibat dalam program. Ada beberapa kriteria yang harus dipenuhi untuk mencapai evaluasi yang efektif yakni : 1. Memiliki tujuan evaluasi yang didefinisikan dengan jelas. 2. Pengukuran dilakukan dengan saksama menggunakan alat ukur yang valid. 3. Evaluasi dilakukan subyektif mungkin yaitu bebas dari penilaian yang bersifat pribadi. 4. Kriteria yang digunakan sebagai standar harus spesifik. 5. Evaluasi harus menggunakan metode ilmiah yang pantas sehingga memiliki nilai kepercayaan yang tinggi. 6. Evaluasi harus dapat mengukur perubahan yang terjadi. 7. Evaluasi harus bersifat praktis. (Wahyunengsih, 2013) 2.3
Manajemen Insiden TI dalam ITIL V3 Menurut (Crown, 2011), dalam ITIL yakni V3, insiden TI didefinisikan sebagai interupsi yang tidak terencana pada sebuah layanan TI atau sebuah penurunan pada kualitas layanan TI. Sedangkan pengertian manajemen insiden TI menurut (Bartolini, Stefanelli, & Torton, 2008) adalah sebuah proses mengembalikan operasi dari layanan ke status normal setelah gangguan layanan, yang dilakukan oleh organisasi yang menggunakan TI. Tujuan dari manajemen insiden TI menurut (Kang, Zaslavsky, Krishnasw, & Bartolini, 2010) adalah untuk mengembalikan insiden berupa gangguan layanan TI ke keadaan normal secepat mungkin. Dalam manajemen insiden, sangatlah penting untuk menyelesaikan insiden baru secara efisien dan akurat. Namun, biasanya, proses penyelesaian insiden sebagian besar dilakukan secara manual, oleh karena itu memakan waktu dan rawan kesalahan. Menurut (Silitonga & Noor Ali, 2010), ITIL merupakan sekumpulan dari praktik-praktik terbaik untuk dapat menyelenggarakan Information Technology System Management (ITSM) yang berfokus pada penyelarasan layanan teknologi informasi dengan kebutuhan bisnis organisasi. Dalam ITIL memuat prosedur-prosedur bagaimana seharusnya layanan teknologi informasi disampaikan dengan baik sehingga dapat meningkatkan kualitas penyampaian layanan secara efektif dan efisien dengan kualitas yang tinggi pula. ITIL yang telah dikembangakan hingga versi terbaru yakni versi 3 ini menjelaskan mengenai tahapan-tahapan pengelolaan manajemen layanan TI yaitu sebagai siklus hidup layanan kedalam 5 proses, yakni 407
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
Service Strategy, Service Design, Service Transition, Service Operation dan Continual Service Improvement yang aktivitas-aktivitasnya dapat dilihat pada Gambar 1 di bawah ini:
ISSN: 2089-9815
yang ada dan membuat proyek dapat dilaksanakan dengan sukses. Analisis kesenjangan pada penelitian ini dilakukan dengan melakukan perbandingan antara kondisi kekinian, kondisi yang diharapkan dan kondisi ideal berdasarkan standar acuan tertentu, yakni ITIL V3, sehingga hasil kesenjangan yang didapat telah sesuai dengan kondisi yang diharapkan, dimana kondisi yang diharapkan tersebut telah disesuaikan dengan kondisi ideal dari standar acuan tertentu. Dengan demikian, usulan rekomendasi aksi yang dapat dilakukan untuk menangani kesenjangan yang didapat dari analisis kesenjangan telah sesuai dengan kondisi ideal berdasarkan standar acuan tersebut. 2.5
Gambar 1 Siklus hidup layanan pada ITIL V3 Dari 5 proses tersebut, yang akan menjadi acuan evaluasi pada makalah ini adalah proses Service Operation pada aktivitas Incident Management Prosedur penanganan insiden teknologi informasi berdasarkan ITIL V3 dimuat dalam Service Operation yakni Incident Management yang didefinisikan sebagai proses yang mengatur siklus hidup dari seluruh insiden yang ditujukan untuk pemulihan layanan teknologi informasi ke kondisi semula secepat mungkin dan memberikan dampak negatif seminimal mungkin pada proses bisnis yang dipengaruhi (Crown, 2011). Menurut (Crown, 2011) dalam ITIL V3, terdapat beberapa tahapan yang dapat dilakukan untuk menangani sebuah insiden, yakni: 1. Identifikasi (Identification) 2. Pencatatan insiden (Logging) 3. Kategorisasi (Classification/Categorization) 4. Prioritisasi (Prioritization) 5. Diagnosa awal (Initial Diagnosis) 6. Eskalasi (Escalating) 7. Investigasi insiden (incident investigation) 8. Pemulihan insiden (Incident Recovery) 9. Penutupan insiden (incident closure) Analisis Kesenjangan Menurut (Mazaris, Almpanidou, Wallace, Pantis, & Schofield, 2014) Analisis kesenjangan adalah pendekatan kuantitatif yang digunakan untuk mengidentifikasi kesenjangan dalam kondisi aktual dengan kondisi yang ingin dicapai. Dengan melaksanakan analisis kesenjangan, dapat diidentifikasi apa saja yang diperlukan untuk meminimalisir bahkan menghilangkan kesenjangan
Metodologi Metodologi penelitian adalah suatu langkah penjabaran proses kegiatan penelitian secara sistematis dan terstruktur yang menjadi landasan untuk menemukan penyelesaian suatu masalah yang menjadi fokus pada penelitian. Langkah penjabaran metodologi penelitian dapat digambarkan dalam bentuk diagram alir input, proses dan output. Secara menyeluruh kerangka konsep dalam penelitian pada PT. XYZ dijelaskan pada Gambar 2 berikut iki :
2.4
Gambar 2 Metodologi penelitian Setelah melakukan studi literatur mengenai manajemen insiden dan menentukan standar acuan manajemen insiden, selanjutnya dilakukan 408
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
ISSN: 2089-9815
identifikasi kondisi kekinian dan kondisi yang diharapkan unit SI terkait manajemen insiden, beserta kondisi ideal manajemen insiden berdasarkan standar acuan yakni ITIL V3. Kemudian dilakukan analisis kesenjangan diantara ketiganya, dimana hasil kesenjangan yang didapatkan dapat digunakan untuk membuat rekomendasi aksi terkait manajemen insiden yang dapat dilakukan untuk menangani kesenjangan yang ada. 3. PEMBAHASAN 3.1 Identifikasi kondisi kekinian unit SI terkait manajemen insiden 3.1.1 Proses penanganan insiden/keluhan Unit SI telah mengklasifikasikan jenis laporan keluhan dalam 2 jenis, yaitu gangguan dan permintaan layanan. Klasifikasi gangguan adalah insiden/keluhan yang terjadi apabila terdapat kerusakan atau malfungsi suatu aset TI. Sedangkan klasifikasi permintaan pelayanan adalah insiden/keluhan yang terjadi apabila pelanggan meminta pelayanan seperti relokasi jaringan ketika terjadi perubahan denah sebuah ruangan. Karena PT. XYZ beroperasi dengan menggunakan sistem yang kompleks sehingga jaringan adalah yang paling utama. Selain itu, insiden/keluhan yang sering terjadi dengan dampak yang paling berpengaruh adalah kategori jaringan. Ada beberapa insiden/keluhan yang unit SI tidak dapat menanganinya. Insiden/keluhan yang berada di luar kuasa Unit SI yang paling sering terjadi adalah terjadi gangguan dari Telkom. Untuk menangani insiden/keluhan khusus seperti yang disebutkan, Unit SI berupaya dengan terus menghubungi pihak Telkom yang terkait agar ditangani secepatnya. Dari semua insiden/keluhan TI yang terjadi, mayoritas penanganan dilakukan dengan pemanduan langsung melalui media telepon. Alur manajemen insiden pada unit SI dapat diilustrasikan seperti pada Gambar 3. 3.1.2 Kondisi kekinian sistem pengelolaan insiden/keluhan Dalam sistem pengelolaan insiden/keluhan unit SI PT. XYZ memiliki database khusus untuk menyimpan insiden/keluhan yang telah terjadi. Selain itu, solusi penanganan insiden/keluhan tersebut juga disimpan. Database tersebut dimanfaatkan sebagai laporan dan pembelajaran untuk karyawan unit SI dalam menangani insiden/keluhan. Namun, aplikasi yang dapat menampilkan database insiden/keluhan yang masuk unit SI hanya dapat diakses oleh karyawan unit SI sendiri. PT. XYZ belum memiliki aplikasi pelaporan insiden/keluhan untuk karyawan non-TI.
Gambar 3 Alur manajemen insiden pada unit SI 3.1.3 Jumlah insiden/keluhan yang terjadi Sebagai unit dalam perusahaan yang mendukung keberlangsungan ketersedian TI, unit SI PT. XYZ sangat sering menerima insiden/keluhan yang masuk dari pihak eksternal unit SI. Dalam 79 insiden/keluhan yang terjadi tersebut, didapatkan 60 insiden/keluhan dalam jenis gangguan dan 19 dalam jenis permintaan layanan. Selain itu, didapatkan pula jumlah insiden/keluhan dari berbagai kategori. Kategori – kategori insiden/keluhan yang diterima oleh Unit SI adalah Aplikasi Anggaran, E-mail, Hardware, Jaringan, KA-Kedatangan, Sibarka, Sikaba, Siloka, Software, Ticketing RTS, dan Aplikasi lainnya. Insiden/keluhan eksternal unit SI tersebut lebih sering terjadi dibandingkan dengan insiden/keluhan yang terjadi pada internal unit SI. 3.1.4 Hasil Identifikasi Kondisi Kekinian Berdasarkan hasil wawancara yang didapatkan, maka dapat teridentifikasi kondisi kekinian di unit SI 409
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
PT. XYZ (dimana parameternya adalah aktivitas manajemen insiden yang telag disebutkan pada Bab I sub bab 1.2.2 Manajemen Insiden TI). Pada Tabel 1 di bawah ini dijelaskan salah satu contoh hasil identifikasi kondisi kekinian pada proses diagnosa awal atau initial diagnosis:
Proses Manajemen Insiden ITIL V3
ISSN: 2089-9815
Aktivitas Manajemen Insiden ITIL V3
Tabel 1 Identifikasi kondisi kekinian unit SI Proses Manajemen Insiden ITIL V3 Diagnosa awal
Aktivitas Manajemen Insiden ITIL V3 Mengetahui solusi
Mengetahui workarounds
Mengetahui error (known error)
Kondisi Kekinian
Mengetahui workaround s
Telah dilakukan diagnosa awal terhadap insiden oleh staf teknis. Jika insiden ditemukan oleh service desk melalui telepon dari user, maka diusahakan service desk tersebut yang menyelesaikan insiden selama user masih berhubungan telepon. Terdapat solusi awal/sementara jika suatu masalah belum ada solusinya. Namun jika masalah tetap tidak bisa ditangani oleh unit SI, maka akan dilakukan eskalasi Terdapat aplikasi khusus yang dapat menyimpan database insiden/keluhan yang masuk unit SI yang digunakan untuk mengidentifikasi awal permintaan layanan dari user.
Identifikasi kondisi yang diharapkan unit SI terkait manajemen insiden Berdasarkan identifikasi kekinian terkait manajemen insiden yang ada, maka selanjutnya dilakukan identifikasi terhadap harapan mengenai pengelolaan insiden/keluhan di unit SI PT. XYZ di masa mendatang (dimana parameternya adalah aktivitas manajemen insiden yang telah disebutkan pada Bab I sub bab 1.1.2 Manajemen Insiden TI). Pada Tabel 2 di bawah ini dijelaskan salah satu contoh hasil identifikasi kondisi yang diharapkan terkait manajemen insiden pada proses diagnosa awal atau initial diagnosis :
Mengetahui error (known error)
3.2
Tabel 2 Identifikasi kondisi yang diharapkan Proses Manajemen Insiden ITIL V3 Diagnosa awal
Aktivitas Manajemen Insiden ITIL V3 Mengetahui solusi
Kondisi Kekinian
Kondisi yang Diharapkan
Telah dilakukan diagnosa awal terhadap insiden oleh staf teknis. Jika insiden ditemukan oleh service desk melalui telepon dari
Sistem akan memberikan solusi atau bila belum ada solusi maka sistem akan menyuruh user menghubungi Unit SI.
3.3
Kondisi Kekinian user, maka diusahakan service desk tersebut yang menyelesaikan insiden selama user masih berhubungan telepon. Terdapat solusi awal/sementar a jika suatu masalah belum ada solusinya. Namun jika masalah tetap tidak bisa ditangani oleh unit SI, maka akan dilakukan eskalasi
Terdapat aplikasi khusus yang dapat menyimpan database insiden/keluha n yang masuk unit SI yang digunakan untuk mengidentifik asi awal permintaan layanan dari user.
Kondisi yang Diharapkan
Sistem akan memberikan solusi/perbaik an/penanggula ngan sementara atas suatu gangguan yang terjadi. Jadi, dengan workaround ini user dapat tetap menjalankan tugasnya meskipun ada gangguan, namun sumber gangguan yang sebenarnya belum teratasi. Sistem akan otomatis menyimpan masalah yang pernah terjadi sebelumnya dalam database, sehingga dapat diketahui solusi masalahnya untuk mengidentifik asi awal permintaan layanan dari user
Identifikasi kondisi ideal terkait manajemen insiden berdasarkan ITIL V3 Setelah kondisi kekinian dan kondisi yang diharapkan terkait manajemen insiden telah diientifikasi, langkah selanjutnya adalah mengidentifikasi kondisi ideal atau yang seharusnya ada terkait manajemen insiden berdasarkan suatu standar acuan. Berikut ini identifikasi kondisi ideal dari tiap sub sub proses atau aktivitas manajemen insiden berdasarkan ITIL V3: 1. a. Proses Manajemen Insiden ITIL V3 : Identifikasi (Identification) b. Aktivitas Manajemen Insiden ITIL V3 : Pemantauan ke semua komponen Kondisi Ideal : 410
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
Semua komponen seharusnya selalu dimonitor sehingga kesalahan atau potensial kesalahan dapat dideteksi lebih cepat sehingga proses manajemen insiden dapat dimulai secepat mungkin Pendeteksian insiden Kondisi Ideal : Terdapat Service Desk yang dapat dihubungi ketika ada permasalahan terjadi pada pengguna 2.
ISSN: 2089-9815
a. Proses Manajemen Insiden ITIL V3 : Pencatatan insiden (Logging) b. Aktivitas Manajemen Insiden ITIL V3 : Pencatatan insiden Kondisi Ideal : Semua insiden harus tercatat, baik insiden dari telepon atau dari otomatis terdekteksi melalui sebuah event alert Elemen pencatatan insiden/masalah Kondisi Ideal : Terdapat ID unik pada pencatatan insiden Terdapat tanggal dan waktu pada pencatatan insiden Terdapat metode notifikasi pada pencatatan insiden (misal telepon, email, intranet portal, event monitoring system) Terdapat data agen Service Desk pada pencatatan insiden (jika memungkinkan, agen Service Desk yang mendaftarkan insiden) Terdapat data penelepon/pengguna pada pencatatan insiden (jika memungkinkan, informasi kontak penelepon/pengguna) Terdapat metode Callback pada pencatatan insiden Terdapat deskripsi gejala pada pencatatan insiden Terdapat data pengguna, lokasi dan/atau area bisnis yang dipengaruhi pada pencatatan insiden Terdapat data layanan yang dipengaruhi pada pencatatan insiden Terdapat pemrioritasan insiden pada pencatatan insiden, yang meliputi : o Urgency (waktu yang tersedia hingga resolusi dari insiden) o Impact atau dampak (kerusakan atau potensi kerusakan pada bisnis atau infrastruktur TI)
o Priority (misal, dapat dinyatakan dengan kode seperti "Critical", "High", "Medium", "Low", "Very Low"): merupakan hasil dari kombinasi urgency dan impact o Major Incident flag (untuk mengindikasikan bawa insiden diperlakukan sebagai sebuah Major Incident) Terdapat data Configuration Items (CI) yang dipengaruhi oleh insiden pada pencatatan insiden. Terdapat kategori insiden pada pencatatan insiden (misal: Hardware error, Software error) Terdapat catatan insiden sebelumnya yang terkait pada pencatatan insiden (menghubungkan insiden sebelumnya yang serupa dengan insiden terbaru) Terdapat histori perubahan status insiden pada pencatatan insiden meliputi : o Tanggal dan waktu o Orang yang bertanggung jawab o Alasan perubahan status o Status baru insiden Terdapat log aktivitas/ histori resolusi pada pencatatan insiden Terdapat data penutupan (closure data) pada pencatatan insiden, meliputi : o Kategori penutupan atau closure categories (jika dibutuhkan, lakukan revisi produk dan kategorisasi insiden) o Potensi timbulnya masalah o Tipe resolusi o Tanggapan pelanggan
3. a. Proses Manajemen Insiden ITIL V3 : Kategorisasi b. Aktivitas Manajemen Insiden ITIL V3 : Memutuskan Kategori level yang sesuai Kondisi Ideal : Terdapatnya multi level kategori insiden yang ditentukan oleh kelompok mendukung terkait Memutuskan penggunaan tools yang akan digunakan dalam kategori Kondisi Ideal : Terdapat tools yang akan digunakan dalam setiap level kategori insiden Uji coba kategori dalam periode tertentu Kondisi Ideal : 411
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
Kategori sebaiknya diuji coba terlebih dahulu dalam periode waktu tertentu untuk memastikan bahwa kategori yang ditetapkan telah sesuai Terdapat data jumlah insiden yang masuk pada setiap level kategori Menganalisis hasil uji coba kategori Kondisi Ideal : Terdapat hasil analisis dari data uji coba kategori Melakukan perincian kategori Kondisi Ideal : Terdapat hasil analisis yang lebih terperinci Peninjauan ulang kategori Kondisi Ideal : Melakukan tinjuan ulang dan melakukan aktifitas aktifitas kategorisasi secara berkala untuk memastikan kategori selalu relevan
ISSN: 2089-9815
Adanya masukan untuk penanganan insiden secara keseluruhan dan dapat memberikan solusi atas insiden. Mengetahui workarounds Kondisi Ideal : Adanya solusi sementara jika suatu masalah belum ada solusinya, biasanya solusi sementara untuk bug perangkat lunak Mengetahui error (known error) Kondisi Ideal : Terdapat database penyimpan masalah yang dikenali (known error) yang digunakan untuk mengidentifikasi awal permintaan layanan dari user. 6. a. Proses Manajemen Insiden ITIL V3 : Eskalasi (Escalating) b. Aktivitas Manajemen Insiden ITIL V3 : Menentukan triggers untuk eskalasi Kondisi Ideal : Terdapat pengukuran tingkat kompleksitas dari insiden, dan lamanya eskalasi, jika insiden tidak dapat diselesaikan dalam jangka waktu yang telah ditentukan. Menentukan tingkat eskalasi dalam bentuk eskalasi hirarki Kondisi Ideal : Seharusnya ada tindakan menaikkan level penanganan kepada manajer IT atau manajer bisnis yang terkait Menetapkan triggers pada eskalasi hirarki Kondisi Ideal : Terdapat kondisi/ aturan/prosedur, yang menyebabkan eskalasi ke tingkat tertentu dalam eskalasi hirarki.
4. a. Proses Manajemen Insiden ITIL V3 : Prioritisasi b. Aktivitas Manajemen Insiden ITIL V3 : Melakukan prioritisasi insiden Kondisi Ideal : Terdapat matriks acuan sebagai tools melakukan pemrioritasan setiap insiden yang masuk Terdapat data insiden yang telah diprioritaskan meliputi : o Urgency (waktu yang tersedia hingga resolusi dari insiden) o Impact atau dampak (kerusakan atau potensi kerusakan pada bisnis atau infrastruktur TI) o Priority (misal, dapat dinyatakan dengan kode seperti "Critical", "High", "Medium", "Low", "Very Low"): merupakan hasil dari kombinasi urgency dan impact o Major Incident flag (untuk mengindikasikan bawa insiden diperlakukan sebagai sebuah Major Incident)
7. a. Proses Manajemen Insiden ITIL V3 : Investigasi insiden (incident investigation) b. Aktivitas Manajemen Insiden ITIL V3 : Menentukan kembali apakakah klasifikasi insiden sudah dilakukan dengan benar Kondisi Ideal : Investigasi insiden dilakukan dengan menggunakan informasi terkait mengenai insiden berupa deskripsi gejala. Selain itu dibutuhkan juga informasi mengenai layanan terkait
5. a. Proses Manajemen Insiden ITIL V3 : Diagnosa awal b. Aktivitas Manajemen Insiden ITIL V3 : Mengetahui solusi Kondisi Ideal : 412
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
yang mungkin terkena dampak, CI, pengguna, insiden terkait, dll. Melakukan pengecekan pada intial support yang telah diberikan Kondisi Ideal : Pengecekan initial support dilakukan untuk menilai apakah penanganan awal dilakukan dengan benar atau belum sesuai dengan keluhan yang dilaporkan. Aktivitas ini bisa dilakukan dengan melakukan pengecekan terhadap checklist pelaporan insiden. Melakukan investigasi terhadap solusi yang diberikan Kondisi Ideal : Jika kedua aktivitas sebelumnya telah dilakukan dan dilalui dengan sukses maka investigasi terhadap solusi dilakukan dengan menentukan solusi yang tepat untuk diterapkan dengan penambahan target penerapan solusi yang disesuaikan dengan kebutuhan perusahaan. 8. a. Proses Manajemen Insiden ITIL V3 : Pemulihan insiden (Incident Recovery) b. Aktivitas Manajemen Insiden ITIL V3 : Pemanduan proses pemulihan Kondisi Ideal : Pemanduan proses pemulihan dapat dilakukan dengan memandu pelapor melalui telepon, namun harus ada langkah-langkah pemanduan yang jelas dan terdokumentasi dengan baik yang bisa disebut dengan dokumen pemulihan (recovery document). Melakukan testing terhadap insiden yang telah dipulihkan dan sistem lain yang berhubungan Kondisi Ideal : Testing terhadap sistem terkait insiden yang telah dipulihkan dilakukan sesuai dengan prosedur testing tertentu yang ada pada service description. Testing dilakukan untuk memastikan semua gejala insiden telah hilang dan tertangani dengan baik. Melakukan investigasi terhadap solusi yang diberikan Kondisi Ideal : Jika kedua aktivitas sebelumnya telah dilakukan dan dilalui dengan sukses
ISSN: 2089-9815
maka investigasi terhadap solusi dilakukan dengan menentukan solusi yang tepat untuk diterapkan dengan penambahan target penerapan solusi yang disesuaikan dengan kebutuhan perusahaan. 9. a. Proses Manajemen Insiden ITIL V3 : Penutupan insiden (incident closure) b. Aktivitas Manajemen Insiden ITIL V3 : Melakukan konfirmasi terhadap status pemulihan insiden (sukses atau tidak) Kondisi Ideal : Konfirmasi status pemulihan insiden bisa dilakukan melalui telepon dengan memastikan kepada pengguna apakah layanan operasi yang ada sudah seperti seharusnya. 3.4
Analisis kesenjangan I : antara kondisi kekinian dan kondisi yang diharapkan terkait manajemen insiden Setelah dilakukan identifikasi terhadap kondisi kekinian, kondisi yang diharapkan, serta kondisi ideal terkait manajemen insiden, langkah berikutnya adalah melakukan analisis kesenjangan yang pertama yakni antara kondisi kekinian dan kondisi yang diharapkan terkait manajemen insiden. Pada Tabel 3 di bawah ini dijelaskan salah satu contoh analisis kesenjangan yang dilakukan terhadap kondisi kekinian unit SI dan kondisi yang diharapkan oleh unit SI terkait manajemen insiden pada proses diagnosa awal atau initial diagnosis : Tabel 3 Analisis kesenjangan I Aktivitas Manajemen Insiden ITIL V3 Mengetahui solusi
Mengetahui workarounds
413
Kondisi Kekinian Telah dilakukan diagnosa awal terhadap insiden oleh staf teknis. Jika insiden ditemukan oleh service desk melalui telepon dari user, maka diusahakan service desk tersebut yang menyelesaikan insiden selama user masih berhubungan telepon. Terdapat solusi
Kondisi yang Diharapkan
Analisis Kesenjangan I
Sistem akan memberikan solusi atau bila belum ada solusi maka sistem akan menyuruh user menghubung i Unit SI.
(Tidak ada kesenjangan, baik kondisi kekinian dan kondisi yang diharapkan, ketika ada gangguan maka akan langsung memberikan solusi)
Sistem akan memberikan
Belum sistem
adanya yang
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015 Aktivitas Manajemen Insiden ITIL V3
Kondisi Kekinian awal/sementar a jika suatu masalah belum ada solusinya. Namun jika masalah tetap tidak bisa ditangani oleh unit SI, maka akan dilakukan eskalasi
Mengetahui error (known error)
Terdapat aplikasi khusus yang dapat menampilkan database insiden/keluha n yang masuk unit SI yang digunakan untuk mengidentifik asi awal permintaan layanan dari user.
Kondisi yang Diharapkan solusi/perbai kan/penangg ulangan sementara atas suatu gangguan yang terjadi. Jadi, dengan workaround ini user dapat tetap menjalankan tugasnya meskipun ada gangguan, namun sumber gangguan yang sebenarnya belum teratasi. Sistem akan otomatis menyimpan masalah yang pernah terjadi sebelumnya dalam database, sehingga dapat diketahui solusi masalahnya untuk mengidentifi kasi awal permintaan layanan dari user
ISSN: 2089-9815
Tabel 4 Analisis kesenjangan II Analisis Kesenjangan I
Aktivitas Manajemen Insiden ITIL V3 Mengetahui solusi
secara otomatis memberikan solusi /perbaikan/pena nggulangan sementara atas suatu gangguan yang terjadi sebab masih ditangani secara langsung oleh unit SI.
Adanya masukan untuk penanganan insiden secara keseluruhan dan dapat memberikan solusi atas insiden.
Mengetahui workarounds
Adanya solusi sementara jika suatu masalah belum ada solusinya, biasanya solusi sementara untuk bug perangkat lunak
Mengetahui error (known error)
Terdapat database penyimpan masalah yang dikenali (known error) yang digunakan untuk mengidentifik asi awal permintaan layanan dari user.
Belum adanya sistem yang secara otomatis menyimpan insiden yang pernah terjadi setelah insiden selesai ditangani.
Analisis kesenjangan II : antara hasil analisis kesenjangan I dengan kondisi ideal manajemen insiden pada ITIL V3 SO 4.2 Incident management Setelah dilakukan analisis kesenjangan yang pertama dan didapatkan hasil kesenjangan antara kondisi kekinian dan kondisi yang diharapkan terkait manajemen insiden, langkah selanjutnya adalah melakukan analisis kesenjangan antara hasil analisis kesenjangan pertama dengan kondisi ideal terkait manajemen insiden yang telah diidentifikasikan sebelumnya. Pada Tabel 4 di bawah ini dijelaskan salah satu contoh analisis kesenjangan yang dilakukan terhadap hasil analisis kesenjangan sebelumnya dengan kondisi ideal manajemen insiden yang berdasarkan pada standar acuan yang dipilih yakni ITIL V3 SO 4.2 Incident Management proses diagnosa awal atau initial diagnosis :
Kondisi Ideal
3.5
3.6
Analisis Kesenjang an I
Analisis Kesenjangan II
(Tidak ada kesenjanga n, baik kondisi kekinian dan kondisi yang diharapkan, ketika ada gangguan maka akan langsung memberika n solusi) Belum adanya sistem yang secara otomatis memberika n solusi /perbaikan/ penanggula ngan sementara atas suatu gangguan yang terjadi sebab masih ditangani secara langsung oleh unit SI. Belum adanya sistem yang secara otomatis menyimpan insiden yang pernah terjadi setelah insiden selesai ditangani.
(Tidak ada kesenjangan karena jika ada gangguan maka akan langsung memberikan solusi)
Belum adanya sistem otomatis untuk memberikan solusi sementara.
Belum ada sistem yang menyimpan masalah beserta solusinya.
Usulan rekomendasi manajemen insiden TI Dari analisis kesenjangan yang kedua, maka didapatkan hasil kesenjangan dari kondisi kekinian, kondisi yang diharapkan, dan kondisi ideal manajemen insiden berdasarkan ITIL V3 yang dapat digunakan untuk membuat suatu rekomendasi untuk menangani kesenjangan yang ada. Rekomendasi yang dibuat tersebut dapat dihubungkan dengan KPI dari unit SI yang dapat dipenuhi dengan adanya rekomendasi tersebut.
414
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
Pada Tabel 5 di bawah ini dijelaskan salah satu contoh usulan manajemen insiden TI berdasarkan hasil analisis kesenjangan II yang dilakukan sebelumnya proses diagnosa awal atau initial diagnosis : Tabel 5 Usulan rekomendasi manajemen insiden TI Aktivitas Manajemen Insiden ITIL V3 Mengetahui workarounds
Mengetahui error (known error)
Analisis Kesenjang an II Belum adanya sistem otomatis untuk memberika n solusi sementara.
Belum ada sistem yang menyimpa n masalah beserta solusinya.
Usulan Rekomendasi
KPI yang ditunjang
Dibuat suatu sistem yang secara otomatis memberikan solusi awal/sementara atas gangguan yang belum ditemukan solusinya Dibuat suatu sistem yang secara otomatis menyimpan masalah beserta solusinya yang digunakan untuk mengidentifikasi awal permintaan layanan dari user.
Prosentase masalah yang dapat diselesaika n dengan solusi sementara
ISSN: 2089-9815
yang diharapkan, serta analisis kesenjangan kedua antara hasil analisis kesenjangan pertama dengan kondisi ideal menurut framework. Dari hasil analisis kesenjangan kedua, bisa didapatkan hasil akhir kesenjangan yang benar-benar terlihat sehingga bisa dibuat usulan rekomendasi mengenai manajemen insiden TI yang tepat yang dapat mengurangi jarak kesenjangan tersebut.
Prosentase knowns error saat diagnosa awal
Gambar 4 merupakan usulan flow atau aliran sub proses manajemen insiden yang sesuai dengan analisis kesenjangan yang telah dilakukan. Pada gambar tersebut, proses dengan garis luar dipertebal merupakan proses yang tidak berubah dari manajemen insiden yang lama. 4.
KESIMPULAN Pada penilitian ini, aktivitas pertama yang dilakukan adalah dengan melakukan identifikasi kondisi kekinian Unit SI dalam mengangani insiden (insiden manajeman), dengan mengetahui mengenai proses penanganan insiden, sistem yang digunakan untuk menangani insiden, serta jumlah dari insiden yang berhasil diselesaikan. Hasil identifikasi tersebut kemudian disajikan dalam sebuah tabel sesuai dengan proses dan aktivitas yang ada dalam manajemen insiden ITIL v3. Selanjutnya, aktivitas yang dilakukan adalah dengan melakukan identifikasi mengenai kondisi yang sebenarnya diharapkan oleh Unit SI mengenai kondisi kekinian yang mereka hadapi yang disajikan dalam sebuah tabel. Selanjutnya, sebelum melakukan evaluasi mengenai manajemen insiden Unit SI, perlu dilakukan identifikasi mengenai kondisi ideal bagaiamana sebuah manajemen insiden seharusnya dilakukan dengan mengacu pada framework ITIL v3. Kemudian analisis kesenjangan bisa dilakukan melalui dua tahap yakni analisis kesenjangan pertama antara kondisi kekinian dengan kondisi
Gambar 4 Rekomendasi alur manajemen insiden pada unit SI
PUSTAKA Bartolini, C., Stefanelli, C., & Torton, M. (2008). SYMIAN: A Simulation Tool for the Optimization of the IT Incident Management Process. Lecture Notes in Computer Science Volume 5273, 83-94. Bestrya, R., Pribadi, A., & Maria, H. (2014). Optimalisasi Layanan Operasional Aplikasi 415
Seminar Nasional Teknologi Informasi dan Komunikasi 2015 (SENTIKA 2015) Yogyakarta, 28 Maret 2015
Manajemen Surat Pada PT. PLN (Persero) Distribusi Jawa Timur Dengan Pendekatan Tata Kelola Berbasis Service Operation Pada ITIL V3. Britannica Company. 2015. Merriam-Webster - An Encyclopedia Britannica Company, (Online), (http://www.merriamwebster.com/dictionary/gap, diakses pada 25 Januari 2015). Crown. 2011. Incident, (Online), (http://www.knowledgetransfer.net/dictiona ry/ITIL/en/Incident.htm, diakses pada 26 Januari, 2015). Crown. 2011. Incident Management, (Online), (http://www.knowledgetransfer.net/dictiona ry/ITIL/en/Incident_Management.htm, diakses pada 26 Januari 2015). IAHRQ Quality Indicators Toolkit. 2012. (Online), (http://www.ahrq.gov/professionals/system s/hospital/qitoolkit/d5-gapanalysis.pdf, diakses pada 25 Januari 2015). Mind Tools. 2015. Gap Analysis : Identifying What Needs to be Done in a Project, (Online), (http://www.mindtools.com/pages/article/g ap-analysis.htm, diakses pada 25 Januari 2015). Kang, Y.-B., Zaslavsky, A., Krishnasw, S., & Bartolini, C. (2010). A knowledge-rich similarity measure for improving IT incident resolution process. SAC '10 Proceedings of the 2010 ACM Symposium on Applied Computing, 1781-1788. Mazaris, A. D., Almpanidou, V., Wallace, B. P., Pantis, J. D., & Schofield, G. (2014). A global gap analysis of sea turtle protection coverage. Biological Conservation 173, 1723. Mind Tools. (2015). Gap Analysis : Identifying What Needs to be Done in a Project. Dipetik Januari 2015, 25, dari Mind Tools: http://www.mindtools.com/pages/article/ga p-analysis.htm Rachmi, A., Susanto, T. D., & Herdiyanti, A. (2014). Pembuatan Standar Operation Procedure (SOP) Service Desk Berdasarkan Kerangka Kerja ITIL V3 Dengan Menggunakan Metode Analisis Gap Layanan (Studi Kasus PT. XYZ, Tangerang). Teknik POMITS, 3, 175-180. Silitonga, T. P., & Noor Ali, A. H. (2010). Sistem Manajemen Insiden Pada Program Manajemen Helpdesk dan Dukungan TI Berdsasarkan Framework ITIL V3 (Studi Kasus Pada Biro Teknologi Informasi BPK-RI). Sutjipta, I. N. (2009). Manajemen Sumber daya Manusia. Bali: Universitas Udayana. Wahyunengsih, S. (2013). Evaluasi Penerimaan Retribusi Parkir Di Tepi Jalan Umum Di
ISSN: 2089-9815
Dinas Perhubungan (DISHUB) Kota Pekanbaru. Widyaningrum, H., & Affandi, A. (2014). Desain Manajemen Service Desk Layanan Jaringan Pemerintah Menggunakan Kerangka Kerja ITIL .
416