Getting started with Business Process Re-engineering (BPR)

To move forward, first we take a step backwards. Every transformation should start with an intimate understanding of the current state of your organization, processes and technical setup. This allows for more accurate problem definition, brings onboard stakeholders at every level of the organization and helps measure the effort required to achieve the objectives and future state that is most suitable to your organization.

Step 1: Define objectives and metrics for success

As with any business initiative, the objectives of a transformation project should align to the company’s long-term vision and corporate strategy. Not only should the objectives be clearly articulated, they should also be measurable. The objectives of some of the projects we’ve worked on:

1. Increase efficiency and scalability
2. Revenue growth
3. Reduce cost
4. Improve customer experience
5. Pre/post-M&A
6. Re-organization
7. Innovation

Step 2: Understand the lay of the land

As an external contractor, we do not carry political stigma, we’re not tied down in the day-to-day and we have a helicopter view to break down siloes. However, there is a bit of a learning curve. We need to understand the lay of the land: both politically, organizationally, technically and from a process perspective. In order to define, plan and prioritize every subsequent step of the project, the following high-level information on people, process and technology needs to be collected:

1. Process model
2. Application landscape model
3. Functional org chart with headcount
4. Stakeholder map

Step 3: Seek champions and build buy-in

This is where change management begins. A broader group of key stakeholders should be consulted, a project governance structure defined and the required skill sets identified. This is also when a project team is brought together and their roles and responsibilities are defined. To speed up the project further down the line, we will identify champions who will be sparring partners and advocates for change throughout the project.

Step 4: Define and prioritize scope

When the objectives, concerns and considerations of key stakeholders have been understood, the project scope can be defined and prioritized. Defining scope is tricky. Too little scope and stakeholders feel left out or the problem is not solved. Too much scope and the project doesn’t take off. We must strike a balance here, be strict and rely on strong internal leadership to manage expectations.

Step 5: Collect information

Depending on the nature and objective of the project, there are different methods to collecting information, all of which should be carefully calibrated with key stakeholders. The most common methods are interviews, surveys, desktop research and observation. Typically the output at this stage of the project is:

1. Process as-is mapping
2. Business capability mapping
3. Time-spent analysis per job function
4. Overview of staffing model, roles responsibilities and incentives per job function

Step 6: Wrap-up as-is mapping

All the information collected in the previous step needs to be processed, organized and documented in a comprehensive way. It then needs to be validated by the stakeholders involved to confirm that this is indeed an accurate reflection of the existing processes. At this point, stakeholders at every level of the organization feel engaged, excited and are looking forward to the next steps.

Step 1: Define hypotheses

Although at this point clear trends will have started to emerge, sometimes further analysis might be required to find or confirm the root cause of what’s holding your organization back from achieving your objectives. In order to go about this in a structured way, we define testable hypotheses.

Step 2: Collect, prepare and analyze data

The next step is to understand what kind of data we require and what the scope of this data should be. Once the data is collected, it may have to be cleaned up and formatted before it can be analyzed. Once the data is in an analyzable format, we need to understand what the data means and whether it makes sense in light of our other findings. But what does good look like? The best way to determine this is to find a benchmark, which can either be historical trends or industry data.

Step 3: Write out problem statements

After validating our hypotheses, we can begin writing up the problem statements. These should be formulated clearly, concisely and describe the concern, the impact on the customer and quantify the magnitude of the problem. Now that we understand what problems we are actually trying to solve, we can move on to the design phase.

Step 1: Define goals

Having clearly identified the problems that need to be solved, the next step is to understand how these problems are holding your organization back from achieving your objectives. The more specific and measurable these goals are, the better.

Step 2: TO-BE design

Each goal defined in step 1 will need to be understood from a people, process and technology perspective. It is at this stage, that a TO-BE process design is done using the principles of Business Process Re-engineering. This step also includes a corresponding to-be technology architecture and organization design.

Step 3: Get buy-in, validate and iterate

Probably the most critical and difficult step in the entire re-engineering cycle. A proposed to-be process, system or organization is no good if your key stakeholders are not understanding or buying into it. At this stage, different avenues should be explored to obtain organizational buy-in, such as mock-ups, workshops, proof of concepts and experiments. Based on feedback from the business, we iterate the design to come to a final future state.

Step 4: Gap analysis, priorities and roadmap

With a future state finalized, we need to understand and prioritize how to go from our current state to the desired future state. A good exercise for this is to understand the gaps between current and future state and prioritize based on effort to execute and impact on the business (revenue, cost, risk, experience).

Note: work streams with little to no interdependencies may proceed through the various phases of a re-engineering cycle faster than others.

With a clear set of objectives and a sign-off on the future state of technology, process and organization, the next step is execution. This is where transformation really happens and includes facets of technical development, but also the human side of change management which all need to be carefully coordinated and project managed.

Step 1: Project design

At this point, the Business Process Re-engineering project turns into a full-fletched transformation project. This requires a new project charter, governance model, a detailed roadmap and an action plan. It should be clear to every stakeholder what their role and responsibility is and decision making should be structured and transparent.

We will work with your leadership team to divide the roadmap and action plan up in to manageable work streams. Each work stream has a leader and a team with their own charter of objectives, deliverables, milestones and a clear structure for reporting and collaborating with other work streams. It should be clear to everyone who they need to work with.

If the project did not already have a name, now is a good moment to think of a name that will:

1. Reflect the project’s objective
2. Create a common understanding and shared responsibility
3. Make staff feel like they’re part of something bigger
4. Keep things light and fun

Step 2: Kick-off and ongoing project management

Some stakeholders brought into the project at this stage may not have been involved before. Especially staff that was added as a team member in a work stream will have a steep learning curve. All stakeholders need to be brought up to speed, either at a company-wide kick-off, or at separately organized and hosted kick-off sessions.

A transformation leader and project manager will at this point oversee the interaction between all work streams, executive committee and the organization. It is their role to ensure deliverables against time and budget.

Step 3: Change management and training

Communication is the most important element of change management. If you think you’re communicating enough, you’re probably not! Staff needs to hear about the ongoing transformation, be constantly reminded of its objectives and hear about its successes and failures. Communication should be well coordinated and come from the leadership, the transformation team and the work stream leaders. With enough leeway until launch, your staff should now be trained on new processes, systems and team structures.

Step 4: Piloting

No battle plan survives first contact with the enemy. The same is true for transformation plans. It is recommended to pilot your new processes, systems and/or organizational structures in a pilot market. Choose this market carefully! It should be representative of the rest of your business, but if something goes wrong, it shouldn’t hurt your business too much. Typically one of the champions we have been working with from the start of the project is the leader of a market that will be keen to take a trial by fire. The successes and failures of the pilot will inform your roadmap, training plan and iterate your final designs.

Step 5: Data migration

If your transformation includes the implementation of new technical solutions, this often will involve the migration of data. This is almost always a step that businesses will underestimate. This requires an extensive amount of preparation and a diligent eye to get right. We will work with you to plan this accordingly.

Step 6: Launch

With all project milestones achieved, it is time for launch. At the beginning of the implementation phase, we will have worked with you to define what launch will look like. This will be somewhere along a spectrum between these two options, both with their advantages:

1. Big bang approach

   1. No additional cost and overhead in refactoring and designing integrations with dependencies on legacy systems
   2. Cost savings (and organizational commitment) to no longer be maintaining legacy systems after a new release
   3. Reduced overhead by scaling down legacy systems, teams and processes
   4. Risks associated to cut-off and data migration are manageable with good project management and senior leadership commitment

2. Piece meal approach

   1. Testing can happen in a piece-by-piece fashion and see progress, rather than waiting until the end of the development
   2. Provides more flexibility in planning, and training of the business can happen according to the pieces released
   3. Data migration is more manageable, with a plan B ready at any time
   4. Safer and less ‘scary’ approach, as no large cut-off required and associated risks to the customer and business
   5. If money runs out, at least the system and the pieces that have been released can still be operated

   {.}