Ein ERP ist selten „nur Software“: Stammdaten, Workflows, Rollen, Schnittstellen und Reporting hängen daran. Wer hier auf Open-Source-ERP setzt, gewinnt Transparenz und Gestaltungsfreiheit – muss aber Lizenzfolgen, Betriebsaufwand und Projektreife sauber bewerten. Drei häufig genutzte Optionen sind Odoo, ERPNext und Dolibarr. Sie unterscheiden sich weniger in „kann Feature X“, sondern in Architektur, Anpassungsmodell und Governance (Regeln, wie ein Projekt Entscheidungen trifft und Beiträge annimmt).
Welche ERP-Anforderungen sollten vorab konkret sein?
ERP-Auswahl scheitert in der Praxis oft daran, dass Anforderungen zu allgemein bleiben („CRM, Lager, Rechnungen“). Sinnvoller ist eine Prozesssicht: Welche Belege und Statuswechsel existieren, wer darf was freigeben, welche Daten müssen revisionssicher bleiben, und welche Systeme liefern oder konsumieren Daten (Shop, DMS, BI, Versand, SSO)?
Prozesse statt Module beschreiben
Beispiel: „Angebot → Auftrag → Lieferung → Rechnung“ klingt simpel, wird aber schnell komplex: Teillieferungen, Sammelrechnungen, Gutschriften, unterschiedliche Steuersätze, Projektgeschäft oder Abos. Ein ERP ist dann passend, wenn es diese Varianten mit möglichst wenig Sonderlogik abbildet. Sonderlogik ist nicht verboten – aber sie kostet Wartung.
Schnittstellen und Datenhoheit klären
Bei Einführung wird häufig unterschätzt, wie sehr das ERP zum „System of Record“ wird. Klarheit hilft: Welche Daten bleiben führend im ERP (Kunden, Artikel, Preise), welche im Shop, welche im Ticketsystem? Wer Self-Hosting plant, sollte außerdem Backup/Restore, Updates und Monitoring als echte Anforderungen behandeln, nicht als „später“.
Odoo, ERPNext, Dolibarr: Worin liegen die Grundunterschiede?
Alle drei decken typische ERP-Basisthemen ab, setzen aber unterschiedliche Schwerpunkte bei Zielgruppe, Erweiterbarkeit und Bedienkonzept. Ein Vergleich sollte daher nicht nur Funktionen zählen, sondern den „Betriebsmodus“ bewerten: Wie werden Anpassungen gebaut, wie werden Updates eingespielt, wie stabil ist das Ökosystem an Erweiterungen?
Odoo: starkes Ökosystem, klarer App-Ansatz
Odoo ist für viele Organisationen attraktiv, weil der Funktionsumfang groß ist und ein Marktplatz-/App-Gedanke gelebt wird. Für Entscheider:innen ist relevant: Odoo existiert in unterschiedlichen Editionen mit verschiedenen Lizenz- und Nutzungsbedingungen. Das wirkt sich direkt darauf aus, welche Module frei verfügbar sind und welche nicht. In der Praxis ist Odoo häufig dann passend, wenn Standardprozesse möglichst „out of the box“ laufen sollen und ein Partnernetzwerk genutzt wird, um Anpassungen kontrolliert umzusetzen.
ERPNext: prozessorientiert, konsistente Oberfläche
ERPNext richtet sich stark an integrierte Geschäftsprozesse und bietet ein vergleichsweise konsistentes Bedien- und Datenmodell. Anpassungen erfolgen typischerweise über ein Framework- und App-Konzept. Das ist vorteilhaft, wenn Teams Erweiterungen versionierbar entwickeln und sauber in Staging/Production ausrollen wollen. Wichtig ist die realistische Einschätzung, ob intern genug Know-how für Betrieb und Weiterentwicklung vorhanden ist – oder ob ein Dienstleister benötigt wird.
Dolibarr: pragmatisch, leichtgewichtig, schnell startklar
Dolibarr ist häufig dort überzeugend, wo „einfach starten“ zählt: kleinere Unternehmen, Vereine, Agenturen oder Projekte mit überschaubarem Prozessumfang. Der Funktionsumfang ist modular, die Einstiegshürde gering. Grenzen zeigen sich eher bei komplexen Abläufen, strengen Freigabeprozessen oder stark individualisierten Datenmodellen. Als Vorteil bleibt: weniger Komplexität kann weniger Wartung bedeuten.
Lizenz- und Nutzungsmodelle richtig einordnen
Bei ERP ist Lizenzierung nicht nur juristisch, sondern operativ relevant: Sie bestimmt, wie Anpassungen verteilt werden dürfen, ob Connectoren eingebunden werden können, und welche Pflichten bei Weitergabe entstehen. Dafür lohnt ein kurzer, korrekter Rahmen: GPL (Copyleft) verlangt bei Weitergabe von abgeleiteten Werken die Weitergabe unter derselben Lizenz; permissive Lizenzen wie MIT License sind deutlich freier bei der Wiederverwendung. Viele ERP-Ökosysteme kombinieren Open Source zudem mit kommerziellen Add-ons oder Enterprise-Editionen.
Wann Copyleft im ERP-Kontext relevant wird
Copyleft wird typischerweise wichtig, wenn Anpassungen oder Erweiterungen verteilt werden (z. B. an Kund:innen oder verbundene Unternehmen) oder wenn Komponenten so eng gekoppelt sind, dass sie als abgeleitetes Werk gelten könnten. Reines Hosting als Dienstleistung führt je nach Lizenz nicht automatisch zu Veröffentlichungspflichten. Entscheidend sind Lizenztext, Kopplung und Distributionsweg – deshalb sollten Compliance-Prozesse und eine klare Add-on-Strategie existieren.
SPDX und Lizenzpflege im Alltag
Für die interne Dokumentation helfen SPDX-Lizenzkennungen (standardisierte Kurzbezeichnungen), um Abhängigkeiten sauber zu erfassen. Praktisch ist das vor allem bei ERP-Anpassungen: eigene Module, Drittmodule, Bibliotheken, Container-Images. Wer ohnehin Softwarelieferketten sauber managen will, findet Anschluss an Themen wie SBOM und Richtlinien für Abhängigkeiten, etwa im Überblick zu Abhängigkeiten sauber managen.
Wie lässt sich Projektreife und Community-Governance bewerten?
ERP-Einführungen sind langfristig. Deshalb zählen Wartbarkeit, Release-Disziplin und Community-Qualität mehr als eine perfekte Demo. Gute Signale: nachvollziehbare Roadmaps, reproduzierbare Builds, klare Contribution-Guides, öffentlich einsehbare Issue-Tracker, regelmäßige Releases und ein realistischer Umgang mit Security-Themen (Security-Policy, Patch-Prozess).
Governance: Wer entscheidet, was ins Projekt kommt?
Community-Governance bestimmt, wie Konflikte gelöst werden, wie Maintainer ernannt werden und wie viel Einfluss einzelne Firmen haben. Für Unternehmen ist das nicht „Politik“, sondern Risiko-Management: Wenn ein einzelner Anbieter die Richtung allein bestimmt, kann ein Strategiewechsel (Open-Core-Ausbau, Prioritätenwechsel) die eigene Roadmap treffen. Ein gutes Zeichen ist, wenn Regeln transparent sind und Beiträge nachvollziehbar reviewed werden.
Wartung in der Praxis: Update-Fähigkeit schlägt Einmal-Anpassung
Viele ERP-Projekte scheitern nicht an der Einführung, sondern an Updates: zu viele „Quick Fixes“ direkt im Kern, unklare Tests, fehlende Staging-Umgebung. Nachhaltig ist ein Setup, in dem Anpassungen als separate Module versioniert werden, Migrationspfade bekannt sind und ein Testdatensatz existiert, der Kernprozesse (Bestellung, Lieferung, Rechnung, Storno) abdeckt.
Einführung und Betrieb: typische Stolpersteine und Gegenmaßnahmen
Ob On-Premises oder Cloud: ERP braucht Betriebsdisziplin. Dazu gehören Rollen und Verantwortlichkeiten (Produktverantwortung, Betrieb, Customizing), klare Change-Prozesse und saubere Datenmigration. Gerade bei Open Source ist die Versuchung groß, „noch schnell“ etwas umzubauen. Besser ist, Anpassungen zu priorisieren und standardnahe Prozesse zu bevorzugen.
Datenmigration: weniger ist oft mehr
Altdaten wirken wichtig, sind aber oft unvollständig oder inkonsistent. Häufig sinnvoll: nur offene Posten, aktive Kund:innen/Lieferant:innen, relevante Artikel und Preislisten migrieren; historische Belege archivieren und bei Bedarf referenzieren. Wichtig ist ein Abgleich von Steuerlogik, Nummernkreisen und Einheiten. Wenn PDF-Archivierung oder Signaturen Teil des Projekts sind, kann ein Blick auf PDF-Workflows mit OCR, Signaturen, Archivierung helfen, die Schnittstelle zwischen ERP und Dokumentenwelt sauber zu gestalten.
Betrieb: Backup, Monitoring, Rechtekonzept
Ein ERP ist geschäftskritisch. Daher sollten Backup/Restore geprobt werden (nicht nur konfiguriert), Logs zentral auswertbar sein und Rechte so aufgebaut werden, dass niemand mit „Admin überall“ arbeitet. Für Monitoring-Ansätze bietet sich die Orientierung an üblichen Open-Source-Stacks an, etwa in der Einordnung zu Prometheus vs. Zabbix, ohne dass das ERP selbst davon abhängig sein muss.
Entscheidungshilfe: Welches System passt zu welchem Kontext?
Statt „bestes ERP“ zählt die Passung. Die folgenden Kriterien sind in Projekten erfahrungsgemäß entscheidend: Prozesskomplexität, Anpassungsbedarf, internes Know-how, Partner-Verfügbarkeit und Lizenzmodell.
| Kriterium | Odoo | ERPNext | Dolibarr |
|---|---|---|---|
| Startgeschwindigkeit | hoch (viele Module/Partner), aber Editionswahl klären | mittel (saubere Prozessabbildung, Setup strukturieren) | sehr hoch (leichtgewichtig, schnell produktiv) |
| Komplexe Prozesse & Workflows | gut, abhängig von Modulen/Edition | gut (integrierte Prozesssicht) | eher begrenzt, je nach Use Case |
| Anpassungsmodell | Modul-/App-Ansatz, häufig partnergetrieben | App-/Framework-orientiert, gut versionierbar | Plugins/Module, pragmatisch, weniger „Engineering-Overhead“ |
| Betrieb & Updates | planbar, aber Disziplin bei Customizing nötig | gut planbar bei sauberer Trennung von Core/Apps | oft unkompliziert, solange Scope überschaubar bleibt |
| Typische Zielgruppe | wachsende KMU, die breites Ökosystem nutzen | KMU/Teams mit Wunsch nach konsistenter Suite | kleinere Organisationen, pragmatische Abläufe |
Konkrete Schritte für eine belastbare Auswahl
- Zwei Kernprozesse als „Referenzfälle“ definieren (z. B. Standardverkauf und Reklamation) und in jedem System durchspielen.
- Customizing-Regeln festlegen: Anpassungen nur als Module/Apps, keine direkten Core-Edits; Versionsverwaltung verpflichtend.
- Lizenz- und Editionsfragen vor dem PoC klären, inklusive Rechte an Eigenentwicklungen und Drittmodulen.
- Community und Wartung bewerten: Issue-Tracker-Latenz, Release-Rhythmus, Migrationspfade, Dokumentation.
- Betriebskonzept skizzieren: Backup/Restore-Test, Rollenmodell, Staging-Umgebung, Update-Fenster.
Open Source im ERP: Nachhaltigkeit aktiv gestalten
Open Source liefert nicht automatisch Stabilität; Stabilität entsteht durch Prozesse. Wer ein ERP langfristig betreiben will, sollte Beiträge und Feedback nicht als Einbahnstraße sehen: saubere Bugreports, reproduzierbare Cases, gegebenenfalls Upstream-Contributions. Das reduziert die eigene Wartungslast, weil Fixes im Projekt landen statt in lokalen Patches zu verrotten.
Mitwirkung ohne Überforderung
Mitwirken bedeutet nicht zwingend Code: Dokumentationskorrekturen, Tests von Release-Kandidaten, Übersetzungen oder das Bestätigen von Issues helfen Maintainer-Teams spürbar. Für Unternehmen lohnt sich zudem ein internes Budget für Wartung: Zeit für Updates, Review von Drittmodulen und gelegentliche Contributions. Das ist oft günstiger als ein „Big Bang“-Upgrade nach Jahren.
Abgrenzung zu benachbarten Plattformen
Ein ERP ist kein Ersatz für alle Systeme. Für Identity- und Rollenmanagement ist häufig ein separates IAM sinnvoll; die Einordnung zu Keycloak kann helfen, Single Sign-on und Rollen sauber zu trennen. Ebenso bleiben Ticketing, Monitoring und DMS oft spezialisierte Bausteine, die über Schnittstellen angebunden werden.
Wer die Auswahl auf Prozesse, Lizenzfolgen, Community-Struktur und Update-Fähigkeit stützt, bekommt ein ERP, das nicht nur heute passt, sondern auch in zwei Jahren noch wartbar bleibt.
