Successful Implementation of ERP System E-Book

Friedrich W. Espeter

• Herausgeber: tredition
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 142

Veröffentlichungsjahr: 2022

Beschreibung

In this book, Friedrich Espeter shows you how to proceed successful the implementation of ERP systems. You will learn how a method-based agile approach helps to meet time, budget and quality targets and specially to find the right balance between changes in the software and in the business processes. It places particular emphasis on the practical aspects of the agile approach, e.g. in the form of workshops and best practices

Leseprobe

Friedrich W. Espeter

Successful Implementation of ERP Systems

A Handbook for Agile Management

© 2022 Friedrich Wilhelm Espeter

Cover, illustration: Friedrich Wilhelm Espeter

Translation: Friedrich Wilhelm Espeter with support of Barbara Wilkens (Thanks a lot!)

Graphics: Carl David Espeter

ISBN Hardcover: 978-3-347-68900-8

Printing and distribution on behalf of the author:

tredition GmbH, Halenreie 40-44, 22359 Hamburg, Germany.

This work, including its parts, is protected by copyright. The author is responsible for the content. Any exploitation is prohibited without his/her consent. Publication and distribution are carried out on behalf of the author, who can be contacted at:

tredition GmbH, Department "Impressumservice", Halenreie 40-44, 22359 Hamburg, Germany.

PREFACE

PART 1 METHOD BASED APPROACH

1 INTRODUCTION

1.1 A new system

1.1.1 Business Necessity: Heading for New Shores

1.1.2 Release Upgrades

1.1.3 Drop-ins

1.2 Implementing business software, what needs to be done?

1.2.1 Change to the software

1.2.2 Changes in the company

1.3 The Methodological Approach

1.3.1 Why no waterfall?

2 THE IMPLEMENTATION METHOD AT A GLANCE

2.1 Phases, Cycles and Milestones

2.2 Work Packages

2.2.1 Strategies

2.2.2 Work package deliverable types

2.3 Important Elements of the Method

2.3.1 Business Processes

2.3.2 Validation Workshops

2.3.3 Validation Scripts

2.3.4 Validation Cases

2.3.5 The Gap List

2.4 Agile Organization and Agile Working Techniques

2.5 The Project Team and Stakeholders

2.5.1 Stakeholders

2.5.2 The Project Team

2.5.3 The Steering Committee

3 THE PROJECT

3.1 The Evaluation Phase

3.1.1 Project Initialization/Rough Planning

3.1.2 The Search

3.1.3 The Purchase

3.1.4 Consulting

3.1.5 Project Setup

3.2 The Implementation Phase

3.2.1 Exploration Cycle

3.2.2 Elaboration Cycle

3.2.3 Construction Cycle

3.3 The Transition Phase

3.4 The Utilization Phase

PART 2 THE WORK PACKAGES

4 BUSINESS PROCESS MAPPING

4.1 Approach

4.2 Work Packages

5 OPERATIONAL DESIGN, CREATION AND SUPPORT

5.1 Approach

5.2 Work Packages

6 IMPLEMENTING NECESSARY CUSTOMIZATIONS

6.1 Approach

6.1.1 Identification of Functional Gaps

6.1.2 Evaluation of the Options

6.2 Work Packages

7 DATA MIGRATION

7.1 Approach

7.1.1 Simple Scenario

7.1.2 Complex Scenario

7.1.3 Consolidation Database

7.2 Work Packages

8 VALIDATING THE SYSTEM

8.1 Approach

8.2 Work Packages

9 CHANGE MANAGEMENT

9.1 Approach

9.2 Work Packages

10 TRAINING

10.1 Approach

10.2 Work Packages

11 SYSTEM TRANSITION

11.1 Approach

11.2 Work Packages

12 DECOMMISSIONING OF THE LEGACY SYSTEM

12.1 Approach

12.2 Work Packages

13 PROJECT MANAGEMENT

13.1 Approach

13.2 Work Packages

PREFACE

Who is this book aimed at?

The book is primarily written for at employees of companies who have responsibility for implementing new software, but also for system consultants who have extensive knowledge of the relevant software modules but no experience of how to successfully carry out a system implementation in its entirety.

Why the book?

Implementing business software is no secret, nor is it witchcraft. For more than 40 years, software systems have been standard in accounting and business management. Standard IT systems have been implemented and used for just as long. However, the question arises as to why these implementations are still so costly, so fraught full of risk, and how these risks can be reduced. This book aims to provide answers to these questions.

What is included in the book?

Looking at the whole life cycle of a system, the implementation phase is in between the evaluation phase, the utilization/optimization phase and the deactivation phase.

Figure 1: Life cycle of a software system

The focus of the book is on the first two phases, i.e., evaluation and implementation. The usage and deactivation phases are covered only in relation to the other two phases.

What is the book based on?

The methodological approach presented here is based on the author's 25 years of experience in implementing ERP software. The methods Triton Target of the former company Baan, AIM for Business Flows of Oracle and the spiral model developed by Barry W. Boehm have been incorporated.

What is not included in the book?

• A scientific treatise on process models and methods

• A detailed description: "What is ERP?"

• A complete project management method

• Functional concepts

• Development projects, i.e. projects in which primarily software is created

How should one read the book?

The author is aware of the fact that non-fiction and technical books are rarely read from the beginning to the end, so here is a quick note:

If one wants to deal with implementation methods only theoretically, chapters 1, "Introduction", and 2, "The Implementation Method at a Glance", are recommended.

If you want to go beyond that, i.e. if you are responsible for an implementation, then Chapter 3, "The Project," should be added to your reading.

Part 2, "The Work Packages" should be read by the project manager; beyond that, it serves primarily as a reference work.

PART 1 METHOD BASED APPROACH

1 INTRODUCTION

A new Enterprise Resource Planning (ERP) system is to be introduced in your company - and you are in the process! This system is not just any system, it is "THE" IT system.

These are usually:

• the financial system with

• the general ledger,

• the sub-ledgers accounts receivable, accounts payable and fixed assets accounting

• the materials management system

• the customer management system/CRM

• the procurement system

• the order management system

• the production planning and control system

• wage and salary, payroll software

• personnel management systems

Not all these systems, such as “payroll”, are classically included in the term ERP, but the method presented here is also suitable for the implementation of such systems.

We are talking here about the system that

• records,

• documents and

• supports

your company's business processes and value creation.

Recording and Documentation

The recording and the documentation of business management and value-adding processes is a core obligation of a company towards its owners and society (state, tax office …). This has to be fulfilled by an ERP system.

Although value is created in the company, e.g. in production, by manufacturing new products, the manifestation/imaging of this value only occurs with a (stock) posting in the ERP system. This and all other bookings are periodically totaled and documented, e.g. in the month-end closing.

This is the most important aspect of an ERP system.

Supports

In addition, an ERP system is expected to provide support for business management and value-added processes, whether through planning or costing functions or by providing information to manage the company's processes. Sales statistics or material requirements planning could be mentioned here as an example.

1.1 A new system

Let's start with the necessity of a new system.

Why should a new system be introduced? The answers here are as varied as business life itself, yet the motivations can be grouped.

1.1.1 Business Necessity: Heading for New Shores

Young and old organizations often have the same problem:

The system used up to now no longer meets the business demands. This is the case in young companies due to rapid growth and changed processes, and in older, more mature organizations because the application is too inflexible or has too high operating costs due to old hardware and/or extensive customizations.

Challenge here: A new software is needed, and of course it should be able to do everything better!

1.1.2 Release Upgrades

It starts with the seemingly harmless information from your system supplier: "Your version is out of support_; you have to upgrade to a more current version."

The most frequent reaction to this is: "The software has been running smoothly for years and we rarely needed support anyway. Why not work with it in future.”

This is a mistake!

If you consider the strong interconnection of hardware, operating systems and application software, this lingering and waiting is not advisable! A trivial failure and replacement of a simple network component can lead to a necessary operating system upgrade, which is then no longer compatible with the application software, which in turn leads to system downtime.

This is a risk you should not take with a mission-critical system!

Unfortunately, the insight into the necessity of an upgrade is often accompanied by the realization that the software version used in the company is so strongly adapted that an automatic upgrade with the tools of the system supplier is very rarely or only to a limited extent possible. This implies that not an "upgrade" but a new installation that is necessary.

This includes the advantage of cutting off old braids (functions, which are no longer needed, but the EDP system requires) and to use additional functions available in the new version, as for example the customer management system.

Challenge here: The new version should be better, of course, and the familiar processes must work as before.

1.1.3 Drop-ins

In the globalized world, companies are constantly being bought, consolidated and integrated - or sold. The integration of the affected company units often leads to processes having to be standardized and streamlined under pressure from the new "parent company". In the process, the business system to be used in the future is often specified, and this is not always the existing one.

The challenge here: The new system is pushed into the business unit. Optimal support for the business unit is secondary to the standardization of processes.

1.2 Implementing Business Software, What Needs to be Done?

The activities that need to be done during an ERP implementation can be categorized into two areas.

• changes to and in the software

• changes in the company

Both activities require resources and therefore have an impact on the costs of the implementation and on the resulting operating costs.

It is important to understand that the implementation project always includes both areas and a successful project is characterized by having found the right balance here.

1.2.1 Change to the Software

Let's start with the less complex part, the software. The activities concerning the software can be summarized roughly into 2 groups,

• the configuration, thus the setting of the functionality and

• the customizations (reports, documents, interfaces, functions).

Figure 2: Change process

These activities are usually low risk if the requirements are correctly recorded by experienced consultants. If there is an explosion of costs here or deadlines cannot be met, this is usually a sign that the right balance has not been struck between the changes to the software and to the business. An early indicator is the gap list (see Section 2.3.5 The Gap List)

1.2.2 Changes in the Company

Activities in and on the enterprise are much more complex. New software, with its new, different, and unfamiliar functions and processes, changes the workflow of almost all employees. This means that all employees in the company will have to adjust. In some cases, they will lose their accustomed workflows and thus know-how, and they will have to learn the new processes. This does not always lead to enthusiasm, especially among experienced employees with a lot of know-how, because who likes to start from scratch again, even if it is only in the use of the IT system. Fears or an attitude of refusal can easily arise here.

Recognizing this is an important prerequisite for successful implementation because new software cannot be introduced without the cooperation of the employees.

In detail, the change activities can be divided into

• understanding and accepting the new business processes

• training the core project teams

• end-user training.

In the case of major changes, e.g. the switch from a decentralized to a centralized application, the support of an experienced change management consultants is advisable.

1.3 The Methodological Approach

Although the introduction states that this book is not a scientific treatise on process models and methods, it is useful to delineate the approach described here in methodological terms. By methodical approach, I describe the way (method) of arriving at a desired goal (procedure).

As announced in the title of the book, I would like to present a method for an "agile" approach and distinguish it from the usual "waterfall model".

1.3.1 Why no Waterfall?

In the past, many system houses and many customers still use a classic waterfall method in the implementation phase. The individual steps being:

• project definition and requirements analysis,

• draft with system design,

• implementation with programming and system construction,

• system test and

• operation and maintenance

applied.

Figure 3: Waterfall method

In these phases, a system is created or implemented step by step that meets the functional requirements described in a requirement or functional specification.

However, this approach has some disadvantages:

• It is rarely possible to definitively and theoretically define all requirements in detail at the beginning of the project. Therefore, there is a risk that the completed software or the implemented system does not correspond to the actual real requirements. To counter this, disproportionately high effort is often expended in the analysis and design phase without ultimately eliminating the above-mentioned risk completely.

• The waterfall method does allow changes to be made during the course of the project (change requests), but this has limitations, particularly in that it is only at the end of the project that the result is "presentable" and can be assessed by the user. As a result, the finished software does not reflect the current state of the requirements at the start of the project, but as a rule the (possibly incorrect) state of the requirements. Since larger software projects usually have a very long running time, it can occur that a new software is content wise already obsolete at the time of its introduction.

This method was and still is meaningful, if a high measure of specific requirements and/or additional programing is to be expected, thus the thought of the standard software into the background steps.

The Alternative

Due to the considerable increase in functions of standard software systems and the possibilities to adapt these functions to the requirements of the company through configuration, it is possible in today's world to significantly reduce the amount of individually created customizations. This is important because customization not only means high investments, but also because it significantly increases the maintenance and update costs of the new system.

In order to ensure or support that the individually created customizations are kept as few as possible, this book presents and describes a method that focuses on the functional possibilities of the software, which is derived from the Rapid Prototype approach and thus clearly differs from the classic waterfall method.

Derived from Barry W. Boehm's spiral model, the method runs through three cycles, in each of which prototypes with different degrees of maturity are created.

The prototype is verified in test workshops (VWS) at the end of each cycle. The workshops are numbered (from 1 to 3) and represent the respective maturity level.

What is Agile About It?

"Agile" is on everyone's lips. Hardly any IT department exists that does not claim to work "agile", as no IT expert can afford not to have already worked "agile".

If one questions what exactly is "agile" about their approach, there often is a wide variety of answers

They range from "Scrum !!!", "we don't need requirement specifications anymore" to "we don't need a plan, we do sprints". Thereby, neither Scrum per se is a guarantee for "agile" nor does the existence of a requirements specification leads to the fact that one cannot work "agile".

In most cases, behind the above statements lie the ideas of the “Agile Manifesto for Software Development”1. However, these ideas are difficult to apply to an ERP implementation because these projects are not primarily about the development/production of software, they are about the installation of a finished software and its adaptation into an organization.

So the question remains as to what we mean by "agile" in this book and why the agile approach helps us to successfully implement the standard software.

According to the standard dictionaries, agile means: “showing great mobility; lively and nimble”.

Thus, an agile approach is about the ability to move, adapt and, if necessary, also, makes changes within the project according to the requirements.

Of course, agility and adaptability are not always positive characteristics, as there are always situations in which it is necessary to act in a calm, stable and principled manner. Nevertheless, agility and adaptability are important success factors in the implementation of an ERP system, especially if one assumes that at the beginning of the project, as described above, many things are still open, vague and unclear.

The core requirement for the method is: if I accept changes in the environment and in the objectives as a normal feature of the project and if this is taken into account methodically or if mechanisms are provided for this, I am able to react to changes in the ongoing project without ignoring the roadmap and milestones.

Keeping the Balance

As I have already written in these sections, an ERP project always involves adjustments to or in the software and adjustment within the company. There will always be both! A successful implementation project not only has to meet the time, budget and quality requirements, but also has to find the right balance between changes to the software and to the business processes.