Teknik borçları görünür kılmak: Portföy kararları için hafif bir skorlama modeli

Birçok BT organizasyonunda teknik borçlar uzun zamandır kalıcı bir durum haline gelmiştir: uygulamalar çalışıyor, süreçler işliyor, fakat yine de her değişiklik daha zor, her sürüm daha riskli ve her kesinti daha pahalı oluyor. Sorun nadiren kimsenin riskleri görmemesi—sorun bunların karşılaştırılabilir olmamasıdır. Beş sistem aynı anda „kritik“ olduğunda, sonuçta hiçbiri önceliklendirilemez. Tam da burada bir teknik borç skorlama modeli yardımcı olur: teknik riskleri, işletme yükünü ve modernizasyon baskısını öyle bir şekilde gösteren, hafif ve tekrarlanabilir bir değerlendirme matrisi ki portföy kararları sağlamlaşır.

Bu yazı, devasa bir değerlendirmeye ihtiyaç duymayan ancak BT yönetimi, işletim, sistem yöneticileri, proje sorumluları ve iş birimlerinin günlük kullanımında işe yarayan bir skorlama modelini tanımlar. Odak noktası dahili kod ayrıntıları değil; bunun yerine İşletim, Güvenlik, Veri, Arayüzler, Teslim kabiliyeti ve Bakım üzerindeki etkileridir. Amaç, bütçe ve öncelik tartışmalarını yatıştıran ve modernizasyonu planlanabilir kılan ortak bir dildir.

Teknik borç skorlama modeli pratikte

Teknik borçlar, kısa vadede zaman kazandırmış ancak uzun vadede faiz maliyeti yaratan kararlar ve kalıntılar için kullanılan bir şemsiye terimdir. Bu „faizler“ kurumsal gündelik işleyişte daha uzun çevrim süreleri, daha fazla koordinasyon, daha yüksek hata oranları, güvenlik açıkları, birkaç kişide yoğunlaşan uzmanlık veya artık desteklenmeyen bileşenlere bağımlılık olarak kendini gösterir. Sorun şu ki: bu etkilerin birçoğu açık bir maliyet merkezinde görünmez.

Teknik borçların portföy oturumlarında göz ardı edilmesinin tipik nedenleri:

• Karşılaştırılabilirlik eksikliği: Stabil bir eski monolit, artan lisans baskısı olan bir SaaS aracı ve gece işlerine sahip bir entegrasyon hattını bir çerçeve olmadan birbirleriyle karşılaştırmak zordur.
• Tutarsız veri durumu: Sistem A için olay istatistikleri ve izleme var, Sistem B için yalnızca sezgi, Sistem C için ise hiçbir veri yok.
• Karışık tartışmalar: İş değeri, teknik riskler ve kişisel tercihler (teknoloji, ekip isteği) aynı potada toplanıyor.
• Aşırı kapsamlı değerlendirme modelleri: Kapsamlı olgunluk modelleri mantıklıdır — ancak genellikle düzenli olarak bakımları yapılmaz. Portföy kararlarında önemli olan tekrarlanabilirliktir.

Hafif bir skorlama modeli mutlak bir gerçeklik iddia etmez. Belirsizliği azaltmak ve kararları izlenebilir kılmak için kullanılan bir araçtır — arkasındaki varsayımlar dahil.

Hafif bir skorlama modeli için prensipler

Bir skorlama modeli „Excel egzersizi“ olarak bitmemesi için birkaç temel ilkeyi karşılamalıdır:

• Az sayıda boyut, net tanımlar: 20 yarım kriter toplamak yerine 6–8 değerlendirme boyutunu net olarak açıklamak daha iyidir.
• Ölçülebilir, ama sayıya sabitlenmiş değil: Her şey sayısal olarak mevcut değildir. Önemli olan kriterlerin tutarlı uygulanmasıdır.
• Portföy-uygun: Değerlendirme sistemler arasında çalışmalıdır — bireysel kurumsal yazılım, standart ürünler veya entegrasyon bileşenleri olması farketmez.
• Açık perspektifler: İşletim, Güvenlik, Veri ve iş birimi modelde yer almalıdır, böylece yalnızca „Teknik karşı İş“ tartışması yapılmaz.

Pratikte, skoru tartışma zemini olarak ele almak faydalıdır: O önceliklendirilmiş bir liste sunar, ancak otomatik kararlar oluşturmaz. Portföy kurulları sorumluluğunu korur – ve sapmaları kasıtlı olarak belgelendirirler.

Skorlama Modeli: Operasyonda Gerçekten Önemli Olan 8 Boyut

Aşağıdaki şablon, tipik kurumsal ortamlarda kolayca ölçülebilecek sekiz boyut kullanır. Her boyut 1 ile 5 arasında puanlanır (1 = önemsiz/iyi yönetilen, 5 = kritik/acil müdahale gerektiren). Önemli olan matematiksel mükemmellik değil, kriterlerin netliğidir.

1) Operasyonel Kararlılık ve Arıza Profili

Burada soru şudur: Sistem operasyonu ne sıklıkla aksatıyor ve bu aksaklıkların organizasyonel maliyeti ne kadar? Temel ölçütler arızalar (Incidents), tekrarlayan talepler (ticket), on-call eskalasyonları ve plansız bakım çalışmalarıdır. Gece işlemlerinin sıkça yeniden çalıştırılması gibi “sessiz” kararsızlıklar da hesaba katılır.

Değerlendirme dayanakları (örnekler):

• 1: Nadir arızalar, net runbook’lar (işletme el kitapları), yeniden başlatma uygulamaları yapılmış.
• 3: Düzenli arızalar veya sık performans sorunları, ancak yönetilebilir.
• 5: Tekrarlayan kesintiler, yüksek destek yükü, nedenin giderilmesi yerine geçici çözümler (workarounds) kullanımı.

2) Güvenlik ve Uyumluluk Riski

Bu boyut, sistemin güvenlik olaylarına karşı ne kadar korunmuş olduğunu ve ne kadar denetlenebilir (prüfbar/auditfähig) işletilebildiğini değerlendirir. Buna patch uygulanabilirlik, desteklenen bileşenler, kimlik doğrulama (ör. SSO über SAML/OIDC – yani merkezi oturum açma), kayıt tutma (Audit-Trail: izlenebilir olay zinciri) ve hassas verilerin korunması dahildir.

• 1: Düzenli güncellemeler, net roller/izinler, izlenebilir loglar, bilinen „End-of-Life“ bileşenleri yok.
• 3: Kısmen eski bileşenler veya kayıt/yeniden sertifikalandırma eksiklikleri, telafi edici önlemler mevcut.
• 5: Kritik eski bağımlılıklar, eksik yamalar, belirsiz sorumluluklar, denetim riskleri.

3) Değiştirilebilirlik ve Sürüm Yayınlanabilirliği

“Değişiklikleri güvenli şekilde teslim etmek ne kadar zor?” Bu, birçok teknik borcun özüdür. Kastedilenler test edilebilirlik (regresyon: yineleme testleri), dağıtım süreci, rollback yeteneği (temiz geri dönüş seçeneği), tek kişilere bağımlılık ve gereksinimden üretime geçiş süresidir.

• 1: Yeniden üretilebilir sürümler, tanımlı ortamlar, planlanabilir bakım pencereleri.
• 3: Sürümler mümkün, ancak manuel adımlar ve artan koordinasyon gerektirir.
• 5: Her değişiklik risklidir, dağıtım ancak „doğru kişilerle“ yapılabiliyor, rollback belirsiz.

4) Mimari ve Entegrasyon Karmaşıklığı

Bu boyut, bir mimarinin “modern” olup olmadığını değil, kontrol edilebilir olup olmadığını ölçer. Entegrasyonlar genellikle maliyet sürücüsüdür: noktadan noktaya arayüzler, özel dosya formatları, zaman kritik toplu işlem (batch) işlemleri, API’lerin (arayüz sözleşmelerinin) versiyonlanmaması veya diğer sistemlere sıkı bağlılık.

• 1: Açıkça belgelenmiş arayüzler, az sayıda bağlantı noktası, değişiklikler yerel etki yaratır.
• 3: Birden fazla bağımlılık, değişiklikler koordine edilmiş sürümler gerektirir.
• 5: “Spaghetti” entegrasyonları, bilinmeyen veri akışları, küçük değişikliklerde yüksek etki.

5) Datenqualität, Datenhoheit und Datenflüsse

Portföy kararları için belirleyici olan, verilerin temiz tutulup güvenilir şekilde kullanılabilir olup olmadığıdır. Veri egemenliği şunu ifade eder: “gerçeğin kaynağının” nerede olduğu, ana verilerin (ör. müşteriler, ürünler, tedarikçiler) nasıl oluştuğu ve değişikliklerin sonraki aşamalarda nasıl etki yarattığı nettir. Veri akışları ayrıca dışa aktarımları, gölge kopyaları ve elle yapılan düzeltmeleri de kapsar.

• 1: Açık sorumluluklar, izlenebilir veri yolları, tanımlı arayüzler, tutarlı anahtarlar.
• 3: Birden fazla veri kaynağı veya düzenli temizlemeler var, ama şeffaf.
• 5: Gerçeğin kaynağı belirsiz, sık düzeltmeler gerekli, raporlama yalnızca özel mantıkla mümkün.

6) Lifecycle-Risiko: Hersteller, Plattform, Skills

Teknik borçlar aynı zamanda kullanım dışına çıkan bileşenlerden de kaynaklanır: işletim sistemleri, veritabanları, kütüphaneler, üretici desteği veya bilgi birikiminin erişilebilirliği. Bu boyut kasıtlı olarak organizasyonel tarafı ele alır: İşletmeyi ve devam eden geliştirmeyi taşıyacak yeterli kişi var mı? Güvenilir bir yükseltme yolu mevcut mu?

• 1: Aktif destek döngüleri, yükseltme planlanmış, yetkinlikler geniş erişilebilir.
• 3: Yükseltme yaklaşıyor, yetkinlik durumu gergin, birkaç kilit kişiye bağımlılık var.
• 5: Kullanım ömrü sonu (End-of-Life), yol haritası yok, bilgi yoğunlaşmış, tedarikçi riski yüksek.

7) Kosten- und Aufwandstreiber im laufenden Betrieb

Burada yalnızca altyapı maliyetleri değil, özellikle değişken maliyetler değerlendirilir: destek çabası, elle yapılan işler, özel süreçler, lisans artışı, dış hizmet sağlayıcıya bağlılık veya pahalı bakım pencereleri. İş yazılımlarında bu dolaylı maliyetler genellikle sunucu maliyetlerinden daha belirleyicidir.

• 1: İstikrarlı işletim, az manuel işlem, maliyetler planlanabilir.
• 3: Artan işletme çabası veya yükselen lisans maliyetleri, ama yönetilebilir.
• 5: İşletme kapasiteyi “yiyor”, çok sayıda manuel düzeltme, maliyetler zor öngörülebilir.

8) Business-Kritikalität und Prozessabhängigkeit

Teknik borçlar, süreç riskiyle birleşmedikçe portföy kararları açısından önem taşımaz. Bu boyut, sistemin çekirdek süreçleri ne derece desteklediğini ve arıza ya da işlev bozukluğunda ortaya çıkacak zarar büyüklüğünü değerlendirir. Önemli: Kritiklik “asla dokunma” izni vermez; aksine temiz stabilizasyon ve modernizasyon için gerekçedir.

• 1: Destekleyici süreç, kesinti tolere edilebilir, geçici çözüm (workaround) mevcut.
• 3: Önemli süreç, kesintiler maliyet yaratır, ama sınırlandırılabilir.
• 5: Çekirdek süreç, kesinti katma değeri durdurur veya uyumluluk (compliance) risklerine yol açar.

Wie aus Scores Portfolio-Entscheidungen werden (ohne Scheingenauigkeit)

Bir skor, ancak bir kararı hazırlıyorsa kullanışlıdır. Bunun için iki adım gerekir: ağırlıklandırma ve karar kategorileri.

Gewichtung: nicht jedes Kriterium zählt gleich

Birçok organizasyon tartışmaları önlemek için başlangıçta eşit ağırlık verir. Sonrasında, portföy hedeflerine göre basit bir ağırlıklandırma faydalı olur, örneğin:

• Güvenlik öncelikli (ör. denetim bulgularına göre): güvenlik ve uyum riskine iki kat ağırlık verin.
• Teslim yeteneğini artırma (ör. yüksek değişiklik birikimi durumunda): değiştirilebilirlik/sürüm yeteneğine daha yüksek ağırlık verin.
• Maliyetleri istikrara kavuşturma (ör. artan destek yükü): işletme üzerindeki maliyet sürücülerine daha yüksek ağırlık verin.

Önemli olan, ağırlıklandırmayı şeffaf şekilde belgelemek ve nadiren değiştirmektir. Aksi takdirde skor değişiklikleri gerçek bir iyileşme yerine „politik“ görünür.

Karar kategorileri: dört net eylem seçeneği

Boyutlardan, portföy kurulunda iyi tartışılabilecek dört pragmatik kategori türetilebilir:

• İstikrara kavuşturma: Yüksek işletme/güvenlik riskleri mevcut, ancak kısa vadede devre dışı bırakma mümkün değil. Odak: runbook’lar, izleme, yama yolları, teknik hijyen.
• Yenileme: Yüksek değişiklik veya yaşam döngüsü riski ile birlikte yüksek kritiklik. Odak: modüler yenileme, arayüzlerin gevşek bağlı hale getirilmesi, veri modellerinin konsolidasyonu.
• Konsolidasyon/Değiştirme: Çift işlevler, yüksek iş yükü, düşük farklılaşma. Odak: kapatma, veri migrasyonu, süreçlerin standartlaştırılması.
• Bilinçli kabul: Düşük kritiklik veya öngörülebilir kalan ömür. Odak: risk kontrolleri, asgari bakım, net çıkış seçeneği.

Bunun teoride kalmaması için, her uygulamaya ayrıca bir sonraki mantıklı adım verilmelidir – en fazla 1–2 somut önlem ve bunların 4–12 hafta içinde gerçekçi olması gerekir. Böylece portföy yönetimi yıllık bir atölye yerine sürekli bir iyileştirme sürecine dönüşür.

Veri temelini pragmatik şekilde oluşturma: Hangi kaynaklar genellikle yeterlidir

Hafif bir model, veri toplamanın ilk önlemlerden daha maliyetli olmaması üzerine kuruludur. Birçok şirket için güvenilir skorlar vermek üzere dört veri kaynağı yeterlidir:

• Bilet-/Incident verileri: Sıklık, tekrarlar, işleme süreleri, eskalasyonlar. Temiz bir kategorilendirme yoksa başlangıçta kaba bir sınıflandırma yeterlidir (kesinti, talep, değişiklik).
• İzleme/Erişilebilirlik: Sadece „çalışma süresi“ değil; aynı zamanda performans zirveleri, iş çalışma süreleri, hata oranları, bellek/disk büyümesi.
• Güvenlik ve yaşam döngüsü bilgileri: Yama durumu, kullanım ömrü sonu tarihleri, bağımlılıklar (ör. veritabanı sürümü, işletim sistemi, kimlik doğrulama), bilinen istisnalar.
• Mimari/Entegrasyon görünümü: Veri akışları ve arayüzlerle basit bir uygulama haritası (sistem haritası). Tamlık ikincildir, güncellik önemlidir.

Rakamlar eksikse bunun skor içinde görünür olması gerekir: „Kanıt eksikliği nedeniyle Değerlendirme 4“ rastgele bir ortalamadan daha dürüsttür. Bilinmeyen, işletmede genellikle en azından bilinen kötü olandan daha risklidir.

90 dakikalık Skorlama-Atölyesi: Akış, roller, çıktı artefaktları

Sık yapılan bir hata, Scoring’i tek kişi işi olarak yürütmektir. Bu ya aşırı teknik ya da politik olur. Daha iyi olan, moderatörlü ve net rollere sahip her sistem için kısa bir atölyedir. Temel veriler mevcutsa ilk güvenilir değerlendirme için 90 dakika yeterlidir.

Katılımcılar (küçük ama eksiksiz)

• IT sistem sorumlusu: yol haritasını, değişiklikleri, teknik darboğazları bilir.
• Operasyon/Administrasyon: kesintileri, bakım pencerelerini, izlemeyi, yedekleme/geri yüklemeyi bilir.
• İş sahibi veya Kilit Kullanıcı: süreç kritikliğini, geçici çözümleri (workarounds), kabul düzeyini, yoğun saatleri bilir.
• Moderatör: tanımlara uyulmasını sağlar ve varsayımları belgelendirir.

İş akışı (kısa, tekrarlanabilir)

1. Bağlam (10 dk.): sistemin amacı, kullanıcı grupları, ana arayüzler, işletim modeli (On-Prem/Cloud/Hybrid).
2. Her boyut için skor (45 dk.): Her kriter için 3–5 dakika, kısa kanıtlarla (ticket sayıları, yama düzeyi, bilinen bağımlılıklar).
3. Sıcak noktaları belirleme (15 dk.): Hangi 2 boyut riski/maliyetleri en çok artırıyor?
4. Eylemler belirleme (15 dk.): 1–2 somut sonraki adım, ayrıca sorumlu (Owner) ve hedef tarih.
5. Portföy etiketi (5 dk.): İstikrara Kavuşturma / Modernizasyon / Konsolidasyon / Kabul.

Sonuç olarak üç çıktı yeterlidir: Skor tablosu, her boyut için kısa gerekçe ve bir eylem özeti. Diğer her şey isteğe bağlıdır.

Tipik tuzaklar – ve modeli bunlardan nasıl korursunuz

Temiz çerçevelenmemiş bir Scoring modeli yanlış teşvikler yaratabilir. Proje deneyiminden en sık rastlanan takılma noktaları şunlardır:

Tuzak 1: „Şeffarlık nedeniyle ekipleri cezalandırıyoruz”

Eğer iyi dokümantasyon yapan ekipler sorunları görünür kıldıkları için daha düşük skor alıyorsa, model çökmüştür. Önlem: Bilinmeyeni (eksik veriler) ayrı bir risk olarak ele alın ve şeffaflığı özellikle bir artı olarak kabul edin; örneğin Değiştirilebilirlik kriterinde (Rollbacks, Runbooks, Monitoring).

Tuzak 2: Skor bütçe kesintisi aracına dönüşüyor

Eğer yüksek skorlar otomatik olarak “proje durdurma”ya götürüyorsa, model siyasallaşır. Daha iyi yaklaşım: Yüksek skorlar, seçenekler içeren bir karar önerisine (ör. İstikrara Kavuşturma vs. Modernizasyon) ve net sonuçlara yol açsın. Bütçe karara göre belirlenir – sadece skora göre değil.

Tuzak 3: Fayda ile riskin karıştırılması

İşsel fayda (ör. gelir potansiyeli) önemlidir, ancak farklı bir eksendir. Önerilen uygulama: Faydaları ayrı bir ızgarada değerlendirin ve sonra bir portföy matrisinde birleştirin (Fayda yüksek/düşük vs. Risk/teknik borç yüksek/düşük). Böylece bir güvenlik riskinin “gelirle” telafi edilip edilmediği tartışılmaz.

Tuzak 4: „Modernizasyon“ büyük bir proje olarak algılanıyor

Portföy kararları genellikle modernizasyonun yalnızca bir Big Bang ile yapılabileceği varsayımının gölgesinde başarısız olur. Gerçekte sıkça modüler bir modernizasyon daha mantıklıdır: arayüzleri stabilize etmek, veri erişimlerini standardize etmek, tek tek alt süreçleri ayırmak, paralel işletimi düzgün şekilde yönetmek. Bir Skor, sırayı bulmaya yardımcı olur; nihai durumu zorlamaz.

Skordan Yol Haritasına: eylem paketleri nasıl uygun şekilde tasarlanır

Model oturduğunda asıl iş başlar: Önlemleri günlük proje faaliyetlerinin yanı sıra çalışacak şekilde bölmek. „Bir ara yapmalıyız“ lafını somut yol haritası öğelerine dönüştürmeye yardımcı olacak üç kural vardır:

1) Önce en maliyetli riskleri „hafifletmek“

Birçok portföyde güvenlik ve işletme riskleri en büyük kaldıraçtır, çünkü dışsal süreler (denetim, End-of-Life) ve yüksek takip maliyetleri getirirler. Tipik hafifletmeler şunlardır: güncelleme yolunu oluşturmak, logging/audit-trail eklemek, yedekleme/geri yükleme süreçlerini test etmek, tek hata noktalarını azaltmak, izinleri mantıklı ve tutarlı hale getirmek.

2) Entegrasyon düğümlerini fonksiyon genişletmeden önce stabilize etmek

Çok sayıda arayüze sahip sistemler değişiklik maliyetlerinin çoğalmasına neden olur. Burada genellikle önceliklendirme şu şekilde olmalıdır: arayüz sözleşmelerini tanımlamak (sürümleme, veri formatları, hata işleme), veri akışları için izleme eklemek, iş zincirlerini birbirinden ayırmak, retry stratejileri (hata durumunda yeniden denemeler) uygulamak. Bu genelde iş birimi için “gözle görülür” değildir, ama kesinti sürelerini ve sürüm kaynaklı stresi ölçülebilir şekilde azaltır.

3) Önlemleri „operasyonel iyileştirme“ olarak planlanabilir yapmak

Birçok teknik borç, küçük paketler halinde operasyonel iyileştirmeler olarak uygulanabilir: runbook’lar, alarm kuralları, kapasite planlaması, ortamların standardizasyonu, düzenli yama pencereleri. Bunlar gösterişli projeler değildir, fakat güvenilirliği artırır ve daha büyük modernizasyon adımları için zaman pencereleri yaratır.

Skorlamayı kalıcı kılmak: bürokrasisiz yönetişim

Bir model ancak iki çeyreğin sonunda unutulup gitmiyorsa değerlidir. Bunun için işletme ve proje gündemine uyan basit bir sürece ihtiyaç vardır:

• Her uygulama için sorumlu (Owner): Skor ve önlem durumunu yöneten atanmış bir kişi (uygulamayı tek başına hayata geçirmez).
• Tetikleyici yerine takvim zorunluluğu: Skor gözden geçirmesi incident kümesi, major sürüm, denetim bulgusu veya platform yükseltmesi sonrasında yapılır.
• Portföy ritmi: Aylık/iki ayda bir, sadece en üst riskler için 60 dakika; tüm sistemler için değil.
• Karar kaydı: Bir riskin neden kabul edildiği veya ertelendiğine dair kısa dokümantasyon. Bu sonraki suçlamaları önler ve varsayımları görünür kılar.

Gerçek yönetime bağlanması önemlidir: Kapasitenin (bütçe veya ekip zamanı) en azından bir kısmı açıkça stabilizasyon/modernizasyon için ayrılmalıdır. Aksi takdirde model sadece etkisi olmayan bulgular üretir.

Sonuç: Teknik borçları görünür kılmak, organizasyonu aşırı yüklemeden

Hafif bir teknik borç skorlama modeli ayrıntılı bir mimari çalışmasının yerini almaz – ancak portföylerde sıkça eksik olan bir şeyi sağlar: karşılaştırılabilirlik. Sekiz net boyut, izlenebilir değerlendirme dayanakları ve kısa bir atölye formatı ile riskler, işletme yükü ve modernizasyon baskısı öyle sunulabilir ki BT, ilgili iş birimi ve yönetim aynı tartışmayı yürütür.

En önemli etki nadiren kesin sayısal değerdir. Önemli olan, teknik borçların nerede oluştuğu, nasıl işletmeyi yıprattığı ve hangi sonraki adımların gerçekçi olduğuna dair şeffaflıktır. Skorlar düzenli olarak gözden geçirilip küçük, somut önlemlerle ilişkilendirildiğinde, tasarım masasında kalmayan, günlük işleyişe dayanan bir modernizasyon yol haritası ortaya çıkar.

Eğer skorlama modelini uygulama portföyünüz için kurmak ya da ilk değerlendirmeleri moderatörlü bir formatta yapmak istiyorsanız, uygun başlangıcı burada bulabilirsiniz: İletişime geçin.

Bu konu için ayrıca Teknik Borçları Değerlendirmek ve Portföy Kararları IT de önemlidir. Yazı bu boyutları anlaşılır şekilde sınıflandırıyor ve günlük uygulamada nelere dikkat edilmesi gerektiğini gösteriyor.

Proje veya modernizasyon girişimini Net-Base ile görüşün.