Evaluating, learning, configuring and going live with a new ERP system is arguably one more risky and rewarding projects an organization can tackle. The purpose of this site is to share knowledge and practices that served me well for more than ten years.
The Plan
Here is a sample ERP implementation plan based on my experience. The typical company (with revenues between $20M and $200M USD) can go live with an ERP implementation in between 6 and 12 months. Customization, additional audit requirements, and advanced reporting can extend the project. I have been a part of projects that have taken two years because of extensive customization and testing. I have yet to see a company go live in less than six months.
It is worth highlighting that the plan does not call for you to create your own client until the end of the learning phase. The means that you will use the GardenWorld sample client for much of your experimentation in accounting, material management, customization, etc... Doing so has the following benefits:
You will minimize the effects of mistakes, abandoned ideas, and bad data in your 'real' client - the client you use when you go live. The learning process requires experimentation. Experimentation leaves a lot of waste. You do not want this waste in your production system.
You will minimize the amount of time you spending maintaining two sets of live data (Business Partners, Products, etc...). You synchronize your data as late in the go-live process as is possible. Once on import live data, you must maintain the two copies simultaneously. Otherwise, you will repeat the import process.
Here is a sample ERP Task List. As you work through the implementation plan, you will uncover tasks that need to be executed. This sheet helps you track what tasks, who owns them, the task's importance, and their impact on the organization. The above implementatation plan (calendar) helps you organize the topic of your focus for a given week. The task list helps you organize all outstanding items. You might reach then end of your implementation plan and still have outstanding tasks that need to be executed before go-live. Here is a video that describes the Task List.
Maintain The Right Goals
In the above Task List video, we identified two ways for a CEO, business owner or project owner to identify when a go-live date is not feasible. This begs the question"which is more important - hitting the g0-live date or achieving a successful go-live?" In my experience, the project owner's single most important goal is to 'protect the organization'. Going live with an ERP system and a group of people who are not ready is the single best way to violate that goal. Said another way, achieving a go-live date falls well below the goal of ensuring the system and your people can perform with near perfect execution. Communicate this point often: "we will be ready when we go live - we will be successful!"
Project Documentation
There is an amazing amount of knowledge and skill to conquer when evaluating and ERP system. One of the worst killers of budget and accurate project planning is having to repeat yourself and re-learn concepts. Good documentation eliminates virtually all duplication. I recommend that you keep at least three primary documents:
Meeting Notes - a single document where you record links to docs, questions, decisions, actions, etc... Each new day/meeting will have its own new section/heading. Being able to search through this document will save you hundreds of hours.
Work Instructions - a single document where you write the instruction of 'how' to use the system to perform specific tasks. This document will start simple and will only gain complexity as needed. Make this document editable by everyone. Encourage all to make it better.
System Administrator - details of how you installed and configured the test and production servers. Include all information needed to replicate the process. Also include information about backups.
Other documents that I recommend you maintain:
Scenarios - describes scenarios where you exercise the system for specific tasks. This document will be the basis of how you test all your employees. The scenarios themselves do not tell you how to use the system. They simply describe the circumstances and the needed actions. These documents describe 'what to do'. This is stark contrast to work instructions (operations manuals) that describe 'how to do'.
Happy Path Scenarios - These are your most dominant scenarios. You will probably only have 1 to 3 of these scenarios depending on the complexity and variety of your business. These are typically two pages of bulleted actions. They describe end-to-end processes. A single happy path scenario will address at least 70% of your system's functionality.
Corner Case Scenarios - These derivations off of your happy path scenario. These documents are typically much shorter. You will have many corner case scenarios
Ticketing System - create a way to log issues and required actions.
When creating a high volume of documetation, organization is important. I recommend creating a folder (say in Google Docs) to hold all artifact. I used a document numbering system to organize all documents:
0000 Readme - this document includes all project summary information. It should be no longer than 1 page. It includes this outline, mission, vision, etc...
1000 Meeting Notes - if your document gets too long, move the current document to 1010 and create a new 1000 Meeting Notes document. Most projects will only need one meeting notes document. Informal side discussions can be held in separate documents (example: 1050 credit card processing meeting notes, 1060 ...).
2000 Scenario - documents including the primary happy path. Other dominant happy path scenarios will have document numbers like 2100 or 2200. Corner case documents will be incremented by 10. Here is an example: 2200 primary happy pass will yield 2210 corner case.
3000 Work Instructions- documents that describe 'how to do' things. There will be many work instructions. Try to avoid screen shots. User interfaces change too much to include in these documents.
4000 Integration - documents that describe how iDempiere will integrate with other systems (credit card, website, etc...)
5000 through 7000 - your decide
8000 - system administration documents. The 8000 document will include all details about production and test systems (IPs, usernames, passwords, etc...)
Create a War Room
ERP Implementation is a highly communal process. I recommend you create a communal resource where people can go to concentrate on the ERP implementation requirements. I call this resource the War Room. Here are some attributes of the War Room:
It has multiple computers where cross-functional teams can interact with iDempiere at the same time. This means that Order Entry can be creating orders while Receiving is receiving orders while Accounting is processing invoices while fulfillment is picking and packing orders while Managers are watching metrics.
It prominently shows the project objective (what you do every day to achieve success) and the vision (the picture of the world to come) statements.
It prominently shows the project schedule/plan.
It has papers taped to the walls everywhere. There should be question about where to find stuff.
Office hours should be maintained. There should be ERP experts available to the mass users at posted times. These are times when users can go in and test the system given their day's real-life scenarios.
This is where documented scenarios (see above) are tested across cross-functional teams. This testing process ensure the right subject mater experts are available to make the right decisions.
If you have a decentralized team, the same concepts apply. Your War Room may be and Intranet site coupled with TeamViewer/GoToMeeting/WebEx. Your virtual War Room will probably look very similar to my open discussion sessions.
End User Documentation
As you get closer to go-live, you will want to start to create end user documentation. This concept is a daunting task. The goal of this section is to give you guidance and options.
iDempiere Documentation - the single best place to document how to do something is within iDempiere itself. Each window had a blue question mark in the left corner of the toolbar. This icon opens a help file for your current window. The window has a description. Each tab has a description, and each field has a description. As you work in the War Room, try not to answer the same question twice. You accomplish this task by updating the help documents as you are asked questions.
Operations Documentation - there are a few tools for documenting how users interact with iDempiere. The big question is "how much is enough documentation". I believe is documenting the bare minimum that ensures user success. I do not recommend including screenshots. Bullets and links to other topics are sufficient in most cases. If iDempiere's help is updated adequately, your operations documents should just be skeleton instructions for how to get to the right window or workflow.
Wiki - I am not a fan of wikis. There are better and more user friendly options.
Google Documents - if your organization already uses Google hosted apps, I believe this option is the best and the easiest.
Wordpress - If you are not going to use Google Documents, then Wordpress is your next best options. It has many many plugins to ensure stability, security, accibility, etc..
Hugo - probably the most geeky option, but also one of the coolest. It scales massively, requires very little hardware. and is pretty easy to use once it is setup. User interact with normal files to create pages. There are many markdown editors that make creating pages easy and intuative.
2014-04-10 AM - Project Planning and Creating your First Client
ERP Gone Wrong - What Not to Do!
All American Semiconductor was the $300M darling turned bankrupt due to a failed ERP implementation. Below is the bankruptcy court case. It highlights is detail the great demise. They actually use the word "demise" in article #17. Search this article for 'ERP' for more information.
All American Semi Conductor Bankruptcy ECF_DOC_2177_9174332.pdf
This event occurred during my first major implementation. We studied the situation carefully. Many of my implementation practices are a direct result if this situation so many years ago.