Hizmet kataloğu oluşturma ve talep karşılama sürecini tasarlama
Beceri rehberi

Hizmet kataloğu oluşturma ve talep karşılama sürecini tasarlama

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 5 dk okuma

BT hizmet kataloğu nasıl kurulur? Katalog kalemlerinin tanımı, talep formu, onay akışı, teslim süreci ve kataloğun yaşam döngüsü adım adım.

Hizmet kataloğu nedir, neden gerekir?

Hizmet kataloğu, bir BT biriminin kullanıcılara sunduğu hizmetlerin ve kullanıcının talep edebileceği kalemlerin düzenli bir listesidir. Kullanıcı "yeni bir bilgisayar istiyorum", "bir uygulamaya erişim lazım" ya da "e-posta grubu açılsın" gibi ihtiyaçlarını bu katalogdan seçerek ve hazır bir form doldurarak iletir. Katalog, talebin kime gideceğini, hangi bilgilerin gerektiğini ve ne kadar sürede karşılanacağını baştan tanımlar.

Katalog olmayan kurumlarda talepler e-posta, telefon ve sözlü iletişimle gelir; eksik bilgiyle açılır, farklı kişilere yönlenir ve süreleri kimse bilmez. Katalogla birlikte aynı türdeki talepler standart bir yoldan işler, ölçülebilir hale gelir ve otomasyona açılır. Burada talep karşılama (service request fulfillment), olay yönetiminden ayrılır: olay bir şeyin bozulduğunu, talep ise standart bir şeyin istendiğini anlatır.

Hizmet portföyü ile katalog arasındaki fark

Portföy, kurumun sunduğu ve sunmayı planladığı tüm hizmetleri içerir; yönetimsel bir bakıştır. Katalog ise portföyün kullanıcıya açık, talep edilebilir kısmıdır. Her hizmet katalogda görünmez: dahili süreçler ya da geliştirme aşamasındaki hizmetler portföyde yer alır ama katalogda yer almaz.

Bu ayrım kataloğu oluştururken şu soruyu sordurur: kullanıcı bunu doğrudan talep edebilir mi? Evet ise katalogda kalemdir. Kataloğu portföyle uyumlu tutmak da önemlidir: katalogdaki her kalemin arkasında bir hizmet, bir sahip ve bir destek yapısı bulunmalıdır. Hizmeti sunmayan bir kalem katalogda bırakılmamalıdır; kullanıcı güveni hızla kaybolur.

Katalog kalemi nasıl tanımlanır?

İyi tanımlı bir katalog kalemi kullanıcının dilinde yazılır ve şu alanları içerir: • Ad ve kısa açıklama: teknik jargonsuz, ne talep edildiğini anlatan. • Kimler talep edebilir: rol, departman ya da konum kısıtı. • Gerekli bilgiler: talep formunda toplanacak alanlar. • Onay gereksinimi: kimin onayladığı ve hangi koşulda. • Teslim sorumlusu ve süre taahhüdü: hangi ekip karşılar, hedef süre nedir. • Maliyet bilgisi: varsa kullanıcıya ya da bütçe sahibine yansıyacak bedel.

Kalemleri gruplandırırken kullanıcının nasıl düşündüğüne bakın: "donanım", "yazılım ve erişim", "hesap yönetimi" gibi kategoriler, BT organizasyon şemasından daha anlaşılırdır. Çok fazla kalem kataloğu kullanılmaz hale getirir; benzer taleplerin tek bir kalemde seçeneklerle toplanması çoğu zaman daha iyidir.

Örneğin "yazılım erişimi" adlı tek bir kalem, kullanıcının listeden uygulamayı seçmesiyle çalışabilir. Form seçilen uygulamaya göre gerekçe, kullanım süresi ya da yönetici onayı alanlarını gösterir. Böylece yüzlerce ayrı kalem yerine bakımı kolay tek bir tanım elde edilir. Kalem yazarken kullanıcıların arama kutusuna yazacağı sözcükleri de düşünün; "VPN" ya da "şifre sıfırlama" gibi gündelik ifadeler açıklamada ve anahtar sözcüklerde geçmelidir.

Talep formu ve onay akışı tasarımı

Talep formu, doğru bilgiyi ilk seferde almak için tasarlanır. Her alan bir karara ya da işleme hizmet etmelidir; kimsenin okumadığı alan hem kullanıcıyı yorar hem de form tamamlanma oranını düşürür.

Form tasarımında şu ilkeler yardımcıdır: • Zorunlu ve isteğe bağlı alanları net ayırın; zorunluları minimumda tutun. • Seçim listeleri ve koşullu alanlar kullanın: kullanıcı "laptop" seçince yalnız donanıma ait sorular çıksın. • Kullanıcının bilgisi otomatik gelsin (ad, departman, yönetici). • Alan açıklamaları kısa ve somut olsun.

Onay akışında ise kimin neyi onaylayacağı baştan belirlenir. Düşük riskli talepler (standart bir yazılımın kurulumu) otomatik onaylanabilir; yüksek maliyetli ya da yetki gerektiren talepler yönetici ya da bütçe sahibinden onay alır. Onaycı yokluğunda vekâlet ve zaman aşımı kuralları tanımlanmalı; aksi halde talepler onay kuyruğunda bekler.

Teslim akışı: görev atama ve süre taahhütleri

Onaydan sonra talep, teslimi gerçekleştirecek ekibe görevler halinde dağıtılır. Basit taleplerde tek bir görev yeterlidir; karmaşık taleplerde (örneğin yeni çalışan hazırlığı) birden fazla ekibin sırayla ya da paralel yaptığı görevler bir araya gelir. Her görevin sorumlusu, hedef süresi ve bağımlılığı tanımlanır.

Örnek bir yeni çalışan talebi: insan kaynakları talebi açar, BT hesap oluşturur, donanım ekibi cihaz hazırlar, uygulama sahipleri erişim verir. Bu görevler tek bir talep altında izlenir ve kullanıcı hangi adımda olduğunu görür.

Süre taahhütleri gerçekçi olmalı. Hedef sürenin tutturulamadığı durumlarda uyarı ve yükseltme (escalation) kuralları işlemelidir. Teslimden sonra kullanıcıya bilgi verilmesi ve talebin kapatılması için onayının alınması süreci tamamlar.

Otomasyon, ölçüm ve katalog yaşam döngüsü

Katalog yayına alındıktan sonra bakım gerektirir. Tekrarlayan ve kuralı net talepler otomasyona alınabilir: hesap oluşturma, yetki verme, standart yazılım kurulumu. Otomasyon süreyi kısaltır ve hatayı azaltır; ancak her otomasyon için bir hata durumu planı olmalıdır.

Ölçüm için şu göstergelere bakın: talep türüne göre ortalama teslim süresi, süre taahhüdünü tutturma oranı, kullanıcı memnuniyeti geri bildirimi, en çok talep edilen kalemler, iptal ya da geri çevrilen talepler. Çok talep edilen kalemler otomasyon adayıdır; hiç talep edilmeyenler katalogdan kaldırılmaya adaydır. Sık geri çevrilen kalemde ise formun ya da tanımın belirsiz olduğu anlaşılır.

Yaşam döngüsü yönetimi için kalem sahibi atayın, düzenli gözden geçirme takvimi kurun, değişiklikleri sürümleyin ve yeni hizmet önerilerini bir giriş sürecinden geçirin.

Bu beceri Mindset programlarında nerede çalışılır?

Hizmet Kataloğu Tasarımı ve Talep Karşılama Süreçleri programı, BT hizmet yönetimi, servis masası ve süreç sahibi rollerinde çalışanlara yöneliktir. Programın hizmet portföyü ve katalog ilişkisi, katalog yapısı ve kalem tanımları, talep formu tasarımı, onay akışları ve yetkilendirme, teslim akışları ve süre taahhütleri ile otomasyon ve katalog yaşam döngüsü başlıkları bu sayfadaki akışı tamamlar.

Katalogu bir hizmet yönetimi platformunda uygulamak isteyen ekipler için ServiceNow ile BT Hizmet Süreçlerinin Uygulanması programında hizmet kataloğu ve talep yönetimi modülü ayrıca ele alınır.

İlgili Mindset programı

Hizmet Kataloğu Tasarımı ve Talep Karşılama Süreçleri

Sık sorulanlar

Sık sorulan sorular

Hizmet kataloğu ile hizmet portföyü aynı şey mi?

Hayır. Portföy kurumun sunduğu ve planladığı tüm hizmetleri kapsayan yönetimsel bir listedir. Katalog ise bunların kullanıcıya açık, talep edilebilir kısmıdır. Her hizmet katalogda yer almaz, ama katalogdaki her kalemin portföyde bir karşılığı olmalıdır.

Katalogda kaç kalem olmalı?

Sabit bir sayı yoktur. Önemli olan kullanıcının aradığını kolay bulmasıdır. En sık istenen taleplerle başlayıp zamanla genişletmek, baştan yüzlerce kalem açmaktan daha sağlıklıdır; benzer talepleri tek kalemde seçeneklerle toplamak sade bir katalog sağlar.

Talep karşılama ile olay yönetimi nasıl ayrılır?

Olay, bir hizmetin beklenmedik biçimde kesilmesi ya da kalitesinin düşmesidir, hızlı onarım ister. Talep ise standart ve planlı bir şeyin istenmesidir ve katalog üzerinden onay ve teslim akışıyla ilerler. İkisi ayrı süreçlerdir ve farklı ölçülür.

Kataloğu hangi kalemle başlatmalıyım?

Sık tekrarlanan, kuralı net ve ekibin zaten iyi bildiği taleplerle başlayın: hesap ve erişim talepleri, standart donanım ya da yazılım istekleri. Böylece hızlı kazanım elde eder, kullanıcı geri bildirimiyle formu iyileştirir ve sonra karmaşık taleplere geçersiniz.

BT Hizmet Kataloğu Nasıl Oluşturulur ve Yönetilir