Everyone agrees that business process improvement is a key success factor in enterprise system implementation. But which comes first? Should organizations redesign their business processes before selecting and implementing new systems? Or should they first select a new software vendor and then redesign their processes to match how the new system does things?
This question comes up repeatedly in vendor evaluation and software selection projects at our sister consulting firm, Strativa. Clients read about failed ERP or CRM projects. They hear the warnings of executives from such companies, telling them to spend more time up front understanding their business processes. They hear about companies that go live but don’t achieve the desired benefits. They vow to do better. They don’t just want to implement a new system. They want to implement best business practices.
These are good reactions. When it comes to enterprise systems, anything that heightens the fear of failure is a good thing. The more business leaders are focused on business processes, the better.
But, how should business leaders deal with their business processes when implementing a new system?
The answer is a little bit of both: the two should be done in parallel. In fact, doing all of one before the other—whether process first, or system first—will result in failure. This post explains why.
Understanding Processes to Pick the Right System
By now, most business leaders understand the risks of picking a new system without first understanding their business processes. For example, in an engineer-to-order business, a key need is to allow a customer to order a product that does not yet exist. If the selection committee does not understand the hand-offs between sales and engineering, they may miss this requirement and pick the wrong system. If so, they will have to implement a procedural work-around for this requirement or modify the system.
There is also the other extreme. The project team may spend enormous amounts of time and money up front to map current processes, then redesign and map those processes in light of “best business practices,” before going out to select the new system. Large consulting firms like this approach because it allows them to staff the project with many junior associates to do detailed “as-is” process mapping followed by equally detailed mapping of the “to-be” processes.
But if the project team maps the future processes in this much detail before selecting the new system, they will be unlikely to find a system that exactly matches their redesigned processes. This means that the future processes will need to be redesigned yet again in light of how the new system actually works—or, worse, the team will attempt to customize the software to fit their newly designed business processes.
Either approach adds time, expense, and risk to the project without adding value. For these reasons, and based upon our experience, we believe that process design and new system selection and implementation should be done in parallel, and in stages, as shown in Figure 2.
The New System as Starting Point for Process Improvement
In the context of a new system, business process improvement is not a one-time effort. As shown in Figure 2, there are at least five points where business processes should be assessed and improved.
There is a tight relationship between new systems and new processes. Years of experience teach us that addressing them in parallel saves time, lowers risk, and maximizes the odds that the organization will achieve implementation success along with process excellence.
E-Commerce Complexity Causes Customer Experience Challenges
Global Crises Fueling New Investments in Supply Chain Management
Digital Workplace—Rising Star of New Technology Trends Study
NFTs: More Than Just Digital Art
Avoid the Watermelon Effect—Focus on Customer Experience
IT Spending as a Percentage of Revenue by Industry
IT Spending in the Insurance Industry
IT Spending in the Retail Industry