Gartner BPM Summit, Lisbon, 2011

Guest Keynote

The differences in definition of “process” range widely within the BPM community and among our clients.  These differences have a huge impact on our work and our effectiveness.  We will offer proven criteria for good process definition and models for clarifying and communicating the scope of processes we’ve found to be effective.

Download PDF

BPTrends, January 2012

Authors: Alan Ramias, Cherie Wilkins

In the previous three installments of this series, we presented three examples of PCO journeys that started in the “core of the business” and were sponsored and driven by line business executives. In this last installment we want to share with you our experience with one client who drove the journey from the IT department.

Let’s look first at how they got to this point. This particular client was a global building products company with operations in about 40 countries. The industry has been consolidating over several years and so their growth had been achieved by a series of successful acquisitions around the world. As the companies they acquired got larger and larger, the integration of those operations took longer and was more expensive and complex. But the economics of their acquisition strategy would only be achieved through cost savings from implementing best practices and leveraging global processes and systems.

The CIO recognized that it was a combination of process and systems that were needed to deliver the results and so he took on the process mantle -in fact, renaming his position as CPIO (Chief Process and Information Officer).

This made sense. There are a growing number of companies that have placed their process center of excellence in IT. Virtually all processes in today’s organizations require data and technology to support them. In fact, for many process steps, technology systems are the performers. Human performers and technology performers are two sides of the same coin – they execute the process, either separately or together.  (Incidentally, some readers might define the confluence of people, process and technology as a “capability”.  For purposes of this discussion we will use “process” to represent all three since it is the window through which their interrelationships are most clearly seen and understood, but we believe the point is relevant regardless of preference in terminology. This move to view technology and process together also makes sense for many process practitioners, in that most of the effort and cost of process change usually falls to IT.)

The Organization Design

So having taken on the mantel of process, it was time for the CPIO to put in place the supporting infrastructure. This is the point at which we were asked to help.  The original request was to develop a standard for process documentation. The company rightly recognized that it needed the language of process to be consistent across the organization. We advised them they also needed a business process architecture (BPA) to establish a common definition of process, a single methodology for making process and IT changes, and a portfolio management system to manage all of the change. These were the four components that were put in place.

They also organized four design groups inside IT roughly based on domains of Operations, Supply Chain, Commercial, and Back Office. These design teams acted as global process owners for the enterprise. They were supported by a group of IT account reps attached to the business that represented the regions and countries. The design groups were accountable for the process design and global process performance. The region and country managers were accountable for process performance in their geography.

The Intake Process

All requests for IT or process change came into the design teams where the portfolio was managed. The design teams used the BPA as the screen and organizer for the portfolio. As you might imagine, most requests arrive in IT as a request for a particular solution (“Build me a database for this.”). The design teams worked with the account reps to reframe the request as a business issue (“I need to solve x or I need to be capable of y”). They then were able to locate which process or which type of work was associated with that issue. They were better able to see patterns in the requests as well as keep track of all other process change related to that same process in this way.

In one particular case, the Operations Design Team was screening the global set of requests and identified more than 30 different solution requests all aimed at the exact same process issue. So instead of 30 initiatives, they had one. They could also look at their total IT expenditures against the BPA and make a judgment as to how aligned to strategy the investments were. As you see in the example below they were surprised to see how much they were investing in contributing processes rather than value creation processes.

Pitfalls of this Approach

We integrated our process improvement methodology with their system development methodology so they were sure to address the process – both sides of the coin (human and technology)—equally and simultaneously. A potential pitfall of placing process in IT is for designers to always opt for a technology solution to process issues when in fact there is often a human solution or combination that may serve the business need, urgency and budget better.

So what are the other potential downsides of this model? We have already mentioned the legacy of making requests for solutions as opposed to coming with a business issue. In addition, when process ownership rests with a support function outside of the core business, connectedness can be problematic.

On the one hand, IT can function as a “neutral party” that can arbitrate all of the varying regional requests and choose those things that are best from an enterprise perspective. On the other hand, because IT does not have a stake in the business, IT may be biased toward technology optimization or merely cutting costs versus value creating solutions. And even if IT can temper its tendencies toward technology solutions, they are often regarded with suspicion as being biased toward their own interests.

There is also a risk that IT may not be as connected to business strategy as IT needs to be to make tradeoffs in cost and internal objectives versus quality and impact on customers. In our example, the design team members had all come from the business, but as time went on, they could have lost their close connection to the business. This has always been the dilemma with the business analyst role in IT. In many organizations, BA’s have been moved back and forth from business to IT in an attempt to find the appropriate balance of business knowledge and IT knowledge. The connection is important because it’s critical for IT to be both solution-neutral and yet informed enough to understand the nature and impact of the business problem or opportunity.
The story would be similar for any organization that is driving the PCO effort from any one of their support functions – HR, Finance, etc. Many of the pitfalls would hold true for those organizations as well. Given the choice, we think that a business-driven effort has a better chance of achieving and sustaining success. The challenge for our client will be getting the business to remain engaged with them on their process journey.
 

 Conclusion

So now we have reviewed four different approaches an organization could take in becoming process-centered, and have tried to outline both the advantages and the shortcoming of each approach. The first approach was the ideal one, in which the top leadership team transformed its entire business by designing, installing, managing and maintaining its value creation system of core processes and contributing functions and processes.  The advantages were great; the downside is finding an organization with the leaders to have the vision and patience to make something this comprehensive actually happen.

The second approach was the slow but steady change by an organization that knew where it wanted to go but had to overcome obstacles one by one.  The advantages include a leadership team and workforce that gradually understand and thoroughly buy into the vision over time, but with the risk of derailments over the long term.

The third approach was the classic example of a company driven by extreme external threats to invent itself.  The business payoffs can be enormous, as they were at Motorola which was our example, but sustaining the changes can end up being problematic.

And the final example we’ve outlined in this Column is the transformation driven by a support organization—an approach becoming more and more common but difficult to achieve because of credibility issues.

We hope you have found these four journeys helpful as you plot your own organization’s PCO
path.  And keep in touch—maybe there is yet another way to go.

Welcome to the information and registration page for the 2012 Performance Design Network Colleague Conference.  This page will feature the latest updated information on the conference – check back frequently for updates.

INFORMATION

The conference has been scheduled for March 28th – 30th, 2012 in Berlin, Germany.  For an overview of the conference, please click here.

The latest agenda for the conference can be viewed by clicking here. Please note that this agenda is subject to change.

The first day of the conference will feature an optional, but recommended workshop, entitled “Metrics and Process Management.”  To view a flyer for this workshop, please click here.  The fee for this workshop is €380 (normally €580).  Please note that the conference on March 29th-30th is free, this fee applies only if you wish to attend the workshop on March 28th.

The conference will take place at the Hotel Pestana in Berlin, Germany.  More information about the hotel can be found by clicking here.  If you have a smartphone, the following QR code will also connect you to the Hotel Pestana:

REGISTRATION

In addition, here is a video of Geary Rummler presenting at MTEC in 1981.

And one final video from 2008, with Geary speaking for the HPT Practitioner Podcast.

Many thanks to Guy Wallace for the videos!

This post is password protected. To view it please enter your password below:

Password:

BPTrends, September 2011

Authors: Alan Ramias, Cherie Wilkins

In our last Column we discussed process-centered organizations (PCO) that take a slow, gradual  route, describing the risks of such an evolutionary approach and its long-term potential benefits.   This time we will focus on organizations that become process-centered because they are in deep trouble.

Organizations in crisis are sometimes ideal for introducing a transformative change at the scale that a PCO requires.  When the need for change is real, when many if not all of the company’s key leaders recognize the crisis, when the pathway to restoration can be seen…good things can happen rapidly.  Unfortunately, even when a company is suffering a crisis, all the variables are not necessarily lined up in favor of rapid change.  We will explore what critical elements need to be in place in order for a stricken organization to move ahead to recovery, and describe two different organizations that have gone down the PCO path because of an initial crisis.  The first example is from the distant past but still offers some valuable lessons; the second example is from today’s headlines.

The Classic Case

Motorola in the 1980’s is still the classic example of a company that transformed itself because of a crisis.  (Never mind its current travails—it still stands as one of the best examples of an organization that became process-centered on a grand scale and was the inspiration for countless other companies.)  Poor product quality and Japanese competition in the late 1970’s were the twin drivers for change, causing CEO Bob Galvin to announce the goal of ten-fold quality improvement, spurring a decade-long effort to improve that completely reconfigured the company, earned it the first Malcolm Baldrige Award and made it an American icon.  We have written before about how the change was accomplished at Motorola (Ramias, 2005), so here we will merely summarize its major stages:

1. Initial efforts were focused in manufacturing, where quality circles were created and training in what we today would call lean techniques were employed.  Improvements were achieved but were scattered and way down at the task level, not addressing end-to-end processes.  To provide the training, Galvin authorized the establishment of a corporate training organization, which became the famed Motorola University.

2. In the second stage, engineers were trained in Statistical Process Control tools and techniques and began to apply them to whole processes, initially confined to manufacturing but then gradually spreading to product design, supply chain and other areas.  At the same time, Geary Rummler entered the scene and co-developed a process improvement methodology that did address end-to-end business processes.  With these developments, large gains in quality, cost reduction, cycle time and reputation began to take place, largely inside the product divisions where manufacturing and engineering resided.

3. In the third stage, the improvement efforts became widespread in Motorola, with virtually every department having some training in improvement techniques and formal goals and programs.  The umbrella label of “Six Sigma” was invented to encompass all of the efforts, and Motorola went public, hosting endless benchmarking visits by other companies.

In the first stage, recognition of the crisis was paramount.  CEO Galvin saw it but not all of his executives did, and the result was a swift trimming of naysayers.  Galvin had the courage the top leader must possess, and it is the variable that matters most in stage one.

The other necessary variable is having in place the means to make the change.  Galvin did this by bringing in Bill Wiggenhorn to create the corporate training organization.  Motorola University became Galvin’s change agent.  He provided funding and political cover as MU spread the quality gospel throughout the company.  All of the major tools and ideas came from outsiders like Rummler, Joseph Juran and Dorian Shainin, and they were brought in via MU curriculum. Training does not necessarily have to be the change agent, but something is usually needed to give a company both the push towards change and the tools, ideas and mechanics.  Companies in crisis often get there because they lack critical skills or ideas, so improvement from inside is not going to happen.

In other cases, the chief limiting factors are the panic and hesitation triggered by the crisis itself—people may have the potential to change their circumstances but they are paralyzed by fear and self-doubts.

Once the improvement efforts began in the product divisions, the driving factor came from the division heads.  Not all of them, of course, at first had the foresight or  courage, but there were a few capable of operating like Galvin on a smaller scale—pushing for change, describing a different future, supplying the means, and providing political safety.  They led the change and others lagged but eventually imitated the leaders.

There is a key lesson in how this happened:  it is wise not to try to make the change everywhere at once, but instead to concentrate on a few places where the need is clear, the leadership is ready, and the results can demonstrate the value of the effort required.  Motorola didn’t think this through, of course—it just kind of happened, but the lesson is clear.

The Current Case

Our second example is a bank that has suffered through the catastrophic economic downturn of 2008 and its aftermath, and is now attempting to right itself by becoming process-centered.  For reasons that will be obvious, we cannot name this institution but will describe its PCO journey to date.

Like its many brethren in the financial industry in middle of the last decade, this bank overextended itself, in particular making commercial loans that went bad when the economy tanked in 2008-9. The situation was so dire that after conducting a review, the FDIC almost closed the bank’s doors.  Instead it was given a brief period to recover, some new leaders were brought in, and we were invited to conduct a review of processes and operations.

Ironically, because of this bank’s location and clientele, one of its more promising areas of business was mortgage lending.  So we then conducted a classic process improvement project, using the well-known Rummler Process Methodology.  This effort was deliberately formulated to be “a tip of the spear”—that is, instead of attempting to transform the whole bank, we concentrated on one of the few areas where there was some promise of measurable results if the improvement happened.  And just as important, the goal was not just to address the mortgage lending process but to raise employee esprit de corps by engaging them in something they could change, by demonstrating how to work across functional boundaries, by producing a design that could, if implemented, have a positive impact on both the workplace and on the customer.

The implementation of this design is now underway, and, as expected, it has revealed the need for a comprehensive makeover of all lines of business, all key processes, all jobs and functions and the governing management system.  The effort on this systematic transformation is currently happening.  Once it has been put in place, it will be a model for the other banks in the larger constellation of banks owned by the parent company to undergo their own transformations.

So another organization in crisis, triggering an improvement effort with the longer-term outcome of being a PCO.  The success variables are much the same as at Motorola:  a clear need for change, in this case coming from outside (i.e., the regulators and the parent company); a set of key leaders in this case deciding that a transformation is required and providing the necessary means; assistance from outside to both understand the problem and propose solutions; a careful
effort to demonstrate the value of this way of designing and running an organization before trying it widely.  A crisis can  be a great trigger for change, but it doesn’t automatically happen—other variables must be in place or the opportunity can be squandered and the organization could join the long list of companies that have gone under because of inertia.

Lessons Learned

So what can these two cases, separated by decades, teach us about successfully implementing BPM and becoming a process-centered organization?

Both cases demonstrate that a crisis can indeed be a golden opportunity to make changes that otherwise an organization may be too complacent to undertake.  Both scenarios required a burning-platform issue, a strong leader willing to assume a “benevolent dictatorship” managerial style for at least a while, both required assistance from outsiders, and both needed a methodology for change.

But there are differences between the two cases. At Motorola, the entire effort took nearly ten years; despite there being a major driving force for change, Motorola’s progress was not actually that different from the slow companies we described in our last Column after all.  In large part, that is because much of what was attempted was experimental.  Galvin did not tell his subordinates how to change the company; his approach was to “let a hundred flowers bloom”.
Some ideas really did create great improvements while others failed or worked only for a time.  A case in point was the use of quality circles, which at Motorola was called the participative management program (PMP).  Its centerpiece was an incentive system that gave everyone a bonus when businesses made a profit. Much propaganda was used to try to link the PMP program to the improvements that the quality circles made, but there was little valid linkage. Some divisions did well and got bonuses without doing any improvements; others were pioneers in reinventing themselves but results were slow in being realized. This all came to an end when the company became unprofitable for a time during the mid-1980’s; and as the bonuses went away, so too did the interest in improvement.  In fact, the “six sigma” program was in part a rather desperate attempt at reviving the mentality for improvement because PMP had effectively died.

At the bank, the timeframe for change is already much briefer, and will be even when the improvement methodology is spread to other banks in the system.  The methodology being deployed had its origins at Motorola but has been vastly expanded and refined over the decades, so it is no longer experimental.

The leadership at the bank has a better sense of how to create and manage organization change.  Its “tip of the spear” tactic is quite deliberate, as opposed to the accidentally learn-while-doing approach that happened at Motorola.  And the leaders recognize that every element of the organization has to be altered to create a fully functioning, integrated high-performance system.

So, after thirty-some years of learning about how to harness BPM to an existential crisis, some variables remain the same: strong, courageous leadership; assistance from outside for many, if not all, companies; a methodology and means to create and support the required changes; and a demonstration of value before attempting a broad scale of change. Those are the variable that can turn a crisis into a transformation.

The new lessons are that BPM can indeed be the means for effecting broad organizational transformation, and now, with enough organizations having undergone the journey, the pathway can be planned at least in its broad stages.

In our final Column of this series on PCO’s, we will explore the unique challenges and benefits of a PCO effort driven by a support function—our example being an IT department in the driver’s seat.

BPTrends, May 2011

Authors: Alan Ramias, Cherie Wilkins

In our last article we described the characteristics of a process-centered organization (PCO) and gave an example of one company that reached the destination in a relatively short period of time.  But that kind of rocket-propelled journey is not the norm. In this and the next two installments of this series we will share with you the more common approaches we have seen.

The example in this article is an organization that illustrates what may seem like the tortoise version of the race to becoming a PCO – slow and steady. We will assess the effectiveness and pitfalls of this approach.

The Starting Line

The journey for this company began seven years ago. The driver was a major customer who was demanding improved performance—higher quality and more predictable cycle times. That customer wanted the company to stabilize its “service delivery” processes and put in a quality control system. In parallel, key members of the management team recognized the importance of process. Because of this, there was a decision to take a process approach to addressing this critical business issue (CBI).

The First Leg of the Race

The company started its journey by establishing a Process Center of Excellence.  The cadre of approximately 20 specialists was largely composed of Six Sigma-oriented process consultants who came from the various businesses augmented by few external hires.  Once in place, the consultants guided management in choosing and defining a business process architecture.  The architecture framework they chose was one of the most widely known in the BPM field, but they did make some adaptations to suit their company’s particular situation.

The company then assigned process owners to each process in the architecture and moved forward with the intent to create management teams, establish metrics, and document processes, all conforming to a standard process maturity model. A process consultant was assigned to help each process owner.

Although the goal was to address all of the processes on the framework, the reality was that the bulk of the effort and attention centered on the delivery processes and on addressing the CBI.

What was Achieved

The company did achieve real results in addressing the CBI.  In fact the results were so compelling that the CEO openly endorsed the goal of becoming a process managed company. He wanted this to be his legacy.

The process architecture was institutionalized, and to this day is the best example we have seen of full adoption.  Just about everyone in the org recognizes the architecture and can name from memory the top-level processes.

There was also some initial success in establishing process management. The Process Owner Council meets regularly to review process metrics.

With the endorsement of the CEO, the company began to slowly and steadily spread their success to the other parts of the organization. This slow and steady approach is a choice many organizations have made.

The Next Lap

CBI ‘s don’t last forever. The CBI was leveraged to drive the first part of the journey and it worked.  What was desired next was steady progress on the rest of the journey. But because the CBI had been addressed—all of the service delivery issues had been eliminated and the processes were yielding steady, predictable results—the urgency went out of the effort. The company settled into very slow progress and all of that driven by push from the Center of Excellence process experts, not pull from the business.

Eventually—five years into the journey—they hit a plateau. As process owners disengaged, there was lots of turnover on the Process Owner Council. The process owners were tired of metrics reviews and were asking to shorten the council meetings. It was tough for the Center of Excellence to continually push.

It was time to up the ante. What they had forgotten was how the CBI had fueled the early efforts. It is not enough to sustain the gains. Success in one area did not inspire effort in other areas as they thought it would. They need to find a new driving force.

Toward the Finish Line – What They are Doing Now to Address their Midlife Crisis

The company recognizes the need to tie back to real business issues to fuel the rest of the journey.  They are making a connection to strategy.  The Center of Excellence specialists have begun working with the strategy organization to use process management and improvement as a way to close gaps between current and future capabilities. In a pilot, they correlated long range business plans to processes, highlighting where the strategy calls for changes in process capability or capacity. These gaps will then have to be addressed in the company’s business plans.

Key managers, aided by Center of Excellence advisors—are actively looking for CBI’s in the other process areas and are gathering real data – including customer feedback -  to drive the desire to address those CBI’s.

The company has also made an adjustment to part of the process architecture – a bold move, given the level of institutionalization. They recognized that some of the complacency about the processes upstream from Service Delivery was due to the overly generic definition of those processes. Remember that they began with a best practice framework that they adopted from outside and then tweaked.  The upstream part of the framework did not really represent their business model – how they now do business. The process performers and managers didn’t resonate with that definition of their work. So they are now redefining that part of the process architecture and have a new framework that better reflects the business. They are hopeful that this will facilitate a higher level of process engagement in these upstream areas.

So the company now has all the right pieces in place and is making some smart moves to keep the journey on track. We are hopeful that, as in the fable, slow and steady wins the race.

Lessons for All of Us

In the beginning this company did not really make a conscious decision to go slow.  In fact it started on the PCO journey the way most companies do—by harnessing its self-education to an urgent business problem.  But after the initial surge in effort—the staffing up of resources, the training, the redesign effort, the establishment of a process management system—it didn’t know where or how to go next.  And that happens to many companies that burst into the BPM arena with great ambitions and enthusiasm but little in the way of long-term plans. And so without necessarily meaning to, the company found itself on the slow road to PCO nirvana. What can we learn from their experience?

One lesson is that this often happens.  A company could plan to go fast but only knows how to begin, not how to continue or how to end.  Asking questions about the destination at the outset might do everyone a lot of good.

Another lesson is the dangers of establishing an internal team of experts.  While staffing up a Process Center of Excellence is a common practice and is usually needed to guide a large organization to becoming a PCO, all too often the accountability for getting there ends up in the laps of the process specialists instead of staying where it belongs, with the business leaders.

The biggest challenge of a go-slow approach is, of course, sustainability. An organizational transformation taking years to achieve will take considerable effort to keep it alive, and it may not be revivable at some point if it is perceived as having “failed”.

And perhaps there is a bit of confusion about journeys versus destinations. Perhaps there is no destination.  If a company institutionalizes process management and links it meaningfully to the business, it has the means to adapt its internal processes and other capabilities as the external world changes.  But that means things are always changing.  So an effective PCO is not a stable, comfortable, predictable organization:  it is wide open to possibilities and able to pounce on them quickly, keenly aware of its vulnerabilities and quick to adjust whenever threatened.

A hideous little cliché making the rounds these days is “It’s a journey but not a destination.”  Some truth in that.

In our next article we will look at the journey undertaken by a company in real crisis – do or die….

Related Links

This article is part two of a multi-part series on the process-centered organization.  For Part 1, click here.

For an article on the pitfalls on the path to becoming a process-managed organization, click here.

For a presentation on the topic of the process-centered organization, click here.

For information on our consulting service to help organizations along the path to becoming a PMO, click here.

March 2011

Gartner BPM Summit, Guest Keynote

London, UK

For an enterprise to be successful it must excel in three dimensions of performance: value, resources and management. BPM can and should play a prominent role in all three dimensions, but that has not been the case in most organizations taking the BPM journey. We’ll tell you the implications for your BPM program, including change management, and give you examples of the successes and failures we’ve seen in leveraging BPM for transformation at an enterprise level.

Download PDF

To register for the conference, please visit:

Colleague Conference Registration Page

The conference will start daily at 8 AM and run till 5 PM. The exception to this rule is Friday, October 7th, which will be a half-day running from 8 AM to 12 PM, to accommodate participants flying home. We will provide a light breakfast starting at 7:30, as well as lunch and snacks.  In addition, there will be a hosted cocktail hour on the evening of October 4th, which is open to all conference participants, regardless of whether you attended the optional workshop that day or not.

The Agenda for the conference can be viewed by clicking here: Download PDF.

The conference will be held at the Hilton Phoenix Airport. A flyer for the hotel can be found by clicking here: Download PDF.  The contact information for this hotel is:

Hilton Phoenix Airport
2435 South 47th Street
Phoenix, AZ 85034
Phone: 480-894-1600
Website

For transportation between the airport and the hotel, the hotel offers a 24-hour complimentary shuttle service.  The hotel is within minutes of the airport and can be there for pickup within minutes.  This shuttle can be accessed by calling 1-480-894-1600.  There is not currently a courtesy phone in the airport terminals by which to contact the Hilton.

For those driving, you will find directions below to the Hilton from various areas around the Valley.

From the Northwest…

Take I-17 South to I-10 East.  Exit onto 143 North (also known as the Hohokam Expressway).  Take the first exit, which is University Drive, and turn left onto University.  Make your first right, which is 47^th Place.  The Hilton is the third hotel down on the left hand side.

From the North…

Take 51 South to the 202 East (also known as the Red Mountain Freeway).  Take the 143 South exit (Hohokam Freeway).  Follow the 143 South past the Airport, and exit on University drive.  Bear right onto University Drive, and make your first right, which is 47^th Place.  The Hilton is the third hotel down on the left hand side.

From the Northeast…

Take the Pima Freeway South (101 South) to the 202 West (the Red Mountain Freeway).  Take the 143 South exit (Hohokam Freeway).  Follow the 143 South past the Airport, and exit on University drive.  Bear right onto University Drive, and make your first right, which is 47^th Place.  The Hilton is the third hotel down on the left hand side.

From the South…

Take I-10 West, and exit onto 143 North (also known as the Hohokam Expressway).  Take the first exit, which is University Drive, and turn left onto University.  Make your first right, which is 47^th Place.  The Hilton is the third hotel down on the left hand side.

From the West…

Take I-10 East, and exit onto 143 North (also known as the Hohokam Expressway).  Take the first exit, which is University Drive, and turn left onto University.  Make your first right, which is 47^th Place.  The Hilton is the third hotel down on the left hand side.

From the East…

Take the Superstition Freeway (US 60) West to I-10 East.  Exit onto 143 North (also known as the Hohokam Expressway).  Take the first exit, which is University Drive, and turn left onto University.  Make your first right, which is 47^th Place.  The Hilton is the third hotel down on the left hand side.

From the Airport…

Take the 143 South Expressway out of the airport and exit University Drive.  Make a left onto University, and then another left onto 47^th Street (there is a traffic light there).  The Hilton is the third hotel down on the right hand side.

BPTrends – February 2011

Authors: Alan Ramias, Cherie Wilkins

The concept of a “process-centered organization” originated with Michael Hammer in his 1996 book, Beyond Reengineering. “To become a PCO” still seems to be the most popular description of the destination that organizations claim to be trying to reach when they embark on BPM.  Because the PCO concept still resonates with so many organizations and practitioners, our column for 2011 will be devoted to that subject.  We will offer you a four-part series on the subject of a PCO, with different examples on the topic:

• In this article we describe the characteristics of a PCO and give you a real-life example of a company that successfully reached the goal.
• In Part 2 we will give you examples of the “tortoise” approach – that is, the slow, incremental path that we have seen a number of organizations take.
• In Part 3 we will give you examples of the “hare” approach – how an organization confronts a crisis by using BPM to achieve organizational change quickly.
• In Part 4 we will give a “from-left-field” example of a company that took an approach to BPM that was significantly different from the typical path.

Characteristics of a PCO

Here are the characteristics (or components) we believe have to be in place in order for an organization to be “process-centered.”  This is, of course, our own list, derived from our experiences with organizations that have asked for our help in going down the BPM path. There may be other characteristics you would add, but we think this is the minimum list of required components.

1. A well-articulated business process architecture

An organization can’t manage what it can’t see.  That is, an organization cannot manage its processes – much less be “process-centered” – if it doesn’t understand its own processes.  That means it must have a set of clear pictures of its core processes – those processes that enable it to create, sell, and deliver valued products and services as well as the key processes that enable and support the core processes.  Thought leaders and consultants in the BPM business have various names for these pictures – an “architecture” being the most common label.  Some would boil it down to a single high-level diagram, and others would argue that it must also include a collection of depictions of the most important processes.  Our preference is the latter, because such a collection of pictures provides a comprehensive view of what we call the organization’s “value dimension.”  But whatever you elect to call it, a prerequisite to becoming process-centered is a clear, complete, logical, and accurate view of how a given organization does its vital work.

2. The business process architecture is institutionalized.

The first requirement, above, may not be that much of a differentiator, as quite a few companies have defined their process architecture.  And some have gone totally overboard, endlessly mapping all the processes of the organization (a trap that numerous “process excellence” groups have slipped into) with little clear purpose.

But it’s a much greater achievement to have institutionalized the architecture – that is, when it is being used as a key tool for understanding the business, making decisions, and managing the daily work.  The process documents are not just sitting in some archive, rarely referenced except perhaps for an audit and generally accessible only by those who created the maps.

Further, the architecture is meaningful to employees:  The notion of process has spread throughout the organization, and any employee can tell you about the work they do in “process” terms.  They know where they fit in the architecture, and they understand the connection of their daily contributions to the business.

3. The management system is process-centered.

It is certainly well known that if an organization is to be process-centered, it must have process management. But the attempts to put process management in place have been problematic in most organizations we’ve seen.  Often a single manager (or a group of managers) is simply designated as process owner, with little clarity about what the role entails. In other cases, process management is a disconnected set of management roles, policies, metrics, and practices that are disconnected from the existing, actual management system.

What is required is for process management to be entirely integrated into the existing management system – integrated from enterprise level down through all levels of process in the organization’s process architecture, down to functions, jobs, and tasks.  In an organization with this process-centric management system, management first turns to the value-creating process view to do long and short-term planning, to identify new capability requirements, to assess the fit of new opportunities, and to make decisions about acquisitions, outsourcing, and other strategic actions.  The process view is applied to all the key activities of managers, including planning, budgeting, resource allocation, monitoring, troubleshooting, and performance management.  Planning and management activities form a closed-loop system linking strategy and objectives to daily work.

4. Capabilities to transform and evolve are in place

A major reason for an organization to become process-centered is to increase its agility.  When new threats or opportunities arise, traditional organizations tend to respond slowly, painfully, or not at all, because it is so difficult to change internal structures and behaviors.  By contrast, the process-centered organization is much better positioned to capitalize on the changing external environment because it understands its internal mechanics, and so it can pinpoint where changes have to be made and can do so quickly.  And, through conducting process improvement projects, process-centered organizations have developed a capability for change.  The tools and knowledge are in place to do continuous improvement or radical redesign.

Some organizations that want to be process-centered never do process improvement.  They aim for process management or spend much of their time in process documentation.  But they are missing much of the reason why processes became prominent in business to begin with.  The process view is an effective, efficient way to make the necessary improvements to an organization’s work systems that make the organization lean, competitive, and adaptive.

Yes, It’s Possible

What we have described may sound like some kind of business nirvana, and you may be asking yourself if any organization has ever even gotten close. The answer is yes. As proof, we offer one client’s 18-month journey and also tell you the circumstances that made this rocket-propelled journey possible.

The journey began with the CEO of a wealth management bank. He read Improving Performance and got excited by the concepts, especially by the section on management. He contacted us with the following plea, “Come make us into that type of organization.” Over the next several months, we worked with his company to put into place the components and practices that we described earlier.

We began with the analysis and redesign of their Client Services Sales and Delivery processes. Our design team consisted of all of their executive team, augmented by a few other subject matter experts. In essence, we redesigned 80% of their value creation processes (those that deliver value to customers). But, in addition to achieving the improvement gains, we also gained deep understanding of the power of the process view of an organization. We tore down most of the organizational silos in one fell swoop. The other thing that these executives experienced in a very real way was the connection between process and strategy. They were making their decisions on the design of the new process, based not just on resolving current issues, but on what the processes need to be capable of, in order to achieve their strategy. After this part of the project, it became pull instead of push. The managers wanted to map and get insight to all of the other processes, including all of the enabling processes like the Technology and Human Resources enablers. Several other improvement projects were launched.

At the same time we were defining and redesigning processes, we got to work defining and redesigning the management system (aka the management processes). For each of the processes we developed a set of process metrics that measured process performance across the functional boundaries. We linked those metrics to enterprise metrics through a performance logic tree. Process owners and process management teams were assigned. Then we were able to redesign the planning and review processes, including meetings to accommodate process plans, both operational and improvement, being developed and used as the drivers for functional plans. This sequence of planning was piloted during the next annual planning round.

Although this work was led by us as consultants, all along the way we were also building the organization’s own internal capabilities in process modeling, improvement, and management system design. In the course of this transformation, virtually everyone in the organization was involved in some way – as a member of a design team or an implementation team, as a process owner, or as a manager participating in the new planning activities.  Everyone in the organization was exposed to some training on the process approach to improvement and management. Every manager used the new management system. In short, it was a profound and successful transformation to a PCO.

However, there was an extraordinary set of circumstances that came into play here to make this journey possible. First and foremost, the CEO was an extraordinary leader. He had a vision and never wavered from it in the years that we worked with him. He made it the priority and understood that achieving the PCO end goal was the way to achieve his strategy. He was also very engaged. He was directly involved in many of the design sessions.

Second, this was a small organization – fewer than 200 employees – so we could get it all done in 1.5 years. They still had all the same processes as a big organization, just fewer resources and less complexity.

End of story? Well, they were a very successful organization. Their PCO journey allowed them to continue their growth and success. They were subsequently bought by a larger wealth management bank that was then acquired by an investment firm that was larger yet. These larger players imposed their systems and procedures on the small company wherever they could. The parts of the operation that we had worked with were sustained as much as they could be for as long as they could. To this day they still have some of it in place.

Related Links

This article is Part 1 of a multi-part series on the process-centered organization.  For part 2, click here.

For an article on the pitfalls on the path to becoming a process-managed organization, click here.

For a presentation on the topic of the process-centered organization, click here.

For information on our consulting service to help organizations along the path to becoming a PMO, click here.

Presented by the Austin chapter of ISPI (The International Society for Performance Improvement), in Austin, TX.

April 1, 2011, 8:30 am to 4:30 pm

Click here for flyer with registration information.

Guest Keynote: Repositioning BPM for Sustainable Success

Monday, 07 March 2011
10:45-11:30

For an enterprise to be successful it must excel in three dimensions of performance: value, resources and management. BPM can and should play a prominent role in all three dimensions, but that has not been the case in most organizations taking the BPM journey. We’ll tell you the implications for your BPM program, including change management, and give you examples of the successes and failures we’ve seen in leveraging BPM for transformation at an enterprise level.

From Process Analysis to Process Design: A Proven Approach

Monday, 07 March 2011
16:45-17:45

There are a wealth of tools and techniques for process analysis and process design but there are few that assist in making the transition from analysis to design. This session will demonstrate a proven approach for making the transition from analysis to design and avoiding common process improvement pitfalls:

• Lack of agreement on where and how the process is “broken” and the significance
• Fixing only what’s broken (and missing other improvement opportunities)
• Not knowing the availability, impact and limitations of potential breakthrough ideas

Turning Client Preconceptions into Performance Gold

Tuesday, 08 March 2011
08:00-09:00

So often, clients come with a predetermined solution. It may be new technology, process improvement, or organizational change, but it’s hard to say ‘no’ when a decision has been made for you. This workshop provides a time-tested model for:

• Reframing the request into performance terms
• Scoping the affected dimensions: value, resources, management
• Helping clients see their solution in terms of likelihood of success

• The evolution of organization complexity and the impact on performance
• The importance of and approaches to making the creation of value visible and understandable
• The benefits of ensuring balance between your resource and value dimensions
• An agenda for moving to the 3-D Enterprise

For those who want application and practice using the PDL tool kit, please see the workshop page for Creating the 3-D Enterprise: The Workshop

Seminar Length:

2 and 4 hour versions available

Who Should Attend:

Executives, Managers at all levels, BPM Practitioners, Business Analysts, Performance Consultants

The first half-day of this workshop presents the content of our introduction seminar. The workshop then goes on to explore the acts of process management, and provides practice in applying PDL’s proven tools and principles to your unique business situation. Workshop topics include:

• Introduction Seminar 
  • The evolution of organization complexity and the impact on performance
  • The importance of and approaches to making the creation of value visible and understandable
  • The benefits of ensuring balance between your resource and value dimensions
• The Acts of Process Management 
  • Definition
  • Design/Improvement
  • Management
  • Performance Support
• An agenda for moving to the 3-D Enterprise

Workshop Length:

1 and 2 day versions available

Who Should Attend:

Managers at all levels, BPM Practitioners, Business Analysts, Performance Consultants

• The History of the BPM movement, including the current state of the field and lessons learned
• The evolution of organization complexity and the impact on performance
• The importance of and approaches to making the creation of value visible and understandable
• The benefits of ensuring balance between your resource and value dimensions
• The Acts of Process Management
  • Definition
  • Design/Improvement
  • Management
  • Performance Support
• An agenda for moving to the 3-D Enterprise

Workshop Length:

1.5 day and 2 day version available

Who Should Attend:

BPM Practitioners and Managers

BP Trends – December 2010

Authors: Alan Ramias, Cherie Wilkins

This is the third and final Column in our series on process performance measurement. In the first Column we described some of the complications we have encountered in helping organizations install effective process performance measurement systems and then offered some principles for accomplishing this important work successfully. In the second Column we provided a tool – the measures chain – for identifying appropriate process metrics linked to both customer and business requirements.

But once you have the metrics identified, what do you do with them? Who uses these metrics to monitor performance? How often is data collected and reviewed? Who makes decisions about corrective actions, and who takes those actions? Metrics not being used to guide and improve performance are worse than useless -they can get in the way of understanding the performance taking place, they can clutter the landscape with irrelevant data; they can create the appearance of control where it doesn’t exist. It may be hard to believe but we’ve seen a good number of organizations in just this situation – where they have created a “chaos of metrics” but have not put it into use for a variety of reasons. So this final article in our series is about the most important step in creating process metrics…and that is figuring out the “who, when, why, and how.”

A Management Model

Our approach to determining who’s watching performance and taking corrective action is based on the management model shown in Figure 1. This model separates the major activities of performance management into “Performance Planned” and “Performance Managed.” (“Performance Executed” is shown in Figure 1 but is actually the actions of performers inside the organization who are doing work and achieving results.) ln “Performance Planned,” the organization’s leaders are setting goals, establishing budgets and action plans, gathering and assigning resources, and setting the plans into motion. In “Performance Managed,” the leaders are monitoring performance as it takes place, identifying deviations in actual performance versus the established goals, determining what corrective actions are required, and taking those actions to get performance back on track. Metrics are, of course, the key component in use during performance monitoring and variation identification and analysis.

This is a simple enough model in concept, yet it’s applicable to even the most complex of organizations in determining who is responsible for performance at any level. Our use of the model for creating process metrics is to figure out who should be responsible for that particular set of performance indicators.

The Management Domain Matrix

To put the management model into use, we apply a tool called the management domain matrix.  Shown in Figure 2, it shows management responsibilities for planning and managing performance. (lt could be called a “role/responsibility chart,” but that term is used commonly for job responsibilities, and our chart is going to contain something a bit different- not just single job responsibilities but collective responsibilities of management teams.) In this particular case, we will demonstrate the application of the domain matrix to a process measurement and management system. We will use it to determine the role (if any) for each level of management regarding a given process. A completed example of this application is shown in Figure 4. But the tool is scalable up to an entire enterprise management system.

Using the measures chain described in our last article (Figure 3), process metrics have been identified for an order fulfillment process. Some metrics are for the entire process (e.g., total cycle time, percent shipped on time), and others are applicable to specific steps inside the process (e.g., number of order entry errors). Now comes the question of who should be responsible for these metrics? What is the logic for assignments of responsibility?

The management domain matrix is organized by level of management. For the sake of illustration, let’s have four layers of management, each of which is a “domain” on the chart. There is Business Management (or management of the entire line of business), Region Management, Process Management (or management of this given process), and Function Management (which consists of the managers of all the functional departments that participate in this process).

To fill out the management domain matrix, we take each domain and fill out the cells by answering these questions:

1. Mission/Value Add: What is the value of managing at this level in regards to this particular process? What can this level of management do that the others can’t? For example, the executive team may be the only level that can look at global process performance. The Region Managers can only look at regional process performance. And an individual plant manager can only look at the process performance in his/her plant.
2. Planning: What planning are they responsible for regarding this process? Which goals should they set? What resources do they specify or approve?
3. Performance Monitored: Which of the measures should management at this level be monitoring? What indicators of performance do they need to fulfill the mission? It is useful to also add the frequency of monitoring (weekly, quarterly etc.) What would be leading indicators to predict performance?
4. Looking for…: What deviations are they watching for? Are they looking for trends? What variables are they tracking?
5. Corrective Actions: What corrective actions should they take based on what they are looking for? Should they initiate a resource change? A process improvement?

In our experience, this tool has been extremely helpful in clearing up much of the reigning confusion about process management:

• To start with, it aligns performance planning with ongoing management. Goals are set and resources are allocated in Performance Planned, but as things happen unexpectedly during the performance period, rational adjustments in expectations, resources, or actions can be made, and it is clear who should be making the decisions.
• Identifying responsibilities for planning, measuring, and taking corrective action by management level has been very helpful in getting away from some of the very disruptive management practices that we have seen, with managers from all levels jumping in to put out fires and with nobody practicing fire prevention.
• This tool also helps managers distinguish between managing process performance and managing individual performance. Process management has failed in some companies because there seemed to be little difference between it and what had always gone on, which was generic performance management of individuals. But process management is a different entity, involving the collaborative achievement of people in teams across departments, regions, and whole businesses. The domain matrix makes this kind of responsibility concrete, because a domain may need to be managed by a team whose members are being held jointly accountable for process performance.

With the use of the measures chain and the management domain matrix, we have been able to overcome many of the pitfalls of process management systems that we described in the first article of this series. These two essential tools help create a balanced and logical set of metrics that enable managers at all levels to get insight in critical performance and take action to keep on track. It is process management in the proper context of organization management.

To view figures 1 and 2, download PDF

Related Links

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

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.

Rummler/Ramias/Wilkins

available early February, 2011

When Improving Performance was published in 1990, it was acclaimed as the book that launched the process improvement revolution -establishing a practical foundation for process improvement and management. In Rediscovering Value, Geary Rummler, Alan Ramias, and Cherie Wilkins establish a foundation for identifying and managing the oft obscured value in organizations. The predominant focus in  most organizations is on resources –the resource dimension. What often suffers or is virtually invisible is the complex system of work that delivers value to customers and thereby shareholders. The key to sustainable success is keeping these two dimension in balance – being able make effective tradeoffs between efficient use of resources and sufficient delivery of value.

Most managers equate the management of resources to effective management – believing value will result by default. It turns out that keeping the resource and value dimensions in balance and making the associated tradeoffs requires more than a subtle enhancement to the role of management in organizations – it requires a  fundamental rethink of the act of management. Thus management itself becomes the third dimension of a sustainably successful enterprise – the 3-D enterprise.

Rediscovering Value presents the executive agenda for making the transition from a typical unbalanced approach to managing organization performance to a true 3-D Enterprise. Readers will appreciate the wealth of practical advice and useful tools found in this book. In addition, the concepts and approach in this book are further supported by a companion book for performance improvement practitioners, White Space Revisited: Creating Value through Process.

The imbalance in the dimensions of organization performance as illuminated in Rediscovering Value, is at the core of many of the “hot button” issues for executive and managers today including failed strategy execution; costly white space between functions, processes, continents, and partner companies; and the inability to improve top line performance. Organizations who can rediscover their value have an effective weapon with which to fight back.

This post is password protected. To view it please enter your password below:

Password:

This post is password protected. To view it please enter your password below:

Password:

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.

The library of a government research lab

Critical Business Issue

The research lab and library had suffered from years of funding cuts, but the area of research had recently received renewed mandate to advance the field. The research lab recognized that leading researchers would require strong library services to access past research and monitor the field, and the lab considered investing in major upgrade to the library to support their new mandate. However, after decades of making due with less, library personnel had difficulty conceiving of the services, processes, and facilities required to support a “library of the future.”

Critical Process Issues

Varied by process, some were more time sensitive than others, but the primary driver was value:  the library services had to meet real needs with the right level of service and at a reasonable and competitive cost.

Approach

• A team of Library Representatives analyzed its current super-system and identified the lab’s value creation processes, then identified the points in value creation at which customers/users could benefit from library services.
• The Library Team then defined the services of the “Library of the Future”:
  • Reviewed and challenged the value of existing services
  • Brainstormed new services and service extensions, including the possibility of teaming with internal and external service partners;  in some cases these were already existing services  but had to be translated so that the customers could understand the value (for example “Bibliographic and Citation Verification” to “Publishing Assistance”)
  • Defined or redefined all services using customer-oriented terms
• The Library Team then developed draft profiles for each service, including service description, value proposition, delivery assumptions and options, customer requirements, key performance indicators, funding assumptions, and facilities requirements.
• Focus groups were conducted with different cross-sections of customers, users, and other stakeholders to get feedback on the value of each service, alternative services, and service requirements.
• The service profiles were adjusted based on the feedback, and the baseline list of Library of the Future services established.
• With this input, the Library of the Future Business Process Framework (BPF) was developed. They developed a framework that could deliver all of the services and still leverage the fewest number of unique processes. (The library’s Value Creation Processes would rightfully be depicted as a Contributing processing system on the research lab’s Value Creation Architecture.)
• The Library Team successfully presented the vision, services, and supporting facilities to lab management and the architects supporting the transformation of the lab.

Key Points About This Case

• In most cases, a support function’s value creation processes would appear as contributing processes on the greater organization’s Business Process Framework. The support function’s Value Creation Architecture would also include management and contributing processes. The management processes identified were consciously aligned with the greater organization’s management process (for example, planning and budgeting sequencing aligned). The contributing processes were a combination of unique-to-the-library contributions and greater organization contributions from other support functions (for example, human capital inputs from Human Resources).
• The work was cast as “process improvement,” and that was clearly the desired end point. However, processes cannot be designed in a vacuum, so the focus became “what” value was to be provided by the library (the processes would define “how” the value would be delivered).
• Using a services-based approach to reviewing support functions was an effective way of understanding the value contribution of a support function. However, it was critical that these contributions be linked in a tangible way to the greater organization’s Business Process Framework to establish credibility and establish the value of each service to the greater organization.
• Development of the support function’s Business Process Framework started with the “Products/Services Delivered” portion of the Value Creation processes, since these processes link directly to the service profiles (the services being delivered). At this point, a key element of organization strategy comes into play by asking two questions: “What are the unique service delivery characteristics that we need to be careful not to lose or compromise” and “What are the desired and required synergies between the service delivery processes.” In this case, the eleven Library of the Future services were organized into four service delivery sets and processes.
• After defining the “Delivered” portion of the Business Process Framework, the focus shifted upstream to the processes for creating awareness and getting commitments to utilize the services (“Sold”), and the processes for refreshing, adapting, creating, and launching services (“Launched”). In each portion of the Business Process Framework unique process characteristics and process synergies were identified, and the resulting process strategy was different in “Sold” than it was in “Delivered,” and different again in “Launched.”

Related Links

For information on our consulting service for redesign of multiple related process, click here.

For information on our consulting service for definition of an organization’s business process architecture, click here.

Financial services company/Human Resources Recruiting Department

Critical Business Issue

Insufficient qualified new talent, affecting bottom-line results

Critical Process Issue

Line department managers considered the “is” recruiting process inefficient, bureaucratic and overcontrolled by HR

Approach

• Project cosponsors from HR and line organizations established a Steering Team and Project Team.
• While project target was the Recruiting Process, scope included downstream processes that were affected by slow recruiting (that is, department on-boarding, training).
• Standard RPM Analysis Phase was conducted.
• Analysis revealed that some key disconnects (slowness in finding qualified technical candidates) was caused by poor or nonexistent relationships with local and state sources such as universities as well as failure of line managers to get their recruiting needs into the recruiting pipeline in on time.
• Project Team conducted fact-finding visits with selected universities to explore options for campus recruiting (for example, fairs, job postings, and so on).
• “Should” design incorporated several possible new sources and techniques for finding candidates.
• Project Team recommended piloting of campus fair concept as well as tightening up of recruiting process to minimize wait times between interviews.
• Steering Team reviewed and endorsed the “Should” design and authorized the pilot.

Related Links

For information on our consulting service for process improvement/redesign, click here.

Global cement, aggregates, concrete, and other building products company

Critical Business Issue

A key component of the organization’s strategy was growth through acquisition. The speed and quality of assimilation was insufficient and greatly affected the ROI of each acquisition.

Critical Process Issues

The assimilation efforts suffered endless and expensive stabilization phases because of the narrow focus on the IT systems integration without understanding and addressing the work processes. The organization leadership had made a decision to take a process approach to this work but lacked a common framework for making critical decisions regarding the scope and phases of ERP (Enterprise Resource Planning) and process practices migration.

Approach

• Existing process lists, business line definitions, and process domain views that already existed were gathered and synthesized into a single draft Business Process Framework (BPF).
• A group of Processes & IT representatives with significant business understanding were assembled to validate and adjust the Business Process Framework (BPF) in a series of sessions.
• Teams of Processes & IT staff were assigned to create profiles of each Value Creation, Management System, and Contributing System process identified in the BPF. The profiles included:
  • Process mission statement
  • Process scope (inputs, outputs, and sub-processes)
  • Key performance indicators
  • Operating functions involved in executing the process
  • Related ERP and other IT systems and applications that supported the process globally
  • Global process variations
  • Standardized and harmonized process components
• The process profiles were shared across teams and cross- referenced to minimize potential for process overlap and gaps.
• The BPF and supporting process profiles were reviewed and endorsed by senior Processes & IT managers
• The BPF was used as a framework for ERP migration planning by creating customized views highlighting those processes that were directly and indirectly supported by each ERP module and the desired staging of the module migration in acquired operations.
• The BPF was used a framework for identifying standardized and harmonized process components to be migrated into acquired operations. Interim process actions for processes supported by ERP modules that would not be migrated immediately were identified.

Key Points About This Case

• Mature global organizations operate a platform of standardized processes and information technology. These platforms are interdependent but unique. Both present opportunities for optimizing the cost and effectiveness of doing business globally.
• Without a view of the work system (the business processes and IT systems) and its relationship to the value created for customers,  the organization had no valid criteria for making tradeoffs between desired requirements/functionalities and potential performance efficiencies. This created great debates among all stakeholders (the acquired operations, business management and the Processes & IT Department) that tended to center around the responsiveness of Processes & IT instead of the impact on organization performance. This was a no-win situation for Processes & IT, which typically defaulted to accepting an “order taker” position. The resulting organization impact was complex systems that accommodated every requirement/functionality but were expensive to maintain and costly and slow to evolve.
• The BPF effort was one of four key components of their process approach. It was supported by the other three components: Process Improvement Methodology, a process-oriented Project Portfolio Management System, and common tools, conventions, and repository for capturing process documentation.

Related Links

To read an article on the subject of the Business Process Framework (which we also refer to as a Business Process Architecture), click here.

For a presentation on the topic of the Business Process Architecture, click here.

For information about PDL’s consulting service, where we assist organizations in defining their Business Process Architecture, click here.

Insurance company that wanted to double in size within five years

Critical Business Issue

Operations hampered by legacy systems that caused work processes to be highly complex, liable to errors, noncompetitive, and an obstacle to growth or change in business approach

Critical Process Issues

Varied by process, but most were too slow compared to competition and prone to human error because of system and process complexities

Approach

• Executive Team analyzed its current super-system and business model, then developed possible future-state scenarios and identified the capabilities (process/technology/people/management/general infrastructure) required to succeed in the future.
• Project Team (composed of process excellence specialists, IT representatives, and middle managers):
  • Updated an “is” Value Creation Architecture down to Level 3 (they already had an “is” Business Process Framework and existing Level 3 “is” process maps
  • Distributed the required capabilities along the Value Creation Architecture, which revealed capability gap
  • Developed high-level (whole business) alternative designs and discovered that the future business would require not one, but three different L-S-D Launched, Sold, and Delivered designs (that is, high tech, high touch and large corporate customers)
• The Project Team then was divided into three sub-teams, each of which developed a full Value Creation Architecture (VCA) down to Level 5, following the standard RPM methodology (from design phase on) but with three designs in parallel and applied to multiple processes within each Value Creation Architecture.
• Each design included models of all the future-state processes showing both human and technology performers in detail and their Human Performance System/Technology Performance System requirements.
• The three Value Creation Architectures were presented to management for approval and funding.
• The three Value Creation Architectures were implemented together into the existing business, as they were not three different lines of business but three ways to deliver the company’s products and services.

Key Points About This Case

• Scope was not predetermined: Project started with a super-ordinate business goal (that is, growth) and critical business issue, then led to a gap analysis between current state and future business scenarios showed that the entire business had to be in project scope and potentially redesigned.
• Executive team engagement in first stage of work ensured their ongoing support and active interest in the result of the project.
• RPM methodology is scalable to multiple processes and even entire lines of business.
• Technologists were key members of each design sub-team, providing design ideas and guidance about the practicality of technology usage in the processes, and watching over alignment of the designs with the company’s Enterprise Architecture vision.
• Once the three sub-teams were formed, they met frequently to review progress and share their designs. The sub-teams were encouraged to borrow process and technology designs from each other, which helped to minimize the total cost of the proposed “should” Value Creation Architectures. (For example, the Large Corporate Customer sub-team largely adopted a mix of processes from the High Tech and High Touch sub-teams and created few of their own.)
• The “alternative designs” technique is scalable: such designs can address any aspect of the Effective Process Framework for a process, the entire process, or even an entire business (which happened in this case).
• Despite the large scale and scope of work, the project was completed in just twelve weeks, because the Project Team members devoted at least three days per week to the project for its duration, and they were supported by the executives who gave the project the highest priority.
• The speed of the project was also helped by the fact that the team had earlier developed something of an “is” Business Process Framework and had Level 3 process maps, so the Analysis Phase was relatively brief.

Related Links

For information on our consulting service for future state design of an organization, click here.

For information on our consulting service to assist with organization redesign, click here.