Top 20 Tips for OLAP Success : "Here are 20 quick tips,
some obvious, but others counterintuitive, which are all based
on real-world experience and research data."
I've got a
lot of time for Nigel Pendse, the industry analyst behind
this article for DMReview and
The OLAP Report, the
"vendor neutral" resource site for OLAP technology. Nigel has
kept true to the core principals behind OLAP and business
intelligence and although he's not always been the most
complementary about Oracle's products, he's been a great
advocate of OLAP technology and not been afraid to call Oracle
on the way they've migrated Express to Oracle OLAP over the
years. Nigel helped me with
the article I wrote last year for DMReview and has a good
understanding of the way Oracle, and Microsoft are building OLAP
functionality into their core database products, and moreover
he's always been a great advocate for the customer when dealing
with OLAP vendors.
Three of the tips that Nigel raised I thought were worth
pointing out here. The first one I thought was particularly
relevant considering a couple of projects I've worked on
recently, where the client wanted to use just one tool -
Discoverer - to do all of their reporting, even though
complementary tools such as Reports or Excel would probably fit
some users' needs better, but would involve extra overhead from
a support perspective.
2. Don't try and force every project to use one
"corporate standard" tool.
There may be IT benefits in doing this, but the projects are
unlikely to deliver the potential business benefits if you
insist on using potentially unsuitable products for every
project or override the end users. Remember that it is better
to have two successful projects using different products than
one integrated but unsuccessful project that conforms to IT
standards but doesn't deliver business benefits. The OLAP
Survey 3 confirms that selecting a product just because it is
a corporate standard does not lead to successful projects. So,
even if you have established corporate standards, set up a
clear "waiver process" to evaluate whether new software should
The next one is one close to my heart, and concerns the
benefits you can get from hiring experienced, BI-focused
consultants to better ensure project success:
"16. Do use consultants to help choose and implement
Try not to use the same firm for both selecting the
product and then implementing it. Implementation consultants
will always favor products they know, rather than those that
are right for the task. Equally, not until you know which
product you will be using can you select consultants who are
known to be expert in it.
Avoid using large, famous, general purpose consultants - they
cost more, take longer and usually deliver less than smaller,
more focused, BI specialists. Always choose the implementation
consultant after choosing the product and make sure that
everyone who will be implementing the solution has already
used the product in at least one previous project; don't let
consultants learn to use the software at your expense."
The last one concerns the role of business users in scoping
and driving the project. This one is a bit harder in practice,
as although we'd all love users to generate the demand in the
first place, lead the project and define the requirements, in
the end what usually happens is that the project is an IT
initiative, and it's IT that usually end up driving the project.
"17. Try to ensure that projects are led by business
users involved with the project.
In-house IT experts may have little BI experience and projects
need to be business led. The OLAP Surveys consistently found
that the most successful projects are led by external BI
specialist consulting firms, and projects that are business
led achieve more than those that are IT led. Of course,
experienced IT people must be fully involved, but the project
should always be "owned" by the business."