SLA (Service Level Agreement), dan OLA (Operational Level Agreement) serta contoh penerapannya.

SLA (Service Level Agreement), dan OLA (Operational Level Agreement) serta contoh penerapannya. 

    Service Level Management adalah salah satu elemen dari service delivery. Service delivery adalah pelaksanaan dari disiplin-disiplin dalam framework 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 dan customers harus dijaga. Dalam Service Level Management terdapat beberapa proses, yaitu: UC (Underpinning Contracts), SLR (Service Level Requirement) ,OLA (Operational Level Agreement), dan SLA (Service Level Agreement), namun pada tugas softskill kali ini saya akan menjelaskan tentang apa itu SLA (Service Level Agreement), dan OLA (Operational Level Agreement) serta salah satu contoh penerapan dari SLA(Service Level Agreement).

APA ITU OLA?

     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. Pada istilah 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 untuk mendukung  nama layanan dari katalog layanan atau di tempat lain. OLA ini tetap berlaku sampai direvisi atau dihentikan.

Enam Tips untuk menyusun OLA, yaitu :

1. Tentukan semua layanan TI yang bertanggung jawab dalam Katalog Layanan. 
2. Sebagai CIO, terlibat dalam proses ini dengan memahami apa yang dibutuhkan masing-masing layanan. 
3. Tentukan pemain kunci (tim jaringan, kelompok server, dll) dan tanggung jawab mereka.
4. Letakkan setiap harapan kelompok TI untuk memberikan setiap layanan.  
5. Datang dengan rencana kontingensi untuk kejadian tak terduga. 
6. Uji dan uji ulang OLA, dan buat perubahan bila diperlukan. OLA, seperti SLA, seharusnya tidak statis dan harus memiliki tanggal mulai, tengah dan akhir.

    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 :

• Tujuan OLA adalah untuk menyajikan deskripsi dukungan internal dari penyedia layanan yang jelas, ringkas dan terukur. 
• Tujuan dari Perjanjian Tingkat Operasional (OLA) ini adalah untuk memastikan bahwa elemen dan komitmen yang tepat tersedia untuk memberikan dukungan layanan dan penyampaian layanan yang konsisten oleh Penyedia Layanan. 
• Tujuan dari Persetujuan ini adalah untuk mendapatkan kesepakatan bersama untuk penyediaan layanan antar unit ITS. 
• Tujuan dari Persetujuan ini adalah untuk memberikan referensi yang jelas tentang kepemilikan, akuntabilitas, peran dan / atau tanggung jawab layanan. Persepsi yang sesuai dengan ketentuan layanan yang diharapkan dengan dukungan dan layanan aktual.  
• Tujuan OLA adalah untuk membantu memastikan bahwa kegiatan pendukung yang dilakukan oleh sejumlah komponen tim pendukung secara jelas disesuaikan untuk menyediakan SLA yang dimaksud.

    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 : 

• Network (NTS)  Jaringan tersedia untuk service_name selama jam operasi tertentu 
• Backup (Core Tech) 
• Pusat Data Hosting (Core Tech) 
• Dukungan vendor ( Nama, jika ada ) 
• Tambahan layanan ketergantungan atau kontrak penunjang lainnya .

      Penyedia Layanan berikut dikaitkan dengan OLA ini:

• Ketersediaan didefinisikan di bagi jadi  4 bagian, yaitu Jam Cakupan, Waktu Respons & Eskalasi,  dan Nomor telepon tidak digunakan selama jam kerja kecuali jika ditentukan dalam bagian ini. 
• Persyaratan Penyedia Layanan (Peran dan Tanggung Jawab); Tanggung jawab dan / atau persyaratan untuk semua penyedia layanan untuk mendukung Perjanjian ini meliputi: Temui waktu tanggap terkait dengan prioritas yang ditugaskan pada insiden dan permintaan layanan.
• Melatih staf yang dibutuhkan pada alat pendukung layanan yang sesuai ( contoh contoh untuk layanan ini ) ;Gunakan Proses Pemberitahuan Outage untuk memberi tahu Pelanggan untuk semua perawatan terjadwal Melalui halaman web Maintenance Calendar, Service Catalog dan / atau komunikasi ke kampus melalui Communication Specialist. 
• Berpartisipasi dalam semua aktivitas dukungan layanan termasuk penanganan insiden, masalah, perubahan, pelepasan dan konfigurasi.
• Temui metrik SLA seperti yang tercantum di service_name SLA yang ada di Service SLA_link     ;Persyaratan tambahan yang diidentifikasi selama pengumpulan persyaratan teknis atau fungsional, misalnya, sebagai bagian dari proses 'Design Review Board (DRB) ITS

Operasi Pusat Data setuju untuk memberikan dukungan di luar jam kerja yang mencakup beberapa hal, yaitu:

• Menjaga dan menegakkan akses fisik yang aman ke fasilitas Data Center
• Pemantauan perangkat keras, perangkat lunak, layanan dan lingkungan
• Meningkatnya masalah / kejadian yang terdeteksi (melalui pemantauan atau inspeksi fisik) ke pihak-pihak yang sesuai per prosedur yang ditetapkan dalam ITS dan / atau prosedur yang ditetapkan dengan pemangku kepentingan
• Sajikan sebagai titik inisiasi / koordinasi untuk kejadian besar
• Melakukan dan mengelola backup sistem 
• Melakukan dan mengelola pemrosesan manual atau tugas operasional bagi pemangku kepentingan

     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:

• Jumlah orang yang terkena dampak signifikan. 
• Struktur organisasi adalah multiplier untuk jumlah orang yang terkena dampak. Yaitu dampak yang signifikan terhadap kemampuan petugas utama untuk melakukan bisnis universitas.     
• Persentase total tugas yang tidak bisa lagi dilakukan oleh individu.            
• Batas akhir Kalender Akademik dan Administrasi. 
• Signifikan dampak pada penyampaian instruksi. 
• Dampak signifikan atau kekal pada prestasi akademik siswa.  
•  Risiko yang signifikan terhadap hukum, peraturan, atau kepatuhan kebijakan.

    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. 

1. Pelaporan metrik ini akan berlangsung (setiap hari, bulanan, kuartalan ) dan dapat diakses di halaman web layanan internal.
2. Masing-masing kelompok memiliki prioritas dan metode operasinya sendiri,
3. seringkali hanya memiliki gagasan samar tentang bagaimana kelompok kerja kopernya berada. 
4. Ketika ketidaksepakatan di antara kelompok muncul, komunikasi menjadi tegang
5. ketegangan meningkat dan tingkat layanan kesepakatan (SLA) kadang tidak terpenuhi. Di situlah tingkat operasional agreement (OLA) masuk. 

 

Penerbitan Perjanjian Tingkat Operasional Setelah membuat perjanjian tingkat operasional, Anda harus mempublikasikannya agar diberlakukan. 

1. Masuk ke Konsol Layanan Meja sebagai pemilik layanan.  
2. Buka Workspace Level Operasional . Sistem menampilkan daftar kesepakatan. 
3. Pilih perjanjian untuk menerbitkan, lalu dari Action Menu, pilih Publish Agreement .kesepakatan tersebut muncul dalam daftar dengan status publikasi . 

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. 

1. Masuk ke Konsol Layanan Meja sebagai pemilik layanan. 
2. Buka Workspace Level Operasional . Sistem menampilkan daftar kesepakatan. 
3. Pilih perjanjian untuk menerbitkan, lalu dari Action Menu, pilih Obsolete Agreement .Kesepakatan tersebut muncul dalam daftar dengan status usang .

    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:

• dapat menentukan layanan TI yang diharapkan bisa mengantarkan dalam bentuk Katalog Layanan. 
• Identifikasi pemain kunci dalam memberikan layanan tersebut. 
• adanya tanggung jawab masing-masing kelompok. 
• Lay out harapan untuk waktu pengiriman. 
• dapat menentukan kontinjensi untuk kejadian tak terduga. 

 Contoh penerapan OLA

  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:

• ABA (Abandonment Average) : Sebuah persentase panggilan masuk, dimana panggilan lain di tahan, dan menjawab panggilan masuk yang lainnya
• ASA (Average Speed to Answer) : Rata-rata jumlah detik yang diperlukan untuk panggilan yang harus dijawab oleh pusat layanan.   
• TSF (Time Service Factor) : Sebuah persentase panggilan dijawab dalam batas waktu tertentu, sebuah contoh yang baik adalah mengatakan 80% dalam 20 detik.    
• FCR (First Call Resolution) : Sebuah persentase panggilan masuk yang dapat diselesaikan/ dipecahkan tanpa harus menelpon pelanggan kembali atau pelanggan tidak perlu menelpon kembali untuk menyelesaikan kasus ini.    
• TAT (Turn Around Time) : Waktu yang dibutuhkan untuk menyelesaikan pekerjaan tertentu.

    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?

• Memastikan bahwa target dapat dipenuhi sebelum disepakati. 
• SLA tidak bisa didasarkan hanya pada keinginan (tapi juga kemampuan). 
• Keterbatasan alokasi sumberdaya SLM. 
• SLM tidak punya kewenangan/otoritas yang cukup. 
• SLA tidak didukung OLA dan UC yang sesuai. 
• Konsumen tidak tahu tingkat layanan yang dibutuhkan.
• SLA kurang jelas/rinci.
• SLA kurang sosialisasi.

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:

• Supplier merupakan pihak yang memberikan sumber daya kepada organisasi untuk menjalankan proses menghasilkan produk/layanan
• Input adalah segala sumber daya yang digunakan dalam proses menghasilkan produk/layanan, meliputi Manusia, Mesin, Metode, Material dan Lingkungan (Mother Nature)
• Proses merupakan serangkaian aktivitas untuk menghasilkan produk/layanan, meliputi Proses Utama yaitu proses yang dilakukan untuk menghasilkan produk
• Proses Pendukung yaitu proses yang dilakukan untuk mendukung proses utama
• dan Proses Manajemen yaitu proses yang dilakukan untuk menyempurnakan proses utama
• Output adalah berupa produk/layanan yang dihasilkan dari suatu proses
• Costumer adalah pihak yang menerima/membutuhkan produk/layanan dari suatu organisasi.

     Pembuatan atau penentuan SLA sebaiknya melibatkan seluruh pihak terkait dalam suatu organisasi, agar diperoleh kesepakatan bersama. Pembuatan SLA ini melalui beberapa tahapan sebagai berikut :

• Untuk membuat SLA yang perlu dipahami adalah tidak semua produk/layanan harus memiliki SLA. Buatlah SLA untuk produk/layanan yang benar-benar critical, dominan terhadap kebutuhan pelanggan.    
• Menentukan pihak-pihak yang terlibat, karena SLA merupakan kesepakatan antara pelanggan dengan penyedia (supplier).            
• Menetapkan harapan pelanggan dan syarat-syaratnya.   
• Memetakan proses dan aktivitasnya dalam menyediakan produk/layanan tersebut.  
• Mengukur waktu yang dibutuhkan untuk menghasilkan produk/layanan tersebut.   
• Melakukan negosiasi untuk mendapatkan kesepakatan waktu penyelesaian dari produk/layanan dimaksud

Menurut Utomo (2008) Untuk dapat membuat perjanjian service level yang mampu menjembatani kebutuhan bisnis, diperlukan langkah-langkah sebagai berikut :

a. Kategorisasi Layanan Bisnis Kritis

    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 :

1. Alokasi dan prioritas terhadap resource di lingkungan TI : Departemen TI selalu bekerja dengan beragam keterbatasan, baik sumber daya manusia  maupun kapasitas sistem. Dengan kategorisasi yang jelas, maka resource TI dapat dialokasi dan diprioritaskan atas kebutuhan paling kritis dari setiap unit bisnis.
2. Implementasi Quality of Services (QoS) :Secara sistem, TI akan mampu menset-up perangkat keras atas dasar tingkatan quality of services dari masing-masing produk/layanan. Service yang memiliki kritikalisasi lebih tinggi akan mendapatkan kapasitas resource dan prioritas yang lebih besar dibanding service dengan kritikalisasi yang lebih rendah. 
3. Alokasi anggaran yang lebih rasional

b. Penentuan Kebutuhan Kinerja Layanan (Availability dan Performance)

   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 :

1. Berapa lama layanan boleh terhenti dalam suatu jangka waktu tertentu, baik karena alasan yang direncanakan maupun karena kerusakan sistem 
2. Berapa lama waktu yang dibutuhkan oleh sistem untuk menyelesaikan satu kali transaksi 
3. Berapa lama waktu yang ditoleransi untuk memulihkan sistem jika terjadi kerusakan Hal ini sangat penting untuk menjadi pengetahuan bersama, karena ada korelasi yang sangat tinggi antara availability dan performance yang dituntut dengan alokasi anggaran yang harus disediakan untuk memenuhi tuntutan tersebut.

c. Pembangunan Service Level atas dasar prioritas bisnis

   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.

d. Penggunaan SLA untuk membangun Service Model

  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.

e. Pengukuran kinerja secara konsisten dan berjangka

   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 :

1. Strategi SLM yang baru diterapkan oleh suatu organisasi TI 
2. Teknologi atau produk baru yang akan “hidup” dari fase pengembangan atau pengujian 
3. Kepedulian pelanggan terhadap penyerahan jasa-jasa TI 
4. Keinginan pelanggan untuk memilih seberapa besar jasa yang mereka inginkan agar disediakan oleh TI.

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.

• Deskripsi Pelayanan ; SLA harus mencantumkan jasa-jasa apa saja yang disediakan. Menuliskan deskripsi yang rinci mengenai jasa-jasa yang dibutuhkan berisi pengertian mengenai apa yang dapat ditawarkan kepada para pelanggan dan memastikan para pelanggan mengerti sebenarnya apa yang mereka butuhkan.Penyedia jasa biasanya akan menyediakan service catalog (katalog jasa) untuk mempermudah apa  yang ingin mereka deskripsikan. katalog tersebut harus memuat semua jasa yang disediakan, termasuk berbagai aplikasi, infrastruktur dan fungsi bisnis lainnya.  Bagi organisasi yang tidak memiliki service catalog, mungkin akan menyadari bahwa cara terbaik untuk mengumpulkan informasi bagi katalog adalah dengan berbicara langsung dengan pelanggan.Karena merekalah yang mengetahui sistem apa saja yang mereka gunakan, termasuk service desk dari pihak pelanggan yang mengetahui jasa-jasa apa saja yang dibutuhkan. Salah satu tantangan yang dihadapi koordinator SLM suatu organisasi adalah menerangkan kepada pelanggan mengenai hubungan antara service catalog dengan SLA. Berhubung service atalog adalah dokumen yang terpisah dari dokumen SLA, maka sangat diutamakan untuk membuat keduanya bisa diakses dengan mudah, salah satunya adalah melalui intranet perusahaan.

• Standarisasi Pelayanan; Setelah menentukan jasa-jasa apa yang disediakan, maka suatu organisasi akan siap mempertimbangkan suatu standarisasi yang mencakup konsep-konsep seperti aksesibilitas, kehandalan, waktu respon dan resolusi. Sebagai contoh, aksesibilitas seharusnya ditentukan dalam target-target yang telah disepakati. Jika jam bisnis normal dari pelanggan anda adalah dari jam 7 pagi sampai jam 6 sore, akan lebih sesuai jika pelayanan yang diberikan dapat mendukung proses-proses bisnis juga tersedia selama kurun waktu yang sama. Tiap pelayanan yang diberikan juga akan memiliki jam operasi regular dan waktu yang terjadwal untuk perawatan. Informasi ini perlu diilustrasikan dalam SLA. Organisasi juga perlu menentukan apa yang dapat ditawarkan pada para pelanggan jika terjadi suatu bencana atau keadaan darurat. Mampukan perusahaan memberikan waktu pelayanan yang sama selama terjadinya salah satu skenario tersebut? Standarisasi lainnya yang juga tercakup melibatkan waktu repson dan waktu resolusi. Akankah hal ini sama bagi semua jenis pelayanan yang ditawarkan atau tergantung pada urgensi dan pengaruh bisnis? Apapun yang sudah menjadi keputusan, pastikan bahwa para pekerja TI yang akan menyampaikan pelayanan tersebut kepada pelanggan agar mereka memiliki pemahaman sampai setingkat mana mereka diharapkan bertindak.

• Durasi; SLA harus menjelaskan kapan kesepakatan itu dimulai dan berakhir. Hal ini sangat penting karena menyangkut ketersediaan jasa yang diberikan dalam rentang waktu tertentu. Tanggal mulainya SLA memungkinkan anda untuk mulai memantau kinerja TI pada tanggal yang sudah ditentukan. Jika anda menyediakan pelayanan baru atau hanya perlu merevisi pelayanan yang telah ada, beri waktu yang cukup untuk mengkomunikasikan rincian kesepakatan itu kepada pelanggan. Misalnya dalam upaya mempertahankan harga tetap rendah bagi pelanggan, anda mungkinmenyewa perlengkapan yang diperlukan selama 18 bulan, jika SLA anda habis dalam waktu 12bulan, pelanggan tentu tidak diwajibkan membayar pelayanan anda yang tidak mereka gunakan (6bulan sisa) dan anda dituntut untuk mencari cara lain dalam membiayai penyewaan perlengkapan itu.

• Peran dan Tanggungjawab;Mengelola harapan pelanggan dan TI sendiri dapat merupakan sesuatu yang rumit jika anda tidak menentukan tanggungjawab semua pihak dalam SLA. Anda dan pelanggan saling memiliki kewajiban satu sama lain yang harus didefinisikan dengan baik. Beberapa dari tanggungjawab pihak pelanggan mungkin tergantung pada strategi perusahaan anda. Misalnya beberapa perusahaan menekankan pentingnya akses langsung atau self-service untuk mempertahankan posisi harga rendah. Jika hal ini benar mengenai organisasi milik pelanggan, anda mungkin perlu meminta agar para pelanggan mempelajari materi-materi fasilitas diri sebelum menghubungi bagian service desk anda. Persyaratan mendasar lainnya adalah bahwa para pelanggan anda menjadi familiar dengan standarisasi perusahaan untuk berbagai pembelian dan penginstalan software PC anda. Para pelanggan juga diharapkan akan melaporkan insiden-insiden ke service desk pada saat hal itu terjadi, bukan setelah berjam-jam kemudian.

• Kriteria Evaluasi; Tanpa kriteria evaluasi, anda tidak memiliki sarana tujuan untuk menentukan sebaik apa organisasi TI anda bekerja. Pastikan bahwa organisasi TI anda sudah memiliki perlengkapan untuk mengikuti apa yang diminta oleh pelanggan sebelum menyetujuinya. Salah satu keuntungan bersama adanya SLA adalah bahwa anda dan pelanggan dapat menentukan bagaimana anda akan menilai layanan yang akan mereka dapatkan. Dengan menetapkan ukuran-ukuran dari tujuan yang diinginkan, anda mengurangi berspekulasi dalam menentukannya.  Batasan-batasan ini sangat penting artinya bagi organisasi TI, tetapi kurang penting bagi para pelanggan. Itu contoh batasan berdasarkan sistem, bukan apa yang dibutuhkan pelanggan saat ini, yaitu batasan berdasarkan pelayanan. Misalnya ukuran aksesibilitas suatu aplikasi dapat dianggap berarti bila mampu merefleksikan penyampaian secara end to end, kemudahan akses aplikasi, kebijakan dan infrastruktur. Selain itu menjadi kebutuhan suatu SLA untuk memasukkan ukuran lainnya karena lingkungan anda yang spesifik.

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

• 1 bulan = 30 hari x 24 jam = 720 Jam (720 jam merupakan layanan 100%) 
• Sedangkan jika 98% maka layanan standard mereka adalah 
• 98% * 720 jam = 705.6 jam (layanan standard mereka, sisanya 14.4 jam dianggap wajar jika layanan itu mati (down)

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 :

• Biaya bulanan internet = Rp. 1.000.000

• SLA layanan (contoh bulan Juli) = 76,6% (100% – 23,3%), artinya pihak provider bulan juli hanya bisa memberikan layanan internet sebesar 76,6% artinya ada selisih (98% – 76.6% = 21.3%, yang tidak bisa dipenuh oleh pihak provider)

Nah 21,3 % itu adalah hak kita u/ mendapatkan penggantian, penggantian ini biasanya dalam bentuk pengurangan pembayaran:

• misalkan kita bayar 1bulan Rp. 1.000.000 = untuk layanan 98% (1% sekitar Rp. 10.204) Maka u/ layanan hanya 76.6% = 1.000.000 – (21.3% X Rp. 10.204)

= 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
• proses yang bernilai tambah
• delay time (waktu tunda)
• banyaknya operator
• dan input yang digunakan.

    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 :

• VAT adalah waktu yang benar-benar digunakan untuk suatu proses, idealnya adalah maksimum
• NVAT adalah waktu yang digunakan untuk menunggu sebelum memulai proses (menunggu input) atau menungggu proses berikutnya. Idealnya NVAT adalah nol
• BNVAT adalah tambahan waktu tunggu karena terkait adanya regulasi dalam suatu proses. Hal ini tidak dapat dihindari dalam suatu proses, namun idealnya minimum.

    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 :

1. Backup 
2. Penyimpanan 
3. Mengembalikan 
4. Pemulihan

   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 :

• Service Level Manager untuk membentuk OLA dengan DBA Team
• DBA dalam merencanakan dan memperluas Katalog Layanan untuk layanan DBA dasar dan lanjutan serta memperkenalkan dan mengukur indikator kinerja internal
• Manajer Proyek dalam mengidentifikasi (atau mengecualikan) kebutuhan akan layanan DBA tingkat lanjut (dan yang lebih mahal), sehingga memungkinkan perkiraan biaya yang lebih akurat

REFERENSI :

• Awasthi, Om. Desember 2015. Service level agreement( SLA ) in projects. https://www.linkedin.com/pulse/service-level-agreement-sla-projects-om-awasthi (diakses tanggal 10 Juni 2017) 
• Djufri,Muhammad. Juli 2013. MENGENAL LEBIH DEKAT SLA – Service Level Agreement.http://webcache.googleusercontent.com/search?q=cache:zK8nB-8XEAUJ:www.bppk.kemenkeu.go.id/publikasi/artikel/167-artikel-pajak/12530-mengenal-lebih-dekat-sla-service-level agreement+&cd=3&hl=id&ct=clnk&client=firefox-b(diakses tanggal 11 Juni 2017) 
• Rouse, Margaret . Maret 2011. Operational Level Agreement (OLA). https://translate.google.com/translate?hl=id&sl=en&u=http://whatis.techtarget.com/definition/operational-level-agreement-OLA&prev=search (diakses tanggal 12 Juni 2017) 
• Taradien,Debby Chodati Sengka.April 2012. PERJANJIAN TINGKAT LAYANAN (SERVICE LEVEL AGREEMENT/ SLA) http://debbychodati07.blogspot.co.id/2012/04/sla-service-level-agreement.html  (diakses tanggal 12 Juni 2017) 
• Chandra. Juni 2016. Apa itu Service Level Agreement?. https://servernesia.com/1460/apa-itu-sla/ (diakses tanggal 13 Juni 2017) 
• IT.Checklist.com.Operation Level Agreement(OLA).http://www.it-checklists.com/SLA_OLA_Operations_Level_Agreement.html (diakses pada tanggal 14 Juni 2017)
• heatsoftware.com. Working with Operational Level Agreements. https://translate.google.com/translate?hl=id&sl=en&u=http://help.heatsoftware.com/content/servicedesk/servicelevelmgmt/operational_level_agreement.htm&prev=searc.html  (diakses tanggal 15 Juni 2017)