Wenn das Business die Richtung vorgibt - erni-consultants.com
Wenn das Business die Richtung vorgibt - erni-consultants.com
Wenn das Business die Richtung vorgibt - erni-consultants.com
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Experience Nr. 43 Oktober 2008<br />
© by ERNI Consulting AG<br />
Experience<br />
ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen<br />
Die businessgetriebene IT<br />
Erfolgsfaktoren für <strong>das</strong><br />
Requirements Engineering.
Requirements Engineering | <strong>Business</strong>getriebene IT<br />
<strong>Wenn</strong> <strong>das</strong> <strong>Business</strong> <strong>die</strong> <strong>Richtung</strong> <strong>vorgibt</strong><br />
Erfolgsfaktoren für <strong>das</strong> Requirements Engineering.<br />
Soll <strong>das</strong> <strong>Business</strong> zum Treiber der IT-Entwicklung werden, stellt <strong>die</strong>s grosse Anforderungen an <strong>das</strong> Requirements Engineering.<br />
Etablierte Methoden erleichtern zwar <strong>die</strong> Definition entsprechender Prozesse. Doch <strong>die</strong> Umsetzung in den Alltag einer Organisation<br />
wird nur mit erfahrenen <strong>Business</strong>-Analysten, Kreativität, Kommunikation und Pragmatismus gelingen. Von Haggai Bass<br />
2
Viele Unternehmen sind derzeit<br />
daran, <strong>die</strong> Abstimmung<br />
zwischen <strong>Business</strong> und IT zu<br />
verbessern. Gerade in Firmen<br />
mit grossen, leistungsfähigen<br />
IT-Abteilungen sind es traditionell<br />
<strong>die</strong> Techniker, welche <strong>die</strong><br />
tifikation der Stakeholder,<br />
<strong>die</strong> Unterstützung der Betroffenen<br />
bei der Formulierung<br />
ihrer Wünsche, <strong>die</strong> Moderation<br />
der Entscheidungsfindung<br />
in Workshops, <strong>die</strong> Konsoli<strong>die</strong>rung<br />
der Ergebnisse und<br />
schliesslich <strong>die</strong> Formulierung<br />
der Anforderungen.<br />
Beispiel 1<br />
Einführung der Rolle<br />
«<strong>Business</strong>-Analyst»<br />
Ein Grossunternehmen aus<br />
der Logistikbranche baute sein<br />
Requirements Engineering neu<br />
auf. Ziel war es, <strong>die</strong> IT-Entwicklung<br />
enger an den Vorgaben<br />
des <strong>Business</strong> auszurichten. Angelehnt<br />
an bekannte Vorbilder<br />
wurden neue Methoden und<br />
<strong>Business</strong>getriebene IT | Requirements Engineering<br />
Der <strong>Business</strong>-Analyst spielt eine zentrale Rolle im businessgetriebenen Requirements<br />
Engineering. Er begleitet den gesamten Prozess.<br />
IT-Entwicklungen prägen. Der<br />
Übergang zu einer businessgetriebenen<br />
IT bedeutet einen<br />
einschneidenden Wandel für<br />
<strong>die</strong>se Unternehmen. Betroffen<br />
ist vor allem <strong>das</strong> Requirements<br />
Engineering. Hier müssen Prozesse<br />
aufgebaut werden, <strong>die</strong><br />
zum einen sicherstellen, <strong>das</strong>s<br />
<strong>das</strong> <strong>Business</strong> intern genügend<br />
klärt, was effektiv gewünscht<br />
wird, und zum andern eine<br />
saubere Übergabe an <strong>die</strong> IT ermöglichen.<br />
Der <strong>Business</strong>-Analyst spielt<br />
eine zentrale Rolle im businessgetriebenen<br />
Requirements<br />
Engineering. Er begleitet den<br />
gesamten Prozess. Zu seinen<br />
Aufgaben gehörten <strong>die</strong> Iden-<br />
Prozesse für <strong>das</strong> Requirements<br />
Engineering definiert. Als zentrale<br />
neue Rolle wurde der<br />
<strong>Business</strong>-Analyst eingeführt.<br />
Die Rolle ist klar auf der geschäftlichen<br />
Seite verankert.<br />
Er ist zuständig für <strong>die</strong> Klärung<br />
der Wünsche des <strong>Business</strong> und<br />
noch nicht für <strong>die</strong> Frage, wie<br />
<strong>die</strong>se Wünsche umgesetzt werden<br />
sollen. Intern wird <strong>die</strong> Rolle<br />
deswegen auch als <strong>Business</strong><br />
Engineer bezeichnet.<br />
Für den Neuaufbau des Requirements<br />
Engineerings zog <strong>das</strong><br />
Unternehmen zwei sehr erfahrene<br />
<strong>Business</strong>-Analysten hinzu.<br />
Sie setzten den Prozess entsprechend<br />
der Vorgaben der Firma<br />
um. Dabei klärten sie eine<br />
3
Requirements Engineering | <strong>Business</strong>getriebene IT<br />
4<br />
Abb. 1: Kontinuierlicher<br />
Verbesserungszyklus<br />
Um <strong>die</strong> inhaltliche Qualität der <strong>Business</strong> Use Cases zu verbessern, verwendet ein Grossunternehmen<br />
Detailprozesse und Szenarien. Der Detailprozess beschreibt einen konkreten Prozess,<br />
angelehnt an den Geschäftsprozess.<br />
Customer Decision Board<br />
Adapt &<br />
Confirm<br />
Reihe offener Detailfragen.<br />
So wurden mehrere Artefakte<br />
ergänzt oder gänzlich neu geschaffen.<br />
Diese zusätzlichen<br />
Dokumente orientierten sich<br />
an der Best Practice im Requirements<br />
Engineering. Sie wurden<br />
aber nicht einfach eingeführt.<br />
Die Verantwortlichen<br />
für <strong>das</strong> <strong>Business</strong> Engineering<br />
und <strong>die</strong> in den Projekten involvierten<br />
<strong>Business</strong>-Analysten<br />
hatten einen Prozess geschaffen,<br />
der garantierte, <strong>das</strong>s <strong>die</strong><br />
Entscheidungen gemeinsam<br />
getroffen wurden. Dieser Prozess<br />
wurde im Sinne einer kontinuierlichen<br />
Verbesserung immer<br />
wieder durchlaufen (siehe<br />
Abb. 1).<br />
Durch <strong>die</strong> gründliche Vorarbeit<br />
wurde der Prozess nicht nur im<br />
Detail definiert, sondern auch<br />
im Alltag der Organisation verankert.<br />
Im Lauf der weiteren<br />
Aufbauarbeit konnten deswegen<br />
fortlaufend Nachwuchskräfte<br />
<strong>die</strong> Rolle von <strong>Business</strong>-<br />
Analysten übernehmen. Doch<br />
nicht nur in <strong>die</strong>ser Hinsicht<br />
war der Start ein Erfolg. In<br />
der Organisation hat der Neuaufbau<br />
des Requirements Engineerings<br />
mittlerweile Vor-<br />
Continuous<br />
Improvement<br />
ERNI <strong>Business</strong> Analyst<br />
Improve<br />
Neue Artefakte, Verbesserung<br />
der existierenden<br />
Artefakte<br />
bildcharakter. Ein wichtiger<br />
Faktor bei <strong>die</strong>sem Erfolg war<br />
<strong>die</strong> Verankerung einer iterativen<br />
inhaltlichen Prüfung der<br />
Wünsche des <strong>Business</strong>. Damit<br />
konnte sicher gestellt werden,<br />
<strong>das</strong>s <strong>die</strong> <strong>Business</strong> Use Cases,<br />
<strong>die</strong> am Ende resultierten, nicht<br />
nur formal korrekt waren, sondern<br />
auch mit der Geschäftsstrategie<br />
übereinstimmten und<br />
gleichzeitig konkret genug waren,<br />
um daraus Anforderungen<br />
ableiten zu können.<br />
Beispiel 2<br />
Szenarien als Kommunikationsunterstützung<br />
Um <strong>die</strong> inhaltliche Qualität<br />
der <strong>Business</strong> Use Cases zu verbessern,<br />
verwendet ein Grossunternehmen<br />
Detailprozesse<br />
und Szenarien. Der Detailprozess<br />
beschreibt einen konkreten<br />
Prozess, angelehnt an<br />
den Geschäftsprozess. So wird<br />
zum Beispiel der Geschäftsprozess<br />
Warenverkauf durch den<br />
Detailprozess Shop-Verkauf<br />
konkretisiert. Die Szenarien<br />
sind konkrete Beispiele, welche<br />
mit Hilfe des Detailprozesses<br />
durchgespielt werden.<br />
Das Szenario hat immer eine<br />
Persona (Peter Muster, Angestell-<br />
ERNI <strong>Business</strong> Analyst<br />
Analyze<br />
Methoden, Artefakte,<br />
Prozesse und Req. Engineering<br />
Vorlagen<br />
ERNI <strong>Business</strong> Analyst<br />
Use<br />
Methoden, Artefakte,<br />
Prozesse und Req. Engineering<br />
Vorlagen<br />
ERNI Company<br />
Get Know-how<br />
Pattern Req. Startup<br />
Pattern Req. Management<br />
Pattern Req. Development-<br />
Pattern Coverage Analysis<br />
ter, bestellt ...) und beschreibt<br />
mögliche Abläufe, egal, ob reibungslos<br />
oder mit Störungen.<br />
<strong>Business</strong> Use Cases werden in<br />
mehreren Iterationen anhand<br />
der Szenarien und Detailprozesse<br />
überprüft.<br />
Insbesondere <strong>die</strong> Szenarien<br />
sind eine wertvolle Basis, um<br />
zusammen mit den Stakeholdern<br />
zu überprüfen, ob <strong>die</strong><br />
Anforderungen richtig verstanden<br />
worden sind. Damit<br />
ist sichergestellt, <strong>das</strong>s <strong>die</strong> Anforderungen<br />
wirklich in <strong>die</strong><br />
Geschäftsprozesse und somit<br />
in <strong>die</strong> Strategie des Unternehmens<br />
passen. Gleichzeitig können<br />
<strong>die</strong> Szenarien während des<br />
Projektverlaufs weiterverwendet<br />
werden, zum Beispiel als<br />
Testfälle.<br />
Der entscheidende Vorteil jedoch<br />
liegt darin, <strong>das</strong>s der <strong>Business</strong>-Analyst<br />
präziser weiss,<br />
was <strong>die</strong> Stakeholder im <strong>Business</strong><br />
wünschen. Dadurch werden<br />
teure Fehlentwicklungen<br />
vermieden. Dies ist letztlich<br />
auch der Grund, warum dem<br />
Requirements Engineering<br />
überhaupt viel Aufmerksamkeit<br />
geschenkt werden sollte.
Glossar<br />
Use-Case-Dokument<br />
fkt. Anforderungen<br />
n. fkt. Anforderungen<br />
Können Missverständnisse beim<br />
Erfassen und Formulieren der<br />
Anforderungen vermieden werden,<br />
spart man Kosten und<br />
beschleunigt <strong>die</strong> Entwicklung.<br />
Wegen der grossen Bedeutung<br />
und der Komplexität des Requirements<br />
Engineerings werden<br />
grössere Unternehmen um<br />
den Einsatz eines Tools nicht<br />
herumkommen. Während des<br />
ohnehin aufwändigen Wandels<br />
hin zu einer businessgetriebenen<br />
IT-Entwicklung haben<br />
<strong>die</strong> Evaluation und <strong>die</strong> Einführung<br />
eines solchen Tools allerdings<br />
nicht oberste Priorität.<br />
Stattdessen sollten zunächst<br />
einfache, pragmatische Mittel<br />
verwendet werden, auf denen<br />
<strong>das</strong> Tool später aufgesetzt werden<br />
kann.<br />
Beispiel 3<br />
Requirements Management<br />
ohne Tooleinsatz<br />
Für <strong>die</strong> Übergangszeit vor der<br />
Einführung eines neuen Requirements<br />
Management Tools<br />
V0.1 V1.0 V1.1 V2.0 V2.1<br />
V0.1 V1.0 V2.0<br />
V1.0 V1.1 V1.2 V2.0<br />
V1.0 V2.0<br />
Release 1 Release 2<br />
Version<br />
konzentrierte sich ein Unternehmen<br />
bei der Anforderungsverwaltung<br />
zunächst auf <strong>die</strong><br />
wichtigen Punkte in der Administration,<br />
insbesondere auf<br />
<strong>die</strong> Sicherstellung der Nachverfolgbarkeit.<br />
Diese wurde mit<br />
einfachen Mitteln unterstützt.<br />
Zum einen wurde für alle Projekte<br />
eine Verzeichnisstruktur<br />
gemäss dem VOLERE-Gliederungsschema<br />
von S. Robertson<br />
& J. Robertson definiert. Darauf<br />
aufbauend erhielt jedes Release<br />
ein Deckblatt, <strong>das</strong> <strong>die</strong> Baseline<br />
eines Requirements Management<br />
Tools simuliert (siehe Abb.<br />
2). Schon mit <strong>die</strong>ser simplen<br />
Methode wird <strong>die</strong> Übersicht für<br />
alle Beteiligten erhöht.<br />
Fazit<br />
Der Wandel von einer technikgetriebenen<br />
zu einer businessgetriebenen<br />
IT ist heute ein<br />
Gebot der Stunde. Dazu muss<br />
allerdings <strong>das</strong> Requirements Engineering<br />
völlig neu konzipiert<br />
werden, da gerade mit <strong>die</strong>ser<br />
Release<br />
Disziplin <strong>die</strong> Schnittstelle zwischen<br />
<strong>Business</strong> und IT gemanagt<br />
wird. Dem Requirements<br />
Engineering müsste dementsprechend<br />
viel Aufmerksamkeit<br />
gewidmet werden. Bei der<br />
Neukonzeption sollte darauf<br />
geachtet werden, <strong>das</strong>s nicht<br />
nur der Prozess formal festgelegt<br />
wird, sondern auch eine<br />
inhaltliche Prüfung der Ergebnisse<br />
garantiert ist. Im besten<br />
Fall wird zudem <strong>die</strong> Anpassung<br />
von gängigen Methoden an <strong>die</strong><br />
Organisation nach Best Practice<br />
gestaltet. Dafür sind erfahrene<br />
<strong>Business</strong>-Analysten zumindest<br />
zu Beginn der Neukonzeption<br />
unumgänglich.<br />
Artikel online:<br />
www.<strong>erni</strong>.ch/experience<br />
<strong>Business</strong>getriebene IT | Requirements Engineering<br />
Abb. 2: Baseline<br />
auf Dokumentenebene<br />
Der Wandel von einer technikgetriebenen<br />
zu einer businessgetriebenen<br />
IT ist heute<br />
ein Gebot der Stunde. Dazu<br />
muss allerdings <strong>das</strong> Requirements<br />
Engineering völlig neu<br />
konzipiert werden, da gerade<br />
mit <strong>die</strong>ser Disziplin <strong>die</strong><br />
Schnittstelle zwischen <strong>Business</strong><br />
und IT gemanagt wird.<br />
Haggai Bass<br />
Kontakt: haggai.bass@<strong>erni</strong>.ch<br />
Senior Consultant in der Firma ERNI Consulting AG.<br />
Die Schwerpunkte seiner Beratertätigkeit liegen<br />
in den Bereichen Requirements Engineering<br />
und Process Improvement.<br />
5
ERNI Consulting AG<br />
Talstrasse 82 · CH-8001 Zürich · Tel. +41 44 215 42 00<br />
Bahnhofstrasse 4 · CH-6340 Baar · Tel. +41 41 227 35 00<br />
Casinoplatz 2 · CH-3011 Bern · Tel. +41 31 381 76 11<br />
ERNI (Deutschland) GmbH<br />
Ganghoferstrasse 31 · D-80339 München · Tel. +49 89 90 40 5907<br />
ERNI (Slovakia) s.r.o.<br />
Sturova 4 · SK-811 02 Bratislava · Tel. +421 2 32 55 37 37<br />
www.<strong>erni</strong>.ch · info@<strong>erni</strong>.ch<br />
www.<strong>erni</strong>.ch/experience