SAP BPEM: Exportfehler aus Massenläufen als Klärfall bearbeiten

Ein Massenlauf endet mit Warnungen. Im Zielsystem fehlen einzelne Sachverhalte, das Protokoll benennt sie, und die Frage, wer sie abarbeitet, hat keine organisatorische Antwort. Zwischen einem protokollierten und einem zugewiesenen Fehler liegt keine Technik, sondern eine Festlegung im Entwurf.

Der stille Fehler

Eigenentwickelte Massenläufe protokollieren sorgfältig. Sie halten fest, was gelesen, was geliefert und was verworfen wurde, und sie tun das nachvollziehbar. Was sie nicht leisten, ist die Übergabe. Ein Protokolleintrag hat keinen Bearbeiter, keine Fälligkeit, keine Wiedervorlage und keine Anleitung, wie der Sachverhalt zu bereinigen ist. Damit fehlt auch die Messbarkeit über die Zeit, denn niemand kann sagen, ob dieselbe Ausnahme wiederkehrt oder zum ersten Mal auftritt.

Das ist kein Versäumnis der Entwicklung, sondern die Eigenschaft eines Protokolls. Es dokumentiert einen Lauf, es organisiert keine Arbeit. Solange die Ausnahme dort liegen bleibt, wird sie nicht behoben, sie wird alt.

Für die Leitung liegt die Folge an einer anderen Stelle als der Fehler. Der Verwurf entsteht in der Ausleitung, bemerkt wird er im Zielsystem oder in der Abrechnung, und erklären muss ihn der Fachbereich gegenüber der Stelle, die mit den gelieferten Daten arbeitet. Steuerbar ist die Ausleitung in diesem Zustand nicht, weil die Qualität ihrer Lieferungen nicht gezählt wird. Was nicht gezählt wird, taucht in keinem Bericht auf und wird deshalb erst dann zum Thema, wenn ein Termin daran hängt.

Wie SAP BPEM Ausnahmen in Arbeit verwandelt

Für dieses Problem hält der Standard einen Kanal bereit, und er ist nicht neu. Das Klärfallmanagement in S/4HANA Utilities, im Standard als SAP BPEM geführt, nimmt Meldungen aus Massenläufen auf und macht daraus Aufgaben mit Bearbeiter, Fälligkeit und nachvollziehbarem Verlauf. Damit wechselt die Ausnahme das Regime. Sie ist nicht mehr Bestandteil eines Laufprotokolls, das jemand lesen müsste, sondern eine Aufgabe in einem Arbeitsvorrat, die jemandem gehört und deren Bestand sich auswerten lässt. Der Fall trägt außerdem seinen Verlauf mit, sodass eine wiederkehrende Ursache als Wiederholung sichtbar wird und nicht als neuer Vorfall.

Der Weg dorthin führt über das Anwendungsprotokoll. Der Lauf klammert seine Verarbeitung je Business-Objekt, indem er Beginn und Ende der Bearbeitung durch die beiden EMMA-Kontrollnachrichten kennzeichnet; alles, was dazwischen protokolliert wird, gehört zu genau diesem Objekt. Aus diesen Klammern bildet die Jobvorbereitung Nachrichtengruppen. Für jede Gruppe wird über den Business-Prozess-Code ermittelt, welche Klärfallkategorien in Frage kommen, und für jede Kategorie wird geprüft, ob die hinterlegte Triggernachricht in der Gruppe vorkommt. Trifft sie zu, entsteht ein Klärfall, das System ermittelt den Bearbeiter, und der Fall bringt seinen Lösungsprozess mit.

Die eigentliche Arbeit leistet dabei die Gruppierung. Sie fasst mehrere Meldungen zu einem Sachverhalt zusammen, sodass ein Objekt mit mehreren Meldungen eine Aufgabe erzeugt und nicht mehrere. Ohne diese Klammer entstünde für jede Meldung ein eigener Fall, und der Bearbeiterkreis bekäme dieselbe Ursache in vielen Fassungen vorgelegt.

Was der eigene Lauf dafür leisten muss

Der Kanal ist vorhanden, er greift aber nur, wenn der Lauf ihn bedient. Die dafür nötigen Eigenschaften liegen im Entwurf des Laufs und nicht im Customizing, und genau deshalb gehört diese Festlegung vor die erste Implementierung und nicht in die Stabilisierung danach. Die folgenden Anforderungen stammen aus dem Bau einer solchen Ausleitung in einem S/4HANA-Utilities-Greenfield bei einem Verteilnetzbetreiber.

• Verarbeitung je Objekt klammern, damit jede Meldung genau einem Objekt zuzuordnen ist.
• Objekttyp und Objekt-Identifikation mitgeben, weil ein Fall ohne Objektbezug keinen Bearbeiter findet und im Zweifel bei niemandem landet.
• Einen eigenen Business-Prozess-Code definieren und aktivieren, weil der Lauf sonst in keiner Kategorieermittlung auftaucht.
• Meldungen stabil, sprechend und je Fehlerklasse unterscheidbar halten, weil aus ihnen Triggernachrichten werden und eine Meldung mit mehreren Ursachen sich später nicht auf mehrere Lösungsprozesse verteilen lässt.
• Alle fachlich erheblichen Meldungen ins Protokoll aufnehmen, statt sie vorab zu filtern, weil eine gefilterte Meldung in der Gruppierung fehlt und damit in der Kategorieermittlung nicht existiert.

Dazu kommt die Rückrichtung, die beim Bau einer Ausleitung leicht übersehen wird. Eine Lieferung, die das Zielsystem ablehnt, ist derselbe Sachverhalt wie ein Fehler im Lauf und gehört in denselben Kanal. Wandert die Ablehnung in ein Betriebspostfach, beginnt die Kette von vorn ohne Adressaten, nur eine Systemgrenze weiter. Auch dieser Fall braucht den Objektbezug, sonst bleibt die Ablehnung eine Datei und wird kein Sachverhalt, den jemand bearbeiten kann. Wer die Rückmeldewege der Marktkommunikation kennt, kennt das Muster, denn dort ist die Antwort der Gegenseite Teil des Prozesses und nicht ein Anhang daran.

Von der Fehlerklasse zur Kategorie

Die Reihenfolge entscheidet hier über die Brauchbarkeit des Ergebnisses. Wer in SAP BPEM mit den Klärfallkategorien beginnt, verteilt Arbeit, bevor er weiß, welche Arbeit anfällt. Der Fehlerkatalog entsteht deshalb zuerst, und die Kategorien folgen ihm.

Ein solcher Katalog benennt die Klassen von Ausnahmen, die eine Ausleitung überhaupt erzeugen kann. Beispiele dafür sind ein fehlender Pflichtwert am Zählpunkt, eine unauflösbare Beziehung im Komplex aus Markt- und Messlokation, eine fehlende Zuordnung im Zielmodell, eine Formatverletzung gegenüber der Zielstruktur und eine fachlich unplausible Menge. Diese Klassen unterscheiden sich nicht in der Technik, sondern im Adressaten. Ein fehlender Pflichtwert ist Stammdatenpflege, eine unauflösbare Beziehung ist Modellierung, eine unplausible Menge ist ein fachliches Urteil.

Je Klasse gehören deshalb ein Objekt, ein Bearbeiterkreis und ein Lösungsprozess zusammen. Erst diese Zuordnung macht aus einer Liste von Fehlern eine Zuständigkeit, und erst danach lässt sich sinnvoll entscheiden, welche Klassen eine eigene Kategorie bekommen und welche sich eine teilen. Der Katalog entsteht damit nicht in der Entwicklung allein, sondern mit den Stellen, die die Fälle später bearbeiten, und das ist der Grund, warum er Zeit im Entwurf braucht und nicht im Test. In der Arbeit an Klärfällen ist das die vertraute Reihenfolge, denn auch dort steht die Fehlerursache vor der Kategorie und nicht dahinter. Seine Form ist eine Tabelle, er steht deshalb nicht in diesem Text.

Die Mengenfrage als Entwurfsanforderung

Ein Anschluss an den Klärfallkanal kann auch zu gut funktionieren. Fällt ein Pflichtwert nach einer Umstellung für viele Zählpunkte aus, erzeugt die Kette so viele Fälle, wie es betroffene Objekte gibt, und der Arbeitsvorrat wird unbrauchbar. Der Bearbeiterkreis sieht dann nicht ein Problem, sondern eine Wand aus gleichlautenden Aufgaben, und die eigentliche Ursache verschwindet darin.

Nicht jeder Fehler wird also ein Fall, und das ist Teil des Entwurfs. Der Lauf braucht dafür einen Schwellenwert je Fehlerklasse. Oberhalb dieser Grenze aggregiert er und meldet den Sachverhalt als Betriebsmeldung an eine Stelle, statt ihn als Einzelfälle an viele zu verteilen; unterhalb bleibt es beim Einzelfall, weil dort die Einzelbearbeitung die richtige Antwort ist. Vollabzug und Migration sind die Sonderfälle, in denen die Fallerzeugung bewusst ausgesetzt wird. Das Protokoll bleibt dabei vollständig, nur die Zuweisung entfällt, und das ist eine begründete Entscheidung im Entwurf und keine Abschaltung im Betrieb. Der Schwellenwert selbst ist eine fachliche Größe und gehört in dieselbe Abstimmung wie die Kategorien, denn er entscheidet, welche Abweichung als Einzelfall behandelt wird und welche als Betriebslage.

Dieselbe Rechnung gehört auch auf die Ebene der einzelnen Kategorie. Eine Kategorie soll einen Fall je Objekt erzeugen und nicht je Meldung. Dublettenverhalten und die zu erwartenden Fallmengen werden deshalb vor der Aktivierung durchgerechnet, sonst verliert der Bearbeiterkreis das Vertrauen in den Kanal, bevor er den ersten Sachverhalt bearbeitet hat. Generische Auffangkategorien sind dabei das Sicherheitsnetz für Ausnahmen, die im Katalog noch nicht stehen. Sie sind ausdrücklich ein Übergangszustand und kein Zielbild, denn ein Fall in einer Auffangkategorie hat einen Bearbeiter, aber keinen Lösungsprozess.

Was dieselbe Disziplin für die Prüfung leistet

Die Anforderungen an Klammerung, Meldungsqualität und Mengensteuerung entstehen aus dem Fehlerweg. Sie erzeugen als Nebenprodukt genau die Belege, nach denen eine Prüfung fragt, und das ist der zweite Grund, warum sie in den Entwurf gehören und nicht in die Nacharbeit.

• Laufidentität. Jede Ausgabedatei ist genau einem Lauf zuordenbar, und jeder Datensatz ist seinem Lauf zuordenbar.
• Mengenabstimmung. Gelesen, geliefert, verworfen und übersprungen ergeben zusammen ein geschlossenes Bild.
• Feldherkunft. Zu jedem gelieferten Feld ist die Quelle benannt.
• Ausnahmebehandlung. Jede Abweichung ist protokolliert, adressiert und in ihrem Verlauf nachvollziehbar.

Die Laufidentität steht dabei nicht zufällig vorn. Ohne sie lässt sich keine Menge und keine Ausnahme einem Zeitpunkt zuordnen, und die übrigen Ketten hängen in der Luft.

Für die Prüfung sind Übersprung und Verwurf zwei verschiedene Sachverhalte, und sie werden unterschiedlich beantwortet. Ein Übersprung bedeutet, dass der Lauf keine erhebliche Änderung gesehen hat und das Zielsystem auf dem Stand des letzten liefernden Laufs bleibt; das ist erklärbar, sobald dokumentiert ist, woran der Lauf Änderung erkennt. Ein Verwurf bedeutet, dass eine Änderung erkannt, aber nicht geliefert wurde; das ist nur erklärbar, wenn der Verwurf einen Adressaten hat und sein weiterer Weg sichtbar ist. Die ausgefüllte Prüfliste gehört zu den Unterlagen der Strecke und nicht in den Kopf einer einzelnen Person.

Zur Art der Prüfung. Gemeint ist die interne und externe Prüfung IT-gestützter Prozesse, die in Abrechnung und Rechnungslegung hineinwirken. Dieser Beitrag beschreibt, welche Belege eine solche Prüfung braucht; er legt keinen Prüfungsstandard aus und bewertet keine Kontrollreife.

Was dadurch entsteht

Ein Lauf, der nach diesen Regeln protokolliert, erreicht einen Zustand, der sich benennen lässt. Der Verwurf einer Einheit hat einen Bearbeiter. Die Behebung kann kontrolliert in den nächsten Lauf zurückgeführt werden; dort wird der Sachverhalt erneut geprüft und bei erfolgreicher Prüfung geliefert. Die Mengen je Lauf sind abstimmbar, ohne dass jemand Protokolle nebeneinanderlegt. Die Fallmengen werden zu einer betrieblichen Kennzahl für das Zusammenspiel aus Datenqualität, Validierung und Fehlerbehandlung. Und eine Frage der Prüfung ist aus dem Entwurf beantwortbar, statt aus Protokollen rekonstruiert zu werden.

Damit verschiebt sich die Diskussion über die Ausleitung. Sie handelt nicht mehr davon, ob ein Lauf erfolgreich war, sondern davon, wie viele Sachverhalte er offen gelassen hat und wer daran arbeitet. Das ist eine Aussage, die sich dem Fachbereich, der Projektleitung und einer Prüfung in denselben Worten erklären lässt.

Ohne diese Festlegungen bleibt es bei der Ausgangslage, und die zeigt sich nicht im Zielbild, sondern am letzten Lauf.

Wie viele Sachverhalte hat Ihr letzter Lauf verworfen, und wer hat sie bearbeitet? Die erste Hälfte der Frage beantwortet das Protokoll, die zweite beantwortet niemand. Verworfene Sachverhalte werden nicht dadurch geliefert, dass sie protokolliert sind. Sie bleiben liegen, bis jemand sie im Zielsystem oder in der Abrechnung bemerkt, und dann leistet die Nacharbeit nicht die Stelle, die den Fehler beheben kann, sondern die, die ihn zuerst sieht. Dazu kommt der Termin. Abrechnungs- und Bilanzierungstermine stehen fest und verschieben sich nicht, weil eine Lieferung unvollständig war, also wird die Lücke unter Zeitdruck von Hand geschlossen und der Anlass wandert nicht in die Ursachenbehebung, sondern in die nächste Runde. Fragt die interne Revision oder ein externer Prüfer nach Vollständigkeit und Fehlerbehandlung, wird die Antwort aus Protokollen rekonstruiert. Das bindet Entwicklungszeit, die niemand eingeplant hat, und erzeugt Antworten, die in der nächsten Prüfung erneut erarbeitet werden müssen, weil sie nirgends verankert sind. Nachrechnen lässt sich das am letzten Lauf. Zählen Sie die verworfenen Sachverhalte, die Stellen, die davon erfahren haben, und die Vorgänge, die am Ende von Hand nachgezogen wurden.

Die tragfähige Reihenfolge im Vorhaben ist der Fehlerkatalog zuerst, dann die Protokollierungsdisziplin im Lauf, dann Kategorien und Lösungsprozesse, zuletzt das Monitoring. Wer sie umdreht und mit den Kategorien beginnt, richtet Bearbeiterkreise für Fehlerklassen ein, die noch nicht benannt sind.

Vorhaben und Stationen von Quellgrund Consulting stehen in den Referenzen.