Data visualisation – my favourite tool for customer development

Continuing our theme on your favourite tool, I was surprised by the suggestion of Data Visualisation.

Despite not being what I thought of as a software tool, I think guest blogger Hanne Sorteberg makes some helpful points in this post. So, I am delighted to welcome back Hanne. She has previously blogged for us on Data Science, role definition & The Goal.

In this post, Hanne makes the case for data visualisation being a key tool to data driven culture change. She shares honestly what has worked for her & what has gone wrong. I’m grateful for her candour & pragmatism. I hope you find this post helpful, especially if you have BI responsibilities.

Data-Driven means you need Data access & insights

“Data-driven” is the mantra for much organisational development these days. For setting the right strategic direction, product management and customer insight.

Data-driven can mean entirely different things to different organizations. It can mean using excel for sales reporting or analysing trends in Google Analytics. All the way up to developing advanced data science models for prediction and even automated prescriptive processes.

My claim is that to be truly data-driven, data insights must be distributed across business units. Key business roles must have direct access to all relevant data sources in a way that makes the data easy to understand.

At a former employer, I was part of a journey to take my entire organisation from “data reporting” to “data insights“. The starting point was a comprehensive data warehouse serving all business units, with standardised static, historic reporting, and some ad hoc data deliveries.

My organisation would claim to be data-driven at this time. There was even a big data project under way. However – there were several issues with providing data to the various business functions:

• To get data, you needed to contact the data warehouse department and order a “data extract”. This would be a CSV file or excel sheet. To use the data, the recipient often needed to manually re-work the data to present them in graphs and/or powerpoint. These files were in turn sent by email to reach the right recipients.
• Data warehouse deliveries of data could take several weeks, depending on work load which was unpredictable. There was a lack of clarity as to how and to whom requests should be directed.
• There was a great distance between business users and data warehouse resources. Unclear requirements, definitions and business rules would result in data deliveries that did not meet the business user’s expectation. Even a small change such as a different aggregation level or a new grouping would result in changes, and a new round of requirements, a new extract and even longer lead time to get value from the data.
• The cumbersome path from data need do data delivery resulted in a situation where data was used solely for reporting historical data, and not actively used for strategic direction and decision making.

Enter Data Visualisation and the roles to implement it

The technological solution to solve these issues was to acquire a data visualisation tool that could build reports on top of data sets customised for reporting and analysis.

Buying the tool and building the data sets was the easy part. The hard part was to implement new roles and processes in the organisation.

We started out by defining two new roles:

Business analyst – a role in the business with responsibility to get value from data

This role would cover:

• Continually perform data analysis to understand their business domain. Create visualisations and reports to share their insights with the rest of the organisation. This could be a KPI dashboard for the management, operative dashboards for the call centre, or predictions as input for strategic processes.
• To create these insights, they required a set of customised data sets with data from their business domain. These data sets has keys to couple data from other sources, such as basic customer and product records, or data from other business domain. The Business analyst is responsible to create requirement specifications for a these data set as a basis for self-service reporting from the data warehouse.

The business analyst role is coupled with a Business architect.

Business architect – a role in IT/BI with responsibility for a business domain

This role’s responsibility is to:

• Design and develop data sets for self-service analysis and reporting according to business’ requirements
• Actively manage and further develop delivered data sets, and actively support the utilisation of the data set / data solution
• Document data sets, definitions and business rules in a way business users can understand

How Data Visualisation helps more agile BI development

The visualisation tool lets analysts play with the data sets built by the business architects. When an insight is reached, or a boring sales report is needed, the business analyst will publish an interactive report with graphs, tables and filters as a web page. The link is sent to whomever is interested, or published to an intranet site.

If you have the right credentials and permissions, the report is always available and updated. No emails, no slides to manually update. A lot of work and hassle is saved, and the ease that comes with experimenting data in this way frees time to look into the future and predict, not just report on historic events.

Redefining the data warehouse roles was not so much of a challenge. Well-defined processes for prioritization involving the business analysts helped free time to focus and specialize on business domains.

The hardest part was to establish the business analyst roles across the different business areas. This role was to a large degree lacking. Some units already had an analyst in place, now very happy to get better tools and data sources. In some cases, we had success in re-educating employees in a similar role, such as a business controller or administrative support.

Other parts of the business needed to recruit people into these roles. Showing success stories and being persistent in selling the value of systematically working with data, gave results over time. Today, all units have at least one business analyst or similar role (and cannot imagine living without).

Invest in the new roles that emerge as needed

To support the business analyst, a Visualisation tool expert role was hired to provide education, structure, and keep track of cool new functionality in the tool.

After a while, basic needs for reporting and distribution of data were covered. The new set-up freed time to evaluate the value from introducing even more data sets, such as web traffic, external registers and social media. The use of algorithms and models would evolve to be more advanced.

After a while, a new problem arose – we had too many reports, too many visualisations. If you have 10 reports covering the same business domain, you may not trust any of them. The need to define a report editor arose.

Each business area was responsible for maintaining public reports for their own business domain. Many of these reports would be available on the intranet for all employees. Customised reports may be shared with partners and customers, but requires a review of network and security access.

The big data project failed. It was a project initiated and run by the data warehouse, without establishing and anchoring the business need and value. All further development in the new organizational model is driven by the business through the business analysts.

Sending excel sheets via email is completely obsolete after completing this journey, and I believe many businesses have successfully distributed the power of data visualisation. However, whenever I share this story, it resonates with many of my data savvy colleagues. They have the technology, but not the mandate or power to change their organisation and processes.

The right approach to avoid failure in your organisation

To embark on a similar journey, I think the right approach is to start small, show and tell, and persistently evolve.

There’s a plethora of reporting and visualization tools out there. The tool from this story is Tableau, but I have also achieved great results with Power BI.

Tableau is beautiful, has a vast connection to data sources and handles huge amounts of data, but licensing cost may be inhibitive to get started, and the extra cost for each developer makes every new business analyst a business case for new licenses.

Power BI is more limited in the size of data you may handle, and which sources you can connect to, but is often sufficient to cover the usual business needs and technological set-up.

Selecting your Data Visualisation tool

I would go for Power BI to get started. It is easy for an excel user to make the leap as the syntax is basically the same, and it has low cost. New developers may be added without extra cost (but to publish you need a license). If and when there is a need for more support of data sources and/or size, the case can be made to upgrade to Tableau or another more advanced tool.

For a more technical and comprehensive comparison of Tableau and Power BI, I think this source from EDUCBA sums it up nicely:

Good luck on your data visualisation journey.

How has Data Visualisation helped you as an Insight Leader

Thanks to Hanne for sharing such a candid picture of both what worked & what failed. I hope the role effective data visualisation can play has sparked your own ideas.

Do you have any lessons to share on using this ‘tool‘? Is Data Visualisation your favourite tool? How has data visualisation helped you advance Customer Insight or overcome challenges?