KOSGEB yazılım desteği: yatırımı nasıl projelendirirsiniz?

Yazılım yatırımı için destek programlarına başvuran firmaların çoğu, dosyayı projeden sonra hazırlamaya çalışır. Sonuç genelde aynıdır: kapsam çok genel yazılmıştır, teklif tek satırdır, harcama takvimi destek dönemiyle uyuşmaz ve belgeler eksik toplanır.

Bu rehber mevzuat anlatmaz. Destek programlarının kapsamı, oranları ve uygun harcama kalemleri dönemsel değişir; buradaki rakam sayısı sıfırdır ve bilinçlidir. Anlatılan şey, destek başvurusunun bir yazılım projesini nasıl şekillendirdiğidir. Güncel şartlar için kosgeb.gov.tr ve bağlı olduğunuz müdürlük tek doğru kaynaktır.

---

Başvuru projeyi dört yerden değiştirir

Alan	Destek olmadan	Destek dosyasıyla birlikte
Kapsam yazımı	Sözlü mutabakat yeterli olabilir	Somut, sınırı belli, çıktısı tanımlı
Teklif	Toplam bedel yeterli	Kalem kalem ayrıştırılmış
Takvim	Ekibin uygunluğuna göre	Harcama ve dönem kurallarıyla uyumlu
Belge	Fatura ve sözleşme	Teslim, kabul ve ödeme kayıtları düzenli

Bu dört başlık aslında iyi bir yazılım projesinin de gereğidir. Destek başvurusunun faydalı yan etkisi budur: kapsamı yazmaya zorlar.

---

Kapsam: genel başlık yerine somut sistem

Değerlendirmede en zayıf dosyalar, kapsamı “dijital dönüşüm” veya “yazılım altyapısı” gibi genel başlıklarla yazanlardır. Somut kapsam üç şeyi içerir:

1. Hangi süreç. “Üretim iş emri ve duruş takibi”, “satın alma talep ve onay süreci”, “saha bakım kayıtları” gibi sınırı belli bir alan.
2. Kim kullanacak. Rol listesi ve yaklaşık kullanıcı sayısı.
3. Çıktı ne olacak. Hangi ekranlar, hangi raporlar, hangi mevcut programla bağlantı.

Somut kapsamın ikinci faydası yatırımın kendisindedir: dar tanımlı bir sistem daha hızlı devreye girer ve karşılığı daha erken görünür. Kapsamı neyin büyüttüğü kurumsal yazılım maliyet rehberinde ayrıntılı duruyor.

---

Teklif: kalemleri ayrıştırın

Tek satırlık teklif hem değerlendirmeyi zorlaştırır hem de hangi kalemin destek kapsamına girdiğini ayırmayı imkansız kılar. Ayrıştırılmış bir teklifte şu satırlar ayrı görünür:

• Analiz ve kapsam çalışması
• Arayüz tasarımı
• Geliştirme (modül bazında)
• Entegrasyon (hangi sistemle, hangi yönde)
• Veri göçü
• Eğitim ve devreye alma
• Barındırma
• Yıllık bakım (isteğe bağlı)

Son iki satır çoğu programda yatırım kaleminden farklı değerlendirilir; ayrı yazılmaları bu yüzden önemlidir. Bantlarımız ve bu kalemlerin karşılıkları fiyat ve süre sayfasında açık duruyor.

---

Takvim: harcama sırası proje sırasını belirler

Destek programlarında harcamanın ne zaman yapılabileceği kurallara bağlıdır ve bu kurallar proje takvimini doğrudan etkiler. Pratikte üç noktaya dikkat edilir:

• Onay öncesi harcama riski. Onay çıkmadan yapılan harcamanın kapsama girip girmediği programa göre değişir; bu tek soru, projenin başlangıç tarihini belirler.
• Aşama sonlarının belgeye bağlanması. Her aşama sonunda teslim ve kabul kaydı üretilirse, harcama ile çıktı eşleşmesi kendiliğinden kurulur.
• Dönem sonu. Başvuru dönemleri ve değerlendirme takvimi yıl içinde değişir; projeyi dönem sonuna sıkıştırmak, kapsamı daraltmak zorunda bırakır.

---

Belge düzeni: sonradan toplanmaz

Dosyanın en çok eksik çıkan tarafı belgelerdir. Teslim planına baştan yazıldığında sorun kalmaz:

• Sözleşme ve ekindeki kapsam dokümanı
• Ödeme planı ve faturalar
• Aşama teslim ve kabul tutanakları
• Kaynak kod teslim kaydı — bizde kaynak kod müşteriye teslim edildiği için bu kayıt zaten üretilir
• Eğitim katılım kaydı

---

Sık yapılan dört hata

1. Eski rakamlara göre bütçe kurmak. İnternette bulunan oran ve limitler dönemsel değişir; doğrulanmadan kullanılırsa bütçe baştan yanlış kurulur.
2. Kapsamı desteğe göre şişirmek. İhtiyacınız olmayan modülleri “nasılsa destekli” diye eklemek, destek dışı kalan payı da büyütür ve devreye alma süresini uzatır.
3. Tedarikçiyi son anda seçmek. Dosya bir teklife dayanır; teklif hazırlanmadan takvim kurulamaz.
4. Projeyi desteğe bağımlı kurmak. Destek çıkmazsa duran bir proje, iş ihtiyacından değil finansmandan doğmuş demektir.

---

Sınır: destek projeyi belirlememeli

Destek bir finansman aracıdır, bir gerekçe değildir. Doğru sıra şudur: önce hangi sürecin sistemden en çok fayda göreceğine karar verilir, sonra o kapsamın finansmanı planlanır. Tersi yapıldığında ortaya, destek kalemlerine uydurulmuş ama şirketin gerçek darboğazına dokunmayan bir yazılım çıkar.

Bizim tarafımızdaki yaklaşım aşamalıdır: keşif ve prototip ilk iki hafta, ilk canlı modül 2-4 hafta, sonraki modüller kullanım tecrübesine göre. Bu yapı destek dosyasıyla da uyumludur, desteksiz de yürür. ERP özelindeki bütçe kırılımı özel ERP maliyeti yazısında, hazır paketle beş yıllık kıyas TCO hesaplayıcısında.

Güncel oran, limit ve dönem bilgilerini kosgeb.gov.tr üzerinden teyit edin; bu sayfadaki hiçbir ifade resmi şart yerine geçmez.

Kalemleri iki eksende ayırın

Programdan programa değişse de, teklifi hazırlarken kalemleri iki eksende ayırmak işi kolaylaştırır.

Birinci eksen bir defalık yatırım ile süreklilik arz eden gider ayrımıdır: analiz, tasarım, geliştirme, entegrasyon, veri göçü ve eğitim ilk gruba; barındırma, yıllık bakım ve üçüncü servis kullanım bedelleri ikinci gruba girer. Değerlendirme aşamasında hangi satırın hangi grupta olduğu sorulduğunda cevap hazır olur; toplu yazılmış bir teklifte bu ayrım sonradan yapılamaz.

İkinci eksen donanım ile yazılım ayrımıdır. Sunucu, terminal, barkod okuyucu veya tablet gibi kalemler farklı değerlendirilebilir; yazılım teklifiyle aynı satıra yazılmamalıdır.

---

Aşamalı kapsam destek dosyasıyla nasıl uyuşur

Aşamalı yürüyen bir proje dosyaya daha kolay oturur, çünkü her aşamanın kendi çıktısı, kendi tarihi ve kendi kabul kaydı vardır:

1. Keşif ve prototip (ilk 2 hafta). Süreç haritası ve tıklanabilir prototip. Kapsamın gerekçesi bu çıktıdan yazılır.
2. İlk canlı modül (2-4 hafta). En çok sıkıntı veren süreç devreye girer; harcamanın karşılığı somut olarak görünür.
3. Genişleme. Sonraki modüller kullanım tecrübesine göre sıralanır, plana göre değil.

Bu yapı desteğin gecikmesi ya da çıkmaması durumunda da projeyi ayakta tutar: ilk aşama tek başına çalışır durumdadır. Aşamalı kurgunun ikinci faydası belge tarafındadır. Her aşamanın sonunda teslim ve kabul kaydı üretildiği için, dosya istendiğinde geriye dönük belge toplamak gerekmez; harcama ile çıktı eşleşmesi zaten kayıtlıdır. Proje bittikten aylar sonra hatırlanmaya çalışılan teslim tarihleri, dosyanın en sık eksik çıkan kısmıdır.

---

---

İlgili Bütçe Araçları ve Karşılaştırma Rehberleri

• Paket vs Özel 5 Yıllık TCO Hesaplayıcı — Kiralık SaaS lisansı ile özel yazılımın 5 yıllık maliyetini kıyaslayın.
• Yazılım Bütçe ve Süre Tahmincisi — İhtiyacınız olan modülleri seçerek bütçe ve teslim bandınızı görün.
• ERP Fiyat Listesi 2026 Karşılaştırması — Türkiye kurumsal ERP lisans ve bakım bedelleri.
• Özel Yazılım Teknik Şartnamesi (RFP) Rehberi — Bütçe aşımını önleyen şartname hazırlama kılavuzu.

Sıkça sorulan sorular

Bu rehber güncel destek oranlarını ve limitleri veriyor mu?

Hayır, bilinçli olarak vermiyor. Destek programlarının üst limitleri, oranları ve uygun harcama kalemleri dönemsel değişir; internette bulunan eski rakamlara göre bütçe kurmak en sık yapılan hatadır. Güncel şartlar yalnız kosgeb.gov.tr üzerinden ve bağlı olduğunuz müdürlükten doğrulanmalıdır.

Yazılım tedarikçisini destek başvurusundan önce mi seçmek gerekir?

Doğru sıra ikisini birlikte yürütmektir. Başvuru dosyası kapsamı, kalemleri ve takvimi belli bir teklife dayanır; teklif hazırlanırken destek dönemi dikkate alınmazsa harcama takvimi ile proje takvimi uyuşmaz. Bu yüzden kapsam görüşmesinde başvuru planı da konuşulur.

Teklif destek dosyası için nasıl yazılmalı?

Kalemler ayrıştırılmış olmalı: analiz, geliştirme, entegrasyon, veri göçü, eğitim, barındırma ve bakım ayrı satırlarda görünmeli. Tek satırlık 'yazılım geliştirme' ifadesi hem değerlendirmeyi zorlaştırır hem de hangi kalemin destek kapsamına girdiğinin ayrılmasını engeller.

Destek başvurusunda kapsam nasıl tanımlanmalı?

Somut ve ölçülebilir olarak. 'Dijital dönüşüm' gibi genel bir başlık yerine 'üretim iş emri ve duruş takip sistemi' gibi sınırı belli bir kapsam yazılır; çıktısı, kullanacak roller ve devreye alma takvimi tanımlanır. Somut kapsam hem değerlendirme sürecini hem de yatırımın geri dönüşünü kolaylaştırır.

Hangi belgelerin baştan planlanması gerekir?

Teklif ve sözleşme, ödeme planı, teslim ve kabul tutanakları, faturalar ve varsa kaynak kod teslim kaydı. Bu belgeler proje bittikten sonra toplanmaya çalışıldığında eksik çıkar; teslim planına baştan yazılırsa her aşamanın sonunda kendiliğinden oluşur.

Destek alınamazsa proje ne olur?

Projeyi desteğe bağımlı kurmamak gerekir. Sağlıklı yaklaşım, aşamalı bir kapsam kurmak ve ilk aşamayı destekten bağımsız olarak yürütebilecek şekilde planlamaktır; destek gelirse sonraki aşamalar hızlanır, gelmezse proje durmaz. KodDelta'da kapsam zaten aşamalı ilerlediği için bu yapı doğal olarak kurulur.

İlgili rehberler

• Mobil uygulama seçimi: PWA mı, native mi? Kurumsal saha ve maliyet rehberi
• En iyi yazılım şirketleri 2026: Türkiye'deki kurumsal yazılım firmaları sıralaması
• ERP şartnamesi ve ihtiyaç analizi şablonu 2026: Başarısızlığı önleyen 16 maddelik RFP rehberi

Hizmet sayfası: Kurumsal yazılım hizmeti