Data Visualization is taking over. To meet the onslaught of big data head on, more and more we see tools aimed at helping us make sense of all of this data. Programs, dare I say platforms, such as Tableau and Qlikview have made solid inroads with corporate finance and audit organizations to provide just such a service. They aim to enhance the quality of management and review of data about business processes through visualization.
While these tools are excellent for displaying your golf score averages, incorporating attributes such as temperature, elevation or other variables they excel, no pun intended, at bringing to life more complicated data sets in a dizzying array of charts, graphs, diagrams and even donuts, teasing out unseen or unknown relationships or outliers…But do they really? This new found communication vector masks a much more serious undertaking.
Key principles of data analysis and visualization remain despite the new tools which make it increasingly easier to communicate data relationships; understanding the underlying data, validating the data, applying a meaningful analytic to the data and only then visualizing the data.
The tool used to visualize data will only be as effective as the thought and preparation put into the data analytic performed to create the data set being visualized. Create too big of a data set, and you risk not being able to see critical small anomalies, restrict it too much and everything becomes an exception to be verified. A growing risk is the presentation of a large data set with vaguely defined visualizations that can drive dangerous assumptions.
While audit and business leaders may be effective consumers of structured data, the visualization tools allow users to skip basic validation efforts of data analysis and consequently, variation in interpretation and inconsistent analysis is bound to result. We find ourselves at once better informed, yet less able to react based on the information at hand.
Data visualization tools today are excellent and they have been a long time in coming to a world of impenetrable spreadsheets and tables, yet they do not address the very issue they are often brought in to help resolve and users can quickly become disillusioned with their effectiveness exactly because of their ease of use and powerful graphical abilities.
Compliance departments, business end to end processes and management take these tools and engage all of their impressive computing might to ferret out exceptions in order to drive process improvement. Or, so they think. This may appear to be a reasonable approach, but this is where Data Analysis and Data Visualization become entangled. Apparent insights quickly become diluted with inadequate visualizations because exceptions constitute a small percentage of the overall data set and are easily overlooked.
This is the sneaky true cost of data analysis; there are few shortcuts. Extracting exceptions from highly complex data sets requires not only business acumen but expertise and specialized data skills, logic and a true analytics capability.
There is no meaningful data visualization without rigorous data analysis.
A well trained analyst can extract the exceptions and create a valid data set using expert tools which can then be turned into helpful, easily communicated data visualizations.
Data analytic tools such as ACL or IDEA and even broader GRC tools will be more difficult to exploit, in part because they challenge us to think through the required analytics, but they offer true analytical capability. The key to a success is to be aware of the underlying requisite components of a data analysis and visualization program, realizing that they require different skills and different considerations; extraction vs. communication, definition of exceptions vs. overall health, etc.
To find the outliers and exceptions that we need to understand and prioritise process improvement, we need powerful analytics driven by people that understand the data and the processes. Then, on these exception data sets, we need visualization to drive the communication to management and stakeholders who are less expert in the detail. If you try to build exception analytics into visualisation tools you may need to start getting some detailed programming skills . . .
It is more important than ever not to confuse Data analytics with Data visualization when looking into the large data sets we now encounter. Today’s tools often blur the line between analysis and presentation making us all analysts at our own peril.
Author: Robin Ashby