Based on a number of projects where we needed to implement new processes, supported by new technology, I start to see a pattern emerge, that seems to work helping people and organisations reach the goals of a certain change program.
The pattern consists of four phases that people can go through, if supported by the right interventions.
Suppose we have defined a certain change requirement (which could be a full blueprint, that needs to be implemented top-down, or, preferably, there is rooom to work together with the involved people to define and implement the required change)....
Then I see five steps/phases to get to a succesful change:
1. Awareness
Our business life is an attention economy: a lot of stuff is happening, and we only have so much time and processing power. If you want to involve people that will be affected by a change, you will need to get above the radar. So with a good combination of receiving/sending the goal is to make people aware that something is coming, something that will effect them. SThe objective is to touch people in three levels:
1. their thinking (understanding what's coming),
2. their feeling(make sure they associate the coming change with A:positive feelings, based on various values, such as "interesting", "fun", "will create new opportunities", "growth" and B: safety: "my needs & concerns will be addressed", "I will be able to handle this change"
3. Their actions (I want to know more, provide input)
But this is not something you can control - people are (fortunately) autonomous, and will react in different ways. All this is vital information.
2. Understand and commit
Where the first phase is still open and has room for "we will see", this phase is about making people really understand what change is coming and how it will effect their workreality. Here usually a lot of energy is created, which can be positive, but can also lead to sharp resistance if not handled properly. With the right combination of listening, telling, and honest but committed communication from the higher management level, people will need to be made aware that their worksituation will be changed. And that their input is vital - but that choices will need to be made, some of which not that great. Assurance on clear decision procedures/criteria is important.
3. Prepare to perform
The last step for the actual change implementation is the building of competences, skills and self-confidence of the people. Here we train people, do proof of concepts, dry-runs etc. All to assure that we all understand the change in all details and that we are able to work in the new situation and deliver the right performance.
4. The real GO
This is the moment of course, that we have planned so carefully. It's a period full of last minute adaptions, issues and, if all goes well, a growing stream of real work, in line with the required change. It's alive and working!
5. Discipline
We tend to forget this, and often as a consultant we miss this phase, but it is important to address already during earlier phases: making sure the changed situation keeps performing (no fall back to old procedure). This deals with interventions on rewards, jobdescriptions. And with a feedback loop that actively uses the input of people to fine tune the process...
I wonder if other people recognize these phases, or see other important steps and activities! I welcome feedback!
Sunday, September 07, 2008
Saturday, September 06, 2008
Borders of BPM - Process management
There is a saying (hope I translate it right): Where people draw borderlines, there will be border-conflicts. In this post, I want to address a definition issue around BPM, based on observations in some recent client work. It deals with (in my view) the difference between business process management and process management. Two areas where the borderline seems blurred. In some discussions I had, due to this blurred borderline, confusion started to grow.
Let's try to find the difference and border conflicts between these area's.
Process management: the area of activity to plan the execution of a process and to steer the execution of a process (through interventions on specific "instances"), to make sure the objectives are met and that process performance is conforming to certain requirements.
(We could also call this: Operations or Operational management).
The managed object here is the performance of the process. The activity is done within the boundaries of the current process, e.g. the process in itself is not changed. Steering will be interventions on people, and work in progress. E.g. analyse a specific client-issue, re-assign work, re-prioritize, fix issues, etc.
Business process management: the area of activity to manage processes as an asset, and manage the life cycle of these processes, aimed at structuredly improving the processes (in a continous cycle).
Here the managed object is the structure/design of the process (perhaps even the existance of the process!)- e.g. in the BPM area of activity, processes are changed, to adapt to sharpened performance goals and/or to structural changing circuimstances (as opposed to reacting to an specific exception - which would be process management).
Activities here range from setting up target improvement goals, analysing/designing processes that can meet these goals, implementating these (changed) processes and checking the structured performance of these processes, to analyse and check if further improvement steps are needed. Here, we act on different levels - we select processes, plan/prioritize processes to analyse/improve, and on a detailed level work with a specifiek process design and adapt it (change activities, business rules for decisions and assignments, etc).
Is process management BPM? Is BPM process management? Difficult, because recursion effects occur: if we implement a process in a company, where this process goal is to increase the performance of other processes, and we are managing this process, uhm, .....
But I do know that if a company has implemented a process, and from that moment on is managing the performance of the process (and not changing anything in the structure), it would be weird to say that they are doing full-swing BPM.... Because a lifecycle perspective and governance is missing.
For me one part of BPM will be to design and implement a process. Part of the process is of course also the processpart that will manage that process (who wants to implement a process without any goverance/control structure?). This means that implementing the process will also create the process management of that process.
Confused? Here is a diagram that tries to show my point: a Plan-Do-Check-Act cycle is implemented and performed (e.g. process management) when (as part of the BPM cycle) the process has been deployed and is being executed for a certain period of time.
Let's try to find the difference and border conflicts between these area's.
Process management: the area of activity to plan the execution of a process and to steer the execution of a process (through interventions on specific "instances"), to make sure the objectives are met and that process performance is conforming to certain requirements.
(We could also call this: Operations or Operational management).
The managed object here is the performance of the process. The activity is done within the boundaries of the current process, e.g. the process in itself is not changed. Steering will be interventions on people, and work in progress. E.g. analyse a specific client-issue, re-assign work, re-prioritize, fix issues, etc.
Business process management: the area of activity to manage processes as an asset, and manage the life cycle of these processes, aimed at structuredly improving the processes (in a continous cycle).
Here the managed object is the structure/design of the process (perhaps even the existance of the process!)- e.g. in the BPM area of activity, processes are changed, to adapt to sharpened performance goals and/or to structural changing circuimstances (as opposed to reacting to an specific exception - which would be process management).
Activities here range from setting up target improvement goals, analysing/designing processes that can meet these goals, implementating these (changed) processes and checking the structured performance of these processes, to analyse and check if further improvement steps are needed. Here, we act on different levels - we select processes, plan/prioritize processes to analyse/improve, and on a detailed level work with a specifiek process design and adapt it (change activities, business rules for decisions and assignments, etc).
Is process management BPM? Is BPM process management? Difficult, because recursion effects occur: if we implement a process in a company, where this process goal is to increase the performance of other processes, and we are managing this process, uhm, .....
But I do know that if a company has implemented a process, and from that moment on is managing the performance of the process (and not changing anything in the structure), it would be weird to say that they are doing full-swing BPM.... Because a lifecycle perspective and governance is missing.
For me one part of BPM will be to design and implement a process. Part of the process is of course also the processpart that will manage that process (who wants to implement a process without any goverance/control structure?). This means that implementing the process will also create the process management of that process.
Confused? Here is a diagram that tries to show my point: a Plan-Do-Check-Act cycle is implemented and performed (e.g. process management) when (as part of the BPM cycle) the process has been deployed and is being executed for a certain period of time.
Subscribe to:
Posts (Atom)