The principles of Business Process Re-engineering (BPR)

Harvard professor Michael Hammer’s paper “Obliterate. Don’t automate” is to us what the Bible is to Christians. Here’s our take on the core principles he outlined.

June 30, 2022
General Image

When re-engineering a process, there are a number of principles we have in the back of our mind. These are the rules of process re-engineering.

Let’s take a look at these rules, how to apply them and some examples of how Monogon has applied them in our client’s transformation projects.

Organize around outcomes, not tasks

One person should own a process end-to-end, instead of merely executing small steps within a process.

When the steps of a process are broken out and owned by multiple stakeholders, there will also be multiple hand-overs that result in loss of information, back-and-forths, and miscommunications. A customer ends up frustrated by delays, confused who to speak with and annoyed about explaining the same thing several times.

Case study example:

One of our clients had a customer journey that was handed down between 6 different functions. Their customers were sent back-and-forth and were not sure who to talk to about what.

Monogon designed a comprehensive customer journey and tailored the organization to fit this journey. One single person was now the interface for the customer throughout their entire journey: no more confusion, miscommunication or frustration

Have those who use the output of the process perform the process

Processes such as procurement and reporting are often delegated to specialized departments in an organization. This is how, as companies grow, departments become internal customers. They exchange wooden dollars that again will need to be tracked by another department.

For each additional layer of specialization that is added, there is more management overhead, capacity planning and interfaces. Slowly the initial intent of scaling the business, has created layers of middlemen that create bureaucracy and slow you down.

Now that technical solutions have become more sophisticated, organizations should build the capabilities and logic owned by these departments into a system so that the end-user can execute this process themselves.

This same logic also, and perhaps especially, applies to your relationship with your customers. Do not become the middlemen that slows your customers down to handle matters themselves.

Case study example:

One of our clients in China had a Business Intelligence team of 23FTE, mostly dedicated to cleaning data, handling ad hoc data requests, generating reports and maintaining a siloed data infrastructure.

Monogon worked with the IT organization to centralize data and create a single source of truth. We designed role-specific dashboards focussed on only the most important KPIs and performance metrics. All dashboards rolled up to senior management and ad hoc reporting was mostly eliminated. Also, we designed governance at the point of data entry to make sure data was clean and reliable.

Integrate information processing work into the real work that produces the information

If frontline staff is not trusted to process and act on the information they themselves generate, this work is often left to specialized teams (such as accounting, quality assurance and admin clerks). Nowadays, however, trust and governance can be built into the system, rather than outsourced to a different department.

This will allow employees who generate information, for example through interaction with customers, to immediately act on it immediately. It speeds up process, removes overhead and leaves no room for confusion. It is also more objective, as governance is managed by the system.

Case study example:

In a call center transformation project that Monogon led in China, we found a team of 28FTE managing Quality Assurance. Their task was to observe agent behavior in the system, monitor the quality of phone calls and selectively administer quality control calls with customers.

Monogon re-engineered processes to eliminate this function completely by baking their activities into the system.

  • We enhanced the agent’s interface to improve the data entry and ensure proper usage
  • We recorded each phone call and used a Tencent AI-tool to transcribe and analyze the sentiment of each conversation, sharing the results with the agent’s manager
  • We designed a mechanism to collect customer feedback in WeChat after each interaction with a sales or support agent, with the results displayed in manager dashboards

Treat geographically dispersed resources as though they were centralized

In the past, decentralization would mean better service to the customer, but at the expense of redundancy and scalability. Nowadays, the pros and cons of centralization and decentralization are no longer a trade-off.

Through the centralization of data and the standardization of process, decentralized units can operate and scale the same way as a centralized organization.

Case study example:

One of our clients provided critical, on-the-ground support for their customers using freelancers that had all developed their own processes and tools. As a result, a major part of our client’s customer journey was outsourced to freelancers with data and processes outside of their control.

We designed a new infrastructure and standardized sets of processes and templates for these freelancers to work with. This allowed them to continue to operate independently with the flexibility they needed, while allowing for central oversight and governance. As internal siloes were broken down, the customer experience improved significantly.

Link parallel activities in the workflow instead of just integrating their results

When similar processes running in parallel are owned by different teams and only come together at the end, the following occurs:

  • Similar activities are taking place in parallel and there is no mechanism to maximize utility across the siloes
  • Since parallel work is performed in siloes, reconciling the output of these processes adds extra overhead towards the end
  • Some extent of double work happens as efficiencies do not carry over to other siloes

The objective here should be to attempt and consolidate or at least link parallel work in such a way that it allows for maximizing utility and efficiency, and reduce the amount of rework when reconciling the output.

Case study example:

Particularly the issue of utility maximization is something we see often in how sales and marketing organizations are structured. These are all parallel processes that feed into some form of operations/service organization after conversion.

In the transformation of a telemarketing center in China, we identified discrepancies in utility between regional teams. For example, where agent resources were utilized 90% of the time in Shanghai, the Chongqing team was only be utilized at 75%.

The organization was structured this way based on some legacy believes: (1) “sales agents do not know the metro network in other cities” and (2) “actually, it has always been this way”.

Monogon designed an operating model that dispatched leads to a team of centralized agents focused on the Mandarin speaking regions of China mainland. At the same time, the agent CRM interface was improved to have easy access to data specific to a certain region e.g., a metro map.

This change significantly improved the utility of call centers agents across the board. Unless there is a very strong cultural imperative or a need for face-to-face meetings, do no design a sales team by regions.

Put the decision point where the work is performed, and build control into the process

The more layers of hierarchy an organization has, the more managerial overhead there is and the further away decision-making happens from the client. As a result organizations become more bureaucratic, work slows down and the customer does not have a great experience.

Technology allows us a way out of this. Frontline staff should be empowered to make decisions by building control mechanisms in the system. Digitized governance of business logic and data input allows for the automation of approval mechanisms. This way, frontline workers do not need to rely on managerial input or feedback to make decisions or handle exceptions. At the same time, management is still in control of decision making logic and has an auditable and transparent record of decisions.

Case study example:

For a multinational firm operating in China we re-engineered and standardized its procurement process. This client was a service provider, so procurement was not a competitive advantage. Therefore, it made sense to automate as much of this process as possible.

Every function in the organization was able to procure items required for their daily activities. However, with a major grey area between personal expenses and corporate procurement, there was no clear overview of what was being procured. As a result, the client lost out on volume discounts and procurement was prone to favoritism. More and more complex validation processes had to be implemented to compensate for the lack of transparency. This vicious cycle was no longer sustainable.

Monogon’s solution was straightforward. We dramatically reduced the number of vendors, worked with the organization to define contracts with a select group of vendors to acquire items at pre-approved price points. Within the system, authorized staff could issue purchase orders against these agreed prices and contracts, without having to get approval from management.

When approval logic is built into the system, repetitive processes can be cut down significantly. This will free up managerial time, save money and empower frontline workers.

Capture information once and at the source

Ever requested a credit card from your bank where you have been a customer your entire life, but were asked to fill out your name and email address in the application form? This type of poor experience is due to siloed organizations, siloed systems and siloed processes.

This principle is simple: capture information once at the start of a process. Store it centrally where each consecutive process can extract and update the information. Never ask for the same information twice. And certainly, don’t store the same information twice in different databases. All of this adds complexity, duplication and extra overhead to manage.

Case study example:

At a large transformation we ran at an education provider in China, we found that customers were asked to provide the same information up to five times. An offline promoter would ask for their personal details, the telemarketer would confirm them, school staff would ask the customer to fill out another form, the sales rep would repeat the questions on the form and the service staff would once again confirm the details during onboarding.

Monogon streamlined this process through the combined power of Salesforce and WeChat. We captured and validated the prospective customer’s phone number using WeChat. The offline promoter would also capture their reason for interest, while the metadata would reflect time, location and the promoter who captured the data. The telemarketer’s script was dynamically adjusted to reflect this degree of contextual awareness. Upon arriving at the education center, a customer would scan a QR code that triggered a pre-filled form, where only missing details had to be input. The sales rep walked into each conversation with all details on their tablet, ensuring a smooth hand-over to the service rep for onboarding.

This principle is not about saving time or money. It’s about taking a commonsensical step to deliver excellent customer experience.{.}