SLA’lar müşterilere verilen sözlerdir; OLA’lar ise bu sözleri iç ekiplerinizin yerine getirebilmesini sağlar. Trupeer ile ücretsiz bir operasyonel seviye anlaşması (OLA) şablonuyla başlayarak OLA yazma işinde saatler kazanabilir, bunu marka yönergeleriniz ile özelleştirebilir ve OLA’yı, tüm iç ekipleri ortak hizmet standartlarında aynı hizaya getiren bir video anlatımına dönüştürebilirsiniz.

Operasyonel seviye anlaşması şablonu nedir?

Operasyonel seviye anlaşması ya da OLA, aynı organizasyon içindeki ekipler arasında yapılan; organizasyon dışındaki birine verilen taahhüdün temelini oluşturan dahili bir anlaşmadır. Hizmet masası, iş dünyasına büyük olaylarda dört saat içinde çözüm sözü verir. Ancak bu söz, ağ ekibi, uygulamalar ekibi ve zincirdeki diğer herkesin bilinen bir zaman içinde kendi payına düşeni yapmasıyla geçerlidir.

OLA, bu dahili parçaların yazıya döküldüğü yerdir. Bir sözleşme değildir; kimse kimseye ödeme yapmaz ve yaptırım tamamen yönetseldir. Bu hem zayıf yönüdür hem de bir sözleşmenin yapamadığı şekillerde dürüst olabilmesinin nedenidir.

Operasyonel seviye anlaşması şablonu, yeniden kullanılabilir yapıdır: taraflar, kapsanan hizmetler, taahhütler, ölçümler ve gözden geçirme düzenlemeleri. Bu şablonları bulmak kolaydır. Çoğu, OLA’nızı tamamen uyumlu yazmanıza rağmen yine de başarısız olabilecek bir OLA oluşturmanıza izin verir; bu sayfanın geri kalanı da bununla ilgilidir.

OLA vs SLA: her biri gerçekte neye taahhüt eder

Bu ailede üç doküman vardır ve karıştırmak ciddi sorunlara yol açar.

Bir hizmet seviyesi anlaşması, müşteri ya da iş dünyasına verilen taahhüttür. Müşterinin diliyle yazılır; genellikle uçtan uca ve teslimat zincirinin dışındaki kişilere raporlanan da budur.

Bir operasyonel seviye anlaşması ise dahili bir belgedir; aynı organizasyona rapor veren ekipler arasındadır. Yalnızca SLA’nın gerçekleştirilebilir olmasını sağlamak için vardır ve SLA’nın ihtiyaç duymadığı hiçbir taahhüt içermemelidir.

Bir destekleyici sözleşme, aynı zinciri destekleyen üçüncü tarafla, bir tedarikçiyle ya da dış kaynaklı sağlayıcıyla yapılan ticari anlaşmadır. OLA’nın sahip olmadığı yasal güce sahiptir ve üçü arasında genellikle en az esnekliğe sahiptir; bu nedenle SLA’dan sonra değil, SLA’dan önce kararlaştırılmalıdır.

Pratik sonuç, bir sıralama kuralıdır. Önce destekleyici sözleşmeleri, ardından bu sözleşmelerin izin verdiği ölçüde SLA’yı, sonra da kalan kısmı dolduran OLA’ları kabul edin. Ters sırayla yapan organizasyonlar, tedarikçinin teslim etmeyi kabul etmediği şeyleri iş dünyasına rutin olarak vaat eder.

Bu şablon Trupeer’da nasıl özelleştirilir

Adım 1: Şablonlar Bölümünü Açın

Ana navigasyondan Şablonlar bölümüne gidin.

Adım 2: Bir Şablon Seçin ve Açın

Açmak istediğiniz herhangi bir şablonun üzerine tıklayın.

Adım 3: Şablon Görünümünü Genişletin

Gerekirse, tam düzeni ve ayrıntıları net görmek için şablon görünümünü genişletin.

Adım 4: Şablonu Düzenleyin

Seçili şablonu değiştirmeye başlamak için Düzenle’ye tıklayın.

Düzenleyici içinde şunları yapabilirsiniz:

• Yeni bölümler ekleyin

• Biçimlendirme kurallarını tanımlayın veya güncelleyin

• Bir logo ekleyin ve konumunu ile ilgili ayarları düzenleyin

Adım 5: Özelleştirilmiş Şablonunuzu Kaydedin

Gerekli tüm değişiklikleri yaptıktan sonra, güncellenmiş şablonu kendi şablonunuz olarak saklamak için Kaydet’e tıklayın.

Adım 6: Şablonu Önizleyin ve İnce Ayar Yapın

Özelleştirilmiş şablonunuzun nasıl göründüğünü görmek istediğinizde Önizleme’yi açın.

Önizleme ekranından, gerekirse doğrudan ayarlamaya devam edebilir; şablonun tam olarak istediğiniz gibi göründüğünden emin olabilirsiniz.

Bir operasyonel seviye anlaşması şablonuyla şunları yapabilirsiniz:

• Yazma süresinde saat kazanın: OLA’lar için oluşturulmuş bir yapıyla boş sayfayı atlayın.

• İç ekipleri aynı hizaya getirin: Dahili alanlar, her ekibin sorumluluğunu bilmesini sağlar.

• Markanıza uygun kalın: Trupeer’ın marka kitini kullanarak logonuzu, yazı tiplerinizi ve renklerinizi uygulayın.

• Müşteri SLA’larını koruyun: Güçlü OLA’lar, dahili devir teslimlerin harici vaatleri bozmasını engeller.

• Tüm hizmetlerde standardize edin: Her dahili anlaşma için aynı OLA şablonunu kullanın.

• Küresel ekiplere ulaşın: OLA’ları tek tıklamayla 65+ dile çevirin.

Her ekip OLA’sını tutturuyor ama SLA yine de ihlal ediliyor

Bu, hizmet yönetiminde en yaygın görülen kalıptır ve bir çelişki gibi görünür.

Her ekip yeşil raporlar. Ağ, kendi saatinin içinde yanıt verir. Uygulamalar, kendi iki saatinin içinde çözer. Hizmet masası, otuz dakika içinde önceliklendirir. Aylık OLA uyum raporu okunması rahattır. Ve müşteri SLA’sı, büyük olayların üçte birinde ihlal eder.

Açıklama şudur: OLA’lar ekiplerin içindeki zamanı ölçer; SLA ise uçtan uca zamanı ölçer. Bu iki sayı arasındaki fark, geçiş süresidir: yeniden atamadan sonra bir kuyrukta bekleyen bilet, alınmayı beklerken geçen süre ya da daha fazla bilgi için geri gönderilmesi.

Bu süre kimseye ait değildir. Hiçbir ekibin OLA’sında yer almaz, hiçbir yerde raporlanmaz ve çoğu zaman tüm çalışma süresinin toplamından daha büyüktür.

Bu da başarısızlığın bir performans sorunu değil, yapısal olduğu anlamına gelir. Mevcut sayıları tutturmaları için ekipler üzerinde baskı kurmak işe yaramaz; çünkü onlar zaten tutturuyor.

OLA, işi değil devir teslimi yönetir

Bunu düzelten yeniden çerçeveleme küçük bir değişikliktir ve dokümanın amacını değiştirir.

OLA’nın alışılmış şekilde yazılması, bir ekibi kendi işinin ne kadar sürdüğüne taahhüt eder. Ekiplerin kontrol ettiği kısım budur; bu yüzden imzalamaya istekli oldukları kısım da budur. Değişken hiç olmadığı için de üzerinde anlaşmak en az işe yarayan şeydir.

İyi yazılmış bir OLA ise ekipleri aralarındaki arayüzlere taahhüt eder. Bilet devredilmeden önce biletin içinde ne olmalıdır. Teslim alan ekibin onu almak için ne kadar zamanı vardır. Bilet eksik olduğunda ne olur. Devir teslim boşluğunda biletin sahibi kimdir.

Devir teslim konu olunca, iki eksik alan netleşir. Giriş kriterleri: teslim alan ekibin saatinin başlamasından önce ne doğru olmalıdır. Bir de geçiş süresinin kendisine açık bir atama: böylece ekipler arasındaki boşluk, kimsenin değil birinin sayısı olur.

OLA şablonundaki diğer her şey idari işlemdir. Bu iki alan ise dokümanın kendisidir.

Giriş kriterleri: saat başlamadan önce ne doğru olmalı

Çok ekipli bir zincirde en yıkıcı davranış, geri gönderme (bouncing) davranışıdır: bir bilet yeterli bilgi olmadan gelir, teslim alan ekip geri gönderir ve onların saati sıfırlanır.

Geri gönderme, teslim alan ekibin bakış açısından tamamen rasyoneldir. Bileti çalışamazlar ve uyumları kendi çözüm sürelerine göre ölçülür; bu yüzden geri göndermek hem kendilerini hem de süreci korur. Ayrıca geçen sürenin büyük bir kısmının aktığı yerdir ve ekipleri ayrı ayrı ölçen her raporda görünmez.

Giriş kriterleri, yükümlülüğü yukarı taşıyarak bunu düzeltir. Her OLA satırı, o ekibin işi kabul edebilmesi için doldurulması gereken belirli alanları listeler. Ağ devri için bu; cihaz adı, site kodu, hatanın birebir metni, ilk ne zaman gözlemlendiği ve diğer kullanıcıların etkilenip etkilenmediği olabilir. Uygulama devri için ise kullanıcı, işlem referansı, yeniden üretim adımları ve bir ekran görüntüsü olabilir.

Sonra gönderen ekibin taahhüdünün dili değişir. “Otuz dakika içinde önceliklendir” değil, “Otuz dakika içinde giriş kriterlerini karşılayan bir bileti devret.” Aynı saat, farklı yükümlülük; teşvik artık bilgiyi gerçekten toplayabilen ekibin tarafında olur.

Teslim alan ekip, reddetme hakkını korur ve bu hak dar kapsamlı olmalıdır: reddetme yalnızca belirlenmiş bir giriş kriteri gerçekten eksik olduğunda geçerlidir ve her reddetme gerekçesiyle birlikte kayda geçirilir. Kayıt tutmak, geri göndermeyi görünmez bir alışkanlıktan, birinin açıklamak zorunda olduğu bir sayıya dönüştürür.

Ücretsiz operasyonel seviye anlaşması şablonu: kopyalanacak yapı

Buradan kopyalayın. Asterisk (*) ile işaretlenen alanlar, standart şablonların atladığı alanlardır.

Başlık. OLA referansı ve sürümü. Taraflar; yani isimleriyle iki ekip. Bunu destekleyen SLA veya hizmet. Her iki tarafta da geçerlilik tarihi, gözden geçirme tarihi ve adlandırılmış sahip.

Kapsam. Hangi hizmetler, sistemler veya talep türleri kapsanır ve açıkça nelerin kapsanmadığı.

Hizmet saatleri. Her taraf için kapsama; mesai dışı düzenlemeler ve bunların nasıl farklılaştığı dahil. Aynı zincirdeki iki ekip arasında saatlerin uyuşmaması yaygın bir durumdur ve sessizce ölümcül bir boşluk yaratır.

Taahhütler tablosu. Her talep türü veya öncelik için bir satır: tetikleyici, giriş kriterleri, yanıt süresi, çözüm veya geri iade süresi, tahsis edilen geçiş süresi ve yükseltme noktası.

Yükseltme. Her aşamada kimin iletişime geçileceği, hangi yol üzerinden ve ne kadar süre sonra. Mesai dışı yolu da ekleyin.

Bağımlılıklar. Bu ekibin diğerlerinden ihtiyaç duyduğu şeyler; üçüncü bir tarafla yapılmış herhangi bir destekleyici sözleşme dahil. Hesap kontrol edilebilsin diye kendi zamanları not edilmelidir.

Ölçüm. Ne ölçülür, hangi sistemden, kim tarafından ve ne sıklıkla raporlanır. Yanıt ve çözümün yanında geri gönderme oranını da ekleyin; çünkü giriş kriterlerinin çalışıp çalışmadığını gösteren ölçüt budur.

İstisnalar. Taahhütlerin geçerli olmadığı, örneğin ilan edilmiş büyük bir olay sırasında veya değişiklik dondurma döneminde olduğu gibi üzerinde mutabık kalınmış koşullar.

Gözden geçirme. Tarihler ve döngü dışı gözden geçirmeyi tetikleyen durumlar.

Buraya kadar kopyalayın. İki ya da üç sayfayı geçmeyin. İki kez okunmasını gerektirecek kadar uzun bir OLA, bir olay sırasında danışılmayacaktır; olay sırasında önemli olan da budur.

OLA’ların gerçekten SLA’ya denk gelip gelmediği nasıl kontrol edilir

Herhangi bir şey imzalamadan önce hesabı yapın. On beş dakika sürer ve neredeyse evrensel olarak atlanır; çünkü OLA’lar farklı günlerde farklı ekiplerle tek tek müzakere edilir.

Bunu işe yarar kılan iki kural vardır. Geçiş süresi kendi satırı olarak görünmelidir; çünkü mesele tamamen budur. Ayrıca her zincirin emniyet payına ihtiyacı vardır; çünkü SLA’ya tam olarak toplayan bir zincir, herhangi bir şey biraz bile yanlış giderse ihlal eder. Yüzde on ila on beş arası makul bir paydır.

Toplam SLA’yı aşıyorsa üç dürüst seçeneğiniz vardır: SLA’yı yeniden müzakere etmek, bir ekibin süresini mümkün kılacak bir şeyle azaltmak ya da bir devir teslimi kaldırmak. Yapamayacağınız şey, ihlali garanti eden OLA’ları imzalayıp ardından performansı bunlara göre yönetmektir; hizmet masalarının şaşırtıcı bir kısmının içinde bulunduğu konum budur.

Geçiş süresi işinden daha uzun olan perakendeci

Rendlesham Group, yaklaşık altı bin çalışanla birlikte birkaç perakende markası işletiyor ve mağazaları ile genel merkez için dahili bir BT hizmet masası sağlıyor.

İş dünyasına yönelik P2 olay SLA’sı, çözüm için dört saatti. P2’de ihlal oranı iki yıldır yaklaşık yüzde otuz sekiz civarındaydı. Her ekibin OLA uyumu aylık olarak raporlanıyor ve her ekip yeşildi.

Birisi nihayet, ihlal edilen yüz yirmi P2 olayının her birindeki durum değişikliklerini zaman damgasıyla kaydetti.

Ortalama (medyan) toplam geçen süre altı saat elli bir dakikaydı. Bunun üç saati on iki dakikası, bilet aktif olarak çalışılırken bir ekip içinde geçen süreydi. Üç saat otuz dokuz dakika ise geçişti: yeniden atamadan sonra bir kuyrukta beklemek, alınmayı beklemek ya da geri gönderilmek.

İhlal edilen bir olayda geçen sürenin yarısından fazlası kimseye ait değildi ve hiçbir yerde raporlanmıyordu.

En büyük tek katkı geri göndermeydi. Yüz yirmi biletin kırk biri, teslim alan bir ekip tarafından en az bir kez yetersiz bilgi nedeniyle geri döndürülmüştü ve her geri gönderme, medyan olarak bir saat yirmi dakikalık ek bir süre yaratmanın yanı sıra o ekibin saatini de sıfırlıyordu. En yaygın iki neden; hata metninin ya da ekran görüntüsünün ekli olmaması ve olayın hangi mağazayı etkilediğinin teyit edilmemesiydi.

Değişiklikler sınırlıydı. Giriş kriterleri her OLA satırına yazıldı. Hizmet masası taahhüdü “otuz dakika içinde önceliklendir” ifadesinden “otuz dakika içinde giriş kriterlerini karşılayan bir bileti devret” ifadesine yeniden yazıldı. Her devir teslim için on beş dakikalık geçiş süresi tahsis edildi ve giriş kriterleri karşılandıktan sonra teslim alan ekibe karşı sayıldı. Ayrıca her geri gönderme gerekçesiyle birlikte kayda geçirildi.

İzleyen iki çeyrek boyunca geri gönderme oranı P2’lerde yüzde otuz dörtten dokuza düştü. Medyan geçiş süresi üç saat otuz dokuz dakikadan bir saat altı dakikaya indi. P2 ihlal oranı yüzde otuz sekizden on bir’e düştü.

Hiçbir ekibin dahili çözüm süresi maddi olarak değişmedi. Kimse daha hızlı çalışmadı. Kimseye ait olan süre, sadece birine verildi.

Operasyonel seviye anlaşması nasıl hazırlanır: adım adım

Şablondan değil, SLA’dan başlayın. Müşteriye uçtan uca ne vaat edildiğini, saat tanımıyla birlikte yazın.

Zinciri haritalayın. Bu talep türüne dokunan her ekip, sırayla; varsa üçüncü taraflar dahil. Devir teslimleri oklar olarak değil, kendi adımları olarak çizin.

Her devir teslim için teslim alan ekibe tek bir soru sorun: geri dönmenize gerek kalmadan çalışmaya başlamak için bilete neye ihtiyacınız var? Yazıya dökülen bu yanıt, giriş kriterlerinizdir. Ekipler bu soruyu kolayca ve net biçimde yanıtlar; ancak çoğu ekip bu zamana kadar hiç sorulmamıştır.

Şimdi süreleri, ekip ekip değil yukarıdaki hesap mantığı içinde mutabık hale getirin. Herkesin hazır olduğu tek bir görüşme olarak yapmak, bir saat toplamı sorununu tamamen engeller ve yaklaşık bir saat sürer.

Geçiş süresini açıkça tahsis edin ve kimin sahipliğinde olacağını belirleyin. Devir teslim başına on beş dakika makul bir başlangıç noktasıdır ve giriş kriterleri karşılandıktan sonra teslim alan ekibe karşı sayılmalıdır.

Geri gönderme oranı dahil ölçümü ve bunun nereden geldiğini de mutabık hale getirin. Araçlarınız bunu üretemiyorsa, ilk gözden geçirmeden önce bunu bilmek değerlidir; imzalamadan önce.

Sonra resmileştirmeden önce bir çeyrek boyunca uygulayın. İlk sürümler genellikle bir veya iki yerde yanlıştır ve imzalar atılmadan önce düzeltmek daha kolaydır.

Yaygın OLA hataları ve her birinin maliyeti

Ekipleri ölçmek ama zinciri ölçmemek. Herkes yeşil ve SLA ihlal ediliyor. En yaygın başarısızlık ve bu sayfanın konusu.

Giriş kriterlerinin olmaması. Geri gönderme, teslim alan ekibin rasyonel savunması haline gelir ve geçen süre görünmez şekilde şişer.

Toplamı tutmayan süreler. Belirlenen OLA seti ihlali garanti eder ve bugüne kadar kimse bunu hiç hesaplamamıştır.

Uyuşmayan hizmet saatleri. Bir ekip altıya kadar kapsar, diğeri beşe kadar. Beşten sonra gelen her şey gece boyunca bekler; bunu hiçbir rapor göstermez çünkü iki ekip de kendi saatlerinin içindedir.

SLA dilini bir OLA’ya kopyalamak. Cezalar, krediler ve yasal ifadeler burada yer almaz; bunları içe aktarmak, ekiplerin dürüstçe değil savunmacı şekilde müzakere etmesine yol açar.

Üçüncü tarafla bir OLA yazmak. Para el değiştiriyorsa bu bir destekleyici sözleşmedir ve şablon değil; satın alma ve hukuk dahil edilmelidir. IT procurement policy template onay yolunu kapsar.

İmzalama ve dosyalama. Kimsenin gözden geçirmediği bir OLA, yaklaşık bir yıl içinde artık var olmayan bir hizmet zincirini anlatır.

OLA’lar oluşturulduktan sonra nasıl yönetilir ve gözden geçirilir

Bileşenleri değil zinciri raporlayın. Önemli olan tek bir sayı vardır: SLA’ya karşı uçtan uca performans ve OLA metrikleri bunu tek başına bırakmak için değil açıklamak için vardır.

Üç ayda bir, tüm taraflar aynı odada olacak şekilde gözden geçirin. İki taraflı gözden geçirmeler, orijinal sorunu yeniden üretir; çünkü boşluklar, hiç aynı konuşmada bulunmayan tarafların arasındadır.

Üç şeye dikkat edin. Devir teslim bazında geri gönderme oranı: giriş kriterlerinin nerede çalışması gerektiğini söyler. Devir teslim bazında geçiş süresi: kuyrukların nerede oluştuğunu gösterir. Ayrıca OLA’nın tarif etmediği bir yolu izleyen olayların oranı: dokümanın gerçeklikten uzaklaştığını anlatır.

Bir ekip yeniden organize olduğunda, bir sistem ekipler arasında taşındığında, zincire yeni bir üçüncü taraf girdiğinde veya SLA değiştiğinde döngü dışı bir gözden geçirme tetikleyin. Dördü de yıllık gözden geçirme döngüsünün varsaydığından daha sık gerçekleşir.

OLA, SLA veya destekleyici sözleşme: hangisine ihtiyacınız var?

Taahhüt, teslimat organizasyonunuzun dışındaki birine veriliyorsa; ister harici bir müşteri ister hizmet verilen dahili bir iş birimi olsun, bu bir SLA’dır.

Para el değiştirmeyen, aynı organizasyon içindeki iki ekip arasında ise bu bir OLA’dır.

Ticari bir düzenleme kapsamında bir tedarikçiyle yapılıyorsa bu bir destekleyici sözleşmedir ve bu şablon yerine hukuk ve satın alma gerektirir.

Zor durum, paylaşılan hizmet merkezi ya da chargeback modeline sahip dahili bir ekip gibi; OLA ile SLA arasında konumlanan durumlardır. Pratik cevap, bunu bir OLA olarak yazmak ve cezalarla ilgili herhangi bir dili bırakmaktır; çünkü dahili ceza rejimleri güvenilir biçimde savunmacı davranış üretir ve daha kötü hizmete yol açar.

Tüm bunların üzerine oturan müşteriyle yüz yüze tanımlar ve yanıt metinleri için, help desk response template ve ticket and resolution template uç kullanıcının gerçekten gördüğü katmanı kapsar.

Word veya Excel’de bir OLA şablonu alabilir miyim?

Anlaşma için Word; çünkü kapsam, istisnalar ve gözden geçirme bölümleri metindir ve doküman imza onayı için dolaşıma girer.

Özellikle iki parça için Excel. Taahhütler tablosu: giriş kriterlerini, süreleri ve geçiş tahsisini sıralayıp kontrol edebileceğiniz sütunlarda istediğiniz yerdir. Bir de her zincirin kendi SLA’sına göre toplandığı ve emniyet payı olmayan her şeyi işaretleyen hesaplama sayfası. İkinci sayfa, çoğu zaman müzakere etmeyi düşündüğünüz şeyi değiştirdiği için önce oluşturulmaya değer olan sayfadır.

İmzalanmış sürüm için PDF; kaynağından dışa aktarılır. Çalışan sürümü düzenlenebilir tutun; çünkü ilk çeyrek gerçek geri göndermelerden sonra giriş kriterlerinin ayarlanması gerekecektir.

OLA ile gerçeği nasıl aynı hizada tutarsınız

Bir OLA, sürekli değişen bir iş zincirini tanımlar. Ekipler yeniden organize olur, sistemler taşınır, araçlar değişir ve doküman, kimsenin en son güncellediği şey olur.

En hızlı eskimeye giden kısım giriş kriterleridir; çünkü bir biletin içermesi gerekenleri tanımlarlar ve bir biletin içermesi gerekenler, mevcut araçların ve mevcut sürecin gerçekte nasıl çalıştığına bağlıdır.

Trupeer AI, altta yatan prosedürleri güncel tutmayı ucuz hale getirerek yardımcı olur. Önceliklendirme ya da devir teslim sürecini bir kez kaydedin; adımlar ve ekranlar yakalanmış şekilde yazılı bir prosedür elde edin. Hizmet masası bunu takip edebilir ve hangi bilgilerin toplandığı açıkça görünür. Araçlar değiştiğinde yeniden yazmak yerine yeniden kaydedin.

Kaydedin. Markalayın. Çevirin. Trupeer’layın.

SOP creator, OLA’nın dayandığı prosedürleri kapsar ve IT SOP template, hangilerinin sürdürülmeye değer olduğuna nasıl karar verileceğini kapsar. Documentation, anlaşmaları ve prosedürleri birlikte tutar; kurulum talimatları ise document template setup guide içinde yer alır.

Sık Sorulan Sorular

Word’de ücretsiz bir operasyonel seviye anlaşması şablonu var mı?

Yukarıdaki yapı, giriş kriterleri ve standart şablonların atladığı geçiş tahsisi alanları dahil olmak üzere doğrudan Word veya Google Docs’a yapıştırılır. Kilitli bir indirme yoktur ve form da yoktur. Taahhütler tablosunu bir elektronik tabloda tutun ve ona referans verin; çünkü bu kısmın sıralanması ve toplanması gerekir.

PDF’de ücretsiz bir operasyonel seviye anlaşması şablonu var mı?

Taraflar üzerinde anlaştıktan sonra imzalanmış sürümü bir kez PDF’ye dışa aktarın ve çalışan kopyayı düzenlenebilir tutun. Giriş kriterleri neredeyse her zaman ilk çeyrekten sonra, biletlerin gerçekte hangi gerekçeyle geri gönderildiğini görebildiğiniz anda güncellenmeye ihtiyaç duyar.

Excel’de ücretsiz bir operasyonel seviye anlaşması şablonu var mı?

Excel, taahhütler tablosu ve hesaplama kontrolü için doğru yerdir. Her devir teslim için bir satır ve SLA’ya karşı kümülatif toplam; emniyet payı yüzde ondan az olan herhangi bir zinciri işaretler. Bu sayfayı müzakere etmeden önce oluşturmak, genellikle müzakere edilecek şeyi de değiştirir.

Operasyonel seviye anlaşması PDF örneğini nerede bulabilirim?

Birçok ITSM sağlayıcısı ve kamu kurumu, doküman olarak OLA ve SLA şablonlarını yayımlar ve yapı açısından makuldür. Herhangi bir yayımlanmış örnekteki taahhütlerin başka birinin zinciri olduğunu ve sürelerin, desteklemek için oluşturuldukları SLA dışında anlamsız kaldığını düşündüğünüz için içerikten ziyade bölümler için okuyun.

Operasyonel seviye anlaşmasını kim imzalar?

Her iki tarafta da adlandırılmış sahip; bu, bir hizmet yönetimi fonksiyonu değil, o ekibin teslimatından sorumlu tutulması gereken yöneticiniz olmalıdır. Yalnızca hizmet yönetimi tarafından imzalanan bir OLA, bir niyettir; çünkü onu kaynaklayacak kişi odada yoktur.

Bir hizmet masası kaç tane OLA’ya ihtiyaç duyar?

Çoğu ekibin beklediğinden daha az. Düzenli olarak iş alışverişi yapan her ekip çifti için bir tane; hizmet başına bir tane değil. Tüm talep türlerini tek bir taahhütler tablosunda kapsayacak şekilde. Yaklaşık bir düzineden sonra bakım kısıt haline gelir ve dokümanlar, gözden geçirilmelerinden daha hızlı güncelliğini yitirir.

Bir operasyonel seviye anlaşmasında cezalar olmalı mı?

Hayır. Uygulanmasını sağlayacak yasal bir ilişki yoktur ve dahili ceza rejimleri güvenilir biçimde savunmacı davranış üretir: ekipler işi reddeder, saat başlangıcı konusunda tartışır ve sonucu değil kendi sayısını optimize eder. Bunun yerine zinciri uçtan uca raporlayın; bu, kimseye ceza kesmeden ortak sonucu görünür kılar.

OLA’lar ne sıklıkla gözden geçirilmeli?

Üç ayda bir, tüm taraflar hazır olacak şekilde; ayrıca bir ekip yeniden organize olduğunda, bir sistem ekipler arasında taşındığında, zincire üçüncü bir taraf girdiğinde veya temel SLA değiştiğinde döngü dışı bir gözden geçirme yapılmalıdır. Üç aylık ritim, dokümandaki kaymayı yakalar ve tetikleyiciler, dokümanı bir gecede yanlış hale getiren değişiklikleri yakalar.