25
SAP BI Process Review - ABB 26 th August 2013

ABB Review Report Final 1.0

Embed Size (px)

DESCRIPTION

ABB

Citation preview

Page 1: ABB Review Report Final 1.0

SAP BI Process Review

- ABB

26th August 2013

Page 2: ABB Review Report Final 1.0

2

Agenda

Objective

Current Process Understanding

Support

Development

Recommendation

Support Process

Development Process

Next Step – To Summarize

Some Best Practices

Deliverables

Discussion

Page 3: ABB Review Report Final 1.0

3

Objective

Objective to study the current process and provide

the best practice approach :

Support

Process

Documentation

Development

Process

Documentation

Page 4: ABB Review Report Final 1.0

4

Support Process & Documentation Understanding on Current Status

High / Available

Medium / Partially Available

Low / Not Available

Task

Induction Manual

Project Overview

Getting Started

About the Landscape / Application

Overview of the Functional Modules

Overview of the Service Level Agreement

Project Communication

Hands-off with Other Team

Project Reference Document

Communication process on Data Non-availability to Business User

Data Load Failure / Delay in Data Load

Data Refresh on Ad-hoc / Cut-Over

System Maintenance

Priority Status

Page 5: ABB Review Report Final 1.0

5 Available / High

Partially Available / Medium

Not Available / Low

Task

Alert Message

Data Load Success / Failure Message

Long Running Job

Escalation process

Data Non-availability / Data Load Failure

Governance and Control Process in Production environment

Process Chain Creation / Modification

Infopackage / DTP Creation / Modification (Used in Process Chain)

Data Load Monitoring Kit

Defined frequency wise list of Job’s

Process Chain Summary / Detail design document

Approval Process for Data Refresh on Cut-over / Ad-hoc

Review with Service Manager on pre-defined frequency

Incident Tracking

Priority Status

Support Process & Documentation Understanding on Current Status…Contd

Page 6: ABB Review Report Final 1.0

6

Development Process & Documentation Understanding on Current Status

High / Available

Medium / Partially Available

Low / Not Available

Task

Blueprint Document

Project Overview

About the Landscape / Application

Build Architecture

Authorization Strategy

Testing Strategy

Data Refresh Strategy

Data Retention Strategy

Development Guidelines

Transport Guidelines

Project Communication

Hands-off with Other Team

Project Reference Document

Priority Status

Page 7: ABB Review Report Final 1.0

7

Development Process & Documentation Understanding on Current Status…Contd

High / Available

Medium / Partially Available

Low / Not Available

Task

Development Activity

Requirement Gathering

Technical Design

Technical Design Approval

Unit Testing

Peer Review

System Integration Testing – SIT

User Integration Testing - UAT

KT with Support team - Overview

Deployment

Support

KT with Support Team & Sign-Off

Change Request Process

Priority Status

Page 8: ABB Review Report Final 1.0

8

Recommendation on Support Process

System

Process Chain Re-Design

Alert Message on data load Failure / Success

Synchronizations of Process Chain across landscape

Proper classification on all Incident in HPSM tool

Track all Activity / Issues in Production through HPSM tool

Process

Detailed escalation Process

Support Activity Review Process

Governance and Control Process in Production Environment Changes

Communication Process on Data Non-availability to Business users

Documentation

Induction Manual

Inadequate Job Monitoring List – Required for Day to Day Monitoring

Inadequate Process chain Design – Support document for decision making

before doing any change to process chain

* Any Change Request handle by Support Team would have to follow the Development Guidelines

Page 9: ABB Review Report Final 1.0

9

Recommendation on Development Process

System

Better Use of Technical Content

Review and Redesign the current model as applicable

Process

Setup Build Architecture

Setup Development standards

Setup Transport Strategy

Setup Data Refresh Strategy

Setup Data Retention Strategy

Development Review with architect

Setup Technical Design Approval Process

Better use of HPALM tool for tracking all UAT issues

KT with Support team before and after moving the changes to production

Documentation

Blueprint Document

Page 10: ABB Review Report Final 1.0

10

Current Delivery Model & Implementation Status

Onsite

Offshore

TCS Co-ordinator

ABB Service Manager

TCS Co-ordinator

Other Vendor’s

Implementation Status - Sample Delivery Model

TCS Support &

Development Team

No Standard

Implementation

Approach

Not followed

Naming

Standards

Process Chain Technical Name Schedule Time FrequencyUS Baldor Installed Base ZUSB_IB1 04.14 Daily

CN GPGDS Loads ZGPG_LOADS_CN 20.00 Daily

CN, FI, US MM Source list loads ZGPG_ZEORD 02.00 Daily

DE GPGDS loads ZGPG_DE 19.30 Daily

FI Transactional Loads ZFI_LOADING_NEW 23.30 Daily

US GPGDS Loads ZGPG_LOADS 02.00 Daily

SD: Transactional Data Loading SD_TRAN_META_CHAIN 22.30 Daily

0MAT_PLANT : Mat Plant Load for US only DATA_LOAD_0MAT_PLANT 22.30 Daily

ABB Finland Master Chain (AIM) New ZFIABB_MASTER1 23.33 Daily

Finland CA Master Data CHain ZFI_CA_MD_MAIN_NEW 17.34 Daily

Finland MM Master data main ZFI_MM_MD_MAIN_NEW 18.58 Daily

Finland MM Purchase requisitions 2 at 6:00 ZFI_MM_PURREQ_2 06.00 Daily

Finland MM Purchase requisitions 3 at 12:00 ZFI_MM_PURREQ_3 12.00 Daily

Finland IM Main FI_IM_NEW 02.30 Daily

Process Chain Design - Sample

No

Dependency

on Master &

Transaction

Data Load

InfoObjects

Page 11: ABB Review Report Final 1.0

11

Immediate Step

Immediate Step - Critical

Implementation Best Practice

Approach

Development & Naming Standards

Process Chain Design

Dependency between Master and Transaction data load

Proper Utilization of System - Loading data Parallel

Process

Technical Design Approval

Transport Mechanism

Better use of HPSM / HPALM Tool

KT with Support Team before and after Deployment in Production

System

Security & Authorization in Production

One Version across landscape

Better Use of Technical Content

Page 12: ABB Review Report Final 1.0

12

Ideal Delivery Model

Onsite

Offshore

TCS Co-ordinator

ABB Service Manager

TCS Co-ordinator

Other Vendor’s

TCS Support

Team

TCS Development

Team

BW/BO Architect Roles & Responsibility

Responsible for implementing standards and best

practices

Responsible for smooth Implementation and/or rollout

Collaboration with Business users, vendors and

partners

Identify Roadmap and Strategy

Evaluate and Introduce new technology

Responsible for Knowledge Retention

Support Team Roles & Responsibility

Ensure Data Availability

Responsible for Data Quality

Process Improvement

Quick turn around on load failure / issues

Control on Process Chain Design and Dependency

Support to Business Users

Co-ordination with other teams

Advantages of Recommended Model

Better Solution and Approach

Better Process & Standards

One Version across the landscape

Availability & Quality of data to Business Users

Control on Changes / Transports

Minimize ongoing TCO for maintenance and Upgrade

Improved Business Users Satisfaction

Why do it now ?

Minimal User Base

Minimal Modules / Reports Implemented

Minimal effort on Implementing Changes

Minimal Impact on stabilization

Delivery Model

BW/BO Architect

* Above model not represent actual no of resources

Page 13: ABB Review Report Final 1.0

13

Next Step - To Summarize

1

4

3

2

5

People

Monitor

Transform

Process

Overall

Focused group of BI SME’s and BW/BO Architect skill-set provide better and scalable solution

Set Process to accelerate, % reduction in the number of defects and % reduction in cost of operations

Implement the proposed corrective measures to improve the operations efficiency and information Quality

Clear demonstration of Business Benefits delivered and Improved Business Users Satisfaction Index

Technology adoption, Control on Process and Changes will enhance the overall effectiveness of the system.

Page 14: ABB Review Report Final 1.0

Some Best Practices

Page 15: ABB Review Report Final 1.0

15

SAP BW Infrastructure and Applications

Enterprise wide information infrastructure

Applications

Finance

Operational

Key Performance Metrics in line with Strategy, Goals & Objectives

Tactical

Dashboard Supporting Strategic & Operational

aspects of Business

Strategic

Strategic KPI’s & Predictive Analysis

Sales &

Distribution Operational

Strategic

BI A

naly

tic C

ap

ab

ilit

ies

SAP BI as an Enterprise Data Warehouse

Quality of Measures and Analysis

Build BI Infrastructure and

governance mechanisms

To address Enterprise information

Management needs

Managed Reporting

Day to day operational needs.

Tools : Web Intelligence and Crystal reports

Analyze Business Performance

Access and interpret data for executives and

Managers.

Tools : Analysis for OLAP, Analysis for

office. SAP Lumira & Business Explorer

Measure Business Performance

Mange by metrics.

Tools : Design Studio , Dashboards and

Predictive Analysis

Supply Chain COPA

Page 16: ABB Review Report Final 1.0

16

Selecting the Right Reporting Tool

Page 17: ABB Review Report Final 1.0

17

TCS Confidential

1. Show information on Dashboards that can be acted upon at a glance

• The most important information/KPIs is shown in a very simple format. The type of information should also be able to be acted upon, so that static information is kept to a minimum.

• Based on best practices, it is ideal to limit the number of graphs/elements to 3-7 per report.

2. Need to answer question on each potential KPI on the report: How will the information be used?

• Without a defined purpose of each KPI/element on the dashboard, it will quickly fill with hollow data.

• The first question that users most commonly ask is: “What can I see in the Dashboard?” This question can lead to a polished interface, but primitive capability

3. Eliminate white space without cluttering

• Dashboards need to convey useful information in a few seconds. Too much white space will make the Dashboard seem inadequate. Clutter will make it too difficult to digest at once.

BI/Analytics – Dashboard Design Principles

Wireframe #1

Wireframe #2

Page 18: ABB Review Report Final 1.0

18

TCS Confidential

4. A Dashboard report is not used to show all information of a system at once

• Many times, users think they want to see ALL the information on a particular segment of the business in one report (sales, distribution, marketing). If we show too much information and make too many connections, the performance of the reports will suffer, and the end users will abandon using the Dashboard.

• The Dashboard will also become too complex to quickly mine information from.

5. There must be context for each element on the Dashboard

• Showing two completely different KPIs that are not related to each other serves no purpose. Those KPIs must be on a separate report, or one must be dropped.

• Having KPIs that are based or work off each other is the most optimal way to show information.

6. The most important information should be located on the left-top/center of the screen

• Eyes tend to gravitate towards those areas

• Focusing on placing elements in these areas will allow for a more natural flow of the Dashboard

• The area that is least noticed by the user is the bottom right

Wireframe #3

Wireframe #4

BI/Analytics – Dashboard Design Principles (contd.)

Page 19: ABB Review Report Final 1.0

19

BW Build Approach 1

Maste

r D

ata

Meta

Data

Data

Dis

trib

uti

on

(O

utb

ou

nd

) la

ye

r

SAP ECC Source System

Staging Layer

Transformation Layer

Subject Layer

Reporting Layer

Data Structure for Business

Analysis & Reporting

Stable Structure , No Reporting

Transformation representing

Business Subjects

Stores one day Data as close

to source system

No

n-S

AP

Syste

m

No Transformation

Transformation

No Transformation

Source of Data

Op

en

Hu

b

Page 20: ABB Review Report Final 1.0

20

BW Build Approach 2

Maste

r D

ata

Meta

Data

Data

Dis

trib

uti

on

(O

utb

ou

nd

) la

yer

SAP ECC Source System

Staging Layer

Propagation Layer

Transformation Layer

Subject Layer

Reporting Layer

Data Structure for Business

Analysis & Reporting

Stable Structure , No Reporting

Transformation representing

Business Subjects

Stores one day Data as close

to source system

Stores Data as close to source

system with region wise split

No

n-S

AP

Syste

m

No Transformation

Division wise Split

Transformation

No Transformation

Source of Data

Op

en

Hu

b

Page 21: ABB Review Report Final 1.0

21

Sample Process Chain Design

Page 22: ABB Review Report Final 1.0

22

Deliverables Support

Induction Manual Template

Data Load Monitoring Kit

KT Checklist

Escalation Process Document

Monthly Review Meeting with Service Manager Template

Weekly Review with Technical Lead Template

Development

Blueprint Template

Project Plan Template

Estimation Template

BI Test Case Template

BI Test Plan Template

Architecture Guidelines

Development Guidelines

Page 23: ABB Review Report Final 1.0

23

Deliverables…Contd Development

Naming Standard Guidelines

BO Authentication Guidelines

BO Security Guidelines

BO Performance Guidelines

Requirement Checklist

BO Deployment Checklist

BO Dashboard Standards

BO Design Standards

Page 24: ABB Review Report Final 1.0

Discussion

Page 25: ABB Review Report Final 1.0

Thank You