Interview mit Damla Nalbant

 
Damla ist schon lange bei borisgloger consulting. Sie hat viele Teams in großen und kleinen Unternehmen gesehen und sich in den letzten Jahren auf Scrum-Implementierungen in großen SAP-Umfeldern spezialisiert. Sie orchestriert dann schon mal einige Dutzend Menschen auf zwei Kontinenten. Damla lebt in Wien und fliegt, wie viele Consultants, montagmorgens zu ihren Kunden.
 
Damla Nalbant
BG: Damla, wie ist das so als Scrum Consultant in einem großen Konzern? Gibt es da etwas Besonderes, etwas das anders ist als bei einem kleinen Unternehmen?
Damla: Wenn ich es einfach beantworten müsste, würde ich sagen: Alles ist größer, mächtiger und komplizierter, als es bei einem kleinen Unternehmen je sein könnte. Jeder Prozess und jedes Vorhaben beinhaltet mehrere Schritte, Abteilungen und Personen. Ich habe zwei Großunternehmen in zwei agilen Projekten begleitet und in beiden Unternehmen waren mehrere Hundert Personen beteiligt. Das führt automatisch zu mehr nötigen Absprachen. Entscheidungen können nur über mehrere Hierarchien bzw. Freigaben getroffen werden. Jede noch so kleine Anforderung involviert mehrere Abteilungen, Fachbereiche oder Hierarchien, die diese absegnen, freischalten oder auch nur kennzeichnen müssen, dass sie es zur Kenntnis genommen haben. Es fühlt sich in einem Großunternehmen meistens sehr bürokratisch und langsam an.
 
BG: Du hast dich auf das Gelingen von SAP-Projekten mit Hilfe von Scrum spezialisiert. Was gefällt dir an SAP oder besser, weshalb findest du gerade dieses Feld spannend?
Damla: SAP sagt von sich als Unternehmen, dass es agil ist und seine Produkte agil implementiert. Viele Unternehmen sagen, dass sie ebenfalls agil sind und ihre Projekte agil umsetzen. Wenn man sich die Projekte jedoch genauer ansieht, sind SAP-Implementierungen oft mit langen Laufzeiten, großem Frust und unzufriedenstellenden Ergebnissen behaftet und kaum agil. Viele Projektleiter und Unternehmen kommen gar nicht auf die Idee, ihre SAP-Implementierung agil umzusetzen, da sie der festen Überzeugung sind, dass SAP-Projekte nicht agil umgesetzt werden können. Meistens lautet die Aussage: ”Agil ist schön und gut, aber bei SAP-Projekten geht es nicht.” Für mich persönlich gibt es kein “geht nicht” und umso spannender ist es für mich, Kunden bzw. Neukunden zu erzählen, dass es geht und dass wir mit mehreren SAP-Projekten erfolgreich waren.
Einer der Gründe, warum ich ERP-Projekte agil machen möchte, ist der Wille sowohl des Kunden als auch des Lieferanten, agil zu arbeiten. Wenn diese Voraussetzungen gegeben sind, dann muss man einfach mal machen, und genau an diesem Punkt setzen wir an. In der Umsetzung finde ich persönlich SAP-Projekte sehr herausfordernd, da es meistens Großprojekte sind und mit einigen 100 Personen umgesetzt werden. Agile Skalierung (Skalierungsmodelle) und der Umgang mit fachlicher Komplexität, die vereinfacht werden muss, sind nur zwei Beispiele von Herausforderungen, die in SAP-Projekten auf einen zukommen, und genau diese Herausforderungen treiben mich persönlich an.
 
BG: Du warst lange dabei, als wir bei einem großen Kunden ein agiles Transition Team begleitet haben. Was ist ein agiles Transition Team und wie unterstützen wir so ein Team?
Damla: Ein agiles Transition Team ist jenes Team, das sich mit Impediments der Organisation beschäftigt, die nicht mehr auf der Ebene eines Scrum-Teams gelöst werden können. Diese Impediments können zum Beispiel mehr Bedarf an Trainings und Schulungen sein, aber auch Testautomatisierung oder der Bedarf an agilen Tools. Viele Unternehmen starten mit mehreren Scrum-Teams, die nach einer Weile sehr gut liefern und alles läuft bestens bis zu jenem Punkt, an dem die Teams auf Impediments stoßen, die sie nicht beeinflussen können und für die es auch keine Verantwortlichen im Unternehmen gibt. An diesem Punkt entscheiden sich viele Unternehmen, ein Transition Team aufzusetzen, das wir vor allem in seinen Anfängen unterstützen. Wie sieht diese Unterstützung aus? Wir erstellen gemeinsam mit dem Transition Team ein Backlog, das sich aus den Impediments der Scrum-Teams erschließt. Diese Impediments werden priorisiert und in einem Sprint Rhythmus abgearbeitet und vorangetrieben.
 
BG: Hast du einen Tipp, worauf man bei der Einführung von Scrum im SAP-Umfeld besonders achten sollte?
Damla: Es gibt vieles, das man beachten muss. Die folgenden Punkte stellen sich allerdings immer wieder als große Herausforderungen heraus, unabhängig davon, ob das Projekt agil oder klassisch geführt wird:

BG: Danke für deine Zeit.
 
Buchcover Scrum-Think bigWenn ihr mehr über das Skalieren erfahren wollt: In meinem neuen Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” geht es genau darum.
 

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, aberpixabay_pdpics ü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.

In der Welt des SAP Customizings

Die Herausforderung
Als ich vor ein paar Wochen die Informationen über meinen neuen Consulting-Auftrag bekam, war ich  gespannt und neugierig zugleich. Erstmals ging es für mich um ein Projekt, das im ERP-System (Enterprise Resource Planning) von SAP angesiedelt war.
Neben einer Weiterentwicklung der hausinternen ABAP-Eigenentwicklung (Advanced Business Application Programming) sollten auch diverse Anpassungen in einem SAP-Standardmodul umgesetzt werden. Letzteres beinhaltet zu großen Anteilen das sogenannte „SAP Customizing“. In diesem Prozess wird das SAP Standardmodul durch einen SAP Berater mit Hilfe von Konfigurationen auf die im Unternehmen eingesetzten Geschäftsprozesse angepasst. Dabei werden die Berater von Entwicklern unterstützt, um etwaige Sonderfunktionalitäten im Standardmodul abzubilden, die nicht mit Hilfe des Customizings realisiert werden können.
Die Vorgehensweise des SAP Customizings ist in vielen Unternehmen typisch klassisch nach einer Wasserfallmethodik ausgerichtet. In einem ersten Schritt wird basierend auf dem Anforderungskatalog ein Konzept entwickelt, indem die Datenstrukturen und deren Verknüpfungen über Masken und Dialoge festgelegt werden. Anschließend werden in der Umsetzungsphase diese Datenstrukturen erstellt und das Standardmodul so angepasst, dass es den Geschäftsprozessen des Unternehmens entspricht.
Die ersten Sprints
Die ersten agilen Iterationen gestalteten sich als äußerst schwierig. Das fehlende Konzept verunsicherte Einzelne der SAP Berater, da sie stets das Gefühl hatten, das SAP Standardmodul im „Blindflug“ zu customizen. Auch die vielen Veränderungen basierend auf dem Feedback des Kunden führten zu Unmut, da Datenstrukturen wiederholt angepasst werden mussten. Den Satz „Das wäre uns mit einem Konzept nicht passiert“ hörte ich unzählige Male. Die Frage, die sich mir stets stellte, war, ob es in früheren Projekten nie zu Change Requests gekommen war? Die Antwort war, dass diese sehr wohl Bestandteil der Projekte waren, aber nicht mit der Häufigkeit wie in agilen Projekten auftraten. So weit so gut, wir beschlossen, die agile Methode einfach durchzuziehen.
Der Kunde war bereits nach den ersten Sprints hochzufrieden mit den Lieferungen des Projektteams. Noch nie zuvor war es ihm möglich gewesen, bereits nach dem ersten Sprint ein vorführbares Ergebnis zu sehen. Es konnte doch tatsächlich ein gesamter Geschäftsprozess durchgespielt werden; auch wenn dieser großteils noch manuell zu bewerkstelligen war und erst in den Folgesprints automatisiert wurde.
Das Learning
Die SAP Berater, angesprochen auf die Erfolge mit der Kundenzufriedenheit, räumten nach ein paar Sprints ein, dass sie immer noch Schwierigkeiten mit der neuen Methode hätten und dass sie „ihr“ Konzept vermissten. Sie sahen sich aber auch mit der Tatsache konfrontiert, dass sie die Einzigen waren, die ihr Konzept vermissten. Für den Kunden, der in früheren Projekten ursprünglich das Konzept vor der Umsetzung absegnete, war das Fehlen eines Konzeptes nicht weiter tragisch. Zumeist hatte er das Konzept ohnehin nicht vollständig verstanden und mit der neuen Methoden konnte er nach ein paar Wochen nicht nur einen Stapel Papier, sondern schon Teile seiner Endlösung sehen.
Der Erfolg des Projektes zeigt, dass auch ERP-basierte Projekte, wie jenes mit SAP, agil entwickelt werden können, ganz gleich, ob es um Programmierung oder Customizing handelt. Es geht in jedem Fall um die Schaffung neuer Funktionalität, um die Entwicklung eines neuen „Produktes“. Wie immer in solchen Prozessen hilft die iterative Vorgehensweise, den Kunden schneller zu beliefern und insgesamt zufriedener zu machen.