0
Inside an SAP Business
Intelligence Project,
Part 1: Best Practices
for Planning and Project
Management
Dr. Bjarne Berg
COMERIT
© 2010 Wellesley Information Services. All rights reserved.
In This Session …
•
Get expert advice on how to budget, scope, and manage
an SAP business intelligence project – Ranging from
SAP BusinessObjects implementations to leveraging
portals
•
Hear best practices for writing a solid business case for
your BI initiative, defining reasonable scope agreements,
creating a rollout strategy, developing budgets, picking
the right front-end tools, and creating a project
organization that matches scope and delivery plans
2
In This Session … (cont.)
•
Walk through real examples of four SAP customers that have
implemented SAP BusinessObjects dashboards and cockpits, and
learn how to avoid their top 10 project pitfalls, including performance
and user interface deployment
•
Explore functional specifications and requirements, and glean
insight into which reports should remain in SAP ERP and which can
be leveraged by your SAP business intelligence and SAP
BusinessObjects front-end tools
•
Take home best-practice functional specification templates, staffing
templates including roles and responsibilities, and decision flow
charts for SAP business intelligence projects
3
What We’ll Cover …
•
•
•
•
•
Planning your SAP business intelligence project
Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up
4
Planning Your SAP Business Intelligence Project
1.
2.
3.
4.
The business case
Scope agreement
Milestones
Steering committee
5
Writing the Business Case
•
•
The business case must be aligned with some
concrete business benefits
The best way to write a business case is to align it
with one of these areas:

Money

Strategy

Reducing time and effort of delivery

Improved information quality
and access for end users
6
Business Case Ideas
Area
Observation
SAP
BI BI
Benefit
Cost of Ownership
Maintaining a custom developed
BI solution is complex and
expensive
SAP is responsible for
maintenance of the
product
Cost Avoidance
Updating extract programs
when upgrading ERP is
expensive
BW – ERP integration
points are maintained
and tested by SAP
Substantial cost savings, by
not having to redevelop new
extract programs for each
SAP upgrade
Web strategy
Web delivery requires rapid data
delivery of high consistency with
the source system
BW is closely integrated
with ERP and can deliver
data that reflects the
source system at short
time intervals
Enables web initiatives to get
closer to the source data,
both in time and consistency
Reconciliation Effort
A substantial portion of the data
warehouse effort is spent on
reconciling information
BW is “closer” to the
source system, and more
accurately reflects data
Users spend less time on
reconciling data, and more
time analyzing it
Information Access
Business users need a high
availability solution
Load times in BW are
less than traditional,
custom- developed
data warehouses
Users get earlier access to
information
Substantial maintenance
cost savings
7
More Business Case Examples
Area
Observation
SAP BI
Benefit
Faster Deployment
Need to increase time to
deliver new applications and
enhancements to existing
areas
Typical use of 60-80%
of predelivered
content increases
development speed
Reduced development
time for new decision
support areas
Integrated Products
SAP continues to offer new
products and modules that
the organization might wish
to leverage in the future
SAP NetWeaver® BW
is the “cornerstone”
of SAP’s BI product
offerings
Enables closer
integration with other
SAP modules
Query speed
Business users need fast
access to their data
Through use of
summaries and the
SAP NetWeaver BW
Accelerator, the blade
architecture lends
itself to faster inmemory query
performance
Users get the data they
need quickly to perform
their job functions
8
Three More Business Case Examples
Area
Observation
SAP BI
Benefit
SAP Strategy
It is the organization’s
SAP strategy to leverage
investments in SAP to
the fullest extent, and
maximize SAP resource
utilization
SAP BI is an SAP product,
and is based on standard
SAP NetWeaver®
technologies (Basis,
ABAP, kernels, etc.)
Strategic fit and synergy
with SAP. SAP Basis,
ABAP, etc., resources
can be used across SAP
projects, including SAP
BI
Tool
Standardization
The organization must
be able to leverage
industry standards to
enable business users to
access data in a variety
of ways
Interfaces such as ODBO
and MDX and Java are
supported by a variety of
major presentation and
Web tools. SAP
BusinessObjects tools can
be integrated rapidly via
“native: connections
Simplifies user access
to data; expands options
for using standard
presentation and Web
tools or developing your
own
Industry Trend
The organization’s
competitors and some of
the organization’s
business areas are
installing SAP BI
Increased industry
resource pool and
knowledge of SAP BI
Enables the organization
to leverage industry
solutions and know-how
9
The Scope Agreement Dimensions
•
•
For the first go-live, keep the scope as small as possible
 For example, Accounts Payable, Accounts Receivable, G/L, or
COPA
You have only three dimensions to work with, if one of these
dimensions changes, you have to adjust at least one of the others
Scope
Resources
(people, technology,
and money)
Time
There is a limit to how far you can compress timelines:
Brooks law states that "Nine women cannot make a baby in one month“*
* Frederick Brooks, The Mythical Man-Month, Addison-Wesley, 1975)
10
The Scope Agreement — A Discovery Exercise
•
Determining the scope is done in a variety of ways, depending on
which methodology you employ. It is a complex process
involving:
1. Discovery and education
An SAP BI implementation involves more
than black-and-white technical decisions;
2. Formal communication
just because something is technically
3. Reviews
feasible, doesn’t mean it is wise or desirable
from a business perspective.
4. Final approvals
Source: Gooy_GUI, 2007
11
Defining The Scope Of Your SAP BI Implementation
•
First, determine what the business drivers are; Then meet these objectives
•
Define the scope in terms of what is included, as well as what is not included
•
Make sure you obtain approval of the scope before you progress any further. All
your work from now on will be based on what is agreed to at this stage.
•
As part of the written scope agreement, make sure you implement a formal
change request process. This typically includes a benefit-cost estimate for each
change request and a formal approval process.
Source: Gooy_GUI, 2007
12
Change Management Process
IT responsible
Change
Request form
Integration tested
QA environment
Business responsible
No
Approved?
Sr. mgmt. responsible
Yes
Approved?
Submission
No
No
Complete?
No
Approved?
Yes
Yes
Moved to
production
System tested
Scheduled
Dev. Environment
Yes
Review
Recommended?
No
Change
Request form
Unit Tested
Developed
Dev. environment
Yes
No
13
Approved?
Yes
The Change Management Form — Page 1
•
•
•
To make this process work, you need a formal instrument
The instrument can be online (i.e., a Web page), electronic (Word
document), or a paper-based system
The form should contain at least these fields
Change Request Form
Requestor Name:
Department
Phone number / email
The front page
that the
requestor fills
out
Describe the change requested, be
detailed
Why is it needed
How important is it that the
change occur? (how would you
manage if this is not done)
TBD
When is the change needed
When
possible
Future
release
Date
Break-fix
(right now)
14
The Change Management Form — Page 2
•
•
This page is used by the system administrator or the project team
The purpose is to have controlled changes that are scheduled and
tested appropriately
For internal use only
Received date:
Reviewed by:
Comments/recommendation
The back page
that the
system admin
and approver
fill out
Pending
Not-Approved
Future
release
Approved
Break-fix
(right now)
Pending
Prototyped
In QA
Tested
In Production
Approval status:
Approved by:
Approved date:
Assigned to:
Due date:
Development status:
15
15
Do You Have a Plan? The Six Dimensions of BI Management
•
•
There are six core global dimensions you must consider before embarking on a
BI project
Project management is important, but it’s only one of these dimensions
 Failure to account for the others may result in project failures.
Source: Peter Grottendieck, Siemens
For each dimension, articulate an approach, constraints, limitations, and
assumptions before you start your project.
16
What We’ll Cover …
•
•
•
•
•
Planning your SAP business intelligence project
Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up
17
Organizing your BI initiative
1. Budgeting
2. Project team organization
3. User Acceptance Testing (UAT) and Rapid Application
Development (RAD)
18
Budgeting Process Steps
1.
2.
3.
4.
Size the SAP BI effort based on the scope
Prioritize the effort
Map the effort to the delivery schedule
Plan for number of resources needed based on the scope,
delivery schedule, and the effort
Create the Milestone Plan and Scope Statement first, before attacking
the budgeting process
Start the budgeting process by estimating the workload in terms of the
development effort. Refine based on the team’s skill experience and skill
level
19
1. Size the SAP BI Effort Based on the Scope —
Real Example
Customi
zation
L
M
L
M
L
M
L
L
L
L
L
L
L
L
L
M
M
M
M
Tech. Dev.
infocube
Financials
General ledger line item (ODS)
COPA
Prod cost planning released cost
estimates (COPC_C09)
Exploded itemization standard
product cost (COPC_C10)
Cost and allocations
(COOM_C02)
Cost object controlling
(0PC_C01)
Order
Extraction and Report
transforms
and roles
Security and
scheduling
Web
development
User
support/
planning
Project mgmt System docs Tech infraand admin
& manuals
structure
Bus. Analysis,
training, req.
gathering, change
mgmt.
Total
Hours
216
158
216
229
286
229
188
153
188
101
127
101
132
153
133
134
152
135
100
120
100
79
94
79
150
180
150
403
470
403
1,732
1,893
1,734
238
286
216
126
153
152
120
94
180
470
2,035
216
1144
188
101
132
135
100
79
150
403
2,648
238
286
216
137
153
152
120
94
180
470
2,046
216
216
216
229
229
229
187
187
187
101
101
101
132
132
132
135
135
135
100
100
100
79
79
79
150
150
150
403
403
403
1,732
1,732
1,732
216
229
187
101
132
135
100
79
150
403
1,732
216
216
228
228
187
187
101
101
132
132
135
135
100
100
79
79
150
150
403
403
1,731
1,731
Delivery data of shipment stages
(0LES_C13)
Delivery service (0SD_C05)
Planning and Scheduling
Material Movements (0IC_C03)
216
228
187
101
132
135
100
79
150
403
1,731
180
229
133
101
132
134
100
79
150
403
1,641
216
457
132
101
132
134
100
79
150
403
1,904
APO Planning
SNP Integration
Manufacturing Processes
Production Orders
Cross Applications
Total Hours
277
277
832
832
216
216
127
127
153
153
152
152
120
120
94
94
180
180
470
470
2,621
2,621
277
277
4,298
832
832
8,074
216
216
3,587
127
127
2,110
153
153
2,656
152
152
2,681
120
120
2,040
94
94
1,606
180
180
3,060
470
470
8,126
2,621
2,621
38,238
Billing
Sales order
Acct. Rec. (0FIAR_C03)
Deliver
Shipment cost details
(0LES_C02)
Shipment header (0LES_C11)
Stages of shipment (0LES_C12)
Remember that your sizing also has to be based on the team’s
experience and skill level.
20
2. Prioritize the Effort
The next
step is to
prioritize
and outline
the effort
on a
strategic
timeline
Make sure your sponsor and the business community agree with
your delivery schedule
21
3. Use Project Estimates and the Timeline to Create Project Load Plan
There are 480 available work hours per project member per quarter.
Knowing this, we can plan the number of team members we need…
22
4. Result: Good Input for the Staffing Costs and Planning
Use this information to plan for training, on-boarding, and staffing
Number of team members
This spike in
resource needs
is due to an
overlap in the
delivery
schedule
14
12
10
8
6
Now might be a
good time to
review that
decision
4
2
qtr 1
qtr 2
qtr 3
qtr 4
qtr 1
qtr 2
qtr 3
qtr 4
qtr 1
qtr 2
qtr 3
Many companies plan a 60%- 40% mix of internal and external resources for a
first go-live. Also, most use $50-$90 per hr for internal budgeting and $90$170 per hr for external resources.
23
How Tightly Should Multiple BI Projects be Controlled?
The relationship between
control and success
according to a conference
Board Survey of 89 BI
projects.
Coordination of Multiple Business Intelligence Projects
Tight Central Control
(24%)
Loose Cooperation
(38%)
Independent
(38%)
88% Successful
30% Successful
100% Successful
Source: The Conference Board Survey
24
Six Ways to Organize your BI Project Team
Option
1
Single site
2
Distributed analysis
3
Distributed analysis and design
4
Co-located analysis and design
5
Multiple co-located analysis and design
6
Fully distributed development
Benefits
Risks
The more distributed the BI
development effort becomes,
the more difficult it is to
maintain communication and
get cohesive requirements.
25
Example 1 — Small Project Team Organization
•
These are roles, not positions

Many companies fail to
formally assign roles and
responsibilities.
Sometimes one team member can
fill more than one role
As a result, they have
many “jack of all trades”
and “masters of none.”
Project Sponsor
Project Manager
Business Team
Business Analyst
Presentation Developer
Technical Team
BI Architect
ETL Developer
BI Basis and functional SAP ERP support
Four to five team members and normally
three to six months duration on each go-live depending on scope
ETL = Extract, Transform, and Load
26
Example 2 — Medium Project Team Organization
This model scales well to
teams of up to 12-15 people
Project sponsor/
Steering
Committee
Project Manager
SAP BI
Architect
Extract,
Transforms
and Loads
Business
Analyst(s)
Data Management
(InfoCubes &
ODS)
Presentation
Developer(s)
- cockpits & queries
Sr. Business analyst
Sr. ETL developer
Sr. SAP BI developer
Sr. Presentation
developer
Business analyst
ETL developer
SAP BI developer
Presentation developer
Basis and functional ERP support
8-10 team members and normally
2-4 months duration depending on scope
27
Example 3 — Large Project Team Organization
Project Sponsor/
Steering Committee
Project Manager
In larger teams, you need to
create functional teams, instead
of the previous technical team
models. This is to avoid “islands”
of teams that are not really
integrated
BI Architect
Portal Developer(s)
Sales Team
Finance Team
Business Analyst/(sub-team lead)
BI Developer
Presentation Developer(s)
ETL Developer
Business Analyst/(sub-team lead)
BI Developer
Presentation Developer(s)
ETL Developer
Material Mgmt. Team
Business Analyst/(sub-team lead)
BI Developer
Presentation Developer(s)
ETL Developer
BI Basis and functional SAP ERP support
15-30 team members and normally
6-18 months duration between each go-live
28
On-Boarding ,Training, and SAP Courses
BW Developer
ETL Developer
Presentation Developer
Project Manager
Business Analysts
Ref
BW-310
BW-305
BW-350
BW-360
BW-361
BW-365
SAP-330
Course
Intro to SAP BI
BI Reporting & Analysis
BI Data Acquisition
BW Performance & Admin
BW Accelerator
BW Authorizations
BW Modeling
Ideal Yrs
Experience
(minimum)
2+
Training days In-house
(if new in the training
role)
days
15
3-5
3+
15-20
3-5
1+
5-10
3-5
5+
10-15
3-5
5+
5-10
3-5
Who should take the training
All
End user support and Training
Data loads and Fixes
System admin
System admin
Information risk mgmt
System admin
Don’t underestimate the value of in-house, hands-on
training in addition to formal SAP training classes.
29
The User Acceptance Group and Its Role
•
Create a user acceptance team consisting of five to seven members
from the various business departments or organizations
•
Keep the number odd to assist with votes when decisions need to be
made. With fewer than 5 members, it can be hard to get enough
members present at each meeting
•
Make this team the focus of your requirements gathering in the early
phase, then let this team perform user acceptance testing during the
Realization phase
•
Meet with the team at least once a month during realization to refine
requirements as you are building, and have something to show them
This approach is hard to execute when also managing scope, but is
essential to make sure that the system meets users’ requirements
30
RAD Approach For Smaller BI and Cockpit Projects
•
In Rapid Application Development (RAD), keep the scope focused
and use a simple approach
Activate
standard content
Request for
modifications
Inscope?
Yes
Make
enhancements
No
Load InfoCube
User
acceptance
session
Test
In-future
scope?
No
Review data
quality issues
Create 2-3
sample queries
Deploy
Rejection
In RAD, no functional or technical specs are used in this approach. Over 8-16
weeks, multiple user acceptance sessions are used to refine requirements and
multiple prototypes are built (think rapid interactive prototyping).
31
What We’ll Cover …
•
•
•
•
•
Planning your SAP business intelligence project
Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up
32
Example 1 — Build on a Solid Foundation
•
•
In this company, the data
volumes were very high
Therefore, a set of
summary cubes were
used instead of building
dashboards on top of
large InfoProviders
Lessons # 1: Make sure you build dashboards on top of summary cubes
and data stores where the volume is small and queries can run fast.
33
Example 1 — Build on a Solid Foundation (cont.)
Lesson #2: Modularize the
data and always leverage
MultiProviders.
•
This reduces data
replication, decreases the
number of data updates,
and makes the data
available to the end user
faster.
•
You can also use the
MultiProviders for other
summary reports beyond
the dashboards.
34
Example 2 — Compare to Plans
Lesson #3: Adding
forward looking
dashboards that are
linked to Business Plans
(BP), Rolling Estimates
(RE), and Prior Year (PY)
makes the dashboard
more meaningful.
Lesson #4: Create charts that “predict” where the sales will be each
month if the trend continues. This makes the dashboard actionable
and tells the users what needs to be done.
35
Example 3 — Provide Numbers, not Just Graphs
Lesson #5: Almost
all dashboards
should have graphs
as well as numbers.
Do not create a
visually pleasing
dashboard with just
images. People are
visual as well as
numerical oriented.
In this example, users can toggle between tables and graphs. This
means that the same information does not consume a large space.
36
Example 4 — Create Drill Downs from Dashboards
Lesson #6: Users want to see the details without having to log-on to a separate
system. It is not advisable to try to cram too much details in a single management
cockpit (max. 500-1000 rows).
Instead, create jump-to reports from the dashboard. This can be to Interactive
Analysis (SAP BusinessObjects Web Intelligence ) or to existing BW Web queries.
37
Example Four — Online Help and Metadata
Lesson #7: When presenting numbers on charts and complex graphs, you should
always provide an online explanation for:
• What the numbers mean
• How they are calculated
• How you read the graphs
This can be developed inside SAP BusinessObjects Dashboard Builder (formerly Xcelsius®).
38
It Is All About Performance, Performance, Performance
Lesson #8: It is hard to build a fast dashboard with
many queries and panels without SAP NetWeaver
BW Accelerator. This provides in-memory
processing of queries that is 10-100x faster.
Lesson #9: Pre-running queries into cache via BEx
Broadcaster requires more memory than the 200MB
default values. Analyze your server and consider
increasing the cache to 400MB+.
Lesson #10: MDX cache is for OLAP Universes, OLAP cache is for BICS
connectors used by SAP BusinessObjects Dashboard Builder. Think how
you are accessing the data before you performance tune the system and
always conduct a stress test before deploying any dashboards.
39
What We’ll Cover …
•
•
•
•
•
Planning your SAP business intelligence project
Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up
40
Getting Started
1. Methodology and Functional Specs
2. Tool Selection
3. Report dispositioning
41
Pick a Formal Methodology — You Have Many Choices
•
•
Accelerated SAP (ASAP) methodology is not your only choice
Even though they are harder to manage on a global project due to
long communication lines, consider RAD, JAD, or EP based on
the time to delivery and impact of failure
When to Select Different Methodologies
High
Joint Application Design
(JAD)
System development Lifecycle
based methodologies
(SDLC)
Time to
Delivery
Extreme Programming
(EP)
Rapid Application Development
(RAD)
Look at what your
organizational partners
have done.
You may know more about
RAD than you think!
Low
Low
High
Impact of Failure
Source: Bjarne Berg, Data
Management Review 2004
42
Monitoring BI Quality and Formal Approval Process:
Example
Integration
Testing
Create Technical
specs
No
Create Functional
specs
System Testing
Complete?
No
Yes
Unit Testing
Complete?
Yes
Configuration
Yes
Peer Review
No
Approved?
Peer Review
Yes
No
Complete?
Yes
Approved?
Structured
walkthrough
No
No
Complete?
Yes
Structured
walkthrough
43
Sample Info Request Form
•
•
•
•
Documents requirements in
a standardized format and
allows for a large comment
section
Prioritizes requirements
Consolidates requirements
Supports follow-up
discussions and reviews
Sample Info Request Form (cont.)
•
Other uses
 Post the form on the
intranet, thereby giving
stakeholders an easy
way to communicate
with the project team
 Use the Comment
section for language and
security requirements, or
add a separate section
for this
 Note the section for
dispositioning the
requirement
45
What Dashboard and Cockpit Tool to Select
•
•
All SAP tools have strength and weaknesses
This is a subjective summary of each of the major dashboard
tools
Development
Capabilities
Tool
End
User
Power
User
Author
IT
Developer Graphing Navigation
External
data
External
web
services
Simplicity
OLAP
Ad-Hoc
querying
Longterm
Stategy
Web
Application
Designer
Dashboard
Designer
(Xcelsius)
Visual
Composer
Interactive
Analysis
(WebI)
46
SAP's Vision — Who Should Do What … ..
•
SAP has a vision of which SAP BusinessObjects tools are
appropriate for the different user groups
Source: SAP
47
Team starts by reviewing documentation tool for
documentation completeness
An example of how to decide
which reports should be in ERP or
the legacy system
cu
Review requirements and identify
corresponding Data Model (InfoCube/ODS)
D1
Is report
documentation
complete?
Yes
D1a
Is this a true
reporting
need
No
(refer to printed version)
Communicate to
bus. leader
Yes
No
D2
Is this
an Intraday
report?
Request additional
input from Business
Team member
No
D2.5
Does data exist
in "in-scope" models
Infocube/ODS
Yes
Yes
Yes
D6
Does
Standard BW
content
exist?
Yes
BW is selected as
Reporting Tool and
documented in doc.
tool
Communicate final
disposition
No
D7
Is it less
expensive to
create in
ERP?
No
BW is selected as
Reporting Tool
and documented
in the documentation tool
Communicate final
disposition
D8
Is BI cost
effective?
Communicate final
disposition
ERP is selected as
Reporting Tool
and documented
in doc. tool
Communicate final
disposition
Yes
D9
ERP Tool
Selection
Process
BW is selected as
reporting tool and Change
Request is submitted if
the scope changed
No
Standard
ERP
Yes
ERP is selected as
Reporting Tool
and documented
in doc. tool
No
No
ERP is selected as
Reporting Tool
and documented
in doc. tool
Yes
A2
Total Cost of
Ownership
Analysis
Communicate final
disposition
D5
Does
Standard ERP
content
exist?
D4
Is the report
system
resource
intensive?
No
Yes
ERP is selected as
Reporting Tool
and documented
Responsible
Team member
acquires/documents
additional information
No
D3
Significant
number
of users?
BW is selected as
Reporting Tool and
documented in doc.
tool
Communicate final
disposition
48
BW Team to forward completed detailed report specifications
based on selected Reporting Tool - BI or ERP
Communicate final
disposition
ABAP/
Custom
Report
Writer
Query
Other
A3
Sub-Process Report Consolidation &
eliminate if appropriate (winnowing)
ERP team make final disposition
A4
Baseline reports
What We’ll Cover …
•
•
•
•
•
Planning your SAP business intelligence project
Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up
49
Resources
•
Evan Delodder and Ray Li, Creating Dashboards with
Xcelsius: Practical Guide, SAP PRESS, 1st Edition;
(September 15, 2010)
•
Boris Otto and Jörg Wolter, Implementing SAP Customer
Competence Center, SAP PRESS, 1st edition; 1st edition
(December 1, 2008)
•
by Frank K. Wolf and Stefan Yamada, Data Modeling in
SAP NetWeaver BW 7.1, SAP PRESS, 1st Edition;
(August 1, 2010)
50
7 Key Points to Take Home
•
•
•
•
•
•
•
Do not jump into a dashboard project. Create a formal strategy,
plan, budgets, and scope, and train your staff before you start.
Have a formal organization, but do not overstaff. Skills are more
important than numbers.
Spend serious time on the backend BI system. Not all systems are
ready for dashboards – Performance is essential.
Consider SAP NetWeaver BW Accelerator as part of your
dashboard project.
Rollout interactive analysis (SAP BusinessObjects Web
Intelligence) as part of the dashboard project – Details are
important and users want drill-down capabilities.
Make the first rollout short and focused (12-16 weeks max).
Use Rapid Application Development (RAD) as you methodology –
Anything else does not make sense!
51
Your Turn!
How to contact me:
Dr. Berg
Bberg@ComeritInc.com
52
Disclaimer
SAP, ERP, mySAP, mySAP.com, SAP NetWeaver®, Duet™®, PartnerEdge, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product
and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by
SAP.
53