Conversations about analytics tend to get muddled because the word describes everything from a simple SQL query to climate forecasting. There are several different ways to classify analytic methods, but in this post I propose a taxonomy of analytics based on how the results are used.
Before we can define enterprise best practices for analytics, we need to understand how they add value to the organization. One should not lump all analytics together because, as I will show, the generic analytic applications have fundamentally different requirements for people, processes and tooling.
There are four generic analytic applications:
- Strategic Analytics
- Managerial Analytics
- Operational Analytics
- Customer-Enabling Analytics
In today’s post, I’ll address Strategic Analytics; the rest I’ll cover in subsequent posts.
Strategic Analytics directly address the needs of the C-suite. This includes answering non-repeatable questions, performing root-cause analysis and supporting make-or-break decisions (among other things). Some examples:
- “How will Hurricane Sandy impact our branch banks?”
- “Why does our top-selling SUV turn over so often?”
- “How will a merger with XYZ Co. impact our business?”
Strategic issues are inherently not repeatable and fall outside of existing policy; otherwise the issue would be delegated. Issues are often tinged with a sense of urgency, and a need for maximum credibility; when a strategic decision must be taken, time is of the essence, and the numbers must add up. Answers to strategic questions frequently require data that is not readily accessible and may be outside of the organization.
Conventional business intelligence systems do not address the needs of Strategic Analytics, due to the ad hoc and sui generis nature of the questions and supporting data requirements. This does not mean that such systems add no value to the organization; in practice, the enterprise BI system may be the first place an analyst will go to seek an answer. But no matter how good the enterprise BI system is, it will never be sufficiently complete to provide all of the answers needed by the C-suite.
The analyst is key to the success of Strategic Analytics. This type of work tends to attract the best and most capable analysts, who are able to work rapidly and accurately under pressure. Backgrounds tend to be eclectic: an insurance company I’ve worked with, for example, has a strategic analysis team that includes an anthropologist, an economist, an epidemiologist and graduate of the local community college who worked her way up in the Claims Department.
Successful strategic analysts develop domain, business and organizational expertise that lends credibility to their work. Above all, the strategic analyst takes a skeptical approach to the data, and demonstrates the necessary drive and initiative to get answers. This often means doing hard stuff, such as working with programming tools and granular data to get to the bottom of a problem.
More often than not, the most important contribution of the IT organization to Strategic Analytics is to stay out of the way. Conventional IT production standards are a bug, not a feature, in this kind of work, where the sandbox environment is the production environment. Smart IT organizations recognize this, and allow the strategic analysts some latitude in how they organize and manage data. Dumb IT organizations try to force the strategic analysis team into a “Production” framework. This simply inhibits agility, and encourages top executives to outsource strategic issues to outside consultants.
Analytic tooling tends to reflect the diverse backgrounds of the analytics, and can be all over the map. Strategic analysts use SAS, R, Stata, Statsoft, or whatever to do the work, and drop the results into Powerpoint. One of the best strategy analysts I’ve ever worked with used nothing other than SQL and Excel. Since strategic analysis teams tend to be small, there is little value in demanding use of a single tool set; moreover, most strategic analysts want to use the best tool for the job, and prefer to use niche tools that are optimized for a single problem.
The most important common requirement is the capability to rapidly ingest and organize data from any source and in any format. For many organizations, this has historically meant using SAS. (A surprisingly large number of analytic teams use SAS to ingest and organize the data, but perform the actual analysis using other tools). Growing data volumes, however, pose a performance challenge for the conventional SAS architecture, so analytic teams increasingly look to data warehouse appliances like IBM Netezza, to Hadoop, or a combination of the two.
In the next post, I’ll cover Managerial Analytics, which includes analytics designed to monitor and optimize the performance of programs and products.
3 thoughts on “Analytic Applications (Part One)”