A Practitioner’s Perspective: Now’s Your Chance – What to Cover in an Executive Briefing on Business Processes

At the end of my November 2011 Column “Capabilities, Agile, and Process Blindness” (http://bit.ly/rGGFJh) I said my next Column would share what I cover in executive briefings on business processes. After waiting for about a year, Adrian Apthorp asked when I was going to get around to writing that. Yet another year later the answer is “now.” Happily, if the topic is a “briefing” I might succeed in my ongoing quest to finally write a brief Column. Let`s see how that works out.

Getting yourself oriented

So, you finally have some time in front of your organization`s senior executives. What will you tell them about the exciting world of business processes? That you`re BPMN compliant? That you will soon be a Level 3 organization? That you could transform the enterprise, if only they`d get on board?

No, that`s not likely to go well, so what should you cover? Maybe I can help with that. I`ve done briefings on business processes for C-level and other senior executives, on five continents, and in a wide range of enterprises. Based on the interest and action they generate, even though the locations and businesses could hardly be more disparate, these 60 to 90 minute briefings have been very successful. Before we get into the contents of a typical briefing, let`s consider some factors that contribute to success.

Setting the right tone

One constant is that executives, like most everyone else, would rather be informed than be lectured to or pitched to. I`m pretty sure one reason the briefings go well is that I never try to sell BPM or convince the execs they`re missing the boat if they don`t get into it. Many years ago I made a conscious decision to eliminate the terms “convince” and “sell” from my consulting vocabulary and shift my thinking to “demonstrate.” Executives in particular don`t naturally respond well to efforts to “convince” or “sell” them. If you begin by thinking “How do I convince the executives of the value of XYZ?” or “How do I sell XYZ to the enterprise?” you`re likely starting off on the back foot. It`s better to think “How do I demonstrate the value of XYZ to the executives, and what can I tell them that will be interesting and informative?

Besides, you`re probably not going to impress anyone with assertions that business processes are critical to:

  1. Reducing costs and increasing efficiency
    (The perennial #1 BPM selling point)
  2. Improving customer service
  3. Increasing responsiveness (and the all-important innovation)
  4. Ensuring regulatory compliance

Of course, these are all true, but remember – every other approach, from Employee Engagement Surveys to Big Data, is making the same claims, so no one would believe you anyway. Keep one of my favorite tag lines in mind – “Don`t preach, don`t overreach.”

Safe assumptions

Three other ideas to keep in mind:

  1. Always (always!) assume that no one else, executive or otherwise, shares your definition and understanding of “business process.” Most executives naturally think in functional terms. In fact, so does everyone else. “Our sales process” and “our distribution process” will sound perfectly reasonable to them, even though those are probably the names of functions or organizational units. Even worse, in some environments 90% of staff and management think “process” means “procedure,” which is not an inspiring topic. That`s why the first point is always to demonstrate what we mean by “end-to-end cross functional business process.”
  2. It`s also a safe assumption (see the preceding) that neither the executives nor anyone else shares your enthusiasm for processes. In fact, they may be quite hostile to the idea. This could be due to the well-known “BPR Hangover” – the result of initiatives that were labelled as “Business Process Reengineering” but were actually downsizing, outsourcing, or mindless technology implementation. More recently, it could be due to overly-zealous Six-Sigma or Lean proponents, and their annoying belts and penchant for funny language.
  3. Finally, don`t assume that the first step is to get the oft-cited “executive commitment” or it`s poor relation, “executive support.” In most cases, the impetus for process orientation doesn`t begin at the top. It starts in the middle, with local or smaller scale successes that lead to larger successes. The message bubbles up, eventually to the highest levels, and you find yourself being asked to deliver a briefing on business processes.

Let`s look at what you might tell them.


We might as well start with the name. Some of the briefing titles I used in 2013 include:

  • “Business Processes – What They Are, and Why They Matter”
  • “Becoming Process Oriented – Five Key Points About Business Processes”
  • “Business Process Change – Avoiding the Common Pitfalls”

I don`t refer to “Business Process Management” (BPM) in the titles – I`ve never been wild about the term because it sounds too passive – but be my guest if it works for you. Perhaps something like “Business Process Management – What It Is and Why It Matters” would work just fine at your organization.

If the term “business process” carries too much baggage at your enterprise, as it often does in education, health care, justice, and other fields, you might opt for “capabilities” or the even more neutral “getting results.” My last Column “Peace Accord Reached – Process vs. Capability Debate Ends with a Whimper” (Nov 2013 – http://bit.ly/1eTvLF6) includes an example of how I adapted one of my frameworks to use “Capability and Capacity” instead of “Business Process.”

Core content

The baseline briefing covers five key points. I outline them on the first slide (after the title/presenter slides) exactly as follows:

  1. It's essential to have clarity on what an end-to-end business process is
  2. Existing performance measures are often functionally aligned and work against business processes
  3. Enterprise system implementations must include a
    business process perspective
  4. Success with business processes depends on a holistic
    (not a technocratic) view encompassing six enablers
  5. Business processes can't be great at everything – a single differentiator or strategic discipline must be chosen

If those points are a bit aggressive or wordy, feel free to dial them back and edit.

I always cover the first two points, and pick and choose from the others. Point 3, on the relationship between enterprise systems and business processes, is the one I drop most commonly. In some companies it`s the point that has the greatest impact, especially if they`re embarking on a major system initiative, but in other cases it ties “business process” and “IT” too closely together. On the other hand, when large-scale system implementation is a looming issue, I`ll often add a topic on process modeling and business analysis techniques.

The order

Other than the first point always being to clarify what we mean by a “business process,” the order can be adjusted to suit the situation. For instance, the head of the business process group at a global oil and gas company felt that the following order (and wording) would resonate better given their current issues, and he was right:

  1. Clarity on what a business process really is
  2. Business processes can excel at only one differentiator
  3. KPIs often work against business processes
  4. ERP implementations must focus on business processes
  5. Business process success depends on a holistic view

Bonus – those points are also less wordy than my usual overview slide.

We`ll now look at what I cover for each of those five topics. Most of the material will be quite familiar to business process professionals, so I`ll cover the key ideas in point form. That way, if you use this Column as a resource, you can easily choose the ideas that will be most relevant in your situation. Many of the individual topics have been addressed in previous Columns, and I`ll provide references to them. The purpose here isn`t to introduce new concepts, but to show which ones carry the most impact at the executive level.

1 – What is an “end-to-end business process?”

The main idea

An “end-to-end, cross-functional, business process” is larger than most people expect when they think of “a process.” Even within the “process community” there are very different ideas of what a process is – a “process” according to a Six Sigma expert will almost certainly be much narrower in scope than a “process” according to a BPM practitioner.

This difference in perspective is summed up nicely in a statement from a manager we worked with – “Processes? We have hundreds of processes, and we don`t need any more!” Cleary, this person was talking about procedures, not business processes.

Why it matters

Improvements to a part of an end-to-end process, without considering the entire process, typically leads to worse performance overall. As Eliyahu Goldratt noted, “local optimization leads to global suboptimization.” On the other hand, transformative improvement is usually only possible when the entire end-to-end process is considered.

Illustrating the point

This is really the fundamental issue in working with business processes, so all business process professionals should have a ready stock of examples. The one I most often use is of a telephone company that confused processes with functions. When they “reengineered” their Service Provisioning processes (which were actually organizational functions, not processes) the performance of the actual end-to-end processes was much worse than it was before. Subsequent work showed that the five “processes” they reengineered were actually subprocesses of an end-to-end process.

Figure 1: The “processes” (and corresponding functions) a telephone  company mistakenly “improved”

Figure 1: The “processes” (and corresponding functions) a telephone company mistakenly “improved”

Figure 2

Figure 2

If time permits, I also include an example showing that processes and functions are related on a many-to-many basis and form a matrix.

Function – a kind of work that provides specific expertise; a central aspect of how most enterprises are organized.

Business Process – a set of activities, usually cross-functional, that delivers a critical business result;

Figure 3: Functions  (“vertical”) and processes (“horizontal”) for a manufacturer

Figure 3: Functions (“vertical”) and processes (“horizontal”) for a manufacturer

Miscellaneous points and resources

  • It takes concerted effort to identify Business Processes – they are usually “hidden” by organizational structure, geography, and systems.
  • Processes must be made visible and managed as a whole;
    neither is easy

Several Columns have looked at what a “business process” really is, with examples you might want to borrow:

Clearly, this is a topic I think needs attention.

2 – Performance measures might be the problem

The main idea

The performance goals of the functions (divisions, departments, …) that participate in a business process often conflict with the goals of the business process, if business process goals are explicitly stated at all.

Why it matters

If explicit and implicit performance measures, and the associated rewards and punishments, are not updated as part of business process change, behavior will always drift back to the old process. Inappropriate KPIs (Key Performance Indicators) are the most frequently unrecognized cause of poor performance. The performance goals for the participating functions must align with the performance goals of the process.

Illustrating the point

This is the other topic for which all business process professionals should have a set of examples to draw on. I regularly use the global high-tech manufacturer that had a goal of reducing the cycle time (“from order to cash”) of its core order fulfillment process. Initial efforts were stymied because the performance targets, and the associated rewards and compensation, were functionally based and actually worked against the goals of the process.

Figure 4: Conflicting  process and functional performance targets

Figure 4: Conflicting process and functional performance targets

Miscellaneous points and resources

  • Performance measures often become “perverse incentives” and lead to unintended consequences.
  • This doesn`t mean functions are “bad,” or that organizational structure should be based on processes. That works poorly in practice – you need a center of expertise (the function) and skilled resources that can contribute to multiple processes. That`s why we avoid the somewhat negative term “functional silos”
  • A business process needs an owner / steward to set direction, ensure alignment, and, most of all, rationalize the competing objectives.
  • Performance measures can`t be totally process-centric. The current situation is typically optimized functions, and very sub-optimized processes. But, if you go too far the other way, you end up with optimized processes and very sub-optimized functions.

Pages 6 and 7 of “Process Architecture on a Budget – Part 1” (Feb 2010 – http://bit.ly/9v3O7n) describe the example I usually use to demonstrate the conflict between process and function performance measures.

Coincidentally, it`s pages 6 and 7 of “Disabled by Enablers, Punished by Rewards” (May 2012 – http://bit.ly/Z4DvMk) that have more examples of the impact of ill-advised performance measures.

3 – Processes and major information systems

The main idea

When major information systems are implemented without regard to end-to-end business processes, the overall result ranges from barely adequate to truly awful.

This is especially true for large-scale COTS (“Commercial Off The Shelf”) and ERP (“Enterprise Resource Planning”) implementations.

Why it matters

Government and commercial enterprises regularly spend tens or hundreds of millions of dollars on system implementations that are unsuccessful, spectacularly so in some cases – they bankrupt the company.

Illustrating the point

The most compelling illustration of this point was in the old (late 1990s) but still entirely relevant “Succeeding With SAP” video featuring the late Dr. Michael Hammer, who I think of as “the godfather of reengineering.” He observed that the success of SAP implementations varied wildly, and sought to uncover the root causes of success and failure. He worked with a large number of organizations to assess the success of their implementation on a 1 – 10 scale:

  • A “1” was an unmitigated disaster
  • A “10” was wildly successful

When he graphed the success rating on the X-axis against the number of enterprises at each success rating on the Y-axis, he expected (as we all would) a normal distribution – lots of companies at “5” or “6” and then tapering off in either direction. Instead, the stunning result was not a normal distribution, but a bimodal distribution – a cluster of “3”s (the “losers”) and a cluster of “8”s (the “winners.”) Note that the results are applicable to any large software implementation.

I have examples of unsuccessful ERP implementations with price tags ranging from $1B to $3.5B. In one case, the company was determined to do it right – “This will be a process-oriented implementation!” The problem was, like the telephone company we referenced earlier, they missed the point about what an “end-to-end business process” really was, and configured the ERP modules on purely functional lines. I can`t share those examples, but you should know a few.

Figure 5: Bimodal distribution  of “winners” and “losers” in ERP implementation

Figure 5: Bimodal distribution of “winners” and “losers” in ERP implementation

Miscellaneous points and resources

  • Organizations often re-implement systems they already have in order to make them more process-oriented.
  • As someone I recently met said, “No large IT project is an IT project.”

It`s not much, but page 6 of “Disabled by Enablers, Punished by Rewards” (May 2012 – http://bit.ly/Z4DvMk) has a little more information on the role of information systems.

4 – The enablers of a business process

The main idea

The performance of a business process is determined by six primary factors, which we refer to as the enablers of the process. The more technical of these (process workflow design and information technology) get the most attention, but are seldom the crucial factors. Those are the human and organizational factors, which we refer to as “Motivation and Measurement,” “Human Resources and Organization,” and “Policies and Rules.” Point 2 in this briefing (Performance Measures) addressed the importance of Motivation and Measurement.

Why it matters

When any sort of major change, including business process change, fails to include appropriate adjustments to the human and organizational factors, performance will inevitably drift back to its original state.

Illustrating the point

I simply show the following graphic and then discuss the meaning of each enabler.

Figure 6: The six enablers  of a business capability (business process)

Figure 6: The six enablers of a business capability (business process)

Note that this is the example I referenced earlier where we use the term “business capability” rather than “business process.” The May 2012 Column referenced below has many examples you can use.

Miscellaneous points and resources

  • As-is process modeling can be seen as a way to build a fact-based understanding of the process that allows an assessment by each enabler, in turn.
  • Every significant feature of a to-be process design should be assessed enabler-by-enabler to identify what it will really take to make that feature work. (That sounds like a future Column…)

I devoted a full Column to the topic of enablers in “Disabled by Enablers, Punished by Rewards” (May 2012 – http://bit.ly/Z4DvMk) and it contains a variety of examples you can draw on.

5 – Choosing what to excel at

The main idea

A business process, like a company, can't be all things to all people – it's essential that a differentiator is chosen. It boils down to three choices:

  • Operational Excellence: a focus on efficiency and cost containment
  • Customer Intimacy: a focus on flexibility for the customer of the process, and how they engage with it
  • Product Leadership: a focus on flexibility for the process itself, especially as it relates to the introduction of new products and services, or changes to the mix

Great processes (and companies) don't try to be all things to all people – they strive to be great at one differentiator, and good at the other two.

Why it matters

A lack of clarity around the differentiator, or conflicting statements about what it is, are major sources of stress, frustration, and poor performance. Often, organizations lack focus, focus on the wrong differentiator, or don't recognize that their parts (the functions) are not focused on the same differentiator.

Illustrating the point

As with the previous point on enablers, I simply show the following graphic and then discuss the meaning of each enabler. The Nov 2012 Column referenced below has many examples you can use.

Figure 7: Three  differentiators

Figure 7: Three differentiators

One point I always stress is that the most common problem, other than not being aware of differentiators at all, is a business process being specifically directed to excel at two particular differentiators:

  • Operational excellence – “We must be the low-cost provider!”
  • Customer intimacy – “We must do what it takes for each client!”

When an organization tries to achieve both of these, they tend to cancel each other out, and lead to constant tension for both staff and management.
Another common failing is assuming that “Op Ex” just means being generally excellent, rather than a relentless, ongoing focus on consistency and efficiency.

Miscellaneous points and resources

The original reference:
The Discipline of Market Leaders

Michael Treacy and Fred Wiersma
Addison-Wesley 1995

  • The concept was originally developed at the level of the entire corporation, but we see it more at the level of individual processes
  • Remember, the idea isn`t to be great at one and lousy at the other two – you have to be great at one and at least at industry par on two differentiators

I introduced the topic of differentiators in “That Squishy Culture Stuff” (Jan 2012 – http://bit.ly/Amdmaf) and devoted a full column to it in “What`s So Special about Your Process?” (Nov 2012 – http://bit.ly/1eTBriC)


Well, so much for a brief Column.

We`ve looked at five core ideas that form the basis of most of my executive briefings:

  1. It's essential to have clarity on what an end-to-end business process is
  2. Existing performance measures are often functionally aligned and work against business processes
  3. Enterprise system implementations must include a business process perspective
  4. Success with business processes depend on a holistic (not a technocratic) view encompassing six enablers
  5. Business processes can't be great at everything – a single differentiator or strategic discipline must be chosen

This structure makes the case for taking concerted action on business processes, but works because it provides interesting and useful information for the executives.  One final point – these are essentially the same points, albeit with different examples and emphasis, that I use when briefing middle management, supervisors, and front-line contributors on business processes. It turns out everyone finds the same key points interesting. For staff, it makes the invaluable point that when processes behave poorly, it`s not their fault – it`s the fault of the overall system.

I hope you`ll be able to take what we covered here and adapt it to your situation. Please contact me with any questions or comments.

What’s next?

Now that I`ve done a Column on executive briefings, I can make good on another promise. At the end of my April 2013 column on “Scoping Models” (http://bit.ly/11qjuhJ) I said I`d follow up with a look at how they can be extended and used as analysis models. Nothing matches a swimlane diagram for understanding the reality of the as-is process, but sometimes you just don`t have time, or there isn`t a defined flow to model (think emergent or adaptive processes.) That`s when we shift to relying on a scoping model, and we`ll look at some frameworks and recent examples to help you do this.

Where’s Alec?

The first half of 2014 is looking as busy as ever. In addition to some interesting consulting gigs (Curriculum Management in higher education, and Content Management in digital media) there are several public workshops and speaking gigs on the agenda:

  • In January and February I`ll be downunder for some in-house and public offerings of our two-day workshop “Advanced BPM – Aligning Process Work with Strategic, Organizational, and Cultural Factors.” Software Education is hosting public offerings in Wellington Jan 27-28, Auckland Jan 30-31, Melbourne Feb 03-04, and Canberra Feb 10-11. Sign up now – it gets great reviews every time. We`ll also be doing IIBA presentations in Wellington and Melbourne, and in-house courses will get us to Brisbane and Sydney as well. See you there! http://bit.ly/vJUlzH
  • Feb 20 I`ll be at home in beautiful Vancouver to present “Business Processes: Practical Techniques and Frameworks” for the Vancouver chapter of ARMA, the association for records and information management professionals. http://bit.ly/1gufDHC
  • Mar 10-11 I`ll be back in Helsinki for the two-day “Process and Data Modelling – Practical Techniques and Synergies” workshop I put together for AriHovi.com. It sold out the last two times we ran it, and we had a great time. http://bit.ly/Z2Og1B
  • Mar 13-14 will be one of my twice-yearly London presentations with IRMUK of our two-day “Working With Business Processes” workshop. The best part – the interplay between participants from multiple countries in Europe, Africa, the Middle East, and Asia. http://bit.ly/bno3ll
  • Mar 27 I`ll be doing a webinar hosted by Karen Lopez for the Dataversity “Big Challenges in Data Modeling” series. The topic is tentatively “How Data Modelers Shoot Themselves in the Foot, and What to Do About It.” http://bit.ly/1dYHX2l
  • April 28 I`ll be in Austin Texas at Enterprise Data World (always a high point of my year) presenting “The Human Side of Data Modeling.” http://bit.ly/1jGOXTk
  • June 16-18 I`ll be back for IRMUK`s always-excellent Business Process Management and Enterprise Architecture co-located conferences. Combining these two events has worked out brilliantly. http://bit.ly/1dYKHN9

I hope our paths cross somewhere!

From the Trenches,
Alec Sharp

Alec Sharp

Alec Sharp

Alec Sharp has managed his consulting and education business, Clariteq Systems Consulting Ltd., for close to 30 years. Serving clients from Ireland to India, and Washington to Wellington, Alec's expertise includes facilitation, strategy development, data management, and of course, business analysis and business process improvement. His popular workshops and conference presentations on these topics, conducted globally, consistently receive "excellent" ratings. Alec is the author of the recently-released second edition of "Workflow Modeling" (Artech House, 2008) which is widely used as a university text and is a best-seller in the field. Contact Alec - asharp@clariteq.com.