Der Kern des Problems ist einfach zu beschreiben: Ein Onlineshop ist ein Verkaufsfrontend. Er präsentiert Produkte, nimmt Bestellungen entgegen und wickelt die Bezahlung an. Was danach passiert — Auftrag prüfen, Ware kommissionieren, Bestand fortschreiben, Rechnung erzeugen, Versand beauftragen, Retoure verbuchen, Umsatz in die Buchhaltung übergeben — ist kein Shop-Thema mehr, sondern klassische Warenwirtschaft. Genau diese Lücke füllt ein ERP-System (Enterprise Resource Planning): Es ist die zentrale Datendrehscheibe und Prozesssteuerung des Unternehmens, in der Artikel, Kunden, Bestände, Aufträge und Finanzdaten zusammenlaufen.
Ohne diese Drehscheibe entstehen im wachsenden Handel typische Reibungsverluste. Bestände werden doppelt gepflegt und driften auseinander, Aufträge werden manuell aus dem Shop in die Warenwirtschaft übertragen, Preise stehen an verschiedenen Stellen unterschiedlich, und am Monatsende gleicht niemand mehr zuverlässig ab, was verkauft, geliefert und bezahlt wurde. Jede dieser Bruchstellen kostet Zeit, produziert Fehler und wird mit jedem zusätzlichen Kanal schlimmer. Ein ERP setzt an genau diesen Bruchstellen an, indem es einen einzigen, verbindlichen Datenstand schafft.
Die saubere Abgrenzung zwischen Shopsystem und ERP ist der wichtigste konzeptionelle Schritt. Ein modernes Shopsystem ist stark in allem, was mit Präsentation und Kaufabschluss zu tun hat: ansprechende Produktseiten, Suche und Filter, Warenkorb, Checkout, Kundenkonten, Marketing- und SEO-Funktionen. Manche Shops bringen auch rudimentäre Lager- oder Bestellverwaltung mit — die aber selten für den ernsthaften, mehrkanaligen Betrieb ausgelegt ist.
Das ERP dagegen ist das operative und kaufmännische Rückgrat. Hier liegen die führenden Stammdaten (welcher Artikel existiert, was kostet er, welche Varianten gibt es), der verbindliche Lagerbestand über alle Kanäle hinweg, die Auftragsabwicklung von der Bestellung bis zur Rechnung, das Bestellwesen gegenüber Lieferanten und die Anbindung an die Finanzbuchhaltung. Vereinfacht gilt: Der Shop ist das Schaufenster, das ERP ist Lager, Kasse, Büro und Buchhaltung dahinter. Beide sind nötig, aber sie erfüllen unterschiedliche Aufgaben — und die Kunst liegt darin, sie sauber zu verbinden, statt Funktionen doppelt vorzuhalten.
Nicht jeder Onlinehändler braucht sofort ein ERP. Der sinnvolle Einstiegszeitpunkt ist weniger eine feste Umsatzgröße als ein Bündel von Anzeichen. Kommen mehrere davon zusammen, wird die Anschaffung meist wirtschaftlich: mehrere Verkaufskanäle (eigener Shop plus ein oder mehrere Marktplätze), ein wachsendes Sortiment mit Varianten, steigende Bestellmengen, die manuell nicht mehr sauber zu bewältigen sind, wiederkehrende Bestandsfehler und Überverkäufe sowie ein zunehmender Aufwand in der Buchhaltung durch manuelle Übertragungen. Wer diese Symptome bei sich erkennt, betreibt faktisch bereits eine Warenwirtschaft — nur eben verteilt, manuell und fehleranfällig.
Dieser Beitrag betrachtet das Thema bewusst herstellerneutral und konzeptionell, nicht als Produktvorstellung. Er erklärt die Kernprozesse eines E-Commerce-ERP (Kapitel 02), die Integrationsszenarien zwischen Shop, Marktplatz und ERP (Kapitel 03), die Datenflüsse und Automatisierung (Kapitel 04), Fulfillment und Omnichannel (Kapitel 05), die Auswahlkriterien für ein E-Commerce-taugliches System (Kapitel 06), Einführung und Betrieb (Kapitel 07), die Praxis im Mittelstand mit Skalierung und Lastspitzen (Kapitel 08), Kosten sowie Datenschutz und Datenhoheit (Kapitel 09) und häufige Fragen (Kapitel 10). Ziel ist eine belastbare Entscheidungsgrundlage.
Der zentrale Prozess beginnt mit dem Auftrag. Sobald im Shop oder auf einem Marktplatz eine Bestellung eingeht, wird sie ins ERP übernommen, dort geprüft (Verfügbarkeit, Zahlungsstatus, Plausibilität) und zur Bearbeitung freigegeben. Aus dem Auftrag entsteht der Lagerauftrag: Die Ware wird kommissioniert, verpackt und für den Versand bereitgestellt. Parallel schreibt das System den Lagerbestand fort, sodass der verfügbare Bestand jederzeit stimmt und in alle angebundenen Kanäle zurückgespielt werden kann.
Der Versand schließt die Kette: Das ERP erzeugt Lieferschein und Versandetikett, übergibt die Sendungsdaten an den Paketdienstleister und stellt die Sendungsverfolgung bereit — im Idealfall automatisch, sodass der Kunde ohne manuelles Zutun eine Versandbestätigung mit Tracking erhält. Diese drei Schritte — Auftrag, Lager, Versand — sind das Herzstück jeder Handelsabwicklung. Ihr Wert entsteht nicht aus einem einzelnen Schritt, sondern daraus, dass sie ohne Medienbruch ineinandergreifen und auf demselben Datenstand arbeiten.
Retouren sind im Onlinehandel kein Sonderfall, sondern Alltag — und ein Prozess, der ohne ERP-Unterstützung schnell chaotisch wird. Eine saubere Retourenabwicklung erfasst die Rücksendung, prüft und bewertet die Ware, bucht sie wieder in den Bestand (oder aus, wenn sie defekt ist), und stößt die Rückerstattung an. Das ERP hält dabei den Bezug zum ursprünglichen Auftrag und sorgt dafür, dass Bestand, Umsatz und offene Posten korrekt fortgeschrieben werden.
Bei den Zahlungen geht es darum, die im Shop oder über einen Zahlungsdienstleister erfassten Zahlungseingänge mit den Aufträgen abzugleichen. Das ERP verwaltet den Zahlungsstatus (offen, bezahlt, teilbezahlt, erstattet) und liefert die Grundlage für Mahnwesen und offene-Posten-Verwaltung. Am Ende der Kette steht die Buchhaltung: Rechnungen, Gutschriften, Umsätze und Zahlungseingänge werden strukturiert an die Finanzbuchhaltung übergeben — entweder in ein integriertes Buchhaltungsmodul oder über eine Schnittstelle an eine externe Buchhaltungslösung oder den Steuerberater. Erst diese Anbindung schließt den Kreis vom Verkauf bis zum verbuchten Umsatz.
Jeder dieser Prozesse ließe sich isoliert auch mit einem Einzelwerkzeug abbilden. Der eigentliche Nutzen entsteht jedoch erst, wenn sie auf einem gemeinsamen Datenstand zusammenspielen. Ein Beispiel verdeutlicht das: Verkauft der Shop einen Artikel, der zugleich der letzte auf einem Marktplatz gelistete ist, muss der Bestand in Echtzeit über alle Kanäle sinken — sonst kommt es zum Überverkauf. Verbucht das ERP zugleich Umsatz und Zahlungsstatus, ist der Monatsabschluss keine mühsame Rekonstruktion mehr, sondern ein Knopfdruck. Diese Durchgängigkeit ist der Grund, warum ein ERP im wachsenden E-Commerce mehr ist als die Summe seiner Module.
Der einfachste Fall ist die direkte Schnittstelle: ERP und Shop werden über einen fertigen Connector oder ein Plugin unmittelbar verbunden. Das ist schnell eingerichtet, wenn beide Systeme füreinander vorbereitet sind, und für einen einzelnen Kanal oft völlig ausreichend. Der Nachteil zeigt sich bei mehreren Kanälen: Jede Punkt-zu-Punkt-Verbindung muss einzeln gepflegt werden, und die Zahl der Verbindungen wächst mit jedem zusätzlichen System.
Hier kommt Middleware ins Spiel — eine Vermittlungsschicht zwischen ERP und den Kanälen. Statt jeden Shop und Marktplatz direkt mit dem ERP zu koppeln, laufen alle Verbindungen über eine zentrale Integrationsplattform, die Daten übersetzt, transformiert und verteilt. Der Vorteil ist Übersicht und Wartbarkeit: Neue Kanäle werden an die Middleware angebunden, nicht an das ERP selbst. Der Preis ist ein zusätzliches System, das eingerichtet, betrieben und bezahlt werden will. Für Händler mit vielen Kanälen und komplexen Datenregeln ist dieser Weg dennoch oft der wirtschaftlichere.
Ein dritter, zunehmend verbreiteter Weg sind standardisierte APIs: Moderne ERP- und Shopsysteme stellen offene, dokumentierte Programmierschnittstellen bereit, über die sich Daten strukturiert austauschen lassen. Sie sind die technische Grundlage sowohl für direkte Anbindungen als auch für Middleware und erlauben individuelle Integrationen, wenn Standard-Connectoren nicht ausreichen. Je offener und besser dokumentiert die API eines Systems ist, desto flexibler und zukunftssicherer ist die Integration.
Die Anbindung an Marktplätze unterscheidet sich in wichtigen Punkten von der reinen Shop-Anbindung. Marktplätze geben eigene Regeln, Datenformate und Prozesse vor: Wie Artikel gelistet werden, wie Preise und Bestände gemeldet werden, wie Bestellungen abgerufen und Versandinformationen zurückgemeldet werden. Ein ERP, das im Marktplatzgeschäft mithalten soll, muss diese kanalspezifischen Eigenheiten beherrschen — direkt oder über eine spezialisierte Anbindung.
Hinzu kommt, dass jeder Marktplatz seine eigenen Anforderungen an Datenqualität und Aktualität stellt. Bestände müssen zeitnah gemeldet werden, um Überverkäufe und Vertragsstrafen zu vermeiden; Produktdaten müssen den jeweiligen Katalogvorgaben entsprechen. Genau hier zahlt sich eine zentrale Datenhaltung im ERP aus: Ein gepflegter Stammdatensatz kann kanalspezifisch aufbereitet und an mehrere Marktplätze zugleich ausgespielt werden, statt jeden Kanal einzeln zu pflegen.
Eine grobe Orientierung: Wer nur einen Shop betreibt und beim Standard bleibt, fährt mit einer direkten Schnittstelle oder einem fertigen Connector meist am wirtschaftlichsten. Sobald mehrere Kanäle, viele Artikel oder komplexe Datenregeln ins Spiel kommen, wird eine Middleware oder eine API-basierte Integration attraktiver, weil sie die wachsende Komplexität bändigt. Entscheidend ist, diesen Weg bewusst zu wählen und nicht durch das schrittweise Ankoppeln immer neuer Punkt-zu-Punkt-Verbindungen in einen kaum noch wartbaren Wildwuchs zu geraten. Die Integrationsarchitektur ist eine strategische Entscheidung, keine technische Nebensache.
Der wichtigste konzeptionelle Grundsatz lautet: Für jede Datenart muss ein führendes System festgelegt sein. Beim Bestand ist das in aller Regel das ERP — es kennt den verbindlichen, physisch verfügbaren Bestand und spielt ihn an alle Kanäle aus. Fließt der Bestand aus mehreren Quellen unkoordiniert zusammen, sind Widersprüche und Überverkäufe programmiert. Der Bestandsabgleich sollte deshalb zeitnah und in eine klare Richtung laufen: vom ERP zu den Kanälen.
Bei den Preisen ist die Lage oft differenzierter. Grundpreise und Kalkulation liegen typischerweise im ERP, doch kanalspezifische Preise, Aktionen oder Marktplatzregeln können Abweichungen erfordern. Hier ist zu entscheiden, ob Preise zentral im ERP gepflegt und ausgespielt werden oder ob einzelne Kanäle eigene Preislogiken behalten. Bei den Aufträgen ist die Richtung meist umgekehrt: Sie entstehen im Shop oder Marktplatz und fließen ins ERP, das sie abwickelt und Statusmeldungen (versandt, storniert, erstattet) zurückgibt. Diese Rückrichtung ist genauso wichtig wie der Auftragsimport — sie hält den Kunden informiert und die Kanäle konsistent.
Der wirtschaftliche Kern eines E-Commerce-ERP ist die Automatisierung wiederkehrender Abläufe. Bestellungen werden ohne manuelles Abtippen importiert, Bestände automatisch synchronisiert, Rechnungen und Versandlabels regelbasiert erzeugt, Versandbestätigungen automatisch verschickt und Umsätze automatisch an die Buchhaltung übergeben. Jeder dieser automatisierten Schritte spart nicht nur Zeit, sondern eliminiert eine Fehlerquelle: Was nicht manuell übertragen wird, kann auch nicht vertippt, vergessen oder verwechselt werden.
Wichtig ist ein realistisches Verständnis von Automatisierung. Sie ersetzt nicht das Denken, sondern die Routine. Regeln, Ausnahmen und Sonderfälle müssen einmal sauber definiert werden, damit die Automatik verlässlich läuft; Fehlerfälle brauchen eine klare Eskalation, damit sie nicht unbemerkt durchrutschen. Gut umgesetzte Automatisierung ist deshalb kein Selbstläufer, sondern das Ergebnis sauber durchdachter Prozesse — mit dem Lohn, dass das Team sich auf Ausnahmen und Wachstum statt auf Fließbandarbeit konzentrieren kann.
Automatisierung ist nur so gut wie die Daten, auf denen sie arbeitet. Fehlerhafte oder inkonsistente Stammdaten — falsche Maße und Gewichte, uneinheitliche Artikelnummern, unvollständige Produktattribute — pflanzen sich durch die gesamte automatisierte Kette fort und tauchen als falsches Versandlabel, abgelehntes Marktplatz-Listing oder fehlerhafte Rechnung wieder auf. Wer Automatisierung ernst nimmt, investiert deshalb zuerst in saubere, zentral gepflegte Stammdaten im ERP. Diese Investition ist unsichtbar und undankbar, aber sie entscheidet darüber, ob die Automatik entlastet oder neue Probleme produziert.
Für die physische Abwicklung gibt es unterschiedliche Modelle, die ein E-Commerce-ERP abbilden können sollte. Beim eigenen Lager steuert das ERP Wareneingang, Einlagerung, Kommissionierung und Versand direkt und führt den Bestand in Echtzeit. Beim Fulfillment durch einen Dienstleister (Logistikpartner oder Fulfillment-Center) übernimmt ein externer Partner die physische Abwicklung; das ERP tauscht dann Aufträge, Bestände und Statusmeldungen mit dem Dienstleister aus, statt selbst zu kommissionieren. Beim Streckengeschäft (Dropshipping) liefert der Lieferant direkt an den Endkunden — das ERP koordiniert Bestellung, Weiterleitung an den Lieferanten und die Rückmeldung, hält aber keinen eigenen Bestand.
Diese Modelle schließen sich nicht aus; viele Händler kombinieren sie. Entscheidend ist, dass das ERP alle genutzten Modelle sauber abbildet und einen konsolidierten Blick auf Bestände und Aufträge behält, egal wo die Ware physisch liegt. Genau diese Konsolidierung verhindert, dass ein hybrides Fulfillment im Datenchaos endet.
Omnichannel beschreibt die Idee, dass Kunden über verschiedene Kanäle hinweg eine zusammenhängende Erfahrung erleben — online, mobil, auf Marktplätzen und, wo vorhanden, im stationären Handel. Für das ERP bedeutet das vor allem eine Anforderung: einen einheitlichen, kanalübergreifenden Blick auf Bestand, Kunde und Auftrag. Nur wenn alle Kanäle auf denselben Bestand und dieselbe Auftragshistorie zugreifen, lassen sich Szenarien wie kanalübergreifende Verfügbarkeitsanzeigen, das Abholen online bestellter Ware im Laden oder das Zurückgeben eines Onlinekaufs im Geschäft überhaupt sauber umsetzen.
Der Anspruch von Omnichannel ist leicht formuliert, aber anspruchsvoll umzusetzen, weil er die Datenkonsistenz auf die Spitze treibt: Ein Artikel, der im Laden verkauft wird, muss sofort auch online als nicht mehr verfügbar erscheinen. Das ERP ist der einzige sinnvolle Ort, an dem dieser gemeinsame Wahrheitsstand zusammenläuft. Ob ein Mittelständler den vollen Omnichannel-Anspruch braucht, ist eine Frage des Geschäftsmodells — die technische Voraussetzung dafür ist jedoch immer dieselbe zentrale Datendrehscheibe.
Fulfillment ist der Bereich, der bei Wachstum am schnellsten an Grenzen stößt. Was bei fünfzig Bestellungen am Tag manuell funktioniert, bricht bei fünfhundert zusammen. Ein tragfähiges E-Commerce-ERP unterstützt deshalb Abläufe, die mit steigenden Mengen mitwachsen: Sammelverarbeitung von Aufträgen, effiziente Kommissionierstrategien, klare Priorisierung und die Anbindung mehrerer Versanddienstleister. Ob diese Funktionen im Einzelfall gebraucht werden, hängt vom Volumen ab — dass die Abwicklung aber der erste Engpass des Wachstums ist, gilt nahezu durchgängig.
Einige Fähigkeiten trennen ein handelstaugliches ERP von einem allgemeinen Warenwirtschaftssystem. Ganz oben steht die Integrationsfähigkeit: verfügbare Connectoren zu den relevanten Shop- und Marktplatzsystemen sowie eine offene, gut dokumentierte API. Ebenso wichtig ist eine mehrkanalfähige Bestands- und Auftragsverwaltung, die Bestände über alle Kanäle konsolidiert und Aufträge aus verschiedenen Quellen einheitlich abwickelt. Hinzu kommen ein robustes Retouren- und Zahlungsmanagement, eine saubere Buchhaltungsanbindung (etwa der Weg zum Steuerberater über gängige Formate) und Funktionen für Varianten, Attribute und Produktdaten, wie sie der Onlinehandel braucht.
Darüber hinaus lohnt der Blick auf Skalierbarkeit und Automatisierung: Kann das System steigende Mengen und Kanäle verkraften, und lassen sich wiederkehrende Abläufe regelbasiert automatisieren? Diese Fragen entscheiden darüber, ob das ERP mit dem Geschäft mitwächst oder nach zwei Jahren selbst zum Engpass wird.
Zwei grundsätzliche Weichenstellungen prägen die Auswahl. Die erste betrifft das Betriebsmodell: Ein Cloud-ERP senkt den eigenen Betriebsaufwand, bringt planbare laufende Kosten und ist für viele wachsende Onlinehändler der naheliegende Weg; On-Premise bietet mehr Kontrolle und Datenhoheit, verlangt aber eigene IT-Ressourcen. Die zweite Weichenstellung betrifft den Zuschnitt: Es gibt auf E-Commerce spezialisierte ERP-Systeme, die Handelsprozesse und Kanalanbindung von Haus aus stark abdecken, und generalistische ERP-Systeme, die breiter aufgestellt sind und E-Commerce über Module oder Erweiterungen abbilden. Welche Richtung passt, hängt vom Geschäftsmodell ab — ein reiner Onlinehändler wählt anders als ein Produktionsbetrieb mit ergänzendem Shop.
Die häufigste Fehlerquelle bei der ERP-Auswahl ist das Vorgehen selbst: Systeme werden anhand von Demos, Funktionslisten oder Empfehlungen ausgewählt, ohne die eigenen Anforderungen vorher sauber zu erheben. Ein tragfähiger Prozess dreht die Reihenfolge um. Zuerst werden die eigenen Prozesse, Kanäle, Mengen und Wachstumsziele beschrieben; daraus entsteht ein Anforderungskatalog mit klaren Muss- und Kann-Kriterien. Erst dann werden Systeme dagegen bewertet, idealerweise anhand konkreter, an den eigenen Prozessen orientierter Szenarien statt allgemeiner Präsentationen. So wird aus der Auswahl eine begründete Entscheidung — und nicht das Ergebnis des überzeugendsten Verkaufsgesprächs.
Bewährt hat sich ein strukturiertes, phasenweises Vorgehen statt eines Big-Bang-Umstiegs, bei dem alles auf einmal umgestellt wird. Am Anfang steht die Analyse: die eigenen Prozesse aufnehmen, den Anforderungskatalog schärfen, die Integrationsarchitektur festlegen. Es folgt die Datenmigration und -bereinigung — erfahrungsgemäß der unterschätzte Aufwand, weil gewachsene Stammdaten selten so sauber sind, wie man annimmt. Danach werden Konfiguration, Anbindungen und Automatisierungsregeln aufgesetzt, ausgiebig getestet und die Anwender geschult. Der Produktivstart wird von einer Stabilisierungsphase begleitet, in der auflaufende Fehler schnell behoben und Abläufe nachjustiert werden.
Ein ERP-Projekt verändert Arbeitsweisen — und Menschen reagieren auf Veränderung mit Skepsis. Erfolgreiche Einführungen binden die Fachbereiche früh ein, machen den Nutzen greifbar und benennen klare Verantwortliche für Prozesse und Daten. Externe Unterstützung kann viel abnehmen, aber nicht das Prozesswissen und die Entscheidungen. Wer im Alltagsgeschäft keine Kapazitäten für das Projekt freistellt, riskiert Verzögerungen, schlechte Datenqualität und Akzeptanzprobleme nach dem Start. Diese personelle Realität gehört an den Anfang der Planung, nicht ans Ende.
Mit dem Go-live beginnt der Dauerbetrieb, und der hat eigene Anforderungen. Schnittstellen müssen überwacht werden, denn eine ausgefallene Anbindung fällt im Onlinehandel schnell und teuer auf. Neue Kanäle, geänderte Marktplatzregeln oder Software-Updates verlangen laufende Pflege. Und die Datenqualität, einmal hergestellt, muss dauerhaft gehalten werden. Ein ERP im E-Commerce ist damit weniger ein Projekt mit Enddatum als eine dauerhafte Infrastruktur, die betreut werden will — ein Punkt, der bei der Ressourcen- und Kostenplanung oft zu kurz kommt.
Viele mittelständische Onlinehändler durchlaufen ein typisches Muster. Zunächst wird der Handel mit Bordmitteln bewältigt: der Shop, ein paar Tabellen, viel Handarbeit. Das funktioniert erstaunlich lange — bis Kanäle, Artikel und Mengen einen Punkt erreichen, an dem die Handarbeit kippt. Bestandsfehler häufen sich, die Buchhaltung wird zur Nachtarbeit, und das Team verbringt mehr Zeit mit Datenpflege als mit dem Geschäft. Genau an diesem Punkt wird das ERP vom Nice-to-have zur Voraussetzung für weiteres Wachstum. Der Umstieg fällt vielen schwer, weil er mitten im laufenden Betrieb erfolgt — anders als beim Neustart auf der grünen Wiese muss das fahrende Auto umgebaut werden.
Die Lehre daraus ist, den Umstieg nicht bis zum Zusammenbruch aufzuschieben. Wer die Anzeichen früh erkennt (siehe Kapitel 01) und das ERP einführt, solange noch Luft im System ist, hat einen ruhigeren Übergang als jemand, der erst reagiert, wenn nichts mehr geht. Skalierung ist planbar — aber nur, wenn man sie vor dem Engpass angeht.
Eine Besonderheit des E-Commerce sind Lastspitzen: Aktionstage, saisonale Höhepunkte wie das Weihnachtsgeschäft oder virale Effekte können das Bestellaufkommen kurzfristig vervielfachen. Ein System, das im Normalbetrieb reibungslos läuft, kann an solchen Tagen an Grenzen stoßen — sei es bei der Verarbeitungsgeschwindigkeit, der Bestandssynchronisation oder der Abwicklungskapazität im Lager. Für den Mittelstand ist das eine reale Herausforderung, weil die Peaks über einen großen Teil des Jahresumsatzes entscheiden können.
Ein E-Commerce-taugliches ERP sollte deshalb nicht nur den Durchschnitt, sondern die Spitze verkraften. Cloud-basierte Systeme haben hier oft den Vorteil, dass sie kurzfristig mehr Leistung bereitstellen können. Wichtiger als jede Technik ist jedoch die Vorbereitung: Prozesse für Hochlast durchspielen, Engpässe vorher identifizieren, Automatisierung so auslegen, dass sie unter Last stabil bleibt, und mit den beteiligten Partnern (Logistik, Zahlungsdienstleister, Marktplätze) die Spitzen abstimmen. Wer die Peaks erst am Aktionstag entdeckt, hat schon verloren.
Der Mittelstand unterschätzt häufig zweierlei: den internen Aufwand einer Einführung und die Dauer, bis sich der Nutzen einstellt. Ein ERP entfaltet seinen Wert nicht am Tag des Go-live, sondern wenn Prozesse eingespielt, Daten sauber und Automatisierungen etabliert sind — das braucht Zeit. Umgekehrt sollte man den Nutzen auch nicht kleinreden: Wenn die Kette einmal läuft, verschiebt sich der Alltag spürbar von manueller Datenpflege hin zu wertschöpfender Arbeit, und Wachstum wird ohne proportional wachsende Handarbeit möglich. Diese Perspektive — nüchtern in Aufwand und Nutzen — hilft, das Projekt weder zu überschätzen noch zu unterschätzen.
Der häufigste Kalkulationsfehler besteht darin, die Lizenz- oder Abokosten für die Gesamtkosten zu halten. Tatsächlich setzt sich die Investition aus mehreren Blöcken zusammen, deren Verhältnis stark vom Einzelfall abhängt. Zu den einmaligen Projektkosten zählen Beratung und Konzeption, Datenmigration und -bereinigung, die Einrichtung der Integrationen, Schulung und die Stabilisierung nach dem Go-live. Zu den laufenden Kosten gehören Lizenz- oder Abogebühren, gegebenenfalls Kosten für Middleware und Connectoren, Wartung und Support sowie interne Betriebsressourcen. Konkrete Beträge lassen sich nicht seriös pauschalisieren — sie hängen von Systemwahl, Kanalzahl, Integrationsweg und Anpassungstiefe ab und sind im Einzelfall zu prüfen.
Wichtiger als eine Zahl ist das Verständnis der Struktur: Die reine Software ist oft der kleinere Posten, während Integration, Datenaufbereitung und die internen Personalkosten den Aufwand dominieren. Interne Kosten tauchen in keinem Angebot auf, sind aber real — die Zeit, die Fachbereiche in Konzeption, Test und Datenpflege stecken, ist ein echter Aufwand. Eine belastbare Kostenrechnung macht diese unsichtbaren Blöcke sichtbar und betrachtet die Gesamtkosten über mehrere Jahre, nicht nur den Einstiegspreis.
Ein E-Commerce-ERP verarbeitet in erheblichem Umfang personenbezogene Daten: Kundenstammdaten, Bestellhistorien, Liefer- und Rechnungsadressen und — je nach Konstellation — Informationen mit Bezug zu Zahlungen. Damit fällt es klar in den Anwendungsbereich der Datenschutz-Grundverordnung, und der Umgang mit diesen Daten will von Beginn an sauber geregelt sein. Die folgenden Punkte sind eine praxisorientierte Orientierung und ausdrücklich keine Rechtsberatung — die verbindliche Bewertung gehört in die Hände der eigenen Datenschutz- und Rechtsverantwortlichen.
Besondere Aufmerksamkeit verdienen die Zahlungsdaten. In der Regel ist es sinnvoll, sensible Zahlungsinformationen nicht im ERP zu speichern, sondern beim spezialisierten Zahlungsdienstleister zu belassen und im ERP nur die für die Abwicklung nötigen Statusinformationen zu führen. Das reduziert Risiko und Aufwand. Ebenso wichtig ist die Frage der Datenhoheit über die Kette hinweg: Sobald Daten zwischen ERP, Shop, Marktplätzen, Middleware und Fulfillment-Dienstleistern fließen, ist zu klären, wer welche Daten verarbeitet und auf welcher vertraglichen Grundlage. Diese Verantwortungskette sichtbar zu machen und vertraglich zu regeln, ist Teil eines seriösen Datenschutz-Setups.
Der praktische Rat lautet: Datenschutz nicht als lästige Nachbearbeitung, sondern als festen Bestandteil der Systemauswahl und -einführung behandeln. Wer Datenstandort, AVV, Berechtigungen und Löschkonzepte von Anfang an mitdenkt, vermeidet teure Nachbesserungen und schafft Vertrauen bei den Kunden — deren Daten das eigentliche Kapital eines Onlinehändlers sind. Die verbindliche rechtliche Bewertung bleibt dabei stets Sache der zuständigen Fachleute.
