Yazılım projesinde yüklenici denetimi, sözleşme imzalandıktan sonra işin şartnameye göre ilerleyip ilerlemediğini alıcı adına düzenli olarak kontrol etmektir. Etkili denetim üç şeye dayanır: ölçülebilir ara teslimler, alıcının kendi ortamında gördüğü çalışan demolar ve senaryo bazlı kabul testi. Böylece sapma teslim gününde değil, ilk haftalarda fark edilir.
Sorun: sözleşme imzalanınca kontrol yükleniciye geçiyor
Çoğu kurumda yazılım alımının en yoğun emeği teklif toplama ve sözleşme aşamasına harcanır. İmzadan sonra ise süreç sessizleşir: yüklenici "geliştirme devam ediyor" der, ayda bir toplantı yapılır, ekran görüntüleri paylaşılır. Aylar sonra ilk gerçek teslim geldiğinde ekipler şunu fark eder: rapor ekranı beklendiği gibi değil, ERP entegrasyonu "ikinci faza" kalmış, kullanıcı yetkileri hiç konuşulmamış.
Bu noktada sorunun kaynağı genellikle kötü niyet değildir. Alıcının kafasındaki iş ile yüklenicinin anladığı iş arasında baştan bir boşluk vardır ve kimse bu boşluğu düzenli aralıklarla ölçmemiştir. Yüklenici denetimi, o boşluğu teslim gününe bırakmadan kapatmanın yöntemidir.
Denetimi zorlaştıran üç tipik durum var:
- Kurumda teknik muhatap yok. Proje sahibi genellikle iş birimidir; kod kalitesini, mimariyi veya test kapsamını değerlendirecek biri kadroda bulunmaz.
- Şartname ölçülemez ifadelerle yazılmış. "Kullanıcı dostu", "hızlı", "güvenli" gibi maddeler ara teslimde de kabulde de test edilemez. Bu konuyu test edilebilir teknik şartname nasıl hazırlanır yazımızda ayrıntılı ele aldık.
- Ödeme takvimi teslimlere bağlı değil. Ödemeler takvime göre yapılıyorsa yüklenicinin öncelik sıralamasında sizin projeniz kolayca geriye düşer.
Denetlemezseniz ne olur: rakamlar
Yazılım ve dönüşüm projelerinin hedeften sapması istisna değil, yaygın bir örüntü:
- BCG'nin 2020 yılında 825 üst düzey yöneticiyle yaptığı araştırmaya göre dijital dönüşümlerin %70'i hedeflerinin gerisinde kaldı; yalnızca %30'u hedeflenen değere ulaşıp kalıcı değişim sağladı (BCG — Flipping the Odds of Digital Transformation Success, 2020).
- ERP tarafında tablo benzer. Panorama Consulting'in 2026 ERP Raporu'na göre katılımcıların dörtte birinden fazlası projesinin bütçeyi aştığını, dörtte birine yakını takvimin gerisinde kaldığını bildirdi. Rapor, bütçe aşımının en yaygın nedenini beklenmeyen ek teknoloji ihtiyacı, takvim aşımının nedenini ise organizasyonel sorunlar olarak gösteriyor. Yani sorunların önemli bölümü kodda değil, kapsam ve yönetimde.
- Türkiye'de işi kurum içinde denetleyecek teknik kadro da sınırlı. TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2026 sonuçlarına göre 10 ve daha fazla çalışanı olan girişimlerin yalnızca %15,2'si BİT uzmanı istihdam ediyor; 10-49 çalışanlı girişimlerde bu oran %10,8. BİT uzmanı arayan girişimlerin %31,7'si de işe alımda güçlük yaşadığını belirtiyor.
Bu üç veri birlikte okunduğunda sonuç açık: projelerin önemli bölümü sapıyor ve çoğu kurumun bu sapmayı teknik olarak görecek bir iç ekibi yok. Denetimsiz geçen her ay, düzeltme maliyetini artıran bir ay demek; çünkü yanlış kurgulanmış bir veri modeli ya da entegrasyon, üzerine inşa edilen her ekranla birlikte daha pahalı hâle gelir.
Yüklenici denetimi için yedi adımlı çerçeve
Aşağıdaki çerçeve, kamu ihalesiyle alınan projelerde de özel sektör sözleşmelerinde de uygulanabilir. Kamuda 4734 sayılı Kamu İhale Kanunu kapsamındaki muayene ve kabul süreçleri ayrıca işler; bu adımlar o resmi sürecin teknik içeriğini doldurmaya yarar.
- Kapsamı iş paketlerine bölün. Şartnameyi "kullanıcı yönetimi", "sipariş modülü", "ERP entegrasyonu", "raporlar" gibi bağımsız teslim edilebilir paketlere ayırın. Her paketin tamamlandığında neyin görüleceği yazılı olsun. Kapsam belirsizse işe yazılım ihtiyaç analizi ile başlayın.
- Ödemeyi ara teslimlere bağlayın. Her hakediş, bir iş paketinin kabul kriterlerini karşılamasına bağlı olsun. Bu tek madde, yüklenicinin önceliklendirmesini en çok etkileyen unsurdur; mantık, inşaatta hakediş takibindeki "yapılan iş kadar ödeme" ilkesinin yazılımdaki karşılığıdır.
- Demoyu kendi ortamınızda isteyin. Sunum ya da ekran görüntüsü değil, sizin erişebildiğiniz bir test ortamında çalışan yazılım. Kullanıcılarınız gerçek veriye benzer örneklerle kendileri denesin. Saha kullanıcısı olan projelerde, örneğin bir inşaat proje takip programında, demoyu şantiyedeki gerçek kullanıcıya tabletten yaptırın.
- Kaynak koduna ve iş takibine erişim alın. Kod deposuna salt okunur erişim, açık iş kayıtları ve sürüm notları denetimin kanıt kaynağıdır. Sözleşmedeki mülkiyet ve teslim maddelerini yazılım sözleşmesinde kaynak kodu yazımızdaki kontrol listesiyle gözden geçirin.
- Sapma kaydı tutun. Her ara teslimde şartnameye uymayan noktaları numaralı bir listede toplayın: madde, beklenen, görülen, önem derecesi, kapanış tarihi. Toplantı notu değil, izlenen bir liste.
- Değişiklik taleplerini ayrı yönetin. Kapsam değişikliği gerekiyorsa yazılı talep, etki analizi (süre ve bedel) ve onayla ilerleyin. "Bunu da ekleyiverelim" kararları bütçe aşımının en sık kaynağıdır; yazılım projesi maliyeti yazımızda bu kalemlerin nasıl büyüdüğünü anlattık. Projenin bütününde hangi giderlerin baştan planlanması gerektiğini dijital dönüşüm maliyet kalemleri yazısında topladık.
- Kabul testini senaryo senaryo yürütün. Her şartname maddesi için en az bir test senaryosu yazın; sonucu (geçti / kaldı / koşullu) tutanağa geçirin. Performans, yetki ve entegrasyon senaryolarını unutmayın.
Ara teslimde neye bakılır?
| Alan | Soru | Kanıt |
|---|---|---|
| Fonksiyon | Paketteki maddeler çalışıyor mu? | Test ortamında kullanıcı denemesi |
| Veri modeli | Alanlar ve ilişkiler şartnameyle uyumlu mu? | Veritabanı şeması, örnek kayıtlar |
| Entegrasyon | ERP / muhasebe bağlantısı gerçek veriyle denendi mi? | Entegrasyon logları, hata senaryoları |
| Güvenlik | Roller ve yetkiler tanımlandı mı? | Rol matrisi, yetkisiz erişim denemesi |
| Kod ve süreç | Kod depoda mı, sürüm notu var mı? | Depo geçmişi, iş takip kayıtları |
| Dokümantasyon | Kurulum ve kullanıcı belgeleri ilerliyor mu? | Taslak belgeler |
Güvenlik satırını yalnızca rol matrisine bakarak kapatmayın. Kişisel veri ya da ödeme bilgisi işleyen sistemlerde canlıya geçişten önce bağımsız bir sızma testi yaptırmayı sözleşmeye yazın; bulguların kapatılması da kabul kriterlerinden biri olsun.
Denetim toplantısı nasıl yürütülür?
Her ara teslimden sonra kısa, gündemi sabit bir toplantı yapın. Önce bir önceki toplantıdan kalan sapmaların durumu konuşulur; kapananlar test ortamında gösterilir, kapanmayanlar için yeni tarih yazılır.
Ardından yeni paketin demosu, alıcı tarafındaki kullanıcılar tarafından yapılır; yüklenici yalnızca soruları yanıtlar. Son olarak açık değişiklik talepleri ve bir sonraki teslimin kapsamı teyit edilir. Toplantının çıktısı güncellenmiş sapma listesi ve iki tarafın onayladığı bir sonraki teslim tanımıdır.
Bu düzen, tartışmayı kişisel izlenimlerden çıkarıp yazılı kanıta taşır.
Sık yapılan üç hata
Denetimi yüklenicinin kendi raporuna bırakmak. Yüklenicinin durum raporu faydalıdır ama bağımsız doğrulama değildir. Rapordaki "tamamlandı" ifadesi, test ortamında sizin gördüğünüzle eşleşmelidir.
Kabulü tek güne sıkıştırmak. Tüm testleri teslim gününe bırakmak, bulunan hataların hepsini aynı anda pazarlık konusu yapar. Paket bazlı kabul, sorunu küçük parçalarda çözer.
Teknik ve iş tarafını ayırmak. İş birimi ekranlara, BT ekibi sunuculara bakar; kimse entegrasyonun gerçek veriyle çalışıp çalışmadığını sormaz. ERP projeleri neden başarısız olur yazımızdaki örneklerin çoğu tam bu boşlukta yaşanıyor.
Digital Bridge'de yüklenici denetimini nasıl yapıyoruz
Digital Bridge 2013'ten bu yana firmaya özel yazılım ve kendi tasarladığı donanımı geliştiriyor. Kurum BT danışmanlığı hizmetimizde bu deneyimi alıcının tarafında kullanıyoruz: yükleniciyi değil, sizi temsil ediyoruz ve önerilerimiz belirli bir marka ya da ürüne göre şekillenmiyor.
- İhaleden önce: İhtiyacı yazılı gereksinimlere dönüştürüyor, her maddesi teslimde test edilebilen teknik şartnameyi ve iş kalemlerine bölünmüş yaklaşık maliyeti hazırlıyoruz. Teslim kriterleri, hizmet seviyesi ve gecikme hükümlerinin teknik tarafını hukuk ekibinizle birlikte netleştiriyoruz.
- Geliştirme sırasında: Ara teslimleri şartnameye göre inceliyor, sapmaları numaralı listeyle erken raporluyoruz. Veri modeli, entegre yazılım sistemleri arasındaki bağlantılar ve API entegrasyonları gibi iş biriminin göremeyeceği noktaları teknik olarak değerlendiriyoruz.
- Teslimde: Kabul testlerini senaryo senaryo yürütüp tutanak hazırlıyoruz.
- Daha geniş resim: Proje, birden fazla yatırımın parçasıysa dijital dönüşüm danışmanlığı ile hangi yatırımın hangi sırayla yapılacağını gösteren yol haritasını birlikte çıkarıyoruz. Planlamadan satın almaya kadar diğer adımları Dijital Dönüşüm rehberimizin tamamında bulabilirsiniz.
Kendi geliştirme ekibimiz olduğu için de, bir özel web yazılımı projesinde hangi aşamanın gerçekte ne kadar emek istediğini ve hangi kısayolun ileride sorun çıkaracağını içeriden biliyoruz. Hazır paket satmıyoruz; her iş ihtiyaç analizi ve kapsamı, aşamaları ve bedeli belli yazılı teklifle başlıyor.
Sonraki adım
Devam eden bir projeniz varsa bu hafta şu üç soruyu yanıtlayın: son ara teslimi kendi test ortamınızda gördünüz mü, açık sapmaların numaralı bir listesi var mı, ödemeleriniz teslimlere mi takvime mi bağlı? Yanıtlardan biri bile "hayır" ise denetim boşluğu var demektir. Yüklenici seçimi henüz yapılmadıysa yazılım firması seçerken sorulacak soruları ve dijital dönüşüm yol haritası rehberimizi okuyun. Projenizi birlikte değerlendirmek için bizimle iletişime geçin; mevcut şartnamenizi ve sözleşmenizi inceleyip denetim planını sizinle birlikte çıkaralım.