Talep genellikle şöyle geliyor: “Sistemde çok fazla eski program var, kullanılmayanları temizleyelim.” Cümle mantıklı. Sıkıntı bir sonraki adımda başlıyor — temizliği kimse listeye bakmadan yapamaz, listeye bakan da çoğu zaman listeye fazla güvenir.
Yıllar içinde birikmiş Z ve Y programları her SAP sisteminin gerçeği. Bazıları hâlâ kritik, bazıları unutulmuş, bazıları yılın yalnızca bir gününde çalışıyor. Üçü de aynı listede yan yana duruyor.
Aday listesinin sınırı nerede?
Kullanım analizi production sisteminde, seçilen tarih aralığı için çalışır. Hangi programın hangi kullanıcı tarafından, hangi tarihte ve kaç kez çalıştırıldığı toplanır; aynı dönemde hiç çalıştırma kaydı bulunmayan programlar ayrı bir liste hâline gelir.
Kapsamı net söylemek şart: bu liste sistemdeki kullanılmayan tüm ABAP kodunu göstermez. TRDIR üzerinden belirlenen Z/Y çalıştırılabilir program adaylarını kapsar. Fonksiyon modülleri, sınıflar ve include’lar bu listeye girmez — bir program hiç çağrılmıyor olsa bile içindeki mantık başka bir yerden kullanılıyor olabilir.
Bir de sistem ayrımı var: statik kod taraması geliştirme sistemine, kullanım toplama production sistemine bağlanır. Aynı modülün iki ayrı sisteme baktığını bilmek, sonucu yorumlarken işe yarıyor.
Üç aylık pencere yıl sonunu göremez
Dönem seçimi sonucu doğrudan değiştirir. Üç aylık bir aralık seçtiyseniz, yıl sonu kapanışında çalışan program “kullanım kaydı yok” tarafında görünür. Envanter sayımı, yasal bildirim ve dönem kapanış işleri bu tuzağın klasik örnekleri.
Pratik yaklaşım basit: dönemi en az bir tam iş çevrimini kapsayacak biçimde seçin ve şüpheli bir adayı paket sahibiyle konuşmadan kapatmayın. Aday listesinde ignore yönetimi de var; “bu program yılda bir çalışır, listeden çıkarın” kararını gerekçesiyle kaydetmek, sonraki turda aynı tartışmayı yeniden açmayı önlüyor.
Kullanım kaydı, statik bulgu ve aylık iş yükü
Elinizde aslında üç ayrı kanıt türü var ve üçü farklı soruya cevap veriyor.
- Kullanım kaydı. Bu program seçilen dönemde çalıştı mı, kim çalıştırdı, kaç kez?
- Statik bulgu. Kodun içinde performans açısından sorunlu bir kalıp var mı?
- Aylık sistem iş yükü. SAP’nin aylık toplulaştırılmış verisinde yanıt, işlemci ve veritabanı süreleri ne söylüyor? Hitlist kayıtları ve iki dönem karşılaştırması burada duruyor.
Bu üçünü tek bir “kod sağlığı” rakamına indirmek yanlış sıralama üretir. Her gün çok kez çalışan ve döngü içinde okuma yapan bir program, hiç çalışmayan ama kötü yazılmış bir programdan önce gelir. Aylık veri toplulaştırılmıştır; kaynak kod satırına kadar iz vermez, ama hangi işin sistemi yorduğunu gösterir.
Silme kararı teknik bir karar değil
Listeden çıkan sonuç “bu program silinebilir” demez, “bu programa bakılmalı” der. Silme, arşivleme ve devre dışı bırakma kurumun değişiklik yönetimi süreciyle yürür. CPA bu kararı vermez; kararı verecek kişiye kanıt üretir.
Zaten temizlik projelerinin çoğu teknik nedenlerle değil, sahiplik belirsizliği yüzünden yarım kalıyor. Aday listesinin yanına paket sahibinin adını yazmak, çoğu zaman listenin kendisinden daha çok iş görüyor.
Başlamak için bütün sistemi taramaya gerek yok. Bir tam mali yılı kapsayan bir dönem seçelim, tek bir Z paketi için kullanım listesini birlikte çıkaralım ve ilk on adayı sahipleriyle konuşulabilir bir forma getirelim. Silme kararı ikinci toplantının konusu olsun.