26

Feb

Right-Sizing Business Intelligence

A common phrase often heard in the United States when getting something to eat at a fast-food restaurant is: “Would you like to super-size that?” The size of the main component of the meal, the sandwich, does not change, but the size of the extras (soda, fries/chips) is increased, adding cost to the meal, increasing the time to eat and, for many people, adding additional weight to their bodies.

Right-Sizing Business Intelligence

Contrast the supersize group with those who have the opposite relationship with food and, due to fear of weight gain, either do not eat or do not eat enough. Both groups have the same root problem: food. How they deal with that problem is what differentiates. Often the people know what they do – whether supersizing or under-sizing – is not healthy, but are unable to stop.

But what does this have to do with Business Intelligence? Those who want promote BI within an organisation are often susceptible to suggestions of additional features and capabilities – in essence, too often a BI project ends up getting supersized and as a result, costs go up, implementation time goes up and you end up with BI bloat; cool features and capabilities that add cost but provide little (and sometimes no) business value.

On the other hand, those who approve BI expenditures and sometimes those who would benefit from the deployment of a BI solution, are often starved for BI. They want to have a lean, effective organisation and so do not want to invest in the cost and effort of a BI programme. They have heard stories of the benefits of BI but either don’t feel it is good for them or they cannot overcome their restrictive diet in terms of such investments.

Neither situation will lead to the best BI solution for an organisation. One option will lead to benefit but may lead to high scrutiny of future expenditures due to the high cost, whereas the other has little or no benefit but also no cost scrutiny. Unfortunately, it is difficult in most cases to quantify the cost of not having information when that information has never been available. 

While the broad examples given above in regard to how not to size your BI programme are extreme, they are not the only factors that result in wrong-sized BI. Rather than one of the extremes, it is much more common to see a BI implementation that does provide some benefit but either that benefit comes at too high a cost or the company is not maximising the benefit they can receive from their BI investment. Let’s look at some of the factors that lead to wrong-sized BI. 

This is not a comprehensive list but rather some of the most common factors I have found working with many companies of different sizes over the years.

 

Common Factors in Wrong-Sized BI

As I discuss these factors, keep in mind that each factor is not mutually exclusive. Many organisations have multiple factors influencing how they deploy BI. Companies that have taken very careful steps in their BI deployment often have some influence from one or more of the factors listed below. Fortunately, by recognising those factors, they can mitigate and plan accordingly.

The Fire Fighter. One of the most common factors for having wrong-sized BI is that BI is used as a fire-fighting tool rather than as a strategic tool. The need to fight a fire is often what motivates a company to invest in BI. Too often, however, organisations never get out of fire-fighting mode. What ensues is a competing list of demands for reports, dashboards, analysis, etc. and often those who are loudest or have the closest relationship with the CEO/CFO, etc. are the ones who get priority in receiving BI.

There is some merit to this method as a contributor to a long-term plan but when it is on its own, it does generate benefit, but perhaps not as great as could have been recognised. The desire of different groups to have BI should play a factor in planning a BI strategy as forcing BI on a group that does not want it can lead to poor results (lack of cooperation, time commitment, adoption, etc.) so those who want BI should be given preference. Just make sure the outcomes of the competing demands are weighed objectively.

Planning. It is common for a BI implementation to be designed with a limited scope, often just one or two projects. There may be a recognised need for BI across an organisation but budget only for a limited number of projects. Without a long-term plan on rolling out BI, the implementation can meander through the business landscape. Just like a river, without a plan the BI deployment will take the path of least resistance. Each project will provide benefit, but not great as it could be and often with duplication of effort.

Budget. This was alluded to in the introduction with either super-sized BI or under-sized BI. Budget cuts both ways. The budget constriction can be easily overcome through proper planning so that budget is used optimally. Without proper planning, often what happens with a small budget is something is done “on the cheap” and is not designed to scale or grow with the business, leading to rework and extra cost. On the other hand, with too much budget, there is likewise no planning and every possible feature is included and time and cost requirements grow to fit the budget. I have seen BI Ferraris built when all that was needed was a Toyota.

The Impressionable Executive. BI companies love impressionable executives. They can be sold large projects by showing pretty screens and talking of benefit. They often don’t spend the time to make sure they are right-sizing but see a need and decide “Product X” meets the need and a directive is given, “We are going to do BI with Product X and this is what we are going to build.”  If the executive takes the time to properly evaluate options, this becomes a positive but if not, what is built depends on their perception of need. This can result in either super-sized or simple-sized BI. 

The Weekend Warrior. We probably all know people who are sedentary during the week but suddenly active on the occasional weekend. Unfortunately for that group, they also have a higher than average rate of heart-attacks due to not being fully prepared for their weekend activities. The same goes for BI.

I have sat with companies who wanted to go from no BI to enterprise-wide BI encompassing Big Data, Master Data Management and any other hot topic all in a very short time frame. They do not have the infrastructure or experience in place to make it work and as a result experience problems with making everything work as it should.

Impatience. What is wrong with wanting something now? To properly implement BI it can take time and planning and when people are impatient, especially key decision makers, it can derail the proper implementation of BI and turn to a less-planned-more-fire-fighting deployment.

This can lead to taking shortcuts such as not building a proper warehouse, failure to consider or measure data quality and so forth. Shortcuts can lead to inaccurate information delivered from BI leading to a mistrust of BI both now as well as in the future.

The Vendor. I almost feel guilty putting this here as I am a vendor and I do not see myself as part of the problem.  However, the fact remains that the vendor is often part of the wrong-size problem.  It may be due to improper planning on their part, them trying to get as big a project as possible (or conversely, trying to be as inexpensive as possible to get the contract); perhaps they have seen grand solutions and envision that as the solution for everyone.  Whatever the reason, the vendor is often part of the problem.

Here I make a differentiation. I feel there is a difference between a vendor and a partner. A partner works with the client to know their business and their needs and will sometimes proactively make suggestions on features and capabilities. A vendor will also occasionally make suggestions on features and capabilities. What is the difference?

A partner is someone who takes a long-term view of the relationship and is not afraid to recommend against work, whereas a vendor is nearly always after more work.  When presented with a situation, a partner may indicate the idea is good but that it may be better to delay some work due to the relative benefit derived from that work. A partner is constantly working to help you get the most from your deployment rather than working to take the most money from your budget.

As mentioned earlier, these are just some of the more common factors I have seen that lead to a wrong-sized BI solution, and this is not intended as a comprehensive list. 

Next I’d like to discuss the drivers which lead to a right-sized BI solution.

 

Right-Sized BI

When I speak of right-sized BI, I incorporate more than just the size and scope of the BI deployment; it incorporates the set of BI tools, the data warehouse and the user experience. Right-sizing BI is simply BI done right; the right information to the right people at the right time and delivered in the right manner. 

With the above criteria in mind, what are factors that go into right-sizing your BI solution? Most of these factors can be addressed through the Who, What, How, Where and When questions.

How many users will be using the BI solution? Not knowing, at least at a ballpark level, this number can lead to a wrong-sized solution. It often leads to either BI bloat (too much for such a small audience) or barebones BI (not enough power and capabilities for the users). Having an answer to the question does not solve the problem though as there are several subsidiary questions needed to properly size your BI solution. An example of some of the subsidiary questions are:

  • What types of users do you have? (Static report users, analysts, etc.)
  • How will they interact with the system? (i.e. interactive data exploration vs. static report consumption.)
  • Where will the content be delivered? (Web, email, mobile, portal, etc.)
  • Is there a minimum response time?
  • How many users will be accessing the system concurrently?
  • Who are the key and/or influential users? (Their acceptance is very helpful in attaining overall acceptance.)

What are the goals of the users in implementing BI? Why are those goals important to the business? 

What is their tolerance for error? Some groups, such as finance, generally have zero tolerance for error. Others may be willing to tolerate small inaccuracies in the numbers. Data Quality is an issue but depending on the tolerance for error, may be delayed to some degree.

What is the group’s willingness to work with BI? Are they excited or sceptical? Do they view it as a help or a threat?

What tools will be used? Is training required or are users already familiar with the tool(s)?

What infrastructure is in place and what is required? Infrastructure includes two components, physical and human. Do they have the servers and hardware necessary? Do they have the people and processes in place to support the solution?

Who will be doing the development? Will it be done in-house by resident IT staff or will it be outsourced? 

And one of the most important questions for a right-sized BI environment – Do they have a BI Roadmap which outlines short-term vs. long-term needs and provides a guideline for all BI related activities?

With answers to the above questions, you can intelligently plan your BI environment. Will you get everything perfect? Probably not. Often reality and estimation will differ but usually they are fairly close meaning that your solution should be pretty close to actual needs.

In summary, Business Intelligence (or Business Analytics if you prefer), can offer organisations some wonderful benefits when it is implemented properly. Unfortunately, there are cases where BI is super-sized, simple-sized or simply misaligned. Bad BI can poison the well for future BI engagements and other similar projects such as Big Data or Predictive Analytics.

The right BI for your organisation may be simple, complex or somewhere in the middle. What is most important is not the size of the need, but getting the proper solution to meet that need and will grow as your needs grow.

Go.  Size.  Deploy.  Satisfy.  Smile.

Posted by: Mark Worthen, Senior Consultant, Enterprise Applications | 26 February 2013

Tags: Business Intelligence, BI


Top Rated Posts

Blog archive

Stay up to date with all insights from the Intergen blog