Articles

In the first three Columns of their series on the Process Centered Organization, Alan ramias and Cherie Wilkins presented examples that started in the “core of the business” and that were initiated and driven by line of business executives. In this, the final Column of the series, they discuss an example of a PCO journey driven by IT. As in the three previous Columns, they evaluate the pros and cons of the IT driven approach and conclude the Column by ranking the four journeys in terms of their potential for success.

In their May Column Alan Ramias and Cherie Wilkins discussed process-centered organizations (PCO) that take a slow, gradual approach. In this Column they focus on organizations that become process-centered because they are in deep trouble. They explore the critical elements that need to be in place in order for a stricken organization to move ahead to recovery, describing two different organizations that took a process centered approach in response to an initial crisis.

In their February Column, Alan Ramias and Cherie Wilkins defined a process-centered organization (PCO) and gave an example of a company that became process-centered in a relatively short period of time. In this Column they reflect on the more frequently experienced approach—the long road. Read about the obstacles that one company encountered, their successes, and lessons learned.

In the first of a four-part series on the (PCO) Process-Centered Organization, Alan Ramias and Cherie Wilkins define the characteristics they believe must be in place for an organization to be “process-centered.” These characteristics are derived from their experiences working with organizations to help them develop and improve their BPM programs. Acknowledging that some readers may wonder if any organization has ever reached their ideal PCO, the authors describe an actual case in which a wealth management bank successfully achieves that ideal.

In their May 2010 Column on process performance measurement, Alan Ramias and Cherie Wilkins provided some principles to avoid complications in creating effective process performance measurement systems. In their September Column they provided a tool for identifying appropriate process metrics linked to both customer and business requirements. In this, the third and final Column in their series, the authors address the issue of who is responsible for process performance. These three Columns provide an invaluable reference for all who are engaged in this important work.

In their May Column, Alan Ramias and Cherie Wilkins began a series on process metrics. They cite some of the recurring problems and pitfalls they have encountered in working with clients, including: creating metrics 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, they address remedies for some of the most significant problems. They describe the guidelines they follow in creating process metrics and apply those guidelines using a tool for identifying the right process metrics.

In two previous Columns on process ownership Alan Ramias and Cherie Wilkins discussed various approaches to process ownership and what process owners actually do. In this, the final installment in the series, they focus on the critical role of the performance architect. Broadly speaking, process owners should be managing while performance architects carry out the tasks that enable the process owners to manage. Combined, these three Columns offer an excellent reference for defining the roles and responsibilities of process owners versus those of process architects.

One of the most important – but frequently most challenging and vexing – aspects of installing business process management in an organization is metrics. There is seldom much argument anymore about the necessity of having metrics at the process level to enable process owners and performing teams alike to monitor performance, diagnose variation, and make effective course corrections. Once a business process has been created or redesigned, measurement of process performance is critical. Measurement can be used to ensure the process is installed properly, produces desired results, and design integrity is maintained. Ongoing measurement is the basis for continuous improvement.

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

Process ownership (and with it, process management) has been at least attempted, and in some cases successfully established, in many organizations since the concept was first described in the book Improving Performance: How to Manage the White Space on the Organization Chart by Geary Rummler and Alan Brache back in 1990.

There are two types of performers that do the work of organizations – people and technology. They can perform work independent of each other, but often perform the work together as a human-technology team.

This is part one of a three-part paper describing a framework for modeling the business architecture (BA) layer of enterprise architecture (EA).

In our last two columns, we ranted at length about the all too prevalent scenario of IT projects that have failed spectacularly, costing the companies that funded them millions of dollars (in some cases, hundreds of millions) with no usable outcomes.

In our first column we wrote about the huge, costly failures of IT systems development projects, citing some of the disasters we saw personally or had read about recently.

Welcome to our inaugural column. Rather than focus on a particular subject or theme, our intention with this column is to write about issues and ideas that seems to intrigue or bother not only us but the various constituencies that visit BPTrends.

Look at any book on business process management or improvement these days and you’ll see a good amount of advice being expended on the creating, chartering, nurturing and managing of process design, or improvement, teams.

We firmly believe that the general understanding that work gets done – and value is added – through cross-functional processes is potentially the greatest business management breakthrough in the past 100 years.

The BPA Framework provides all the executives with a common view of all the components/processes of our organization – on one page. The complete document set* is a concise summary of the value-add work that must be performed and managed to provide value to customers – the operative word being work.

In her book, Electronic Performance Support Systems, Gloria Gery popularized the notion of designing technology to assist workers in performing tasks, writing about the growing use, and importance, of electronic job aids such as on-line tutorials, directories, help menus, technical support and the like, for users of laptop and desktop computers.

Inside organizations that are doing various kinds of process “work”-whether improvement projects, technology enhancements or process definition and documentation—we often hear a lot of confusion and frustration because people sometimes mean different things when they use the word “process.”

Everyone interested in business processes seems to know that Six Sigma was invented at Motorola and that Motorola became the first winner of the Malcolm Baldrige Quality Award in 1988. The origin of Six Sigma has been the subject of countless articles, a series of Harvard Business School cases, and many books.