How to gather requirements for ERP
The ultimate success in ERP software requirements gathering is not only to capture everything that the current business process does today, but also to compile a list of realistic “should-be” changes. The term “realistic” is important, because if the should-be list is largely comprised of the wishful thinking of a few dreamers, then no ERP vendor will touch it. But if you can capture changes which are reasonable, and would improve the process, then you can simultaneously ask, “And how much would that be worth to you, if we could do that?” From that point, financial benefits begin accruing, and you are starting to compile the data required for a justified and proven ERP ROI.
Quantifying the financial benefits from ERP software has always been a dicey proposition. There is no accounting entry for “improved efficiency”, “better decisions”, or “greater understanding”. So if your ERP requirements gatherers are good, they will coax along the thought process using those intangible phrases to try to get at things that are, in fact, tangible. “Where will improved efficiency show up? How can you recognize improved efficiency?” (Side note: No rumor will insert more negative energy into ERP software requirements gathering than the perception that ERP is going to “put a bunch of people out of work”.)
When it appears ERP would, in fact, be able to eliminate non-value-added work, the discussion should be in terms of re-assigning people, not eliminating people. Every organization has turnover that requires backfilling jobs. “What is the cost of bad decisions today?” may lead to some quantifiable discussion about inventory obsolescence costs, lost sales, or poor choices in product development.
Typically, the tangible benefits side of ERP software requirements gathering will result from reduced working capital and associated carrying cost, reduced manpower, reduced obsolescence cost, greater material, and product yield, and service improvements leading to revenue increases. Expect some tension at this point, as ERP requirements gatherers push for every possible benefit dollar, and the business unit pushes back on commitments they may be called upon to verify, and that they may live to regret.
Relative to its eventual importance, requirements gathering is the most under-appreciated yet tactically critical step in the ERP selection process. The ERP requirements list will serve as the basis for all ERP vendor discussions, for the eventual ERP software contract language, and for the basis of your vendor relationship going forward. Get it right, and you have a common language for holding vendors accountable, for realistic ERP product comparisons, and for guiding configuration decisions. Get it wrong, and you will spend inordinate amounts of time trying to unravel what was really meant by ambiguous requirements.
After you have been through the ERP software requirements gathering phase, you will pretty much know whether you have a compelling business case or not. If you do, it’s time to sell the case to your leadership and get project approval so you can begin talking with ERP vendors in good faith.
Featured white papers
70 features to look for in your next ERP
A comprehensive guide to help you identify requirements for your ERP selectionDownload
ERP Software RFP Guide
The comprehensive guide to developing an RFP document for your ERP projectDownload
ERP Selection Survival Guide
Get your free survival guide to ERP selectionDownload
Five great ERP features to engage millennial users
These five features are must-haves for millennial users
ERP and cryptocurrencies - where do we stand?
How can we expect cryptocurrencies to impact ERP in the future?
Five construction ERP systems to consider
Include these ERP systems when selecting or comparing construction ERP