Download - ABB Review Report Final 1.0
SAP BI Process Review
- ABB
26th August 2013
2
Agenda
Objective
Current Process Understanding
Support
Development
Recommendation
Support Process
Development Process
Next Step – To Summarize
Some Best Practices
Deliverables
Discussion
3
Objective
Objective to study the current process and provide
the best practice approach :
Support
Process
Documentation
Development
Process
Documentation
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
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
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
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
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
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
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
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
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
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.
Some Best Practices
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
16
Selecting the Right Reporting Tool
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
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.)
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
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
21
Sample Process Chain Design
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
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
Discussion
Thank You