İçindekiler
Onay süreçlerini ölçmenin en hızlı yolu onaylananlara bakmak değildir. Reddedilenlere bakmaktır. Çünkü bir kontrolün gerçekten çalıştığını gösteren şey, geçirdikleri değil, geçirmedikleridir. Bu yazı tek bir soruyu ve o sorunun neden bu kadar iyi çalıştığını anlatıyor.
Denetçinin Sevdiği Soru
"Geçen çeyrekte kaç değişiklik talebi reddedildi? Listeyi görebilir miyim?"
Soru tek cümledir ve cevabı bir sayıdır. Ama o sayı, bir saatlik süreç anlatımından daha çok şey söyler. Kurumun onay akışı şemasını dinlemeden, kontrolün eleme yapıp yapmadığını doğrudan gösterir.
Çoğu kurumda cevap iki biçimde gelir. Birincisi: "Sanmıyorum, genelde her şey onaylanır." İkincisi: "Vardır ama bir listesi yok, bakmam gerekir." İkisi de aynı sonuca çıkar.
Sıfır Neden Bir Başarı Değil
"Hiçbir talebimiz reddedilmedi" cümlesi ilk duyulduğunda iyi bir şey gibi gelir. Ekip disiplinli, talepler kaliteli, süreç akıcı. Denetçi kulağında ise bu cümle farklı çalar: kontrol eleme yapmıyor.
Bir onay adımının anlamı, hayır diyebilme ihtimalinden gelir. Hayır deme ihtimali hiç gerçekleşmiyorsa, o adım bir kapı değil bir turnike sayacıdır: herkesi geçirir, yalnız sayar. Üç ihtimal vardır ve üçünü de ayırt etmek gerekir:
- Talepler gerçekten kaliteli ve red gerekmiyor. Mümkündür, ama o zaman düzeltme turlarının sayısı görünür olmalıdır: kaç talep geri gönderilip düzeltildi?
- Red oluyor ama kaydı tutulmuyor. En yaygın durum budur.
- Onay bir biçimsel tıklamaya dönüşmüş. Onaylayan kişi karar için gereken bilgiyi görmediği için okumadan onaylıyor.
Üçüncü ihtimal, onay yorgunluğu olarak bilinir ve tasarım hatasıdır, karakter hatası değil. Onaylayanın ekranında karar için gereken her şey yoksa (tetiklenen kural, etkilenen nesneler, risk gerekçesi, geri alma planı) okumadan onaylamak akılcı davranıştır.
Çerçeveler Ne Diyor
Red kaydı bir tercih değil, çerçevelerin açıkça istediği bir şey. COBIT 2019'un değişiklik yönetimi alanında, değişikliklerin durumunu izleyip raporlayan bir sistemin bulunması ve bu sistemin reddedilen değişiklikleri de belgelemesi beklenir. Cümlenin içinde "de" var: onaylananlar zaten belgelenir, ayrıca istenen şey reddedilenlerdir.
Gerekçesi de mantıklıdır. Reddedilen talep, kontrolün çalıştığının tek doğrudan kanıtıdır. Ayrıca reddin kaydı olmadan şu soru cevaplanamaz: reddedilen bir talep daha sonra başka bir yoldan üretime ulaştı mı?
Reddin Kaybolduğu Üç Yer
1. Konuşmada
En yaygın biçim budur. Talep resmi olarak açılmadan önce bir sohbet penceresinde veya koridorda konuşulur, deneyimli bir kişi "bunu böyle yapmayalım" der ve konu kapanır. Kontrol gerçekten çalışmıştır; kötü bir değişiklik üretime gitmemiştir. Ama hiçbir yerde iz yoktur. Denetim gününde kurum, kendi başarısını gösteremez.
2. Silinen bilette
Talep açılır, tartışılır, sonra kapatılır veya silinir. Bilet sistemlerinde kapatma nedeni çoğu zaman serbest metindir ve "iptal" ile "reddedildi" aynı kutuya düşer. İkisi çok farklı şeydir: iptal talep sahibinin kararıdır, red onaylayanın kararıdır. Aynı durum kodunda toplandıklarında ikisi de sayılamaz hale gelir.
3. Onaylanıp hiç çalıştırılmayan talepte
Bu en sinsi olanıdır. Talep onaylanır ama bir daha dokunulmaz. Kayıtta durumu "onaylandı" olarak kalır ve istatistiklerde başarılı bir onay gibi görünür. Gerçekte ne olduğu bilinmez: vazgeçildi mi, başka yoldan mı yapıldı, unutuldu mu? Ölü talepleri ayrı bir durumla kapatmayan her sistemde bu birikim büyür.
Bir Red Kaydı Ne Taşımalı
"Reddedildi" damgası tek başına yetmez. Kayıt şu beşi taşımalıdır:
| Alan | Neden gerekli |
|---|---|
| Reddedilen metnin kendisi | Aynı betik daha sonra başka bir talepte gelirse fark edilebilsin. |
| Red gerekçesi | Serbest metin bile olsa, kararın nedenini taşır. Gerekçesiz red bir tercih gibi görünür. |
| Reddeden kişi ve rolü | Kararın yetkili bir tarafça verildiğini gösterir. |
| O gün yürürlükte olan kural seti | Aylar sonra "bu neden reddedildi" sorusuna bugünkü kuralla değil, o günkü kuralla cevap verilebilsin. |
| Talepte istenen değerler | Reddedilen bir ayar değişikliğinde, istenen değerin ne olduğu kayıtta kalmalıdır; canlı kayda hiç yazılmadığı için başka yerde bulunamaz. |
Gri Alan: Sessiz Red
Dürüst olmak gerekirse hiçbir sistem koridorda söylenen "bunu yapmayalım" cümlesini yakalayamaz. Yakalanabilecek olan farklıdır: talebi sisteme girmenin maliyetini o kadar düşürmek ki, konuşma yerine talep açmak daha kolay hale gelsin.
Bir talep açmak on dakika sürüyorsa, insanlar önce konuşup sonra emin olduklarında talep açarlar ve red hiç görünmez. Bir talep açmak iki dakika sürüyorsa, tartışma taleple birlikte başlar ve red kayda geçer. Kayıt oranını yükselten şey daha sıkı kural değil, daha düşük sürtünmedir.
Dört Sayıyla Ölçün
Onay sürecinizin sağlığını dört sayı özetler. Hiçbiri onay adımı sayısı değildir:
- Red oranı. Geçen çeyrekte reddedilen talep sayısı bölü toplam talep. Sıfırsa neden sıfır olduğunu araştırın.
- Düzeltme turu. Kaç talep geri gönderilip düzeltildikten sonra onaylandı? Red sıfırken bu sayı yüksekse süreç aslında çalışıyordur.
- Talepten çalıştırmaya geçen süre. Onay adımı sayısını değil süreyi ölçün. Süre uzarsa iş başka kanaldan yapılır.
- Onaylanıp çalıştırılmamış talep sayısı. Bu sayı büyüyorsa süreç kağıt üzerinde işliyor, sahada başka bir şey oluyordur.
Bu dört sayıyı bugün üretebiliyorsanız süreciniz ölçülebilir durumdadır. Üretemiyorsanız, süreç hakkında söylenen her şey deneyime dayalı bir tahmindir. Deneyim değerlidir; denetimde kanıt yerine geçmez.
Dört sayıyı üretebilir hale gelin
Red oranı, düzeltme turu, geçen süre ve onaylanıp çalıştırılmamış talep sayısı hazır raporlarda durur. Kendi verinizle nasıl göründüğünü gösterelim.
Demo Planlayın →