Unternehmen müssen immer schneller neue Anforderungen von Kunden und internen Stakeholdern disruptiv entlang von Geschäftsmodellen adaptieren und implementieren. In diesem Zusammenhang werden zunehmend Ansätze zur skalierten Agilität angewendet. Doch wie lassen sich agile Ansätze im Kontext von SAP-Lösungen erfolgreich einsetzen?

Die Digitalisierung rückt die Innovation ganzer Geschäftsmodelle in den Fokus, die eng mit neuen Technologien wie dem Internet der Dinge (Internet-of-Things, IoT), Blockchain oder künstlicher Intelligenz verzahnt sind. Aufgrund der hohen Schwankung teils unbekannter Einflussfaktoren erweisen sich klassische, wasserfallartige Projektansätze vielfach als wirkungslos. Dieser Komplexität versuchen Unternehmen einerseits mit kürzeren und adaptierbaren Entscheidungszyklen zu begegnen. Andererseits verteilen sie Entscheidungskompetenzen auf mehr Mitarbeitende. Dementsprechend ändern sich die strategischen Planungsansätze der Unternehmen: Anstatt mehrjährige Strategien zu definieren und die Ressourcen daran auszurichten, müssen neue Möglichkeiten schneller adaptiert und Bedrohungen pariert werden.

Essentiell für den Unternehmenserfolg ist, dass die Expertise aller Mitarbeitenden in unternehmerischen Rollen berücksichtigt wird. Aus dieser Überzeugung heraus haben sich neue agile Transformationsansätze wie Scaled Agile Framework (SAFe) oder Large Scale Scrum (LeSS; siehe Glossar) entwickelt. Sie erweitern Ansätze wie Scrum und ermöglichen agiles Zusammenarbeiten im Unternehmen. Die zentrale Idee von skalierter Agilität besteht darin, strategische Ideen sukzessive entlang der Organisationspyramide in kleinere Arbeitspakete zu unterteilen – wobei über Vorgaben das „Was“ formuliert und das „Wie“ der nächsten Stufe überlassen wird.

An konkreten Lösungen bauen

Statt langer und detaillierter Analysen und Konzeptionen, die in einem Blueprint enden, wird schon vor Ende der Konzeption an konkreten Lösungen gebaut, die weiterentwickelt werden. So werden die zentralen Anforderungen sukzessive aufgenommen und unmittelbar ein fassbares Produkt rasch mit dem Kunden validiert. Man spricht in diesem Zusammenhang von einem Minimal-Viable-Product (MVP) – einer einsatzfähigen Lösung, die die wesentlichen Funktionen enthält, aber keine reduzierte und funktionale Version der Ziellösung ist. Aus Architektursicht muss geklärt werden, wie ein erster MVP-Prozess final aussehen könnte und was die Standardkomponenten von SAP tatsächlich zulassen.

Herausforderungen von SAP

Die dezentrale Entscheidungsdynamik agiler Lösungsarchitekturen läuft dabei in einen Zielkonflikt mit der Funktionsweise von Standard-Software-Lösungen: Während agile Modelle ihren Mehrwert vorwiegend aus sehr schnellen, lokalen Lösungen für ein konkretes Problem schöpfen, besteht der Vorteil von ERP-Lösungen insbesondere darin, möglichst wiederverwendbare Elemente anzubieten und die individuelle Abbildung von Funktionen zu begrenzen. In vielen Unternehmen sind fachliche Strukturen und Prozesse mit einem hohen Eigenentwicklungsanteil gewachsen, was wiederum die Nutzbarkeit von Standardfunktionen einschränkt und zusätzlichen Aufwand für die Analyse von Architekturen und das Testing nach sich zieht.

Architekturbezogene Grundsatzentscheide

Deshalb muss früh geprüft werden, wo die bestehenden Lösungen des Standards ausreichen und wo Individualentwicklungen notwendig sind. Die Arbeit mit Lösungs- und Umsetzungsszenarien ist hier bedeutend. Zusätzlich muss die Integration spezifischer Lösungskomponenten aus der SAP- und Nicht-SAP-Welt berücksichtigt werden.

Daher empfiehlt es sich, bereits in der Sprint-­Planung verschiedene Varianten auszuarbeiten und die Schlüsselentscheide vor dem Start des Sprints gemeinsam mit dem Business auf unterschiedlichen Ebenen zu treffen. Technologische Entscheidungen, z. B. im Zusammenhang mit SAP-Cloud-Lösungen, oder Entscheidungen zu Business-Funktionen, z. B. zu bereits gekauften Funktionen im Anwendungsportfolio oder zu komplett neuen Lösungen, können nicht auf der gleichen Stufe getroffen werden. Zudem ist es wichtig, Halbwertszeit und Entwicklungsszenarien von SAP ausführlich zu betrachten. Ein verlässliches Lösungs-Design von SAP ist darüber hinaus wichtig und macht bei Nichteinhaltung Korrekturen oder Work-arounds notwendig.

Kontinuierliche Validierung

Die Idee agiler Vorgehensweisen beinhaltet kurze Wiederholungen gefolgt von schnellen und häufigen Release-Zyklen. Dadurch können die Anforderungen regelmäßig mit den Anwendergruppen validiert werden. Das trägt dazu bei, dass die Gesamtlösung besser akzeptiert und verstanden wird.

Ein probates Mittel, um eine einheitliche Perspektive zu entwickeln, ist es, die Diskussion auf die User-Journey zu fokussieren. Hierfür bietet SAP die Lösung build.me an. Sie ermöglicht, die Oberflächen und deren Look-and-feel sowie Verhalten schnell aufzubauen. Die Ergebnisse auf Basis von SAPUI5 lassen sich später als lauffähige Lösungen weiterentwickeln und direkt in die Cloud-basierte SAP­-Entwicklungsumgebung WebIDE integrieren.

SAP Activate (siehe Glossar) bietet bestimmte Ansätze im Kontext der Einführung von agilen Projekten. Als Add-on für den Solution Manager unterstützt SAP Focused Build (siehe Glossar) die Activate-Methodik und ermöglicht so einen integrierten „Requirements­-to-Deploy“-Prozess nach agilem Vorgehen. Damit können Anforderungen entlang der User-­Journey direkt im Solution Manager erfasst und als User-Stories im Backlog aufgenommen werden. Freigegebene User-­Stories lassen sich anschließend durch das Entwickler-Team in Wellen und Sprints iterativ einplanen. Eine volle Integration in die agilen Werkzeuge ist damit allerdings noch nicht gegeben.

Agilität verändert den Bedarf an Skillsets

Der Geschäftsmodell- und Nutzerzentrierte Ansatz der Agilität führt zudem zu einem veränderten Bedarf an SAP-Know-how. Architekturwissen hinsichtlich der Integration und Kompatibilität von modulübergreifenden Lösungsszenarien wird wichtiger. Um solche Lösungen entwickeln zu können, braucht es breites Wissen über mögliche Entwicklungen des Geschäftsmodells, Auswirkung auf die Prozesse und Lösungsszenarien in der SAP-Welt. Aufgrund der kürzeren Innovationszyklen nimmt die Halbwertszeit des Wissens ab und breites Integrations-Know-how wird wichtiger.

Der seitens SAP propagierte Guided-Configuration-Ansatz, der eine geführte Schritt-­für-Schritt-Konfiguration der Customizing-­Tabellen unterstützt, kann hier hilfreich sein. Er wird aber aufgrund der Komplexität der SAP-Funktionalitäten nur bedingt Spezialkenntnisse und Erfahrung im Customizing einzelner Module ersetzen können.

Dementsprechend wird das T-Shaping, das die Stärken von Generalist und Spezialist vereint, auch aus SAP-Perspektive immer wichtiger: Zwar besteht weiterhin der Bedarf, spezifisches Know-how in bestimmten Bereichen, Komponenten und Modulen aufzubauen, gleichzeitig wird das Verständnis für die Gesamtintegration und Auswirkungen wichtiger, um ganzheitliche Lösungen in agilen Teams effektiv entwickeln zu können.

Treiber für skalierte Agilität mit SAP

Zusammengefasst lassen sich die folgenden Treiber ausmachen, um SAP im Rahmen der skalierten Agilität zu nutzen:

Bildnachweis: Fernfachhochschule Schweiz, Daniella Winkler + Shutterstock