> If we assume that the problem with self-serve BI is not SQL, but the context and semantics of the data, then it follows that the solution is to teach people about the data they're querying, regardless of interface.

This has been the basic truth of any self-serve BI system I've used.

Even in smallish orgs there are often three steps - the engineer who instruments code/implements a metric, the engineer who builds the ETL pipeline into the underlying BI warehouse, and the person querying that data. So there are minimally three people in potentially three different roles who need a shared specification and understanding.

Also, self-serve BI tools can be surprisingly opaque and their output can be hard to validate/test. So even if you know accurately what data you are querying, testing that your query is what you intend is hard.

Hot take as a datamonkey who’s done a lot of work in this vein professionally:

General-purpose self-serve is hostile to non-technical end users. Most do not have the mental model of SQL to guide their usage of the tool, so giving them an “open-ended” option to run their own vizes ends up really being a fence-toss of some technobabble garbage that isn’t useful to them at all.

“Slice n’ Dice”-style filtering added to an existing set of reports, however, is a completely viable middle ground. Practically speaking, this means writing the basic dashboard query, then hooking a bunch of query parameters up to some front-end UI widgets to let end users pick the date range, level-of-detail, filter which trendlines or categories of data are shown, etc. Just use good taste to avoid going overboard - don’t try to make every last detail configurable.

This is something I've been wrestling with for a little bit. The challenge is that if everything is locked behind a data analyst then things only move as fast as the data analyst. If a business person needs some information now, not next quarter, the challenge is managing the queue for the data analyst which devolves into a world of "rush jobs". It's all the things highlighted by the theory of constraints (The Goal by Goldratt is sooo good). You can alleviate the DA bottleneck by getting more DAs or you can find ways to help the business users do some of the basic stuff themselves.

I wholeheartedly agree that just giving a business user access to the straight database is not ideal for all the issues mentioned - they don't know the context and the gotchas in the data combined with probably not understanding how to write SQL. I think an effective data warehouse strategy with straightforward data marts of materialized views can simplify the interaction and maybe even make it really simple for someone to generate basic visualizations. A lot of business people can make basic dashboards in Excel which, worst case, could be connected to a data mart. It's not going to handle BIG data but may cover a large number of use cases for most businesses.

I'm in favor of creating some basic dashboards We've also been experimenting with embedding dashboards in internal tools that provide some slice and dice capabilities but with a high level filter. A user can manipulate and tweak a dashboard for a specific customer but to look at a different customer they need to navigate to it in the internal tools, not via the dashboard.

Yes. Say you want to get all sales for a list of 75 products out of the 30,000 products that you sell in a list of 125 stores out of the 4500 stores you operate. Self-serve is perfect for this. So long as you can paste lists and not require people to search for things and click checkboxes.