Answering these questions and cutting loose from the net of ERP confusion requires a strong analysis within a well-built methodological framework. In this article, I lay out a three-stage framework that a company can use to assess its needs and to find an ERP package that has the functionality to meet those needs.
Stage 1: Identify the 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 selecting company becomes more likely to try to mould its business processes to those defined by the ERP software. Then, it runs into the problem of using business processes defined by an ERP vendor that had little or no knowledge of the selecting company’s unique business needs.
In our view, your ERP journey should start with introspection — an internal business and IT assessment. 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. The purpose of an introspective exercise is to define how the company can use ERP to evolve its operations and meet its business objectives.
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 a business transaction takes to wind its way through the company. In the following diagram, I illustrate a simple process map (a.k.a. workflow) relating to a fictional company’s – ACME Co. – Chinese sourcing practices.
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 two spreadsheets is time consuming, cumbersome and costly. Also, manual data transcription introduces significant human error risks that could delay purchasing and jeopardize timely delivery.Here is a brief summary of this workflow. A procurement employee conducts a daily review of purchase orders and creates two separate spreadsheets: one containing parts for sourcing and the other containing quality control specifications. Once drafted, the employee emails the first spreadsheet to the Chinese supplier and the second to ACME’s China procurement office.
If improving 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 should first define the functional components that make up this business processes. For example, in this case, ACME would want to ensure that the ERP system is capable of splitting of purchase orders into parts and quality control specifications, among other things. A failure to identify all of the underlying sourcing requirements could cause ACME to pick the wrong system, one that is incapable of fulfilling its particular needs.
In the next step, the company should prioritize the defined specifications according to how important it will be for the system to be capable of executing those tasks. The prioritization exercise is key because each system has its own strengths and weaknesses. The selecting company wants to make sure to pick the system whose strengths match its most critical needs.
Stage 2: Weight the 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’s assume that Chinese sourcing is a key business driver. ACME would therefore give strong weights to the functional requirements that are necessary to execute Chinese sourcing 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
1. Future Use
Once priorities have been assigned, the functional requirements should be sent out to the vendors for completion along with the other elements of a request-for-proposal (RFP). Once the vendors have completed and returned the RFP, the company must then score the vendor responses. The scoring process includes an analysis of how well the selected system meets the company’s functional requirements.
Stage 3: Evaluate 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 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 completedÂ the definition and prioritization stages of the analysis. Failing to identify or otherewise mis-prioritizing functional needs creates a risk of acquiring the wrong system. For example, let us assume that ACME failed to identify a key sourcing specification: namely, that the system be capable of splitting purchase orders into parts. However, it was only during implementation that ACME realized that it had omitted a key specification. Its project became delayed and suffered significant cost overruns as it tried toÂ modify or change the software’s source code to deliver the missing functionality.
As this example shows, a methodology is a necessary but insufficient tool for running an effective system selection project. A methodology must be supplemented by high quality analysis of functional specifications, among other things. Remember, your ERP project is a 10-year investment into operational improvements. If your business does not the internal skills that are needed to run a proper selection project, it should look outside its walls for those skills.
Substantially similar version published by Manufacturing AUTOMATION on August 30, 2010
Substantally similar version published by Software Advice and cited by SupplyChainBrain