Zum Inhalt springen

Blog für S/4HANA, SAP BTP, OpenText, E-Rechnung und Neptune

FINK IT-Solution Logo
Menü
header

SAP Build Apps: Low-Code ERP Apps mit Fiori-UX – in Tagen zum Prototyp, ohne Clean Core zu gefährden

SAP Build Apps
Schlagwörter:

Einleitung

Dein Fachbereich will endlich Ergebnisse bei Apps mit SAP. Die IT will Stabilität. Der Chef will AI -Einsatz. Und irgendwo dazwischen liegt die Realität: Prozesse hängen, weil „die kleine App“ für Genehmigungen, Status oder Datenerfassung nie priorisiert wird – oder weil sie als Shadow-IT-Lösung entsteht und später teuer zurückgebaut werden muss. SAP Build Apps ist genau für diesen Spagat gemacht: Low-Code auf der SAP BTP, schnell genug für Prototypen in Tagen, aber so aufsetzbar, dass Governance, IT-Security und Clean Core nicht über Bord gehen. SAP positioniert SAP Build (inkl. Build Apps) als Suite für App-, Prozess- und Workplace-Erweiterungen mit Governance- und AI-Unterstützung. Und es hat endlich einen guten Reifegrad!

Warum lohnt es sich, weiterzulesen? Du bekommst ein praxistaugliches How-to, wie du als Anforderer für eine SAP App ein Mockup erzeugst, daraus einen klickbaren Prototypen baust und ihn sauber in Richtung Produktivbetrieb entwickelst.

Inhaltsverzeichnis

1. Was ist SAP Build Apps – und was heißt „SAP ERP-Apps“ in der Praxis?

SAP Build Apps ist ein Low-Code-App-Builder auf der SAP BTP, mit dem du Web- und Mobile-Apps per Drag-and-drop erstellst, Logik über Variablen und Flows abbildest und Datenquellen (z. B. OData/REST) konsumierst.
„SAP ERP-App“ heißt dabei meist nicht „S/4 neu bauen“, sondern: eine fokussierte SAP-Oberfläche, die einen Engpass löst – schnell, messbar, prüfbar.

Typische ERP-nahe Use Cases mit SAP Build Apps:

  • Antrag + Freigabe (Sonderpreis, Invest, Stammdatenänderung, Abweichungsfreigabe)
  • Status & Monitoring (Aufträge, Lieferungen, Bestände – „wo hängt’s?“)
  • Mobile Datenerfassung (Werk, Lager, Außendienst: Foto, Kommentar, Checklisten)

Was SAP Build Apps bewusst nicht ersetzen soll:

  • große, stark verzweigte Business-Logik, komplexe Integrationsorchestrierung oder Engineering-intensive Produktentwicklung (dafür sind Pro-Code-Stacks wie UI5/CAP/ABAP sinnvoller)

Überblick:

SAP Build Apps ist ein Low-Code-Tool auf der SAP BTP, mit dem Fachbereiche und IT schnell Web- und Mobile-Apps erstellen und über standardisierte Schnittstellen (z. B. OData/REST) an SAP-Backends anbinden. Mit klaren Governance-Leitplanken bleibt die Erweiterung upgradefähig und clean-core-konform.

2. Mockup mit KI: Als Anforderer reinsprechen → klickbarer Prototyp (How-to)

Wenn du Geschwindigkeit willst, musst du die „Anforderungsschleife“ verkürzen. Der schnellste Weg ist: Voice → KI → Screen Map → Prototyp.

Schritt 1: 3-Minuten-Voice Note (mit klarer Vorlage)

Der Anforderer spricht eine kurze Voice Note ein (Handy reicht). Du gibst vorher diese Leitfragen vor:

  1. Rolle: Wer nutzt die App? (z. B. Einkäufer, Meister, Sachbearbeitung)
  2. Ziel: Was soll nach 2 Minuten Nutzung besser sein?
  3. Daten: Welche Felder müssen gesehen/erfasst werden?
  4. Entscheidung: Welche Aktion folgt? (Genehmigen, Ablehnen, Rückfrage, Speichern)
  5. Erfolgskriterium: Wann ist der Use Case „fertig“?

Voice-Template (zum Vorlesen):
„Ich bin [Rolle]. Ich brauche eine App, um [Ziel]. Ich muss sehen/ändern: [Felder]. Danach will ich [Aktion]. Fertig ist es, wenn [Kriterium].“

Schritt 2: KI macht daraus User Stories + Screens + offene Fragen

Du transkribierst die Voice Note (Meeting-Tool/Smartphone/Intern). Dann gibst du der KI eine strukturierte Aufgabe:

Prompt (1:1 verwendbar):
„Erstelle aus dem folgenden Text:
(1) 7–12 User Stories im Format Als [Rolle] will ich [Ziel], damit [Nutzen],
(2) eine Screenliste mit Reihenfolge (User Journey),
(3) pro Screen: Felder, Pflichtfelder, Validierungen, Buttons/CTAs,
(4) eine Liste offener Fragen,
(5) Risiken: Berechtigungen, Datenschutz, Clean Core, Integrationen.
Text: …“

Schritt 3: „Low-Fidelity“-Entwurf in 15 Minuten

Jetzt baust du bewusst low fidelity: Liste, Detail, Formular, Bestätigung.
Optional: Lass die KI Layouts als Text skizzieren:

Prompt:
„Skizziere für jeden Screen ein Layout als Liste: Header, Filter, Liste, Detailfelder, Primary CTA, Secondary CTA, Fehlermeldungen.“

Schritt 4: Klickbarer Prototyp in SAP Build Apps (zuerst ohne Backend)

Der Trick ist: erst Interaktion validieren, dann Integration.

  1. Neues Projekt in SAP Build Apps anlegen.
  2. Screens erstellen (Inbox → Detail → Formular/Kommentar → Success).
  3. Mock-Daten als lokale Collection/JSON anlegen.
  4. Navigation + Validierungen bauen (Pflichtfelder, einfache Regeln).
  5. Demo-Skript definieren: 3 Minuten, 1 Happy Path, 1 Fehlerfall.

Praxis-Tipp: Wenn dein Team „schnell in die Plattform reinfinden“ muss, sind kurze Hands-on-Tutorials Gold wert. Das Fink-ITS Tutorial „in einer Stunde zur eigenen Low-Code-App“ ist dafür ein guter Ramp-up. Frag uns!

3. Praxisbeispiel 1: „Freigabe-App“ in 48 Stunden – von Voice Note bis Demo

Use Case: Einkauf muss Sonderpreis-Anfragen freigeben. Heute: E-Mail + Excel + Rückfragen.

Tag 1 (Vormittag): Voice → KI → Ablaufplan

Voice Note vom Teamlead Einkauf (3 Minuten) ergibt:

  • Ziel: „Offene Anfragen als Inbox sehen, Details prüfen, genehmigen/ablehnen mit Kommentar.“
  • Pflichtfelder: Kunde, Material, Zielpreis, Menge, Gültigkeit, Begründung, Status
  • Rollen: Sales (Antragsteller), Einkauf (Approver), Controlling (Viewer)

KI liefert:

  • 9 User Stories
  • Screens: Inbox / Detail / Kommentar / Entscheidung / Bestätigung
  • Offene Fragen: „Ab welchem Rabatt braucht es 2. Genehmiger?“, „Welche Felder sind vertraulich?“

Tag 1 (Nachmittag): Prototyp in SAP Build Apps (ohne Backend)

In SAP Build Apps baust du:

  • Inbox als Liste, Filter „Status = offen“
  • Detailansicht: read-only Felder + Kommentar
  • Buttons: „Genehmigen“ / „Ablehnen“
  • Statuswechsel schreibt in Mock-Collection

Ergebnis: Klickbarer Prototyp, der den Prozess fühlbar macht.

Tag 2: „Backend light“ – Integration nur über freigegebene Schnittstellen

Jetzt erst klärst du: Welche API ist freigegeben? Welche Rollen? Welche Logs?
Für die technische Anbindung (wenn vorhanden) nutzt du OData/REST und eure freigegebenen Destinations. Community-Beispiele zeigen, wie OData-Daten in Build Apps angezeigt werden können.

4. Praxisbeispiel 2: „Änderungsantrag Materialstamm“ – von Prototyp zu produktivfähig

Use Case: Produktion meldet Materialstamm-Korrekturen (Kurztext, Verpackung, Einheit). Heute: Tickets, unvollständig, Rückfragen.

Phase 1: Prototyp (Tempo im Fachbereich)

In SAP Build Apps:

  • Screen „Neuer Änderungsantrag“: Materialnummer, Feld, neuer Wert, Begründung, Foto optional
  • Validierung: Materialnummer Pflicht, Begründung min. 20 Zeichen, Feld nur aus Dropdown
  • Status: Entwurf → Eingereicht → In Prüfung → Umgesetzt

Phase 2: Produktivfähig machen (Freigabe- und Qualitätsstufe)

Jetzt stellst du um von „schnell“ auf „sauber“:

  • Datenzugriff nur über freigegebene Schnittstellen
  • Rollen/Berechtigungen zentral
  • Audit/Logging: Wer hat was wann beantragt und entschieden?

Technisch sind auch Schreiboperationen (z. B. POST) möglich – Community zeigt Wege, OData-POSTs in Build Apps auszuführen. Genau hier ist Governance Pflicht: Schreibrechte, Validierung, Audit, Fehlerfälle.

5. Governance, die nicht bremst: Leitplanken für Citizen Development

Low-Code scheitert selten an der Technik – meist am Operating Model. Du brauchst keine Bürokratie. Du brauchst Leitplanken.

Minimal-Rollenmodell

  • Citizen Developer (Fachbereich): baut Screens/Flows im Rahmen
  • Product Owner (Fachbereich): verantwortet Nutzen & Prioritäten
  • BTP/IT Platform Owner: Identitäten, Rollen, Destinations, Policies
  • Security/Compliance: Review vor Produktiv

10 Leitplanken, die wirklich funktionieren

  1. App-Katalog: Owner, Zweck, Datenklassifizierung, Status (Prototyp/Produktiv)
  2. Freigegebene Datenquellen: nur approved Destinations/APIs
  3. Standardrollen: Viewer/Editor/Approver (Role Collections)
  4. Produktiv-Freigabe („Go-Live Check“): Security, Datenschutz, Logging, Ownership
  5. Vorlagen: Naming, Error Handling, UI-Patterns
  6. Wiederverwendung: Komponentenbibliothek (Fiori-nah)
  7. Monitoring: Fehler, Nutzung, Latenz (minimal, aber konsequent)
  8. KI-Regel: KI-Output wird geprüft (besonders bei Logik & Zugriff)
  9. Prototyp klar kennzeichnen (Mock-Daten, keine „heimliche Produktiv-App“)
  10. „CoE light“: kleines Team für Enablement + Standards

6. Clean Core sichern: Architektur-Standards für SAP Build Apps

Clean Core heißt: Erweiterungen so bauen, dass Upgrades nicht zur Dauerbaustelle werden. SAP beschreibt den Clean-Core-Ansatz und Extensibility-Modelle (inkl. Side-by-Side) als Best Practice, um Erweiterungen upgradefähig zu halten.

3 Architektur-Standards:

  1. Side-by-Side auf BTP: App lebt in der Extension-Schicht, nicht im Kern
  2. Released APIs / Extension Points statt Abkürzungen
  3. Entkopplung: keine „Businesslogik in 30 UI-Formeln“, sondern klare Schnitte

7. Joule/KI nutzen, ohne sich Risiken einzukaufen

AI beschleunigt – und verstärkt Fehler, wenn du sie ungeprüft übernimmst. SAP beschreibt Joule for Developers als Assistenz für Entwickler (u. a. Unterstützung bei Modellen, Logik, UI und Tests in passenden SAP-Entwicklungsumgebungen).

So setzt du KI pragmatisch ein:

  • KI für den „Tempo-Layer“: Screen-Varianten, Formeln, Texte, Dummy-Daten
  • Vier-Augen-Prinzip: Datenzugriff, Rollen, Business-Regeln immer reviewen
  • Prompt-Policy: keine sensitiven Daten in Prompts
  • Definition of Done: „KI-Output geprüft“ als Check

8. Nächste Schritte

Wenn du SAP Build Apps im Fachbereich etablieren willst, nimm dir 2 Wochen:

  • Woche 1: 2 Use Cases, Voice → KI → Mockup → Prototyp in SAP Build Apps
  • Woche 2: Leitplanken + Produktiv-Check + „Prototyp→Produktiv“-Pfad definieren

Weiterführend (Hands-on, Team-Ramp-up):

  • Fink-ITS: „SAP Build Apps Tutorial 2025: In einer Stunde zur eigenen Low-Code App“
  • (Optional ergänzend) SAP Build Apps allgemeine Einordnung / Produktkontext: SAP Build Suite

Weitere Informationen:

9. Fazit

SAP Build Apps ist der Sweet Spot, wenn Fachbereiche schnell ERP-nahe Apps brauchen – und die IT trotzdem sauber bleiben will. Der Hebel ist ein klarer Ablauf: Voice → KI → Screen Map → Prototyp → Produktiv-Check → Integration. Mit Governance-Leitplanken und Clean-Core-Standards (Side-by-Side, released APIs) bekommst du Tempo ohne Upgrade-Risiko.

10. FAQ

Wo ist der Unterschied zwischen SAP Build Apps und SAP Fiori?

– die Technologiewelt um SAPUI5/Fiori Elements. SAP Build Apps ist ein Low-Code-Werkzeug, mit dem du Apps baust, die sich Fiori-nah gestalten und ins Launchpad integrieren lassen, aber nicht automatisch „klassische Fiori-Apps“ (UI5/Fiori Elements) sind.

Praktisch:

  • SAP Build Apps: ideal für schnelle Prozess-Apps, Prototypen, Citizen Development (mit Leitplanken)
  • Fiori Elements / UI5: ideal, wenn du maximal SAP-nah, standardisiert, engineering-getrieben und langfristig skalierbar bauen willst

Merksatz: Build Apps ist wie du schnell baust. Fiori ist wie es sich für den User anfühlt (und oft womit es im klassischen SAP-Stack gebaut wird).

Wo ist der Unterschied zwischen SAP Build und Neptune DXP?

SAP Build ist SAPs Suite auf der SAP BTP (u. a. Build Apps, Process Automation, Work Zone, teils Pro-Code-Bausteine) – also „SAP-native“ im Plattform-Ökosystem mit Fokus auf Integration, Governance und Erweiterbarkeit.
Neptune DXP ist eine eigenständige Digital-Experience-Plattform eines Drittanbieters, die ebenfalls Low-Code/No-Code-Ansätze anbietet und häufig als zusätzlicher UI-/Experience-Layer um SAP-Systeme herum eingesetzt wird.

Entscheider-Sicht in 4 Punkten:

Lock-in: Bei SAP Build bindest du dich stärker an SAP-BTP; bei Neptune an einen Drittanbieter-Stack.

Plattform-Nähe: SAP Build ist BTP-integriert; Neptune ist ein zusätzlicher Stack (Runtime/Tooling).

Governance/ALM: SAP Build passt oft einfacher in SAP-CoE/BTP-Governance; Neptune braucht Governance als eigener Layer.

Skillset: SAP Build bleibt stärker im SAP-Ökosystem; Neptune erfordert stärkeres Tool-/Vendor-Spezialwissen.

Kann ich mit SAP Build Apps ohne IT starten?

Für Mockups/Prototypen mit Mock-Daten: ja. Für produktive Datenanbindung brauchst du Plattform-Setup (Destinations, Rollen, Policies) und einen Produktiv-Check.

Wie schnell ist ein klickbarer Prototyp realistisch?

Mit Voice-Vorlage, KI-Strukturierung und Mock-Daten oft 1–2 Tage (Inbox/Detail/Formular + Navigation + Validierungen). Die Produktivierung hängt an Leitplanken, Datenfreigabe und Security.