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.



1. Tweets that mention Gathering ERP Requirements « World Class Technology Discussions -- Topsy.com - 01/01/2010

[…] This post was mentioned on Twitter by Tweet ERP, Todd Boehm. Todd Boehm said: Gathering ERP Requirements: http://wp.me/pqzT0-2C […]

2. Hobie Swan - 04/21/2010

Your readers might want to check out http://mapthink.blogspot.com/2010/04/using-conceptdraw-mindmap-to-gather_19.html to watch a video on how to use mind mapping to gather requirements. (No, this is not some wacky new age thing. Mind mapping is used by most of the Fortune 100 as an alternative tool–one that emphasizes creativity and collaboration.) When you build a mind map with your client, it creates a very transparent process that can reduce cycles of assumption and miscommunication. And it will show your clients that you listen to them and, with their help, actuallly understand what they are saying.

3. Brett Beaubouef - 01/16/2011

Great post. Gathering requirements is not a single step but multiple steps. It is also important to understand the different approaches in gathering business requirements. For additional information check out my blog article on the best approach in gathering ERP requirements.



4. Edmundo Vado - 03/09/2012

where can i find or buy functional and non-functional pre-defined requirements templates?

Edmundo Vado

TBoehm30 - 03/09/2012

Edmundo: As a consultant, we have intellectual property that we don’t sell.  I have lists of suggested requirements that I can use to get started, but the most important part of that is to talk to the users to find out their needs. 

That is why a consultant is helpful.  I would talk to everyone at your company to find out what they are looking for in a software system.  I would then take that information and create a requirements checklist. If you find a template, free or otherwise, it most likely came from a software vendor.  The template would not be objective; it would be biased toward their own software. Good Luck, Todd

5. Tinie Timpah - 10/14/2012

Good to understand ERP requirements must read once before selection…..nice sharing

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: