Anyway, that being said, these terms are no laughing matter for those faced with the real challenge of making simple the complexity of data available to companies today.  From my experience I’d say that most companies – even those single location small companies, have a multitude of information stored in a multitude of systems.  The “systems” containing this data may be an individual PC, a company ERP system on a server, a sales (CRM) system (maybe on a multitude of salespersons laptops) – each its own “silo”. 

There are many stories of failed BI implementations.  Why?  I would posit that users trust their data and information, but not necessarily that coming from say, the IT department.  They know where “their” data is coming from, how it was collected, and it’s meaning – because its “theirs”!  Whether it presents a complete picture, or is applicable in all instances is totally irrelevant – just ask that branch manager, or department manager … or whoever has the data.

That being said, I’d say that perhaps key to getting the most value from the data you have available is getting the buy-in of the end-users of the data in regard to data source and reliability.  If a data source is to be used, do the end-users “trust” the data?  No trust – Don’t use it!  An interesting post suggesting 3 causes of failure for BI implementations is available here – an interesting read.

This scenario is perfect for the creation of a “dashboard” presentation. However, very much like the “business intelligence” applications that are available, creating the dashboard can be cost prohibitive. What a shame!

In my opinion the well run small business, be they multi-location or single-location, has perhaps more to gain from such information availability and presentation than does the larger company. There is more at stake for the smaller company.

I find myself constantly on the lookout for reasonably priced software (under $1000 – preferably in the $500-600 range) which can be used to create such a reporting application. For the small businesses that I deal with, spending $25,000 or so for a BI/Dashboard application just doesn’t make it. What I have found so far as a tool to use to create the application I’d like to provide is very expensive, cumbersome to use, and requires extensive programming beyond my particular skill set.

Where’s my reasonably priced tool out there? I’ll be searching, but if you have pointers please respond to this blog and help all of us out.

 I certainly don’t pretend to have the “answer”.  In fact, I believe, there really is no one answer for any organization, and the answers and methods used to evaluate “value” will vary from project to project.  My experience would show that sometimes the applications that prove of greatest value weren’t on anybodys radar, but were championed by someone within the organization with enough “clout” to say simply “do it!”

To set the record straight, I’m not saying here to “build it and they will come”, but I am saying that with proper consciousness to the business processes it is possible to hit a home run with an application that if analyzed early on with a “cost / benefit” analysis would fail miserably.  In following posts I intend to bring forth some of the perhaps “odd” methods I’ve been familiar with.

In the mean time, If you have anything you think should be addressed about application value — please post.

In examining the question of how BI “fits” for a small company, I found myself asking the question “What makes BI – BI?  How does it differ from reporting which may include graphs and really neat visual presentations similar in many ways to those of BI applications?”  In researching this topic I found an excellent white paper entitled “Reporting vs. Business Intelligence“, written by Jim Hammond, President of RainMaker Software, Inc. 

While the focus of this paper is BI as it applies to law firm needs and RainMaker’s software it provides insight into some of the key differences between reporting and BI which apply across all business applications.

Personally, I look at BI as being reporting on steroids.  Mr. Hammond refers to BI as an “…ad-hoc way of easily selecting “exactly what you want” in the “exact format you want to see it in” type of reporting tool.  I see reporting as presentation of the “details”, and BI as presentation of the “big picture”. 

Enter the “Data Warehouse”.  Mr. Hammond refers to the data warehouse as built “…for nothing more than precise, high-speed, data analysis…”  While reporting generally is against a transactional database, the BI application runs against the “data warehouse” which generally will have summary information not readily available when reporting against the transactional system – hence the speed of data availability.

There are constant references to reporting against the transactional system as being “hard coded”, thus being limited by the design choices of the application developer.  However, there is much consideration that needs to be made relative to the creation of the “data warehouse”.  Will not the BI application require design of said “data warehouse”?  To the best of my knowledge one doesn’t go to their friendly retailer and buy a “data warehouse” — perhaps an opportunity for new product?

As for small business situations, my experience is that in most there is no user who has the knowledge to access the “ad-hoc” capabilities of the BI system and produce meaningful, useful and accurate analysis data.  The idea of “slice and dice” of data has much appeal, but my experience to date has been that users still consistently turned to the IT staff for their “slicing and dicing”, and the IT personnel ended up creating the equivalent of “canned reports” so that the users could just “point and click”.  In this case what really resulted was reporting against the “data warehouse” information rather than the transactional database. 

There is a cost associated with the creation of the “data warehouse” which can be prohibitive for the small business.  The return on investment, however, can be significant.  Getting into BI should not be taken lightly, as behind the “glitz” of presentation, its still really all about the data integrity driving the presentation – for any BI project to succeed one requires good data.

I would posit that the place to start that is most effective is with clearly defining the expectations for the output of the application.  How is the output going to be used?  Viewed?  Printed?  Web or client?  Specifically, what are the data elements that are needed to form the output?  What about output sequencing – what are the requirements?  Any filtering of data required? 

My starting point of choice is with the output, as I have found that once the expectations for output are clearly defined everything else around what data and how best to get it will fall into place. 

My most recent experience with this phenomonon was in the form of a request something like “Can you add (various data pieces) to our program?”  It has literally been years since I’d been into the program in question, yet I had a nagging feeling that the “pieces” of data in question should be available.  The “real” question became “What do you want to do with these pieces of data if they are made available?”.  The answer came in the form of a spreadsheet layout which would form the basis of about a half dozen reports — this was a very clear communication of the desired program output. 

Once having this, further investigation indicated that there needed to be no changes to the existing database tables or various data entry screens controlling the data.  What became clear was that bottom line this required output in a more useable format than currently available, and since this application was developed in the late 80′s newer technology could be used to access the data and format output as desired.

 This is a case where the output requirements defined the input!  Since the required input exists, it becomes strictly a reporting project, although a reasonably meaty one.