Business intelligence (BI) continues to be front and center on the agendas of businesses of all sizes and in all industries and geographies. Ever-increasing data volumes, complexity of global operations, and demanding regulatory reporting requirements are just some of the reasons. But also, more and more businesses realize that BI is not just a tool but rather a key corporate asset that they can use to survive, compete, and succeed in an otherwise increasingly commoditized global economy.

However, we consistently find that many BI initiatives fail and even more are less than successful. Well, maybe we can help. Even if just a little bit. Come to our interactive one-day BI Strategy Workshop to learn the fundamentals and best practices for building effective and efficient BI platforms and applications. The Workshop will also include hands-on exercises with tangible deliverables that you can take back to your teams to help you jump-start or adjust the course of your BI initiatives.

Why attend? Because hundreds of organizations have already benefited from reading Forrester research and working with Forrester analysts on the topics covered in this Workshop. I plan to present Forrester’s most recent research on:

• Why are BI initiatives at the top of everyone's agenda, while many of them still fail?
• What are some of the best practices necessary to achieve successful BI implementations?
• What are some of the next-generation BI technologies and trends that you can't overlook, such as Agile BI and self-service BI?
• How do you assess your BI maturity so that you can get a solid starting point on the way to your BI vision and target BI state?
• How do you assess whether your organization has a solid BI strategy?

By Boris Evelson

We all know that the war of fighting the proliferation of spreadsheets (as BI or as any other applications) in enterprises has been fought and lost. Gone are the days when BI and performance management vendors web sites had “let us come in and help you get rid of your spreadsheets” message in big bold letters on front pages. In my personal experience – implementing hundreds of BI platforms and solutions – the more BI apps you deliver, the more spreadsheets you end up with. Rolling out a BI application often just means an easier way for someone to access and export data to a spreadsheet. Even though some of the in memory analytics tools are beginning to chip away at the main reasons why spreadsheets in BI are so ubiquitous  (self service BI with no modeling or analysis constraints, and little to no reliance on IT), the spreadsheets for BI are here to stay for a long, long, long time.

With that in mind, let me offer a few best practices for controlling and managing (not getting rid of !) spreadsheets as a BI tool:

1. Create a spreadsheet governance policy. Make it flexible – if it’s not, people will fight it. Here are a few examples of such policies:
   • - Spreadsheets can be used for reporting and analysis that support processes that do not go beyond individuals or small work groups vs. cross functional, cross enterprise processes  
   • - Spreadsheets can be used for reporting and analysis that are not part of mission critical processes

I recently asked my Twitter followers if they had good examples of queries, business questions that SQL can't do. It turns out a better question is "what SQL can't do easily", so I thought I'd share with everyone what I heard and found. Seth Grimes was the first one to provide an excellent answer with some informative examples - thank you, Seth! I also found very useful articles on typical SQL challenges such as avoiding multiple duplicate sets in your SQL results, and why NULLs create tons of headaches for SQL coders.

There's also a typical SQL challenge with ragged, sparse, unbalanced hierarchies and dimensions. For example, a retail store, a wholesaler or a distributor with thousands of products, and a manufacturer with thousands of parts often struggle with dissimilar data. A pencil in an office supply store does not have the same descriptive attributes (lead type, for example) as a calculator (scientific, financial, etc.) or an office chair (number of wheels, etc.). Or a tire in a car manufacturing supply chain does not have any common descriptive elements (rubber grade, width-to-height ratio) with gear boxes (automatic vs. manual, 4 or 5 speed, gear-to-gear ratios, etc). When looking for correlation between two entities (for example, what is a potential product quality issue that is making my sales go down?) in cases with disparate, dissimilar products (as in retail products or manufacturing parts), the same SQL query cannot work for all products or parts. One would be forced to write multiple SQL queries for each product or part type to find such a sales/quality relationship.

I know many of you already know my position on this, but I thought I'd get it out in the open and challenge all of you with a controversial discussion. In my definition – and believe it, I am fighting and defending it every day – analytics has always been, and will always be, part of BI. What many of the vendors and analysts describe as "the new age of analytics" I built at Citibank in the early '80s and then built in about 50+ enterprises in the '90s at PwC. I think the effort of trying to differentiate analytics from BI is a vendor-invented hype, since many BI vendors are running out of ways to differentiate themselves (and incorrectly so: see the next paragraph, and many other next-gen BI trends). I also disagree with the “old BI = bad”, “new analytics = good” premise that I see in many analysts' papers. You and I know that you can’t build analytics (OLAP, advanced analytics, etc.) without basic ETL, DW, MDM, etc. So nothing’s really changed as far as I am concerned: we are still fighting the same battles – silos, data quality, etc.

By Boris Evelson

I get this request almost on a weekly basis: "Boris, my BI vendor is offering me the following discount, is it a good deal or not?" The first question is what are you comparing it to? It reminds me of an old joke: Q. How much is 5 times 5. A. Depends on whether you're buying or selling. Many of the vendors do not publish or reveal list prices, or even if they do, they are revealed only under NDA to each client, so good luck comparing what the vendor told you and what they told another client. So what ARE you comparing it to?

Another problem, IMHO, is that many of the vendors muddy the waters with CPU based prices, clock speed based prices, etc. Yes, CPU, server, core based prices make sense if you are growing and want to lock in a good deal now, before you grow and expand. But in the end, you, the buyer, still need to figure out how much the software costs you per seat, per user.  So with both of these challenges in mind I looked through my 20+ years of notes on BI contracts and per seat license costs and came up with the following. Notice, an interesting X-factor (obviously, I fixed the numbers a bit to have it look nicely like that):

• BI output consumer, no interactivity $300
• BI output consumer, with light (sort, filter, rank) interactivity $600 (or 2x)
• BI output consumer with heavy interactivity (interactive dashboards, search, etc.) $1,200 (or 4x)
• Power users (generate content) $2,400 (or 8x)
• Developers (includes ETL, scripting, scheduling, etc.) $3,600 (12x)
• Administrators $10,800 (36x)
• Advanced analytics (data mining, predictive modeling) $10,000 and up.