Harmon on BPM: Integrating BPM, Lean and Six Sigma Organizations

I got into a discussion of how an organization might go about organizing to integrate their business process improvement efforts. The organization is a diversified company that does some assembly work, but is primarily a service organization that operates in several different markets. In essence, the organization already has a group which is termed a Lean Six Sigma Group, and is currently training other staff in Business Process Management. Now, I was being asked by a senior executive about how the two groups would work together.

I began by arguing, strongly, that they should work together. Setting up rival process change groups is a recipe for infighting and duplication. It happens, but I certainly don't advise it.

Just as important, however, is the question of who makes up the BPM group, and, separately, if IT maintains a separate process group. While it isn't always the case, it's often the case that the L6S effort is centered in a business area while the BPM effort is centered in IT. In the specific organization in question, I was told, that, no, IT did not maintain a process group, as such, although they had a team that had explored the use of BPM software and they had analysts that often worked on projects that involved changing processes – although the executive was quick to say that IT used “process” to mean something rather different from what the L6S group did. I agreed with that observation. Again, it isn't always the case, but most often, the L6S people will focus on processes where people are the problem while the IT folks will focus on sets of activities that are to be automated. I went on to explain that, another generalization was that BPM groups tended to look at larger processes, while the L6S people tended to look at smaller processes – processes within departments, as opposed to those that crossed departmental lines.

The key to integration, I suggested was to have each group focused on what they did best, while cooperating when possible. The BPM people, like the Business Process Renewal (BPR) people in the 90s, tended to be top-down in their focus. They tended to look at value chains and large-scale process and to ask how the entire process could be changed to make a major improvement. Those focused on Lean and Six Sigma tended to be focused on processes within departments, and on people problems associated with those processes, while IT and, in most cases, business analysts, were focused on automation opportunities. Most organizations have problems in each of these areas, so there need be no necessary clashes. On the other hand, each group have people who think outside the box, and they are likely to end up focused on the same problems, and will need some coordination.

I recommended setting up a Business Process Center of Excellence – although the company decided to call it a Process Council – with members from each group. (IT wasn't directly represented on the Process Council, but Business Analysts were, and they, in this case, represented IT.) The group was established and reported to the COO. (I would have had it report to the CEO, but got overruled.) The Process Council got some specific goals: To coordinate all process change efforts, to coordinate process training throughout the entire organization, and to develop interdisciplinary teams that could help with the initial analysis of problems and recommend subsequent action plans. I hoped that by centering expertise in the Process Council, and establishing some interdisciplinary teams, the company would get the three groups to work together and begin some cross-disciplinary training. I was particularly interested to see that many of the L6S belts took classes in business process architecture, and that most of the BPM trainees and many of the business analysts signed up for classes in Lean techniques.

I suggested that the BPM group be given responsibility for developing a high-level business process architecture that would identify major value chains and high level processes for the entire organization. (We got into some trouble here when IT maintained that their Enterprise Architecture Group was already on top of the business architecture, but eventually agreed that a business process architecture was slightly different, and that the two groups could coordinate in defining a business process architecture.) I further suggested that the Council map any current process change efforts unto the business process architecture so that this could provide an overview of what all the various process groups were doing.

Next, I suggested that they maintain a clear distinction between major process change projects, and incremental improvement projects, and that they L6S group always take the lead in the latter. I also suggested that the BPM people indicate projects that were primarily automation and projects that were primarily human performance improvement efforts, and always let the business analysts head automation projects while having L6S people head the people projects.

I'm not suggesting that we solved the problem of integrating all process change at the organization. The effort is going better in some areas, and having problems in others. Some projects are still clearly being managed by one group without the help of the other groups. But at least everyone agrees on what projects they are undertaking and who is doing what. The COO is pleased, however, that he now has a team (the Process Council) that represents all the different process perspectives and that works together to give him an ongoing summary of where the problems lie, and what is being done to fix them. He claims that they are saving real money by allocating efforts and avoiding duplication. Moreover, the head of the Process Council, who formerly led the L6S group, reports that the mixed teams are gradually developing respect for each other, and is going to be the main source of future process leaders who will being a new spirit of cooperation to the organization.

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of Enterprise Alignment, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in San Francisco. Paul can be reached at pharmon@bptrends.com
FacebookTwitterGoogle+Share

Comments

  1. Coenie Wiese says:

    What has been said here about methodologies supporting and enriching one another is so very true and it extends way beyond L6S & BPM. I have been busy with BPMI for a while now, 2003, and along the way have seen a lot of methodology introduced to our company. So often a project manager will come up with their flavour of the month methodology and introduce it as the Grail of methodologies. This extends to business requirments and specification as well where the dicussion goes on about UML vs Agile, etc.
    My view on this is that we need to use what works to place our client (the business) in a place where they get a result, but more than that understand how they got to the result.

  2. Mike Whalley says:

    This is a very interesting article. I’m trying to set up something similar within my organization. I’m specifically interested in the comment “he claims that they are saving real money by allocating efforts and avoiding duplication”. Do you have any additional insight into this statement about the precise nature of these savings because ultimately this is what C-level management are interested in when setting up a new organizational function. Moreover, I would be interested to know if the subject of potential savings to the organization was discussed when you were making recommendations and if so, what guidance did you provide ?

Speak Your Mind

*