SAP BPC 10 NW MEGA ELITE Enablement

BPC Project Delivery

Key question

What are the key success factors for BPC implementations?

(1) (2)

Product Expertise A structured Project Delivery using Best Practices

2011 SAP AG. All rights reserved.

Architect Training 2011

Architect Academy 2011 30 BPC Principals created a set of BPC delivery standards based on more than 100 BPC implementations done over the last years Top

3 topics -

Method-based Scoping and Implementation efforts (ASAP 7.1 BPC add-on) Blueprinting Project Quality Assurance

2011 SAP AG. All rights reserved.

Method-based Scoping and Implementation efforts (ASAP 7.1)

Project Phases

Project Preparation

Business Blue Print

Realization

Final Preparation

Go-Live & Support

ASAP Methodolgy for Implementation 7.1 BPC Business Add-on: ASAP Business Add-on SBO EPM Business Planning and Consolidation* ASAP-based Scoping and effort structure:

ASAP Effort Estimation

*BPC Business add-on must be activated before usage

2011 SAP AG. All rights reserved. 4

Method-based role allocation Delivery Plan (ASAP 7.1)

Implementation Phases

Project Preparation
RESOURCES/ACTIVITIES /RESULTS Project Manager (100%) (BPC desireable) BPC Solution Architect (40-60%) BPC Platform Consultant (50-100%) Project Manager (100%) IT Responsible (50-100%) Business Leads (20%)

Business Blue Print

RESOURCES/ACTIVITIES /RESULTS Project Manager (60%) BPC Solution Architect (100%) BPC Platform Consultant (50% x 2-3 weeks) BPC Consultants techn.1x (100%) (BW Integration) BPC Consultants funct. 1-3x (80%) (optional) ECC Integration Consultant Business and IT Representatives, PM, nominated endusers

Realization
RESOURCES/ACTIVITIES /RESULTS Project Manager (60%) BPC Solution Architect (50- 100%) BPC Platform Consultant (50% x 2-3 weeks) BPC Consultants techn.1x (100%) BPC Consultants funct. 3x (100%) ABAP Developer (BPC desirable) Business and IT Representatives, PM, Super user

Final Preparation
RESOURCES/ACTIVITIES /RESULTS Project Manager (60%) BPC Solution Architect (50- 80%) BPC Platform Consultant (50% x 2-3 weeks) BPC Consultants techn.1x (60%) BPC Consultants funct. 2x (100%) ABAP Developer (BPC desirable) Enduser, Business and IT Representatives, PM

Go-Live & Support

RESOURCES/ACTIVITIES /RESULTS Project Manager (60%) BPC Solution Architect (50- 80%) BPC Platform Consultant (50% x 2-3 weeks) BPC Consultants techn.1x (60%) BPC Consultants funct. 1x (100%) Enduser, Business and IT Representatives, PM

Blue marked roles are client side

2011 SAP AG. All rights reserved. 5

Business Blueprint

ASAP Methodology for Implementation 7.1

Project Preparation

Business Blue Print

Realization

Final Preparation

Go-Live & Support

BPC is a very versatile tool and can be used to cover many different business processes. A BPC Business Blueprint document can therefore look quite differently depending on the type of project and on the client as well. Due to the nature of BPC, there is not a single template that will fit all requirements. This presentation will follow the least common denominator approach to identify those points that should be included in any blueprint document.

*BPC Business add-on must be activated before usage

2011 SAP AG. All rights reserved. 6

Business Blueprint scoping

The blueprinting activity is a key activity in any BPC project. It is key not to underestimate the time required for this task (at least 20 to 30 percent of the total time of the project depends on the availability of documented requirements) Here are some of the factors that will impact the blueprinting effort:
Type of project (Planning, Consolidation) Number of processes to be covered Level of details required

2011 SAP AG. All rights reserved.

Business Blueprint process

The blueprint document should reflect what is going to be customized in BPC. Therefore it is key that: written in a way that the Business / IT departments fully understand it
Use appropriate terminology Have an appropriate level of details

Sign-off of the blueprint is essential and no implementation should start before a formal sign-off. Any change requested after the sign-off should go through a change request process. Detail Design Document Important must-be steps: detail design documents will provide additional structure and could be leveraged in documentation and for unit testing (lean implementation model and agile) Prototyping is a key for early user involvement and to prove designs. It reduces change management efforts during Go-Live Preparation (lean implementation model and agile)

2011 SAP AG. All rights reserved. 8

Business Blueprint Content

Table of Content Introduction Management/Executive Summary Project Description of AS-IS Situation Description of TO BE Situation Processes to be covered Data Model Data Sources Security Concept Operational Concept Backup approach System Landscapes and Transports Historical Data Migration Concept

2011 SAP AG. All rights reserved.

Business Blueprint Content - AS-IS / TO-BE processes

The current process and the future process need to be described from
A user point of view
Describe how user interact with the system (data input, execution of calculations, set status, )

A System point of view

Maintenance of system (master data) Data flows Calculations

Benefit: the comparison of the AS-IS and TO BE processes from a user point of view can then be a good starting point for Change Management activities Relevant information in process description: High level and detailed description of process Business Requirements User Roles Security requirements Setup and Customizing in BPC (BPF, Input Schedules/reports, Calculations, Data Model) Custom development requirements Improvements compared to current process
2011 SAP AG. All rights reserved. 10

Business Blueprint Content - Data Model and Data Sources

The Data Model should at least have the following information
List of all applications List of dimensions per application (and dimension type) High level content for each dimension List of properties for each dimension Description of internal data flows between applications (end-to-end testing)

The Data Sources need to be specified for the following type of data:
Master Data Transaction Data

For each type data, the source system should be identified and a data import concepts need to be defined, this would include:
Central / De-central data load Automatic / Manual trigger Full vs. Incremental load Technology used for data load (out-of-the box, development in ABAP, ...) Integration of BPC loads into the general process chain framework (early involvement of the client side BW teams)
2011 SAP AG. All rights reserved. 11

Business Blueprint Content - Operational Concept (Application Management) and Backup (Archiving) Approach
The operational concept should include
System Maintenance
Maintenance of master data (frequency, responsibility) Initialization of system for a new period Roll-out of application updates/fixes

User Maintenance
Responsibility for maintenance

Concept for service packs / updates

Testing Roll-out of local client (if applicable)

The backup approach needs to be addressed from a global point of view, if BPC is not run on a dedicated NW server. In that case, the backup strategy will have to be aligned to the strategy of the NW environment. If the NW instance is dedicated to BPC, then a strategy can be defined specifically for BPC and it should include:
Frequency, Type of backup. Restore possibilities and time estimation

2011 SAP AG. All rights reserved.

12

Business Blueprint - System Landscape and Transports

This point should define the number of system that will be used (usually Development, Quality and Production). Sandbox system is strongly recommended for Support Pack regression tests, prototyping etc It should be clearly specified where each type of object will be maintained (for example reports) to specify what needs to be transported. For master data, the maintenance should also be detailed, especially for those dimension where the maintenance will be done manually. It is also a good idea to come up with an emergency fix concept, for urgent fixes that need to be applied to a production system and that might not go through the full release process.

2011 SAP AG. All rights reserved.

13

Business Blueprint - Historical Data Migration

The migration of Historical Data should include at least the following information:
Source system (or systems) Number of periods required Approach (for calculations, mapping of dimension members, ) Migration efforts should not be underestimated and could have an impact on the interfaces (might additional temporary interfaces required)

2011 SAP AG. All rights reserved.

14

Method-based Quality Assurance (QA)

Method-based Quality Assurance Project Preparation Business Blue Print Realization Final Preparation Go-Live & Support

The preferred approach is to integrate the Quality Assurance activities in the project plan. These activities should be carried out throughout the project lifecycle and cover all aspects of the project. There will be 3 different types of reviews:
Functional Technical Project Management

Each review should be carried out by experienced resources in the relevant topics, it is also key that the resources engaged in the reviews are not part of the delivery team. The Quality Assurance team will be responsible for delivering reports at the different phases of the project

2011 SAP AG. All rights reserved.

15

QA - BPC Reviews method-based

Stage Gate 1 Milestone 1 Stage Gate 2 Stage Gate 3 Milestone n

Implementation

Project Preparation

Business Blue Print

Technical: Architecture and Installation Sizing Review

Realization
Technical: Review of the BPC Transport process, -Performance Analysis Milestone review Technical * Functional: Milestone review Application * Stage Gate review (Build review)

Final Preparation
Technical: QA of open technical Issues, Performance Test Design Review

Go-Live & Support

Technical: Review the maintenance hand ongoing optimization measures put in place for the Go Live, Review of the operational processes and technical handover to operations

Functional: Project Plan review Stage Gate review Design advisory PM: Project Plan review

Functional: Stage Gate review

2011 SAP AG. All rights reserved.

16

QA - Roles and days

BPC QA Roles Role description QA Slot Technical QA Functional QA PM QA Functional QA Functional QA Functional QA Technical QA Technical QA Functional QA Functional QA Architecture, Installation, Sizing Review Design advisory Project Plan review Project Plan review Stage Gate review Milestone review Application * Review of the BPC Transport process, Performance Analysis Milestone review Technical * Stage Gate review (Build review) Stage Gate review

Phase BBP BBP BBP BBP BBP Realization Realization Realization Realization Final Preparation (Test Phase) Final Preparation (Test Phase)

days 5 days 1 day/ week 2 days 2 days 3 days 2-3 days / critical milestone ~ 10 days 1-2 days (optional) 5 days 3-5 days

Technical QA

QA of open technical Issues, Performance Test Design Review

~ 5- 10 days

Technical QA

Go-Live & Support Review of the maintenance and ongoing optimization measures put in place for the Go Live, Review of the operational processes and technical handover to operations

~ 5-10 days

2011 SAP AG. All rights reserved.

17

QA - Step-by-Step
1) Agree on Quality Assurance scope

Project management, executive sponsor and client representative

2) Secure Quality Assurance team

Quality Assurance stream lead

3) Define Quality Assurance plan

Project management, Solution Architect and Quality Assurance stream lead

4) Provide budget

Project management
5) Present Quality Assurance team to client

Project management, Design Authority and Quality Assurance team

2011 SAP AG. All rights reserved.

18

QA - Review approach and examples

Reviews as part of the Quality Assurance stream are following the same approach.
1)

Assessment of status quo and pain points with relevant client representative and project team members (different views) Execute review and document results Present outcome to the client representative and project team member Formalize report and present results to the stakeholders

2) 3) 4)

The must-be reviews are on the following topics:

Business Blueprint review (Assessment of build quality - Functional review)

Implementation review

Performance review (reports / input schedules, calculations)

2011 SAP AG. All rights reserved.

19

QA - Blueprint and Implementation Reviews

Blueprint- and Implementation Reviews are considered as usually a 5 day initiative To secure on the project stages Business Blueprints and Realization that
1.

Implementation of business requirements are following best practices as much as possible (like business rules instead of script logic, Process Flows instead of one huge workbook) but also giving some advisory regarding project approach to proof the implemented solution if potential risks are considered during the build (like maintenance efforts for the model, performance etc.) Milestonebased

2.

Mandatory outcome for any review: Provide an action plan (with type of resources and planned activities)

2011 SAP AG. All rights reserved.

20

QA - Performance Reviews Methodology

Preparation:
1)

Client example

Get an understanding about the implemented solution to anticipate potential performance impacts.

2)

Get the most critical report (if reporting has performance issues) to check VBA usage, usage of formatting, member selections, no. of formulas (BPC 7.x/EPM 10), no. of sheets in a workbook.

4)

Request system access for BPC client, BW backend server with the

authorization to UJSTAT, MDXTEST Execution:

1)

Get in touch with client stakeholders / implementation team and make short interviews to understand the individual experiences about the performance Check provided information regarding client settings, server settings, BWA etc.
21

2)

2011 SAP AG. All rights reserved.

QA - Performance Reviews Methodology (contd)

Reporting runtime issues 1.) If several sheets are used isolate them and run them one by one and the workbook 2.) Run stress tests and benchmark with iterative approach and document result using Tcodes UJSTAT, MDXTEST etc. 3.) Benchmark Networktime using Fiddler etc. 4.) Activate / Deactivate VBA, formatting etc to identify the bottlenecks 5.) Either eliminate bottlenecks directly or make a list of action items

2011 SAP AG. All rights reserved.

22

QA - Performance Reviews Methodology (contd)

Write-back runtime issues 1.) Check writeback time in UJSTAT 2.) Analyze the default logic and, if used, the called BAdI 3.) Test script logic using UJK_Script_LOGIC_TESTER 4.) Improve script logic and/or ABAP or request a scripting resource to do it 5.) Analyze write-back calculations and evaluate potential batch jobs (realtime vs near-time availability of calculated no.)

2011 SAP AG. All rights reserved.

23

QA - Performance Reviews Methodology (contd)

Logon issues 1.) Check on different client desktops (document different client settings) 2.) Check on BPC clients installed on the .NET Server (usually different client settings as no standard client images) 3.) Check logon process (download dimension files etc) 4.) Check SDN, Customer Message System to identify potential bugs/side effects from SPs as usually client logon issues are reported soon from clients Open customer message as soon it looks into a direction of SW related issues

2011 SAP AG. All rights reserved.

24

QA - Performance Reviews Findings

Possible reasons for performance issues : Lack of data in the development system (reports were build on completely empty applications), so the performance of the reports could not be assessed upfront (some dummy data should be generated in the development system)

Lack of stress testing activities in project plan in system with large number of concurrent users

Design errors. An application, calculation or report were designed in a way that they could not be performant

Performance is a very important component in a project and it should be addressed right from the beginning of the project. Pushing the performance topic to the end of a project will most of the time end up causing delays in the project.

2011 SAP AG. All rights reserved.

25

Key Findings

Key success factors for BPC implementations:

Product Expertise A structured Project Delivery using Best Practices

Method-based Scoping and Implementation efforts (ASAP 7.1 BPC add-on) Blueprinting Project Quality Assurance

2011 SAP AG. All rights reserved.

26