In der Welt des SAP Customizings

Die HerausforderungAls 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 SprintsDie 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 LearningDie 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.