Tuesday, 16 December 2014

OBIEE Projects - Solution Process

Sixth and last chapter of session Success with Oracle BI? Typical Error Scenarios and their Solution outlines implementation steps to achieve a first production rollout of a revised OBIEE repository fulfilling client's needs. Please follow our OBIEE project series presenting our process for solving typical OBIEE project issues:

1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process

What did we do until now? Coming from a concrete defect description and a list of nonexistent OBIEE functionalities we implement a prototype to show the client that OBIEE fulfills his requirements. At the same time we analyze previous supplier's OBIEE repository, elaborate a turn-around plan based on proven OBIEE implementation principles and provide a detailed effort estimation for further tasks (phase 6 described below). Time frame to accomplish phase 1 up to 5 is just a few days of work.

We start to build a running OBIEE solution utilizing gathered topics in prior phases. Of course that's not just configuring the OBIEE repository, we create detailed design documents and establish coding standards. Don't wonder that we introduce coding standard in a software which is just configured. You may ask "Is it really necessary?" - Yes, it is. Additionally it's crucial to:
  • Create a new OBIEE repository. Changing the previous one will take much more time and the risk of failure increases.
  • Use existing data warehouse tables for your OBIEE logical model even if they should be changed to get an optimized or correct data model. Tables are only changed if it's absolutely necessary. OBIEE is able to handle such a situation and changing OBIEE configuration later causes not too much effort. Data warehouse tables changes can be done after first rollout. We avoid to generate data warehouse process change effort at this point, because focus is still to have the first OBIEE repository running after at most two or three weeks.
Of course we identify and define an optimized data warehouse model for OBIEE in parallel, but corresponding tasks are fulfilled later. In general the current phase occurs near to important project milestone. So it's perhaps necessary to implement an interim solution. Don't care, OBIEE is flexible enough to do so with very reduced extra cost.

When first production rollout is achieved we apply regular process cycles to the project. In parallel we solve errors identified across the complete BI and DWH stack in prior phases and start to consider new or changed business requirements as we have now a sound basis to release the full power of OBIEE. During all the time we stay in close contact to business users to verify functional and nonfunctional requirements continuously.

Is it possible to recognize aberration early?
Situations as described in this OBIEE project series shouldn't occur, but they do. You can follow some rules to avoid and recognize such trends, especially when projects will be in development phases for months:
  • BI projects must be independent from other IT projects. Don't force them to be just sub-projects of any other software launch.
  • Perform rollout extreme having two week cycles for delivering new or changed functionality to end users.
  • Support and evolve agility between IT and business (see our presentation Self Service BI with Oracle BI)
  • Create know-how early (see article OBIEE End User Training Concept).
Why? Because proper OBIEE structure supports agility and high reactivity.

Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.

No comments:

Post a Comment