BI and the Airline Industry: Case Study

I am a huge air transportation enthusiast, so naturally, our Cloud Airlines example in class inspired me to look for a BI solution that has been implemented in the real world. I will introduce a case that I have found in this blog.

An Asia-Pacific airline company determined that it needed a business intelligence solution that would serve as a single information source and integrate all systems across its enterprise. The company tried to implement a solution on their own but found that they lacked the internal resources. So, they reached out to Accenture to help them do so. They chose Accenture because of its more than 30 years of experience working with SAP existing relationship with the company and previous work in this area for another major airline.

Accenture used SAP Business Objects Enterprise for reporting and Dashboard Design for for the dashboard. This was designed to replace the existing, manual process of creating reports, which helped the managers focus more on analysis instead. After Accenture helped the company design their new enterprise airline data warehouse model, the next stages included:

• Building and implementing the data warehouse and dashboard
• Creating BI reports for airline operations, passenger revenue and profitability analysis
• Preparing the client's team for further development and improvement

The implementation covered the entire business, from flight operations to sales to customer service. With the new solution the airline company's employees no longer needed to spend large amounts of time generating reports for top management. The automation process also reduced the risk of reporting errors that had previously existed when the reporting was performed manually. 

To learn more, visit here: http://www.accenture.com/us-en/Pages/success-asia-pacific-airline-data-warehouse-solution.aspx. 

Thanks for reading!

Gathering Requirements

We talked about best practices for gathering business requirements in class, and I thought I would expand upon what we discussed.

Source Quality

It is important to point out that we should take some time to think about exactly whom to gather requirements from, because depending on the source, the answers we get may have varying degrees of value to us. For example, in some cases, the marketing department's input may be more helpful, while in others, the accounting department may provide more valuable information for our BI/DW work.

Key Techniques

There are specific ways via which we can gather requirements, and we may get different results at different degrees of quality and specificity. If there are no clearly defined questions, a brainstorming section, which allows free exchange (i.e., anything goes), may be the most helpful. If there are specific questions you are ready to ask, then one-on-one interviews may be better. If you are unable to find a time that both you and your clients can meet, perhaps a questionnaire is the way to go. Finally, in the case of system upgrades especially, studying the existing system may be a good starting point, because you can gather a lot of the same requirements that way without having to talk to the clients.

Selecting a Technique

You may wonder how we can select the best technique to gather requirements. Below is an interesting framework that may provide some guidance:



 Based on where your individual situation is in the graph above, you can select the right technique as follows:

• Catch-up: Interviews, work in target environment
• Fuzzy: Brainstorming, workshops
• Mature: Questionnaires, workshops, prototypes
• Selling/Teaching: prototypes

I hope that helped in shaping how you approach the critical requirement gathering process in BI/DW design!

Reference: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/req_gathering_techniques_8CB8E44C.html

The Four-Step Dimensional Design Process

Kimball and Ross laid out a systematic way to approach dimensional modeling. I will review the four key steps below:


Step 1: Select the Business Process

A business process is a low-level activity performed by an organization. This can be taking orders, processing claims or registering students. To identify these, look for the following common characteristics:

• Expressed as action verbs
• Supported by an operational system
• Generate key performance indicators
• Triggered by an input and result in output metrics

Be careful, though, when interviewing the users in an organization, as they often tend to talk in terms of broad strategic business initiatives. These would not serve well for dimensional modeling purposes. Make sure to dig deeper and seek out the specific underlying business processes that support the analytic requirements of the initiatives. 

Step 2: Declare the Grain

Declaring the grain means specifying exactly what an individual fact table row represents. This step is crucial in the modeling process, yet many professionals tend to overlook its importance. In the past, failing to declare the grain has been the most frequent mistake that professionals make. Although the grain is ultimately equivalent to the primary key, it should still be described using business terms for clarity. Below are a few examples:

• One row per individual boarding pass scanned at an airport gate
• One row per bank account each month
• One row per line item on a bill from a doctor

Step 3: Identify the Dimensions

Once the grain has been properly declared, the dimensions typically can easily be identified as they represent the “who, what, where, when, why, and how” associated with the event. A robust set of dimensions representing all possible descriptions should be identified. The following are some examples:

• Date
• Customer
• Employee
• Facility

Step 4: Identify the Facts

The facts are the performance metrics that business users are concerned about. These must be appropriately defined in accordance with the declared grain. If not, they should be placed in a different fact table. Usually, facts are numerical data, such as total cost or order quantity. However, in some case, they are not - we would call them "factless" facts. 

The four-step process must take into account not only the data sources, but more importantly, the business requirements. Although gathering user input may involve more complexity than relying on the data alone, it is essential for a sound dimensional design.

Reference: "The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd Edition" by Ralph Kimball and Margy Ross