BT’de “Acil” Kültürü: Hız mı Kaos mu?

Bilgi Teknolojileri ekiplerinde “acil” kelimesi, bir öncelik etiketi olmaktan çıkıp organizasyonel bir yaşam biçimine dönüştüğünde, artık hızdan değil; yönetilemeyen kaostan bahsederiz.

ITHERO360 gibi süreçleri tek çatıdan yöneten sistemler bile, eğer kültür ve governance olgunluğu yoksa sadece veri toplar; yönetimsel karar üretmez. Sorun, araç eksikliği değil; öncelik yönetimi, sahiplik ve hesap verebilirlik modelinin olmamasıdır.

⚠️ “Acil” Kültürü Nasıl Kaosa Dönüşür?

1. Talep yönetimi bypass edilir

Çalışanlar ticket açmaz, Slack/Teams üzerinden direkt kişiye yazar.
Sonuç: Denetlenemeyen iş, ölçülemeyen performans, görünmeyen risk.

2. Root Cause yerine Quick Fix

Aynı sorun 10 kez çözülür ama bir kez analiz edilmez.
Bu durum ITIL’den uzaklaşmış BT’nin en net göstergesidir.

3. Sahiplik bulanıklaşır

“Bu firewall kuralını kim açtı?”, “Bu sunucu kimin sorumluluğunda?”
Cevap yoksa: Incident yönetilemez, audit’te açıklanamaz.

4. Risk iştahı değil, iş baskısı karar verir

Güvenlik ekibi risk nedeniyle kapatmak ister, iş birimi “acil” diye açtırır.
Ama ortada Risk Değerlendirme Kaydı yoktur.

🧩 IT Governance Perspektifinden Asıl Sorun

Governance şu 3 soruyu net cevaplamalıdır:

Eğer “acil” talepler için:

• Değişiklik kaydı (Change Log)
• Risk değerlendirme (Risk Register)
• Sorumlu ataması (RACI/RACI-V)
• Onay akışı (CAB/mini-CAB)
• Geri izleme (Ticket/Task)

yoksa, yapılan her iş teknik olarak çözüm olabilir ama yönetsel olarak kontrolsüzdür.

🔐 Güvenlik Etkisi: Görünmez Incident’lar

Acil kültürünün güvenliğe en büyük etkisi:

Olay tespiti değil, olayın varlığını kanıtlayamama riskidir.

Çünkü:

• Log retention yoktur veya merkezi değildir
• Değişiklikler kayıt altına alınmaz
• Yetki talepleri trace edilemez
• Mesai dışı erişimler alert’e bağlı değildir

Bu da Incident Response’u reaktif ve kör hale getirir.

🧭 Olgunluğa Geçiş İçin 5 Governance Kuralı

1. Acil ≠ Süreçsiz

Her acil talep minimum bir Change Kaydı ile başlar.

2. Kararların izi olmalı

Risk nedeniyle yapılan açma/kapama kararları Risk Register’a yazılır.

3. Sahiplik atanmamış sistem gölgedir

Envanterde varlık + sahip eşleştirmesi zorunlu olmalı.

4. Acil işler için mini-CAB

KOBİ’de tam CAB ağır olabilir ama Teams üzerinden hızlı bir mini-CAB onayı gerekir.

5. Tekrar eden acil, acil değil; governance sorunudur

Aynı issue 3 kez tekrar ediyorsa Problem Kaydı açılır.

🎯 Yönetici Kıvamında Sonuç

Gerçek BT liderliği:

Yangını en hızlı söndüren olmak değil,
yangının tekrar çıkmasını engelleyen sistemi kurmaktır.

Hız değerlidir; ama governance yoksa hız sadece hatayı daha çabuk büyütür.

Yasin Yiğit

Merhaba. Bu platform, benim dijital not defterim ve kişisel bilgi arşivimdir