Explore Phase Overview

Let’s have a look again at the key activities in each SAP Activate project phase for cloud implementations.​

The main purpose of the Explore phase is to perform a Fit-to-Standard Analysis to validate the solution functionality included in the project scope and to confirm that the business requirements can be satisfied. ​

Identified deltas and configuration needs are validated by the product owner and, if approved, added to the Product Backlog to be implemented in the Realize phase. To collect the User Stories, in a Fit-to-Standard approach, the solution experts lead a series of structured show-and-tell sessions. The goals of these workshops are to review with the Customer the SAP Best Practice or SAP standard functionalities, to identify delta requirements and to determine the configuration of the SAP Cloud solution.​

Business Driven Configuration Questionnaires are available as accelerators in the SAP Roadmap Viewer to support the preparation of the Fit-to-Standard Analysis.​

​

There are five steps in the Fit-to-Standard workshop execution that lead to the sixth one that is actually its ultimate objective – to enable the customer to execute the standard scenarios in the Starter System.​

The preparation for the workshop is key for its success.​

In the case of a public cloud implementation scenario, the preparation includes the customer self-enablement activities and the completion of the Business Driven Questionnaire for the business processes that are discussed in the workshop.​

The demonstration of the process flows is done in the Starter System by an SAP Expert who is highlighting the areas that require configuration decisions. Standard process fit is discussed with the customer and identified requirements are collected in the Product Backlog. Some configuration decisions can be taken during the workshop itself or written down for further discussions and alignment. The customer has as the responsibility to provide value lists (for example, product group definition) and configuration values for Product Backlog refinement.​

The workshops are time-boxed so that the entire functional scope can be reviewed and Product Backlog entries are created with a lower or higher level of additional information associated. The right level of refinement for the requirements in the Product Backlog is achieved through Backlog Refinement sessions in a just-in-time manner when making them ready them for Sprint execution.​

The private Cloud has additional steps in the workshop as there's more flexibility in terms of enhancements possible for the standard – workflow, report, interfaces, conversions, enhancements and exits, and forms (WRICEF) requirements. So, Step 5 has, besides configuration, the identification of WRICEF type of work.​

​

*WRICEF objects and design documentation are more common in private cloud implementations. Public cloud offers less extensibility and fewer enhancements.​

After Fit-to-Standard Analysis, the identified Product Backlog is prioritized, because there's a new series of time-boxed workshops that follows – the Design workshops. ​

Product Owners are responsible for determining the top priority Product Backlog items using specific prioritization techniques and having the SAP Experts input in regards to functional and technical dependencies between backlog items. Only those top-priority requirements are scheduled for Design to make sure that the team has a refined backlog ready for the first couple of Sprints or more, depending on the allocated time for the workshops. These Design workshops are also used to have an agreement on the Design Decisions that will impact the Product Backlog implementation.​

We can see that there are iterations marked for both types of Explore workshops, which means that teams are already working in Sprints to create the Product Backlog. The Explore Sprints are typically shorter than the Realize Sprints to allow quick adaptation and fast learning about Customer context, needs, and ways of working.​

​

Looking at the Explore Sprint events, we can see that that Fit-to-Standard workshop sessions can be organized as Sprint Reviews. The feedback from the Process Experts to the demonstrated SAP standards is captured in the User Story format as entries in the Product Backlog.​

During the Sprint itself, all the activities revolve around the selected business processes and the preparation of the Starter System for the show and tell that's done in the Sprint Review. ​

Sprint Review duration in Explore might take an entire day, much longer that the Sprint Review in Realize phase – not only because feedback is collected during the session but also so that the Agile team gets the needed clarity to move forward. SAP experts get clarity about the Customer needs, and Customers get clarity about SAP Standard capabilities.​

The outcome of the Explore workshops resides in the Product Backlog that's created but also in the discussions, which generate shared understanding, aligning more and more the Agile team members towards the same goal. ​

​

Through the Sprint Retrospectives Agile team:​

• Develops a working model

• Gets more solid ​

• Identifies a common language and improves communication ​

• Becomes more effective in applying the Agile process

​

The Scrum Master importance in an Agile project is paramount because of the services delivered by this role to the Product Owner and to the Scrum Teams.​

Often the Scrum Master job is seen in relation with the scope size, and the budget for staffing Scrum Masters is saved for the Realization phase. This approach endangers the success of the Explore phase. Some of the possible effects are:​

• Product Owner’s low performance in delivering responsibilities​.

• Poor Product Backlog and Product Backlog prioritization, for example: Most of the Backlog Items are Must Have with no proper ranking​.

• Extended duration for the Fit-to-Standard and/or Design period. Common root cause: Timeboxes are ignored or longer time for reporting and resolving impediment​.

• Project and Teams not fully benefiting from the Agile process. Common cause: Roles aren’t fully understood, and the team needs practice before running a new process.​

In Agile projects, teams no longer create large Design documents or Business Blueprints as waterfall-based projects created.​

The figure, Solution Documentation (Process Design – Lean Approach), shows a collection or body of documents and objects (assigned to different levels of the process structure) that together make up the Design section of our Solution Information Assets held in the customer’s Solution Manager system for on-premise implementation.​

Similar documentation structure can be achieved with SAP Cloud ALM for Cloud implementation projects.​

Process Documentation created during the Explore phase can be stored in SAP Cloud ALM linked with the documented process. ​

There's an additional view in SAP Cloud ALM called Solution Process Traceability, which gives you a visual status of implementation progress at the process level.​

Looking at the Fit-to-Standard workshop from the input and output perspective we can turn them into checklists.​

Depending on the implementation type, public/private cloud or on-premise, the input varies only for the system conversions, where we have as additional inputs:​

• The simplification items resulted for the automatic assessment of the current solution implementation ​

• The list of the already implemented changes to the SAP base solution (existing WRICEFs).​

​

The output is always the same: the prioritized Product Backlog (from a business value perspective), the key decisions for solution Design, and, if time allows, the updated process diagrams to document the workshop agreements for business processes.​

​