jump to navigation

Gathering ERP Requirements 01/01/2010

Posted by TBoehm30 in ERP, Project Management, Software.
Tags: , , , , ,

One of the most important steps of any software project, especially the choice of an ERP system, is to gather requirements. You need to know what is needed, what is wanted, and what you can do without. You need to have an idea of what to look for in a complicated system. You also need to have an idea of how you are going to be ready for the new system and what abilities you have or will need to implement the new system.

When you are looking at acquiring a new ERP system, you need to know what you want. The definition of ERP is very loose, and could include modules that you don’t need, or not include modules that you will eventually want. Before you look at new ERP systems, you need to take an internal look at your own company and document your requirements. Do you need manufacturing? How about accounting? CRM? Is a data warehouse important?

Most of the time, employees are too busy and too close the problem to accurately document what is needed. Consultants are great at gathering requirements because they have general knowledge of systems, and know how to talk to the people in your company who can best describe your desires. Where an employee can’t see the forest for the trees, a consultant usually keeps the big picture in focus while still understanding the details.

Gathering requirements has numerous stages. First the person or team responsible will identify the knowledge experts to interview everyone who might be important to the project. Some consultants will have a checklist or a set of questions already created to aid in the process.

Once the discussions have occurred, the next stage is analysis. The requirements need to be evaluated and prioritized. Priorities are important for people to come back to during the life of the project. To ensure the full use of these priorities, the requirements must be properly documented. They must contain very specific information so no one would be confused.

The documented requirements should be as specific as possible. Any vague descriptions or goals could lead to problems down the line. Some people may know exactly what they want, but if it is not described exactly they risk not getting what they want. They could also get a system that matches the requirements but doesn’t fulfill the needs of the company. Being as technically precise as possible is a key characteristic of good requirements.

Once the requirements are created, they should be validated. A team of employees or management should sign off on them. Having more people review the documents will lead to fewer disagreements down the line.

Finally, the requirements need to be managed. Once everyone knows what they want, it won’t work to put the documents on a shelf. They should be a living document that changes as new knowledge is gathered. Keeping the documentation current will allow parties to stay on the same path.

Requirements should include everything that you want out of a new system. Functional requirements are obvious; your system should provide all of the new services you need. Your documentation should also include non-functional requirements such as security plans, reliability expectations, availability, etc. You may need new space to put the equipment, you may need new training, you may even need to slow down existing schedules to get the new system going.

Some needs will be out of scope. It is important to not spend too much time on issues that won’t affect the project. If you are buying new software, some people may want to argue about the hardware that will be needed. You could wait until you get recommendations from the final chosen vendor before you choose the hardware. Debating the details before you are ready is just a waste of time.

There are many ways to get a set of requirements done. You can use prototyping, storyboards, modeling, state transition diagrams, use case analysis, or just plain text to describe what you want. No matter which way you choose, there are plenty of examples on the internet to give you a template to begin. Another reason that consultants are great is that they will have templates already created to drive the requirements project.

Most projects begin because somebody has an idea of what they want. Unless everybody knows what is needed, the project won’t succeed. Gathering the requirements is the step that will guarantee that everyone is working on the same path to success. Don’t be negative in the requirements, say what you want and stay true to the needs of the company.

I know that you can do a great job with those requirements. If you need help, then get it; because it’s a global world out there and Technology makes it happen.