11–20 of 29 posts
Since in Brazil we have 0 self-service gas stations, should I understand that Brazilians do not have the skill necessary to pump gas?
Domain expertise is hugely important at making sense of data. Self-service allows domain experts to quickly look at data themselves. They may have to learn skills in data-sensemaking, but the expert in data will have to learn about the specific domain (often much harder).
I'm noticing that more and more people in a variety of fields have at least a passable understanding of how to make sense of data. For quick questions, self-service access to data makes the process much faster with little risk.
I've been in organizations that tried to put data behind gatekeepers who would protect users from making mistakes. In those cases, we made a lot more mistakes because not enough analysis was done, or people didn't have access to data.
I've been in other organizations where we let everyone look at the data. Sure, some people made mistakes, but we used that as an opportunity to teach.
If I had to bet on which type of firm would win, I'd bet on the latter. I'm deeply skeptical of the promises made by BI vendors, but self-service analytics isn't one of them.
I work in business intelligence, and my understanding of "self-service BI" has never been "no developer needed at any point" or even "unskilled knowledge work". I have always approached it as a particular environment. Specifically, BI team must produce the appropriate data lakes and interfaces to support user-driven design and simple aggregations. The BI team would model the data, optimize for analytical speed, apply…
Get along to a Microsoft sales presso on Power BI for that.
Self Service BI tools are not intended to take the place of analytic skill any more than they take the place of domain expertise and that has never been the meaning of the term. The promise of SSBI is to reduce the incredible friction domain experts traditionally had to deal with to get their key business questions answered. Yes, your users need to develop other analytic skills to go along with their domain expertise! Turns out most of us have stronger and weaker points and have to learn and evolve our skills to get our jobs done well. Taking on SSBI means exactly that for your users who most likely have at least one of the key skills (domain expertise) already and maybe more.
Using an exploratory type ssbi tool is a conversation with your data via an interactive tool. One question leads to another leads to another and if the alternative is having to stop and ask another department to put each follow up question on their backlog the conversation is basically broken and often business users just stop asking and revert to pure gut feel decision making. I think most of the progress made over the past 20 years in BI has been about making this kind of process more agile in the same sense as iterative development. SSBI is part of that. The inversion of analytic process in big data systems is part of that as well. ML can also play a role in that with the right circumstances.
What we can do, as BI vendors, is build tools and documentation that guide users who start with only part of the skills they need into learning the rest while using the tools we provide. We can present defaults that guide the user towards visualizations and views that are easier to interpret. We can embed analytic skill building into our applications in tutorials and hints. We can build metadata up as users inform us about the data as they use it rather than requiring them to do it up front in a big-bang DW modeling session. We can inspect the data with simple heuristics to try and hint the user how to use it with the tool or apply better defaults. We can build better cleansing munging and data consolidation tools. We can build tools to let data analyst teams also turn things around more quickly. And yes, perhaps we can try using machine learning to suggest possible avenues for the user to explore which _of course_ must be interpreted by a user with the right skills because ML is going to be wrong a lot of the time and users need to understand false positives. It's all part of the process.
Bailing out on SSBI because of marketers being marketers just isn't pragmatic. Better that we just keep evolving our products from both the data science team end and the business user ssbi end.
To me, what is wrongly called self-service analytics is often really self-service reporting. You are consuming the end result, not the analysis itself.
I work for a company making a "self-service analytics" tool, but we don't sell it as a "magical analytics" tool that does everything for you. Rather, we see it as a "you don't have to involve the IT department" tool for those quick jobs that analysts or other knowledgeable people would ideally like to do themselves, but can't due to lack of tools. To me, what is wrongly called self-service analytics is often really s…
Yes, there are pitfalls if you give people in ~B access to the BI tool. They could make bad decisions based on the data. On the other hand, they are already making bad decisions without the data. In a world where |B| is limited, it can be hard to make the right tradeoffs. You might choose to let people in ~B use the tool but have a policy against sharing the results without a once-over from someone in B.