ERP-Anforderungskatalog erstellen: Prozesse statt Funktionswünsche

Ein ERP-Anforderungskatalog soll Entscheidungen ermöglichen. Eine lange Liste mit Begriffen wie „Lager“, „Schnittstellen“ und „Reporting“ reicht dafür nicht: Zwei Anbieter können dieselben Punkte bestätigen und sehr unterschiedliche Abläufe meinen. Beschreibe deshalb, was dein Team heute tut und welches Ergebnis künftig verlässlich entstehen soll. Die folgende Struktur ist eine redaktionelle Planungsempfehlung für ein Einführungsprojekt.

Mit einem vollständigen Geschäftsvorgang beginnen

Nimm einen typischen Auftrag und verfolge ihn vom Verkauf bis zur Buchhaltungsübergabe. Notiere beteiligte Systeme, Personen und Daten. Ergänze anschließend einen relevanten Sonderfall, etwa einen teilweise lieferbaren Auftrag. So wird sichtbar, an welchen Übergängen Informationen verloren gehen oder manuelle Arbeit entsteht.

Ein sinnvoll formulierter Bedarf lautet beispielsweise: „Wenn nur ein Teil der bestellten Menge verfügbar ist, muss das Team die Restmenge eindeutig weiterbearbeiten können.“ Diese Aussage beschreibt ein gewünschtes Ergebnis. Wie es im ausgewählten System umgesetzt wird, bleibt eine gesonderte Lösungsentscheidung.

Nutze die Anforderungen anschließend, um eine ERP-Demo mit eigenen Abläufen vorzubereiten. Nach der Auswahl hilft die Vorbereitung des Xentral-Projekts, aus Anforderungen konkrete Zuständigkeiten und Abnahmeschritte zu machen.

Eine einheitliche Struktur pro Anforderung

Verwende für jeden Eintrag dieselben Felder. Das macht Rückfragen und spätere Änderungen leichter nachvollziehbar:

• Prozess und Verantwortlicher: Wer arbeitet mit dem Ergebnis?
• Auslöser und Eingangsdaten: Wann beginnt der Vorgang, welche Informationen liegen vor?
• Erwartetes Ergebnis: Was muss anschließend fachlich richtig sein?
• Sonderfälle: Welche Abweichungen treten tatsächlich auf?
• Priorität und Begründung: Warum ist der Punkt für den Start nötig?
• Nachweis: Wie wird die Erfüllung geprüft?

Trenne eine gewünschte Funktion von einer bereits festgelegten technischen Lösung. „Bestände korrekt an den Shop melden“ ist eine Anforderung. „Dafür eine eigene Middleware bauen“ ist zunächst ein Lösungsvorschlag, dessen Notwendigkeit erst geprüft werden muss.

Priorisieren, ohne wichtige Ausnahmen zu übersehen

Markiere Anforderungen, ohne die euer Betrieb nicht sinnvoll starten kann. Begründe diese Einstufung anhand eines konkreten Prozesses. Ein seltener Fall kann kritisch sein, wenn er sonst nicht kontrolliert bearbeitbar ist. Umgekehrt muss eine häufig gewünschte Komfortfunktion nicht zwingend zum ersten Start gehören.

Führe außerdem eine Liste späterer Verbesserungen. Sie verhindert, dass jeder neue Wunsch unbemerkt den vereinbarten Umfang erweitert. Änderungen sollten mit Auswirkung auf Aufwand, Termin und Abnahme bewertet werden. Ein kurzer, abgestimmter Startumfang ist hilfreicher als eine scheinbar vollständige Liste ohne Reihenfolge.

Daten und Schnittstellen ausdrücklich aufnehmen

Viele Anforderungen betreffen keine sichtbare Bildschirmfunktion. Prüfe Artikelkennungen, Varianten, Mengeneinheiten, Kunden- und Lieferantendaten sowie die Zuständigkeit für ihre Pflege. Für jede Schnittstelle gehören Übertragungsrichtung, Häufigkeit, Fehlerbearbeitung und notwendige Rückmeldungen in den Katalog.

Beschreibe auch, welche bestehenden Informationen migriert werden sollen. „Alle Daten übernehmen“ lässt offen, ob historische Belege, offene Vorgänge oder nur aktive Stammdaten gemeint sind. Ein klarer Umfang ermöglicht eine belastbare Aufwandsschätzung und einen gezielten Migrationstest.

Aus Anforderungen Abnahmetests machen

Formuliere vor der Umsetzung, wie ein Punkt nachgewiesen wird. Verwende einen repräsentativen Testdatensatz und ein erwartetes Ergebnis. Bei einer Shopanbindung kann der Test von der Bestellung über die ERP-Bearbeitung bis zur Rückmeldung reichen. Ein grüner Verbindungsstatus allein erfüllt diese Anforderung nicht.

Halte Ergebnis, offene Einschränkungen und verantwortliche Freigabe zusammen. Der Katalog bleibt so während Auswahl, Umsetzung und Go-live-Abnahme nutzbar. Für einen gemeinsamen Anforderungsworkshop helfen eine Systemübersicht, typische Vorgänge und die drei größten Probleme eures heutigen Ablaufs.

Passender Einblick aus einem Kundenprojekt

Bei Kloster Kitchen begann die Zusammenarbeit laut veröffentlichter Fallstudie mit einer bereichsweisen Prozessaufnahme. Dieser Projektansatz verdeutlicht, warum Anforderungen aus den Abläufen des Unternehmens entstehen sollten.

Ein vollständig ausgefüllter Mustereintrag

Anforderung: Ein Auftrag mit teilweise verfügbarer Ware soll kontrolliert in Lieferungen aufgeteilt werden können. Verantwortlich: Versandverantwortlicher und Kundenservice. Auslöser: Bestellte Gesamtmenge ist nicht vollständig lieferbar. Ergebnis: Gelieferte und offene Mengen bleiben je Artikel nachvollziehbar; Rückmeldungen passen zum Verkaufskanal.

Nachweis: Ein illustrativer Testauftrag mit zehn Einheiten wird in sechs sofortige und vier spätere Einheiten aufgeteilt. Beide Lieferungen und ihre Belege müssen zur ursprünglichen Bestellung zurückverfolgbar sein. Offene Bedingung: Die konkrete Kanalrückmeldung ist separat nachzuweisen. Das Muster ist eine Vorlage, keine pauschale Zusage für jeden Connector.

Auch Betriebsanforderungen aufnehmen

Ergänze Fragen, die erst nach dem ersten erfolgreichen Durchlauf sichtbar werden: Wer erkennt einen liegen gebliebenen Vorgang? Wie wird eine unterbrochene Verarbeitung fortgesetzt? Welche Person kann einen Fehler mit normalen Benutzerrechten korrigieren? Wie wird eine Änderung geprüft, bevor sie alle Aufträge betrifft?

Solche Anforderungen verhindern, dass eine technisch funktionierende Verbindung organisatorisch unbetreut bleibt. Der Middleware-Leitfaden zeigt dafür Wiederholungs- und Fehlerfälle.

Nachweis und Voraussetzung zusammen bewerten

• Standardfunktion: Für den vorgesehenen Prozess demonstriert und dokumentiert.
• Konfiguration nötig: Funktion vorhanden, konkrete Einstellung und Abnahme noch ausstehend.
• Erweiterung nötig: Lösung, Aufwand und Betrieb müssen gesondert geklärt werden.
• Offen: Es liegt noch kein belastbarer Nachweis vor.

Diese Zustände sind unsere Empfehlung für die Projektsteuerung. Verknüpfe jeden Nachweis mit seiner Version beziehungsweise dem geprüften Stand. Eine spätere Änderung des Ablaufs kann einen früheren Nachweis unzureichend machen.

Den Katalog während des Projekts weiterführen

Wenn eine neue Anforderung auftaucht, dokumentiere Anlass und Auswirkung auf bestehende Tests. Ein zusätzlicher Verkaufskanal kann beispielsweise neue Zahlungs-, Versand- und Rückmeldefälle erzeugen. Die Xentral-Ersteinrichtungscheckliste bietet eine ergänzende Liste technischer Einrichtungsbereiche. Sie ersetzt eure fachlichen Abnahmekriterien nicht.

Einordnung und Stand

Redaktioneller Praxisleitfaden von CommerceOS, Stand 17. September 2026. Die beschriebenen Prüfschritte sind Planungsempfehlungen und keine Zusage bestimmter Produktfunktionen oder Projektergebnisse.