Warum „fertige ERPs“ oft an der Realität scheitern
Warum „fertige ERPs“ oft an der Realität scheitern
Standard-ERPs sind nicht per se schlecht. Sie werden dann problematisch, wenn sie in einer gewachsenen Organisation als „Einheitslösung“ dienen sollen. Typische Muster, die wir in Projekten sehen:
- Prozessverbiegung statt Prozessabbildung: Man passt sich dem System an – nicht umgekehrt.
- Customizing im Kern: Änderungen werden „hineinprogrammiert“ und machen Updates riskant oder unmöglich.
- Insellösungen entstehen trotzdem: Für Sonderfälle baut man Nebenlösungen, Exporte, Workarounds.
- Vendor Lock-in: Lizenzlogik, Cloud-Zwang oder proprietäre Schnittstellen reduzieren eure Freiheit.
- Wachstum wird teuer: Neue Standorte, neue Prozesse, neue Integrationen werden zur Dauerbaustelle.
Das Ergebnis: Das ERP wird nicht zur Wertschöpfungsbasis, sondern zur Bremse. Und dann beginnt der Kreislauf aus „noch ein Tool“, „noch ein Interface“ und „noch ein Excel-Export“.
ERPNext + Frappe: ERP als Kern, Framework als Wachstumsschicht
ERPNext liefert einen etablierten ERP-Kern. Der entscheidende Hebel ist aber das Frappe Framework: Damit wird das ERP zu einer Plattform, auf der ihr zusätzliche Applikationen sauber entwickeln könnt – getrennt vom Kern, strukturiert und langfristig wartbar.
Was „erweiterbar“ im Mittelstand konkret bedeutet
- Zusätzliche Apps statt Kern-Hacks: Erweiterungen werden als eigene Module umgesetzt, nicht als fragile Eingriffe in den Standard.
- Integrationen als Normalfall: Schnittstellen zu CRM, DMS, Shop, Maschinen/IoT, BI oder Datenbanken sind Teil des Designs.
- Upgrade-Fähigkeit bleibt realistisch: Weiterentwicklung ohne „Update-Angst“ – weil Erweiterungen sauber gekapselt sind.
- Skalierung über Jahre: Neue Bereiche, neue Anforderungen, neue Datenquellen – ohne Systembruch.
- Prozesse werden datengetrieben besser: Wenn Datenflüsse stimmen, kann man Abläufe iterativ optimieren statt jedes Mal neu zu bauen.
- App-basierte Erweiterungen und klare Trennung von Standard und Custom
- Saubere Datenmodelle und Workflows im Framework statt „Hardcode überall“
- API-/Schnittstellenfähigkeit für System- und Datenbank-Integrationen
- On-Premise-Betriebskonzepte für Sicherheit, Compliance und Datenhoheit
- Wartungs- und Upgrade-Strategien als Teil der Architektur (nicht als Nachgedanke)





