Business analysis for business intelligence initiatives requires a very specific approach, and a lot of insight into the target architectures, the business intelligence approach and the roles of change management and quality control in these environments.
Background knowledge
For business analysts to come up with useful business requirements - which, in the end, will be measurable - they have to be very aware of the target technical and informational architectures that they are analysing for. On completion of the requirements, a data modeller and ETL programmers (among others) have to be able to take the requirements and use them as input for their specifications. If the authoring business analyst is not aware of the target environment, the requirements can easily be incomplete or inappropriate. For example, without awareness of the technical architecture, how can the business analyst poll the business for data availability and data delivery time-scales? Or how can they discuss data quality feedback cycles?
Similarly, the business analysts must participate in an iterative development and delivery approach. The deliverables of their analyses must cater for the specifics encountered in a fast-cycling business intelligence program`s methodology. A totally "independent" document of requirements would just not be useful enough.
An approach often used in business intelligence initiatives is to "fetch one and all" from the source system. For example, if a particular business unit requires some product information from a particular source system, the approach is generally to "fetch" all the product information from that source system, while "you`re there anyway" to avail that information for future initiatives. Although this should not necessarily affect the requirements signed off by the business unit, the business analyst must be aware of the implications this may have on the initiative at hand, as well as on other parallel initiatives.
Analysis approach
The approach used to drive out business intelligence requirements are quite different to that used for operational systems. This is done by questioning the business users as to what are the key focus points and objectives of their business area. The business users must be questioned to determine which measurable quantities they use or would like to use in their decision-making process. After identifying these measures, it must be determined from which angles they would like to investigate these measures, and by which sub-components they would like to analyse it. For example, salesmen typically like to analyse sales data per product (product group, product itself, colour, size, etc.), per geographic region (country, state, province, city, suburb, etc), and per time period (year, quarter, month, week, weekend and day).
During this step, the following (among others) should be documented:
* The objectives of the business units and the objectives required to be satisfied by the project.
* The information required to support those business units, and what decisions are made, based on that information.
* The measures they are interested in analysing, as well as the dimensions from which it will be analysed. This should include the level of detail of the measurements (also called the grain) and the hierarchies of the dimensions along which the measures will be summarised.
* A list of reports and interactive information displays required.
* Data usage, security, availability and data access requirements.
* Data analysis and data mining requirements.
* Metadata requirements - which should tie in with architectural standards.
* Data quality requirements.
* Required response times and performance criteria.
* Success criteria for evaluating the success of the initiative.
Change control
It is crucial that change controls be considered right from the business requirements analysis. A big problem encountered in many organisations is that new functionality or changes made to the operational systems are not fed through to the business intelligence delivery mechanisms until after the new or changed operational components have been released to the business. Of course, the business then immediately expects management information on these components, but that`s only when the BI team can start analysing these requirements, let alone implement the solution.
Good change control procedures dictate that the BI business analysts be involved right from the start in any operational analysis activities. In this way it can be ensured that the required BI changes are specified and subsequently implemented in time with the operational components. However, to get this right necessitates good communication between the operational and BI teams - especially between the business analysts.
Summary
Business analysis for business intelligence initiatives require insight into the process and architecture and in-depth knowledge of the approach how to draw the requirements from the business - especially if the business is not sure what its informational requirements are. It becomes the business analyst`s responsibility to ensure the business` requirements are drawn out, documented and cross-checked.
Business analysts can play a major role in ensuring the change controls between operational systems and BI initiatives are in place and are followed correctly.
One cannot merely re-deploy an operational system`s business analyst into a BI initiative, even if they know that part of the business intimately, without first providing them with the necessary training and background on what is required.
Share
