3 Business Process Reengineering Examples: Airbnb, T-Mobile, Ford Motor Company Success Stories

Michaela Magátová
Minit Process Mining
10 min readMar 24, 2020

Search online for Business Process Reengineering (BPR) case studies or examples of its successful implementation, and you’ll find what we found — Ford Motor Company.

Ford’s successful attempt at reengineering a core business process is a textbook example of Business Process Redesign done right (we’ll get to that, don’t worry).

It’s the BPR case study talked about a 1,000 times online, and the story made famous in “Reengineering the Organization”, a book written by American business consultants, Michael Hammer and James Champy, in 1993.

But that was 1993 … that was pre-dot-com boom, pre-social media, and only 2 years after the World Wide Web became publicly available. Jurassic times, really.

What About New Examples of Business Process Reengineering Projects?

For thoroughness’ sake, and because it is a damn good example of BPR, we do take a moment at the end of this article to describe how Ford Motor Company transformed Procure-to-Pay with invoiceless processing.

But now for freshness’ sake, we want to explore how modern businesses of the 21st century undergo Digital Transformations associated with process redesign.

>> Watch Now: Process Simulation Webinar <<

We turned to two well-known companies who have undergone massive process transformation and are relevant to how businesses operate in 2020 — Airbnb and T-Mobile.

You won’t find these BPR implementation case studies cited in any textbook, nor will you find them quoted across the internet. That’s because we dug deep to find stories about businesses of today that are applying the principles of Business Process Reengineering to achieve quantum leaps.

Yet, they don’t always call it BPR.

Digital Transformation, Change Management, and Process Reinvention are sometimes more popular terms to call what Hammer and Champy coined as “Business Process Reengineering”.

A rose by any other name would smell as sweet, thus, the underlying rules of Business Process Reengineering apply to these examples:

  • A core business process is broken, dysfunctional, or underperforming
  • Leadership seeks dramatic process change (reengineering) as a solution

The following stories from Airbnb, T-Mobile, and Ford are all within this thread. A Problem / Solution / Learning format can help you identify similar patterns within your own organization.

How Airbnb Reengineered the Product Development Process

Airbnb is known for their coolness. Want to sleep in a treehouse in the Balinese jungle? It’s just a few clicks away. Looking to make some secondary income on your vacation home? List it on Airbnb.

Behind the scenes, the company was struggling to find their internal identity in a design-centric Silicon Valley, and to create a sustainable, quick to deliver, product development process.

Problem Definition

The three main functions which contributed to the Airbnb product development process — designers, engineers, and researchers — worked in silos, only jumping into the process at defined times.

Those defined times weren’t serving the end goal of delivering a great product on time.

Designers had to wait on engineers to write code before a mock-up could be visualized on screen. In turn, engineers had to wait on researchers to validate product ideas, only to find at the very end that project assumptions were off-base.

This was less so a failure of bulldozing researchers, needy designers or overly-coveted engineers.

It was a process failure.

“This was a strong signal to me [of] a failure of process and the need for more deep and consistent engagement between … teams.”

Judd Antin, Head of Research, Airbnb

Solution #1: Treat Geographically Dispersed Resources as Though They Were Centralized

The product development process needed to be reengineered. Not optimized or automated, but fundamentally redesigned. According to Alex Schleifer, Head of Design at Airbnb, he and about 300 other people on Airbnb’s product team spent nine months doing just that.

The solution? To create one digital environment where designers and engineers work seamlessly together.

Rather than each team working on separate systems, which meant rounds and rounds of “quasi-prototypes” and “layers of abstraction”, this single digital environment enables files to show updates in real time and reflect real data.

“To prototype [something] before, it would have taken us days of revisions. Using the new system, we can redesign one of those screens in 45 minutes.”

Alex Schleifer, Head of Design at Airbnb

BPR Learning

Treat geographically dispersed resources as though they were centralized. In Airbnb’s case, the way to centralize the product development process was to centralize the internal development tool.

Even if coworkers weren’t able to sit in the same room, they were looking at the same product in real time. This virtual centralization supports the team in quick back and forth product development.

Solution #2: Organize Around Outcomes, Not Tasks

Another part of the reengineering solution of Airbnb’s product development process was to design product teams around outcomes, not features.

“If you [organize] based on features, then you’re going to be perpetuating those features whether they’re useful or not,” explained Jonathan Golden, Airbnb’s Head of Product.

This approach baked in an unfamiliar step into the product development process — emotions. Teams were now pushed to talk about outcomes from both a lofty, aspirational perspective, as well as a nitty gritty code perspective.

“Outcomes define what we want to achieve for people in our community.”

Jonathan Golden, Airbnb’s Head of Product

This process reorganization around outcomes also meant teams were thinking more deeply about customer needs. They all became customer advocates and were better able to find the voice of the customer throughout the process.

BPR Learning

Organize around outcomes, not tasks. This principle holds true when applied to common business processes such as Procure-to-Pay and Order-to-Cash, but also to Product Development. When individual tasks (or in Airbnb’s case, features) become the organizational priority, the larger outcome is mistakenly shelved for the immediate need of the task.

Solution #3: Link Parallel Activities Instead of Integrating Their Results

What about the researchers who would come in at the end of a project and bulldoze everything designers and developers had built?

According to Antin, researchers became “deeply embedded into teams, as equal partners on the product team, forming strong and enduring relationships.”

They now participate in every stage of the product development process to ensure the voices of guests and hosts are incorporated throughout the project, not just as a validation stage at the very end.

“By making all this happen at the right point in the process, things move faster, not slower, because there’s … more informed decisions and less backtracking.”

Judd Antin, Head of Research, Airbnb

BPR Learning

Link parallel activities instead of integrating their results. By embedding researchers into the process, they were able to validate development stages along the way. Rather than trying to massage in research outcomes to an already existing product, Airbnb links research activities along with designer and engineering activities.

(This case study was sourced from the following articles: Wired, Wired, Aribnb, Firstround.)

T-Mobile Becomes Un-Carrier by Reinventing Customer Service Process

T-Mobile had one goal — to make customers happy. Simple, humble, some may say obvious, but in the telecommunications world, happy customers were not the KPI customer service reps cared about.

Pay structure and customer service success at large were measured mainly by First Response Time (FRT) and Average Handling Time (AHT). Two metrics that screamed “Be quick!” Not “Be kind, be helpful, make customers happy!”

Problem Definition

T-Mobile found itself in a KPI pickle: stick with the industry standard of quick service at a low cost, or find a new process for serving customers and transform how value is measured from a service performance perspective?

Due to the introduction of self-service portals, customers no longer used the T-Mobile call center for basic transactional tasks such as balance inquiries and change of address.

Now, customers were calling with complex issues that customer service reps, with their existing level of training, low level of authority, and disconnect to local markets, could not solve.

Solution #1: Have Those Who Use the Output of the Process Perform the Process

T-Mobile set out to reengineer the customer service process for the new needs of customers, by undergoing a wholesale transformation from factory floor to knowledge-work.

“Unshackled from legacy metrics like handle time, [customer service reps] instead think about the best way to solve each caller’s problem and, ultimately, how best to improve customer retention, share of wallet, and loyalty.”

hbr.org

Within the Business Process Reengineering initiative, T-Mobile started redesigning the team structure — the core of how customer service is delivered.

Like most call centers, there was one long queue and customers were connected to agents via an often frustrating phone tree. Rather than optimize the existing phone tree, or invest in bots that could better understand human voice requests, T-Mobile reorganized teams based on a typical B2B “named accounts” format.

They called this structure TEX — Team of Experts model.

Cross-functional groups of 47 people were formed which served a dedicated market, geographically speaking. The TEX structure gave representatives power over the entire process of customer service. They were empowered and trained to solve a customer’s problem from start to finish.

“Transfers are rare; the only time a rep will hand off a customer is when an … unusually complex problem requires the help of the team’s tech specialists. Even then, the rep will stay on the call to learn how to resolve similar matters in the future.”

hbr.org

BPR Learning

Have those who use the output of the process perform the process. Agents are the ones responsible for the outcome of the process — happy customers. KPIs are connected to Profit and Loss (P&L), so the process outcome is extremely important to agents. Because they perform the customer service process, often in full, they are happy to be accountable for the outcome.

Solution #2: Put the Decision Point Where Work Is Performed and Build Control Into the Process

The next big change, deeply connected to the new TEX model, was shifting authority and decision points within the process.

Managers were playing a superficial role, being called upon for the tiniest of things “officially” beyond the scope of the low-level agent. It was clogging up the process, increasing wait times, and left agents stuck at the bottom of the ladder.

By shifting the decision point directly to customer service agents, the entire process became stronger and shorter. Those performing the work were responsible for the work and could make a true impact on process outcomes.

“TEX teams are expected to manage their own profit and loss statements. They’re like mini-CEOs running their own businesses.”

Callie Field, executive vice president of customer care, T-Mobile

BPR Learning

Put the decision point where the work is performed, and build control into the process. Now agents don’t need to turn to managers to make decisions, they can decide what’s best for the customer at the right moment of the process.

The outcomes of reengineering the customer service process have been astounding.

Over three years since introducing the new measures in 2015, T-Mobile achieved a 71% decrease in transferred customer calls, 31% reduction in calls escalated to supervisors, 25% drop in postpaid customer churn, 56% increase in Net Promoter Score, and 48% decrease in annual customer agent attrition.

Ford Motor Reengineers Purchase-to-Pay Process With BPR

Now, for the evergreen of all the BPR examples, Ford Motor Company.

The American automotive giant was probably aweb by the news that Japanese competitor Mazda had operated with an Accounts Payable team of 5. Ford had a whopping head count of 500 for the same department.

Initially, before turning to Business Process Reengineering, Ford had a modest improvement goal of 25% headcount reduction. After the revolution that Mazda, a much smaller company but viable competitor nonetheless, managed the Procure-to-Pay process with significantly less resources, Ford reconsidered the necessary measures needed to compete in a globalized market.

Ford formulated a hypothesis — if we rethink how Accounts Payable, part of the Procure-to-Pay process, creates value, then we can restructure our entire approach to invoicing, and thus, save a lot of money.

Ford put this hypothesis into action, took a page from their competitor’s playbook and reduced headcount by 75% through invoiceless processing. Read about Ford Motor Company’s experience with BPR here or here.

What Role Could Process Mining Play in These Business Process Reengineering Examples?

Did Airbnb, T-Mobile, and Ford Motor Company use Process Mining to undergo their Business Process Reengineering projects? Maybe, maybe not. We don’t know.

But, if we assume that:

#1: these companies are data driven,

#2: the majority of their process workflows occur within systems,

We can discuss how Process Mining technology could have been applied to these BPR examples.

Business Process Discovery: mine event logs to reveal the as-is process. This basic function of Process Mining technology enables teams to align assumptions and create a shared understanding of reality.

Identify Process Bottlenecks: it’s easy for employees to give anecdotal evidence of what’s causing a process bottleneck. But diving into the data can reveal unintended consequences, such as process bottlenecks, from well intended activities.

Process Simulation: once a new process design is proposed based on mined data, the best way forward is to simulate that process in a controlled environment, but with real data and real parameters. Simulation provides a space for play, without risking a complete process fallout.

Business Process Monitoring: an ongoing element of BPR is ensuring the process is continuously working as intended. Particularly if RPA or other forms of automation are employed in the new process, process monitoring is the built in security that things are running according to process architecture.

Start Your Business Process Reengineering Project With Minit!

Business Process Reengineering is a big step towards Operational Excellence. It favors drastic change over incremental and challenges you to step back, rethink how the process really works, and ask:

  1. Which steps are superficial and which steps are fundamental?
  2. Where is value really added and how can we be sure a proposed change is the right change?

These are all valid questions, and sometimes fears, that come along with undergoing Business Process Reengineering. Minit has created a solution for mitigating the risks associated with BPR — Process Mining combined with Process Simulation.

We make it possible to deliver a BPR project supported by real data. Your data + our system = data-driven process reengineering.

See how it works and get in touch with our team today to try Minit for yourself.

--

--