KAMU İHALELERİNDE ŞİKAYET VE İTİRAZEN ŞİKAYET SÜRECİNİ YÖNETMEK

Kamu ihalelerinde itiraz mekanizmaları, sadece “hakkını aramak” için değil, aynı zamanda ihale sürecinin şeffaf ve öngörülebilir kalmasını sağlamak için vardır. Ne var ki pratikte en büyük sorun, haklı gerekçelerin bile yanlış süre hesabı, eksik delil veya hatalı dilekçe kurgusu nedeniyle etkisiz kalmasıdır. Bu yazıda, şikayet ve itirazen şikayet süreçlerini uçtan uca yönetmek için sahada işe yarayan bir yaklaşımı adım adım ele alacağız.

Özellikle kurumsal yazılım geliştirme ekipleri ve karar vericiler açısından ihaleler; gereksinim dokümanı, kabul kriterleri, risk yönetimi ve sözleşme hükümleriyle doğrudan ilişkilidir. Bir teknik şartnamedeki muğlak ifade, bir değerlendirme dışı bırakma gerekçesi ya da bir açıklama talebinin yanlış yönetilmesi; şirketin gelir planını, ekip kapasitesini ve ürün yol haritasını etkileyebilir. Bu nedenle şikayet yönetimini “hukuk biriminin işi” olarak görmeyip, proje yönetişimi disiplininin bir parçası gibi ele almak gerekir.

Buradaki hedef; kamu ihalelerinde itirazen şikayet süreci dahil tüm başvuru adımlarını doğru kurgulamak, süreleri kaçırmamak, delil setini standardize etmek ve kurum içi koordinasyonu artırmaktır. İçerik boyunca, hem idareye şikayet hem de Kamu İhale Kurumu (KİK) aşamasında dikkat edilmesi gereken kritik noktaları, gerçekçi örneklerle ve kontrol listeleriyle bir araya getireceğiz. Detaylı öğrenme için kamu ihale eğitimi içeriğine de göz atabilirsiniz.

Şikayet ve itirazen şikayet kavramlarını ayırt etmek

İhale sürecinde başvuru yolları iki temel hatta ilerler: idareye şikayet başvurusu ve ardından (gerekirse) KİK nezdinde itirazen şikayet başvurusu. İlk hat, ihaleyi yapan idarenin kendi işlemini gözden geçirmesine yönelik bir mekanizmadır. İkinci hat ise idarenin kararına karşı, bağımsız bir inceleme otoritesi olan KİK tarafından değerlendirme yapılmasını sağlar.

Kurumsal açıdan bakıldığında, bu iki hat arasında stratejik farklar vardır. İdareye şikayette amaç; çoğu zaman hızlı düzeltici işlem alınması, yanlış yorumlanan bir teknik kriterin açıklığa kavuşması veya teklif değerlendirmesinde yapılan maddi hatanın düzeltilmesidir. İtirazen şikayette ise dosya daha formal bir değerlendirmeye taşınır; bu aşamada delil standardı yükselir ve başvurunun kurgusu daha sistematik olmalıdır.

Yanlış yapılan en yaygın hata, idareye şikayetin “zaten reddedilecek” düşüncesiyle yüzeysel hazırlanmasıdır. Oysa itirazen şikayet dosyasının iskeleti, çoğu durumda idareye şikayet dilekçesinde kurulur. Bu yüzden ilk aşamayı “taslak” değil, nihai argüman setinin başlangıcı gibi tasarlamak verimlidir.

Başvuru yolunu ihale aşamasına göre seçmek

Şikayet konusu, ihalenin hangi aşamasında ortaya çıktıysa, başvurunun kapsamı ve dili ona göre ayarlanmalıdır. Örneğin doküman düzenlemelerine ilişkin bir itiraz, teklif verme öncesi dönemde yoğunlaşırken; değerlendirme dışı bırakılma gibi sorunlar, değerlendirme ve karar bildirimleri sonrasında gündeme gelir. Teknik ekibin, hangi aşamada hangi dokümana dayanacağını bilmesi, argümanların somutlaşmasını sağlar.

Kurumsal rol dağılımını netleştirerek ilerlemek

Şikayet sürecinde hukuk, satınalma/teklif ekibi ve teknik ekip arasında tek bir dosya sahibi belirlemek önemlidir. Teknik ekip, şartname maddelerini ve uyumsuzlukları somut örneklerle ifade eder; teklif ekibi EKAP/iletişim akışını takip eder; hukuk birimi ise hukuki dayanakları ve formatı standardize eder. Bu rol dağılımını önceden yazılı hale getirmek, özellikle yoğun ihalelerde hata payını düşürür.

Süreleri doğru hesaplayarak hak kaybını önlemek

Süre yönetimi, şikayet ve itirazen şikayet süreçlerinin bel kemiğidir. En güçlü teknik argümanlar bile, süresinde yapılmayan başvuruda karşılık bulmaz. Bu nedenle ekiplerin “tebliğ tarihi”, “öğrenme tarihi”, “doküman satın alma tarihi” ve “işlem tarihi” gibi kavramları bir takvim mantığıyla yönetmesi gerekir.

Pratikte sürelerin kaçırılmasının iki nedeni öne çıkar: (1) kurum içi onay süreçlerinin uzaması ve (2) farklı ekiplerin farklı tarihleri “başlangıç” kabul etmesi. Özellikle yazılım şirketlerinde, teklif hazırlığı ve sözleşme incelemesi paralel yürüdüğü için takvim kirliliği oluşabilir. Burada çözüm, tek bir “süre panosu” oluşturmak ve tarihleri kanıtlayan belgeleri aynı yerde toplamak olabilir.

Tebliğ ve öğrenme tarihini delille sabitlemek

Bir kararın ne zaman bildirildiği veya hangi tarihte öğrenildiği, başvurunun süresini doğrudan etkiler. Bu nedenle bildirim ekran görüntüleri, sistem kayıtları, e-posta başlıkları ve EKAP üzerinden alınan çıktılar gibi delillerin korunması gerekir. Ayrıca şirket içinde, bildirimi alan kişinin bu bildirimi ne zaman ilgili birimlere ilettiği de önemlidir; iç yazışmalar bazen “öğrenme tarihini” tartışmalı hale getirebilir.

Kurumsal takvimle süre hesabını otomatikleştirmek

Süre takibini manuel yapmak yerine, basit bir hesaplayıcı mantığıyla hareket etmek verimli olabilir. Aşağıdaki örnek, bir kurum içi araçta kullanılabilecek temel bir yaklaşımı gösterir. Buradaki kod parçası hukuki danışmanlık değildir; amaç, ekiplerin süre mantığını sistemleştirmesine yardımcı olmaktır.

// Basit süre takip örneği (kurum içi kontrol amaçlı)
// input: işlem tarihi (YYYY-MM-DD), süre (gün)
// output: son gün (YYYY-MM-DD)
function addDays(isoDate, days) {
  const d = new Date(isoDate + 'T00:00:00');
  d.setDate(d.getDate() + days);
  const y = d.getFullYear();
  const m = String(d.getMonth() + 1).padStart(2, '0');
  const day = String(d.getDate()).padStart(2, '0');
  return `${y}-${m}-${day}`;
}

const actionDate = '2026-02-13';
const deadline = addDays(actionDate, 10);
console.log({ actionDate, deadline });

Bu tarz bir araç, her ihale için “işlem tarihi + süre” mantığını görünür kılar. Ancak en kritik nokta, hangi olayın “işlem tarihi” kabul edileceğinin ekip içinde net tanımlanmasıdır. Bu tanımı, ihale türü ve olay tipine göre bir şablon halinde oluşturmak pratikte hız kazandırır.

Dilekçeyi delil ve gerekçeyle kurgulamak

Şikayet ve itirazen şikayet başvurularında dilekçe; bir “itiraz metni” değil, bir “kanıt ve gerekçe dosyası”dır. Kurumsal ekipler için en iyi yaklaşım, dilekçeyi bir ürün gereksinim dokümanı gibi düşünmektir: iddia, dayanak, delil, etki ve talep net olmalıdır. Bu yapı, hem idare hem de KİK nezdinde okunabilirliği artırır.

Dilekçe kurgusunda üç parça öne çıkar: (1) olayın kısa özeti, (2) somut aykırılıklar ve (3) talep edilen düzeltme. Somut aykırılıklarda, “şartnameye aykırı” demek yerine, hangi madde ile hangi işlem arasında çelişki olduğu gösterilmelidir. Yazılım ihalelerinde bu çelişki çoğu zaman “teknik şartname yorum hatası”, “benzer iş tanımı”, “kalite belgeleri” veya “puanlama kriterlerinin uygulanması” gibi başlıklarda çıkar.

İddia-dayanak-delil üçlüsünü standardize etmek

Her iddia için aynı şablon kullanılabilir: “İddia: … / Dayanak: … / Delil: … / Etki: … / Talep: …”. Bu, farklı ekiplerin katkısını tek bir iskelette birleştirir. Örneğin teknik ekip “Delil” kısmına test raporu, ekran çıktısı veya şartname maddesi eklerken; hukuk birimi “Dayanak” kısmını mevzuat ve içtihatla güçlendirebilir.

Teknik şartnameyi maddeler halinde haritalamak

Teknik şartname; yazılım ekipleri için bir “kabul kriterleri listesi” gibidir. Bu nedenle şikayet dosyasında, ilgili maddeleri tablo mantığıyla haritalamak güçlü bir yöntemdir. Örneğin “Madde 3.2 – API güvenliği” ile “değerlendirme komisyonu gerekçesi” yan yana konulup çelişki netleştirilebilir. Böylece okuyucu, teknik tartışmaya boğulmadan sorunu görür.

Yukarıdaki yaklaşım, özellikle çok paydaşlı şirketlerde “kimin neyi hazırlayacağı” sorununu azaltır. Ayrıca delillerin tek yerde toplanması, son dakika telaşını düşürür. Burada amaç, dilekçeyi tek seferde kusursuz yazmak değil; her iddiayı doğrulanabilir hale getirerek başvurunun dayanıklılığını artırmaktır.

KİK incelemesine hazırlık yaparak savunmayı güçlendirmek

İtirazen şikayet aşaması, çoğu kurum için “dosya KİK’e gitti, bekleyelim” şeklinde yanlış bir pasifliğe dönüşebilir. Oysa bu aşama, delil setini olgunlaştırmak ve olası ek bilgi taleplerine hazırlıklı olmak için kritik bir fırsattır. KİK incelemesi, başvurunun şekli unsurlarından başlayarak esasa doğru ilerlediği için, format ve bütünlük hataları ciddi risk yaratabilir.

Bu noktada “ön inceleme” mantığını kurum içinde taklit etmek faydalıdır. Dilekçede başvuru ehliyeti, süre, imza/temsil, vekalet, ekler ve talep kısmı kontrol edilmelidir. Ardından teknik ve mali iddialar, birbiriyle çelişmeyen bir hikaye halinde kurgulanmalıdır. Özellikle yazılım hizmetlerinde, “benzer iş”, “personel niteliği”, “iş deneyimi” ve “kalite yönetimi” gibi konular; teknik ve idari boyutu birlikte taşıdığı için dil bütünlüğü ister.

Başvuru dosyasını ön inceleme mantığıyla kontrol etmek

Kurum içi kontrol listesi oluşturmak, tekrar eden hataları azaltır. Bu kontrol listesinde eklerin isimlendirilmesi, sayfa numaraları, atıfların tutarlılığı, her iddia için en az bir delil bulunması gibi maddeler yer alabilir. Tek bir eksik ek bile, güçlü bir iddianın zayıf görünmesine neden olabilir.

Kritik belgeleri versiyonlayarak izlenebilir kılmak

Kurumsal ekipler için versiyonlama alışkanlığı doğal bir avantajdır. Dilekçe ve ekler; Git benzeri bir mantıkla, değişiklik kaydı tutularak yönetilebilir. Böylece “son hali kim güncelledi” sorusu ortadan kalkar ve denetim izi oluşur. Aşağıdaki örnek, ek yönetimi için basit bir dosya manifest yaklaşımını gösterir.

# Ek dosyaları için örnek manifest (kurum içi)
# Amaç: delillerin tekil kimliklerle izlenmesi
EKS/
  EKS-01_teblig_ekran_ciktisi.pdf
  EKS-02_sartname_madde_3_2.pdf
  EKS-03_degerlendirme_gerekcesi.pdf
  EKS-04_teknik_karsilastirma_tablosu.xlsx

# Dilekçede atıf örneği:
# "EKS-02'de yer alan 3.2 maddesi uyarınca ..."

Bu mantık, özellikle birden fazla ihalenin aynı anda yürüdüğü dönemlerde karışıklığı azaltır. Ayrıca KİK sürecinde ek belge ihtiyacı doğduğunda, hangi belgenin nerede olduğunu hızlıca bulmayı sağlar. Böylece ekip, savunmayı güçlendirmeye odaklanır.

Teknik ve ticari riskleri birlikte değerlendirerek karar vermek

Her haklı itirazın takip edilmesi, her zaman en doğru ticari karar olmayabilir. İtiraz sürecinin maliyeti; iş gücü, zaman, fırsat maliyeti ve ilişki yönetimi boyutlarıyla birlikte değerlendirilmelidir. Bu noktada yazılım şirketleri için kritik olan, itirazı “kazanma olasılığı” kadar “kazanıldığında yaratacağı değer” ile birlikte ele almaktır.

Örneğin bir ihalede değerlendirme dışı bırakma hatası, şirketin büyük bir gelir kalemini kaybetmesine yol açacaksa, itirazın daha agresif yönetilmesi anlamlıdır. Ancak daha düşük bütçeli, yüksek belirsizliğe sahip bir işte, itiraz süreci ekip odağını dağıtabilir. Bu nedenle kurum içinde basit bir “risk-değer matrisi” kullanmak faydalıdır.

Risk-değer matrisini basit kurallarla uygulamak

Aşağıdaki maddeler, kurum içi karar toplantılarında hızlı bir çerçeve sunabilir. Buradaki amaç, kararın kişisel kanaatlerle değil, standartlaştırılmış ölçütlerle verilmesidir:

• Olasılık: Delillerin gücü, süre uyumu, iddianın somutluğu
• Değer: Sözleşme bedeli, stratejik müşteri etkisi, referans değeri
• Yük: Dosya hazırlama eforu, ek belge üretimi, iç onay süresi
• Zaman: Proje takvimi, kaynak planı, alternatif iş fırsatları

Bu çerçeve, özellikle karar vericilerin “neden itiraz ediyoruz” sorusuna net yanıt üretir. Ayrıca teknik ekibin yaptığı çalışmanın ticari gerekçeyle örtüşmesini sağlar. En sağlıklı karar, hem teknik doğruluk hem de iş öncelikleri birlikte tartıldığında ortaya çıkar.

Kurumsal süreç ve araçları olgunlaştırarak sürdürülebilir kılmak

Şikayet ve itirazen şikayet yönetimini tek seferlik bir “kriz çözümü” olarak görmek yerine, kurumsal kapasiteye dönüştürmek gerekir. Bunun için süreç; tekrar eden adımlar, şablonlar, kontrol listeleri ve sorumluluklar üzerinden tasarlanmalıdır. Bir yazılım şirketinde süreç olgunluğu, sadece ürün geliştirmede değil, teklif ve uyum yönetiminde de rekabet avantajı yaratır.

En pratik yaklaşım; her ihale için “ihale klasörü” standardı oluşturmak ve bunun içine dokümanlar, yazışmalar, ekran çıktıları, kararlar, süre tablosu ve dilekçe taslaklarını düzenli koymaktır. Böylece yeni bir ihale geldiğinde, ekip sıfırdan öğrenmek yerine mevcut yapıyı kopyalayıp uyarlayabilir. Ayrıca süreç sonunda “ders çıkarımı” toplantısı yaparak, hangi hataların tekrarlandığı tespit edilebilir.

İhale sonrası retrospektif toplantılarını düzenli yapmak

Her itiraz süreci bittikten sonra kısa bir retrospektif yapılması, kurumsal öğrenmeyi hızlandırır. Örneğin “hangi delil geç geldi”, “hangi madde yorumlanamadı”, “hangi ekipte darboğaz oluştu” gibi sorularla süreç iyileştirilebilir. Bu kültür, zamanla daha az hatayla daha hızlı başvuru üretmeyi sağlar.

Şablon ve kontrol listelerini canlı tutarak güncellemek

Mevzuat ve uygulama dinamikleri değişebildiği için şablonlar da canlı tutulmalıdır. Hukuk birimi, güncel yorumları ve karar örneklerini şablonlara entegre edebilir; teknik ekip ise en sık karşılaşılan şartname kalıpları için hazır açıklamalar geliştirebilir. Böylece şirket, her yeni dosyada aynı kaliteyi yakalar.

Sonuç olarak, şikayet ve itirazen şikayet süreçlerini yönetmek; doğru süre hesabı, güçlü delil seti, anlaşılır dilekçe kurgusu ve iyi koordinasyonun birleşimidir. Bu yaklaşım, yalnızca tek bir ihaleyi değil, şirketin kamu pazarındaki uzun vadeli sürdürülebilirliğini destekler. Eğer süreçleri ekip içinde standardize etmek ve pratik örneklerle derinleşmek isterseniz, kamu ihale eğitimi içeriği iyi bir başlangıç sağlayabilir.