Page 291 -

Chapter 9 • Organizational Change and Business Process Reengineering 249

and fully understood by the organization. In the case of an ERP implementation, the functions
included in the scope must also be identified. In addition to the goals, during the preparation phase
the implementation teams should address goals that need to be created along with an elaborate and
extensive communication plan. The teams will be made up of functional users and managers, initially
along with facilitators, to walk the teams through the BPR phases. The ERP system is sometimes not
purchased until after the “to be” processes are defined and communicated. In that case the BPR
process can then be used to define functionality needs and requirements within the system.
Here are some of the drivers behind the need for BPR:
•Implementing a current purchased ERP system
•Automating current manual or error-prone processes
•Improving service to customers
•Streamlining current processes to decrease time to market
•Participating in or conducting e-marketplaces
•Reducing costs
•Addressing accountability
•Conducting e-Procurement
“As Is” Working with the vision and goals, the functional teams must define the existing
processes. The processes will need both a written description and graphical depiction of each and
every process. Each process will likely have predecessors and successors linking processes together
for future analysis in the “to be” phase. Expect a lot of discussion during this phase, especially
around processes that cross functional boundaries. This usually results from one functional area not
knowing what occurs in another functional area. Ensuring that a process is well understood by the
team during this phase will be important for the “to be” phase. There needs to be clarity around
decision points for who is responsible and why. Last, the teams will need to develop a sense of
timing for each process. This will assist in the measurement process later in the methodology. In
working through the “as is” phase it is often tedious and stressful. This can often be countered with
team-building exercises and events. Part of the goal of this phase will be to develop good interaction
between and among the teams and to prepare them for the much more difficult “to be” phase.
“To Be” This is the phase where facilitators earn their stripes. This phase must address
timing of processes and the changes needed to meet the original set of goals. This phase requires
much thought and analysis. The questioning of current processes is a must. A team member will
often say things similar to, “we’ve always done it like that.” The understanding of why a process
does what it does needs to be uncovered, irrespective of who does it. Some team members,
although not all, will be threatened by the idea of changing a process. It is critical to work
through this phase and all the processes objectively and thoroughly. It will assist in developing
trust and minimizing some of the anxiety created by the “to be” phase. As stated earlier, this
phase dismantles processes and puts them back together with a new sense of purpose. Some
processes will even be eliminated, and all new processes must have estimates of timing and who
is responsible. This sets the stage for the measurement phase.
If the ERP system is already purchased, then this phase must address the existing ERP system
functionality and how the changed processes will work with the system. If the system is not
purchased, then the defined processes should be used to compare systems on the market for an
organizational match.
Testing and Measurement Even though the “to be” processes are clearly documented and the
timing for each process estimated, the testing and validation of each process is necessary to ensure
that a step was not missed or that a process not achievable. If the system is already purchased, then