SAP classic - agil

"Softwareentwicklung" wird häufig mit Menschen assoziiert, die für eine Lösung Zeile für Zeile Code in ihrem Computer schreiben. Tatsache ist, dass viele Geschäftsprozesse von Unternehmen heute durch Standardsoftware abgebildet werden. Für eine neue Anforderung muss in dieser Software nicht zwangsweise wirklich neuer Code generiert werden. In vielen Fällen reicht ein „Anpassen“, das so genannte „Customizing“, der Standardsoftware aus. Aus diesem Customizing von Standardsoftware sind bei den bekanntesten Produkten ganze Geschäftszweige entstanden. Auf den Punkt gebracht spreche ich zum Beispiel von SAP-Beratern, die mit ihrer Expertise die einzelnen SAP-Module, auch als "SAP classic" bezeichnet, so anpassen, dass sie die Prozesse des Unternehmens abbilden und somit unterstützen.Nun gibt es in der realen Business-Welt oft Projekte, die bereits vorhandene SAP-Module nutzen, aber

über reines Customizing der Software hinausreichen und das Modul mit maßgeschneiderten Zusätzen ergänzen. Und genau hier wird es spannend: SAP-Berater treffen auf Softwareentwickler. Warum, ist nicht ganz einfach zu erklären. Vielleicht sind es die unterschiedlichen Typen, die in den einzelnen Berufsgruppen anzutreffen sind, vielleicht sind es auch die unterschiedlichen Rollen - vielleicht aber auch etwas ganz anderes. Der Grund tut vielleicht gar nicht soviel zur Sache. Die Tatsache ist, dass ein solches cross-funktionales Team sehr gut, effizient und erfolgreich mit agilen Methoden wie Scrum zusammenarbeiten kann.Ich habe in meinen Projekten die Erfahrung gemacht, dass sich gerade die Berater an diese neuen Teamkonstellationen gewöhnen müssen. Ihre Vorgehensweise ist oft geprägt von traditionellem Denken - vor der Implementierung wird ein Konzept ausgearbeitet wird. Von Vorteil ist, dass dieses Konzept zumeist in intensiver Interaktion mit dem Kunden in gemeinsamen Workshops erarbeitet wird. Problematisch ist dabei häufig die fehlende Vorstellungskraft der Kunden, der Fachbereiche des Unternehmens. Für sie ist die Welt der Datenstrukturen, Objekte und Transaktionen äußerst irreal und zumeist zu komplex, um sie vollständig zu verstehen. So entstehen oft aus monatelang diskutierten und mit dem Kunden abgestimmten Konzepten erst recht wieder Prozessabbildungen im System, die den Anwender nicht optimal unterstützen.Die gute Nachricht ist: Es ist möglich. Erfahrungen zeigen, dass Berater nebst Entwicklern in cross-funktionalen Teams in kurzen Iterationen miteinander arbeiten und so kontinuierlich Business Value liefern können. Customizing-Einstellungen und Codierung können so Hand in Hand in Form von User Stories erfolgen. Müssen verschiedene Möglichkeiten der Prozessabbildung doch einmal intensiver mit den Anwendern erarbeitet, besprochen und abgestimmt werden, so sollten diese Arbeitsschritte ebenfalls in Form von User Stories abgebildet werden. Ausgearbeitete und aufbereitete Entscheidungsgrundlagen entsprechen ebenfalls Lieferungen von Kundennutzen. Mit Hilfe der kontinuierlichen Lieferungen ist es dem Anwender nun auch möglich, nicht nur die Datenmodelle, sondern lauffähige Software zu begutachten. Im optimalen Fall kann er seinen Geschäftsprozess oder Teilprozesse davon bereits nach wenigen Sprints nutzen, um Feedback für das agile Team zu generieren. Alle Beteiligten können so durch die Anwendung agiler Methoden profitieren, auch oder gerade weil es sich in diesem Fall nicht nur um reine Softwareentwicklung handelt.