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.
BT ekibinin hayatında bazı günler vardır ki takvimde kırmızıyla işaretlenir. Doğum günü, terfi günü falan değil… Denetim günü!
Evet, işte o gün geldiğinde bütün ofisin havası değişir. Normalde kahvesini yudumlayarak işine bakan BT ekibi, bir anda CSI ekibine dönüşür. Ama bizde kanıt torbası yok, bolca Excel dosyası ve kayıp laptop hikayesi var.
Sabah: “Aykan, envanter listesi hazır mı?”
Denetim günü sabahı her zaman aynı sahne yaşanır:
“Aykan, envanter listesi hazır mı?”
“Hazır da… hangi versiyonunu istiyorsunuz?”
Çünkü gerçek şudur: Excel dosyasının 5 farklı versiyonu vardır. Biri masaüstünde, biri paylaşım klasöründe, biri de kim bilir hangi e-posta ekinde…
Öğle: “Bu cihaz kimin?”
Denetim ilerledikçe sahada dolaşılır. Masalarda laptoplar, depoda monitörler, odalarda yazıcılar… Ve o meşhur soru sürekli sorulur:
“Bu cihaz kimin?”
“Bilmem, benden önce buradaydı.”
“O zaman kayıtlarda niye yok?”
Aykan burada CSI moduna girer, cihazın seri numarasını inceler, geçmişe dair iz sürer. Ama bazen sonuç hep aynıdır: “Bilinmeyen kullanıcı”
Akşamüstü: Kaybolanlar Listesi
Denetim ilerledikçe tablo netleşir: 100 cihaz gözüküyor ama ortada 97 var. Üç tanesi yok!
“Aykan, eksik üç cihaz nerede?”
“Excel’in başka bir versiyonunda olabilir.”
Böylece kayıp cihazlar, ofisin “kara delik” vakası olarak dosyaya geçer.
Denetim Sonrası
Denetim günü bittiğinde herkes yorgundur. BT ekibi bir kahve içer, birbirine bakar ve aynı cümleyi kurar:
“Bir dahaki sefere daha düzenli olalım.”
Ama gerçek şudur: Bir dahaki sefere yine aynı kaos yaşanır. Çünkü BT varlıklarının gizemi hiç bitmez.
Sonuç
Denetim günü, BT ekibi için gerçekten bir kabustur. Ama aynı zamanda ofisin en eğlenceli hikayelerinin de kaynağıdır.
Ve bu hikayelerde Aykan’ın rolü bellidir: Kaybolan cihazların izini süren, Excel versiyon savaşlarının ortasında kalan, ama sonunda her zaman bir çözüm bulan kişi.
Denetim biter. Birkaç cihaz bulunamaz, bazı kulaklıklar “esrarengiz şekilde kayıp” çıkar. Ama aslında herkes bilir ki asıl mesele cihaz değil, insan faktörüdür.
Ve Aykan günün sonunda şöyle der: “Denetim dediğin şey, cihazların değil insanların yaratıcılığını ölçen bir sınavdır. Bizim iş, kayıp laptop değil; kayıp mantık bulmaktır.”
BT varlık yönetiminde en heyecanlı kısım nedir biliyor musunuz?
Ne yeni bir sunucu almak, ne lisans takibi yapmak… En eğlenceli (ve bir o kadar da sinir bozucu) kısım kaybolan eşyaların gizemini çözmeye çalışmak.
Evet, yanlış duymadınız. Kaybolan laptop, sahipsiz monitör, çift kişiye zimmetlenmiş yazılım lisansı… Adeta kendi CSI dizimizi çekiyoruz. Ama bizim dizide parmak izi yok, bol bol Excel var.
Kayıp Laptop Vakası
Bir gün envanter tablosuna bakarsınız: 50 laptop gözüküyor ama IT odasında 47 tane var. Klasik replik şudur:
“Arkadaşlar, üç laptop nerede?”
“Abi, belki depodadır.”
“Depoda değil, saydım.”
“O zaman birilerinin evindedir.”
Sonra işin içine mistik bir hava da katılır: “Ya da… kaybolmuş olabilir.”
Aslında gerçek şudur: O cihaz bir projede kullanılıyordur ama kimse sisteme işlememiştir. Ama bu küçük ayrıntı kayıp laptopu ofisin “kara kutusu” yapar.
Sahipsiz Monitörler
Depoya girdiğinizde her zaman köşede duran birkaç monitör vardır. Kime ait olduğu bilinmez, nereden geldiği hatırlanmaz.
Etiket yok, kayıt yok… Sadece oradadır.
IT ekibinin açıklaması genelde şöyledir:
“Abi bu monitörün hikayesini kimse bilmiyor. 2015’ten beri burada. Belki de bizden önceki IT ekibinden kalmadır.”
Böylece sahipsiz monitör, ofisin “hayalet varlığı” olur.
Lisansların Gizemli Yolculuğu
Fiziksel cihaz kaybolur da lisans kaybolmaz mı? Excel dosyasında bir satır vardır: “Adobe Lisansı – 1 adet”
Peki kime verilmiş? Belli değil.
Bir gün kontrol edersin, bakarsın ki aynı lisans 3 kişiye zimmetlenmiş. İşte o an anlarsın: Lisanslar fizik kurallarına meydan okuyor, paralel evrenlerde çoğalmışlar.
Küçük Eşyaların Dramı
Mouse, klavye, kulaklık… İşte en çok kaybolanlar bunlardır. Çünkü kimse onları varlık olarak ciddiye almaz.
Ama yıl sonu envanter denetiminde tabloya bakılır: “50 kulaklık vardı, şu an 38 var. 12’si nerede?”
Cevap:
“Kırıldı, çöpe atıldı.”
“Yanlışlıkla eve götürdüm.”
“Abi kulaklık mı zimmetleniyordu ya?”
Kaybolan Eşyaların Mucizevi Dönüşü
Bazı kayıp varlıklar ise yıllar sonra yeniden ortaya çıkar. Mesela bir taşınma sırasında dolabın arkasında bir laptop bulunur. Veya depoda kutunun içinde unutulmuş bir yazıcı çıkar.
O an ofiste sevinç çığlıkları yükselir:
“Buldum! Kayıp laptop buradaymış!”
Sanki define bulmuş gibi mutlu olunur. Halbuki o cihaz zaten senin malın. Ama işte, BT dünyasında bulmak da bir başarıdır.
Sonuç
BT varlık yönetiminde kayıp eşyalar aslında birer ofis efsanesidir. Her kayıp cihazın bir hikayesi vardır, her sahipsiz monitör bir dedikodu konusu olur.
ITIL bu durumu kitaplarda çok ciddiye alır: “Kayıtlar güncellenmeli, denetimler yapılmalı.”
Ama biz gerçekte şöyle yaşarız:
“Abi üç laptop kayıp, Excel’in başka versiyonuna bak belki ordadır.”
Bilgisayar, telefon, yazılım, sunucu… Bunların hepsi bizim BT varlıklarımız. Yani işin özü: şirketin teknolojik çeyizi. Ve bunların da bir ömrü var. Ama biz genelde “bozulana kadar kullan, sonra köşeye at” şeklinde takılıyoruz. Halbuki işin biraz daha düzenli bir yolu var. İşte buna da süslü adıyla “BT varlık yaşam döngüsü” deniyor.
Bu döngü nasıl işliyor?
Aslında çok basit:
Planla: Önce parayı nereye harcayacağına karar ver. Satın mı alınacak, kiralanacak mı, yoksa abonelikle her ay cüzdan mı boşalacak?
Edin: İhtiyaç olan cihaz veya yazılımı al. Tabii kayıt da tut, yoksa sonra kim aldı bu laptop diye aranırsın.
Ata: Cihazı birine zimmetle. Yani “Bu senin, sorumluluk sende” de.
Kullan: Cihaz işini görsün. Lisanslar, sertifikalar, tarihleri falan takip et.
Denetle: Kağıtta 100 bilgisayar görünüyor ama depoda 95 var. Beş tanesi nerede? İşte bu soruların sorulduğu yer.
Devre dışı bırak: Artık iş görmeyen cihazı kenara al. Bizdeki klasik replik: “Dursun ya, belki lazım olur.”
Elden çıkar: İşe yaramayan cihazı çöpe, hurdacıya ya da geri dönüşüme gönder. Ruhuna El-Fatiha…
Döngü sabit değil
Bu iş tek yönlü bir yol değil. Bazen aynı cihaz üç farklı kişiye verilir, bazen kenara atılan laptop yeniden hortlar, bazen de küçük şeyler için denetim yapılmaz. Yani kısaca: “Her cihazın hikâyesi farklıdır.”
Tüm varlıklar aynı yaşamıyor
Bir sunucu ile bir kulaklık aynı şekilde yönetilmez. ITIL da der ki: “Her varlığa kendi modelini uygula.” Yani yazılım başka, donanım başka, bulut bambaşka…
Peki bu bilgiler nerede tutulacak?
İşte asıl soru bu!
Excel mi? Herkesin aklına ilk gelen. Ama sonra hep aynı sahne: “Abi bu dosyanın son versiyonu hangisi?”
Araç mı? Daha profesyonel çözümler var. Uzun vadede sinirlerini korumak istiyorsan onları tercih et.
Sonuç
Aslında BT varlık yaşam döngüsü şu kadar basit: Al – Ata – Kullan – Kaybolsun – Excel’den bul – Bozulsun – Kenara koy – Hurdacıya ver.
Aradaki süslü cümleler ITIL’ın işi. Bizim işimiz ise şunu bilmek: Eğer varlıkları düzgün yönetmezsek, bir gün biri çıkıp sorar:“Arkadaşlar, şirkette 50 laptop vardı, 12’si nerede?”Ve cevap şu olur:“Bilmiyorum, belki başka bir Excel’de vardır…”
BT departmanı bazen tam bir kaos olabilir: ticket’lar kaybolur, kullanıcı bekler, aynı sorun tekrar tekrar çıkar… İşte ITSM tam burada devreye giriyor ve işleri düzene koyuyor.
1️⃣ Düzen
Her ticket ve talep kayıtlarda, kaybolmaz. 💡 Aykan sahnede: Kullanıcı bilgisayarının açılmadığını söylüyor ve ticket açıyor. Ben kaydı kontrol ediyorum, eksik bir şey varsa tamamlıyorum. Böylece hiçbir talep unutulmuyor, herkes işini rahatça yapıyor.
2️⃣ Hız
SLA ve önceliklendirme sayesinde çözümler hızlı. 💡 Aykan sahnede: Printer çalışmıyor, ticket açılıyor. Ben hemen önceliğini belirliyorum, ekip sorunu çözüyor. Kullanıcı beklemek zorunda kalmıyor, işine devam ediyor.
3️⃣ Kalite
Standart süreçler hata riskini azaltır. 💡 Aykan sahnede: Yeni yazılım kurulacak. Adım adım prosedürleri takip ediyorum, yanlış kurulum veya eksik yetki riski ortadan kalkıyor. Sistem sorunsuz çalışıyor.
4️⃣ Analiz ve İyileştirme
Incident ve problem verileri sayesinde sorunların kökü bulunur, süreçler sürekli iyileştirilir. 💡 Aykan sahnede: Sunucu sık çöküyor. Verileri inceliyorum, temel nedeni bulup kalıcı çözümü uyguluyorum. Aynı problem bir daha çıkmıyor.
5️⃣ Kullanıcı Memnuniyeti
Kullanıcı “Sorunum takip ediliyor, ben rahatım” der. 💡 Aykan sahnede: Yeni lisans veya mouse talebi geliyor. Ticket kaydıyla süreci takip ediyorum, kullanıcı işine kesintisiz devam ediyor ve mutlu oluyor.
Özetle: ITSM, BT’yi sadece “sorun çözen birimler” olmaktan çıkarıyor. Düzenli, hızlı, kaliteli ve ölçülebilir bir hizmet sağlayıcı hâline getiriyor.
Bu yazımda ITSM’i size kendimce, basitleştirerek anlatacağım.
BT dünyası karmaşık bir şehir gibi: sunucular, uygulamalar, kullanıcılar… İşte ITSM, bu şehrin trafik lambaları ve yol haritaları gibi. Her şeyin kaydı var, süreçler kontrol altında, kaos yok.
ITSM (IT Service Management) ⚙️ BT’de işlerin aksamadan yürümesini sağlayan, mutfakta her işi takip eden şef gibi düşünebilirsin.
Bilgisayar bozuluyor, sunucu patlıyor, kullanıcı yeni yazılım istiyor… ITSM devreye giriyor ve her şeyi kayda alıyor, süreçleri takip ediyor, kaosu engelliyor.
💡 Aykan sahnede: Kullanıcı “Bilgisayarım açılmıyor!” diyor. Ticket açıyor ve süreç başlıyor. Ben de durumu takip edip çözülmesini sağlıyorum. Kullanıcı fark etmeden işine devam ediyor.
ITSM’in Ana Süreçleri
1️⃣ Interaction Management (Etkileşim Yönetimi)
💬 Ne yapıyor? Kullanıcı veya müşteri ile yapılan her türlü iletişimi kaydeden ve takip eden süreç.
💡 Aykan sahnede: Kullanıcı “Laptopum bozuldu” diyor ve ticket açıyor. Ben kaydı alıyorum, süreci takip ediyorum ve ilgili ekibe yönlendiriyorum. Buradaki amaç iletişimi yönetmek ve talebin takibini sağlamak.
2️⃣ Incident Management (Olay Yönetimi)
💥 Ne yapıyor? Sistemde bir aksaklık çıktığında veya kullanıcı işi durduğunda sorunu hızlıca çözmek için devreye girer.
💡 Aykan sahnede: Kullanıcı laptopunun açılmadığını bildiriyor ve ticket açıyor. Ben süreci takip ediyorum, önceliği belirliyorum ve sorunun çözülmesini sağlıyorum. Kullanıcı işine kesintisiz devam ediyor.
🔑 Not: Interaction Management sadece iletişimi kaydeder ve talebi takip eder, Incident Management ise teknik sorunu çözmeye odaklanır.
3️⃣ Problem Management (Problem Yönetimi)
🔍 Ne yapıyor? Olaylar sürekli tekrar ediyorsa veya tek seferlik çözüm yetmiyorsa, kök nedeni bulur ve kalıcı çözüm üretir.
💡 Aykan sahnede: Sunucu her hafta çöküyor. Ben kök nedeni bulup önlemleri planlıyorum ve uyguluyorum. Kullanıcılar fark etmeden işine devam ediyor.
4️⃣ Change Management (Değişiklik Yönetimi)
🔄 Ne yapıyor? Sistem üzerinde planlı bir değişiklik yapılacaksa, riskleri kontrol edip, prosedüre uygun şekilde uygular.
💡 Aykan sahnede: Yeni yazılım kurulacak. CAB onayı alıyorum, riskleri kontrol ediyorum ve değişikliği sorunsuz uyguluyorum.
5️⃣ Service Request Management (Hizmet Talebi Yönetimi)
📝 Ne yapıyor? Kullanıcının standart ve tekrar eden taleplerini hızlı ve düzenli şekilde karşılar.
💡 Aykan sahnede: Kullanıcı yeni lisans veya donanım talep ediyor. Talebi değerlendiriyorum, gerekli erişimi sağlıyorum. Kullanıcı işine kesintisiz devam ediyor.
ITSM’in Kazandırdıkları
Düzen: Her ticket ve etkileşim kayıtlarda, kaybolmaz.
Hız: SLA ve önceliklendirme ile çözümler hızlı.
Kalite: Standart süreçler hata riskini azaltır.
Analiz: Incident ve problem verileri ile sistem sürekli iyileştirilir.
Kullanıcı memnuniyeti: Kullanıcı “Sorunum takip ediliyor, ben rahatım” der.
💡 Aykan sahnede: Tüm süreçleri kontrol ediyorum, sistemi takip ediyorum ve işlerin sorunsuz ilerlediğinden emin oluyorum.
Küçük Rehber: Süreçleri Kafada Netleştirmek
Interaction: “Talebi kaydet, takip et, ekibe yönlendir.”
Incident: “Sorunu hızlıca çöz, kullanıcıyı tekrar çalışır duruma getir.”
İçinde Incident, Problem, Change, Request, Configuration gibi süreçler var.
Amacı: BT hizmetlerini ölçülebilir, tekrarlanabilir ve denetlenebilir hale getirmek.
💡 Aykan sahnede: Şirketin karmaşık sistemlerinde bir sorun çıkıyor. “Bu olay Incident mi, yoksa Problem mi?” diye emin olamıyor. ITIL kitabını açıyor, doğru süreci bulup işini yoluna koyuyor.
ITIL. Information Technology Infrastructure Library. Vector Illustration in flat style. Isolated on white background.
ITSM (IT Service Management)
⚙️ ITIL’in pratikteki karşılığı, yani teoriyi mutfağa sokan şef.
Ticketing sistemleri (Service Desk, Jira, ServiceNow vs.) üzerinden işler akar.
KPI’lar, SLA’lar devreye girer.
Süreç: Kullanıcı talep açar → kayıt sistemde sınıflanır → ekibe atanır → çözülür.
💡 Aykan sahnede: Bir kullanıcı “Laptopum bozuldu!” diye geliyor. Aykan ITSM aracıyla incident kaydını açıyor, ilgili ekibe paslıyor. SLA süresi dolmadan sorun çözülüyor, kullanıcı da “Vay be!” diyor.
ITAM (IT Asset Management)
💻 Donanım, yazılım, lisans… Kısacası şirketteki tüm varlıkların nüfus müdürlüğü.
CMDB’de her şey kayıtlı: cihaz sahibi, lokasyon, garanti, bakım geçmişi.
Lisanslar takipte, compliance kontrol altında.
💡 Aykan sahnede: Lisansın süresi bitmek üzere. Aykan “Son gün geldiğinde panik olmasın” diye önceden yenileme talebi açıyor. Ayrıca kaybolan bir cihazı CMDB’de bulup olayı tatlıya bağlıyor.
ITOM (IT Operations Management)
🌐 Altyapının kalp atışını dinleyen stetoskop.
Sunucu uptime, ağ erişilebilirliği, uygulama performansı sürekli izlenir.
Monitoring & Alerting araçları (Nagios, Zabbix, SCOM vs.) iş başında.
İş sürekliliği için kritik.
💡 Aykan sahnede: Monitoring ekranında bir sunucunun CPU %95 olmuş. Alarm düşüyor. Aykan hemen aksiyon alıyor, sorun büyümeden çözülüyor. Kullanıcılar hiçbir şey hissetmeden günlük işine devam ediyor.
