Big Data Not the Answer to Business Agility

IT organizations must challenge vendors on their claims that their Big Data and business intelligence solutions "automagically" create business agility.

The hype about agile business intelligence is getting out of hand. IT will probably suffer for it.

A recent, egregious example was an EMC ad for a webcast headlined "Why Big Data is the Answer to Business Agility." The text of the claim pulled back only slightly: "Find out why a unified approach to Big Data Analytics is the fastest way to business agility." The aim of the sales pitch was, of course, to sell EMC’s Greenplum database.

The claim is flat-out wrong. Big Data is not the answer to business agility. A business is fully agile if its key processes are fully agile, not if analytics allows the CEO to make optional, incremental improvements in agility.

Also, analytics applied to fundamentally un-agile processes typically doesn’t make them agile. In fact, analytics applied badly to un-agile processes like "waterfall" product development can lead to less agility, as a focus on using analytics to improve product quality instead of time-to-value can inhibit changes during the development process.

Let’s take a slightly altered hypothetical use case for Big Data analytics recently mentioned in a recent EMC briefing on Greenplum. In it, analytics is applied to two CEOs with the same car insurance. Careful search of one person’s personal information on the Web reveals that his car is rarely used, since he prefers the corporate jet. The other’s Facebook page reveals that he is a sports car fanatic and in several emails has mentioned warnings for speeding.

The reaction: the "safe" driver is rewarded with a cut of $500 in yearly premiums, and the "risky" driver is punished with an increase of $1,000. Sounds great, right? Clearly the insurance company is more agile, since by aggressively fine-tuning its customer-of-one pricing it can increase revenues while encouraging more responsible driving.

Not so fast. Business agility is about fast, fundamental change – preferably change that keeps pace with volatile customer wants and needs. Does the car insurance company really think that the CEO who gets a much bigger premium increase than his colleague’s premium decrease won’t notice that? Who is going to be more vocal about this, the CEO who is helped or the one who is hurt?

Is there an opportunity to reassess the frequency and size of premium changes, so they wouldn’t hit the annoyed CEO like a snowball in the face? What’s the company’s policy for getting feedback on its solutions via Web? Is the company just cherry-picking Big Data that will give it a bigger short-run profit at the expense of scathing tweets from customers propagated worldwide?

Why is the focus on incremental improvement of existing processes instead of constant, incremental process change driven by customer interaction, or even by “crowdsourcing” product development?

I would argue that the car insurance company in this case would see little if any increase in business agility by using Big Data analytics in this way. This type of use may even increase the probability that the company will react defensively to criticism and double down on its investments in present processes instead of investing in changes to improve its agility.

Hype Can Hurt You

I don’t mean to pick on EMC. A quick Google search reveals plenty of other vendors touting the ability of their solutions to promote agility. Unfortunately, the negative effects of expecting too much from this kind of hype, and then failing, fall more heavily on IT than on the vendors who push these claims.

It reminds me of the salesman I knew who, when told by the customer that the product wasn’t working as hoped, would say “Ah, that’s because you didn’t do XYZ, like our customer Company N over there. What you need is ABC, which also does PDQ. Sign here.” And the customer would sign, knowing that if they didn’t their CEO would look at Company N’s “success” and blame IT for the failure instead of the vendor. The resulting IT “doubling down on failure,” I assert, means that IT wastes more spending and the vendor makes more money.

The specific danger to the IT shops that implement Big Data analytics and expect business agility to arrive "automagically," is that (a) failure will mean wasted money at a time of cost stringency, and (b) failure will discredit the idea of business agility in the organization. While (a) is unfortunate, (b) is life-threatening because there are companies out there with almost fully agile new-product development. Those companies will eventually figure out how to spread this kind of agility to other parts of the organization. If and when they do, they will eat your lunch.

The Way to Business Agility Is: (Drumroll, Please) Business Agility

What role should business intelligence in general, and analytics in particular, play in your efforts to achieve IT and business agility? To understand this, you should cast aside the vendor hype and understand what it really takes to achieve business agility.

Business agility is not just about reacting to change, but anticipating it. It’s not just about new tools, but about new processes focused on handling change well. It’s not at all about efficiency, but all about effectiveness. It’s not just about a command-and-control strategy from on high, but about a pervasive company mindset.

In other words, you can’t have business agility if everyone and every tool is thinking and operating as if change isn’t the norm. Like a good performer reading sheet music, the agile business is always thinking a note ahead of the one being played.

What is the role of business intelligence in all this? Agile business must perform two mutually reinforcing tasks: supporting business agility and being agile itself.

The second of these tasks is, surprisingly, within reach of being accomplished. A recent Sloan Management Review article notes the rise of the "business analyst," whose process never mentions the word agile, but whose characteristics and culture could be lifted out of an agile development how-to-manual – rapid generation of incremental analytics, constant interaction with the end user that changes the design on-the-fly, emphasis on time-to-value and related metrics rather than formal "waterfall" processes with cost metrics.

Meanwhile, the IT shops busy using agile development practices to generate their own business intelligence upgrades are being deservedly criticized, not for lack of product quality or slow delivery, but rather for lack of attention to the needs of the business end user – in other words, for not being agile enough. A return to agile development fundamentals should be a straightforward fix for that.

That leaves the task of supporting business agility. In essence, this means that agile business intelligence should be aimed primarily at providing data that helps the business function or corporate end user act in an agile way, as part of an agile business process – always focusing on change, always in touch with the customer, often a step ahead rather than always reacting.

For example, the chief marketing officer should be thinking not only of where the market has been and is but also where it might be going, where it should be going, and how to bake the ability to meet possible upcoming needs into present solutions and services – and marketing processes. Analytics needs to tell the CMO the fine points of the customer-of-one’s present relationship for more rapid and effective reaction. Even more importantly, analytics should help reveal new possibilities for where the market might be going, business barriers to "crossing the chasm," and ways in which the new-product development process and marketing’s own processes may hinder the organizational ability to change to meet upcoming customer demands.

Thus, in order for the business to improve its agility in a major way, it needs to adopt agile processes and agile thinking in key areas. Truly agile business intelligence used to support business agility is a great help. However, despite what vendor hype is saying, it’s a tool, not a solution. The only long-term way to make major improvements in your company’s agility is to make major changes in your company’s mindset and supporting processes.

Caveat Vendor

It should be noted that while an agile business armed with agile business intelligence may be a fearsome competitor in the medium term, at present most of your competitors are pretty far from fully agile themselves. This is a good thing, as true business agility requires a significant and pervasive change in mindset across much of the organization. So in addition to aiming business intelligence in the correct direction, IT has the time and opportunity to keep the entire business agility effort from being deep-sixed forever.

What that means, specifically, is that IT should start demanding that vendors talk about truly agile business intelligence use cases. These use cases should be:

Forward-looking or what-if, focusing on possible upcoming shifts in customers’ markets, not those that are existing and well-known;

Process-changing, identifying ways that data flow and/or new product development should be able to change to meet prospective new market needs;

Customer interactive, involving not just examination of customer data but negotiation with the customer about the outcome of the business change.

Here’s a slightly altered real-world example: A zoo saw its revenues slowly decrease, as school trips that were a major source of revenues faltered in the face of state austerity budgets. It brought in a new business intelligence tool, and began the obvious process of identifying and better targeting key customers for greater revenue.

During the process, the business intelligence tool spit up an odd fact: The zoo’s ice cream stand shut down an hour early, to save wages and give employees a head start on cleaning up after the crowd. Luckily, the zoo didn’t stop there. It talked to key customers, and realized that most of them wanted ice cream at the end of the day when kids were hot and tired. So the zoo kept the ice cream stands open another hour, and saw their revenues in that area soar.

The zoo didn’t stop there. It used the initial success to justify a process in which key customers were frequently asked for feedback or ideas and new efforts could be pre-tested. It started to wonder whether there were trends in other parts of the market that could be used to attract new customers, like high-schoolers interested in the environment. It involved its employees and customers in a BI-driven process not only to adapt to changes in the markets, but also to identify possible new changes and opportunities and started to change that BI-driven process to take advantage of them.

In other words, the zoo used its business intelligence to take a big step toward business agility by getting everybody thinking about change. And, by the way, in the process of improving business agility it also made its business intelligence more agile. Profit results are beginning to follow.

The ancient Romans had an expression: caveat emptor, meaning "let the buyer beware." It has always been taken to mean, it’s the job of the IT buyer to see through vendor hype. In this case, IT should make it the vendor’s job to prove that its solutions can help create real business agility, not hype. If the vendor doesn’t … caveat vendor.

Wayne Kernochan is the president of Infostructure Associates, an affiliate of Valley View Ventures that aims to identify ways for businesses to leverage information for innovation and competitive advantage. Wayne has been an IT industry analyst for 22 years. During that time, he has focused on analytics, databases, development tools and middleware, and ways to measure their effectiveness, such as TCO, ROI, and agility measures. He has worked for respected firms such as Yankee Group, Aberdeen Group and Illuminata, and has helped craft marketing strategies based on competitive intelligence for vendors ranging from Progress Software to IBM.