In meiner Funktion als Leiter Informatik und Projektleiter ERP Migration, setze ich häufig BPMN Modelle als Kommunikationshilfe ein. Bei der Erhebung von Geschäftsprozessen im Rahmen von Requirements Engineering habe ich damit sehr gute Erfahrungen gemacht.
Verbindung zweier Welten
Ich bin häufig an IT-Projekten beteiligt, in denen es um Softwaremigrationen, Neubeschaffungen oder Funktionsanpassungen geht. Die grundsätzliche Schwierigkeit in solchen Projekten ist immer die Kommunikation zwischen dem Business und externen IT-Dienstleistern.
Die Auftraggeber-Firma weiss genau wie das Business laufen muss. Die IT-Dienstleister wiederum wissen, was ihre Systeme leisten können. Aufgrund der unterschiedlichen Hintergründe ist die Verständigung aber eine grosse Herausforderung.
Der Requirements Engineer steht dabei immer zwischen diesen Welten. Eine der wichtigsten Aufgaben besteht nun darin, diese Welten zu Verbinden und ein gemeinsames Verständnis der Anforderungen für beide Seiten herzustellen.
Gescheitertes Requirements Engineering
Leider war ich auch schon an Projekten beteiligt, in denen das Requirements Engineering vernachlässigt wurde. Solche Projekte laufen, meiner Erfahrung nach, in vier groben Phasen ab.
- Die Auftraggeber-Firma liefert ein Sammelsurium aus veralteten Prozessbeschreibungen, Visio Flussdiagrammen mit ca. drei Aktivitäten, eine Liste mit unsortierten Wunschvorstellungen und ein Kostendach.
- Der IT-Dienstleister behauptet; „alles kein Problem“. Die Kosten werden jedoch nach Aufwand berechnet.
- Desaster.
- Das gebaute System entspricht zu 50% den Vorstellungen, kostet aber doppelt so viel wie budgetiert.
Erhebung der Anforderungen mit dem Wissen aus dem CAS
Im CAS Requirements Engineering haben wir viele verschiedene Erhebungstechniken kennengelernt. Bei Anpassungen am ERP-System sind immer auch Geschäftsprozesse betroffen. Von allen möglichen Methoden habe ich für die Erhebung der Geschäftsprozesse, Interviews und Beobachtung am häufigsten eingesetzt. Meine bisherige Erfahrung ist, dass die meisten Prozessbeteiligten ihre Aufgaben grob im Kontext des gesamten Ablaufs einordnen können. Jedoch fehlt meistens das Bewusstsein für den gesamten Kontext.
Stark überzeichnet können die Aussagen meist so dargestellt werden:
Vorteile von BPMN Modellen bei der Erhebung der Anforderungen
Nach den Interviews und den Beobachtungen können die Aussagen aller Prozessbeteiligten zusätzlich in einem BPMN Modell dargestellt werden. Mit dieser Technik lassen sich lückenhafte Aussagen aus den Interviews bereits beim Modellieren erkennen und können bei Bedarf nochmal erfragt werden.
Die Besprechung der Modelle ist ein wichtiger Teil. Dabei sehen die Prozessbeteiligten ihre Aufgabe meist zum ersten Mal im Gesamtkontext. Nach einer kurzen Einführung in die Notation erkennen sie Redundanzen, nicht mehr weiterverarbeitete Informationen, Sackgassen, Umwege usw. meist schon selbstständig.
Pflücken der „low-hanging fruits“
Die Besprechung des gesamten Prozessablaufs steigert automatisch das gegenseitige Verständnis unter den Beteiligten. Als Requirements Engineer kann man sich somit früh als Mittler/in positionieren und steigert damit die eigene Akzeptanz. Mit dieser Vorgehensweise ist es auch möglich, in einer frühen Projektphase, Empfehlungen für organisatorische Prozessoptimierungen abzugeben. Die BPMN Modelle können zusätzlich zur Verbesserung der Prozessdokumentation genutzt werden.
Letztendlich können, zusätzlich zu all diesen Vorteilen, widerspruchsfreie und von allen Beteiligten akzeptierte Anforderungen daraus abgeleitet werden.
