Ağır Sanayi ve Otomotiv Yedek Parça Sektöründe Şasi No (VIN) ve OEM Kodlu B2B E-Ticaret

Ağır sanayi makineleri, ticari araçlar ve otomotiv yedek parçalarında dijital satışın temel sorunu, ürünü çevrim içi göstermekten çok doğru parçayı doğru araç, makine ve müşteriyle eşleştirmektir. Benzer görünümlü parçalar; model yılına, motor seçeneğine, üretim serisine, aks tipine veya donanım varyantına göre farklılaşabilir. Bu nedenle klasik kategori ve ürün adı araması, profesyonel satın alma sürecinde tek başına yeterli değildir.

Şasi numarası (VIN), OEM kodu ve teknik ürün özelliklerini B2B sipariş deneyiminin merkezine alan bir platform, alıcının seçenekler arasında kaybolmasını önlemeyi amaçlar. Doğru kurgulandığında bayi, servis ya da filo müşterisi uygun parçaya daha hızlı ulaşabilir; satış ekibi tekrarlayan uygunluk kontrollerine daha az zaman ayırabilir; hatalı sipariş ve iade riski azaltılabilir. Ancak bunun için arama ekranından veri modeline, fiyatlandırmadan ERP entegrasyonuna kadar bütün sistem birlikte tasarlanmalıdır.

VIN ve OEM kodlu B2B e-ticaret nedir?

VIN, karayolu araçlarını tanımlamak için kullanılan yapılandırılmış bir kimlik numarasıdır. ISO 3779 standardı, VIN içeriği ve yapısı üzerinden dünya çapında ortak bir araç tanımlama sistemi kurulmasını amaçlar. ABD Ulusal Karayolu Trafik Güvenliği İdaresi de kendi düzenlemeleri kapsamındaki motorlu araçlarda VIN'in 17 karakterden oluştuğunu ve araca ilişkin belirli bilgileri kodladığını açıklar. Bununla birlikte VIN'den elde edilebilecek alanlar pazara, üreticiye ve veri kaynağına göre değişebileceği için platformun her karakterden kesin bir parça sonucu çıkaracağı varsayılmamalıdır.

OEM kodu ise parçanın üretici ekosistemindeki referansını bulmaya yardımcı olur. Fakat eski ve yeni kodlar, yerine geçen parçalar, takım ve alt parça ilişkileri, farklı markalardaki çapraz referanslar ile yazım biçimleri yönetilmeden yalnızca kod araması da güvenilir sonuç üretmez. VIN ve OEM kodlu B2B e-ticaret; bu tanımlayıcıları ürün özellikleri, uyumluluk kayıtları, ticari kurallar ve kurumsal iş akışlarıyla birleştiren dijital satış sistemidir.

Doğru parça bulma deneyimi nasıl kurgulanır?

1. Girdi doğrulanmalı ve normalize edilmelidir

Kullanıcı VIN, OEM kodu, stok kodu, üretici referansı veya serbest metinle arama yapabilir. Sistem; boşluk, tire, büyük-küçük harf ve yaygın yazım farklarını normalize etmeli, geçersiz biçimleri erken aşamada bildirmelidir. VIN girildiğinde araç veya makine profili oluşturulmalı; marka, model, üretim dönemi, motor, şanzıman, şasi tipi ya da erişilebilen diğer nitelikler görünür olmalıdır. NHTSA VIN Decoder örneğinde de sonuçların üretici tarafından bildirilen verilere dayandığı belirtilir. Bu, veri kaynağının ve güncellik tarihinin platformda izlenmesi gerektiğini gösterir.

2. Eşleşmenin nedeni açıklanmalıdır

Bir ürünün sonuçlarda görünmesi yeterli değildir. Kullanıcı, parçanın neden uyumlu olduğunu anlayabilmelidir: belirli motor koduyla eşleşme, üretim tarihi aralığı, aks veya kabin varyantı, seri numarası eşiği ya da OEM çapraz referansı gibi kanıtlar sunulmalıdır. Eşleşme kesin değilse sistem bunu “uyumlu”, “koşullu uyumlu” veya “teknik doğrulama gerekli” gibi seviyelerle göstermelidir. Böylece belirsizlik yanlış bir kesinlik olarak sunulmaz.

3. Alternatif ve yerine geçen parçalar yönetilmelidir

Aranan kod kullanım dışı olabilir, yeni bir kodla değiştirilmiş olabilir veya eşdeğer ürün bulunabilir. Platform; önceki-yeni kod ilişkisini, orijinal ve muadil ayrımını, takım içeriğini ve zorunlu tamamlayıcı parçaları açıklayabilmelidir. Muadil önerileri yalnızca ticari önceliğe göre değil, teknik uyumluluk ve müşteri sözleşmesindeki ürün politikalarına göre sıralanmalıdır.

Ürün bilgi mimarisi neden projenin temelidir?

Başarılı bir yedek parça platformunda ürün kartı yalnızca ad, fiyat ve fotoğraftan oluşmaz. OEM kodları, marka kodları, ölçüler, malzeme, montaj yönü, araç veya makine uyumluluğu, üretim aralıkları, dokümanlar, görseller, paket miktarı ve lojistik bilgiler yapılandırılmış alanlarda tutulmalıdır. Parça, araç ve uyumluluk ilişkilerinin ayrı veri varlıkları olarak modellenmesi; aynı bilginin binlerce üründe tekrar edilmesini ve çelişmesini önler.

Veri sahipliği de açıkça belirlenmelidir. Hangi alan ERP'den, hangisi üretici kataloğundan, hangisi ürün bilgi yönetimi katmanından gelir? Değişikliği kim onaylar ve eski değer nasıl izlenir? Bu sorular yanıtlanmadan geliştirilen arama motoru, eksik veriyi yalnızca daha hızlı gösterir. Ürün verisinin kanallar arasında yönetilmesi için PIM yaklaşımı ayrıca değerlendirilmelidir.

B2B müşteriye özel fiyat, stok ve yetki yönetimi

Aynı parçanın her kullanıcıya aynı koşullarla sunulması B2B gerçekliğine uymaz. Cari hesap, bayi grubu, sözleşme, para birimi, miktar basamağı, kampanya, ödeme koşulu ve teslimat noktası fiyatı etkileyebilir. Sistem, kuralların öncelik sırasını tanımlamalı ve kullanıcıya uygulanan fiyatın kaynağını yetkisi ölçüsünde açıklayabilmelidir. Çakışan ticari kurallar için ayrıntılı yaklaşım, bayi portalında özel fiyat ve iskonto yönetimi rehberinde ele alınabilir.

Stok görünürlüğü de tek bir sayıdan ibaret değildir. Merkez depo, bölge deposu, transit stok, rezerve miktar, tedarik süresi ve tahmini sevk tarihi ayrıştırılmalıdır. Bir bayi yalnızca kendi deposunu ve izin verilen merkez stoklarını görürken, servis yöneticisi farklı lokasyonları karşılaştırabilir. Fiyat görüntüleme, teklif oluşturma, sipariş verme, iskonto isteme, belge indirme ve iade açma yetkileri rol ve müşteri hesabı düzeyinde yönetilmelidir.

Hızlı siparişten onaya uzanan satın alma akışı

Profesyonel alıcılar çoğu zaman onlarca veya yüzlerce satırı birlikte sipariş eder. Bu nedenle ürün kartından sepete eklemenin yanında OEM ya da stok koduyla hızlı giriş, kopyala-yapıştır, kayıtlı listeler ve Excel/CSV yükleme seçenekleri gerekir. Yüklenen her satır; kod, miktar, birim, uyumluluk, satışa açıklık, minimum paket, fiyat ve stok açısından doğrulanmalıdır. Hatalı satırlar tüm dosyayı durdurmak yerine açıklanabilir biçimde ayrıştırılmalıdır. Bu sürecin ayrıntıları B2B toplu sipariş planlama içeriğinde incelenebilir.

Sepet tamamlandığında müşterinin organizasyon yapısı devreye girer. Tutar, ürün grubu, bütçe, şube, risk limiti veya özel iskonto talebi bir onay gerektirebilir. Talebi oluşturan, teknik uygunluğu kontrol eden, bütçeyi onaylayan ve siparişi kesinleştiren kişiler farklı olabilir. Vekâlet, zaman aşımı ve reddetme gerekçeleriyle birlikte denetim izi tutulması, süreci e-posta zincirlerinden çıkarır.

ERP ve harici sistem entegrasyonu nasıl tasarlanır?

B2B platformu ile ERP arasında hangi sistemin hangi veride ana kaynak olduğu açıkça tanımlanmalıdır. Ürün ana verisi, cari hesap, risk limiti, fiyat, stok, sipariş, irsaliye, fatura ve iade durumları için veri sahipliği tablosu hazırlanmalıdır. Platform siparişi aldığında ERP'nin belge numarası üretmesi tek başına yeterli değildir; kabul, kısmi kabul, ret, bekleme ve hata durumları da kullanıcıya geri dönmelidir.

Entegrasyonun gerçek zamanlı mı, olay tabanlı mı yoksa periyodik mi çalışacağı veri türüne göre seçilmelidir. Fiyat ve kullanılabilir stok hızlı güncellenmek isterken teknik dokümanlar daha seyrek aktarılabilir. Aynı siparişin ağ kesintisi nedeniyle iki kez oluşmasını önleyen güvenli tekrar mekanizması, kuyruk, hata kaydı, yeniden deneme ve mutabakat ekranları operasyonun vazgeçilmez parçalarıdır.

Sipariş sonrasında kısmi sevkiyatlar, taşıyıcı bilgisi, irsaliye, fatura ve teslimat kanıtı tek yaşam döngüsünde gösterilmelidir. Bu görünürlük için B2B sipariş takip portalı yaklaşımı kullanılabilir. İade sürecinde ise VIN veya makine kaydı, sipariş satırı, iade nedeni, görsel, seri ya da lot bilgisi ve depo kabul sonucu birbirine bağlanmalıdır.

Ağır sanayi makinelerinde VIN yaklaşımı nasıl uyarlanır?

Her ağır sanayi makinesinde otomobillerdekiyle aynı VIN yapısı veya aynı veri kapsamı bulunmayabilir. Şasi numarasının yanında makine seri numarası, motor seri numarası, ekipman modeli, üretim yılı ve ataşman kodu gerekebilir. Bu nedenle platform, tek bir araç veri şemasını bütün markalara zorlamak yerine ürün ailesine ve üreticiye göre genişleyebilen bir varlık modeli kullanmalıdır.

Karayolu araçları için ortak tanımlama yaklaşımı güçlü bir başlangıç noktası olsa da uyumluluk veri seti üretici katalogları ve yetkili veri kaynaklarıyla beslenmelidir. Avrupa Birliği'nin 2018/858 sayılı düzenlemesi, araç onarım ve bakım bilgilerine ilişkin erişim çerçevesini de kapsar. Yine de hukuki erişim hakkı, belirli bir platformun bütün uyumluluk verisine otomatik olarak sahip olduğu anlamına gelmez; lisanslar ve kullanım şartları ayrıca değerlendirilmelidir.

Güvenlik, performans ve yönetilebilirlik

Fiyat listeleri, ticari koşullar, müşteri hesapları ve araç kayıtları hassas kurumsal veriler içerir. Rol tabanlı erişim, güçlü kimlik doğrulama, işlem kayıtları, şifreleme, yedekleme ve entegrasyon kimlik bilgilerinin güvenli saklanması proje kapsamında ele alınmalıdır. Bir kullanıcı bağlı olmadığı cari hesabın fiyatını, belgesini veya siparişini görememelidir.

On binlerce OEM referansı ve uyumluluk kaydı bulunan kataloglarda arama performansı kullanıcı deneyimini doğrudan etkiler. İndeksleme, filtreleme, önbellek ve veri güncelleme stratejisi birlikte planlanmalı; performans yalnızca ana sayfada değil VIN çözümleme, toplu doğrulama ve yoğun sipariş saatlerinde de ölçülmelidir. Yönetim paneli ise veri ekiplerinin eşleşme kurallarını, kod ilişkilerini ve yayın durumlarını yazılım ekibine bağımlı kalmadan yönetebilmesini sağlamalıdır.

Proje kapsamı belirlenirken hangi sorular sorulmalı?

• Hangi araç, makine, marka ve pazarlarda satış yapılacak?
• VIN, seri numarası ve OEM eşleştirme verisi hangi kaynaklardan gelecek?
• Uyumluluğun kesinliği nasıl derecelendirilecek ve kim tarafından onaylanacak?
• Fiyat, iskonto, stok ve kredi kurallarının ana kaynağı hangi sistem olacak?
• Hangi kullanıcı rolleri teklif, sipariş, onay, belge ve iade işlemi yapabilecek?
• ERP dışında PIM, CRM, ödeme, taşıyıcı veya üretici kataloğu bağlantısı gerekecek mi?
• Başarı; arama süresi, eşleşme oranı, hatalı sipariş, iade veya manuel işlem süresiyle nasıl ölçülecek?

Bu sorulara verilen yanıtlar, hazır bir katalog kurulumundan farklı olarak projeye özel B2B e-ticaret ve web yazılımının gerçek kapsamını oluşturur. İlk sürümde en çok kullanılan marka, ürün grubu ve sipariş senaryolarına odaklanmak; veri kalitesi ve entegrasyon sonuçları ölçüldükçe kapsamı genişletmek daha yönetilebilir bir geçiş sağlar.

Sonuç: Dijital katalogdan bütünleşik satış sistemine

VIN ve OEM kodlu B2B e-ticaret, arama kutusuna iki yeni alan eklemek değildir. Değer; kimlik doğrulama, açıklanabilir uyumluluk, nitelikli ürün verisi, müşteriye özel ticari kurallar, hızlı sipariş, onay, sevkiyat ve iade süreçlerinin aynı mimaride buluşmasıyla ortaya çıkar. ERP ve gerekli harici sistemlerle güvenilir veri alışverişi kurulduğunda platform, satışın yanı sıra servis, depo ve müşteri operasyonları için de ortak görünürlük sağlayabilir.

Kumsal Ajans, ağır sanayi ve otomotiv yedek parça B2B e-ticaretini yalnızca çevrim içi katalog olarak değil, kurumun gerçek işleyişine uyarlanan bütünleşik bir dijital satış sistemi olarak ele alır. VIN ve OEM kodlu yedek parça satış süreçlerinizi, kullanıcı rollerini, ürün verisini ve ERP entegrasyonu gereksinimlerini birlikte analiz ederek kurumunuza özel B2B e-ticaret platformunun kapsamını belirlemek için Kumsal Ajans ile iletişime geçin.