The Process-Centered Organization: In From Left Field

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.


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.