Ask yourself the following questions to determine what your internal support issues are:

As shown in Figure 11-2, one size does not fit all for end-user support and product support. It is not a bad idea to sketch a pyramid (or dodecahedron, or whatever) of your users and think through how and where support will occur. What levels of support will they require, and where will they go?

Figure 11-2. End-user support by user profile.

As you create your internal support structure and roadmap for support, it is beneficial to establish a service level agreement with users and make it clear that internal procedures and policies are to be followed.

If you are a strong proponent of product education as I am, you will establish a schedule of education events, including a requalification process when new releases or versions are implemented.

Ask yourself the following questions to determine what your vendor support issues are:

Take the segments listed above, and add any that you feel would make your BI environment a stronger and more viable one. Using the lists above, let's expand upon their impact on a BI environment. Keep in mind your own personal life. What if you purchased something for $500 or more? Would it bother you to receive only a fraction of its value and usage because you encountered a shoddy or non-existent support structure?

Have you ever purchased software for personal use only to find it was hard to install, configure, and use? When you called the toll-free telephone number, were you put off, put on hold, or given a terse, erroneous reply?

This section looks at those questions from above in greater detail.

This is not the scapegoat for the project; this is the individual who represents the corporate view for the return we expect. This person will ensure that our efforts are articulated in business value and will arbitrate should any internal difficulties arise.

Without this person, we will wallow in small pockets of interest and selfishness. Promotion of interdepartmental and higher efforts for BI simply will not happen. One significant result this individual will deliver is the ability to excite others at the executive level and foster cooperative growth.

Greatest impact: Internal advocate with some “clout.”

Someone has to be the scapegoat of sorts. The project leader is the one who will stand up and say, “I will own this, and I will tell you if we are succeeding or failing.” This person is responsible for ensuring that all elements and activities agreed to for delivering the project are in place and that milestones are met. He should be the first one to stand up and say, “This will not work because we have no resource committed for the action required.”

Someone also must be responsible for reporting the ongoing success (or failure) that we are experiencing. The project leader should hold periodic meetings with users and determine how well they are doing with their new BI tools and activities. We should never be surprised to find that our end users are very unhappy with the choices we have made.

Greatest impact: A view from the trenches and ongoing, realistic assessment with accountability.

Someone has to establish a legacy of familiarity and connectivity to our vendors. Too many “Severity 1” support issues are erroneous because the customer simply doesn't know enough about a product, and a minor situation escalates to a major crisis.

The vendor should be made to understand that this individual or set of individuals must be involved in all facets of the vendors contact with the customer. They are the ones who help weed out the bogus problems from the valid ones and are held accountable for keeping the users and others from “crying wolf” regarding product support and issues.

This individual need not be a technician but should have an understanding of how the products are being used, deployed, and exercised in the enterprise's environment.

Greatest impact: An enterprise-oriented and business-oriented level to deal with vendor issues versus haphazard and erroneous calls for help.

The necessity for these functions should be self-explanatory. However, one key role that must be addressed is the need to assign permanent resources to the BI tools and associated databases. If we discover that dramatic changes in our data would vastly improve our end-user productivity, there must be a support person intimately familiar with the supporting data and how to implement these changes. This should be part of that person's job description and evaluation, not just on a per-call basis.

Sometimes, the technical setup for tools can be very tricky. Today, there is a massive rush to deliver thin-client access to query and reporting functions. The associated complexity of the tools, the data, connectivity, server performance, and more can provide a huge challenge. After technicians have plodded through the many pitfalls once, the same people should either be involved in rolling out other implementations of the same nature or document them so others may learn.

Many tools will have unique characteristics and quirks that, once encountered and overcome, are trivial when handled by experienced technicians. I recently set up a router in my home office as a personal project. I needed to set up a personal network, and I had never done this. After many hours (and aspirin), I finally got it set up. I have taken copious notes and filed them away where I can refer to them again. Now that I know what I am doing, it's easy. My hindsight is 20/20.

Constantly covering the same ground, uncovering the same problems, dealing with the same issues over and over should motivate you to not want the cycle to continue. One “old saw” comes to mind. It's the one about the guy who goes to the doctor and says, “Hey Doc! Every time I do this, it hurts!” And the doctor says, “Well dummy, don't do that!”

Greatest impact: Success or failure…period.

An internal product specialist can be an invaluable asset. Where is that Information Center when we need it? Who is going to understand enough about the products to determine whether new releases or upgrades are germane to our BI environment? Users will always want the latest and greatest features and functions. IT will always want to walk the fine line of keeping things as stable as possible and being “officially” supported.

Is there a set of functions or features that we simply have to have? If so, do we have a test environment or set of users with an adequate fall-back plan? If we cannot assign a full-time product maven, then we need to assign this role to those who fall into the top user category and have them provide a collective view and justification for upgrades and more.

Greatest impact: Delivering a realistic, unbiased assessment to justify or defer new releases and changes. This person would work closely with the internal vendor liaison or function in both roles if a liaison is not assigned.

This is somewhat related to the support role just covered, except that this person would be responsible for delivering results within a department or functional area. He is almost a walking data mart. His usage of the tool would be most adept for the features and functions that deliver the results required in his domain. He is often an individual who works with some of the more unique characteristics of a tool in his quest to satisfy some very specific analyses.

There may be many areas within the tool never touched by this individual, because the functions have no relevance to his needs. However, this individual may also be the one who “pushes the envelope” because he may have to try every option and every function to get the results he needs. If anyone is going to make or break the project within his area, it will be this person.

Greatest impact: Delivering the real applications and validating the ability (or inability) of the tools to deliver.

We would probably all agree that osmosis for skills transfer of any BI tool is going to occur. I am constantly amazed at how much money is spent for tools when there is no plan for education or end-user training. It seems the “hype” about ease of use, coupled with tremendous naiveté about the complexity of most BI problems, negates common sense.

I would not purchase any end-user BI tool from a vendor if the vendor weren't fully prepared to include guidance and direct education as part of the package. Most vendors offer a series of education venues (classroom, computer-based training, and tutorials) that you can take advantage of.

Why would any company just expect their users to pick up usage on their own? Doesn't it make sense that the producer of the software would have the best ideas for the basics of the software that they developed?

Because most BI output requires additional mathematics calculations beyond the base form of the data, vanilla functions from a tool probably are not adequate for the job. There may be several ways to obtain the desired result, but one may be substantially easier or more efficient—or both.

You simply won't attain the results you desire nor maximize your investment by letting users run amok with BI tools. Certification for usage should be done, and every reasonable step should be taken to ensure that they have consistent, quality training so they do not waste their time or corporate assets.

Greatest impact: Shorten the learning curve and establish best practices with the tool early on.

What is your plan to ensure that end users will continue to grow their use of the tools and to do so in a manner that is optimal for the business? I have listed a few such as newsletters, lunch-and-learns, etc. What venue fits your corporate culture the best?

In the early days of Decision Support, it was very common to host periodic internal user group meetings in which individuals could exchange information, tips, “gotchas,” and more. Creating and posting an internal support document was also thought to be essential.

The lean, mean business environment of today has created a workplace in which many people are simply “maxed out.” It may be good for the bottom line, but it makes sharing and taking time to share very difficult. The tendency to work remotely from a central office makes individuals even more isolated.

Some companies sponsor inter-enterprise user groups such that they may share ideas and work with their peers or others who are using the same tools. I have been involved with a number of these and find them to be good and bad. If true information sharing occurs, these meetings can be wonderful. If they degenerate into soapbox oratory practice sessions or ill-prepared meetings, they are a waste of time—if not detrimental. Some of the best-of-breed product support people “magically” find new employment from such encounters.

However you do it, the users will benefit greatly, as will the enterprise, if you provide a consistent focal point of information. This also allows your favorite vendors to present their latest wares or share tips and techniques that may prove essential to some project down the road.

Greatest impact: Corporate information sharing; providing a common and consistent source of BI tools information and experiences that relate to your business and projects.

When you believe that a specific feature should work in a manner that it does not or you are getting errors that simply defy all that you believe to be accurate, you may have a “bug.” So to whom do you go to solve this? Is it a departmental specialist? Is it the systems support group? Do you call the vendor toll-free telephone number?

It is probably not a good idea to have individuals coming up with their own approach to solving a problem. Sometimes, the steps they take actually make the situation worse. A simple checklist for problem resolution and escalation is essential. There are two compelling reasons for doing this:

Remember my example of a query tool with DB2? In a situation like that, someone simply has to own the product support, nuance, changes area. I have seen circumstances in which a group of significant business users had been held at bay waiting for a “fix” for a product defect. In several cases, there was no defect at all. Someone had made a small system change or some such minor thing, and everyone was put on hold waiting for unnecessary problem resolution.

Greatest impact: Bringing order and formality to problem resolution.

I will pool all of the vendor support issues into a single discussion. First, it helps to understand what resources the vendor is willing to bring to bear for supporting you. You also can fit your support model into their structure.

What if, for example, the vendor provides only a limited pool of user IDs for access to their support lines? Do we pass the IDs around, or do we provide a central, filtering process so we do not have random, unknown requests and responses?

In many cases, the ability to handle the “how-to” questions will determine the viability or failure of our use for any particular tool. I have worked with numerous tools for which some critical topic had been covered in a class, but the notes provided were weak and my notes were even weaker. I then went to the online User Guide or similar facility and just couldn't make sense of the information. The examples given were not illustrated enough to figure out how to do what I wanted to do.

Sometimes, a vendor's web site has provided exactly what I needed in FAQs or other online addenda. Sometimes, vendors' web sites are atrocious for support and problem resolution. When you are involved in the vendor selection process for BI, you should set up a meeting with IT, the users, and the vendor and that meeting should cover support and education issues alone.

It may well be that your preference for a particular vendor outweighs some perceived shortfalls in the way you want support to be. You should make sure that your company does not go any farther with BI implementation until you have a solid plan for support and education that fits your model and the vendor's model and one that could be effectively used.

How will we feed these answers and new information learned into internal support systems? Consider how you will feed this information into your processes and loops such that the information is available and provided to your knowledge-based systems if you have them. If not, it's time to consider what they may provide.

All the features, functions, and firepower in the world will do little to benefit you if the majority of the users simply cannot figure out how to use them. The best BI tool for you may not be the one with which you are most enamored, but the one that provides the most complete solution to all your end-user requirements.

I have stated several times that I am a single-tool advocate. Realistically, one tool will not satisfy all user requirements. However, there should be significant thought and justification for supporting more than one vendor product. The primary mission should be to select the tool that best fits the needs of those who will make a definitive impact upon our bottom line.

Assuming that we have all the right “stuff” in place, the stars are aligned properly, the moon is in the Seventh House, and all that, how should we implement BI solutions?