Two perspectives on ERP business processes
This article is about business processes performed in ERP systems and is written from two different perspectives. The first perspective is a company that has outgrown its existing ERP and wants to replace it. The second perspective looks at avoiding the expense and disruption of replacing ERP software by improving the business processes.
Part 1: Business processes from an ERP selection perspective
By Chris Doig, CEO Wayferry
Companies outgrowing their ERP software find it increasingly painful to use, which drives them to replace the software. But 90% of ERP projects fail to meet expectations, and about 25% leave nothing but a smoking hole in the budget. We need a different approach when replacing outdated ERP systems, and this starts with understanding the difference between business requirements and software requirements.
Business requirements
From an informational perspective, a business is a collection of related processes that work together to deliver outputs, and most of these processes are executed in the ERP software. Business requirements describe process deliverables, i.e., WHAT the processes performed in the ERP software should deliver. Usually, this takes the form of an output from a process, e.g., the output deliverable of a purchasing process is a properly approved purchase order placed on an approved supplier.
Software requirements
Software requirements describe HOW the software will be configured to deliver these outputs. Using the purchase order example above, HOW the approvals process is configured is decided during implementation and has nothing to do with selecting the software. In other words, when replacing ERP software, most of the business process improvement will occur during the implementation.
Business process owners are interested in WHAT outputs the software delivers because they use those outputs to do their jobs. On the other hand, IT is focused on HOW those processes are configured, which is part of the implementation. The focus on WHAT the software must deliver to satisfy business requirements is why selecting ERP software is much more of a business decision than an IT decision.
When selecting an ERP system, you can treat business processes as “black boxes,” where you have no interest in HOW the process works inside the box. All you care about are the process outputs and the value created by the new ERP delivering those outputs. This principle is extensively used to tame complexity when writing software code (it’s called “refactoring the code”) and should be utilized when selecting ERP for the same reason.
To sum up: To successfully select a new ERP system, the business requirements should specify WHAT the new system must deliver and the value (priority) of those deliverables. HOW that functionality is delivered is not part of the selection. Instead, it is handled in the business process optimization that is part of implementing that new software.
Part 2: Business processes from an ERP implementation perspective
By Peer Nielsen, Partner at Business Improvement Group
To pick up on the lingo in part 1 above, here we focus on the WHAT the business processes should deliver. Before you consider replacing your ERP system, understanding the WHAT is critical. Because the last thing you want is to define the WHAT so that the new ERP system ‘automates current bad habits.’
You need to establish the effectiveness and efficiency of your current processes, asking the question: “Do our existing processes deliver business value efficiently that supports the current business model?” Therefore, a detailed mapping of current processes is required to evaluate the business value the processes deliver. The evaluation needs to be quantitative as well as qualitative.
Over time, business processes take on a life of their own, acquiring extra non-value-adding steps and functionality that bleeds out to Excel sheets, manual steps, and the like. Our experience is that business processes typically contain 5-30% inefficiency, and there are always some that are misdirected and even superfluous. The matrix below illustrates this point:
We always encounter this inefficiency, and it needs to be rectified before attempting to specify a new ERP system. The objective is to move all the processes to the upper right-hand box of the matrix above. While doing so, we establish WHAT the processes should deliver. Business processes are purged of time waste, sped up, and re-designed to provide maximum value to the business.
Conclusion
Viewed from these two different perspectives, you can conclude:
If you are likely to keep the current ERP system, it is wise to start with business improvement. After all, why undertake the expense, disruption, and risk of replacing an ERP system if ultimately it is not necessary?
On the other hand, you may be sure the ERP needs replacing, e.g., it is over ten years old, and the company has outgrown the functionality. You need to start by defining WHAT you want in terms of the outputs the business processes executed in the new ERP should deliver. In this case, there is no need to worry about HOW processes will be performed because they may be performed differently in the new ERP.
In both cases, you need to start the project by creating an inventory of your business processes.