In many organisations, there exists a vast debris of incomplete and out-dated visual models.
And they are many reasons for this.
It may be as simple as an abandoned project, a concept that did not make it into development, or simply a project whose funding ran out. The more likely reason is that abandonment of models once they are seen (erroneously) as having outlived their usefulness.
An astoundingly common mind-set, is that models is a product deliverable that is developed, and once developed is complete. And in the helter-skelter project world, modellers cannot be blamed as it often is developed in support of a milestone on a project schedule. And once the milestone is achieved, it often is left behind in the mad dash for the next milestone.
In projects, visual models are often considered to be the means to the end of developing test cases, software code and training materials. Once these outcomes have been achieved the model serves no more purpose to the project team.
In the long term, models not seen as a living asset become outdated and are often forgotten.
The British statistician George E. P. Box (called “one of the great statistical minds of the 20th century”), will forever be remembered for his enlightening words: “All models are wrong; the practical question is how long do they have to be not to be useful.”
Even in abandoned models there are value.
Models that are abandoned along the way often contains the only recorded explicit information that documents systems that execute in business environments. Often support teams have only these out-dated models to develop the learning. Or when new analysts join the team this is often the only resource they have to understand systems from which the original team has long moved on.
So, what’s the alternative?
Instead of seeing a model as a final deliverable that serves as a means to an end, it should be considered a way of thinking. And not only a milestone deliverable, but a living representation that will grow and change as business change over time.
So, what is a model?
A model is meant to be a representation of a system – a business, information system, strategy, infrastructure, or anything that is useful to know. It is typically an abstract description on a smaller scale, that allows the analyst to imitate, or follow, the logic of the system.
This means we approach modelling as a way of testing how real world works. We model to create both logic and possibility.
When we model a business process, we want to see if the business process will work if it executes in practice. The model should make it easy to see the different behaviours and all the logical consequences if the outcome of the process is either achieved, or fails.
We may start with modelling the business process as a representation of current behaviour to the best of the knowledge available to us through business resources, practitioners and good practices.
Once a baseline process is modelled it must be tested. Not only against the standard behaviour but also against all potential scenarios that are likely in the present and are possible as viable potential future behaviour.
And as each scenario, or potential behaviour, emerges, it is tested to see if the business process accommodates it. This leads to two possibilities.
Either it accommodates it – which indicates to the modeller that the business process is robust.
Or it fails – which may mean that a redesigned process, a variant of the process, or even a new process is needed.
And then things change. And we accommodate those changes by testing it against, and adapting the model again.
Notice how we now use the model as a tool to assess present-day execution and potential future execution scenarios. Now the model becomes a thinking tool as opposed to just a deliverable. Business interactions, present and future, can now be simulated without the danger of real life execution and failure.
And in the design, or redesign, of the business process model, knowledge emerges which ultimately contributes to a better process.
Now start modelling to think!