Tableau Implementation Strategies-Which One Will Work Best For Your Organization?

Tableau Implementation Strategies-Which One Will Work Best For Your Organization?

By: Bridget Cogley & Preston Howell
May 11, 2018

*This blog builds upon a webinar conducted by Teknion’s Bridget Cogley and Joshua Milligan, both Tableau Zen Masters. The webinar can be viewed here:

What is the correct way to roll out Tableau to your organization?

This is a simple question that almost every organization we've 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: corporate culture, end users of the dashboards, and the state of the underlying data.

We've had the opportunity to see 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 not the same mistake others have made and make your implementation more successful.

The first place to start is by analyzing how your data sources are governed, and who will be analyzing that data.

How will the data be handled?

The methods range from having a Data Guardian in place to have Data Stewards in place. A Data Guardian protects the data, while a data steward welcomes a user to explore the data themselves.

How will dashboards be created?

Here, it ranges from a few experts to everyone in the organization. Traditional BI in the 1990’s and early 2000’s was slow and hard to use, so it required having only a select few develop reports. Tableau is fast and easy to use, so why not enable users throughout the organization?

We've seen six (6) primary strategies used by organizations.

  • Data as a Service
  • Web Edit/Data Democracy
  • Published Authority
  • Data as Software
  • Analyst as a Service
  • Traditional BI

Of those, we’ve seen the first five (5) implemented successfully, while Traditional BI has failed almost every time. (Read Why Here)

Take this quiz to learn which strategy may work for your implementation and read on to learn more about each of the strategies.

Take Quiz
 

Data as Software:

This approach is most commonly used when Tableau is deployed as a “product”. There’s a small group of people creating dashboards, but a large group of people consuming those dashboards. The data is generally handled by IT (who use ETL tools), and the dashboards can be handled by IT or the business.

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 is going to be branded ‘PATT’, and will be embedded into Salesforce, where it will be consumed by your sales team across the United States. This group of users isn’t extremely technical, 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 done through versioning and rolled 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 into the data steward role. Users managing the changes to dashboards tend to be smaller in number and may handle only certain facets.

Often, these solutions are embedded, requiring additional considerations in the development of dashboards. Some solutions may only deploy a chart-level approach, using another solution, such as HTML or JavaScript, to integrate the dashboard. Others may include the dashboard, but use action filters for navigation. These techniques further encourage a limited number of designers to prevent mishaps or extensive documentation requirements.

When This Works:

  • You are creating a tool for a group of end-users, and have a 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 want or need to explore their own 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 a 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 Server:

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.