Bir tedarikçi puan kartı uygulamasının zamanında teslimat, kusurlar ve maliyet değişikliklerini nasıl takip edip otomatik olarak bir QBR sayfası oluşturduğunu öğrenin.
Tedarikçi incelemeleri genellikle iyi niyetle başlar, sonra bir yığın elektronik tablo, e-posta zinciri ve “en son sürüm” karışıklığına kayar. Bir kişi zamanında teslimatı takip eder, başka biri kusurları ayrı bir dosyada kaydeder ve finans maliyet değişikliklerini kendi çalışma kitabında tutar. Çeyrek bittiğinde toplantı, ne yapılacağına karar vermek yerine kimin sayısının doğru olduğu tartışmasına dönüşür.
Elektronik tablolar kolayca düzenlenir ama kontrol etmek zordur. Bir kopyala-yapıştır hatası bir skoru değiştirebilir. Açık bırakılmış bir filtre satırları gizleyebilir. İnsanlar sütun adlarını değiştirir, “geçici” notlar ekler ve bir metriğin tanımı çeyreğin ortasında sessizce değişir. Net bir iz olmadan, bir tedarikçinin puanının neden hareket ettiğini açıklamak veya sonraki kararları savunmak zordur.
Çeyreklik incelemeler ayrıca metrikler tutarlı olmadığında raydan çıkar. Bir çeyrekte “gönderi tarihi” kullanılıp diğerinde “varış tarihi” kullanılırsa, trendler artık bir anlam ifade etmez. Kusurlar bir ekip tarafından “açılan ticketlar” olarak sayılırken başka bir ekip tarafından “onaylanmış kök neden” olarak sayılırsa, tedarikçi puana itiraz eder ve ekibinizin net bir yanıtı olmaz.
Bu incelemeler genellikle farklı önceliklere sahip birden çok paydaşı içerir. Satın alma fiyatları, şartları ve riskleri önemser. Operasyonlar zamanında teslimat ve lead time ile ilgilenir. Kalite kusurlar, iade ve düzeltici aksiyonlara odaklanır. Finans maliyet değişikliklerini, kredi ve tahmin etkisini izler.
"İyi" basit görünür: her çeyrekte aynı tanımlarla tekrar edilebilir bir süreç, kaynak kaydına kadar izlenebilen sayılar ve herkesin beş dakikada okuyabileceği bir çeyreklik iş incelemesi (QBR) sayfası. Bir tedarikçi puan kartı uygulaması tek bir paylaşılan veri kümesini tuttuğunda, metrik tanımlarını kilitlediğinde ve çeyreklik görünümü otomatik oluşturduğunda yardımcı olur; böylece konuşma performans ve kararlara odaklanır.
Bir çeyreklik inceleme, herkes neyin “iyi” olduğunu kabul ettiğinde işe yarar. Bir şey inşa etmeden önce toplantıda savunabileceğiniz en küçük ölçümler kümesini tanımlayın. 20 şey takip etmeye başlarsanız, hiçbirini sürdüremezsiniz.
Tedarikçi listenizle başlayın. Her tedarikçiye, tedarikçi adı değişse bile asla değişmeyen benzersiz bir tedarikçi kimliği verin (örneğin, "ACME Manufacturing" vs "ACME Mfg"). Bu tek karar çoğaltmaları önler ve her seferinde doğru geçmişi çekmeyi kolaylaştırır.
Çoğu ekip için sağlam bir asgari set zamanında teslimat (OTD), kusur oranı (iade, RMA veya muayene başarısızlıkları) ve maliyet değişiklikleridir (fiyat artışları, hızlandırma ücretleri, krediler). Hacim isteğe bağlıdır ama bağlam sağlar.
Sonra inceleme dönemi kurallarınızı kilitleyin. Çeyrek sınırlarını tanımlayın (takvim çeyrekleri veya mali takvim), zaman damgaları için kullandığınız saat dilimini ve kesme kuralını. Örneğin: "Çeyreğin son gününde yerel depo saatine göre 23:59'dan sonra teslim edilen gönderimler bir sonraki çeyreğe dahil edilir." Bu tür küçük ayrıntılar sonraki tartışmaları önler.
Ardından her metriğin sahipliğini ve gerçek kaynağını belirleyin. Bir puan kartı yalnızca her sayının net bir sahibinin ve açık bir kaynağının olduğu zaman güvenilir olur.
Örnek: OTD teslim alma zaman damgalarından geliyorsa ama Lojistik sevk tarihlerini raporluyorsa, yine de OTD'yi takip edebilirsiniz. Yapmanız gereken tek şey bir tanım seçmektir (teslim tarihi veya teslim alma tarihi) ve her tedarikçi, her çeyrek için buna bağlı kalmaktır.
Bir puan kartı, herkes aynı şeyi ölçtüğünü düşünse de aslında farklı şeyler ölçüyorsa başarısız olur. Bir tedarikçi puan kartı uygulaması kurmadan önce, her metriği yeni işe giren birinin soru sormadan izleyebileceği bir kural gibi yazın.
Zamanında teslimatla başlayın. "Zamanında" net bir kesme gerektirir (PO'daki vaat edilen tarih, rıhtım zaman damgası veya taşıyıcı teslimat kanıtı). Ayrıca kısmi sevkiyatların nasıl sayılacağına karar verin. Bir PO iki kısımda gönderilirse, son kutu geldiğinde mi zamanında sayılır yoksa her satır öğesi ayrı mı puanlanır? Bir yaklaşımı seçin ve ona bağlı kalın.
Kusurlar tartışması daha kolay alevlenir, bu yüzden payda ve payda tabanını kilitleyin. Kusurlar iade edilen birimler, başarısız muayeneler, açılan RMA'lar veya reddedilen partiler olarak mı sayılıyor? Ve payda olarak alınan birimler, alınan partiler veya toplam gönderimler mi kullanılıyor? "Kusur oranı" yalnızca herkes aynı tabanı kullandığında anlam taşır.
Maliyet değişiklikleri basit bir karşılaştırma gibi okunmalıdır. Temelinizi tanımlayın (sözleşme fiyatı, geçen çeyrek ortalaması veya pazarlıklı bir endeks). Sonra bir değişikliğin ne zaman yürürlüğe girdiğini belirleyin: fatura tarihi, sevkiyat tarihi veya tedarikçinin bildirim tarihi. Etkin tarih yoksa, bir çeyreğin neden kağıt üzerinde kötü göründüğünü açıklayamazsınız.
Tartışmaları önlemek için her metriğin temelini yakalayın: tam kaynak (PO, fatura, muayene kaydı) ile bir cümlelik tanım, sayım kuralları (kısmi ve krediler dahil), çeyrek atama için etkin tarih kuralı, istisnalar için net bir sahip ve kanıtla kısa bağlam notları.
Örnek: Bir sevkiyat depo kapanışı nedeniyle bir gün geç geldiyse, geç olarak kaydedin. Kapanış bildirimini ekleyin ve düzeltici aksiyon sahibi atayın. Skor tutarlı kalır ve QBR konuşması adil olur.
Bir tedarikçi puan kartı uygulaması veri modeline bağlıdır. Tablolarınız gerçek olayları yansıtıyorsa, raporlama basit bir sorgu olur, aylık temizlik projesi değil.
Zaten uğraştığınız küçük bir çekirdek kayıt setiyle başlayın: Tedarikçiler, PO'lar veya Sevkiyatlar, Muayeneler veya Kusurlar, Fiyat Değişiklikleri ve İnceleme Dönemleri.
Ham olayları çeyreklik özetlerden ayrı tutun.
Bu ayrım, geç gelen veri gelince geçmişi yeniden yazmadan yeniden hesaplama yapmanıza izin verir.
Kanıtı saklayın, sadece skoru değil. Her olay için bir QBR toplantısında sayıyı savunmak için ihtiyaç duyacağınız şeyleri yakalayın: tarihler, miktarlar, parça numaraları ve bir belge referansı (fatura numarası, teslim alma raporu ID'si, muayene kaydı ID'si). Birisi "Hangi sevkiyat gecikti?" diye sorduğunda, dosyaları karıştırmadan cevap verebilmelisiniz.
Son olarak, manuel düzeltmeler için plan yapın çünkü gerçek dünya karmaşıktır. Ham değerleri üzerine yazmak yerine, kim değiştirdi, ne zaman, neden ve orijinal değer ile birlikte bir ayarlama kaydedin. Bir sevkiyat depo kapanışı nedeniyle hariç tutulduysa, neden görünür kalmalıdır.
En iyi tedarikçi puan kartı uygulaması zaten sahip olduğunuz verileri ödünç alandır. Her metriğin zaten nerede yaşadığını listeleyerek başlayın. Zamanında teslimat bir ERP dışa aktarımında veya depo teslim alma kaydında olabilir. Kusurlar bir kalite sisteminde veya iade notlarında olabilir. Maliyet değişiklikleri genellikle faturalar, fiyat listeleri veya kredi notlarında görünür.
Her kaynak için değişme sıklığına ve sahibine göre bir güncelleme yöntemi seçin. Zamanlanmış içe aktarmalar tekrarlayan dosyalar için iyi çalışır (haftalık ERP dışa aktarımları, günlük depo günlükleri). Manuel yüklemeler aylık olarak aldığınız finans tabloları için uygundur. Küçük ekiplerde basit form girişi istisnaları kaydetmek için yeterlidir. API çekimleri yalnızca kaynak sistem destekliyorsa ve stabil kalabileceğini düşünüyorsanız anlamlıdır.
Başta biraz doğrulama saatler kazandırır. Kuralları basit ve görünür tutun, bir şey yanlışsa hızlıca başarısız olsun. Bir teslimat tarihi zorunlu kılın, negatif miktarları engelleyin, yinelenen fatura numaralarını işaretleyin ve kusur sayısı alınan birimlerden yüksekse uyarı verin.
Geç veri olur, özellikle kusurlar ve krediler için. Geçmişi sessizce yeniden hesaplamayın. Orijinal kayıt tarihini ve raporladığınız çeyreği saklayın, sonra bir politika seçin: geçmiş çeyrekleri imzalamanın ardından kilitleyin ya da açık bir değişiklik günlüğü ile düzeltmelere izin verin. Yaygın bir yaklaşım "puanı dondur, notlara izin ver": QBR sayfası onaylanmış skoru tutar ve düzeltmeler bir sonraki çeyreğe ayar olarak gelir.
Otomasyon ancak kurallar net ve girdiler tutarlı olduğunda çalışır. Çeyrek bittikten sonra tedarikçi puan kartı uygulamanız aynı sayıları her seferinde üretmelidir, birinin formülleri tekrar kontrol etmesine gerek kalmadan.
Çeyrek kaydını oluşturun ve tarihleri kilitleyin. "Q1 2026" gibi bir giriş ekleyin ve başlangıç ile bitiş tarihlerini belirleyin. İncelemeler başladıktan sonra aralığı kilitleyin ki geç düzenlemeler sonuçları değiştirmesin.
Sevkiyatlardan zamanında teslimatı hesaplayın. O tarih aralığındaki tüm sevkiyatları çekin. Vaat edilen tarih ile alınma tarihini karşılaştırın. Hem zamanında yüzdeyi hem de ham sayımları kaydedin.
Kusur olaylarından kusur oranını hesaplayın. Aynı çeyrekte o tedarikçiye bağlı kusur olaylarını çekin. Tek bir tanım seçin (örneğin, 1.000 birim başına kusur veya kusur içeren gönderimlerin yüzdesi). Oranı ve toplam kusur sayısını saklayın.
Temelle karşılaştırmalı maliyet değişikliklerini özetleyin. Temel fiyatınızı (sözleşme listesi veya geçen çeyrek ortalaması) çeyrekteki fiili fatura satır fiyatlarıyla karşılaştırın. Ortalama yüzde değişimi ve fiyatı değişen öğe sayısını kaydedin.
Genel skoru hesaplayın ve kaydedin. Her metriği 0–100 aralığına çevirin, ağırlıklar uygulayın (örneğin, teslimat %50, kalite %30, maliyet %20) ve son skoru ile kullanılan ağırlıkları saklayın.
Bu değerler her çeyrek için saklandığında, QBR sayfalarını hızlıca üretebilir ve her skoru altındaki kayıtlarla açıklayabilirsiniz.
İyi bir QBR sayfası slayt destesini her çeyrek yeniden yapan bir yapı gibi değil, bir gösterge panosu gibi hissettirmelidir. Her tedarikçi için her çeyrekte tek sayfa tutun, her seferinde aynı düzenle. Tutarlılık insanların hızlıca taramasını, karşılaştırmasını ve karar vermesini sağlar.
Baştaki KPI'ları koyun ki hikâye 10 saniyede anlaşılabilsin: zamanında teslimat yüzdesi, kusur oranı, maliyet değişim yüzdesi ve genel skor. Her sayının altında "geçen çeyreğe göre" ve "yıl başından beri" gibi basit karşılaştırmalar gösterin ki tek seferlik bir sapma mı yoksa gerçek bir trend mi olduğu anlaşılsın.
KPI'ların altında sayıları açıklayan görünümler olsun. Bir bölüm aylık dağılımı (veya sevkiş başına) gösterebilir, başka bir bölüm skoru etkileyen sorunları listeleyebilir. Tabloları kısa tutun ve ham olayları hesaplanan sonuçlarla aynı görünümde karıştırmaktan kaçının.
Sayfanın kendiliğinden güncellenmesi için, el ile düzenlemeler yerine kaydedilmiş sorgular veya hesaplanan alanlardan oluşturun. Sayfa Vendor ve Quarter ile filtrelenmeli, saklanmış çeyreklik sonuçları çekmeli ve her seferinde aynı mantığı kullanmalıdır.
Eylemler blokuyla bitirin; çünkü skorsuz eylem sadece süs olur. Bir sahip, son tarih, durum ve kısa bir not ekleyin. Örnek: "Parça A'daki kusurları azalt: QA lideri, 15 Şub, devam ediyor, yeni muayene adımını bir sonraki çeyrekte doğrula."
Bir tedarikçi puan kartı ancak insanlar ona güvendiğinde yardımcı olur. Çoğu puan kartı basit nedenlerle başarısız olur: girdiler dağınıktır veya kurallar sessizce değişir.
Yaygın bir sorun metriğin çeyrek ortasında değiştirilmesidir. "Zamanında" "istenen tarihe yetişme"den "onaylanmış tarihe yetişme"ye geçerse, trend çizgisi gürültüye dönüşür. Tanım sürümlerini takip edin ve değişiklikleri yalnızca bir sonraki çeyrekten itibaren uygulayın (veya her iki sürümü yan yana saklayın).
Başka bir tuzak kusur oranı hesaplanırken birimlerin karıştırılmasıdır. Tedarikçi lot, kutu veya metre ile gönderiyorsa, ne ile bölündüğüne göre daha iyi veya daha kötü görünebilir. Kusurları 1.000 birim başına takip ediyorsanız, "birim"in her zaman aynı şeyi ifade ettiğinden emin olun ve sevkiyatla birlikte birim türünü saklayın.
Tarihler güveni hızla bozabilir. İptal edilen PO'lar ve yeniden planlanan teslim tarihlerinin çoğu zaman orijinal vaat edilen tarih çekildiğinde gecikmiş sayılmasına yol açar. Hangi tarihler geçerli sayılacak (talep edilen, onaylanan, revize edilen) kararını verin ve iptal edilen satırları gecikme mantığından hariç tutun.
Manuel düzenlemeler de risklidir. Birisi raporu düzeltmek için teslim tarihini üzerine yazarsa, ham gerçeği ve değişikliğin nedenini kaybedersiniz. Ham veriyi tutun ve düzeltmeleri ayrı kaydederek kim neyi neden değiştirdiğini görünür kılın.
Bir tedarikçi 82 aldıysa, inceleyenler buna yol açan zamanında yüzdesini, sevkiyat sayısını, kusur sayısını ve maliyet değişimini görebilmelidir. Eğer göremezlerse, skor başka bir tartışma kaynağı olur.
Bir QBR sayfasını paylaşmadan önce hızlı bir güven kontrolü yapın. Sayılar yanlış görünüyorsa, toplantı veride takılıp kararlar kaçırılır.
Tarihlerle başlayın. Geç teslimatı ölçmek için her sevkiyat satırının hem bir zorunlu tarihi hem de bir alınma tarihi (veya "henüz alınmadı" durumu) olmalıdır. Bunlardan biri eksikse sahte mükemmel performans veya haksız cezalar ortaya çıkabilir.
Sonra kalite ve maliyetin aynı çeyrekte karşılaştırılabilir olduğundan emin olun. Paydasız kusurlar ve etkin tarih olmayan fiyat değişiklikleri güveni hızla zedeler.
En yaygın problemleri yakalamak için kısa kontrol listesi:
Pratik bir test: bir tedarikçiyi açın, bir sevkiyat seçin ve onu ham kayıttan nihai KPI'ya kadar izleyin. Eğer bu yol net ve tekrarlanabilir ise, çeyreklik incelemeniz sayılar rahatsız edici olsa bile dayanır.
Tedarikçi A kritik bir plastik muhafaza sağlar. Geçen çeyrekte alt tedarikçi sorunu nedeniyle reçineyi değiştirdiler. Tedarikçi puan kartı uygulamanız üç sinyal çeker: zamanında teslimat, kusur oranı ve maliyet değişiklikleri.
Q3'te sayılar şöyle görünüyor:
QBR sayfası hikâyeyi tek bir görünümde açıkça gösterir. OTD yeşil, ama kusurlar 5. haftadan itibaren (parça değişikliğinin değişiklik günlüğündeki notundan hemen sonra) yükseliyor. Fiyat artışı, kaliteye denk bir iyileşme olmadan gerçekleştiği için işaretlenir.
Liderlik net bir özet görür: teslimat performansı düzelmiş ama kalite riski ve maliyet yükselmiş. Operasyon ve kalite daha pratik bir şeye ihtiyaç duyar. Sayfa eylemleri doğrudan metriklere bağlar: bir düzeltici plan (8D) son tarihli, gelecek üç alım için gelen muayene değişikliği ve kalite hedefine dönülüp dönülmemesine bağlı fiyat takibi.
Bir puan kartı yalnızca insanlar ona güvendiğinde çalışır. Küçük başlayın, tanımları kilitleyin ve her tedarikçi için sayılar gerçeğe uyduğunu kanıtlayana kadar genişletmeyin.
5–10 tedarikçi ve bir tamamlanmış çeyrek ile pilot başlatın. Gerçek faturalar, PO'lar, teslim notları ve QA günlükleri kullanın. Amaç mükemmel olmak değil; amaç eksik tarihler, belirsiz kusur kuralları ve tartışmalı maliyet değişiklikleri gibi sorunlu kenarları küçük kapsamla bulmaktır.
Pratik bir yayılma planı:
Pilot sonrası, tutarlılığa odaklanarak iyileştirmeler yapın: istisnaları baştan ele alın, metrik tanımlarını çeyrek bazında versionlayın, skorları değiştirmeden sayıların yanına yorum ekleyin ve kısa bir denetim izi tutun.
Ağır mühendislik olmadan bunu inşa etmek isterseniz, AppMaster (appmaster.io) pratik bir seçenek olabilir: tedarikçileri ve çeyreklik sonuçları PostgreSQL'de modelleyebilir, puanlama mantığını görsel olarak oluşturabilir ve aynı veriden web QBR sayfası üretebilirsiniz ki çeyrekten çeyreğe tutarlı kalsın.
Çeyreklik tedarikçi puan kartı için başlamak üzere en iyi metrikler nelerdir?Toplantıda savunabileceğiniz küçük bir çekirdek küme ile başlayın: zamanında teslimat, kusur oranı ve maliyet değişiklikleri. Hikâyeyi açıklamaya yardımcı olması durumunda hacmi ekleyin. Bir metrik bir dakikada nasıl hesaplandığını açıklayamıyorsanız, çeyreklik rutine muhtemelen çok karmaşıktır.
İsimler değiştiğinde veya farklı yazıldığında nasıl yinelenen tedarikçilerden kaçınırım?Tedarikçi adı değişse veya farklı yazılsa bile asla değişmeyen benzersiz bir tedarikçi kimliği verin. Bu kimliği sevkiyat, kusur ve fatura kayıtlarında her yerde kullanın. Böylece yinelenen kayıtlar önlenir ve geçmiş doğru tedarikçiye bağlanır.
Herkesin aynı metrik tanımlarını kullandığından nasıl emin oluruz?Her metriği tek cümlelik kural şeklinde yazın, bir kaynak belirleyin ve çeyrek boyunca buna bağlı kalın. "Zamanında" için hangi tarihin sayılacağını, kısmi sevkiyatların nasıl puanlanacağını ve kusur oranı için hangi paydanın kullanılacağını kararlaştırın. Bir tanımı değiştirirseniz, bunu bir sonraki çeyrekten itibaren uygulayın ve geçmiş için eski sürümü saklayın.
Çeyrek sınırlarını ve kesme kurallarını nasıl tanımlamalıyız?Bir takvim sistemi seçin ve sabitleyin: takvim çeyrekleri veya mali takviminiz, zaman damgaları için tek bir saat dilimi ve çeyreğe ait olma kuralı. Kuralı açık yapın ki geç gelen teslimatlar veya zaman dilimleri arasında kalan sevkiyatlar tartışmaya dönüşmesin. İnceleme başladıktan sonra tarih aralığını dondurun, böylece sonuçlar toplantı sırasında değişmez.
Tedarikçi puan kartı uygulaması için en iyi veri modeli nedir?Önce gerçek olayları modelleyin, sonra bunlardan özetler hesaplayın. Kabuller, muayeneler ve fatura satırları gibi ham gerçekleri çeyreklik toplamlar (OTD yüzdesi, kusur oranı) ile ayrı tutun. Bu, puandan ayrıntıya inmeyi ve raporlama hatalarını azaltmayı kolaylaştırır.
Çeyrek kapandıktan sonra keşfedilen kusurlar veya sonradan girilen krediler gibi geç verilerle nasıl başa çıkmalıyız?Geç gelen verilerle tarihçeyi üzerine yazmayın. Orijinal kayıt tarihini, etki eden çeyreği ve yapılan düzeltme notunu saklayın ki neyin değiştiğini ve nedenini açıklayabilesiniz. Pratik bir varsayılan yaklaşım, yayımlanan puanları dondurmak ve düzeltmeleri bir sonraki çeyreğe ayarlama olarak taşımaktır.
Endless tartışma olmadan genel tedarikçi puanını nasıl hesaplarız?Her metriği 0–100 aralığına çevirin, basit ağırlıklar seçin ve ağırlıkları çeyreklik sonuçla birlikte saklayın. Operasyonel güvenilirlik önemliyse teslimatı en yüksek ağırlıkta başlatın; paydaşlar anlaşınca ağırlıkları değiştirmekten kaçının. Ağırlıkların görünür olması "gizli matematik" tartışmalarını azaltır.
Bir QBR sayfası insanların beş dakikada okuyabilmesi için neleri içermeli?Her tedarikçi için tek sayfa, her çeyrek için aynı düzen. Üstte ana KPI'ları koyun, hızlıca önceki çeyreğe göre karşılaştırma gösterin, sonra sayıları açıklayan yeterli detayı verin. Sonunda sorumlu, son tarih ve durum içeren eylemler olsun ki inceleme takiple sonuçlansın.
Veriye güveni bozmadan nasıl manuel düzeltmelere izin veririz?Ham değerleri değiştirilemez tutun ve düzeltmeleri kim, ne zaman, neden ile birlikte ayrı olarak kaydedin. Bu, sayıyı savunmanıza izin verirken orijinal olayı da saklar ve gerçek dünya istisnalarını raporlama mantığını bozmadan ele almanızı sağlar.
Ağır mühendislik işi olmadan tedarikçi puan kartı uygulaması oluşturabilir miyim?Evet. Kod yazmadan da işe yarayan bir yaklaşım, tek bir paylaşılan veri kümesi, kilitli tanımlar ve tekrarlanabilir hesaplamalar gerektiğinde işe yarar. AppMaster'ı kullanarak tedarikçi ve olayları PostgreSQL'de modelleyebilir, görsel olarak puanlama mantığı oluşturabilir ve aynı veriden web QBR sayfaları üretebilirsiniz. İyi bir ilk adım, kuralları ve veri akışını doğrulamak için 5–10 tedarikçi ve bir tamamlanmış çeyrek ile bir pilot yapmaktır.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
