How often have you seen a TV clip of a fashion show (Milan, London, New York) and asked yourself “What the hell are the models wearing?” Business analysts may be guilty of something similar. Of course he is a model, but what does it mean, what is he trying to say?
In the fashion industry, models are used to communicate (bring to life) a designer’s ideas and creations. But they also go a step further: they help us consumers to imagine what the clothes would look like if we were wearing them.
Models in business analysis play a similar role, they stimulate our imagination so we can analyze problems, explore solutions. The case for modeling 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 gives the business analyst the opportunity to think analytically and creatively about what the organization really needs to do to achieve a better “to be” solution.
Modeling is one of those timeless techniques that transcends business analysis and is used in virtually every discipline, from accounting to zoology, including engineering, design, construction, research, and more. By the way, accountants use modeling techniques to analyze financial data, zoologists use modeling techniques to analyze, among other things, animal behavior.
Just as accountants and engineers have specific modeling techniques that are used in their respective professions, so does business analysis. But this article is not about which technique you should use, there are many to choose from, it is more about what you are trying to achieve.
So what are we trying to achieve? It comes down to two things. First, what is the problem? What’s wrong with the system “as is”? To get to the bottom of this, we need to dialogue with stakeholders. If the issue is well documented and understood, then great, but often the stakeholder will only see the issue from a particular perspective. It is up to the analyst to dig below the surface and discover the real cause.
Here you have two options, 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 get the inconsistencies, loops, delays and bottlenecks in the current process? And a (very important) by-product of doing the latter is that you can work collaboratively with stakeholders instead of 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 interested party and say “Can you draw that for me?”
The second of our objectives is to decide what the “to be” system will be like. Modeling again offers a rich variety of options. It can be as easy as modifying an existing diagram “as is” or as liberating as asking draw me a picture of what you would really like to see happen. Very few people would say they can’t understand a simple UML process diagram.
A final world about models: They can also clarify the often confusing steps in the business analysis process. Whether your project is agile, iterative, waterfall, or a mix of all of these, they all have the same goal…
… to reach an end point and produce a deliverable.