Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications
Подождите немного. Документ загружается.
Don't depend on any single business unit to
completely fund the BI initiative. The true business
potential for BI usually lies in delivering information
that is used across the lines of business.
Don't get maneuvered into promising a specific
dollar-value return on investment that the BI
information is supposed to offer. For example, if a
business benefit is the potential for cross-selling,
the amount that could be generated from cross-
selling is pure guesswork. One selling experience
could generate a minute amount, while another
could generate enough revenue to cover the entire
cost of the first BI application release.
Never work alone. Realize that business managers
would like to profit from any competitive advantage
they can get in this increasingly competitive
marketplace. Business managers are quite willing to
work with IT on business justification for a BI
decision-support initiative.
Tips and Rules of Thumb
Chances to succeed or fail:
- If the BI decision-support initiative is driven
by a business problem, it has a very good
chance of success.
- If the BI decision-support initiative is driven
only by the latest trend in technology, it has a
very good chance of failure.
Keep complexity and integration to a minimum on
every BI decision-support project to avoid a higher
risk of failure.
As early as possible, assess the risk for the six
categories of technology, complexity, integration,
organization, staffing, and financial investment in
order to gain a better understanding of the BI
initiative.
Usage: 20 percent of the business people will be
using the BI decision-support environment 80
percent of the time. Initially address the needs of
those people who form that 20 percent.
2. Enterprise
Infrastructure Evaluation
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
561/631
Section A.
Technical
Infrastructure
Evaluation
Pay attention to scalability; avoid any components
that scale poorly. Scalability is one of the most
important factors to be considered.
Watch out for products that offer unnecessary
technical elegance. The price you will pay for this
elegance is either needing more staff training or
requiring more resources.
Use tools whenever possible instead of writing your
own custom code.
Understand the types of analyses the business
people need to perform so that you can choose the
appropriate tool set.
Keep current with technology.
Don'ts
Don't jump to implement a very large database
(VLDB) unless the vendor's VLDB features are
delivered and have proven themselves.
Don't expect to buy a BI decision-support turnkey
solution. A BI decision-support environment evolves
over time.
Don't select a tool without participation by the
business people; otherwise they may not buy into it
and may not use it.
Never assume that because a software product is
labeled "OLAP" it will satisfy the analytical reporting
needs of the business community.
Don't select an OLAP tool just because it is popular.
First and foremost, it must have functionality that
matches the analytical requirements of the business
community, and it must be easy to use.
Tips and Rules of Thumb
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
562/631
Hardware: One of the main features required to
support the BI decision-support environment is
scalability. Therefore, monitor the rapid changes in:
- Data volume
- Load frequencies
- Data access patterns
- Number of reports and queries
- Number of tools
- Number of people accessing the BI target
databases
- Number of operational systems feeding the
BI target databases
DBMS functions: The necessary and important
functions of the selected DBMS for the BI decision-
support environment are:
- Degree of parallelism in handling queries
and data loads
- Intelligence in handling dimensional
database designs (optimizers)
- Database scalability
- Internet integration
- Availability of advanced index schemes
- Replication on heterogeneous platforms
- Unattended operations
DBMS workload: The BI decision-support
environment is an unpredictable mix in workload
demand. It is common for a BI application to
support hundreds of knowledge workers, business
analysts, and business managers performing data
access requests that range from simple indexed
retrievals to more complex comparative analysis
queries. Such an environment requires that the
DBMS not only provide efficient complex JOIN
processing but also manage and balance the overall
workload effectively.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
563/631
Section B.
Nontechnical
Infrastructure
Evaluation
Identify the missing or ineffective nontechnical
infrastructure components. These components
provide the glue for cross-organizational
integration.
Pay attention to meta data. Meta data is much more
than documentation. It facilitates navigation
through the BI decision-support environment and is
an integral part of every BI project.
Provide standards for your formal project
documents. For example, specify that each
document must have a title, description, purpose,
author, owner, creation date, latest update date,
latest version number, revision history, page
numbers, and sign-off space.
Don'ts
Don't attempt to build all components of the
nontechnical infrastructure at once. Start with
standards, then model the common business data
architecture, and go from there. This is an iterative
refinement process.
Don't forget to allocate time and resources on the
project plan for working on noninfrastructure
activities.
Don't skip data standardization because you think it
is too difficult or takes too much time. One of the
main reasons for a BI decision-support initiative is
to address data quality and data standardization.
Tips and Rules of Thumb
Use a meta data repository if you have one. If you
do not have one, but you have a fairly sophisticated
CASE tool, use that CASE tool in the interim until a
more permanent repository solution is established.
At a minimum, document the source-to-target data
mapping and the transformation rules in some
format that can be accessed by the business people
and that can later be used to populate a meta data
repository.
Determine what types of standards, guidelines, and
procedures already exist in the organization—what
is useful, what is not, and what is missing. The
fastest way to assess this is to talk to the staff of the
following groups: data administration, strategic
architecture, quality assurance, security, audit,
standards, training, and even operations.
Include at least one nontechnical infrastructure
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
564/631
requirement with every BI project. Implement at
least 80 percent of its functionality, and plan to
revise it in future BI projects.
As much as possible, reuse the standards,
guidelines, procedures, and so on that already exist
in the organization. Try not to reinvent the wheel.
Get input from as many people in IT and on the
business side as you can to develop a practical and
useful nontechnical infrastructure at your
organization.
3. Project Planning
Use Business Intelligence Roadmap to create your
work breakdown structure and project plan. If you
have Microsoft Project, copy and modify the work
breakdown structure on the CD included with this
book.
Insist on having a full-time business representative
matrixed into your project. Development work will
go much faster because issues can be resolved on
the spot. Also, knowledge transfer will occur
because the business representative will be part of
the project core team. This will also go a long way
toward eliminating the "us versus them" syndrome
between IT and the business.
Create a detailed project charter and use it as your
baseline for change control.
Have stringent change-control procedures. Never
change the scope without renegotiating the
constraints of time, budget, resources, and quality.
If your project plan was doable before the scope
change, it will no longer be doable unless you
renegotiate all constraints.
Plan to keep an issues log. Be aware that some
issues may not get resolved during the project. This
may result in a scope change, and some
deliverables may have to be deferred to a future
release.
Perform a detailed risk analysis. Be sure to weigh
the risks and provide recommendations and a plan
to mitigate them. Also, include a contingency plan in
case the risks cannot be avoided.
Consider all your assumptions as potential risks,
and manage them accordingly.
Assess the quality of source data early so that you
can have confidence in your estimates for the
project completion date.
Don'ts
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
565/631
Never build the BI application "by the seat of the
pants" because you will miss tasks, and you will
underestimate the effort.
Never make any assumptions about knowing
intuitively what tasks have to be performed and how
long they will take. Document your estimates in a
detailed project plan.
Don't assemble a large team. Although BI projects
are big and complicated, communication and
coordination among the team members will slow
down the project. Keep the project core team down
to about four or five people (never more than
seven). Keep each step core team down to two or
three people. Remember that multiple roles can be
assigned to one person, and that multiple people
can share one role.
Don't plan to perform all tasks or all activities in
Business Intelligence Roadmap. Select only the ones
you need and add any additional tasks that may be
unique to your BI decision-support project.
Don't forget to allocate time to be spent on other
common project-related or organizational activities
not listed as tasks on your project plan (for
example, troubleshooting other systems, attending
department meetings, and dealing with computer
downtime).
Don't forget to allocate time for vacations, sick
leave, jury duty, and so on.
Don't spend too much time on tuning your
estimates, only enough to have confidence in them.
Tips and Rules of Thumb
Review the stages and determine at which stage
your project needs to begin. For example, some
projects will begin with justification, others will
begin with planning, and some short enhancement
releases may even begin with design. Then, in a
similar vein, review the steps and determine which
ones are appropriate for your project. Finally,
review the activities as well as the tasks and
subtasks, and extract only those you need to
perform on your project. Most projects require 90
percent of the activities to be performed for the
selected steps.
Be prepared to answer the four questions that are
always asked about every project:
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
566/631
- What will be delivered?
- How much will it cost?
- When will it be done?
- Who will be doing it?
Project failures: A very high percentage of BI
projects are aborted because of inadequate or
nonexistent project planning and because of
inadequate resources. Don't become one of the
casualties.
One of the critical success factors is having a very
strong business sponsor who understands the
release concept of BI projects and who is agreeable
to keeping the scope small and the quality high.
Skills: It takes one week to acquire a basic skill in a
seminar and six months to master it. Be sure you
understand the skill set of your BI project team
members.
Estimates of time required for data cleansing are
often missed by a factor of three or four. Estimate
the time you think you will require and multiply it
by three if your source data is stored in relational
databases; multiply it by four if your source data is
stored in old flat files.
Data quality: Find out in how many places the data
is stored and how many variations of the data exist.
- If the same customer record is stored in no
more than two places and the data is
consistent, you have a minor problem.
- If the same customer record is stored in
three to five places and the data is consistent,
you have a medium-sized problem.
- If the same customer record is stored in six
or more places and the data is inconsistent,
you have a serious problem!
Work with several important business people who
will be using the BI data and discuss your findings
with them.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
567/631
4. Project Requirements
Definition
Prioritize the functional requirements into
mandatory, important, and nice-to-have.
Concentrate on the mandatory functions and add
important functions as time allows. Nice-to-have
requirements should be dropped from the project
scope.
Prioritize data requirements into mandatory,
important, and nice-to-have. Identify the exact
business needs that will be met by each category.
Concentrate on the mandatory and important data,
and don't include the nice-to-have data. Remember
to keep data scope to a minimum because that is
where all the effort is.
Determine whether the required source data has
ever been gathered and stored in an operational
system. You cannot create new data with a BI
decision-support application.
Try to determine the types of ad hoc queries the
business people may want to write. Although "ad
hoc" implies that those queries are not yet defined,
most business people have a pattern of questions
they usually ask on a regular basis. This information
will have bearing on the design of the BI target
databases.
Be prepared to negotiate and renegotiate the final
deliverables throughout the project. Unexpected
roadblocks can derail a project if the scope is not
renegotiated with the business representative and
the business sponsor. Keeping the business
representative involved in all decisions increases
your chances for success despite the obstacles.
Don'ts
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
568/631
Don't work without a business representative.
Project requirements must come from business
people, not from IT systems analysts.
Don't spend too much time in this step on source
data analysis. Investigate suspected data quality
problems only enough to get a better understanding
of the cleansing complexity. Conversely, don't wait
until design or testing to discover dirty source data.
Preliminary source data analysis must be performed
in this step, and rigorous source data analysis will
be performed in Step 5, Data Analysis.
Don't spend too much time in this step on refining
the logical data model, only enough to take it
beyond the conceptual level and to add the
significant attributes (data elements).
Never accept a wish list of data elements and a
stack of mock reports as the final requirements.
Requirements need to be negotiated.
This is not the time to commit to service-level
agreements because it is too early to know if they
can be met. However, you can document the outer
limits of what will be acceptable and what will not
be acceptable to the business sponsor and to the
business people.
Tips and Rules of Thumb
Always review the scope to see if it is still doable
within the constraints of time, budget, resources,
and quality. Always balance the constraints and
renegotiate them when necessary with the business
sponsor and the business representative.
Defining requirements is a different activity than
designing a solution. Don't let the technicians jump
into designing the solution at this time, as many like
to do.
Try to conduct as many group interviews as
possible. The synergy created during these sessions
often brings new requirements to the surface,
uncovers definitional and quality problems, clears
up misunderstandings, and occasionally even
resolves disputes.
In regards to source data for the BI target
databases, going after too much operational data
"just in case they'll need it some day" leads to more
complex data models and more time and money
spent for data extraction, cleansing, and
maintenance. Not all data is created equal. Keep in
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
569/631
mind that in most cases, only 20 percent of the BI
data is regularly used 80 percent of the time.
Ask the IT staff to help identify which source data is
seldom or never used by the business people. This
means that it most probably does not have to be
included in the BI project scope. However, let the
business representative make the final decision, not
the technicians.
5. Data Analysis
Ensure that the logical data model reflects the
cross-organizational understanding of data and is
not an isolated view of one business representative
or one department. For example, if the desire is to
study customer profiles that cross all product lines
in the organization, common customer and product
definitions are critical components.
Understand the kinds of external data that will be
used in the BI decision-support environment.
Determine what the basis will be to synthesize the
external information with the internal information.
Review all business meta data with the data owners
and with the information consumers (business
managers and business analysts in other
departments who use that data) to obtain their
concurrence on data definitions, data domains,
business rules, and data usage.
Establish a dispute resolution procedure to resolve
differences among business people from different
departments regarding data definitions, data
domains, business rules, and data usage. These
procedures should suggest the involvement of a BI
arbitration board as a last resort.
Urge the data owners to accept responsibility and
accountability for the quality of their data. Ask them
to clean up their operational source data, if feasible.
Identify the critical data elements that have real
business value. These critical data elements have to
be cleansed to meet the business expectations of
data reliability.
Don'ts
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
570/631