Day 1 How Focused Build accelerates SAP S/4HANA projects

PUBLIC

Rajeev GollapudiAPR 2020

Day 1How Focused Build accelerates SAP S/4HANA projects

2PUBLIC© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ

SAP ALM Strategy

Introduction to Focused Build

Process Management with SAP Solution Manager and Focused Build

Requirements Management with SAP Solution Manager and Focused Build

Agenda – DAY 1


What is Application Lifecycle Management (ALM) for SAP solutions?

Demand

TestBuild

Deploy

Operations

Implementation

Improve

DiagnoseCorrect

Monitor

Keep your business running and get faster value.

&


Start Running

§ Accelerate time to value

§ Reduce cost of implementation

Run with the Best

§ Don’t re-invent the wheel

§ Use best-of-suite

Keep Running

§ Ensure business continuity

§ Reduce cost of operations

Run at your Best

§ Benchmark against business KPIs

§ Implement business process improvements

Do you leverage all ALM values?


Accelerate Time to Value andReduce Cost of Implementation

§ Leverage pre-configuration§ Follow agile implementation approach§ Only test what matters§ Accelerate test management and execution§ Automate tasks§ Avoid custom code

Start RunningSpeed up innovation

Cost

Reduce Costof Implementation

Reduce Time to Value

Profit

Time


Ensure Business Continuity§ Analyze risks§ Detect problems pro-actively§ Accelerate problem resolution§ Improve business operations

Reduce Cost of Operations§ Apply best practices§ Standardize processes§ Centralize operations§ Automate processes

Keep RunningEnsure efficient IT operations

Reduce cost of operations to have more budget for value-generating projects

The average cost of 1 minute downtime is more than 5,000 US$ (including production loss) *)

Cost ofOperations

Profit

*) Gartner, 2014


Benchmark Business KPIs§ Identify business process improvement potentials

Implement Business Process Improvements§ Reduce backlog§ Increase throughput§ Shorten lead time§ Improve automation

Run At Your BestHelp the business run better

ProfitBusiness Process

Improvement


Don’t re-invent the wheel§ Learn from the ALM

community§ Implement community-

proven practices§ Collaborate with peers

Run With the Best ALM from SAP

Accelerate ALM adoption

Standardize ALM

Use best-of-suite§ Run one integrated ALM§ Fulfil all your ALM needs § Join thousands of successful

ALM customers

Your best-run

ALM


Start Running Run with the BestKeep Running Run at your Best

In a Nutshell

Don’t look elsewhere – Leverage the ALM offerings from SAP

For cloud-centric customers

For on-premise centric customers

For customers withadvanced needs

+


Start Running Run with the BestKeep Running Run at your Best

In a Nutshell

Don’t look elsewhere – Leverage the ALM offerings from SAP

For on-premise centric customers

+


SAP S/4HANA Project Kick-Off

Go-Live SAP S/4HANA Operate & Optimize

BP Improvement

SAP TransformationNavigator

SAP Model Company

SAP Best Practices

Data Volume Mgt.

ProjectManagement

SAP ValueAssurance

Make yourcase

CustomCode Mgt.

Landscape Management

App Ops BP Ops/Improvement

Readiness Check

SAP S/4HANA Project

Core

Content

Choice

Focused Build

ProcessManagement

TestSuite

Change Control Mgt.

Requirements ReleaseMgt.

SAP Solution Manager and Focused Build for SAP S/4HANA

Business ProcessReality Check

SAP S/4HANA Move

SAP ActivateMethodology


Deployü Transport controlü Change traceabilityü Deployment managementü Release planning ü Retrofitü Quality gate managementü Change analytics and diagnostics

Testü Manual testsü Automated tests for SAPü Test automation frameworkü Test dataü Change impact analysisü Test planningü Test analytics

Design and buildü Graphical modelingü Process managementü As-is, reference, and to-be landscapesü Connection to run time and design timeü Requirements managementü Solution readiness dashboard

What are we delivering in SAP Solution Manager ?

Plan and controlü Build project managementü Financial project managementü Effort planning and time recordingü Resource managementü Work breakdown structureü Project reporting

For the Intelligent Enterprise

Supporting on-premise,hybrid, and cloud

environments

Open and integrated

One, preconfigured, ready-to-go solution

Implementation experience for low TCI of SAP solutions, covering the complete implementation lifecycle from design to deploy


As of 2020, the usage rights of SAP Solution Manager include Focused Build and Insights

at no additional costs!


Focused Build solution for SAP Solution Manager

Requirements to Deploy

Agile development projects: from sprint to

release

Project governance with automated status

reporting

Modern applications with high usability for

all involved roles

Prepare Explore Realize Deploy Run

Focused Build is a turnkey solution to manage agile development projects.

Requirements management within

process models

Role-based rollouts

�

�

�


Project Management

Sprint 1..n

Task 1..n

Wave1

Milestone

Q-Gate

Focused Build – Architecture Overview and Integration Model

Test Suite

Test Plan Test Package

Solution Readiness Dashboard

Process and Application Landscape

Process Management

�Test Cases

Branches

�Design Documents

�Requirements Work Packages

�Work Items

Requirements / Work Packages / Work Items

�

Release ManagementRelease Number and CycleChange Control Landscape


ü If it is a business process-driven project (for example, based on SAP Model Company services or SAP Best Practices content or customer-driven process structure)

ü If there are many (>30) WRICEFs or gaps expected that must be realized by development and consulting teams

ü If the project team is distributed over several locations or remote delivery is expected

ü If an SAP Value Assurance service package is involved, as Focused Build services are involved in the deliverables

ü If the PMO wants to use a project tool that supports standardized activities in the project – starting from target business process modelling, requirement backlog, developing, project documentation, testing

ü If SAP Solution Manager is in use or planned to be used in the operation after the go-live

ü If the project approach wants to follow basic agile principles or the SAP Activate methodology

ü If the project starts soon and there is a need for a holistic implementation tool ASAP

Focused Build for SAP Solution ManagerWhen should Focused Build be strongly recommended

* If any one of these conditions is met, Focused Build should be considered.

Demo – How to run a SAP Project Live!

Focus Build – PROCESS MANAGEMENT


Benefits of Process Management in Focused Build

IT Service Management

TestManagement

ChangeManagement

ProjectManagement

ReleaseManagement

Business Process and

Interface Monitoring Process

Management

TransportManagement

The usage of Process Management in Focus Build is a fundamental deep integrator between documentation, change and test management.


Process Management in Focused Build covers the following tasks§ Scope and import best practice or model company content§ Document implementation of the solution by:

▫ Requirements▫ Creation of specific design documents▫ Assignment of technical objects required to satisfy the requirements

§ Model BPMN diagrams for business processes§ Monitor the solution documentation progress

Efficient Process Documentation is Key for Project Success


Access SAP Solution Manager via Fiori Launchpad

Access all SAP Solution Manager functionalities via the Fiori Launchpad.

Use the predefined role specific areas or create your own Home view.


Solution Documentation with SAP Solution Manager 7.2

Process Hierarchy and Process Diagrams are two sides of the same coin. They are managed as a whole.

Process Hierarchy

Process Diagrams


What is a solution?

Solutionis the sum of a company’s systems, applications and

processes. It acts as a container for versions of solution documentation, one of which is the production version

Information about system landscapecontains the information about the entire system landscape and orders it in Logical Component Groups

Change Control Landscapespecifies which parts of a Logical Component Group are relevant to the Change Control Management

Solution Documentationcontains the information technical objects, their use by business and business process documentation.

Sites conceptallows to represent a complex system landscape situation in a very simplified way in solution documentation. It takes care on appropriate navigation to a dedicated landscape depending on site you selected.

Branchesrepresents a version of the solution documentation containing processes, libraries and systems.

Scopesallowing focusing on a subset of solution documentation.

Standardsdefinition of document templates which are used in the solution for documenting processes and libraries.

Standards

SitesChange ControlLcsp

System Landscape

SolutionDocumentation

Scopes

BranchesProduction

PRD

OperationsPRD

MaintenanceDEV & QAS

DevelopmentDEV & QAS

DesignSandbox

ImportSandbox


Best-Practice Approach for Branch Setup (1)

= Change controlled

§ Production branch– Production branch represents the productive solution

§ Operations branch– Operations branch to apply monitoring instrumentation

§ Maintenance branch– Maintenance branch to change the productive solution

= Locked

ProductionPRD

As-is solution

To-be solution

�


As-is solutionTo-be solution

Fix & Enhance Innovate



= Change controlled




= Locked

ProductionPRD

As-is solution

To-be solution

OperationsPRD






= Change controlled




§ Innovation branches– Import branch to import new best-practice processes– Design branch to design customer target operating

model– Development branch to build the actual operating

model

= Locked

ProductionPRD

As-is solution

To-be solution

OperationsPRD



DesignSandbox

ImportSandbox





= Change controlled

§ Design and Import branch– During run discovery workshops you are focused

▫ to scope SAP Best Practices and DBS model company content, and

▫ To model the to-be operation model and process flows

– Even though they are required for other purposes, you can ignore all other branches than Design and Import

= Locked

ProductionPRD

As-is solution

To-be solution

OperationsPRD



DesignSandbox

ImportSandbox




Branch content: Re-use concept with Libraries

Interface Library Configuration Library

Process Step Library

Development Library

Executable Library

Processes

Proc

ess

�

�

� � �

�

�

� �

� �

��

Library concept helps to re-use documentation elements to avoid redundancies


Branch content: Re-use concept with Libraries


Executable Library

Processes

Proc

ess

� ��

Every process step in a process has a corresponding process step in the library.

Process Step Original

Process Step Reference

Executable Reference

Executable Original

Element reuse by referencing procedure

– Library elements may be referenced in a process

– Library elements may be referenced by other library elements




Development Library

Executable Library

Processes

Proc

ess

�

�

� �

�

�

�

�

��

Document type basic setup

SAP Solution Manager allows to define document standards, by central definition of document types, their templates, allowed usages and completeness rules.

Minimum documentation standards and their typical usage:

Business process description

Functional specification type Interface

Technical design

Configuration guide

Functional specification type WRICEF

Functional integration test case description

Single functional test case description


Solution Documentation UI

Column Browser(Structure)

Elements List(Object assignments)

Attribute Pane(Attributes)

Global Functions


Sample Business Process Map


Delivery platform to manage implementations end-to-end

Model company assets:§ Business process hierarchy, end to

end scenarios and process diagrams by roles

§ Configuration and how-to guides, test and demo scripts, implementation tools

§ Ready to run appliance, including all applications, configuration and sample data

Roadmap (tasks)Best practices processes

LoB or industry solutionEnd-to-end processes

SAP DBS Model Company SAP Activate

+

Demo 1. Activate Content2. Solution Documentation3. Branch Concept4. Process Modelling

No of Scenarios: 8• 8 x End-2-End processes, split into 200+

Variants (only for testing purpose)

No of Processes: 600

No of Process Steps: 710035

PROCESS MANAGEMENT - VOLUME

• Defines the documentation structure for the entire process design• Interacts with the Process Models• The Process Hierarchy and Process Models are two sides of the same coin• Modular design vs E2E design• Tips

– Can import best practices as a starting point– It is imperative to avoid bottom-heavy process definition– Define your process hierarchy and process steps outside of SolMan Dev first

36

BUSINESS PROCESS DESIGN – PROCESS HIERARCHY

Folders (Process Groups) Scenario Process Process Step

37

PROCESS MANAGEMENT – EXAMPLE SUCCESS FACTOR

Requirements Management


What’s in Focused Build on top of SAP Solution Manager? Explore Phase

Requirements Management

§ Create Requirements in Validation workshops with customers for delta identification (Fit/Gap analysis)

§ Requirements are integrated into process context allowing better handover to build team

§ Multi-language support for Requirements§ Tight integration of Requirements Mgmt. into

solution landscape, process models, Work Packages, Work Items, Solution Documentation, and the Solution Readiness Dashboard


What happens during Fit/Gap analysis?

1. Reference Value• Provide Process, Value and

Strategic Context• Set boundaries and expectations• Tie to Business Case & Value

Drivers

2. Validation of SAP Solution• Show and tell SAP

standard key design elements

3. GAP Identification• Identify and document

gaps to standard; • Log additional scope

items

5. Delta Design• Update Business Models

and Process Design for delta requirements

• Solution Design and Visualize for the gaps

6. Verify & Accept• Verify process and solution

design• Drive acceptance for release

and sprint planning

4. Backlog / Gap Prioritization

Workshop Type ASolution Validation Workshop

Workshop Type BDelta Design Workshop

7. Release & Sprint Planning


Build Design: Example New ImplementationFit Gap Analysis and Delta Design – Methodology Overview

1. Finalize System Setup� Prepare additional sample data � Enhance system setup with add.

Scope

2. Fit Gap Workshops / Validation of SAP Solution� Show and tell SAP standard key

design elements / Gap Identification

3. Gap Documentation� Document and specify identified Gaps

in initial Backlog5.2 Design/Specify� Specify the work to be done, e.g.

� Create Delta Design Documents� Upload Configuration Documents

� Prepare distribution of work by definition of Work Items

6. Verify & Accept� Verify solution design� Acceptance Procedure

4. Delta Scope Prioritization

� Prioritization according to agreed criteria (e.g. Business Value, Criticality)

Step AFit Gap Analysis / Solution Validation

Step BDelta Design

Extend Processes which are not part of Best Practices, e.g.QM

Fit Gap Workshop per Solution Capability, e.g. operational procurement:- Process / Steps- Solution / Function- Roles- Frontend (Fiori vs. GUI)

Capture and classify identify gaps in backlog:- Document Requirements- Classification (process gap, functional gap, etc)- Initial solution proposal- Initial effort estimates

Central review of identified gaps:- Completeness - Priorization

Workshops per Line of Business, e.g. Sourcing and Procurement: - Present solution based on delta design- Capture open issues if required- Obtain sign off

Approve Requirements to be part of release,with Mass Change app

Verify Priority, Effort and Value with Requirement Management app

Best Practices / Model Companies uploaded to SAP Solution Manager

Process ManagementSolution Readiness Dashboard

Rework Requirements via Requirement Management or My Requirements app

5.1 Create Product Backlog� Prioritization

according to technical criteria (e.g. Development sequence)

Create Work Packages to be part of the first Wavewith Requirement Management app

Repeat this Wave planning activity for each Wave -> agile

Plan all Waves at once -> waterfall

Result: Product Backlog

To sign-off release Functional Specificationin My Work Packages app and set according Work Package Status

5. Delta Design

For real Gaps and WRICEF, create Functional Specificationin My Work Packages app

Create solution design:- Slice the Requirements into Work Packages which need to fit in one Wave- Document relevant configuration- Document solution for identifiedgaps e.g. One Delta Design forSourcing and Procurement

Repeat steps 5 & 6 at the beginning of each Wave


How to come to an Initial Backlog - SummaryStepsStep 1: Requirements are gathered with the help of Fit-Gap Workshops

§ The creation of an Initial Backlog is a process which typically lasts several weeks or month§ The Requirements definition process can vary very much, dependent of the SAP Partner and Implementation methodology

Step 2: Working with processes and process structures and diagrams§ Best Practice is, to start with predefined SAP Content (Best Practice or Model Company) and directly maintain the Requirements in SAP Solution

Manager. The advantage is, that process structure elements are automatically assigned and all documents are automatically stored at the correct place

§ This data is then inherited by each follow-up document, e.g. the Work Packages and Items§ Working with diagrams coming with the SAP Content and prepared by the SAP consultant beforehand the workshop accelerate the discussion§ Alternatively it’s as well possible draw processes on brown paper and gather the Requirements in xls. When this is done you can bring the

Requirements with one upload in SAP Solution Manager. Then the process structures in Solution Documentation need to be maintained, optionally the process diagrams redrawn, and after the Requirement upload, the process structure manually assigned to the Requirements.

Step 3: There is a slim approval workflow for the Requirements§ During the Fit-Gap Workshops the Requirements are in Status ‘Draft’§ When the Gap definition for a scenario or process is ready, the responsible Business Analyst sets the Requirement on status ‘To be Approved’

Step 4: The approval procedure for Requirements for each release is done by an Approval Board§ This is commonly done via the Mass Change Analysis, where the ‘To Be Approved’ Requirements are collected and checked§ Requirements which are not so urgent are put on status ‘Postponed’ and are re-checked at the next Approval Workshop for the next Release§ The activity shall be executed by an Architect (having change authorization for the Mass Change) but under the participation of the program and

project managers


Once all activities/outcomes of the Fit/Gap Workshops are called ‘Gap’ we distinguish in Focused Build a bit more and ‘classify’ Requirements, Work Packages and Work Items in the following way:

Gap: is a completely new development witch needs to be specified in detail with big As-is, To-be evaluation, often with no technical information or idea how to realize it in the beginning. Technical design is fully done by developer in WI with the help of a technical design document

WRICEF: is a typical and from SAP expected extension, where no business background needs to be described. The consultant often already knows how to implement and configure. So the Specification is often already a mixture between functional and technical design

Fit: there is no coding adjustment, but only customizing. So specification is often an existing standard configuration guide and only a customizing documentation is needed to be maintained on Work Item level

Non-functional: Is used for documentation upload or a parameter settings without the need to document a Functional Specification (no document KPI maintained in customizing for Work Package and Work Item).

Requirement Classification What does the Requirement Classification stand for?


Document RequirementsAdding Requirements



Development Library

Executable Library

Processes

Proc

ess

�

�

� � �

�

�

� �

� �

��

Requirements�

Best Practice is to add Requirements to process steps and processes, but they can also be linked to other elements if required.

Requirements can be maintained at the following SolDoc Elements: • Structure Elements

• Process

• Process Step (Reference)

• Library Elements• Configuration Item

• Process Step (Original)

• Executable

• Development

• Interface


Requirements for Process StepsRelationship from Requirements to processes in Solution documentation

Feature details• Indicate in the process if Requirements are available

• 4 different decorator icon shows the different status of Requirements• Preview of Requirement in pop up window

• Direct access to all existing Requirements for the process step to create further Requirements

BenefitsMonitor in the process structure how many Requirements exist and which status Avoid creating redundant Requirements for the same process

Document Requirements Display of Requirements in Process Management


How to start - Methods for Requirement Maintenance or UploadOverview

Requirement Management

Excel uploadè Initial upload of Requirements into Requirements Management. Manual assignment to Process Structure as follow-up activity

Process Management Diagramè Directly maintain Requirement at Business Processes or Business Process Steps

Process Management Column Browserè Directly maintain Requirement at Library or process structure elements

Excel down-/uploadè Initial down- and upload of process structures includingRequirements, e.g. from cloud or Model Company systems


SP05 Requirements Management Process FlowDetailed Workflow

Set by WP

PostponedRestore

Set by WP

Draft Approved

Rejected

In Realization Realized Completed(FINI)

Set by WP

Canceled(FINI)

Postponed

Requirements�

Send for Approval

Reject

Withdraw

Recover

Recover

Postpone

To Be Approved

Set by WP

CreateWP

Revise

CreateWP Set

by WP

CreateWP

Withdraw

Approve

Withdraw

Set by WP

Postpone

= manual status setting

= automated status setting


Key Takeaways Requirements Management

Requirements– Are created on the Design branch and not released to Development branch– Should be related to any process structure in SAP Solution Manager

process management, process or non-process related– Should be specific and granular – Have an 1:m or n:1 relationship to Work Packages– Are ideally consolidated (not x Requirements for the same need)– Need to be approved– Get an automated status update from the Work Package– Maintain categories reflecting your build projects

Demo1. Requirement Creation2. Requirements Tracking3. Introduction to SRD


• SAP Solution Manager together with Focused Build accelerates the SAP S/4HANA implementation and allows you to run the projects with utmost transparency

• Focused Build and Focused Insights are now included in the SAP Solution Manager usage rights

• Focused Build supports agile methodology and SAP Activate

• Process Management• Full fledged modelling tool is available in SAP Solution Manager• SAP Recommends you to start with SAP Best Practice content as a base line• Process Management is well integrated into various other ALM/Project processes

• Requirements Management• Allows you to capture requirements against processes and process steps• Full workflow to manage requirements from creation to realization

Recap

Questions?

PUBLIC

Rajeev GollapudiAPR 2020

Day 2How Focused Build accelerates SAP S/4HANA projects


• SAP Solution Manager together with Focused Build accelerates the SAP S/4HANA implementation and allows you to run the projects with utmost transparency

• Focused Build and Focused Insights are now included in the SAP Solution Manager usage rights

• Focused Build supports agile methodology and SAP Activate

• Process Management• Full fledged modelling tool is available in SAP Solution Manager• SAP Recommends you to start with SAP Best Practice content as a base line• Process Management is well integrated into various other ALM/Project processes

• Requirements Management• Allows you to capture requirements against processes and process steps• Full workflow to manage requirements from creation to realization

• Process Structure à Requirement à Work Package à Work Items

Recap

Demo1. Requirement Creation2. Requirements Tracking3. Introduction to SRD

Build Management


Transparent Requirements-to-DeployRelease Management to synchronize projects and keep them under control

Release 1

Project 3

Scope Build Test Deploy Hypercare Operate

Build & Functional Test Freeze

Project 2

Build & Functional Test

Project 1

Build & Functional Test Go-Live

Go-Live

Go-Live

Synchronized Go Live

Freeze

Freeze

Join

t Int

egra

tion

Test

Pha

se

Reduce Risks, Simplify Go-Live Process, and Decrease Test Efforts


Transparent Requirements-to-Deploy Incremental deployment with constant feedback loops with the business

Prepare Scope Build Deploy Run

Projects

Waves

Sprints

�

�

Single functional &user acceptance test

Unit test

Agile Releases�Final integration& regression testing

�

�

Releases synchronize project go lives andensure continuous delivery and integration.

Project to bundle deliverables. Multiple and parallel projects are possible

Phases ending with Quality GatesShort Discover & Prepare and Explore, incremental Realize & Deploy

Waves ending with Touch and Feel by the business (~ 8 – 12 weeks)

Sprints with Show and Tell sessions to the business (~ 2 weeks)


Waves

Wave details§ A wave comprises a well-defined functional

scope of work packages to define what needs to be done

§ Starts with scope definition and a preparation time– Provides at least the functional

specification required to start the first sprint of the wave

§ Actual build execution is done in Sprints§ Execute functional integration testing§ Ends with the q-gate “Wave exit-criteria

fulfilment” for passing the q-gate§ Optional: Release can be assigned to a

Wave to allow Go-Live after the Wave

Work Package assigned to a Wavereceiving milestones from Wave as default due dates

Legend= Q-Gate

= Milestone


Sprints

Sprint details§ A sprint comprises a well-defined scope

of work items to define how to do it§ Starts with sprint backlog definition and

prioritize the work items§ Provides technical design documents and

software developments for review in show and tell sessions / sprint reviews

§ Unit test to confirm work item is completed

Work Item assigned to a Sprintreceiving milestones from Sprint as default due dates


Project Management and integration aspects in Focused Build

IT Area PMO Area

ResourceManagement

Cost Controlling Accounting

Requirements & ChangeManagement

TestManagement

ProcessManagement

Issue Management

Optional via integration to ERP

Focused Build – R2D Project Integration

RiskManagement

Scope

Collaboration & Documentation

Task Management

Timeline


Project Organization Example Using Master / Build Templates

Steering Committee

Application Area 1 Technical InfrastructureApplication Area 2 Migration Management

Architecture Program and Project Management

Quality Management

Project Sponsor

Organizational Change Management

PMO Office

Master Project (Program)

Build Project 1 Build Project 2 Project 3 - n

Template Type: Build Project Template Type: Master Project


Using project templates as jump start for your project planning

Master ProjectPredefined project structure• Lean Project structure for Focused Build

Foundation with focus on Wave / Sprint Schedule

Feature details• Predefined Waves and Sprints with related

Q-Gates and Milestones• Cross Wave in Master Project can be used for

integration activities (e.g. Testing) across multiple Build projects

BenefitsSimplified project setup with flexibility to manage dedicated work streams

Build Projects


Focused Build Project Management app - Overview

Improved user experienceSetup and administration of Focused Build projects

Feature details• Improved filtering, support of favorites and variants in

Project Landing page• Enhanced Gantt Chart for Focused Build related

project elements• Integration and Mass Change for Project Risks• Navigation to related Work Packages and Work

Items

BenefitsSimplified and efficient project setup and administration

Demo – Project Planning

Build Management


Build Design: Example New ImplementationFit Gap Analysis and Delta Design – Methodology Overview

1. Finalize System Setup� Prepare additional sample data � Enhance system setup with add.

Scope

2. Fit Gap Workshops / Validation of SAP Solution� Show and tell SAP standard key

design elements / Gap Identification

3. Gap Documentation� Document and specify identified Gaps

in initial Backlog5.2 Design/Specify� Specify the work to be done, e.g.

� Create Delta Design Documents� Upload Configuration Documents

� Prepare distribution of work by definition of Work Items

6. Verify & Accept� Verify solution design� Acceptance Procedure

4. Delta Scope Prioritization

� Prioritization according to agreed criteria (e.g. Business Value, Criticality)

Step AFit Gap Analysis / Solution Validation

Step BDelta Design

Approve Requirements to be part of release,with Mass Change app

Verify Priority, Effort and Value with Requirement Management app

Best Practices / Model Companies uploaded to SAP Solution Manager

Process ManagementSolution Readiness Dashboard

Rework Requirements via Requirement Management or My Requirements app

5.1 Create Product Backlog� Prioritization

according to technical criteria (e.g. Development sequence)

Create Work Packages to be part of the first Wavewith Requirement Management app

Repeat this Wave planning activity for each Wave -> agile

Plan all Waves at once -> waterfall

Result: Product Backlog

To sign-off release Functional Specificationin My Work Packages app and set according Work Package Status

5. Delta Design

For real Gaps and WRICEF, create Functional Specificationin My Work Packages app


Create Work PackageGuidelines • Bundling Requirements and Work Packages (WPs) follow the organizational structure of the team, e.g. Purchase to

Pay, Logistics, Controlling, Master Data, … • Each team works on it’s Product Backlog which is the summary of the assigned Work Packages

• Work Packages are linked to a process structure or library element • To automatically inherit the Process Documentation context, create WPs based on Requirements • Exception can be “basis module” customizing: then there is no direct link to a Requirement, but a direct link to the

process structure, e.g. Configuration Item in the Configuration Library

• Work Package Title • Reuse Requirement Title (in case of 1:1), e.g. SO_via_Rigo_fixed_handling_fee• Reuse Requirement Title plus additional specification of needed deliverable (in case of 1:m),

e.g. SO via Rigo fixed handling fee – Logistics interface• In case multiple Requirement are defined and summarized in one WP (in case of n:1),

define a suitable Work Package title

• A Work Package has at least one Functional Specification assigned• A Work Package needs to be testable by an end- or key user (functional test) in one wave

• A Work Package can be subdivided into one or more Work Items in case the work needs to be distributed between several project members


Create Work PackageGuidelines A Work Package needs to be implementable in one wave (~4-12 weeks) –> the smaller the Wave duration, the better the tracking and status based reporting

Example Waterfall approach with fix planned waves - rough Wave planning according to the WP type• Wave 1: Fit (Customizing) -> basis configuration• Wave 2: Gap (Development) -> bigger developments, with integrative aspects• Wave 3: WRICEF -> smaller developments and adjustments• Wave 4: Left overs and Integration Testing

Example Scaled Agile approach with fix planned waves • Wave 1: Plan WPs with the priority according to the ranking in the Product Backlog. Create appropriate Specification• Wave 2: Plan WPs with the priority according to the ranking in the Product Backlog. Extend appropriate Specification

Wave 3: like aboveIn case a Work Package is too big to finalize it in one Wave, slice it in several and smaller parts, e.g.� one WP for developing the basic functionality� one WP to extend the functionality.� one WP for finish the functionality


FIT, RT

Unit Test

Focused Build methodology – BranchesStandard Workflow

hand over to release ProductiveNew

Single Functional Test & AT

In Development

To be tested (Unit)

Test Confirmed

Approved

Created Scoping In Development To Be Tested Successfully

TestedHanded over to Release

Productive/Completed

In Realization Realized

To Be Tested SuccessfullyTested

Req

uire

men

tsW

ork

Pack

age

Wor

k Ite

m

Created

Scope Finalized

Handed over to Release


In Development

Completed

To Be Developed

Development BranchDesign Branch Production Branch

= Automated action

= Manual action

= WI with General Change

= WI with Normal Change

In Repair


Productive


FIT & RT

Handover to releaseNew

Unit Test


In Development

To be tested (Unit)

Test Confirmed

Focused Build methodology – SystemsStandard Workflow

Approved






Req

uire

men

tsW

ork

Pack

age

Wor

k Ite

m

Created

ScopeFinalized

Hand over to Release

In Development

Completed

To Be Developed

DEV

SBX QAS PRE PRD

In Repair

Create Transports

Create Work Item

Create Work Package


Requirements�

�Wave

� Work Package

1:m

FunctionalSpecification

Test Case

Interface LibraryConfiguration Library


Development Library

Executable Library

Processes

Process

� � �

�

�

�

�

Created

Scoping

Rejected

Draft

Approved

Postponed

ResultWork Packages are created and documentation is assigned

• In Focus Build we limit the documentation to the really required documentation

• So there needs to be a document describing what needs to be customized and tested

• The availability of the functional specs can be tracked via the Solution Readiness Dashboard

� �Dashboard


Functionality of dropDocdropDoc integration to Work Package and Work Item Applications

Technical Design

Process Steps

Developments

Executables

Business Processes The decision where the dropped document will be stored is done in the background by dropDoc and based on the standard document type configuration e.g.:§ Functional specification shall be stored at <Step origin>§ Single Functional Test at <Step origin>§ Technical Design at development or executable elements§ Use Case at <Step reference>

DEFINE DOCUMENT


� Work Package

Scope and release from DESIGN to DEVELOPMENT branch


DesignSandbox

ProductionPRD

Innovate

� Work Item

� Work PackageFS

SFT

TSFSSFT

Release of relevant solution documentation elements between Design and Development branch is done automatically by Work Package when handing over to development.

Work Item picks the scoped documentation scope and adjusts or creates additional documentation

Work Package point now to development branch.

Focused Build – TMS integration


New

Unit Test

Single Functional Test & UAT

Test

Focus Build - Transport Handling with ToC and Unit Test in QASDetailed Transport/Status Dependencies

Approved

Created Scoping

In Development To be tested Successfully

testedProductive/Completed

In Realization RealizationCompleted

To be tested Successfullytested

Wor

k Pa

ckag

eW

ork

Item

Created

Scope finalized

Handover to release


In Development

IT,RT

Productive

To be Developed

Transport

DEV PrePRD PRDQAS

TOC*

create Release Import (manual)

Transport

Req

uire

men

t

Handed over to release

* Transport of Copies

Transportbatch import Release Import (manual)

Defect (batch)


DEV QAS PRE PRD

Work Package status flow with integrated TMS actions

Import buffer Import buffer

Create Transport and Tasks

Release Tasks ü

Import in PRE Q

üü

ü

Import in QAS Q

Import buffer

Status:

Created

In Development

To Be Tested

Successfully Tested

Productive

Handed Over to Release

Import in PRD Q

Legend:Regular TransportsTransport of Copies


DEV QAS PRE PRD

Work Item status flow with integrated TMS actions

Import buffer Import buffer

Release Tasks

Import in PRE Q

üü

ü

Import in QAS Q

Import buffer

Created

In Development

To Be Tested Successfully Tested Productive(Status set by Import)

Handed Over to Release(Status set by WP)

Import in PRD Q

Legend:Regular TransportsTransport of Copies

Work Item

Demo1. Work Package Creation2. Work item creation3. Tracking in SRD

Test Management


On Top Functionality of Focused Build for SAP Solution Manager

SAP Solution Manager – Test Suite

Solution Documentation Test System Setup Test Execution and AnalyticsChange Impact Analysis Test Planning

Prepare Explore Realize Deploy Run

• Requirements / Work Package based Test Plan Generation

• Test Steps Designer

• Test Execution: My Test Executions

• Test Suite Dashboard

• Manual Test Cases

• Automated Test Cases

• Test Automation Framework with 3rd party test tool integration

• Test Composition Environment to manage SAP and partner tools

• Test Data Management

• Change Impact Analysis

• Test Plan and Test Package Management

• Test Execution of manual and automated tests

• Gap and Completeness Analytics

• Test Execution Analytics

SAP Solution Manager - Test SuiteCapabilities of SAP Solution Manager Test Suite and Focused Build


Functional Integration Test

Example of Project StructureBuild Projects for Waterfall Approach

Project structure sample with 1 wave and 1 sprint

Acceptance Test

Discover & Prepare Explore Realize Deploy Run

Wave 1

Project

Sprint 1

Handover to Release

Functional Integration Test (final)

& Regression

Test

Functional Specification available

Scope defined

Work Package Build completed

Single Functional Test completed

Work Item Build completed

Unit Test completedTechnical Design available

Wave Milestones

Sprint Milestones


Requirements based Test ApproachAll Test Types

Work Items (Technical Design)

Software Implementation and related Configuration

Unit Tests

QAS PRE

Requirements

Work Packages (Functional Specification)

Single Functional Tests

Regression Tests (optional)

Functional Integration Tests (final)

Regression Tests (final)

Functional Integration Tests (optional)

Acceptance Test

SBX DEV PRD

Definition and Specification Implementation and Configuration Functional Tests Process Tests PRD use


FIT, RT

Unit Test

Focused Build methodologyStandard Workflow



In Development

To be tested (Unit)

Test Confirmed

Approved






Req

uire

men

tsW

ork

Pack

age

Wor

k Ite

m

Created

Scope Finalized



In Development

Completed

To Be Developed In Repair

Business Analyst/Process Expert�

� Solution Architect

� Test Coordinator

� Developer

� Technical Tester (Developer)


FIT, RT

Unit Test

Focused Build methodology – BranchesStandard Workflow



In Development

To be tested (Unit)

Test Confirmed

Approved






Req

uire

men

tsW

ork

Pack

age

Wor

k Ite

m

Created

Scope Finalized



In Development

Completed

To Be Developed

Development BranchDesign Branch Production Branch

= Automated action

= Manual action

= WI with General Change

= WI with Normal Change

In Repair


Productive


FIT & RT


Unit Test


In Development

To be tested (Unit)

Test Confirmed

Focused Build methodology – SystemsStandard Workflow

Approved






Req

uire

men

tsW

ork

Pack

age

Wor

k Ite

m

Created

ScopeFinalized


In Development

Completed

To Be Developed

DEV

SBX QAS PRE PRD

In Repair

Create Transports

Create Work Item

Create Work Package


Variant A1:Without formal documentation, without test plan

Variant A2:With formal documentation, without test plan, possibility to create defect correction during Single Functional Test starting directly from the Work Package

Variant A3:With formal documentation, with test plan(s)

Single Functional Test (SFT) and Acceptance Test (AT)Three Variants supported by Focused Build - Overview

w/ Test Cases�w/o documentation of test results

w/ documentation of test results

You can choose the variant fitting best to your individual test requirements.

not recommended

� Work Package Test Cases�ß Assigned to

Defect Correction

Assigned to

ß

w/ documentation of test results

� Work Package Test Cases�

� Test Plan

Assigned to

ß Assigned to

ß

Defect

ßAss

igned

to

Defect Correction

Assigned to

ß


Variant A3 - Single Functional Test (SFT) and Acceptance Test (AT)Sample Workflow

Solution Documentation Test Execution and AnalyticsTest Planning

• Setup of Solution Documentation

• Setup of Project(s) and Release

• Create Requirements and Work Packages

• Assign Test Cases to Work Packages

Create / Assign Test Cases to Process Steps

Check Assignment of Test Case(s) to Work Package (WP)

Create Test Plan based on WP status

Create / Adjust Test Packages

Assign Tester(s)

Access My Test Executions (MTE)

Execute Test Case(s) (manual / automatic)

Document test results/ set status/ create defects

Defect Correction (Developer provides fix)

Retest and set test case status

Test Suite Dashboard

Test Suite Analytics


Test StepsTest Step Designer

Design time application to create and maintain manual test cases of type Test Steps

Entry points• Standalone – start from SAP

Solution Manager Launchpad• Solution Documentation (Process

Steps and Executables can automatically transferred into your Test Case)

Test Steps• Steps + sub-steps • Descriptions, Executables • Partner • Attachments • Evidence • Result Attributes• File upload using (csv)


Variant A3 - Single Functional Test (SFT) and Acceptance Test (AT)Overview – Activities during Test Execution

Manual Test Execution

Correction / Adjustment

Test sign-offTransport Retest Test Status Reporting

Test Defect

The test cases were executedand Test Status values are set. Ifrequired, a Defect is created for

the related test case.

In case of a defect in the application, a software correction or configuration adjustment is needed. This

changes are transported to the test system, were a retest is required.

The Test Manager monitors the Test Status; at the end of the test phase,

the Project Manager is informed aboutthe status and the Test is finally

signed off.


Sample usage scenarios for Regression TestsScenarios

Scenario 1 – Regression Test before Deploy

• Re-execute selected Test Cases across the Test Types executed before to ensure no side-effects on test results of earlier Test Types occurred

• Scope: All units, functionalities and processes of the entire release • Recommendation: Focus on high priority Test Cases

Scenario 2 – Regression Tests after Waves or Sprints

• Re-execute selected Test Cases across the Test Cases in former Waves and Sprints in order to make sure respective test results are still 'OK' after new developments or bugfixes have been introduced

• Scope: Selected units, functionalities and processes of former Waves and Sprints • Recommendation: Focus on high priority Test Cases


Regression Test Recommendations

§ Regression Test activities such as Creation of Test Plans, Test Execution can be handled very similar to the procedure described for FIT.§ To further facilitate those activities SAP Solution Manager offers:

– Business Process Change Analyzer (BPCA) to define an optimized test scope – Test Automation Framework (TAF) including Component Based Test Automation (CBTA) to reduce manual testing efforts

BPCA TAF


Regression Test SupportBusiness Process Change Analyzer

Identify your test scope and significantly reduce your test effort for regression tests with BPCA!

§ Change impact analysis for business processes resulting from software change events

§ Use cases:

– Impact analysis for customizing and code changes

§ Benefits:

– Precise impact analysis and significant test scope reduction


Regression Test SupportTest Automation Framework

Test Design

§ Seamless integration between SAP Solution Manager and test tools from SAP and Partners

§ Test Data Container (TDC) provide test data for test script parameters

§ Central management of System under Tests

Test Automation Framework

Test Execution§ Start of automated tests

from Workcenter Test

Management

§ Ad-hoc start or scheduler

for unattended execution

§ Integrated test execution

logs from partner tools

Test Result Analysis§ Test Manager can view test

results from manual and

automated tests in one

environment

§ Status and progress

resports

§ Integrated partner reports

Accelerated Repair§ Workflow between Tester

and Test Engineer to trigger

test case repair

§ Rich environment for Test

Engineer to analyze

problems and perform

repair activities

Non-SAP

Demo1. Test Step Designer2. Assignment Analysis and Test Plan Generation3. Test Suite Dashboard

Deploy – Release Management


Whenever something shall be deployed into the productive environment, it will be handled via a Release.

Usually Work Packages are assigned to one of the waves within Project Management. Such a wave is associated with a certain release. All Work Packages assigned to the same release within 1 project, will be deployed together (Go-Live) at the end of the project or wave.

Release Management Concept in Focused Build


The release has many different phases which all have a defined semantic meaning.

The phases of the release also control which activities are possible in the Work Packages and Work Items –related to the release.§ e.g. assignment to a release, import of transports, …

Release Phases - Introduction


Created Prepare Build Test DeploymentPreparation Deploy Hypercare Operation Completed

§ In the Prepare phase, the development of the release content takes place

§ Work Packages will be processed and broken down into Work Items

§ Changes will be implemented (with Workbench and Customizing Transports)

§ In addition, at the end of a sprint the Single Functional Test of Work Packages will be performed within this phase and at the end of a wave the optional (early) Functional Integration and the UA Test will take place as well in the cycle phase. After the test plans are completed according the exit criteria's defined at the beginning, a board consisting of Release Manager(s) and Test Manager(s) will decide on which Work Packages are supposed to go with the next release deployment. The supporting tool(s) for this decision are the Test Suite Dashboard – Traceability Matrix and the Mass Change Operations app.

Prepare Phase (1)


Prepare Phase (2)

Test Plans in combination with Traceability Matrix toverfiy that everything is tested which shall be includedinto the release.

Mass Change Operations app for bulk changingstatus of Work Packages identified for the nextrelease deployment.


• In the build phase, the content of the release will be finally defined.

• This is the time, when the release manager needs to make a decision about which Work Packages shall be part of the release deployment and which shall be taken out (e.g. postponed to next release). For the selection of Work Packages which could be part of the release Mass Change Operation app will be utilized:

• Please refer to the slides of the previous phase regarding the completed Single Functional Test phase for the final scope of the release as well.

Build Phase (1)



• In the build phase, you are now switching the status of all Work Packages which are previously nominated for the next release deployment with the help of the Mass Change Operations app from Tested to Handed over to Release. Please be aware of the fact this will be the Point of NO Return! After setting the status Handed over to Release there is just the way forward into the pre-production and finally into the productive system. NO WAY BACK ANYMORE!

Build Phase (2)



– In the test phase, the testing of the release takes place. The content is finalized.

– This is the final release test, which means the entire package needs to be validated and tested for functional and technical correctness before the import into the Production environment.

– Usually this involves a whole series of tests including▫ Regression Test

▫ Integration Test

– In order to have a valid test result, the Pre-Production system needs to be reset before the test phase.

– In case of bugs or issues, a defect correction can be created to fix the errors.

Test Phase



• In the Deployment preparation phase, the technical steps to perform the cutover into the production system need to be done.

• This includes all required preparation steps – technical as well as non-technical.

• Typically the Deployment preparation is a short phase which is directly followed by the Deployment phase (e.g. as part of a weekend).

Deployment Preparation Phase



• The Deployment phase includes the “big day” – the actual technical cutover of the entire release into the production environment.

• This means all transports will be imported into the production environment.

• The activity to trigger the import will be done by an Administrator or Technical Release Manager from within SAP Solution Manager.

• The content of the package will be calculated automatically by SAP Solution Manager and imported in the correct sequence.

Deployment Phase



• After the Deployment there is a special phase called “Hypercare”.

• This is due to the fact that usually shortly after a go-live, the number of incidents increases significantly.

• Sometimes this is due to missing information about the new functionality, wrong documentation or bugs which have not been detected and solved before.

• During this time, there is still a high attention on the release and a consistent monitoring of the incident queue.

• Usually this phases ends after a few days or weeks – then the release will be formally handed over from the Project Team to the IT Operation Team, which ensure production support.

Hypercare Phase



• Once Hypercare phase is completed you can switch the cycle phase to Operation which means that this release is now productively operated.

Hypercare Phase



Productive


FIT & RT


Unit Test


In Development

To be tested (Unit)

Test Confirmed

Focused Build methodology – Release PhaseStandard Workflow

Approved






Req

uire

men

tsW

ork

Pack

age

Wor

k Ite

m

Created

ScopeFinalized


In Development

Completed

To Be Developed

PreparePlanned Build/Test Deploy

In Repair

Create Transports

Create Work Item

Create Work Package

Other topics


Project Management

Sprint 1..n

Task 1..n

Wave1

Milestone

Q-Gate

Focused Build – Recap

Test Suite

Test Plan Test Package

Solution Readiness Dashboard

Process and Application Landscape

Process Management

�Test Cases

Branches

�Design Documents

�Requirements Work Packages

�Work Items

Requirements / Work Packages / Work Items

�

Release ManagementRelease Number and CycleChange Control Landscape


Recommendations

� Review Roadmap “Transition to SAP S/4HANA” as input channel for your project plan.Decide on usage of project management in SAP Solution Manager

Review relevance of SAP’s business process best practice

- SAP Solution Manager- CAL Trial for S/4HANA and SAP Solution Manager

- https://service.sap.com/public/solutionpackages

Decide on SAP Solution Manager for modelling and documenting your to be S/4HANA business processes.

https://service.sap.com/public/solutionpackages


Understand the Use Cases of Focused Build (2)How do you plan to use SAP Solution Manager in SAP S/4HANA projects?

Y

N

X

Focused Build Add-on in SAP Solution Manager 7.2

Standard Process Management

with Test Suite in SAP Solution Manager 7.2

��

�

7.2

*WRICEFs stands for workflows, reports, interfaces, conversions, enhancements, and forms

Are many WRICEF*s or functional gaps

expected?

Next


Understand the Use Cases of Focused Build (3)Smart project delivery with SAP Solution Manager 7.2

ProcessManagement

RequirementsManagement

Change ControlManagement

Portfolio & ProjectManagement

ReleaseManagement

TestSuite

Size S§ Process Management and Test Suite

– Small innovation projects in time and effort – Pure configuration and less WRICEF– Intuitive user interfaces and dashboards in Test

Suite*

Size L*Full scope Focused Build with Release Management� Full project transparency� 5+ tier landscape� Delivery with out-tasked development

factories� Full project management capabilities to

manage scope changes, risks, and Q-gates * Focused Build licenses required

Size M*Process and Requirements Management with Test Suite in Focused Build� WRICEF intensive projects � No transport management integration� PMO dashboards with live project data

*

Next


Find an Implementation Partner

Several local partners support you in setting up your focused solution, provide knowledge transfer, and assist you in managing the project.A list of Focused Solutions circle members can be found at https://support.sap.com/en/solution-manager/focused-solutions.html

Back to overview

Customers who receive services from Focused Solutions Circle

member get a 20% discount for each new Focused Build or Focused Insights license.

https://support.sap.com/en/solution-manager/focused-solutions.html


Install a Methodolgy & Tool coach (1)

Next

It is strongly recommended to enable a Methodology and Tool coach if you plan to use the Focused Build - Requirements to Deploy- process.

Focused Build coaches are provided from either SAP Service Delivery (PE customers) or from a Focused Solution Circle member.

Typical tasks of a methodology and tool coach are – Support in defining the implementation concept aligned with SAP Solution Manager,

SAP Activate, SAP Model Company, and SAP Value Assurance services– Explain the tasks, benefits, and key deliverables in each phase and the integration with

SAP Activate– Act as a central contact and key user guide and explain the users in their different roles

the Focused Build processes in projects– Being able to support projects in the tool administration and master data maintenance

for the Focused Build processes– Orchestrate required technical tasks to get setup services, technical support, etc. – Being your contact to SAP as part of a Focused Build community with regular exchange

of experiences with other FB experts and SAP Backbone.

https://support.sap.com/en/solution-manager/focused-solutions.html


Train Your Project Members

The following information material helps you to get an understanding of the focused build functionality§ Read the whitepaper to get an overview of tool and methodology.

–Whitepaper Focused Build (32 pages)

§ Train your project members according to their roles in the Focused Build process. The focused build training curriculum is free-of-charge and can be used immediately.–Role-based training curriculum

Back to overview

https://support.sap.com/content/dam/library/SAP%2520Support%2520Portal/support-programs-services/solution-manager/focusedsolutions/focusedbuild/01%2520Focused%2520Build_Whitepaper_v3.pdf

https://service.sap.com/sap/bc/bsp/spn/esa_redirect/index.htm%3Fgotocourse=X&courseid=70324959


Targets:• Overview about the Focused Build process and its

functionalities along the project lifecycle.• How to use the standardized best practice tasks of Focused

Build in an SAP S/4HANA implementation project• Train the project members in their different roles before

starting an implementation project how to use Focused Build• Gain a certificate after completion of the exam in October.

Target roles:• Project members who use Focused Build• Project Managers who decide to use Focused Build as

implementation tool• Agile methodologists and tool consultants

New openSAP courseAgile Project Delivery with Focused Build for SAP Solution Manager(link)

Join this free open online course to learn how Focused Build for SAP Solution Manager can guide project members through the entire lifecycle of an implementation project such as SAP S/4HANA on-premise or private cloud.

• Course starts on 4th of September, but can be started any time later, too• Week 1: Project Preparation and Management

Week 2: Explore Phase (Process Expert/Analyst)Week 3: Realization (Architect/Developer)Week 4: Test ManagementWeek 5: Release ManagementWeek 6: Focused Build EnablementWeek 7: Final Exam

https://open.sap.com/courses/solman2

Questions?

Thank you.


Glossary AT – Acceptance Test

DEV – Development System

FB – Focused Build

FIT – Functional Integration Test

GC – General Change

NC – Normal Change

PRE – Pre Production System

PRD – Production System

SFT – Single Functional Test

SolMan – SAP Solution Manager

TOC – Transport of Copies

TR – Transport Request

QAS – Quality Assurance System

TC – Test Case

UT – Unit Test

WP - Work Package

WI – Work Item

RfC – Request for Change