The post for this week (or rather this fortnight – you may have noticed that my posts have slipped further apart) will probably prompt a change in my model. Only a small change mind you, but one nevertheless. It has become very clear that I just can’t talk about decision tables without covering process models first, so I’d better switch them around! And I’m also thinking that it’s not enough to merely talk about models of processes – although that’s the important one – but I don’t think we should ignore procedure models either.
This week I’m looking at what process models are, but I think that’s been done by many people many times before. Hopefully all my readers have seen flow charts before – if not, google ‘process model’ – and I don’t really have anything new to say on the construction or appearance of a process model of this sort.
So I’ve spent the last few days thinking about how I did want to address this topic and how to do it justice, as I think that processes are the heart of implementing a vision. If an activity is not embedded in a repeatable and accepted way of doing things, it is not core business, it is not necessarily done (or done well) and it is not reliably producing benefits for an organisational unit. Which means I’ve had to think carefully to work out how to tackle a subject of such… such beauty and such potential power.
There are different process modelling notations, methodologies and application that exist but I don’t want to explore them today. For now I’ll thumb my nose at this level of detail. Instead, I want to explore the commonality of process models. I’ll be honest though – this has ended up being a circular post. Read on if you dare and see if you can spot the loop yourself.
I’ve covered the definition of processes versus procedures in a previous blog. While processes “are ‘a series of actions’ they are more high-level actions that may be undertaken by multiple people. Meanwhile, procedures are ‘a series of steps’ that are quite explicit and detailed. Processes and procedures are respectively “the series of high and low level steps required to undertake a business operation.”
Today I’m also not focussing on this distinction and will talk about process models only, but I really don’t see why the bulk of these comments can’t be applied to procedures too. The only warning that I would have in respect to this is that the more detail you go into (ie the more you dig into a procedure) the more likely it is that changes will be more frequent and the benefits of documentation will become eroded by the sheer effort and time required to maintain them. I think that the level of detail you need to go into to sufficiently capture corporate knowledge and ensure alignment with the organisation’s goals in an efficient, cost effective and appropriate way is something that needs to be assessed on a case by case basis. I’d be happy to hear any thoughts on that though!
Given that a process is a series of steps and will generally have a trigger/s and outputs, a process model reflects how it is believed that the process would or should occur in a perfect world based on a given set of assumptions. Maybe I should have defined a model first… But hopefully you agree with me.
A model – whether it be a computer-generated model of a river system, a 3-D papier mache model of the solar system, or a very trim and pretty girl on a catwalk – is a visual representation of how the creator thinks that his subject matter would exist and operate in a perfect world. I would argue that the key difference between these is that an environmental engineer would probably do a very good job of documenting the assumptions they have used in developing their model, whereas a primary student or a fashion designer may not. Nevertheless, I would suggest that the assumptions are always there, whether expressed or implicit. Obviously it is not a perfect world, so the model will generally not hold exactly true, but at least it gives me a common understanding of what is being aimed for.
So – supposing that everything I’ve said in the previous paragraph is correct – a process model is also useful and also must use some assumptions.
For a process model, these assumptions can be a wide range of things. In developing a process model, one might assume that:
- Business rules will be adhered to.
- Specified tools, templates and roles /actors exist in a usable state.
- Certain scientific and /or behavioural theories hold true.
- Other processes that it is part of or links to.
Well, business rules we’ve covered. Templates and forms we’ve covered. Scientific and behavioural theories – well that’s a thinking project I’ll save for another day. And processes – we’re looking at them here!
One of the loveliest things for me about process models is the hierarchical granularity which can so easily be illustrated. When I think of an organisation I think of this humungous conceptual pyramid, where miniscule actions comprise procedures, which comprise low level processes, which comprise high level processes, which eventually could (if everything was set up right) comprise the organisation’s value chain. It can be like an shiny and sleekly aerodynamic rocket in the neat way it fits together and aims for the stars (although, yes I will admit that things change and nothing in this world can be perfect)!
Here’s an example of what I mean, without going too far ahead of myself and turning it into a multi-layered process model.
- Review customer complaints – a process in itself that is also one step in:
- Assess customer satisfaction with products – a process that is also one step in:
- Review portfolio of products – a process that is also one step in:
- Undertake annual planning process.
I’m afraid my heart wasn’t in trying to find a cutesy example – so I’ve left you with a horribly dry one. However, I think (if you were able to read through it without your eyes glazing over!) that it makes the point.
There really are processes within processes. No process stands alone as it is always possible to go into greater granularity, into the micro-detail of how you open an email, or change the font colour, or find the code for your custom font colour. The other way in which processes link together is more horizontal than vertical, where processes at a similar level of granularity link to each other. Either way, the processes that link to, form part of, or comprise of a single process are key assumptions of this process.
Maybe you’ve spotted the circularity of this post already? You have already read that I think that processes are at the heart of implementation – ie document your processes, or else! The problem is that talking about assumptions has lead me to a secondary conclusion. To properly implement processes, you also need your assumptions for the process model clearly defined. That is, your assumptions including business rules, templates (and other tools) and other processes.
So yes, process documentation is incredibly important – I guess that’s why the ISO standards always seem to place so much importance on them – but still, without the supporting parts of the Superior Business Analysis model being in place, the model is not going to ring true in reality.
But if you’re going to ask me about the assumptions on which the Superior Business Analysis model is based on, I’ll have to take that as a question on notice!
What do you think?
What other assumptions might underpin a process model? And have you got any examples of how process dependency modelling has been applied in your organisation?
(Picture: ‘4 Terrestrial Planets Size Comp True Color’, uploaded to Wikipedia 30 August 2012 by Scooter20, licensed under the Creative Commons Attribution 2.0 Generic license, and sourced from Wikipedia at http://en.wikipedia.org/wiki/File:4_Terrestrial_Planets_Size_Comp_True_Color.png)