ERP selection: Three steps to analysing functional needs

Companies evaluating ERP solutions may find themselves ensnared in a net of vendor confusion. Selecting the right ERP software from among 15 or 20 seemingly good candidates is a difficult project. So, how does a company go about comparing, contrasting and ranking the various ERP software alternatives? How can it determine which software package best fulfills its various needs?

Answering these questions – and cutting loose from the net of ERP confusion – requires a strong analysis within a well-built methodological framework. Below is a three-stage framework that a company can use to assess its needs and find an ERP package that has the functionality to meet those needs.

Stage 1: Identifying functional specifications
Your system selection journey should not start with an assessment of various ERP packages. Starting the selection project with an external analysis pushes a company into an awkward restructuring project that could lead to failure. Using this ill-advised approach, a company becomes more likely to try to mould its own business processes to those defined by the ERP software. The problem is that those ERP-defined business processes were established by an ERP vendor that had little or no knowledge of the selecting company’s unique business needs. As a result, the selecting company will likely find itself trying to squeeze its business processes into the wrong-sized box.

Rather, your ERP journey should start with introspection. Starting with an internal analysis puts your company on a path to finding a system that fits its needs – and helps it avoid changing itself just to fit a specific system.

Business process mapping is key to this internal analysis. The fruits of this exercise include a set of diagrams that show the precise steps that the various business transactions take to wind their way through the company.

Consider, for example, a relatively simple business process (a.k.a. workflow) relating to the Chinese sourcing practices of fictional company, ACME Co. An ACME procurement employee conducts a daily review of purchase orders and extracts only those parts that are to be sourced from China. The employee then enters the relevant parts information into a spreadsheet and e-mails that spreadsheet to the Chinese supplier.

Though this workflow contains relatively few steps, it highlights some significant operational inefficiencies. For example, the job of manually combing through purchase orders and populating a spreadsheet is time consuming, cumbersome and costly. Also, manual data transcription introduces significant human error risks that could delay purchasing and jeopardize timely delivery.

If sourcing efficiency is a key business objective, ACME might decide that it wants to acquire an ERP system to perform part or all of this workflow. Ultimate automation, however, will depend on ACME’s ability to select a system with the right functionality.

To evaluate whether an ERP system has the requisite capabilities, the selecting company must first define the functional components that make up this business process. In ACME’s case, it would want to ensure that the ERP system is capable of segregating purchase order parts by part code, among other things. A failure to identify this and other functional specifications could cause ACME to pick the wrong system – one that would be incapable of fulfilling its sourcing needs.

Once a selecting company has defined all of the functional specifications, it then has to prioritize those specifications. The prioritization exercise is key because each system has its own strengths and weaknesses. The selecting company wants to make sure that it picks the system whose strengths match its most critical needs.

Stage 2: Weighting functional specifications
Functional specification weights should be assigned relative to the importance – or business value – of the underlying business process. In ACME’s case, let us assume that Chinese sourcing is a key business driver. ACME would, therefore, give heavy weights to the functional requirements that are necessary to execute the related business routines.

For our systems selection clients, we typically use the following four-point scale to weight functional specifications:
4.    Required and cannot be worked around;
3.    Required, but can be worked around if missing;
2.    Nice-to-have; and
1.    Future use.

Once priorities have been assigned, the functional requirements list should be sent out to the vendors for completion, along with the other elements of a request for proposal (RFP). Upon receipt of the completed RFP, the company must then score the vendors’ responses. The scoring process must include an analysis of how well the candidate systems meet the company’s functional requirements.

Stage 3: Evaluating the ERP software
One purpose of a selection methodology is to help a company put itself in a position to pick a system whose strengths align with its high-priority needs. Another purpose is to help a company avoid picking a system that would fail to deliver on any of its high-priority needs. This latter category of unfulfilled, high-priority needs is what we call the "Danger Zone."

Avoiding the Danger Zone largely depends on how well the company completes the definition and prioritization stages of the analysis. Failing to identify or prioritize functional specifications creates a risk of acquiring an inadequate system. For example, let us assume that ACME failed to identify purchase order parts segregation as a key sourcing specification. Let us also assume that ACME only first discovered this omission during implementation. As a result of this late discovery, ACME had to try to rectify this mistake during implementation by customizing – or programming – the software to deliver the missing functionality. In the end, the customization process delayed the implementation project and caused cost overruns.

As this example shows, a methodology is a necessary but insufficient tool for running an effective system selection project. The methodology must be supplemented by a high-quality analysis of functional specifications. Remember, your ERP project is a 10-year investment into operational improvements. If your business does not have the internal skills that are necessary to run a proper selection project, it should look outside its walls for those skills.

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.