5 steps to successful ERP requirements gathering

The right requirements are absolutely essential to choosing and implementing any ERP successfully. The ERP you eventually select will be made based on the requirements you define for your organization. All your conversations with ERP vendors will center around how well each of your requirements are met. Keep in mind that some of the most important customers of the ERP system you eventually select are the users in your own organization. Be sure those customers are satisfied. These steps will help your journey begin well.

This article will cover:

1. Putting your ERP requirements team together for selection

2. Creating your ERP requirements plan

3. Finding your pain points

4. Ensuring your ERP requirements match your lean processes

5. Making your requirements SMART

1. Put your team together

Form a team of people who will work to develop successful ERP requirements.  Core members of this team will be SMEs (subject matter experts). ERP is an enterprise-wide system so aim for at least one SME from every functional area or department within your business.  Each business is unique but all have finance and sales. Others will include software development, production, supply chain, engineering, and perhaps external compliance experts. While there is no magic number of SMEs to include, if your conference room overflows, you might need to make some cuts.

Your team can include people from outside your organization too.  You might want a consultant with recent experience developing ERP requirements, and this person might sell systems, as long as they attempt to remain agnostic about recommending their product during this phase.  Your financier could want a seat too. If your business support is venture capital or your business is a subsidiary of another, ask the people who pay your bills. They likely will insist on being a team member.

GET ERP RESEARCH & KNOWLEDGE RIGHT TO YOUR INBOX

Covering the key issues faced by businesses selecting and implementing ERP.

Get your management on board right away.  You might already have asked someone from the executive management team to join.  Do not leave this group off the core team. Nothing will happen without their support.  This team member will be a liaison to the executive group. You also will benefit by incorporating executive management requirements.

Now the core team is almost ready.  The next step is to include users from all the business functions in an auxiliary group.  Identify people who will take an active part as needed. Find users who communicate well and can balance their individual wants against the business whole needs. These people will be “super users” as the ERP implementation proceeds. Some will also work as trainers in a later phase of the implementation. All of this group will serve as local mentors and examples spread across the business providing guidance and mentorship to the remaining users.

2. Make a plan

Your team effort now needs a framework of operations that will ensure every potential requirement will be mentioned and evaluated.  One common approach is to work through each department and functional area. Each will have suggestions that benefit their department.  We all need to know, “What’s in it for me?” and this approach ensures everyone has some gain on the board. The benefit for finance might not even consider purchasing, for example.  However, purchasing has an opportunity to temper the finance suggested requirement with a version that considers both sides and allows collaboration.

Another approach is to work along process flows.  How does your business receive new customer orders?  What is involved around delivering that order to your customer?  Who produces the order and what steps do they take? Most processes flow through more than one functional department.  Often we find that the requirement turns out to be the handoffs and not the work needed within any department.

There is no single right approach.  Choose one that makes sense for you and your team and stick with it until you have a long list of possible requirements. Your team will document as many requests for some need to be included as a requirement.  Then, the team will rewrite the statements so that the benefit is shown as to the entire enterprise and possibly modify some that were skewed toward a particular function so they are more balanced for a business-wide benefit.

Once all agree on a list of requirements that a new ERP can provide, the next step is to prioritize those requirements.  In the unexpected case that some requirement cannot be met, we want to ensure it would only be a low-priority point.

The last step at this point is to list benefits that were not scored as requirements but clearly would be beneficial.  If the new ERP can provide for any of these “Nice to have” benefits without prohibiting any true requirements, we want to take that advantage.

3. Where is the pain?

We all have tasks we prefer to delay as long as possible.   Anyone in your business can probably tell stories about some process that makes no sense from their perspective.  With this step, we will begin to refine the suggested requirement list. Understand where the pain points exist within your organization and verify that your requirement list includes a remedy for those pains. ERP is implemented to fix a problem, or improve a part of the business, in fact, the top reason for implementing a new system is to improve efficiency according to the latest ERP report data. What is your business looking to get from the new system?

Get your free comprehensive guide to developing your ERP requirements with our ERP software RFP guide

For this step, go outside your core team.  As many people as possible should get a chance here to contribute.  Your janitor might have some pain no one on the core team ever considered that has surprising value for the business.  How will you know without asking? Consider developing a questionnaire that people can fill out and leave in the suggestion box.  Make up an online survey using Survey Monkey or another popular application. Bring people together in focus groups similar to the way many consumer products are developed.

You might want to extend this search for pain to people outside the organization.  Imagine that a person you will never meet has a pain you unknowingly cause. The receiving clerk at your customer wishes you made deliveries through another carrier because the UPS schedule did not fit that person’s daily schedule.  While this example might not be an ERP requirement, it shows the possibility of a pain point no one within your business could be aware of.

You can now rewrite your original suggested requirements list in a form that eases those pain points and specifically indicates the value to be added to the business.  One of the original suggestions could have been, “Better flow of work enabling accounting to have preliminary financial statements by the fourth workday each month”. We have now learned that incoming quality inspections were a bottleneck and the inspector suffered pain each month when accounting applied pressure to perform inspections faster than possible.  Now our requirement reads, “An ERP that allows automated transactions and workflows so that the time to complete 14,000 transactions monthly can reduce from an average of 12 seconds to less than 6 seconds saving $21,000 monthly in transaction costs”.

4. Aim for lean

Think of lean as in reducing waste.  Go back and re-read Ohno and some of the authors who started the lean movement.  Your ERP project might not have considered lean. Likely, some of your requirements are related to lean.  What work do you perform that your customer would not want to pay for? Does your inventory only move just in time to enable a customer delivery?  Inventory is not just physical items but might also be software development that should move along a schedule so do not limit your thinking to products in work in process or waiting for sale in a store shelf.  Where do you allow known defects in a process that have to be cleaned up before the process is complete? Is the right quantity of everything in your supply chain or is your purchasing manager overproducing with the hope of saving unit costs?  We all do some things that violate lean and we usually have good rationalizations to permit our actions. Find that waste in your organization and use ERP to trim the fat. This could mean adding a requirement to your list. It could also mean you restate one already listed.  Hopefully, you haven’t added a requirement that will produce waste.

Reduction in variability is another benefit of lean.  In many situations, a person might choose multiple possible actions.  There could be two actions with the same likely benefit. You can use ERP to help people at all levels in your organization to make decisions that optimize the good for the whole enterprise.  That decision could be at a high level – selecting a new supplier for a key component of your next product. It could be on the shop floor too. Should a user start work on the next operation now before all the needed components are on hand?  If the missing component is already on the way, maybe the user can begin work with some confidence. If not, maybe that user should start a different job even though the first job will be late to the customer.

Use our free ERP features guide to create a list of requirements for your new ERP system

Two workers extrude plastic on similar machines. One worker prefers higher heat and lower pressure and the other prefers the opposite. Both base their choice on experience and training and both techniques can result in a product that meets a customer’s requirements. ERP can guide both to make the same choice using the method management wants to use and possibly the method the customer wants to use as well. This guidance resides in the shop routing system that is already a component of every manufacturing ERP system.

5. SMART requirements

We all know about SMART goals.  Make your ERP requirements SMART too.  They should be specific, measurable, attainable, relevant to your business, and time-based.

By now, your requirements should be specific.  They came from your functional or process framework and they will help your business run lean.  Think carefully about how you will measure what benefit this requirement will produce. You will use this measured benefit against the costs of your ERP later on to calculate the return on your investment.  Check that you can measure the benefit too. While you think you will save time using the new ERP, you should have a stopwatch in your hand to make the measurement. If you cannot measure or predict a money benefit, consider skipping that benefit toware ROI. a mere possibility you will reduce your workforce should not be considered as there is no money benefit until the workforce is actually reduced.

Be sure the requirements you ask for are attainable.  Asking for a four-day accounting close could be realistic but asking for a four-second close might not be.  All your current requirements are desirable but watch out for some that no ERP can get for you. Do not wait for the ERP sales person to say that requirement is unrealistic.  Weed your own garden. Weed out the irrelevant requirements too if any remain on your list at this point. Whatever ERP you choose will be a beneficial tool. However, ERP will not show the pot of gold at the end of the rainbow.  Is every requirement something that a new ERP can help you attain?

ERP systems have a lifespan.  Most businesses consider an upgrade every decade or so.  Here is where your time basis comes into play. If your requirement will take twenty years to pay off, this ERP will probably not provide that requirement and might not help progress enough.  

Conclusion

Use these steps or gather requirements using a different plan.  But certainly, have steps that will lead your business toward selecting the best ERP for you now and into the future. Develop your own prioritized list of requirements and supplement it with a list of additional benefits that are not requirements.  You will use this requirement list against each potential ERP provider’s offering.  Any proposal that does not satisfy every requirement in your eyes is a proposal to be eliminated.  “Almost” is not an argument you  can accept from that bidder.  Your requirements are just that and must be satisfied.

Be obsessive about developing your ERP requirements.  Tom Stephenson wrote ERP Requirements Gathering: “Obsessives Wanted” eight years ago and his comments remain valid.  Your business will use the ERP tools you choose for many years and you  want them to be the best tools that fit all your user’s hands well.

These requirements will shape the expectations of your users, your management, your customers, and all stakeholders.  Promise them what they need and deliver on every one of your promises.