Successfully Managing S4HANA Projects

Prévia do material em texto

Successfully 
Managing S/4HANA 
Projects
Denise Banks-Grasedyck
Eckhard Lippke · Hans Oelfin
Reinhold Schwaiger · Volker Seemann
The Definitive Guide to the Next Digital 
Transformation
Management for Professionals
Management for Professionals
The Springer series Management for Professionals comprises high-level business
and management books for executives. The authors are experienced business
professionals and renowned professors who combine scientific background, best
practice, and entrepreneurial vision to provide powerful insights into how to achieve
business excellence.
More information about this series at http://www.springer.com/series/10101
http://www.springer.com/series/10101
Denise Banks-Grasedyck • Eckhard Lippke •
Hans Oelfin • Reinhold Schwaiger •
Volker Seemann
Successfully Managing
S/4HANA Projects
The Definitive Guide to the Next Digital
Transformation
Denise Banks-Grasedyck
Berlin, Germany
Eckhard Lippke
Leimen, Germany
Hans Oelfin
Waldenbuch, Germany
Reinhold Schwaiger
Sehnde, Germany
Volker Seemann
Werder (Havel), Germany
ISSN 2192-8096 ISSN 2192-810X (electronic)
Management for Professionals
ISBN 978-3-030-86083-7 ISBN 978-3-030-86084-4 (eBook)
https://doi.org/10.1007/978-3-030-86084-4
Translation from the German language edition: SAP-S/HANA-Projekte erfolgreich managen by Reinhold
Schwaiger, et al., # Rheinwerk-Verlag GmbH 2020. Published by Rheinwerk-Verlag. All Rights
Reserved.
# The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland
AG 2022
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether
the whole or part of the material is concerned, specifically the rights of reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or
dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or
the editors give a warranty, expressed or implied, with respect to the material contained herein or for any
errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.
This Springer imprint is published by the registered company Springer Nature Switzerland AG.
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
https://doi.org/10.1007/978-3-030-86084-4
Preface
Before we take you into the depths of SAP project management and tell you about
what you can expect in SAP (S/4HANA) projects, we’ll briefly explain how this book
is structured and how to get the most out of it. To give you the big picture, there is
also a short overview of SAP’s history.
When we wrote the first edition of this book in 2015/2016, we had really only
wanted to write an article about SAP projects—but then we simply had too much fun
writing to stop there. Too many aspects that are essential for the success of a large
SAP project had to remain unmentioned in an article. That is why we went ahead and
wrote an entire book about it.
Technological Change
Since then the world has changed enormously. Technological progress in the last
decade has led to drastic upheavals: companies are increasing their productivity
through more and more automation, which means that the need for human labour is
dwindling. Cloud providers such as Facebook, Uber, Workday, Airbnb and many
others have created platforms that are fundamentally changing the way we live,
work, travel and communicate with others. AI (artificial intelligence) applications
have become a natural part of our everyday life (do you still “google” or do you ask
Siri or Alexa?). Billions of people carry small computers (smartphones) with them,
each of which has more computing power than the supercomputers used to send the
first humans to the moon in 1969—and they can even be used to make phone calls.
These rapid developments raise many social questions, but this book is mainly
about how you as a project manager can contribute to your company’s success in this
global competition of the best ideas, the best services, the best products and the most
capable providers through modern and efficient IT. Historically, a company’s IT was
often seen as a cost factor, but it can now become and important “enabler”, allowing
companies to offer new services, business areas and customers.
v
How Can Your Company Compete in a Global, Digital World?
The world has become a different place, but the companies using SAP software and
SAP itself have also changed massively, so that a fundamentally revised edition of
our book seemed to be called for. Many companies have been using SAP software
successfully for years and are now facing a new challenge, the switch from the
classic SAP Business Suite to SAP S/4HANA—the new SAP flagship and core
product. The question arises whether it is better to wait or tackle this task now?
Besides the core SAP products, SAP’s cloud offerings must also be evaluated:
starting with the SAP HANA Enterprise Cloud on to the integration platform SAP
Cloud Platform as well as SAP Cloud for Customer and SAP Analytics Cloud.
Technologies such as machine learning, speech recognition, robotic process auto-
mation, blockchain , etc. promise completely new possibilities to stand out from the
competition and win new customers and business areas. Today, no company can
afford to ignore these developments without jeopardising its own competitiveness
and thus its own future. SAP has many interesting products on offer, but it is safe to
assume that you will only reap the greatest benefit if you use them together with SAP
S/4HANA.
SAP’s Biggest Bet and Business Transformation
SAP S/4HANA is not only the latest ERP Business Suite from SAP, but the new core
of SAP’s strategy, SAP’s biggest and most important bet on the company’s future.
Although SAP strives to make the migration to SAP S/4HANA as easy as possible, a
closer look reveals: introducing SAP S/4HANA needs to be accompanied—if it is to
pay off—by a fundamental corporate transformation.
• ERP in the Cloud
SAP has been the market leader for years for business-critical systems and data in
on-premise ERP systems. Customers should now feel encouraged to migrate
business-critical data and processes to the cloud (provided by SAP). SAP S/
4HANA Cloud, Essential Edition or Extended Edition is SAP’s offering for these
companies.
Behind this is a new ERP philosophy: a standardised ERP system as the heart
of the company, surrounded by additional, specialised SAP cloud solutions and
supplemented by customer-specific extensions in PaaS or on-premise SAP
applications.
• O-Data and X-Data
SAP S/4HANA makes it possible to combine operational data (O-Data) with
experience data (X-Data), i.e. classic company reports with real-time evaluations
of customer preferences and customer satisfaction. This enables companies to
react very quickly and flexibly to changing customer requirements.
• Artificial Intelligence, Robotic Process Automation, Machine Learning
vi Preface
SAP S/4HANA opens up the possibility for companies to make future topics such
as artificial intelligence (AI), robotic process automation (RPA), machine
learning (ML), etc. a reality as part of the Fourth Industrial Revolution and to
benefit from them.
These massive changes that many companies are facing in the coming years have
the potential to become as painful, revolutionary,time-consuming and costly as the
first company-wide introduction of SAP ERP software was many years ago—or not,
if approached correctly: carefully weighing up opportunities and risks and avoiding
common project management errors. In this book, we want to show you how to
do this.
And what about SAP? SAP has evolved from a somewhat conservative but solid
“German” provider of integrated enterprise resource planning software in the 1990s
and early 2000s to a global software manufacturer, cloud provider and service
provider. Today, Germany remains an important but by no means the most important
sales market for SAP products and solutions. SAP has changed at such a pace that
some customers are rubbing their eyes and fear they are losing touch. In 2015, when
the first version of this book was published, SAP had approximately 66,000
employees—today, five years later, due to organic growth and numerous
acquisitions and takeovers, this number has risen to more than 100,000.
SAP: From SAP R/3 to Full-Service Cloud Provider in 30 Years
In the 1990s, the product range consisted mainly of the core product SAP R/3 and
was initially expanded in the early 2000s with logical developments for customer
management (SAP Customer Relationship Management, SAP CRM), reporting
(SAP Business Warehouse, SAP BW, formerly SAP BI—SAP Business Intelli-
gence), supplier management (SAP Supplier Relationship Management, SAP
SRM), supply chain management (SAP Supply Chain Management, SAP SCM),
etc. In 2008, a reorientation towards cloud software and service offerings began,
resulting in an enormous broadening of the product portfolio (see also Fig. 1).
The next step was to move away from being a pure software manufacturer to
becoming a provider of cloud solutions and IT services for infrastructure and
software management. Licence sales are still important, but with almost 70% of
sales, SAP today earns its money primarily from “recurring revenues”, i.e. long-term
customer contracts with regularly recurring payments, as is customary with cloud
offerings, for example.
What is certain is that SAP as a company has undergone major changes and has
also realigned its focus. This is also reflected, for example, in the company motto,
which in 2013 was still “The Best-Run Businesses Run SAP” and in 2016 was
changed to “The Cloud Company powered by SAP HANA”. Meanwhile, (since
2019)—admittedly a little less catchy—it is: “The Experience Company powered by
the Intelligent Enterprise”. Keywords of technological development are taken up
here and point the way into the future of the company.
Preface vii
A look at the sales figures (Annual Report 2019) also shows the changes that SAP
has undergone in recent years: cloud revenues are growing by almost 40% compared
to the previous year and reach approximately €7 billion, while revenues from classic
software licences are at approximately €4.5 billion in the same period, which is a
slight decline.
Conclusion: Over the last decade, SAP changed dramatically. You could also say
that SAP has reinvented itself as a company and offers its customers the opportunity
to keep up with these changes and benefit from them.
Berlin, Germany Denise Banks-Grasedyck
Leimen, Germany Eckhard Lippke
Waldenbuch, Germany Hans Oelfin
Sehnde, Germany Reinhold Schwaiger
Werder (Havel), Germany Volker Seemann
Infrastructure On-premise or 
Partner Data Center
SAP Data 
Center
Hyperscaler 
Azure – AWS – GCP
Technology
Business Technology Platform
Analytics
Database 
Data Management
Development
Integration
Artificial 
Intelligence
Applications Intelligent Suite
S/4HANA
Industry CloudCross-Industry SaaS Clouds
Experience Mgmt
(Qualtrics)
Sustainability 
Mgmt
Business Process Intelligence (cross functional)
Business
Processes
Business N
etw
orks
Fig. 1 Overview of the SAP product strategy
viii Preface
Acknowledgement
Writing a book is also a project: with ups and downs and many challenges, which we
also know from our SAP projects. Fortunately, this book project was not quite as
complex as a large SAP project. Nevertheless, we too worked as an international
team at different locations: with three Germans, one Austrian and one American.
Yes, we also had to give room to the different cultural attitudes and overcome the
linguistic challenges that result from a mixture of German, English, Austrian and
Swabian dialects. But we strictly followed the experience-based advice,
recommendations and also warnings that you will find in this book. And behold,
we completed the project on time, without exceeding the budget, without a case of
burnout and hopefully with lasting success!
At this point we would also like to mention that we had a lot of fun writing and
thank the many people who supported us in many different ways. We would also like
to thank Springer, our editor Ms Bethke and the various project managers and project
members who gave us interviews to tell us about their experiences in a wide variety
of SAP projects. We would also like to thank the colleagues with whom we have
worked on many projects over the years. And last but not least, we would like to
thank our families, friends and also you. Without the former, we would not have had
the time and leisure for such a project, and without “you” we would have no reason
to write the book.
ix
About This Book
Before we dive headlong into the world of SAP projects, we would like to answer the
following questions: Who is this book written for? What is special about it? Which
chapters are there, and what is the best way to read the book?
What Is the Definition of an SAP Project?
We write a lot about SAP projects in this book—about what makes SAP projects so
special and what makes them different from “normal” IT projects.
The “Typical” SAP Project Does Not Exist
But what do we mean when we talk about an SAP project? After all, there is no such
thing as a typical SAP project; instead, you will find SAP projects in all colours and
shapes. Are you planning to introduce SAP software for the first time? Are you
flirting with SAP S/4HANA or one (or more) SAP cloud offerings? Or are you
already a long-standing SAP customer, planning improvements and optimisations of
your existing SAP landscape? Do you still run your SAP ERP software on-premise
and plan to use cloud services, or have you already arrived in the cloud and even
gained experience with hybrid system landscapes?
Or are commercial aspects your motivation? SAP is intensively promoting the
switch from classic licence agreements with associated support contracts to sub-
scription agreements. Instead of a one-off licence fee, you pay a (usually) monthly
“software rent” (in a kind of subscription). This is a very interesting offer, as it allows
customers to convert capital expenditure (CapEx for short) into operating
expenditures (OpEx), which often results in significant cost savings. However, this
is only possible in conjunction with an SAP HANA enterprise cloud contract,
i.e. your SAP landscapes are operated for you by SAP in its own data centres or at
one of the three major hyper scalers (Google Cloud Services, Amazon Web Services
and Microsoft Azure).
Depending on your answer, you will be faced with many different questions. A
key criterion for the preparation and implementation, but also for the probability of
xi
success of your SAP project, is the size of the transformation. The risk increases
exponentially with the transformation size. A great many medium-sized and even
more multinational companies took the first major hurdle back in the 1990s or 2000s
and mapped a large part of their business processes in SAP software. SAP ERP is
widely used in German-speaking countries as well as internationally. (SAP is the
undisputed world market leader for business software with a market share of more
than 22%.) Companies using SAP ERP are now facing new challenges: On the one
hand, the complexity of the SAP product range has increased considerably, not least
due to the acquisition of Business Objects,Sybase, SuccessFactors, Ariba and
Fieldglass (to name but a few). On the other hand, SAP’s move away from database
agnosticism by focusing on SAP HANA and the integration of more and more cloud
technologies poses new challenges for IT departments.
In this book, we do not go into detail about the special features of individual SAP
products or components. Nor are the differences between the individual SAP
releases relevant to what we want to describe here. However, the complexity of
SAP ERP solutions has increased 50-fold in the last 29 years (since the release of
SAP R/3). And we ‘will mention complexity even more frequently on the following
pages.
Complex Transformations
All projects in our combined more than 100-year career, in which we have
accompanied or managed SAP projects, have in common that they are complex
transformations. But then what is the lowest common denominator in an SAP
project, as we understand it? In most SAP projects, the core element is the SAP
Business Suite powered by SAP HANA and the Intelligent Suite SAP S/4HANA.
Frequently, other on-premise or cloud solutions play a role. The following applies to
all these projects:
• They are in fact very complex.
• SAP S/4HANA is the functional linchpin, but often other SAP applications are
also involved.
• They have points of contact with non-SAP applications and often non-SAP
integration platforms.
• They very often consist of distributed or hybrid system landscapes.
• The changes these transformations bring about, affect large parts of the company.
In this book, we assume that you will also carry out an SAP project that has these
characteristics. We will not, or only very rarely, discuss release-specific features in
the project. This means that you can use this book within the framework of current
and future SAP projects and regardless of whether your project is a “greenfield”
project that produces the first SAP application in your company or whether you are
carrying out an upgrade or optimisation project.
xii About This Book
Who Is This Book’s Target Audience?
We are delighted that you have chosen this book, because we have written it just for
you. By “you” we mean people who, for a variety of reasons and in a wide range of
roles, want to (or perhaps “have to”) deal with the implementation of SAP projects.
No matter what your motivation is for your interest in the successful implementation
of SAP projects, we are sure that you will find something in this book that will help
you to accompany and complete your current or even future SAP project with more
success and less stress.
Core Target Groups
This book is primarily aimed at project and sub-project managers in companies that
are facing an SAP project (or are already involved in one), SAP consultants, project
staff and managers and decision-makers. You can use this book in many ways: for
new project members, it is a guide describing the individual project phases and
activities. You will learn what to expect in the individual project phases and gain
valuable insights into the everyday life of a project manager. You will learn how to
offer support and contribute ideas beyond your role in the project, thus proving
yourself a particularly valuable team member.
For prospective or new project managers, this book is a manual with important
tips on pitfalls and critical success factors. Project management is to a large extent a
“craft”, i.e. there are good practices that can significantly increase the probability of
project success. You will get to know courses of action that start where the usual
project management training courses end. We will take you “into the trenches”,
where project management practice is often more than just a little different from
theory. As a project manager, you can thus rely on proven experience from your first
assignment in your new role and systematically steer your project towards success.
For experienced project managers, this book is a reference book, and for strategic
decision-makers and other stakeholders who want to contribute to the success of a
project by making better decisions, this book is a guide. You can read the whole
book or consult it on specific issues.
How Is This Book Structured?
In this book, you will find nine additional chapters, the contents and objectives of
which we would like to summarise briefly below:
The (Not So) Subtle Difference
Chapter 2, “What Makes an SAP Project So Different?”, highlights the special
features of SAP S/4HANA projects. It shows what distinguishes an SAP S/4HANA
About This Book xiii
project from classic IT projects and what the objectives of an SAP S/4HANA
project are.
From the Ideal Project. . . ..
Chapter 3, “The SAP S/4HANA Project: How It Should Be”, describes the conditions
that must be met for SAP S/4HANA projects to be successful. To this end, the
“Activate method”—the implementation method developed and recommended by
SAP—is briefly introduced and a description is given of why its use makes sense.
Using the individual phases and tools of this method, we present our ideal project to
you. We introduce the individual phases, Discover, Prepare, Explore, Realise, Deploy
and Run. In this chapter, everything runs like clockwork—without financing gaps,
disputes with the specialist departments about resources and other problems.
. . . ..to Project Reality
Chapter 4, “The SAP S/4HANA Project: How It Is’s really like”, presents the main
pitfalls in SAP S/4HANA projects. Here, too, we follow the SAP Activate Roadmap
and show which failures and setbacks are typical for the individual project phases—
from planning to go live and support.
Soft Skills as a Success Factor
In Chap. 5, “The Underestimated Success Factor: People”, everything revolves
around the most important resource in the project. We show which qualities and
knowledge project managers and project teams need to have in order to work
successfully. You will learn what difficulties can arise here and how you can
recognise early on, for example, signs of excessive demands on your project team.
In interviews with project members, we have evaluated which support the
participants would like to receive and which success factors were particularly
valuable in their projects.
Project Planning, Control and Quality Assurance
Chapter 6, “Project Planning, Control and Quality Assurance”, deals with the
activities in the project that require a particularly well-structured approach, project
discipline and realism. In this chapter, we show you what you should pay particular
attention to without taking you too much into the theoretical world of methods,
because it is ultimately the success in practice that counts.
xiv About This Book
From Theory to Practice in the Project
Chapter 7, “Examples from Real-Life SAP S/4HANA Projects”, describes the
implementation of an SAP S/4HANA project using various sample companies.
You will gain valuable insights into how the implementation was successful in
practice and what difficulties and challenges were involved. Last but not least, we
have compiled some “lessons learned” from our projects with worldwide rollout,
which can serve as a basis for future projects.
Outside Assistance
Chapter 8, “Consultants: Boon or Bane? Benefit or Burden?”, is dedicated to the
external supporters of our SAP-S/4HANA project. Here you can find out which roles
you may want to assign to external consultants and where they might not be your
best choice. You will also find tips on how to find the right partners and what to look
out for when filling positions. In addition, there are some reflections on offshore or
nearshore teams.
The Toolbox for Your SAP S/4HANA Project
Chapter 9, “Project Support Tools”, describes some important tools for supporting
SAP S/4HANA projects. We do not primarily focus on the completeness or topical-
ity of the tools. Rather, we aim to present the tools that are (or had to be) used most
frequently in our projects.
12 Commandments for SAP S/4HANA Projects
Chapter 10, “12 Commandments fora Successful SAP Project”, without whose
observance any SAP S/4HANA project is inevitably doomed to failure, is made
available at the end of the book.
In the appendix, you will find a glossary explaining the most important terms we
use in this book. The bibliography will give you ideas for further reading.
Our Approach
Project management books are a dime a dozen, including some on SAP projects.
What makes this book special? In this book, we would like to present real projects—
more specifically: real SAP S/4HANA projects. In doing so, we name the reasons
why SAP projects often fail or cannot be implemented in a planned manner. We
discuss the prerequisites that should ideally be fulfilled in order to successfully
implement a project—and also show why these prerequisites are usually not met.
About This Book xv
In this context, we present the most common pitfalls and show how you can still
manage to bring an SAP project across the finish line. The “human factor” is
particularly important to us. We are convinced that without effective change man-
agement no sustainable project success can be achieved. In this context, you will
come across a number of topics again and again throughout the book. For example,
we highlight the importance of the Project Management Office (PMO) in various
sections of this book—from different perspectives.
Taken from Project Life
To bring our book to life, we will give you numerous fictitious project examples that
illustrate the dos and don’ts of project work. This book is not about cramming facts,
but rather designed to help you recognise yourself and your project. That way you
can elegantly avoid mistakes that others made before. Even if we base our examples
on the experiences we have had “in the wild”, similarities with living persons or real
companies (where not explicitly stated) are purely coincidental.
To make working with this book easier for you, we use information boxes to
indicate special notes and tips:
• Note:Warns you of common errors or problems that may occur. This symbol also
highlights references to e.g. further information on the discussed topic.
• Tip: We have marked tips that will make your SAP project easier.
Even More Content: Materials for the Book
Checklists and Templates for Download
Why reinvent the wheel again and again? In the materials accompanying the book,
you will find a series of checklists and templates for various documents on project
planning and implementation that have proven themselves in project practice.
Electronic supplementary material (ESM) is electronic material that is published
online on SpringerLink. The templates can be downloaded there.
• Quality Gate checklist for the Prepare Phase as Word document
• Quality Gate checklist for the Explore Phase as Word document
• Quality Gate checklist for the Realise Phase as Word document
• Quality Gate checklist for the Deploy Phase as Word document
• Project order as Word document
• Selection criteria for ERP Software as Word document
• RACI matrix as Excel document
• Example model for the estimation of expenses of SAP projects as Excel file
• Example of a project status sheet as Word and Excel document
• Example for the recording and tracking of risks as Word document
xvi About This Book
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 SAP Solutions: From the Beginning to Today . . . . . . . . . . . . . . . 1
1.1.1 One SAP ERP System for All Business Areas . . . . . . . . . 2
1.1.2 Standard Software as an Alternative to In-House
Developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Overcoming the Monolithic SAP ERP Architecture . . . . . 5
1.1.4 Acquisitions, Cloud Company, SAP HANA . . . . . . . . . . 7
1.1.5 Cloud and SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.6 SAP S/4HANA: The Largest Investment in the
Company’s History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Current SAP Software Solutions and Outlook . . . . . . . . . . . . . . . 12
1.2.1 The Experience Company Powered by the Intelligent
Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 SAP S/4HANA: A Slow Seller? . . . . . . . . . . . . . . . . . . . 14
1.2.3 On-Premise or in the Cloud? . . . . . . . . . . . . . . . . . . . . . . 15
2 What Makes an SAP Project So Different? . . . . . . . . . . . . . . . . . . . 17
2.1 What Distinguishes IT Projects from Business Transformation
Projects with SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Not All Projects Are the Same . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 What Is a Project? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 What Types of Project Management Are There? . . . . . . . 23
2.2.3 Who Is Involved in the Project? . . . . . . . . . . . . . . . . . . . 28
2.3 Digitalisation in Project Management . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 How Can Project Management Benefit from Digital
Transformation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 From Classical Project Management to Agile Processes
(Methods) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.3 Hybrid Project Management . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Why Software from SAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1 Analysis of the Initial Situation . . . . . . . . . . . . . . . . . . . . 37
2.4.2 Example for Selecting an ERP Software . . . . . . . . . . . . . 38
2.4.3 Review of the Existing System Landscape . . . . . . . . . . . . 38
xviixvii
2.4.4 The Assessment: Conducting an Analysis of the As-Is
Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.5 Software Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.6 Looking Back: Experiences with the SAP System and
Potential for Improvement . . . . . . . . . . . . . . . . . . . . . . . 42
2.5 The Road to SAP S/4HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.5.1 Your Company Has Been Using SAP for Years . . . . . . . . 45
2.5.2 Your Company Is About to Introduce SAP for the First
Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5.3 SAP S/4HANA Usage Models . . . . . . . . . . . . . . . . . . . . 47
2.5.4 What Is the Right Approach for Moving to SAP
S/4HANA: Greenfield Versus Brownfield Versus
Selective Data Transition . . . . . . . . . . . . . . . . . . . . . . . . 54
2.5.5 Data Migration Aspects of the Greenfield-Approach . . . . . 62
2.5.6 Economic Feasibility Considerations/Business Case . . . . . 64
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3 The SAP S/4HANA Project: How It Should Be . . . . . . . . . . . . . . . . 69
3.1 Project Management Standards, Methodology and Tools: An
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.1.1 Selection of the External Project Management . . . . . . . . . 72
3.1.2 The Importance of Project Management Methodology . . . 73
3.2 The Project Management Basics: PMI Project Management
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.3 Everything Perfectly Prepared: The Ideal Conditions . . . . . . . . . . 76
3.4 ASAP: The Mother of All SAP Methods . . . . . . . . . . . . . . . . . . 79
3.4.1 Phase 1: Planning and Preparation . . . . . . . . . . . . . . . . . . 80
3.4.2 Phase 2: Business Blueprint . . . . . . . . . . . . . . . . . . . . . . 82
3.4.3 Phase 3: Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.4.4 Phase 4: Production Preparation . . . . . . . . . . . . . . . . . . . 84
3.4.5 Phase 5: Go-Live and Support . . . . . . . . . . . . . . . . . . . . 84
3.4.6 Advantages and Disadvantages of ASAP . . . . . . . . . . . . . 85
3.5 SAP Launch: The ImplementationMethodology for SAP Cloud
Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.6 SAP Activate: The Better ASAP . . . . . . . . . . . . . . . . . . . . . . . . 87
3.6.1 Phase 1: Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.6.2 Phase 2: Prepare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.6.3 Phase 3: Explore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.6.4 Phase 4: Realise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.6.5 Phase 5: Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.6.6 Phase 6: Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.7 Support Tools Provided with SAP Activate . . . . . . . . . . . . . . . . 95
3.7.1 Roadmap Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.7.2 SAP Best Practices Explorer . . . . . . . . . . . . . . . . . . . . . . 97
3.7.3 SAP Model Company . . . . . . . . . . . . . . . . . . . . . . . . . . 97
xviii Contents
4 The SAP S/4HANA Project: How It Is . . . . . . . . . . . . . . . . . . . . . . 101
4.1 Phase 1: Discover (Or Explore Possibilities!) . . . . . . . . . . . . . . . 102
4.2 Phase 2: Prepare (Project Preparation) . . . . . . . . . . . . . . . . . . . . 103
4.2.1 Official Project Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.2 Simplification Through Solution Modules . . . . . . . . . . . . 103
4.2.3 Planning the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.4 Project Organisation and Project Resources . . . . . . . . . . . 105
4.2.5 Provisioning the Infrastructure . . . . . . . . . . . . . . . . . . . . 107
4.2.6 Communication Within the Company . . . . . . . . . . . . . . . 108
4.3 Phase 3: Explore (Or Map Business Processes!) . . . . . . . . . . . . . 109
4.3.1 Business Process Requirements . . . . . . . . . . . . . . . . . . . . 110
4.3.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.3.3 Project Standards and Procedures . . . . . . . . . . . . . . . . . . 112
4.4 Phase 4: Realise (Or The Implementation) . . . . . . . . . . . . . . . . . 113
4.4.1 Project Management and Control . . . . . . . . . . . . . . . . . . 114
4.4.2 Configuration of the Systems . . . . . . . . . . . . . . . . . . . . . 115
4.4.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.4.4 Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.4.5 Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.5 Phase 5: Deploy (Or Preparation for Going Live) . . . . . . . . . . . . 119
4.5.1 User Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.5.2 Going Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.6 Phase 6: Run (Or Go-Live and Support) . . . . . . . . . . . . . . . . . . . 120
4.7 The Top Flops in the SAP S/4HANA Project . . . . . . . . . . . . . . . 121
4.7.1 Pitfalls Throughout the Project . . . . . . . . . . . . . . . . . . . . 121
4.7.2 Phase 1: Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.7.3 Phase 2: Prepare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.7.4 Phase 3: Explore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.7.5 Phase 4: Realise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.7.6 Phase 5: Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.7.7 Phase 6: Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5 The Underestimated Success Factor: People . . . . . . . . . . . . . . . . . . 125
5.1 Who Belongs to the Project Team? . . . . . . . . . . . . . . . . . . . . . . 126
5.2 The Importance of Project Management Leads . . . . . . . . . . . . . . 130
5.3 Qualification, Personal Suitability and Availability of Project
Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.3.1 Skill Requirements in Digital Project Management . . . . . . 139
5.3.2 How to Select the Right Employees . . . . . . . . . . . . . . . . 141
5.3.3 To Ensure the Availability of Resources . . . . . . . . . . . . . 144
5.4 Key Factors for Good Teamwork . . . . . . . . . . . . . . . . . . . . . . . . 146
5.4.1 Mutual Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.4.2 A Common Understanding of the Mission . . . . . . . . . . . . 147
5.4.3 Individual Engagement and Self-Commitment to the
Team Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Contents xix
5.4.4 Clearly Defined Roles and Responsibilities . . . . . . . . . . . 148
5.4.5 Rules for Working in a Team . . . . . . . . . . . . . . . . . . . . . 148
5.4.6 Clear Decision-Making . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.4.7 Effective Group Processes . . . . . . . . . . . . . . . . . . . . . . . 148
5.4.8 Guidelines for High-Performance Teams . . . . . . . . . . . . . 149
5.5 Humanity, Feasibility and Motivation . . . . . . . . . . . . . . . . . . . . . 151
5.5.1 Detect Overload and Excessive Stress . . . . . . . . . . . . . . . 152
5.5.2 Employees Need Motivation . . . . . . . . . . . . . . . . . . . . . . 155
5.5.3 Help to Avoid Stress . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.6 Communication as a Success Factor . . . . . . . . . . . . . . . . . . . . . . 161
5.6.1 Communication Culture . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.6.2 Communication Structure and Corporate Culture . . . . . . . 166
5.7 International Project Staffing: A Special Challenge . . . . . . . . . . . 169
5.7.1 Good Advice Is Half the Battle . . . . . . . . . . . . . . . . . . . . 170
5.7.2 The Journey Has Just Begun: After Arrival . . . . . . . . . . . 170
5.8 Impact of Digitalisation on Project Management . . . . . . . . . . . . . 173
5.8.1 What Is Important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.8.2 Digitalisation of Customer Relations . . . . . . . . . . . . . . . . 173
5.8.3 Building Digital Talent . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.8.4 Use of Data and Advanced Technologies . . . . . . . . . . . . . 175
5.8.5 Digitalisation of Operations and Automation
of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6 Project Planning, Control and Quality Assurance . . . . . . . . . . . . . . 177
6.1 Support Whenever You Need It: The Project Management
Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.2 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.2.1 The Pillars of Project Planning . . . . . . . . . . . . . . . . . . . . 182
6.2.2 Planning Factors: Goals, Deadlines and Cost . . . . . . . . . . 182
6.2.3 How Do You Plan a Project? . . . . . . . . . . . . . . . . . . . . . 183
6.2.4 How Expensive, How Long, and How Much? The Effort
Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.3 Project Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.3.1 Guidelines for a Successful Project Control . . . . . . . . . . . 191
6.3.2 Carry Out Control Processes . . . . . . . . . . . . . . . . . . . . . . 197
6.4 Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6.4.1 What Are the Practical Problems? . . . . . . . . . . . . . . . . . . 203
6.4.2 What Does Quality Assurance in Project Work Mean? . . . 204
6.4.3 Preparation and Execution of Reviews . . . . . . . . . . . . . . . 204
6.4.4 Treatment of the Review Results . . . . . . . . . . . . . . . . . . . 207
6.5 Planning, Control and Quality Assurance in SAP S/4HANA
Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
6.5.1 What’s New in the IT Project World Today? . . . . . . . . . . 209
6.5.2Project Management in SAP S/4HANA Projects . . . . . . . 211
6.5.3 Special Features of SAP S/4HANA Projects . . . . . . . . . . 212
6.5.4 Tasks in the Different Project Phases (Checklists) . . . . . . 215
xx Contents
7 Examples from Real-Life SAP S/4HANA Projects . . . . . . . . . . . . . . 219
7.1 Preparation of an SAP S/4HANA Implementation Project . . . . . . 219
7.1.1 Initial Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.1.2 Reasons for the Project . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.1.3 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
7.1.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
7.2 Implementation of SAP S/4HANA at ELKB in Bavaria . . . . . . . . 224
7.2.1 Initial Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.2.2 Reasons for the SAP S/4HANA Project . . . . . . . . . . . . . . 226
7.2.3 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
7.2.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
7.2.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
7.2.6 Summary and Lessons Learned . . . . . . . . . . . . . . . . . . . . 234
7.3 “Be Liquid”: BITZER’s Agile Way to SAP S/4HANA . . . . . . . . 235
7.3.1 Development of the System Landscape . . . . . . . . . . . . . . 238
7.3.2 The 5-Year Plan: SAP S/4HANA . . . . . . . . . . . . . . . . . . 239
7.3.3 Not Your Run-of-the-Mill SAP S/4HANA
Implementation Project . . . . . . . . . . . . . . . . . . . . . . . . . . 240
7.4 Project to Replace Global Procurement Systems (Automotive
Industry) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
7.4.1 Initial Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
7.4.2 Reasons for the Project . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.4.3 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.4.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
7.4.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.5 Lessons Learned from Our SAP ECC Projects . . . . . . . . . . . . . . 251
7.5.1 Global SAP Implementation from the Perspective
of a Pilot Country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
7.5.2 Lessons Learned: The Local Project Preparation . . . . . . . 257
7.5.3 Lessons Learned: Local Business Blueprint . . . . . . . . . . . 258
7.5.4 Lessons Learned: The Realisation Phase . . . . . . . . . . . . . 259
7.5.5 Lessons Learned: Final Phase of Preparation/Go-Live
and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
7.5.6 What Happened After the Pilot Installation: The Rollout
Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
8 Consultants: Boon or Bane? Benefit or Burden? . . . . . . . . . . . . . . . 273
8.1 Why Bring in External Support? . . . . . . . . . . . . . . . . . . . . . . . . 273
8.2 Finding the Right Ones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
8.3 Fixed-Price Service Contract or Time and Material? . . . . . . . . . . 278
8.4 Role Distribution Between Client and Consultant . . . . . . . . . . . . 281
8.5 The Internal External . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
8.6 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
8.7 Projects with Offshore or Nearshore Teams . . . . . . . . . . . . . . . . 286
Contents xxi
9 Project Support Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
9.1 Project Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
9.1.1 Microsoft Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
9.1.2 Microsoft Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
9.1.3 Microsoft Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
9.1.4 Microsoft Outlook/Exchange/Outlook 365 . . . . . . . . . . . . 296
9.1.5 Shared Network Drive . . . . . . . . . . . . . . . . . . . . . . . . . . 297
9.1.6 SAP Solution Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 298
9.2 Tools for Business Process Management . . . . . . . . . . . . . . . . . . 301
9.3 Tools for Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
9.3.1 SAP Solution Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 304
9.3.2 CATT and eCATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
9.3.3 Other Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
9.4 Tools for Operational Support and Software Logistics . . . . . . . . . 306
9.4.1 Transportation/Software Logistic . . . . . . . . . . . . . . . . . . . 306
9.4.2 Systems Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
9.4.3 Master Data Management . . . . . . . . . . . . . . . . . . . . . . . . 308
9.5 Minimised Downtime Services . . . . . . . . . . . . . . . . . . . . . . . . . 309
9.6 SAP S/4HANA Migration Cockpit . . . . . . . . . . . . . . . . . . . . . . . 310
9.7 SAP Data Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
10 12 Commandments for a Successful SAP Project . . . . . . . . . . . . . . 315
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
xxii Contents
About the Authors
Denise Banks-Grasedyck is a certified coach, consul-
tant and speaker specialising in the further development
of professionals and executives. Through her many
years of work in a global consulting and auditing com-
pany, she gained extensive experience in project
organisation and project and relationship management.
In the process, it became clear time and again that the
correct handling of the “human factor” in project work is
the critical key to success.
Committed to helping others utilise their full poten-
tial, Denise Banks-Grasedyck continues to expand her
knowledge and competency and has earned multiple
certifications, including Certified Global Leadership
Coach and Certified Global Team Coach through the
Global Coach Group, as well as Certified Executive
Coach and Certified Team Coach through Marshall
Goldsmith Stakeholder Centered Coaching. She
completed her initial training and certification as a Per-
sonal and Professional Development Coach at the Insti-
tute for Professional Excellence in Coaching (iPEC) in
Boston (USA).
Denise Banks-Grasedyck earned her MBA in inter-
national dual studies at the Berlin School of Law and
Economics and Anglia Ruskin University in Cambridge
and Chelmsford (UK). She graduated from the Univer-
sity of Maryland with a BA in Management and
Technology.
xxiiixxiii
Eckhard Lippke joined SAP in 2000, after obtaining a
master’s degree from the University of Siegen
(Germany). During the first 9 years at SAP, he worked
as a technology consultant and PMP certified project
manager on many large projects in Europe, Asia and
the USA. He then took on a management position in
SAP Technology Consulting and in 2015 joined SAP’s
largest cloud business unit “Enterprise Cloud Services”
as customer engagement manager. In his current role, he
accompanies many SAP customers on their journey to
the Digital Enterprise in the Cloud.
Hans Oelfin has been managing director of SOP
Schwaiger & Oelfin Project Consulting in Waldenbuch
since 2014. SOP specialises in IT project management,
project quality assurance and corporate trainingin proj-
ect management. Previously, Hans Oelfin managed
local and global IT projects for more than 20 years in a
worldwide IT company. Of these, he spent 15 years as a
development and deployment manager in the SAP envi-
ronment. He studied business administration at the Uni-
versity of Applied Sciences (FH) Ludwigshafen/Rhein,
and graduated as Diplom-Betriebswirt FH. He has been
a lecturer at the Nürtingen-Geislingen University of
Applied Sciences (HfWU) for several years.
Reinhold Schwaiger has been Managing Director of
SOP Schwaiger & Oelfin Project Consulting in
Waldenbuch near Stuttgart since 2004. SOP specialises
in IT project management, project quality assurance and
corporate training in project management. Previously,
Reinhold Schwaiger worked for many years in the man-
agement of a global IT corporation. He was responsible
for SAP pilot installations and worldwide rollouts in the
SAP environment for 15 years. He studied social
sciences and economics at the University of Graz/
Austria and graduated with a diploma.
xxiv About the Authors
Volker Seemann is Managing Director of REBASE3
GmbH in Potsdam since 2014. Rebase3 offers consult-
ing, interim management and software development for
companies from various industries. Previously, he
worked for various global consulting companies as a
project and program manager and as an IT architect.
Dr. Volker Seemann has been working in the SAP
environment since 1994. He studied electrical engineer-
ing at the Humboldt University in Berlin, where he
received his doctorate in electrical engineering. He was
a guest lecturer at the Brandenburg University of Tech-
nology for several years.
About the Authors xxv
Introduction 1
1.1 SAP Solutions: From the Beginning to Today
When SAP was founded in 1972 by five former IBM employees, the company
started with an idea that would revolutionise the world of ERP (enterprise resource
planning) software.
Electronic data processing (EDP) was not yet widespread in small- and medium-
sized enterprises, not least because of its high cost. Only large companies used
mainframes (often from IBM) in certain areas of their business. Although these
systems filled entire rooms, their computing power and applications were very
limited from today’s point of view.
Batch Processing
A major problem was the delayed posting of business transactions: databases were
usually updated once a day, i.e. business transactions such as goods movements were
collected during the day and then posted overnight in batchmode. The next morning,
the databases were synchronised with the actual stocks, but during the day, changes
were not posted directly but collected until the next nightly batch processing. As the
day progressed, therefore, the data stock increasingly deviated from the actual stock.
Real-Time Instead of Nightly Batch Processing
The revolutionary idea was to make all data changes real time; this means writing to
the central database in real time (the “R” in SAP R/3 stands for exactly this). Instead
of only finding out the next day whether their bookings had been successfully
completed, employees could now always rely on the correctness and topicality of
the data. They were also able to reliably answer enquiries, e.g. about the availability
of goods.
The first SAP products were solutions for accounting (real-time financials, RF)
and materials management (real-time materials management, RM), which were
introduced to the market in 1973 with the first product SAP R/1. The successor,
# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_1
1
http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-86084-4_1&domain=pdf
https://doi.org/10.1007/978-3-030-86084-4_1#DOI
SAP R/2, was a very successful, mainframe-based soft real-time application in the
1980s and 1990s and was used primarily by large international corporations in
Europe. It contained the most important functions necessary for the control of an
internationally operating company: financial accounting, purchasing and merchan-
dise management, warehouse management, production planning, quality manage-
ment, sales, logistics and human resources.
SAP’s response to the emerging client-server-based systems was the even more
successful product SAP R/3, which was launched on 6 July 1992 (see Fig. 1.1). Back
then, the SAP development team allowed themselves the joke of immortalising the
date by making it the default password of the two central admin users SAP* and
(in reverse order) DDIC.
“R” again stood for real time and “3” for both the third software product and the
three levels (three-layer architecture or three-tier architecture): a client-server
software architecture consisting of database, application server and frontend (SAP
GUI).
1.1.1 One SAP ERP System for All Business Areas
SAP ERP is a software that covers all important business areas of a company, from
purchasing, production, sales, warehousing, materials management, human
resources to finance, which is scalable and stores all data in a central database: this
was a very attractive offer for companies that previously only had the choice
between very expensive mainframe computers, self-developed individual solutions
and many smaller products with limited functionality, e.g. missing or hardly opera-
ble interfaces.
Mainframe Computer, In-House Development or Standard Software?
At that time, mainframes were already mature, high-performance systems that could
cover a large part of business transactions. However, they caused high acquisition
R/3 Client / Server
ABAP
Logis�cs
SD Sales & Distribu�on
MM Materials Management
PP Produc�on Planning
QM Quality Management
PM Planned Maintenance
Human Resources
HR Human Resources
Financials
FI Financials
CO Controlling
TR Treasury
Cross-Func�onal
PS Project System
WF Workflow
IS Industry Solu�ons
Fig. 1.1 SAP R/3: Overview of the modules
2 1 Introduction
and operating costs and required complex adaptations to company-specific
requirements. Such an investment was only worthwhile for large companies.
Individual solutions have the advantage of being tailored to the respective
business requirements but also entail a number of risks: at the beginning of an
in-house development, one does not know whether the final product will meet all
requirements. Will it be stable, performant and adaptable? What about long-term
operation and software maintenance? Can changing legal requirements be
implemented cost-effectively? These risks should not be underestimated: an invest-
ment in a comprehensive in-house development can influence the economic success
of the entire company for better or for worse.
Special applications for individual company areas or specific tasks offer the great
advantage of often combining the best functionality with the simplest operability
(so-called best of breed), a dream for end users but a bit of a nightmare for the IT
department, because operating these solutions presents them with major challenges.
In addition to the many point-to-point interfaces, which have to be tested again and
again with each new program version (and adapted if necessary), topics such as
master data management, monitoring and consistent backup/restore are also causing
headaches. Such special applications can do their tasks much better than standard
software such as that offered by SAP, but the operational deficits and risks speak in
favour of using standard software in the long term.
1.1.2 Standard Software as an Alternative to In-House
Developments
SAP offers an attractive alternative: standard software includes numerous standard
processes for all company areas from the outset. Customers receive an adaptable
software template for their business processes, which they can adopt with simple
settings or adapt, extend and modify as required. SAP customers have always been
supplied with the entire sourcecode and a powerful development environment,
which allows company-specific process enhancements, additional developments
and modifications to be easily implemented.
Originally, SAP R/3 was written in ABAP (Advanced Business Application
Programming), a programming language developed by SAP itself, a 4GL ( fourth-
generation language), which is designed to be able to develop entire applications
with as few lines of code as possible. With each system, SAP delivers a powerful
development tool that enables development projects to be implemented in a very
short time, especially due to the reusability of existing routines and data structures.
In addition, SAP offers numerous customising settings that allow the SAP
software to be adapted to the specifics of the company without any programming
knowledge. Open interface standards enabled communication with external
applications, customers and suppliers.
1.1 SAP Solutions: From the Beginning to Today 3
80:20 Rule for Standard Software
SAP’s claim was and is to cover approx. 80% of a company’s business processes out
of the box—the remaining 20% can be added or adapted by customers through
customer-specific developments. By delivering the source code and the
corresponding development environment—including an open extension standard
by the way—there are virtually no restrictions for customers to adapt the software
to their needs.
The SAP business processes, which were conceived by SAP and tested thousands
of times, promised a solid process model for almost all companies. SAP was also
able to score points with continuous improvement and further development as well
as future—proofing through long maintenance cycles. Internationally active
companies also appreciated the multi-language capability, which allowed them to
easily map different character sets (e.g. Latin and Chinese) in one system.
Experience shows that it is better to adapt the company to SAP software than to
adapt the software to the company, because a standard software that deviates greatly
from the standard loses its key advantage and costs a lot of additional money over the
years as the deviations must be adapted and tested each time the SAP standard
software is updated.
But there were (and still are) restrictions: standard software is never so precisely
tailored to the company’s requirements that there is no need to make any
concessions. Experience has shown that customers who have adapted their
organisational structure and business processes to the SAP processes they had in
mind have been more successful in the long term than customers who have (drasti-
cally) changed the SAP standard software to adapt it to their previous organisational
structure and their own processes. SAP R/3 could be changed massively, but in the
long run, they paid a high price for it, as any new version had to be extensively
analysed, tested and, if necessary, adapted again. And this is the best-case scenario.
Some customers found out the hard way that they had modified the standard SAP
software so fundamentally that it was no longer possible to implement newer
versions. They had the choice of either staying on their release indefinitely (which
was really not an option) or re-implementing SAP.
The great commercial success of SAP R/3 triggered an initial, very strong growth
phase in the 1990s. Between 1991 and 1996 alone, SAP’s turnover increased
fivefold. In order to cope with the rush of customers, an extensive partner network
was established, which carried out the implementation of SAP R/3 (and later the
successor products SAP ERP and SAP Business Suite) for many customers
worldwide.
Key to SAP’s Success: The Global Partner Network
The establishment of an extensive partner network was crucial to the global success
of the SAP ERP software, as many more customers could be served than SAP could
ever have done with its own employees. It was also a lucrative business for both
sides: the partners provided the consulting experts—often with in-depth industry
know-how and years of project experience—and earned money on the
4 1 Introduction
implementation, which often took many months or even years. They had the
opportunity to establish a lasting partnership with end customers. SAP, on the
other hand, earned from the licences and the subsequent support business. An
attractive software product and a successful partner model were the key to SAP’s
success.
At the beginning of the 2000s, SAP thus rose to become the world market leader
for ERP software, growing at breath-taking speed in Germany as well as worldwide
and continuously expanding its software range. Industry solutions were developed,
of which there are now more than 30, covering the needs of, for example, the
manufacturing industry, the service sector, consumer goods manufacturers, energy
companies and the public sector. The next step was to extend the monolithic SAP
R/3 system by developing the SAP Business Suite.
1.1.3 Overcoming the Monolithic SAP ERP Architecture
SAP Business Suite
In the first decade of the new millennium, SAP R/3 was a mature product, but as a
“one-size-fits-all solution”, it could no longer meet all customer requirements. In
order not to increase the complexity of the core product any further, specific
solutions were created with the SAP Business Suite for business subareas:
• Customer management (SAP CRM)
• Reporting (SAP BW, formerly SAP Business Intelligence, SAP BI)
• Warehousing (SAP Extended Warehouse Management, SAP EWM)
• Procurement management (SAP SRM)
• Supply chain and supplier management (SAP SCM)
The basis for these new products was the common application platform SAP
NetWeaver. This common application environment ensured smooth operation and
close integration of the systems.
SAP NetWeaver
was (and still is) the common foundation for the SAP Business Suite applications
and provides numerous common functions. These include user management,
development environment, database management, web server, etc.
The expansion of the product range was accompanied by the introduction of a
further programming language: in addition to ABAP, applications were now also
developed in Java.
In 2004, SAP R/3 was converted to SAP ECC (SAP Enterprise Core Component)
and together with SAP CRM, SAP BW, SAP SCM, etc. marketed as SAP Business
Suite.
Other products were added to round off the offering:
1.1 SAP Solutions: From the Beginning to Today 5
• SAP Portal provided a configurable entry interface and landing page for
customers.
• SAP NetWeaver Exchange Infrastructure, SAP Process Integration, SAP Process
Orchestration
SAP NetWeaver Exchange Infrastructure, later renamed SAP PI (SAP Process
Integration) and finally SAP PO (SAP Process Orchestration), is a central inter-
face hub for internal and external data exchange. The aim of SAP PO is to replace
point-to-point connections between IT systems (not only SAP) with an interface
hub, which facilitates monitoring, maintenance and troubleshooting: nearly all
adjustments can be made at one central point in the PO system.
Two topics were the focus of the development of these new products. Special
processes, for example, reporting or supply chain management, were outsourced to
dedicated applications. This made it possible to include more customer requirements
than would have been possible in SAP R/3—and the common SAP NetWeaver
platform ensured the close integration and easy operability of all components of SAP
Business Suite.
Customers were able to decide whether the functionality covered by SAP R/3
(or SAP ECC) was sufficient for them or whether the additional process
requirements of the specialist departments should be covered by the new SAP
special applications without having to make compromises in the area of operability
or data integration.
Standard Software vs. “Best-of-Breed”
SAP had taken up the challenge with the promise that standard software, which
covers practically all areas of the company, would be more stable and more cost-
effective to operate in the long term, morereliable and more efficient than in-house
developments or special solutions for individual company areas. This is known as
the standard software vs. best-of-breed approach. “Best-of-breed” Software may
offer better features, but in terms of operability, standard software is better, leading
to the quip: Standard (software) is better than “Better Than Standard”.
Although SAP’s standard software products were in some cases not always the
best on the market in terms of functionality and user-friendliness, a decisive advan-
tage of these solutions from the customer’s point of view was their close integration
into the overall solution portfolio: they were based on the SAP NetWeaver Applica-
tion Server (SAP NetWeaver AS) and were therefore easier for customers to operate
than special solutions from different suppliers, some of which are difficult to
integrate. Many companies also appreciated the fact that they only had to deal
with one supplier when software problems arose—not several, whose default answer
was that their software was of course error-free and that the error was surely to be
found with the other supplier. In a worst-case scenario, the company’s core IT
systems are down and the software providers are passing the buck to each other.
6 1 Introduction
1.1.4 Acquisitions, Cloud Company, SAP HANA
The acquisition of “Business Objects” marked a turning point in SAP’s strategy.
Until then, SAP had focused on organic growth, an integrated software portfolio and
its own innovative strength. However, the limits of its own growth seemed to be
approaching. Now the company began to buy up innovations from the market: the
takeover of the French business intelligence specialist Business Objects in the same
year was the first major acquisition that required the integration of a completely
foreign software stack into the solution portfolio.
Organic Growth Is Not Enough: SAP Goes on a Shopping Spree
After SAP was accused of underestimating the importance of the Internet for too
long in the early 2000s, SAP reacted quickly: as early as 2014, SAP described itself
as “The Cloud Company powered by SAP HANA”, and the Walldorf-based com-
pany implemented this goal with great determination in the following years.
From 2008 on, SAP went on a shopping spree and in 11 years took over more
than 20 software manufacturers, most of which offered cloud-based solutions:
Sybase in 2010, SuccessFactors 2011, Ariba 2012, Concur in 2014 and Callidus in
2018. In the same year, SAP bought Qualtrics, the most expensive acquisition in the
company’s history, at a price of around €6.4 billion.
In this way, SAP acquired numerous innovative software solutions but paid a
high price (some believe it was too high), not only financially: the much-vaunted,
exemplary integration of SAP software on a common application server was history.
On the one hand, there was the well-integrated SAP Business Suite and, on the other
hand, third-party products that needed to be integrated into the portfolio in the
following years. The initial “integration” of Ariba via CSV file interface is indicative
of the challenges SAP faced and what the customers had to put up with. On the one
hand, the business departments on the customer side cheered in view of the new
functionalities and offers. IT departments, on the other hand, were less enthusiastic
as operations became considerably more complicated, costly and less reliable.
Nevertheless, the core product and the cash cow was and remained SAP Business
Suite, a mature, solid product but one that was becoming technologically outdated,
having its roots in the 1990s. Through continuous development, it had evolved into a
complex, scalable yet easy to operate software. Customers appreciated its stability
and extensive functions, but the user-friendliness and user guidance in the proprie-
tary SAP GUI (SAP Graphical User Interface) were perceived by many customers as
no longer up to date. SAP responded first by introducing the new Business Client
user interface and later with SAP Fiori. However, it has not yet managed to
completely replace the old SAP GUI.
The ever-increasing data volumes also caused problems for some customers, and
cloud computing was out of the question with this software. SAP Business Suite was
a well-designed, consistent on-premise software—at a time when the market for
cloud software was quickly becoming the market of the future par excellence. What
could SAP do now to keep up with this market trend?
1.1 SAP Solutions: From the Beginning to Today 7
1.1.5 Cloud and SAP HANA
At this point, two parallel, actually independent developments intersect, which
ultimately come together: the trend towards “cloud” and the development of the
SAP HANA in-memory database.
Led by company founder Hasso Plattner, a revolutionary new database technol-
ogy was developed from 2008 onwards: SAP HANA (High-Performance Analytics
Appliance). In contrast to relational databases (mostly those of the American com-
petitor Oracle), which used to store customers’ business data on storage mediums,
SAP HANA is an in-memory database that can offer massive performance
improvements—and ultimately completely new possibilities for real-time data
processing and analysis.
SAP HANA Versus Relational Database Systems
Relational database systems, which had previously been the basis for SAP business
applications, reached their limits in the face of ever-faster data growth. The need for
ever-more powerful servers and performance problems with large amounts of data
were the result.
While relational databases had to repeatedly read and save data from hard disks or
other (relatively slow) storage media, SAP HANA took a different approach. The
entire database was stored in the fast, random access memory (RAM) of the server.
The company switched from line-oriented data management to column orientation
and thus achieved a considerably reduced data volume and an enormously increased
performance, especially for read reporting tasks. Supported by the falling price of
memory modules and increasingly powerful servers, completely new application
possibilities arose for processing real-time data and data streams and for analysing
large amounts of data.
This is begging the question: “And what if the power fails?”
For performance reasons, only data changes are backed up in slim log files on
permanent data storage devices. This means there is no risk of data loss even in the
event of a sudden power failure.
The SAP HANA log files protect reliably against data loss but also lead to longer
startup times, since all data must first be loaded into the server’s working memory
when restarting. This can take 30 minutes or more on larger systems. So the fast
processing speed has its price in daily operations.
Ending Support for Numerous OS and DBMS
The next major event was the release of SAP Business Suite on the new in-memory
database SAP HANA in 2013. SAP software was previously largely “agnostic”
when it came to OS (operating system) and DB (database), i.e. it could be operated as
desired on a number of common operating systems and databases from various
suppliers. Customers appreciated this flexibility. Most of SAP’s customers used the
Oracle database, which led to the astonishing situation that for many years, SAP was
the largest licence vendor for its closest competitor.
8 1 Introduction
On the other hand, this led to high costs for SAP. Each new software version had
to be extensively tested on several operating systems and database systems before
delivery. It is an open secret that not all OS-DB combinations could be thoroughly
tested. Especially with more “exotic” combinations, it was the customers who found
some bugs. In addition, error notes had to be created and maintained, sometimes
specifically for individual databases and operating systems. Furthermore, SAP was
forced to maintain installation guides and other documentation for numerous OS-DB
combinations.
The openness for different operating systems and database systemsreduced the
training expenses for the customers, as they could switch to products for which the
company already had know-how—but it cost SAP dearly.
SAP HANA and Linux Are the Future
Through the introduction of SAP HANA, this situation was brought to an end: now,
the in-memory database SAP HANA and the Linux operating system are exclusively
part of the SAP software stack. This is an about-turn, as other operating systems and
databases have since then played practically no role in SAP’s product strategy. Only
the ASE and IQ databases acquired as part of the acquisition of Sybase are used in
certain cases and some special products.
The switch to SAP HANA as the one and only database for SAP software was a
hurdle for SAP customers that should not be underestimated.
• SAP HANA requires specially certified hardware, which is expensive to
purchase.
• The Oracle/DB2/MS-SQL server know-how developed over the years lost its
importance; instead, SAP customers’ IT departments had to build up new SAP
HANA know-how to be able to operate the new database.
Smaller companies, in particular, which had mostly relied on easy-to-run
Windows-based servers, initially struggled with the very different,
non-commercial, free operating system Linux.
SAP Business Suite: Full Throttle with Handbrake Applied
The first step was to adapt the SAP Business Suite so that it could run on the new
in-memory database. But SAP Business Suite had been developed for relational
databases and could not really exploit the strengths of the SAP HANA database. In a
hurry, performance optimisations were made in the SAP Business Suite to demon-
strate to customers the superiority of the SAP HANA-based Business Suite (today’s
name: SAP Business Suite powered by SAP HANA). Good results were achieved in
reading operations, while in writing operations, the success was rather limited.
Apart from SAP BW—a system that mainly performs read operations for the
display of reports—the move to SAP HANA on the classic SAP Business Suite did
not actually bring such great benefits for SAP customers that the high implementa-
tion costs for new hardware, training of staff, etc. actually paid off.
1.1 SAP Solutions: From the Beginning to Today 9
The decision was inevitable: SAP’s flagship product, SAP Business Suite, had to
be developed in a new version specifically for SAP HANA in order to take full
advantage of the new possibilities offered by in-memory technology.
1.1.6 SAP S/4HANA: The Largest Investment in the Company’s
History
The SAP Business Suite was written over decades by thousands of SAP developers
and consists of millions of lines of code—a new development was a unique
challenge and is the largest investment in the company’s history. Considerable
development resources have been and will be tied up for years to come.
SAP S/4HANA: Impressive, but Customers Still Hesitate
In 2015, the time had come: SAP S/4HANA, an SAP ERP solution specially
developed for the in-memory database SAP HANA, was presented. It was impossi-
ble to implement the functionality of the classic SAP Business Suite in SAP
S/4HANA within 2 years; therefore, the first step was to focus on FI/CO (Finan-
cials/Controlling) and offer this “slimmed down SAP ERP”. In the following years,
the functionalities were successively extended. The goal was never to create merely
an in-memory version of SAP ERP. Instead, the focus was on simplification and
optimisation of business processes. In the meantime (as of spring 2021), the SAP
S/4HANA on-premise solution with 35 supported languages, 61 country versions
and 23 industry solutions has caught up considerably with the SAP Business Suite.
For SAP, this has been an enormous effort, which goes to show what this company is
capable of. The result is impressive, but it has not yet led to a mass migration of SAP
customers to the new core product.
SAP software forms the IT backbone of many companies and is used in the most
critical business areas. If it fails, large parts of the company are no longer able to
work. Operations come to a standstill. Every major outage costs a lot of money and,
in the worst case—assuming the outage lasts for days and weeks—can threaten the
company’s existence.
SAP Customers: Never Touch a Running (SAP) System
SAP customers are therefore very conservative and risk-averse: reliability, stability
and operability are decisive factors for business-critical IT systems. The vast major-
ity of SAP customers run the core of their applications in their own data centres.
Many, particularly smaller companies, have transferred operation to experienced
hosting providers specialising in SAP. Innovations are carefully evaluated, tested
and introduced step by step to minimise business risk.
The growing importance of cloud-based solutions was already foreseeable in
2013; therefore, SAP S/4HANA was developed from the beginning as an
on-premise solution and in two further variants as a cloud solution. SAP is
10 1 Introduction
performing a balancing act here and, on the one hand, responds to the demands of
major customers who want to operate their core applications in their own data
centres with the SAP S/4HANA on-premise solution.
On the other hand, the SAP S/4HANA Cloud solution is designed to open up new
business areas and customer markets. Although cloud solutions offer far fewer
possibilities to adapt them to specific customer requirements, their monthly sub-
scription rates mean that they represent a lower investment, can be consumed more
quickly and reduce the need for in-house IT specialists.
Cloud solutions also offer a host of other important advantages:
• Scalability
Cloud solutions can be easily adapted to the company’s requirements—more
computing capacity or less: just as the business requires!
• Connectivity.
Cloud allows mobile data access worldwide and around the clock via PCs, laptops
or mobile devices.
• Flexible workstations
Since all data is stored in the cloud, the location of the workstation is no longer
important. Whether in the office, at home or abroad—as long as the data connec-
tion is stable and fast enough—it doesn’t matter anymore. Employees have the
privilege to be able to work from anywhere.
• Data security
Cloud solution providers offer security systems for customer data that are far
more professional than what small companies can do on their own.
For customers who cannot or do not want to do without the advantages of the
cloud and the configurability of on-premise solutions, there is the possibility to
combine the best of both worlds: hybrid system landscapes (i.e. partly on-premise,
partly in the cloud) allow business-critical applications to continue to operate as
on-premise applications; new areas of application can be introduced and used
quickly and cost-effectively using cloud software.
The requirement for SAP S/4HANA was therefore not only to become the new
and improved SAP Business Suite, but the stated goal was to integrate with SAP
cloud offerings—and these are now quite a few, thanks to acquisitions and solutions
developed by SAP itself:
• SAP SuccessFactors: cloud-based HCM solution (acquisition)
• SAP Ariba: cloud-based trading networks (acquisition)
• SAP Customer Experience: E-commerce (acquisition)
• SAP Fieldglass: cloud-based temporary employment management (acquisition)
• SAP Concur: travel and expense management (acquisition)
• CallidusCloud: cloud-based distribution software (acquisition)
• Qualtrics: cloud-based enterprise feedback management (EFM) (acquisition)
• SAP Analytics Cloud: SaaS cloud (software as a service), especially for reporting
(proprietary development, based on SAP Business Objects)
1.1 SAP Solutions: From the Beginning to Today 11
• SAP Sales Cloud: SaaS cloud for CRM (in-house development)
• SAP Marketing Cloud: SaaS cloud for marketing (in-house development)
• SAP Service Cloud: SaaS cloud for customer service and after sales support
(in-house development)
• SAP Cloud Platform: PaaS cloud (platform as a service) for the integrationof
cloud and on-premise landscapes (proprietary development)
• SAP HANA Enterprise Cloud: PaaS cloud for operating customer landscapes in
SAP-owned or hyperscaler data centres (infrastructure service)
1.2 Current SAP Software Solutions and Outlook
Over the last decade, SAP has massively expanded its range of software solutions
and especially its cloud offerings. At the same time, there has been a huge invest-
ment in new technologies. From 2012, former SAP CEO Dr. Henning Kagermann
became a leading representative of the future project Industrie 4.0 in Germany, a
vision of intelligent, digitally networked systems, on the basis of which self-
organised production should become extremely advanced. The focus was (and still
is) the automation of production and IoT scenarios (IoT, Internet of Things) through
which physical and virtual objects are connected and cooperate via information and
communication technologies. Evaluations of the enormous amounts of data
generated in this process are made possible by big data applications, which in turn
are based on the very fast SAP HANA database.
Industrie 4.0: Machine Learning, AI, IoT
In parallel, SAP developed fascinating new functions initially called SAP Leonardo,
e.g. block chain, machine learning and big data. RPA (robotic process automation)
as part of machine learning, artificial intelligence (AI) and IoT was successively
integrated into SAP products: RPA can use chatbots to speed up administrative tasks
and improve customer experiences. IoT creates new possibilities in the digitalisation
of the logistics chain, not to mention big data applications—the list goes on and on!
Numerous acquisitions, especially from cloud software providers, have opened up
new customer and business areas. Cloud and subscription models offer customers
commercially very attractive new possibilities (and, unlike one-time license fees,
provide SAP with stable, recurring revenues). SAP is evolving from what has some-
times been disrespectfully referred to as a “software shop” into a full-service provider
that combines the development and operation of software solutions in one hand.
In 2019, a strategic partnership was agreed with Microsoft. The so-called
Embrace programme is designed to encourage customers to use SAP software on
the Microsoft Azure Hyperscale infrastructure. However, this is not an exclusive
partnership—Amazon (Amazon Web Services) and Google (Google Cloud Plat-
form) are also supported. Although SAP operates more than a dozen data centres
with thousands of customer landscapes worldwide, the company is obviously relying
on the economies of scale in the infrastructure area for future growth that only
12 1 Introduction
hyperscalers can offer. In the future, SAP will focus on the upper parts of the
software stack and intends to operate as a full-service provider in this area.
1.2.1 The Experience Company Powered by the Intelligent
Enterprise
X- and O-Data for the Intelligent Company
Since the acquisition of Qualtrics, SAP’s new corporate motto has been “The
Experience Company powered by the Intelligent Enterprise”. This means that the
combination of operational business data (O-data) with customer satisfaction data
(customer experience data, X-data) allows companies to deliver a specifically tai-
lored shopping experience to their customers and thereby meet customer
expectations. The result is the Intelligent Enterprise (Fig. 1.2).
The heart of the system remains the SAP S/4HANA system, now called the intelli-
gent ERP suite. It consists of the ERP system, digital logistics, customer experience
and Intelligent Spend and Human Experience Management (HXM) solutions. Mod-
ern technologies, such as machine learning, AI, blockchain, Internet of Things and
analysis functions, are used as integral components of SAP software products and
allow O-data to be combined with X-data.
The concept consists of the following components:
1. Intelligent Suite
• The Intelligent Suite includes enterprise resource planning (ERP), digital
supply chain management, customer experience, Intelligent Spend Manage-
ment and Human Experience Management. It is modular, yet the individual
Network & 
Spend Mgmt
People 
Engagement
Digital Core
Manufacturing 
+ Supply Chain
Customer 
Experience
Intelligent 
Technologies
AI
Machine Learning
Analytics
IoT
Intelligent 
Suite
Digital 
Platform
Cloud Platform
Data 
Management
Fig. 1.2 SAP Vision: Intelligent Enterprise
1.2 Current SAP Software Solutions and Outlook 13
applications are fully integrated. Industry solutions also offer industry-specific
processes and end-to-end scenarios.
2. Business Technology Platform
• The Business Technology Platform is the control centre and the technical
foundation for the Intelligent Suite and supports the conversion of company
data into business values. It comprises database and data management
functions, application development, integration, analytics and intelligent
technologies on-premise and in the cloud. In future, all SAP solutions will
be based on the Business Technology Platform, which means a fundamental
shift away from the attempt to integrate basically independent, vertical soft-
ware stacks towards a common, integrated software stack.
3. Experience Management (XM)
Experience Management enables organisations to focus on four areas: customers,
employees, product and brand. The API integration between XM and the Intelli-
gent Suite provides the link between X-data and O-data.
A shift in emphasis from earlier times is evident. It is no longer just about
productivity gains through standard software but about technologies to help
companies bring innovations faster to market while putting the customer experience
and customer feedback at the heart of business decisions. In doing so, they must not
lose sight of the well-being of their employees and the perception of their own
products and brand. On the contrary, fast reaction to changing customer preferences
and continuous feedback on the customer experience are factors that are becoming
increasingly important and can decide on business success.
1.2.2 SAP S/4HANA: A Slow Seller?
The SAP flagship SAP S/4HANA has not yet been able to achieve its sales targets.
Although SAP now has more than 440,000 customers and 12 million users, SAP
S/4HANA is only used by about 14,000 customers (as of spring 2020). The largest
investment in the company’s history has therefore not yet paid off. The development
of SAP S/4HANA was certainly the right decision: sales are picking up and SAP is
in it for the long haul anyway.
Many existing SAP customers often stick with older SAP software versions for
business-critical applications and are hesitant to use newer products in their central
business processes. In response to pressure from SAP user groups and major
customers, SAP has extended its maintenance commitment for SAP Business
Suite 7 until the end of 2027 (extendable to 2030). SAP S/4HANA will remain in
maintenance until at least 2040. That is an unusually long commitment in the fast-
changing software industry.
SAP S/4HANA: Key to Success
After the major shopping spree of the last decade, SAP has realised what customers
are missing and what may be holding them back from switching to SAP S/4HANA
or the Intelligent Suite:
14 1 Introduction
• Even if things are progressing steadily and the gap is closing, SAP S/4HANA still
does not have the complete functional scope of the SAP Business Suite.
• The SAP S/4HANA data model has been simplified compared to the SAP
Business Suite. This means that existing extensions (investments in the SAP
Business Suite) cannot always be transferred without problems. Expensive
adjustments or new developments may be necessary just to restore the current
functionality on SAP S/4HANA. This potentially incurs high costs but brings
little added value to the business. That is not an easy sell.
• The number of on-premise and cloud products, with partial functional overlaps,
confuses customers with regard to future-proofinvestments.
• The end-to-end mapping of business processes across the various software
offerings has become complex and has so far not always achieved the stability
and resilience that customers are used to from the on-premise world.
• Business issues, especially in hybrid landscapes, bring new challenges, e.g. in
terms of monitoring and consistent backup/restore of business processes across
the landscapes, which run partly on-premise and partly in the cloud.
• The version management of the various SAP cloud and on-premise products
requires careful planning if frequent updates are to be avoided.
When SAP’s new CEO, Christian Klein, replaced long-time SAP CEO Bill
McDermott in October 2019, a strategic reorientation began, focusing on a stable,
easy-to-manage, integrated SAP product portfolio, concentrating on core areas and
paying increased attention to cooperation with partners. Bill McDermott led SAP
into the cloud era; Christian Klein is now consolidating the product portfolio and
structuring it in such a way that it meets customers’ high demands for operability,
planning reliability, integration and stability.
1.2.3 On-Premise or in the Cloud?
SAP continues to see a large market for on-premise software in industries with high
process complexity, such as manufacturing and the automotive industry, where ERP
adaptations are required. This is also true for companies in countries with political
instability, limited infrastructure or increased data security concerns. The introduc-
tion of a public-cloud infrastructure is certainly not possible there in the near future.
Cloud, On-Premise Solution or Both?
Cloud solutions however, are becoming increasingly important in other areas of the
business: human resources, procurement, the front office and customer relationship
management (CRM). SAP will offer modular cloud solutions but also ensure a
strong integration into the ERP core.
Technical integration is one thing—the integration and innovation of business
processes end-to-end is the second important aspect that SAP will focus on.
1.2 Current SAP Software Solutions and Outlook 15
The (Maintenance) End Is Near!
In view of the foreseeable end of maintenance for the classic SAP Business Suite,
more and more customers will have to deal with the topic of introducing SAP
S/4HANA in the core areas of their company in the coming years. This often
resembles open heart surgery and carries many risks. Good preparation, planning
and implementation (usually supported by external consulting experts) are the key
success criteria. On the one hand, one should not start too early, because important
functionalities might not yet be available or at least not mature enough. On the other
hand, one should not start too late, not only because the competition may have a
competitive advantage by innovating earlier, but also because more customers (have
to) start upgrade projects before the end of maintenance, which is getting closer and
closer. This is likely to make it all the more difficult to find well-qualified consulting
support on the market. When is the right time to start the switch to SAP S/4HANA?
This book will help you answer this question.
16 1 Introduction
What Makes an SAP Project So Different? 2
Let us start with a look at the figures: statistically speaking, a considerable number of
IT projects are not successful. A number of studies over the last two decades have
measured the success or failure of IT projects and came to the conclusion that
approx. 40% of the IT projects examined were completed successfully. This
means that budgets were met and the expected functions were made available within
the planned timeframe. About 40% of the projects were completed with restrictions,
and about 20% were cancelled. In other words, less than half of all IT projects are a
success—the vast majority fail partially or completely.
The reasons for the failure of the projects were the lack of involvement of end
users, the lack of clear objectives, insufficient requirements management and lack of
management support. Are we dealing with new findings here? The answer is “no”.
The study confirms our experience from many projects. Interestingly, although these
stumbling blocks are sufficiently well known, the same mistakes are made in projects
again and again.
When you analyse these studies in more detail, it becomes clear very quickly that
many reasons for the (partial) failure of projects lie either in the responsibility or at
least within the sphere of influence of the project manager.
Of course, the success of a project depends on many factors: a successful project
is always the success of a well-functioning team, with sufficient qualification,
motivation, time, management support and a clearly defined scope. But you as a
project manager have a very special role—you are not the leading actor but the
“director”, who makes sure that all “actors” play their parts at the right time.
Even if you already have experience managing IT projects, you will face
completely new challenges in your SAP project. Because SAP projects are different!
But what distinguishes an SAP project from a conventional IT project, such as the
replacement of old hardware with new, more powerful servers or the relocation of IT
Supplementary Information The online version of this chapter (https://doi.org/10.1007/978-3-
030-86084-4_2) contains supplementary material, which is available to authorized users.
# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_2
17
http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-86084-4_2&domain=pdf
https://doi.org/10.1007/978-3-030-86084-4_2#DOI
https://doi.org/10.1007/978-3-030-86084-4_2#DOI
https://doi.org/10.1007/978-3-030-86084-4_2#DOI
infrastructure components to other data centres, to hyperscalers or to the cloud? Is it
the processes that need to be mapped in an ERP system like S/4HANA? Is it the
system architecture, which has become increasingly complex over the past decades?
Is it the way in which the data has to be migrated from the old systems? Is it the
impact on the overall organisation of a company? Five times “yes” to that.
2.1 What Distinguishes IT Projects from Business
Transformation Projects with SAP
Companies today are under increasing pressure to change and optimise their busi-
ness models and processes in order to be successful in global and regional markets. If
they are not already using SAP ERP software, now is a very good time to kick-start
this transformation process. If you have already been using SAP—possibly for many
years—now is also the right time to take the step into the new S/4HANA world:
• S/4HANA, particularly the Intelligent Suite, has reached a good functional level
and is offered in a host of different versions for on-premise and cloud.
• S/4HANA know-how is now available at many consulting companies in suffi-
cient quality and quantities. The demand does not yet exceed the supply of
qualified consultants—this will probably change when the end of mainstream
maintenance of the classic Business Suite is approaching 2027 or at the latest
2030 for extended support.
• An indication that S/4HANA has arrived on the market is shown by surveys of
user groups: SAP customers in the German-speaking countries and in North
America are planning significantly higher investments for S/4HANA in the next
few years. A considerable number intend to tackle the migration in the next
3 years.
From IT Project to Business Transformation
But let’s take a look at the individual types of IT projects first:
Between a pure IT project and a company transformation, e.g. with SAP, there are
different levels in terms of complexity, number of project participants and scope of
changes:
• Pure IT project
In a pure IT project, the focus is on activities such as the replacement of hardware
or a purely technical upgrade. Theproject is mainly implemented by employees
of the IT department. Processes and organisation are not part of the IT project and
usually not affected by it.
• Standardisation/harmonisation
The next stage involves the standardisation of data and transactions. For example,
by standardising customer master and product data in the company, improved
reports and analyses can be made available to the management for corporate
decision-making. Such suggestions for improvement come primarily from the IT
departments; the business departments are involved only as needed. A revision of
18 2 What Makes an SAP Project So Different?
the business processes, however, does not take place, or only to the extent that is
absolutely necessary.
• Optimisation/redesign of business process flows
With the optimisation and redesign of business processes, it is possible, for
example, to handle the entire order process more efficiently. Unnecessary process
steps or system breaks can be removed, with positive effects, e.g. on the delivery
times of products and thus also on customer satisfaction. Such projects are carried
out in close cooperation between IT and business departments.
• Company transformation with SAP standard software
The next stage is characterised by significant changes in business models, pro-
cesses and organisational structures. There is a strong management commitment
to these process changes. The business departments are closely involved in the
project and assume responsibility.
From beginning to end, such a project usually takes years and passes through
various phases: first, there is the recognition by the management that there is a
need for change. Usually this realisation is accompanied by an idea of which
business models are to be implemented with which process flows and
organisational adjustments. Then, a step-by-step plan is drawn up, in which
order and in which timeframe the changeover to SAP software should take
place. One usually starts with less business-critical systems or company areas,
and then, after the team has come together and has a wealth of experience from
the first go-lives, one ventures on to the more critical IT systems.
Affected Business Areas
Which areas are affected by such a transformation project, and what measures are
necessary? The following should be mentioned in particular:
• Optimisation of business processes
The optimisation of business processes is supported by the use of ERP standard
software. This involves redefining cooperation within the company as well as
customer and supplier relationships. The integrated, end-to-end business pro-
cesses, based on common master data, offer enormous potential for productivity
increases and quality improvements.
• Organisational adjustment
The introduction of ERP standard software often leads to changed organisational
structures that are adapted to the new standardised processes and business
models. We strongly recommend that you adopt the preplanned organisational
structures from SAP as much as possible. The more you adapt SAP to your
company organisation, the more you lose many of the advantages of standard
software and pay a high price in the long run.
• Organisational change management
The change processes in corporate transformations are considerable. In order to
strengthen the willingness of stakeholders and employees to change, change
management methods are used to support them. Unfortunately, this area is often
neglected with oftentimes adverse effects on project success. Remember
concerns, fears and resistance within the company that are not taken seriously
2.1 What Distinguishes IT Projects from Business Transformation Projects with SAP 19
can endanger the acceptance of the new software—and thus the success of your
project (more about this in Chap. 5, “The Underestimated Success Factor:
People”).
• Training measures and knowledge
Without education and training, nothing works! With training and knowledge
transfer, employees are enabled to understand and perform their new roles in the
changed system environment. SAP unfortunately does not have the reputation of
being particularly intuitive to use, so you should not underestimate the effort
involved in this area. It is hard to make time for training, despite the day-to-day
demands of the job. But this investment always pays off.
• Cost savings and process improvements
Try to ensure that the whole team identifies with the project objectives and feels
responsible for the changes/savings to be achieved. The ultimate goal is to
achieve productivity gains and therefore cost savings through process
improvements.
The reasons for carrying out a transformation project can be very different:
• You want to set yourself apart from your competitors, for example, by signifi-
cantly reducing the delivery times for your products.
• Your company must adapt to changing market conditions because you want to
operate globally.
• Through acquisitions and/or sales of business units or mergers, you need to make
organisational changes, which in turn require adjustments in your ERP landscape.
• You want to implement cost-cutting programmes and therefore need standardised
and harmonised processes in order to be able to relocate administrative tasks to
more cost-effective locations, for example.
• You want to use new technologies, such as mobile applications, for your sales.
• You plan to make greater use of cloud technologies.
In all these cases, however, there are always major upheavals in the company,
which entail the need to change strategy, process, infrastructure and organisation.
These in turn have a noticeable impact on the corporate culture.
Note: Nothing Works Without Change Management
The changes that the project entails trigger fears and uncertainty among
employees and can disrupt ongoing business operations. Ignoring this can
jeopardise the success of your project.
An SAP project therefore requires the sponsoring of top management to be
able to successfully implement the changes in the company. Change manage-
ment methods that focus on people can be used to support this. Change
management is a separate sub-project within the overall project. Further
information on this topic can be found in Chap. 5, “The Underestimated
Success Factor: People”.
20 2 What Makes an SAP Project So Different?
But tackling an SAP project also offers you the great opportunity to question
traditional procedures and structures; to standardise, simplify and harmonise busi-
ness processes; and to replace an outdated system architecture with modern
technologies. Sponsorship from the highest management level is also necessary to
be able to implement such changes within the company against internal resistance.
With the introduction of S/4HANA, you will receive an integrated, modular and
cross-company standard software with a wide range of functions to realise these
goals.
2.2 Not All Projects Are the Same
SAP Project Characteristics
A project can be described as a wide variety of undertakings: from cleaning up the
basement to building a new airport. However, since our book is about SAP projects,
we would like to use this section to create a common understanding of the
characteristics of a project, what forms of project organisation there are and who is
involved in an SAP project.
2.2.1 What Is a Project?
The term “project” is used today for many different situations in everyday life. For
example, it may involve smaller tasks within a department for which no separate
project organisation is planned or necessary. Larger projects can be pure IT projects
(e.g. the creation of individual software for statistical evaluations), which are
implemented by the IT department, or transformation projects, which require close
cooperation between IT, business departments and management. For all projects,
however, you will have to compete with other projects for scarce resources. There-
fore, a new project needs good arguments to find support both from decision-makers
and the workforce. You need to haveanswers to the questions of what benefits it
brings, what damage it prevents and what business risks it can reduce.
What is a project? A specific task is a project if we are dealing with a complex but
nevertheless clearly defined problem for which there is a goal and a timeframe (start/
end) and which requires cross-departmental or cross-functional cooperation. A
project is usually different from the daily business of a company. In contrast to
regular tasks, a project carries a greater risk of failure and is handled in a project
organisation specially set up for this purpose. At the end of the (hopefully success-
ful) project, the project results are transferred to the standard company organisation
(often called line organisation).
Elements of a Project
In the following two sections, we will briefly present the most important elements in
a project:
2.2 Not All Projects Are the Same 21
• The project charter
• The different types of projects
• The project management systems
• The project organisations
• The different roles in the project
• The project phases
The Project Charter
The project charter is the central document for the project. Make sure that your
project charter contains the elements listed in Table 2.1.
Table 2.1 Example of a project order form/project charter
Project title Introduction of SAP standard software
Project sponsor Dr. James sponsor, managing director, ACME Corp.
Project number SAP 1.35
Project duration • Start: 03/01/2021
• End: 11/30/2021
Reasons for the
project
Heterogeneous processes and heterogeneous IT system architectures stifle
business and make growth in global markets more difficult. Outdated
software inventories lead to rising operating costs
In/out of scope • In scope: sales, distribution and financial processes
• Out of scope: production and personnel processes
Critical
milestones
• Process template developed and target IT architecture defined: 06/30/2021
• Development and tests completed: 09/30/2021
• Production preparations and training completed: 10/30/2021
• Go-live: 11/30/2021
Project resources • 1 project manager (Max Miller)
• 15 project staff full time (PMO, specialist departments, IT)
• 2 external consultants (as required)
Project funding • 16 laptops
• New hardware for implementation
Project budget US$ 1.6 million
Project risks • Lack of qualified personnel
• Overly aggressive implementation timeline
• High complexity
• Changing process requirements
Benefits of the
project
• Harmonisation of process flows
• Replacing old system infrastructure, increasing productivity through
standardisation
• Higher customer satisfaction, reduction of stock
Project
organisation
Pure project organisation
Attachments Statement of work (SOW), rough project plan with milestones
22 2 What Makes an SAP Project So Different?
Note: Templates for Download
All the templates we present in the book can be downloaded free of charge.
2.2.2 What Types of Project Management Are There?
Next, we would like to take a brief look at the different types of project management:
• Multi-Project Management
Multi-project management is characterised by the fact that several projects must
be controlled and coordinated simultaneously. This can lead to resource conflicts
or conflicts of objectives, for example:
– Project A competes with project B for the same employee, a proven expert in
her field.
– While project A imposes a code freeze in the development system to perform
the final integration tests, project B must continue development in the same
system landscape.
Typical examples of multi-project management environments are company-wide
transformation projects, such as SAP projects.
• Program Management
A program is a bundle of related projects with a common objective. As a rule,
individual, related projects are managed. For example, various individual projects
can be combined for the optimisation of warehousing.
• Large-Scale Project Management
In principle, large-scale project management is similar to program management.
Here, sub-projects of a major project are coordinated, such as in the projects “Big
Dig” in Boston or the “California High-Speed Rail”. These two examples alone
illustrate the challenges that large-scale project management can bring with it.
• Project Portfolio Management
Project portfolio management is used to manage a company’s projects, including
those that do not belong together thematically. The task of project portfolio
management is to consolidate key figures of all projects of a company. In this
way, it provides the management with a basis for making decisions on the
prioritisation of tight investment budgets (which project promises the greatest
benefit for the company?) as well as cross-project information on the status of the
total stock of projects. Project portfolio management is a permanent task of all
organisations.
2.2 Not All Projects Are the Same 23
Project Management System
If you want to establish project management in a company, certain basic conditions
are required, which are mapped in the project management system. Many parts of the
project management system are independent of the type of project and concern
general project tasks such as:
• Determine personnel requirements.
• Ensure transparency of the project structure.
• Adjust planning if necessary.
• Create conditions for systematic project monitoring and project controlling.
• Monitor the achievement of the project goals.
Ensure effective, complete and timely communication to all key stakeholders
Other parts are more specific to the type of project, such as clearly defined project
implementation phases or technical requirements identification. A project manage-
ment system helps you to keep your projects under control.
Project Organisation
When we talk about project organisation, we mean the combination of organisational
forms and regulations to handle specific types of projects. You can choose between
several project organisations, depending on the type of project:
• Pure project organisation
Pure project organisation is particularly suitable for large projects that require
cross-company and cross-organisational control, e.g. a large-scale SAP imple-
mentation project. The project goals and timeframe are clearly defined. The
project employees are released for the duration of the project and report to the
project manager. There are clear competences and responsibilities and short
communication channels. One of the possible disadvantages could be problems
with reintegration or with the transfer of the project results to the line
organisation.
Figure 2.1 shows a pure project organisation as it is used for critical transfor-
mation projects such as SAP projects. The project staff from the purchasing, sales,
production and finance departments report to the project manager of project A.
• Functional project organisation
The tasks or the specific project is integrated into the line organisation. This is
usually recommended for less complex tasks. One department assumes responsi-
bility for the project and coordinates with other departments and divisions. The
responsible employee from the leading department has a coordinating task with-
out authority (therefore, he/she is usually not called “project manager” but
“project coordinator”). Employees are usually not fully assigned to the project.
Figure 2.2 shows a functional project organisation for small projects with low
priority. The financial officer responsible for project A has a coordinating role and
no authority to issue instructions.
24 2 What Makes an SAP Project So Different?
• Matrix project organisation
A characteristic feature of this project organisation is the clear structuring of
project tasks, which can also be processed separately. In most cases, these are
projects of small to medium complexity. The knowledge required for the project
is available in the specialist departments. The project manager has a strong formal
position in the company and is responsible for the implementation of theproject.
The employees of the specialist departments have two different reporting paths:
although they are technically assigned to the project manager, their reporting path
remains in the line organisation. Figure 2.3 shows a matrix project organisation
for projects of low to medium complexity.
Func�onal Project Organisa�on
Line Organisa�on
Finance & 
Controlling HR Produc�on
Coordinator
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
Project Coordina�on
PurchasingSales
Fig. 2.2 Functional project organisation
Pure Project Organisa�on
Top Management
Line Organisa�on
Finance & 
Controlling Purchasing
Team 1: 
Finance
Team 2: 
HR
Project
HR Sales Produc�on Team 3: Sales
Team 4: 
Purchasing
Team 5: 
Produc�on
PMO
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
Fig. 2.1 Pure project organisation
2.2 Not All Projects Are the Same 25
• Staff project organisation
In staff project organisations, the project manager has no direct authority to issue
instructions and make decisions. His task is to ensure coordination between the
various functional representatives. The decision-making authority is vested in a
superordinate body, such as the management. The tasks of the project staff
members can be performed independently of each other. The project staff
members are not exclusively released for the project. The project manager has a
high level of professional competence and has a strong position in the company,
usually reporting to executive or even top-level management.
Figure 2.4 shows a staff project organisation for small- to medium-sized
projects. The staff member responsible for project A has a high level of profes-
sional competence and, as he/she is reporting directly to top management, has a
strong position in the company. He has a coordinating task in the project without
formal authority. The project manager derives his power from a superior author-
ity, e.g. the management.
Depending on the corporate culture, however, we very often find mixed forms of
these project organisations in practice.
Note: Make Sure You Use the Right Project Organisation!
Choosing the right type of project management is a decisive factor for the
success of your project. In general, the more disruptive the desired change will
be, the stronger the project management type must be. As a project manager,
you are largely powerless in a line project organisation and merely implement
the specifications of your manager. In a matrix organisation, you as a project
manager have more decision-making powers but are still dependent on the
cooperation of the contributing departments. Since SAP projects can mean
(continued)
Matrix Project Organisa�on
Line Organisa�on
Finance & 
Controlling PurchasingHR Sales Produc�on
Proj. Mgr.
XXX…
XXX…
XXX…
Staff 1
XXX…
XXX…
XXX…
Staff 2
XXX…
XXX…
XXX…
Staff 3
XXX…
XXX…
XXX…
Staff 4
XXX…
XXX…
XXX…
Project Coordina�on
Fig. 2.3 Matrix project organisation
26 2 What Makes an SAP Project So Different?
very large changes for a company, we clearly recommend “pure project
organisation” in most cases. As a project manager, you have your own
employees and your own budget. You have a greater degree of freedom in
making important decisions and setting the course. However, they are still
dependent on the support of the line organisation’s departments and should
therefore closely involve important stakeholders/decision-makers in the proj-
ect. It is advisable to establish a steering committee consisting of
representatives of the line organisation, which regularly evaluates the progress
of the project and makes strategic project decisions. This also facilitates the
handover of the project results to the line organisation at project close.
Staff Project Organisa�on
Top Management
Line Organisa�on
Finance & 
Controlling PurchasingHR Sales Produc�on
Project Manager
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
XXX…
Fig. 2.4 Staff project organisation
2.2 Not All Projects Are the Same 27
2.2.3 Who Is Involved in the Project?
What important roles do we find in projects? We will now introduce you to the
people involved in SAP projects, who will also play a role in the next chapters.
The Project Manager
First of all, we have the project management, which is responsible for operational
project management. That’s right; that’s you! As a project manager, you lead the
project team as well as the specialists (usually called “SME”, subject matter experts)
and manage the operative project processes. The requirement profile for you is
therefore quite demanding. You should of course have experience in project work
and be familiar with the project management tools. Other important requirements are
soft skills, leadership skills, stress resistance and an “eye for the big picture”. Last
but not least, you should have the ability to persuade, possess assertiveness and have
good communication skills.
Quite a tall order? Don’t worry; by the time you have read this book, you will
have sufficiently trained these qualities and come a good deal closer to the ideal
project manager. Nevertheless, project management is like learning to swim—you
don’t learn it by standing at the edge of the pool; you only learn it by jumping into
the water and experiencing it hands-on. To find out what skills a project manager
should have, see Sect. 5.2, “The Importance of Project Management Leads”.
Note: Coaching/Mentoring for Project Managers
Find a coach and/or mentor who will be available to you as a sparring partner
and feedback provider. A coach acts as a neutral, critical discussion partner
who helps you to develop new perspectives and offers suggestions for self-
reflection.
A mentor, on the other hand, is an experienced advisor who supports you
with his/her expertise and personal contacts in dealing with your tasks.
The Project Team
The project team—your task force—should be characterised by a high level of
professional competence, the ability to work in a team and a high degree of self-
discipline and self-management. Give your team time and opportunity to come
together as a team. More information on choosing the right team for your project
can be found in Sect. 5.3.2, “How to Select the Right Employees”. The tasks are
performed within the framework of predefined standards and tools for business
processes and technical infrastructure (see also Chap. 9, “Project Support Tools”).
Monitoring the execution of the project plan is performed by a project office, the
project management office (PMO). You can read more about the ideal structure of
the PMO in Sect. 6.1, “Support Whenever You Need It: The Project Management
Office”.
28 2 What Makes an SAP Project So Different?
The Project Sponsor
The project sponsors for the project are responsible for providing resources, setting
strategic priorities, budget adjustments and, if necessary, setting deadlines. The
sponsors are also represented in the steering committee, which has the final
decision-making authority. A good connection to the sponsor is therefore very
important for you as project manager!
The Business Process Manager
The business process managers who are responsible for partial or total process flows
in the company, e.g. for the entire order processing logistics, can help you to control
the request process. This responsibility is a management task and is usually
performed by upper management hierarchies. You must formally agree to the
catalogue of requirements and the ongoing changes during the project phase (change
control), so make sure they are on board in all project phases! The business process
manager is also the final decision-making authority regarding process issues that
affect his/her area of responsibility.
The Key User
The business process manager issupported by specialists, the key users (SME,
subject matter expert), who are the actual process experts. The business process
manager also has the important task of formally releasing the selected business
scenarios for test activities and approval for production start.
Project Phases
Last but not least, the project is divided into sections, the project phases. Each phase
contains a number of activities with expected results, which are managed and
controlled by the project management. As a rule, project phases end with milestones
or defined exit criteria, the achievement of which is a prerequisite for entering the
next phase. In project management literature, we find different models and
designations for the individual project phases; however, the difference in content
is fairly small. It is always about activities for project preparation, definition,
implementation and control as well as the start of production (“go-live”).
Figure 2.5 gives an overview of the phases of a project. These are reflected in the
Activate methodology used by SAP, the topic of Chap. 3 “The SAP S/4HANA
Project: How It Should Be”.
2.3 Digitalisation in Project Management
Digitalisation means new challenges for project management. In its original form,
digitisation refers to the conversion of analogue values into digital formats and their
processing or storage in digital technical systems. The term “digitalisation”, how-
ever, is used to refer to digital change, the digital revolution or digital transformation,
meaning the increasing adoption of digital technologies. With big data, cloud
2.3 Digitalisation in Project Management 29
computing or even Industrie 4.0 (also called the “Fourth Industrial Revolution”),
artificial intelligence and more complex systems also come into play. Extensive
volumes of data have to be processed and analysed in ever shorter time. Proven
processes and traditional ways of communication are changing.
Digitalisation affects all areas of life, such as the economy, society, work and
private life. For example, 10–15 years ago, it was still unimaginable to monitor the
birth of calves with the help of digital aids. It is now possible to transfer measure-
ment and movement data, such as body temperature, drinking and eating behaviour
from the rumen of the cows directly to a smartphone. For this purpose, the cows
carry a small tracker in their fore stomachs, which transmits all important data to the
farmer. It is a “win-win” situation for the farmer but also for the cow, where the risks
of birth can be reduced by using the tracker! Whereas with analogue processing of
the measured data, the farmer has to note the data on a piece of paper, which is time-
consuming, digitally generated data not only can be captured much faster but also
can be processed, stored and distributed directly. Modern information technologies,
such as smartphones, computers, databases and mobile applications, make this
possible.
2.3.1 How Can Project Management Benefit from Digital
Transformation?
Collaboration
Project management processes can benefit from the use of digital tools in
different ways.
Digital tools have already supported projects in the first decade of the new millen-
nium. Think of central repositories and document stores, or even messengers such as
Microsoft Teams or Slack for easy and fast communication around the globe. Even
then, however, the great challenge was to distribute information in a goal-oriented
manner and not with a watering can. To process hundreds of unnecessary e-mails per
day is not very effective. However, the requirements, especially in large international
1 2 3 4 5 6
Discover Prepare Explore Realise Deploy Run
High-level project
scope, solu�on
selec�on and
project approach
Project ini�a�on,
form project team,
finalize plans and
start the project
Map project scope
to solu�on, perform
fit-gap analysis and
define gap closure
ac�vi�es
Incrementally build
and test integrated
system environment.
Load and validate
legacy data, build
interfaces, plan
opera�ons concept,
train users
Detailed planning
of cutover
ac�vi�es, verify
system and
organiza�on
readiness. Switch
to opera�ons to
new system (go-
live)
Operate landscape,
implement opera�ons
standards to maintain
and improve system
and opera�ons
quality (con�nuous
improvement)
The six Ac�vate Phases
Fig. 2.5 Overview of the SAP Activate project phases
30 2 What Makes an SAP Project So Different?
projects which are becoming more and more complex, are constantly growing. This
makes it all the more important to develop a concept and establish an efficient
structure for the efficient distribution of relevant information. Each project member
should receive the information that he/she really needs for his/her tasks and that is
important to him/her and be spared from receiving (large amounts of) information
that bears no relevance to his job. The focus should not be on a hedging mentality but
on responsible and independent action. Digital tools make it possible to network
project staff and specialist functions in real time using computers and mobile apps.
This can also enable the connection of external partners. Personal responsibility,
teamwork, specialist knowledge and also social and cultural skills, especially in
global teams, are important factors for success. Important decisions can be made
more quickly and with higher quality, thus avoiding costly wrong turns in the
project. Especially in the time of a worldwide coronavirus pandemic, we are
experiencing how online tools can be used to facilitate the daily work in projects.
Project staff working in a home office can work very efficiently with other team
members internationally, calling into question the need for a central project office
location. The current project status can be viewed by all those involved at any time.
Notepads are replaced by to-do lists. Everyone can see which tasks are currently in
progress or already completed. We would like to take a closer look at a few tools in
this context.
• Slack (the name stands for the backronym Searchable Log of All Conversations
and Knowledge), recently acquired by one of SAP’s main competitors Salesforce,
is a collaboration software to support team communication. Teamwork takes
place in so-called channels. Team members can join or leave a channel as
required. Projects or teams can be assigned to a channel. Documents can be
exchanged within the team. The information gets to those employees who really
need it. Endless long e-mail threads with huge distribution lists are a thing of the
past. All messages, documents and tools are visible in one place for everyone in
the channel.
• Microsoft Teams is a competing product to Slack and enables people to work
together on documents in a virtual space, with the emphasis on chat room
functions and video telephony. In addition, other Microsoft 365 products are
integrated, such as Outlook, PowerPoint or SharePoint. The tool can also be used
on smartphones. According to the manufacturer, Microsoft Teams will replace the
popular telephony and chat software Skype for Business “over time”.
• Confluence is a Wiki software used in companies and organisations for commu-
nication and knowledge exchange on the basis of a central platform. The contents
of an online lexicon can not only be read but also be edited.
• MindMeister is a web-based tool on an app that supports the brainstorming
process. Employees who are not in the same room but in the home office, for
example, work via a virtual mind map (instead of flipcharts or similar).
• Trello enables the assignment and management of tasks of a project in so-called
boards with cards. The status of the individual tasks is visible to all team members
via the maps. Each map contains a task, which is provided with descriptions,
2.3 Digitalisation in Project Management 31
deadlines, checklists, attachments and evaluations. Communication via e-mail is
no longer necessary, as the tasks are used to communicate directly with team
members in Trello.A single Trello board provides an overview of all details.
Appointments can be easily set in the calendar view.
• Doodle is the most well-known web-application for scheduling meetings. Every-
one knows how long it can take to coordinate an appointment with all relevant
parties. The employees choose a topic, suggest a date and in a few minutes create
an online survey of all participants. This is much easier and saves time than
tediously coordinating proposed dates with an e-mail or in numerous telephone
calls. It is similar to an online questionnaire, where various selection options can
be clicked on.
• Toggl is a modern time management tool. With the help of the time-tracking
function, you always have an overview of how much time you have spent on
tasks, whether for private or professional matters. You can see the time spent on a
specific project. There are also reports on the time spent at certain time intervals.
• Clickup is a project management tool particularly suitable for internationally
operating teams. It supports the coordination of teams working in different
locations. Priorities for tasks, responsibilities and deadlines can be assigned.
Different tasks can be assigned to different projects.
• Google Drive can be seen as a combination of cloud-based file storage and office
applications such as Google Docs, Sheets, Slides and Forms. Spreadsheets,
presentations or even documents can be created and edited together in the cloud.
• MURAL is a cloud-based digital whiteboard that allows you to share notes,
pictures, drawings, videos, etc. in a virtual team. The goal is to enable collabora-
tive design thinking and collaboration despite different locations, time zones and
working hours.
Monitoring in Daily Project Business
Whereas in earlier projects, quality and progress reviews were usually carried out at
previously defined points in time (e.g. after critical milestones or even after comple-
tion of project phases), today special project management software can be used for
ongoing monitoring. This means that all project staff can access the information
relevant to them at any time. The evaluation of project data with the support of big
data applications enables precise problem analyses. With big data, information from
different sources of the project can be merged into uniform reports that can be
viewed by all project members. Undesirable developments in the project can thus be
recognised at an early stage, and countermeasures can be initiated. Project manage-
ment tasks of the project management offices are supported by digital assistants and
in some cases are completely taken over.
Control of Funds and Resources
Cloud services or software-as-a-service (SaaS) services help to keep project costs
under control. Complex processes can be analysed in detail, and comparable data can
be used for support.
32 2 What Makes an SAP Project So Different?
While the new digital possibilities offer the chance to implement several projects
at the same time, there is also the danger that the quality of the project work will
deteriorate due to too many projects in parallel. This is particularly true for internal
projects. Here, it is important to take countermeasures and find the right balance in
order to avoid resource conflicts within the company. Priority setting with flexible
multi-project management is required here, starting with the question: which project
has the greatest benefit and is implemented first? Sufficient resources are then
allocated to this project. The number of projects is reduced to what is feasible,
according to the motto: “Stop starting and start finishing!”
Digitalisation Competence
Digitalisation competence will be of crucial importance for the future competitive-
ness of companies and countries.
A study of the European Investment Bank (EIB.org) shows that European firms
currently lag behind in adopting digital technologies. Yet, digitalisation is clearly
associated with better firm performance:
Digital firms tend to have higher productivity than non-digital firms, have better manage-
ment practices, be more innovative, grow faster and create higher-paying jobs.
Digital adoption rates in the EU are lower than in the US. Only 66% of manufacturing
firms in the EU, compared to 78% in the US, report having adopted at least one digital
technology. The difference is particularly large in the construction sector, where the share of
digital firms is 40% in the EU and 61% in the US. The difference in adoption rates between
EU and US firms is 13 percentage points in services and 11 percentage points in the
infrastructure sector. When focusing on the share of firms that have fully organised their
business around at least one digital technology, the EU is lagging in particular in the
construction sector (5% compared to 17% in the US) and the infrastructure sector (15%
compared to 20% in the US).
2.3.2 From Classical Project Management to Agile Processes
(Methods)
It is therefore no surprise that digitisation is also changing the processes and
procedures in IT project management. The effects concern not only the project
managers but also the project teams and the entire approach to a project. Decisions
can no longer be made by a project manager alone. Experts from the various
corporate divisions must be involved as advisory bodies. We see a trend in many
companies to avoid large projects if possible and instead carry out a larger number of
smaller, time-limited projects: long-term projects with fixed objectives become the
exception. The scope is becoming dynamic. Sub-objectives are dynamically adapted
to new challenges during the project duration. Classical project management
methods, such as the waterfall method, are supplemented by agile procedures.
2.3 Digitalisation in Project Management 33
http://eib.org
Manifesto for Agile Software Development
The term “agile” was already used in software development in the early 1990s. In
February 2001, 17 IT experts then formulated the “Manifesto for Agile Software
Development” with the following principles, which are still valid today:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
The thought patterns of information technology form the basis here. A problem is
approached in a structured way and from a logical perspective. Complex topics are
broken down into individual parts and reduced to core elements. Through abstrac-
tion, the problem is viewed holistically and led to the solutions step by step. The
results of partial, hands-on tests are the basis for the next steps. Each step is reflected
in the teams, and possible improvements are implemented immediately.
Scrum
A good example of this is “Scrum”, which has become an established standard for
project management in software developpment. The approach no longer corresponds
to the old model of giving employees precise instructions on how a problem is to be
solved. With Scrum, teams are put together for a task in a cross-functional way. How
the goal will ultimately be achieved is left to the team to figure out. This also means
delegating more responsibility to decentralised pools of experts. It is important to
pay attention to a clear communication structure and rules. The “Scrum” approach is
described in more detail in Sect. 2.3.3, “Hybrid Project Management”.
There are also good examples of this in the automotive industry. At Daimler, for
example, project management for product development has been transferred to a
so-called swarm organisation. Some of the employees are no longer subject to a rigid
hierarchy but collaborate with one another on specific topics, similar to a startup.
Agile Approaches and Practices
While the agile approach can undoubtedly bring many advantages, it is also worth-
while to look at it from a different angle. The “Swiss Agile Study 2012” (Agile
Software Development in Switzerland, Prof. Martin M.Kropp, FH
Nordwestschweiz, Windisch; Andreas A. Meier, Zurich University of Applied
Sciences, Winterthur) shows in this context interesting results compared to classical
processes in software development.
According to the study, the aspects of software maintenance/extensibility and
software development costs remain unchanged or have deteriorated, in some cases
considerably.
On the other hand, the aspects of the following have improved:
34 2 What Makes an SAP Project So Different?
• Adaptation to changing priorities
• Development processes
• Market readiness
• Consistency between IT and business objectives
• Benefits and visibility of a project
• Team morale
• Requirements management
• Productivity
• Risk management
A company survey from 2011 with approx. 800 people comes to similar results,
with 1/3 of the companies employing between 100 and 1000 employees. The survey
was conducted by the Bremen University of Applied Sciences, Bremerhaven, the
Cologne University of Applied Sciences, ANECON Software Design und Beratung
GmbH, the German Testing Board and the Swiss Testing Board. The result shows
that in principle there is no difference between agile and non-agile developed
software regarding software errors in daily operations.
In summary, there is not one correct approach for all situations! Many projects are
certainly suitable for an agile approach, but this does not mean that the classic project
management method (e.g. the waterfall method) should no longer be used. Classic
project management is characterised by long-term plans and processes. The project
manager distributes the tasks and, in many cases, has the needed expertise. The
situation is different with agile project management. The responsibility lies where
the expertise is. But that does not mean that there are no structures and no leadership
in the agile approach. The Scrum Master is responsible that the team follows the
structures. The “classic” manager does not exist in Scrum!
An interesting approach is the combination of agile and classic techniques in
so-called hybrid project management. We will deal with the details of this method in
the next section.
2.3.3 Hybrid Project Management
The classical approach, using the “waterfall method”, still has its right to exist if the
underlying mechanisms are properly understood. Detailed project documentation is
also helpful for new project members—and of course the organisation taking over
after project completion.
In hybrid project management, the methods of the classical approach are com-
bined with agile elements. The aim is to combine the advantages of both methods in
one project, thus saving time and reducing project costs. In this section, the neces-
sary framework conditions for a functioning “hybrid project management” are
discussed.
2.3 Digitalisation in Project Management 35
Project Goals and Catalogue of Deliverables
First of all, the project objectives and the catalogue of services must be defined by
the project manager, who is responsible for the entire project. The service catalogue
contains elements that are clear (linear processes such as training or marketing) and
elements with a certain degree of uncertainty (nonlinear processes such as software
development). For the linear processes, the waterfall method can be used in princi-
ple; for the nonlinear elements, the agile method is preferred. The project manager
should be able to assign the individual elements to the method that is most suitable in
each case. Last but not least, the project manager should draw up a risk mitigation
plan for both methods as part of the project risk management.
Project Roles
A central aspect of project organisation is the definition of project roles with
associated task areas, decision-making powers and responsibilities. It is important
to define the roles so that there are as few overlaps and gaps as possible. Overlaps
may lead to fights over competence, and if project tasks are not assigned to a project
role, there is a risk that these (possibly critical) tasks will not be performed by
anyone.
The key roles are as follows:
• Product Owner
The product owner can be either the project manager or product manager. He/She
is the link between customers and/or stakeholders and the Sprint Teams and is
responsible for prioritising requirements.
• Scrum Master
The Scrum Master can also be the project manager if he/she is familiar with the
agile processes. He/She leads the sprint meetings and ensures that the time targets
for the individual process steps are met. However, the Scrum Master has no
formal leadership function.
• Sprint Team
The Sprint Team estimates the effort for the tasks at hand and is responsible for
development and testing. Ideally, the Sprint Team, including the product owner
and the Scrum Master, should not be larger than seven people to ensure fast
decision-making processes. The team consists of developers, testers, architects
and technical experts. In addition, it is recommended to include subject matter
experts (SMEs), who understand the business processes and will be the future
users, in the team. Each team member knows the overall goal of the project.
Conclusion
If a process is too complex to use the waterfall method, it is more effective to use the
hybrid approach, which is essentially a combination of the waterfall and agile
approach.
36 2 What Makes an SAP Project So Different?
At the end of the day, the advantages of the hybrid approach are that it offers
greater flexibility in rapidly changing situations. In addition, by detecting errors
earlier in the development cycles, costs can be reduced, and the team can continu-
ously improve during development. Finally, close communication with stakeholders
during development is also beneficial for the acceptance and quality of the project
results.
2.4 Why Software from SAP?
In the following section, we’ll discuss the criteria you should apply and the steps you
should follow when you decide if you want to implement S/4HANA and possibly
other SAP products. These steps and criteria are independent of any particular
software version.
2.4.1 Analysis of the Initial Situation
The IT strategy and the decision for an ERP system based on the strategic
considerations and goals in general guide the future development of the company.
The company strategy and the IT strategy, which form the basis for business
operations and future development, are derived from these. These frameworks
form the foundation, as well as the guardrails, both in terms of content and
organisation, for the SAP project.
Next, we’ll outline how these individual strategies influence the SAP project:
• Corporate strategy
The corporate strategy sets the fundamental frame of reference for all strategic
decisions, including the SAP project. It answers questions regarding the purpose
of the enterprise, how to differentiate from the competition and implicitly “what
not to do”.
• IT strategy
Based on the corporate strategy, the IT strategy defines the implementation of
business processes on an IT platform. The IT strategy may need to be reviewed,
when the corporate strategy is changed or updated.
• ERP strategy
The ERP strategy is an essential part of the IT strategy (alongside, e.g. strategies
for IT security, IT infrastructure and IT operations) and deals with one of the core
components of a corporation’s IT: the selection, implementation, operation and
further development of a company’s ERP solution.
In the following, we show you examples of how a company’s IT and ERP
strategies influence the choice of ERP software.
2.4 Why Software from SAP? 37
2.4.2 Example for Selecting an ERP Software
Let’s assume we are in a globally active company in the service industry with
independently operating national subsidiaries. Over the years, a heterogeneous
software and IT infrastructure landscape has developed within the group, which
drives the overall IT costs in the company to levels that are no longer sustainable.
Identical business processes are supportedin the national companies with different
software solutions. For the most part, these are in-house developments which are
expensive, difficult to integrate and complex to maintain.
Global Consolidation as a Challenge
Each national company has its own IT team, which is responsible for implementing
the requirements from the business departments and for ongoing operations. The
global consolidation of business figures for the monthly, quarterly and annual
financial statements is therefore a nightmare and keeps numerous employees busy
for weeks. There are always cautious approaches to harmonising processes and
systems across countries, but without much of an impact. Killer arguments such as
“Our processes are particularly specific to each country and if we change them we
lose sales” have long been heard by the company management. However, declining
sales, increasing cost pressure and declining profitability are now leading to a rethink
in management.
2.4.3 Review of the Existing System Landscape
To avoid rushing into a strategic decision like this, it is first necessary to carry out an
inventory. Conduct a thorough review of the existing system landscape in order to
find out what improvements can actually be achieved by a new software solution.
Back to our example, “A new broom sweeps clean” is not only an often used but
also a fitting saying. In our project, a change of the chief information officer (CIO),
the head of IT, is intended to turn things around. As a first step, the new CIO,
Mr. Smith, will conduct IT reviews in the national subsidiaries to get a comprehen-
sive picture of the situation: a selection of IT and process specialists from the
company is sent on a mission to examine the IT systems of all the country operations
in detail.
Contents of the Review
The agenda and questions for the reviews are set by the CIO and his team with the
following content:
– Actual system architecture and infrastructure environment
– Ongoing application support of business processes
– IT resource situation
– Total IT costs
– Local IT strategy
38 2 What Makes an SAP Project So Different?
The reviews are carried out with the local IT management, the business process
managers, the finance department and a representative of the local management. The
results of the reviews are sobering: the CIO’s first impression that each country
organisation does its own thing and drives its own process and IT solutions is fully
confirmed. It quickly becomes clear that things cannot go on like this.
The problems in the business development of the national companies also lead to
a realignment of the organisational structures in the company, from a strongly
decentralised to a more centralised form of organisation. This means that
responsibilities and tasks which were previously performed by the national
companies are being transferred to the head office. This is a further piece in the
puzzle on the way to an overall corporate IT strategy. Mr. Smith can convince the
management board that there is a need for action and he is authorised to develop an
overall IT solution for the company.
2.4.4 The Assessment: Conducting an Analysis of the As-Is
Situation
To become competitive again in the global markets, company management takes
several measures. An important step towards achieving this goal is the
standardisation and harmonisation of business processes and systems for all national
companies, which will also reduce infrastructure costs within the company.
Draw Up Specifications
To carry out an analysis of the status quo, a working group consisting of employees
from the head office and the national subsidiaries is set up, which, in an effort to
make those who are affected by the change, part of the change, includes both IT and
process experts. The results of the earlier IT reviews can be used as a basis. In
addition, a functional specification of future requirements is drawn up, which on the
one hand contains the necessary consolidations and centralisation measures and on
the other hand takes into account justified requirements of the national subsidiaries.
At this point in time, some fundamental decisions on how to proceed have already
been made.
Deciding on a Standard Software
The future software solution will no longer be a proprietary custom development but
standard software from a provider with a good reputation on the market. For the final
decision, which standard software is to be used company-wide in the future, the next
step is to define additional selection criteria.
2.4.5 Software Selection Criteria
The first step is to create a shortlist of eligible software providers. To do this, it is first
necessary to determine the technical and functional requirements (i.e. the target
2.4 Why Software from SAP? 39
processes) for the software. This task is performed by the task force team. In this
early phase, it is crucial to clarify to what extent the existing organisational structures
of the group can be mapped in the new ERP system. The company management will
pay particular attention to the price-performance ratio of the software, as this is a
core criterion for the business case.
To determine the extent to which the target processes are covered by the software
in question, the functionality of the software providers must be compared and
evaluated against the existing process specifications. At this point in time, a high-
level comparison of the target processes with the functionality offered by the
provider’s standard software is sufficient. Ideally, this task will be carried out in
cooperation with the consultants of the software providers in question.
Another important aspect is the comparison of the current system architecture
with the target system architecture of the future ERP system. Since this task is very
time-consuming due to the different system architectures in the individual market
units, larger countries are examined first. The aim is to determine which legacy
systems can be replaced and how many new interfaces are required for the new ERP
system.
For the final decision, the team uses the following general selection criteria (see
Table 2.2). These criteria should definitely be taken into account when making your
own software decision, and you should decide how to weigh them. The extent to
which the individual selection criteria are fulfilled is then answered with regard to
SAP S/4HANA.
Draw up a realistic cost-benefit calculation. Proceed in a structured way: first
describe the problem and the proposed solution. If you have several proposed
solutions, evaluate the individual alternatives. Calculate the profitability by compar-
ing the costs and savings. In addition to the hard factors, such as savings on the IT
side through the replacement of old systems, personnel savings on the user side,
costs for hardware purchases or software licences, also take soft factors into account:
possible increases in turnover through higher customer satisfaction. Also, do not
forget to point out the risks for the project. They will become the basis for project
risk management.
Note: High Expectations
Expectations of a rapid return on investment (ROI) in SAP projects are high.
Realistically speaking, success must be viewed in the long term.
Generally speaking, corporate and cross-functional implementations offer
the highest savings potential.
Implementation Cost
In our experience, the implementation costs for the new software are often
underestimated for various reasons, and on the other hand, the savings are often
inflated to get the project off the ground. Once the project has started, the actual costs
become apparent, but that rarely leads to projects being cancelled or stopped (“sunk
cost fallacy”).
40 2 What Makes an SAP Project So Different?
Table 2.2 General selection criteria for ERP software
Criteria Questions
Market position of the supplier • How much experience does the provider have in the
market?
• How long has the supplier been on the market?
• How safe and sustainable is the investment?• How innovative is the supplier?
• Is the supplier globally active or in the countries relevant
for you?
Certifications • Is the supplier certified according to ISO 9001?
• What other industry-relevant certifications are fulfilled?
Cost-benefit analysis/business case • What are the costs for the introduction and operation of
the software?
• What savings can be achieved with the software?
Implementation risks • What were the challenges in the reference customers’
project?
• How long did comparable projects of reference
customers usually take?
• How many existing implementations are there in our
industry?
Stability/performance • Does the software run stable and performant in daily use
at reference customers?
Scalability • Is further growth possible without running the risk of
performance losses?
• Can additional modules be introduced in the future?
• How will this affect the performance in daily operation?
User-friendliness and language
options
• Is the user interface user-friendly?
• In which languages and alphabets is the software
available?
Hotline support/helpdesk • Is there a hotline support, and when is it available?
• Is there an emergency hotline for crisis situations that is
available 24/7?
• Are there service SLAs for restoring operability during
an outage?
Software maintenance/update • How long is the vendor’s mainstream maintenance?
Maintenance should be guaranteed for at least 5–10 years
after a new version is available
• Is an upgrade path available to be able to install newer
software versions without much effort?
• In case of a cloud-based software (SaaS), how often are
updates made available and what is their impact on
operations?
Support for release upgrades Are there special tools available and needed to perform a
release upgrade?
Data security and authorisation
concept
How do you prevent unauthorised changes and access to
data?
Data migration Are there special tools for migrating legacy data?
Functionality/process
harmonisation/standardisation
• How high is the degree of coverage of the software
functionality for the company-specific requirements?
(continued)
2.4 Why Software from SAP? 41
Tip: Exchange of Experience with Like-Minded People
To better assess the implementation risks, you should try to exchange infor-
mation with other customers of the software vendor in your industry, prefera-
bly without any of the software vendor’s representatives present.
Often there are also user groups (such as ASUG, Americas SAP Users’
Group) that can offer assistance.
You should also get future users on board during the software selection
process. For example, arrange software demonstrations (“live demos”) using
practical examples with the supplier. If possible, also take your future users to
reference customers. This is a good opportunity to exchange information from
user to user and to involve your employees in the project at an early stage.
2.4.6 Looking Back: Experiences with the SAP System and Potential
for Improvement
Back to our earlier example, once our task force team has agreed on the selection
criteria, these are assessed according to their relevance. The result is then presented
to the CIO, who is very satisfied with the team’s work.
In addition to these, a number of technical and functional aspects as well as other
criteria are often relevant to management decisions. This was also the case in the
example project presented in this chapter:
Table 2.2 (continued)
Criteria Questions
• What possibilities are there to close any gaps by
extensions or modifications?
IT infrastructure costs • What financial benefits/savings will the uniform system
architecture offer?
• What are the additional costs for upskilling technical
personnel?
Archiving • How can data that is no longer needed in daily business
operations be archived?
Cloud offerings • Can the software be operated cost-effectively in the
cloud?
WRICEF: workflows, reports,
interfaces, conversions, forms
What functional scope does the software offer in the area
of workflows, i.e. partial process automation, report
generation, interface types, data transfer and forms (print
products)?
RPA, AI, blockchain, IoT Which offerings in the areas of robotic process
automation, artificial intelligence, blockchain and Internet
of Things are included/available with the software?
Experience data vs. operational data How can customer experience data be mapped to
operational processes performance?
42 2 What Makes an SAP Project So Different?
• Uniform data model
With the help of a uniform integrated data model, it is possible to make company
group-wide decisions quickly and efficiently. Master data and interface problems
are avoided.
• Improved data quality
Cumbersome and lengthy data consolidation from the legacy systems of individ-
ual national companies is no longer necessary. The quality of the data used for
corporate management has improved significantly.
• Harmonisation of business processes
The group’s business processes are being harmonised worldwide, supporting the
plans to centralise operational units in more cost-effective locations. Customer
satisfaction will be enhanced by the uniform processes, as lead times from receipt
of order to delivery (and ultimately receipt of payment) are substantially reduced.
• Lower infrastructure costs
IT infrastructure costs are considerably reduced by a uniform system architecture.
New business models can be easily supported and implemented. The implemen-
tation risks are relatively low, and the system is stable.
• Usability
Various reference customer visits have shown that the user-friendliness of the
application meets the requirements.
• Investment security
As the ERP market leader, SAP offers the best prerequisites for a long-term
partnership: SAP has been developing business software for 50 years and is one
of the world’s largest software manufacturers with a huge number of successful
implementations in a variety of industries.
Taken from Project Life
In addition to the technical and functional aspects, in our example project, the
expenses and savings calculated in the cost-benefit analysis are once again aligned
with the finance department and the affected functional and departmental managers.
Nonetheless, it is to be expected that the selection of the new ERP software will
lead to passionate discussions at the board meeting. And this is how it happens: the
CIO has invited a technical and functional representative from the task force team to
support the meeting. The meeting agenda includes 60 minutes for this topic—an
ambitious time schedule for a decision that will mean significant changes for the
company and impact its future for years to come.
Green Light for the SAP Project
Thanks to the good preparation of the team, the meeting went as expected: apart from
a few points that were not relevant to the decision, all open questions were answered
satisfactorily. The biggest point of contention is the cost-benefit analysis
calculations, which promise to reach the break-even point only 4 years after the
introduction. At this point, it becomes clear just how important it was to closely
coordinate with the finance department and functional representatives. With good
2.4 Why Software from SAP? 43
arguments, the management board can be convinced that the planned introduction of
standard SAP software within the group is the right way forward: green light for the
SAP project!
Tip: Careful Preparation Is Crucial for Important Decision-Making
Meetings
Our experience is that the outcome of important decision meetings depends
largely on preparation. This includes the preparation of the relevant documents
and, above all, contact/coordination with key decision-makers and
stakeholders before the actual meeting. Only if the proponents and opponents,
as well as their views and concerns, are known in advance is it possible to
compile the materials for the decision meeting in a targeted manner.
Pilots
To minimise the risk, a pilot should precede the worldwide rollout.The CIO will be
responsible for the installation, with the guidance to approach the proposed rollout
dates aggressively and, if possible, to complete the pilot earlier than planned. The
project is thus already under pressure before it has even started. In this difficult
situation, the project management injects a dose of realism and underpins the
top-down deadlines with solid bottom-up planning. If this shows that the planned
introduction dates cannot be met with the best team in the world, a change request is
inevitable. Our recommendation is to tackle this issue, which is unpleasant for all
parties involved, in a timely, constructive and fact-based manner early on and not to
put it off for later.
Retrospective
Following the successful implementation and subsequent worldwide rollout,
13 years have now passed. In summary, it can be said that the expectations have
been largely fulfilled. IT and personnel costs have been reduced; the harmonisation
of global processes has brought considerable progress in productivity; customer
satisfaction, especially from internationally operating customers, has increased; and
sales have risen considerably.
Potential for Improvement
However, when several companies were acquired during the implementation project,
it was not possible to avoid including third-party programs to accommodate the
expanded business portfolio. This increased the complexity and the maintenance
effort. It was discussed if it would make sense to merge several ERP systems into a
new uniform system. The considerable memory requirements of transactional
processing in the various SAP systems increasingly became a problem. For fast
decision-making, real-time data processing is a prerequisite, which is not possible
with the previous systems. In the same way, one would like to take advantage of the
opportunities offered by digitalisation with a future-oriented IT architecture without
losing the previous investments in the SAP systems. A further aspect to be
44 2 What Makes an SAP Project So Different?
considered is the duration of the maintenance commitment from SAP for the existing
SAP system. As things stand today, the maintenance commitment for SAP Business
Suite 7 has been extended from 2025 to the end of 2027 due to considerable pressure
from major customers. A further extension until 2030, an additional cost is possible.
Nevertheless, the journey to SAP S/4HANA will be a major challenge for the
company. Our recommendation is to start this journey in 2021 to be able to exploit
the advantages of the new technology to maintain a competitive edge.
2.5 The Road to SAP S/4HANA
There are different scenarios on the way to S/4 HANA. Many criteria that we have
already considered when introducing a new ERP solution also apply here.
Today, many corporations find themselves in one of two fundamentally different
starting situations.
2.5.1 Your Company Has Been Using SAP for Years
For a great number of customers, the first wave of transformation, process and
organisation optimisation, which took place within the framework of the SAP
introduction, is already “water under the bridge”. They have already mastered the
fundamental business transformation which went hand in hand with the introduction
of SAP (ERP/Business Suite) years or even decades ago. The business departments
now have in-depth SAP process know-how, and in the IT department, years of SAP
operating experience are available. The challenge for you is you have already been
using your SAP software for years or even decades and have successively adapted it
to your requirements. What, besides the looming end of mainstream maintenance, is
the business case for S/4HANA?
After the initial introduction, functional enhancements were implemented in the
following years either on your own or with the support of partners (whose experts are
usually no longer available). The list of extensions—and in the worst case
modifications—has become longer and longer, so today hardly anyone understands
it all. In many companies that have been using SAP for years, SAP systems resemble
an onion with many layers: changing business requirements lead to numerous
extension and adaptation projects over the years. Many are successful, others less
so, but all leave their (development) traces in the system landscapes. The documen-
tation is partly available, partly outdated but often incomplete. A distinction between
“this is needed” and “this needs to be cleaned up” is difficult, and therefore, calls for
consolidation projects are unsuccessful. For lack of demonstrable business benefit,
these projects are a “hard sell” to the management within the company anyway. The
main thing is that the systems work.
Rising Operating Costs
But the operating costs for this grown system landscape are increasing: every new
release requires extensive testing, as the effects on other areas can no longer be
2.5 The Road to SAP S/4HANA 45
reliably estimated in advance. Checking and adapting to extensions and
modifications costs a lot of time and money.
“Never change a running system” is the motto, but the clock is ticking. Older SAP
software versions run out of support, S/4HANA and cloud offers from SAP beckon
with new functionalities and potential cost savings. Perhaps the competition is faster
and achieves competitive advantages by using new solutions. The change from SAP
ERP/Business Suite to S/4HANA offers the opportunity to use the new in-memory
architecture to design completely new, considerably more efficient processes and
possibilities for your own company. The key question is how to make the switch to
this fundamental new technology: clean cut or evolutionary development? What
moves to the cloud? What remains on-premise?
Analysis of Existing Processes
The possibilities of digitalisation, the use of artificial intelligence (AI) in companies
and the increasing competitive pressure in a global market environment require a
detailed analysis of existing processes.
The following questions should be asked:
• Can I develop new business areas with my existing processes?
• Do I need to harmonise my business process?
• What about my IT system landscape?
• Is all the data I need for business management on a uniform system, or is the data
managed in different, disjointed systems?
• Is it possible to process large amounts of data in real time?
• Has the IT infrastructure that has grown over the years, become too complex and
expensive to operate?
• Can I react quickly to changes in the market with my existing processes and
systems?
• How long is the maintenance of my existing SAP infrastructure still guaranteed
by the manufacturer?
If you have already dealt with some of these questions or can answer some of them
with “yes”, it makes sense to consider the advantages of SAP S/4HANA technology.
Whether it is a new SAP implementation, a conversion of an existing SAP ERP
system to SAP S/4HANA or a consolidation of several SAP ERP systems into “one”
SAP S/4HANA system, the same principle applies to all scenarios: we are dealing
with a transformation project that has to be located at the highest level in the
company. For both variants, this is the opportunity to adapt the old processes as
far as possible to the standard of the new, simplified S/4HANA processes. A new
implementation may also make sense in an existing SAP landscape, but you must
weigh carefully whether such a path is the right one.
46 2 What Makes an SAP Project So Different?
2.5.2 Your Company Is About to Introduce SAP for the First Time
Over the years, SAP has achieved enormous market penetration. Today’s net new
SAP customers are usually relatively young companies that have grown steadily in
recent years and are now reaching the limits of their existing IT systems. SAP, as the
world market leader for business software, is usually introduced to replace a whole
slew of smaller IT solutions and thus enable further growth. Problems with different
master data, system breaks and a multitude of interfaces make life difficultfor these
companies. They are concerned with standardising their IT landscape, eliminating
island solutions, reducing IT costs and using new technologies. The IT landscape has
not kept pace with the rapid development of the company and is in dire need to be
transformed from a millstone around the company’s neck into an innovation driver
and “enabler” for new offers and services.
These young, dynamic companies are very open to cloud solutions but soon find
that their requirements for business software in the cloud cannot be mapped as easily
as an office package in the cloud. Understanding the complexity of SAP software
and the breadth of its offerings and being able to assess what you actually need are
serious challenges. You can expect a relatively steep learning curve, as staff usually
lack SAP solution architects, i.e. experts with broad and detailed SAP know-how
who can translate business requirements into a flexible, cost-effective and future-
proof IT strategy. This kind of expertise usually needs to be brought in for the
development and implementation. Having an experienced solution architect, who
designs the SAP solution, is a key success factor.
Even at this early stage, the question arises: do you ultimately operate your SAP
solution yourself? Do you turn to a hosting partner or one of SAP’s PaaS or SaaS
offerings? Or do you try to use cloud products as much as possible to keep your IT
expenditure low? After all, S/4HANA offers all these variants.
2.5.3 SAP S/4HANA Usage Models
The first question is how to operate SAP S/4HANA in the future. In the following
section, we will discuss the different usage models for S/4HANA operation in more
detail (see Table 2.3).
Table 2.3 SAP S/4HANA usage models
Deployment Product Name License
On Premise S/4HANA on Premise Perpetual Licensing
SAP’s PaaS Cloud (HANA
Enterprise Cloud)
S/4HANA on Premise Bring your own License
(BYOL)
S/4HANA PCE (Private
Cloud Edition)
Subscription
S/4HANA Cloud, extended
edition
Subscription
SAP’s SaaS Cloud S/4HANA Cloud Subscription
2.5 The Road to SAP S/4HANA 47
S/4HANA On-Premise System (Local Approach)
SAP S/4HANA on-premise is the new Intelligent Suite based on the in-memory
database HANA. In this model, operations run in the company’s own data centre and
on its own servers or are operated by an infrastructure/application hosting provider.
The entire IT infrastructure, such as hardware, applications, operating system,
middleware, network and HANA database, is managed by the customer or the
hosting provider. The control over upgrades, customising and necessary
enhancements remains in the company. The company decides on the frequency
and schedule of software upgrades and support packages, within the maintenance
framework given by SAP. However, this option is also time- and cost-intensive and
requires trained IT personnel. We recommend this option for the following:
• Industries with high process complexity
Industries with high process complexity, such as manufacturing (discrete
industries) and the automotive industry. Often numerous adjustments are
unavoidable and can be implemented most easily in the S/4HANA on-premise
variant.
• Countries with limited IT infrastructure
Here, it is usually not possible to set up reliable data lines with the required
bandwidth to the data centre.
• Customers with very high data security requirements
Customers with very high data security requirements, such as intelligence
services, defence and public security or customers in a country where data
security is limited.
Companies to which these special circumstances do not apply, have the option of
switching to a combination of on-premise offering and IaaS or private cloud (PaaS)
or even to purely cloud-based SAP S/4HANA versions.
SAP S/4HANA as On-Premise Version in the IaaS Cloud
This variant of operating the SAP S/4HANA on-premise is offered, e.g. by
Hyperscalers, among others (SAP itself offers this only in exceptional cases).
Customers save the investment in infrastructure, server and network but still retain
full control over the landscape. From the provider’s point of view, an IaaS cloud is a
“black box”, i.e. topics such as monitoring, backup/restore, etc. are only offered in a
very rudimentary form, if at all. Everything that goes beyond basic availability
monitoring and restores to a delivery state remains usually the responsibility of the
customer.
SAP S/4HANA as On-Premise Version in the Private Cloud
Platform as a Service (PaaS)
The SAP S/4HANA on-premise version can also be operated in a “private cloud”
environment. In this case, the customer-specific system landscape runs in the SAP
HANA Enterprise Cloud (HEC), which is part of SAP’s Enterprise Cloud Services
organisation. This option was developed by SAP to facilitate the implementation of
48 2 What Makes an SAP Project So Different?
SAP S/4HANA for customers. It emulates an on-premise environment in a cloud
environment. The service is delivered as an SAPManaged Service based on a private
cloud infrastructure.
In this case, servers and hardware are provided by SAP—either in its own data
centres or partner data centres—or at a hyperscaler (Microsoft Azure, Amazon Web
Services, Google). The system landscape is managed by SAP, and the applications
are operated by SAP’s own global IT teams. The standard contracts include 24/7
operation of the landscapes with SLAs (Service Level Agreement) between 95%
and 99.9% and the provision of infrastructure-related services. Depending on
requirements, additional services from the areas of basis and application manage-
ment can be purchased in this model.
Users of the SAP-HANA Enterprise Cloud pay a monthly rate that varies
depending on the size of the system landscapes and the agreed SLA. EU-only
team support can be provided for an additional charge to ensure EU-data protection
regulations are met. The offer comprises two contract types:
Bring-your-own-license
(BYOL)
Customers use the (usually existing) software licences in the cloud
This means that they pay a one-time license fee as
well as an additional annual, percentage-based
software maintenance fee
Subscription Customers acquire the usage rights as a “bundle”
together with the infrastructure service. The one-
time license fee and the software
maintenance fee are included in this subscription
Note: Special Maintenance Clauses in Some Subscription Models
Subscription models are attractive: they relieve the cash flow because the
one-off, cost-intensive purchase of licences is no longer necessary. They are
predictable cost blocks, since the “rent” must be paid at regular intervals. But
pay attention to the small print:
• Any changes to the contract (Commercial Change Requests) during the
term of the contract require—as with any other contract—the agreement of
both parties. SAP does not normally accept “negative CRs”, i.e. changes
that would reduce the monthly fee.
• The subscription model includes the usage fee, infrastructure, operating
costs and software maintenance. Should you decide to switch back to
BYOL at a later date, SAP will still require you to pay the maintenance
fee for the subscription period. Together with the licence fees then incurred,
this can result in a very considerable sum.
2.5 The Road to SAP S/4HANA 49
Mainstream Maintenance
The customers commit to operate only software versions that are in SAP mainte-
nance (mainstream maintenance) in this PaaS environment. In addition, there is no
obligation (unlike the following offers) to regularly install newer software versions,
but there are limitations regarding OS (Linux only) and the database (SAP HANA or
ASE—Adaptive Server Enterprise—a relational database acquired from Sybase).
This has several advantages:
– Standardisation of the infrastructure stack (DB + OS) while retaining the familiar
user interface and any extensions
– Cost reduction potential through the subscription models offered (“software
rental”)
– Possible savings on own IT personnel
– Easy extension with otherSAP cloud offerings
– Possibility to have the entire software stack, from infrastructure to application
management, operated by SAP
But the disadvantages must also be taken into account:
– No customer access to operating system allowed.
– Limited flexibility: Detailed description of the tasks to be performed is neces-
sary—lead times for service requests are between a few hours (for automated
services like system restart) and 6 days for highly complex ones.
– Limited possibilities of operating third-party (non-SAP) software.
– Customers still need their own SAP experts as contact persons for SAP.
SAP HANA Enterprise Cloud
The SAP HANA Enterprise Cloud was originally intended as an intermediate step
for customers planning to move from SAP Business Suite on-premise to SAP
S/4HANA in the cloud. Since the changeover from SAP Business Suite to SAP
S/4HANA is a very big step for many customers, SAP offers assistance through the
SAP HANA Enterprise Cloud: the technological stack is standardised (Linux and
SAP HANA only), the end users retain their familiar user interfaces and processes,
and the customer’s IT department is relieved of operational issues.
Due to the great commercial success of the SAP HANA Enterprise Cloud, the
offer was extended to include SAP S/4HANA Cloud, Extended Edition. The
contracts differ in some areas from the classic SAP HANA Enterprise Cloud
contracts, but the delivery model is the same.
SAP S/4HANA Private Cloud Edition:
The S/4HANA PCE is a new offering, introduced in late 2020, which aims to make it
easier for customers currently running SAP ERP on-premise versions to move to
S/4HANA.
50 2 What Makes an SAP Project So Different?
It is a private managed cloud offering (PaaS), which offers an extension of the
customer’s private network and integration into his private DNS and runs in SAP’s
data centres, or on hyperscaler. The migration can be performed by SAP or partners
and the rules for modifications and extensions the same as in the S/4HANA
on-premise solution. In terms of functionality, S/4HANA PCE is also identical to
S/4HANA on premise and offers the same relaxed upgrade requirements: customers
must remain within SAP’s mainstream maintenance period and can choose to
upgrade at any time within this framework.
SAP S/4HANA Cloud, Extended Edition:
The S/4HANA Cloud EE differs from the on-premise version in three main points:
• Modifications are not possible (but extensions are).
• SAP offers updates twice a year; customers must install at least one update
per year.
• The Extended Edition can only be used in SAP’s own cloud services.
The S/4HANA Cloud Extended Edition can be used in the same way as the
on-premise solution in the PaaS cloud (SAP HEC) but only in the subscription
model.
The advantages for this option (in addition to those already mentioned above) are
as follows:
• Customers can adopt and use the latest SAP technologies promptly.
• The SAP enhancement model allows many possibilities to customise the software
according to individual needs.
But the disadvantage is that updates must be installed within the defined period of
time—which causes expenses on the customer side. However, it can be assumed that
the effort will be kept within limits, as there can be no modifications whatsoever.
SAP S/4HANA Cloud, Essential Edition
Software as a Service from SAP (SaaS)
SAP S/4HANA Cloud is the only true “SAP SaaS version” (software as a service)
of S/4HANA. It is the only S/4HANA variant with “one code line”, i.e. all customers
use the same program code. The resource-intensive maintenance of different
versions for SAP is thereby eliminated. Updates are automatically imported into
all customer systems every quarter. Customising is only possible to a very limited
extent. Extensions are possible (via BAdI, business add-ins); in addition, there are
the functionalities in-app extensibility and “side-by-side development” in the SAP
Business Technology Platform. These extension possibilities are the fundamentally
new concept of SAP S/4HANA Cloud. Enhancements cannot—as in the past—be
mapped in the ERP software but only via extensions outside SAP S/4HANA. Thus,
the core of the ERP solution always remains in the standard, massively reducing
upgrade efforts.
2.5 The Road to SAP S/4HANA 51
In-App Extensibility:
In-app extensibility is a simple way to customise screen masks (e.g. hide fields),
create new tables and fields and store them with process logic. Deep technical know-
how is not required, so experienced end users (power users, key users) can create
these extensions themselves.
Side-by-Side Development:
Side-by-side development is the method of choice for complex development
projects. SAP offers an SAP S/4HANA Cloud SDK (software development kit),
which, in conjunction with the SAP Cloud Platform, enables time- and cost-
transparent development of complex apps. By using open APIs (application pro-
gramming interfaces) and CDS views (core data services, a method of data
modelling for the definition of customer-specific “views”), which are provided via
OData services (Open Data Protocol), it is possible to develop apps that remain
usable and unchanged despite quarterly SAP S/4HANA updates.
Further Advantages:
Users can use a large part of the S/4HANA functions without the hardware,
databases or IT staff required for the local version. In the S/4HANA Cloud, SAP
provides and manages almost the entire infrastructure for the customer. However,
the flexibility for process adjustments and requirements is less than with the
on-premise version. Compared to on-premise, implementation is faster because a
fully tested cloud version is provided by the manufacturer on a ready-made platform.
The use of S/4HANA Cloud Essentials requires a fundamental change in
approach. There is no longer a familiar development environment, and there is no
access to the backend. Business processes have to adapt to the given standard. At the
same time, the import of new software versions is effortless (compared to the
on-premise version), as it is a pure standard system. Extensions are only possible
to a limited extent within the S/4HANA system—instead using the abovementioned
extension possibilities in connection with the SAP Business Technology Platform.
Conclusion: On-Premise Versus Cloud Version
The SAP S/4HANA on-premise variant is best suited for companies that require the
full range of functions with a high degree of flexibility for customisation and—if
necessary—modification. As a rule, these are larger companies with complex, firmly
established processes or legal requirements that are currently not addressable via
SAP’s standard process framework.
The SAP S/4HANA Cloud variant is particularly suitable for companies that
require an agile offering that covers the most important business processes and
allows a fast innovation cycle. However, customer-specific changes are not possible.
Keep in mind that the infrastructure costs of a cloud solution are in most cases lower
than those of an on-premise solution, where ongoing maintenance and
modernisation costs must also be taken into account. With a cloud solution,
52 2 What Makes an SAP Project So Different?
companies also benefit from the latest technologies and timely innovations devel-
oped by SAP.
Hybrid Approach:
A combination of both variants is also possible. In this case, we speak of a hybrid
approach. Important business processes or core processes can continue to run on
local servers (on-premise), while other standard processes, such as payroll, can be
operated in the cloud. Here, the SAP Cloud Platform acts as a central “data hub” in
the system network.
Multi-Cloud:
Finally, there is also the possibility of bundling solutions and offers from various
cloud providers under a common roof. This is called a multi-cloud, where, for
example, the network infrastructure and applications can come from different
providers. SAP has entered into strategic partnerships with cloud providers such as
Amazon Web Services (AWS),Google Cloud Platform (GCP) and Microsoft Azure.
Data Security for On-Premise and Cloud:
When deciding on a cloud solution, data security aspects are also relevant for many
companies. Initially, the on-premise solution appears to be the safer option compared
to the cloud solution. However, on closer inspection, it must be noted that even an
on-premise solution is not protected against cybercrime activities. Especially smaller
companies often lack the know-how to protect themselves effectively against hacker
attacks. On the other hand, cloud solutions today must meet the highest industry
standards. These include security aspects such as external audits, data protection and
data security, user management and “best practices” for data centre operations.
Using SAP S/4HANA Cloud is certainly the most innovative way to break with
traditional approaches. At the same time, it opens fascinating opportunities to rethink
ERP software.
One example is the possibility of the “Customer Influence Ticket”: customers can
use it to request new functionality, and other customers can vote on whether they
also consider this functionality to be useful and want to see it developed. If an idea
receives sufficient support, it is put on SAP’s development roadmap.
We strongly recommend taking a closer look at S/4HANA Cloud, Essentials
Edition, when deciding which S/4HANA Version is right for you. Maybe it is only
suitable for a part of your business processes or your organisation, but in these areas,
you can benefit significantly from the enormous advantages of this new type of ERP
software.
Rise with SAP Initiative:
In early 2021, SAP announced the “Rise with SAP” initiative which bundles a
number of products and services in one package. The goal is to simplify the portfolio
for customers, as well as giving an incentive to move to S/4HANA and consume
SAP’s cloud service offerings like Asset Intelligence, Ariba, BTP, etc.
2.5 The Road to SAP S/4HANA 53
Rise with SAP contains the following:
• Either SAP S/4HANA Cloud or SAP S/4HANA PCE
• Tools and Services like S/4HANA Readiness Check and Custom Code Analyser
• A small annual credit for SAP’s Business Technology Platform
• SAP Business Process Intelligence Discovery Reports to benchmark customer
processes
• SAP Business Network “Starter Pack” which contains access to the Ariba Net-
work, Asset Intelligence Network and Logistics Business Network
2.5.4 What Is the Right Approach for Moving to SAP S/4HANA:
Greenfield Versus Brownfield Versus Selective Data
Transition
There are three ways to introduce S/4HANA (see Fig. 2.6). A greenfield installation
is a new installation of an SAP S/4HANA system. The system is unconfigured and
does not contain any data—customising, enhancements, data load, etc. will follow.
In a brownfield installation, however, a new system is set up based on an existing
SAP system. During a migration project, customising, data, authorisations, etc. are
transferred from the source system. This is called system conversion.
In a Selective Data Transition Project, data, customising and enhancements from
one or more source systems are selectively migrated to the S/4HANA target system.
There are some points to consider before making the decision for Greenfield or
Brownfield:
System Conversion 
(Brownfield)
New Implementa�on
(Greenfield)
Selec�ve Data Transi�on
(Landscape Transforma�on)
SAP ERP
System
S4 On Premise
SAP PaaS 
Cloud (HEC)
SAP ERP or 
3rd party
System
S4 On Premise
SAP PaaS Cloud 
(HEC)
S/4HANA Cloud
SAP ERP 
Region A
SAP ERP 
Region B
SAP ERP 
Region C
S4 On Premise
SAP PaaS 
Cloud (HEC)
S/4HANA
S/4HANA
S/4HANA
Fig. 2.6 The road to SAP S/4HANA
54 2 What Makes an SAP Project So Different?
• Are your current business processes appropriate for your long-term business
goals?
• If “yes”, you may want to go for a conversion, since the existing process
configurations are largely adopted.
• Can you significantly improve your business processes by adopting SAP best
practices or the SAP model company?
• If “yes”, this suggests a Greenfield approach, which offers the possibility to
reconfigure and redesign business processes.
• Do you want to consolidate your system landscape(s) at the same time during the
S/4HANA implementation?
• If “yes”, this suggests a Greenfield approach or a selective data transition, because
you can consolidate source data from multiple systems into a new S/4HANA
system.
• Do you want to transfer existing transactional data to the S/4HANA target
system? This is possible with Brownfield as well as with Greenfield but more
complex with the Greenfield approach.
There is no one-size fits-all SAP S/4HANA. The decision for a Greenfield or
Brownfield approach, or even selective data transition, has to be made based on the
respective circumstances.
Greenfield Approach
“Greenfield” means a new implementation of the SAP system(s). The business
processes are remodelled, and the data from the legacy systems is transferred as if
the source was a legacy (i.e. non-SAP) system. The existing production system can
continue to operate in parallel while this strategy is implemented.
However, do not underestimate the efforts for customising, developing
enhancements and data migration. Many customers who choose the Greenfield
approach also opt for the SAP “Model Company” to cut down on customising
time. For more information on the Model Company, see Sect. 3.7.3.
For SAP customers, who are migrating from a previous SAP version to
S/4HANA, this method makes sense if it is possible to largely adapt the business
processes to be newly modelled to the specified standard of S/4HANA and cut out
the dead wood.
In many companies that have been using SAP for years, time and again the
standard SAP processes have been adapted individually to new business
requirements. Takeovers and strong growth in many internationally active
companies have also contributed to a heterogeneous IT system architecture and
complex business processes. Many companies run several SAP systems side by
side, which could possibly be consolidated to save maintenance and other costs.
A very detailed examination of the business processes and the system architecture
“end to end”, including the processes in non-SAP systems, is mandatory to get the
necessary information for a sound decision. It is recommended to involve SAP or
experienced external partners directly for this task. First, process experts create an
2.5 The Road to SAP S/4HANA 55
overall picture of the currently implemented processes before going into the process
details:
• Which processes are used?
• Which extensions of process logic and data structures have been implemented?
This information is compared with the SAP standard process and data model to
get a picture of the expected effort.
Master and Transaction Data
If the Greenfield strategy is applied, the master and transaction data from the legacy
systems can be transferred to the new S/4HANA system using data migration tools
(e.g. SAP S/4HANA Migration Cockpit). It is important to transfer updated and
cleansed standardised datasets to avoid data issues down the road; data quality has
top priority here! Just as this principle applies to the initial transfer of data from a
non-SAP system to an SAP ERP system, the same applies to the transfer of data from
SAP to SAP systems. Unfortunately, data migration is the one area where many
projects spend too little time and resources to ensure the quality is good—and the
company pays a high price later.
What happens with customising? Ideally, SAP’s collection of best practices or the
SAP Model Company can be used for support. In this case, a large part of the
customising is already preset. It should be noted here that the use of the Model
Company means additional costs. Whether you then decide on a big bang (i.e. a
simultaneous go-live of all SAP landscapes) or a multistage implementation depends
mainly on the complexity of the migration and the associated risk assessment. We
generally adviseagainst a big bang approach unless there is no way around it.
With the Greenfield approach, it is possible to free oneself from legacy problems
and at the same time take advantage of the additional new functionality. During the
migration to S/4HANA, the existing SAP system will continue to run. This reduces
the project risk for the new implementation. However, speed is of the essence for the
new implementation project because the source systems will continue to change
during the implementation project as the business develops. These changes must be
captured and considered during the implementation of the new S/4HANA system.
The standardisation of the systems reduces the costs for maintenance and updates.
Overall, however, the project effort, such as testing the new processes during a new
implementation and migrating the data, is higher than for a system conversion
(Brownfield). In addition, the increased effort and costs for operating the existing
SAP system landscapes and the new Greenfield landscapes should not be
underestimated. Especially medium-sized companies with limited IT resources
quickly reach their limits here.
Brownfield Approach (System Conversion)
In the context of a Brownfield implementation, the existing SAP system(s) serve
(s) as the source for a technical migration (called S/4HANA conversion). This
56 2 What Makes an SAP Project So Different?
involves a simultaneous upgrade (to the new S/4HANA release) and change (con-
version) of the data structures.
Some technical requirements have to be met:
• The source system should already be a Unicode system. If this is not the case, a
Unicode conversion must first be performed. Non-Unicode systems are rare;
therefore, this is not an issue in most cases.
• Dual-stack systems (ABAP + Java) are not supported. If the source system is a
dual-stack system, a dual-stack split must be performed first.
• The ERP system must be at least ECC 6.0.
• OS and DB booths must also meet the minimum requirements before the conver-
sion can start. SAP has created notes with detailed information.
The Readiness Check
The freely available SAP Readiness Check for SAP S/4HANA (https://help.sap.
com/viewer/p/SAP_READINESS_CHECK) consists of several tools that examine
the source system and provide information about the expected conversion efforts and
activities. It includes an interactive dashboard that displays the results:
• Consistency Check results
• Categorisation of the results into mandatory and optional
• Indication which tasks must be done before the project starts and which can be
implemented during the project
• System sizing recommendations and additional information for sizing calculation
• Information about add-on compatibility and third-party add-ons
• Information about BW extractors and unsupported (black-listed) IDoc interfaces
Maintenance Planner
As part of the Readiness Check for SAP S/4HANA, SAP offers the Maintenance
Planner, a tool that checks the source system for activated business functions,
industry solutions and add-ons. If a conversion is not possible, the Maintenance
Planner indicates this. Incompatibilities occur mainly with third-party add-ons—in
this case, the manufacturer must provide a new version, or the add-on must be
removed.
Simplification Item Catalogue and Simplification Item Check
With S/4HANA, SAP has introduced a variety of simplifications in data structures
and processes. Simply put, these are major changes in the code that lead to
incompatibilities with previous versions. An extensive, version-specific list of the
affected objects can be found in the Simplification Item Catalog at https://launchpad.
support.sap.com/#sic
2.5 The Road to SAP S/4HANA 57
https://help.sap.com/viewer/p/SAP_READINESS_CHECK
https://help.sap.com/viewer/p/SAP_READINESS_CHECK
https://launchpad.support.sap.com/#sic
https://launchpad.support.sap.com/#sic
The Simplification Item Catalog contains not only descriptions of the objects but
also information about the necessary activities in the respective project phases to
implement these simplifications.
As of 2019, the SAP Readiness Check contains the simplification check, meaning
you see the list of items which need simplification (i.e. manual adjustments) when
you run the SAP Readiness Check.
To avoid searching through these objects by hand, there is the report Simplifica-
tion Item Check for SAP S/4HANA, which should be executed as early as possible
in the migration project (or even before the project start). The result of the report
provides information about the effort required for the needed adjustments.
Custom Code Analysis
The custom code analysis examines whether there are customer developments that
are not compatible with S/4HANA. With the help of the UPL (Usage Procedure
Logging) and the ABAP Call Monitor, it can be determined whether this custom
code is actively being used or is just lying dormant in the system. If it is in use by
business processes, it must be updated, or it won’t work in S/4HANA.
Incompatibilities mainly affect Native SQL statements in the customer ABAP
code (which should not exist in the first place) and pool/cluster tables in customer
namespace—these no longer exist in SAP S/4HANA. (Standard) pool/cluster tables
created by SAP are automatically converted into transparent tables during the
conversion.
Experience has shown that about 30% of incompatible custom code is not used,
i.e. this code can be deleted during the conversion project. 60% of the
incompatibilities can be fixed by largely automated “quick fixes”, and about 10%
must be adjusted manually.
With the Brownfield strategy, existing processes (unless they had to be adapted
for compatibility reasons) are transferred to the S/4HANA system as is. This is
particularly advantageous if the processes largely meet current requirements. The
project duration is therefore usually shorter compared to a new implementation.
However, it can be assumed that the full potential of the S/4HANA functionality
cannot be exploited with this approach and that the system complexity is not
significantly reduced. On the other hand, change management activities, such as
training, can be estimated to be lower compared to the Greenfield approach. Existing
in-house developments that are important for the business processes can be taken
over. Since the existing legacy data is also migrated automatically, proactive cleans-
ing and updating of the data is not only recommended but absolutely necessary. As
always, the rule is “garbage in—garbage out”.
Success Factors for a System Conversion
From a project management perspective, the following success factors,
recommendations and planning approaches must be considered for a system
conversion:
58 2 What Makes an SAP Project So Different?
• Simplification
• Finance
• Test runs
• User experience (UX)
The migration to S/4HANA offers the possibility to replace customer-specific
application code with SAP standard processes and to simplify existing processes.
Detailed simplification lists are created for the topics in question and are updated on
an ongoing basis. Every project member and the key users must be familiar with the
simplification lists. Sufficient time should be provided in the project plan for
workshops, training and change management activities. To successfully implement
a system conversion to S/4HANA, process expertise, application management and
very good financial skills are required. Practice has shown that projects without the
use of financial experts regularly struggle. Therefore, financial expertise is a “must”
in a project!
The technical requirements or the technical expertise of the SAP experts involved
should also not be underestimated. As always, the shorter the productive downtime,
the higher the effort and expertise required from the technical team to make it
happen.
The test runs run on a sandbox with a current copy of the production system. Two
to three test runs should be the minimum. However, if necessary, more can be
scheduled. To build upskills, the testers are integrated into the project at an early
stage. It is advisable to keep a detailed runbook in which the sequence of activities,
the errors and their correction and the time required for this are documented. This
requires a certain amount of discipline, but it pays off!
Recommendations
• Clarify whether you can archive data to reduce the volume of data to be migrated.
During the migration runs, the system checks whether the data in the tables is
consistent. Especially in the financial sector, inconsistent table entries lead to
problems that can stop and delay migration activities.
• Third-party applications and add-ons must be checked and tested at an early stage
to determine whether adjustments are necessary. In some cases, the third-party
software may no longer be supported in the S/4HANA environment.
• It also makes sense for dedicated process experts to work closely with the
business functions and business teams in the project.
• Although in many cases SAP GUI can still be used, you should plan to use the
new SAP Fiori user interface in order not to miss any innovations and to be able to
integrate mobile devices, such as smartphones and tablets.
• Finally, be sure to run basic housekeeping jobs to reduce the amount of unneces-
sary data prior to conversion.
In the S/4HANA environment, some logistics processes will in the future be
handled in the finance module. There are also completely new processes that were
not available in the old SAP ERP solution. This requires an early review of the
2.5 The Road to SAP S/4HANA 59
authorisation concept and user access. It makes sense to deal with possible problems
in the financial area and with customer and supplier master data before the project is
started. The creation of a realistic project plan will only be possible after the
S/4HANA Readiness Check is executed, mandatory items are fixed, and the first
migration test run. This first run will, as already mentioned, be performed on a
sandbox that represents a current copy of the production system (see Fig. 2.7). You
will only know at this point in the project how many and which problems in terms of
content must be solved before or during the actual migration.
SAP expertise should be consulted to optimise the downtime of the production
system. The fact that the first attempt may cause longer downtime than planned is not
a great cause for concern. This is to be expected, and this is also the reason why the
project plan provides for at least two, three or even more test migrations.
Planning for a System Conversion
Figure 2.7 shows the specific migration steps for the changeover from the existing
ERP system to SAP S/4HANA. In the first phase of the migration, configuration
adjustments are made, before it is possible to carry out the technical part of the
migration. Further adjustments are necessary after the migration is complete. Plan
sufficient time for testing and correcting the business processes in the unit test. It is
even possible that adjustments need to be made in the old ERP system. For example,
if you make changes to customer master data or even supplier master data, take time
to carefully evaluate the existing processes to prevent possible problems during the
migration. Data correction during migration is an iterative process that must be
carried out until you have a good understanding of the issues and how to solve them.
Plan a sufficient time buffer for corrections during the S/4HANA migration in order
not to jeopardise the go-live date. We recommend to tackle the different options
early in the project and to develop a roadmap that best fits your situation. The
successful transition to the new S/4HANA platform will ultimately help you to reap
the benefits of all the innovations.
Neither Greenfield nor Brownfield
Selective Data Transition Working Group for Selective Data Transition
Prepare Phase Realize Phase
Maintenance 
Planner Pre-Checks Pre-Checks
Simplification List
S/4HANA PCE / On-Premise Edition
Software Update 
Manager (SUM)
Application-specific 
Post Steps
Database Migration
Software Update
Data Conversion
Fig. 2.7 SAP S/4HANA conversion steps
60 2 What Makes an SAP Project So Different?
If neither the Greenfield nor the Brownfield approach is suitable, SAP and a
number of third-party companies support customers in their individual changeover
to SAP S/4HANA. To this end, SAP has formed a new working group with four
consulting firms (CBS, Datavard, Natuvion and SNP) called SAP S/4HANA Selec-
tive Data Transition Engagement, which is intended to facilitate the migration of
major SAP ERP customers to SAP S/4HANA.
These partners are developing solutions that combine the characteristics of a
classic new implementation with those of a system conversion. In the process,
master data and balances are transferred to the SAP S/4HANA environment on the
migration date. This also applies to certain business objects with their complete or
partial history.
In addition, it is defined which changes to company structure and business
processes make sense during data migration (so-called valid migration scenarios).
Here, the group follows a selective approach that can be combined with the SAP
Model Company.
This means that customers can continue to choose freely from the products and
services of the various providers. The working group will not develop common new
software for hybrid data migration.
(https://support.sap.com/en/offerings-programs/support-services/data-manage
ment-landscape-transformation/selective-data-transition-engagement.html)
This is begging the question: why isn’t everyone taking the Selective Data
Transition approach if it offers the best of both worlds? The answer is mostly “the
price tag”. These projects are significantly more expensive and more complex than
Brownfield or Greenfield approaches.
Conclusion:
The advantages of the Greenfield approach include a complete overhaul of pro-
cesses, correct data sets and the chance to get rid of obsolete legacy processes.
Leveraging the Model Company approach, you can avoid “starting from scratch”
when it comes to customising and developing enhancements, but it involves extra
cost and is not available for all industries and solutions yet.
The Brownfield approach makes it possible to bring your existing SAP ERP
system to SAP S/4HANA. This approach makes sense if the ERP system is relatively
close to the SAP standard. It can generally be assumed that the conversion is less
time-consuming than a new implementation with the Greenfield approach. Selective
Data Transition will be the exception but offers interesting possibilities to consoli-
date system landscapes. However, as these system conversions via Selective Data
Transition are complex and expensive, this procedure is more likely to pay off for
companies with a large number of SAP system landscapes and an equally large
potential for consolidation.
2.5 The Road to SAP S/4HANA 61
https://support.sap.com/en/offerings-programs/support-services/data-management-landscape-transformation/selective-data-transition-engagement.html
https://support.sap.com/en/offerings-programs/support-services/data-management-landscape-transformation/selective-data-transition-engagement.html
2.5.5 Data Migration Aspects of the Greenfield-Approach
Data Always Causes Problems in the Greenfield Approach, but It is not Possible
to Do Without
Data can be a nightmare! It doesn’t help to duck away or ignore it: problems with
data or data quality keep catching up with you throughout the entire project.
Data migration is a topic that often does not receive the necessary focus in the
initial phase of a project. In a Greenfield, as well as a classic SAP project, data must
be migrated either from the legacy systems to a structured SAP target system or, as in
our case, from an existing SAP ERP system to the new SAP S/4HANA system. This
is an elaborate and complex process, starting with the analysis of the data, the setup
of the test systems and finally the migrationof the master and transaction data into
the new SAP system within a quite limited time.
The data migration strategy is therefore an elementary component of the project
and, as mentioned above, builds on the procedures to be replaced. The migration
objects that are a prerequisite for the SAP S/4HANA implementation are predefined,
which makes it a little easier. The following questions must be clarified:
• Which activities must be used for the data transfer, and what are the
responsibilities, roles and schedules?
• Which data must be transferred, edited or deleted for each migration object?
Identify Data Sources
To find out which data you have to migrate, you have to look at the data in the source
systems (e.g. open invoices from the previous year, open orders, master data such as
customers, materials, products and suppliers). The results of the analysis of the data
sources are data profiles with information on the content, structure and quality of the
data sources. Another important step is to determine the business-relevant data that
can be cleaned, harmonised or even deleted.
It is useful to develop a standardised procedure for data migration and data cleansing
activities. Can the following questions be answered in advance?
• In what order must the data be transferred?
• What are the quality requirements for transferring the data into the SAP
S/4HANA system?
Statistical Evaluations
A mock data migration is performed to check the quality of the migrated data. The
data migration test consists of several cycles with the following statistical
evaluations:
• Is the transferred data complete and how much data is transferred?
• Is the transferred data correct in terms of content?
62 2 What Makes an SAP Project So Different?
• How long is the data transfer time?
• What is the error rate?
Error Rate
The number of migration cycles is therefore repeated until a qualitatively satisfactory
data quality is achieved (e.g. error rate < 1%). After each cycle, further data
cleansing activities need to be carried out.
It is impossible to overstate the importance of this! A high data quality is the
prerequisite for a successful test and the final transfer of the data into the S/4HANA
system, and without doubt, data cleansing in the project is a labour-intensive process
that must be planned accordingly!
What Tools Are Available for Data Migration Activities?
SAP Data Migration Cockpit: A Good Choice!
With the SAP Data Migration Cockpit, which is the successor of the Legacy
System Migration Workbench (LSMW), SAP provides a convenient and powerful
tool to support the migration activities of master and transaction data from non-SAP
and SAP systems to S/4HANA.
The following activities are supported:
• Overview of tables and objects for migration
• Execution of the data migration
• Maintaining the correct sequence of all migration activities
• Overview of all completed migration runs
• Error handling
• Repetition and suspension of migration activities
First, a list of all pending migration activities is drawn up. This list contains the
number of tables to be transferred with the number of table entries. The individual
activities are then processed sequentially. Errors are displayed and possible solutions
are suggested. A correction is not necessary in every case. For example, if old table
entries in the SAP ERP system are no longer needed in the new S/4HANA system,
the errors can also be ignored. For master data management, SAP offers the newer
SAP Master Data Governance application. For further details on the topics, see Sect.
9.4.3, “Master Data Management” and Sect. 9.6, “SAP S/4HANA Migration
Cockpit”.
Loading the Data
When all data cleansing activities have been carefully completed and all further
preparations have been made, the data can be loaded into the final production system
SAP S/4HANA. Various tools are available to support this process, enabling the data
to be loaded according to the data migration strategy. The sequence of the loading
processes can be adjusted and adapted depending on the data volume to be loaded.
2.5 The Road to SAP S/4HANA 63
However, a certain sequence of the data to be loaded is mandatory, e.g. first the
customer master data and then the corresponding orders (transactional data).
After each data load, certain characteristics are checked again, e.g. whether the
number of loaded data records has arrived correctly in the target system, the totals
match, etc. Errors must be corrected immediately at this stage, either by manual
intervention or by automated correction tools (programs).
2.5.6 Economic Feasibility Considerations/Business Case
Value Discovery Workshop
The commercial starting point for an S/4HANA project is of course the business
case. SAP offers a Value Discovery Workshop for SAP S/4HANA. Consultants and
architects from SAP and specialists (SMEs) and managers on the customer’s side
discuss the problems with the existing ERP system. To allow comparison with the
industry, a benchmark analysis of critical business processes can be carried out to
define potential for improvement. The result is a cost-benefit analysis of the intro-
duction of an SAP S/4HANA system.
To be able to conduct such discussions efficiently, the customer needs to be well
prepared with the following activities:
Identify Problem Areas and Pain Points
This is about identifying real business problems and setting priorities. In parallel,
study the available information material about new functions und possibilities that
can be implemented with SAP S/4HANA. Existing SAP ERP customers can also
request the SAP S/4HANA Business Scenario Recommendation report via the self-
service tool (see https://d.dam.sap.com/a/AREDtXr/Process_Discovery_How_To-
V36.pdf).
The SAP Transformation Navigator gives you a framework for your digital transfor-
mation journey and—based on your answers—shows the way forward (see https://
go.support.sap.com/transformationnavigator/#/welcome). Both tools provide a good
overview of the benefits that a migration from an existing SAP ERP system to an
SAP S/4HANA system can bring (Fig. 2.8).
Quantifying Problem Areas
There are various approaches to quantifying the problem areas. You can either
compare your company with competitors using publicly available information
(e.g. annual financial statements) or with the help of a benchmarking tool such as
the SAP Value Lifecycle Manager (see https://vlm.cfapps.eu10.hana.ondemand.
com/index.html#/home). For example, you can calculate the productivity losses
caused by inefficient processes in the manufacture of products or compare inventory
costs with leading companies in the industry.
64 2 What Makes an SAP Project So Different?
https://d.dam.sap.com/a/AREDtXr/Process_Discovery_How_To-V36.pdf
https://d.dam.sap.com/a/AREDtXr/Process_Discovery_How_To-V36.pdf
https://go.support.sap.com/transformationnavigator/#/welcome
https://go.support.sap.com/transformationnavigator/#/welcome
https://vlm.cfapps.eu10.hana.ondemand.com/index.html#/home
https://vlm.cfapps.eu10.hana.ondemand.com/index.html#/home
Identify Potential for Improvement Through the Use of an SAP S/4HANA
System
What are the benefits of switching to SAP S/4HANA?
In this section, the financial impact and the benefits of using an SAP S/4HANA
system is determined. In addition to the hard monetary factors, such as savings on the
IT side by replacing a complex system landscape or a reduction in personnel cost on
the IT and user side, also consider soft factors such as possible increases in sales
through higher customer satisfaction with improved processes or better data quality
available in real time for corporate management. Also do not forget to point out the
risks for the project and the changeover. The assessments of customers who have
already converted to SAP S/4HANA and have published their experiences are also
helpful here.
Compare Costs and Benefits
When all the information is finally collected and available, the business case or a
profitability calculation canbe prepared. Try to set up a realistic cost-benefit
analysis, and proceed in a structured manner. If there are several proposed solutions
to a problem, evaluate the individual alternatives. The business case created in this
way can then be extended by further detailed analyses, for example, by subdividing
and analysing problem processes into further sub-processes (https://news.sap.com/
2017/11/how-to-write-your-first-sap-s-4hana-business-case/).
Overview Execu�ve Summary LoB-specific recommenda�ons and results Next Steps
PurchasingAccoun�ng Sales …
Iden�cal structure for all LoB’s
Introduc�on Results Recommenda�ons
• Overview of iden�fied 
improvement poten�al
• Overview of business KPI and 
comparable industry figures
• List the respec�ve S/4HANA
innova�ons
• Details and explana�ons about 
each innova�on
• SAP Best Prac�ces, taking the 
current process coverage 
into account.
• Details about each 
recommended business 
scenario, including process 
improvements
Fig. 2.8 Structure of the report “SAP Business Scenario Recommendations for SAP S/4HANA”
2.5 The Road to SAP S/4HANA 65
https://news.sap.com/2017/11/how-to-write-your-first-sap-s-4hana-business-case/
https://news.sap.com/2017/11/how-to-write-your-first-sap-s-4hana-business-case/
2.6 Conclusion
SAP S/4HANA’ s innovations can bring considerable added value to a company.
Data can be analysed in real time, leading to accurate and reliable business forecasts.
The possibilities offered by the Intelligent Suite are impressive. Process simplifica-
tion leads to more efficient audit management and thus to qualitatively better risk
management. With the SAP Business Technology Platform, new business ideas can
be implemented more quickly, resulting in a faster time to market. The infrastructure
costs for the system can be reduced, among other things, due to the lower storage
requirements. Despite all the qualitative and quantitative advantages that the use of
an SAP S/4HANA platform can bring, it should not be underestimated that the road
to S/4HANA must be planned very carefully, the necessary means and resources
must be available and it requires an experienced project team with the support of
qualified consultants to be successful.
In our experience, the implementation costs for the new software are often
underestimated for various reasons, and on the other hand, the savings are inflated
to get the project off the ground. It is beneficial to inject a dose of realism at this
point!
These are the three most important KPI for the successful changeover to SAP
S/4HANA.
1. SAP projects require top management support!
SAP projects are transformation projects with effects on processes, system
landscapes and organisational structures in your company. You as a project
manager have to be a master of multitasking because competing resources
must be coordinated across several projects. Transformation projects or multi-
projects require company-wide and cross-organisational control. SAP projects
are therefore usually decided on at top management level, and management
must be involved throughout the project. The effort required for an SAP
implementation and the changes and effects associated with it are often
underestimated, and executive sponsorship is crucial to overcome the inevita-
ble stumbling blocks and resistance in the organisation.
2. The adaption of business processes is an opportunity.
Unlike the development of individual software, SAP projects start with
standard business processes. This applies to a change from a legacy system to
SAP as well as from an SAP ERP system to S/4HANA. The adaptation of
business processes to SAP processes is a great opportunity for simplification.
Changes and modifications to the standard are difficult and costly. Even if SAP
processes may seem inflexible at first glance, simplification is the key to realise
the potential for savings. Programming efforts are reduced by adapting
existing business processes to standard SAP processes. However, do not
(continued)
66 2 What Makes an SAP Project So Different?
underestimate the requirements around change management to overcome
concerns and fears within the organisation.
3. Spot on data migration: don’t forget to clean the house.
Data migration is a costly and complex process. Data cleansing and archiv-
ing tasks are an elementary part of any data migration strategy and must be
considered in the project plans. The tasks must be carried out early and
continuously in the project. Unfortunately, data migration is oftentimes treated
like the proverbial unwanted stepchild. Squeezed for time between (delayed)
customising finalisation and the need to start integration/user acceptance
testing as part of go-live preparations, it does not get the attention, resources
and time it needs to ensure the data quality is up to par. The business pays a
high price after go-live, dealing with (and manually cleaning up) dirty data.
2.6 Conclusion 67
The SAP S/4HANA Project: How It Should Be 3
In an ideal world, our book would be finished after this chapter: here, you will get to
know the best planning and implementation of an SAP project, in which project
management, project staff and the entire team adhere to this planning perfectly.
If only everything were that simple! Then, there wouldn’t be so many projects
that are finished late or never completed at all. There would also be no projects
whose scope changes over and over again in the course of the project, which in the
end do not or only partially achieve their goals and have to be marketed as “great
successes” even though in reality they weren’t.
Nevertheless, many companies approach large IT projects that have the potential
to change the entire corporate structure, business-critical procedures and processes
(such as an SAP S/4HANA implementation) with remarkable naivety. The expenses
for professional project management are all too often among the first budget items to
be slashed. We like to compare project management with oil in an engine, even if a
project management, on the surface, only produces costs: too little or no project
management at all leads to serious damage in the project, up to total loss—project
cancellation and write-off of costs.
In contrast to lawyers, engineers or doctors, project managers are not protected
professional titles with nationally or even internationally recognised training.
Irrespective of the level of education, experience and qualifications, every project
manager or even program manager can call themselves project manager. This leads
to very diverse quality in project management. However, for some years now, formal
qualifications—not only the general reference in the CV of years of experience
(which can hardly really be verified)—have become more important when it comes
to the selection of external consultants. This is a difficult situation for companies that
have considerable financial resources at their disposal and whose economic future
depends largely on a successful SAP project: how can you ensure that you hire a
project manager who knows their trade?
We have already referred to this in the introduction: the majority of IT projects
fail partially or completely. Industry publications report regularly about large “SAP
projects” (mostly managed by SAP partners) which struggled with long delays or
# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_3
69
http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-86084-4_3&domain=pdf
https://doi.org/10.1007/978-3-030-86084-4_3#DOI
budget problems or were even cancelled. And the affected companies paid dearly—
losses up to US$ millions! Good project management is crucial for project success!
Good project management is to a large extent a craft, i.e. the application of proven
best practices and methodology. Projects are dynamic, complex entities of formaland informal processes, relationships and motivations. No one can fully understand
and predict a complex project. Therefore, a proven methodology and best practices
are crucial tools for success.
Tip: Book Recommendation
If you want to learn more about managing complex situations successfully,
you should read Dietrich Doerner’s very informative and easy-to-read book
The Logic of Failure: Recognizing and Avoiding Errors in Complex
Situations, which was published as early as 1997.
Take this chapter as a frame of reference to which we will refer again and again in
the following chapters. The pitfalls and challenges, the predictable and unpredictable
problems and surprising twists and turns that we present to you in the course of this
book can thus be compared with the SAP S/4HANA implementation project as it
should be.
First of all, we show you how the journey begins and what prerequisites need to
be created in order to then describe an SAP S/4HANA project with all its phases and
structure. Imagine your boss giving you a free hand in planning and implementing
your project. You can ask for anything (as long as it contributes to making the project
a success), and nobody complains about budgets to be adhered to, tight schedules
and lacking resources.
3.1 Project Management Standards, Methodology and Tools:
An Overview
President Harry S. Truman had a famous sign on his desk in the Oval Office: “The
buck stops here”. In our case, this refers to the role of the project manager, either
from your company or as an external service provider. Many companies commission
consulting firms to carry out SAP projects and therefore decide on a dual leadership:
an internal project manager who is responsible for the successful planning and
implementation of the project together with an external project manager. In a broader
sense, it is often even a “triumvirate” of internal and external project management
and the solution architect, who is responsible for the entire content of the project.
Whether you manage an SAP project exclusively with your own team or com-
mission one or more consulting companies, in addition to the qualifications of the
project members, the qualifications of the project management are particularly
important.
70 3 The SAP S/4HANA Project: How It Should Be
A number of international project management standards and related
organisations have developed that are dedicated to standardising project manage-
ment methodology and improving project management quality through training and
certification.
These project management standards now offer a whole slew of tools and
methodological procedures that support you in the planning and implementation
phases of the project. The organisations behind them ensure the continuous devel-
opment and improvement of the methodology and tools.
The “Big 3” of Project Management Standards
Three major project management methods with associated organisations and inter-
national certifications have become established worldwide. These trainings and
certifications are designed to ensure project management quality standards:
1. The Project Management Institute (PMI), headquartered in Newtown Square, PA
(incidentally, very close to SAP America’s corporate headquarters), has devel-
oped a project management methodology which is described as best practices in
Guide to the Project Management Body of Knowledge (PMBOK Guide). PMI is
the project management organisation with the largest number of members world-
wide. There are eight internationally recognised certifications, the most important
and most widespread of which is the Project Management Professional (PMP)
certification, which is valid for 3 years and requires continuous upskilling during
its validity.
2. The PRINCE2 Project Management Methodology (Projects in Controlled
Environments) was originally developed by the Office of Government Commerce
(OGC) in Great Britain and is now part of AXELOS, a joint venture between the
Cabinet Office of the British government and the Capita Group.
In addition to PRINCE2, the well-known ITIL certification (IT Infrastructure
Library) is also part of this. It is a collection of best practices for which training
and standard certification is offered. ITIL has become a de facto industry standard
in IT service management.
3. In Europe, the project management association IPMA (International Project
Management Association) was founded, which also functions as a certification
body for project management standards. IPMA published the ICB (IPMA Com-
petence Baseline), which is the basis for national project management baselines.
These national project management standards are based on the ICB and addition-
ally consider country-specific requirements. The current version is ICB 4.0,
which covers the three fields of competence (behavioural, contextual and techni-
cal competencies). IPMA has local partner organisations in 72 countries. IPMA
USA issues four types of certificates:
– IPMA Level D: Certified Project Management Associate
– IPMA Level C: Certified Project Manager
– IPMA Level B: Certified Senior Project, Program or Portfolio Manager
– IPMA Level A: Certified Project, Program or Portfolio Director
3.1 Project Management Standards, Methodology and Tools: An Overview 71
Tip: Professional Qualifications
If you want to take on responsibility for an SAP project as a project manager in
your company, you should be familiar with at least one of these standards and
ideally have acquired the corresponding certification.
3.1.1 Selection of the External Project Management
If you commission an external project manager with the responsible implementation
of your SAP project, a proven project management certification is one of the must-
have assignment criteria in addition to a reference list of successfully completed SAP
projects. On the one hand, it increases the likelihood that good, qualified project
management will be assigned—and thus improves the chances of success for your
project. On the other hand, this approach contributes to the standardisation of the
project management profession and thus to better quality for all SAP implementation
projects.
Now the time has come: several candidates are introduced and offer their services.
What should you pay attention to? In the following, you will find some assistance for
the selection of the suitable project manager for your SAP S/4HANA project:
• Formal qualification
This includes project management certifications but also relevant industry know-
how.
• References
Contact the references provided, and try to find out detailed information about
previous projects as well as strengths and weaknesses of the candidate.
• Communication skills
The project leader must be a good communicator and be able to motivate,
convince and lead both the project team and the stakeholders. The most important
project currency is trust—and the project leader must radiate this.
• Language skills
Nothing connects and separates us more than language. Business-fluent English is
a matter of course; other languages like Spanish are an advantage, especially if it
is an international project. As an aside, make sure that the standard project
language is actually consistently followed in international teams to avoid
misunderstandings and tensions between project members.
• Gut feeling
Trust your gut feeling! If, after getting to know each other and after an in-depth
interview, you have the slightest doubt about the applicant’s suitability, you
should continue your search. Guiding principle: never give anyone the benefit
of the doubt!
A technically well-qualified and personally convincing project management is a
central success factor for your SAP project. Take your time in the selection process
72 3 The SAP S/4HANA Project: How It Should Be
and do not hesitate to reject candidates proposed by an external partner if they are not
completely convincing. Several interviews with different stakeholders can round-off
the candidate selection process.
3.1.2 The Importanceof Project Management Methodology
SAP projects, like all other major projects, are complex systems. They are
characterised by their own dynamics, interconnectedness, polytely (i.e. pursuing
several, sometimes even contradictory goals at once), intransparency and complex-
ity. What does this mean?
• Momentum
The project continues to develop and move forward on its own—irrespective of
the actions (or inactions) of individual actors.
• Interdependencies
“Everything depends on everything”. Changes in one area (sometimes surpris-
ingly) lead to changes in other areas.
• Polytely
From Greek roots poly- and -tel-, meaning “pursuing many goals”: managing a
project requires weighing up and balancing possibly conflicting objectives in
order to achieve the overall objective (e.g. quality objectives vs. timetable).
• Opacity and complexity
It is not possible to have an overview of all aspects of the project at the same time.
Everyone involved in the project sees only a part of it but often thinks he/she has
understood the project. In fact, it is more like looking through a frosted glass
pane: much is blurred in its details and can be guessed rather than clearly
identified.
Consistently Planning Ahead Enables Timely Countermeasures
These are the basic reasons why many projects only achieve their objectives to a
limited extent: complexity, momentum and lack of transparency inevitably lead to
wrong decisions with sometimes far-reaching consequences. A good project man-
agement methodology reduces the probability of poor decisions and—if they are
recognised in time—gives you sufficient time and opportunities to minimise the
fallout. Basic project management tasks, such as the preparation of a work break-
down structure, a time schedule, risk management, etc., are activities that reduce
complexity, make the interconnectedness visible and thus at least somewhat reduce
the lack of transparency. They provide the project management with important
structures and information for forward-looking planning and well-founded
decisions.
A generic project management methodology, i.e. not SAP-specific, is an impor-
tant foundation for both Accelerated SAP (ASAP), the “classic” SAP implementa-
tion methodology, and the successor SAP Activate.
3.1 Project Management Standards, Methodology and Tools: An Overview 73
There is no project management methodology prescribed by SAP. However, in
practice, many SAP project managers are PMI or PRINCE2 certified, and as we will
see, there are overlaps and similarities between PMI/PRINCE2 and ASAP. Before
we go into ASAP and SAP Activate in more detail, we will give a brief overview of
the PMI project management methodology: the PMI methodology is one of several
possible structured approaches—it is a good tool, but certainly not the only tool in
your project manager toolbox. The decisive factor is not which methodology you
have chosen but its consistent and competent application in your SAP project.
3.2 The Project Management Basics: PMI Project Management
Methodology
Every project is different—and yet all projects have a lot in common. There are
certain aspects that do not change, and therefore, there are good practices that are
helpful in every project. Of course, there is a big difference between designing and
building a motorway bridge, developing and launching a satellite into space or
implementing SAP standard software.
What Defines a Project?
But there are still many similarities: for example, every project has a defined
beginning, a defined scope and a defined end—and in between project phases with
milestones that have to be passed or achieved. In contrast to day-to-day business,
each project phase has specific tasks and deliverables, results that must be success-
fully developed and “delivered” as well as milestones that must be reached in order
to bring the project successfully to its goal.
The project management methodology structures projects. It provides a frame-
work and conveys concepts and technical terms that help every project manager to
plan a project professionally and to manage it successfully. It is at least as important
that the project management methodology conveys technical terms and concepts, a
kind of project management language that facilitates the exchange between project
managers. Just as every doctor knows what a fracture is, trained project managers
know exactly what is meant by a work breakdown structure (WBS).
Standardised Methodology
Founded in 1969 in the USA, PMI has been editor of the PMBOK Guide. According
to PMI, each project consists of the following phases, also called process groups (see
Table 3.1).
Phase 4 (monitoring and control) is a special case: unlike the other phases, this
activity takes place throughout the entire project duration—so the jury is still out
whether it is a separate phase or activities within all phases.
74 3 The SAP S/4HANA Project: How It Should Be
Phases and Knowledge Areas: All at the Right Time!
Let’s set the discussion about phase 4 aside as a minor issue: the PMI methodology
consists—and this is key for understanding—of a matrix of temporal project phases
and content-related topics, the knowledge areas (see Table 3.2).
The PMI methodology of project management offers great support, as important
tasks are listed for each project phase and each knowledge area. This is an important
orientation in order to keep all necessary project management tasks in view in each
Table 3.1 PMI process groups
Phase/process group Details
1 Concept and initiation(conception
and project preparation phase)
Clarification and definition of the project
objectives. Agreement/creation of a common
understanding
2 Definition and planning(definition
and planning phase)
Planning of project content and scope; development
of project, time and cost plans taking dependencies
into account
3 Execution(execution phase) Assignment of project resources to activities in the
project plan
4 Monitoring and controlling
(monitoring and control)
Reporting and change management
5 Closing(project completion) Order completion and administrative project
completion
Table 3.2 Knowledge areas according to PMI
Knowledge area Details
1 Integration
management
Coordination and exchange of information between the project
participants
2 Scope management Definition and monitoring of the project content; processes for
initiating and rescheduling necessary changes
3 Time management Monitoring compliance with the timetable
4 Cost management With the help of project cost accounting, the cost trend is
monitored, and necessary measures are taken
5 Quality
management
Standardisation of project processes and documentation of results
6 Human resource
management
Allocation of project resources to the project tasks according to
training/qualification
7 Communication
management
Information exchange with all project participants
8 Risk management Risk analysis, preventive measures, mitigation and emergency
concepts
9 Procurement
management
Cooperation with partners and suppliers
10 Stakeholder
management
Coordination and agreement with project participants inside and
outside the project
3.2 The Project Management Basics: PMI Project Management Methodology 75
project phase. This is where the circle closes: structuring, reduction of complexity,
focusing on the essentials, advance planning, and risk management—these are the
tools of the project manager’s trade which increase the chances of successfully
completing a project. As Mark Twain rightly said, “Forecasts are difficult, especially
when they concern the future”. Therefore, even the best managed project can fail.
Without a doubt, project success is the goal. But the task of project management is
also to do everything possible to minimise the risk of failure and to maximise the
available time for countermeasures through long-term planning.
3.3 Everything Perfectly Prepared: The Ideal Conditions
The right course must be set long before the first phase of your SAP project begins.
Dealingwith the requirements that ultimately set the SAP project in motion has
already begun with the corporate strategy, which comes before the IT strategy and
before the decision for SAP software.
For our ideal project, we assume that the company has decided on an IT strategy
based on SAP products. We have discussed the decision criteria in detail in Sect. 2.4.5,
“Software Selection Criteria”. Consequently, the decision to implement an SAP
S/4HANA implementation project does not come out of the blue: your processes or
even your business model changes, parts of your company are sold, or other
companies are bought. All these changes also require a change in your IT system.
The basis for all plannable changes in the company should be long-term, strategic
decisions, which are regularly reviewed and, if necessary, reassessed.
Sustainable corporate management is characterised by long-term corporate
strategies which include a suitable IT strategy. It may be clear from a distance that
such a long-term view often runs counter to short-term profit maximisation, but
nevertheless, these strategic decisions lay the foundation for a successful SAP
project.
Figure 3.1 shows an ideal project organisation embedded in the line organisation
and supported by subject matter experts from the respective departments. The
specifications and the acceptance of the results are carried out by the line
organisation, while implementation is the responsibility of the project team, which
is divided into several sub-projects. The key tasks of project control, solution design
and integration design (interfaces) are set up across sub-projects. The technical
infrastructure is provided by the corporate IT.
Note: Back to Start: Strategy Changes
Unless you are using accelerators like the model company or the project scope
is very limited, complex SAP projects often last longer than 12 months.
Certain strategic projects, which are also rolled out to different regions,
countries and business units after design and implementation, may take several
(continued)
76 3 The SAP S/4HANA Project: How It Should Be
years. A change in strategic direction during the project can become a very
serious issue and jeopardise the success of the project. However, since this
book is not about successful business management but about successful SAP
projects, we will not focus on the effects of short-term changes in strategy.
All strategic decisions have been made and confirmed by the management. The
SAP project can begin. In the following, we will take a look at the first steps until the
start of the actual SAP project.
The Project Office as Command Centre
The project management office (PMO) is the central point of every SAP project—
this is where all the threads come together.
You have staffed your PMO with colleagues who are up to the challenge. The
members of the project office are the first point of contact for many topics. You
should understand the technical content of the SAP project and have organisational
talent. Often topics are discussed here that are not yet ready for “public” communi-
cation. You as project manager must have full confidence in your PMO. Many
“small” enquiries and tasks that make an SAP project possible in the first place come
up here: whether you lack a workstation or the team urgently needs a meeting room
for a sub-project, the colleagues immediately take care of it and always find a
solution. There are no problems with the office supply in your project because
your PMO reorders in good time. The PMO is also responsible for operational
project planning, i.e. the maintenance of planning documents.
Subject Ma�er Experts
sevitucexE elbisnopse
R
sren
w
O ssecorP labol
G
 strepxE ssecorP labol
G
Integra�on-
Manager
Benefits-
Realiza�on
Process-
transforma�on
Informa�on-
technology
Change-
Management
SME
Team 1 (FI)
SME
Team 2 (Log)
SME
Team 3 (HR)
Development-
Team
SME
Team … (…)
Solu�on-
Architects
Integra�on-
Architects
Project-Sponsors (Execu�ves)
Steering-Commi�ee
Program Manager
Responsible 
for Template 
Design
Responsible 
for Approval of 
Strategic design 
Responsible 
for Approval of 
Detailed Design 
Business Department Experts Valida�ng Design 
against Requirements 
Fig. 3.1 Project team with responsibilities and decision-makers
3.3 Everything Perfectly Prepared: The Ideal Conditions 77
What Is the Overall Mood in the Project?
However, the most important task of the PMO, in our view, is that its members are
the first to notice “atmospheric disturbances” in the project. Long before the first
official discussions about any kind of malfunction, risks to the project or even
interpersonal problems are started or the problem escalates, the PMO has already
recognised it. It is therefore the heart of the project in more ways than one.
This is illustrated by Fig. 3.2: the PMO plays a central role in the organisational
structure of the project.
It primarily supports you as the project leader but also has at least one virtual
connection to each sub-project; and through the central administrative processes
(onboarding, procurement of materials and workstations, etc.), all those involved in
the project know their colleagues from the PMO. You can read more about the
structure and tasks of the PMO in Sect. 6.1, “Support Whenever You Need It: The
Project Management Office”.
The organisational and administrative preparations for the SAP project are now
almost complete. Before you start your work, you must choose a methodology for
your SAP project: SAP Activate. In the next part, we explain how SAP Activate has
developed from the previous implementation methodology ASAP.
Program
Sponsor
Execu�ve Steering
Commi�ee
Project
Management
Office
Business 
Process Owners
Advisory Boards
SAP
Execu�ve
Leadership Team
Technology
Regional
Leadership Teams
Organiza�onal 
Stakeholders
Employees
representatives
Data protection 
Officer
Country-specific
Organizations
Project
Management
Specialist teams IT Teams Change Mgmt.
Fig. 3.2 PMO as project headquarters
78 3 The SAP S/4HANA Project: How It Should Be
3.4 ASAP: The Mother of All SAP Methods
Everyone who has been involved in SAP projects over the last decades knows
ASAP. ASAP means Accelerated SAP and describes as a method or model the
introduction of SAP software as a project. The fact that the abbreviation asap is
widely known as an acronym for as soon as possiblewas certainly one of the reasons
for the choice of name. With ASAP, SAP, the developer of the software, has
provided a method for its implementation.
ASAP Development Discontinued:
ASAP was developed as a method by SAP in 1998. The last and final software
version is ASAP 8.0 from 2013. Since then, ASAP has not been developed further;
nevertheless, the documentation is still available today at https://archive.sap.com/
documents/space/asap-methodology.
ASAP has been replaced by the new SAP Activate methodology, which builds on
and extends ASAP. Some central things did not change during the move from ASAP
to SAP Activate—therefore, we will first give a short overview of ASAP before we
take a closer look at SAP Activate.
Figure 3.3 shows the phases of the ASAP roadmap and the different tasks that
need to be performed during each phase. In contrast to the five project phases
according to PMI, ASAP comprises six phases.
Project-
Prepara�on Blueprint Realisa�on
Final
Prep
Go Live
Support
• Project structure
• Resource 
planning
• Effort es�ma�on
• Quality 
assurance 
Planning 
• Establish 
communica�on 
structure
• Set up project 
controlling
• Assign 
responsibili�es
• Develop process 
landscape
• Develop 
architecture
• Create 
documenta�on
• Prepare training 
documents
• Prepare system 
architecture
• Develop 
Prototype
• Documenta�on 
sign-off
• Build system 
landscape
• Customizing
• Programming
• Build integra�on 
architecture
• Develop security 
and performance 
concept
• Tes�ng
• Solu�on 
Acceptance
• User Training 
Materials
• Preparedata 
migra�on
• Go-Live 
Prepara�on
• Acceptance Test
• Setup a 
produc�ve 
system landscape
• Performance Test
• Security test
• End user training
• Test data 
migra�on
• Plan the Go Live
• Go Live Plan sign-
off
• Communicate 
Change
• Shutdown legacy 
systems
• Produc�ve Data 
migra�on
• Data migra�on 
sign-off
• Final test of the 
produc�ve 
system 
landscape incl. 
data
• Formal approval
• Unlock users
• Communica�on
• Start produc�ve 
system
• Hypercare 
Support
Fig. 3.3 SAP’s ASAP roadmap
3.4 ASAP: The Mother of All SAP Methods 79
https://archive.sap.com/documents/space/asap-methodology
https://archive.sap.com/documents/space/asap-methodology
3.4.1 Phase 1: Planning and Preparation
Once the decision for an SAP project has been made, the implementation process
begins with phase 1 according to ASAP, the planning and preparation of the project
(project preparation).
Top-Down and Bottom-Up Planning:
Planning is of central importance in a project: it is the key to success. A combination
of top-down and bottom-up planning with the active involvement of all key
stakeholders leads to the best planning results.
During the project planning for the individual phases, it is advisable to plan the
coming phase in detail and all future phases more high level. The current plan
milestones are the basis for further planning, but it should not be set in stone. This
means that you need to maintain a certain flexibility for future milestones, which is of
course tightly linked to your scope management/change management processes.
The Critical Path Determines the Duration of the Project:
Determining the critical path (see Fig. 3.4) is the simplest way to estimate the total
duration of the project in planning terms. All activities that lie on the critical path
together or one after the other result in the total duration of the project. If there are
changes in any of the activities on the critical path, the subsequent activities will
move. Activities that are not on the critical path do not affect the total duration, so a
late completion would not be critical, as it does not impact the overall project
timeline.
Process Defini�on
End–to–end 
Processes
End- to -end 
Processes
Ini�al Architecture 
Defini�on
Integra�on 
Architecture
Define 
Scenarios
Implementa�on
Test Approval
Cri�cal Path
Set up the ini�al system 
landscape
Fig. 3.4 Critical path in the project
80 3 The SAP S/4HANA Project: How It Should Be
The critical path in Fig. 3.4 is composed of the following activities:
1. End-to-end processes
2. Definition of the scenarios and initial setup of the system landscape
3. Realise (implementation)
4. Test
5. Acceptance
The remaining activities (e.g. the initial architecture definition and the integration
architecture) are not on the critical path and therefore have no impact on the runtime
of the project.
Once the critical path is identified, project management’s attention focuses on all
activities that lie on it. Please note, however, that the critical path may change during
the course of the project. Activities that were previously not on the critical path may
become critical due to a change request or if their delay becomes too large.
Therefore, it is important to not only focus on the activities on the critical path but
additionally determine how much buffer the rest of the important project activities
have before they in turn affect the critical path. Prudence and diligence in controlling
and monitoring the progress of the project will protect you from such unpleasant
surprises.
Note: The scope statement is the most important document created during the
project preparation phase. It describes the project tasks and scope. The follow-
ing points should be included in the scope statement:
• Project Rationale: Explanation of why the project is necessary
• Business Objectives: Overview of project goals to be achieved from a
business perspective
• Project Results: List of project deliverables to be developed by the
project team
• Project Exclusions and Project Assumptions: Any issues or tasks not
undertaken by the project team and the assumptions on which project
planning is based (e.g. strong revenue growth requiring better IT support)
• General Conditions: Description of the financial, temporal and content-
related framework conditions in which the project operates
The scope statement is a working document. Each change request in the course of
the project is compared with the scope statement to decide whether the changed/
additional requirements can be accepted or not. If a change request is accepted, an
adjustment of the scope statement is often required.
3.4 ASAP: The Mother of All SAP Methods 81
3.4.2 Phase 2: Business Blueprint
With phase 2 (business blueprint), the actual technical part of the SAP project
begins. In this phase, it is necessary to describe the framework, the contents, the
interaction with other systems, projects, departments and the technical
implementation.
Business Process Requirements:
The most important and challenging, often most extensive and also most consequen-
tial aspect, is the development and documentation of the business process
requirements. They form (as shown in Fig. 3.5) the basis for process modelling
and the subsequent mapping of business processes in the SAP system. The com-
plexity should not be underestimated. The interaction between customising (master
data and transaction data), additional developments that may become necessary and
interface data must be described in detail at the process step level.
The following topics are considered in the context of the preparation of the
business blueprint:
• Integration scenarios (interfaces)
• Frontends (user interfaces)
• Implementation sequence (central instance vs. distributed systems vs. rollout of a
template)
• Industry solutions, add-ons, third-party products
• Go-live strategy
For You Know What You Are Doing!
The result of the blueprint phase is a largely complete overview of the process
landscape and the associated architecture that will be implemented. This involves a
Event Process step 1 Process step 2 Decision Process step 3 Result
New 
Order
Create Sales 
Order
Check 
Inventory
Iden�fy 
Suppliers
Request 
Quotes
Select 
Offer
Create Order
Delivery 
Received
General Process Flow
Example: Procurement Process
Confirm Order
Fig. 3.5 Example of a business process flow
82 3 The SAP S/4HANA Project: How It Should Be
detailed assessment, as general statements have already been made in the prelimi-
nary phases of the project. The goal of the blueprint phase is thus to create an
implementable business blueprint.
Documentation of the Blueprint—Knowledge Transfer:
The results of the business blueprint are often compiled and filed in the form of
documentation. In principle, the result of the business blueprint is the “book” of the
project (sometimes casually called a “very expensive book”):
• Blueprint document
The blueprint document contains a description of the process landscape and the
business concept.
• RICEF or WRICEF planning document
RICEF stands for Reports, Interfaces, Conversions, Enhancements, Forms and
the W for Workflows. This document contains a description of all development
objects. The objects to be developed are later documented in business and
technical specification templates.
• RACI matrix
RACI stands for Responsible, Accountable, Consulted, Informed. This matrix is
basically a table showing who does what in the project and is responsible for what
(see Sect. 6.3.1, “Guidelines for a Successful Project Control”).
Blueprint, WRICEF and RACI matrix are very important project documents that
need to be carefully developed, versioned, approved and filed. They form the basis
for the following realisation phase, so “version confusion” must be avoided at all
costs. Additionally, make sure that every project member has access to this crucial
information and knows how to find it.
3.4.3 Phase 3: Realisation
After the acceptance of the blueprintphase, the implementation of the third ASAP
phase follows immediately—the realisation phase. Now it is a matter of defining and
implementing the processes documented in the blueprint phase and the underlying
architecture in detail. This is usually the most expensive and time-consuming project
phase.
The main tasks in the realisation phase:
• Building and operating the project systems
• Customising and developments
• Definition and selection of the business data
• Interfaces and integration scenarios
• Extensions
• Users and authorisations
• Archiving
3.4 ASAP: The Mother of All SAP Methods 83
• Non-functional requirements
• Trainings
• Test procedures
3.4.4 Phase 4: Production Preparation
Almost Done! Tasks in the Production Preparation:
Within the framework of phase 4, the production preparation (final preparation), the
following tasks are performed:
• End-user training
• Setting up the productive system landscape
• Preparing the productive data transfer
• Cut-over planning
This critical phase requires very careful planning and execution. For complex
projects, so-called dry runs are performed to find possible mistakes and to practice
the execution of the activities in the interaction of all parties involved. The less time
is available for the actual cut-over, the more effort has to be put into the production
preparation phase. Optimised technical procedures, such as minimised downtime
service, reduce technical downtime during the go-live as well as organisational
measures to speed up the handover between persons and teams involved. This is
an optimisation task in which the most time-consuming tasks on the critical path are
analysed and accelerated in several iterations until the goal, completion within the
maximum available downtime, is reached.
The most important milestone is completed when all tasks have been planned,
documented and successfully tested. At this point, everything is well prepared for the
culmination of the SAP project: the go-live.
3.4.5 Phase 5: Go-Live and Support
The go-live and support phase shows whether the preparations were in fact good
enough—although unforeseen surprises can still jeopardise success.
The tasks in the go-live and support phase include the following:
• Shutting down legacy systems
• Execution, review and acceptance of the data migration
• Final test of the productive system landscape with the loaded data
• Obtaining the formal approval (go/no-go decision)
• Activation of the interfaces
• Opening the production system to the end users
84 3 The SAP S/4HANA Project: How It Should Be
Once the Interfaces Are Activated, There Is No Way Back!
The most important milestone in this phase is the go/no-go decision, which must take
place before the interfaces are activated. Once they are opened and data is exchanged
between the new production system and connected internal and external systems,
there is usually no way back. If, at this point, the new production system has such
serious problems that it is necessary to shut down and reactivate the previous
systems, this will cause massive problems. In complex system landscapes, it is
almost impossible to analyse the data exchange that has taken place up to that
point via the interfaces and to post it in the previous system landscape. It would be
a mammoth task under massive time pressure: the old productive system or the old
system landscape can only be reactivated once the clean-up work has been
completed, meanwhile business activities have to be suspended for the most part.
In short, as long as the interfaces have not been reactivated, the go-live can still be
aborted; after that, one can only try to rectify any problems that arise during
operation as you go.
The risk of serious problems during or after the go-live is considerable. Unfortu-
nately, it often happens that details have been overlooked and now lead to difficulties
as operations begin. Therefore, the go-live is followed by a so-called hypercare
phase, where special measures and preparations are in place to stabilise the system
and to solve problems in a timely manner. The new system is unfamiliar and poses
new challenges for users, so supporting them is as important as solving technical
problems.
3.4.6 Advantages and Disadvantages of ASAP
ASAP is a proven implementation methodology for SAP ERP projects. In the 1990s
and early 2000s, when many companies switched from legacy systems to SAP,
ASAP was an important tool for making these projects a success and has proven its
usefulness.
Better Is the Enemy of Good!
Companies that are about to implement their first SAP system today can continue to
benefit from ASAP, but let us state it very clearly: SAP Activate is better!
For most customers who have already passed the phase of initial implementation,
the value of ASAP is limited. Its focus on classic SAP implementation is both a
strength and a weakness:
• Optimisation projects, which often start shortly after a large SAP implementation,
include smaller, incremental improvements and go-lives; agile project manage-
ment methods, consisting of sprints, are not well-supported by ASAP.
• ASAP offers little assistance for introducing cloud-based solutions or building
hybrid landscapes.
3.4 ASAP: The Mother of All SAP Methods 85
• ASAP focuses on software products developed by SAP—third-party software
(especially in the cloud) is not in focus.
In our opinion, SAP’s decision to release ASAP 8.0 as the last ASAP version and
to rely on the successor SAP Activate instead was the right one.
3.5 SAP Launch: The Implementation Methodology for SAP
Cloud Products
While ASAP has traditionally been used for on-premise-based SAP implementations
and has proven its worth, there is—and not every SAP expert knows this—another
implementation method, especially for SAP cloud products, such as SAP
SuccessFactors and SAP Ariba.
SAP Launch consists of four phases, which will be briefly presented below:
1. Prepare (preparation)
2. Realise (implementation)
3. Verify (test phase)
4. Launch (startup phase)
Prepare Phase
The prepare phase corresponds roughly to the project preparation phase and the
business blueprint in ASAP: first of all, it is about the development of a scope
statement, the different roles and tasks in the project and the high-level project period
(milestone plan). The second step is the solution design, i.e. the detailed description
of the software solution.
It is precisely in this phase that particularly close cooperation with the specialist
departments is necessary to fully identify and incorporate the business requirements.
The challenge lies in translating the business requirements into software features and
capabilities. It is important to keep in mind what the cloud solution is designed for to
create a viable solution design.
In addition, integration issues are also highlighted: this involves connections
between the cloud solution and other (on-premise) systems. Fundamental decisions,
such as the use of middleware software or, alternatively, point-to-point interfaces,
play an important role here. In addition, it is necessary to identify the data objects to
be migrated into the cloud solution.
At the end of this phase, the following important milestones have been reached:
• All project participants have a common understanding of the project scope. What
is and what is not covered by the project?
• The scope also includes an approval procedure for scope changes in the project.
How are scope changes evaluated in terms of effort and impact on the project
86 3 The SAP S/4HANA Project: How It Should Be
duration? Who has the ultimate authority to decide whether a scope change is
accepted?
• Roles and tasks are defined. Certain tasks are carried out by experts; others—
especially process test activities—are taken care of by employees of the specialist
departments.
• The solution design is at a very advanced stage. It describes in detail the functions
of the software. It also includes the integration requirements, i.e. a plan forcreating or adapting the connections to other systems. Finally, the solution design
includes a list of the data objects to be migrated.
Realisation Phase
In the realisation phase, the solution design is implemented in the development
environment. The system configuration is carried out, and any development
activities or adjustments are realised. It is important in this phase to involve the
departments that will use the system in the future at an early stage. The phase is
concluded with a discussion (walk-through) of the entire functionality with the
department managers and their (hopefully) positive feedback on the implemented
solution.
Verify Phase
Once configuration and development is complete, the solution is transferred to the
test environment, and the verify phase begins. In a series of test runs, individual
functionalities are first tested, followed by entire processes from start to finish. In
addition, integration scenarios (if possible) are verified, and a test (mock) data
migration is carried out. It is strongly recommended that the tests are carried out
on migrated real data (pseudonymised if necessary) to obtain meaningful results.
Launch Phase
The launch phase is about the preparation and execution of the cut-over in the
productive environment (the actual transition to the new system). The configurations
and development objects are imported into the productive system, and the data
transfer is carried out. After successful go-live, the system is handed over to the
operations team, whose task is to ensure smooth operation from then on.
3.6 SAP Activate: The Better ASAP
SAP Activate: The “Swiss Army Knife”:
Over the years, the implementation of SAP software has become increasingly
complex, which is not only due to the increased functional scope and complexity
of the software itself. On the one hand, the SAP product range or range of solutions
has constantly expanded, while on the other hand, the starting points or objectives of
SAP projects vary considerably: some customers are planning the initial introduction
of SAP software, others are about to switch to SAP S/4HANA, and yet others want
3.6 SAP Activate: The Better ASAP 87
to optimise their SAP system landscape through SAP cloud products. SAP Activate
offers support for each of these different types of project.
SAP S/4HANA Implementations
SAP Activate supports all three current variants of SAP S/4HANA implementations,
the focus of this book: SAP S/4HANA, on-premise version; SAP S/4HANA Cloud,
Extended Edition (aka “Single Tenant Edition” or “STE” for short); and SAP
S/4HANA Cloud, Essentials Edition. Functionally, these SAP S/4HANA variants
do not differ in terms of technology stack—only the deployment option (on-premise
version, private cloud, public cloud) varies, which in turn affects the implementation
project. The possibility of making changes to the code is completely excluded for
SAP S/4HANA Cloud, Essentials Edition, and quite restricted for SAP S/4HANA
Cloud, Extended Edition. This affects the fit-to-standard analysis in the explore
phase (see Sect. 3.6 “SAP Activate: The Better ASAP”).
SAP Activate aims to take the different starting points between one customer and the
next into account and offers the right tools and the appropriate methodology for the
project. It is thus possible to introduce the SAP S/4HANA on-premise version as a
“Greenfield version” as well as to carry out conversions to SAP S/4HANA (“Brown-
field version”) and of course also the SAP S/4HANA Cloud variants.
The general goal of SAP Activate is to enable customers to implement SAP
solutions in a time- and cost-saving manner by providing them with additional tools
in addition to the methodology: SAP Best Practices and Guided Configuration. SAP
Activate is also integrated in SAP Solution Manager 7.2, and thanks to the SAP
Model Company, a further time-saving is possible through ready-made customising.
However, all this has led to a certain complexity of SAP Activate itself, as you
will see below.
The SAP Activate methodology, like ASAP, consists of six phases, as shown in
Fig. 3.6. The monitoring and controlling tasks of project management, which
according to PMI represent a separate phase parallel to the other project phases,
Discover Prepare Explore Realize Deploy Run
• Handover 
sales dept. to 
implemen-
ta�on team
• Scope 
defini�on
• Compare 
business 
requirements 
and scope
• Develop 
solu�on 
scenarios
• Project Start:
Define the 
business 
benefit and 
the success 
criteria
• Define the 
basic con-
figura�on
• Set up and 
test the 
configura�on
(based on 
requirements 
defined in the 
Explore 
phase)
• Transfer the 
configura�on 
to the 
produc�ve 
environment
• Support a�er 
go - live
• Con�nuous 
maintenance 
and update 
of the 
systems to 
ensure stable 
opera�ons
Fig. 3.6 The six SAP Activate phases
88 3 The SAP S/4HANA Project: How It Should Be
are no longer represented as a separate phase in SAP Activate. Instead, these
activities are integrated into the respective phases. We will first give you an overview
of the phases and most important tasks in it.
3.6.1 Phase 1: Discover
Before the actual project can start, it is necessary to create a company strategy for
digital transformation or to revise and update it, if it already exists. It forms the
overarching framework for the project. SAP S/4HANA as the future ERP system
represents the core, but other important issues must also be considered: IoT, big data,
omnichannel (i.e. integrated, coordinated customer communication across different
communication channels to optimise the customer experience) and business
networks (such as cloud solutions, SAP Ariba, SAP Fieldglass and SAP Concur)
to name but a few. The question that needs to be answered is: which of these
products promise significant benefits in the transformation of the company to an
Intelligent Enterprise? The basic concept of linking O-data (operational data,
business data) and X-data (experience data, customer experiences) must be applied
to the company’s situation. At the same time, inject a dose of reality by always
looking at operational aspects. The most sophisticated landscape has very limited
value, if stable operations are not ensured.
But back to the “daily grind” of project work: the next step is to analyse the
functionality of SAP S/4HANA or the innovations compared to the classic SAP
Business Suite. In addition to the functional changes and simplifications, the focus is
also on SAP Fiori-based user experience and, for example, the possibility of
realising agile innovations with the help of the SAP Cloud Platform. SAP offers
free (time-limited or functionally limited) demo versions for many solutions, which
can be used to become familiar with the innovations:
SAP S/4HANA Trial Offers
• SAP S/4HANA Cloud Trial (usable for 14 days), to be found at https://www.sap.
com/cmp/oth/crm-s4hana/s4hana-cloud-erp-trial.html
• SAP S/4HANA Trial (usable for 30 days), to be found at https://www.sap.com/
cmp/oth/crm-s4hana/s4hana-on-premise-trial.html
• SAP Cloud Platform Trial (valid for 6 months, renewable), available at https://
www.sap.com/cmp/td/sap-cloud-platform-trial.html
The Solution Scenario: Looking Back, Looking Forward
The third step is the development of the scope or solution scenarios. In the case of an
SAP S/4HANA conversion, it is recommended that in this early phase, the existing
ERP system is analysed with the help of the SAP Readiness Check for SAP
S/4HANA to identify necessary adjustments. This gives a first impression of how
complex the conversion will be—and this is very important for further project
planning.
3.6 SAP Activate: The Better ASAP 89
https://www.sap.com/cmp/oth/crm-s4hana/s4hana-cloud-erp-trial.html
https://www.sap.com/cmp/oth/crm-s4hana/s4hana-cloud-erp-trial.html
https://www.sap.com/cmp/oth/crm-s4hana/s4hana-on-premise-trial.html
https://www.sap.com/cmp/oth/crm-s4hana/s4hana-on-premise-trial.html
https://www.sap.com/cmp/td/sap-cloud-platform-trial.html
https://www.sap.com/cmp/td/sap-cloud-platform-trial.htmlThe result is a business case as a basis for project approval.
3.6.2 Phase 2: Prepare
The prepare phase marks the actual start of the project. The project team is assem-
bled; scope and project plan are finalised:
• Create project goals, high-level scope and project plan.
• Name a project sponsor (executive level!), and win them over for the project.
• Define project standards, project organisation and governance.
• Define roles and responsibilities in the project team.
• Analyse project goals in detail.
• Set up project management structures, progress monitoring and reporting
requirements.
• Build up know-how in the project team: consultants get to know the client’s
business; employees gain experience with the new SAP S/4HANA solution.
• Carry out the project kick-off.
3.6.3 Phase 3: Explore
Fit-to-Standard Analysis as a Main Task
In the exploration phase, it is usually a good idea to hold joint workshops with
customers, subject matter experts (SMEs) or key users and consultants in which the
standard functionality is presented (preferably in a demo system!). In this fit-to-
standard activity, it is possible to determine which gaps exist and which customising
settings are necessary. This information must be carefully documented so that it is
available as a basis for the development activities in the next phase. In addition, it is
important content for the test cases to be created and executed in the next phases of
the project. The most important activities in the exploration phase are as follows:
• Fit-to-standard analysis
• Definition of the configuration (customising)
• Definition of user authorisations and system access
• Preparation for data migration (Greenfield)
• Test planning
• Analysing the training needs of end users
• Milestone: Phase completion and acceptance of the results
The explore phase sets the stage for the implementation of the solution design.
Thorough and detailed definition of the business processes—validated with the help
of a demo system whenever possible—is crucial for a successful realisation phase.
Any issues that have not been carefully planned and prepared will emerge in the
realisation phase as open issues for which a concept and solution must be developed.
90 3 The SAP S/4HANA Project: How It Should Be
In the worst case, these gaps in the solution design require further adjustments
elsewhere, with potentially significant impacts on project effort and schedule. The
more time and care is spent on the explore phase, the smoother the project progress
in the subsequent phase.
3.6.4 Phase 4: Realise
Agile Implementation of the Requirements:
The most important tasks in the realisation phase are the configuration and testing of
the solution landscape. SAP Activate supports agile methods, which means that the
project team builds the solution in cycles/iterations (also called “sprints”): each cycle
consists of a configuration, test and acceptance phase, together with the relevant
documentation. At the same time, preparations for data migration (in the case of a
Greenfield approach) take place.
A key success factor in this approach is the close cooperation with experts from the
specialist departments. They ensure that the solution actually meets the business
requirements. Frequent and early deployment of the solution during agile develop-
ment cycles is designed to shorten the project duration and improve the quality of the
solution.
These are the main activities in the realisation phase:
• Setting up the system landscape (quality assurance and production system,
usually called QAS and PRD for short) including the high availability landscape
(HA system)
• Configuration of the solution (customising)
• Development of the solution extensions (development)
• Structuring of the integration scenarios (interfaces) in the QAS landscape
• Output management configuration (printer settings)
• Planning and implementation of regular integration workshops (process walk-
through)
• Data transfer from the source systems: definition of the data objects and configu-
ration of the data transfer tools
• Preparation and execution of the tests:
– Test cases
– Test plan
– Test execution and coordination
– Correction of errors
• Preparation of the training materials for the users
• Preparation of the operating manual and handover plans
• Creation of the cut-over plan
• Milestone: phase completion and acceptance of the results
3.6 SAP Activate: The Better ASAP 91
Note: Continuous Quality Check and Improvement Services (free of
charge).
As part of the regular maintenance and support contract, SAP offers a range
of Continuous Quality Check and Improvement Services. Some of them are
free of charge (depending on the type of support contract) but must be ordered
early (usually at least 6 weeks before the go-live). More information can be
found at https://support.sap.com/en/offerings-programs/enterprise-support/
enterprise-support-academy/continuous-quality-check-improvement-services.
html.
3.6.5 Phase 5: Deploy
Production Preparation and Go-Live:
In the deploy phase, the preparations and plans for the productive start of the new
system landscape are finalised. This phase shows whether everything really fits
together. Solutions must now be found for all remaining critical open points so
that the go-live can take place. The systems are finally tested (e.g. by means of
so-called final tests or user acceptance tests) to ensure that the sizing is sufficient for
the expected data and user load.
Note: System Sizing
System sizing refers to the estimation of the system size (number of
processors, size of the working memory, storage, etc.) so that the landscape
can cope with the requirements, but on the other hand is not unnecessarily
large.
For many years, SAP has been offering the Quick Sizer tool at https://www.
sap.com/about/benchmark/sizing.quick-sizer.html.
There are three versions:
• HANA
• Classic
• HANA Cloud
The most important factors are the amount and expected growth of data
(with the SAP HANA in-memory database, the amount of data should never
occupy more than 50% of RAM), the number of users and the processes.
Sizing is half science and half art, i.e. it is always an estimate. If sizing was
carried out during the sales phase, experience shows that it is at the lower end
and should be verified prior to go-live.
The sizing estimate is never based on average system utilisation but on peak
loads, which usually occur at the end of a month, quarter or year.
92 3 The SAP S/4HANA Project: How It Should Be
https://support.sap.com/en/offerings-programs/enterprise-support/enterprise-support-academy/continuous-quality-check-improvement-services.html
https://support.sap.com/en/offerings-programs/enterprise-support/enterprise-support-academy/continuous-quality-check-improvement-services.html
https://support.sap.com/en/offerings-programs/enterprise-support/enterprise-support-academy/continuous-quality-check-improvement-services.html
https://www.sap.com/about/benchmark/sizing.quick-sizer.html
https://www.sap.com/about/benchmark/sizing.quick-sizer.html
The exact design of the deploy phase depends on the chosen approach: a “big bang”
approach is a go-live where all new functionalities are set live at the same time. With
incremental go-lives, on the other hand, the functionalities are successively set live.
The risk is lower than with the big bang, but you pay the price of the frequent
adjustments to the system landscape that are necessary with each new functional go-
live. In an (international) rollout project, one often proceeds country by country or
region by region: one country or region after another is set live.
These are the most important activities in the deploy phase:
• Final configuration of the productive landscape
– Import customising and custom developments.
– Prepare interfaces and integration scenarios for the changeover.
– Prepare data migration before the go-live (e.g. transfer of master data).
• Finalisation of user training
• Finalisation of the detailed cut-overplan, including contingency and emergency
plans in case the go-live is not successful
• Implementation of the cut-over
• Go-live (go/no-go decision)
• Milestone: Phase completion and acceptance of the results
Note: Cut-Over Plan
The cut-over plan contains a detailed list of all tasks, activities and
responsibilities that arise during the go-live. Activities are usually planned
down to hours and minutes in order to make the best use of the limited time
available. It has proven useful to conduct a mock cut-over (dry run) before the
actual go-live date, i.e. a dress rehearsal that is as realistic as possible, during
which the go-live steps can be practised and previously undiscovered
problems can be identified and solved.
In addition to the activities to be carried out, the cut-over plan also contains
provisions in case not everything goes according to plan: these contingency
plans describe the measures to be taken to minimise risks and to remedy any
conceivable problems during the go-live. The golden rule is never go live
without carefully laid out contingency plans!
Last but not least, every cut-over plan includes the go/no-go decision: at a
meeting of all important project members and stakeholders, a final decision is
made (and recorded) on whether to go ahead or stop the go-live.
3.6.6 Phase 6: Run
After the successful go-live, the run phase begins. The first step is to stabilise the new
system landscape. The hypercare phase is intended to prevent system failures and to
3.6 SAP Activate: The Better ASAP 93
overcome startup difficulties. The team then focuses on maintaining the quality
standard achieved and successively implementing improvements.
On the user side, a distinction is made between normal end users and key users
(SMEs), which take care of solving application problems in the company. They are
Phase 1: 
Discover
Phase 2: 
Prepare
Phase 3: 
Explore
Phase 4: 
Realize
Phase 5: 
Deploy
Phase 6: 
Run
Project 
Management
Team Training
Technical 
Infrastructure
Applica�on 
Development
Select Roadmap Set up Project Management, 
Onboarding, 
Kick Off 
Standards, 
Infrastructure
Execu�on Supervision / Monitoring and Controlling
Baseline plan 
and Build
Coordinate 
Sprints Finalise Solu�on
Train Project 
Team
Develop 
Training Plan
Trail System 
Deployment Demo System
Sizing
Technical 
Solu�on Design
Dev System 
Setup
System Setup QA and Prod
Import 
Configura�on 
and Extensions
Con�nuous 
Improvement
Strategic 
Planning
Business Case 
and Scope
Business 
Process Map
Select solu�on
FIT to Standard 
Analysis
Baseline Build
Develop 
Configura�on 
and Extensions
Fig. 3.7 Overview of the SAP Activate phases and activities: 1
Phase 1: 
Discover
Phase 2: 
Prepare
Phase 3: 
Explore
Phase 4: 
Realize
Phase 5: 
Deploy
Phase 6: 
Run
Integra�on
Test
Data 
Migra�on
Move to 
Produc�on
Develop the 
Solu�on
Create Interface 
Overview
Develop / adapt 
Interfaces 
Test Cases and 
Test Plan
Run Tests:
Unit-, 
Integra�on-, 
Load-, 
Interface-
Acceptance-
Test
Define Test 
Strategy
Define 
Migra�on 
Strategy
Develop and 
Test Migra�on 
Tools
Hypercare Phase
Load Data to 
QAS for Tests
Produc�ve Data 
Migra�on
Select Project 
Team
Create 
Roadmap for 
Organisa�onal 
Change 
Management 
Op. Manual
Hand-Over Plan
Change Management
Administra�on 
of Roles and 
Authoriza�ons
Ac�vate 
Interfaces 
Con�nuous 
Improvements
End User Training
Change Control
Fig. 3.8 Overview of SAP Activate phases and activities: 2
94 3 The SAP S/4HANA Project: How It Should Be
the first point of contact for users who find that they cannot use the system as they
should. These problems can be of various types: authorisation problems, incorrect
user roles or deficits in training (also jokingly referred to as “the problem is in front
of the computer”). Of course, they can also be configuration or data errors that were
not noticed during the tests. The key users take care, for example, of carrying out an
initial problem analysis and—if they cannot fix the issue themselves—forwarding it
to the right places for rectification.
These are the main activities in the run phase:
• Support for users
• Solving operational problems as they arise
• Definition of future functional improvements and extensions
Last but not least, we would like to give you an overview of all SAP Activate
phases and the associated activities (Figs. 3.7 and 3.8).
Note: Regular Updates of the SAP S/4HANA Cloud Solutions
The SAP S/4HANA Cloud solutions are regularly updated and extended. In
systems based on SAP S/4HANA Cloud, Essentials Edition, an update is
automatically installed every quarter. For SAP S/4HANA Cloud, Extended
Edition, updates are provided every 6 months and must be installed after
2 months at the latest. These changes are not at all comparable with classic
upgrades in terms of the effort required for testing and configuration
adjustments. This is where the great advantage of a completely standardised
solution comes in, which works without modifications and extensions.
3.7 Support Tools Provided with SAP Activate
With SAP Activate, SAP offers a completely integrated system consisting of meth-
odology, best practices and guided configuration. In addition, SAP Activate is
integrated into the SAP Solution Manager as a central landscape management
system. With the SAP Model Company, a preconfigured SAP S/4HANA configura-
tion is available (at extra cost). In the following, we will introduce the individual
tools.
3.7.1 Roadmap Viewer
The Roadmap Viewer offers Implementation Roadmaps which are arranged
according to categories and solutions. These Implementation Roadmaps provide
an overview of the projects and the tasks, activities and deliverables.
The selected roadmap can be adapted so that company-specific activities can be
added. It can also be used as a work breakdown structure and transferred to the SAP
3.7 Support Tools Provided with SAP Activate 95
Solution Manager to be used there as a starting point for project planning and
execution. The Roadmap Viewer can be found at https://go.support.sap.com/
roadmapviewer.
There are two generic roadmaps:
1. SAP Activate Methodology for New Cloud Implementations
This roadmap is intended for public cloud projects.
2. SAP Activate Methodology for Business Suite and On-Premise
This roadmap comes in two versions: an agile and a waterfall version. The
roadmap is intended for on-premise projects.
In addition, there are 11 further roadmaps, which are solution-specific:
1. SAP S/4HANA Cloud, Essentials Edition
2. SAP S/4HANA Cloud, Extended Edition
3. SAP SuccessFactors (cloud)
4. SAP Service Cloud
5. SAP Data Warehouse Cloud
6. Intelligent Spend Management (cloud)
7. SAP Analytics Cloud
8. Hire to Retire (cloud)
9. Transition to SAP S/4HANA (on-premise)
10. Transition to SAP BW/4HANA (on-premise)
11. S/4HANA Upgrade and Product Integration Roadmap (on-premise)
It is also possible to download the information as a compressed archive. The ZIP
file contains a work breakdown structure in Microsoft Project and XML format.
In addition, an .xlsx file (Microsoft Excel) is supplied, which contains
explanations of the WBS entries. The supplied XML file contains the same informa-
tion as the work breakdown structure in Microsoft Project format but offers the
possibility of integration (upload) into SAP Solution Manager 7.2. This makes SAP
Solution Manager the central project management tool.
The Roadmap Viewer contains a number of accelerators. The accelerators
represent an extensive collection of useful documents, sorted by project phases
and working groups. These include questionnaires and templates for the preparation
phase, Microsoft PowerPoint slides and checklists. There are also links to blogs and
websites with further information.
SAP Best Practices: It’s All About Making the Right Choice
Overall, the amount of information provided is impressive; some might even say
overwhelming. However, it is not always easy to find the rightinformation for one’s
own project, and in most cases, it must be adapted to one’s own needs. Nevertheless,
the Roadmap Viewer provides a variety of useful and helpful tools to successfully
manage the SAP S/4HANA project with the SAP Activate methodology.
Familiarising oneself with the Roadmap Viewer at the start of a project is certainly
time well-spent.
96 3 The SAP S/4HANA Project: How It Should Be
https://go.support.sap.com/roadmapviewer
https://go.support.sap.com/roadmapviewer
3.7.2 SAP Best Practices Explorer
The SAP Best Practices Explorer is the central entry point for all SAP Best Practices
and Rapid Deployment Solutions (RDS). SAP Best Practices contain all necessary
information to model and use standard business processes in SAP. Rapid Deploy-
ment Solutions contain preconfigured business processes that can be executed
immediately.
The SAP Best Practices are related to the SAP Model Company approach:
specific content is imported into an existing system, together with the necessary
data, customising, etc. This makes it possible to set up a system with standard
processes that can ideally be adopted by the customer in his industry without any
major changes. The advantages are obvious: customers can implement SAP
S/4HANA faster and model business processes in a shorter time. There are
country-specific solutions which are adapted to the legal particularities in the
respective country.
After activating the SAP Best Practices solution, the configuration can be
extended and changed as before using transaction SPRO. It is important to use the
Administration Guide for SAP Best Practices, which describes in detail how to set up
the system configuration with SAP Best Practices: https://help.sap.com/viewer/
S4HANA1909_AdminGuide.
Note: Integration of SAP Solution Manager 7.2 with SAP Best Practices
As of SAP Solution Manager 7.2, it is possible to import SAP Best Practices.
Each SAP Best Practices package contains process and configuration content,
such as process diagrams, test scripts and configuration recommendations.
These packages are continuously adapted to new SAP S/4HANA versions.
The SAP Best Practices Explorer is therefore used in the discover and prepare
phase and provides support in selecting the appropriate best practices for the
respective project.
SAP Best Practices can be activated in the development system using the
SAP Solution Builder. The configuration is then distributed via transports to
downstream systems (QAS and PRD).
3.7.3 SAP Model Company
The SAP Model Company, a combination of SAP Best Practices, which together
cover most standard processes of a “model company”, has been in existence since
2017. SAP Model Company is a “ready-to-run solution” consisting of business
content (data), ready-made solutions and accelerators, such as test data and test
scripts. It can be thought of as a collection of best practice building blocks that
together create a fully functional environment that covers the core processes of a
company.
3.7 Support Tools Provided with SAP Activate 97
https://help.sap.com/viewer/S4HANA1909_AdminGuide
https://help.sap.com/viewer/S4HANA1909_AdminGuide
The simplification compared to the best practice approach is that you don’t have
to decide for yourself if it fits and is necessary for your project. The SAP Model
Company package is fully configured—a selection is no longer possible at process
level but only at business unit and industry level.
On the other hand, one loses flexibility in defining the project scope, since it is not
possible to selectively include or exclude individual processes. The SAP Model
Company comes preconfigured for 17 industries and comprises 12 business areas
(lines of business, LoB), but once you have chosen a model company, the content
cannot be changed. You can only make adjustments in the Project System after you
have imported the Model Company.
SAP Model Company Packages exist (as of summer 2020) for the following
sectors:
• Agribusiness
• Airline Back Offices
• Automotive
• Chemicals
• Consumer Products
• Core Retail
• Defence Logistics
• Fashion and Vertical Business
• High Tech
• Industrial Machinery and Components
• Integrated Digital Banking
• Integrated Utilities
• Mill Products
• Mining Production and Execution
• Oil and Gas
• Pharmaceuticals
• Trade Management for Consumer Products
• Utilities for Regulated Markets
The following divisions are covered by SAP Model Company Packages:
• Billing and Revenue Innovation Management
• Connected Assets
• Connected Manufacturing
• SAP Customer Experience
• SAP EWM for Industries
• Finance
• Human Resources
• Logistics Execution
• Multinational Corporations
• Research and Development/Engineering and Sustainability
• Shared Services
98 3 The SAP S/4HANA Project: How It Should Be
• Supply Chain Planning
• Wholesale Distribution
The SAP Model Company concept is arguably the most successful innovation in
the field of implementation methodology and tools in recent years. It has consider-
ably reduced complexity and thus the time required as well as the investment (time-
to-value) and is the first choice for many customers for their implementation projects
(Greenfield).
The advantages lie in five core areas:
1. The initial definition of the project scope and the quality of the associated effort
estimates is considerably better and more resilient. It is a solid basis for business
case and budget planning!
2. The project duration will be reduced drastically in most cases.
3. The process modelling is much more closely aligned with the SAP standard,
which pays off due to lower development costs and, in the long term, lower
adaptation costs when importing newer software versions.
4. Decision-making in the project is accelerated (which in turn saves time and
money), as it is possible to take SAP standard process settings as a starting
point and guideline.
5. The process and landscape design is “future-proof”, i.e. it is based on SAP’s
roadmap and future developments.
The big advantage of the Model Company compared to individual accelerators is
its integrated, out-of-the-box approach: the model company system ensures that the
different parts of the business fit together.
As mentioned at the beginning, the biggest challenge in an SAP project is the
complexity in technical, process and organisational terms. An SAP implementation
is a huge effort for any company and—as the number of failed projects illustrates—
an enormous risk.
The implementation methodology makes a big difference when it comes to
reducing complexity and making risks more manageable. Errors will always happen,
but the number and severity of errors can be reduced. Sound, forward-looking
planning allows you to react earlier to avoid the worst consequences of wrong
decisions.
Generic approaches, such as PMI or PRINCE2, are the basis of good project
management. SAP-specific implementation models like SAP Activate build on these
and offer highly specialised tools for their designated purpose.
SAP has invested enormous amounts of time and resources in the SAP Activate
implementation method as the successor to ASAP and is continuing to push ahead
with updates and refinements. Roadmap Viewer and SAP Best Practices contain
concentrated SAP know-how that can be used in a targeted manner to accelerate
projects and make decisions for solutions that are as close as possible to the SAP
standard.
3.7 Support Tools Provided with SAP Activate 99
The limits of SAP Activate are reached, when the customer landscape leaves the
SAP world. As soon as customers connect their SAP systems to third-party
systems—and this is the case for almost all SAP customers—SAP Activate support
stops. Here, customers depend on the support of their software partners to identify
and solve problems that may arise after implementation at an early stage.
For most customers, this is a big challenge, because for them, it does not matter
whether it is SAP software or third-party software—the entire landscape has to work
together. As a projectmanager, using SAP Activate you have a good methodology to
manage and control the SAP project deliverables. Keep in mind that it is the business
critical non-SAP systems linked to your SAP landscape, which you must keep a
close eye on as well.
100 3 The SAP S/4HANA Project: How It Should Be
The SAP S/4HANA Project: How It Is 4
From dream to nightmare, in this chapter, we return to the hard ground of reality.
There is probably no complex SAP S/4HANA project that runs without problems.
However, most of the time, the mistake is not in the (SAP) system: no, the problems
are home-made, overlooked or underestimated by those running the project!
Despite (supposedly) careful planning and a methodical approach, there will
always be occasions when your project is in a tailspin. This chapter draws your
attention to the pitfalls that occur most frequently in practice. In terms of content, we
will mainly deal with “new” SAP S/4HANA projects. These projects use SAP
S/4HANA as a basis, SAP HANA as a technology platform and SAP S/4HANA
projects with agile parts. We are aware that currently, a large number of SAP
implementations based on SAP ERP Central Component (SAP ECC) are still
productive and will not be converted or migrated to SAP S/4HANA anytime soon.
Besides, there are ongoing projects that use Accelerated SAP (ASAP) as a project
method and SAP ECC or its predecessor releases or hybrid implementations (mainly
because the functionality of SAP S/4HANA has not yet reached the full scope of the
“old” SAP Business Suite).
In this chapter, we refer to the phases of the SAP Activatemethod introduced with
SAP S/4HANA, which you got to know in Chap. 3, “The SAP S/4HANA Project:
How It Should Be”. There, we have already discussed similarities and differences
between SAP Activate and ASAP.
In this chapter, we discuss mistakes that frequently occur during the project’s
course in the context of the phase in which they can have the most serious impact on
your project’s success. Think creatively before starting the project and before each
project phase about how you can avoid the respective stumbling blocks—or at least a
large part of them. You will find additional support in Chap. 6, “Project Planning,
Control and Quality Assurance”.
An SAP S/4HANA project is not an IT project in the classic sense but rather a
transformation project that will change processes, business models and company
organisations in the long term. If you succeed in anchoring this special feature in the
# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_4
101
http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-86084-4_4&domain=pdf
https://doi.org/10.1007/978-3-030-86084-4_4#DOI
minds of the project sponsors, stakeholders and decision-makers in the company,
you have already taken an important step towards project success.
We have already provided an insight into the individual phases of SAP Activate
in Chap. 3, “The SAP S/4HANA Project: How It Should Be”.
4.1 Phase 1: Discover (Or Explore Possibilities!)
Determine the Project Scope:
This phase before the actual project start is new in the implementation methodology
of SAP software—not only in name but as an additional important phase. Even
before the project’s actual start, this phase provides methodical support in preparing
for the project. The transition of the project from (internal) sales (every project has
advocates* and opponents* and must first assert itself) into the operative phase takes
place here. This handover from sales to delivery is the first part of this phase. Every
project of the size of an SAP S/4HANA transformation project requires thorough
preparation in terms of technical aspects and (and perhaps above all) in the involve-
ment and conviction of important decision-makers and the coordination of the
project’s scope. Equally important is the definition of what should not be part of
the project. If these decisions are made, documented and approved here, annoying
discussions and shifts of planning and budget can be avoided during the later project
implementation.
Thus, this phase’s results are the documented handover of the project to the
executing project organisation and the definition and acceptance of the project scope.
What Works and What Does Not (Yet) Work?
In contrast to “conventional” SAP projects based on SAP Business Suite, where the
full functionality is available, SAP S/4HANA projects are currently still somewhat
limited in certain functional areas. There are many new possibilities in finance and
controlling, and we are also able to find and use many tried and tested solutions. In
some other areas (e.g. SAP Supplier Relationship Management, SAP SRM, or SAP
ERP Human Capital Management, SAP ERP HCM), SAP S/4HANA does not (yet)
offer the full range of functions. Here, a clear distinction must be made from the
outset in the scope definition of what can and cannot (yet) be done.
Another important aspect is to have found one or more project sponsors at this
early stage. There will always be discussions about the usefulness of decisions.
Therefore, it is important to have stable decision-makers behind you.
You, as a project manager, are, of course, already in the “driver’s seat” at this
stage. However, you will not bring the majority of the project organisation on board
until the next phase.
102 4 The SAP S/4HANA Project: How It Is
4.2 Phase 2: Prepare (Project Preparation)
Laying the Foundation Stone:
The decision for the SAP S/4HANA project has been made. In the preparation phase,
you now lay the foundation for successful project implementation: set goals, plan
times and resources, set up the project organisation and define the infrastructure for
project work. You pay particular attention to the coordination and communication of
the project within the company. So far, so good! In these sections, we will introduce
you to the challenges you most frequently face when planning and preparing the
project.
4.2.1 Official Project Start
Projects on the scale of an SAP S/4HANA project usually affect (or perhaps better
“impact”) several parts of your company and a large number of employees in the
respective divisions. As the project moves forward, more and more new external
consultants will be involved in the project and will often occupy their new workplace
in the company for some time. There are many changes—and these should be well
prepared and communicated. You also have to make sure that everything you are
planning now is implemented accordingly. Once the project team is ready to start,
there is a joint project kick-off. The starting signal for the project has been given!
4.2.2 Simplification Through Solution Modules
One of the biggest (and best) innovations in SAP Activate is providing ready-made
solutions in the form of “guided configuration” and the delivery of ready-to-run
business processes. On the one hand, this facilitates (and shortens) the implementa-
tion and, on the other hand, sets stricter standards. See Chap. 3, “The SAP S/4HANA
Project: How It Should Be”, and Chap. 9, “Project Support Tools”, for more
information.
For you, as project manager, this means (even more so than perhaps in an SAP
ECC project) to pay attention to the use of this standard functionality.
4.2.3 Planning the Project
I Want It All and I Want It Now:
It is not uncommon for you to be under great pressure of expectations as early as your
SAP S/4HANA project planning stage. If you are responsible for a project in your
company, this pressure comes from your management. If you work as a customer
consultant, the pressure comes from the client. The following examples should
illustrate the difficulties that lurk in this project phase:
4.2 Phase 2: Prepare (Project Preparation) 103
• Stress from within your own camp (internal projects)
The “go” for a new project is often associated with theclear expectation that the
specified introduction deadlines will be met and, if possible, even undercut.
Carried by exuberance and the lack of experience with transformation projects,
the deadline is not subject to a qualified review. Quiet doubts are suppressed.
Nobody wants to expose themselves and admit that the timetable could be far too
ambitious.
If you have already had successful SAP projects in your company, the pressure
of expectations may even increase (“it can’t be that difficult, we managed it the
first time around”). However, we advise caution here: we are talking about a
completely new technological platform with new possibilities! (The Simplifica-
tion List, which describes the process simplifications of SAP S/4HANA com-
pared to SAP ECC, has over 1000 pages for the current 1909 version—and these
changes will definitely make your SAP S/4HANA project a completely new
project.)
• Wishes of the customer (consulting projects)
In the battle for a contract, many a supplier has been tempted to make unrealistic
promises. Based on the customer’s requirements, which are often not clearly
defined in the offer phase, you have to make statements about budget and
deadline. There is the risk of overlooking possible problems in favour of future
sales expectations. It is often impossible to meet the promised deadlines with the
agreed budget.
In both cases, you, as the project manager, are facing your first challenge. Do not
allow yourself to be lured into the trap of aligning the project plan too optimistically
with a target date. In general, many planning errors result from the effort to meet
given deadlines (even if they are unrealistic).
• The availability trap
If the project complexity and/or the project staff’s availability are assessed
unrealistically, the deadlines cannot be met from the outset. For example,
employees are often scheduled for 5 days a week for the whole year. The
realisation that a summer holiday is also due this year does not set in until June.
• The optimism trap
Estimates of project costs are too optimistic, too superficial or even wrong. They,
therefore, do not provide a reliable basis for project implementation.
• Planning too rough
There is not enough detail in planning: the planning is not based on milestones,
and critical paths are not defined.
• Incomplete planning
The planning is not complete: work packages are missing or are not assigned to
the project phases in a logical order.
• Insufficient communication
Plans are not communicated sufficiently to project staff, stakeholders, specialist
departments and adjacent projects.
104 4 The SAP S/4HANA Project: How It Is
• The blinders effect
Potential risks are insufficiently evaluated. The plans do not contain measures to
avoid or minimise risks. For example, it is not considered that employees may be
assigned to other projects or their specialist department and thus have only limited
availability for the project.
• Lack of quality assurance
No quality assurance procedures are planned. It is unclear who carries out quality
checks, when and on what basis. In complex projects, however, an independent
assessment by external auditors with experience and sensitivity is helpful.
• Too few or too many buffers
If deadlines are tight, planning is done without or with too little buffer. Planning
without a time reserve endangers the project. But the opposite is also a problem:
excessively generous buffers result in a certain carelessness and make the project
more expensive.
• SAP S/4HANA release cycle
Currently, the SAP S/4HANA system is in a very stable state but is being
functionally developed further. You will almost certainly be upgraded to a new
release during your project. Time is needed for both the technical conversion and
the necessary tests, which you will lack in the end without long-term planning.
If you are prepared for the many challenges waiting in such a complex project as
an S/4HANA introduction, you can elegantly avoid many pitfalls.
4.2.4 Project Organisation and Project Resources
In this section, we would like to show you the most important pitfalls you may face
when setting up the project organisation and nominating project staff.
The Most Important Resource—Qualified Personnel:
The establishment of an efficient project organisation and project structure and the
staffing of the teams with qualified employees require a lot of attention and care. If
roles, responsibilities and procedures are not clearly defined projects can get into a
tailspin right from the start.
Taken from Project Life:
In the practical example that you got to know in Chap. 2, “What Makes an SAP
Project So Different?”, a competition for the limited SAP process and project
management skills develops, for example, because the interests at the global and
local level are not always congruent. Besides that, the new SAP S/4HANA platform
has split the world of SAP experts into two camps for the time being: on the one
hand, SAP S/4HANA expertise and on the other, the currently still relatively large
number of SAP consultants with SAP Business Suite Certification. There is enough
work available for both groups: for your SAP S/4HANA project, you need a
4.2 Phase 2: Prepare (Project Preparation) 105
considerable number of SAP S/4HANA consultants—and those with extensive
project experience are still relatively rare.
When setting up the project organisation, ask yourself who the people are with
whom you want to make your project successful. This does not only apply to the
project team in the narrower sense because the project organisation includes all the
people involved in the project (management, steering committee, stakeholders and
specialist departments).
When setting up a project organisation as well as during the course of the project,
the following areas can cause particular headaches:
• The others are always responsible
The responsibilities of all persons involved in the project are not defined and
agreed upon within the company. There is no overwiew, which clearly describes
who is responsible for which tasks in the project, e.g. a RACI matrix (Responsi-
ble, Accountable, Consulted, Informed) (see Sect. 6.3.1, “Guidelines for a
Successful Project Control”).
• Unclear decision-making powers
In an SAP project, decisions have to be made, which involve personnel,
organisational and process-specific changes. If it is not clearly regulated, who
in the company is authorised to decide? This lack of regulation leads to delays in
decision-making. In the worst case, massive acceptance problems arise during
rollout.
• The right people are missing
The availability of qualified specialists at the right time is not guaranteed. For
example, a project manager with a lack of experience in complex SAP projects
and/or lacking leadership qualities is deployed. The project manager of an SAP
S/4HANA project should also have at least participated in the successful imple-
mentation of SAP S/4HANA in a leading position. Knowledge gained through
trainings is helpful here but not sufficient. The search for suitable candidates is
often difficult and takes much time, during which the project cannot move forward.
• Conflicts of tasks in the case of parallel staff deployment
Employees are often only assigned to a project on a part-time basis to keep in
touch with the practice and with colleagues in the department, which can be quite
useful. However, these employees then find themselves in a permanent conflict
between the project’s demands and the day-to-day business of their traditional
tasks. There is the danger that they will be scheduled several times.
• The chemistry is not right: disagreements in the team
Not all the people involved are compatible, because in addition to technical
qualifications, interpersonal factors also play an important role in the project’s
success.
• No common objectives
The project staff’s personal goals and the company’s responsible persons do not
coincide with the project’s goals, e.g. concerning the duration of thecooperation
106 4 The SAP S/4HANA Project: How It Is
in the project, the career interests of the project staff and the different interests in
the specialist departments.
• Fears about the future
Sometimes, project staff’s previous jobs are filled by others, making their reinte-
gration into specialist functions more difficult. Worries about their future job can
harm their willingness to perform.
• Conflicts of competence
There are conflicts between external consultants and long-established process
owners or between supervisors of legacy systems and the SAP S/4HANA project
group. Resentment of advocates of the status quo towards the new is widespread
and should not be underestimated.
• Unclear expectations
You have failed to discuss clearly with your staff what you expect from them
from a professional and personal point of view before the project begins.
• Agile sub-projects
Agile sub-projects are increasingly used in SAP S/4HANA projects (especially in
software development). Here, other methods and project management approaches
are necessary. Experts for this are (still) rare and must be involved at an early
stage.
The project organisation’s structure is a foundational and crucial issue because,
normally, it is valid for the whole project duration. The time invested here usually
pays off at the end of the project.
4.2.5 Provisioning the Infrastructure
Creating the Right Framework:
Despite the obstacles mentioned in the previous section, you have managed to put
together a highly qualified and motivated project team. However, there is still unrest,
and the work is not progressing as planned in the project plan. What happened?
If logistical and technical prerequisites for successful project work are not created in
time, daily work delays will occur. Instead of devoting themselves to their tasks in
the project, the employees are busy chasing after important work equipment. The
resulting dissatisfaction and frustration endanger the progress of the project.
The following examples, from our years of experience, may sound familiar to
you:
• Lack of workspace
Employees cannot work because there are not enough workplaces available.
• No system access
Employees cannot work because they do not have system access or the IT
equipment has not been ordered in time. This may be because the employee
4.2 Phase 2: Prepare (Project Preparation) 107
responsible for purchasing not know which hardware to order—or he / she was
simply on holiday.
• Systems missing
Employees cannot work because the system landscapes (SAP system or legacy
systems) are not available for customising, development or testing.
Cloud Usage:
With SAP S/4HANA, SAP’s strategy has developed even more clearly in the direction
of becoming a provider of cloud solutions. Many of the new components that are no
longer part of the digital core, such as SAP SuccessFactors, SAP Ariba or SAP
Fieldglass, are now only available as cloud solutions. SAP S/4HANA still offers the
possibility to run the software in your own data centre; however, software innovations
are available faster in the public cloud. When you are leveraging SAP S/4HANA Cloud
(be it extended edition, or essentials edition), SAP is not only the software manufacturer,
but also the service provider—which means you have another “player” in your project.
Although this provider is (usually) very service-oriented, it processes tasks according to
a catalogue and with experts not directly assigned to the project. Special expertise and
increased attention are required here to avoid costly delays.
4.2.6 Communication Within the Company
Marketing is Everything and Everything is Marketing!
Coordination of the project and publicising the project within the company should
go hand in hand. However, experience shows that failures in this area can lead to
considerable misunderstandings and difficulties:
• Unclear project objectives
The project objectives are not communicated to all participating or affected
organisations in the company. There is no common understanding of project
expectations, urgencies and priorities. Some of those directly involved do not
know what to expect during and especially after the project.
• Boundaries are missing
Boundaries that define and clearly communicate the project’s scope and—most
importantly—what will not be part of the project are missing. Especially for
companies that already operate a complex SAP landscape, the SAP S/4HANA
project will only replace part of it. A clear demarcation is necessary here.
• Lack of involvement of the specialist departments
Specialist departments do not participate. As a consequence, the departments
affected by the project do not feel obliged to support the project. This can lead to
permanent disputes, making the project unnecessarily difficult, causing delays or
even causing the entire project to fail. Without careful coordination within the
company, conflicts regarding budgets and project resources can also be expected.
108 4 The SAP S/4HANA Project: How It Is
• Lack of basics
There is no statement of work defining the project’s content, scope, duration and
budget. Sometimes such a document exists but is not accepted by all project
participants.
• The left hand does not know what the right hand is doing
The project management fails to coordinate the content and technical aspects of
parallel or sub-projects. Serious consequences for the project’s course are to be
expected if the effects of parallel projects on upstream and downstream processes
are recognised too late or ignored. Inconsistencies in process design or the system
architecture can make a complete redesign necessary.
Suppose you have not managed to reach a common understanding with your
organisation’s leadership and other key parties in the company about the priorities of
the SAP S/4HANA project and have not agreed on realistic timetables and budgets.
In that case, at this stage, at the latest, you should make a recommendation not to
continue the project.
4.3 Phase 3: Explore (Or Map Business Processes!)
What Is Missed Here Is Hard to Fix Later!
Now the project is taking off. The aim is to develop the best possible support for
essential business processes. The starting point are the default templates that come
with SAP Activate (templates to realise business processes and their implementa-
tion). This content comes from the SAP Best Practices (these already existed in
ASAP) and the solution implementation proposals. They are available as content for
business processes and as content for migration and integration.
So far, so good! The challenge is to align these offers with the company’s actual
requirements (and thus our project’s requirements). Which requirements can be
covered by default (hopefully quite a lot), and which cannot? In SAP Activate, we
are talking about the fit-gap analysis (which was also already available in ASAP).
The aim is to describe the solution: the business blueprint.
Business Blueprint
In the business blueprint, you lay the solid foundations for your SAP S/4HANA
project. You design the future SAP system based on the business process
requirements and decide on the system architecture. Errors and oversights in this
phase put the project at high risk. Corrections in the later course of the project always
mean additional work and, in many cases, delays. This makes it all the more
important that you familiarise yourself with the pitfalls described in the following
sections.
4.3 Phase 3: Explore (Or Map Business Processes!) 109
4.3.1 Business Process Requirements
The development of business process requirements and their implementation in the
new SAP S/4HANA system requires detailed corporate strategies for the coming
years.
Corporate Strategy as the Starting Point
The business strategies and the processes derived from them are usually decided
before the decision for SAP S/4HANA. If such strategies are missing in the project
team or are not sufficiently understood, the following dangers for the project may
arise:
• Requirementsthat are difficult to meet
The process requirements are not aligned with the SAP S/4HANA standard pro-
cesses. It is not sufficiently evaluated to what extent the detailed process
requirements can be mapped in the SAP S/4HANA software. No prototype will be
created to demonstrate the SAP standard’s possibilities to the business departments
for reasons of time and budget. Therefore, the desired processes are not executable in
the SAP system or can only be implemented with a great deal of programming effort.
• Missed opportunities: strategy and implementation do not fit
The business processes described in the blueprint do not fit into the corporate
strategy.
• Processes get out of hand
The process experts in the project develop their own “visions”, which are rejected
once the coordination with the specialist departments takes place.
• Old processes in the new system
The process experts describe what they know, namely, the existing processes. In
extreme cases, this can lead to extensive project effort and business processes
being locked in or frozen for a long time. Especially when switching from SAP
ECC to SAP S/4HANA, many of the new possibilities offered by SAP S/4HANA
are not exploited.
• Unclear requirements
Business process requirements are not formulated precisely enough. To avoid
false interpretations and misunderstandings during implementation in the SAP
S/4HANA system, well-thought-out requirements that fit both the company and
the SAP S/4HANA standard are necessary.
• Incomplete documentation
The documentation of the requirements does not contain sufficient details
required for coordination with the specialist departments.
• No coordination with the specialist departments
There is no formal acceptance of the specialist departments’ new processes, for
example, because business process managers are not involved in the decision-
making processes.
110 4 The SAP S/4HANA Project: How It Is
The business processes implemented in our SAP S/4HANA solution are the main
deliverable of our project. For this reason alone, this phase is of particular
importance.
4.3.2 System Architecture
The definition of the process landscapes has significant impact on the system
architecture. It is often forgotten (or underestimated) that the decision for an SAP
S/4HANA system is also a decision for a new SAP architecture. Thus, many
boundary conditions are predetermined, e.g. a client-server architecture of an
in-memory database system or the programming languages to be used (still ABAP
under SAP S/4HANA).
Hardware as the Basis of Every SAP Project—Even in the Cloud:
An unstable architecture jeopardizes the project: the specifics of the implemented
SAP software scenarios have a great impact on the architecture and the costs. What
are the pitfalls?
• Miss-outs during the software selection process
It is not absolutely clear which systems are upstream and downstream of the SAP
S/4HANA system—or the selection is changed again and again. Often decisions
on the whereabouts or replacement of systems not directly affected by the project
are simply postponed or forgotten. Later in the project, such omissions lead to
changes in the architecture, additional costs or adjustments to the project scope.
• Re-inventing the wheel again and again
The prerequisites that SAP has set for reference architectures are not adhered to.
Instead of learning from the experiences of other projects, the participants design
everything themselves, thus investing more time and money than necessary.
Often only those functions that the consultants themselves know are
implemented. Unknown functions are sometimes imitated (i.e. reprogrammed),
although they are available in the standard system. Quality reviews performed by
SAP Consulting can help as quality assurance in the project (or experienced
consultants familiar with SAP S/4HANA functionality).
• The interface planning is missing
There are studies that in SAP S/4HANA projects, up to 50% of the budget is spent
on integration. Nevertheless, the required integration scenarios (interfaces) are often
unclear, althoughmuch money can be saved through well-thought-out planning, the
use of integration platforms and standardisation. If the SAP S/4HANA solution is
operated in the cloud, interfaces often become necessary across data centre
boundaries. Projects must plan additional expenditure (e.g. coordination with the
network infrastructure operators) to implement and test interfaces.
4.3 Phase 3: Explore (Or Map Business Processes!) 111
Freedom to Adapt the Software:
One of the fundamental questions is how many new system architecture changes
compared to the SAP S/4HANA standard are required/necessary. The various
options for implementing SAP S/4HANA have different specifications. An
on-premise implementation means the software is running in your own computer
centre or with a computer centre operator of your choice, offering the greatest scope
for adapting the software to your own needs. This form of implementation is well
known from the SAP ECC environment. Whether you want to develop your own
functionality or modify SAP S/4HANA standard code—anything is possible. And
these possibilities are often very tempting.
The situation is different with SAP S/4HANA Cloud. There are limits to
enhancements, and modifications are simply impossible. The use of SAP’s
“preconfigured” solutions for processes mapped as standard in S/4HANA is per-
fectly adequate for smaller companies or companies with a standard process land-
scape. For these customers, the use of SAP S/4HANA Cloud has great advantages.
There is no obstacle to using the latest innovations with each new release. And the
constant discussion about whether certain, cherished “special features” need to be
incorporated into the new S/4 solution has been settled from the outset: it is simply
not possible—full stop! However, foresight is required here. Even future
requirements that deviate from the standard will not be realisable in S/4HANA
Cloud, but only in external systems.
4.3.3 Project Standards and Procedures
If you have not set standards for your project and disagree on how to proceed, you
will not succeed. If standards and procedures are defined, but nobody follows them,
you will also not succeed. Do you want to know what problems you may encounter?
Here’s the scoop:
• No stable project structure
Project organisations, project methods and procedures are casually or even
spontaneously changed. For example, tasks are reassigned, teams are regrouped,
documentation and reporting structures are changed, or processing cycles are
restructured. As a consequence, you can expect additional training effort and a
lack of transparency.
• Project management tools are not used
Tools for planning, management, documentation and controlling are not used to a
sufficient extent or not at all.
• Unclear communication channels
Communication is the key to success, and yet communication and escalation
channels are often not clearly defined as mandatory. There are no fixed dates for
status meetings, steering committee meetings or communication with
112 4 The SAP S/4HANA Project: How It Is
stakeholders. This leads to uncertainty and mistrust at all levels regarding the
status and impact of the project.
• Lack of documentation standards
Standards for the documentation of processes and system solutions (configura-
tion/programming) are missing.
• Documents are lost
There is no filing structure for documents, which significantly reduces
retrievability. In other words, you can't find what your are looking for.
• Knowledge transfer not organised
No system is used for knowledge storage and knowledge transfer. Alternatively,
there may be a system, but not all project staff have been trained in its use.
• Moving away from the SAP standard
Special requirements that can be mapped in the standard but are “much nicer” if
developed in-house can often be implemented on-premise, but they often cannot
be implemented in the cloud.
Certain project standards recur timeand again. In such cases, the project team can
use the experience from previous projects and external project staff.
4.4 Phase 4: Realise (Or The Implementation)
The Realisation Phase: A Long-Distance Run
Even if you have gone through the previous phases strictly according to project
management rules and almost without a blemish, you are still far from reaching your
goal. In the longest and most difficult phase of a project, the number of errors and
omissions naturally increases.
In this section, we would like to show you which errors can occur in the areas of
project management and control, the configuration of SAP S/4HANA systems, tests,
data migration and change management.
For They Know Not (Yet) What They Do:
Before we delve into the details, we would like to address one of the most common
omissions that affect all the tasks mentioned above during the realisation phase. As
you enter this most complex phase of the project, the number of project staff
increases—new colleagues join your project. The new team members’ training and
the team’s preparation for the realisation phase tasks are often underestimated.
Therefore, take new team members by the hand!
4.4 Phase 4: Realise (Or The Implementation) 113
4.4.1 Project Management and Control
An important success factor is the management and control of the project by the
project leadership and the project management office (PMO). Deficits in expertise
and leadership are immediately reflected in the progress of the project. Here are two
practical examples:
• Professional competence as a stumbling block
The project manager considers himself/herself the best specialist. They try to turn
visions into reality by describing and specifying the new processes. Project staff is
thus forced into a supporting role and lose their initiative and drive.
• Loss of confidence
One party (either the consulting company or the client) changes the project
manager without consulting the partner in a project. Such behaviour can lead to
anger and mistrust in the project.
• Deficiencies in leadership behaviour
The project manager has professional deficits and/or weaknesses in communica-
tion and leadership behaviour. He/She:
– Cannot delegate
– Takes over critical tasks him- or herself
– Is too deply involved in detailed tasks
– Does not understand how to promote team building
• Lack of professional competence in the project management office
The staff in the PMO are not sufficiently qualified for their central task in the
project. For example, there is a lack of business management competence to
assess project situations correctly.
• Lack of soft skills in the project management office
The PMO staff cannot detect atmospheric disturbances and the resulting risks for
the project’s progress at an early stage.
• Controlling becomes an end in itself
Project management develops a life of its own: using tools and gathering project
data and key figures without recognising and initiating necessary measures from
the controlling mechanisms does not help the project.
• The project status is always green—no matter what
The transparency of the project status leaves much to be desired. There is no
honest status communication, information is suppressed, and problems are
minimised. The left hand does not know what the right hand is doing.
• Lack of consequences
Deadlines are missed without action being taken. There is no objective evaluation
of partial results and implementation steps. Identified weaknesses are ignored or
not consistently pursued and remedied.
• Teams work in silos.
Individual teams devote themselves to team-specific subtasks, whose results
cannot be integrated and corrected later or only with great effort.
114 4 The SAP S/4HANA Project: How It Is
• Skills are missing or lost
Skills are often missing or lost; this problem can have many faces:
– It is only in the implementation phase that it is recognised that internal and
external project staff lack important know-how.
– Central competencies are lost because indispensable employees leave the
project prematurely.
– Departments withdraw their staff, employees resign or are promoted too early,
and external consultants are dismissed.
• Project reviews do not take place
– Project reviews are not carried out at all, or not carried out with the necessary
care.
The longest phase in a project also requires staying power and a consistent focus on
what is important in the project.
4.4.2 Configuration of the Systems
In general, your originally estimated and planned expenditure is put to the test in this
phase. This is the time when realistic planning and experience really pay off. The
configuration of the SAP S/4HANA system is based on detailed descriptions of the
process steps as they are to be carried out by end users.
Additional Work for Customising?
The realisation phase now shows to what extent the often optimistic ideas in
planning the expenditure (in phase 1) and the detailed description of the process
requirements in the blueprint (in phase 2) can be implemented with as little program-
ming effort as possible.
So what can happen when customising the SAP system?
• Additional expenditure due to lack of knowledge about the SAP standard
To solve the new processes only via customising in the SAP standard is the dream
of all project clients and the project management! It often looks like this: the
process steps cannot be implemented in customising, and the programming effort
increases. The causes for the increase are often a lack of detailed knowledge about
the possibilities in the SAP S/4HANA standard when defining the processes and
the specialist departments’ lack of willingness to tread new ground.
• Process Creep
The processes defined at the beginning of the project are moving further and
further away from the SAP standard. One reason for this may be that those
responsible are trying to avoid permanent and exhausting fights with the specialist
departments in the interests of project progress.
• Requirements never end
A weak or even missing requirements management leads to the constant addition
of new requirements. This can make it exponentially more difficult to adhere to
4.4 Phase 4: Realise (Or The Implementation) 115
the project duration and the project budget. The project leadership often neglects
setting deadlines to submit requirements or neglects to communicate these
deadlines within the company.
• Financial targets and budgets were too ambitious
The expenditure shown in the original plan is so tightly calculated that there is
hardly any room for additional requirements. Nevertheless, if you accept new
requirements, this will increase your effort, budget and project duration. Perhaps
the cost estimates were also too optimistic in the preparation phase, e.g. because
the effort involved in error correction was underestimated.
• Superficial requirements analysis
If the requirements analyses are missing or superficial, you risk additional
expenses and integration risks for process flows and system architecture.
• Changes without approval
The requirments approval process, if it even exists, is not strictly adhered to with
increasing pressure towards the end of the implementation phase. Changes are
then often implemented without project management’s awareness or approval.
This phase also shows whether all the good ideas can be implemented in the
system. At this point, creativity is sometimes key for a successfully realisation.
4.4.3 Testing
Your System on the Test Bench
An important pillar for completing the new system is testing all components,
including testing across SAP S/4HANA boundaries. Ultimately, the decision to go
live with the new system depends on the results of the tests. A test’s significance
stands and falls with the test employees’ professional and methodical qualifications
and well-founded and realistic test planning.
Unfortunately, these requirements are not always met in real-life, but instead, you
will be confronted with the following situations:
• Underestimatingthe importance of testing
The importance of the tests and their complexity and thus the preparation time are
often underestimated. Under time and budget pressure, no dedicated test team is
then established. Instead, an attempt is made to manage the test only with virtual
part-time resources.
• Lack of testers
There is a general reluctance among the specialist departments to make their best
employees available for test tasks and to release them from their operational
activities for the test period.
• Shortcomings in test planning and test methods
There is no successful test without specialist knowledge: there are shortcomings
in test planning and using modern test methods and test test tools, leading to
116 4 The SAP S/4HANA Project: How It Is
insufficient test coverage. Much is left to chance, as well as the personal skills of
the staff overseeing the test, which usually negatively impacts test coverage.
• Test environment missing
The test environment (in the SAP S/4HANA system and upstream/downstream
systems) is not always available when starting the test. The underlying causes can
be manifold. For example, master data has not been loaded in time, or it was
neglected to order test machines in time. Potential system limitations are not taken
into account with foresight during test running in parallel.
• No coordination of the test strategies
The test strategies and test coverage are not coordinated with the relevant
company units before starting the implementation phase.
• Too much test effort
Often there is a lack of understanding for test optimisation on the part of the
company units; everyone wants to test the overall processes. This would lead to a
massive increase in testing efforts, e.g. in cross-border implementations.
• Tests happen too early
Due to the deadline pressure towards the end of the realisation phase, tests are
started, although development is still in progress.
• Missing test data
The “real” data, i.e. the data transferred from the legacy systems in live operation,
is missing for the test cycles—possibly because the data migration is not yet ready
or because the planning does not fit. Testing is done with “synthetic” data. Often,
however, not all possible data constellations can be tested in this way, and the
nasty surprise follows after the actual data migration—often too late.
Testing the solution is one of the most exciting stages in the project. Now you see
whether everything works as intended. The (successful) test is also essential to
minimise the risk of going live!
4.4.4 Data Migration
Data Migration: An Underestimated Task
In Chap. 2, “What Makes an SAP Project So Different?”, we have already
complained that data migration often does not receive the necessary attention.
Unfortunately, the effort required to transfer the data to the new systems is often
underestimated. Remember that a successful data migration requires a team of
experts who work parallel with the system configuration.
The key risks associated with data migration are as follows:
• Lack of qualifications
It is not recognised how much expertise is required for data migration, presenting
the risk that the employees deployed do not have the professional qualifications
for this task. The transformation of old data into the new SAP data structure
requires a thorough knowledge of the business processes and business data and
4.4 Phase 4: Realise (Or The Implementation) 117
your new SAP S/4HANA system components. Because configuration and data
migration activities overlap, there is a risk that your top process experts will be
deployed primarily for process design. The migration from SAP ECC to SAP
S/4HANA is a big job because the data model has changed fundamentally.
• Data mapping
Data mapping activities are not seen as an iterative process parallel to system
configuration and are therefore initiated too late.
• Garbage Out, Garbage In
The cleansing of old data before transfer to the SAP S/4HANA system is often not
given the necessary attention and care. To believe that the migration to the new
systems would solve all data problems always proves to be a fallacy. Existing
problems are thus transported into the new system.
• Data load programs are not tested
Usually,there are large amounts of data to be loaded, which means highly
automated data load programs are required. If you fail to create sufficient control
mechanisms for the correct data load, you will inevitably run into productive
operation problems.
With the SAP S/4HANA Data Migration Cockpit, a highly sophisticated data
migration tool is available with SAP S/4HANA. This tool is certainly no panacea for
all possible migration scenarios, but it is a the best starting point. In Chap. 9, “Project
Support Tools,” we will discuss this in more detail.
A common reason why projects are not 100% successful is that many of the
problems described here are linked to small mistakes, which are often not individu-
ally recognised as problems during the project. Only with integrated testing across
functions and systems can the new SAP S/4HANA solution’s proper functioning be
guaranteed.
4.4.5 Change Management
Heard it Through the Grapevine:
An SAP S/4HANA project always entails changes in process flows that have a
potential impact on business models and company organisations. This can lead to
FUD (fear, uncertainty, doubt), a climate of insecurity and fear of retrenchments. A
lack of transparency and guidance are the ideal breeding ground for rumors and
concerns. Open or hidden adversity or slow-walking can be the result.
There is no way around proactive change management. If you fail to involve all
affected employees and managers in the transformation process, you will jeopardise
your project’s acceptance.
What are the most common pitfalls that you should avoid?
• Lack of coordination of project objectives
Project objectives are not coordinated with all business units.
118 4 The SAP S/4HANA Project: How It Is
• Question marks in their eyes: regular updates are missing
Management and employees are not regularly or openly informed about project
results and impacts.
• Unsuitable training concept
The training concept is not specifically geared to the knowledge needs of the
respective employee groups.
Change management is perhaps the most underestimated topic in transformation
projects. Each of these projects leads to many changes in processes, organisation or
the cooperation between people and departments. If the workforce is not adequately
prepared and brought on board, conflicts and rejection are inevitable.
4.5 Phase 5: Deploy (Or Preparation for Going Live)
Preparation for the Go-Live
You still have the last few yards ahead of you, and then the big goal, the go-live, will
be achieved. Now you must make the final preparations for the production startup.
The last go-live preparations include training future end users and planning the
go-live. If you use SAP S/4HANA cloud, your colleagues from the large cloud
providers’ support organisations, who are often not known by name, will be added.
The necessary support processes must be clear, and the employees must be prepared.
Here are the topics that must be addressed.
4.5.1 User Training
In Chap. 3, “The SAP S/4HANA Project: How It Should Be”, you learned that
training end users well is one of the key success factors in the SAP S/4HANA
project. If the end users are well-trained, the support effort will be reduced, and you
will avoid unnecessary friction because you will be able to recognise the users’
worries and needs and address them. But even during planning stage of your training
curriculum, you may make mistakes which may come back to bite you later. This
includes the following:
• Who should be trained?
Nobody really knows what the individual training needs are.
• Insufficient training material
The departments are not involved in the production of the training material. There
is, therefore, a risk that the training material is too strongly system-related and not
sufficiently process-and user-oriented.
• Missing training systems
4.5 Phase 5: Deploy (Or Preparation for Going Live) 119
The training systems are not available in time, or the data in the system is not up
to date.
The users from the departments are the most important indicators for a successful
project. Only when they are familiar with the system, the project can be successfully
completed.
4.5.2 Going Live
Get Ready: Get Set—Don’t Go!
It is almost done: the start date is set, and all data migration activities have been
determined. But wait: is everything really prepared? Possibly not, because one or the
other activity may have been forgotten in your project:
• Unfinished productive systems
Setting up the productive systems takes more time than planned.
• Missing interfaces
The interface connections have not been agreed upon with all involved parties.
• Inadequate quality assurance
Quality assurance measures are not given the necessary importance or even fall
victim to time pressure.
• Testing has been neglected
The final productive system tests (performance tests or stress tests) have not been
thorough enough.
• The data load takes longer than anticipated
The time needed to load the legacy data is underestimated (possibly insufficient
testing was done).
• There is no master plan
The cut-over plan is not complete or too imprecise and not agreed with all parties
involved.
Going live is the final milestone in every SAP S/4HANA project. Now is the time
when it is decided whether the project is a success or a failure. It would be a pity if a
major transformation project failed or had to be postponed just because of missing
hardware or other “minor oversights”.
4.6 Phase 6: Run (Or Go-Live and Support)
Last Check:
Even when the decision to go live has been made, it is still too early to sit back and
celebrate. It is important to avoid typical pitfalls:
120 4 The SAP S/4HANA Project: How It Is
• Going live although critical errors have not been fixed
The pressure of implementing on time leads to putting the system into production,
although critical errors have not yet been eliminated. This, in turn, can lead to
serious disruption and stress in the production system.
• Non-functioning support systems
Neither the internal nor the external support structure is fully established for going
live. If the support is not provided efficiently and competently, especially at the
beginning, this negatively impacts the employees’ acceptance of the new system.
• Loss of competence
Employees with project-critical skills leave the project too early and are no longer
available for the stabilisation phase or further support.
• Downtimes are exceeded and no precautions were taken
The downtimes during the system changeover for going live are underestimated
and therefore need to be extended, leading to serious impairments in the handling
of business processes. The handling of business processes during downtime is not
sufficiently coordinated within the company.
• Incomplete documentation
The documentation of the processes and system solutions is not complete or not
detailed enough for going live. This makes error analysis and error correction
considerably more difficult.
Before we close Pandora’s box again and devote ourselves to the project staff in
Chap. 5, “The Underestimated Success Factor: People”, we would like to present our
personal “hit list” of typical pitfalls.
4.7 The Top Flops in the SAP S/4HANA Project
Mishaps, Bad Luck and Epic Fails:
We have compiled the best of the best of mishaps, bad luck and epic fails from our
practical experience. Do not do what is described in the following sections!
4.7.1 Pitfalls Throughout the Project
You underestimate that an SAP S/4HANA project is not a simple IT project but has
serious impacts on processes, jobs and organisations.
You do not ensure that project management and project staff meet the complex
SAP S/4HANA project requirements. The problems include both technical deficits
and weaknesses in management and communication behaviour.
You have not agreed on the project objectives with all business units concerned
and do not inform them of the results.
There is no clear requirements management process.
You underestimate that many small, individually unimpressive problems can end
up adding up to one massive problem, both in terms of time and content.
4.7 The Top Flops in the SAP S/4HANA Project 121
4.7.2 Phase 1: Discover
Although the project starts with a well-considered idea, the actual scope is not
defined or not adopted, opening the door to possible problems.
You fail to get the project sponsors to commit to a marathon. Without the support
over the project’s full duration, you lack the necessary support of the sponsors—
especially when it comes to critical decisions.
Although you defined and approved a well-prepared project idea and scope, you
did not deal with the new possibilities of SAP S/4HANA (and what is not (yet)
possible).
The product SAP S/4HANA is continuously developed during the project
period—currently one release per year. Whether it makes sense to “take” each
release with you in the project needs to be well considered.
4.7.3 Phase 2: Prepare
The project plans are too aggressively optimised towards a (given) target date.
Planning is too superficial, milestones are not defined, and there are no critical
paths.
Project and process responsibilities are not clearly defined.
You don’t have the right experts (with the required skills) on board.
Although the right experts are involved in the project, they are busy with day-to-
day business, and the project suffers as a result (“Making money is more important
than spending money”).
4.7.4 Phase 3: Explore
Corporate strategies are missing or not understood by the project team. Therefore,
they develop their own visions or continue with obsolete processes.
They do not know what possibilities the SAP S/4HANA standard offers and do
not consider these in the process design.
No final decision was made on the system architecture and interface scenarios.
When defining integration scenarios, interfaces between data centres are defined
without considering possible restrictions (e.g. data security requirements).
4.7.5 Phase 4: Realise
Essential knowledge is is lost during the project.
Quality assurance measures are insufficient.
Tests are started although development is still ongoing.
You underestimated data migration from the old systems into the new system and
did not pay attention to the employees’ professional qualifications.
122 4 The SAP S/4HANA Project: How It Is
You have failed to clean up the legacy data before the data migration.
The project scope is not consistently monitored. Changes are not aligned with the
budget and schedule (change request management): this causes delays in the
project’s course compared to the original time and budget plan. The planning
becomes increasingly unrealistic, and the project is delayed.
Functional and integration tests are created and carried out with data specially
created for the test instead of real migrated data. These tests’ seemingly positive
results are deceptive—they say very little about whether the system will run reliably
after the go-live with the migrated data. This kind of test is pointless—don’t bother.
The data migration duration from legacy systems is underestimated or given less
priority because of an existing project delay. This leads to problems with data quality
at best in the final integration test (or worst case, only after go-live) and can result in
high costs and project delays.
Important interfaces are not sufficiently tested before going live, as there is no test
environment with suppliers. Be sure to look for creative solutions to perform
interface testing as best you can.
4.7.6 Phase 5: Deploy
The training material does not meet the requirements of the end users.
The time needed to set up the productive systems is underestimated, and the
involvement of external experts from the computer centres arrives too late.There are no clear decision criteria to determine if the go-live was successful.
Interfaces to production systems are tested for the first time during go-live and do
not work.
4.7.7 Phase 6: Run
Excessively long downtimes before going live can impair ongoing business
processes.
The support structure is not sufficiently established. Important knowledge is lost.
The quality of implementation and data migration often only becomes apparent
after a certain period of time. This delayed manifestation means that events that do
not occur immediately after production, such as month-end closing, MRP runs or
similar, must be checked in detail, even if all tests were successful.
4.7 The Top Flops in the SAP S/4HANA Project 123
The Underestimated Success Factor: People 5
Among the many factors that determine a project’s success, some are more important
than others: the people involved in a project are among them. In this chapter, we
would like to show you how to give the people involved in your project the
importance they deserve. And because we know that a lack of time and the
complexity of an SAP project can block your view of what is essential, we give
you practical tips from our wealth of experience to help you do this.
Project Team
You will learn who belongs to the project team and why you would benefit from a
broader understanding of the term “project team” and the importance of project
management for good teamwork. Because the qualifications, personal aptitude and
availability of project members are the main criteria for selecting personnel for
project staffing, we dedicate a separate section to this topic. We also show which
key factors lead to high performance in a project team.
On one hand, it is essential to bring the right people together in the project. On the
other hand, communication must also work. If the communication is not effective,
even the best project manager with the most capable team will not lead the project to
success. The right communication is a decisive factor for success. Project leaders
often underestimate the importance of communication in their projects. Paradoxi-
cally, the bigger and more complex a project is, the more undervalued communica-
tion is, although it is particularly important in such projects. We, therefore, explain
how you can cultivate communication as a further success factor with effective
communication structures, a supportive project culture and stakeholder-oriented
messages.
There is hardly a major SAP project in which people from different countries and
cultures do not work together. International staffing in SAP projects can be both a
curse and a blessing. We consider it above all as a blessing! In the following
chapters, you will learn about the pitfalls of working with and in internationally
staffed SAP project teams and how to avoid them.
# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_5
125
http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-86084-4_5&domain=pdf
https://doi.org/10.1007/978-3-030-86084-4_5#DOI
Effects of Digitisation in Project Management
No area of modern life is developing faster and with more far-reaching significance
and consequences than technology. These effects, in particular digitalisation of the
world of work, can also be observed and felt in the project area. We explain the
essential impact digitalisation has on project management and how to deal with them
to benefit your project’s success.
This chapter is about something close to our hearts—the people who work
together in SAP projects, day after day and often for years. In an SAP project, the
SAP landscape and business processes of a company are “transformed”, as are the
people involved in the project. We have interviews with some people who have
gained a lot of SAP project experience. It was important for us to be able to offer you
the widest possible range of expertise. That is why we spoke to people who have
experienced transformation projects from different perspectives, as project members,
project managers or stakeholders—from developers and experienced consultants* to
CIOs.
We asked them the following questions on the different topics in this chapter:
• Which factors or circumstances played a decisive role in your most successful or
unsuccessful/failed projects?
• How present were the criteria for a high-performance team in the successfully
completed projects in which you were involved?
• How do you rate the criteria for team performance in projects that were not
completed successfully or only with a significant time or budget overrun or
change of objectives?
• Based on your experience, which factors represent a high or the highest burden
for the project staff?
• What kind of help or support would you most like to see in the project?
• Which skills are important for project management concerning digitalisation?
• What advice would you give for better cooperation and better results in the
project?
You will find “sound bites”, unedited excerpts from the answers, in this chapter.
These interview excerpts are in italics.
One more note, if you have difficulty putting an idea, statement or tip into a
particular drawer of project management, remember that much of this book reflects
the experiences of project stakeholders. The theory often cannot be put into practice
without adaptation. We derived the insights and best practices from the hard lessons
of failure and the successful application of theories.
5.1 Who Belongs to the Project Team?
Together We Are Strong
A good team is more than the sum of its members: in addition to their technical
expertise and qualifications, the project team members must bring something extra to
126 5 The Underestimated Success Factor: People
put their project in the fast lane. This section shows you what abilities and personal
qualities the people who fill these roles must possess.
Roles in an SAP Project
Let us look again at the roles in the SAP project, which you got to know in Sect. 2.2.1,
“What Is a Project?”
• The project leadership (including project project management)
• The operational project team (the task force)
• The client
• The business process managers
• Key users from the respective specialist departments
Stakeholders are all those who can impair or hinder the project through their
actions but who can also support, encourage and promote it. This definition applies
regardless of the roles, tasks and interests in and on the project. In our many years of
project experience, we have learned, among other things, how important it is that all
stakeholders, as part of the extended project team, be seen. This approach supports
the project’s sustainable success: even after a successful project conclusion, the
processes, structures and, if necessary, the new culture introduced in the project will
last long enough to produce the desired effects.
The extended project team approach can be very helpful if you do it right. If you
do it the wrong way or do not recognise the stakeholders’ importance, you may
experience delays and disruptions or even see your SAP project fail.
Stakeholders in the SAP Project
The obvious stakeholders in addition to the project team:
• The executive leadership
• The heads of department
• The steering committee
• The works council
Less obvious stakeholders include the following:
• External suppliers or customers
• Consultants
• Placement agencies
• Employees in other divisions not directly involved
Figure 5.1 provides an overview of the people who belong to the extended project
team.
5.1 Who Belongs to the Project Team? 127
Fi
g
.5
.1
O
ve
rv
ie
w
of
th
e
ex
te
nd
ed
pr
oj
ec
t
te
am
128 5 The Underestimated Success Factor: People
Tip: Know the Stakeholders in Your Project!
Create an overview as early as possible of all groups and people who might be
interested in your SAP project. Makea note of what these interests are and
how they relate to the project’s course and outcome. In what ways can they
support your project or, on the other hand, hinder it? This assessment is the
only way you can establish effective stakeholder-oriented communication.
Taken from Project Life
We would like to illustrate the importance of stakeholders with an anecdote. The
placement agency E-Z Expert (the name is fictitious) is supposed to provide a project
with professional expertise not available within the company to a sufficient extent.
With this company and all other suppliers and service providers, carefully
proofed contracts are made—just like all E-Z Expert customers. In addition, the
person responsible, Mr. Miller, has maintained good relationships with some top
placement agencies, including E-Z Expert, for a long time.
During the course of a project, two experts critical to the project’s success are
unexpectedly unavailable. When this happens, E-Z Expert goes to great lengths to
find the necessary personnel within the shortest possible time. They also ensure good
contract terms, without the surcharge usually required when the placement must
happen extremely quickly. Why is this so? Every organisation comprises people
who prefer to work with other people who value them and their work and treat them
with respect. Mr. Miller understands well how to treat the service providers as part of
his extended project team. Through open communication and binding dealings, he
ensures that the projects he manages receive higher prioritisation and particularly
reliable support.
The project manager or project leader, who behaves like Mr. Miller, is not only
pleasant and professional; they also have leadership qualities and “preferred” status
with suppliers and service providers. She or he receives the best possible price for the
best possible service. For Mr. Miller, this means that even experts can be conjured up
(almost) out of thin air when, despite the best planning, there is a sudden bottleneck
in the project. This kind of “magic” means that the project avoids costly delays.
Win-Win Situation
As a project leader or project officer, you will stand out from the crowd if you set the
course for the appreciative treatment of every individual on the extended project
team. You will see the people, who are often only on the project sidelines, as the
valuable resource they are. It is a win-win situation for everyone involved.
In the next section, we look at the key skills that all project team members need to
bring or cultivate to contribute to the project’s success. In line with our recommen-
dation in Sect. 2.2.2, “What Types of Project Management Are There?”, to opt for a
5.1 Who Belongs to the Project Team? 129
pure project organisation for large transformation projects, we emphasise the impor-
tance of project leadership here.
5.2 The Importance of Project Management Leads
“To whom much is given, much is required”—this saying has never been more
appropriate than in the context of good project management. One of the most
far-reaching decisions for the success of a project is made early on in the project’s
course, but often without enough foresight: who will become the project manager?
Note: Project Management as the Supporting Pillar of the Project?
In transformation projects, even with agile parts, there is still project manage-
ment. Although the project manager is no longer the sole focus of the project
team, the role is still very important. He or she takes on a wide range of tasks
and maintains an overview of the entire project. At the same time, the project
lead is the link between the different groups and people in the project teams.
One of the project manager’s most important tasks as project lead, is to ensure
good communication at all project levels and with all project participants and
stakeholders. In doing so, the project lead must always convey messages in an
appropriate way for the target group.
A special challenge in connection with agile methods such as Scrum is that
for correspondingly large projects, instead of just one project leader, several
product owners are required. They all must also meet the high demands of this
role, especially in their communication skills.
The project leader must have the full support of both the client or project owner
and the top management. If a project manager is assigned to a project despite
reservations from key stakeholders and decision-makers, they will soon face addi-
tional resistance within the project. In such situations, even the most competent
project manager will find himself in a “fight against windmills”.
There are plenty of examples, even outside of transformation projects, which
show how unfortunate the situation can be, both for those affected and for the project
itself, when a project manager, take ‘or project lead’ out is appointed who is perfectly
capable but controversial and who is not accepted by all decision-makers. To
illustrate, we will take the United States’ former president, Barack Obama, as an
example. Many projects that were very good in terms of content had little chance of
success right from the start because of strong political headwind stemming from his
opponents’ resistance towards him as an individual.
I am president, I am not king. I can’t do these things just by myself.
(U.S. President Barack Obama from a transcript of an interview with Univision Radio,
LA Times, October 25, 2010)
130 5 The Underestimated Success Factor: People
Project Management Skills
The project manager is to a certain degree like a Swiss Army knife. Without equating
a project manager to a popular multi-tool, we want to highlight what high
expectations and demands are placed on project managers.
In my most successful projects, the project managers always worked in a very structured
way. They communicated with all stakeholders, and they knew exactly who needed which
information and reports. (Quote from a project leader)
Suppose you have had the pleasure of slipping into the role of a project manager
in large projects or of working with a very good project manager. In that case, you
know that you also need a variety of personal qualities in addition to good specialist
knowledge. Digitalisation and the desire to use more agile working methods have
added to the already long list. In the following list, we have set and an asterisk
(*) next to the skills that are particularly important in connection with digitalisation
or more agile working methods. We also explain these in more detail below.
The skills of a project manager include the following:
• Agile mindset*
• Tolerance of ambiguity*
(serenity in dealing with ambiguity and uncertainty)
• Analytical capability
• Adaptability*
• Readiness to delegate
• Assertiveness
• Dynamism/commitment
• Decision-making power
• Creativity*
• Conflict ability*
• Willingness to cooperate
• Willingness to learn*
• Motivation
• Optimism*
• Organisational talent
• Resilience
• Entrepreneurial thinking
• Readiness to take responsibility
• Negotiating skills
• Networked thinking (concerning all teams, areas and stakeholders)
• Trust*
• Goal awareness
• Targeted and solution-oriented action
5.2 The Importance of Project Management Leads 131
Below you will find the previously mentioned explanation of the characteristics
and skills that with the increase in digitalisation and the introduction of agile
methods, will take on increased importance for project management.
In a VUCA world (Volatility, Uncertainty, Complexity, and Ambiguity), it is
important to have the following qualities as a project manager:
• Agile mindset (way of thinking)
It is important to have an agile mindset in order to promote this in the project and
to contribute to an agile project culture as well as an agile corporate culture.
• Tolerance of ambiguity
Tolerance of ambiguity is important to be able to accept different opinions and
points of view and to be able to tolerate ambiguity and contradictions in situations
and actionswithout feeling uncomfortable or reacting aggressively.
• Adaptability
Adaptability enables you to pursue and achieve a goal despite constant change.
• Readiness to delegate
A willingness to delegate is a necessary characteristic, regardless of the chosen
project management methodology. Today, a successful transformation project is
not possible without transferring responsibility to the right experts.
• Creativity
If only the goal is clear, but the way is still unknown, one must be open to new,
creative ideas.
• Conflict capability
It is important to be equipped with the necessary resources that enable conflict
ability because flattening hierarchies often make conflicts visible much earlier.
Conflict capability offers a great advantage in handling disputes and conflicts in
the right way.
• Willingness to learn
The rapid pace of digitalisation requires ever-new skills, new knowledge and
continuous learning.
• Optimism
Optimism is important because, in projects where an iterative approach prevails,
temporary defeats and setbacks must be dealt with positively. Both a positive and
a negative attitude have a contagious effect on the project team.
• Networked thinking
Another basic prerequisite is the ability to think in a networked way—in terms of
all the teams, departments and stakeholders with whom we work closely and
whose different needs must always be kept in mind. Networked thinking is
essential in terms of the project’s technical aspects and the communication and
change management aspects.
Trust
It is important to have a high degree of trust, especially with a mixture of classical
and agile methods, because the project manager does not determine the approach.
The project leader has to delegate much more and grant decision-making powers to
132 5 The Underestimated Success Factor: People
other participants or at least accept that they have them. It is important to trust in the
expertise and others’ ability to judge, for example, in the development team.
Management Tasks of the Project Management
In order to be able to master the various steering and management tasks that await
him/her in a project, the project manager must also have specialist knowledge and
project experience. Still, leadership and management skills are much more impor-
tant. If you recognize yourself in the following descriptive list for a project lead*,
you have the best prerequisites to master your SAP project with flying colours—and
if you notice that you do not yet meet all the criteria, you now have the chance to
build up these skills.
Key leadership responsibilities of project management include the following:
• They should be role models, i.e. they should set an example of the desired and
expected behaviour or appearance in the project.
• They should be able to communicate project goals, milestones, plan changes,
project status and problems to all relevant project participants. At this point, the
information on the current status of the project, as just described, should be
independently accessible to all project members at all times to enable more
agile work.
• They should accompany the selection interviews for key positions in the
project team.
• They should be able to conduct employee interviews and provide coaching for
employees.
• They should encourage team building and all team members’ involvement, taking
into account individual and professional needs and skills.
• They should manage and resolve conflicts.
Tip: Solving Conflicts Constructively
If you understand how and why conflicts arise, you can better manage and
resolve them. A simple and effective way to deal with conflicts (not only in a
project) is the so-called nonviolent communication of Dr. Marshall Rosenberg.
The main principles of nonviolent communication are as follows:
• Identify your observations, feelings and needs, and learn to express them
without blame.
• Learn to recognise and accept the observations, feelings and needs of your
counterpart without criticising them.
A detailed description of these methods of conversation can be found in
Nonviolent Communication; A Language of Life by Marshall Rosenberg (3rd
Edition 2015).
5.2 The Importance of Project Management Leads 133
Organisational Tasks of the Project Management
The project processes and tasks with which the project specifications can be adhered
to are planned, monitored and controlled by the project management and the
specialist project managers. The most important organisational tasks of the project
manager include the following:
• Coordination of objectives and expected results
• Coordination of milestones
• Scheduling and monitoring
• Budget planning and monitoring
• Definition and organisation of necessary resources
• Distribution of tasks within the team: with an agile approach, this task is left to the
development team itself
• Initiation of external resource procurement
• Dynamic risk analysis (before and during the project)
• Convening and organising necessary meetings with the project teams and other
stakeholders
• Reporting
• Controlling
Note: The Project Management Office (PMO)
In large projects, a project management office (PMO) carries out plan controlling
and monitoring. The PMO and its tasks are described in detail in Sect. 3.3,
“Everything Perfectly Prepared: The Ideal Conditions”, and in Sect. 6.1, “Sup-
port Whenever You Need It: The Project Management Office”. The PMO is a
very important support and information source for project management. They
must be able to rely on the PMO to monitor the project and inform them
immediately of any deviations from the defined objectives, deadlines and results.
First of all, we discuss which specific management and leadership skills project
leadership requires. Since both management and leadership skills are essential for
successful project completion, we have very consciously decided at this point to
consider these two areas separately. We start with management skills.
Leadership Skills
To get started, we would like you to express your opinion. Take a pencil in your
hand, think for a moment, identify five skills that you feel are essential for successful
leadership in a project, and write them in the boxes below.
1. Xx
2. Xx
3. Xx
4. Xx
5. Xx
134 5 The Underestimated Success Factor: People
You see, you have taken on this small task and taken a stand. Openness and
decisiveness (not stubbornness) are some of the qualities that are extremely helpful
for successful project leadership.
From our viewpoint, the five most important leadership skills for project man-
agement are as follows:
• Communication skills*
• Social competence*
• Operational management skills (e.g. delegating work and employee coaching*)
• Knowledge of methods
• Professional competence
Communication Skills
The complex leadership role of project leadership requires very strong communica-
tion skills. These enable project leaders to communicate tasks, goals and milestones
effectively. They help to express praise and recognition in a targeted and effective
manner. Only a few project managers who have excellent communication skills can
conduct even difficult discussions in an open, direct and goal-oriented way. Effective
communication is so important for a project’s success that we will go into more
detail later in this chapter.
Social Competence
Authenticity, sovereignty and emotional intelligence (including, and in particular,
empathy and influence) as an expression of social competence are also essential for
the project leader to understand, motivate and bring the project team together. This
team often consists of several individuals, smaller teams and other groups. The ever-
increasing possibilities of digitalised and global working mean that the participants
often come from diverse cultures worldwide. The team comprises experts, both from
the same and different professional backgrounds with various tasks, knowledge and
expectations, between whom it is necessary to mediate. The team also consists of the
stakeholders alreadymentioned, some of whom have very different expectations.
The project management must meet these groups of people at eye level to inform and
convince them.
Note: The Importance of Soft Skills
The common values, interpersonal skills, knowledge and organisational cul-
ture are called soft factors. Do you believe that it is worth investing time,
energy and money in the so-called soft factors in your SAP project? If not, you
are not alone: many project managers and the management are often not
convinced of the benefits of such investments. This doubt is unfortunate, and
it can be costly. It is often the neglect of the soft factors that causes a belly-
landing in the project—anything but soft! And the money that a project plans
to save on the soft factors is usually spent on damage control in the end,
making the inglorious belly-landing even more painful.
5.2 The Importance of Project Management Leads 135
Operational Management Capability
Operational management skills often play a role in large projects. They include the
monitoring and controlling parts of the operational project management tasks,
e.g. cost estimates or the assignment of work packages, which the project leader
further delegates. The project leader must have an eye and a feeling for which tasks
they can delegate and to what extent. Because even if important tasks are delegated
and others must and should do them, the main project leader remains responsible for
the results.
Methodological Competence
Methodological competence describes systemic, proven knowledge that enables a
person or organisation to obtain, structure, process, correctly interpret and repeatedly
apply and present information in different forms using suitable tools, techniques and
methods. Examples of methodological competence include the ability to find or
identify the right solutions even when faced with a multitude of possibilities,
moderate discussions in a goal and result-oriented manner, resolve conflicts or
ensure quality management across project interfaces. Methodological competence
offers structure and, at the same time, flexibility in problem-solving and is enor-
mously important for project management to achieve good results reliably—despite
the momentum inherent in every project.
Professional Competence
Professional competence falls under management competence and leadership com-
petence; however, different facets are in the foreground in each case. Professional
competence is the sum of the knowledge and skills needed to complete a project on
time and within budget. Professional competence is also necessary to ensure that the
project’s technical and professional aspects are sufficiently taken into account to
bring about a successful conclusion with the desired results. Technical expertise
includes knowledge of the technology that the project team will encounter and the
tools and methods required to implement it. Also, understanding of
interdependencies between the technologies and their applications and limitations
is necessary.
Finally, you need to know what expertise is required for the introduction and
successful use of the technology, even if you cannot demonstrate this expertise
yourself. As a project manager, you do not have to be the top expert yourself, but you
must have sufficient expertise to bring the necessary experts on board, discuss the
issues with them objectively and lead them. For example, a project leader who has
project management as technical expertise but has little or no understanding of the
system and technology he/she is introducing will find it difficult to discuss problems
and possible solutions with their teams. They run the risk that project stakeholders,
especially their technical team, will call their overall competence into question.
Thus, professional competence is a component of leadership competence.
136 5 The Underestimated Success Factor: People
Note: Pitfall Professional Competence
Many companies inevitably link career development to taking on personnel
management tasks. In these cases, employees are promoted to leadership roles
due to their excellent professional skills—e.g. project management. However,
precisely because they have the best specialist skill, these project managers
often find it difficult to break away from their previous exclusive role as “the
technical expert” and delegate tasks. They jump in uninvited when technical
work is being done, narrow their team’s competencies and lose sight of their
broader function and additional work as a manager and leader. There is a risk
that they will become overworked and demotivate the team due to their lack of
confidence in their team. Furthermore, the project leader’s behaviour usually
causes the project members to take increasingly less responsibility for their
work and the project results.
Operational vs. Strategic Management
There is a basic distinction between operational and strategic management, and this
difference also applies to project management. The operative management is respon-
sible for all questions, problems and tasks in the project. (This is often referred to as
classical or executive project management.) Operative project management asks the
key question: “Are we doing the project right?”
On the other hand, strategic project management addresses the question “Are we
doing the right project?” and clarifies why a project investment is necessary at all.
Figure 5.2 shows the relationship between strategic and operational project
management and the positioning of the project leader.
Strategic project management combines the strategic corporate goals with opera-
tional project management, enabling the leadership to translate the strategic goals
into operational project goals more easily. Through the specifications and defined
goals of a project aligned with the strategic corporate goals, projects can be carried
out more efficiently, bring the company more sustainable advantages and achieve a
better ROI. After all, a successful project that misses the corporate goals or—worse
still—undermines them is a bad investment. In the sense of a successful SAP project,
the project manager is an important interface between operational and strategic
project management.
A good project manager must also demonstrate additional management skills,
including technical and analytical skills. These skills enable them to take responsi-
bility for leadership tasks and further management tasks relating to planning,
organisation, personnel deployment, personnel development and controlling within
the SAP project.
5.2 The Importance of Project Management Leads 137
Fi
g
.5
.2
S
tr
at
eg
ic
an
d
op
er
at
io
na
l
pr
oj
ec
t
m
an
ag
em
en
t
138 5 The Underestimated Success Factor: People
5.3 Qualification, Personal Suitability and Availability
of Project Members
The next important step after a project leader has been selected is planning
capacities, i.e. assigning resources and resource availability planning. In the follow-
ing sections, you will learn how to best proceed with your resource planning.
5.3.1 Skill Requirements in Digital Project Management
Qualified Employees Among the Top 5 Success Factors
The CHAOS Report 2015, published by the Standish Group in October 2015,
examined a total of 50,000 IT projects of various sizes around the world over the
period from 2011 to 2015. From this survey, Standish identified ten criteria crucial
for project success. The factor “qualified employees” is among the top 5.
Table 5.1 illustrates each factor’s importance and the Standish Group’s recommen-
dation on the effort and investment that one should consider for improving a
project’s success.
Qualified employees are people who have the necessary professional and per-
sonal skills to participate effectively and goal-oriented in the project. These people
understand both technology and business. They are competent in carrying out the
project requirements and delivering the project or product. So far, so good!
What skills does increasing digital project managementrequire from employees?
What is certain is that the number of tools and technical resources available to make
projects more effective and efficient will grow, and project staff will need to be
trained in these resources in real time.
The areas that will initially require new digital project management skills include
project organisation, information gathering and analysis and project documentation.
Table 5.1 Success factors 2015, from the CHAOS Report 2015 (# Standish Group)
Success factors Points
Investment
%
Executive sponsorship (advocacy and political backing for a project by
the senior management of the organisation)
15 15
Emotional maturity 15 15
User participation 15 15
Optimisation 15 15
Qualified employees 10 10
Standard architecture 8 8
Agile process 7 7
Moderate design 6 6
Project management expertise 5 5
Clear business objectives 4 4
5.3 Qualification, Personal Suitability and Availability of Project Members 139
The possibility of automating many things, increasingly informal communication
channels and, in some cases, ever shorter timeframes for planning and control in
projects means that new skills will also be required. From today’s perspective, we
are unable to identify these skills with 100% accuracy. In our view, this is okay
because the skills necessary in the future are not in the technical realm.
If you need programmers or database and network administrators, you can find
these workers freely on the market or “borrow” them from temporary employment
agencies. What becomes much more difficult is finding the people you can fully
integrate into the team who meet all the requirements of increasingly agile transfor-
mation projects. They must be technically fit and have the skills to work closely with
others from the business side, listen to them properly and understand their business
processes.
Finding these project staff is a major challenge, which is constantly changing in
step with technology. This challenge is one reason that researchers are publishing
one study after the other. In the following paragraphs, we describe in more detail the
skills that are becoming increasingly important for project management, both now
and in the future.
Customer Focus
The ability to work highly customer-focused is not a requirement that has arisen
from digitalisation. However, it has become more important because of the greater
transparency and customer intelligence (CI) (businesses now know so much about
their customers) made possible by big data. These factors, in turn, drive the expecta-
tion that companies meet customer needs both accurately and immediately.
Change Management
Transformation projects are about nothing more than change. Despite thousands of
years of evolution and the new pressure to become more agile, we humans are still
rarely enthusiastic about massive change. Digitalisation makes it possible to intro-
duce massive change rapidly—and to do so by an entire organisation, even across all
borders. Project staff at all levels must be able to see the impact of these changes.
They must recognise when they need to be more empathic. For example, when
employees are required to work on a transformation project that will ultimately
eliminate their jobs, recognising and dealing with resistance will be crucial to the
project’s progress. Understanding difficult issues or even grief reactions to change
processes in an organisation is neither common nor typical in project management.
However, they may still be decisive for the success or failure of the project.
Dealing with Data Science
The ability to work with and understand large data volumes is what enables a project
leader to make the best decisions. Effective project management requires people
with the ability to analyse data in the project.
Innovation Mindset
Project teams are increasingly encouraged to look at problems and challenges from
new perspectives and find innovative solutions creatively. They need to adapt to new
140 5 The Underestimated Success Factor: People
technologies, acquire new knowledge and skills and discover and take advantage of
the latest opportunities. In this context, it is important to have the ability to distance
oneself somewhat from what was and what is to discover solutions that have never
been there before.
Data Security
Since the DSGVO came into force in Europe in May 2018, data security and data
protection are a very high priority for many project teams. Companies want to
protect both their own data and the data of their respective customers (consumers).
Compliance Knowledge
The project management team should by no means assume the tasks of compliance
experts. The team must nevertheless understand how far compliance issues can
influence the implementation of their projects. Project teams must have knowledge
of legal rules and regulations that affect the implementation and management of a
project. These rules range from labour laws to tax regulations. It is important to have
at least enough knowledge to decide when to call in compliance experts.
Ability to Make Data-Based Decisions
Project managers have always needed the ability to make data-driven decisions.
Now, with digitalisation comes a flood of data that is brought together and
transformed into applicable information. Therefore, the ability to use data as a
basis for decisions that drive the project has gained importance.
Collaborative Leadership Skills
The requirement for collaborative leadership qualities is also not a direct result of
digitalisation because collaboration in cross-function teams has always been impor-
tant for project management. Projects are becoming more complex and hierarchies
flatter, so the ability to influence other people is becoming even more important.
Only those with collaborative leadership skills can bring together teams with
different needs and individual goals to achieve great common goals.
5.3.2 How to Select the Right Employees
Building a Strong Team
In this section, by resource selection, we mean the selection of personnel for the
project team. It is important to find the people who have the necessary skills to plan,
carry out and complete their tasks in the project. It’s all very simple: if you look at
both quality and quantity when selecting personnel, you’ve won—you just need to
know which people with which qualifications you need in the project and how many.
In reality, of course, it’s simple, yet not that easy.
For your project, you are looking for suitable people both professionally and
personally for a large, important, possibly long and often stressful undertaking.
5.3 Qualification, Personal Suitability and Availability of Project Members 141
Your project staff must be able to work independently. For this, they need profes-
sional expertise. To determine what specific expertise your project members need,
get an overview of the project’s different requirements. Then decide what skills you
need onboard. Don’t just look at who is “there and available”.
Role Descriptions
The creation of role descriptions and a catalogue of questions to select resources is a
great help when selecting employees. First, create a role description for the different
positions you want to fill. For each role, develop a list of questions to determine the
criteria for a suitable resource.
The role description documents the role with the associated tasks and processes
that are to be performed by one or more employees. We recommend that you create
role descriptions for roles relating to SAP processes and all other project roles.
Catalogue of Questions
The catalogue of questions includes a collection of questions that will help you
identify the appropriate resources for the project. The following questions belong in
the employee selection process for each SAP project:
• What technical qualifications are required?
• What is the required professional expertise?
• Which soft skills does the employee need (in particular)?
• How often do I need this employee (in terms of weekdays)?
• How importantis project experience for this position?
• Over what timeframe should the employee work on the project?
• In which other project is the employee already involved or planned?
• In which area is the employee already involved in day-to-day business?
• On how many days of the week is the employee working on other projects or with
other tasks?
We deliberately calculated with weekdays instead of percentages in the questions
on the deployment of the employee. This approach allows you to identify potential
conflicts in the later availability of resources more quickly.
Taken from Project Life
Here is an example: if the head of the HR department promises you that
Mr. Schroeder from his department will be allowed to work 40% of his 40-hour week
on a project with you for a month, you will initially be pleased. You can now expect
to integrate Mr. Schroeder into the project for 16 hours a week without any problems
because 40% of 40 hours is 16 hours. However, the calculation does not add up. The
joy will quickly evaporate as soon as you realise that Mr. Schroeder is only
theoretically available because he is completely indispensable to his department
3 days a week. Unfortunately, you need Mr. Schroeder for at least 3 hours on 5 days
of the week for functional tests during the planned hot phase. You only have 2 days
on which Mr. Schroeder is actually available.
142 5 The Underestimated Success Factor: People
If you had planned to have Mr. Schroeder and an SAP expert work in a daily test
and review cycle, you would now have to organise the work packages differently.
This example should clearly illustrate what effects exact availability can have on
work planning. It should also clarify why you should think and communicate both in
terms of the percentage of working time and the weekdays when coordinating the
project staff.
Methods in Personnel Selection
There are different methods to support the selection of personnel for external or not
yet existing project members. Some of the possibilities to provide a basis for
decision making are as follows:
• Review and analysis of the application file
• Interviews
• Technical tests
• Assessment centre
• External personnel agencies (with a focus on IT projects)
We recommend that for each important position or role in the project, the
personnel selection process should include a personal interview and at least one
other selection method. The different selection methods provide additional informa-
tion about a potential employee and look at the person from different perspectives. If,
for example, you are looking for a specialist in the team, it is useful to check the
candidate utilising specialist tests. Specialised testing is particularly important if a
candidate cannot sufficiently prove the desired expertise through documented and
verifiable experience.
The Chemistry Is Right!
However, you should not rely exclusively on quantitative assessment methods, such
as performance tests when selecting personnel. These methods disregard some
important factors, such as personal disposition (including motivation, punctuality
and teamwork) or the proverbial “chemistry”, i.e. interpersonal harmony or possibly
disharmony. Interpersonal harmony is a factor that strongly influences cooperation,
in both a positive and negative sense. Since a large project almost always involves a
high workload under increased time pressure, it is particularly important to rule out
any avoidable disruptive factor from the outset. The latter is another reason why it is
best to establish the personal interview as an integral part of personnel selection for
important positions.
Filling the project team with staff already in the organisation must be carried out
with similar criticality to selecting personnel from candidates via external sources.
Take a close look at the staff for key projects. Make sure that they have the expertise
and experience required for the position or role in question.
5.3 Qualification, Personal Suitability and Availability of Project Members 143
What Doesn’t Fit Is Made to Fit!
When selecting project members from existing staff within an organisation, the
project leader may (have to) follow the motto “if it doesn’t fit, make it fit”. This
saying is not a reference to a special training program or a meaningful qualification
measure for the project staff. Sometimes management expects or even demands the
project leader utilise the available staff and make the best of it. If you find yourself in
this position and the technical expert, who has practically been forced onto your
project, has frightened away everyone with whom he has ever worked, you must be
proactive. The best thing to do is make your teamwork expectations clear early in the
project and facilitate team player skills through targeted coaching. Ideally, the
coaching should happen before the project begins. If the person does not accept
the coaching, or the coaching is not effective, and you cannot replace the individual,
give them a wide berth and minimise their interactions with the team. Do your best to
avoid taking on such team members by stressing the importance of team fit and
culture during the very early project planning phases.
5.3.3 To Ensure the Availability of Resources
In our context, resource availability refers to the actual availability and accessibility
of the resources planned in the project. When it comes to resource availability, your
first priority is to ensure that the people you schedule in the project are actually
available when you plan them. It sounds like a straightforward matter, yet this simple
requirement can often be extremely difficult to implement in reality. Why is that?
This section answers that question. We will look at the aspects of resource security
that require particular attention and the factors that often make it difficult to ensure
the availability of resources.
Ensure Specific Technical Knowledge
The specialist technical knowledge needed in your project depends on several
factors, including the project objective and the industry in which your client
operates.
Taken from Project Life
An SAP project at a large shipping company is an example of a requirement of
special technical knowledge. In this example, the management of incoming goods,
processes, warehouse and operations management and the administration of outgo-
ing goods processes are to be optimised. The project is to optimise by implementing
the SAP Extended Warehouse Management (SAP EWM) solution, which under
SAP S/4HANA is now part of the core and no longer an additional component. In
this example, it is important to have resources (people) with the expertise on this
SAP solution for logistics and order fulfillment in the project team.
144 5 The Underestimated Success Factor: People
Take Important Employees into Account in the Planning
It happens more often than you might think that a project involves employees who
can only work in theory or even exist only in theory.
Identify Knowledge and Trust Carriers
Over the years, we have repeatedly encountered situations similar to the following:
the employee, Ms. Meyer, is most familiar with the finance department’s business
processes. She is also the only colleague who is widely accepted and respected by
everyone in the department. Ms. Meyer is finally able to fulfill her dream of a 6-week
trip to Australia. Unfortunately, her absence is during the process analysis phase of
the project, so the project team conducts an important basis of the project without
participation from the expert and highly trusted person, Ms. Meyer.
The result is that the department and department management colleagues mistrust
and have little confidence in the project from the very beginning. This mistrust
creates a success-critical hurdle for the project.
The example above illustrates that it is extremely important to identify the
required technical and business experts early to secure their participation in critical
project activities.
The same applies to employees who can positively