The consultant demonstrates a standard process. Someone says, “That will not work for us.” The next question is where a useful workshop begins: which business requirement would it fail to meet, and what evidence supports that concern?
For SAP programme owners and business process leads, preparation means being able to answer that question. Bring a reviewed account of the relevant process, examples of important exceptions and people who can decide what must change. You do not need to document every click across the company before a workshop can start.
What a fit-to-standard workshop is for
Fit-to-standard analysis evaluates how the proposed SAP standard processes meet the business requirements in scope. SAP places this analysis in the Explore phase of SAP Activate. The objective is to assess the standard and establish justified gaps, rather than assume the current process must be reproduced. SAP’s overview of Activate explains that role.
Your implementation partner prepares the relevant demonstration and guides the solution discussion. Business participants explain the requirements, controls and operational consequences. Confirm the workshop scope and preparation with your partner: the system and content depend on your SAP edition and transition approach. SAP provides distinct preparation guidance for Private Edition and Public Edition.
The checklist below is a practical way to prepare the business evidence for that discussion. It complements the partner’s SAP preparation.
Agree the decision and the process boundary
Before asking people to record walkthroughs, name the process you will discuss and the decisions you expect the workshop to support. “Procure to pay” may be too broad for one useful preparation exercise. “How AP resolves an invoice discrepancy with receiving and the supplier” gives participants something concrete to explain.
Ask the partner which standard processes and test scripts the workshop will cover. Review the relevant process flows, confirm which business roles should attend, and ask what configuration information your team must bring. Agree the legal entities, locations and roles in scope, and identify the process owner who can approve business decisions. Include people who perform the process, especially at handoffs between teams.
If a workshop decision requires a policy, data or integration owner who cannot attend, arrange how that person will respond. Otherwise an unanswered question can quietly become an assumed requirement.
Bring a small, reviewable evidence pack
| Bring | What it needs to explain |
|---|---|
| Current process map | The trigger, completion point, responsible roles and handoffs, including steps outside SAP |
| Ordinary case and relevant exceptions | What actually happened, where it differed and why that difference matters |
| Business requirements and controls | The outcome or obligation that must be met, with an owner and supporting source |
| Known data and system dependencies | Records, applications and interfaces the proposed process must account for |
| Open questions | What is unknown, who can resolve it and when the answer is needed |
Start with existing maps and documents. Use focused walkthroughs to fill the gaps. Ask a participant to show a permitted example, including the email or spreadsheet they use between system steps. Capture only material your team is authorized to share, with agreed access and retention.
Have the receiving role review each important handoff. A process can look complete from AP’s side while omitting the information the warehouse needs to act. Where accounts conflict, record the disagreement instead of choosing the tidier story.
The Duvo Clarity map below is an invoice-reconciliation example. It shows review branches and supplier follow-up that a process owner can inspect. It is not a target SAP design or evidence that a particular SAP configuration has been validated.
Open the process map at full size.
Separate the requirement from today’s workaround
“We need this spreadsheet in the new system” describes an existing solution. Ask what it accomplishes. Perhaps it keeps an unresolved supplier claim visible until a credit arrives. That business need can be evaluated against the demonstrated standard without assuming the spreadsheet must survive.
For each disputed step, establish who needs the outcome, why it matters and what evidence supports it. If someone calls an exception frequent, ask for a source or mark the frequency as unknown. A walkthrough describes a case; it does not measure the whole population.
This Clarity step record shows a potential overpayment trigger and its sources. That detail gives reviewers a starting point for checking the description and asking what the future process must support.
The graphic below shows the discussion to prepare for. Current practice supplies context; the standard demonstration supplies a proposed way to meet the need. The business owner and partner assess the difference together.
Work through one exception before the meeting
Consider an illustrative case: a supplier accepts only part of an overpayment claim. AP records the accepted amount, but the remaining balance is tracked in a personal spreadsheet.
The requirement could be: an authorized reviewer can see the unresolved balance, its supporting evidence and the next responsible person until the claim is closed. This wording gives the partner something to demonstrate and the business owner something to test.
Bring a record like this into the workshop:
| Field | Illustrative entry |
|---|---|
| Current issue | A partial settlement leaves a balance tracked outside the shared process |
| Supporting evidence | Redacted claim, supplier reply and the AP walkthrough |
| Business requirement | Keep the unresolved balance visible, with an owner and its evidence |
| Question for the partner | How would the in-scope standard process handle this case? |
| Acceptance check | A partial settlement leaves the correct balance open and traceable to the claim |
| Decision status | Open until the proposed approach has been demonstrated and reviewed |
The workshop may conclude that the standard covers the need, that a business procedure should change, or that further solution assessment is needed. A difference from today’s process is not automatically a reason for an extension. Let the partner assess configuration, integration and extension options against the agreed architecture and governance.
Leave with decisions someone can act on
For each requirement discussed, record the agreed approach or unresolved question, its owner and the next action. Keep the evidence linked to the requirement so the same discussion does not restart when another team joins.
For accepted changes, identify the roles that need training and the procedures that must be updated. For open gaps, set a decision date and an acceptance check. A map approved as an accurate account of today’s process is not approval of the target design.
Agree the handoff format before discovery begins. The receiving team may need process models in Signavio and requirements or test records in its project delivery tool. Confirm what will be transferred and who will maintain it; a diagram export alone does not complete that handoff.
Where Duvo Clarity helps
Duvo Clarity uses guided screen walkthroughs, AI interviews and documents to prepare process maps and improvement recommendations for team review. It can help capture steps around SAP, including spreadsheet work and email handoffs, without first connecting to the ERP.
That reviewed evidence can support your workshop preparation. The implementation partner still owns the SAP solution assessment, and your business owners approve the requirements and changes. Discovery does not replace technical migration checks, configuration, testing or cutover planning.
If you already have reliable maps and sufficient evidence, use them. If important steps remain undocumented, start with one process through Duvo’s process discovery offer, or discuss the wider preparation through the SAP migration offer. Bring the workshop scope and the partner’s expected outputs so the discovery answers the right questions.
For help choosing the capture method, see process mining vs process discovery. For a provider evaluation brief, read how to choose process discovery software.