Business Process Re-engineering – Getting the Cart Before the Horse

There are two, conflicting schools of thought about the interrelationship between business process reengineering and software selection. One school of thought says that process reengineering should be done first prior to executing a solution selection. The other school would have business process reengineering done in parallel to the software selection or during the implementation of the new software solution.

The Conundrum

The “prior to a selection” school uses the business process reengineering activities to build an understanding of the organization’s requirements. It then looks to either the existing legacy software solution or to new manual processes (e.g. written process documents, spreadsheets, etc.) to institutionalize the new policies and procedures.  It then considers the selection of a new technology solution.

The “during or after selection” school implicitly acknowledges that the baseline process and procedures built into the new software you will select actually impact what the businesses new processes need to be. It is our view that the requirements gathering phase of a well-designed software selection methodology accomplishes the identification of current processes, current process flows, issues, and future state requirements. The RFP for a new selection is the documentation of the future “to be” set of requirements and the processes implied therein. The implementation of the new solution institutionalizes the new processes and affords the opportunity to train the staff on how things will work going forward.  We see this method as the merging of the two major activities, process re-engineering and software selection, into one cohesive whole.  It insures the appropriate tasks are done in the right sequence and at the right time.

With the “prior to a selection” approach, the organization is faced with one of two choices. One, execute business process reengineering a second time taking into consideration the new software or, two, modify the new software to meet the recently instituted new processes. We do not believe that either of these choices are attractive. Both significantly add to the project cost and increase the overall duration of the project.

The Correct Approach

It is our view that the correct approach to business process re-engineering, when the organization has also acknowledged that new enterprise systems are needed, is to blend the two approaches – merge the steps of both processes into an orchestrated process that enables the new system to be the place for “institutionalization” of the changes while allowing the new processes to take advantage of the best practices already incorporated into the new system.

This merging starts with requirements gathering intended to understand and document the state of the existing infrastructure, applications, and the flow of information, communications and activities within and between business functions to identify risks, improvement opportunities, costs, as well as the timing and level of effort required to mitigate risk and/or recognize benefits from opportunities.

The next stage of the merging of software selection and process re-engineering is to translate the requirements, both current and future state, into the documents used to search out and select a new solution.  These documents include requests for proposal (RFP), structured demonstration scripts, and preliminary implementation plans from the solution providers.  This step is almost exclusively one associated with software selection.

With a new solution provider selected, the final stage of the merging of process re-engineering and software selection begins.  This is the development of an implementation strategy which is more than just taking the vendor’s implementation plan and driving forward with it. Many more things need to be considered to include;

• organizational readiness for change
• solution type, cloud vs. on premise, and the implementation differences
• change and program management needs
• data conversion (is more than just conversion, its data cleansing and summarization of historical data to be brought forward)
• potential business critical periods of time
• appropriate phasing of key go-live activities
• internal staff availability
• as well as overall project scope and budget

These activities are characteristic of both process re-engineering projects and implementations of a new software solution.

The Problematic Approach

The “prior to a selection” method of doing process re-engineering first forces the organization to implement the new processes in the old solution with new added manual controls.  The net effect of re-engineering first is to execute all the tasks in a serial, single threaded approach.  This method extends the full implementation cycle by a factor of 2 or 3 times the interleaved approach.  For example, a process re-engineering effort for a large part of an enterprise can easily take 12-18 months.  If this is then followed by a 6-month software selection process followed by an 18-24 month software implementation and second organizational re-engineering process, the total duration for all tasks can be in the 36-48 months range.  The “merged” multi-threaded approach we recommend incorporates a 6-9 month selection process with a 12-18 month software implementation combined with process re-engineering efforts totaling 18-27 months.  This is an 18-21 month improvement or the re-engineer first method.

Not only does this shorten the overall time involved, it also reduces the overall project costs.  Doing a re-engineering first process sequentially followed by the selection and 2^nd re-engineering effort might be good for consultant billable time but it is not good for the enterprise’s bottom line.

Conclusion

The bottom-line from our perspective is that you do not do the process reengineering activities first and then seek new software.  This involves doing the re-engineering activities twice or crippling the new software with customizations to support the re-engineered process.

We do recommend that you do the selection and the re-engineering activities together. You gather requirements, identify opportunities but not do a major implementation of re-engineered processes.  You take the requirements and process change opportunities and find the new software. You then implement the software and re-engineer the processes together.

The approach we do not recommend may be good for consulting billing hours but it is not good for your enterprise or the total project cost.  The approach we do recommend dramatically shortens the overall project duration and costs.