Which Comes First: New Processes or New System?

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?

1. Should they improve their processes before implementing the new system, so that the new system is not automating broken processes?
    
2. Or should they choose the new system first, so that they can redesign their business processes using the best business practices that are embodied in the 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.

1. Initial Process Assessment to Determine Key Requirements. Before evaluating software vendors and selecting a new system, the project team should do a high-level assessment of all business processes to be supported by the new system. Although it is not necessary to do “as-is” process mapping, we do recommend that the project team “frame” each process. Process framing defines the process boundaries, the major activities, the actors, key metrics, the case for action, and the vision for the future process. The process framing can then be used to draft key business requirements for the new system.
    
2. BPI before the New System Implementation. Data cleanup activities are a typical example. During process framing, it is likely that immediate process improvement opportunities will be uncovered. These may include quick hits: process improvements that can be done immediately, without waiting for a new system. These may also include process changes that will need to be done regardless of what new system is selected. Examples include data clean up, documentation, training, and developing policies and procedures to enforce discipline.
    
3. Designing New Processes Based on the New System. If the team did a good job defining key requirements for the business, they should have confidence that the new system is a good fit for the business. If the new system has been adopted by multiple customers similar to the organization, it should embody best business practices for that industry. After the new system has been selected, the project team—in collaboration with the system implementation consultants—should do a more detailed evaluation of the current processes along with the future vision (from step 1) in order to design the organization’s processes under the new system. Here is where the best business practices embodied in the new system should be applied. This stage is sometimes called prototyping, conference room piloting, or blueprinting.  During this phase, the project team is likely to uncover more BPI initiatives that should be completed before the new system implementation. Building new data files for loading to the new system is a common example.
    
4. BPI during the Implementation. Some redesigned business processes will depend on capabilities that are only available in the new system. In these cases, the process improvements are implemented as part of the new system go-live. These are generally the process changes that are essential to implementation success.
    
5. BPI after the Implementation. In other cases, some process improvements can wait until some period of time after the new system go-live. This may be because they are lower priority improvements. It is more often the case, however, that these changes require an effort that is larger or more disruptive than the organization can take on while also getting used to the new system. It is often better to postpone these larger, more strategic BPI initiatives until after the new system has become stable in production.

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.