You come across it all the time. You read it on the ERP, SaaS or Software vendor websites, you hear it from software sales reps, and you see it in proposals:
“Don’t worry about business process reengineering – our software will tell you how your processes should work.” You may also hear things like: “Just use our pre-configured 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 the expert witness experience supporting high-profile lawsuits wasn’t enough to convince us, our experience cleaning up messes from ERP system integrators, SaaS´s, VARs and do-it-yourselfers also point to the fact that business process reengineering should happen before – NOT AFTER – you begin your Digital Transformation (DT) implementation. Other than poor organizational change management, poor business process management is the single biggest and most common differentiator between DT success and 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 DT / 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 implementation:
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.
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 systems.
Mitigate the downside of the flexibility of modern systems. Most of today’s systems are very flexible. In fact, I have read that the average SAP implementation requires 10,000 configuration decisions in order to assemble a working, end-to-end process flow. If your business processes are not well defined and documented prior to implementation, these thousands of configuration decisions will be made in a vacuum by software techies. SaaS and cloud ERP systems are becoming more flexible as well, so even the SaaS bandwagoners will have trouble disputing this point (although I’m sure at least one will try in the comments section below).
Best practices [software embedded] are a farce, but lean Six Sigma isn’t. [These] 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 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.
Faster realization of business process improvements and business benefits. When we help clients identify process improvements, we often find that although a new system may help automate and further enable process changes, many improvements can be rolled out independent of the chosen 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 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.
Business process reengineering is one of the holy grails of Digital Transformation 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 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.
Based on:
Eric Kimberling, October 10, 2012