Data driven decision making, or in other words, who data analysts really are and why do we need them?
Data analytics is, on one hand, one of the most needed skills in any company (or team) and on the other hand, one of the most underrated ones. It is a backbone of any process improvement and the moving engine of decision and change. But why do we need a specific person for it – what can an analyst tell me that the data itself won’t?
Well, let me explain…
I will take you on a journey, that may, to some extent, open your eyes to what benefits you may get from hiring a good data analyst. And, maybe, you will appreciate our skills a little bit more after reading this.
What most of us, as data analysts, deal with on a day-to-day basis are databases. Or rather, endless lines of entries (rows) containing various data. More often than not, it is not one table we need to take into account, but multiple ones, not necessarily equipped with a unique identifier to connect the data between them in a logical way. But hey, what do you care about the daily struggles of a data analyst, right? Let’s go back to the main topic – what does a data analyst really do??
Contrary to popular belief, manipulating and aggregating data and crunching numbers is not all we do, and this is not how we start…
Data analysis does not start with data (newsflash, right?), it starts with a process.
No amount of data makes sense if you have no clue of what (process) it describes and what questions we want to answer with the analysis (i.e. business objective).
There is this great example on how you can read data wrong if you don’t know the backbone.
Let’s say there is a linear correlation between a number of units involved and the damage done in an event – logical conclusion would be – cut down on the number of units involved, right? Well, yes! Or at least it seems logical.
Now, let’s hear about the process: there is a fire somewhere in the city, the “units” are fire trucks, and the “damage” is the one done by fire. And yes, the correlation is correct. The more firetrucks involved (statistically), the more damage there is. Why? Because the bigger the fire, the more trucks they send – not the other way around. Would our first conclusion solve the issue? ??
Tricky, right? This is why, in my humble opinion, a good data analyst should partially (or in many cases entirely) be also a process analyst. And this is the reason it all must start with a process.
We need to have great communication skills and ability to grasp wide concepts very quickly, as our first task is to understand a process, we knew nothing about just yesterday.
Process owners are our key contacts, together with the people who follow the process in their daily work (let’s call them ‘process users’). We usually schedule multiple calls with them, depending on the complexity of the process. The first meeting is just for us to learn about what the process flow looks like, what is the outcome supposed to be, and what our target is – what do we want to measure and WHY. This is where we start teaching process owners on how to define KPIs and when we have a first stab at what we want to see in the end.
Then, we usually ask for raw data – unfiltered, with everything we can get – straight out of the system, without human intervention – as clean as possible. This is where the process users come in. They are the ones actively using the tools. This is when we connect with them to map the data to whatever process owners told us. Believe it or not, often, the process flow described by process owner does not really match what the process user is saying… But I digress, this might be a topic for process improvement article.
After a while we have a few sets of information: we have the process flow from the process owner, the raw data, the desired outcome, and the support of the process users who can tell us which data point (field) means what, and what pain points and bottlenecks the process suffers from.
All this concludes step one – understanding the idea of the process and the objective of the analysis.
Step two is organizing data.
Here, with often many back and forth meetings with process users (and sometimes process owners) we slice and dice the data, gathering it into usable chunks, and presenting in a graphical form, that we can draw conclusion from.
领英推荐
This is where a lot of the data analyst magic happens. We tend to see data in a different way. It usually comes with experience – the more we do it, the more we see. We spot patterns and irregularities, and we have to ask questions… A LOT OF questions, to the point, when you start hating us ??. There is a method in that madness though. Bear with us, please, and answer everything we ask. Remember we are still new to the process and something that is normal from your perspective, may seem like an odd thing to us. All the “stupid” questions we ask, are in fact essential for us to understand what we are dealing with, and you are asking of us. When you start working with a data analyst you will hear the words WHY / HOW / WHAT a lot. This is almost a part of our job description ??. Get used to it, it’s not going to go away. ??
Everything up to this point seems easy – why doesn’t a process user or a process owner do this… filtering data is easy, you might think.
It may seem this way, but good data analysts don’t just look at the data you provided. They should understand the complexity of the whole organization and how various processes, and various databases interact with one another, how the data flows between them, or how it is siloed, even though it shouldn’t. This is where the data-analyst-superpower kicks in. We propose the solutions, and extensions to data that you provided, by integrating your view of the process with the view of the whole organization.
Most of us switch from one analysis to another very quickly.
We leave one, with a working dashboard or a report and we move on the other one, and then to another and one more… Day in, day out. We never forget, though. We can recall what we heard about a different process months ago and connect the dots and use the information when working on your process. Every single day (week/month) we work on a different process with a different person – this is why, even if we work for just one team – we usually have a better overall view on the portfolio of processes than any single process owner has. And we tend to use that knowledge.?
Plus, don’t forget about spotting patterns and irregularities. It really is a skill. We do develop a hunch (a sixth sense if you will) after a few years on the job.? It usually manifests itself in a form of “something’s off with the data, but I don’t know what…” or something along those lines. Then we take a deeper look, and it becomes an insight.
?
The outcome of step two is usually a dashboard of some sort with a few visuals (between 3-6 is optimal – less seems “empty” to most users, and more gets people lost). With that said, this is when we usually have our first bigger disagreement with over-eager process owners who want to put down 20-30 KPIs and flood the poor team with over-analyzing. With data visualization – less is more. Just pick the most important KPIs, try them out in real life, if they bring no value, we can redefine them. No biggie.?
Step three is the best one yet, and the one I love the most, because it brings insights.
This is where we transform data into conclusions (ever heard the new, trendy phrase “story telling”? This is it!). This is where the real magic happens and here lies what will be, in the end, a basis for decision making. We teach you how to read the data. If you hired the best of the best – you will not need schooling, the data will speak by itself, and you’d have learned enough from your analyst while you were defining KPIs, that you know how they work together and interact.
A good data analyst will – for a few days (weeks/months – depending on the process), observe the data together with you, they will show you the patterns they see and open your mind to drawing conclusions where you wouldn’t even think about them.? After a while, you will spot the patterns in the data for this one process on your own. You will know the co-dependencies and you will be able to read and use the information to your advantage.
This is when we step back a bit. We are still there, in the background, ready to help you if any new patterns come in, but from then on, you should be able to work on your own, look at the datasets and graphs they provided, connect the dots between various views and draw conclusions, and, maybe, ask a process analyst for tips on how to improve a process.
Why not get a process analyst to start with, you ask?
The answer is two-fold – I still stand by my initial opinion that a data analyst should also be a process analyst, so in that sense – yes – get a process analyst (with data analytics background). If they are two separate people, the answer is: you can only improve a process you know, and to know your process, you need to quantify it first, so make them work together for mutual benefit. And – once you start making decisions about process improvement, remeasuring to see if the change paid off, connecting back with your process analyst and data analyst, you will find yourself caught up in a PCDA (Plan Do Check Act) continuous improvement cycle, that brings more and more maturity to the process, removes bottlenecks and pain-points and allows you to fine-tune the process to the people, not the other way around. Be careful – process improvement is addictive. I am beyond saving now. ??
Expect the second part of the article soon - there you will learn how (and whether it is even possible) to improve a process.
LifeHub animation. Innov4Ag program at Bayer
6 个月Really to the point! I wish to know more data analyst with go story telling ?? !
IT Program Manager | (PMP)? Certified | Driving Digital Transformation and Compliance
1 年Very insightful and explained in a language that can be digested outside IT as well! Data without context is just numbers!