IT Systemauswahl Methodik: Mein Framework für belastbare Software-Entscheidungen

In meiner Beratungspraxis beobachte ich ein wiederkehrendes Muster: Unternehmen starten Systemauswahl-Projekte mit einer Marktrecherche. Sie googeln „beste ERP-Systeme 2025", lesen Vergleichsartikel, besuchen Messen und laden drei bis fünf Anbieter zu Demos ein. Das Problem: Zu diesem Zeitpunkt ist noch nicht klar definiert, welches Problem das neue System eigentlich lösen soll.

Tool-first statt Problem-first – das ist der Grundfehler. Wenn ein Unternehmen sagt „Wir brauchen ein neues ERP", verbirgt sich dahinter in der Regel ein Bündel von Problemen: unzuverlässige Lagerdaten, manuelle Rechnungsprozesse, fehlende Transparenz über Auftragsauslastung, keine durchgängige Nachverfolgung von der Bestellung bis zur Auslieferung. Jedes dieser Probleme hat unterschiedliche Lösungsansätze – und nicht jeder davon erfordert ein ERP-System.

Die erste Phase jeder seriösen Systemauswahl sollte daher eine Problemanalyse sein, nicht eine Marktanalyse. Das bedeutet: Die kritischen Geschäftsprozesse identifizieren, die aktuellen Schmerzpunkte dokumentieren und messbare Ziele definieren. „Wir wollen die Durchlaufzeit von Angeboten von 5 Tagen auf 1 Tag reduzieren" ist ein Ziel. „Wir wollen ein modernes System" ist keines.

Erst wenn das Problemstatement steht, kann die zweite Frage beantwortet werden: Welche Systemklasse löst dieses Problem? Muss es ein ERP sein – oder reicht ein spezialisiertes PIM-System, eine iPaaS-Plattform oder sogar eine Kombination aus Best-of-Breed-Lösungen? Diese Entscheidung hat massive Auswirkungen auf Budget, Komplexität und Betriebskosten.

Herstellerunabhängigkeit ist in der Software-Beratung ein viel benutzter, aber selten eingelöster Begriff. Viele Beratungshäuser haben Partnerschaften mit Software-Herstellern – sie erhalten Provisionen, Leads oder Implementierungsaufträge. Das beeinflusst die Empfehlung, bewusst oder unbewusst. Wenn ein Berater 30 Prozent seines Umsatzes mit SAP-Implementierungen macht, wird er selten empfehlen, statt SAP eine Kombination aus kleineren, spezialisierten Systemen einzusetzen.

Echte Vendor-Neutralität bedeutet: Der Berater hat kein finanzielles Interesse am Ergebnis der Empfehlung. Er verdient gleich viel, ob das Ergebnis SAP, Haufe X360, Xentral, Akeneo oder eine Low-Code-Plattform ist. Nur so entsteht die Freiheit, die tatsächlich beste Lösung für den konkreten Anwendungsfall zu empfehlen.

In der Praxis zeigt sich Vendor-Neutralität an drei Stellen: Erstens bei der Longlist – werden auch unbekannte oder Nischen-Anbieter berücksichtigt, die für den konkreten Anwendungsfall besser passen? Zweitens bei der Bewertung – werden Demos mit denselben Use Cases durchgeführt und anhand derselben Kriterien bewertet? Drittens bei der Empfehlung – wird transparent dokumentiert, warum ein Anbieter empfohlen wird und welche Trade-offs damit verbunden sind?

Die meisten Anforderungskataloge, die ich am Anfang eines Projekts sehe, sind Feature-Listen: „Das System muss Workflows unterstützen", „Dashboards müssen anpassbar sein", „API-Schnittstellen müssen vorhanden sein". Das Problem: Jeder Anbieter hakt diese Punkte ab. Ein Workflow in SAP, ein Workflow in Monday.com und ein Workflow in HubSpot sind fundamental unterschiedliche Dinge – aber auf einer Feature-Checkliste sehen sie identisch aus.

Use Cases machen den Unterschied. Ein Use Case beschreibt einen konkreten Geschäftsprozess von Anfang bis Ende: „Vertriebsmitarbeiter erfasst Opportunity → Angebot wird aus Produktkatalog generiert → Kunde bestätigt → Auftrag wird automatisch im ERP angelegt → Lager bekommt Kommissionierungsauftrag." Dieser Use Case testet nicht ein einzelnes Feature, sondern die Prozessfähigkeit des Systems.

In meinen Projekten arbeite ich mit einem Use-Case Backlog von 10 bis 25 Fällen, priorisiert nach Geschäftskritikalität. Jeder Use Case hat Akzeptanzkriterien – messbare Bedingungen, die erfüllt sein müssen, damit der Fall als „bestanden" gilt. Diese Use Cases werden in jeder Anbieter-Demo durchgespielt – mit denselben Daten, demselben Zeitrahmen und derselben Bewertungslogik.

Der Vorteil: Die Bewertung wird vergleichbar und nachvollziehbar. Statt „der Berater fand System A sympathischer" steht im Scoring: „System A löst 22 von 25 Use Cases, System B löst 19 von 25 Use Cases, aber System B ist bei den drei kritischsten Use Cases überlegen." Das ist die Basis für eine fundierte Entscheidung – keine Bauchentscheidung.

Total Cost of Ownership (TCO) wird in den meisten Auswahlprojekten als Preisvergleich missverstanden: Lizenzkosten System A versus Lizenzkosten System B. In der Praxis machen Lizenzkosten aber nur 20 bis 30 Prozent der Gesamtkosten aus. Der Rest verteilt sich auf Implementierung (25–35 %), Integrationen (10–15 %), Datenmigration (5–10 %), Change Management und Training (5–10 %) sowie laufende Betriebskosten (15–25 %).

Ein sauber berechneter TCO über 5 Jahre dreht regelmäßig die Reihenfolge der Anbieter um. Das vermeintlich günstigste System mit niedrigen Lizenzkosten wird zum teuersten, wenn man Customizing-Aufwand, Integrationskomplexität und den laufenden Admin-Bedarf einrechnet. Umgekehrt kann ein System mit höheren Lizenzkosten günstiger sein, wenn es einen besseren Standard-Fit bietet und weniger Anpassungen erfordert.

Praxis-Beispiel: Ein mittelständisches Handelsunternehmen verglich zwei ERP-Systeme. System A: 80.000 EUR Lizenz/Jahr, System B: 120.000 EUR Lizenz/Jahr. Auf den ersten Blick war A günstiger. Die TCO-Analyse über 5 Jahre ergab jedoch: System A benötigte 180.000 EUR für Customizing und einen dedizierten Admin (60.000 EUR/Jahr), während System B mit Standardkonfiguration und einem 50-Prozent-Admin auskam. Ergebnis nach 5 Jahren: System A = 720.000 EUR, System B = 650.000 EUR – bei besserer Prozessqualität.

TCO ist daher kein einmaliger Vergleich, sondern ein Steuerungsinstrument für die gesamte Lebensdauer des Systems. Es sollte neben den harten Kosten auch qualitative Faktoren berücksichtigen: Vendor Lock-in Risiko, Verfügbarkeit von Fachkräften für das System, Release-Zyklen und die strategische Roadmap des Anbieters.