11.2.5 Impact on Knowledge Areas
This section explains how specific business analysis practices within business intelligence are mapped to business analysis tasks and practices as defined by the BABOK® Guide. This section describes how each knowledge area is applied or modified with the business intelligence discipline.
Each knowledge area lists techniques relevant to a business intelligence perspective. Techniques used in the discipline of business intelligence do not deviate, to any great extent, from the BABOK® Guide techniques. BABOK® Guide techniques are found in the Techniques chapter of the BABOK® Guide. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.
.1 Business Analysis Planning and Monitoring
A business intelligence initiative may require establishing an underlying data infrastructure to support the solution, or it might be an enhancement based on the infrastructure of an existing solution. Scope Modelling is frequently used to differentiate between these alternatives and plan the relevant business analysis activities accordingly.
The business intelligence paradigm of information delivery might be a new, unfamiliar approach for business stakeholders and for the business analysts themselves. In planning the initiative, the business analyst considers:
- how experienced the stakeholders are in expressing their information and communication requirements in the business intelligence context, and
- how skilled the business analysts are in interpreting those requirements into detailed specifications for business intelligence technical specialists.
Business intelligence solutions typically provide frameworks, tools, and techniques that can assist in requirements definition and solution modelling. The level of stakeholders’ and business analysts’ expertise in these can have an impact on the planned approach.
When assessing stakeholder attitudes towards the business intelligence initiative, the business analyst should be aware that an enterprise-wide business intelligence solution might not provide direct value to some operational stakeholders, but will deliver it elsewhere in the organization, and the flexibility and extensibility provided by the business intelligence infrastructure delivers longer-term strategic value that goes beyond short-term operational benefits.
A business intelligence solution that integrates multiple data sources typically engages many stakeholders with overlapping information requirements. Business analysts prepare for the analysis and synthesis of individual requirements into a set that is complete and cohesive without conflicts and redundancies.
BABOK® Guide Techniques
- Acceptance and Evaluation Criteria (p. 217)
- Balanced Scorecard (p. 223)
- Brainstorming (p. 227)
- Decision Analysis (p. 261)
- Estimation (p. 271)
- Functional Decomposition (p. 283)
- Interviews (p. 290)
- Item Tracking (p. 294)
- Metrics and Key Performance Indicators (KPIs) (p. 297)
- Non-Functional Requirements Analysis (p. 302)
- Organizational Modelling (p. 308)
- Prioritization (p. 311)
- Process Modelling (p. 318)
- Reviews (p. 326)
- Risk Analysis and Management (p. 329)
- Roles and Permissions Matrix (p. 333)
- Root Cause Analysis (p. 335)
- Scope Modelling (p. 338)
- Stakeholder List, Map, or Personas (p. 344)
- Survey or Questionnaire (p. 350)
- Use Cases and Scenarios (p. 356)
- User Stories (p. 359)
- Workshops (p. 363)
.2 Elicitation and Collaboration
The cross-functional nature of business intelligence typically requires business analysts to employ specialized documentation tools and techniques to elicit particular types of requirements from stakeholders, both business and technical.
Individual stakeholders may only possess partial knowledge and expertise regarding:
- the business decisions that need support,
- the data elements that support those business decisions,
- the data sourcing, transformation, and integration rules, and
- the presentation of the required information.
Interviews with individual stakeholders identify the information and analytic insight required to support their decision making. Workshops with stakeholders from across different functional areas of the business can help detect common, overlapping information requirements that would be better met with an integrated solution.
Data models and data dictionaries provide definitions of the structure and business rules of existing systems data. The business analyst assesses available documentation to identify incompleteness of a model or inconsistencies between models.
Process models that are extended to include data artifacts can help identify the data sources required at decision points. Decision models specify the data analytic requirements and business rules for decisions.
Commercial off-the-shelf packages of business intelligence functionality can provide the business analyst with a set of highly effective prototyping tools to elicit and clarify stakeholder information and communication requirements.
BABOK® Guide Techniques
- Brainstorming (p. 227)
- Document Analysis (p. 269)
- Focus Groups (p. 279)
- Functional Decomposition (p. 283)
- Glossary (p. 286)
- Interface Analysis (p. 287)
- Interviews (p. 290)
- Item Tracking (p. 294)
- Observation (p. 305)
- Prototyping (p. 323)
- Workshops (p. 363)
- Stakeholder List, Map, or Personas (p. 344)
- Survey or Questionnaire (p. 350)
.3 Requirements Life Cycle Management
The architectural nature of the business intelligence discipline requires establishing the infrastructure capabilities in the solution. This can introduce structural dependencies within the solution, particularly where delivery is phased, that affect the prioritization of individual business needs. It is often possible to achieve efficiencies by implementing related requirements at the same time.
BABOK® Guide Techniques
- Item Tracking (p. 294)
- Organizational Modelling (p. 308)
- Prioritization (p. 311)
- Reviews (p. 326)
- Roles and Permissions Matrix (p. 333)
- Stakeholder List, Map, or Personas (p. 344)
- Workshops (p. 363)
.4 Strategy Analysis
Business analysts can use high-level conceptual data models to map the current state of corporate information, to identify information silos, and to assess their related problems and opportunities. Organization Modelling can be used to evaluate any current data management infrastructure, such as metadata management and data governance.
In defining the future state strategy, business analysts can use high-level models to map the architecture for data storage and for data conveyance and transformation:
- Logical data models: provide a static view of the solution architecture, representing the information portal that connects the sourcing of operational data inputs with the delivery of the business information outputs.
- Data flow diagrams: are commonly used to map the dynamic aspects of the solution (data-in-motion) and to identify other architectural constructs such as latency and accessibility.
- Decision models: are useful for defining how relevant business decisions are made and where and how data analytics can be effectively used to meet these needs.
- Physical data models: show the implementation environment including the data warehouse and data marts.
The extensible architecture provided by business intelligence solutions can support incremental implementation across different functional areas of the business. Business analysts can define change strategy options based on business needs and priorities, impact on the business operations, and the usability of existing infrastructure components.
BABOK® Guide Techniques
- Backlog Management (p. 220)
- Benchmarking and Market Analysis (p. 226)
- Brainstorming (p. 227)
- Business Rules Analysis (p. 240)
- Data Flow Diagrams (p. 250)
- Data Modelling (p. 256)
- Decision Analysis (p. 261)
- Decision Modelling (p. 265)
- Document Analysis (p. 269)
- Estimation (p. 271)
- Focus Groups (p. 279)
- Functional Decomposition (p. 283)
- Glossary (p. 286)
- Organizational Modelling (p. 308)
- Risk Analysis and Management (p. 329)
- Root Cause Analysis (p. 335)
- Stakeholder List, Map, or Personas (p. 344)
- SWOT Analysis (p. 353)
.5 Requirements Analysis and Design Definition
When modelling and specifying back office data capture and storage requirements, business analysts use specific data-oriented modelling techniques such as Data Modelling, Data Dictionary, Decision Modelling, and Business Rules Analysis.
Models of an existing system’s data help to define data availability and identify redundancies, inconsistencies, and data quality issues. Where existing systems documentation is non-existent or out of date, reverse-engineered modelling can be a substantial component of work, and frequently requires collaboration with technical experts such as database administrators and application programmers.
A future state data model demonstrates how the source information is generically structured in the proposed solution. The overall transformation process is commonly modelled using Data Flow Diagrams to illustrate the management of latency and accessibility requirements in the solution. Business analysts define specific business rules for data integrity checking and for data transformation.
For modelling and specifying front office information outputs, business analysts:
- analyze existing reports to determine if they are candidates to be replaced or repaired with business intelligence outputs, and
- use business intelligence capabilities such as ad hoc queries, data mining, and complex event processing to identify and specify the content and format of new business intelligence outputs.
Business analysts are involved in assessing the capability of a proposed solution (typically a commercial off-the-shelf software package) in respect of the specified requirements. In the business intelligence context, these include functional requirements such as self-serve facilities, data analytics tools, data presentation tools, drill down capabilities, and non-functional requirements related to issues such as data quality, data latency, and query performance.
.6 BABOK® Guide Techniques
- Acceptance and Evaluation Criteria (p. 217)
- Balanced Scorecard (p. 223)
- Business Rules Analysis (p. 240)
- Data Dictionary (p. 247)
- Data Flow Diagrams (p. 250)
- Data Modelling (p. 256)
- Decision Modelling (p. 265)
- Document Analysis (p. 269)
- Functional Decomposition (p. 283)
- Glossary (p. 286)
- Interface Analysis (p. 287)
- Interviews (p. 290)
- Metrics and Key Performance Indicators (KPIs) (p. 297)
- Non-Functional Requirements Analysis (p. 302)
- Observation (p. 305)
- Organizational Modelling (p. 308)
- Prioritization (p. 311)
- Process Modelling (p. 318)
- Prototyping (p. 323)
- Reviews (p. 326)
- Scope Modelling (p. 338)
- Sequence Diagrams (p. 341)
- Stakeholder List, Map, or Personas (p. 344)
- State Modelling (p. 348)
- Use Cases and Scenarios (p. 356)
- Vendor Assessment (p. 361)
.7 Solution Evaluation
A common enterprise limitation with the introduction of a business intelligence solution is the under-utilization of the information resource and analytic functionality that the solution provides. Stakeholders who are not familiar with the capabilities of business intelligence might focus on simply replacing or repairing existing information outputs. Business analysts explore and evaluate opportunities for additional value that are enabled by a business intelligence solution.
.8 BABOK® Guide Techniques
- Acceptance and Evaluation Criteria (p. 217)
- Balanced Scorecard (p. 223)
- Business Rules Analysis (p. 240)
- Data Flow Diagrams (p. 250)
- Data Modelling (p. 256)
- Decision Analysis (p. 261)
- Decision Modelling (p. 265)
- Estimation (p. 271)
- Focus Groups (p. 279)
- Functional Decomposition (p. 283)
- Glossary (p. 286)
- Interviews (p. 290)
- Item Tracking (p. 294)
- Metrics and Key Performance Indicators (KPIs) (p. 297)
- Observation (p. 305)
- Organizational Modelling (p. 308)
- Prioritization (p. 311)
- Process Modelling (p. 318)
- Risk Analysis and Management (p. 329)
- Stakeholder List, Map, or Personas (p. 344)
- Survey or Questionnaire (p. 350)
- SWOT Analysis (p. 353)
- Use Cases and Scenarios (p. 356)
- User Stories (p. 359)
- Vendor Assessment (p. 361)
