Cloud-DMS oder On-Premise-DMS: Ein Leitfaden für europäische Autohändler

1. Der Architekturunterschied aus operativer Sicht

Bei einem On-Premise-DMS befinden sich Anwendungsserver, Datenbanken oder beides üblicherweise in Einrichtungen unter Kontrolle des Händlers. Die interne IT oder ein beauftragter Partner wartet Hardware, Betriebssysteme und Sicherungen und steuert die Bereitstellungspläne. Bei einem Cloud-DMS übernimmt ein Dienstleister einen größeren Teil dieser Aufgaben. Benutzer greifen normalerweise über einen Browser oder eine verwaltete Anwendung auf die Plattform zu, während der Anbieter eine gemeinsam genutzte oder dedizierte Cloud-Infrastruktur betreibt.

Die Abgrenzung ist selten absolut. Ein On-Premise-System kann gehostete Portale und Cloud-Sicherungen nutzen. Auch ein Cloud-DMS kann lokale Druckdienste, Schnittstellen zu Werkstattgeräten, Identitätskomponenten oder ein Integrations-Gateway benötigen. Das Beschaffungsteam sollte deshalb die tatsächliche Topologie abbilden: wo Kunden-, Fahrzeug-, Buchhaltungs- und Werkstattdaten verarbeitet werden, welche Komponenten ausfallen können, wer die einzelnen Ebenen aktualisiert und welche Verbindungen für Verkauf, Reparaturauftrag oder Rechnung erforderlich sind.

Die Cloud-Nutzung in Europa liefert Kontext, aber kein abschließendes Urteil für Händler. Laut Eurostat nutzten 2025 52,74 % der EU-Unternehmen kostenpflichtige Cloud-Dienste, gegenüber 45,32 % im Jahr 2023. Die Nutzung reichte von 49,3 % bei kleinen bis 84,67 % bei großen Unternehmen. Zur Cloud-Nutzung zählen jedoch auch einfache E-Mail- und Dateispeicherdienste. Daraus folgt nicht, dass die Hälfte der Händler ein Cloud-natives DMS betreibt. [1]

2. Gesamtkosten vergleichen, nicht Abonnement gegen Hardware

Zu den On-Premise-Kosten gehören üblicherweise Server, Datenbanklizenzen, Virtualisierung, Sicherung, Überwachung, Sicherheitswerkzeuge, Strom, Räumlichkeiten, Hardwareerneuerung und Fachpersonal. Cloud-Kosten umfassen meist Abonnementgebühren, Implementierung, Datenmigration, Umgebungen, Speicher, Nutzungsschwellen, Premium-Support und Integrationsarbeiten. Beide Modelle können außerdem Kosten durch Ausfallzeiten, Schulungen und Prozessneugestaltung verursachen.

Erstellen Sie ein Fünf- bis Siebenjahresmodell mit transparenten Annahmen. Berücksichtigen Sie neue Standorte, saisonale Lasten, Übernahmen, regulatorische Änderungen, Schnittstellenwartung und vertragliche Indexierung. Prüfen Sie, was bei steigenden Transaktionsvolumina, Benutzerzahlen oder API-Aufrufen geschieht. Beziehen Sie die Kosten für den vollständigen Datenexport in nutzbaren Formaten am Vertragsende ein. Ein niedriger Preis im ersten Jahr kann irreführend sein, wenn Integrationen, Umgebungen oder Ausstiegsunterstützung separat berechnet werden.

Das Kostenmodell sollte auch interne Kapazitäten bewerten. Verringert ein Cloud-Dienst routinemäßige Infrastrukturarbeiten, entsteht der Nutzen nur, wenn das Team die frei gewordene Zeit anderweitig einsetzen kann. Verfügt ein Händler dagegen über eine stabile Infrastruktur, spezialisierte Integrationen und qualifizierte Mitarbeiter, kann ein sofortiger Austausch sinnvolle Investitionen vernichten. Ein belastbarer Business Case dokumentiert sowohl vermiedene Kosten als auch neue Abhängigkeiten.

3. Resilienz ist eine Eigenschaft der gesamten Leistungskette

Eine Cloud-Plattform kann mehrere Verfügbarkeitszonen, automatisierte Sicherungen und zentral getestete Wiederherstellung bieten. Eine On-Premise-Plattform kann manche Abläufe bei einem externen Verbindungsausfall weiterführen. Keine dieser Aussagen belegt für sich genommen Resilienz. Händler benötigen Servicelevel-Definitionen, eine Störungshistorie, Wiederherstellungspunkt- und Wiederherstellungszeitziele sowie Nachweise aus Wiederherstellungstests.

Erfassen Sie kritische Abläufe nach ihren Abhängigkeiten. Kann die Annahme bei Ausfall der Filialverbindung einen Kunden identifizieren und einen Auftrag eröffnen? Können Techniker freigegebene Arbeiten sehen? Kann der Verkauf ein Fahrzeug reservieren? Kann die Buchhaltung eine regelkonforme Rechnung ausstellen? Ein Offline-Verfahren kann digital, papiergestützt oder zur späteren Synchronisierung vorgemerkt sein; Verantwortlichkeit und Abstimmung müssen jedoch vor einem Vorfall festgelegt werden.

Cyberresilienz ist wichtig, weil Ransomware Betriebsunterbrechungen mit der Offenlegung von Daten verbinden kann. Die ENISA-Bedrohungsanalyse 2025 untersuchte 4.875 Vorfälle und identifizierte verschlüsselnde Ransomware als Bedrohung mit unmittelbarer Wirkung. Im Teilbereich Cyberkriminalität dominierte Ransomware, wenngleich der Datensatz keine Vollerhebung aller EU-Organisationen darstellt. [2] Diese Einschränkung muss berücksichtigt werden; aus dem Bericht darf keine Angriffswahrscheinlichkeit für Händler abgeleitet werden.

4. Sicherheit und Datenschutz folgen geteilter Verantwortung

Die Cloud überträgt nicht die gesamte Verantwortung auf einen Anbieter. Der Händler bestimmt weiterhin zahlreiche Verarbeitungszwecke, verwaltet Benutzer, konfiguriert Berechtigungen, wählt Integrationen aus und bearbeitet Kundenanfragen. Die DSGVO verlangt Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen sowie dem Risiko angemessene technische und organisatorische Maßnahmen. [3] Die Beschaffung sollte die Rollen von Verantwortlichem und Auftragsverarbeiter, Unterauftragsverarbeiter, internationale Übermittlungen, Löschung, Sicherungen, Protokollierung und Zusammenarbeit bei Datenschutzverletzungen klären.

Verlangen Sie Nachweise statt beschreibender Behauptungen. Relevante Nachweise können unabhängige Prüfberichte, den Zertifizierungsumfang, Verfahren des Schwachstellenmanagements, den Turnus von Penetrationstests, Kontrollen privilegierter Zugriffe, das Verschlüsselungskonzept, sichere Entwicklung, unveränderliche Sicherungen und Störungsverfahren umfassen. Ein Zertifikat kann die Sorgfaltsprüfung unterstützen, jedoch nur für die Systeme und den Zeitraum innerhalb seines Geltungsbereichs.

Bei einer On-Premise-Bereitstellung gelten dieselben Fragen für interne Abläufe und lokale Lieferanten. Wer prüft Administratorzugriffe? Wer aktualisiert Datenbank- und Betriebssystemkomponenten? Sind Zugangsdaten für Sicherungen getrennt? Ist eine Wiederherstellung ohne das produktive Identitätssystem möglich? Die Architektur verändert, wer Kontrollen durchführt, nicht deren Notwendigkeit.

5. Integration und Aktualisierungsrhythmus bestimmen den langfristigen Wert

Ein DMS verbindet OEM-Systeme, CRM, Fahrzeugdatenquellen, Buchhaltung, Zahlungen, Identität, Werkstattausrüstung, Websites und Reporting. Eine Cloud-Bereitstellung kann die Verteilung zentral verwalteter APIs und Aktualisierungen erleichtern. Eine undokumentierte API oder ein stark angepasster Veröffentlichungsprozess bleibt jedoch unabhängig vom Hosting schwierig.

Standards geben ein sinnvolles Ziel vor. Das Automotive Retail Domain Model von STAR definiert gemeinsame Strukturen für operative Autohausdaten und richtet neuere Dienste an JSON- und OpenAPI-Verfahren aus. [4] Es beseitigt weder lokale Fiskalregeln noch OEM-Schnittstellen oder Datenzuordnungen. Es zeigt jedoch, worauf eine gute Sorgfaltsprüfung achtet: stabile Entitäten, eindeutige Kennungen, Versionierung, dokumentierte Fehler und Testumgebungen.

Lassen Sie den Anbieter eine reale Änderung vorführen: ein Feld hinzufügen, einen Ablauf aktualisieren, Zugangsdaten wechseln, eine ausgefallene Schnittstelle wiederherstellen und ein Ereignis von der Quelle bis zum Ziel nachverfolgen. Die Qualität des laufenden Betriebs ist wichtiger als ein Diagramm zum Einführungszeitpunkt.

6. Entscheidungstabelle für die Migration

Eine schrittweise Migration beginnt häufig mit einer repräsentativen Filiale. Der Pilot muss die Komplexität jedoch prüfen, statt sie zu vermeiden. Beziehen Sie Gebrauchtwagenbestand, offene Reparaturaufträge, Buchhaltungssalden, Dokumentenhistorie, Kundendubletten und Schnittstellen ein. Legen Sie Abnahmeschwellen vor der Umstellung fest und gleichen Sie Summen unabhängig ab. Ein Parallelbetrieb kann Risiken reduzieren; eine langwierige doppelte Dateneingabe verursacht jedoch eigene Fehler.

Wo Omnetic einzuordnen ist

Die dokumentierte Produktausrichtung von Omnetic verbindet Kunden-, Fahrzeug- und Geschäftskontext über CRM, Gebrauchtwagenbetrieb, Beschaffung, Preisgestaltung, Bestandsinformationen und mobile Begutachtung hinweg. Zudem beschreibt Omnetic ein modulares Implementierungsmodell, das eine schrittweise Einführung unterstützen kann. Dies sind Produktbeschreibungen und kein Nachweis dafür, dass jedes Modul, jede Integration oder jede Architektur in jedem Land oder Paket verfügbar ist.

Eine verantwortungsvolle Bewertung sollte Omnetic daher dieselben Fragen stellen wie jedem anderen Anbieter: aktuelles Hosting und Datenstandorte, Nachweise zu Verfügbarkeit und Wiederherstellung, API-Katalog, unterstützte OEM-Schnittstellen, Berechtigungsmodell, Audit-Protokollierung, Unterauftragsverarbeiter, Migrationsansatz und Ausstiegsformat. Die Eignung ist dort am größten, wo ein Händler Wert auf Kontinuität von der Erkenntnis bis zur operativen Maßnahme legt; sie muss jedoch anhand der realen Abläufe des Händlers nachgewiesen werden.