DMS mimarisi
Bulut DMS ve Şirket İçi DMS: Avrupa Bayi Rehberi
Yararlı soru, hangi dağıtım etiketinin daha modern göründüğü değildir. Hangi işletim modelinin bayi grubuna kabul edilebilir toplam maliyetle doğru kontrolü, sürekliliği, entegrasyon hızını ve kanıtı sağladığıdır.
Kısa cevap
Bulut DMS genellikle ağ üzerinden erişilen, merkezi olarak işletilen bir hizmet olarak sunulurken şirket içi DMS esas olarak bayilikte veya grupta kontrol edilen altyapı üzerinde çalışır. Bulut, güncellemeleri, şubeler arası erişimi ve esnek kapasiteyi kolaylaştırabilir. Şirket içi ise doğrudan altyapı kontrolü sağlayabilir ve özel yerel bağımlılıkları destekleyebilir. Hiçbir model kendiliğinden daha ucuz, daha güvenli veya daha güvenilir değildir. Karar; ölçülebilir gereksinimlere, paylaşılan sorumluluk modeline ve test edilmiş bir geçiş ve çıkış planına dayanmalıdır.
1. Operasyonel açıdan mimari farkı
Şirket içi DMS genellikle uygulama sunucularını, veritabanlarını veya her ikisini bayi kontrolündeki tesislere yerleştirir. Dahili BT veya sözleşmeli bir ortak; donanımı, işletim sistemlerini, yedeklemeleri ve dağıtım takvimlerini korur. Bulut DMS bu görevlerin büyük bir bölümünü hizmet sağlayıcıya devreder. Kullanıcılar genellikle platforma bir tarayıcı veya yönetilen uygulama üzerinden erişir; sağlayıcı ise paylaşılan veya özel bulut altyapısını işletir.
Sınır nadiren kesindir. Şirket içi bir sistem barındırılan portallar ve bulut yedeklemesi kullanabilir. Bulut DMS yine de yerel yazdırma hizmetlerine, atölye cihazı bağlayıcılarına, kimlik bileşenlerine veya entegrasyon ağ geçidine ihtiyaç duyabilir. Bu nedenle satın alma ekibi gerçek topolojiyi çizmelidir: müşteri, araç, muhasebe ve atölye verilerinin nerede işlendiği; hangi bileşenlerin arızalanabileceği; her katmanı kimin yamaladığı ve bir satış, iş emri veya fatura için hangi bağlantıların gerekli olduğu.
Avrupa'daki bulut benimsemesi bağlam sağlar; ancak bayi için bir sonuç değildir. Eurostat, AB işletmelerinin %52,74'ünün 2025'te ücretli bulut hizmetleri kullandığını bildiriyor; bu oran 2023'te %45,32 idi. Benimseme, küçük işletmelerde %49,3'ten büyük işletmelerde %84,67'ye kadar değişiyordu. Ancak bulut kullanımı temel e-posta ve dosya depolamayı da kapsar. Bu, bayilerin yarısının bulut yerlisi bir DMS çalıştırdığı anlamına gelmez. [1]
2. Abonelik ile donanımı değil toplam maliyeti karşılaştırın
Şirket içi maliyet genellikle sunucuları, veritabanı lisanslarını, sanallaştırmayı, yedeklemeyi, izlemeyi, güvenlik araçlarını, elektriği, tesisleri, donanım yenilemelerini ve uzman iş gücünü kapsar. Bulut maliyeti genellikle abonelik ücretlerini, uygulamayı, veri geçişini, ortamları, depolamayı, kullanım eşiklerini, premium desteği ve entegrasyon çalışmasını kapsar. Her iki model de kesinti, eğitim ve süreç yeniden tasarımı maliyetleri doğurabilir.
Şeffaf varsayımlarla beş ila yedi yıllık bir model oluşturun. Yeni şubeleri, mevsimsel yükü, satın almaları, düzenleyici değişiklikleri, arayüz bakımını ve sözleşme endekslemesini dahil edin. İşlem hacimleri, kullanıcılar veya API çağrıları arttığında ne olacağını sorun. Sözleşme sonunda verilerin tamamının kullanılabilir formatlarda çıkarılma maliyetini dahil edin. Entegrasyonlar, ortamlar veya çıkış desteği ayrı fiyatlandırılıyorsa düşük bir ilk yıl fiyatı yanıltıcı olabilir.
Maliyet modeli dahili kapasiteyi de değerlendirmelidir. Bulut hizmeti rutin altyapı işini azaltıyorsa fayda yalnızca ekip bu zamanı yeniden kullanabiliyorsa vardır. Tersine, bayinin kararlı altyapısı, uzman entegrasyonları ve yetkin personeli varsa hemen değiştirmek faydalı bir yatırımı yok edebilir. Sağlam bir iş gerekçesi hem kaçınılan maliyeti hem de yeni bağımlılığı belgelemelidir.
3. Dayanıklılık, tüm hizmet zincirinin bir özelliğidir
Bulut platformu birden çok kullanılabilirlik bölgesi, otomatik yedekleme ve merkezi olarak test edilmiş kurtarma sağlayabilir. Şirket içi platform, dış bağlantı arızası sırasında bazı iş akışlarını çalışır durumda tutabilir. Bu ifadelerin hiçbiri dayanıklılığı kanıtlamaz. Bayilerin hizmet düzeyi tanımlarına, olay geçmişine, kurtarma noktası hedeflerine, kurtarma süresi hedeflerine ve geri yükleme testlerinden elde edilen kanıtlara ihtiyacı vardır.
Kritik süreçleri bağımlılığa göre haritalayın. Şube bağlantısı kesildiğinde resepsiyon müşteriyi tanımlayıp iş açabilir mi? Teknisyenler yetkilendirilmiş işi görebilir mi? Satış aracı rezerve edebilir mi? Finans uyumlu bir fatura kesebilir mi? Çevrimdışı prosedür dijital, kâğıt tabanlı veya sonradan eşzamanlanmak üzere kuyruğa alınmış olabilir; ancak sahiplik ve mutabakat bir olay yaşanmadan önce tasarlanmalıdır.
Siber dayanıklılık önemlidir; çünkü fidye yazılımı operasyonel aksamayı veri ifşasıyla birleştirebilir. ENISA'nın 2025 tehdit görünümü 4.875 olayı analiz etti ve şifreleyen fidye yazılımını doğrudan etkili bir tehdit olarak belirledi. Siber suç alt kümesine fidye yazılımı hâkimdi; ancak veri kümesi tüm AB kuruluşlarının bir sayımı değildir. [2] Bu sınırlama korunmalı; rapor bir bayi saldırı olasılığına dönüştürülmemelidir.
4. Güvenlik ve gizlilik paylaşılan sorumluluğu izler
Bulut, tüm hesap verebilirliği bir sağlayıcıya devretmez. Bayi hâlâ birçok işleme amacını belirler, kullanıcıları yönetir, izinleri yapılandırır, entegrasyonları seçer ve müşteri taleplerini işler. GDPR, tasarım ve varsayılan olarak veri koruma ile riskle orantılı teknik ve organizasyonel önlemleri gerektirir. [3] Satın alma; veri sorumlusu ve veri işleyici rollerini, alt işleyicileri, uluslararası aktarımları, silmeyi, yedeklemeleri, günlüklemeyi ve ihlal iş birliğini netleştirmelidir.
Sıfatlar değil kanıt isteyin. İlgili kanıt; bağımsız güvence raporlarını, sertifikasyon kapsamını, güvenlik açığı yönetimi uygulamasını, sızma testi sıklığını, ayrıcalıklı erişim kontrollerini, şifreleme tasarımını, güvenli geliştirmeyi, yedekleme değişmezliğini ve olay prosedürlerini içerebilir. Sertifika titizliği destekleyebilir; ancak yalnızca kapsamındaki sistemler ve dönem için.
Şirket içi dağıtım için aynı sorular dahili operasyonlar ve yerel tedarikçiler için de geçerlidir. Yönetici erişimini kim inceler? Veritabanı ve işletim sistemi bileşenlerini kim yamalar? Yedekleme kimlik bilgileri ayrı mı tutulur? Geri yükleme, üretim kimlik sistemi olmadan yapılabilir mi? Mimari, kontrolleri kimin uyguladığını değiştirir; kontrollere olan ihtiyacı değil.
5. Entegrasyon ve güncelleme sıklığı uzun vadeli değeri şekillendirir
DMS; OEM sistemleri, CRM, araç akışları, muhasebe, ödemeler, kimlik, atölye ekipmanı, web siteleri ve raporlama arasında yer alır. Bulut dağıtımı, merkezi olarak yönetilen API'lerin ve güncellemelerin dağıtımını kolaylaştırabilir. Ancak belgelenmemiş bir API veya ağır biçimde özelleştirilmiş bir yayın süreci, barındırmadan bağımsız olarak zor kalır.
Standartlar faydalı bir hedef sunar. STAR'ın Automotive Retail Domain Model'i operasyonel bayi verileri için ortak yapılar tanımlar ve daha yeni hizmetleri JSON ile OpenAPI uygulamalarıyla hizalar. [4] Yerel mali kuralları, OEM arayüzlerini veya veri eşleştirmesini ortadan kaldırmaz. Ancak iyi bir titizliğin nasıl göründüğünü gösterir: kararlı varlıklar, açık tanımlayıcılar, sürümleme, belgelenmiş hatalar ve test ortamları.
Sağlayıcıdan gerçek bir değişikliği göstermesini isteyin: bir alan ekleme, bir iş akışını güncelleme, kimlik bilgilerini döndürme, başarısız bir arayüzü kurtarma ve bir olayı kaynaktan hedefe kadar izleme. Yaşam döngüsü operasyonlarının kalitesi, lansman günü diyagramından daha önemlidir.
6. Geçiş karar tablosu
| Boyut | İstenecek kanıt | Karar testi |
|---|---|---|
| Kullanılabilirlik | SLA tanımları, olay geçmişi, kurtarma testleri | Kritik şube iş akışları kararlaştırılan kesinti süresini karşılayabilir mi? |
| Güvenlik | Kontrol sahipliği, güvence kapsamı, erişim günlükleri | Kontroller sağlayıcı ve bayi genelinde kanıtlanıyor mu? |
| Entegrasyon | API kataloğu, sürümler, sanal alan, izleme | OEM ve yerel arayüzler güvenle değiştirilebilir mi? |
| Maliyet | Yedi yıllık model, hacim kademeleri, yenileme ve çıkış | Maliyet, gerçekçi büyüme altında öngörülebilir mi? |
| Geçiş | Eşleştirme, mutabakat, paralel çalıştırma, geri alma | Veriler ve operasyonlar nesnel olarak kabul edilebilir mi? |
| Çıkış | Dışa aktarma formatı, zamanlama, destek ve silme | Grup, kullanılabilir geçmişi kaybetmeden taşınabilir mi? |
Aşamalı bir geçiş genellikle temsili bir şubeyle başlar; ancak pilot, karmaşıklıktan kaçınmak yerine onu test etmelidir. İkinci el araç stoğunu, açık iş emirlerini, muhasebe bakiyelerini, belge geçmişini, yinelenen müşterileri ve arayüzleri dahil edin. Dönüşümden önce kabul eşiklerini belirleyin ve toplamları bağımsız olarak mutabık kılın. Paralel çalıştırma riski azaltabilir; ancak uzun süreli çift giriş kendi hatalarını yaratır.
Omnetic'in konumu
Omnetic'in belgelenmiş ürün yönü; CRM, ikinci el araç operasyonları, tedarik, fiyatlandırma, stok içgörüsü ve mobil inceleme genelinde müşteri, araç ve işlem bağlamını birbirine bağlar. Ayrıca aşamalı benimsemeyi destekleyebilecek modüler bir uygulama modeli tanımlar. Bunlar ürün açıklamalarıdır; her modülün, entegrasyonun veya mimarinin her ülkede veya pakette mevcut olduğunun kanıtı değildir.
Bu nedenle sorumlu bir değerlendirme, Omnetic'e diğer sağlayıcılara sorulan aynı soruları sormalıdır: mevcut barındırma ve veri konumları, kullanılabilirlik ve kurtarma kanıtı, API kataloğu, desteklenen OEM arayüzleri, izin modeli, denetim günlüğü, alt işleyiciler, geçiş yaklaşımı ve çıkış formatı. Uygunluk, bayinin içgörüden operasyonel bir aksiyona kadar sürekliliğe değer verdiği durumlarda en güçlüdür; ancak bu uygunluk bayinin gerçek iş akışlarına karşı gösterilmelidir.
Sınırlamalar
Bu rehber evrensel bir ROI hesaplamaz veya her bayi için tek bir mimari önermez. Eurostat rakamları işletmeleri genel olarak kapsar; ENISA olay verileri bayiye özgü bir risk oranı değildir. Yasal yükümlülükler rollere, verilere, ülkeye ve sözleşmeye bağlıdır. Ulusal gereklilikleri doğrulayın ve planlanan dağıtım için hukuk, güvenlik ve muhasebe danışmanlığı alın.
Sık sorulan sorular
Hayır. Toplam maliyeti tanımlı bir dönem boyunca karşılaştırın; buna geçiş, entegrasyonlar, dahili BT, bağlantı, destek, değişiklik talepleri ve çıkış maliyetleri dahildir.
Hayır. Güvenlik; mimariye, kontrollere, yapılandırmaya, operasyonlara, tedarikçilere ve kanıta bağlıdır. Bulut sorumluluk modelini değiştirir; ancak bayinin hesap verebilirliğini ortadan kaldırmaz.
Evet. Arayüzler, veri mutabakatı, eğitim, kabul ölçütleri ve geri alma planları açık olduğunda aşamalı bir uygulama operasyonel riski azaltabilir.
Mimariyi, kullanılabilirlik ve kurtarma hedeflerini, güvenlik kanıtını, veri konumlarını, alt işleyicileri, API belgelerini, geçiş kontrollerini, denetim günlüklerini, destek koşullarını ve bir çıkış planını isteyin.