SAP-Business-Data-Cloud-Intelligent-Applications — deployen und erweitern
Stand 2026-09-25
Für Beraterinnen und Berater, die eine SAP-Business-Data-Cloud-Intelligent-Application auf Praktikerebene cadrieren, deployen oder erweitern müssen. Behandelt, was eine Intelligent Application von einem Data Product unterscheidet, die fünf von SAP angekündigten Fähigkeiten (People, Cloud ERP, Customer, Finance, Spend Intelligence) mit dem Hinweis, den aktuellen GA-Status zu prüfen, die echte Vorbedingung bereits provisionierter Data Products hinter dem von SAP genannten Vier-bis-sechs-Wochen-Aktivierungsfenster, die drei Stellen, an denen sich Erweiterungsarbeit konzentriert (Data Products, Geschäftsregeln, Joule-Erzählschicht), wie man die Zuordnungsbehauptung einer Erzählung gegen zugrunde liegende Daten und den Knowledge Graph validiert, Data Access Controls auf Anwendungsebene, sowie Capacity-Unit-Dimensionierung. Schließt mit der BDC-Zertifizierungslandschaft und drei Praktikerübungen.
Was Sie lernen
- Ein Data Product von einer Intelligent Application unterscheiden und erklären, wie SAP Letztere aus mehreren Ersterer zusammensetzt
- Die von SAP angekündigten oder ausgelieferten Intelligent Applications (People, Cloud ERP, Customer, Finance, Spend Intelligence) benennen und den GA-Status als auf dem Tenant zu verifizieren, nicht anzunehmen, behandeln
- Erklären, warum ein Aktivierungszeitplan davon abhängt, ob zugrunde liegende Data Products bereits provisioniert und agentenbereit sind
- Die drei Stellen identifizieren, an denen sich Erweiterungsarbeit konzentriert: zusätzliche Data Products, Geschäftsregeln/Schwellenwerte und die Joule-Erzählschicht
- Die narrative Ausgabe einer Intelligent Application gegen ihre zugrunde liegenden Data Products und Knowledge-Graph-Beziehungen validieren, statt sie ungeprüft zu akzeptieren
- Data Access Controls und Capacity-Unit-Dimensionierung beim Cadrieren einer Intelligent-Application-Aktivierung berücksichtigen
Für wen dieses Modul gedacht ist. Ihr Kunde hat den Begriff „Intelligent Application“ in einer Sapphire-Zusammenfassung oder einem Partner-Pitch gehört und will wissen, was das tatsächlich ist, was es braucht, um eine zu deployen, und ob sie für seinen spezifischen Prozess erweitert werden kann. Dieses Modul ist eine Praktikerantwort: keine Marketing-Tour, sondern woraus eine Intelligent Application gebaut ist, das echte Vorbedingung, die entscheidet, ob eine Aktivierung Wochen oder Quartale dauert, und wo die Erweiterungsarbeit eines Beraters tatsächlich stattfindet.
1. Was eine Intelligent Application tatsächlich ist
SAP definiert Intelligent Applications als „vorgefertigte, komponierbare Anwendungen, die vertrauenswürdige Data Products, KI-Fähigkeiten und Geschäftssimulationen nahtlos integrieren“ — konzipiert, um „traditionelle Analytik zu übersteigen, indem Arbeit über analytische und transaktionale Workflows hinweg automatisiert und orchestriert wird“. Die festzuhaltende Unterscheidung: Ein Data Product (M343 behandelt dies im Detail) ist ein einzelnes, gesteuertes Geschäftsobjekt — Rechnungen, Kopfzahl, Lieferungen. Eine Intelligent Application ist darüber gebaut, aus mehreren Data Products zusammengesetzt mit KI- und Simulationslogik zu einem benannten, für Führungskräfte gedachten Liefergut. SAPs eigene Sprache ist explizit: Data Products sind das Fundament und Intelligent Applications das, was daraus gebaut wird — nicht zwei Namen für dieselbe Schicht.
Voraussetzungen
- M343 (SAP-Business-Data-Cloud-Data-Products für KI-Agenten) oder gleichwertiges Verständnis von Data Products und ihren Governance-Metadaten
- Praktische Vertrautheit mit dem Katalog von SAP Business Data Cloud und der Knowledge-Core-Positionierung (C009, C263)
- Grundlegendes Verständnis von Joule als natürlichsprachlicher Schnittstelle (C024)
Lernergebnisse
- Eine benannte Intelligent Application in die Data Products zerlegen, die sie verbindet, und die Bereitschaft jedes einzelnen beurteilen.
- Einen ehrlichen Zwei-Szenario-Aktivierungszeitplan schreiben, der provisionierte von noch nicht provisionierten Data-Product-Fällen unterscheidet.
- Eine realistische Erweiterung (Data Product, Schwellenwert oder Erzählung) vorschlagen und die dafür nötige Governance- und Knowledge-Graph-Arbeit benennen.
- Die Zuordnungsbehauptung einer Erzählung gegen den Knowledge Graph validieren, statt flüssige Sprache als Beweis zu akzeptieren.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.