die bank 04 // 2015

ó BERUF & KARRIERE

ó BERUF & KARRIERE Mittler zwischen Kerngeschäft und IT BUSINESS-ANALYSTEN Gemeinsame Projekte von IT und Kernressorts geraten oft zum Kraftakt. Nicht selten führen mangelnde oder mangelhafte Kommunikation zu ihrem Scheitern. Häufiger noch geraten sie in Verzug, sprengen das Budget, oder ihr Nutzen bleibt hinter der Erwartung zurück. Ursache ist meist beiderseitiges Unverständnis: Den operativen Abteilungen fehlt oft der Sinn für IT-Prozesse, den Informatikern der tiefe Einblick ins Kerngeschäft. Als Wandler zwischen den Welten kann der Business-Analyst hier Nutzen stiften. Rüdiger Lang | Jan Zinser | Joachim Schü Keywords: Projektmanagement, interne Kooperation, Teamarbeit Wer schon einmal an der Abbildung unternehmerischer Anforderungen in einem IT-System mitgewirkt hat, kennt die Fallstricke solcher Projekte: unklare Vorgaben, Missverständnisse, zu optimistische Aufwandsschätzung, enger Zeitplan, inadäquate Umsetzung, Verzug durch verspätete Lieferung. Oft fehlen den Projektbeteiligten auf Business- und IT-Seite nicht nur das Verständnis für die Welt des Gegenübers, sondern auch die Zeit oder die Hilfsmittel, sich dieses Wissen anzueignen. Die Verständnisprobleme vervielfachen sich mit dem Umfang des Projekts beziehungsweise der Zahl parallel laufender Vorhaben. ” 1 zeigt, welche Konflikte in welcher Projektphase typisch sind. Der Business-Analyst sitzt organisatorisch an der Schnittstelle zwischen Informatik und Kerngeschäft. Er kennt die Arbeitsabläufe der operativen Sparten, versteht aber auch einiges von den Prozessen und Sachzwängen der Softwareentwicklung sowie des Systembetriebs. fl Oft fehlen den Projektbeteiligten auf Business- und IT-Seite nicht nur das Verständnis für die Welt des Gegenüber, sondern auch die Zeit oder Hilfsmittel sich dieses Wissen anzueignen. Auftrag Mit Methodenkompetenz und Kommunikationsstärke sorgt der Business-Analyst für eine effektive, partnerschaftliche Zusammenarbeit zwischen IT und Kernressorts. So sichert er die Entwicklung des richtigen Produkts mit hohem Nutzen für den Kunden. Je nach Projektphase nimmt der Analytiker andere Aufgaben wahr. Als Sachverständiger berät er während der Projektinitiierung den betreffenden Geschäftsbereich und achtet darauf, dass Projektidee, Grob- und Feinkonzept strukturiert und IT-nah beschrieben werden. In späteren Projektphasen fördert er als Übersetzer die Kommunikation zwischen Business und IT. Zudem schafft er als Berichterstatter Transparenz, koordiniert und strukturiert Anforderungen der Kernressorts. Die Projektarbeit steuert er nach den Kriterien Nachvollziehbarkeit, Vorschriftsmäßigkeit und Wirtschaftlichkeit. Bei der Abnahme der Ergebnisse wirkt er als Mediator. ” 2 listet die Aufgaben des Business-Analysten in jeder Projektphase auf. Der betriebswirtschaftliche Nutzen des Business-Analysten umfasst im Wesentlichen vier Punkte: ó Maximierung der Akzeptanz des Projektergebnisses durch den Kunden respektive die User – und somit des gewünschten Nutzens. ó Minimierung der Projektkosten durch frühzeitige Beseitigung von Hindernissen und Missverständnissen zwischen Kerngeschäft und IT. ó Vermeidung von Änderungsanträgen und der damit verbundenen Kosten durch Herausgabe einer hinreichend ausführlichen Spezifikation und Dokumentation des Produkts. ó Kontrolle der Projektrisiken wie Verzug, Budgetüberschreitung oder Qualitätsmängel. In einer Langzeitstudie hat das US-amerikanische IT-Analystenhaus Standish Group unzureichende Spezifikation, lückenhafte Planung, mangelnde Einbindung der Nutzer, Änderungen der Anforderungen während des Projekts, überzogene Erwartungen sowie eine fehlende Unterstützung durch die Firmenspitze als Hauptgründe des Scheiterns von Projek- 72 diebank 4.2015

BERUF & KARRIERE ó ten ermittelt. Der Business-Analyst behält diese kritischen Punkte im Blick und verhindert durch rechtzeitiges Gegensteuern, dass sie den Projekterfolg gefährden. ” 3 zeigt anhand einer exemplarischen Kalkulation, wie der Business-Analyst die Risiken abfängt, die sich aus den in der Studie erhobenen Gründen ergeben. Das Projektbudget ist hier mit 1 Mio. € veranschlagt. Demnach liegt der Wert der Risikominimierung bei etwa 47.000 €. Mit einem Projekt dieser Größenordnung ist der Analytiker allerdings nicht ganzjährig ausgelastet. Deshalb arbeitet er meist an mehreren Projekten parallel. Betreut er drei Vorhaben ähnlichen Umfangs, steigt der Wert der Risikominderung auf 140.000 €. Stellt man diesem Betrag das Jahresgehalt eines Business-Analysten mit drei bis vier Berufsjahren von rund 60.000 € gegenüber, zeigt sich der Nutzen der Investition. Den Erfolg des Analytikers kann das Unternehmen u. a. an diversen Kennzahlen messen, beispielsweise der Anzahl der Änderungsanträge der Kernressorts wegen übersehener Lösungsaspekte, der Anzahl der Änderungsanträge seitens der IT wegen ungenauer Konzeption, am Konzeptionsaufwand beider Seiten relativ zum Gesamtaufwand des Projekts sowie einem subjektiven und objektiven Erfolg des Produkts beim Kunden. In größeren Unternehmen, die mehrere Business-Analysten beschäftigen, ergibt sich ein weiterer Vorteil: Durch die Kommunikation untereinander verhindern sie, dass ähnliche oder übergreifende Softwarefunktionen mehrfach entwickelt werden. Einführung der Analystenrolle Wo noch kein Business-Analyst tätig ist, nehmen dessen Aufgaben andere Mitarbeiter wahr. Oft schreibt der Projektleiter die Spezifikation, zuweilen auch ein Entwickler in Absprache mit dem jeweiligen Kernressort. Ist dies in kleineren Projekten meist noch problemlos zu stemmen, so müssen die Mitwirkenden mit wachsender Größe und Differenzierung des Vorhabens zunehmend ihre eigentliche Rolle spielen. Der Projektleiter etwa hat dann kaum mehr die Zeit, das Vorhaben in allen Einzelheiten zu spezifizieren. Die Rolle des Business-Analysten lässt sich in fünf Schritten im Unternehmen vergleichsweise leicht verankern ” 4. Bei der Bestandsaufnahme analysiert das Projektteam in Interviews und Workshops das bisherige Vorgehen bei kleinen, mittleren und Großprojekten, ermittelt die dabei eingesetzten Rollen sowie deren theoretische und tatsächlich erledigte Aufgaben. Anhand der Analyse, der Ziele und Randbedingungen entwirft das Team die Blaupause des Einsatzes des Business-Analysten. In Form einer Matrix verortet es die Rolle im Projektablauf und grenzt deren Aufgaben von anderen Rollen ab. Im dritten Schritt prüfen die internen Stakeholder das Rollenkonzept. Das Projektteam plant die Pilotierung der Rolle, wählt dazu Projekte, Personen und den Starttermin aus. Besetzt 1 Hitzelandkarte zwischen Fachbereichen und IT Projektphase Fachbereich: Verantwortliche und Aufgaben Qualität Kosten Termine IT: Verantwortliche und Aufgaben 1. Initiierung 2. Planung 3. Ausführung Abteilungsleiter, Mitarbeiter: Einsteuern von Geschäftsideen und groben Anforderungen Projektleiter, Mitarbeiter: Konkretisierung Projektidee, Bewertung von Kosten & Nutzen, Planung, Teamauswahl Projektleiter, Mitarbeiter: Klärung offener Fragen, ggf. Aktualisierung Planung Fehlende Klarheit für Schätzung von IT-Aufwand und Dauer geringe Transparenz der IT-Umsetzung gegenüber dem Fachbereich geringe Beschreibung fachlicher Anforderungen, fehlende Kommunikation Unzufriedenheit über Häufigkeit von Ände rungen, unzureichende Rückmeldung bei Fragen IT-Leiter, Entwickler: frühes Feedback und Machbarkeitsabschätzung IT-Projektleiter: Interpretation der Anforderungen und Aufwandsabschätzung IT-Projektleiter, Entwickler: Erstellung Lastenheft, Auswahl des Teams und IT-Planung, Realisierung 4. Überwachung Projektleiter: Controlling des Projektfortschritts, Bündelung und Bewertung von Änderungsanfragen Bewertung & Prüfung von Zwischenergebnissen erfolgt nicht aktuell Unzufriedenheit über Änderung der Planung und der Anforderungen IT-Projektleiter: Kommunikation des Projektfortschritts, Bewertung Änderungsanfragen 5. Abnahme/Abschluss Projektleiter, Mitarbeiter: Abnahme der Ergebnisse und Entlastung der IT, Übergabe an den fachlichen Betrieb Endprodukt entspricht nicht ursprünglichen Zielvorstellungen Unzufriedenheit über verzögerte Abnahme, Last-Minute-Änderungen Projektleiter, Entwickler: finale Tests, Übergabe in technischen Betrieb 4.2015 diebank 73