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 compromised of the wishful thinking of a few dreamers, then no ERP vendor will touch it. But if you can capture changes that 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 position. 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 to 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 a 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.
If your business is considering an upgrade from outdated legacy systems, it’s time to start building a list of requirements for an ERP system. We can assist in identifying key problem areas within your organization and help you make the right decision on which business solution will be best for you. Contact allonline365 on firstname.lastname@example.org or +27 (21) 205 3650.
Resource Credit | ERPFocus