ERP-Auswahl im Mittelstand: ein vollständiges Beispiel nach Standard First
Ein ERP betrifft fast jede Abteilung, und genau das macht die Auswahl schwer. Dieses Beispiel begleitet ein mittelständisches Unternehmen durch den gesamten Prozess: von der Prozessanalyse über den Anforderungskatalog und die Standard-First-Prüfung bis zur Nutzwertanalyse, den Kostenfallen und der dokumentierten Entscheidung.
Inhalt dieses Beispiels
- Die Ausgangslage: ein Altsystem voller Sonderlösungen
- Das Prinzip Standard First und die Prüf-Checkliste
- Wer im Projekt mitarbeitet
- Der Zeitplan: von der Prozessanalyse bis zur Entscheidung
- Ein Auszug aus dem Anforderungskatalog
- Standard First in der Praxis: fünf Anforderungen im Test
- Das Demo-Playbook für die Anbieterpräsentationen
- Die Nutzwertanalyse mit Beispielrechnung
- Die Kostenfallen hinter dem Lizenzpreis
- Sechs Fallstricke und wie das Beispiel sie umgeht
- Das Ergebnis und die Lessons Learned
- Häufige Fragen
Ein Altsystem voller Sonderlösungen
Ein mittelständischer Fertiger mit rund 300 Mitarbeitenden will sein altes ERP ablösen. Über zehn Jahre wurde es immer weiter angepasst, jede Abteilung hatte irgendwann ihre eigene Sonderlösung erhalten.
Das Ergebnis ist ein System, das niemand mehr vollständig versteht. Jedes Update wurde aufwendiger, weil die Anpassungen einzeln geprüft und oft neu gebaut werden mussten. Der Entwickler, der die Chargenverwaltung damals gebaut hat, ist längst nicht mehr im Haus. Und niemand kann mehr genau sagen, warum bestimmte Prozesse so und nicht anders laufen.
Die Wünsche für das neue System liegen entsprechend weit auseinander. Die Finanzabteilung will sauberere Auswertungen, der Einkauf eine bessere Lieferantenverwaltung, die Produktion eine engere Anbindung an die Fertigung, der Vertrieb mobile Zugriffe, die Geschäftsführung vor allem Planungssicherheit beim Budget. Jede Anforderung ist für sich berechtigt.
Genau hier liegt die eigentliche Gefahr eines neuen Systems: wenn jede Abteilung ihre alten Sonderwünsche unverändert in die neue Software überträgt, entsteht in wenigen Jahren dasselbe Problem noch einmal. Das neue ERP wäre dann nur eine teure Kopie des alten, mit denselben Schwächen. Deshalb wird in diesem Beispiel jede Anforderung zuerst durch einen Standard-First-Filter geführt.
Dieses Beispiel bildet einen typischen Verlauf ab. Es nennt bewusst keine realen Firmennamen, keine echten Zitate und keine konkreten Produktnamen. Alle Größen, Zeiträume, Punktwerte und Anpassungsfälle sind realistische Näherungen, keine Zusagen für einen konkreten Fall.
Standard First: der Standard zuerst
In der ERP-Beratung hat sich ein einfacher Grundsatz bewährt. Bevor eine Anforderung zu einer Anpassung der Software führt, wird zuerst geprüft, ob der Standard das Bedürfnis nicht ohnehin abdeckt, oft mit einem leicht veränderten Prozess statt mit einer Änderung an der Software.
Individualisierung bleibt dabei die begründete Ausnahme, nicht der erste Reflex. Der Grund ist einfach: jede Anpassung, die heute Zeit spart, kostet später bei jedem Update erneut Zeit und Geld. Standardfunktionen werden vom Hersteller gepflegt und weiterentwickelt. Individuallösungen dagegen müssen bei jeder neuen Version einzeln geprüft, getestet und oft neu gebaut werden.
Ein häufiges Missverständnis: Standard First bedeutet nicht, niemals anzupassen. Es bedeutet, jede Anpassung zu begründen. Wo eine echte fachliche oder gesetzliche Notwendigkeit besteht, ist die Erweiterung richtig. Wo nur eine Gewohnheit fortgeschrieben wird, ist sie teuer und überflüssig.
Die folgenden vier Fragen haben sich als Filter bewährt. Sie lassen sich in jedem Auswahlprojekt anwenden, unabhängig vom Anbieter und vom eingesetzten Werkzeug.
Notwendigkeit: Ist das wirklich eine fachliche oder gesetzliche Notwendigkeit, oder nur eine liebgewonnene Gewohnheit aus dem alten System?
Alternative im Standard: Deckt eine andere Standardfunktion das Bedürfnis auf einem anderen Weg ab, auch wenn der Prozess dafür leicht angepasst werden muss?
Lebenszykluskosten: Was kostet die Anpassung nicht nur bei der Einführung, sondern bei jedem künftigen Update der Software?
Verantwortung: Wer trägt und pflegt die Anpassung langfristig, wenn die Person, die sie beauftragt hat, das Unternehmen verlassen hat?
Wer im Projekt mitarbeitet
Ein Auswahlprojekt scheitert selten an der Technik und häufig an unklaren Zuständigkeiten. In diesem Beispiel arbeitet ein kleines Kernteam mit klar verteilten Rollen.
Projektleitung
Steuert den gesamten Prozess, hält den Zeitplan, moderiert Konflikte zwischen Abteilungen und verantwortet den Standard-First-Filter. Sie entscheidet nicht fachlich, sondern sorgt für Struktur.
Key User
Kennen den Alltag ihres Bereichs im Detail. Sie bringen die Anforderungen ein, prüfen sie gegen den Standard, testen in den Demos und bewerten. Sie sind später auch Multiplikator bei der Einführung.
IT und Systembetrieb
Prüfen Schnittstellen zur bestehenden Landschaft, Betriebsmodell, Datenschutz und Migrationsaufwand. Sie bewerten technisch, nicht fachlich, und sind bewusst nicht federführend.
Entscheidungsgremium
Geschäftsführung und kaufmännische Leitung. Sie legen das Budget fest, geben die gewichteten Kriterien frei und treffen am Ende die Entscheidung auf Basis der dokumentierten Bewertung.
Externe Begleitung
Eine anbieterneutrale Beratung kann den Prozess moderieren und Erfahrung aus vergleichbaren Projekten einbringen. Wichtig ist, dass sie keine Provisionen von Anbietern erhält.
Betroffene Anwender
Die Menschen, die später täglich mit dem System arbeiten, werden früh eingebunden, nicht erst bei der Einführung. Das senkt Widerstand und deckt praktische Probleme rechtzeitig auf.
Von der Prozessanalyse bis zur Entscheidung
Der zeitliche Verlauf dieses Beispiels. Die Wochenangaben sind Näherungen und verschieben sich je nach Verfügbarkeit der Beteiligten.
Prozesse verstehen, bevor Anbieter angeschaut werden
Das Kernteam nimmt die wichtigsten Kernprozesse auf, vom Auftragseingang bis zur Rechnung. Ohne dieses Bild lässt sich später nicht beurteilen, ob ein Standardprozess passt oder eine Anpassung nötig ist. Parallel legt das Entscheidungsgremium den Budgetrahmen fest.
Aus dem breiten Markt wird eine Shortlist
Anhand von Branche, Größe, Betriebsmodell, wichtigen Schnittstellen und Budget entsteht eine anbieterneutrale Vorauswahl. Statt wochenlanger eigener Recherche bleiben wenige Systeme übrig, die zum Profil des Fertigers passen.
Wünsche sammeln und durch den Standard-First-Filter führen
Alle fünf Abteilungen tragen ihre Anforderungen zusammen, geordnet nach Muss, Soll und Kür. Jeder Anpassungswunsch durchläuft die vier Prüffragen. Aus rund zwanzig Anpassungswünschen bleiben am Ende drei begründete Individualisierungen übrig. Diese Phase ist die arbeitsintensivste und zugleich die wertvollste.
Alle Anbieter zeigen dieselben Szenarien
Jeder Anbieter der Shortlist erhält vorab dasselbe Demo-Playbook mit denselben Aufgaben und denselben Testdaten. So werden die Termine direkt vergleichbar, statt dass jeder Anbieter seine Schokoladenseite zeigt. Bewertet wird direkt nach jedem Szenario, solange der Eindruck frisch ist.
Nutzwertanalyse und Gesamtkostenbetrachtung
Die Punkte aus den Demos fließen in die gewichtete Nutzwertanalyse. Parallel werden die Gesamtkosten über die geplante Nutzungsdauer verglichen, nicht nur die Lizenzpreise. Bei knappem Ergebnis entscheidet der verbleibende Anpassungsaufwand.
Entscheiden, begründen, dokumentieren
Das Entscheidungsgremium wählt auf Basis der dokumentierten Bewertung. Jede Anforderung, jede Standard-First-Entscheidung und jede Bewertung bleibt nachvollziehbar festgehalten, als Grundlage für die Freigabe und für spätere Rückfragen.
Ein Auszug aus dem Lastenheft
So sehen gute Anforderungen aus: konkret, prüfbar und einer Quelle zugeordnet. Jede Zeile trägt eine Priorität und ein Kriterium, an dem sich in der Demo eindeutig zeigen lässt, ob sie erfüllt ist.
| Bereich | Anforderung | Prüfkriterium in der Demo | Priorität |
|---|---|---|---|
| Finanzen | Standardberichte ohne IT erstellen | Ein Sachbearbeiter erstellt den Bericht offene Rechnungen nach Kunde in unter drei Minuten und exportiert ihn als PDF. | Muss |
| Finanzen | Anbindung an die Buchhaltung | Buchungssätze werden ohne manuelle Nacharbeit in das bestehende Buchhaltungssystem übergeben. | Muss |
| Produktion | Chargenrückverfolgung bis zum Rohstoff | Zu einer gelieferten Charge lässt sich in unter fünf Minuten jeder verwendete Rohstoff mit Lieferant und Datum belegen. | Muss |
| Produktion | Rückmeldung aus der Fertigung | Ein Werker meldet einen abgeschlossenen Arbeitsgang an einem Terminal in unter dreißig Sekunden zurück. | Soll |
| Einkauf | Lieferanten nach eigenen Kriterien bewerten | Die Gewichtung der Bewertungskriterien lässt sich ohne Programmierung durch den Fachbereich anpassen. | Soll |
| Vertrieb | Mobiler Zugriff auf Kundendaten | Ein Außendienstmitarbeiter ruft auf dem Smartphone Kundenhistorie und offene Angebote ab, ohne Zusatzsoftware. | Soll |
| Vertrieb | Angebote aus Vorlagen erzeugen | Ein Angebot entsteht aus einer Vorlage in unter zwei Minuten, inklusive aktueller Preise. | Kür |
| Geschäftsführung | Kennzahlen auf einen Blick | Umsatz, Auftragsbestand und Deckungsbeitrag sind ohne Zutun der IT in einer Übersicht sichtbar. | Soll |
| IT | Betrieb wahlweise in der Cloud | Der Anbieter belegt ein Betriebsmodell mit Rechenzentrum im europäischen Rechtsraum. | Muss |
| IT | Offene Schnittstelle zum Versanddienstleister | Eine dokumentierte Schnittstelle existiert und wird in der Demo an einem echten Beispiel gezeigt. | Kür |
Beispielhafter Auszug. Ein vollständiger Katalog dieses Beispiels umfasst rund 120 Anforderungen, davon etwa 30 als Muss eingestuft.
Fünf Anforderungen im Test
So sieht die Prüfung im Projektalltag aus. Vier der fünf Wünsche ließen sich mit dem Standard lösen, einer war eine begründete Ausnahme.
Sechsstufige Rechnungsfreigabe wie im Altsystem
Die Finanzabteilung wollte den alten, sehr feingliedrigen Freigabeprozess mit sechs Stufen eins zu eins übernehmen. Die Prüfung zeigte, dass die Standardfreigabe des neuen Systems vier flexible Stufen bietet, die dieselbe Kontrolle mit weniger Verwaltungsaufwand erreichen. Der Prozess wurde auf den Standard verschlankt, keine Anpassung nötig. Nebeneffekt: die Durchlaufzeit einer Freigabe sank spürbar.
Eigene Punkte-Matrix zur Lieferantenbewertung
Der Einkauf nutzte seit Jahren eine selbst gebaute Excel-Tabelle mit einer sehr spezifischen Gewichtung. Die im System bereits vorhandene Standardbewertung deckte dieselben Kernkriterien ab, es musste lediglich die Gewichtung konfiguriert werden. Keine Programmierung, nur Einstellung. Der Unterschied ist entscheidend: Konfiguration überlebt jedes Update, Programmierung nicht.
Eigene Angebotsvorlage mit besonderem Layout
Der Vertrieb bestand auf einem exakt nachgebauten Angebotslayout, weil Kunden es so gewohnt seien. Die Prüffrage nach der Notwendigkeit ergab, dass kein Kunde je Rückmeldung zum Layout gegeben hatte. Die Standardvorlage wurde mit dem Firmenlogo und wenigen Feldern angepasst, was im Standardumfang vorgesehen ist.
Ein individuelles Kennzahlen-Dashboard
Gewünscht war ein maßgeschneidertes Dashboard mit einer sehr eigenen Kennzahlenlogik. Im Gespräch zeigte sich, dass die eigentliche Anforderung schlicht Aktualität war, nicht die spezielle Darstellung. Die Standardauswertungen erfüllten das, sobald die Datenpflege sauber lief. Die Anforderung wanderte von Muss auf Soll.
Branchenspezifische Chargenrückverfolgung
Die Produktion brauchte eine lückenlose Rückverfolgbarkeit einzelner Chargen bis zum Rohstoff, gesetzlich vorgeschrieben für die Branche. Kein Standardmodul deckte diese Tiefe vollständig ab. Hier war die Erweiterung berechtigt, weil eine regulatorische Pflicht dahinterstand, keine bloße Gewohnheit. Wichtig war, die Anpassung sauber zu dokumentieren und ihre Update-Fähigkeit vertraglich abzusichern.
Ein Playbook, das jeder Anbieter durchspielt
Ohne Vorgaben zeigt jeder Anbieter seine Schokoladenseite und umgeht seine Schwächen. Deshalb erhalten alle vorab dasselbe Drehbuch mit denselben Aufgaben und denselben Testdaten aus dem eigenen Haus.
Ein Kernprozess von Anfang bis Ende
Ein Kundenauftrag von der Erfassung über die Fertigung bis zur Rechnung. Zeigt, wie rund der wichtigste Alltagsprozess wirklich läuft, ohne Schnitt und ohne Vorbereitung.
Ein kritischer Sonderfall
Eine Teillieferung mit anschließender Reklamation und Gutschrift. Hier zeigt sich, ob das System auch abseits des Standardwegs trägt, und genau dort scheitern viele Systeme.
Eine Auswertung mit echten eigenen Daten
Der Bericht offene Rechnungen nach Kunde, erzeugt aus einem bereitgestellten Datenauszug. Musterdaten verbergen Schwächen, eigene Daten zeigen die reale Komplexität.
Die Chargenrückverfolgung
Zu einer beliebigen Charge werden alle verwendeten Rohstoffe belegt. Genau hier trennt sich, welcher Anbieter die Muss-Anforderung im Standard erfüllt und welcher anpassen müsste.
Eine Aufgabe aus Anwendersicht
Ein Key User bedient das System selbst, statt zuzuschauen. Nichts zeigt die tatsächliche Bedienbarkeit so deutlich, wie wenn jemand ohne Schulung eine Standardaufgabe versucht.
Jedes Szenario wird direkt im Anschluss bewertet, nicht erst am Ende des Tages. Der Eindruck der letzten Demo verzerrt sonst das Ergebnis.
Die Nutzwertanalyse mit Beispielrechnung
Zuerst werden die Kriterien gewichtet, ihre Summe ergibt hundert Prozent. Dann bewertet jeder Fachbereich die Systeme je Kriterium auf einer Skala von eins bis fünf. Punkte mal Gewichtung ergibt den Nutzwert.
| Kriterium | Gewichtung | System A | System B | System C |
|---|---|---|---|---|
| Abdeckung der Fertigungsprozesse | 25 % | 5 · 125 | 3 · 75 | 4 · 100 |
| Finanzen und Berichtswesen | 20 % | 3 · 60 | 5 · 100 | 4 · 80 |
| Schnittstellen und Integration | 20 % | 4 · 80 | 3 · 60 | 5 · 100 |
| Bedienbarkeit im Alltag | 15 % | 4 · 60 | 5 · 75 | 2 · 30 |
| Anbieter, Support und Zukunftsfähigkeit | 10 % | 4 · 40 | 4 · 40 | 3 · 30 |
| Gesamtkosten über fünf Jahre | 10 % | 3 · 30 | 4 · 40 | 4 · 40 |
| Nutzwert von maximal 500 Punkten | 100 % | 395 | 390 | 380 |
| Verbleibende Anpassungen nach Standard First | Tiebreaker | 3 | 6 | 5 |
| Entscheidung | Gewählt |
Beispielhafte Werte. Gelesen wird jede Zelle als Punktzahl mal Gewichtung, also bei System A und dem ersten Kriterium fünf Punkte mal fünfundzwanzig Prozent gleich 125.
Das Ergebnis ist knapp, und genau das ist die wichtigste Lehre dieses Kapitels.
System A und System B liegen mit 395 zu 390 Punkten praktisch gleichauf. Wer nun so lange an den Gewichtungen dreht, bis das Wunschsystem gewinnt, hat die Nutzwertanalyse missverstanden. Ein knappes Ergebnis bedeutet, dass beide Systeme fachlich passen und ein anderer Faktor den Ausschlag geben muss.
In diesem Beispiel war das der verbleibende Anpassungsaufwand nach der Standard-First-Prüfung. System A benötigte drei Individualisierungen, System B deren sechs. Über eine geplante Nutzungsdauer von zehn Jahren bedeutet das bei jedem Update den doppelten Prüf- und Pflegeaufwand. Die Entscheidung fiel damit nicht gegen die Nutzwertanalyse, sondern jenseits ihres unentschiedenen Bereichs. Genau dafür wurde der Anpassungsaufwand vorab als Tiebreaker definiert, nicht erst nachträglich.
Was hinter dem Lizenzpreis steckt
Wer nur Lizenzpreise vergleicht, vergleicht den kleinsten Posten der Gesamtrechnung. Diese sechs Kostenblöcke gehören in jede Betrachtung, und zwar über die gesamte geplante Nutzungsdauer.
Lizenzen oder Abonnement
Der sichtbarste Posten, oft aber der kleinere Teil der Gesamtkosten. Wichtig ist, wie sich der Preis bei wachsender Nutzerzahl entwickelt.
Einführung und Datenmigration
Konfiguration, Datenübernahme aus dem Altsystem und Tests. Häufig unterschätzt, weil die Datenqualität im Altsystem selten so gut ist wie angenommen.
Anpassungen und ihre Pflege
Jede Individualisierung kostet nicht nur einmal, sondern bei jedem Update erneut. Genau hier zahlt sich Standard First über Jahre aus.
Schulung und Anlaufphase
Neben den Schulungskosten entsteht ein zeitweiliger Produktivitätsverlust, bis das Team routiniert arbeitet. Diese Phase gehört eingeplant.
Betrieb und Support
Hosting oder eigene Infrastruktur, Wartungsverträge, Supportstufen. Die Reaktionszeiten im Vertrag sind wichtiger als der Preis dafür.
Interner Aufwand
Die Arbeitszeit der eigenen Key User im Projekt. Sie taucht in keinem Angebot auf, ist aber ein realer und erheblicher Kostenblock.
Sechs Fehler, die das Beispiel bewusst umgeht
Diese Muster tauchen in fast jedem ERP-Auswahlprojekt auf. Zu jedem steht, wie sich der Fehler vermeiden lässt.
Anbieter anschauen, bevor die Prozesse klar sind
Wer erst Demos sieht und danach Anforderungen schreibt, übernimmt unbewusst die Logik des zuletzt gesehenen Systems. Lösung: Erst die eigenen Kernprozesse aufnehmen, dann den Markt betrachten.
Anpassungswünsche ungeprüft übernehmen
Jede Abteilung will ihre alte Lösung eins zu eins wiederhaben. So wird das neue System zur teuren Kopie des alten. Lösung: Jeder Wunsch durchläuft die vier Standard-First-Prüffragen.
Fast alles wird zur Muss-Anforderung erklärt
Aus Angst, etwas zu vergessen, landet jeder Wunsch bei Muss. Die Priorisierung verliert damit ihren Zweck. Lösung: Die Verteilung auf Muss, Soll und Kür sichtbar machen und Überladung diskutieren.
Jeder Anbieter zeigt, was er will
Ohne Drehbuch präsentiert jeder seine Stärken. Die Termine werden unvergleichbar, die kritischen Anforderungen kommen nicht vor. Lösung: Ein einheitliches Demo-Playbook mit denselben Aufgaben und eigenen Daten.
An den Gewichtungen drehen, bis das Ergebnis passt
Wenn das Wunschsystem nicht gewinnt, werden die Gewichte nachträglich angepasst. Damit ist die Analyse wertlos. Lösung: Gewichtung und Tiebreaker vor der ersten Demo festlegen und freigeben lassen.
Nur die Lizenzpreise vergleichen
Der Lizenzpreis ist der sichtbarste, aber selten der größte Posten. Einführung, Anpassungen und Betrieb überwiegen deutlich. Lösung: Gesamtkosten über die geplante Nutzungsdauer betrachten, inklusive internem Aufwand.
Was Standard First am Ende bringt
Die Zahlen sind realistische Näherungen für dieses Beispiel, keine Zusagen für einen konkreten Fall.
Lessons Learned
- 01Nicht jeder Wunsch nach Anpassung ist eine echte Notwendigkeit. Vier von fünf deckte hier der Standard bereits ab.
- 02Konfiguration überlebt jedes Update, Programmierung nicht. Dieser Unterschied entscheidet über die Kosten von morgen.
- 03Ein knappes Bewertungsergebnis ist kein Problem, sondern die Aufforderung, einen vorab definierten Tiebreaker zu nutzen.
- 04Gewichtungen und Tiebreaker gehören vor die erste Demo, nicht danach. Sonst bestätigt die Analyse nur das Bauchgefühl.
- 05Wer die Anwender erst bei der Einführung einbindet, zahlt den Widerstand später mit Zinsen.
- 06Individualisierung bleibt richtig, wenn eine fachliche oder gesetzliche Notwendigkeit dahintersteht. Sie muss nur begründet sein.
Häufige Fragen zu Standard First und ERP-Auswahl
Einordnung des Beispiels und Antworten zu den Fragen, die in Auswahlprojekten regelmäßig auftauchen.
Ist dieses Beispiel ein echter Kundenfall?
Nein. Es ist ein illustratives Anwendungsbeispiel, das einen typischen Ablauf zeigt. Es nennt bewusst keine realen Firmennamen, keine echten Zitate und keine konkreten Produktnamen. Alle Größen, Zeiträume, Punktwerte und Anpassungsfälle sind realistische Näherungen, die einen üblichen Verlauf abbilden, aber keine Zusagen für einen konkreten Fall darstellen.
Was bedeutet Standard First bei der Softwareauswahl?
Standard First bedeutet, dass jede Anforderung zuerst gegen die Standardfunktionen einer Software geprüft wird, bevor eine Anpassung in Betracht kommt. Oft deckt der Standard ein Bedürfnis bereits ab, manchmal mit einem leicht veränderten Prozess statt mit einer Änderung an der Software. Individualisierung bleibt die begründete Ausnahme, nicht der erste Reflex. Das senkt Kosten bei der Einführung und bei jedem künftigen Update.
Wie viele Anpassungen sind bei einer ERP-Einführung normal?
Eine allgemeingültige Zahl gibt es nicht, jedes Unternehmen und jede Branche ist anders. Bewährt hat sich aber, jeden Anpassungswunsch einzeln zu hinterfragen, statt Wünsche pauschal zu übernehmen. In diesem Beispiel wurden rund zwanzig Anpassungswünsche aus fünf Abteilungen geprüft, am Ende blieben drei begründete Individualisierungen übrig. Der Rest ließ sich mit Standardfunktionen oder leicht angepassten Prozessen lösen.
Wann ist eine Anpassung an der Software trotzdem gerechtfertigt?
Eine Anpassung ist gerechtfertigt, wenn eine echte fachliche oder gesetzliche Notwendigkeit dahintersteht, die kein Standardmodul abdeckt, etwa eine branchenspezifische Pflicht zur Rückverfolgbarkeit. Nicht gerechtfertigt ist eine Anpassung, wenn sie nur eine liebgewonnene Gewohnheit aus dem Altsystem fortsetzt. Die Faustregel lautet, jede Anpassung muss ihren Aufwand über die gesamte Nutzungsdauer hinweg rechtfertigen, nicht nur im ersten Moment.
Wer sollte in einem ERP-Auswahlprojekt mitarbeiten?
Bewährt hat sich ein kleines Kernteam mit klaren Rollen. Eine Projektleitung steuert den Prozess, je Fachbereich benennt ein Key User die Anforderungen und bewertet die Systeme, die IT prüft Schnittstellen und Betrieb, ein Entscheidungsgremium gibt frei. Wichtig ist, dass die Menschen, die später täglich mit dem System arbeiten, von Anfang an beteiligt sind und nicht erst bei der Einführung davon erfahren.
Wie funktioniert eine Nutzwertanalyse bei der ERP-Auswahl?
Bei einer Nutzwertanalyse werden die Bewertungskriterien zunächst gewichtet, sodass ihre Summe hundert Prozent ergibt. Anschließend bewertet jeder Fachbereich die Systeme je Kriterium mit Punkten, etwa auf einer Skala von eins bis fünf. Punkte mal Gewichtung ergibt den Nutzwert je Kriterium, die Summe den Gesamtnutzwert. So werden Systeme vergleichbar, statt nach Bauchgefühl gegeneinander gestellt zu werden.
Was tun, wenn zwei Systeme in der Bewertung fast gleichauf liegen?
Ein knappes Ergebnis ist kein Problem, sondern eine wichtige Information. Es bedeutet, dass beide Systeme fachlich passen und andere Faktoren den Ausschlag geben müssen. Bewährt haben sich als Tiebreaker der verbleibende Anpassungsaufwand nach der Standard-First-Prüfung, die Gesamtkosten über die geplante Nutzungsdauer und die Frage, welchem Anbieter das Team langfristig mehr zutraut. In diesem Beispiel entschied der Anpassungsaufwand.
Welche Kostenfallen gibt es bei der ERP-Auswahl?
Die Lizenzkosten sind meist der kleinere Teil. Häufig unterschätzt werden Einführung und Datenmigration, individuelle Anpassungen und deren Pflege bei jedem Update, Schulung und Produktivitätsverlust in der Anfangszeit, laufender Betrieb und Support, sowie der interne Aufwand der eigenen Mitarbeitenden während des Projekts. Wer nur Lizenzpreise vergleicht, vergleicht den kleinsten Posten der Gesamtrechnung.
Wie organisiere ich eine ERP-Auswahl mit mehreren Abteilungen?
Bewährt hat sich ein zweistufiger Ablauf. Zuerst eine anbieterneutrale Vorauswahl, die aus dem breiten Markt eine handhabbare Shortlist macht. Danach ein gemeinsamer Prozess, in dem alle Abteilungen ihre Anforderungen einbringen, jede Anforderung nach dem Prinzip Standard First geprüft wird und alle Anbieter dieselben Demo-Szenarien zeigen. Bewertet wird nach einem gewichteten, gemeinsamen Raster.
Wie lange dauert eine strukturierte ERP-Auswahl im Mittelstand?
Das hängt von Größe und Komplexität ab. In diesem Beispiel dauert der Weg von der Prozessanalyse bis zur Entscheidung etwa drei bis vier Monate. Die Vorauswahl liefert eine Shortlist in wenigen Minuten, der Großteil der Zeit entfällt auf die Anforderungsaufnahme mitsamt der Standard-First-Prüfung, auf die Anbieterpräsentationen und auf die Bewertung. Eine klare Struktur verkürzt vor allem die Abstimmung zwischen den Abteilungen.
Anforderungen schärfen, statt Software verbiegen
Standard First lässt sich auf jede Softwareauswahl übertragen, unabhängig vom Anbieter. Wer jede Anpassung vorab hinterfragt, spart Kosten bei der Einführung und bei jedem künftigen Update.