Tedarikçi RFQ'ları ve Teklif Karşılaştırması için Web Uygulaması Nasıl Oluşturulur

RFQ ve Teklif Karşılaştırma İş Akışını Kapsamlandırın

Ekranları tasarlamadan veya teknoloji yığını seçmeden önce iş akışının baştan sona ne yapması gerektiğini netleştirin. Açık bir kapsam, her ekip kendi uç durumlarını ekleyerek işin büyümesini önler ve ilk sürümünüzün hemen kullanılabilir olmasını sağlar.

Ana kullanıcılar ve ihtiyaçları

Önce birincil rolleri ve aralarındaki sınırları isimlendirin:

• Alıcılar RFQ oluşturur, tedarikçi davetlerini yönetir, soruları yanıtlar ve teklifleri inceler.
• Onaylayanlar kısa liste seçenekleri gözden geçirir, politika uyumunu sağlar ve ödülleri onaylar.
• Tedarikçiler davetleri alır, teklifler gönderir, destekleyici belgeler yükler ve cevapları revize eder.
• Yöneticiler şablonları, para birimleri/vergiler kurallarını, izin setlerini ve denetim gereksinimlerini yapılandırır.

Temel işler (vazgeçilmezler)

MVP iş akışınız genelde şunları içerir:

1. RFQ oluşturma (kalemler, miktarlar, teslim yerleri, istenen şartlar).
2. Tedarikçileri davet etme (e-posta veya portal erişimiyle) ve kimin görüntülediğini/yanıtladığını izleme.
3. Teklifleri alma (satır bazlı fiyatlandırma artı ekler ve notlar).
4. Karşılaştırma ve ödül (verileri normalleştir, kısa liste yap, öner, tedarikçiyi kesinleştir).

“Karşılaştırma”nın ne anlama geldiğini tanımlayın

“Yan yana” gösterim kuruluşlara göre çok farklı şeyler ifade edebilir. Hangi boyutların birinci sınıf olduğunu baştan belirleyin:

• Fiyat (birim fiyat, toplam, indirimler, kademeli fiyatlandırma)
• Teslim süresi (üretim + nakliye, taahhüt edilen teslim tarihi)
• Ticari şartlar (ödeme koşulları, garanti, iadeler)
• Kalite ve risk (sertifikalar, geçmiş performans, tedarikçi risk uyarıları)

Her şeyi etkileyen kısıtlar

Sert gereksinimleri erken yakalayın çünkü bunlar veri modeli ve UI'ı şekillendirir:

• Çoklu para birimi teklifleri ve döviz kurları (spot vs ödül anındaki sabit kur)
• Vergiler ve harçlar (dâhil/dâhil değil fiyatlama; bölgesel vergi kuralları)
• Incoterms (EXW/FOB/CIF vb.) ve nakliye sorumluluğu
• Ekler (spesifikasyonlar, uyumluluk belgeleri) boyut/tür sınırlamalarıyla
• SLA'lar ve son tarihler (soru dönemi, gönderim kesme, revizyon penceresi)

Bunlar kararlaştırıldıktan sonra iş akışı durumlarını ve izinleri çok daha az sürprizle tasarlayabilirsiniz.

Süreci Tasarlayın: Durumlar, Roller ve Bildirimler

Net bir RFQ süreci, “herkes işin bittiğini düşünüyor” ile ekibinizin güvenebileceği bir iş akışı arasındaki farktır. Ekranları oluşturmadan önce RFQ'nizin geçebileceği durumları, kimlerin hareket ettirebileceğini ve her adımda hangi kanıtların olması gerektiğini tanımlayın.

Uçtan uca aşamaları eşleyin

Durumları basit ama açık tutun:

• Taslak: dahili hazırlık; tedarikçiler hiçbir şeyi göremez.
• Gönderildi / Açık: RFQ seçilen tedarikçilere yayımlandı; gönderim penceresi açık.
• Soru-Cevap: tedarikçiler soru sorar; cevaplar adil şekilde paylaşılır (genelde tüm davetlilere).
• Kapandı: teklifler alındı (veya son tarih geçti); tedarikçi düzenlemesi kilitlenir.
• Değerlendirildi: alıcılar teklifleri normalleştirir ve karşılaştırır.
• Ödül Verildi: karar kaydedildi ve iletişim kuruldu.
• Arşivlendi: RFQ denetim için saklanır; değişiklikler resmi bir istisna gerektirir.

Aşama başına gereken belgeler

RFQ'nin ilerlemesi için hangi belgelerin eklenmesi veya yakalanması gerektiğini tanımlayın:

• RFQ paketi (spesifikasyonlar, şartlar, teslim gereksinimleri) Draft → Sent/Open geçişi için zorunlu.
• Gönderim sonrası herhangi bir değişiklik için Addenda (sürümlenmiş).
• Tedarikçi teklifi (dosyalar ve/veya satır öğeleri) Closed için gerekli.
• Açıklamalar RFQ ve tedarikçiye bağlı konu dizileri olarak yakalanmalı.

Bu, uygulamanın iyi alışkanlıkları zorlamasını sağlar: "eklenti olmadan gönderilemez", "değerlendirme kaydı olmadan ödül verilemez" gibi hataları önler.

Roller ve onaylar

En azından şu rolleri modelleyin: Talep Eden, Alıcı, Onaylayan, Tedarikçi ve isteğe bağlı Finans/Hukuk. Onay kapılarını erken belirleyin:

• RFQ yayın onayı (Draft → Sent/Open) yüksek değerli veya hassas kategoriler için.
• Ödül onayı (Evaluated → Awarded), miktar eşiklerine göre kural tabanlı yönlendirme dahil.
• İstisnalar (geç teklifler, gönderim sonrası spes değişiklikleri) açık onay gerektirebilir.

Bildirimler ve hatırlatmalar

Bildirimleri durum değişikliklerine ve son tarihlere bağlayın:

• Gönderildi/Açık olduğunda tedarikçi davetleri ve son tarih hatırlatmaları.
• Bir mesaj gönderildiğinde alıcı ve tedarikçilere Soru-Cevap uyarıları.
• Tüm teklifler alındığında ve değerlendirme geciktiğinde iç hatırlatmalar.
• Ödül ve red bildirimleri Awarded durumunda, denetime uygun zaman damgası ile.

Veri Modelinizi ve Varlıkları Planlayın

Veri modeliniz, bir tedarikçi RFQ yönetim uygulamasını esnek tutar veya değiştirmesi acı verici hale getirir. "RFQ → davet edilen tedarikçiler → teklifler → değerlendirme → ödül" zinciri için temiz bir yapı hedefleyin; fiyat karşılaştırma tabloları, çoklu para birimi teklifler ve denetim izi gibi özellikler için yeterli yapı bırakın.

RFQ: başlık + satır öğeleri

Genelde RFQ için başlık düzeyi alanlarını saklayan bir RFQ varlığı ile başlayın: proje/referans, son tarih ve zaman dilimi, varsayılan para birimi, teslimat yeri (ship-to), ödeme/Incoterms ve standart koşullar.

RFQ Satır Öğelerini ayrı modelleyin. Her satır SKU/hizmet tanımı, miktar, birim ölçü ve hedef spesifikasyonları saklamalı. Kabul edilebilir ikame ve alternatifler için açık alanlar ekleyin ki tedarikçiler ayrıntıları serbest metinde saklamak zorunda kalmasın.

Tedarikçi: kimler ve uygunluk

Tedarikçi varlığı; çoklu kontaklar (e-posta/roller), hizmet verdikleri kategoriler, uyumluluk belgeleri (dosyalar + son kullanma tarihleri) ve dahili performans notlarını kapsamalı. Bu, kategori veya uyumluluk durumuna göre otomatik davet filtrelemesi gibi satın alma otomasyonunu destekler.

Teklif: karşılaştırabileceğiniz yapılandırılmış yanıtlar

Teklif RFQ ve tedarikçiye bağlanmalı; satır bazında yanıtlar: birim fiyat, para birimi, teslim süresi, MOQ, geçerlilik tarihi, yorumlar ve dosya ekleri saklanmalı.

Çoklu para birimi teklifleri için orijinal para birimini ve normalleştirme için kullanılan döviz kuru anlık görüntüsünü saklayın. Tedarikçi tarafından girilen değerleri asla üzerine yazmayın—hesaplanmış “normalleştirilmiş” toplamları ayrı tutun.

Değerlendirme: kararlar, puanlama ve izlenebilirlik

Puanlama, karar notları ve onaylar için bir Evaluation varlığı oluşturun. Bunu bir Audit Event tablosuyla eşleştirin; kim neyi ne zaman değiştirdiğini kaydetsin (durum değişiklikleri, düzenlemeler, ödüller). Bu, onay iş akışı ve denetlenebilirliğin belkemiği olur.

İlham için minimal bir şema istiyorsanız, basit tutun: RFQ, RFQLine, Supplier, SupplierContact, Quote, QuoteLine, Evaluation, AuditEvent, FileAttachment.

Tedarikçi Portalı ve Yanıt Deneyimini Oluşturun

İyi bir tedarikçi deneyimi yanıt oranlarını artırır ve geri dönüşleri azaltır. Önce gerçekten kendinize portal gerekip gerekmediğini veya yalnızca e-posta ile almanın yeterli olup olmadığını karar verin.

Portal vs yalnızca e-posta alımı

Küçük bir tedarikçi tabanınız, basit RFQ'larınız ve teklifleri tekrar elle girme isteğiniz varsa e-posta tabanlı intake MVP için işe yarayabilir. Yapılandırılmış yanıtlar (fiyatlar, teslim süreleri, MOQ, Incoterms), sık tekrar eden RFQ'lar, çoklu ekler veya güçlü bir denetim izi gerektiğinde portal değeri artar.

Hibrit yaklaşım genelde en iyisidir: tedarikçiler portaldan yanıt verebilir, aynı zamanda e-posta bildirimleri alır ve dahili inceleme için RFQ PDF'si indirebilir.

Tedarikçi onboarding: davet, hesaplar ve güven

Onboarding'i hafif tutun. Satın alma bölümü tedarikçileri e-posta ile davet edebilmeli, davet bağlantısı için bir son tarih belirleyebilmeli ve isteğe bağlı olarak temel şirket bilgilerini ön-doldurabilmeli.

En azından onboarding şunları içermeli:

• E-posta doğrulamalı hesap oluşturma
• Basit bir tedarikçi profili (şirket adı, kontaklar, adres, vergi/VAT ID, tercih edilen para birimi)
• Hassas kategoriler veya yüksek değerli alımlar için isteğe bağlı çok faktörlü kimlik doğrulama (MFA)

Tedarikçilere ne göreceklerini net gösterin: sadece kendi RFQ'ları, kendi gönderimleri ve durum güncellemeleri—başka hiçbir şey.

RFQ yanıt formu: yapılandırılmış ama sıkıcı olmayan

Yanıt deneyimi tedarikçileri yapılandırılmış bir form boyunca yönlendirmeli, ama nüans için alan bırakmalı.

İçerik:

• Satır öğesi alanları (birim fiyat, para birimi, teslim süresi, minimum sipariş miktarı, ambalaj, geçerlilik tarihi)
• Başlık düzeyi alanlar (nakliye şartları, ödeme koşulları, navlun gibi toplam ücretler)
• Ekler (spesifikasyonlar, uyumluluk belgeleri) ve açıklamalar için yorum dizisi

Otomatik kaydetme, net doğrulama mesajları ve tedarikçilerin onaylaması için “önizleme gönderimi” adımı kullanın.

Revizyonlar, sürümler ve son tarih kilitleme

Tedarikçiler sıkça teklif revizyonu yapar. Her gönderimi bir sürüm olarak ele alın: geçmiş, zaman damgaları ve kimin gönderdiği saklansın. Son tarihe kadar yeniden gönderime izin verin, sonra düzenlemeyi kilitleyin ama tedarikçilere gönderdiklerini görüntüleme izni verin. RFQ'yi yeniden açarsanız yeni bir tur oluşturun ki karşılaştırmalar temiz ve savunulabilir kalsın.

RFQ'leri Verimli Oluşturun: Şablonlar, İçe Aktarımlar ve Mesajlaşma

Hız önemlidir, fakat tutarlılık da öyle. En iyi yaklaşım RFQ oluşturmayı şablonlar, geçmiş etkinlikler ve tedarikçi listeleri gibi mevcut bilgileri yeniden kullanan rehberli bir iş akışı olarak uygulamaktır; her değişiklik izlenebilir kalsın.

RFQ oluşturma sihirbazı: şablonlar, önceki kopyalama, toplu içe aktarımlar

Bir şablonla başlayan bir RFQ oluşturma sihirbazı oluşturun: varsayılan şartlar, zorunlu alanlar, standart satır sütunları (teslim süresi, Incoterms, garanti) ve önceden belirlenmiş zaman çizelgesi.

Tekrarlanan alımlar için “önceki RFQ'den kopyala” ekleyin; böylece alıcı satır öğelerini, ekleri ve davet edilen tedarikçileri klonlayıp sadece değişeni düzeltebilir.

Daha büyük etkinlikler için CSV ile toplu satır içe aktarımı destekleyin. Önizleme gösterin, geçersiz satırları vurgulayın ve kullanıcıların sütunları eşlemesine izin verin (ör. “Unit Price” vs “Price/EA”). Bu, el girişini azaltır ama kontrolü kaybettirmez.

Tedarikçi seçimi: onaylı listeler, öneriler ve hariç tutmalar

Tedarikçi seçimini hızlı ama kasıtlı yapın. Her kategori için onaylı tedarikçi listesi sunun, ayrıca geçmiş katılım, ödüller veya coğrafya bazında önerilen tedarikçiler gösterin.

Aynı derecede önemli: hariç tutmalar. Alıcıların belirli nedenlerle satıcıları “davet etmeme” olarak işaretlemesine izin verin ve kısa bir not isteyin. Bu, onaylar ve denetimler sırasında bağlam sağlar.

RFQ paketi oluşturma: ekler, şartlar ve Soru-Cevap politikası

Ekleri (çizimler, teknik dokümanlar), ticari şartları ve yanıt talimatlarını bir arada sunan net bir “RFQ paketi” oluşturun. Açık bir Soru-Cevap politikası dahil edin: tedarikçi sorularının özel mi paylaşılacak mı ve açıklama için son zaman ne zaman?

İletişim: toplu mesajlar, özel sorular ve addenda takibi

İletişimi RFQ içinde merkezileştirin. Tüm tedarikçilere yayınlanan mesajlar, özel Soru-Cevap dizileri ve addenda takibi (spes, tarihler veya miktarlarda sürümlenmiş değişiklikler) destekleyin. Her mesaj ve addenda zaman damgalı olmalı ve denetlenebilirlik için RFQ geçmişinde görünmelidir.

Teklif Normalizasyonu ve Yan Yana Karşılaştırmalar Uygulayın

Bir teklif karşılaştırma görünümü, “$10”un tedarikçiler arasında aynı şeyi ifade ettiğine güvenebiliyorsanız işe yarar. Amaç, her yanıtı tutarlı, karşılaştırılabilir bir şekle dönüştürmek—sonra farkları açıkça gösteren bir tabloda sunmaktır.

Kullanıcıların gerçekten taradığı karşılaştırma tablosunu oluşturun

Çekirdek görünümünüzü bir ızgara olarak tasarlayın: tedarikçiler sütun, RFQ satır öğeleri satır olacak şekilde; hesaplanmış ara toplamlar ve tedarikçi başına net bir genel toplam gösterin.

Değerlendiricilerin hemen baktığı birkaç pratik sütun ekleyin: birim fiyat, genişletilmiş fiyat, teslim süresi, geçerlilik tarihi ve tedarikçi notları. Detaylı notları açılabilir yapın ki tablo okunur kalsın.

Karşılaştırmadan önce fiyatları normalleştirin

Normalizasyon, içe aktarma sırasında (veya gönderimden hemen sonra) olmalı ki UI tahminde bulunmak zorunda kalmasın.

Yaygın normalizasyonlar:

• Para birimi dönüşümü: orijinal para birimini saklayın ve RFQ tarafından tanımlanan bir kur anlık görüntüsü kullanarak dönüştürülmüş değerleri kaydedin (tarihsel karşılaştırmaların değişmemesi için).
• Birim dönüşümleri: tedarikçi birimlerini (ör. “12'li kutu”) RFQ'nin temel birimine açık dönüşüm faktörleri ile eşleyin.
• Vergi, navlun ve ücretler: bunları satır fiyatlarından ayrı modelleyin; hem “satır toplamı” hem de “her şey dâhil toplam” gösterin.

Anomalileri ve eksik yanıtları vurgulayın

İstisnaları hafif bayraklarla görünür yapın:

• Aykırı fiyatlar (örn. medyandan \u003eX% sapma)
• Eksik satırlar veya ikame edilen öğeler
• Süresi geçmiş/kısa geçerlilik süreleri
• Uzun teslim süreleri veya tutarsız incoterms/navlun varsayımları

“Ne-olursa” ödüller ve alternatifleri destekleyin

Değerlendiriciler nadiren her şeyi tek bir tedarikçiye verir. Kullanıcılara senaryolar oluşturma izni verin: satır bazında bölünmüş ödüller, kısmi miktarlar veya alternatifleri kabul etme.

Basit bir desen, normalleştirilmiş teklifler üzerinde bir “senaryo” katmanıdır; kullanıcılar miktarları tedarikçilere atadıkça toplamları yeniden hesaplar. Senaryo çıktıları kolayca dışa aktarılabilir olmalı (ör. /blog/rfq-award-approvals) onay iş akışları için.

Değerlendirme, Puanlama ve Ödül Önerileri Ekleyin

Teklifler normalleştirildiğinde ve karşılaştırılabilir hale geldiğinde, uygulama “daha iyi”yi “karar” haline getiren net bir yola ihtiyaç duyar. Değerlendirme yeterince tutarlı olmalı, ama farklı kategoriler ve alıcılar için esnek kalmalıdır.

Gerçekten nasıl satın aldığınızla eşleşen kriterleri tanımlayın

Çoğu ekip tarafından tanınan varsayılan bir puan kartıyla başlayın, sonra RFQ bazında ayarlara izin verin. Yaygın kriterler: maliyet, teslim süresi, ödeme koşulları, garanti/destek ve tedarikçi riski.

Her kriteri açık tutun:

• Ne ölçülüyor (örn. “takvim gün cinsinden teslim süresi”)
• Hangi yön daha iyi (daha düşük/daha yüksek)
• Zorunlu mu (örn. Net 30 kabul zorunlu)

Ağırlıklı puanlama (büyüleyici değil, şeffaf olsun)

Ağırlıklı puanlama takımların "hep en düşük fiyat" kuralına takılmasını önler ve ödünleşimleri görünür kılar. Basit ağırlıklandırma destekleyin (örn. %40 maliyet, %25 teslim süresi, %15 risk, %10 garanti, %10 ödeme şartları) ve kullanıcıların RFQ başına ağırlıkları ayarlamasına izin verin.

Formüller için şeffaflık ve düzenlenebilirlik öncelikli olsun:

• Her tedarikçi için kullanılan kesin hesaplamayı gösterin
• Kullanıcıların hesaplanan alt-puana not ile birlikte geçersiz kılmasına izin verin
• Ağırlıklar veya formüller değiştiğinde kim tarafından değiştirildiğini kaydedin

Çoklu değerlendirici incelemeleri notlar ve kanıtlarla

Gerçek kararlar birden çok görüş içerir. Birden fazla değerlendiricinin bağımsız olarak puan vermesine, not eklemesine ve ek destekleyici dosyalar (spesler, uyumluluk belgeleri, e-postalar) yüklemesine izin verin. Ardından birleşik bir görünüm gösterin (ortalama, medyan veya rol-ağırlıklı) ancak bireysel girdileri saklamayın.

Karar çıktısı: öneri, gerekçe, istisnalar

Sistem, paylaşılmaya hazır bir “ödül önerisi” üretmelidir: önerilen tedarikçi(ler), ana nedenler ve ödünleşmeler. Ayrıca istisna yönetimini destekleyin—örn. daha kısa teslim süresi nedeniyle daha pahalı bir tedarikçiye ödül verme—zorunlu gerekçe alanları ve ek belge yükleme gereksinimleri ile. Bu onayları hızlandırır ve kararlar sonra incelendiğinde ekibi korur.

Onaylar, İzinler ve Denetlenebilirlik

Bir teklif karşılaştırma aracı ancak insanların karara güvenmesi ve nasıl alındığını kanıtlayabilmesi durumunda işe yarar. Bu, satın alma politikalarına uyan onaylar, yetkisiz değişiklikleri engelleyen izinler ve incelemelerde ayakta kalacak bir denetim izi gerektirir.

Politika ile eşleşen onay yolları

Küçük bir onay kural seti ile başlayın, sonra gerekirse genişletin. Yaygın desenler: harcama eşiğine göre onay, kategoriye göre yönlendirme, proje bazlı onay ve istisna bayrakları.

Örnek:

• Harcama eşiği: $5k, $25k, $100k seviyelerinde onaylar tetiklenir (para birimi başına yapılandırılabilir).
• Kategori bazlı: IT alımları IT onayı, tesis alımları tesis onayına gider.
• Proje bazlı: proje sahibi veya maliyet merkezi yöneticisine yönlendirme.
• İstisna kuralları: tercih edilmeyen tedarikçi seçimi, bütçe aşımı, bölünmüş ödüller veya geç kabul edilen teklifler otomatik yönlendirilir.

Onayları UI'da okunabilir tutun (“neden bekliyor?”) ve kapsam, miktar, ana tarihler veya fiyat farkları gibi maddi değişikliklerde yeniden onay gerektirin.

En az ayrıcalık ilkesiyle izinler

Rolleri gerçek görevler etrafında tanımlayın:

• Alıcılar RFQ oluşturabilir, tedarikçileri davet edebilir ve taslak ödüller hazırlayabilir.
• Onaylayanlar karşılaştırmaları görüntüleyip onaylayabilir/reddedebilir, ancak tedarikçi yanıtlarını düzenlememeli.
• Tedarikçiler yalnızca kendilerine gelen davetleri, mesajları ve gönderdikleri teklifleri görebilir.

Ayrıca “fiyatları görme”, “ekleri indirme” ve “yayından sonra düzenleme” gibi ince tane izinleri düşünün.

Denetim izi ve saklama

RFQ düzenlemeleri, tedarikçi teklif güncellemeleri, onaylar ve ödül kararları—ekler ve ana alan değişiklikleri dahil—için “kim neyi ne zaman yaptı” kaydı tutun. Dışa aktarma seçenekleri (CSV/PDF artı destekleyici belgeler) sağlayın ve saklama kuralları belirleyin (ör. 7 yıl tutma; hukuki inceleme durumları için bloke etme).

Backend Mimarisi ve Temel API'ler

Bir tedarikçi RFQ uygulaması güvenilir iş akışına bağlıdır: son tarihler, revizyonlar, ekler ve onaylar öngörülebilir davranmalıdır. Pratik bir backend deseni modüler monolit (tek dağıtım, net modüller) ile iş kuyruğu ve API-öncelikli bir yüzeydir—evrimleşmesi kolay, işletmesi basit.

Hızlanmak isterseniz, bir prototip oluşturma iş akışı yardımcı olabilir. Örneğin ekipler Koder.ai kullanarak RFQ iş akışını düz dilde tanımlar, çalışan bir React UI ve Go + PostgreSQL backend üretir, sonra kaynak kodunu dahili inceleme ve yineleme için dışa aktarır.

Temel API yüzeyi (sıkıcı ve tutarlı tutun)

Birkaç öngörülebilir kaynak etrafında tasarlayın, UI bileşimini yapsın.

• RFQs: POST /rfqs, GET /rfqs?status=\u0026category=\u0026from=\u0026to=, GET /rfqs/{id}, PATCH /rfqs/{id} (durum geçişleri), POST /rfqs/{id}/invite-suppliers
• Suppliers: GET /suppliers, POST /suppliers, GET /suppliers/{id}
• Quotes: POST /rfqs/{id}/quotes (tedarikçi gönderir), GET /rfqs/{id}/quotes, PATCH /quotes/{id} (revize), POST /quotes/{id}/line-items
• Files: POST /files/presign (yükleme), POST /files/{id}/attach (RFQ/teklif/mesaja ekleme)
• Messages: GET /rfqs/{id}/messages, POST /rfqs/{id}/messages
• Approvals: POST /rfqs/{id}/approvals, POST /approvals/{id}/decision (approve/reject), GET /rfqs/{id}/audit

Erken ihtiyacınız olacak arka plan işleri

Hatırlatmalar ("3 gün kaldı"), son tarih kilitlemeleri (otomatik kapanış) ve döviz kuru güncellemeleri için bir kuyruk kullanın.

Dosya depolama stratejisi

Dosyaları nesne depolamada imzalı URL'ler (kısa TTL) ile saklayın, boyut limitleri uygulayın ve yükleme sırasında zararlı yazılım taraması çalıştırın. Meta verileri (hash, dosya adı, sahibi, bağlı varlık) veritabanında tutun.

Arama ve filtreleme

En azından RFQ durumu, tedarikçi, kategori ve tarih aralıkları ile filtrelemeyi destekleyin. Önce veritabanı indeksleriyle başlayın; gereksiz kalırsanız arama motoru ekleyin.

Güvenlik ve Veri Koruma Temelleri

Güvenlik sadece hack'leri önlemek değil—doğru kişilerin doğru veriyi görmesini sağlamak ve hassas bir olay olduğunda açık bir kayıt bırakmaktır.

Kimlik doğrulama: SSO, e-posta girişi ve MFA

Kullanıcıların nasıl oturum açacağını belirleyin:

• SSO (SAML/OIDC) büyük kuruluşlardaki alıcılar için idealdir; erişimi merkezileştirir ve çalışan ayrılışında offboarding'i kolaylaştırır.
• E-posta + parola tedarikçiler ve küçük ekipler için işe yarayabilir ama güçlü korumalar gerektirir.

Her iki yaklaşımda da MFA (authenticator uygulaması veya en azından e-posta kodları) destekleyin. Parolalar sunuluyorsa açık politikalar koyun: minimum uzunluk, hız sınırlı giriş denemeleri ve yaygın ele geçirilen parolaların engellenmesi.

Veri erişim sınırları (“kim neyi görebilir” kuralı)

RFQ verisi ticari olarak hassastır. Varsayılan duruş katı izolasyon olmalıdır:

• Bir tedarikçi hesabı yalnızca davet edildiği RFQ'ları görmeli ve sadece kendi tekliflerini ve eklerini erişebilmelidir.
• Alıcı organizasyonu içinde bile erişimi rol bazında sınırlayın (talep eden vs değerlendirici vs onaylayan).

Bunu uygulamak en kolay yol, her API isteğinin hem kimlik (kim) hem de yetkilendirme (ne yapabilir) kontrol etmesidir—sadece UI'ya güvenmeyin.

Girdi doğrulama ve güvenli veri işleme

Teklif girdileri birçok kenar durumu içerir. Kenarlarda doğrulayın ve normalleştirin:

• Açık fiyat formatları (birim fiyat, indirimler, vergiler) kabul edin, para birimi kodlarını zorunlu kılın ve tutarlı ondalık hassasiyeti kullanın.
• Tüm metin alanlarını (dosya adları ve mesaj gövdeleri dâhil) enjeksiyonlara karşı temizleyin.

Yüklemeleri güvensiz kabul edin: dosyaları tarayın, boyut/tip sınırı koyun ve uygulama sunucularından ayrı depolayın.

Kayıt, izleme ve uyarılar

Denetim günlükleri seçici ve okunabilir olduğunda en değerlidir. Şunları izleyin:

• Tekrarlayan başarısız oturum açma girişimleri, MFA hataları, olağandışı konumlardan girişler
• RFQ/teklif dışa aktarımları ve toplu indirmeler
• İzin değişiklikleri ve ödül kararları

Kayıtları izleme ile eşleştirin ki şüpheli desenler hızlıca uyarı üretsin—ve günlüklerin hassas değerler (parolalar veya tam ödeme detayları) içermemesine dikkat edin.

Entegrasyonlar: ERP, E-posta, Dışa Aktarımlar ve Webhook'lar

Entegrasyonlar RFQ aracını “başka bir web sitesi” olmaktan çıkarıp satın almanın günlük işine entegre eder. Yeniden yazmayı azaltan ve onayları hızlandıran yüksek değerli bağlantılara odaklanın.

ERP ve finans sistemleri

Manuel mutabakatı azaltan akışlarla başlayın:

• Tedarikçi master senkronizasyonu: tedarikçi isimleri, ID'ler, ödeme koşulları ve durum (aktif/bloke) içe aktarın. RFQ uygulamanızdaki tedarikçi kaydını ERP tedarikçi ID'si ile bağlayın ki ödüller downstream temiz akış yapsın.
• Ödül sonrası PO oluşturma: ödül verildiğinde bir PO taslağı (veya requisition) oluşturun; ödüllü satır öğeleri, kararlaştırılmış birim fiyatlar, vergiler ve teslim detayları ile.
• Maliyet merkezleri ve muhasebe alanları: maliyet merkezlerini, GL kodlarını ve proje kodlarını senkronize edin ki talep edenler RFQ oluştururken geçerli değerleri seçebilsin.

Bunu idempotent uç noktalarla bir entegrasyon katmanı olarak tasarlayın (tekrar denemeye uygun) ve eksik eşlemeler olduğunda net hata geri bildirimi verin.

E-posta ve takvim

E-posta tedarikçiler ve onaylayanlar için varsayılan iş akışı UI'si olmaya devam eder.

Gönderilecekler:

• tedarikçi davetleri ve güvenli “RFQ'ye yanıt ver” bağlantıları
• son tarih hatırlatmaları ve açıklama istekleri
• onay istekleri, tek tıklamayla “görüntüle ve onayla” derin bağlantıları

Kullanıcılar Outlook/Google Calendar kullanıyorsa, önemli tarihler için isteğe bağlı takvim rezervasyonları oluşturun (RFQ kapanış, değerlendirme toplantısı).

Raporlama dışa aktarımları (CSV/Excel ve PDF)

Giriş yapmayan paydaşlar için dışa aktarımlar yardımcı olur.

Sağlayın:

• CSV/Excel: RFQ satır öğeleri, normalleştirilmiş teklif yanıtları ve karşılaştırma tabloları
• PDF paketleri: RFQ paketi (kapsam, şartlar, ekler) ve ödül özeti (seçilen tedarikçi, fiyatlama, gerekçe)

Dışa aktarmaların izinleri gözettiğinden ve gerekirse hassas alanları kırptığından emin olun.

Önemli olaylar için Webhook'lar

Webhook'lar diğer araçların gerçek zamanda tepki vermesini sağlar. Yayınlayın:

• quote.submitted
• approval.completed
• award.issued

İstikrarlı bir olay şeması, zaman damgaları ve kimlikler (RFQ ID, supplier ID) ekleyin. İmzalama sırları ve yeniden deneme mantığı ekleyin ki alıcılar özgünlüğü doğrulayabilsin ve geçici hataları ele alabilsin.

MVP, Pilot Planı ve Sonraki Adımlar

Bir RFQ aracı benimsenme veya başarısız olma üzerine kuruludur. Odaklanmış bir MVP hızlı yayınlamanızı, değer kanıtlamanızı ve gerçek alıcılar/tedarikçilerle iş akışını doğrulamadan gelişmiş özellikler inşa etmemenizi sağlar.

MVP kontrol listesi (ilk sürüm)

Gerçek RFQ'leri uçtan uca çalıştıracak must-have ekranlar ve kurallar:

• Alıcı ekranları: RFQ listesi, RFQ oluşturma (satırlar + ekler), tedarikçi seçimi, mesaj kaydı, teklif karşılaştırma görünümü, ödül karar özeti
• Tedarikçi portalı: davet kabulü, RFQ görüntüleme, satır bazlı teklif girişi (fiyat, teslim süresi, MOQ), ek yükleme, son tarihe kadar gönder/gönderiyi tekrar gönderme
• Temel kurallar: durum akışı (Draft → Sent/Open → Closed → Evaluated → Awarded → Archived), otomatik kapanışlı son tarihler, tedarikçi gönderimlerinde sürümleme, temel e-posta bildirimleri (davet, hatırlatma, ödül)
• Veri gereklilikleri: çoklu para birimi yakalama (henüz dönüştürmeseniz bile), birim ölçü alanı ve karşılaştırmayı sağlamak için net bir “aynı ürün” tanımlayıcısı
• Uyumluluk temelleri: rol tabanlı erişim (alıcı vs onaylayan vs yönetici) ve ana işlemler için değiştirilemez etkinlik günlüğü

Hızlı yineleme için ilk çalışan versiyonu Koder.ai ile üretmeyi, sonra kaynak kodunu dışa aktarıp paydaşlarla inceleyerek üretime götürmeyi düşünebilirsiniz.

Pilot dağıtım planı

Bir kategoriyle (örn. ambalaj) ve birkaç işbirlikçi tedarikçiyle başlayın.

Kısa döngüler çalıştırın: haftada 1–2 RFQ, ardından kullanıcılarla 30 dakikalık bir inceleme. Sürtünme noktalarını (eksik alanlar, kafa karıştıran durumlar, tedarikçi katılımının düşmesi) yakalayın ve genişletmeden önce düzeltin.

İzlenecek KPI'lar

Etkisini küçük bir metrik setiyle ölçün:

• RFQ çevrim süresi (taslaktan ödüle)
• Tedarikçi yanıt oranı ve zamanında gönderimler
• Tasarruf görünürlüğü (en iyi teklif vs ödüllü, eşdeğer karşılaştırma)
• Uyumluluk (araç içinde yürütülen RFQ'ler vs platform dışında)

Sonraki inşa adımları

MVP stabil olduktan sonra öncelik verin:

• Tedarikçi performans geçmişi (zamanında teslim, kalite, yanıt hızı)
• Sözleşme bağlantısı (tercih edilen tedarikçiler, fiyat listeleri, yenileme uyarıları)
• Gelişmiş raporlama ve dışa aktarma paketleri

Güncelleme ve paketleme planlarken, /pricing gibi basit “sonraki adımlar” sayfaları ve /blog altında birkaç eğitim rehberi ekleyin.