Das Wichtigste in Kürze
Über die Systemauswahl entscheiden die wenigen Anforderungen, die ein Anbieter nur mit einer Erweiterung oder gar nicht löst. Sichtbar werden sie erst, wenn zu jeder Zusage die Erfüllungsstufe im Protokoll steht.
Warum jeder Anbieter Ihre Anforderungsliste erfüllt
Auftragserfassung, Rechnungsstellung, Lagerbewegungen und Buchhaltung gehören in den ERP-Anforderungskatalog, schon für Abnahme und Vertrag. Zur Unterscheidung der Anbieter tragen sie allerdings nichts bei, weil jedes etablierte ERP-System diese Funktionen seit Jahren im Standard abdeckt und sie deshalb auch jeder Anbieter bestätigt.
Ein Zulieferer schreibt „Chargenrückverfolgung“ in seine Anforderungen, und alle Anbieter bestätigen die Zeile. Damit liegen sie zunächst richtig, denn eine Chargenverwaltung gehört bei jedem System für Fertigung und Handel zum Lieferumfang.
Erst im Prozessworkshop zeigt sich, was das Unternehmen tatsächlich benötigt. Die Rückverfolgung muss über die Zukaufteile hinweg bis auf die Schmelze reichen. Und der Nachweis muss binnen 24 Stunden beim Kunden liegen, weil dessen eigener Rückrufprozess daran hängt. Aus einer Zeile im Katalog wird damit das Kriterium, an dem ein Teil der Kandidaten scheitert.
Der Unterschied zwischen der Zeile und dem Kriterium entsteht nicht am Schreibtisch, sondern im Gespräch mit den Mitarbeitern, die den Prozess täglich verantworten. Die kostenlose ERP-Analyse grenzt den Markt vorab auf die Systeme ein, die zu Ihrem Unternehmen passen. Die Arbeit am Katalog richtet sich danach auf eine überschaubare Zahl von Kandidaten statt auf den gesamten Markt.
Bei welchen Anforderungen unterscheiden sich ERP-Systeme überhaupt?
Bei einem Einproduktbetrieb mit einer Gesellschaft fällt die Entscheidung an ganz anderer Stelle als bei einer Holding mit Werken in mehreren Ländern. Bei einem reinen Händler können allein die Nachweispflichten die Shortlist bestimmen. Welche Anforderung den Ausschlag gibt, zeigt sich deshalb erst, wenn man die Anforderungen einzeln durchgeht. Diese Anforderungen stammen fast immer aus vier Bereichen.
Branchenlogik
Entscheidend ist, wie weit der Standard eines Systems branchentypische Abläufe ohne Eingriff in das Produkt abbildet: Einkaufsbudgetplanung im Modehandel, Rezepturen mit Kuppelprodukten, terminierte Arbeitsgänge. Genügen Einstellungen, bleibt das System updatefähig. Braucht es Code, zahlen Sie dauerhaft mit.
Konzern- und Gesellschaftsstruktur
Mehrere Rechtsträger wirken bis in das Datenmodell hinein, nicht nur in die Berichte. Intercompany-Verrechnung, mehrere Währungen, abweichende Geschäftsjahresenden, Konsolidierung: Entweder bringt ein System das mit, oder jedes Thema wird zum Teilprojekt mit eigenem Budget.
Systemlandschaft und Schnittstellen
Ein neues ERP-System trifft immer auf eine gewachsene Landschaft. Wie viele Altsysteme bleiben, entscheidet über Zahl und Art der Schnittstellen. Für dieselbe Anbindung an Webshop oder Lagertechnik liefert der eine Hersteller einen fertigen Konnektor. Beim anderen wird daraus ein Entwicklungsprojekt.
Pflichten und Nachweise
E-Rechnung, revisionssichere Archivierung und die Nachweise, die ein Prüfer verlangt, stehen nicht zur Verhandlung. Jedes aktuelle ERP-System beherrscht sie. Unterschiede zeigen sich im Tempo, mit dem ein Hersteller die nächste Fassung nachzieht, und in der Zahl der abgedeckten Länder.
Von diesen vier Bereichen wird die Systemlandschaft am häufigsten unterschätzt. Ob ein bestehendes System bleibt oder weicht, ist eine Architekturentscheidung mit eigener Begründung und kein Nebenprodukt der Systemauswahl. Liegt die Zielarchitektur vor der Systemauswahl fest, stehen prüfbare Schnittstellenkriterien im Katalog statt einer Absichtserklärung.
Auf welcher Stufe erfüllt ein Anbieter die Anforderung?
Bejaht ein Anbieter eine Anforderung, ohne den Lösungsweg zu benennen, wissen Sie anschließend nicht mehr als zuvor. Denn er kann sie im Standard abdecken, über Konfiguration, über eine Erweiterung oder Branchenlösung, oder nur mit einem zusätzlichen Drittsystem. Auf dem Papier sehen diese vier Stufen gleich aus, in den Kosten über die Laufzeit unterscheiden sie sich erheblich. Eine fünfte Antwort hören Sie häufiger als alle anderen: Die Funktion kommt in einem der nächsten Releases. Solange der Anbieter dafür keine Releasenummer, keinen Termin und keine vertragliche Zusage nennt, ist sie zum Zeitpunkt Ihrer Entscheidung nicht vorhanden und wird wie eine Lücke bewertet.
Dass ein System konfiguriert werden muss, ist der Normalfall und kein Mangel. Jedes ERP-System wird eingerichtet, bevor es in den Produktivbetrieb geht. Nummernkreise, Buchungsregeln, Freigabestufen und Berechtigungen sind Einstellungen, keine Eingriffe in das Produkt. Ein Abzug für Konfigurationsaufwand bewertet am Ende nur, wie ein Hersteller seinen Auslieferungszustand gewählt hat. Verlangt ein System allerdings so viel Einrichtung, dass sie in Beratungstagen gemessen wird, gehört dieser Aufwand ins Angebot.
Mit der ersten Erweiterung entsteht Code, der den Releasetakt des Herstellers mitgehen muss, und in der Cloud ist dieser Takt nicht verhandelbar. Die technische Kompatibilität prüft der Hersteller. Ob Ihr Prozess nach dem Update fachlich noch durchläuft, müssen Ihre eigenen Mitarbeiter mit Ihren eigenen Testdaten feststellen. Ändert der Gesetzgeber eine Pflicht, liefert der Hersteller die Anpassung für seinen Standard. Für Ihre Erweiterung müssen Sie selbst sorgen. Das spricht nicht gegen Erweiterungen. Sie verursachen aber über die gesamte Laufzeit Kosten, und dieser Posten fehlt in den meisten Bewertungen.
Deckt der Standard eine Anforderung nicht ab: Beruht sie auf einer gesetzlichen Pflicht oder einer Zertifizierung, wird zugekauft, weil ein Hersteller die Pflege dauerhaft übernimmt. Betrifft sie das, was das eigene Unternehmen von Wettbewerbern unterscheidet, lohnt die Eigenentwicklung.
KI-gestützte Entwicklung senkt die Kosten für das Schreiben von Code. Bei Integrationen und kleinen Zusatzwerkzeugen macht das die Eigenentwicklung tatsächlich attraktiver. Im Kern des ERP-Systems ändert sich dagegen wenig, denn dort entfällt der größere Teil des Aufwands auf Spezifikation, Test und Releasepflege.
In einer herstellerunabhängigen ERP-Auswahlberatung wird die Stufe deshalb zu jeder einzelnen Zusage schriftlich festgehalten. Dazu gehören das Datum und der Name dessen, der die Zusage gegeben hat.

Warum ein System an einer einzigen Anforderung scheitern kann
Eine Muss-Anforderung ist noch kein K.O.-Kriterium, auch wenn beides im Sprachgebrauch oft zusammenfällt. Die meisten Muss-Anforderungen lassen sich über eine Erweiterung lösen, werden bepreist und fließen regulär in die Bewertung ein. Nur bei den wenigen Anforderungen, die vorab ausdrücklich als Ausschluss gesetzt wurden, scheidet ein Kandidat aus dem Verfahren aus, und daran ändert auch eine hohe Gesamtpunktzahl nichts. In der Bewertungsrunde löst das regelmäßig Widerspruch aus, weil ein ausgeschiedener Kandidat in der Gesamtwertung häufig gut abschneidet.
Ein Multichannel-Modehändler mit mehreren Gesellschaften, Filialen, eigenem Onlineshop und Großhandel für seine Eigenmarken ließ seine Anforderungen aufnehmen. Aus über 200 Anforderungen wurden rund 80 gewichtete Bewertungskriterien, von 44 betrachteten ERP-Systemen kamen 5 in die Detailbewertung.
Einen dieser fünf nahm am Ende ein einziges vorab gesetztes Ausschlusskriterium aus dem Verfahren: Im Cloud-Lieferumfang fehlte die Einkaufsbudgetplanung, die im Modehandel als Open-to-Buy geführt wird. Sichtbar wurde das erst in der Detailbewertung, weil der Anbieter die entsprechende Zeile zuvor bejaht hatte.
Solche Ausschlusskriterien legt die Geschäftsführung fest, schriftlich begründet und bevor das erste Angebot vorliegt. Wer ein K.O.-Kriterium erst einführt, nachdem die Ergebnisse vorliegen, bestätigt damit ein System, das längst gesetzt war. Was für die Ausschlusskriterien gilt, gilt genauso für die Gewichtung. Nach den Anbieterpräsentationen gewichtet niemand mehr unbefangen, weil allen Beteiligten bekannt ist, welcher Kandidat von welcher Verschiebung profitiert.
Ändern sich die Voraussetzungen, etwa durch eine neue gesetzliche Pflicht oder einen Zukauf, darf ein Kriterium ergänzt werden, dann aber für alle Kandidaten und vor der nächsten Bewertungsrunde.
Jeder dieser Schritte bedeutet Aufwand: die Anforderungen zu finden, bei denen die Systeme auseinandergehen, sie nachprüfbar zu beschreiben, die Stufen vor der ersten Präsentation festzuhalten. Neben dem Tagesgeschäft verfügt kaum ein Unternehmen über diese Kapazität.
Wie das Vorprojekt SPARK® 2.0 der ICB GmbH die entscheidenden Anforderungen prüft
Für Sie beginnt das ERP-Vorprojekt SPARK® 2.0 mit moderierten Workshops, einem je Ende-zu-Ende-Prozess. Zwei bis drei Stunden je Fachbereich genügen, um die Stellen zu benennen, an denen das heutige System die Arbeit behindert. Ihr Aufwand beschränkt sich auf diese Termine und einzelne Rückfragen.
Die Arbeit, die sonst über Wochen Kapazität bindet, läuft parallel, ohne Sie zu beanspruchen. Der Markt wird in einem Durchgang gesichtet, jede Anforderung bei jedem Anbieter nach demselben Maßstab eingeordnet und mit einer Quelle belegt, die Sie nachlesen können. Die Kriterien, an denen ein Kandidat ausscheidet, liegen fest, bevor die Anbieter präsentieren. Das Tempo kommt von KI-Agenten, ein Berater nimmt jeden Schritt ab.
Die ICB GmbH verkauft keine Lizenzen und erhält keine Provisionen von ERP-Anbietern, abgerechnet wird nach Aufwand. Welches System am Ende empfohlen wird, ändert am Honorar nichts. Was bleibt, ist eine Entscheidung, die Sie zwei Jahre später noch begründen können. Zu jeder Anforderung ist nachlesbar, welcher Anbieter was zugesagt hat.
Über die Systemauswahl entscheiden die wenigen Anforderungen, die ein Anbieter nur mit einer Erweiterung oder gar nicht löst. Sichtbar werden sie erst, wenn zu jeder Zusage die Erfüllungsstufe im Protokoll steht.
Das Titelbild ist KI-generiert. Die Darstellung der Erfüllungsstufen ist eine eigene Grafik der ICB GmbH. Das Projektbeispiel beschreibt ein reales Beratungsprojekt in anonymisierter Form.




