Defining business requirements for ERP: Where do you start?

By now you know that ERP should be treated as a business project, part of a larger transformation project. You probably also know that ERP success depends on your business’ ability to find an ERP vendor that’s capable of meeting your business’ key requirements. But, you’re probably wondering, “What the heck are business requirements?”, “When should we define them?” and “Where should we start?”.

What are business requirements?

Your business has certain ways of doing business, from its high-level business planning functions all the way down to its low-level shipping procedures. In many cases, it has developed processes that work well for its business, and it has no intention of changing those processes. In other cases, it has areas that – if improved – may make the business more productive, efficient and/or effective.

In the context of ERP, business requirements represent both the non-negotiable existing processes as well as the planned changes that are intended to yield future improvements.

When should we define them?

Requirements should be defined for every ERP-related project that is identified (i.e., selection, implementation or post-implementation optimization). If done properly, these requirements should chart a roadmap to an improved, ERP-enabled business state. If you happen to have requirements from a prior project, review them and make sure they’re current.

Requirements analysis should always be among the first project phases to be completed. To do otherwise would be to put the cart before the horse. In terms of selection, a company probably shouldn’t solicit vendors until it understands what business problems ERP can help it solve. If the problems aren’t well defined, how can vendors propose solutions? For implementation, the path from the current business state to the future state needs to be mapped. Otherwise, the company won’t know the end-game, which is one of the major causes of runaway implementations. The same thing goes for post-implementation optimization.

Where do we start?

It would make sense that the very first item to check off the list is to understand the purpose of ERP. Generically, that purpose is to help a business realize its goal of becoming an integrated organization, one whose departments and units collectively drive the same business objectives.

What this means is that a requirements gathering initiative shouldn’t start with a departmental-level business process mapping exercise. This type of approach would simply reinforce an old way of doing business – one where various departments pursue their own goals with little or no consideration of upstream, downstream or cross-stream effects.

Rather, the process should start at the top, with an in-depth analysis of the company’s business models and strategic objectives. These will act as the guiding lights – or benchmarks – against which proposed requirements should be evaluated. By proceeding this way, businesses will be taking steps to ensure that proposed solutions drive a unified set of corporate goals.

For example, consider a case where a manufacturer/distributor has a primary objective of improving customer service and a secondary objective of minimizing costs. Its warehousing department has identified finished goods inventory as an area for potential cost savings. The company might consider reducing levels to minimize carrying costs. However, given its primary objective, it might only want to reduce inventory levels to an extent that won’t compromise its ability to make timely customer deliveries.

Let’s move the narrative along. The next step is to review the business’ organizational structure – again, with the goal of promoting an appropriate level of integration. Do business units, divisions and departments operate in a siloed manner? Are there redundant departments that could be centralized? Again, the business should be looking at ways of building a structure that’s an enabler of, and not a hindrance to, the achievement of goals.

Now, once business models, objectives and structures have been defined, the company would apply the same methodology at the departmental level. On a function-by-function basis, it would assess business processes against corporate objectives with a view to the following: Identifying non-negotiable, goal-driving processes; Identifying process gaps and issues that, if rectified, would better promote corporate goals; Identifying appropriate solutions to resolve those issues and fill those gaps.

Once it makes its way through this top-to-bottom requirements analysis, a company puts itself in a strong position to know what it needs an ERP system to do, whether from selection, implementation or optimization perspectives.

Jonathan Gross is vice-president of Pemeco, Inc., a consulting firm specializing in ERP selection and implementation. He can be reached at jonathang@pemeco.com. This article originally appeared on Pemeco’s website – www.pemeco.com.