Forrester Reports on BPM
Our good friends at Forrester have released a free report called 'The EA View: BPM has become Mainstream" by Ken Vollmer. It is a wide ranging but quite detailed report summarising research and surveys carried out at the back end of last year.
It's worth a read if you have the time.
However, it does fall prey to a couple of the things that are personal bugbears for me when it comes to processes and BPM
1) It surveys what people are currently doing rather than what is the right way to do things. In an environment where many different people are doing things different ways, and in a maturing market, there will always be different ways of doing things, some right, some wrong. A report like this does not include any recommendations on which is the most effective way of doing things, rather what current people are doing. How am I supposed to know if I'm doing things the best way in that case? For example it mentions that the top two most widely used BPM vendors are IBM and Microsoft. Now the last time I looked, both of these companies where in the operating system/ software business and one of them was in the hardware business. Are they really the best companies to use for BPM work? Maybe the are (and this is said with no prejudice at all towards these two companies), but just because they are the biggest doesn't necessarily mean they are the right ones to use. (Interestingly it was mentioned that on average each respondent to the survey was using 3.5 BPM vendors. Another interesting statistic)
2) It talks about metrics giving details of which metrics are used to measure BPM success. From my post on Comerford's Three Laws of Metrics you will no doubt remember that I said (amongst other things) "Metrics for the sake of metrics are a waste of time". Looking at the Forrester list I see that the top 4 items were Process cycle times, customer satisfaction, risk reduction and process error rates. Of these four I, personally, feel that process error rates and cycle times are metrics for the sake of metrics. Why would you want to measure the fact that your process is producing a number of errors? Does it matter? (Of course it matters, but the question is what percentage of the processes are producing errors? That's a more useful measure). Cycle time is also another misleading entry. Why would you measure the fact that your process cycle is now 45 minutes? So what? A more effective measure would be cycle time reduction. 'My cycle is now 70% quicker than previously'. That adds value and that's the sort of thing that would look good on a management dashboard. Interestingly enough 5% of major companies over $1b revenue were not measuring their BPM success
As I mentioned earlier, this is worth a few minutes of your time to read and digest.
But as with all 'survey based findings' take the results with a pinch of salt.
Visio - The Devil's Tool
In a recent post I talked about the elements of a good process model. Or more particularly an effective process model.
But surely a process model is whatever it is supposed to represent? By that I mean 'Can't we put whatever needs to be put into a process model to make it do the job it's supposed to?'
The short answer is "Yes"
The long answer is "Absolutely not!"
If you're putting together some sort of diagram that can explain or illustrate something to users (whether these are existing users or potential new users), you need to make the diagram as clear and informative as possible. This means adding in (or subtracting) whatever information will help you achieve that. In many cases this means a process modeling package is not the appropriate tool. Visio probably is.
I've spoken before on this site about the use of Visio for process modeling (and, incidentally there is a section on this in the new eBook I am writing 'The Perfect Process Project"). To recap, my advise is "Don't use Visio for Process Modeling".
However, as a communication device that can show lots of unconnected things in a clear, visual manner, Visio is an excellent tool. Remember, though, that it is a drawing tool not a modeling tool. The diagram you draw in Visio should be based on an existing carefully modeled process from within the modeling tool of your choice.
With Visio you can add in little figures to represent your users, you can format the model to ignore good process notation standards, you can drop big chunks of descriptive text all over your diagram. In short it is the correct tool for putting something out there that is informative without being totally accurate (and by accurate I mean referring to established notation standards).
However I would advise against this.
The reason is simple: Expectation setting.
If you make it clear or known to your users that within your project it is acceptable to produce non-standard process models, then this expectation will then have to be met and managed. Similarly, if you make it known to your project that it is acceptable to define and manage process models in a drawing tool rather than a modeling tool then this expectation will also have to be met and managed.
It's all very easy to say "I know Visio, I can use it. Everyone in my organisation can use it and it's cheap (at least compared with most Process Modeling tools on the market at the moment)" But remember the objective of your project is to define & manage your processes as well as to produce the pictures that illustrate these.
Experience has taught me that letting inexperienced users draw their 'processes' in Visio is a recipe for disaster.
Don't do it.
You will end up with non-standard diagrams, superfluous objects, lack of consistency, missing notation standards and other similar issues.
You will also end up with a set of pieces of paper that are not connected, diagrams that don't link, activities that are repeated but named differently, deliverables that are missing from one diagram but appear in other diagrams and a myriad of similar issues.
Don't do it!
But surely a process model is whatever it is supposed to represent? By that I mean 'Can't we put whatever needs to be put into a process model to make it do the job it's supposed to?'
The short answer is "Yes"
The long answer is "Absolutely not!"
If you're putting together some sort of diagram that can explain or illustrate something to users (whether these are existing users or potential new users), you need to make the diagram as clear and informative as possible. This means adding in (or subtracting) whatever information will help you achieve that. In many cases this means a process modeling package is not the appropriate tool. Visio probably is.
I've spoken before on this site about the use of Visio for process modeling (and, incidentally there is a section on this in the new eBook I am writing 'The Perfect Process Project"). To recap, my advise is "Don't use Visio for Process Modeling".
However, as a communication device that can show lots of unconnected things in a clear, visual manner, Visio is an excellent tool. Remember, though, that it is a drawing tool not a modeling tool. The diagram you draw in Visio should be based on an existing carefully modeled process from within the modeling tool of your choice.
With Visio you can add in little figures to represent your users, you can format the model to ignore good process notation standards, you can drop big chunks of descriptive text all over your diagram. In short it is the correct tool for putting something out there that is informative without being totally accurate (and by accurate I mean referring to established notation standards).
However I would advise against this.
The reason is simple: Expectation setting.
If you make it clear or known to your users that within your project it is acceptable to produce non-standard process models, then this expectation will then have to be met and managed. Similarly, if you make it known to your project that it is acceptable to define and manage process models in a drawing tool rather than a modeling tool then this expectation will also have to be met and managed.
It's all very easy to say "I know Visio, I can use it. Everyone in my organisation can use it and it's cheap (at least compared with most Process Modeling tools on the market at the moment)" But remember the objective of your project is to define & manage your processes as well as to produce the pictures that illustrate these.
Experience has taught me that letting inexperienced users draw their 'processes' in Visio is a recipe for disaster.
Don't do it.
You will end up with non-standard diagrams, superfluous objects, lack of consistency, missing notation standards and other similar issues.
You will also end up with a set of pieces of paper that are not connected, diagrams that don't link, activities that are repeated but named differently, deliverables that are missing from one diagram but appear in other diagrams and a myriad of similar issues.
Don't do it!
Safety in the Skies
I've picked this up at a couple of places on the web and it's worth repeating.
A recent article at the BBC told the story of whistle-blower in Air Traffic Control who claimed that the controllers are deliberately sequencing aircraft closer than is necessary in order to meet targets for aircraft movements. He claims this is common-place and potentially impacts safety.
This is interesting for a couple of reasons.
1) From a process point of view, the process allows controllers leaway to do this sort of thing (apparently with the collusion of their management). Is this a process issue? Should there be stronger controls? Is the procedure designed well enough?
2) From a flying point of view, are we comfortable that the system can deal with aircraft being this close? I know that on several occasions flying in to Heathrow as a commercial passenger the aircraft has had to go-around because the plane in front hasn't vacated the runway yet. The go-around procedure is meant for just such an eventuality, but to need to do this due to air traffic issues is stretching a point, I feel.
So as a passenger would you rather arrive on time, but in a potentially risky situation, or later than advertised but safer? I know where my vote is going
Any thoughts or comments from you?
A recent article at the BBC told the story of whistle-blower in Air Traffic Control who claimed that the controllers are deliberately sequencing aircraft closer than is necessary in order to meet targets for aircraft movements. He claims this is common-place and potentially impacts safety.
This is interesting for a couple of reasons.
1) From a process point of view, the process allows controllers leaway to do this sort of thing (apparently with the collusion of their management). Is this a process issue? Should there be stronger controls? Is the procedure designed well enough?
2) From a flying point of view, are we comfortable that the system can deal with aircraft being this close? I know that on several occasions flying in to Heathrow as a commercial passenger the aircraft has had to go-around because the plane in front hasn't vacated the runway yet. The go-around procedure is meant for just such an eventuality, but to need to do this due to air traffic issues is stretching a point, I feel.
So as a passenger would you rather arrive on time, but in a potentially risky situation, or later than advertised but safer? I know where my vote is going
Any thoughts or comments from you?
Tips for effective process modeling
Bruce Silver at the BPMN Institute has posted a number of tips about effective process modeling which is a topic very dear to my heart. I've worked with lots of companies that think that if you can drop it into a Visio model it is a good process, without understanding key fundamental issues associated with this. As Bruce says:
Bruce does make one comment which I'm not totally aligned with. He believes that everything on your model should be labelled, not just activities, but subprocesses, intermediate events, gateways, sequence flows, end events and message flows. Up to a point I agree with this but I actually believe that a process model consists of two things:
But with that caveat I would heartily recommend Bruce's article to you.
Remember "Verb Noun"!
The BPMN specification presents lots of technical definitions and rules, but it does not teach you how to create process models that are effective in their primary mission - maximizing shared understanding of the as-is or to-be process. To do process modeling effectively, you need to go beyond the spec and learn a basic methodology, best practices, and specific diagram patterns to use in common situations.The other key point he makes in his article is
While the diagram is the key output, a process model is more than a drawing, and a modeling tool is more than a drawing tool. A real modeling tool has the semantics and rules of BPMN baked in, and gives you a Validate button that can display a list of errors when you violate the spec. A free BPMN stencil in Visio can’t do that.Some of my particular favourite tips are #3 (Make your model hierarchical) and #4 (Label your activities 'Verb/noun") . Both of these are things I constantly have to remind my clients.
Bruce does make one comment which I'm not totally aligned with. He believes that everything on your model should be labelled, not just activities, but subprocesses, intermediate events, gateways, sequence flows, end events and message flows. Up to a point I agree with this but I actually believe that a process model consists of two things:
- The diagram: This is the model you have created with all it's boxes, shapes and flows
- The supporting documentation of the diagram: This is the textual interpretation of the diagram which includes items such as descriptions, timings, resource uasge etc. Putting all of this on a diagram would be counterproductive, I feel.
But with that caveat I would heartily recommend Bruce's article to you.
Remember "Verb Noun"!
The art of process facilitation
In the heat of a project it's always difficult to remember why we are doing process work. It's even more difficult to try and work through process definition while under a time deadline (and you're usually under a time deadline of some sort).
Process facilitation is a method of coming into an environment and doing the appropriate things to understand what the process is. Usually this occurs with various participants in the room and someone facilitating the process.
The art of the facilitator is something of a black one. Good facilitators can get you to where you want to be without a great deal of difficulty, exploring different avenues along the way but ultimately ending up at the correct destination. Unfortunately there aren't a great number of good process facilitators out there.
So if you are stuck with having to facilitate a process out of a group of people, here are 8 tips to help the facilitation process go a lot smoother.
1) Get all the right people in the room.
Get the folks who actually do this role into a room. Get the folks who feed into this process and the folks who receive the output from this process. Differing points of view are good in this case. Don't get managers or supervisors or senior vice presidents in there. You want people who know the process and can answer the questions you ask quickly.
2) Get rid of the 'system'.
Get your attendees to understand that we are not interested at the moment in 'what the system does'. Designing a process around 'what the system does' is a sure-fire way of locking you in to the things a particular system is capable of. When your business model changes (as it will) you'll need to get a different system and redefine your processes. Design a process that is system independent and you can change systems without changing process. The key question to keep asking yourself in this case is 'If we had to do this with paper and pencil what would the process steps be?'
3) Go round in circles for a while.
No-one knows what their process is. They know what their own procedure is. The know what they do on a day to day basis. This isn't a process. The process is how things happen at a macro level. (Try and find me an IT process for 'purchasing and configuring a new PC'. There isn't one. There are processes for procuring hardware, for installing software, for updating asset inventories, but not purchasing and configuring a PC. What you have at that level is a procedure for doing this. The trick is in extracting the process from the procedure. This will be iterative, so do it, go on, learn something new and different later on, then come back and see how that affects your 'process'.
4) Forget a tool to help you.
Too many people get hung-up on making sure they have an appropriate tool for mapping their processes during the facilitation sessions. Forget about it. Use brown paper and post-it notes. Get folks to throw things up there and then see what happens when you step back and look at things. When you're happy with the final product, photograph all your post-it and then transpose them into a tool of some sort. I had a group once consisting of three departments in a functional area. They all swore blind they had their own processes for doing a particular activity. I got them each to map their processes using brown paper and post-it notes on a wall. When we stood back we found out that they are actually all doing parts of a bigger process and that was the process we needed to understand. There was a visible 'Ah Ha!' moment in the room when this was shown. It took a couple of hours and involved several iterations, none of which would have been possible with any of the current tools on the market. After that we were able to drop our process into a BPA tool and print out pristine copies for everyone. The tool shouldn't drive your process!
5) Identify the inputs and outputs.
For every input work out where it comes from. For every output work out where it goes to. If you can't identify these things then remove the offending input/output. If your process is not producing something that is needed (such as a legal report) then your process needs changing or the legal report is not needed. If your process is producing a report for a manager and that manager is not doing anything with it then that output (and associated process step) can be removed. Working with another group who were looking at quoting for services to support an external piece of work, we found that early on in the project the baseline quote was sent to finance. I asked Finance what they did with it and they said 'Nothing, we can't use the baseline quote, only the agreed quote'. We removed that step from the process, sped up the cycle time and made sure that the agreed quote was delivered to the finance group when they could make use of it.
6) Make sure you understand terminology.
I love going into environments where I am unfamiliar with the work that is performed there. This means I have no preconception of the final product and can ask the dumb questions that more familiar people wouldn't do. But the downside to this is that words get thrown around that other people understand that I don't. As a result I tend to create a Glossary as we go through. I get folks to explain terms they use and clarify this with other people in the room to ensure they understand the terminology too. There's nothing worse than spending 30 minutes discussing a process point than finding out that when Finance talked about 'Credit reports' they meant the reports that are produced on a monthly basis to send to customers with their outstanding balance, but Management Accounting understood Credit Reports to mean official feedback from an accredited agency detailing the risk of giving credit to a potential customer. Create a glossary and get everyone on the same page. Also do this with your nomenclature. explain concepts such as the meaning of a process, procedure, task, and activity.
7) Take your time.
This is not a quick process. Allow at least a day for a small process and up to week for a large process. Don't rush things or you will cut corners. If your key participants have to leave at a certain time and you're not finished, don't speed up to get things done before they leave, arrange a follow on session. If this is important enough to do it's important enough to do correctly.
8) Use the Hype Cycle.
The Gartner Group have a concept know as a Hype Cycle. it explains the various stages that new technology goes through from it's introduction to it's integration into society as a meaningful piece of hardware (or concept). I have found that process facilitation sessions tend to follow a similar, but accelerated Hype Cycle.
Process facilitation is not rocket science. It's actually fairly straightforward. Remember the 8 key's listed above and you'll be a process ninja in no time!
Or do you think otherwise....? Let me know in the comments.
Process facilitation is a method of coming into an environment and doing the appropriate things to understand what the process is. Usually this occurs with various participants in the room and someone facilitating the process.
The art of the facilitator is something of a black one. Good facilitators can get you to where you want to be without a great deal of difficulty, exploring different avenues along the way but ultimately ending up at the correct destination. Unfortunately there aren't a great number of good process facilitators out there.
So if you are stuck with having to facilitate a process out of a group of people, here are 8 tips to help the facilitation process go a lot smoother.
1) Get all the right people in the room.
Get the folks who actually do this role into a room. Get the folks who feed into this process and the folks who receive the output from this process. Differing points of view are good in this case. Don't get managers or supervisors or senior vice presidents in there. You want people who know the process and can answer the questions you ask quickly.
2) Get rid of the 'system'.
Get your attendees to understand that we are not interested at the moment in 'what the system does'. Designing a process around 'what the system does' is a sure-fire way of locking you in to the things a particular system is capable of. When your business model changes (as it will) you'll need to get a different system and redefine your processes. Design a process that is system independent and you can change systems without changing process. The key question to keep asking yourself in this case is 'If we had to do this with paper and pencil what would the process steps be?'
3) Go round in circles for a while.
No-one knows what their process is. They know what their own procedure is. The know what they do on a day to day basis. This isn't a process. The process is how things happen at a macro level. (Try and find me an IT process for 'purchasing and configuring a new PC'. There isn't one. There are processes for procuring hardware, for installing software, for updating asset inventories, but not purchasing and configuring a PC. What you have at that level is a procedure for doing this. The trick is in extracting the process from the procedure. This will be iterative, so do it, go on, learn something new and different later on, then come back and see how that affects your 'process'.
4) Forget a tool to help you.
Too many people get hung-up on making sure they have an appropriate tool for mapping their processes during the facilitation sessions. Forget about it. Use brown paper and post-it notes. Get folks to throw things up there and then see what happens when you step back and look at things. When you're happy with the final product, photograph all your post-it and then transpose them into a tool of some sort. I had a group once consisting of three departments in a functional area. They all swore blind they had their own processes for doing a particular activity. I got them each to map their processes using brown paper and post-it notes on a wall. When we stood back we found out that they are actually all doing parts of a bigger process and that was the process we needed to understand. There was a visible 'Ah Ha!' moment in the room when this was shown. It took a couple of hours and involved several iterations, none of which would have been possible with any of the current tools on the market. After that we were able to drop our process into a BPA tool and print out pristine copies for everyone. The tool shouldn't drive your process!
5) Identify the inputs and outputs.
For every input work out where it comes from. For every output work out where it goes to. If you can't identify these things then remove the offending input/output. If your process is not producing something that is needed (such as a legal report) then your process needs changing or the legal report is not needed. If your process is producing a report for a manager and that manager is not doing anything with it then that output (and associated process step) can be removed. Working with another group who were looking at quoting for services to support an external piece of work, we found that early on in the project the baseline quote was sent to finance. I asked Finance what they did with it and they said 'Nothing, we can't use the baseline quote, only the agreed quote'. We removed that step from the process, sped up the cycle time and made sure that the agreed quote was delivered to the finance group when they could make use of it.
6) Make sure you understand terminology.
I love going into environments where I am unfamiliar with the work that is performed there. This means I have no preconception of the final product and can ask the dumb questions that more familiar people wouldn't do. But the downside to this is that words get thrown around that other people understand that I don't. As a result I tend to create a Glossary as we go through. I get folks to explain terms they use and clarify this with other people in the room to ensure they understand the terminology too. There's nothing worse than spending 30 minutes discussing a process point than finding out that when Finance talked about 'Credit reports' they meant the reports that are produced on a monthly basis to send to customers with their outstanding balance, but Management Accounting understood Credit Reports to mean official feedback from an accredited agency detailing the risk of giving credit to a potential customer. Create a glossary and get everyone on the same page. Also do this with your nomenclature. explain concepts such as the meaning of a process, procedure, task, and activity.
7) Take your time.
This is not a quick process. Allow at least a day for a small process and up to week for a large process. Don't rush things or you will cut corners. If your key participants have to leave at a certain time and you're not finished, don't speed up to get things done before they leave, arrange a follow on session. If this is important enough to do it's important enough to do correctly.
8) Use the Hype Cycle.
The Gartner Group have a concept know as a Hype Cycle. it explains the various stages that new technology goes through from it's introduction to it's integration into society as a meaningful piece of hardware (or concept). I have found that process facilitation sessions tend to follow a similar, but accelerated Hype Cycle.
- You start with the 'Trigger' which is when people are keen to start working on processes
- Rapidly you move into the 'Peak of inflated expectations' where people have convinced themselves that this will solve all their problems
- Soon you start to drop into the 'Trough of Disillusionment' where people now realise that they might not get all they wanted from this. motivation starts to drop and energy levels diminish
- As they work through this they climb the 'Slope of Enlightenment' and realise that this could be useful after all
- Finally they get to the 'Plateau of Productivity' and the exercise becomes much more useful and output increases rapidly.
Process facilitation is not rocket science. It's actually fairly straightforward. Remember the 8 key's listed above and you'll be a process ninja in no time!
Or do you think otherwise....? Let me know in the comments.
