What is the correct way to roll out Tableau to your organization?
This is a simple question that almost every organization we have worked with has asked. Sadly, the answer isn’t as simple as the question. As with many areas of Tableau, the reality is that a single strategy will not work at every organization. There are numerous variables at play that influence whether a given strategy will be successful at an organization, including: the health of corporate culture, the proficiency of dashboard end users, and the state of the underlying data.
We have had the opportunity to serve many organizations that span the range of possible Tableau implementations. Some of them have been wildly successful, and some of them have failed miserably. This implementation blog is our effort to help you avoid making the same mistakes others have made to give you the best chance for implementation success.
The first place to start is to analyze how your data sources are governed and identify who will be analyzing that data.
How will the data be handled?
Your methods for handling the data should include employing a single Data Guardian to protect the data and establishing multiple Data Stewards to assist users with exploring the data themselves.
How will dashboards be created?
Your dashboard creation process could either depend on a few resident experts or could include everyone in the organization. Traditional Business Intelligence (BI) in the 1990’s and early 2000’s depended on a select few members to generate organization-wide reports because it was slow and hard to understand. Tableau is fast and easy to use, so why not enable users throughout the entire organization?
We’ve seen six primary strategies used by organizations.
- Data as Software
- Web Edit/Data Democracy
- Published Authority
- Data as a Service
- Analyst as a Service
- Traditional BI
Of these six, we have seen the first five implemented successfully, while Traditional BI has failed almost every time. (Read Why Here.)
Data as Software
This approach is most commonly used when Tableau is deployed as a “product”. A small group of people creates the dashboards while a larger group consumes them. The data is generally handled by IT through the use of ETL tools, while the dashboards can be handled by all members of the organization.
This strategy may work for you if the following situation sounds familiar:
“Tableau has been selected as the tool of choice for a new data project. This project, branded as ‘PATT’, will be embedded into Salesforce and consumed by your sales team across the United States. This group of minimally technical users needs data to drive their decision making but has no interest in doing their own development”.
This approach leverages analytics to create a product that is used across a wide array of users. Dashboards are viewed and treated more as a fixed solution than as a dynamic resource or ad hoc tool. Changes may be made through versioning and approved through a Software Development Life Cycle (SDLC) process. These types of implementations are common when Tableau dashboards are deployed to outside users. Data requirements are highly structured but often cross a number of functional departments; thus, falling under the responsibility of the data steward. Users managing the changes to dashboards tend to be smaller in number and may handle only certain facets.
These solutions are often embedded, requiring additional considerations in the development of dashboards. Some solutions may only deploy a chart-level approach, using HTML or JavaScript to integrate the dashboard. Others may include the dashboard but use action filters for navigation. These techniques further encourage the need for a limited number of designers in order to prevent mishaps or extensive documentation requirements.
When This Works
- You are creating a tool for a group of end-users but have limited ability to train or educate.
- These users have little to no interest in creating their own ad hoc analysis and will benefit from easy-to-understand visualizations.
- The owners of the data are able to work closely with the individuals responsible for creating and maintaining the new tool.
- You roll updates out in a set period of time (generally monthly or quarterly).
When This Can Fail
- Your users try to explore data in their own ways. If this is the case, they’ll just dump the data into Excel and do their analysis there.
- The developers of the dashboards aren’t able to work closely with the owners of the data.
- You want to empower analysts to slice, dice, and analyze the data however they want.
In short, this rollout strategy works when you are rolling Tableau dashboards out as a sort of ‘product’. These could be internal facing dashboards or external facing dashboards, and can be accessed via a website, embedded BI portal, Salesforce, or the Tableau app.
Web Edit/Data Democracy
- Users have tiered access to Tableau. Power users are Tableau Creators, with access to Tableau Server, Desktop, and Prep, while others are Tableau Explorers who create or edit via the Web Edit functionality of Tableau Server.
- The organization may use a variety of certification methods to authenticate dashboards.
Web Edit/Data Democracy is the denouement of the Data as a Service rollout strategy, as it opens access to nearly all users. Both of these strategies empower organizations through published data sources, and they have many similarities to the Published Authority model (lots of people connecting to published data sources). Where they differ is that the Web Edit/Data Democracy utilizes a newer concept in the industry: Data Stewards.
A Data Steward can be from IT or from the business side and is responsible for maintaining data sources that exist on Tableau Server. The Data Steward should be someone who understands the source systems and what they are useful for, which enables their data sources to be extremely powerful for others as they create visualizations. The Data Stewards utilize Tableau Prep to create and maintain powerful data sources. The Tableau Data Sources that they create should have default formatting applied, calculated fields added, and comments where applicable – this all makes it easier for the end users.
A worry that organizations have with these approaches is the risk of unchecked proliferation of data sources. This is where data source certification comes into play: as data sources are created, the Server Admin, Site Admin, or Project Leader can certify those that are good to go. When a user wants to connect to data sources, these certified sources will be recommended to them.
When This Works
- Business users with knowledge of the source data exist. These become your data stewards.
- Your organization wants to empower users of all varieties to explore and analyze data.
- You don’t expect a select few to be responsible for creating content on your Tableau Server.
- People throughout the organization use data to drive decision making.
- Users are given access to a wide variety of data sources, even if they aren’t immediately necessary for them.
- Business users need to be able to quickly make changes to dashboards.
When This Can Fail
- IT has a strong grip on the data, and wants to heavily limit who sees what.
- Your Data Stewards have a poor understanding of the data.
- Server Admins are too hands-off, and don’t certify data sources or monitor performance/usage.
- There is not enough support or ongoing education for business users.
- The server is allowed to ‘sprawl out’ and is not monitored.
- There are not enough champions to support and manage the program.
Published Authority
This approach is most often used when the data sources published to Tableau server are controlled, but a wide range of analysts (and even some non-analysts) can connect to the data sources. This is the approach that Tableau initially supported when they introduced Server.
This approach involves publishing data sources for business users to connect to when they want to perform their analysis. It requires a significant amount of support from IT or a highly empowered business unit with appropriate access to create and maintain the data sources.
If you rolled out Tableau Server early in its existence, the Published Authority model was likely recommended to you.
In recent years, the BI environment has been shifting to a Data as a Service <Insert Anchor> model as it enables more rapid development and greater flexibility with ad hoc analysis.
Published Authority allows Tableau Server to act almost as a staging area for data, in addition to a place to host visualizations. It provides a number of approved sources for analysts to begin understanding their business
When This Works
- You have strong support for a server-centric environment
- Your publication authority is responsive to demands around data
- You want to empower analysts to slice and dice and analyze a predefined data set however they want.
- The data sources involve connections to databases that business users don’t have access to.
- You want to limit the number of spreadsheets used as sources.
- The data is extremely secure/insured, but you still want to empower business users to explore their own data.
When This Can Fail
- IT is not able to devote the resources to create and maintain data sources. This should cause a shift to the Data as a Service rollout.
- Your users have no interest in exploring the data on their own.
- You’re using too many outside sources to keep pace with data demands.
- Users require greater flexibility/assistance in the creation of data sources and visualizations.
- The business users have a better understanding of how to use the source data for the sake of their analysis than IT does. This should cause a shift to the Data as a Service rollout.
- You are creating a product with Tableau.
Data as a Service
Almost everyone in the organization has access to data (both analysts and non-analysts). Some data sources will fall into a published authority model (handled by IT), but other data sources can be maintained by users familiar with that data. Data stewards utilize Tableau Prep to create and maintain data sources. Server admins can utilize certification to approve even excel-based sources managed by an analyst.
The most data-driven of organizations tend to have a Data as a Service or Web Edit/Data Democracy rollout. These implementations are very similar, and primarily differ in how content is created in Tableau.
In a Data as a Service rollout, visualizations are created by Tableau Creators (i.e. users who have a copy of Tableau Desktop and Tableau Prep). In a Web Edit/Data Democracy, visualization creation is shared by Tableau Creators and Tableau Explorers.
Analyst as a Service
This approach can alternately be labeled as “internal consulting”. The data can be almost any source, and is not necessarily handled by IT. But, there is a small number of analysts actually creating dashboards.
We rarely see Analyst as a Server strategy used, but when it was, it was implemented successfully.
You may want to utilize this strategy if the following situation sounds familiar to you:
“The Accounting department is kicking off a project, and they need to bring in some data experts. They send a request to the department with the experts (Analytics, BI, IT), and get a resource assigned to them. Once available, that internal resource and Accounting start working together. This resource is paid by the accounting department and comes out of their annual budget”.
In essence, this is internal consulting. If the rest of your organization behaves like this, odds are that your visualization will follow suit. Your BI department can provide the specialists, who will come in and act as a data steward and dashboard developer. Because of this, the number of individuals developing dashboards will be smaller.
When This Works
- Charge-back is common in the corporate culture
- You have a dedicated team of analysts that are cross-functional
- You have a wide variety of data sets, but few qualified analysts
- Departments want to limit ad hoc analysis
When This Can Fail
- Charge-back is an atypical practice
- Time constraints demand ad hoc analysis
- Demand outpaces the team’s ability to provide services
- Departments operate at vastly different data literacy levels
Traditional BI
Read our more detailed opinion on Traditional BI implementation here.
Share:
