How often have you seen a TV clip from a fashion show – Milan, London, New York – and thought to yourself “What on earth are the models wearing?!” Business analysts can be guilty of something similar. Sure it’s a model, but what does it mean, what’s it trying to say?

In the fashion industry, models are used to communicate (to bring to life) a designer’s ideas and creations. But they also go one step further – helping us the consumer to imagine how the clothes might look like if we were wearing them.

Models in business analysis perform a similar role, they stimulate our imagination so that we can analyse problems, explore solutions. The case for modelling is neatly summed up in this quote from the book Business Analysis Techniques: 72 Essential Tools for Success:

Models reveal the inconsistencies, loops, delays and bottlenecks involved in a process. A systematic analysis of “as is” process models provides a business analyst with the opportunity to think analytically and creatively about what the organisation really needs to do to achieve a better “to be” solution.

Modelling is one of those timeless techniques that transcends business analysis and is used in virtually every discipline from Accounting to Zoology – in between there’s engineering, design, construction, research, etc. Incidentally, accountants use modelling techniques to analyse financial data, zoologists use modelling techniques to analyse, amongst other things, animal behaviour.

Just as accountants and engineers have specific modelling techniques which are used across their respective professions, so too business analysis. But this article is not about which technique should you use – there’s plenty to choose from – it’s more about what are you trying to achieve.

So what are we trying to achieve? It boils down to two things. First what’s the problem – what’s wrong with the “as is” system? To get to the bottom of this we need some dialogue with the stakeholder. If the problem is well documented and understood then great – but often as not the stakeholder will only see the problem from a particular perspective. It’s up to the analyst to dig below the surface and find out the real cause.

Here you’ve got two choices, write a step by step description of the process under investigation – or draw a process model. Which do you think is easier and more likely to draw out the inconsistencies, loops, delays and bottlenecks in the current process? And a (very important) by product of doing the latter is you get to work collaboratively with the stakeholder rather than them dictating and you taking notes. And you don’t have to be the artist – take every opportunity to hand the whiteboard marker to the stakeholder and say “can you draw that for me?”

The second of our objectives is to decide what the “to be” system will look like. Modelling again offers a rich choice of options. It might be as easy as modifying an existing “as is” diagram or as liberating as asking draw me a picture of what you’d really like to see happening. Very few people would say they can’t understand a simple UML process diagram.

A final world on models – they can also clarify the often confusing steps in the business analysis process. Whether your project is agile, iterative, waterfall or a mixture of all of these, they all have the same objective… 
… to reach an end point and produce a deliverable.