Individuelles ERP oder angepasstes fertiges ERP?

Nach Einschätzung der Mesterséges Intelligencia Központ Kft., eines Softwareentwicklungsunternehmens in Budapest, passt ein fertiges ERP, wenn sich die Abläufe dem Standard anpassen lassen; ein individuelles ERP, wenn die Arbeitsweise abweicht oder Anpassungen schon die Updates gefährden würden.

Das Wichtigste: Es gibt drei Wege: das fertige ERP, so wie es ist; das fertige ERP, konfiguriert und über die Erweiterungspunkte des Herstellers ergänzt; und das individuelle ERP. Je tiefer man in den Kern des fertigen Systems eingreifen müsste, desto eher lohnt es sich, den individuellen Teil in ein separates Modul zu legen oder ein eigenes System zu bauen. Der Umstieg ist auf jedem Weg in Etappen und mit vorheriger Datenbereinigung mit geringerem Risiko verbunden als ein einmaliger, großer Wechsel.

Was ist ein ERP?

Ein ERP (Enterprise Resource Planning, auf Deutsch Unternehmensressourcenplanung) fasst die Kernprozesse eines Unternehmens in einem System zusammen. Nach der Definition von Microsoft ist ERP eine Unternehmenssoftware, die Organisationen hilft, ihre Kernprozesse zu integrieren, zum Beispiel Finanzen, Lieferkette, Fertigung, Personalwesen, Beschaffung und Projektmanagement (Microsoft: What is ERP?).

In der Praxis liegt der Wert eines ERP darin, dass dieselben Daten nur einmal entstehen: Aus der eingehenden Bestellung wird der Warenausgang, daraus die Rechnung, aus der Rechnung die Buchung und die offene Forderung. Leben diese Schritte in getrennten Programmen und Tabellen, wandern die Daten von Hand, und mit ihnen wandern auch die Fehler. Die Verwaltung von Kunden und Vertrieb ist ein verwandtes Gebiet, aber eine eigene Entscheidung; darüber schreiben wir im Artikel Wann lohnt sich die Entwicklung eines individuellen CRM?.

Drei Wege zu einem ERP

Die Frage „individuell oder fertig“ ist in Wahrheit eine Wahl zwischen drei Möglichkeiten. Die Grenze ist nicht scharf, doch der Unterschied bei Kosten, Updates und Abhängigkeit ist erheblich.

Fertiges ERP, so wie es ist

Das Unternehmen führt ein fertiges Produkt ein und passt die eigenen Abläufe an die Standardarbeitsweise des Produkts an. Das funktioniert gut, wenn die Abläufe üblich sind und das Unternehmen bereit ist, gewohnte Arbeitsweisen zu ändern. Vorteile sind der schnellere Start und die vom Hersteller gelieferten Updates; der Nachteil: Was im Produkt fehlt, wird in Tabellen oder von Hand weitergeführt.

Fertiges ERP, konfiguriert und erweitert

Die meisten Einführungen landen irgendwo hier. Es lohnt sich, drei Dinge zu unterscheiden, denn für die Updatefähigkeit bedeuten sie sehr Unterschiedliches:

Konfiguration (Einstellung): Nutzung der vom Hersteller vorgesehenen Möglichkeiten ohne Programmierung, etwa für Arbeitsabläufe, Freigabestufen, Felder, Formulare und Berechtigungen.
Erweiterung (Extension): neue Funktionen über die vom Hersteller unterstützten, dokumentierten Erweiterungspunkte und Schnittstellen, ohne den eigenen Code des Produkts zu ändern.
Modifikation (Anpassung des Kerns): Umschreiben des eigenen Codes oder der Objekte des Herstellers bzw. deren Kopieren und Umschreiben. Das bietet die größte Freiheit, ist aber nach der eigenen Dokumentation der Hersteller bei Updates mit dem größten Risiko verbunden (siehe unten).

Individuelles ERP

Das System baut auf den eigenen Abläufen und dem Datenmodell des Unternehmens auf, und es entsteht nur, was wirklich gebraucht wird. Es gibt keinen Herstellerkern, der aktualisiert werden müsste, über die Weiterentwicklung entscheidet der Auftraggeber. Im Gegenzug müssen auch Entwicklung, Betrieb und Wartung organisiert werden, sei es mit einem eigenen Team oder einem beauftragten Entwickler. Die allgemeine Abwägung zwischen Individualsoftware und fertiger Software behandelt der Artikel Individualsoftware oder fertige Lösung (SaaS)?.

Warum erschweren viele Anpassungen das Update?

Der Hersteller eines fertigen ERP veröffentlicht regelmäßig Korrekturen und neue Versionen. Hat das Unternehmen den Herstellercode geändert, muss bei jedem Update geprüft werden, ob die Änderung noch funktioniert, und oft muss sie auch umgeschrieben werden. Die eigene Dokumentation der großen Hersteller kommt zum selben Schluss:

SAP: Nach dem Ansatz „Clean Core“ (sauberer Kern) sind Erweiterungen strikt getrennt von der SAP-Anwendung zu halten, über klar definierte, updatestabile Schnittstellen; die direkte Änderung oder das Kopieren von Standardobjekten hält der Hersteller für problematischer, weil sie nach jedem Korrekturpaket oder Update gründliche erneute Tests erfordern kann (SAP Learning: Introducing the Clean Core Approach).
Microsoft Dynamics 365: Für die Produkte Finance, Supply Chain und Commerce begründet der Hersteller das erweiterungsbasierte Modell damit, dass die Cloud und häufige Updates eine weniger eingreifende Anpassung erfordern, sodass Updates individuelle Lösungen mit geringerer Wahrscheinlichkeit beeinträchtigen; in diesen Produkten ist die Erweiterung die einzige Form der Anpassung, das Überschreiben des Anwendungscodes (Overlayering) wird nicht unterstützt (Microsoft Learn: Extensibility home page).
Odoo: Laut Dokumentation kann eine Datenbank mit individuellen Modulen erst dann aktualisiert werden, wenn die individuellen Module für die Zielversion fertig sind, und für die Kompatibilität ist der Betreuer des individuellen Moduls verantwortlich (Odoo: Upgrade).

Die Lehre ist bei SAP und Microsoft dieselbe: Der Kern bleibt unberührt, und was im Unternehmen individuell ist, lebt in einer abtrennbaren Erweiterung oder einem separaten Modul, das über eine dokumentierte Schnittstelle mit dem fertigen System kommuniziert; bei Odoo bestimmt die Wartung der individuellen Module, wann das System aktualisiert werden kann. Ist die nötige Individualität so groß, dass sich das nicht mehr sauber lösen lässt, ist das ein starkes Signal für ein individuelles ERP oder ein individuelles Modul.

Ungarische Besonderheiten: NAV Online Számla, Rechnungsstellung, Bank, Webshop

Das ERP eines ungarischen Unternehmens muss auch mit inländischen Systemen zusammenarbeiten. Am wichtigsten ist NAV Online Számla, das Online-Meldesystem der ungarischen Steuerbehörde (NAV) für Rechnungsdaten: Nach Angaben der NAV müssen seit dem 4. Januar 2021 Daten zu jeder Rechnung, Korrekturrechnung und Stornorechnung gemeldet werden, für die die Rechnungsvorschriften des ungarischen Umsatzsteuergesetzes gelten (NAV: Online Számla).

Die unterstützte Version der Maschinenschnittstelle zwischen den Systemen ist die Version 3.0 (geprüft am 17. Oktober 2026). Nach der Schnittstellenspezifikation muss das Rechnungsprogramm die Datenmeldung automatisch erfüllen, ohne gesonderten menschlichen Eingriff innerhalb des Prozesses; die NAV verarbeitet die übermittelten Daten asynchron, und die Meldung gilt erst dann als erfüllt, wenn sich das Programm vom Erfolg der Verarbeitung überzeugt und die zur Rechnung gehörende Quittungsnachricht erhalten hat (NAV Online Számla: Dokumentation). Die NAV ändert die Spezifikation von Zeit zu Zeit (auch im August 2026 hat sie eine geänderte Fassung veröffentlicht), deshalb muss die Anbindung gepflegt werden.

Was ein ERP in Ungarn typischerweise können muss und was wir anbinden:

NAV Online Számla: Übermittlung der Rechnungsdaten über die Maschinenschnittstelle, Abfrage des Verarbeitungsergebnisses und Behandlung von Fehlern.
Rechnungsdienste: Bleibt die Rechnungsstellung in einem externen Rechnungsprogramm, erfolgt die Anbindung über dessen Schnittstelle.
Banken: Einlesen von Kontoauszügen und Transaktionen, Abgleich der Zahlungseingänge mit den Rechnungen.
Webshop: Synchronisierung von Bestellungen, Lagerbestand und Preisen zwischen Webshop und ERP.
Kurierdienste und weitere Systeme: Paketversand, das bestehende CRM, E-Mail und Kalender.

Bei der Wahl eines fertigen ERP lohnt sich die Frage, ob es für das Produkt eine ungarische Lokalisierung gibt, wer die NAV-Anbindung pflegt, wenn sich die Spezifikation ändert, und wie die Verbindung zu ungarischen Banken und Rechnungsprogrammen aussieht. Bei einem individuellen ERP sind dieselben Anbindungen Teil der Entwicklung. Über das Verbinden von Systemen schreiben wir ausführlicher auf der Seite Prozessautomatisierung.

Entscheidungstabelle

Kriterium	Fertiges ERP, wie es ist	Erweitertes fertiges ERP	Individuelles ERP
Passung zu den Abläufen	das Unternehmen richtet sich nach den Standardabläufen	der Standard passt größtenteils, einige Punkte sind individuell	die Arbeitsweise weicht wesentlich vom Standard ab
Start	in der Regel schnell, wenn die Konfiguration genügt	länger durch die Entwicklung der Erweiterungen	erfordert die Zeit der Entwicklung, kann auch in Etappen starten
Updates	liefert der Hersteller, mit geringem Risiko	die Erweiterungen müssen bei jedem Update geprüft werden	plant der Auftraggeber, führt der Entwickler aus
Individuelle Abläufe	nur über Einstellungen	über Erweiterungspunkte oder in einem separaten Modul	beliebige Geschäftslogik
Integrationen	mit den Konnektoren des Herstellers und seiner Partner	Konnektoren und individuelle Integrationen	mit allem, dessen Schnittstelle oder Daten zugänglich sind
Kostenstruktur	Lizenz- oder Abonnementgebühr nach den Bedingungen des Herstellers	Lizenz plus Entwicklung und Wartung der Erweiterungen	Entwicklung, Betrieb und Weiterentwicklung
Abhängigkeit	vom Hersteller und von der Zukunft des Produkts	vom Hersteller und vom Partner, der die Erweiterungen entwickelt	mit dem Quellcode auch mit einem anderen Entwickler weiterführbar
Für wen geeignet?	für Unternehmen mit üblicher Arbeitsweise und schnellem Start	für Unternehmen, denen der Standard eine gute Basis bietet, die aber an einigen Punkten abweichen	für Unternehmen mit individueller Arbeitsweise oder individuellen Integrationen

Häufig ist auch eine gemischte Lösung: Das fertige ERP bleibt für Finanzen und Buchhaltung, die besonderen Abläufe des Unternehmens, zum Beispiel eine individuelle Produktionsplanung oder Preisgestaltung, laufen dagegen in einem separaten, individuellen Modul, das über eine Schnittstelle mit dem fertigen System kommuniziert.

Umstieg vom alten System

Ein ERP-Projekt beginnt selten bei null: Es gibt ein altes Programm, ein fertiges System oder ein Geflecht aus Tabellen, in dem die Daten vieler Jahre stecken. Die Schritte des Umstiegs:

Bestandsaufnahme: welche Daten, Abläufe und Verbindungen es gibt und was heute in Tabellen außerhalb des Systems läuft.
Dateninventur und Datenbereinigung: Doppelte Kunden, ein lückenhafter Artikelstamm und veraltete Posten werden noch vor der Migration bereinigt.
Datenzuordnung: welches alte Feld im neuen System wohin gehört und was mit alten, abgeschlossenen Posten geschieht.
Probemigration: Die alten Daten kommen in eine Testumgebung, wo die Key-User sie an echten Fällen prüfen.
Livegang in Etappen: modulweise oder standortweise, gegebenenfalls mit einem kurzen Parallelbetrieb von altem und neuem System, damit die tägliche Arbeit nicht stillsteht.
Nachbetreuung: Fehlerbehebung, ergänzende Schulung und Betrieb nach dem Livegang.

Nicht alles muss auf einmal ersetzt werden. Oft ist es der gangbare Weg, das neue Modul zunächst neben das alte System zu stellen und beide über eine Schnittstelle Daten austauschen zu lassen, bis der alte Teil abgelöst werden kann.

Risiken und wie man sie verringert

Zu große erste Etappe: Startet alles auf einmal, legt ein Fehler das ganze Unternehmen lahm. Es lohnt sich, mit einem klar abgegrenzten Modul zu beginnen.
Ungeordnete Daten: Fehlerhafte Daten bleiben auch im neuen System fehlerhaft. Die Datenbereinigung ist Teil des Projekts, keine nachträgliche Aufgabe.
Verborgene Abläufe: Viele wichtige Schritte leben in Tabellen oder im Kopf einzelner Mitarbeitender. Die Bestandsaufnahme muss auch diese aufdecken.
Fehlende Key-User: Wenn die Menschen, die die tägliche Arbeit erledigen, nicht an Planung und Tests beteiligt sind, lebt neben dem System die Tabelle weiter.
Integrationsfehler: Die Anbindungen an NAV, Bank und Webshop brauchen Protokollierung und Fehlermeldungen, damit eine hängengebliebene Synchronisierung nicht unbemerkt bleibt.
Einseitige Abhängigkeit: Die Übergabe des vollständigen Quellcodes und der Dokumentation stellt sicher, dass das System später auch mit einem anderen Entwickler weitergeführt werden kann.

Wo hilft künstliche Intelligenz im ERP?

Die großen Sprachmodelle, also ChatGPT von OpenAI, Claude von Anthropic und Gemini von Google, sind dort nützlich, wo bisher ein Mensch gelesen, kopiert oder formuliert hat:

Dokumente: Auslesen der Daten eingehender Rechnungen, Lieferscheine und Bestellungen, mit einer zur Prüfung vorbereiteten Erfassung.
E-Mail-Verkehr: Verarbeitung eingehender Bestell-E-Mails und Vorbereitung eines Antwortentwurfs.
Fragen an die Daten: Fragen an das System in Alltagssprache, zum Beispiel, welche Kunden überfällige Rechnungen haben.
Hinweis auf Abweichungen: Ungewöhnliche Posten werden zur Prüfung hervorgehoben, zum Beispiel eine Bestellung, die stark von den bisherigen Bestellungen des Kunden abweicht.

Wo ein Irrtum Geld kostet, macht die KI einen Vorschlag, und ein Mensch gibt ihn frei. Über die Anbindung der Modelle und den Datenschutz schreiben wir auf der Seite KI-Integration.

Unsere Erfahrung

Derzeit entwickeln wir ein großes ERP- und CRM-System; den Namen des Kunden und des Produkts nennen wir nicht. Bei einem ERP ist selten die Bildschirmoberfläche der schwierige Teil: Das Datenmodell, die Berechtigungen, die Integrationen und die Übernahme der Altdaten entscheiden darüber, ob die Mitarbeitenden das System nutzen oder daneben weiter ihre Tabelle führen.

Häufige Fragen

Wann lohnt es sich, ein individuelles ERP zu entwickeln?

Wenn die Arbeitsweise des Unternehmens wesentlich von dem abweicht, was fertige ERP-Systeme voraussetzen, und es diese Abweichung beibehalten will; wenn viele Systeme zu verbinden sind und es keine fertigen Konnektoren für sie gibt; oder wenn die nötige Anpassung bereits eine Änderung des Herstellerkerns erfordern würde. Deckt ein fertiges ERP den Großteil der Abläufe über Einstellungen ab, ist es in der Regel der schnellere Weg, und das sagen wir Ihnen auch im Erstgespräch.

Wie weit lässt sich ein fertiges ERP anpassen?

Auf viele Arten, aber es kommt darauf an, wie. Einstellungen (Konfiguration) und die vom Hersteller unterstützten Erweiterungspunkte berühren Updates kaum; eine Änderung des Herstellercodes kann dagegen bei jedem Update neue Arbeit verursachen. Die Dokumentation der großen Hersteller SAP und Microsoft empfiehlt, den Kern unberührt zu lassen und Erweiterungen getrennt zu halten; nach der Dokumentation von Odoo ist die Wartung der individuellen Module Voraussetzung für das Update.

Welches Risiko bergen viele Anpassungen?

Vor allem, dass Updates teuer und riskant werden: Bei jeder neuen Version müssen die Änderungen geprüft und oft umgeschrieben werden, und bei manchen Herstellern lässt sich das Update gar nicht erst durchführen, bevor die individuellen Teile für die neue Version fertig sind. Außerdem wird das Unternehmen auch von dem Partner abhängig, der die Erweiterungen entwickelt. Rechtfertigt der Umfang der Anpassung das, lohnt sich ein Vergleich mit den Kosten eines individuellen Moduls oder eines individuellen ERP.

Wie läuft der Umstieg vom alten System ab?

Er beginnt mit Bestandsaufnahme, Datenbereinigung und Datenzuordnung; darauf folgen eine Probemigration in einer Testumgebung und dann der Livegang in Etappen, modulweise oder mit einem kurzen Parallelbetrieb von altem und neuem System. Nach dem Livegang folgen Fehlerbehebung und Betrieb. Das alte System kann eine Zeit lang auch neben dem neuen laufen, über eine Schnittstelle verbunden.

Binden Sie NAV Online Számla an?

Ja. Die Rechnungsdaten übermitteln wir über die Maschinenschnittstelle der NAV, fragen das Verarbeitungsergebnis ab und behandeln Fehler, wie es die Schnittstellenspezifikation der NAV vorschreibt. Ebenso binden wir externe Rechnungsdienste, Banken und den Webshop an.

Wie können wir helfen?

Die Mesterséges Intelligencia Központ Kft. entwickelt individuelle ERP-, CRM- und Verwaltungssysteme, baut individuelle Module und Integrationen für fertige Systeme und verbindet sie mit künstlicher Intelligenz. Das Erstgespräch ist kostenlos, und wenn ein fertiges ERP genügt, sagen wir Ihnen auch das. Die funktionale Größe der Entwicklung messen wir in COSMIC-Funktionspunkten (ISO/IEC 19761) und leiten daraus das Angebot und den Zeitplan ab; die Methode beschreibt die Seite Preisgestaltung. Auf Wunsch schließen wir eine Geheimhaltungsvereinbarung (NDA), und nach der Übergabe übernehmen wir auch Betrieb und Wartung. Quellcode und Nutzungsrechte regelt der Vertrag.

Einzelheiten finden Sie auf der Seite Unternehmenssoftware. Wenn Sie mit uns über Ihr eigenes System sprechen möchten, schreiben Sie uns über die Kontaktdaten auf der Seite Kontakt.