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.
Baştan netleşsin: 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. Ölçülmüş karşılığı şu: 19 kiracı kod yazmadan toplam 277 özel alan tanımladı, bir kiracı 9 özel nesne ekledi. 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. API tarafının ölçülmüş kapasitesi şu: kimlik doğrulama OAuth2 iledir, composite ucu tek istekte 25 alt-istek, toplu uç tek çağrıda 200 kayıt taşır. Katalog aktarımı bu sayılara göre 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.
Bizim sınırlarımız
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. Sihirbaz da kusursuz değil: erişebildiğimiz 8 kiracıda çalıştırılan 34 içe aktarma işinden 16'sı hatayla bitti. Sıfır veri kaybı garantisi vermiyoruz.
Sütun eşleştirmesini otomatik saymayın. Salesforce müşteri adayı dışa aktarımında 19 başlığın 19'u doğru alanla eşleşti; HubSpot kişi dışa aktarımında 17 başlığın 13'ü eşleşti ve 2'si yanlış alana bağlandı. Bu ölçüm yalnız o iki dosyaya aittir, adı geçen ürünlerin geneli hakkında bir hüküm değildir. Eşleştirmeyi ekranda siz onaylarsınız; ayrıntısı alan eşleştirme yazısında.
Bir de üründe kurulu olup sahada ölçmediğimiz bir şey var: belge imzalama ekranı. Ölçüm günü bakılan 8 kiracının 8'inde de 0 imza ve 0 imza talebi vardı. Bayi sözleşmesi akışını buna göre planlayın.
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'i kuran ekip, Salesforce döneminde 200'den fazla kurumsal CRM projesi tamamladı. 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.
Kurulumun kapsamı keşiften sonra yazılı paylaşılır; aralık değil tarih veririz.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
