Skip to Content

During a recent project review of an upcoming Enterprise BI / DW platform,
one of the project tasks’s was to do an end to end tool selection. However,
beyond technology the other aspects of a successful BI program necessary
including people, process and data (ownership) were not properly being assessed.
The needs to properly assess and manage these areas would outlast any
particular phase/sprint of development and would have an even greater impact
than the technology.  With a brand new large BI program there will need to be
new processes and new teams created in IT to make the current software in order
to be effective in this program (note: projects end, programs evolve and change
with the business, so BI/DW programs should be built and staffed that way from
day 1)

What was missing in the evaluation is the desired impact in the IT culture.
All of the solutions involved in the evaluation would demand a high level of
experience, technical knowledge and creativity during the design and development
in order to make it a success.  While the technical evaluations were sound, I
wanted to see that there had been consideration of other non-technical aspects
of a Data warehouse necessary to make the program and systems a success.

Questions arose that needed to be answered

– Is the expectation that business users will be connecting with Vendor
support directly?

– who is responsible for “quality” resource acquisition

– Who is responsible for help desk models to support Business Rules, Data
Miniing , etc

– Who is responsible for ensuring that the quality of the data is kept intact
over time from a technical architecture as the business change over time?

– Who is responsible for ensuring that the knowledge of business rules are
kept as assets?  An enterprise data warehouse/ BI system is a huge investment
and that investment should be protected as an asset of the company.

No matter what tool is chosen there are huge drains to a project, in time and
quality, when users need to make business rule and solution design decisions on
the fly.  This includes the creation of new business metrics, new reporting
processes and mini-tool selections as new requests come up. (i.e. the users uses
the excel export so they can recalculate a metric because the data warehouse
team takes 3 weeks to get a change in place).

One of the best practices to balance the projects technical needs with the
people and processes is to establish a Business Intelligence competency group at
the outset of the project that sits outside of any software or services vendor
and has staffed BI/DW architects to can “rapidly” respond to the changing needs
of the business with the “correct” solution and the ability to pull in the
correct IT resources to meet that need at the speed the business needs before
they feel the need to go out on their own.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply