Praxisbericht

Vibe Coding trifft auf SAP S/4HANA

Die Fachabteilung ist der Entwickler. Wie ein Pflegewerkzeug für rund 140 Materialmerkmale entstand, gebaut mit Claude Code.

Hubert Strohmeier, STROWA GmbH

Rund 140 technische Merkmale beschreiben bei einem Industrieunternehmen ein einzelnes Bauteil, von den Massen bis zur Lieferform. In SAP S/4HANA liegen sie in der Materialklassifizierung. Damit die Pflege nicht zur Fehlerquelle wird, hat das Projektteam ein eigenes Erfassungswerkzeug gebaut, entwickelt im Vibe Coding mit Claude Code. Die Fachabteilung war dabei der «Entwickler».

Ausgangslage

Das Unternehmen fertigt technische Bauteile, häufig nach Kundenvorgabe und mit eigener Spezifikation. Jedes Bauteil wird in SAP als Materialstamm abgebildet. Was es technisch ausmacht, steht in der Materialklassifizierung, hier in einer Klasse mit rund 140 Merkmalen. Sie beschreiben Masse, Toleranzen und Werkstoffangaben des Bauteils, dazu die Lieferform. In SAP S/4HANA sind diese Merkmale die führende Quelle für die Produktion und alle Folgeprozesse.

Die SAP-Standardoberfläche zeigt sie als lange Liste, prüft ohne zusätzliches Beziehungswissen keine fachlichen Abhängigkeiten und rechnet keine Werte. Gebraucht wurde eine geführte Erfassung je Produktfamilie, mit Prüfung jeder Eingabe, berechneten Grössen und automatisch generierten Zeichnungen und Kostenkalkulationen. Aber SAP muss das führende System bleiben.

Ein Editor aus einer einzigen Datei

Das Ergebnis ist ein eigener Editor für die Materialspezifikation. Er besteht aus einer einzigen HTML-Datei auf dem SharePoint, die per Doppelklick im Browser läuft. Die Datei enthält das Regelwerk, die Vorlagen je Produktfamilie, die Zeichnungslogik und den PDF-Generator. Es gibt nichts zu installieren und nichts zu betreiben. Wer im Produktbaum eine Produktfamilie wählt, bekommt genau die Felder und Vorbelegungen dieses Bauteiltyps.

Editor, Reiter General Info mit einer Vorlage
Abbildung 1. Editor, Reiter General Info mit einer Vorlage.

Die eigentliche Arbeit steckt in den Feldregeln. Masse und Toleranzen werden mit Einheit und Vorzeichen erfasst, Abhängigkeiten zwischen Feldern sofort ausgewertet, abgeleitete Grössen automatisch berechnet. Ein Export nach SAP ist erst möglich, wenn alle Felder fehlerfrei und konsistent sind.

Zeichnungen, die live mitlaufen

Aus denselben Werten entsteht eine massstäbliche Bauteilzeichnung mit Draufsicht, Schnitt und 3D-Ansicht. Ändert sich ein Wert, ändert sich die Zeichnung. Die komplette Spezifikation lässt sich mit der Zeichnung als PDF ausgeben und mit dem Kunden teilen.

So läuft der Prozess

  1. Der Kunde liefert die Spezifikation für ein Bauteil.
  2. Die Fachabteilung erfasst die Werte im Editor über die passende Vorlage.
  3. Die konsistenten Daten gehen als Exportdatei über einen schlanken SAP-Report in die Klassifizierung des Materialstamms.
  4. Bei Änderungen wird der Stand aus SAP in den Editor geladen, gegen dieselben Regeln verprobt und zurückgeschrieben. Die Änderungsbelege in SAP halten jeden Schritt revisionssicher fest.

Wichtig ist, was der Editor bewusst nicht tut. Er hat keine eigene Datenbank, Arbeitsstände liegen nur als lokaler Entwurf beim Anwender, gültig ist allein der Stand in SAP.

Die Fachabteilung ist der Entwickler

Der Editor ist ohne klassisches Entwicklungsteam entstanden. Gebaut haben ihn die Fachabteilung des Unternehmens und Hubert Strohmeier von STROWA, mit Claude Code, dem KI-Entwicklungswerkzeug von Anthropic. Im Vibe Coding werden die Anforderungen in normaler Sprache formuliert, die KI schreibt den Code, das Team prüft das Ergebnis im Browser und im SAP-System und gibt die nächste Runde vor.

Die Fachabteilung kennt die Produkte, die Kundenspezifikationen und die Sonderfälle aus der Praxis. Sie hat die fachlichen Regeln vorgegeben und jede Version an echten Spezifikationen geprüft. Strohmeier hat die SAP-Seite eingebracht und die Entwicklung mit Claude Code gesteuert. Rückmeldungen kamen meist als Screenshot mit einer kurzen Beschreibung und waren in der nächsten Fassung umgesetzt. So ist das Werkzeug in kurzen Zyklen neben der eigentlichen Projektarbeit entstanden.

Drei Entscheide haben das Vorhaben getragen. Das Regelwerk lebt in einem Modell, nicht im Code. Die Merkmalsliste aus SAP und eine von Hand gepflegte Regeldatei werden zu einem Modell zusammengeführt, aus dem Oberfläche, Prüfung, Export und PDF abgeleitet werden. Ein neues Merkmal braucht keine Zeile Code, die Wertelisten pflegt die Fachabteilung selbst. Ein Prüflauf mit über 800 Kontrollen sichert jede Änderung automatisiert ab. Das SAP-Wissen bleibt beim Menschen. Welche BAPIs die Klassifizierung sauber schreiben und wie Änderungsnummern und Berechtigungen wirken, wurde vom Team vorgegeben und im SAP-System geprüft.

«Wir haben die Regeln direkt an echten Kundenspezifikationen ausprobiert und Fehler sofort korrigiert. Eine neue Anforderung war in kürzester Zeit in der nächsten Version umgesetzt. So werden Sonderfälle schon vorab erkannt und korrigiert, bevor sie in der Produktion hohe Kosten verursachen.»

Fachbereich des Kunden

Was es gekostet hat

Ein vergleichbares Werkzeug klassisch in SAP zu bauen, als Fiori-App mit den entsprechenden OData-Services, schätzt STROWA auf grösser 40 Personentage. Der Editor hat 5 Personentage gebraucht, läuft ohne zusätzliche SAP-Lizenz und ohne eigene Infrastruktur. Bei der Wartung wird der Unterschied grösser. Ein neues Merkmal heisst in der Eigenentwicklung Anpassungen in Backend, Oberfläche und Test plus Transport, im Editor ein Eintrag im Modell. Ein Releasewechsel von SAP berührt den Editor nicht, der Report nutzt nur Standard-BAPIs.

Was das für SAP-Anwender bedeutet

Die Geschichte ist kein Sonderfall einer einzelnen Branche. Fast jedes Unternehmen hat Stammdaten, die fachlich anspruchsvoll und in der SAP-Standardoberfläche mühsam zu pflegen sind. Bisher hiess die Antwort Excel mit Makros oder ein Entwicklungsprojekt, das sich für einen Fachbereich selten rechnet. Mit KI-gestützter Entwicklung entsteht eine dritte Möglichkeit. Ein Werkzeug, das genau zu einem Prozess passt, entsteht mit einem Aufwand von wenigen Tagen statt mehreren Monaten. Voraussetzung ist ein Team, in dem die Fachabteilung der Entwickler ist und jemand die SAP-Seite kennt. KI beschleunigt das Bauen deutlich, aber SAP-Verständnis, Prozesswissen und die Verantwortung für das Ergebnis bleiben beim Menschen.

≈ 140
Merkmale je Material
1
HTML-Datei, keine Installation
5 PT
statt grösser 40 bei klassischer Entwicklung
800+
automatische Prüfungen je Build
Hubert Strohmeier

Über den Autor. Hubert Strohmeier ist Inhaber der STROWA GmbH in Wangen-Brüttisellen bei Zürich und seit über 25 Jahren in SAP-Projekten unterwegs, als Berater, Projektleiter und Lösungsarchitekt.

Kontakt

Ein ähnliches Thema?

Technische Stammdaten, Klassifizierung oder ein Fachbereich, der mit der Standardoberfläche kämpft. Wir schauen es gemeinsam an.

Kontakt aufnehmen

Passende Leistungen