Sonucu değil çözümü tarif etmek
'Şu ekranda şu buton olsun' diye yazmak yerine 'şu iş hangi sonuca ulaşmalı' diye yazın. İhtiyacı sonuç odaklı tanımlamak, tedarikçinin daha iyi ve daha ucuz bir yol önermesine alan açar.
Rehber: Tedarik ve Satın Alma
Yazılım şartnamesi (RFP) nasıl hazırlanır? Örnek şablonla adım adım
İyi bir yazılım şartnamesi, teklif sürecinin kaderini baştan belirler. Bu rehber; bilgi işlem yöneticileri (CIO), satın alma ve karar verici patronlar için sağlam bir teklif şartnamesinde (RFP) olması gereken başlıkları, en sık yapılan hataları ve indirilebilir bir örnek şablonu pratik bir dille topluyor. Amaç satış değil; doğru teklifi, doğru fiyatla, kıyaslanabilir biçimde almanıza yardımcı olmak.
10Şartnamede olması gereken ana başlık
40-60%Lisans dışı kalemlerin (kurulum, göç, eğitim, bakım) toplam yatırımdaki tipik payı (piyasa tahmini, değişir)
1 sayfaFiyat formatı tablosuyla kıyaslanabilir teklif
Neden önemli
Şartname neden teklif sürecinin en kritik belgesidir?
Şartname, ihtiyacınızı tedarikçinin diline çeviren tek belgedir. Ne kadar net olursa, gelen teklifler o kadar karşılaştırılabilir olur.
Yazılım teklif şartnamesi (yaygın adıyla RFP, Request for Proposal), bir işin kapsamını, beklentilerini ve değerlendirme ölçütlerini tedarikçilere aynı dilde anlatan belgedir. Şartname olmadan alınan teklifler birbirinden farklı varsayımlarla hazırlanır: biri eğitimi dahil eder, diğeri etmez; biri veri göçünü kapsar, diğeri ek kalem olarak sonradan faturalar. Sonuçta elinizde elma ile armutu kıyaslayan bir tablo kalır.
Net bir şartname üç şeyi aynı anda yapar. Birincisi, talebinizi disipline eder; kendi ihtiyacınızı yazarken eksik düşündüğünüz noktaları görürsünüz. İkincisi, tedarikçileri aynı kapsam üzerinden teklif vermeye zorlar, böylece fiyatlar gerçekten kıyaslanabilir hale gelir. Üçüncüsü, sözleşme aşamasında ve proje sırasında çıkacak 'bu kapsamda yoktu' tartışmalarının önünü baştan keser.
Şunu da dürüstçe söylemek gerekir: aşırı katı, her ekranı pikseli pikseline tarif eden bir şartname de işi zorlaştırır. Çok detaylı bir doküman, tedarikçinin daha iyi bir çözüm önermesini engelleyebilir ve fiyatı şişirir. Doğru denge; 'ne istediğinizi' net, 'nasıl yapılacağını' ise tedarikçinin uzmanlığına alan bırakacak şekilde yazmaktır. Bu rehberin amacı bu dengeyi kurmanıza yardımcı olmaktır.
İçindekiler
Sağlam bir şartnamede olması gereken başlıklar
Aşağıdaki on başlık, hem hazır paket hem de özel yazılım tekliflerini aynı çerçevede toplamanızı sağlar. Her birini kendi projenize göre kısaltıp uzatabilirsiniz.
- Kapsam ve amaç: Projenin hangi sorunu çözeceği, mevcut durum, başarı kriterleri ve kapsam dışı bırakılan konular. 'Neyi yapmayacağız' cümlesi en az 'neyi yapacağız' kadar değerlidir.
- Modül ve özellik listesi: İhtiyaç duyulan fonksiyonlar; her biri için 'zorunlu' / 'tercih edilen' / 'opsiyonel' ayrımı. Bu ayrım, tedarikçinin fiyat ve takvimini sağlıklı kurmasını sağlar.
- Entegrasyon gereksinimleri: Bağlanması gereken sistemler (muhasebe/ERP, e-fatura, CRM, üretim, e-ticaret, banka, kargo). Hangi yönde veri akacağı ve API/dosya/çift yönlü senkron beklentisi.
- Teknoloji ve mimari beklentileri: Bulut mu, şirket içi (on-premise) sunucu mu; web/mobil ihtiyacı; tarayıcı ve cihaz desteği; kimlik doğrulama, yetkilendirme ve KVKK/veri güvenliği gereklilikleri.
- Veri göçü: Mevcut verinin nerede durduğu (Excel, eski yazılım, veritabanı), hacmi, temizlik ihtiyacı ve göçün kimin sorumluluğunda olduğu. Bu kalem çoğu projede sürpriz maliyetin kaynağıdır.
- Eğitim ve devreye alma: Kaç kullanıcıya, hangi rollerde, yerinde mi uzaktan mı eğitim verileceği; kullanıcı kılavuzu, test ve canlıya geçiş (go-live) planı.
- Bakım, destek ve SLA: Garanti süresi, destek kanalları ve çalışma saatleri, müdahale/çözüm süreleri (örn. kritik arıza için yanıt süresi), güncellemelerin kapsamı ve yıllık bakım bedelinin nasıl hesaplandığı.
- Referanslar ve ekip: Tedarikçinin benzer sektör/ölçek referansları, projede çalışacak ekibin rolleri ve deneyimi, alt yüklenici kullanılıp kullanılmayacağı.
- Fiyat formatı: Tek kalem değil; kurulum/geliştirme, lisans, veri göçü, entegrasyon, eğitim, yıllık bakım gibi kalemlerin ayrı ayrı yazılacağı standart bir tablo. Bu format tekliflerin kıyaslanmasını mümkün kılar.
- Zaman planı ve teslim koşulları: Beklenen başlangıç, ara teslimler (milestone), kabul (UAT) kriterleri, ödeme planının teslimlere bağlanması ve gecikme durumunda yaklaşım.
Tuzaklar
Şartname hazırlarken sık yapılan hatalar
Bu hataların çoğu, teklif geldikten sonra değil proje ortasında pahalıya patlar. Şartnameyi yollamadan önce bu listeyi bir kez daha okuyun.
Entegrasyonları geçiştirmek
'Mevcut sistemlerle entegre olacaktır' cümlesi tek başına hiçbir şey ifade etmez. Hangi sistem, hangi yönde, hangi veri, hangi sıklıkta? Belirsiz entegrasyon maddesi, tekliflerdeki en büyük fiyat sapmasının kaynağıdır.
Veri göçünü unutmak
Eski veriyi taşımak çoğu zaman ayrı bir projedir. Hacmi, kalitesi ve temizlik ihtiyacı yazılmazsa tedarikçiler ya boşa düşük ya da temkinli yüksek fiyat verir. Her ikisi de sizi yanıltır.
Bakım ve SLA'yı boş bırakmak
Canlıya geçiş projenin sonu değil başıdır. Garanti süresi, destek saatleri ve müdahale süreleri yazılmazsa, ilk arızada beklentiyle teklif çakışır. SLA'yı baştan netleştirmek en ucuz sigortadır.
Fiyatı tek kalem istemek
Toplam bir rakam istemek kıyaslamayı imkânsız kılar. Kurulum, lisans, göç, eğitim, bakım kalemlerini ayrı isteyin. Bir teklifin ucuz görünmesi, çoğu zaman bakım veya göç kaleminin gizlenmesinden kaynaklanır.
Tek doğru cevap dayatmak
Belirli bir markayı, teknolojiyi veya mimariyi şart koşmak rekabeti kapatır ve sizi tek tedarikçiye mahkûm eder. Zorunlu olmadıkça sonucu tarif edin, teknolojiyi tedarikçinin gerekçesiyle önermesine izin verin.
Lead magnet
İndirilebilir örnek şartname şablonu
Yukarıdaki on başlığı boş doldurulabilir bir iskelet haline getirdik. Kendi projenize göre uyarlayıp doğrudan tedarikçilere gönderebilirsiniz.
Hazırladığımız örnek şablon, on ana başlığın her birini açıklamalı boşluklarla içerir: kapsam ve amaç, modül/özellik listesi (zorunlu-tercih-opsiyonel kolonlu), entegrasyon matrisi, teknoloji ve güvenlik beklentileri, veri göçü, eğitim ve devreye alma, bakım/destek/SLA, referans ve ekip, standart fiyat tablosu ve zaman planı. Her bölümün başında 'bu bölümde ne yazmalısınız' notu bulunur.
Şablonu /sablonlar/yazilim-sartnamesi-sablonu.md adresinden indirebilirsiniz. Düz metin (Markdown) formatında olduğu için kurum içi her editörde açılır, kolayca kopyalanır ve kurum şablonunuza dönüştürülür. İçinde gerçek müşteri adı, uydurma metrik veya sektöre özel hazır cevap yoktur; bilinçli olarak nötr ve doldurulabilir bırakılmıştır.
Şablonu kullanırken pratik bir öneri: önce 'zorunlu' özellikleri sınırlı tutun. Her isteğinizi zorunlu yaparsanız fiyat ve takvim şişer. Gerçekten olmazsa olmazları zorunlu, geri kalanı tercih edilen veya opsiyonel olarak işaretleyin; tedarikçilerin kıyaslanabilir ve gerçekçi teklif vermesini bu ayrım sağlar.
Pan'ın yaklaşımı
Pan teklifinizde şartnamenizin neyi karşılar?
Bir şartname size geldiğinde onu nasıl okuduğumuzu ve teklifimizde her başlığa nasıl yanıt verdiğimizi açıkça paylaşıyoruz. Tarafsızlık adına önce şunu söyleyelim: kapsamınız standart ve oturmuşsa hazır paket bir ürün çoğu zaman daha hızlı ve uygun maliyetlidir; süreçleriniz kendine özgüyse ve mevcut paketlere sığmıyorsa özel yazılım daha doğru olur. Pan, bu kararı sizinle birlikte verir, sonra köprüyü kurar.
- Kapsam okuması: Şartnamenizdeki her başlığa tek tek, aynı sırayla yanıt veririz. 'Anlaşıldı / kısmen / kapsam dışı' biçiminde açık işaretleriz; muğlak madde bırakmayız.
- Standart fiyat tablosu: Kurulum/geliştirme, lisans, veri göçü, entegrasyon, eğitim ve yıllık bakımı ayrı kalemler halinde sunarız; rakipler arasında kıyaslama yapabilmeniz için sizin fiyat formatınıza uyarız.
- Entegrasyon netliği: Hangi sisteme, hangi yönde, hangi yöntemle (API/dosya/çift yönlü) bağlanacağımızı ve kimin neyi sağlayacağını teklifte yazılı hale getiririz.
- Veri göçü planı: Verinizin kaynağını ve hacmini birlikte tespit eder, temizlik ve doğrulama adımlarını ayrı bir iş kalemi olarak şeffafça gösteririz.
- Bakım ve SLA taahhüdü: Garanti süresi, destek kanalları ve müdahale sürelerini yazılı taahhüde dönüştürürüz; 'sonra konuşuruz' demeyiz.
- Gerçekçi takvim: Ara teslimler (milestone) ve kabul (UAT) kriterlerini ödeme planına bağlarız; takvimi olduğundan kısa göstermeyiz.
- Karar danışmanlığı: Şartnameniz aslında hazır bir paketle çözülebiliyorsa bunu dürüstçe söyleriz; özel geliştirme gerçekten gerekliyse gerekçesiyle anlatırız.
Sıkça sorulan sorular
Merak edilenler
Şartname olmadan teklif alınır mı?
Alınır, ancak gelen teklifler büyük olasılıkla karşılaştırılamaz olur. Şartname olmadan her tedarikçi kendi varsayımıyla teklif verir: biri eğitimi ve veri göçünü dahil eder, diğeri etmez. Sonuçta en ucuz görünen teklif, gizli kalemler yüzünden en pahalısı çıkabilir. Çok küçük ve net işlerde kısa bir gereksinim listesi yeterli olabilir; ama birden fazla tedarikçiyi kıyaslayacaksanız, en azından kapsam, entegrasyon, veri göçü ve fiyat formatı başlıklarını yazılı hale getirmenizi öneririz.
Şartname ne kadar detaylı olmalı?
Ne istediğinizi netleştirecek kadar detaylı, ama tedarikçinin daha iyi çözüm önermesini engellemeyecek kadar esnek. İyi pratik; sonucu (hangi iş hangi çıktıya ulaşmalı) net tarif etmek, çözümün teknik detayını (hangi mimari, hangi teknoloji) tedarikçinin gerekçesiyle önermesine bırakmaktır. Her ekranı pikseli pikseline tarif eden şartnameler rekabeti ve yaratıcılığı kapatır, fiyatı yükseltir. Özellik listesini zorunlu / tercih edilen / opsiyonel diye ayırmak, doğru detay seviyesini bulmanın en kolay yoludur.
Küçük firma da şartname yapmalı mı?
Evet, ama orantılı ölçekte. Küçük bir firmanın şartnamesi onlarca sayfa olmak zorunda değil; iki üç sayfalık net bir belge çoğu zaman yeterlidir. Önemli olan başlıkların doğru olması: ne istediğiniz (kapsam), nelere bağlanacağı (entegrasyon), mevcut verinin durumu (göç), eğitim ve bakım beklentisi, ve kalem kalem fiyat formatı. Bu beş başlık bile, küçük bir işletmenin sonradan 'bu dahil değil miydi?' sürprizleriyle karşılaşmasını büyük ölçüde önler.
RFP, RFI ve RFQ arasındaki fark nedir?
Üçü tedarik sürecinin farklı aşamalarıdır. RFI (Request for Information) bilgi toplama amaçlıdır; pazarı ve tedarikçileri tanımak için kullanılır. RFP (Request for Proposal), bu rehberin konusu olan teklif şartnamesidir; tedarikçilerden ihtiyacınıza çözüm önermelerini ve fiyatlandırmalarını istersiniz. RFQ (Request for Quotation) ise kapsam tamamen netken sadece fiyat teklifi istemektir. Yazılım projelerinde genellikle RFP en doğru araçtır, çünkü çözüm yaklaşımı da fiyat kadar önemlidir.
Şartnameye fiyatı tek kalem mi, kalem kalem mi istemeliyim?
Kalem kalem isteyin. Tek bir toplam rakam, teklifleri kıyaslamayı neredeyse imkânsız hale getirir. Kurulum/geliştirme, lisans, veri göçü, entegrasyon, eğitim ve yıllık bakımı ayrı satırlar halinde istemek; hem gizli kalemleri ortaya çıkarır hem de hangi teklifin nerede pahalı olduğunu görmenizi sağlar. Piyasada lisans dışı kalemlerin (kurulum, göç, eğitim, bakım) toplam yatırımın önemli bir bölümüne ulaşabildiği bilinir; bu yüzden bu kalemleri ayrı görmek bütçe planınız için kritiktir.
Şartnamede belirli bir teknoloji veya marka şart koşmalı mıyım?
Zorunlu bir gerekçeniz yoksa hayır. Belirli bir veritabanı, programlama dili veya marka şart koşmak rekabeti daraltır ve sizi tek tedarikçiye bağımlı hale getirebilir. Mevcut sistemlerinizle uyum, kurum içi ekibinizin yetkinliği veya yasal bir zorunluluk gibi somut sebepler varsa elbette belirtin; aksi halde sonucu tarif edip teknoloji seçimini, gerekçesiyle birlikte, tedarikçinin önermesine bırakmak genellikle daha sağlıklı ve daha rekabetçi teklifler getirir.
Birlikte başlayalım
Şartnamenizi birlikte gözden geçirelim
Hazırladığınız şartnameyi bize iletin; her başlığa açık yanıt verdiğimiz, kalem kalem fiyatlı bir teklif sunalım. Henüz şartnameniz yoksa, örnek şablondan başlayıp ihtiyacınızı birlikte netleştirelim. Satış baskısı değil, doğru kararı vermenize yardımcı olacak bir görüşme.
İlgili sayfalar