DDA (Digital Discovery Assessment)

Moving to SAP Cloud ERP is rarely blocked by technology alone. Most programs stumble earlier—when scope, operating model, and commercial assumptions don’t line up. That’s exactly where DDA (Digital Discovery Assessment) comes in. DDA helps you validate what you actually need (process scope, localization, integrations, extensibility) before you commit to a solution path.

But here’s the part many teams miss: the DDA should directly feed your licensing BOM (Bill of Materials). If your DDA says you need specific capabilities, integrations, environments, or extension patterns and your BOM doesn’t reflect that, you’ll either overpay “just in case” or discover costs too late during delivery.

In this article, you’ll learn how to use DDA as the structured input for a defensible BOM when choosing between SAP S/4HANA Cloud Public Edition and Private Edition with a practical workflow, common pitfalls, and governance tips you can run with IT, procurement, and finance.

Contact us now!

DDA (Digital Discovery Assessment) is a structured assessment used early in SAP cloud programs to capture requirements and match them to a suitable solution scope and operating model. It’s usually performed in the “discover” phase and produces a DDA report that helps align stakeholders on what is in scope, what needs standardization, and what must be integrated or extended.

Think of DDA as your scope truth:

• which processes are in scope,

• which countries/localizations matter,

• what compliance constraints exist,

• what your integration and extension needs look like,

• and how realistic a Public vs. Private path is.

If you want the result of your cloud program to be predictable, the DDA cannot remain a “pre-sales document.” It must become an input artifact for architecture, delivery planning—and your licensing BOM.

Your BOM is your commercial and governance blueprint. It defines what you need to buy, how you classify usage, and how you prevent licensing surprises later.

When DDA and BOM are disconnected, you typically see one of these failure modes:

• Over-licensing: you size the BOM by headcount and anxiety, not by roles and real scope.

• Under-scoping integrations: DDA identifies interfaces and data flows, but the BOM doesn’t include the services or effort model behind them.

• Non-production blind spot: DDA implies a delivery model that requires dev/test/QA/sandbox, but the BOM is sized for production only.

• Public/Private confusion: stakeholders talk “Public,” but the DDA reveals constraints that push parts of scope toward Private (or require a phased approach).

• Scope drift: the DDA report goes to implementation, procurement never sees it, and the BOM is negotiated on assumptions.

A good rule: Every meaningful DDA decision should have a BOM consequence.

The DDA is where you pressure-test the operating model choice.

Public Edition implications

Public Edition works best when you embrace standardization and “clean core.” In the BOM, that usually means:

• stronger focus on role-based access design,

• a deliberate plan for side-by-side extensions,

• explicit integration approach (APIs, events, middleware),

• and controlled governance (because updates are regular and standardized).

Private Edition implications

Private Edition provides more flexibility for customer-specific requirements and transition patterns. In the BOM, this often translates into:

• more landscape considerations (environments, system separation),

• higher emphasis on integration and legacy coexistence,

• more variation in how extensions/custom logic is handled.

Practical takeaway: use DDA to decide Public vs. Private per process domain, then build the BOM accordingly. Finance may fit Public well; manufacturing planning might require a different path depending on constraints. The BOM should reflect that reality.

To keep this practical: here are the DDA outputs that should become explicit BOM components.

Here’s a workflow you can implement without overengineering it.

Step 1: Run DDA with the right stakeholders

Include:

• process owners (finance, procurement, supply chain),

• security/IAM,

• integration architecture,

• procurement/finance,

• license management (SAM).

This prevents “scope vs. contract” gaps later.

Step 2: Extract three lists from the DDA

1. Must-have capabilities (day 1)

2. Integrations + extensions required

3. Constraints (localizations, compliance, timeline, clean-core readiness)

Step 3: Convert the lists into BOM sections

Create a BOM template with sections:

• Edition & scope (Public/Private per domain)

• Role model & entitlement sizing

• Environments (prod + non-prod + project peaks)

• Integrations & interfaces

• Extensions/platform services

• Governance & measurement plan

Step 4: Baseline, version, and approve

Treat the BOM like engineering:

• v0.9 planning baseline,

• v1.0 contract baseline,

• v1.1 go-live update,

• v1.2 stabilization.

Tie each version to DDA decisions and scope changes.

Step 5: Operate the BOM

After go-live, the BOM becomes a living control instrument:

• quarterly role and usage review,

• integration inventory updates,

• exception handling for temporary project users.

• SAP ERP Cloud / S/4HANA: https://www.fink-its.de/en/capabilities/sap-erp-cloud-s4-hana.html

Mistake 1: Treating DDA as a checkbox
Fix: make the DDA report a required attachment to the BOM baseline.

Mistake 2: Sizing the BOM by headcount
Fix: size by roles and usage intensity; review “power user” assignments quarterly.

Mistake 3: Forgetting non-production
Fix: include an environment pack section in the BOM from day 1.

Mistake 4: Integration scope not owned
Fix: assign a single owner for the integration inventory; no interface goes live without a BOM update.

Mistake 5: Mixing Public and Private assumptions
Fix: define scope rules per domain, document them, and enforce them in governance.

A licensing BOM needs ownership and rhythm:

Ownership

• IT + Procurement + Finance as steering triangle

• SAM/license manager as BOM owner

• Security/IAM for role governance

• Enterprise Architecture for scope discipline

Cadence

• Quarterly BOM review

• Release checkpoints (especially relevant in Public Edition)

• New integration / extension gate: “no design complete without BOM impact check”

DDA is not just a discovery exercist, it’s the best input you have to build a reliable licensing BOM for SAP Cloud ERP. Use DDA to validate Public vs. Private per domain, convert DDA outputs into BOM line items, and govern the BOM after go-live. That’s how you protect your business case, avoid late cost surprises, and keep licensing aligned with real usage.