The more decision support technology has matured, the more it has permeated the enterprise. The earliest systems, circa 1985, served limited numbers of users – primarily highly technical business analysts or line-of-business IT people. Back then, simply getting at the data was a chore; and once you got it, you needed strong technical skills to make the most of the scarce and difficult- to-use query tools. Thankfully, times have changed. Business intelligence (BI) can now be delivered with relative ease to large groups of similar users who don't necessarily have to be technically savvy to reap the benefits.

Even so, when deploying analytical applications to hundreds or thousands of users, you need to adjust your implementation strategy with regard to scope, design and access.

Let's look at the example of deploying BI to thousands of sales representatives. The goal is to give each sales rep a set of data to help them understand their customers better – their buying habits, their recent purchase history, their overall value to the enterprise, etc.

Scope

Although the pressure to customize the mart for each individual user will be strong, you won't be able to satisfy every requirement of every user. The core application should address the most common requirements or satisfy the largest number of users. You'll need to set the end- users' expectations regarding this early on. In mass deployment, the 80-20 rule (80 percent of the questions can be answered easily; the remaining 20 percent are very difficult, usually proprietary to the individual and take significant effort) must be enforced. If you can answer most of the questions in a timely, consistent and easily maintainable fashion, your user community will be thrilled. Don't get distracted by the off-the-wall, once-in-a-while, sometimes- I-use-it types of questions that will cause your downfall.

One way to accomplish this mind-set is to keep the group of users focused on their common objectives. Often, large groups of people who perform similar tasks for the organization (e.g., our sales reps) are managed using very tangible objectives and measures. Once the group understands that the purpose of application is to help them reach their common objectives, buy in will be stronger and they'll be less inclined to take it personally if you have to nix one of their pet requirements that few others share. What's more, if you cave in and green light an esoteric requirement for one user, the others will probably demand the same treatment.

Design

Once the requirements are boiled down, you'll need to ensure that the database design is equally straightforward. Whether you are creating a relational mart (star schema) or multidimensional one (cube), you should fight the urge toward complexity and create a design that contains just the necessities for the application. A straightforward and easy design will simplify your life and deployment issues significantly. It can be tempting to include extraneous data – just in case. However, if you make the dimensions overly complicated – the facts a laundry list of every conceivable measurement, calculation or derivation – then the cubes will explode in size and deployment can become a massive effort. Just delivering these overly complicated stars or cubes on time becomes a nightmare, and you end up with thousands of dissatisfied users.

Access

For large user groups, it follows that since the requirements are relatively predictable and the database design is relatively modest, many of the queries are also predictable and lend themselves to being "canned." So, BI for mass audiences frequently entails menus of predefined queries and more query programming. This adds a burden to the developer; but, once created, the maintenance becomes manageable and stable. This does not eliminate the users' ability to create their own sets of queries or to drill up, down, around and across the data.

Should a more complicated need arise for a substantial segment of your user community, you may have to create a specialized mart for them. Even so, it's not nearly as difficult as trying to do this specialized treatment on a mass-consumption basis. Fortunately, these highly specialized marts are the exception.

Distributing business intelligence to large user groups requires a different mind-set from the traditional one. It requires simplification, identification of the core necessities and an understanding of how much can be done with less data and less complications.

The study of an employee's objectives is a great way to get the ball rolling. It focuses the requirements on these necessities – not the "nice to haves" – for the masses. It forces the users to sort out the wheat from the chaff and to resolve the contentious issue of what is absolutely needed within the analytical application. Finally, it eases the burden on the IT resources who are responsible for installing, updating and maintaining this application to the thousands of users.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access