İç Denetimde Veri Analitiği: Organizasyonel Rolü ve Kullanım Alanları

İç denetimde veri analitiğinin en somut karşılığı bu başlıklardadır. Aşağıdaki kontrollerin ortak özelliği şudur: hiçbiri belge inceleyerek makul bir sürede tespit edilemez. Hepsi veriyle dakikalar içinde tespit edilir.

Görevler ayrılığı ihlalleri

Görevler ayrılığı (segregation of duties) basitçe şu demektir: Bir ödemeyi talep eden kişi ile onaylayan kişi aynı olmamalıdır. Aynı kullanıcının hem tedarikçi kartı açıp hem ödeme onayı vermesi bu ilkenin klasik ihlalidir.

Sorun genellikle yetki matrisinin yanlış tasarlanmış olması değildir. Matris kâğıt üzerinde doğrudur; ihlal geçici yetkiler, vekâlet tanımları ve iş çıkışında kapatılmamış roller veya görevler üzerinden oluşur. Yetki tablosuna bakan bir denetim bunu göremez.

Analitik yaklaşım, yetki tablosu ile işlem loglarını kesiştirir. Sorulan soru “kimin yetkisi var” değil, “kim fiilen ne yaptı” sorusudur. İki cevap arasındaki fark, çoğu şirkette kimsenin bakmadığı yerdedir.

Mükerrer ve hatalı ödemeler

Aynı fatura numarasının farklı tedarikçi kodlarıyla, aynı tutarın farklı tarihlerde, aynı IBAN’ın farklı unvanlarla kaydedilmesi. Tam popülasyon üzerinde bulanık eşleştirme (fuzzy matching) ile taranır — çünkü kayıtlar nadiren birebir aynıdır.

Bu çoğu zaman bir suistimal bulgusu değil, süreç ve ana veri kalitesi bulgusudur. Doğrudan nakit etkisi olduğu için yönetimin en hızlı aksiyon aldığı alandır ve bir analitik programının ilk somut getirisini genellikle burası üretir. Bu bulguların kaynağı çoğu zaman verinin kendisidir. Aynı müşteri, tedarikçi veya stok kalemi için açılmış birden fazla kayıt, mükerrer ödemenin hem sebebi hem göstergesidir. Veri analitiği uygulanmadan önce verinin temizlenmesi ve teste uygun hale getirilmesi gerekir; bu, analitik çalışmasının içine sıkıştırılabilecek bir adım değil, ayrı ve uzmanlık gerektiren bir çalışmadır.

Onay limiti aşımının gizlenmesi

Onay limiti 100.000 TL ise, 180.000 TL’lik bir ihtiyaç aynı gün aynı tedarikçiye iki ayrı 90.000 TL’lik siparişle geçilebilir. Her iki sipariş de tek tek kurallara uygundur. İhlal yalnızca birlikte bakıldığında görünür.

Analitik: tedarikçi–tarih–tutar kümelemesi ve tutar dağılımının onay eşikleri çevresinde incelenmesi. Eşiğin hemen altında anormal yığılma, tek başına güçlü bir göstergedir ve genellikle bir kontrol tasarımı sorununa işaret eder.

Kaynak: TeoLupus

Bayi ve franchise ağı denetimi

Coğrafi olarak dağılmış bir bayi ağında yerinde denetim pahalıdır ve doğası gereği örneklemdir. Ciro bildirimi, stok devir hızı, iade oranı ve iskonto kullanımının bayi bazında karşılaştırmalı analizi, yerinde denetim ekibini veriyle seçilmiş bayilere yönlendirir. Denetim maliyeti düşer, isabet oranı yükselir.

Benford analizi — ve sınırları

Benford Yasası, doğal olarak oluşan sayı kümelerinde ilk basamak dağılımının belirli bir örüntü izlemesine dayanır. Sapma, incelenmeye değer bir anomali işaretidir.

Burada dürüst olmak gerekir: Benford analizi suistimal tespit etmez, inceleme gerektiren anomaliyi işaretler. Uygunsuzluğun masum açıklamaları vardır — fiyat eşikleri, yuvarlama politikaları, onay limitleri. Uygunluk ise suistimalin yokluğunu kanıtlamaz.

UZMAN NOTU

Benford analizi her veri kümesine uygulanamaz ve yanlış uygulandığında iç denetim raporunun güvenilirliğini zedeler.

Hacim: ISACA, güvenilir sonuç için 1.000 ve üzeri kayıt önerir; 500 kaydın altındaki kümelerde yanlış pozitif oranı kullanılamaz düzeye çıkar.

Uygulanamayacak veriler: Formülle veya atama yapısıyla üretilenler (fatura numarası, hesap kodu, sıra numarası), alt/üst sınırla kısıtlı olanlar (saatlik ücret), dar bantta toplananlar. Veri birkaç büyüklük mertebesine yayılmalıdır.

Test seçimi: Ki-kare testinin bu alandaki yaygın kullanımı, örneklem büyüklüğüne aşırı duyarlılığı nedeniyle eleştirilmektedir; SSD (Sum of Squared Deviations) ölçütü tercih edilmelidir (Kossovsky, Stats, 2021).

Benford herhangi bir IIA standardında yer almaz. “Yaygın kabul görmüş analitik teknik” olarak sunulmalıdır, “standardın öngördüğü yöntem” olarak değil.

Orta ölçekli bir ambalaj üreticisinde, satın alma sürecinde tek bir analitik testin nasıl işlediğini izleyelim. (Aşağıdaki senaryo, birden fazla projeden derlenmiş anonim bir örnektir.)

Soru: Onay limitleri fiilen çalışıyor mu? Veri analitiğinin tek bir testte nasıl işlediğini bu örnek üzerinden izleyebilirsiniz.

Veri: 14 aylık satın alma siparişi — yaklaşık 31.000 satır. Çekilen alanlar: sipariş no, tarih, tedarikçi kodu, tutar, talep eden, onaylayan, onay tarihi.

Test: Tutar dağılımının onay eşikleri çevresinde incelenmesi; ardından aynı tedarikçiye 72 saat içinde geçilen ve toplamı bir üst eşiği aşan sipariş gruplarının tespiti.

İlk çalıştırma: 240 işaretli grup. Bunların büyük bölümü meşru çıkar — çerçeve anlaşması kapsamındaki tekrarlayan siparişler, aynı gün girilen kalem bazlı bölünmeler.

Kalibrasyon: Çerçeve sözleşmesi olan tedarikçiler ve stok yenileme siparişleri hariç tutulur. İşaretli grup sayısı 19’a iner.

Bulgu: 19 grubun 11’i tek bir satın alma sorumlusunda ve dört tedarikçide yoğunlaşıyor. Kök neden bir suistimal değil, bir kontrol tasarımı boşluğu: sistem, aynı tedarikçiye kısa aralıkla geçilen siparişleri toplamıyor, dolayısıyla eşik fiilen kişi başına değil sipariş başına çalışıyor.

Aksiyon: ERP’de kümülatif eşik kontrolü tanımlanır. Denetim, kuralı aylık çalıştırılacak bir göstergeye dönüştürür.

Bu örneğin anlatmak istediği nokta şudur: analitiğin ürettiği değer, yakaladığı suistimalde değil, görünmeyen kontrol tasarımı hatasını görünür kılmasındadır. Suistimal bulguları istisnadır; tasarım hataları kuraldır.

Bu ayrım Türkçe kaynaklarda en sık karıştırılan konudur ve yönetişim açısından belirleyicidir.

Sürekli izleme (continuous monitoring) yönetimin sorumluluğundadır. Kontrolün kendisidir; süreci işleten birim tarafından kurulur ve işletilir. Üç Hat Modeli’nde birinci ve ikinci hattın işidir.

Sürekli denetim (continuous auditing) iç denetimin sorumluluğundadır. Yönetimin kontrollerinin çalışıp çalışmadığını bağımsız olarak test eder. Üçüncü hattın işidir.

Pratikteki hata şu şekilde oluşur: İç denetim bir analitik kural seti kurar, bulguları yönetime raporlar, zamanla bu kural setinin işletilmesi denetimin rutin görevi haline gelir. Bu noktada iç denetim kendi kurduğu kontrolü denetler duruma düşer ve bağımsızlığını kaybeder.

Bu ayrım, kurumsal risk yönetimi yapısının nasıl kurulduğuyla doğrudan ilgilidir. Doğru kurgu üç adımlıdır: İç denetim kuralı geliştirir, etkinliğini kanıtlar, operasyonel işletimini ilgili birime devreder. Denetim, kuralın işletildiğini test etmeye geri döner. Devir olmadan kurulan her sürekli denetim programı, birkaç yıl içinde bir bağımsızlık sorununa dönüşür.

UZMAN NOTU

Üç Hat Modeli terminolojisi güncellenmiştir. IIA 2020’de “savunma hattı” (lines of defence) ifadesini terk etti. 2020 tarihli doküman da artık güncel değildir. IIA 8 Temmuz 2026‘da yeni bir Statement of Position on the Three Lines Model yayımladı ve önceki metnin yerine geçirdi. Yeni metin birincil muhatabı yönetim kurulu olarak tanımlar. Aynı tarihte iç denetimin kurumsal risk yönetimindeki rolüne ilişkin pozisyon metni de yenilendi.

Kontrol çerçevesi tarafında iki ayrı referans vardır. COSO Internal Control — Integrated Framework (2013) beş bileşen ve 17 ilkeden oluşur. COSO Enterprise Risk Management — Integrating with Strategy and Performance (2017) ise beş bileşen ve 20 ilke içerir. Bileşen listeleri birleştirilmemelidir. 2017 metninin adı Integrated Framework değildir; o başlık 2004 sürümüne aittir.

Veri analitiğinin ham maddesi ERP’dedir. Bu iki sonuç doğurur.

Birincisi, ana veri kalitesi analitiğin tavanını belirler. Tedarikçi ana verisinde aynı firma dört farklı kodla kayıtlıysa mükerrer ödeme analizi çalışmaz. Analitik projelerinin gerçekçi ilk fazı model kurmak değil, ana veri ve süreç haritası çıkarmaktır. Bu fazı atlayan projeler, teknik olarak doğru ama işletme açısından anlamsız çıktılar üretir.

İkincisi, ERP kurulum ve geçiş projeleri kontrolleri sisteme gömmek için en ucuz andır. Yetki matrisi, onay hiyerarşisi, zorunlu alan tanımları ve log politikası devreye alma sırasında tasarlanırsa maliyeti düşüktür. Aynı kontroller canlı sistemde sonradan kurulduğunda, üzerine süreç değişikliği ve kullanıcı direnci maliyeti biner.

Türkiye’de ERP projelerinin ayrıca bir uyum boyutu vardır. e-Dönüşüm uygulamaları — e-Fatura, e-Arşiv, e-İrsaliye, e-Defter — GİB gereklilikleri kapsamında sistem tasarımını doğrudan etkiler ve denetlenebilir bir iz bırakır. Bu iz, analitik için hazır bir veri kaynağıdır.

Bu nedenle ERP projelerinde(yeni bi ERP’ye geçiş, mevcut ERP’de sürüm güncellemesi gibi) iç denetim perspektifinin projenin başında masada olması, sonradan yapılacak uyum çalışmasından belirgin biçimde ekonomiktir.

Veri neden kirlenir: ana veri sahipliği

Kirli veri bir dikkatsizlik sonucu değil, bir yetki tasarımı sonucudur.

Çoğu şirkette ana veri sorumlusu tanımlı değildir. Hesap açma, kart oluşturma ve tanım değiştirme yetkileri farklı kişilere ve farklı departmanlara dağıtılmış, birbirinden habersiz işler. Sonuç, aynı müşteri, tedarikçi veya stok kalemi için açılmış çok sayıda kayıttır — ve bu tablo istisna değil, yaygın olandır.

Veri temizliği bu nedenle analitik projesinin içinde eritilebilecek bir adım değildir; ayrı, özenli ve uzmanlık gerektiren bir çalışmadır. Tek başına da yeterli değildir: verinin yeniden kirlenmesini önleyecek mekanizmaların kurulmuş ve fiilen işliyor olması gerekir. Bu mekanizmalar yoksa, aynı temizlik çalışması iki yıl sonra tekrar edilir.

Kaynak: TeoLupus

Bir yöneticinin veri analitiği programı hakkında karar verebilmesi için teknik detaya girmesi gerekmez. Ancak dört soruya cevap vermesi gerekir.

Veri nasıl çıkacak?

Üç yol vardır ve maliyetleri farklıdır. Manuel dışa aktarım en ucuzdur, tekrarlanabilirliği en düşüktür — her çalıştırmada insan müdahalesi gerekir. Zamanlanmış rapor çıktısı orta yoldur; ERP’nin kendi raporlama katmanı üzerinden periyodik dosya üretir. Doğrudan veritabanı bağlantısı veya API en temiz olanıdır, ancak BT tarafında yetkilendirme ve güvenlik çalışması gerektirir.

Karar kriteri şudur: Analitik yılda bir kez mi çalışacak, yoksa aylık bir gösterge mi üretecek? Aylık ise manuel dışa aktarım kısa sürede sürdürülemez hale gelir. Yoksa bazı veriler için haftalık, günlük veya anlık mı çalışacak?

Hangi araç kategorisi?

Üç kategori vardır ve seçim şirketin olgunluğuna bağlıdır.

kaynak: TeoLupus

Yaygın hata, üçüncü kategoriyle başlamaktır. Yazılım satın alındığında kural seti henüz yoktur; lisans kullanılmadan durur. Ancak, doğru dış kaynak kullanıldığında işler daha olumluya dönebilir. Teolupus’un bu alandaki veri analitiği, yapay zeka ve otonom yapay zeka hizmetleri bu konuda organizasyonunuza katma değerli çözümler sunmaktadır.

Yapmak mı, dışarıdan almak mı yoksa eş kaynak mı?

Bu bir kadro kararıdır, teknoloji kararı değil. Kendi içinde kuran şirket, denetim veri analisti profilinde bir kişiyi işe almak ve elde tutmak zorundadır. Orta ölçekli bir P&L’de bu kadro genellikle tam kapasite çalışmaz.

Eş kaynak (co-source) modeli bu sorunu çözer: metodoloji ve kural seti dışarıdan kurulur, işletimi içeride kalır. Bilgi transferi projenin çıktısının parçasıdır.

Maliyeti ne belirler?

Analitiğin karmaşıklığı değil, verinin durumu belirler. Bir projenin süresini uzatan başlıca üç etken şudur: veriye erişimin BT tarafında beklemeye alınması, ana veri düzensizliği ve süreç dokümantasyonunun bulunmaması. Kural yazmak günlerle ölçülür; veriyi güvenilir hale getirmek haftalarla.

Bu nedenle teklif alırken sorulacak doğru soru “kaç test yapılacak” değil, “veri kalitesi doğrulaması kapsamda mı” sorusudur.

UZMAN NOTU

Analitik çıktısının denetim kanıtı niteliği taşıyabilmesi için tekrarlanabilir olması gerekir. Pratikte bu şu anlama gelir: veri çekme sorgusu, uygulanan filtreler, hariç tutma kuralları ve dönüştürme adımları çalışma kâğıdında kayıtlı olmalı; aynı girdiyle aynı çıktı yeniden üretilebilmelidir.

Kaynak veri ile ERP arasındaki mutabakat kanıtı da dosyada bulunmalıdır — satır sayısı, dönem toplamı ve kritik alan toplamları düzeyinde. Bu kanıt yoksa bulgunun kaynağı tartışmaya açıktır.

Kural setinin sürüm kontrolü ayrıca önemlidir: bir kural kalibre edildiğinde önceki dönem bulgularının hangi sürümle üretildiği izlenebilir olmalıdır. Sürümü izlenmeyen bir kural seti, dönemler arası karşılaştırmayı geçersiz kılar.

Veri analitiği programları kabaca dörde ayrılan seviyede ilerler. Şirketin hangi seviyede olduğunu bilmesi, gerçekçi hedef koymasını sağlar.

Seviye 1 — Talep üzerine. Analitik, belirli bir denetim görevinde bir defaya mahsus yapılır. Kural seti kalıcı değildir, çıktı kişiye bağlıdır.

Seviye 2 — Tekrarlanabilir. Kurallar dokümante edilmiştir, periyodik olarak çalıştırılır, sonuçlar dönemler arası karşılaştırılabilir.

Seviye 3 — Entegre. Analitik, risk bazlı iç denetim planının girdisidir. Hangi sürecin denetleneceğine veri karar verir.

Seviye 4 — Sürekli. Kural setinin operasyonel işletimi ilgili birimlere devredilmiştir; iç denetim kuralın işletildiğini test eder ve göstergeleri izler.

Orta ölçekli şirketlerin çoğu Seviye 1’dedir ve gerçekçi ilk hedef Seviye 2’dir. Seviye 4’ü ilk hedef olarak koymak, programın kalibrasyon aşamasında tükenmesine yol açar.

Kaynak: TeoLupus

Olgunluk seviyesi yükselmesinin önündeki engeller teknik engeller değildir. Analitik programlarının başarısız olma biçimleri tahmin edilebilirdir ve dördü de tekrar eder.

Yanlış pozitif yorgunluğu. İlk çalıştırma yüksek sayıda istisna üretir. Kalibrasyon yapılmazsa süreç sahipleri listeyi ciddiye almayı bırakır ve program sessizce ölür. Kalibrasyon bir gecikme değil, projenin zorunlu fazıdır. Uzman desteği önemlidir.

Veriye erişimin şirket içi direnç hale gelmesi. Denetimin ham veri talebi, BT veya süreç sahibi tarafından yavaşlatılabilir. Bu genellikle teknik değil, örgütsel bir dirençtir. Çözümü, veri erişim yetkisinin denetim komitesi veya üst yönetim düzeyinde bir kez tanımlanmasıdır.

Analitik tiyatrosu. Etkileyici gösterge panelleri üretilir, ancak hiçbir kontrol tasarımı değişmez. Ölçüt şudur: Analitik çalışmanın sonunda bir kontrol değişti mi? Değişmediyse üretilen şey rapordur, güvence değil.

Kural setinin bayatlaması. Süreç değişir, ERP güncellenir, kural aynı kalır. Bir yıl sonra kural ya hiç istisna üretmez ya da anlamsız istisna üretir. Kural seti periyodik olarak gözden geçirilmelidir; bu, programın parçasıdır. Analitik yapısına sürekli bakım yapılması çok önemlidir.

ERP verisi üzerinde veri analitiği çalıştırmak, çoğu durumda kişisel veri işlemek anlamına gelir. Personel bordro kayıtları, kullanıcı işlem logları, müşteri ve tedarikçi iletişim bilgileri bu kapsamdadır.

Suistimal tespiti veya görevler ayrılığı testi yapıyor olmak, tek başına bir işleme dayanağı oluşturmaz. Dayanağın önceden belirlenmesi ve veri kapsamının buna göre daraltılması gerekir.

UZMAN NOTU

6698 sayılı Kişisel Verilerin Korunması Kanunu (2016) kapsamında, ERP verisi üzerinde denetim analitiği çalıştırılırken şu yükümlülükler doğar:

İşleme dayanağı (Md. 5). İç denetim faaliyetinde pratikte Md. 5/2-(ç) (veri sorumlusunun hukuki yükümlülüğü) ve/veya Md. 5/2-(f) (meşru menfaat) dayanak alınır. Alt bentler Türk alfabesine göre sıralanır — meşru menfaat (f) bendidir, (e) değil. Çalışan rızası, iş ilişkisindeki güç dengesizliği nedeniyle güvenilir bir dayanak sayılmaz.

Ölçülülük (Md. 4/2-(ç)). Veri “işlendikleri amaçla bağlantılı, sınırlı ve ölçülü” olmalıdır. Denetim amacı için gerekmeyen alanların çekilmesi başlı başına bir ihlaldir.

Aydınlatma (Md. 10) ve veri güvenliği tedbirleri (Md. 12) ayrıca uygulanır. KVKK’nın Kişisel Veri Güvenliği Rehberi (Ocak 2018) yetki matrisi, erişim politikaları ve düzenli log kaydı tutulmasını öngörür — yani analitiğin dayandığı log altyapısı zaten bir KVKK gerekliliğidir.

Kurul’un işveren tarafından çalışan verisi işlenmesine ilişkin kararları bu alanda yol göstericidir. Doğru kurgulanmış bir iç denetim analitiği projesi, KVKK uyumunu sonradan eklenen bir madde olarak değil, veri kapsamı tasarımının parçası olarak ele alır.

Orta ölçekli şirketlerde en sık duyulan itiraz budur. Üç gözlemle yanıtlanabilir.

Veri hacmi engel değil, avantajdır. KOBİ ve orta ölçekli şirketlerde iç kontrol yapısı büyük kurumlardakinden daha sade olduğu için analitik de daha hızlı kurulur. 40.000 satırlık bir satın alma verisi, milyonlarca satırlık bir veriden analitik olarak daha kolay yönetilir. Büyük kurumlarda projelerin uzamasının nedeni analitiğin kendisi değil, sistem parçalanmışlığı ve örgütsel karmaşıklıktır. Tek ERP üzerinde çalışan orta ölçekli bir şirket ilk anlamlı sonucu haftalar içinde alır.

Ayrı bir ekip gerekmez. Kapasite kadro kurarak değil, eş kaynak modeliyle edinilebilir. Bu, orta ölçekli bir şirket  için bir iç denetim veri analisti kadrosundan belirgin biçimde uygundur.

Kapsam dar başlar. Bir veri analitiği programı tüm süreçlerle başlamaz. Nakit etkisi en yüksek ve verisi en temiz tek süreçle — genellikle satın alma veya ödeme — başlar, sonuç üretir, sonra genişler.

Global denetim ağlarının bu kapasiteyi uzun süredir sunduğu doğrudur. Erişilemez olduğu ise doğru değildir. Fark yöntemde değil, hizmet ekonomisindedir.

TeoLupus, İstanbul merkezli güvence hizmetleri ve yönetim danışmanlığı firmasıdır ve hizmetlerini Türkiye genelinde sunar. İç denetim ve kurumsal risk yönetimi çalışmalarını veri analitiği ile birlikte kurgularız. Tipik bir analitik projesinin akışı şöyledir:

Faz 1 — Kapsam ve veri envanteri. Hangi süreç, hangi ERP modülü, hangi tablolar, hangi alanlar. KVKK veri kapsamı bu fazda tanımlanır. Sizden gereken: süreç sahibi ve BT’den birer kişi, sınırlı zaman.

Faz 2 — Veri kalitesi doğrulaması. Çekilen verinin kaynak sistemle mutabakatı. Atlanırsa sonraki tüm bulgular tartışmaya açık hale gelir.

Faz 3 — Kural setinin geliştirilmesi ve kalibrasyonu. İlk çalıştırmada yanlış pozitif oranı yüksektir; kurallar süreç sahibinin geri bildirimiyle daraltılır.

Faz 4 — Bulguların değerlendirilmesi ve raporlama. Anomali listesi değil, kök neden ve kontrol tasarımı önerisi.

Faz 5 — Devir ve tekrarlanabilirlik. Kural setinin dokümantasyonu, periyodik çalıştırma sorumluluğunun tanımlanması, göstergelerin belirlenmesi.

Tek süreçli bir kapsamda Faz 4’e kadar olan bölüm genellikle haftalarla ölçülür. Şirketten sürekli tam zamanlı kaynak talep edilmez; yoğunluk Faz 1 ve Faz 2’dedir.

Butik modelin buradaki karşılığı şudur: Kural seti sektörünüzün süreç yapısına göre yazılır, çalışmayı Partner  gözetiminde uzman bir ekip yürütür ve kapsam şirketinizin ölçeğine, dijital olgunluk seviyesine ve kurum kültürüne  göre belirlenir ve yürütülür. Metodoloji TeoLupus’un kendisine özgüdür, global disiplinle sistematiği standardını içerir; farklı olan, orta ölçekli bir bütçeye her bir şirketin ihtiyaçlarının butik olarak belirlenmesi ve yetkin kadronun sunduğu kaliteye uyarlanmış olmasıdır.

Kaynak: TeoLupus

Mevcut iç denetim yaklaşımınızın analitikle nasıl güçlendirilebileceğini konuşmak için bizimle iletişime geçebilirsiniz.

Veri analitiği programı olan ya da kurmayı planlayan bir şirkette, denetim komitesi veya yönetim kurulu şu soruları sorarak programın gerçek olup olmadığını anlayabilir:

• Son denetim raporundaki bulgular popülasyonun tamamı üzerinden mi, örneklem üzerinden mi üretildi?
• Analitik senaryolarının sektörü temsiliyeti, çeşitliliği ve derinliği ne durumda? Analitik çalışmanın sonunda hangi kontrol tasarımı değişti?
• Kural setini kim işletiyor — iç denetim mi, süreç sahibi mi? (Denetim işletiyorsa bir bağımsızlık sorusu vardır.)
• Veri kalitesi doğrulaması yapıldı mı, kanıtı dosyada mı?
• Kullanılan kişisel verinin KVKK dayanağı ve kapsam sınırı tanımlı mı?

Bu beş sorunun cevabı, bir analitik programının olgunluk seviyesini teknik bir inceleme yapmadan ortaya koyar.

İç denetimde veri analitiği bir araç değil, güvence düzeyini değiştiren bir yöntem değişikliğidir. Örneklemden tam popülasyona geçiş, iç denetimin yönetim kuruluna verdiği cevabın niteliğini değiştirir.

Bu dönüşümün önündeki engel teknoloji değildir. Engel genellikle üç tanedir: Ana veri kalitesi, sürekli denetim ile sürekli izleme arasındaki yönetişim ayrımının kurulmamış olması ve KVKK kapsamının tasarıma dahil edilmemiş olması. Üçü de proje başında ele alınabilir; sonradan ele alındığında maliyetlidir.

Veri analitiğinde başlangıç noktası bir yazılım seçimi değil, tek bir sorudur: Hangi sürecin kontrollerinin fiilen çalıştığını bilmiyorsunuz? Analitik oradan başlar. Veri analitiğinde başlangıç noktası bir yazılım seçimi değil, tek bir sorudur: Bugün, hangi süreçlerinizdeki kontrollerin çalıştığını kanıtlayabiliyorsunuz? Kanıtlayamadığınız her süreç, veri analitiğinin başlangıç noktasıdır.

Veri analitiği için ayrı bir yazılım yatırımı gerekir mi?

Ayrı bir yazılım yatırımı, başlangıç aşaması için zorunlu değildir. İlk aşama çalışmalar mevcut ERP’den alınan veri üzerinde yürütülebilir. Özel bir iç denetim analitiği yazılımı, program kalıcı hale geldiğinde ve tekrarlayan test sayısı arttığında gündeme gelir. Yazılımla başlamak yaygın bir hatadır; kural seti yokken alınan lisans kullanılmadan durur. Veri analitiğinin sonraki aşamalarında ileri veri analitiği, yapay zeka ve otonom yapay zeka gibi projeler planlanabilir.

ERP’miz eski veya birden fazla sistem kullanıyoruz. Yine de mümkün mü?

Eski veya parçalı ERP yapısında veri analitiği mümkündür, ancak veri kalitesi doğrulama fazı uzar. Belirleyici olan sistemin yeni olması değil, verinin dışa aktarılabilir ve kaynağıyla mutabık olmasıdır. Parçalı sistem yapısında ilk kapsamın tek sistemle sınırlanması önerilir; kapsamı genişletmek sonraki adımdır. Veri temizliği ve düzenlemesine özel önem vermek gerekir.

İç denetim ekibimiz yok. Bu çalışma yine de anlamlı mı?

İç denetim ekibi bulunmayan şirketlerde veri analitiği çalışması anlamlıdır. Bu tür şirketlerde analitik çalışma çoğu zaman ilk yapılandırılmış kontrol testidir ve fonksiyonun kurulmasına zemin hazırlar. Eş kaynak ve dış kaynak modelleri tam da bu durum için tasarlanmıştır. Türkiye’de özel şirketler için iç denetim geniş kapsamlı bir yasal zorunluluk değildir; bu bir yönetim tercihidir. Halka açık şirketler için ise çeşitli düzenlemelerin yanında TTK m. 378 uyarınca riskin erken saptanması ve yönetimi komitesi kurulması zorunludur.

Çalışanlarımızın verisini incelemek hukuki risk yaratır mı?

Çalışan verisi üzerinde yürütülen analitik çalışma, kapsamı doğru tanımlanmadığında hukuki risk yaratır. KVKK açısından veri işleme dayanağının belirlenmesi, veri kapsamının denetim amacıyla sınırlandırılması ve aydınlatma yükümlülüğünün karşılanması gerekir. Bunlar proje tasarımının parçasıdır, sonradan eklenen bir formalite değildir. Şirketinize özel değerlendirme için hukuk danışmanınızla birlikte çalışılması uygun olacaktır.

Bulgular çalışanlar için disiplin sürecine dönüşür mü?

Bulguların disiplin sürecine dönüşüp dönüşmeyeceği şirketin politika tercihidir, denetimin kararı değildir. Analitik çıktısı kontrol zafiyetini gösterir; kişisel sorumluluk değerlendirmesi ayrı bir süreçtir ve ayrı usul güvenceleri gerektirir. Bu ayrımın proje başında netleştirilmesi, bulguların kurum içinde kabul görmesini de kolaylaştırır.

Bir analitik çalışması ne kadar sürer?

Tek süreçli bir kapsamda, veri kalitesi makul düzeydeyse, ilk anlamlı bulgu seti haftalarla ölçülür. Süreyi uzatan başlıca etken analitiğin karmaşıklığı değil, veriye erişim ve ana veri düzensizliğidir. Teklif değerlendirirken veri kalitesi doğrulamasının kapsama dahil olup olmadığına bakılması önerilir.

Bulgular kime raporlanır?

İç denetim bulguları, bağımsızlığın gereği olarak yönetim kuruluna veya denetim komitesine raporlanır; icra bu raporun muhatabı değil, konusudur. Aksiyon planı ve sorumlu ataması icra tarafında yapılır, takip denetimi ise denetim tarafından yürütülür.