A Holistics colleague of mine, Dave, has this thing where he says 'No data tool can ever help you achieve data literacy in your company. But we sure can make sure we don't get in the way.'
I think about that a lot.
As a tool maker, it's easy to introspect too much and think about all the ways Holistics can solve all of our customers's problems, and make their lives better, and make them write happy emails to us, and so on. But the truth is that business intelligence problems are socio-technical problems, and you usually have to fix some combination of people (read: culture) and process and tool, all at the same time.
Which brings us to today's topic.
It shouldn't be a surprise to anyone that self service in the data space is hard to define. Benn Stancil has a whole piece where he argues 'self service is a feeling' — which I largely agree with — and Stancil says that what self-service is depends on how the org feels about self-serving data from their tools. Do they trust it? Do they feel comfortable getting what they need, without emailing an analyst?
This, Stancil continues, depends on the context of the organization (do they trust the numbers in their data systems?) and their data maturity (do they feel comfortable with their BI tool?) and their business needs (does the CEO set the tone for metrics consumption?)
So, yes, the organizational context matters when you're talking about self-service BI. A self service setup that works in one company might not be equivalently self service in another.
But I think we can get more specific than 'SS is a feeling'.
Instead, I'm going to invert the question and define self service by what it's not. Because I think this is more useful.
In a sentence: I think self service can be thought of as a business outcome that successfully avoids a common organizational failed state. To put this more concretely, I think self-service is a state where the business is sufficiently data-driven, but the data org does not look like an army of English-to-SQL translators.
This should become more useful in a minute. Let's walk through this together:
You are a small company. You realize you need a data team, so you hire your first analyst and you use Google Data Studio or Tableau or something. Your analyst churns out reports for management, and all is well for a few months. But eventually your analyst can't keep up with all the requests she's getting, so you hire another. And another. And another. And then your company grows up, creates departments that report to different leaders, and each department hires their own analysts, and now you have an army of analysts in various parts of the company all writing queries or tuning Excel spreadsheets, just trying to keep up with the business requests your company throws at them.
These analysts are mostly English-to-SQL translators, or Excel jockeys. They're all relatively junior. Some are senior, sure. But there's not much career progression for them overall. And many of them are suitably displeased with their jobs, and a reliable percentage of them churns out (read: quits your company) every six months or so. You keep hiring new analysts to keep up with business demand, and grit your teeth at the management challenge of constantly churning employees.
This is the failed state.
(Note that in this scenario, your company is data-driven. This isn't always a thing! It's more common to be in a company that isn't data-driven, which doesn't have this problem, and will instead have a different set of problems and a different set of failed states. Anyway.)
This is the failed state that self service is supposed to solve. It is a failed state because it's rather painful to maintain an army of English-to-SQL translators. Ideally you want a smaller group of data folks that can service a much larger number of data consumers. And the only way you can hit that scale is to have some form of 'self service' — that is, some way that business people can get the data they need, without going through an analyst on Slack or email.
In other words, self service is valuable as a goal because it increases the operating leverage of your data team. You can serve many more people with fewer analysts. This is an ideal business outcome.
Now: notice that I have not defined what features a self service BI tool should have in this context. Notice that I have not talked about tools, or processes, or even org structure. All of these depend on the nature of the company.
Instead, I'm describing self service by telling you what it is not — it is not this failed state where the company is data driven but they've gotten there by just throwing bodies at the problem, and have 100 data analysts spread across six departments writing 100-line SQL queries. Self service, when seen through the lens of my inverted definition, is how far away you are from that failed state.
Of course, smart readers would recognize that this is simply another way of saying 'in a data-driven company with high demand for data, bad data organizations tend look the same, but working data organizations look very different from each other'. And indeed data-driven companies with good self service capabilities all look very different. For instance, in one consumer software company I know, many people in the company's reporting structure are fluent with SQL, so they are able to solve their self service problems with a combination of SQL-oriented BI tool, a well-curated data warehouse, and one or two visualization tools. This would not work in a cosmetics company where the majority of their staff aren't SQL-savvy, and prefer to have dashboards built for them. Self service in the first company looks different from self service in the second. (Holistics, by the way, works better in achieving self-service goals at that second company, as opposed to the first).
In other words, self service business intelligence is most usefully described as a business outcome — a place that you get to through a combination of tools and processes and org structure. And the way you get to it is by asking yourself, each step of the way: "does this move bring us closer or further away from the failed state?"
In such a scenario, the best thing a tool can do is to not get in your way. The best thing a BI tool can do is to give you handles when you want to evolve your org away from the failed state. And that's what we have to do.
What's happening in the BI world?
Join 15k+ people to get insights from BI practitioners around the globe. In your inbox. Every week. Learn more
No spam, ever. We respect your email privacy. Unsubscribe anytime.