Author: Alan Ramias

In most of the process maps I have seen produced by others, the process activities (or steps) are depicted like this:

Version 1

That is, the activities are described with a verb-noun format.  Whenever I have worked with a group of people for the first time and they begin to create process maps (without first being trained by PDL), this is the format they naturally, for some reason, apply.  (I suspect this is “natural” because it follows from the question, “What happens in this process?”  “Well, first we design the engine, then we manufacture the parts…”  It’s a grammatical construct that makes sense and is the way we describe how things happen.)

But those of you who have worked with PDL, or taken one of our process courses—such as the Rummler Process Methodology (RPM) or Process Modeling and Improvement—know that we promote a different approach to the naming of activities.  We say that instead of dwelling on activities, the steps in a process map should identify the accomplishments that are achieved as a result of what are often multiple activities.  That is, we see an accomplishment as generally being at a higher level than a single activity.  It is something more important than an activity, and is also measurable against organizational goals or milestones.

To indicate accomplishments inside the boxes on a process map, we use a noun-verb construct, as follows:

Version 2

You’re likely thinking, “What’s the difference between this map and the first one?”  And of course, there isn’t any in this particular example.  The activities in Version 1 are huge.  Designing an engine is composed of numerous sub-steps or activities that when all completed, constitute the achievement of a major accomplishment.  So reversing the noun and verb doesn’t make any difference.

This is why very often when working with client groups, I tend not to push the accomplishment notion.  I’ll explain it, demonstrate it, and if I’m leading the group in creating a map, I’ll apply it.  But often I can tell that I am the only one who really cares about the notion.  And I’ve learned that if I push it too hard, it tends to be viewed as an academic nicety rather than all that helpful.

So in actual practice, I’ve backed off from a militant application of the accomplishment notion and believe my colleagues at PDL have as well.  But still, there is something of real value here that is being overlooked and perhaps worth reviving.

The Origins of the Accomplishment Model

Geary Rummler was a partner with Tom Gilbert at Praxis Corporation from 1969-1979, where they promoted and applied their pioneering notions about performance technology.   The word “accomplishment” pops up in much of their writing, particularly in Gilbert’s book Human Competence:  Engineering Worthy Performance, in which he argued that results can only be produced by accomplishments. 

During his Rummler Group days, Geary often used a tool he called an Accomplishment Model, which could identify and link all the accomplishments an organization has to achieve, from the highest level down to individual jobs.  (A partial example is shown in Figure 1.)  This device could be used for a variety of diagnostic purposes, such as identifying potential breakdowns in accountability, or overlaps between parts of an organization.

And in process modeling, the concept of an accomplishment was intended to keep a group of process mappers from dropping down into the weeds, into small, insignificant activities.  The use of accomplishments also provides a managerial view of a process, which is important in distinguishing between all the details and the worthiness of the result.  To illustrate, here is a mythical cornball interchange between a visiting executive and a worker operating a drill press at a furniture factory.

Manager:    So what is it you do?

Operator:  Well, first off, I brush off the platen, to make sure there is no sawdust in the way.  Then I choose the next chair leg.  I always choose the right front corner leg if it is the first leg of a chair I am doing because then I work my way around the chair a leg at a time.  Then I align the leg on the platen, bottom toward me, like so.  Then I look to see if I must adjust the drill bit.  This is often the case.  And then…

Manager:   Good God, man, I asked you what you do!

Operator:   I’m telling you what I do.  Then I bring the drill bit down…

Manager:   OK, OK, what is it you accomplish with all this work?

Operator:   Oh.  Well, when I’m finished, the legs are ready to be assembled onto the chair.

The key question always is, “So what got accomplished?  What’s the result?” 

So long live accomplishments.  We shouldn’t lose the concept completely, even though we’ve come to recognize that it may strike some people as largely an academic distinction.

BP Trends – September 2010

Authors: Alan Ramias, Cherie Wilkins

Our last column kicked off a series on process metrics.  We started off by citing some of the problems and pitfalls we have encountered in our work with clients, such as creating metrics (and process management roles) that were unlinked to management of the business; creating disorganized piles of metrics instead of a logical set; measuring too much, too little, or the wrong things.

In this column we provide some principles and a tool to remedy the most significant problems.  We will describe the guidelines we follow in creating process metrics for clients and will apply those guidelines using a tool for identifying the right process metrics.  This tool is part of a larger toolkit that we employ when helping an organization build a comprehensive process-focused management system; this particular tool is central to the task of producing good, useful process metrics.

To apply the following principles and tools, some assumptions are necessary:  You have singled out a business process, you have mapped it in enough detail to identify its major subprocesses or phases, and you understand the existing management system into which these process metrics will be inserted.

Principles for Process Metrics Design

• Every process is designed to reliably produce one or more outputs, so, in deciding what metrics to develop, we always focus at first on process outputs, not activities,. The metrics should measure whether the process not only produces the outputs but also that all appropriate expectations are met every time the process is executed.
• Metrics should be applied to all the significant outputs of the process.  If the process is order fulfillment, for example, the output is not just the product but also the invoice, the order documentation, and customer information that will be used again for future orders.
• We always start outside the process itself and try to understand the expectations of the receivers of the outputs.  The receiver may be an actual customer, or it may be an internal party who is also a “customer” for a given output.  Regardless whether the process has an external or internal customer, the starting point is to understand what is important to that customer – what  are the expectations that we can then translate into what we call the “critical dimensions of performance.”  Once we know the expectations for the process, we then create and distribute metrics along the process that measure all of the relevant critical dimensions of performance, such as timeliness, quality, economics, volume, compliance, and so on.
• In first developing metrics, we focus on what to measure, not how measurement is going to happen.  There are several reasons for this:  First, the decision about whether to create a given metric is more important at first than determining exactly how the data might be tracked, reported, archived, and so on.  While measurement can be costly and sometimes not worth the effort, we have watched some teams talk themselves out of a potentially valuable metric just because they weren’t exactly sure at first how to collect the data.  Usually, you have choices as to what to collect and report – for example, maybe you focus only on exceptions, or only reporting quarterly – that can reduce the cost.  And metrics don’t have to be perfect.  Collecting data on secondary indicators of performance may be quite adequate for triggering a closer look, rather than collecting volumes of data that sometimes obscure what is actually going on.  There is also a tendency these days to fixate only on data from systems, but visual data (go and look) and interview data (go and ask) are also viable ways to collect data.
• The most useful performance data helps one see trends in performance.  So, metrics that can be constructed to yield a trend are the most useful, and most metrics can be formulated this way.  For example, “number of defects” for a given output is not that useful except for fixing a single product, but number of defects by product type by day, week, and month could provide a lot of insight into where performance problems are originating.  So in the table below, once we have identified all of the metrics we want, we turn them into trend data by adding an element that enables trend tracking (such as per lot, per day/week/month, per location per week, and the like).
• We seek to identify metrics that will be both leading and lagging indicators of performance.  Lagging indicators are the common ones:  they provide data on events in the past.  But leading indicators provide insight into the future; they center on data that act as an early warning on emerging problems or declining performance.  When chosen well, a leading indicator can signal the need for a course correction before the problem gets out of control.  The tool we describe below is a great way to identify possible leading indicators.

The Measures Chain

The Measures Chain is used to develop metrics for a given process.  The concept is shown in Figure 1.  The essence of this tool is to identify and link external requirements to an internal process. The technique is to start with customer requirements and work backwards and downwards into more detail that would be used for each dimension of performance.

The starting point is outside the process, where the process output is received.  In Figure 1, the process is order fulfillment, the output is a product, an invoice, and order documentation, and the receivers are customers in a given market.   (However, this tool and its principles can be applied to processes that deliver outputs to internal “customers” too.)

Once we know what the customer of the process wants, we can identify where to place appropriate metrics inside the process to see if we are meeting the customer’s expectations.  We end up creating a “chain” of metrics (hence the name) related to some performance requirement, such as timeliness across the process.

To build a Measures Chain for a given process, we usually create a table like the one in Figure 2.  We already know the process inputs and outputs as well as the outputs of each subprocess.  We start by asking what the customer requirements or expectations are.  These become the highest set of metrics – what we call M-1-External.  In Figure 2, the M-1-E metrics for the product are in three dimensions (economics, timeliness, and quality) because the customer has requirements in those three categories. Specifically, the customer cares about percent of deliveries made on time and about price, so those are metrics we place in the table.  We also decide to track customer complaints and returns because those are direct forms of feedback from the customer about product quality.

We then ask if there are additional business requirements for this output.  Business requirements are those things a customer may not necessarily know or care about (our costs, our internal standards, our compliance requirements, etc.), but we want to measure this output against any of those requirements that might exist.  So in Figure 2 you can see business metrics (called M-1-Internal metrics) in the same dimensions of quality, economics, and timeliness, but price is now reclassified as profit, because the business wants to measure how profitable this product is, and timeliness is measured in process cycle time.

Then we go inside the process and place metrics on the outputs of the subprocesses (M-2 level) in the same dimensions of quality, timeliness, and economics.  We can go even lower in the process, down to the activity level, and place M-3 metrics if we think this will provide insight about performance.  For example, the output of the process for writing a book is a manuscript; one of the activities for producing the output is editing.  One M-2 metric is the cycle time to edit the manuscript, but we may want an M-3 metric on the hours spent editing is that is a particularly problematic part of the process.

Possible Pitfalls

The Measures Chain is a great tool for identifying and classifying possible metrics for a given process, but there are some misconceptions to avoid:

It might seem as though the goal is to identify as many metrics in the Measures Chain as possible, but that should not be your aim.  You don’t need a metric for every dimension on every subprocess output.  You will notice in the table in Figure 2 that there are blank cells.  The goal is to identify metrics that provide insight into performance – especially ones that are leading – that give us early warning about possible performance issues.  Nevertheless, it is tempting to fill in all the blanks on a Measures Chain Table.  We have found that the best way to go about this is to fill out the table twice.  The first time, just fill in all the cells with all the metrics that are logically implied.  The second time, go through and choose only those metrics that will provide the greatest insight.

As we said earlier, in creating the Measures Chain, you have not necessarily formulated the metrics in a way that you will want to collect and track data.  For example, how are we going to measure whether every order meets throughput standards?  Will we be able to count every one going through?  Can we date-stamp every order?  Does a computer log show throughput time?  All these are questions to be figured out once there is agreement that we need to track and understand certain kind of process performance, but we haven’t figured out when, where, and how the tracking and reporting will happen, and we don’t know yet who is responsible for keeping watch on the metrics.

In our next article, we will take on some of these questions, and provide some guidance and a tool for determining who should watch what performance data and what they should be looking for.  Till next time.

To View Figures 1 and 2, download PDF

Related Links

Related Links

This article is Part 2 of a 3-part series on the topic of metrics and measurement.  For other articles in the series: Part 1,  Part 3.

For more detailed information on the management system, consult our book Rediscovering Value.

For a 3-part series of articles on the topic of process ownership, click here: Part 1, Part 2, Part 3.

For an article on the role of management in performance support, click here.

For information on our workshop about Metrics and Process Management, click here.

For information on our consulting service where we assist organizations in designing a measurement and management system (or “Organization IQ”), click here.

For information on our consulting service where we assist organizations in designing a process measurement and management system, click here.

In this case, though, there was a bigger problem. The proposed title was something like, “How X Will Help You Succeed During this Recession”. “X” was the specific topic that I was being asked to talk about, but I could plug in my own material as the solution.

I would assume that just like me, you have been bombarded in the past 8 months or so with e-mails and pop-up ads, newsletters and white papers, all screaming with headlines like “The 12 Steps to Financial Recovery!” and “Here’s Your Own Personal Stimulus Package!” and “How to Survive and Thrive in a Down Economy!” Enough to gag a maggot, as my pals on the playground used to say. It seems to me this is just a form of ambulance-chasing. And you gotta wonder about the soundness of a solution that somebody has just, overnight, invented that could possibly save you when all around you are drowning. But then of course you realize that that none of these things being merchandised is likely to be new—they are just the already existing products—hastily relabeled—of people eager to cash in on disaster or so desperate they’ll say anything to get a sale. And you even wonder if some of these purveyors are the same shadowy folks who sold products and services that led to the home mortgage/financial market meltdown to begin with. Buy now, no money down, no credit no problem, we don’t care…

So the last thing I wanted is to be viewed as a hustler looking to make a fast buck off the miseries of the recession. But on the other hand, what we have to offer here at PDL is to me exactly what organizations should be doing—good times and bad—to better manage their organizations. It’s good, helpful stuff, regardless of the economy—to build lasting enterprises dedicated to creating value.

So the resolution, finally, was for me to go to this conference and open the session by just candidly telling the participants that had I been there a year earlier, I would have told them exactly the same thing I was about to tell them, and the approach I was about to describe, if followed, probably would help their organizations but it’s no short-term fix and there are no guarantees. And no, I was not smart enough to predict the meltdown and yes I had lost money too, so don’t take financial advice from me.

Then I showed them some of these ads I’ve been collecting, and we all gagged, in unison.

BPTrends – October 2009

Written By: Alan Ramias, Cherie Wilkins

In our last column, we described various approaches to process ownership that we have seen established, with varying degrees of success, in different companies. Our focus was primarily on the organizational position of the role (a senior executive, a staff, a line manager, and so on) and the amount of authority accorded the position (control of process design, process performance, or both, or neither).

This time we would like to describe what we have seen process owners actually doing in the performance of their roles. To some extent, of course, what they do is dictated by their position and authority, but not entirely, so we are presenting a different angle on the subject of process ownership. We will first describe how we have seen people carry out the role, and then offer some advice as to what we think they should be doing. We have organized these variations of the job somewhat by frequency – that is, we start with the tasks we have most often seen process owners doing and then go from there.

For the sake of simplicity, we are also restricting our descriptions of process ownership to a single owner of a single process. In reality, there could be multiple process owners in an organization who collectively view themselves as managing a network or architecture of processes, or we could have an owner who owns several related processes. All those possibilities are understood but left out of the following descriptions.

The Minister of Process Documentation

The most common preoccupation of process owners that we’ve seen in actual practice has been the creation and/or maintenance of process documentation. The purpose for having the documentation has usually been for certification – for ISO, CMMI, Baldrige, and so on. Sometimes, the documentation activity is a one-time event (we got certified and that’s it), but most of the time, verification or recertification is required, so the task becomes maintaining the documentation or refreshing it in order to survive the next audit. But, of course, depending on the resources available to do all this documenting and depending on their position in the organization vis. a vis. the “line” where the processes are actually performed, there can be an ever widening gap between the details of the process documentation and actual work practices.

The IT version of this role is creating and keeping documentation for systems. It is all about having a reusable set of documents that can speed the next project. Sometimes this is a way of avoiding going back to the SMEs actually performing the process, and, once again, the documentation may lose its authenticity. In addition, IT documentation of processes can be too focused on technology and user interfaces while missing other significant (but manual) parts of the process, so it is not always the best source of information for improvement efforts.

The Chief Watcher

Someone in this role collects and reports process performance to whomever is supposed to be managing the work. If there is a company “scoreboard” or “dashboard,” this is the person who is posting the scores and perhaps maintaining the website or another place where the scoreboard is kept.

This is an important role, and somebody certainly has to do it. If the role includes figuring out what performance data should be monitored and how to collect it, the work can be complex and challenging, requiring someone with sophisticated skills in measurement and systems design. If the person performing this role is also involved in management of performance, it can be a powerful position from which to influence the design and improvement of the process. But, if relegated to merely collecting and reporting, the role may be little more than clerical. If the person in this role is reporting to functional managers who have the real authority, it is easy for them to treat that person as the “process nag,” while they continue to manage as they always have.

Continuous Improvement Initiator

The focus here is on finding small areas of improvement and running projects to close the gaps. This is often the role that you see internal Black Belt specialists doing. On the plus side, improvement (like data collection) is a legitimate role that supports process management. If this person has real authority to authorize, fund, and manage the projects, it is potentially a very effective role. And having someone in charge of all those projects in some organized, centralized fashion is far better than the chaos you can see inside organizations where everybody and anybody can start up an improvement effort. On the minus side, it may have little to do with management, but can instead be more of an order-taking function.

Process Cop

A process owner in this role is the enforcer of process standards (perhaps also the creator of those standards). More and more, we have seen this role attempted when a company wants global standards – for example, in how customer relations are performed, or to meet some strict environmental or other regulatory requirements that are imbedded in particular processes. When this role is in IT, it is usually driven by the desire to have standardized systems – a single instance of the ERP system, for example, across a set of diverse regions or businesses. This can be a powerful role if given real authority to enforce compliance – and is absolutely suicidal if that authority is missing.

Process Engineering Manager

A person in this role conducts health scans of the process in question in order to identify improvements, does analysis of the current process when there is some reason to evaluate performance, and does redesigns of the process to meet new or future requirements (a changing market, or new technology, for example). The person is responsible for design of the process but not for the people who perform it. We described this configuration in our last column as “staffers being process owners.” While theoretically possible, we have seen it always leads to problems – such as arguments over who is really in charge of the process and the performers; the implementation of process changes (since they are coming from the staffers) are treated as optional – process redesigns that make sense at the corporate level but not in the field where the process is actually performed.

We have described these various roles and tasks of a process owner as if they existed separately, and in some organizations they do, while in others you can find them in various combinations. But our view is some, but not all of these activities, should all be part of the role, as we describe below…

What Should a Process Owner Be Doing?

First and foremost, a process owner should be performing management duties, not clerical duties. At the highest level, management includes the planning, managing, and supporting of performance. A process owner should be doing all those activities for a given process.

Planning includes setting annual performance goals for the process that are derived from organizational goals. The goals and support plans of the functional areas that participate in the process should cascade from those process goals. The process owner should be actively engaged with functional leaders to determine what kinds of resources are needed to enable and support the process and then to get commitments from the functions to provide those needed resources. This planning and resource allocation activity includes determining if the process is capable of meeting organizational goals, which means regularly assessing the condition of the process in question, and then initiating, sponsoring, and steering the improvement efforts that will make the process capable. But the role does not include doing the improvements – process ownership is not a role for the Black Belt specialist.

As for ongoing management, the process owner role should include regular reviews of process performance and capability, and re-planning or adjusting as necessary. This monitoring of process performance should be driven by both process and function metrics that help the process owner and functional managers understand where performance deviations are occurring and agree on what the corrective actions should be.

In short, a process owner should be performing process management – not clerical duties or improvement projects.

So what about the tasks we left out, such as documenting of processes and the mere collecting and reporting of process data (as opposed to managerial review and decision-making)? We said those are actually some of the most common activities of existing process owners, and somebody should be doing those activities.

In our view, the process owner should not be doing these tasks, but should be supported by someone else – what we call the performance architect – who does these things and other tasks while the process owner concentrates on the governance aspect of process management. We will describe the role of performance architect in our next column.

Related Links

This article is Part 2 of a 3-part series on process ownership.  For the other articles in the series: Part 1, Part 3.

For more detailed information on the management system, consult our book Rediscovering Value.

For a three part series of articles on the topic of metrics and measurement, click here Part 1, Part 2, Part 3.

For an article on the role of management in performance support, click here.

For information on our workshop about Metrics and Process Management, click here.

For information on our consulting service where we assist organizations in designing a measurement and management system (or “Organization IQ”), click here.

For information on our consulting service where we assist organizations in designing a process measurement and management system, click here.

BP Trends – August 2009

Written By: Alan Ramias, Cherie Wilkins

Process ownership (and with it, process management) has been at least attempted, and in some cases successfully established, in many organizations since the concept was first described in the book Improving Performance: How to Manage the White Space on the Organization Chart by Geary Rummler and Alan Brache back in 1990. They described it as a role entirely separate and distinct from that of functional line managers; its purpose is to “oversee the cross-functional performance of a process,” but “does not represent a second organizational structure.” From that rather simple description, a host of different designs for process management has evolved over the ensuing decades, and we come across many of them as we visit companies or have people attend our workshops and presentations.

Our purpose in this column is to describe and critique the varieties of process management we have been able to observe. We will do this in roughly the order we have come across them, as we believe that sequence is typical of the way process management concepts have evolved since the earliest attempts. We will describe both the positive attributes of these approaches and the difficulties that tend to arise once these versions of process management are put in place. And, finally, we will try to provide a set of principles that we think should guide any organization as it endeavors to establish process management.

Approach 1: Process Management as a Power Base

One of the earliest – and most powerful – versions of process management we witnessed took place in a high-tech company when the Chief of Staff, just one step away from the CEO, was asked to create and inhabit the position of Corporate Process Manager for the new product development process. In this role, he was given the authority to set and enforce standards for the design and management of the process in question in all of the company’s locations. To carry out the assignment, he mapped the generic process and then identified the amount of acceptable variation. He conducted scheduled evaluations and, when he spotted deviations, he could dictate the changes required to bring the local process practices into conformance. Ultimately, he could – and occasionally did – intervene in a given organization to make the changes himself when the response from the local management team was slower than he considered reasonable.

Advantages of this Approach

This was the most powerful enactment of process ownership we have ever seen. The process owner had the accountability for process performance but also the broad authority to enforce corporate standards. He was so successful that his role was duplicated for several other key processes – such as order fulfillment – that were practiced in multiple divisions of the company.

The process owner certainly benefited from having a relationship where he responded directly to the CEO, thus making the power of the role as significant as that of any line manager. This approach was also targeted to just a few processes – those essential to organization-wide success. And he was accountable for both the design and ongoing performance of the process – a combination of responsibilities that was both powerful and, as you will see, unusual.

The Disadvantages of this Approach

The man described above had had a long and distinguished career in the company, having led many of the business divisions that comprised the corporation, so he had great credibility from the outset. Some of his effectiveness was due as much to his personal reputation as to anything invested in the process owner role. And, in fact, none of the other corporate process owners were quite as effective as he.

The greater drawback, though, is that we never saw any other company adopt this approach to process ownership even though we described it often. For most organizations, it is probably unthinkable to place such a senior executive into such a role, which, of course, begs the question of how important they really think process management is.

Approach 2: A Peer among Peers

The next evolution of process ownership (and one still widely practiced today) was to identify the functional managers whose organizations participate in a given process and to choose one of them as the process owner, typically, the one whose people have the biggest role or greatest amount of participation in the process, or the one who “owns” the customer for that process. A common example is the head of the manufacturing department being named as the head of the process management team for the production process since so much of that process (although not necessarily all of it) is executed by employees of the manufacturing function.

Advantages of this Approach

The biggest plus of this approach is that someone is in charge who knows the process and has a solid reason for its success; the person chosen has, we often said, “the most skin in the game.” The other advantage is that someone is in charge. A group of peers who see themselves as jointly responsible for design and performance of a process are like any other team: They need a leader and a means of resolving questions and disputes.

The Disadvantages of this Approach

So much depends on the skill of the process owner in managing a team of peers. If someone who is skilled at negotiating and influencing is chosen, the team can function quite effectively. In the places where we have seen this form of ownership, the process owner has no real authority. The team may grant the individual a large amount of decision-making leadership, but stalemates are still common.

Even more common is that the selected process owner tends to go in one of two directions. Either the person will not really understood what the process owner role is and will do nothing, in which case the role dies a quiet death; or the person will try to exert real control over the process, irritating his or her peers and causing a revolt that kills off support for process ownership.

The other version we have seen of this approach is to establish a process management team, but, in an attempt to avoid the disputatious effects we described above, they don’t name anyone as head of the team. Not hard to predict the result of this: stalemate again, and the team fades away – invariably, in our experience.

Approach 3: Staffers as Process Owners

This is process ownership coming from a newly created staff organization, such as the “Global Process Office” or the “Process Excellence Group” or from an existing support function such as IT. The idea is that these people are generally held responsible for process design but not for performance. The line organization where the performers reside maintains responsibility for performance, including process and individual employee performance.

Advantages of this Approach

The idea here is that in this type of scenario the “process owners” are process experts. They know a lot about process design principles, they often have credentials in various design or improvement methodologies, and, thus, they should be able to apply an objective critique of their assigned process, with the goal of making the process as lean and competitive as possible. They are expected to review process performance with line managers and together, with them, analyze the causes of unacceptable performance. Where the causes have to do with ineffective process design, the process owner has to make changes; where the causes are because of people executing the process ineptly, the line managers have to make the appropriate adjustments.

So the expected advantage is a division of authority and responsibility based upon the notion that process ownership actually consists of two elements – design and performance – that are best managed by two different people.

Disadvantages of this Approach

This approach is widespread, but it always breaks down due to the same two issues: ambiguity and accountability. Despite the nice separations of roles described above, when process performance breaks down, the causes tend to be mixed, and it is quite difficult to sort them into process design versus process performance. So, in order to do the job, the process owner is constantly reviewing process data and showing up on the floor, questioning this or that until it is unclear who is in charge, that person or the line manger. Shouting ensues.

To avoid this contentious arrangement, the role of process owner in many places is reduced to that of an advisor who occasionally points out something that line managers might consider an improvement, or it becomes a data-gathering role in which the process owner is the main collector of process performance data, but it is the line managers who take action. The other role common here is for the process owner to conduct improvement projects but “ownership” is really a misnomer.

A variation on this approach is when process ownership is in a function such as IT, where the business analysts are dubbed the process owners. They are seen as responsible for the process and for the technology that supports it. This results in a weird schizophrenia for people in such roles because they are in charge of the very thing they are supposed to be supporting. But they are process owners in name only; they continue to act like BAs.

Bottom line is, it is very hard to make this approach work. Staffers can’t be managers in any true sense without getting into trouble with line managers about accountability of process performance.

Approach 4: Functionally Defined Processes

When we talk about process management, we mean those large, important cross-functional processes that create and deliver value to customers. The concept was not intended for those processes that exist inside departments or functions. However, the term has been adopted by many functions to describe their functionally defined processes whose boundaries begin and end inside the function. To accomplish this, they simply give the head of the function a new hat – that of process owner – while changing nothing else.

Advantages of this Approach

It’s easy enough. You can have a well-defined process, clean metrics, a reporting system, and all other attributes of a well-designed process. But it avoids the very rationale for having process management, which is to have a means for managing the white spaces between functional areas; it may be presented as an advantage, yet make no difference.

Disadvantages of this Approach

So what does it accomplish? It’s a different name for what is already in place, but it is not process management. At its worst, we have seen some organizations take this notion down below the functional level into subprocesses and tasks, and end up dubbing dozens, even hundreds, of people as process owners. Anyone with a task to do is now a process owner – which utterly devalues the entire notion.

Approach 5: The Governance Fad

Google the word “governance” and you will get tons of stuff these days. It is one of the most popular terms in business parlance today, but nobody can tell you what anyone else means by it. What its popularity suggests, though, is that people everywhere are feeling the lack of appropriate oversight and management of various things (the financial meltdown of 2008 being the ghastliest example), and it is hoped that “governance” will be a way to put things straight again.

In the process world, this term has been grabbed and applied to what is most often a team of senior executives, or their chosen proxies, whose mission is to oversee process performance on a large scale, across a corporation, or across all the regions of a business. Sometimes they are responsible for one big process, sometimes a set of related processes, sometimes all processes. They are called “global governance councils” or something along those lines.

Advantages of this Approach

This mechanism does tend to reengage executives in process management, where they have long been absent. Being a “governance council” has a ring to it sufficient to draw them into the role. And this larger scope of process ownership often makes great sense. Trying to manage single processes, even if they are big complicated ones, may not be nearly as important as managing the complex “process architecture” of a business.

Disadvantages of this Approach

One of the big problems plaguing process ownership and management through all of the variations herein cited are that they can be “bolt-on” additions to the existing management system instead of being integrated into it. This is bound to lead to conflicts and ambiguities. Even when established by a senior executive council, the governance approach can run into the same problem of who is really in charge. A typical issue that we’ve witnessed is when a dispute arises because the regions (or whatever entities make up the council) refuse to follow similar process rules or designs, so you end up with seven different versions of the process and with no synergy or learning between them.

Some Principles of Process Ownership

By now it may look as though process ownership is an impossible concept, but we don’t think that is necessarily the case. Any of the variations cited above could work if they address the following principles (and they are quite likely to fail if these principles are ignored):

• Process management has to be part of the real management system. It cannot be separate from the real decision-making about resources and work, or it becomes a short-lived “shadow” governance: It will always die out, because people resist it, ignore it, or fail to value it.
• There must be crystal-clear expectations for the role of process owner and any process management teams. The approach of “I dub thee Process Owner – Go forth and do good work!” has never succeeded. The result is many confused process owners who either don’t take the concept seriously or who try and fail.
• There have to be teeth in the accountabilities of the role, which includes real positive and negative consequences for carrying out the role effectively or not. Someone in upper management has to care that this role exists and monitor its performance.
• The role of process owner has to be connected to the power system and career advancement opportunities of the organization. If this doesn’t happen, the role becomes a Dilbert cartoon, in which no sane person wants the job.
• Finally, the role has to be aimed at the management of the real, important, cross-functional processes of the organization. The role has to matter, or else why do it?

The final thought is that if all these principles were closely followed, it would beg the question of why have process owners at all? That is, if process ownership is entirely integrated into an organization’s existing management system, the members of the management teams in place would view themselves as already wearing two hats: one for their assigned areas of responsibility and the other for their cross-functional (or cross-regional, or cross-divisional) role of managing the business processes collaboratively with the other members of the team. In such an event – voila’! – process management is now, simply, management. And that is as it should be.

Related Links

This article is Part 1 of a 3-part series on process ownership.  For the other articles in the series: Part 2, Part 3.

For more detailed information on the management system, consult our book Rediscovering Value.

For a three part series of articles on the topic of metrics and measurement, click here Part 1, Part 2, Part 3.

For an article on the role of management in performance support, click here.

For information on our workshop about Metrics and Process Management, click here.

For information on our consulting service where we assist organizations in designing a measurement and management system (or “Organization IQ”), click here.

For information on our consulting service where we assist organizations in designing a process measurement and management system, click here.

BPTrends – April 2009

Written By: Alan Ramias, Cherie Wilkins

There are two types of performers that do the work of organizations – people and technology. They can perform work independent of each other, but often perform the work together as a human-technology team. Both are performing the work of the organization’s business processes. In order to effectively diagnose performance, design and implement change, and manage process performance, we need to understand and engineer the performance of individuals and technology systems.

Each of these performers exists in a performance system: a system of variables that influences how well the performer executes the work. Let us first understand these systems, the Human Performance System and the Technology Performance System. Later we will explore the usefulness of these models to those of us concerned with improving and sustaining process performance.

Related Links

For information on our Serious Performance Consulting workshop, which enables participants to diagnose and analyze performance problem (including those at the performer level), click here.

Download PDF

Download PDF

Alan Ramias
February 2008
Gartner BPM Conference
Las Vegas, NV

Alan Ramias
April 2007
Shared Insights
Miami, FL

December 15, 2006

Written By: Alan Ramias

Look at any book on business process management or improvement these days and you’ll see a good amount of advice being expended on the creating, chartering, nurturing and managing of process design, or improvement, teams. Typically, these are made up of employees who perform the processes being improved along with a gaggle of supporters, technical experts, and the like. In organizations where process management is a goal, a similar phenomenon takes place, typically with teams of mid- level managers nominated as “process owners” accompanied by a host of process excellence specialists and various other coaches or hangers-on. Look inside a corporation that has gotten into process work with technology as the driver and you are likely again to find a huge complex infrastructure of improvement teams, steering committees, regional oversight committees of site coordinating teams, centers of excellence, and on and on. The complexities of these team infrastructures tend to mirror the organization’s structure, with tiers of interlocking teams for every level that exists in the company.

Is this a good thing? Usually, not very. The teams frequently tend to either ignore each other or bicker over tools and methods and get territorial, and then they burn out after documenting the processes like maniacs for a time but never quite getting to any real improvement or management.

So where on earth did the idea come from that creating a bureaucracy was the way to do BPM? Sad to say, from us. That is to say, it came from the various consultants and advocates who over the past 15 years have advised companies on the worth and mechanics of process improvement and management. My colleagues at the Performance Design Lab (PDL) and my former colleagues at the Rummler-Brache Group all recommended these steering team/design team infrastructures, and so did all of our competitors. So now it’s a given. But once upon a time, there once were no such givens.

Alan Ramias
September 11, 2006
ISPI The Results Focused Organization: Pathways to Excellence Fall Symposium
Lake Buena Vista, FL

Alan Ramias
September 11, 2006
ISPI The Results Focused Organization: Pathways to Excellence Fall Symposium
Lake Buena Vista, FL

BPM Strategies – August 2006

Written By: Alan Ramias

In her book, Electronic Performance Support Systems, Gloria Gery popularized the notion of designing technology to assist workers in performing tasks, writing about the growing use, and importance, of electronic job aids such as on-line tutorials, directories, help menus, technical support and the like, for users of laptop and desktop computers. Now often called Performance Support Tools ( PST), electronic performance support sys- tems (EPSS) include includes PDA’s, laptops, UPC scanners, and a host of other technologies. EPSS/PST is a useful concept and has grown to be a significant consideration for anyone who designs or improves processes and work environments.

Unfortunately the EPSS/PST movement has put all the emphasis on electronic devices as the means of performance support. For many, “performance support” connotes technology and nothing else. Yet there is potentially much more to the concept. This article is intended to retrieve the idea of performance sup- port, strengthen and expand on its definition, and explain why it ought to be regarded as a critical element in achieving and maintaining high organizational performance.

Related Links

To read an article with more information on the Human Performance System, click here.

For information about our Metrics and Process Management workshop, which provides extensive details on the specifics of “Performance Planned” as mentioned in this article, click here.

For information about our Serious Performance Consulting workshop, which helps develop the skillset required to understand and work with the variables that influence performance, as discussed in this article, click here.

BPM Institute.org – August 1, 2006

Written By: Alan Ramias

Inside organizations that are doing various kinds of process “work”-whether improvement projects, technology enhancements or process definition and documentation—we often hear a lot of confusion and frustration because people sometimes mean different things when they use the word “process.” The most common frustration happens when two people are talking at different “levels” of process—with one person perhaps talking about a big end-to-end process such as order fulfillment while the other person is talking about a single task but one with multiple steps and considerable complexity—yet both are using the term “process”. The problem gets even worse when whole segments of an organization adopt one interpretation of “process” versus the general understanding within the organization, and well-intentioned initiatives are frequently undermined when tools are applied at an inappropriate level. For example, we have frequently seen six sigma practitioners at odds with others where management expects large-scale improvement of the important value-creation processes such as product development, or selling and marketing, yet the six sigma folks are focused on detailed measurement and improvement of sub-processes at a micro level.

At The Performance Design Lab, our approach to resolving this confusion is to offer people a Processing System Hierarchy and help them to sort out what they mean by process and to have them identify which levels are relevant to their use of the term.

Figure 1 is a Hierarchy consisting of six levels. (Note: Download PDF to view graphics) At the top is the entire organization as a system, with all of the processes and functional areas depicted in the context of its  marketplace, its resources and competitors, and the general environment in which the  organization must operate. Most of the time, people are not referring to this topmost level when they talk about processes, but what this model suggests is that every organization is in fact a giant processing system, and all of its individual processes are contained somewhere in this system, and sometimes improvement is required at this level, when an organization has to overhaul its entire way of doing business.

Level 2 is a depiction of the organization’s value chain, which is the means by which the organization creates, sells and delivers products and services of value to the marketplace. The value-chain level is kind of a mega-process view, and in a large, complex company there may be multiple value chains for different products and services. Sometimes people who talk about process do mean the entire value chain, and quite often improvement is needed at this level, when parts of the value chain are misaligned or missing.
Level 3 then divides the components of the value chain into three general types of processes, what we call the Available, Sold and Delivered processes.  Available includes those processes–such as research, product development, and product extensions—whose purpose is to create new products and services. Sold includes those processes that are aimed at marketing and selling the goods and services. And Delivered includes those many processes that get the products and services to customers and provide on-going support. At this level, we are still talking about multiple sets, or bundles, of processes.

It’s at Level 4 that we reach the individual process level, and it will be one of those processes contained inside Available, Sold or Delivered. Often this is the level of process that people mean when they talk about “end-to-end” processes, because these processes typically begin with a market or customer input (an order, a product idea) and
end with an output that either goes to the customer or becomes an input to another stage of the value chain. For example, the output of the product development process in Available is a new product that now can be marketed and sold by those employees who participate in the Sold processes. The other processes to be found at this level are
management processes and enabling processes (for example, the hiring process or the technology development process).
One important point: Even if we are invited into an organization that has already focused on Level 4 processes, we always advise them to go back up to define andunderstand at least Level 3 and maybe higher. Our approach is macro to micro, making sure we understand the context of performance at a broad level before diving deeper.

Level 5 then decomposes a given process into sub-processes and tasks. It’s at this level that the performer (whether human or technology or a combination) becomes visible. And Level 6 goes into even greater detail, delving into sub-steps and procedures. Sometimes people who use the word “process” are actually talking about Level 5 or
even 6, because from their vantage point, what they do is a whole process, although from the Process Hierarchy view, they are well down in the weeds within a single sub-process or even a single task.

It is important to get agreement of what level of process is appropriate for various kinds of process improvement or definition work before launching the effort. For example, if an organization decides it wants to document its current processes (let’s say in order to meet Sarbanes-Oxley compliance requirements), at what level should the documentation take place? Should it be at Level 4, which would mean mapping the big processes of the organization at a fairly high level, or should it be at Level 5, which would mean dozens of sub-process maps and hundreds of steps and tasks, or does it have to be at Level 6, the procedural level, in order to meet the compliance standards? What hinges on the decision is the amount of effort that will be required- a Level 4 documentation effort may take weeks, while a Level 5 effort could take many months and many resources- and what level of detail is sufficient to meet the objective.

In guiding organizations while they make decisions like this, we try to first help everyone understand and adopt the same mental model of processes, which the Process Hierarchy helps us to achieve. Then we try to guide them in making a good decision about which level we should be working at for a given effort, and it is not always at the
most excruciating level possible.

Related Links

For more information on the Processing System Hierarchy (which we later renamed the Value Creation Hierarchy), consult our book for practitioners, White Space Revisited.

For workshops on the Rummler Process Methodology, our complete, proven methodology for designing or improving the Value Creation System (Levels 2-4 in this model), click here.

We also offer several other, simpler workshops for those looking to learn about modeling or improving processes.  These workshops are the Process Modeling and Documentation Workshop, and the Process Modeling and Improvement Workshop.

The Value Creation Hierarchy is a fundamental model that underlies our approach to consulting – almost all of our consulting services listed on the Consulting Services page will make use of the Value Creation Hierarchy in some way.  For organizations who are interested specifically in articulating, designing, or improving their Value Creation Hierarchies, the following Consulting Services may be of specific interest:

• Business Process Architecture Definition
• Value Chain/Value Stream Analysis and Design/Redesign
• Rummler Process Methodology

BPTrends – October 2005

Written By: Alan Ramias

“If I try to thank all the people claiming credit for this movie, I wouldn’t know where to begin.” – Bill Murray, accepting a Golden Globe award for his role in the movie Lost in Translation

Everyone interested in business processes seems to know that Six Sigma was invented at Motorola and that Motorola became the first winner of the Malcolm Baldrige Quality Award in 1988. The origin of Six Sigma has been the subject of countless articles, a series of Harvard Business School cases, and many books. What happened 20 years ago might not matter much anymore except that many practitioners continue to refer to the Motorola experience for inspiration and practical models. Meanwhile, as someone who was present at the dawn of Six Sigma and a participant in the early design of Motorola’s approach to process improvement, I am often amused, and sometimes appalled, at the descriptions I’ve read in various publications.

So this is a recitation of some of the myths versus the realities, from my personal point of view. I was hired by Motorola in 1981 as a member of the Motorola Training and Education Center (MTEC), the start-up corporate training department that evolved into Motorola University. One of my assignments at MTEC was to work with consultant Geary Rummler and others to develop what became Motorola’s first process improvement methodology. And after being transferred to the Semiconductor Products factory organizations in the Phoenix area, I sold and participated in the first large-scale process improvement initiatives that gave Motorola its reputation in the field of process. So I had a unique vantage point, both as observer and participant. On the other hand, I didn’t see everything that happened, or know all the participants, so this article has a decidedly narrow view (my own) and a modest purpose (what I think really happened).

Myth #1: Six Sigma was invented by… me! No, me! Me, me, me!

“Motorola is where Six Sigma began. A highly skilled, confident, and trained engineer who knew statistics, Mikel Harry, began to study the variations in the various processes within Motorola.” – Six Sigma for Everyone, by George Eckes.

“Like many companies at the time, Motorola didn’t have one “quality” program, it had several. But in 1987, a new approach came out of Motorola’s Communications Sector – at the time headed by George Fisher, later top exec at Kodak. This innovative improvement concept was called “Six Sigma” – The – Six Sigma Way, by Peter Pande, et al.

“Alan Larson, one of the early internal Six Sigma consultants who later helped spread the concept to GE and AlliedSignal.” – The Six Sigma Way by Peter Pande, et al.

“Six Sigma per se didn’t exist twenty years ago. Miraculously, a single individual working for a large corporation in a cubicle at a nondescript office building saw something…the late Bill Smith, a reliability engineer at Motorola in Arizona…” – Six Sigma for Dummies, by Craig Gygi, et.al.

Jeez, what are the facts? Well, the biggest fact is that lots of people participated in the invention of Six Sigma over a long period of time, so there is plenty of credit to go around.

If you disregard the Charles Dickens quality of the quote about Bill Smith, it turns out to be the closest to the truth (except he didn’t reside in Arizona, Mikel Harry did). Bill Smith did write and circulate a technical paper on the definition of Six Sigma in the mid-80s, and it did influence the thinking of many people to move away from a narrow focus on defects to the concept of process capability. But did he single-handedly invent Six Sigma? Don’t think so. Truth is, the efforts to improve quality through use of statistics went back to the early 1980s, and the creation of Six Sigma as a program was essentially a repackaging of tools and methods going all the way back to Deming.

And the rest? Call it the triumph of the visible:

Mikel Harry was initially a consultant, then an engineer at the Government Electronics Group in Arizona who got involved in capability studies, then became an instructor for Motorola’s quality training programs and did so well that he migrated to Motorola University, became head of the Six Sigma Academy, and spoke to thousands of benchmarking teams about Motorola’s accomplishments. Naturally enough, some people assume that he was not only a passionate advocate of Six Sigma, but also its inventor.

George Fisher was an up and coming executive who strongly supported quality improvement. And he became Motorola’s CEO for a time. But did Six Sigma originate in his operation? That’s where Bill Smith worked, so you can see how the assumptions might arise. But the concepts and tools that went into the Six Sigma program came from many different places within Motorola.

And Alan Larson? Never heard of him. But he probably never heard of me either. That’s the point. So many contributors – to claim that any one person was the inventor is to fall prey to the “great man” fallacy that a major idea has to come from one person. If there is any truth to the theory, there would be several great men: Deming, Juran, and Geary Rummler, who provided the intellectual capital for Six Sigma.

Myth #2: Motorola won the Baldrige award because of its Six Sigma program

The Six Sigma methodology was formalized in the mid-80s at Motorola. The result was a staggering increase in the levels of quality for several Motorola products, and the inaugural Malcolm Baldrige Quality Award was bestowed on the company in 1988.” – Six Sigma for Dummies

“Only two years after launching Six Sigma, Motorola was honored with the Malcolm Baldrige National Quality Award.” – The Six Sigma Way.

Don’t you think it odd that a company can be so successful with a new program that it earns a national award for its achievements in just two years? Yeah, exactly. Motorola won the Baldrige Award not because of its formal Six Sigma program that kicked off in 1987 but because it had made truly awesome improvements in both quality and cycle time over the preceding 8 years. Those achievements were a result of all the TQM and BPI efforts going on, and they weren’t viewed as a single comprehensive program called “Six Sigma” or anything else…except in hindsight.

The Six Sigma goal was announced in 1987, and the methodology was packaged and rolled out in 1987-88. As a formal program, Six Sigma was barely in place when the Baldrige Award was obtained.

Six Sigma was a repackaging of tools and techniques already in place, and the program was rolled out because Motorola had essentially stalled in its improvement efforts. The company suffered a severe downturn in 1985-86 when Japanese manufacturers invaded the memories chip market and wiped out Motorola’s memories division. The company went into shock, and it was not until mid-1987 that things stabilized and attention began to be paid to improvement. But by that point cycle time was more the focus.

Quality fell off the radar, partly because a lot of people were plain tired of the quasi-religious atmosphere that accompanied TQM and partly because managers began to recognize that some of the quality problems were due to wait times, inventory mismanagement, and other issues related to long cycle times. The other driver for Six Sigma was the influence of its customers. One of Motorola’s biggest customers was Ford Motor Co., which began to require Six Sigma quality and on-time performance. Its insistent demands were a huge impetus for the revival of improvement efforts.

Myth #3: Six Sigma was Motorola’s approach to process improvement

In the early 1980s, Motorola’s approach to quality was a quality circles program called participative management (or PMP). MTEC was created to produce training products to support that effort, at first primarily for factory production workers, and later for technicians and engineers. Those training programs were the origins of much of today’s Six Sigma methodology. But none of it was considered “process improvement.” The focus was on product defects; the word “process” referred only to the manufacturing process, and later to the product design process. Business processes were not what anyone meant by “process.”

Meanwhile, MTEC brought in consultant Geary Rummler to help design a performance-based approach to the development of instructional programs. While working with the manager of the manufacturing curriculum, Paul Heidenreich, Geary conducted a broad study of manufacturing operations, using a variety of analytical tools that included process analysis. Paul recognized the potential value of these tools and sponsored the development of a training program that evolved into an approach to process improvement, called OPS. This program was the origin of what became the well-known Rummler-Brache process improvement and management methodology. It was applied in many Motorola organizations, usually to the issue of cycle time improvement, and achieved phenomenal results that were included in the 1988 Baldrige submission. OPS was aimed at business processes and management teams, while the quality programs were aimed at product design and manufacturing employees, which may be why for a time nobody put two and two together and saw that these efforts were – or should be – linked.

It was not until 1988, when process capability became of interest, and Rummler’s approach to process improvement had become well known throughout Motorola, that the quality and process sides became joined. That year, MTEC (by then renamed Motorola University) issued its first Six Sigma training program that contained techniques from previous quality programs and Rummler’s methodology.

According to Mark Schleicher, who also worked at Motorola University and developed that first Six Sigma training program, the Six Sigma initiative “made the quality message clear and consistent. It was not DMAIC at that time but a focus on variation and defects that link back to the customer via the product. The original emphasis was really Design for Six Sigma, linking the customer to both the product design and the manufacturing processes.”

What does any of this history matter now? Here are a few lessons to consider:

• Organizational transformations don’t happen quickly. Motorola’s journey from duck to swan took the better part of 10 years, propelled by a series of business crises and a lot of fumbling around.
• Most of the ideas came from outside. Motorola deserves the credit for recognizing the importance of concepts in quality, process, and performance, and for opening its doors to new ideas, but virtually all the tools and how-to knowledge came from a large cadre of outsiders. Juran, Deming, Dorian Shainin, Richard Schonberger, and Rummler were the true sources of Motorola’s approach. And the drumbeat of customer demand, from Ford and others, was also a source for both ideas and inspiration.
• There was no grand plan. Only in hindsight can a path be dimly seen. CEO Bob Galvin issued a challenge to the company in the early 1980s (10X improvement in 5 years) and then a second set in 1987 (100X improvement in 4 years), and the organizational response both times was a lot of head scratching and scoffing. The man-on-the-street response to the call for Six Sigma in 1987 was simultaneously, “It can’t be done” and “We’ve already done that,” depending on your interpretation of what Galvin was asking for.

Yet much was accomplished. In addition to huge improvements in product quality and cycle time, Motorola succeeded in creating a strong organizational culture. By the late 1980s, no matter where you were in the company, no matter who you talked to, every last employee was keenly aware of the importance of meeting customer requirements and of producing world-class products quickly and flawlessly. Indeed, it is still an inspirational story.

Related Links

For information on our “Strategic Lean/Six Sigma” consulting service, where we help bring traditional six sigma and lean process improvement approaches into alignment with strategy, click here.