Analysephase

• Blue Print/ Pflichtenheft
• GAP-Analyse
• Hürden

******************************************************************************

Die Analysephase dient dem Anbieter dazu, die Anforderungen des Kunden zu erfassen, näher zu spezifizieren, umso anhand eines detaillierten Überblicks die weitere Umsetzung zu planen. Zielsetzung ist es, am Ende der Phase einen Blue Print (Pflichtenheft) zu haben, auf dessen Basis gemeinschaftlich die Umsetzung verabschiedet werden kann.

Bestandteil des Blue Print ist dann auch ein überarbeitetes Budget und ein angepasster Zeitplan. Wurden im Vorfeld nur unzureichende oder gar falsche Informationen transportiert, unabhängig von welcher Seite, wird das spätestens im Blue Print deutlich.

Du siehst die Vorarbeit in einer frühen Phase hat durchaus ihre Berechtigung. Möchte man noch sicherer gehen, empfiehlt sich eine detailliertere Analyse bereits im Vorfeld, bevor die Software überhaupt gekauft wurde. Es besteht dann zwar die Gefahr, dass die Aufwendungen für die Analyse umsonst waren, allerdings kann auch ein etwaiger Gesamtschaden von vorherein deutlich reduziert werden.

Blue Print

Ziel der Analysephase ist die gemeinsame Verabschiedung des Blue Prints.

Ja, es ist wahr, der Anbieter hat natürlich einen sehr großen Vorteil durch die Erstellung des Blue Prints, da er dadurch ein Papier in die Hand bekommt, welches seine Aufgaben klar formuliert. Bezahlt wird dieses Ergebnis durch Dich, den Kunden.

Zur Rechtfertigung muss man aber auch sagen, dass in den meisten Fällen erst durch die Erarbeitung des Blue Prints ein klar strukturiertes Anforderungsprofil beim Kunden entsteht. Dies liegt zum einen darin begründet, dass vielleicht erstmals die richtigen Fragen gestellt wurden und andererseits, dass im Vorfeld einfach die notwendigen Hausaufgaben nicht gemacht wurden. Hier bin ich zurück beim Thema ‚pro aktives Handeln‘ mit oder ohne Unterstützung durch externe Berater.

Was passiert nun in der Analysephase?

Ich würde empfehlen, dass Du Dich zunächst mal an den Vorschlägen des Projektmanagers des Anbieters orientierst. Der sollte sein Produkt kennen und daher das gemeinsam verabschiedete Ziel strukturierter und schneller erreichen.

Der RFP ist eine sehr gute Basis für die durchzuführende GAP-Analyse. Daher sollte dieses Dokument wesentlicher Bestandteil der Analyse sein. Sofern bereits ein Prototyp der finalen Softwareversion  besteht, wird das sehr hilfreich sein. Für Teilbereiche können so schon die Experten aus Front, Middle und Back Office auf einer realitätsnahen Ebene einbezogen werden.

Bestandteil der GAP-Analyse sollten neben den Vereinbarungen aus dem Vertrag insbesondere auch die bestätigten Protokolle aus der Präsentation sein.

Damit Du besser mit der neuen Software klar kommst, solltest Du frühzeitig um eine erste Schulung bitten. Da die Datenmigration Deine Ressourcen in der nächsten Zeit sehr stark binden wird, solltest Du Dir den Prozess frühzeitig erläutern lassen. Gewisse Vorbereitungen können sicherlich schon getroffen werden. Allerdings kann mit der eigentlichen Vorbereitung erst dann angefangen werden, wenn überhaupt feststeht, was, wo und wie im neuen System genutzt werden soll. Gültigkeit wird dies erst nach gemeinsamer Verabschiedung des Blue Print haben.

Hürden

Probleme sind immer dort vorprogrammiert, wo die Themen entweder zu sehr in den IT-Bereich oder andererseits zu stark in den Finanzbereich abdriften. Du kannst nicht unbedingt ein tiefes fachliches Grundverständnis über Dein Business voraussetzen. Je mehr Deine Anforderungen vom Standard des Produktes abweicht, umso unwahrscheinlicher wird es, dass Du verstanden wirst. Bei fremdsprachlichen Projekten mit internationalen Anbietern kommen meist noch sprachliche Barrieren hinzu oder werden manchmal auch als Grund für das Problem vorgeschoben.

Auch in Deiner eigenen Organisation werden die Kollegen aus der Fachabteilung nicht unbedingt einen Draht zur IT-technischen Umsetzung haben. Es ist immer wieder überraschend, wenn man bestimmte Arbeitsschritte hinterfragt. Eigentlich möchte man für das Projekt die einzelnen Schritte einfach nur strukturiert dokumentieren. Das führt dann in vielen Fällen zu regem treiben beim Experten. Vieles was nämlich in der täglichen Praxis  so anfällt ist noch gar nicht dokumentiert. Daher wird eben auch viel improvisiert. Dies dann alles in ein Regelwerk zu packen, kann sehr aufwendig werden.

Für die Analysephase auf der basierend ich einen Blue Print erstellen möchte, nutze ich folgende Fragenstruktur.

Im Originaldokument, gelangt man über die Nummern oder Bereich auf die Unterseiten mit den spezifischen Fragestellungen. Es ist bei der Ermittlung der Anforderungen sehr hilfreich, zumindest am Ende der Interviews zu prüfen, ob der Fragenkatalog auch abgearbeitet wurde, um so für sich selbst einen Plausibilitäts-Check einzubauen.

Die Qualität der Analyse hängt natürlich auch sehr stark von den eingesetzten Ressourcen und dem Budget ab. Im Verhältnis zum gesamten Projekt liegt die Inital- und Analysephase bei gut 30%.

In dieser Projektphase macht sich eventuell der Einsatz eines externen Projektbegleiters, wenn bis dahin noch nicht involviert, bezahlt. Er kann beratend und moderierend eingreifen und Teil einer gelungenen Transformation zwischen IT- und Fachbereich sein.

Eine weitere Problematik, die mit dem Blue Print verbunden ist, liegt darin, dass dieser gemeinsam von Dir und dem Anbieter verabschiedet wird. Es ist daher wichtig sich bei der Prüfung des Dokuments, nicht unter Druck setzen zu lassen. Lass Dir also vor Projektbeginn ausreichend Zeit für die Prüfung einräumen. Lege auch fest, welche qualitativen Maßstäbe Du Deiner abschließenden Prüfung zugrunde legen wirst. Ich hatte Dir ein pro-aktives Vorgehen durch die Erstellung eines RFP bereits in der Evaluierungsphase empfohlen. Außerdem sollten Zusicherung aus den Vertriebspräsentationen von Dir protokolliert und vom Anbieter gegengezeichnet werden. Diese Dokumente sollten dann Bestandteil der Verträge werden.

Jetzt, wo der Blue Print vorliegt, sollte genau geprüft werden, inwiefern Zusagen auch eingehalten werden. Es ist aber auch ganz normal, das auf Kundenseite neue oder geänderte Anforderungen basierend aus den Rückfragen während der Analyse und der Trainingsphase entstehen. Umsetzung und Budget sind nochmals auf Herz und Nieren zu prüfen. Ein leichtfertiges Einverständnis mit dem Blue Print könnte böse Folgen haben, denn hier gibst Du grünes Licht für die Umsetzung.

Der Beitrag schildert ganz grob die Analysephase bei der Einführung einer branchenspezifischen Standardsoftware. Was ich unter einer branchenspezifischen Standardsoftware verstehe, möchte ich im Artikel: Branchenspezifische Standardsoftware – was ist das? (Teil 1), der für den 18. September 2013 geplant ist, erläutern. Folgebeiträge zur Umsetzungsphase bei der Softwareeinführung sind auch geplant.