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 SigmaGroup, 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 changeefforts, 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.
0 comments:
Post a Comment