Tuesday, March 29, 2011

The Art of Identifying Meaningful BI Requirements

We have seen time and time again that the success of DW/BI implementations is dependent on the ability to identify BI requirements that have a measurable impact on the organization’s business decision making process (see our blog article “You just need three letters: WHY?”). However, identifying such requirements is a not a trivial process. A repeatable process is needed that is designed to keep the focus on the client’s business when developing business requirements for a DW/BI implementation. The following sections describe an overall approach with suggested techniques that we have used successfully.

Macro Level Understanding of Business

It is important to understand how your organization operates: how the business runs in order to make the best use of your BI capability. When you understand the key business processes and key business objectives, you can begin to drill down into more details that will provide not only reporting requirements, but also the data elements that are required to support those requirements.

Business Processes/Objectives

By understanding the business at a high level, you can begin to understand the business processes that support the organization. We need to understand what the key business processes are, then we need to understand how they work. We also strive to understand the core business objectives. Ultimately, all decisions that the customers make should support one or more business objectives. Once we identify business decisions, we can more easily identify detailed business questions and related data elements. The business questions will lead directly to specific reports or sets of reports. The data elements will support those reports and potential ad hoc analysis needs.

How to Implement

We can use the following tools and techniques to implement this requirements process. Background Research provides initial information about the nature of the business and its processes. It can help provide a preliminary list of decision centers, activities, and major decisions that are part of the organization you are focused on.

Structured Interviews should be used to build on the initial research you have gained. Seek out those who are knowledgeable of the organizational business processes. Through the interview process, the interviewer can gain information about problems, decisions, or critical success factors that are part of the running of the business. This high-level information can be used as a starting point in gathering more detailed requirements necessary for building a decision support system. Ask questions that lead the interviewee to indirectly identify information that supports decision-making. One approach is to ask the interviewee to identify the major business drivers that they are responsible for. Once these drivers are identified, ask them to identify the major decisions that they need to make to support those business drivers and one or more questions that they ask in the process of making each decision. Another approach is to ask your customer to identify the critical success factors they are responsible for. The individual should then be asked to identify for each critical success factor the information they need to ensure that the critical success factor is under control.

Joint Application Design (JAD) is a communal effort to further refine and agree on the hierarchy of business needs. When individuals are interviewed alone, they tend to respond to questions more or less in a vacuum; without the context of others’ views on how information is used. They also may have difficulty identifying a comprehensive set of answers to each question they are asked. A JAD session helps to elicit greater “thinking” by the participants as they hear other ideas and perspectives. A JAD session helps to bring out more decisions and business questions as more approaches are identified. The result: a more complete set of requirements upon which to build a BI system. The JAD session will be most successful if the right people are present. Individuals who have a solid understanding of each of the business processes to be covered, have the authority to make design decisions, and communicate well, should participate. The facilitator should be knowledgeable in BI system design as well as the business being supported. A JAD session should be held only after you have identified a baseline of business drivers, business decisions, and business questions based on information from the initial set of structured interviews and research.

Prototyping is a technique used after initial requirements have been established. Based on the information gathered from interviews and JAD sessions, you can develop an initial reporting database with limited BI reports. This gives you an opportunity to demonstrate the information and functionality of the reports to end users early in the development process. The feedback you received will help you to fine-tune your product early in the process so that the delivered product more closely meets your customer’s needs.

The figure below summarizes how a top-down approach will help to derive both reporting requirements as well as supporting data elements. For each business objective, there may be several business processes and decisions to support that objective. Each process and decision will involve business questions that need to be answered to support the process or decision. A business question may drive a specific report requirement. Meanwhile, each business question will require multiple data elements. By going through this process, you not only identify business-driven requirements for your BI system; you also keep the customer more heavily involved by forcing them to think critically about how their day-to-day decisions help drive the overall business. We have found these techniques to be successful using them in different combinations based on our client situation. How have these techniques worked for you? What other methods have you found valuable in driving requirements for your reporting initiatives?

Friday, March 4, 2011

Conditional Report Execution in OBIEE

Here is a solution for providing conditional report execution based on prompt selection. For example, if a user chooses value ‘A’ in the prompt, then report ‘Report A’ should be executed. If a user chooses value ‘B’, then OBIEE should execute report ‘Report B’. In other words, the prompt will not be used as a filter but rather as a tool to conditionally execute reports. Here are the steps to implement conditional report execution: In this example, we want to conditionally execute the following two OBIEE reports: “Detail” and “Summary”. The prompt should determine which of these two reports should be executed. First, we have to create a prompt with two hard-coded values: "Detail" and "Summary". 'Detail' and "Summary" refer to the respective reports that we want to execute. We can select any column that is not being used in the report.

SELECT case when 1=0 then "Dim Credential"."Credential Type Level 1" else 'Detail' end FROM "Field Readiness" union all SELECT case when 1=0 then "Dim Credential"."Credential Type Level 1" else 'Summary' end FROM "Field Readiness"
The prompt will now look like this: Next we will have to create a new report "pqr" that we will use for guided navigation. This report must include a column that returns the constant value "Detail". We then create a filter on the column with a constant value "Detail" using presentation variable "xyz". This report will only return values when the prompt value is same as "Detail". Since we know the prompt has two values "Detail" and "Summary", this report will not return any record when the prompt value is set to "Summary". Next we have to go into the dashboard editor and create three sections, one for the prompt and one for each of the two conditional reports. We then click "Properties" on the Report 1 section and select "Guided Navigation" option. We now have to refer to the "pqr" source report as shown in the image below. Then click ‘Properties’ on Report 2 section and select ‘Guided Navigation’ option. When we open the new dashboard page, we can now test whether the conditional report execution is working. Please let us know if you have any questions.