As ERP consultants we frequently and regularly preach to our customers and prospective customers the value and importance of analyzing their processes before an ERP implementation (and sometimes during when revisiting those processes in greater detail). The result of a business process analysis (or BPA in our parlance) is usually some form of business process reengineering.
So we’re always interested in other consultants’ opinions about the process of both BPA and BPR. Recently, the CEO at Panorama Consulting suggested 7 Myths of Business Process Reengineering, which we thought worth reprising in today’s post. Here then, are Eric Kimberling “7 Myths” along with an abbreviated synopsis of his comments. (You can access the full post here.)
- Business process reengineering doesn’t need to happen on ERP projects. Perhaps the most misguided of all. Every ERP system will wreak some sort of havoc on your business processes. Most of these changes will be positive improvements, but will still require some effort in defining your operations in the new system environment.
- Simply implementing a new ERP system will drive process improvements. The most pervasive myth. Today’s ERP systems are extremely robust and flexible, meaning even the simplest business processes can be performed in a wide variety of ways. This leads to a need for pre-defined business processes so the software can be configured and/or customized accordingly.
- ERP project teams should focus on “to-be” rather than “as-is” processes. If you are the organization making the changes or the employees doing the work every day then the current processes absolutely DO matter. It is thus critical that you assess the current state of your processes to help you obtain the future state as part of your business process reengineering and optimization efforts.
- Business process improvements can be done without organizational change management. Too many executives think that they can simply redefine and implement business processes without organizational change management. This is a misguided view. The most effective business process reengineering efforts succeed largely because of the way organizational change is addressed – not because of how well the processes were defined on paper.
- You can’t reengineer business processes before knowing which software you are going to implement. It is typically more advantageous and efficient to both evaluate and improve your business processes prior to selecting and implementing a new system.
- All business processes need to be overhauled before selecting and implementing a new ERP system. Not true. Typically, the most successful organizations focus on improving their core areas of competitive advantage or differentiation as part of their ERP implementations, while letting other non-core business processes follow the lead of the software’s out-of-the-box functionality.
- Business process reengineering will cause my ERP implementation to take more time and money to implement. The Achilles heel of many failed ERP implementations is that they assume that “doing things right” will cost more time and money than if they cut some corners along the way. While it may look good on paper to strip out any extensive business process work, the reality is that your project will most likely take longer to implement and proceed to fail at go-live if business processes are not adequately addressed as part of your implementation. Remember that it is much less expensive to do things right the first time than it is to do clean up after an ERP failure.
We couldn’t agree more with Kimberling’s points, and urge all companies embarking on their own ERP initiative to take them to heart.