Kitabı oku: «Business-Analyse», sayfa 2
Keine operative Erfahrung
Auch hier hilft ein „unverstellter Blick“, Anforderungen zu ermitteln und zu dokumentieren. Anforderer, die beispielsweise lange für Geschäftsprozesse zuständig sind, neigen dazu, viele Sachverhalte als selbstverständlich vorauszusetzen. Dies kann leicht zu Lücken oder Missverständnissen bei der Ermittlung und Dokumentation von Anforderungen führen. Ein „unvoreingenommener“ Business-Analyst kann hier korrigierend wirken.
Zusätzliche Schnittstelle
Durch eine Bündelung der Aufgaben, die rund um Anforderungen anfallen, können beim Einsatz von Business-Analysten Schnittstellen sogar verringert werden. Mit einem zentralen Ansprechpartner für Anforderungen haben sowohl der Fachbereich als auch die Systementwickler/Lösungsbauer weniger Schnittstellen als wenn „jeder mit jedem“ spricht.
Weder Fachbereich noch IT zugehörig
Eine neutrale Positionierung von Business-Analysten bringt durchaus Herausforderungen mit sich. Dem stehen jedoch alle die genannten Vorteile gegenüber, die aus einer neutralen Rolle erwachsen.
Mangelnde Akzeptanz
Skepsis und Widerstand sind fast immer zu erwarten, wenn Veränderungen oder Neuerungen eingeführt werden. Aber „gute Arbeit zahlt sich aus“. Wenn Business-Analysten ihren Job gut machen, wächst die Akzeptanz in der IT und im Fachbereich. Dabei hilft ein gesundes Maß an Selbstvermarktung, indem den übrigen Beteiligten die Vorteile bewusst gemacht werden, die die Business-Analyse mit sich bringt.
Zusätzliche Bürokratie
Professionelle Business-Analyse setzt und nutzt Standards, zum Beispiel durch ein strukturiertes Vorgehen oder zur Dokumentation von Anforderungen. Es gilt, das richtige Maß aus Standards und Pragmatismus zu finden und hohen Administrations- und Dokumentationsaufwand zu vermeiden. Eine übertriebene Business-Analyse, die sich in starren Regelungen und dem Ausfüllen von Templates verliert, wird wenig Akzeptanz finden. Es hat sich bewährt, den Prozess und die Standards der Business-Analyse mit ihren „Kunden“ (insbesondere Fachbereich und IT) abzustimmen und weiterzuentwickeln.
Bevormundung des Fachbereichs
Business-Analysten sollten eine neutrale Haltung einnehmen. Die inhaltliche Verantwortung für die Anforderungen tragen die Anforderungssteller, die Verantwortung für die (IT-)Lösung tragen die Entwickler. Business-Analysten sind Berater und Dienstleister auf dem Weg zu qualitativ guten Anforderungen. Sie tragen die Verantwortung, dass dieser Weg strukturiert und systematisch gegangen wird.
Stille-Post-Effekt
Business-Analysten sind kommunikationsstark. Dies gilt sowohl für das Zuhören als auch für das Kommunizieren rund um Anforderungen. Missverständnisse in der menschlichen Kommunikation lassen sich nie ganz ausschließen. Professionelle Business-Analyse hilft dabei, diese Missverständnisse bei den Anforderungen aufzudecken und zu minimieren.
G.1.2 Fallbeispiel TREND Möbelhäuser
Die Konzepte der Business-Analyse werden anhand eines durchgängigen Beispiels veranschaulicht.
Die Möbelhauskette TREND vertreibt in ihren neun Filialen das folgende Sortiment: Möbel für Wohnzimmer, Dielen, Schlafzimmer, Küchen, für Bäder, Kinder- und Jugendzimmer, für Gärten und für Büros; daneben werden Leuchten verkauft, Dekoration, Textilien und Teppiche, Utensilien für Essen und Trinken, Kochen und für Aufbewahrung.
Das inhabergeführte Unternehmen hat sich in den letzten vierzig Jahren einen guten Namen in den jeweiligen Regionen gemacht. Die Filialen punkten mit persönlicher Beratung und kundenfreundlichem Service.
Dennoch machen die Mitbewerber dem Management Sorgen. Gerade schwedische Mitbewerber binden junge und kaufkräftige Kunden an sich. Dies bestätigen die Verkäufer in den TREND-Filialen, wenn sie nach der Altersstruktur ihrer Kunden befragt werden.
Als eine Ursache für diese Entwicklung wird der bisherige Internetauftritt vermutet (das Sortiment in den Filialen soll zu einem späteren Zeitpunkt auf Attraktivität überprüft werden). Auf der gemeinsamen Internetseite werden im Wesentlichen nur die Standorte der Filialen, ihre Öffnungszeiten und allgemeine Kontaktdaten (Telefon, Fax, E-Mail) genannt. Die wichtigsten Markenhersteller der Produkte sind nur namentlich aufgeführt. Interessenten können sich aber keine Produkte auf der Internetseite ansehen, geschweige denn bestellen. Dies verwundert vermutlich junge bzw. internetaffine Kunden und lässt sie zu anderen Möbelhäusern wechseln.
In der Hauptverwaltung arbeiten ca. 100 Personen: neben der Geschäftsführung sind dort die Buchhaltung, das Marketing, die zentrale IT-Abteilung, der zentrale Einkauf, Personalabteilung, Organisationsabteilung und das Gebäudemanagement angesiedelt (vgl. Abb. G.03).
Die neun Filialen sind nahezu gleich aufgestellt: neben den Verkäufern (inzwischen Kundenbetreuer genannt, die wechselnd auch an den Kassen eingesetzt werden), gibt es das lokale Lager, die Filialleitung mit Sekretariat, einen lokalen EDV-Techniker und eine Imbissecke, die den Kunden Getränke und eine kleine Auswahl an kalten und heißen Gerichten anbietet.
Abb. G.03: Organigramm der TREND Möbelhäuser
Bei den TREND Möbelhäusern reichen die Anforderungen vom Wunsch einer „Auswertung der Verkaufszahlen pro Möbelkategorie je Filiale“ als Ergänzung eines bestehenden Berichtswesens, über die Ablösung des bisherigen Warenwirtschaftssystems durch ein neues, bis hin zu konkreten Inhalten und zum Layout des nächsten Werbeflyers.
G.2 Anforderungen und Klassifikationsschema
G.2.1 Übersicht
Unter dem Begriff Anforderung werden in der Praxis unterschiedliche Wünsche, Bedingungen und Bedürfnisse verstanden, die von kleinen Änderungsideen über grobe Projektvorschläge bis hin zu konkret ausgearbeiteten Lösungsvorschlägen reichen. Werden Anforderungen sinnvoll zusammengefasst, um eine gewünschte Veränderung zu charakterisieren, lässt sich daraus eine zielführende Lösung entwickeln.
Eine Lösung ist die Summe der Veränderungen des Ist-Zustands eines Unternehmens, um einen Bedarf zu decken und/oder Ziele zu erreichen.
Schon seit einiger Zeit werden die Stimmen lauter, die einen Internetshop für die TREND Möbelhäuser vorschlagen. Zu dieser möglichen Lösung werden auch entsprechende Anforderungen genannt wie z.B. Möbelkonfigurator, 3D- Ansicht, Lieferung der Möbel nach Hause oder Abholung in der Filiale.
Eine Anforderung ist
(1) eine von einem Stakeholder benötigte, angeforderte oder gewünschte Beschaffenheit oder Fähigkeit einer Lösung,
(2) eine Beschaffenheit oder Fähigkeit einer Lösung, um Vorgaben von Verträgen, Standards, Spezifikationen oder anderen Dokumenten einzuhalten,
(3) eine Dokumentation der vorgenannten Beschaffenheiten oder Fähigkeiten.
(1) In den TREND Möbelhäusern werden viele Anforderungen von Stakeholdern (Anforderungsstellern) benötigt, z.B. von Filialleitern, Geschäftsführung oder Kunden. Während Management und Führungskräfte Anforderungen tatsächlich anfordern, ist dies bei anderen Stakeholdern nicht unbedingt der Fall. Gerade die Möbelkunden äußern selten aktiv ihre Bedürfnisse. Trotzdem gibt es auch bei ihnen benötigte und gewünschte Beschaffenheiten oder Fähigkeiten einer Lösung. Diese sollten umgesetzt werden. Wie viele Unternehmen lebt auch TREND davon, die Kundenbedürfnisse zu kennen und zu erfüllen.
(2) Aus Verordnungen und Gesetzen (z.B. Steuerrecht, Preisangabenverordnung) ergeben sich weitere Anforderungen, die TREND als Unternehmen zu berücksichtigen und zu erfüllen hat. Daneben gibt es z.B. auch Rahmen- und Lieferverträge mit Möbelherstellern, Großhandel und Logistikern.
(3) Immer wieder kommt es vor, dass die Business-Analysten bei TREND Anforderungen aus (1) oder (2) nicht in den Anforderungsdokumenten berücksichtigen. Dies geschieht in der Regel unbeabsichtigt und kann mehrere Gründe haben:
Zeitmangel
Stakeholder „benötigen“ oder „wünschen“ ihre Anforderungen zwar, äußern sie aber nicht tatsächlich und fordern sie damit nicht aktiv an.
Bei der Fülle der eigentlich zu berücksichtigenden Dokumente und Standards werden einzelne Anforderungen nicht ermittelt. Gesetzestexte und Rahmenverträge sind so umfangreich, dass nicht immer sichergestellt werden kann, dass alle Anforderungen ins Anforderungsdokument übernommen werden.
Von Anforderungen zu unterscheiden sind Annahmen und Restriktionen, die häufig zusammen bzw. „gemischt“ mit Anforderungen während der Anforderungsermittlung von Stakeholdern genannt werden. Annahmen und Restriktionen werden in Kapitel G.2.3 skizziert und in Kapitel 2.3 „Anforderungsermittlung“ näher beschrieben.
G.2.2 Klassifikationsschema der Anforderungen
In den meisten Projekten ist eine große Anzahl von Anforderungen zu berücksichtigen. Auch Anforderungen, die nicht in Projekten umgesetzt werden (sondern z.B. in Einzelmaßnahmen oder im Tagesgeschäft), kommen sprichwörtlich „selten allein“. Deswegen sollten Anforderungen gegliedert werden, um eine Übersicht zu bekommen und Gemeinsamkeiten herauszuarbeiten. Hierzu werden unterschiedliche Kategorisierungen genutzt. Die Tabelle zeigt einige gebräuchliche Anforderungsklassen.
| Anforderungen an (Benutzer-) Schnittstellen | Rechtliche Anforderungen |
| Vertragliche Anforderungen | Systemanforderungen |
| Marketing-Anforderungen | Produktanforderungen |
| Komponentenanforderungen | Technische Anforderungen |
| Anforderungen an die Entwicklung | Anforderungen an Mitarbeiter |
| Qualitätsanforderungen |
Abb. G.04: Gebräuchliche Anforderungsklassen
Anforderungen können sehr allgemein sein oder sehr speziell. Sehr detaillierte Anforderungen sollten nicht mit groben Anforderungen verglichen werden – die sogenannte Granularität sollte in etwa vergleichbar sein. Ansonsten besteht die Gefahr, dass „Äpfel mit Birnen verglichen“ werden.
Ein Klassifikationsschema der Anforderungen bietet eine Anforderungsstruktur. Die hier zugrunde gelegte Struktur besteht aus vier Anforderungskategorien.
Das im Folgenden erläuterte Klassifikationsschema für Anforderungen bietet Kategorien, die zum einen eine sinnvolle Gruppierung der Anforderungen auf „ihrem Lebensweg“ ermöglichen und zum anderen die Zusammenhänge zwischen den Anforderungen deutlich machen. Dabei werden insbesondere die Fragen „Warum?“, „Was?“ und „Wie?“ beantwortet.
Warum? Geschäftsanforderungen geben darüber Auskunft, wieso eine Veränderung sinnvoll oder notwendig ist.
Was? Stakeholder-Anforderungen verdeutlichen, welche Merkmale und Beschaffenheiten eine Lösung bieten soll.
Wie? Lösungsanforderungen (unterschieden in funktionale und nicht-funktionale Anforderungen) beschreiben, auf welchem Weg eine Lösung die Geschäftsanforderungen erreichen soll und systematisieren dabei die Stakeholder-Anforderungen.
Transitionsanforderungen bilden insofern eine eigene Kategorie, als sie beschreiben, wie der Übergang vom Ist- zum Soll-Zustand verlaufen soll, nachdem die Lösung zumindest grob beschrieben ist.
Abb. G.05: Klassifikationsschema der Anforderungen
G.2.2.1 Geschäftsanforderungen
Eine Geschäftsanforderung ist eine Aussage zu Zielen und erwünschten Wirkungen. Sie beschreibt die Gründe für eine Veränderung.
In den Geschäftsanforderungen finden sich die „gröbsten“ Aussagen innerhalb der vier Anforderungskategorien. Sie sind damit häufig allgemein gültige Forderungen, die es zu erfüllen gilt und die in vielen Fällen auch mittel- bis langfristig gültig bleiben. Demgegenüber können Anforderungen der anderen Anforderungsklassen in der Regel nach ihrer Umsetzung als erfüllt oder „erledigt“ betrachtet werden.
Geschäftsanforderungen beantworten die Frage „Warum?“: „Warum ist eine Veränderung des Ist-Zustands sinnvoll oder notwendig?“
Inhaber, Filialleiter und Management haben sich in einer ihrer quartalsweisen Führungskräfterunden darauf verständigt, dass für die kommenden Jahre die folgenden Geschäftsanforderungen angestrebt werden sollen:
10 % mehr Umsatz im Vergleich zum abgelaufenen Kalenderjahr
Steigerung des Bekanntheitsgrads in der Region
höhere Kundenzufriedenheit, gemessen an weniger Reklamationen
einheitliches Auftreten gegenüber den Kunden in allen neun Filialen.
Weitere Ausführungen zu Geschäftsanforderungen finden sich in Kapitel 1.3.
G.2.2.2 Stakeholder-Anforderungen
Eine Stakeholder-Anforderung ist der Bedarf, der sich aus der beruflichen Funktion der Stakeholder ergibt.
Letztlich dienen diese Anforderungen dazu, die Geschäftsanforderungen zu erreichen. Stakeholder-Anforderungen können eine Brücke zwischen Geschäfts- und Lösungsanforderungen schlagen.
Stakeholder-Anforderungen konkretisieren die Geschäftsanforderungen, indem sie die Frage beantworten „Was soll geändert oder erreicht werden, um die Geschäftsanforderungen zu erfüllen?“
Auch wenn der Begriff es suggeriert, Stakeholder-Anforderungen stammen nicht zwangsläufig von Personen oder Personengruppen (Anforderungsstellern); sie können auch aus Dokumenten, Standards oder rechtlichen Vorgaben stammen.
Nach der Führungskräfterunde wurden die Business-Analysten bei TREND beauftragt, Vorschläge dafür zu sammeln, wie die Geschäftsanforderungen erreicht werden können. Die Business-Analysten haben bei verschiedenen Stakeholdern (Filialleiter, Kunden, Mitarbeiter, Lieferanten) eine Liste mit Vorschlägen zusammengetragen, u.a.
Marketing-Kampagne für einen größeren Bekanntheitsgrad und zur Steigerung des Umsatzes
bessere Liefer- und Rahmenverträge sowie kulantere Reklamationsbearbeitung zur Steigerung der Kundenzufriedenheit
standardisierte Geschäftsprozesse für einheitliches Auftreten und Arbeiten (hierbei sind u.a. Vorschriften und Standards zum Arbeitsschutz zu beachten).
Weitere Ausführungen zu Stakeholder-Anforderungen finden sich in Kapitel 2.
G.2.2.3 Lösungsanforderungen
Eine Lösungsanforderung ist eine Beschreibung der Aspekte einer Lösung, die Stakeholder-Anforderungen oder Geschäftsanforderungen erfüllt.
Lösungsanforderungen unterteilen sich in funktionale und nicht-funktionale Anforderungen. Funktionale Anforderungen beschreiben, was eine Lösung leisten soll, wie sie sich verhalten oder wie sie reagieren soll, wie sie beschaffen sein soll und welche Leistungsmerkmale sie erfüllen soll.
Nicht-funktionale Anforderungen beschreiben, unter welchen Bedingungen eine Lösung funktionieren soll.
Stakeholder-Anforderungen liegen häufig nicht in einer angemessenen Qualität und in einem geeigneten Detaillierungsgrad (Granularität) vor, so dass sie nicht direkt zur Umsetzung bzw. Entwicklung einer Lösung verwendet werden können (eine Lösung kann dabei IT-Systeme, organisatorische Änderungen oder die Optimierung von Geschäftsprozessen umfassen).
Wünsche, die „menschliche“ Stakeholder äußern, widersprechen sich unter Umständen, weil verschiedene Fachabteilungen unterschiedliche Bedürfnisse haben.
Einige Anforderungen sind schon sehr konkret, ohne den Kontext zu berücksichtigen; andere sind zu allgemein, so dass für eine Umsetzung zu viele Annahmen und Interpretationen benötigt werden.
Nicht-funktionale Anforderungen werden durch Stakeholder häufig nicht genannt, weil sie als selbstverständlich oder „zu technisch“ aufgefasst werden.
Es ist ein wesentliches Aufgabenfeld der Business-Analyse, aus (unzureichenden) Stakeholder-Anforderungen konsistente, klare, zielgerichtete Lösungsanforderungen zu entwickeln, die durch ihre Umsetzung einen (Mehr-)Wert für die Stakeholder erbringen. Dabei sollten funktionale Anforderungen idealerweise technologiefrei sein (das „Was“, nicht das „Wie“ beschreiben). Nichtfunktionale Anforderungen müssen zum Teil Aussagen zu einer Technologie treffen und damit die Lösung einschränken (synonym wird auch von Qualitätsanforderungen oder technischen Anforderungen gesprochen).
Auch in den TREND Möbelhäusern ergeben sich Widersprüche, die gelöst werden müssen: Während die Marketing-Abteilung nur noch auf Online-Werbung setzen möchte, stellen sich die Kollegen der Filialen vor, bestehende Prospekte und Printwerbung zu verbessern. Dabei gibt es schon sehr konkrete Vorschläge: „Das €-Zeichen sollte zur besseren Lesbarkeit hinter und nicht vor dem Preis stehen“.
Aus der IT kommt der Wunsch, das bestehende und in die Jahre gekommene Warenwirtschaftssystem durch ein neues zu ersetzen. Dabei bleibt zunächst völlig unklar, wie das im Detail aussehen könnte und – noch viel wichtiger – ob dieser Wunsch überhaupt zu den Geschäftsanforderungen passt. Auf Nachfrage äußert der IT-Leiter, dass u.a. nicht-funktionale Anforderungen wie „schnelle Antwortzeit“ und „leichte Wartbarkeit“ durch das aktuelle Warenwirtschaftssystem nicht mehr gegeben seien.
Lösungsanforderungen sind typischerweise detaillierter und umfangreicher als Geschäfts- oder Lösungsanforderungen (vgl. Abbildung G.06). Damit beschreiben sie eine Lösung mit mehr Inhalten und konkreter. Je konkreter eine Lösung durch die Lösungsanforderungen beschrieben ist, desto weniger Freiheit bleibt den Umsetzern dieser Lösung.
Business-Analysten sollten allerdings darauf achten, Lösungsanforderungen fachlich zu beschreiben und die konkrete (technische) Umsetzung den (IT-) Experten zu überlassen.
Abb. G.06: Determiniertheit der Lösung und Freiheitsgrad in der Umsetzung der Anforderungen
Determiniertheit im Zusammenhang mit Anforderungen beschreibt, wie stark diese Anforderungen bereits eine Lösung bzw. ihre eigene Umsetzung vorgeben. Anforderungen mit großer Determiniertheit beinhalten bereits Vorgaben, wie sie (technisch) umzusetzen sind. Anforderungen mit schwacher oder keiner Determiniertheit sind lösungs- und umsetzungsneutral beschrieben.
Weitere Ausführungen zu Lösungsanforderungen finden sich in Kapitel 2.
G.2.2.4 Transitionsanforderungen
Eine Transitionsanforderung ist eine Beschreibung der Aspekte einer Lösung, die den Übergang vom Ist-Zustand zum Soll-Zustand ermöglichen.
Transitionsanforderungen sind analog zu Stakeholder- und Lösungsanforderungen zu ermitteln, zu analysieren, zu dokumentieren und zu genehmigen. Das Besondere an Transitionsanforderungen ist, dass sie erst definiert werden können, wenn die Lösung (zumindest grob) beschrieben oder entworfen ist. Transitionsanforderungen sind in der Regel nur für den Übergang vom Ist-Zustand zur (neuen) Lösung gültig und befassen sich damit,
wie Daten migriert werden sollen
welche neue Qualifikation oder welche erweiterten Kompetenzen bei den Mitarbeitern notwendig sind, damit sie die Lösung nutzen können
wie Geschäftsprozesse oder Geschäftsvorgänge fortgeführt werden, die im Ist-Zustand begonnen, aber vor Einführung der Lösung noch nicht abgeschlossen werden.
Sollte ein neues Warenwirtschaftssystem bei TREND eingeführt werden, müssen Transitionsanforderungen an die Überführung der Daten aus dem alten ins neue System definiert werden. Ob die Mitarbeiter ein neues Warenwirtschaftssystem erst nach einer Schulung und einer begleiteten Einführung nutzen können, ergibt sich u.a. aus der Benutzerfreundlichkeit des Systems und aus der optischen und technischen Nähe zum alten Warenwirtschaftssystem. Die Business-Analysten müssten u.a. prüfen, ob eine begonnene Bestellung im neuen System fortgeführt werden kann oder ob sie dort neu angelegt werden muss.
Weitere Ausführungen zu Transitionsanforderungen finden sich in Kapitel 3.2.2.
G.2.3 Annahmen und Restriktionen
Nicht alle Äußerungen seitens der Stakeholder sind tatsächlich Anforderungen.
Eine Annahme ist ein noch nicht überprüfter Einflussfaktor auf eine Lösung, die als Arbeitshypothese in die Untersuchung eingeht.
Die TREND Möbelhäuser vermuten, dass junge Kunden fehlen, da kein Online-Shop vorhanden ist. Daraus ließe sich unmittelbar eine Anforderung nach einer Verkaufsmöglichkeit im Internet ableiten. Sinnvollerweise prüfen Business-Analysten aber zunächst erst einmal diese Annahme und entscheiden dann gemeinsam mit den Stakeholdern, ob sie valide ist und weiterverfolgt werden kann, oder ob sie verworfen werden sollte.
Eine Restriktion ist eine zwingende Vorgabe, die eine Lösung einschränkt oder bestimmte Lösungskomponenten erzwingt.
Restriktionen sind wichtige Informationen. Sie werden häufig nicht in einer Lösung umgesetzt, beeinflussen diese allerdings maßgeblich. Daher sollten sie als Restriktionen kenntlich gemacht werden und nicht mit Anforderungen „vermischt“ werden.
Das Management nannte die zwingende Vorgabe, dass das bestehende Warenwirtschaftssystem nicht abgelöst wird. Zudem soll eine Lösung spätestens in 12 Monaten umgesetzt sein.
Die Unterscheidung zwischen Annahmen und Anforderungen bzw. Restriktionen und Anforderungen ist nicht immer offensichtlich. Business-Analysten fragen besser einmal mehr nach, um herauszufinden, womit sie es gerade zu tun haben.
Weitere Ausführungen zu Annahmen und Restriktionen finden sich in Kapitel 2.3 „Anforderungsermittlung“.
