DDA (Digital Discovery Access)

Der Umstieg auf SAP Cloud ERP scheitert selten an der Technik. Er scheitert an falschen Annahmen: Was ist wirklich im Scope? Welche Integrationen sind Pflicht? Welche Erweiterungen braucht ihr? Und passt Public oder Private wirklich zu euren Prozessen? Genau hier setzt DDA (Digital Discovery Assessment) an. DDA strukturiert die Discover-Phase und schafft eine belastbare Grundlage für Scope, Zielbild und Liefermodell.

Der entscheidende Punkt: DDA darf nicht als „Pre-Sales-Fragebogen“ enden. Die Ergebnisse müssen direkt in eure Lizenz-BOM (Bill of Materials) einfließen – also in die Lizenz-Stückliste, die festlegt, was ihr kaufen müsst, wie ihr Nutzerrollen dimensioniert, welche Umgebungen ihr braucht und welche Integrations-/Plattform-Services einkalkuliert werden müssen.

Jetzt Kontakt aufnehmen!

Was ist DDA im SAP-Kontext?

DDA (Digital Discovery Assessment) ist eine strukturierte Erhebung und Bewertung eurer Anforderungen in der frühen Projektphase. Ziel ist, Prozess- und Funktionsanforderungen, Rahmenbedingungen (z. B. Länder, Compliance, Timing) sowie Integrations- und Erweiterungsbedarfe so zu erfassen, dass daraus ein belastbares Zielbild und ein realistischer Projektumfang entsteht.

Du kannst dir DDA als Scope-Wahrheit vorstellen:

Welche Prozesse sind wirklich „Day 1“?
Wo müsst ihr standardisieren?
Wo sind Integrationen zwingend?
Wo braucht ihr Erweiterungen (z. B. Apps, Workflows, Automatisierung)?
Welche Constraints sprechen für Public, welche für Private?

Wenn DDA sauber durchgeführt wird, bekommst du ein Ergebnis, das nicht nur die Implementierung steuert – sondern auch eure Lizenz- und Kostenlogik absichert.

Warum DDA entscheidend für eure Lizenz-BOM ist

Ihr Lizenz-BOM ist die Lizenz-Stückliste für SAP Cloud ERP: Edition, Rollen-/Nutzungsmodell, Umgebungen, Integrationen, Erweiterungen, Governance. Und genau diese Punkte liefert DDA als Entscheidungsgrundlage.

Wenn DDA und BOM getrennt laufen, passieren typischerweise diese Dinge:

Überlizenzierung: BOM wird aus Kopfzahl und Sicherheitsdenken gebaut („lieber zu viel“).
Späte Kostensprünge: DDA identifiziert Integrationen/Erweiterungen, die BOM berücksichtigt sie nicht – und später wird’s teuer.
Non-Prod-Blindspot: DDA impliziert ein Delivery-Setup mit Dev/Test/QA/Sandbox, BOM ist nur für Produktion dimensioniert.
Public/Private-Widersprüche: Stakeholder sagen „Public“, DDA zeigt, dass Teile des Scopes so nicht passen – Ergebnis: Rework.
Scope Drift: DDA-Report geht zur Delivery, Einkauf/SAM sieht ihn nie – BOM und Projekt laufen auseinander.

Merksatz: Jede relevante DDA-Entscheidung muss eine BOM-Konsequenz haben.

Public vs. Private: Wie DDA Ihre BOM verändert

DDA ist genau der Punkt, an dem „Public vs. Private“ nicht mehr Bauchgefühl ist, sondern evidenzbasiert wird.

Public Edition: Standardisierung + Side-by-Side Extensions

Public funktioniert dann gut, wenn ihr Standardprozesse akzeptiert und den Core sauber haltet. In der BOM heißt das meistens:

stärkerer Fokus auf rollenbasierte Zugriffsmodelle
saubere Planung von side-by-side Extensions
Integrationen klar über APIs/Events/Middleware
Governance, weil Updates regelmäßig kommen

Private Edition: mehr Freiheitsgrade + Übergangskomplexität

Private erlaubt mehr Flexibilität, bringt aber oft mehr Komplexität in Übergang und Betrieb. In der BOM spiegelt sich das häufig so:

stärkere Landscape-/Umgebungsdiskussion
mehr Fokus auf Integrationen und Koexistenz
klarere Regeln, wie Custom/Extensions gemanagt werden

Praxis-Tipp: Entscheidet Public/Private pro Prozessdomäne und führt die Ergebnisse in einer konsolidierten BOM zusammen. Finance kann Public-fit sein, während bestimmte SCM-/Planungsthemen Private brauchen – abhängig von Constraints.

Welche DDA-Ergebnisse in die BOM gehören

Hier wird es konkret: DDA liefert Outputs – und du übersetzt sie in BOM-Positionen.

1) Prozess-Scope → Rollenmodell → Dimensionierung

DDA sagt, welche Capabilities Day 1 im Scope sind. Daraus baust du:

10–25 Business-Rollen (keine Jobtitel)
Nutzungsintensität (Power/Core/Self-Service/Admin)
Rollout-Wellen (wer nutzt wann was?)
SAP License Consulting: SAP, OpenText & Atlassian License Consulting - Fink IT-Solutions

2) Integrationen → Integrations-BOM

Was im DDA als Integration auftaucht, muss als BOM-Block sichtbar sein:

Integrationsservices (Plattform/Middleware)
API-Governance, Monitoring, Fehlerhandling
Identity-Flows (SSO, Provisioning)
Business Process Integration: Business Process Integration - Fink IT-Solutions

3) Erweiterungen → Plattformservices (BTP) in der BOM

Gerade in Public ist der Erweiterungsbedarf oft „side-by-side“. Das muss in die BOM:

Extension-Pattern (Workflows, Apps, UI-Erweiterungen)
benötigte Plattformfähigkeiten
SAP BTP: SAP Business Technology Platform | Integration & Innovation - Fink IT-Solutions

4) Delivery-Setup → Non-Prod-Umgebungen

DDA impliziert immer ein Liefermodell. Die BOM muss enthalten:

Dev/Test/QA/Sandbox
Cutover-/Hypercare-Spitzen
Partnerzugänge (zeitlich begrenzt, kontrolliert)

5) Constraints/Localizations → Scope-Regeln

Wenn DDA Länder, regulatorische Anforderungen oder harte Deadlines zeigt, dann gehört in die BOM:

Scope-Regeln (Day 1 vs Phase 2)
Annahmen, Ausschlüsse, Abhängigkeiten

So verhinderst du, dass die BOM zum Wunschzettel wird.

Schritt-für-Schritt: DDA → BOM Workflow

Ein Workflow, den du in echten Projekten sauber durchziehen kannst:

Schritt 1: DDA mit den richtigen Leuten durchführen

Nicht nur IT, nicht nur Pre-Sales. Rein müssen:

Process Owner (Finance, Procurement, Supply Chain)
Security/IAM
Integration Architecture
Einkauf/Finance
SAM/Lizenzmanagement

Schritt 2: Drei Listen aus dem DDA extrahieren

Must-haves (Day 1)
Integrationen + Erweiterungen
Constraints (Länder, Compliance, Timeline, Standardisierungsgrad)

Schritt 3: In BOM-Sektionen übersetzen

BOM-Template:

Edition & Scope (Public/Private je Domäne)
Rollenmodell & Dimensionierung
Umgebungen (Prod + Non-Prod + Peaks)
Integrationen & Interfaces
Extensions/Plattformservices
Governance & Messplan

Schritt 4: Baseline, Versionierung, Freigabe

Wie im Engineering:

v0.9 Planung
v1.0 Vertragsbaseline
v1.1 Go-Live-Update
v1.2 Stabilisierung

Schritt 5: BOM betreiben

Nach Go-Live wird die BOM zum Steuerungsinstrument:

Quarterly Review der Rollen und Nutzung
Integration-Inventar aktualisieren
Ausnahmen (Projektuser, Partner) sauber managen

Typische Fehler und wie du sie vermeidest

Fehler 1: DDA als Checkbox behandeln
Fix: DDA-Report als Pflichtanlage zur BOM-Baseline.

Fehler 2: BOM nach Kopfzahl dimensionieren
Fix: Rollenbasiert, mit Evidenz; Power-Role-Zuordnungen quartalsweise reviewen.

Fehler 3: Non-Prod vergessen
Fix: „Environment Pack“ als Standardblock in jeder BOM.

Fehler 4: Integrationen ohne Owner
Fix: Ein Owner für Integration-Inventar; keine neue Schnittstelle ohne BOM-Update.

Fehler 5: Public/Private-Annahmen vermischen
Fix: Scope-Regeln pro Domäne definieren und in Governance erzwingen.

Governance: So bleibt die BOM nach Go-Live sauber

Eine BOM ist nur so gut wie ihr Betrieb.

Ownership

IT + Einkauf + Finance (Steuerdreieck)
SAM/Lizenzmanager als BOM Owner
Security/IAM für Rollen und Zugriffe
Enterprise Architecture für Scope-Disziplin

Cadence

Quartalsweise BOM-Reviews
Release-Checkpoints (bei Public besonders wichtig)
Gate: „Keine Extension/Integration ohne BOM-Impact-Check“

Fazit

DDA ist nicht nur „Discover“, es ist der beste Input, den du hast, um eure Lizenz-BOM für SAP Cloud ERP sauber aufzubauen. Nutze DDA, um Public vs. Private pro Domäne realistisch zu entscheiden, übersetze DDA-Outputs in BOM-Line-Items und betreibe die BOM nach Go-Live mit klarer Ownership und Rhythmus. So schützt du Business Case, Compliance und Lieferfähigkeit – ohne späte Überraschungen.