Wenn das Business die Richtung vorgibt - erni-consultants.com

Experience Nr. 43 Oktober 2008
© by ERNI Consulting AG
Experience
ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen
Die businessgetriebene IT
Erfolgsfaktoren für das
Requirements Engineering.

Requirements Engineering | Businessgetriebene IT
Wenn das Business die Richtung vorgibt
Erfolgsfaktoren für das Requirements Engineering.
Soll das Business zum Treiber der IT-Entwicklung werden, stellt dies grosse Anforderungen an das Requirements Engineering.
Etablierte Methoden erleichtern zwar die Definition entsprechender Prozesse. Doch die Umsetzung in den Alltag einer Organisation
wird nur mit erfahrenen Business-Analysten, Kreativität, Kommunikation und Pragmatismus gelingen. Von Haggai Bass
2

Viele Unternehmen sind derzeit
daran, die Abstimmung
zwischen Business und IT zu
verbessern. Gerade in Firmen
mit grossen, leistungsfähigen
IT-Abteilungen sind es traditionell
die Techniker, welche die
tifikation der Stakeholder,
die Unterstützung der Betroffenen
bei der Formulierung
ihrer Wünsche, die Moderation
der Entscheidungsfindung
in Workshops, die Konsolidierung
der Ergebnisse und
schliesslich die Formulierung
der Anforderungen.
Beispiel 1
Einführung der Rolle
«Business-Analyst»
Ein Grossunternehmen aus
der Logistikbranche baute sein
Requirements Engineering neu
auf. Ziel war es, die IT-Entwicklung
enger an den Vorgaben
des Business auszurichten. Angelehnt
an bekannte Vorbilder
wurden neue Methoden und
Businessgetriebene IT | Requirements Engineering
Der Business-Analyst spielt eine zentrale Rolle im businessgetriebenen Requirements
Engineering. Er begleitet den gesamten Prozess.
IT-Entwicklungen prägen. Der
Übergang zu einer businessgetriebenen
IT bedeutet einen
einschneidenden Wandel für
diese Unternehmen. Betroffen
ist vor allem das Requirements
Engineering. Hier müssen Prozesse
aufgebaut werden, die
zum einen sicherstellen, dass
das Business intern genügend
klärt, was effektiv gewünscht
wird, und zum andern eine
saubere Übergabe an die IT ermöglichen.
Der Business-Analyst spielt
eine zentrale Rolle im businessgetriebenen
Requirements
Engineering. Er begleitet den
gesamten Prozess. Zu seinen
Aufgaben gehörten die Iden-
Prozesse für das Requirements
Engineering definiert. Als zentrale
neue Rolle wurde der
Business-Analyst eingeführt.
Die Rolle ist klar auf der geschäftlichen
Seite verankert.
Er ist zuständig für die Klärung
der Wünsche des Business und
noch nicht für die Frage, wie
diese Wünsche umgesetzt werden
sollen. Intern wird die Rolle
deswegen auch als Business
Engineer bezeichnet.
Für den Neuaufbau des Requirements
Engineerings zog das
Unternehmen zwei sehr erfahrene
Business-Analysten hinzu.
Sie setzten den Prozess entsprechend
der Vorgaben der Firma
um. Dabei klärten sie eine
3

Requirements Engineering | Businessgetriebene IT
4
Abb. 1: Kontinuierlicher
Verbesserungszyklus
Um die inhaltliche Qualität der Business Use Cases zu verbessern, verwendet ein Grossunternehmen
Detailprozesse und Szenarien. Der Detailprozess beschreibt einen konkreten Prozess,
angelehnt an den Geschäftsprozess.
Customer Decision Board
Adapt &
Confirm
Reihe offener Detailfragen.
So wurden mehrere Artefakte
ergänzt oder gänzlich neu geschaffen.
Diese zusätzlichen
Dokumente orientierten sich
an der Best Practice im Requirements
Engineering. Sie wurden
aber nicht einfach eingeführt.
Die Verantwortlichen
für das Business Engineering
und die in den Projekten involvierten
Business-Analysten
hatten einen Prozess geschaffen,
der garantierte, dass die
Entscheidungen gemeinsam
getroffen wurden. Dieser Prozess
wurde im Sinne einer kontinuierlichen
Verbesserung immer
wieder durchlaufen (siehe
Abb. 1).
Durch die gründliche Vorarbeit
wurde der Prozess nicht nur im
Detail definiert, sondern auch
im Alltag der Organisation verankert.
Im Lauf der weiteren
Aufbauarbeit konnten deswegen
fortlaufend Nachwuchskräfte
die Rolle von Business-
Analysten übernehmen. Doch
nicht nur in dieser Hinsicht
war der Start ein Erfolg. In
der Organisation hat der Neuaufbau
des Requirements Engineerings
mittlerweile Vor-
Continuous
Improvement
ERNI Business Analyst
Improve
Neue Artefakte, Verbesserung
der existierenden
Artefakte
bildcharakter. Ein wichtiger
Faktor bei diesem Erfolg war
die Verankerung einer iterativen
inhaltlichen Prüfung der
Wünsche des Business. Damit
konnte sicher gestellt werden,
dass die Business Use Cases,
die am Ende resultierten, nicht
nur formal korrekt waren, sondern
auch mit der Geschäftsstrategie
übereinstimmten und
gleichzeitig konkret genug waren,
um daraus Anforderungen
ableiten zu können.
Beispiel 2
Szenarien als Kommunikationsunterstützung
Um die inhaltliche Qualität
der Business Use Cases zu verbessern,
verwendet ein Grossunternehmen
Detailprozesse
und Szenarien. Der Detailprozess
beschreibt einen konkreten
Prozess, angelehnt an
den Geschäftsprozess. So wird
zum Beispiel der Geschäftsprozess
Warenverkauf durch den
Detailprozess Shop-Verkauf
konkretisiert. Die Szenarien
sind konkrete Beispiele, welche
mit Hilfe des Detailprozesses
durchgespielt werden.
Das Szenario hat immer eine
Persona (Peter Muster, Angestell-
ERNI Business Analyst
Analyze
Methoden, Artefakte,
Prozesse und Req. Engineering
Vorlagen
ERNI Business Analyst
Use
Methoden, Artefakte,
Prozesse und Req. Engineering
Vorlagen
ERNI Company
Get Know-how
Pattern Req. Startup
Pattern Req. Management
Pattern Req. Development-
Pattern Coverage Analysis
ter, bestellt ...) und beschreibt
mögliche Abläufe, egal, ob reibungslos
oder mit Störungen.
Business Use Cases werden in
mehreren Iterationen anhand
der Szenarien und Detailprozesse
überprüft.
Insbesondere die Szenarien
sind eine wertvolle Basis, um
zusammen mit den Stakeholdern
zu überprüfen, ob die
Anforderungen richtig verstanden
worden sind. Damit
ist sichergestellt, dass die Anforderungen
wirklich in die
Geschäftsprozesse und somit
in die Strategie des Unternehmens
passen. Gleichzeitig können
die Szenarien während des
Projektverlaufs weiterverwendet
werden, zum Beispiel als
Testfälle.
Der entscheidende Vorteil jedoch
liegt darin, dass der Business-Analyst
präziser weiss,
was die Stakeholder im Business
wünschen. Dadurch werden
teure Fehlentwicklungen
vermieden. Dies ist letztlich
auch der Grund, warum dem
Requirements Engineering
überhaupt viel Aufmerksamkeit
geschenkt werden sollte.

Glossar
Use-Case-Dokument
fkt. Anforderungen
n. fkt. Anforderungen
Können Missverständnisse beim
Erfassen und Formulieren der
Anforderungen vermieden werden,
spart man Kosten und
beschleunigt die Entwicklung.
Wegen der grossen Bedeutung
und der Komplexität des Requirements
Engineerings werden
grössere Unternehmen um
den Einsatz eines Tools nicht
herumkommen. Während des
ohnehin aufwändigen Wandels
hin zu einer businessgetriebenen
IT-Entwicklung haben
die Evaluation und die Einführung
eines solchen Tools allerdings
nicht oberste Priorität.
Stattdessen sollten zunächst
einfache, pragmatische Mittel
verwendet werden, auf denen
das Tool später aufgesetzt werden
kann.
Beispiel 3
Requirements Management
ohne Tooleinsatz
Für die Übergangszeit vor der
Einführung eines neuen Requirements
Management Tools
V0.1 V1.0 V1.1 V2.0 V2.1
V0.1 V1.0 V2.0
V1.0 V1.1 V1.2 V2.0
V1.0 V2.0
Release 1 Release 2
Version
konzentrierte sich ein Unternehmen
bei der Anforderungsverwaltung
zunächst auf die
wichtigen Punkte in der Administration,
insbesondere auf
die Sicherstellung der Nachverfolgbarkeit.
Diese wurde mit
einfachen Mitteln unterstützt.
Zum einen wurde für alle Projekte
eine Verzeichnisstruktur
gemäss dem VOLERE-Gliederungsschema
von S. Robertson
& J. Robertson definiert. Darauf
aufbauend erhielt jedes Release
ein Deckblatt, das die Baseline
eines Requirements Management
Tools simuliert (siehe Abb.
2). Schon mit dieser simplen
Methode wird die Übersicht für
alle Beteiligten erhöht.
Fazit
Der Wandel von einer technikgetriebenen
zu einer businessgetriebenen
IT ist heute ein
Gebot der Stunde. Dazu muss
allerdings das Requirements Engineering
völlig neu konzipiert
werden, da gerade mit dieser
Release
Disziplin die Schnittstelle zwischen
Business und IT gemanagt
wird. Dem Requirements
Engineering müsste dementsprechend
viel Aufmerksamkeit
gewidmet werden. Bei der
Neukonzeption sollte darauf
geachtet werden, dass nicht
nur der Prozess formal festgelegt
wird, sondern auch eine
inhaltliche Prüfung der Ergebnisse
garantiert ist. Im besten
Fall wird zudem die Anpassung
von gängigen Methoden an die
Organisation nach Best Practice
gestaltet. Dafür sind erfahrene
Business-Analysten zumindest
zu Beginn der Neukonzeption
unumgänglich.
Artikel online:
www.erni.ch/experience
Businessgetriebene IT | Requirements Engineering
Abb. 2: Baseline
auf Dokumentenebene
Der Wandel von einer technikgetriebenen
zu einer businessgetriebenen
IT ist heute
ein Gebot der Stunde. Dazu
muss allerdings das Requirements
Engineering völlig neu
konzipiert werden, da gerade
mit dieser Disziplin die
Schnittstelle zwischen Business
und IT gemanagt wird.
Haggai Bass
Kontakt: haggai.bass@erni.ch
Senior Consultant in der Firma ERNI Consulting AG.
Die Schwerpunkte seiner Beratertätigkeit liegen
in den Bereichen Requirements Engineering
und Process Improvement.
5

ERNI Consulting AG
Talstrasse 82 · CH-8001 Zürich · Tel. +41 44 215 42 00
Bahnhofstrasse 4 · CH-6340 Baar · Tel. +41 41 227 35 00
Casinoplatz 2 · CH-3011 Bern · Tel. +41 31 381 76 11
ERNI (Deutschland) GmbH
Ganghoferstrasse 31 · D-80339 München · Tel. +49 89 90 40 5907
ERNI (Slovakia) s.r.o.
Sturova 4 · SK-811 02 Bratislava · Tel. +421 2 32 55 37 37
www.erni.ch · info@erni.ch
www.erni.ch/experience