Antwort.

Bei Integrationsprojekten muss der Business Analyst als Bindeglied zwischen technischen und nicht technischen Stakeholdern fungieren. Die Hauptaufgabe ist es, das gegenseitige Verständnis der Parteien zu gewährleisten, damit Anforderungen, Risiken und Einschränkungen von allen Beteiligten verstanden werden und die Dokumentation die erforderlichen Details für die Integration enthält.

Schlüsselmerkmale:

• Moderation von Meetings: Der Analyst strukturiert die Kommunikationsprozesse, hilft den Teilnehmern, in einer für alle verständlichen Sprache zu sprechen, und erklärt technische Details den Geschäftsleuten sowie geschäftliche Anforderungen den Entwicklern.

• Dokumentation der Schnittstellenanforderungen: Es ist wichtig, nicht nur die Anforderungen zu beschreiben, sondern auch Vereinbarungen zu Datenformaten, Übertragungskanälen, Fehlerbehandlung und Versionsverwaltung der Integrationen zu klären.

• Abstimmung der Ziele und Einschränkungen des Projekts: Der Analyst identifiziert versteckte Risiken und hilft, im Voraus Vereinbarungen über Erfolgskennzahlen und Kontrollpunkte zu treffen.

Fangfragen.

Kann die Erstellung der API vollständig an technische Spezialisten delegiert werden?

Nein. Der Analyst muss sicherstellen, dass die Geschäftsanforderungen korrekt in der Schnittstellendokumentation reflektiert sind und dass die realen Geschäftsszenarien durch die technische Lösung unterstützt werden.

Reicht es aus, nur die Formate der eingehenden/ausgehenden Daten abzustimmen?

Nein. Es ist äußerst wichtig, die Geschäftsregeln, die Handhabung von Ausnahmefällen (z. B. was zu tun ist, wenn die Integration nicht verfügbar ist), Zugänglichkeitsbeschränkungen und Zugriffsrechte zu klären.

Ist die Teilnahme des Business Analysts bei der Diskussion von architektonischen Entscheidungen zwingend erforderlich?

Ja, auch wenn er keine technische Entscheidung trifft, muss der Analyst sicherstellen, dass die geschäftlichen Aspekte und Einschränkungen bei der Architekturplanung berücksichtigt werden.

Typische Fehler und Anti-Patterns

• Der Business Analyst nimmt nicht an technischen Meetings teil, was zu einer Asynchronität der Anforderungen und der umgesetzten Lösungen führt.
• Die Dokumentation wird „eins zu eins“ vom Geschäft ins Technische übersetzt: Der Kontext, die Spezifik der Integration und wichtige Szenarien der Fehlerbehandlung gehen verloren.

Beispiel aus dem Leben

Negativer Fall: Bei der Integration von CRM und einem externen Dienst nahm der Analyst nicht an der Vorbereitung der technischen Spezifikationen teil. Vorteile: Das technische Team entwickelte die API schneller. Nachteile: Die Integration unterstützte die erforderlichen Geschäftsregeln nicht, es kam zu Datenverlusten.

Positiver Fall: In einem ähnlichen Projekt nahm der Analyst an allen Phasen der Diskussion teil und involvierte die Geschäfts- und das technische Team. Vorteile: Die Integration deckte alle realen Szenarien ab, die Tests waren erfolgreich. Nachteile: In der Phase der Anforderungspräsentation wurde mehr Zeit benötigt.