Vortrag am Swiss Requirements Day
Methodik für das Priorisieren von Anforderungen für der Evaluation von IT-Lösungen
Referenten:
Dr. Thomas Strösslin, APP Unternehmensberatung AG
Berthold Prutscher, Zürcher Kantonalbank
Praxisbeispiel CMS-Einführung bei der ZKB.
Die Evaluation eines ersten Systems wurde gar nicht erst abgeschlossen. Bei einem zweiten Versuch gab es bei der Einführung so viele Probleme, dass die Implementierung abgebrochen wurde.
Danach wurde eine dritte Evaluation gestartet für die 5000 Mitarbeiter der ZKB.
Die Fragen drehen sich um geschäftsstrategische Entscheide im Umfeld von Grosssystemen wie SAP oder Avaloq. Kauft man ein Produkt oder entwickelt man eines (make or buy)?
Grundsätzlich bieten sich meist die beiden Probleme, dass das neue System alles können soll und der Lieferant sich an die eigenen Bedürfnisse anpassen soll.
Das Problem 1 der «Eierlegenden-Woll-Milch-Sau» adressiert man durch Fokussierung auf Priorisierung. Z.B. möglichst wenig Ausnahmen zulassen, Prozesse an das Standardprodukt anpassen, fachliche und nicht politische Auswahl der Stakeholder.
Der Fokus soll bei der Ablösung eines bestehenden Systems auf möglichst wenig Kernpunkte liegen. Andere Aspekte werden in der Roadmap adressiert.
Das Grundsatzproblem 2 der Zusammenarbeit mit einem Software-Lieferanten basiert stark auf dem Thema Kommunikation: Es ist sehr schwierig, alle Projektteilnehmer auf demselben Wissensstand zu halten. Informationen werden durch Kommunikation über verschiedene Instanzen verfälscht.
Auch sollte man die Perspektive des Lieferanten mitberücksichtigen und den Fokus auf die ursprüngliche Aufgabe nicht verlieren. Diese wird oft durch die verschiedenen Lösungsanbieter beeinflusst.
Lieferanten sollten von vornherein wissen, welche Dokumente sie in welcher Form einzureichen haben. Dadurch kann die Vergleichbarkeit gefördert werden.
Auch sollte das Bewertungsschema kommuniziert werden.
APP geht in den 4 Hauptschritten vor
– Identifizieren der Anforderungssteller
– Definieren der Evaluationsmethoden
– Definiern der Struktur der Anfroderung und Fragen
– Bewerten und kommunizieren
Zu jedem Schritt verfügt APP über diverse Sets von Templates. Je nach Fall werden diese eingesetzt oder nicht. Z.B. umfasst die Stakeholder Analyse die Anzahl Personen, deren Wichtigkeit und deren Impact auf das Projekt. Die End-User sind meist die grösste Gruppe, dazu kommen je nach Fall Domain Architect, Software-Entwickler, IT-Operators, Enterprise architect, etc.
Evaluationsmethoden gibt es viele. Wichtig sind immer der
– Umfang des Projektes (Systemgrenzen)
– Stückelung der Evaluation (Etappierung möglich?)
– Granularität der Anforderungen (wichtig bei Grossprojekten: so grob wie möglich)
– Ausschreibung oder Einladung von Lieferanten
– Bewertungsteam (Wer wertet aus?)
– Bewertungskriterien
Bei der ZKB hat man sich für ein zweistufiges Evaluationsverfahren entschieden. In der ersten Stufe wurden 15 Bewerber berücksichtigt. In der zweiten Stufe wurden noch 10 Bewerber gewichtet. Dabei ist wichtig, nur wenige aussagekräftige Werte zu benutzen, z.B. 0 für «nicht erfüllt», 1 für «erfüllt».
Im Request for Proposal wird dem Lieferanten ein Fragenkatalog zugestellt. Dabei soll man nicht fragen, ob eine Funktion unterstützt wird (Antwort «Ja»), sondern wie ein Service geboten wird.
Der Anforderungskatalog soll hierarchisch organisiert sein in funktionale, nicht-funktionale Anforderungen und hersteller-/produktrelevante Informationen.
Die drei Aspekte werden gewichtet und deren Wichtigkeit kommuniziert.
Die offerierten Kosten müssen gegen die Anforderungen abgeglichen werden: Hat der Lieferant den Projektumfang wirklich verstanden?
Entsprechend können Projektkosten allenfalls auch steigen, wenn zusätzliche Module nötig werden, die nicht in der ursprünglichen Offerte enthalten waren.
Vollständigen Vortrag Priorisieren von Anforderungen hier herunterladen.
Ein Kommentar
Der beschriebene Prozess deckt sich in etwa 1:1 mit eigenen Erfahrungen. Für besonders wichtig erachte ich die fachliche und gerade nicht politische Auswahl der Stakeholder!