DMS Nasıl Seçilir: Avrupalı Bir Bayi için RFP ve Puan Kartı

1. Karar ekibini ve kapsamı oluşturun

DMS seçimi satışı, ikinci el araçları, atölyeyi, parçaları, finansı, BT'yi, gizliliği ve grup raporlamasını etkiler. Yalnızca temsilcilerden değil, hesap verebilir operasyonel sahiplerden oluşan bir karar ekibi kurun. Bir yönetici sponsor, ürün sahibi, veri lideri, entegrasyon lideri, güvenlik/gizlilik lideri, finans kontrolörü ve değişim lideri belirleyin. Kimin öneride bulunacağını, kimin onaylayacağını ve zorunlu bir gereklilik konusunda kimin reddedebileceğini tanımlayın.

Tüzel kişilikleri, şubeleri, markaları, ülkeleri, dilleri, kullanıcıları, işlem hacimlerini ve kritik dönemleri belgeleyin. Mevcut kapsamı olası üç yıllık yol haritasından ayırın. Her varsayımsal gelecek pazar için gereklilik belirlemek kararı çarpıtabilirken olası genişlemeyi göz ardı etmek başka bir değişim ihtiyacı yaratabilir.

2. İhtiyaçları test edilebilir gerekliliklere dönüştürün

Bir gereklilik; uygulayıcıyı, tetikleyiciyi, veriyi, eylemi, çıktıyı ve kabulü belirtmelidir. “Güçlü CRM” ifadesini “web, OEM veya telefon sorgusu eşleştirilir ya da oluşturulur, onay kaydedilir, potansiyel müşteri markaya ve coğrafyaya göre yönlendirilir, sahibi ve SLA'sı görünür olur, iletişim kaydedilir ve tamamlanan işlem yinelenen müşteri oluşturmadan durumu döndürür” ifadesiyle değiştirin.

Ülke ve OEM matrisi oluşturun. Her hücre için muhasebe, vergi, fatura, ödeme, tescil, garanti, parça, kampanya, raporlama, kimlik ve dil gerekliliklerini kaydedin. Avrupa bağlamı önemli ölçüde çeşitlilik gösterir. Eurostat'ın binek araç verileri, ülkeye göre filo yaşında ve güç aktarım sisteminde büyük farklılıklar gösterirken gizlilik, veri erişimi ve e-fatura konusundaki AB kuralları yine de yerel uygulama gerektirir.^[1]

3. Geçiş kriterleri, ağırlıklı ölçütler ve kanıt düzeyleri kullanın

Uygunluk geçiş kriterleri yüksek bir toplam puanın ölümcül bir boşluğu gizlemesini önler. Örnekler arasında gerekli bir ülke için üretim desteği, adı geçen OEM arayüzü, yasal muhasebe çıktısı, veri ikamet sınırı veya geçiş son tarihi bulunur. Başarısız bir geçiş kriteri yalnızca tarih, sahip, maliyet ve sözleşmesel taahhüt içeren onaylı bir düzeltmeyle çözülebilir.

4. Ürün turlarını kabul etmek yerine demoları senaryolaştırın

Temsili ama güvenli veriler ve sabit senaryolar sağlayın. Tedarikçiden bir potansiyel müşteriyi teklif, takas ve sipariş üzerinden; bir ikinci el aracı değerleme, inceleme, hazırlık, medya, yayın, fiyatlandırma ve satış üzerinden; bir iş emrini rezervasyon, teknisyen çalışması, parçalar, ek onay ve fatura üzerinden; ve bir dönem kapanışı veya yönetim raporu yolunu göstermesini isteyin.

İstisnaları ekleyin: yinelenen müşteri, yanlış şasi numarası, iptal edilen işlem, bulunmayan parça, başarısız arayüz, çevrimdışı inceleme, ters çevrilmiş fatura ve işlem sırasında ayrılan kullanıcı. Sistemleri, tıklamaları, yeniden girilen değerleri, manuel dışa aktarmaları ve görünmeyen arka plan bağımlılıklarını sayın. Gösterilen sürümü ve pazarı kaydedin.

Standartlar birlikte çalışabilirliği artırabilir; ancak bir gösterimin yerini tutmaz. STAR, otomotiv potansiyel müşteri, işlem ve perakende teslimat API'lerini ve bir perakende alan modelini yayımlar.^[2] Bir tedarikçinin ilgili standartları uygulayıp uygulamadığını ve nasıl uyguladığını sorun, ardından önerilen gerçek arayüzü test edin.

5. Bulut, API, güvenlik ve veri iddialarını doğrulayın

Bulut için SaaS, özel barındırma veya barındırılan eski mimariyi belirleyin. Kullanılabilirlik tanımlarını, olay geçmişini, RPO'yu, RTO'yu, yedekleme ve kurtarma test kanıtını, bakım kurallarını ve kapasite modelini isteyin. API'ler için nesneleri, alanları, olayları, yazma işlemlerini, kimlik doğrulamayı, sanal alanı, hız sınırlarını, aşımları, sürümlemeyi, izlemeyi ve veri dışa aktarma haklarını isteyin.

Gizlilik ve güvenlik için rolleri, en az yetki ilkesini, MFA'yı, günlüklemeyi, şifrelemeyi, güvenlik açığı yönetimini, alt işlemcileri, aktarım mekanizmasını, saklamayı, silmeyi, olay bildirimini ve bağımsız güvenceyi değerlendirin. GDPR risk düzeyine uygun kontroller ve tasarım gereği gizlilik gerektirir; ancak bir sertifika veya bulut sağlayıcısı bayiyi otomatik olarak uyumlu hâle getirmez.^[3] ENISA rehberliği kanıt taleplerini yapılandırabilir; ancak NIS2 kapsamı ayrı olarak değerlendirilmelidir.^[4]

6. Adil kamuya açık kanıt durumları uygulayın

Kamuya açık durum bir yönlendirme aracıdır. Satın alma kanıtları bunu değiştirebilir. Bir tedarikçi, gerçek hataları düzeltmeye ve uygun bir süreç kapsamında güncel gizli kanıt sunmaya davet edilmelidir.

7. Uygulama, referanslar ve sözleşmeyle tamamlayın

Referans görüşmeleri ülke, bayi büyüklüğü, OEM karmaşıklığı ve kapsamla eşleşmelidir. Sözleşme sonrasında nelerin değiştiğini, hangi geçici çözümlerin gerektiğini, hangi verilerin başarısız olduğunu, benimsemenin ne kadar sürdüğünü, olayların nasıl ele alındığını ve referansın farklı ne yapacağını sorun. Yalnızca kullanıcıların ürünü beğenip beğenmediğini sormayın.

Kabul kriterlerini sözleşmesel hâle getirin. Veri eksiksizliğini ve mutabakatını, kritik iş akışlarını, entegrasyonları, performansı, güvenliği, eğitimi, geçişi ve desteği kapsayın. Geçiş yinelemelerinin, ortamların, API kullanımının, mesajların, depolamanın, rapor çalışmasının, seyahatin, endekslemenin ve değişiklik taleplerinin fiyatını belirleyin. Hizmet düzeylerini, yükseltmeyi, çıkış dışa aktarımını, geçiş desteğini, silmeyi ve yasal kayıtlara devam eden erişimi tanımlayın.