Thoughts from the Dataspace

CONFUSING TERMINOLOGY: pt1 - Business Intelligence

Last week I logged into a really good webinar entitled Ten Changes to Maximize the Impact of Your BI Strategy by Gartner analyst Kurt Schlegel.  I found it to be well worth the hour spent on it (perhaps because most of his opinions seem to parallel mine) and have recommended it to a number of folks.  Mr. Schlegel made one point, in passing, that got me thinking about how we, as BI professionals, seem to go out of our way to confuse the business community about what we do.

Business Intelligence?

For just a minute, try to put yourself into the shoes of a BI consumer or prospect.  In particular, try to forget the concepts of business intelligence, data warehouses, reporting systems, etc.

Now, consider the term ‘Business Intelligence’.  What does it really mean?  Once you get yourself past the standard, glib comment, “Oh, that’s an oxymoron isn’t it?”, what do you think of?  Hmmmm, could it be something like spying?  Could it be something like gathering intelligence about the business environment?

My point is, your first thought isn’t going to be business performance measurement (BPM) systems.  However, BPM is probably about 90% of what we do in the BI field.  Sure, Business Intelligence has a sexy, almost James Bondian ring to it but is it very descriptive?  Not at all.

We Were DSS Once… And Young

For those who haven’t been around for very long, keep in mind that Business Intelligence wasn’t the first name for what we do.  Before BI was DSS, or Decision Support Systems (yes, that’s the reason why MicroStrategy’s product used to be called DSS Agent).

Stepping back even further, does anyone still remember EIS, Executive Information Systems?  Same concept, different name (and BTW, for real trivia, MicroStrategy used to sell a product called EIS Toolkit)

In a lot of ways, these old terms are just as good, and maybe even better, at describing to users what this whole field is about.

The Takeaway

So, what’s the takeaway?  Well, the folks who need business intelligence largely don’t think in terms of business intelligence.  They think in terms that fit their world.  Terms like business performance reporting or, even better, inventory optimization reporting OR sales force performance reporting OR sales margin analysis…

So, if you want folks to buy in to your concepts, don’t lean on our industry-speak. Talk in terms that your target consumer understands,

Do you have any ideas on terminology that just confuses the business community?  How about anything else we do to shoot ourselves in the foot / collective feet?  Let me know.

Want Executive Buy-In? Deliver Quickly!

Somewhat like wars, business intelligence projects can take years and cost millions of dollars. So, how do you be a hero and not a victim?

Deliver Quickly

More than one business intelligence project has been cancelled because management lost interest in spending money on an intangible.  Visionary executives understand that BI is a tool to transform the business.  They understand the organizational changes they are looking for, including new business processes, and why BI is the path to making those changes.

But, unless you’re working with a visionary sponsor (and the world has desperately few of these), BI is really just a “nice to have” item, not a necessity. There’s a little voice in the back of most sponsor’s heads saying, “My folks do their jobs today without pretty charts & tables, they’ll be able to do their jobs tomorrow without them, too.  We all know that most IT projects are big sink holes, maybe that BI project is just another one of them.”  

You’ve got to show this kind of executive something they can wrap their head around.  Something concrete.  Something that demonstrates you’re not wasting time and money. And, you’ve got to show it quickly.  Unless you do, your sponsorship could quickly dry up and find some other, more tangible, effort to sponsor.

While you certainly won’t be delivering a complete system with all the bells and whistles, or even with all of the data, I recommend that you push to get a user-accessible deliverable out in under a month.  That’s right - prove your value in 4 weeks, or less.  And then, after that, keep pushing to upgrade and enhance every month.

Other Benefits of Delivering Quickly

Maintaining sponsor interest is just one of the advantages of pushing out rapid deliverables.  Here are some other benefits:

• RETURN ON INVESTMENT: Assuming that you’re actually delivering something of value, why not get a head start on paying for it?

• USER VISUALIZATION: I’ve read that Steve Jobs didn’t believe in asking for user requirements.  He felt that his intended users couldn’t really visualize what he had in mind and the only way for them to understand it was to give them the finished product (please excuse me if I bastardized that a bit).  Business intelligence is much the same.  There are a great number of users who just can’t understand what they’d use the system for until they’re given a real-life example of the tool, with their data in it.  Thus, providing them with quick, early deliverables will help them understand what they’ll be getting, also helping them better visualize ways to take advantage of the technology.

• REQUIREMENTS VALIDATION: Sadly, it is possible to create a BI system that just doesn’t provide any value.  It’s been done before and it will be done again.  Of course, wouldn’t you prefer not to be the one doing it?  Given this fact, isn’t there value in quickly getting feedback on whether or not your project is pursuing the right deliverables?  Delivering intermediate, partial results will give you this validation.

• MAINTAINING TEAM FOCUS: Finally, big projects frequently get bogged down.  But, we all know that nothing motivates like a deadline.  Think about how motivated folks in the US get just before April 15 (which reminds me…).  Well, use the monthly delivery cycle to set those deadlines.

Metadata: Mundane… Yet Critical For Analytics Success

Years ago I saw Bill Inmon speak at a conference and one thing he said resonates with me to this day.  He said, “Let’s face it, no self-respecting developer ever went back and documented his code.”  Not only can this be applied to program documentation but it can also be applied to the other metadata that describes a business intelligence system.

But that metadata can be crucial, especially if you’re trying to get out of the business of creating reports.

The New Model of Analytics & BI

As I’ve written recently, more and more companies are finding BI success by getting IT out of the business of creating reports.  They’re seeing more users jump on the BI bandwagon if the responsibility for creating reports is distributed to the departments that need those reports (frequently to reporting gurus in those departments).  In this model, IT becomes the data provider and the departments become the data consumers.

Why the New Model Screams Out for Decent Metadata

As effective as this model is, however, you need to beware of some potential pitfalls.  One of the biggest is in how these user departments find and interpret the data that IT provides.  Put another way, if the user can choose between twenty data elements that all sound similar, how do they know which to put onto their reports?

Furthermore, how do you ensure that departments A and B are both interpreting the available data in the same ways?

As should be obvious, if you don’t provide some tool for understanding and interpreting data, reporting remains a series of departmental stovepipes that can’t be reconciled and will very likely be misinterpreted.

What You Should be Doing About Metadata

There are a few, relatively simple, things you can do to ensure that you don’t face the Tower of Babel that led you to build a data warehouse in the first place.

1) CAPTURE METADATA IN DATA MODELS: It always surprises me when I visit a mature IT department that isn’t using a competent data modeling tool. There comes a point when data models in Visio, or Excel, or notebook paper, or pure grey matter just don’t cut it.  Not only will it help IT folks keep track of what’s going on but a good data modeling tool is also a great place to store metadata about your systems.  For example, this screen from Embarcadero ER/Studio Data Architect shows some of the metadata you can capture about an individual field.  At the bottom of this screen you’ll notice that the data modeler has entered some user-friendly information about what the field UniqueFloorKey represents.

2) GENERATE METADATA INTO YOUR DATA DICTIONARIES:  A lot of folks don’t realize that most relational databases come complete with administrative tables to hold data dictionaries.  The databases use these so their engines can understand the database structures.  However, these tables can also hold a good deal of optional information about the databases. The best part of it is, you can write simple SQL queries to get at this information!  I’ve used this capability for a few things in the past including writing queries to generate data dictionary documentation and writing reports in BI tools so users can access this information themselves.  I’ve, even, written queries against these data dictionaries to generate other queries (probably not advisable for novice users).

Better yet, if you’ve stored your metadata in your data model, you can automatically have it generated into your database, along with the rest of the data model.

For more information on how to use these capabilities, look into the data dictionary in Oracle, the extended properties in SQL Server and similar items for other databases.

3) DEVELOP MECHANISMS FOR GETTING USABLE METADATA INTO END USER HANDS: Once you’ve captured this metadata, makes sure you have a way to get it into your end users’ hands.  Some tools, such as Business Objects and Microstrategy, have the ability to read these data dictionaries into their tool-specific metadata.  Once this is done, users can easily see your definitions, sometime by right clicking on a reporting object and, sometimes, with no extra work at all.

Other ways to expose metadata to your users might be some piece of documentation, predefined reports built into your BI environment, or a metadata tool such as IBM’s Business Glossary.  Dedicated metadata tools will provide even more functionality than providing the basic column and table definitions we’re talking about here.

In any case, to successfully deliver intelligence, you need to also deliver information about the data (i.e. you need to deliver metadata).  You don’t want to overdo it but you do need to make sure that all your users are working from the same script.

The Novice’s Approach to… “What… If Analysis”

When folks talk about what they want to do with business intelligence, “What… if?” analysis is rarely number one on their lists.  On the other hand, it is most folks’ number two (usually after “provide users with easier access to data” and before “predictive analysis”).  It’s interesting, however, that “What… if?” analysis is rarely actually performed in real life.

WHAT IS “What… If” ANALYSIS?

What if analysis is exactly what it sounds like - looking at your data as if some situation was true.  For example

• WHAT would our profits be IF our unit cost was reduced by 2%.
• WHAT would happen to our profits IF we spent 5% more on marketing but it produced a 5% increase in revenues? A 0% increase?
• WHAT would each salesperson have produced last year IF we didn’t carry our  vanilla-flavored chocolate pudding?

It isn’t.

AN EXAMPLE

Here is a simple example from QlikView that asks the question, “What would happen if our revenues changed by X%?”

In this example, the user can modify the revenue forecast.  As the example shows, if you don’t expect there to be any changes in revenue, the ‘as is’ and ‘simulation’ amounts will exactly equal each other.

On the other hand, let’s see the predicted results of 25% increase in forecast revenues:

Now the user can see the difference graphically.  This analysis could also, of course, be shown as a table so users could analyze the actual, What..If figures.

BEHIND THE SCENES

You can do What If analysis with any BI tool.  The trick is to insert prompts and variables into your reports that users can change.  Then, use those variables as figures or multipliers in your reports.  Just about every BI tool supports the use of variables.

In the example above, the slider bar sets a variable called vRevenueIncrease.  The magic is in the graph.  Basically, the graph charts two lines: the forecast revenue AND the forecast revenue * vRevenueIncrease.

While we’ve shown a slider bar, most BI tools give you a few ways to enter variable values.  

BE CAREFUL

When you do “What..If” analysis, make sure to consider the cause and effect relationship between variables.  For example, if you model a 5% increase in revenue you’ll show a great improvement in profitability.  However, that profit improvement is really illusory if you haven’t also modeled the increase in cost of goods sold and the other costs associated with an increase in sales (By the way, a 5% increase in sales price, as opposed to unit sales, might properly show the related profit increase so long as the increased sales price wouldn’t also lead your customers to purchase less).

Also note that, most BI tools make it difficult to store variables between sessions or to save multiple scenarios.  So, if you want to keep what you’ve created, export it, print it, or lose it.

Anyhow, thanks for your time.  Feedback is encouraged & appreciated.

Dance Moms and the Future of Business Intelligence Acceptance

If you’ve read my posts about business intelligence you know that I’m fascinated by the fact that many BI and analytics systems just don’t garner the usage that their sponsors envision for them.  This can be tied to a number of factors including a failure to align analytics with business processes, mismatches between BI tools and user requirements, corporate culture issues, and organization design matters (I covered this point in my last post).

But, I’ve recently started to believe there is another factor that, in the long run, bodes well for BI usage.  This change relates to the general comfort with data and technology in society.

When I graduated from college (1984, if you must know), the IBM PC was relatively new and 15 megabytes of disk storage was huge.  In fact, most PCs didn’t even have hard drives - they had floppy disks.  There was no Apple Macintosh.  I, actually, wrote term papers using a mainframe word processing program that formatted them in batch jobs!

So data, and even computer, comfort was developed only by those of us who were interested in the concept (i.e. most people created their term papers with a technology we called the type-writer).  Most of us also remembered and feared HAL9000, the computer in 2001 A SPACE ODYSSEY, 

As a result, many of us harbored, and still harbor, a basic fear of computers and technology.  Our children, on the other hand, grew up with computers and they aren’t afraid to press buttons (as evidenced by the number of viruses and hidden background processes recently discovered on our home computer).

Consider your own situation for a minute.  Do you know someone, perhaps your spouse, parent, or in-law (or, frequently, all three) who seize up with fear at the thought of trying to program the TiVo, downloading apps onto the iPad, or clicking the wrong link in their web browser?

Now, compare these folks to your kids.  Do your kids suffer from the same fears?  Most likely the answer is, “No.”

These same kids are the knowledge workers of tomorrow.  They’ve grown up with the concept of computers and the concept of searching for data.  On the whole, the next generation of corporate leaders are just more comfortable with data and computers.

I guess what I’m saying is that, in the future, BI will be more easy to integrate into organizations because today’s kids know how to record Dance Moms (Tuesdays at 9 pm, 8 Central, on Lifetime) on the TiVo.  Gd help us :)

Would love to hear your thoughts!

Ensure BI Usage by Building A Data Driven Company

When building an analytics system, don’t let some BI vendor convince you that everyone in your company will create their own reports; They won’t.  Virtually every new BI effort starts off with this goal of instant user self sufficiency.  But remember, while BI and analytics are marketed as the Viagra of data self-sufficiency; actual mileage may vary (OK, I believe I mixed a few industries and metaphors there but I think I’ve made my point).

When they realize that the Viagra approach just provides false (and expensive) hope, the next place most companies turn is to having a set of experts in IT use the shiny, new BI tool to create predefined reports for users.  While a step in the right direction, this not the right step to take for two closely-related reasons:

1. Virtually every BI effort starts with the premise that distributing reporting responsibilities to the business will reduce the reporting demands on IT. Having IT create reports largely shifts the same work to a new toolset, and
2. When IT creates the reports, the report developers are a step removed from the day-to-day input of the folks who need the data.  The developers won’t have that hands-on feel for what’s really needed and even for what the basic business terms mean.

I recently spoke with managers in two Fortune 1000 companies (Automotive and quick service restaurant) who have both come up with the same answer to this problem.  And, both have user communities that are gobbling up their BI capabilities.  The approach is this: Develop a BI subject matter expert (SME) in each user department.  This SME will create the templates and reports for their peers in the department.  Rather than assigning this role to a random person in the department, this person must already show a proclivity for working with data.  This is usually the guy in the department who everyone already turns to when they need to do something complex in Excel.  

Situations will vary but being the BI SME is usually not a full time role.  These folks have other day-to-day jobs to do.  But, because they are a part of the department every day, they’re in the perfect position to understand what their coworkers are saying & what they need.

Having a BI SME also saves you from wasting money training folks who aren’t going to get anything out of it.  Train the SME on the complexities of the tools.  Train the rest of the department on the few steps necessary to open & use the analyses he creates.

So, when preparing to roll out your BI or analytics system, don’t expect users to just pick it up.  Build the right organization, use the right tools and, if the need for data is really there, the system will get used.

Would love to hear your thoughts!

The Futility of BI Standards

RIGHT TOOL FOR THE JOB?

Whenever an organization gets into business intelligence they almost always want to pick a standard BI tool.  I heard this theme again today on a call with a major insurer.  Now, I’m not against the concept of standards but BI is usually too broad a concept to be covered by one ‘standard’.

For example, do you expect your BI environment to support:

• Executives with pretty dashboards?
• Data analysts with high powered OLAP and, maybe, predictive analytic needs?
• Casual BI users who need standard, paramaterized reports?  (BTW, this usually the largest group of users in organizations that see wide adoption)
• Executives who need a map-centric, geographic view of their data?
• … ?

Can you shoehorn all of these users into one tool?  Probably; but in most cases putting them all into one tool will cost you:

• Unnecessary license fees - for example, compare the price of a QlikView user license with that of a SQL Server Reporting Services license
• User frustration - How is your novice user going to react to all the bells and whistles of an advanced analytic tool?  How is your data analyst going to react to the limitations of pretty front end with little data manipulation capability and no access to the underlying detail?

So, don’t pick a BI standard tool.  Categorize your users by need and then pick standards for each category.  Don’t go crazy; you probably don’t need 8 different BI tools.  But, also don’t try to shoehorn everyone into the same tool.

The Myth of Self Service BI

Appfluent for Monitoring BI & DW Usage

What parts of your data warehouse are really important and which are never touched?  A few weeks ago I and some colleagues here at Dataspace saw a brief demo of Appfluent.  Affluent is a tool that monitors and reports on the use of database objects and, in some cases, BI tools.  It can answer important questions such as:

• Which tables are being used and which aren’t?
• Which queries are run most often?
• Which queries gobble up the most resources?
• etc.

Armed with information like this you can do things like:

• Eliminate unused tables
• Develop strategies to improve the performance of troublesome queries
• Determine if your warehouse is really being used at all

In the end, monitoring like this can help you improve and, perhaps, lower the cost of your data warehouse.  You might want to give it a try.

Angry Birds, Good - Angry BI Sponsors, Not So Much

Most BI vendors are actively pushing technologies for developing mobile business intelligence applications.  Now, anyone who’s ever shot an angry bird at a rickety stack of debris knows that apps are cool.  

The question I have is: With the ubiquity of web access, do we really need to be putting dollars and effort into supporting new BI delivery platforms?  Since web delivery has improved so much over the past few years and promises to move even farther, do we really need mobile BI apps?  Can’t we use existing, web-based BI to support multiple needs?  Are tablet vendors planning to stop supporting their web browsers? I doubt it.

To be clear, I am not doubting the need for BI on the go but I am doubting the need for BI software built solely for mobile devices.

I just spoke with an old contact, a sharp data warehousing manager here in Detroit and he had the same opinion.  I, also, recently read a strong blog posting on this subject (click here for the article) on the Dashboard Insight website that explains why dedicated mobile BI apps just don’t make sense.

Now, I’m sure there are some applications for which dedicated mobile BI Apps are a good fit but I’ll bet they are few and far between.  I am open to other opinions, however.  Think I’m wrong?  Post your reply and let’s get a conversation going.

Thanks!