Heuer findet das BA Camp zum insgesamt vierten Mal statt. Die Veranstaltung steht unter dem Motto: Ihr habt die Macht: Von der Idee zur Umsetzung. Was das für mich bedeutet, erzähle ich in diesem Beitrag. Wie letztes Jahr haben wir auch heuer zur Blogparade aufgerufen und die folgende Frage gestellt:

Wieso werden manche Ideen von Unternehmen sofort aufgenommen und andere verschwinden sang- und klanglos in der Schublade? Und das, obwohl Ihr mit allen Stakeholdern gesprochen, Workshops erfolgreich moderiert, tragfähige Konzepte erarbeitet habt und das Ergebnis sich sehen lassen kann?

Also, hier ist mein Beitrag:

Natürlich möchten wir Projekte möglichst erfolgreich umsetzen. Als Business-Analysten ist unser Ziel, Unternehmen erfolgreicher zu machen. Und das geht nur, wenn sich das Unternehmen stetig verändert und auf neue Herausforderungen reagiert. Veränderung passiert in den meisten Unternehmen im Rahmen von Projekten. Diese werden erst konzipiert und danach umgesetzt.

Die Praxis zeigt aber, dass viele Konzepte in der Schublade verschwinden und nie umgesetzt werden. Und genau das adressiert  die Frage der diesjährigen Blogparade.

Ich stelle jedoch eine Gegenfrage: Sind denn Konzepte, die in der Schublade verschwinden, wirklich so schlecht?

Dazu möchte ich gerne eine Geschichte aus meiner eigenen Erfahrung als Business-Analyst in großen und kleineren Unternehmen erzählen. Es war vor einigen Jahren, relativ am Anfang eines neuen Projekts, bei dem ich die Business-Analyse für ein neues CRM-System übernommen hatte. Ein Kollege warnte mich damals vor dem Projekt und meinte, ich sollte aufpassen, dass mein Konzept nicht „in der Schublade“ verschwindet. Es wäre nämlich nicht der erste Versuch dieser Firma ein neues CRM-System zu etablieren. Was ich damals noch nicht ahnte war, dass es auch nicht der letzte Versuch bleiben sollte.

Für mich hatte diese Warnung etwas Eindrückliches, denn für mich ist dabei die folgende Warnung in Erinnerung geblieben:

„Du hast als Business-Analyst versagt, wenn dein Konzept nicht umgesetzt wird.“

Soweit ich mich erinnere, hat der Kollege diesen Satz so nie gesagt. Ich habe ihn selbst so interpretiert und abgespeichert. Und das hat dazu geführt, dass ich eine wichtige Erfahrung gemacht habe…

Aber was ist eigentlich das Ziel der Business-Analyse?

In meinen Trainings beschreibe ich Business-Analyse als eine Art Berater-Rolle, bei der es darum geht, den Zustand von Unternehmen zu untersuchen, um Verbesserungsmöglichkeiten vorzuschlagen, diese auszuarbeiten und umzusetzen.

Als Business-Analysten arbeiten wir im Grund an drei unterschiedlichen Dingen:

1. Wir untersuchen Unternehmen, beispielsweise ihre Strategie, ihren organisatorischen Aufbau, die internen Abläufe und die dabei genutzten IT-Systeme, um zu verstehen, was sich ändern muss.
2. Wir schlagen Möglichkeiten vor, wie das Unternehmen verbessert werden kann, um erfolgreicher zu sein, beispielsweise schneller, billiger oder besser.
3. Wir arbeiten die Empfehlung genau aus, weil der Schritt von einer allgemeinen Empfehlung bis zur tatsächlichen Umsetzung ziemlich umfangreich sein kann.

Zurück zu meinem Projekt.

In meinem erwähnten CRM-Projekt bin ich genau nach diesen drei Schritten vorgegangen:

Der erste Schritt war relativ aufwändig: Die Auftraggeber waren der Meinung, ich sollte doch gleich Anforderungen erheben, anstatt die Strategie des Unternehmens zu hinterfragen oder  viel Zeit mit einer Ist-Analyse zu verschwenden. Ich blieb aber standhaft und habe dadurch wichtige Einblicke in das Unternehmen erhalten. So konnte ich beispielsweise erkennen, welche Wünsche den Mitarbeitern tatsächlich wichtig waren und welche nicht.

Der zweite Schritt war weniger aufwändig, aber bei meiner Empfehlung hatte ich bereits ein ungutes Gefühl. Ich habe die Optionen, die ich für das Unternehmen erarbeitet habe, mit ihren Kosten und Nutzen beschrieben, aber es blieb alles ein wenig vage und unkonkret. Der Vorschlag wurde jedoch vom Steuerungsgremium genehmigt, also ging es weiter zu Schritt Nr. 3.

Der dritte Schritt viel mir als geübter Requirements-Engineer sehr leicht: Zurück zu den Stakeholdern, Anforderungen im Detail erheben, Design-Vorschläge mit anderen Experten erarbeiten, diese den Nutzern präsentieren, Lücken schließen und so weiter, und so fort, bis alle mit dem Ergebnis zufrieden waren…

Die Realisierung der spezifizierten Anforderungen in neuen IT-Systemen und Geschäftsprozessen war nicht mehr mein Aufgabengebiet. Aber genau hier zeigten sich die ersten Probleme. Hier sind ein paar Beispiele: Ein Vertriebsmitarbeiter meinte, dass das neue System viel zu umständlich sei. Ein anderer wiederum fand, dass eine bestimmte Funktionalität unbedingt notwendig sei, aber gar nicht berücksichtigt worden ist. Und ein Mitarbeiter des IT-Supports beklagte Probleme beim Datenimport über eine neue Schnittstelle. Die meisten dieser Rückmeldungen konnten wir aufgreifen und entsprechend verbessern. In weiterer Folge wurde das neue IT-System eingeführt und die Geschäftsprozesse entsprechend angepasst.

Alles in Butter? Leider nicht.

Nach nur 6 Monaten wurde die Software wieder außer Dienst gestellt und die Mitarbeiter arbeiteten wieder nach den ursprünglichen Geschäftsprozessen. (Um ehrlich zu sein: Dafür war nicht viel Rückgewöhnung notwendig, denn die neuen Prozesse wurden nie vollständig genutzt.) Die Entscheidung für diesen Rollback wurde von demselben Gremium beschlossen, das ca. 1 Jahr davor die Umsetzung beauftragt hatte.

Was waren, nachträglich betrachtet, die drei wichtigsten Gründe dafür?

1. Obwohl viele kleinere und größere Probleme im Rahmen der Realisierung behoben wurden, sind doch immer wieder neue aufgetreten, die die Zufriedenheit mit der Lösung laufend reduziert hat. Aber diese Problem hätten wir vermutlich in den Griffe bekommen können. Ein größeres Problem war dabei das folgende:
2. Der Business Case basierte einerseits auf Einsparungspotentiale durch eine effizientere Arbeitsweise, andererseits aber auch auf Umsatzsteigerungen. Beides konnte jedoch weder sinnvoll gemessen werden, noch waren die zugrundeliegenden Daten realistisch. Und das führt uns gleich zum dritten, wirklich ausschlaggebenden Problem:
3. Es gab keine einheitliche Sichtweise, was das Ziel des gesamten Projekts sein sollte. Aus dem Business Case hätte man herauslesen können, dass das Ziel mehr Effizienz und mehr Umsatz gewesen sein könnte. Aber weil die Zielerreichung in Bezug auf das Projekt nur schwer messbar war und es an anderen übergeordneten Zielen gefehlt hatte, wurde die neue Arbeitsweise nachträglich wieder rückgängig gemacht.

Welche Schlüsse können wir aus dieser Geschichte ziehen?

Um diese Frage zu beantworten, möchte ich die drei unterschiedlichen Dinge, an denen wir als Business-Analysten arbeiten, noch einmal wiederholen:

1. Unternehmen untersuchen
2. Verbesserungsmöglichkeiten vorschlagen
3. Empfehlungen ausarbeiten

Um den Fehlschlag dieses Beispiels zu zeigen, reicht es jedoch nicht, diese drei Dinge zu analysieren. Eigentlich müssen wir (wortwörtlich) zwischen den Zeilen lesen:

Zwischen Punkt 1 (Unternehmen untersuchen) und 2 (Verbesserungsmöglichkeiten vorschlagen) müssen wir als Business-Analysten sicherstellen, dass der erhobene Ist-Zustand vom Management auch so gesehen wird. Und noch wichtiger: Dass die Ziele des Projekts mit dem Ist-Zustand und den Erwartungen des Managements übereinstimmen. Eigentlich hätte es da schon lauten müssen: Ab in die Schublade, mit dem Konzept!

Und zwischen Punkte 2 (Verbesserungsmöglichkeiten vorschlagen) und 3 (Empfehlungen ausarbeiten) müssen wir als Business-Analysten dafür sorgen, dass sich der Business-Case auf die tatsächlichen Ziele bezieht und diese auch wirklich messbar sind, oder wir müssen zumindest so ehrlich sein und sagen, welche Ziele verfolgenswert, aber trotzdem nicht messbar sind. Auch hier hätte es spätestens lauten müssen: Ab in die Schublade, mit dem Konzept.

Fehler, die hier bereits passiert sind, lassen sich bei der detaillierten Ausarbeitung mit noch so guten Techniken des Requirements Engineerings nicht mehr korrigieren. Wenn es kein gemeinsame Ziel gibt, hilft es nichts, wenn der Weg zum Ziel perfekt asphaltiert ist.

Es ist kein Problem, wenn dein Konzept nicht umgesetzt wird. Es ist viel mehr ein Problem, wenn ein Konzept umgesetzt wird uns sich der erhoffte Nutzen nicht einstellt.

Somit komme ich zu meiner anfangs gestellten Gegenfrage zurück:

Sind denn Konzepte, die in der Schublade verschwinden, wirklich so schlecht?

Nein, denn manchmal ist es gut zuzugeben, dass man sich geirrt hat. Und in diesem Fall sollten Konzepte in der Schublade verschwinden und andere Ideen umgesetzt werden, die des eher verdienen.

Damit das gelingt, müssen wir als Business-Analysten aber auch unserer Einschätzung vertrauen und deutlich aussprechen, wenn wir von einer Idee nichts halten. Wir haben nicht nur die Macht, Ideen bis zur Umsetzung zu bringen, sondern auch, genau das zu verhindern.

Mehr Artikel zur Blogparade des BA-Camp 2017 findet ihr auf ba-camp.org.