My Articles‎ > ‎

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
Comments