9.8 Best Practices
Those experienced in business
intelligence generally agree that the following are typical reasons
why these projects fail:
- Failure to involve business users, IT representatives, sponsoring executives, and anyone else with a vested interest throughout the data warehousing process
Not only do all of these groups provide valuable input for creating a
data warehouse, but lack of support by any of them can cause a data
warehouse to fail.
- Overlooking the key reasons for the data warehouse existence
During the planning stages, data warehouse designers can lose sight
of the forces driving the creation of the warehouse.
- Overlooked details and incorrect assumptions
A less-than-rigorous examination of the environment for a data
warehouse can doom the project to failure.
- Unrealistic time frames and scope
As with all projects, starting the creation of a data warehouse with
too short a time frame and too aggressive a scope will force the data
warehouse team to cut corners, resulting in the mistakes previously
mentioned.
- Failure to manage expectations
Data warehouses, like all technologies, are not a panacea. You must
make sure that all members of the team, as well as the eventual users
of the data warehouse, have an appropriate set of expectations.
- Tactical decision-making at the expense of long-term strategy
Although it may seem overly time-consuming at the start, you must
keep in mind the long-term goals of your project, and your
organization, throughout the design and implementation process.
Failing to do so has two results: it delays the onset of problems,
but it also increases the likelihood and severity of those problems.
- Failure to leverage the experience of others
There's nothing like learning from those who have
succeeded on similar projects. It's almost as good
to gain from the experience of others who have failed at similar
tasks; at least you can avoid the mistakes that led to their
failures.
Successful business intelligence projects require the continuous
involvement of business analysts and users, sponsoring executives,
and IT. Ignoring this often-repeated piece of advice is probably the
single biggest cause of many of the most spectacular failures.
Establishing a warehouse has to produce a clear business benefit and
return on investment (ROI). Executives are key throughout the process
because data warehouse and data mart coordination often crosses
departmental boundaries, and funding likely comes from high levels.
Your business intelligence project should provide answers to business
problems that are linked to key business initiatives. Ruthlessly
eliminate any developments that take projects in another direction.
The motivation behind the technology implementation schedule should
be the desire to answer critical business questions. Positive ROI
from the project should be demonstrated during the incremental
building process.
9.8.1 Common Misconceptions
Having too simplistic a view
during any part of the building process (a view that overlooks
details) can lead to many problems. Here are just a few of the
typical (and usually incorrect) assumptions people make in the
process of implementing a business intelligence solution:
Sources of data are clean and consistent. Someone in the organization understands what is in the source
databases, the quality of the data, and where to find items of
business interest. Extractions from operational sources can be built and discarded as
needed, with no records left behind. Summary data is going to be adequate, and detailed data can be left
out. IT has all the skills available to manage and develop all the
necessary extraction routines, tune the database(s), maintain the
systems and the network, and perform backups and recoveries in a
reasonable time frame. Development is possible without continuous feedback and periodic
prototyping involving analysts and possibly sponsoring executives. The warehouse won't change over time, so
"versioning" won't
be an issue. Analysts will have all the skills needed to make full use of the
warehouse or the warehouse tools. IT can control what tools the analysts select and use. The number of users is known and predictable. The kinds of queries are known and predictable. Computer hardware is infinitely scalable, regardless of design. If a business area builds a data mart independently, IT
won't be asked to support it later. Consultants will be readily available in a pinch to solve last-minute
problems. Metadata is not important, and planning for it can be delayed.
9.8.2 Effective Strategy
Most software and implementation projects have difficulty meeting
schedules. Because of the complexity in business intelligence
projects, they frequently take much longer than the initial schedule,
which is exactly what an executive who needs the information to make
vital strategic decisions doesn't want to hear! If
you build in increments implementing working prototypes along the
way, the project can begin showing positive ROI, and changes in the
subsequent schedule can be linked back to real business requirements,
not just to technical issues (which executives don't
ordinarily understand).
You must avoid scope creep and expectations throughout the project.
When you receive recommended changes or additions from the business
side, you must confirm that these changes provide an adequate return
on investment or you will find yourself working long and hard on
facets of the warehouse without any real payoff. The business
reasoning must be part of the prioritization process; you must
understand why trade-offs are made. If you run into departmental
"turf wars" over the ownership of
data, you'll need to involve key executives for
mediation and guidance.
The pressure of limited time and skills and immediate business needs
sometimes leads to making tactical decisions in establishing a data
warehouse at the expense of a long-term strategy. In spite of the
pressures, you should create a long-term strategy at the beginning of
the project and stick to it, or at least be aware of the consequences
of modifying it. There should be just enough detail to prevent wasted
efforts along the way, and the strategy should be flexible enough to
take into account business acquisitions, mergers, and so on.
Your long-term strategy must embrace emerging trends in warehousing
such as web deployment and the need for high-availability solutions.
The rate of change and volume of products being introduced sometimes
makes it difficult to sort through what is real and what is hype.
Most companies struggle with keeping up with the knowledge curve.
Traditional sources of information include vendors, consultants, and
data-processing industry consultants, each of which usually has a
vested interest in selling something. The vendors want to sell
products; the consultants want to sell skills they have
"on the bench"; and IT industry
analysts may be reselling their favorable reviews of vendors and
consultants to those same vendors and consultants. Any single source
can lead to wrong conclusions, but by talking to multiple sources,
some consensus should emerge and provide answers to your questions.
The best way to gain insight is by discussing business intelligence
projects with similar companies�at least at the working
prototype stage�at conferences. Finding workable solutions and
establishing a set of contacts to network with in the future can make
attendance at these conferences well worth the price (and may even be
more valuable than the topics presented).
|
No comments:
Post a Comment