Ein ERP-Projekt ist kein reines Softwareprojekt: Welche Entscheidungen vor der Auswahl fallen müssen

Drei ERP-Anbieter zeigen Einkauf, Vertrieb, Lager und Buchhaltung. Alle Demonstrationen wirken schlüssig. Jeder Anbieter kann die vorbereitete Funktionsliste weitgehend mit „vorhanden“ beantworten. Trotzdem ist noch nicht entschieden, welches System zum Unternehmen passt.

Das eigentliche Problem liegt häufig nicht in einer fehlenden Funktion. Vertrieb, Buchhaltung und Service verwenden unterschiedliche Definitionen eines aktiven Kunden. Artikelnummern werden in mehreren Systemen gepflegt. Für Sonderpreise existiert ein historischer Freigabeweg, dessen Entscheidungsgrund niemand mehr genau benennen kann. Gleichzeitig soll das neue ERP möglichst viel Standard verwenden.

Keine Produktdemo kann diese Widersprüche auflösen. Sie kann nur zeigen, wie ein Anbieter sie technisch abbilden würde.

Eine belastbare ERP-Auswahl beginnt deshalb vor der Bewertungsmatrix. Das Unternehmen muss nicht jeden späteren Prozessschritt fertig spezifizieren. Es muss jedoch die Grundentscheidungen treffen, aus denen sinnvolle Anforderungen, Demoszenarien und Ausschlusskriterien entstehen.

Ein ERP bildet ein Betriebsmodell ab

Ein ERP-System verbindet keine isolierten Funktionen. Es verbindet Geschäftsprozesse, Daten, Entscheidungen und Verantwortlichkeiten über Abteilungsgrenzen hinweg.

Ein Kundenauftrag betrifft beispielsweise:

• Kunden- und Artikeldaten,
• Preis- und Konditionsregeln,
• Verfügbarkeitsprüfung,
• Auftragsbestätigung,
• Beschaffung oder Produktion,
• Lieferung,
• Rechnung und Zahlung,
• Auswertung und Nachweis.

Wenn jeder Bereich nur seine eigene Maske bewertet, kann das ausgewählte Produkt lokal überzeugen und den End-to-End-Prozess trotzdem verschlechtern. Zusätzliche Übergaben, manuelle Exporte und widersprüchliche Daten werden dann erst während der Einführung sichtbar.

Eine Veröffentlichung von Mittelstand-Digital verbindet ERP-Einführung deshalb mit einer gemeinsamen Analyse von Geschäftsprozessen, Stammdaten und IT-Strukturen. Der entscheidende Punkt ist nicht ein bestimmtes Analyseverfahren. Es ist die Einsicht, dass Prozess, Daten und System nicht nacheinander unabhängig entschieden werden können.

Das ERP-Projekt gestaltet damit einen Teil des künftigen Betriebsmodells:

• Welche Abläufe werden vereinheitlicht?
• Welche Daten gelten unternehmensweit?
• Welche Rolle darf verbindlich entscheiden?
• Welche Systeme bleiben führend?
• Welche Abweichungen besitzen tatsächlichen Geschäftswert?
• Welche Fähigkeiten benötigt die Organisation nach dem Projekt?

Das Produkt soll diese Entscheidungen unterstützen. Es sollte sie nicht unbemerkt ersetzen.

Ein konstruiertes Beispiel: Drei Definitionen eines Kunden

Stellen Sie sich folgende Situation vor:

Vertrieb, Buchhaltung und Service verwenden drei unterschiedliche Definitionen eines aktiven Kunden. Für den Vertrieb genügt eine laufende Verkaufschance, die Buchhaltung erwartet eine geprüfte Rechnungsbeziehung und der Service benötigt einen gültigen Vertrag. Drei ERP-Produkte können Kundendaten verwalten. Keine Demo kann jedoch entscheiden, welche Status getrennt bleiben müssen, welche Information führend ist und wer ihre Qualität verantwortet.

Dieses Beispiel ist konstruiert. Es beschreibt keinen behaupteten Kundenfall und enthält keine erfundene Projektdauer oder Ergebniszahl.

Ein ungeklärtes Datenmodell würde in der Einführung meist auf eine von drei Arten sichtbar:

1. Ein Bereich setzt seine Definition als vermeintlichen Standard durch.
2. Alle Varianten werden als zusätzliche Felder und Sonderlogik abgebildet.
3. Die Entscheidung wird vertagt und durch manuelle Listen außerhalb des ERP kompensiert.

Alle drei Wege können technisch funktionieren. Keiner beantwortet automatisch, welches fachliche Modell das Unternehmen benötigt.

Acht Entscheidungen vor der Produktauswahl

1. Welche End-to-End-Prozesse gehören in den Auswahlumfang?

Beginnen Sie nicht mit Modulen, sondern mit den wichtigsten Ergebnissen, die das Unternehmen künftig durchgängig erzeugen muss. Beispiele sind:

• vom Angebot bis zum Zahlungseingang,
• vom Bedarf bis zur bezahlten Lieferantenrechnung,
• von der Produktidee bis zum gepflegten Artikel,
• vom Auftrag bis zur ausgelieferten und verbuchten Ware.

Für jeden priorisierten Prozess werden Start, Ergebnis, wesentliche Varianten und beteiligte Rollen benannt. Dadurch wird sichtbar, welche Funktionen wirklich zusammenarbeiten müssen.

Der Prozess-Reifecheck vor einer Digitalisierung liefert dafür sieben grundlegende Felder. Eine ERP-Auswahl benötigt zusätzlich die systemübergreifende Daten- und Integrationssicht.

Warnsignal: Die Auswahlliste ist nach Abteilungen oder Produktmodulen gegliedert, aber niemand prüft einen vollständigen Geschäftsvorgang.

2. Was soll Standard werden – und welche Abweichung schafft Wert?

„Wir wollen möglichst nah am Standard bleiben“ ist eine vernünftige Richtung, aber noch keine Entscheidung. Ein ERP-Standard kann Betrieb und Updates vereinfachen. Er kann zugleich einen Prozess erzwingen, der nicht zum Geschäftsmodell passt.

Für jede wesentliche Abweichung sind deshalb zwei Fragen zu beantworten:

1. Welchen nachweisbaren geschäftlichen Nutzen erzeugt sie?
2. Welche Einführungs-, Test-, Betriebs- und Upgradefolgen sind dafür vertretbar?

Eine Besonderheit ist eher zu erhalten, wenn sie Kundenwert, regulatorische Sicherheit oder einen echten Wettbewerbsvorteil erzeugt. Eine historische Gewohnheit ohne erkennbaren Zweck sollte nicht durch teures Customizing konserviert werden.

Die offizielle britische Beschaffungsleitlinie für Technologie warnt davor, dass selbst kleine Anpassungen von Standardsoftware Wartung, Skalierung und spätere Upgrades erschweren können. Daraus folgt kein allgemeines Customizing-Verbot. Es folgt eine Begründungspflicht.

Warnsignal: Jede heutige Arbeitsweise wird als Muss-Anforderung behandelt oder jede Produktabweichung vorschnell als notwendige Anpassung eingeplant.

3. Welche Stammdaten gelten – und wer verantwortet sie?

ERP-Projekte scheitern nicht daran, dass Daten technisch nicht importiert werden können. Schwieriger ist die Frage, welche Daten fachlich richtig, vollständig und künftig führend sein sollen.

Für zentrale Objekte wie Kunde, Lieferant, Artikel, Stückliste, Preis, Kostenstelle oder Standort werden mindestens geklärt:

• fachliche Definition,
• erforderliche Attribute,
• führende Quelle,
• Erstellungs- und Änderungsrecht,
• Qualitätsregel,
• Behandlung von Dubletten und Konflikten,
• verantwortlicher Data Owner.

ISO 8000-8 ordnet Datenqualität als messbare Managementaufgabe ein. Für die ERP-Auswahl bedeutet das: „Datenmigration enthalten“ ist keine ausreichende Anforderung. Das Unternehmen muss vorher entscheiden, woran geeignete Daten erkannt werden und wer Abweichungen verbindlich klärt.

Eine Bereinigung vor der Migration allein genügt ebenfalls nicht. Wenn Anlage- und Pflegeprozesse unverändert bleiben, entstehen dieselben Qualitätsprobleme im neuen System erneut.

Warnsignal: Das Projekt spricht über Feldzuordnung und Importwerkzeuge, aber nicht über Definition, Quelle und dauerhafte Verantwortung der Daten.

4. Welche Systeme bleiben führend und welche Integrationen sind kritisch?

Ein neues ERP ersetzt selten die gesamte Anwendungslandschaft. Lohnabrechnung, CRM, E-Commerce, Produktionssysteme, Dokumentenmanagement, Banken, Logistikdienste oder branchenspezifische Anwendungen bleiben angebunden.

Für jede kritische Integration sind vor der Auswahl mindestens zu beschreiben:

• benötigte Information oder Transaktion,
• Richtung und Zeitpunkt des Austauschs,
• führendes System,
• Qualitäts- und Fehlerbehandlung,
• Sicherheits- und Berechtigungsgrenze,
• erwartetes Volumen und zeitliche Anforderung,
• Verhalten bei Ausfall,
• verantwortliche Rollen auf beiden Seiten.

Eine vorhandene Schnittstelle auf einer Produktfolie ist noch kein Integrationsnachweis. Der Anbieter muss zeigen, ob genau die benötigten Daten, Operationen und Fehlerwege unterstützt werden.

Eine CMDB oder schlanke Abhängigkeitsübersicht kann helfen, bestehende Systeme und Services einzuordnen. Für die ERP-Auswahl muss diese technische Sicht um fachliche Datenflüsse ergänzt werden.

Warnsignal: Die Bewertung vergibt Punkte für „API vorhanden“, ohne die benötigten Geschäftsvorgänge gegen die Schnittstelle zu prüfen.

5. Welche Anforderungen sind wirklich entscheidend?

Eine vollständige Wunschliste behandelt häufig seltene Komfortfunktion, gesetzlichen Zwang und geschäftskritischen Prozess gleich. Das macht Bewertungen mathematisch umfangreich, aber fachlich beliebig.

Ordnen Sie Anforderungen stattdessen nach:

• Geschäftswirkung,
• Häufigkeit,
• Risiko bei Nichterfüllung,
• Zahl betroffener Rollen,
• Veränderbarkeit des eigenen Prozesses,
• Aufwand und Folgekosten einer Anpassung.

Daraus entstehen drei unterschiedliche Kategorien:

Kategorie	Bedeutung	Beispiel
Ausschlusskriterium	Ohne diese Fähigkeit ist ein verantwortbarer Betrieb nicht möglich	erforderliche gesetzliche Buchungs- oder Nachweislogik fehlt
bewertetes Kriterium	Unterschiede beeinflussen Nutzen, Aufwand oder Risiko	Planung kann einen relevanten Prozess mit weniger manuellen Übergaben abbilden
Lernfrage	Die Organisation kennt den Bedarf noch nicht ausreichend	welche Variante eines seltenen Sonderprozesses künftig bestehen bleibt

Eine Lernfrage wird nicht künstlich zum Muss-Kriterium. Sie wird durch Workshop, Prototyp oder zeitlich begrenzte Erprobung geklärt.

Warnsignal: Die Zahl erfüllter Funktionen bestimmt das Ergebnis, obwohl einzelne Ausschlusskriterien oder Integrationsrisiken wesentlich schwerer wiegen.

6. Wie werden Migration, Umstieg und Rückfall geplant?

Migration ist kein Arbeitspaket, das erst nach der Produktauswahl mit „Daten übernehmen“ beschrieben werden sollte. Umfang und Qualität der Bestandsdaten, notwendige Transformationen, Parallelbetrieb und Abschaltung beeinflussen Aufwand und Produkttauglichkeit.

Das V-Modell XT Bund fordert für ein Migrationskonzept eine inhaltliche, zeitliche und organisatorische Planung. Dazu gehören Daten und Schnittstellen, Migrationsstufen, Datenzustand, Transformation und eine Rollbackstrategie.

Vor der ERP-Auswahl muss noch kein vollständiges Migrationsdrehbuch vorliegen. Benötigt werden jedoch belastbare Annahmen:

• Welche Daten müssen vollständig, teilweise oder gar nicht übernommen werden?
• Welche Historie bleibt im Altsystem oder Archiv?
• Welche Daten werden vor oder während der Migration bereinigt?
• Wie werden Mengen, Salden und fachliche Zusammenhänge geprüft?
• Ist Parallelbetrieb notwendig und welche Doppelpflege entsteht?
• Wer nimmt Daten und Prozesse ab?
• Wann kann das Altsystem abgeschaltet werden?
• Was geschieht, wenn ein Umstieg abgebrochen werden muss?

Warnsignal: Der Anbieter nennt eine Migrationspauschale, obwohl Datenumfang, Qualitätsprobleme und fachliche Abnahme noch unbekannt sind.

7. Wer kann das ERP nach der Einführung betreiben und weiterentwickeln?

Ein ERP benötigt dauerhaft Entscheidungen über Rollen, Konfiguration, Daten, Schnittstellen, Releases und Verbesserungen. Das Einführungsprojekt endet; die Abhängigkeit vom System bleibt.

Das künftige Betriebsmodell klärt:

• fachliche Process Owner,
• Data Owner für zentrale Objekte,
• interne Anwendungsbetreuung,
• technische Verantwortung für Plattform und Integrationen,
• Berechtigungs- und Sicherheitsverantwortung,
• Release-, Test- und Change-Prozess,
• Supportaufteilung zwischen internem Team und Dienstleister,
• Vertretung und Wissenssicherung.

Die Unterscheidung von Verantwortung und technischer Berechtigung ist dabei entscheidend. Ein Implementierungspartner kann konfigurieren. Er sollte nicht dauerhaft ungeklärte fachliche Entscheidungen für das Unternehmen treffen.

Warnsignal: Der Projektplan beschreibt Key User für die Einführung, aber keine Rollen, Kapazitäten und Entscheidungswege für den späteren Betrieb.

8. Welche Gesamt- und Wechselkosten sind vertretbar?

Der Lizenzpreis ist nur ein Teil der ERP-Entscheidung. Eine belastbare wirtschaftliche Betrachtung umfasst abhängig vom Modell:

• Einführung und Konfiguration,
• Datenbereinigung und Migration,
• Schnittstellen und Infrastruktur,
• interne Projekt- und Schulungszeit,
• Test und Betriebsübergabe,
• Lizenzen oder Abonnements,
• Support und Weiterentwicklung,
• Customizing und Upgradefolgen,
• Parallelbetrieb und Abschaltung alter Systeme,
• Export, Wechsel und Vertragsbeendigung.

Der aktuelle GOV.UK Service Standard für Technologieentscheidungen verbindet Total Cost of Ownership mit nachhaltigem Betrieb, Umgang mit Altsystemen und der Möglichkeit, spätere Entscheidungen zu ändern. Dieser Grundsatz ist für ERP besonders relevant, weil Daten, Prozesse und Integrationen langfristige Wechselkosten erzeugen.

Der Beitrag IT-Kosten im Mittelstand zeigt, warum Kosten mit Zweck, Leistung und Verantwortung verbunden werden müssen. Ein günstigeres ERP ist nicht wirtschaftlicher, wenn manuelle Umgehungsprozesse oder schwer wartbare Anpassungen den Unterschied später überkompensieren.

Warnsignal: Die Wirtschaftlichkeitsrechnung endet beim Go-live oder bewertet den späteren Datenexport als technisches Detail.

Anbieter sollten reale Geschäftsszenarien zeigen

Eine Standarddemo zeigt die Stärken des Produkts unter vorbereiteten Bedingungen. Für die Auswahl ist sie ein Einstieg, kein Nachweis.

Das Unternehmen sollte den Anbietern wenige, aber relevante End-to-End-Szenarien vorgeben. Ein Szenario enthält:

• Ausgangslage und gewünschtes Ergebnis,
• beteiligte Rollen,
• notwendige Daten,
• relevante Entscheidung,
• bekannte Ausnahme,
• benötigte Integration,
• erwarteten Nachweis.

Beispiel:

Ein Bestandskunde bestellt einen konfigurierten Artikel, dessen Liefertermin von einer externen Komponente abhängt. Während der Bearbeitung ändert sich die Menge. Zeigen Sie, wie Preis, Verfügbarkeit, Freigabe, Bestellung, Kundeninformation und Nachvollziehbarkeit zusammenwirken.

Die Anbieter müssen nicht jeden Sonderfall live konfigurieren. Sie sollen aber erklären, was Standard, Konfiguration, Erweiterung, Fremdprodukt oder manuelle Tätigkeit wäre. Dadurch werden Unterschiede sichtbar, die eine Checkbox „Auftragsbearbeitung vorhanden“ verdeckt.

Für besonders riskante Annahmen eignet sich ein begrenzter Prototyp oder Produkttest. Die Beschaffungsleitlinie des UK Government empfiehlt, bei einer Erprobung ein kleines, schwieriges Problem sowie Integration und realistische Betriebsbedingungen zu prüfen. Ein einfacher Happy Path bestätigt vor allem, dass die Demo funktioniert.

Das Auswahlbriefing auf einer Seite

Vor Marktabfrage oder Ausschreibung sollte die Leitung folgende Entscheidungen zusammenfassen können:

Feld	Festzuhaltende Aussage
Geschäftsziel	Welche Ergebnisse soll das ERP messbar verbessern?
priorisierte Prozesse	Welche End-to-End-Abläufe entscheiden über die Auswahl?
Standardisierung	Was soll vereinheitlicht werden, welche Abweichungen bleiben begründet?
Daten	Welche Objekte sind zentral, welches System und welcher Owner führen sie?
Integrationen	Welche Datenflüsse und Transaktionen sind kritisch?
Ausschlusskriterien	Welche Fähigkeiten und Rahmenbedingungen sind unverzichtbar?
Migration	Welche Daten, Historien, Stufen und Abnahmen werden erwartet?
Betriebsmodell	Welche internen und externen Rollen tragen den späteren Betrieb?
Wirtschaftlichkeit	Welche Lebenszyklus-, Anpassungs- und Wechselkosten werden verglichen?
Lernfragen	Welche Unsicherheiten müssen Demo oder Prototyp gezielt prüfen?

Dieses Briefing ist kein vollständiges Lastenheft. Es verhindert aber, dass ein Lastenheft aus ungewichteten Einzelwünschen entsteht.

Was vor der Auswahl noch nicht fertig sein muss

Eine ERP-Auswahl darf nicht in einer endlosen Voranalyse stecken bleiben. Vor der ersten Markterkundung müssen deshalb nicht feststehen:

• jede spätere Maske und Feldbezeichnung,
• jeder seltene Ausnahmefall,
• das vollständige Soll-Prozessmodell,
• alle Details der technischen Architektur,
• die endgültige Einführungsmethode,
• jede spätere Berichtsanforderung.

Produkte und Prototypen können helfen, Möglichkeiten zu verstehen und Anforderungen zu schärfen. Die Grenze verläuft dort, wo eine Produktentscheidung organisatorische Unklarheit dauerhaft festschreibt.

Prozessverantwortung, führende Daten, zentrale Integrationen und Ausschlusskriterien dürfen nicht an die Demo delegiert werden. Detailkonfiguration und geeignete Standardabläufe dürfen dagegen bewusst mit dem ausgewählten System weiterentwickelt werden.

Der erste sinnvolle Schritt

Wählen Sie einen End-to-End-Prozess, der für die ERP-Entscheidung wesentlich ist. Lassen Sie die beteiligten Bereiche drei Aussagen gemeinsam vervollständigen:

1. Der Prozess ist erfolgreich, wenn …
2. Für die zentrale Information … ist künftig … führend und verantwortlich.
3. Vom Standard weichen wir nur ab, wenn …

Wenn diese Sätze widersprüchlich bleiben, ist die nächste Produktdemo noch keine Entscheidungshilfe. Wenn sie geklärt sind, kann der Anbieter zeigen, wie sein System das gewünschte Betriebsmodell unterstützt – und welche Kosten, Abhängigkeiten oder Veränderungen damit tatsächlich verbunden sind.

Ein ERP-Projekt ist damit selbstverständlich auch ein Softwareprojekt. Belastbar wird es erst, wenn die Software nicht zum Ersatz für fehlende Prozess-, Daten- und Verantwortungsentscheidungen wird.