Profil in 15 Minuten einordnen
Der ERP-Fit-Check übersetzt Ihre Angaben in eine Ersteinordnung mit Kriterien, Risiken und nächsten Schritten — ohne Kontaktzwang.
Zum Fit-Check →Ein ERP passt nicht deshalb, weil die Funktionsliste lang ist. Entscheidend ist, ob Prozesse, Unternehmensstruktur, Integrationen und Betriebsmodell zusammenpassen — und das entscheidet sich im Auswahlprozess, nicht in der Demo. Dieser Leitfaden beschreibt die sechs Phasen von der Zielbild-Arbeit bis zum Vertrag, mit Zeitrahmen, Bewertungslogik und den Fehlern, die Projekte regelmäßig Monate kosten.
Die teuersten Fehler in ERP-Projekten passieren nicht beim Customizing, sondern in den ersten Wochen der Auswahl: Anforderungen entstehen aus Meetings statt aus Prozessen, Anbieter werden nach Funktionslisten verglichen statt nach Passung zur eigenen Geschäftslogik, und am Ende entscheidet das Bauchgefühl — nicht reproduzierbar, nicht begründbar. Eine Entscheidung über eine sechs- bis siebenstellige Investition muss gegenüber Geschäftsführung, Beirat und Eigentümern begründbar sein.
Ein strukturierter Auswahlprozess löst dieses Problem nicht durch mehr Aufwand, sondern durch die richtige Reihenfolge: erst das Zielbild, dann die Anforderungen, dann der Markt. Wer die Reihenfolge umdreht und mit Anbieterterminen beginnt, übernimmt unbemerkt die Kriterien des überzeugendsten Vertriebs.
Für mittelständische Unternehmen hat sich ein Prozess in sechs Phasen bewährt. Die Zeitangaben sind Orientierungswerte für ein Unternehmen mit 50 bis 500 Mitarbeitenden; Mehrgesellschaftsstrukturen und internationale Rollouts verlängern vor allem die Phasen 1, 2 und 6.
| Phase | Ergebnis | Typische Dauer |
|---|---|---|
| 1 · Zielbild und Scope | Dokumentiertes Zielbild, Nicht-Ziele, Projektorganisation | 2–4 Wochen |
| 2 · Anforderungen und Prozesse | Muss-/Kann-Katalog mit prüfbaren Beispielen | 4–8 Wochen |
| 3 · Longlist | 8–12 Systeme, nach einheitlichem Raster vorgefiltert | 2–3 Wochen |
| 4 · Shortlist und Demos | 2–4 Anbieter, bewertete Demos mit eigenem Skript | 4–6 Wochen |
| 5 · Verproben | Referenzgespräche, Testszenarien, ggf. Proof of Concept | 2–6 Wochen |
| 6 · Vertrag und Partnerwahl | Verhandelter Vertrag, Implementierungspartner, Projektplan | 3–6 Wochen |
In Summe sind das vier bis neun Monate. Das wirkt lang — ist aber kurz gegen die zehn bis fünfzehn Jahre, die ein ERP-System im Unternehmen bleibt, und sehr kurz gegen die Kosten einer Fehlentscheidung.
Am Anfang steht nicht die Frage „welches System?", sondern „welcher Zustand?": Was soll in zwei Jahren anders sein als heute — messbar, nicht als Absichtserklärung? Typische Zielbilder sind ein konsolidierter Monatsabschluss in fünf statt fünfzehn Tagen, durchgängige Auftragsabwicklung ohne Schatten-Excel oder die Ablösung eines abgekündigten Altsystems mit klarem Enddatum.
Genauso wichtig sind die Nicht-Ziele: Was wird ausdrücklich nicht Teil des Projekts? Ohne dokumentierte Nicht-Ziele wächst der Scope in jedem Fachbereichsgespräch. Zum Zielbild gehört außerdem die Projektorganisation: eine verantwortliche Projektleitung mit ausreichender Kapazität, je Kernprozess ein Fachbereichs-Owner, ein Entscheidungsgremium mit Geschäftsführungsbeteiligung. Die ERP-Auswahl ist Chefsache — nicht, weil die Geschäftsführung jede Demo sehen muss, sondern weil Zielkonflikte zwischen Fachbereichen nur dort entschieden werden können.
Anforderungen werden belastbar, wenn sie aus realen Abläufen abgeleitet sind, nicht aus Wunschlisten. Der pragmatische Weg: die acht bis zwölf Kernprozesse des Unternehmens durchgehen und je Prozess festhalten, was heute funktioniert, was heute schmerzt und was das neue System nachweisbar können muss. Jede Muss-Anforderung braucht ein prüfbares Beispiel mit Mengengerüst — „Mehrwährungsfähigkeit" ist keine prüfbare Anforderung, „Eingangsrechnung in USD gegen Bestellung in EUR mit automatischer Kursdifferenzbuchung" ist eine.
Praktisch jedes ERP-System erfüllt 80 bis 90 Prozent einer Standardliste. Entscheidend sind die verbleibenden Punkte, in denen sich Anbieter tatsächlich unterscheiden — und genau diese stehen selten in generischen Vorlagen. Wie ein tragfähiger Anforderungskatalog entsteht, beschreibt unsere ERP-Auswahl-Checkliste; für die formale Struktur eines Lastenhefts gibt es den Lastenheft-Bereich. Wer zunächst eine schnelle Ersteinordnung des eigenen Profils möchte, kann den ERP-Fit-Check nutzen — das Ergebnis ist ohne Kontaktaufnahme einsehbar.
Die Longlist beantwortet eine einzige Frage: Welche Systeme kommen für dieses Profil grundsätzlich in Frage? Gefiltert wird nach harten Kriterien — Unternehmensgröße und Nutzerzahl, Branchen- bzw. Prozessabdeckung, Mehrgesellschafts- und Mehrwährungsfähigkeit, Betriebsmodell, Integrationsfähigkeit in die bestehende Landschaft und Partnerdichte im eigenen Markt. Acht bis zwölf Systeme sind ein gesunder Umfang.
Quellen für die Longlist sind neben Marktübersichten vor allem strukturierte Einordnungen einzelner Systeme. Unsere Übersicht der ERP-Lösungen beschreibt je System typische Stärken, Grenzen und Einsatzbilder — bewusst als Einordnung, nicht als Ranking, nach der dokumentierten Methodik.
Aus der Longlist werden zwei bis vier Anbieter, die zur Demo eingeladen werden. Der wichtigste Hebel dieser Phase: Die Demo folgt Ihrem Skript, nicht der Standardpräsentation des Anbieters. Drei bis fünf End-to-End-Prozesse, mit Ihren Daten, in Ihrer Komplexität, vor den Personen, die später damit arbeiten. Eine gute Demo zeigt sonst nur die fünf Prozent des Systems, die der Vertrieb zeigen möchte.
Bewertet wird mit einem einheitlichen Raster, das vor der ersten Demo feststeht: je Szenario eine Bewertung der Prozessabdeckung (Standard, Konfiguration, Anpassung, nicht abbildbar), dazu Nachvollziehbarkeit der Bedienung, Qualität der Antworten auf kritische Fragen und Belastbarkeit der Aussagen zu Migration und Integration. Jede Bewertung wird direkt nach dem Termin dokumentiert — nicht Tage später aus der Erinnerung.
Vor der Entscheidung werden die ein bis zwei Favoriten verprobt. Referenzgespräche wirken nur, wenn die Referenz vergleichbar ist — ähnliche Größe, ähnliche Prozesswelt, idealerweise dieselbe Branche und derselbe Implementierungspartner. Gefragt wird nach dem, was schiefging: Wo hat der Anbieter nachverhandelt? Welche Aufwände kamen ungeplant? Wie reagiert der Support unter Last?
Ein Proof of Concept — die eigenen Daten und ein bis zwei kritische Prozesse laufen für einen begrenzten Zeitraum real im System — lohnt sich, wenn Sonderprozesse über Erfolg und Misserfolg entscheiden oder die Integrationsdichte hoch ist. Für Standardprofile ist ein gut vorbereitetes Demo-Skript meist ausreichend; ein PoC kostet beide Seiten spürbaren Aufwand und gehört deshalb bewusst eingesetzt, nicht ritualisiert.
Im Mittelstand wird häufig nicht das System zum Problem, sondern der Implementierungspartner. System und Partner sind zwei getrennte Entscheidungen: Derselbe Softwarestand liefert mit einem erfahrenen Branchen-Team völlig andere Ergebnisse als mit einem überbuchten Generalisten. Zum Partner gehören Referenzen im eigenen Prozessumfeld, benannte Schlüsselpersonen im Angebot und eine ehrliche Aussage zur Teamauslastung.
Im Vertrag zählen die unspektakulären Klauseln: klar abgegrenzter Leistungsumfang mit Abnahmekriterien, geregelter Umgang mit Change Requests, Mitwirkungspflichten realistisch beschrieben, Preisgleitklauseln und Supportkonditionen über die ersten Jahre, Datenexport und Exit-Regelungen. Wer in Phase 2 prüfbare Anforderungen formuliert hat, kann sie hier als Vertragsbestandteil referenzieren — das ist der Moment, in dem sich die Vorarbeit auszahlt.
Drei Themen laufen durch alle Phasen. Erstens die Gesamtkostenbetrachtung: Lizenz- oder Subscriptionkosten sind häufig nur ein Fünftel der tatsächlichen Investition über fünf Jahre; wie sich Software-, Projekt-, interne und Folgekosten realistisch einordnen lassen, zeigt der Beitrag ERP-Kosten und Aufwand. Zweitens die internen Ressourcen: Auswahl und Einführung sind kein Nebenjob; ohne freigeräumte Kapazität der Schlüsselpersonen verzögert sich jedes Projekt. Drittens Change: Die Fachbereiche entscheiden über die spätere Nutzung. Wer sie erst in der Demo einbindet, bekommt Widerstand statt Mitwirkung.
Mit Anbietern starten statt mit Anforderungen. Wer zuerst Demos ansieht, übernimmt fremde Kriterien. Die Reihenfolge Zielbild → Anforderungen → Markt ist der halbe Prozess.
Funktionslisten abhaken. Lange Kriterienkataloge mit Ja/Nein-Spalten erzeugen Scheingenauigkeit. Wenige prüfbare End-to-End-Szenarien schlagen hundert Checkboxen.
Den „Heimspieler" ungeprüft setzen. Ein Anbieter mit persönlicher Verbindung ins Haus gehört in den Vergleich wie jeder andere — mit demselben Skript und demselben Raster.
Die Entscheidung delegieren. Fachbereiche bewerten mit, aber die Zielkonflikte entscheidet die Geschäftsführung. Delegierte Auswahl rächt sich in der Budget- und Change-Phase.
Den Partner nicht separat prüfen. Das beste System scheitert am falschen Einführungsteam. Partnerreferenzen und benannte Personen gehören in jede Endverhandlung.
Für mittelständische Unternehmen sind vier bis neun Monate vom Zielbild bis zur Vertragsunterschrift ein realistischer Rahmen. Kürzer wird es, wenn Anforderungen und interne Rollen bereits geklärt sind; länger, wenn mehrere Gesellschaften, Standorte oder Fachbereiche einzubinden sind.
Bewährt haben sich acht bis zwölf Systeme auf der Longlist und zwei bis vier Anbieter in der Shortlist. Mehr Demos erhöhen selten die Entscheidungsqualität, aber immer den Aufwand aller Beteiligten.
Nicht zwingend. Externe Begleitung lohnt sich vor allem, wenn intern keine Erfahrung mit ERP-Ausschreibungen vorhanden ist, mehrere Gesellschaften betroffen sind oder die Moderation zwischen Fachbereichen neutral bleiben soll. Die Methodik dieses Leitfadens funktioniert auch in Eigenregie.
Der größte Posten ist interne Zeit: je nach Projektgröße 20 bis 60 Personentage über alle Phasen. Hinzu kommen gegebenenfalls Kosten für externe Begleitung. Diese Investition ist klein im Verhältnis zu den Folgekosten einer Fehlentscheidung.
Die Demo zeigt Ihre Szenarien im System des Anbieters, vorbereitet durch dessen Team. Ein Proof of Concept lässt Ihre eigenen Daten und Prozesse über einen begrenzten Zeitraum real im System laufen. Ein PoC ist aufwendiger und lohnt sich vor allem bei kritischen Sonderprozessen oder hoher Integrationsdichte.
Autor: Joerg H. Paul Schaefer · Stand: September 2026 · erp-check.info ist eine herstellerunabhängige Informationsplattform.
Der ERP-Fit-Check übersetzt Ihre Angaben in eine Ersteinordnung mit Kriterien, Risiken und nächsten Schritten — ohne Kontaktzwang.
Zum Fit-Check →Vier Ebenen — Unternehmen, Prozesse, Technik, Projekt — als konkrete Prüffragen für Phase 1 und 2.
Zur Checkliste →Moderierte Auswahl mit Bewertungsmatrix, Demo-Skripten und dokumentierter Entscheidung — für Projekte, die Tempo und Struktur brauchen.
Zur Auswahlberatung →