Im grossen Stil ansetzen – Agile Transformation und SAP

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 erteilen 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 Seite 70) 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 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ösungsdesign von SAP ist wichtig und macht bei Nichteinhaltung Korrekturen oder Workarounds 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.