ERP Requirements Gathering: “Obsessives Wanted”

Almost no organization decides suddenly that ERP should be the next capital investment. Usually, an ERP project is a gradually escalating idea, beginning with a person or small group being given permission to explore and develop the idea sufficiently enough to be turned into a legitimate business discussion. Conducting a legitimate business discussion requires forming some kind of defensible idea of how big (“big” simultaneously equals “cost” and “time”) the project is and what the tangible benefits might be.

The size of the project, and the benefits of the project, result from a step known as “requirements gathering”. As the name implies, requirements gathering is the process of obtaining and writing down a detailed list of the activities that an ERP system must be capable of handling. This list is used as the fundamental basis to enter into discussion with ERP vendors about the capability of their product to satisfy your list of requirements. Later, if the project progresses far enough and a contractual agreement is made, fulfilling your list of needs can become a legal requirement.

The Devil is in the Detail

As you can imagine, the key to requirements gathering having value is getting down to gory details. For instance, if you list as a requirement, “Be able to take a customer order”, any vendor would be able to say their ERP product does that. “Be able to take a customer order in any unit of measure and in any currency” is a more detailed definition. “Be able to take a customer order in any unit of measure and in any currency over the internet” is an even finer description, and not every ERP vendor would likely be able to respond affirmatively to that requirement. Assuming you plan to do multiple modules – finance, planning, sales and distribution, purchasing, manufacturing – then the right level of detail will probably result in between five hundred and twenty five hundred written requirements.

Clearly, requirements gathering requires patience, an obsession for detail, and the business knowledge and communication skills to get people to articulate nuances about their job that they might take for granted. It is very possible that requirements gathering will be done by someone or some group other than the eventual ERP project manager or implementation team. Take a moment to think about a few processes that are outside the normal core operations, say freight accounting, legal entity structure, purchase requisition approval, asset management, sample delivery, and exporting. Would you know all the questions to ask? What the documentation problems were? Where legal boundaries exist? For this reason, it may be a very good investment to hire an ERP consultant with requirements gathering experience that can help tease out answers from these types of specialized knowledge areas.

Requirements gathering is a thankless task. If you can find people who do it well, nurture them and give them what they need. The payback will be enormous.