My Articles

I wrote these articles in my leisure time, some of them have published on Pustipanda’s website. Please enjoy it *-*

Persiapan implementasi iTop (Bagian ke-2)

posted Jan 13, 2016, 8:26 PM by husniteja sukmana   [ updated Jan 13, 2016, 8:31 PM ]

Setelah melakukan pengisian data-data dasar seperti lokasi, struktur organisasi, pegawai dan data peralatan (Sudah dijelaskan pada tulisan persiapan implementasi iTop bagian pertama), proses berikutnya adalah penyiapan layanan. Dalam penyiapan layanan ini (service), sangat dianjurkan untuk mengerti tentang service catalog (pembahasan terdapat pada service design) dan service portfolio (terdapat pada service strategic). Kedua bahasan ini bisa dilihat pada bab-bab sebelumnya.

Terdapat beberapa informasi yang terdapat pada sebuah service catalog, diantaranya (lihat gambar dibawah ini):

1.      Service category; misalnya nework service

2.      Nama service

3.      Contact; PIC yang akan meng-handle operasi ini, bisa juga dibuat team

4.      Service definition; ini harus dicantumkan karena definisi ini akan mem-boundary jenis layanan, misalnya layanan perbaikan hardware terdiri dari PC, Printer dll

5.      Base level service; ini penjelasan dari service definition agar lebih detail

6.      Service not included; contoh pada layanan perbaikan hardware, tidak termasuk pelayanan untuk hardware yang bukan barang kantor

7.      Service availability; ini terkait dengan waktu pelayanan

8.      Service Level Agreement; digunakan untuk memastikan kalau terjadi request baik itu sebagai pemenuhan kebutuhan maupun sebagai incident harus ditetapkan time to resolve (TTL) dan time to own (TTO)


Fig. 1 Contoh Service Catalog

 Delivery Model

Setelah kita mendapatkan list semua service catalog layanan IT yang ada, sekarang kita akan mulai mencoba untuk memasukkan service tersebut kedalam iTop. Selain harus menyiapkan field-field yang sudah ada pada service catalog, iTop meminta kita untuk men-define delivery model. Delivery model adalah sebuah objek yang mendefinisikan tim yang mana yang akan memberikan service ke pelanggan. Kita dapat menggunakan delivery model dengan menggabungkan beberapa support team untuk memberikan service ke 1 orang organisasi pelanggan. Setiap organisasi pelanggan harus memiliki HANYA satu delivery model.





Misalkan kita memiliki beberapa team, seperti: hardware support, software support, system support, network support. Kemudian kita putuskan team mana yang akan mensupport organisasi pada universitas, sebagai contoh: rektorat, akademik, kepegawaian. Setiap organisasi customer tersebut HANYA bisa dipetakan dengan 1 delivery model, dan 1 delivery model bisa digunakan lebih dari 1 organisasi Pada aplikasi iTop kita memilih organisasi pelanggan pada tab Customers (lihat gambar dibawah). Untuk organisasi pada tab Properties kita pilih serive provider yang melayani, contohnya IT department atau Puskom.

 

Service Level Target

Biasanya pada sebuah service, seperti yang kita lihat pada contoh service catalog diatas, terdapat Service level Agreement, dimana didalamnya terdapat waktu untuk penyelesaian (TTR) dan waktu untuk pengembalian (TTO). Pada aplikasi iTop, objek TTR dan TTO didefenisikan pada modul service level target (SLTs). Kita bisa menbagi beberapa service level target, contohnya sebagai berikut:

1.      Name: TTR incident high priority

2.      Name: TTR request low priority

3.      Name: TTO request medium priority

Masing-masing SLT harus didefenisikan nama, prioritas, tipe request (ex. Insiden, request atau yang lainnya), nama metric (TTR atau TTO), kemudian yang paling penting adalah berapa lama  waktu TTR dan TTO nya, ini dimasukkan ke field value (ex. 10), dan unit (ex. menit).

 

Service Level Agreement (SLA)





Definisi TTR dan TTO yang sudah dibuat di modul SLT kemudian disatukan di modul Service Level Agreement (SLA). Tidak semua SLT dimasukkan ke SLA, sesuaikan saja dengan service yang sudah direncanakan. Pada gambar dibawah ini dikasih contoh untuk SLA: PC-repairing, yang akan dilaksanakan oleh provider (ex. Puskom), setelah itu pada tab SLT, masukkan SLT yang akan digunakan untuk SLA ini.

Service Family, Service dan Service sub-kategori

Tiga kategori ini sangat penting, karena disini kita mulai memasukkan service-service yang sebelumnya sudah kita buat pada saat fase pembuatan service strategic dan service design. Ada perbedaan sedikit saja, karena sebelumnya, saat mencontohkan service catalog, kita tidak mendefinisikan service family, service dan sub-category. Sedangkan aplikasi iTop menggunakan skema 1 ke n mulai dari service family, service dan sub-service. Agar lebih memahami, ada baiknya kita melihat contoh struktur dibawah ini.


Fig. 4 Service Family, Service and Sub-Service

Network support pada struktur diatas diumpamakan sebagai service family, dibawahnya terdapat  2 service utama yaitu wifi support dan LAN support. Kemudian masing-masing service kita turunkan kembali menjadi sub service, pada contoh diatas password wifi and wifi security menjadi sub-service bagi wifi support.

Pembagian ini akan sangat bermanfaat pada saat end-user / client saat membuat tiket dengan menggunakan sistem aplikasi iTop. Kalau tidak ada pendefenisian seperti ini, maka kemungkinan yang akan terjadi adalah tiket yang masuk akan banyak sampahnya. Hal ini dikarenakan client melihat menu layanan, sehingga mungkin saja, hal-hal yang bukan menjadi layanan kita diminta.



Service Family


Pada aplikasi iTop, untuk menginput service family cukup menyiapkan nama service family-nya saja (contoh Network support).  Setelah service family kita buat (lihat gambar 5), selanjutnya service Wifi support seperti yang terlihat pada gambar 6 mulai dibuat. Ada beberapa parameter pada saat pembuatan service, pertama provider dalam hal ini adalah penyedia service (Puskom UIN), service family (Network support), status (untuk kasus ini production). Untuk data-data yang lain, bisa kita abaikan dahulu, sampai kita menyelesaikan pembuatan sub-kategori.  

Service



Untuk sub-kategori, parameter penting yang kita butuhkan adalah mendefinisikan tipe dari sub-service ini, apakah masuk kedalam kategori incident atau request (pemenuhan kebutuhan).

Sampai disini, kita sudah melakukan pendataan semua service, akan tetapi service ini belum bisa digunakan sampai kontrak dibuat. Kita akan membahas tentang consumer contract dan provider contract pada tulisan berikutnya. 


Lengkong, 1 Januari 2016

Persiapan Menggunakan iTop (Bagian Pertama)

posted Dec 28, 2015, 8:05 PM by husniteja sukmana

Persiapan Implementasi iTOP (bagian pertama)

Sebelum membaca artikel ini, ada baiknya untuk melihat-lihat terlebih dahulu tulisan-tulisan sebelumnya agar mengetahui rentetan keinginan untuk melihat Indonesia bisa menerapkan manajemen layanan berbasis IT (IT Service Management). Sebagai panduan bagi rekan-rekan sekalian, tulisan ini akan mengulas persiapan penggunaan software iTop (salah satu ITSM tools). Untuk itu diperlukan sedikitnya pengetahuan mengenai konsep dari ITSM dengan menggunakan pendekatan ITILv3 dan panduan instalasi software iTop. Semua sudah saya coba tulis pada artikel-artikel sebelum ini.

Baiklah, sekarang saatnya untuk menyiapkan hal-hal mendasar untuk menggunakan iTop dalam rangka persiapan implementasi ITSM. Contoh penggunakan iTop ini, kami menggunakan studi kasus pada sebuah univesitas. Berikut hal-hal yang harus dipersiapkan:

1.      Struktur

Organisasi dari sebuah universitas bisa dibagi menjadi 2 organisasi, satu yang bersifat struktural dan satu lagi yang sifatnya fungsional. Contoh dari struktural mulai dari Biro (eselon 2) sampai Kasubag (eselon 4). Sedangkan yang sifatnya fungsional adalah Rektorat-Dekanat-sampai ke Program Studi. Agar persiapan untuk proses pengisian di iTop lebih cepat, buatlah tabel organisasi yang terdiri dari nama, kode organisasi, status, parent dan delivery model (lihat gambar dibawah ini).   Parent digunakan untuk struktural organisasi, sedangkan delivery model (untuk sementara bisa dikosongkan) digunakan untuk menentukan jenis service yang akan digunakan (misalnya standard support atau premium support). 



 

2.      Lokasi

Lokasi digunakan untuk menentukan siapa-siapa saja user, service provider, peralatan yang berada pada sebuah lokasi. Misalnya pada lokasi sebuah universitas terdapat 3 kampus, yaitu kampus 1, kampus 2 dan kampus 3. Maka kita bisa mendata lokasi-lokasi tersebut berdasarkan nama, status, organisasi apa saja yang bekerja disana, siapa kontak –user, service provider- dan peradalatan yang berada disana. Ada beberapa kasus lokasi ini dibuat lebih detail (misalnya per-gedung). Untuk kasus di buku ini, kita cukup melokalisasi sebuah universitas menjadi (sebagai contoh) memiliki 3 kampus utama, yaitu kampus 1 (beralamat di Jln.x), kampus 2 (alamat di Jln. y), dan kampus 3 berada di Jln. z). Dibawah ini contoh file excel yang harus disiapkan.


 

3.      User / Data pegawai

Semua pegawai yang akan menggunakan jasa layanan IT harus terdata, untuk kasus universitas semua staff dan dosen harus didata, selain itu mahasiswa sebagai main stakeholder juga harus di data. Ada beberapa kampus yang menyediakan layanan IT untuk orang tua mahasiswa, maka ada baiknya kalau memang diperlukan data orang tua juga di data.

Selain mendata user secara individu, kita juga harus bisa mengelompokkan user tersebut sesuai dengan fungsinya masing-masing. Pengelompokan ini disebut juga sebagai Team. Untuk melakukan pendataan silakan disiapkan data-data sesuai excel dibawah ini.

 


 

 

4.      Pendataan peralatan / device

Semua peralatan yang masuk dalam kategori layanan IT harus didata disini. Peralatan yang ada bisa kita kategorisasikan menjadi:

a)      Infrastruktur IT

Rak server, enclosure, server, peralatan network, storage, dan lain-lain

b)      Virtualisasi

Mesin virtual, hypervisor, dan lain-lain

c)      Peralatan yang dipakai user

Personal Computer, telephone PABX, mobile phone, printer, dan lain-lain

d)     Software dan aplikasi

Web server, db server, PC software, sistem aplikasi, dan lain-lain

e)      Dan lain sebagainya

Bisnis proses, SOP, dan lain-lain

Berikut contoh untuk pendataan Personal Komputer. Yang dibutuhkan adalah ownership dari PC tersebut, organisasi, dan lokasi. Selain tentunya data-data lain seperti: kapan waktu dibeli, tahun berapa, tipe OS, RAM, CPU dll.

 

 

Instalasi iTop -Open Source ITSM Tool-

posted Dec 25, 2015, 2:11 AM by husniteja sukmana

Ada 3 hal yang harus diperhatikan dalam mengimplementasikan ITSM pada sebuah organisasi, 3 hal tersebut biasa di singkat dengan 3P, yaitu People, Proses dan Product. Semua harus di manage dengan baik agar best practice ITIL (salah satu ITSM framework) dapat diimplementasikan dengan baik. Pada artikel kali ini, kita akan memperkenalkan mengenai salah satu product (tool) ITSM yang bersifat open source. Tools tersebut adalah iTop dari combodo. Tools ini kami pilih, pertama karena sebelumnya kami sudah menggunakannya :) jadi gampang jelasinnya :), kedua kami melihat tools ini cukup lengkap dengan balutan open source (bandingkan dengan tools dari Manage Engine yang berbayar dan cukup mahal), memiliki dashboard yang cukup baik (lihat gambar dibawah).

Gambar 1. Tampilan Dashboard iTop

Sebelum instalasi iTop, berikut persyaratan-persyaratan umum yang harus dipenuhi:
  1. Environment yang dibutuhkan untuk menjalankan iTop pada server adalah: webserver, PHP minimal ver 5.3, Mysql (disini saya pakai xampp
  2. iTop source versi community yang bisa didownload dari http://sourceforge.net/projects/itop/files/
  3. Graphvis (Graph Visualization Software); digunakan untuk melihat impact / dashboard dalam beluk grafik. Bisa di download di  http://www.graphviz.org/Download_windows.php

Setelah semua telah disiapkan, langkah pertama adalah memastikan bahwa environment di syarat pertama berjalan (web server berjalan, php sudah terpasang dan mysql sudah terinstall). Kalau masih ada yang belum jalan, silakan refer ke referensi tentang cara menginstall xampp di http://www.wikihow.com/Install-XAMPP-for-Windows

Kemudian exstrak file iTop dan pindahkan ke folder htdocs (lihat gambar dibawah), pada sample dibawah saya menggunakan folder itsm.


Lanjutkan proses instalasi dengan membuka browser dan jalankan http://localhost/itsm, maka otomatis proses instalasi akan berjalan. Kalau ada warning, sialakan dibuka lagi konfigurasi PHP di php.ini. Biasanya warning terkait dengan extension modul yang dibutuhkan oleh iTop. Nanti ada beberapa yang harus diisi, terkait dengan akses database, user database, user administrator dan lain sebagainya.

Kalau semua berhasil maka binggo .... software iTop sudah siapa digunakan (lihat gambar dibawah ini)



Next kita akan bahas satu persatu mengenai penggunaan software ini


25/12 2015

Service Operation

posted Sep 21, 2015, 11:02 PM by husniteja sukmana   [ updated Sep 22, 2015, 1:11 AM ]

Service Operation (SO)  adalah salah satu fase dari framework ITIL. Pada ITILv2, SO dimasukkan dalam kategori service support (lihat gambar dibawah). Focus pada ITILv2 adalah untuk keselarasan antara IT dan bisnis, dimana dalam proses managementnya dibagi menjadi dua bagian besar yaitu Service Support dan Service Delivery. Service support focus pada aktivitas operasi harian (day-to-day activities), sedangkan Service delivery focus pada perencanaan service yang akan diberikan kepada pelanggan.

Gambar 1 ITILv2 Diagram (sumber xxxx)

Sedangkan pada framework ITILv3, dimana ITILv3 ini fokus pada integrasi bisnis dan IT, SO menjadi salah satu fase tersendiri disamping fase service strategic (SS), Service Design (SD), Service Transition (ST) dan Continual Service Improvement (CSI). SO adalah tempat dimana service fortoflio, service level management yang sudah dibuat di fase SS, service catalog di fase SD, dan service transition akan diuji langsung oleh pelanggan.

Service operasi adalah layanan harian terhadap kebutuhan IT dari para pelanggan. Contoh kebutuhan IT yang tiap hari ada contohnya:

1.       Kebutuhan akan peralatan, misalnya: printer, scanner, laptop dll

2.       Kebutuhan akan layanan jaringan, misalnya: akses internet menggunakan kabel, akses internet menggunakan wifi

3.       Kebutuhan aplikasi, misalnya: reset password, bug aplikasi dll

Dan kebutuhan tersebut para pelanggan  harus terpenuhi(sesuai dengan SLA yang sudah dibangun) agar objektif bisnis dari sebuah organisasi dapat tercapai.  Tercapainya objektif bisnis tersebut adalah tujuan dari pelaksanaan SO, disamping tujuan lainnya adalah membuat efektif hubungan  antara proses didalam SO (service request, event, incident dan problem management).

Mengapa SO ini harus dimanage sedemikian rupa? Seperti yang sudah disinggung pada pembahasan diatas, semua terkait dengan efektifitas hubungan antar proses didalam SO agar tercapatinya bisnis objecktif dari sebuah organisasi. Berikut ini adalah contoh studi kasus kenapa kita perlu memanage SO di sebuah organisasi atau perusahaan. Pada tahun 2010 kami ditunjuk sebagai team yang menangani sistem informasi disebuah perguruan tinggi. Pada awal kami ditujuk, organisasi tersebut belum merapkan layanan berbasis IT. Sehingga sebagai seorang ketua team saat itu, kami yang sering dimintai tolong untuk layanan IT yang sudah ada. Hal ini terjadi karena belum adanya service desk yang sesuai dengan tupoksi ITIL. Akibatnya untuk layanan-layanan yang sifatnya sangat sederhana, sebagai contoh reset password terkadang pelanggan tetap menghubungi Ketua. Dengan kondisi ketua yang sering rapat dan harus memanage banyak hal, terkadang hal-hal tersebut bukan membuat pelayanan menjadi cepat tetapi bahkan membuat menjadi lambat, tidak tercatat dan terkadang tidak terselesaikan.  

Kemudian kami mencoba mengubah layanan IT yang ada menggunakan konsep ITILv3, untuk fase awal kami tidak menggunakan seluruh fase yang ada, tetapi hanya menerapkan layanan service desk dengan konsep Single Point Of Contact (SPoC). Hasilnya sangat mengembirakan, terutama disisi dokumentasi terhadap masalah yang masuk ke service desk, dimana semua masalah menjadi tercatat. Team development yang tugasnya untuk memikirkan pengembangan sistem menjadi lebih focus dalam bekerja (tidak sering medapat gangguan langsung dari pelanggan). Walau kedepannya akan terjadi masalah karena penerapan SO saja tidak cukup, karena SO harus menggunakan patokan service portfolio yang sudah didefenisikan di SS dan SD dan di uji cobakan pada fase ST. Tetapi ini menjadi titik kemajuan penerapan ITSM dikampus kami.

Ada beberapa proses didalam Service Operation yang harus dimanage, dimana satu sama lain saling terkait. Proses-proses tersebut adalah:

  1. Service request (request fulfillment)
  2. Incident management
  3. Problem management
  4. Event management
  5. Access management

Kita akan membahas mengenai proses diatas satu persatu pada bab-bab selanjutnya. Sekarang kita akan melihat hubungan flow antara proses diatas (lihat gambar dibawah). Pada gambar dibawah, kita bisa melihat ada beberapa aktor yang akan men-triger layana di SO, yaitu pelanggan (end user), IT staff dan IT infrastruktur. Perbedaan diantara trigger yang ada adalah IT Infrasruktur akan meng-generate events apabila ada ada alert (melebihi threshold yang sudah ditentukan), IT Staff akan mengenerate incident dan pelanggan akan berhadapan dengan Service Desk untuk kemudian baru diitentukan apakah itu masuk kedalam service request atau berupa incident.

Gambar 2 Hubungan antar proses di SO (ITIL@2011 Edition with Case Study)

 

Dari gambar diatas kita mendapati ada beberapa fungsi yang terkait dengan satu sama lain. Fungsi disini bisa juga dimasukkan sebagai bagian pekerjaan. Ada pekerja yang berfungsi sebagai service desk, teknikal manajemen, IT Operation manajemen, dan manajemen aplikasi. Pembahasan mengenai fungsi secara detail juga akan dibahas dibahasan selanjutnya.

Ruang Dosen FST – 22 September2015

Access Management –Service Operation-

posted Sep 8, 2015, 7:59 PM by husniteja sukmana   [ updated Sep 9, 2015, 7:45 PM ]

Setiap layanan (service) pasti membutuhkan akses. Sebagai contoh: layanan permintaan data, layanan untuk reset password dan lain-lain. Akses ini sangat penting, karena jika disalah-gunakan dapat berakibat turunnya kepercayaan bagi sebuah organisasi. Kita ambil studi kasus industri perbankkan. Industri perbankan adalah industri yang sangat mengandalakan trust (Kepercayaan). Kita meletakkan dana di Bank dengan harapan dana tersebut aman. Bayangkan seandainya akses ke data-data perbankan bisa diambil oleh orang-orang yang tidak bertanggung jawab dan lebih jauh lagi data-data tersebut ternyata mengandung akses ke data pribadi atau akun pribadi nasabah. Sehingga semua bank menggunakan pengalaman berlapis dalam rangka meminimalisasi resiko. Yang kasat mata yang bisa kita lihat pengamanan berlapis akses di bank adalah di bagian teller. Setiap transaksi diatas 50 jt (tiap-tiap bank beda), harus mendapatkan izin dulu dari supervisor teller tersebut.

Dalam ITILv3, terdapat satu proses sendiri yang dinamakan access management untuk memanage siapa yang berhak dan siapa yang tidak berhak untuk bisa akses kedalam sistem. Access management ini digunakan untuk menjamin bahwa layanan IT disebuah organisasi memenui syarat-syarat confidentiality, integrity dan availability (CIA). Access management ini mengatur, mengontrol dan juga mengaudit akses terhadap layanan sehari-hari.

Access management tidak mengatur policy mengenai siapa yang berhak dan siapa yang tidak, policy sendiri diatur di service design pada process Information Security Management. Selain itu Access management juga tidak akan mengatur ketersediaan (availability) akses terhadap layanan, karena ketersediaan sudah diatur sebelumnya pada service design pada process availability management (lihat gambar dibawah ini).

 

Gambar 1 Hubungan Security, Availability Management dan Access Management

Access management akan melayanani dan memberikan efisiensi kepada siapapun yang berhak untuk mendapatkan akses sesuai aturan yang sudah dibuat di Information Security Management. Proses ini memastikan bahwa level, identitas pengakses, privilages dari pengakses semua tercatat. Apabila ada perpindahan personil disebuah organisasi, maka akses management harus segera tahu bahwa ada perubahan personil, karena ini akan menyangkut bagaimana hak akses dari personil tersebut.

Apabila ada hal-hal yang janggal, access management bisa meng-eskalasi hal-hal janggal tersebut ke proses incident. Contoh dari hal-hal janggal tersebut sebagai berikut:

  1. Saat monitoring akses ke sistem, access mananger melihat ada mantan pegawai yang ternyata masih bisa akses kedalam sistem.
  2. Personil yang sudah dipindahkan ternyata masih bisa akses  sistem seperti dia sebelum dipindahkan.

Dari contoh-contoh diatas, terlihat sekali peranan penting dari access managemen untuk menciptakan integritas dari sebuah organisasi dengan cara monitoring dan kontroling yang baik.


PLT-UIN Jakarta 9/9/2015

Event Management – Service Operation-

posted Sep 4, 2015, 3:49 AM by husniteja sukmana

Organisasi yang belum menerapkan layanan IT baik, biasanya akan berhadapan dengan banyak kendala. Pertama yang  biasa dihadapi, terutama bagi Ketua bidang IT adalah sangat bergantungnya users kepada Ketua IT. Karena belum menerapkan Single Point of Contact, Ketua IT selalu menjadi orang pertama yang akan dihubungi jika terjadi masalah dengan layanan IT. Mulai dari direktur sampai ke staff akan menghubungi Ketua IT tersebut untuk mendapatkan pelayanan yang “ katanya” bisa lebih cepat. Padahal dengan cara seperti itu, dijamin semua masalah, request dan sebagainya menjadi tidak tercatat, dan mengakibatkan waktu untuk penyelesaian akan menjadi lebih lama.

Bayangkan seandainya Ketua IT sedang rapat, atau sedang tidak berada di lokasi, atau yang lebih exsterm lagi, Ketua IT nya sedang cuti. Sudah pasti eskalasi akan menjadi lebih lambat dan mungkin saja akan baru terlaksana kalau sang Ketua sudah balik ke kantor. Akibatnya pasti akan berdampak pada bisnis dari sebuah perusahaan.

Penyelesaian dari contoh diatas pada best practice ITILv3, bisa dijembatani dengan menggunakan Service Desk dan Single Point of Contact (SPoC). Pembahasan mengenai Service desk dan Single Point of Contact bisa dilihat dibahasa tersendiri.

Yang menjadi pertanyaan selanjutnya adalah apakah permasalahan yang dimunculkan oleh users hanya satu-satunya input bagi proses incident dan problem management? Kalau organisasi IT hanya mengandalkan laporan dari users kemudian bergerak untuk menyelesaikan masalah yang ada, maka kami akan katakan bahwa cara ini adalah cari paling konvensional.

Organisasi IT harus “beyond” dari sisi informasi akan adanya masalah, jangan sampai organisasi IT hanya tahu masalah hanya karena ada laporan dari user. Untuk itu dibutuhkan cara lain yang bisa digunakan oleh organisasi IT untuk dapat mengetahui akan terjadinya masalah lebih cepat dibandingkan user. Cara lain tersebut dengan monitoring IT Infrastructure.  Dari hasil monitoring tersebut, dapat dibuat batasan (threshold) tertentu. Jika sudah mendekati atau melebihi threshold maka, akan memberitahu kepada service desk secara otomatis bahwa ada sesuatu masalah. Service desk kemudian bisa mencoba menangani dan juga bisa mengeskalasi masalah yang ada.

Dalam ITILv3, proses monitoring seluruh event yang mungkin bisa berdampak bagi layanan IT adalah bagian dari proses event management. Event management memiliki beberapa objektif diantaranya:

·         Mendeteksi perubahan-perubahan yang ada pada IT Infrastructure, IT Application  yang dapat mengakibatkan adanya efek bagi organisasi

·         Menentukan aksi yang harus dilakukan apabila ada perubahan pada kondisi dan melakukan komunikasi kepada proses lain (incident management, problem management, dll)

·         Menentukan batasan-batasan threshold perubahan-perubahan yang ada  dan memberitahu kalau perubahan tersebut sudah menyentuh nilai threshold yang sudah ditetapkan kepada Service Desk agar kemudian bisa dieskalasi ke fungsi atau struktural yang tepat

Event management dalam menentukan perubahan-perubahan yang ada sebaiknya memperhatikan Configuration Item (CI), kondisi lingkungan (environment condition), software / aplikasi, security dan lain-lain. Melihat kondisi seperti ini, maka sudah seharusnya pada saat pemilihan tools ITSM, penerapan event management ini sudah harus otomatis bisa tersambung ke proses-proses yang lain.

Setelah melihat beberapa literature yang ada, kami coba petakan langkah-langkah yang ada pada event management sebagai berikut:

1.       Tentukan semua aspek yang ingin dikontrol, misalnya dari disisi infrastruktur (server, network devices, PC), aplikasi (service aplikasi), security (firewall, akses), lingkungan (Air conditioning, kelembapan)

2.       Tentukan batasan dari item-item pada point 1 diatas, sebagai contoh:

a.       Infrastruktur

                                                               i.      Bandwidth yang melewati router harus kurang dari 10GB

                                                             ii.      Memory pada server tidak boleh lebih dari 80% dalam waktu lebih dari 1 menit

b.      Aplikasi

                                                               i.      Akses terhadap user tertentu

                                                             ii.      Service aplikasi jalan pada semua cluster

                                                            iii.      Masa lisensi dari aplikasi

c.       Lingkungan

                                                               i.      Ditetapkan suhu ruang server harus berada diantara 10-15 derajat Celcius

d.      Security

                                                               i.      Batasan terhadap ekstensi file yang diperbolehkan

                                                             ii.      Akses terhadap situs-situs tertentu

3.       Mendefenisikan level dari batasan-batasan yang sudah ditentukan. Misalnya warning berdasarkan level (hijau, kuning, merah). Kapan dinyatakan level kuning (sebagai contoh bandwidth disebuah router sudah mendekati 10GB, misalnya 9.5GB)

4.       Menentukan proses otomatisasi notifikasi kepada service desk dan juga secara struktural (IT Staff, Level Manager, CIO). Proses ini bisa menggunakan tools monitoring yang terhubung dengan CI sehingga lansung tercatat dan ternotifikasi (email, sms)

Contoh nyata untuk pelaksanaan event management yang baik, sudah diterapkan oleh beberapa Bank di Indonesia, khususnya untuk penanganan ATM. ATM yang baik harus bisa memberikan informasi ke pihak bank atau pihak yang ditunjuk oleh bank untuk menangani masalah ATM (Vendor), apabila ada masalah dengan ATM. Ada mekanisme komunikasi secara terus menerus antara mesin ATM dan sistem monitoring central. Apabila ATM mati, maka komunikasi tersebut menjadi fail (gagal), sehingga akan mentriger sistem sentral untuk memberikan notifikasi ke PIC / Vendor. Otomatis SLA akan terjaga bahwa ATM tidak akan mati lebih dari waktu yang ditentukan.

Bayangkan kalau Bank belum menerapkan proses event management, dan kebetulan ATM yang dipasang berada diluar kota dan agak terpencil. Sudah untung kalau ada users yang memberikan notifikasi via telepon untuk melaporkan ATM tersebut mati, tetapi biasaya users tidak akan melakukan itu. Users lebih senang untuk mencari ATM lain atau bisa jadi menuju ATM bank tetangga karena sudah terhubung dengan jaringan bersama.

 

Serpong – 4 September 2015-

Problem Management –Service Operation-

posted Sep 2, 2015, 7:05 AM by husniteja sukmana   [ updated Sep 2, 2015, 7:07 AM ]

Semua area yang menggunakan Best Practice ITILv3 pasti akan menggunakan pendekatan nilai (value) bagi sebuah organisasi. Service yang dilakukan  harus dapat menghasilkan value, value yang paling sering didiskusikan adalah berupa keuntungan secara financial. Sebagai contoh, mesin ATM dalam bisnis per-bank-kan, mesin tersebut digunakan sebagai media antara bank dan nasabah dalam bertransaksi. Secara kasat mata, setiap transaksi mungkin menghasilkan pendapatan bagi pihak bank, setiap transaksi antar bank, ada charge yang dikenakan kepada nasabah. Atau juga pembayaran tagihan-tagihan, semua ada “fee” kepada pihak Bank. Dan ini semua adalah bagian dari value yang dihasilkan oleh mesin ATM.

Sudah pasti akan ada hitung-hitungan secara financial tersendiri dari masing-masing bank terhadap keberadaaan mesin ATM tersebut. Tentunya akan ada kerugian apabila layanan mesin ATM tersebut ternyata tidak berfungsi. Proses mengurangi kerugian (impact) terutama yang diakibatkan oleh kesalahan (error) pada layanan IT harus dimanage dengan baik. Apalagi kesalahan yang ada sudah bersifat problem.

Dalam ITILv3, problem adalah sebuah permasalahan (satu atau banyak incident) yang terjadi dan tidak / belum diketahui akar masalahnya (root cause). Kejadian ini pasti terjadi dalam layanan IT, untuk itu harus digunakan sebuah management yang baik dalam rangka meminalisasi impact yang berdampak pada proses bisnis dari sebuah organisasi. Harapannya  tidak mengganggu proses bisnis bagi sebuah organisasi yang berdampak hilangnya value. ITILv3 menyebut proses tersebut dengan sebutan Problem Management. 

Problem management memiliki hubungan yang sangat dekat dengan incident management. Untuk mengingatkan kembali bahwa semua request baik itu request fulfilment dan incident semua masuk melalui Single Point of Contact (SPoC) yang dihandle oleh Service Desk. Service Desk kemudian akan mencatatat, mengkategorisasi, dan mementukan prioritas berdasarkan dokumen service catalog yang dian miliki. Pada saat terjadi incident, biasanya Service Desk seperti terlihat pada gambar (lihat incident management) akan melakukan eskalasi kepada fungsional dan juga struktural. Kalau tidak bisa terpecahkan, artinya akar masalahnya tidak diketahui, maka incident manager bisa melempar isu tersebut menjadi problem, dan selanjutnya akan di-handle oleh Problem Manager.

Bagaimana contoh dari problem yang harus dihandle oleh Problem Management?

Coba kita lihat kembali contoh-contoh yang pernah kita bahas di proses request fulfilment (lihat bahasan Request Fulfilment). Disana kita melihat ada proses yang bisa kita jadikan contoh yaitu: Ada report internet mati dari client. Setelah di eskalasi menjadi incident, ternyata incident management tidak bisa menentukan akar permasalahan dari matinya internet ini.

Proses di incident management mungkin sudah mencoba menyelesaikan dengan menggunakan tools koneksi atau mungkin juga dengan standar tools yaitu ping. Setelah di cek memang ada masalah ping dari gedung A ke gedung B. Tetapi di cek lagi ternyata router yang ada kedua-duanya nyala, semua konfigurasi berjalan seperti biasa. Beberapa koneksi ke alamat-alamat tertentu ternyata masih bisa di Ping. Maka incident manager bisa meng-eskalasi ke structural bahwa kasus ini masuk ke Problem Management.


Problem manager kemudian menggunakan proses flow  penanganan problem seperti yang terlihat pada gambar diatas ini.  Inti dari flow yang ada diatas adalah: diagnose (kategorisasi dan prioritas), catatat, coba diselesaikan berdasarkan catatan yang ada, kalau tidak ada solusi, coba lakukan solusi sementara (workaround) untuk memastikan layanan tetap berjalan, cari akar masalah, eskalasi (ke special group atau vendor atau 3th party), jadikan lesson learn (masukkan ke database), bisa dimasukkan ke proses yang lain (Continual Service Improvement, lesson learn atau Change Management).

 2 September 2015

 

Request Fulfilment -Service Operation-

posted Aug 27, 2015, 1:18 AM by husniteja sukmana   [ updated Aug 27, 2015, 1:23 AM ]

Dalam menggunakan framework ITSM dengan pendekatan best practices ITILv3, kita akan jumpai istilah Request Fulfilment (dalam bahasa Indonesia disebut dengan pemenuhan kebutuhan, selanjutnya kita singkat request saja). Request berbeda dengan incident dan atau problem. Kalau request biasanya berupa permintaan dari service yang sudah kita siapkan. Sedangkan incident adalah kejadian yang tidak kita harapkan dan itu terjadi (lihat pembahasan mengenai Incident Management). Incident yang terjadi berulang kali atau tidak diketahui akar masalahnya (root cause) disebut dengan problem.

Untuk mengetahui secara praktis perbedaan antara ketiga layanan diatas, ada baiknya kita melihat contoh-contoh dibawah ini:
1. Ada report internet mati dari client
2. Ada client telp ke help desk ingin ubah password
3. Report client tidak bisa blm bisa bayaran kuliah padahal sudah masa pembayaran kuliah
4. Client dari sebuah unit datang untuk meminta data alamat pegawai untuk penelitian
5. Ada pegawai report bahwa data yang sudah diisikan kemarin kok berubah?

Nah sekarang kita akan coba bahas dan pilah contoh diatas berdasarkkan incident, problem dan request fulfilment. Dari definisi yang sudah kita bahasa diatas, pertama kita akan memilah berdasarkan request (permintaan). Request artinya sebuah permintaan yang memang sudah ada cara / SOP penyelesaiannya. Tujuan lain dari request fulfilment bisa sebagai penyedia informasi dan juga penerima masukan. Kita lihat contoh nomor 1, internet mati bukan merupakan request, karena tidak ada yang ingin meminta layanan internet mati. Begitu juga contoh nomor 5, disini kelihatan sekali bahwa nilai yang berubah ini bukan sebuah request.

Untuk contoh nomor 3, dimana client tidak bisa membayar bayaran kukliah padahal sudah masa pembayaran kuliah, masih bisa kita masukkan ke request, incident dan problem. Kenapa demikian? karena kita belum bisa mengetahui secara pasti apakah ini masuk dalam ketegori request informasi (request fulfilment), atau incident atau problem. Maka harus didiagnoasa lebih dalam kenapa masalah ini muncul. Bisa saja hanya sebuah request informasi karena secara sistem ternyata memang tidak bisa bayar karena ada tunggakan sebelumnya. Kalau seperti ini, maka kita catat dikategori request fulfilment. Tetapi kalau tidak bisa bayar karena ada bug di sistem, maka bisa kita analisis lebih lanjut untuk dimasukkan ke incident atau problem.

Dari 5 contoh diatas, dapat disimpulkan bahwa yang masuk dalam kategori request fulfilment adalah contoh nomor 2, 3 (dengan catatan hanya informasi) dan contoh nomor 4. Ubah password dan permintaan data jelas masuk kedalam Request Fulfilment karena tidak ada kejadian yang tidak diharapkan dan bukan kejadian yang tidak diketahui akar masalahnya.

Bagaimana dengan incident dan problem? kita mulai dari incident dulu, contoh nomor 1, 3 dan 5 bisa kita diagnosa awal sebagai sebuah incident. Internet mati dari client harus lebih di-explore masalahnya, bisa saja sebagai incident kalau masalahnya ternyata hanya kabel-nya goyang (terlepas). Tetapi kalau ternyata semua dicoba dan tidak ketemu (misalnya routingnya hilang), maka bisa dikateogrikan sebagai problem. Untuk contoh nomor 3, bisa dikategorikan incident jika masalah tidak bisa bayar karena waktu diserver ternyata berbeda dengan kalender. Kalau untuk contoh 5, agak lebih berat kita ketegorikan sebagai problem karena akar masalahnya tidak diketahui.

Setelah mengetahui definisi dan contoh-contoh Request Fulfillment, kita juga harus tau siapa saja yang berperan untuk menjaga proses ini. Sudah jelas dan sudah pasti fungsi yang paling awal menerima Request Fulfillment ini adalah Service Desk Staff. Service desk akan memilah apalah request ini masuk kategori request fulfillment, incident ataukah problem. Selain service desk, bisa juga exsternal supplier yang harus menghandle ini (level kedua atau level ketiga) atau entitas lain dari organisasi tersebut. Inti dari proses ini sama seperti proses-proses yang lain, adalah memastikan bahwa layanan sesauai dengan SLA yang sudah ditentukan.

KPI untuk proses ini bisa kita tentukan, contoh:
% Request yang dihandle sesuai SLA
% Request yang dieskalasi tidak benar
% Request yang bisa diselesaikan oleh Service Desk

Langkah-langkah proses ini tidak jauh berbeda dan bahkan lebih sederhana dibandingkan proses incident. Intinya adalah tangkap semua request dari pelanggan, catat, diagnosa, lempar ke incident kalau memang tidak diharapkan, penyelesaian (report ke client).



27 Agustus 2015

Incident Management -Service Operation-

posted Aug 26, 2015, 9:24 PM by husniteja sukmana   [ updated Aug 27, 2015, 1:19 AM ]

Siapa diantara kita yang mau tertimpa sebuah incident? Misalnya saat jalan-jalan dikebun duren, tiba-tiba angin bertiup kencang....wusss duren jatuh nimpa kepala (ihh ... serem). Contoh yang lain, pagi-pagi naik taxi ke Bandara mau transaksi project di kota Palembang, tiba-tiba saat dijalan ban taxi bocor sehingga mengakibatkan kita ketinggalan pesawat dan akibatnya project diambil orang lain. Begitulah contoh dari incident pada kehidupan nyata.

Berdasarkan contoh diatas dan juga berdasarkan literatur-literatur yang ada, dapat didefenisikan bahwa incident adalah sebuah kejadian yang tidak diharapkan dan itu terjadi. Menurut kamus Oxford, incident is A violent event, such as a fracas or assault[1]. Nah bagaimana kalau incident ini terjadi pada layanan IT. Misalnya saat mau transaksi tiba-tiba ATM nya mati, atau saat mau download journal ilmiah eh... wifi-nya tidak nyala. Tentunya sangat tidak mengenakan bagi pelanggan dan akan lebih parah jika incident terjadi menyebabkan efek yang buruk bagi bisnis, misalnya berkurangnya pendapatan perusahaan.

Untuk itu dalam penerapan IT Service Management (ITSM), incident harus di manage. Dalam pendekatan menggunakan IT Infrastructure Library Versi 3 (ITIL-V3), kita mengenal istilah incident management yang berada pada tahapan Service Operation (dalam ITIL-v3, terdapat 5 tahapan: Service Strategy, Service Design, Service Transition, Service Operation, dan Continual Service Improvement). Incident management ini bertujuan untuk menormalisasi service operasi secepat-cepatnya dalam rangka memimalisasi efek bagi bisnis. Selain itu, incident management juga  bertujuan agar kualitas service dan ketersediaan (availability) terjaga. Harap  dicamkan, bahwa incident management ini bukan cara untuk menghindari incident, tapi lebih kepada bagaimana cara penanganan incident. Menghindari incident akan banyak dibahas Risk Management, Availability Management dan mungkin juga di Capacity Management.

Pertanyaan berikutnya akan muncul, bagaimana memanage sebuah incident? Sebelumnya kita harus mengetahui dulu bahwa objektif dari dilaksanakannya incident management ini adalah untuk memastikan bahwa SEMUA METODE DAN PROSEDURE penanganan incident dilaksanakan dalam koridor target waktu Service Level Agreement (SLA) yang sudah ditetapkan. Berikut adalah langkah-langkah penanganan sebuah incident (simple) yang saya modifikasi sedikit untuk penyederhanaan [2].



Semua proses yang berwarna kuning adalah milik dari Service Desk, Specialist Group (2sd level atau 3th level) -biasanya secara fungsi berada di application management dan Technical Management- diberi warna coklat, dan eskalasi secara hirarki untuk mendapatkan corrective action berwarna abu-abu. Terlihat disini bahwa incident management lebih banyak dikelola oleh service desk.

Proses inputan ke incident management didapat dari keluhan pelanggan dan juga dari proses event management (diberitahu secara otomatis oleh IT infrastructure melalui mekanisme monitoring yang telah melewati threshold yang sudah ditentukan). Beberapa proses penting lainnya adalah: pencatatan log, eskalasi functional (application management atau ke techinical management), eskalasi bersifat hierarchical (bisa ke IT management atau  juga ke CIO dalam rangka mendapatkan corrective action), perubahan incident ke problem atau Request for Change (RFC), dan terakhir adalan penyelesaian incident.

Selanjutnya kalau Procedure sudah ada, kita tinggal mengontrol pelaksanaan. Sesuai dengan prinsip management, semua harus bisa ukur agar bisa dikontrol, kalau sudah bisa dikontrol ka bisa dilakukan improvement[3]. Maka untuk mengukur keberhasilan proses incident management ini, kita bisa tentukan beberapa Key Performance Indicator (KPI). Beberapa KPI yaitu [2]:
  • % incident yang dihandle sesuai dengan SLA
  • % incident yang dieskalasi tidak benar
  • % incident yang bisa diselesaikan oleh service desk
  • % incident yang dikategorisasikan salah
  • dll

Incident management bisa juga dianggap sentral (terutama pada ITILv2 -Service Delivery-), dengan penanganan sesuai prosedure maka kita bisa mengatakan bahwa hasil dari proses ini bisa digunakan untuk data bagi proses-proses yang lain, misalanya: capacity planning, Service Level Management, Problem Management, Availability Management, Information Security, Access management dll.

Kesimpulan sederhana dari proses incident management ini adalah: tangkap, catat (logging), diagnosa, selesaikan sendiri, eskalasi, penyelesaian (report ke konsumen).

Referensi
[1]http://www.oxforddictionaries.com/definition/english/incident
[2] Service Operation, ITIL Foundation with Case Study
[3]http://cdn.ttgtmedia.com/searchSoftwareQuality/downloads/ect01TreasurechestSixSigma.pdf

25 Agustus 2015

1-9 of 9