Perhaps you’re new to your organisation and are taking advantage of that brief honeymoon period. Or your boss just came back from his latest conference all enthused about “business intelligence”. You’ve done your research and decided Tableau is the tool your organisation needs. You have the budget. You are go for launch…
Congratulations. You just finished the easy bit.
You want to make this work, so you need a plan. You’ve some up-front design decisions to make. And you’ll be faced with 101 executive decisions during implementation. All of which will have a significant bearing on the success or failure of your implementation.
I’m not going to give you a template plan here – your plan will vary greatly dependant on your circumstance. This article is based on our experience rolling out Tableau on both a small and a larger scale and offers you some guidelines on making the best of it.
Not so much a recipe for success, as a list of key ingredients that your recipe (your plan) should include.
Tableau is a great product but it can only ever be as good as the data you feed it. As a tool, it has an increasing repertoire in data processing, reshaping and joining.
Try not to use them.
Don’t get me wrong – they are good, and very useful on occasion. But as a matter of design you should try and do as much of the data wrangling before the data gets to Tableau. A design feature you should aspire to is compartmentalisation, separating the management of data from its presentation.
Management, and manipulation, of data should be done in a database. (Clue’s in the name: that’s what they are good for.) If you have an Enterprise Data Warehouse (EDW), great, use it. If you don’t, you have three options:
- Get an Enterprise Data Warehouse. It’s a good idea. However, you do not want to couple your Tableau roll-out plan to an EDW implementation if you can help it. Either do them sequentially – EDW then Tableau – or go with an interim basic database, and ‘transfer’ your standard datasets into the EDW (a separate project) once it is up and running. The latter will get you up and running quicker, but will be more work overall.
- Invest in a basic, but proper, relational database. Leverage whatever technology you already have / are familiar with, e.g. SQL Server, MySQL, PostgreSQL, Oracle. If you do not have someone on your team who is proficient in SQL, acquire one. Borrow them from another department, hire a contractor, whatever it takes. Do not be tempted to save money by letting an existing member of your team, keen but inexperienced in SQL, learn-on-the-job whilst implementing what will be a key system. This is a false economy. Your implementation will over-run, be glitchy and difficult to maintain. You’ll probably also end up with a single point of failure, with learn-on-the-job Bob being the only person who understands what they’ve done. If money is tight go with a free open-source database rather than skimping on the skills to set it up.
- Do without a database. Use Tableau to draw directly from your various data sources: Excel, text files, directly hooked into administrative system databases (these are in order of desirability: links to Excel worst; text files less bad; direct links to other databases best). If you are a department of one in a small company and/or virtually all your data comes from one source (which you can link Tableau directly to), then this might be ok. But as a rule you should really try and avoid this. As a set-up, this ‘system’ will break easily and often. Someone will mess with your Excel contents, rename folders containing text files, suppliers will update their admin systems: you’ll end up spending a significant amount of time fixing things.
You want to end up with a database which contains a series of ‘standard’ datasets. Views of your data – structured like single tables, similar to that you would need if constructing a pivot table in Excel – which will be used as data sources in Tableau. Exactly what these are, how many, how detailed, should be driven entirely by your business requirements. The 80/20 rule of thumb holds here. Aim for the minimum number of standard datasets which could underpin c.80% of your reports. Too few and you’ll end up without adequate control of your data. Too many and you’ll end up wasting effort producing and maintaining datasets that are rarely if ever used.
You should err towards these being as granular as possible. Databases, and Tableau, can handle millions of records without breaking a sweat (volumes which would cripple your PC if you were trying to pivot in Excel). It is generally no more effort to set up and maintain and it gives you the option to report at any level of aggregation subsequently. For example, in a hospital setting you would want an Emergency Department dataset with one record per individual patient contact (attendance), not one which gives you simply a count of attendances with one record per day.
Establish a strong change control process for these standardised datasets. If you do not, you will find that, over time, your datasets get fat and unwieldy. People will add more and more fields to them, they will quickly get confusing to use and the risk of producing erroneous reports (e.g. by using a field inappropriately) will increase exponentially. You need to be quite draconian to prevent this. Only add a field if you are sure it will be used/needed by multiple reports. Ensure that fields added are helpfully named and documented.
If you find yourself needing to add fields to a dataset which you know are only needed temporarily, try very hard to find an alternative. Removing fields from standard datasets is something you want to avoid, as doing so will break any report which uses that field. Minimise this by being über-careful about what fields you add in the first place, rather than being über-relaxed about removing redundant fields.
If you find yourself wanting to change the definition of what a record is, don’t. Instead create a separate (new) dataset. For example, perhaps you have a standard dataset of customer orders with one row per order. But each order can be for more than one product and you’re tempted to modify it so that there is one record for each order/product-combination. Don’t. Create a separate products-in-order dataset instead. The definition of a record in your standard dataset should be set in stone. (Change it and you’ll most likely break every report which uses it.)
How will users access reports?
You have three basic options when rolling out. (Clearly you should decide which is best for you before you place an order.)
Use Tableau Online. This is a managed cloud-based service hosted by Tableau themselves. Your data (or a copy of it) will be stored on Tableau’s servers, secure but technically outside your direct control. All software updates, server management etc. are taken care of for you. You will need to purchase a licence for each user. Reports are accessed by users from anywhere (with internet access) – work, home, mobile device – by navigating to a web page and entering a username and password. To create and publish reports your developers will each need their own copy of Tableau Desktop. Best for smaller companies – with small, predictable numbers of users – who are comfortable with their data being hosted in the cloud.
Use Tableau Server. This can be installed either on a cloud-based server (in which case it has all the attributes of Tableau Online except you are responsible for managing it) or on site. If on site, it will be ‘within’ your network, all your data stays on-site. Users access reports via a web browser, but must be connected to your company network. You purchase a licence for a server: there is no limit on the number of users. To create and publish reports, developers require their own copies of Tableau Desktop. Best for larger companies, those with a large number of occasional users, those expecting to scale rapidly, or who cannot permit data to be stored off-site.
Use Tableau Desktop only. This scenario is the cheapest – with no need to purchase Tableau Server or subscribe to Tableau Online – but you are giving up a lot of the benefits. You will not be able to produce reports which automatically refresh when new data is available, only static snapshots. Best if you only intend to use Tableau as a tool for analysts doing ad hoc analyses and data presentations (as some management consultancies do).
(Most of the advice in this article assumes you will be using Tableau Server or Tableau Online.)
How will users find reports?
The traditional way to organise reports is to store them in folders. Perhaps on a shared drive where everyone can access. But your users will be accessing your new Tableau reports via a web browser, so how will they find them? Tableau Server is structured around ‘Sites’ and ‘Projects’. Think of ‘Sites’ as being like different drives and ‘Projects’ as being like folders on those drives. With the added restriction that ‘Projects’ cannot contain other ‘Projects’ (no nested folders). Tableau also offers very good ‘search’ functionality. Users can search by date, name, ‘tag’, name of publisher or even for all reports containing a given word.
It is entirely up to you how you use these. You will end up using some combination of the two approaches: folder-based and search-based. Think of it as a continuum. Exactly where you plan to sit on that continuum will depend on your users’ expectations, company conventions, your workflow for monitoring / archiving reports etc.
A more folder-based design might be more familiar to users – “I go to the
Board Reports ‘folder’ to find the performance dashboard”. But it will be significantly more onerous to maintain. As the number of ‘folders’ grows, the ease with which users can find what they’re looking for rapidly diminishes.
A more search-based approach is to have only a small number of ‘folders’ and rely on users finding reports by either searching for them, following a direct link to them (e.g. from an email) or via their saved ‘favourites’. This is much easier to administrate. The ease with which users can find things is not impacted greatly by the number of reports you have. However, some users may baulk at the lack of structure they’re used to.
If you need more control over how users find reports you could build your own ‘portal’ web page, integrated into your company’s intranet. (At a pinch it’s even possible to do this using Tableau itself.) But if you are going to develop your own portal, please make sure you have the necessary web-development skills in your team, and plan the time to do it well.
Migrating reports into Tableau
As part of your roll out plan I strongly recommend picking a few (no more than five) key existing reports to produce Tableau versions of. Ideally they should be well used, but currently badly designed, existing reports. Budget statements for managers. A sales dashboard. Or a view on hospital bed occupancy. You want to ‘launch’ with some really good, useful content. It will set a good precedent with users – who will want more – and lays down some best practice that your developers will copy and carry on.
Now – and this is very important – I do not mean for you to literally copy the existing report. You are not trying to make it look exactly like what they had before. (Not least because what you’re replacing was terrible, right?). Please reproduce what the report was for, not what it was. If the report you are reproducing is for detecting outliers in hospital waits, use Tableau to show that graphically, make it interactive, allow users to drill down. Don’t just reproduce the static table of numbers the old report was.
Tableau is very easy and intuitive to use, but you still need to plan for some training and familiarisation. Off the back of the key reports you plan to launch with, build a 45-minute training/how-to session and practice until you can comfortably deliver it in 15-30 mins (without interruption). Back this up with a single-page hand-out which users can pin to the wall and use as a crib reminder. If you have a small concentrated set of users, you might even try to train them all in one go. A better idea, if you have a wider potential audience, is to schedule a series of drop-in sessions for user training. Provide lunch or think of other ways to encourage attendance. Have more than one person able to give the training, and be prepared to do a number of 1:1 sessions whether you plan them or not (“the Chief Exec’s got 20 mins free at 2pm and would like to know about this Tableau thing”).
Create a page on your intranet with links to training documentation, dates, FAQs and other Tableau-related information. Include links to select relevant examples of Tableau’s own online training. Consider making short screen-recording demonstrations showing how to use your own key reports.
If you have developers – those who will be using Tableau Desktop to produce new reports – in different locations or teams, run a monthly ‘Tableau Developers Meet-Up’ where you can share experience and best practice, refine conventions, discuss data quality issues and new data / reporting areas. Be disciplined in trying not to let this get out-prioritised by other things, it will make a big difference to the quality of reports in the long run.
It is possible to get very fancy with access permissions, only letting select users see select reports (or even select data within a report). But you should try and keep it as simple as possible. As a good rule of thumb make it the default – when publishing a new report – that everyone in the organisation can see it unless there is a really good reason why not. Is there really a good reason why Sales Team A should not be able to see Sales Team B’s figures as well as their own? Often not. But if you secure reports unnecessarily, along these lines, you will end up with reports built for one team which could, with minor tweaking, have been generalised and made useful to all teams.
If you do need to lock down access, try to leverage existing mechanisms for assigning permissions (e.g. use ActiveDirectory groups maintained by your IT dept). Ensure you have made adequate provision in your plan to set up and test these. And the resources and processes in place to manage permissions thereafter.
There are many conventions and protocols you will establish. Some key ones to think about before you start.
You should decide from the outset what your approach to publishing new reports / dashboards is. Specifically, what, if any, level of approval does someone need to publish something. Your broad options.
- Approved-content-only. In which all newly developed reports are required to be checked and approved by a central authority before they can be published. Gives you maximum control on quality, but very difficult to make work in practice. Do this and you’ll get a bottleneck at the approvals step and end up discouraging people creating content (and they’ll find undesirable ways to circumvent)
- ‘Kite-marking’. In this model, select key reports are subject to formal checks, and given a ‘kite-mark’ if meet the required standards / conventions. But developers are free to publish other reports without this restriction. Good, but requires continuous management to ensure kite-mark retains its meaningfulness and integrity.
- Free. The most unrestrictive option which trusts developers publish without formal restriction. Just be sure that you have a good process to moderate content and to keep things under control.
As a rule, you want to maximise the freedom for developers. Doing so means they are more likely to create reports / dashboards and less likely to circumvent due process (e.g. by reverting to Excel or using Tableau to produce PDFs and manually emailing it out).
Enabling access to underlying data
You can enable or disable users from being able to access the raw underlying data in your reports. You can set a default, and it can be set for individual reports at the time they are published. Decide what the default should be – enable or disable – and define the circumstances under which it will be appropriate for developers to over-ride this default. If you do enable access, be sure to cover this in your training. If you don’t, have a prepared answer to the “how do / can I get the underlying data?” question you will inevitably get from users.
Tableau’s system is founded on an ethos of ‘self-service’. Users go and view a report, when they want to. This is a ‘pull’ model of distribution. Many managers will be used to, and indeed will ask for, a ‘push’ model of distribution (“please can you ensure this report gets emailed to the whole sales team every Monday morning”). Tableau allows users to subscribe themselves to receive a report by email, but – at time of writing – there is no built-in way for a central team to subscribe others. There are ways around this if you really need to do it.
Make use of Tableau’s (self-)subscription model and you will end up with happier users. They don’t get ‘spammed’ with reports they are not interested in. (You retain the big-brother power to be able to see who has subscribed, who is viewing reports, and who is not.)
You will make your life a little easier if you settle on a common Tableau-specific vocabulary. The list of key terms is short: reports, dashboards, dataviz, workbooks, tabs, worksheets, parameters, menus, refresh, export etc. Include it as a glossary alongside your FAQ document. Exactly what that list of key terms is will probably become most apparent when you construct (and deliver) your training to users. Exactly which terms you use, where there are competing alternatives, is not that important. Don’t get upset if your users want to keep referring to your new lovely interactive Tableau dashboards as “reports” rather than “dataviz”. It doesn’t matter. Settle on terms which sit best with users, not with developers. What does matter is that there is a clear, common understanding of what those terms mean. If a user rings you up for help and you tell them to “refresh” the page, you want them to know exactly what you mean.
Bear-traps to beware of
Here are a few things which have little in common other than their ability to cause annoyance and mishap unless you take care.
Date formatting. Tableau is excellent at dealing with dates. It can easily show dates in the context of fiscal years over calendar years for example. But it does want you to hold your dates as dates. If your datasets traditionally have fiscal dates stored as a month field (“M1”) and separate financial-year field (“2015/16”), you should convert these to genuine dates in your data warehouse. The conversion is easy, the benefits large.
Dashboard sizes. When you are publishing dashboards you can set them to publish as a specific size or allow them to resize automatically. Experiment with different sizes, testing them on different monitors / laptops / mobile devices to see what works best. And establish some conventions. Fixing the size means that on some monitors the user may need to scroll to see the whole dashboard or the opposite, that the dashboard leaves large areas of white space on the screen. Allowing it to size automatically solves this, but can result in the layout not appearing exactly as you intended. These aren’t fatal problems, but they can be annoying.
Check your web browsers. Hopefully your office environment is festooned only with the latest and greatest in internet browser versions. If your users are surfing with Internet Explorer (IE), please make sure they are using version 9 or higher. (Anyone using Chrome, Firefox or Safari should be fine.) If they don’t, you will need to have a plan to rectify this – ideally get them upgraded, or install Chrome or Firefox. As a rule of thumb, if you have users still on Windows XP, they probably have a too-old version of IE.
You need to have a plan around upgrading. For general users – those just accessing reports through their browser – there is no issue. But you will need to decide how you manage upgrades for your Tableau Desktop users, your developers. The latest versions of Tableau Desktop check themselves for updates. Are you going to rely on / let users update themselves? There is no right or wrong answer, it’s whatever works for you. However, your convention on this should always ensure that your version of Tableau Server is the same or newer than your Tableau Desktop version. If you try to publish a report to an older version of Tableau Server than your version of Tableau Desktop it may not work. (If you subscribe to Tableau Online this won’t be an issue as it will always be running the latest version.)
As you can see, there is a lot to consider when rolling out Tableau. (Most of the points above will apply if you were rolling out QlikView, Microsoft BI or any other business intelligence reporting system too.) This isn’t a complete list, but if you can tick these points off you will be well on your way.
I hope you found this article useful. I wish you luck on your implementation – if this is you – and, if we at Urban AI can assist you, please do get in touch.