Service Level Management adalah salah satu elemen dari service delivery.
Service delivery adalah pelaksanaan dari disiplin-disiplin dalam framework of ITIL, sehingga layanan bisnis-IT dapat berjalan.
Tujuan utama dari Service Level Management adalah :
untuk menjaga dan memperbaiki kualitas pelayanan, dan mengetahui apa yang sebenarnya diinginkan oleh user.
Oleh karena itu hubungan yang baik antara IT Services Provider dan customers/Users harus dijaga.
Dalam Service Level Management terdapat beberapa proses, yaitu:
Perjanjian tingkat operasional (Operational level agreement / OLA) adalah kontrak yang menentukan bagaimana berbagai kelompok TI dalam perusahaan berencana memberikan layanan atau rangkaian layanan.
OLA dirancang untuk mengatasi dan memecahkan masalah TI dengan menetapkan seperangkat kriteria tertentu dan menentukan rangkaian layanan TI tertentu yang masing-masing departemen bertanggung jawab.
Service Level Agreement ( SLA ) digunakan di banyak perusahaan saat mendiskusikan kesepakatan antara dua kelompok internal, namun menurut kerangka Teknologi Informasi Infrastruktur Informasi ( ITIL ) untuk praktik terbaik jenis kontrak internal yang sesuai adalah sebuah Perjanjian Tingkat Operasional (OLA).
Perjanjian tingkat operasional ( OLA ) mengartikan hubungan saling membutuhkan dalam mendukung perjanjian tingkat layanan (SLA).Kesepakatan tersebut menggambarkan tanggung jawab masing-masing kelompok pendukung internal terhadap kelompok pendukung lainnya, termasuk proses dan kerangka waktu untuk penyampaian layanan mereka.
Perjanjian Tingkat Operasional (OLA) antara penyedia layanan untuk menyimpan hubungan kerja dan waktu respons (response time) serta Solutions Time untuk mendukung nama layanan dari katalog layanan atau di tempat lain. OLA ini tetap berlaku sampai direvisi atau dihentikan.
Meskipun komponen dari IT Infrastructure Library (ITIL) , OLA dapat diimplementasikan secara standalone. OLA (Operational Level Agreement) merupakan bentuk persetujuan antara sesama IT provider.OLA kadang diperluas ke frase lain tapi semuanya memiliki arti yang sama: Kesepakatan tingkat organisasi , Perjanjian tingkat operasi, OLA bukan pengganti SLA. OLA harus dilihat sebagai dasar praktik yang baik dan kesepakatan bersama. Jika OLA tidak ada, maka sangat sulit bagi organisasi untuk kembali dan memberi persetujuan insinyur antara tim pendukung untuk mengirimkan SLA.
Adapun tujuan-tujuan dari OLA adalah sebagai berikut :
Layanan OLA ini merupakan elemen penting dari layanan service_name berfungsi sebagai dokumen yang masing-masing layanan ini memiliki OLA. (Jika OLA ada, link akan diberikan. Jika OLA tidak ada, unit yang terdaftar adalah unit utama Anda untuk menghubungi). Ini beberapa layanan OLA, yaitu :
Penyedia Layanan berikut dikaitkan dengan OLA ini:
Operasi Pusat Data setuju untuk memberikan dukungan di luar jam kerja yang mencakup beberapa hal, yaitu:
Manajemen insiden dan Permintaan Layanan Pengolahan Operasional dimana bagian ini memvalidasi proses yang didukung untuk mengelola pengiriman layanan. Pengecualian juga didokumentasikan. Permintaan layanan Permintaan Pekerjaan (jika ada) / Permintaan Layanan Standar Permintaan kerja sebagaimana didefinisikan oleh Layanan Media atau Telco. Permintaan layanan yang terkait dengan layanan ini contohnya bisa berupa upgrade aplikasi, patch OS, perubahan arsitektur, konsultasi tentang penggunaan layanan, pengaturan daftar email, dll.
Permintaan Layanan Non-standar / Permintaan Kerja Ad-hoc merupakan pekerjaan satu kali atau waktu terbatas yang tidak didokumentasikan dalam katalog layanan.
Contohnya termasuk pemasangan WAP di kelas selama seperempat, di install di sana setelahnya. Atau pulihkan email untuk Kanselir tapi tidak untuk pelajar. Inti dari hal ini adalah untuk memberi tahu staf ITS tentang jenis penyedia layanan satu kali yang dapat diberikan untuk membantu memenuhi harapan klien. Permintaan layanan non-standar atau permintaan kerja ad-hoc diproses agar dievaluasi oleh anggota staf atau tim layanan yang paling tepat.
Permintaan perubahan layanan dapat dikirim ke Service Manager. Tim layanan akan meninjau permintaan untuk memahami kebutuhan dan menggembalakannya melalui saluran yang sesuai. Proses Insiden Normal Karena teks ini menjadi standar, lihat prosedur eskalasi yang ada di Katalog Layanan Internal untuk detail lebih lanjut tentang bagaimana insiden dan permintaan layanan diproses dan meningkat.
Penyedia layanan yang mendukung layanan ini akan memprioritaskan insiden layanan masuk sebagai prioritas rendah, sedang atau tinggi kecuali jika kejadian layanan sesuai dengan satu atau lebih kriteria yang tercantum di bawah ini. Penyedia layanan yang mendukung layanan ini akan memprioritaskan permintaan insiden masuk sebagai kejadian mendesak jika memenuhi salah satu dari kriteria berikut:
Perjanjian ini harus ditinjau sekurang-kurangnya satu kali per tahun. Namun, sebagai pengganti sebuah tinjauan selama periode yang ditentukan, Perjanjian saat ini akan tetap berlaku. Layanan TI bertanggung jawab untuk memfasilitasi tinjauan reguler dokumen ini. Isi dokumen ini dapat diubah sesuai kebutuhan, asalkan kesepakatan bersama diperoleh dari pemangku kepentingan utama dan dikomunikasikan kepada semua pihak yang terkena dampak. Layanan TI akan menggabungkan semua revisi berikutnya dan mendapatkan persetujuan / persetujuan bersama sesuai kebutuhan. Metrik yang dipantau secara internal untuk layanan ini di bagi menjadi 5.
Penerbitan Perjanjian Tingkat Operasional Setelah membuat perjanjian tingkat operasional, Anda harus mempublikasikannya agar diberlakukan.
Membuat Perjanjian Tingkat Operasional Usang Perjanjian tingkat operasional secara otomatis diatur ke status usang saat tanggal akhir terjadi. Namun, Anda bisa menetapkan secara prematur perjanjian tingkat operasional agar usang sesuai kebutuhan. Kesepakatan tingkat operasional usang tidak lagi dipertimbangkan dalam aturan bisnis paket layanan S.
OLA mendefinisikan bagaimana berbagai kelompok TI, baik antar atau intracompany, berencana untuk memberikan layanan atau rangkaian layanan kepada pelanggan mereka, menurut analis Yankee Group Research Inc. Laura DiDio. OLA, DiDio mengatakan,dirancang untuk mengatasi dan memecahkan masalah pada TI dengan menetapkan seperangkat kriteria tertentu dan menentukan rangkaian layanan TI tertentu yang masing-masing departemen bertanggung jawab.
PRO + Konten : Temukan lebih banyak konten
PRO + dan penawaran anggota lainnya saja,
E-Zine : AR, teknologi VR siap merevolusi manajemen bisnis digital.
E-Zine : RPA: Memetakan rencana otomasi perusahaan
OLA dirancang untuk mengatasi dan memecahkan masalah TI dengan menetapkan seperangkat kriteria tertentu dan menentukan rangkaian layanan TI tertentu yang masing-masing departemen bertanggung jawab. OLA yang efektif terbagi dari beberapa ciri utama. yaitu:
Misalnya, pengiriman dan dukungan email ke organisasi, layanan yang melibatkan berbagai kelompok TI, termasuk grup data center yang mengawasi server email, grup dukungan desktop yang menangani masalah klien dan grup jaringan yang mengelola jaringan Layanan email berjalan OLA untuk layanan email akan mengidentifikasi kelompok-kelompok ini, menjelaskan tanggung jawab masing-masing dan menetapkan kerangka waktu untuk menyelesaikan berbagai masalah.
Yang terpenting, kata DiDio, sebuah OLA harus dirinci. Ini adalah rencana permainan yang sangat spesifik, sangat jelas dan sangat teknis, katanya.
Template OLA sederhana memecahkan masalah serius Ketika operasi help desk mulai menderita pada pertengahan tahun 2006, perselisihan antara kelompok TI menjadi umum di Dana Moneter Internasional yang berbasis di Washington, DC. Pada saat itu, pemberi pinjaman yang disponsori pemerintah meng-outsource tanggung jawab di satu tier-one help desk. Vendor tersebut diharapkan menangani mayoritas, hingga 80%, dari panggilan telepon bantuan – hal-hal sederhana seperti mengambil kata kunci yang hilang dan menyiapkan voicemail – dan hanya meneruskan masalah paling sulit ke departemen internal TI IMF.
Tetapi beberapa di departemen TI merasa bahwa agen outsourcing tersebut merujuk terlalu banyak masalah ke kantor pusat, mengabaikan tanggung jawabnya dan menyebabkan penundaan yang tidak dibutuhkan dalam waktu penyelesaian. Entah masalah itu nyata atau dirasakan, operasi meja bantuan perlu disederhanakan dan Manajer Layanan IMF Chris Edler memutuskan untuk menerapkan OLA adalah cara terbaik untuk melakukannya.
“Saya membuat template OLA yang benar-benar sederhana,” kata Edler. “Pada dasarnya, siapa, bagaimana, kapan, di mana, bagaimana, Kami melewati setiap pertanyaan ini dan kami menentukan siapa pemainnya, jam operasi apa dari organisasinya, bagaimana dan pengobatan mana yang akan kami gunakan.”
Edler, yang meninggalkan IMF awal tahun ini dan sekarang menjadi kepala sekolah praktik di Hewlett-Packard Co., mengatakan bahwa dia juga menetapkan perkiraan waktu resolusi, dan memasukkan “tombol keluar nol” di OLA yang ditentukan ketika sebuah isu telah sampai pada Buntu dan memang perlu eskalasi ke otoritas yang lebih tinggi, baik itu manajer TI atau bahkan CIO.
“Dalam proses menciptakan OLA, banyak cucian kotor terekspos. Banyak jari yang menunjuk, banyak pushback, jadi harus ada wasit,” kata Edler. “Dan benar-benar, siapa wasit bagi organisasi individu? Ini adalah CIO atau seseorang yang ditunjuk oleh CIO.”
Meskipun Edler meninggalkan IMF sesaat setelah menerapkan help desk OLA, dia berkata, “Apa yang dilakukannya lakukan adalah memulai dialog antara kelompok pendukung yang berbeda, yang memecahkan masalah secara dramatis.”
Unsur manusia dan tantangan OLA lainnya
Yankee Group DiDio sepakat bahwa tantangan utama untuk menerapkan OLA adalah berurusan dengan kepribadian yang terlibat, dan terserah kepada CIO untuk mengatur nada. Setiap kelompok menganggap ini sebagai pemain yang paling penting, katanya, jadi CIO “harus semacam totaliter tentang hal itu” agar masing-masing kelompok membeli OLA. “Anda harus memberitahu orang-orang untuk memeriksa ego mereka di depan pintu.” Lebih banyak tentang TI dan bisnis Relationship management merupakan bagian penting dari IT, keselarasan bisnis Pendekatan praktis untuk menerapkan praktik ITIL.
Contoh template OLA
DiDio juga merekomendasikan agar CIO “menguji, menguji dan menguji ulang” OLA mereka dan melakukan penyesuaian bila diperlukan. Dia menekankan bahwa OLA harus memiliki tanggal mulai, tengah dan akhir. “OLAs terbaik akan berkembang seiring dengan kebutuhan bisnis” dan teknologi yang terlibat, katanya.
Pada akhirnya, OLA yang sukses adalah strategi yang meningkatkan komunikasi antar kelompok TI, dengan jelas menjabarkan tanggung jawab dan harapan masing-masing kelompok, dan menghasilkan keberhasilan pengiriman layanan TI. Merancang dan menerapkan OLA “memakan waktu, ini menantang,” kata DiDio, “tapi jika Anda menjalani latihan ini, sangat membantu.”
APA ITU SLA?
SLA singkatan dari Service Level Agreement (Perjanjian Tingkat Layanan). SLA (Service Level Agreement) merupakan bentuk persetujuan antara business customer dengan IT provider. Pengertian SLA adalah bagian dari perjanjian layanan secara keseluruhan antara 2 dua entitas untuk peningkatan kinerja atau waktu pengiriman harus di perbaiki selama masa kontrak kerjasama. Dua entitas tersebut biasanya dikenal sebagai penyedia layanan dan klien, dan dapat melibatkan perjanjian secara hukum karena melibatkan uang, atau kontrak lebih informal antara unit-unit bisnis internal. misalkan : Waktu DownTime antara Internet Service Provider dengan Perusahaan Dagang yang. Dengan adanya SLA diharapkan Pelayanan Pihak Kedua (Penyedia Jasa) akan menunjang Produktivitas Pihak Pertama sehingga mampu menjaga Kepuasaan Nasabahnya.
SLA biasanya terdiri dari beberapa bagian yang mendefinisikan tanggung jawab berbagai pihak, dimana layanan tersebut bekerja dan memberikan garansi, dimana jaminan tersebut bagian dari SLA memiliki tingkat harapan yang disepakati, tetapi dalam SLA mungkin terdapat tingkat ketersediaan, kemudahan layanan, kinerja, operasi atau tingkat spesifikasi untuk layanan itu sendiri. Selain itu, Perjanjian Tingkat Layanan akan menentukan target yang ideal, serta minimum yang dapat diterima.
Adakalanya pula SLA diterapkan di Internal Perusahaan melalui 2 Divisi yang berbeda, contohnya : Divisi IT dengan Divisi Marketing, dimana Marketing adalah Pihak Pertama sebagai Pemilik Proyek dan IT adalah Pihak Kedua sebagai Penyedia Proyek. Dapat kita simpulkan bahwa SLA dominan dipakai bagi Perusahaan atau Divisi.
Mengapa diperlukan SLA?
Dari definisi SLA di atas, terdapat dua pihak yang berkepentingan, yaitu pihak penyedia (supplier) dan pihak pelanggan (costumer). Tentunya keduanya memiliki harapan masing-masing yang bisa saja berbeda. Harapan pelanggan menginginkan produk/layanan tersedia dengan cepat, namun dari pihak penyedia memerlukan waktu proses untuk menyediakan produk/layanan yang dibutuhkan tersebut. Perbedaan harapan inilah yang perlu dikomunikasikan agar tidak terjadi konflik.
Disinilah diperlukan SLA untuk menjembatani perbedaan harapan, mendefinisikan kewenangan dan tanggung jawab masing-masing pihak sekaligus menjadi alat ukur efektifitas penyediaan produk/layanan oleh supplier.
SLA dibutuhkan jika dilihat dari sisi Penyedia layanan adalah sebagai jaminan atas serviceyang diberikan kepada klien, sehingga klien tersebut bisa puas atas layanan yang diberikan,dampak lain yang akan muncul dari sisi penyedia layanana adalah konsep pemasaran tradisional yaitu pemasaran dari mulut ke mulut , maksudnya adalah klien akan memberikanrekomendasi kepada temannya/ rekan lainnya bahwa layanan yang diberikan oleh penyedia tersebut bagus, sehingga berharap teman/ rekan lainnya mau berlangganan kepada provider/penyedia layanan tersebut
Dari sisi Klien adalah menjamin aspek ketersedian (availability) informasi (kalau kita mengacu kepada konsep informasi yang berkualias, adalah mengacu kepada availability, accurate, Update). Sehingga pihak klien merasa terbantu dengan ketersediaan layanan yang diberikan oleh pihak provider, sehingga proses pengelolaan data/ informasi dengan pihak- pihak terkait (customer/ vendor) berjalan lancar & tidak terganggu karena layanan itu mati, bisa dibayangkan jika klien tersebut adalah sebuah institusi perbankan (dimana layanan yang dibutuhkan adalah 24 jam , dengan kata lain layanan internet nya tidak boleh down (mati), dan bisa dibayangkan juga jika layanan dari perbankan itu down (mati), akibatnya dari aspek pemasaran nasabahnya dari bank tersebut tidak akan percaya , sehingga dampak yang paling tragis adalah nasabah tersebut akan berpindah kepada layanan dari bank lain, begitu pula layanan-layanan lainnya seperti Perguruan tinggi, yang nantinya akan berdampak kepada image yang kurang baik dari perguruan tinggi tersebut.
Aplikasi Bisnis
Dengan mengetahui hal itu, diharapkan tingkat pelayanan dan juga tingkat minimum, pelanggan dapat menggunakan layanan dengan maksimal. Hal ini juga sangat membantu jika klien adalah perantara, yang menjual kembali atau bundling dengan pelayanan yang lebih besar yang sedang dijual. SLA telah digunakan sejak awal 1980-an oleh perusahaan telepon dengan pelanggan dan reseller yang lebih besar perusahaannya dengan pelayanan mereka. Konsep “tertangkap” dari bisnis unit dan usaha lainnya dalam perusahaan besar mulai menggunakan istilah dan pengaturan yang ideal dalam awal kontrak layanan telekomunikasi. Ide menciptakan sebuah layanan yang lebih besar dari layanan yang lebih kecil hampir membutuhkan SLA dari penyedia jasa. Misalnya, untuk memiliki cakupan ponsel nasional, Anda tidak perlu untuk membangun menara dan antena di seluruh kota. Sebaliknya, Anda bisa menemukan perusahaan lokal dan daerah yang menawarkan layanan yang sama, menulis tentang SLA dan mengukur hasilnya. Untuk pelanggan anda, anda akan menawarkan SLA yang sama. Dalam SLA asli tidak memerlukan perusahaan dari mana anda membeli, dan anda dapat mengontrol biaya anda, ketika pelanggan mematuhi SLA yang anda buat dengan mereka. Hal ini memberikan kemampuan bagi Perusahaan untuk menggunakan banyak sub kontraktor untuk menyediakan pelayanan yang lebih besar, namun mengendalikan biaya dan sumber daya untuk menawarkan produk yang lebih besar.
Kekhawatiran akan kemungkinan korupsi. Bila menggunakan cita-cita yang ditetapkan dalam manajemen layanan TI, menerapkan metrik untuk proses dan menjamin waktu pengiriman sangat baik untuk manajemen produk manufaktur. Tetapi ketika Anda menerapkan metodologi ini ke call center, pengkodean, atau sistem desain, kehandalan dan kreativitas menghilang dan untuk kembali dalam rangka memenuhi SLA, sehingga perusahaan tidak lagi memberikan pelayanan terbaik kepada pelanggan pada akhirnya.
Penggunaan SLA telah menyebar luas dengan penggunaan layanan manajemen TI dasar seperti SMF atau ITIL. Penggunaan umum dalam manajemen layanan TI adalah sebagai call center. Pengukuran dalam kasus-kasus ini biasanya diidentifikasi sebagai:
Hasil ini dicatat dan dimonitor untuk memberikan masukan kepada manajemen untuk efisiensi dan kegunaan dari personil call center dan untuk membantu mengindikasikan di mana pelatihan atau sumber daya yang lebih diperlukan.
Beberapa waktu yang lalu penulis mendapat kesempatan untuk mengikuti Diklat Service Level Agreement (SLA) yang diselenggarakan oleh Pusdiklat Keuangan Umum Kementerian Keuangan Republik Indonesia. Nara sumber yang menyampaikan materi dari Mandiri University. Penerapan SLA penting bagi Pusdiklat Pajak maka penulis tergerak untuk sharing knowledge terkait materi tersebut.
Penggunaan SLA tidak terbatas pada dunia IT atau telekomunikasi – mereka juga digunakan untuk real estate, medis dan bidang apapun yang menyediakan produk atau layanan kepada pelanggan.Layanan berorientasi manusia dan bisnis memiliki kebutuhan untuk mengukur dan memikul tanggung jawab, dan SLA menyediakan pengukuran dan ide bagi entitas untuk menyepakati.
Apa saja permasalahan yang ada di SLA?
Bagaimana membuat SLA?
Sebelum membuat SLA, terlebih dahulu harus dipahami dahulu tentang unsur- unsur yang terkait SLA yaitu Supplier, Input, Proses, Output, dan Costumer (SIPOC). Adapun penjelasannya adalah sebagai berikut:
Pembuatan atau penentuan SLA sebaiknya melibatkan seluruh pihak terkait dalam suatu organisasi, agar diperoleh kesepakatan bersama. Pembuatan SLA ini melalui beberapa tahapan sebagai berikut :
Menurut Utomo (2008) Untuk dapat membuat perjanjian service level yang mampu menjembatani kebutuhan bisnis, diperlukan langkah-langkah sebagai berikut :
Unit bisnis harus mampu memetakan kritikalisasi dari beragam produk dan layanannya, paling tidak menjadi 3 kategori penting, yaitu :critical, medium dan low priority. Dari sudut pandang TI, informasi ini sangat penting untuk beberapa alasan :
Setelah kategorisasi dilakukan, langkah berikutnya adalah melakukan kesepakatan kinerja layanan antara departemen TI dan unit bisnis, yaitu menyangkut availability dan performance untuk masing-masing kategori. Beberapa contoh parameter yang harus disepakati antara lain :
Setelah kedua belah pihak mengetahui parameter-parameter kinerja yang akan dicapai, maka parameter tersebut harus dituangkan dalam kontrak perjanjian service level. SLA yang dihasilkan harus dapat memenuhi kepentingan dan prioritas bisnis.
Tujuan dari pembuatan service model ini adalah untuk memberikan gambaran yang lengkap tentang interkorelasi antara produk/layanan bisnis dengan infrastruktur/ sistem TI yang melayaninya. Model ini mendefinisikan IT resources mana yang kritikal untuk menjamin kelangsungan operasi layanan bisnis. Bagi departemen TI, ketersediaan model ini sangat penting untuk melakukan service impact analysis, yaitu analisis pengaruh kegagalan satu komponen terhadap keseluruhan layanan sistem. Dengan menghubungkan model tersebut ke dalam komponen-komponen TI dan menyimpannya ke dalam tools configuration management dan asset anagement yang terpusat, setiap perubahan dapat dijejaki dan dianalisis pengaruhnya terhadap keseluruhan sistem.
Dibeberapa perusahaan, mekanisme kontrol ini dilakukan dengan membentuk quality committee, yang secara rutin mengadakan quality meeting untuk membahas pencapaian kinerja dan rencana perbaikan sistem. Quality Committee ini harus dikendalikan oleh senior manajemen guna mendapatkan kekuatan komitmen dari seluruh pihak yang terlibat. Dengan menerapkan prinsip-prinsip dan langkah-langkah tersebut di atas, diharapkan bisa didapatkan harmonisasi operasional departemen TI dengan unit bisnis, dimana keduanya akan dapat berkomunikasi dalam bahasa dan protokol yang sama.
Bagaimana strategi menjaga loyalitas pelanggan dengan SLA?
SLA (Service Level Agreement) merupakan kesepakatan antara penyedia jasa dan pengguna jasa mengenai tingkat/mutu layanan. SLA merupakan komponen kunci dari keseluruhan SLM (Service Level Management) suatu organisasi TI. Suatu SLA yang bagus sekaligus dapat berfungsi sebagai sarana komunikasi yang baik pula bagi perusahaan dalam menangani harapan masing-masing pihak. Dilihat dari defenisinya, SLA lebih merupakan suatu kesepakatan, bukan suatu kontrak. Baik dari pihak bagian TI yang menjalankan pelayanan bagi pelanggan internal seperti untuk bagian personalia, maupun sebagai konsultan yang menawarkan jasa TI kepada para pelanggan. SLA dapat dibuat dalam berbagai macam konteks. SLA perusahaan (Enterprise SLA) adalah suatu kesepakatan antara penyedia jasa dengan semua pelanggan dari keseluruhan organisasi. Sedangkan SLA pelanggan (Customer SLA) merupakan suatu kesepakatan antara penyedia jasa dengan sekelompok pelanggan tertentu dari organisasi tersebut. SLA layanan (Service SLA) dapat dipahami sebagai suatu kesepakatan antara penyedia jasa dan para pelanggan dari suatu jasa tertentu. Beberapa alasan yang cukup penting dalam pembangunan suatu kesepakatan tertuang dalam SLA, misalnya antara konsultan TI dengan para pelanggannya, mencakup :
Dengan demikian, apapun jenis SLA yang akan dikembangkan, harus mencakup lima bagian penting, yaitu deskripsi pelayanan, standarisasi pelayanan, durasi, peran dan tanggungjawab, dan kriteria evaluasi.
Bagaimana menghitung SLA?
Cara menghitung SLA, tergantung dari layanan yang diberikan , sebagai contoh yang saya ketahui beberapa provider IT khususnya provider / penyedia layanan internet memberikan SLA antara 96% – 99%, artinya dalam 1 bulan pihak provider menjamin bahwa layanan yang diberikan adalah :
Menghitung SLA (asumsi dengan SLA 98%, artinya layanan standard mereka 98% dalam 1 bulan, dan 2% dianggap wajar jika terjadi mati (down) dalam layanan tersebut)
1 hari = 24 jam
1 bulan = 30 hari
Biaya bulanan Internet = Rp. 1.000.000
Pengertian Restitusi dan Bagaimana menghitung Restitusi
Restitusi adalah pengembalian dalam bentuk (bisa dalam bentuk pembayaran (uang), ataupun lainnya (tergantung kontrak) dari pihak penyedia layanan kepada klien. Sebagai contoh (dengan mengambil lanjutan perhitungan diatas), jika klien mempunyai kewajiban membayar Rp. 1.000.000 :
Nah 21,3 % itu adalah hak kita u/ mendapatkan penggantian, penggantian ini biasanya dalam bentuk pengurangan pembayaran:
= Rp1.000.000 – Rp. 217.345
= Rp. 782.654
Artinya dalam bulan ini kita hanya punya kewajiban membayar sekitar Rp. 782.654. Jika kita mendapatkan masalah terkait layanan yang diberikan oleh provider, maka jangan lupa minta nomor tiketnya, karena nomor tiket tersebut sebagai dasar perhitungan SLA, dengan kata lain Argo perhitungan SLA nya sudah mulai jalan sejak kita minta nomor tiket. Membuat SLA bersama pelanggan akan memberikan suatu pengertian yang lebih baik mengenai bisnis pelanggan anda. Begitu juga dampak layanan TI terhadap pelanggan dan kemampuan dalam menjalankan berbagai proses bisnis, sehingga akhirnya membentuk hubungan yang lebih baik. Pada intinya SLA itu bagus dan dapat menunjukkan kepercayaan diri providernya tapi jangan dijadikan acuan utama. Karena apabila pas down maka kita sendiri tidak mendapatkan ganti rugi yang sebanding. Dan biasakan melakukan backup rutin agar pas terdeteksi adanya masalah bisa langsung pindah ke provider lain, baik sementara atau permanen.
Contoh Penerapan SLA
Sebagai analogi, misalnya Widyaiswara memerlukan Jadwal Tatap Muka selama satu bulan dari Bidang Penyelenggaraan karena Widyaiswara membutuhkan waktu persiapan untuk membuat atau menyempurnakan Bahan Ajar, Bahan Tayang dan Soal. Yang menjadi Supplier adalah Bidang Perencanaan dan Pengembangan (Renbang) dengan input berupa Rekomendasi Pengajar.
Selanjutnya terdapat proses menyusun jadwal selama satu bulan dan mengkonfirmasikannya dengan pengajar. Output yang dihasilkan dari proses ini adalah Jadwal Tatap Muka Satu Bulan sebagaimana permintaan Widyaiswara sebagai Costumernya. Untuk memenuhi permintaan Widyaiswara tersebut, Bidang Penyelenggaraan membutuhkan input dari Bidang Renbang berupa Rekomendasi Pengajar, dengan harapan dapat diterima dalam jangka waktu tertentu. Di sisis lain, Bidang Renbang pun membutuhkan input lain dan waktu proses untuk membuatnya.
Hal inilah yang mengakibatkan harapan Widyaiswara untuk mendapatkan Jadwal Tatap Muka Satu Bulan dalam jangka waktu tertentu belum tentu dapat dipenuhi oleh Bidang Penyelenggaraan karena terkait juga dengan beberapa proses di bidang-bidang lainnya.
Nah, waktu proses untuk menghasilkan Jadwal Tatap Muka Satu Bulan inilah yang nantinya dinegosiasikan dan disepakati oleh pihak-pihak yang terlibat. Begitu seterusnya untuk produk/layanan lainnya, sehingga dengan adanya kesepakatan ini tidak menimbulkan friksi atau konflik yang mengakibatkan terganggunya proses dalam oganisasi secara keseluruhan.
Dalam membuat SLA dapat menggunakan tool berupa Value Stream Map (VSM), yaitu teknik yang digunakan untuk menganalisis dan mendesain flow (alur) dokumen dan informasi yang dibutuhkan dalam memproses produk/layanan. Dalam VSM, memuat berbagai informasi yang berkaitan dengan proses, seperti:
Total Waktu Proses dapat disebut dengan Process Lead Time (PLT) adalah waktu proses keseluruhan untuk menghasilkan suatu produk/layanan yang merupakan penjumlahan dari Value Added Time (VAT), Non Value Added Time (NVAT), dan Bussines Non Value Added Time (BNVAT).Dibawah ini adalah arti dari VAT, NVAT dan BNVAT yaitu sebagai berikut :
Untuk memahami penggunaan VSM sebagai tool untuk membuat SLA, dapat digambarkan di bawah ini :
Gambar Contoh Penggunaan Value Stream Map
Pelanggan tidak mau tahu bahkan tidak mau membayar NVAT maupun BNVAT, namun pelanggan hanya mau membayar VAT. VAT ini adalah SLA yang sebenarnya diinginkan oleh pelanggan. Namun pada pelaksanaannya oleh penyedia produk/layanan unsur NVAT dan BNVAT juga dimasukkan sebagai bahan pertimbangan dalam menentukan SLA.
Kesimpulan
Pelanggan tentunya memiliki harapan terhadap suatu produk/layanan, namun sebaliknya penyedia memiliki kewenangan yang terbatas dan memerlukan waktu proses untuk menyediakan produk/layanan tersebut. Untuk itulah diperlukan SLA yang dapat menjembatani perbedaan harapan, mendefinisikan kewenangan dan tanggung jawab masing-masing pihak serta pada akhirnya diperoleh kesepakatan bersama.
Begitu juga dengan Pusdiklat Pajak, setiap Bidang/Bagian termasuk Widyaiswara Pusdiklat Pajak yang dapat berperan sebagai pelanggan atau pun penyedia, tentunya juga memiliki harapan dan keterbatasan yang berbeda-beda. Maka SLA perlu segera dirumuskan, untuk menjadi acuan bersama dalam menghasilkan suatu produk/layanan.
Perbedaan SLA dan OLA
Perbedaan antara Service Level Agreement (SLA) dan Perjanjian Tingkat Operasional (Operational Level Agreement / OLA) adalah apa yang secara keseluruhan oleh organisasi TI menjanjikan kepada pelanggan (SLA), dan apa yang diinginkan oleh kelompok fungsional TI satu sama lain (OLA).
Kalau OLA adalah kesepakatan antara berbagai departemen IS / IT dan Service Level Manager, sedangkan SLA adalah kesepakatan keseluruhan antara IS / IT dan departemen bisnis.
SLA dapat menyatakan bahwa TI akan memastikan bahwa peralatan komputer akan dipertahankan. Tentu pernyataan itu adalah generalisasi yang tidak bisa diukur, jadi mungkin pernyataan yang lebih baik adalah Tidak akan ada kurang dari 100 jam kerja yang hilang per tahun karena kurangnya pemeliharaan peralatan komputer.
OLA perlu menyatakan segala hal yang dibutuhkan kelompok fungsional TI dalam hubungannya satu sama lain untuk mendukung SLA. Ini mencakup apa yang tim server akan lakukan untuk menambah server, apa tim desktop yang akan dilakukan untuk menambah sistem desktop, apa yang akan dilakukan oleh DBA untuk mengoptimalkan basis data dan lain-lain. Intinya adalah bahwa janji yang dibuat di SLA harus dapat diukur dan didukung sepenuhnya oleh OLA yang diandalkan SLA.
Alamat SLA Persyaratan Tingkat Bisnis, misalnya “Setelah kehilangan data, Aplikasi aktif dan berjalan dalam 6 Jam”. Untuk bisnis itu tidak menarik, berapa jam yang dibutuhkan oleh tim yang berbeda, misalnya tim server untuk mengganti disk, tim cadangan untuk mengembalikan file dari tape ke disk, tim DBA untuk memulai dan memulihkan (roll forward) database dan Tim pendukung aplikasi untuk memulai aplikasi. Rincian ini harus didefinisikan dalam OLA yang Manajer Layanan Tingkat perlu dinegosiasikan dan setuju dengan semua tim yang terlibat.
Langkah-langkah dalam membangun dan SLA dan OLA saling terkait.
Jika Service Level Manager perlu menawarkan Business Service Agreement (SLA) untuk Layanan IS / IT-Service End-to-End, dia menandatangani SLA ini hanya setelah dia mengaturnya dalam IS / IT untuk setiap sistem atau komponen yang digunakan untuk menyediakan Layanan ini merupakan Perjanjian Tingkat Operasi (Operations Level Agreement / OLA) dengan tim atau departemen yang menyediakan.
Tampilan Bisnis (SLA-View)
(1) Bisnis (mewakili pengguna) memerlukan dari IS / IT – yang ditunjukkan oleh Service Level Manager (SLM) – satu kesepakatan tentang kuantitas dan kualitas layanan (tugas) yang disediakan oleh IS / IT pada tingkat sistem (layanan); Persyaratan dari bisnis tersebut dinyatakan dalam Service Level Requirements (SLR).
Kesepakatan yang dihasilkan adalah SLA (Service Level Agreement) (4)
(6) Dokumen Pelaporan Tingkat Pelayanan jika Persyaratan Tingkat Layanan dipenuhi atau tidak.
Tampilan TI-internal (OLA-View)
Karena ada banyak tim yang berbeda, melaporkan ke manajer yang berbeda, diminta untuk menyediakan layanan yang disepakati
(2a-h) Manajer Tingkat Layanan memecah Persyaratan Tingkat Layanan yang diminta oleh Bisnis pada tingkat sistem end-to-end ke Persyaratan Tingkat Operasi (OLAP) untuk setiap tim dan
(3a-3h) menetapkan semua tim yang dibutuhkan akan mengadakan Perjanjian Tingkat Operasi .
Keempat istilah “Perjanjian Tingkat Operasional”, “Perjanjian Tingkat Operasional”, “Perjanjian Tingkat Operasional” dan “Perjanjian Tingkat Organisasi” digunakan sama dengan literatur yang dipublikasikan.
Tentang OLA-Template
Kekuatan dan nilai utama template kami adalah konten khusus subjek . Mereka bukan template yang menyediakan struktur OLA generik, mereka benar-benar berisi konten spesifik tim yang spesifik. Masing-masing template kami berisi daftar lengkap layanan yang disediakan / tugas yang dilakukan oleh tim terkait dan metrik terkait bagaimana cara mengukurnya. Tip Penggunaan: Jika tim proyek tidak meminta (dan membayar) layanan tertentu (perpanjangan), penulis menyarankan untuk lebih mengecek kotak centang “NO” (terbaik dengan penjelasan) daripada menghapus yang dari perjanjian. Hal ini untuk menghindari diskusi tentang kami tidak sadar bahwa ini tidak termasuk yang biasanya dimulai setelah beberapa hal yang tidak menyenangkan terjadi. OLA adalah prasyarat penting bagi manajer tingkat layanan untuk menyetujui bisnis pada SLA (Service Level Agreement).
Cadangan SLA / OLA
Template ini mendukung Service Level Manager untuk membentuk OLA dengan Tim Cadangan, antara lain :
Jika aspek internal Manajemen Tingkat Layanan tidak diperkenalkan hari ini, template ini mendukung Manajer TI proaktif untuk bersiap menghadapi langkah selanjutnya – yang akan datang dengan pasti – dengan merencanakan dan memperluas Katalog Layanan untuk Pencadangan dan Pemulihan dan Memperkenalkan dan mengukur indikator kinerja internal.
Selama perkiraan biaya, Manajer Proyek dapat dengan cepat mengidentifikasi jika layanan backup dan pemulihan dasar memadai atau proyeknya mungkin memerlukan beberapa layanan yang lebih maju (dan lebih mahal).
Database SLA / OLA Template ini mendukung antara lain :
REFERENSI :