Mit dem BPMN-Kollaborationsdiagramm zu verlässlichen Aufwandschätzungen für IT-Projekte: In diesem dritten Beitrag der Serie „Vorsicht bei Festpreisangeboten“ (Teil 1, Teil 2) erkläre ich, wie IT-Dienstleister und Auftraggeber eine gemeinsame Basis für die angebotene Lösung finden. In einem BPMN Kollaborationsdiagramm stellen Sie eindeutig dar, wer welche Aufgaben im Ablauf erledigt und wann er dazu mit welchem System kommuniziert. Die automatischen Arbeitsschritte der Systeme werden dabei in gleicher Weise modelliert wie Arbeitsschritte von Personen. („Computer sind ja auch bloß Menschen.“) Eine kurze Einführung, was BPMN ist, habe ich in diesem Blog bereits gegeben. Siehe hier.
Je Applikation ein Pool
Um eine Anforderungsbeschreibung mit einem BPMN-Diagramm zu erstellen gehen Sie wie folgt vor:
Schritt 1: Erstellen Sie je beteiligter Organisationseinheit und je verwendeter Applikation einen Pool. Lassen Sie sich die Abfolge der Arbeitsschritte aus den verschiedenen Perspektiven der Bearbeiter erläutern und modellieren Sie die Schritte im jeweiligen Pool. Achten Sie im ersten Durchgang darauf, dass Sie nicht zu fein granulieren. Jede Übergabe von Informationen an oder von anderen Organisationseinheiten und jede Eingabe in ein System bzw. die Ausgabe, modellieren Sie als Nachrichtenfluss zu den jeweiligen Pools dieser Einheiten. Die Pools der Applikationen bleiben zunächst leer. So stellt das Diagramm dar, wer wann was tut und wann wer Interaktionen mit welchen Applikationen benötigt.
Interaktionen als Nachrichtenfluss
Wenn der Prozess auch Interaktionen mit Kunden enthält (zum Beispiel über ein Web-Frontend), dann modellieren Sie auch den Kunden als Pool. Hier wissen Sie nicht, was der Kunde wann tut, aber Sie kennen die Nachrichtenflüsse mit Ihren internen Bearbeitern und Systeme.
Task-Typen im technischen Pool
Mit diesem System von Ein- und Ausgaben zwischen Applikationen und Bearbeitern können Sie danach die Pools der Applikationen ausmodellieren. Dabei verwenden Sie unterschiedliche Task-Typen der BPMN:
Wenn die Applikation mit einem Benutzer kommuniziert, verwenden Sie eine Aktivität vom Typ User-Task. Das bedeutet, dass die Applikation an dieser Stelle einen Benutzerdialog bereitstellen muss. Sie haben im ersten Schritt bereits einen Nachrichtenfluss von und zur dazu entsprechenden Aufgabe im Benutzerpool modelliert. Ziehen Sie diese Nachrichtenflüsse jetzt direkt auf den User-Task im Applikationspool.
Kommunikationen zu anderen Applikationen
Soll die Applikation Daten über eine Schnittstelle an andere Applikationen oder externe Einheiten senden (Mail), verwenden Sie dafür eine Aufgabe vom Typ Send-Task und verbinden Sie diese Task mit dem Pool der korrespondierenden Einheit per Nachrichtenfluss.
Muss Ihre Applikation einen Web-Service in einer anderen Applikation starten, modellieren Sie dafür eine Aufgabe vom Typ Service-Task. Soll die Applikation selbst Daten transformieren oder Berechnungen anstellen, verwenden Sie den Aufgabentyp Script-Task. Wenn die Aufgaben im Applikationspool ausmodelliert sind, ist jeder Nachrichtenfluss von oder zu diesem Pool direkt mit einer Aufgabe im Pool verbunden.
Haben Sie diese Spezifikation für alle beteiligten Applikationen modelliert, bietet Ihr Diagramm einen vollständigen Überblick über die zu erwartenden Leistungen der Applikation: Für Benutzer-Tasks ist ein Benutzerdialog zu programmieren, für Send-Tasks eine Schnittstellenspezifikation für eine Datenausgabe, für Service-Tasks der Aufruf eines Web-Services und für Script-Tasks eine entsprechende Klasse zu programmieren. Der IT-Dienstleister kann anhand dieses Modells sehr gut den Umfang seiner Entwicklungsarbeit schätzen.
Organisatorische Veränderung wird greifbar
Ein weiterer Vorteil dieser Darstellung: Sie können verschiedene Lösungsoptionen für einen Prozess darstellen und vergleichen. Anforderungsanalysen nutzen gerne die Priorisierung von „must have“ und „nice-to-have“ Funktionen. Mit verschiedenen Szenarien in BPMN-Diagrammen können Sie klar aufzeigen, welche organisatorische Konsequenz das Weglassen einer „nice-to-have“ Funktion nach sich zieht. Wenn gleichzeitig der IT-Dienstleister die verschiedenen Szenarien mit Aufwänden bewertet, verschieben sich oft die Prioritäten zwischen den gewünschten Funktionen.
Dieses BPMN-Diagramm ist die Struktur für das Fachkonzept Ihrer IT-Lösung. Beschreiben Sie die einzelnen Tasks des Applikationspools dazu detaillierter mit Beschreibungen oder UML-Klassendiagrammen. Je detaillierter Sie Ihre Lösung im Vorhinein beschreiben, desto genauer die Aufwandsschätzung und desto verlässlicher die Realisierung.
Aufwandschätzung mit klaren Erwartungen
Aber auch ohne die weitere Differenzierung der Aktivitäten haben Sie die Sicherheit, dass die angeforderte Funktionalität einer Lösung tatsächlich die benötigte Wirkung in der Organisation herbeiführen wird und dass Ihr IT-Dienstleister wirklich die Lösung anbietet, die Sie benötigen. Anhand dieser Darstellung kann der Entwicklungsumfang einer Lösung gut geschätzt werden – das heißt aber noch nicht, dass damit der Aufwand in Euro und Personentagen abgelesen werden kann
Der Umfang einer Lösung schlägt sich nämlich nicht unmittelbar im Aufwand nieder. Der Aufwand hängt von zahlreichen weiteren Faktoren ab, über die ich in der nächsten Folge der Serie berichten werde. Als Auftraggeber haben Sie aber mit dieser Detaillierung genug geliefert, um eine zuverlässige Aussage des Lieferanten zu ermöglichen. In der nächsten Folge lesen Sie, wie Sie nachvollziehen können, dass der Anbieter auch die weiteren Faktoren auf dem Schirm hat, wenn er Ihnen sein Angebot unterbreitet.