Das Framework für die digitale Transformation von objectiF RPM – Teil 3: Geschäftsanforderungen und Ziele

Nachdem ich Ihnen im ersten Teil der Blog-Reihe einen Überblick über das Framework gegeben und das Beispiel Northern Country Stores vorgestellt habe, befasste sich der zweite Teil mit der Strategieanalyse. Dort haben Sie erfahren, welche Stakeholder, Bedarfe und Nutzen das Change-Vorhaben zur digitalen Transformationen analysiert hat. Heute geht es weiter mit der Definition und Priorisierung von Geschäftsanforderungen sowie Zielen. Wir befinden uns also bei Schritt 2 von 5. Und wie letztes Mal heißt es:

Betrachten Sie die Reise zur digitalen Transformation als eine der etwas anderen Art. Obwohl wir mehrere Etappenziele in diesem Workflow erreichen, rudern wir in der Praxis doch zu den vorherigen Orten immer wieder zurück. Denn wir verfolgen eine iterative Entwicklung, d.h. alle Schritte laufen mehr oder weniger parallel ab.

Nach der Strategieanalyse geht es weiter zu den Geschäftsanforderungen und Zielen.

Ziele von Geschäftsanforderungen

Warum sollten Sie Geschäftsanforderungen definieren? Nun, Sie bilden zum einen die Brücke von der Strategie zu den konkreten Anforderungen, d.h. zum „klassischen“ Requirements Engineering, das Sie später durchführen werden.

Zum anderen lassen sich durch Geschäftsanforderungen konkrete Ziele ermitteln. Konkreter in dem Sinne, weil sie u.a. realistisch, erreichbar und messbar sind. Am Projektende sollen Sie schließlich mit Gewissheit sagen können: Wir haben die gesetzten Ziele erreicht. Und wenn dies nicht der Fall ist, lässt sich exakter feststellen, warum und inwieweit Sie die Ziele verfehlt haben. Kurzum: Die Entwicklung wird transparenter und nachvollziehbarer.

Geschäftsanforderungen definieren und priorisieren sowie Ziele ableiten

Auch das Projekt Northern Country Stores hat Geschäftsanforderungen ermittelt. Sie finden diese in der Themenleiste unter Strategie. Dort wurden sie ebenfalls bereits priorisiert. Ein Klick auf eine Geschäftsanforderung wie Läden weitgehend ohne Personal betreiben öffnet ein Formular, in dem die Anforderung beschrieben und mit Bedarfen, Zielen, Stakeholdern sowie Risiken verbunden ist. Sie hat sich z.B. aus dem Bedarf Läden nicht mehr rentabel ergeben. Um die Geschäftsanforderung zu konkretisieren, wurde ein Geschäftsziel abgeleitet. Und zwar: Die Personalkosten sollen um 80% gesenkt werden. Es wird somit eine spezifische Zahl genannt, anhand derer Sie später den Erfolg des Projekts zur digitalen Transformation messen können.

Für die Geschäftsanforderungen und deren Priorisierung gibt es ein spezielles Backlog.

Es lassen sich die gesamten Ziele im Change-Vorhaben Northern Country Stores durch einen Klick auf das Zieldiagramm betrachten. Dort erkennen Sie, wie bereits ein Feature Requirement vom oben genannten Geschäftsziel abgeleitet wurde. Dazu mehr in einem anderen Blog-Beitrag, der sich mit dem Requirements Engineering befassen wird.

Alle Ziele mit Stakeholdern auf einen Blick: das Zieldiagramm in objectiF RPM.

Risiken ableiten

Betrachten wir die Möglichkeit, Geschäftsanforderungen mit Risiken zu verbinden, genauer. Jedes Vorhaben ist mit Risiken behaftet. Insbesondere ein solch weitgreifendes Projekt mit dem Ziel der digitalen Transformation. Wenn es die Risiken kennt, kann es ihnen entgegenwirken oder – sofern sie eintreten – auf eine bereits erarbeitete Behebungsstrategie zurückgreifen.

Auch im Projekt Northern Country Stores hat man u.a. erkannt, dass die IoT-Technologie, die für Läden ohne Personal notwendig ist, Sicherheitsrisiken aufweist. Denn sie verarbeitet personenbezogene Daten wie die Kontoinformationen, auf die eine dritte Person z.B. zugreifen könnte.

Risikoanalyse mit objectiF RPM

Fazit

Heute haben wir die Geschäftsanforderungen und die daraus abgeleiteten Ziele im Change-Vorhaben Northern Country Stores betrachtet. Anhand der Ziele können Sie am Projektende den Erfolg messen. Außerdem lassen diese sich mit Stakeholdern und Anforderungen verbinden, sodass die Traceability sichergestellt wird. Bis Sie am Projektende ankommen, braucht es noch weitere Schritte bzw. Etappenziele auf unserer Reise. Zum Beispiel: Wie soll die Lösung konkreter aussehen? Wie lässt sich ein erster Lösungsentwurf gestalten? Das erfahren Sie im nächsten Teil der Blog-Reihe.

Wer selbst Antworten auf diese Fragen erhalten möchte, kann sich gern die kostenlose Trial Edition von objectiF RPM herunterladen. Ich hoffe, wir lesen uns trotzdem beim nächsten Mal! Denn die Reise geht weiter.