11.5 Fit-to-Standard Workshops, Design Workshops, and Business Process Configuration

Fit-to-Standard Workshops, Design Workshops, and Business Process Configuration

Fit-to-standard workshops in the Explore phase decide how the system will be configured in the Realize phase. For a sales consultant, they are where requirements such as an extra field on the sales order or a different order confirmation are found and documented. The S4C03 units Gathering Data in Fit-to-Standard Workshops and Validating and Configuring Business Processes describe the approach.

Purpose by Project Type

In both cases the team decides whether SAP GUI transactions are replaced by SAP Fiori apps, documents and prioritizes the requirements, and then holds design workshops and plans the configuration sprints (prioritized backlog, estimated effort).

Choosing the Workshop System

• SAP S/4HANA Fully-Activated Appliance from SAP Cloud Appliance Library: the best choice for most customers, including conversions, where it shows compatibility-scope processes and new functions.
• SAP S/4HANA Cloud Private Edition Customer Evaluation System, delivered by SAP Enterprise Cloud Services: it takes longer and costs more, so it suits larger customers who want to reuse its configuration later.
• Converted sandbox: the first conversion can take a month or more, and SAP Best Practices content cannot be deployed into a converted system with Solution Builder, so it is often not ready in time.

Planning the Workshops

• Demonstrate the complete test procedures of each process's test script (the preliminary steps can be skipped).
• Use the length of the test script as a gauge: the course compares Material Requirements Planning (J44, about 40 pages) with Production Capacity Leveling (3LQ, 11 pages). One or two processes fit into a half-day workshop and two or three into a full day.
• Group processes in which the same business roles do most of the work, using the process flows in SAP Signavio Process Navigator.
• Run the chart of accounts and organizational structure workshops first; the other line-of-business workshops can follow in parallel.
• Invite at least two and no more than four people per business role. If customer experts cannot find time, escalate through the project managers to the executive sponsors, who must tell managers that the workshops have priority.

Running a Workshop

Each workshop starts with a mini kick-off that explains why the participants are there, where the project stands (Explore, then Realize, then their UAT), and the cloud mindset: change the standard as little as possible, use the in-app tools first, move further extensions to SAP BTP, and avoid backend changes. Every change has to be checked after each upgrade (the Release Assessment and Scope Dependency tool helps), so only need-to-have requirements count, not nice-to-have ones. Participants also learn where to find process flows, test scripts, and tutorials: in SAP Signavio Process Navigator and in the system help (question mark icon, then the graduation cap icon, or the learning center).

For each process, the team:

1. Shows the process flow and test script in SAP Signavio Process Navigator and runs the test procedures in the sandbox, including how to reach embedded support.
2. Validates the level 2 answers and gathers the level 3 answers of the Business Driven Configuration Questionnaire (BDCQ).
3. Documents requirements in SAP Cloud ALM: business role, space, and page changes; data visibility restrictions; custom fields and custom logic; form and email template changes; analytical app changes; additional integrations; data migration values or contacts; and the perceived change impact, which goes to the change management team.

Ideally two consultants run a workshop: one demonstrates and moderates, the other records each requirement separately in the SAP Cloud ALM Processes app (Create → Requirement); the Requirements app shows the master list. A requirement is the difference between what the standard system does and what the customer needs it to do.

Design Workshops

Design workshops document solutions for the prioritized delta requirements; requirements already met by the preconfigured processes are not documented. The design document contains a short process description, the high-level requirements, the process flow changes (the SAP Best Practices flow is the baseline, so only adjustments are shown), a configuration summary, user roles and authorization requirements, interfaced IT systems, customization requirements and solutions, developments, organizational aspects, and the process quantification (data volume). In new implementations, detailed configuration requirements are documented outside the design document and linked to a process; in conversions, the focus is on what configuration must change.

A master data design document is produced (in conversions, updated) and later used for the data migration design. Functional specifications are written for the WRICEF objects (workflows, reports, interfaces, conversions, enhancements, and forms) so the Realize phase can be estimated. Custom business roles also need custom spaces and pages.

Configuring and Validating the Processes

• New implementation: SAP Best Practices are deployed with the Solution Builder (transaction /SMB/BBI). A solution contains scenarios, and each scenario consists of building blocks with Customizing settings and master data steps. Content is activated once in the development system and transported to quality and production. Copy a process before changing it, because directly changed processes no longer receive enhancements during upgrades; entirely custom processes are documented in SAP Signavio Process Manager. A report documents the configuration for any level (activity, building block, scope item, or solution). As a standard service, SAP activates the SAP Best Practices the customer selects during provisioning; customer-specific configuration is a partner service. The LoB experts then enter their BDCQ values in the customizing tenant and work through their open requirements.
• System conversion: the sandbox is converted and tested first. Sprint 1 tests the current processes, for example in order to cash: review an open sales order, create the delivery, post goods issue, create the billing document, and complete the collection. Sprint 2 looks for improvements, mainly replacing SAP GUI transactions with SAP Fiori apps that the customer can now try with their own data. The other systems are then converted the same way and tested formally in SAP Cloud ALM.
• Partner solutions: SAP Certified Solutions (listed in the SAP Certified Solutions Directory) and SAP Qualified Partner-Packaged Solutions (found in the Partner-Packaged Solution Finder) can add industry content on top of the SAP Best Practices baseline.