Otomotiv Yedek Parçada Envanter ve Talep Yönetimi: Zor Olan Stok Değil, Parçanın Kimliği
- Kategori
- CRM
- Yayın tarihi
- 27 Ağustos 2026
Otomotiv yedek parçada envanter yönetiminin zor kısmı sayım değildir. Zor olan, sayılan şeyin ne olduğudur: raftaki kutunun hangi parça olduğu, hangi numaralarla anıldığı ve hangi araçlara uyduğu.
Bir rafta kaç balata durduğunu her stok programı söyler. «Bu balata 2016 model dizel bir Focus'a uyar mı?» sorusunun cevabı ise stok kaydının içinde yoktur. Ayrı bir veri kümesindedir, ayrı bakım ister ve yanlış olduğunda iade olarak geri döner.
Bu yazı o ayrımı anlatıyor: parça kimliğinin (OEM numarası, muadil, çapraz referans) ve araç-parça uyumluluğunun neden stok miktarından daha zor yönetildiğini, bu verinin kimin sorumluluğunda olduğunu ve CRM'in zincirin neresinde durduğunu. Ürün tarafındaki karşılığı oto yedek parça CRM sayfasında duruyor; burada mekanizmayı yazıyoruz.
Stok otoritesi CRM'de değildir; aşağıda ayrı bir bölümde açıyoruz. Yazıdaki ürün rakamları kendi kurulumlarımızda ölçülmüş değerlerdir. Sektör hakkında dışarıdan alınmış bir istatistik kullanmadık.
Stok bir sayıdır ve tek bir doğru cevabı vardır. Uyumluluk ise bir iddiadır: kim söyledi, hangi kaynağa dayanıyor, en son ne zaman doğrulandı. Üçü birden bilinmiyorsa o iddia iade demektir.
İçindekiler
Yedek parçada envanterin birimi «adet» değil, kimliktir
Envanter yönetimi genelde iki soruyla anlatılır: elimde kaç var, ne zaman biter. Yedek parçada bu ikisinin önünde üçüncü bir soru durur ve diğerlerini geçersiz kılabilir: elimdeki tam olarak nedir?
Sebep, aynı fiziksel parçanın birden çok adla dolaşmasıdır. Araç üreticisinin verdiği bir numara vardır; parçayı fiilen üreten tedarikçinin kendi kodu vardır; yan sanayi muadillerinin her birinin ayrı kodu vardır; depo yazılımınızın kendi stok kodu vardır; kutunun üzerinde ayrıca bir barkod vardır. Beşi de aynı balatayı işaret eder ve hiçbiri diğerinden otomatik türetilemez.
Bu yüzden yedek parçada mükerrer kayıt sorunu başka sektörlerdekinden farklı çalışır. İki müşteri kaydını birleştirirken karar verirsiniz; iki parça kaydını birleştirmeye hakkınız olup olmadığını bilmek içinse o iki kodun aynı parçayı gösterdiğini bir yerden doğrulamanız gerekir ve o yer sizin kataloğunuzdur.
Sorun ters yönde de çalışır: tek bir kod, üretim tarihine ya da donanım seviyesine göre birbirinin yerine geçmeyen iki parçayı işaret ediyor olabilir. Bunu söyleyen şey kaydın kendisi değil, yanına yazılmış uyumluluk şartıdır.
Parçayı tarif eden numaralar ve her birinin sınırı
| Numara | Kim verir | Tek başına neyi söylemez |
|---|---|---|
| OEM numarası | Araç üreticisi | Hangi muadillerin bu numaranın yerine geçtiğini |
| Üretici parça kodu | Parçayı fiilen üreten tedarikçi | Hangi araç modellerine takıldığını |
| Muadil (yan sanayi) kodu | Muadil üreticisi | Hangi OEM numarasının karşılığı olduğunu |
| Çapraz referans tablosu | Katalog sağlayıcısı ya da işletmenin kendisi | Ne zaman güncellendiğini ve kimin doğruladığını |
| Dahili stok kodu | İşletmenin kendi stok programı | Dışarıdaki bir katalogla eşleştiğini |
| Barkod (EAN) | Ambalajı basan taraf | Kutudaki parçanın hangi araca uyduğunu |
Uyumluluk verisi bir varlıktır; sahibi de bakımı da sizdedir
Araç-parça uyumluluğu, «şu parça şu araçlara uyar» biçiminde yazılmış bir eşleştirme kümesidir. Tek bir parça için onlarca satır olabilir: marka, model, kasa kodu, üretim yılı aralığı, motor kodu, donanım seviyesi. Ve bu satırlar bir kere yazılıp bitmez; yeni model çıkar, üretici numarayı değiştirir, muadil tedarikçi kod haritasını günceller.
Bu veriyi kim sağlar? Üç kaynak vardır ve üçü de sizin tarafınızdadır: üreticiden gelen katalog, abone olduğunuz ticari bir katalog servisi ve ekibinizin yıllar içinde biriktirdiği düzeltmeler. Üçüncüsü genelde en değerlisidir ve genelde tek bir kişinin hafızasındadır.
Asıl risk bir yazılım eksiği değil, bir sahiplik boşluğudur. Uyumluluk verisinin kimin sorumluluğunda olduğu yazılı değilse, o veri kimsenin sorumluluğunda değildir. Dijital dönüşüm konuşurken ilk soru şudur: bu tablo hangi sistemde yaşayacak, kim güncelleyecek, yanlış çıktığında kim düzeltecek?
Rapitek CRM bu soruların hiçbirini sizin yerinize cevaplamaz. Yaptığı iş daha dar: karar verildikten sonra o kararın kayıt üzerinde alan olarak durmasını sağlamak. Özel alan ve nesne yönetici ekranından, kod yazmadan eklenir: OEM ve muadil kod alanlarını, hatta ayrı bir uyumluluk nesnesini geliştirici beklemeden açabilirsiniz. Ama içine ne yazılacağı sizin verinizdir.
Stok otoritesi CRM'de değildir
Bunu net yazalım: bir parçanın kaç adet olduğunun resmî cevabı CRM'de değildir. Stok miktarının otoritesi, mal kabulünü ve sevkiyatı kaydeden sistemdedir; pratikte ERP'niz, depo yönetim programınız ya da muhasebe yazılımınız. CRM ekranında görünen herhangi bir stok sayısı o kaynaktan alınmış bir kopyadır ve kopya her zaman bir yaşlılık taşır.
Bu bir eksiklik değil, bir sınır tanımıdır. Aynı sayıyı iki sistem birden yazabiliyorsa hangisinin doğru olduğu sorusu çözümsüzdür; tek yazar belirlenmediğinde «sistemler konuşmuyor» denen şey çoğu zaman tam olarak budur.
Pratik sonucu şu: satıcı ekranında bir stok bilgisi göstermek isterseniz, o bilgi anlık değil, beslenen bir bilgidir. Anlık stok senkronizasyonu vaat etmiyoruz. Bağlantı REST API, webhook ve içe/dışa aktarma ile kurulur; hangi verinin hangi yöne ve hangi sıklıkta akacağı kurulumda yazılı olarak tanımlanır. Müşteri adayından teklife, faturadan göreve CRM'deki kayıtlar REST API ile okunup yazılır; alan yapısı da dışarıdan görülür. Erişim şifre paylaşmadan, yetkiyle verilir. Katalog aktarımı kurulumda planlanır; yaklaşım ERP-CRM entegrasyonu sayfasında.
Aynı sınırın teklif-sipariş-sevkiyat-fatura zincirindeki karşılığını sipariş yönetimi yazısında ele aldık.
CRM tarafında gerçekten duran dört kayıt
Talep kaydı
Gelen sorgu kayda geçer: hangi araç, hangi parça, hangi kanal. Parça stokta yoksa bile kayıt kalır; sorulan ama verilemeyen parçanın listesi ancak böyle oluşur. Bu liste satın alma kararının girdisidir, stok sayımının değil.
Teklif
Fiyat müşterinin bağlı olduğu listeden gelir, iskonto kaydın üzerinde görünür. Teklifin hangi parça kimliğiyle verildiği de kaydedilir; «hangi kodu teklif etmiştik» sorusu bu yüzden sonradan cevaplanabilir.
Müşteri ve araç geçmişi
Hangi servisin hangi araçlarla çalıştığı ve geçmişte hangi parçaları sorduğu müşteri kartında birikir. Aynı araç bilgisi üçüncü kez sorulmaz.
İade ve garanti takibi
İadenin gerekçesi kayda geçtiğinde uyumluluk verisi geri besleme alır: «yanlış parça» gerekçeli iadeler çapraz referans tablosundaki hatalı satırı işaret eder. Kataloğu düzeltmenin en ucuz girdisi budur.
Sorulan ama verilemeyen parça: talebin envanteri
Stok raporu elinizde ne olduğunu söyler; elinizde olmayıp sorulanı söylemez, çünkü o kayıt hiç doğmamıştır. Yedek parçada kaçan satışın önemli bir kısmı burada durur: müşteri aradı, parça yoktu, telefon kapandı, geriye iz kalmadı.
Talep kaydı bu izi üretir. Sorgu, sonucundan bağımsız olarak kayda geçtiğinde iki liste doğar: hangi parçalar sık sorulup verilemiyor ve hangi müşteri hangi araç grubu için düzenli talep açıyor. Birincisi satın alma tarafının girdisidir, ikincisi satış tarafının.
Bir ön koşulu var ve atlanırsa yöntem çalışmaz: kaydın sonucu gerekçesiyle kapatılması gerekir. «Stokta yoktu» ile «fiyat yüksek geldi» aynı kutuya düşerse liste karar verdirmez, yalnız hacim gösterir. Aşamaların çıkış kriterlerini yazıya dökmek bu yüzden bir kurulum işidir, yazılım işi değil; aynı mekanizma fırsat yönetimi yazısında genel olarak anlatılıyor.
Kapsam ve kurulum koşulları
Araç-parça uyumluluk verisi satmıyoruz, üretmiyoruz ve kutudan çıkan bir katalogla gelmiyoruz; uyumluluk bilgisinin kaynağı sizin kataloğunuzdur ve doğruluğu ondan devralınır.
Anlık stok senkronizasyonu vaat etmiyoruz. Stok miktarının otoritesi sizin ERP ya da stok programınızda kalır; CRM'de görünen değer, kurulumda tanımlanmış bir akışla beslenen kopyadır.
Katalog aktarımının ölçülen tavanı iki kalemde duruyor: bir dosya en fazla 25 MB, bir iş en fazla 100.000 satır. Uyumluluk tabloları bu tavanı kolayca aşar; o durumda aktarım parçalara bölünür ya da REST API üzerinden projeye özel yazılır. İçe aktarmada biçim ve zorunlu alan hataları sık görülür; bu yüzden aktarımı canlıya geçmeden önce deneme verisiyle birlikte test ediyoruz.
Sütun eşleştirmesini otomatik saymayın. Dışa aktarım dosyasındaki sütun başlıkları sihirbazda alanlarla otomatik eşlenir; eşleşmeyenleri kurulumda birlikte eşleriz. Eşleştirmeyi ekranda siz onaylarsınız; ayrıntısı alan eşleştirme yazısında.
Belge imzalama ekranı üründe kurulu ve yeni bir özellik; bayi sözleşmesi akışınız buna bağlıysa demoda birlikte deneyelim.
Yedek parçada envanter ve talep yönetimi hakkında sık sorulanlar
OEM numarası, muadil kod ve çapraz referans arasındaki fark ne?
Araç-parça uyumluluk verisini Rapitek CRM sağlıyor mu?
CRM stok takibi yapar mı, ERP'nin yerine geçer mi?
Katalogumuzu içe aktarabilir miyiz, kaç satıra kadar?
OEM ve muadil kod alanlarını açmak için geliştirici gerekir mi?
İade ve garanti takibi CRM tarafında mı?
Yedek parça işletmesinde dijital dönüşüm nereden başlar?
İlgili içerikler
- Oto Yedek Parça CRM: sektör sayfası: sorgudan teklife akış, bayi fiyat listeleri ve kurulum kapsamı.
- Sipariş yönetimi nedir?: teklif-sipariş-sevkiyat-fatura zincirinde CRM ile ERP sınırının nerede çizildiği.
- CRM veri göçünde alan eşleştirme: katalog aktarırken sütunların ne kadarının otomatik eşleştiğinin ölçümü.
- Excel'den CRM'e ne zaman geçmeli?: parça ve müşteri listesi hâlâ Excel'deyse eşiği gösteren sinyaller.
- ERP-CRM entegrasyonu: stok ve cari verisinin hangi yöne aktığı nasıl tanımlanır.
- Lastik CRM: mevsimlik talep ve ebat bazlı kimlik: aynı problemin komşu hâli.
Parça kimliğini kendi kataloğunuzla birlikte kuralım
Rapitek CRM, kurucumuzun 200'den fazla Salesforce projesindeki deneyimiyle kuruldu. Hangi kod alanlarının açılacağını, uyumluluk verisinin nerede yaşayacağını ve stok bilgisinin hangi yönden besleneceğini keşif görüşmesinde birlikte çıkarırız. Ardından 7 günlük deneme hesabınızı açalım; kredi kartı istemiyoruz.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
