accelerate business value realization from your s/4hana ... · think one lubrizol – design what...

Accelerate business value realization from your S/4HANA investment using Agile Approach

October 18th, 2018

© 2018 IBM and SAP Confidential

Key ObjectivesAccelerate business value realization from your S/4HANA investment using Agile Approach- A Case Study of SAP S/4HANA 1709 Business Transformation at a Global Chemicals companyA. Learn how you can accelerate the SAP S/4 Implementation timelines by adopting Agile Framework and help chart out

your Business Transformation Journey by understanding the key pre-requisites of Agile Business Transformation.B. Understand the importance of clearly defining "Minimum Viable Product" and the key Agile Roles (Scrum Master &

Product Owner) to focus on the Key Business Benefits tied to the business case of the program.C. Walk-through a "Day in the life" of a Design Sprint and understand how you can increase the Business Adoption of

S/4HANA Solution by leveraging a reference S/4HANA solution as a starting point and driving a strong Business participation throughout the S/4HANA Program.

D. Outline your SAP S/4HANA Roadmap to help implement the Digital Core and then layer on the new Digital Transformation Technologies by walking through the Lessons learned from Agile S/4HANA 1709 Implementation Journey at a Leading Global Chemicals company.

2


AgendaA. Key Pre-requisites for Agile SAP S/4HANA TransformationB. Key Agile Terms C. Day in the Life of A SprintD. Lessons Learned from an SAP S/4HANA 1709 Implementation at a Chemicals Company

3

© 2018 IBM and SAP Confidential 4

IBM Impact & SAP Model Company Partnership

https://news.sap.com/2018/01/ibm-and-sap-combine-efforts-to-accelerate-sap-s-4hana-implementations/ https://www.youtube.com/watch?v=DGJPz2wpgXQ&feature=youtu.be

https://news.sap.com/2018/01/ibm-and-sap-combine-efforts-to-accelerate-sap-s-4hana-implementations/

https://www.youtube.com/watch?v=DGJPz2wpgXQ&feature=youtu.be


The NEW SAP® Model Company | Faster, Proven, Better

Faster time-to-value through a jump-start for implementations, and fast, simple and flexible deployment of SAP innovations

Lower riskthrough state-of-the-art architecture and best practices, proven end-to-end solutions and guidance

Better resultsthrough focus on innovation and adoption instead of standard best practices and foundation


“Which Benefits did you observe, using SAP® Model Company?”

• “Over 30% reduction in spending on custom developments and maintenance”

• “Reduction in discovery by >70%”

• “Reduction in overall project development phase by 50%“

• “Highly decreased project expenses due to fewer and more-effective meetings enabled through demos and effective workshops”

• “Significantly lowered project risks, since SAP Model Company services employ proven, compatible business process configurations, and allow companies to demonstrate actual system usage”


IBM Impact Industry Solutions


IBM Impact Industry Solutions Details

Why Agile for SAP Projects?

Challenges Today Addressed by New Tools• Late delivery of key deliverables during DBT cycles• Late nights hours / weekends at end of DBT cycle to catch up• Late discovery new requirements• Insufficient focus on value generation(e.g. for R__EFW objects)• Putting releases at risk by including too many 'improvements' that

can be delivered independently of a release• Inefficiency (waste, program run rate is too high)• Missed live environment components found after go-live

(organization/process/system integration)• Trying to build functionality into SAP that SAP is not best suited for• Resource contention between subsequent releases• Scope control due to a lack of focus on value priority• Too much Central; too little decentralization• Process asset duplication, inconsistency, re-work• Out of date documentation• Documentation to transfer knowledge

• More releases per year• Dedicated release teams that alternate between releases• Continuous Improvement Program with monthly releases• Deliver, review ‘Products’ every 3 weeks• SAP Products are (chunks of) the End-to-End business scenario.• Energizing team collaboration by autonomous E2E Scrum teams• Teams are ~7-10 multidisciplinary staff who can autonomously

deliver their ‘Products’• Fewer PMO processes, simplified status/progress tracking• Less and only fit-for-purpose documentation• Fewer hand offs – team collaborates and shares understanding• Product Owners help teams by value focus and prioritization• Deploy/Training representative part of autonomous team

• TFS• SPS

Explorer• Jira

Note: it will only work if you make it work!9


Key Themes and Guiding Principles for S/4HANA Transformation

Simplification, Standardization & Automation

Culture Shift

Leadership & Organizational Focus

Process Orientation & Governance

Accountability

First, Do No Harm – Ensure business continuity with minimal disruption while we fundamentally transform the business

Think One Lubrizol – Design what is best for LZ overall and commit to following that process

Skate to Where the Puck is Going – Design processes that set Lubrizol up for the next 20 years

One and Done - Strive for simplification, eliminating non-value added steps to improve the efficiency and effectiveness of internal processes

Challenge Exceptions – Limit customization to areas that are clear differentiators and valued by our customers

Follow the Money – Concentrate on areas where we spend too much

Focus – Prioritize initiatives and allocate resources to achieve a successful transformation

Stop the Buck – Define clear accountability for decision making and performance

Measure Results – Assign a measurable benefit and an accountable owner for every improvement initiative

Themes Guiding Principles

• Enterprise Focus - Design processes that will support their growth for the next 20 years

• Simplification – Simplify, standardize and automate by limiting customization to areas that are clear market differentiators and valued by customers

• Accountability - Define clear roles (accountabilities), responsible for decision making and performance, and assign measurable benefits for every improvement initiative

Incremental versus Iterative


Roles

Product Owner

Scrum Master

Team Member

Meetings

Backlog Grooming

Sprint Planning

Daily Stand-up

Sprint Review

Sprint Retrospective

Outputs

Product Backlog

Sprint Backlog

PotentiallyShippableRelease

Key Agile/Scrum Concepts

• Teams assigned Scenarios (E2Es)• 10 people max per team total• Each team will have a designated meeting

area

1 Product Owner per Scrum Team

1 Scrum Master per Team

10 people maxper Scrum Team

Scrum Team and RolesBadge-less, Hierarchy-less, Geography-less

13

• One Product Owner per Scrum Team

• Responsible for Business Value and ROI

• Identification (Who, What, Why, Acceptance Criteria) of features and Product Backlog Items

• Prioritization of features/Product Backlog Items in tandem with Scrum Master

• Review and acceptance of features/Product Backlog Items and help preparing Sprint Review

• PO should be dedicated and work closely with the team and the user

• PO represents the users in all aspects. PO has to be able to take decisions on behalf of user (consuming the value/output)

• PO will typically spend 50% of the time with the sprint team and 50% with the Users

• PO and user should not have more than 1 degree of separation

• There is no hierarchical relationship between the PO and the team members

• Participates in Meta-Scrum

Product Owner

SAP Scrum Master

• Responsible for the success of the overall Scrum process, the Scrum Master does this by ensuring that the Scrum Team adheres to the Scrum theory, practices, and rules

• Ensures that the team is fully functional and productive by protecting the team from outside disturbances• Scrum Master Service to Product Owner:

• Facilitating Scrum ceremonies• Work with Product Owner to update the Product Backlog to maximize value• Understanding and Practicing Agility

• Scrum Master Service to Team Members:• Coaching the team in self-organization and cross-functionality• Scrum Master Tracks and removes impediments. Scrum Master escalates the impediments to the Leadership

team, if they are not resolved within the team.• Scrum Master Service to the Organization:

• Working with other Scrum Masters of other teams to increase the effectiveness of Scrum in the Organization• Participates in Scrum of Scrums• Scrum Masters are NOT PMs

• Self Organizing, Cross-Functional, with all the skills as a team necessary to create a product increment

• Responsible for Organizing Tasks & Committing to Work• Commits to the delivery of the top prioritized features/Product Backlog Items as defined by the

Product Owner for a Sprint• Estimates how much they can deliver• Individual Team Members may have specialized skills and areas of focus, but accountability belongs

to the Team as a Whole• Presents Work Results to the Product Owner and any other interested parties• Team members are badge less• Team members are T-shaped (pick up multiple deliverables, not just their ‘specialty’)• Team members should understand the business outcomes

SAP Team Members

Must

Should

Could

Would

IBM Ascend Powered by SAP Activate

‘Quad A’Classification

Preassembly

Final Preparation

Training Delivery

OrganizationReadiness

SIT / UATTests

Training Development

1615141312111009080706050403020100

Priority

Backlog & Release Plan Explore

Sprints 1 - 3

Inte

grat

ion

Sprints 4 - 5

Inte

grat

ion

Delta Design

Solution Validation

Selective Conversions/Interfaces

Sprints 6- 7

Inte

grat

ion

Sprints 8 - 10

Inte

grat

ion

Delta Design

WorkflowReportsInterfacesConversionsEnhancementsForms

Should

Could

Would

Must

1615141312111009080706050403020100

Priority

Backlog & Release Plan Explore

ExplorePrepare DeployRealize-TestRealize-Build


Sprint iterations are used to identify the backlog of work

Client High-Level

Scope & Req’ts

In-Scope EPICs

(End to EndProcesses)

Map Client Req’ts to

User Story LibraryIn-Scope

User Stories

Refined with Client

Assign Story Points

(Complexity Estimate) to User Stories

Sizing / Estimating

Sprint 0

Build Product Backlog – see example below

Over time, the IBM User Story Library will be updated w/ Baseline Story Points

Design / Config. Sprints Core Build / Integration Sprints

Sprint 1Epic 1 O2C

APStories

1, 5

Sprint 2 Sprint n

Prioritize Backlog

Int.Sprint

Create User Stories for GAPs to Add to Product

Backlog

Sprint 1 Sprint 2 Sprint n Int.Sprint

INVStories 2,3,4

Epic 2 EAM

GLStories 8, 10,

AMStories

25

Epic 1 O2C

APStories

6,7

INVStories 9,11,14

Epic 2

GLStories 12,13

AMStories

30

Epic 1 O2C

APStories 28,29

INVStories 20,21

Epic 2 EAM

GLStories

17

AMStories 34,35

APStories 15, 27

INVStories

16Epic 2 EAM

GLStories

17

AMStories

31

APStories 15, 27

INVStories 18, 19

Epic 2 EAM

GLStories 20,21

AMStories 32,33

APStories 38,39

INVStories 22,23

Epic 2 EAM

GLStories

17

AMStories 36,37

Epic 1 O2C

Epic 1 O2C

Epic 1 O2C

E2E Test

Assign User

Stories to Sprints

SIT

VPT

UAT

Groom (Maintain) Product Backlog

Prepare Explore Realize

18


Sprint Cycle Overview

19

1. Reference Value• Provide process, value

and strategic context• Set boundaries• Tie to Business Case,

Value Drivers

2. Validation of SAP Solution using Quad A Framework (overleaf)• Show and tell SAP

standard key design elements

3. Delta Scope Prioritization

Workshop ASolution Validation

Workshop BDelta Design

6. Release & Sprint Planning

4. Delta Design• Update Business Models and

Process Design• Solution Design and

Visualization / UX

5. Verify & Accept• Verify process & solution

design• Design Acceptance

Sprint Cycle Timeline


Sprint Cycle Timeline Overview

1. Execute WorkshopsDemo Model Company/IMPACT solutions, Assess Quad-A

3. GAP - AssessDisposition GAPs, Add user stories to backlog

2. ConfigurationCreate Config Rationale Doc, Configure, Test

6. DemoFinal demo of key user stories

5. WRICEF (for Build Sprints Starting in Sprint 2)Create Func/Tech spec, Build. Test

Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10 Day 11 Day 12 Day 13 Day 14 Day 15

Timelines are illustrative

7. Closing CeremoniesSprint Retrospective, Backlog Grooming, Sprint Planning

Daily/Other Recurring : Daily Stand-Up, Scrum-of-Scrums, Integration Meeting

4. Additional DeliverablesUpdated Workflow Diagrams(AWD), Business Process Procedures, Security Roles, Controls, etc.


Workshop Execution & Documentation: Process Overview

Explore, Confirm and Identify GAPs leveraging the preexisting business processes, S/4HANA solution and other tools. Documentation becomes a by-product of the process

Process Documentation

Organizational Change Impact Assessment

Workshop and design documentation of Key

outcomes, Action Items, GAPs, Issues….

Pre-assembled Solution

Documentation of Standard Process Steps, Roles and Transactions

Walkthrough of End-to-End Transactions

Model Company/Impact Test Scripts

Custom Dev Func/Tech Spec

Documentation of functional requirements to address GAP and

support end to end processes

Process Flow Diagram

Visualization of process flow

BPP Doc

Documentation of Process related Org Change Impacts

Process & SystemReplay

input to education development

21


Sprint Deliverable Execution: Configuration Process Overview

22

Configuration Rationale Document

(posted in Focused Build)

Optional – for Enterprise Structure / Complex items

needing prototypingConfig in Sandbox

IBM/SAP

Config in Development Functional Unit TestIn Dev

SAP Test Suite

Business Process Procedure (BPP)

Document created and posted in Focused Build


Sprint Deliverable Execution: GAP Lifecycle

23

Solution Review

Integration Team and key PMO members review GAPS for Solution viability and alternatives.

GAP Dispositioned

GAP dispositioned and documented in Focused Build. Approved GAPS converted into WRICEF type.

GAP Identified

GAP surfaces in workshop or post-workshop activities

Governance Approval

Escalation approval based on governance levels, development time, and business justification $ amount

Document GAP

GAP recorded in Focused Build. WRICEF Type, Preliminary Solution, and Business Justification, $ amount documented.


Sprint Deliverable Execution: WRICEF Process Overview

24

Combined Functional/Technical Spec

(posted in Focused Build)Worked in parallel with Dev. Build

Functional Unit TestSAP Test Suite

Approved GAP

Always Finalize in Development Env

Iterative Agile Development

Process

Use Sandbox As Necessary

Business Process Procedure (BPP)

Document created and posted in Focused Build


End of Sprint Lifecycle: Review Definition of Done 1/2

25

Phase Work Item Definition of Done Deliverable

Both Prepare, Execute, and Document Workshop

Workshop deliveredWorkshop Documentation Template (WSD) posted in Focused Build

WSD (Focused Build)

Both Business/Security Roles Business Role definedSecurity Roles required validated by security team

TBD

Explore Complete FIT to Standard Analysis

Explore Change Impact Assessment Change Impacts identified and documented in WSDChange Impacts reviewed with OCM team

WSD (Focused Build)

Explore Define, Submit, and Disposition GAP

Gaps dispositioned (deferred, rejected or approved) GAP (Focused Build)

Both Key Data Element Key Data Element Updated to reflect process impactsKDE Posted in Solman

KDE (Sharepoint)

Both Configuration Configuration Rational Document (CRD)Created, posted in SolmanConfiguration PerformedConfiguration Functional Unit Tested, (ALM)

CRD (Focused Build)FUT (Focused Build / SAP Test Suite)

Explore Localization Impact Identified Localization Impacts Identified. Legal Regulatory Status Confirmed. Gaps created and dispositioned if required, or Config created if required.

GAP (Focused Build)CRD/FUT (Focused Build/SAP Test Suite)


Phase Work Item Definition of Done Deliverable

Explore Activity Workflow Diagram (AWD) (Process Flow)

AWD Completed and posted in Focused Build AWD (Focused Build)

Both Governance Risk Controls (GRC) / Process Controls

Internal controls has identified if process requires any Key ControlsProcesses able to be monitored through GRC are identified

TBD

Both Business Process Procedure (BPP) BPP Updated and posted in Focused BuildBPP turned over and initial review done by training team

BPP

Build WRICEF (Workflow/ Reports/ Interfaces/ Conversions/ Enhancements / Forms)

Functional Technical Spec (FTS) (Merged functional/technical spec) completed and posted in SolmanBuild completedFUT test complete and results posted (ALM/Worksoft)Product Owner signoff of FUT resultsConversion team consulted for CDD updates

FTS (Focused Build)FUT results (Focused Build/SAP Test Suite)

Both Cutover Impacts Business Cutover Impacts Identified and DocumentedTechnical Cutover Impacts Identified and DocumentedCutover Strategy Document created/updated

Cutover Strategy - Sharepoint

Both Interim Impacts Assessed and Gaps created Interim state assessed (some waves lives, some not on S/4), and gaps created and dispositioned

GAP (Focused Build)

Both Reporting Impacts Assessed against strategy Reporting gaps created and dispositioned against standard and project reporting strategy

GAP (Focused Build)

Explore Opportunities for Robotic Process Automation Assessed

Opportunities documented as WRICEF GAPS of type “A” for Automation. Objective of 10 overall, focusing on external interactions, highly repetitive processes.

GAP (Focused Build)

End of Sprint Lifecycle: Review Definition of Done 2/2


End of Sprint Lifecycle: Execute and Document Demo• Schedule Demo sessions for 13th/14th day of the sprint (Wednesday/Thursday)• Demos should show those items that were adjusted/built during the sprint cycle• Several user stories can be combined into one Demo session depending on audience, scheduling requirements,

etc.• Simpler user stories that did not require adjustment may not even need to be demoed – initially in earlier sprints

may default to showing more rather than less.• Use the User Story / Demo Sign Off Template to document the results of the Demo session and record GPO sign-

off. You can record which user stories were covered in the demo, which got full agreement, and what key stakeholders were in attendance, as well as key action items and issues coming out of the demo session.

• After the Demo, record the template in Focused Build by linking it to all appropriate user stories, as well as recording any open issues in Sharepoint.

27


Lessons Learned1. Having a Reference System ready is critical for the success of the Agile S/4HANA

Transformation2. Do NOT Agile the Methodology. Define the Methodology, Train the Project Team and

then Execute As per the Methodology. Conduct a Sprint 0 to make sure the Project Team has understood the Key Concepts

3. Agile Methodology does NOT reduce the rigor or discipline needed in Large Business Transformation Projects Define the definition of “DONE” early in the project life-cycle.

4. Establishing Agile Methodology might need MORE people, especially from Business.5. Integrate Security, Training, Testing, Data as part of the Sprint Planning and

Execution. Do not wait for the Sprint to be over to fill in the Gaps.

28


Contact Information

29

Shivesh Sharma, Partner (Chemicals & Petroleum), IBMEmail: [email protected]

Frank Ruland, Global Vice President Partner Management Energy & Natural Resources Industries, SAP Email: [email protected]

mailto:[email protected]

mailto:[email protected]

accelerate business value realization from your s/4hana ... · think one lubrizol – design what...

Documents