5 steps to successful ERP requirements gathering
The right requirements are absolutely essential to choosing and implementing any ERP successfully. These steps will help your journey begin well.
This article will cover:
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 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.
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.
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.
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”.
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 might 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.
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. ERP can lead both to make the same choice using the method management wants to use and possibly the method the customer wants to use as well.
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 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.
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.
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.
Featured white papers
ERP Software Pricing Guide
Get your comprehensive guide to the cost of ERP softwareDownload
70 features to look for in your next ERP
A comprehensive guide to help you identify requirements for your ERP selectionDownload
60-Step ERP Selection Checklist
Get the comprehensive checklist for your ERP selection projectDownload
Five of the most important things to look for in ERP selection
Our most recent guest blog from abas USA
A guide to the ERP life cycle
The stages of the ERP life cycle
Four of the top ‘free’ ERP systems on the market
When it comes to free ERP software, it pays to remind yourself of the old adage ‘there ain’t no s...