ERP-Systeme im Überblick

ERP-Systeme gibt es in vielen Ausprägungen – von der breiten Standardsoftware bis zur Branchenlösung, als Cloud-Dienst oder im eigenen Rechenzentrum. Dieser Überblick hilft, die Typen zu unterscheiden und systematisch zu vergleichen.

Welche Arten von ERP-Systemen gibt es?

ERP-Systeme lassen sich nach mehreren Dimensionen einteilen. Für die Vorauswahl sind vor allem drei relevant: das Betriebsmodell, der Spezialisierungsgrad und die Zielgröße der Unternehmen.

Cloud vs. On-Premise

Die wohl wichtigste Grundsatzentscheidung. Beim Cloud-ERP betreibt der Anbieter die Software in seinem Rechenzentrum; Sie zahlen nutzungsabhängig und greifen über den Browser zu. Beim On-Premise-Betrieb läuft das System auf eigener oder gemieteter Infrastruktur unter eigener Kontrolle.

Beide Modelle haben ihre Berechtigung. Der Trend geht klar in Richtung Cloud, doch für stark individualisierte Prozesse oder besondere Anforderungen an die Datenhaltung bleibt On-Premise relevant.

Generalist oder Branchenlösung?

Ein generalistisches ERP-System deckt viele Branchen breit ab und ist flexibel anpassbar. Eine Branchenlösung bringt typische Prozesse einer Branche – etwa Handel, Fertigung oder Dienstleistung – bereits mit und reduziert so den Anpassungsaufwand. Je spezifischer Ihre Abläufe, desto eher lohnt eine Branchenlösung.

Bekannte ERP-Systeme

Zu den im Mittelstand verbreiteten Systemen zählen unter anderem SAP Business One und S/4HANA, Microsoft Dynamics 365 Business Central (vormals Navision), Odoo (vormals OpenERP), Sage, Oracle NetSuite sowie zahlreiche deutsche Anbieter wie Abas, proALPHA oder myfactory. Eine Auflistung gängiger Produkte finden Sie unter ERP-Programme.

So vergleichen Sie ERP-Systeme

• Funktionsabdeckung gegen das eigene Lastenheft prüfen.
• Branchenfit und Referenzen ähnlicher Unternehmen bewerten.
• Integration in vorhandene Systeme (Shop, DATEV, Versand) klären.
• Gesamtkosten (TCO) über 3–5 Jahre rechnen.
• Zukunftssicherheit: Roadmap, Verbreitung und Support des Anbieters.

Architektur: Monolith, modular oder Best-of-Breed

Neben Betriebsmodell und Spezialisierung unterscheiden sich ERP-Systeme auch in ihrer technischen Architektur – ein Aspekt, der die spätere Flexibilität stark beeinflusst. Klassische monolithische Systeme bilden alle Funktionen in einem geschlossenen Block ab; das sorgt für enge Integration, macht Änderungen aber aufwendiger. Modulare Systeme bestehen aus klar getrennten Bausteinen, die sich einzeln aktivieren und kombinieren lassen, sodass ein Unternehmen klein starten und bei Bedarf erweitern kann. Beim Best-of-Breed-Ansatz schließlich wird für jeden Bereich die jeweils beste Spezialsoftware gewählt und über Schnittstellen verbunden – das bietet maximale Funktionstiefe, erhöht aber den Integrationsaufwand und die Zahl der Wartungsverträge.

Für die meisten mittelständischen Unternehmen ist ein modulares Standardsystem der pragmatische Mittelweg: Es vereint eine solide Integration mit der Möglichkeit, gezielt Spezialfunktionen über zertifizierte Erweiterungen zu ergänzen. Wichtig ist, beim Vergleich nicht nur auf die heutigen Anforderungen zu schauen, sondern auch auf die Ausbaufähigkeit. Ein System, das sich über offene Schnittstellen (APIs) anbinden lässt, bleibt langfristig flexibel und vermeidet eine teure Abhängigkeit von einem einzigen Anbieter.

Schnittstellen als Auswahlkriterium

Kein ERP-System steht für sich allein. In der Praxis muss es mit Online-Shops, Versanddienstleistern, der Steuerberatung (etwa über eine DATEV-Schnittstelle), Banken und teils mit Maschinen kommunizieren. Prüfen Sie deshalb früh, welche Standard-Schnittstellen ein System mitbringt und wie offen seine Programmierschnittstellen sind. Je besser die Anbindung gelingt, desto reibungsloser läuft der spätere Betrieb – und desto geringer ist das Risiko teurer Sonderentwicklungen.

Systemwechsel: Wann eine Ablösung sinnvoll ist

Viele Unternehmen betreiben über Jahre ein gewachsenes oder veraltetes System und fragen sich, wann ein Wechsel angebracht ist. Klare Warnsignale sind: Der Anbieter stellt Wartung oder Updates ein, das System lässt sich nicht mehr an neue Anforderungen anpassen, Schnittstellen zu modernen Anwendungen fehlen, oder der Betrieb verursacht hohe Kosten bei geringer Stabilität. Auch wenn zentrale Prozesse nur noch über Workarounds und Excel-Listen außerhalb des Systems funktionieren, ist die Zeit für eine Neubewertung gekommen.

Ein Systemwechsel ist allerdings ein erhebliches Vorhaben und sollte nicht leichtfertig begonnen werden. Sinnvoll ist eine nüchterne Abwägung zwischen den laufenden Nachteilen des Altsystems und dem Aufwand einer Migration. Dazu gehört auch die Frage, ob sich das vorhandene System nicht durch ein Update oder gezielte Erweiterungen wirtschaftlicher modernisieren lässt. Erst wenn die Nachteile dauerhaft überwiegen, ist die Ablösung die bessere Entscheidung.

Datenübernahme als kritischer Faktor

Beim Wechsel ist die Übernahme der Altdaten einer der heikelsten Punkte. Stammdaten zu Artikeln, Kunden und Lieferanten sowie offene Vorgänge müssen sauber übertragen werden, ohne historische Fehler mitzunehmen. Bewährt hat sich, den Wechsel zur gründlichen Datenbereinigung zu nutzen und mehrere Testmigrationen durchzuführen, bevor das neue System produktiv geht. Auch der Umgang mit historischen Daten will geklärt sein: Nicht alles muss migriert werden – manches lässt sich archivieren und bei Bedarf separat einsehen. Ein gut geplanter Wechsel verbindet so den Abschied vom Alten mit einem sauberen, zukunftsfähigen Neustart.

Internationalität und Mehrsprachigkeit

Für Unternehmen mit Auslandsbezug ist die internationale Tauglichkeit eines ERP-Systems ein wichtiges Kriterium. Dazu gehören die Unterstützung mehrerer Sprachen in Oberfläche und Belegen, die Verarbeitung verschiedener Währungen samt Umrechnung, sowie die Abbildung landesspezifischer steuerlicher und rechtlicher Anforderungen. Ein System, das nur den deutschen Rechtsraum kennt, stößt schnell an Grenzen, sobald eine ausländische Tochtergesellschaft oder ein Lager im Ausland hinzukommt.

Auch wenn ein Unternehmen heute rein national agiert, lohnt der Blick auf diese Fähigkeiten, falls eine Expansion denkbar ist. Ebenso relevant ist die Frage der Mandantenfähigkeit: Können mehrere rechtlich getrennte Einheiten in einem System geführt und bei Bedarf konsolidiert werden? Solche Eigenschaften lassen sich nachträglich nur schwer ergänzen und sollten deshalb früh in der Auswahl berücksichtigt werden. Wer international wachsen will, wählt besser von Beginn an ein System, das diese Anforderungen im Standard beherrscht, statt später teuer nachzurüsten oder erneut zu wechseln.

Benutzerfreundlichkeit als unterschätzter Erfolgsfaktor

Bei aller Funktionstiefe entscheidet im Alltag oft die Bedienbarkeit über den Erfolg eines ERP-Systems. Eine Software, die Anwender als umständlich empfinden, wird umgangen, unvollständig gepflegt oder führt zu Fehlern – und entwertet damit den gesamten Integrationsgedanken. Achten Sie in Demos deshalb gezielt darauf, wie viele Schritte ein alltäglicher Vorgang erfordert, wie übersichtlich die Oberfläche ist und wie schnell sich neue Mitarbeitende einarbeiten können. Eine moderne, aufgeräumte Benutzeroberfläche ist kein Luxus, sondern wirkt sich unmittelbar auf Produktivität und Datenqualität aus. Gerade weil ein ERP-System täglich von vielen Menschen genutzt wird, summieren sich kleine Reibungsverluste schnell zu erheblichen Kosten. Beziehen Sie die späteren Anwender deshalb früh in die Bewertung ein.

Updatefähigkeit und Releasewechsel

Ein oft übersehenes, aber langfristig entscheidendes Kriterium ist die Updatefähigkeit eines ERP-Systems. Cloud-Systeme werden vom Anbieter laufend aktualisiert und bleiben dadurch ohne große Projekte technisch aktuell. Bei On-Premise-Lösungen sind dagegen geplante Releasewechsel nötig, deren Aufwand stark davon abhängt, wie sauber Anpassungen vom Standard getrennt sind. Wer Individualanpassungen konsequent über updatesichere Erweiterungen statt über tiefe Eingriffe umsetzt, hält künftige Wechsel beherrschbar. Prüfen Sie deshalb früh, wie ein Anbieter Updates organisiert, wie häufig neue Versionen erscheinen und wie lange ältere Stände unterstützt werden. Eine gute Updatestrategie schützt die Investition und verhindert, dass ein System über die Jahre schleichend veraltet.

Die wichtigsten Arten von ERP-Systemen

„ERP-System“ ist ein Sammelbegriff für sehr unterschiedliche Lösungen. Für die Orientierung helfen vier Einteilungen, die sich überlagern: nach Betriebsmodell (Cloud, On-Premise, hybrid), nach Spezialisierung (Generalist oder Branchenlösung), nach Zielgröße (Kleinunternehmen, Mittelstand, Konzern) und nach Architektur (monolithisch, modular, Best-of-Breed). Wer diese Dimensionen kennt, kann den unübersichtlichen Markt schnell auf wenige passende Kandidaten eingrenzen.

Cloud-ERP vs. On-Premise im Detail

Die Grundsatzfrage des Betriebsmodells prägt Kosten, Verantwortung und Flexibilität über die gesamte Laufzeit. Beim Cloud-ERP betreibt der Anbieter die Software und stellt sie als Dienst bereit; beim On-Premise-Betrieb läuft sie auf eigener oder gemieteter Infrastruktur.

Daneben verbreiten sich hybride Modelle, die beide Welten kombinieren – etwa sensible Daten im Haus, der Rest in der Cloud. Der Markttrend zeigt klar Richtung Cloud, während On-Premise bei besonderen Anforderungen an Datenhoheit und Individualisierung seine Berechtigung behält.

Monolith, modular oder Best-of-Breed?

Die Architektur entscheidet über die spätere Flexibilität. Ein monolithisches System bildet alles in einem geschlossenen Block ab – eng integriert, aber schwerer zu ändern. Modulare Systeme bestehen aus kombinierbaren Bausteinen und erlauben einen schrittweisen Ausbau. Beim Best-of-Breed-Ansatz wird für jeden Bereich die jeweils beste Speziallösung gewählt und über Schnittstellen verbunden – maximale Funktionstiefe bei höherem Integrationsaufwand. Für den Mittelstand ist ein modulares Standardsystem mit offenen Schnittstellen meist der pragmatische Mittelweg.

So vergleichen Sie ERP-Systeme strukturiert

• Funktionsabdeckung gegen das eigene Lastenheft prüfen
• Branchenfit und Referenzen ähnlicher Unternehmen bewerten
• Betriebsmodell (Cloud/On-Premise/Hybrid) festlegen
• Schnittstellen zu Shop, Versand, DATEV & Co. klären
• Gesamtkosten über drei bis fünf Jahre rechnen
• Skalierbarkeit und Roadmap des Anbieters berücksichtigen

Single-Tenant, Multi-Tenant und SaaS: was hinter den Cloud-Modellen steckt

Wer ein ERP-System auswählt, stößt früher oder später auf die Begriffe Single-Tenant, Multi-Tenant und Software as a Service (SaaS). Im Vertriebsgespräch werden sie oft synonym mit dem Schlagwort „Cloud“ verwendet – und genau hier beginnt das Missverständnis. Die Frage, ob eine Software in einem Rechenzentrum betrieben wird oder im eigenen Serverraum, ist eine andere Frage als jene, wie die Software intern aufgebaut ist und wie viele Kunden sich eine technische Instanz teilen. Das Mandantenmodell – also die Architektur, mit der ein Anbieter mehrere Kundenorganisationen auf seiner Plattform bedient – ist eine eigenständige Kategorisierung. Sie entscheidet darüber, wie Updates ausgerollt werden, wie weit Sie das System anpassen dürfen, wie die Kosten kalkuliert werden und wem die Verantwortung für Betrieb und Skalierung gehört.

Dieser Abschnitt klärt die drei Modelle trennscharf und zeigt, welche praktischen Konsequenzen sie für Ihren Alltag mit der ERP-Lösung haben. Die übergeordnete Betriebsfrage – also wo und durch wen ein System betrieben wird, inklusive Sonderformen jenseits der reinen Cloud/On-Premise-Dichotomie – behandeln wir an anderer Stelle; hier geht es ausschließlich um die innere Architektur und das daraus abgeleitete Geschäfts- und Betriebsmodell.

Mandantenfähigkeit ist nicht gleich Multi-Tenant

Ein verbreiteter Stolperstein vorweg: Fast jedes seriöse ERP-System ist mandantenfähig im betriebswirtschaftlichen Sinn. Das bedeutet, dass Sie innerhalb einer Installation mehrere rechtlich oder organisatorisch getrennte Einheiten – etwa Tochtergesellschaften, Filialen oder Buchungskreise – mit eigenen Stammdaten, Belegnummernkreisen und Auswertungen führen können. Diese Form der Mandantentrennung betrifft Ihre Organisation und Ihre eigenen Daten.

Single-Tenant und Multi-Tenant meinen etwas anderes: Sie beschreiben, wie der Softwareanbieter verschiedene Kundenunternehmen auf seiner Infrastruktur unterbringt. Hier geht es um die Trennung zwischen Ihnen und völlig fremden Unternehmen, die dieselbe Software desselben Herstellers nutzen. Diese beiden Bedeutungsebenen werden im Marketing gern vermischt, weil beide das Wort „Mandant“ tragen. Halten Sie die Unterscheidung gedanklich auseinander: Betriebswirtschaftliche Mandanten sind eine Funktion innerhalb Ihres Systems, Multi-Tenancy ist eine Eigenschaft der Anbieterarchitektur.

Single-Tenant: eine eigene Instanz pro Kunde

Im Single-Tenant-Modell erhält jeder Kunde eine dedizierte, vollständige Instanz der Anwendung. Das heißt: eine eigene Applikationsumgebung und eine eigene Datenbank, die ausschließlich Ihrem Unternehmen gehört. Andere Kunden laufen auf völlig getrennten Instanzen, oft sogar auf separater virtueller oder physischer Hardware. Bildlich gesprochen bewohnt jeder Kunde sein eigenes Haus mit eigenem Fundament, eigener Verkabelung und eigenem Schloss.

Diese Isolation hat handfeste Vorteile. Anpassungen, Erweiterungen und sogar Eingriffe in den Programmcode wirken sich nur auf Ihre Instanz aus. Sie können Releasestände individuell halten, Schnittstellen tief integrieren und das System auf Ihre Prozesse zuschneiden, ohne Rücksicht auf andere Kunden zu nehmen. Auch regulatorisch lässt sich eine eigene Datenbank leichter argumentieren, weil Ihre Daten physisch und logisch nirgends mit Fremddaten vermengt sind. Klassische, hochgradig anpassbare Systeme – wie sie etwa im Umfeld von Navision-ERP über Jahrzehnte gepflegt wurden – folgen häufig diesem Muster.

Der Preis dieser Freiheit ist Aufwand. Jede Instanz muss separat betrieben, überwacht, gesichert und aktualisiert werden. Updates laufen nicht zentral, sondern pro Kunde – was bedeutet, dass ein Anbieter mit vielen Single-Tenant-Kunden eine entsprechend große Zahl individueller Umgebungen pflegen muss. Das schlägt sich in höheren Betriebskosten nieder und führt dazu, dass Releases tendenziell seltener und gestaffelt eingespielt werden. Genau hier liegt der wirtschaftliche Grund, warum viele Anbieter zum Multi-Tenant-Modell übergegangen sind.

Multi-Tenant: eine geteilte Instanz, getrennte Datenmandanten

Im Multi-Tenant-Modell teilen sich viele Kunden eine einzige, gemeinsame Anwendungsschicht. Es läuft also nur eine logische Instanz der Software, die alle Kunden gleichzeitig bedient. Die Trennung der Daten erfolgt nicht durch separate Häuser, sondern durch eine logische Adressierung: Jeder Datensatz trägt eine Mandanten-ID (Tenant-ID), und die Anwendung stellt durch ihre Zugriffslogik sicher, dass ein Kunde nur die Daten sieht, die zu seiner ID gehören. Bildlich ist das ein großes Apartmenthaus: gemeinsames Fundament, gemeinsame Versorgungsleitungen, aber abgeschlossene Wohnungen, zu denen nur der jeweilige Mieter den Schlüssel hat.

Die Datentrennung kann technisch unterschiedlich tief umgesetzt sein – von einer gemeinsamen Datenbank mit Tenant-Spalte über getrennte Schemata bis zu einer eigenen Datenbank pro Mandant bei weiterhin geteilter Applikationsschicht. Entscheidend für die Einordnung als Multi-Tenant ist, dass der Anwendungskern geteilt wird. Genau daraus ergeben sich die charakteristischen Eigenschaften des Modells.

Der große Vorteil ist Effizienz im Betrieb. Der Anbieter pflegt nur eine Codebasis und eine laufende Umgebung. Updates, Sicherheitspatches und neue Funktionen müssen nur an dieser einen Stelle eingespielt werden und stehen sofort allen Kunden zur Verfügung. Auch Infrastruktur lässt sich gemeinsam nutzen und damit besser auslasten. Diese Skaleneffekte sind der Grund, warum Multi-Tenant-Architekturen die wirtschaftliche Basis für günstige, breit verfügbare Cloud-Angebote bilden.

Die Kehrseite ist eingeschränkte Individualisierung. Weil der Kern geteilt wird, darf kein einzelner Kunde ihn verändern – ein Eingriff in den gemeinsamen Code würde alle anderen treffen. Anpassungen sind deshalb nur über definierte Mechanismen möglich: über Konfiguration und über einen separaten Extension-Layer. Dazu unten mehr. Außerdem teilen sich alle Kunden dieselben Ressourcen, weshalb Anbieter Mechanismen gegen den sogenannten „Noisy-Neighbour“-Effekt vorsehen müssen – also dagegen, dass ein lastintensiver Kunde die Performance der anderen beeinträchtigt.

SaaS: das Betriebsmodell auf der Multi-Tenant-Architektur

Software as a Service ist kein Architekturmuster, sondern ein Betriebs- und Bereitstellungsmodell, das in aller Regel auf einer Multi-Tenant-Architektur aufsetzt. Der Anbieter betreibt die Software vollständig in seiner Verantwortung und stellt sie als laufenden Dienst bereit. Sie als Kunde greifen über den Browser oder definierte Schnittstellen zu und müssen sich weder um Server noch um Datenbankpflege, Backups oder das Einspielen von Updates kümmern. Die gesamte technische Betriebsverantwortung liegt beim Anbieter; Sie konsumieren das Ergebnis als Service.

SaaS und Multi-Tenant treten so häufig gemeinsam auf, dass sie oft verwechselt werden. Der Unterschied ist dennoch wichtig: Multi-Tenant beschreibt, wie die Software intern aufgebaut ist; SaaS beschreibt, wie sie Ihnen gegenüber bereitgestellt und abgerechnet wird. Theoretisch ließe sich ein SaaS-Dienst auch single-tenant betreiben, aber die wirtschaftliche Logik von SaaS – geringe Stückkosten, zentrale Pflege, schnelle Auslieferung – entfaltet sich erst auf der geteilten Multi-Tenant-Basis vollständig. Welche dieser Modelle für Ihr Unternehmen tragfähig ist, gehört zu den Kernfragen einer fundierten ERP-Auswahl.

Updatezyklen: erzwungen statt wählbar

Die wohl spürbarste Konsequenz des Mandantenmodells betrifft die Updates. In einer Single-Tenant-Welt entscheiden Sie weitgehend selbst, wann ein neuer Releasestand eingespielt wird. Sie können ein Update aufschieben, in einer Testumgebung prüfen und erst nach Freigabe produktiv setzen. Das gibt Kontrolle, erzeugt aber Pflegeaufwand und das Risiko, technisch zurückzufallen.

Im Multi-Tenant-SaaS gilt das Gegenteil. Weil alle Kunden denselben Kern teilen, werden Updates zentral und für alle gleichzeitig ausgerollt. Sie erhalten neue Funktionen und Sicherheitskorrekturen automatisch, ohne eigenes Zutun – aber Sie können sie in der Regel nicht ablehnen oder dauerhaft auf einem alten Stand verharren. Releases sind damit eher erzwungen als wählbar. Viele Anbieter mildern das durch geplante Release-Fenster, Vorabinformationen, Funktions-Flags zum schrittweisen Aktivieren neuer Features und Sandbox-Umgebungen, in denen Sie kommende Versionen vorab testen können. Das ändert nichts am Grundprinzip: Der Stand der Software wird durch den Anbieter getaktet, nicht durch Sie.

Für Sie bedeutet das einen Tausch: weniger Wartungslast und stets aktuelle, gepatchte Software gegen weniger Kontrolle über den Zeitpunkt von Änderungen. Prozesse, die exakt auf eine bestimmte Programmversion abgestimmt sind, müssen in diesem Modell anders abgesichert werden – nämlich über den Extension-Layer statt über eingefrorene Versionsstände.

Anpassbarkeit: konfigurieren und erweitern statt im Kern programmieren

Daraus folgt unmittelbar die zweite große Konsequenz. In einem geteilten Kern ist die individuelle Programmierung am Quellcode tabu, weil sie alle Kunden beträfe und beim nächsten zentralen Update überschrieben würde. Multi-Tenant-SaaS-Systeme bieten Individualisierung deshalb über zwei klar getrennte Wege an.

Der erste Weg ist Konfiguration: Über Einstellungen, Parameter, Geschäftsregeln, Workflow-Designer und Berechtigungskonzepte passen Sie das Verhalten der Standardsoftware an, ohne Programmcode zu berühren. Der zweite Weg ist der Extension-Layer – eine definierte Erweiterungsschicht oberhalb des Kerns, in der kundenspezifischer Code, Add-ons und Integrationen leben. Diese Erweiterungen sprechen den Kern über stabile, dokumentierte Schnittstellen (APIs) und Erweiterungspunkte an, statt ihn zu verändern. Der entscheidende Vorteil: Updates des Kerns lassen Ihre Erweiterungen unberührt, solange die Schnittstellen stabil bleiben. Man spricht von updatesicherer Anpassung.

Dieses Prinzip verlangt ein Umdenken gegenüber klassischen, tief modifizierten Installationen. Wer gewohnt war, Sonderwünsche durch direkte Eingriffe in den Programmcode zu lösen, muss im SaaS-Umfeld lernen, dieselben Anforderungen über Konfiguration und Extensions abzubilden. Das diszipliniert die Projektarbeit und ist ein wiederkehrendes Thema in der ERP-Implementierung, weil es bereits in der Konzeptphase die Grenze zwischen Standard und Erweiterung schärft.

Skalierung und Kostenstruktur: Subskription statt Lizenzkauf

Auch wirtschaftlich unterscheiden sich die Modelle deutlich. Single-Tenant-Systeme werden klassisch über einen Lizenzkauf erworben: Sie zahlen einmalig für die Nutzungsrechte (oft als aktivierbares Anlagegut) und laufend für Wartung und Support. Der Betrieb – ob im eigenen Haus oder ausgelagert – verursacht zusätzliche Kosten und bindet Kapital in Infrastruktur und Know-how.

SaaS dreht dieses Modell um. Sie schließen ein Abonnement (Subskription) ab, das typischerweise pro Nutzer und pro Zeitraum berechnet wird und in dem Software, Betrieb, Updates und Support gebündelt sind. Aus einer großen Anfangsinvestition wird eine laufende Betriebsausgabe. Das senkt die Einstiegshürde und macht Kosten planbar, kann aber über lange Laufzeiten in Summe erheblich sein – ein Aspekt, der in jede Wirtschaftlichkeitsbetrachtung gehört. Die Skalierung folgt derselben Logik: Wächst Ihr Unternehmen, buchen Sie zusätzliche Nutzer oder höhere Kapazitätsstufen hinzu, statt neue Server zu beschaffen. Die elastische Skalierung der gemeinsamen Infrastruktur übernimmt der Anbieter, der seine Ressourcen über alle Mandanten hinweg dynamisch verteilt.

Abgrenzung: SaaS ist nicht jedes „gehostete“ System

Eine Verwechslung verdient besondere Aufmerksamkeit, weil sie regelmäßig zu Fehlentscheidungen führt. Wird ein klassisches, single-tenant aufgebautes ERP-System in einem Rechenzentrum betrieben und Ihnen über den Browser oder eine Fernverbindung bereitgestellt, sieht das oberflächlich aus wie Cloud – ist aber kein SaaS. Man spricht von gehostetem On-Premise, häufig auch als Hosted-Modell oder, historisch, als Application Service Providing (ASP) bezeichnet.

Der Unterschied ist substanziell. Beim gehosteten On-Premise läuft weiterhin eine eigene, dedizierte Instanz für Ihr Unternehmen – lediglich der Standort des Servers hat sich verschoben, vom eigenen Keller in ein fremdes Rechenzentrum. Sie bleiben single-tenant. Updates werden nicht zentral für alle Kunden ausgerollt, sondern weiterhin pro Instanz eingespielt; tiefe Anpassungen am Code bleiben möglich; und das Kostenmodell beruht häufig weiterhin auf einer Lizenz zuzüglich einer Hosting-Gebühr, nicht auf einer echten nutzungsbasierten Subskription. Sie erhalten also die Standortvorteile eines Rechenzentrums, aber nicht die Skaleneffekte, die automatischen zentralen Updates und die wirtschaftliche Logik einer geteilten Multi-Tenant-Plattform.

Diese Abgrenzung ist nicht akademisch. Wer ein gehostetes System für echtes SaaS hält, erwartet automatische Updates, die nicht kommen, kalkuliert mit Subskriptionspreisen, die in Wahrheit verkappte Lizenz- plus Betriebskosten sind, und unterschätzt den eigenen Pflegeaufwand. Umgekehrt fürchten manche Unternehmen bei echtem SaaS die vermeintliche Vermischung ihrer Daten mit fremden – obwohl die logische Trennung über die Mandanten-ID bei seriösen Anbietern strikt durchgesetzt wird. Prüfen Sie deshalb im Auswahlprozess nicht nur, ob ein System „in der Cloud“ läuft, sondern konkret: Wird der Anwendungskern geteilt? Werden Updates zentral und automatisch ausgerollt? Wie genau werden meine Daten von denen anderer Kunden getrennt? Und welches Abrechnungsmodell liegt wirklich zugrunde?

Welches Modell zu welchem Unternehmen passt

Eine pauschale Empfehlung gibt es nicht, wohl aber klare Tendenzen. Multi-Tenant-SaaS spielt seine Stärken dort aus, wo standardnahe Prozesse, planbare Kosten, geringer eigener IT-Aufwand und stets aktuelle Software im Vordergrund stehen – ein Profil, das auf viele wachsende und mittelständische Organisationen zutrifft und das wir im Kontext von ERP für den Mittelstand ausführlicher beleuchten. Single-Tenant- oder gehostete Modelle bleiben dort attraktiv, wo sehr tiefe Individualisierung, vollständige Kontrolle über Versionsstände oder besondere Anforderungen an die Datenhaltung den höheren Betriebsaufwand rechtfertigen.

Entscheidend ist, dass Sie die Begriffe nicht als Marketingvokabular hinnehmen, sondern als technische und wirtschaftliche Weichenstellung verstehen. Ob eine Instanz geteilt oder dediziert ist, ob Updates erzwungen oder wählbar sind, ob Sie konfigurieren und erweitern oder im Kern programmieren, und ob Sie abonnieren oder lizenzieren – all das hängt am Mandantenmodell. Wer diese Zusammenhänge kennt, liest jedes Cloud-Angebot mit anderen Augen und stellt im Gespräch mit Anbietern genau die Fragen, die hinter die glänzende Oberfläche des Wortes „Cloud“ führen.

Open Source vs. proprietäres ERP: Lizenz, Geschäftsmodell und Anbieterbindung

Eine der grundlegendsten Weichenstellungen bei der Beschäftigung mit ERP-Software wird oft erst spät bewusst getroffen, obwohl sie alles Nachgelagerte prägt: die Frage, ob ein System auf einem offenen oder einem geschlossenen Quellcode-Modell beruht. Diese Unterscheidung ist keine rein technische Detailfrage für die IT-Abteilung. Sie entscheidet darüber, wer den Programmcode einsehen, verändern und weitergeben darf, wie das dahinterstehende Unternehmen Geld verdient, an wen Sie sich bei Anpassungen und Problemen wenden und wie stark Sie langfristig an einen bestimmten Anbieter gebunden sind. Open Source und proprietäre Software bilden damit zwei grundverschiedene Markt-Kategorien, die sich quer durch alle Größenklassen und Betriebsmodelle ziehen. Dieser Abschnitt arbeitet die Logik beider Welten heraus, ohne die eine pauschal über die andere zu stellen.

Wichtig vorab: Open Source und proprietär beschreiben das Lizenz- und Geschäftsmodell einer Lösung, nicht ihren Funktionsumfang und nicht ihre Betriebsart. Ein quelloffenes ERP kann als gehosteter Dienst angeboten werden, ein proprietäres lässt sich im eigenen Rechenzentrum betreiben. Wenn Sie vor einer konkreten ERP-Auswahl stehen, lohnt es sich daher, diese Dimension getrennt von der Frage nach Tier und Hosting zu bewerten.

Was Lizenzen rechtlich regeln

Jede Software wird unter einer Lizenz ausgeliefert. Die Lizenz ist der rechtliche Rahmen, der festlegt, was Sie mit dem Programm tun dürfen und was nicht. Bei proprietärer Software erwerben Sie in aller Regel ein Nutzungsrecht, kein Eigentum am Code. Der Quellcode bleibt das Geschäftsgeheimnis des Herstellers. Sie erhalten kompilierte, ausführbare Programme und die Erlaubnis, diese in einem definierten Umfang einzusetzen, etwa bemessen nach Anzahl der Benutzerkonten, der Prozessorkerne, der angebundenen Standorte oder der abgerufenen Funktionsmodule. Verändern, dekompilieren oder weitergeben dürfen Sie die Software typischerweise nicht. Die Vertragslogik ist die einer Lizenzierung gegen Entgelt: Sie zahlen für das Recht, ein Werkzeug zu benutzen, dessen Innenleben verschlossen bleibt.

Open-Source-Lizenzen kehren diese Logik um. Sie gewähren jedem Empfänger vier grundlegende Freiheiten: das Programm für jeden Zweck auszuführen, seinen Quellcode zu studieren, ihn zu verändern und veränderte oder unveränderte Kopien weiterzugeben. Der Quellcode ist also offengelegt. Allerdings sind nicht alle Open-Source-Lizenzen gleich. Sie unterscheiden sich vor allem darin, welche Pflichten sie an die Weitergabe knüpfen, und genau diese Unterschiede sind für ein ERP wirtschaftlich relevant.

GPL, AGPL und LGPL: die Lizenzfamilien im Detail

Die sogenannten Copyleft-Lizenzen verlangen, dass abgeleitete Werke unter denselben Bedingungen wieder offengelegt werden. Die bekannteste ist die GPL (General Public License). Wer ein unter GPL stehendes ERP verändert und das Ergebnis verbreitet, muss den geänderten Quellcode ebenfalls unter GPL bereitstellen. Das verhindert, dass jemand offenen Code nimmt, ihn proprietär einschließt und exklusiv vermarktet.

Die AGPL (Affero General Public License) verschärft diesen Gedanken für eine Welt, in der Software nicht mehr ausgeliefert, sondern als Dienst über das Netz bereitgestellt wird. Bei der klassischen GPL greift die Offenlegungspflicht erst bei der Verbreitung der Software. Wer ein Programm nur intern betreibt oder über einen Server zur Verfügung stellt, verbreitet es im juristischen Sinne nicht. Die AGPL schließt diese Lücke: Schon das Anbieten der Software über ein Netzwerk gilt als auslösender Tatbestand, sodass auch die Nutzer eines gehosteten AGPL-ERP Anspruch auf den modifizierten Quellcode haben. Für ein ERP, das häufig als zentraler Serverdienst läuft, ist diese Unterscheidung erheblich.

Die LGPL (Lesser General Public License) ist die mildeste der drei. Sie erlaubt, eine als Bibliothek vorliegende Komponente in proprietäre Software einzubinden, ohne dass das umgebende Gesamtwerk offengelegt werden müsste. Nur Änderungen an der LGPL-Komponente selbst fallen unter die Pflicht. Daneben existieren permissive Lizenzen wie MIT, BSD oder Apache, die kaum Pflichten auferlegen: Sie dürfen den Code praktisch beliebig verwenden, auch in geschlossenen Produkten, solange Sie Urheberhinweise erhalten. Manche kommerziellen ERP-Hersteller bauen daher Teile ihres Produkts auf permissiv lizenzierten Bausteinen auf, ohne dass das Endprodukt offen wäre.

Open Core: das verbreitete Geschäftsmodell hinter offenem ERP

Reine Open-Source-Projekte ohne kommerzielle Trägerschaft sind im ERP-Umfeld die Ausnahme. Verbreitet ist stattdessen das Open-Core-Modell. Dabei steht ein funktionsfähiger Kern unter einer offenen Lizenz frei zur Verfügung, häufig Community Edition genannt. Um diesen Kern herum bietet der Hersteller eine kostenpflichtige Enterprise Edition an, die zusätzliche Module, Bequemlichkeitsfunktionen, geprüfte Stabilität, gewartete Schnittstellen und vertraglich zugesicherten Support enthält. Wirtschaftlich finanziert sich der Anbieter also über die Differenz zwischen offenem Fundament und geschlossenen oder kostenpflichtigen Aufbauten sowie über Abonnements, Hosting und Dienstleistung.

Dieses Modell erklärt eine Erfahrung, die viele Interessenten irritiert: Eine als Open Source beworbene Lösung erweist sich im produktiven Einsatz keineswegs als kostenlos. Die Community Edition deckt oft die Grundfunktionen ab, doch ausgerechnet jene Bausteine, die ein mittelständischer Betrieb benötigt, etwa fortgeschrittene Buchhaltung, bestimmte Branchenfunktionen, ein Servicevertrag oder die Ausfallsicherheit, gehören zum kostenpflichtigen Teil. Das ist kein Widerspruch und keine Täuschung, sondern die innere Logik des Open-Core-Ansatzes. Wer den Begriff Open ERP hört, sollte daher stets nachfragen, wo genau die Grenze zwischen frei und kostenpflichtig verläuft.

Was "kostenlos" bei ERP wirklich bedeutet

Selbst dort, wo die Software-Lizenz tatsächlich nichts kostet, ist das ERP-Vorhaben damit nicht umsonst. Der Lizenzpreis ist nur ein Posten in einer längeren Kette von Kosten, und bei betrieblicher Standardsoftware ist er häufig nicht einmal der größte. Wer die Gesamtkosten realistisch einschätzen will, muss mehrere Ebenen zusammenrechnen.

• Implementierung: Konfiguration, Datenmigration aus Altsystemen, Abbildung der eigenen Prozesse und Anpassung an betriebliche Besonderheiten. Diese Arbeit fällt unabhängig vom Lizenzmodell an und ist bei offener wie geschlossener Software vergleichbar aufwendig.
• Hosting und Betrieb: Server, Speicher, Datensicherung, Aktualisierungen und Überwachung. Wer ein offenes ERP selbst betreibt, übernimmt diese Aufgaben in Eigenregie oder kauft sie als Dienstleistung ein.
• Wartung und Updates: Das Einspielen von Korrekturen und neuen Versionen, das Beheben von Inkompatibilitäten und die Pflege individueller Erweiterungen über die Zeit.
• Support: Ein verlässlicher Ansprechpartner bei Störungen, idealerweise mit zugesicherten Reaktionszeiten. Genau dieser Punkt ist bei rein gemeinschaftlich getragener Software der wundeste, denn ein Forum garantiert keine Antwort innerhalb einer Frist.
• Schulung und internes Know-how: Mitarbeiter müssen das System beherrschen, und beim Eigenbetrieb offener Software braucht es technisches Personal, das Code und Infrastruktur versteht.

Die wirtschaftlich saubere Betrachtung ist daher die der Gesamtbetriebskosten über mehrere Jahre, nicht der Vergleich von Listenpreisen. Eine kostenlose Community Edition kann durch hohen Eigenbetriebsaufwand am Ende teurer ausfallen als eine lizenzpflichtige Lösung mit umfassendem Service, und umgekehrt. Weiterführende Überlegungen zur Kostenstruktur und zum Auswahlprozess finden Sie auf unserer Seite zur ERP-Auswahl im Mittelstand.

Quellcode-Zugang: wer einsehen und anpassen darf

Der vielleicht greifbarste Unterschied liegt im Zugang zum Quellcode. Bei offener Software können Ihr Team oder ein beauftragter Dienstleister jede Zeile lesen, nachvollziehen, wie eine Berechnung zustande kommt, einen Fehler selbst lokalisieren und eine fehlende Funktion ergänzen. Diese Transparenz schafft Unabhängigkeit auf der technischen Ebene und erlaubt Anpassungen, die kein Hersteller freigeben muss. Sie verlangt aber auch die Fähigkeit, mit dieser Freiheit umzugehen. Ohne entsprechende Kompetenz im Haus oder bei einem Partner bleibt der offene Code ein Versprechen, das niemand einlöst.

Bei proprietärer Software bleibt der Code verschlossen. Anpassungen erfolgen über die vom Hersteller vorgesehenen Mechanismen: Konfigurationsoberflächen, Erweiterungspunkte, Programmierschnittstellen und gegebenenfalls eine herstellereigene Anpassungssprache. Was außerhalb dieses Rahmens liegt, lässt sich nur über den Anbieter selbst oder zertifizierte Partner umsetzen. Das kann ein Nachteil sein, wenn Sie eine sehr spezielle Anforderung haben, und ein Vorteil, weil der definierte Rahmen die Komplexität begrenzt und die Upgrade-Fähigkeit schützt. Genau dieser Aspekt ist im klassischen Mittelstandssegment relevant, etwa bei Lösungen rund um Microsoft-basierte ERP-Systeme, wo Erweiterungen über definierte Schnittstellen statt über Eingriffe in den Kern erfolgen.

Update- und Releasehoheit

Eng mit dem Code-Zugang verbunden ist die Frage, wer über den Versionsfortschritt bestimmt. Bei proprietärer Software liegt die Releasehoheit beim Hersteller. Er entscheidet, welche Funktionen kommen, wann eine Version erscheint, wie lange eine ältere noch gepflegt wird und wann sie ausläuft. Das bringt Verlässlichkeit und eine klare Verantwortlichkeit, bindet Sie aber an den Takt und die Prioritäten des Anbieters. Läuft eine Version aus, müssen Sie migrieren, auch wenn Ihnen die alte genügen würde.

Bei offener Software haben Sie grundsätzlich die Freiheit, eine Version länger zu behalten, selbst zu pflegen oder gezielt einzelne Korrekturen zu übernehmen. Diese Hoheit ist ein echter Wert, sie verlagert aber die Verantwortung zu Ihnen. Wer Aktualisierungen aussitzt, sammelt technische Altlasten an, und wer den Kern stark verändert hat, muss bei jedem Versionssprung prüfen, ob seine Anpassungen noch tragen. Die Freiheit, nicht zu aktualisieren, ist also zugleich die Pflicht, die Folgen selbst zu verantworten.

Vendor-Lock-in: Abhängigkeit in beide Richtungen

Der Begriff der Anbieterabhängigkeit, häufig als Vendor-Lock-in bezeichnet, wird gern als Argument gegen proprietäre Software ins Feld geführt. Das greift zu kurz, denn beide Modelle erzeugen Abhängigkeiten, nur eben unterschiedliche. Eine nüchterne Bewertung verlangt, beide Richtungen zu betrachten.

Bei proprietären Systemen entsteht Bindung typischerweise über drei Hebel. Erstens über geschlossene oder schlecht dokumentierte Datenformate: Liegen Ihre Geschäftsdaten in einer Struktur, die nur das herstellereigene System sauber lesen kann, wird ein späterer Wechsel mühsam und teuer. Zweitens über die Lizenzbindung selbst, samt Abomodellen, Preisanpassungen und der Tatsache, dass Sie bei Vertragsende kein Nutzungsrecht behalten. Drittens über proprietäre Erweiterungen und Schnittstellen, deren Logik außerhalb des Herstellerökosystems wertlos ist. Diese Hebel sind real und sollten bei jeder Auswahl bedacht werden, etwa durch die Frage nach Exportformaten, dokumentierten Schnittstellen und vertraglichen Ausstiegsregelungen.

Bei Open Source verschwindet die Abhängigkeit jedoch nicht, sie verlagert sich. Der offene Code schließt einen Lock-in über das Datenformat weitgehend aus, denn Sie können die Speicherstruktur einsehen und Ihre Daten jederzeit auslesen. An seine Stelle treten andere Bindungen. Wenn Sie das System nicht selbst beherrschen, sind Sie abhängig von einem Implementierungspartner, der die Lösung für Sie aufgesetzt und angepasst hat. Hat dieser Partner stark in den Code eingegriffen, kennt womöglich nur er die Besonderheiten Ihrer Installation, und ein Wechsel wird ähnlich schwierig wie bei einem geschlossenen System. Beim Eigenbetrieb wiederum binden Sie sich an internes Spezialwissen: Verlässt die betreffende Person das Unternehmen, steht das ERP-Wissen auf wackligen Beinen. Offener Code allein verhindert Abhängigkeit also nicht, er macht sie nur anders gestaltbar.

Aus dieser doppelten Perspektive folgt eine pragmatische Konsequenz: Die entscheidende Frage ist nicht, ob ein System bindet, sondern wie austauschbar die jeweilige Bindung ist. Ein proprietäres System mit offenen Standardschnittstellen und sauberen Exportwegen kann weniger einsperren als ein offenes System mit einem einzigen, unverzichtbaren Partner. Wer diese Frage strukturiert beantworten will, profitiert von externer Begleitung im Rahmen eines ERP-Consultings, das die langfristige Beweglichkeit zum Auswahlkriterium macht.

Wann welches Modell trägt

Eine generelle Überlegenheit lässt sich nicht begründen, wohl aber lassen sich Eignungsprofile beschreiben. Offene Systeme spielen ihre Stärken dort aus, wo eigene technische Kompetenz vorhanden ist oder ein verlässlicher Partner zur Verfügung steht, wo besondere Anforderungen tiefe Anpassungen verlangen und wo die Unabhängigkeit vom Datenformat einen strategischen Wert hat. Proprietäre Systeme überzeugen, wo ein klar definierter Funktionsumfang, planbare Kosten, ein einziger verantwortlicher Ansprechpartner und vertraglich zugesicherter Support im Vordergrund stehen und das Unternehmen seine IT-Kapazität lieber auf das Kerngeschäft konzentriert.

In der Praxis verschwimmen die Grenzen zunehmend. Viele Hersteller offener Software bieten vollwertigen Enterprise-Support und schlüsselfertigen Betrieb, während proprietäre Anbieter ihre Systeme über offene Standardschnittstellen anschlussfähig halten. Die ehemals scharfe Trennlinie wird damit zu einem Spektrum. Entscheidend für Ihre ERP-Lösung ist deshalb weniger das Etikett Open Source oder proprietär als die konkrete Antwort auf drei Fragen: Was kostet der vollständige Betrieb über die geplante Nutzungsdauer, wer trägt im Störungsfall die Verantwortung, und wie aufwendig wäre ein späterer Wechsel? Wer diese drei Punkte für beide Welten ehrlich beantwortet, trifft eine fundierte Wahl, statt einem Schlagwort zu folgen.

Markt-Tiers: vom Großkonzern-ERP bis zur Kleinunternehmer-Lösung

Wer sich erstmals mit dem ERP-Markt befasst, stößt schnell auf eine Einteilung, die in Analystenberichten, Anbietervergleichen und Beratungsgesprächen wie selbstverständlich verwendet wird: die Rede ist von Tier 1, Tier 2 und Tier 3. Diese Begriffe stammen ursprünglich aus der Marktbeobachtung und beschreiben grob, für welche Unternehmensgröße und welchen Komplexitätsgrad eine Lösung typischerweise gebaut wurde. Tier 1 steht dabei für die Schwergewichte, die multinationale Konzerne tragen können; Tier 2 für Lösungen des gehobenen Mittelstands; Tier 3 für Systeme, die kleine und mittlere Betriebe bis hinunter zum Kleinunternehmer adressieren. Es handelt sich um eine Orientierungshilfe, nicht um eine offizielle Norm – die Grenzen sind fließend, und kein Gremium vergibt Tier-Zertifikate.

Dieser Abschnitt erklärt, woran sich die Tiers in der Praxis festmachen, und ordnet sie bewusst neutral ein, ohne einzelne Produkte zu bewerten. Das wichtigste Missverständnis, das es auszuräumen gilt, sei vorweggenommen: Ein höheres Tier ist nicht „besser“ und ein niedrigeres nicht „schlechter“. Tiers beschreiben einen Passungsbereich, keine Qualitätsrangfolge. Wer das verkennt, läuft Gefahr, eines der teuersten Auswahlfehler überhaupt zu begehen – den Tier-Mismatch, auf den wir am Ende ausführlich eingehen.

Was ein Tier überhaupt bezeichnet

Ein Tier ist kein technisches Merkmal des Programmcodes, sondern eine Aussage über den Zielmarkt, für den eine Lösung konzipiert, kalkuliert und ausgeliefert wird. Anbieter treffen früh grundlegende Entscheidungen darüber, wie viele gleichzeitige Nutzer ihr System tragen soll, wie viele rechtliche Einheiten und Standorte es abbilden muss, in wie vielen Ländern es einsetzbar sein soll und wie tief es sich an eine einzelne Branche anpassen lässt. Aus diesen Entscheidungen ergibt sich fast zwangsläufig, in welchem Tier ein Produkt landet – und sie prägen Architektur, Preismodell, Vertriebsweg und die Art der typischen Einführungsprojekte.

Es lohnt sich, das Tier-Modell von zwei verwandten, aber anderen Fragen sauber zu trennen. Die Frage, wie ein System architektonisch und betrieblich bereitgestellt wird – also Mandantenmodelle, Cloud- und Betriebsformen – ist unabhängig vom Tier; ein Tier-2-Produkt kann genauso als Cloud-Dienst laufen wie ein Tier-1-Produkt. Auch die Lizenz- und Geschäftsmodellfrage, also ob eine Lösung proprietär oder quelloffen ist, schneidet quer durch alle Tiers. Das Tier sagt also nichts darüber, wie Sie das System betreiben, sondern für welche Unternehmensgröße und Komplexität es gedacht ist. Genau diese Größen- und Komplexitätsfrage steht im Zentrum jeder fundierten ERP-Auswahl.

Die sechs Dimensionen, an denen sich Tiers festmachen

In der Praxis lassen sich Tiers an einem Bündel zusammenhängender Merkmale erkennen. Selten passt ein Unternehmen oder ein Produkt zu hundert Prozent in genau ein Raster – aber die folgenden sechs Dimensionen geben gemeinsam ein erstaunlich verlässliches Bild.

Unternehmensgröße und Nutzerzahl. Das offensichtlichste, aber für sich allein unzureichende Kriterium ist die Größe der Organisation, gemessen an Mitarbeitenden, Umsatz und der Zahl gleichzeitiger Systemnutzer. Tier-1-Lösungen sind darauf ausgelegt, Tausende bis Zehntausende gleichzeitiger Anwender und sehr hohe Transaktionsvolumina zu tragen. Tier-2-Lösungen bedienen typischerweise den dreistelligen bis unteren vierstelligen Nutzerbereich, Tier-3-Lösungen einige wenige bis einige Dutzend Arbeitsplätze. Wichtig: Die reine Mitarbeiterzahl täuscht oft, weil ein kleines Unternehmen mit hochkomplexen, international verteilten Prozessen anspruchsvoller sein kann als ein größerer, aber sehr homogener Betrieb.

Standorte und Mandanten. Je mehr rechtlich oder organisatorisch getrennte Einheiten ein System abbilden muss – Tochtergesellschaften, Buchungskreise, Werke, Niederlassungen –, desto höher liegt typischerweise das benötigte Tier. Tier-1-Systeme sind darauf ausgelegt, konzernweite Strukturen mit konsolidierter Buchhaltung über viele Mandanten hinweg zu führen. Tier-2-Systeme beherrschen mehrere Mandanten und Standorte solide, stoßen aber bei sehr großen, verschachtelten Konzernstrukturen an Grenzen. Tier-3-Systeme sind häufig auf einen oder wenige Mandanten ausgelegt. Die technische Mandantenfähigkeit als solche ist dabei eine eigene Architekturfrage; hier geht es um die betriebswirtschaftliche Tiefe, mit der konzernweite Konsolidierung unterstützt wird.

Internationalisierung. Ein zentrales Unterscheidungsmerkmal ist, wie viele Länder, Sprachen, Währungen und lokale Rechtsräume ein System „ab Werk“ beherrscht. Damit gemeint sind landesspezifische Steuerlogiken, gesetzliche Meldewesen, Buchhaltungsstandards und Lokalisierungen. Tier-1-Produkte bringen oft Dutzende Länderlokalisierungen mit und sind darauf ausgelegt, in vielen Jurisdiktionen gleichzeitig gesetzeskonform zu arbeiten. Tier-2-Produkte decken eine überschaubare, aber für den gehobenen Mittelstand ausreichende Zahl an Ländern ab. Tier-3-Produkte sind häufig stark auf einen Heimatmarkt fokussiert und decken dessen rechtliche Anforderungen sauber ab, ohne den Anspruch globaler Mehrsprachigkeit zu erheben.

Branchentiefe. Hier zeigt sich, wie spezifisch ein System die Prozesse einer bestimmten Branche unterstützt – etwa diskrete Fertigung, Prozessindustrie, Handel, Projektdienstleistung oder das Gesundheitswesen. Branchentiefe verläuft nicht streng parallel zu den Tiers: Es gibt hochspezialisierte Tier-3-Branchenlösungen, die in ihrem engen Segment mehr Funktionstiefe bieten als ein generisches Tier-1-System. Generell aber stellen Tier-1-Plattformen sehr breite, über Module konfigurierbare Branchenfunktionalität bereit, während kleinere Lösungen entweder breit-generisch oder eng-spezialisiert ausgerichtet sind. Wie sich der passende Funktionsumfang systematisch eingrenzen lässt, ist Gegenstand einer strukturierten ERP-System-Bedarfsanalyse.

Implementierungsaufwand. Mit dem Tier wächst in der Regel die Komplexität der Einführung. Tier-1-Projekte erfordern umfangreiche Konzeptions-, Konfigurations- und Migrationsarbeit, häufig begleitet von spezialisierten Beratungshäusern und einem internen Projektteam über viele Monate. Tier-2-Einführungen sind klar strukturierbar und gut beherrschbar, verlangen aber weiterhin methodisches Vorgehen und Begleitung. Tier-3-Lösungen sind oft auf eine schlanke, teils standardisierte oder vorkonfigurierte Einführung ausgelegt. Wie aufwendig die ERP-Implementierung tatsächlich ausfällt, hängt dabei nicht nur vom Tier, sondern auch vom Grad der gewünschten Anpassung ab.

Typische Projektgröße und -dauer. Aus allen vorigen Punkten ergibt sich der Gesamtaufwand eines Projekts – gemessen an Budget, Teamgröße, Dauer und Risiko. Tier-1-Projekte sind Großvorhaben mit entsprechend langer Laufzeit; Tier-2-Projekte bewegen sich im mittleren Bereich; Tier-3-Projekte sind vergleichsweise kompakt. Diese Größenordnungen sind keine festen Werte, sondern Erfahrungskorridore, die je nach Branche, Anpassungsgrad und Datenmigration erheblich schwanken können.

Die Tiers im Einzelnen

Tier 1 – das Konzern-ERP. Lösungen dieser Kategorie sind gebaut, um die volle Bandbreite eines Großkonzerns abzudecken: viele Länder, viele Mandanten, sehr hohe Datenmengen, tiefe Konsolidierung und ein extrem breites Funktionsspektrum über zahlreiche Module hinweg. Diese Mächtigkeit hat ihren Preis – nicht nur monetär, sondern auch in Form von Komplexität. Ein Tier-1-System will mit Bedacht konfiguriert, organisatorisch getragen und kontinuierlich gepflegt werden. Es entfaltet seinen Nutzen erst dort, wo die abzubildende Komplexität tatsächlich vorhanden ist; in einer schlanken Organisation wird ein Großteil der Funktionalität nie gebraucht und erzeugt dennoch Aufwand.

Tier 2 – das Mittelstands-ERP. Diese Lösungen zielen auf den gehobenen Mittelstand, der über einfache Standardprozesse hinausgewachsen ist, aber nicht die Konzernkomplexität eines Tier-1-Hauses trägt. Sie balancieren Funktionstiefe und Beherrschbarkeit: genug Spielraum für mehrere Standorte, mehrere Mandanten und eine moderate Internationalisierung, ohne dass die Einführung zum Jahrhundertprojekt wird. Für viele wachsende Unternehmen ist dieses Segment der natürliche Heimathafen; die Besonderheiten und Auswahlkriterien für diese Zielgruppe vertiefen wir auf der Seite zu ERP für den Mittelstand.

Tier 3 – das KMU- und Kleinunternehmer-ERP. Im untersten Tier finden sich Lösungen für kleine Betriebe, Handwerk, lokalen Handel und Kleinunternehmer. Sie setzen auf schnelle Einführbarkeit, überschaubare Kosten und einen Funktionsumfang, der die Kernprozesse zuverlässig abdeckt, ohne mit Optionen zu überfrachten. Häufig handelt es sich um stark standardisierte oder vorkonfigurierte Pakete, die ein einzelnes Unternehmen ohne großen Beratungsapparat in Betrieb nehmen kann. Was diese Systeme an Konzernfunktionalität nicht bieten, gleichen sie durch Geschwindigkeit, niedrige Einstiegshürden und Bedienbarkeit aus.

Warum ein höheres Tier nicht automatisch „besser“ ist

Es ist verführerisch, das oberste Tier mit der besten Lösung gleichzusetzen – schließlich kann ein Tier-1-System „mehr“. Genau hier liegt der Denkfehler. Ein ERP-System ist kein Statussymbol, sondern ein Werkzeug, das zur Organisation passen muss. Funktionen, die Sie nicht brauchen, sind kein neutraler Überschuss, sondern aktiver Ballast: Sie erhöhen die Einführungskosten, verlängern die Projektdauer, erschweren die Schulung der Anwender und binden Pflegeaufwand, ohne einen Gegenwert zu liefern. Umgekehrt ist ein Tier-3-System in einem Konzern keine sparsame, sondern eine riskante Wahl, weil es an strukturellen Grenzen scheitert, die sich nicht durch Fleiß überbrücken lassen.

Der eigentliche Maßstab ist also nicht die Höhe des Tiers, sondern die Passung zwischen den Anforderungen Ihrer Organisation und dem Zielmarkt, für den eine Lösung gebaut wurde. Genau diese Passung zu ermitteln, ist eine zentrale Aufgabe im Vorfeld jeder Einführung – und ein klassisches Feld für unabhängiges ERP-Consulting, das die tatsächliche Komplexität einer Organisation nüchtern vermisst, statt sie an einer Wunschvorstellung auszurichten.

Der Tier-Mismatch: zwei typische Auswahlfehler

In der Praxis treten zwei spiegelbildliche Fehler immer wieder auf. Beide haben dieselbe Ursache – eine falsche Einschätzung der eigenen Komplexität – und beide sind teuer.

Zu groß gegriffen (Over-Engineering). Ein Unternehmen wählt ein System aus einem höheren Tier, als es seine tatsächlichen Anforderungen rechtfertigen. Die Folgen zeigen sich oft erst im Projektverlauf: Das Einführungsbudget übersteigt den ursprünglichen Rahmen, weil ein mächtiges System eingerichtet, individualisiert und integriert werden will. Die Anwender kämpfen mit Funktionsfülle und unübersichtlichen Masken. Ein erheblicher Teil der lizenzierten Funktionalität wird nie genutzt. Und nach dem Go-Live bleibt ein dauerhafter Pflege- und Beratungsbedarf, der die Organisation langfristig belastet. Häufige Treiber dieses Fehlers sind Wachstumserwartungen, die zu großzügig in die Gegenwart projiziert werden, sowie der Wunsch, „auf der sicheren Seite“ zu sein.

Zu klein gegriffen (Out-Growing). Das Gegenstück ist die Wahl eines Systems, das den Anforderungen nicht gewachsen ist – sei es von Anfang an oder weil das Unternehmen schneller wächst als gedacht. Symptome sind fehlende Mandanten- oder Mehrwährungsfähigkeit, wenn neue Standorte oder Auslandsgesellschaften hinzukommen, Performance-Probleme bei steigendem Transaktionsvolumen, oder das Ausweichen auf Behelfslösungen wie Tabellenkalkulationen, weil das System bestimmte Prozesse nicht abbildet. Die Folge ist oft ein vorzeitiger, ungeplanter Systemwechsel mit erneuter Migration – faktisch ein zweites Einführungsprojekt, das man durch eine vorausschauende Auswahl hätte vermeiden können.

So nutzen Sie die Tier-Einteilung richtig

Die Tier-Logik ist am wertvollsten als Vorfilter, nicht als Endurteil. Sie hilft, das unüberschaubare Feld der am Markt verfügbaren Systeme auf eine handhabbare Auswahl einzugrenzen, bevor Sie in die detaillierte Bewertung einsteigen. Verstehen Sie sie als groben Such-Korridor: Wenn Ihre Komplexitätsanalyse klar auf den gehobenen Mittelstand zeigt, brauchen Sie Tier-1-Großvorhaben gar nicht erst zu evaluieren – und müssen sich nicht von Funktionsbroschüren beeindrucken lassen, deren Inhalte Sie nie aktivieren werden.

Wichtig bleibt das Bewusstsein für die Grenzen des Modells. Die Tier-Grenzen sind unscharf, Anbieter positionieren sich teilweise bewusst zwischen den Tiers, und ein und dasselbe Produkt kann in unterschiedlichen Ausbaustufen oder Editionen mehrere Tiers bedienen. Die Einteilung ersetzt deshalb keine echte Anforderungsanalyse – sie ordnet das Spielfeld. Wenn Sie zuerst Ihre eigene Komplexität sauber vermessen und erst dann das passende Tier bestimmen, vermeiden Sie beide Mismatch-Fehler und schaffen die Grundlage für eine ERP-Entscheidung, die auch in einigen Jahren noch trägt. Die methodischen Schritte dieser Vermessung beschreiben wir vertieft im Leitfaden zur ERP-Auswahl.

Betriebs- und Hosting-Modelle jenseits von Cloud und On-Premise

Kaum eine Gegenüberstellung prägt die Diskussion über betriebliche Standardsoftware so stark wie das Begriffspaar Cloud gegen On-Premise. Es ist eingängig, aber es täuscht eine Klarheit vor, die der Wirklichkeit nicht standhält. Zwischen dem klassischen Eigenbetrieb im eigenen Serverraum und dem reinen, abonnementbasierten Mietdienst aus dem Netz liegt ein ganzes Feld von Zwischenstufen, die sich nicht sauber dem einen oder dem anderen Lager zuordnen lassen. Gehostete Systeme, dedizierte Instanzen bei einem Provider, Managed-Hosting mit umfassendem Servicepaket und hybride Aufstellungen mit verteilten Komponenten sind keine Randerscheinungen, sondern für viele Betriebe die tatsächlich gewählte Realität. Dieser Abschnitt fächert diese Modelle auf, ordnet sie entlang einer durchgehenden Logik und zeigt vor allem, worauf es bei der Wahl wirklich ankommt: nicht das Etikett, sondern die Frage, wer für welche Betriebsaufgabe geradesteht.

Wichtig zur Abgrenzung: Es geht hier ausschließlich um die Betriebs- und Hosting-Dimension, also darum, wo ein System läuft und wer es technisch verantwortet. Die davon getrennte Frage, wie die Software intern aufgebaut ist und ob sich mehrere Kunden eine Instanz teilen, behandeln wir an anderer Stelle. Auch wer ein System architektonisch trennt, kann es in ganz unterschiedlichen Modellen betreiben, und genau diese Trennung der Fragen schützt vor folgenschweren Verwechslungen bei der ERP-Auswahl.

Warum die Cloud/On-Premise-Dichotomie zu grob ist

Die Zweiteilung suggeriert, es gäbe nur zwei Pole: entweder Sie betreiben alles selbst, oder Sie mieten alles fertig. Tatsächlich beschreibt jedes Betriebsmodell eine bestimmte Aufteilung von Verantwortung über mehrere Ebenen hinweg. Zu diesen Ebenen gehören die physische Infrastruktur aus Gebäude, Strom, Kühlung und Netzanbindung, darüber die Hardware aus Servern und Speicher, darauf die Virtualisierung und das Betriebssystem, dann die Datenbank, schließlich die ERP-Anwendung selbst und zuletzt die Verantwortung für Daten, Konfiguration und Benutzer. Bei jeder dieser Ebenen lässt sich getrennt festlegen, ob Sie als Kunde oder ein Dienstleister zuständig ist.

Genau hier liegt der Kern der Sache: Die verschiedenen Modelle unterscheiden sich nicht in einem einzigen An-oder-Aus-Schalter, sondern darin, an welcher Stelle die Trennlinie zwischen Ihrer Verantwortung und der des Anbieters verläuft. Je weiter diese Linie nach oben wandert, desto mehr Betriebslast nimmt der Anbieter Ihnen ab und desto weniger Gestaltungsspielraum behalten Sie. Wer das verstanden hat, erkennt, dass zwischen den beiden vermeintlichen Polen eine Stufenleiter liegt, auf der man sich genau die Sprosse aussuchen kann, die zum eigenen Reifegrad, zur eigenen Risikobereitschaft und zu den eigenen regulatorischen Pflichten passt.

Klassisches On-Premise im eigenen Rechenzentrum

Am einen Ende der Leiter steht der vollständige Eigenbetrieb. Beim klassischen On-Premise-Modell steht die Hardware in Ihren eigenen Räumen oder in von Ihnen angemieteter Fläche, und Sie verantworten praktisch jede Ebene selbst. Ihr Team beschafft und wartet die Server, hält das Betriebssystem aktuell, betreibt die Datenbank, spielt Updates der ERP-Anwendung ein, organisiert die Datensicherung, härtet das System gegen Angriffe und sorgt für die nötige Verfügbarkeit durch redundante Auslegung und Notfallpläne. Der Anbieter der Software liefert Ihnen die Programme und gegebenenfalls Wartungsverträge für Korrekturen, doch der laufende Betrieb bleibt vollständig in Ihrer Hand.

Dieses Modell gewährt maximale Kontrolle. Sie bestimmen den Zeitpunkt jedes Updates, behalten Ihre Daten physisch im eigenen Haus und können das System tief an die eigene Infrastruktur anbinden. Diese Kontrolle hat einen Preis, der nicht nur in der Hardware liegt, sondern vor allem im dauerhaften Bedarf an qualifiziertem Personal. Wer im eigenen Rechenzentrum betreibt, braucht Fachleute für Server, Netzwerk, Datenbanken und Sicherheit, und zwar verlässlich auch im Urlaub, bei Krankheit und nachts, wenn ein Ausfall das Tagesgeschäft lahmlegt. Für Betriebe mit gewachsener IT-Mannschaft und besonderen Anforderungen ist das ein gangbarer und manchmal alternativloser Weg, etwa wenn ein Warenwirtschaftssystem eng mit Produktionsmaschinen oder Lagertechnik vor Ort verzahnt ist und niedrige Latenz zwingend erforderlich ist.

Gehostetes ERP beim Dienstleister: Hosting und ASP

Die nächste Stufe verlagert die Hardware aus dem eigenen Haus heraus, ohne dass Sie deshalb gleich zum Mieter eines fertigen Dienstes werden. Beim klassischen Hosting stellt ein Dienstleister Ihnen Server in seinem Rechenzentrum bereit, auf denen Ihre ERP-Installation läuft. Die physische Infrastruktur, also Gebäude, Strom, Kühlung und Netzanbindung, verantwortet der Provider. Die Betriebssystem- und Anwendungsebene kann je nach Vertrag weiterhin bei Ihnen liegen. Sie betreiben dann gewissermaßen Ihre eigene Installation, nur eben auf fremder Hardware. Diese Spielart entlastet Sie von der Sorge um Hardwarebeschaffung und Rechenzentrumsbetrieb, lässt Ihnen aber die Hoheit über Software und Updates.

Eine historisch wichtige Variante ist das Application-Service-Providing, kurz ASP. Dabei stellte ein Dienstleister eine zentral installierte Anwendung mehreren Kunden über das Netz zur Verfügung, lange bevor der Begriff Cloud üblich wurde. ASP gilt als konzeptioneller Vorläufer dessen, was heute als Software aus dem Netz verstanden wird, betrieb die Anwendung jedoch typischerweise als gesonderte Installation je Kunde und nicht als geteilten Mehrmandantendienst. Wer dem Begriff in älteren Verträgen oder Systembeschreibungen begegnet, sollte ihn als gehostetes Bereitstellungsmodell einordnen, dessen Verantwortungsteilung im Einzelfall genau zu klären ist, weil die Ausgestaltung stark variierte.

Managed-Hosting und Betreibermodelle als Zwischenstufen

Zwischen dem reinen Hardware-Hosting und dem vollständig fremdbetriebenen Dienst liegt das Managed-Hosting. Hier übernimmt der Dienstleister nicht nur die Infrastruktur, sondern auch den laufenden Betrieb der darüberliegenden Schichten: Er pflegt das Betriebssystem, wartet die Datenbank, spielt Sicherheitsaktualisierungen ein, überwacht die Systeme rund um die Uhr und kümmert sich um die Datensicherung. Sie als Kunde behalten Ihre eigene, dedizierte Umgebung und meist erheblichen Einfluss auf Versionsstände und Konfiguration, geben aber die tägliche Betriebslast ab. Managed-Hosting ist damit die Antwort auf das zentrale Dilemma des Eigenbetriebs: Sie wollen Kontrolle über das System, aber nicht die volle Personallast des Rechenzentrumsbetriebs tragen.

Eine Steigerung dieses Gedankens sind echte Betreibermodelle, bei denen ein Partner die komplette Verantwortung für den Betrieb Ihrer ERP-Landschaft übernimmt und vertraglich an Servicezielen gemessen wird. Statt einzelner Leistungen kaufen Sie hier ein Ergebnis ein, etwa eine zugesicherte Verfügbarkeit, definierte Reaktionszeiten bei Störungen und die fortlaufende Aktualität des Systems. Der Betreiber bündelt dazu Infrastruktur, Administration, Wartung und oft auch Anwendungsbetreuung in einem Vertrag. Solche Modelle sind besonders im Mittelstand attraktiv, wo eigene IT-Ressourcen knapp sind und der Fokus auf dem Kerngeschäft liegt; Hinweise zur passenden Ausgestaltung im Mittelstand vertieft unsere Seite zum Thema ERP im Mittelstand. Entscheidend ist, dass Sie die zugesagten Leistungen, ihre Grenzen und die Verantwortung für Daten und Konfiguration im Vertrag präzise fixieren, denn was nicht ausdrücklich beim Betreiber liegt, bleibt im Zweifel bei Ihnen.

Private Cloud: dedizierte Instanz beim Provider oder Hyperscaler

Der Begriff Private Cloud bezeichnet eine Betriebsform, bei der Ihnen dedizierte, also exklusiv für Sie reservierte Ressourcen in einer virtualisierten Umgebung bereitstehen. Anders als beim geteilten öffentlichen Dienst laufen Ihre Systeme nicht auf einer mit fremden Kunden gemeinsam genutzten Mandantenbasis, sondern auf abgegrenzten, Ihnen zugeordneten Kapazitäten. Diese können in einem dedizierten Bereich bei einem großen Infrastrukturanbieter liegen, bei einem spezialisierten Provider oder sogar als private Wolke im eigenen Rechenzentrum, betrieben mit Cloud-Technologien wie automatischer Bereitstellung und elastischer Skalierung.

Die Private Cloud verbindet zwei Welten: die Bereitstellungseleganz der Cloud, also schnelle Skalierung und weitgehend automatisierten Betrieb, mit der Abgrenzung und Kontrolle einer eigenen Umgebung. Die Verantwortungsteilung hängt stark davon ab, wie tief der Anbieter in den Betrieb eingebunden ist. Stellt er nur die virtuelle Infrastruktur bereit, verantworten Sie die Anwendung und ihre Pflege selbst. Bietet er einen verwalteten Dienst, übernimmt er auch hier Betriebssystem, Datenbankpflege und Aktualisierungen. Für regulierte Branchen mit besonderen Anforderungen an Abschottung und Nachweisbarkeit ist die Private Cloud oft der Kompromiss der Wahl, weil sie moderne Betriebsvorteile bietet, ohne die Daten mit anderen Mandanten zu vermengen.

Public-Cloud-SaaS: der vollständig fremdbetriebene Dienst

Am anderen Ende der Leiter steht die Software, die Sie als reinen Dienst beziehen. Beim Public-Cloud-Dienst betreibt der Anbieter die gesamte Kette vom Rechenzentrum bis zur Anwendung und stellt Ihnen das ERP über das Netz als laufenden Service bereit. Sie kümmern sich weder um Hardware noch um Betriebssystem, Datenbank oder das Einspielen von Updates. Der Anbieter aktualisiert die Software zentral, sorgt für Datensicherung, Verfügbarkeit und die technische Absicherung der Plattform und skaliert die Kapazität nach Bedarf. Ihre Verantwortung schrumpft auf die oberste Ebene: die Verwaltung Ihrer Benutzer, die fachliche Konfiguration im vorgesehenen Rahmen und natürlich die Richtigkeit und Pflege Ihrer eigenen Daten.

Diese weitgehende Entlastung ist der größte Vorteil und zugleich die größte Einschränkung. Sie geben die Update-Hoheit ab und folgen dem Takt des Anbieters, der Versionen für alle Kunden zentral fortschreibt. Tiefe individuelle Eingriffe in das System sind in der Regel nicht möglich, Anpassungen erfolgen über vorgesehene Konfigurations- und Erweiterungspunkte. Im Gegenzug entfällt nahezu der gesamte technische Betriebsaufwand. Wichtig bleibt auch hier: Dass der Anbieter den Betrieb übernimmt, entbindet Sie nicht von Ihrer Verantwortung für die Daten als solche. Die Pflicht, eine eigene Sicherungs- und Ausstiegsstrategie zu durchdenken, bleibt bestehen, denn der Plattformbetrieb schützt Daten technisch, ersetzt aber kein Konzept für den Fall eines Anbieterwechsels.

Die Verantwortungsleiter im Überblick

Die folgende Stufenleiter ordnet die Modelle vom selbstbetriebenen On-Premise bis zum vollständig fremdbetriebenen Public-Cloud-Dienst. An jeder Stufe ist markiert, wie sich die Last für Betrieb, Updates und Sicherheit zwischen Ihnen als Kunde und dem Anbieter verschiebt. Lesen Sie die Leiter als Spektrum: Mit jeder Sprosse wandert mehr Verantwortung vom Kunden zum Anbieter.

Die Leiter macht zugleich deutlich, dass keine Stufe pauschal besser ist als eine andere. Sie verschieben mit jedem Schritt nach oben Betriebslast und Personalbedarf zum Anbieter, geben aber im selben Maß Kontrolle und Gestaltungsspielraum ab. Die richtige Sprosse ist diejenige, deren Mischung aus Entlastung und Kontrolle zu Ihrer IT-Reife, Ihren Anforderungen und Ihrem Budget passt. Bei der Strukturierung dieser Abwägung unterstützt eine neutrale Begleitung im Rahmen eines ERP-Consultings, das die Verantwortungsteilung zum expliziten Auswahlkriterium macht.

Hybrid-Betrieb mit verteilten Komponenten

Selten ist die Wirklichkeit eine einzige Stufe. Viele Betriebe betreiben ihre Landschaft hybrid, verteilen also Komponenten gezielt über mehrere Modelle. Ein typisches Muster hält besonders sensible oder eng mit der Produktion verzahnte Teile vor Ort und verlagert andere Funktionen in einen fremdbetriebenen Dienst. So kann etwa die Fertigungssteuerung mit ihren niedrigen Latenzanforderungen on-premise bleiben, während Auswertung, Personalfunktionen oder die Anbindung externer Partner aus der Cloud kommen. Auch ein gestaffelter Übergang ist verbreitet: Ein Betrieb startet im Eigenbetrieb und verlagert über die Zeit Schritt für Schritt Funktionen in betreute Modelle.

Der Reiz des Hybrid-Betriebs liegt darin, für jede Funktion das passende Modell zu wählen, statt sich auf einen Kompromiss für die gesamte Landschaft festzulegen. Der Preis ist gestiegene Komplexität. Verteilte Komponenten müssen über sichere Verbindungen zusammenarbeiten, Daten müssen konsistent zwischen den Welten fließen, und die Verantwortungsteilung wird vielschichtiger, weil sie nun je Komponente zu klären ist. Wer hybrid betreibt, braucht ein klares Bild davon, welche Datenflüsse die Modellgrenzen überschreiten und wo im Störungsfall die Zuständigkeit liegt. Die Integration der verteilten Teile zu einer stimmigen Gesamtlösung ist dabei eine Disziplin für sich, die wir auf der Seite zur ERP-Lösung näher beleuchten.

Datenstandort und digitale Souveränität als Entscheidungsfaktor

Quer durch alle Modelle zieht sich eine Frage, die für viele Betriebe heute mit über die Wahl entscheidet: Wo liegen die Daten physisch, und welcher Rechtsordnung unterliegt ihr Betrieb? Der Datenstandort bezeichnet den geografischen Ort der Rechenzentren, in denen Ihre Geschäftsdaten gespeichert und verarbeitet werden. Beim Eigenbetrieb ist dieser Ort offenkundig: Ihr eigenes Haus. Je weiter ein Modell in Richtung fremdbetriebener Dienst rückt, desto wichtiger wird es, sich diesen Ort ausdrücklich zusichern zu lassen, denn ein Anbieter kann Daten grundsätzlich in verschiedenen Regionen verarbeiten.

Eng damit verbunden ist der Gedanke der digitalen Souveränität, also der Fähigkeit, die Kontrolle über die eigenen Daten und ihre Verarbeitung wirksam zu behalten. Dabei geht es nicht allein um den Speicherort, sondern auch um die Frage, welchem nationalen Recht der Betreiber unterliegt und wer unter welchen Bedingungen Zugriff verlangen könnte. Ein Anbieter mit Rechenzentrum in der gewünschten Region kann gleichwohl einer fremden Rechtsordnung unterstehen, die im Zweifel Zugriff vorsieht. Souveränität verlangt daher, Standort, Betreiberzugehörigkeit und Vertragsgestaltung zusammen zu betrachten. Für Betriebe mit besonders schutzbedürftigen Daten oder strengen regulatorischen Vorgaben ist genau dieser Aspekt häufig der Grund, eine Private Cloud oder ein Betreibermodell mit zugesichertem Standort dem reinen öffentlichen Dienst vorzuziehen.

In der Praxis bündeln sich diese Überlegungen zu einer Reihe von Fragen, die Sie bei jedem Modell jenseits des Eigenbetriebs stellen sollten: An welchem geografischen Ort werden meine Daten gespeichert und verarbeitet, und ist dieser Ort vertraglich festgeschrieben? Welcher Rechtsordnung unterliegt der Betreiber? Wer hat unter welchen Bedingungen Zugriff, und wie wird das nachgewiesen? Wie bekomme ich meine Daten am Vertragsende vollständig und in nutzbarem Format zurück? Und wer haftet, wenn eine zugesicherte Verfügbarkeit oder Sicherheit verletzt wird? Diese Fragen sind keine Formalität, sondern der eigentliche Hebel, mit dem Sie die Verantwortungsteilung eines fremdbetriebenen Modells überprüfbar machen. Wer sie vor der Entscheidung klärt, wählt nicht ein Schlagwort, sondern eine nachweisbare Aufteilung von Pflichten, und genau darauf kommt es bei der Betriebsform eines ERP an.

Integrationsplattformen und iPaaS: ERP als Knoten in der Systemlandschaft

Ein modernes ERP-System steht nie für sich allein. Es ist eingebettet in eine Landschaft aus Onlineshops, CRM-Systemen, Versanddienstleistern, Banking-Anbindungen, Business-Intelligence-Werkzeugen, Lohnabrechnung, Produktdaten-Management und unzähligen Fachanwendungen. Genau an dieser Stelle entscheidet sich, ob das ERP zum reibungslos arbeitenden Herzstück der digitalen Prozesse wird oder zur Datendrehscheibe verkommt, an der ständig manuell nachgepflegt, exportiert und importiert wird. Während die Frage nach einzelnen Schnittstellen als Auswahlkriterium an anderer Stelle behandelt wird, geht es hier um eine eigenständige Kategorie von Bausteinen: die Integrationsschicht, die zwischen den Systemen liegt und sie überhaupt erst zu einem Verbund verknüpft. Diese Schicht hat sich in den vergangenen Jahren von einer technischen Randnotiz zu einem strategischen Architekturthema entwickelt, das die Entscheidung über die gesamte ERP-Strategie mitbestimmt.

Der Kern des Problems ist einfach zu benennen: Daten entstehen an vielen Orten, müssen aber konsistent über Systemgrenzen hinweg fließen. Eine Bestellung im Shop erzeugt einen Auftrag im ERP, der wiederum einen Versandauftrag, eine Rechnung, eine Lagerbuchung und eine Kennzahl im Reporting auslöst. Wer diese Kette über direkte, paarweise Anbindungen verdrahtet, baut schnell ein dichtes Geflecht von Punkt-zu-Punkt-Verbindungen auf, das mit jeder neuen Anwendung exponentiell komplexer wird. Integrationsplattformen verfolgen den entgegengesetzten Ansatz: Sie bündeln den Datenverkehr an einer zentralen, beherrschbaren Stelle. Dieser Abschnitt erklärt die wesentlichen Plattform-Ansätze, ordnet ein, wann sich der Schritt von der Direktverbindung zur Plattform lohnt, und zeigt, wie diese Frage die Wahl zwischen einer integrierten Suite und einer Best-of-Breed-Landschaft beeinflusst.

iPaaS: Integration Platform as a Service als Cloud-Integrationsschicht

Der Begriff iPaaS steht für Integration Platform as a Service und bezeichnet eine in der Cloud bereitgestellte Plattform, die der Verknüpfung von Anwendungen, Datenquellen und Diensten dient. Anders als klassische Integrationswerkzeuge, die im eigenen Rechenzentrum installiert und betrieben werden, wird iPaaS als Dienst gemietet und vom Anbieter betrieben, gewartet und skaliert. Der Anwender modelliert seine Datenflüsse in einer meist grafischen Oberfläche, in der er Quell- und Zielsysteme auswählt, Felder einander zuordnet (das sogenannte Mapping), Transformationsregeln definiert und Auslöser festlegt, die einen Datenfluss starten.

Charakteristisch für iPaaS sind drei Eigenschaften. Erstens stellt die Plattform eine Sammlung vorgefertigter Verbindungsbausteine bereit, mit denen verbreitete Systeme ohne Programmierung angebunden werden. Zweitens abstrahiert sie die technischen Unterschiede der angebundenen Systeme – ob ein System über eine moderne REST-Schnittstelle, einen Dateiimport oder ein älteres Protokoll kommuniziert, wird hinter einer einheitlichen Logik verborgen. Drittens verlagert iPaaS Betrieb und Wartung der Integration aus dem eigenen Haus zum Plattformbetreiber, was den Pflegeaufwand reduziert, zugleich aber eine Abhängigkeit erzeugt, die bei der Architekturentscheidung mitgedacht werden sollte.

Der typische Einsatzfall für iPaaS ist eine Landschaft mit mehreren Cloud-Anwendungen, die regelmäßig und zuverlässig Daten austauschen müssen, ohne dass für jede Verbindung ein eigenes Entwicklungsprojekt aufgesetzt wird. Gerade im wachsenden Mittelstand, der schrittweise einzelne Funktionen in spezialisierte Cloud-Dienste auslagert, hat sich iPaaS als pragmatischer Mittelweg etabliert: Es vermeidet sowohl den Wildwuchs unkontrollierter Einzelschnittstellen als auch den schweren Apparat einer großen unternehmensweiten Integrationsinfrastruktur. Bei der ERP-Auswahl lohnt es sich daher, frühzeitig zu klären, welche Plattform der ERP-Anbieter selbst empfiehlt oder mitliefert und wie offen das System für externe Integrationsdienste ist.

Middleware und ESB: das klassische Rückgrat der Systemintegration

Bevor iPaaS in der Cloud entstand, wurde die Aufgabe der Systemkopplung von Middleware übernommen – einer Software-Schicht, die zwischen den Anwendungen vermittelt. Die ausgereifteste Ausprägung dieses Gedankens ist der Enterprise Service Bus (ESB). Der Name beschreibt das Prinzip treffend: Statt jedes System einzeln mit jedem anderen zu verbinden, dockt jede Anwendung an einen gemeinsamen „Bus" an. Der Bus übernimmt das Weiterleiten der Nachrichten, die Umwandlung der Datenformate, die Verteilung an mehrere Empfänger und die Überwachung des Nachrichtenverkehrs.

Ein ESB bringt typischerweise Funktionen mit, die über das reine Verbinden hinausgehen: garantierte Zustellung von Nachrichten auch bei zeitweiligem Ausfall eines Zielsystems, Pufferung über Warteschlangen, Protokollvermittlung zwischen unterschiedlichen technischen Standards sowie die Orchestrierung mehrstufiger Abläufe. Diese Robustheit hat ihren Preis in Form von Einrichtungs- und Betriebsaufwand. ESB-Lösungen werden klassisch im eigenen Rechenzentrum oder in einer dedizierten Umgebung betrieben und erfordern spezialisiertes Know-how. Sie sind das Mittel der Wahl, wenn große Datenmengen, hohe Verfügbarkeitsanforderungen, viele angebundene Systeme und komplexe Verarbeitungslogik aufeinandertreffen – also häufig in Konzernen oder im gehobenen Mittelstand mit gewachsener, heterogener IT.

Die Grenze zwischen klassischer Middleware/ESB und modernem iPaaS verschwimmt zunehmend. Viele Anbieter offerieren ihre Integrationsfunktionen heute sowohl als betreibbare Software als auch als Cloud-Dienst, und die Konzepte – Nachrichtenvermittlung, Transformation, Orchestrierung – sind weitgehend deckungsgleich. Der entscheidende Unterschied liegt im Betriebsmodell und in der Verantwortung: Wer die volle Kontrolle und Datenhoheit im eigenen Haus behalten will, tendiert zur betreibbaren Middleware; wer Aufwand und Skalierung abgeben möchte, wählt iPaaS. Diese Abwägung berührt unmittelbar die Überlegungen zur passenden ERP-Lösung, denn sie bestimmt, wie viel Integrations-Eigenleistung das Unternehmen dauerhaft tragen muss.

API-Management: Schnittstellen ordnen, sichern und steuern

Während Middleware und iPaaS vor allem den Datenfluss zwischen Systemen organisieren, befasst sich das API-Management mit der geordneten Bereitstellung und Nutzung von Programmierschnittstellen. APIs (Application Programming Interfaces) sind die definierten Zugänge, über die Systeme Funktionen und Daten füreinander verfügbar machen. In einer wachsenden Landschaft entstehen schnell viele solcher Zugänge – und ohne übergeordnete Steuerung weiß bald niemand mehr, welche Schnittstelle existiert, wer sie nutzt, wie sie versioniert ist und ob sie ausreichend abgesichert ist.

Eine API-Management-Plattform schafft hier Ordnung. Sie übernimmt typischerweise vier Aufgaben. Sie stellt ein Gateway bereit, über das aller API-Verkehr läuft und zentral kontrolliert wird. Sie regelt Authentifizierung und Autorisierung, also wer auf welche Schnittstelle zugreifen darf. Sie begrenzt und überwacht die Nutzung über Mechanismen wie Ratenbegrenzung (Rate Limiting) und Kontingente. Und sie dokumentiert die verfügbaren Schnittstellen in einem Katalog oder Entwicklerportal, sodass interne Teams oder externe Partner die APIs auffinden und einbinden können. Gerade wenn ein ERP-System als zentrale Datenquelle für Partner, Portale oder mobile Anwendungen dient, wird API-Management vom Nice-to-have zur Notwendigkeit.

Für die Praxis ist wichtig zu verstehen, dass API-Management und Integrationsplattform unterschiedliche, sich ergänzende Aufgaben erfüllen. Die Integrationsplattform sorgt dafür, dass Daten zwischen Systemen fließen und korrekt transformiert werden; das API-Management sorgt dafür, dass die Zugänge, über die dieser Austausch stattfindet, sicher, dokumentiert und kontrolliert sind. In modernen Architekturen treten beide häufig kombiniert auf, etwa wenn ein ERP-Hersteller eine offene API anbietet und gleichzeitig eine Integrationsplattform mitliefert, über die diese API komfortabel angebunden wird.

Vorgefertigte Konnektoren: schnelle Anbindung ohne Eigenentwicklung

Ein wesentlicher Wert moderner Integrationsplattformen liegt in ihren vorgefertigten Konnektoren. Ein Konnektor ist ein fertig entwickelter, getesteter Verbindungsbaustein für ein bestimmtes Zielsystem – etwa für einen bekannten Shop, einen Zahlungsdienstleister, ein verbreitetes CRM oder einen Versanddienst. Statt die technische Anbindung eines Systems von Grund auf zu programmieren, wählt man den passenden Konnektor aus, konfiguriert Zugangsdaten und Feldzuordnungen und ist binnen kurzer Zeit betriebsbereit.

Der Nutzen ist doppelt. Zum einen verkürzen Konnektoren die Einführungszeit erheblich, weil das Rad nicht jedes Mal neu erfunden wird. Zum anderen verlagern sie die Pflegeverantwortung: Ändert ein angebundenes System seine Schnittstelle, aktualisiert idealerweise der Plattformanbieter den Konnektor, ohne dass das Unternehmen selbst eingreifen muss. Diese Pflege ist in der Praxis oft wertvoller als die initiale Einsparung, denn Schnittstellen verändern sich über die Jahre, und eine eigenentwickelte Anbindung muss jedes Mal nachgezogen werden.

Allerdings haben Konnektoren auch Grenzen. Sie decken die gängigen Standardfälle ab; sehr spezielle Prozesse, ungewöhnliche Datenmodelle oder branchenspezifische Sonderlogik lassen sich häufig nicht vollständig über einen Standardkonnektor abbilden. In solchen Fällen bleibt entweder eine ergänzende Eigenentwicklung nötig, oder es entsteht ein Anpassungsbedarf, der den vermeintlichen Vorteil der schnellen Anbindung relativiert. Bei der Bewertung eines Konnektors ist daher zu prüfen, wie tief er die benötigten Prozesse wirklich unterstützt und nicht nur, ob er das Zielsystem grundsätzlich verbindet. Diese Detailtiefe gehört in jede seriöse ERP-Einführung als eigener Prüfpunkt.

Marktplätze und App-Stores als Erweiterungsökosystem

Moderne Cloud-ERP-Anbieter setzen zunehmend auf Marktplätze und App-Stores, um ihr System um Funktionen zu erweitern, die der Hersteller selbst nicht abbildet. Das Prinzip ähnelt dem von App-Stores auf Mobilgeräten: Auf einer zentralen Plattform bieten der ERP-Hersteller und unabhängige Drittanbieter Erweiterungen, Branchenmodule, Konnektoren und Zusatzdienste an, die sich mit überschaubarem Aufwand in das Basissystem einbinden lassen.

Dieses Ökosystem hat erhebliche strategische Bedeutung. Ein lebendiger Marktplatz ist ein Indiz dafür, dass ein ERP-System offen gebaut ist und dass Drittanbieter es als attraktive Plattform betrachten. Er erlaubt es Unternehmen, fehlende Funktionen gezielt zu ergänzen, ohne den Kern des Systems anzupassen oder den Hersteller mit Einzelaufträgen zu beauftragen. Damit verschiebt sich die Erweiterung weg von individueller Programmierung hin zur Auswahl und Konfiguration vorhandener Bausteine – ein Modell, das Investitionssicherheit erhöht, weil die Erweiterungen einem definierten technischen Rahmen folgen und vom Anbieter mitgepflegt werden.

Gleichzeitig verdient das Ökosystem eine kritische Betrachtung. Die Qualität der angebotenen Erweiterungen schwankt, die Verantwortlichkeit bei Fehlern verteilt sich zwischen ERP-Hersteller und Drittanbieter, und es entsteht eine zusätzliche Abhängigkeit von Anbietern, deren Fortbestand nicht garantiert ist. Wer Erweiterungen aus einem Marktplatz einsetzt, sollte daher klären, wer für Wartung, Datenschutz und Kompatibilität bei künftigen Versionswechseln einsteht. Die Existenz eines starken Marktplatzes ist gerade für mittelständische Anwender ein gewichtiges Argument, das in die ERP-Bewertung im Mittelstand einfließen sollte – sie zeigt an, wie zukunftsfähig und erweiterbar eine Lösung tatsächlich ist.

Wann lohnt sich eine Integrationsplattform statt direkter Anbindung?

Die zentrale architektonische Frage lautet: Reicht eine direkte Punkt-zu-Punkt-Anbindung, oder rechtfertigt die Situation eine eigene Integrationsschicht? Eine Direktverbindung verknüpft zwei Systeme unmittelbar miteinander. Bei wenigen Systemen, stabilen und seltenen Datenflüssen und begrenzter Komplexität ist das der einfachste und kostengünstigste Weg – eine zusätzliche Plattform wäre überdimensioniert. Mit jeder weiteren Anwendung steigt jedoch die Zahl der möglichen Verbindungen überproportional an, und das Geflecht wird unübersichtlich, fehleranfällig und teuer in der Wartung.

Eine Integrationsplattform spielt ihre Stärken aus, sobald mehrere der folgenden Bedingungen zusammentreffen: Es sind viele Systeme anzubinden; Datenflüsse sind häufig, zeitkritisch oder müssen zuverlässig wiederholt werden; Daten müssen zwischen Formaten transformiert werden; mehrere Empfänger benötigen dieselben Daten; oder es besteht ein erhöhter Anspruch an Überwachung, Fehlerbehandlung und Nachvollziehbarkeit. In diesen Fällen amortisiert sich die zusätzliche Schicht, weil sie Wartung, Erweiterung und Fehlersuche dramatisch vereinfacht und weil neue Anwendungen ergänzt werden können, ohne bestehende Verbindungen zu berühren.

Die Entscheidung ist dabei keine reine Bauchsache, sondern lässt sich anhand der Zahl der Systeme, der Häufigkeit und Kritikalität der Datenflüsse und des erwarteten Wachstums der Landschaft begründen. Wichtig ist, sie bewusst zu treffen, statt durch das schrittweise Hinzufügen von Einzelverbindungen unbemerkt in ein nicht mehr beherrschbares Geflecht hineinzuwachsen.

Wie die Integrationsfrage Suite und Best-of-Breed beeinflusst

Die Verfügbarkeit leistungsfähiger Integrationsplattformen hat die alte Grundsatzfrage zwischen einer durchgängigen Suite und einer Best-of-Breed-Landschaft spürbar verändert. Eine Suite bietet alle wesentlichen Funktionen aus einer Hand und mit von Haus aus integrierten Datenflüssen; das Integrationsthema entschärft sich, weil die Bestandteile bereits aufeinander abgestimmt sind. Der Best-of-Breed-Ansatz kombiniert hingegen für jeden Bereich die jeweils beste spezialisierte Lösung – und steht und fällt mit der Qualität der Integration zwischen diesen Bausteinen.

Genau hier wirkt die Integrationsschicht als Hebel. Wo früher die aufwendige und fragile Kopplung spezialisierter Systeme ein starkes Argument für die geschlossene Suite war, senken iPaaS, vorgefertigte Konnektoren und offene APIs heute die Kosten und Risiken des Best-of-Breed-Modells erheblich. Eine professionelle Integrationsschicht macht es realistischer, ein spezialisiertes Shopsystem, ein eigenständiges CRM und ein dediziertes BI-Werkzeug verlässlich mit dem ERP zu verbinden, ohne dass jede Verbindung zum Dauerproblem wird. Die Best-of-Breed-Strategie gewinnt damit an Attraktivität – allerdings um den Preis, dass die Integrationsschicht selbst zu einer eigenständigen Komponente wird, die geplant, betrieben und gepflegt werden muss.

Umgekehrt verschiebt sich auch das Suite-Argument: Eine Suite reduziert nicht nur den Integrationsaufwand im Inneren, sondern verlagert ihn an die Außengrenze – die Anbindung an Systeme jenseits der Suite. Selbst wer sich für eine integrierte Lösung entscheidet, kommt also nicht ohne Gedanken zur Integration mit der übrigen Welt aus. Die ehrliche Schlussfolgerung lautet daher nicht „Suite oder Best-of-Breed", sondern: In beiden Fällen ist die Integrationsschicht eine bewusste Architekturentscheidung, deren Tragweite über Jahre wirkt. Wer diese Frage früh in der Konzeption mitdenkt – im Idealfall begleitet durch erfahrenes ERP-Consulting –, wählt nicht nur ein System, sondern legt fest, wie offen, erweiterbar und zukunftsfähig die gesamte Landschaft sein wird. Das ERP bleibt dabei der zentrale Knoten; die Integrationsplattform entscheidet darüber, wie tragfähig die Verbindungen zu allen anderen Knoten sind.

Häufige Fragen