1. Migrate and Evolve with SAP ERP
Achieve a successful SAP ERP version upgrade project
Draw full advantage from the investment made
White Paper
exchange&sharing
www.askconseil.com
/ImprimerieNPC0155902920Conception:
www.usf.fr
ISBN : 2-9523607-0-7 50 e
2. Migrate and Evolve with SAP ERP
Achieve a successful SAP ERP version upgrade project
Draw full advantage from the investment made
White Paper
exchange&sharing
4. WHITE PAPER / page 3
We particularly wish to thank the enterprises who have readily accepted to reply as well as
the colleagues who spent time participating in the interviews to provide us with the most
meaningful experience feedback elements. For confidentiality reasons and, in compliance
with the study protocol, their names are not disclosed here.
We also thank the board of directors of USF, for having outlined the Terms of Reference
of this study, facilitated its conduct and carefully monitored its progress all the way:
Didier Gamain (GDF SUEZ), Hermine Quilici (COFIROUTE), as well as USF’s administrative
services.
Our thanks go also to the two ASK Conseil managers who have operationally conducted
the two studies related to this White Paper: Alexandre Colonna d’Istria for the first one,
Didier Cohen for the second.
Paris, 15 October 2008
Eric Remy
Chairman of The USF
Technology Commission
Gilbert Grenié
Associate Director
ASK Conseil
acknowledgements
5. page 4 / WHITE PAPER
WHITE PAPER / Migrate and Evolve with SAP ERP
n n n First study: the SAP ERP version upgrade project . . . . . . . . . . . . . . . . . . . . page 7
The approach adopted
Applied method, Sample analysis, Results analysis, the version upgrade project contribution to SAP
governance.
The results obtained
Operational control over the version upgrade project, impact on users, cost control and alignment with the IT
Division’s policy, added value to perspectives, key indicators of a version upgrade.
Risk factors and best practices
Recommendations for the organization of a version upgrade project
The phases of a SAP ERP implementation project, splitting the project in work groups, key points for each stage
of the project.
Conclusion
Observations, recommendations.
n n n Second study: SAP ERP’s strategic perspectives . . . . . . . . . . . . . . . . . . . . page 65
The approach adopted
Applied method, sample analysis, results analysis.
Evolution of expectations in relation to ERPs
Operations oriented expectations (flexibility, differentiation…), management oriented expectations (cost control,
data security…).
Perception (by the enterprises) of the SAP ERP offer structure
The NetWeaver stack, the SOA concept, the functional contributions, the complementary bricks to ECC, the
solution maintenance tools.
Analysis of SAP ERP’s contributions
Rather satisfied and rather unsatisfied expectations.
Strategies considered during the implementation
Risks and opportunities brought by SAP ERP
At business level, at IS level, analysis of potential gain in function of the enterprise’s context.
Segmentation
Application case study.
Recommendations
Conclusion
structure of the paper
6. WHITE PAPER / page 5
This study has been conducted by USF (Club des Utilisateurs SAP Francophone – SAP French
Speaking Users Club) and ASK Conseil in two phases. The first phase is a synthesis from feedback
emanating from French and German companies who have completed the version upgrade from
SAP R/3 to SAP ERP 6.0 The second phase is a synthesis of a set of views from enterprises who
have completed their upgrade or are in the process of completing it and who wish, once the first
phase of the upgrade has been completed, to draw full advantage from the investment.
Previous studies, conducted in 2004 and 2006 and which were followed by the publishing of
two White Papers by ASK Conseil, had highlighted the maturity level concept of an enterprise in
relation to SAP as well as a set of good governance rules which allow a better management, over
time, of its SAP investment.
These best practices came from feedback from companies using the SAP R/3 4.7 or prior versions.
Subsequently, came the evolution to my SAP ERP 5.0 and the current version SAP ERP 6.0. This
version is the subject of this White Paper, which incorporates ECC (Enterprise Central Component),
the new version of our historic core R/3 as well as the NetWeaver platform.
The Business Suite includes, SAP ERP, SAP CRM, SAP SCM, SAP SRM and SAP PLM components
each of which is a separate product on its own, based on the NetWeaver platform.
This new SAP version came out with innovative features which are likely to provide added value
to those companies who know how to take advantage from them. It was tempting to find out
whether, in practice, the companies who had “taken the leap” had been able or not to take
advantage of the features and, if so, to what ends.
Where do we stand to-day, more than two years now after the SAP ERP6.0 launch, and what are
the interim observations that can be drawn?
• Taking into account the technological leap, is this version upgrade
project more complex and difficult to successfully achieve than the
previous version upgrades or not?
• What are the main problems and risks that should be avoided?
• What is the impact on the users?
• Does this version upgrade allow the enterprise making the
investment to, in effect, profitably utilize, due to the new
NetWeaver platform, SAP ERP’s opportunities and promises in the
main fields claimed by the editor? (“people” integration, process
integration, technology integration, information integration,
improvement of the SAP CC IT processes, etc.)?
• How do companies plan the timeframe for the new technical
base deployment and the exploitation of the new version’s
opportunities, and what are its key success factors? Are these
projects part of a strategic plan of deployment of new formal and
shared SAP services within organisations?
introduction
7. page 6 / WHITE PAPER
introduction
Finally, does such a version upgrade represent a strong indication from the enterprises who have
gone through the upgrading process that they have in place a governance policy of their SAP ERP
Information System?
This White Paper attempts to shed some initial light on these questions.
Based on the interviews conducted, it seems to us that this White Paper may interest several levels
within the organisation:
Our immediate wish is that this White Paperwill immediately assist companies to achieve their
upgrade and draw full advantage from their investment.
It is important to highlight that this study has been conducted independently from the Editor and
that these results are being presented in compliance with the ethics rules and neutrality which
are at the basis of the USF charter.
Readers are invited to send us all their questions to the following email address: relation@usf.fr
• What short term benefits do enterprises derive from this upgrade
and what are the planned medium term benefits?
• Are the selected SAP architectures aligned on expected future
benefits from the new SAP system and are those same benefits, in
turn, themselves aligned with the enterprise’s strategy?
• Does the NetWeaver platform and its underlying technologies and
new languages allow a deployment of the various announced SAP
services with minimal specific developments? (for example on SAP
Enterprise Portal…).
• General Management of course, provided that it dedicates some
of its time to this important subject, often misrepresented as IT
technique
• The IT Division, which is primarily involved since the SAP
Competence Centre will have to maintain, exploit and promote
this new version as well as develop the overall IS strategy inclusive
of non – SAP applications.
• The business managements, who have participated in the selection
of SAP as the core solution for the enterprise and need to have a
visibility into the features capabilities and potential limits of this
new version, including performance.
8. THE SAP ERP VERSION UPGRADE PROJECT / page 7
Migrate and Evolve with SAP ERP
THE SAP ERP VERSION UPGRADE PROJECT
White Paper
studyfirst
10. THE SAP ERP VERSION UPGRADE PROJECT / page 9
This first study aims at assisting companies that have not yet performed their technical upgrade
to SAP 6.0, derive the best possible value while limiting the risks. It is a follow up to the inquiry
on version upgrade which was conducted in summer 2007 and is in line with USF’s objective to
provide its members with impartial and exploitable information.
Over and above establishing how to ensure a successful technical upgrade project, this study aimes
to determine the value obtained following the technical upgrade: was the lack of enthusiasm
from enterprises to upgrade to SAP ERP 6.0 evidenced during the 2007 USF convention inquiry,
justified?
The first chapter covers the study and its objectives. The second chapter describes the method
utilized. The third provides the main quantitative results of our study: statistics and indicators.
In the fourth chapter, we discuss the main risk factors identified as well as the recommended
best practices. The fifth chapter proposes a technical upgrade project model, based on customer
feedback.
The conclusion summarizes the main observations found and suggests a prospective orientation
to the SAP ERP version upgrade for the enterprises who have not yet migrated or those which
would like to derive greater benefit from their version upgrade.
introduction of the first study
11. page 10 / THE SAP ERP VERSION UPGRADE PROJECT
The methodology consisted of conducting interviews with 19 French and German companies.
The sample size chosen may not be statistically valid, but is still sufficient for the purpose of
providing insight and guidance.
It was not possible to select the companies by industry sector, size or other criteria. As the pool of
companies who had already upgraded and inclined to participate in this study would be limited,
we accordingly looked for most companies who had already upgraded and had a relationship
with USF. This is particularly valid for France. Obtaining replies from companies in Germany was a
more challenging effort, primarily due to the absence of a sponsoring entity, such as USF.
A questionnaire was distributed to the participants and included questions to gauge the extent
of the SAP footprint (quantitative) and the extent to which the participating company adopted
best practices (qualitative).
In order to ensure the reliability of the information gathered, each interviewee validated the
interview minutes; the latter remaining confidential, as agreed with the enterprises.
The answers were subsequently categorized and statistics and correlations made, based on the
answers obtained from participants. The categories are shown below.
Finally, the study summarized the primary lessons learned in terms of best project practices and
value added for the enterprise.
Out of the 19 enterprises, 15 were interviewed in France by ASK and the remaining four were
interviewed in Germany by our partner WESTTRAX.
The main industrial sectors represented were: Services, Health, Energy, Food-processing,
Chemicals, Pharmaceuticals, Manufacturing, Automobile, Telecommunications, Distribution
(Retail), Associations, Insurance, Publishing.
APPLIED METHOD
the approach adopted
studyfirst
SAMPLE ANALYSIS
12. THE SAP ERP VERSION UPGRADE PROJECT / page 11
In terms of enterprise size,
the following repartition is
observed:
In addition, let us
highlight that:
n 63% of the
enterprises have less
than 300 users and
only 37% have several
thousands of users.
The large enterprises,
less enthusiastic, have
invited the Middle Market
enterprises to play the
leading roles.
n Among the enterprises
interviewed, more than
50% are international
ones (multi-country)
and 84% are multi-site
ones (the majority are
“extended enterprises”
with both local and global
systems).
0%
5%
10%
15%
20%
25%
30%
35%
10 0001 000
to 10 000
100
to 1 000
= 100
Business Turnover in EURk
Size of the enterprises in the sample what does
this chart represent in terms of size?
0%
5%
10%
15%
20%
25%
30%
35%
40%
2 000500 to 2 000200 to 500 200
Number of users
CA en k
Number of “super” users
As regards the number of intensive users, it is spread according to the following repartition:
It appears that Enterprises who have already completed their SAP
ERP technical upgrade have a smaller number of users. To determine
if the number of users influences the decision to upgrade, a
subsequent study was undertaken.
theapproachadopted
SAMPLEANALYSIS
13. page 12 / THE SAP ERP VERSION UPGRADE PROJECT
theapproachadopted
level 1
1 unique
SAP system
level 2
between
2 to 3
SAP systems
level 3
between
4 to 5
SAP systems
level 4
between
6 to 10
SAP systems
level 5
over 10
SAP systems
For the SAP technical upgrade project, 13 dimensions were identified, each associated with
5 complexity levels. On a scale of 1 to 5, 5 reflects the highest complexity score.
Project dimensions of a version upgrade
n n n Organisation of the enterprise: countries, companies, sites
level 1
single country
enterprise,
single
company and
single site
level 2
single country
enterprise,
single
company and
multi-site
level 3
single country
enterprise,
multi-company
and multi-site
level 4
multi-country
enterprise,
multi-company
and single site
level 5
multi-country
enterprise,
multi-company
and multi-site
n n n Number of users: number of SAP users (“super” users)
level 1
up to 250
users
level 2
251 to
500 users
level 3
501 to
1000 users
level 4
1001 to
5000 users
level 5
more than
5000 users
n n n Number of SAP systems in production: number of SAP components in the enterprise
(one or more instances of core SAP R/3, a SAP BI system, a SAP CRM system, a SAP ARO system, an
Industry Solution)
complexity levels:
SAMPLEANALYSIS
14. THE SAP ERP VERSION UPGRADE PROJECT / page 13
theapproachadopted
level 1
1 SAP
system
level 2
2 SAP
systems
level 3
3 SAP
systems
level 4
4 or 5 SAP
systems
level 5
more than
5 SAP systems
level 1
ECC 5.0
version
level 2
SAP R/3 4.7
version
level 3
SAP R/3 4.7
version/3 4.6
level 4
SAP R/3 4.0 or
4.5 version
level 5
SAP R/3 3.x
version
level 1
core R/3
with 1 to
3 modules
level 2
core R/3
with the main
modules
level 3
core R/3 with
the main
modules
+ 1 additional
component
(CRM, BW,
APO,
an Industry
Solution,…)
level 4
core R/3 with
the main
modules
+ 2 additional
components
level 5
core R/3 with
the main
modules
and at least
3 additional
components
level 1
conformity
with the
standards –
targeted and
limited specific
developments
( 100 m/d)
(- 100 H)
level 2
selective and
filtered usage
via a demand
validation
committee (
500 m/d)
(-500 H)
level 3
extended
usage with
a controlled
specifics
mapping(500
to 3000 m/d)
(to 3000 /H)
level 4
extended
usage but
with an
uncontrolled
specifics
mapping (500
to 3000 m/d)
level 5
absence of
governance
and no control
over the usage
of specifics
(3000 m/d)
n n n Number of upgraded SAP ERP systems: number of distinct SAP components which are in
the version upgrade scope and which have effectively been migrated
n n n Functional scope of upgraded SAP systems: (what R/3 modules, what other components:
BW, CRM, SRM…)
n n n SAP R/3 source version (betweenR/3 3.0 and R/3 4.7)
n n n Adherence to Governance Standards, such as the number of specific developments conducted
around the R/3 core, the principles applied by the enterprise to adhere or not to the SAP standard, the
control process around enhancement demands
SAMPLEANALYSIS
15. page 14 / THE SAP ERP VERSION UPGRADE PROJECT
theapproachadopted
level 1
one centralized
SAP CC (usually
1 unified Core
Model)
level 2
SAP CCs by
branch or
business (several
Core Models
dedicated
by branch or
business)
level 3
one competence
entity per
production
environment
(primarily
administrative,
operations)
level 4
1 centralized
operations
center
level 5
absence
of internal
competence unit
level 1
SAP
communicates
with minor
components in
the landscape.
(non critical
solutions)
level 2
SAP
communicates
with a limited
number of
software
packages from
third party
bolt-ons (limited
interfaces)
level 3
SAP
communicates
with a limited
number of
software
packages from
third party
bolt-ons SAP
or not (limited
interfaces)
level 4
SAP
communicates
with internal
software
packages and
developments
(mapping
application
of medium
complexity)
level 5
SAP
communicates
with internal
software and
developments
(complex
mapping
application
- numerous
interfaces)
level 1
90% are internal
resources 10%
are external
resources
level 2
internal
resources
mobilized and
combined
with external
resources
representing
between 10% to
30% of the cost
level 3
internal
resources
mobilized and
combined
with external
resources
representing
between 30% to
60% of the cost
level 4
internal
resources
hardly available,
requiring
more reliance
on external
resources 60%
of the cost
level 5
Internal
resources limited
to testing tasks
(IT Division
testers and key
users)
n n n SAP integration with non SAP systems: relates to SAP’s mapping application and its
complexity (SAP interfaces, legacy and third party bolt-ons)
n n n Several SAP CC organisation models, depending on the enterprise’s maturity level and
the IS strategy (variable scope, including parameter setting or not, developments, management of
user data, middleware administration and DBMS ….)
n n n Ability to perform the technical upgrade (sufficient trained staff; degrees of reliance
on third party resources on T+M or fixed price)
SAMPLEANALYSIS
16. THE SAP ERP VERSION UPGRADE PROJECT / page 15
theapproachadopted
level 1
very good
level 2
good
level 3
fair
level 4
weak
level 5
very weak
level 1
very good
level 2
good
level 3
average
level 4
weak
level 5
very weak
level 1
updating of
the technical
platform (ISO
functionalities)
and modification
of the IS
components
(OS, DBMS,…)
level 2
level 1 +
implementation
of Unicode
level 3
level 2 +
implementation
of SAP ERP
functionalities
(not
implemented
under R/3)
level 4
level 3 +
implementation
of NetWeaver
functionalities
level 5
level 4 +
activation of
an Industry
Solution
n n n Technical upgrade combined with new functionality, new components of Industry
Solutions
n n n Use of tools; the extent to which tools are used for testing and other project activities
n n n Project management best practices: relates to an evaluation of the maturity level of
the enterprise in project management (implementation of an internally developed initiative for
a version upgrade project, project phase planning, project communication, management of risk
portfolio, analysis phase of anticipated impact, splitting of the project by work breakdown schedule/
packages, monitoring of deliverables, project status reporting, etc. – formalization and spreading of
best practices within the IT Division project teams IT)
SAMPLEANALYSIS
17. page 16 / THE SAP ERP VERSION UPGRADE PROJECT
theapproachadopted
The benefits of the version upgrade project can be assessed used the Balanced Score Card
approach.
n n n Prospective Balanced Score Card applied to SAP version upgrade projects
contribution to the enterprise’s policy
How do the shareholders
perceive IT services?
Mission: Obtain a reasonable contribution to
the enterprise’s business from IT investments.
Strategies: Control over IT expenses, business
value of projects (project ROI), contribution of new
abilities to the enterprise…
user
How do the users
perceive IT services?
Mission: To be the preferred supplier to the users
(applications and processing).
Strategies: Propose the best solution, regardless of
the source, partnership with the users, perceived
quality of the service, delivery delays.
future orientations
Is IT well positioned to respond
to future needs? (ability to improve
the products and services of the enterprise
and create value)
Mission: Develop opportunities to respond to
future needs.
Strategies: General and professional training of
the IS / IT staff, expertise of IT staff, research of
emerging technologies and solutions to improve
the agility and flexibility of the IS.
operational excellence
What is the efficiency of IT processes?
Mission: Deliver efficient services and applications.
Strategies: Efficiency of developments, deliveries,
maintenance and systems operations.
SAMPLEANALYSIS
18. THE SAP ERP VERSION UPGRADE PROJECT / page 17
theapproachadopted
ANALYSIS OF RESULTS OBTAINED
We have evaluated the contribution of a version upgrade project, based on 15 criteria. Applying
the Balanced Score Card principles, we have regrouped the criteria as follows:
contribution to the enterprise’s policy
- SAP operations and maintenance costs
- adherence to budget
- increase of technical resources
- global satisfaction of IT Division
user
- user satisfaction
- improvement in performances
- system downtime
- freeze on developments
future orientations
- contribution to business
- reduction of the specifics list
- strategic lever for the IT policy
operational excellence
- achievement of project objectives
- adherence to detail
- compatibility / Interoperability
- reliable start up
n n n Contributions of a SAP ERP version upgrade: Cost, Utilization, Future use (business
growth), Operational excellence
SAP GOVERNANCE VISION: SAP GOVERNANCE VISION: WHAT
CONTRIBUTION FROM THE SAP ERP VERSION UPGRADE PROJECT?
Any IT Master Plan should align with the business direction of the enterprise. To facilitate the
interpretation of the results, we will utilize the criteria contained in the Balance Score Card.
19. page 18 / THE SAP ERP VERSION UPGRADE PROJECT
THE STUDY RESULTS
User Dashboard
n n n Performance improvement: did the migrated SAP systems show improved, deteriorated
or stable performance?
n n n User satisfaction: assessment of the enterprise’s business management satisfaction
(project impact on service levels, ownership of the new SAP ERP version, project communication
with users)
n n n Code freeze: period during which enhancement requests have been frozen
n n n System downtime: from a user perspective, was the SAP system unavailable due to switch
over operations (switch to live production)
level 1 level 2 level 3 level 4
significant
deterioration
slight deterioration iso performance improved
performance
level 1 level 2 level 3 level 4
more than 2 days 1 to 2 days approximately
1 day
no downtime
level 1 level 2 level 3 level 4
unsatisfied fairly satisfied satisfied very satisfied
level 1 level 2 level 3 level 4
freeze 70%
of the project
duration
40% freeze
70% of the project
duration
20% freeze
40% of the
duration project
freeze 20%
of the project
duration
the results obtained
20. THE SAP ERP VERSION UPGRADE PROJECT / page 19
theresultsobtained
Operational Excellence Dashboard
n n n Post Go Live Reliability: assessment of the reliability level of the delivered solution,
(number and criticality of the problems and incidents that occurred after SAP ERP went live)
n n n Achievement of the project objectives: global assessment of the enterprise (usually from
the SAP CC responsible person) on the achievement of the project objectives
n n n Adherence to scheduled time line: was the scheduled live production date adhered to?
n n n Compatibility issues / interoperability: issues faced during the project and especially
post migration regarding the interoperability between the new SAP version and other business
software packages, specific developments, operational tools and other IS components (database,
operating systems), output management software, mail servers, EAI other than PI,…
level 1 level 2 level 3 level 4
unsatisfied fairly
satisfied
satisfied very satisfied
level 1 level 2 level 3 level 4
major
compatibility or
interoperability
issues faced
minor
compatibility or
interoperability
issues faced
no issues faced improved
interoperability
of some IS
components
level 1 level 2 level 3 level 4
objectives
not achieved
objectives
partially achieved
objectives
achieved
objectives
exceeded
level 1 level 2 level 3 level 4
planning
exceeded by more
than 50%
planning
exceeded by
25% to 50%
planning
exceeded by less
than 25%
planning adhered
to
THESTUDYRESULTS
21. page 20 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
Future Orientations Dashboard
Contribution to the enterprise’s policy Dashboard
n n n Contribution to business (es): contribution of the version upgrade towards achievement
of business objectives (availability of new functionalities…)
n n n Reduction in the specifics list I donlt understand this? What is the specifics list? any
reductions or not in the list of SAP specific developments and to what extent?
n n n Strategic lever for the IS policy of the enterprise: does the version upgrade project
contribute to the improvement of the enterprise’s IS?
n n n SAP maintenance costs: costs after the SAP migration (including the administration and
maintenance of the migrated SAP system, the associated middleware and DBMS, as well as the OS
management, the server (s), the storage and the high availability)
level 1 level 2 level 3 level 4
partial misalignment
of the IS and the
business
no change minor contribution
(availability of minor
functionalities)
major contribution
(major evolutionary
maintenance
operations)
level 1 level 2 level 3 level 4
increase of more than
10%
increase between 5%
and 10%
no increase in costs reduction in costs
level 1 level 2 level 3 level 4
increase
in the number
of specifics
Carry over
of specifics
limited reduction
in specifics
high reduction
in the number
of specifics
level 1 level 2 level 3 level 4
exploitation of SAP
ERP’s opportunities
not planned (nothing
concrete)
exploitation of SAP
ERP’s opportunities
planned (projects in
pipe line)
effective and minor
exploitation of SAP
ERP’s opportunities
(implemented in the
course of the project)
effective and major
exploitation of SAP
ERP’s opportunities
(implemented in the
course of the project)
THESTUDYRESULTS
22. THE SAP ERP VERSION UPGRADE PROJECT / page 21
0%
20%
40%
60%
80%
100%
ExceededAchievedPartially
achieved
Not
achieved
Achievement of the project goals
theresultsobtained
n n n Increase in technical resources: evaluation of the percentage increase in technical
resources necessary for the smooth functioning of the new SAP version (disk space, processor
memory, number of servers)
n n n Adherence to the allocated budget (investment in licences, hardware, other IS components
and service providers’ costs)
level 1 level 2 level 3 level 4
increase exceeding
25%
increase between
15% and 25%
increase below 15% budget adhered
to, and even below
forecast
level 1 level 2 level 3 level 4
increase of more than
10%
increase between 5%
and 10%
increase below 5% no increase
n n n IT’s satisfaction with service providers including, knowledge transfer dispensed by SAP
level 1 level 2 level 3 level 4
unsatisfied fairly
satisfied
satisfied very satisfied
ACHIEVEMENT OF PROJECT OBJECTIVES
n An average score of
2,9 / 4 on this angle for
the interviewed enterprises.
n Most enterprises
interviewed (95%)
estimated having
achieved the objectives
in their project Plan.
The graphic below shows
the results obtained in terms
of achievement of project
objectives.
THESTUDYRESULTS
23. page 22 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
n Note: in the remaining
part of this document, the
terms I am not familiar
with this (functional
version upgrade equal”
and “technical version
upgrade” will be utilized
in an equivalent manner.
0%
10%
20%
30%
40%
50%
60%
Idem +
business
solution
Idem + Netweaver
architecture
evolution
Idem +
SAP ERP
functionalities
Idem + technical
evolutions
(Unicode or Cis)
Technical
platform
migration
CA en k
Version upgrade project typology
This result is very high but what does it hide in practice? To ascertain this, it appears necessary
to examine the objectives which the enterprises set to themselves before starting their version
upgrade project.
The detailed list of objectives mentioned by the enterprises is given below. We have structured
this list by BSC dashboards. Some of these objectives came up in the course of the project, in an
opportunistic logic (for lack of advance project planning in some cases).
Operational Excellence Dashboard
• Centralization of the SAP system monitoring, alert management and the level 4 tickets
between SAP CC and the Editor (thanks to Solution Manager).
• Improvement of the integration between the SAP system and the non SAP systems (for
example: retain SAP ERP’s mail server instead of a third party server or implement SAP
partner editors’ solutions which secure some operating tasks such as failed backups).
ACHIEVEMENTOFPROJECTOBJECTIVES
• It is observed that most enterprises (72% in all) have limited
their objective to a technical upgrade. Few enterprises (17%)
retained a functional objective for their version upgrade and still
less (11%) retained a utilisation objective of the new NetWeaver
architecture.
24. THE SAP ERP VERSION UPGRADE PROJECT / page 23
theresultsobtained
User Dashboard
• Unicode implementation.
• Delivery of new functionalities to the SAP (for example: New General Ledger).
• Compliance with legislation in the financial field (application of IFRS norms to the
groups’ entities).
• Implementation of some core SAP modules which are more refined in SAP ERP than
in R/3.
• Activate some SAP add-ons.
• Improve the availability of “real time” information, particularly in the client relationship
management field (updating of real time information between the SAP back office and
SAP CRM).
Contribution to the Enterprise policy Dashboard
• Avoid the increase in maintenance (+2% in Year 1 and + 2% applicable from the
following year) of SAP R/3 by reverting to a standard maintenance contract.
• Reduction in hosting and costs of SAP systems by simplifying the system landscape and
by centralizing and mutualising the IT resources (opportunistic logic of outsourcing a
number of IT areas).
• Renegotiation of third party applications maintenance by attempting to reduce the list
of specific developments.
Future Orientations Dashboard
• Facilitate the implementation of business projects through the modernization of the
SAP system base (SAP ERP is promising in business opportunities and innovations in the
field of integration of processes, human resources, technologies and information).
• Prepare the deployment of new major SAP system components (for example: the
enterprise portal so as to allow subsidiaries which are equipped with non SAP IS to
access the QM module and utilize part of the SAP system services rendered in the
quality management field).
• Replace the EAI by the PI (previously called XI).
We enumerate here the general objectives stated by the enterprises. Most of these
objectives have not been part of planned projects within a strategic planHave a more
reliable, state of the art technical platform so as to allow the SAP system to support
the growth of the enterprise (creation of new entities or easier integration of new
subsidiaries).
ACHIEVEMENTOFPROJECTOBJECTIVES
25. page 24 / THE SAP ERP VERSION UPGRADE PROJECT
n Finally (see graphic
below), only 16% of the
enterprises interviewed
have taken advantage of
this project to utilize the
new SAP ERP features.
89%
No Unicode
11%
Unicode
40% No
Unicode
60%
Unicode
Multi-country enterprisesSingle country enterprises
CA en k
Unicode implementation
60% of the multi-country enterprises (and, hence, multi-characters) have implemented Unicode
so as to manage character translation.
theresultsobtained
The objective has, no doubt, been achieved for most enterprises but the ambition was limited.
Why?
0%
10%
20%
30%
40%
50%
Effective exploitation
of SAP ERP
and / or
NetWeaver
opportunities
Effective
exploitation
of SAP ERP
opportunities
Exploitation
planned
Exploitation
not planned
Strategic lever for the IS policy
Idem + évol.
techniques
(Unicode ou Cis)
• First of all, the enterprises have followed the editor’s
recommendation: separate the technical version upgrade from the
functional aspects and, thus isolate the risks.
• Most of the enterprises have not clearly realized the functional
contributions of the new version.
ACHIEVEMENTOFPROJECTOBJECTIVES
26. THE SAP ERP VERSION UPGRADE PROJECT / page 25
theresultsobtained
Most enterprises already
have SAP version upgrade
project experience: 63% of
the enterprises interviewed
had already conducted
at least one R/3 upgrade,
which has facilitated achie-
vement of the objectives as
the process, mechanisms
and stages of prior projects
remained applicable.
0%
2%
4%
6%
8%
10%
12%
4 release
upgrades
3 release
upgrades
2 release
upgrades
1 release
upgrade
Experience of the enterprises in SAP version upgrades
• And also, the contribution brought by the new NetWeaver
technical architecture has appeared complex to implement; The
enterprises who already have an EAI are keeping it because a
change of EAI is a complex project, which needs to be conducted
in an independent and progressive manner.
• Finally, management involvement is generally observed as rather
low, to attach more ambitious objectives to this version upgrade.
This is, no doubt, due to lack of time, information and SAP ERP
vision.
• Thetechnicalversionupgradehighlightedanumberofperformance
issues, necessitating a global system tuning.
• The interviewees expressed post upgrade regrets that they had
not enough taken into account two things: the possibilities of
reducing the number of specific developments / modifications
carried over into the upgrade and also the possibility of exploiting
the functional contributions of the new version.
On the other hand, we have observed a good experience level on the SAP technical version
upgrades.
As regards the 5% enterprises whose objective was only partially achieved, two factors explain
this:
ACHIEVEMENTOFPROJECTOBJECTIVES
27. page 26 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
Observation n° 1 : The SAP ERP version upgrade project has mainly been perceived as a technical
project, which most enterprises estimate having achieved.
We finally arrive to a first observation:
OPERATIONAL CONTROL OF THE VERSION UPGRADE PROJECT
This observation is indeed encouraging for the enterprises: their already acquired experience
in SAP version upgrades is re-usable, the announced technological leap does not lead to major
difficulties on the project. At the same time, however, this observation reinforces the question on
what economic value has been derived by the enterprise from this version upgrade. We will go
into further depth on this question.
n An average score
of 3,9 / 4 on this angle
of analysis for the
enterprises interviewed.
n Most companies
(94%) report
compliance with the
planning provided.
0%
20%
40%
60%
80%
100%
No delayDelay
10%
Delay
25%
Delay
50%
Adherence to the project time line
Let us first take a closer look at the results obtained in terms of operational control of the version
upgrade.
• An underestimation of the adaptation charge and of the specific
developments testing.
• Supplier delays in equipment delivery.
This good result is attributed to the good control levels exercised by the project teams of the
version upgrade project, the absence of major show stoppers during these version upgrade
projects and the stability of the SAP ERP version which, as at the date of this study, is more than
a year and a half old.
As to the 6% enterprises that have not adhered to their planning, the main reasons are:
ACHIEVEMENTOFPROJECTOBJECTIVES
28. THE SAP ERP VERSION UPGRADE PROJECT / page 27
theresultsobtained
n An average score of
2,4 / 4 for the enterprises
interviewed.
n 50% of the
enterprises interviewed
indicated having met
with minor or major
interoperability issues
between the new
migrated SAP version
and its IS environment.
0%
10%
20%
30%
40%
50%
Improved
interoperability
No issuesMinor issuesMajor issues
Compatibility and interoperability issues
• A version upgrade of the interfaced tool as a prerequisite.
• Some adjustments: parameter setting modification or, even code
modification.
• Implementation of SAP Add-On.
• DBMS version delet all withs below.
• Some messaging tools.
• A property management software.
• Some fax servers.
• Some barcode scanners.
• Some “.net” connectors.
• Some archiving tools.
Most of the interoperability issues were dealt with by:
NB: Unicode has generated incompatibility issues (in some cases, it has been necessary to change
the backup robot.
Examples of tools / applications for which issues were observed by some enterprises:
Major issues: A number of interoperability issues observed with third party products such as
application scheduler, backup software and other IS components such as the OS, some database
versions etc. These issues are being addressed by the Technologies Commissions of the USF.
Minor interoperability problems observed with:
OPERATIONALCONTROLOFTHEVERSIONUPGRADEPROJECT
29. page 28 / THE SAP ERP VERSION UPGRADE PROJECT
What are the possible causes of these difficulties? Can the “Integration with non SAP systems”
context explain the observed phenomenon? For this purpose, we calculate: the proportion of
enterprises that have expressed an issue and / or those that have not expressed any issue. And this
proportion is calculated, on one hand, for the enterprises that have a rather complex mapping
and, on the other hand, for those enterprises that have a rather simple mapping.
Terminology:
Simple mapping application:
few interfaces between SAP and other IS applications SAP interacts with other IS components
which we consider as minor (services of weak business or operations criticality). SAP communicates
mainly with partner editors’ software packages (standard connectors).
Complex mapping application:
numerous interfaces between SAP and other IS applications. These applications are either
software packages from partner editors as well as non SAP partners, or specific developments
realized by internal teams.
theresultsobtained
n n n Incidence of the mapping
Hence the table below:
simple
mapping
interoperability
issues
no interoperability
issues
complex
mapping
33%
67%
71%
29%
The mapping complexity is clearly and logically a source of interoperability issue for the
enterprises.
An enterprise which disposes of a complex mapping will accordingly have to take special
precautions to analyze and verify these interoperability issues.
OPERATIONALCONTROLOFTHEVERSIONUPGRADEPROJECT
30. THE SAP ERP VERSION UPGRADE PROJECT / page 29
theresultsobtained
• Implementation of the SAP fax coupling tool.
• Replacement of an external mail server by the SAP mail server.
As for the few enterprises who have observed an improvement of their interoperability, the
contributions mentioned are:
n An average score of
3,2 / 4 on this aspect
for the enterprises
interviewed.
0%
20%
40%
60%
80%
100%
Very
satisfactory
SatisfactoryFairly
satisfactory
Unsatisfactory
Reliability at start up
• The adaptation of specific developments by allowing a swift identifica-
tion of the reasons for the specific development and by facilitating the
identification of the adaptations to be realized.
• Well documented and up to date test scripts for the main business
streams.
The degree of satisfaction towards the quality level of the project is linked to the number and
seriousness of the incidents that occurred during production but also to the quality of the project
deliverables, particularly the functional documentation, the updating of test plans, and the
validating scenarios.
Few of the enterprises interviewed had registered an important volume of anomalies and these
anomalies were essentially minor. As regards documentation, the enterprises having replied to the
question had quality documentation at their disposal at the end of the project.
It is noted that the quality of the available documentation relating to the existing system has
allowed a significant gain of time for some enterprises for:
OPERATIONALCONTROLOFTHEVERSIONUPGRADEPROJECT
31. page 30 / THE SAP ERP VERSION UPGRADE PROJECT
Observation n° 2 : Most enterprises have secured their operational control of the version upgrade
project, the main difficulty to be anticipated being the interoperability of the new version within
its environment.
Hence, this observation:
IMPACT ON USERS
Finally, the global score obtained for the Operational Excellence Dashboard on the sample of
enterprises interviewed stands at 3,1/ 4, which denotes a satisfactory level of operational control
of the technical version upgrade project.
n An average score of
2,9 / 4 for the people
interviewed.
n Most users were
satisfied with the
version upgrade
(87,5%).
0%
20%
40%
60%
80%
100%
Very
satisfied
SatisfiedFairly
satisfied
Unsatisfied
User satisfaction
What was the impact of
this project on the users?
The SAP ERP user interface remains unchanged in relation to the SAP R/3 4.6C and 4.7 versions
and the technical migration does not require any specific training.
theresultsobtained
achievement of
objectives
2,9
adherence to
time line
3,9
interoperability
2,4
reliability at
start up
3,2
overall
operational
control
3,1
OPERATIONALCONTROLOFTHEVERSIONUPGRADEPROJECT
32. THE SAP ERP VERSION UPGRADE PROJECT / page 31
n An average score of
3,1 / 4 for the enterprises
interviewed.
n Most enterprises
(60%) have achieved
their version upgrade at
ISO performances level.
0%
10%
20%
30%
40%
50%
60%
70%
ImprovementIso-
performance
Slight
deterioration
Significant
deterioration
Performances of the SAP system
• The SAP ERP version upgrade was limited to a technical project,
not introducing anything new to the business.
• In general, most enterprises view this project as a relatively
transparent one for the business, except that it necessitates user
mobilization for the tests and validations.
12,5% were fairly satisfied, mainly for the following reasons:
theresultsobtained
• Insufficient sizing of the production equipment.
• Poor tuning of the production equipment.
• Cleaning and reorganisation of databases.
• Increase in the existing production equipment capacity.
• Installation of new, more powerful, servers (more CPU – increase
in the number of SAPS, in disk memory).
• Move to 64 bit.
• Change in technical architecture – Example: mutualisation of
resources, virtualization of servers.
12% of them faced a slight or significant deterioration, principally attributed to the following
factors:
And, worth highlighting, 28% managed to obtain an improvement in performance following the
version upgrade, mainly attributed to the following reasons:
The version upgrade project has been utilized as an opportunity for technical optimization
by a significant number of enterprises.
IMPACTONUSERS
33. page 32 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
n 40% of the
enterprises have been
able to complete their
version upgrade project
without any downtime
seen by the user (in
other words, with a
technical switchover
performed during
a weekend without
disruption during the
week).
n An average score of 2,9 / 4 on this angle of analysis for
the enterprises interviewed.
n The remaining 60% had between 1 to 4 working days of
downtime but most of the enterprises remained within one
downtime day.
0%
5%
10%
15%
20%
25%
30%
35%
40%
No
downtime
1 dayBetween
1 and 2 days
Exceeds
2 days
System down time from the users’ perspective
Business downtime is the unavailability of the SAP system during normal work hours. In most
cases, it is the down time duration over and above the cut over weekend.
Note that the duration of the switchover process (downtime) includes the export process of
production data from the existing R/3 DBMS and the import of that same data in the target SAP
ERP DBMS. Accordingly, the more voluminous the data is, the longer is the process, resulting in
a correlated downtime duration.
Finally, we observe that the analysis of the downtime factors identified during the interviews
highlights the main following causes:
• The average real migration time observed from the old system to the
new one is slightly superior to 2 days (2,2).
• Accordingly, enterprises organize themselves to conduct this migra-
tion over a weekend, or even better, a prolonged weekend (3 days),
so as to minimize the impact on their business activity.
IMPACTONUSERS
34. THE SAP ERP VERSION UPGRADE PROJECT / page 33
theresultsobtained
n An average score of
2,4 / 4 for the people
interviewed.
0%
5%
10%
15%
20%
25%
30%
Freeze
20%
20%
Freeze
40%
40%
Freeze
70%
Freeze
70%
Freezing of enhancements as a % of the project duration
What are the factors that lead to decide on the duration of the freeze?
The decision to freeze enhancements is linked either:
• To minimize the impact risks of a system downtime on business
activity, the enterprises interviewed have conducted at least one
“practice” migration so as to verify the smoothness of the process
and also to check whether the migration time is satisfactory in
terms of business downtime.
• Some enterprises have had to extend the migration time in view of
unsatisfactory delays noted during the practice migration.
• Some companies have reduced their downtime by applying the
“downtime minimized” migration methods proposed by SAP via
the SAPUP’s System switch upgrade option.
• To a low volume of enhancements requested by the business.
• To a lack of availability of the resources responsible for enhan-
cements as they are busy with the migration project – this lack
of availability is either total since the beginning of the project or
progressive as the migration approaches its completion.
• To an historical scenario whereby enhancement requests have
typically always been made by the business managements in an
uncontrolled manner. This lack of control and policy in place for
the management of the SAP Core Models in production has thus
prompted IT Division Management, as a measure of precaution to
put a freeze on all such enhancement requests at an early stage
of the upgrade.
IMPACTONUSERS
35. page 34 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
The choice between a complete freeze on enhancements at the beginning of the project or a
partial / progressive freeze is accordingly dependent on the enterprise’s context, its organisation,
the availability of its internal resources, its configuration management method and on the control
over the underlying risks.
Note that some enterprises, having achieved a good level of governance maturity of their SAP
Core Model solution, are able to introduce a progressive freeze on enhancements process which
takes into account:
• The need to be responsive to enhancement requests which are
critical for the business (high financial, commercial stakes,...).
• The constraints of the version upgrade project (insistence on the
acceptance of the requests depending on the various stages of the
project).
• Once the development environment has been migrated, any new
production enhancement needs, need to be kept in synch with the
configuration (prior and post migration).
• To a combination of these various reasons.
In conclusion, the freeze on enhancements policy appears to vary to a great extent,
depending on the enterprise’s context.
Observation n° 3 : The SAP ERP version upgrade project, as conducted by most enterprises, ge-
nerates low impact on the users, the most significant impact being the freeze on enhancements,
of variable duration, depending on the enterprises.
Hence, this observation:
Finally, the global score obtained for the Users Dashboard on the sample of enterprises inter-
viewed, stands at 2,9 / 4 which denotes a good transparency level towards the users for the
technical version upgrade project: the users have hardly been disturbed and, also hardly involved,
with the exception, for some enterprises, for their participation in testing. Hardly involved?
user
satisfaction
2,9
performances
3,1
downtime
2,9
freeze on
enhancements
2,5
global
transparency
towards the users
2,9
IMPACTONUSERS
36. THE SAP ERP VERSION UPGRADE PROJECT / page 35
theresultsobtained
CONTROL OVER COSTS AND ALIGNMENT WITH IT POLICY
THE IT DIVISION’S POLICY
n An average score of
2.7 / 4 for the enterprises
interviewed.
0%
10%
20%
30%
40%
50%
60%
70%
ReductionNo
increase
5% Increase 10%Increase
exceeding
10%
SAP system operations and maintenance costs
Let us now examine how
does the version upgrade
project position itself
in relation to the policy
objectives of IT Division
IT, in particular of control
over costs.
• Most enterprises have not attempted to utilize the version upgrade
to reduce operations and maintenance costs linked to the suppres-
sion of specific developments which are unutilized or transferable
within the standard.
• Apart from the above factor, there is a quasi mechanical growth
in costs, following the version upgrade, even if one of the major
aims stated by the enterprises was to avoid the 2% rise in main-
tenance costs (for the first year), at the end of the standard SAP
maintenance contract (and another+2% applicable as from the
second year).
We note that, for the majority of enterprises, the operations and maintenance costs have remained
stable (for 94% of the enterprises). In our view, this means two things:
We have a slightly paradoxal result here: the enterprises, for the major part, went into
the version upgrade project with the aim of avoiding an increase in operations costs (the
SAP licenses) but they did not succeed in going further into their analysis of opportunity
gains, in particular, by trying to reduce the volume of specific enhancements that needs
to be maintained.
37. page 36 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
As regards the enterprises who have highlighted an increase in operational and maintenance
costs, it is the increasing complexity to exploit the new system which causes the increase.
As for those who managed to obtain a reduction in costs, they attribute it to the following
reasons:
• The mutualisation of the new system operations with others,
internal or external.
• The setting up of a more homogeneous technical architecture,
resulting in a reduction of the number of technologies to be
maintained and, hence, a reduction in the number of types of
technical experts to be mobilized.
n An average score of
3,8 / 4 for the enterprises
interviewed.
n Most of the
enterprises (87,5%)
stayed within budget.
0%
20%
40%
60%
80%
100%
Adherence
to the budget
Increase
15%
15% Increase 25%Increase
25%
Adherence to the budget of the SAP ERP version upgrade project
No
increase
15% Increase 25%
• A wrong estimation of the adaptation costs of the specific
developments.
• To a wrong equipment sizing, thus necessitating the purchase of
supplementary resources.
This result is coherent with the control over time line already observed earlier.
However, some of them exceeded the budget due to:
CONTROLOVERCOSTSANDALIGNMENTWITHITPOLICYTHEITDIVISION’SPOLICY
38. THE SAP ERP VERSION UPGRADE PROJECT / page 37
theresultsobtained
n An average score of
2.2 / 4 for the enterprises
interviewed.
n Around 78% of
the enterprises have
taken advantage of
the technical version
upgrade project to
increase the technical
resources utilized.
n An average score of
3,1 / 4 on this angle
for the enterprises
interviewed.
n A fairly general
satisfaction level is
apparent here from
IT Division: IT : the
“technical version
upgrade” project has
not appeared to be a
disturbing project for
the IT Division IT, be
it in terms of strategic
alignment or risk
incurred.
0%
5%
10%
15%
20%
25%
30%
35%
40%
No
increase
Increase
5%
5% Increase 10%Increase
10%
Increase of technical resources
0%
20%
40%
60%
80%
100%
Very
satisfied
SatisfiedFairly
satisfied
Unsatisfied
IT’s global satisfaction: IT
The enterprises have, in effect, wanted to anticipate the subsequent extension of their ERP
(external growth…) and have accordingly invested technically.
The IT Division is globally satisfied with the service providers chosen
and the tasks realized (IS architecture, technical migrations of
databases, OS versions changed or migrated and the SAP software
package).
As regards enterprises that have expressed dissatisfaction, this
appears to be mainly due to their budget having been exceeded.
CONTROLOVERCOSTSANDALIGNMENTWITHITPOLICYTHEITDIVISION’SPOLICY
39. page 38 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
To note, however, including for the globally satisfied enterprises, an expression of regret,
sometimes, for the perhaps too limited ambition on the project conducted which could have
constituted the opportunity for:
• Optimizing / harmonizing / homogenizing the technical architec-
ture.
• Eliminating the obsolete specific developments.
• The version upgrade is not really being utilized by the entreprises
as an opportunity for reduction of operation and maintenance
costs or of the project cost itself. Reduction of costs is indeed pos-
sible by reducing the volume of modifications to be carried over
(available benchmarks show that, on average, 30% of the specific
developments / modifications are not actually utilized in practice
or are hardly utilized). Are the enterprises properly advised by their
service providers? Or do we not have here a divergence of interest
risk which should be closely monitored?
• The final result of this situation is that, taking into account the
technical investments conducted and, short of a systematic, deter-
mined policy on the specifics, the general trend would seem to be
that of a slow, moderate but real growth in SAP operations and
maintenance costs.
This apparently satisfactory result however appears to us as hiding two realities:
No doubt, the IT Divisions, used as they are to additional costs of functional projects, feel satisfied
here, with a technical project that has stayed within budget. This misleading parallel however
leads to neglecting the opportunity of optimizing one’s operations and maintenance costs thanks
to the version upgrade project.
Finally, the global score obtained for the Control over costs and alignment Dashboard with IT
Division’s policy the IT Division’s policy, is 2,9 / 4, which denotes a good alignment level.
operations
cost
2,7
project
budget
3,8
technical
resources
2,2
IT
satisfaction
3,1
global
result
2,9
CONTROLOVERCOSTSANDALIGNMENTWITHITPOLICYTHEITDIVISION’SPOLICY
40. THE SAP ERP VERSION UPGRADE PROJECT / page 39
theresultsobtained
n An average score of
2,9 / 4 for the people
interviewed.
n For the large majority
of enterprises (72%),
the version upgrade
conducted has no
positive impact on
the businesses (which
is coherent with the
objective, limited,
more often, to a purely
technical version
upgrade).
0%
20%
40%
60%
80%
100%
Major
contributions
(evolutions)
Minor
contributions
(adaptations)
No
change
Partial
disalignment
with business
Contribution to business
Over and above the technical short term results, in what strategic perspective is positioned the
SAP ERP version upgrade?
This result is accordingly not surprising, the more so, given the Editor’s recommendation to
conduct a technical version upgrade prior to any functional project, is known and respected by
the enterprises.
We have, however, also observed a weak knowledge of the functional possibilities brought by the
new SAP version. Enterprises are complaining about the lack of information from the editor on
the functional enhancements of the new version.
Observation n° 4: Most IT divisions appear satisfied with the control over operations and main-
tenance costs following the version upgrade. But the opportunity to reduce these costs, notably
by the reduction of the specifics maintained, is not really exploited.
Hence, this observation:
ADDED VALUE TO STRATEGIC PERSPECTIVES
CONTROLOVERCOSTSANDALIGNMENTWITHITPOLICYTHEITDIVISION’SPOLICY
41. page 40 / THE SAP ERP VERSION UPGRADE PROJECT
theresultsobtained
n An average score of
2.8 / 4 for the people
interviewed.
n An average score of
1,8 / 4 for the enterprises
interviewed.
0%
5%
10%
15%
20%
25%
30%
35%
40%
Significant
reduction
Limited
reduction
Specifics
carried over
Increase
in specifics
Reduction of the specific developments list
0%
10%
20%
30%
40%
50%
Effective SAP ERP
and / or
Netweaver
exploitation
Effective
SAP ERP
exploitation
Exploitation
planned
Exploitation
not planned
Strategic lever for the IS policy
Many enterprises simply and purely carry over their prior modifications without trying to
eliminate those that are not utilized or profit from the transfer possibilities to the SAP standard. Only
a few enterprises (18%) fully utilize the potential for reduction of modificatiosn brought about by the
version upgrade (30% reduction or more).
The enterprises that reduced their specific developments identified the obsolete and / or unutilized
modifications and have eliminated them. A majority of our interviewees are disappointed with the
lack of management support to return to SAP standard.
These upgrade versions having been recently realized, a number of the functional possibilities
will, no doubt, be taken advantage of later but, provided at least that one studies the possibilities
offered and is convinced of the contributions to businesses.
ADDEDVALUETOSTRATEGICPERSPECTIVES
42. THE SAP ERP VERSION UPGRADE PROJECT / page 41
theresultsobtained
Clearly, the functional and, indeed, strategic (NetWeaver) possibilities brought about by
the new version are still rather largely underestimated or, at least, little taken advantage
of for the time being.
• An insufficiency of information and understanding of the perspec-
tives offered by the new SAP ERP version.
• A rather restrained involvement from management (business and
IT) who express limited expectations in relation to the simple tech-
nical upgrade, no real search for optimum cost and value.
• But also, to qualify the above comments, the vision deficit may
also be attributed to the fact that the version upgrades conducted
are quite recent and some enterprises will, in time, use this as a
stepping stone for a more ambitious plan.
This deficit appears to have several causes:
Finally, the global score obtained for the Future Orientations Dashboard stands at 2,3 / 4, which
denotes a medium term prospective vision deficit of the version upgrade.
contribution to
businesses
2,3
reduction of
specifics
2,8
strategic
lever for
the IS policy
1,8
global
result
2,3
ADDEDVALUETOSTRATEGICPERSPECTIVESObservation n° 5 : The strategic possibilities of the new SAP ERP version, whether functional
or architectural, are hardly valued and put in perspective; should the enterprise stop there, it
would lead to an underutilization of this version’s potential and to a more limited return on
investment.
Hence, this observation:
43. page 42 / THE SAP ERP VERSION UPGRADE PROJECT
Operational
excellence
Contribution to
the enterprise’s
policy
User
Future orientations
Results of a version upgrade project
4
1
5
3
2
2,3
2,9
2,9 3,1
Recapitulating the results obtained in a BSC vision, we observe that the results level expressed
is globally satisfactory on the 3 “short term” dashboards (Operational Excellence, Users, Control
over costs), but that there is clearly a deficit in strategic vision of the version upgrade: the
strategic (and also economic at medium term – value creation) potentiality of the version
upgrade is not correctly taken into account.
THE KEY INDICATORS OF A VERSION UPGRADE
theresultsobtained
SUMMARY
commentsindicator average value
• Includes the analysis phases, technical migration,
tests, 1 to 2 dummy migrations and the
implementation to production.
• More than 60% of the enterprises have migrated
in around 6 months.
• The IT divisions arrange for switchovers to
coincide with the prolonged May weekends.
average duration
of a project
migration period
7.1 months
between September
and May
We have requested the enterprises to provide us with the values attached to a number of key
indicators of their version upgrade. Only some enterprises were able to provide us with an estimation
of these indicators and the values given below are accordingly purely intuitive?. In the second phase
of our study (October 2008), we will attempt to refine the estimation of these indicators.
44. THE SAP ERP VERSION UPGRADE PROJECT / page 43
theresultsobtained
THEKEYINDICATORSOFAVERSIONUPGRADE
commentsindicator average value
• Only 14% of the enterprises utilize tools for the
non-regression and performance tests.
• 10% of the enterprises managed the project only
with internal resources.
• The external services are essentially the
management of the SAP middleware and of
the DBMS, the installation of the environments
and technical migration works of the SAP
version, the eventual migration of the DBMS
and the replacement of the operating system,
and particularly the updating of specific
developments.
• As an example, budget of EUR350K for a Middle
Market enterprise with a R/3 core limited to a few
modules, not many users, not many specifics to
maintain, implementation of Unicode.
• Another example: EUR1000K if the project
profile proves to be complex: R/3 migrated with
another SAP system (BI or CRM), numerous
interfaces ( complex mapping, and SAP partner
applications to be migrated in parallel), a non
negligible number of specifics to carry over,
an updating of the technical platform which is
accompanied by the implementation of new
standard SAP functionalities, replacement of a
number of the IS components, etc.
work load
budget
50 to 65%
dedicated
to tests
Variable,
depending on SAP
lanscape
• The duration varies strongly, depending on
the enterprise, between 0 to 5 months. Some
enterprises have proceeded to a “categoric”
freeze from Day 1 of the project.
average duration
of the freeze on
enhancements
average duration of
the freeze in % of
the project
duration
2.5 months
around 40%
45. page 44 / THE SAP ERP VERSION UPGRADE PROJECT
THE MAIN RISKS OF A SAP ERP VERSION UPGRADE PROJECT
Risks linked to the conduct and monitoring of the project
Risks linked to the availability of technical competences
• Difficulties in coordinating the functional and technical
work groups (R7 risk): projects with predominantly technical
characteristics are not likely to mobilize key users in charge of
tests. It is recommended to organize a launching meeting in the
presence of the key project players and to present the project
phases, the sequencing of the development activities and tests
from a business process approach.
• Incomplete tests (R8 risk): the project impacts the SAP system as
a whole and the testing scope is an extended one. It includes the
unit tests realized by the developers after adaptation of the SAP
objects, the non regression tests (CC SAP consultants and key
users), integration and operations tests as well as performance
tests. It is appropriate, in preparation phase, to define the testing
scope and evaluate the associated work load. The operations and
performance tests must not be neglected. It is recommended
to use the last functional test plan again and enrich it with the
appropriate new test plans.
• Difficulty to find skilled external resourcest (R1 risk): several
enterprises were dissatisfied with the lack of competence of the
service providers’ teams (BC profiles) and about project managers
who do not always have the required experience, not to mention
resources who do not finish the project. It is appropriate to draw
the matrix of the project key competences at the project definition
level and to proceed to a call for interested external parties to bid
for offering their services (SAP ERP migration project experience
with their CV) It is then necessary to ensure that service providers
offer a continuous service during the life of the project (contractual
clause).
We have identified the key success factors of a SAP ERP version upgrade project and have linked
to those factors the main risks which the enterprises had to face.
Risks linked with the availability of business resources
• Lack of motivation and involvement from key users (R2 risk): the
projects lack business stakeholders and it is hence difficult to
mobilizetheProjectSponsorswhichdonotseethedirectusefulness.
It is appropriate to involve the Project Sponsors at the project
risk factors and best practices
46. THE SAP ERP VERSION UPGRADE PROJECT / page 45
riskfactorsandbestpractices
THEMAINRISKSOFASAPERPVERSIONUPGRADEPROJECT
Risks linked to the objectives and scope of the project
• Project which does not appear to bring any real contribution to
the business (R3 risk): the project is often “transparent” for the
users who are satisfied with no disruption to their day to day
activities. On the other hand, the slightest deterioration in service
will affect the image of IT Division.It is recommended to put in
place a progressive freeze on enhancements process (avoid the
“sudden” freeze), limit the downtime period (during switchover)
and put forward the list of functional improvements, even minor
ones, induced by the version upgrade (example: better integration
between SAP and Microsoft Office Suite, etc.).
• Carry over of a too large number of specific developments (R5
risk) : the version upgrade project is not compatible with the desire
to return to the SAP standard. Most modifications are carried over
and this does not support the upgraded SAP system in being more
flexible.It is desirable to establish a governance processs from the
initial project phase and to get the business line managements to
adhere to a Core Model policy and return to the SAP standard.
• Lack of training / creation of awareness of the internal teams to
the SAP ERP version the SAP ERP version (R6 risk) results in a lack
of vision of the enterprise on the post migration opportunities,
an absence of planning and a difficult task for the enterprise
to supervise the service providers’ works. It is necessary to
internally identify the project key stakeholders (managers, SAP
CC consultants, key users, developers, architects, …) and to
provide the adequate training (delta modules, SAP awareness
sessions,…).
definition phase and identify the SAP ERP business advantages. It
is subsequently appropriate to build a communication plan which
satisfies and convinces the key users of the legitimacy of the project
and insists on their key role within the functional task team.
47. page 46 / THE SAP ERP VERSION UPGRADE PROJECT
riskfactorsandbestpractices
Risks linked to the tooling and best practices of project management
• Incorrect sizing of the SAP system architecture components (R9
risk): Sizing assessments studies of the targeted SAP system
components (development line or production system) must be
rigorously conducted. Servers, processors, disks and memory must
be sized in accordance with the SAP recommendations (charts)
and thereafter, proceed with performance tests by using market
tools (response time, increase in load).
• Incorrect estimation of the load linked to tests (R4 risk): the testing
load is largely linked to specific developments that need to be
carried over or modified. It is recommended to utilize market tools
which allow an evaluation of the load linked to testing:
- identification of specific developments that need to be
carried over (utilized and with high business criticality),
- evaluation of the workload linked to the adaptation of
specifics that are carried over (realisation and unit tests),
- evaluation of the tests load (functional tests).
We have positioned the main risks put forward by the enterprises in the risk matrix according to
their occurrence probability (P) and their gravity (G). The (P x G) product gives us the criticality
level of the risk (gross risk).
fatalmajorminor
• Difficulty to find service
providers with the right
SAP competences (R1)
• Lack of motivation and
involvement of key users (R2)
• Incorrect estimation of the
Testing tasks workload (R4)
• Carrying over of a too
large number of custom
developments (R5)
• Lack of formation / awareness
of the MOE / MOA teams on
SAP ERP (R6)
• Incomplete tests (R8).
• Incorrect sizing of SAP SI
architecture components
(servers, disks, memory,
rocessors) (R9).
• Project without contribution
for the business (R3)
(project “transparent”
for the users)
• Difficulty to well coordinate
the functional and technical
task groups (R7)
unlikelyfairlyprobableveryprobable
THEMAINRISKSOFASAPERPVERSIONUPGRADEPROJECT
48. THE SAP ERP VERSION UPGRADE PROJECT / page 47
RECOMMENDATIONS AND BEST PRACTICES
riskfactorsandbestpractices
Apply SAP system good Governance principles
Management of resources and partnership competences
1• Involve General Managementand business managements at
project launching phase (R3) and (R2).
2• Identify the specific developments which will not be carried over
(obsolete or with a low level of business criticality) (R5).
3• Review processes so as to carry over a minimum number of
specific developments and make maximum exploitation of the
SAP standard (R5).
4• Proceed to a permanent SAP technological watch (maintain the
maturity level on the internal teams’ tool – key users and SAP CC
resources) (R6).
1• Anticipate on the availability of the business resources and free
the key users from their daily work during the project (R1).
2• Choose the service providers according to their teams’ experience
(CV) (R1) and (R7).
3• Secure the continuity of the critical resources of the project
(contractual clauses with the service providers) (R1).
4• Carefully evaluate and monitor the equipment load during the
project and in start up phase (adjustments sometimes necessary)
(R9).
5• Sign a “Safeguarding” type contract with SAP which consists in
having a “Total Quality Manager” (project quality assurance and
better reactivity from SAP developers for problem solving).
• Management of resources and competences.
• Governance of the SAP system.
• Change management.
• Project monitoring.
We propose a classification of the recommendations put forward by the enterprises according
to 4 main themes:
The recommendations are classified, according to a decreasing importance order, taking into
account the frequency character of the recommendation as well as its operational character
(implementation) Regarding the recommendations which are risk preventive (or mitigation), we
mention the corresponding risk number.
49. page 48 / THE SAP ERP VERSION UPGRADE PROJECT
riskfactorsandbestpractices
Change Management - Communication
Best project management practices
1• Communicate to sell the project to the project owner and present
it as a first technical stage which opens the door to planned
business projects (R2).
2• Communicate regularly on the project progress with business
managements, the contact users in the work groups and the key
users (R2).
1• Ensure the scope of the tests is correctly evaluated and book
competent resources (the tests represent over 50% of the
project’s total workload) (R8).
2• Manage the project risk portfolio all along the project (R1 à
R9).
3• Cautiously evaluate the analysis and adaptation workload of the
specific developments to be carried over (R4).
4• Conduct several dummy migration (rehearsals) before the actual
switchover (R8).
5• Rigorously size the future SAP development and production
servers (apply at least the SAP recommendations in SAPS) (R9).
6• Provide for a RSV (regular service verification) which corresponds
to a definitive test as well as a guarantee period of 3 to 6
months.
7• Provide for a recovery plan.
8• Utilize tested upgrade methods recommended by SAP or by the
service providers (R7).
9• Utilize validation tools (tests automation, performance control)
(R8) et (R9).
5• Communicate regularly with business managements on the
enhancements scheduled by the editor and define a system
enhancement plan (R3) et (R2).
6• Be attentive to the users’ new requirements and identify the SAP
opportunities in the project definition phase (R2) et (R3).
7• Convert a technical version upgrade obligation into an IS impro-
vement opportunity (R3).
RECOMMENDATIONSANDBESTPRACTICES
50. THE SAP ERP VERSION UPGRADE PROJECT / page 49
STUDY OF TWO CONTRASTING SCENARIOS
riskfactorsandbestpractices
The favorable scenario which leads to the best results
The extended enterprise is a multi-country, multi-company and multi-site one. It has between
1000 to 5000 SAP users. Its various businesses are federated within a sole Core Model R/3 which
operates the main SAP back office modules (SD, MM, FI, CO, PS, HR, QM). The enterprise has rolled
out the SAP solution of Management of Client Relationships (SAP CRM) and its Management is
monitoring the activity, the results and the business performance process by using the SAP BI
solution (BW) The migration project includes the SAP R/3 4.7 core version and the SAP BW solution
3.1 version (migration in SAP BI 7.0).
The good Governance maturity level of the SAP system has allowed the enterprise to promote
a Core Model policy supported by General Management and relayed by the Business Process
Owners (BPO) who are the “temple guards”. Any enhancement request is first examined by a
BPO and the SAP CC (filtering of the request, feasibility study, proposition of a quantified solution
which is based on the SAP standard and/or a specific development, qualitative or quantitative
gains and criticality level for the business). It is subsequently supported by the BPO in “Solution
Board” (the Core Model governance instance) which decides on the appropriateness or not of the
request, depending on the Business Case initiative. The result is a controlled utilization of specific
developments (a total below 500 m/d) limited to critical business processes and with strong added
value.
The enterprise’s mapping application is controlled thanks to a sustained urbanization effort of
the IS. An initiative to streamline the IS operations has led the enterprise to limit the interfaces
between SAP and other ERPs, for the most part, SAP’s partner editors, which cover business related
processes (vertical solutions) or transverse processes (central applications).
The SAP CC is centralized. Its resources and mutualised competences (analysts, functional and
technical consultants, abapers) are mainly in charge of the adaptative and evolutive maintenance
of the SAP system: technological watch, receipt of enhancement requests from the BPOs, research
of the best SAP solutions in view of guaranteeing the evolution and deployment abilities of the
SAP Core Model, solution production and management of the Core Model documentation.
The hosting, the SAP administration, (SAP middleware and DBMS) and the systems operations
(servers, operating system, backups, availability,…) are externalized (global information manage-
ment contract). The IT DivisionIT Division, which manages the deployment of Core Model projects
in parallel, has been reinforced with external SAP consultants who conduct deployment tasks:
localization parameter setting (entities), management of user data, non regression tests,…
51. page 50 / THE SAP ERP VERSION UPGRADE PROJECT
riskfactorsandbestpractices
An internal project team (SAP CC and key users) is strongly mobilized on the project and represents
over 50% of the total m/d. It is assisted by the service providers in charge of the SAP technical
migration and of its DBMS as well as of the change of operating system.
The project consists of the implementation of the new SAP ERP platform, move to Unicode and
benefit from the functionalities of New General Ledger.
The enterprise applies the best practices of project management: definition study, splitting of
project in work groups and phases, management of project risks and exploitation of the experience
feedback of its 2 previous migration projects which have been the subject of project reports.
The enterprise has tooled the testing phase (automation of the non regression tests campaign and
performance tests by using market software products).
We note that the radar surface represented below is not well developed: the project is of a relati-
vely low complexity.
Profile of the version upgrade project (the best result)
5
4
1
5
3
3
3
3
3
2
2
2
Tooling level
Project management
best practices
Typology of
the release upgrade
Involvement of
the enterprise
in the release upgrade
SAP CC’s organization
model
Integration with non SAP systems Governance maturity
of custom developments
SAP R/3 release to migrate
Scope of the migrated
SAP IS
Number of SAP systems
migrated
Number of SAP systems
in production
Number of users
Organization
of
the enterprise
STUDYOFTWOCONTRASTINGSCENARIOS
52. THE SAP ERP VERSION UPGRADE PROJECT / page 51
riskfactorsandbestpractices
STUDYOFTWOCONTRASTINGSCENARIOS
The results obtained according to the 4 BSC dashboards
Operational Excellence Dashboard
User Dashboard
The project objectives have generally been achieved:
• The project planning has been adhered to.
• No compatibility / interoperability problem is observed because
the preparation phase has allowed identification of the work to be
done: adaptation of interfaces and need to proceed with version
upgrades of ERPs from the SAP partner editors. The automated
tests have allowed identification and rectification of anomalies
before launching production (exhaustivity of non regression
tests).
• No incident or problem faced at start up due to a controlled and
equipped tests task team.
• The users are satisfied with the project: no deterioration of service
level and the delivery of new functionalities was accompanied by
adequate training.
• The SAP system’s performance has slightly improved (users
perception).
• Delivery of new functionalities in the Accounting / Finance field
(financial monitoring by activity and site).
• Implementation of Unicode.
• Compliance alignment in the financial field (application of IFRS
norms to the Group entities).
• Availability of information which is more “real time”, notably in
the field of Business Intelligence (real time data communication
between the SAP ERP core and SAP BI).
• The freeze on enhancements has been progressive and, on the
whole, has remained below 2 months (which is less than 20% of
the total project duration).
• The project has not led to downtime for the users (SLA adhered to)
and the switchover took place over two days (weekend).
53. page 52 / THE SAP ERP VERSION UPGRADE PROJECT
riskfactorsandbestpractices
Results of the version upgrade project (the best result)
4
1
5
3
2
4 4
4
4
4
33
3
3
3
3 3
3
2
2
Reliable start up
Adherence to project budget
Freeze on developments
(in project duration %)
Contribution to business
Increase in technical
resources
Compatibility /
interoperability problems
User satisfaction IT Division global satisfaction
SAP Operations costs
Adherence to time line
Strategic lever
for policy
System downtime
Improvement
of performances
Reduction of the list
of custom developments
Project
objectives
achieved
Contribution to the Enterprise policy Dashboard
Future Orientations Dashboard
• The operations and maintenance costs remain unchanged and the
information management contract has not been subject to any
modification.
• The IT DivisionThe IT division is globally satisfied of the project
and notably of the quality of the tasks outsourced to the service
providers (competence of the teams, quality of the SAP system
elements delivered – guarantee period of 6 months).
• The project budget has been adhered to.
• Technical resources have increased by around 10% in anticipation
of the projects to come.
• Reduction of specifics limited (their number is reduced because
the enterprise applies a good Governance of specifics).
• The project is a lever for the IS policy: deployment of an optimized
SAP architecture with a simplified SAP system landscape, improve-
ments on the IS components which render it more flexible so as to
facilitate its deployment within new entities.
• Thecontributiontobusinessremainsnegligibleandtheprojectremains
above all a technical migration project which consists in deploying the
new SAP ERP platform, promissory of future innovations.
• The enterprise has placed emphasis on training and creating awa-
reness among its future project teams(consultants and managers
of SAP CC, BPO and some key users) so as to inspire innovation
and prepare the exploitation of SAP ERP’s opportunities.
STUDYOFTWOCONTRASTINGSCENARIOS
54. THE SAP ERP VERSION UPGRADE PROJECT / page 53
Tooling level
Project management
best practices
Typology of
the release upgrade
Involvement of
the enterprise
in the release upgrade
SAP CC’s organization
model
Integration with non SAP systems Governance maturity
of custom developments
SAP R/3 release to migrate
Scope of the migrated
SAP IS
Number of SAP systems
migrated
Number of SAP systems
in production
Number of users
Organization
of
the enterprise
Profile of the version upgrade project (the worst result)
5
44
4
4
4
4
1
5
5
5
3
22
2
riskfactorsandbestpractices
STUDYOFTWOCONTRASTINGSCENARIOS
The unfavourable scenario which leads to poor results
The enterprise’s organisation remains complex (multi-country, multi-company and multi site) and the
number of users is between 1000 and 5000 There are numerous Core Model SAP R/3 in production
because the initial Core Model (first SAP integration project), whose objective was to diffuse a unique
organisation model and standardized business processes, has deviated as deployments took place, for
lack of SAP system Governance. The upgrade version project consists in migrating the 4.5 version of one
of the Core Model R/3 (of one branch of the enterprise regrouping several subsidiaries and sites) as well
as the Client Relationships SAP CRM Management solution (migration from 4.0 to 5.0).
The absence of Core Model R/3 Governance (no BPO, a General Management hardly involved and no
instance for the validation of enhancement requests) has led to the proliferation of specifics (more than
3000 m/d) which are part of the migration project. For lack of urbanization, the application mapping
is complex: the SAP Core Model cohabits with a large number of local applications (local interfaces on
sites) and central (transverse solutions).
There are several SAP CCs dedicated by Core Model (with various geographic localizations). The
resources and competences are “verticalized” by business and/or a branch of the enterprise (absence
of mutualisation and little synergies). The SAP CC resources and the key users of the branch are hardly
mobilized on the project and the service providers’ share exceeds 60% of the project’s total m/d.
The version upgrade is mainly technical and is accompanied only by the implementation of Unicode. The
enterprise has not formalized, let alone, diffused project management best practices and the projects, as
well as the SAP solutions, suffer from a chronic lack of tooling, the whole situation being due to frequent
recourse to service providers and a lack of internal control on projects.
The radar surface is much more developed and reflects the high level of the project’s complexity which
the enterprise will have to face up to The level of results obtained is of “chamois skin” type.
55. page 54 / THE SAP ERP VERSION UPGRADE PROJECT
riskfactorsandbestpractices
The results obtained according to the 4 BSC dashboards
Operational Excellence Dashboard
• The limited project objectives are globally achieved.
• The time line has not been respected (production launch delayed
by 2 months – Testing tasks undervalued, notably due to the
number of specifics carried over).
• The IT Division The IT Division has to face an incompatibility issue
post switchover between SAP and a critical operating system.
• Start up reliability is evaluated as mildly satisfactory due to post
start up issues met (anomalies which were not detected and
rectified during the non regression tests and particularly the
operations tests which were breezingly done).
User Dashboard
• The users are globally satisfied of not having noticed anything.
• A slight deterioration in the SAP CRM performance which could
have been avoided if the performance tests had been conducted
with a market software.
• The SAP enhancement requests have been frozen during around
4 months (which is equivalent to around 50% of the project
duration).
• The project has led to 3 working days downtime (user service
unavailable from Friday morning to Tuesday night).
STUDYOFTWOCONTRASTINGSCENARIOS
56. THE SAP ERP VERSION UPGRADE PROJECT / page 55
riskfactorsandbestpractices
STUDYOFTWOCONTRASTINGSCENARIOS
Reliable start up
Adherence to project budget
Freeze on developments
(in project duration %)
Contribution to business
Increase in technical
resources
Compatibility /
interoperability problems
User satisfaction IT Division global satisfaction
SAP Operations costs
Adherence to time line
Strategic lever
for policy
System downtime
Improvement
of performances
Reduction of the list
of custom developments
Project
objectives
achieved
Results of the version upgrade project (the worst result)
4
1
5
3
2
1
1
1
1
1
3
3
3
2
2
2
222
1
Contribution to the Enterprise policy Dashboard
Future Orientations Dashboard
• No increase in operations and maintenance costs of the SAP system.
• The IT Division is mildly satisfied because the task of carrying over
specifics has not been controlled by the service provider and its
budget has trebled (nearly 70% of the total cost of the project).
• Technical resources have increased by 30% (impact of Unicode
observed on the size of the DBMS).
• The list of specifics has been carried over as is, which reflects an
absence of will to return to the SAP standard and a lack of vision
in terms of flexibility and agility of the SAP system with regard to
the enterprise’s future trajectories.
• The project is not a lever for the IS policy: no improvement brought
to the SAP system’s architecture and no exploitation of this SAP
version upgrade planned for the months to come.
• Contribution to business remains unchanged (no new functionality
delivered to the SAP users).
57. page 56 / THE SAP ERP VERSION UPGRADE PROJECT
Delimitation of project (phase 1)
The call for interested external parties to bid for offering their
services is optional (phase 2)
The migration project
Delimitation of project (Phase 1) it allows to define the scope of the
version upgrade project and to build the deployment plan of the
SAP ERP opportunities (scope of the initial migration project and the
subdivision of value creating business sub projects).
The call for interested external parties to bid for offering their
services is optional depending on its sourcing policy and its decided
involvement level in the delimitation phase, the enterprise may or
may not be led to solicit service providers in various fields (SAP
technical migration, DBMS migration, middleware and DBMS
administration, implementation of SAP modules,…).
The migration project which we will develop below, at ISO functionalities,
is rolled out from the preparation phase until the implementation phase
with the start up and the support (phases 2.2 to 6).
THE PHASES OF A SAP ERP IMPLEMENTATION PROJECT
phase 1 phase 2.2 phase 3 phase 4
phase 2.1
phase 5 phase 6
delimitation
of project preparation
realization
tests
integration
validation
call
offering
final
preparation
start up
support
n n n Project phases
recommendations for the organisation of
a version upgrade project
58. THE SAP ERP VERSION UPGRADE PROJECT / page 57
recommendationsfortheorganisationofaversionupgradeproject
SPLITTING THE PROJECT IN WORK GROUPS
The splitting of the project in work groups is a classic move. It is recommended that one responsible
person should be appointed per task team and a global coordinator (often the Project Manager)
who will be responsible to ensure that there is a good synchronization between the various work
groups so that the tests can start at the earliest possible date.
n n n The work groups of the SAP ERP version upgrade project
phase 1 phase 2.2 phase 3 phase 4 phase 5 phase 6
delimitation
of project preparation
realization
tests
integration
validation
final
preparation
start up
support
project management, quality management, communication
environment systems
system administration
SAP – Technical migration – OS SGBD
functional (customizing, non regression tests, validation)
development integration
safty - autorisation
change management (training…)
Note 1
For the enterprises that have not yet gone through the management
experience of accreditations organized in “roles”, this subject will be
a task on its own within the context of a version upgrade. This point
will be discussed in further depth in the White Paper second edition,
as well as the other elements which are identified as exercising an
impact in relation to this first White Paper edition.
59. page 58 / THE SAP ERP VERSION UPGRADE PROJECT
recommendationsfortheorganisationofaversionupgradeproject
Note 2
Depending on the maturity level of the SAP technical architecture,
the “Environment Systems” task is a critical project factor and
it must be well anticipated. Note that the passage to 64 bits is
recommended as it will be mandatory for the next SAP version
(budget permitting, might as well anticipate the future migration).
KEY POINTS FOR EACH PROJECT STAGE
Preparation
• Make an inventory of the SAP system documentation (notably, the
blueprint, the list of developments, the documentation for each
specific with details of the SAP objects modified, the test plans,
the scenarios and existing test plans).
• List the specifics to be carried over (as per business criticality) and
those to be eliminated (obsolete, not utilized, or which will be
replaced by the standard SAP ERP).
• Communicate on the project objectives.
• Freeze the ongoing developments and projects.
the migration SAP project
(phase 2.2 à 6)
phase 1 phase 2.2 phase 3 phase 4
phase 2.1
phase 5 phase 6
delimitation
of project preparation
realization
tests
integration
validation
call
offering
final
preparation
start up
support
n n n Migration project phases
SPLITTINGTHEPROJECTINWORKGROUPS
60. THE SAP ERP VERSION UPGRADE PROJECT / page 59
recommendationsfortheorganisationofaversionupgradeproject
KEYPOINTSFOREACHPROJECTSTAGE
Realisation and tests
• Not to underestimate the numerous treatments and adaptations
to be performed:
- Treatment of all the specifics and, accordingly of all the
associated objects (tables, programs,…) which are present in
the SPDD and SPAU transactions.
- Updating of the ABAP syntax in the programs if the latter
has evolved.
- Unicode migration of specific programs (for multilingual
enterprises).
- Other treatments to be performed, linked to SAP evolutions
(new organisations of tables such as TVARVC, new parameters
in the module functions, …).
- SAP standard modification to be redone if the program has
strongly been modified in SAP ERP version in relation to the
existing R/3 version.
• At least, pass the developments in “Unicode compatible” version,
in anticipation of the next version, even if there is no immediate
migration of the base to Unicode (provide for a corresponding
workload which should not be underestimated).
• The environment must be operational before the arrival of the
functional groups in charge of the validation (during this phase,
the unit tests and the non regression tests are performed by the
SAP CC consultants who communicate with the developers in
charge of the necessary adaptations and treatments on the SAP
objects).
• Starting with the business scenarios to formulate them first in unit
tests ensures the respect of the business imperatives and facilitates
the transition to non regression tests and to the functional
validation.
• Get the SAP Quality Manager to intervene if necessary to accele-
rate the treatment of the OSS notes.
• Automate the non regression tests when there is an extended
scope and several entities are involved.
61. page 60 / THE SAP ERP VERSION UPGRADE PROJECT
recommendationsfortheorganisationofaversionupgradeproject
Integration and validation
Final preparation
Start up and support
• Optimize the testing documentation (enrichment of the previous
phase test plans).
• Involve and accompany the functional team (key users) and
identify within the project ownership a responsible person for the
validation task team.
• Do not get the functional team in charge of functional validation
to intervene as long as the priority developments are not up to
date.
• Identify the Go/no Go criteria for the switchover.
• Validate the recovery plan (fallback).
• Mobilize the onsite contacts in charge of level 1 support (if the
functional enhancements are important).
• Trigger the level 1 support by key users (contacts).
• Make the training / awareness documentation available on line.
• Hierarchise the residual anomalies.
KEYPOINTSFOREACHPROJECTSTAGE
62. THE SAP ERP VERSION UPGRADE PROJECT / page 61
• Avoiding the R/3 surcharge maintenance costs.
• Move to Unicode.
• Adhere to international reglementation.
• Prepare the deployment of the organisation model within new enti-
ties, in the best of cases.
• Simplify the system landscape, mutualize and modify some
SAP components for savings purposes (servers, databases, OS,
combination of different more or less greedy processors dedicated to
business transactions or to operations activities, …).
• Centralization of SAP administration (monitoring, alerts, management
of level 4 tickets with Walldorf) with the implementation of Solution
Manager scenarios (often with the information management
services).
• Specific developments, unfortunately too often carried over.
• Mapping applications which remain complex, due to interfaces
maintained and a lack of will to better exploit the SAP potential
The SAP ERP migration project is well tuned, facilitated by a stable version since more than
18 months and the ISO functional character. Its complexity is mainly linked to the number of custom
developments, of interfaces and components impacted by the modernization of SAP’s platform.
Nevertheless, whilst it is predominantly technical, it still consummates functional resources, the
tests being a major task that falls under the client’s responsibility.
The project with ISO functionality is transparent to the user since the 4.6 version, a situation which
does not facilitate the mobilization of functional resources who don’t feel concerned by a project
which is not bringing them anything. Still on the subject of ISO functionality, no particular action
in change management or training is necessary.
The projects consist mainly in the modernization of SAP’s technical platform. They are based
on objectives and stakes which remain limited and contribute too modestly to the IS good
Governance:
These projects are realized in a short term optic, they are launched without real project definition
thinking and thus do not find their place within a strategic plan of profitable expoitation of
opportunities. They contribute little to improving the flexibility of the IS and its capacity to
synchronize itself on the governance trajectory and the general direction of the enterprise.
In this sense, we can for example cite:
conclusion
OBSERVATIONS
