„Warum dauert die Software-Auswahl so lange?“, „Können wir nicht einfach den Marktführer nehmen, den nehmen doch alle?“, „Warum finde ich meine Anforderungen nicht im Lastenheft?“, „Genügt es nicht, einfach alle ‚Features‘ aufzuschreiben und damit an die Anbieter zu gehen?“ – Kennen Sie diese Sätze aus der Praxis? Dieser Beitrag beleuchtet den Aspekt der Anforderungen in einem Softwareauswahl-Projekt und den Umgang mit den Anforderungen und Erwartungen der Key-User. Warum ist es wichtig, diese zu kennen und adäquat zu behandeln?
Ein wichtiger Aspekt betrifft die Vielzahl an Stakeholdern, die an einer Software-Auswahl beteiligt sind. Während Geschäftsführung und Projektleitung die Auswahl aus einem übergeordneten Blickwinkel, also aus gesamtunternehmerischer Sicht betrachten, müssen die Key-User das Projekt aus einer fachbereichsspezifischen bzw. Teilprozess-Sicht betrachten. Weitere Stakeholder sind nicht im Projekt beteiligte Mitarbeiter, deren Meinung mitunter über „Key-User-Kollegen“ Eingang in das Team finden. Dabei bleibt der Gesamtkontext häufig außer Acht, weil im Fachbereich zwangsläufig nur aus der (eingeschränkten) Sicht heraus beurteilt werden kann und muss.
Zudem kommen Auswahlprojekte sehr selten in den meisten Unternehmen vor, zumal wenn es nicht nur Systeme für kleinere Teilbereiche, sondern umfassende Systeme wie ERP, PPS, xRM o. ä. betrifft. Diese kommen nur alle fünf bis zehn Jahre vor, häufig sogar noch seltener. Somit kennen viele Anwender nur „fertige“ Systemlandschaften, die sie bei Eintritt in das Unternehmen vorgefunden haben oder in die sie nach einer früheren Einführung hineingewachsen sind. Die damit zusammenhängende Arbeit bei Auswahl, Einführung und Betrieb bleibt oft verborgen oder wird unterschätzt.
Ein letzter Aspekt betrifft die Key-User. Diese gehen mitunter von Annahmen aus, die in der Realität keinen Bestand haben. Da werden oft nur technische Aspekte („Funktionsdenken“) gesehen. Der zukünftige Arbeitsablauf („Kernprozess“) wird nicht oder nur implizit beachtet, obwohl dieser die Hauptrolle spielen muss.
Aus all den genannten und weiteren Aspekten ergeben sich mitunter falsche Erwartungen an den Ablauf einer Software-Auswahl und ‑Einführung, bspw.:
[1] Hier kann ein beliebiger Funktionsbaustein eingesetzt werden, egal ob erforderlich oder nicht, ob im Gesamtkontext passend oder nicht.
Das Wichtigste ist die Kommunikation. Von Anfang an müssen alle direkt und später auch indirekt Beteiligten und Auftraggeber (Geschäftsführung oder Vorstand) in den Ablauf einbezogen werden. Es muss klar sein, dass ein Lastenheft nur die aus gesamtunternehmerischer Sicht sinnvollen Punkte enthalten sollte und kann. Es ist nicht ratsam Anforderungen jeglicher Granularität aufzuführen, sondern sich auf die zu konzentrieren, die nicht zum Standard heutiger Software-Systeme gehören und den Kernprozess unterstützen bzw. für diesen unerlässlich sind. Eine Auswahlliste mit hunderten bis tausenden von Fragen für den Software-Anbieter ist weder zielführend noch sicher! Sie gibt eine Scheinsicherheit, da diese Anforderungen sowieso vom Anbieter mit „erfüllt“ oder „mit Konfiguration/Customizing erfüllt“ beantwortet werden (man denke nur an die Zeit, die ein „korrektes“ Ausfüllen solcher Listen in Anspruch nehmen würde…).
Neben der Zeit, die es für den Anbieter braucht, selbstverständliche oder Unmengen an Anforderungen zu bewerten, kostet es auch intern Unmengen an Zeit, diese aufzustellen – alles ohne erkennbaren Mehrwert für die Auswahl bzw. noch wichtiger Einführung und Betrieb des Software-Systems.
Neben der Kommunikation mit den Key-Usern, ist ein permanentes Überprüfen der Anforderungen auf Sinnhaftigkeit und die passende Granularität erforderlich. Bereits in der Anforderungsaufnahme müssen die Punkte unmittelbar bewertet werden. Das verhindert späteres Aufräumen des Anforderungsprofils („Lastenheft“), um selbstverständliche Anforderungen zu entfernen. Wenn Sie bspw. solche Anforderungen im Lastenheft finden, ist es Zeit, aufzuräumen:
Derlei Anforderungen sind in heutigen ERP-Systemen vollkommen selbstverständlich bzw. lassen sich abbilden, ohne „ein Feld“ dafür zur Verfügung zu halten.
Die richtige Granularität in den Anforderungen findet man durch einen Abgleich mit dem Kernprozess. Alles was nicht unbedingt für diesen erforderlich ist und was selbstverständlich in modernen Software-Systemen ist, sollte entfernt werden. Bei der Bewertung kann ein kompetenter und erfahrener Berater behilflich sein.
