Bpc 10 Nw Mega Elite Project Delivery

SAP BPC 10 NW MEGA ELITE Enablement

BPC Project Delivery

© 2011 SAP AG. All rights reserved. 2

What are the key success factors for BPC implementations?

(1) Product Expertise

Key question

(2) A structured Project Delivery using Best Practices


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


Method-based Scoping and Implementation efforts (ASAP 7.1)

Project Phases

ProjectPreparation

BusinessBlue Print Realization Final

PreparationGo-Live &Support

ASAP Business Add-on SBO EPM – Business Planning and Consolidation*

ASAP Methodolgy for Implementation 7.1 – BPC Business Add-on:

*BPC Business add-on must be activated before usage

ASAP-based Scoping and effort structure:

ASAP Effort Estimation


Method-based role allocation – Delivery Plan (ASAP 7.1)

Implementation Phases

ProjectPreparation



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%)


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 IntegrationConsultantBusiness and IT Representatives, PM, nominated endusers



BPC Solution Architect (50- 100%)


BPC Consultants techn.1x (100%)

BPC Consultants funct. 3x (100%)ABAP Developer(BPC desirable)

Business and IT Representatives, PM, Super user






BPC Consultants funct. 2x(100%)ABAP Developer(BPC desirable)

Enduser, Business and IT Representatives, PM






BPC Consultants funct. 1x(100%)

Enduser, Business and IT Representatives, PM

Blue marked roles are client side


Business Blueprint

ASAP Methodology for Implementation 7.1

ProjectPreparation



*BPC Business add-on must be activated before usage

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.


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 coveredLevel of details required


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.

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)

Detail Design Document


Business Blueprint Content

Table of ContentIntroductionManagement/Executive SummaryProjectDescription of AS-IS SituationDescription of TO BE SituationProcesses to be coveredData ModelData SourcesSecurity ConceptOperational ConceptBackup approachSystem Landscapes and TransportsHistorical Data Migration Concept


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

The current process and the future process need to be described fromA 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 processBusiness RequirementsUser RolesSecurity requirementsSetup and Customizing in BPC (BPF, Input Schedules/reports, Calculations, Data Model)Custom development requirementsImprovements compared to current process


Business Blueprint Content - Data Model and Data SourcesThe Data Model should at least have the following information

List of all applicationsList of dimensions per application (and dimension type)High level content for each dimensionList of properties for each dimensionDescription of internal data flows between applications (end-to-end testing)

The Data Sources need to be specified for the following type of data:Master DataTransaction 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 loadAutomatic / Manual triggerFull vs. Incremental loadTechnology 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)


Business Blueprint Content - Operational Concept (Application Management) and Backup (Archiving) ApproachThe 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 maintenanceConcept 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


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.


Business Blueprint - Historical Data Migration

The migration of Historical Data should include at least the following information:Source system (or systems)Number of periods requiredApproach (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)


Method-based Quality Assurance (QA)

ProjectPreparation



Method-based Quality Assurance

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:

FunctionalTechnicalProject 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


QA - BPC Reviews – method-based

Implementation

ProjectPreparation



PM:•Project Plan review

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

Technical:•Review of the BPC •Transport•process, -Performance• Analysis•Milestone review •Technical *

Functional:•Milestone review• Application *•Stage Gate review •(Build review)

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

Functional:•Stage Gate review

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

Technical:•Architecture and Installation Sizing Review

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


QA - Roles and days

BPC QA RolesRole description QA Slot Phase days

Technical QA Architecture, Installation, Sizing Review BBP 5 days

Functional QA Design advisory BBP 1 day/ week

PM QA Project Plan review BBP 2 days

Functional QA Project Plan review BBP 2 days

Functional QA Stage Gate review BBP 3 days

Functional QA Milestone review Application * Realization 2-3 days / critical milestone

Technical QA Review of the BPC Transport process, -Performance Analysis

Realization ~ 10 days

Technical QA Milestone review Technical * Realization 1-2 days (optional)

Functional QA Stage Gate review (Build review) Realization 5 days

Functional QA Stage Gate review Final Preparation (Test Phase)

3-5 days

Technical QA QA of open technical Issues, Performance Test Design Review

Final Preparation (Test Phase)

~ 5- 10 days

Technical QA 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

Go-Live & Support ~ 5-10 days


QA - Step-by-Step

1) Agree on Quality Assurance scopeProject management, executive sponsor and client representative

2) Secure Quality Assurance teamQuality Assurance stream lead

3) Define Quality Assurance planProject management, Solution Architect and Quality Assurance stream lead

4) Provide budgetProject management

5) Present Quality Assurance team to clientProject management, Design Authority and Quality Assurance team


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)

2) Execute review and document results

3) Present outcome to the client representative and project team member

4) Formalize report and present results to the stakeholders

The „must-be“ reviews are on the following topics:

• Business Blueprint review

•Implementation review (Assessment of build quality - Functional review)

• Performance review (reports / input schedules, calculations)

•


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

2. to proof the implemented solution if potential risks are considered during the build (like maintenance efforts for the model, performance etc.) – Milestone-based

Mandatory outcome for any review:

Provide an action plan (with type of resources and planned activities)


QA - Performance Reviews Methodology

Preparation:

1) 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, MDXTESTExecution:

1) Get in touch with client stakeholders / implementation team and make short interviews to understand the individual experiences about the performance

2) Check provided information regarding client settings, server settings, BWA etc.

Client example


QA - Performance Reviews Methodology (cont‘d)

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



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 (real-

time vs near-time availability of calculated no.)



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


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.


Key success factors for BPC implementations:

Product Expertise

A structured Project Delivery using Best PracticesMethod-based Scoping and Implementation efforts (ASAP 7.1 BPC add-on)

Blueprinting

Project Quality Assurance

Key Findings

Bpc 10 Nw Mega Elite Project Delivery

Documents

Transcript of Bpc 10 Nw Mega Elite Project Delivery