BI Resources

Data transformation is an essential part of the BI process. Businesses need to turn their raw, unedited business data into actionable, insightful data implications. They can't do that without transforming their data in new ways.  However, many businesses don't want to invest in data transformation. They think it's overly complicated, and not worth the time. They don't want their employees working on data transformations when they could be doing real data analysis.  Data transformation is worth the time, but it is true that it can be overly complicated. A single BI tool might offer two dozen different transformation techniques, without providing guidance on how to use any of them.  Just looking at a data transformation feature can be daunting. While a lot of work has been done to make data transformation easier to perform, employees can easily get overwhelmed by all of the choices that they have.  The core problem here is that BI users don't know what different data transformation functions do, and how they can be used to make raw data more actionable. This glossary is here to help with that.  We've listed some of the most common data transformations, and explained what they're for. This way, you can transform your data in a more effective way.  Add Constants - This transformation can add a new column to your data set that contains a constant value. That constant value can be a number, or it can be some kind of text.  This transformation is useful for keeping data from multiple sources straight. For example, if you're joining data from different branches, you can add the name of the branch as a constant to each individual data set, so you know where each data point came from.  Alter Columns - This transformation is used to change the data type of a column. Sometimes, a data integration will incorrectly transfer over numbers as text columns, or not effectively recognize dates or monetary information.  Using this transformation, you can tell a BI tool what kind of data is in a given row. This way, it can run content-specific analytics on that row, like ordering dates based on recent-ness.  Append Rows - An append is one of the major techniques for combining data sets. In an append, the data to be appended is added to the bottom of the original data set. For best results, the columns of both data sets need to match.  It can also be used in cases where columns don't match exactly, but that'll leave the data set with a lot of null values. It's best for updating old data sets with newer data from the same source.  Calculated Field - This function can add a calculated result to the data set as a column. It uses a formula to power this result. For instance, you could add a column that's a multiplication of the data from another column, or divide one column by another to get a new value.  This is useful for situations where end users will need a derived value that's not in the original data set, but can be added easily with a basic formula. Using SQL queries, these formulas can get more complicated.  Combine Columns - This simple transformation merges two or more columns into one, unified column. This takes all of the content from the original rows, and adds it to a new, combined row.  A user might want to combine two rows to group content in a more effective way. For example, they might combine 'First Name' and 'Last Name' columns into a more useful 'Name' column.  Date Operations - This transformation is similar to a calculated field, except it uses date data instead of integers. With this function, users can derive new dates from their other date fields. This is useful if there was important date data left out of the original data set. For instance, you could add a month or a year to a data set that just had raw MM/DD/YYYY data.  Deduplicate - Deduplication is a process that removes duplicate rows from a data set. This function allows users to run that process on their data set automatically.  While deduplication can be useful for removing errors from a raw data set, it's really useful for removing duplicates from combined data. A join or append can easily result in duplicate rows, but this function can automatically clean that up.  Filter Rows - This operation allows users to define filter rules for their data set, and then filter out any row that has data that does or doesn't meet those rules. Users can filter out specific dates, text strings, or numbers.  It's particularly helpful for filtering out incomplete data. Often, data sets will include rows that don't have all the data that they need to be effective. These null data points can throw off analytics if they're not filtered out.  Group By - This function allows for aggregation of data based on a single shared characteristic. For example, if you have a data set with multiple entries for the same dates, you can group by date to aggregate all that data under a single entry.  Businesses can use this to aggregate large data sets into smaller, less detailed data sets that provide broader views. It can also help to aggregate data sets so that they can be joined with other data sets more effectively.  Join - A join is one of the most common techniques for combining data sets. In a join, the columns from one data set are added to another data set to create one large dataset. To do this, the data points in at least one column of each data set need to match, so that it's clear where each data entry should go.  There are a few types of join, depending on which columns need to be kept and which should be discarded. For example, a full outer join includes all the rows from all the data sets, while an inner join only keeps the columns that match.  Joins are extremely effective for combining data from different data sources. Users can look for shared data points across their data sources, like dates and sales IDs, and then join related data points to get a wider view of their operations.  Pivot - A pivot transformation can turn a row in a data set into a column. The data is 'pivoted' from a vertical row to a horizontal column or set of columns. This allows users to widen their data sets or fix data sets that were badly integrated.  Pivots can help users to arrange their data in more useful ways. With pivots, users can highlight the metrics that are really important without getting a new data set or changing their integration. Sometimes, pivots can even help in aggregating data.  Rank - A rank transformation evaluates the data in a given data column, organizes it in some consistent way, and then filters out all rows that fall above or below a certain threshold.  For example, a sales manager could rank all of their salespeople by their total revenue, and then filter out all but their top 50 best-performing. This way, they can run data analytics to figure out what makes a salesperson successful.  Replace Data - This transformation allows users to replace all occurrences of a specific text string with another text string. It's like the find-and-replace tool that you might find in a word processing program.  Sometimes, a data source may express a specific data point in an ineffective way. For example, it might abbreviate the names of the months, which throws off visualizations that look for full month names.  With a replace, you can replace abbreviations with full text, or replace full text with abbreviations. You can edit any text string and replace it with more effective data.  Select Columns - Using this transformation, a BI user can delete, reorder, and rename the columns in their data set. This way, they can configure their data set to be just the way they want it.  This function is also essential for properly joining data. Using this function, you can make sure your matching columns have the same name, so that it's easier to join them later on. They can also remove columns that they know won't be useful.  Split Column - This transformation can split one column into multiple columns, distributing that column's content across the new ones. To do this, it looks for a delimiter, like a comma or a period, and sorts everything between the delimiters into new columns.  For example, you might have an 'Address' column that you want to make more granular. Using the split column transformation, you could split it up into 'Street Address', 'City', 'State', and 'Zip Code' columns, as long as commas or other delimiters separate those data points from each other.  String Operation - This somewhat technical operation allows users to put specific text strings out of their text-based data entries. By defining some simple rules, you can cut out irrelevant content from your text entries or add and remove spaces.  For example, a business may use a 15-number SKU to label its products, but only the last 5 numbers actually mean anything; the rest are zeroes. With a string operation, they can cut out all of the useless zeroes to use their SKUs in a more effective way.  Text Formatting - With the text formatting transformation, businesses can fix minor formatting problems with their text entries. This transformation handles the smallest, mostly cosmetic errors; larger errors need more powerful transformations.  Using this transformation, a business can change the case on their text entries, switching them into all uppercase, all lowercase, or using title case. They can also remove numbers from their text data, or only show numbers and remove the text.  Unpivot - The unpivot function is the opposite of the pivot function. Instead of turning rows into columns, it turns columns into rows. This is useful for narrowing data sets or for formatting it in a more effective way.  Value Mapping - This transformation is similar to the replace function, but it can act on non-text values like numbers and dates. With this function, users can replace values in a column with other values in a programmatic way.  This function can be helpful in dealing with null values or empty entries. With a value mapper, you can fill null values with a zero, so that the null values don't throw off your data analytics.  Windowing - The window function allows users to execute simple formulas on a specific window of their data, instead of the data as a whole. In conjunction with the ranking function, this can allow businesses to filter their data to a high degree.  For example, a sales manager may rank all of their salespeople by revenue, and then window their data to focus on salespeople between the top 25% and top 75%. This way, they can get a more accurate view of how their 'average' salespeople are doing. 

The dashboard is the most basic building block of any BI implementation. There are other important parts of a BI tool, like data connection and transformation, but dashboards are how data analysts actually turn their analysis into action. Because of this, they're the most important part of most businesses' BI strategy.  Often, a business that's invested in a powerful BI tool ends up garnering fewer benefits from it than they anticipate. The most common reason that businesses don't get the full benefit from their BI tool is that they don't focus on making intuitive, effective dashboards.  If someone were to focus on one aspect of BI that would make their data analysis more effective, focusing just on dashboard design would be a very good choice. Well-designed dashboards are supremely useful for any data-driven business, while a poorly designed dashboard can be actively unhelpful and lead viewers to draw the wrong conclusions about their data.  One reason so many businesses are suffering through poorly designed, ineffective dashboards is the rise of self-service BI. Self-service BI is a design paradigm that assumes that a layperson should be able to use a BI tool without much training or difficulty.  In general, the self-service BI approach is extremely valuable, and self-service BI tools are far more effective for most businesses that don't already have in-house data analysts. However, this approach can lead to some obstacles.  The biggest problem with self-service BI is that it expects people without much knowledge about dashboard design and best practices to build effective, useful dashboards. Without at least some training, this sets the average user up for failure.  One aspect of dashboard design that many beginner BI users aren't aware of is that there are different types of dashboard. Best practices for dashboard design shift and change as the goals and business questions of a dashboard change. There are three (or four, depending on who you listen to) main types of business dashboard.  Beginner dashboard builders should learn about these different types of dashboard so they can know when to use them and why. With a better understanding of the main types of business dashboard, they can build dashboards that are more useful for solving business problems and driving insight.  The Most Important Dashboard Types Depending on who's talking, there are three or four main types of dashboards. The type of a dashboard affects the sort of design decisions that its builder should make, the sort of visualizations that will be the most effective in making its point, and even where the dashboard should be displayed to be maximally visible to its target audience.  The main elements that determine what type of dashboard would be best for answering a given business question are what sort of business question it is, what sort of answers need to be surfaced, and what sort of metrics need to be tracked.  Sometimes, a dashboard builder may look at their dashboard goals, business questions, and planned metrics, and figure out what type of dashboard they need to build. Other times, a dashboard builder may get asked to build a certain type of dashboard, and then go find the right metrics and business questions to populate it.  The three main types of dashboard are strategic dashboards, which provide a high-level overview of a certain goal, operational dashboards, which provide important real-time metrics about current business performance, and analytical dashboards, which provide a deeper view into one certain aspect of a business question.  The fourth type of dashboard, tactical dashboards, occasionally gets mentioned by some literature on dashboards, but generally, it's thought of as a subtype of strategic dashboards. Tactical dashboards focus a bit more on the operational aspects of a goal, and are generally used for temporary projects and campaigns.  Each of the different kinds of dashboards have different use cases. A strategic dashboard might not be very effective in a situation that calls for an analytical dashboard, and an operation dashboard wouldn't fit either.  Operational dashboards might be the most common type of dashboard. Operational dashboards are used to track overall performance of a certain aspect or aspects of business operations.  These sorts of dashboards are great for providing a real-time view into how things are performing, which can help employees to spot trends and react to changes. Since they're so useful in this way, it often helps to make operational dashboards available to everyone who might need or want the information that they contain.  Since they're designed for such a broad audience, operational dashboards aren't usually built with drill-down or ad-hoc analytical features in mind. Many of the people viewing the dashboard wouldn't have the ability to drill down anyway. Because of this, operational dashboards need to surface all the relevant information that its viewers need, so that there's no need to drill down.  Operational dashboards are often designed for a large audience without much data training and who don't necessarily have the ability to interact with the dashboard. It's usually best to use simple, intuitive visualizations that can be easily understood at a glance. Anything more complicated might confuse.  Dashboards of this type are often some of the most useful dashboards for embedded analytics. With embedded analytics, these kinds of dashboards can be embedded into apps and web pages that users access frequently, which helps to streamline workflows and make them more data-driven.  Strategic dashboards are the most important dashboard type for monitoring projects or strategic goals. Unlike operational dashboards, which just provide a view into current performance, strategic dashboards put this performance into context to show a business's progress towards its goals.  Often, these dashboards compare current performance to past performance to show how things are improving (or how they're not improving). This sort of comparison is known as benchmarking. More high-level strategic dashboards might compare metrics year-over-year or month-over-month, while more focused, timely dashboards might look at week-over-week or even day-to-day data.  Businesses can also use predictive analytics in strategic dashboards. In these sorts of dashboards, analysts might compare current metrics to predicted future trends. This sort of approach is also popular for setting quotas and forecasting future KPIs.  Managerial and executive dashboards are often strategic. These sorts of dashboards help decision makers use data to drive their choices, which make them very useful for data-driven organizations.  Strategic dashboards can also be more generalized and public-facing, as well. This is especially true of businesses that track the success of their employees against quotas; employees will naturally want to know their progress towards those quotas.  Generally, strategic dashboards need the sort of data visualizations that show clear trends over time and allow users to compare data points easily. Users should be able to understand these visualizations easily, but they can't be designed so simply that they lose all of their nuance. A balance is necessary.  Some amount of drill-down and ad-hoc analysis is good, since it can often be assumed that most of the people viewing the dashboard will have the permissions necessary to interact with it. However, there's no need to make these kinds of dashboards too interactive, since they'll still be public-facing a lot of the time.  Some businesses will want to use strategic dashboards for embedded content, while others will be OK with just limiting access to the dashboard to those who can access it through a BI tool.  Tactical dashboards are a subset of strategic dashboards, though some organizations treat them as a fully unique type of dashboard in their own right. Tactical dashboards are similar to strategic dashboards, in that they focus on monitoring progress towards goals using KPIs, but they're far more specific than strategic dashboards.  The goal for a strategic dashboard tends to be very broad. These dashboards cover a broad area, like 'Revenue' or 'Marketing Success'. Tactical dashboards, on the other hand, are much more narrow. They look at one specific, real-world goal, and track progress on that goal.  For example, a company might have a strategic dashboard that aggregates all their marketing data, so they can track the success of their marketing strategy overall. They then might also have individual dashboards for each marketing source, so that they can drill down and find problems with each one. These more focused dashboards would be tactical dashboards.  With these smaller, more focused dashboards, users can evaluate the success of each marketing channel independently of one another, which allows for a more precise knowledge of how the marketing is performing overall. Often, these dashboards are paired with strategic dashboards, and are used as drill-down views or as sub-dashboards. It's not uncommon to see them as standalone dashboards, though, especially for teams that are focused on one specific part of an overall goal.  Tactical dashboards can also be useful for temporary projects, or for tracking metrics across one specific sprint or quarter. In this way, they can act more as operational dashboards, but for situations that have a clear start and end date.  Analytical dashboards are the last type of dashboard, and are generally the least common across an organization's BI strategy. That's not to say they're the least useful - they might have the most utility out of any dashboard type.  These types of dashboards are designed to allow for ad-hoc analysis of business data. They use interactive features and drill-down menus to help users to see new dimensions and trends in their data.  Analytical dashboards are great for situations where the relationships between data sources are unclear, or where there's still new insight to be discovered between different data sources. While they're generally too complex for the average employee, they're very useful for data analysts who want to find new insight, as well as decision makers who want to perform ad-hoc analysis.  These kinds of dashboards often use the same kinds of visualizations as other dashboards, but they include more filters, customization features, alternative views, and drill-down paths than other dashboard types. Dashboard designers really need to know their tool to put together a good analytical dashboard. Predictive analytics are also a great use-case for this dashboard type. Analysts can perform 'what-if' scenarios, seeing how metrics might change as different variables are manipulated. They can also help with forecasting, showing decision makers how the changes they want to make will affect their future KPIs.  While these dashboards often require more data expertise to use properly, making these sorts of dashboards public can often encourage more data analysis from average employees. For this reason, they're especially popular for embedded work.  Dashboard types -  an important element of dashboard design The types of dashboard aren't hard and fast boundaries. Many dashboards will have elements of multiple different types of dashboards, and some dashboards might not fit into any type.  For example, it's common practice to insert some analytical features like filters and drill-down menus into strategic dashboards. An operational dashboard might have tactical sub-dashboards that dive deep into specific aspects of the operation.  Regardless of how the dashboard types blend, it's important to consider what sort of type a dashboard will be before adding visualizations or connecting data sources. A user won't get the same sort of value that they get out of a strategic dashboard from an operational one.  Each of the dashboard types have their own strengths and weaknesses, and a situation that calls for one dashboard type will be badly served by a different type. It's the responsibility of a good dashboard designer to properly tailor each dashboard to each situation and make sure it's as useful as it can possibly be.  If you feel that your BI tool doesn't have the dashboard functionality that you need to survive, contact us today. Our team of experts can help you find the software that will work best for your use case. Get free BI advice in a no-cost, no-obligation consultation. 

Dashboards are the most basic way that most employees at an organization interact with their BI tool. Generally, only a few employees interact daily with the background processes of their business's BI solution; it just doesn't make a lot of sense to have every user poking around back there.  The majority of employees at most organizations don't need to perform data analysis directly. They don't need to connect to software through integrations or transform their raw data into actionable data. They do need data, though, and dashboards are how they get it.  BI systems are extremely valuable for the sort of analysis that they can provide to their users. With a BI tool, businesses can find novel trends in their data, make new connections, and find relationships that might have been invisible.  This sort of data analysis is valuable for businesses, but for most organizations, it's not the most valuable thing that a BI tool can do, or even the most common. At many businesses, the value of a BI tool comes from how well it monitors and reports on their business operations.  At many businesses, their operational data is spread out across different software solutions. There's no way for them to get a centralized view of their operations, since the data that they'd need is in different tools. This also means they can't analyze that data, since it all exists separately.  With a BI tool, businesses can finally centralize all of their data. Now that all of their data is in the same place, they can start to build a coherent view of all of their business operations, instead of trying to manage their operations by just looking at a few disconnected metrics.  For instance, a manufacturing company may track its incoming raw material with one tool, the activity of its assembly line with a second, their production numbers and shipping data with a third, its financial data with a fourth, and its marketing tool with a fifth.  Without a BI tool, it'd be impossible for this business to get a centralized view of its operations. Even with just five tools, it'd take a huge amount of work to get useful data out of all of them, and by the time everything was connected and visualized, the data would be out of date. Now, this business can use a BI tool to connect all of its operational software. They can finally view their operations in a high-level, connected way. They can analyze the data from their entire pipeline at once, which would be completely impossible without a BI tool supporting and connecting everything.  This business could even build a dashboard that contains all of their operational data from all of their sources, so that they could get a sense of their operations at a glance. In many BI tools, this dashboard could even update in real time, so that it's a real, active view of their business operations.  A dashboard of this type is called an operational dashboard. It's a type of dashboard that's meant to give its users real-time insight into actual business performance. These dashboards generally make up the core of most businesses' data strategy.  Operational dashboards are the most common type of dashboard used by the average worker, since they're the best type of dashboard for informing day-to-day and hour-by-hour work. They provide real-time information about business performance that's very valuable to frontline and low-level employees who are actually doing that work.  To build a data strategy that makes good use of operational dashboards, businesses need to know three things - how operational dashboards are different from other dashboards, what sort of situations they're best for, and what sort of metrics and visualizations make them the most effective.  How Are Operational Dashboards Different? Operational dashboards are one of the three main types of dashboards. They're used for monitoring performance metrics that are important to the day-to-day operations of either the business as a whole, or a more specific aspect of business operations.  Think of the dashboard in a car. The different gauges on a car dashboard inform the driver exactly how the car is performing at the given moment. It would be infeasible for the driver to monitor metrics like miles per hour or gas tank capacity themselves, so the dashboard collects all the data the driver would need and presents it in a compact, simple way.  If there's some change in a metric that needs the driver's attention, it'll be highlighted on the dashboard hopefully before it becomes a real problem. If the driver makes an input that changes some metric, they can see how that metric changes based on that input in real time. In the same way that a driver uses a dashboard to operate their car safely and effectively, employees use their dashboards to operate their business.  The other two main types of dashboard, strategic and analytical dashboards, are much less focused on providing real-time operational data. Strategic dashboards provide insight into how current performance towards broad strategic goals compare with past performance, and analytical dashboards provide an opportunity to drill down, filter, and sort data in novel ways.  If an operational dashboard is like a car's dashboard, then a strategic dashboard is the car's GPS. They help to make sure that the car is going in the right direction and inform if the business has taken a wrong turn somewhere.  Analytical dashboards are closest to a mechanic's set of diagnostic tools, where they can use the data that's been collected to see where problems lie, find inefficiencies and errors, and hopefully discover solutions to problems.  A good data strategy will include each of these three types of dashboard, but for monitoring and acting on the most basic, day-to-day operations of a business, dashboard builders can't really do much better than an operational dashboard.  When Are Operational Dashboards Useful?  Operational dashboards are best used for monitoring how different aspects of a business are performing in real-time. Often, they're thought of as only being useful for tracking physical operations, like assembly lines and supply chains, but they can be used for all sorts of business operations.  For example, a sales team can use an operational dashboard for tracking their sales success as it happens. They can plug into things like accounting and POS software to see exactly how sales are going in the real world.  These sorts of dashboards are at their most useful when people viewing the dashboard can change their workflows, prioritize different tasks, and shift their goals based on the information they see on the dashboard, and actually make a meaningful, immediate impact on business operations.  In an extremely basic example, a business might use an operational dashboard to monitor their assembly line. Based on the data from the operational dashboard, a foreman might see that they're making too much of Part A, and not enough of Part B.  With knowledge of the part imbalance from the operational dashboard, the foreman can move immediately to fix the problem. Without this sort of real-time intelligence, the part imbalance would continue, and the first time that anyone on the manufacturing team would find out about it would be when it became a problem.  Operational dashboards help lower-level managers and frontline employees react quickly to unanticipated changes in their business metrics, solving problems before they even become problems.  Even in situations where users can't necessarily react quickly to the changes that they see on the screen, operational dashboards are useful just as a useful store of information for low-level and frontline employees. It's a good practice to make operational dashboards visible to as many people as possible, so that they can use the information on it to guide their actions.  Operational dashboards aren't just useful to lower-level employees. Higher-level employees, managers, and executives can make good use of operational dashboards as well. At this level, operational dashboards are less focused on one specific aspect of business operations, and monitor business health more generally.  These sorts of general operations dashboards can look very similar to strategic dashboards, but unlike strategic dashboards, operational dashboards aren't worried about goal attainment. They just tell things how they are, which can be a valuable quality in itself.  In short, operational dashboards are valuable at every level of an organization, since they help businesses to have a better understanding of their current processes and how their operations are going in real time.  What Sort of Visualizations Are Useful on Operational Dashboards? The most useful visualizations on operational dashboards are ones that highlight one key figure - the metric as it exists in real time. As such, operational dashboards make good use of scorecards, gauges, and line graphs to inform viewers about the real-time state that their operations are in.  Scorecards and gauges are especially useful on operational dashboards, since they cut away all the information about a metric that isn't useful for real-time analysis and billboard one key number that represents that metric.  Line graphs can show how a given metric has trended over time. They're especially useful for metrics where every rise and fall has some importance. Think of situations like stock price, where even minor fluctuations in a metric's performance can have outsized effects.  An operational dashboard is usually only going to have a few metrics, the things that are most important for monitoring business performance. A business might collect dozens or hundreds of different metrics that track business operations, but their dashboards should only highlight the half dozen or so most important.  Interactivity isn't generally very important in operational dashboards. It's useful to have things like drill-downs, filters, and data sorting, but they're not essential for an effective operational dashboard. In fact, building too much interactivity can be harmful for the dashboard's overall usefulness.  In many cases, operational dashboards will be presented to users in situations where interactivity isn't an option. Either users don't have the credentials to interact, or they view the dashboards in contexts where interactivity is limited, like on public monitors or within an embedded solution.  If the metrics that a user needs to access are hidden behind a clickthrough or drill down, they won't be able to get to them if they can't interact with the dashboard. It's best practice when building operational dashboards to assume that the end user won't be able to interact with them.  Operational Dashboards - The Base Of Any Data Strategy While every type of dashboard has its uses, operational dashboards are the most generically useful of the three types. Any team and department can make use of them, and they're useful at every level of governance.  Low-level and frontline employees can use operational dashboards to guide their day-to-day operations and quickly solve business problems that crop up, and executives value operational dashboards as a clear snapshot of business health.  These are just a handful of the use cases for an operational dashboard. In the same way that every car needs a dashboard so that its driver can properly operate it, every business, and every team and department within that business, need operational dashboards to properly navigate their business operations.  For more on the types of dashboard and when they're useful, check out our guide to the three main dashboard types. We also have guides to the best BI software for dashboarding and the best BI software for data visualization. 

Businesses need a well-trained, well-informed workforce to build a really effective data strategy. Data-driven companies can assume that every employee in their organization is capable of at least understanding a data visualization. At these businesses, skill sets like data analytics and dashboard building are common, as well.  Many companies are the direct opposite of this imagined ideal. Data knowledge is rare among these business's staff, and where it does exist, it's extremely limited in scope. These businesses don't have the human resources that they need to become modern, agile, data-driven organizations.  However, there's hope for these businesses. Agile, data-driven organizations didn't get that way overnight, and many of them started with the same lack of data expertise that data-poor businesses have now. There are ways for businesses to improve their internal data culture, boost data knowledge and literacy, and promote data fluency, without layoffs or hiring blitzes.  Two of the most important terms for business leaders to know for this initiative are 'data literacy' and 'data fluency'. While these terms might seem similar, and do refer to similar ideas, the difference between the two goes a long way to explain the success (or lack of success) of a business's data strategy.  Data literacy is how well someone can understand data, while data fluency is how well someone can incorporate data into their position. Data fluency is the next step past data literacy - an employee might be able to understand what their dashboards say, but can't figure out how to use that knowledge to benefit their business.  To build an effective data strategy and really make their business data-driven, leaders need to figure out how to drive data literacy in their organization, how to turn that data literacy into data fluency, and how to cultivate a culture of data fluency moving forward.  How To Drive Data Literacy Data literacy is an extremely valuable quality, and even just encouraging greater data literacy among employees will do a lot of good. For businesses just starting to implement a data strategy, it can be difficult to just reach this step.  Driving data literacy doesn't happen overnight, but it's one of the most sensible investments a business can make, right up there with implementing a BI tool in the first place. A business's data is only as effective as the tools that the business has to analyze it, and if no one at the business is sure how to do that, it'll be an uphill battle.  It's very important for any business that's invested in a BI tool to drive data literacy among their workers. Businesses need data-literate employees to actually operate their BI tool, so some level of data literacy is required. Even beyond using the tool, employees that aren't data-literate won't be able to read dashboards or understand visualizations. The first step towards building a data-literate workforce is improving access to data. Many employees aren't very good at understanding data because they're unfamiliar with everything but the most basic data visualizations. There are some kinds of visualization that people see every day, but many other visualizations that employees haven't seen since high school math class.  By making data more accessible and more visible, a lot of that unfamiliarity goes away. One major advantage of data visualizations compared to regular paper reports is that once someone's learned how to read a certain type of data visualization, they can understand that visualization in any context, not just the one they learned it in.  At some level, the more that a business uses their BI tool, the more data-literate their employees will become. This isn't always true; if a business only spreads their BI tool's visualizations across a small percentage of their workforce, then only those that actually see and interact with those visualizations will get any benefit.  In general, though, the more that a business actually uses their BI tool, and builds dashboards and visualizations with it, the more that the average employee will come to understand the tool.  In this way, increased access and increased visibility creates a positive feedback loop, where the more that people use the tool, the easier it is for other people to understand the tool. The more that someone understands the tool, the likelier they are to use it.  It's also important to encourage a culture of experimentation and creativity with the tool and the data it analyzes. At many businesses, employees are actively encouraged away from interacting with their BI tool in a self-led way. This works against the goal of data literacy and makes it harder to drive an effective data culture.  How To Turn Data Literacy Into Data Fluency Businesses don't usually need to work to drive data literacy in a centralized, top-down way. For data literacy, a bottom-up, decentralized strategy is much more effective. With data fluency, though, a top-down approach is much more useful.  At some level, businesses don't really need to worry too much about driving data literacy with specific training or other initiatives. By changing some of their data policies, like data access, and by encouraging experimentation with data, businesses can mostly boost data literacy in a natural, employee-led way. They can do some of the same to boost data fluency, but boosting data fluency mostly needs to be far more intentioned, purposeful, and directed. This is true for a few different reasons - first, data fluency is just a harder concept to understand than data literacy.  It's easy enough to look at a graph and understand what it says, but it's much harder to look at a graph, understand what it says, and understand what specifically should be done about it. This is what separates data literacy, a surface-level view of data, from data fluency, which puts data in its proper context and allows it to be used for insight.  With data literacy, employees can see a trend on a line chart going up, and know that the metric that the line chart is tracking is going up. Data fluency, though, is how these employees know whether that trend is something that they need to worry about, and what they should do about it, if anything.  This sort of intuitive realization is much harder for companies to cultivate in their employees. At some level, it's pretty simple to understand a line chart, but understanding how that line chart relates to company success is much harder, and usually requires at least some training on business data.  In addition, the ideal actions an employee should take when they see an unanticipated change in an important metric will change from industry to industry and even business to business. The value of a given business decision will change based on the situation.  To make things even more complicated, other metrics might affect what a good response to a business problem looks like. In the real world, changing metrics affect other metrics, and there can be a web of connection that makes even small changes have outside impacts.  Employees need training on what to do, why to do it, and how to avoid causing other problems when doing it. This sort of knowledge is central to data fluency, and can really only be obtained in a formal, top-down training session.  At its core, data fluency is about combining an employee's knowledge of the business operations they're responsible for with their knowledge of data analytics, so that they can connect the data visualizations that they see on a dashboard with actual business operations happening in the real world.  How To Cultivate Data Fluency A high level of data fluency is very valuable for businesses, especially those who have made major investments into a BI tool. If a business's employees can't use the data analytics that a BI tool provides, then the utility of that tool will be very limited.  The best way to get value out of a BI tool is to make sure that anyone who needs access to its data can understand the data that they get, and know what to do with it. Businesses need their decision makers to be knowledgeable about data, so that they can leverage the data analytics of their BI tool towards insight.  The best strategy for promoting data fluency among the employees of an organization is a top-down, centralized training program that helps workers to understand their own jobs and the importance of their tasks on a deeper level.  One of the biggest difficulties in promoting data fluency is a disconnect between data analytics and visualizations, and the real-world operations that drive those analytics. Without training, it's very easy for an employee to not know what a metric translates to in the real world, or refuse to use dashboards because they don't understand how their business operations are communicated through it.  Helping employees to make these sorts of connections is the most important part of cultivating data fluency. Employees that realize how their dashboards connect to real-world metrics will have a far better understanding of those metrics and will know what to do when those metrics shift.  This sort of knowledge is also useful for separating real changes in a metric from errors in collection or integration. Employees that don't have real-world knowledge of their metrics have to take their metrics at face value, while employees that are more data-fluent can be more critical.  This is especially useful in industries like transportation and manufacturing, where malfunctioning sensors can often send back junk data. If one sensor on an assembly line starts returning junk values, while the others stay normal, it's very easy for a data-fluent employee to catch the error, while other employees might assume that the junk data represents a real problem with the assembly line.  Turning Data Literacy Into Data Fluency Both data literacy and data fluency are important for any business trying to build an effective data strategy. Data literacy is the first line of defense, helping businesses to understand their data better by encouraging dashboarding and visualization.  Data fluency represents a step beyond data literacy. With data fluency, businesses go from simply monitoring their operations with dashboards, to actually using the data within those dashboards to make decisions and drive insight.  Data-driven businesses should make promoting data fluency a large part of their internal data strategy. Promoting a deeper understanding of the processes that drive their metrics and how they connect to the data that a business collects is extremely helpful for providing valuable data insight.  To learn more about driving data literacy in an organization, read our article about it. If you're still looking for your perfect BI tool, check out our rankings of the best BI tools for data analytics and the best BI tools for data discovery. 

There are four main types of data analytics. Each has its own use case, and a good business intelligence strategy will incorporate analysis of all four types. These types are descriptive, diagnostic, predictive, and prescriptive analytics.  These types of analysis can easily be split into two pairs. Descriptive and diagnostic analytics are focused on past and present data trends, while predictive and prescriptive analytics are focused on how data will trend in the future.  Descriptive and diagnostic analytics are important, but we've already written an article on them (which you can read here). While they're an important element of most effective BI strategies, they can be simplistic. They also often lack timeliness; they can tell a user how things trended in the past, and how things are trending right now, but they can only react to changes, not anticipate them.  Relying exclusively on descriptive and diagnostic analytics for a BI strategy is common among beginner BI users, but it has a few key problems. The most damaging problem with this sort of approach is that it's always playing catch-up - since it can only track past and present trends, users can't solve problems until they've already become problems.  This is where predictive and prescriptive analytics come in. These types of analytics use the data that a business has already collected and is collecting to predict future trends and suggest plans of action that will avoid problems. This is extremely useful for businesses, and can help them to build an effective analytical strategy.  But it's not as simple as just setting predictive analytics to 'on' in a BI tool. There's a huge variety of techniques and strategies underneath the prescriptive and predictive analytics umbrella, and implementing those types of analytics is much harder than it seems.  To build an effective analytical strategy, businesses need to be aware of what predictive analytics and prescriptive analytics are, what sort of strategies they can leverage from them, and how they can be used to drive business success.  Predictive Analytics  Predictive analytics focus on using the data that's already been generated to make predictions about how that data will trend in the future. Using statistical techniques that determine the probability of changes in the data, data analysts can build analytical models for making predictions.  One of the most basic uses for predictive analytics is forecasting. Data analysts take an already existing data set and, using statistical models, forecast what that data set will look like in the future. It's fair to say that any business that plans on operating in the future can benefit from forecasting.  Businesses can then use these forecasts to plan ahead for the future. At its most simplest, businesses often use revenue projects to plan future budgets and justify capital expenditures. Other situations might call for other actions, like a forecasted budget drawdown provoking budget cuts and layoffs.  One important element of forecasting is that it doesn't necessarily recommend a plan of action, it just forecasts what's most likely to happen. Decision makers then need to use their own judgment to find the best plan of action.  For example, a forecast might suggest that demand for a given product will decline over the next few months. One business might decrease production of that product, anticipating less demand. Another might increase the marketing budget for that product, to counteract the effects of lower natural demand.  Predictive analytics don't suggest a concrete path forward; instead, they just inform decision makers on how their data is most likely to trend in the future. The biggest challenge that businesses have with predictive analytics is knowing how best to react to the predictions it generates.  Businesses can also use predictive analytics to perform 'what-if' modeling. With this technique, analysts compare the trends of two or more different data sources, and then attempt to project how a change in one data set might affect the others.  For instance, a business might want to institute a hiring freeze due to the cost of acquiring new talent. With what-if modeling, that business can see the effect of that hiring freeze on their budgets, but also its effect on other related statistics like turnover and productivity.  Predictive modeling is only as valuable as the data used to feed it. For effective predictions, data analysts need as much historical data as possible. The more data that they have to feed into the model, the more accurate the model will be. If an analyst has to run a model off of a smaller data set, the predictions it makes will be less accurate.  These are just some of the more common use cases for predictive analytics. Businesses can make use of predictive data techniques in all sorts of different situations. They shouldn't feel limited to just the examples listed here.  For example, predictive models can help drive e-commerce sales. It's very common to see banners or pop ups on online stores that recommend products to customers based on the products already in their cart. These suggestions are powered by predictive models, which look for items that are commonly bought together and assume that if a customer is buying one, they'll be likely to buy the other.  In short, predictive analytics help businesses to make predictions, but don't provide any insight into what to do with those predictions. Used correctly, predictive analytics can be a valuable tool, but it takes a good business sense to actually take advantage of the predictions that it generates.  Prescriptive Analytics Prescriptive analytics represents the next step beyond predictive analytics. Many businesses use predictive analytics in dozens of different ways, but don't perform prescriptive analytics at all.  With prescriptive analytics, predictive models can suggest the most successful plan of action, and forecast the consequences of any choice made. They allow businesses to algorithmically generate solutions to their anticipated problems.  With basic predictive models, decision makers have to choose for themselves what the best plan of action is. In a complex business situation, there may be dozens of different strategies that decision makers can implement to solve a problem. With regular predictive models, there's no way to know which solution will solve the problem most effectively.  Through prescriptive analytics, business leaders actually can forecast the consequences of each business decision that they make. They can model their decisions and find the one that best solves the problem at hand.  For example, a business might forecast a drop in demand for their product over the next three months. A business leader might need to decide between decreasing production in anticipation of this decreased demand, or boosting marketing to prevent this drop. Prescriptive analytics can help guide that business leader to the correct answer.  Maybe decreasing production will have knock-on effects that will end up costing the business more than they'll save. Perhaps there's no latent demand for the product, so increasing the marketing budget won't change anything. Prescriptive models help business leaders to see these unforeseen challenges before any decision is made.  Prescriptive models can also bring a precision that business leaders can't match. Algorithmic models can find the exact correct amount of changes to be made, while business leaders have to use blunter tools.  For example, business leaders might decide that raising ad spend 15% will lead to the most cost-effective rise in conversion rates. Using a prescriptive model to analyze the relationship between ad spend and conversion rates, though, they may find that the best strategy is to raise ad spend exactly 11.78%.  At many businesses, this added precision will often go completely unnoticed. At enterprise-scale organizations, though, changing just a few decimals on a percentage point can lead to millions of dollars of new revenue, making precise prescriptive models very valuable.  Using Predictive and Prescriptive Analytics for Business Success Predictive and prescriptive analytics make up a large part of a well-rounded analytics strategy. In conjunction with descriptive and diagnostic analytics, businesses can use them to build an extremely precise statistical model of how their data has moved in the past, how it's moving right now, how it will move in the future, and what to do about it.  Businesses that want to access powerful analytics need a powerful BI tool to do so. Not every BI tool can handle the sort of analysis that businesses want nowadays. Some tools are focused on just descriptive and diagnostic analytics. Others allow for predictive analytics, but don't prioritize prescriptive analytics.  Those looking to invest in a BI tool need to be careful. If they don't do their research and select a tool that meets their needs, they can end up with a tool that's a bad fit for their situation. Even worse, it might not have all of the analytical features that they're expecting to get out of their tool.  Most market-leading tools can help businesses to perform predictive and prescriptive analytics. Both are fairly resource-intensive activities, so smaller, less powerful tools might not offer them as a feature.  To find a tool that can meet all of your business analytics needs, contact us today. Our team of experts can connect you with the tool that'll best fit your needs in a quick, no-cost, no-obligation consultation. We'll work with you to help find the best tool possible. 

BI tools take all the data that a business collects, and puts it all in one place so that it can be analyzed and visualized as a whole. Data analysts can take data from one tool and directly compare and analyze it with data from another tool. This allows businesses to get a holistic view of their business data.  However, there are some challenges that can get in the way. Businesses usually can't use the data that they collect in its raw form. Raw data is bad for analysis, since it has all sorts of flaws, inconsistencies, and other problems that affect its accuracy.  Data analysts have to change, reformat, and edit their raw data so that it can be used for analysis. This process is called data transformation, and it's an important step in the data process.  There's additional complication in the data transformation process when a business has to combine data from different sources. In a BI tool, this means that data analysts almost always need to do this extra work.  When data comes from two or more different sources, it needs to all be changed to fit a standardized format so that the data can be compared and analyzed together effectively. Usually, this doesn't mean the overarching meta-formatting of the data has to be changed. Data standardization is far more commonly about changing the way specific data points are expressed so that all information is expressed in the same way.  In practice, this means that data standardization is about changing things like abbreviations or phone numbers, so that they're always expressed in the same format. This may not seem like a very important step of the process, but it's essential for the proper analysis of complex data sets.  Businesses need to implement a consistent, far-reaching data standardization scheme so that all of their data is expressed in the same way. This way, they can be sure that their data always says the same thing and that it can all work together well.  Why do data standardization? In data standardization, analysts reformat and restate different kinds of data points so that they're more consistent with other data that the business has already connected. This way, businesses can compare their data sets directly instead of trying to navigate all sorts of different schemas for expressing data. These data points usually are things like abbreviations, addresses, and phone numbers. They're things where the core meaning of the data point doesn't change, even though the data can be expressed in multiple different ways. For example, one data set might express state names in an abbreviated way, while another might write the names out completely. While this may not seem like it should be a massive deal, most BI tools aren't able to figure out that 'California' and 'CA' represent the same information.  This causes all sorts of problems when data analysts start working on the data. First, it makes querying the data much harder. If a data analyst queries their data set by searching for the entry 'California', they'll only get results that have that string. They won't get any results that use the string 'CA'. This means they'll have to do another query to get that data, or else some of the data will get left out of their query.  Second, it makes it difficult to analyze the data properly. If an analyst wanted to take the average of all the sales made in California, that average wouldn't be useful if it just analyzed the 'California' data and not the 'CA' data as well. State names are just a clear example; there are tons of different ways this can happen, and many situations where the same information might be expressed five or six different ways.  Sometimes, the issue is less with how the data is expressed, and more with how the data is structured. Many tools structure the same sorts of data in different ways, and this can affect how the data can be combined, analyzed, and visualized.  For example, many different tools have different ways for structuring address data. In some tools, each section of the address is stored in its own structured column, while in others, the whole address is stored in one column or different sections are combined.  Businesses have to standardize this structure across tools, not only so that the data is easier to query and analyze, but also so that the data is easier to join. Trying to join data sets that structure the same data differently is a headache, and it's easier to standardize the structure beforehand.  Simply put, if data isn't standardized, it can't be effectively used to drive insight. This is especially true when combining data from many different sources at once, sources that use multiple different kinds of structure and expression.  Tips for standardizing data Businesses that want to use data from many different sources need to figure out a strategy for data standardization. They can't just change things ad-hoc and hope that it always works out for the best. They need to outline consistent rules for combining and reformatting data so that everything works together correctly.  It's fairly common for businesses to know that they need to standardize data across multiple data sets, but not bother with outlining company-wide standardization rules. This leads to a lot of reformatting which works for that specific situation, but isn't consistent at all business-wide.  Businesses need to set up consistent rules, so that the same data gets expressed and structured in the same way every time. This approach ensures that every data set can combine with every other data set easily, without any additional standardization.  How can businesses implement data standardization schemes, and make sure that their employees actually follow them? Even though it's a complicated topic, it's not as hard as it seems to build out these rules and make sure they get followed.  First, data standardization isn't something that the average employee should be worried about. It's exclusively the domain of those who transform data and build out data sets. Since this is a more technical job, not everyone has to know these standardization rules.  Businesses don't need to worry about training their entire workforce on these rules, they just have to train their data analysts and BI experts. This saves a lot of time and expense.  Second, it's not hugely important what the rules are, just as long as they're consistent. A lot of these data standardizations, like making sure everything is abbreviated the same way or that phone numbers are all formatted alike, are unimportant from a data science perspective.  It doesn't matter if a state is written 'California' or 'CA', since by definition, they mean the same thing. A business will get the same sort of results whether or not they standardize around the full name or the abbreviation.  In most cases, all that matters is that the data is all the same, so it can be effectively used for analysis. This means businesses don't really have to agonize over the 'right' way to standardize something. No matter how they do it, it'll generally be fine.  Third, it's important to cultivate a culture where those doing the transformations are comfortable asking for clarification if they're unsure of how to standardize something. It's much more preferable that someone ask for guidance than do it wrong, but not every company's employees are comfortable doing that.  Lastly, it's often helpful to standardize all the information in a data set before that data set is combined with other data sets. This way, data analysts don't need to worry as much about standardizing their data when they actually do the ETL for a given data set.  Data standardization - the key to data success Data standardization is an important part of the data transformation process. It's how data analysts make sure everyone is talking about their data in the same way, using the same sorts of formatting, structure, and expression.  Without proper data standardization, businesses can't effectively search their data, they can't effectively do analysis, and the rest of the data transformation process is far more difficult. It's important that businesses standardize their data correctly, so that everything can communicate.  Businesses need to make consistent data standardization rules a priority. This way, everyone is on the same page as to what needs to be changed and how, and there's no confusion. 

Data analytics help businesses to make valuable choices. BI tools help businesses to access data analytics, so that they can use their data to drive insight. With a BI tool, they can unlock their data, spot trends, and find relationships.  However, not all analysis results in the same sorts of answers. Data analytics is complex, and it's very easy for new BI users to build dashboards and visualizations that aren't particularly useful.  Data analytics isn't only about asking questions and finding answers in data. It's also about knowing what sort of problems you're having, and knowing what sort of questions to ask to get solutions to those problems.  Often, businesses don't get the answers that they want out of the analytics that they're performing. This isn't necessarily because they're doing the analysis wrong, or because they're using the wrong visualizations. Usually, it's because businesses don't know how to ask the right questions to get the answers they want.  The difference between descriptive analytics and diagnostic analytics is one that trips up a lot of businesses. If businesses don't recognize the difference between these kinds of analytics, they'll end up with reports and visualizations that don't really answer the questions that they want answers to.  Many businesses don't even know there's a distinction between different types of analytics. They may not be able to realize there's even a problem with their data analytics that needs to be solved. With some additional knowledge about this topic, they can perform analytics that actually answer valuable business questions.  Types of analytics There are actually four main types of data analytics. Each type answers a different kind of business question. Mostly, they're split up by how actionable the analysis is, and how much it recommends a clear course of action.  We won't go into detail about two of the main types, predictive and prescriptive analytics, right now. It's not that these types are unimportant; they're some of the most valuable analytics that a business can perform. They're just so complex that they're worth focusing other content on them. For more on predictive analytics, check out our guide on the topic.  Descriptive and diagnostic analytics are the most common forms of analytics that businesses that have a new BI system try to implement. They make up the bedrock of any business's BI strategy.  Descriptive analytics is usually the simplest kind of analytics. It shows trends and relationships between data, but it doesn't draw any conclusions about what a business should do about them. Many of a business's most basic reports and visualizations are descriptive.  Diagnostic analytics take descriptive analytics one step further. It attempts to find the root causes of problems by finding correlations between data. It's a much better tool for finding answers to complex business questions than descriptive analytics, since it recommends a clear plan of action that a business can follow.  In short, descriptive analytics tell a business what's happening, while diagnostic analytics show businesses strategies for solving specific business problems. They both have their own strengths and weaknesses and often, visualizations using one type of analytics might be better served with the other type.  For example, a graph that shows how revenue is trending over time is a fairly simple descriptive analytic that many businesses use. It's useful for telling viewers what's happening with the business's revenue, but it doesn't offer any insight into what to do if it goes down.  On the other hand, a pie chart that shows revenue by product might be more useful as a diagnostic analytic. It can show users exactly where the business is making its money, and a viewer can draw insight from the graph on where to focus their efforts to boost revenue.  Descriptive analytics Descriptive analytics tend to make up the core of most business's analytical strategy. They're usually very easy to implement, and they're the easiest sort of visualization for the average person to understand. Since they're so simple, many businesses use a ton of descriptive analytics in most of their dashboards.  These sorts of analytics are best at answering simple, common business questions. They often answer questions that start with 'what', 'who', or 'where'. These sort of questions are simple to answer, but are important for tracking business health.  Monitoring business health is just as important a function of a BI tool as solving complex business problems. Just because these questions are less complex than ones solved by other analytics doesn't mean they're any less useful.  Descriptive analytics are very important for building alerts and notifications. While users can build alerts off of other analytics easy enough, descriptive analytics generally are the best fit for these sorts of use cases. Since they're actively monitoring important business metrics, they're the best early warning system for issues.  Other analytics may excel at telling users how to solve issues, but descriptive analytics are the best at telling users when problems are happening. They're how businesses know that there are problems that need solving. Actually solving the problem is a task better left to diagnostic analytics.  There's an almost endless list of use cases for descriptive analytics. Any situation where someone needs to track a metric is a good fit. If your question is some variation of 'What's happening?', then descriptive analytics will provide the best answers.  Diagnostic Analytics Diagnostic analytics are the analytics that actually suggest a path forward. They're reports and visualizations that try to accurately find the causes of business problems, so that users can plan solutions to them.  Some people think that a BI tool is going to tell them what they should be doing in big clear letters. Diagnostic analytics are rarely that specific. Usually, they just provide some important pieces of information and let the user draw their own conclusions on what to do.  Often, diagnostic analytics come in the form of a regression analysis. This is the classic 'when this line goes up, this line goes down' type of graph that users have probably been using since grade school. These sorts of graphs are a useful way to see the relationship between two variables.  Diagnostic analysis determines if there's any causal relationship between two variables that move in concert, and if there is, to what degree the two variables are related. This analysis helps businesses to see the solutions to their problems.  For example, if a business knows through diagnostic analysis that their lead generation is related to the number of deals that convert, then they can use that information to decide on their best course of action. There isn't some big visualization that says 'boost your lead generation or go bankrupt', just an analysis that shows a lever that the business can pull.  Sometimes diagnostic analytics can end up looking more like descriptive analytics. In these cases, there's less active analysis going on. The BI tool just presents the information, and lets users figure out the best sort of action.  Using both types of analytics Businesses that want to properly leverage data analytics need to know the difference between descriptive and diagnostic analytics. They need to know when to use both types, and what sort of questions are best answered by them.  A good dashboard should have both types of visualization on it, not just one. Since both types answer different types of questions, a dashboard that's aiming for a comprehensive view of a topic should have both types.  One common perception is that descriptive analytics are less useful than diagnostic analytics, since descriptive analytics answer simpler kinds of questions and don't suggest a clear path forward. However, both types have their uses, and it's a mistake to only use one type at the exclusion of the other.  Descriptive analytics show businesses where problems are occuring, and diagnostic analytics present some solutions to those problems. A business can't effectively solve their problems without diagnostic analytics, but they're completely blind to new problems if they aren't using descriptive analytics.  Along with the other two types of analytics, descriptive and diagnostic analytics make up the core of a business's data solution. With a better understanding of the types of analytics, businesses can ask the right questions and get valuable answers. 

Data governance is an important element of any business's BI implementation. However, it's often overlooked by businesses that have just recently begun to bring their BI tool to a broad audience.  Businesses that are just beginning to implement their BI system probably aren't thinking about data governance beyond 'maybe not everyone in the company should be able to see our financials' or 'maybe frontline workers shouldn't be able to see customer's personal information'.  Beyond the obvious situations where it's necessary, data governance can seem like a chore to businesses. It doesn't always have a clear benefit that affects a business's bottom line, and so there's a perception of data governance as busywork, something that can be ignored if you don't want to mess with it.  However, data governance is important to BI success, beyond just preventing employees from viewing sensitive information. Used properly, data governance can be a powerful tool, streamlining data discovery and making it much easier for the average user to draw insight out of their BI tool.  What is data governance? Data governance is the term used to describe the collection of techniques and strategies that businesses use to limit access to their data. It's how businesses decide who gets to see what data, when.  There's a wide range of different features that different BI tools use to govern data. Basically every tool has some sort of role-setting feature, where admins can assign users to roles and decide what sort of data access those roles will have. Some tools have additional limiters at a personal level, so even coworkers in the same role could have different data access.  Data governance also means governing what users can do to their data once they've accessed it. Not everyone who needs to view a dashboard or visualization should be able to edit that dashboard. Similarly, users building dashboards and visualizations of underlying data shouldn't necessarily be able to mess with that data's ETL.  BI tools allow admins to limit what their users can do to the data they have access to. Usually, there's some sort of view-only role who can't build cards and dashboards, but can view other's work, an editor role that can build content but can't access underlying data, and then some sort of data scientist role that can alter ETLs.  Most tools allow for more than just these basic roles, and allow for customization of their basic roles. This way, businesses can tailor their data governance to their currently existing workflows, instead of the other way round.  The exact details of a data governance strategy will vary from tool to tool. Some tools have extremely robust data governance options, allowing admins to limit access at the row level in structured data. Others use more broad strokes and don't offer that level of granularity.  What can data governance do?  Most businesses start focusing on data governance so that they can limit access to sensitive information. Even though it's not the only reason that a business should invest resources into data governance, it still is the most common and most important.  If the average employee had access to all of the data that their business generates, they'd be able to access a lot of information that the business wouldn't necessarily want them looking at. In a pretty basic example, businesses don't want to make HR information like compensation or complaints public knowledge.  Businesses need to limit the sorts of things that their employees can see. HR information should only be visible to people in HR, client information should only be visible to sales employees, and so on.  Admins can restrict this view even further. For example, a business could restrict their employee's data access so that they can only view data that's associated with them in some way. A sales employee might only have access to data on their sales, and so on.  Not everyone in an organization should have full editing access for every card, ETL, and dashboard in the tool. Employees shouldn't be messing with ETLs or visualizations they don't need to be messing with, whether or not they're doing so maliciously.  There are also different levels of access that an employee might need. An employee might have full authority over some data sources, only have editing privileges on others, and only have viewing privileges on another.  Restricting access to sensitive data isn't the only thing that businesses can use data governance for, though. Sometimes, it's best to limit a user's access to a data set, not because the information could be misused, but because it's irrelevant.  The average employee doesn't need access to the majority of a business's data. Most of the data that a business collects will be completely irrelevant to most of their departments. The sales department will only need data related to sales, and their employees won't need access to data from other departments.  Businesses can use their data governance tools to limit data team or department-wide, so that employees can't access data that isn't important to them. This helps them to focus on building dashboards and visualizations that will actually be useful for answering business questions.   Some businesses don't care if employees can access information that's not relevant to them. However, it's usually better to narrow an employee's view to just the information that they need to do their job.  Data governance is also important for building personalized dashboards. With some basic data governance rules, data experts can build dashboards that show different viewers different information. This way, users can just build one dashboard for a large audience, instead of building individual dashboards for every different situation.  For example, a senior sales manager may want to share regional sales data with all their regional managers. Instead of making a different dashboard for each region, the manager can build one dashboard that contains aggregated data for every region, then use governance rules to limit what each regional manager can see.  This way, when a manager logs in to their BI tool to view the dashboard, they'll only see their own region's data instead of seeing the aggregated data. In most BI tools, the tool will only visualize the data that the user has access to. This is a convenient shortcut for creating dashboards at scale.  Benefits of data governance First, data governance keeps business data safer. With consistent rules about who can and can't access data, the chances that data could be accessed by bad actors or that ETLs and visualizations could be edited maliciously is lower.  Imagine a phishing scam that manages to dupe your employees out of their BI credentials. If the hacker manages to log in with stolen credentials, and the employee has access to all of their business's data, then all of that business's operations have been compromised.  Data governance limits how harmful a breach like this can be. With proper governance rules, where employees have a narrow scope of information, the effects of a data breach will also be limited. Hackers will have to try a lot harder to get at business data.  Limiting data access can also have benefits beyond security. When a user only has access to data that's relevant to them, it's much easier for them to quickly start doing their own analysis on their data.  If a user has access to the entire database of a business's data, that's a whole lot of data to sift through to find the data that will actually be useful. Employee's data experiences should be curated in some way so that they don't get lost in a sea of data.  With self-service BI software, the average employee should be able to do data discovery themselves. To develop a personal relationship with data, they need to be given the right tools. Data governance helps to separate the signal from the noise and give employees the tools they need to succeed.  Personalized dashboards are another unique advantage of data governance. Data governance tools help data managers to construct dashboards at scale, but also deliver personalized information to employees up and down the organization.  Conclusion Many businesses think that data governance is all about making sure that their employees can't steal customer's phone numbers or take a peek at their co-worker's salary. However, that mindset can limit how effectively these companies govern data.  Data governance is an important element of data security, to be sure, but that's not the only thing that a business can use data governance for. It might not even be the most useful thing that they can use data governance for.  Properly used, data governance can be an important tool for managing employee's data experience. It can help guide employees towards new insight, and encourage them to use the data they already have at their disposal in new ways. 

One major advantage of modern, self-service BI tools is that they let any user, not just data experts or technical staff, build out dashboards and visualizations. These tools are customizable and flexible, and they don't require much technical expertise to create powerful, effective visualizations.  This flexibility means that many businesses have begun to give their employees more freedom in building their own dashboards and visualizations. Instead of every visualization being made by a data team or by IT staff, many employees now have the tools to build visualizations themselves, without any input from anyone else.  In many ways, this is a net good for both the business and the employee. Employees can create dashboards that meet their needs more effectively, and businesses can ensure that their employees are understanding their data on a more personal level.  However, this approach can lead to some issues. Since the average employee rarely has any sort of formal training on dashboard design or data visualization, they're often unprepared to make effective use of their BI tool's visualization suite. Combined with a general disinterest from businesses to invest in training, this means that many employees are largely left to their own devices.   Self-service tools can only go so far. They can give employees the resources they need to create dashboards and visualizations, but ultimately, it's the employee's responsibility to make sure these visualizations are useful. At businesses that don't invest in visualization training, this is easier said than done.  There are many mistakes that dashboard builders and visualization designers can make, especially if they don't have any specific training in design principles. Novice BI users often don't even know that they're making these mistakes, which make them even harder to fix.  Here are some of the most common mistakes that novice BI users make, why they cause so many problems, how a user can identify them, and the best approaches for fixing them.  Ignoring Data Transformation At many businesses, the end user is responsible for the entire data process, from connecting their data all the way to visualization. It's very tempting to skip over some parts of this process, especially for those that have other responsibilities beyond data. Data transformation is one of the parts that most often gets skipped, since it's often the most confusing part of the process, and its benefits aren't immediately noticeable. Users want to take their raw data from their connectors and funnel it directly into their visualizations, and they don't want to waste time transforming it.  In some cases, this is OK. Often, for pulling basic insight out of a data set that's already clean, it's fine to not worry about data transformation too much. However, for more complex data sets, transformation is essential.  If data isn't transformed correctly, then it can be harder to use in analysis and visualizations. Transforming data is also essential for combining different data sets. If a user plans to do something complex with their data, and they haven't transformed the data, it's going to be much harder.  Users that find that their data sets are too hard to use properly often need to transform the data set in some way to make it easier to use. When planning out a dashboard or visualization, it's important to think about what information will be necessary and the best way to transform the data to make that information easy to utilize.  Failing To Answer Business Questions Once a user has their data connected, and hopefully has gone to the trouble to transform the data, they have to decide what sort of analysis they want to perform.  This is where the trouble really begins. All too often, first-time data analysts just kind of click around until they end up with a visualization that looks impressive, instead of approaching the data analysis process with any sort of consistent framework.  Charitably, this approach could be called open-ended. Less optimistically, this approach leads to a lot of visually interesting charts and graphs that end up being mostly meaningless. Data designers need to have clear goals in mind before they start their analysis. This way, they can build content that's actually useful.  The best framework for approaching this process is thinking about which business questions the content is trying to answer. End users view dashboards to get answers to specific business questions; if the dashboard can't answer those questions, then end users won't use the dashboard.  Visualization designers have to figure out how to best use the data that they have to answer relevant questions. Instead of semi-randomly clicking around to discover new data trends, it's much more effective to go in with a concrete goal.  This approach is also better for learning how to visualize data. Users will eventually get the hang of what sort of analysis is most effective for answering which kinds of business questions.  This is the reason that so many beginner data analysts build dashboards that are visually interesting, but go unused. Beginners often focus on the form of their dashboard at the exclusion of function. While a dashboard should look good, it's more important that it actually answers the questions that its users need it to.  Using the wrong visualization Not every answer is going to turn into an interesting visualization. It's more fun to use complex visualizations and crazy colors, but most of the time, business data is best conveyed through a simple line graph or bar chart. When novice dashboard designers start to build out visualizations, they're often tempted to use more complicated methods. BI tools have dozens of different kinds of visualizations, and with that sort of selection, it can be hard to justify using just a basic bar chart.  However, complicated visualizations are generally harder to understand than simpler ones. Almost everyone can intuitively understand a basic line chart or map, but it's much harder to understand a treemap or heatmap.  In general, dashboard builders should be more worried about how easy the dashboard is to understand, than they are about how good the dashboard looks. Less complicated dashboards are generally easier to understand, so they're the best choice for most situations.  Of course, there are some situations that do call for more complex visualizations. Dashboard builders usually want to err on the side of simplicity, but they shouldn't completely ignore complex visualizations. Simplifying a complex analysis can end up distorting the implications of the data, which can be just as harmful to overall dashboard effectiveness.  Designers also need to know what sort of visualizations are the most effective for showing trends and relationships in a more general sense. They need to know which sorts of analysis calls for a line chart, what sort of data is best displayed on a bar chart, and so on. Often, designers can end up using the wrong kinds of visualizations for their data, which hurts how well it can be understood.  Fighting BI Mistakes Many BI tools are moving to a more self-service model. They're more accessible to those without BI experience, and that's mostly a good thing. This way, more people can build their own dashboards and visualizations, without relying on data experts or having to wait for someone else to do it.  Self-service dashboards and visualizations are very valuable, since they allow users to tailor their own content. Users can better make content that they actually want to view, instead of relying on things made by people who didn't understand the end goals.  However, this approach comes with some risks. Users rarely come to their BI tool with any specific training in best practices for building BI content, and that means they often make mistakes. These mistakes mean their visualizations aren't as useful as they could be.  With more knowledge of what causes these sorts of mistakes, what they look like, and how to fix them, users can make dashboards and visualizations that are much more valuable. 

Pricing in the BI space can be very confusing. For one, only a handful of BI companies make their prices public, which makes gauging the average cost of a BI implementation pretty difficult. Even among the tools that do post their prices, the pricing structure can be somewhat complicated, and businesses don't always know what they're buying when they buy it.  BI vendors that don't make their prices public often don't tell prospective customers the price of their BI implementation until they're already pretty far down the sales pipeline. This isn't necessarily because they want their customers to go in blind; since a BI implementation is so personalized, it's very hard for businesses to give a good estimate before they know all the details.  This can lead to a lot of confusion and frustration when businesses are budgeting for a BI tool. Since rates are all over the place, and there isn't a ton of concrete information one way or the other, potential BI customers are in an awkward position. They don't know if their BI vendor is overcharging them, or if they're getting a good deal.  When a BI vendor gives a customer a price, the customer has to have a lot of faith that the vendor is giving them a fair price. Since pricing happens so far down the deal pipeline, there isn't a ton of opportunity to comparison shop or negotiate.  Again, this isn't because BI vendors are maliciously trying to overcharge their customers. Finding a good price for a BI implementation is challenging for both the vendor and the customer; the vendor has to make sure that their costs are covered and they'll actually be able to provide the level of support that the implementation requires.  To add another wrinkle, not every BI vendor sits at the same spot on the price ladder. A less powerful or smaller vendor will probably charge different prices than a market leader.  All this makes properly budgeting and pricing a BI tool extremely difficult. Businesses can't get a lot of clear answers on how much a BI implementation 'should' cost, since that question is so personal to the business, their needs, and what sort of vendor they decide to go with.  However, there are some general guidelines that businesses can follow to ensure that the pricing estimates at least make sense for the scale and complexity of their implementation. This way, businesses still may not be able to budget exactly for a BI tool, but they can at least make some guesses to what the price will end up looking like.  Factors that affect BI price There are a few key factors that affect what sort of price a BI vendor will offer a customer. These include things like the scale of the implementation, the complexity of an implementation, the industry of the client, the amount of support a client needs, and the feature set on offer from the vendor.  The scale of an implementation might be the most important factor in deciding on a price. Most BI tools sell their tool on a per-seat basis, meaning that the more people that the business plans to give access to, the more that they'll have to pay.  Each user gets a unique set of BI credentials, which they use to log into their BI instance. Generally, businesses have to pay for each set of credentials that they want to issue. Businesses that want more people to use their BI system will need to buy more credentials so that those people can have access.  The number of user seats isn't the only way that a BI implementation can be large-scale. Businesses need to be conscious of the amount of data they put into their BI tool. It's not uncommon for BI vendors to charge their customers if their data demands go above certain limits, or throttle data upload speeds for smaller clients.  Some tools arrange their entire pricing structure around their customer's data demands, rather than the amount of people using the software. Power BI, for example, allows customers to buy blocks of data capacity instead of user seats. This approach can be useful for businesses that have low data demands, but lots of people who want to access that data.  The complexity of an implementation is also an extremely important factor. Some businesses have extremely simple implementations; they may only need to connect a handful of tools with basic data connectors. Others have more complicated demands; they may need to connect with an on-premise database, modify their data connections in some way, or want to use a third-party data warehouse.  As a general rule of thumb, the more complicated an implementation will be, the more a business will need to pay their vendor for support and consulting. This isn't always necessarily true; it depends on the business's specific needs and situation.  A smaller company without much technical staff might need more help than expected with a 'basic' implementation. A larger business might choose to forgo support and do most of their implementation with in-house staff. Complexity is still a useful guideline, though.  Many businesses want to implement embedded solutions. Embedded analytics are generally more expensive than comparable non-embedded solutions specifically because they're more challenging to implement. A business that wants to embed content will most likely need to pay more than they'd otherwise have to.  The industry of the customer is generally not too relevant in how much a BI vendor will charge, but industry-specific demands can increase the price of an implementation.  For example, companies that handle medical data are governed by regulations that make it harder to connect that data to a BI tool or other third-party application. There are workarounds, but they're more complicated than connecting the data normally. This can raise the price of an implementation.  Other businesses are in industries that use niche, industry-specific software. BI tools can rarely connect to these sorts of tools easily, so again, the implementation will be more complicated. Connecting these tools might raise the price.  Even beyond the implementation, businesses buy different amounts of support, consulting, and training. It's pretty self-explanatory, but the more consulting hours and training resources that a business buys, the more expensive their tool will be overall.  Some businesses might want to train their employees on the software in an official, vendor-led way, while other companies won't worry about training or after-the-fact support. Sometimes, businesses buy consulting hours to have the consultants build out more complicated transforms and visualizations.  This is a place where businesses can save money, since they only have to buy as much after-the-fact support as they want to buy. Many businesses, especially those with self-service tools, won't have to invest very much in post-implementation support and consulting.  One last factor that affects the final price that a business will pay for their tool is the feature set of the tool, and which features they want access to. More feature-rich tools tend to be more expensive than less robust ones, and some tools let users pick the features they want a la carte.  Often, businesses can buy user seats that have access to fewer features than admin-level ones. This way, they can minimize their per-user costs for employees that don't need access to the full BI user suite.  Many BI vendors offer certain features as optional add-ons that aren't included with the basic version of their tool. For instance, Domo's machine learning tool isn't part of their default offering, but businesses that want it can pay more for access. This helps to keep costs lower for everyone else, since they don't have to pay for a complex feature they'll never use.  To sum up, large businesses with complex BI plans in a niche industry, that need lots of support and access to every optional feature, will pay the highest prices for their tool. Smaller businesses, with less complicated implementations and more common use cases, won't need to pay as much.  To minimize their costs, businesses can scale back their BI plans, go without support and training, and limit their amount of user seats. Of course, trying to cut costs this way can be damaging, but every business will need to make that decision for themselves.  Conclusion The first number that a BI vendor puts out for their services is rarely the number that a business should expect to pay for the service. Vendors expect their customers to negotiate the price, so that they can find a number that works for both the vendor and the customer.  Businesses should be up-front with the amount that they've budgeted for their BI tool. This will help the vendor to know what their options for features and implementations are. Often, vendors can plan around a budget and deliver something that meets their customer's needs while staying within a certain budget.  This also can speed up the sales pipeline. If a vendor won't be able to provide a useful product based on the business's prospective budget, both parties will want to know as soon as possible so they don't waste time on a deal that won't happen.  It's also worth remembering that almost every BI vendor sells their software as-a-service. This means businesses can expect to pay an up-front implementation fee, and then recurring fees as they continue to use the tool.  Purchasing a BI tool is a process that's extremely trying for first-time buyers. Information is scarce, and there aren't really any consistent benchmarks that a business can gauge their quotes against. However, there are some rules of thumb that vendors use to determine their price, and knowing these considerations can help businesses to know what to expect.  The scale and complexity of the implementation is what affects the price the most. Large businesses with complex implementations will expect to pay the most. There are some other considerations, like the industry of the customer, the amount of support they want, and the sort of features they're looking for. For more on BI pricing, plus advice on navigating the BI purchasing process, contact us today. Our team of experts can help you to make the right decisions and connect oyu with the vendors who can meet your needs.