RFQ ve Teklif Toplama Süreci Nasıl Kurulur?
Ders 5 / 10 · 30 dakika okuma · İleri
Satın alma ihtiyacını açık ve karşılaştırılabilir bir teklif talebine dönüştürmeyi; tedarikçi daveti, soru-cevap, teklif revizyonu, son tarih ve teklif bütünlüğünü kontrollü bir RFQ süreci içinde yönetmeyi öğrenin.
Bu Derste Öğrenecekleriniz
- ✓RFI, RFQ ve RFP benzeri tedarikçi etkileşimlerinin kullanım amaçlarını ayırt etmek
- ✓Karşılaştırılabilir teklif üreten RFQ kapsamını ve veri alanlarını tasarlamak
- ✓Teknik kapsam ile ticari teklif formatını birbirinden ayırmak
- ✓Tedarikçi davet listesini uygunluk ve rekabet koşullarına göre oluşturmak
- ✓Soru-cevap ve zeyil/değişiklik sürecini tüm katılımcılar için tutarlı yönetmek
- ✓Teklif son tarihi, revizyon, versiyon ve audit izini sistematik hale getirmek
- ✓Eksik veya koşullu teklifleri değerlendirme öncesinde tespit etmek
Teklif toplamanın amacı farklı tedarikçilerden birkaç fiyat rakamı almak değildir. Amaç, aynı ihtiyacın mümkün olduğunca aynı kapsam ve ticari varsayımlar altında fiyatlandırılmasını sağlayarak gerçek bir karar zemini oluşturmaktır. Kapsam belirsizse alınan teklifler sayısal olarak yan yana gelebilir ancak ticari olarak karşılaştırılabilir olmayabilir.
Not — RFQ'nun temel sorusu
1. Önce hangi tedarikçi etkileşimine ihtiyacınız olduğunu belirleyin
Satın alma ihtiyacı her zaman doğrudan fiyat istemeye hazır olmayabilir. Pazar ve çözüm seçenekleri bilinmiyorsa önce bilgi toplamak; çözüm yaklaşımı bekleniyorsa daha kapsamlı öneri istemek; kapsam net ve karşılaştırılabilir ise fiyat/koşul odaklı teklif toplamak daha uygundur.
| Yaklaşım | Temel amaç | Ne zaman yararlı? |
|---|---|---|
| RFI / bilgi talebi | Pazar, yetkinlik ve çözüm seçeneklerini anlamak | İhtiyaç veya tedarikçi pazarı henüz net değilse |
| RFQ / teklif talebi | Tanımlı kapsam için fiyat ve ticari koşul toplamak | Ürün/hizmet karşılaştırılabilir biçimde tarif edilebiliyorsa |
| RFP / öneri talebi | Çözüm yaklaşımı, metodoloji ve ticari öneriyi birlikte değerlendirmek | Sonucun tanımlı fakat çözüm yolunun tedarikçiye bırakıldığı karmaşık alımlarda |
Uyarı — Etiket değil ihtiyaç önemlidir
2. RFQ'yu talep formunun kopyası olarak göndermeyin
İç satın alma talebi işletmenin kendi karar süreci için hazırlanır. RFQ ise tedarikçinin doğru kapsamı anlayıp fiyatlandırabilmesi için ticari ve teknik bir dış iletişim belgesidir. İç notlar, bütçe limitleri veya karar mekanizmasına ait gereksiz bilgiler RFQ'nun parçası olmak zorunda değildir.
| RFQ bileşeni | İçerik örneği | Neden gerekli? |
|---|---|---|
| Kapsam | Ürün/hizmet tanımı, teknik şartname | Ne fiyatlandığını sabitler |
| Miktar/hacim | Adet, dönemsel tahmin, lot | Fiyat ve kapasite varsayımını netleştirir |
| Teslimat | Lokasyon, tarih, Incoterm gerekiyorsa | Lojistik ve termin koşulunu belirler |
| Ticari format | Birim fiyat, para birimi, vergi, iskonto | Teklifleri karşılaştırılabilir yapar |
| Ödeme | Beklenen veya teklif edilecek vade/avans koşulu | Nakit akışı etkisini görünür kılar |
| Geçerlilik | Teklifin geçerli olacağı süre | Karar dönemindeki fiyat riskini sınırlar |
| Teklif son tarihi | Tarih/saat ve kanal | Süreç disiplinini sağlar |
| Ek koşullar | Garanti, SLA, servis, ambalaj, sertifika | Fiyat dışı yükümlülükleri netleştirir |
3. Fiyat şablonunu satın alma kararına göre tasarlayın
Tedarikçilerin biri toplam paket fiyatı, diğeri birim fiyat, üçüncüsü kurulum ve yıllık hizmeti birlikte yazarsa teklif karşılaştırması manuel düzeltmeye dönüşür. RFQ'da hangi fiyat bileşenlerinin ayrı girileceği ve hangi para biriminin kullanılacağı açık olmalıdır.
Örnek — Yazılım hizmeti için fiyat kırılımı
4. Teknik uygunluk ile ticari teklifi ayrı alanlarda toplayın
Tedarikçi düşük fiyat verebilir ancak zorunlu teknik koşullardan birini karşılamayabilir. Bu nedenle teklif formu yalnız fiyat tablosundan oluşmamalı; zorunlu gereksinimlere uygunluk, sapma ve açıklamalar da yapılandırılmış biçimde alınmalıdır.
| Gereksinim | Tedarikçi yanıtı | Sapma/açıklama |
|---|---|---|
| Zorunlu teknik özellik A | Uygun / Uygun değil | … |
| Teslim süresi ≤ X gün | … | … |
| Garanti ≥ X ay | … | … |
| Belge/sertifika | … | … |
İpucu — Sapmaları saklamayın
5. Davet listesini yalnız mevcut alışkanlıklara göre oluşturmayın
RFQ'ya hangi tedarikçilerin davet edileceği rekabetin ve karar kalitesinin önemli parçasıdır. Onaylı tedarikçi statüsü, kategori yetkinliği, kapasite, coğrafya, risk durumu ve geçmiş performans davet kararında kullanılabilir. Yeni tedarikçi gerekiyorsa onboarding ile sourcing süreçleri koordineli ilerlemelidir.
- İlgili kategori için yetkinlik
- Aktif/onaylı veya koşullu uygunluk durumu
- Kapasite ve teslimat bölgesi
- Zorunlu belge ve sertifikalar
- Risk/kısıt durumu
- Geçmiş performans
- Rekabet ve alternatif kaynak ihtiyacı
- Çıkar çatışması veya politika kısıtları
6. Tedarikçi soru-cevap sürecini eşit bilgi prensibiyle yönetin
Bir tedarikçinin sorduğu soru RFQ kapsamındaki belirsizliği ortaya çıkarıyorsa cevap diğer katılımcıların teklifini de etkileyebilir. Kararı etkileyen açıklamalar yalnız soruyu soran tedarikçide kalmamalı; gizli/ticari bilgi içermeyen gerekli açıklamalar kontrollü biçimde ilgili katılımcılara duyurulmalıdır.
Örnek — Eşit bilgi örneği
7. RFQ değişikliklerini versiyonlayın
Teklif sürecinde miktar, teknik özellik veya teslim tarihi değişebilir. Eski dosyanın üzerine yeni belge yüklemek yerine değişikliğin ne olduğu, ne zaman yayımlandığı ve teklif son tarihini etkileyip etkilemediği kayıt altına alınmalıdır.
- Değişiklik ihtiyacını ve gerekçesini kaydedin.
- Yeni RFQ/şartname versiyonunu oluşturun.
- Etkilenen tedarikçileri aynı kontrollü kanaldan bilgilendirin.
- Gerekirse teklif son tarihini güncelleyin.
- Tedarikçilerin güncel versiyona göre teklif verdiğini doğrulayın.
- Eski versiyonları audit geçmişinde koruyun.
8. Teklif son tarihi ve geç teklif politikasını önceden belirleyin
Son tarih geçtikten sonra bir tedarikçinin teklifini kabul edip diğerine aynı imkanın verilmemesi süreç güvenilirliğini zedeler. Geç teklif, süre uzatma ve teknik sistem arızası gibi durumların nasıl yönetileceği RFQ başlamadan önce politika ile belirlenmelidir.
Uyarı — Manuel e-posta trafiği audit izini zayıflatır
9. Teklif revizyonlarını ilk teklifin üzerine yazmayın
Müzakere veya açıklama sonrası tedarikçi revize teklif verebilir. Her versiyon ayrı zaman damgası, teklif sahibi ve değişiklik geçmişiyle saklanmalı; seçim kararında hangi versiyonun kullanıldığı açık olmalıdır.
| Versiyon | Birim fiyat | Termin | Ödeme | Durum |
|---|---|---|---|---|
| V1 | 100 | 20 gün | 30 gün | İlk teklif |
| V2 | 96 | 20 gün | 30 gün | Müzakere sonrası |
| V3 | 96 | 15 gün | 45 gün | Nihai teklif |
10. Teklifleri puanlamadan önce uygunluk kapısından geçirin
Eksik zorunlu belge, karşılanmayan kritik teknik koşul veya belirsiz fiyat kapsamı bulunan teklif doğrudan fiyat sıralamasına alınmamalıdır. Önce teklifin değerlendirmeye uygun olup olmadığı belirlenmeli; düzeltilebilir eksikler için politika kapsamında açıklama süreci işletilmelidir.
| Kontrol | Sonuç örneği |
|---|---|
| Zorunlu teknik koşullar | Geçti / geçmedi |
| Teklif kapsamı tam mı? | Tam / açıklama gerekli |
| Fiyat formatı uygun mu? | Uygun / normalize edilmeli |
| Zorunlu belge mevcut mu? | Evet / hayır |
| Teklif süresinde mi? | Evet / politika istisnası gerekli |
| Ticari sapmalar açık mı? | Evet / açıklama gerekli |
İlgili çözüm: Satın Alma ve Tedarikçi Portalı
Şimdi Uygulayın
Uygulama Görevi — Karşılaştırılabilir RFQ Tasarlayın
İşletmenizde yakın zamanda satın alınmış bir ürün veya hizmet seçin. Aynı ihtiyacı yeniden RFQ'ya çıkaracağınızı varsayın. Kapsam, miktar, teslimat, teknik uygunluk, fiyat kırılımı, ödeme koşulu, teklif geçerliliği, soru son tarihi ve teklif son tarihini içeren bir RFQ veri şablonu hazırlayın. Ardından üç farklı tedarikçinin aynı şablonu doldurduğunda hangi alanların doğrudan karşılaştırılabileceğini kontrol edin.
| RFQ alanı | Zorunlu mu? | Tedarikçi yanıt formatı | Kararda kullanım |
|---|---|---|---|
| Kapsam/ürün | … | … | … |
| Miktar | … | … | … |
| Birim fiyat | … | … | … |
| Termin | … | … | … |
| Ödeme | … | … | … |
| Teknik uygunluk | … | … | … |
| Garanti/SLA | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓İyi bir RFQ yalnız 'fiyat gönderin' talebi değildir.
- ✓İhtiyaç kapsamı, miktar, teknik gereksinimler, teslimat, ödeme, teklif formatı, geçerlilik süresi ve değerlendirmeyi etkileyen ticari koşullar açık olmalıdır.
- ✓Tedarikçilere aynı karar verici bilgi sağlanmalı; soru-cevap ve değişiklikler izlenebilir biçimde yönetilmeli; tekliflerin kapsam farkları seçimden önce görünür hale getirilmelidir.