Eine belastbare Softwareauswahl vergleicht nicht abstrakte Funktionslisten, sondern prüft Lösungen anhand realer Arbeitssituationen. Sie beginnt mit dem betrieblichen Problem und endet erst mit einer Entscheidung, die Einführung, Betrieb und spätere Ablösung einschließt.
1. Auftrag und Entscheidung klären
Definiere:
- welches betriebliche Problem bearbeitet wird,
- welches Ergebnis sich verbessern soll,
- welche Bereiche und Rollen betroffen sind,
- wer fachlich entscheidet,
- welche Rahmenbedingungen und Ausschlusskriterien gelten,
- woran der Erfolg später erkannt wird.
Eine Auswahl ohne klare Entscheidungsverantwortung sammelt leicht immer neue Wünsche, ohne Prioritäten setzen zu können.
2. Reale Arbeit untersuchen
Verfolge typische und schwierige Vorgänge. Dokumentiere:
- benötigte Informationen,
- Rollen und Entscheidungen,
- Hauptschritte und Übergaben,
- verwendete Systeme und Nebenlisten,
- Ausnahmen,
- beobachtete Fehler, Wartezeiten und Abhängigkeiten.
Trenne Problem und Lösung. „Der Außendienst kennt den freigegebenen Termin nicht“ ist eine Anforderungslage. „Wir brauchen eine mobile App“ ist eine mögliche Antwort.
3. Anwendungsszenarien formulieren
Anwendungsszenarien beschreiben, wie eine Rolle mit der künftigen Lösung ein relevantes Ergebnis erzeugt.
Beispiel:
Eine Projektleitung erkennt vor der Kundenzusage, ob Material und Fachrolle im gewünschten Zeitraum verfügbar sind. Abweichungen sind sichtbar und können einer entscheidungsbefugten Rolle vorgelegt werden.
Formuliere auch Ausnahmefälle, Vertretung, Korrektur und Systemausfall. Sie unterscheiden geeignete Lösungen häufig stärker als der Normalweg.
4. Anforderungen priorisieren
Ordne Anforderungen in:
- Muss: Ohne diese Fähigkeit kann die betriebliche Funktion nicht angemessen erfüllt werden.
- Soll: Hoher Nutzen, aber gegebenenfalls anders lösbar.
- Kann: Wünschenswert, jedoch nicht entscheidend.
- Ausschluss: Risiko oder Grenze, die nicht akzeptiert wird.
Ergänze neben Funktionen:
- Bedienbarkeit für relevante Rollen,
- Datenführung und Migration,
- Integration und Schnittstellen,
- Berechtigungen und Nachvollziehbarkeit,
- Betrieb, Support und Wiederherstellung,
- Anpassbarkeit und Updatefähigkeit,
- Export und Ausstieg.
5. Den Markt sinnvoll eingrenzen
Eine schriftliche Kurzinformation mit Szenarien und Ausschlusskriterien ermöglicht eine gezielte Vorauswahl. Prüfe öffentlich verfügbare Dokumentation, Schnittstellen, Betriebsmodell und Referenzen im vergleichbaren Anwendungskontext.
Bewertungen anderer Nutzer können Hinweise geben, ersetzen aber keinen eigenen Test. Nutzungserfolg hängt stark von Prozess, Konfiguration und Einführung ab.
6. Demos führen statt konsumieren
Gib ausgewählten Anbietern dieselben Anwendungsszenarien. Bitte um eine durchgängige Demonstration mit eigenen, anonymisierten Beispieldaten.
Beobachte:
- Wie viele Schritte benötigt der typische Fall?
- Was geschieht bei fehlenden oder widersprüchlichen Daten?
- Wie funktionieren Entscheidung und Vertretung?
- Welche Konfiguration oder Zusatzkomponente wird benötigt?
- Wo entstehen Exporte oder manuelle Übertragungen?
- Wie wird ein Fehler sichtbar und behoben?
- Welche Aussagen sind Standardfunktion, Planung oder individuelle Entwicklung?
Dokumentiere offene Punkte und lass Zusagen schriftlich konkretisieren.
7. Technik und Betrieb prüfen
- Systemarchitektur und Betriebsmodell
- Rollen, Authentifizierung und Berechtigungen
- Schnittstellen und Datenformate
- Protokollierung und Überwachung
- Sicherung und Wiederherstellung
- Leistungsgrenzen und Verfügbarkeit
- Release- und Änderungsprozess
- Administrations- und Supportbedarf
- Datenexport und Vertragsende
Rechtliche, datenschutzbezogene oder branchenspezifische Anforderungen müssen für den konkreten Einsatz aktuell fachkundig bewertet werden.
8. Gesamtkosten und Nutzen rechnen
Berücksichtige über einen sinnvollen Zeitraum:
- Lizenzen und nutzungsabhängige Gebühren,
- Einführung und Konfiguration,
- Migration und Datenbereinigung,
- Schnittstellen und Erweiterungen,
- interne Projektzeit,
- Schulung und Begleitung,
- Betrieb, Support und Administration,
- Updates und Weiterentwicklung,
- Ausstieg und Datenübernahme.
Stelle diesen Kosten die erwartete Wirkung gegenüber, etwa weniger Rückfragen, kürzere Durchlaufzeit, höhere Datenqualität oder bessere Vertretbarkeit. Vermeide Scheingenauigkeit bei unsicheren Annahmen.
9. Einen Pilot durchführen
Ein Pilot sollte einen vollständigen, begrenzten Arbeitszusammenhang mit realen Rollen, Daten und Ausnahmen abbilden.
Lege vorher Kriterien fest:
- Können Nutzer relevante Fälle ohne dauernde Hilfe bearbeiten?
- Sind Status, Verantwortung und Information erkennbar?
- Funktionieren Integrationen und Datenqualität?
- Wie hoch sind Konfigurations- und Pflegeaufwand?
- Entstehen neue Nebenlisten?
- Was passiert bei Fehler und Ausfall?
10. Entscheidung und Einführung verbinden
Zur Entscheidung gehören auch:
- fachliche Produktverantwortung,
- Daten- und Migrationsplan,
- Rollen- und Berechtigungskonzept,
- Einführung in sinnvollen Etappen,
- Schulung anhand realer Arbeit,
- Support und Fehlerweg,
- Abschaltung oder Ablösung alter Lösungen,
- Termin für die Wirkungsprüfung.
Typische Auswahlfehler
- Anforderungen sind eine unpriorisierte Wunschliste.
- Nur Führungskräfte beschreiben die Arbeit.
- Anbieter zeigen ausschließlich ihren idealen Standardfall.
- Bedienbarkeit wird mit einer kurzen Demo beurteilt.
- Migration und Integration gelten als spätere Details.
- Vertrags- und Ausstiegskosten fehlen.
- Der Pilot testet Funktionen, aber keinen vollständigen Arbeitsablauf.
- Mit Vertragsunterschrift endet die fachliche Verantwortung.
Gute Unternehmenssoftware wird nicht durch eine perfekte Bewertungstabelle gefunden. Sie entsteht aus einer begründeten Auswahl und einer Einführung, die Technik und Organisation gemeinsam gestaltet.
Direkt anwenden
Entscheidungsraster Softwareauswahl
Vergleiche Lösungen anhand desselben Anwendungsszenarios – nicht anhand unterschiedlich inszenierter Demos.
Anschlussfragen
Häufig gefragt
Wie viele Anbieter sollte man vergleichen?
Eine kleine, begründete Vorauswahl ist meist aussagekräftiger als eine breite Funktionsabfrage. Entscheidend ist, dass alle Kandidaten dieselben realen Szenarien und Ausnahmefälle zeigen.
Reicht eine Produktdemo für die Auswahl?
Nein. Eine Demo zeigt zunächst nur, was ein Anbieter zeigen möchte. Ein Pilot mit eigenen Beispieldaten, Rollen und Ausnahmen prüft, ob die Lösung im tatsächlichen Arbeitszusammenhang trägt.