You come across it all the time. You read it on the ERP vendor websites, you hear it from ERP software sales reps, and you see it in proposals: “Don’t worry about business process reengineering – our ERP software will tell you how your processes should work.” You may also hear things like: “Just use our pre-configured ERP system with best practices baked into the software, and your business processes will improve by leaps and bounds.”
It sounds good in theory, and it’s what most executives want to hear in the boardroom, but how realistic is this notion? Unfortunately, it’s not very realistic at all.
There are a number of flaws with this approach. If our expert witness experience supporting high-profile lawsuits wasn’t enough to convince us, our experience cleaning up messes from ERP system integrators, VARs and do-it-yourselfers also point to the fact that business process reengineering should happen before – not after – you begin your ERP implementation. Other than poor organizational change management, poor business process management is the single biggest and most common differentiator between ERP success and ERP failure. In fact, results from one of our recent polls that effective business process management and well-designed business processes was one of the top reasons CIOs attribute to the level of success (or failure) of ERP implementations.
I already know what you’re thinking. You’re wondering how one can possibly reengineer business processes without having the software installed, or in some cases, not even knowing what software is being selected, right? It’s a great question, so here are the five reasons why business process reengineering should start before your ERP implementation:
1. Maintain your competitive advantage. Yes, your current enterprise systems are probably a mess . . . if they even exist. You probably have a ton of spreadsheets, manual workarounds and other inefficiencies that make you wonder how your organization has managed to survive and thrive for this long. But you probably also have business processes that give you a competitive edge, no matter how painful or inefficient they may be. Business process reengineering without the constraints of software configuration ensures that you maintain these competitive advantages as you select and implement your new ERP systems.
3. Best practices are a farce, but lean Six Sigma isn’t. Best practices are a lot like unicorns and Santa Clause – they sound mythical, magical, and represent what we all hope really exists, but then we realize one day that they don’t. Best practices sound good in theory, but the reality is that they are simply best practices for how any particular ERP vendor’s software works rather than for your operations. An exception to this rule is vanilla, back-office functions such as HR and accounts payable. Lean Six Sigma, on the other hand, is a set of tools that can be used to define your own set of best practices, efficiencies, and competitive advantages that you likely don’t want to be replicated by industry peers. The graphic below illustrates some of the lean Six Sigma activities that Panorama’s team has built into its business process reengineering methodology:
4. Faster realization of business process improvements and business benefits. When we help clients identify process improvements, we often find that although a new ERP system may help automate and further enable process changes, many improvements can be rolled out independent of the chosen ERP software. For example, if a company decides that it wants to incorporate a purchase order approval workflow to institute tighter controls on procurement costs, it may decide to do so via email approvals until a more robust ERP system is in place to further automate this change. In addition, from an organizational change management perspective, “spoon feeding” changes to employees sooner is more effective than waiting to implement a massive degree of change all at once during an ERP implementation.
5. Avoid the “paving the cowpaths” trap. Companies that fail to define business process improvements prior to their implementations are much more likely to simply automate their existing broken processes. The reason? Once an implementation starts, the meter is running on expensive technical consultants, so every minute spent making process decisions or agreeing to changes costs time and money. This set-up forces most project teams into the path of easiest resistance (i.e., simply configuring or customizing the software to fit existing processes). On the other hand, companies that take the time to define processes up front ultimately end up accelerating their implementation durations and minimizing extra costs, allowing the technical resources to focus on how the software can be best configured to meet those processes.
Business process reengineering is one of the holy grails of ERP implementations. Everyone wants it, but few know how to achieve it. By having a realistic understanding of how processes are best defined and incorporated into an ERP implementation, projects teams will be much more likely to succeed. In addition, your implementation will be faster, less expensive, and more widely embraced by employees with these tips and guidelines in place.