Thoughts from the Dataspace

Thoughts on business intelligence and data warehousing from folks who've been doing it for 20 years

[dataspace]

[dataspace]

To be Successful in Business Intelligence, Build Four Pillars

Effective Business Performance Measurement, Business Intelligence, and Data Warehousing requires more than simply ‘throwing a BI tool’ at some data.  After 20 years in BI, we've come to the realization that success rests on four ‘pillars’.  If you've got these covered, you're on the right path.  These pillars are Culture & Business Process, Data, Architecture, and Business Intelligence. 

These four pillars are defined below:

CULTURE & BUSINESS PROCESS

As I've noted here and here, BI success is much more than just rolling out a system that works (oh, and here, too).  Real BI success means rolling out a system that gets used.  In many cases BI is optional - people do their jobs today without it so just throwing data at them doesn't mean they'll use it.  On the other hand, understanding where BI can enhance the business and then designing business processes with BI at their heart helps ensure that the new BI system will get used.  Thus, while the tool might be BI, the goal is not BI - the goal is improved business processes.  And, to ensure that your BI system will support those business processes, you need to think them through BEFORE you design it.

At the same time, some organizations are data oriented / data friendly and some are not.  In designing your BI system you must be realistic about your culture.  Will your people take to it?  If not, are there some people who will take to it and can feed it to their coworkers?  Are there managers willing to consider data-drivenness (yes, not a word but better than what the spell checker recommended - data-drunkeness) when evaluating their staff?  If not, perhaps you need to start with with lower BI expectations.

DATA

It doesn't really matter whether you're using a Kimball approach, a normalized approach, some hybrid, a punched card approach...  What does matter is that you have a data modeling and storage approach that will work and can be justified, beyond simply what some book tells you to do.

In the end, we're largely talking about data models: do they correctly model reality and still provide the necessary information and query performance?  The data pillar isn't talking about technology but, instead, about your ability to represent the business in data models.  Along those same lines, do you even need a data warehouse at all?  While everyone enjoys a good data warehouse project, perhaps you can address your specific situation by applying a BI tool directly to your OLTP data.

ARCHITECTURE

Architecture represents the technologies underpinning your system - do you have the processes and tools necessary to reliably get clean data to the places where it is needed?    

BUSINESS INTELLIGENCE

Business Intelligence is the piece that the user sees: can you develop and deliver reports, analyses, and predictive analytics in forms required by the business users & processes?  Remember, BI isn't just one thing.  It really encompasses a wide variety of technologies such as prompted reporting, slice and dice OLAP, data mining and predictive analytics, geographic information systems...

Remember, too, that it usually makes sense to set BI standards for categories of users but not for whole organizations.  Why?  Well consider the case of the BI tool SAS.  SAS is used by analysts, frequently with a statistical background, to build predictive models.  Would you put it in front of your C-level executives?  Probably not.  The point being that SAS may be the standard for your business analysts but it shouldn't be your sole BI standard.

So...

What do do with this framework?  Well, I'm afraid it gets a touch more complex now.  For each of the pillars, examine your people, your processes and your technologies in light of your goals.  Are they sufficient?  Where are the cracks?

In future posts I'll provide more details on the kinds of tasks and staffing each pillar requires as well as the consequences of failing to build that pillar sufficiently strong.

Let me know your thoughts.

[dataspace]

Why BI Efforts Fail

Contrary to what many people may believe, BI failure is neither a result of President Obama's Health Care Legislation nor of Mitt Romney's offshore bank accounts.  BI failure, actually, results from things that are largely under our control.

I recently responded to this commonly-asked question of BI Failure on a Linked-In forum.  While I'm not sure as many fail as some folks think, it is worth taking a look at why some do fail.

What Does BI Failure Really Mean?

Before you answer the question of why Bi efforts fail, you need to define what you mean by "fail".  Believe it or not, there is an vast and exciting array ways in which these efforts can "fail", including:

1) The system gets built but not used (Business Process Failure)

2) The system does not work on a technical level (Technical Failure)

3) System development time and costs run far above what was budgeted and scheduled (Project Management Failure)

4) It takes too long to get any tangible results from the system leading management to lose interest and pull the project's funding (Attention Span Failure)

Of these, one and four are more dangerous, and less understood, than two or three.  Technology, frankly, is relatively easy.  Project management is a little harder - but still doable.  Commitment and adoption, on the other hand, are not.

Avoiding Business Process Failure

To avoid cause number 1 (built but not used), realize that successful BI rests on four pillars: Business process / Culture, Data, Architecture, and BI Front end.  While these things are tightly interconnected, attacking them should start with Business process / Culture.  Unless you understand how the business will change with the new system and why this change is valuable, there is a good chance that the business will NOT change and your BI investment will be meaningless.  

Remember, the change is NOT something like, "We will be more data driven." (really, who doesn't want that?)  It IS about things like, "Every quarter, each sales rep will be expected to analyze a list accounts by margin dollars and schedule visits to those in the top and bottom quartiles of this list."

Avoiding Attention Span Failure

Regarding management patience, don't take years to roll out your system.  I recently saw Ralph Hughes speak on Agile BI and the concept is very powerful.  Don't wait for a major release but, instead, shoot for 2 week delivery cycles.  Give your users incremental pieces of functionality every few weeks, learn what's useful and what's not, and use this information to shape your efforts going forward.

This is easier said than done when the data behind the BI system is dirty and disconnected.  Still, there are ways to create partial solutions with partial data that do provide quick value as well as a vision for what will eventually be accomplished.

Thus

Thus, before running off and blaming Fox News or the liberal media for BI failure, look at yourself, your team and your processes.  In other words, success is largely within your control.

More at: http://www.dataspace.com/blog/

[dataspace]

CONFUSING TERMINOLOGY: PT 2 - Data Warehousing

With all due respect to Bill Inmon, the father of data warehousing (Dad?), isn't the very term Data Warehousing confusing to everyone but the folks who build data warehouses?

Really, when you tell people that you work in data warehousing don't they usually respond that they know all about data centers?  In other words, the term data warehouse just doesn't make sense for what we do.  Perhaps we should go to something less flashy but more accurate like, "Reporting Databases"?  Or, perhaps, something like, "subject oriented, integrated, non volatile, time variant collections of data in support of management decisions?*"

OK, maybe not.  But, in the end, don't sell your sponsors on the terminology, sell them on what the technologies will allow them to do.

* Roughly, Bill Inmon's original definition of a data warehouse 

[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.

[dataspace]

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.

Agree with these ideas?  Vehemently disagree?  Add your thoughts.  Let's push the conversation forward.

By the way, if I might gently pitch a Dataspace offering, we're about to announce a service that will deliver a working business intelligence system at a reasonable fixed price in two weeks or less.  If you're considering BI, this is a great way to get started. Call or email me at [email protected] if you'd like more information.  

Thanks!

[dataspace]

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.

[dataspace]

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?

WHY IS IT SO HARD?

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.

[dataspace]

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!

[dataspace]

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:

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

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!

[dataspace]

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.

[dataspace]

The Myth of Self Service BI

Most business intelligence efforts start with a statement like the following, "Let's build a BI system so our employees can get whatever data they need, when they need it."  While well intentioned, statements like these are misguided.

The truth:

If folks do their jobs today without using a shiny, new BI tool, why are they going to put extra effort into learning your snappy new tool?

Most folks don't get a big thrill out of accessing data - BI is like a dishwasher, a tool for getting a job done.  Do you want to go to classes and learn a panoply of new things just to use your dishwasher?

Most folks' data needs are limited to a relatively narrow range of topics (e.g. sales folks typically don't need to access HR data).

Even with data warehouses and strong metadata, BI tool vendors have not yet produced a tool that gives anyone simple access to every piece of data in an organization.

The implications:

A few folks do have the need, desire & technical skills to get and analyze their own data.  These folks are called data analysts.

While it's not sexy in terms of BI (is anything sexy in terms of BI?), the vast majority of folks have structured jobs that require access to a limited range of data and they usually need it in some set format (e.g. this week's accounts receivable aging report).  Assume that these folks need BI tools that provide predefined reports into which they can enter a few parameters - tools like WebFocus, Crystal Reports, and SQL Server Reporting Services.  Also assume that these folks will NOT create these reports on their own - you will need technical experts to create and maintain these reports.

You are far more likely to see wide usage of your BI systems if your business processes are designed to be data driven.  Business process design, along with a culture change towards being data-focused is a prerequisite to widespread BI adoption.  It is also hard, time consuming work.

Widespread BI adoption isn't always the correct measure of success.  A $2 million BI system that serves just one user could be a major success if that one person makes or feeds input into multi-million dollar decisions. 

So, if you want a clear path to ROI, rather than starting out to build a BI system, start out to change your organization.  Then, figure out how and where BI is necessary to enable that change.

[dataspace]

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.

[dataspace]

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!

[dataspace]

Not to Offend, But You Are Thinking All Wrong About BI (Probably)

What's the first step in building a data warehouse or a business intelligence system?  Defining the key performance indicators (KPIs), right?  Wrong!  KPIs are certainly great to know and can definitely apply when you're developing BI applications like management dashboards.  But, BI is NOT about management dashboards or data warehouses or query and reporting or QlikView or Business Objects...

Business intelligence is simply about capitalizing on data that was captured for other purposes.

I was struck by this thought over the Thanksgiving holiday when speaking to my brother in law.  He's an executive with an up-and-coming, private-equity-financed distributor.  One night, his CEO had an epiphany

We know what people buy but we don't know if what people buy is generally correlated with other things that they buy, or should buy.  If we knew this, we could encourage folks buying one thing to also purchase its natural accompaniment.

For those of us who have been in the BI business for long enough, this is a take on the classic 'beer and diapers' data mining example (click here for more on this BI 'fable').

This is certainly a use of BI, of capitalizing on data assets but it doesn't really work in the way that folks expect BI to work:

It doesn't really start with a definition of KPIs

While it may use a data mining tool, it doesn't use dashboards or query tools or other, common, reporting tools

It may use a data warehouse but it may, also, just use data assembled for a one-time analysis

In any case, when thinking about BI, the vast majority of companies need to stop thinking about BI.  BI is not the point.  Doing something extraordinary is the point and, if using data assets gets you to extraordinary, then BI is the mechanism.

[dataspace]

Got BI? Now Become Data Driven

Participate in enough BI groups and you'll see one question come up time and again: Why do so many BI systems fail?  A lot of time it's not failure in development but in implementation.  Let's face it, too often these systems get built but not used.  For years I've written on how a key to usage is making sure that your BI system enables some new business process.

Well, a recent client in New York has a great approach to ensuring that his new BI system gets used.  This senior manager has a set of subordinates reporting to him.  He's a very data-savvy guy and wants his folks to be data driven, rather than flying by the seats of their pants.

So, when his new BI system became available he sat down with his managers and required each of them to pick two charts that they would review with him at their monthly meetings.  Charts, of course, are built around key metrics and dimensions.  Thus, in order to optimize their performance, his folks must keep their eyes on these metrics.

With this approach, this manager is showing that he fully supports the BI system while pushing the cultural changes necessary to be data driven and make sure his organization gets the ROI it expects.

Do you believe in being data driven?  Do you believe in your BI system?  Prove it!  Don't passively hope that your folks will use your new BI toys.  Require them to make BI a key part of how work gets done.

Want to kick around some ideas?  Drop me a line at [email protected].

-- Ben

[dataspace]

Infobright

Saw a great presentation on Infobright, column-oriented database last night. It looks like an inexpensive, low maintenance way to speed up BI queries.  Their KnowledgeGrid concept seems like it could provide blazing performance - especially if you're smart about how you sort your data on the way in.

For years we at Dataspace have been saying that, rather than picking a corporate BI Standard, companies should pick standards for business-focused BI applications (e.g. Dashboarding, OLAP, Ad hoc query, online reports, GIS, etc.).  Interestingly, the Infobright speaker pushed the same concept for databases.  The point is that there isn't a job like, "Database."  Instead, there are jobs like high performance OLTP, BI and reporting, unstructured data, etc.  

It makes sense.  Think about automobiles.  You don't buy a generic, "Auto".  Instead, you buy a sedan, or a sportscar, or a station wagon, or a pickup truck, or a van, or an 18 wheeler...  Could you use a sedan instead of a pickup truck?  Sure, for some jobs.  Is it wise to buy a sedan if what you need is a pickup?  Probably not; After all, how many shovels full of compost do you really want to be carrying in the back seat & trunk of your Altima?

Anyhow, if you're having BI performance issues, this technology is definitely worth a look.  Want to kick it around, let's talk!

-- Ben ([email protected])