Knowledge Bi Lifecycle

8/13/2019 Knowledge Bi Lifecycle

1/39

we transfer data to knowledge

Business Intelligence

Project and Operations Lifecycle

Business Intelligence

Business intelligence describes the enterprise's ability to access data and explore information(often contained in a data warehouse) and to analyze that information to develop insights andunderstanding, which leads to improved and informed decision making.

K. Harris, H. Dresner, Gartner Group

Business Intelligence Platform

A business intelligence platform supports indi-vidual end users with reporting on demand,giving them fast and easy access to a unifiedbusiness related reporting model thru analyticalapplications built for interactive standard reportsand ad-hoc reporting.The data extraction from all relevant sources, itscontent verification and integration into the re-porting model is updated thru automated back-ground processes (ETL).


2/39

Business IntelligenceProject and Operations Lifecycle1.0 2/39

VERSION 1.0

FILENAME KNOWLEDGE_BI_LifeCycle_ver1_0.doc

REVISION HISTORY

VERSION DATE AUTHOR COMMENT

0.8 05.08.2009 Michael Brnnimann Created

0.9 12.08.2009 Michael Brnnimann Draft to first review/finalization0.9 14.08.2009 Michael Brnnimann User Interactivity >> Information Scope

1.0 18.08.2009 Michael Brnnimann Final ReviewInitial public version 1.0


3/39


Management Summary

This document provides an overview about the different key aspects, which are crucial for asuccessful implementation of a corporate business intelligence solution. Next to professionalproject management with a strong corporate sponsorship, the proper assessment and envision-ing of todays and potentially future business requirements is the key driver and thereaftermeasure of success towards a sustainable solution.

Next to the conceptually comprehensive approach, there exist a few potential shortcuts, whichhelp to reduce times and costs especially for an initial release. But there are also common pit-

falls, business intelligence initiatives should be aware of to avoid project and investment fail-ures.

The design, development and deployment of a sustainable business intelligence solution isprimarily an organizational project and not a technology driven project.Due to new and chang-

ing demands in business reporting and analysis, a business intelligence solution must be flexi-ble and scalable to be able to satisfy the business needs in short times at minimal costs.

The technology and implementation partners involved serve as enabler to achieve the businessgoals. Therefore the evaluation and selection of base components (data warehouse and OLAPdatabases, ETL tools, analytical application platforms, etc.), intermediate best-practice tem-plates (customizable data model, standard reports) and implementation partners (implementa-tion, customizing, support) must be done carefully, as they facilitate the creation of the funda-ment for a sustainable solution.

Copyright

All materials in this document are copyright of ibax AG and may not be used for any commercialpurpose without ibax's prior consent in every specific case. The materials may not be alteredwithout the prior consent of ibax AG.

Disclaimer

The information and materials provided in this document are intended to be general and do not

constitute advice in any specific case. Information provided does not create a legal relationshipbetween ibax AG and the reader and ibax does not accept any responsibility or provide anyguarantee of any kind with respect to the accuracy or relevance of information provided in thisdocument.

Trademark

The trademarks and logos of ibaxand its products are registered trademarks of ibax AG. There

is no right to use any trademark displayed in this document without the written permission ofibax AG or such third party that may own the trademarks.


4/39


Business Intelligence Lifecycle Diagram


5/39


Table of Contents

The structure and numbering of the document follows the numbering logic of the business intel-ligence lifecycle diagram as shown on the previous page.

A short introduction, feasible project shortcuts andpotential project pitfalls follow on the next pages.

1 Initiative 82 Planning 113 Project Management 154 Specification 165 Evaluation 21

5a Partner Evaluation 215b Product Selection 22

6 Business Intelligence Platform 266a Architectural Components 266b Information Scope 316c Reporting ModelDesign & Implementation 336d Analytical ApplicationDesign & Development 34

7 Final Assurance 358 Deployment 359 Operations 36

9a Production 369b Outsourcing 36

10Growth 36

Further Reading

The Data Warehouse Lifecycle Toolkit, 2nd Edition from Ralph Kimball, Margy Ross,Warren Thornthwaite, Joy Mundy, Bob Becker; publisher Wiley & Sons, January 2008ISBN: 978-0-470-14977-5 andhttp://www.lifecycle-toolkit.com/pages/index.htm

Impossible Data Warehouse Situations: Solutions from the Experts from Sid Adelman,Joyce Bischoff, Jill Dych, Douglas Hackney, Sean Ivoghli, Chuck Kelley, David Marco,Larissa T. Moss, Clay Rehm; publisher Addison-Wesley, Oct 1, 2002ISBN: 978-0-201-76033-0

Abbreviations / Glossary

Used abbreviations and technical terms are explained in the appendix.
http://www.lifecycle-toolkit.com/pages/index.htmhttp://www.lifecycle-toolkit.com/pages/index.htmhttp://www.lifecycle-toolkit.com/pages/index.htmhttp://www.lifecycle-toolkit.com/pages/index.htm


6/39


IntroductionThe Business Intelligence Lifecycle Diagram (thereafter re-ferred as LifeCycle) provides an overview about the differentaspects and major dependencies to implement a sustainablebusiness intelligence solution.

Independent of the solution scope, especially also for small andeasy looking BI projects, the use of the LifeCycle is recom-mended at least in the context of using it as a checklist, to make

sure all areas are considered. Because a business intelligencesolution should be understood as a multi-release process cycle,the different aspects have different importance depending on itsrelease level. This means, not all aspects must always be cov-ered in full detail, but you have to ensure you dont run into u n-planned efforts for future releases or in worst case have to con-sider re-building the whole solution from scratch.

Especially for an initial releasethe phases of the BI initiative, theidentification and specification of business requirements and thedesign and development of the reporting model are of key im-portance, even if your first release is just focused on quick wins

or intends to serve a single business unit or business purpose.

The left handed project time diagram in standard work unitsvisualizes a typical relation of the different efforts regarding itsrelease cycle. A standard work unit is a multiple of days de-pending on the size of the project. Depending on the existingskills and experience of your internal resources, for an initialrelease its advisable to involve project and product independentBI expertise in form of approved BI consulting specialists.


7/39


ShortcutsThe rollout of an initial release can be significantly reduced (by 30-50%; as indicated by theyellow colored areas in the project time diagram on the previous page), in case there is only onedata source and there is no need for a data warehouse with a corresponding ETL processes.

Further cutbacks in the specification phase and the design and implementation of the reportingmodel usually result in higher development efforts for the initial analytical application and all itsfuture enhancement cycles, because missing functional features of the reporting model have tobe covered by specific functionalities of the analytical application (i.e., date series, date aggre-gates).

Potential Pitfalls

The most common potential pitfalls for causing poor use and low level of acceptance of thedeployed business intelligence solution up to complete project failures are:

Prejudiced opinion of BI initiative, that a successful BI implementationis solely a question of a good product selection

Missing definition of project sponsorship and steering committee

Insufficient or exceeding decision taking involvement of project sponsorship and steering committee

Inadequate (unrealistic) project scope setting

Inadequate project cost/time estimates

Missing or insufficient early warning system (issue tracking) and project progress monitoring

Inadequate handling of moving target situations(change of project goals during project progress)

Insufficient skill set, project understanding or goal focused commitment of project team members

No or inadequate internal communication towards all potential recipients

Missing or poorly maintained library of corporate terminology

Missing or poorly execution of gathering and specifying the business requirements

Missing identification and addressing of existing compliance requirements

Insufficient business context related BI expertise of project management or design & dev. partner

Insufficient reflection of BI vision in reporting model and analytical application

Poor or even partially invalid source mapping definitionsMissing definition, communication and deployment of business reporting processes

Missing or poorly execution of the final assurance prior the platform deployment

Missing or insufficient involvement of IT operations

Missing or inadequate end user training

Missing or poor quality assurance process

Platform doesnt meet the required date timeliness

Platform doesnt meet the specified query and processing performance

Despite or because of all known potential pitfalls an initial releaseof a business intelligence solution can become a success story!


8/39


1 Initiative

The objectives of this phase are to build awareness about the potential of business intelligencesolutions in the context of the own corporation and to form the organizational key drivers, whichhelp to stay on the track towards a successful business intelligence implementation. With everymajor change in corporate strategy, or change of business fields and their critical success fac-tors, or at least every 3-5 years, the established BI initiative should be reviewed and revisedregarding its organizational setup and its mid-term vision.

Sponsorship: The project sponsor should preferably be the most senior person with widelyaccepted leadership, which itself also is direct or indirect user of the analytical business report-

ing results. Usually its a non-IT person from the top management (CEO, COO, CFO) or busi-ness line middle management (Controlling, HR, Sales, etc.).

Steering Committee:A well constituted committee (3-7 people) ensures that all potential inter-ests of building, operating and using a business intelligence platform are represented. Togetherwith the sponsor they form the backbone of the project management. The committee reviewsthe project progress on a regular base (weekly/monthly, milestones) and participates and sup-ports the project manager and sponsor in decision taking questions. Depending on the projectscope the committee may be extended during the phases of planning and business requirementdefinitions. Particularly in the phase of model and application detail specification and in case ofmoving target situations (change of project goals during project progress), the committeesfeedback is a crucial indicator for a future solutionsacceptance and project success.

Project Manager:The project manager should be a person with proved project managementexperience and strong skills in communication, people and conflict management. The projectmanager may be assisted by an independent BI specialist to cover the necessary BI back-ground expertise.


9/39


Vision:The envisioning task regarding the possibilities of a business intelligence solution helpsto explore all potential fields which may be involved in a long-term, future business intelligencesolution, which empowers users to create and analyze reports on demand themselves. Thisvision shall be created independent of cost/benefit considerations and other existing or potentialconstraints.

Target Audience Biz Area Content Granularity

Key Customers / SuppliersBank / Investors / M&AAuditing & Compliance

Chairman/BoardTop Mgmt (CEO, CFO, etc.)Middle Mgmt (Sales, HR, Prod-uct Mgmt, Production, etc.)

Operational Monitoring andBusiness Applications, etc.

X

Finance

HR

Sales

Production

Inventory

others

X

Dashboard/Cockpit

Standard Reports

Information Lookup

Ad-hoc Reporting & Analysis

Recons. Customer Base

others

X

By Month/Day/Hour

By Customer

By Product

By Cost Account

By Shopping-Basket

others

A major advantage of business intelligence solutions is to provide a source independent unifiedview (single version of truth) on aggregated quantitative data with excellent data access perfor-mance and nearly unlimited user interactivity functionalities.

Non-quantitative data and interactive invocation of the source systems can be embedded in a BIplatform up to a certain extent, whereas detail reports (fact sheets) on non-aggregated transac-tion data (i.e., invoices) and looking up item details bound to specific visualization/layout rules oritem specific value calculations (i.e., customers, products, accounts) are preferably created andretrieved thru their source application.

There is no strict line between what kind of information should be retrieved thru a business intel-ligence platform or thru its source applications, as the BI platform usually hosts the same levelof detail (granularity) as the sources. The resulting blurry borderline is defined by the question ofcost-effectiveness about re-creating application logic of the source application on the businessintelligence platform, which primary purpose is to create reports on aggregated data.

Multi-lingual Support: Its possible to create a multi-lingual business intelligence platform. But

for reasons of cost-effectiveness and reduced implementation, deployment, documentation andmaintenance costs its recommended to stay with one primary language, as it creates about30% extra costs to the overall total costs.

Multi-lingual solutions keep the technical implementation in the primary corporate language,whereas the analytical application applies different alternative translation schemas (languageand/or business terminology) for all visible reporting model metadata. Additionally, for all visiblereport aspect items (product catalog, geographical names, chart of accounts, etc.) the datasources must provide item specific translations.

Alternatively a limited multi-lingual approach might be appropriate, where translations are li-mited to the visible metadata in the analytical application and related documents (incl. onlinehelp).


10/39


BI as Evolution:All involved people (project, source data provider, end user) must understandthe cyclic nature of a business intelligence solution and know the importance of building a solidfundament for a successful and sustainable use of future solution releases. Furthermore theyappreciate, that a BI platform may evolve with the future business needs, but recognize that noteach release can address all needs from the beginning at the same time.

Business Case 4 BI: Based on the corporate related vision and the rough estimate of costs,potential savings and other non-financial benefits (strategy, tactical, operational), a 2-5 pagesbusiness case must be established to verify potential cost-effectiveness for a drafted mid-term(3-5 years) solution scenario. Following indicators may be used to create a break-even estimatefor an envisioned solution scenario:

Companies with more than 100 employees

Companies with more than 20 report explorers and analysts (controlling, HR, sales)

Companies with more than 15-20 subunits/branches

Companies with more than 1000-4000 products, customers, and/or suppliers

Companies with high transaction data volumes (> 300000 -500000 transactions / year)

Companies, which have to integrate data from more than 3-5 different sources

Companies with existing business applications platforms (ERP/CRM, etc.) with no or notsatisfactory reporting functionality, where initial implementation costs (license / customiz-

ing) are above 150250 K EURCompanies where the monthly time spent to prepare standard reports (data collection,data consolidation and reconciliation, report creation) exceed 15 work-hours.(This time does not include the time used to analyze and interpret the reporting results.)

Companies with strong demand for analytical reporting, complex financial consolidation,detailed cost/profit analysis, having many different standard reports, have frequentlychanging reporting needs, ask for interactive ad-hoc reporting and analysis.

Quick Wins: Identify the most wanted and urgent business related reporting and other needs,which may be addressed by the targeted business intelligence solution already in an initial re-lease (low hanging fruits).


11/39


2 Planning

Scope: The sponsor, project manager and steering committee define the scope (audience,business area, content, and time frame) for an initial release based on the preliminary estab-lished BI vision and identified quick wins. The defined scope for a platform release should beachievable within the next 6-12 months time.

In the context of the defined scope, the steering committee may be temporarily extended bycontext related members. In case of a new or adjusted BI vision the subsequent phase of identi-fying the high level business requirements has to cover a mid-term range for all aspects ad-

dressed by the BI vision.

Project Team:The design, development and deployment of a business intelligence solution arean interdisciplinary challenge.More than for the constitution of the steering committee, it is im-portant, that all team members have next to a global understanding of the LifeCycle a specificstrong conceptual and technical skill set regarding the related components. But they must un-derstand themselves as team member always aiming and contributing to achieve the overallproject goals.

An existing member of the steering committee cannot be a member of the project team andvice-versa.Specialists not having the required soft skills (language, culture, tolerance, and ac-

ceptance) should not be member of the core team, but may get involved to perform very specifictasks upon request.

For the initial implementation of a sustainable business intelligence solution the core projectteam (5-10 members) often implies the involvement of external people from different compa-nies, who bring in the required in-depth expertise. For development and deployment tasks, themembers of the core project team may be supported by further assistant personnel (5-20 assis-tants), which are not member of the core team. The project core team has to cover followingroles/skill sets:

a) Best-practice business reporting including KPIs (key performance indicators)and corporate reporting and escalation processes

b) Business terminology and naming rulesmaintaining an object metadata repository

c) Assurance of data quality and legal compliance, maintenance of data access security

d) BI platform operations (incl. data processing, backup/recovery)e) Deployment (rollout, training, application support)

f) SQL data warehouse environments and ETL processes

g) OLAP database environments and enhanced cube design

h) Design & Development of analytical applications

i) Source system data architecture

j) Master data management

In a typical setup, the areas a) to e) are usually staffed with internal people, whereas for aninitial release, the remaining areas are assigned to external experts, which join the team at alater stage. They are assigned as result of the evaluation of the design and implementation

partners. For later release cycles, the involvement of external specialists may be significantlyreduced, as the initial release should also provide an initial knowledge transfer and documenta-tion to operate and extend the platform without or minimal external support.


12/39


Volume Assessment:The assessment is focusing on the involved data sources with their datavolumes and the target standard reports. Each volume assessment (for data sources and stan-dard reports) should be done in two variants, where the first one just relates to the current

project scope and the second one refers to the potential context of fully outlined BI vision. Theassessment results are an indicator for the mid-term size and complexity of the solution andhelp to verify the identified budget costs and savings.

SourceID DescriptionContact,Owner

AccessPath

TimeZone

AccessFormat

Data AreaCurrentVolume

AnnualGrowth

Modifi-cations

NAV

Navision ERPVx.0

for productionand trade

Mr. Sample

LAN:

Server Instance:NAV\SQL2005

GMT+1

Microsoft SQL

Server 2005

Transactions

ProductsCustomers

3.0 Mio.

40001200

0.5 Mio.

100300

5%

30%20%

ABACUSAbacus ERP2008 for HR

Ms. NiceLAN:ABAC_HR

GMT+0 Pervasive SQL

Time-Trx:Recruitm.-TrxUnitsPersons

1000001500

50400

350100

520

5%5%

10%30%

AVALOQAvaloq BankingSystem

Ms. Money-penny

LAN (VPN):AVLQ

UTC Oracle 10gTransactionsProductsCustomers

5.0 Mio.10000

300

1 Mio.50030

5%15%20%

BudgetBudget forFinance andCost Profit

Mr. AccountLAN: \\GLOBAL\Finance\Budget

GMT-1MS Excel2008

TransactionsAccounts

5000800

500050

25%10%

FX_RatesForeign Ex-change Rates

Mr. Contact;ContractID:

Oanda_xy

FTP://ftp.oanda.com

UTC CSV FileRatesCurrencies

160000250

800002

25%3%

Explanatory notes:

Volume As sessment for Data Sources covers internal & external sources:ERP, CRM; budget-ing/planning tool; market quotes (foreign exchange, stock quotes), market poll/survey, phone/ ad-dress directories, zip-codes; item specific background information (GTIN/EAN product databases,company registrations, credit ratings).

SourceID:is assigned for easier reference.

Descr ipt ion:contains information about application, version, content and primary usage.

Contact, Owner:contact information (technical, responsibility, data ownership)and contract reference details for external sources.

Access Path: information about from which origin and how the data can be retrieved.

Time Zone:data source related local time zone. Indication for potentiallyrequired time zone / daylight saving adjustments during ETL process.

Access Format :Database/file format and version. Note: despite its on electronic nature also purelypaper-based sources should be listed, if they contain information, which is used to create reports.

Data Area:type of transactional data and primary, large context dimensions.

Current Volume:todays data volume (incl. historical data) for each data area.

Annual Growth:annual growth (net) for each data area.

Modif icat ions:annual modifications applied as percentage, multiple annual changes add up.


13/39


14/39


Savings:All major potential savings related to the defined scope are identified, quantified andweighted according to their scenario probability (worst, expected, best): work-hours to preparereports, improved bargaining power towards key suppliers and customers, ability to act in-timedue to efficient information availability and early detection of changes, reduced IT costs for re-port programming and maintenance thru end user empowerment (user interactivity), etc..

Also identified non-financial benefits should be listed. Such benefits indirectly support theachievement of the financial goals: improved bonus targeting, decreased wait time to getaccess to up-to-date reports, improved data quality, strengthened business connections to keycustomers and suppliers, tightened data access security, etc..

Budget: Establish a multi-scenario (worst, expected, best) budget estimate at full cost:

internal & external resources (time/cost), license fees, working extra-hours, hardware invest-ments, legal costs, etc. Add a surplus of 30-60% to the estimated budget for exchange rate andproduct price changes, other unknown extra expenses and moving target situations.

The break-even of savings against budget can usually not be achieved with the first platformrelease due to the initial investments (design, development, licenses) in the base platform, butshould be achieved with follow-up releases within 2-3 years after the initial BI initiative.

Communication:Define the recipients, frequency, and channel of distribution and its minimalstructural content. The communication informs about the project status (in relation to time/cost

and level of progress), recent/current activities and the next major steps. A well structuredcommunication on a regular base (monthly, quarterly) is especially useful to keep people in-formed, which are not directly involved in the current project activities. The communication alsosets the ground for a later-on smooth deployment and usually results in a higher level of useracceptance and subsequent use of the business intelligence solution.

Milestones / Reviews:Prior having established a detailed project plan, milestones should be

set for at least each project critical step: specification of business requirements, reporting modeldesign, analytical application design, development work results and the achievement of theproject goals (final review and assurance) prior deployment. The setting of the milestones isbeing agreed by the sponsor, project manager and steering committee.

All milestones related deliverables are reviewed and revised as necessary. The project man-

agement and steering committee specifies details about how to enter the next phase, whichmay include task specific details (modifications) and other constraints. The sponsor is informedabout the milestone achievement and how to enter the next phase, whereas he has a remainingright of veto, but not the right to change directions (goal setting) of the project himself.


15/39


3 Project Management

The project manager and the steering committee create the initial detailed multi-phase projectplan. If required, the project manager may be assisted by an independent BI specialist to coverthe necessary BI background expertise.

The resulting project plan provides time-related information about phases, tasks/reviews, miles-tones and assigned resources and costs (task related budget) by functional roles (includinglicense and other fees). Make sure, that you also allocate 20-40% extra calendar time up fronteach milestone. Wherever applicable, the roles/tasks are assigned to the existing project team

members. This draft version must be refined as final task of the business requirement specifica-tions.

The remaining role assignments to external people will be done later after the evaluation andjob assignment to external design and development partners. In this phase its also recom-mended to re-verify/confirm and adjust the existing role/member assignments.

The project manager is responsible to track the fulfillment (deliverables) of the tasks regardingtime, working hours and running costs on a weekly base and summarize a progress/status re-port for the project sponsor and the steering committee (weekly/monthly). This summary in thesame or slightly simplified form is also an integrated part of the regular information statementsfor all potential stakeholders (internal communication). Additionally its recommended to intro-duce an early warning system in form of an ongoing issue tracking, which lists and monitors allrising (unexpected) issues, even the related running tasks are still within cost and time.

Whenever the monitored work progress on the critical path gets behind plan or the runningcosts exceed the related budget, the project manager must develop together with the steeringcommittee corrective measures and/or adjustments of the project plan, which must be signed offby the sponsor afterwards, before the suggested actions can be put into place.


16/39


4 Specification

A detailed specification of the business requirements is the key for a sustainable and well ac-cepted business intelligence solution. In case of an initial release, where its important to get thebig picture, also all future potential requirements must be collected and summarize at least at adraft best estimate level.

The data required is collected and summarized thru standardized qualitative interviews. Thestructure and content of the specific interviews and identification of the target interviewee per-sons is prepared by the project team and reviewed by the steering committee. Whenever possi-

ble, the same interview should be addressed to 2-3 interviewee persons. The interviews areconducted with the selected interviewee persons (user, legal department, IT operations, etc.)oneby-one or in a single group. The interviewer teams are made up of one content qualifiedmember of the project team and one adequate member of the steering committee.

The consolidated findings are summarized by the project team and formally reviewed by thesteering committee.An abstract version of the findings will be signed off by the sponsor and

communicated thru the regular information statement.

Whenever some requirement details of the current project scope cannot be transformed intocorresponding deliverables, the related issue must be raised from the project manager and re-solved in the steering committee. The suggested measures (adjustment of requirement detailsand/or project plan) must be signed off by the project sponsor and communicated thru the regu-lar information statements.

The following areas are the primary information aspects, which should be covered by the busi-ness requirement specifications.

Corporate Business Model:An overall business process model describes all main current and

planned standard business processes with their actors and other involved resources.In combination with known general best-practice processes, this especially helps the design anddevelopment teams to create a reporting model, which is extensible and flexible enough, tocover potential future platform releases.


17/39


Report (Template) and KPI Specification:Similar to the assessment in the planning phase allidentified reports are documented but specified in much more detail, and each report mustmandatory be illustrated with some sample reports. Understanding the underlying businessgoals of specific reports is crucial for a successful translation of the specifications into design(reporting model, analytical application). In addition to the known aspects of the report assess-ment in the planning phase the specification must cover following areas:

Purpose in depth: Identification of the underlying business goals.

Component and visualization details (pivot table and chart items).

Row, column and filtering items of visible (pivot) tables and/or hidden tables sourcing specific charts.

Complimentary background information for specific row/column/filtering items, like address, birthday,social security number etc. for person items, or company registration id, website, stock listing for or-ganizational items (corporate, supplier, etc.). These attributes may be used for special filtering, in-teractive functionality (see below) or to create item list reports.

Special report-wide calculation requirements like support of multi -currency, -scenario, -rate-types;value scales, date-series; financial consolidation (intra-group elimination / minority-handling), etc.

Special calculated report item values like percentages, key figures, forecasting calculation and sta-tistical computations.

Special item naming (terminology) of row, column or filter items or calculations.

Special interactive functionality. Most professional analytical application platforms provide followinginteractivity options by default: expand/drilldown, value filtering, sorting, and hiding empty reportrows/column. Further additional typical requirements are:

invocation of source business application (ERP/CRM), other applications (document manage-

ment system, semantic web), information services (internet) or office applications (email, etc.)reporting model related context sensitive online help

interactive lookup of background information for visible report items

Special data quality assurance requirements (if required)

Report specific query performance requirements (maximum and average in seconds)

Report specific user data access restrictions (if required)

In addition to the primarily business line driven report specifications, the report requirements forcomplimentary statistics may be specified regarding platform updating process/status, dataquality reports and end user platform usage.

The resulting reporting specifications should be checked against the preliminary assessed datasources. In cases where reports require the integration of additional data sources, consider to

postpone the specific reports for a later release or refine their specifications, so they can becovered by the available sources. We strongly discourage from adding more data sources atthis phase, as it implies additionally complexity, time and cost efforts to the current release,which are not reflected or covered by the existing budget and time plan.

For improved ease of use and collaboration aspects, its encouraged to align the identified re-ports with a collection of report templates regarding the major visualization aspects. The tem-plates also incorporate the same set of interactive functionality and follow common design prin-ciples (typefaces/fonts, coloring, and page layout settings as agreed or defined by corporatedesign guidelines).

The resulting report and template specifications, which might partially get adjusted during thedesign of the analytical applications and their standard reports, are used to review the final re-sults and serve as base to create the technical and user related report/template documentation.


18/39


Data Timeliness:Based on the required frequency for having updated reports, the overall mi-nimal update frequency for report items (products, customers, accounts, etc.) and related valueinformation (transactional data) can be derived. Theoretically its possible to build sophisticatedETL solutions, where with each load process just the absolute minimal required information isextracted from its sources.

From the point of ease of monitoring and maintain load processes, we recommend always toextract all dimensional data (=full extract of current, changed and historical data of all reportitems like products, customers, etc.) and to restrict the extraction of fact data to new andchanged data (= incremental extract of transactional data for with reduced load times).

Data Requirements: In the context of the specified reports, their update frequency and the

available data sources, the following data specific requirements regarding retrieval and storageshould be answered in a way, they comply with the mid-term BI vision. Whereas the currentimplementation release may not cover all requirements right away, the platform design and theselected products must guarantee that they can be met with future releases without the need fora re-design and/or or unforeseen product licenses.

Data persistency in a dedicated storage area (data warehouse) provides a source inde-pendent archive over time, even the genuine source systems are replaced.

Collecting processsupports full and incremental data load for better load performance.

Preservation of historical structures(organizational structures, product hierarchy, etc.),might be required by business and/or compliance, to be able to re-produce date-related,historical reports any time in the futurebased on their historical structures.

Master data managementas a functional extension of a business intelligence platform,allows a fully or partially automated alignment of different data structures coming from dif-ferent source (.i.e.; product catalogs, chart of accounts, etc.) prior its integration into thetarget reporting model. Master data management as such is not a business intelligencecore component, but a prerequisite in case of a necessary merge/integration of differentdata structures, coming from different sources. Master data management is not required,in case the data for a target data structure just comes from a single source.

Data quality assurance is usually covered by embedded rule checking mechanisms inthe ETL process (data load), which automatically generates and delivers quality relatednotifications/reports. Quality assurance can optionally be extended thru reporting modelextensions providing item related quality ratios, which can be used to generate additionalin-depth quality reports. Quality rules usually check up on invalid, incomplete, missing andoutdated data, and moreover for wrong/inadequate data context (business process).If the quality aspects refer to a specific report only, they should be detailed within the re-port specifications; otherwise they can be listed as part of the data requirements.


19/39


Performance: A good query performance for standard reports is crucial for user acceptanceand report usability/interactivity. A stable superior performance (especially on platforms withgrowing data volume and user audience) is primarily a question of a good design and code de-velopment of the analytical application and the underlying reporting model. Using more powerfulhardware may help to improve the performance additionally, but usually only if the overall BIsolution can make use of the additional resources.

In some cases low bandwidth network connections may cause bad query performance. Thiscan either be addressed thru increased bandwidth, distributed copies of the query platform dataand/or thru giving the users access to the analytical applications thru hosted remote sessions(terminal services, Citrix, etc.).

Next to the query performance, the background processing performance relates to the dataupdating processes of a business intelligence platform. Processing performance must stay with-in the required date timeliness (as defined by the business) and moreover leaf enough room forother IT operations (backup and regular maintenance activities). Existing query performancemay be improved thru performing pre-calculations and building data aggregates during the pre-liminary data processing. But be aware, that using such features increase the resultingprocessing load times.

Query performance specifications should at least differentiate between standard reports and ad-hoc queries. They required answering times (average and maximum times in seconds) shouldbe reasonably set and reflect how often and intensive the reports are used. For users using theplatform during data processing times, (working off the regular office times or accessing fromdifferent time zones) the (reduced) response time requirements should be defined separately,

as such activities may interfere with the resource consumption of background load and main-tenance processes. As the different reports can be of quite different complexity, its advisablealso to specify required response times for each report separately.

The maximum background processing time allowed (incl. allowed scheduling) must fit into theexisting IT operations plan. Existing maintenance schedules and other constraints should bedocumented.

System Availability and Outage:Depending on the user audience and their working times the

required system availability (weekdays, hours of day) for query access must be defined. Also amaximum tolerance time (hours or minutes) for a system outage of the business intelligenceplatform should be fixed, as this implies platform related measures (hardware, software,

processes) to reduce the risks and/or support specific recovery times.

User Data Access Security:Next to general restrictions, report related restrictions should bedefined at report specification level. Due to the nature of the multidimensional reporting model,which is a core element of every business intelligence solution, the various report specific re-quirements are later translated into reporting model related rules. This guarantees user relateddata access control at the platform data level for all potential analytical applications, standardreports and ad-hoc queries alike. Wherever possible, data related access rules should be direct-ly extracted from existing data sources and integrated in the logic of the BI platform security.

Despite its possible to add complex and tight security mechanism, for the cost -effectiveness ofan initial release and its future maintenance, its recommended, that the really required restric-tion rules should be evaluated carefully and be kept as simple as possible.


20/39


Compliance:Depending on the usage purpose and context of the specified standard reportsand ad-hoc queries, additional constraints may have a significant impact on the design of thereporting model, the platform technology, the ETL process and the analytical applications. Suchconstraints are usually given by external laws, regulations, reporting standards or other internalrequirements (SOX, Basel II, IKS; MiFID, ISO, IFRS, data privacy, external auditing, etc.).

All such constraints may add a high degree of extra complexity (plus costs and times) to a busi-ness intelligence solution. Therefore we encourage verifying such constraints carefully in thecontext of the real usage and purpose of the specified reports. If only a few reports underliesuch constraints, consider creating the reports in its genuine source application. Such reportsare usually of a more static character and dont take advantage of the integrated interactivity ofa business intelligence solution.

Process Specifications: As the business intelligence platform provides a unified business-

related reporting model for all standard and ad-hoc reports, also all related organizationalprocesses should be documented and provide information about the default process with itsworkflow tasks, actors and involved resources:

Business reporting at strategic, tactical and operational level(incl. escalation and linkage to connected processes like planning and publishing)

BI platform operations

End user training & support

Data quality assurance (incl. escalation and linkage to data providers)

Prototyping and Proof of Concept:Depending on the complexity of the resulting requirementspecifications, it might be appropriate to ask the design and development team(s) to provide aprototype. Such a prototype is used to verify specific functional and conceptual topics and toreview/adjust the requirement specifications and/or project scope depending on its outcome.

In case of an initial release with having external BI specialists involved, a prototype for a pre-agreed lump-sum may also facilitate the evaluation process for design and development part-ners and/or a related product selection.

The work results of the prototype can be taken into the design and development phase as draftconceptual input only and which explicitly excludes program code and similar documents.


21/39


5 Evaluation

5a Partner Evaluation

Based on the collected BI vision, the volume assessments and the specified business require-ments, the project team must be completed. For an initial release people covering followingtopics, must be recruited internally and/or externally:

a) SQL data warehouse environments and ETL processes

b) OLAP database environments and enhanced cube design

c) Design & Development of analytical applications

d) Source system data architecture

e) Master data management (if required)

As mentioned earlier, its important, that the new members are real team players and fit well intothe overall team. Non team conforming specialists may be called in temporarily, to cover specif-ic and well defined tasks. Depending on the overall skill set covered by the new team formationand the individual performance of the existing team members, it may be appropriate to replacesome of the existing team members.

The member and/or partner evaluation should be focused on the area specific in-depth know-ledge and experience for conceptual design, technical development and implementation in

combination with the product related expertise. Due to the nature of the wide field of requiredexpertise, often a combination of several partners and products provide the best results. Follow-ing selection criteria should be considered as well:

Existence of area specific solution templates(reporting model, ETL workflows, analytical application,data source model mapping) or potential team members have proven experience by reference toother similar productive solutions. Note: Good quick-fitting solution templates, help to reduce timesand costs for design, development and implementation.

Ask for details about theirpartner networkgiving them quick access to peer-specialists on demand.

Make sure, that a potential contract can be cancelled within a short notice time, if deliverables dontmeet the agreed specifications by content and/or quality, or are not in time.

For negotiating prices, ensuring continuity and further contract details, you may also consider:

The overall project goals and deliverables must be specified.Make sure the deliverables align to existing project phases and milestones.

Ask for deliverable related fixed prices (supporting different (budget) scenarios, incl. expenses)and its underlying calculation considerations, estimated work times and personal availability.Note: realistic fixed rate estimates can only be done on the base well documented detailedspecifications of the preceding phases related to the different budget scenarios.

Alternatively ask for variable rates and deliverable related target time/cost estimates.Include bonus/malus payments on previously agreed target time/cost estimates inthe contract provisions. This enables you to split exceeding costs or savings.

Define apredefined escalation process for potentially moving target situations,so existing contracttask agreements and the project plan (incl. budget) can be reviewed and adjusted in time.

A (time) limited warranty on deliverables and invalid applications behavior applies, which includescorrective measures in time, but excludes any liabilities regarding data loss or other damages.

The regulation about the intellectual property and program code of the solution must ensure thecompany either owns the code or the code provider fixes bugs and adds minor extensions withina reasonable pre-defined time at predefined rates (if not covered by the warranty).


22/39


5b Product Selection

Depending on the BI vision and current project scope some or all of following architectural com-ponents are necessary to form a business intelligence solution addressing all the specified re-quirements. BI products as such must be understood as pure solution enabling technologies,which provide specific functionalities in the context of the architectural components of a BI plat-form. Details about the functions covered by the different architectural components can befound in the next chapter.

The key success factors of a sustainable business intelligence solution are:

Corporate business intelligence vision

Business requirement specifications

Business intelligence expertise (design & development)

Unless there is a strong strategic and sustainable case for a specific technology vendor, whichalso fully complies with the mid-term BI vision, then we urge to focus on well established non-proprietary products with open, documented data access interfaces supporting database queryand communication industry standards like

SQLfor DWH databases

MDXfor OLAPdatabases

ODBC/OLEDB andXMLA

for database communication

allows the (re-) combination ofproducts from almost any vendor

ensures access to a vastcommunity of specialists andproduct in-depth knowledge

minimizes product relateddependency from designand development partner

Further general selection criteria are

scalability and high performance without volume degradation

system stability, high availability and fast recovery

integrated user data access security

multi-lingual support (if required)

manufacturer product support

product market share as indicator for

high product acceptance by market and end users

lower adjustment costs for new employees already familiar with the product

easier recruitment of IT staff having existing product knowledge

pricing (license and annual maintenance fees by: platform, modules, user volumes by theiruser profile (reader, explorer analyst), server CPUs and/or data volume)

continuity of core product developmentproduct is already in use or already covered by existing license within company

or there exist other internal restrictions regarding product / manufacturer selection

product related expertise of selected design & implementation partner


23/39


Related to the different architectural componentsadditional criteria may apply:

Server

Server hardware:scalable hardware (CPU, memory, disk-array). Depending on the work-load, the DWH and OLAP database may be run on own dedicated servers. In case of veryhigh volume query loads, the parallel access to multiple copies of OLAP databases maybe required.

Server OS:well performing OS (Operating System) supporting scalable high end server

hardware (multiple CPU, 64 bit, SAN, fiber optic); supported by SQL and OLAP engine

BI Platform (Software Components)

DWH database engine: server scalable core; support of SQL object / query standardsand other de-facto features like index, triggers, stored procedures, user-defined functions;integrated user data access security.

ETL workflow engine: supports parallel object processing on DWH database and pro-vides standard interfaces to business application source data and relational and non-relational data formats of other vendors (incl. CSV/XML-files).

OLAP database engine:server scalable core; well performing, reads data from any SQLsources and support of MDX object / query and XMLA communication standards

with integrated user data access security.

Analytical application(s):

Other products and add-ons:pre-defined business related templates for reporting mod-els and analytical applications, and value-adding product add-onsfor selected DWH andOLAP products may significantly help to reduce times and costs for an initial release. De-pending on the data integration requirements, dedicated master data management solu-tions may facilitate the development of related integration activities.

Network and Other Components

Network: low bandwidth networks may require that analytical applications can only beused as web application and/or they are made accessible thru remote applicationsessions, hosted on a Citrix or Terminal Service server.

Client hardware: the appropriate configuration of the client hardware depends on thenetwork and the usage of the analytical application (web versus desktop).

Other solution related components:data source system, web server used by analyticalapplication(s), corporate file share for report sharing and/or access to reporting templates;internet, office applications, source system and document management system called byclients thru invoking functionality of the analytical application, etc..


24/39


Explanatory notes regarding the evaluation of analytical applications

There exist only a few established manufacturers for DWH and OLAP database engines and/orETL workflow engines. But the area of analytical application platforms is a fast growing marketwith a large variety of manufacturers and vendors. But remember, nevertheless the analyticalapplication is the most visible part of the overall BI platform to the end user,the business con-

tent and data structures of the report come from the underlying DWH and OLAP sources. Incombination with a unified reporting model, these, and not the analytical application as such,are the elementary sources which support easy interactive use and fast data query perfor-mance.

A BI initiative just focusing a nice looking dashboard /cockpit application is like buying an emptyskyscraper with a nicely furnished top floor, but with no elevator and no electricity, water andheatingstanding on a weak fundament.

The different user profiles (reader, explorer and analyst) have different needs towards an ana-lytical application. A carefully selected mix of alternative products accessing the same datasource (DWH and/or OLAP) often provides the best result regarding the user specific applica-tion skills and the application related license fees.

Depending on the specific user profile following sample criteria(with focus on Analysis Services OLAP databases) may apply:

Support of OLAP (MDX/XMLA) and DWH (SQL/OLEDB/ODBC) sources (for numeric and text data)

Centralized definition of corporate visualization templates for analysis, printing and publishing(content/object placement, fonts, colors, logos)

Repository based multi-lingual / business terminology translation of reporting model metadata

The existing metadata model incl. description properties is fully accessible for end users(cubes, measures, dimensions, attributes, hierarchies, levels)

Running queries may be cancelled

Existing reports can still be opened gracefully, also in case of changes in the reporting model

Export to Excel and PDF

Support for multi-scenario data entry with value distribution support for budgeting and planning

Support of cube and application based calculated members and dynamic named sets, whereas ana-lytical application provides own centralized library to access and administrate the specific definitions

Support of StrToMember, StrToSet and StrToValue MDX with specific solve order / cube scope

Support of cube based actions: rowset, dataset, html, url, drillthrough

Support of customizable reporting model sensitive context help

Support cube cell level properties (colors, value formatting)

Dimension member properties can be made visible

Support of enhance visualizations (waterfall graphs, sparklines/sparkbars)

Display of inverted dimension hierarchies (parent member stays at bottom of expanded subtree)

Collaboration support for adding/sharing report, dimension, and cell level annotationsCollaboration support for creating, storing and sharing personal reports / analysis snapshots


25/39


Following table gives an overview about the architectural components and a selection of themajor BI technology manufacturer and products. Good sources to get more vendors unbiasedinformation about the different OLAP related products and their market shares can be found onwww.olapreport.com,www.gartner.com,www.barc.de,andwww.idc.com.

Hint: many comparisons found on the market do no clearly distinct between the different archi-tectural components, which sometimes makes comparisons more confusing than they help.

Manufacturer Product

Architectural Components

CommentDWH ETL OLAP

AnalyticalApplication

www.microsoft.comSQL Server Suite(includes all othercomponents)

SQL ServerIntegrationServices(SSIS)

AnalysisServices(SSAS)

Reporting Services(SSRS)

Comprehensive flexible Suite, butno standard solution templates.

OLAP reporting and further solutiontemplates are supported by a vastcommunity of product vendors(incl. Open Source).

www.oracle.com BI SuiteOracleDatabase

DataIntegrator

OLAP orEssbase

Answers,Publisher

Comprehensive mixed Suite of manymerged products (thru acquisition)with solution templates.

www.ibm.com Cognos Suite DB IISeries 7 orAscential

Power-Play

Cognos BI,Cognos Now

Comprehensive mixed Suite of manymerged products (thru acquisition),no or limited solution templates.

www.pentaho.com BI SuiteMySQL,PostgreSQL

Kettle Mondrian JPivot

Collection of Open Source products,may be combined with other prod-ucts like Talend (ETL), Jasper

(Reporting); no solution templates.

www.teradata.com DWH SuiteProprietary databaseand ETL

n/aProprietaryApplications

High End data warehouse specialistwith proprietary componentsand solution templates

www.jedox.com Palo n/aPalo, pure in memoryOLAP solution.

Proprietary Open Source OLAPdatabase with Excel add-in

www.incormatica.com Power Center n/aPowerCenter

n/aHigh end ETL platform with exten-sions like master data mgmt, etc.

www.cubeware.com Cubeware n/a Importer Cockpitsupports various existing OLAPdatabase products

www.ibm.com Cognos TM1 n/aFormer Applix TM1, purein memory OLAP solution

Proprietary OLAP database withExcel add-in and Web Application

www.qliktech.comCube /FrontEnd Suite

n/aQlikView, pure in memory OLAP solutionwith limited ETL capabilities

Proprietary OLAP database with ownAnalytical Application.

Other MDX / XMLA compatible vendors of analytical application platforms(MDX/XMLA are language standards to query and communication with OLAP databases; established by major OLAP engine manufacturers.)

www.microsoft.com ProClarity < supports SSAS only>Desktop Proces-sional & AnalyticsWebServices

Excellent functionality and value forinteractive OLAP of SSAS

www.microsoft.com

Excel(other products aresupported by vendorspecific add-ins)

< supports natively SSASand Gemini only>

Microsoft ExcelLimited support of SSAS Cubes.In-memory OLAP solution Gemini(Excel add-in) will follow soon.

www.bissantz.de DeltaMaster DeltaMaster Powerful analytical application

www.microstrategy.com MicroStrategy 9 MicroStrategy 9Desktop & Web

Supports almost all possible sources(SQL, OLAP, etc.) and providesreporting solution templates.

www.it-workplace.co.uk Intelligencia Desktop & Office& SSRS

Powerful extensions for SSRS andOLAP reporting

www.panorama.com NovaView Desktop & Web Good for enterprise analyticalreporting & analysis

www.xlcubed.com XLCubed Excel & Web Interesting visualization features

And at least 10-20 more powerful products of analytical applications (incl. open source), with full support for MDX/XMLA and partially for SQL.
http://www.olapreport.com/http://www.olapreport.com/http://www.gartner.com/http://www.gartner.com/http://www.gartner.com/http://www.barc.de/http://www.barc.de/http://www.barc.de/http://www.idc.com/http://www.idc.com/http://www.idc.com/http://www.microsoft.com/http://www.microsoft.com/http://www.oracle.com/http://www.oracle.com/http://www.ibm.com/http://www.ibm.com/http://www.pentaho.com/http://www.pentaho.com/http://www.teradata.com/http://www.teradata.com/http://www.jedox.com/http://www.jedox.com/http://www.incormatica.com/http://www.incormatica.com/http://www.cubeware.com/http://www.cubeware.com/http://www.ibm.com/http://www.ibm.com/http://www.qliktech.com/http://www.qliktech.com/http://www.microsoft.com/http://www.microsoft.com/http://www.microsoft.com/http://www.microsoft.com/http://www.bissantz.de/http://www.bissantz.de/http://www.microstrategy.com/http://www.microstrategy.com/http://www.it-workplace.co.uk/http://www.it-workplace.co.uk/http://www.panorama.com/http://www.panorama.com/http://www.xlcubed.com/http://www.xlcubed.com/http://www.xlcubed.com/http://www.panorama.com/http://www.it-workplace.co.uk/http://www.microstrategy.com/http://www.bissantz.de/http://www.microsoft.com/http://www.microsoft.com/http://www.qliktech.com/http://www.ibm.com/http://www.cubeware.com/http://www.incormatica.com/http://www.jedox.com/http://www.teradata.com/http://www.pentaho.com/http://www.ibm.com/http://www.oracle.com/http://www.microsoft.com/http://www.idc.com/http://www.barc.de/http://www.gartner.com/http://www.olapreport.com/


26/39


6 Business Intelligence Platform

6a Architectural Components

(Extract from Business Intelligence Lifecycle Diagram)

Reporting Model:The multi-dimensional reporting model is the key element to organize andaccess the companys consolidated data. It provides a unified business related view to all trans-actions and transaction related structures (date, daytime, unit, person, product, account, geo-graphy, etc.). This unified view is also often named as single version of truth.

For simplicity of understanding, ease of use and good data access performance for large datavolumes, the object model follows a simple star-structure, where the facts (transactions) aresurrounded by all context related dimensions (report aspects). Depending on the overall busi-ness model, the star can grow into a snowflakeor even galaxylike shape, whereas in case ofhaving multiple facts, they should share their common dimensions. This allows comparing dif-ferent facts along their common shared dimensions.

The conceptual model also defines how the data is organized in its data storage area (datawarehouse). A functional slightly extended version of the model is also used for OLAP cubes,which then are accessed by the users thru their analytical application(s).


27/39


Data Warehouse:The data warehouse is a database system designed to host the consolidateddata and make it accessible to analytical applications (SQL) and/or OLAP engines. Moreover itprovides space to support the data collecting and consolidation process, which is coordinatedby the ETL workflow. Therefore a typical data warehouse differentiates between following dataareas:

Extract / Staging / Target: The ETL process initially stores fully or incrementally ex-tracted data from the various sources in an extract area before they are subsequentlytransformed into the reporting model structure (staging) and loaded into the consolidatedpersistent target data structure (target). The non-persistent data in the extract and staging

area is recreated and overwritten by the ETL process, whereas the target represents a

continual data area, which keeps all source data in the unified reporting model structure,even if the operational source system changes or its historical data has been removed.

Export:As part of the ETL process, data may be exported selectively from the target datastructure to provide business applications (sources) and other special programs (i.e., sta-tistical packages) with custom structured data extracts (i.e., consolidated product catalog).

Query: The query area serves as abstraction layer for the physical target data structureand provides end users and OLAP engines data warehouse access on the base of theunified business related reporting model.

Repository: This area holds the core information to re-create and load the data ware-house. The repository describes all data warehouse hosted data objects (metadata) andstores the object related ETL process settings (ETL Configuration).

OLAP Cubes:OLAP engines provide fast access to structured data following the unified report-ing model. Compared to the underlying data warehouse, OLAP engines process data ware-house data and store them as cubes in a proprietary pre-aggregated and query optimized dataformat. Depending on the performance requirements further intermediate levels are pre-aggregated during the cube processing.

For user-friendly fast and efficient report creation and to support simplified user interactions, theOLAP related unified reporting model is usually extended with additional OLAP specific func-tional dimensions. Independent of additional features of the selected analytical application,these dimensions enable the user to create fast and easy any ad-hoc reports without the needfor in-depth knowledge about the query language.

The so called in-memory OLAP engineskeep the immediate processed data constantly in thememory, except the operating system itself frees up memory by disk related memory pageswapping. Conventional OLAP engines store the processed data on disk, but supported by asophisticated caching logic (server and client), they keep as much cube data as possible in thememory, which de-facto results in the same query performance as known from pure in-memoryOLAP engines. In case of system failure, conventional OLAP engines dont have to reprocessthe data and can be queried right away, whereas in-memory OLAP engines must reprocess alldata first before its accessible toqueries again. In case of high data volumes in-memory OLAPdatabases can only be run on a 64-bit server with plenty of memory (hardware investments) andruns into risk that after a case of failure reprocessing may not be done within the specified re-covery time.

Only in cases of medium to low volume source data and non-shareable OLAP data, the one bigadvantage of in-memory OLAP engines, is that they dont require a server infrastructure or aclient with server-like hardware specifications. Such engines can be run on any regular client

hardware, empowering the end user to build and analyze ad-hoc cubes completely on theirown. To still assure a single version of truth (except its data timeliness) across individually builtad-hoc cubes, its recommended, that all users access the same unified reporting model of thedata warehouse. Be aware, that such client based approaches are a potential security hole.


28/39


ETL Process: Any business intelligence platform requires an ETL process, where data fromseveral sources must be consolidated or the data warehouse is required to maintain a persis-tent data base or to preserve historical data structures or the data conversion into the reportingmodel involves complex transformations. The ETL process updates the data in the target datawarehouse by extracting data from the sources, transforming and cleansing the data towardsthe unified reporting model structure and loading the data into a persistent target database. Thisprocess should be fully automated and scheduled according to the minimal required updatefrequency.

The overall ETL process is configured thru object specific ETL execution settings. All necessaryobject information used to create, extract, load and update the object data itself, comes from the

repository database of the data warehouse. The data transformation into the reporting modelstructure requires Source Mappingdefinitions and optionally additional rules how to cleanse andenrich the data.

Data cleansingor data scrubbing is the act of detecting and correcting (or removing) corrupt orinaccurate records from a record set, table, or database. Used mainly in databases, the termrefers to identifying incomplete, incorrect, inaccurate, irrelevant etc. parts of the data and thenreplacing, modifying or deleting this dirty data.http://en.wikipedia.org/wiki/Data_cleansing

Data enrichingis the act to optionally enrich existing database records based on lookups withinthe same or other database tables. Enriching is often used to complete item catalogs like cus-tomer or products, where up-to-date item related information is retrieved from special lookupsources (phone directories, GTIN/EAN database, etc.).

The topic of data quality assurance is favorably implemented as part of the data cleansing,where the data is checked on the base of object related quality verification rules (attribute, in-row, in-table, cross-table). All rule violations are fully logged. At the end of a data quality assur-ance task, all data responsible persons are automatically notified with an individual data relatedstatus report.

As part of an optional master data management,alternate item catalogs (i.e., products, custom-ers, accounts) coming from different sources are automatically merged and aligned according tospecific rules and reference (catalog) data.

Conventional business intelligence solutions focus on reporting and analysis of quantitativedata, whereas an enhanced reporting model also includes many supportive attributes. Suchitem specific background information (address, color, etc.) can be used in the analytical applica-tions to provide additional functionality. An integration with existing qualitative data (text, im-

ages, streaming media), as stored in document management systems, knowledge managementand semantic web applications, may require the creation of some special ETL tasks, which linkthe quantitative data accordingly.

The data warehouse is also a source to create customized extracts for other applications, likeunified product and customer catalogs for business applications (closed loop), transactions ex-tracts for other programs like statistical packages, item structure extracts for customer mailingsor for other (external) recipients. This aspect is covered by an export task,which (re-)createsthe customized table objects and exports the selected data.

Only in cases, where you can directly access pre-integrated and preferably pre-transformeddata and there is absolutely no need for persistent target data, you may build a business intelli-gence platform without a data warehouse and ETL process. As soon you want to integrate non-pre-transformed sources or you need a place to keep (historical) data, there is no feasible wayhow it can be done without a data warehouse and a corresponding ETL process.
http://en.wikipedia.org/wiki/Data_cleansinghttp://en.wikipedia.org/wiki/Data_cleansinghttp://en.wikipedia.org/wiki/Data_cleansinghttp://en.wikipedia.org/wiki/Data_cleansing


29/39


Analytical Application(s):The analytical application is the visible interface to the end users tocreate and retrieve their reports and to perform ad-hoc queries. Independent of the selectedanalytical application all visible data content (values and structures) is identical as long the datacomes from the same unified reporting model either from the OLAP database and/or the datawarehouse.

The analytical application primarily helps to create and visualize data content.Additionally, mostapplications empower the user to explore and analyze the data with interactive functions likedrilldown/drill-up, expand/collapse, pivotize, sort, value-highlighting, export to Excel and PDF,etc.. Some applications also support advanced cube features like cube-based cell formatting,creation and use of local/cube-based dynamic named sets and calculations, and the invocationof cube-based actions (incl. model context sensitive online help). For multi-lingual solutions afew applications also support the on-the-fly translation of all visible reporting model metadata.

Additional statistical, visualization and interactivity features like inverted display of dimensionhierarchies, in-cell sparklines/sparkbars, waterfall diagrams, interactive ABC/Pareto-charts,hyperbolic trees, and dimension impact analysis, are further features of some applications.

Following useful features are supported by only a few analytical application platforms so far:

Collaboration Support

create and share personal reports (derived from other standard reports)

add and share personal annotations at report, dimension and cell level

WCMS-like (report) layout templates, which can be administrated centrallyand allow alignment with existing corporate design guidelines.

Enhanced template basedpublishing supportwith automated integration of text data.

Budgeting and planning with multi-scenario data entry and workflow support: This quitecomplex theme is not a real BI topic in the narrower sense, but is often raised as pendingbusiness issue from users using the analytical applications. Also a few vendors havestarted selling integrated planning features in their analytical application, such approachesusually dont deliver the expected value and its recommended to address planning relatedissues with specialized application packages.

Further details about the different aspects can also be found in the related chapter about prod-

uct selection criteria for analytical applications.

Because not all users have the same needs, a mix of carefully selected alternative analyticalapplications may provide the best result regarding the user specific application skills and theapplication related license fees. The different levels of user interactivity are explained in moredetail in the next chapter.


30/39


Batch report distribution is a task coming from earlier days, when it usually took minutes tohours to create updated business reports. But as there are situations, where report recipientsare not end users or they have only limited or no access to the DWH and/or OLAP databases, itmay still make sense to look for specific application features of the analytical platform, whichsupport a fully automated creation and distribution of published reports.

Data mining is the process of extracting hidden patterns from data. As more data is gathered,with the amount of data doubling every three years, data mining is becoming an increasinglyimportant tool to transform this data into information. It is commonly used in a wide range ofprofiling practices, such as marketing, surveillance, fraud detection and scientific discovery.http://en.wikipedia.org/wiki/Data_mining

Some DWH and OLAP database products and some analytical applications provide serverand/or client based data mining functionality. The result of the data mining activity is the crea-tion of an explanatory mining model, which helps for a given record with providing someattribute values to predict the probable values for specific remaining attributes within the samerecord. Such models are usually not visible to the user and are automatically updated as part ofthe ETL process and indirectly used by regular business applications to predict customer pro-file/behavior and business risks already during the data entry or before the data is being loadedinto the data warehouse.

Depending on the selected data mining algorithm like cluster analysis or decision tree, it may beuseful to create and update a mining model ad-hoc and to analyze the outcome directly.

Note: Some DWH and OLAP database products support the re-integration of preliminarycreated or updated mining models as artificial reporting dimension.
http://en.wikipedia.org/wiki/Data_mininghttp://en.wikipedia.org/wiki/Data_mininghttp://en.wikipedia.org/wiki/Data_mining


31/39


6b Information Scope

(Extract from Business Intelligence Lifecycle Diagram)

The information scope shows the relation between the users of the different organizational le-vels in context of their business role (management, knowledge worker, analyst, operation moni-toring, and data entry/creation). According to a usersrole, the person asks for different levels ofaggregates and different types of primary visualizations combined with a set of specific interac-tivity options to perform their tasks. Analysts usually create their individual ad-hoc reports onbase of an existing standard report. In cases of very specific analytical function requirements itmay be useful, to equip the analyst users with a specialized analytical application.

The diagram also illustrates the context of data sources and the business intelligence platform

within the overall information scope. As explained earlier, the item detail reports are preferablycreated and used within their source application, but could be migrated to the BI platform ondemand.

From point of view of the business intelligence platform, the users are profiled regarding therequired application interactivity (reader, explorer, and analyst). This user profiles correspondwith the features of the available alternative analytical application platforms and facilitate theoptional selection of a mix of alternative, profile specific analytical applications. Such a mixusually provides the best result also regarding the user specific application skills and the appli-cation related license fees.

Reader:This user (typically a manager at any level) was used to receive static reports inelectronic or paper form. With the introduction of an analytical application, most of the newinteractive features are not really useful to this group of users. They are satisfied to get

updated standard reports and charts in time and have the possibility to change some ofthe available filters and the set of standard header columns themselves. Depending onthe report they may use the platform also as source for centralized information lookup andask for some item background information (customer address, staff phone no.).


32/39


Explorer:This user (often called knowledge workers;typically a controller, product or keyaccount manager) was either used to receive many regular reports covering all possibleaspects and levels of details or a few extensively large reports. With the introduction of ananalytical application, he can interactively browse thru all different aspects of filter combi-nations and drill-down selectively to the lowest level of detail on demand, without havingto go thru loads of static reports. The ad-hoc invocation of context related informationsources (company reg., etc.) or the ability to quickly send an email to a related person,helps them to improve their productivity on using multiple applications simultaneously.

Analyst:This user (typically a qualified assistant of top ormiddle management, or product/service/business devel-

opment) has to answer diverse questions quite frequently.Therefore he was used to gather information from manydifferent sources to create a consolidated view before hewas able to analyze and interpret the findings. With the in-troduction of an analytical application on the base of anextensive business intelligence platform, he gains a lot oftime to get a unified picture of almost any business relateddata context, as he can directly retrieve all required datadirectly thru the unified reporting model. The analyst bene-fits most of the potential interactivity, special statisticalfunctions and collaboration features. Based on his exper-tise using the unified reporting model and analytical appli-cation features, he is also predestinated to create new or

maintain existing standard reports upon request.

Typical distribution of the countof the different BI user profiles

Operation Monitoring: This user (typically operations staff) must be able to create itemspecific detail reports (customer billing, purchase/sales order, etc.) and fact sheets (singlecustomer, specific product or account, etc.). Such reports are preferably created and usedwithin their source application, but can be migrated to the business intelligence platformon demand.

Reporting Process: The regular reporting processes (operational monitoring, area specificcontrolling, management reporting, report publishing for key customer/suppliers and the public)

should be documented and communicated to all involved people. Next to information about theprocess workflow tasks and the involved actors and resources, the documents should also in-form about escalation procedures in case of exceeding existing threshold values.

Operations and Support: The regular operation processes to run, update and maintain the

business intelligence platform should be documented. Next to information about the processworkflow tasks and the involved actors and resources, they should also inform about existingescalation procedures. Moreover processes regarding end user related training and supporthave to be illustrated and communicated to all potentially involved people.

50%

15%

35%

Reader Explorer Analyst


33/39


6c Reporting Model

Design & ImplementationMultidimensional Modeling: A multidimensional reporting modelis primarily a conceptual ap-proach to create an easy to use data model supporting high performance data access. A simplestar-schema has been proven to achieve the optimum for the two contrary goals and allowsusing the same standardized ETL processes for all dimension and fact objects alike. The result-ing conceptual model should be able to answer all specified report requirements by the struc-ture of its multidimensional design.

Thephysical implementation of the model in the data warehouse target database may be opti-mized regarding ETL processing and required data storage space. For example for specifiedrequirements like currency exchange calculation into a specific report currency or intra-groupeliminations, the reporting values are not fully pre-calculated and stored in the related fact table.Such calculations are preferably integrated directly in the user accessible abstraction layer of

the query database representing the unified reporting model thru specific database views.With the physical implementation in the OLAP cube, some additional, so called functional di-mensions may be added to improve cube usability. Such functional dimensions are for instancedate-series, date-aggregations (YTD, etc.), date-relation (Previous Year) and value scales.

Compliance:Compliance related business requirements and/or constraints must be reflectedby the logical and physical designs and its underlying ETL processes.

Source Mapping and Master Data Management: During the Source Mapping,all objects andattributes of the physical reporting model implementation must be mapped to objects andattributes of the identified data sources. This time-consuming task may become quite complex,when different sources provide similar, but not constantly equal data and multiple alternativesources must be merged into single attribute values.

The merge and alignment of multiple item catalogs from different sources (products, customers,and accounts) also called master data managementshould be solved as own task. Afterwardsthe execution of the resulting integration logic can be embedded in the main ETL process.

ETL workflow design and configuration: ETL workflows,which extract, transform and loadthe source data into the target data warehouse, have to be designed and implemented. Thiscan either be done by creating individual workflows and code routines for all source extractionsand transformation/load-operations of target objects, or by creating a general ETL workflow withstandard code routines, where object related execution parameters are retrieved dynamicallyfrom an own repository (ETL Configuration). The second approach is more complex for an initialrelease, but makes maintenance and platform extending efforts much more cost-effective due tocentralized configuration und parameter settings. A further advantage of this approach is that alldocuments and operation settings are well documented in one place (potential metadata com-

pliance requirement). This repository offers also a good source to create all kind of customizeddocumentation. Depending on the selected ETL engine product, an existing add-on productsupporting a centralized repository approach should be considered to facilitate a cost-effectiveinitial design and implementation of the ETL processes.


34/39


Documentation: A good documentation of the final design and the development deliverablesincluding the key considerations, which have lead to specific design and development adapta-tions, are important for future maintenance and growth of the business intelligence solution. Itdocuments, transfers and preserves knowledge that future releases and other project teamscan build on.

6d Analytical Application Design & Development

Terminology and Naming Rules:Its important to build and maintain a library about corporateterminology definitions for all items which are visible in the unified reporting model. This informa-

tion should be an integrated part of the usersdocumentation and/or the model context sensitiveonline help in the analytical application. This ensures that all internal or external users across allorganizational units have the same understanding about specific terms. The library must coverat least all metadata objects (facts, dimensions) and its attributes. Moreover we recommendincluding definitions for specific content items (financial accounts, customer segments, key fig-ures and ratios). In practice this task oft

Documents

Knowledge Bi Lifecycle