Mean What You Say: Overcoming Semantic Confusion in BI

We came across a humorous post at a Harvard Business Review blog the other day about silly business language. All the acronyms, consultant-speak, jargony slang and high-tech spin are making basic business communication nearly impossible:

you get phrases like, “You should meet this guy with the SIO. He’s sort of this kind of social entrepreneur thinking outside of the box in the sustainability space and working on these ideas around sort of web-based social media, and he’s in a round two capital raise in the VP space with the people at SVNP.” This would all be funny if it weren’t true. People just don’t make sense anymore.

A similar story about LinkedIn’s most overused resume words of the year also reminded us of the often careless and sometimes abusive relationships businesspeople seem to have with the English language.

Synergy, paradigm, silo, value-add, net-net, win-win, leverage, most unique, align – these various clichés have all driven me crazy at some point over the years. But, like a lot of people in technology, I’m probably guilty of overusing “solution,” “stack,” “partner,” and a few others. Within BI, “big data” looks to be shooting across the buzzword hype cycle with record speed. When these words are thrown around so loosely, they lose their essential meaning. For example, we’ve tried to break down the meaning of big data.

All of this reminds me that “semantic confusion” in BI remains a serious problem and appears to be getting worse. Consider the great BI (business intelligence) vs. BA (business analytics) debate. The conventional wisdom seems to be that BI is backward-looking, a technology or process that helps organizations understand what happened, while BA is forward-looking and predictive.

Maybe that’s why IBM has positioned its Watson play around analytics. In our view, however, the fundamental difference between BI and BA is basically how the data is processed and presented to the user – what I would characterize as features of the tool or platform.

A greater challenge is the confusion that results when organizations have multiple definitions of key terms like “customers” or “sales.” This is a huge problem at both ends of the BI spectrum – for developers trying to build easy-to-use applications and for analysts and executives trying to make decisions. And it’s a particular problem at large enterprises with complex organizational charts and fragmented IT systems (dare I say siloed?).

Defining core metrics consistently across the organization as part of a common business language is the keystone of effective BI. As we point out here:

Standardizing your business language also enables transparency, accountability, and concurrence. And the process of establishing a common business language helps promote best practices in collaboration and fact‐based decision making.

For workers in any field to collaborate productively, they must be able to communicate clearly. In BI, the need for collaboration between users and BI teams is especially great at the moment, which means there is a premium on communicating clearly. Developers and business users must simply learn to speak each other’s language if they are to bridge the BI Delivery Gap and if investments in data warehousing and BI are to deliver optimal returns. We think continuous engagement is the right model for developers to think about growing and strengthening their relationship with BI users, who, like or not, truly are calling the shots these days.

So that’s why we say let’s lose the lingo, jettison the jargon, and excise the acronyms. Clearer communication can lead to better BI.