In an ideal world, the ERP software selection process would be straightforward; a company would only have to consider one ERP solution and that solution would satisfy all of its needs. However, this isn’t an ideal world. For many companies, a high-level review of ERP software might yield 10 to 20 potentially suitable alternatives. Few of those alternatives, however, would likely prove to be a good fit. For example, some might be incapable of delivering critical functionality. Others might be difficult to integrate with existing infrastructure and systems. Still others might be accompanied by unacceptably onerous maintenance and support obligations.
Slicing-and-dicing through that long list to the right-fit solution is a difficult project – and one that calls for a well-conceived analytical methodology. Using a good methodology, a company can cut through the confusion and the red herrings. It can give a company an opportunity to perform an “apples-to-apples” comparison of the various ERP alternatives, where the “apples” represent the company’s entire universe of needs.
In general, a company’s universe of ERP system needs will be made up of a few categories, namely: functional specifications, costs, implementation requirements, technology, and maintenance and support requirements. In this post, I focus on the first category: functional specifications.
Before setting out our firm’s three-stage methodology to analyze functional specifications, let me first define and give examples of what I mean by “functional specification.” In a generic and non-technical way, a “functional specification” refers to an electronic task that supports the execution of business processes. As a first example, a logistics-related functional specification might be a requirement that the ERP system electronically communicate bills of lading to carriers. As a second example, a finance-related functional specification might be a requirement that the ERP system track and value WIP (work-in-progress) at different stages of a manufacturing cycle.
Getting back to the analytical methodology, a company should at a minimum perform the following three exercises:
- Identify Functional Specifications
- Weight Functional Specifications
- Evaluate ERP Software Packages
Stage 1: Identify Functional Specifications
At the outset, it is important to note that a company should never solely rely on a template spreadsheet to identify its functional specifications. Though these types of spreadsheets are easy to acquire, they are of limited use in the absence of underlying business analysis. Rather, the company should define its specifications from an analysis of its operating and IT environments.
An operations and IT assessment should invariably include business process mapping. These maps show – in step-by-step diagrams – how a business transaction winds its way through the company. In the following sample business process map diagram (a.k.a workflow diagram), I have set out the steps that a fictional company takes to submit its purchase orders to a Chinese parts supplier. As you can see below, every day, a procurement employee has to comb through purchase orders to identify the parts that it intends to source from its Chinese supplier. Then, that employee creates a spreadsheet with the order details and attaches certain relevant documents. Finally, the employee sends a daily purchase email to the Chinese supplier.
However, automation will partly depend on the company’s ability to select an ERP system that can perform the underlying functional tasks. As a result, it is crucially important for the selecting company to be able to first identify all of the key functional specifications. For example, in the case of our fictional company, one of the underlying specifications would likely include a requirement that the ERP system be capable of electronically splitting purchase orders into single parts. This specification would need to be identified because only certain parts in a given purchase order are to be sourced from the Chinese supplier.
Once this and all other relevant functional specifications have been identified, the company must next weight the specifications relative to their importance.
Stage 2: Weighting Functional Specifications
Determining which processes should be “ERP-ized” and which should remain outside of the ERP system is a question best answered in reference to business goals. For example, if sourcing from China represents a big part of the company’s plans, it might decide to automate the underlying processes. However, if the crystal ball does not predict a future for Chinese sourcing activities, the company might decide against “ERP-ization.” Consequently, weights should be assigned to the specifications relative to the business value of the associated business processes.
With respect to the weighting exercise, we generally recommend using a points-scale that does not exceed five. In our experience, a point-scale that exceeds five makes it difficult to distinguish among the priority levels. For our systems selection clients, we typically use the following four-point weight scale:
- Required and cannot be worked around
- Required, but can be worked around if missing
- Nice-to-have
- Future Use
In terms of allocating weights, we generally require input from all affected stakeholder groups – including end-user employees and top-floor executives. The end-users should be involved because they have the in-the-trenches experience to know what would make their jobs easier. The top-floor executives should be involved because they are in a position to translate strategic goals into operational needs.
Once priorities are assigned, the company is in a position to evaluate the ERP alternatives from a functional perspective.
Stage 3: Evaluate the ERP Software
Through the evaluation process, the selecting company intends to pick a system whose strengths align with its high-priority needs. It also intends to avoid picking a system that would fail to adequately meet its high priority needs.
Using our fictitious company example, let us imagine that it placed a high value on automating purchase order workflows. Let us also imagine that it failed to identify a specification requiring the system to split purchase orders into parts. After evaluating the various alternatives, the company selected what it thought was the good-fit ERP package. However, by the time the company had learned that it had omitted a key specification from its request for proposal, it was too late. After spending $1million-plus on the system, the company still needs an employee to manually extract information and complete spreadsheets. As a result, the company will fail to achieve the full extent of the projected efficiencies and labor cost savings.
As the above example illustrates, the identification, weighting and evaluations exercises go a long way in helping a company select an ERP system that meets its goals. In my next post, I will dig into another key ERP system selection evaluation category: price. Among other things, I will offer some tips on negotiating license fees, implementation fees, and maintenance and support fees.
Your R.E.Q. (Relevant Experiences and Questions)
In the meantime, I would like to hear about your experiences relating to functional specifications and the ERP selection process:
- Did your company undertake a process-mapping exercise as part of its selection project? If so, did you find it valuable? Why or why not?
- What experiences or issues have you had with identifying functional specifications?
- What challenges do you face when evaluating alternative ERP solutions?
-
KRW