BUSINESS ANALYSE FÜR KANBAN FLUSSAUFWÄRTS

AUSGANGSSITUATION

Manchmal frage ich mich wirklich, wie wir Menschen es geschafft haben, von den Bäumen herunter zu kommen. Entschuldigen Sie den harten Einstieg. Das Thema, worüber ich hier schreibe, ist leider ein stets wiederkehrendes Thema, welches selbst in hoch entwickelten Organisationen immer wieder auftritt.

Dabei handelt es sich um ungenügend vorbereitete Anforderungen. Darunter leiden sehr viele Entwickler immer wieder. Letztendlich auch das Unternehmen. Damit das klar ist – mir ist durchaus die Herausforderung der Interaktion bewusst. Gemeinsame Sprache suggeriert nur Verständnis hat mal Gregory Bateson gemeint. Das trifft es gut.

Über diesen Umstand hinaus scheint es mir aber viel mehr ein stetiger unglaublicher Drang zu sein, Entwickler:innen in dem Glauben vollzustopfen, nur wenn entwickelt wird, geht auch etwas weiter. Man solle vorab nicht so lange herum trödeln, sondern lieber etwas arbeiten.

Zu Tode analysieren in dem anderen Glauben, sich dadurch die Welt gefügig zu machen und alle Stolpersteine aus dem Weg geräumt zu haben, ist der gegenpolige Auswuchs an Verschwendung.

Deswegen ist es an der Zeit, sich unterstützendes Vorgehen mal genauer anzusehen.

KLÄRUNGEN

Wofür ist die Rolle des ´Business Analysten´ nach gängier Lehrmeinung überhaupt einsetzbar:

Die Aufgabe des Business Analysten besteht darin, den gesamten Geschäfts- und Informationsbedarf eines Unternehmens zu untersuchen, um Lösungen für Geschäftsprobleme zu finden. Dies kann Folgendes beinhalten:

• Unterstützung bei der strategischen Analyse, Modellierung strategischer Themen und Antriebskräfte
• Modellierung von Geschäftsfähigkeiten - Modellierung dessen, was das Unternehmen tut (konzeptionelle Aktivitätsmodelle), im Gegensatz zu dem, wie es das tut (physische Prozessmodelle)
• Abbildung von Prozessen und Wertströmen (Wertketten)
  
• Abbildung von Fertigkeiten und Kompetenzen
• Neudefinition/Re-Engineering von Prozessen
• Datendefinition und Identifizierung von Ereignissen
• Verbindung zwischen verschiedenen geschäftlichen und technischen Disziplinen
• Entwicklung von Anforderungen
• Entdeckung und Definition kosteneffizienter, wertvoller Lösungen für Geschäftsanforderungen

Die Business Analyse erstreckt sich von der obersten Ebene des Unternehmens, die sich mit der Vision, der Mission, den Zielen und der Strategie befasst, bis hin zur taktischen Ebene, auf der die Arbeit zur Umsetzung der Strategie erstellt wird und auf der häufig Projekte zur Lösungsentwicklung angesiedelt sind.

Obiges liest sich einleuchtend. Die Rolle wird nur oftmals anders genannt und die Übergabe der Informationen sollte über die Ebenen hinweg erfolgen. Ob die Ebenen nun tatsächlich Projekte, Programme und Unternehmen genannt werden, ist irrelevant. Wichtig ist, die Business Analyse im grossen Format zu sehen sowie dessen Wertigkeit auf allen Betrachtungsebenen zu erkennen.

ANALYSEMETHODEN

ÜBERSICHT & SCHWERPUNKTE 

MÖGLICHST ALLES BERÜCKSICHTIGEN & RISIKEN
 

2) Sämtliche W-Fragen, Schmerzen und Bedarfe können sehr gut in einem RICH PICTURE ausgedruckt werden. Da insbesondere Techniker damit grosse Berührungsschwierigkeiten haben, ist es ideal geeignet, (unbewusst) versteckte Informationen an den Tag zu bringen.

BIG PICTURE 

3) Grosse Wirkung erzielen POPT-Analysen (vielfach auch unter anderen Namen bekannt) zu Beginn an. Wir wollen ja v.a. Abhängigkeiten identifizieren. POPT ist ein Akronym und steht für:

• Personen: Fähigkeiten, Motivatoren, Erfahrung, Ausbildung und Entwicklung, Verständnis der Unternehmensziele, Kultur und Führungsstile
• Organisation: Struktur (einschliesslich der Möglichkeiten und Beschränkungen, die sich aus der Art der Organisation ergeben), Aufgaben und Zuständigkeiten, Ausmass der funktionsübergreifenden Arbeitsstrukturen, Managementstil und -ansatz, Einhaltung von Vorschriften und rechtlichen Beschränkungen
• Prozess: Leistung (erreicht durch ausreichend gut definierte, gut verstandene und gut unterstützte Prozesse)
• Technologie: Infrastruktur (zur Unterstützung und Verbesserung von Geschäftsprozessen in der gesamten Organisation)

Brechen Sie jeden Bereich grafisch herunter und bilden den aktuellen sowie Wunsch-Status visuell ab. Sie werden viel Verständigung ernten. Insbesondere wenn dieses Ergebnis sichtbar für die Dauer der Umsetzung bleibt.

Ein Beispiel anhand dem Bereich „Organisation":

Wenn Sie erst NACH Klärung dieser Parameter Entwicklungen starten, ist schon sehr viel Sinnvolles passiert. Da soll es kein Entgegenkommen seitens der Entwickler:innen geben. Gleich für wen. Ansonsten ist eine bittere Suppe während der Umsetzung hoch wahrscheinlich.

Diese Methode ist auch gut kombinierbar mit modernen Canvas-Ansätzen und kann je nach Erfordernis strukturiert werden.

PLAUSIBILITÄT & OPTIONEN

SCHNITTSTELLEN & BESTANDTEILE

5) Das Context-Scoping-Diagramm ist ebenso ein Instrument der Visualisierung, welches auf mehreren Ebenen Sinn macht. 

BERÜHRUNGSPUNKTE

6) Die Berühungspunkte der Benutzer während der Anwendung eines Produkts bzw. der Weg von Benutzern während eines typischen Arbeitszyklus kann wunderbar mit dem a) Customer-Journey-Mapping dargestellt werden. 

TYPISCHE BENUTZERPROFILE

In Verbindung dazu dient der Einsatz spezifischer Kundengruppen durch die Methode b) Personas. 

FOKUS & DETAILS 

7) TOWS kann sowohl für strategische als auch detaillierte Ausrichtungen genutzt werden. TOWS ist eine Vertiefung und Aufbau zur bekannten SWOT-Analyse.

ANSATZPUNKTE 

8) Alleine schon die W-Fragen in den Zuständen As Is – To Be entlang der Entwickl-ung zu stellen, ist oftmals eine grossartige Unterstützung für das Finden der passenden Gestaltung.

9) Weiters sind gängige Prozessmodelle, UML-Diagramme und Wireframes nach wie vor hilfreich. Für diese verzichten wir auf eine grafische Abbildung.

10) Abschliessend darf noch erwähnt werden, wie die Frage des Zuschneidens – Solution Focus – der Entwicklungsvorgänge sehr wesentlich frür frühen Nutzen, Lernen und Lieferung innerhalb der vorhergesagten Bandbreite ist.

Agiles Denken sorgt für querfunktionale Einsatzbereiche pro Inkrement oder Release.

ZUSAMMENSETZUNG DER LIEFERUNGEN 

 

ZUORDNUNG

Die obigen Ausführungen sind in der nachstehenden Tabelle zusammengeführt und mit Beschreibungen um die oftmals sinnvollste Anwendung ergänzt.

FAZIT 

Vorbereitung in ausreichendem Masse hilft zu erkennen, was auf einen in einer tieferen Ebene zukommt. Das kann von Abhängigkeiten bis zu Scheiterfallen reichen oder zumindest einer angebrachten Qualität dienen. Sanftes Herangehen an die Tiefe ist sinnvoll durch vorhergehendes Abstecken der Breite. Diese kann sich verändern, was jedoch auch bei agilen Vorgehensweisen immer wieder Änderungen in der Tiefe sowie entsprechende Berücksichtigung von Abhängigkeiten nach sich zieht.

Niemals sollten Entwickler:innen für Analysen abgezogen werden. Viel mehr sollte es übergreifend über die Services auf allen Ebenen ausreichend Analysten geben, welche qua Fähigkeiten zu den jeweiligen Aufgaben herangezogen werden.

Ebenso niemals ist es das Ziel zu analysieren um des Analysierens wegen. Immer gerade soweit sinnvoll – im Minimum auf Sicht für einen nächsten Entwicklungszyklus, damit die Umsetzungsarbeit flutschen kann.

Anregungen in sehr konkrekter Form sind umfangreich vorhanden. Die Ausführungen sind so konkret als möglich – eine einzige Konfiguration für alle Zwecke existiert nicht. Daher bitte ich, für konkrete Zuordnungen samt Erzeugung bzw. Erweiterung Ihrer bestehenden Struktur, auf mich oder andere Experten zuzukommen.

Dieter Strasser, MSc, CMC, Geschäftsführer:
▪ This email address is being protected from spambots. You need JavaScript enabled to view it.

Trainer, Coach, Facilitator bei Viable Projects GmbH:
▪ www.viableprojects.eu