Defining BI Requirements - Measures

The first task in a BI progam [and the first goal of the BI roadmap] is to identify what the business wants to achieve, and how business intelligence can support that need.

Look for opportunities in your organisation where business intelligence can:

1. improve the quality of day-to-day decision making
2. add value to operational efficiency
3. support tighter collaboration

BI Value Assessment

1. Where can business intelligence be used effectively?
2. Who will use the application?
3. What information do they need?
4. How will the outcomes be measured?

Defining How The Outcomes Will Be Measured

Defining outcomes relates directly to the roles of the users in the functional area. There are two aspects to this step:

1. Determining the base data required to measure outcomes - this data will be used in terms of dimensions to add context to the data, and thus transform the data into information.
2. Determining the level of data required - based on the business requirements

Define the Dimensions

Dimensions are used to describe the measures, and give them context. For instance, sales by customer group. 'Sales' is the base measure, and 'customer group' is the dimension. At a higher levels, calculated measures such as profitability by customer group.

When deciding on measures, consider how they interrelate and are calculated before defining dimensions such as time, product group, location etc.

Consider where the data is derived, how available it is based on current systems, and what data transformation will be required to access it to provide these measures.

Dont just think on each dimension alone, consider how multiple dimensions can describe a particular measure. Analysis across multiple dimensions simultaneously makes the data useful for analysiss

Dimensions typcially found in BI applications for each functional area include:

• Sales and Marketing—products, customers, demographics (age group, gender), sales channel, geography, promotions, campaigns, sales force, order status, sales type, time
• Human Resources—organizational chart, employees, time, business unit, department
• Operations—shift, time, assembly line, product, manufacturer, warehouse, suppliers
• Finance—currency, account, scenario, time, business unit, department

Define the Level of Detail

For each combination of dimensions and measures, decide how much detail is desired. This is defined as the lowest level of information for each dimension that must be available across different user groups. This is important, because all summarized data can be easily derived from the lowest level of detail.

The level of detail required is driven by the business requirements, yet it must remain practicable. Consider the relative cost and benefits of summarized vs. detailed data.

• Summarized or high-level data tends to minimize the number of data points that you have to analyze, but it does not allow you to see trends at lower levels of detail.
• Detailed, low-level data means that you will need to analyze more data points to identify trends.

This is required to meet the needs of both transactional level users who require detailed data to monitor activity performance, and managers who require summarized data to identify trends.

The key to finding the right balance is by first determining a reasonable level of detail for the lowest level of data required across all users, and then using the BI system to create hierarchical summaries.

Detailed data may also be used for more advanced analytical techniques, such as data mining.

Once the level of data detail is determined from a business requirements perspective, it will still need to be evaluated in terms of the feasibility of accessing the data.

NEXT: Conceptualising Ideas And Collating Information

Back To Top