SLA adalah janji kepada pelanggan - OLA memastikan tim internal Anda dapat memenuhinya. Dengan Trupeer, Anda bisa menghemat waktu berjam-jam untuk penulisan OLA dengan memulai dari template perjanjian tingkat operasional gratis, menyesuaikannya dengan panduan brand Anda, lalu mengubah OLA menjadi panduan video yang menyelaraskan setiap tim internal di balik standar layanan bersama.

Apa itu template perjanjian tingkat operasional?

Perjanjian tingkat operasional, atau OLA, adalah kesepakatan internal antar tim dalam organisasi yang sama yang menjadi dasar komitmen yang dibuat untuk pihak di luar organisasi tersebut. Help desk menjanjikan bisnis penyelesaian dalam empat jam untuk insiden besar. Janji itu hanya berlaku jika tim jaringan, tim aplikasi, dan siapa pun yang berada dalam rantai tersebut masing-masing menjalankan perannya dalam waktu yang sudah diketahui.

Di sinilah bagian-bagian internal itu dituliskan dalam OLA. Ini bukan kontrak, tidak ada pihak yang membayar pihak lain, dan penegakannya sepenuhnya bersifat manajerial—yang sekaligus menjadi kelemahannya dan alasan mengapa OLA bisa jujur dengan cara yang tidak bisa dilakukan kontrak.

Template perjanjian tingkat operasional adalah struktur yang dapat digunakan ulang: pihak-pihaknya, layanan yang dicakup, komitmen, metrik, serta pengaturan peninjauan. Template seperti ini mudah ditemukan. Kebanyakan template memungkinkan Anda menulis OLA yang sepenuhnya dipatuhi namun tetap gagal—dan itulah yang dibahas halaman ini.

OLA vs SLA: masing-masing benar-benar berkomitmen pada apa

Ada tiga dokumen dalam keluarga ini, dan mencampuradukkannya menimbulkan masalah nyata.

service level agreement adalah komitmen kepada pelanggan atau bisnis. Dokumen ini ditulis dalam istilah pelanggan, biasanya end-to-end, dan inilah yang dilaporkan kepada pihak di luar rantai pengantaran.

operational level agreement bersifat internal, antar tim yang sama-sama melapor ke organisasi yang sama. Dokumen ini ada semata-mata agar SLA bisa dicapai, dan dokumen ini tidak boleh memuat komitmen yang tidak diperlukan oleh SLA.

underpinning contract adalah kesepakatan komersial dengan pihak ketiga, vendor, atau penyedia yang di-outsourcing, yang mendukung rantai yang sama. Dokumen ini memiliki kekuatan hukum, yang tidak dimiliki OLA, dan biasanya fleksibilitasnya paling kecil di antara ketiganya, sehingga sebaiknya disepakati sebelum SLA, bukan setelahnya.

Konsekuensi praktisnya adalah aturan urutan. Sepakati underpinning contract, lalu SLA berdasarkan apa yang diizinkan oleh kontrak-kontrak tersebut, kemudian OLA yang mengisi sisanya. Organisasi yang melakukannya dengan urutan lain secara rutin menjanjikan bisnis sesuatu yang belum disepakati vendor untuk diserahkan.

Cara menyesuaikan template ini di Trupeer

Langkah 1: Buka Bagian Templates

Buka bagian Templates dari navigasi utama.

Langkah 2: Pilih dan Buka sebuah Template

Klik pada template apa pun yang ingin Anda gunakan untuk membukanya.

Langkah 3: Perluas Tampilan Template

Jika diperlukan, perluas tampilan template untuk melihat tata letak dan detail secara jelas.

Langkah 4: Edit Template

Klik Edit untuk mulai memodifikasi template yang dipilih.

Di dalam editor, Anda bisa:

• Menambahkan bagian baru

• Menentukan atau memperbarui aturan pemformatan

• Menambahkan logo dan menyesuaikan posisinya serta pengaturan terkait

Langkah 5: Simpan Template yang Anda Sesuaikan

Setelah membuat semua perubahan yang diperlukan, klik Save untuk menyimpan template yang diperbarui sebagai milik Anda.

Langkah 6: Pratinjau dan Penyempurnaan Template

Saat Anda ingin melihat seperti apa tampilan template yang Anda sesuaikan, buka Preview.

Dari layar pratinjau, Anda bisa terus melakukan penyesuaian secara langsung jika diperlukan, sehingga template tampil persis seperti yang Anda inginkan.

Dengan template perjanjian tingkat operasional, Anda bisa:

• Menghemat waktu untuk penulisan: Lewati halaman kosong dengan struktur yang dibuat untuk OLA.

• Menyelaraskan tim internal: Kolom bawaan memastikan setiap tim mengetahui tanggung jawabnya.

• Tetap sesuai brand: Terapkan logo, font, dan warna Anda menggunakan brand kit dari Trupeer.

• Melindungi SLA pelanggan: OLA yang kuat mencegah perpindahan internal merusak janji eksternal.

• Menstandarkan lintas layanan: Gunakan template OLA yang sama untuk setiap kesepakatan internal.

• Menjangkau tim global: Terjemahkan OLA ke 65+ bahasa hanya dengan satu klik.

Mengapa setiap tim memenuhi OLA-nya, tetapi SLA tetap dilanggar

Ini adalah pola paling umum dalam manajemen layanan dan terlihat seperti sebuah kontradiksi.

Setiap tim melaporkan hijau. Jaringan merespons dalam jamnya. Aplikasi menyelesaikan dalam dua jamnya. Help desk melakukan triase dalam tiga puluh menit. Laporan kepatuhan OLA bulanan mudah dibaca. Namun, SLA pelanggan dilanggar pada sepertiga insiden besar.

Penjelasannya adalah OLA mengukur waktu di dalam tim, sedangkan SLA mengukur waktu end-to-end. Perbedaan antara dua angka tersebut adalah transit: tiket yang berada dalam antrean setelah dialihkan, menunggu untuk diambil, atau dikembalikan untuk informasi tambahan.

Waktu itu milik tidak ada siapa pun. Waktu itu tidak ada dalam OLA siapa pun, tidak dilaporkan di mana pun, dan sering kali lebih besar daripada seluruh waktu kerja yang digabungkan.

Artinya, kegagalannya bersifat struktural, bukan masalah kinerja. Menambah tekanan pada tim untuk memenuhi angka yang sudah ada tidak akan membantu, karena mereka sudah memenuhinya.

OLA mengatur perpindahan, bukan pekerjaan

Penyusunan ulang yang memperbaiki masalah ini kecil, tetapi mengubah tujuan dokumennya.

OLA yang ditulis dengan cara biasa membuat sebuah tim berkomitmen pada berapa lama pekerjaan tim itu sendiri berlangsung. Bagian itulah yang dikendalikan tim, sehingga bagian itulah yang bersedia mereka tanda tangani, dan itu adalah hal yang paling tidak berguna untuk disepakati karena sejak awal bagian itu bukan variabel.

OLA yang ditulis dengan baik membuat tim berkomitmen pada antarmuka di antara mereka. Apa yang harus ada dalam tiket sebelum tiket tersebut dialihkan. Berapa lama tim penerima harus mengambilnya. Apa yang terjadi ketika tiket belum lengkap. Siapa yang bertanggung jawab atas tiket selama jeda.

Begitu perpindahan menjadi pokok bahasan, dua kolom yang hilang menjadi jelas. Kriteria masuk, artinya apa yang harus benar sebelum jam tim penerima mulai berjalan. Dan alokasi eksplisit untuk waktu transit itu sendiri, sehingga jeda antar tim menjadi angka milik seseorang, bukan milik tidak ada siapa pun.

Semua hal lain dalam template OLA adalah administrasi. Dua hal inilah dokumennya.

Kriteria masuk: apa yang harus benar sebelum jam mulai berjalan

Perilaku yang paling merusak dalam rantai multi-tim adalah bouncing: sebuah tiket datang tanpa informasi yang cukup, tim penerima mengembalikannya, dan jam mereka direset.

Bouncing sepenuhnya rasional dari sudut pandang tim penerima. Mereka tidak bisa mengerjakan tiket tersebut dan kepatuhan mereka diukur berdasarkan waktu penyelesaian mereka sendiri, sehingga mengembalikannya melindungi keduanya. Ini juga tempat sebagian besar waktu yang berlalu mengalir, dan tidak terlihat dalam setiap laporan yang mengukur tim secara terpisah.

Kriteria masuk memperbaikinya dengan memindahkan kewajiban ke hulu. Setiap baris OLA mencantumkan kolom spesifik yang harus diisi agar tim tersebut dapat menerima pekerjaan. Untuk perpindahan dari jaringan, itu bisa berupa nama perangkat, kode lokasi, teks error yang persis, waktu pertama kali diamati, dan apakah pengguna lain terdampak. Untuk perpindahan dari aplikasi, itu bisa berupa pengguna, referensi transaksi, langkah untuk mereproduksi, dan tangkapan layar.

Lalu, komitmen tim pengirim berubah redaksinya. Bukan “triase dalam tiga puluh menit”, melainkan “serahkan tiket yang memenuhi kriteria masuk dalam tiga puluh menit”. Jam yang sama, kewajiban yang berbeda, dan insentif kini berada pada tim yang benar-benar bisa mengumpulkan informasi tersebut.

Tim penerima tetap berhak menolak, dan hak itu sebaiknya sempit: penolakan hanya valid jika kriteria masuk yang disebutkan memang benar-benar tidak ada, dan setiap penolakan dicatat beserta alasannya. Pencatatan inilah yang mengubah bouncing dari kebiasaan yang tidak terlihat menjadi angka yang harus dijelaskan seseorang.

Template perjanjian tingkat operasional gratis: struktur untuk dicontoh

Salin dari sini. Kolom yang ditandai dengan tanda bintang adalah yang biasanya dihilangkan oleh template standar.

Header. Referensi dan versi OLA. Pihak-pihaknya, artinya dua tim berdasarkan nama. SLA atau layanan yang didukung. Tanggal efektif, tanggal peninjauan, dan pemilik yang disebutkan di setiap sisi.

Ruang lingkup. Layanan, sistem, atau jenis permintaan yang dicakup, serta secara eksplisit apa yang tidak dicakup.

Jam layanan. Cakupan untuk setiap pihak, termasuk pengaturan di luar jam kerja dan perbedaannya. Jam layanan yang tidak cocok antara dua tim dalam rantai yang sama adalah celah yang umum dan diam-diam fatal.

Tabel komitmen. Satu baris per jenis permintaan atau prioritas, dengan: pemicu, kriteria masuk, waktu respons, waktu penyelesaian atau penyerahan kembali, waktu transit yang dialokasikan, dan titik eskalasi.

Eskalasi. Siapa yang dihubungi pada setiap tahap, melalui jalur apa, dan setelah berapa lama. Sertakan jalur di luar jam kerja.

Ketergantungan. Apa yang dibutuhkan tim ini dari pihak lain, termasuk underpinning contract apa pun dengan pihak ketiga, dengan waktu masing-masing dicatat agar perhitungannya bisa dicek.

Pengukuran. Apa yang diukur, dari sistem mana, oleh siapa, dan seberapa sering dilaporkan. Sertakan bounce rate bersama respons dan penyelesaian, karena metrik inilah yang menunjukkan apakah kriteria masuk bekerja.

Pengecualian. Kondisi yang disepakati ketika komitmen tidak berlaku, seperti selama insiden besar yang dinyatakan, atau saat perubahan dibekukan.

Peninjauan. Tanggal, dan apa yang memicu peninjauan di luar siklus.

Salin sampai di sini. Pertahankan hanya dua atau tiga halaman. OLA yang cukup panjang untuk perlu dibaca dua kali tidak akan dikonsultasikan selama insiden, dan justru saat insiden itulah yang paling penting.

Cara memastikan OLA benar-benar menjumlah hingga SLA

Sebelum menandatangani apa pun, lakukan perhitungan. Ini hanya butuh lima belas menit dan hampir selalu dilewati, karena OLA dinegosiasikan satu per satu dengan tim yang berbeda pada hari yang berbeda.

Dua aturan membuat ini berguna. Waktu transit harus muncul sebagai barisnya sendiri, karena itulah inti persoalannya. Dan setiap rantai membutuhkan cadangan (headroom), karena rantai yang jumlahnya tepat sama dengan SLA akan dilanggar setiap kali ada sesuatu yang sedikit saja berjalan tidak sesuai. Sepuluh hingga lima belas persen adalah margin yang masuk akal.

Jika totalnya melebihi SLA, Anda punya tiga opsi yang jujur: negosiasikan ulang SLA, kurangi waktu sebuah tim dengan sesuatu yang membuatnya memungkinkan, atau hapus perpindahan. Yang tidak bisa Anda lakukan adalah menandatangani OLA yang menjamin pelanggaran lalu mengelola kinerja berdasarkan itu—dan itulah posisi yang mengejutkan banyak help desk.

Perusahaan ritel yang waktu transitnya lebih lama daripada pekerjaannya

Rendlesham Group menjalankan beberapa merek ritel dengan sekitar enam ribu staf dan help desk TI internal yang mendukung toko dan kantor pusat.

SLA insiden P2 mereka untuk bisnis adalah empat jam hingga resolusi. Tingkat pelanggaran pada P2 berada di sekitar tiga puluh delapan persen selama dua tahun. Kepatuhan OLA setiap tim dilaporkan bulanan dan setiap tim berstatus hijau.

Seseorang akhirnya memberi timestamp pada setiap perubahan status untuk seratus dua puluh insiden P2 yang dilanggar.

Waktu total median yang berlalu adalah enam jam lima puluh satu menit. Dari itu, tiga jam dua belas menit adalah waktu di dalam tim yang sedang aktif mengerjakan tiket. Tiga jam tiga puluh sembilan menit adalah transit: duduk dalam antrean setelah dialihkan, menunggu untuk diambil, atau dikembalikan.

Lebih dari setengah waktu yang berlalu pada insiden yang dilanggar dimiliki oleh tidak ada siapa pun dan tidak dilaporkan di mana pun.

Kontributor terbesar adalah bouncing. Empat puluh satu dari seratus dua puluh tiket telah dikembalikan setidaknya sekali oleh tim penerima karena informasi yang tidak memadai, dan setiap bounce menambah median satu jam dua puluh menit sekaligus mengatur ulang jam tim tersebut. Dua alasan paling umum adalah tidak ada teks error atau tangkapan layar yang terlampir, serta tidak ada konfirmasi toko mana yang terdampak insiden.

Perubahannya sempit. Kriteria masuk dituliskan ke setiap baris OLA. Komitmen help desk diubah dari triase dalam tiga puluh menit menjadi “serahkan tiket yang memenuhi kriteria masuk dalam tiga puluh menit”. Transit lima belas menit dialokasikan untuk setiap perpindahan dan dihitung terhadap tim penerima setelah kriteria masuk terpenuhi. Dan setiap bounce dicatat dengan alasannya.

Selama dua kuartal berikutnya, bounce rate turun dari tiga puluh empat persen P2 menjadi sembilan. Waktu transit median turun dari tiga jam tiga puluh sembilan menit menjadi satu jam enam menit. Tingkat pelanggaran P2 turun dari tiga puluh delapan persen menjadi sebelas.

Waktu resolusi internal tidak berubah secara material pada tim mana pun. Tidak ada yang bekerja lebih cepat. Waktu yang sebelumnya milik tidak ada siapa pun kini sekadar diberikan kepada seseorang.

Cara menyusun operational level agreement, langkah demi langkah

Mulailah dari SLA, bukan dari template. Tuliskan apa yang dijanjikan kepada pelanggan, end-to-end, lengkap dengan definisi jamnya.

Petakan rantainya. Setiap tim yang menyentuh permintaan dengan jenis tersebut, secara berurutan, termasuk pihak ketiga mana pun. Gambarkan perpindahan sebagai langkahnya sendiri, bukan sebagai panah.

Untuk setiap perpindahan, ajukan satu pertanyaan kepada tim penerima: apa yang Anda butuhkan dalam tiket agar Anda bisa mulai bekerja tanpa harus kembali kepada kami. Jawaban itu, yang dituliskan, adalah kriteria masuk Anda. Tim menjawab ini dengan mudah dan tepat, dan sebagian besar belum pernah diminta sebelumnya.

Sekarang sepakati waktu, dengan mengikuti perhitungan di atas, bukan per tim. Melakukannya sebagai satu percakapan dengan semua orang yang hadir memakan waktu satu jam dan mencegah masalah penjumlahan sepenuhnya.

Alokasikan transit secara eksplisit dan tentukan siapa yang memilikinya. Lima belas menit per perpindahan adalah titik awal yang masuk akal dan sebaiknya dihitung terhadap tim penerima.

Sepakati pengukuran, termasuk bounce rate, dan dari mana asalnya. Jika alat Anda tidak bisa menghasilkannya, itu penting untuk diketahui sebelum Anda menandatangani, bukan saat peninjauan pertama.

Lalu jalankan selama satu kuartal sebelum memformalkan. Versi pertama biasanya salah di satu atau dua tempat, dan lebih mudah memperbaikinya sebelum tanda tangan ada.

Kesalahan OLA yang umum dan biaya dari masing-masing

Mengukur tim dan bukan rantainya. Semua orang hijau dan SLA dilanggar. Ini adalah kegagalan paling umum dan topik halaman ini.

Tidak ada kriteria masuk. Bouncing menjadi pembelaan rasional tim penerima, dan waktu yang berlalu membesar secara tidak terlihat.

Waktu yang tidak dijumlahkan. Setelan OLA menjamin pelanggaran dan tidak pernah ada yang menjumlahkannya.

Jam layanan yang tidak cocok. Satu tim mencakup sampai jam enam, tim berikutnya sampai jam lima. Semua yang masuk setelah jam lima menginap semalaman, yang tidak ditunjukkan oleh laporan mana pun karena kedua tim masih berada dalam jam layanan mereka.

Menyalin bahasa SLA ke dalam OLA. Penalti, kredit, dan redaksi hukum tidak cocok di sini, dan mengimpor semuanya membuat tim bernegosiasi secara defensif alih-alih jujur.

Menulis OLA dengan pihak ketiga. Jika uang berpindah tangan, itu adalah underpinning contract dan perlu keterlibatan procurement serta legal, bukan template. IT procurement policy template kami mencakup jalur persetujuannya.

Menandatangani dan mengarsipkan. OLA yang tidak ditinjau oleh siapa pun menggambarkan rantai layanan yang tidak lagi ada dalam waktu sekitar satu tahun.

Cara mengelola dan meninjau OLA setelah tersedia

Laporkan rantainya, bukan komponennya. Satu angka yang penting, yaitu performa end-to-end terhadap SLA, dan metrik OLA ada untuk menjelaskannya, bukan berdiri sendiri.

Tinjau setiap kuartal, dengan semua pihak berada di ruangan yang sama. Peninjauan bilateral mereproduksi masalah awal, karena celah berada di antara pihak-pihak yang tidak pernah berada dalam percakapan yang sama.

Perhatikan tiga hal. Bounce rate berdasarkan perpindahan, yang memberi tahu Anda di mana kriteria masuk perlu diperbaiki. Waktu transit berdasarkan perpindahan, yang memberi tahu Anda di mana antrean mulai terbentuk. Dan proporsi insiden yang melewati jalur yang tidak dijelaskan oleh OLA, yang memberi tahu Anda dokumen telah bergeser dari kenyataan.

Lakukan peninjauan di luar siklus saat sebuah tim melakukan reorganisasi, saat sebuah sistem berpindah antar tim, saat pihak ketiga baru masuk ke rantai, atau saat SLA yang mendasarinya berubah. Keempat hal ini terjadi lebih sering daripada yang diasumsikan oleh siklus peninjauan tahunan.

OLA, SLA, atau underpinning contract: yang mana yang Anda butuhkan?

Jika komitmennya ditujukan kepada pihak di luar organisasi pengantaran Anda, baik pelanggan eksternal maupun unit bisnis internal yang dilayani, maka itu adalah SLA.

Jika komitmennya berada di antara dua tim di dalam organisasi yang sama tanpa ada uang yang berpindah tangan, maka itu adalah OLA.

Jika komitmennya adalah dengan pemasok dalam pengaturan komersial, maka itu adalah underpinning contract dan memerlukan legal serta procurement, bukan template ini.

Kasus yang canggung adalah shared service centre atau tim internal dengan model chargeback, yang berada di antara OLA dan SLA. Jawaban praktisnya adalah menuliskannya sebagai OLA dan menghapus bahasa apa pun tentang penalti, karena rezim penalti internal secara andal menghasilkan perilaku defensif dan layanan yang lebih buruk.

Untuk definisi yang menghadap pelanggan dan redaksi respons yang berada di atas semuanya, help desk response template dan ticket and resolution template kami mencakup lapisan yang benar-benar dilihat oleh pengguna akhir.

Bisakah saya mendapatkan template OLA dalam Word atau Excel?

Word untuk perjanjian, karena ruang lingkup, pengecualian, dan bagian peninjauan adalah paragraf, dan dokumen diedarkan untuk persetujuan tanda tangan.

Excel untuk dua bagian secara spesifik. Tabel komitmen, tempat Anda ingin kriteria masuk, waktu, dan alokasi transit dalam kolom yang bisa diurutkan dan dicek. Dan lembar aritmetika, tempat setiap rantai dijumlahkan terhadap SLA dan menandai apa pun yang tidak memiliki headroom. Lembar kedua itulah yang layak dibuat terlebih dahulu, karena sering kali mengubah apa yang sebelumnya akan Anda sepakati.

PDF untuk versi yang ditandatangani, diekspor dari sumbernya. Pertahankan versi kerja agar bisa diedit, karena kriteria masuk perlu disesuaikan setelah kuartal pertama dari bounce yang benar-benar terjadi.

Cara menjaga OLA dan kenyataan tetap selaras

OLA mendeskripsikan rantai pekerjaan yang berubah terus-menerus. Tim melakukan reorganisasi, sistem berpindah, alat berubah, dan dokumen adalah hal terakhir yang diperbarui siapa pun.

Bagian yang paling cepat menjadi usang adalah kriteria masuk, karena bagian itu menjelaskan apa yang harus dimuat dalam tiket, dan apa yang harus dimuat dalam tiket bergantung pada bagaimana alat dan proses saat ini benar-benar bekerja.

Trupeer AI membantu dengan membuat prosedur yang mendasarinya murah untuk tetap diperbarui. Rekam proses triase atau perpindahan sekali, lalu Anda mendapatkan prosedur tertulis dengan langkah dan layar yang ditangkap, yang bisa diikuti help desk dan menunjukkan dengan jelas informasi apa yang dikumpulkan. Saat alat berubah, rekam ulang, bukan menulis ulang.

Rekam. Branding. Terjemahkan. Trupeer-kan.

SOP creator mencakup prosedur yang menjadi dasar OLA, dan IT SOP template kami mencakup cara memutuskan mana yang layak dipelihara. Documentation menjaga kesepakatan dan prosedur tetap bersama, dan instruksi penyiapannya ada di document template setup guide.

Pertanyaan yang Sering Diajukan

Apakah ada template perjanjian tingkat operasional gratis dalam Word?

Struktur di atas langsung ditempel ke Word atau Google Docs, termasuk kolom kriteria masuk dan alokasi transit yang biasanya dihilangkan oleh template standar. Tidak ada unduhan yang dibatasi dan tidak ada formulir. Simpan tabel komitmen di spreadsheet dan jadikan referensi, karena bagian itu perlu diurutkan dan dijumlahkan.

Apakah ada template perjanjian tingkat operasional gratis dalam PDF?

Ekspor versi yang ditandatangani ke PDF setelah para pihak menyetujuinya, dan pertahankan salinan kerja agar bisa diedit. Kriteria masuk hampir selalu perlu disesuaikan setelah kuartal pertama, saat Anda bisa melihat tiket yang sebenarnya dibounce.

Apakah ada template perjanjian tingkat operasional gratis dalam Excel?

Excel adalah tempat yang tepat untuk tabel komitmen dan pengecekan aritmetika. Satu lembar dengan satu baris per perpindahan dan total berjalan terhadap SLA, yang menandai setiap rantai dengan headroom kurang dari sepuluh persen. Membuat lembar itu sebelum negosiasi cenderung mengubah apa yang dinegosiasikan.

Di mana saya bisa menemukan contoh PDF perjanjian tingkat operasional?

Beberapa vendor ITSM dan badan pemerintah mempublikasikan template OLA dan SLA sebagai dokumen, dan strukturnya masuk akal. Bacalah untuk bagian-bagiannya, bukan untuk kontennya, karena komitmen dalam contoh apa pun yang dipublikasikan adalah rantai milik orang lain, dan waktunya tidak berarti di luar SLA yang dibuat untuk mendukungnya.

Siapa yang menandatangani operational level agreement?

Pemilik yang disebutkan di setiap sisi, yang seharusnya menjadi manajer yang bertanggung jawab atas pengantaran tim tersebut, bukan fungsi manajemen layanan. OLA yang ditandatangani hanya oleh manajemen layanan adalah sebuah aspirasi, karena orang yang harus menyediakan sumber daya untuk itu tidak ada di ruangan.

Berapa banyak OLA yang dibutuhkan help desk?

Lebih sedikit daripada yang diperkirakan sebagian besar tim. Satu per pasangan tim yang secara rutin saling bertukar pekerjaan, mencakup semua jenis permintaan dalam satu tabel komitmen, bukan satu per layanan. Setelah sekitar selusin, pemeliharaan menjadi kendala dan dokumen cepat menjadi usang dibandingkan saat ditinjau.

Apakah operational level agreement harus memiliki penalti?

Tidak. Tidak ada hubungan hukum untuk menegakkannya, dan rezim penalti internal secara andal menghasilkan perilaku defensif: tim menolak pekerjaan, memperdebatkan kapan jam mulai berjalan, dan mengoptimalkan angka mereka sendiri alih-alih hasilnya. Laporkan rantai end-to-end sebagai gantinya, sehingga konsekuensi bersama terlihat tanpa siapa pun harus didenda.

Seberapa sering OLA harus ditinjau?

Setiap kuartal dengan semua pihak hadir, plus peninjauan di luar siklus setiap kali sebuah tim melakukan reorganisasi, sebuah sistem berpindah antar tim, pihak ketiga masuk ke rantai, atau SLA yang mendasarinya berubah. Ritme kuartalan menangkap pergeseran, dan pemicunya menangkap perubahan yang membuat dokumen salah dalam semalam.