Jira kullanan herkes bir noktadan sonra şunu fark ediyor:
Sistem bazen ticket yönetim aracı olmaktan çıkıp, Indiana Jones’un kayıp tapınağına dönüşüyor.
Bazı ayarlar var ki… İnsan onları bulunca başarı hissi yaşamıyor. Daha çok gizli achievement açmış gibi hissediyor.
Özellikle:
Permission
Request type mapping
Field context
Screen scheme
Workflow binding
Customer permission
Portal visibility
kısımları…
Sanki Atlassian oturup şöyle düşünmüş gibi:
“Bu ayarı bulan kişi zaten admin olmayı hak etmiştir.”
Bir field ekliyorsun görünmüyor. Issue’da var, portalda yok. Portalda var, request type’da yok. Automation görüyor ama kullanıcı göremiyor. Kullanıcı görüyor ama edit edemiyor. Edit ediyor ama save olmuyor.
Bir noktadan sonra insan ticket çözmeyi bırakıp kendi akıl sağlığını troubleshoot etmeye başlıyor.
Sonra ekrana boş boş bakıp şu cümleyi kuruyorsun:
“Ben Jira mı yönetiyorum… yoksa escape room mu oynuyorum?”
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.
