What Fit-to-Standard Means
Fit-to-standard is the core methodology of SAP Activate's Explore phase. The principle is straightforward: prove that SAP standard processes work for the business before introducing any customization. If a standard process fits, you configure it. If it doesn't fit, you document the gap and assess whether it requires a process change, a configuration workaround, or custom development (a RICEFW object).
The goal is to minimize customization. Every RICEFW object you avoid is tens of thousands of dollars saved in development, testing, and long-term maintenance.
Who's in the Room
A well-run fit-to-standard workshop typically involves:
- Functional consultant — leads the session, demonstrates SAP standard processes, and captures requirements
- Business process owners — the people who actually run the business process today and will use SAP going forward
- SAP solution architect — provides cross-module perspective, catches integration impacts, and challenges unnecessary customization
- Note-taker / business analyst — documents decisions, gaps, and action items in real time
The functional consultant runs the show. The business process owners are the subject matter experts. The solution architect is the guardrail.
How to Prepare
Preparation is everything. The quality of a fit-to-standard workshop is directly proportional to the preparation that went into it.
Build the process hierarchy first
Before a single workshop, you need a process hierarchy — L1 modules (Finance, Procurement, Sales, Manufacturing) broken down into L2 business processes (Procure-to-Pay, Order-to-Cash, Record-to-Report). This hierarchy becomes the scaffolding for every workshop session.
Draft user stories in advance
Don't walk into a workshop with a blank page. Your functional consultants should have pre-drafted user stories based on discovery interviews, existing process documentation, and industry best practices. The workshop is for validating and refining — not for starting from scratch.
Configure the SAP demo environment
The functional consultant should have a pre-configured SAP system with relevant master data and sample transactions. Showing the business a live SAP process is infinitely more effective than describing it on a slide.
Running the Session
Step 1: Walk through the SAP standard process
The functional consultant demonstrates the end-to-end process in SAP. For a Procure-to-Pay workshop, this might be: purchase requisition → purchase order → goods receipt → invoice verification → payment. Show real screens, real transactions, real data.
Step 2: Business confirms fit or identifies gap
After each process step, the business process owner confirms: "Yes, this works for us" (fit) or "No, we need something different" (gap). Capture the decision immediately — not in a follow-up email, not in a separate meeting.
Step 3: Gap captured as a user story
Every gap should be captured as a structured user story: As a [role], I need [capability], so that [business outcome]. Include the fit/gap classification and any context about why the standard process doesn't work.
Step 4: Gap assessed
For each gap, the team assesses the resolution path:
- Configuration change — SAP supports it, just needs to be configured differently
- Process change — the business can adapt their process to match SAP standard
- RICEFW — custom development required (report, interface, conversion, enhancement, form, or workflow)
This assessment is critical. A RICEFW that should have been a configuration change is wasted money. A process change that should have been a RICEFW is a frustrated business user.
What Good Looks Like
A well-prepared, well-run fit-to-standard workshop produces 3-4 RICEFWs per session. The majority of gaps are resolved through configuration or process change. Decisions are captured in real time. The business process owner leaves feeling heard and understanding the tradeoffs.
What Bad Looks Like
A poorly prepared workshop produces 30-40 RICEFWs because nobody prepared, nobody challenged the business, and every gap defaulted to "we'll build something custom." The functional consultant didn't demo SAP standard. The solution architect wasn't in the room. The business process owner listed every feature from their legacy system and assumed SAP would replicate it exactly.
A RICEFW that could have been avoided with better workshop preparation costs $30,000-$80,000 to build, test, and maintain through every SAP upgrade.
Capturing Workshop Outcomes
The outputs of every fit-to-standard workshop should include:
- User stories with fit/gap classification — the atomic unit of requirements
- RICEFW objects for confirmed gaps requiring custom development
- Configuration items for gaps resolvable through SAP configuration
- Process change decisions where the business agreed to adapt
- Open items requiring follow-up with additional stakeholders
These outputs need to live in a single system — not scattered across Word documents, Excel trackers, and meeting notes that nobody reads after the workshop ends.
The System of Record Principle
The workshop is where the most critical decisions of an SAP implementation are made. Requirements are born here. RICEFWs are identified here. Process changes are agreed here. If these decisions aren't captured in a structured, searchable, traceable system, they're effectively lost.
Three months later, during the Realize phase, a developer asks: "Why do we need this RICEFW?" Nobody remembers. The workshop notes are in someone's email. The Excel tracker has a one-line description. The business process owner who made the decision has moved to another project.
Axia was built to solve this — a platform where every workshop decision, every user story, every fit/gap classification, and every RICEFW links back to the process flow it came from. One source of truth from Explore through Deploy and beyond.