- -
- 100%
- +
Alle diese Entwicklungen führen dazu, dass die begrenzten Ressourcen bestmöglich genutzt werden – auch dabei kann der Business-Analyst einen wertvollen Beitrag leisten, weil er die Instrumente kennt, mit denen komplexe Problemstellungen effizient bearbeitet werden können.
Ein Stillstand eines Unternehmens ist in vielen Fällen ein Rückschritt, wenn das Umfeld sich weiterentwickelt. Daraus leitet sich ein weiterer Aspekt für die Existenzberechtigung der Business-Analyse ab.
Steigende und sich schnell wandelnde Erwartungen der Kunden
Steigende Erwartungen der Kunden sind wahrscheinlich die größte Herausforderung für Unternehmen. Mehr denn je müssen Erwartungen und Anforderungen externer Kunden an Produkte und Dienstleistungen erfüllt werden, wenn ein Unternehmen im Markt bestehen will. Durch die Spezialisierung in verschiedenen Disziplinen (siehe oben) haben meistens nur noch vergleichsweise wenige Mitarbeiterinnen und Mitarbeiter einen direkten Kontakt zum Kunden und kennen so aus erster Hand die Erwartungen. Aber nicht nur die Anforderungen der externen „richtigen“ Kunden müssen umgesetzt werden. Auch Abteilungen, die nicht direkt mit externen Kunden zu tun haben, tragen zur Wertschöpfung bei und haben Anforderungen, die erfüllt werden müssen.
Interne und externe Kunden haben steigende und sich wandelnde Erwartungen an Produkte und Dienstleistungen. Bei internen Kunden sind dies in der Regel (Zwischen-)Ergebnisse anderer Abteilungen, die als Input für die eigene Arbeit dienen. Letztlich dienen auch die „internen Kunden“ fast alle dem Markt, das heißt dem externen Kunden. Bei internen wie bei externen Kunden arbeiten Business-Analysten als Brückenbauer und Dolmetscher, um eine effektive und effiziente Zusammenarbeit zu gewährleisten. Sie helfen, dass aus Schnittstellen zwischen Abteilungen Nahtstellen werden.
Im Zentrum des unternehmerischen Handelns sollte jedoch der externe Kunde stehen und die Anforderungen im Unternehmen sollten sich an seinen Erwartungen ausrichten.
Die oben genannten Gründe für den Einsatz von Business-Analysten lassen sich nicht immer klar voneinander trennen. In Summe verdeutlichen sie aber, dass Business-Analysten in Unternehmen sehr wertvolle und nützliche Funktionen erfüllen können. Analog zu der Spezialisierung in verschiedenen Disziplinen erscheint es sinnvoll, dass sich Personen auf das Ermitteln, Dokumentieren und Analysieren von Anforderungen und auf die neutrale Unterstützung bei der Entwicklung von Lösungen spezialisieren sollten. Immer mehr Unternehmen erkennen diesen Nutzen, den Business-Analyse ihnen bringen kann.
In der Vergangenheit wurden die Aufgaben rund um Anforderungen von anderen Rollen ausgeführt, z.B. von
Organisatoren, die Änderungen an Aufbau- und Prozessorganisation in Unternehmen begleiten
IT-Koordinatoren, die als Bindeglied zwischen Fachabteilung und IT-Abteilung fungieren
Projektleitern, die sich neben anderen Aufgaben im Projekt um Anforderungen kümmern.
Auch Personen mit anderen Rollenbezeichnungen als „Business-Analyst“ übernehmen solche Aufgaben. Gebräuchliche Bezeichnungen sind zum Beispiel Requirements Engineer, Anforderungsmanager, Business Consultant sowie die schon erwähnten Organisatoren, IT-Koordinatoren und Projektleiter. Im Folgenden wird die Bezeichnung Business-Analyst genutzt, die verwandte Rollen mit einschließt.
Die folgende Abbildung G.02 fasst weitere Gründe für den Einsatz von Business-Analysten zusammen und nennt gebräuchliche Gegenargumente, auf die im Weiteren eingegangen wird.
Pro Business-Analyse Contra Business-Analyse Fester und zentraler Ansprechpartner für Anforderungen Zusätzlicher Aufwand (Zeit, Kosten, Ressourcen) Qualitätssicherung der Anforderungen Hohe Veränderungsrate der Anforderungen Strukturiertes Vorgehensmodell Externer Blick – keine Kenntnisse aus erster Hand Kenntnisse aktueller Methoden Keine operative Erfahrung Hohes Maß an Erfahrung durch Spezialisierung auf Anforderungen Weitere Rolle und zusätzliche Schnittstelle Neutrale Beratung des Fachbereichs Weder Fachbereich noch IT zugehörig „Blick über den Tellerrand“ eines Fachbereichs hinaus Mangelnde Akzeptanz in der IT und im Fachbereich Zeit- und Kostenersparnis durch qualitativ gute Anforderungen Zusätzliche Bürokratie (hoher Administrationsaufwand und Dokumentationsaufwand) Objektivität gegenüber allen Anforderungen Bevormundung des Fachbereichs Frühzeitiges Erkennen von Zusammenhängen Stille-Post-Effekt Kosten-Nutzen-Analyse der Anforderungen vor deren Umsetzung Zeitliche Freistellung für Business-Analyse-Aufgaben Entlastung von IT und Fachbereich Abgleich der Anforderungen mit Zielen und dadurch zielführende LösungenAbb. G.02: Pro- und Contra-Argumente zu Business-Analyse
Gegenargumente und ihre Entkräftung
Zusätzlicher Aufwand
Der Aufbau von Stellen bzw. Rollen für Business-Analysten verursacht (Personal-)Kosten und verbraucht Ressourcen. Allerdings wird dieser Aufwand durch professionelle Business-Analyse wieder „eingespielt“. Die Spezialisierung auf die Aufgabenfelder rund um Anforderungen macht deren Management effektiver und effizienter.
Hohe Veränderungsrate der Anforderungen
Das kann auch als Pro-Argument aufgefasst werden, denn Business-Analysten unterstützen in der Begrenzung von Anforderungen, falls Änderungen nicht sinnvoll sind, und sie begleiten die Aktualisierung von Anforderungen, falls eine Änderung einen Mehrwert bietet.
Keine Kenntnisse aus erster Hand
Business-Analysten haben tatsächlich oft weder das detaillierte Fachwissen noch die Erfahrungen wie der anfordernde Fachbereich. Diese Neutralität schützt allerdings vor „Betriebsblindheit“ und erlaubt eine andere Perspektive auf die Anforderungen. Gemäß dem Motto „Vier Augen sehen mehr als zwei“ forciert dieser neutrale Blick, die Anforderungen zielgerichtet, umfassend und in einer sinnvollen Detaillierung zu erfassen.
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ätsanforderungenAbb. 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“.