ITSM Sadece Bir Tool Değil
Kendi sitemde paylaşmak üzere, son dönemde ITSM tarafında yaptığım çalışmaları ve yaklaşımımı biraz daha sade bir dille anlatmak istedim. Çok “kitabi” bir ITIL yazısı değil; daha çok sahada neyle karşılaştım, neyi neden değiştirdim ve ne işe yaradı onun özeti gibi düşünebilirsiniz.
ITSM’e başlarken: Sorun tool değil, akış
İlk fark ettiğim şey şuydu:
Aslında elimizde kötü bir tool yoktu. Jira Service Management gayet güçlüydü. Ama süreçler karışıktı.
- Incident ile request birbirine girmişti
- Herkes her şeyi aynı formdan açıyordu
- Teknik alanlar kullanıcıya bırakılmıştı
- Değişiklikler (change) kontrolsüz ilerliyordu
Yani problem “hangi tool’u kullanıyoruz” değil,
👉 talebin nasıl açıldığı ve nasıl yönetildiğiydi
Ben de buradan başladım.
Incident – Request – Change ayrımını netleştirmek
ITIL’in en temel ama en çok ihmal edilen kısmı burası.
Benim yaklaşımım basitti:
- Incident → Bir şey çalışmıyorsa
- Service Request → Bir şey yapılması isteniyorsa
- Change → Sistem üzerinde değişiklik yapılacaksa
Bunu sadece teknik olarak ayırmak yetmiyor, kullanıcıya da doğru anlatmak gerekiyor.
Portalın en üstüne şu mantığı koydum:
- “Bir şey çalışmıyorsa → Sorun Bildir”
- “Bir şey istiyorsan → ilgili formu seç”
Bu küçük dokunuş bile yanlış açılan ticket’ları ciddi şekilde azalttı.
Form tasarımı: Kullanıcıya teknik soru sorma
Başta formlarda klasik alanlar vardı:
- General Incident Type
- Software Type
- Category vs.
Ama gerçek şu: kullanıcı bunları bilmiyor.
Ben de hepsini sadeleştirdim.
Örnek:
Eskisi:
❌ General Incident Type
Yenisi:
✔ Sorun Türü
- Giriş yapamıyorum
- Çalışmıyor
- Yavaş
- Hata alıyorum
Kuralım şu oldu:
👉 Kullanıcı ihtiyacını söyler, çözüm şeklini IT belirler
Access yönetimi: Basit vs yetkili erişim
Access tarafı genelde en çok risk barındıran alan.
Burayı ikiye ayırdım:
1. Normal Access
- Jira / Confluence erişimi
- Teams / SharePoint erişimi
2. Privileged Access
- Local Admin
- Admin yetkileri
- Kritik sistem erişimleri
Özellikle Local Admin için:
- Kalıcı yetki vermemeye çalıştım
- Mümkün olduğunca geçici (temporary) erişim modeli kurdum
- Gerekçe (justification) zorunlu yaptım
Bu hem güvenlik hem de audit açısından ciddi fark yarattı.
Change Management: “Küçük değişiklik” diye bir şey yok
Sahada en çok gördüğüm şeylerden biri:
“Ufak bir değişiklik yapalım” deyip production’ı bozmak.
Bunu engellemek için Application Change formunu ayrı tuttum.
Bu formda:
- Değişiklik türü (workflow, config, flow vs.)
- Gerekçe (neden yapılıyor)
- Etki (impact)
alanlarını zorunlu yaptım.
Bazı durumlarda da approval süreci ekledim.
Yani aslında klasik ITIL Change Management mantığını,
👉 gereksiz karmaşaya sokmadan uygulamaya çalıştım.
Cihaz tarafı: Reinstallation’ı Incident’tan ayırmak
Kullanıcılar genelde şöyle geliyor:
“Format atalım”
Ama bu her zaman doğru çözüm değil.
O yüzden:
- Device Reinstallation’ı ayrı bir form yaptım
- Incident’tan tamamen ayırdım
Kullanıcıya da şunu dedim:
👉 “Yeniden kurulum istiyorum” demen yeterli
👉 Nasıl yapılacağına IT karar verir
Ayrıca:
- Veri sorumluluğunu kullanıcıya bıraktım
- Onay checkbox ekledim
Bu da ileride çıkabilecek sorunları minimize etti.
Yazılım yönetimi: Tek form, merkezi kontrol
Yazılım tarafında da ayrı ayrı formlar yerine tek bir yapı kurdum:
Software Installation & Update
Kullanıcı sadece şunu yazıyor:
- Hangi yazılımı istiyor
Arka tarafta ben:
- Standart mı?
- Intune üzerinden mi dağıtılacak?
- Approval gerekiyor mu?
bunlara göre ilerliyorum.
Genel sonuç: Küçük değişiklikler, büyük fark
Yaptığım şey aslında çok kompleks değil.
Ama doğru yerlere dokununca etkisi büyük oluyor.
Gözlemlediğim değişimler:
- Ticket kalitesi arttı
- Yanlış form açma azaldı
- Çözüm süreleri kısaldı
- IT ekibi daha az yoruluyor
- Kullanıcı deneyimi iyileşti
Son söz
Bu süreç bana şunu net gösterdi:
ITSM işi tool kurmak değil,
👉 doğru akışı tasarlamak işi.
Formu sade yaptığında,
kullanıcıyı zorlamadığında,
ve ITIL mantığını arkada doğru kurguladığında…
sistem gerçekten çalışmaya başlıyor.