Successful Implementation of ERP System (eBook)

A Handbook for Agile Management

Friedrich W. Espeter (Autor)

eBook Download: EPUB

2022 | 1. Auflage
141 Seiten
tredition (Verlag)
978-3-347-68901-5 (ISBN)

Infos

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

Project Manager (PMP/PMI) and Scrum Master (PSM I), has been working as a project manager in the implementation of standard software for more than 30 years. He was a manager at well-known American and European software houses and today works as a consultant on project management services especially in the ERP environment.

Textauszug

2 THE IMPLEMENTATION METHOD AT A GLANCE

Many companies feel the need to stay close to the standard software and hope to avoid escalating implementation and system operating costs due to minor customizations. The significant increase in functionality of standard software systems in recent years has made this possible. However, this requires an implementation method that focuses on the functional capabilities of the system.

In other words: How can I use the standard system to map my business processes and which functions, if any, are missing?

The following implementation method assumes the following boundary conditions:

1. the software is capable of covering at least 80% of the required business processes. This must be verified by the company during the evaluation phase!

2. a right of termination is contractually agreed, which, if the 1st boundary condition has to be revised after validation workshop 1, enables both contracting parties to withdraw from the contract or to agree on a different approach (e.g. waterfall method).

For the method presented here, the spiral model developed by Barry W. Boehm was adapted, focused and extended to the needs of implementation projects.

It comprises a phase model oriented to the course of a project with equally structured cycles and technically structured work packages.

2.1 Phases, Cycles and Milestones

Phases

Based on the lifecycle approach of a system, the implementation phase, which is primarily considered here, is embedded in the evaluation, utilization and optimization phases. These are partly considered methodically. A deactivation phase (decommissioning) associated with the lifecycle is only included to the extent that the decommissioning of the previous system is included in the scope of the implementation.

Figure 4: Phases and Cycles

Figure 3.1: Phases and cycles

Cycles

The implementation phase itself goes through three cycles, each of which creates system prototypes: the exploration cycle, the elaboration cycle, and the construction cycle, and then moves into use with a transition and go-live.

Figure 5: Phases and cycles in the spiral diagram.

According to the diagram in Figure 3.2, each cycle is divided into individual quadrants and contains the following activities:

1. requirements gathering and evaluation

2. concept for prototype

3. creation of the prototype or in the last cycle of the production system

4. planning of the next cycle

These activities take place in each cycle, but always more detailed and comprehensive.

• In the Exploration Cycle, the focus is on the system with its functional possibilities as a whole,

• in the Elaboration Cycle, the focus is on the individual functions in detail with the company-specific configuration then entered, and

• in the Construction Cycle, these individual functions are once more developed, including data transfer, adjustments and integration.

Milestones

The cycles are completed with the successful conclusion of the respective validation workshop (VWSn) as a milestone.

Only if the validation workshop is successfully completed the next cycle can be started.

2.2 Work Packages

In the context of implementing a standard software, the activities during the project can be grouped into work packages, such as business processes, system support, etc.

Figure 6: Cycles and work packages

These groups contain activities and work results that should always be performed or delivered, and those that should only be performed under certain boundary conditions. A list can be found in Part 2, "The Work Packages". This list also includes a numbering of the work packages.

The structure corresponds to:

<abbreviation of the group>.<consecutive no. in steps of 10>.

e.g. DUE.010.

If the same work packages are created for several topics e.g. the test script (actually SV.050) for invoice entry and the test script for production planning, this is provided with another index (e.g. SV.050.1 … SV050.2 … etc.). This ensures that each work package has a unique number in the project.

2.2.1 Strategies

As you can see in Figure 3.3, the domains have work packages in almost all cycles. These vary by area, of course, but all have as their first work package the creation of a strategy specific to the Area.

Strategies should not be doctoral theses, but all Areas should ask and answer the questions:

• What do we want to accomplish?

• How do we want to do it?

o What is our approach?

o What standards do we want to use?

o What tools do we want to use?

The answers to these questions must be clearly communicated in the project.

Communicating clearly means ensuring that the key stakeholders have received and processed this information. It is advisable to present the work results - usually a document that is subject to version control - in detail in a special workshop or meeting. For this purpose, extracts of the document can be summarized in PowerPoint or similar programs. PowerPoint presentations alone are not recommended because strategies must be referred back to as the project progresses and PowerPoint does not contain what is said, "the soundtrack."

2.2.2 Work package deliverable types

In order to structure the results of the work packages and the procedures of the work results, each work package is marked with a result type.

Document

Since requirements, definitions, agreements, strategies, etc. are repeatedly created in the implementation project and must be recorded in written form, the majority of the work packages described in this method have the result type "Document". In order to maintain an overview here and also to meet the required quality standards, it is advisable to adhere to the simple rules of document management and to control this restrictively.

These rules include

• the procedures and

• the standards.

If there are no guidelines for this in companies, here are recommendations:

Document Management Procedures

The following steps must be performed for all documents that are reviewed, approved, or revised. The format of the controlled document conforms to the project document control standard.

• Review, revise, and issue document. Each controlled document shall be reviewed and approved prior to issuance.

• Maintain controlled documents. Updates to all controlled documents are reviewed and approved. Changes to deliverable documents are approved in accordance with the project's change control process.

• Distribute updated documents. The document system used automatically notifies the document owner of any updates made by other project members.

Document Management Standards

Here are examples and recommendations for document management standards created in the project:

File formats and structure: there has been a bad habit in recent years of creating work results only in presentation forms (e.g. PowerPoint). However, in order to create and communicate authoritative and complete information, it is necessary that it be created in document form (e.g. Word). Presentations should only be used to present the information in aggregate at a meeting, if necessary.

• Document file name: All documents have the same file name structure: YYYYMMDD_<work package number><work package description>_<version> (e.g. 20220319_SV.050.1_Invoice Receipt_V1.1).

• Document storage and distribution: all documentation created related to this project will be stored according to the storage specification (PM.040).

• Use of a standard template: A template should be provided for the project that specifies a uniform structure for document-specific data (author, change index, etc.).

• Version numbering: all documents in draft status start with "X", accepted versions with "V", example:

o X0.1 - first draft version of document distributed for review.

o X0.4 - updated draft version of the document circulated for review

o X1.0 - a design risk/problem that arises due to major functional changes

o V1.0 - updated based on review and approved

System

The "System" result type in this method is simply a functioning computer system.

Software Configuration

With the result type "Software configuration" it concerns data/inputs in the system, which define or change the behavior of the system. They are saved via a data backup.

Acceptance

Work results sometimes require formal approval, not only for contractual reasons, but also to involve stakeholders in the project through decisions and acceptances. It is...

Produkt-Details

• Erscheint lt. Verlag: 11.7.2022
• Verlagsort: Ahrensburg
• Sprache: englisch
• Themenwelt: Mathematik / Informatik ► Informatik
• Themenwelt: Wirtschaft ► Betriebswirtschaft / Management
• Schlagworte: Dynamics • ERP • implementation • infor • Method • Oracle • SAP
• ISBN-10: 3-347-68901-1 / 3347689011
• ISBN-13: 978-3-347-68901-5 / 9783347689015