When analyzing and implementing processes, I found out that we (ok, that includes me...) often focus too much on the core "content" process at hand. We dive into the main "named" processes that are in our scope, focus on the participants, activities, rules, etc. - model them, design improved processes and implement them. But due to this focus on "named content" we tend to forget that every process actually turns out to be three processes (and maybe even 3 more, more on this later).
If we only explore the main one, the other's are either implicitely covered, or completely forgotten, with all negative (change) consequences.
As an example: suppose our scope is "provide quote", in, say, a credit lending bank area. As analysts we dive into the process, find and model all activities - receive quote request, determine credit worthiness, calculate proposed interest rate, create quote, send quote, etc.
And if we are lucky, some analyst might even ask - what are KPI's or what is the management information that is required for the people steering this process? That person felt possibly intuitively that there are other processes floating around.
We might end up with a great "provide quote" process, and yet we might face issues around change management and reinforcement of improvements.
Let's get to the point:
The three processes that "hide in every process" in my opinion are:
- The "content process" - e.g. the main process, aimed at fullfilling the specific customer request, activities leading to the transformation of input to output
- The "operational management process" - the proces (usually plan-do-check-act) of making sure that the "content process" keeps performing.
- The "improve and (re)align process" - the process of "sharpening the saw", making sure that the content process (and operational management process) are improved, and when strategy changes of the company occur, that these processes are adapted to the new strategy .
Some thoughts...
1. As said, most of analyst's attention typically is spend on the "content process". That's ok, since in the end, if that does not run well, we end up with nothing. But let's not forget the other processes....
2. If we look at the operational management process, we might have analysts remembering that we need "management information". That's a step, but not the complete one. Steering requires a number of "process items":
- Who is steering?
- What process is followed for the steering?
- What possibilities are there for interventions ("act"), if process performance is not acceptable? According to what policies and rules?
- What information is required to steer (for planning, for checking), with what frequencies, in what form?
If we only focus on management information, we forget to focus on understanding and implementing the operational management process. Something I earlier wrote about in
"driving 50 MPH without a steer".
3. Interestly, whenever I start talking about operational management, process participants start to look "upward" to a management level. That's a choice, and usually determined by company culture.
My point is: many of the operational management activities you can also place at the process participants level. Many principles ("when is our process functioning fine, and in what situations should we act to correct issues) can better be done by the process participants themselves - they have the knowledge and see things happening. Instead of thinking "I should focus on the process and not the issue, my manager should fix this", we can make them responsible for steering as well. "When I see someone in my team having too much work, I will jump in and help", "When I see an error, I fix it, and make sure we don't make the same error again"...
4. You might object, and say "operational management" and possibly even more "improve and (re)align" should be part of a top-down scope in which we create a BPM framework for management. Sure, that's fine - if it's there. But in many situations that might take a long time. Don't wait for it - start bottom-up/middle out, learn and evaluate.
Conclusion: focus on content is fine, but don't forget to implement operational management and improve/(re)align.
As a PS:
I talked about possibly three more. These are:
- Your supplier and customer processes. What steps do they need to take to deliver and get their need fulfillled? If we forget to look at these processes, then we also miss out on possibly great opportunities for improvement in their and our own processes.
- Supporting processes. I remember working on an improvement project, where we just could not figure out why a certain process step (content level) was taking 2 - 3 days. When diving deeper, we found a supporting process (deliver physical mail) where moving a certain paper-folder took 2 days. Ah.
Sunday, December 07, 2008
Monday, November 10, 2008
Gosh - OCEB Fundamentals certified
41 and getting a diploma....
As a betatester, I got certified as OMG's OCEB Fundamentals Certified Expert in BPM. Tada...
As a betatester, I got certified as OMG's OCEB Fundamentals Certified Expert in BPM. Tada...
I think it is a good enough certification program, which is aware of the many schools in BPM thinking. The more European/Dutch focus on Risk management ("AO/IC") is lacking a bit, but in the Business Intermediate this is covered better.
Not sure if I will do betatesting for the rest. For some reason, OMG seems to be really pushing the schedule. For the Fundamentals exam, I received the invitation on June 25th, and had to do the exam before july 25th. The results I received only recently. The Business Intermediate invitation I received on October 10th, with a deadline of November 14. And now the Technical Intermediate has a deadline of Dec 4th - 3 weeks after the deadline of Business Intermediate. While the amount of materials is growing and growing.
Hm.... BPM consultants are busy and have family lives... (or is that a European bias?)
But anyway, I seem to be the first Dutch OCEB certified... Or?
Sunday, September 07, 2008
BPM & Change - Five steps to change
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!
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!
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.
Wednesday, July 30, 2008
(Dutch) Onderzoek "BPM in Nederland - 2008" : resultaten beschikbaar
(This is a dutch message about the availability of the Dutch results of a BPM survey we ran earlier this year).
Eerder dit jaar berichtte ik over het onderzoek dat Hogeschool Utrecht en Capgemini hebben gedaan rond BPM in Nederland. De resultaten van dit onderzoek zijn inmiddels beschikbaar - het rapport kan aangevraagd worden op www.bpmsurvey.nl.
Interessant leesmateriaal!
Enkele bevindingen:
- BPM krijgt groeiende aandacht
- Hoewel de meeste deelnemers BPM als een management discipline zien, wordt ook gesteld dat BPM nog teveel als IT wordt gezien
- BPM initiatieven redelijk succesvol
- BPM technologie met name nog gebruikt voor procesbeschrijving en publicatie (BPA)
- Tevredenheid over BPM technologie matig
- BPM trajecten hebben last van functionele organisatie/cultuur
- Organisaties die BPM willen toepassen zijn met name op zoek naar ondersteuning bij training
Meer bevindingen in het eindrapport. Veel leesplezier - www.bpmsurvey.nl
Eerder dit jaar berichtte ik over het onderzoek dat Hogeschool Utrecht en Capgemini hebben gedaan rond BPM in Nederland. De resultaten van dit onderzoek zijn inmiddels beschikbaar - het rapport kan aangevraagd worden op www.bpmsurvey.nl.
Interessant leesmateriaal!
Enkele bevindingen:
- BPM krijgt groeiende aandacht
- Hoewel de meeste deelnemers BPM als een management discipline zien, wordt ook gesteld dat BPM nog teveel als IT wordt gezien
- BPM initiatieven redelijk succesvol
- BPM technologie met name nog gebruikt voor procesbeschrijving en publicatie (BPA)
- Tevredenheid over BPM technologie matig
- BPM trajecten hebben last van functionele organisatie/cultuur
- Organisaties die BPM willen toepassen zijn met name op zoek naar ondersteuning bij training
Meer bevindingen in het eindrapport. Veel leesplezier - www.bpmsurvey.nl
Wednesday, July 23, 2008
Studying for OCEB fundamentals
I was lucky to become one of the beta-testers for the OMG's OCEB fundamental exam.
More info on: http://www.omg.org/oceb/
A great refresh (well, to be honest - some new stuff!). And the nice thing - some of the new material I could immediately use in my work. For instance the BMM standard is a great framework for strategy and planning concepts. And Martyn Ould's book about BPM is a nice read, I like his tone of voice - I will probably not just read chapter one, but continue.
A fair amount of BPM area's is covered :
- Process concepts
- Process modelling (BPMN)
- Maturity (BPMM)
- Compliance (but a warning: very USA centric)
- Process performance - KPI's, goal setting, etc
- General MBA stuff on business concepts
- Six Sigma (very very basic)
Stuff that I miss (maybe in a more advanced level?):
- Change management
- BPM technology (including BAM, Rules, Document management interfacing)
- How to do BPM projects (from pure processwork to BPM technology)
- Other process improvement methods such as Lean, TOC
- The relation between BPM and Business/IT architecture
- Other "activity coordination" approaches besides orchestration & choreagraphy: case management, human interaction management, collaborative BPM
A tip: Don't underestimate the work - it's quite a lot of material.
A question: any other Dutch participants? Would be nice to become the first Dutch OCEB certified (ah, my ego again ;-))
Friday exam. Will let you know more... (well, as far as the quite strict NDA will allow me….)
Wednesday, June 18, 2008
Just attended the virtual eBizq seminar
I just attended the eBizq virtual seminar on BPM.
Also see: http://expoq.unisfair.com/index.jsp?id=4616
Fun! And a great way to network, meet people and find information on BPM (although the number of vendor booths is not a bit low).
The presentations and webcasts will be available soon, which is nice, because I missed the first two parts (tip for Ebizq: publish not only the starttime US based, but also the time for people in other time zones ;-)).
He, and my question on collaborative BPM was even answered in the final panel. Nice, although the first speakers sticked too much to the casemanagement, 1 person handling tasks view of BPM technology. I am still looking for collaborative BPM (or HIMS) which can support process-fragments supporting people working concurrenly together on a certain process task (be it deciding, researching, issue-resolution, planning, whatever). See - most processes are partly structured (and can be supported by WFM), partly casemanagement, and some parts are just a total adhoc bunch of people running around, meeting and deciding.... collective intelligence at it's best, but hopefully supported by great BPM features in the future.
The virtual environment was a bit limited (chat rooms that echo-ed of emptyness, and booth chats with vendors, where people did not answer...hmmm).
But it saved me a lot of flying :-)
Also see: http://expoq.unisfair.com/index.jsp?id=4616
Fun! And a great way to network, meet people and find information on BPM (although the number of vendor booths is not a bit low).
The presentations and webcasts will be available soon, which is nice, because I missed the first two parts (tip for Ebizq: publish not only the starttime US based, but also the time for people in other time zones ;-)).
He, and my question on collaborative BPM was even answered in the final panel. Nice, although the first speakers sticked too much to the casemanagement, 1 person handling tasks view of BPM technology. I am still looking for collaborative BPM (or HIMS) which can support process-fragments supporting people working concurrenly together on a certain process task (be it deciding, researching, issue-resolution, planning, whatever). See - most processes are partly structured (and can be supported by WFM), partly casemanagement, and some parts are just a total adhoc bunch of people running around, meeting and deciding.... collective intelligence at it's best, but hopefully supported by great BPM features in the future.
The virtual environment was a bit limited (chat rooms that echo-ed of emptyness, and booth chats with vendors, where people did not answer...hmmm).
But it saved me a lot of flying :-)
Friday, May 02, 2008
JIT training in a BPM technology environment
I cam across an interesting research paper on BPM and knowledge management:
http://www.ejel.org/Volume-5/v5-i3/Leyking_et_al.pdf
Key points:
- Most training efforts are not linked to the situational context - so the learning is too remote from reality, in terms of content and timing
- A process focus can increase the value of training - process context can support modeling of required knowledge areas to complete an activity in the process
In my view there is a strong link between BPM and knowledge management. Many processmodelling efforts, as a start, where created from a knowledge perspective - helping new (and existing) employees in the business to understand the processes and activities to be done, so that they could perform their work accordingly.
And of course, when executing processes, the right employees with the right skills and knowledge are needed for performing certain tasks.
Some BPM technology vendors are already taking some steps to support knowledge management in the context of process. Simple example: a user can click on "show the process map" when working on an activity, and the processmap + highlighted activity is shown, helping the user to understand the context of the activity.
The paper triggered me to think a bit further -
Wouldn't it be great to have a BPM technology solution that enabled us to trigger "just in time" learning?
The scenario:
An employee gets a task assigned. The BPM suite identifies that the person has never performed this task before (of possibly other triggers: the employee scores low on certain other KPI's around this activity such as errors made, throughput time, etc).
The BPM suite suggest to the user, prior to activity start: "Do you want to follow a quick Just In Time training on how to succesfully complete this activity"?
And from that point on, a link is provided to some training environment, which trains the user, through video, text, quizes etc to understand the link to strategy, process context, activity and best practices for the activity.
Benefit: Just in Time, so very closely linked to the context of the actual work to be done.
http://www.ejel.org/Volume-5/v5-i3/Leyking_et_al.pdf
Key points:
- Most training efforts are not linked to the situational context - so the learning is too remote from reality, in terms of content and timing
- A process focus can increase the value of training - process context can support modeling of required knowledge areas to complete an activity in the process
In my view there is a strong link between BPM and knowledge management. Many processmodelling efforts, as a start, where created from a knowledge perspective - helping new (and existing) employees in the business to understand the processes and activities to be done, so that they could perform their work accordingly.
And of course, when executing processes, the right employees with the right skills and knowledge are needed for performing certain tasks.
Some BPM technology vendors are already taking some steps to support knowledge management in the context of process. Simple example: a user can click on "show the process map" when working on an activity, and the processmap + highlighted activity is shown, helping the user to understand the context of the activity.
The paper triggered me to think a bit further -
Wouldn't it be great to have a BPM technology solution that enabled us to trigger "just in time" learning?
The scenario:
An employee gets a task assigned. The BPM suite identifies that the person has never performed this task before (of possibly other triggers: the employee scores low on certain other KPI's around this activity such as errors made, throughput time, etc).
The BPM suite suggest to the user, prior to activity start: "Do you want to follow a quick Just In Time training on how to succesfully complete this activity"?
And from that point on, a link is provided to some training environment, which trains the user, through video, text, quizes etc to understand the link to strategy, process context, activity and best practices for the activity.
Benefit: Just in Time, so very closely linked to the context of the actual work to be done.
Sunday, April 27, 2008
Convergence of process model silos
Go look in a random, reasonably mature organisation, and it is likely that you will encounter a number of places where people think, discuss, record and analyse process.
Let's see where.....
Let's see where.....
First of all we see BPA centers, that model processes so the organisation can... be compliant, reach ISO certification, communicate to people (knowledge management). Often the procesmodels and instructions are published on some intranet.
Then we see enterprise architects, modeling processes (often from a higher view).
We see business analists, working in a change project, trying to find the As-is and To-be situation, and documenting them in requirements tool (parts of business or system use cases) or documents
We see BPM engines running, with procesmodels.
That's a lot of process models, with often a lot of overlap.
Duplication of data and of simular tooling is often the case.
Currently, we see that the tools in the various areas are not integrated. It means remodelling processes in the other tool. And we see that the tools are limited. A BPA tool can have great modelling capabilities, but can't link things to (abstract) services. Or the BPM-suite is great to model processes, but we can't publish them to do knowledge management.
The key question - will we end up with convergence?
There are signs.
- Some companies are using BPA (for instance ARIS) to also model requirements, next to as-is and to-be processes
- Some companies are using their extended BPM suite to also publish the processes to some intranet (for instance Pega systems)
- Some BPM companies are buying BPA tooling
- Some BPA vendors are extending their BPA offering with BPM-suite execution cabilities.
I long for an integrated tool (either one tool, or a clear, say XPDL type, integration - but beware round-trip...)... where I....
- Can model an enterprise (functions, processes, services, organisational units)
- Can model requirements (including business rules), and link them to all of these elements, as-is and to-be
- Can define processes in more detail
- Can execute and measure some of these processes
Human BPM/BPI-game and my key lessons
Recently I attended a good training on process modeling and analysis. One of the final parts was a group exercise where we simulated a process. A lot of fun - first we got the specs of a process, e.g. activities, flows, business rules and resources. And each of us was given a role in the process. Based on a computermodel we received "customer orders", and we performed the tasks, delivering the requested product, while the computer was measuring %on-time delivery and leadtime (+ variances + some other KPI's).
Then we had the opportunity to discuss the process, our observations on performance, and as a group suggest and implement improvements. Of course we used various techniques, we just learned in the training, such as elements from value added analysis, bottleneck removal, leveling, and other lean + common sense techniques. Then we performed the process again, with again KPI measurement. And one last round of improvement and simulation.
We did fine in the end - the process was definitely improved. And - both leadtime went down, resourcing went down, cost went down and predictability went up (less lead time variance).
My key lessons:
1. A lot of improvements is FREE
We often have the idea that improvement comes at a cost. Yes - for most improved processes that will probably be true. But the start process we were given was not so unrealistic. Yet, with surprising little improvement changes, we were able to improve on all major performance elements.
Wandering around various organizations, I have often been puzzled by the lack of view on processes and the great, yet unattemped potential for improvement...
2. Change management is hard....
Running the process went fine, but as a group coming to terms with the analysis, improvement ideas and selection/implementation - ough. A lot of discussion, confusing, different angles, lack of leadership.
It learned me the valuable lessons:
-Business Process Improvement (BPI) needs a mix of people from the floor and people with general process improvement skills
- BPI workshops need a strong facilitator
- BPI needs someone that takes decisions - e.g. management that understand the BPI ideas and is able to prioritize and select
In real live I see these things too. So much room for improvement. Coming up with good improvement ideas is often easy. But getting all the people aligned and agreeing- that's the hard part. In terms of evolution, I guess that's our next challenge. We are great survivors. But in the future collaboration will define our real survival. Not sure if we humans are equiped enough for this task...
Then we had the opportunity to discuss the process, our observations on performance, and as a group suggest and implement improvements. Of course we used various techniques, we just learned in the training, such as elements from value added analysis, bottleneck removal, leveling, and other lean + common sense techniques. Then we performed the process again, with again KPI measurement. And one last round of improvement and simulation.
We did fine in the end - the process was definitely improved. And - both leadtime went down, resourcing went down, cost went down and predictability went up (less lead time variance).
My key lessons:
1. A lot of improvements is FREE
We often have the idea that improvement comes at a cost. Yes - for most improved processes that will probably be true. But the start process we were given was not so unrealistic. Yet, with surprising little improvement changes, we were able to improve on all major performance elements.
Wandering around various organizations, I have often been puzzled by the lack of view on processes and the great, yet unattemped potential for improvement...
2. Change management is hard....
Running the process went fine, but as a group coming to terms with the analysis, improvement ideas and selection/implementation - ough. A lot of discussion, confusing, different angles, lack of leadership.
It learned me the valuable lessons:
-Business Process Improvement (BPI) needs a mix of people from the floor and people with general process improvement skills
- BPI workshops need a strong facilitator
- BPI needs someone that takes decisions - e.g. management that understand the BPI ideas and is able to prioritize and select
In real live I see these things too. So much room for improvement. Coming up with good improvement ideas is often easy. But getting all the people aligned and agreeing- that's the hard part. In terms of evolution, I guess that's our next challenge. We are great survivors. But in the future collaboration will define our real survival. Not sure if we humans are equiped enough for this task...
Thursday, April 17, 2008
(Dutch only) Al goede deelname Nederlands BPM onderzoek (nog lopend)
(Dutch only - concerns progress on a dutch research on application of BPM as discipline and BPM technology in dutch organizations)
Eerder heb ik geschreven over het onderzoek "Business Process Management in Nederland - 2008" dat de Hogeschool Utrecht ism Capgemini uitvoert.
Ik moet zeggen - we hebben nog een week te gaan, maar al 100 mensen hebben de enquete ingevuld op www.bpmsurvey.nl .
Het betekent dat we qua onderbouwing van resultaten redelijk stevig staan, ook gezien de spreiding van de deelnemers over de verschillende branches in Nederland. En ik denk dat de resultaten interessant worden en bruikbaar voor organisaties om te kijken waar BPM zich heen ontwikkelt en te zien wat andere organisaties doen met BPM en BPM technologie.
Reacties van de deelnemers waren voornamelijk positief. Eén quote:
"Het BPM survey werkte voor mij heel verhelderend. Aan de hand van de vragen zie ik de gaten op BPM gebied in onze organisatie. Ik ga mij binnen onze afdeling verder bekwamen in alle facetten van BPM om verbeteringen door te voeren en deze uit te dragen binnen de organisatie."
Kijk, daar worden we natuurlijk blij van. Maar er kwam ook kritiek, goede kritiek, die we meenemen voor toekomstig onderzoek naar BPM.
Vanaf deze plaats kan ik alleen maar zeggen: als je nog niet hebt meegedaan, en geinteresseerd bent in de resultaten van het onderzoek - doe dan mee! Je input is waardevol.
www.bpmsurvey.nl. De vragenlijst is nog tot en met 25 april actief.
Voor meer informatie over het onderzoek, zie ook:
http://www.bpmsurvey.nl/BPMuitnodiging.html
Eerder heb ik geschreven over het onderzoek "Business Process Management in Nederland - 2008" dat de Hogeschool Utrecht ism Capgemini uitvoert.
Ik moet zeggen - we hebben nog een week te gaan, maar al 100 mensen hebben de enquete ingevuld op www.bpmsurvey.nl .
Het betekent dat we qua onderbouwing van resultaten redelijk stevig staan, ook gezien de spreiding van de deelnemers over de verschillende branches in Nederland. En ik denk dat de resultaten interessant worden en bruikbaar voor organisaties om te kijken waar BPM zich heen ontwikkelt en te zien wat andere organisaties doen met BPM en BPM technologie.
Reacties van de deelnemers waren voornamelijk positief. Eén quote:
"Het BPM survey werkte voor mij heel verhelderend. Aan de hand van de vragen zie ik de gaten op BPM gebied in onze organisatie. Ik ga mij binnen onze afdeling verder bekwamen in alle facetten van BPM om verbeteringen door te voeren en deze uit te dragen binnen de organisatie."
Kijk, daar worden we natuurlijk blij van. Maar er kwam ook kritiek, goede kritiek, die we meenemen voor toekomstig onderzoek naar BPM.
Vanaf deze plaats kan ik alleen maar zeggen: als je nog niet hebt meegedaan, en geinteresseerd bent in de resultaten van het onderzoek - doe dan mee! Je input is waardevol.
www.bpmsurvey.nl. De vragenlijst is nog tot en met 25 april actief.
Voor meer informatie over het onderzoek, zie ook:
http://www.bpmsurvey.nl/BPMuitnodiging.html
Saturday, April 12, 2008
Business Process Control in two loops
Earlier I blogged about the role of Business Activity Monitoring. When talking to various vendors I found different views on the use of this. Again - this blogitem's inspiration I got from a presentation from Pallas Athena (www.pallas-athena.com)
Basically there are two efforts going on in a BPM environment that require monitoring, as part of the Plan-Do-Check-Act loop:
1. Operational management (let's call this loop 1)
This is: making sure that current procesflows (real orders, cases, complaints, whatever) deliver within acceptable scoring range.
This is the daily management process to make sure all customer/stakeholder expectations are met. It could include firefighting to make sure that one order gets delivered on time, the certain complaint gets the right attention, that the illness of employee XYZ is not impacting the question a customer had, etc, etc.
2. Process improvement management (let's call this loop 2)
This is the more structural view on the process performance. Now we are not interested in making sure a certain process instance (order, complaint, etc) is executed on time, within budget, but we want to look at the process performance as a whole. And analyse the process - where are bottlenecks, in what type of instances we typically end up with trouble, what are average leadtimes, costs, etc?
I see a number of things in the BPMS market:
1. Some vendors do not see the difference, or limit their view on only one type of management.
2. Most vendors promise that "the BPMS will help you to improve", but most vendors deliver for only one thing: Business Activity Monitoring.
My main point: BAM is not a solution. BAM can be a supporting role (CHECK) to be able to manage both management processes, but we need more in a BPMS. We need to be able to ACT.
A simple analogy:
When I see smoke pooring out of my oven, and the temperature-meter of the oven is well in the red, I have information: my food is burning, my process is out of acceptable KPI ranges.
However, the key question: what can I DO to 1. fix this now, and 2. Fix this from happening again?
My control in this situation is:
Process 1. Switch oven off, take food out, curse, start over (or eat out)
Process 2. Read the recepy, use the oven timer, set the right temperature, and maybe have my girlfriend doublecheck, plus check progress every 5 minutes
BAM is nice, but we need a linked feature called "Business Process Control" in BPMS (and some already have it, but name it differently) - the ability to:
1. Fix current process instance that are off limits (or are in danger to become that)
For instance:
- Reassign staff, temporarely hire new staff
- Prioritize processes / tasks / certain customers
- Say sorry to the customer pro-actively and negotiate new delivery conditions
(Can you think of other control activities?)
2. Fix the process
Usually people think "change process activities" when improving. But my believe is: usually much can be done through:
- Changing assignment business rules (triage, priority based, etc)
- Tune process flow rules
- Increase staff
- Train staff
(Can you think of other control activities?)
BPC - Business Process Control. Now that would be a nice feature in a BPMS.
And maybe even BPCC - Business Process Coaching and Control: a BPMS that alerts you (BAM), suggests (Coaching) possible actions ("why don't you assign this task to Mary?") and allows you to take control measures on loop 1 and loop 2.
But then again, we have enough TLA and FLA's....
Basically there are two efforts going on in a BPM environment that require monitoring, as part of the Plan-Do-Check-Act loop:
1. Operational management (let's call this loop 1)
This is: making sure that current procesflows (real orders, cases, complaints, whatever) deliver within acceptable scoring range.
This is the daily management process to make sure all customer/stakeholder expectations are met. It could include firefighting to make sure that one order gets delivered on time, the certain complaint gets the right attention, that the illness of employee XYZ is not impacting the question a customer had, etc, etc.
2. Process improvement management (let's call this loop 2)
This is the more structural view on the process performance. Now we are not interested in making sure a certain process instance (order, complaint, etc) is executed on time, within budget, but we want to look at the process performance as a whole. And analyse the process - where are bottlenecks, in what type of instances we typically end up with trouble, what are average leadtimes, costs, etc?
I see a number of things in the BPMS market:
1. Some vendors do not see the difference, or limit their view on only one type of management.
2. Most vendors promise that "the BPMS will help you to improve", but most vendors deliver for only one thing: Business Activity Monitoring.
My main point: BAM is not a solution. BAM can be a supporting role (CHECK) to be able to manage both management processes, but we need more in a BPMS. We need to be able to ACT.
A simple analogy:
When I see smoke pooring out of my oven, and the temperature-meter of the oven is well in the red, I have information: my food is burning, my process is out of acceptable KPI ranges.
However, the key question: what can I DO to 1. fix this now, and 2. Fix this from happening again?
My control in this situation is:
Process 1. Switch oven off, take food out, curse, start over (or eat out)
Process 2. Read the recepy, use the oven timer, set the right temperature, and maybe have my girlfriend doublecheck, plus check progress every 5 minutes
BAM is nice, but we need a linked feature called "Business Process Control" in BPMS (and some already have it, but name it differently) - the ability to:
1. Fix current process instance that are off limits (or are in danger to become that)
For instance:
- Reassign staff, temporarely hire new staff
- Prioritize processes / tasks / certain customers
- Say sorry to the customer pro-actively and negotiate new delivery conditions
(Can you think of other control activities?)
2. Fix the process
Usually people think "change process activities" when improving. But my believe is: usually much can be done through:
- Changing assignment business rules (triage, priority based, etc)
- Tune process flow rules
- Increase staff
- Train staff
(Can you think of other control activities?)
BPC - Business Process Control. Now that would be a nice feature in a BPMS.
And maybe even BPCC - Business Process Coaching and Control: a BPMS that alerts you (BAM), suggests (Coaching) possible actions ("why don't you assign this task to Mary?") and allows you to take control measures on loop 1 and loop 2.
But then again, we have enough TLA and FLA's....
New BPMS feature: process mining
Recently I attended a meeting where a BPMS vendor (Pallas Athena, http://www.pallas-athena.com/) presented a new (for me) feature: process mining.
They worked on this concept together with the Eindhoven University (Van der Aalst, a well-known name in BPM research, also see http://www.processmining.org/ and http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/process%20mining.htm)
Basically, the concept is:
- the BPMS reads all kinds of logfiles from various computersystems.
- The BPMS analyses the logfiles and will construct a processmodel automatically
- The data + model can be used for animation and simulation
That's interesting for multiple reasons:
- It usually takes quite some time to construct a procesmodel manually - talks to stakeholders, workshops, etc. Process mining can save time (and cost)
- Even when interviewing stakeholders, they might not have the correct overview and the modelled process might not match reality. Process mining can confront stakeholders and improve model quality.
There is catch of course:
1. The logfiles need to provide data that a BPMS can interpret - aka some type of task identification, a timestamp and a unique ID (of a certain flowing object, such as customer, order, process, etc)
2. Process models that are "mined" will only contain the reality as is presented in the logfiles, and no more. They will miss:
- Business rules for decisions and assignments (why did this instance go left, why was person X the performer of the task)
- Manual activities or activities not traced in logfiles
Still, I saw some cool stuff, that could have added value in BPM efforts:
1. A logfile of a helpdesk application was analysed. Step by step you saw the processmodel appear and get refined, based on the logfile entries
2. A time-based animation could be run, based on the original logfile, showing the flow (little dots) through the process model. This was quite interesting, because it visually showed the execution, quickly pointing to bottlenecks and opportunities for improvement
(Note: if would even be better if the system would be able to present possible improvement actions, based on process improvement frameworks such as Lean and Six Sigma)
3. When the animation was shown to the stakeholders, they did not believe the process - certain flows where against company policy, but did happen. Compliance issues became clear.
4. Based on the logfiles, various KPI's could be calculated. In addition, various statistical facts could be derived, usefull for subsequent simulation
5. If the eventlog also contained userdata, it was possible to analyse and visualize the "social map" - who is involved when, where and is linked to other people.
So, even though the technology is quite new, needs refinement and has limitations, I do see interesting benefits:
- Quickly "mine" a starting point for a processmodel, and then add tasks and business rules
- Visualize currect processes and analyse bottlenecks
For more information - see: http://tabu.tm.tue.nl/wiki/_media/pressrelease/press_release_stw_project_ned2.pdf?id=news&cache=cache
Disclosure: I have no commercial relation with Pallas Athena.
They worked on this concept together with the Eindhoven University (Van der Aalst, a well-known name in BPM research, also see http://www.processmining.org/ and http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/process%20mining.htm)
Basically, the concept is:
- the BPMS reads all kinds of logfiles from various computersystems.
- The BPMS analyses the logfiles and will construct a processmodel automatically
- The data + model can be used for animation and simulation
That's interesting for multiple reasons:
- It usually takes quite some time to construct a procesmodel manually - talks to stakeholders, workshops, etc. Process mining can save time (and cost)
- Even when interviewing stakeholders, they might not have the correct overview and the modelled process might not match reality. Process mining can confront stakeholders and improve model quality.
There is catch of course:
1. The logfiles need to provide data that a BPMS can interpret - aka some type of task identification, a timestamp and a unique ID (of a certain flowing object, such as customer, order, process, etc)
2. Process models that are "mined" will only contain the reality as is presented in the logfiles, and no more. They will miss:
- Business rules for decisions and assignments (why did this instance go left, why was person X the performer of the task)
- Manual activities or activities not traced in logfiles
Still, I saw some cool stuff, that could have added value in BPM efforts:
1. A logfile of a helpdesk application was analysed. Step by step you saw the processmodel appear and get refined, based on the logfile entries
2. A time-based animation could be run, based on the original logfile, showing the flow (little dots) through the process model. This was quite interesting, because it visually showed the execution, quickly pointing to bottlenecks and opportunities for improvement
(Note: if would even be better if the system would be able to present possible improvement actions, based on process improvement frameworks such as Lean and Six Sigma)
3. When the animation was shown to the stakeholders, they did not believe the process - certain flows where against company policy, but did happen. Compliance issues became clear.
4. Based on the logfiles, various KPI's could be calculated. In addition, various statistical facts could be derived, usefull for subsequent simulation
5. If the eventlog also contained userdata, it was possible to analyse and visualize the "social map" - who is involved when, where and is linked to other people.
So, even though the technology is quite new, needs refinement and has limitations, I do see interesting benefits:
- Quickly "mine" a starting point for a processmodel, and then add tasks and business rules
- Visualize currect processes and analyse bottlenecks
For more information - see: http://tabu.tm.tue.nl/wiki/_media/pressrelease/press_release_stw_project_ned2.pdf?id=news&cache=cache
Disclosure: I have no commercial relation with Pallas Athena.
Thursday, April 03, 2008
BPM - Thoughts about change
BPM projects are change projects. And I want to address a number of thoughts about change.
1. Likelihood of change
Thinking about change (and mainly based on my sometimes painfull lessons on projects that actually did not lead to sustained change) I came up with a simple formula to make me once and for all remember factors required for change. They prevent me from being overly optimistic (as I sometimes have the tendency to run too far from the troops...)
The formula: Likelyhood of sustainable change =
Need x Awareness x Sense Of Urgency x Ambition x Priority x Vision x Resources x Courage / Risks
Need: is there current pain? Something that the people want to get away from?
Awareness: is there real awareness of the pain, the causes and the need to get away from it?
(sidenote: in learning theory you have the powerful model of:
UU - Unaware Unable - We are not able to do something, but unaware....
AU - Aware Unable
AA - Aware Able
UA - Unaware Able
In this case: are the key stakeholders at AU level?)
In this case: are the key stakeholders at AU level?)
Sense of Urgency: do key people, with power, affected by the pain (directly or indirectly) really want to get away from it?
Ambition: is there an ambition to spend time, energy and resources to actually do something?
Priority: is this required change and the effort it requires a priority? Or are there other things more important?
Vision: do we have a vision how the TO BE situation looks like and how to get there (more about this later)
Resources: do we have money, people, some time, etc to get there?
Resources: do we have money, people, some time, etc to get there?
Courage: do the leaders, excuses le mot, have the BALLS to actually stick their heads out and get it going?
Risks: how much risk is involved (the bigger, the less likely change will occur, unless.... Courage and Vision is available...)
My lesson: check this formula in the beginning of your efforts on a specific project/change.
And if the outcome is too low, ask yourself: Am I in control to influence the factors? If yes - make an effort, and check again. If no, or if after a number of interventions no significant likelihood is garantueed: go and pick another change worth fighting for.... And if you are working for a manager or client: tell them the outcome and tell them NO.
2. A word on Vision.
As a consultant I learned there are two ways to implement change:
1. Design approach
In this case, we approach the required change from a "blueprint" perspective. E.g. we try to work out a model of the to be situation as much as possible, then perform a gap analysis, leading us to actions required to get from the As-is to the To-be
Base assumption: the future can be designed in a blueprint. The vision can be expressed in a model of the desired state.
2. Development approach
In this case, we work with the people to develop, step by step, required change, and implement it, learning from our efforts, and then get on with the next step.
Base assumption: the future is what happens here and now, and we work together, without a blueprint, but with common goals. The vision needs to be expressed in "common ground", and we need to trust and enable people to create results, develop insights and learn/adapt.
Is there a prefered way? No. Use them both, when appropriate.
I am, for some reasons, too impatient to go with 2, hate unclarity and risk, so I love blueprint visions. That hinders me a lot.
However, a key lesson on 1: think about the number of factors you want to include in the blueprint. I often (and still do :-)) tend to include too many factors. Why? Because I find blueprinting so #^&#$! interesting. But I forget the key thing: the blueprint is there to create a direction, a vision and movement. People are better directed with a strong but simple blueprint, then one with 30 factors, covering 20 slides or so... The elephant is eaten in small pieces...
A word on following the change path....
In my naive starting years, I always thought change went like this:
Right. Of course, this was not reality. It was more like...
An important thing I learned was: if the path of change seems to wander away from the vision, do not immediately start spending lots of energy to push it back. Mischa, a collegue of mine, drew the diagram above and made it suddenly very clear: Groups of people can wander around, and do not follow straight lines. It can cost a LOT of energy (believe me, I learned :-)) to push back. A better way is to see where things are going (and they might suddenly turn...), and only if a certain boundary is crossed, you push back to get them back between the boundary lines.But, how much clarity and detail is needed in the blueprint? As said, I tend to included too many factors, because I like it and gives me a feeling of direction and risk-reduction.
Some lessons here:
- The more factors you stick in, the more energy it will take you to make people see, buy in, and reach the change factor. Links back to likelihood of change....
- The more factors you try to stick in the blueprint, the more factors are likely to change. To my sad realization, I have to admit that even my blueprints are far from the reality that was finally delivered. Lessons on the way and changed circuimstances change the required TO BE, all the time...
So, that's why I am more and more a fan of incremental, iterative change, where we mix design and development approaches and create interim TO BE's that get refined on the way, as shown in the diagram...
Tuesday, April 01, 2008
(Dutch) Onderzoek "BPM in Nederland - 2008" gestart
[This is a dutch message, requesting dutch people to participate in a BPM survey covering BPM in the Netherlands]
Uitnodiging deelname onderzoek “Business Process Management in Nederland - 2008”
Beste lezer,
Graag wil ik je uitnodigen om deel te nemen aan het onderzoek “BPM in Nederland - 2008”, uitgevoerd door de Hogeschool Utrecht in samenwerking met Capgemini.
BPM is een relatief nieuw aandachtsgebied binnen organisaties
Binnen veel organisaties is de aandacht voor processen groeiende. Dit blijkt uit toenemende initiatieven in organisaties rond “Business Process Management”, afgekort als BPM.
Voorbeelden hiervan:
Uitnodiging deelname onderzoek “Business Process Management in Nederland - 2008”
Beste lezer,
Graag wil ik je uitnodigen om deel te nemen aan het onderzoek “BPM in Nederland - 2008”, uitgevoerd door de Hogeschool Utrecht in samenwerking met Capgemini.
BPM is een relatief nieuw aandachtsgebied binnen organisaties
Binnen veel organisaties is de aandacht voor processen groeiende. Dit blijkt uit toenemende initiatieven in organisaties rond “Business Process Management”, afgekort als BPM.
Voorbeelden hiervan:
- Een bank analyseert en documenteert de activiteiten bij het afsluiten van hypotheken
- Een gemeentemedewerker is proceseigenaar “verstrekken bouwvergunningen” en coördineert uitvoering van activiteiten door functionele afdelingen in dit proces
- Een energiebedrijf meet structureel doorlooptijd en tevredenheid bij afhandeling van klachten en zorgt dat deze performance indicatoren binnen bepaalde normen blijven
- Klanten van een telefoonbedrijf vragen een telefoonaansluiting aan via het internet, waarna alle vervolgstappen volautomatisch worden uitgevoerd middels BPM technologie
Vanuit BPM streven organisatie naar wendbare, transparante en efficiënte processen.
De reden hiervoor: organisaties realiseren zich dat procesinrichting een belangrijk onderdeel is in concurrentievermogen en strategie.
Er zijn echter nog vele vragen rond BPM
Wat is BPM? Wat gaat BPM voor jouw organisatie betekenen? Wat doen andere organisaties in Nederland rond BPM en BPM technologie? Met welke resultaten?
Dit zijn essentiële vragen.
Onderzoek rond BPM is nodig, gericht op Nederland
Diverse onderzoeksorganisaties doen marktonderzoek naar BPM om deze vragen te beantwoorden. Echter – dit gebeurt primair buiten Nederland (met name de VS).
Onderzoeksresultaten zijn daarom maar beperkt toepasbaar in Nederland.
Om deze reden voert de Hogeschool Utrecht, in samenwerking met Capgemini, een onderzoek uit naar Business Process Management in Nederland.
Je bijdrage wordt gevraagd (20 minuten van uw tijd)
Om dit onderzoek uit te kunnen voeren hebben wij je hulp nodig.
Voor het onderzoek is een vragenlijst opgesteld die via een internetbrowser eenvoudig kan worden ingevuld.
Invullen duurt ongeveer 20 minuten.
Wil je deze vragenlijst invullen, op basis van je inzicht in BPM bij jouw organisatie?
Je levert daarmee een belangrijke bijdrage aan dit onderzoek.
Deelname levert inzicht op (en kans op een prijs)
Wij hopen uiteraard dat je mee wilt doen. Als deelnemer ontvang je in juni het onderzoeksrapport “BPM in Nederland – 2008”.
Het rapport geeft je inzicht in BPM bij Nederlandse organisaties rond de volgende onderwerpen:
- De huidige toepassing van BPM en ambities van organisaties op BPM gebied
- De resultaten, barrières en succesfactoren bij BPM initiatieven
- Het huidige en geplande gebruik van BPM technologie
Als blijk van waardering wordt elke 30ste deelnemer beloond met een boekenbon. Daarnaast worden nog enkele MP4 spelers verloot onder de deelnemers.
Heb je 20 minuten en wil je aan de slag?
Vul dan onderzoek in – klik hiervoor op de volgende link: http://www.bpmsurvey.nl/
Indien de link niet werkt, kun je het adres van de website http://www.bpmsurvey.nl/ in je browser invullen.
Alvast hartelijk dank voor je bijdrage!
Belangrijk: je kunt de vragenlijst tot uiterlijk 25 april 2008 invullen.
Heb je geen tijd of heb je onvoldoende zicht op BPM binnen je organisatie?
Indien invullen van de vragenlijst niet mogelijk voor je is, kun je dan een ander persoon binnen je organisatie vragen dit onderzoek in te vullen (middels het doorsturen van het adres van deze website: http://www.bpmsurvey.nl/)? Bij voorbaat dank!
Je gegevens en antwoorden worden zorgvuldig gebruikt
Je contactgegevens en antwoorden worden strikt vertrouwelijk behandeld en worden na analyse verwijderd. Het onderzoeksrapport is anoniem en niet herleidbaar tot een organisatie of persoon.
Hopelijk tot ziens op de BPM survey site - http://www.bpmsurvey.nl/
Met vriendelijke groet,
Onderzoeksteam “BPM in Nederland – 2008”
Tom Kastelein – Hogeschool Utrecht
Roeland Loggen – Capgemini Nederland BV
Friday, March 14, 2008
There must be 50 ways... to view your process
While working with quite of lot of different people in the area of business process management, I am starting to see the value of different viewpoints on various concepts.
One of these concepts is "process". And I want to share with you some of the views I have encountered. All of them have helped me to understand the concept of "process" in different ways, and (from time to time) have prevented me from blindness to certain factors.
Let's list them (and as always - I am very curious on other views you might have!)...
So... hop on the bus, gus!
1. As a transformation from input to output
2. As a operationalization of strategy ("great slides - but let's get to work")
3. As a series of events, activities and decisions (based on business rules)
4. As a social/antropological context for people working/playing together
5. As a means to delight a customer (or scare him/her away)
6. As some "trainable thing" that you can improve forever (faster, quicker, cheaper, better)
7. As something that can be ill, like a patient, and should be diagnosed and cured
8. As something for which you can define targets, then measure it, and steer it
9. As a means for intervention in human and systems activity
10. As a psychology domain, full of emotions, unconscious behaviours and interactions
11. As something (we think) we can model in a process diagram using graphical symbols such as BPMN.
12. As something that is way too complex and too adhoc to model usefully...
13. As something that allows various stakeholders to understand your business
14. As something that gives people context, clarity and safety
15. As something people sometimes cling to "this is the way we have always done it"
16. As something which has historically grown, but nobody can tell me why it is
17. As something you should automate as fast as possible, so you can fire all the people and save a lot of money
18. As something in which SOA/services can be orchestrated
19. Something you can label as best practice and copy to other organisations
20. As something that will always grow into complexity (following the rules of entropy)
21. As a series of resonsible people doing little things, that all added up define your competive edge
22. As something that is compliant to certain laws or certificationrules, or not...
23. As something that you can outsource (or view as your "core competency")
24. As something that can expose you to risk
Well, that's 24. Know more??
One of these concepts is "process". And I want to share with you some of the views I have encountered. All of them have helped me to understand the concept of "process" in different ways, and (from time to time) have prevented me from blindness to certain factors.
Let's list them (and as always - I am very curious on other views you might have!)...
So... hop on the bus, gus!
1. As a transformation from input to output
2. As a operationalization of strategy ("great slides - but let's get to work")
3. As a series of events, activities and decisions (based on business rules)
4. As a social/antropological context for people working/playing together
5. As a means to delight a customer (or scare him/her away)
6. As some "trainable thing" that you can improve forever (faster, quicker, cheaper, better)
7. As something that can be ill, like a patient, and should be diagnosed and cured
8. As something for which you can define targets, then measure it, and steer it
9. As a means for intervention in human and systems activity
10. As a psychology domain, full of emotions, unconscious behaviours and interactions
11. As something (we think) we can model in a process diagram using graphical symbols such as BPMN.
12. As something that is way too complex and too adhoc to model usefully...
13. As something that allows various stakeholders to understand your business
14. As something that gives people context, clarity and safety
15. As something people sometimes cling to "this is the way we have always done it"
16. As something which has historically grown, but nobody can tell me why it is
17. As something you should automate as fast as possible, so you can fire all the people and save a lot of money
18. As something in which SOA/services can be orchestrated
19. Something you can label as best practice and copy to other organisations
20. As something that will always grow into complexity (following the rules of entropy)
21. As a series of resonsible people doing little things, that all added up define your competive edge
22. As something that is compliant to certain laws or certificationrules, or not...
23. As something that you can outsource (or view as your "core competency")
24. As something that can expose you to risk
Well, that's 24. Know more??
Tuesday, March 11, 2008
(Dutch only) Hulp gevraagd! BPM onderzoek gaande.
Hallo lezers,
Ik heb een verzoek.
Ik ben betrokken bij een onderzoek vanuit de Hogeschool Utrecht rond business process management (BPM) (ik begeleid hierbij een stagiare, sponsor is Capgemini, mijn werkgever).
Doel van het onderzoek is inzicht te krijgen in...
- De huidige activiteiten en plannen van bedrijven rond BPM
- De "maturity" van de BPM activiteiten
- De huidige en geplande inzet van BPM technologie
- Succes en faalfactoren rond BPM en BPM technologie
Mijn vraag aan jullie - ik ben op zoek naar mensen (uit bepaalde doelgroepen) die onze online enquete willen gaan invullen. Duurt ongeveer 20 minuten en er zijn "perks" - kans op wat prijzen (IpodTouch, boeken rond BPM).
En uiteraard een uniek inzicht in de ontwikkelingen rond BPM in Nederland (BPM onderzoeken zijn nog niet eerder op deze schaal in NL gedaan!).
We zoeken met name bedrijven (andere ook welkom):
- > 500 medewerkers
- In Nederland gevestigd
- In branches Financieen, Overheid, Telecom, Utilities ofbeursgenoteerd
En in die bedrijven zoeken we met name:
- CIO's of Informatie managers
- BPM afdelingshoofden
- Afdelingshoofden Processen & Organisatie
- Business en IT consultants bezig met BPM en/of BPM technologie
Als je zelf iemand bent, of mensen kent die aan deze criteria voldoen en je wilt ons helpen, dan verzoek ik je:
- Ofwel mij (roeland punt loggen apestaartje capgemini punt com) de contactgegevens van jezelf of deze mensen te sturen:
- Naam
- Organisatie
- Functie
- Emailadres
- Ofwel deze email door te sturen naar mensen die mogelijk geinteresseerd zijn in dit onderzoek en de uitkomsten ervan, en ze te vragen aan mij hun contactgegevens door te sturen (en laat ze jouw naam noemen).
Mijn dank zou groot zijn - mensen die ons hierbij helpen zal ik ook op de prijstrekking-lijst zetten.
NB: Deze contactgegevens zullen ALLEEN gebruikt worden voor het verzenden van het enqueteverzoek en zullen na verzending van enqueteresultaten worden verwijderd.
Alvast bedankt,
Met vriendelijke groet,
Roeland Loggen
Ik heb een verzoek.
Ik ben betrokken bij een onderzoek vanuit de Hogeschool Utrecht rond business process management (BPM) (ik begeleid hierbij een stagiare, sponsor is Capgemini, mijn werkgever).
Doel van het onderzoek is inzicht te krijgen in...
- De huidige activiteiten en plannen van bedrijven rond BPM
- De "maturity" van de BPM activiteiten
- De huidige en geplande inzet van BPM technologie
- Succes en faalfactoren rond BPM en BPM technologie
Mijn vraag aan jullie - ik ben op zoek naar mensen (uit bepaalde doelgroepen) die onze online enquete willen gaan invullen. Duurt ongeveer 20 minuten en er zijn "perks" - kans op wat prijzen (IpodTouch, boeken rond BPM).
En uiteraard een uniek inzicht in de ontwikkelingen rond BPM in Nederland (BPM onderzoeken zijn nog niet eerder op deze schaal in NL gedaan!).
We zoeken met name bedrijven (andere ook welkom):
- > 500 medewerkers
- In Nederland gevestigd
- In branches Financieen, Overheid, Telecom, Utilities ofbeursgenoteerd
En in die bedrijven zoeken we met name:
- CIO's of Informatie managers
- BPM afdelingshoofden
- Afdelingshoofden Processen & Organisatie
- Business en IT consultants bezig met BPM en/of BPM technologie
Als je zelf iemand bent, of mensen kent die aan deze criteria voldoen en je wilt ons helpen, dan verzoek ik je:
- Ofwel mij (roeland punt loggen apestaartje capgemini punt com) de contactgegevens van jezelf of deze mensen te sturen:
- Naam
- Organisatie
- Functie
- Emailadres
- Ofwel deze email door te sturen naar mensen die mogelijk geinteresseerd zijn in dit onderzoek en de uitkomsten ervan, en ze te vragen aan mij hun contactgegevens door te sturen (en laat ze jouw naam noemen).
Mijn dank zou groot zijn - mensen die ons hierbij helpen zal ik ook op de prijstrekking-lijst zetten.
NB: Deze contactgegevens zullen ALLEEN gebruikt worden voor het verzenden van het enqueteverzoek en zullen na verzending van enqueteresultaten worden verwijderd.
Alvast bedankt,
Met vriendelijke groet,
Roeland Loggen
Sunday, March 09, 2008
Process footprint - a new, green, element in BPM
Interesting - the link between BPM and the Green movement is there.
I stumbled on...
http://greenbpm.com/
and
http://www.global360.com/collateral/blog_articles/greenbpm.pdf
When definining and analysing processes I typically look at:
- Effectiveness/alignment with strategy
- Performance/Efficiency (cost, lead time, etc)
- Profitability
- Agility
- Compliance
- Customer satisfaction
- Employer satisfaction
I will add a new one: the environmental footprint of a process. As a logic extension of the efficiency - can we optimize the process in such a way, that we minimize the impact of environment..
For the dutch readers:
It made me realize that the COPAFIJTH abbrevation (see older post) for making sure all aspects of a change are thought through, needs an extension. Let's start talking about COMPAFIJTH! (Milieu as integral part of any change effort).
I stumbled on...
http://greenbpm.com/
and
http://www.global360.com/collateral/blog_articles/greenbpm.pdf
When definining and analysing processes I typically look at:
- Effectiveness/alignment with strategy
- Performance/Efficiency (cost, lead time, etc)
- Profitability
- Agility
- Compliance
- Customer satisfaction
- Employer satisfaction
I will add a new one: the environmental footprint of a process. As a logic extension of the efficiency - can we optimize the process in such a way, that we minimize the impact of environment..
For the dutch readers:
It made me realize that the COPAFIJTH abbrevation (see older post) for making sure all aspects of a change are thought through, needs an extension. Let's start talking about COMPAFIJTH! (Milieu as integral part of any change effort).
From current BPM patterns to the future patterns of BPM technology....
I read a number of recent postings on the various "BPM technology patterns":
http://www.bpm.com/FeatureRO.asp?FeatureId=242 (bij Peter Fingar) and http://www.global360.com/blog/index.php/2008/03/04/prevalent-process-patterns-enable-bpm-benefits-differently/ (by Jim Sinur).
(updated: Sandy - www.column2.com - pointed to the correct article on BPM.com that I actually intented to link to. Thanks!)
Interesting typology of various BPM technology patterns - but, in my view incomplete and (a bit) outdated. STP, Workflow and Casemanagement is stuff that we understand now.
My interest is:
- What other (future) types of BPM technology patterns can we see ?
- How are the various patterns positioned?
To answer the second question, I tried to create a model, based on two dimensions.
See the following diagram:
http://www.bpm.com/FeatureRO.asp?FeatureId=242 (bij Peter Fingar) and http://www.global360.com/blog/index.php/2008/03/04/prevalent-process-patterns-enable-bpm-benefits-differently/ (by Jim Sinur).
(updated: Sandy - www.column2.com - pointed to the correct article on BPM.com that I actually intented to link to. Thanks!)
Interesting typology of various BPM technology patterns - but, in my view incomplete and (a bit) outdated. STP, Workflow and Casemanagement is stuff that we understand now.
My interest is:
- What other (future) types of BPM technology patterns can we see ?
- How are the various patterns positioned?
To answer the second question, I tried to create a model, based on two dimensions.
See the following diagram:
It tries to map out BPM patterns on:
1. The process - how structured is it?
With "structured" I mean processes that we can map out, in terms of predictable events, activities and business rules. Based on incoming data (from events and activities) during the execution of the proces, certain activities are performed and decision rules determine the flow. Example: quoting a new car insurance.
With semi-structured I mean processes that are more tricky to model - some of the business rules can not be formalized and stay in the head of people as knowledge. And some of the events might not be predictable.
Example: trying to decide on a complex insurance claim
Unstructured are processes (if we can still speak of process) in which in advance very little can be said on flow, events, activities and business rules.
Example: the way I clean my house ;-)
2. Who is performing the process?
In some cases processes can be fully performed by a computer, based on predefined rules and transactions.
Other processes need human activity, based on certain knowledge and the realisation that life is more fuzzy than a computer can handle (at this stage). We can see processes in which there is most of the time one person in the lead, performing work without a lot of communication during the execution of the activity. There could be more people involved but either they are working serially or they are working on separate process parts without direct contact.
And most complex are processes where people are collaborating together at the same time, working together on performing activities, making decisions, etc.
Now, if we use these two dimensions, one can map out a number of BPM patterns...
First the well-understood patterns ...
STP - Straight Through Processing - in which a computer fully handles the execution of a process. No people involved, hands-off. Great business case for high volume, low revenue transactions.
E-Forms - this is my entry level workflow. People fill in eForms, which are send around for approval, with not much (complex) integration or complex business rules. Think - reserving parkingspaces or rooms.
Workflow - this is the typical inbox, task, form, more complex business rules and back-end integration, with some process monitoring on top. Great business case for process control, compliance, worker-support and efficiency.
Case management - a lot of discussion on the defition on this one. My view: automated process support where one can perform tasks in any order, skip tasks, add tasks. Usually quite data & document centric. Great for loosely structured processes, where we want to keep control, and support the knowledge worker with a one-stop place for all work to be done, data, documents and activity-history.
Groupware - all solutions that enable sharing information (Wiki's, email, discussion boards). Very handy, but unfortunately it creates a lot of "setup time" every time you dive into one of these components, because the process context often is missing or is not easy to establish (what't this about? what't the status? what's expected of me, now?)
Automated BPM patterns of the future
I see CEP (Complex Event Processing) as a new area, that might grow into a BPM pattern that can support complex interrelated processes. Think inter-process coordination (don't process a new policy, if we just got word that the client is in financial trouble) and more complex rule based event driven stuff (analyse this cloud of data, and determine appropriate pre-defined actions, that need to be started)
Agents and AI will provide possibilities to go even further. I am thinking of self-learning systems, that can formulate a process, based on clouds of data/events, perform it, and if needed adjust it....
Then - Collaborative BPM patterns of the future
What happens if you have a process which requires many people to work together to perform a process? Currenly we know the answer - manually planning of meetings, meeting minutes/recording of decisions, and email - lot's of email.
Typical "knowledge worker" processes are currently not well supported by BPM technology. We are far from the "high performance workplace".
Some patterns I see:
Collaborative BPM
Process engines that support working together around a structured process: automatically planning a meeting, calling a client, opening and recording a chat/IM session. All still activity focused - making sure the process can finish.
(Note: Collaborative BPM is also used as a "design time" concept, in "together defining a procesmodel")
HIMS
Wilder stuff. Process engines and collaboration platforms that can handle less structured processes in the form of "processes on the fly" with "stories" that the group can create, evolve and finish. Where messaging is structured (assignments, decisions, data). See the thoughts around "Human Interaction Management".
CEBP
A platform that would enable users to manage all communication around a process as well. Unified, connected to the process as context. Could probably support both CBPM and HIMS.
I see a platform in which I...
- Can manage my presence (for these types of processes, please contact me via phone of IRL unless it's weekend, than only contact me if status is RED, via SMS)
- Can route voicemails, calls, emails, documents, linked to a certain process context and activity context
It this still vague? You bet. I don't know where it's going - but I can see that the current IT support for working together is not sufficient. That troubling me. .. the growth in information overload, the growth in "setup time" to get (re)started, and the economic reality that productivity improvement in knowledgeworkers intensive processes has not significantly grown, while this area of work (services) is outgrowing manufacturing by the day...
To compete in the next 20 years, something will need to be done...
Let's check in 5 years!
Friday, February 01, 2008
Key skills on a BPM technology project
The last year, while doing BPM technology projects, I learned a number of lessons on skillsets that you will need on a BPM project. Some lessons the hard way (e.g. missing them, and needing to fight for them :-)).
Let's take a "typical" BPM technology project where...
- A company wants to improve certain processes (think efficiency, visibility and agility)
- A project has been started that tries to tackle this from two sides:
1. BPM as a set of process interventions (proces analysis, design, and implementation of a new operating model around processes - ranging from process ownership, measurements/KPI's to improving the process awareness end to end, and breaking functional silos)
2. Introducing BPM technology (I prefer to call this BPMS or BPM technology, instead of just BPM, to avoid confusion - some people unfortunately still think you can do BPM with only this 2nd item...). Think BPM Suite, maybe a Portal, maybe some ECM/Document management, some or much back end integration, realizing a mix of use cases around human centric workflow, straight through processing and business/process intelligence.
I found the following skills extremely needed:
1. Projectmanagement
2. Changemanagement
3. Process analist and processdesigner, with Lean/Six Sigma skills
4. Requirements/Functional analist
5. Business intelligence specialist
6. Interaction design/usability specialist
7. Solution architect
8. BPM technology/development infrastructure specialist
9. Software engineers
10. Testing specialists
Some remarks per skillset:
1. Projectmanagement
Managing scope, expectations, budget, timeline and issues. The usual. Someone that knows how to let things get done!
2. Changemanagement
BPM in the end is about people working in new ways. You will need skills on your team to be able to involve people, get ideas, stimulate thinking and collaboration, identify risks, etc.
I am not a proponent of the typical "changemanagement" concepts as "communicate" "train" "push down their throats".... What I mean is people that can build a process culture, where people are valued and are actively involved in making their daily joblife meaningfull, fun and effective. I am thinking of the Toyota culture here..
3. Process analist/designer
Analysing processes is a skill. A skill that in the end more and more people in your business should possses, but in the beginning you will need to have a specialist here - don't try this on your own. I am thinking of someone with Lean Six Sigma skills, that can work with key stakeholders in analysing and designing processes. Preferably someone that can teach the people involved how to keep this going themselves for process refinements
4. Requirements analist/Functional designer
Again, being able to look at a new process and translate it to a meaningfull set of software requirements is a skill. You will need someone that understands possibilities of modern technology such as BPM, Portals, Web 2.0, etc. If possible, find someone that is also able to translate requirements into solutions. Of course this person also finds and details business rules.
5. Business/process intelligence specialist
How do you measure a process? What does need to be measured? How will you present the information to people? How will this enable them to steer and control processes? Key questions that a BI/Process intelligence specialist should be able to answer, leading to data/reporting requirements
6. Interaction design/Usability specialist
Unfortunately, with the whole BPM thinking, some people believe that applying BPM is simply defining a process, defining forms that end up in people's inbox, and voila, BPM is running.
It reminds me of the horrible user interfaces we ended up with, when working with IT people doing prototype sessions and building client-server apps. No!
Realize - the user interface of your BPM solution will give people feelings (about your company and your brand) and has a immense influence on their ability to work and trust the solution. I have seen interaction designers that have created wonderfull easy effective user interfaces, thet people loved!
The funny thing is also: during your BPM project you will need to keep selling your projectgoals and future system. Do you think CEO's and users get impressed with your service bus based, SOA super duper EDA CEP Agile BPM solution? I think not. But you can reach out to them with a good user interface - crystal clear...
7. Solution architect
The person that is able to understand the processes, requirements and functional design, have an overview of the backend systems and all technology layers and stacks, and come up with a firm architecture. A person that can guide the engineers and make sure quality is delivered.
8. BPM & development technology specialist
This new BPM technology is new stuff. Many settings, many known bugs. You will run into problems. Don't let your solution architect or engineers get bogged down with this stuff - get someone in with close ties to the vendor. Let this person (or another) also create the best development environment - source control/config management, automatic builds & automatic testscripts execution, deployments, server maintenance, etc.
9, Software Engineers
This is the gold in your team - the people that actually create working software (and that's in the end what is all boils down to, right?). Depending on the scope you might see various skillsets centralized or distributed in your team: people that can magically connect to backend systems and understand transactions, services, etc. People that can build user interfaces. And people that understand how to translation process data to meaningfull BI solutions.
10. Testing specialist
If you use TDD, then you might be able to combine this with 9. But in general, you will often need testingspecialists on your team. And realize - this is not trivial testing. You will need testers that are able to test end-to-end processes from a process, functional and non-functional perspective.
Hope this helps! If you are about to start a BPM technology project, use this as a checklist. And realize - if you ommit some of these skills, the issues and activities will not go away, but simply haunt you during the project....
Let's take a "typical" BPM technology project where...
- A company wants to improve certain processes (think efficiency, visibility and agility)
- A project has been started that tries to tackle this from two sides:
1. BPM as a set of process interventions (proces analysis, design, and implementation of a new operating model around processes - ranging from process ownership, measurements/KPI's to improving the process awareness end to end, and breaking functional silos)
2. Introducing BPM technology (I prefer to call this BPMS or BPM technology, instead of just BPM, to avoid confusion - some people unfortunately still think you can do BPM with only this 2nd item...). Think BPM Suite, maybe a Portal, maybe some ECM/Document management, some or much back end integration, realizing a mix of use cases around human centric workflow, straight through processing and business/process intelligence.
I found the following skills extremely needed:
1. Projectmanagement
2. Changemanagement
3. Process analist and processdesigner, with Lean/Six Sigma skills
4. Requirements/Functional analist
5. Business intelligence specialist
6. Interaction design/usability specialist
7. Solution architect
8. BPM technology/development infrastructure specialist
9. Software engineers
10. Testing specialists
Some remarks per skillset:
1. Projectmanagement
Managing scope, expectations, budget, timeline and issues. The usual. Someone that knows how to let things get done!
2. Changemanagement
BPM in the end is about people working in new ways. You will need skills on your team to be able to involve people, get ideas, stimulate thinking and collaboration, identify risks, etc.
I am not a proponent of the typical "changemanagement" concepts as "communicate" "train" "push down their throats".... What I mean is people that can build a process culture, where people are valued and are actively involved in making their daily joblife meaningfull, fun and effective. I am thinking of the Toyota culture here..
3. Process analist/designer
Analysing processes is a skill. A skill that in the end more and more people in your business should possses, but in the beginning you will need to have a specialist here - don't try this on your own. I am thinking of someone with Lean Six Sigma skills, that can work with key stakeholders in analysing and designing processes. Preferably someone that can teach the people involved how to keep this going themselves for process refinements
4. Requirements analist/Functional designer
Again, being able to look at a new process and translate it to a meaningfull set of software requirements is a skill. You will need someone that understands possibilities of modern technology such as BPM, Portals, Web 2.0, etc. If possible, find someone that is also able to translate requirements into solutions. Of course this person also finds and details business rules.
5. Business/process intelligence specialist
How do you measure a process? What does need to be measured? How will you present the information to people? How will this enable them to steer and control processes? Key questions that a BI/Process intelligence specialist should be able to answer, leading to data/reporting requirements
6. Interaction design/Usability specialist
Unfortunately, with the whole BPM thinking, some people believe that applying BPM is simply defining a process, defining forms that end up in people's inbox, and voila, BPM is running.
It reminds me of the horrible user interfaces we ended up with, when working with IT people doing prototype sessions and building client-server apps. No!
Realize - the user interface of your BPM solution will give people feelings (about your company and your brand) and has a immense influence on their ability to work and trust the solution. I have seen interaction designers that have created wonderfull easy effective user interfaces, thet people loved!
The funny thing is also: during your BPM project you will need to keep selling your projectgoals and future system. Do you think CEO's and users get impressed with your service bus based, SOA super duper EDA CEP Agile BPM solution? I think not. But you can reach out to them with a good user interface - crystal clear...
7. Solution architect
The person that is able to understand the processes, requirements and functional design, have an overview of the backend systems and all technology layers and stacks, and come up with a firm architecture. A person that can guide the engineers and make sure quality is delivered.
8. BPM & development technology specialist
This new BPM technology is new stuff. Many settings, many known bugs. You will run into problems. Don't let your solution architect or engineers get bogged down with this stuff - get someone in with close ties to the vendor. Let this person (or another) also create the best development environment - source control/config management, automatic builds & automatic testscripts execution, deployments, server maintenance, etc.
9, Software Engineers
This is the gold in your team - the people that actually create working software (and that's in the end what is all boils down to, right?). Depending on the scope you might see various skillsets centralized or distributed in your team: people that can magically connect to backend systems and understand transactions, services, etc. People that can build user interfaces. And people that understand how to translation process data to meaningfull BI solutions.
10. Testing specialist
If you use TDD, then you might be able to combine this with 9. But in general, you will often need testingspecialists on your team. And realize - this is not trivial testing. You will need testers that are able to test end-to-end processes from a process, functional and non-functional perspective.
Hope this helps! If you are about to start a BPM technology project, use this as a checklist. And realize - if you ommit some of these skills, the issues and activities will not go away, but simply haunt you during the project....
Subscribe to:
Posts (Atom)