Seit gut 20 Jahren arbeite ich mit Software für Planung, Reporting und Analytics. Ich war Controller, habe verschiedene Lösungen implementiert und begleite heute Unternehmen bei der Softwareauswahl. Dabei zeigt sich immer wieder: Die Qualität der späteren Lösung hängt wesentlich davon ab, wie die Entscheidung vorbereitet wird. Fehler fallen häufig erst nach dem Kauf auf, wenn Lizenzen erworben, Berater beauftragt und interne Erwartungen geweckt sind.
Eine neue Auswahl hat meist einen konkreten Auslöser. Der Anbieter wurde übernommen und die weitere Produktstrategie ist unklar. Die Cloud kostet mehr als erwartet. Ein ERP-Wechsel verändert Prozesse und Datenströme. Nach einer Fusion gelten neue Anforderungen. Oder die Planung läuft weiterhin in Excel, was flexibel ist, aber bei Skalierung, Wartung und Kontrolle hohe Risiken erzeugt.
Solche Veränderungen setzen Unternehmen unter Entscheidungsdruck. Gleichzeitig wächst der Markt: Anbieter verändern ihre Portfolios, neue Produkte kommen hinzu und etablierte Produkte werden mit neuen AI-Funktionen aufgewertet. Die meisten Unternehmen kennen zwei oder drei Produkte genauer. Für eine Investition, die viele Jahre wirken soll, ist das eine schmale Entscheidungsbasis.
Wie lässt sich unter diesen Bedingungen verlässlich entscheiden, welche Software zu den Anforderungen, zur Architektur und zur Organisation passt?
Warum reicht ein formaler Auswahlprozess allein nicht aus?
Ein Auswahlprozess kann auf den ersten Blick sehr ordentlich wirken, wenn es einen Kriterienkatalog, Punktwerte, Anbieterpräsentationen und am Ende eine Rangliste gibt. Die Qualität der Entscheidung hängt allerdings davon ab, welche Fragen gestellt werden, wie gut die Kriterien zwischen Produkten unterscheiden und ob alle Kandidaten unter vergleichbaren Bedingungen geprüft werden.
Ohne klares Zielbild prägen verfügbare Angebote und bestehende Anbieterbeziehungen die Vorauswahl. Ohne trennscharfe Kriterien bekommen Präsentationsstärke, der berühmte erste Eindruck und aktuelle Trendfunktionen zu viel Gewicht. Ein attraktives Dashboard oder ein neuer AI Agent sagen wenig darüber aus, wie Datenintegration, Kalkulationslogik, Performance und Modellpflege im Alltag funktionieren.
Auch der Begleiter beeinflusst das Ergebnis. Implementierungspartner und IT-Dienstleister kennen bestimmte Produkte sehr gut. Ihre Empfehlungen orientieren sich am eigenen Portfolio, an vorhandenen Kompetenzen und an wirtschaftlichen Interessen. Das ist nachvollziehbar, schränkt aber die neutrale Sicht auf den Gesamtmarkt ein. Wer später an Auswahl, Lizenzen oder Implementierung verdient, bewertet Alternativen aus einer anderen Position als ein unabhängiger Analyst.
Und ChatGPT? Generative AI kann Fragen kreieren, Workshops vorbereiten helfen und einen ersten Kriterienkatalog strukturieren. Das spart Zeit. Solche Kataloge enthalten oft viele plausible Fragen, die fast jedes Produkt gleich beantwortet. Aktuelle Produktstärken, reale Projekterfahrungen, die Qualität eines Implementierungspartners und die Eignung für die eigene Architektur kann ChatGPT nicht verlässlich prüfen. Und ob das LLM darunter einen Bias hat, werden Sie nie erfahren.
AI ist damit ein nützliches Werkzeug für die Vorbereitung. Für die Entscheidung braucht es zusätzlich aktuelle Marktkenntnis, vertrauenswürdige Vergleichsdaten und Tests mit den eigenen Anforderungen.
Was zeigen die BARC-Daten über strukturierte Softwareauswahl?
Eine Auswertung aus dem BARC BI & Analytics Survey zeigt einen deutlichen Zusammenhang: 72 Prozent der Vorreiter führten vor dem Kauf eine kompetitive Evaluation mehrerer Produkte durch. Bei den Nachzüglern waren es 41 Prozent. Als Vorreiter gelten die rund zehn Prozent der Unternehmen mit dem höchsten Business Benefits Index. Die Auswertung basiert auf 1.014 Antworten.
Die Zahlen zeigen eine Korrelation. Unternehmen mit hohem Business-Nutzen investieren häufiger in eine umfassende Anforderungserhebung, einen breiten Marktvergleich und eine detaillierte Prüfung der Shortlist-Kandidaten. Bei Unternehmen mit geringerem Nutzen finden wir häufiger Entscheidungen auf Basis eines strategischen Anbieters oder einer informellen Empfehlung.
Zeit und Budget für die Auswahl sichern damit die eigentliche Investition ab. Eine Fehlentscheidung erzeugt später zusätzliche Implementierungsarbeit, Akzeptanzprobleme, schlechte Performance, funktionale Lücken oder einen vorzeitigen Systemwechsel. Entsprechend hoch sind die monetären und nicht-monetären Folgekosten.
Wie läuft eine strukturierte Softwareauswahl ab?
Unser Auswahlprozess umfasst sechs Phasen. Jede hat einen klaren Zweck.
- Vorbereitung: Ziele, Scope, Rollen und Verantwortlichkeiten festlegen. Wer entscheidet? Wer kennt die Prozesse? Wer verantwortet die Lösung später im Unternehmen?
- Anforderungen erheben: Vorhandene Unterlagen analysieren, Workshops durchführen und die Auskenner und Könner aus Fachbereich und IT interviewen.
- Anforderungen strukturieren: Die Ergebnisse dokumentieren, priorisieren, abstimmen und in K.-O.-Kriterien sowie ein Bewertungsraster übersetzen.
- Markt eingrenzen: Aus mehr als 100 Produkten entsteht eine Longlist von rund 30 Produkten und anschließend eine Shortlist mit drei bis fünf Kandidaten. Diese Phase dauert typischerweise ein bis zwei Monate.
- Detailevaluierung: Die Finalisten unter gleichen Bedingungen prüfen. Dazu gehören strukturierte Demos, gezielte Tests und bei relevanten Investitionen ein kompetitiver Proof of Concept. Am Ende stehen Entscheidung und Verhandlung.
- Einführung: Die Ergebnisse strukturiert an den ausgewählten Implementierungspartner übergeben. Eine gute Dokumentation beschleunigt den Projektstart.
Die Anforderungen müssen fachliche, technische, organisatorische und anbieterbezogene Aspekte abdecken. Welche Kriterien relevant sind, hängt vom Zielbild und Einsatzkontext ab.
Eine Frage wie „Unterstützt das Produkt Planung?“ trennt den Markt kaum. Aussagekräftiger sind die konkrete Planungslogik, die Verbindung operativer Teilpläne mit der Finanzplanung oder der Aufwand für spätere Änderungen. Auch die Gewichtung sollte vor den Anbieterpräsentationen feststehen. Sonst verschiebt eine gute Demo unbemerkt die Prioritäten.
Wann lohnt sich ein kompetitiver Proof of Concept?
Bei einer relevanten Investition, komplexen Anforderungen oder geschäftskritischen Kriterien bietet ein kompetitiver Proof of Concept (PoC) die höchste Sicherheit. Dabei schauen Sie unter die Motorhaube der Software und lernen Ihre zukünftigen Berater bei der Zusammenarbeit kennen:
- Wie gut können die späteren Anwender typische Aufgaben im Produkt selbstständig erledigen?
- Wie werden die relevanten Daten integriert und verarbeitet?
- Wie einfach lassen sich Modelle und Logiken anpassen?
- Wie gut versteht der Implementierungspartner die Aufgabenstellung?
- Welche Performance zeigt das Produkt mit realistischen Datenmengen?
- Wie hoch ist der Aufwand für Betrieb, Pflege und spätere Änderungen?
Die Vorbereitung für einen guten PoC ist zweifellos aufwendig. Aufgabenpapier, Daten, Testfälle, Bewertung und Termine müssen sauber aufgesetzt werden. Ein PoC mit nur einem Produkt spart überraschend wenig Arbeit, liefert aber keinen direkten Vergleich. Deshalb raten wir in den meisten Fällen dazu, mindestens zwei, besser drei Kandidaten direkt miteinander zu vergleichen.
Wenn die Entscheidung langfristige Folgen hat, führt an einem kompetitiven PoC kaum ein Weg vorbei.
Wo reduziert BARC Aufwand und Risiko?
Eine gründliche Auswahl kostet Zeit. Bewährte Methoden, vorbereitete Anforderungs- und Kriterienkataloge sowie aktuelle Marktdaten verkürzen die Arbeit deutlich.
BARC ist ein neutrales Analystenhaus. Wir verkaufen keine Softwarelizenzen und erhalten von Anbietern kein Geld für eine bessere Bewertung oder Platzierung. Unser Interesse liegt in einer belastbaren Entscheidung für das Unternehmen, unabhängig davon, welches Produkt am Ende gewinnt.
Dazu kommt die Marktkenntnis aus mehr als 20 Jahren und über 1.000 begleiteten Auswahlprojekten. Die BARC Scores machen Stärken und Schwächen der Produkte vergleichbar. Die BARC Surveys zeigen, wie Unternehmen die Produkte im realen Einsatz bewerten, etwa bei Zufriedenheit und Performance.
Auf dieser Basis erstellen wir eine bewertete Shortlist. Für den Proof of Concept helfen wir beim Aufgabenpapier, begleiten die Durchführung und bereiten die Entscheidungsempfehlung auf.
Neutrale Beratung und vertrauenswürdige Vergleichsdaten erhöhen die Verlässlichkeit und reduzieren Ihren internen Aufwand.
Was sollten Sie jetzt konkret tun?
Grenzen Sie zuerst das Problem ab. Welche Verbesserung soll die neue Software erreichen? Welche Prozesse gehören in den Scope? Welche Themen bleiben außerhalb des Projekts?
Benennen Sie anschließend die Prozesskenner, späteren Anwender, IT-Verantwortlichen und den Sponsor. Das Team braucht ausreichend Zeit und ein klares Mandat. Starten Sie danach den Auswahlprozess und halten Sie die vereinbarten Entscheidungspunkte ein. Wiederholte Vertagungen entwerten die Ergebnisse, weil sich Anforderungen, Markt und Angebote weiterentwickeln.
Weitere Details finden Sie in der Keynote „Wie finde ich die richtige Planungs- und Reporting-Software, ohne es zu bereuen?“ und im BARC-Leitfaden zur Softwareauswahl. Wenn Sie eine Shortlist oder einen Proof of Concept vorbereiten, können Sie das Auswahlprojekt mit BARC besprechen.
Am 24. November 2026 lassen sich aktuelle Lösungen auf der BI & Analytics Tagung in Wien direkt vergleichen. Dr. Christian Fuchs zeigt dort in seinem Vortrag „Augen auf beim Softwarekauf: Was nach der Demo wirklich zählt“, welche Kriterien nach der Präsentation entscheidend sind.
