This month BPTrends launched a mini-survey to determine what readers think constitutes a business process. So far we have only had 18 respondents, and we look forward to more. Even with our initial response, however, its clear, that a few things are core and a couple of things are less likely to be included by at about a third of our readers.
Everyone agrees, for example that some kind of Input-Output specification and a description of the sequence of activities that transform inputs to putputs is part of a process analysis effort. Similarly, almost everyone agrees that branching points, actors, and decisions or business rules are part of a process. A few less people think description of data used, a description of policies, and a description of who works at each activity is a part of a process.
And fewer still think that a list of resources consumed (needed for simulation) or a description of motivational contingencies that managers reinforce are part of a process. (See my previous blog on US Air Force problems in Afghanistan to see why I think management contingencies are so important.)
Hopefully others will respond to this mini-survey and we'll get a better idea of what others think is core and simply nice to have. In the meantime, its clear that a solid majority think all of the items on our list are important — and we do as well.
Different groups or methodologies have always emphasized one aspect of process or another, but, at the end of the day, a good process analyst wants every tool in his tool box so he or she can be more likely to identify problems and deliver improved results.
To me, on the most abstract level a processes are ‘the things’ that make organizations do what they promise.
To me a process is a means, never a goal. Every organization just has processes because they deliver products or services. And there must be a process to do that. That doesn’t mean that every organization sees processes as important or worth attention.
So a process; a means to deliver some kind of result. So in my opinion a good process starts at the end. What do we promise? Can be anything of course. A delivered pizza within 15 minutes. A cured headache. Also be aware that a process can have more stakeholders.
So the start question is; what are the useful results we want to deliver ? And when you know the end result you could consider thinking about the process. When you take your processes serious, there are 3 levels on which you have to look:
1. Execution
2. Management
3. Improvement
Ad 1. You have to think about what is needed to execute a process? I always split that up in:
– milestones (what are the important milestones of the process?)
– workflow (what actions need to be taken for a case?)
– People (do they have the right capabilities)
– Information about a case (what data is needed at what moment?)
– Supporting software
– Other supporting facilities
Ad 2. Is the operational level where you manage all the cases currently in your process. That is what I really would call process management (or better; case management)
What you need for that is:
– information about the status of all cases (some kind of dashboard)
– process rules (what happens with certain cases)
– A fitting style of managing (workflow bases, goal bases)
And most important: the right level of flexibility because what is speedometer without a throttle or a brake? Useless.
So this is all about being able to act when something doesn’t go as planned with cases. If you are not able to act, why bother showing the progress of cases?
I often use soccer as a metaphor. This level 2 is playing the game. During the game you still got a chance to win. After the game it is too late. That’s why I call level 3 ‘Locker room talk’
Ad 3 is just good old process improvement.
You need information about the performance of a process for that. When this kind of information is logged by the systems you use for execution, you could consider using process mining.
And there is much more to say about these 3 levels, but I always help organizations to get all 3 implemented. On level1 we have to think about ‘how do we handle cases’ on level 2 it’s about ‘how do we manage all those cases on daily basis’ When level 1 and 2 are ok, hopefully level 3 where we ‘rethink the process design’, is not needed.
Regards,
Emiel
And be aware that this is focused on ‘information’ processes. For production processes you also need materiakls (iron, paint, plastic) during execution
We use business process analysis to get high level agreement on how things are supposed to work among technical and non-technical teams. Including most of the detail described in the poll would simply put off more than half my audience and therefore fail to achieve any value from the exercise. That’s not to say that we wouldn’t use any of it. Every time we look at a process there is a different objective and depending on what that is will dictate whether any of these things are useful.
What is always there, as I voted, are a descriptions of the activities, inputs, outputs and who is RESPONSIBLE. We don’t need any more than that in most cases.