Eine Verwaltung im öffentlichen Dienst führte S/4HANA neu ein, Greenfield, also ohne Übernahme des Altsystems, in Wellen, und ich war in der ersten Welle technisch für FI verantwortlich. Das Altsystem war über viele Jahre gewachsen, voller Eigenentwicklungen, und das erklärte Ziel war die Rückkehr in den Standard, bei Prozessen, Schnittstellen, Code und Customizing. Dafür muss man wissen, was das alte System tut, und niemand dort konnte das aus dem Kopf sagen. Das ist in gewachsenen Systemen der Normalfall. Die Beschreibung, die man braucht, steht im System selbst, verteilt auf vier Quellen.

Der Fragenkatalog bringt keine Entscheidungen

Der Einstieg war der übliche: eine Sandbox mit Grundcustomizing, dann eine virtuelle Roadshow durch die Bereiche, in der wir mit den Fachbereichen Fragenkataloge durchgingen, je Modul einer, mit Fragen wie "Welche Nummernkreise und Belegarten verwenden Sie aktuell?" und "Welche Zahlungsbedingungen sind im Einsatz?". Heraus kam eine Beschreibung der heutigen Klicks, als Grundlage für ein neues System taugte sie nicht.

Das ist keine Schwäche der Fachbereiche, sondern die falsche Frage an die falsche Stelle. Ein Sachbearbeiter kennt seine Prozesse als Folge von Transaktionen und Eingaben, nicht als Customizing-Einträge. Die Frage nach den Belegarten kann er nicht beantworten, weil er nie entschieden hat, welche es gibt, er benutzt die, die da sind. Und die Kollegen, die das System einmal eingerichtet haben, sind in einem gewachsenen System selten noch da. Wer so fragt, bekommt entweder Schweigen oder eine Abschrift des heutigen Zustands, und beides bringt ein Greenfield-Projekt nicht weiter.

Niemand hat das Dokument, das das System beschreibt

Ich fragte nach einem Überblick über die Systemlandschaft, also die SAP-Systeme, die angebundenen Drittsysteme und die Schnittstellen dazwischen. Es gab keinen aktuellen. Das ist nicht ungewöhnlich: eine Landschaftsübersicht ist am Tag nach ihrer Erstellung veraltet, und niemand pflegt sie nach, weil sie im Tagesgeschäft niemand braucht. Dasselbe gilt für Konzepte, die zwei Releases alt sind, und für Prozessbeschreibungen, die beschreiben, wie es gedacht war.

Die einzige Beschreibung des Systems, die nicht veraltet, ist das System. Das Customizing und die Rollen stehen in Tabellen, die Eigenentwicklungen im Objektkatalog, und was davon benutzt wird, in den Nutzungszahlen. Also habe ich die Fachbereiche vorerst in Ruhe gelassen und das System gelesen.

Vier Quellen beantworten, was das Altsystem tut

Vier Fragen beschreiben ein fremdes System ausreichend, um ein Projekt darauf zu planen, und jede hat eine Quelle, die man ohne Entwicklerzugang und ohne Debugger lesen kann.

Frage Quelle Was sie liefert
Was wird benutzt? Nutzungszahlen aus den Workload-Statistiken (ST03N) Programme, Benutzer, Aufrufzahlen je Zeitraum
Was ist eingestellt? Der Einführungsleitfaden (IMG) und die Customizing-Tabellen dahinter Jede Aktivität, jede View, jeder Wert
Was wurde gebaut? Objektkatalog TADIR im Z-Namensraum, dazu die Quelltexte Reports, Schnittstellen, Formulare, Erweiterungen
Wer darf was? Rollen und ihre Transaktionszuordnung Welche Transaktionen im Rollenbau vorkommen

Die erste Frage, was benutzt wird, kommt zuerst, weil sie die anderen drei verkleinert. Die Nutzungszahlen über zwölf Monate zeigten 461 Programme, die mindestens einmal gelaufen waren. 247 davon lagen im Z-Namensraum, also Eigenentwicklungen. 106 dieser 247 hatte in zwölf Monaten genau ein Benutzer aufgerufen, und hinter manchem dieser Benutzer steckt ein Schnittstellenjob. Die vier meistgenutzten Eigenentwicklungen kamen dagegen auf je rund 505.000 Dialogschritte bei zehn Benutzern. Über diese vier muss man reden.

Die selten genutzten Eigenentwicklungen sind Kandidaten für den Standard oder für nichts, und das weiß man, bevor man eine Zeile Code gelesen hat.

Erst messen, dann fragen. Wer die Liste der Eigenentwicklungen an die Fachbereiche schickt, mit der Bitte zu prüfen, was davon noch gebraucht wird, hat im Folgemonat einen Sprung in den Nutzungszahlen, weil jeder einmal nachsieht, was das Programm mit dem merkwürdigen Namen tut. Eine Auswertung danach misst nur die Neugier.

Für die zweite Frage, was eingestellt ist, ist der IMG die Liste. Der Einführungsleitfaden führt das gesamte Customizing eines Systems, also die Einstellungen, die das Standardsystem an ein Unternehmen anpassen, als Baum von Aktivitäten, und wer einen Ast davon als Rahmen nimmt, kann nichts vergessen, was darin steht. Welche Tabellen hinter einer Aktivität stehen, sagt das System: jede Aktivität nennt ihre Pflegeobjekte, meist Views, und das Data Dictionary nennt zu jeder View die Tabellen darunter.

Aus dem Altsystem habe ich diese Tabellen in voller Breite gezogen, 62 Views mit ihren 89 Tabellen, je Paar aus View und Tabelle ein Blatt in einer Excel-Mappe. Das ist das Ist des gewählten Asts, so weit der Baum reicht.

Die dritte Frage, was gebaut wurde, war für FI in dieser Welle klein: von den 247 Eigenentwicklungen gehörte der größte Teil anderen Modulen und späteren Wellen, für FI blieben wenige Reports, wenige Schnittstellen, wenige Formulare, kein Workflow. Die meisten davon hatte ich mit den Nutzungszahlen schon einsortiert, und für den Rest reichte ein Blick in den Quelltext, um zu sehen, dass der Standard das inzwischen kann.

Die vierte Frage, wer was darf, beantwortete eine Auswertung der Rollen gegen ihre Transaktionen, und sie lieferte nebenbei die Liste der Transaktionen, die überhaupt jemand ausführen durfte.

Das Altsystem ist die Checkliste für das neue

Mit dem Ist auf dem Tisch ändert sich die Frage an den Fachbereich. Statt "Welche Belegarten brauchen Sie?" heißt sie "Hier sind die 88 Belegarten, die es gibt, welche davon brauchen Sie weiter, und warum?". Die zweite Frage kann ein Sachbearbeiter beantworten, die erste nicht.

Hier zweigt Greenfield von Brownfield ab. Ein Brownfield-Projekt übernimmt das Altsystem und räumt auf. Ein Greenfield-Projekt baut neu und benutzt das Altsystem nur, um nichts zu vergessen. Das Customizing des Altsystems ist deshalb eine Checkliste: je IMG-Aktivität steht das Ist daneben, und dann folgen drei Fragen. Braucht das neue System diese Einstellung noch? Kann der Standard inzwischen, was damals eigens eingestellt oder programmiert wurde? Und liegt die Einstellung in S/4 an derselben Stelle, oder bildet das Hauptbuch in S/4 sie in anderen Tabellen ab?

Viele Antworten fallen leicht. Ein Altsystem aus der R/3-Zeit trägt angepasste Kopien von Standardprogrammen, deren Sonderlogik der Standard längst kann, das kopierte Kontoauszugsprogramm ist das klassische Beispiel. Eine Eigenentwicklung, die im ganzen Jahr einmal gelaufen ist, braucht keine Diskussion. Für einen Customizing-Eintrag, den das Hauptbuch in S/4 nicht mehr kennt, entscheidet man, wie der Zweck im neuen Modell abgebildet wird.

Was man nicht tun sollte, ist das Altsystem Tabelle für Tabelle abzuziehen und ins neue System hochzuladen. Das wäre Brownfield auf die umständlichste Art.

Das Konzept schreibt sich zur Hälfte selbst

Aus dem Rahmen und dem Ist entstand das Gerüst des technischen Feinkonzepts, generiert: je IMG-Aktivität ein Abschnitt mit Pfad, Standarddoku und den Tabellen dahinter, das Ist aus dem Altsystem daneben in der Mappe, und dazwischen Platz für den Satz, der die Entscheidung trägt. Der fachliche Teil, nach Prozessen gegliedert, kam aus den Gesprächen mit den Fachbereichen, die jetzt eine Vorlage hatten, zu der sie Ja oder Nein sagen konnten. Im Januar des Folgejahres ging das Konzept an die Customizer.

Und weil die Aktivitätenliste schon im Oktober stand, stand auch die Aufwandsschätzung, bevor jemand ein Kapitel geschrieben hatte: je Arbeitspaket eine Drei-Punkt-Schätzung aus optimistischem, wahrscheinlichem und pessimistischem Aufwand, und eine Spalte mit der Begründung. Heute rechnet die Schätzung je Aktivität mit einer Komplexität aus der Zahl der Tabellen und Views dahinter. Wie das Gerüst aus dem System entsteht und wie die Schätzung auf derselben Liste rechnet, sind zwei eigene Beiträge.

Der Readiness Check sagt, was bei der Konvertierung bricht

Für den Weg nach S/4HANA liefert SAP den Readiness Check und die Custom-Code-Analyse, und beide beantworten die Brownfield-Frage: was bei einer Konvertierung bricht. Die Greenfield-Frage lautet, was der Kunde braucht. Das beantworten beide nicht, sie halten Code und Konfiguration gegen die Simplification List, die Liste der Änderungen zwischen ECC und S/4HANA. Die vier Quellen oben beantworten sie auch nicht, aber sie machen die Frage so klein, dass ein Fachbereich sie beantworten kann.

Was dieser Weg nicht zeigt

Er zeigt nicht, was außerhalb von SAP passiert. Die Excel-Mappe, in der ein Sachgebiet seit Jahren sein eigenes Berichtswesen pflegt, steht in keiner Tabelle, und sie ist oft der Grund, warum ein Report im System nicht mehr benutzt wird.

Nutzungszahlen über zwölf Monate übersehen, was seltener läuft. Ein Programm für den Jahresabschluss taucht einmal auf, eines für eine Prüfung alle drei Jahre gar nicht. Die Liste der selten genutzten Programme ist deshalb eine Liste von Fragen an den Fachbereich.

Und er zeigt nur, was im gewählten IMG-Ast hängt. Eigene Z-Tabellen, die ein Kunde über eine Pflegetransaktion ohne IMG-Knoten pflegt, kommen aus der dritten Frage.

Rollen zeigen, was jemand darf, und ohne die Nutzungszahlen daneben überschätzt man daraus die Breite des Systems.

Alle vier Quellen lassen sich lesen, ohne etwas zu installieren

Alle vier Quellen sind Tabellen. Customizing und Code zieht man aus dem Entwicklungssystem, die Nutzungszahlen aus der Produktion, installieren darf man in keinem von beiden etwas. Danach beginnt die Arbeit mit den Fachbereichen, und sie beginnt mit einer Liste statt mit einem leeren Blatt. Wie man die Tabellen von dort holt, mit einer Ladedatei und einem Aufruf, ist der nächste Beitrag.