I know, I know, this is what analysts do. But I personally would never want to get involved in doing a BI market size – it’s open game for serious critique. Here are some of the reasons, but the main one is a good old “garbage in garbage out.” I am not aware of any BI market size study that took into account the following questions:
What portion of the DBMS market (DW, DBMS OLAP) do you attribute to BI?
What portion of the BPM market (BAM, process dashboards, etc.) do you attribute to BI?
What portion of the ERP market (with built-in BI apps, such as Lawson, Infor, etc.) do you attribute to BI?
What portion of the portal market (SharePoint is the best example) do you attribute to BI?
What portion of the search market (Endeca, Google Analytics, etc.) do you attribute to BI?
What is the market size of custom developed BI applications?
What is the market size of self built BI apps using Excel, Access, etc?
On the other side, what is the % of licenses sold that are shelfware and should not be counted?
Plus many more unknowns. But, if someone indeed did do such a rough estimate, my bet is that the actual BI market size is probably 3x to 4x larger than any current estimate.
BI projects are never short, and, alas, many of them don't end since a fast-paced business environment often introduces new requirements, enhancements, and updates before you're even done with your first implementation. Therefore, we typically recommend doing sufficient due diligence upfront when selecting a BI services provider — as you may be stuck with them for a long time. We recommend the following key steps in your selection process:
Map BI project requirements to potential providers. Firms should use Forrester's "BI Services Provider Short-Listing Tool" to create a shortlist of potential providers. With the tool you can input details about your geographic scope, technology needs, and the type of third-party support you need (i.e., consulting versus implementation versus hosting/outsourcing). The tool then outputs a list of potential providers that meet the criteria. For each potential fit, the tool also generates a provider profile summary that offers key details around practice size, characteristics, and areas of expertise.
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?
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:
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
Whoever said BI market is commoditizing, consolidating and getting very mature? Nothing can be farther from the truth. On the buy side, Forrester still sees tons of less-than-successful BI environments, applications and implementations as demonstrated by Forrester's recent BI Maturity survey. On the vendor/sell side, Forrester also sees a flurry of activity from the startups, small vendors and large, leading BI vendors constantly leapfrogging each other with every major and minor release.
In terms of the amount of BI activity that Forrester sees from our clients (from inquiries, advisories and consulting) there’s no question that SAP BusinessObjects and IBM Cognos continue to dominate client interest. Over the past couple of years Microsoft has typically taken the third place, SAS fourth place and Oracle the distant fifth. But ever since Siebel and Hyperion acquisitions, the landscape has been changing, and we now often see Oracle jumping into third place, sometimes leapfrogging even Microsoft in the levels of monthly interest from Forrester clients.
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.
IBM announced its intentions to acquire Coremetrics, a leading Web analytics vendor, as BI megavendors continue to round out their BI portfolios (the other leading vendor in the space, Omniture, was recently picked up by Adobe). Good move, IBM. Web analytics can't really continue to exist in a silo. In order to get truly complete 360-degree view of customers, prospects and products, one needs to combine Web analytics data with ERP, CRM, HR, Financials and other transactional and analytical data sets. Currently, there are no off-the-shelf solutions that do that - it's pretty much the realm of customized offerings and systems integration. If IBM can indeed plug Web analytics into its data integration, data warehouse and BI products and solutions, it'd be quite a differentiated offering. Other large BI vendors, like Microsoft, Oracle and SAP will probably pick up one of the remaining Web analytics vendors Nedstat, Unica and Webtrends sometime soon.
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.
Defining a successful BI strategy is a lot more than gathering requirements and selecting a vendor. While it’s been a subject of many books, I know few of you have time to read them, so here’s a short version.
First defining what BI is and what it is not. Is it just reporting, analytics and dashboards? Or does it involve ETL, DW, portal, MDM, etc., as well?
If the former, you then need to define linkages, dependencies, overlaps and integration with all of the latter (including - very importantly - integration and coordination with the higher level enterprise architecture efforts). If latter, it’s a whole different subject. You then really do need to read a few thick books.
Ensure senior business executive commitment and top down mandate. If you cannot get that, do not proceed until you do. Two ways to “sell BI” to them (even though that’s not a good position to be in):
Educate them on BI ROI. Here's where you'd build a high level BI business case.