Grensing

Business Technology Consulting GmbH

Ist BRF+ gescheitert? Über intelligente Arbeitsorganisation im SAP-Projekt

2017-02-12

Seit geraumer Zeit ist ein Tool Bestandteil des SAP NetWeaver Stacks - und damit auch Bestandteil jedes SAP ECC Systems, mit dessen Hilfe sogenannte Business Rules modelliert und in die Anwendungsfunktionalität eingebettet werden können: das Business Rule Framework BRF+.

Dies funktioniert so, dass in BRF+ die Business Rules z.B. als Formeln, Entscheidungsbäume oder Entscheidungstabellen angelegt werden und das Tool dann ABAP-Code generiert, mit dem man an der gewünschten Stelle - also in eigenen Anwendungen oder in User-Exits in der Standardabwicklung - die Business Rules aufrufen und abarbeiten kann.

Wer lange mit SAP Software arbeitet, kennt sicherlich die Konditionstechnik aus der Preisfindung oder der Nachrichtenverarbeitung. BRF+ ist ein verallgemeinertes und noch viel mächtigeres Werkzeug, um ähnliche Funktionalitäten kundenspezifisch aufzubauen. Von daher ist es nur logisch, dass seit einem der letzten Release Packages in ECC BRF+ in der Preisfindung genutzt werden kann und in S/4-HANA die Nachrichtenfindung komplett auf BRF+ umgestellt wird.

BRF+ hat den Anspruch dem Anwender die Möglichkeit zu geben, in einer sich ständig wandelnden Umwelt Regeln und damit Systemfunktionalität selbständig anzupassen, ohne dass es dazu Programmieraufwand bedarf.

Das klingt erst einmal wie ein mächtiges Versprechen und entsprechend groß war meine Neugier, BRF+ zu diesem Zweck zu nutzen.

Als aus einer anderen Ecke das Gerücht kam, mit BRF+ könne man Z-Tabellen ersetzen, wurde in einem größeren Projekt die Entscheidung getroffen, wo es sinnvoll ist, grundsätzlich BRF+ für kundeneigene Logiken zu nutzen. Weil: es wird weniger programmiert, BRF+ ist Konfiguration, die Lösung wird transparenter und der Entwicklungsaufwand wird enorm reduziert.

Das Ergebnis war ein wenig ernüchternd: die meisten funktionalen Experten sahen es schlicht und einfach nicht als ihr Tool an und schrieben lediglich in ihre funktionale Spezifikation hinein, dass anstatt Z-Tabellen bitteschön BRF+ zu nutzen ist. Resultat: die outgesourcten Programmierer durften sich auf Kundenkosten in ein neues Tool einarbeiten und hatten einen neuen Skill in ihrer CV-Datenbank. Dazu kamen jede Menge Verständnisprobleme über die Toolphilosophie (Nein, man kann keine Million Artikeldatensätze in eine BRF+-Entscheidungstabelle packen.....).

Ok. So war es nicht gedacht, aber ok, denn:

es ist ja jetzt kein Code mehr notwendig, sondern nur noch Konfiguration?

Ganz richtig ist das nicht, denn die BRF+-Logik muss mit einem generierten Wrapper-Code aufgerufen werden. Und je nach User-Exit/BADI müssen da u.U. noch eigene Anpassungen und Konvertierungen gemacht werden. Wenn das in SAPMV45A-PREPARE_BEFORE_SAVE 15 mal passiert, ist von der Transparenz nicht mehr viel übrig.

Dazu kommt, dass eine einmal erstellte BRF+-Anwendung für einen Außenstehenden relativ schwierig zu "lesen" ist und es etwas Einarbeitungszeit benötigt, eine fremde Anwendung zu verstehen. Das kann da zum Problem werden, wo von Beratern komplexere BRF+-Anwendungen erstellt werden, die dann von einem Support-Team übernommen werden müssen, die dieser Technologie noch nicht ausreichend mächtig sind.

Waren die Programmierer in BRF+ wenigstens effizienter als in ABAP?

Das darf ernsthaft bezweifelt werden.

Jetzt mal ein bisschen ökonomisches Denken und etwas Arbeitsorganisation: im Normalfall sind ABAP-Programmierer günstiger als Funktionsexperten. Warum um Himmels Willen sollen wir dann ein Tool einsetzen, das Aufgaben von günstigen auf teurere Ressourcen verlagert? Ich kann mir eigentlich nur zwei Fälle vorstellen, in denen dies wirklich sinnvoll ist:

  • durch einen hausgemachten Fixkostenblock ("es ist nicht erwünscht, dass programmiert wird. Deswegen wird jede Änderungsanforderung sechs Wochen geprüft.") können bestimmte Anforderungen nur durch konfigurierbare Logik zeitnah umgesetzt werden. Dann gibt es aber auch einen funktionalen Experten (vor Ort), der das beherrscht.
  • bestimmte Logiken sind hochkomplex und hochflexibel und werden von einem dedizierten Team aus Funktionsexperten betreut.

Ansonsten bleibt für mich die Lehre:

  • lediglich Z-Tabellen zu ersetzen, in dem die Kundenlogik einfach mit einem anderen Tool gebaut wird, bringt keine Vorteile. Ich sehe daher auch keinen Grund, solch eine Richtlinie im Projekt zu erlassen.
  • BRF+ kann seine Stärken da ausspielen, wo Regeln wirklich komplex und flexibel sein müssen und die Einbettung in die Standardfunktionalität problemlos möglich ist. Einfacher als in ABAP wird es dadurch jedoch nicht unbedingt.
  • ABAP ist eine 4GL-Programmiersprache. Diese wurden bei ihrer Erfindung in den achtziger und neunziger Jahren des letzten Jahrhunderts damit begründet, dass es mit ihnen möglich ist, dass Anwendungsfunktionalität durch funktionale Experten anstatt durch Programmierer definiert werden könne. Wie wir heute sehen, hat dies nicht funktioniert.
  • BRF+ ist eine eigene Technologie innerhalb der SAP-Welt. Kann ich in meinem Unternehmen (z.B. aufgrund seiner Größe oder aufgrund der Fähigkeiten meiner Dienstleister) nicht die langfristige Wartbarkeit und Konfigurierbarkeit von BRF+-Funktionalitäten sicherstellen, darf ich dieses Tool nicht benutzen.

Oder aber:

  • Innerhalb der SAP-Welt wird die Wichtigkeit des Business Rule Frameworks in Zukunft zunehmen, denn jedes Unternehmen hat Bereiche, in denen komplexe Regelwerke das Unternehmensgeschehen steuern. Deswegen ist es um so wichtiger, diese Technologie jetzt zu erlernen und einzusetzen. Anwender und Funktionsexperten müssen frühzeitig geschult werden und die Philosophie, Fähigkeiten und die Möglichkeiten eines solchen Werkzeugs müssen kreativ und nutzenbringend erforscht werden. Nicht als neues Tool für Programmierer sondern als neues Tool für Ihr Unternehmen.
  • Beim Design des Einsatzes von BRF+ ist die richtige Anwendungsarchitektur entscheidend. Damit eben nicht 15 BRF+-Applikationen beim Speichern des Kundenauftrags durchlaufen werden, sondern nur eine. Kompetente Beratung ist damit für den Erfolg ausschlaggebend.

Gestalten Sie Ihren Erfolg!

P.S.: Aufgrund der SAP-Systemphilosophie ist der Bereich, in dem für mich in der Zukunft BRF+ am wichtigsten sein wird, die Generierung und Validierung von Stammdaten. Die Komplexität in diesem Bereich wird mit Sicherheit nicht abnehmen. BRF+ hat hier riesiges Potenzial!