I was part of a conversation recently where something like this was said:
“We need a data model that will bring all of our data together so that we can analyze risk and do predictive analytics… No, just build the model, don’t worry about using Tableau – we’ll do that after you build the model because data visualization is the easy part…”
Now, I’m all for empowering others with Tableau so they can see and understand their data. And it is easy. And I fully believe a good data model and solid data structures are important for good analysis. And I love data visualization… but, Tableau is so much more than just charts and graphs. If you wait to use Tableau for just making charts and graphs after you’ve done your data discovery, analysis, predictive analytics, modeling and structuring then you’ve really missed out…
The Cycle of Analytics
If you search for “cycle of analytics/analysis” you’ll get quite a few different (and even contradictory) descriptions of the data analysis cycle. One old-school model suggests the steps of 1) Identifying a Problem, 2) Designing data requirements, 3) Pre-processing the data, 4) Performing Analytics over the data, and 5) Visualizing the Data. Notice that visualizing the data is the last step and only done after requirements are defined, data is processed, and analysis is done (yikes!)
Tableau actually has a decent guide to choosing the right analytics platform that includes a cycle that flows from Interacting to Analyzing & Discovering to Sharing, to Governing to Accessing. Overall I like the scope and definition of the cycle as described there, though I tend to simplify to something like this in my day-to-day role:
You’ll notice a few things:
- It’s very simple and free flowing: I don’t necessarily have to start at any one step and I don’t have to end at any other. And it truly is an iterative cycle that I will repeat as needed (end even circle back on steps that need some iterations).
- Governance and Sharing are assumed: Really, you have to have these at all stages the data that is discovered, prepped, analyzed, and shared must be governed.
- There is no stage labeled Data Visualization! Why? Because you should be visualizing (seeing) your data at every step throughout the process. Data Visualization doesn’t happen after analysis. It happens during analysis as you ask questions and “see” answers that raise new questions. Data Viz isn’t the end-result – it’s the guide to the whole process!
(By the way, the cycle is why I love Tableau compared with other competitor products – the entire paradigm of Tableau allows for an iterative, free-flowing, ask-questions-get-answers-ask-more flow of thought that I’ve never seen elsewhere…)
Using Tableau only at the end…
Imagine a hospital with a lot of data – patient data, financial data, medications, procedures, doctors and more! And imagine that they want to understand patient care to make better decisions. One potential approach would be to identify a problem and a metric to track against the problem (e.g. Length of Stay), draft some data requirements (“we’ll have to have a table of each patient visit that tracks start and end dates and calculates the length of time”), process the data (take the various sources and bring it together into a set of reporting tables), perform analysis (let’s filter out certain sets of patients and do some statistical analysis to see things like the average length of stay), and finally visualize the data with Tableau (let’s make a bar chart or maybe even get fancy with a Gantt chart to wow management!)
At the very end of this process, in the best case scenario, the hospital has achieved their goal and now has some insight into the length of stay of various subsets of patients.
Leveraging the power of Tableau throughout the entire cycle…
I take Tableau and point it directly at the source system that tracks patient visits. The source system isn’t optimal, but I’m still able to report the length of stay metric without much data prep, so that requirement is met quickly. After some additional exploration I’m making new discoveries: There are patients who have lots of visits; that is, they’ve come back to the hospital numerous times. The length of stay might even be short, but they’re back in a few days. So then, I use Tableau to prep some data on the fly and join together some other source systems of diagnosis and medication data. I start to see correlations between certain diagnoses and medications that might predict which patients will be readmitted. I suggest building out a few data structures and a predictive model (did you know Tableau integrates with R and Python?) and I’m able to see the results of the predictions quickly and iterate through various groups of patients. Finally, I take some of the visualizations I’ve done all along the way and arrange them as an interactive data story to share with hospital management, showing them how patient care can be improved.
So, what should you do?
If you are using Tableau, but you see it primarily as just for making charts and graphs at the end of a business intelligence project, please reconsider. If that’s what you are doing, you are only getting a fraction of the insight you could have if you leveraged the power of Tableau through the entire cycle of analytics.
Instead, use Tableau throughout the entire project – for every stage. Allow it to guide the process as you “see” the data along the way. Make it a part of your culture so that you are iterative, rapid, responsive, inquisitive, always seeking new insights and asking new questions. And of course…