Mit jeder Softwareentwicklung werden fachliches Wissen und Geschäftsprozesse in Sourcecode niedergeschrieben. In den Fachabteilungen jedoch wird mit fachlichem Wissen und der Methodenkompetenz für die Business Analyse teilweise sorglos umgegangen. Es wird zugelassen, dass dieses Wissen in die IT-Abteilungen abwandert und dann auch dort verbleibt.
Besonders in großen Konzernen, deren ursprüngliches Kerngeschäft nicht die IT ist, wird Software häufig nicht als in Sourcecode gegossene Kernkompetenz gesehen und fachliche Betreuung von Softwareentwicklung nicht als kritischer Beitrag zum Projekt- und Unternehmenserfolg geschätzt.
Requirements Engineers als Schnittstelle zwischen Fachabteilung und IT
Für gute Software muss das Wissen der Fachabteilungen in den Entwicklungsprozess einfließen. Dieser Wissenstransfer funktioniert teilweise so gut, dass die Kollegen in den IT-Abteilungen mehr über die Fachlichkeit wissen als die Fachabteilungen selbst.
Als Bindeglied zwischen den Fach- und IT-Abteilungen fungiert das Requirements Engineering (RE). Requirements Engineers analysieren IST-Prozesse – organisatorische und technische. Sie unterstützen mit ihren Methoden- und im besten Fall mit Fachkenntnissen bei der Konzeption von Software.
Bei der Softwareentwicklung sind auch die abteilungsübergreifenden Gesamtzusammenhänge zu berücksichtigen. Hierfür tragen die Requirements Engineers Informationen zusammen, stimmen die fachlichen Schnittstellen zwischen den Abteilungen ab und sammeln so das für die Softwareentwicklung nötige Wissen an, welches die Basis für die fachliche Dokumentation darstellt.
In der Umsetzungsphase übernehmen sie die fachliche Führung von Entwicklungsteams und klären die Details mit dem Kunden. Ihre Tätigkeiten sind unter anderem:
- Moderation und Facilitation von Gruppen
- Dokumentation von Prozessen und Geschäftsregeln
- Fachliches Wissen und Abläufe den IT-Kollegen verständlich machen
- Den Fachabteilungen die Möglichkeiten der IT vermitteln
- Inhaltliche Steuerung von IT-Projekten
Das Wissen aus den Fachabteilungen wandert in die IT
Die Fachabteilungen freuen sich über die Tätigkeiten der Requirements Engineering-Kollegen aus den IT-Abteilungen. Ihnen werden die nicht-fachlichen Tätigkeiten, in denen sie normalerweise wenig Routine haben, abgenommen. Sie übersehen aber folgende Konsequenzen:
- Das fachliche Wissen über die Zusammenhänge des Gesamtprozesses wandert in die IT-Abteilung und wird dort dokumentiert.
- Die Verantwortung für das Fachwissen wandert automatisch auch in die IT-Abteilungen.
- Der Zugriff auf das Wissen ist nicht mehr so leicht möglich.
- Verlust bzw. der fehlende Aufbau von RE-Methodenkompetenz stärkt die Entwicklung von Punkt 1-3.
Das Fachwissen liegt dann in Kollaborations-Tools, Wikis, ALMs in der IT-Abteilung oder im Sourcecode mit eingeschränktem Zugriff für die Fachabteilungen. Der Zugriff zu diesen Tools wird meist mit Rechtekonzepten durch IT-Abteilungen eingeschränkt. Auf den Sourcecode haben noch weniger Leute Zugriff oder sie können ihn weder lesen noch verstehen. Zudem verstehen die Kollegen aus der Fachabteilung oft nicht die „Sprache“ der IT oder der Business Analysten. Es gibt eine Hürde, Dokumente der Requirements Engineers zu lesen. Komponentendiagramme, Use-Case-Diagramme, BPMN-Prozesse mit unterschiedlichen, bedarfsgerechten Sichten, Testfälle und all die anderen nützlichen Helferlein in der Softwareentwicklung werden nicht verstanden, können nicht eingeordnet und genutzt werden.
Mit der Aufgabe der Verantwortung für Fachwissen und unzureichender RE-Methodenkompetenz auf der einen und dem Aufbau von Wissen auf der anderen Seite, wird es für die Fachabteilungen immer schwerer, sich in die Themen/Dokumente der IT-Projekte einzuarbeiten und ihren Teil zum Projekterfolg und somit Geschäftserfolg beizutragen. Die IT-Abteilungen werden im Gegensatz dazu Projekte immer eigenständiger bearbeiten und die Fachabteilungen nur noch in Ausnahmefällen oder FYI mit Informationen versorgen. Im schlimmsten Fall umgehen sie die Fachabteilungen für die Softwareentwicklung komplett.
Zum einen, weil das fachliche Wissen ja schon bei der IT, bzw. den Requirements Engineers liegt und zum anderen, weil die Fachabteilungen nicht mehr als kompetenter Partner auf Augenhöhe angesehen werden. Allerdings wird leicht übersehen, wie viel Detailwissen für eine gute Software nötig ist. Dazu gehört auch Wissen über aktuelle Entwicklungen bei den Kunden, Detailwissen über Prozesse und deren Einfluss auf die User Experience (UX), etc.
Da Softwareentwicklung keine One-Man-Show einzelner Personen oder Teams ist, sondern von der guten Zusammenarbeit verschiedener Kompetenzen lebt, ist die oben beschriebene Situation für die Qualität der Software wahrscheinlich nicht förderlich.
Wie kann eine bessere Kooperation von Fachabteilung und IT aussehen?
Es sollte daher eine Lösung für die Zusammenarbeit gefunden werden. Kunde, Fachabteilung und IT-Abteilung sollten als Partner zusammenarbeiten. Mit mehr Methodenkompetenz für IT-Projekte auf der Fachseite und mehr Offenheit bei der Nutzung/ beim Zugriff auf die fachliche Dokumentation auf Seiten der IT-Abteilungen. Mögliche Lösungen können vielfältig und individuell sein.
Vielleicht hilft es schon, den Zugang zu den Tools der IT-Abteilungen für Fachabteilungen zu öffnen, wenn die Fachabteilungen die Bereitschaft zeigen, sich auf die Art und Weise der fachlichen IT-Dokumentation einzulassen.
Man könnte auch den Mitarbeitern der Fachabteilungen das nötige Wissen vermitteln, sodass sie ein besseres Verständnis für die Softwareentwicklung bekommen. Das wiederum ist wahrscheinlich nicht mit einer „How to read Use Cases in 2h“ Veranstaltung oder mit einem IREB-Kurs gleich für alle gelöst. Es geht um das Gefühl für die Nutzung der richtigen Methode, zum richtigen Zeitpunkt sowie ein Verständnis dafür, dass Softwareentwicklung eines kontinuierlichen Austauschs bedarf. Der Entwicklungsprozess ist nie gradlinig, deshalb sind zusätzliche Schleifen, Feedbackrunden und konzeptionelle Korrekturen Teil des Prozesses. Auch das erfordert Übung und praktische Anwendung.
Als drittes kann man überlegen, ob die Requirements Engineers näher an den Fachabteilungen angesiedelt werden sollten. Dadurch würde das Wissen und die Verantwortung für die Fachlichkeit vielleicht bei den Fachabteilungen bleiben und die IT-Abteilungen hätten einen Ansprechpartner auf der Fachseite.
Transparenz und Offenheit für die Informationen und kontinuierliche Zusammenarbeit bleiben allerdings in jedem Fall Voraussetzungen für ein gutes Gelingen von IT-Projekten.
Happy Engineering
René
Mehr zu René Busch finden Sie auf http://www.requireminds.de/. 