Fragment

A brief summary of the chapters

Chapter 1 You should divide projects into phases, provides an introduction to project phases. Even though the naming of project phases may differ from project to project, the activities that should take place during those phases do not. It is important to understand how projects are structured, and what goes on in each phase of a project.

Chapter 2, You should involve your best people in projects, discusses roles and teams on ERP implementations, focussing on internal business resources, who play the most important roles on projects. They provide the project with the knowledge it needs to implement new processes and a working system, and they are internal sellers of the changes the organisation is being put through. It is important to understand at the start of a project where they are needed, and to use as many of them as possible.

Chapter 3, You should treat external consultants like one of your own, explains how to get the most out of external consultants. Working with external consultants is unavoidable on a large ERP implementation. If it is your first time, it may take some getting used to. And even for the people out there experienced in dealing with them, this chapter contains a number of tips to help you maximise their output.

Chapter 4, You should use your own implementation methodology, provides tips for creating a methodology that fits your needs. Using an implementation methodology is vital to the success of an ERP implementation. It is more than a collection of templates, it should describe how your company “does things”. To make the methodology your own, this chapter pays special attention to using target application landscapes, non-functional requirements and architectural guidelines.

Chapter 5, You shouldn’t reimplement legacy, is all about defining scope, business cases and design approaches. When implementing a new ERP system, there is a strong tendency on all projects to make the new system fit into the old way of working. As a result, the new software resembles current systems a lot and its potential is not fully utilised. This chapter discusses ways of mitigating this risk.

Chapter 6, You should build a Knowledge Base, is all about keeping application and process information organised and accessible. Before an implementation starts a knowledge base process should be established and communicated to ensure all knowledge that floats around on projects gets captured, and all project deliverables are made to fit a company’s knowledge base.

Chapter 7, You should have a vanilla environment, is about defect management, defect ownership and vanilla environments. During test phases many issues will arise with custom or base software, integrations, conversions, etc. Streamlined issue triage is one aspect that is vital to the success of the test phase. Another aspect to this is SR ownership: companies should own their SRs as soon as possible as it builds knowledge and experience. Issue resolution itself is greatly helped by having a vanilla environment, especially where modifications are involved.

Chapter 8, You should patch, explains why you should define a patching and upgrade strategy. Often companies forget to plan time and budget during the implementation to allow for patch upgrades. When the project runs for a long time, software issues may accumulate and require a patch upgrade. The project plan should have enough time allocated for retrofitting modifications, potential tech stack updates, regression testing, conversion and configuration updates. Having an upgrade strategy will help the implementation team focus on the (re)usability of all deliverables.

Chapter 9, You shouldn’t modify, unless you really have to, clarifies why modifications should be avoided as much as possible. Organisations often try to recreate legacy in their new system, because thinking outside the box is difficult. All business processes must be reviewed end-to-end, which will enable more opportunities to push out modifications. If modifications are inevitable, make them “bolt-on” as much as possible to stay on the upgrade path.

Chapter 10, You should have a proper design and review process, will help you design your design process. The quality of design documents, whether they are high level designs, functional designs or technical designs, increases dramatically when a thought through and documented design and review process is established. This does not mean designing and reviewing will take up more project time and budget: it will save you time.

Chapter 11, You should assign data owners, explains why data ownership is key to good data. Data owners come in two varieties: systems and people. Every piece of data should have a master, i.e. the single system in which this data
is maintained and sourced from to other systems. And every piece of data, or rather data entity, should have an owner; a person responsible for maintaining data integrity, the data model, and the integration of the data across systems.

Chapter 12, You should clean your data, discusses why data cleansing, conversion testing and conversion sign off is important. Data conversion is often underestimated by projects, in terms of complexity and in terms of effort. Conversion of data should be an automated, repeatable process that is executed in a dedicated conversion environment.

Chapter 13, You should support your people after go-live, talks about the importance of post go-live support, and how to best organise it. ×