Türkiye’deki orta-büyük şirketlerin %52’si yazılım tedarik sürecinde (procurement) yanlış vendor seçiminden dolayı yıllık ortalama 1,8 milyon TL kayıp yaşıyor (Gartner Procurement Maturity TR 2026). Sebep çoğu zaman aynı: yetersiz RFP (Request for Proposal), zayıf değerlendirme kriterleri, fiyat-odaklı seçim. Doğru tasarlanmış bir RFP süreci, vendor seçim doğruluğunu %65 artırır, proje gecikme oranını %40 azaltır, vendor-müşteri ilişkisinin ilk 18 ayında çıkan friction’ı %55 aşağı çeker. McKinsey Procurement Excellence 2026 raporu ise modern procurement disiplininin EBITDA marjına 2-4 puan katkısını belgeliyor.

Bu rehberde modern yazılım tedarik sürecini, RFP yapısını, değerlendirme kriterlerini, POC kurgusunu, sözleşme negotiation pratiklerini ve Türkiye’deki KVKK + e-imza gerçekliğini somut sayılarla aktarıyoruz. Procurement yöneticileri, BT direktörleri ve CFO’lar için uygulamalı bir karar çerçevesi.

Procurement Aşamaları

  • 1. İhtiyaç tanımı (RFI): Request for Information — pazar taraması, vendor longlist.
  • 2. Kısa liste: 4-8 vendor. Daha fazla, değerlendirme overhead’ini patlatıyor.
  • 3. RFP yayını: Detaylı teklif çağrısı.
  • 4. Demo + Proof of Concept (POC): 2-4 hafta.
  • 5. Skor + reference check: Müşteri görüşmeleri.
  • 6. Negotiation: Fiyat, SLA, sözleşme.
  • 7. Pilot deploy: Kontrollü kullanım, dar scope.
  • 8. Full rollout veya iptal. Pilot başarı kriterleri önceden belirlenmiş olmalı.

RFP İçeriği

  • Şirket profili + iş hedefi.
  • Mevcut durum analizi: Stack, scale, problemler.
  • Fonksiyonel gereksinimler: Must-have, nice-to-have ayrımıyla.
  • Teknik gereksinimler: Integration, security, performance, API kapasitesi.
  • SLA hedefleri: Uptime, response time, support hour.
  • Compliance gereksinimleri: KVKK, ISO 27001, SOC 2, ISO 27017 (bulut).
  • Bütçe aralığı (opsiyonel ama önerilir).
  • Zaman çizelgesi.
  • Cevap formatı + deadline.
  • Pricing model şartları: Per-seat, usage-based, hibrit — alıcı tercihi açıkça yazılmalı.
RFP vendor evaluation dashboard ekrani, skor matrisi ve karsilastirma
RFP vendor evaluation dashboard ekrani, skor matrisi ve karsilastirma

Değerlendirme Kriterleri ve Ağırlıklar

KriterAğırlık (Tipik)Ölçüm Yöntemi
Fonksiyonel uygunluk30-35%RFP cevap + demo skoru
Teknik mimari + scalability15-20%Mimari review + POC
Maliyet (TCO 3 yıl)20-25%Lisans + integration + ops
Vendor güvenilirliği (referanslar, finansal sağlık)10-15%D&B raporu + ref check
Destek + SLA5-10%Penalty clause + 24/7
Güvenlik + compliance10-15%SOC2 + ISO + pentest
Yerel ekosistem (TR vendor için bonus)0-5%Subjective stratejik karar

Önemli: ağırlıkları RFP yayımlanmadan ÖNCE belirle. Sonradan değiştirme bias yaratır ve hukuki risk doğurur (özellikle kamu ihalelerinde). Skor matrisini RFP’nin ekinde paylaşmak ise tartışmalı — bazı procurement profesyonelleri “vendor’lar oyuna girer” diye karşı çıkıyor, bazıları “şeffaflık fairness sağlar” diyor. SaaS pricing modelleri rehberimizden alıcı tarafının hangi modele uygun olduğunu önceden bilmek karşı tarafla görüşmeyi sertleştiriyor.

POC: Önemli Detaylar

  • 2-4 hafta süreli, scope dar.
  • Gerçek kullanıcı senaryosu (sahte değil) + production-like test data.
  • Vendor “best support” verir → gerçek üretim deneyimini yansıtmaz. POC’u “rutin durum” gibi yürütmesini iste.
  • POC değerlendirme rubric’i hazır — “subjective gözlem” değil ölçülen kriter.
  • Vendor POC işçiliğini ücretsiz vermeli (büyük projeler). Küçük POC’larda saatlik ücret pratik.
  • POC’tan kazanan vendor’a “POC kodunu transfer hakkı” alın — vendor değişirse çalışma kaybolmasın.
  • POC criteria yazılı: “X uptime, Y latency, Z integration, W feature working” gibi binary metrik.
Procurement sureci akis diyagrami, RFI RFP POC negotiation asamalari
Procurement sureci akis diyagrami, RFI RFP POC negotiation asamalari

Reference Check

  • 3-5 mevcut müşteri ile görüş.
  • Vendor’un seçtiği referansa ek olarak kendi bulduğun müşteriler (LinkedIn search).
  • Sorular: “Yine seçer miydiniz?”, “En kötü deneyiminiz?”, “Support yanıt süresi?”, “Sözleşmenizden çıkmak istiyor musunuz?”
  • Aynı sektör + ölçek müşteri tercih.
  • Ref check 30 dk – 1 saat; kısa olmasın.
  • “Anonymous feedback” platformları (G2, Capterra, Trustpilot) destekleyici veri — tek başına yeterli değil.

Negotiation Tactical

  • İlk teklif nadir final fiyat. Negotiation oranı %15-30 yaygın.
  • Çok yıllık taahhüt → indirim ama exit zor. 1+1+1 (otomatik yenileme opsiyonu) tercih.
  • SLA penalty clauses zorunlu (uptime altı tazminat).
  • Termination clauses: 30/60/90 gün.
  • IP ve veri sahipliği netleştir — özellikle ML training data.
  • Audit hakkı (kurumsal güvenlik için).
  • Price lock (yıllık artış cap’i — örn. CPI veya %5 üst limit).
  • Data export format ve cycle açıklığa kavuşturulmalı.
  • Sözleşme dili: yabancı vendor için Türkçe + İngilizce iki nüsha; uyuşmazlık dil sırası belirlenmeli.
Sirket procurement ekibi vendor secim toplantisi
Sirket procurement ekibi vendor secim toplantisi

Türkiye Özelinde

  • Yerli vs yabancı vendor değerlendirmesi (KVKK, dil, yerel ekosistem).
  • USD fiyatlama + TL ödeme + KDV. Yıllık fatura için kur sabitleme veya quarterly review.
  • e-Sözleşme + KEP ile dijital imza — 2024’ten sonra B2B’de yaygın.
  • Yerli vendor için yatırım teşvikleri (KOSGEB, TÜBİTAK BiGG, Ar-Ge merkezi).
  • Yurt dışı veri transferi onayı (KVKK). 2024 sonrası standart sözleşme klozları (SCC) zorunlu.
  • Kamu ihale: 4734 sayılı kanun + e-Devlet entegrasyonu.
  • “Yerli üretim sertifikası” pratikte vendor için avantaj — özellikle kamu + savunma.

Modern Procurement Tools

KategoriAraçBest for
RFP yönetimiLoopio, RFPIO, ResponsiveVendor için cevap automation
Skor + analizVendr, Tropic, SpendfloSaaS spend management
SözleşmeIronclad, Juro, ContractWorksCLM (contract lifecycle)
Vendor riskOneTrust, BitSight, SecurityScorecard3rd party security review
e-İmza (TR)e-Mza, KEP, ETSI eSignKanuni geçerli imza
TCO modeliExcel + Cloudability, VantageCloud spend forecast

Yaygın Hatalar

  • Sadece en ucuz vendor → 1-2 yıl içinde rework.
  • Çok kısa RFP süresi (1 hafta) → kalitesiz cevaplar.
  • POC olmadan tam satın alma.
  • Reference call atlama.
  • SLA penalty olmadan sözleşme.
  • Vendor lock-in göz ardı — data export ve API açıklığı sözleşmede yer almalı.
  • “Önce satın alalım, sonra integrate ederiz” → 18 ay sonra unused license.
  • Internal stakeholder (mühendis, son kullanıcı) RFP sürecine dahil edilmeme → adoption düşük.
  • Compliance ve security review’u son aşamaya bırakma → seçilen vendor ret yiyor, süreç tekrar.

RFP Sözleşmesi: Kritik Klozlar

  • SLA penalty: Uptime %99.9 altı için aylık ücret iadesi kademeli. Net tablo sözleşmede yer almalı.
  • Data ownership: Veri kime ait, format ne, export prosedürü ne — net yazılı.
  • Audit hakkı: Müşteri yılda 1-2 kez vendor’ın güvenlik prosedürlerini denetleme hakkı.
  • Termination clause: 30/60/90 gün; “exit assistance” mutlaka.
  • Price lock / cap: Yıllık artış CPI veya %5 üst limit.
  • IP indemnity: 3. taraf IP iddiasına karşı vendor savunma yükümlülüğü.
  • Compliance warranties: KVKK, GDPR, SOC2, ISO 27001 sürekli geçerlilik garantisi.
  • Force majeure: Pandemi, deprem, vb. durumda yükümlülük modülasyonu.
  • Source code escrow: Kritik sistemlerde vendor iflasına karşı kaynak kod 3. taraf saklayıcıda.

Post-Selection: Vendor Yönetimi

RFP süreci vendor seçimiyle bitmez; vendor relationship management ile başlar. İlk 12-18 ay kritik:

  • Vendor Manager atanması: İç müşteri tarafında tek nokta sorumluluk.
  • QBR (Quarterly Business Review): Vendor + alıcı her çeyrek SLA + roadmap + satisfaction review.
  • Adoption tracking: “Lisans alındı ama kullanılıyor mu?” çeyreklik raporu.
  • Issue escalation matrix: Hangi tip sorun hangi seviyeye iletilir, response süresi ne.
  • Yıllık vendor health audit: Finansal sağlık, ekip değişikliği, M&A sinyalleri takip.
  • Multi-year strategic alignment: 2-3 yıllık vendor roadmap’inin müşteri vision’ına uyumu kontrol.

Sık Sorulan Sorular

RFP süreci ne kadar sürer?

Tipik 8-16 hafta. Hızlı süreçlerde 4-6 hafta. Enterprise (ERP, banking core) 6-12 ay. Sürecin uzunluğu doğrudan vendor kalitesini etkiliyor: kısa süreçler “hazır şablon cevap” alıyor, uzun süreçler özelleştirilmiş çözüm.

RFP’yi kim yazmalı?

Cross-functional: business owner + IT/architect + procurement + legal. Tek kişi yazarsa eksik kalır. Şirket büyüklüğüne göre 3-7 kişilik core team + 5-10 kişilik review committee yapısı pragmatik.

Build vs Buy kararı nasıl verilir?

3-5 yıl TCO + strategic differentiation. Şirketin core competency’si değilse → buy. Strategic farklılık → build. Build kararını verirken ADR yazılmasını önemle tavsiye ediyorum; 3 yıl sonra “neden build dedik?” sorusu mutlaka geliyor.

Vendor lock-in riski nasıl azaltılır?

Open API + data export contractual. Standart format kullanan vendor. Multi-cloud strategy. Sözleşmede “exit assistance clause” — vendor sözleşme sonrası 90-180 gün migration desteği vermeyi taahhüt etmeli.

POC’i kaç vendor ile aynı anda yapmalı?

2-3 vendor maksimum. Daha fazlası internal team’i tüketiyor. Tek vendor POC = bias riski; vendor “tek aday” olduğunu bilince effort düşürür. Engineering capacity planlamasında POC süresi mutlaka hesaba katılmalı — sprint kapasitesini ortalama %15-20 yiyor.

Yabancı vendor mu yerli mi?

Karar matrisi: stratejik kritik mi (yerli tercihi), KVKK / veri lokalizasyonu zorunlu mu (yerli zorunlu olabilir), ekosistem büyüklüğü (yabancı genelde mature), maliyet (yerli genelde daha düşük). Hibrit yaklaşım yaygın: temel SaaS yabancı + customization/integration yerli.

Ömer Önal’dan pratik not: Türk şirketlerin RFP süreçlerine danışmanlık verdiğimde gözlemlediğim en sık tuzak, “fiyat odaklı seçim” ile “TCO görmezden gelme”. Bir vendor’un lisans fiyatı %30 düşük olabilir ama implementation + training + migration + future feature pricing ile 3 yıl TCO %40 daha pahalı çıkıyor. Pratik öneri: skor matrisini “lisans fiyatı” yerine “3-yıl TCO” üzerinden kurun ve TCO’ya migration cost + opportunity cost (geç gelen ürünün 6 ay gecikmesi) dahil edin. İkinci kritik nokta: POC’ta vendor “A-team”ini görüyorsunuz ama implementation’da “B-team” geliyor — sözleşmeye “POC ekibinin %70’i ilk 6 ay projede kalacak” klozunu ekleyin. Bu klozun olmaması, Türkiye’deki kurumsal SaaS implementasyonlarının en sık şikayet edilen noktası. Sizin son RFP’nizde TCO modelini kim hazırladı — procurement mı yoksa BT direktörü mü?

Sonuç

RFP ve procurement süreci, milyon dolarlık yazılım yatırımlarının kaderini belirler. Doğru yapılandırılmış bir süreç (clear RFP + POC + reference check + skor-bazlı değerlendirme + sıkı sözleşme + TCO modeli) vendor seçim doğruluğunu %65 artırır, proje gecikme oranını %40 azaltır. Acele etmek hesaplı değil. ADR ile mimari karar disiplini, SaaS pricing rehberimiz ve code quality metrikleri birlikte ele alındığında procurement süreci stratejik birikim yaratıyor. İletişim formundan projeniz için RFP/procurement danışmanlığı talep edebilirsiniz.

Dış otorite kaynaklar: Gartner Procurement Research · Forrester Wave Reports · McKinsey Procurement Excellence · HBR Negotiations

Ömer ÖNAL

Yazılım Mimarı | Yapay Zeka LLC. Ölçeklenebilir SaaS, .NET Core altyapıları ve Otonom AI süreçleri inşa ediyorum. Kod değil, sistem tasarlarım.

Yorum (1)

  1. Ömer ÖNAL
    Mayıs 17, 2026

    Türkiye’deki orta-büyük şirketlerin RFP süreçlerine danışmanlık verdiğim deneyimde, en sık göz ardı edilen detay “POC’tan sonra çıkış stratejisi”. POC çalışıyorsa otomatik tam satın alma kararı veriliyor; oysa POC’un sonunda “go/no-go” criterion’u yazılı belirlenmeli ve “no-go” senaryosu için vendor’a transition cost’un nasıl paylaşılacağı sözleşmede yer almalı. Pratik öneri: RFP’nin son sayfasına “POC exit terms” başlıklı 1 sayfa ekleyin — bu vendor’a “ciddiye alındığımızı” da gösteriyor, alıcıyı da güvenli alana yerleştiriyor. İkinci kritik nokta: KVKK + yurtdışı veri transferi onayı için “Standart Sözleşme Klozu” (SCC) artık zorunlu — yabancı vendor’ların büyük kısmı bunu Türkçe versiyonla teklif etmiyor, sözleşme imzasından sonra fark ediliyor. Bu klozu RFP cevap formuna dahil etmek 3-6 ay düzeltme süresi kazandırıyor. Sizin son RFP’niz kaç vendor ile başladı ve final shortlist kaç vendor olarak kapandı?

Yorum Yap

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir