Business process re-engineering is not a new concept. Quite the contrary, with 30 years since Michael Hammer’s article “Obliterate, don’t automate”, this is arguable an old management paradigm. But it aged well, very well.
Give or take every decade there is a wave of new technologies that organizations try to wrap their heads around. Internet in the 80s, eCommerce and ERPs in the 90s, double-sided platforms in the 2000s, SaaS and Cloud in the 2010s, and now in the 2020s we talk about VR, AR and machine learning.
Learn to crawl, before learning to walk
The shiny thing in front of us distracts us from the reality: we’re probably still 10 years behind. However, as McKinsey suggested in their Horizon’s model of innovation, these different technologies, or horizon’s of innovation, do not exclude each other. Business process re-engineering is what helps organizations catch-up and be prepared to achieve current and future innovation.
Business Process Re-engineering is the exercise of (fundamentally) rethinking the way work happens in organizations in order to save cost, achieve growth or reduce risk. At Monogon, we’ve adopted and iterated this methodology to also assess People and Technology. Our approach follows 4 steps.
Phase 1: Discovery
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:
- Increase efficiency and scalability
- Revenue growth
- Reduce cost
- Improve customer experience
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:
- Process model
- Application landscape model
- Functional org chart with headcount
- 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:
- Process as-is mapping
- Business capability mapping
- Time-spent analysis per job function
- 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.
Phase 2: Analysis
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.
Phase 3: Design
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.
Phase 4: Implementation
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:
- Reflect the project’s objective
- Create a common understanding and shared responsibility
- Make staff feel like they’re part of something bigger
- 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:
Big bang approach
- No additional cost and overhead in refactoring and designing integrations with dependencies on legacy systems
- Cost savings (and organizational commitment) to no longer be maintaining legacy systems after a new release
- Reduced overhead by scaling down legacy systems, teams and processes
- Risks associated to cut-off and data migration are manageable with good project management and senior leadership commitment
Piece meal approach
- Testing can happen in a piece-by-piece fashion and see progress, rather than waiting until the end of the development
- Provides more flexibility in planning, and training of the business can happen according to the pieces released
- Data migration is more manageable, with a plan B ready at any time
- Safer and less ‘scary’ approach, as no large cut-off required and associated risks to the customer and business
- If money runs out, at least the system and the pieces that have been released can still be operated