Birçok şirkette IT desteği hâlâ şöyle işler: kullanıcı e-posta atar, telefon eder ya da koridorda yakalar; IT ekibinden biri “hallederim” der. İş küçükken bu yöntem yeterli görünür. Ama kullanıcı sayısı arttıkça aynı sorular tekrar tekrar gelir, bazı talepler unutulur ve “IT ekibi ne iş yapıyor?” sorusuna kimse rakamla cevap veremez. IT talep yönetimi, bu dağınık akışı kayıtlı, önceliklendirilmiş ve ölçülebilir bir sürece dönüştürmektir.
IT talep yönetimi nedir?
IT talep yönetimi, çalışanlardan gelen her türlü bilgi teknolojisi isteğinin (arıza bildirimi, yetki talebi, donanım ihtiyacı, yazılım kurulumu vb.) tanımlı bir kanaldan alınması, sınıflandırılması, doğru kişiye atanması, takip edilmesi ve kapatılmasıdır. Uluslararası literatürde bu alan ITSM (IT Hizmet Yönetimi) olarak geçer ve ITIL gibi çerçevelerle tarif edilir. Ama iyi bir başlangıç için ITIL sertifikası gerekmez; birkaç temel kuralı doğru koymak yeterlidir.
E-postayla yürüyen desteğin gizli maliyetleri
- Kayıp talepler: Gelen kutusunda aşağıya kayan bir e-posta, kullanıcı tekrar sorana kadar görünmez olur.
- Kişiye bağımlılık: Talep kimin kutusuna düştüyse iş ondadır. O kişi izne çıktığında süreç durur.
- Önceliksizlik: Genel müdürün yazıcı sorunu ile üretim hattını durduran sistem arızası aynı sırada bekler ya da sesi çok çıkan önce çözülür.
- Ölçülemeyen emek: Ayda kaç talep geldiği, ortalama ne kadar sürede çözüldüğü ve en çok hangi konunun tekrarladığı bilinmez. Bu yüzden ek kaynak ya da yatırım talebi de verisiz kalır.
Önce iki kavramı ayırın: arıza ve hizmet talebi
İyi kurulmuş bir IT talep sürecinin ilk adımı, gelen işleri iki ana türe ayırmaktır:
- Arıza (olay): Çalışan bir şey bozuldu. “VPN bağlanmıyor”, “ERP ekranı açılmıyor”. Hedef: hizmeti en kısa sürede eski haline getirmek.
- Hizmet talebi: Yeni bir şey isteniyor. “Yeni başlayan personele bilgisayar ve hesap”, “ortak klasöre erişim yetkisi”. Hedef: standart adımlarla, gerekiyorsa onay alarak karşılamak.
Bu ayrım önemlidir, çünkü ikisinin akışı farklıdır. Yetki taleplerinde genellikle yönetici onayı gerekir; arızalarda ise onay değil hız önemlidir.
Öncelik nasıl belirlenir?
En pratik yöntem etki × aciliyet matrisidir. Etki: sorun kaç kişiyi veya hangi iş sürecini etkiliyor? Aciliyet: ne kadar süre beklenebilir?
| Aciliyet yüksek | Aciliyet düşük | |
|---|---|---|
| Etki yüksek (birim/hat/şube) | Kritik: hemen müdahale | Yüksek: aynı gün |
| Etki düşük (tek kişi) | Orta: 1 iş günü | Düşük: planlı sırada |
Süreler kurumunuza göre değişir. Önemli olan, önceliği talebi açan kişinin sesinin değil, önceden anlaşılmış bir kuralın belirlemesidir.
E-postadan kayıtlı talebe geçiş: 5 adım
- Tek giriş kapısı belirleyin. Bir talep formu, bir destek adresi ya da ikisi birlikte. Destek adresine gelen e-postalar otomatik olarak kayda dönüşmelidir. Böylece kullanıcı alışkanlığını değiştirmek zorunda kalmaz.
- Kategori listesini kısa tutun. Başlangıç için 6–8 kategori yeterlidir: donanım, yazılım, ağ/erişim, e-posta, yetki talebi, ERP, diğer. Uzun listeler yanlış seçime yol açar.
- Atama kuralı koyun. Her kategori için ilk sorumlu belli olsun. Atanmamış talep havuzda kalmasın.
- Hedef süreleri (SLA) yazın. İlk yanıt ve çözüm için öncelik bazında hedef süreler belirleyin. Süre aşımına yaklaşan talepler görünür olsun.
- Kapatırken kullanıcıyı dahil edin. Talep kapandığında kullanıcı bilgilendirilsin; “çözüldü” onayı ya da kısa bir memnuniyet sorusu ile döngü tamamlansın.
Hangi göstergeleri izlemelisiniz?
- Aylık açılan ve kapanan talep sayısı (birikim artıyor mu?)
- Öncelik bazında ortalama ilk yanıt ve çözüm süresi
- Hedef süreyi aşan taleplerin oranı
- En çok talep üreten 5 kategori (tekrarlayan sorunlar kalıcı çözüm ister)
- Tekrar açılan talep oranı (çözüm gerçekten çözüm mü?)
Bu göstergeler bir yönetim panosunda toplandığında, IT ekibi ilk kez yaptığı işi rakamla anlatabilir hale gelir. Pano kurgusu için Metabase sayfamıza göz atabilirsiniz.
Sık yapılan hatalar
- İlk günden her şeyi modellemeye çalışmak. 40 kategori ve 12 durumlu bir iş akışı kimse tarafından kullanılmaz. Sade başlayın, veriye bakarak geliştirin.
- Telefonla gelen talebi kayda almamak. “Hızlıca hallettim” denen işler kayda girmezse emek görünmez kalır.
- Aracı süreçten önce seçmek. Hangi aracı kullandığınızdan çok, akışı nasıl tanımladığınız belirleyicidir. Karşılaştırma için: Redmine mi Jira mı?
Sık sorulan sorular
IT talep yönetimi ile helpdesk aynı şey mi?
Yakın kavramlardır. Helpdesk genellikle talebi karşılayan ekibi ve ilk temas noktasını anlatır; IT talep yönetimi ise talebin açılışından kapanışına kadar tüm süreci kapsar. Müşteriye dönük destek süreçleri için helpdesk sayfamıza bakabilirsiniz.
Küçük bir IT ekibi için de gerekli mi?
Özellikle küçük ekipler için gereklidir. İki kişilik bir ekip, kayıtlı bir süreçle hem işini planlayabilir hem de ek kaynak ihtiyacını veriyle gösterebilir.
Geçiş ne kadar sürer?
Sade bir kurguyla başlandığında, ilk talep kanalının devreye alınması genellikle birkaç hafta sürer. Asıl zaman alan kısım, kullanıcıların yeni kanala alışmasıdır. Bu yüzden duyuru ve kısa bilgilendirme planı da işin parçasıdır.
IT taleplerinizi dağınık e-postalardan çıkarıp ölçülebilir bir sürece taşımak için nereden başlayacağınızı birlikte netleştirelim. Ayrıntılar: IT talep yönetimi.