Management for Professionals

Denise Banks-Grasedyck
Eckhard Lippke · Hans Oelfin
Reinhold Schwaiger · Volker Seemann

Successfully
Managing S/4HANA
Projects
The Definitive Guide to the Next Digital
Transformation
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

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 Eckhard Lippke
Berlin, Germany Leimen, Germany

Hans Oelfin Reinhold Schwaiger

Waldenbuch, Germany 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
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
vi Preface

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
Preface vii

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.
viii Preface

Business
Processes

Business Process Intelligence (cross functional)

Business Networks
Sustainability Intelligent Suite Cross-Industry Experience Mgmt
Applications Industry Cloud
Mgmt (Qualtrics)
S/4HANA SaaS Clouds

Business Technology Platform

Technology
Development Database Artificial
Analytics
Integration Data Management Intelligence

On-premise or SAP Data Hyperscaler

Infrastructure
Partner Data Center Center Azure – AWS – GCP

Fig. 1 Overview of the SAP product strategy

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
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
xii About This Book

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.
About This Book xiii

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
xiv About This Book

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.
About This Book xv

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 for a 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.
xvi About This Book

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
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

xvii
xviii Contents

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 Implementation Methodology 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
Contents xix

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
xx Contents

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.2 Project 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
Contents xxi

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
xxii Contents

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
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.

xxiii
xxiv About the Authors

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 training in 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.
About the Authors xxv

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.
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 batch mode. 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 1

D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_1
2 1 Introduction

Logiscs Financials
SD Sales & Distribuon FI Financials
MM Materials Management CO Controlling
PP Producon Planning TR Treasury
QM Quality Management R/3 Client / Server
PM Planned Maintenance ABAP
Cross-Funconal
PS Project System
Human Resources WF Workflow
HR Human Resources IS Industry Soluons

Fig. 1.1 SAP R/3: Overview of the modules

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
1.1 SAP Solutions: From the Beginning to Today 3

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 source code 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.
4 1 Introduction

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
1.1 SAP Solutions: From the Beginning to Today 5

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:
6 1 Introduction

• 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, more reliable 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.
1.1 SAP Solutions: From the Beginning to Today 7

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?
8 1 Introduction

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.
1.1 SAP Solutions: From the Beginning to Today 9

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 systems reduced 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.
10 1 Introduction

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
1.1 SAP Solutions: From the Beginning to Today 11

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)
12 1 Introduction

• 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 integration of
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
1.2 Current SAP Software Solutions and Outlook 13

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 &
Cloud Platform
Spend Mgmt

People
Engagement
Intelligent
Technologies
Digital Core
Intelligent Digital
Suite AI Platform
Machine Learning
Analytics
IoT
Manufacturing
+ Supply Chain

Customer Data
Experience Management

Fig. 1.2 SAP Vision: Intelligent Enterprise

14 1 Introduction

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:
1.2 Current SAP Software Solutions and Outlook 15

• 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-proof investments.
• 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.
16 1 Introduction

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.
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 17

D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_2
18 2 What Makes an SAP Project So Different?

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. The project 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
2.1 What Distinguishes IT Projects from Business Transformation Projects with SAP 19

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
20 2 What Makes an SAP Project So Different?

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”.
2.2 Not All Projects Are the Same 21

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 have answers 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:
22 2 What Makes an SAP Project So Different?

• 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 Heterogeneous processes and heterogeneous IT system architectures stifle
project 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 • Process template developed and target IT architecture defined: 06/30/2021
milestones • 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 • Harmonisation of process flows
project • Replacing old system infrastructure, increasing productivity through
standardisation
• Higher customer satisfaction, reduction of stock
Project Pure project organisation
organisation
Attachments Statement of work (SOW), rough project plan with milestones
2.2 Not All Projects Are the Same 23

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.
24 2 What Makes an SAP Project So Different?

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.
2.2 Not All Projects Are the Same 25

Pure Project Organisaon

Top Management

Line Organisaon Project

PMO

Finance & Team 1: Team 2: Team 3: Team 4: Team 5:

HR Sales Purchasing Producon
Controlling Finance HR Sales Purchasing Producon

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

Funconal Project Organisaon

Line Organisaon

Project Coordinaon

Finance &
HR Sales Purchasing Producon
Controlling

Coordinator XXX… XXX… XXX… XXX…

XXX… XXX… XXX… XXX… XXX…
XXX… XXX… XXX… XXX… XXX…
XXX… XXX… XXX… XXX… XXX…

Fig. 2.2 Functional project organisation

• 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 the project.
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.
26 2 What Makes an SAP Project So Different?

Matrix Project Organisaon

Line Organisaon

Project Coordinaon Finance &

HR Sales Purchasing Producon
Controlling

Proj. Mgr. Staff 1 Staff 2 Staff 3 Staff 4

XXX… XXX… XXX… XXX… XXX…
XXX… XXX… XXX… XXX… XXX…
XXX… XXX… XXX… XXX… XXX…

Fig. 2.3 Matrix project organisation

• 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)
2.2 Not All Projects Are the Same 27

Staff Project Organisaon

Top Management

Project Manager

Line Organisaon

Finance &
HR Sales Purchasing Producon
Controlling

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

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.
28 2 What Makes an SAP Project So Different?

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”.
2.3 Digitalisation in Project Management 29

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 is supported 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
30 2 What Makes an SAP Project So Different?

The six Acvate Phases

Discover Prepare Explore Realise Deploy Run

1 2 3 4 5 6

High-level project Project iniaon, Map project scope Incrementally build Detailed planning Operate landscape,
scope, soluon form project team, to soluon, perform and test integrated of cutover implement operaons
selecon and finalize plans and fit-gap analysis and system environment. acvies, verify standards to maintain
project approach start the project define gap closure Load and validate system and and improve system
acvies legacy data, build organizaon and operaons
interfaces, plan readiness. Switch quality (connuous
operaons concept, to operaons to improvement)
train users new system (go-
live)

Fig. 2.5 Overview of the SAP Activate project phases

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
2.3 Digitalisation in Project Management 31

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,
32 2 What Makes an SAP Project So Different?

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.
2.3 Digitalisation in Project Management 33

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.
34 2 What Makes an SAP Project So Different?

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:
2.3 Digitalisation in Project Management 35

• 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.
36 2 What Makes an SAP Project So Different?

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.
2.4 Why Software from SAP? 37

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.
38 2 What Makes an SAP Project So Different?

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 supported in 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
2.4 Why Software from SAP? 39

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
40 2 What Makes an SAP Project So Different?

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”).
2.4 Why Software from SAP? 41

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 • Is the user interface user-friendly?
options • 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 How do you prevent unauthorised changes and access to
concept data?
Data migration Are there special tools for migrating legacy data?
Functionality/process • How high is the degree of coverage of the software
harmonisation/standardisation functionality for the company-specific requirements?
(continued)
42 2 What Makes an SAP Project So Different?

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, What functional scope does the software offer in the area
interfaces, conversions, forms 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?

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:
2.4 Why Software from SAP? 43

• 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
44 2 What Makes an SAP Project So Different?

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
2.5 The Road to SAP S/4HANA 45

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
46 2 What Makes an SAP Project So Different?

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.
2.5 The Road to SAP S/4HANA 47

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 difficult for 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 S/4HANA on Premise Bring your own License
Enterprise Cloud) (BYOL)
S/4HANA PCE (Private Subscription
Cloud Edition)
S/4HANA Cloud, extended Subscription
edition
SAP’s SaaS Cloud S/4HANA Cloud Subscription
48 2 What Makes an SAP Project So Different?

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
2.5 The Road to SAP S/4HANA 49

SAP S/4HANA for customers. It emulates an on-premise environment in a cloud

environment. The service is delivered as an SAP Managed 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 Customers use the (usually existing) software licences in the cloud
(BYOL) 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.
50 2 What Makes an SAP Project So Different?

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 other SAP 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.
2.5 The Road to SAP S/4HANA 51

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.
52 2 What Makes an SAP Project So Different?

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,
2.5 The Road to SAP S/4HANA 53

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.
54 2 What Makes an SAP Project So Different?

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 SAP ERP S4 On Premise

SAP PaaS
(Brownfield) System Cloud (HEC)
S/4HANA

New Implementaon SAP ERP or S4 On Premise

SAP PaaS Cloud
3rd party
(Greenfield) (HEC)
System S/4HANA S/4HANA Cloud

SAP ERP
Region A S4 On Premise
Selecve Data Transion SAP ERP SAP PaaS
Region B
(Landscape Transformaon) S/4HANA
Cloud (HEC)
SAP ERP
Region C

Fig. 2.6 The road to SAP S/4HANA

2.5 The Road to SAP S/4HANA 55

• 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
56 2 What Makes an SAP Project So Different?

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 advise against 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
2.5 The Road to SAP S/4HANA 57

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
58 2 What Makes an SAP Project So Different?

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:
2.5 The Road to SAP S/4HANA 59

• 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 up skills, 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
60 2 What Makes an SAP Project So Different?

Prepare Phase Realize Phase

Maintenance Software Update Application-specific

Planner
Pre-Checks Pre-Checks
Manager (SUM) Post Steps

Database Migration

Simplification List Software Update

S/4HANA PCE / On-Premise Edition

Data Conversion

Fig. 2.7 SAP S/4HANA conversion steps

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
2.5 The Road to SAP S/4HANA 61

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.
62 2 What Makes an SAP Project So Different?

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 migration of 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?
2.5 The Road to SAP S/4HANA 63

• 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.
64 2 What Makes an SAP Project So Different?

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.
2.5 The Road to SAP S/4HANA 65

Execuve
Overview LoB-specific recommendaons and results Next Steps
Summary

Accounng Purchasing Sales …

Idencal structure for all LoB’s

Introducon Results Recommendaons

• Overview of idenfied • Overview of business KPI and • SAP Best Pracces, taking the
improvement potenal comparable industry figures current process coverage
• List the respecve S/4HANA into account.
innovaons • Details about each
• Details and explanaons about recommended business
each innovaon scenario, including process
improvements

Fig. 2.8 Structure of the report “SAP Business Scenario Recommendations for SAP S/4HANA”

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 can be 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/).
66 2 What Makes an SAP Project So Different?

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)
2.6 Conclusion 67

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.
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 69

D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_3
70 3 The SAP S/4HANA Project: How It Should Be

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 formal
and 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.
3.1 Project Management Standards, Methodology and Tools: An Overview 71

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
72 3 The SAP S/4HANA Project: How It Should Be

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
3.1 Project Management Standards, Methodology and Tools: An Overview 73

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 Importance of 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.
74 3 The SAP S/4HANA Project: How It Should Be

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.
3.2 The Project Management Basics: PMI Project Management Methodology 75

Table 3.1 PMI process groups

Phase/process group Details
1 Concept and initiation(conception Clarification and definition of the project
and project preparation phase) objectives. Agreement/creation of a common
understanding
2 Definition and planning(definition Planning of project content and scope; development
and planning phase) 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 Reporting and change management
(monitoring and control)
5 Closing(project completion) Order completion and administrative project
completion

Table 3.2 Knowledge areas according to PMI

Knowledge area Details
1 Integration Coordination and exchange of information between the project
management 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 Standardisation of project processes and documentation of results
management
6 Human resource Allocation of project resources to the project tasks according to
management training/qualification
7 Communication Information exchange with all project participants
management
8 Risk management Risk analysis, preventive measures, mitigation and emergency
concepts
9 Procurement Cooperation with partners and suppliers
management
10 Stakeholder Coordination and agreement with project participants inside and
management outside the project

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
76 3 The SAP S/4HANA Project: How It Should Be

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.
Dealing with 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)
3.3 Everything Perfectly Prepared: The Ideal Conditions 77

Project-Sponsors (Execuves)
Responsible Responsible
for Approval of Steering-Commiee for Template
Strategic design Design
Program Manager

Process- Benefits- Change- Integraon- Informaon-

Responsible Executives

Global Process Owners

Global Process Experts

transformaon Realizaon Management Manager technology

Subject Maer Experts

SME SME SME SME
Team 1 (FI) Team 2 (Log) Team 3 (HR) Team … (…)
Development- Soluon- Integraon-
Team Architects Architects

Responsible Business Department Experts Validang Design

for Approval of against Requirements
Detailed Design

Fig. 3.1 Project team with responsibilities and decision-makers

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.
78 3 The SAP S/4HANA Project: How It Should Be

Program
Sponsor

Execuve Steering
Advisory Boards Organizaonal
Commiee
Stakeholders

SAP
Project
Employees
Management representatives

Technology
Project Data protection
Officer
Execuve
Management
Leadership Team Office
Country-specific
Organizations
Regional
Leadership Teams Specialist teams IT Teams Change Mgmt.

Business
Process Owners

Fig. 3.2 PMO as project headquarters

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.
3.4 ASAP: The Mother of All SAP Methods 79

Project- Final Go Live

Blueprint Realisaon
Preparaon Prep Support

• Project structure • Develop process • Build system • Go-Live • Shutdown legacy

• Resource landscape landscape Preparaon systems
planning • Develop • Customizing • Acceptance Test • Producve Data
• Effort esmaon architecture • Programming • Setup a migraon
• Quality • Create • Build integraon producve • Data migraon
assurance documentaon architecture system landscape sign-off
Planning • Prepare training • Develop security • Performance Test • Final test of the
• Establish documents and performance • Security test producve
communicaon • Prepare system concept • End user training system
structure architecture • Tesng • Test data landscape incl.
• Set up project • Develop • Soluon migraon data
controlling Prototype Acceptance • Plan the Go Live • Formal approval
• Assign • Documentaon • User Training • Go Live Plan sign- • Unlock users
responsibilies sign-off Materials off • Communicaon
• Prepare data • Communicate • Start producve
migraon Change system
• Hypercare
Support

Fig. 3.3 SAP’s ASAP roadmap

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 possible was 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.
80 3 The SAP S/4HANA Project: How It Should Be

Process Definion

End–to–end
Processes
End- to -end
Processes
Crical Path
Inial Architecture
Definion
Integraon
Architecture
Define
Scenarios

Set up the inial system

landscape

Implementaon

Test Approval

Fig. 3.4 Critical path in the project

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.
3.4 ASAP: The Mother of All SAP Methods 81

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.
82 3 The SAP S/4HANA Project: How It Should Be

General Process Flow

Event Process step 1 Process step 2 Decision Process step 3 Result

Example: Procurement Process

New Create Sales Check Idenfy Request Select

Order Order Inventory Suppliers Quotes Offer

Delivery
Create Order Confirm Order Received

Fig. 3.5 Example of a business process flow

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
3.4 ASAP: The Mother of All SAP Methods 83

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 blueprint phase, 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
84 3 The SAP S/4HANA Project: How It Should Be

• 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
3.4 ASAP: The Mother of All SAP Methods 85

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.
86 3 The SAP S/4HANA Project: How It Should Be

• 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
3.6 SAP Activate: The Better ASAP 87

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 for
creating 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
88 3 The SAP S/4HANA Project: How It Should Be

Discover Prepare Explore Realize Deploy Run

• Handover • Project Start: • Compare • Set up and • Transfer the • Connuous

sales dept. to Define the business test the configuraon maintenance
implemen- business requirements configuraon to the and update
taon team benefit and and scope (based on producve of the
• Scope the success • Develop requirements environment systems to
definion criteria soluon defined in the • Support aer ensure stable
• Define the scenarios Explore go - live operaons
basic con- phase)
figuraon

Fig. 3.6 The six SAP Activate phases

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,
3.6 SAP Activate: The Better ASAP 89

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.
90 3 The SAP S/4HANA Project: How It Should Be

The 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.
3.6 SAP Activate: The Better ASAP 91

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
92 3 The SAP S/4HANA Project: How It Should Be

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.
3.6 SAP Activate: The Better ASAP 93

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-over plan, 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
94 3 The SAP S/4HANA Project: How It Should Be

Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: Phase 6:

Discover Prepare Explore Realize Deploy Run
Project Set up Project
Select Roadmap Execuon Supervision / Monitoring and Controlling
Management Management,
Onboarding,
Kick Off Baseline plan Coordinate
Finalise Soluon
and Build Sprints
Standards,
Infrastructure

Team Training Train Project

Team
Develop
Training Plan

Technical Trail System Technical Connuous

Demo System System Setup QA and Prod
Infrastructure Deployment Soluon Design Improvement
Dev System Import
Sizing
Setup Configuraon
and Extensions

Applicaon Strategic Business FIT to Standard Develop

Development Planning Process Map Analysis Configuraon
Business Case and Extensions
Select soluon Baseline Build
and Scope

Fig. 3.7 Overview of the SAP Activate phases and activities: 1

Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: Phase 6:

Discover Prepare Explore Realize Deploy Run
Integraon Create Interface Develop / adapt Acvate
Overview Interfaces Interfaces

Test Define Test Test Cases and Run Tests:

Strategy Test Plan Unit-,
Integraon-,
Load-,
Interface-
Acceptance-
Test

Data Define Develop and Load Data to Producve Data

Migraon Test Migraon QAS for Tests Migraon
Migraon
Strategy Tools

Move to Administraon
Hypercare Phase
Producon of Roles and
Authorizaons Connuous
Op. Manual Improvements
Hand-Over Plan

Develop the Select Project Create

Change Management Change Control
Team Roadmap for
Soluon
Organisaonal
Change End User Training
Management

Fig. 3.8 Overview of SAP Activate phases and activities: 2

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
3.7 Support Tools Provided with SAP Activate 95

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
96 3 The SAP S/4HANA Project: How It Should Be

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 right information 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.
3.7 Support Tools Provided with SAP Activate 97

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.
98 3 The SAP S/4HANA Project: How It Should Be

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
3.7 Support Tools Provided with SAP Activate 99

• 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.
100 3 The SAP S/4HANA Project: How It Should Be

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 project manager, 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.
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 Activate method 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 101
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_4
102 4 The SAP S/4HANA Project: How It Is

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.
4.2 Phase 2: Prepare (Project Preparation) 103

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:
104 4 The SAP S/4HANA Project: How It Is

• Stress from within your own camp (internal projects)

The “go” for a new project is often associated with the clear 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.
4.2 Phase 2: Prepare (Project Preparation) 105

• 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
106 4 The SAP S/4HANA Project: How It Is

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 the cooperation
4.2 Phase 2: Prepare (Project Preparation) 107

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
108 4 The SAP S/4HANA Project: How It Is

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.
4.3 Phase 3: Explore (Or Map Business Processes!) 109

• 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.
110 4 The SAP S/4HANA Project: How It Is

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:

• Requirements that 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.
4.3 Phase 3: Explore (Or Map Business Processes!) 111

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, although much 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.
112 4 The SAP S/4HANA Project: How It Is

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
4.4 Phase 4: Realise (Or The Implementation) 113

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 time and 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!
114 4 The SAP S/4HANA Project: How It Is

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.
4.4 Phase 4: Realise (Or The Implementation) 115

• 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
116 4 The SAP S/4HANA Project: How It Is

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:

• Underestimating the 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
4.4 Phase 4: Realise (Or The Implementation) 117

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
118 4 The SAP S/4HANA Project: How It Is

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.
4.5 Phase 5: Deploy (Or Preparation for Going Live) 119

• 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
120 4 The SAP S/4HANA Project: How It Is

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:
4.7 The Top Flops in the SAP S/4HANA Project 121

• 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.
122 4 The SAP S/4HANA Project: How It Is

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.
4.7 The Top Flops in the SAP S/4HANA Project 123

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.
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 125
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_5
126 5 The Underestimated Success Factor: People

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
5.1 Who Belongs to the Project Team? 127

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.
128 5 The Underestimated Success Factor: People

Fig. 5.1 Overview of the extended project team

5.1 Who Belongs to the Project Team? 129

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. Make a 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
130 5 The Underestimated Success Factor: People

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)
5.2 The Importance of Project Management Leads 131

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
132 5 The Underestimated Success Factor: People

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 actions without 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
5.2 The Importance of Project Management Leads 133

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).
134 5 The Underestimated Success Factor: People

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
5.2 The Importance of Project Management Leads 135

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 already mentioned, 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.
136 5 The Underestimated Success Factor: People

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.
5.2 The Importance of Project Management Leads 137

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.
 138

Fig. 5.2 Strategic and operational project management

5 The Underestimated Success Factor: People
5.3 Qualification, Personal Suitability and Availability of Project Members 139

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 management require 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)
Investment
Success factors Points %
Executive sponsorship (advocacy and political backing for a project by 15 15
the senior management of the organisation)
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
140 5 The Underestimated Success Factor: People

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
5.3 Qualification, Personal Suitability and Availability of Project Members 141

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.
142 5 The Underestimated Success Factor: People

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 important is 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.
5.3 Qualification, Personal Suitability and Availability of Project Members 143

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.
144 5 The Underestimated Success Factor: People

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.
5.3 Qualification, Personal Suitability and Availability of Project Members 145

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 influence the project due to
their acceptance within the organisation and their role as a trusted third party. This
inclusion is the best, if not only, way to ensure access to the best possible resources
for your SAP project.

The Project Collides with the Daily Business

Additional work requires additional cooperation.
In large projects, many divisions operate in strong interdependence with each
other. Among them are also divisions that had little contact with each other until the
start of the project. In a project, they suddenly have to work closely together and, if
necessary, share resources that were previously under the responsibility of the
respective divisional management. These divisional managers must continue to
manage the day-to-day business and additionally fully support the large project. It
is not uncommon that the management expects the business teams to handle the
additional project work with the available resources.

In our view, this expectation is often highly unrealistic and is a stumbling block to
the availability of resources. As a project leader, you must encourage and ensure that
management supports the need to deploy additional staff to relieve the business
units’ burden during the project.

Tip: Relieve Daily Business

Look for a reinforcement staff who will temporarily take over tasks from the
departments lending their team members to your project. You can use recruit-
ment agencies, hire temporary staff or request replacements from other, less
busy areas.
146 5 The Underestimated Success Factor: People

Consider Critical Phases

Project leaders must plan the project work so that it does not collide with the critical
work phases for the business unit. You can only achieve this if you contact each head
of the different divisions, learn about and understand their processes and closely
coordinate with them.

The Indispensability of the Best Employees

No struggle for critical personnel resources.
In addition to the resource availability issue, there is often the expectation and the
need for departments to make available those employees whose contributions they
can or least want to forego. These are usually particularly high-performing
employees who have the most experience.

An example of this is a finance department required to provide a staff member for

a project. The requirement is that the employee has comprehensive knowledge of all
department processes and their technical background, including dependencies on
other business processes overlapping the finance department. However, clearly, such
people are also extremely important for their department. Besides this, the external
employees are not available as quickly as they are needed. And so the struggle for the
resources that are urgently required in the project begins.

5.4 Key Factors for Good Teamwork

Which key factors contribute to high performance in the project team? Everyone
who wants to implement and complete a large SAP project successfully must know
the answer to this question.

The A and O of the Team Success

Several studies and practical observations of some well-known organisations have
documented that several factors are crucial for the successful cooperation in high-
performance project teams.

Like the professional aptitude of the employees, the following criteria are also
decisive for the success of a high-performance project team:

• Mutual trust (perhaps the most important factor for a high-performance project
team)
• A common understanding of the mission as a team
• Individual commitment and self-commitment to the team goals
• Clearly defined roles and responsibilities (both in the team and in the overall
project)
• Jointly agreed on rules for working and dealing in a team
• A defined and documented model for decision-making
5.4 Key Factors for Good Teamwork 147

• An effective group process that provides for open communication, mutual

accountability and appropriate self-assessment that supports autonomy in
working

Now you will certainly want to know what effect the criteria have in detail. We
elaborate further on the points we have mentioned in the following sections.

5.4.1 Mutual Trust

Mutual trust is probably the most important factor for a high-performance project
team. In a team in which there is little or no trust, the members feel forced to look
after their personal interests. The common interests, namely, those of the project,
then receive little or no attention.

5.4.2 A Common Understanding of the Mission

The “Sense of Unity” Success Factor

A common understanding of the mission as a team brings a higher level of clarity
and enables a goal-oriented project execution throughout the entire project
organisation. Furthermore, it promotes a sense of unity and strengthens the project
team’s cohesion. This unity is particularly important because projects are often
subject to heavy work pressure and stress.

In large teams with a high degree of diversity, the common mission and sense of
“we” becomes more important. This diversity encompasses teams with many differ-
ent tasks, numerous experts with varying fields of expertise and people from
different cultural backgrounds and corporate cultures. The more diverse the
differences are, the more important it is to bring about a common understanding of
the team’s mission.

In the most successful projects, we all knew exactly where the journey was headed. The
strategy was clear, and everyone knew why they were involved. (Quote from a project
manager)

5.4.3 Individual Engagement and Self-Commitment to the Team

Goals

Everyone Is Part of the Solution

Individual commitment and self-commitment to team goals is an important factor in
high-performance project teams. They cause the individual members to see them-
selves as part of a possible solution, especially in difficult project times, and often
rise above themselves to achieve the team goals.
148 5 The Underestimated Success Factor: People

5.4.4 Clearly Defined Roles and Responsibilities

Clearly defined roles and responsibilities, both in the project and the overall project,
are critical for high-performance teams. They determine how and by whom the
project work is to be done. They ensure that each team member understands how
his/her role relates to the project objectives. Clear roles and responsibilities also
make the expectations clear, both of the individual team members and of the project
team as a whole. They also enable a clear, well-thought-out and goal-oriented
approach to the project, even in the event of changes to the plan and even in a crisis.

Few projects have really failed, but for those (that failed) there was no clear definition of
roles or responsibilities. Communication was also poor. (Quote from a project manager)

5.4.5 Rules for Working in a Team

Jointly agreed on rules for working and interacting within the team support the
project team. Rules relativise performance factors such as individual working styles,
personal values or cultural norms. These rules must not be so narrow or rigid that
they hinder the development of creativity and innovation in the team.

Note: Dosing Rules Correctly

Establish rules sparingly and purposefully, and work more with
recommendations. In this way, you only specify what is necessary and, in
the other cases, show a guideline for the desired behaviour. In this way, you
leave room for individuality and initiative for the employees.

5.4.6 Clear Decision-Making

A defined and documented model for decision-making increases the project team’s
efficiency when decisions have to be made. It also minimises the friction that can
arise—not only when decisions have to be made quickly and under increased
pressure.

5.4.7 Effective Group Processes

An effective group process that provides for open communication and mutual
accountability is essential for high-performance teams. Equally crucial within the
group process is the space for appropriate self-assessment that supports autonomy in
working. A project team that is expected to deliver maximum performance needs
5.4 Key Factors for Good Teamwork 149

both guidelines and leeway and flexibility in setting operational objectives within
the team.
As simple as these factors can be presented and as natural as they sound, it is
precisely these requirements that are often not taken into account in large projects.
As a result, the project team cannot develop its full potential. At best, the
consequences are a project team that is in constant conflict with each other, works
ineffectively and inefficiently and brings the project to an acceptable conclusion with
much hardship, effort and more luck than reason. And in the worst case, disregarding
these factors leads to the entire project failing.

Note: Trust Must Grow

Regulations are quickly established. Trust, a common understanding of the
mission as a team, and a high level of commitment require space and the right
framework to develop.

5.4.8 Guidelines for High-Performance Teams

Start Early
If you want a functioning and effective project team, it makes sense to put the
success factors on the project kick-off agenda.

Clear rules and guidelines for working together support high-performance teams. A
very good description of the rules for a successful team’s cooperation can be found
in the book Pulling Together: 10 Rules for High-Performance Teamwork by
Murphy (2016).
The tips in the following box are based on those rules from John Murphy. Here
you will also find examples for putting these rules into practice. These can give you
ideas for creating your own set of rules for working together in your SAP
project team.

Tip: 9 Rules for Teamwork

1. We put the common project goals before the individual goals.
– Be aware of the scope of your decisions and activities throughout the
project.
– Know your individual goals and their significance in the context of the
entire project.
– Each individual’s contribution to the joint success of the project must be
made measurable using defined criteria.
– Announce your holiday plans as early as possible and coordinate them
with the project management and the team.

(continued)
150 5 The Underestimated Success Factor: People

2. We communicate openly, honestly and respectfully.

– Give your colleagues concrete and honest praise more often.
– Formulate criticism objectively and solution-oriented.
– Always ask yourself what you want to achieve with a conversation to
communicate in a targeted manner.
– We are all part of the solution rather than part of the problem.
– Try to think in a solution-oriented way, and find concrete approaches for
overcoming specific challenges.
– Think about what contribution you specifically can make to solving the
problem.
3. We respect the differences within the team and the overall project
environment.
– Be open to new ideas and learn from the contributions of others.
– Treat colleagues respectfully even in the event of differences of opinion.
– Humour is important but must never be at the expense of others. Do not
make jokes that exclude or attack certain people (circles) (cultures,
sexes, races, religions, sexual orientation, etc.).
4. We ask the right questions and encourage others to do the same.
– When problems arise, ask for solutions: “What haven’t we tried yet?
How can I help? Who else can help?”
– Use solutions to create new standards and look for ways to optimise your
work: “How can we use this further? What would inspire the customer?
Why doesn’t it go faster?”
5. We use comprehensible, quantifiable and qualified methods to solve
problems.
– Use best-practice methods to work in a resource-efficient way.
– For new approaches and methods, you will answer the questions: “How
will we measure success and effectiveness? When will we measure it?
How will we measure it? Who will take care of it?”
6. We deserve and maintain trust through behaviour worthy of trust.
– Act with integrity and set a good example.
7. We are committed to excellence in everything we do.
– Always deliver the best possible results, and use all available resources
to achieve them.
8. We focus on our own area of responsibility and keep in mind the joint
responsibility for each other and the project.
– When problems or errors occur, do not look for culprits but solutions.
– If you notice that someone needs help, you help.
– If you need help, ask the team and the project management for it.
9. The rules apply to all of us on the team. We respect them, act accordingly
and support each other in complying with them.

(continued)
5.5 Humanity, Feasibility and Motivation 151

– If you are part of the team, respect the rules, and act accordingly.
– Within the context of your individual project assessment, we address
your engagement with and adherence to team rules.

5.5 Humanity, Feasibility and Motivation

The Mix Is What Makes the Project a Success

We often see that management and project leaders do not consider humanity,
feasibility and motivation from the beginning of a project because of the desired
increase in efficiency and the hoped-for cost savings. Later, however, in a quality
review, we see that this circumstance has been detrimental to many once-promising
IT projects. In this section, we would like to show you strategies that will help you to
pay the necessary attention to these points.

Superheroes in the Project

There are projects in which the project goals can only be achieved if the staff work
nonstop or each team member can miraculously do the work of at least three other
people. These projects are planned with superhumans who, unlike normal people,
rarely eat or sleep. They hardly ever take a break, which is why no breaks are
scheduled. These superhumans can teleport from one project location to the next, so
no time is allotted for changing locations conventionally. It is also clear that these
superhumans get along wonderfully without a life outside of work, e.g. friends,
family or personal interests. The superhumans, or superheroes, work without signifi-
cant interruption and are always ready to perform at their best. And they do all this
without stress or any health problems!

Even if this is the dream of some project managers, the project reality and working
with real humans is very different. Anyone who builds on the “superhuman” success
machine in a project builds their project on proverbial sand—at the expense of
stressed, demotivated and burnout-prone project members.

Note: Why Motivation Pays Off

Why should you worry about things like overwork, motivation or the health of
your project staff? The answer is simple: it is the compassionate thing to do as
a leader and a caring human. And from a business management perspective,
these factors have a huge impact on the staff’s project performance. Thus they
both, directly and indirectly, influence the project costs and the overall project
success.
152 5 The Underestimated Success Factor: People

5.5.1 Detect Overload and Excessive Stress

This section considers the possible effects of work-overload and excessive stress on
the employees’ motivation and health and thus on project performance. Our practical
approach also includes some suggestions and tips to help you steer the project in a
positive direction before the emergency occurs or when situations arise that could be
threatening for the project and the employees.
We would first like to take a look at the effects that overworking project staff can
have. By overload, we do not mean the situation where a team member or the whole
team “spends a night on the job” during a hot phase of the project. We are addressing
a repeatedly exceeding working hours and normal workload, under increased pres-
sure to perform without sufficient breaks during the working day and real recovery
times between work assignments.

Nothing Works Anymore

Overload can affect project staff in many different ways and have very different
effects. However, most people show typical signs when they are in a phase of
overwork. These include both physical and psychological symptoms such as the
following:

• Tiredness
• Lack of sleep and sleep disorders
• Eating disorders or a major change in eating behaviour (e.g. much more/much
less)
• Headaches, back pain stomach problems
• Lack of concentration
• Forgetfulness
• Increased irritability
• Mood swings
• A negative change in attitude and overall demeanour

This list is by no means exhaustive, but it does include the signs of overload,
which occur particularly often and usually first. Many of these signs concern internal
conditions that are not or only with difficulty recognizable to outsiders. You can,
however, pay attention to the signs and effects of these processes, as they may be
noticeable in everyday working life. Table 5.2 provides you with assistance in this
respect.
Figure 5.3 shows the signs of overload (also in the project) once again in an
overview.
The point at which an employee is overburdened depends not only on the work
assignment but also on their personal resilience. Therefore, it is difficult to know
exactly when it becomes “too much” for an individual. As a project manager, you
protect the project members and yourself and the company if you strictly observe the
working time laws when planning and implementing the project. This is the first step
towards counteracting project overload.
5.5 Humanity, Feasibility and Motivation 153

Table 5.2 Signs of overwork among project staff

Possible signs in everyday work: the
Indications employee...
Tiredness • More and more looks “bleary-eyed” or “done
in”
• Arrives late in the morning more often
• Drinks a greatly increased amount of coffee
or takes other stimulating substances
• Has difficulty staying awake in meetings or
even nods off
• Is increasingly working longer than before
Lack of sleep and sleep disorders • (See fatigue)
(note: cognitive performance can be impaired • Participates less in meetings than before
after just 3 consecutive days of less than • Makes frequent mistakes
6 hours of sleep) • Has extreme difficulties in understanding
complex issues; asks to have things repeated
more often
Eating disorders or a major change in eating • Shows a rapid and/or stark weight change
behaviour (e.g. much more/much less) • Often has no appetite or no longer joins
others for lunch
• Eats an unusual amount of food, or eats very
often, especially fatty and/or sugary snacks
like chocolate or chips
Headaches, back pain, stomach problems • Notes that she/he has such complaints
• Takes painkillers more often
• Works more often standing up
• Must occasionally interrupt or stop work due
to pain
Lack of concentration • Makes frequent mistakes
• Misses deadlines more often
• Provides work of lower quality than before
Forgetfulness • Missed appointments
• Does not deliver work on time
• Makes comments that she/he cannot
remember anything, including personal
anecdotes, e.g. that there was trouble at home
because she/he forgot to pick up the children
Increased irritability • Shows aggressive behaviour
• Is more often mistaken in the tone
• Receives complaints from colleagues due to
improper behaviour
Mood swings (See increased irritability)
• Is moody and shows great mood swings even
within a short period
• Changes abruptly and often between a very
optimistic and a very pessimistic attitude
towards their work and/or the project
Negative change in attitude/demeanour Suddenly express themselves from a
fundamentally negative perspective/attitude
towards their work, environment and/or the
project
154 5 The Underestimated Success Factor: People

Fig. 5.3 Signs of overload (also in the project)

Counteracting Overload
This first step is good and necessary yet rarely sufficient for the successful course
and completion of the project. Strict compliance with the law is not enough to protect
employees* who often work at their limits and under increased stress for many
months or even years. However, as a project manager, you cannot interfere with your
employees’ privacy, nor should you. For example, you cannot ensure that they sleep
at least 6 hours a night, eat a balanced and healthy diet and keep themselves fit for the
increased stress in project work with a short program of sports, relaxation techniques
and concentration and mindfulness exercises. You will best fulfill your
responsibilities if you both design the formal framework of working conditions
according to relevant labour laws and have a keen eye for early signs of overwork
so you can offer targeted support and help.

Aids Against Overloading

You can implement support in the form of discussions, training, coaching and
advice. It can also mean, for example, a change of job within the project. As the
project leader, you cannot be everywhere, so ensure that everyone in the project team
is sufficiently familiar with stress management. Ensure at the start of the project that
they are training in maintaining performance under pressure and strain, e.g. by
5.5 Humanity, Feasibility and Motivation 155

building up their resilience and motivation. Resilience in this context means having
psychological resistance and the ability to deal well with difficult and highly stressful
situations without suffering long-term damage.

5.5.2 Employees Need Motivation

This section looks at motivation and the effects of a lack of motivation in the project.
By motivation, we mean the drive by which goal-oriented action is initiated,
controlled and maintained.

Extrinsic and Intrinsic Motivation

There are two types of motivation, extrinsic and intrinsic motivation. If extrinsic
motivation is the main focus, you do something, e.g. your work in the project, to get
something else, e.g. your salary, a bonus payment, praise or recognition. Intrinsic
motivation, on the other hand, is based on a person’s inner drive. Intrinsic motivation
is basically about doing something because you like doing it. An example of intrinsic
motivation is employees who ask to be involved in a project because they want to use
their knowledge in the field and enjoy their work.

Note: Effects of Lack of Motivation

If motivation is used to initiate, control and maintain goal-oriented action, this
means the reverse:

• A lack of motivation prevents employees from acting in a target-oriented

manner in the project.
• A lack of motivation deprives you, as project manager, of control of the
employees’ goal-oriented actions in the project.

A lack of motivation among team members can and will have a devastating effect
on the entire project if you do not intervene in time.

Advantages of Motivation
The negative effects of lack of motivation are easy to summarise. Recognising the
effective opportunities motivation offers in staff management within a project is
more important but incomparably more difficult than compiling a list. Studies show
that motivated employees are willing and able to work more, harder and longer than
unmotivated counterparts. They embrace the project’s goals and are persistent and
ambitious in their search for solutions in critical situations. This perception reflects
our experience, both from discussions with colleagues in the projects and project
management’s point of view.
156 5 The Underestimated Success Factor: People

And What Drives You?

Even if you would like to, as a project manager, you cannot conjure up motivation or
force it on your employees. Motivation—that which spurs a person on and makes
them do something specific to achieve something else, i.e. to act in a goal-oriented
way—is subjective and personal. That which spurs Ms. Schmidt to top performance
can make Mr. Miller completely apathetic. What is certain, however, is that there is
something that motivates each person.

Often, only the superstars in the project are noticed. It is important to commitment (to the
project) that a project manager rewards even the seemingly small things. Without them (the
small things), there would be no project success. It's enough if the project members can
present their work from time to time. (Original sound of a project manager)

We also know this from our less scientific observations of other people: with long
faces, these people are transported day after day and week after week from the
country’s buses, trains and planes to the most diverse workplaces. We were not able
to interview them all, but we often followed their unguarded conversations. From
these conversations, the people’s motives for repeating an apparently unpalatable
ritual were clear. They wanted to pay their mortgages on time, go on worry-free
holidays, provide for their children and not have to walk around naked. Money as a
motivating factor is an example of so-called extrinsic motivation.

Creating Incentives
In the following, we show incentives that have a motivating effect on the majority of
employees, even in the most diverse companies. Although adequate remuneration is
a basic requirement, it has only a limited motivating impact on the project staff.

Tip: 5 Tips for More Motivation

1. Give feedback.
Many employees find regular, direct and constructive feedback from
managers motivating.
2. Convey praise and recognition.
Comprehensible praise and recognition, aimed at concrete situations, con-
vey to the employee that they are not only noticed but also appreciated.
3. Assign the right tasks.
Activities and roles that enable employees* to show their special abilities
often have a motivating effect.
4. Encourage through challenges and trust.
Challenges that show that the project management places a high degree of
trust in the employee can spur them on. However, you must ensure that
employees have the necessary resources and support to complete the task
successfully. Otherwise, the effect is negative and demotivating.
5. Give rewards.

(continued)
5.5 Humanity, Feasibility and Motivation 157

Reward the whole team. A meal in a good restaurant, or a round of drinks

after work, helps strengthen community and increases motivation. Make
sure to give rewards and show appreciation even when things are going less
well in the project. It’s all about appreciation of the effort and not just the
result.

5.5.3 Help to Avoid Stress

Even if the project’s working conditions are as humane and socially acceptable as
possible, and the staff is highly motivated and willing to perform, rest assured it will
still be stressful. Sometimes it will be too stressful and too much for some staff*; this
is why we want to address burnout.

Sometimes It Becomes Too Stressful and Too Much

According to some statistics, the number of burnout cases has been slowly decreas-
ing after a decade of growth. Unfortunately, most of those statistics were before May
2019, when the World Health Organization recognised burnout as an occupational
health phenomenon. The statistics were also gathered before the 2020 global pan-
demic, which has brought new stress issues to the challenge of managing projects.
Project-related burnout is a topic that should be dealt with the goal of prevention.
Because although the number of people diagnosed with burnout has decreased, the
number of employees diagnosed with a mental or psychological illness has increased
simultaneously. Whether there is a connection between the two trends is currently as
unclear as the definition of burnout itself.

We are not trying to do what doctors and psychologists have been trying to do for
years: to establish a universally accepted definition of the phenomenon of burnout.
Instead, we want to help you to avoid problems that could disrupt or torpedo your
SAP project in the first place.

Note: Definition of Burnout

We remain practical and use a definition of the Federal Institute for Occupa-
tional Safety and Health, which states that burnout is a syndrome of physical,
mental and emotional exhaustion, depersonalisation and reduced performance.
And we supplement this definition with a statement from the German Society
for Psychiatry, Psychology and Nervous System Medicine (DGPPN); it reads:
Burnout is not an illness in itself, but a state of risk for mental and physical
health and must therefore be taken very seriously.
158 5 The Underestimated Success Factor: People

We also believe that we must take seriously anything that endangers the impor-
tant resource of human health. This attitude is foremost humane and ethical, and it is
also practical from a business point of view.
Even if we do not define burnout as an illness, affected employees* experience a
state of exhaustion that impairs their work and life, and the risk of actually becoming
ill increases. The most common afflictions caused by burnout include depression,
anxiety and addiction disorders, tinnitus or high blood pressure. These illnesses
often have further impairments and disadvantages, both for the working life and the
private life of an affected person.

It depends on the person, but there are three things that put a very high strain on many
colleagues in a project: the projects running in parallel, the often very long daily working
hours over months and if there is such a thing, bullying or psychological strain. (Quote from
a project manager)

Factors that Favour Burnout

The relevance of burnout concerning large, extended-duration projects becomes
apparent when you look at the main factors favouring burnout. These are as follows:

• Overload due to parallel running projects

• Overload due to excessive working hours
• Too many complex and/or extremely detail-oriented tasks
• Too little real recovery time
• Persistent or extreme psychological stress, including bullying,
fear for the job, etc.
• Lack of education and knowledge about stress management practices
• Above all, about building resilience

Risk Factor “Multitasking”

Of course, each management would like to staff its projects with the best possible
team, but please do not schedule the same expert for three projects in the same
timeframe and with 33.33% workload each! Many studies show that the ubiquitous
multitasking in various situations always leads to reduced performance in the
individual tasks. Participation of team members in multiple simultaneously running
projects is multitasking at a high level and increases the risk of overworking the
project staff.

Even if it is often difficult to manage in practice when planning resources, you

should ensure that no staff member, except highly specialised people, is involved in
more than two large projects running simultaneously. In the case of particularly
complex or high-priority projects, employees* who are involved at several points in
the main project should work exclusively on one project.
Even if you manage to plan the assignment as compatible as possible for the
employees, large and highly complex projects with all their facets often remain
5.5 Humanity, Feasibility and Motivation 159

strenuous and sometimes very stressful. In addition to the projects and the work, the
employees’ private life* continues to run parallel to the projects. Organising this life,
especially in hot project phases, is often a great personal challenge. Every challenge
and every other task that has to be mastered by project staff demands strength from
them. This strength is no longer available to the person and therefore not to the
project. The project staff’s overall well-being is also a matter of efficiency and
success-oriented project management.

Note: Keep an Eye on Work-Life Balance

The project leader is requested to keep an eye on his team members’ work-life
balance within reasonable limits while guaranteeing their privacy and
addressing the situation in case of imbalance if necessary. This approach is
important for the care of the staff and for strategic and pragmatic reasons to
ensure or not endanger the project’s success.

Schedule Buffer
The recurring and yet so often overlooked bottleneck periods, such as Christmas and
the summer holidays, should be considered. Also to be taken into account are
workload buffers of about 10% of the available working time per project member
and project for unexpected absences in the project team. If these buffers are not
needed, everyone will be all the happier in the end.

These factors are another reason why it is advisable to offer project staff a project
environment where they can find support and assistance on the broadest possible
basis in the event of difficulties, both professional and nonprofessional.

With the large and especially with the global projects, personal situations often come off
badly. People are simply more distant and anonymous. If you can get to know the people
better, it's better for the whole project. (Quote from a project manager)

Note: Opportunities and Risks of International Project Teams

In complex, large projects, international project teams are used almost exclu-
sively. This diversity has many positive effects, e.g. that the different
nationalities bring in various approaches and that national differences are
taken into account very early on in global rollouts. However, if the team
members are insufficiently prepared, this can be a source of additional stress.
The deployment of international teams entails other risks, including commu-
nication in a foreign language, different ways of thinking and culturally
influenced behaviour, which we look at in more detail in Sect. 5.7, “Interna-
tional Project Staffing: A Special Challenge”, and in Sect. 8.7, “Projects with
Offshore or Nearshore Teams”.
160 5 The Underestimated Success Factor: People

Coaching of the Employees

We recommend that all project staff learn practical strategies for stress management
and building their resilience. This is in addition to learning to communicate and
cooperate in an intercultural context. This learning can be achieved in many different
ways through external and internal training, coaching and reading appropriate books.

The specialist (technical and methodology) training courses are offered, but I would like to
see more soft skills training and qualified coaching not only for project managers but also for
normal project staff. Stress management and intercultural training are two important topics.
(Quote from a project manager)

Stress Management in the Office

We want to give you a few simple tips here, which have proven to be particularly
effective in our project work and in advising employees, even at low cost, and being
valuable in stress management and strengthening your resilience. All employees
must have at least one or two techniques or strategies in their repertoire that help
them and protect them from stress-related overload.

• Meditation and attention exercises

Simple meditation and attention exercises are well suited for dealing with stress in
the office and reducing it. Even a 5- to 7-minute meditation with breathing
exercises every day before starting work can work wonders. This practice is
effective if you follow it regularly and preferably daily.
• Taking a lunch break
A frequently neglected practice to reduce both physical and psychological stress
is taking a lunch break. A light meal followed by a walk at a slightly increased
pace prevents a physical and mental decline due to low blood sugar levels.
Exercise improves the blood circulation and oxygen supply to the brain so that
you can think clearly again.
• Healthy nutrition
Anyone who has ever worked on a large project knows the following situation. It
is half-past three in the office; colleagues are groaning and sighing loudly under
pressure and stress. In between, the voice of colleague Bill Bearbelly is humming:
“I need some brain food”, and he is already on his way to the canteen’s candy
machine.
Certain foods are indeed helpful in stress, but these foods are rarely found in
candy machines. The chocolate you can buy there usually has too little cocoa.
(Cocoa contains a variety of different ingredients that help to reduce stress and
produce happiness hormones.) So it is better to fall back on “real” food that
nourishes your brain, such as a small amount of dark chocolate or pistachios,
walnuts, almonds and yogurt.
5.6 Communication as a Success Factor 161

Tip: Healthy Nerve Food

The project manager, who provides a small supply of “brain food” for the
project team, can use this gesture to create a better working atmosphere and
contribute to the well-being and health of the team.

• Proactive employee management

In addition to individual employees’ measures, project managers can take a
proactive approach through good leadership to prevent negative stress. For
example, they can minimise the ambiguity and uncertainty that are often huge
stress factors in project work. In a very short team meeting, a so-called team
huddle that lasts less than 10 minutes, the day’s top priorities are clearly
formulated and succinctly communicated. The team members leave the huddle
knowing which tasks and topics they must handle throughout the day and which
problems they must report. This clarity creates more freedom in the heads of the
employees* so that they can focus on the essentials.
• Building and strengthening resilience
Resilience refers to psychological strength and the ability to deal well with
difficult situations without suffering long-term damage. There is certainly an
interaction between mental and physical resistance.

Being Crisis-Proof
From our own, sometimes painful experience, we consider resilience a key skill in
complex projects. As technical and personnel managers in global SAP projects
lasting several years, we have contributed to the success of projects under frequently
changing conditions. Changing conditions included the following:

• Multiple planning and reprioritisation rounds

• Changing project managers and project sponsors
• Changing methods and tools
• Changing consulting companies
• Different cultures and mentalities

In these situations, the ability to adapt flexibly to changing circumstances has

always been of particular importance.

5.6 Communication as a Success Factor

Communication is not everything, yet everything that people do is communication.

Whether said or kept silent, whether verbally, in writing or even through our body
language, we communicate constantly, and this long before any digitalisation.
However, digitalisation has given us even more opportunities to share much faster
162 5 The Underestimated Success Factor: People

and with a greater reach. Those who are smart will use this fact to the advantage of
the transformation project.

Communication is not everything, yet everything is communication!

This capital is about people as a success factor in the project. Therefore, it will
probably not surprise you to learn that communication is a critical success factor in
the project. This assertion is supported by our experience and the statements from
our interviews and by numerous studies and surveys, including a study by the global
consulting firm McKinsey & Company entitled “How to beat the transformation
odds” from April 1, 2015 (see https://www.mckinsey.com/business-functions/
organisation/our-insights/how-to-beat-the-transformation-odds).
In the survey, managers who had implemented a transformation project were
asked about 24 practical actions that support the successful implementation of a
transformation in McKinsey’s experience. The result was a clear correlation between
the implementation of these specific actions and the transformation’s success. When
this action-based approach was consistently implemented, the success rate of trans-
formation projects increased to 58%, twice the average success rate. The most
successful projects were those in which all or a high number of the 24 actions
queried were carried out. However, it also became clear that even more important
than the mere number of actions was which of the activities were implemented.
We have provided the list of 24 actions below (translated). The actions are listed
to impact the probability of success of a transformation (from the greatest to the least
effect). In all 24 transformation actions, communication—especially about prog-
ress—is most closely related to success. We have marked actions that represent
direct communication with an asterisk (*).

Tip: The 24 Actions of Transformation

1. Managers throughout the company communicate openly about the prog-
ress and success of the transformation.*
2. Everyone can see how their respective work affects the vision of the
organisation.*
3. Managers exemplify the behavioural changes which they ask their
employees to make (managers as role models).*
4. All employees adjust their daily capacity to changes in customer demand.
5. Managers throughout the organisation communicate openly about the
impact of the transformation on the daily work of the individual(s).*
6. All are actively engaged in identifying errors before these errors reach the
customers.
7. Best practices are systematically identified, exchanged and improved.*
8. The organisation develops its employees in such a way that they can
exceed performance expectations.
9. Managers know that their main task is to lead and develop their teams.

(continued)
5.6 Communication as a Success Factor 163

10. Performance evaluations hold the leaders of the initiative responsible for
their contributions to transformation.
11. Leaders use a consistent change story to align the organisation with the
objectives of the transformation.*
12. Roles and responsibilities in the transformation are clearly defined. *
13. All employees are fully committed to achieving their individual goals.
14. Sufficient staff will be made available to support the implementation of
the initiative.
15. Expectations of new behaviour are directly incorporated into the annual
performance evaluations.
16. At all levels of the organisation, employees who actively support the
transformation also play key roles in the transformation.
17. The transformation goals are adapted for relevant employees at all levels
of the organisation.
18. Initiatives are led by superiors in the context of their daily tasks.
19. The organisation assigns people with great potential to lead the transfor-
mation (e.g. by giving them direct responsibility for initiatives).
20. A capacity-building program has been developed to enable employees to
achieve the transformation goals.
21. The teams start each day with a formal discussion on the results of the
previous day and the work of the current day.*
22. A diagnostic tool helps quantify goals (for new ways of thinking and
behaviour, cultural change, organisational agility) for the long-term
sustainability of the transformation.
23. Leaders of initiatives receive training on change leadership during the
transformation.
24. A special organisational team (a project management or transformation
office) coordinates the transformation centrally.

One-third of the actions consist of actions that constitute direct communication.

The communication types range from spoken and written communication to drawn
communication and lived communication through the role model function.
Perhaps it surprised you when you read the table of the important role and great
impact communication has on a transformation project. We are not surprised because
we experience time and again that the course for a project’s success is set by good,
generous stakeholder-oriented communication and by promoting a supportive com-
munication culture.

5.6.1 Communication Culture

Contrary to the opinion of too many managers, you can neither create nor command
a communication culture. A culture needs time and a framework to develop.
164 5 The Underestimated Success Factor: People

Nevertheless, there are some things you can do as a project manager to promote a
good communication culture in the transformation project.
At this point, we do not want to present an explanation of the ever-increasing
number of technical possibilities to get in contact and exchange information. More-
over, you probably know them better than we do. Therefore, we want to talk about
the framework mentioned above, which you can offer without technical aids. This
framework, which consists of four simple principles, can be a wonderful basis for a
strong and sustainable communication culture, strengthening the people in the
project.

Principles of a Sustainable Communication Culture

We call them systemic principles of communication. Systemic principles are
conditions that endure even under changing circumstances. They are like laws of
nature, in this case concerning good and effective communication. If you take them
to heart, they not only help you to master difficult conversations but often prevent
conversations from becoming difficult in the first place.

As mentioned above, it is about simple solutions to complex challenges. These

four principles are also a kind of harmony theory because, without them, all the
techniques and communication methods can only work superficially. The techniques
and structures can help to conduct effective conversations and navigate difficult
discussions, but they cannot completely transform people, relationships and
organisations. For this, you need a deeper basis, something that can fundamentally
change the way people think, feel and act.
The four principles in question are as effective as they are simple.
They are as follows:

• Communicate with honesty and openness.

• Communicate with intention.
• Communicate with integrity.
• Communicate with empathy.

Nice of You to Ask!

To communicate with honesty and openness means to be open to a new view of
things. This type of communication is the epitome of “being agile”. It is important to
question reality constantly because things can be true from several perspectives.

Anyone who has ever had the experience of witnessing a car accident knows that
just because it is true does not mean it reflects the whole truth! Yes, Mrs. Miller
arrives an hour later than everyone else every day, but is she lazy or disinterested in
the project because of this? Maybe she has a temporary arrangement on working
hours because her husband had an accident. Or perhaps she has already worked
2 hours from home. If there is a real need to know about something, ask rather than
assume you know.
5.6 Communication as a Success Factor 165

Speaking honestly and openly also means listening actively, not conveying any
hidden messages or agendas, and not speaking in a roundabout way. One should try
to act with goodwill and, for example, express anger, hurt or disappointment rather
than secretly trying to “get the better of” someone. It means to live out a win-win
mentality and not the I-win-and-you-lose ideology.
To communicate with intention means making yourself aware of why you have a
particular conversation, how it should occur and what it should achieve. This
principle can work wonders when, as is sometimes the case, strong personalities
meet and sometimes collide with each other.

Taken from Project Life

This type of clash was the case in our following example from project life. Ms. High
was appointed project manager. Mr. Low, a manager in the project, was unhappy
about the nomination from the beginning for personal reasons, and now they were to
work together daily. Mr. Low behaved increasingly unfriendly and disrespectful
towards Ms. High. And although Ms. High had spoken to him about it several times,
the behaviour continued.

As the project manager, it was important for Ms. High to handle the matter herself
if possible. Nevertheless, she sought advice after one last incident. How could she
get the situation under control without involving Mr. Low’s superior? The recom-
mendation to Ms. High was to communicate with intent. She should be clear about
why she wants to have the conversation, how it should be arranged and carried out
and what the conversation should achieve.
The next incident with Mr. Low was not long in coming. Ms. High initially
retreated to her workplace. She thought for a moment and then wrote the questions
about the desired conversation, found below, and her answers on a piece of paper:

• What are the reasons that I want to have a conversation with Mr. Low?
– I deserve to be treated with respect.
– I would like to create a basis for a respectful attitude and a professional
approach to each other.
– This is important because, otherwise, we cannot work well. It puts a strain on
the team atmosphere, and it jeopardises the project for both of us.
• How should the interview take place, and what should it achieve?
– I will ask Mr. Low if he realises that I find his behaviour disrespectful and
hostile to clarify his intention.
– I will give him two examples of such behaviour and request him to refrain
from such actions from this point forward.
– I will inform him that I will not repeat this conversation and will ask for a
meeting with him and his supervisor or manager in the event of another
incident.
– I will ask whether he has questions before I end the conversation.
– In conclusion, I will point out that we do not have to like each other, but we
should still treat each other professionally and with respect.
166 5 The Underestimated Success Factor: People

So Ms. High went to Mr. Low’s office and spoke to him as she had prepared.
After 10 minutes, the conversation was over, and the very next day, Mr. Low’s
interaction was quite different—professional and respectful.

Taking Responsibility for What Is Said

To communicate with integrity, you must be aware of your values. This requires
your willingness to take responsibility for what you say, how you say it and the
consequences. Ask yourself whether the way you are behaving and communicating
aligns with your self-image and how you want to be perceived.

Acting Compassionately
To communicate with empathy means to put oneself in the position of the other
person. You have to understand that everything that someone experiences could
happen to you. It requires you to know that each of us, including those involved in
the project, from their perspective, do the best we can in every situation. When we
know better, we do better. Here, even more than usual, the focus is on relationships
and people.

If you act according to these principles, you will be a communication role model,
a better project manager and a better leader. In theory, these principles are quite
simple, but their consistent implementation is not because how else do you explain
that projects so often fail precisely because of communication.

5.6.2 Communication Structure and Corporate Culture

A communication structure is a formalised representation of the information flow in

a group. In this context, a group is understood to be both the project team and the
entire organisation. Communication structures are existentially important for the
success of your project.
A lack of communication structures puts unnecessary pressure on the project and
the employees. Careful, realistic and detailed planning of application development
capacities, available end users (testers) in the specialist departments, budget
specifications and other relevant internal and external dependencies is a key success
factor for the project. The detailed plans enable the project management to either
confirm the original project assumptions and key data for the project or proactively
communicate changes like revised deadlines to the steering committee and the
sponsors. It is simply impossible to carry out this comprehensive, detail-oriented,
and cross-departmental planning without well-thought-out communication
structures.

Enable Course Corrections

We often observe in practice that the opportunity for project course correction is
forfeited due to missing or insufficient communication structures. A course
5.6 Communication as a Success Factor 167

Fig. 5.4 Less project

pressure through effective
communication

correction can mean, for example, that a critical project phase is postponed early in
the planning process to avoid a resource bottleneck in a crucial business phase.
Without a communication structure in which the relevant stakeholders are addressed
early, this situation may only become apparent shortly before the bottleneck occurs
and lead to costly delays and unnecessary stress.

The bigger and more important the project, the better it runs with strong communication,
directly from above (management) to the entire project team and all those involved. This
type of communication signals how important the project is and makes it easier to gain
support. (Quote from a project manager)

Figure 5.4 shows that effective communication generates less project pressure.

Centralised Versus Decentralised Communication Structure

A large and complex project is always a challenge, especially in terms of communi-
cation. The nature of the requirements is decisive for your choice of communication
structures in the project—and because the requirements in large projects are complex
and entail a high need for communication, a decentralised communication structure
(see Fig. 1.6) is preferable to a centralised communication structure.

Figure 5.5 shows an example of a central communication structure that, as we

have mentioned, is less suitable for a large project.
You need communication structures that enable all those involved—from indi-
vidual team members entering data, sub-project teams and employees* in the
specialist departments and extended project teams to all committees at the manage-
ment level—to receive the necessary information on time. This ensures that your
team also receives information from these circles. In practice, it makes sense to
integrate a centralised and decentralised communication structure (Fig. 5.6) in a
model that fulfills your project’s complex requirements.
168 5 The Underestimated Success Factor: People

Fig. 5.5 Central

communication structure

Fig. 5.6 Decentralised communication structure

5.7 International Project Staffing: A Special Challenge 169

An Open Solution-Oriented Corporate Culture Helps

The lack of communication structures is often compounded by a corporate culture of
fear that prevents open and timely communication. In a corporate culture of fear,
mistakes and misjudgements in project planning are punished with negative
consequences. This reprisal approach generally extends to all areas of the
organisation’s approach to addressing and handling things.

In my most successful projects, there was open, constructive criticism in the team and
regular feedback from the project management about the project and in other respects as
well. (Quote from a project manager)

Suppose employees expect they may be exposed at the next project meeting,
excluded from the project or even have to fear for their jobs. In that case, they will
shy away from active communication, e.g. even if they recognise possible dangers
within the project. Furthermore, in such situations, people will actively conceal
mistakes that may endanger the project.

Abolish a Culture of Fear

A culture of fear leads, for example, to critical situations which, despite being
recognised early, are communicated so late that they cause even greater problems.
Early communication enables more efficient problem management! An important
part of any project’s communication strategy is a rule that says that people should
always seek solutions when problems and concerns arise, rather than who is to
blame.

5.7 International Project Staffing: A Special Challenge

International projects are always a special challenge, not only concerning the
employees and how they are to be treated. However, if they are well planned and
managed, they also offer many opportunities. Firstly, it is important to distinguish
between the countries in which internationally staffed projects are being carried out.
If, for example, a project is carried out in one’s own country with a team coming
from the implementing country and supplemented by a few international project
members, problems are often easier to solve.
As with other projects, in the case of projects with international participants, the
project staff’s availability must be considered. The possibilities of virtual collabora-
tion mean that some colleagues will never actually meet “in the flesh”. Nevertheless,
there are many situations in which it is important to have a project worker on-site,
either initially or in critical phases. Suppose it is necessary to involve project staff
from abroad. In these cases, project managers must remember that possible obstacles
are greater in number and have more variables, so arriving at solutions often takes
more time, patience and flexibility.
170 5 The Underestimated Success Factor: People

Taken from Project Life

We would like to illustrate the above statement with an example: in a complex
project to harmonise company-wide business processes after acquiring a company
and restructuring, a particular expert from abroad is necessary. Ms. Lee is already
scheduled to start on day X. However, the planning was done without the foreign
authorities. In this case, a simple oversight is a trigger for a nerve-racking delay in
the project. Presumably, because Ms. Lee has already worked on other projects
without any problems, the project manager did not consider important details this
time. With an expired work permit and a passport that would expire during the
planned stay, the employee is initially not allowed to begin the position. Despite the
active support of the human resources department in communicating with the foreign
authorities, it takes 6 very long weeks until all the necessary documents, including
the proof of health insurance, the new passport and the entry visa, have been
collected. During this time, the coveted expert stays exactly where she is—and
that is unfortunately far away from the project.

5.7.1 Good Advice Is Half the Battle

Help with Advice and Action: PMO & Co.

For the special challenges around personnel deployment in international projects, the
project management team should ensure they work with expert staff in the personnel
department or PMO. The requirements and regulations are very different for differ-
ent countries. We recommend obtaining further information and advice in the early
planning phase.

Advice and Assistance on the Deployment of Foreign Employees

Project managers can usually obtain information and advice on foreign employees’
deployment, beyond the scope of the residence issues and work visas, from local and
national government employment offices and associations that promote interna-
tional economic exchanges. In Germany, where this book originated, organisations
such as the Federation of Foreign Workers (Bund der Auslands-Erwerbstätigen e.V.,
BDAE) (https://www.bdae-ev.de/) and the Info Centre of the Central Placement
Office for Foreign Nationals and Professionals (ZAV) of the Federal Employment
Agency ((http://bit.ly/ZAFGermany) can provide support. Further help is also avail-
able on the European Employment Services Portal (EURES) at the URL http://ec.
europa.eu/eures. The Citizens’ Service of the Federal Foreign Office (http://bit.ly/
EnterGermany) also offers advice and further information on this topic.

5.7.2 The Journey Has Just Begun: After Arrival

Once you have overcome the first hurdles to find and hire the right foreign
employees for your SAP project, do not believe you are in the clear and can go
right to “business as usual”. In Sect. 7.7, “Projects with Offshore or Nearshore
5.7 International Project Staffing: A Special Challenge 171

Teams”, we list more challenges associated with the deployment of foreign

employees in SAP projects.

Intercultural Communication
At this point, we would like to prepare you for the challenges of different languages,
cultures and working cultures and help you turn them into advantages. Despite all the
differences found in international and multicultural teams, it is important to remem-
ber that the criteria for high-performance teams already mentioned in Sect. 5.4, “Key
Factors for Good Teamwork”, also apply here. They only require a new interpreta-
tion to be implemented.

Tip: 10 Success Factors for International Teams

The following success criteria in connection with international teams take into
account the cultural differences of language, social culture and work culture:

1. Developing intercultural understanding

Mutual trust is built up through openness and strengthened through
appreciation of the other person. Intercultural training, both formal and
informal, can be very helpful here.
2. Overcoming language barriers
If there are linguistic difficulties, important communications should be
made both in writing in the common working language and orally. If you
find that the difference in language levels impedes reliable communication
in daily work, it may be necessary and useful to translate important
communications.
3. Bypassing spatial separation
Different time zones often aggravate the spatial separation of project staff
over long distances. Communication with team members is often via
delayed e-mails and tickets stored in the SAP system. In such cases and
especially in large and long-lasting projects, it is important and worth
every effort to have a very good sub-project manager or an excellent
project coordinator on-site with whom you are in regular contact
(at least once a week). Besides this, you should hold at least one telephone
conference every fortnight in a question-and-answer style to which all
project staff, including virtual colleagues whom you rarely or never see,
are invited.
4. Acknowledge engagement and effort
Even in mono-cultural and homogeneous teams, individual commitment
and self-commitment to team goals are not easy to conjure up. In interna-
tional teams, the challenge often resembles an Olympic discipline. Never-
theless, it is possible. Here, too, you must pick up the individual
employees where they stand and show them how they and their roles

(continued)
172 5 The Underestimated Success Factor: People

contribute to success. In some cultures, the focus is on success in the

community, i.e. in the team. In other cultural circles, the individual comes
first. To define the best strategy, you must know with whom you are
dealing.
5. Ways to finding a decision
A defined and documented decision-making model also has a similar,
difference-bridging effect as the operating rules just mentioned.
6. Promote working independently
Identifying and executing an effective group process that provides open
communication, mutual responsibility and self-assessment supporting
autonomy in working is a particular challenge for international teams.
Cultural and corporate culture influence these issues most strongly.
7. Obtain feedback: does “yes” actually mean “yes”?
Consider, for example, that a clear “yes” from a local employee may
actually mean “I am not sure, but asking is not allowed” if this is a cultural
norm for the foreign employee. In international projects, you must ensure
that all team members are involved in the process and that reporting works
well so that you can intervene in good time if necessary.
8. Clearly define and document roles
Clearly defined roles and responsibilities in the team and in the overall
project take on even greater significance in internationally staffed teams.
Because different languages and culturally determined interpretations can
often complicate even simple topics, it is important to document the
defined roles and responsibilities and make them available to all project
members, e.g. via company intranet platforms.
9. Fill in roles and responsibilities
It is not enough to simply define and document roles and responsibilities.
They must be lived out. You have to question whether the roles and
responsibilities are really clear. Dealing with hierarchies, authority and
adherence to time and deadlines can lead to discrepancies, even work
conflicts and project disruptions if you are not aware of or do not consider
the cultural and corporate culture-related differences.
10. Establish binding rules
Jointly agreed on rules for working and interacting in a team help to
relativise or bridge differences caused by different cultural backgrounds
and different corporate cultures.
5.8 Impact of Digitalisation on Project Management 173

5.8 Impact of Digitalisation on Project Management

For many, digitalisation means that everything runs via IT—that’s it. However, this
consideration is not broad enough. Even if the simplest definition of digitalisation
describes the conversion of analogue content and processes into a digital form or
procedure, it is not that simple. For the people involved in the project, this transfor-
mation means that they have to get involved in profound changes at a fast pace and,
at the same time, successfully complete a transformation project.

5.8.1 What Is Important

Businesses across the economy are using digital technologies and advanced analyti-
cal techniques to discover new sources of economic value. They want to tap into
these sources to increase productivity, flexibility and speed, including labour and
innovation. To reap the benefits of digitalisation fully, they must take on many new
challenges. In this chapter, we deal with the topic of “people in the project”
intensively and address the effects of digitalisation on project management primarily
from this perspective.

Pillars of Digitalisation
According to several studies, there are (at least) four areas of digital transformation
in which companies must demonstrate a high degree of adaptability because these
areas are crucial to the success of the transformation. These areas are referred to as
the four pillars of digital transformation as follows:

• Digitalisation of customer relations

• Development of digital talents and organisation
• Use of data and advanced technology
• Digitalisation of operations and automation of processes

Based on these four pillars, we will address the most significant digitalisation
effects on project management in the following.

5.8.2 Digitalisation of Customer Relations

Relational Model
Customer relations’ digitalisation means that suppliers and customers move further
and further away from a product-oriented transaction model to a relational model in
their interactions. In this relational model, suppliers and customers work closely
together to achieve business objectives and greater operational efficiency. The
vendor is no longer just the expert who delivers a good solution but is increasingly
becoming a “sparring partner” for the customer. With agile thinking and working,
the question is shifting from “can this work?” to “how can this work?”
174 5 The Underestimated Success Factor: People

A stronger focus on finding a way to make things work, coupled with the drive for
greater agility, hugely impacts project management. It means that in addition to
understanding customer requirements, the customer’s priorities must be clearly
understood, both within the project team and by all stakeholders. Even if “how”
and “by when” are still open, it is necessary to examine critically, clarify and
understand what the project should and can achieve in the light of the objective.
Regardless of how it is implemented—whether with a dynamic requirements speci-
fication or with a product backlog including customer stories—agile requirements
management is becoming increasingly important for project management. Conse-
quently, critical thinking and active listening are also becoming more important as
crucial skills in project management and should be widely spread throughout
the team.

5.8.3 Building Digital Talent

We remember companies that once seemed to have always existed, and we thought
they would be around forever, for example, the former largest mail-order company in
Europe, Quelle, or the ancient rock of the camera world, Kodak, or even the
company Nokia, which was still the ruler of mobile telephony in 2006 with an
incredible market share of about 50%. Within 6 years, that same company had a
market share of less than 4% and was on the verge of going out of business. These
are examples of large companies that went under, largely because they resisted
digitalisation and the market’s customer-centred developments for too long. We
can assume that the companies that will be successful in the future will be those that
have achieved a high degree of digitalisation. At this point, we have a question for
you:
Let us assume that a company succeeds in successfully opening itself to the
inevitable digitalisation. Which will be the most crucial contributing factor to that
successful digital transformation?
If you answered with “the talent in the company”, you are right. And you are just
as smart as we thought; after all, you bought this book.

Employees with Digital Skills

A company that wants to use digitalisation to its advantage needs talented employees
who use the existing digital technologies, acquire dynamically developing methods
and new approaches and continuously develop themselves further. It needs people
with technical skills, people with a sound knowledge of human-centred design,
people with a deep knowledge of data analysis, etc. The company needs such people.
For project management, there must be someone in the project team who can talk to
people from the company at eye level to understand the wishes, needs and objectives
of the customer and enable the close cooperation mentioned above.

For project management to create great long-term added value for customers
through a transformation project, project managers must recognise when necessary
5.8 Impact of Digitalisation on Project Management 175

talent is not available within the customer’s organisation. And they must support the
customer with advice or at least point the way forward.
Another effect of digitalisation on project management requirements includes the
need to understand how digitally affine people tick. The flattening of hierarchies
means more participation of members at levels across organisations, thus a loss of
hierarchy-based power and a greater need for conflict management skills.

5.8.4 Use of Data and Advanced Technologies

The use of data and the latest advanced technologies is what many people think of
first when they think of digitalisation—and this is understandable because, at first
glance, this is exactly what it is all about. If we look at this area of digitalisation from
a project management perspective, we can see deeper aspects of the use of data and
technologies. Issues such as data collection, personal data protection, customer
consent and cybersecurity have always been important. With the possibilities of
bringing together even more data more easily and quickly, they become even more
critical. Project management must consider these aspects of the project and ensure
that the decision-making paths and processes are clear and good, cooperative
relationships are established. These include relationships with data protection
officers, risk management and the works council or other employee representative
bodies.

Dealing with the Legacy: Legacy Systems

The speed at which new technologies are developing means that more new tools and
methods are constantly emerging, which can meet the customer’s needs and achieve
their objectives. In companies that have repeatedly introduced partial solutions and
interim solution technologies over time, the project team will be confronted with
legacy systems. The project team often has to evaluate whether integrating old legacy
systems is possible and sensible for the customer and achieving their goals or if
building an entirely new system is the better solution.

And because the customer often learns about the growing flood of possible
solutions and integration options, project management must convey a clear picture
of why the path agreed upon is the right solution—knowing full well that nothing
lasts forever, especially in the VUCA world of digitalisation.

5.8.5 Digitalisation of Operations and Automation of Processes

Organisations that want to gain the most benefits from digitalisation must take a
holistic view of their organisation—all operations, processes and networks. There
are two main actors across the whole range of these operations: people and technol-
ogy, including machines.
176 5 The Underestimated Success Factor: People

The centralisation of processes and the homogenisation or integration of technol-

ogy platforms means that fewer interfaces are needed to manage the company’s
operations. By combining large amounts of data with analytics and artificial intelli-
gence (AI), machines can completely take over more and more tasks previously
partly done by humans aided by machines.
These two facts have the following effects: the project management team needs to
look intensively at the company’s operations and processes to gain a good under-
standing of the scope of process changes together with the key users.

In the Dictionary, Change Comes Before Empathy: But Not in Life

The project manager must be aware that the topics of change management and
communication are of absolutely central importance for the cooperation and ulti-
mately for the project’s success. With all the progress and benefits that digitalisation
brings to the business, there is still the fact that the changes will be significant, not
just positive, for the people in the business.

The entire project team must be aware that a transformation project is always
about much more than just changing technology and business processes. The project
can change an employee’s entire life, even if the change initially takes place mainly
in the working environment. Empathy is needed to put oneself in the other person’s
position, e.g. to recognise and invalidate the cause of any resistance more quickly.

To bring about change, you have to take away people’s fear. They must understand why the
change is necessary and what will happen. (Quote by a CIO and former head of global
transformation projects)
Project Planning, Control and Quality
Assurance 6

Project planning, Control and Quality Assurance are areas of

the project where the focus must be shifted from creativity to
discipline.

In this chapter, we would like to empower you to master planning, control and
quality assurance of your project. It is not our goal to take you into the world of
scientific methods. It is our aim to show you the activities and procedures which, in
our many years of practical experience, really matter.
A competent project management office (PMO) is crucial for successful planning,
control and quality assurance. Before we go into the abovementioned topics in more
detail, we would like to present our view of the PMO.

6.1 Support Whenever You Need It:

The Project Management Office

Project Office vs. Project Management Office

The project office usually performs administrative tasks and provides support for the
project management and project specialists. The administrative tasks include support
creating and updating of project plans and the recording of project master data,
collecting time sheets, etc. The employees in the project office provide information
about the project (e.g. project plans, project status reports and key figures) to support
the project management.

Supplementary Information The online version of this chapter (https://doi.org/10.1007/978-3-

030-86084-4_6) contains supplementary material, which is available to authorized users.

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 177
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_6
178 6 Project Planning, Control and Quality Assurance

The PMO: To Serve and Support

The definition of a project management office (PMO) goes beyond this scope
(although the terms are by no means used uniformly in the project management
literature). A PMO is generally understood to be a team with much more extensive
tasks and competencies that cannot be covered by project managers alone in an SAP
project.

The PMO’s tasks may vary according to the size and complexity of the projects. We
recommend that you entrust your PMO with the following tasks:

• Planning and management of the project

• Training of the project participants
• Coaching of the sub-project leaders
• Training the project staff on project standards and tools
• Implementation of project management trainings for project staff and project
management, even including preparation for certifications

The lynchpin of these tasks is the area of planning and management, which we
have therefore placed at the top of our list. These activities can be broken down even
further. The PMO’s staff carry out the following activities:

• Introduction of uniform project management standards and tools

• Structure and content of project plans and a creation/rollout of a uniform reporting
system
• Coordinating the deployment of staff in cooperation with the departments
• Alignment with parallel projects in the company
• Monitoring project progress through regular status meetings based on ongoing
project progress analyses
• Conducting internal project reviews and organising project audits by external
auditors
• Follow-up on action plans
• Coordinating and prioritising new requirements in the project

Ideally, you will establish your PMO team at the project location with a team
leader. Team leaders in the PMO should be a certified project manager with SAP
project experience and in-depth knowledge in the following areas:

• Project methods (SAP Activate, PMI, PRINCE2 quality assurance measures)

• Project tools (e.g. project planning tools, SAP Solution Manager, MS Project, test
tools, etc.)

The PMO is thus the body responsible for carrying out the tasks described in this
chapter, for planning, controlling and quality assurance. In the following sections,
we look in detail at how the PMO staff can achieve these objectives. Figure 6.1 gives
an overview of the tasks of the PMO.
6.1 Support Whenever You Need It: The Project Management Office 179

ensure use of
common
provide project standards and build project
management tools plans and
training reports
Training
educaonder of
Projekeil-
project project planning,
members
nehmer - controlling

organize
personnel
coaching of deploymentsfr
Project Leads om business
Project
units
Management
Office
control of
Kontrolle der (PMO) coordinaton
project with parallel
Projeknhalte
content projects

ensure quality assurance document and overall project monitoring

perform internal monitore project
track acon
project reviews progress
plans

Fig. 6.1 Overview of the PMO’s tasks

Divisional
Management

Project
Department 1 Department 2 Department 3 Management Office
(PMO)

Project a Project c Project f

Project b Project d Project g

Project e

Fig. 6.2 Cross-project project management office

Parallel Projects
It is quite common that several projects are carried out in parallel in the company. It is
obvious that all organisational tasks should be bundled in one PMO, which is respon-
sible for all projects. In such cases, you need to consider to whom the PMO should be
assigned organisationally. It makes sense to establish a cross-project PMO directly
under the divisional management or even the executive management. Figure 6.2
illustrates what the company or divisional hierarchy might look like in such a case.

Your Own PMO

In this organisational form, the PMO management reports to the divisional manage-
ment or, depending on the size of the company, to the executive management.
Communication with the projects in the individual departments is handled by the
respective project managers.
180 6 Project Planning, Control and Quality Assurance

Divisional
Management

Project Lead

Project
Sub-Project 1 Sub-Project 2 Sub-Project 3 Management Office
(PMO)

Team a Team c Team f

Team b Team d Team g

Fig. 6.3 Project management office integrated into the project

However, we strongly recommend to be “selfish” and establish your own PMO if

possible. You will definitely need direct support. You should also bear in mind that
with a higher-level PMO, you have an additional player with whom you will have to
deal on a daily basis.
If your project is assigned its own PMO, the team management reports to the
overall project management in this case. The organisational hierarchy when the
PMO is integrated into your project is shown in Fig. 6.3. We consider such direct
integration of the PMO into the project to be an essential prerequisite for the success
of the project.
The following sections will show you which measures are necessary to ensure
that projects are carried out properly, in scope, on time and within budget.

6.2 Project Planning

“Good planning is half the battle”, they say. In this section, we will show you how
crucial sound and qualified planning really is for project success. To illustrate this
importance, we would like to give you a real-life example.
“ACME Corp.” is a global corporation in the automotive supply industry,
producing car spare parts. The monthly figures for the first quarter of 2020 show
that the planned results for the current year are unlikely to be achieved, as sales
development is behind expectations while costs continue to rise steadily. At the
monthly board meeting, the CFO, Mr. Blunt, recommends reducing the costs of the
process organisation by modernising internal IT applications. The Board of
Directors then instructs Mr. Blunt to set up a project.
Mr. Blunt is asked to return within the following 3 weeks with a project proposal.
He decides to modernise the order entry processes and to bring the invoicing system
up to date, using the standard software SAP.
6.2 Project Planning 181

The corporation’s board of directors is very pleased with the proposals and gives
Mr. Blunt the project order. Mr. Blunt tries to nominate a project manager. Unfortu-
nately, no qualified or even certified person can be found at short notice.
To keep the date for the presentation to the board, Mr. Blunt temporarily pulls in a
project management team from a parallel project to support him in the preparation of
the project proposal. At the next board meeting, he presents a high-level proposal,
which already promises initial dates, without having been able to analyse the
complexity, the dependencies on other areas and the availability of skilled staff.
Nevertheless, the board accepts the proposal and brings its own change requests into
the project. Mr. Blunt is now called upon to implement the project, start work as soon
as possible, meet the deadlines and, if necessary, even beat them.
As an interim solution, a committed and talented employee, Mrs. Miller, from the
specialist department, will be assigned as the provisional project lead. Although Mrs.
Miller has proven to be a pillar of the finance department, she has no experience with
large ERP projects. She only knows SAP systems as a user. The first specialists are
brought on board. Weeks go by without a detailed project plan being developed. The
coordination of the detailed requirements with the departments concerned (pro-
cesses, software selection, system architecture) is still not complete. Consequently,
the final dates for these tasks have not yet been defined in the project plan. In this
phase, Mr. Blunt is requested by the board to present the status of the project at the
next board meeting. The board would like to know when the new software can be
introduced and what benefits can be expected for the success of the company.
Mr. Blunt assigns Mrs. Miller, his interim project manager, to prepare a status
presentation. He assumes that a finished project plan with the essential key data
already exists. Hectic activity breaks out: Ms. Miller quickly tries to gather all the
data for a status report and to deduce a possible introduction date—not an easy feat
with so many open questions and the rather informal approach taken so far. To the
best of her knowledge and belief, she prepares a presentation, which Mr. Blunt
presents to the board. The implementation date is accepted by the management.
However, this date proves to be a heavy burden for the project. (For more informa-
tion on how to proceed with our example company, please refer to Sect. 6.3, “Project
Control”.)
This small example already shows a number of classic mistakes that can put a
project in a difficult position from the very beginning:

• The foundation is laid by an interim project manager without project management

experience, and without SAP knowledge.
• At this point in time, the project contents (scope) are not fully specified.
• There is no overview of all necessary activities.

These stumbling blocks alone cause planning and design errors, this at a time
when the project is still in a very early stage. It is not possible to make a reliable
statement on contents and schedules on this basis. This makes communication all the
more dangerous in this phase. Once a deadline has been published and anchored in
182 6 Project Planning, Control and Quality Assurance

people’s minds, it is difficult to say the least to wake up to a very different reality
later.
Of course, we hope that your projects do not end up in similar situations and
would like to give you some help in the following. .

6.2.1 The Pillars of Project Planning

You should be aware that by creating and communicating a plan, you are making a
commitment to achieve the project’s objectives. Your customers (whether external
or internal), your stakeholders, your clients and your project partners must be able to
rely on the plan and support it. You can only achieve this if all parties involved
consider the plan to be feasible. Figure 6.4 shows the pillars on which good project
planning is build.
As already mentioned in Sect. 3.4.1, “Phase 1: Planning and Preparation”, the
plan is subject to changes in the course of the project. It will be continuously
expanded, fleshed out and adapted as necessary. It is important, however, that the
overall objectives of the project, i.e. introduction dates, costs and goals (content and
quality), remain constant and are not thrown overboard on a whim.
Regular comparisons of planned vs. actual data form the basis for plan
adjustments. If shifts in the introduction dates or project costs become apparent,
these must be coordinated with the steering committee, the project sponsor and even
the management.

6.2.2 Planning Factors: Goals, Deadlines and Cost

The main factors on which any project planning is based are the project objectives
(content and quality), the project deadlines and the costs. There is naturally a mutual
dependency between these factors, which is illustrated by the triangle in Fig. 6.5. If
there are deviations from these factors in the planning or in the course of the project,
the project priorities must be renegotiated.

Fig. 6.4 Pillars of project

planning
Pillars of Project Planning
Constancy
Feasibility
Reliability
6.2 Project Planning 183

Fig. 6.5 Factors in project Objecves (Content and Quality)

planning (based on Kuster,
Jürg, Handbuch
Projektmanagement, Springer
2008)

Date Cost

6.2.3 How Do You Plan a Project?

In the preliminary phase of the project, you are already required to define the
objectives of the project within the framework of a high-level planning. On this
basis, you usually receive the project order for customer projects or the project
release and budget approval for internal projects. Even at this early stage, an
important difference between traditional IT projects and SAP projects becomes
apparent.

Difference Between Classic IT and SAP Projects

In traditional IT projects, business requirements are defined and then implemented
through programming. In SAP projects, you must already have an idea of the extent
to which the business requirements can be mapped in the SAP standard (i.e. through
customising) and how much programming will be involved. The extent to which the
SAP standard can be used depends, on the one hand, on the willingness of the
company to change processes in order to follow the SAP standard as far as possible.
On the other hand, the qualification of your SAP consultants is key, because they
ultimately assess the amount of customising versus programming.

As a rule, detailed requirements are not yet available in the initial planning phase.
This where the consultants’ experience from similar SAP projects comes into play.

Note: Making It Tangible: The Prototype

It makes sense to configure an SAP prototype at an early stage to help
convince the representatives of the specialist departments of the SAP standard
processes. This may allow you to reduce your expenditure and the duration of
the project. The more effort you invest at the beginning to find out what is
possible with SAP “out of the box”, the better your basis to go into detailed
planning.
184 6 Project Planning, Control and Quality Assurance

How Detailed Should Your Plans Be?

How far do you have to go in detail in your planning? “It is the mark of an educated
mind to rest satisfied with the degree of precision which the nature of the subject
admits and not to seek exactness where only an approximation is possible.” These
wise words are attributed to Aristotle—and this is also the gist of project planning:
you move along the narrow ridge of planning as detailed as necessary but as simple
as possible.

Different items need to be considered in the detailing (see Tran-Gia, Phuoc 2013).
A higher level of detail has the following advantages:

• Greater transparency
• Early identification of opportunities and risks
• Reduction of uncertainties

On the other hand, a lower level of detail brings the following advantages:

• Reduction of the complexity of the plan

• Reduction of planning effort and time
• Reduction of the planning control effort

You should be aware that a structured and complete plan is the most important basis
for the success of your project. In several iterative stages, you will need to create
successive plans, which ultimately form the basis of your overall plan.

Work Breakdown Structure: The Mother of All Plans

It all starts with the work breakdown structure: with the work breakdown structure,
you create an overview of all tasks in the project and the basis for all subsequent
planning. It describes the overall project goals, the sub-projects, the tasks and the
work packages in the sub-projects. You can see an example of a work breakdown
structure in Fig. 6.6.

Based on the already defined overall project tasks and sub-projects, you develop
the following detailed plans:

• Work packages
Work packages contain all necessary development activities (process design,
customising, programming and all supporting activities).
• Effort estimation
The procedure for effort estimation is described in Sect. 6.2.4, “How Expensive,
How Long, and How Much? The Effort Estimation”.
• Personnel planning/resource planning
Here, you plan the staff deployment and the technical requirements (e.g. SAP
systems). Make sure that you do not schedule your employees with 100% of their
working hours from the beginning and on weekends. Bear in mind that the crises
6.2 Project Planning 185

Work Breakdown Structure

W
Project

Subproject A Subproject B Subproject C

Task A 1 Task A 2 Task B 1 Task B 2 Task C 1 Task C 2 Task e C 3

WP WP WP WP WP WP WP
A 1.1 A 2.1 B 1.1 B 2.1 C 1.1 C 2.1 C 3.1

WP WP WP WP WP
A 1.2 A 2.2 B 2.2 C 2.2 C 3.2

WP
C 2.3
WP = Work Packages

Fig. 6.6 Example of a work breakdown structure (based on Projektplanung 2, Tran-Gia, Phuoc
2020)

are still to come and that you must retain some flexibility. Think carefully about
what you can achieve with your project team, keeping a buffer for medical and
other leaves.
• Dates/procedure
The time required for each work package is estimated. Then assign the work
packages to the project phases in a logical sequence. At the end, there is a
milestone (¼ a target date with a list of results). Carefully work out the critical
paths for the activities that are directly interdependent and must be completed in
sequence.
• Costs
The cost planning is based on the estimated times per work package. Other costs
(hardware, software, travel expenses, etc.) are also included in the cost planning.
• Risk management
Potential project risks and measures to deal with them are part of the plan. It is
advisable to include a risk surcharge for this in the total expenditure.
• Communication plan
The communication plan contains the dates/frequencies for status meetings in the
project and for higher-level meetings (steering committee, stakeholders) and the
dates and addressees for status reports (see subsection “Setting Project Standards”
in Sect. 6.3.1, “Guidelines for Successful Project Control”).
• Quality assurance plan
The quality plan shows when and by whom regular walk-throughs, inspections
and project reviews are carried out (see Sect. 6.4, “Quality Assurance”).
186 6 Project Planning, Control and Quality Assurance

Work Breakdown Structure

Work Packages Effort Esmaon

Sequence Personnel-/ Cost Risk Communi- Quality-

Schedule Plan
Planning Resource-Plan Planning Management caon Plan

Fig. 6.7 Planning hierarchy for all plans

Figure 6.7 shows the planning hierarchy for all plans.

How to Create a Work Breakdown Structure

Three methods are available for the creation of work breakdown structures:

• Top-down approach
This so-called deductive approach (or top-down approach) leads from the big
picture to the details. The work breakdown structure is divided into subtasks, and
the subtasks in turn are further divided into work packages. For this approach, you
need extensive knowledge of the contents of the project and the possibilities
offered by the SAP standard. Experience from projects of similar size and scope is
helpful here. Without this experience, you increasingly run the risk that the plans
on the lower levels will prove to be unrealistic and unfeasible.
• Bottom-up approach
This so-called inductive path leads from the detail to the whole. All project tasks
need to be collected and structured. Based on that, you build a task hierarchy. This
approach is advisable if you have little experience with corresponding projects.
However, there is a much higher need for coordination and thus planning effort
and the risk that in the end, the scope is too large to be realised in the given time
and with the given resources.
• Yo-Yo procedure
Here, you alternate between the above approaches, thus taking advantage of the
benefits of both procedures. In the end, this is the safest method to ensure that no
task is missing. Start with the top-down approach to determine the major
milestones, and fill in the blanks (and at the same time validate) via the bottom-
up approach.

Both the top-down and the bottom-up methods, when used alone, carry great
risks. We consider the iterative process of the yo-yo method to be the best way to
arrive at realistic and reliable plans, in terms of effort/scope, time and budget.
Figure 6.8 shows the main features of these methods.
6.2 Project Planning 187

Top-Down Approach
- high experience needed
Deducve Path - high risk (possibly Not
from the whole to details doable in detail)

Yo-YYo-Yo Procedure ( (Strategy-Mix)

safest method, not to miss tasks

- high communicaon needs

Inducve Path
- safest path, in case of lile
from details to the whole
experience

Boom-Up Approach

Fig. 6.8 Comparison of top-down, bottom-up and yo-yo methods

6.2.4 How Expensive, How Long, and How Much?

The Effort Estimate

Estimation of expenditure is of particular importance in the context of project

planning. It represents the central challenge with which the success or failure of
your project ultimately stands or falls. We therefore would like to show you how to
proceed with the effort estimation.
Similar to work breakdown structure creation, you will find both the top-down
and bottom-up methods for estimating expenditure being used.

• Top-down estimation
Top-down means that the individual budgets for sub-projects and work packages
are derived from a total expenditure (and thus a total budget). We consider this as
a risky approach in an SAP project. It takes a great deal of experience, preferably
from similar projects, to dare to make such an effort estimate. Whoever
undertakes this estimation should already have an overview of the relationship
between SAP standard and in-house developments at this stage (which is usually
never the case).
However, there are clients who like to use this approach to build up pressure
on the project budget, to limit the number of change requests of the project from
the outset.
• Bottom-up estimation
Bottom-up estimation is much more precise but also much more complex. In this
case, the bases are the work packages, which have been evaluated in detail. It is
already determined in which time and with which effort the respective work
packages can be implemented. For this procedure, we strongly recommend the
use of a project planning software (see Chap. 9, “Project Support Tools”).
188 6 Project Planning, Control and Quality Assurance

• Mix of methods
In practice, you will often find a mixture of these methods by trying to approach a
reasonably realistic estimate in an iterative process. Figure 6.9 shows the sticking
points of the respective methods at a glance.

Top-Down Effort Esmaon

extensive experience with

SAP projects necessary
risky

Mix of Methods
most realistic estimation

Präzise
Aber aufwendig
precise
but costly

Boom-Up Effort Esmaon

Fig. 6.9 Top-down and bottom-up effort estimation, mix of methods

SAP Objects Person

Blueprint Days

Interfaces
Development Effort

Reports
Forms
Converons
Addional Effort
Data Mapping
Workflow Addional
Requirements
Extensions…
Programming & Customizing Communicaon

Documentaon
Test
Data Migraon
% of
Develop- Project-
Mgmt. Error Fixing
ment Effort Go Live

General Cost (e.g. Travel Cost..) Producon -

Preparaon / -Build

Fig. 6.10 Example model for estimating the effort of SAP projects

Figure 6.10 shows a model for estimating the effort for an SAP project. The
model is based on the fact that the development effort (programming and
6.3 Project Control 189

customising) per SAP object is first determined in days. All further efforts are then
calculated as a percentage of the development effort. It makes sense to classify the
development effort for the individual objects according to complexity (e.g. in high/
medium/low) and to allocate these days for each object based on experience. The
granularity of the classification can of course be refined as desired.
An example of this model can be downloaded as a Microsoft Excel file.

Tip: 7 Tips for Project Planning

1. Involve your team in the planning processes from the outset. This increases
transparency and understanding of the project, which has a positive effect
on the motivation of your project staff. The combined expertise will
increase the quality of your planning.
2. The more effort you invest in the beginning to explore the possibilities of
the SAP system, the more solid is your plan.
3. Use the possibilities of an SAP prototype to convince the representatives of
the specialist departments of the functions of the SAP standard and thus
reduce both project effort and project duration.
4. Put your PMO in charge of planning and control.
5. Use a planning tool for planning and control. In our experience, we
recommend using Microsoft Project for scheduling, progress tracking and
cost control (see Sect. 9.1, “Project Management Tools”).
6. React immediately if you notice a deviation from the target. It may be
necessary to reflect the changed situation in your plans. Close change
request management is crucial to avoid “scope creep”, which can otherwise
lead to cost and time overruns.
7. Pay attention to the appropriate granularity of your plan. Planning must not
become an end in itself.

6.3 Project Control

With the help of regular plan/actual comparisons, you maintain an overview of the
project progress and can react in good time to deviations and initiate corrective
measures. The basis of the plan/actual comparisons are detailed project plans in
which you have specified work packages with times, milestones, efforts, personnel
requirements and costs, as described in the previous section. Again, the goal of
project control is to become aware of deviations from the plan as early as possible so
that there is ample time to react to them.

Real-Life Project Example

The difficulties you may face in project control are illustrated by the continuation of
the fictitious practical example from Sect. 6.2, “Project Planning”.
190 6 Project Planning, Control and Quality Assurance

Mrs. Miller will take over the management of the entire SAP project with the
words “now you can prove yourself”. The project she originally worked on will be
passed on to an ambitious young colleague. However, Mrs. Miller is expected also to
be available for her old project with advice and support.
In the meantime, a project plan with the key data is also available. Mr. Blunt, the
division manager, got the commitment from the various departments that the project
will be supported. However, the nominated departmental staff will not be available
full time, as the day-to-day business still has to be taken care of.
During the weekly status meeting with the board of directors, Mr. Blunt learns
that additional requirements should be included. Confronted with these wishes, Mrs.
Miller points out: “The deadlines are already ambitious. If we now also include new
requirements on the agenda, they cannot be kept”. Mr. Blunt reacts gruffly: “Mrs.
Miller, please add this to your list, these changes will certainly be possible.”
At the same time, enquiries to Mrs. Miller from her “old project” are piling
up. She feels compelled to delegate the regular status meetings with the project team
to her colleague, Mr. Schultz. Mr. Schultz is participating in a project for the first
time and is doing his best.
Due to time constraints, he sends out invitations for the status meetings to the
participants the evening before the meeting without a meeting agenda. When the
team gathers around the conference table the next day, each participant provides a
status of his or her tasks. However, these results are not recorded. Mr. Schultz
informs the project manager, Mrs. Miller, verbally about the discussion topics.
At the next board meeting, the management would like to know how the SAP
project is progressing. Mr. Blunt is not prepared, gets nervous and makes only a
short comment: “Everything is on track”. He is then prompted to deliver a detailed
status report at the next board meeting, 1 week later. Now hectic activities take over
again. Mr. Blunt informs Mrs. Miller. Mrs. Miller turns to Mr. Schultz, who first
starts to stutter. Mrs. Miller must gather all the necessary information in several
discussions with her project team. In the process, the development team signals that
there could be delays in the introduction date due to new requirements demanded by
the board.
Mr. Blunt does not have the courage to point out these risks at the board meeting.
Rather, he reports that everything is going according to plan and the project team is
working hard to achieve its objectives.
We hope that you will be free of such situations in your projects. However, this
somewhat exaggerated description shows how crucial a clear project structure,
project progress checks, competent project managers and honest communication in
problem situations are for the success of a project.
Finding out which problems will have to be overcome is one of the most
important tasks of project control. The list of pitfalls (see Chap. 4, “The SAP
S/4HANA Project: How It Is”) is long, and unfortunately, there is no silver bullet
for every project and for every potential problem. However, in this section, we
would like to provide you with general guidelines for successful project control.
6.3 Project Control 191

6.3.1 Guidelines for a Successful Project Control

The starting point for successful project control is a thorough inventory of all
resources (staff and documents) available to you.
The next step is to create the prerequisites in terms of organisation, staff assign-
ment, project standards, project management methods, status controls, key perfor-
mance indicators/measurement systems and the monitoring of project risks.

Note: What Is Often Missed in Real Life?

It is a fundamental mistake if structured project control is not given the
necessary importance by all project participants. Without professional
reporting, using project management tools and without sufficient key figures,
there will be a lack of transparency. Project progress is difficult to evaluate,
and as you don’t know your project’s true status, you cannot address any new
issues in a timely manner.

Ultimately, you will be measured by the success of your project: your goal must
be to complete the project to the satisfaction of your company or your customer on
time, within budget and with the agreed quality. Below you will learn the most
important factors on the way to achieving this goal.

Taking Stock: Where Are We?

The basis for project control is a thorough inventory survey about the skills of your
project staff and existing documents and tools:

• Expertise of the Team Members

– Are all employees with the needed skills available?
– What is really possible with the skills of the available employees?
– Do the team members already have some experience with project management
methods?
Are the investments for the instruction and training of employees in methods and
tools included in the plan?

• Documents and Tools

– Are there reusable instructions, checklists, documentations and lessons learned
reports from previous projects?
– Have tools been used in previous projects, that can also be used in the new
project?

Carefully taking stock saves time and costs and protects against surprises in the
later stages of the project. Additionally, this careful stocktaking serves as a baseline
for communication and expectation setting with the project stakeholders.
192 6 Project Planning, Control and Quality Assurance

Select a Method
There are a large number of different project management methods, including agile
project management methods (e.g. Scrum, eXtreme Programming, Kanban, etc.). As
the leader of an SAP project, however, you do not need to worry about this. From our
point of view, there is only one recommendation:

Use the Activate method!

Assign Employees and Define Responsibilities

The decision for a project organisation and the assignment of the employees to the
work areas is a decisive step for the implementation of your project. For the choice
of project organisation, please refer to the description of potential organisations in
Sect. 2.2.2, “What Types of Project Management Are There?” Each of these forms of
organisation has a direct influence on the overall organisation of the company. It is
important that the adopted organisation is accepted and supported by the executive
board, as well as by all department heads.

Take great care when selecting project staff members and assigning them to work
areas and teams, according to their expertise, role competence, availability and
capacity. You should be aware that this is the most important foundation stone for
your project.

Note: Soft Skills as a Success Factor for Project Control

In this book, we have often pointed out how easily the human factor of success
is underestimated in projects. We would therefore like to take this opportunity
to emphasise once again the importance of leadership, motivation and perse-
verance in successful project control. Tips for an effective management culture
and more motivation in the project can be found in Chap. 5, “The
Underestimated Success Factor: People”.

If Responsibilities Are Not Clear, Nobody Feels Responsible

In order to ensure effective monitoring of the project, it is necessary to define clear
responsibilities, e.g. in a RACI matrix (RACI stands for Responsible, Accountable,
Consulted, Informed), which clearly defines the responsibilities for different tasks:

• Responsible (R)
Responsible is the person (or several persons) who carries out the actual task or
delegates the execution to other persons. Responsible is to be understood here as
“getting it done”.
• Accountable (A)
The accountable person is responsible for the acceptance of the work performed
by the responsible person. This person is legally or commercially responsible for
6.3 Project Control 193

the task in question (e.g. cost centre responsibility). This often includes
delegating the work to sub-projects. Only one person/party may be “accountable”
for each task.
• Consulted (C)
One or more persons who are not directly involved in the implementation but who
have relevant information. These could be experts in various fields, who contrib-
ute detailed information or assessments of the project.
• Informed (I)
These people are informed about the progress and/or result of a task.

A RACI matrix defines, for example, the responsibilities in project management,

regarding the scope of customising the SAP system, data migration, testing and
coordination with the specialist departments or end users. Figure 6.11 is an example
of a RACI matrix, which shows in the responsibilities between the customer and an
external project partner.

Tasks Task Descripon

Customer External Partner

R A C I R A C I
Project Preparaon
Kick-Off Presentaon Common Task: Customer and External Partner X X

Project Cookbook Includes all tools and management procedures, X X

e.g. risk management.
Quality Management Quality Plan (specificaon of quality assurance X X
tasks)
Project Plan Detailed Project Plan (e.g. in Microso Plan) X X X

Communicaon Plan Descripon who needs to be informed about the X X

project status (schedule and format)
Prototype Concept Descripon of content and objecves of the X X X
Prototyping
Prototype Environment Decision on system, processes and data X X

Business Process Requirements

Business Process Overview Idenficaon of the main processes X X

Detailed Processes Descripon of the detailed processes X X

(including Process Flows)

……. …….

Fig. 6.11 RACI matrix for the division of work between customer and external project partner
194 6 Project Planning, Control and Quality Assurance

Tip: 5 Steps to Create a RACI Matrix

Proceed as follows when developing your RACI matrix:

1. What are the responsibilities?

First you need to clarify with your team which roles a RACI matrix covers
and which obligations are associated with each role. It is important to
ensure that everyone has a common understanding of the roles.
2. Who has which responsibilities?
Now assign the tasks to each role. In the rows of the RACI matrix are the
tasks and in the columns the roles.
3. Who has what task?
The first thing to do is to determine who is accountable for which task. In
the RACI matrix, this role is usually marked with an A. Assign the other
necessary roles to each task. The abbreviations R, A, C and I are usually
used here. Each task must have exactly one “A” and one or more “Rs”.
4. What is the completion date of each task?
In connection with the distribution of roles and tasks, it makes sense to
define who carries out which activities and when and who has to be
informed when and by whom.
5. What has changed?
Do not fail to update the RACI matrix if tasks or roles change.

In the materials of this book, you will find a detailed example of a RACI matrix.

Use Forecasting Techniques

Various methods are available for assessing your project situation:

• The cost trend analysis (CTA)

The cost trend analysis compares the actual costs with the planned costs at the
time of the analysis and extrapolates the expected costs up to the end of the
project.
• Milestone trend analysis (MTS)
The milestone trend analysis is used to determine the progress of the project on
the basis of planned milestones in order to detect delays at an early stage. It is then
necessary to evaluate the effort, which needs to be spent, to reach the milestones
and to determine potential delays.
• The Earned Value Analysis (EVA)
The earned value analysis shows the progress and the predicted development of
the work packages defined in the plan. The following formula is used to calculate
the earned value: Earned Value ¼ Percent complete (actual) x Task Budget.

There is of course no question that project management methods and forecasting

techniques are important factors in the project approach. However, in our view,
6.3 Project Control 195

common sense is at least as important for project management. By this, we mean the
ability to observe, listen and draw the right conclusions. The exciting questions you
have to deal with almost every day are “Where are we in terms of project comple-
tion?”, “Are we achieving the milestones?” and “How do problems in certain areas
of the project affect the overall goals?
Therefore, our advice is do not invest effort in the implementation of complex
theories and concentrate on detailed planning and consistent control of your project
steps. Project management is more of a practical craft than scientific theory.

Set Project Standards

If you are starting your project on a “Greenfield” site and you have not yet found any
usable project standards when you take stock, you have to establish such standards.
In particular, standards for reporting and communication (see Chap. 5, “The
Underestimated Success Factor: People”), including project status meetings, need
to be established.

You should implement the following procedures:

• Documentation structures for processes and developments

• Configuration standards
• Authorisations
• Error handling procedures
• Reporting system

Among others, the following reports are mandatory:

• Internal reports about the status of the work packages, including forecasts, in case
of deviations from targets
• Status reports on sub-projects and the overall project

Project Status Meetings

Define the frequency and content of status meetings, meetings with the steering
committee and with your stakeholders as well as the templates, dates and recipients
for regular information on the progress of the project.

The project management invites to regular project status meetings. Make sure that
the meetings are limited in time (max. 1.5 hours). They should be used exclusively
for the exchange of information, to present the current problems and to determine the
next steps. Detailed discussions on problem solutions and coordination of corrective
measures must take place outside these meetings to ensure that they are efficient
means to determine the current project status.
In an ideal world, all project members take part in the project status meeting.
However, this is in many cases not possible due to the size of the projects.
196 6 Project Planning, Control and Quality Assurance

Participation is therefore limited to sub-project leaders or team leaders for specific

work packages.
An agenda for a project status meeting could include the following agenda items:

1. General: Information on current events, changes in the project team, in the project
plans, etc.
2. Project status per work package: Project progress and possible deviations from
targets (deadlines, capacities, costs), and risks.
3. Actions to be taken: Identify need for action or decision and agree on actions.
4. Action status: Status of actions that were previously agreed/taken.
5. Any other business: General information.

Tip: Efficient Project Status Meetings

The efficiency of meetings is increased if you let your PMO check and assess
the status of work packages and actions that have not yet been completed. This
allows you to concentrate on the critical points in the status meeting. The
results of the meetings must be recorded! Do not forget to appoint a minute-
taker at the beginning and ensure proper minute-taking standards are
established and adhered to.

Target Group-Specific Reporting

Target group-oriented, regular reports on the progress of the project are indispens-
able for project management, steering committee, client/customer and stakeholders
for managing the project and reacting to new development. However, not all project
participants require the same level of detail or frequency of reporting. Therefore, you
must tailor your project reporting to the target group’s needs.

In addition to tailoring the report to the respective target group, you should also
pay attention to the necessary administrative effort in relation to the benefit of a
particular report. There is certainly a risk that your reporting system will become an
end in itself with a high level of effort and that the thorough analysis of the results
will suffer as a result.
Here is a selection of possible report contents:

• Status and results of the work packages

• Plan deviations
• Target and actual dates
• Target/actual costs
• Budget deviations
• Risks, problems and, where appropriate, need for action

Figure 6.12 shows an example of a project status sheet. The template for this can
be downloaded.
6.3 Project Control 197

Project:
status
start end status
Main Acvies date date
prev.-
actuall
week
Team Name:
Status previous week actual status

(red – yellow - green)

Dates
Milestones plan actual status status
date date prev.- actual
week
Dependencies responsible status

crical situaon resp. open target actual

since date date

risks O (*1) D (*2) acons

(*1)O = probability of occurrence

(*2) D = extend of damage

Fig. 6.12 Example of a project status sheet

For regular communication within and outside the project, you need to define the
appropriate meeting structure. We recommend weekly project status meetings.
Meetings with the steering committee or with stakeholders can be held monthly if
the project is not in a critical state.

Note: Meetings with the Steering Committee/Stakeholders

We recommend monthly meetings with the steering committee. In the case of
uncritical project progress, stakeholder meetings can be held every 2 or
3 months, depending on the overall project duration. The aim of the meetings
is to inform the committee about the progress of the project. Important
milestones (at least the completion of one project phase and entry into the
next phase) should be approved by the steering committee.

6.3.2 Carry Out Control Processes

You have created all the prerequisites for effective project control. Now it is
important to carry out project controls continuously and regularly, from the begin-
ning of the project to its successful completion. Consistent cost and quality monitor-
ing of the projects is the basis of all project control. Milestones and schedules form
the project control system.
198 6 Project Planning, Control and Quality Assurance

Based on your planning and the schedules and milestones defined in it, you
control the progress of the project. Regular plan/actual comparisons of the comple-
tion date, costs and resources show you the current status of the project.
The basis for the comparison of planned/actual data is provided by detailed
project plans, described in Sect. 6.2.2, “Planning Factors: Goals, Deadlines and
Cost”, in which you have specified work packages with durations, completion dates,
milestones, efforts, personnel requirements and costs.
This allows you to keep an overview of the progress of the project and to react in
time to deviations and initiate corrective measures. Proactive project reviews give
you an additional picture of the situation in the project (more on this in Sect. 6.4,
“Quality Assurance”).
Based on the results, thorough and realistic analysis and interpretations of the
respective situations are carried out. If there are any deviations from the plan, you are
required to intervene and initiate the appropriate countermeasures to correct them. In
critical situations, you prepare the necessary decision-making proposals for your
management. In your regular status meetings, you follow up on the agreed measures.
Your most important helper in determining the project status and developing correc-
tive actions should be your project management office (PMO).

Using Key Figures and Measurement Systems

You should design key figure and measurement systems in such a way that you can
identify deviations from your planning data at an early point in time so that you can
still take corrective action. They represent your early warning system in the project.
It would go too far in the context of our book to explain KPI systems in detail.

We merely provide an overview of possible areas of application for key figures:

• Key figures for the work packages (adherence to schedules, capacity

utilisation, etc.)
• Indicators for specific project teams and stakeholders regarding the satisfaction
and the degree of utilisation of the project: customers, project management,
specialist departments, end users, steering committee, etc.
• Financial indicators (budget compliance, business case, etc.)
• Key personnel figures (fluctuation, morale, etc.)
• Quality indicators (results from reviews, etc.)

You can always add more key figures to the list. However, when selecting the key
figures, we recommend weighing up the regular effort required for this and the
benefit for controlling the project. What is the actionable information gain compared
to the time invested?

Risk Management
Actively monitoring project risks is an important part of project control. Particularly
in the case of very complex SAP projects, it is very important to identify risks at an
early stage and to initiate countermeasures.
6.3 Project Control 199

Profile Risk
Potenal Soluons
Probability of occurence

= High
= Medium
= Low

very low low medium high very high

Damage Potenal
Fig. 6.13 Example of a risk profile

We strongly recommend identifying potential risks at the beginning of the project

and assessing them according to their scope and probability of occurrence. It is
advisable to record risks in a risk log. Risks occurring during the project period will
then be systematically recorded and evaluated. The impact of the risk, the probability
of occurrence (if no countermeasures are initiated) and the priority are also
documented.
It is important to highlight the risk situation in project status/steering committee
and stakeholder meetings. Figure 6.13 shows a risk profile with which you can
illustrate the risk situation of your project at a glance.
This representation shows you at a glance your risk situation in the project.
Here is how to fill in the risk profile:

1. You assess the probability of occurrence of the risks you have identified (high/
medium/low).
2. Then you determine the potential for damage that these risks carry and the options
for risk mitigation or avoidance (each ranging from low to high).
3. According to your assessment, you assign the risks in the matrix.

Note: The 7 Most Common Risks in a Project

1. Overly optimistic project timeline
2. The effort involved was underestimated, e.g. the programming scope far
exceeds the original assumptions.
3. The scope of the project is extended by additional, ongoing requirements
(but no adequate adjustments to timeline/budget/resources are made).
4. Project staffing is insufficient or proves unsuitable.

(continued)
200 6 Project Planning, Control and Quality Assurance

5. There are delays in decision-making due to limited access to decision-

makers.
6. The decision-makers are not clearly identified.
7. Project communication is insufficient or ineffective.

Special Factors Influencing a Project

In every project, you are exposed to influencing factors, which you cannot necessar-
ily recognise in the standardised plan/actual comparisons. Below you will find some
suggestions as to what you should pay particular attention to (based on Köhler, Jens–
Kloos, Bernd; Steffan, Peter, in section references).

The Blind Spot

In large and complex projects, there is a danger that risks may be overlooked or
deliberately ignored. Objections raised by outsiders to the project are sometimes
brushed aside (so-called groupthink). This danger can be minimised by forming a
diverse team with people who bring different experiences and qualifications and who
pay attention to each other’s blind spots.

Sub-Projects in the Project Taking on a Life of Their Own

There is a risk that individual teams may get lost in subtasks whose results are
difficult to integrate into the overall project later on. The consequences are time-
consuming rework, resulting delays and, last but not least, atmospheric dissonance in
the project.

Figure 6.14 shows an example of how individual risks can be recorded and
tracked. The template for this can be downloaded.

Risks Categories Impacts Prioritiy Corrective Dates Status

Actions
(e.g. infrastructure,
dates, effort,
staffing, complexity,
decision processes,
communication…) .

- Test system not - Infrastructure - test start delayed -1 - temporary use of open
availabel the development
system
- …

- …

Fig. 6.14 Example of a template for recording and tracking risks

6.3 Project Control 201

Conflicts of Interests
Introducing SAP software will inevitably affect existing processes and organisations
in the company (see Chap. 2, “What Makes an SAP Project So Different”). This can
lead to conflict within the departments, departmental egoisms and competence
wrangling. In these cases, it is a particularly difficult challenge to keep harmful
influences on the project low and prevent roadblocks by regular coordination and
communication with all parties involved.

Boycott, Sabotage, Intrigue

If you are unlucky, you may come across people in your SAP project who turn out to
be boycotters, saboteurs or schemers. Such behaviour can have many different
causes, including the following:

• Unresolved (goal) conflicts

• Dissatisfaction with the (assigned) role in the team
• Shift/change or unclear position of power
• Changes in familiar settings

Dealing with such “time bombs” in a project is one of the biggest challenges of
project management. Your leadership skills are required: creating a fault-tolerant
atmosphere, flat project structures, specific target agreements, foresighted career
planning and regular checks will help you recognise such situations early on and
solve any problems that may arise.

Real-Life Project
You are surely curious now what has become of the SAP project at ACME Corp?
Here is the result:

In the last board meeting, Mr. Blunt presented that everything is going according
to plan, although there are already clear signals from the development team that the
go-live date cannot be kept. These signals and the unorthodox preparation for this
board meeting make Mr. Blunt increasingly doubt that his project can be successful
without competent project management and without clear project structures. He calls
his entire project team together for an open discussion. The result is sobering:
nobody believes that the published deadline can be met. Mr. Blunt decides to eat
humble pie, i.e. to inform the board of directors.
After fierce discussions, he receives approval to call in an external consulting
company for an independent analysis of the project situation. The experts of the
consulting company come to the conclusion that the deadline must be postponed by
6 months, based on the original project scope. With this heavy burden, Mr. Blunt
eats some more humble pie.
The following decisions are made:

• The consulting company receives the project order and provides an experienced
project management.
202 6 Project Planning, Control and Quality Assurance

• The originally agreed content remains unchanged; the additionally requested

extension to auditing is taken out of scope and will be realised in a follow-up
release.
• The go-live date will be postponed by 6 months.

With a lot of “sweat and tears”, they finally manage to meet this revised
introduction date. We do not want to speculate at this point about potential disci-
plinary measures due to the bumpy start (such as transfers, dismissals or even
unexpected promotions). We are simply delighted, along with the company and
the project team, that the successful completion of the project can be celebrated at
the end.

Tip: 10 Tips for Successful Project Control

1. Trust the proven SAP methods (previously ASAP, now SAP Activate).
2. Make your start easier by drawing on existing experience, structures and
tools.
3. Always keep an overview of the status of your project.
4. Establish consistent control processes that extend from the beginning to
the end of the project.
5. Set clear standards (e.g. for communication), and train your project team
accordingly.
6. Proceed in a structured and methodical way.
7. Use reports, key figures, methods and tools sensibly, and do not let them
become an end in themselves.
8. Keep the project risks under control.
9. Develop an eye for extraordinary developments.
10. Create an atmosphere of trust and error tolerance.

6.4 Quality Assurance

The following quotation illustrates the importance of quality assurance in the

project: “Of course quality is expensive, but a lack of quality even more expensive”
(Quadbeck-Seeger, Hans-Jürgen, in section References). The more importance you
attach to the topic of quality from the outset and the better you prepare your quality
assurance processes, the less you have to fix, rework and improve later.

Methodological Approach and Analytical Measures

A first step in the right direction is to define clear constructive measures for your
project. These include methodical procedures, guidelines, standards and checklists.
But that is not enough: you must make sure to familiarise all those involved,
especially your project staff, with these procedures. The so-called analytical
measures are of particular importance. We understand them to mean quality
reviews, process walk-throughs, program inspections, audits and tests.
6.4 Quality Assurance 203

Note: Quality Assurance Systems: Knight in Shining Armour?

On the Internet, you will find numerous offers from management consultancies
for quality assurance systems, reviews, project management quality systems,
health checks and audits. Check out exactly what experience the provider has
before you decide to award a consulting contract!

You can of course undertake lengthy studies to determine which of the offers
could meet your specific needs. However, we think it is more important that you first
find out for yourself about quality assurance measures in your project. In this section,
we would like to give you an overview of the importance of quality assurance
measures, In addition, we’ll provide instructions on how to prepare and conduct
project reviews. You will need to think about the issues and the scope of the reviews
in detail in the context of your particular project. When identifying the critical points
in the respective phases, use common sense.

6.4.1 What Are the Practical Problems?

Quality, quality management and quality assurance are the subject of a flood of
publications and training. Nevertheless, many SAP projects face massive problems
or even fail miserably.
What’s the rub? There is often a lack of awareness that quality assurance begins
with the project kick-off and is not limited to tests or reviews shortly before the start
of production. In most cases, it is cost and scheduling reasons that stand in the way of
consistent quality assurance, even though repair work at an advanced project status
costs many times more.
Among the most common grievances or omissions are the following:

• There is no quality review concept over the entire course of the project.
• Reviews are not anchored in the plans from the outset.
• Your own project staff do not have the qualifications or are too closely involved
themselves to carry out reviews.
• People are reluctant to hire external auditors.
• Any flaws that are discovered are disregarded or not consistently followed-up and
resolved.

Note: Quality Assurance Is an Obligation

With the project order, you enter into an irrevocable obligation towards your
customers, your clients, the specialist functions and your project staff to bring
the project to a successful conclusion, on time, within the budget and with the
agreed quality.
204 6 Project Planning, Control and Quality Assurance

6.4.2 What Does Quality Assurance in Project Work Mean?

By quality assurance (or also quality management), we understand all measures for
risk minimisation in the course of the project to achieve the agreed project goals.
Quality assurance covers all phases of the project. The aim is to detect errors or
deviations from the project objectives at an early stage, so that corrective measures
can be initiated in good time. This includes the following measures:

• Planning, design and architecture reviews in the early phases of the project
• Reviews of the project processes, documentation and the results achieved in each
phase of the project
• Detailed tests in the course of software development

If you are able to present the status of your project at any time and, so to speak, in
your sleep, you have laid an important foundation stone for your success.

6.4.3 Preparation and Execution of Reviews

When you prepare a review, you should first look at all documents that play a role in
the project. These include the following:

• The written project order

• The project organisation (who has what responsibility in the project, and who are
the decision-makers?)
• The risk management plan
• The change requests and decisions within the change control process
• Minutes from previous reviews
• Status protocols and action plans

You then develop checklists for the areas on which you want to focus in the
respective review, e.g.:

• Project methods/techniques/tools
• Project standards (documentation, programming)
• Assignment of tasks
• Process and technology reviews and quality controls
• Progress key figures
• Reporting system
• Communication
• Status meetings
• Dates
• Actual situation of the staffing plan
• Actual situation of the budget plan
• Change control process
6.4 Quality Assurance 205

You also define the group of people you want to interview in the respective
review. In addition to the project management and project staff, these may include
sponsors, stakeholders, members of the steering committee and representatives of
the departments.
Ideally, you set the dates and content for project reviews during the project
planning stage and communicate them to all involved parties. In the case of a
planned review, the reviewer informs all participants, the project managers prepare
summary presentations on the areas in question, and the project staff update the
project results. Reviews are carried out using the checklists in the form of interviews.

Tip: Who Should Do the Reviews?

Whenever possible, independent reviewers should be engaged to carry out the
review. They may come either from within the company or from external
companies with experience in conducting SAP project reviews.

There are different types of reviews, which we would like to bring present here.

Initial Review
The aim of the so-called initial reviews is to identify weaknesses in the project
preparation before the official project start.

• Timing: 4–2 weeks before project start

• Focus on:
– Project goals
– Coordination of the project in the company
– Project contents
– Project organisation
– Project resources
– Infrastructure
– Initial project planning
– Project risks

Periodic Review
The aim of periodic reviews is the independent, regular assessment of the course of
the project and the confirmation of the assessment of the situation from the status
meetings.

• Frequency—depending on the project duration, e.g.:

– Monthly, from 9 months to 4 months before implementation
– Biweekly, from 12 weeks to 2 weeks before implementation
– 1 week before/after implementation
• Focus on:
206 6 Project Planning, Control and Quality Assurance

– Project plan progress review

– Control of project risks
– Costs vs. project budget
– Project dates
– Project team morale
– Processing of project changes

Tip: Examples of Questions in Periodic Reviews

Below is a list of typical questions that you can ask during a periodic review:

• Is this plan finalised?

• Are the project dates planned too optimistically (possibly by planning
“backward from a fixed deadline”)?
• Can the project manager identify the critical milestone activities with
high risk?
• Is there a risk management plan for the critical milestone activities that may
affect project deadlines?
• Are all plan activities assigned to employees?
• How many plan activities are not (yet) assigned to an employee?
• Does the project activity plan list all outputs/results?
• Are all of the planned activities assigned to team members?
• Do the employees have the appropriate expertise to manage the plan
activities?
• If not, what additional training measures are planned?
• Are the planned activities scheduled to last max 40 hours? Which activities
lie above that?
• Have the resources been reconciled in terms of skills and availability?
• Is there a critical path for project activities?
• How is the completion of activities recorded?
• Are all of the dependencies defined?
• Which risks/problem areas can influence the project plan?
• Is an effective requirement process in place?
• What impact do new requirements have on the project objectives?
• Are there regular status checks/meetings?
• Are action plans documented and followed up?
• Are the plans updated in a timely manner?
• Are problems openly communicated or perhaps even suppressed?
• Is there evidence that managers do not “manage”?
• Are there signs of an inefficient project organisation?
• Are project standards established and clearly communicated?
• Is compliance with standards monitored?
• Are there any restrictions on project approvals (e.g. for project phase
changes, on new processes)?
6.4 Quality Assurance 207

Readiness Review
The aim of a readiness review is to check whether all conditions for a successful
implementation are fulfilled (completion of the SAP system with the corresponding
adjustments of partner systems as well as preparation and information of all parties
involved).

• Frequency: 5 months / 3 months / 6 weeks before implementation

• Focus on:
• Overall project status vs. plan/milestones
• Test results
• Change management, including training concept
• Communication concept
• Production preparation

Situation Review
The aim of the situation review is to counteract serious project problems or to seek
the advice of an independent project manager.

• Date: Ad hoc review requested by steering committee/stakeholder/sponsor.

• Focus on: Situation reviews (content corresponds to the periodic reviews)

Post Reviews
The aim of the post review is to check the system, the process quality, the production
management system and the efficiency of the support structures.

• Timing: 2–6 months after production start

• Focus on: Key figures
• Process performance (response times, system availability)
• Potential for improvement
• System and interface performance (measurement criteria, lead time, quality,
process costs and customer satisfaction)
• Process quality, control and safety
• Cost-benefit analysis (review of the business case)

Although project reviews are excellent tools for ensuring project quality, many
projects fail to consistently implement them, for cost and/or time reasons. Even
though it should be clear, repairs performed in advanced project phases cost many
times more.

6.4.4 Treatment of the Review Results

The review results are documented in a final report and reported to the review’s
clients (project management, steering committee, stakeholders, etc.). The following
information should be included in a final review report:
208 6 Project Planning, Control and Quality Assurance

• General information on the project and review (project title, review dates,
participants, etc.)
• An overall rating of the review, with justification
• Presentation of the risks in detail
• Recommendations by priority with proposed solutions
• A recommendation on when the next review should take place

Ultimately, the be-all and end-all of quality assurance is that it is lived consis-
tently from the very beginning of the project. It must become a matter of course to
follow all constructive and analytical measures and not to regard them as an
additional burden.
Table 6.1 gives you an example of an overall rating of a review. In general, all
recommendations are recorded in the standard reporting system, and compliance
with the measures is monitored in status meetings.

Table 6.1 Classification of the project in the review

Classification Diagnosis Measures
A Minor problems, project is under • A plan to solve the problems is in place
control • No special measures on the part of the
project management are required
• The solutions are monitored within the
framework of the status meetings
B Several problems, project is • The problems need management
currently still under control attention
• The project management produces a
monthly status report on the improvement
measures
• The monitoring of the measures is
carried out within the framework of the
status meetings and the periodic reviews
C Major problems (there are first • Correction plans are urgently needed
indications that deadlines/budgets • Management focus is required
cannot be met) • The project management draws up
action plans in coordination with the
steering committee and the project
sponsor and provides a frequent/regular
status report (monthly at the latest)
D Critical problems • The dates and budget are likely to be
untenable
• A high level of management focus is
required
• The project management draws up
action plans in cooperation with the
steering committee and project sponsor
and provides a weekly status report
6.5 Planning, Control and Quality Assurance in SAP S/4HANA Projects 209

Note: Quality Assurance at a Glance

Quality assurance as part of project management has the following objectives:

• Ensure compliance with the project objectives (deadlines/budget/quality).

• Keep the status of the project documented.
• Identify errors and deviations from the project objectives at an early stage.
• Minimise risk.

Plan quality assurance from the outset and choose the appropriate methods:

• Constructive measures:
• Project management methods
• Tools for quality assurance
• Guidelines and standards
• Checklists
• Analytical measures:
• Reviews of planning, design and architecture
• Reviews of project processes, documentation and results
• Detailed tests

6.5 Planning, Control and Quality Assurance

in SAP S/4HANA Projects

In this chapter, we analyse whether the recommendations given so far are still valid,
or which new methods and procedures you should consider in your SAP S/4HANA
project.

6.5.1 What’s New in the IT Project World Today?

Many manufacturer documentations, as well as offers from service providers and

current publications on project management, deal with how IT projects can be
realised faster, more efficiently and with improved quality.
As the person responsible for the project, you will of course consider new aspects,
such as the following:

• New implementation approaches (SAP Activate)

• New tools/introduction models to simplify and accelerate your projects
• New quality assurance approaches
210 6 Project Planning, Control and Quality Assurance

Agile Project Management

One of the main topics is often the use of agile project management methods to
accelerate IT projects.

There is no doubt that the use of agile methods for IT projects has become
increasingly important in recent years. You’ll be hard-pressed to find any
publications on IT projects that do not deal with agile methods or at least some of
their aspects. A casual observer might get the impression that waterfall methods are
“totally out” and only have disadvantages and that at best hybrid methods (as a
combination of agile and waterfall methods) promise success.

Side Note: Agile Versus Classical Methods

Before we go into the procedures in SAP S/4HANA projects, we would like to
showcase some aspects of agile project management methods compared to waterfall
methods, which we consider important.

The classic waterfall method gives the illusion that total costs, deadlines and
project content can be determined with a high degree of accuracy in the first phase of
a project. According to the purist’s teachings, changes to the scope are permitted in
the context of strict requirements management via change requests. As a result,
projects with many unpredictable factors that require flexible adaptations often
struggle with this approach.
Agile methods in turn pursue the concept of realising project goals without
detailed overall planning before the project begins. Smaller delivery objects are
defined, which can be implemented in short periods of time (so-called sprints) and
ideally used immediately.
This begs the question: what then is the importance of project planning in agile
projects? Fixed factors are the budget (also called agile fixed price) as well as the
deadlines, while the project content remains the variable factor. The primary goal is
therefore to adapt the project contents to the given framework (budget and deadline).
Psychologically, this increases the pressure to prioritise those requirements that have
the greatest business value. Process owners or product owners are under much
greater pressure to meet their responsibilities. The responsibility is no longer pri-
marily with the project group. In the ideal case, this results in a close cooperation.
The classic project management triangle (see Sect. 6.2.2, “What is Planned?”)
applies in a limited way, if at all. Some publications even talk about it being turned
upside down, because only the content remains as a variable.

Advantages and Disadvantages of Agile and Waterfall Methods

In theory, waterfall methods are suitable for projects that have very constant
requirements and do not require short-term correction loops. Agile methods, on
the other hand, are better suited for projects with many unpredictable factors that
require flexible adjustments and continuous results. Both waterfall methods and
agile methods have advantages and disadvantages (see Table 6.2).
6.5 Planning, Control and Quality Assurance in SAP S/4HANA Projects 211

Table 6.2 Comparison of agile and waterfall methods

Agile Classic
Advantages
+ Regular delivery of functional and quality- + Precise definition of the project results at the
assured intermediate products at short beginning (based on the specification sheet)
intervals
+ Flexible adjustments for projects with many + Accurate planning of extensive, complex
unpredictable factors projects
+ Greater adaptation to changing customer + Reliable implementation of complex
and market requirements projects, thanks to the well-defined structures
of a phase project
+ Faster time to market + Better control of distributed/virtual teams
and external project partners, based on specific
work packages
Disadvantages
– Decreased predictability of the final project – Unsuitable for projects with many
results, as only short-term periods (sprints) unpredictable factors that require flexible
are precisely planned adjustments
– Almost impossible to estimate total costs – More complex adaptation to changing
hardly at the beginning requirements
– Increased need for ongoing coordination – Planning errors are often only detected in
later phases of the projects, as the planned
sequence from the preparation phase is strictly
adhered to

Hybrid Method with SAP Activate

Since the IT project world is not always black and white, hybrid project management
approaches (a combination of both agile and classic approaches) are becoming more
and more important. The SAP Activate methodology for SAP S/4HANA projects
reflects this development.

6.5.2 Project Management in SAP S/4HANA Projects

In SAP S/4HANA projects, too, the question of which methods you want to work
with arises at the beginning. You can of course carry out detailed studies to find a
suitable method. Not to forget that even then, you will still be required to find or even
train suitable project managers or project staff with these skills.
As in our SAP ERP projects, we have come to the decision to use the tools
provided by SAP. Why abandon a tried, well-documented approach in favour of
something new, not recommended/supported by the manufacturer? That does not
make sense.
212 6 Project Planning, Control and Quality Assurance

Project Management with SAP Solution Manager

The SAP Solution Manager 7.2 provides all the functions you need to manage the
project, from the initial preparation phase to the completion of the project (see
Chap. 9, “Project Support Tools”). We recommend that you consult the SAP
S/4HANA Implementation Roadmap guideline. This is a description of the imple-
mentation method over the complete life cycle of a project, for all three SAP
S/4HANA transition scenarios:

• New implementation
• System conversion
• Landscape transformation (selective data transfer)

It includes, among others, a best-practice project plan, a description of the SAP

Activate phases and tools to manage the project for each phase. Depending on the
project type, agile and waterfall variants are also described there (more details on the
roadmaps can be found in Sect. 3.7.1, “Roadmap Viewer”).
It seems pointless to us to consider whether you follow more the classical paths or
the agile paths with SAP Activate. In our estimation, SAP Activate is a combination
of methodology and technical tools, which, if used consistently, can help to speed up
projects compared to previous methods.
Importantly, SAP Activate provides opportunities to perform activities within
specific phases in agile modes, based on a more traditional framework. SAP Activate
comprises three core competencies:

• SAP Best Practices (preconfigured business processes)

• Guided configuration (guided configurations using SAP Solution Builder to
enable SAP Best Practices)
• Methodology (defined methodology for adapting SAP S/4HANA in phases)

Not to forget a fourth aspect, which has become increasingly popular in recent
years (although it comes with additional cost): the SAP model company. This is a
collection of best practices (available for many industries) which are selected in such
a way that the result is an integrated, largely configured “running” SAP system.

Project Acceleration Through Ready-Made Solutions

This is the perfect segue to SAP Focused Build. With the Focused Solutions, SAP
offers ready-made solutions for specific purposes in the company. These are agile,
tool-supported methods based on SAP Solution Manager.

6.5.3 Special Features of SAP S/4HANA Projects

You will certainly ask yourself what has changed in the abovementioned activities;
what needs to be considered, especially in SAP S/4HANA projects; or which
(hopefully) improved tools are available.
6.5 Planning, Control and Quality Assurance in SAP S/4HANA Projects 213

Planning
No planning without a work breakdown structure
The following still applies: all those aids, tools and guidelines do not automati-
cally deliver the planning. The basis is and remains a work breakdown structure,
which has to be created anew for each project. You need to focus particularly on
planning and estimating the agile activities in the context of SAP Focused Build. In
general, SAP Activate provides for the following plan cycles:

Strategic planning in the discover phase

In this phase, you lay the foundation for your future business strategy and the IT
architecture required for it. The goal must be to develop a complete innovation
strategy for the introduction of new or expanded business areas. SAP Best Practices
can provide valuable support in this process. As a result, you will set the project
processes for the planned business and IT changes on an appropriate timeline,
although still at a high level.

Transition planning in the prepare phase

As a basis for your project plan, you define the project contents and the detailed plan
for implementation in this phase. The explanations on the procedure for creating a
project plan in Sect. 6.2.3, “How Do You Plan a Project?”, still apply. The decision
on the approach and the level of detail cannot be made by new methods or tools. The
agile development objects are derived from the work breakdown structure.

Estimation of Agile Objects

Our comments in Sect. 6.2.4, “How Expensive, How Long, and How Much? The
Effort Estimate”, are applied to the estimation of agile projects as well.
However, this leads to the question how agile development objects can be
estimated. Due to the short cycles, you cannot afford to make time-consuming
calculations.
You may find the following procedure (which requires a lot of experience)
helpful: The individual development objects are compared with each other in
terms of the ratio of effort. The smallest object gets the value 1. Derived from this,
other objects get a multiple of that, up to an upper limit for the most complex objects,
which you set yourself.

Project Control
SAP Solution Manager 7.2
As mentioned at the beginning of this chapter, SAP Solution Manager 7.2
provides all the functions you need to control the project. The Roadmap Viewer
shows you all information about the progress of the project. (However, plan
adjustments are not possible. To do this, use the project management function in
SAP Solution Manager. ) The Roadmap Viewer also offers the possibility of on-the-
job training (by providing so-called knowledge articles).
214 6 Project Planning, Control and Quality Assurance

Quality Assurance
Regarding quality assurance in SAP S/4HANA projects with SAP Activate, you are
not really breaking new ground compared to your previous IT projects, e.g. SAP
ERP projects with ASAP. What is really new is the increased focus on quality gates
in SAP Activate and thus a much stronger formalisation at the end of each project
phase. It is a structured process for checking whether all the requirements for one
project phase have been met before moving on to the next phase.

Technical Quality Manager: Knight in Shining Armour

Of course, this only leads to success if you actually attach the appropriate importance
to these quality gates in your project. SAP recommends to include a technical quality
manager (TQM), who helps the project management to identify and quickly solve
critical situations.
The most important prerequisite is that you have a project quality plan included in
your project plan and ensured sufficient resources to execute the quality gates. In our
opinion, this is an investment that pays off at the end of the day and one that you
should not skimp on.
But, the reality is that cost and schedule (tight deadlines) oftentimes stand in the
way of consistent quality assurance.

Quality Gates
In terms of quality assurance measures, SAP recommends at least four project
reviews at the end of each project phase—before the transition to the next phases
(see Fig. 6.15). You are of course free to decide on the number of such quality gates
in your project. However, we strongly recommend that you comply with these
minimum requirements! In addition, we recommend that in agile sub-projects,
each sprint (e.g. in the Scrum method) is subjected to an appropriate review.

Combination of Quality Gate Reviews and Phase Pre-Reviews

As recommended in SAP Activate, it is also advisable to conduct so-called pre-
reviews at the beginning of a phase. The aim is to prepare the project organisation for
the coming project phase. It is advisable to combine the quality gate reviews with the
phase pre-reviews.

Discover Prepare Explore Realize Deploy Run

Prepare Explore Realize Deploy

Q-Gate Q-Gate Q-Gate Q-Gate

Fig. 6.15 Quality Gates

6.5 Planning, Control and Quality Assurance in SAP S/4HANA Projects 215

6.5.4 Tasks in the Different Project Phases (Checklists)

Unfortunately, we have not yet been able to find detailed questionnaires in SAP
Activate for the respective phase reviews. As a suggestion, we therefore give you
some ideas from our practice below, which you can also find in the download section
of this book.
The following checklists are available with important tasks in the various project
phases: prepare phase (Table 6.3), explore phase (Table 6.4), realisation phase
(Table 6.5) and deploy phase (Table 6.6).

Table 6.3 Questionnaire: prepare phase

Tasks in the prepare phase Done
The transition plan is available, including scope, deadlines, effort estimates and a □
detailed implementation plan
System architecture, interfaces and effects on adjacent applications are defined □
The project team is established □
A project kick-off meeting was held □

Table 6.4 Questionnaire: explore phase

Tasks in the explore phase Done
The detailed business process requirements have been defined, documented and □
approved by the project sponsors and business process owners
The definition of the technical requirements (SAP system architecture) for implementing □
the business process requirements has been completed
Interfaces and extensions have been defined
An initial analysis of possible organisational adjustments was carried out □
Technical development and test platforms are installed and available □

Table 6.5 Questionnaire: realisation phase

Tasks in the realisation phase Done
Programming and configuration (customising) is completed □
Data in the legacy systems have been cleaned up, converted and are ready for migration. □
The maximum accepted number of errors is fixed (always <1%!)
The new process flows for organisations/workplaces are approved by all affected □
specialist functions (formal approval is recommended)
The training material is developed, training plans and teaching methods are defined, a □
pilot training course and a performance test of the training systems has been carried out
The start of production is coordinated with all parties involved: data centres, application □
owners, end-user organisations, stakeholders
The interface programs have been developed and tested □
216 6 Project Planning, Control and Quality Assurance

Table 6.6 Questionnaire: deploy phase

Tasks in the deploy phase Done
All the responsibilities for go-live have been agreed, and the decision-makers are □
identified; the final go-/no-go criteria are defined
The number and selection of test cases before production start are defined □
The production systems have been set up, and the final test with selected test cases was □
successful
All data has been successfully migrated, and the results meet the quality criteria □
The training courses have been completed; all end users have been trained □
Production accesses for end users are set up □
Job profiles and roles are assigned; there are no authorisation conflicts □
The support structure after the productive start is established; a helpdesk is set up and □
operational
The announcement letters based on the internal and external communication strategy are □
prepared accordingly
All releases for production start are available □

Table 6.7 Questionnaire: entry criteria for acceptance test

Entry criteria for acceptance test
(End-to-end test of business processes in SAP S/4HANA, including all upstream and
downstream application systems) Done
The test concept is developed and contains the definition of the test environment, □
interfaces, test procedure, test tools and acceptance criteria Performance and stress tests
are part of the test strategy
Test plan and resources are available □
Test cases: □
• The type and number of planned test cases have been defined in the test matrix
• The specialist functions are integrated for the selection of the test cases
• The business process managers have released the test matrix
A test kick-off with all partners has been carried out □
The integration tests with partner applications, which are a prerequisite for the start of the □
acceptance test, have been successfully completed (there are no critical open errors)
The agreed real-life data for the test are loaded □
The support structure for the test has been established □
Test management and problem management tools are available □
Potential test risks are documented, and action plans are defined for the event of an □
occurrence
Error categories are defined (Our recommendation: 1–4) □

SAP Activate does not provide quality gates for the discover and run phases. In
the last two Tables (6.7 and 6.8), you will find the entry and completion criteria for
the acceptance test.
6.5 Planning, Control and Quality Assurance in SAP S/4HANA Projects 217

Table 6.8 Questionnaire: closure criteria for acceptance test

Exit criteria for acceptance test Done
All planned test cases were successfully completed □
All errors of the critical error categories (following our recommendation, the highest □
categories 1 and 2) are documented, analysed, corrected, tested again and released
An action plan is in place for all outstanding errors in the less critical error categories □
(3 + 4)
Upstream and downstream processes have been approved □

You are of course free to decide how you want to implement your SAP S/4HANA
project. However, our clear recommendation is as follows:
Use the methods, tools and aids recommended by SAP as much as you
possibly can!
Examples from Real-Life SAP S/4HANA
Projects 7

We believe that nothing is as helpful as real-life examples to further your under-

standing of what you have read. In this chapter, we would like to share with you
some of our experiences of project life in SAP S/4HANA projects or projects with
SAP HANA as a platform and with agile sub-projects. We focus on particularly
relevant tasks from the field of project management. To make it easier to understand,
general project information is included for each project. We have also tried, as far as
it seemed reasonable, to stick to a uniform agenda. Nevertheless, we do not explain
all the details of the projects, because such a project report could otherwise quickly
fill a book of its own.

7.1 Preparation of an SAP S/4HANA Implementation Project

This reference does not describe a complete project but the preparation of an
implementation in the prepare project phase (phase 2), in which the tool, in this
case SAP S/4HANA, and the service providers are selected for implementation.

7.1.1 Initial Situation

Every successful company, especially medium-sized ones, sometimes has to make

strategic decisions that help to ensure their future success. Currently, the topic of
digitalisation often plays a role in this. With the generational change in company
management, the switch to digital business processes and thus the increase in speed
and efficiency are often on the agenda alongside other important decisions.
Our example is a medium-sized company with its own production (process
industry), which has been operating very successfully in Germany and globally for
decades. All processes in the company are tested and have been implemented
successfully for years: some exist in integrated IT solutions that have now become
outdated, many are in single workstation applications, and some are even

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 219
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_7
220 7 Examples from Real-Life SAP S/4HANA Projects

paper-based. However, this includes various media breaks as well as parallel and
shadow processes.
However, due to the current situation (many independent process steps, often
manual), the company is also very flexible when it comes to designing and applying
these processes. The strategic renewal of the IT support was started years ago.
However, a digitalisation strategy was not developed yet. With this situation in
mind, initial talks on the implementation of a new ERP system landscape were
started some time ago.
The legacy systems have reached the end of their lives. Maintenance and opera-
tion depend on a small number of colleagues, who in turn are looking forward to
their well-deserved retirement. Clearly, these IT processes, both the technology and
the mapping of (sub)-processes, are not very sustainable. Current requirements can
no longer be realised. The user interface is outdated, and it is challenging to adapt
interfaces. A new solution is needed. The following alternatives are being
considered:

• Continue the selective renewal of the IT landscape, and develop solutions for
special requirements.
• Implement a standard solution which is maintained by the manufacturer and
which already contains most of the required functionalities. Additional
requirements can be realised relatively easily as add-ons.

To this end, strategic questions regarding the basis of the new solution had to be
answered:

• Support of the main process areas with isolated solutions and mostly manual
integration and consolidation of data
• An integrated standard solution for many process areas, enriched with
functionalities from special applications, such as laboratory management systems
or systems for controlling special production areas

In parallel to the discussion about a new ERP solution, the company engages in a
fundamental discussion about existing processes and their optimisation. The results
from this parallel project are directly incorporated into the ERP decision.
The strategic discussions about processes and the future ERP landscape lead to
the conclusion that an integrated solution with additional special applications is the
better solution in the long term. However, the process of selecting the future ERP
tool and the appropriate implementation partner leaves some questions to be
answered:

• Which ERP application is suitable for a relatively small company with currently
approx. 75 active ERP users (functionality, implementation effort, long-term
operating costs, operating models)?
• Which partner is suitable in terms of content, size and approach?
7.1 Preparation of an SAP S/4HANA Implementation Project 221

• Which functionalities should/must be mapped in the ERP system, and which

should rather not be (e.g. for reasons of data security)?
• Which implementation method will be used, and how will the work be divided
between service provider and customer (considering the limited availability of
internal expertise)?
• How will necessary special applications be integrated into the overall solution?

Eventually, a tender containing these questions was prepared, which asked

potential providers to describe the most fitting solutions.

Note: Solutions in the Selection

The tender considered both an SAP S/4HANA solution and a solution based
on Microsoft 365. The differences between a pure ERP solution like SAP
S/4HANA, which is based on one of the most modern database technologies,
and the platform solution Microsoft 365 would be worth a book of its own.
However, this tender shows that SAP S/4HANA has become a very competi-
tive solution for (smaller) medium-sized companies.

7.1.2 Reasons for the Project

Let us quickly outline the reasons for the project. The company has been very
successful in their industry for years, but did not consider processes and IT as their
main focus. Instead, the main focus was on product development, customer loyalty,
optimisation of purchasing and sales for raw materials and products. Digitalisation
was a media buzzword, but not a corporate goal or strategy.
However, with the generation change, the digital world entered the company. In
initial discussions (internally and with external support), the idea creates a platform
for digitalisation in the form of a standardised, company-wide and integrated ERP
system. Parallel to this, all existing processes are reviewed and documented. The
question was: “What did we actually always want to do better?” The documented
processes and the respective “fields of action” are the basis for a modern ERP
implementation. It turns out that there are a large number of implementation partners
who consider medium-sized businesses to be their area of expertise, and this is true
for both SAP S/4HANA and Microsoft 365.

7.1.3 Project Goals

The aim of the ERP project is to create a digital, company-wide platform. However,
it is not about creating a new, digital business model but optimising and reinventing
the current process landscape. The optimisation focuses not only on cost savings but
also on the ability to adapt more quickly to changing customer requirements and
222 7 Examples from Real-Life SAP S/4HANA Projects

CRM Production

CRM MES LIMS

• Customer communication
• Customer data • Manufacturing Execution • Labor
• Production planning (detail) • QA
Distribution

Scope NewERP •
NewERP
Order processing
• Incoming and outgoing invoices Personal
• financial statements, consolidation
• Production planning
• etc. QMl
PIM/PDM
Purchasing Sales Financals Controlling Reporting
EDI

CMS/DMS
Audit-compliant storage of documents with ERP reference
Product data
(incoming and outgoing invoices etc.)

Fig. 7.1 Possible target architecture with SAP S/4HANA as ERP system

saving resources such as time, energy and storage space. Staff reduction is not one of
the primary objectives of the project.
The project goal is a central, integrated ERP system based on SAP S/4HANA, in
which all core processes (purchasing, sales, financial accounting and controlling,
human resources) are available. For production and special processes, such as
laboratory management, specialised systems are envisioned, such as a CRM (cus-
tomer relationship management) system for customer communication, an MES
(manufacturing execution system) for production, a LIMS (laboratory information
management system) for laboratory functionality and a PIM (product information
management) system for product information. All these systems need to be
integrated with the SAP S/4HANA core system. The architecture needs to be defined
during the project. Figure 7.1 shows the first idea (“New ERP” is the target system).
Business requirements as well as “soft” factors, such as system availability or
meeting data protection requirements, will play a role in the selection of architectural
components.

7.1.4 Approach

Typically, customers decide to use the standard approach for S/4HANA projects, the
SAP Activate method. As part of the prepare phase, before the actual project starts,
Activate offers a module for process selection and the definition of the functional
project scope, which was leveraged in this example. The templates shown in
Figs. 7.2 and 7.3 were used for the selection criteria.
7.1 Preparation of an SAP S/4HANA Implementation Project 223

# Category Criteria
1 Operation
1.1 Operation on-premise in private cloud at partner or public cloud.
1.2 Support offer for 24/7 service
1.3 …
2 Technical coverage -- fulfillment of requirements for core functions
2.1 Mastery of the technical background relevant to the project
2.2 Medium-sized group (consolidation finance/aggregate view)
2.3 …
3 Experience with the vendor's industry/products/processes and the software solution
3.1 References: process industry
3.2 Experience of people in process industry
3.3 …
4 System -- overall impression tool, operation and communication
4.1 general impression ("look and feel")
4.2 operating concept
4.3 …
5 Internationality (networking, connection, interfaces)
5.1 Connection to standard systems
5.2 Cross-location networking
5.3 …

Fig. 7.2 Criteria for the selection of suppliers for the SAP S/4HANA tender-1

# Category Criteria
6 Costs and license model
6.1 Total cost of ownership (TCO) over 10 years
6.2 One-time costs: Consulting/services
6.3 …
7 Dependency (collaboration model and framework).
7.1. Physical location of the provider
7.2. Dependency on the supplier
7.3. …
8 Impression provider/presentation
8.1. First impression of the provider and gut feeling
8.2. Presentation: structure, composition, comprehensibility
8.3. …
9 Project approach and methodology
9.1. Project procedure
9.2. Project structure / key positions
9.3. …
10 Proposal
10.1. Quality of the proposal structure and content
10.2. Structure and depth of the proposal content
10.3. …

Fig. 7.3 Criteria for the selection of suppliers for the SAP S/4HANA tender-2

At this point, the selection process was on the home stretch. Out of 12 bidders
who were asked, 10 participated in the tender, and 5 were invited to present
their bids.

7.1.5 Summary

From the initial exchange of ideas to the preparation of the decision, the selection
process, including the prepare phase of the project described above, took about
8 months. The parallel project for the fundamental optimisation of the business
processes proved to be a stroke of luck for the discussion of the task definition and
224 7 Examples from Real-Life SAP S/4HANA Projects

for the selection process. The results of the process discussions could thus be directly
transferred to the provider discussions.
The main person responsible for preparing and implementing the call for
proposals and the selection process is the internal project management. In our
view, it is an advantage if the person responsible for the project in the future is
already involved in the selection of the implementation partner. After all, they will
later be measured by the success of the project and can therefore help determine the
direction from the very beginning.

7.2 Implementation of SAP S/4HANA at ELKB in Bavaria

SAP S/4HANA at ELKB

The Protestant Lutheran Church in Bavaria (ELKB) writes about its self-image on
its website:

Church—that is a multitude of people who are committed. The church sees itself as a body
with many members. Each has its place.

The quotation could also be the motto of an SAP project at ELKB. The Protestant
Church is diverse—and so are the participants in the project, the opinions on
proposed solutions and the results of the specialist workshops held in preparation
for a project. What certainly fascinates the external project staff (or touches them if
they are close to the church) sometimes leads to lengthy discussions and complex
processes to find solutions. In the end, this also has an impact on results and project
duration. But we mention this only in passing at this point. As you will see, the SAP
S/4HANA project at ELKB also had other interesting challenges.

7.2.1 Initial Situation

The Protestant Lutheran Church in Bavaria has been operating an SAP ERP system
landscape in and for its regional church office in Munich since 2010. The SAP ERP
systems are used primarily for financial accounting and controlling as well as SAP
ERP Human Capital Management (SAP ERP HCM), especially payroll accounting.

Note: Regional Church Offices and Church Districts

The Regional Church Office is the central administrative office of the ELKB
and acts as a service provider for the congregations and institutions. A church
district is defined as follows:
A church district is the largest unit in the Bavarian Regional Church in
terms of area; it extends over several deanery districts. The name designates

(continued)
7.2 Implementation of SAP S/4HANA at ELKB in Bavaria 225

an area of jurisdiction; church districts in this sense are no legal entity of their
own. At the head of a church district is a pastor with the official title
“Oberkirchenrätin, Oberkirchenrat im Kirchenkreis”, which roughly
translates to “Senior councillor of the church district.

In 2015, a project was initiated to use this SAP ERP system also in the church
districts of the ELKB. A separate SAP ERP system landscape (a copy of the original
implementation) was set up to support this project.
The decision for a separate system landscape was based on both technical and
organisational decisions. From a technical point of view, the implementation in the
regional church office was a system copy of a previous implementation at another
church institution. Over the years—and the various projects which have been carried
out based on this template—the system has been modified in a number of places.
Since the original implementation happened several years ago and the external
service provider had been changed in the meantime, these modifications could not
be reversed. This in turn meant that it was no longer possible to import current
innovations in the form of SAP Support Packages—or to perform the urgently
needed upgrade.
In addition to the technical reasons for a separate system landscape, there were
organisational reasons: both the IT organisation and the organisation of the specialist
departments in the Regional Church Office and in the church districts are different.
In addition, church districts value their autonomy.
After thorough organisational preparation and implementation based on SAP
ERP, a template for all church districts was developed and tested, and the employees
received comprehensive training.
The first successful productive rollout took place at the end of 2017. Subse-
quently, as part of project planning, the next rollouts for the remaining five districts
were prepared. In the course of this roll-out, two important decisions were made:

• An upgrade to the current SAP S/4HANA system was to be performed before

further rollouts.
• In the course of the upgrade to SAP S/4HANA, both system landscapes (that of
the Regional Church and that for the church districts) were to be reunited.

This decision was made possible because the ELKB had decided to start a project
to set up a common IT organisation for the whole ELKB. This exciting process took
place partly at the same time as the SAP project, and it could fill a book of its own.
We will therefore only occasionally mention the mutual influence of the projects.
226 7 Examples from Real-Life SAP S/4HANA Projects

7.2.2 Reasons for the SAP S/4HANA Project

The starting point and cause for the activities around the SAP systems at the ELKB
was the need for an efficient, affordable administration of the ELKB and its church-
specific structures and processes.
The first phase of the project based on SAP ECC included the functional areas of
financial accounting, controlling, planning, reporting and payroll accounting for the
regional church office. Since the SAP standard solution had to be modified, espe-
cially in payroll accounting, to implement the requirements, the topic of human
resources (HR) in SAP was left out for the second phase in the church districts.
Instead of SAP ERP Human Capital Management (SAP ERP HCM), the KIDICAP
solution from GIP (GIP Gesellschaft für Innovative Personalwirtschaftssysteme
mbH), which is commonly used in church environments in Germany, was chosen.
However, the long-term goal was to implement SAP ERP HCM for church districts
as well.
The start of the SAP S/4HANA consolidation project brought the question of an
integrated HCM solution for the entire ELKB again to the fore. The decision was
made in the period 2018/2019—a period in which SAP presented its HCM
customers with one or two planning challenges. The reason was that SAP’s official
HCM strategy in the context of SAP S/4HANA was to move all HR processes to
SAP SuccessFactors, a cloud solution. In the future, SAP ERP HCM would no
longer be part of SAP S/4HANA. However, SAP SuccessFactors was and still is not
an option for ELKB: the fact that it is only available as a cloud solution but also
functional deficits for public institutions like ELKB ruled this out.
At that time, SAP’s HCM strategy was changing dynamically: from an interim
solution that could only be operated in a separate system landscape to a solution
under SAP HANA, but not integrated with SAP S/4HANA, finally to an SAP
S/4HANA HCM solution. By the time this solution was finally ready to be
implemented, the train had left the station at ELKB: FICO-SAP S/4HANA was
implemented—without HCM. The future HCM solution was evaluated in parallel to
the SAP S/4HANA project and was to be introduced separately. Possible target
solutions were KIDICAP Neo (the successor version of KIDICAP) and SAP ERP
HCM on SAP S/4HANA.

7.2.3 Project Goals

The project objective of Release 1 was simple and yet quite complex: introduce an
easy-to-use SAP S/4HANA solution that meets all the requirements of accounting,
planning and controlling and can be used for all six church districts of ELKB. For
one of the six church districts (Augsburg), this meant migrating from an SAP ECC
solution to SAP S/4HANA. For all other church districts, it meant the step from
cash-based accounting systems to double-entry bookkeeping. In Augsburg, the
support structures and SAP ECC-trained employees were in place. Here, the
7.2 Implementation of SAP S/4HANA at ELKB in Bavaria 227

SAP ECC

08/2020
Naonal Church Office

01/2021

01/2022
ELKB SAP S/4HANA
- Target System- 1 2 3 4 5 6

Administrave
FI/CO

reform for church

Congregaons
SAP ECC

Area Kameral
Non-SAP
Key points: 1 Deanery District Augsburg on S/4 2 Church district Augsburg on S/4
3 Deanery District München on S/4 4 Further Deanery Districts on S/4
5 Naonal Church Office on S/4 6 Enre ELKB on S/4 S/4

Fig. 7.4 Timeline for the SAP S/4HANA project at ELKB

technical challenges were the main focus: complete data migration, design changes
and changes in the organisation’s structure in SAP.
For the five other church districts, the first task was to lay the foundations. These
were created in a separate organisational project prior to the actual SAP S/4HANA
introduction, i.e. the rollout of the church master template. The actual SAP
S/4HANA project here was more of an upgrade project, even though the Greenfield
approach was used as the implementation method.
All other church districts moved from the old, cash-based IT world directly to
SAP S/4HANA. The preliminary project, which was far more complex in terms of
organisation and training—also in terms of project duration—ran parallel to the SAP
S/4HANA implementation. However, the migration effort was limited, since virtu-
ally no transaction data was transferred.
Looking into the future (further rollouts are not yet planned), we expect it will
take several years until the transition to SAP S/4HANA is complete (see Fig. 7.4).
We have already mentioned the diversity of user groups at the beginning. This
ranges from IT experts (some of whom are now SAP experts) to volunteer part-time
staff in community offices. The job of the volunteers is actually not to operate a
complex SAP S/4HANA system (or any other IT system for that matter) but rather to
look after the needs of the church and the members of the congregation. Adminis-
trative tasks tend to get in the way. An intuitive, easy-to-use user interface (UI) is a
basic requirement for this user group to accept the solution. Under SAP S/4HANA, it
would certainly be possible to find SAP Fiori applications, which could meet these
requirements. The SAP ECC application, which was to be replaced, however, was
equipped with a web-based frontend for precisely these reasons. It simplified the
necessary entries and then passed the data to the SAP system in the background. To
reduce training efforts, this solution was retained and adapted to SAP S/4HANA.
The changeover to SAP Fiori was postponed to a later project phase (which, during
the first rollout, increased the acceptance of a further SAP project by the end users).
228 7 Examples from Real-Life SAP S/4HANA Projects

Accounng Budget planning

Pension funds,
religious Regional Church
…
educaon, … Office Release 2

Financial
Budget planning
accounng for Cash desk and
for church
church donaons
congregaons
congregaons

Release 1
Basic sengs FI Basic sengs
(ledger, CO (plan
Essenal client
document version, order
types, payment types, cost
parameters „Base Plate“
methods, ...) center types, ...)

Fig. 7.5 Division of Release 1, Release 2 and “base plate”

The main goal of Release 2 was to integrate the new SAP S/4HANA landscape
with the old SAP ECC implementation in the regional church. For Release 2, some
of the foundations were already laid with Release 1 (internally, this was referred to as
the “baseplate” of the system). This required extensive discussions about the
standardisation of the chart of accounts and SAP organisational elements, such as
the joint use of controlling areas, company codes, etc. Figure 7.5 shows the func-
tional demarcation.
Originally, as already mentioned, the SAP implementation was used as an
integration platform for FICO and HCM in a system landscape. When the SAP
ECC project for the church districts was launched, this integration had already been
removed. The background here was the complexity of the requirements, especially
for the HCM part, which involved various modifications and would have compli-
cated regulated system operation. For this reason, SAP S/4HANA was planned
without HCM right from the start. In parallel, an evaluation for a future strategic
HCM solution was started. Since SAP decided that SAP ERP HCM will remain part
of the SAP S/4HANA solution, a decision in favour of the SAP system would make
sense. However, the decision has not yet been made.

7.2.4 Approach

The implementation method SAP Activate was used as the approach for the SAP
S/4HANA project. The ELKB Activate methodology shown below was used (see
Figs. 7.6 and 7.7).
7.2 Implementation of SAP S/4HANA at ELKB in Bavaria 229

Prepare Explore Realize

SAP Best
Delta design
Pracces Proposed Implementaon Realize soluon
(what is sll
and bpc "church soluon Plan (customizing)
missing?)
master”

Approach Confirm Soluon

Soluon test
(Roadmap) and gaps

Create the Does the

basics of the soluon meet Prepare go-live
Prototyp
soluon the and operaons
(VfKG processes) requirements?

Project start with pre- Idenfy and Create and test

assembled soluon validate gaps the soluon
• Project start • Funconal specificaons • Realisaon documentaon
• Project guide • Technical specificaons • Test documentaon
• Workshop results • Implementaon planning • Migraon documentaon

Fig. 7.6 SAP Activate at the ELKB—phases 1, 2 and 3

Deploy Run

Maintenance and
Support aer
further development
go-live
of the soluon

Go-live incl. data Applicaon Lifecycle

migraon Management

Readiness of
Tesng the Control of the
organizaon and
enre soluon operaon
systems

Protecon and operaon of the implemented soluon

• Go Live planning
• Migraon
• Handover to operaons

Fig. 7.7 SAP Activate at the ELKB—phases 4 and 5

The company Best Practice Consulting (BPC AG) from Münster was selected as
the partner for the implementation. The BPC team are well-connected and well-
known in the church environment. They also implemented recurring church-specific
230 7 Examples from Real-Life SAP S/4HANA Projects

All historical data

Takeover of historical data Aggregated historical data No historical data
(line items)

Data scope All line items No canceled documents

Post clearings downstream as separate

Dealing with balances Post balances 1:1
clearing documents

Technology Data Base-Insert Posting of documents

SAP Data Transformation SAP-integrated

Tool SAP Data Services
Replication Server (SLT) (Cockpit, LSMW etc.)

Fig. 7.8 Transfer of historical data

requirements in a template. Consequently, an SAP S/4HANA Greenfield implemen-

tation based on the BPC church master was chosen for the project.
Since the users of the system in the church districts, deanery districts and parishes
of the ELKB were not primarily concerned with the operation of IT systems or even
SAP applications, special attention was paid to user-friendliness and the training of
staff. The colleagues from the project team of the church and the service provider
BPC included the future users in the project at a very early stage and meticulously
prepared them for their future tasks.
Data migration is a challenge in almost every SAP project. The migration from
SAP ECC to SAP S/4HANA seems straightforward at first, since the SAP tools are
ready for use and data models are known. Against the background of maintaining the
functionality in principle and the limitation to FICO, the task in the ELKB project
seemed to be quite feasible.
Transferring the data from the old SAP ECC system to the SAP S/4HANA
implementation turned out to be a bit trickier than expected (see Fig. 7.8). The
background to this is that the existing SAP ECC implementation was replaced by
SAP S/4HANA and users had to be trained in the municipalities and administrative
institutions of ELKB, which was carried out with great energy and attention to detail.
The acceptance of an SAP solution for the parishes, which was achieved at great
expense, would have been greatly diminished if the colleagues had not found “their”
data in the new system.
As some process areas and, above all, organisational elements in the system have
changed with the new possibilities under SAP S/4HANA, the devil was in the detail,
as is so often the case. Three possible approaches were examined:

• The first option was to use the SAP Landscape Transformation service. This
option was discussed but was discarded due to some limitations at the time of the
project and because of the high costs involved.
7.2 Implementation of SAP S/4HANA at ELKB in Bavaria 231

Table 7.1 Tool selection for data migration

Legacy
System SAP
Migration S/4HANA GSST
DB Workbench Migration (generic
Object insert IDoc BAPI (LSMW) Cockpit interface) Others
CO master X X
data
Set GR57/58
hierarchies
Projects/PSP X X
elements
G/L accounts FS15/16
Business X
partner
SEPA X
mandates
Annexes X X X
TRM master X X
data
(SAP
Treasury and
Risk
Management)
Shops TRM X X
Banks for ZV X Excel?
CO cycles Transport

• The second option was to migrate all receipts. This approach means that migrat-
ing to new organisational structures and the new data model is achieved via
subsequent postings in the system.
• Finally, the third option was to exclude the transfer of historical documents and to
make the data available outside SAP S/4HANA. This option was also discarded
to increase user acceptance and was only kept in mind as an emergency concept.

The choice of option 2 meant tools for data migration had to be chosen. Table 7.1
shows a variety of methods and tools for migrating the data. The data objects shown
are only a selection.

7.2.5 Results

The project “SAP S/4HANA at ELKB” was about to go live for Release 1 in
mid-2020 (planned for 01.08.2020). All activities were quite on schedule, and
nothing stood in the way of a successful start.
232 7 Examples from Real-Life SAP S/4HANA Projects

The three project phases prepare, explore and realise were completed according
to the project method SAP Activate for SAP S/4HANA projects. All necessary
results were obtained, and the quality gates have been passed successfully.
During the preparatory phase, the functionalities already defined in the SAP ERP
project were compared with the new SAP S/4HANA platform and adapted accord-
ingly. Many of the preparatory activities were already done in the BPC church
master. This made it possible to shorten the path from SAP ECC to SAP
S/4HANA without having to forego the innovations of SAP S/4HANA. In
workshops, this comparison was verified and approved by the future users. In
doing so, great care was taken to ensure that the future regional users of Release
2 were also involved.
This joint project with experts from the finance department of the Regional
Church Office and the competence centre for church districts showed how important
it is to bring together internal expertise with highly qualified and well-connected
consultants. But even the best consultant will not be able to implement an accepted
solution without the users’ support.
Even though Release 2 for the Regional Church will not begin before the
complete rollout of Release 1 in the first church district, the new solutions and the
new common approaches found (e.g. the use of electronic incoming invoice
processing under SAP S/4HANA) have strengthened the desire for a rapid Release 2.
At this point, we would like to remind you once again of the importance of
appropriate project management on the customer side. At the beginning of the SAP
S/4HANA project, the position of the responsible manager for the financial account-
ing operation and thus for the project management on the customer side was vacant.
With the new appointment of the manager for financial accounting operation and for
project management in that area, the project immediately gained the necessary
momentum.
Close cooperation between the operations team and the project team was a key
success factor during the design and implementation of the new SAP S/4HANA
solution. The Augsburg church district and the Regional Church Office were
responsible for the “base plate”; the internal IT of the ELKB and the external
consultants were primarily involved in the project team.
Close oversight by the project steering committee was also essential. The steering
committee, consisting primarily of the senior church councils of the departments
involved and the new CIO, was very interested in a smooth, timely and budget-
friendly implementation. It goes without saying that the core competence of the
church management is not the introduction of IT systems. However, interest in the
processes and decisions was very high from the beginning of the project. Close
cooperation and communication between all key stakeholders was crucial.

Here Is an Anecdote Out of the Steering Committee

After the external project manager had presented his status at the very beginning of
the project, using the common formulations used in the SAP/IT environment, which
he found easy to understand, one of the present members of the “High Council” of
the church explained a church issue to him—also easy to understand from his point
7.2 Implementation of SAP S/4HANA at ELKB in Bavaria 233

of view. This clearly showed that the project team had to learn about communication
and to adapt much more to the members of the committee. Even if you speak the
same language, you not necessarily understand each other—and IT experts often like
to use Anglicism and abbreviations. Good preparation and appropriate adjustments
to the audience’s background help—and lo and behold, you find that it is possible to
explain even complex issues in simple terms (which, in a way, is certainly also true
of this book).

Furthermore, necessary decisions in this context also required thorough prepara-

tion. Stakeholder management—even if this term was less common in the church
environment—was particularly important here!
An important part of Release 1 was the definition, coordination, agreement and
finally the realisation of the “base plate”. It included a joint definition of all the
organisational elements and master data, which needed to be valid for both Release
1 (SAP S/4HANA for the church districts) and Release 2 (SAP S/4HANA for the
Regional Church Office).
Why should this be such a significant effort? At this point, we need to make a
small detour and explain a bit more about the already mentioned project to change
the IT support organisation at ELKB:
In accordance with the maxim “everyone has their place”, there was a very
distributed responsibility—also for many IT topics. The Regional Church Office
had, historically grown, two IT departments, which made sense at the time of the first
SAP introduction: one for the SAP area and one for the so-called rest (infrastructure,
network, telephony, etc.). There was a similar structure in the church districts. This
was (and still is) reasonable in view of the distributed responsibility in the church,
but it presents various challenges for a central SAP landscape, which applies to all
areas. Hence, the question came up who would be responsible for the SAP system
for the church districts. In functional terms, there is a competence centre for this—
proven SAP experts. From a technical point of view, it was initially the implemen-
tation project. However, as there were separate SAP ERP instances, this was not a
big problem.
Since both systems were to be united, it quickly became clear that a central
contact person needed to be established. This was, among other things, a starting
point for setting up a central IT organisation (CIO organisation) for ELKB. The aim
was to bundle all IT know-how in one department. Different professional views
remained (also driven by different consulting partners in the Regional Church Office
and church districts). Convincing people of the need for common structures in the
system was and is necessary too.
In the end, two factors proved to be very helpful in this discussion: on the one
hand, the IT know-how was centralised under a strong CIO who was technically up
to date but who could also respond to the needs of the church. This CIO started his
work after the project for the church districts was started in SAP ERP. One of his first
official acts was to bring about the decision to upgrade to SAP S/4HANA and thus to
unify both SAP systems in the future. The buildup of the CIO organisation was
accompanied by the transfer of knowledge from IT to the business departments and
vice versa. This led to a better understanding of the requirements and to a trustful
234 7 Examples from Real-Life SAP S/4HANA Projects

cooperation. However, there were also fears and uncertainties on the CIO side,
which were addressed in discussions about the future joint SAP S/4HANA solution
for church districts and regional church offices. Many joint solutions were
developed.
On the other hand, selecting the right implementation partner was also fundamen-
tal for the past and future success of the project. Here, the colleagues at “BPC AG”
showed not only very good SAP S/4HANA expertise but also broad knowledge of
the church environment and knowledge of the necessary management methods,
which led to the success of the project (perseverance, willingness to compromise,
understanding of the fears and anxieties of the employees and of the church as an
institution). At the same time, they always kept an eye on the success of the project,
the timetable, the budget and the transfer of knowledge, took a stand in the project
committees before representatives of church bodies and discussed the situation in an
understandable way. The colleagues mastered this balancing act very well, and their
expertise and respectful behavior made them a valued partner.

Challenges
What challenges does the SAP S/4HANA project still face at ELKB?

• Further rollouts in the remaining five church districts are still to come. The
functional foundation has largely been laid. Above all, the project faces
organisational challenges.
• A practicable solution is still needed for the topic of human resources—and here
almost importantly, but not only, for payroll accounting.
• The development of Release 2 and the subsequent migration and merging of the
SAP ERP solution of the Regional Church Office with the SAP S/4HANA
implementation (now for the church districts, later for the entire ELKB) must
be tackled.
• Human resource software, which is useful and usable for the entire ELKB, must
be developed and integrated.

7.2.6 Summary and Lessons Learned

The answer to the question of whether SAP and the church fit together is yes, but
there are some special circumstances to be considered!
It is common knowledge that not every SAP user finds the design of the frontend
(whether SAP GUI, WEB GUI or others) particularly user-friendly. You can proba-
bly imagine that users who work on a voluntary basis, part-time or as employees in a
church congregation or similar institutions find this particularly challenging. SAP
logic (regardless of whether SAP ECC or SAP S/4HANA is used) is not always
intuitive. While in other companies or public institutions there is sometimes some
pressure to make do with the new tool, ELKB was more convinced or adapted. Even
if this contradicts the requirement to use the SAP standard as far as possible, it is a
worthwhile project goal to offer users an IT solution that they like to use and that
meets their requirements.
7.3 “Be Liquid”: BITZER’s Agile Way to SAP S/4HANA 235

Competent Consulting Partner

For us who were involved in this project, the ELKB and its surroundings were also
something special—not so much from a professional point of view but rather from a
“spirit” point of view. We have often wondered how a project team from one of the
big well-known system houses would have fared in this church project—probably
not very well. The choice of an implementation partner must be appropriate, not only
from a professional and budgetary point of view but above all in terms of soft skills.
In the case of ELKB, “BPC AG” proved to be a good choice.

Realistic Time Planning

What is feasible always depends on many factors, and one of these is the acceptance
of the solution. Even if project management or consultants consider a timeline
possible, realistic estimates are dependent on the customer and his internal pro-
cesses, especially in the church environment. If the project team takes these
particularities into account and plans accordingly, realistic planning is possible,
and frustration, as well as missed deadlines, can be avoided.

Adequate Budget
Budget planning is a challenge for every SAP project but especially for long-term
projects. Since one or two framework conditions are currently changing in the public
and church environment, a great deal of foresight is required here.

Concentration of Competence
It is important, as in every project, but especially in the church environment, to
generate interest in the necessary changes. If there is interest, competence is built
up—and for external employees, just as in other sectors, it is important that they have
a certain competence in the customer’s processes. In the church environment, it is
helpful to feel committed to the church, because otherwise cooperation will be
difficult and the success of the project will suffer.

7.3 “Be Liquid”: BITZER’s Agile Way to SAP S/4HANA

As an independent specialist for refrigeration and air conditioning technology,

BITZER is active around the world and in all major markets: with products and
services for refrigeration, air conditioning, process cooling and transport, the com-
pany ensures optimum temperature conditions in goods trading, industrial processes
and room air conditioning—always striving for the highest possible energy effi-
ciency and quality.
With sales offices and production facilities, the BITZER group of companies is
represented at 65 locations in 34 countries worldwide. Including trade and service
partners, the BITZER manufacturing, development and sales network cover almost
all countries of the world.
236 7 Examples from Real-Life SAP S/4HANA Projects

The IT department at BITZER is based on the following basic principles:

• IT is always a means to an end, i.e. all IT systems serve to support the business
departments. Their task is to offer the best support possible and advance the
value-added processes of the company with the limited financial resources
available.
• The company consistently pursues a “SAP software-preferred” strategy, which
means that SAP software products are used whenever possible. Third-party
products are only used if SAP has no comparable product in its solution portfolio.
• In line with its strategy of using SAP software as a preferred option, BITZER
always aligns with the current SAP product strategy and frequently implements
new, innovative SAP solutions at an early stage, i.e. shortly after market launch.
Therefore, it is no surprise that BITZER is leveraging the latest SAP solutions to
implement SAP’s vision of the “intelligent enterprise”.

In many companies, IT departments act as service providers to the business.

Software decisions are often made in the business departments, in coordination with
or even driven by the CFO—often with limited involvement of the IT
department. However, IT is subsequently responsible for the introduction or operation
of the software. Budget responsibility lies with the business; therefore, functional and
commercial aspects are at the forefront of software procurement and implementation
projects. The operation and future proofing of the software often plays only a minor
role, if at all. In the worst case, this results in heterogeneous system landscapes that
combine high operating costs with low reliability and stability. The resulting problems
put an additional strain on the relationship between specialist departments and IT.
At BITZER, things are different: the company’s own IT department plays a
formative role in the company. The budget for software purchases is allocated to
the IT department, which promotes cooperative collaboration between IT and
specialist departments. Both aspects, the functional business requirements and the
IT’s operational needs, are considered holistically. In order to ensure that this is a
dialogue at eye level, BITZER-IT has set up a business competence centre for the
specialist areas:
IT experts (who have frequently moved from the business to IT) have in-depth
technical and functional knowledge of the respective business processes and the IT
tools and are therefore able to discuss and develop business processes with the
various departments (purchasing, sales, production, etc.) at expert level. These
employees continuously keep their knowledge up to date so that they can advise
the specialist departments. In turn, the specialist departments appreciate the leading
and supporting function of this competence centre, as they can focus on the what:
“What should the software be able to do?” The IT experts, on the other hand, are
concerned with the how: “How are the business processes mapped in the software,
and how can we ensure stable software operations?”
It has proven to be a good idea not to focus on specific software products or
versions but rather talk about the business requirements that have to be fulfilled by
the software. Medium-sized IT departments tend to be rather informal (in the best
7.3 “Be Liquid”: BITZER’s Agile Way to SAP S/4HANA 237

sense) to develop pragmatic solutions—perhaps not always perfect but promptly

applicable and appropriate for the purpose. In the next review round, incremental
improvements are developed, and over time, this leads to continuously better and
better solutions.
In addition to the requirements of the divisions, the following questions from an
IT perspective are central to software procurement for business critical applications:

• Does the new product fit into the existing IT system landscape without any
problems?
• Can existing (SAP) know-how be used, or is an upskilling necessary to operate
the new software? Is there a need for the IT staff to be formally trained to
operate this?
• How stable/fault-tolerant is the software?
• What support does the manufacturer offer in the event of an unplanned
downtime?
• How future-proof is the software? Is it supported and maintained over a longer
period of time by the manufacturer?

If central IT systems in BITZER’s system network fail, product research and

development, purchasing, sales, warehousing and production are massively affected,
which immediately causes high costs: employees cannot work, materials cannot be
stored or retrieved, complete shifts have to be sent home, and promised delivery
dates cannot be met. Loss of orders and reputation are looming, and customers may
permanently move to the competition. Smooth, reliable operation is therefore the key
to success. To achieve this overriding goal, BITZER occasionally accepts the
proverbial bird in the hand instead of two in the bush.
On the other hand, the topic of IT operations is an area in which the company
specifically aims to reduce the workload of its own IT staff. It goes without saying
that professional operation of the landscape is necessary, but this creates little added
value for the company: system operation has become a commodity, which means
little or no expert qualifications are needed. The highly qualified IT staff should take
care of the further development of the system landscape and innovations to increase
the quality and productivity of the departments. Outsourcing infrastructure operation
is therefore an obvious decision, and as early as 2015, BITZER became one of the
first customers of the SAP HANA Enterprise Cloud and uses the SAP private cloud
service since then.
BITZER made a conscious decision to have the SAP landscape operated by the
software manufacturer. On the one hand, quality aspects play a role, because the
expectation is that the software manufacturer should know best how to operate his
own software. Even if it is “only” system operations, reliable infrastructure operation
is indispensable. This becomes very clear when the landscape suddenly fails. A
professional, trustworthy technical operations organisation, like the SAP HANA
Enterprise Cloud, has “BITZER’s back” in this area. At the same time, it is a means
to intensify the partnership between BITZER and SAP, which is beneficial for both
238 7 Examples from Real-Life SAP S/4HANA Projects

sides. The SAP HANA Enterprise Cloud is in a way BITZER’s ambassador within
the SAP organisation.
Over the years, BITZER has built up an important network with SAP—which
pays off in several respects: on the one hand, this facilitates the flow of information
regarding SAP products and future strategy—on the other hand, BITZER is a valued
early adopter for SAP. The company is a partner who adopts new products at an
early stage, provides valuable feedback and, as a reference customer, helps to
establish these products in the market. Informal interpersonal relationships are also
a factor that should not be underestimated, especially when it comes to assistance,
support and sometimes important information that is not officially available yet.
As a matter of principle, BITZER does not operate any plants at low-wage
locations with low-skilled employees. BITZER’s high-quality products are
manufactured by highly qualified and fairly paid employees. What applies to
BITZER’s products also applies to the company’s own IT: quality is more important
than minimising costs—if consulting support is needed, BITZER commissions SAP
consulting by default. Even though SAP consulting’s daily rates are higher than
those of other consulting companies (although reduced by a quota contract), experi-
ence has shown that SAP’s own consultants have better qualifications than third-
party providers and also closer connections to SAP development and support
experts. This pays off especially with new products, which are frequently introduced
at BITZER at an early stage. When weighing up the quite considerable daily rates
against the cost risk of project delays and other problems, BITZER has decided to
focus on quality and thus minimise risks. As BITZER’s Director of Organisation and
IT, Christian Stenzel, explains:

Changes to our business-critical systems are like open heart surgery. We can't afford to take
any unnecessary risk.

7.3.1 Development of the System Landscape

BITZER has been using SAP software since the start of the new millennium. These
are SAP systems that have grown and developed over the years, with a significant
number of in-house developments covering all major company areas.
The central entry point for employees is the SAP portal, which is used to access
all other SAP applications. The central SAP ERP system is supplemented by SAP
Business Warehouse (SAP BW), SAP Customer Relationship Management (SAP
CRM) and SAP Global Trade Service (SAP GTS). BITZER operates an integrated
landscape with systems for Manufacturing Integration and Intelligence (MII) and
Manufacturing Execution System (MES), engineering systems (CAD) and a central
SAP Hybris web shop. Suppliers and customers are connected electronically, as well
as the automated management of the high-bay warehouse, time recording and access
control. Interfaces are therefore a central and very critical topic at BITZER, which
must be kept in mind with any changes.
7.3 “Be Liquid”: BITZER’s Agile Way to SAP S/4HANA 239

BITZER is what is called an “early adopter” and traditionally very open to

innovations. As early as 2014, the company switched to the SAP HANA Foundation
licence, which was not only forward-looking but also reduced the licence costs. In
the year 2016, the systems based on MaxDB/HP-UX were migrated to the SAP
HANA database, which was still quite new at that time. In 2017, BITZER was one of
the first customers to use SAP S/4HANA Finance, and in the same year, SAP Fiori
was introduced as the default user interface. The leap from SAP ECC EHP 0 to EHP
8 was a comparatively large changeover in 2017, and in 2019, the introduction of
SAP HANA 2.0 followed, and cloud products such as SAP SuccessFactors, SAP
Concur, SAP Sales Cloud, SAP Asset Intelligence Network and SAP Leonardo are
in use. Despite such a large number of changes within a few years, BITZER pays
attention to stability and tries to keep the impact on the end users as low as possible.
For example, it is possible—depending on personal preference—to work with SAP
Fiori or continue to work with the classic SAP GUI.

7.3.2 The 5-Year Plan: SAP S/4HANA

Due to the close cooperation with SAP, the responsible persons at BITZER became
aware early on of the strategic importance of the SAP HANA database for the future
SAP product strategy: the classic SAP Business Suite was not able to make sufficient
use of the new, revolutionary possibilities of the in-memory database technology.
Therefore, SAP decided to develop the SAP Business Suite completely from scratch
for SAP HANA. BITZER quickly realised the implications of this decision: the
development of the SAP S/4HANA Suite based on the HANA in-memory database
meant that this was not a normal upgrade but the introduction of a completely new
ERP software—a complex and very costly undertaking. However, the changeover to
SAP S/4HANA itself was never questioned—so the question never arose whether
S/4HANA would be introduced but only when and how.
As part of a long-term planning process, SAP consultants first worked out which
functionalities would be mapped in SAP S/4HANA and in which areas other SAP
cloud solutions would be used in the future.
The close exchange of information with SAP resulted in the following forward-
looking decisions for BITZER:

1. Adoption of the SAP cloud strategy and other innovative products

BITZER already uses the cloud solutions SAP Concur, SAP Sales Cloud, SAP
SuccessFactors as well as SAP Asset Intelligence Network and SAP Leonardo.

2. Use of hybrid system landscapes

BITZER uses a combination of on-premise and cloud products. This helped

BITZER to successfully overcome the corona crisis, for example, where the number
of home office users rose from 50 to 500 virtually overnight.
240 7 Examples from Real-Life SAP S/4HANA Projects

3. Hyperscaler strategy adoption

SAP relies on strategic partnerships with the three major hyperscalers Google,
Amazon and Microsoft for infrastructure operations, and BITZER is also adopting
this strategy. The system landscape has already been virtualised and will soon be
migrated to a HEC Hyperscaler data centre.
BITZER has deliberately chosen the early adopter role, i.e. suitable new SAP
solutions are introduced shortly after general availability. This often leads to
increased efforts, as some functionalities are not yet available or not fully developed.
It also happens that the SAP product strategy changes, and this leads to additional
expenses for BITZER. Nevertheless, BITZER secures access to the latest SAP
technologies and thus competitive advantages through this strategy. In addition,
BITZER has the ability to influence the SAP product strategy in this way.
For BITZER, the introduction of the SAP Private and Public Cloud solutions are
important prerequisites for the conversion to SAP S/4HANA, which was planned as
a long-term project. Functionalities that will be offered in other cloud solutions in the
future instead of in S/4HANA have already been outsourced from the existing SAP
ERP system as part of a strategic 5-year plan.

7.3.3 Not Your Run-of-the-Mill SAP S/4HANA Implementation

Project

The implementation approach for SAP S/4HANA at BITZER is fundamentally

different from that of many other companies. This becomes clear when you consider
all the things that do not exist:

• There is no SAP S/4HANA implementation project with budget, project manage-

ment and project staff.
• There is no kick-off and no regular steering committee, and there are no
sub-projects.
• There are no waterfall planning, no formal milestones and no official go-live date
for the SAP S/4HANA conversion.

This raises two obvious questions: can this approach work? And what is the reason
for this unusual approach? First of all, it is the realisation that BITZER has “only one
shot” with the SAP S/4HANA implementation. The productive changeover must be
completed in a maximum of 72 hours downtime, and it must be successful. Once the
interfaces are reopened, there is no way to turn back to the old system. If serious
problems arise at this point, this could result in considerable financial damages and, in
the worst case, potentially even threaten BITZER’s existence.
In addition, some of the stumbling blocks on the way to SAP S/4HANA conver-
sion cannot be identified in advance. In the case of a complex, integrated SAP system
landscape with numerous third-party products, it is not possible to estimate in
advance what problems will arise in the course of the project. Therefore, creating a
7.3 “Be Liquid”: BITZER’s Agile Way to SAP S/4HANA 241

reliable project schedule is not possible. Experienced project managers can tell you a
thing or two about it: project milestones develop a life of their own. Once they have
been published, they are set in stone in the minds of everyone involved. If these
milestones, which may have been fixed months ago in complete ignorance of the
problems that will arise in the future, are not met, the project will at least be seen as
“struggling” and be in trouble. Unfortunately, this is true even if these milestones
were only based on assumptions and were not supported by any bottom-up planning.
The pressure is increasing to make up for this “time lag”—with possible negative
effects on quality and reputation.
A better approach is to move ahead steadily, continuously and persistently in
small steps. Checking all areas for risks and adjusting as necessary in the course of
the project, without being exposed to the pressure of a fixed schedule, is indeed the
better approach in this situation. Replacing the core of a complex, business-critical
SAP landscape is “open heart surgery”—and nobody would think of putting time
pressure on heart surgeons.
Through early and long-term planning and preparation of the SAP S/4HANA
conversion, BITZER avoided putting itself under unnecessary pressure. It is
expected to be ready by 2022 at the latest, well before the end of SAP Business
Suite maintenance in 2027.
BITZER pursues an agile implementation methodology, which is internally
referred to as be liquid. Just like water, which is constantly looking for new ways,
this refers to the (exploitation) of opportunities that arise: tackling, trying out, using
existing relationships to obtain support, (finding) new solutions again and again, etc.
In short, frequent small, incremental changes are the means of choice. The risks of a
large-scale project must be avoided—especially since agile business development
would not allow things like a code freeze for several weeks or even months anyway.
Parallel to day-to-day business, the prerequisites for the SAP S/4HANA intro-
duction are gradually being created, and problems are being eliminated. Current
operations and special events (e.g. the IT integration of an acquired company) have
priority; nevertheless, in the background, the work steadily continues to create the
conditions for the SAP S/4HANA introduction.
There are two good reasons for BITZER as a medium-sized company to prepare a
Brownfield migration:

1. Existing developments are business-critical and cannot be abandoned or

redeveloped: “What works today must also work tomorrow”.
2. There are simply not enough resources to be able to operate the existing (old)
system landscape and—in parallel—set up model processes in a new Greenfield
SAP S/4HANA landscape.

The conclusion from these preconditions and considerations is that there is no

alternative to a Brownfield migration.
For several years, BITZER has pursued the strategic goal of preparing its own
system landscape for SAP S/4HANA conversion. A whole slew of measures have
already been started or completed:
242 7 Examples from Real-Life SAP S/4HANA Projects

• The simplification list has been completed. Even though this step has to be
repeated shortly before conversion, most of the work has already been done.
• An automated custom code analysis was performed to remove code that was no
longer needed or used.
• Necessary code adaptations were carried out by an in-house development team. In
this way, the expertise is kept “in-house”.
• Modifications were consistently reduced. The golden rule is always remain in the
SAP standard, even if the solution is not perfect.
• SAP GTS was already removed from the SAP ERP system years ago.
• In the area of HCM, the company has already partially switched to the cloud
version (SAP SuccessFactors) and continues to drive this development forward.

As of summer 2020, BITZER is able to test SAP S/4HANA functionally and

technically in a sandbox. In this informal project (without formal milestones), an
important milestone has been reached!
BITZER operates a highly complex, highly integrated system landscape
consisting of many SAP and non-SAP systems. Therefore, it is not enough to take
care of SAP S/4HANA alone. Dependencies and interfaces to all other connected
systems must also be considered. The complexity of the task can only be mastered by
careful “anticipation” of what could go wrong, in which all affected areas are
screened for possible problems and risks. Changes in one system can have unex-
pected negative effects in a completely different system. These problems often
cannot be identified and eliminated in advance. Therefore, the only way to find a
solution is to test and try in a safe sandbox or test environment until a solution is
found. An example of the importance of this analysis of the entire system network
(consisting of SAP and third-party systems) and the occasionally surprising
“showstoppers” encountered is the connection of the web shop to the ERP system:
currently, the BITZER web shop, the central software for customer orders, is
connected to the central SAP ERP system via a synchronous interface. Thanks to
the “good connection” to SAP development, it became clear that the synchronous
interface currently used for incoming orders will no longer be supported in the
future—instead, a changeover to an asynchronous interface was inevitable. It is
costly to develop and test this adaptation, so it had the potential to throw the SAP
S/4HANA conversion off track in terms of time and budget. Together with SAP, a
solution was developed that keeps the effort and costs within reasonable limits and
solves the problem in a timely manner.
In general, the interfaces are the largest minefield. Especially, the connection of
third-party software, e.g. for the high-bay warehouse systems, is a challenge for the
BITZER team, as SAP can only offer little support for these topics.
In the course of the project, some important insights for BITZER have emerged:

• An important factor that should not be underestimated is the impact of the SAP
S/4HANA conversion on the licensing situation. This topic must be discussed in
detail with SAP license sales at an early stage so that the license costs can be
budgeted and planned. Otherwise, there may be nasty surprises waiting at the end.
7.3 “Be Liquid”: BITZER’s Agile Way to SAP S/4HANA 243

• The SAP HANA Enterprise Cloud is occasionally advertised as a “springboard”

on the way to SAP S/4HANA and other SAP cloud solutions, but one should not
expect too much. Primarily, the SAP HANA Enterprise Cloud provides infra-
structure operation services and not comprehensive SAP innovation consulting
for SAP S/4HANA adoption.
• SAP has highly trained, competent specialists for practically all topics related to
SAP S/4HANA conversion. What is hard to find are architects who are able to
design an overall architecture, which takes the customer-specific SAP on-premise
and cloud solutions as well as third-party software products into account, in other
words, someone who can help customers to plan and implement the conversion of
their system landscape in a comprehensive and strategic way.
• SAP Activate is helpful to a certain extent. However, the devil is often in the
details, and SAP Activate as an implementation method cannot, of course, cover
this level of detail.
• SAP’s support offerings relate almost exclusively to SAP’s own software
products. There is little support for third-party software, but this is no less
important for customers since the entire system network must function—not
just the SAP part.

Conclusion
BITZER is taking its own, unusual approach to the SAP S/4HANA implementation.
But this path has been carefully chosen, is sensible and is characterised by a well-
thought-out approach that increases the chances of success:

• SAP’s role as a strategic partner is a given. BITZER invests a lot in this

partnership but also derives considerable benefits from it. This is particularly
helpful when implementing SAP S/4HANA in a complex, integrated system
landscape.
• The SAP S/4HANA introduction was carefully prepared and implemented over
the long haul. The reliable operation of the business-critical SAP system land-
scape is a top priority for BITZER. This approach minimises risks and avoids
unnecessary time pressure.
• The widespread willingness to find pragmatic solutions in medium-sized
companies, a cooperative collaboration between business departments and IT as
well as continuous, incremental improvements characterise the approach.

For BITZER, it’s all about implementing small improvements today and tomor-
row rather than creating the perfect IT world in the distant future. Christian Stenzel
(BITZER’s Director of Organisation and IT) likes to quote the famous British
economist John Maynard Keynes:

In the long run we are all dead

244 7 Examples from Real-Life SAP S/4HANA Projects

7.4 Project to Replace Global Procurement Systems

(Automotive Industry)

This project reference does not describe an SAP S/4HANA implementation. How-
ever, we would like present the project in this book anyway:

• Since this project can serve as a prime example of a successful implementation of

the SAP Business Suite (powered by SAP HANA)
• Since agile project methods were successfully applied in a very large SAP HANA
project
• Since the company had a project manager who did almost everything right (even
though this book did not yet exist)

Supplier Relationship Management

The SAP Business Suite solution Supplier Relationship Management (SAP SRM)
was selected as the future-proof platform for global purchasing. Even during the
preliminary phase of the project, which had started in the pre-SAP HANA era, the
decision was made to switch to the new, future-oriented platform when SRM on
HANA became available. But many people were worried. After all, this meant using
a new platform, which had not yet been extensively tested and established in the
company, for a mission-critical project.

7.4.1 Initial Situation

Every IT system has its time. In-house developments are an excellent match for the
requirements at the time of their introduction. However, they are often relatively
inflexible when it comes to keeping up with major process or organisational
changes—and even a complex redesign of such an in-house development is often
lengthy and costly and tends not to be sustainable and secure. This is where standard
software has its day. It often does not fit “like a glove”, but it does fit longer, and it is
also more flexible in the long term and thus usually the better solution. And even if,
just as with in-house developments, the technology of standard software is also
evolving, the joint innovative strength of customers, software manufacturers and
consultants forms a good basis for long-term investments and investment security.
And this is exactly where the story of this project began (with a very similar
beginning as the example of the prepare project phase in Sect. 7.1, “Preparing an
SAP S/4HANA Implementation Project”). The legacy systems had reached the end
of their useful lives; current requirements could no longer be mapped. The user
interface was outdated, and interfaces to suppliers could not be mapped adequately.
A new solution was needed! The following two alternatives were evaluated:

• Develop a custom-built solution that optimally reflects the current requirements.

• Rely on a standard solution which is supported and continuously maintained/
developed further by the manufacturer, which covers all basic functionalities and
7.4 Project to Replace Global Procurement Systems (Automotive Industry) 245

in which special requirements can be realised relatively easily through in-house

development or as third-party add-ons.

The decision was made in favour of a standard solution based on SAP SRM:
firstly because SAP was already successfully used in the company as one of several
standard solutions and secondly because SAP itself wanted to further develop its
product with this project, which meant that the company could be sure of receiving
the appropriate attention and support as an early adopter. For strategic reasons, the
company did not want to implement a solution that was already in use in other
automotive companies. In addition to exploiting the advantages of standard soft-
ware, it is important to defend one’s own ideas and gain competitive advantages
against competitors.

7.4.2 Reasons for the Project

The functional reasons for the project have already been explained. At this point, we
would like to come to the “soft” facts that made this project possible and eventually
successful. We already talked about necessary activities before the actual project
start. Currently, there is a separate phase for this in the SAP Activate implementation
method. The project described here was started when SAP Activate did not even
exist as an implementation approach. The activities described in it, however, did of
course already exist: to turn a technical requirement into a project, to find a team to
take charge of the preparation of the project and above all to find a project manager
who really drives the project, puts together a team and “sells” the project internally.

7.4.3 Project Goals

The fact that large industrial companies are now very closely linked with suppliers is
well-known. In the automotive industry, we are talking about hundreds of thousands
of individual parts and assemblies, some of which are delivered directly to the
assembly line. The suppliers are critical to the company and so are the associated
systems. To make matters worse, the assembly lines are distributed all over the
world. In addition to global suppliers for specific assemblies, there are also local
suppliers for locally different or only locally available products.
Of course, a global corporation also needs materials that are not specific to
production—these include office supplies, such as pencils and ballpoint pens, but
also materials for the plants worldwide (e.g. for maintenance) or for the development
of new products and the construction of new plants. There is a wide range of
requirements for a “purchasing solution” that should ultimately work for all
materials—anywhere in the world, 24/7, 365 days a year.
The following objectives were set at the beginning of the project:

• Standardise and streamline purchasing processes.

• Use SAP standard functionality wherever possible.
246 7 Examples from Real-Life SAP S/4HANA Projects

• Replace the legacy systems with an integrated platform based on standard

software for the entire purchasing department.
• If possible, develop a shared service centre (SSC) for the purchasing department.
• Create a system landscape which meets the company’s IT standards.
• Shut down the legacy applications once the new solution is introduced, and
redesign the plant interfaces (implement the connection using standard SAP
means, remove legacy solutions).
• Keep the existing portal solution as a user entry point for the buyers, and reduce
the different document types to the necessary minimum.
• During the course of the project, build know-how in the area of maintenance and
operation of the new solution to be ready for operations when the project is
completed.
• Ensure adequate support by the relevant departments for each phase of the
project.
• The results of all phases should be approved by and rolled out to all departments.
This means that the specialist departments should accompany and release the
results of the SAP solution based on the prototypes. This ensures that gaps in the
SAP solution are identified at an early stage and that solution measures were
tackled right away.
• The SAP solution room (SAP SRM) was to be equipped with a functional,
ergonomic and fast SAP Web GUI.
• The project was intended to bring about a far-reaching harmonisation of
processes.
• The processes of the German plants should be rolled out to the international
plants.
• The introduction of the new system should not lead to a deterioration in
performance.
• The success of the project should be assessed based on the following criteria:
– The introduction should take place without loss of vehicles.
– The introduction should take place without additional expenditure (measur-
able in additional working time in person days due to introduction problems).
– The number of incidents (in the purchasing system) after the end of
stabilisation should be below the level of the previous solution (measurable
in the number of support tickets per category).
– The new software should be more efficient to use than the old software
(processes to be implemented should be faster in the new software than in
the old system). Furthermore, the usability should be better than in the old
system.
– The costs for operation and technical maintenance should not exceed the costs
of the old solution. At the beginning of this project example, as well as
throughout the book, we have already emphasised the importance of project
management for the success of the project. At this point at the latest, it becomes
clear that the project manager and his team faced an enormous challenge.
7.4 Project to Replace Global Procurement Systems (Automotive Industry) 247

We cannot go into all facets and all areas of the project here, because it would go
beyond the scope of this book. But one thing we can say is that the project described
here has met or exceeded the requirements for all the above criteria.

7.4.4 Approach

For large transformation projects in large companies, the approach to project initia-
tion, project planning and implementation is probably always roughly the same.
Since the project “Replacement of the Old Systems in Purchasing” probably does not
deviate far from the standard here and as we were involved as external consultants,
we do not go into further details here. We also do not want to and cannot cover the
entire life cycle of the project. However, we will discuss some specific approaches in
some subareas that are important for project management and that were fundamental
for the success of the project. These issues are as follows:

• Project organisation in a multifunctional environment with various external

consultants from different companies as well as the integration of the indirectly
(technically via interfaces) affected parts of the company
• Agile development/customising of the solution with the involvement of SAP
resources
• Test approach
• Transition to production with an adapted, phased plan and ensuring functionality
across different releases

As is common in large transformation projects, the customer looks for at least one
partner for the implementation. The reasons for this are mentioned repeatedly in this
book. In this case, one partner was not sufficient for this project. Thus, in line with
the decision to choose the solution SAP SRM powered by SAP HANA, it was clear
that SAP itself should take on a responsible role in the project. Since the implemen-
tation on the new SAP HANA technology platform required the adaptation of some
standard SRM programs to support necessary additional developments, SAP became
the partner who was responsible for software development. Another important role is
played by the partners responsible for the development and operation of the legacy
systems. As a further important component for the implementation and success of
the project, an additional partner was responsible for test management and support
during the introduction of the new solution.
Overall responsibility for the project lay with an internal team of experts from the
automotive company. The project management team consisted of project
professionals—i.e. internal consultants—and experienced colleagues from the pur-
chasing department. In this way, achieving the goal of a secure, long-term usable
solution that was accepted by the users was ensured.
The selection of the internal consultants and above all the project manager was
certainly one of the greatest challenges and in retrospect a stroke of luck. The
mixture of excellent technical expertise and a capable project manager, including
248 7 Examples from Real-Life SAP S/4HANA Projects

PMO, just fit the bill. We are talking about a project with more than five external
companies involved—all committed to the success of the project but also keen to
make the project an economic success for their company. On top of this came the
usual time and budget pressure.
Already during the planning of the different releases, it became obvious that a
successive development and introduction of the functionalities did not work. “Line
of sight operation” was the motto in the project, i.e. to interlock design, development
and testing of the functionality up to the go-live, prioritise it according to importance
and then use it step by step. This sounds like an agile project approach, which it
was—and it only worked because the sub-projects acted in close coordination but
independently and the corresponding results went live and were tested.
A big challenge was the testing of the different releases. Testing was offered and
initially performed by a team on site. The team carried out the tests in close
coordination with the development and specialist teams and reported the test results
back to the development teams in a very timely manner. HP ALM (now Micro Focus
ALM) served as a tool for planning the tests. The tests were performed and
documented in SAP Solution Manager.
This approach was successful in the end but very time- and resource-intensive.
Furthermore, the test team was not set up for an agile approach at the beginning.
During the project, a prototype for an automated test procedure was developed and
tested. Tosca from Tricentis was used as a test tool. We will talk about the results
later.
For “line-of-sight operation” or, in current IT jargon, agile project management
and the agile introduction of a complex, business-critical IT—in this case an SAP
solution—to work, it requires good planning, the right experts, the right methodol-
ogy, comprehensive testing and constant coordination between the project and the
business departments. It is obvious, that this cannot be handled by one person
(i.e. the project manager) alone.
A functioning, distributed project organisation has proven to be one of the most
important success factors. What does that mean? It means that everyone in the
project must take responsibility. Each sub-project on its own must keep its results
in view and continuously coordinate with all adjacent sub-projects. This is about a
central, global solution for purchasing worldwide. Everything depends on every-
thing else, so to speak. Going live in a monthly cycle (as opposed to a maximum of
two releases per year in conventional waterfall projects) leads to additional work
during testing and the transition to production. For a “conventional” SAP project
manager who does not dream of going live before an extensive multistage test phase
of at least 4 weeks, this would be a nightmare.
In the following, we will discuss some of the more detailed results of the project.
We have already revealed that the project overall was a success.
7.4 Project to Replace Global Procurement Systems (Automotive Industry) 249

7.4.5 Results

We have already described the important role the test team plays in agile SAP
projects. At this point, you will learn a little more about the approach, the necessary
skills, the integration with other sub-projects and the advantages and limits of test
automation in complex projects.
It is clear that increasing the number of cycles in the project—i.e. the changeover
to several releases in quick succession—means that the effort for testing also
increases. Alternatively, simply trusting that the solution works (“we test less, then
the effort does not increase with more releases”) is not a prudent approach.
An important point in testing is the selection of the “right” test cases. Every
critical process must be tested comprehensively; nice-to-have functionality must also
work correctly but may not be tested in every cycle. The prioritisation of test cases is
particularly important.
Another point that is self-evident, but which is becoming increasingly important
in light of the rapid succession of releases is the close cooperation between
developers, testers and specialist sub-projects. If testers who find an error see
themselves as the first problem-solvers, errors can be corrected more quickly, and
subsequent errors can be avoided. There is a learning curve for this in every project.
However, if the test sub-project does not test in test phases but actually becomes part
of the development process and builds up the corresponding skills, the time required
to introduce a release can be shortened and the quality increased.
Another important task is to provide meaningful test data. Attention to detail is
key here. A process may run smoothly using artificially generated data, but with
external “real” data, that is perhaps not the case. The challenge increases when
upstream or downstream systems are involved in the test case, i.e. results from
upstream systems have to be processed, or the results of a process need to be
successfully processed in the downstream system as well. This is where the topic
of communication takes on a special significance. What happens if a critical test case
cannot be processed because the data from the legacy system is missing and the
colleagues who look after the legacy system have to focus on important tasks for the
productive support of the previous system and do not even know that a critical test is
currently taking place? Seen from a distance, this might be a topic for project
organisation, but sometimes it is not predictable due to the complexity. It is good
if the testers concerned do not take a wait-and-see approach but instead work
proactively to solve the problem.
To speed up and simplify test cycles, using test automation tools appears to be a
good course of action. In the course of digitalisation, terms such as continuous
testing, DevOps or predictive testing and many more have become standard in IT
projects. In our project example, the opportunity arose to leverage test automation as
a prototype in an agile implementation method. The aim was to automate the
repetitive tests of basic functionalities before the introduction of a new release—
i.e. to perform a regression test.
The Tricentis Tosca test platform was selected for this: on the one hand, because
corresponding licences were available in the company, and on the other hand,
250 7 Examples from Real-Life SAP S/4HANA Projects

Extracted interface model Generate data

Technical Business-
Informaon informaon

Automaon
System Test cases
model

Automated user interfaces Generate test cases

Fig. 7.9 Model-based testing: the idea

because Tricentis was the external project partner in charge of test management. A
additional advantage of the platform is the possibility to automate test cases without
having to bring extensive programming knowledge into the project. The
corresponding keyword for Tricentis is model-based test management. The test
cases are generated directly from the system being tested without having to write
scripts for them. The idea behind this approach is shown in Fig. 7.9.
The aim of the prototypes in the project was to clarify whether test automation is
promising for testing functions (i.e. process sections) that are already finished and
partly already in productive use during the agile development of further functions.
This is based on the assumption that the clear separation or segregation of functions,
i.e. of function modules or other technical function groups, is not always possible
(actually, it turned out that this is not possible in most cases).
For this reason, testing at short intervals (e.g. before transporting development
objects from the development system to the test system) is useful. For the different
methods, see also Fig. 7.10.
The results of the prototype were mixed. It was possible to prove its usefulness,
and various errors were found in the automated test, which the test experts later
found in manual tests as well. However, the software just as often found false
positives. The reason was partly errors, due to the test setup, i.e. errors generated
by the test automation itself. But there were also errors that were found by the
automated test scripts that obviously weren’t. Here the parameterisation proved to be
the source of error, or the automatic generation of test data was faulty.
In the end, manual testing has (still) prevailed in this project. The mostly positive
results have convinced the project participants that there is a potential for a mean-
ingful use of test automation. However, the approach of automated testing must be
anchored in the project from the very beginning.
7.5 Lessons Learned from Our SAP ECC Projects 251

Continuous Testing (CT)

Waterfall Agile

Dev Testing Ops

Ops

Faster Releases

… …
INT UAT GO
LIVE

Time-to-market
Time-to-market

Fig. 7.10 Differences in test philosophy between waterfall and agile projects

We have presented some important aspects of project management and agile SAP
projects. Of course, such a complex project offers many other interesting topics, but
we want to conclude this real-life chapter with some lessons learned, i.e. experiences
from the projects described here and many other projects from which you can
perhaps draw one or two helpful lessons for your project.

7.5 Lessons Learned from Our SAP ECC Projects

In the first edition of this book (Successful SAP Projects, Rheinwerk Verlag, Bonn
2016), we reported in great detail on the introduction of an SAP ECC system at an
international corporation with a pilot installation and subesquent, world-wide roll-
out. The phases for this pilot installation followed the well-known ASAP implemen-
tation method. Our experience from this form of implementation is still valid for
current and future projects. For this reason, we have briefly summarised the most
important suggestions and advice in this section, especially the lessons learned in the
pilot country and the global rollout concept.

7.5.1 Global SAP Implementation from the Perspective of a Pilot

Country

In this section, we will first introduce you to the initial situation and the example
company. The summary of lessons learned from the practical implementation
follows the ASAP roadmap (which has meanwhile been replaced by the Activate
methodology).
252 7 Examples from Real-Life SAP S/4HANA Projects

The Example Enterprise

In our example, a globally operating corporation in the service industry, the decision
was made to use SAP standard software. The decision was driven primarily by the
new global CIO, Mr. Smith, who reviewed the entire IT infrastructure in the group.
With the introduction of globally consistent, harmonised processes and uniform data
standards, the group’s head office expects a number of economic benefits. These
include greater transparency through improved information management, shorter
delivery times, lower administrative and IT costs as well as higher customer satis-
faction and thus the opportunity for further sales growth and a larger market share.
Mr. Smith knows that the success rate of global ERP projects is lower than that of
traditional ERP projects. In most cases, the blame is not to be placed on the
technology. Reasons for failure are, for example, more likely to be cultural
differences and different mentalities, different time zones or the challenges of
managing virtual project teams.

An international development team, supported by process experts from various

national subsidiaries, described the global processes and worldwide data standards
and developed the global SAP template approved by global and regional
stakeholders.
The next step was to test the global template in a pilot installation before taking
the next steps towards further rollout. To minimise the risk of the initial implemen-
tation, a business unit within the group was selected for this pilot installation.
Figure 7.11 shows the iterative approach that was to be followed for the template

Global Implementaon Program/

Template Rollout
Global
Processes/Standardizaon
/Harmonizaon

Global Template /
Development

Pilot

Lessons Learned

Lessons Learned
Country Rollouts

Fig. 7.11 Template rollout (Source: SAP)

7.5 Lessons Learned from Our SAP ECC Projects 253

rollout. After the pilot installation and after each implementation in another country,
the experience and findings are to be documented and fed back to the global template
team for further optimisation and efficiency enhancement.
The global template answered the following questions:

• Which processes are covered by the new SAP system? In this context, the process
model, global data standards, predefined business scenarios, data migration
procedures and developments are defined.
• What should the global application system architecture be like? Interfaces,
customising, in-house developments and add-ons are described here.
• What will the technical system architecture, including authorisation concept as
well as change and transport concept, look like?
• What measures are planned regarding the training of project staff and end users?
• How should the new system be documented?
• Which implementation method is used? This includes project guidelines,
standards, procedures, templates, etc.

The advantages of a template rollout are obvious:

• The implementation will be more efficient and less risky.

• Laying the basis for future requirements and maintains adaptability.
• The system is flexible in case of organisational changes (e.g. mergers or
acquisitions).
• The experience and knowledge gained from the implementations can be used by
other countries.
• Standardisation offers increased process transparency.
• The group’s reporting system can be considerably improved by consistent data.
• The maintenance effort is considerably reduced by standardising the IT
infrastructure.

The next step was to select a pilot country for implementation. The selection of a
suitable pilot country is particularly important and critical, as the initial implementa-
tion must be a success for the implementation of the global template. The experiences
from the pilot implementation will be gathered and will be made available to the
successor countries as a guideline for further rollouts. It was specified by the global
decision-makers that it should preferably be a European country with a representative
coverage of the different types of revenue within the selected business area. Several
countries had applied for the pilot installation, including Germany. A major motivation
for the countries to apply was to be able to have a greater influence on the further
development of the global template by being selected as a pilot country, an assumption
which, in hindsight, was at least partially fulfilled.
The following sections describe the experiences with the SAP project from the
perspective of the pilot country. The focus is on the time starting with the decision
for the pilot country to the productive implementation and the later rollout in other
countries.
254 7 Examples from Real-Life SAP S/4HANA Projects

Selection of the Pilot Country

In order to decide which country should take the first step towards SAP software, a
meeting with international decision-makers was scheduled. The meeting with the
German team was attended by CIO Mr. Smith, the globally responsible business unit
manager; the local IT manager for Germany, Mr. Miller; the local process manager,
Mr. Pingel; and a representative of the local management, Mrs. Rosenbusch. The
aim of the meeting is to answer the following questions:

• What are the country’s most important business processes?

• Which software solutions are currently used to support these processes?
• How is the local system architecture structured, and which interfaces are in use?
• What expertise and project experience are available in the local project? To what
extent are they at the project’s disposal?

The workshop was scheduled for 2 days. Afterwards, all country teams saw an
opportunity to be considered for the pilot selection. The eagerly awaited decision
was communicated to the teams after 2 weeks. Germany was awarded the contract
for the pilot installation for the following main reasons:

• There is a good match between the globally defined processes and the ongoing
business processes. The selected business segment is representative of the busi-
ness within the group.
• The replacement of the existing IT infrastructure landscape (legacy systems) with
the new global SAP architecture promises considerable savings potential in IT
costs.
• The country team already has experience with large projects of comparable size.
• The management, especially Mrs. Rosenbusch, is committed to the project and
promises to provide the necessary resources.
• Comparatively easy access to SAP experts in Walldorf is seen as another addi-
tional advantage.

The implementation method is based on the phases of SAP’s Global ASAP Local
Rollout Roadmap. In this roadmap, key global activities are defined and
implemented at company level. The activities described in the roadmap are the
guidelines for the pilot installation and subsequent rollouts.
Figure 7.12 shows the different phases of the Global ASAP Local Roadmap. The
company-wide business requirements, based on the corporate strategy, are defined
with specialists from different countries, including process experts from the pilot
country Germany. The corporate and organisational structures and uniform data
standards are defined. The global template is developed on this basis. The figure
shows the individual phases and the starting point of the pilot country.
We have had good experience of project organisation, covering both global and
local levels, with a global SAP development and implementation team and a local
pilot team. Table 7.2 shows the respective tasks and responsibilities.
7.5 Lessons Learned from Our SAP ECC Projects 255

Global ASAP Roadmap-Phases

Template
Global Globale Global Pilot-
Rollout,
Project- Business Realizat Preparat
Support/
Preparaon Blueprint ion ion
Mainten.

Iniaon and Development of Adaptaon of the

Planning of the the global template for
overall program template further Rollout

We start here !
Definion of the
business Pilot-
requirements for Implementaon
the company

Fig. 7.12 Global ASAP Roadmap (based on SAP Global ASAP Implementation Methodology)

Table 7.2 Tasks and responsibilities of the global development and implementation team and
local pilot team
Global development and implementation
team Local pilot team
• Develop and implement a global template • Provision process resources for the global
based on global, standardised processes and development team
worldwide data standards • Ensure all local processes and legal
requirements for the pilot country are covered
• Manage the worldwide system architecture • Manage local and regional system architecture
components components
• Responsible for worldwide system • Responsible for local and regional interfaces
interfaces
• Develop and implement the data migration • Identify data sources from legacy systems
strategy • Support the data migration strategy with
resources for data cleansing activities
• Support the pilot country in change Perform local change management tasks:
management tasks • Communication strategy
• Prepare the training material • Training logistics
• Global stakeholder management • Local stakeholder management
• Responsible for the overall plan • Responsible for local plans (local project
(worldwide project office/PMO) office), close cooperation with the worldwide
project office
256 7 Examples from Real-Life SAP S/4HANA Projects

Global Project-Organisaon for Pilot

implementaon

Global System Architecture

Management Dependencies
Global Global Processes/IT
Development- Global Test/Data
Steering Team Global Management
Commiee/ PMO/Quality Assurance/Integraon
Project-
Sponsor/Project
-Execuve Mgmt. Global Regions
Rollout-Team/ Info Europe/Asia/
Pilot-Country North America etc.
Pilot-Implementaon
Local-/Regional System Architecture
Local Process/IT
Local Test-Support/ Data Migraon
Local Change Mgmt
Local PMO

Fig. 7.13 Worldwide project organisation for pilot installation

The respective IT and process managers of the national companies are integrated
into the worldwide pilot management system from the very beginning, i.e. they are
regularly updated with the latest status information. This is intended to ensure that
they were continuously informed about the project status in the pilot country. At the
same time, it is also a good preparation for the rollouts planned after the pilot
implementation.

Figure 7.13 shows the worldwide project organisation for the pilot installation.
The overall responsibility for the project has the project sponsor who appoints a
project executive. The global development and implementation team and the global
rollout organisation in turn report to this person. The pilot country is involved in the
global rollout organisation. The representatives of the country organisations are part
of the organisation and are kept informed about the progress of the project.
Figure 7.14 shows the project organisation in the pilot country. The local respon-
sibility lies with the local sponsor (management level) respectively with the technical
sponsors for processes and IT. The global development team is integrated into the
management system of the pilot country in an advisory capacity.
The pilot team has a dual reporting path: on the one hand, to the global level of the
organisation which leads the global rollout team and on the other hand, to the heads
of processes and IT at the local level. The target achievement discussions for the
7.5 Lessons Learned from Our SAP ECC Projects 257

Project-Organisaon Pilot Country

Execuve-Sponsor
Pilot Country

Professional Management
Sponsors/ Pilot-Ctry Global Rollout-
- Process / IT Team
Global
Development Pilot-Team
Team

Change Local
Process Data
Mgmt IT/Test

Project-
Office

Fig. 7.14 Project organisation in the pilot country

employees in the pilot country take place at local level with coordination of the
international organisation. After initial doubts about the practicability of the
described matrix management system, no significant problems were encountered
during the project.
The pilot implementation phases generally follow the ASAP implementation
methodology, with local project preparation, local blueprint phase, realisation of
local adaptations, production preparation and finally go-live and support.

7.5.2 Lessons Learned: The Local Project Preparation

What were the main lessons learned in the local project preparation phase?

1. Senior management support

Strong senior management support, especially in the initial phase of the project, is
extremely important. Assigning suitable local staff for the project, provisioning
office space and infrastructure was quickly completed. Searching for a suitable
project management team was also completed in time for the project, albeit with a
few challenges along the way. Similarly, integrating additional resources from
258 7 Examples from Real-Life SAP S/4HANA Projects

countries that are planned for a later rollout also proved to be a successful move. In
this way, knowledge transfer was ensured at an early stage.
2. Realistic time scheduling

It is advisable to inject a healthy dose of realism in the project planning. Avoid an

introduction date which is too optimistic and without further detailed planning
towards a target date. When project objectives are not clearly described at the
beginning, important dependencies for the project (in scope/out of scope) are
overlooked. The feasibility of introduction dates must be checked before they are
communicated, based on sufficient detailed knowledge and bottom-up planning.
Careful planning is the foundation for the success of the project!

3. Stakeholder analysis

A careful stakeholder analysis in the initial phase helps to understand the interests
of those involved in the project, to agree on communication needs and to align
communication plans accordingly. It also helps you to involve the specialist
functions that you need to support your project at an early stage.
In the next phase, the global processes which are valid for all countries will be
defined.

7.5.3 Lessons Learned: Local Business Blueprint

The global process design template is the cornerstone for common worldwide
processes and for future requirements. The decision to deploy a cross-national
international process team already in the development phase has proven successful.
On the basis of the global template, tasks such as the planning of the training
strategy, infrastructure requirements, system architecture and interfaces as well as
change management tasks can be handled in the project preparation phase.
In the blueprint phase, the pilot team focuses mainly on local process
requirements. The most important findings in the blueprint phase are as follows:

1. Approval of the global template

The global template, as developed by the team, is accepted by all stakeholders as

the basis for the SAP implementation.

2. Careful requirements management

Careful requirements management helps to keep local process-related

requirements within manageable limits. To support this process, two new roles are
defined: the integration team for process analysis and the SAP architect role. Equally
important and supportive are the weekly process design reviews with the global
development and implementation team.
7.5 Lessons Learned from Our SAP ECC Projects 259

3. Prototyping

The prototype contributes to a better understanding for the pilot project team and
the business functions about the functioning of the new SAP system and builds trust.
Important decisions can be made faster, and time can be saved when things can be
shown in real time in the prototype.
In the realisation phase, special attention must be paid to the resource situation,
which reaches its peak.

7.5.4 Lessons Learned: The Realisation Phase

The complexity of the project is increased significantly by the large number of

activities scheduled for the implementation phase. The project team is facing
problems due to a lack of project management and control. For example, there is a
lack of oversight for the development of interfaces of downstream systems. By the
time this is noticed, it is much too late to avoid an impact on the timetable of the
preparatory activities for the user acceptance test. Disciplined project control is a
prerequisite for the success of a complex SAP implementation project. Identifying
problems early and implementing timely countermeasures is one of the most impor-
tant tasks of project management. In Sect. 5.3, “Qualification, Personal Suitability
and Availability of the Project Members”, we therefore have summarised the most
important guidelines for a successful approach.
The project staff’s workload reaches its peak in the realisation phase. There are
bottlenecks especially for employees with process knowledge. They have to support
development, testing, data migration tasks, the development of training materials
and often outstanding tasks from the previous phase. Therefore, enough resources
with very good process knowledge are required. Since the ideal case of unlimited
resources does not exist, you will have to prioritise and compromise. In this phase, it
is also particularly important to keep your project team motivated and happy. Plan
for a short break for everyone involved, despite the high level of stress or precisely
because of it. It doesn’t have to be a big deal; even a small event can work wonders.
What are the most important findings in the implementation phase?

1. Resource requirements reach their peak.

The resource requirements reach their peak in the implementation phase. Many
project members are under enormous stress, and there is a permanent risk that
experienced employees will leave the project. For this reason, always plan a short
time out in between, e.g. a stand-up event and the like. Also plan proactively for
possible replacement of critical skills.
260 7 Examples from Real-Life SAP S/4HANA Projects

2. Building the test infrastructure takes time.

The user acceptance test is probably the most important test in the project and
requires special attention and careful planning. Allow enough time for setting up and
providing the technical test infrastructure.

3. Data quality, data quality, data quality.

The quality of the data significantly influences the progress of the project.
Perform continuous data cleansing activities.

4. Practical training material helps.

Produce training and education materials in a practical way based on actual

business processes. Conduct a pilot course.

5. Independent training systems.

Set up a stable SAP training system for training that is independent of test and
development systems.
After the user acceptance test has been completed with only a few remaining test
cases, production preparations can begin.

7.5.5 Lessons Learned: Final Phase of Preparation/Go-Live

and Support

The main task packages in the final project preparation phase are as follows:

• Conduct training for users.

• Technical infrastructure activities for production deployment and cut-over man-
agement activities.
• Load data into the production system.
• Establish a support structure (helpdesk).

For the first 2 months after going live, all the project staff and development teams
in our sample project are still available to solve any production problems that arise.
After that the project can be handed over to ongoing operations and completed.
Finally, the project is concluded with a proper party, in which all stakeholders
participate. Mrs. Rosenbusch, the representative of the local management, and
Mr. Smith, the worldwide CIO, will have another opportunity to honour particularly
deserving project employees. All the experience gained will be documented and
recorded for future projects.
Let us now review the critical success factors for this SAP project, which are
essential for the successful implementation of the transformation process:
7.5 Lessons Learned from Our SAP ECC Projects 261

1. The project supports the corporate strategy.

It is of fundamental importance that the project supports the corporate strategy

and corporate goals.

2. The management shows commitment and support.

The management communicates the vision of the target state to the organisation.
The organisational change processes are accompanied by visible and committed
leadership by the stakeholders. The necessary budget and resources are released for
the project.

3. Common agreement about the importance of the project.

The objectives of the project clearly describe why the project is important and
what the risks would be if it is not implemented.

4. Early buy-in of the affected organisational units.

The broad-based cooperation across functional boundaries enables an early

buy-in. The functions/organisational units are actively involved in the change
process. The analysis of internal roles, responsibilities and control processes of the
affected units is carried out to determine the extent of the changes.

5. Focus on organisational change management.

Change management methods are applied consistently and throughout the proj-
ect. Organisational resistance is recognised early in the project and proactively
addressed. The communication strategy is implemented in a targeted and effective
manner throughout the entire project duration. A project homepage is developed to
keep the employees in the company up to date. Future end users are involved in the
training preparations at an early stage.

6. Disciplined project management.

Strict adherence to a disciplined project management system with regular moni-

toring and information on the project status is a must. Project risks are identified at
the beginning of the project, and countermeasures are initiated. The project plans
have a level of detail that can be understood by the project staff. A quality review is
carried out at the end of each phase. The decision-making processes are clearly
described and can be applied successfully. Conflicts across functional boundaries are
resolved quickly.
262 7 Examples from Real-Life SAP S/4HANA Projects

7. Efficient requirements management.

Ensure the introduction of a formal requirements management process, and

establish substitution rules for decision-makers who cannot be reached due to
absence.

8. Clear and unambiguous project objectives.

The project goals are measurable, clear, understandable and comprehensible for
every employee in the company.

9. Use of an experienced project team.

The staff employed in the project have the necessary skills and experience from
previous projects. The introduction date was considered feasible by the project staff
after initial difficulties and revision of the plans.

10. Focus on clean and correct data.

Focus on the data migration strategy and in particular on the ongoing data
cleansing activities. Even though data cleansing was neglected at the beginning of
our example project, the quality requirements for the final data migration could still
be achieved by timely countermeasures.
After handing the project over to ongoing operations for the pilot country, the
question arose which concept should be used for the global rollout. The obvious
thing to do is to deploy the experienced staff from the pilot project and to propose a
uniform approach, which we will discuss in the next section.

7.5.6 What Happened After the Pilot Installation: The Rollout

Concept

Goals of the Rollout Concept

There are good reasons to use the experience of the pilot project team for further
rollouts after the pilot country.

What are the objectives?

• Clear, unambiguous messages for the country teams regarding the corporate
strategy and the project objectives based on it
• Development of a uniform approach or implementation method for the rollout
and the use of common methods, project plans, tools and templates (best
practices)
• Deployment of a central “rollout team” with experienced project staff from the
pilot country to support the successor countries
7.5 Lessons Learned from Our SAP ECC Projects 263

• Bundling of project activities on a global (central) level. On the one hand, to apply
a standardised implementation method based on experience and on the other
hand, to relieve the local resources of the countries to be newly implemented,
• Alignment of global plans with local plans based on the global corporate strategy
• Central, worldwide control of the global template and the worldwide data
standards, supported by a global change board (a procedure that allows several
countries or groups of countries to be implemented in parallel; the selection of the
groups of countries should be based mainly on organisational and systemic
considerations; preferably those countries were grouped together for implemen-
tation that were supported by a nearly uniform legacy system platform and
formed a single organisational unit)
• Ensuring fast decision-making processes in a global rollout management system

The rollout method described below involves collaboration and task distribution
between the global and local project teams.

The Rollout Method

Each implementation for a country or group of countries is introduced together with
a new release.

A project handbook was made available to the countries, a kind of “cookbook”

with all activities and milestones and roles and responsibilities. The project plan is
centrally defined and supplemented with local requirements. A common, uniform
tool is used to manage the plans. Global project management is the responsibility of
the central rollout team.
Table 7.3 shows the tasks and responsibilities of the central rollout team and the
country teams.

Table 7.3 Tasks and responsibilities of the global rollout team and country teams
Global rollout team Responsibility of the
Task responsibility individual country teams
Project management Master plan, coordination of Local plans and tasks,
the global partners coordination of regional and
local partners
Process Implementation of process Provision of local process
workshops with the countries/ expertise, rollout of target
fit-gap analysis processes
Change management Introducing the global Providing local expertise and
(organisation, roles, organisational model and the introducing the new job roles,
communication, new job roles for end users, adapting communication and
Training) providing global training material to local
communication and training requirements, development of
material, advice and support a local training plan
in all local change
management tasks
(continued)
264 7 Examples from Real-Life SAP S/4HANA Projects

Table 7.3 (continued)

Global rollout team Responsibility of the
Task responsibility individual country teams
Group reporting Introduction to the new global Defining local requirements
group reporting system, for group reporting,
guidance and support on local introduction of group
rollout issues reporting in the country
IT Supporting the local rollout Implementing local
• Local adjustments/ team in the preparation of requirements including
interfaces requirements for local development, testing and
applications, coordinating the coordination of local partners
worldwide partners
Test User acceptance and Providing local expertise for
• Preparing test scenarios preproduction testing, test preparation and test
and test execution, test coordination of global partner execution, responsible for
management, test plan, test applications providing the local test
infrastructure, error correction infrastructure
Production preparation Overall cut-over/go-live plan, Coordinating local partners
• Creating the overall coordinating global partners, and preparing all local
plan for cut-over/go-live support for local country activities
activities teams
Migrating legacy data into the Data migration strategy and Supplying local expertise for
target system all data migration activities all data migration activities,
as well as of resources for
data cleansing activities
User support/support Introducing the local country Adapting local support
structure teams to the worldwide structures to the global model
support structure

Process Workshops
In order to evaluate the country-specific process requirements, the countries are
provided with a questionnaire for workshop preparation 4–6 weeks before the first
process workshop. The questionnaire contains questions such as the following:

• Which application programs are used to support the running processes?

• Are the processes carried out manually?
• Which legal requirements must be taken into account?
• In which organisational form are the processes carried out?
• How many users are in which locations?

The workshops are conducted with the department specialists of the countries, the
process experts of the rollout team and the staff of the central data migration team in
the last 2 weeks. The aim of the workshops is to keep the common worldwide
processes, as documented in the global template and implemented in the SAP
system, as unaltered as possible, thus keeping country-specific requirements to a
7.5 Lessons Learned from Our SAP ECC Projects 265

minimum. This way, the development costs for future implementations can be kept
within reasonable limits.
The procedure is as follows:

1. First, the actual processes of the countries to be newly implemented are identified
and discussed. This is based on process documentation and interviews with local
experts.
2. In the second step, these processes are compared to the global template and the
SAP solution that was implemented in the pilot country.
3. On the basis of the actual and target processes, the future solution is documented with
the aim of avoiding development costs wherever possible. However, there were
intense discussions whether the process requirements set by the local country
organisations were justified or not. The burden of proof lies with the local countries.
In these cases, the rollout management system with fast decision-making processes has
proven its worth. For local requirements that were justified but would cause excessive
development costs, semiautomated or manual process sequences have been agreed.
4. Finally, the requirements for the implementation are already documented and
prepared during the workshop (system-specific) so that the development teams
can start programming immediately.

Another key success factor for the success of a complex international project is
the introduction of an adequate rollout management system.

The Rollout Management System

The management system for the rollout is a matrix management system with a global
and country-specific level. All activities that can be performed centrally are handled
by the global rollout team or the global test and data migration team.

Figure 7.15 shows the roles and tasks of the teams involved in the rollout
management system: the central development and infrastructure team, the central
test and data migration team and the central rollout team. At local level, the
implementation teams are located in the post-pilot countries.
All development, testing and data migration activities are controlled and carried
out at a central global level. Local project plans must be coordinated with the master
plan of the global rollout team.
The main responsibility of the rollout countries is to provide the necessary local
expertise for the various activities with experienced staff. The interface to the global
development team is handled exclusively by the global rollout team. All global
support functions (development, testing, data, rollout) have a direct reporting chan-
nel to the global sponsor, the local country teams to the global rollout team and the
local managing directors. Communication to global partners in the project is handled
by the central rollout team, communication to regional/local partners by the
country team.
In an international project with project teams that perform different roles and
tasks in different geographies, an up-to-date information must be available for
266 7 Examples from Real-Life SAP S/4HANA Projects

Rollout-Management-System

Roles/Responsibilies

Global Sponsor
Global Test-
Team

Global Global Rollout-Team

Development Interface to Sponsor and global
and Partner/PMO/
Process/Training/Communicaon
Global Partner
Infrastructure

Global Data Region-/Country-Team

Migraon- Interface to regional and local
Team Partner / Experse in local
Regional and
Process, Systems, Execuon of
local acvies local Partner

Fig. 7.15 Roles and responsibilities in the rollout management system

everyone involved. But a word of caution here! Too many meetings and telephone
conferences tie up valuable time because they require preparation and participation
by the project team members. On the other hand, missing or incomplete information
leads to duplication of work, overlapping and ultimately to lost project time. It is
important to find the right balance here, according to the motto “as much as
necessary, as little as possible”. Sounds easy, but it is a challenge in a complex
international project! How it is implemented is shown in the following summary:

• Meetings of the steering committee

The members of the steering committee meet monthly. The central rollout team is
responsible for preparing and organising the meetings. The following items are on
the agenda:
• Overview of the project plan timeline
• Objectives achieved since the last meeting/status action plan
• Status of dependencies on other partners/open issues
• Worldwide/local milestone overview
• Status of development, test and data migration
• Problems/risks/issues requiring a decision
• Next upcoming activities according to the project schedule
• Worldwide project status meetings
Weekly worldwide project status meetings of the overall plans (of all partners
involved in the project). The global PMO prepares the meetings, and they are
hosted by the global project sponsor.
7.5 Lessons Learned from Our SAP ECC Projects 267

• Local project status meeting

There are also weekly project status meetings between the local project teams and
the global rollout team in preparation for the global project status meetings.
Preparation is done by the local PMO.
• Process design reviews and solution design reviews
Process design reviews and solution design reviews take place when required to
obtain approval for a development solution from the local teams and affected
partner functions.
• System architecture meetings
These coordination meetings take place monthly or as required to identify
changes or deviations.
• Quality checks
Quality checks are performed after each project phase is completed and in
preparation for the productive phase. They are led by the global sponsor, while
preparation and implementation is handled by the central rollout team.
Let’s now take a look at how the concept has proven itself in daily
project work.

How Does the Implementation Succeed in Practice?

Next, we’ll describe how the rollout concept is successfully implemented in daily
life. First is a brief summary of the critical challenges for a rollout of new processes
and systems in other countries or groups of countries:

• Making critical skills available is difficult to ensure in smaller groups of

countries. Knowledge of the new processes and systems is with the global rollout
team. Local specialists are required for the analysis of the local as-is situation.
• The complexity of the integrated overall solution. The changes affect different
processes, systems and organisational units and require the cooperation of differ-
ent departments in the local subsidiaries.
• The rapid implementation requirement is also a critical challenge.

It is only possible to ensure that local specialists are made available via the
continued strong support of stakeholders in the project. Equally helpful is the already
proven global project management system with a global project sponsor, who also
assumes overall responsibility for further rollouts after the pilot installation.
Important! The project continues to have top priority within the group.
The project kick-off for a new country implementation is planned 4 weeks before
the actual project start. The global rollout team is responsible for organising the kick-
off. The global and local project sponsors, the local project management and the
management of the global rollout team with some of their technical specialists
participate in this event.
The following topics are covered:

• Overview of the new global processes and systems

• Organisational impact of the project on the local departments
268 7 Examples from Real-Life SAP S/4HANA Projects

• Lessons learned and experience from the pilot installation and subsequent country
implementations
• Presentation of the worldwide rollout management system and proposal for local
project management system
• Tasks and responsibilities of the global support functions (rollout, testing, data,
development)
• Aims and contents of the project handbook (cookbook)
• Local specialist resource requirements for the rollout
• Overview of project budgets and budget management
• Worldwide project plan with milestones as a basis for local plans

At the same time, preparations are being made for the local country-specific
process workshops (see rollout concept before “What Happened After the Pilot
Installation: The Rollout Concept”). Either before or during the project kick-off
meeting, the process questionnaire will be made available to the local rollout
organisations. Apart from appointing the local project management, the most urgent
task is to assign local process specialists to support the planned process workshops.
The development process for implementing new requirements from the process
workshops is shown in Fig. 7.16. The requirement is first analysed in its entirety by
process specialists to determine whether the requirement can be incorporated into the

Development process for new requirements from the process

workshops

Procedure:
Determinaon of Program Review Program
Development
requirements Specificaons Code

Requirement-Analysis Component Test

Release Program
Requirement-Review Customizing Code /Update
Documentaon

Update Process documents/

SAP Architecture Enduser Instrucons

Review

Final acceptance of the

Prozesse Experts requirements

Development Team

Fig. 7.16 Development process flow

7.5 Lessons Learned from Our SAP ECC Projects 269

Rollout-Timeline for succession countries

10 Months

Producon-
Planning and Realizaon Go Live and
Blueprint 2-4 Preparaons
Preparaon 1-2 4-7 Support 10
8-9

Project-Management

Adaptaon Process Template

Customizing/Developmt/Interf
aces/System-Integraontest/
Training Material developed
Data Cleansing
Data Conversion/Load

Training completed,
Producon-System
tested, Helpdesk, Go
Live Approval

Go Live/Handover
Helpdesk

Fig. 7.17 The post-pilot rollout timeline shows the main activities of the rollouts over the different
project phases

overall strategic solution. If this is the case, SAP architects check the consistency
across various modules and clarify whether there could be interface problems with
upstream or downstream processes. If the requirement is approved, the implementa-
tion can be achieved either by customising or, in if necessary, by development. After
completion, the process and end-user documents must be updated, and the final
acceptance is performed by process specialists.
If a request is rejected, it is possible to escalate the process within the project
management system via the global PMO. Final decisions are made by the global
steering committee.
Based on the experience with the pilot installation, the project duration for the
rollout of a country or group of countries is assumed to be 10 months. This is a
challenging timeframe, but with a few exceptions, it can be met. Figure 7.17 shows
the main activities of the roll-outs over the different project phases.

Pay Attention to Cultural Differences!

The start of the project is proceeding without major problems for most countries. The
fact that cultural differences must be taken into account becomes obvious with the
first rollouts to non-European countries. In accordance with the rollout concept,
further coordination is initially carried out by telephone after the project kick-off. In
the first few weeks, the local pilot team must supplement the already existing global
270 7 Examples from Real-Life SAP S/4HANA Projects

project plans with local activities. Telephone conferences are planned twice a week
for this coordination. The detailed project plans agreed between global and local
teams should be made available after 4 weeks.

The first conference calls were held without any major queries from the local
participants. After 3 weeks, the first local sub-project plans should be available. It is
only at this point that the global rollout team finds out that no detailed activities had
been carried out at the local country level. The reasons are on the one hand language
barriers—the project language is English—and on the other hand the reluctance of
the staff in the local country team who had not asked any questions. In order not to
waste any more time, two members of the central rollout team were therefore sent to
the local country team for the following 4 weeks. In this way, questions and
ambiguities can be answered immediately in a personal meeting. In retrospect, this
decision was an important step for the success of the rollout project and the trustful
cooperation going forward.
A quality review is planned after the end of the Blueprint phase. This review
focuses on the critical activities of the individual sub-plans. For each sub-plan, there
is a catalogue of questions to be answered in advance by the local team. The review
itself takes place in the rollout destination with the local management and country
team, the global project sponsor, the global support functions (test, data, develop-
ment) and the central rollout team present. It is scheduled for 2 days and is organised
by the central rollout team. The review of the sub-plans included the following tasks:

• Project management
– Overview of budget/resources
– Overview of the plan status and plan tracking
– Introduction of the local project management system (frequency of meetings,
involvement of local partner functions)
– Compliance with documentation guidelines
• Process
– What is the current process request status/which critical processes are
still open?
– What is the link to partner functions?
– Overview of the implementation plan of the new process control points.
– What is the status of the local project documentation influenced by the project?
– Are experienced resources participating in the testing local processes?
• IT
– What is the status of the local IT dependencies that are a prerequisite for the
user acceptance test?
– Are other IT infrastructure measures planned (laptops, PCs, printers etc.), and
what is their status?
• Test
– What is the status of the local test preparations?
– Are local testing resources assured?
– Are local partner functions involved?
7.5 Lessons Learned from Our SAP ECC Projects 271

• Training
– Are the resources for training available?
– Are the training participants identified and informed?
– Are local adaptations of the worldwide training material necessary?
– Are the logistical requirements for the training measures fulfilled?
• Job roles
– What is the local implementation plan for new job roles?
– Are all affected local organisations informed?
• Communication
– Are the stakeholders identified and informed?
– Is local management support for the project ensured?
– Are the internal departments informed?
– Is there an overview of the local communication plan?
– Have external partners affected by the project been identified, and how are
they kept up to date?
• Data
– Are local resources available for data migration tasks?
– What is the status of local data cleansing actions?

The result and the recommendations and actions derived from the quality review are
communicated to local and global management in a report. The follow-up of the
actions is done through the weekly project status meetings. After completion of the
user acceptance test and before the start of production preparations, a further review
takes place on site. In terms of content, the focus is on the final activities of the
realisation phase and the planned activities of the production preparation phase.
The positive experience gained by sending specialists from the worldwide rollout
team to the local country team also helps in the user acceptance test. An experienced
test employee supports the local team on site during the entire test phase. This way,
problems with the different time zones can be at least partially mitigated,
i.e. standstill in the project can be avoided in most cases. Questions that cannot be
answered immediately by the central test person on site are clarified the next working
day in telephone coordination meetings. For countries that have already been
implemented, uniform test regression scenarios are used, which are administered
by the central test team or handled with the support of automated test tools. After
successful completion of the user acceptance test, the SAP transport requests can be
released into the productive environment and the training system. A further final test
is then carried out on the preproduction system with some selected business
transactions. Afterwards, loading of the data for the new country can begin.

Training for the New Countries

Training courses for end users run parallel to this. The training materials prepared
for the pilot installation are adapted to country-specific requirements in order to
include local processes. For classroom training, a project team member from the
country team is upskilled according to the already proven “train the trainer” concept.
He/She is accompanied by an experienced trainer from the pilot installation who is
272 7 Examples from Real-Life SAP S/4HANA Projects

available to answer questions. The training is conducted in the national language; the
training material itself is available in English and is not translated. As with the pilot
installation, online training modules are also offered for additional user groups. This
successful concept is maintained for all further rollouts.

Go-Live
The go-live for each new country or group of countries requires the approval of local
and global stakeholders in a final go/no-go meeting. The prerequisite for this is the
successful completion of all criteria from the go-live checklist (see Sect. 6.5.4 in
Chap. 6, “Tasks in the Different Project Phases (Checklists)). For the handling of
production problems after the go-live phase, two additional staff members are
scheduled to support the country teams on site for the first 4 weeks after production
start.

Note: Advantages of the Rollout Method

The procedure we present here has the following advantages:

1. The standardisation of activities in central teams very quickly achieves high

productivity, reduces the total cost of the project and enables a fast rollout.
2. The central teams work in different time zones according to the follow-the-
sun principle. In this way, problems can be solved without delays.
3. Resource bottlenecks in smaller countries that have problems providing
specialists can be addressed by support of the central teams (testing, data,
rollout).
4. The chosen procedure for identifying local process requirements (prepara-
tion and implementation of workshops) contributes significantly to reduc-
ing development costs.
5. Several countries or groups of countries can be set productively at the
same time.
6. The standardised uniform approach allows production stability to be
maintained during country implementations.

The experience gained from the pilot installation and the subsequent worldwide
rollouts clearly show how essential careful planning, control and quality assurance
are for the success of a project. Chapter 6, “Project Planning, Control and Quality
Assurance”, explains how to lay the foundation in this sense.
If you want to know who or what is supporting you in your project, then read on
in the following two chapters: the best way to leverage external resources is covered
in Chap. 8, “External Resources: Curse and Blessing”, and which helpful software
tools exist in Chap. 9, “Project Support Tools”.
Consultants: Boon or Bane? Benefit
or Burden? 8

In the previous chapters of this book, we have taken the perspective of a project
manager to introduce you to pitfalls and possible solutions. In most cases, it is
irrelevant whether the project manager is employed by the company carrying out the
project or he/she is an employee of a consulting firm or a freelance consultant.
In this chapter, we take the perspective of the company implementing SAP
S/4HANA and show you what you should look for with regard to external
consultants. We will show you how to find the best SAP consultants and how to
work together successfully. In addition, we will discuss the special benefits and risks
of using teams from offshore or nearshore centre locations.
In this chapter, we are talking about SAP consultants in general, but we mean
consultants with special SAP S/4HANA experience. As already mentioned at the
beginning of the book, there are two groups of SAP experts: those with SAP ECC
experience and true SAP S/4HANA specialists. That is as it should be, because there
are currently far more productive SAP ECC (or SAP Business Suite)
implementations than those based on SAP HANA or SAP S/4HANA. With the
continuing success and increasing adoption of SAP S/4HANA, however, the scales
will continue to tilt towards SAP S/4HANA consulting. Having said that, many
selection criteria for external help in the project do not differ between conventional
(SAP ECC) consultants and those for SAP S/4HANA projects, so we will only refer
to this in this chapter if there are special SAP S/4HANA selection criteria. Other-
wise, what has been said applies to many transformation projects, SAP S/4HANA
or not.

8.1 Why Bring in External Support?

Consultants are involved in almost every major SAP project. Therefore, it makes
sense to take a closer look at how these external helpers can be integrated into your
project in the best possible way. First of all, we take a closer look at the role of

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 273
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_8
274 8 Consultants: Boon or Bane? Benefit or Burden?

consultant companies in general. Then, we look at the special challenges of working

with consultants from your own company, so-called in-house consultants.

Dream Job SAP Consultant

Since the beginning of the SAP R/3 era, many consulting companies have focused
on SAP consulting because it is simply a lucrative business. In the beginning, it was
the large consulting companies that established their own SAP consulting areas in
addition to strategic and organisational consulting and general IT consulting. Later,
specialised SAP consulting companies joined the market, offering expertise and
specialist industry knowledge that the rapidly growing number of SAP customers
needed. SAP itself cooperated intensively with external consulting firms at an early
stage, thereby refining the methods used to introduce the software—an approach that
has certainly also contributed to the SAP success story.

However, SAP S/4HANA is not just a new software version; it also changes the
content, duration and budget of SAP projects. With SAP ECC, there were (or are)
some lean, standard-oriented and relatively quick SAP implementation projects but
also many programs that run for years and devour tens of millions of euros (in some
cases without much to show for it). With SAP S/4HANA, things have changed
fundamentally: compared to SAP ECC or even the entire SAP Business Suite, the
functional scope of SAP S/4HANA is still rather limited, and with the ready-made
solutions (keywords here, Focused Build and Rapid Implementation), implementa-
tion close to standard will be accelerated once again.

Transformation Projects
But SAP S/4HANA projects are of course still transformation projects, and
extensions to the standard are also possible and often useful (except in the SAP
S/4HANA Cloud). The bottom line is that SAP S/4HANA projects are currently
often shorter and smaller than conventional SAP ECC projects. Of course, this also
reduces the time external consultants spend on a project. There are fewer of them in
the project, and hopefully (as was the case at the beginning of the SAP project era)
they will once again have far more knowledge and experience with the new SAP
product than the customers. In general, SAP’s own consulting now plays a greater
role in many projects, which is not surprising given the frequency of one new SAP
S/4HANA release per year.

Note: Have Laptop: Will Travel

At this point, we would like to take a brief look at some common prejudices: in
the past, it was often standard practice for graduates of computer science or
business information technology to be hired by consulting firms just to be
“resold” at a high price as SAP consultants only a short time later. A common
adage in consulting circles was that as a consultant, one should have a one-day
knowledge advantage over the customer. The next day on the project was

(continued)
8.1 Why Bring in External Support? 275

prepared the night before—by reading online help or interviewing “experi-

enced consultants”. Junior colleagues were also frequently asked to prepare
and conduct training sessions.
Fortunately, the days are over when anyone who could spell SAP called
himself/herself “SAP consultant”. Nowadays, SAP customers have so much
know-how themselves that a “consultant” is lost without profound knowledge
and is quickly sorted out. And SAP S/4HANA know-how in particular is by no
means easy to learn. You can recognise good SAP S/4HANA consultants
relatively quickly by their up-to-date SAP S/4HANA knowledge.

SAP consultants, who have implementation experience, industry knowledge and

in-depth IT expertise, are in demand. In an SAP project aimed at improving the
company’s processes, consultants play a major role as know-how providers in
addition to providing additional manpower. They bring along best practices from
various projects and ideally have already introduced S/4HANA in a similar company
to your own. This means that you can draw on experience that internal employees
would first have to laboriously acquire in the course of the project.
The following reasons speak for the use of external consultants:

• Lack of in-house knowledge

The required knowledge is not available in many areas in-house. Often it is
simply not worthwhile to hire an expert for a special topic on a permanent basis.
For example, you may only need an SAP S/4HANA project controlling expert
or an SAP workflow expert for a limited time during the introduction phase.
Special technical skills may also only be needed for a short period of time.
Consultants bring valuable process and industry expertise to the project team,
as they have carried out similar projects more than once and know what is
important.
• Lack of manpower
During a project, additional staff are always needed: besides the daily business,
the project has to move ahead—and that takes several weeks to several years.
Although these additional employees are more expensive as consultants, they can
be deployed more flexibly and are often not subject to the strict labour laws and
working rules of the client’s industry.
• SAP consultants as messengers for tough decision
In many cases, unpleasant decisions have to be made and announced in the course
of a project. External consultants are in a much better position to do this, because
they (usually) leave the company again after the project.
• SAP projects as a recruiting platform
Consultants are also a welcome long-term reinforcement for your own team. The
fact that consultants change sides is also not unwelcome on the side of many
consulting companies: former employees will later use their old networks and be
good contacts for future SAP projects.
276 8 Consultants: Boon or Bane? Benefit or Burden?

Know-how Transfer
Within the framework of a project know-how transfer plays a key role: after all, you
need the additional manpower of the consultants as well as their knowledge. But the
consultant will leave your company again at some point. Therefore, make sure that
the knowledge that is important for your project and your SAP S/4HANA solution
remains in the company. At the end of the project, the new SAP S/4HANA system
has to be operated, supported and understood by the internal departments—unless
the system operation is also carried out by external companies.

Almost every professional or technical problem has been encountered before at

some point. Your consultants are trained in the use of tools such as knowledge
portals and communities and have established contacts within SAP or the endless
networks that play an important role in everyday consulting—so make use of them!
You can also learn a lot from your consultant.

Note: Project Information Sources

SAP provides numerous resources that will help you find answers for
questions from your project. Online services such as the SAP Community or
the SAP Help Portal contain the concentrated knowledge of countless SAP
users, consultants and developers. Here you will find solutions to many
problems or forums where you can discuss with helpful experts (both from
SAP and external companies).

In the next section, we will look at which project roles consultants can and should
take on and which ones you may prefer to keep in-house.

8.2 Finding the Right Ones

There are two ways to involve external consultants in your project:

• Temporary staff and experts on demand

Experts or teams of experts in the project are paid on a time and effort basis. The
client (the customer who carries out the SAP project) usually assumes responsi-
bility for the project’s budget and time schedule.
• Work contracts: entire work packages are handed over
Parts of the project (and in rare cases the whole project) are realised by a
consulting firm. Here, the responsibility for these areas, including budget and
time schedule, is transferred to the service provider—often at a fixed price.

The project roles that are assumed by consulting in these variants are discussed in
Sect. 8.4, “Role Distribution Between Client and Consultant”.
8.2 Finding the Right Ones 277

Ways of Working Together

But first a few thoughts on choosing the right partner: in our many years of practice,
we have come across a wide variety of ways that client and consultants work
together. In most cases, reasons for the respective preferences are personal (good
or bad) experiences of the decision-makers involved, the available budget,
timeframe and availability of expertise among others.

Examples:

• There is a long-standing strategic partnership between the client and the

consultancy firm.
• There will be project-related tendering procedures (these are sometimes compul-
sory, particularly in the public sector).
• Sometimes contracts are awarded to more than one consulting firm—especially
for large and expensive projects. This also applies to smaller SAP S/4HANA
projects, as SAP S/4HANA often brings other cloud products into the project—
often with specialised consulting providers.
• There is no link to a (large) company; freelance consultants or smaller, local firms
are more likely to be used.
• Leveraging one’s own consulting firm/in-house consulting, or there is a close
connection to a consulting firm that has been working for the business for a
long time.
• Only our own resources are used; if necessary, employees are hired.

Decision Criteria for the Selection of Consultants

There is no silver bullet here. However, if you want to hire an external consultant, the
following tips are certainly useful:

• Professional knowledge
You know pretty much what role or task the consultant should take on in your
team. Have his or her experience explained to you. Ask about similar projects the
person has worked on. It is also important to have experience in the industry and
in which project phases he/she has been involved. Good consultants can provide
references to prove their experience. Do not hesitate to call them. You may gain
valuable information about the candidate from a conversation with a previous
client.
• Soft skills
The question of whether the future consultant fits into the team is very important.
Someone can be excellent in their area of expertise—but if they don’t fit in the
team, problems are inevitable. A colleague put it this way: “A person is a good fit
for your team if you can see yourself spending time on a desert island with him or
her”.
• Price
Of course, the financial conditions must not be ignored either. If someone blows
the budget, he/she will not fit, even if all other checkboxes are ticked.
278 8 Consultants: Boon or Bane? Benefit or Burden?

Note: SAP Consulting and Support

SAP’s support organisation is involved at a certain point in every project—as
the last instance for questions and problems. In addition, there are the sales
staff and SAP’s enterprise support organisation. In many cases, experts from
SAP’s own consulting arm (SAP Consulting) are also involved in the project.
In most cases, these are so-called subject matter experts, in other words,
experts in a specific topic who have the shortest line to SAP product develop-
ment. This short line is all the more important with SAP S/4HANA. The short
development cycles often lead to incomplete documentation.
Compared to other consulting companies, SAP expertise is significantly
more expensive. Many customers therefore decide to engage other consulting
firms for the bulk of the project work and rely either on SAP consulting or
enterprise support for project phase reviews at certain milestones and “third-
level support”.

8.3 Fixed-Price Service Contract or Time and Material?

By Effort or Result-Oriented?
There are various ways to define the contractual framework with external consultants
and structuring the renumeration.

The two most common ones are as follows:

• Accounting is carried out on a time and material basis by means of so-called staff
augmentation.
• The project tasks are provided as packages with a fixed price.

Both, like most things in life, have advantages and disadvantages, as you will see
below.

External Advice or Long-Term Reinforcement?

The possible division of tasks between internal staff and those of a supporting
consulting firm is usually determined before the actual project. Commonly applied
criteria can be found in Table 8.1.

Staff-Leasing
If external staff are brought into the project for limited tasks, the costs are usually
charged on a time and material basis. Billing is based on working time, not on
results. The management of the project remains fully under the supervision of the
client. Even if the position of project manager is filled externally, the overall
responsibility for the budget and the course of the project remains with the client.
Table 8.2 shows the advantages and disadvantages of this approach.
8.3 Fixed-Price Service Contract or Time and Material? 279

Table 8.1 Overview of the possibilities for the division of labour between internal and external
staff
Criterion Possible solutions
Shortage of own staff (long term) Strengthen your team in the long term through
an internal transfer, or hire a new employee
Shortage of own staff (short term) Look for (temporary) internal support for your
own team, or look for an external consultant
Lack of expertise • Is the missing expertise needed long term? Try
to build it up internally
• To close a temporary knowledge gap (only for
the project), look for an external consultant
Changing boundary conditions (outsourcing, • Will this be a permanent or temporary change?
acquisition/divestiture of parts of a company, • You are looking for an external consultant for a
change of business model) limited time. For long-term changes, you should
upskill colleagues or hire new employees with
the appropriate know-how
Budget restrictions Sometimes it is easier to assign an external
employee to a project (even if it is more
expensive) than to hire a new employee. You
may want to call on external help first and wait
for the right moment to obtain internal support
External financing of projects (or project Sometimes it is an option to have the project
parts) financed externally—but then the financial
backer often specifies the personnel. In this case,
IT service providers finance not only hardware
and software but also the related (SAP)
projects—provided they then also carry them
out

Table 8.2 Advantages and disadvantages of staff leasing (“body leasing”)

Advantages Disadvantages
You can easily compare effort Full responsibility for the results is with the client
and results
Early detection of deviations The project manager is fully responsible for the performance
from the plan of the external staff
Problems are easily spotted All boundary conditions are the responsibility of the client
Complete control over the Project management is the responsibility of the client
project status

Assigning Work Packages

The other approach is to award work packages to external consultants. In addition to
working on SAP projects, you can also define system administration, the operation
of non-SAP software or project-related tools (e.g. the ARIS toolset) as a work
package. As a general rule, work that can be easily separated from the rest of the
project (e.g. software development, data migration or testing) is a good candidate for
work packages.
280 8 Consultants: Boon or Bane? Benefit or Burden?

Table 8.3 Advantages and disadvantages of awarding work packages

Advantages Disadvantages
The costs for these work packages can be Problems or delays often only become apparent
easily planned over the entire project duration when the results are delivered (or just before)
The responsibility for these packages lies with Responsibilities lie with different companies;
the consulting firm/external provider different views on the scope/quality of the
results are possible, which can lead to
disagreements in the project
Fixed milestones for the transfer of results are The estimated and actual effort are sometimes
specified; the development of the results is the far apart, although this is not visible up front
responsibility of the provider (including the
necessary project management)

When awarding work packages, central success factors are the precise definition
of the work that belongs to the package and an accurate estimate of the required
budget. And this is the crux of the matter for both sides. It is a bit like looking into a
crystal ball: you have to provide detailed information and estimates for the results of
the project before the project starts. However, a solid estimate is often not possible at
this point, as many things only emerge in the course of the project or may change
during the project. For example, interfaces are often documented on the basis of data
flows. The technical specifications often change due to additional systems that are
integrated into the process. For this reason, assumptions are often made, which are
later put to the test and confirmed—or not. Fixed-price projects are therefore
sometimes subject to a risk surcharge to cover unforeseeable costs. Table 8.3
shows some advantages and disadvantages of fixed price work packages.

Hand Over Full Responsibility

A possible third option is the transfer of overall responsibility to a service provider.
This contractual setup is particularly interesting for companies that are implementing
their first SAP project and have no—or very little—SAP know-how in-house. In this
type of contract—which can be realised either as a fixed-price project or on a time
and material basis—close project monitoring by the client is indispensable, as
otherwise these projects can easily develop a life of their own.

Make sure to define the most important key data for the project precisely. These
include the following:

• Content
• Scope
• Results (in detail, which results are expected during the project and what are the
deliverables at its end)
• Milestones and total duration
• Budget

Make sure that the deliverables are part of the contract. In addition (not only at the
end of the project), continuous, detailed progress reports on all the abovementioned
8.4 Role Distribution Between Client and Consultant 281

points are required. Even if the overall responsibility during the project phases lies
with the service provider, tight control from the client company is key.

Note: Common Pitfalls when Transferring Overall Responsibility

If you hand over the entire project responsibility to a service provider, two
different objectives may coincide: of course, all parties involved want to make
the project a success; for the consultant, however, each additional consulting
day also means additional revenue, while for the customer, each additional day
of consulting means additional costs.
In the case of a fixed-price project, however, it is the opposite. Each
additional day spent on the project means less profit for the consultant.

8.4 Role Distribution Between Client and Consultant

In this section, we look at the distribution of roles and responsibilities between the
internal project team, i.e. the employees who participate in the SAP project within
the company, and the external consultants. There are essentially three ways of
assigning responsibility to distribute:

• Shared responsibility
• Sub-projects under consulting responsibility
• Individual task under consultant responsibility

The first way of distributing roles is the so-called two-in-a-box approach. The
project roles are filled equally by internal experts and external consultants. Each
team, up to the project management, consists of internal employees and consultants.
This has several advantages: knowledge transfer—an important project task in order
to be able to operate the SAP system later without external help—takes place
“organically” during daily work. As a customer, you have a daily insight into the
concrete project results. The responsibility for the good and bad of the project lies
equally with both sides. Even you as project manager have a co-project management
from the consulting side.

Clear Rules and Trust as a Basis

To guarantee the success of this constellation, it is necessary to establish clear rules
of the game from the outset. If the integration is successful, after a certain time, it will
no longer be possible to determine from the outside who is an external consultant and
who is an employee. But this requires one thing above all: trust—trust in the abilities
of the other side and also trust in the human qualities. After all, the teams work very
closely together over a long period of time and have to cope with a number of critical
situations. In addition, there are periods with a very high workload; ideally, this
brings consultants and clients together.
282 8 Consultants: Boon or Bane? Benefit or Burden?

Table 8.4 Advantages and disadvantages of shared responsibility

Advantages Disadvantages
Everyone feels responsible for the overall result ... ... or problems arise due to different
opinions
Different corporate cultures can create added value ... ... or cause problems
The two-in-a-box approach secures additional ... which at the end of the project
manpower and knowledge in the project at short disappears just as quickly as it came
notice ...

Table 8.5 Advantages and disadvantages of sub-project transfer

Advantages Disadvantages
You as a project manager will be ... or you are no longer involved in the decisions and
relieved of work ... experience unpleasant surprises
A clear task definition makes your work ... or there is additional work for coordination and
easier ... documentation
At the end of the project, this sub-project ... but you do not know how you got there
delivers good results ...

Table 8.4 shows you the advantages and disadvantages of the “two-in-a-box”
approach.

Sub Projects Under Consultant Responsibility

The second variant of role allocation is the transfer of certain sub-projects to the
advisers. This is useful, for example, when integrating certain systems, migrating
data, rolling out to certain countries, developing tasks and testing. Basically, you as
project manager only need to query the status of the outsourced task. The details
must be clarified by the respective person in charge of the consulting team. Of
course, you must (be able to) rely on the quality of the delivery and adherence to
deadlines.

Table 8.5 compares the advantages and disadvantages of sub-projects under

consultant responsibility.

Taken from Project Life

An example from our project experience is a finished SAP template which is to be
rolled out in parallel in two different countries. The customer has developed his own,
very well-thought-out procedure. The consultants can only counter this with their
tried and tested method. Mixing the teams would not have brought success. In the
end, there is a migration and rollout contest, so to speak: two projects running in
parallel with the same goal—rollout of an SAP template in a national company—
using different methods and tools. The result is a draw. The consultants are a bit
faster, but the internal team is ahead of the game in data migration.

The project organisation chart for awarding sub-projects to consultants could look
like the one shown in Fig. 8.1. Often there is a second project management office
8.5 The Internal External 283

Program
Sponsor

Advisory Boards
Execuve
Steering
SAP Commiee

Technology
Customer: Consultants:
PMO
Executive PMO PMO
Leadership Team

Regional Customer: Customer: Consultants: Consultants:

Leadership Teams Funconal Technical Funconal Technical
Teams Teams Teams Teams

Fig. 8.1 Division of responsibilities between client and consultant

(PMO) for the consultants and a co-project management. However, responsibilities

are clearly defined.

Individual Project Tasks in Consultant’s Hands

The third and simplest variant of role allocation is the use of external experts for
defined project tasks. These may be technical experts for specific processes, and their
tasks may range from quality assurance to project management. If the project is
going well, the external consultants will soon be blending in and almost become an
integral part of the client company. The only catch is that external consultants are
usually more expensive than your own employees.

8.5 The Internal External

Consultation in Your Own Company

One variation of the role allocation between internal and external project staff, which
we encounter primarily in large SAP projects, is the use of a company’s own
consultants. In many cases, such in-house consultants are only experts who can be
flexibly deployed within the company, but do not work on external SAP projects.

In contrast, many large IT companies (e.g. SAP or IBM) have their own consulting
division. The SAP consultants employed there are mainly involved in external
projects. They work on internal projects only in (not so rare) exceptional cases.
These consultants usually have the necessary knowledge and know the customer
(i.e. their own company) and of course the industry. In addition, the internal transfer
prices are usually lower than the rates of external consultants.
284 8 Consultants: Boon or Bane? Benefit or Burden?

Note: Five Pitfalls when Using Internal Consultants

Are internal consultants a guarantee for the success of a project? From our
experience, this statement is not necessarily true. When planning projects with
internal consultants, be aware of the following pitfalls:

1. Training projects.
Internal SAP projects are often used to train young consultants. Therefore,
an above-average number of inexperienced consultants may be involved in
the project.
2. Replacement bench for consultants.
Often an internal project is used to “park” colleagues who are currently
available. Every consulting company uses the capacity utilisation as a key
figure—and this a way to achieve this KPI.
3. Replacement.
Consultants who have either completed their training or whose area of
expertise is needed externally (see points 1 and 2) can be quickly pulled
from the project. This increases the risk for the project management as it
may lead to key resources becoming unavailable at short notice.
4. Is it worth it?
There are often bonus system that rewards external revenue and external
capacity utilisation. These do not fit in with internal SAP projects. As a
result, some consultants avoid internal projects and see them only as a stop-
gap measure when external business is slow.
5. The prophet has no honour in his own country.
The planning and implementation of the project may suffer from a lack of
professionalism (“is only an internal project”).

And finally, there are hierarchies in every company. External consultants are
outside this hierarchy; internal consultants are not. The reluctance to admit that a
particular wish cannot be fulfilled becomes much greater for the consultant if the
customer is also a superior.

Note: Jobs for Consultants

Killing the bearer of unpleasant news has fallen out of fashion since Graecian
times; our recommendation is that for certain key positions and” difficult”
roles (i.e. those that need to communicate unpleasant truths), external
consultants are the better choice—even if they are more expensive.
8.6 Project Goals 285

8.6 Project Goals

The various parties in your SAP project all share the same goal: to bring the project
to a successful conclusion. However, there are small, but sometimes significant
differences in motivation of the individual project members. Being aware of
individuals’ “hidden agenda” and boldly counteracting such tendencies can contrib-
ute considerably to the success of the project.
Some examples:

• The internal project management

• As one of the main actors of the project, the internal project management
committed to the success of the project. He/She identifies with the task and the
project. Why? The successful project enhances his/her reputation in the company
and promotes his/her professional career. The project manager is responsible for
content, planning and budget. He/She will continue to accompany or be linked to
the project in the future. The success of the project is his/her success!
• The external project management
Generally speaking, the same applies to the external project management as for
internal project management, except that for the external project manager, the
involvement with the customer ends at the same time as the SAP project. This can
be detrimental to sustainability, and when major problems arise, it is much easier
for the external project manager to leave the project without further consequences
for his/her career. (I am sure the same applies to all sub-project leaders of the
consulting teams and the consultants themselves.)
• Line managers
• The respective department heads, process owners, management personnel and
project staff often change their professional environment during the project and
especially after the project is completed. This means that not only the software
they work with changes but the entire environment. If these changes and if the
future field of work and the professional perspective are not communicated
appropriately, this can have consequences for the project. After all, why should
someone be committed to working on a project that eliminates their own work-
place? (More on successful communication can be found in Chap. 5, “The
Underestimated Success Factor: People”).
• Partner/stakeholder of the consulting firm
At a time when many of the key points are still unknown, the project consultants’
superiors must submit an estimate of the costs and effort involved and, depending
on the type of engagement, provide a contractual guarantee. However, in every
SAP project, the effort changes over time (usually it increases). But at this point, a
contractual adjustment is often not possible. To nevertheless complete the project
successfully (read “financially successful for the consulting company”), it is
important to come to a result quickly. Loss of quality can be the result. If
“cheaper” (¼ less experienced) consultants are used, quality can also suffer.
Often there are also discussions about whether certain results are necessary at
all. This is where a sure instinct for a successful project conclusion is required.
286 8 Consultants: Boon or Bane? Benefit or Burden?

• Customer stakeholders
There are also guidelines and budgets for internal stakeholders. These budgets are
often released for a period of time that is shorter than the duration of the SAP
project. Targets may be set based on success criteria that are not necessarily
conducive to the success of the project (such as savings in manpower and
materials).

Note: Everyone Pulls Together

To deal with conflicting objectives, always try to find a solution together with
your partners. No project that has been marred by conflict has yet been
successfully completed. If no solution is in sight, seek external help. Mediators
are more helpful than lawyers. So solve conflicts early!

8.7 Projects with Offshore or Nearshore Teams

International SAP projects are particularly complex and do not stop at borders. In
this section, we look at projects that have outsourced part of the project work to
offshore or nearshore teams.

Note: Offshore and Nearshore

The term offshore is probably familiar to you from the discussion on renew-
able energies. Offshore wind farms are particularly efficient, and, since they
are far away in the open sea, they do not bother anyone. The term has also
become established for (IT) services. Offshore refers to parts of companies,
service departments or software developers that operate independently of the
parent company in a country that offers the desired conditions: sufficiently
large labour force, (good) training, (low) wage levels and possibly subsidies
for the industry in the respective country (tax savings, subsidies, etc.). Off-
shore teams are mainly based in India and China. For projects based in Europe,
nearshore teams are recruited from Eastern European countries, Italy or
Ireland, for the USA recruited form Latin America (Brazil or Mexico) thus
closer to the client in terms of both location and time zone. However, the
advantage of lower costs remains (mostly).

Advantages
Relying on offshore and nearshore teams has been the rule rather than the exception
for a number of years, especially in large consulting firms. There are many reasons
for this: the countries, where these teams are located, usually have a large number of
well-trained experts at their command. Their own economy is often not yet so
8.7 Projects with Offshore or Nearshore Teams 287

developed that these experts are needed in their own country—and therefore, it is
relatively easy to put very large teams together, especially in India and China.

As a rule, the main aim of using offshore and nearshore teams is to reduce costs.
The wage level in the teams’ countries of origin is very low compared to Central
Europe and North America. In addition, many teams mainly do not operate on-site
but from their home locations. Consequently, there are no travel costs, which can
otherwise make up a significant proportion of the project budget.
With the help of offshore and nearshore teams, experts can also be recruited for
special tasks that are scarce in their own country. Since every project also involves a
transfer of know-how, part of the knowledge is transferred to your project.

Challenges
The integration of offshore or nearshore teams but also brings with it a number of
additional challenges:

• Language barriers
Employees with different native languages and different dialects are integrated
into the team. It is often said that the project language is English—and that’s
it. Especially in critical situations in the project, it would often be helpful to be
able to exchange ideas in the mother tongue.
• Time zones
The employees in the offshore centres often work in a different time zone. This
limits the time available for working together on a topic. And the time for replies,
especially in time-critical situations, is often extended.
• Cultural differences
The employees come from a different cultural background and live and work in
this environment. In addition, the corporate culture is often a different one. A lack
of understanding of customs, working styles and other cultural differences can
lead to misunderstandings and conflict.
• Lack of personal contact
Most of these team members are only known in the project through their results.
They communicate little with the project staff on site and are only rarely person-
ally present in the project.
• Lack of influence on project staffing
Often the project is staffed directly by the offshore partner. The knowledge
required as per the project profile and the actual skills of the employees do not
always match. Often it is not possible for the project manager to select the team
members themselves based on their professional and personal aptitude. (We do
not share the belief that this is not necessary.)

Taken from Project Life:

We would like to illustrate these challenges with three examples from our projects.

In a project in the Middle East, a large part of the project team came from India
and a few additional colleagues from Pakistan. The project language was English.
288 8 Consultants: Boon or Bane? Benefit or Burden?

The language of the Asian team was also English. At the beginning, we thought that
out of consideration for us Europeans, the colleagues would not speak to each other
in their own language. But there are not even two of the colleagues from India and
Pakistan working on this project who speak the same mother tongue or dialect. The
lingua franca is indeed English.
Everywhere, there are hierarchies in coexistence that do not stop at the company
gates. In one of our projects in India, however, massive problems in communication
arose due to the still existing system of castes and the many independent languages,
although the employees are basically very well trained and also open-minded. The
problem is not necessarily the hierarchy as such, because the colleagues are quite
willing to communicate with each other. Rather, there are perceived barriers to
communication among the project staff. This could be compared to the feeling you
get when you meet a former teacher years after graduating from high school and still
feel self-conscious.
In one case, an employee of a company from the Middle East was assigned to our
project practically overnight. This was easy as there was no notice period and not
even a formal termination. Due to the working environment in some countries,
loyalty to the company is not very high, and together with very loose employment
contracts, there is sometimes a high turnover of project staff. In this case, this has
worked in our favour. In general, however, every employee who leaves the project
takes know-how with him/her, and knowledge cannot be passed on easily. There-
fore, such a high fluctuation is not conducive to the success of the project.

Note: These Germans Are Crazy?

That the cultural characteristics of a project partner can lead to
misunderstandings naturally applies to both sides. In an international project,
it is often helpful to be aware of the communication rules and expectations that
are anchored in your own heads. In other countries, for example, Germans are
often perceived as too matter-of-fact and direct to the point of being rude.
We have also made this experience in our projects and learned from it. The
well-intentioned phrase “this won’t work”, for example, is understood as a
sign of stubbornness. A critical remark is perceived as much more constructive
in a formulation à la “let’s look at the pros and cons again”. It promotes the
success of the project if greater attention is paid to the relationship level in
communication.

Nothing but Problems: Really?

If you follow some basic rules, a project with an offshore or nearshore component
can be successful. Some of the basics are as follows:

• Schedule reaction times.

An active and forward-looking management and monitoring of outsourced proj-
ect activities is necessary. In any case, make sure you expect and plan for longer
8.7 Projects with Offshore or Nearshore Teams 289

reaction times (if only because of the time difference) and direct feedback on the
respective tasks you have assigned. You would not be the first project manager
who notices after a few days that a task that should have been finished has not
even been started.
• Define clear responsibilities.
Defining clear responsibilities is essential. In each of your sub-projects, where
tasks are handed over directly, and of course in the PMO, colleagues must be
made directly and personally responsible for communication with the centre
leadership. The assumption that someone will sure take care of this has never
worked before—especially not in a constellation where the person opposite is
located half-way around the globe. It is helpful to anchor outsourced teams firmly
in the overall project and, if possible, to assign team leads to their areas of
responsibility—then they feel more part of the project and also responsible for
the results.
• Carefully estimate efforts.
Communication, documentation and management mean additional effort that you
have to plan and implement. Especially the colleagues from sales or purchasing,
who plan and approve the budgets for SAP projects, like to calculate the total
budget by using employees from offshore or nearshore centres and calculate
according to the motto: the more people work offshore, the smaller the budget.
But the formula “a colleague on site is replaced by a colleague offshore, and we
have already reduced the cost rate for this employee by at least 50%”, does not
work like that. You need additional resources on both sides to organise, translate,
write documentation, etc.
• Keep critical areas with local teams.
You should outsource tasks relating to data protection (e.g. the legally binding
principles of the European Data Protection Directive) as well as labour law issues
and areas affecting corporate culture only with caution.

Note: Project Staffing

If you contract a large consulting firm, in most cases, offshore and/or near-
shore teams are by default part of the SAP project team. Many consulting firms
have now set up their own divisions or national companies, for example, in
India and China, simply because of the good training opportunities and the
number of potential employees.

In SAP projects particularly, technical sub-projects are outsourced, such as the

following:

• Software development (i.e. reports, interfaces, conversion programs for data

migration, migration programs, SAP enhancements)
• Data migration (both developing the programs and executing and monitoring the
data migration)
290 8 Consultants: Boon or Bane? Benefit or Burden?

Program
Sponsor

Execuve
Advisory Boards
Steering
Commiee
SAP

PMO Off-shore
Overall Project Communicaon
Technology

Executive
Funconal Funconal PMO
Leadership Team Outsourcer
Team FI/CO Team SD/MM

Regional
Leadership Teams
Development- Migraon-
Team Team

Fig. 8.2 Project organisation with offshore component

• Tests (here especially recurring tests or automated test sequences)

• SAP system operations

Customising; developing integration architectures, e.g. interfaces; implementa-

tion of services; EAI systems (enterprise application integration); as well as
activities within the scope of going live (especially for global rollout projects) can
also be realised offshore. Various consulting companies and service providers have
specialised in specific applications and have gained a lot of know-how in numerous
projects. In some consulting companies, certain services are now only available off-
or nearshore.
Offshore and nearshore projects are usually organised virtually. For each
outsourced area (in many cases complete sub-projects), there are sub-project
managers, a local PMO, a separate resource management and a separate controlling
in the offshore or nearshore centre. Figure 8.2 shows how a project organisation with
an offshore part could look like.
Additional project roles need to be filled both on site, i.e. at the company to which
you have outsourced project parts, and in the main project. The roles on the service
provider side are not always transparent for you as project manager.

Shadow Project Management

The offshore or nearshore partner often has a complete and independent project
organisation with all its inherent complexities. You therefore establish a kind of
shadow project management in the offshore centre, which may be a black box to
you. Even if this does not seem to have much influence on your project management,
its importance for the success of the project should not be underestimated.
8.7 Projects with Offshore or Nearshore Teams 291

The offshore partner carries out the following tasks:

• Project Management
Controlling and communication are independently regulated in the offshore
centre. Close cooperation with the project management on site is a must.
• Change Management
All changes to business processes and system architecture made by the offshore
centre must be documented, approved and budgeted. The change management of
the project must therefore be extended to the offshore centre.
• Resource Management.
As you may not have direct access to the project team in the offshore centre, you
will have to rely on their resource management. For this reason, close cooperation
is recommended. It often helps to locate part of the resource management from the
offshore or nearshore centre in your PMO (also physically on site). The urgency
of an enquiry becomes clearer this way than via a phone contact.

There should also be project roles in your local team that are responsible for
managing the offshore team. These team members are responsible for establishing
communication structures and cooperating with the staff of the offshore teams. Staff
in resource management must implement the requirements of the colleagues working
in the offshore teams. Ideally, members of your project team should know the
responsible colleagues on the offshore partner’s side personally.

Note: Documentation: Even More Important Than Before

The colleagues in the offshore teams work on the basis of the documentation
created by your project team. Perform quality control of these documents
already in the central PMO! For this, you need experts who are highly skilled
in the languages used as well as in the functional and technical requirements.
Please note that each question that arises during the review may lead to a delay
in the schedule due to time differences and language problems. Please factor in
sufficient time for the documentation. It will provide you with valuable
services in the final phase of the project and afterwards. However, sloppy
documentation costs extra time and money at the end of each project.

In probably every current project, there is a discussion about expanding the team
with employees or sub-teams who are not sharing an office with your project team.
The reasons range from a lack of skills to a lack of personnel to a lack of budget. This
form of team expansion can be very useful for your project, but keep in mind that this
also increases the effort.
In the next chapter, we turn our attention from the people who support your
project to the IT tools you leverage to make your project a resounding success.
Project Support Tools
9

In the previous chapters, we have already mentioned at various points that there are a
number of tools available to support your SAP project. In this chapter, we give you
an overview of useful tools that can help you in all project phases. We show you
tools for the following:

• Project management
• Business process management
• Testing
• Support during operation

Our selection does not claim to be exhaustive: experienced SAP project managers
usually have their “favourite tools”—which one is particularly suitable for you
depends to a certain degree on the project environment. We focus our attention on
proven tools. In addition, there are numerous current tools for different needs. To
ensure that you can also use these tools, we give you recommendations for further
reading in this chapter.
Ultimately, however, the successful use of a tool always depends on the
employees who must have the necessary tool knowledge and the will to leverage
them to their full potential.

9.1 Project Management Tools

The management of SAP projects is a relatively complex task, and project manage-
ment tools are helpful in mastering it. Every project requires tools that support
project management and the project management office (PMO).
What tools are involved in complex SAP projects? In our experience, there are
clear favourites in terms of frequency of use:

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 293
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_9
294 9 Project Support Tools

• Microsoft Project
• Microsoft Word
• Microsoft Excel
• Microsoft Outlook/Exchange
• SAP Solution Manager

Note: Why Only Microsoft Products?

Are you surprised by this selection? Probably not. And this despite the fact that
project management software is a dime a dozen. Many of these tools provide
support for resource planning, project controlling, risk management, schedul-
ing, quality management, status reporting and much more. Apart from
Microsoft Project, Microsoft tools are already available everywhere. Everyone
involved in a project—from department heads, project managers, stakeholders
and consultants to technical experts—is familiar with these tools and can use
them. An unbeatable advantage.
Many project managers don’t spend much time thinking about what they
could achieve with the right tools for their project. And if they do, it often
means that in the turbulent initial phase of an SAP project, another new tool
would have to be introduced—no way!

Note: Microsoft 365

Microsoft Office is now Microsoft 365, and the good old Office package has
rigorously—and even more exclusively than SAP with S/4HANA—made its
way into the cloud. Without ifs and buts and with very few exceptions,
Microsoft Office and Microsoft Project are now only available as cloud
versions. You can still install a local copy on your PC, but nothing works
without a Microsoft account. This certainly has many advantages (such as the
tiresome issue of compatible versions in large projects). Some people find the
occasionally requests for passwords and the constant suggestion to store the
files in the Microsoft Cloud (OneDrive) annoying.

In the following, we will take a closer look at these tools.

9.1.1 Microsoft Project

Microsoft and SAP: A Success Story?

Microsoft Project is a software for planning, controlling and monitoring projects.
The software provides functions for schedule management, resource management,
project monitoring and reporting.
9.1 Project Management Tools 295

In our opinion, Microsoft Project is the tool of choice for the documentation of
project planning. The simple reason for this is that the tool is widely used and quite
powerful. A server version of Microsoft Project is also available, which means that
different planning statuses can be stored in consolidated form and several planners
can work on the overall planning simultaneously.

Server Availability
But be careful—setting up this server version is not very easy, and if the server is not
available (according to the motto “It’s only a project system, we don’t need backup
and high availability for that”), neither planning nor reading the plan is possible. And
that becomes a huge problem after a few hours. If this happens regularly, the fear of
such cases leads people to keep a “current” copy of the plan on their computer—and
in the end, nobody knows the really current status of the planning. Since some
employees have no experience with Microsoft Project, partial plans are outsourced to
Microsoft Excel. This makes it very difficult to manage an up-to-date overall
planning. This is where you as a project manager are challenged to ensure that the
tool is used correctly and consistently throughout the project.

Note: Project Management with Solution Manager

The current Solution Manager also offers functionalities for planning and
managing projects. Version 7.2 adds SAP portfolio and project management
features. Just as with MS Project, you can define projects, plan deadlines and
resources, track the status of the project and display results. Comprehensive
reporting is also a component of SAP portfolio and project management in
Solution Manager. A great advantage is the deep integration into the other
areas of SolMan (e.g. the link to the results documentation from the SAP
Activate methodology). It remains to be seen whether Solution Manager can
replace MS Project as the standard tool in SAP projects in the long term.

9.1.2 Microsoft Word

Microsoft Word is by far the best known and most widely used word processing
program in the world. Word is mainly used for writing documents such as process
descriptions, interface documentation and change management.
The great advantage of Word is that it is easy to use and is familiar to every
employee in the project. Word is also very suitable for meeting minutes and
documents that distribute information.
Problems arise from the decentralised creation of documents, often in a team.
Clean documentation is only possible here through accurate work and strict adher-
ence to rules. Especially at the end of the project and in critical situations, sometimes
the rules and standards are not strictly followed, leading to problems: Older versions
are then sometimes accidentally updated, work is done on documents in parallel, and
296 9 Project Support Tools

local copies are used that are not available to colleagues later on. Probably every
(SAP) project manager has experienced such situations.
Microsoft with SharePoint is increasingly used for document management in
projects. The big advantage is the seamless integration with the other Office
365 products. The integration with MS Teams facilitates collaboration and reduces
the need to distribute documents, which may lead to “version confusion”. However,
the use of SharePoint is not always intuitive, and even with SharePoint, it requires
great discipline to manage the many documents in the project.

Tip: Document Management

Use strict document management with appropriate naming conventions and
versioning. The aim is to find the current versions of important documents in
the project management office at any time.

The tool’s ease of use and high availability often make Word the tool of choice,
despite all the foreseeable problems. In addition to Word, similar products are
available, for example, from the OpenOffice range or the text editor “vi” for Unix
experts. There are other tools available for a thorough documentation of a complex
SAP system with business processes, architecture and a corresponding user manual.

9.1.3 Microsoft Excel

The Microsoft Excel spreadsheet program is the first choice for creating lists. Excel
is used particularly frequently for lists, such as the list of interfaces, RACI matrix or
simple planning. Also, parts of the overall planning are often “designed” in Excel
and possibly later transferred to Microsoft Project.
The advantage in this case is again the simple operation and good availability. As
part of the documentation tools, Excel is not missing in any project. Disadvantages
are the local storage (which can be avoided; see the remarks about SharePoint above)
and the fact that there is no automated versioning of the documents.
Excel is more than just a spreadsheet: more complex calculations can be
automated using the macro-programming language Visual Basic for Applications
(VBA). This makes it very easy, for example, to keep the cost estimates for the
design, development, documentation and testing of interfaces up to date.

9.1.4 Microsoft Outlook/Exchange/Outlook 365

Most of the communication in the project takes place via groupware, such as
Microsoft Outlook (alternatively via Lotus Notes). Outlook is used in the SAP
project for e-mail and appointment management. To get the most out of all the
functions of Outlook, it is necessary to operate an Exchange server. Thus, for
9.1 Project Management Tools 297

example, meetings and other appointments with several participants can be planned.
The appointment calendars of all participants can be compared, and possible
overlapping appointments can be displayed. The fact that you can use Outlook on
smartphones is also very useful, because appointments can be entered, or reminders
can be sent out while on the move.

10 Tips for E-Mail Communication

E-mails are a great invention. However, anyone who has ever been exposed to
a flood of partially meaningless e-mails in a large project will know the
following problem: in large projects, it is not uncommon to receive up to
500 e-mails per day. This quickly eats up the whole working day just for
reading and keeping up.
Therefore, please observe the following golden rules when emailing:

1. Keep it short and provide clear and understandable information.

2. If possible, only deal with one topic at a time in an e-mail.
3. Use meaningful subject lines so that your message can be easily allocated
and found again.
4. Only put those persons on cc who should or would like to have explicit
knowledge of the e-mail content.
5. If necessary, ask explicitly for a reaction to your e-mail: “Please give me
feedback by ...”.
6. Stay objective and friendly, even when things are stressful.
7. Respond quickly to important messages (with an intermediate status if
necessary), and delete unimportant messages right away.
8. Avoid attachments that are too large. Rather send links to files located on
SharePoint.
9. Only flag urgent e-mails as important.
10. Sometimes using the telephone is more effective and faster. Most
problems can best be solved in a direct conversation. This is often the
best way to quickly put an end to a seemingly unsolvable problem in
e-mail traffic.

9.1.5 Shared Network Drive

A shared network drive is still widely used as a filing system for project documenta-
tion. At the end of a project, the drive sometimes contains several gigabytes of
information and becomes very confusing.
298 9 Project Support Tools

Tips for Document Management

The better alternative to simple file folders is a document management system
(DMS). Here documents are stored in versions and on specific topics. In
addition, an index is often possible, which makes searching easier. However,
a DMS can be costly and requires additional effort for operation.
Network drives (or folders in the cloud) will continue to play a role in the
project. A few rules for their use are as follows:

1. Define the folder structure at the beginning of the project.

2. Establish firm rules on who is allowed to change this structure.
3. Current versions of documents are always stored on the share.
4. Regulate the file access on the share (who can do what, read, write, change,
delete).
5. Make sure that the share is regularly backed up.
6. The share must be available and accessible to anyone who needs it.
7. Documents need to include a version number and information about the last
change.

A major advantage of Microsoft’s tools, apart from their widespread use and ease
of operation, is their good integration with SAP Solution Manager and the SAP
architecture in general.

Note: Microsoft Office and SAP Solution Manager

Professionally managed projects use SAP Solution Manager as a repository for
Office documents, making them much easier to find. Otherwise, countless
versions of different documents can be floating around on local hard disks or
various network drives. (For detailed information on SAP Solution Manager
as a project management tool, see the following Sect. 9.1.6, “SAP Solution
Manager”.)

In summary, the following can be said: in most projects, we find either products
from Microsoft or comparable products such as OpenOffice or Lotus Notes to
support project management (planning, documentation, groupware, etc.). The
reasons for this are good availability, ease of use and wide distribution.
It definitely makes sense to leverage professional project management tools in
SAP projects—but this is done too rarely.

9.1.6 SAP Solution Manager

SAP Solution Manager has played and continues to play a central role in every SAP
project. SAP Solution Manager is often used in SAP projects as the central tool for
9.1 Project Management Tools 299

SAP Soluon Manager SAP Value Assurance

• Infrastructure Provisioning • Safeguard transion to SAP
SAP Value Assurance Services
• Coordinate End-to-End Service S/4HANA with Value
Delivery Assurance Services
SAP Soluon Manager

S/4HANA Transion Roadmap

SAP Best Pracces

Digital Core
S/4HANA

SAP Best Pracces for S/4HANA SAP S/4HANA Transion

• Ready-to-run business Roadmap
processes (and integraon & • SAP Acvate Roadmaps for all
migraon) from SAP Acvate scenarios
• Opmized for S/4HANA • Agile implementaon support

Fig. 9.1 SAP Solution Manager and SAP Activate

the entire life cycle of the SAP landscape. With SAP S/4HANA and the current
implementation method, Solution Manager will become even more important.
Solution Manager is used to deliver the entire “content”—i.e. the “knowledge”
delivered with Activate. The “big picture” of what Activate and Solution Manager
can contribute to the success of a project is shown in the Fig. 9.1.

Note: IT Infrastructure Library

SAP Solution Manager adheres to the specifications of the ITIL method. ITIL
stands for IT Infrastructure Library and is a collection of procedures for IT
service management—de facto a standard in IT.

With SAP S/4HANA, the role of the Solution Manager within an SAP project has
grown once again. The entire project life cycle according to SAP Activate is
accompanied by SolMan. In this section, we will only deal with those functions of
the SAP Solution Manager that in our experience play an important role in project
management. Often SAP Solution Manager is only used as a point of integration
with other tools in project implementation, for example, for testing and system
administration (see Chap. 3, “The SAP S/4HANA Project: How It Should Be”).
First, we would like to give you a brief overview of the tool.
Figure 9.2 shows the SAP Solution Manager support during the life cycle of an
SAP landscape.
SAP Solution Manager is the central instance of every productive SAP landscape,
and also of every SAP project.
With the current version 7.2, Solution Manager has become a very mature
product. The integration of functionality from SAP’s CRM and further development
in many areas (project management, business process management, testing, etc.)
mean that Solution Manager could increasingly become the central point for SAP
S/4HANA project management. It remains to be seen whether you, as a project
300 9 Project Support Tools

SAP Acvate and SAP Soluon Manager

Discover Prepare Explore Realize Deploy Run

QG QG QG QG QG

Operate,
Fit-Gap based on Scope and Migraon, Integraon, Onboard and
First Steps Monitor,
Model Company Configuraon Extension, Test Deploy
Support

• Role-based first • Ready to run • Soluon scoping and • Configured and • Geng Started and • Handover of
steps on Business processes content acvaon prepared best pracces Guided Tours SolMan to the ops
preconfigured opmized for S/4 • Easy acvaon of best for migraon • Embedded training team for
business cases and • Model Company pracces through self- • Automated tesng with and documentaon Monitoring Change
preconfigured with Org Structures service acvaon pre-defined test scripts for easy on-boarding Management
Soluon Manager and Master Data • Fit/Gap analysis instead • Extensions with expert of end users Support
• Quality Gates (QG) Ready in SolMan of complex Blueprint configuraon • Controlled SW
aer each phase • Set-up of the • Product backlog is • Agile development and logiscs
with checklists in SolMan managed in SolMan configuraon workflows • Integraon with SAP
SolMan • Ramp-up project Learning Hub
team and business • Go-Live
readiness

Fig. 9.2 SAP Solution Manager support for SAP Activate

manager, project member or decision-maker, will in future rely more on SAP’s

services or those of other providers.
What is the role of SAP Solution Manager in project management? On the one
hand, it offers the possibility to connect all external tools: be it documents in
Microsoft Word, Excel or PowerPoint or the business process hierarchy from a
process management tool or the MS Project-based project plans.All these documents
can be stored centrally and assigned to the right work package. In addition, the
documentation of the development objects (interfaces, data definitions, extensions)
can be stored here and linked directly to the corresponding program. This comes
pretty close to a document management system. At the end of the project, this
information becomes useful documentation for the line organisation.
As already mentioned in the subchapter on Microsoft Project, Solution Manager,
with the current version 7.2, itself offers functionalities for project implementation.
And finally, Solution Manager provides all the nice implementation tools like
Model Company and SAP Best Practices.

Note: A Project Within a Project

SAP projects can be compared to “Matryoshka Dolls”: often there is still a
project in the project. The introduction of SAP Solution Manager or its
adaptation to the respective SAP project requirements is thus a separate SAP
project. An appropriate framework, resources, time and budget must be
provided for this project.

Like any SAP system, SAP Solution Manager covers a wide range of application
areas. Here too, standard scenarios are specified, which can be individually
configured as required. These scenarios, like the business processes in ERP or in
the SAP Business Suite, are preconfigured in SAP Solution Manager and can be
9.2 Tools for Business Process Management 301

Table 9.1 Example scenarios supported by Solution Manager

SAP Solution Manager Scenarios
Implementation based on SAP • SAP Activate: method and accelerators
Activate • Support for agile development methods
• Quality gates and archiving of documents
SAP operations and monitoring • Central system monitoring and alerting
• Monitoring of business processes and integration
• Technical administration and troubleshooting
SAP IT service management • IT service management based on SAP CRM
• Ticketing system integrated with SAP services and
support
• Centralised IT service management based on ITIL
SAP test management • Cross-system test management
• Test planning and execution
• Test automation
SAP business process management • Specification and modelling of business processes
• Administration of business processes across system
boundaries
Change request management • Complete, workflow-based process for changes
• User and role based
• Synchronisation across system landscapes

adapted to the respective project requirements. The scenarios shown in Table 9.1 are
required in almost every SAP project.

Note: Further Information About SAP Solution Manager

For more information about SAP Solution Manager, see the following books:

• SAP Solution Manager, Das Praxishandbuch by Markus Bechler, Andreas

Hömer, Michael Markert, Marco Michel, Jan Rauscher, Timo Steinsberger
(SAP Press, Bonn 2017)
• SAP Solution Manager für SAP S/4HANA by Marc O. Schäfer, Matthias
Melich (SAP PRESS, Bonn 2016)

9.2 Tools for Business Process Management

Business process management (BPM) plays a role in almost every SAP project.
Business process management focuses on the methods and tools for the design,
implementation, realisation and operation of business processes.
In an SAP project, these are all processes that are implemented for the company in
the SAP system, and we can take it even further. In most cases, the business IT not
only consists of SAP components. We could therefore also map the overall picture of
our process landscape in BPM (Fig. 9.3).
302 9 Project Support Tools

Data Entry Clerk Legacy system S/4HANA Business Partner

create new
enter data
contract

Check plausibility

business partner Business Partner

search/find search/find

Business partner
synchronisation
set collection save collection
data data

search/create
set bank data
bank data

create
contract/quote

save save
contract/quote contract/quote

Fig. 9.3 Process “new contract creation”, visualised with Microsoft Visio

The traditional approach to business process management is based on tools such

as Microsoft Word, PowerPoint or Visio. The processes are described verbally and
then visualised—usually in an overview.
This has the great advantage that those who develop and define the processes can
also document them immediately. Up to a certain degree of complexity, this is in fact
an advantage. However, above a certain project size, it becomes overwhelming and
confusing.
Alternatively, there is the possibility of using a BPM tool. BPM tools boast the
following features; the list of tools offered is long:

• Business processes
Optimisation of business processes with real-time transparency of ongoing work
through constant process monitoring and analysis
• Governance
Optimising change management and improving the security of the operation of
the process landscape through intuitive governance.
• Monitoring
Continuous insight into operations by seamlessly combining business processes
with central enterprise systems.
• Modelling
9.2 Tools for Business Process Management 303

Business process modelling and process analysis are designed to ensure that the
various roles involved in continuous improvement activities perform their tasks
as efficiently as possible.
• Simplicity
Thanks to state-of-the-art weaving technology, processes are designed in no time
at all. The business processes and the IT map can be modelled quickly and easily.

Note: SAP and BPM Tools—It’s Complicated

In our opinion, the reason why non-SAP tools for BPM have received little
attention in the past is that the success of SAP software is largely based on the
possibility of implementing ready-made business scenarios—in other words,
the use of standard software. Over the past 30 years, these scenarios have been
stored in the SAP Business Suite by a large number of SAP software designers
and developers and have in most cases been newly implemented in SAP
S/4HANA.
In short, there is too much knowledge in the SAP system to be documented
or even modelled easily with a BPM tool. We would first have to transfer the
existing SAP system (especially the preset business processes) to a BPM tool
to be able to use it sensibly afterwards.
There are no two SAP implementations that are identical. From our point of
view, nobody knows the possible overall functionality of an SAP system—
without changes to the standard code. The effort to transfer the business
process functionality of an entire SAP system to a BPM tool would be
enormous, and it would simply not be possible to accommodate several
systems there.
With the current version 7.2, SAP Solution Manager has become a tool for
process management. The processes defined in the SAP Activate Framework
as well as integration architectures are supported.

Note: Further Information on BPM

A number of books deal with the topic of BPM. We recommend the following:

• “SAP Process Orchestration und SAP Cloud Platform Integration” by

Marcus Banner, Olaf Glebsattel, Raffael Herrmann, Abdeljalil Labrache,
Christian Niermann (SAP Press, Bonn 2017)
• “Prozessmanagement mit dem SAP Solution Manager” by Michael
Demuth (SAP Press, Bonn 2017)
304 9 Project Support Tools

9.3 Tools for Testing

Testing plays a special role in an SAP project. During testing, we do not only make
sure self-developed programs run, but above all we focus on ensuring the correctness
of the implemented processes, the data, the integration of the individual processes
within SAP and externally and finally also the response times of the system
(i.e. performance).
Testing is also particularly relevant because of the complexity of the solution, the
different data in the system and the many users. As our SAP solution grows and
changes over the course of the project, the requirements for test management and the
tools used also change.
The testing of S/4HANA implementations poses a special challenge because of
the agile approach and working in sub-projects. In the pure “waterfall project”,
testing was meticulously planned before each go-live and times for error correction
and retesting were scheduled. Such a test cycle often lasted several weeks, and test
teams consisting of IT and business experts were involved. With SAP S/4HANA and
more agile implementation methods, functionalities are to be implemented and
subsequently tested in parallel, independently of each other and in sprints lasting
days instead of months. Every SAP ECC test manager is getting grey hair just
thinking about it, because the SAP system is still a monolith—and the functionalities
within it are interdependent. If someone “fiddles with” one functionality, this can
have an impact on other areas, which may also be undergoing further development.
The testing effort increases, and the time required for testing is reduced. This calls
for new solutions!

9.3.1 SAP Solution Manager

If the SAP Solution Manager is part of your project, it is worth thinking about using
the Test Workbench when you are testing. Here, you can:

• Create and manage test plans

• Define and manage test cases
• Put together test cases into test packages
• Assign testers to test cases and test packages
• Use workflows for monitoring the test cases
• Manage status information

9.3.2 CATT and eCATT

One of the most important test tools in the past (and probably one of the best known)
is the CATT or eCATT . CATT stands for Computer Aided Test Tool. The e in
eCATT stands for extended. eCATT and CATT are tools integrated in SAP for the
automation of test cases. The following functions are included:
9.3 Tools for Testing 305

• Testing of transactions, reports and scenarios

• Calling BAPIs and function modules
• Testing of remote systems
• Checking authorisations (user profiles)
• Testing of updates (database, applications, user interface)
• Testing the effects of changed customising settings
• Checking system messages

CATT and eCATT can be integrated into the Test Workbench of the SAP
Solution Manager. eCATT has existed for a very long time and was developed to
test SAP applications in SAP’s own user interface (SAP GUI).
However, these tools are still useful for testing SAP GUI and Web Dynpro
interfaces. In the age of SAP Fiori, SAPUI5 and SAP S/4HANA, this is not enough.
However, since a lot of knowledge is available and especially in upgrade projects to
S/4HANA, old ERP functionality under the new SAP S/4HANA has to be tested, the
partial use is often still useful—even if only temporarily.

9.3.3 Other Tools

SAP Component-Based Test Automation (CBTA) has been developed in SAP

Solution Manager to enable automated testing of both browser-based web
applications and SAP GUI applications. In contrast to eCATT, CBTA records
component-based test scripts, which considerably simplifies maintenance later.
CBTA pursues a more modern approach and is SAP’s preferred in-house test tool.
But here, too, the ravages of time are gnawing away. With the further spread of
modern user interfaces and deeper integration with SAP cloud solutions in addition
to S/4HANA, the use of CBTA is limited.
There are various external, i.e. non-SAP test tools on the market. These are
particularly useful for automated testing across system boundaries. External tools
play a major role, especially in testing. The advantage here is that they can be used
for both SAP components and non-SAP solutions. For SAP testing, these solutions
can be integrated into SAP Solution Manager. Prominent examples are SAP Quality
Center by Micro Focus (formerly HP) or the tools from Rational (IBM).
In the last few years, new players have also appeared on the market in the field of
testing, who have created tools for test support in the SAP environment—and here
especially for SAP S/4HANA—through modern technologies. Two tools from our
own wealth of experience are presented here very briefly.

Tosca from Tricentis

A tool that can test continuously running processes is Tosca from Tricentis. With this
tool, it is relatively quick and easy to set up cross-system test scenarios, which scan
the process in the “background” and report any errors that occur. And this even
works across system boundaries. This technology is particularly helpful in agile
projects as a kind of continuously running regression test. The challenge here is often
306 9 Project Support Tools

to decide what is really an error at the beginning. If such a system (“test machine”)
often sounds a false alarm and tends to generate additional work (e.g. because the
system settings for test integration change), at some point, the desire for automatic
testing turns to frustration.

Worksoft
Another tool with a similar approach comes from Worksoft. With this tool, a similar
concept of “continuous testing” can be implemented. In practice, we have seen this
tool as part of a test factory for a global SAP implementation.

These two tools are certainly only an excerpt from the list of sensible and useful
test tools. As in many places in this book, we report about our own project
experiences. And even with more than 100 years of combined project experience,
you certainly have not seen everything out there.

Note: Further Information on Testing

You can find assistance with testing in the book SAP-Testmanagement, Tests
planen, entwickeln und durchführen by Stefan Huber (SAP PRESS,
Bonn 2015).

9.4 Tools for Operational Support and Software Logistics

SAP Solution Manager is also usually the central tool for operating an SAP land-
scape. Since an SAP Solution Manager installation is required for the subsequent
productive operation of the SAP solution anyway, it is strongly recommended that it
be installed directly at the start of the project. In the following, we show you a
selection of tools for operational support and software logistics.

9.4.1 Transportation/Software Logistic

Every SAP consultant is familiar with the Correction and Transport System or, for
SAP projects with a Java component, the extended Change and Transport System
(CTS+) as the tool for software logistics (i.e. the distribution of customising and
developments across system boundaries). With this tool, you can manage all
customising settings and development objects and transport them within the SAP
landscape.

Change Request Management

In newer releases of the SAP Solution Manager (as of Release 7.1), the ChaRM tool
can also be used. ChaRM stands for Change Request Management and offers, in
addition to the pure transport of programs and customising settings based on the
9.4 Tools for Operational Support and Software Logistics 307

Correction and Transport System, extensive functions for managing changes in the
SAP systems involved. Furthermore, ChaRM includes functions for quality assur-
ance, including the administration of different users for the change process and a
workflow connection. ChaRM is so powerful and sophisticated that a small project
within the project is required for its implementation. ChaRM is part of the SAP
Solution Manager and was developed by SAP. An external tool for transport
management that is frequently used is RealTech’s SmartChange Transport
Manager.

Note: Further Information on Transporting

You can find out more about transport in the book SAP-Änderungs- und
Transportmanagement by Armin Kösegi and Rainer Nerding (4th updated
and extended edition, SAP PRESS, Bonn 2013).

9.4.2 Systems Operations

Computing Center Management System

With the transition to outsourced operations or even cloud solutions, the topic of
system operations has declined in importance and lost its terror.

Large and small providers of S/4HANA Cloud and outsourcing solutions offer
guaranteed availability, guaranteed response times and data security. Since these
landscapes are usually running in virtual hardware clusters, key figures, such as
availability of processes, database capacity utilisation, etc., are only of limited
significance.
Another area that is difficult to manage without tool support is the operation of
SAP systems. With the Computer Center Management System (CCMS), SAP offers
a console for system administration that is available in every SAP system. This
console, in turn, can be operated centrally via the SAP Solution Manager for all SAP
systems involved in the project (or later in the company). The CCMS is usually
sufficient for the operation of SAP systems in the project; for productive operation in
a computer centre, in which other technologies must be controlled in addition to
SAP, additional tools are used.

Monitoring and Alerting Infrastructure

SAP has already introduced the successor to CCMS in SAP Solution Manager: the
Monitoring and Alerting Infrastructure (MAI). MAI is designed to ensure stable and
reliable operation of complex and heterogeneous system landscapes. The tool
contains various metrics and alert types as well as a host of applications that inform
you about problems. Figure 9.4 shows the monitoring of SAP systems in May. The
CCMS will continue to be supported by SAP but will not be developed further.
308 9 Project Support Tools

Fig. 9.4 SAP monitoring and alerting infrastructure in SAP Solution Manager

Note: Additional Information on System Operation

If you would like to deal more intensively with the operation of SAP systems,
we recommend the book Monitoring and Operations with SAP Solution
Manager by Lars Teuber, Corina Weidmann and Liane Will (SAP PRESS,
Bonn 2013).

9.4.3 Master Data Management

SAP Master Data Governance

In this book, we have repeatedly emphasised the importance of data in SAP projects.
SAP offers its own tool for data management: SAP Master Data Governance. SAP
Master Data Governance is integrated into the SAP system as an add-on to SAP ERP
and offers standard processes based on predefined workflows using SAP Business
Workflow and SAP Business Rule Management. This makes it possible to model
data management processes and execute them within the SAP system landscape. It is
also possible to maintain objects with SAP Change Request Management. You can
use the SAP authorisation concept and special input help to control data entry.

Other tools, such as IBM’s InfoSphere Platform, offer a wider range of functions
(such as rules for data cleansing) and can also be integrated into the SAP landscape.
However, the operation of the tools does not fit so seamlessly into the SAP system.

Note: Additional Information on Data Management

If you would like to take a closer look at data management in SAP system
landscapes, we recommend the book (unfortunately only available in German

(continued)
9.5 Minimised Downtime Services 309

at the time of writing) Stammdatenmanagement mit SAP Master Data Gover-

nance by Oliver Lauffer, Jan Rauscher and Rene Zimmermann (SAP PRESS,
Bonn 2016).

9.5 Minimised Downtime Services

In every SAP project, an important requirement of the business process owners is to

keep production downtime during the changeover as short as possible. In the case of
a new implementation, the downtime can last few days to few weeks depending on
the size of the project. For critical and urgent business transactions, an “Emergency
Process” is typically used for this situation, with which the jobs can be administered
manually.
However, larger support packages (so-called OCS Packages, Online Correction
Support) can also lead to downtimes during production operation. Although the
system does not have to be restarted when importing these packages, it cannot be
used productively.
With the Minimised Downtime Services developed by SAP, downtime during the
import process can be reduced for certain objects. These are packages with a high
proportion of “program coding” and “program texts”. The objects are not immedi-
ately activated in the production system. This means that the production system can
continue to be used during this process. It makes sense to import the packages in
larger queues, or, if possible, in a single queue. The use of Downtime Services is
primarily intended for production systems. However, the service is also suitable for
use in test systems to test the downtime of the production system in advance. This is
important! In this case, the test system must be treated in the same way as the
production system during the import process; there are no manual changes to
program objects and no imports of transport requests. It should also be considered
that more memory space is required due to the inactive and active objects in the
database in parallel. Available memory should be about 1.5 times the size of the
packages to be imported.
For development systems and systems in which many transports are continuously
imported, such as QA systems, the use of the services is not recommended due to the
risk of system inconsistency. This also applies to the import process of support
packages in BBP (business-to-business procurement) or CRM (customer relation-
ship management) systems, where manual upstream and downstream activities must
take place during downtime.
310 9 Project Support Tools

9.6 SAP S/4HANA Migration Cockpit

We have already briefly talked about the SAP S/4HANA Migration Cockpit in Sect.
2.5.5. “Data Migration Aspects of the Greenfield Approach”. In this section, we
want to go into the practical application of data transfer in more detail. The SAP
Migration Cockpit supports the process of transferring master and transaction data
from an SAP ERP system or non-SAP system to the SAP S/4HANA system for the
cloud and on-premise version.
But let us first list the requirements for a modern data migration tool, which are as
follows:

• It should be possible to avoid having to manually create extract programs in the

legacy systems.
• Mapping of data structures between source and target systems should be largely
automated.
• It should be possible to easily integrate customer-specific objects.
• The test effort should be reduced by simulation possibilities. Data should not have
to be transferred to the system with every test run. This avoids costly system
“resetting” after each test run. It saves time and effort, and by the way, it has a
positive effect on the project budget.
• The “blackout period” during the final data transfer into the production system
must be kept as short as possible.
• A user manual should be made available for the project staff that describes the
execution of the individual project activities.
• Data selection and data transformation, even between related/dependent objects,
should be possible.
• Comprehensive, audit-proof documentation of all activities performed is a must.

It should now come as no surprise that the SAP S/4HANA Migration Cockpit
meets most of these requirements. The data transfer is carried out either with the help
of files or with the help of staging tables for larger data volumes, such as material
master data or customer master data.
The files are Microsoft Excel XML files provided by SAP for each individual
migration object. The file for the migration object is downloaded and the relevant
data enriched and then uploaded again. The limit for the files of the migration cockpit
is 100 MB. With ZIP files, however, several files can be uploaded simultaneously.
Attention! The total file that can be added to the ZIP file must not be larger than
160 MB. However, for the on-premise version, the file size can be increased to
200 MB. This approach is particularly suitable for transferring smaller data volumes
that are to be loaded manually.

Use of Staging Tables

When using staging tables in the cloud, the migration cockpit automatically creates
tables for each relevant migration object in a staging system. The data can then be
entered into the staging tables either manually or with the support of tools (such as
9.6 SAP S/4HANA Migration Cockpit 311

SAP Agile Data Preparation). Before creating a staging project, you must create a
database connection to an SAP HANA database system. A remote system is
available as staging system. If the data connection “Standard” is used, the staging
tables are located in the local ABAP schema of the SAP S/4HANA system, or a
database connection to an SAP HANA database system can be specified, where the
staging tables can be used.

With the staging approach, the customer must still create extraction programs for
reading data from the legacy systems. However, there are empty templates (migra-
tion templates) in the form of XML files. These files can be maintained via Excel and
can be filled by the customer.

Note: Status App

In the SAP S/4HANA Cloud, the SAP S/4HANA Data Migration Status App
is available for checking the status. Successfully and unsuccessfully loaded
records are displayed. Simulations are not displayed.

Direct Transmission Via an RFC Connection

When transferring data directly from an SAP system, the S/4HANA Migration
Cockpit is connected to SAP ERP or another SAP-supported system via an RFC
connection. The SAP Migration Cockpit is used to select the data according to
specific criteria.

A big advantage of the tool is that you can start with preconfigured objects. For
each migration object, predefined templates in Microsoft Excel XML file format,
which are always up to date, are available in the cockpit. The mapping is done for the
template and the API target structure for on-premise and cloud. As already men-
tioned, migration programs are created for loading the data, so that no separate
program development is necessary, except of course for customer-specific objects.
After simulation runs, the tool shows the fields that need to be corrected.

SAP S/4HANA Migration Object Modeler

Customer-specific objects can also be integrated and adapted using the SAP
S/4HANA Migration Object Modeler. The modeler is part of the migration cockpit
and available in the on-premise version. Customer-specific objects can thus be easily
integrated, as can standard SAP objects that are not yet in the S/4HANA scope of the
migration cockpit. If necessary, customer-specific fields can be added using the
Modeler, provided the fields are available in the API. It is based on SAP “Best
Practice Fields”, i.e. the fields that are used most in the system. In the cloud, SAP
does this for customers. The data can only be loaded using function modules or
BAPIs compatible with the SAP S/4HANA Migration Cockpit. The APIs are
selected in the migration cockpit according to the S/4HANA field contents. The
XML files are always generated from the cockpit and are therefore always up to date
even after upgrades and updates.
312 9 Project Support Tools

The take-away message is, whenever migration activities are coming up, it makes
sense to explore the possibilities of the tool.

• With the preconfigured migration content, the content specific to S/4HANA is

already available, and you can start immediately. Automatic mapping is available
for the file/staging approach between template and target system or for the direct
transfer approach between SAP system and target system.
• All migration cockpit activities are already integrated into the SAP Activate
implementation methodology.
• The project team is guided step by step by means of an operating manual.
• With the Migration Cockpit Modeler, the tool can be flexibly extended.

Note: Additional Information

You can find more information about the SAP Migration Cockpit in the
bookMigrating to SAP S/4HANA by Frank Densborn, Frank Finkbohner,
Jochen Freudenberg, Kim Mathäß and Frank Wagner (2nd, updated and
extended edition, SAP PRESS, Bonn 2021).

9.7 SAP Data Services

ETL (Extract, Transform, Load)

To help solve data migration problems, there are a number of helpful tools in the
SAP portfolio of Enterprise Information Management (EIM). We have had very
good experience with SAP Data Services. SAP Data Services is an ETL tool
(Extract, Transform, Load) that supports the process of extracting data from source
systems and mapping and loading the data. The tool is located outside the SAP
S/4HANA system and can only be used in the S/4HANA on-premise version. In the
cloud, we have integrated the Migration Cockpit in SAP S/4HANA with the
functions described in Sect. 9.6.

Rapid Data Migration

The Rapid Data Migration solution is also part of SAP Data Services. The basis for
the individual process steps is the ETL tool SAP Data Services. The process starts
with the analysis of the data in the legacy systems. Corrections can already be made
in this phase. After the extraction of the data, the actual cleansing starts. This allows
duplicate data records to be deleted and further corrections to be made. The next
step is to validate or compare the data with the configuration of the target system
SAP S/4HANA. Afterwards, the data is ready for the loading process. At this point,
it is safe to assume that the data to be transferred is correct to a high percentage. The
process ends with the reconciliation of the data in the data services repository to
ensure that the data is complete between the legacy and target systems (Fig. 9.5).
9.7 SAP Data Services 313

Fig. 9.5 Rapid Data Migration architecture

Note: SAP Rapid Data Management

SAP Rapid Data Management can be found in the SAP network at rapid.sap.
com/bp (best practices).

SAP Information Steward and SAP Agile Data Preparation

Further support tools from the EIM portfolio for the on-premise version are the
“SAP Data Information Steward” and the “Agile Data Preparation” tools. The
SAP Data Information Steward supports the data correction process with a
web-based application. Agile Data Preparation is used to prepare data from different
source systems for the Migration Cockpit.

Microservices in the Cloud

Furthermore, the cloud version also includes the Data Quality Management Tool—
Microservices. With this tool, for example, customer data can be compared with
information from a business directory and corrected or enriched.

Note: Further Reading

For more information about SAP Data Services and Rapid Data Migration, see
the following books:

(continued)
314 9 Project Support Tools

• Enterprise Information Management with SAP by Corrie Brague, David

Dichmann, George Keller, Markus Kuppe and Philip On (2nd updated and
extended edition, SAP PRESS, Boston 2014).
• Migrating to SAP S/4HANA by Frank Densborn, Frank Finkbohner, Jochen
Freudenberg, Kim Mathäß and Frank Wagner (2nd updated and extended
edition, SAP PRESS, Bonn 2021)
12 Commandments for a Successful SAP
Project 10

When we got together to distill the key success factors for an SAP project in general
and for an SAP S/4HANA project in particular from the wealth of possibilities, we
had a lively discussion. What the people involved in SAP implementation consider
to be the most important is highly variable and quite individual. Depending on
whether you are a department head, program or project manager, SME, trainer,
consultant or user, you will have a different perspective and consequently a different
view on the project.
If we had tried to create a ranking, we would probably still be discussing today
which commandment is the most important and why. Therefore, we have refrained
from a prioritisation in the form of a numbering of the commandments presented
here. The order of these recommendations is purely coincidental. Please understand
our 12 commandments as our common and personal collection of interesting facts
from more than 100 years of project experience.
Of course, there could also be a 13th, 14th or 15th commandment—our list was
initially much longer. And ultimately, no two SAP projects are alike! How you apply
our commandments depends on you and your project. You will make your own
experiences in your SAP project—we hope that these 12 commandments and our
book can help you to make it a positive experience.

Make Sure that Everyone Sees Change as an Opportunity!

The business processes in your company should support the company goals, and
your project must serve to improve these business processes. The resulting changes
in the company must be supported by the management and accepted by everyone
involved. A mature and well-thought-out change management concept is therefore
an important prerequisite for the successful implementation of an SAP system.

Know Your stakeholders!

All those who favour or have the power to negatively influence the project are
stakeholders! Identify your stakeholders, and involve them in your project as early as
possible. Communication is key here to build trust and enlist support.

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 315
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4_10
316 10 12 Commandments for a Successful SAP Project

Remember: The Project Team Members Are the Most Important Asset!
Keep the following in mind: the people who work on your project will only become
a success factor if they are treated and valued as an important resource. Ensure that
all project staff can fulfil their roles and contribute to the project’s success.

Good Project Management Is Key!

The selection of the right project management, both professionally and personally, is
crucial for the success of the SAP project. Your project manager must have experi-
ence with SAP projects and possess persuasiveness, leadership skills and an eye for
the big picture. He/She should be able to keep a cool head under stress and
understand how to create a good project management culture within the company.
He/She must also have a knack for selecting the right tools and their use.

Put Together a Strong Team!

Ensure the quality and continuous availability of the required know-how and
manpower. The right staffing of the project team is a management task of the highest
priority. The business units are usually reluctant to give their best team members to
the project. But, the qualification and experience of the people in the project with
regard to the SAP system, the business processes, the peculiarities of your industry,
the project management as well as the leadership skills are important building blocks
for the success of the project. Don’t forget: motivation and teamwork are important
factors for success!

Out with the Old: In with the New!

The decision to implement SAP implies that it is necessary to part with individual
business solutions to be able to benefit from the advantages of the SAP standard. Not
much is gained when SAP becomes just another puzzle piece in a heterogeneous and
unnecessarily complex system landscape. Also it is important for the success of an
SAP project to make only as few adjustments to the SAP standard as necessary.

Create Structures, and Make Sure They Work!

Ensure that you have a resilient project infrastructure that meets the requirements of
an SAP project. Select the right methods and tools for the SAP implementation
before your project gets underway. Also ensure continuous project controlling,
e.g. in the form of reviews and proactive risk management.

Lay a Solid Foundation for Your Project!

Allow sufficient time for the design phase of the project. Only a thorough evaluation
and use of the possibilities of the SAP system can ensure a successful project. Resist
the temptation to have consultants build a tailor-made solution when SAP offers
something comparable as part of the standard. Minimising the development effort
saves time and money during the project and for years to come.
10 12 Commandments for a Successful SAP Project 317

Put Changes Through Their Paces!

The project content (scope) and the processes to be implemented must be clearly
defined and accepted by all parties involved. Ensure that changes may only be
implemented after careful economic consideration with a cost-benefit analysis. A
continuous and strict requirements management is a must to keep “scope creep”
under control.

Do Not Build Sand Castles in the Air!

The deadlines for project implementation must be realistic and comprehensible for
each project phase. Regular, standardised plan/actual comparisons allow project
progress to be tracked and help you recognise deviations from the plan in good time.

Use the SAP S/4HANA Standard Software As Far As Possible!

The new SAP S/4HANA business software is constantly evolving. Currently, the
cloud is updated four times a year, and an on-premise version is released once a year.
Stay as close as possible to the standard so that you don’t miss out on the innovations
coming your way.

Look for the Right Partners!

One of SAP’s recipes for success was and is the community—experts in the
companies, consultants, developers and project experts everywhere and for every
topic. SAP S/4HANA does not yet have such a broad range of expertise. Make sure
that you have the right (and literally proven) experts in the project. If someone is not
fulfilling your expectations, give them clear feedback and a second chance, but not a
third, fourth and fifth. Think of the opportunity cost if you waste too much time
hoping that the performance will improve.
Glossary

ABAP Advanced Business Application Programming.

ABAP Workbench Integrated Development Environment for software in SAP
systems.
Activate Implementation method developed by SAP for SAP Software projects
(esp. S/4HANA). Successor to ASAP.
Add-on Additional functionality that is not part of the SAP standard, which is
developed and distributed by software providers other than SAP.
Agile Data Preparation Tool Supports the preparation of data from source
systems for the Migration Cockpit.
Agile project management method Methodology for increasing the speed of
change in project management, which should lead to a faster introduction of
systems. Especially suitable for projects where requirements may change fre-
quently during the course of the project
AI applications Artificial intelligence applications, Software products that have the
ability to “learn” and adapt over time.
Analytical competence Skills that required to understand complex situations, to
develop, improve and apply solution models and to structure the current (project)
situation according to these models.
Analytical measures for quality assurance Quality reviews, process walk-
throughs, program inspections, audits, tests.
API Target Structure Application Programming Interface (API)—technology
from the interface management. Enables the connection of at least two systems
or programs via a standardized program interface.
Application Link Enabling (ALE) Proprietary middleware technology used to
transfer masterdata and transactional data between SAP systems.
ARIS Tool Set or ARIS Platform Tools for designing/modeling business pro-
cesses and the associated IT architecture. Distributed by Software AG.
ASAP Accelerated SAP: Standard implementation method of SAP up to 2013.
Replaced by SAP Activate.
ASE Adaptive Server Enterprise. Relational database management system (devel-
oped and distributed by SAP) for mission-critical, data-intensive environments.

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 319
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4
320 Glossary

Authentication The process of verifying the identity of a computer user to allow

access to a system or data.
Availability of resources Description of the degree to which an employee is free
and can be deployed in terms of time, location and capacity.
BAdI Business Add-In is an enhancement to the standard version of the SAP
System. BAdIs are created to accommodate requirements too specific to be
included in the standard delivery.
Baseline configuration Initial configuration of an SAP system. Prerequisite for
every SAP implementation project. Part of the ASAP/Activate methodology.
Best-of-Breed Systems Special applications for individual company divisions,
which are considered the best applications available for their particular purpose.
Best Practices Here: proven functionality of an SAP system. Sum of the
experiences of various similar SAP projects. Also: List of accelerators and tools
available in SAP Best Practices Explorer
Big-bang Immediate replacement of all legacy systems that are in scope of the
project when the new system goes live.
Big Data Refers to the processing of large and complex data sets.
Bottom-up approach Here: Planning project activities from detail to the whole
(inductive approach).
Blackout period Downtime during an SAP implementation.
Brownfield Migration of an existing ERP Business Suite to an SAP S/4HANA
System (System Conversion) in which data and configuration of the previous
system are preserved.
Business Add-in (BAdI) SAP extension technology. Positions predefined by SAP
to link your own developments (own program code) ! User Exit.
Business Application Programming Interface (BAPI) Interface in the SAP sys-
tem to which certain business rules are linked.
Business Blueprint Phase 2 of the ASAP method. Written description of the
business processes to be introduced and the corresponding architecture. Basis
for the IT solution to be implemented. Equivalent phase in Activate ! Explore
Phase
Business intelligence (BI) Collective term for processes that are used to evaluate
data available throughout the company. These evaluations are made available to
users as reports for decision support. BI data is often stored in a ! data
warehouse.
Business Process Management (BPM) Deals with design, modeling, documenta-
tion, implementation, and improvement of business processes. Here also as a
method for optimizing business processes in IT.
Business Process A series of interconnected steps that lead to a defined result and
are executed in a business environment. SAP applications support typical busi-
ness processes such as invoicing.
Business Technology Platform The Business Technology Platform is technical
foundation for the Intelligent Suite, offering integration, extension, and data-to-
value from all SAP and third party application and data assets.
Glossary 321

CATT/eCATT (extended) Computer-Aided Test Tool. SAP tool for executing test
cases.
Central Processing Unit (CPU) Processor of a computer.
Change Control Here: Requirements management during the project duration.
Identifying, evaluating and deciding on scope changes after the project start.
Change Request Management (ChaRM) SAP tool, integrated in SAP Solution
Manager, that supports the implementation of changes (software and
customizing) in SAP systems.
Chief Information Officer (CIO) Chief IT Officer of a company.
Cloud Computing On-demand availability of IT infrastructure and computing
services (data storage and computing power) from data centers over the Internet.
Computer Centre Management System (CCMS) SAP’s own tool for operating
SAP systems.
Computer-Based Test Automation (CBTA) SAP’s own test tool (successor of
(e)CATT).
Communication Skills The ability to communicate in a goal-oriented, construc-
tive, effective and conscious manner.
Communication plan The communication plan contains the dates/frequencies for
status meetings, for higher-level meetings (steering committee, stakeholders) and
the dates and addressees for status reports.
Communication structure The structure of information exchange within a system
(team, organisation).
Constructive measures of quality assurance Quality assurance through methodi-
cal procedures, guidelines, standards, checklists.
Cost trend analysis Comparison of the actual and planned costs as well as the
projection of the expected costs until the end of the project.
Contingency Planning A plan created to manage outcomes other than the expected
plan. Part of risk management and often used to handle risks with severe
consequences.
Critical path Special network planning technique to systematically plan and mon-
itor projects. The sequence of the longest dependent project activities from start to
finish determines the critical patch. Changes in start/end dates impacts the overall
project duration.
Custom Code Analysis Report that examines customer developments that are not
S/4HANA compatible.
Customizing Adaptation of the SAP standard software to the customer’s needs. In
customizing (in contrast to in-house developments) the software is adapted to the
processes of the company without programming. ! Implementation Guide.
Data Warehouse “Data warehouse”; a centralized database whose data comes
from various sources (e.g. SAP ERP) and can be made available for analysis
and reporting. Historical data is also included. The data warehouse in the SAP
system is called SAP BW (Business Warehouse).
Data archiving Moving currently no longer needed data from the relational data-
base to archives, where it can be accessed when needed.
322 Glossary

Database System for electronic data management, in which large amounts of data
are stored and required data are provided in the correct display form for users and
application programs. Databases for SAP systems, prior to Suite on HANA (as of
2013) and S/4HANA (as of 2016) are ASE from SAP, SAP HANA, Oracle and
DB2 from IBM. Current SAP products only support HANA and ASE
Data migration Transferring data from one system (legacy system) to another. The
data is extracted, transformed to fit the data model of the target system, and finally
loaded into the target system.
Deploy Phase The fifth phase as per Activate methodology. The deploy phase
consists of the go-live/cut-over and the subsequent hypercare activities.
Digitization Conversion of analog values into digital formats and their processing
and storage in digital technical systems.
Discover Phase First project phase as per the Activate methodology. Starting with
the business pain points, the goal is to identify the right SAP solution.
Document Management System (DMS) System to support the management and
control of documents.
Electronic Data Interchange (EDI) Procedure for electronic data exchange.
Embrace Program Use of SAP software on the Microsoft Azure Hyperscaler
infrastructure.
Emergency Process Administrative exception process during the downtime of an
SAP implementation.
End-to-end process Business management processes from the customer inquiry to
the provision of services.
Enhancement Framework Extension concept of the ABAP Workbench.
Enterprise Application Integration (EAI) Group of applications that support the
integration of IT systems and the business processes implemented in them.
Enterprise Service Bus (ESB) Integration platform for IT applications.
Experience Management Process of monitoring buyer interactions to spot
opportunities for improvement and brand expansion. Providing a personalised
experience to enhance customer-centricity.
Explore Phase After Discover and Prepare phase, the third phase as per Activate
methodology. The goal is to finalise the business processes of the target SAP
system landscape.
Extensible Markup Language (XML) Description language for data.
eXtreme Programming Iterative programming method; approximation of
requirements in small steps, less formalized approach.
Extrinsic Motivation Motivation that comes from outside or is stimulated exter-
nally via rewards.
Flow Chart/Time Schedule Planning of work packages in logical sequence with
target date.
Go-Live Productive implementation of the system.
Graphical User Interface (GUI) i.e. the application interface on the computer
screen through which the user communicates with the computer.
Glossary 323

Greenfield New implementation of a S/4HANA system, often with process

reengineering.
HANA (High Performance Analytical Appliance) is an in-memory, column-ori-
ented database developed and sold by SAP
Health Checks Project Quality reviews/audits. Also: Automated, customizable test
of an IT system that proactively alerts relevant users about errors that must be
fixed or improvements that must be made to avoid unplanned outages or other
negative impact on system health.
High-performance project teams Teams or virtual groups that are highly focused
on a common goal and thus achieve excellent project or business results.
Hybrid project management methods Hybrid project management methods are
combinations of classical (waterfall) and agile methods.
Hybrid system landscapes Partly on-premise, partly in the cloud.
IDES Internet Demonstration and Education System; model company whose busi-
ness processes are implemented in the SAP system for training purposes. IDES
packages are only available for ERP cross industry.
IDoc Intermediate Document. Proprietary SAP standard format for data exchange
between SAP systems.
Implementation Guide (IMG) Menu for ! customizing the SAP system. The
guide is structured hierarchically and is based on the hierarchy of the SAP
components.
Infrastructure-as-a-Service (IaaS) Infrastructure-as-a-Service is a service model
of cloud computing that provides data centre services.
Initial Review Quality review about 2–4 weeks before the official project start.
IPMA International Project Management Association
InfoSphere Platform Tool from IBM for data management.
Intelligent Suite The Intelligent Suite includes Enterprise Resource Planning
(ERP), Digital Supply Chain Management, Customer Experience, Intelligent
Spend Management and Human Experience Management.
Intrinsic motivation Motivation that comes from an inner (not external) drive.
IoT Internet of Things
IT Infrastructure Library (ITIL) Collection of best practices for implementing
IT service management.
Jo-Jo procedure Alternate, iterative application of the top-down and bottom-up
planning methods to take advantage of both.
Kanban method Support/acceleration of project management through visualiza-
tion and metrics.
Key figure Key Performance Indicator or KPI; quantitative (measurable in num-
bers) information that is presented in a condensed form and reflects the success or
failure of a company.
Key User Process expert, who represents the professional interests of the depart-
ment in the project team and later in the department
KTW Correction and transport system/also change and transport system function-
ality in SAP systems for consistent distribution of software and customizing.
324 Glossary

Legacy System Migration Workbench (LSMW) SAP tool to support data

migration.
Legacy System Old System
Lessons Learned Recording of experiences from previous projects (project
retrospective).
LoadRunner by HP Tools for measuring system performance.
Master Data Information that remains generally unchanged over a long period of
time and is needed repeatedly in business processes. E.g. name, address and date
of birth of an employee are master data.
Master Data Management (MDM) Procedure and tools for administration, distri-
bution and governance of ! master data.
Maturity Matrix Possibility of displaying the usability of software components.
Milestone Trend Analysis Procedure for determining the progress of the project on
the basis of planned milestones and evaluation of the effort still to be made to
achieve the milestones.
Methodological Competence Ability to apply suitable working techniques,
procedures and learning strategies in a goal-oriented manner.
Mix of methods Here: Mixing of top-down and bottom-up methods in the effort
estimation (iterative process).
Migration Cockpit Tool to support data migration
Model Company Reference solution for SAP S/4HANA, SAP C/4HANA, or SAP
SuccessFactors, tailored to a specific industry or line of business. Pre-configured,
ready-to run industry-specific or line of business solution in the cloud or on
premise.
Monitoring and Alerting Infrastructure Analysis Tool (MAI) SAP tool for
system monitoring (formerly CCMS).
Motion data Variable data valid for a specified period of time and for a specific
business transaction. They occur in business processes and are processed within a
limited period of time by users or the SAP system. ! Master data.
Nearshoring (local relocation) Use of (IT) experts from countries often from the
same continent, coming from countries with lower wage levels and good IT
infrastructure.
Nonviolent communication Concept developed by Marshall B. Rosenberg to
ensure that the flow of communication leads to more trust and joy in life.
Offshoring (relocation abroad) Relocation of entrepreneurial tasks abroad. As
with nearshoring, this is due to the availability of expertise and a low wage level.
Online Service System (OSS) (outdated) replaced by SAP Service Marketplace
(until 2017). Currently: SAP Support Portal
On-Premise The operation of a software solution runs in a local data center.
Operational management capability Ability to deploy and manage people in such
a way that an organisation’s strategy is implemented to achieve the desired
results.
Operational Management Level of management, where the content worked out in
the strategic development process is derived and implemented in actions.
Glossary 325

Organisational structure Structuring of a company into organisational units.

Performance Here: The entirety of the system properties in terms of system
response times and processing speed.
Periodic Review Regular quality review during a project
Personnel/Resource Plan Planning of staff deployment and technical
requirements.
Platform-as-a-Service (PaaS) Platform-as-a-Service is a service that provides a
computing platform for developers and web applications in the cloud.
PM-ZERT The Certification Body of the German Association for Project Manage-
ment (GPM), which awards four types of certificate: “Certified Project Manage-
ment Specialist”, “Certified Project Manager”, “Certified Senior Project
Manager” and “Certified Project Director”.
Point of no return The point in time when a system is introduced where reverting
to the old systems is no longer possible or only possible with massive impact on
the business processes.
Post-Review Review of productive operation: technical system operation, process
quality, production management system and efficiency of support structures.
Prepare Phase The second project phase as per Activate Methodology. The goal is
to select project resources, define the project scope, prepare a high-level project
plan and conduct the kick-off.
Professional Competence Ability to link, deepen and apply subject-related and
interdisciplinary knowledge in order to independently master typical professional
tasks.
Project Lifecycle Management Method for managing projects from the idea to the
handover to production.
Project Management Institute (PMI) Project management methodology devel-
oped in the USA. It offers the popular PMP (Project Management Professional)
certification.
Project Management Office (PMO) Project office with extended tasks/
competencies (beyond the administrative tasks).
Project Office (PO) Project office with administrative tasks.
Prototype Mapping of selected processes in the SAP system to demonstrate the
functionality and possibilities offered by the new system.
Quality Plan Shows when and by whom regular walkthroughs, inspections, audits,
project reviews are performed.
Quality assurance Various measures to ensure the project meets defined quality
standards.
Quality Gate A formal check whether the project results meet the standards and
plans.
RACI Matrix Definition of responsibilities for the project tasks (RACI ¼ Respon-
sible, Accountable, Consulted, Informed).
Random Access Memory (RAM) “volatile” memory in IT systems.
Readiness Review Verification that all requirements for a successful implementa-
tion are met.
326 Glossary

Realize Phase The fourth phase in Activate methodology. Based on the results of
the explore phase, the system configuration, development, customizing, and
testing are performed.
Redesign Here: Redesign/adaptation of already defined processes.
Resource selection Identification of the necessary and suitable employees and their
assignment to the appropriate places in the project organisation.
Result Trend Analysis Analysis of progress and projected development for the
work packages defined in the plan.
Return on Investment (ROI) Key figure that enables the return on capital
employed to be measured.
RFC connection Remote Function Call. Proprietary interface technology with
which functions can be called in another system.
Risk Management The active monitoring of project risks in order to identify risks
at an early stage and initiate countermeasures.
Risk Profile Visualization of risks (e.g. according to probability of occurrence and
potential damage).
Roll out Here: Transformation of further business units, countries to the new
system (after the pilot installation).
Rough planning Here: first planning step in the project preparation phase.
Run Once One productive system for all subareas or country subsidiaries of a
company.
Run Phase The sixth and final phase of the Activate methodology.
SAP Activate Implementation method for SAP S/4HANA with the phases Dis-
cover, Prepare, Explore, Realise, Deploy and Run. Successor of ASAP.
SAP Advanced Deployment A support offer from SAP: ‘guides’ customers to
their own dedicated planning, design support, and functional and technical
safeguarding services orchestrated by TQM (technical quality management)’.
SAP Best Practices Explorer SAP Best Practices contain all the information
necessary to model and use standard business processes in SAP.
SAP Business Suite Comprehensive business solution from SAP, which includes
the following solutions: SAP ERP (Enterprise Resource Planning), SAP CRM
(Customer Relationship Management), SAP PLM (Product Lifecycle Manage-
ment), SAP SCM (Supply Chain Management), SAP SRM (Supplier Relation-
ship Management), SAP SNC (Supply Network Collaboration). Successor
Product: Suite for HANA and currently S/4HANA
SAP Business Information Warehouse (BW) Formerly SAP BI ¼ SAP Business
Intelligence.
SAP Business Workflow SAP component used to facilitate business processes. A
workflow controls the flow of documents or records in the SAP system. Several
people are usually involved in processing these documents or records, and they
must be processed according to a defined pattern.
SAP Community Network (SCN) Community of SAP developers. Exchange
platform for SAP experts.
Glossary 327

SAP Data Information Steward Part of the Enterprise Information Management

suite of products that target the Information Management for data governance.
Improve the quality of data assets through modules like Data Insight, Metadata
management etc. Web-based application to support the data correction process.
SAP Data Services ETL (Extract, Transform, Load) tool that supports the process
of extracting data from the source systems, mapping and loading the data across
heterogeneous sources and applications. Provides development UI, metadata
repository, connectivity layer, run-time environment and a management console.
SAP Customer Relationship Management (CRM) Customer relationship
management.
SAP ERP Human Capital Management (HCM) Part of SAP ERP for the man-
agement of personnel matters such as personnel administration, time manage-
ment, payroll, travel management. See ! SuccessFactors
SAP ERP Software solution that covers the core business requirements of midsize
and large companies, including human resources (SAP ERP HCM), Finance
(SAP ERP Financials), Sales and Distribution, and Logistics (SAP ERP
Operations).
SAP FIORI User interface in the S/4HANA system.
SAP Focused Build With the Focused Build component, SAP offers an add-on tool
with preconfigured solutions for individual situations in the company.
SAP Graphical User Interface (GUI) The graphical user interface of an SAP
system and the program that provides this interface.
SAP Launch The Implementation Methodology for SAP Cloud Products.
SAP Master Data Governance (MDG) SAP tool for managing master data
according to the company’s business rules and processes.
SAP Model Company The SAP Model Company is a combination of SAP Best
Practices, which together cover most standard processes of a “model company”.
SAP NetWeaver Application Server Formerly SAP Web Application Server;
technical basis for most SAP products. It consists of an ABAP application server
(formerly SAP R/3 Basis) and a Java EE application server, which can be used
together or separately.
SAP NetWeaver SAP technology platform; technical basis for most SAP
solutions.
SAP Process Integration (PI) SAP tool for Enterprise Application Integration,
i.e. for the integration of business functions that are distributed across different
applications on different platforms. Old name SAP Exchange Infrastructure (XI).
SAP Process Orchestration SAP infrastructure used to design business processes
(procedures and interfaces required to integrate SAP systems and non-SAP
systems).
SAP R/3 Software based on SAP’s client-server architecture, introduced in 1992
and predecessor of SAP ERP.
SAP Roadmap Viewer Offers Implementation Roadmaps, which are arranged by
categories and by solutions
SAPscript Script language for creating forms in SAP systems.
328 Glossary

SAP S/4HANA Successor of the existing ERP SAP product line, where ‘S’ stands
for simple, ‘4’ for the fourth product generation and ‘HANA’ for the new modern
in-memory database technology.
SAP S/4 HANA Implementation Road Map Description of the implementation
method over the complete life cycle of a project.
SAP S/4HANA Migration Object Modeler Part of the Migration Cockpit in the
on-premise version. Supports the integration of customer-specific objects or SAP
standard objects that are not yet in the SAP S/4HANA scope of the Migration
Cockpit.
SAP Service Marketplace (obsolete) SAP online help system, in which error
messages from customers are recorded and processed by SAP. Successor: SAP
Support Portal
SAP Solution Manager Support tool from SAP that helps SAP customers imple-
ment and operate SAP software.
SAP Supplier Relationship Management (SRM) Supplier Management
SAP Supply Chain Management (SCM) Supply Chain Management
SAP Support Portal Contains SAP Notes, SAP Knowledge Base Articles, SAP
Community, Software Downloads, Incident reporting, Product Documentation
and Cloud Availability
SAP System Landscape Directory (SLD) Solution Manager functionality for
administration and documentation of SAP system landscapes.
SAP Value Assurance Service offering from SAP to support the implementation of
SAP S/4HANA.
SAP XI (SAP NetWeaver Exchange Infrastructure) A central interface hub for
internal and external Data exchange: later renamed SAP PI (Process Integration)
and finally in SAP PO (Process Orchestration).
Scope Here: Project Scope – the sum of all tasks and activities required to complete
a project.
Scrum Agile project management method in software development.
Service-oriented architecture (SOA) Software architecture that enables the use of
interchangeable web services to create business processes.
Simplification List List provided by SAP with the collection of new features of a
new S/4HANA release. Usually published once a year.
Situation Review Individual review of serious project problems as a basis for
mitigation measures
Scalability The property of a system to be easily expanded and upgraded to
accommodate a higher workload.
Software-as-a-Service (SaaS) Software-as-a-Service Cloud enables customers to
access offerings (for example, software and infrastructure) from external service
providers via the Internet.
Social Competence Ability to deal with other people, work constructively in teams
and develop a realistic self-image.
Staging tables Creation of temporary tables for data migration objects to support
data migration
Glossary 329

Stakeholders Person/group of persons who have an interest in the success of the

project, or are affected by the project outcome.
Statement of Work (SOW) Document on the content, scope, duration of the
project and the necessary budget.
Steering Committee The highest decision-making body of a project organisation.
Subscription model Software licensing model which includes the usage fee of a
license, infrastructure, operating costs and software maintenance
System landscape Installed system constellation (e.g. development system, test
system, training system and production system).
Technical Quality Manager (TQM) Customer-facing expert role of SAP’s Ser-
vice and Support organisation to safeguard SAP implementation projects and
operations.
Template Document template, here also a template of a software solution for later
roll-out.
Temporary employment Temporary work, temporary employment or employee
leasing means that an employee is provided by an employer to a third party
against payment and for a limited time. The employer becomes the lender, the
third party the hirer (Federal Employment Agency).
The blind spot Here: overlooked or deliberately hidden project activities/risks.
Tipco Non-SAP tool for Enterprise Application Integration (EAI).
Top-down approach Planning from the big picture to the detail (deductive).
Top-down estimation Derivation of the expenditures (budgets) of subprojects and
work packages from a total expenditure (total budget).
Upgrade Here: Change to a higher software release level.
User exit (obsolete) Standard docking points in the SAP system for in-house
developments (own program code), similar to the ! Business Add-in.
Value Discovery Workshop Workshop for a cost and benefit analysis for an SAP
S/4HANA system.
Visual Basic for Applications (VBA) Programming language, a script language
belonging to the Microsoft Office programs.
War Room Command center, which is used to centrally control and coordinate
project processes.
Waterfall methods (or waterfall models) are linear methods, especially in software
development, which divide development processes into successive project phases
(project stages).
Web Service Module of program code that provides a business management
function and is made available via the Internet. It is usually linked to other web
services to form a business process and, once created, can be reused in other
business processes.
WebSphere Middleware tool from IBM for Enterprise Application Integration
(EAI).
“We-feeling” A feeling of solidarity among group members (including
organisations) by pursuing a common goal.
330 Glossary

Work breakdown structure Description of overall project tasks, sub-project tasks,

tasks/work packages in the sub-projects as a basis for downstream planning.
Workflow Organisation Determination and definition of work processes taking
into account space and time.
Work package A development activity (design, customizing, programming).
WRICEF document (or also: RICEFW) Document in which all customer-
specific developments, interfaces etc. are described (WRICEF ¼ Workflows,
Reports, Interfaces, Conversions, Enhancements, Forms).
(XM) As a platform, Experience Management brings X-data and O-data together
and enables organisations to keep an eye on four areas: Customers, employees,
product and brand.
Bibliography

Agiles Projektmanagement für SAP-Projekte?!. (n.d.). Interview mit Prof. Dr. Komus, Professor für
Organisation und Wirtschaftsinformatik an der HS Koblenz, über die Nutzung agiler
Projektmanagement-Methoden in SAP-Projekten. Redaktion IT-Onlinemagazin, Accessed
Aug 15, 2020, from https://it-onlinemagazin.de/interview-agiles-projektmanagemnet-fur-sap-
projekte/
Agiles Projektmanagement. (n.d.). Methoden und Prozesse. Accessed Aug 15, 2020, from https://
www.brightsolutions.de/blog/agile-projekte-sicher-planen/
Alpar, P., Bensberg, F., Weimann, P., et al. (2016). Anwendungsorientierte Wirtschaftsinformatik.
In Strategische Planung, Entwicklung und Nutzung von Informationssystemen. Springer
Vieweg.
Baumann, M., & Schumacher, T. (2014). Kein Bullshit. Was Manager heute wirklich kennen
müssen. Murmann Verlag.
Baumgartl, A., & Frank, M. (2012). Volker Seemann: Das SOA-Praxisbuch für SAP. SAP PRESS.
Bechler, M., Hömer, A., Markert, M., Michel, M., Rauscher, J., & Steinsberger, T. (2017). SAP
Solution Manager, Das Praxishandbuch. SAP Press.
Bick, M.(n.d.). Einführungsstrategien des Wissensmanagements In: Accessed Aug 15, 2020, from
http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten-
wissen/Wissensmanagement/Wissensmanagement%2D%2DStrategien-des/
Wissensmanagement%2D%2DEinfuhrungsstrategien-des
Birkenbach, D. (2017, May). SAP, SAP Activate & Focused Build, Agile Methodology meets
Project tool.
Borgert, S. (2015). Wie resilient ist Ihre Projektorganisation? Haufe-Akademie. Accessed July
28, 2015, from http://www.haufe-akademie.de/blog/themen/projekt-prozess-und-change-man
agement/6-schritte-fuer-mehr-resilienz-im-projekt/
Brague, C., Champlin, R., Densborn, F., Dichmann, D., Felsheim, I., Keller, G., Kuppe, M., On, P.,
& Stefani, H. (2014). Enterprise information management with SAP (2nd ed.). SAP PRESS.
Burchard, B. (2017). High performance habits: How extraordinary people become that way. Hay
House.
“Chaos Manifesto 2013. Think Big, Act Small”. (n.d.). The standish group. Accessed Aug
15, 2020, from https://larlet.fr/static/david/stream/ChaosManifesto2013.pdf
“CHAOS Report 2015”. (n.d.). The standish group. Accessed Aug 15, 2020, from https://www.
standish-group.com/sample_research_files/CHAOSReport2015-Final.pdf
Daniel, C. (n.d.). Digitalisierung im Projektmanagement. Blogbeitrag unter. Accessed Aug
15, 2020, from https://www.projektassistenz-blog.de/digitalisierung-neue-heraus-forderungen-
fuer-das-projekt-management
Densborn, F., Finkbohner, F., Gradl, J., Roth, M., & Willinger, M. (2015). Datenmigration in SAP
(4th ed.). SAP PRESS. aktualisierte und erweiterte.

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 331
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4
332 Bibliography

Densborn, F., Finkbohner, F., Freudenberg, J., & Mathäß, K. (2018). Wagner, Frank: Migration
nach SAP S/4HANA (2nd ed.). SAP PRESS. aktualisierte und erweiterte Auflage.
Densborn, F. (2018). Datenmigration to SAP S/4HANA. Open SAP Course, 2018. https://open.sap.
com/courses/s4h8
Deutsche Gesellschaft für Psychiatrie, Psychotherapie und Nervenheilkunde (DGPPN). (n.d.).
Burn-out: genau diagnostizieren. Presse-Information vom 21.11.2012/Nr. 50. Accessed Sep
16, 2015, from http://www.dgppn.de/direct-mail/pressemitteilung-21112012-02.html
Die Wahl der passenden ERP-Software–Auswahlkriterien. (n.d.). Accessed Sep 16, 2015, from
https://www.meinerpfinden.de/auswahl-erp-system
Dietzel, E. (n.d.). “SAP Solution Manager 7.2 & Focused Solutions Demo System with SAP
S/4HANA on SAP CAL”. Blogbeitrag unter Accessed Aug 15, 2020, from https://blogs.sap.
com/2017/09/22/sap-solution-manager-7.2-focused-solutions-demo-system-with-sap-s4hana-
on-sap-cal/
Dörner, D. (1992). Die Logik des Mißlingens. Strategisches Denken in komplexen Situationen.
Rowohlt Taschenbuch Verlag.
Epicor. (n.d.). 12 Kriterien für die Auswahl eines neuen ERP-Systems. Accessed Sep 16, 2015, from
http://www.softselect.de/files/awb-whitepaper/12_Kriterien_zur_Auswahl_eines_neuen_ERP-
Systems.pdf
Facchinetti, M., & Baumann, D. (n.d.). Führungs- und Organisationskompetenzen als zentrale
Motivationsfaktoren. In projektMANAGEMENT aktuell 1/2015. GPM Deutsche Gesellschaft
für Projektmanagement e.V.
Gronau, N. (2012). Handbuch der ERP-Auswahl. GITO.
Hakanen, M., & Soudunsaari, A. (n.d.). “Building Trust in High-Performing Teams”.Technology
Innovation Review 2012. Accessed Aug 15, 2020, from http://timreview.ca/article/567
HayGroup. (n.d.). Mitarbeiter sind käuflich, ihre Motivation nicht. Studie der HayGroup 2012. In:
Accessed Aug 15, 2020, from http://www.haygroup.com/downloads/de/Mitarbeiter_sind_
kauflich_Ihre_Motivation_nicht.pdf
Heilig, B., & Möller, M. (2014). Business process management mit SAP NetWeaver BPM. SAP
PRESS.
Heinrich, L. J., & Lehner, F. (2005). Informationsmanagement: Planung, Überwachung und
Steuerung der Informationsinfrastruktur. In: Wirtschaftsinformatik. Oldenbourg
Wissenschafts-Verlag, 8.Auflage.
Herrmann, R. (n.d.). “Was ist ein Projektstrukturplan?“ DER WINF 2015 Accessed Aug 15, 2020,
from http://derwirtschaftsinformatiker.de/2013/11/03/projektmanagement/was-ist-ein-
projektstrukturplan/
Hesseler, M., & Görtz, M. (2007). Basiswissen ERP-Systeme. Auswahl, Einführung und Einsatz
betriebswirtschaftlicher Standard-Software. W3l.
Hochschule B., Hochschule B., & Fachhochschule K. (n.d.). ANECON Software Design und
Beratung G.m.b.H., German Testing Board (GTB), Swiss Testing Boar (STB): Umfrage zur
Software-Qualitätssicherung im deutschprachigen Raum. Accessed Aug 15, 2020, from http://
www.anecon.com/wp-content/uploads/2015/09/110914_PA_Softwarerwar-in-der-Praxis.pdf
Hoffmann, S. (n.d.). Projektmanagement. Aufarbeitung der Vorlesung »Projektmanagement« von
Max L. J. Wolf und Gerhard Hab an der FH-München. Accessed Aug 15, 2020, from http://
www.sun-dra.de/de/download/PM-Zusammenfassung.pdf
Huber, S. (2016). SAP-Testmanagement: Tests planen, entwickeln und durchführen. SAP PRESS.
Goncalves, J. N. (n.d.). “SAP Activate–with Agile, really works and save time?” Blogbeitrag unter
Accessed Aug 15, 2020, from https://blogs.sap.com/2017/08/12/sap-activate-with-agile-really-
works-and-save-time/
Kahle, C. (n.d.). “Burn-out”. Informationsseite der Medizinischen Medien Informations GmbH.
Accessed Aug 17, 2020, from https://www.meine-gesundheit.de/krankheit/krankheiten/burnout
Kallies, A., & Przybilla, A. (n.d.). Marktanalyse von enterprise resource planning-systemen.
Accessed Aug 15, 2020, from http://www.wi.hs-wismar.de/~wdp/2007/0712_
KalliesPrzybilla.pdf
Bibliography 333

Karavul, B. (n.d.). Aufwandsschätzung und Schätzverfahren. In: Projektmanagement-Handbuch der

Truecare GmbH. Accessed Aug 15, 2020, from http://www.projektmanagementhandbuch.de/
projektplanung/aufwandsschaetzung-und-schaetzverfahren/
Kloos, B., & Steffan, P. (n.d.). Boykotteure, Saboteure, Intrigante–Die besten Freunde des
Projektmanagers. Vortrag am 30.3.2011 im Arbeitskreis Forum Hessen-IT Transkript unter
Accessed Aug 15, 2020, from https://docplayer.org/20448485-Boykotteure-saboteure-
intriganten-die-besten-freunde-des projektmanagers-bernk-kloos-und-peter-steffan-frarnkfurt-
30.html
Köhler, J. (n.d.). Der blinde Fleck–ein unsichtbarer Begleiter mit ungeahnten Nebenwirkungen.
projektMANAGEMENT aktuell 5/2014. GPM Deutsche Gesellschaft für Projektmanagement
e.V.
Kohnke, O., & Bungard, W. (n.d.). Change Management als strategischer Erfolgsfaktor bei
ERP-Implementierungsprojekten. Accessed Aug 15, 2020, from http://www-1v75.rz.uni-
mannheim.de/Publikationen/MA%20Beitraege/05-01/2005-01_Beitrag02_Kohnke.pdf
Komus, (n.d.). Prof. Dr., Agiles Projektmanagement für SAP-Projekte?!
Korn, H-P. (2014). Das ‘agile’ Vorghen: Neuer Wein in alte Schläuche–oder ein ‘Deja-vu?’ 37.
WI-MAW Rundbrief des GI-Fachausschusses‚ Management der Anwendungsentwicklung.
Kösegi, A. (2013). SAP-Änderungs- und Transportmanagement (4th ed.). SAP PRESS.
Kuster, J. (2008). Handbuch Projektmanagement (3rd ed.). Springer.
Lange, M. (n.d.). Digitalisierung im Projektmanagement: Was sich im Projektalltag ändern wird.
Accessed Aug 17, 2020, from https://www.management-circle.de/blog/digitalisierung-im-
projectmanagement-was-sich-im-projektalltag-aendern-wird/
Laudon, J. P., Laudon, K. C., & Schoder, D. (2015). Wirtschaftsinformatik (2nd ed.). Pearson-
Studium.
Lehner, Hildebrand, F., Knut, & Maier, R. (1995). Wirtschaftsinformatik. Hanser.
Lohmann-Haislah, A. (n.d.). Stressreport Deutschland 2012: Psychische Anforderungen,
Ressourcen und Befinden. Bundesanstalt für Arbeitsschutz und Arbeitsmedizin. Accessed
Aug 15, 2020, from http://www.baua.de/de/Publikationen/Fachbeitraege/Gd68.pdf
Meier, A., & Kropp, M. (2017). 3. Swiss Agile Study, Agile und hybride Software-Entwicklung in
der Schweiz, Swiss Agile Research Network, 2017. Accessed Aug 15, 2020, from http://blogs.
fhnw.ch/swissagilestudy/files/2017/09/3,SwissAgile-Study.pdf
Meissner, G. (1997). SAP, die heimliche Software-Macht. Wie ein mittelständisches Unternehmen
den Weltmarkt eroberte. Heyne.
Meyer, M. (n.d.). Microsoft Project 1.0: Endlich Schluss mit Tabellenkalkulationen.
projektMANAGEMENT aktuell 5/2014. GPM Deutsche Gesellschaft für Projektmanagement
e.V.
Morieux, Y. (n.d.). Bringing managers back to work. Accessed Aug 15, 2020, from https://www.
bcg.com/de-de/publications/2018/bringing-managers-back-to-work
Murphy, J. (2010). Pulling together–10 rules for high performance teamwork. Simple Truths.
Murphy, J. J. (2016). Pulling together: 10 rules for high performance teamwork. Simple Truths.
Naumann, R. (n.d.). Keine Angst vor SAP S/4HANA – ein kleiner Wegweiser für einen sicheren
Wechsel. Blogbeitrag unter. Accessed Aug 15, 2020, from https://blogs.sap.com/2019/06/05/
keine-angst-vor-sap-s4hana-ein-kleiner-wegweiser-fuer-einen-sicheren-wechsel/
Neffinger, J., & Matthew, K. (2013). Compelling people: The hidden qualities that make us
influential. Hudson Street Press.
Nutzwertanalyse zur Software-Auswahl. (n.d.) Accessed Aug 15, 2020, from http://www.softselect.
de/wissenspool/nutzwertanalyse-zur-software-auswahl
Pentland, A. (n.d.) The new science of building great teams Accessed Aug 15, 2020, from https://
hbr.org/2012/04/the-new-science-of-building-great-teams
Pink, D. H. (2009). The surprising truth about what motivates us. Riverhead Books.
PMI. (2017). A guide tot he Project Management body of knowledge (Pmbok guide) (6th ed.).
Project Management Institute.
334 Bibliography

Pütter, C. (n.d.) Misserfolgsfaktoren bei Projekten: Studie der deutschen Gesellschaft für
Projektmanagement. CIO Accessed Aug 15, 2020, from http://www.cio.de/a/
misserfolgsfaktoren-bei-projekten,2911199
Quadbeck-Seeger, H.-J. (2008). Der Wechsel ist das Beständige. Wiley-VC.
Reinhaus, D. (n.d.). Erfolgsfaktor Motivation. Wie Projektleiter Projektmitarbeiter wirklich
motivieren und Projekte damit erfolgreich machen. projektMANAGEMENT aktuell 3/2014.
GPM Deutsche Gesellschaft für Projektmanagement e.V.
Rosenberg, M. (2003). Nonviolent communication – A language of life (2nd ed.). Puddle Dancer
Press.
Rozovsky, J. (n.d.). Five key to a successful google team blogbeitrag unter Accessed Aug 15, 2020,
from https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/
SAP Business Consulting. (2004). Template rollout: IT strategy details, hypothesis-based develop-
ment of the implementation approach and roadmap. SAP AG 2004.
SAP. (2006). Global ASAP implementation methodology: Approach and methodology presenta-
tion. SAP AG 2006 Accessed Aug 15, 2020, from http://support.sap.com/support-programs-
services/methodologies/implement-sap/global-asap-roadmap.html
SAP. (n.d.). A 48-year history of success. Accessed Aug 17, 2020, from https://www.sap.com/
corporate/en/company/history.html
Schäfer, M. O., & Melich, M. (2011). SAP solution manager. SAP PRESS, 2011.
Schäfer, M. O., & Melich, M. (2016). SAP Solution Manager für SAP S/4HANA. SAP PRESS.
Schöttel, K. (n.d.). Können SAP-Projekte agile sein? Accessed Aug 15, 2020, from https://acent.de/
koennen-sap-projekte-agile-sein/
Schreiber, D. (n.d.). Unternehmensplanung mit SAP BPC optimized for S/4HANA: Vorstellung und
Projekterfahrung. Accessed Aug 15, 2020, from https://www.verovis.de/fachbeitraege/news/
unternehmensplanung-mit-sap-bpc-optimized-for-s4hana-vorstellung-und-projekterfahrung-
35/
Scott, S. (2004). Fierce conversations: Achieving success at work and in life one conversation at a
time. Berkeley Publishing.
Stanley, M. (n.d.). The Hybrid/Agile project management process. Accessed Aug 17, 2020, from
https://bia.ca/the-hybrid-agile-project-management-process/
Steeger, O. (n.d.). PMOs mit überwältigender Akzeptanz im Unternehmen.
projektMANAGEMENT aktuell 4/2014. GPM Deutsche Gesellschaft für Projektmanagement
e.V.
Strasser, J. (n.d.). Hybrides Projektmanagement–Wie Sie agile und klassische Methoden verbinden.
Accessed Aug 15, 2020, from https://www.theprojectgroup.com/blog/hybrides-project-
management-so-gehts/
Suter, A., & Höning, F. (n.d.). Die 5 Gründe, warum ERP-Projekte scheitern Computerwoche.
Accessed Aug 15, 2020, from http://www.computerwoche.de/a/die-5-gruende-warum-erp-
projekte-scheitern,1906344
Teuber, L., Weidmann, C., & Will, L. (2013). Monitoring und Betrieb mit dem SAP Solution
Manager. SAP PRESS.
Tiemeyer, E. (n.d.). Kennzahlengestütztes IT-Projektcontrolling: Projekt-Scorecards einführen und
erfolgreich nutzen. SIMAT-Arbeitspapiere 03–11-010. Fachhochschule Stralsund 2011.
Accessed Aug 15, 2020, from http://www.econstor.eu/bitstream/10419/60093/1/719933110.
pdf
Töper, A. (n.d.). Es geht um die Kultur: Wie Sie mit den richtigen DevOps-Prinzipien agile
SAP-Projekte stemmen. Accessed Aug 15, 2020, from https://www.salt-solutions.de/solutions/
detail/es-geht-um-die-kultur-wie-sie-mit-den-richtigen-devops-prinzipien-agile-sap-projekte-
stemmen.html
Tran-Gia, P. (n.d.). Professionelles Projektmanagement in der Praxis. Projektplanung 2:
Projektstrukturplan, Arbeitspakete, Aufwandsschätzung. Vorlesung von Prof. Dr. Harald
Wehnes an der Universität Würzburg. Transkript unter Accessed Aug 15, 2020, from https://
Bibliography 335

wuecampus2.uni-wuerzburg.de/moodle/pluginfile.php/547919/mod_resource/content/1/2015-
05-04-2-Planung2x.pdf
Viana, R., & Mutumba, J. (2015). SAP process orchestration. SAP PRESS.
Wissing, M. (2006/2007). Projektorganisation. Vorlesung an der Ludwig-Maximilian-Universität
München. WS 2006/2007.
Zak, P. J. (2017). Trust factor: The science of creating high-performance companies. AMACOM.
Zillmann, M., & Ganowski, T. (n.d.). Lünendonk-Studie: Mit S/4HANA in die digitale Zukunft,
Lünendonk & Hossenfelder GmbH 2019. Accessed Aug 17, 2020, from https://www.
luenendonk.de/produkte/studien-publikationen/luenendonk-studie-2019-mit-s-4hana-in-die-
digitale-zukunft/
Index

0-9, and Symbols Arbeitszeit, 142

4GL, see Fourth Generation Language (4GL) ASAP, see Accelerated SAP (ASAP)
Assessment, 39
Aufgabenauswahl, 156
A Aufgabenkonflikt, 106
ABAP, 3, 319 Auftraggeber/Auftraggeberin, 127
Ablauf, 185 Aufwandsschätzung, 104, 116, 184, 187, 213
Abteiungsleiterinnen/Abteilungsleiter, 127 Bottom-up-Ansatz, 187
Accelerated SAP (ASAP), 73, 79, 101, 192, 251 Top-down-Ansatz, 187
phase 1, project preparation, 80 Ausfallzeit, 84, 121
phase 2, business blueprint, 82 Auslastung, 284
phase 3, realization, 83 Auswärtiges Amt, 170
phase 4, final preparation, 84
phase 5, go-live and support, 84
vor- und nachteile, 85 B
Accountable, 192 Batch-Betrieb, 1
Administration Guide, 97 Beispielunternehmen, 252
Agile Methoden, 130, 210 Benutzerfreundlichkeit, 43
Agiles Mindset, 132 Berater und Beraterinnen
Altdaten, 118 Einsatzgrund, 275
Ambiguitätstoleranz, 132 Berater/Beraterin
Änderungsmanagement, 295 Abrechnungsmodus, 278
Anerkennung, 156 Arbeitspakete, 279
Anforderungsanalyse, 110, 116 Auswahlkriterium, 277
Anforderungsmanagement, 258 Fachwissen, 277
Angebotsphase, 104 Gesamtverantwortung, 280, 281
Angstkultur, 169 Mitarbeiterüberlassung, 278, 279
Anpassungsfähigkeit, 132 Rollenverteilung, 281–283
Anwendung Soft Skill, 277
Big Data, 12 Beraterauswahl
Applikation server, 2 Preis, 277
Arbeitnehmerüberlassung, 276 Beraterinnen/Berater, 127
Arbeitsbereich, 192 Berechtigung, 195
Arbeitskraft Bericht, 196
fehlende, 275 interner, 195
Arbeitspaket, 184, 196, 279, 280 Berichtserstellung, 294
Arbeitsplatz, 107 Berichtsinhalt, 196
flexibler, 11 Berichtswesen, 195

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 337
D. Banks-Grasedyck et al., Successfully Managing S/4HANA Projects, Management
for Professionals, https://doi.org/10.1007/978-3-030-86084-4
338 Index

Beschleuniger, 96 Continuous Quality Check and Improvement

Bestandsaufnahme, 191 Services, 92
Betriebskosten, xi Controlling, 88, 134
Betriebsrat, 127 Conversion, 89
Betriebsunterstützung, 306–307 Cost management, 75
Big Bang, 93 Customer experience, 13
Big Data, 12, 89 Customizing, 3, 115, 183
Blockchain, vi Cut-over, 87, 93
Blueprint
implementierbarer, 83
Blueprint-Dokument, 83 D
Blueprint-Phase, 82 Data Science, 140
Bottom-up-Ansatz, 186 Daten, 175
Bottom-up-Schätzung, 187 Daten laden, 120
Boykott, 201 Datenänderung
BPM-Werkzeuge, 302 realtime, 1
Budget, 116, 210 Datenbank, 2
Budgetplanung, 134 Daten-Mapping, 118
Burnout, 157 Datenmigration, 117, 122, 123
Anzeichen, 158 Datenmodell, 118
definition, 157 Datenqualität, 43, 123, 260
Business Blueprint, 82, 109, 258–259 Datenschutz, 141, 175
Business Objects, 7 Datensicherheit, 11, 175
Business Process Hierarchy, 300 Definition and planning, 75
Business Process Management (BPM), 301 Delegationsbereitschaft, 132
Business Technology Platform, 14 Deliverables, 95
Deploy, 216
Digitalisierung, 126, 173, 174, 219
C Säulen, 173
CapEx, see Capital Expenditure (CapEx) Dokumentation, 83, 110, 113, 121,
Capital Expenditure (CapEx), xi 191, 291
CATT, 304 Dokumentationsstruktur, 195
Change and transport system (CTS+), 306 Dokumentenmanagementsystem (DMS),
Change management, 19, 20, 118–119, 132, 296, 298
176, 291 Dokumentenverwaltung, 298
Change request management (ChaRM), Drei-Schichten-Architektur, 2
123, 306
Checkliste, 215
Client-Server-Software architektur, 2 E
Cloud, 10, 86, 112 Early adopter, 238
Cloud-Angebote, 11 eCATT, 304
Cloud-Lösung Echtdaten, 123
modulare, 15 EDV, see Elektronische Datenverarbeitung
Cloud-Software, vii (EDV), 1
Coaching, 160 Ehrlichkeit und Offenheit, 164
Communication management, 75 Eigendynamik, 73
Competence Center, 236 Einführungstermin, 104
Compliance, 141 Einsatz, 157
Computer Center Management System Einsparungen, 20
(CCMS), 307 Elektronische Datenverarbeitung (EDV), 1
Concept and initiation, 75 ELKB, see Evangelisch-Lutherische Kirche in
Connectivity, 11 Bayern (ELKB)
Consulted, 193 E-Mail-Kommunikation, 297
Index 339

E-Mail-Verwaltung, 296 G
Embrace-Programm, 12 Gesamtverantwortung, 280, 281
Emotionale Intelligenz, 135 Geschäftsanforderung, 183
Empathie, 166 Geschäftsbereich, 98
Enterprise resource planning (ERP), 1 Geschäftsdaten, 13, 89
Entscheidungsbefugnis, 106 Geschäftsleitung, 127
Entscheidungsfindung, 148, 172 Geschäftsprozess
Entscheidungsübermittler, 275 ready to run, 103
Ergebnisliste, 185 Geschäftsprozessanforderung, 82, 110
Ergebnistrend-Analyse (ETA), 194 Geschäftsprozessmanager, 127
Erfahrungsbericht, 191 Geschäftsvorfall
Ernährung zeitversetzte Verbuchung, 1
gesunde, 160 Global ASAP Local Rollout Roadmap, 254
ERP, see Enterprise Resource Globales Prozessdesign-Template, 258
Planning (ERP) Globales Template, 252, 258
Erwartungsdruck, 103 Go-/No-go-Entscheidung, 85, 93
Erwartungshaltung, 107 Go-live, 120, 260–262, 272
ETA, see Ergebnistrend-Analyse (ETA) Vorbereitungen, 119
EURES, see European Employment Services Go-live and support, 84–85
Portal (EURES) Grobplanung, 183
European Employment Services Portal Großprojektmanagement, 23
(EURES), 170 Groupware, 296
Evangelisch-Lutherische Kirche in Bayern Gruppenprozess, 148
(ELKB), 224 Guided configuration, 88, 103, 212
Execution, 75
Experience data, 89
Experience Management (XM), 14 H
Explore, 215 Harmonisierung der Prozesse, 43
Herausforderung, 156
Hidden Agenda, 285
F High-Performance-Projektteam, 146
Fachabteilung, 108, 110 Human Experience Management (HXM), 13
Fachkompetenz, 114, 136, 137 Human Resource Management, 75
Feedback, 156 HXM, see Human Experience Management
Fehlerbehandlungsverfahren, 195 (HXM)
Festpreisprojekt, 280 Hybride Landschaft, 11
Final Preparation, 84 Hypercare-Phase, 85, 93
Fit-Gap-Analyse, 109 Hyperscaler, xi, 12, 240
Fit-to-Standard, 90
Flaggschiff, vi
Flexibilität, 80 I
Focused Build, 274 ICB, see IPMA Competence Baseline (ICB)
Focused Solutions, 212 Implementation Roadmap, 95
Fourth Generation Language (4GL), 3 Implementierungsmethode, 254
Fragenkatalog, 142 In scope/out of scope, 258
Freigabeprozess, 116 Industrie 4.0, 12
Frontend, 2 Industrielösung, 5
Führungsfähigkeit Informed, 193
operative, 136 Infrastruktur, 107
Führungskompetenz, 134 Infrastrukturkosten, 43
Führungsverhalten, 114 Inhouse-Berater/-Beraterinnen, 274
Full-Service-Anbieter, 12 Inhouse-Beratung, 283
Funktionstest, 123 In-Memory-Datenbank, 8, 9
340 Index

Integration Management, 75 Kommunikationsfähigkeit, 135

Integrationstest, 123 Kommunikationskultur, 163–166
Integrität, 166 Kommunikationsplan, 185
Intelligent Enterprise, 13, 89 Kommunikationsstruktur, 166
Intelligent Spend, 13 dezentrale, 167
Intelligent Suite, 13, 14 zentrale, 167
Intelligenz Kommunikationsweg, 112
künstliche, v Kompetenzen, 107
Interkulturelle Kommunikation, 171 Kompetenzverlust, 115
interkulturelles Verständnis, 171 Komplexität, 73
International Project Management Association Konfiguration, 115
(IPMA), 71 Konfigurationsstandard, 195
Internationales Projekt, 169 Konflikt
Internet of Things (IoT), 12, 89 lösen, 133
Interviews, 126 Kontrollprozess, 197–202
Intransparenz, 73 Kosten, 182
Investitionsausgaben, xi Kostenplanung, 185
Investitionssicherheit, 43 Kostenstellenverantwortung, 193
IoT, see Internet of Things (IoT) Kostentrend-Analyse (KTA), 194
IPMA, see International Project Kreativität, 132
Management Association Kritik
(IPMA) konstruktive, 169
IPMA Competence Baseline (ICB), 71 KTA, see Kostentrend-Analyse (KTA)
Istanalyse, 39 Kunde, 127
Iteration, 91 Kundenerlebnis, 89
ITIL, see IT Infrastructure Library (ITIL) Kundenfokussierung, 140
IT Infrastructure Library (ITIL), 71, 299 Kundenzufriedenheit, 13, 89
Künstliche Intelligenz (KI), v
Kurskorrektur, 166
J
Jo-Jo-Verfahren, 186
L
Ländergesellschaft, 256
K Last-Test, 92
Kennzahlen im Projekt, 198 Legacy-System, 175
Kennzahlensystem, 198 Leistungstest, 143
Kernprodukt Lenkungsausschuss, 127
SAP S4/HANA, vi Lernbereitschaft, 132
Key-User, 94, 127 Lessons Learned, 192, 251
KI, see Künstliche Intelligenz (KI) Business Blueprint, 258
Kick-off, 103 Projektvorbereitung, 257
Know-how-Transfer, 276 Realisierungsphase, 259
Knowledge Area, 75 Lieferant, 127
Knowledge Articles, 213 Line of Business (LoB), 98
Kollaboration, 141 Linienprojektorganisation, 24
Kommunikation, 104, 108–109, 161, 176 LoB, see Line of Business (LoB)
Ehrlichkeit und Offenheit, 164 Logdateien, 8
Empathie, 166 lokaler Business Blueprint, 258–259
gewaltfreie, 133 Lösung
Integrität, 166 cloudbasierte, 10
interkulturelle, 171 Lösungen
systemische Prinzipien, 164 vorgefertigte, 212
Index 341

M Projektmanagement, 291
Machbarkeit, 151 Ressourcenmanagement, 291
Machine Learning, vi Offshore-Team, 286
Mainframe, 1 Herausforderungen, 287
Management OGC, see Office of Government Commerce
operatives, 137 (OGC)
strategisches, 137 On-Premise-Software, 15
Matrixprojektorganisation, 25 Operational Data, 89
Meditation, 160 Operational Expenditure (OpEx), xi
Meilenstein, 104, 134, 185 OpEx, see Operational Expenditure (OpEx)
Meilensteintrend-Analyse (MTS), 194 Optimierung von Prozessen, 19
Menschlichkeit, 151 Optimismus, 132
Messsystem, 198 Organisationsform, 192
Methodenkompetenz, 136
Microsoft Excel, 294, 296
Microsoft Exchange, 294 P
Microsoft Outlook, 294, 296 PaaS, see Platform as a Service (PaaS)
Microsoft Project, 294 Parallele Projekte
Microsoft Project, Server, 295 parallel laufende, 179
Microsoft Word, 294, 295 Parallelprojekt, 109
Mindset, 132 Personalauswahl, 143
Minimized Downtime Service, 84 Personaleinsatz
Mitarbeiter/Mitarbeiterinnen internationaler, 170
ausländische, 170 Personalplanung, 184
Mitarbeiterführung, 161 Pfad
Mitarbeiterüberlassung, 278, 279 kritischer, 185
Mittagspause, 160 Pilotimplementierung, 256
Modellbasiertes Testmanagement, 250 Pilotinstallation, 252
Monitoring, 88 Pilotland, 251–257
Monitoring Alerting Infrastructure (MAI), 307 Pilot-Projekt, 260
Monitoring and Controlling, 75 Plan-Ist-Vergleich, 189, 198
Motivation, 151, 155, 156, 285 Planung, see Projektplanung
extrinsische, 155 Planung und Vorbereitung, 80
fehlende, 155 Platform as a Service (PaaS), 12
intrinsische, 155 PMBOK Guide, 71
MTS, see Meilensteintrend-Analyse (MTS) PMI, see Project Management Institute (PMI)
Multiprojektmanagement, 23 PMO, see Project Management Office (PMO)
Multitasking, 158 PMP, see Project Management Professional
(PMP)
Polytelie, 73
N Prepare, 215
Nearshore-Center, 290 Pre-Review, 214
Nearshore-Team, 286 PRINCE2, see Projects in Controlled
Herausforderungen, 287 Environments (PRINCE2)
Procurement Management, 75
Produktionsplan, 120
O Produktionsvorbereitung, 84, 119
O-Daten, 13, 89 Produktivsetzung, 120, 272
Office of Government Commerce (OGC), 71 Prognosetechnik, 194
Offshore-Center, 290 Programmmanagement, 23
Aufgaben, 291 Project Management Institute
Change Management, 291 Knowledge Areas, 75
Dokumentation, 291 Project Management Institute (PMI), 71, 74
342 Index

Project Management Institute (PMI) (cont.) SAP Activate, 87

Phasen, 74 SAP Launch, 86
Prozessgruppen, 74 Projektmitarbeiter und -mitarbeiterinnen
Project Management Office (PMO), 77, 114, Fachkenntnis, 191
177, 178 Projektmitarbeiter*in
Aufgaben, 178 Verfügbarkeit, 104
Hierarchie, 179 Projektorganisation, 105–107, 192
Teamleiter, 178 lokale, 256
Project Management Professional (PMP), 71 mit Offshore-Anteil, 290
Project Office, 177 weltweite, 256
Project Preparation, 80, 103 Projektphase, 185
Projects in Controlled Environments Prepare, 219
(PRINCE2), 71 Projektphasen
Projekt Checkliste, 215
Grenze, 108 Projektplan, 122
planen und vorbereiten, 103 Projektplanung, 184, 295
Rollenverteilung, 281–283 Detailgrad, 184
Projektaufgaben, 283 Detaillierungsgrad, 104
Projektauftrag, 183 Projekttermin, 182
Projektbeispiel Projektziel, 182
Automobilhersteller, 244 Säule, 182
BITZER SE, 235 Tipps, 189
Evangelisch-Lutherische Kirche Bayern, Vollständigkeit, 104
224 Projektportfoliomanagement, 23
Lessons Learned, 251 Projektqualitätsplan, 214
Mittelstand Prozessindustrie, 219 Projektressource, 105
Projektbesetzung Projektrisiko, 198, 199
internationale, 169–172 Risikoprofil, 199
Projektbüro, 77, 177 Projektrollen, 127
Projekt-Controlling, 294 Projektstandards, 112–113, 185, 195
Projektfreigabe, 183 Projektstatus, 114
Projektgegenstand, 108 Projektstatusmeeting, 195, 196
Projekthandbuch, 263 Projektsteuerung, 114–115, 181, 189–202
Projektkontrolle, 114, 189–202 Projektstrukturplan, 74, 95, 184, 213
Projektleiter, 72 Bestandteil, 184
Projektleitung, 127, 130–137 Bottom-up-Ansatz, 186
Aufgaben, 133 deduktiver, 186
Auswahl, 72 Erstellung, 186
Fähigkeiten, 131 induktiver, 186
Führungskompetenz, 134 Jo-Jo-Verfahren, 186
organisatorische Aufgabe, 134 Top-down-Ansatz, 186
Qualifikationen, 72 Projektteam, 126–130
Projektmanagement, 74, 112, 291 erweitertes, 127, 128
agiles, 210 operatives, 127
ASAP, 73 Projekttermin, 182
hybrider Ansatz, 211 Projektüberwachung, 294
Methoden, 210 Projektziel, 108, 118, 182
Methodik, 74 Projektziele, 285
SAP Activate, 73 Hidden Agenda, 285
Standards, 71 Prototyp, 183, 259
Projektmanagementarten, 23–27 Prozessbeschreibung, 295
Projektmanagementmethode, 192 Prozessdesign, 109, 258
ASAP, 79 Prozessgruppe, 74
Index 343

Prozessworkshop, 264 Arten, 205

Puffer, 105, 159 Ergebnisse, 207
periodischer Review, 205
Readiness-Review, 207
Q Situations-Review, 207
Qualitätskontrolle, 291 Review der Systemlandschaft, 38–39
Qualitätsmanagement, 294 RICEF, 83
Qualitätsplan, 185 Risiko, 199
Qualitäts-Review, 270 Eintrittswahrscheinlichkeit, 199
Qualitätssicherung, 105, 120, 202, 209, 214 Schadenspotenzial, 199
Qualitätssicherungsmaßnahme, 214 Risikoanalyse, 134
Quality Gates, 214 Risikoaufschlag, 280
Quality Management, 75 Risikobewertung, 105
Qualtrics, 7, 11 Risikodatenbank, 199
Quick Sizer, 92 Risikomanagement, 185, 198, 294
Risikominimierung, 204
Risikoprofil, 199
R Risk management, 75
RACI, see Responsible, Accountable, Roadmaps, 96
Consulted, Informed (RACI) Roadmap Viewer, 95, 213
RACI-Matrix, 83, 106, 192, 194, 296 Robotic Process Automation (RPA), vi, 12
Raodmap Viewer Rollen, 127
Knowledge Articles, 213 Rollenbeschreibung, 142
Rapid Deployment Solution (RDS), 97 Rollenverteilung, 281
Rapid Implementation, 274 festgelegte Projektaufgaben, 283
Rational (IBM), 305 Inhouse-Beratung, 283
RDS, see Rapid Deployment Solution (RDS) Teilprojekte, 282
Ready to Run, 103 Two-in-a-Box-Ansatz, 281, 282
Realisierungsphase, 83, 113–119 Roll-out-Konzept, 262–272
Realization, 83 Roll-out-Managementsystem, 265
Realize, 215 RPA, see Robotic Process Automation (RPA)
Rechenschaftspflicht, 192 Rückmeldung, 172
Recruiting-Plattform, 275
Redesign, 109
Redesign von Prozessen, 19 S
Referenzarchitektur, 111 SaaS, see Software as a Service (SaaS)
Reine Projektorganisation, 24 Sabotage, 201
Relationalen Datenbank, 8 SAP Activate, 73, 101, 212, 213
Releasezyklus, 105 phase 1, discover, 89
Reporting, 134, 196 phase 2, prepare, 90, 219
Resilienz, 155, 161 phase 3, explore, 90
Responsible, 192 phase 4, realize, 91
Responsible, Accountable, Consulted, phase 5, deploy, 92
Informed (RACI), 83 phase 6, run, 93
Ressourcenauswahl, 141 Phasen, 88
Fragenkatalog, 142 pre-reviews, 214
Ressourcenbedarf, 259 quality gates, 214
Ressourcenbeschaffung, 134 SAP Activate Methodology for Business Suite
Ressourcenmanagement, 291, 294 and On-Premise, 96
Ressourcenplanung, 139, 184, 294 SAP Activate Methodology for Nnew Cloud
Ressourcenverfügbarkeit, 104, 139, 144 Implementations, 96
Review, 204 SAP Analytics Cloud, 11
Anfangs-Review, 205 SAP Ariba, 11
344 Index

SAP Best Practices, 88, 97, 109, 212 SAP Solution Manager, 88, 95–97, 298–301,
Administration Guide, 97 304
SAP Best Practices Explorer, 97 SAP Solution Manager 7.2, 212, 213
SAP Business Intelligence (SAP BI), 5 SAP SRM, 5
SAP Business Suite, 4, 5, 7, 8 SAP SuccessFactors, 11, 226
SAP BW, 5 SAP XI, see SAP NetWeaver Exchange
SAP Cloud Platform, 12 Infrastructure (SAP XI)
SAP Component Based Test Automation SAP-Berater und _Beraterinnen, 273
(CBTA), 305 SAP-Projekt, 183
SAP Concur, 11 SAP-Referenzarchitektur, 111
SAP Consulting, 278 SAP-Standard, 110, 115
SAP CRM, 5 Säulen der Digitalisierung, 173
SAP Customer Experience, 11 Schnittstelle, 120, 258
SAP Data Migration Cockpit, 118 Schnittstellendokumentation, 295
SAP ECC, see SAP Enterprise Core Schnittstellenplanung, 111
Component (SAP ECC) Schnittstellentest, 123
SAP Enterprise Core Component Schulung, 20, 119, 271
(SAP ECC), 5 Schulungskonzept
SAP Extended Warehouse Management unpassendes, 119
(SAP EWM), 5 Schulungsmaterial, 119, 123, 260
SAP Fieldglass, 11 Schulungssystem, 119, 260
SAP Fiori, 7 Scope, 69, 86, 89, 122, 123, 210
SAP Focused Build, 212, 213 Scope management, 75
SAP Graphical User Interface (SAP GUI), 2, 7 Scrum, 130
SAP GUI, see SAP Graphical User Interface Selbstständigkeit, 172
(SAP GUI) Selbstverpflichtung zu den Teamzielen, 147
SAP HANA, 8, 9 Situations-Review, 207
SAP HANA Enterprise Cloud, 12 Sizing, 92
SAP Launch, 86 Skalierbarkeit, 11
launch-phase, 87 Skills, 121, 122
prepare-phase, 86 Soft Skills, 135, 192
realize-phase, 87 Software as a Service (SaaS), 11
verify-phase, 87 Softwareauswahl, 111
SAP Leonardo, 12 Softwarelogistik, 306–307
SAP Model Company, 88, 97 Solution Design, 86, 87
Branchen, 98 Sozialkompetenz, 135
Geschäftsbereiche, 98 Spezialwissen, 144
SAP NetWeaver, 5 Sprachbarriere, 171, 287
SAP NetWeaver Application Server Sprachbarrieren, 270
(SAP NetWeaver AS), 6 Spracherkennung, vi
SAP NetWeaver Exchange Infrastructure Sprint, 85, 91, 210
(SAP XI), 6 Stabsprojektorganisation, 26
SAP PI, see SAP Process Integration (SAP PI) Stack, 9
SAP PO, see SAP Process Orchestration Stakeholder, 127
(SAP PO) Stakeholder-Analyse, 258
SAP Portal, 6 Stakeholder Management, 75
SAP Process Integration (SAP PI), 6 Stakeholder-Meeting, 197
SAP Process Orchestration (SAP PO), 6 Standardsoftware, 3
SAP Quality Center by HP, 305 Stapelverarbeitung, 1
SAP S/4HANA Implementation Roadmap, 212 Statement of Work, 109
SAP S4/HANA, vi Statusbericht, 195
SAP Sales Cloud, 12 Status-Reporting, 294
SAP SCM, 5 Steering Committee, see Lenkungsausschuss
Index 345

Steuerung, 114 Top-down-Ansatz, 186

Steuerungsprozess, 197–202 TQM, see Technical Quality Manager (TQM)
Stressmanagement, 160 Trainingssystem, see Schulungssystem
Subject Matter Expert (SME), 278 Transformationsgröße, xii
Support, 120, 121, 260–262 Transportmanager, 307
Systemarchitektur, 109, 111–112 Transportwesen, 306–307
Systembetrieb, 307 Two-in-a-Box-Ansatz, 281, 282
Systemintegrator, 127
System-Sizing, 92
Systemzugriff, 107 U
Überlastung, 152
Übertragungsprogramm, 118
T Unternehmenskultur, 169, 287
Tabellenkalkulation, 296 Unternehmensstrategie, 76, 110
Tagesgeschäft, 145 Unterstützung der Geschäftsleitung, 257
Entlastung, 145
Team
internationales, 171 V
Regeln, 172 Verantwortlichkeit, 106, 148, 192
Rollen, 172 Verantwortung, 192, 281
Unstimmigkeit, 106 Vermittlungsagentur, 127, 129
Verantwortlichkeiten, 172 Vernetztes Denken, 132
Team Huddle, 161 Vernetztheit, 73
Teamarbeit Vertrauen, 114, 149, 156
Regeln, 148, 149 Visual Basic for Applications (VBA), 296
Technical Quality Manager (TQM), 214 Volatility, Uncertainty, Complexity, Ambiguity
Teilprojekt, 107, 109, 282 (VUCA), 132
Teilprojekte, 282 Vorbereitung
Template, 252, 258 finale Phase, 260–262
Template-Rollout, 252 VUCA, see Volatility, Uncertainty,
Termin- und Zeitplanung, 134, 182, 185, Complexity, Ambiguity (VUCA)
258, 294
Terminverwaltung, 296
Test Workbench, 304 W
Testaufwand, 117 Walk-through, 87
Testdaten, 117 Wartungsende, 16
Testen, 120, 123, 304–306 Wasserfallmethode, 210
Testinfrastruktruktur, 260 Werkvertrag, 276
Testmanagement Wertschätzung, 157
modellbasiertes, 250 Wir-Gefühl, 147
Testmethode, 116 Wissen
Testplanung, 116 spezielles und technisches, 144
Teststrategie, 117 Wissenstransfer, 113
Testteam, 116 Work-Life-Balance, 159
Testtermin, 117 WRICEF, 83
Testumgebung, 117
Testwerkzeuge, 304–306
Textverarbeitung, 295 X
Time Management, 75 X-Daten, 13, 89
Time-to-Value, 99 XM, see Experience Management (XM)
346 Index

Z Zentrale Auslands- und Fachvermittlung

ZAV, see Zentrale Auslands- und (ZAV), 170
Fachvermittlung (ZAV) Zukäufe, 7
Zeitplanung Zukunftsangst, 107
Puffer, 105 Zyklus, 91
Zeitzone, 171, 287