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”.)

Recommended Reading: ERP Selection Survival Guide - Start your ERP selection process right with this guide

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.

Expect Tension

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.