Yazılım Tedarikçisi RFP Kontrol Listesi (B2B)

Bir yazılım RFP'i, hiçbir tedarikçi yanıt vermeden önce sorunu, işlevsel ve işlevsel olmayan gereksinimleri, güvenlik ve veri ihtiyaçlarını, ticari koşulları ve puanlama yöntemini tanımlamalıdır. Ağırlıklı kriterleri puanlayın; sonrasında tartışmayın, vaka anlatımlarına inanmak yerine referansları arayın ve bütçe bağlayan herhangi bir şeyi imzalamadan önce kısa ve ücretli bir pilot yapın.

Bir yazılım RFP'i ne içermeli?

Belge cevapları karşılaştırılabilir kılmak için vardır. Bir tedarikçi yalnızca yazana yanıt verebilir; bir vizyonu tarif edip fiyat isteyen bir RFP, hepsi mükemmel görünen ama hiçbirinin diğerleriyle değerlendirilemeyeceği teklifleri davet eder. İşlevsel içerik, kısıtlar ve puanlama kuralı ilk yanıt gelmeden sabitlenmelidir; aksi hâlde değerlendirme, kriterler üzerine bir pazarlığa dönüşür. Şimdiye kadar yazdığınız gereksinimleri gönderin; teklif isteyin, bunları puanlanabilir bir şartnameye çeviren gözden geçirmeyi fiyatlandıralım.

Eksik bir RFP'in yapamadığı ama tam bir RFP'in yaptığı beş şey:

• Çözümü değil, sorunu tanımlar. "Aylık konsolide raporu günlerden tanımlı bir saat sayısına indirmek" bir sorun ifadesidir; "bize bir veri deposu yapın" çözmesi gereken şeyi bilmeyen bir çözüm tahminidir.


• Gereksinimleri tercihlerden ayırır. Geçip geçmeyi belirleyen vazgeçilmezler, sıralamayı belirleyen olmazsa olmazlar ve hiçbir şeyi belirlemeyen güzel-olacaklar. Bu ayrım görünür olmadan tedarikçiler ciddi yanıt vermez.


• Kısıtları adlandırır. Bağlanması gereken mevcut sistemler, taşınması gereken veri, denetim ve saklama yükümlülükleri, devreye alma penceresi, onayı kimin verceği.


• Değerlendirme yöntemini önceden söyler. Ağırlıklı kriterler, kimin değerlendirdiği, hangi kanıtın istendiği ve başarısız tedarikçilerin puan özetlerini ne zaman alacağı.


• Süreç tarihlerini koyar. Soru son tarihi, açıklama penceresi, teslim son tarihi, değerlendirme dönemi, karar tarihi. Tarihi olmayan süreç, zaten meşgul tedarikçileri çeker.

RFP yapısı

İşlevsel ve işlevsel olmayan gereksinimler

İşlevsel gereksinimler sistemin ne yaptığını tarif eder: hangi süreçler, hangi roller, hangi çıktılar. İşlevsel olmayan gereksinimler bunu ne kadar iyi yaptığını tarif eder ve en sık eksik kalanlar da bunlardır; sonra pahalı biçimde, ya da hiç, zorlanırlar.

Çoğu B2B projesinde açıkça söylenmeye değer:

• Performans. Önemli olan işlemlerde — sipariş girişi, rapor üretimi, ay sonu kapanışı — belirli bir yük altında yanıt süreleri.


• Kullanılabilirlik. İşletmenin ne kadar çalışma süresi ihtiyacı var, bakım pencereleri nedir, sistem kapalıyken ne olur; kabul edilebilir kesinti tarif edilmemiş bir hedef gereksinim değildir.


• Kurtarma. RTO ve RPO sade dille: bir olaydan sonra operasyonun ne kadar sürede döndüğü ve ne kadar işin kaybedilebileceği. Her iki rakam da yalnızca sözleşmede değil, değerlendirmede olmalıdır.


• Denetim izi Kim neyi ne zaman değiştirdi; ne kadar süre saklanır, kim erişebilir — özellikle para, stok veya kişisel veri hareket ediyorsa.


• Erişilebilirlik ve kullanılabilirlik. Kim kullanır, hangi cihazlarda, hangi dillerde; deponun çalıştıramadığı bir sistem, iyi puanlasa da uygulanmış değildir.


• Entegrasyon ve veri. Hangi sistemler bağlanır, veri hangi yönde akar ve her varlığın kaydı kimdedir.

Güvenlik ve uyum soruları

Güvenlik, evet/hayır satırı yerine kanıt istenen sorular olarak sorulduğunda daha iyi sonuç verir. Dahil etmeye değer olanlar:

• ISO/IEC 27001 — tedarikçi belgeye sahip mi, sertifikalı kapsam neyi kapsıyor? Satış organizasyonunu teslim ekiplerini değil kapsayan bir belge size özgü bir şey söyler.


• Güvenli geliştirme — güvenliğin tasarım, kod incelemesi ve testte yeri nedir; bağımlılık ve açık yönetimi rutin mi.


• OWASP Top 10 — web'e açık bileşenlerin incelemesinin parçası mı; somut ve yanıtlanabilir bir soru.


• Erişim kontrolü — ortamlarınıza ve verinize kim erişebilir, erişim nasıl verilir ve kaldırılır, ne tür kayıt tutulur.


• Veri koruma yükümlülükleri — uygulandığı yerde KVKK ve GDPR; kim sorumlu kim işleyen, alt işlemciler ve ihlal bildirimi hakkında veri işleme sözleşmesi ne diyor.

Ticari koşullar ve SLA'lar

Fiyatı karşılaştırılabilir bir yapıda isteyin: ne dâhil, ne ayrı fiyatlanıyor ve değişiklikler nasıl fiyatlanıyor. Arkasında kapsam olmayan tek bir rakam, başka bir tek rakamla karşılaştırılamaz; yaygın yapıları ve her birinin doğurduğu soruları maliyet ve fiyatlandırma modelleri sayfası anlatır.

SLA'lar da gereksinimler kadar kesinlik ister. Bir kullanılabilirlik yüzdesi ancak ölçüm yöntemi, istisnaları ve telafisiyle anlam taşır; bir yanıt süresi ancak önem dereceleri ve çalışma saatleriyle anlam taşır. Yüzdeliklerden oluşan, tanımı olmayan bir sayfayı kabul etmek yerine tedarikçilerden SLA içindeki terimleri tanımlamalarını isteyin.

Değerlendirme puanlama matrisi

Kopyalanabilir bir şablon. Aşağıdaki ağırlıklar bir örnektir — kendi önceliklerinize göre ayarlayın ve toplamı 100'de tutun. 1, 3 ve 5'in ne anlama geldiğini kimse puanlamadan önce, tartışmalar başlamadan önce tanımlayın.

Bu işi yapan iki disiplin. Tartışmadan önce bağımsız puanlayın; ilk kendinden emin ses odayı belirlemesin. Ve puan başına bir satır gerekçe kaydedin — gerekçeli puan özeti alan tedarikçiler sonucu çok daha kolay kabul eder ve kendi ekibiniz bunu altı ay sonra savunabilir.

Üçüncü bir disiplin kimin puanladığıyla ilgilidir. Panel, sonucu yaşayacak kişileri içermelidir: süreç sahibi, veriden sorumlu kişi, varsa güvenlik veya finanstan biri — yalnızca satın alma değil. Panel, değerlendirebildiği şeyleri (teklifin düzenini, satış ekibinin parlaklığını) puanlayıp yargılayamadığı şeyleri ertelediğinde değerlendirmeler sessizce başarısız olur. "Bu, çalıştığımız sistemlerle gitmez" deme yetkisine sahip bir teknik kişi, herhangi bir iskontodan daha fazla maliyeti önler.

Ağırlıkların kendileri de bir uyarı hak eder: öncelik beyanıdır ve tedarikçilere görünür. Güvenlik %5, fiyat %30 ağırlıklaysa ciddi güvenlik duyarlılığı olan tedarikçiler bunu fark eder; sözleşmeyi imzalarken kendi ekibiniz de fark eder. Tabloyu doldurmak için aceleyle verilmiş bir ağırlık, odadakiler dışındaki herkesin gerçeği olarak okunur; onu odada karar sahipleriyle bir kez belirleyin ve yalnızca kurulurkenki aynı ciddiyetle değiştirin.

Referanslar ve pilot

Vaka anlatımları pazarlamadır; referans aramaları kanıttır. İşe yarayan çağrı kısa olandır ve teslim edilenden çok ne olduğuna sorar: proje bitti mi, kapsamda ne değişti, ekip gerçekten kimdi, başka ne yaparlardı ve bu tedarikçiyle aynı projeye tekrar başlarlar mıydı. Geçmiş zaman ve somut yanıtlar işaretin kendisidir. Bir referansın daha söylemediği ama öğrenmeye değer bir şey vardır: proje bittikten sonra ne oldu. Sistem hâlâ kullanılıyor mu, yeni talepler aynı ekiple mi karşılanıyor, yoksa teslimattan sonra sessizce başka bir tarafla mı devam edildi? İyi iş, teslimattan sonraki sessizlikte belli olur.

Boyut ve karmaşıklık açısından size benzeyen bir projeden referans isteyin; tedarikçinin en gurur duyduğu işten değil — bütçeniz iki katı olan amiral gemisi bir uygulama, ekibin sizin ölçeğinizde nasıl davrandığı hakkında az şey öğretir. Ve referansı kendiniz kontrol edin: tedarikçiye önceden brifing verilmiş bir kişi referans değil, temennidir; işe yarayan çağrı, müşterinin size sorulacakları o anda öğrendiği çağrıdır.

Ardından kısa ve ücretli bir pilot, hiçbir referansın veremeyeceği kısmı test eder: gereksinimler eksikken bu ekibin sizin insanlarınızla nasıl çalıştığını. Tasarım kuralları her pilot için geçerli olanlardır: gerçek iş, yazılı kabul kriterleri, bir yol ortası değişikliği ve önceden anlaşılmış bir karar kuralı. Pilot tasarımını outsourcing sayfası daha ayrıntılı ele alır.

Kontrol edilecek sözleşme maddeleri

• Fikri mülkiyet devri — kod, dokümantasyon ve türevlerin haklarının yalnızca son ödemede değil, yaratılıştan itibaren size devri.
• Veri mülkiyeti — veriniz sizindir; tedarikçinin hakları teslim için gerekenle sınırlıdır.
• Kabul — kabulün ne demek olduğu, kimin ilan ettiği ve bir şey kabulü geçemediğinde süreç.
• Değişim kontrolü — kapsam değişikliklerinin nasıl istendiği, fiyatlandığı ve onaylandığı; olmadan her değişiklik bir uyuşmazlık olur.
• Çıkış ve geçiş — sonunda kaynak kod, erişim, dokümantasyon ve yardım; tedarikçi değişirse bilginin aktarımı.
• Escrow — iş sürekliliği tedarikçinin elindeki bileşenlere bağlıysa tedarikçi devam edemezse ne olduğu.
• Sorumluluk — sınırlar, istisnalar ve sigortalanmayanlar; fiyatla aynı dikkatle okunur.
• Fesih — bildirim süreleri, fesih sonrası yükümlülükler ve verinin iade ya da silinme süreci.

Bu maddeleri okurken bir bütünlük sorusu da yardımcı olur: her madde bir varsayım barındırır ve maddeler birbirini besler. Kabul tanımı yoksa değişim kontrolü de işlev görmez; çünkü her şey kabul edilmemiş iş gibi görünür. Çıkış maddesi yoksa IP devri kısmen kalır; çünkü koddan ayrı bir ekibi kimin sürdüreceği belirsizdir. Bu yüzden maddeleri tek tek pazarlık etmek yerine, aralarındaki bu bağımsallıkla birlikte okumak ve en kritik üçünü — kabul, değişim ve çıkış — daha ilk taslağı gönderirken yazdırmak, müzakereyi çok daha kısa tutar.

Sıkça Sorulan Sorular

Önce RFP mi RFI mi göndermeliyiz?

Piyasa ya da sorun belirsizse RFI: ne var ve ne kadar tutuyor diye sorarsınız. Gereksinimler ve değerlendirme yöntemi tanımlıysa RFP; daha önce göndermek gereksinim işini her tedarikçinin teklifine, onların diliyle ve öncelikleriyle taşır.

Kaç tedarikçiye davet gönderelim?

Her teklifi düzgün okuyabileceğiniz ve her aramayı yapabileceğiniz kadar az. Birkaçının üzerinde değerlendirmelerin kalitesi düşer; bir RFI, bir eleme görüşmesi ve bir benzer referans projesiyle kurulmuş kısa liste, ünlü isimlerden uzun bir listeden çoğu zaman daha yararlıdır.

Ağırlıklar nasıl belirlenir?

Hiçbir teklif görmeden önce önceliklerinizden ve sonucu yaşayacak kişiler arasında uzlaşarak. Sık görülen hata her şeye eşit ağırlık vermektir; bu, hiçbir şeyin diğerinden daha önemli olmadığını söylemenin bir yoludur. Fiyat ya da risk sizin için baskınsa ağırlıklar bunu söylemelidir.

Fiyat puanlanmalı mı?

Evet, ama kapsamı sabitlenmiş tek bir ağırlıklı kriter olarak; tüm değerlendirme olarak değil. Kapsamı olmadan puanlanan fiyat, en az işi varsayan tedarikçiyi ödüllendirir; önce gereksinimlerinizi fiyatlayın, sonra aynı şeyin toplamlarını karşılaştırın.

Güvenlik yanıtları nasıl puanlanır?

Tona göre değil, kanıta göre. Üç seviye iyi çalışır: konum yok (1), politikalar tarif edilmiş (3), sertifika kapsamı doğrulanmış artı güvenli geliştirme tarif edilmiş ve kanıt sunulmuş (5). Belgesi olmayan bir tedarikçiden yazılı olarak hangi eşdeğer kontrollerin olduğunu sorun; belgeli denetimlerle dürüst bir hayır, doğrulanamayan bir evetten daha iyi puan alır.

RFP'ten sonra gereksinimleri değiştirebilir miyiz?

Teslimlerden önce, evet — değişikliği herkese duyurarak. Teslimlerden sonra yalnızca tüm teklif sahiplerinin aldığı resmî bir açıklamayla; bir tedarikçiye sessizce gereksinim değiştirmek, tüm sürecin üzerine kurulduğu karşılaştırılabilirliği bitirir. Sözleşmeden sonra bunun için değişim kontrolü vardır.

Kaynaklar ve standartlar

• ISO — ISO/IEC 27001 (bilgi güvenliği yönetim sistemi) yayıncısı; bir belgeye dayanmadan önce geçerli basımı ve kapsamı doğrulayın.
• OWASP — bu sayfada adı geçen Top 10 web uygulaması güvenlik riski listesinin yayıncısı.
• Puanlama matrisi ilkeleri yayımlanmış RFP şablonu uygulamalarına dayanır; gösterilen ağırlıklar düzenlenecek bir örnektir, tavsiye değildir. Bu sayfa satın alma rehberidir, hukuki tavsiye değildir ve WorldwideTradeX için sertifika veya denetim iddia edilmez.

İlgili sayfalar

Yazılım geliştirme · Türkiye'den yazılım outsourcing · Maliyet ve fiyatlandırma modelleri · IT denetimi ve danışmanlık · Teklif isteyin