My views
What I mean by data analysis, how I approach a project, and what its implications are — or should be.
Data, structured or not, is the basis of information and of knowledge. It is the moment we come to know things that we become able to make the most advantageous decisions and the most considered choices.
I have an objective to reach, I have a strategy in mind, I need to gather information and so I analyse the data.
That is what the right approach should look like.
Reality often puts a rather different scenario in front of us, one in which the frenzy of “everything, and now” makes us forget the logic of calibrating our objectives.
This is where data analysis comes in, and where the analyst — the data analyst — takes on a role that is strategic and decisive for success.
A premise is in order: when I speak of the Data Analyst I am referring to the consulting side of the job rather than the technical one. On that side the term normally used is Business Intelligence Analyst.
Without drawing too sharp a line between the two — and aware that this is a relatively young profession — I will use both terms in the same way.
Rather than explaining technically who the analyst is, I would rather talk about who the analyst ought to be.
Certainly the person who puts the end client in a position to make the main decisions, through the correct presentation of information. Put like that, it might even sound like a simple job.
You tell me what you need, I use a data query tool, I hand you a few reports and a few charts.
In certain companies — the ones I will permit myself to call “loosely structured” — that approach is more than enough.
But companies are becoming ever more sensitive to the correct presentation of information, and as a consequence ever more demanding about the numbers. The analyst has to be ready for that shift, with an approach that cannot be only the IT specialist’s, but has to cut across every discipline, technical and humanistic alike.
Which is why we can say that the analyst should be part IT specialist, part mathematician, part economist and above all part psychologist — the last of these not to be underestimated, and one I come back to in the approach to the client. Qualities to put in your bag as you go, not entry requirements.
The analyst does however need to know a data query language, what a database is, the logic of an information system. The sharpest among us may even learn a programming language — but the colleague who reads the code will always say “yes, it works, but it wasn’t written by a programmer”. And let us be honest, that is not always a bad thing.
Then again, does someone who studied engineering or mathematics absolutely have to know the difference between debit and credit, the two sides of a balance sheet? I would say no — but they do need to be able to frame the subject well enough to talk it through with a more expert colleague.
Here we get into a wider point: nobody today can presume to know everything they need on their own. Collaborating and engaging with others — especially in the world of data analysis, though the principle holds in any field — is an indispensable formula for success.
“And there he is, the man himself”, a football commentator would say: the client, first and last element of the whole business.
It is the client who tells us what they want to achieve, and it is always the client who is the real final tester of the solution, the one who declares the objective met and the work a success.
We all know that from the start of a project to its close the road is not always straight: changes of mind, misunderstandings, new particulars can surface. But if the initial approach is made with certain precautions, the whole thing will run as smoothly as it can.
Is it really that easy? I did not say that — but a good method helps. Four fundamental points:
Have we actually understood what we have to achieve? The moment a project is commissioned, the first thing to do is to work out whether the objective is clear in our own minds — and above all in the client’s.
The mistake is to take it for granted that we have understood. The mistake is equally to take it for granted that our client has a clear picture of the result they want.
Careful: I am not saying we should presume to know what other people want. On the contrary, we have to be humble and assertive at the same time, taking nothing for granted and being as simple and as clear as possible in our initial analysis.
It is about understanding the client’s primary need, the main objective. That saves time, prevents misunderstandings and avoids wasted energy. Once that is clear, we can concentrate on getting there.
Opening a spreadsheet, using a notebook or a slide to sketch an example of what is being asked of us, is a necessary condition for “understanding whether we have understood”.
At the same time it gives the client a different point of view, letting them see in practice the result they would expect.
Sometimes a sheet of paper is genuinely enough — something to draw a process on, a flow of information with the interactions it would generate.
This is the stage when the first questions and the first doubts appear, and the stage where the aim can still be adjusted without much consequence.
Clients are not all alike. For better or worse that is the reality, and while the people change, the consulting approach has to stay the same and always be the best it can. This is where the psychological side of the B.I. Analyst comes into play: someone who has to be excellent with numbers, but also with words and with attitude.
You have to “study” the person in front of you: understand them, listen to them, which is what tells you “what to do” and “how to do it”.
What kind of client am I facing? What role do they have inside the organisation? How do they deal with their colleagues, inside and outside the company? What sector is the business in? Working in furniture is completely different from working in engineering.
You do not need an anthropological survey of the territory before starting a B.I. consulting project — but you do need to pay close attention, and not make the mistake of underestimating these things.
The typical North-East Italian client — the example comes easily to me, since it is where I live and work — has the classic profile of “everything, and now” and “it should have been ready yesterday”. The leitmotiv is always urgency. Run, run and run again… yes, but run where?!
The analysis (I come back to it in the approach to the data) has to be done with the greatest accuracy, leaving nothing to chance. Haste here is not merely a bad counsellor: it risks coming back like a boomerang the moment some piece of information has been left out. In short, better to pause once more at the beginning, with the sights properly trained on an objective that is shared by everyone.
The work is done, the objective met. Good, everyone is happy. And then no — because some time later there may be something to adjust, or in the extreme cases, which are not to be ruled out, an objection: “we misunderstood each other”, or “you didn’t solve my problem”.
The doubt remains. Was the problem genuinely not solved, or did the client simply not test it straight away, so that over time some detail got lost? Let us avoid all of this by applying the rule of feedback immediately, whether or not clients have the time. But if you commissioned that work you are going to need it, so you will certainly find the time to look at it — and if it was urgent?! There, I will say no more, the point speaks for itself.
This is not the analyst’s problem, though — or rather, only partly. It certainly would not be, if the analyst received a response straight away, positive or otherwise.
In conclusion, to be sure of the work delivered you have to question the client, insist on an account, a test, in writing if that is what it takes.
Data is the heart of the analysis. That number, that table or chart which, extracted the right way, can make the better decision possible.
It is easy to see that for a data analyst this is the fundamental element of the job.
Precisely for that reason data — always understood as information, whatever its source — has to be handled with care, through a precise approach. Let us look at the main points:
Why does it matter to “do a good analysis”? Because it lays the foundations of all the work that will follow.
Depending on the complexity of the project, it can take hours, sometimes days. Getting the analysis wrong — or worse, doing it superficially — can mean getting the whole project wrong.
It is like designing a desk: we have to make sure we have everything we need before it can be built.
So how should a good analysis be put together?
I have done the analysis, tracked down the sources, designed and presented the whole thing perfectly, perhaps with charts and interactive tables too. I have spoken to all the parties involved and I declare myself satisfied with the result.
Pity that a few hours later the client calls and says “something doesn’t add up”. And that is where the whole stage collapses — or where the penny drops, take your pick of the saying. Either way the result is the same: the numbers have not been reconciled.
If I present a report on sales by agent and client over three years, and the client tells me the January figure looks too high, it means the analysis was not done properly.
Filters have probably been left out: we included entities that should not have been counted, we should have excluded the affiliated companies. In short, we have to go back over the analysis — which translates into wasted time and “financial stomach aches” on the client’s side.
Mistakes happen, of course they do. But reconciling the data has to be an integral part of the work of data analysis.
The result — whether it uses tables, charts of one kind or another, or key performance indicators — has to be presented as clearly as possible. We can identify three key rules for presenting data:
Usability is about the ability to present data simply and intuitively. Even a plain report has to land immediately: whoever uses it should not have to spend long working it out, and every single number, table or chart has to be able to “speak” and convey at once the objective it is meant to serve.
The data analysis tools themselves matter here too: powerful, but at the same time flexible and easy to read.
Notes can be used — through text boxes, for instance — alongside a chart or a table, so that whoever is using our application always has a feel for where things stand.
And one piece of information must never be missing: when the data was last updated. As of when are these figures current? What period are we talking about?
If it matters that the data is intuitive, it matters just as much that I can explore it quickly.
We see it every day online: I open a site, and if it is too slow I abandon it, because I will certainly find a faster one covering the same ground. That cannot be allowed to happen here.
To stop it happening, the attention has to go to the technique: an overly complex algorithm needs rewriting, or the database query logic needs changing, redefining how things are presented and perhaps thinking of alternative routes.
It is certainly true that the business intelligence tool makes a difference — but a great deal also depends on how we approach the problem.
As in everyday life, business intelligence too feels the weight of aesthetics.
There is no doubt that presenting an analysis with, say, a dashboard using a particular kind of chart, font and colour is the equivalent of turning up to dinner in a good suit. It may not make the absolute difference, but we are off to a good start.
It is our calling card at the meeting, at the presentation, or simply in the decisions of every day.
On that note, for example, a pastel colour is preferable to one that is too strong or too bright, and a clean, easily read typeface is far more appreciated than a showy, over-elaborate one.
The choice of the best form of presentation certainly depends on the content, and on who our solution is aimed at.
If the audience is the board, or a sales director, an area manager or a department head, the tendency is to turn to dashboards.
The aim, after all, is to make available few figures but meaningful ones. Each dashboard can hold charts, key indicators and numbers, with the immediate purpose of measuring whatever is under analysis. From the summary to the detail, if needed — but the detail only at a later stage.
As for tables and reports, much depends on the content of the analysis. In administration, for instance, reporting solutions are more common than graphical ones. It is a different matter in sales, where graphical presentation plays an important part in grasping the trend of something.
Which charts to use? That choice depends a great deal on the content and on the time periods involved. Studying the monthly trend of orders over the last year against the previous one is usually shown with a line chart. If instead I am looking at delivery service levels in one specific period, without necessarily comparing across time or place, a gauge will do.
On the Solutions page you will find the areas I work on, broken down by subject.
Rezzani’s definition makes it immediately clear how Business Intelligence is the heart of data analysis and at the same time its indispensable element.
I like the word system, understood as a mix of elements integrated with one another, whose interaction has as its objective putting the end user in a position to make decisions in the best way possible.
The starting point of Business Intelligence is certainly the database, often organised through datawarehouse systems or sets of datamarts. Without dwelling on the strictly technical definition, I can say it is the underlying data from which the information we need is organised, using every tool B.I. makes available.
Management asks more and more often for smart tools to support decisions. The BI analyst, backed by these techniques, has to be ready to give them the best conditions to do so.
What is used for this are reports, charts, tables and key indicators (KPIs, or key performance indicators), the whole thing organised logically and functionally through interaction with people, the organisation of tasks, and training.
The right answer is “it depends on the objective we want to reach”. The market offers plenty of options: from high-end tools with practically limitless possibilities, to lower-tier ones that look easier but can do less.
So which to use? My view is to use whatever lets us reach our objectives in the simplest way possible.
If our aim is to give the sales network — agents and area managers — a body of information usable on a web platform, from desktop to tablet to phone, we will be looking at advanced software: Qlik View, Tableau, Power BI, to name the main ones among those Gartner places at the top of its Magic Quadrant.
On the other hand, if we are “content” with using the data while we are at the office, or in “real time” connected directly to the ERP system, less demanding tools will be enough.
Careful, though, not to confuse two different things.
I am not talking about “better” or “worse” tools. These are clearly tools with different characteristics, in cost as much as in performance — but if we have done a considered analysis, and bought what we actually needed, both will prove useful and therefore powerful, regardless of processing power or list price.
It is rather like being asked “sorry, but which computer do you think I should buy?” I always answer: it depends — what do you need it for?
Let me pick up some thoughts on company KPIs, key performance indicators.
How many times have I heard those answers, and how many times have I thought that the problem behind this “fear of the index” was only the way these indicators get approached.
Often the difficulty lies in the explanation, too complex and not schematic enough; often in a thin culture around something that is taken to be superficial. And again, if we turn our thoughts to companies, the resistance is fed by a low inclination to measure how processes perform.
It is no longer possible to sail by sight; it is no longer possible to think we are succeeding because turnover goes up every year. And the costs? And client loyalty? And how promptly we get paid?
The objective is to change that approach, or at least soften it, because the first step of any improvement is awareness — and awareness is very often a synonym for measurement.
If our objective is to apply our index, that index has first of all to be clear. If it is not comprehensible, if it turns out too complicated, there is a case for dropping it and treating it as useless. I take the view that things have to be understood before they can be applied. And to be understood, they have to be explained simply and practically.
A good method is to have an effective orientation. In plain terms: an approach, a scheme of analysis, a guideline to follow. When I explain an indicator I always work through six points of view:
…and what if I never studied economics? What if I have never heard of any of this?
My view remains that “almost” everything can be explained and understood. What is left is to work out how much that “almost” weighs on the final result.
Which indicators to use? The right answer is… it depends. It depends on each individual company, on the activity I want to monitor, and above all on the objectives to be reached. Those are what, representing the final result, will have to be turned into measurable indicators and monitored constantly.
If we are to set ourselves some rules, the first important step is certainly to understand the thing being measured, whether that is a business, a sport, or an event. Which means:
Measuring the effectiveness and efficiency of each process amounts to measuring the performance of my organisation. And at that point the index follows of its own accord, because I am aware of what I want to achieve.
