Mentioning Supplementary Content

These are the 12 principles of the Agile Manifesto. They do come from Software Development, but they’re valid in any other environment too.

This picture shows some of the most frequent reasons that can lay the foundation of a strong business case for implementing SAP S/4HANA.

SAP Best Practices bring to customer organizations the process standardization that large companies are seeking after merging or after years of operations and customizations, so as to simplify and unify the business processes across all sites.

The Agile approach to address complex systems implementation is to 'slice the elephant' into smaller and manageable pieces, so that it can be released with controllable costs and risks.

Having multiple and smaller releases is the Agile approach in opposition with the big-bang approach that's very common in projects delivered with the traditional waterfall approach.

The selection of the business areas to be covered by the first release is the first step in deciding how to determine the scope for the releases. Other business areas will continue to work in parallel with the legacy system. Numerous elements must be considered, for example:

• Interfaces with other systems in the landscape

• Data migration needs

• Business Data (Master and Transactional) that must be maintained and kept coherent in both new and legacy systems

• Operations activities

In this customer example, along the core business processes (Logistics, Warehousing, Plant Operations, and Plant Maintenance), the management support functions have been selected for the first release.

The example customer is a global company with more than 250 agencies worldwide. Only 12 countries of the total amount will be impacted by the first release as these have many commonalities and only a few country-specific requirements.

Agencies from all the other countries will have their systems implemented in subsequent future releases.

The key features that secured the project's success are (some of them are the same in traditional projects):

• Clear project vision and strategy

• Customer involvement

• SAP roles and SAP Solution Manager usage as a single source of truth for the solution documentation

• Quality gates, KPIs, and strong budget management.

The agility proven by the teams handling the configuration and custom code development brought extra speed and risk alleviation.

Testing executed during the Sprints, by Business Experts from the customer side who were participating in the project as Scrum team members, brought early solution acceptance by the business.

The discipline of the Agile teams that were driving the project provided the cadence for synchronization with the non-Agile teams and standardization in managing activities, risks, and impediments.

Sprint by Sprint the predictability of the new feature ready to be tested increased, which made the planning of other activities delivered by the non-Agile teams easier: integrations, infrastructure, training, migration, and so on.

The early acceptance of functionalities by the business, after the first couple of Sprints, motivated the Scrum to keep the pace.

Transparency brought by Focused Build and other Agile-specific information radiators for the Scrum Team progress and impediments proved its value to the management team who was able to take timely decisions about scope and budget.

The clear Design to Budget approach gave the Product Owners the power to decide how to split the available budget among all requirements, including changes in the area of their responsibility. POs define the new solution with their decisions within the given budget.

Besides the definition of specific points of contacts within the Scrum teams, the project has benefited from the frequent multilevel synchronization among Agile and non-Agile teams that's specific to Scrum:

• Weekly SoS

• Weekly PO synchronization

• Sprint Planning

• Sprint Review

The project was delivered with Activate Methodology. The Foundation phase is an enhancement to the SAP Activate standard phases. It was designed to set the focus on the solution landscape provisioning and baseline configuration activities done by the SAP experts to prepare the solution for the Fit-to-Standard workshops.

All the other activities in the Explore phase related to workshop preparation covered the preparation of the organization: customer team enablement on Best Practices, on tools, and on the discipline of running the workshops.

The Product Backlog design was time boxed to one month and limited to the deltas for the first two Sprints. The design of the requirements continued throughout the Realization phase, as part of Sprints activities, in a just-in-time approach for the requirements identified as valuable for the upcoming Sprints.

The Explore strategy for the product backlog creation was to focus only on the global processes and requirements to build the common and standardized foundation for all the 12 countries in the Release 1.

The project management team decided to organize the Sprints into Waves, each Wave being composed of three Sprints of three weeks plus a hardening, integration, and planning (HIP) Sprint. The HIP Sprint was used for end-to-end functional testing, integration testing, and planning for the next Wave.

Starting with the second Wave:

• Country-specific legal requirements have been identified and integrated into the Product Backlog.

• Data migration workstream provided customer-specific data for Wave testing in the quality systems.

In the Deployment phase, a special importance has been given to the business acceptance tests on migrated data to validate the correctness of the migrated data and the solution robustness.

The project organizational chart shows the hybrid Agile approach: business aligned teams were organized into Scrum teams, whereas the other activities delivered by the other SAP Activate workstreams were organized as traditionally-provided services for the Agile teams.

The Scrum teams were organized to deliver end-to-end processes in an attempt to minimize the team dependencies, for example:

• Order to cash

• Invoice to Payment

• Request, Procure to Pay

In the Scrum teams, there were appointed representatives to the non-Agile teams. These points of contact (PoCs) were attending in the traditional teams' synchronization calls with the objective to clarify the requests coming from the Scrum teams. These PoCs were also participating to work, if necessary, in the traditional teams to facilitate the interactions between the teams.

So, the PoCs were the bridge between the two worlds, Agile and non-Agile, and were participating as team members in both types of teams.

As visible in the org chart, a special attention was given to Organizational Change Management activities. Two teams with specialized focus were created to ensure the solution adoption by the organization from day one after go-live.

In all teams, there was at least a double presence – customer and SAP. In some teams, also third-party experts with special skills, like analytics or data migration, were also involved.

For the Scrum Teams, the Product Owner always came from the Customer, and they were seconded by an SAP Lead, an expert in the SAP solution for the respective business area.

In some teams, the PO came from the Business. In other situations, the PO came from the Customer IT department but had a deep knowledge of the business needs and synchronized often with Key Users and Business Stakeholders.

Also from the Customer organization, the Product Owners were coordinated by an Area Product Owner called Workstream Lead in this organization chart. There were two such Area Product Owners: one for Management Support Functions and another one for Core Business.

Their role was more on coordination among POs and also on budget management at the area level.

SAP Cloud ALM aids in the implementation and operation of intelligent cloud-based and hybrid business solutions. You can benefit from a ready-to-use, native cloud solution that's designed to serve as the central entry point for managing your SAP landscape. This solution offers content-driven guided implementation and highly automated operations.

SAP Cloud ALM is included in:

• Cloud subscription containing Enterprise Support
• Cloud edition
• SAP Enterprise Support

SAP Cloud ALM supports the complete application lifecycle from design, build, test, and deploy. Also monitoring capabilities and applications supporting the operation of SAP solutions are included. The provided capabilities are all built-in, preconfigured, and ready-to-use.

New capabilities are added constantly and delivered biweekly to the customer tenants – see SAP Road Map Explorer.

SAP Cloud ALM manages not only cloud but also hybrid (combination of on-premise and cloud) solutions.

SAP Cloud ALM provides support in configuring and managing projects with SAP Activate on a broad list of roadmaps (for example, SAP S/4HANA Cloud, public edition implementation and upgrade, SAP S/4HANA Cloud, private edition implementation, system conversion, SAP Ariba and SAP Fieldglass implementation, SAP Success factors implementation, Intelligent Enterprise implementation, and so on).

For further information, check the Help Portal link: https://help.sap.com/docs/cloud-alm/applicationhelp/consuming-tasks-from-sap-activate.

This end-to-end process flow provides the key activities for each project role during the whole project lifecycle.

You can select each activity to open the how-to demo for detailed guidance.

As visible in the figure, SAP Cloud ALM supports Agile Sprints from the Explore phase down to the Deploy phase in SAP Activate Methodology.

SAP Cloud ALM provides a Process Hierarchy application to manage the processes for the solution. For each solution process in SAP Cloud ALM, you can have associated Requirements, User Stories, Project Tasks, and Test Cases.

The Requirement concept in SAP Cloud ALM corresponds to a large functionality to be implemented or an Epic from the Agile vocabulary. A Requirement has multiple Features (transport bundles) associated with it, and a Feature can contain multiple User Stories.

Requirements are expectations that must be fulfilled from a business point of view. They represent business needs from a customer perspective.

In SAP Cloud ALM, you collect all requirements resulting from the Fit-to-Standard workshops. Each requirement is linked to the respective process. It enables the members of the implementation project to track the progress of each requirement from different angles, for example, from task, development, and test perspective.

For a requirement, create the following:

• A user story for the development team, to be assigned to sprints and to the responsible team.

• A feature to define how and when the requirement is deployed to a QA or production system, for example.

• Sub-tasks in the user story, to be assigned to individual team members.

• Additional project tasks, for example, if someone must take care of training activities or an authorization concept.

The Feature concept in SAP Cloud ALM is created as a collection of Transports that contain the changes produced as a result of User Stories implementation.

A User Story in SAP Cloud ALM describes a small functionality that can be finished within one Sprint.

Links to the ALM SAP Help Portal for Project Leads:

• Setup Project – Projects and Setup | SAP Help Portal
• Onboarding Team Members – https://help.sap.com/docs/cloud-alm/applicationhelp/maintaining-users
• Plan Releases and Timeboxes – https://help.sap.com/docs/cloud-alm/applicationhelp/project-planning-timeboxes
• Manage and Execute Project Tasks – https://help.sap.com/docs/cloud-alm/applicationhelp/task-management

SAP Cloud ALM Support for Business Process Experts activities:

• Select Process Scope – https://help.sap.com/docs/cloud-alm/applicationhelp/manage-scopes

• Collect and Document Requirements – https://help.sap.com/docs/cloud-alm/applicationhelp/creating-requirements
• Approve Requirements – https://help.sap.com/docs/cloud-alm/applicationhelp/approving-requirements

SAP Cloud ALM Support for Change and Deployment Lead activities:

• Create Features – https://help.sap.com/docs/cloud-alm/applicationhelp/creating-features
• Create/Assign Transports – https://help.sap.com/docs/cloud-alm/applicationhelp/creating-transports
• Deployment to QAS – https://help.sap.com/docs/cloud-alm/applicationhelp/deploying-transports-of-feature
• Deployment to PRD – https://help.sap.com/docs/cloud-alm/applicationhelp/deployment-confirmation

SAP Cloud ALM Support for Configuration Expert/Consulting Expert activities:

Create/Plan User Stories for Developments – https://help.sap.com/docs/cloud-alm/applicationhelp/agile-support

SAP Cloud ALM Support for Test Lead and Testing Expert activities:

• Create Test Cases – https://help.sap.com/docs/cloud-alm/applicationhelp/test-preparation
• Manage Test Plan and Assign Testers – https://help.sap.com/docs/cloud-alm/applicationhelp/test-plans
• Execute Test Cases – https://help.sap.com/docs/cloud-alm/applicationhelp/test-execution
• Process Defects – https://help.sap.com/docs/cloud-alm/applicationhelp/defects

The task content for your project follows the hierarchy provided by SAP Activate.

To automatically derive the tasks from the SAP Activate methodology, select the product-related task roadmap when you create your implementation project. This ensures that your team is using the correct roadmap for the implementation of your cloud product.

The content from the SAP Activate methodology gets the source attribute SAP Activate Roadmap, so you can easily distinguish it from manually created tasks and tasks generated from requirements.

The SAP Activate content is updated regularly, in both Roadmap Viewer and SAP Cloud ALM. You can track the changes in the history of the Projects and Setup app.

Project Progress Reporting application in SAP Cloud ALM shows the progress in terms of task completion for phases, sprints, and deliverables.

You can filter the report for scope, tasks types, priorities, teams, and user types.

The report outlines all planned tasks, completed tasks, and remaining tasks, as well as the distribution with regard to phases.

SAP Cloud ALM serves as a central platform for you to access business process content that's provided by SAP and partners. In addition, you can create your own process structures.

During scoping, you add the solution scenarios that define the project process scope.

In the SAP Cloud ALM Processes app, you can manage the scope of your solution processes and create your own process structures.

The standard business process content is the foundation of your projects. It defines and organizes the relation between project tasks and business areas.

In the Process Authoring app, you can create and maintain any custom solution process.

Apart from creating a diagram from scratch, you can create a diagram from an existing SVG or BPMN file.

Manually create requirements for the entire process or individual elements of the process.

In the Processes app, you can create a requirement for a whole process or for individual elements like a lane, process step, or connector.

You can perform mass uploads for requirements. If a requirement has children or dependencies, this hierarchy is also included in the upload.

When a requirement has been completed and approved, you can use it to generate user stories and tasks for development and testing.

In the Analytics app, you can use the Solution Process Traceability for in-depth reporting. Here, you can analyze the readiness of your scoped solution processes based on the progress of the related requirements and tests.

For each solution process, you can check the status and numbers of requirements, user stories, project tasks, and test cases. There are extended filters for related objects like requirements, user stories, project tasks, test preparations, and test executions.

Use the Documents app to create, edit, and delete documents.

You can add a document text, such as a description of steps for a configuration, and further information like a reference to an external source.

The status is set to In Progress by default. However, this can be changed at any time. There are three statuses for documents:

• In Progress: Used for documents that are still being worked on

• In Review: Used for documents that are still to be reviewed and that aren't yet ready to be released

• Released: Used for documents that are completed

To manage external documents that are stored outside of SAP Cloud ALM, the References function is introduced. External documents can be referenced in the Documents app by linking via URL.

To each project, in SAP Cloud ALM, you can assign one deployment plan. It helps the release manager to drive a deployment schedule to production.

A deployment plan serves as a container for Releases: One deployment plan can include several releases.

The Test Preparation app in SAP Cloud ALM is where you prepare your test cases before they can be executed.

Test plans are sets of test cases that are executed in specific test cycles, helping you run your testing activities in iterations.

While you can also carry out your testing activities without test plans for a leaner approach, in larger implementation and transformation projects, it might be necessary to reuse the same or a similar set of test cases in multiple test phases. This way, each test case occurrence can be executed within the defined time frame and receives a dedicated execution context.

In the SAP Cloud ALM Test Execution app, you can execute the test cases that have been prepared in the Test Preparation app.

As a testing expert, you can monitor the progress and the outcomes both of manual test runs executed in SAP Cloud ALM, and of automated test runs executed in the connected test automation tool.

If you discover a deficiency during a test run, you can enter a defect directly from the Test Execution app.

In the Defects app, you can find more detailed information about the defects in your project.

By default, the list shows only open defects. To also see closed defects, add the Closed attribute to the Defect Status in the filter bar.

Track the readiness of requirements for your projects based on the status of related project tasks, user stories, and test cases.

In the Analytics app of SAP Cloud ALM, you can track the contents of each requirement.

If you would like to learn more about SAP Cloud ALM, please see:

• SAP Cloud ALM overview: https://support.sap.com/en/alm/sap-cloud-alm.html
• SAP Cloud ALM for Implementation: https://support.sap.com/en/alm/sap-cloud-alm/implementation.html

Please navigate to the Overview page for further details.

There's a set of input elements that are required for a successful Fit-to-Standard workshop that's validating the fitness of the business processes that are available in the solution standard as SAP Best Practices.

In the Discovery phase, the business areas to be covered by the solution are identified, and corresponding SAP Best Practices are selected. This selection along with the engagement proposal and statement of work that will be attached to the solution implementation contract.

In this same phase, the Customer must make sure that value drivers for the organization are identified as part of the value case and that success measures are established, for example, customer satisfaction index, number of complaints, cost-to-serve, capital employed, revenue per customer, and so on.

Based on these success measures, processes in scope will have business value associated, so that we can organize and prioritize the most valuable business processes in the workshops. That's why the process determination value is an important input for the Fit-to-Standard workshop.

To be able to show the Best Practices processes, these must be activated in the sandbox or demo landscape that is used for the show and tell in the workshops.

The standard and most important outcome from the Fit-to-Standard workshops is, besides the Product Backlog, the validation of the solution fit. Issues might be identified while configuring the baseline solution to prepare it for the workshops. Any standard software defects must also be collected and raised to the product team to be managed before the go-live through SAP Support.

User Authorization related requirements must be identified and collected as Product Backlog items and the Authorization Concept document is being drafted.

Although the responsibility for the quality of the Fit-to-Standard workshops' outcomes is shared between SAP and the Customer, specific roles, like Solution Architect and Project Manager, are playing more important parts in this process.

A truly Agile Explore phase is run in Sprints, with the Agile Team members onboarded and Product Owner and Scrum Master staffed and effective in their roles.

Baseline Build is the name under which we can group all the activities necessary to prepare the standard SAP solution for Fit-to-Standard workshops.

Sprints in Explore are recommended to be shorter, as a rule of thumb – two weeks.

As a final outcome for the Explore workshops, we'll have a Baseline Solution with its corresponding high-level process documentation that contains the validated Best Practices for the scope and a Product Backlog that contains the additional business requirements for the solution, ranked by their value.

This Product Backlog is created with the Customer leadership. The Product Owners who rank the backlog belong to the Customer organization, and, therefore, the Product Backlog is endorsed by the Customer.

In some situations, backlog approval is required by a decisional body created for this purpose in the Prepare phase of the project.

The fact that the Product Backlog gets approved doesn't mean that it stays unchanged until the end of the project. It's just establishing the initial baseline for the scope of work that was identified necessary as a result of the Explore phase workshops.

During the Realize phase, new requirements will typically be identified. If their value is higher than the value of the remaining and unfinished product backlog items, changes in the Product Backlog will be made to maximize the value delivery as per the change procedure agreed in the Prepare phase.