S/4HANA
Discovery phases in SAP S/4HANA programs are explicitly designed to mitigate uncertainty and risks ahead of design and build phases. Yet, empirical evidence from countless implementations, including industry benchmarks showing discovery-related rework accounting for 30-50% of total project delays, demonstrates they routinely produce the inverse: an unrelenting torrent of workshop notes, slide decks, and ephemeral "working documents" that evaporate without reliably informing configuration decisions, test cases, or build tickets, ensnaring teams in protracted ambiguity and expensive rework cycles.
This entrenched failure stems not from any dearth of expertise, but from a profoundly defective operating model: one that enshrines workshops as the infallible engine of progress while relegating documentation to a disposable afterthought. Far from innocuous, this imbalance foreseeably unleashes a domino effect of catastrophic failure modes, program derailments, exponentially amplified costs, and irreparably eroded stakeholder trust, that have doomed countless S/4HANA rollouts.¹
The symptoms are painfully familiar:
If you take one practical lesson from this: workshop count is not a measure of discovery progress—artifact quality is.
Imagine flipping discovery on its head: make every workshop or meeting produce a real, updated deliverable—one that's reviewable, testable, and traceable right away. Workshops aren't scrapped; they're just sharpened into quick input sessions that spit out these updates in hours or days, not weeks.¹
In typical S/4HANA programs, here's the bare-minimum lineup:
This isn't piling on paperwork—it's basic engineering smarts. If it can't be reviewed, versioned, and handed off smoothly, it's just rough notes, not a deliverable.
Focusing reviews on deliverables makes sessions snappier and more effective:
Bottom line: fewer repeat workshops because the project's memory lives in artifacts, not brains.¹
Most SAP teams already "write requirements." The issue is that many requirements are not usable downstream. A requirement that can't be tested or owned is not a requirement—it's a wish.
A high-utility SAP requirement should be:
| Field | Description | |-------|-------------| | Requirement statement | What must happen | | Business rationale | Why it matters | | Process context | Where it happens | | Roles | Who executes / approves | | Data objects | Master/transactional data involved | | Acceptance criteria | How we know it's satisfied | | Source + Owner + Priority | Traceability and accountability |
The hidden payoff: faster fit-to-standard. When requirements are written in a standard-comparable way, fit-to-standard becomes faster and less emotional. You're no longer arguing preferences; you're evaluating whether SAP standard meets the requirement and what the delta costs.
This is where tools can help: Qorelo can take messy discovery inputs (MoMs, transcripts, BRD fragments) and output structured requirement candidates in a consistent template—then humans validate and own them.
Process models are where discovery becomes real. If your process flows are vague, every downstream activity becomes interpretive—config, integration, testing, training, change impact.
BPMN (and tools like Signavio) provide a disciplined way to represent process truth. The key is consistency, not perfection.
In Prepare & Explore, you typically need:
Stakeholders often disagree in discovery because they're talking at different abstraction levels. A flow forces specificity: "Where exactly does approval happen?" "Which role owns the exception?" "What triggers a credit block?"
This is another area where automation helps: Qorelo can convert workshop transcripts and MoMs into a first-draft flow structure (lanes, steps, decision points) in a Signavio/BPMN-ready format—then the process owner reviews and corrects.
Deliverables-first discovery works best as a pipeline. Each artifact feeds the next, and each iteration tightens ambiguity.
Inputs: workshop notes, MoMs, BRDs, emails, legacy process docs, RICEFW lists, pain-point backlogs.
Outputs:
Produce structured requirements with owners and acceptance criteria. Don't chase completeness in v1; chase clarity and testability.
Outputs:
For each requirement cluster, log decisions:
Outputs:
Draft flows based on the decided baseline. This avoids modeling fantasy processes that will be rejected later.
Outputs:
Connect artifacts to build and test planning (Cloud ALM / Solution Manager / Jira—whatever you use).
Outputs:
Discovery is "done enough" when artifacts can drive build and testing without re-interpreting stakeholder intent.
Scenario: A pharma distributor operating in two countries is moving from ECC to SAP S/4HANA. They have strict compliance requirements (batch traceability, controlled substances), a lean IT team, and a systems integrator pushing for "template adoption." The business is anxious because operations can't pause.
Artifacts: input repository + question backlog + requirement clusters v0.
For "returns processing," they write requirements like:
Artifacts: requirements pack v1 with owners and acceptance criteria.
They evaluate standard and decide:
Artifacts: fit-gap log with owner, rationale, risk, and downstream consequences (build + training + control).
They model:
They can now review flows in playback sessions with minimal debate—because the flow is tied to decisions already logged.
Artifacts: process flows v1 + exception register + traceability links.
This is the practical promise of deliverables-first discovery: fewer workshops, faster convergence, and a baseline that survives handover.
| Pitfall | Fix | |---------|-----| | "We'll document later." | Set an SLA—every workshop must produce artifact updates within 48 hours. | | Fit-gap logs without ownership. | No gap entry is valid without an owner and decision status. | | Requirements that read like slogans. | Require acceptance criteria and process context. | | Modeling processes before deciding baseline. | Sequence: requirements → fit-gap decisions → flows. | | Variants and exceptions hidden in side conversations. | Maintain a variant register and exception register as first-class artifacts. |
Most discovery pain comes from delayed documentation, missing ownership, and wrong sequencing—fixable with simple operating rules.
AI in SAP discovery is useful when it reduces synthesis labor without weakening governance.
This is the "AI colleague" model: Qorelo, for instance, is designed to transform messy discovery inputs into execution-ready deliverables like requirements packs, fit-gap logs, and Signavio/BPMN-ready flows while keeping artifacts reviewable and controlled.
Assumption: you have governance discipline in place (owners, sign-offs, versioning); AI accelerates the conversion step, not accountability.
| Dimension | Workshop-heavy discovery | Deliverables-first discovery | |-----------|--------------------------|------------------------------| | Unit of progress | # workshops held, decks produced | # deliverables versioned and approved | | Output quality | Notes and summaries vary by facilitator | Standard templates: requirements, fit-gap, flows | | Traceability | Often implicit ("ask the consultant who ran it") | Explicit links: source → requirement → decision → flow | | Fit-to-standard | Repeated debates, decisions drift | Decisions logged with owners and rationale | | Process | Late, inconsistent, sometimes "retrofit" documentation | Early, iterated, Signavio/BPMN-ready | | Governance | Steering sees activity, not clarity | Steering sees decisions, impacts, and risks | | Handover to build/test | Interpretation-heavy, rework-prone | Backlog/test-ready artifacts with context |
What is SAP S/4HANA discovery in Prepare & Explore? It's the crucial phase where you transform stakeholder input—raw ideas, needs, and debates—into a rock-solid baseline: requirements, fit-to-standard decisions, and process definitions ready to power design, build, and testing.
How do we cut down on workshops without losing alignment? Don't ditch workshops, just make them shorter and sharper. Shift the focus to reviewing deliverables. Pump out artifact updates within 48 hours, then run quick playback sessions on those to keep everyone synced.
What deliverables do we need before build kicks off? The essentials: a testable requirements pack, a fit-gap log (with clear owners and decision status), baseline process flows (covering exceptions and variants), and full traceability back to your sources. No more guesswork.
What turns a fit-gap log from useless to game-changing? It's all about ownership, clear rationale, decision status, and real-world consequences. Without those, your "gaps" list just gathers dust or sparks endless re-debates.
Should we jump into Signavio process modeling during discovery? Yes, if you're modeling the decided baseline and keeping flows easy to review. Skip speculative paths that'll get scrapped later.
Can AI wipe out SAP discovery workshops entirely? Nope. AI shines at slashing synthesis grunt work and boosting consistency, but humans own the tough trade-offs, approvals, and accountability.
How do we nail traceability without bogging down the team? Stick to simple linking rules and standard templates. Smart automation keeps those links fresh—no manual drudgery required.
SAP S/4HANA discovery isn't complete when workshops wrap up—it's finished when you have battle-tested, auditable deliverables: precise requirements, owned fit-gap decisions, and Signavio-ready process flows that drive seamless design, build, testing, and governance. In 2026, speed wins through discipline, not endless meetings. Prioritize a deliverables-first pipeline, review artifacts rigorously until they're rock-solid, and watch your program surge ahead.
Ready to operationalize this? Subscribe to Insights for weekly playbooks from the Qorelo team, or explore Qorelo to see how an AI colleague transforms chaotic inputs into execution-ready artifacts—elevating your discovery from reactive to relentless.
