Sind Lastenhefte noch zeitgemäß?
Agiles Anforderungsmanagement stellt klassische Vorgehensweisen in Business-Software-Auswahlprojekten in Frage
Lesedauer: 5 Minuten
Agile Werkzeuge (insb. User-Stories) können das klassische Projektmanagement und den Lastenheft- und Pflichtenheft-basierten Ansatz ergänzen. Durch ihre Nutzerorientierung fördern sie den Change-Prozess und schaffen eine lösungsneutrale Sicht auf Anforderungen. Somit können Anforderungen verständlich und greifbar für die Stakeholder erfasst, dokumentiert und umgesetzt werden. Das sogenannte hybride Projektmanagement in Softwareauswahlprojekten bietet einen nachhaltigen Umgang mit Stakeholder und Anforderungen.
Im Zuge der Digitalen Transformation hinterfragen Unternehmen ihre bestehende Business Software in der IT-Systemlandschaft und versuchen, diese zukunftsfähig zu gestalten. Dabei ergibt sich häufig der Bedarf, ein bestehendes Anwendungssystem zu erneuern oder eine zusätzliche Lösung in die Landschaft zu integrieren [1]. In beiden Fällen steht das Unternehmen vor der Herausforderung, die passende Software am Markt zu finden und zielgerichtet einzuführen. Diese Projekte sind häufig aufwandsintensive und risikoreiche Unterfangen, da sie Individualcharakter haben, kein bekanntes Alltagsprojekt sind und Entscheidungen unter Unsicherheit verlangen [2].
Um die Risiken sowie die Aufwände besser steuern und überwachen zu können, haben sich diverse Vorgehensmodelle etabliert, welche Unternehmen bei der Softwareauswahl unterstützen. Durch die Strukturierung des Auswahlprojektes in prozessuale, organisatorische und funktionale Bausteine wird die Komplexität handhabbar [1]. Dies wird durch methodische Werkzeuge wie Lasten- und Pflichtenhefte (vgl. „Blue Prints“ bei SAP) unterstützt, welche im Status Quo vom klassischen, sequenziellen Auswahlprozess geprägt sind und daher Defizite in der Verständlichkeit und Praktikabilität aufweisen.
Klassische Lastenhefte sind sehr gut geeignet, Funktionen von Software zu strukturieren und Ausprägungen zu definieren. Daher sind sie eine ideale Grundlage für die Vertragsgestaltung zwischen Anbieter/innen und Anwender/innen. Leider erfordern sie ein hohes Maß an Vorkenntnis der Systemtypen (MES, ERP etc.) und sind aus Nutzer- und Prozessperspektive schwer verständlich. Nachfolgend wird eine Methode vorgestellt, welche Lastenhefte als Element des klassischen Projektmanagements mit dem agilen Werkzeug User-Stories kombiniert.
Aktuelle Herausforderungen in Softwareauswahlprojekten
Das Ziel einer Softwareauswahl ist es, unter Budget- und Kapazitätsrestriktionen die passende Software für die betroffenen Unternehmensprozesse auszuwählen und diese unter minimalem Aufwand erfolgreich in der Organisation zu etablieren. Von klassischem Projektmanagement wird gesprochen, wenn Budget und Inhalt (bzw. Ergebnis) festgesetzt sind, die Projektlaufzeit aber variabel ist. Im Gegensatz dazu sind beim agilen Projektmanagement der Inhalt variabel und Zeit- und Budget festgesetzt.
Eine häufig anzutreffende Rahmenbedingung ist eine ausgesprochene Zeit- und Ressourcenknappheit in Softwareauswahlprojekten. Diese führt dazu, dass die Projekte als Ziel einen First-Time-Right-Charakter haben und daher methodisch fundiert geführt werden sollten.
Möchten Unternehmen ein Softwareauswahlprojekt angehen, so stehen sie vor vielschichtigen Her-ausforderungen, denen sie sich vor Beginn oder auch im Laufe der Auswahl und Implementierung stellen müssen. Der typische Auswahlprozess einer Software ist in Bild 1 dargestellt und lässt sich in 3 Phasen mit einer anschließenden Implementierungsphase unterteilen.
Bild 1: Die Phasen der klassischen Softwareauswahl und die Einbeziehung von agilen Werkzeugen für ein übergreifendes Wissensmanagement.
Die wohl komplexeste Herausforderung dieser Projekte ist das Einbinden und Beteiligen der betroffenen Organisationseinheiten. Softwareauswahlprojekte betreffen fast immer die jeweiligen Businessfunktionen, haben aber auch übergreifende Einheiten als Stakeholder (z. B. Zen-trale-IT, Prozessmanagement etc.). Durch das Ablösen und das Neueinführen einer Software sind die Nutzer/innen dieser Software mit einer Neuerung in Arbeitsweisen und Prozessschritten konfrontiert, welche Unsicherheit und daraus resultierenden Widerstand hervorrufen.
Typische Fragestellungen sind:
- „Wie sieht diese Funktion denn aus?“
- „Ist das eine Standardfunktion am Markt?“
- „Kann die neue Software das auch?“
- „Was passiert mit unseren Z-Transaktionen und Eigenprogrammierungen?“
- „Die alte Software geht doch noch, warum machen wir das überhaupt?“
Daher sind Softwareauswahl- und Einführungsprojekte keine reinen IT- sondern vielmehr Organisationsprojekte, welche sich vor allem durch eine große Anzahl Betroffener im Unternehmen und damit einem erheblichen Bedarf an Change-Aktivitäten auszeichnen [3]. Der aktive Umgang mit den Widerständen und Ängsten, aber auch kreativen Ideen der direkten Nutzer (Stakeholder) schafft die Basis für ein erfolgreiches Projekt.
Eine weitere Herausforderung bezieht sich auf den Lösungsraum und den Zeithorizont als Rahmenbedingung. Steht eine Anwendung zur Disposition oder wird eine ergänzende gesucht, so gibt es einen großen Gestaltungsspielraum, der zur Verfügung steht. Eine zukünftige Lösung kann auch weitere Anwendungen ablösen und somit einen Beitrag zur Harmonisierung leisten, muss sie aber nicht. Die bestehende Anwendung kann vielleicht nur in Teilschritten abgelöst werden, da sie kritische Funktionen enthält und diese in der vorliegenden Form am Markt nicht verfügbar sind. Oft steht an dieser Stelle die Abwägung zwischen der Nutzung des Systemstandards inklusive des damit verbundenen Standardprozesses oder einer Anpassungsprogrammierung auf den unternehmensindividuellen Ablauf.
Zusätzlich sind die IT-Landschaft sowie das gesamte Unternehmen in einem laufenden Wandel und oft historisch divergent gewachsen oder durch Zukäufe inhomogen. Der Harmonisierungsauftrag, den fast jedes Softwareauswahlprojekt mitträgt, bedarf einer vielschichtigen Betrachtung.
Daher ist das Festlegen der „strategischen Leitplanken“ eine große Herausforderung zum Beginn einer Softwareauswahl. Diese schränken den Lösungsraum „passend“ ein, sodass das Projekt einen handhabbaren Charakter behält. Ohne Einschränkung des Scopes ist das Projektteam mit einer Vielzahl an Stakeholdern, Prozessen, Zielsystemen und Restriktionen konfrontiert. Widersprechen sich diese zusätzlich, ist dies eine weitere Herausforderung auf der Suche nach einer geeigneten Software, welche zur Organisation und der vorhandenen IT-Landschaft passt.
Die aufgeführten Herausforderungen machen deutlich, dass die Anforderungserhebung und das zugehörige Stakeholdermanagement für eine zukünftige Software sehr vielschichtig sind. Neben den funktionalen Anforderungen, welche über die Stakeholder, den Prozess und das bestehende Funktionsportfolio ermittelt werden können, lassen sich nicht funktionale Anforderungen häufig nur in Rücksprache mit der zentralen IT bzw. IT-Governance definieren.
Klassisches vs. agiles Projektmanagement
Die Auswahl der Projektmanagementmethodik ist keine Entweder-oder-Entscheidung, sondern
