Proje Yönetimi · İhale & Şartname Rehberi
Özel yazılım teknik şartnamesi nasıl hazırlanır? 2026 RFP Şablonu ve Örneği
Muğlak maddeler, ucu açık bütçeler ve teslim edilmeyen projeler. Genel Müdürler, CFO'lar ve BT yöneticileri için riskleri sıfırlayan kurumsal yazılım şartnamesi kılavuzu ve kopyalanabilir şablon.
Özel yazılım ve ERP teknik şartnamesi (RFP), bir projenin bütçe aşımını ve başarısızlığını önleyen en temel yasal ve teknik belgedir. Başarılı bir yazılım şartnamesi 6 temel omurga üzerine kurulmalıdır: 1. Ölçülebilir İş Hedefleri (örn. 'Hızlı olmalı' yerine 'Liste ekranları 1.5 saniye altında açılmalı'), 2. Kesin Kapsam ve Kapsam Dışı Sınırlar (yapılacaklar kadar yapılmayacakların açıkça listelenmesi), 3. Senaryo Bazlı Fonksiyonel Gereksinimler ('Stok modülü' yerine 'Depocu ürün okuttuğunda otomatik irsaliye oluşur' gibi kullanıcı hikâyeleri), 4. Kaynak Kod Devri ve Telif Hakları (tüm kaynak kodların, veri tabanı şemalarının ve dokümantasyonun müşteriye teslimi; ajansa kilitlenmeme), 5. Sabit Fiyat ve Kilometre Taşı (Milestone) Ödeme Takvimi (çalışan ekran teslim alınmadan sonraki ödemenin yapılmaması), 6. SLA ve Bakım Koşulları (kritik hatalara en geç 2–4 saatte müdahale garantisi). KodDelta, şartnamesi hazır olan projelere 24 saat içinde mimar incelenmiş net kapsam ve sabit fiyat teklifi sunar.
Türkiye'de özel yazılım ve dijitalleşme projelerinin önemli bir kısmı teknik yetersizlikten değil, kötü yazılmış veya hiç yazılmamış şartnameler yüzünden mahkemelik olur veya rafa kalkar. Şirket sahibi "Bize bir üretim takip programı lazım" der; yazılımcı "Yaparız" der. 6 ay sonra yazılımcının teslim ettiği ekran ile fabrika müdürünün hayal ettiği süreç birbiriyle uyuşmaz. Yazılımcı "Siz bunu istememiştiniz, ek ücret ödemelisiniz" der; şirket ise parasını kaptırdığını düşünür. Bu krizin tek panzehiri, ihaleye veya teklif toplamaya çıkmadan önce hazırlanan net bir Teknik Şartname (RFP - Request for Proposal) dokümanıdır.
Şartname yazarken yapılan 4 ölümcül hata
- "Kullanıcı Dostu ve Hızlı Olacak" Tuzağı: Hız ve kullanıcı dostu olmak göreceli kavramlardır. Bir sayfanın 4 saniyede açılması yazılımcıya göre normal, sahadaki plasiyere göre felakettir. Bunun yerine şartnameye: "Masaüstü ve mobilde liste sayfaları 4G bağlantıda en geç 1.5 saniyede render edilmeli, Core Web Vitals LCP skoru 2.5 saniyenin altında olmalıdır" yazılmalıdır.
- Kapsam Dışı (Out of Scope) Maddesi Yazmamak: Nelerin yapılacağı kadar nelerin yapılmayacağı da yazılmalıdır. Örneğin: "Bu fazda mobil native uygulama geliştirilmeyecek, sistem mobil uyumlu PWA (web) olarak teslim edilecektir" veya "e-İrsaliye entegrasyonu bu faza dahil değildir" gibi net sınırlar çizilmezse proje asla bitmez.
- Kaynak Kod Mülkiyetini Şarta Bağlamamak: Birçok yazılım evi sistemi kendi lisanslı sunucusunda barındırır ve kodları teslim etmez. Şirket ayrılmak istediğinde tüm kurumsal hafıza ve yatırım çöpe gider.
- Peşin veya Takvime Göre Ödeme Yapmak: "Her ayın 1'inde ödeme yapılır" maddesi yanlıştır. Ödemeler takvime göre değil, çalışan ekranın kabul tutanağına göre bağlanmalıdır.
Kurumsal Yazılım ve ERP Teknik Şartname Şablonu (RFP)
Aşağıdaki 10 maddelik şablonu kendi şirketinizin süreçlerine göre kopyalayıp düzenleyerek teklif toplayabilirsiniz:
İşletmemizin [Sektör / Faaliyet] alanındaki [Örn. Üretim / Sevkiyat / Teklif] süreçlerinin dijitalleştirilmesi ve mevcut [ERP / Muhasebe] sistemiyle entegre çalıştırılması hedeflenmektedir.
2. MEVCUT DURUM VE KULLANILAN SİSTEMLER:
Halihazırda veriler [Örn. Logo Tiger / Excel / WhatsApp] üzerinde tutulmaktadır. Sistemde ortalama [X] kullanıcı işlem yapacaktır.
3. KAPSAM VE MODÜLLER:
- Modül 1: [Örn. Barkodlu Paketleme ve Çift Doğrulama]
- Modül 2: [Örn. Dinamik Cari Risk Limiti ve B2B Sipariş Ekranı]
- Modül 3: [Örn. Canlı Üretim ve Duruş Takip Panosu]
4. KAPSAM DIŞI ALANLAR (OUT OF SCOPE):
İlk fazda [Örn. İK bordrolama ve e-Fatura kesme] süreçleri bu projenin dışındadır.
5. FONKSİYONEL İŞ SENARYOLARI (USER STORIES):
- [Rol]: [İşlemi yapar] -> Sistem [Otomatik sonucu üretir ve kaydeder].
6. ENTEGRASYON VE VERİ GÖÇÜ GEREKSİNİMLERİ:
Mevcut ERP'den son 1 yıllık [Cari, Stok, Fiyat] verileri temizlenerek taşınacaktır. Sistem çift yönlü REST API üzerinden haberleşecektir.
7. KAYNAK KOD VE FİKRİ MÜLKİYET HAKLARI:
Yazılan tüm kaynak kodlar, veri tabanı şeması ve belgeler eksiksiz olarak işverene devredilecektir. İşverenin sistemi bağımsız sunucularda barındırma hakkı saklıdır.
8. KABUL KRİTERLERİ VE TEST PROSEDÜRÜ:
Her faz tesliminde [5 iş günü] test süresi uygulanacak; kritik seviyedeki hatalar giderilmeden ilgili fazın kabul tutanağı imzalanmayacaktır.
9. ÖDEME VE KİLOMETRE TAŞI PLANI:
- %20 Proje Başlangıcı & Mimari Tasarım
- %30 Çekirdek Modüller Test Teslimi
- %30 Entegrasyon ve Kullanıcı Kabul Testi
- %20 Canlıya Geçiş ve Nihai Kabul Tutanağı
10. SLA VE TEKNİK DESTEK ŞARTLARI:
Canlıya geçişten sonraki ilk [60 gün] garanti kapsamında ücretsiz destek verilecek; kritik duruş arızalarına en geç [2 saat] içinde müdahale edilecektir.
KodDelta Şartnameli Projelerde Nasıl Çalışır?
KodDelta olarak muğlak işleri sevmeyiz. Müşterimizin hazırladığı şartnameyi ilk görüşmede yazılım mimarımızla satır satır inceleriz. Geliştirilemeyecek veya sahada işlemeyecek maddeleri açıkça söyler, alternatif yalın çözümü öneririz. Projeyi sabit fiyat ve kesin teslim taahhüdüyle sözleşmeye bağlarız.
Sık Sorulan Sorular
Özel yazılım teknik şartnamesi (RFP) neden gereklidir?
Teknik şartname, işverenin ne istediği ile yazılım geliştiricinin ne anladığı arasındaki farkı sıfırlayan belgedir. Şartnamesi olmayan yazılım projelerinin %70'i bütçe aşımı, süre uzaması veya işverenin istediği sonuçları alamaması nedeniyle başarısızlıkla sonuçlanır.
Şartnamede kaynak kod devri maddesi nasıl yazılmalıdır?
Şartnamede "Proje kapsamında yazılan tüm kaynak kodlar, veri tabanı mimarisi, kurulum betikleri ve API dokümantasyonu, mülkiyeti ve fikri haklarıyla birlikte eksiksiz olarak işverene teslim edilecektir. Yazılım hiçbir üçüncü parti geliştiriciye bağımlı olmadan bağımsız sunucularda derlenebilir ve çalıştırılabilir olacaktır" maddesi açıkça yer almalıdır.
Ödeme takvimi şartnamede nasıl kurgulanmalıdır?
Tüm bütçeyi peşin ödemek veya sadece proje bitiminde ödemek yerine, somut kilometre taşlarına (milestone) bağlı aşamalı ödeme modeli benimsenmelidir. Örneğin: %20 Proje Başlangıcı ve Mimari Tasarım Onayı, %30 Çekirdek Modül Kabul Testi, %30 ERP ve Canlı Entegrasyon Kabulü, %20 Canlıya Geçiş ve 30 Günlük Sorunsuz Çalışma Kabul Tutanağı.
Fonksiyonel gereksinimler nasıl tanımlanmalıdır?
"Stok modülü olmalı" gibi soyut maddeler yerine "Kullanıcı Hikâyeleri" (User Story) yazılmalıdır. Örneğin: "Depo sorumlusu, gelen irsaliyedeki barkodları el terminaliyle okuttuğunda sistem irsaliye tutarı ve kalemlerini ERP'ye otomatik aktarır; eksik/hasarlı kalem varsa satın alma sorumlusuna anlık SMS/e-posta uyarısı düşer."
KodDelta hazır teknik şartnamelere nasıl teklif verir?
Hazırladığınız teknik şartnameyi bize ilettiğinizde, yazılım mimarımız dokümanı inceler; varsa belirsiz noktaları netleştirir ve 24 saat içerisinde net teslim takvimi, kesin kapsam sınırları ve sabit proje bedeli içeren bağlayıcı teklifimizi iletir.
Şartnameniz hazır mı? 24 saatte net teklif alın
Hazırladığınız şartnameyi veya ihtiyaç listenizi bize iletin. Yazılım mimarımız kapsamı analiz edip 24 saat içinde sabit bütçe ve takvim teklifini sunsun.