Implementation Best Practice

This Wiki is read-only for reference purposes to avoid broken links.

The original page was written by Michael Judd. Other contributions come from:

Introduction

When embarking on your first Adempiere implementation, either as the implementation partner or within your own business, can be daunting. There are many things you think you know and many things you know you don't know.

Even after many implementations, you will find each implementation has it's own special challenges. In this page, I am documenting my experiences and advice, and I invite others to contribute their implementation best practice tips.

Defining the Project

In the theory of project management there is a box with four quadrants which project managers are encouraged to consult before starting any project. It looks a little bit like this:

The "How" and "What" questions are "What are we going to do" and "How are we going to do this". If you don't have the answers to both of these you shouldn't start the project.

In general, you can reduce the risk of a project by breaking it down in to smaller, more manageable segments of phases. Start with a the lowest risk and highest return area and deliver those benefits on time. This requires you to prepare and manage a project plan - so engage in this effort early and make sure you involve all of your project team.

In deciding what you are going to do I find it helpful to have a map of the business process as it is. This can be used to map the change in business process before and after the implementation, but also serves to focus the organisation on their business process (which often need to be solved first) and teaches them the language to communicate issues and the techniques to solve process issues.

Assemble the Team

Enterprise system implementation can touch every part of the organisation by definition. You team should include:

1. people with excellent knowledge about the functions of the business and how the business currently works
2. Project management
3. domain experts who understand the environment in which you operate
4. product experts who understand and have control over the configuration of the product
5. technical experts who have machine code tattooed to the insides of their eyelids and generally make computers work

The exact number of mix of people will depend on the functional scope of the project, the industry and the size and maturity of the business amongst others.

Most organisations will only be able to contribute staff from the first and second categories. Often it is not economical to have full time employees that have skills in the other categories. Implicitly, this means getting a team of people who may not already know each other together to deliver a high value and important project in your business. It is advisable to spend some time to help you team bond and a few early quick wins are a good way to help form team cohesion.

Manage the Organisation Change

One of the main benefits of implementing ERP is the focus that it creates internal to the client organisation around understanding their own business process. It may be the first time that organisation has truly understood their entire business and the people who have been on the journey in the project will have a great deal of new skills and in depth knowledge about the business. They will have access to the business process charts and have contact with the process owners. They will have higher access privileges to the system and new data will be available to them.

Free Up Key Internal Resources

The people recruited from inside the business to form part of the implementation team will have a been pulled out of their day to day jobs because of their expertise in the business. This resource issue must be addressed early in the proejct plan - those people are unlikely to be able to do their old day job and work on the implementation. If they are unable to free up their time, you will have a bottleneck and this will slow down your implementation - and perhaps even stifle it altogether.

Retain Knowledge & Reward New Skills

The people in you business working in the project team will become more skilled as they work on the project. They may learn more about the business processes and help to design new processes. They will may learn new skills like process mapping and flow charting, influence management, dispute resolution, as well as specific domain knowledge about your products and services, your business and the system.

At the end of the project, it is important not to loose these skills and the people may not feel so happy to return to their own jobs. They may decide to take their new skills elsewhere and make some more money. There are many aspects of staff motivation and retention and I am not able to cover them in this page. However, you should give consideration to what skills people are developing and what their value is to the business. Some people may be more suited to analysis (with more high quality data being produced by the system), some people will have more power and influence because of their understanding of the business and the value these people can contribute to the business will probably increase. You should be aware that the ongoing success of the system requires this knowledge to be retained in the business (especially as many projects run over a number of stages). My advice is to identify these people early in the process and the plan to retain them by creating a new or enhanced position for them after the project and to find other ways to motivate and recognise their new skills and contribution.

Implementation Methodology

So you've had the sign off on the project plan and the project is finally under way! So where do you start first. Well this is not the time to throw away the project plan - go back to the milestone and the project tasks and start there. In the following section I'm going to briefly describe some of the 'things' we do when we implement that you may find useful.

Understanding the Software Sales Process

Many other software vendors start by demoing their product and then trying to 'help' the customer write a specification so the customer can evaluate the playing field. Whilst it is very generous for software providers to do this, the reality is they do it because it helps them hit a "home run". So what is this "home run"? Well sales people like to help you specify the solution because they can influence the criteria towards their products strengths and frame the analysis in such a way that their product will win the bid. They show you the product early, because the human mind likes patterns and once you have been exposed to something it is more difficult for your mind to think of something else. Try this out. Whilst your sitting their in your office at your computer pause for a moment and look around the room for all the items you can see that are the colour red. Look for the person wearing a red jacket, the weird guy wearing red socks and braces, and the annoying woman who sits behind you has a photo on her desk of her son sailing a boat with red sails. OK - so do it now - take 30 seconds and come back here........... OK you are back! Now tell me how many green things you spotted? (Well don't tell me - I wrote this article some time ago actually) Perhaps you cheated and read ahead to find the 'trick'. But if you did this you may have found it slightly harder to name the green things than if you had just looked around the room. In fact, by focusing you mind on the red, people's minds tend to ignore the other things they see (You can read more about this and other limitations of the human mind in books by Edward De Bono - the guy who is attributed with the invention of the term "Lateral Thinking")

Anyway, the point is that before too long you will be ready to buy the product without really understanding the problem. First seek to understand and to do this - you need to break out of the traditional software sales model.

Start with the Process

In order to understanding the problem, start by understanding your business and your business process. We start by doing some analysis of business process. Sometimes this is limited to a very small part of the process - usually the issue behind why the customer first approached us. Sometimes this is a department or function or the entire business. Remember, it is easier to break down the problem in to smaller chunks.

We work with some functional people within the business to do some process mapping which could be used to evaluate software at a later stage. This means you match the software to you, rather than match you to the software. It also means that you understand the current process even if you might not understand how to solve it. Don't worry about solving the problem now - that's where expertise of your implementation partner comes in.

We use "swim lanes" to denote the actions of certain actors, putting the time dimension at the top going across the page and having the process chart work across the page from left to right, top to down. We number each of the process objects and where process objects link to objects on other process maps, we identify this and keep a handshake list to ensure that when we think we send this report to 'sales' - we pick this up when process mapping the 'sales' area and make sure they actually do something worthwhile with that report. In one project, we were able to eliminate 130 heads from a finance function because no-one was using their output that the produced to a high standard and distributed month in - month out.

Here's a simple example:

As you process map your business processes, keep a log of them and the versions. Teach the people in the organisation how to create the charts and how to modify them. If the business doesn't have software to help them with this, consider getting some. We use Dia which is open source: http://www.gnome.org/projects/dia/

Always identify process owners, the people who are responsible for the process. They need to be consulted if a process needs to change and they should be able to identify issues and negotiate with other process owners if this is necessary (and it usually is). Ensure that the process owner knows they are the process owner and ensure they understand their responsibility for the process and to keep it updated. They may find it helpful to have a talented member of their staff to actually do the hack work for them on the computer. They should understand their process maps and be able to use them as a communication tool with other people in the organisation and their own staff

Scenarios & Testing

Once the process maps are changed, a technique for ensuring you have covered all of the functionality in the solution is to go back through all of the process maps and the various routes through them and construct a test for each scenario. You can then use the tests to confirm that the system performs all of the processes the business currently has. As you do this, map the screens to the process maps - apart from being a useful start to comprehensive testing, it will also server as part of the customers documentation. You may also find it cost effective to have someone in the organisation help with this. It assists the staff memeber(s) to build confidence with the system and embeds system knowledge and the culture of exploration.

Get one in early

One of the problems with projects is that you will start the project with a great plan and things will change. People will get ill and have extend periods of time off, new areas of functionality will become 'must haves', the data from the old systems will be 'dirty' and the business will open five new stores and perhaps even undergo a management change.

We have to operate effectively in this environment of change and that means recognising it when it happens and managing it. So when that first change occurs that is going to cause extra work to be done - get a project variation in early. Ensure it goes to the person responsible in the business for the implementation project with an explanation of what has changed and outline the additional work required. If you can quantify the additional work, do so in the project variation. If it requires some further investigation, ask for approval of that investigation and then move to quantify it as soon as possible. It may be that the additional work is not required and the project sponsor can decide this. It will help you to manage change and for all parties to recognise that change occurs and we have to manage it proactively.

Going Live

1. Make sure you have thoroughly tested all of you scenarios and the users have also tested them.
2. Phase your role out if possible.
3. Have plenty of people from the project team around on the day to help the business cope if necessary.
4. Have some handy references (perhaps on paper or card) for staff to guide them through critical tasks.
5. Ensure your timing doesn't conflict with business critical times (such as the 'holiday season' for retail businesses)

Summary

Unfortunately, that is all I have time for today. Please feel free to add your own tips here and add your name to the contributors list at the top of the page.