Service Operation

  

A.     Konsep
a.      Pengertian, tujuan dan peran penting tahapan Service Operation
Service operation ialah tahapan operasional layanan TI sehari – hari, termasuk melakukan
aktivitas dukungan terhadap layanan TI untuk memastikan value layanan benar –benar
dirasakan dan sesuai dengan harapan serta kebutuhan pengguna yang dilakukan secara
berkala.
Service operation bertujuan untuk :
1)      Mengkoordinasikan dan melaksanakan kegiatan dan proses yang dibutuhkan untuk
memberikan layanan TI kepada pengguna dan pelanggan, serta mengelola layanan
memenuhi tingkat layanan yang telah disepakati.
2)      Mengelola teknologi yang digunakan untuk menghasilkan dan mendukung layanan TI.
Seperti bagaimana memahami dan mengelola komponen-komponen teknologi seperti server,
mainframe, jaringan komputer, komunikasi, basis data, media penyimpanan, sistem desktop
dan aplikasi software.
Peran penting dari tahapan service operation ialah adanya suatu hal yang menjalankan suatu
proses supaya bisnis berjalan dengan lancar (terukur atau hanya biasa saja) dan
menyeimbangkan konflik antar aspek (keseimbangan dari semua aspek ; Bisnis & TI, Cost &
Quality). 
b.      Event dan Jenis Event
Event ialah sebuah perubahan keadaan pada infrasturktur TI yang memiliki nilai penting bagi
manajemen layanan TI atau configuration item TI, berupa pesan atau tampilan yang
dihasilkan oleh layanan, configuration item atau alat monitoring.
Jenis – jenis event :
1)      Informasi (information) : sebuah event yang normal terjadi sehingga tidak  memerlukan
tindakan apapun, misalnya seseorang yang login ke suatu sistem.
2)      Peringatan (warning) : sebuah event yang berada diambang batas normal dengan adanya
sebuah peringatan yang nantinya memerlukan sebuah respon tindakan yang diperlukan atau
tidak untuk mencegah potensi kegagalan. Contohnya adanya peringatan bahwa volume disk
hanya tersisa 5% dari maksimum kapasitas yang diijinkan.
3)      Ketidak-wajaran (Exception) : sebuah event yang menginformasikan bahwa sebuah layanan
atau komponen berjalan tidak sewajarnya (abnormal) dan membutuhkankan respon tindakan,
seperti kecepatan akses internet yang sangat lambat.
c.       Incident vs Problem
Incident adalah kejadian interupsi sebuah layanan yang tidak terencana (tidak diharapkan)
atau penurunan kualitas sebuah layanan Ti. Sedangkan problem ialah akar (sumber,
penyebab)  dari satu atau lebih incident.
Contoh : sakit kepala yang merupakan gejala yang menginterupsi tubuh kita (incident) dan
menjadi penyebab berbagai sumber penyakit seperti tekanan darah tinggi atau kolesterol
tinggi (problem).
d.      Impact, Urgency, dan Priority
Impact Urgency Priority
Seberapa besar potensi Seberapa lama Sebuah kategori yang
kerugian yang waktu yang dibutuhkan digunakan untuk
ditimbulkan atau untuk penyelesaian atau menentukan nilai
seberapa banyak penanganan dari penting sebuah incident,
jumalah pengguna incident, problem, atau problem, atau change.
terkena dampak dari change yang memiliki Priority diukur
sebuah incident, dampak signifikasi pada berdasarkan impact dan
problem atau change bisnis.  urgency, dan digunakan
pada proses-proses Misalnya sebuah untuk menentukan
bisnis. incident yang memiliki seberapa cepat sebuah
Yang umumnya diukur impact tinggi namun tindakan respon harus
berdasarkan seberapa urgencynya rendah. segera diambil.
pemenuhan Seperti down/error Contohnya : dalam
target/standar tingkat sebuah aplikasi sebuah dokumen
layanan TI (Service akademik mahasiswa, SLA  dinyatakan bahwa
*

levels) akan secara impact sebuah incident

terpengaruh. berdampak tinggi  pada “prioritas 2” harus
mahasiswa, namun diatasi dalam waktu 12
urgencynya tidak begitu jam sejak laporan
berpengaruh pada masuk.
bisnis karena belum
efektifnya perkuliahan *SLA (Service Level
hingga semester baru Agreements) :
dimulai. kesepakatan penyedia
layanan TI dan
pelanggan (eksternal).
Berisi informasi tentang
layanan TI, dokumentasi
target tingkat layanan,
dan tanggung jawab
antara penyedia layanan
TI dan pelanggan.  

e.      Major Incident, Timescale, dan Incident Model

Major Incident ialah  Kategori tertinggi sebuah incident, yang memiliki karakteristik :
a.      Incident yang memiliki dampak besar pada bisnis,
b.      Memiliki urgensi tinggi,
c.       Penyebab telah diketahui tetapi belum ada panduan solusi atau workaround.
Perusahaan harus mendefinisikan indikator major incident (misal jika kejadian berdampak
pada minimal 5.000 pengguna) dan membuat prosedur penangan khususnya, baik dalam hal
timescale (umumnya timescale lebih pendek) maupun staf yang menanganinya. Seringkali
beberapa incident yang memiliki prioritas rendah namun berdampak tinggi bagi perusahaan
menggunakan major incidents ini.
Timescale  ialah  Target waktu respon dan penyelesaian sebuah incident sesuai yang ditulis
di dokumen SLA.
 Incident Model  adalah sebuah prosedur standar aktivitas dan timescale telah ditetapkan
sebelumnya) yang dibuat untuk menangani incident “standar” atau “special”.
Informasi yang harus ada dalam incident model mencakup :
a.      Tindakan-tindakan yang harus diambil untuk menangani incident,
b.      Urutan tindakan,
c.       Penanggung-jawab,
d.      Timescales,
e.      Prosedur eskalasi.
f.        Workaround, Known Error,  dan  Known Error Database (KEDB)
Workaround :  tindakan standar (terdokumentasi) untuk mengurangi dampak buruk dari
sebuah incident atau problem yang belum diketahui solusi tuntasnya.
Known Error :  sebuah masalah (problem) yang telah diketahui dan terdokumentasi akar
masalahnya, gejala-gejala incident-incident yang terkait, solusi standarnya atau langkah
meminimalisasi dampak buruknya apabila solusi totalnya belum diketahui (workaround-nya).
Known Error Database (KEDB)  : basis data known error yang akan digunakan oleh service
desk dan staff pendukung lainnya untuk melakukan incident management dan workaround. 
g.      Escalation
Adalah tindakan meneruskan laporan dan penanganan incident yang belum terselesaikan ke
function lain di perusahaan untuk memperoleh dukungan lebih lanjut.
Ada 2 macam eskalasi :
1)      Functional escalation : meneruskan penanganan sebuah incident ke tim pendukung atau
second level support.
2)      Hierarchical escalation : meneruskan/mengkomunikasikan  informasi incident yang belum
terselesaikan ke manajemen bisnis diatasnya (seperti manajer) untuk dicari solusinya.  
h.      Service Request, Request Model,  dan  Self-Help Technology
Service Request   : yakni permintaan pengguna tentang informasi tertentu, pertanyan atau
permintaan saran, perubahan yang bersifat standar (standard change), atau akses ke suatu
layanan TI. Permintaan layananan ini umumnya ditangani oleh service desk* tanpa perlu
membuat/mengirimkan RFC.
*service desk (help desk, support desk,  atau IT service center)  adalah sebuah unit
(function)  dalam organisasi yang berfungsi sebagai gerbang komunikasi (single point of
contact atau SPOC) antara penyedia layanan dengan pengguna.  
Request Model :  yakni standar prosedur (SOP) untuk menangani tipe-tipe permintaan tertentu
yang rutin terjadi.
Self-Help Technology :  teknologi berbasis web yang membantu permintaan pengguna.
Umumnya dalam bentuk formulir online yang mengharuskan pengguna untuk login ke sistem
terlebih dahulu.
i.        Access Request, Identity, Privileges
Access Request :  permintaan akses layanan, dapat berupa permintaan layanan standar atau
RFC.
Identity :  yakni informasi unik dari setiap pengguna, yang menjelaskan status pengguna
didalam organisasi dan sekaligus menentukan hak akses dia terhadap sistem layanan TI.
Contoh : sidik jari.
Privileges :  yakni hak akses seseorang/grup pengguna ke satu/kelompok layanan IT.
Misalnya : sistem kepegawaian hanya bagian HRD sebagai administratornya, sedangkan
bagian keuangan hanya mengelola penggajian dari kinerja atau tingkat kehadiran seluruh
karyawan.
B.      Proses
a.      Event Management
Event Management  dasar untuk memantau kinerja dan ketersediaan layanan, tepat sasaran
dan mekanisme untuk memantau apa yang harus ditentukan dan disepakati selama proses
ketersediaan dan Kapasitas manajemen berlangsung.
Event Management tools  ialah sebuah aplikasi yang mengautomatisasi aktivitas-aktivitas
dalam Event Management.
Tujuan Event Management  ialah mengelola event,  yang mencakup :
1)      Mendteksi Event  (“Apa yang terjadi?”)
2)      Menganalisis Event :  mengklasifikasikan jenis Event,  penting/tidak?  (“Apa artinya?”)
3)      Menentukan tindakan yang paling tepat dan sesuai dengan Event  yang sedang terjadi
tersebut : mencatatnya/log, mengabaikannya, menyampaikan peringatan kepada orang lain,
atau menindaklanjuti dengan tindakan Incident Management,  Problem Management, atau
Change Management  (“Apa yang harusdilakukan?”)
Aktivitas-aktivitas pada Event Management :
1)      Event Notification,  Event Detection,  Event Logging
Event Notification :  aktivitas menentukan “pesan” apa yang kita ingin hasilkan dan informasi
apa yang terdapat didalan pesan tersebut.
Event Detection  :  menentukan jenis notifikasi mana yang ingin dideteksi dan dikenali
oleh tools,  dan menentukan apakah event  akan di catat di log/tidak dan bagaimana
pencatatannya.
Event Logging :  mencatat data di dalam tools  yang mendeteksi event  tersebut atau
menghasilkan rekaman event   dalam event-logging tool  tertentu. 
2)      Event Filtered,  Event Correlation
Event Filtered :   aktivitas yang mengklasifikasi sebuah Event  sebagai sebuah informasi,
peringatan atau ketidakwajaran dan memutuskan tindakan apa yang akan diambil
dari event  tersebut.  
Event Correlation :  mengambil kesimpulan dari event  yang terjadi berulang-ulang sehingga
dipahami dampak akumulasinya.
3)      Response selection :  menentukan jenis respon untuk setiap kemungkinan event,  yaitu :
a)      Auto Response :  mengatur sebuah peralatan melakukan respon otomatis
tertentu khusus untuk sebuah event.
b)      Alert :  sistem akan secara otomatis menghasilkan dan mengirimkan informasi peringatan
untuk menarik perhatian.
c)      Incident, Problem, Change :  sistem mampu secara otomatis menghasilkan
laporan/permintaan untuk proses Incident Management,  Problem Management, atau Change
Management  sesuai kriteria-kriteria tersebut. Namun, untuk melaksanakan proses ini, perlu
persetujuan dari manajemen.      
4)      Review Action, Close Event :   me-review penanganan sebuah event perlu dilakukan untuk
memastikan bahwa langkah yang tepat telah diambil. Jika review penanganan tersebut
sudah tepat, maka aktivitas event dapat dikatakan selesai/ditutup. Contoh : event-event
informasi otomatis selesai manakala telah tercatat (ter-log).  
b.      Incident Management :  mengembalikan layanan yang bermasalah agar berfungsi seperti
sedia kala.
Aktivitas-aktivitas pada incident management :
1)      identifikasi incident dan logging : aktivitas menemukan/mengenali sebuah incident.
2)      kategorisasi incident : incident yang dicatat selanjutnya dikategorisasikan dnegan kode
kategori incident.
3)      Prioritisasi incident : menentukan prioritas penanganan sebuah incident yang telah dicatat
dan dikategorisasi, secara teknis dengan memberi kode prioritas incident.
Priority Description Target Resolution Time
code
1 Critical 1 hour
2 High 8 hour
3 Medium 24 hour
4 Low 48 hour
5 Planning Planned
4)      Diagnosis Awal : service Desk akan berupaya untuk menyelesaikan  incident  terlebih dahulu
sebelum diteruskan kepada tim teknis.
5)      Investigasi dan diagnosis : penyelesaian masalah dan pemulihan kondisi layanan (resolution and
recovery), tindakan pengembalian layanan harus dipastikan benar-benar tuntas dan catatan
incident harus di update.
6)      Penutupan incident : setelah incident diatasi, staf service desk harus menginformasikan kepada
pengguna bahwa masalah telah teratasi dan memastikan pengguna puas dengan penanganan
(misalnya dengan survei) dan setuju laporan incident ditutup.
c.       Problem Management  :  yakni proses menganalisis dan myelesaikan akar penyebab incident.
Reactive Problem Management :  tindakan mencari akar permasalahan dan menyelesaikan
dipicu oleh sebuah/lebih kejadian (atau sebagai reaksi dari) incident.
Proactive Problem Management : tindakan mencari dan menyelesaikan akar sebuah masalah
tanpa menunggu incident terjadi.
Aktivitas-aktivitas  dalam problem management mirip dengan aktivitas dari incident
management, yang biasanya dilakukan secara periodik/terjadwal (misal sebulan sekali atau
tiga bulan sekali).
Langkah-langkah problem management :
a)      Problem detection and problem logging : diawali dengan aktivitas mengenali (detection) dan
mencatat penyebab masalah (problem).
b)     Problem categorization and prioritization : setiap problem dikategorisasi dan ditentukan
dengan prioritasnya.
c)      Problem investigation and diagnosis : tim teknis dapat juga bekerja sama dengan supplier,
melakukan sebuah investigasi menemukan akar permasalahan layanan TI tertentu dan
pilihan-pilihan solusinya.
d)     Mencatat sebuah known error dan disimpan ke known error database (KEDB).
e)      Problem resolution : berdasarkan hasil problem investigation and diagnosis, selanjutnya
pilihan solusi atau workaround diaplikasikan untuk menyelesaikan problem.
f)       Problem closure : ketika sebuah permasalahan telah selesai diatasi dan catatan known error
juga telah dibuat, lalu diberistatus selesai dan ditutup.
g)      Major problem reviews : khusus untuk permasalahan-permasalahan yang memiliki dampak
besar bagi bisnis.
d.      Request Fulfillment  :  yakni proses memenuhi permintaan pengguna layanan TI, diluar
laporan terkaitdengan incident TI.
Service desk  bertugas memilah panggilan/laporan yang masuk apakah sebagai sebuah
laporan incident, permintaan akses, atau permintaan lainnya.

Aktivitas-aktivitas dalam request fulfillment
1)      Receive, request, request logging dan validation.
2)      Request categorization, request prioritization
3)      Request authorization
4)      Request review, request model execution
5)      Request closure
e.      Access Management  :  yakni proses pengelolaan hak akses pengguna ke sistem layanan TI.
Aktivitas-aktivitas dalam access management :
1)      Permintaan akses
2)      Verifikasi
3)      Menyediakan hak akses
4)      Memonitor status identitas, mencabut,membatasi hak akses

5)      Pencatatan dan penelusuran aktivitas akses.

 

Sumber :
Susanto, Tony.D.2016.Manajemen Layanan Teknologi Informasi.Surabaya;Asosiasi Sistem
Informasi Indonesia (AISINDO)