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.
 

User Storys im ERP-Umfeld

Ich gebe zu: Es freut mich sehr, dass sich immer mehr Unternehmen dazu entscheiden, für die Entwicklung und Einführung ihrer Enterprise Software auf alternative Vorgehensmodelle zu setzen. Das klassische Fachkonzept, das in einer monatelangen Analyse- und Konzeptionsphase geschrieben wird, hat ausgedient. Für die Herausforderungen der Zukunft sind agile Geschäftsprozesse, die mit den Anforderungen mitwachsen, besser geeignet. Ein paar Feinheiten sollte man im ERP-Umfeld dennoch beachten – zum Beispiel beim Schreiben von User Storys. Der Unterschied zu anderen Kontexten ist nicht gravierend, aber doch eine Besonderheit, der man ein wenig Aufmerksamkeit widmen sollte.
User Storys im ERP-Umfeld leiten sich in der Regel immer von den Geschäftsprozessen eines Unternehmens ab. Oft werden parallel zur Entwicklung und/oder Einführung einer neuen Enterprise Software auch diese Geschäftsprozesse fachlich und organisatorisch modelliert, was eine zusätzliche Herausforderung ist. Ich finde in diesem Zusammenhang das Konzept des Minimum Viable Products von Frank Robinson sehr hilfreich. Dabei soll ein Produkt geschaffen werden, das für den Markt akzeptabel genug ist, dass es verkauft werden könnte.
Werden Geschäftsprozesse für eine Enterprise Software nach dem MVP-Konzept modelliert, bedeutet das: Die Prozesse sind gerade so ausgestaltet, dass sie von den Anwendern verwendet werden können. Diese minimale Prozessausprägung sollte zudem …

Ist dieser Prozess gefunden, kann er eins zu eins als User Story übernommen werden. Ist diese Story zu groß für einen Sprint, muss noch einmal geschnitten werden. Das kann auf unterschiedlichste Art und Weise erfolgen, mir persönlich gefallen besonders diese zwei Varianten:

  1. Versuche, noch dünnere Prozessausprägungen zu schneiden, auch wenn diese kein sinnvolles MVP mehr ergeben.
  2. Versuche, den Prozess in Teilprozesse zu gliedern, um jeden Teilprozess in weiterer Folge als User Story aufzunehmen.

Variante 1

Für die erste Variante kann es sich anbieten, das Verb der User Story genauer zu untersuchen. Möglicherweise kann es weiter konkretisiert werden. Sehen wir es uns an einem Beispiel zur Auftragssteuerung für regionale Einheiten oder externe Dienstleister an. Die ursprüngliche User Story könnte in etwa so lauten:

„Als Vertriebsmitarbeiter möchte ich meine Aufträge steuern, um jederzeit Kontrolle über diese zu haben.”

Das Wort „steuern“ ist in diesem Beispiel bewusst gewählt, um zu zeigen, dass es weiter konkretisiert werden kann:

In diesem Fall haben wir die User Story nun weiter detailliert. In vielen Fällen handelt es sich jedoch nicht um solch triviale Beispiele, sodass kleinere User Storys durchaus kein sinnvolles MVP ergeben können. Nichtsdestotrotz kann ich diesen Ansatz empfehlen.

Variante 2

Bei Variante 2 wird eine Story Map (Idee von Jeff Patton) erstellt. Dazu können Hauptgeschäftsprozesse in Prozesse und diese in weiterer Folge in Teilprozesse gegliedert werden. Der Geschäftsprozess „Einkauf“ kann beispielsweise in folgende Teilprozesse untergliedert werden:

Für jeden dieser Teilprozesse kann nun eine User Story formuliert werden. Auch der Tipp aus Variante 1 bietet sich hier wieder an. So kann es in einem ersten Schritt durchaus gewollt sein, dass …

Es sind nur kleine Kniffe. Aber sie helfen manchmal sehr dabei, auch bei der Modellierung und Abbildung von Geschäftsprozessen auf die agilen Grundsätze wie eine End-to-End-Betrachtung von User Storys und den Fokus auf das „Minimum Viable Product“ zu vertrauen.

Scrum und ERP-Systeme – das passt zusammen!

In der Rolle der ScrumMaster und Coaches betreuen meine Kollegen und ich seit mehr als zwei Jahren intensiv diverse ERP-Projekte. Alle sind wir mittlerweile der Meinung, dass Scrum im SAP- bzw. ERP-Umfeld nicht nur funktioniert, sondern dass Scrum und ERP sogar eine besonders vorteilhafte Kombination ergeben können. Aber Moment, wie kommen wir überhaupt zu dieser Aussage?
Was sind die größten Herausforderungen, wenn es um ERP-Systeme geht:

In den 1990er- und 2000er-Jahren, in denen agile Ansätze populär wurden, war es gerade die Softwareentwicklung, die als Erste die Vorteile zu nutzen wusste. Heute führt bei Web-Anwendungen und eCommerce-Produkten kein Weg mehr an agilen Methoden vorbei. Anders sieht das hingegen bei ERP-Systemen aus, was auch die aktuellste Status Quo Agile 2014 Studie belegt. Doch woran liegt das? Ist es die Komplexität und die „Größe“ moderner ERP-Systemlandschaften? Ist es der Mix aus Einführung, Customizing und Programmierung, der Fragen zur Anwendbarkeit von Scrum aufwirft?
Während der Begleitung der Projekte konnten wir zahlreiche Stimmen und Meinungen von ERP-involvierten Personen einfangen. Wir haben versucht, die größten Bedenken in punkto Nutzung von Scrum in ERP-Projekten zu extrahieren. Drei der am öftesten genannten Bedenken und unsere Antwort darauf will ich hier anführen (die übrigen sind in unserem Whitepaper ERP nachzulesen):
„Wieso sollten bei standardmäßigen ERP-Einführungen agile Methoden verwendet werden? Es wird doch meistens nichts entwickelt, sondern die Software nur an die bestehenden Prozesse angepasst.“
ERP-Einführungen greifen in die Arbeitsweise vieler Mitarbeiter ein, und ob Standard oder eigene Entwicklung: Veränderungen bewirken Unsicherheit vor allem bei jenen Mitarbeitern, die tagtäglich die zukünftige Software nutzen müssen. Widerstand ist dann oft vorprogrammiert. Agile Methoden wie Scrum haben den klaren Vorteil, dass sie die Betroffenen, die Anwender, frühzeitig in den Entwicklungsprozess einbeziehen. Deren Feedback wird ernst genommen und sie bekommen so kein System übergestülpt, das nicht zu ihren Arbeitsabläufen passt. Einbeziehung steigert die Akzeptanz und führt so auch eher zu einem Projekterfolg.
„In ERP-Systemen kann nur schwer agil entwickelt werden, da alle Anforderungen am Anfang bekannt sein müssen. Darauf aufbauend können das Datenmodell und das Fachkonzept erstellt werden.“
Im Grunde ist es doch so: Die meisten ERP-Systeme unterstützen ihre Nutzer nicht auf die effizienteste Art und Weise, die systemtechnisch möglich wäre. Ursache dafür ist aus unserer Sicht das Festhalten an Anforderungen und Fachkonzepten, die als vollständig und unumstößlich betrachtet werden. Der Fachbereich als Anforderer kann sich zu Beginn eines Projekts meist gar nicht vorstellen, wie das IT-System den Prozess unterstützen soll. Das von der IT vorgelegte Fachkonzept wird durchgewinkt, ohne es komplett verstanden zu haben. So steuern einige Projekte auf nicht bedienbare Systeme zu, die anschließend mit unzähligen Change Requests an die Realität angepasst werden müssen. Scrum kann hier helfen, sich dem für den Anwender „richtigen“ System von Anfang an anzunähern. Denn was die Anwender tatsächlich brauchen, erkennen sie durch Ausprobieren. Das passiert durch das kontinuierliche Liefern in kurzen Zyklen. Die Nutzer haben etwas in den Händen, können es testen und Rückmeldung geben, was bereits passt und was noch angepasst oder weitert werden sollte.
„In ERP-Systemen ist es nur beschränkt möglich, alle zwei Wochen fertige Software mit zusätzlicher Funktionalität zu liefern und produktiv zu setzen. Es besteht die Gefahr, dass bestehende Funktionalität nicht mehr einwandfrei funktioniert und operative Prozesse blockiert werden.”
Scrum selbst ist keine Entwicklungsmethode, sondern eine Vorgehensweise, um komplexe Aufgaben in überschaubaren Teilgrößen zu zerlegen und umzusetzen. Im Zusammenhang mit agilen Management-Frameworks für die Softwareentwicklung haben sich aber auch agile Entwicklungspraktiken etabliert. Es geht darum, die Qualität des Quellcodes konstant hoch zu halten und Funktionalitäten mit automatisierten Tests kontinuierlich zu überprüfen. Langsam aber sicher setzen sich auch im ERP-Bereich intelligente Entwicklungsumgebungen und nützliche Tools (Eclipse Unterstützung, eCATT, Mock-Frameworks) durch, mit deren Hilfe die Stabilität eines gewaltigen ERP-Komplexes nachhaltig abgesichert werden kann.
Was sind also auf den Punkt gebracht die größten Vorteile von agilen Methoden im ERP-Umfeld?

Mehr zur Frage, ob Scrum und ERP zusammenpassen, lesen Sie in unserem Whitepaper ERP.