Jira Service Management ile hizmet masası kurmak: portal, istek türü, kuyruk ve SLA

Hizmet masasını araçta kurmak ne demektir?

Jira Service Management (JSM), BT ve diğer destek ekiplerinin talepleri tek bir yerden almasını, sınıflamasını ve çözmesini sağlayan Atlassian ürünüdür. Kurulum, ürünü açıp birkaç ayar yapmaktan ibaret değildir; ekibin hangi taleplere hangi sürede cevap vereceğine dair kararların araca yazılmasıdır. Önce bu kararlar verilmezse araç boş bir yapı olarak kalır.

Hizmet masasının kavramsal tarafı (olay ile hizmet talebi ayrımı, kademeli destek) ayrı bir sözlük sayfasında, hizmet kataloğu tasarımı ise ayrı bir beceri sayfasında anlatılır. Burada odak, bu kararların JSM içinde hangi yapı taşlarına karşılık geldiğidir: müşteri portalı, istek türleri, kuyruklar ve SLA'lar.

Temel mantık şudur: müşteri portaldan bir istek türü seçer, form doldurur; istek bir kuyruğa düşer; ajan kuyruktan alıp çözerken SLA saati işler. Kurulumun kalitesi bu zincirin her halkasının tutarlı olmasına bağlıdır.

İstek türleri: müşteriden doğru bilgiyi almak

İstek türleri, müşterilerin açabileceği taleplerin kategorileridir: "BT yardımı al", "Yeni hesap iste", "Erişim talep et" gibi. Her istek türünün özelleştirilebilir alanları vardır; bu alanlar müşterinin hangi bilgiyi vereceğini belirler. İyi bir istek türü, ajanın ilk sorusunu müşteriye sormak zorunda kalmadan çözmesine yetecek bilgiyi form aşamasında toplar.

Başlangıçta az sayıda, müşterinin dilinde adlandırılmış istek türü kurmak çoğu zaman doğrudur. "Sınıf B sorunu" gibi iç jargon portalda anlamsızdır. İstek türleri portal gruplarına ayrılarak müşterinin aradığını bulması kolaylaştırılır: erişim, donanım, yazılım gibi.

Her istek türü tek bir iş türüne (work type) bağlanır; yani formun arkasındaki iş akışı ve alanlar o iş türünden gelir. Bu yüzden istek türü eklemek önce iş akışını düşünmeyi gerektirir. Aynı akışı paylaşabilen birkaç istek türü bakımı kolaylaştırır; her istek için ayrı akış kurmak yönetilemez bir yapıya götürür.

Hizmet kataloğunuz varsa istek türleri onun portaldaki karşılığıdır. Katalogda olmayan bir hizmet için istek türü açmak, ilerde sahipsiz formlar biriktirir.

Müşteri portalı: ilk izlenim burada oluşur

Portal, müşterinin talep açtığı ve açık taleplerini izlediği yüzdür. Burada iki ölçüt öne çıkar: müşteri ne istediğini hızlıca bulabilmeli ve form kısa olmalı. Gereksiz zorunlu alan, müşteriyi talebi e-postayla göndermeye iter ve kuruluma duyulan güveni zedeler.

Portalın adı, açıklaması ve istek türü grupları müşterinin diliyle yazılmalıdır. Hangi taleplerin portaldan, hangilerinin başka kanaldan karşılanacağı da açıkça belirtilmelidir. Acil kesintiler için telefon gibi ayrı bir kanal gerekiyorsa portalda görünür bir yerde yazılı olmalıdır.

JSM, bir Confluence bilgi tabanıyla bağlanabilir; böylece müşteri talep açmadan önce ilgili makaleleri görebilir. Tekrarlayan soruların bilgi tabanına dönüştürülmesi, talep hacmini azaltmanın en kalıcı yollarındandır.

Portalı yayına almadan önce bir iç kullanıcıyla uçtan uca deneyin: talep açın, kuyrukta görün, yanıtlayın ve portaldan geri okuyun. Eksikler genellikle bu denemede çıkar.

Kuyruklar: ajanların iş listesi

Kuyruk, gelen talepleri ölçütlere göre süzen ve ajanlara odaklı bir görünüm sunan listedir. Bir kuyruk oluştururken adı, hangi taleplerin içine gireceği ve hangi sütunların görüneceği seçilir. Süzme ölçütü genellikle Jira sorgu dili (JQL) ile yazılır; bu nedenle JQL bilgisi kuyruk tasarımının asıl gücüdür. Kuyrukları öncelik gruplarına ayırmak da mümkündür.

İyi bir kuyruk yapısı ajanın sabah "önce neye bakacağım" sorusunu ortadan kaldırır. Yaygın bir düzen şöyledir: atanmamış talepler, SLA ihlaline yaklaşanlar, müşteriden yanıt bekleyenler ve bana atananlar. Kuyrukların sıralaması çoğu zaman SLA'ya göre yapılır; talebin üzerindeki saat, bir sonraki hedefe kalan süreyi gösterir.

Kuyruk sayısı büyüdükçe bakım zorlaşır ve ajanlar nereye bakacağını şaşırır. Ayrıca her kuyruğun sorgusu çalışma maliyeti taşır; çok karmaşık sorgular yavaşlık doğurabilir. Az sayıda, net amaçlı kuyrukla başlamak ve ihtiyaç doğdukça eklemek daha sağlıklıdır.

SLA'lar: sözü ölçülebilir hale getirmek

JSM'de SLA, ekibin müşteri taleplerine ne kadar sürede yanıt verdiğini ve çözdüğünü ölçer. En yaygın iki örnek ilk yanıt süresi ve çözüm süresidir. Her SLA için bir hedef (goal), bir takvim ve saatin ne zaman başlayıp durduğunu belirleyen koşullar tanımlanır. Takvim iş saatlerini ve tatilleri içerir; hesaplama SLA takviminin saat dilimine göre yapılır.

Saatin müşteriden yanıt beklerken durması gibi kurallar kritik önemdedir. Bu kural olmazsa ekip, kontrol edemediği bir bekleme yüzünden hedefi kaçırmış görünür. Hedefler öncelik düzeyine göre farklılaştırılabilir: kritik bir talebin hedefi, düşük öncelikli bir talebinkinden kısa olur.

SLA hedeflerini araca girmeden önce hizmet sahipleriyle konuşmak gerekir. Aracın hedefi sizin yerinize belirlemesi mümkün değildir; yazdığınız süreleri ekip fiilen karşılayabilmelidir. Kuyruklarda ve taleplerin üzerinde SLA saati renklenir ve ihlal olunca işaretlenir; bu görünürlük, yönetimin ihlalleri konuşmasının zeminidir.

SLA, OLA ve destek sözleşmeleri arasındaki ilişki ayrı bir beceri sayfasında ele alınır; burada yalnız aracın içindeki kurulum anlatılmıştır.

Adım adım kurulum sırası

Önce hizmetleri ve ekipleri tanımlayın: hangi talepleri kim karşılıyor? Ardından en çok kullanılacak birkaç istek türünü ve bu türlerin ihtiyaç duyduğu alanları belirleyin. İş akışını mümkün olduğunca sade tutun; yeni durum eklemek her zaman yeni bakım yükü demektir.

Sonra kuyrukları kurun, ajanları ekleyin ve izinleri verin. SLA'ları en sona bırakmak yerine, kuyruklar çalışmaya başlar başlamaz tanımlayın; çünkü ilk dönemde ölçülen gerçek süreler, hedefleri gerçekçi yazmanızı sağlar. Bildirimler, otomasyon kuralları ve bilgi tabanı bağlantısı sonraki iterasyonlarda eklenir.

Pilot olarak bir ekiple başlayıp geri bildirim toplamak, tüm şirkete aynı anda açmaktan çok daha güvenlidir. Pilot sırasında müşterilerin hangi istek türlerini yanlış seçtiğine bakmak, portal tasarımını düzeltmenin en değerli kaynağıdır.

Sık yapılan hatalar

En sık hata, çok sayıda istek türü açmaktır. Müşteri hangisini seçeceğini bilemez, yanlış türle açılan talepler kuyruklar arasında dolaşır. İkinci hata, SLA hedeflerini gerçeklikten bağımsız yazmaktır; sürekli ihlal gören bir SLA hızla anlamını yitirir.

Üçüncü hata, müşteriden yanıt beklerken saatin durmasını tanımlamamaktır. Dördüncü hata, kuyruk ve izinleri sonradan eklemek; herkesin her talebi gördüğü bir kurulum hem gizlilik hem düzen sorunu yaratır. Beşinci hata ise kurulumu bir kez yapıp bırakmaktır: istek türlerinin kullanım sıklığına ve SLA ihlal nedenlerine düzenli bakılmalıdır.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Jira Eğitimi: Temel ve İleri Uygulama programındaki proje kurulumu ve yapılandırma, terminoloji ve durum geçişleri ile gösterge panoları başlıkları, JSM kurulumunun dayandığı iş akışı ve yapılandırma mantığını sağlar. ITIL 4 Foundation eğitimi ise talep, olay ve hizmet masası kavramlarını çerçeveleyerek kurulum kararlarının neden alındığını açıklar. Hizmet masası kuracak BT ekipleri ve Jira yöneticileri için iki programın birlikte değerlendirilmesi anlamlıdır.

Araç arayüzü sık değiştiği için JSM'e özgü menü adlarını uygulama sırasında Atlassian belgelerinden teyit etmek gerekir.