Alle Kapitel aufklappen
Alle Kapitel zuklappen
A Single Worked Example, Followed Throughout
29
PART I Technical Context and Integration Principles
31
1 Why Enterprise Architecture and Business Process Architecture Data Must Be Integrated for AI Execution
33
1.1 The Structural Failure of Most Transformation Programs
34
1.1.1 Design, Delivery, Telemetry, and Improvement
34
1.1.2 The Enterprise Execution Pyramid
35
1.1.3 Why AI Amplifies Both Coherence and Fragmentation
36
1.2 Limitations of Isolated Process Repositories
37
1.3 Limitations of Isolated Enterprise Architecture Repositories
39
1.3.1 Architecture Without Execution Semantics
39
1.3.2 Middleware Drift and Disconnected Integration Logic
40
1.3.3 Architecture Describes Systems; Process Describes Execution
40
1.4 Why SAP AI Requires Unified Semantic Context
41
1.4.1 SAP AI Is Layered, Not Monolithic
41
1.4.2 What Each Layer Requires from the Semantic Foundation
42
1.4.3 The Specific Requirements of Generative and Agentic AI
43
1.4.4 AI Grounding Bundles and the Role of the Canonical Layer
43
1.5 The Role of SAP BTP as the Data Spine, Integration Layer, and Extension Layer
44
1.5.1 Three Architectural Roles of SAP BTP
44
1.5.2 Why Canonical Semantics Live on SAP BTP
45
1.5.3 Validation, Publication, and the Role of Boundary Enforcement
46
1.5.4 SAP BTP as the Coordinator of the Design-to-Delivery Loop
46
1.6 Non-Goals: What AI Must Not Automate
46
1.7.1 Key Learning Points
48
1.7.2 Common Design Pitfalls
49
1.7.3 Review Questions
50
1.7.4 Student Companion Notes
50
2 Reference Integration Architecture
53
2.1 Logical Architecture Overview
54
2.2 Authoritative Systems of Record
56
2.3 Data Ownership and Write Boundaries
57
2.3.1 The Three Write Boundary Rules
58
2.3.2 Why Boundary Enforcement Cannot Be Conventional
59
2.3.3 Worked Example: Tracing a Cost Center Update Across the Architecture
59
2.4 Integration and Extension Responsibilities
60
2.5 Execution and Consumption Layers
62
2.6 Security Architecture Principles for Process- and AI-Driven Integration
64
2.7 Identity, Authentication, and Authorization in SAP Signavio, SAP LeanIX, and SAP BTP
66
2.8 Data Access Segmentation and Role-Based Exposure of the Data Spine
69
2.8.1 Three Dimensions of Segmentation
69
2.8.2 Segmentation in the Token
69
2.8.3 Segmentation for AI Consumers
69
2.8.4 The Scope Vocabulary in Practice
70
2.9 Security Boundaries Between Execution Services, AI Services, and User Interfaces
71
2.10 Auditability, Traceability, and Non-Repudiation by Design
71
2.11 Allocation of Security Responsibilities Across Platforms
73
2.12.1 Key Learning Points
76
2.12.2 Common Design Pitfalls
77
2.12.3 Review Questions
78
2.12.4 Student Companion Notes
78
PART II Configuring SAP Signavio for Execution and AI Readiness
81
3 SAP Signavio Data Model for Integration
83
3.1 L4 and L5 Process Object Requirements
84
3.1.1 L4 Process Step Objects
85
3.1.2 L5 Work Instruction Objects
86
3.1.3 Digital Discovery Assessment as the Source for L4
87
3.2 Process and Activity Identifiers
87
3.2.1 The Identifier Standard
88
3.2.2 Immutability and Renaming
90
3.2.3 Identifier-to-System Mappings
91
3.3 Mandatory Execution Attributes
92
3.3.4 Application Reference
94
3.3.6 Data Objects In and Out
94
3.3.7 Key Performance Indicator Anchor
95
3.4 Roles, Variants, and Localization
95
3.4.1 The Six-Role Taxonomy
96
3.4.2 Swimlane Discipline
98
3.4.3 Variant Classification
98
3.4.4 Localization Markers
100
3.5 Versioning and Lifecycle Management
101
3.5.1 The Version State Machine
101
3.5.2 Change Rules: Major, Minor, Patch, and Variant
102
3.5.3 The Digital Thread: DDA to BPMN to Runtime
103
3.6 What Must Not Be Modeled in SAP Signavio
105
3.7.1 Key Learning Points
110
3.7.2 Common Design Pitfalls
111
3.7.3 Review Questions
112
3.7.4 Student Companion Notes
112
4 Extending SAP Signavio for Downstream Consumption
115
4.1 Standard Attributes Versus Custom Attributes
116
4.1.1 The Role of Attributes in an Integration-Ready Process Model
116
4.1.2 Standard Attributes: What They Cover and Where They Stop
117
4.1.3 A Disciplined Custom Attribute Strategy
118
4.1.4 Naming Conventions and Dictionary Management
119
4.1.5 Common Pitfalls in Attribute Design
121
4.1.6 Attribute Scoping: Process, Activity, Lane, and Workspace
121
4.1.7 Data Types and Controlled Enumerations
122
4.1.8 Worked Example: Custom Attributes Across Three Process Domains
123
4.2 External Reference Patterns
124
4.2.1 Defining an External Reference
124
4.2.2 Why URL-Based Linking Is Avoided
125
4.2.3 Reference Patterns by Target System
125
4.2.4 Multi-Valued and Qualified References
127
4.2.5 Governance of References Across Lifecycles
127
4.3 Preparing SAP Signavio APIs for Extraction
128
4.3.1 The SAP Signavio API Landscape
129
4.3.2 Authentication, Tokens, and Service Identities
129
4.3.3 Endpoint Inventory for Spine Ingestion
130
4.3.4 Scoping and Permissioning
131
4.3.5 Rate Limits, Pagination, and Backoff
131
4.3.6 Schema Versioning and Compatibility Discipline
133
4.3.7 Sample API Calls and Response Handling
133
4.3.8 Calling SAP Signavio APIs: SAP Integration Suite Versus Direct from SAP BTP
135
4.3.9 Operational Telemetry for the Extraction Flow
136
4.4 Event Versus Batch Export Considerations
136
4.4.1 Two Patterns, Two Failure Modes
136
4.4.2 Batch Export Design
137
4.4.3 Event-Driven Export Design
138
4.4.4 Reconciliation Between Event and Batch Exports
139
4.4.5 Decision Heuristics: Choosing the Right Pattern
139
4.4.6 Worked Example: A Reconciliation Cycle
140
4.4.7 Failure Handling and Operational Runbooks
141
4.5 Validation and Data Quality Checks
142
4.5.1 Where Validation Runs in the Extension Contract
142
4.5.2 Categories of Validation Checks
143
4.5.3 Severity Levels and Outcome Handling
144
4.5.4 Quarantine Versus Reject: Handling Bad Records
144
4.5.5 Closing the Loop with Modeling Teams
145
4.5.6 Worked Example: Validating an Execution-Ready Activity
146
4.5.7 Quality Scoring as a Leading Indicator
147
4.5.8 Worked Example: Validation Across a Process Variant
148
4.5.9 Auditability of the Validation Layer
149
4.6.1 Key Learning Points
150
4.6.2 Common Design Pitfalls
151
4.6.3 Review Questions
151
4.6.4 Student Companion Notes
152
PART III Configuring SAP LeanIX for Dependency and Context Data
153
5 SAP LeanIX Data Model for Integration
155
5.1 The Running Scenario: Cost Center to Position
157
5.2 Application Objects Required for Integration
158
5.2.1 The Integration-Eligible Application
159
5.2.2 The Mandatory Attribute Set
159
5.2.3 Application Versus IT Component
161
5.2.4 Worked Anatomy of an Application Factsheet
161
5.2.5 The Application Inventory Discipline
162
5.2.6 Application Factsheet: Build Specification
163
5.3 Interface and Dependency Modeling
168
5.3.1 What Belongs on an Interface Factsheet
168
5.3.2 Dependency Modeling and Chains
170
5.3.3 Worked Example: Cost Center to Position
171
5.3.4 Hub Interfaces and the Limits of Direct Modeling
172
5.3.5 Interface Factsheet: Build Specification
173
5.4 Lifecycle and Change-Related Attributes
177
5.4.1 The Five-Phase Lifecycle Model
178
5.4.2 The Two Approval Flags
179
5.4.3 Lifecycle Transitions as Governance Events
179
5.4.4 Beyond Phases: Other Change-Related Attributes
180
5.4.5 Phase-to-Consumer Visibility Matrix
181
5.4.6 Lifecycle Attribute Set: Build Specification
182
5.5 Stable Identifiers and Keys
184
5.5.1 The factSheetId as a Primary Key
185
5.5.2 External Identifiers as Resolvable References
186
5.5.3 Identifier Changes as Governance Events
187
5.5.4 Binding Identifiers to Activities
187
5.5.5 SAP Fiori App ID as a Secondary Identifier
188
5.5.6 Identifier Set: Build Specification
189
5.5.7 Cross-Chapter Field Name Glossary
191
5.6 Avoiding Overlap with SAP Signavio
196
5.6.1 The Division of Responsibility
197
5.6.2 Anti-Patterns and Their Costs
198
5.6.3 Worked Example: Boundary: Cost Center to Position Propagation
200
5.7.1 Key Learning Points
204
5.7.2 Common Design Pitfalls
205
5.7.3 Review Questions
206
5.7.4 Student Companion Notes
207
6 Mapping SAP LeanIX to Process Semantics
209
6.1 Linking Applications to L4/L5 Activities
211
6.1.1 The LEANIX|APPLICATION Reference
211
6.1.2 Cardinality and the Single-Execution Location Rule
213
6.1.3 Activity_Stable_ID as the Owner of the Binding
215
6.1.4 Resolution at Lookup Time, Not at Binding Time
215
6.1.5 Worked Example: Cost Center to Position Application Bindings
216
6.2 Interface-to-Process Relationships
217
6.2.1 The LEANIX|INTERFACE Reference
218
6.2.2 Role Tag Semantics
219
6.2.3 Hub Interfaces and Two-Sided Bindings
220
6.2.4 The Activity-Level Data Flow Statement
221
6.2.5 Worked Example: Cost Center to Position Interface Bindings
222
6.2.6 What the Interface Binding Does Not Carry
223
6.3 Capability and Domain Alignment
224
6.3.1 The Capability Map in SAP LeanIX
224
6.3.2 The Domain Layer Above the Capability Map
225
6.3.3 Capability and Domain Inheritance Through the Data Spine
225
6.3.4 End-to-End Process Views from Inherited Capabilities
226
6.3.5 Worked Example: Cost Center to Position Capability and Domain Inheritance
227
6.4 Change Impact Use Cases
228
6.4.1 Use Case 1: Application Phase-Out
229
6.4.2 Use Case 2: Interface Deprecation
231
6.4.3 Use Case 3: Role Reorganization
231
6.4.4 Use Case 4: Control Intent Change
232
6.4.5 Worked Example: Cost Center to Position Composite Change Impact
233
6.5 Data Preparation for SAP BTP Ingestion
234
6.5.1 Stage 1: Extract
235
6.5.2 Stage 2: Validate
236
6.5.4 Stage 4: Enrich
237
6.5.5 Stage 5: Publish
238
6.5.6 Composition with the SAP Signavio Pipeline
239
6.5.7 Worked Example: Cost Center to Position Bundle Publication Record
239
6.6 Cross-Chapter Vocabulary Continuity
241
6.7.1 Key Learning Points
245
6.7.2 Common Design Pitfalls
246
6.7.3 Review Questions
247
6.7.4 Student Companion Notes
248
PART IV WalkMe for Process-Aware Adoption and Telemetry
251
7 Designing WalkMe for Process-Aware Adoption
253
7.1 Positioning WalkMe in a Process-Driven Architecture
254
7.1.1 Why the Target Distinction Matters
255
7.1.2 WalkMe as a Knowledge Graph
256
7.1.3 WalkMe in the Reference Architecture's Trust Zones
257
7.2 Mapping WalkMe Content to L4/L5 Process Steps
258
7.2.1 Stable Identifiers as the Binding Mechanism
258
7.2.2 The WALKME_ASSET_BINDING Entity and the Data Model
259
7.2.3 Worked Example: Cost Center to Position with WalkMe Overlay
260
7.2.4 Resolution at Render Time
262
7.3 Aligning WalkMe with SAP Signavio and SAP Build Work Zone
262
7.3.1 SAP Signavio: The Authoritative Process Reference
263
7.3.2 SAP Build Work Zone: The Launch Surface
264
7.3.3 WalkMe: The Guidance Surface
265
7.3.4 Joint Operating Cadence
265
7.4 Governance of In-App Guidance and Change
266
7.4.1 The Lifecycle of a WalkMe Asset
266
7.4.2 Approval and Separation of Duties
268
7.4.3 WalkMe as a Target for AI Agents
269
7.4.4 Change Coordination with SAP Signavio and SAP LeanIX
270
7.4.5 Audit Evidence and Retention
271
7.5.1 Key Learning Points
273
7.5.2 Common Design Pitfalls
273
7.5.3 Review Questions
274
7.5.4 Student Companion Notes
275
8 Using WalkMe Telemetry to Improve Process and Integration Outcomes
277
8.1 Capturing User Interaction Signals
278
8.1.1 The Four Signal Channels
279
8.1.2 Identity Tagging at the Edge
280
8.1.3 The Single Governed Gateway
281
8.2 Linking Adoption Data to the SAP BTP Data Spine
282
8.2.1 The Telemetry Data Model
282
8.2.2 The Five-Stage Ingestion Pipeline
285
8.2.3 The Dead-Letter Queue and Replay
286
8.3 Detecting Friction, Deviations, and Training Gaps
287
8.3.1 Friction Detection
287
8.3.2 Deviation Detection
288
8.3.3 Training Gap Detection
289
8.4 Feeding Adoption Insights into Downstream AI Services
291
8.4.1 WalkMe as a Target for AI Agents
291
8.4.2 The Two Downstream Destinations
292
8.4.3 Adoption Signals in the Knowledge Graph
293
8.4.4 The End-to-End Loop
294
8.5.1 Key Learning Points
297
8.5.2 Common Design Pitfalls
298
8.5.3 Review Questions
298
8.5.4 Student Companion Notes
299
PART V The Data Spine on SAP BTP
301
9 Designing the Canonical Data Spine
303
9.1 Why Point-to-Point Integrations Fail
303
9.2 Canonical Data Spine Entities and Relationships
305
9.2.1 Domain Model Overview and Architectural Boundaries
306
9.2.2 From Domains to Canonical Entities
307
9.2.3 Execution Context as the Structural Pivot
308
9.2.4 Logical Consolidation of the Canonical Model
308
9.3 Process, Activity, Application, and Interface Keys
310
9.3.1 Stable Identity and Version: Process and Activity
311
9.3.2 Architecture Keys and Identity: Applications and Interfaces
312
9.3.3 Mapping Tables: Process-to-Architecture and System Involvement
313
9.3.4 Execution Context: Ownership Clarity in Multisystem Processes
314
9.3.5 Master Data Referencing (Not Replication)
315
9.3.6 Adoption and Telemetry: WalkMe
316
9.3.7 Configuration Objects and Activity Mapping
317
9.3.8 Governance Overlay: Validation and Publication
318
9.3.9 AI Artifacts: Separated from Canonical Truth
319
9.4 Use Case: Creation of a New Position
320
9.4.1 Sample Data Set
320
9.4.2 Business Context and SAP Best Practice Alignment
322
9.4.3 End-to-End Cross-System Flow
322
9.4.4 Execution Context as Structural Control
323
9.4.5 Master Data Referencing in the Data Spine
324
9.4.6 Configuration Dependencies
324
9.4.7 Validation and Publication Discipline
325
9.4.8 AI-Governed Suggestion Flow
325
9.4.9 Architectural Outcome
326
9.5 Versioning and Lineage Strategy
327
9.5.1 Structural Identity and Version Separation
327
9.5.2 Version Graph and Lineage Modeling
327
9.5.3 Temporal Validity and Runtime Resolution
328
9.5.4 Publication as an Execution Structural Boundary
328
9.5.5 Dependency Revalidation on Structural Change
329
9.5.6 AI Grounding and Bundle Immutability
330
9.5.7 Managing Variant and Regulatory Branches
331
9.5.8 Versioning as an Operational Control System
331
9.6 Ownership and Lifecycle Rules
332
9.6.1 Entity Ownership Boundaries
332
9.6.2 Identity and Mutability Boundaries
333
9.6.3 Lifecycle State Model
334
9.6.4 Validation and Publication Authority
334
9.6.5 Cross-Domain Change Discipline
335
9.6.6 Separation of Duties and Access Control
335
9.6.7 AI Consumption Boundaries
336
9.6.8 Governance as Structural Integrity
336
9.7.1 Key Learning Points
337
9.7.2 Common Design Pitfalls
337
9.7.3 Review Questions
338
9.7.4 Student Companion Notes
338
10 Implementing the Data Spine on SAP BTP
339
10.1 Persistence Options on SAP BTP
340
10.1.1 SAP HANA Cloud as the Canonical Relational Core
341
10.1.2 Object Store for Raw Telemetry and Archival Payloads
341
10.1.3 Document Store for Schemaless and Variant Payloads
342
10.1.4 SAP HANA Cloud Vector Engine for AI Grounding Embeddings
342
10.1.5 Event Mesh for Change Propagation
342
10.1.6 SAP Build Process Automation for Workflow States
343
10.1.7 Choosing the Right Store for Each Canonical Concern
343
10.2 Table and Schema Design
345
10.2.1 Process and Activity Tables
346
10.2.2 Architecture Tables
348
10.2.3 Execution Context: Where Process Meets Architecture
349
10.2.4 Master Data and Adoption References
350
10.2.5 Audit and AI Consumption Tables
351
10.3 Data Extension Patterns
353
10.3.1 Why the Canonical Core Stays Closed
354
10.3.2 The Extension Side-Table Pattern
354
10.3.3 The Anti-Pattern That Destroys the Data Spine
356
10.3.4 Industry Variants and Vertical Extensions
356
10.3.5 AI-Derived Extensions
356
10.3.6 Extension Discoverability
358
10.4 API Design for Ingestion and Access
358
10.4.1 The Ingestion API: Idempotent Writes from Upstream Sources
359
10.4.2 The Access API: Read with Role and Version Context
361
10.4.3 The Governance API: State Transitions Through Workflow
362
10.4.4 AI Grounding Endpoints
363
10.4.5 Event Mesh Integration
364
10.4.6 Versioning the API Surface
365
10.4.7 Alignment with SAP API Policy v.4.2026a
366
10.5 Governance and Auditability
367
10.5.1 Hash-Chained Audit Events
368
10.5.2 Lineage as a First-Class Query Path
369
10.5.3 Separation of Duties Through SAP Authorization and Trust Management Service Scopes
371
10.5.4 Retention Tiering and Cryptographic Anchoring
372
10.5.5 Compliance Evidence Chain
373
10.6.1 Key Learning Points
376
10.6.2 Common Design Pitfalls
377
10.6.3 Review Questions
379
10.6.4 Student Companion Notes
379
PART VI Integration Flows and Execution Services on SAP BTP
381
11 Integration Flows from SAP Signavio and SAP LeanIX
383
11.1 SAP Signavio to SAP BTP Ingestion Flows
384
11.1.1 Reference Architecture for SAP Signavio Ingestion
384
11.1.2 Event-Driven and Batch Ingestion Patterns
385
11.1.3 End-to-End SAP Signavio Ingestion Flow
387
11.1.4 Payload Mapping into the Canonical Data Spine
389
11.1.5 Adapter Implementation Notes
393
11.1.6 Authentication and Credential Rotation
393
11.2 SAP LeanIX to SAP BTP Ingestion Flows
394
11.2.1 SAP LeanIX as the Architecture System of Record
394
11.2.2 Dependency-First Ingestion Order
395
11.2.3 Capability and Domain Alignment
396
11.2.4 SAP LeanIX Webhook Semantics and Bulk Export Sizing
398
11.2.5 Data Classification and Sensitive Attribute Handling
399
11.3 Synchronization and Reconciliation
399
11.3.1 States and Transitions
400
11.3.2 Daily Reconciliation Cycle
401
11.3.3 Drift Classification: Material Versus Immaterial
403
11.3.4 Snapshot Retention and Forensic Replay
404
11.3.5 Watermarks and Hot Restart Semantics
405
11.3.6 Operational Cadence and On-Call Posture
405
11.4 Error Handling and Retries
406
11.4.1 Error Classification
406
11.4.2 Idempotency Discipline
407
11.4.3 Retry, Backoff, and Dead-Letter Routing
408
11.4.4 Observability Tied to Failures
408
11.4.5 Service-Level Objectives and Alerting Thresholds
409
11.4.6 Poison Messages and Circuit Breakers
410
11.5 Data Consistency Validation
410
11.5.1 Four-Tier Validation Model
410
11.5.2 Validation Rules Catalog
412
11.5.3 Validation Log as the Audit Spine
413
11.5.4 Rule Lifecycle and Versioning
414
11.5.5 Validation Discipline and Financial Reporting Trust
415
11.5.6 Worked Example: A Single Activity Through the Pipeline
415
11.6.1 Key Learning Points
417
11.6.2 Common Design Pitfalls
417
11.6.3 Review Questions
418
11.6.4 Student Companion Notes
419
12 Process-Aware Execution Services
421
12.1 Process Lookup Services
422
12.1.1 Service Boundaries and Read-Only Contract
423
12.1.2 Latency Budget and Throughput Target
424
12.1.3 Worked Example: A Single Process Lookup Call
425
12.1.4 Filter Predicates and Their Cost
425
12.2 Context Enrichment APIs
426
12.2.1 The Three Distinguishing Properties
427
12.2.2 Latency Budget and Caching
428
12.2.3 Why Context Enrichment Is the Source for AI Grounding
429
12.2.4 Enrichment Output Schema
429
12.3 Change Impact Resolution Services
430
12.3.1 Forward Impact
431
12.3.2 Reverse Impact
432
12.3.3 Performance and Caching of Graph Walks
432
12.3.4 Graph Traversal Patterns by Use Case
433
12.3.5 Worked Example: Retiring an Interface
433
12.3.6 Edge Cases the Service Handles Explicitly
434
12.4 Reusable Integration Services
435
12.4.1 The Action Library
436
12.4.2 Versioning and Deprecation of Actions
437
12.4.3 Contract Stability
438
12.4.4 Action Definition Format
438
12.4.5 Service Contract: Process Lookup View
440
12.5 Performance and Scalability Considerations
441
12.5.1 Latency Budgets and Throughput Targets
441
12.5.2 Three-Tier Caching
442
12.5.3 Cache Invalidation and Stale Reads
443
12.5.4 Service Composition and Versioning
444
12.5.5 Capacity Planning
446
12.5.6 Failure Modes and Graceful Degradation
447
12.5.7 Multiregion Deployment
447
12.5.8 Cost and Resource Considerations
448
12.5.9 Financial Planning and Analysis Drilldown and the Controller’s Trace
448
12.5.10 AI Grounding Bundle Shape
450
12.6.1 Key Learning Points
452
12.6.2 Common Design Pitfalls
454
12.6.3 Review Questions
455
12.6.4 Student Companion Notes
455
PART VII SAP AI Consumption of the Data Spine
457
13 Introducing SAP AI Architecture
459
13.1 SAP AI Core Execution Model
460
13.1.1 Scenarios, Executables, Deployments, and Serving
462
13.1.2 Resource Groups and Tenancy
463
13.1.3 Scaling Policy and Capacity Reasoning
464
13.1.4 Inference Lineage and INFERENCE_EVENT
465
13.1.5 Worked Example: Deployment Manifest
466
13.2 SAP AI Launchpad and Model Access
467
13.2.1 Provider Categories and Their Governance Properties
469
13.2.2 Generative AI Hub and the Foundation Model Interface
469
13.2.3 Catalog Dimensions and the Deployment Decision
470
13.3 AI Lifecycle and Governance
472
13.3.1 Lifecycle States and What They Promise
473
13.3.2 Gates and Their Verdicts
474
13.3.3 Continuous Evaluation: Why the Gate Is Not a One-Time Check
476
13.3.4 Lifecycle Verdicts and the Financial Planning and Analysis Trace
477
13.4 Joule as the Interaction Layer
478
13.4.1 Joule Studio and Agent Authoring
479
13.4.2 The Agent Capability Matrix
479
13.4.3 Joule’s Tool Catalog Is the SAP Build Process Automation Action Library
481
13.5 Integrating AI with SAP BTP APIs
482
13.5.1 AI Grounding Endpoints: The Consumer Contract
484
13.5.2 AI Consumption Pathways and Their Audit Signatures
484
13.5.3 End-to-End Trace: The Controller’s Variance Question
486
13.5.4 Cost Lineage: INFERENCE_EVENT as a Controllable
488
13.6.1 Key Learning Points
489
13.6.2 Common Design Pitfalls
491
13.6.3 Review Questions
493
13.6.4 Student Companion Notes
494
14 Preparing Data for SAP AI
497
14.1 Data Eligibility for AI Consumption
498
14.1.1 The Eligibility Policy
498
14.1.2 Three Eligibility Classes
499
14.1.3 The Ineligibility Default
499
14.1.4 Review Cadence and Reevaluation
500
14.1.5 The Eligibility Decision Matrix
501
14.1.6 Worked Example: A German Payroll Master-Data Row
503
14.2 Filtering and Role-Based Scoping
504
14.2.1 Why Prepared Data Sets Are Never Reused Across Actors
504
14.2.2 The Role-Scoped Assembly Algorithm
505
14.2.3 The Composite-Role Case
507
14.2.4 Refusal Rather Than Partial Return
508
14.3 Version Control and Approvals
509
14.3.1 The PROCESS_VERSION Pin
509
14.3.2 The AS-OF Semantic
510
14.3.3 The Approval Chain
511
14.3.4 Worked Example: Approval
512
14.3.5 Freshness Budgets and Their One-Way Property
513
14.4 Grounding Rules and Constraints
515
14.4.1 Grounding as a Property of the Prepared Data Set
515
14.4.2 Manifest Signing and Immutability
516
14.4.3 The Citation Contract
517
14.4.4 Grounding Constraints: What May and May Not Be Bound
517
14.5 Preventing Hallucination and Drift
520
14.5.1 Hallucination Prevention as Structural Property
521
14.5.2 Drift as an Ongoing Concern
522
14.5.3 Drift Detection in Practice
523
14.5.4 A Worked Drift Detection Cycle
524
14.6.1 Key Learning Points
526
14.6.2 Common Design Pitfalls
527
14.6.3 Review Questions
528
14.6.4 Student Companion Notes
529
15 Generating Process Suggestions Using AI
531
15.1 Definition of Process Suggestions
532
15.1.1 The Suggestion Artifact
533
15.1.2 The Suggestion Table
534
15.1.3 The Suggestion Lifecycle
535
15.1.4 Enforcing the Stated AI Boundary
536
15.1.5 Where the Suggestion Pipeline Sits Operationally
537
15.2 Pattern Detection and Similarity Analysis
538
15.2.1 Worked Example: A Harmonization Suggestion
540
15.2.2 The Reference Corpus Is Itself a Governed Artifact
540
15.2.3 Failure Modes the Discipline Is Designed Against
541
15.3 Scoring and Prioritization Logic
543
15.3.1 The Four Factors in Detail
544
15.3.2 Worked Example: Scoring a Control-Gap Suggestion
545
15.3.3 Weights Are Configuration, Not Learning
545
15.3.4 Rescoring and the Stability Guarantee
546
15.4 Explainability and Traceability
548
15.4.1 The SUGGESTION_EXPLANATION Table
549
15.4.2 What the Validator Sees
550
15.4.3 The Explanation Under Adversarial Review
550
15.5 Human-in-the-Loop Validation
552
15.5.1 The VALIDATION_VERDICT Table
552
15.5.2 The Governed Commit Chain
553
15.5.3 Hybrid and Non-SAP Agents Submit Through the Same Path
554
15.5.4 What the Verdict Does Not Settle
554
15.6.1 Key Learning Points
557
15.6.2 Common Design Pitfalls
558
15.6.3 Review Questions
559
15.6.4 Student Companion Notes
559
PART VIII SAP Build Consumption
561
16 SAP Build Process Automation: Workflow on Top of the Data Spine
563
16.1 Positioning SAP Build Process Automation on the Data Spine
565
16.1.1 Building Block and What Each Is Allowed to Do
565
16.1.2 Projects, Releases, and Why Versioning Lives in the Data Spine
566
16.1.3 Destinations, Identity, and the Single Write Path
566
16.2 Approval Workflows
567
16.2.1 Why the Trigger Is Keyed to the Accepted Suggestion, Not the Raw Suggestion
567
16.2.2 Deriving the Approver Chain from Process Context
568
16.2.3 Separation of Duties as a Structural Property
570
16.2.4 What the Approval Writes Back, and How
570
16.2.5 An Annotated Reference Approval Process
571
16.2.6 Approval Forms: What They Display and What They Must Never Collect
573
16.2.7 The Anatomy of a Verdict-Keyed Trigger
574
16.2.8 Risk Bands and the Shape of the Approver Chain
575
16.2.9 Worked Example: A Cross-Region Sequencing Change
576
16.2.10 Time, Escalation, and the Standing Approver Problem
577
16.3 Exception and Remediation Flows
577
16.3.1 An Exception Is a Typed, Severity-Banded Event
578
16.3.2 Three Governed Remediation Paths
579
16.3.3 Worked Example: A Failed Control-Gate Validation
580
16.3.4 The Exception Event Schema
580
16.3.5 Auto-Remediation Is a Governed Rule, Not a Code Path
581
16.3.6 The Remediation Case as a Data Spine Object
582
16.3.7 Reconciliation Between Workflow State and Data Spine Truth
582
16.3.8 Worked Example: Telemetry-Driven Remediation
583
16.4 AI-Assisted Recommendations
584
16.4.1 The Recommendation Is Advisory by Design
584
16.4.2 What the Recommendation Panel Must Carry
585
16.4.3 An Annotated Human Task Contract
586
16.4.4 The Verdict Records What the Human Did with the Advice
587
16.4.5 Why the Panel Cannot Prefill the Decision
588
16.4.6 Worked Example: A Recommendation Inside an Approval Task
588
16.4.7 Disposition Analytics: The Controller’s Earliest Signal
589
16.5 Governance and Audit Handling
590
16.5.1 Every Workflow Instance Is an Audit Row
590
16.5.2 The One-Query Reconstruction
591
16.5.3 Governance Exceptions Are First Class, Not Errors
592
16.5.4 What an Auditor Actually Asks, and the Answer’s Shape
592
16.5.5 Where Workflow State Lives, and Why It Matters for Audit
593
16.5.6 The Refusal Ledger
594
16.5.7 The Control Catalog: Mapping Workflow Controls to Audit Frameworks
595
16.5.8 Audit Handling Across Programs and Regions
596
16.5.9 One Change, End to End
597
16.6.1 Key Learning Points
599
16.6.2 Common Design Pitfalls
599
16.6.3 Review Questions
600
16.6.4 Student Companion Notes
600
17 SAP Build Work Zone: Process-Aware User Experiences
603
17.1 Positioning SAP Build Work Zone on the Data Spine
605
17.1.1 Components and What Each Is Allowed to Do
605
17.1.2 Why the Experience Layer Holds No Data
606
17.1.3 The Single Read Path and the Absent Write Path
607
17.1.4 What May Live in SAP Build Work Zone and What May Not
608
17.2 Process-Driven Navigation
609
17.2.1 Navigation Is a Query, Not a Menu
609
17.2.2 The Process-to-Space Mapping
611
17.2.3 Search Is a Scoped Projection, Not an Index
612
17.2.4 Worked Example: The Cost Center to Position Journey
613
17.2.5 Deep Links, Bookmarks, and the Stale URL Problem
614
17.3 Role-Based Task Views
615
17.3.1 A Task View Is a Role-Scoped Assembly
615
17.3.2 Where the Tasks Come From: SAP Build Process Automation
616
17.3.3 Separation of Duties Is Visible, Not Just Enforced
616
17.3.4 Delegation and Substitution Without Scope Escalation
618
17.4 Surfacing AI Insights
620
17.4.1 An Insight Is a Citation, Not an Answer
620
17.4.2 Joule in SAP Build Work Zone
621
17.4.3 The Insight Card Contract, Annotated
622
17.4.4 Multi-Suggestion Cards and the Comparison Trap
623
17.4.5 When the Bundle Is Stale: Insight Expiration and Regrounding
624
17.5 User Interaction Boundaries
625
17.5.1 The User Interface Offers Only What the Data Spine Would Permit
626
17.5.2 The Absent Control Is the Strongest Control
626
17.5.3 Break-Glass Is a Separate, Human-Authenticated Path
628
17.5.4 The Mobile and Offline Case
628
17.5.5 One Interaction, End to End: Across the Boundaries
630
17.6.1 Key Learning Points
632
17.6.2 Common Design Pitfalls
633
17.6.3 Review Questions
633
17.6.4 Student Companion Notes
634
PART IX Operations, Security, and Extensibility
635
18 Operating the Integrated Platform
637
18.1 The Operating Model of the Integrated Platform
638
18.2 Monitoring and Observability
640
18.2.1 Three Signal Classes
640
18.2.2 The Golden Signals per Layer
641
18.2.3 Service-Level Objectives and the Error Budget
642
18.2.4 The Severity Model and On-Call Posture
644
18.2.5 Correlation: One Identity for Health and Evidence
644
18.2.6 The Observability Data Model
645
18.2.7 Dashboards as Operated Artifacts, Not Decoration
646
18.2.8 Worked Example: The Incident Response Lifecycle
647
18.3 Data Quality Management
648
18.3.1 Quality Is an Operated Property
649
18.3.2 The Steward Operating Model
650
18.3.3 The Quarantine Economy
651
18.3.4 AI as a Quality Pattern Detector and Its Boundary
651
18.3.5 The Validation Rule Lifecycle
652
18.3.6 Worked Example: Reconciliation Is the Engine of the Scorecard
653
18.4 Version Drift and Resynchronization
654
18.4.1 The Drift Taxonomy, Carried Forward
654
18.4.2 The Resynchronization Decision Flow
655
18.4.3 Drift Never Mutates in Place
656
18.4.4 Forensic Replay
657
18.4.5 Hot Restart and Regrounding
657
18.4.6 The Reconciliation Cadence, Operated
658
18.4.7 Snapshot Retention Economics
659
18.4.8 Worked Example: A Drift Event, End to End
659
18.5 Scaling Across Programs
660
18.5.1 Program Tenancy on Resource Groups
660
18.5.2 Multiregion Topology and Jurisdiction-Bounded Replication
661
18.5.3 The Program Onboarding Lifecycle
662
18.5.4 Verifying Tenant Isolation
662
18.5.5 Scaling the AI Tier
663
18.5.6 The Federated Team and Its Accountabilities
664
18.5.7 Work Example: Cost Lineage and the AI Tier as a Controllable
664
18.6.1 Key Learning Points
666
18.6.2 Common Design Pitfalls
667
18.6.3 Review Questions
667
18.6.4 Student Companion Notes
668
19 Security, Controls, and Audits
669
19.1 Data Access and Authorization
670
19.1.1 Identity Is the First Control, Not a Prerequisite to It
671
19.1.2 Defense in Depth as an Architectural Property
672
19.1.3 The Authorization Vocabulary: Scopes Bound to Canonical Operations
673
19.1.4 The Four Canonical Operations in Detail
675
19.1.5 Worked Example: An AI Agent Reaches Its Boundary
676
19.1.6 Role-Based Segmentation of the Data Spine
676
19.1.7 AI Agents as Named Actors
677
19.1.8 Worked Example: A Data Residency Question
679
19.2 Control Effectiveness
680
19.2.1 Effectiveness Is Design Adequacy Multiplied by Operating Evidence
680
19.2.2 The Three Control Classes
681
19.2.3 Why the Refusal Ledger Is the Most Valuable Evidence
682
19.2.4 The Control Catalog as a Generated Register
684
19.2.5 The Dimensions of a Catalog Entry
685
19.2.6 Worked Example: Evidencing a Preventive Control Over a Quarter
686
19.2.7 Effectiveness Is a Property of the Architecture, Not the Effort
686
19.3 Audit Trails and Evidence
687
19.3.1 The Hash-Chained Audit Event
687
19.3.2 Lineage as a First-Class Query Path
689
19.3.3 What the Auditor Actually Asks
690
19.3.4 Worked Example: The Controller Variance Question, Step by Step
691
19.3.5 Worked Example: Forensic Replay of a Past Decision
691
19.3.6 Retention, Anchoring, and Forensic Replay
692
19.4 Compliance Considerations
692
19.4.1 Obligation, Control, Evidence
693
19.4.2 Why Mapping to Queries Rather Than Binders Matters
695
19.4.3 Worked Example: Decomposing a Compliance Obligation
695
19.4.4 Why the Same Mechanisms Satisfy Independent Regimes
696
19.4.5 Jurisdiction, Residency, and Multiregion Compliance
696
19.4.6 The Compliance Posture Is Continuous, Not Periodic
697
19.5.1 Key Learning Points
698
19.5.2 Common Design Pitfalls
699
19.5.3 Review Questions
700
19.5.4 Student Companion Notes
700
19.6 Conclusion: The Integrated, AI-Ready Enterprise
701