Bir teklifin hatası bazen sipariş alındıktan sonra ortaya çıkar. Fiyata dâhil edilmemiş bir test, yanlış yorumlanmış bir teknik koşul ya da tedarikçiden teyit alınmadan verilmiş bir teslim tarihi, kazanılmış görünen işi zarara çevirebilir. Oysa sorun çoğu zaman üretimde başlamamıştır. Teklif hazırlanırken bir bilgi eksik kalmış, bir varsayım sorgulanmamış veya bir değişiklik ilgili ekibe ulaşmamıştır.
RFQ yönetimi tam da bu nedenle satışın, mühendisliğin, satın almanın, üretimin ve finansın birlikte yürüttüğü bir iştir. Müşterinin ne istediğini anlamak, şirketin bunu hangi koşullarda karşılayabileceğini belirlemek ve fiyatı bu koşullara göre oluşturmak gerekir. Hazırlanan teklif, bütün bu değerlendirmenin müşteriye sunulan sonucudur.
Yapay zekânın bu süreçte değer yaratabileceği geniş bir alan var. Ancak bunun için talebin gelişinden teklifin gönderilmesine kadar hangi kararların verildiğini, bu kararların hangi verilere dayandığını ve kim tarafından onaylandığını anlamak gerekiyor.
RFQ yönetiminin kapsamı
RFQ, “Request for Quotation”, yani teklif talebi anlamına gelir. Satın alan şirket, belirli ürün veya hizmetler için tedarikçilerinden fiyat ve koşul ister. SAP’nin RFQ tanımı da mal veya hizmet tedariği için tedarikçiye yapılan bu çağrıyı esas alır.
Bu yazıda konuyu, talebi alan ve müşteriye teklif hazırlayan şirket açısından ele alıyoruz. Böyle bir şirketin RFQ süreci; gelen talebi kaydetmeyi, teklif verip vermeyeceğine karar vermeyi, teknik ve ticari koşulları değerlendirmeyi, gerekli onayları almayı ve teklif revizyonlarını takip etmeyi kapsar.
İşin kapsamı ürüne göre değişir. Standart bir yedek parça için güncel fiyat ve stok kontrolü yeterli olabilir. Müşteriye özel bir makine, ekipman paketi veya mühendislik işi ise çizim incelemesi, maliyet çalışması ve tedarikçi görüşmeleri gerektirebilir. Bu yüzden bütün talepleri aynı inceleme ve onay sürecinden geçirmek yerine, kapsamlarına göre ayırmak daha anlamlıdır.
Talep geldiğinde önce sorumluluk ve kapsam belirlenmeli
E-posta, müşteri portalı veya satış temsilcisi üzerinden gelen taleplerin ortak bir kayda alınması, işin takip edilebilmesi için ilk adımdır. Müşteri, proje, teklif numarası, yanıt tarihi, teslimat beklentisi ve ilgili belgeler bu kayıtta bulunmalıdır. Teklif hazırlığını kimin yürüteceği de baştan belli olmalıdır.
Burada iki tarih kolayca birbirine karışabilir: müşterinin teklifi beklediği tarih ve ürünü istediği tarih. İlki teklif ekibinin çalışma takvimini, ikincisi tedarik ve üretim planını belirler. Müşteriye verilecek yanıtı hazırlarken ikisini de ayrı takip etmek gerekir.
Kaydın açılmasıyla birlikte ilk değerlendirme yapılabilir. Talep şirketin ürün ve hizmet kapsamına uyuyor mu? Mevcut kapasiteyle karşılanabilir mi? Gerekli sertifikalar veya teknik yetkinlikler var mı? Teklif hazırlamak için ne kadar mühendislik çalışması gerekiyor? Eldeki bilgiler fiyat vermeye yeterli mi?
Bu soruların ardından talep doğrudan teklif çalışmasına alınabilir, eksik bilgi için müşteriye dönülebilir veya teklif vermeme kararı alınabilir. Böylece ekip, sonucu belirsiz her talebe aynı zamanı ayırmak zorunda kalmaz. Teklif vermeme gerekçesini kaydetmek de hangi fırsatların kapasite, fiyat veya teknik kapsam nedeniyle elendiğini görmeye yardımcı olur.
Şartnameyi okumak kadar belge sürümünü takip etmek de önemli
Bir RFQ dosyası, tek bir şartnameden ibaret olmayabilir. Teknik çizimler, malzeme listeleri, kalite koşulları, müşteri standartları ve e-posta açıklamaları birlikte değerlendirilir. Üstelik teklif hazırlanırken bunların yeni sürümleri gelebilir.
Bu nedenle her gereksinimin hangi belgeden ve hangi revizyondan geldiği bilinmelidir. Sayfa veya madde numarası da kayda eklendiğinde mühendislik ekibi, çıkarılan bilgiyi kaynağından kontrol edebilir. Bir müşteri açıklaması önceki koşulu değiştiriyorsa bu değişiklik ilgili gereksinime işlenmelidir.
Örneğin ilk çizimdeki malzeme daha sonraki bir e-postada değiştirilmiş olsun. Maliyet hesabı eski çizime, teknik teklif yeni e-postaya dayanıyorsa aynı teklifin iki bölümü birbirini tutmaz. Belge sürümlerini takip etmek, bu tür tutarsızlıkların önüne geçmek için gereklidir.
Belgeler birbiriyle çeliştiğinde de hangi koşulun geçerli olduğu varsayımla belirlenmemeli. Açıklama gerektiren konu müşteriye sorulmalı; yanıt gelene kadar teklifin hangi bölümünü etkilediği görülmelidir. Açık sorunun bir sorumlusu ve beklenen yanıt tarihi olduğunda, teklifin neden beklediği anlaşılır.
Teknik uygunluk, her gereksinime verilen yanıtla anlaşılır
Ürün adının veya birkaç katalog değerinin eşleşmesi, bütün şartnamenin karşılandığını göstermez. Malzeme, çalışma koşulları, ölçüler, testler, belgeler ve bakım beklentileri ayrı ayrı incelenmelidir.
Teknik uygunluk tablosu bu incelemeyi düzenler. Her satırda müşteri gereksinimi, önerilen çözüm, uygunluk durumu ve dayanak belge yer alır. Karşılanmayan koşullar, müşteriden açıklama bekleyen maddeler ve onay gerektiren alternatifler de açıkça belirtilir.
Basit bir örnek düşünelim: Müşteri IP66 motor istiyor, standart ürün ise IP55 motorla geliyor. Uygun bir alternatif bulunduğunda bunun ürünle kullanılabileceğini doğrulamak gerekir. Ardından yeni motorun maliyete, tedarik süresine ve üretim planına etkisi incelenir. Tek bir teknik koşul, teklifin birkaç bölümünü birden değiştirebilir.
Müşterinin istediği çözüm karşılanamıyorsa önerilen farklılık teknik teklifte açıkça yazılmalıdır. Şirket içinde kabul edilmiş bir alternatifin müşteri tarafından da kabul edildiğini varsaymak, sipariş sonrasında anlaşmazlığa yol açabilir.
Maliyet çalışması, teklifin kapsamıyla birlikte yapılmalı
Doğru fiyat için önce nelerin fiyata dâhil olduğunu bilmek gerekir. Ana ürünün yanında özel bileşenler, mühendislik çalışması, takım ve kalıp, test, sertifika, paketleme, nakliye, kurulum ve devreye alma gibi kalemler de maliyet doğurabilir. Hangilerinin hesaba katılacağı, işin kapsamına bağlıdır.
Bu nedenle maliyet çalışması ile teknik kapsam aynı bilgiler üzerinden ilerlemeli. Şartnameye eklenen bir kabul testi veya dokümantasyon talebi, fiyatlandırmaya da yansımalıdır. Kapsam dışında bırakılan işler ise müşterinin anlayacağı şekilde belirtilmelidir.
Satın alınacak parçalar için fiyatın tarihi, para birimi, geçerlilik süresi, asgari sipariş miktarı ve teslim koşulları önem taşır. Geçen yıl alınmış bir tedarikçi fiyatını güncel kabul etmek ya da toplu alım fiyatını küçük bir siparişe uygulamak, maliyeti olduğundan düşük gösterebilir.
Satış fiyatı belirlenirken iskonto yetkileri, hedef marj ve ödeme koşulları birlikte değerlendirilir. Özellikle uzun vadeli veya aşamalı ödemelerde finansman ihtiyacı da ticari değerlendirmeye girer. Maliyet kesinleşmemişse hangi tutarın tahmin olduğu ve hangi varsayımla kullanıldığı, onay veren kişi tarafından görülebilmelidir.
Termin, tedarik ve kapasite birlikte değerlendirilerek verilir
Müşterinin istediği tarih, planlamanın başlangıç bilgisidir. O tarihte teslimat yapılıp yapılamayacağını görmek için malzeme bulunabilirliği, tedarik süresi, üretim kapasitesi, dış işlemler, test ve lojistik birlikte değerlendirilmelidir.
Stok kontrolünde de fiziksel miktarla kullanılabilir miktarı ayırmak gerekir. Depoda görünen bir parça başka bir siparişe ayrılmış veya kalite kontrolünde bekliyor olabilir. Teklifte kullanılacak stok bilgisinin bu durumu yansıtması gerekir.
Tedarikçi süresi tek başına yeterli değildir. Sürenin siparişten mi, avans ödemesinden mi yoksa teknik çizim onayından mı başladığı bilinmelidir. Aynı şekilde, tedarikçinin bildirdiği tarihin kendi fabrikasından çıkışı mı yoksa sizin fabrikanıza varışı mı ifade ettiği net olmalıdır.
Üretimde bazı işler paralel yürür, bazıları ise bir öncekinin tamamlanmasını bekler. Bu nedenle bütün süreleri art arda toplamak her zaman doğru sonuç vermez. Sevk tarihini belirleyen iş sırası, kapasite durumu ve takvim planlama hesabına dâhil edilmelidir.
Böylece müşteriye sunulan tarih, kontrol edilmiş koşullara dayanır. Henüz malzeme veya kapasite ayrılmadıysa bunun da bilinmesi gerekir; teklif hazırlarken öngörülen bir tarih ile sipariş için teyit edilmiş tarih aynı kesinlikte değildir.
Onay süreci, alınan kararın sorumlusuna ulaşmalı
Teklif onayı yalnızca toplam fiyatın kabulüyle sınırlı tutulmamalı. Mühendislik teknik farklılıkları, planlama sevk tarihini, finans ticari koşulları, satış yönetimi ise fiyat ve iskonto kararını kendi yetkileri içinde değerlendirebilir.
Her teklifin bütün yöneticileri dolaşması da gerekmez. Standart koşullara uyan işler daha kısa bir yoldan ilerleyebilir. Düşük marj, alışılmadık ödeme koşulu, karşılanamayan teknik madde veya kapasite sorunu varsa ilgili sorumlunun onayı istenir.
Bu ayrım, onay bekleyen kişinin önüne anlamlı bir karar getirir. Kişi hangi koşul nedeniyle kendisine başvurulduğunu, önerilen çözümü ve bunun işe etkisini görür. Ürün seçimi, fiyatlandırma ve onayların bağlantılı ele alınması, Oracle’ın CPQ kapsam tanımında da yer alır.
Onay sonrasında teklif değişirse önceki onayın hangi koşullar için verildiği korunmalıdır. Örneğin müşteri miktarı yarıya indirdiğinde birim maliyet ve marj değişebilir. Bu durumda eski fiyat onayını yeni teklif için geçerli saymadan önce etkilenen hesapları yeniden kontrol etmek gerekir.
Teklif gönderildikten sonra iş devam eder
Müşteriye gönderilen teklifin sürümü, gönderim tarihi, geçerlilik süresi ve ekleri kayıt altında tutulmalıdır. Sonraki görüşmelerde hangi teklif üzerinden konuşulduğu ancak böyle netleşir.
Müşteri kapsamı daraltabilir, miktarı değiştirebilir veya alternatif ürün isteyebilir. Bu değişiklikler yeni bir teklif sürümünde takip edilmeli. Önceki fiyatın neden değiştiği ve hangi koşulların aynı kaldığı hem satış ekibi hem de müşteri için anlaşılır olmalıdır.
Sipariş geldiğinde son bir karşılaştırma gerekir. Siparişteki ürün, miktar, fiyat, teslim tarihi ve diğer koşullar, onaylı teklifle örtüşüyor mu? Müşteri farklı bir çizim revizyonuna atıf yapmış mı? Teklifte kapsam dışı bırakılan bir işi siparişe eklemiş mi?
Bu kontrolün ardından teknik kapsam, kabul edilmiş farklılıklar, belgeler ve teslimat koşulları işi gerçekleştirecek ekibe aktarılabilir. Böylece üretim veya proje ekibi, satış sırasında verilen sözleri sonradan öğrenmek zorunda kalmaz.
Yapay zekâ nerede zaman kazandırabilir?
RFQ sürecinde yapay zekâ için uygun işler; e-posta ve belgelerden bilgi çıkarmak, gereksinimleri düzenlemek, ilgili ürün kayıtlarını bulmak, revizyonlar arasındaki farkları işaretlemek ve teklif taslağı hazırlamaktır. Uzun bir yazışmada açık kalan soruları derlemek veya eksik belgeleri belirlemek de bu kapsama girer.
Ancak belgeyi okuyan sistemin çıkardığı bilgiler doğrulanabilir olmalıdır. Örneğin bir ölçünün birimi, bir şartın istisnası veya çizimdeki bir not yanlış yorumlanabilir. Kaynak belgeye bağlantı ve uzman incelemesi, bu nedenle tasarımın parçası olmalıdır.
Fiyat, vergi, marj ve takvim hesapları ise tanımlı kurallarla çalışan hesaplama araçlarına bırakılmalıdır. Yapay zekâ bu hesaplar için gerekli bilgileri hazırlayabilir; sonuçlar güncel veriler ve şirketin kuralları üzerinden üretilmelidir. Belirsiz bir maliyet veya eksik tedarik süresi, kesin bilgi gibi kullanılmamalıdır.
Yetkiler de işin kapsamına göre tanımlanır. Stok okumak, tedarikçiye fiyat sormak, sipariş açmak ve müşteriye teklif göndermek farklı işlemlerdir. Özellikle dışarıya verilen fiyat ve tarihlerin hangi koşullarda insan onayı gerektirdiği baştan belirlenmelidir.
PromptRails ile RFQ yönetimini ele alırken başlangıç noktası bu iş bölümüdür: yapay zekânın hazırlayacağı bilgiler, şirket sistemlerinden alınacak veriler, hesap kuralları ve uzmanların vereceği kararlar. Uygulamanın kapsamı da bu ayrım üzerinden kurulmalıdır.
Başarıyı teklif hızıyla birlikte doğruluk ve kârlılıkla ölçmek
İlk uygulama için belirli bir ürün ailesi veya talep türü seçilebilir. Bu kapsamdaki geçmiş işlerden yararlanarak tekliflerin nerede beklediği, hangi bilgilerin eksik geldiği ve hangi hataların tekrarlandığı incelenir. Ardından aynı tür işler üzerinde yeni sürecin etkisi ölçülebilir.
İzlenebilecek göstergeler şunlardır:
- Talebin alınmasından müşteriye teklif gönderilmesine kadar geçen süre.
- Çalışma süresi ile müşteri, tedarikçi veya iç onay bekleme süreleri.
- Eksik kapsam, yanlış ürün veya hesap hatası nedeniyle yapılan düzeltmeler.
- Zamanında yanıtlanan talepler ve ilk incelemede onaylanan teklifler.
- Teklifte öngörülen maliyet ile sipariş sonrasında oluşan maliyet arasındaki fark.
- Teklifte verilen tarihle gerçekleşen sevk tarihi arasındaki fark.
- Teklifin kazanılma veya kaybedilme nedeni.
İyi yönetilen bir RFQ sürecinde satış ekibi müşteriye hangi ürünü, hangi kapsamda, hangi fiyatla ve hangi tarihte sunabileceğini bilir. Mühendislik, satın alma ve üretim de bu teklifin arkasındaki koşullara ulaşabilir. Yapay zekâdan beklenen katkı, bilgi toplama ve hazırlama yükünü azaltarak bu ortak değerlendirmeyi hızlandırmaktır.
Kendi sürecinizi değerlendirirken yakın zamanda tamamlanmış bir teklifi baştan sona takip edin. Hangi karar için hangi bilgi beklendiğini, kimin onay verdiğini ve sonradan nelerin değiştiğini çıkarın. İlk iyileştirme alanı, çoğu zaman bu incelemede belirginleşir.