The following is a guest blog post from business process guru, Alec Sharp. For more details on the processes and frameworks described in this post, you can access a recording of his recent webinar with Lucidchart, "What You Really Need to Know about Improving Business Processes," here. 

We’ve all heard the benefits of improving our business processes—efficiency, productivity, and cost savings. While those are the widely-cited benefits, sustainability, agility, responsiveness, and innovation are also outcomes an organization can strive for. It’s not all about efficiency and cost! But actually improving business processes can be daunting without a clear framework and realistic methods. 

To start, let’s take it back to the origins of the modern focus on processes. In a 1990 article, Michael Hammer, a leader in management practices, was one of the first, if not the very first, to describe how organizations could radically rethink their approach to business processes. (In fact, the term “business process” wasn’t used until Hammer’s landmark article.) Rather than try to speed up and improve old processes with software and technology, he proposed that “as-is” processes should be “obliterated” and that it would be better to start fresh, taking an “end-to-end” perspective in designing the “to-be.”

We soon learned it was important to take some time to understand the as-is process before obliterating it, but Hammer’s holistic perspective is more essential than ever

This article takes Hammer’s concept of fundamentally rethinking business processes, and pairs it with simple yet powerful techniques you can use to begin improving your own processes without having to completely start over.  

What is a business process?

According to Hammer, a true business process is “end to end” and “cross-functional” in nature, concepts that have a specific meaning. A business process consists of a set or sequence of major activities (or sub-processes) initiated by a triggering event, that collectively produce meaningful results for one or more stakeholders. By “end-to-end” we mean from trigger to results. Almost invariably, the activities span multiple departments and groups, which is what we mean by “cross-functional.” 

Here’s a simple framework to describe a business process. I call it TRAC: 

• Trigger: An event that initiates the entire process
• Results: Outcome(s) of the process 
• Activities: Major phases or milestones (seven or so) within the process 
• Cases: Major variations that will influence the flow of the process 

This is an “essential” description of a process, a fundamentally important idea we’ll expand on shortly. Before that, let’s look at a common source of confusion.

Process vs. Procedure 

The words “process” and “procedure” are often used interchangeably, but they are not the same thing at all. A process is broader in scope (“end-to-end”) and includes many participating roles and organizations, units, or functions ( making it cross-functional). A process can be broken into several major activities (sub-processes, phases, or milestones) each of which contains more detailed activities, which, in turn, contain multiple specific tasks. And there might be a procedure for each of these tasks. 

A procedure, at the other end of the spectrum, is a set of instructions to complete a single task in a way that delivers identical results every time. Essentially, a procedure is a job aid. Most important to the process-procedure distinction, a process will contain many or even hundreds of procedures. 

For example, the process “Onboard New Product User” cannot be reduced to a single procedure. Rather, it is made up of several steps, each with their own procedure, to help the user get acquainted with the product. To show the difference between a process and a procedure we’ve broken it down using TRAC. 

Triggering Events

• Company targets potential product user
• Product user signs up for account

Results

• Product user: activated product access 
• Company: activated subscription, onboarding metrics

Activities

• Send user welcome
• Set up user account
• Complete user in-product orientation 
• Confirm user onboarding milestones 
• Provide onboarding metrics 

Cases

• Corporate users (part of a large organization) 
• Individual user 
• Foreign / Offshore user

Focus on the what not the who or how

One of the first steps to improving a process is to open individuals up to the possibility of change. Because processes involve many people, it’s easy to get caught up in individuals’ roles and responsibilities–the who–and overlook the process’ big picture. When the who is the focus, people are more resistant to change because it can become personal. Therefore, we must shift our focus to determine and understand the essence of the process–the what.

Reorienting your perspective around what yields what is called an essential model because it depicts the essence of the process with no implementation details–what is the trigger, what are the results, what are the main activities, and what are the major cases? That is, what is the essence of the process? We depict this in what I call a “Process Scope Model,” following the TRAC framework we introduced earlier.

An essential model illuminates the most important aspects of the process and not any one person’s role in it–the who. Also critical, it contains no reference to how–the systems, technology, procedures, forms, and other mechanisms that support the process.  

With this implementation-independent view, you and your team have the space to start envisioning real change. When I’m engaged by a client to do what I call “project recovery” work–getting a stalled or failing initiative working again–I have to help them construct this essential view using the TRAC framework 100% of the time. Not 50, or 80, or 95% of the time–100%! Why? Because a common denominator of struggling projects is a rapid descent into the weeds of unhelpful detail. 

How to name your process 

Properly naming your process is far more important than you might assume. The process’ name should clearly, for everyone involved, indicate the intended result – what the process achieves. If it doesn’t, you’re already subject to confusion and misinterpretation. The key is to use active verbs and nouns, and no “mushy verbs.” 

Here are two simple steps to name a process: 

1. Start with an “active verb – noun” format,
   e.g., “Acquire Customer” 

2. Flip it to a “noun is verbed” format to restate the name as a discrete result,
   e.g., “a Customer is acquired” 

This should be an identifiable, countable result. That is,

• you can identify each individual Customer that was acquired; 
• you can count how many Customers were acquired each day, week, or whatever.

Note there could be two nouns, e.g. "Assign Agent to Region," or even two verbs, e.g., "Admit and Onboard Student."

Some of the most common mushy verbs include monitor, manage, handle, review, administer, and, ironically, process. If we named a process “Handle Claim” that would yield the result “a Claim is handled,” which certainly doesn’t tell us the intended result. “Settle Claim” would be much clearer.

Don’t get bogged down by the details

“All models are wrong, but some are useful.” — George E.P. Box

Box’s quote reflects how models can be used and misused for process improvement. While detailed models can be helpful, they shouldn’t be the backbone of your improvement effort, and certainly not the starting point. Higher level models, like the Process Scope Model (TRAC) we described earlier, are usually less wrong and more useful.

When groups and organizations set off to refine existing processes, it’s easy to get caught up in the most granular work. All too often, the result is a process model that describes procedural-level details. When this happens, the essence of the process is lost, and, surprising to many practitioners, the additional detail leads to less useful information!

As counterintuitive as it may seem, when it comes to process improvement, less detail can actually lead to more speed and agility. Focusing on the process as a whole rather than individual details lets you and your team quickly go through the entire process to pinpoint issues and iterate rapidly to find solutions. 

But getting out of the weeds is tough without a clear, “big picture” framework. Struggling with this issue, over many assignments, I ended up developing three higher-level models your team can use to get started on process improvement. Bonus: you can focus on the entire process and less on the details. 

1. The Process Scope Model, illustrating the essence of the process, using the TRAC framework, as illustrated in the “Onboard New Product User” example earlier. This is important to help everyone focus on what the process is, and set aside the who and how until later.  

2. The Process Summary Chart, which strips some detail from the Scope Model, but adds the Functions/Organizations that participate in the process. This is a critical tool in helping people understand the difference between process and organization.

3. The Augmented Scope Model, which is a transition into what actually must be accomplished in each phase of the process, and then adding who and how. It captures detail rapidly that often eliminates the need for an as-is swimlane diagram, and always makes it much easier and faster to develop the initial swimlane diagram. 

Here’s just a little more detail on each type of model.

1. Process Scope Model

Before improving a business process, you must understand what  the process is, and what it is intended to achieve–its essence. As an essential model, it focuses on the what of the process and not the who or how. When you remove specific people and their roles from the equation, and the current technical implementation, it makes it easier for everyone to embrace the possibility of change. Being open to change is essential, too. 

The process scope model follows the TRAC framework. As such, it starts with a triggering event. There are three types of triggering events: 

• Action: A decision-based event (e.g., a customer decides to purchase a subscription) 
• Temporal: A time-based event (e.g., the end of a free trial experience) 
• Conditional: A data-based event (e.g., a user engages with your product six times)  

The completion of the process is indicated by the delivery of a specific result to each stakeholder. Most processes deliver a result to the Customer of the process and to the Owner of the process, typically the enterprise itself. 

For example, the Customer might receive an ordered product, and the Owner might receive payment. An individual Performer often receives a result, for instance a Salesperson might receive a sales commission. Other potential stakeholders include Suppliers, Partners, Regulators, Associations, and so on. Results generally fall into three categories:

• A good: A physical item, such as a delivered product. 
• A service: The performance of some activity, such as a resolved service issue.
• Information: The provision of information, such as a financial statement. 

Now that the “bookends” of the process (the beginning and end) are clear, focus on determining the 5 to 7 major phases that are a part of the process you are examining. Try brainwriting (individual brainstorming on sticky notes or a Lucidchart white board) to get people thinking about the activities that go into the process. 

Then, synthesize these as a group into 5 to 7 main activities or milestones. We say “5 to 7” because that is a natural starting point for most people–you don’t want to jump into the detail of 25 activities between trigger and results. The key to success at this point is ensuring people only use active verbs and nouns, which is a great trick for keeping people out of unhelpful details. As soon as “who and how” creep in you’re on the slippery slope into procedural level detail, which is very unhelpful at this stage.

This is all highly iterative, and you might be more comfortable identifying the main activities first, then working back to the triggering event, and forward to the final results. 

Part of what makes the process scope model so useful is that it can be done quickly and efficiently. In less than an hour you can put together a simple scope model that includes the triggering event, the major phases, the results, and even a few major cases or variations. 

Additionally, the process scope model provides a clear, broad picture of the entire process. Even if your team only needs to improve one or two phases or sub-processes, understanding how they fit into the overarching process is critical. Focusing on local optimization leads to global sub-optimization, hindering the entire process.  

2. Summary chart

A summary chart is a simple overview of the entire process and the involved organisations. It simplifies the Process Scope Model and adds the internal and external participants. For instance, internal participants might include the organization unites Inside Sales and Accounts Payable. External participants could include enterprises such as Courier or Regulator, or Individuals such as Customers or Applicants. 

Generally, I don’t show the trigger, result, or cases on a Process Summary Chart, but that’s a matter of personal taste. I keep it simple because, above all, I want to clearly depict the cross-functional nature of the process. That’s the point of the Summary Chart–it illustrates in a simple accessible way the what and the who of the process. While simple, the Summary Chart illustrates the complete end-to-end process to get the point across.

3. Augmented Scope Model 

The Augmented Scope Model builds on the Process Scope Model. After putting together your process scope model you will have identified several major phases of the process. The Augmented Scope Model breaks each of the major phases or sub-processes into five to ten individual activities.  

Initially, we just focus on “what,” e.g., “Log Service Issue.” Later, we can add “who and how” to each activity, e.g., “Customer Service Rep - Log Service Issue - using CRM.” This efficiently captures the level of detail that should be in your initial swimlane diagram. I never do a swimlane diagram without first doing a Process Scope Model and an Augmented Scope Model because they make the “swimlaning” go so much faster!

Understanding process behavior

How well (or not!) a business process performs is influenced by multiple factors called enablers. There are six common enablers that can impact the business process’s behavior.

• Business process design 
• Technology and information systems
• Motivation and measurement 
• Human resources and organization 
• Policies and rules 
• Facilities 

Typically workflow design and technology get the most attention when it comes to process improvement. However, the human, social, and organizational elements are often the most influential factors, as people are the ones implementing the process.

Consider the motivation and measurement enabler. It is a performance measurement that contributes directly to how the process functions–what is measured determines the outcome. For example, while it may seem like a good goal to keep sales calls under two minutes to drive efficiency on the sales floor, this measurement may lead to unforeseen problems. Keeping calls under two minutes may lead to a decline in sales and revenue, poor customer service, and more.

Therefore, it is essential to incorporate the enablers into the entire process improvement framework. Determine how individuals in each of the major phases interact with the process and where in the process they are to fully understand their impact on the process. An entire process could be assessed, changed, and communicated, but if these enablers aren’t considered it is impossible to have sustainable change with a positive outcome.

Process improvement is no easy task, but given the right time and strategy it can yield huge benefits. By following the strategies outlined above, you can start making real change in your organization.