Erp

Integrating Business Intelligence with ERP
INTEGRATING BUSINESS INTELLIGENCE WITH ERP
To Improve Operational and Strategic Planning Information in
Small and Medium-sized Enterprises
Paula O’Hara
Master of Software and Information Systems
The National University of Ireland, Galway in conjunction with Regis University
School for Professional Studies, Denver, Colorado.
Department of Information Technology
August 2009
Head of Department: Professor Gerard Lyons
Advisor: Dr. Owen Molloy – NUI, Galway
-1-
Certificate of Authorship
Final Project/Thesis Submission
MSc in Software & Information Systems
Department of Information Technology
National University of Ireland, Galway
Student Name: Paula O’Hara
Telephone: 00 353 (0)87 9069535
E-mail: pohmasters@googlemail.com
Date of Submission: 28th August 2009
Title of Submission: Integrating Business Intelligence with ERP to Improve
Operational and Strategic Planning Information in
Small and Medium-sized Enterprises.
Supervisor Name: Dr. Owen Molloy
Certification of Authorship:
I hereby certify that I am the author of this document and that any assistance I received in
its preparation is fully acknowledged and disclosed in the document. I have also cited all
sources from which I obtained data, ideas or words that are copied directly or paraphrased
in the document. Sources are properly credited according to accepted standards for
professional publications. I also certify that this paper was prepared by me for the purpose
of partial fulfilment of requirements for the Degree Programme.
Signed: Date: 28th August 2009
-2-
Acknowledgements
To my husband Kieran, daughter Antoinette and son Thomas – thank you for your
understanding and support during the last two years
To my sister Maria – for being mother number two
To my friends Joey and Marie – for reminding me there is life after learning
To Dermot – for this opportunity, his sympathy, advice and financial support
To Barbara – for keeping my seat in the clubhouse and our friendship warm
To Dr. Owen Molloy – for your guidance, patience and above all sharing your
knowledge
To the MScSIS Teams at NUI Galway and Regis University – for a tremendous
learning experience
Thank you all for helping me to fulfil my dream.
-3-
Table of Contents
List of Tables ............................................................................................................11
List of Figures...........................................................................................................12
List of Figures in Appendices..................................................................................17
Abstract.....................................................................................................................18
Introduction..............................................................................................................19
Chapter 1 - The Thesis Statement ..........................................................................21
1.1 The Problem Statement....................................................................................21

1.2 The Sub-Problems Identified ...........................................................................21
1.3 The Hypotheses................................................................................................22
1.4 The Scope of the Thesis...................................................................................23
1.5 The Significance of the Study..........................................................................24
1.6 Success Criteria................................................................................................25
Chapter 2 - Literature Review................................................................................26
2.1 Introduction......................................................................................................26
2.2 Motivation........................................................................................................26
2.3 ERP – Implementation Success Factors ..........................................................28
2.4 SME Specific Constraints ................................................................................35
2.5 Operational and Strategic Planning .................................................................36
2.6 Business Intelligence Concepts........................................................................38
2.6.1 BI Evolution..............................................................................................39
2.6.2 BI Definitions and Purpose.......................................................................40
2.6.3 BI Trends and Good Practice....................................................................41
2.7 BI Solutions .....................................................................................................42

2.7.1 Standalone BI Tools – Reporting, Analytics, Scorecards, Dashboards....43
2.7.2 Software as a Service (SAAS) ..................................................................44
2.7.3 Open Source..............................................................................................45
2.7.4 Cloud Computing......................................................................................46
-4-
2.8 BI Approaches .................................................................................................46

2.8.1 Data Warehouse ........................................................................................46
2.8.2 Business Performance Management .........................................................47
2.8.3 Customer Relationship Management........................................................48
2.8.4 Dashboards................................................................................................51
2.8.5 Scorecarding .............................................................................................51
2.8.6 Key Performance Indicators – Translating the Organization’s Strategy to
meaningful metrics ............................................................................................52
2.9 BI Implementation Considerations ..................................................................54

2.9.1 Data Requirements....................................................................................55
2.9.1.1 Online Transaction Processing (OLTP) versus Online Analytical

Processing (OLAP) ..........................................................................................57
2.9.1.2 Data Mart Design and Implementation................................................58
2.9.1.3 Star schema design considerations: .....................................................59
2.9.1.4 Data mart implementation steps...........................................................61
2.9.2 End User Considerations ..........................................................................62
2.9.3 Development Considerations ....................................................................64
2.9.4 Business Environment Considerations .....................................................64
2.10 Conclusion .....................................................................................................65

Chapter 3 – Methodology........................................................................................66
3.1 Introduction......................................................................................................66
3.2 Survey Related Data ........................................................................................66
3.3 Case Study .......................................................................................................67
3.4 Content Analysis..............................................................................................68
3.5 Vendor Interviews and Product Reviews.........................................................68
3.6 Exploration of Business Process Modeling Tools ...........................................68
3.7 Designing the Framework................................................................................69
Chapter 4 – Survey Results.....................................................................................70
4.1 Introduction......................................................................................................70
4.2 Operational and Strategic Planning .................................................................72
4.3 BI Technology Awareness...............................................................................76
-5-
4.4 Business Intelligence Use ................................................................................78

4.5 ERP Use ...........................................................................................................80
4.6 Company Details and Respondent General Characteristics.............................85
4.7 Conclusion .......................................................................................................86
4.8 Lessons Learned...............................................................................................87
Chapter 5 - Performance Management and Measurement .................................88
5.1 Introduction......................................................................................................88
5.2 Strategy Processes in SMEs.............................................................................88
5.3 Business Process Management ........................................................................93
5.4 Conclusion .......................................................................................................94
Chapter 6 - BI Maturity Models.............................................................................96
6.1 Introduction......................................................................................................96
6.2 BI Maturity Model Illustrations .......................................................................96
6.2.1 BI Maturity Model 1: Deng’s BI Maturity Hierarchy ..............................96
6.2.2 BI Maturity Model 2: TDWI’s Business Intelligence Maturity Model ....98
6.2.3 BI Maturity Model 3: Business Intelligence Maturity Model (BIMM)..102
6.2.4 BI Maturity Model 4: IBM’s Information Lifecycle ..............................102
6.3 Conclusion .....................................................................................................103

Chapter 7 - Case Study: Integrating BI with ERP in Company A ...................104
7.1 Introduction....................................................................................................104
7.2 Background to the Project..............................................................................105
7.3 Project Scope .................................................................................................105
7.4 Business Process Review...............................................................................106
7.4.1 Information Consumers and Producers...................................................107
7.4.2 Current Process Flows ............................................................................108
7.4.3 Reports in Use.........................................................................................108
7.4.4 MIS Capability........................................................................................110
7.4.5 ERP Implementation Type and Data Characteristics .............................110
7.4.6 Data Sources (other than ERP) ...............................................................111
-6-
7.4.6.1 Integration of other data sources........................................................112

7.4.7 Sales Related KPIs..................................................................................114
7.4.7.1 KPIs selected for trial.........................................................................115

7.4.8 Defining the Dimensions and Facts for use in a Data Mart....................116
7.4.9 Data sets in use .......................................................................................118
7.5 BI Maturity Level Assessment Pre-implementation......................................118

7.6 Integration of BI with ERP ............................................................................119
7.6.1 Data mart design ...................................................................................120
7.6.2 Populating the data mart – ETL ............................................................123
7.7 Query Testing: OLTP versus OLAP..............................................................124
7.7.1 Test Data Specification ...........................................................................124
7.7.2 Configuring the Test Environment and Report Design ..........................125
7.7.2.1 Allow BI application to access the ERP OLTP files directly ............125
7.7.2.2 Build a data mart based on a star schema with aggregation - OLAP 128
7.7.3 Testing and Results of OLTP vs OLAP Query Processing ....................131
7.8 Reports Designed to monitor KPIs identified................................................136

7.8.1 Report Design and Analysis ...................................................................136
7.8.2 Additional benefits noted in the case study on the use of BI..................141
7.8.3 Summary Comments...............................................................................142
7.9 BI Maturity Post Implementation ..................................................................142

7.10 Conclusion ...................................................................................................143
Chapter 8 - Moving BI to the Next Level.............................................................147
8.1 Introduction....................................................................................................147
8.2 Characteristics of BI Maturity .......................................................................147
8.3 Service Oriented Architectures (SOA) ..........................................................148
8.4 Web Services .................................................................................................149
8.5 Business Process Integration..........................................................................150
8.6 Web Services Business Process Execution Language (WS-BPEL 2.0) ........151
8.6.1 WS-BPEL Evolution...............................................................................151
8.6.2 WS-BPEL Definition ..............................................................................152
8.6.3 Language Specification...........................................................................153
-7-
8.6.4 WS-BPEL Application ...........................................................................153
8.6.5 WS-BPEL Language Constructs ............................................................155
8.6.6 Sample WS-BPEL Process .....................................................................157
8.7 Conclusions....................................................................................................163
Chapter 9 – Alternate BI and ERP Delivery Methods .......................................164
9.1 Introduction....................................................................................................164
9.2 Showcase 1: SaaS ..........................................................................................164
9.3 Showcase 2: Professional Open Source.........................................................166
9.4 Show Case 3: Amazon Elastic Compute Cloud (EC2)..................................170
9.4.1 Amazon EC2 Costs .................................................................................173
9.4.2 Who is using it? ......................................................................................173
9.4.3 Configuration of EC2 for use..................................................................174
9.4.3 Is Cloud Computing Feasible for SMEs? ...............................................178
9.4.3.1 Advantages of Cloud Computing ........................................................179
9.4.3.2 Disadvantages and Concerns over Cloud Computing .........................180
9.5 Conclusions....................................................................................................180
Chapter 10 - Guide to BI Selection and Integration for SMEs..........................182
10.1 Introduction..................................................................................................182
10.2 The BI Integration Framework ....................................................................182
10.3 The BI Selection Framework .......................................................................190
Conclusions.............................................................................................................193
Chapter 11 – Concluding Remarks ......................................................................194
11.1 Returning to the the Hypotheses ..................................................................194

11.2 Evaluation ....................................................................................................197
11.3 Further Research ..........................................................................................197
References...............................................................................................................199
Appendix A .............................................................................................................209
Methodology for Slowly Changing Dimensions (SCDs) Type 1 ........................209

Appendix B .............................................................................................................210
-8-

Appendix C .............................................................................................................211

Appendix D .............................................................................................................212
Survey on Business Intelligence (BI) ..................................................................212

Appendix E .............................................................................................................230
Invitation to Participate in the Survey .................................................................230

Appendix F .............................................................................................................232
Reminder to Participate in the Survey .................................................................232

Appendix G.............................................................................................................233
Request for Permission to use the TDWI’s Business Intelligence Maturity Model
Poster....................................................................................................................233
Appendix H.............................................................................................................235
Information Users and Consumers - Company A................................................235

Appendix I ..............................................................................................................236
Information Producers and Consumers in the Context of the Organizational

Hierarchy – Company A ......................................................................................236
Appendix J..............................................................................................................237
Current Sales Reporting Data Sources and Methods- Company A .....................237

Appendix K.............................................................................................................238
MIS Capability - IT Hardware Infrastructure Diagram - Company A ................238

Appendix L .............................................................................................................239
MIS Capability - Software Pertaining to the BI Project – Company A...............239

Appendix M ............................................................................................................240
MRC’s m-Power Technical Specification ...........................................................240

Appendix N .............................................................................................................242
Structure of a WS-BPEL 1.0 Process ..................................................................242

Appendix O.............................................................................................................243
Control Flow within WS-BPEL 1.0.....................................................................243
-9-
Appendix P .............................................................................................................244
Pentaho BI Suite Community and Enterprise Edition Features...........................244

Appendix Q..........................................................................................................246
Pentaho Enterprise Edition Pricing Guide (2009) ...............................................246
Appendix R .............................................................................................................247
Selected Pricing for the EC2 Cloud Environment ...............................................247

Appendix S..............................................................................................................251
Business Intelligence Vendor and Application Assessment (RFI) ......................251

Appendix T .............................................................................................................268
Business Intelligence Vendor and Application Assessment (Proof of Concept).268
- 10 -
List of Tables
Table A. Analysis of Ad-hoc Query Reports Stored by Company…………............109

Table B. Query Response Times against an OLTP Structure on an Active System………132
Table C. Query Response Times against an OLTP Structure on a Dedicated System……133
Table D. Query Response Times against an OLAP Structure on an Active System……...134
Table E. Query Response Times against an OLAP Structure on a Dedicated System…… 135
Table F. BI Inhibitors…………………………………………………… ………..183
TableG. BI Facilitators…………………………………………………………… 184
Table H Business Intelligence Vendor and Application Assessment Client
Requirements Ranking………………………………………………… ……… …192
- 11 -
List of Figures
Figure 1. Example of MRC Productivity developments including operational BI. ....44
Figure 2. MRC Example of operational BI presenting real time data.........................44
Figure 3. A complete architecture for Business Performance Management (BPM)...48
Figure 4. A taxonomy of CRM analysis types. ...........................................................50
Figure 5. Example of a performance dashboard..........................................................51
Figure 6. Example of a scorecard ................................................................................52
Figure 7. Excerpt of a taxonomy of CRM analyses (S=Strategic and T=Tactical).....53
Figure 8. Mapping users to BI Tools...........................................................................64
Figure 9. Survey response to O&S planning Q1…………………………………….72
Figure 10. Survey response to O&S planning Q2………………………………… 72
Figure 11. Survey response to O&S planning Q3……………………………….. 72
Figure 14. Survey response to O&S planning Q6………………………………….. 72
Figure 16. Survey response to O&S planning Q8………………………………….. 73
Figure 18. Survey response to BI awareness Q10………………………………… 76
Figure 19. Survey response to BI awareness Q11…………………………………..76
Figure 20. Survey response to BI awareness Q12…………………………………. 76.
Figure 21. Survey response to BI awareness Q13………………………………… 76
Figure 22. Survey response to BI awareness Q14………………………………….. 76
Figure 23. Survey response to BI awareness Q15………………………………….. 76
Figure 24. Survey response to BI awareness Q16.......................................................77
- 12 -
Figure 25. Survey response to BI use Q22…………………………………………..78
Figure 26. Survey response to BI use Q23…………………………………………..78
Figure 27. Survey response to BI use Q24 ..................................................................79
Figure 28. Survey response to ERP use.Q25……………………………………… 80
Figure 29. Survey response to ERP use Q28……………………………………….. 80
Figure 30. Survey response to ERP use Q29……………………………………… 80
Figure 33. Survey responses to ERP use Q32……………………………………….81
Figure 35. Survey response to ERP use Q34……………………...............................81
Figure 39. Survey response to ERP use Q38………...................................................82
Figure 42. Survey response to company details Q44 ..................................................85
Figure 43. The key determinants of strategic context .................................................89
Figure 44. The key constraints to strategy process in SMEs.......................................90
Figure 45. Strategy process wheel framework ............................................................91
Figure 46. Top strategic actions for best in class SMEs..............................................92
Figure 47. Deng's BI maturity hierarchy .....................................................................96
Figure 48. TDWI's BI adoption curve .........................................................................99
Figure 49. TDWI's business intelligence maturity model .........................................101
- 13 -
Figure 50. Business Intelligence Maturity Model (BIMM) ......................................102
Figure 51. IBM's information lifecycle model ..........................................................103
Figure 52. Mapping users to BI tools ........................................................................107
Figure 53. m-Power's “create a new table from spreadsheet data” utility screen-shot
....................................................................................................................................113
Figure 54. Result of new table creation from a spreadsheet with 65,536 rows.........114
Figure 55. KPI hierarchy ...........................................................................................115
Figure 56. Customer dimensional hierarchy .............................................................117
Figure 57. Item dimensional hierarchy......................................................................117
Figure 58. Time dimensional hierarchy.....................................................................117
Figure 59. TDWI BI adoption curve .........................................................................118
Figure 60. Logical model for item sales data mart for company A...........................121
Figure 61. Physical implementation of the star schema for company A...................122
Figure 62. Movex ERP database tables registered to the data dictionary within m-
Power .........................................................................................................................125
Figure 63. Report selection screen for OLTP vs OLAP Test: OLTP direct test .......126
Figure 64. SQL generated by report selection based on OLTP data structures ........127
Figure 65. Result of OLTP test record selection when records exceed report limits 127
Figure 66. Report presented by integrating BI with ERP directly ............................127
Figure 67. Example of Fact table data before loading to data mart .........................128
Figure 68. Example of Time Dimension data before loading to data mart ..............128
Figure 69. Example of Item Dimension data before loading to data mart ................128
Figure 70. m-Power metadata repository showing data mart tables registered.........129
Figure 71. Report selection screen OLTP vs OLAP: Data mart test.........................129
- 14 -
Figure 72. REsult of record selection on method 2 where records exceed report limits
....................................................................................................................................130
Figure 73. SQL generated by report based on OLAP data structures .......................130
Figure 74. Report presented by integrating BI with the data mart ............................131
Figure 75. Top N analysis company A......................................................................137
Figure 76. Sales by value in each market sector in which the company operates.....138
Figure 77. Sales by customer and product group ......................................................139
Figure 78. Suggested library report for end users with filter capability in m-Power 139
Figure 79. End user report style displaying use of filters in m-Power ......................140
Figure 80. Example of an executive dashboard for Company A displaying sales
growth ........................................................................................................................141
Figure 81. m-Power enquiry screen example ...........................................................142
Figure 82. SOAs Find-Bind-Execute paradigm ........................................................149
Figure 83. Evolution of WS-BPEL 2.0 .....................................................................152
Figure 84. Web Services stack ..................................................................................154
Figure 85. BPEL: Relationship to partners................................................................157
Figure 86. BPEL process designer image for simple synchronous process .............158
Figure 87. BPEL activities on Netbeans Pallette.......................................................159
Figure 88. Example of XML schema definition for BPEL Process Module.............160
Figure 89. Graphical view of variable definitions for BPEL Process Module..........161
Figure 90. Partner links for the sample BPEL process..............................................161
Figure 91. Mapping of input and output variables in BPEL process ........................162
Figure 92. Conditional logic applied to manipulate return variable in BPEL process
....................................................................................................................................162
Figure 93. Growth in open source BI Licensing .......................................................166
- 15 -
Figure 94. The Pentaho BI Enterprise Console .........................................................169
Figure 95. Configuring data sources in the Pentaho BI Enterprise console..............169
Figure 96. Operating systems available on Amazon EC2.........................................172
Figure 97. Sample of software available on Amazon EC2 .......................................173
Figure 98. Amazon EC2 configuration for persistence .............................................174
Figure 99. Amazon Elastic Block Store (EBS) multiple instance diagram...............176
Figure 100. Data refinement hierarchy within a BI maturity context .......................182
Figure 101. Roadmap to BI Maturity ........................................................................185
Figure 102. BI maturity enablers...............................................................................186
Figure 103. Strategy process and MIS synergy wheel ..............................................190
- 16 -
List of Figures in Appendices
Figure H1. Information users and consumers - Company A…………………...235

Figure I1. Information producers and consumers in the context of the
organizational hierarchy…………………………………………………….…..236
Figure J1. Current sales reporting data sources and methods – Company A.….237
Figure K1. MIS capability - IT hardware and infrastructure diagram –
Company A………………………………………………………………….….238
Figure L1. Company A software capability pertaining to BI…………………..239
Figure N1. BPEL Process Definition………………………………………….. 242
Figure O1. BPEL Control Flow……………………………………………….. 243
Figure P1. PentahoTM BI Suite Community and Enterprise Edition Features.. 244
Figure Q1. Pentaho Enterprise Edition pricing guide for 2009………………...246
Figure R1. EC2 instance types………………………………………………….247
Figure R2. EC2 On-Demand hourly cost (Europe)……………………………..248
Figure R3. EC2 Reserved cost (Europe)………………………………………..248
Figure R4. EC2 data transfer costs…………………………………………. ….249
Figure R5. EC2 cloud watch costs………………………………………………249
Figure R6. EC2 load balancing costs………………………………………. …..249
Figure R7. EC2 load balancing costs……………………………………………250
- 17 -
Abstract
Business Intelligence (BI) applications are increasingly prevalent in the Small and
Medium-sized Enterprise (SME) sector. BI vendors are targeting SMEs but many
projects fail due to poor planning, lack of resources, organization immaturity and
failure to understand the complexities of integrating such applications with existing
business systems. This study looks at how manufacturing Small and Medium-sized
Enterprises (SMEs) using or planning on using Enterprise Resource Planning (ERP)
software could integrate BI to improve the availability of operational and strategic
planning information within the constraints imposed on organizations in the SME
category. SMEs need BI tools integrated with their financial (and other) applications
so users (not only dedicated IT resources) can access the financial and operational
data residing in the ERP systems in a quick, easy, efficient and cost effective manner.
The study approaches BI integration from three perspectives. Strategy process looks
at how strategy is implemented in SMEs as a precursor to defining how BI
applications can integrate organizational goals into Key Performance Indicators
(KPIs). BI maturity models are presented as a roadmap to measure the capability and
readiness of an organization to progress BI, and BI tools are discussed from the
perspective of selection, integration strategies and delivery platforms suited to SMEs
culminating in a best practices framework for BI integration in the SME sector.
- 18 -
Introduction
This study looks at how manufacturing SMEs using or planning on using ERP
software could integrate BI to improve the availability of operational and strategic
planning information within the constraints imposed on organizations in the SME
category.
Chapter 1 outlines the original thesis question and documents the sub-
problems and hypotheses associated with integrating BI with ERP to improve
operational and strategic planning information in SMEs
Chapter 2 presents an overview of literature relating to ERP and BI
implementation which details critical success factors, constraints on SMEs, the
meaning of operational and strategic planning, the meaning of BI and an overview of
BI concepts, solutions and approaches.
Chapter 3 outlines the methodology for this research outlining the approach
adopted for the study which comprises a survey and case study among others.
Chapter 4 details the results of a survey conducted among SME manufacturing
companies covering operational and strategic planning practices, BI technology
awareness, BI use, ERP use and general company details and respondent general
characteristics.
Chapter 5 presents a framework for strategic context in manufacturing SMEs
outlining the determinants of strategic context and the constraints to strategy process.
A Strategy process framework is provided as a means for SMEs to formulate strategy.
Business Process Management (BPM) and BI are discussed as a means of
implementing strategy.
- 19 -
Chapter 6 provides an overview of four BI Maturity Models to provide a
framework for assessment of the readiness of the organisation for a particular BI
project. There is commonality in the BI lifecycle between the models suggesting
organisations move through stages of maturity and the level of knowledge grows as
BI matures.
The Case study of Company A (a real life manufacturing company) is
presented in Chapter 7. The company is assessed against the backdrop of the strategy
framework presented in Chapter 5 and the BI maturity models in chapter 6. Work
completed to move the company from no BI capability to the early stages of BI
maturity is presented.
Chapter 8 entitled “Moving BI to the next Level” introduces WS-BPEL 2.0 as
a means of implementing business processes. As organisations move through the
stages of BI maturity the requirement for real time analytics increases. Using WS-
BPEL one may orchestrate web services capable of providing real time metrics in an
SOA environment. The chapter presents an overview of the language constructs, tools
and a sample process.
Chapter 9 presents some BI delivery mechanisms by showcasing a few
examples covering cloud computing, SaaS and Open Source solutions.
The final chapter provides a summary of the work complete which culminates
in a BI selection and integration framework for manufacturing SMEs.
- 20 -
Chapter 1 - The Thesis Statement
1.1 The Problem Statement
This study looks at how manufacturing Small and Medium-sized Enterprises
(SMEs) using or planning on using Enterprise Resource Planning (ERP) software
could integrate BI to improve the availability of operational and strategic planning
information within the constraints imposed on organizations in the SME category.
1.2 The Sub-Problems Identified
1. Defining the meaning of operational and strategic planning in an SME to
ensure the right questions are been asked of the solution.
2. Looking at how SMEs implement ERP in an attempt to define best practice in
this area to ensure a good data foundation as a prerequisite to implementing a
BI solution.
3. Defining the meaning of BI in a manufacturing organizational context.
4. Ascertaining what data an SME requires to enable operational and strategic
planning to take place.
5. Defining the role of Key Performance Indicators (KPIs) in operational and
strategic planning.
6. Categorising data in the case study company.
7. Documenting the type of analyses an organization would like to perform on
the data including levels of detail, summary levels, drill down features, three
dimensional views, consolidations and more.
8. Analysing the outputs required of the solution for the purposes of defining
storage and presentation methods required.
- 21 -
9. Defining the constraints the organization size and structure impose on BI
selection.
10. Defining the constraints the hardware and software in use in the organization
impose if any.
11. Determining the levels of competency required to install, configure, support
and maintain a BI solution.
12. Defining the criteria for evaluation of the BI solutions available in terms of
availability, features, platform, costs, ease of use, complexity, interfaces, and
outputs.
13. Establish if BI always requires a Data Warehouse (DW). Could BI be
integrated directly with an OLTP system to provide the required information
to improve operational and strategic planning without the need for a full blown
DW?
14. Implementing a BI solution for the case study company.
15. Establishing an actual BI selection framework.
1.3 The Hypotheses
The first hypotheses states that the primary purpose of BI applications is to
facilitate attainment of an organizations overall strategy or mission through provision
of visibility to KPIs which have been derived from an organizations strategic goals.
The second hypothesis proposes that lack of knowledge of BI tools and their
capabilities among both IT and non- IT decision makers contribute to its low take-up
in SMEs.
The third hypothesis states that SMEs aware of BI solutions do not pursue
such implementations due to perceived cost and lack of resources.
- 22 -
The fourth hypothesis is a small amount of the overall data held by
organizations is used for strategic and operational planning. Efforts should therefore
concentrate on preparing this subsection of data for analysis in resource constrained
projects.
The fifth hypothesis proposed that there is an affordable BI solution for SMEs
which can be used successfully post installation by properly trained end users to attain
sufficient information to facilitate improved operational and strategic planning with
minimal support.
1.4 The Scope of the Thesis
The study relates to SMEs in the manufacturing industry sector only. This
group is more likely to be using ERP than non manufacturing entities. For the
purposes of this study a variant of the European Commission’s definition of an SME
is used to categorize the organizations to which the study relates. The European
Commission defines SMEs as those “made up of enterprises which employ fewer than
250 persons and which have an annual turnover not exceeding EUR 50 million, and/or
an annual balance sheet total not exceeding EUR 43 million.” The study is extended
to those employing up to 250 and/or a turnover of up to EUR 100 million.
The primary focus was on developing a framework for integrating BI
technology with ERP systems for the SME sector. The study analyses the use and
availability of BI solutions within the SME segment. The study suggests mechanisms
to ascertain if BI solutions meet the requirements of SMEs in terms of content, cost,
ease of use; skill set requirements, ongoing support, development and maintenance
needs. The analysis ascertains awareness in the sector of integrated BI sold as part of
ERP packaged solutions, proprietary offerings sold as bolt-on options to existing
systems and open source BI packages.
- 23 -
The constraints assumed for businesses in the SME segment include
organization size, budget, the availability and competencies of IT staff, the
availability and competencies of non-IT staff to champion the project, and the
attitudes of decision makers.
1.5 The Significance of the Study
In general BI has been IT-led as business people in general have a lesser
understanding of what technology can do. SMEs need BI tools integrated with their
financial (and other) applications, so they can get access to some of the benefits
without having to go through a major BI implementation requiring dedicated IT
experts to install and maintain it. Such applications should allow users (not only
dedicated IT resources) to access the financial and operational data residing in the
ERP systems in a quick, easy, efficient and cost effective manner. Many ERP
systems are used for accounting and transaction management such as inventory,
material requirements or capacity planning but they fall short on reporting capabilities
with many SME’s attempting to plan and manage their operations with spreadsheets.
Standard reports may take days to produce requiring expert programming skills or
users generate large spreadsheets which are prone to erroneous entries. A lot of SMEs
produce very basic reports and don’t have the knowledge, skills or resources to tackle
BI even though it is vital that they have good operational and strategic intelligence.
The main problem faced by SMEs when it comes to ERP is that their requirements are
limited while the products offered are often feature rich, much of which will never be
used and fall outside the specification of requirements adding unnecessary cost and
complexity. A balance needs to be made between needs and costs. ERP vendors have
in recent years shifted their focus from large enterprises to the SME market. There is
now an opportunity to define best practice in sourcing and implementing a solution to
- 24 -
meet the real information needs of the SME. By finding a solution that meet the needs
of this sector it is hoped the wider community will benefit from reduced costs,
improved information, centralised information stores, adaptable and flexible software
solutions which eliminate wasted effort by eliminating duplication, reduce data
inconsistencies and facilitate better decision making.
1.6 Success Criteria
Success is measured by the ability of the author to prove or disprove the
hypotheses listed. This is can only be achieved by dealing with and resolving each of
the sub-problems described. The survey and literature review will be used to test the
first three hypotheses. The case study will test the fourth and fifth hypotheses with a
primary focus on ascertaining if there is an affordable BI solution for SMEs which
can be used successfully post installation by properly trained end users to attain
minimal support.
- 25 -
Chapter 2 - Literature Review
2.1 Introduction
The literature review will look at both ERP and BI implementation and
integration concepts to provide guidance on what factors need to be considered when
embarking on a BI project which integrates with an ERP system in an SME
environment for the purpose of improving operational and strategic planning.
Evidence to support the hypothesis stated in Chapter 1 is sought as part of this review.
Defining what is meant by the term BI and determining the meaning of operational
and strategic planning as part of the review will provide the focus for the case work
undertaken in terms of what is to be achieved by integrating BI with ERP. The
purpose of the literature review is to expose best practice in implementation and
integration strategies, define operational and strategic planning and heighten
awareness of the BI solutions which are currently available. This information will
then be used along with the primary research to produce a BI selection and integration
framework document for SMEs.
2.2 Motivation
Organizations extract data from many sources in order to gain insight into
their operations to aid decision making and improve performance. These information
sources can be as varied as spreadsheets, specialist applications packages such as
Enterprise Resource Planning (ERP), Customer Relationship Management (CRM),
Business Performance Management (BPM), BI), KPIs, Industry articles, the Internet
and a host of functional specific applications. When selecting a system, a primary
objective should be to ensure the system fits the business and not the other way
around. Much effort is also wasted in maintaining multiple versions of data.
- 26 -
Organizations need to ensure they are maintaining a single version of the truth by
capturing the correct data to facilitate good operational and strategic planning. It is
important that data is captured at source, eliminating error prone duplication. Data
integrity is a prime factor in inspiring confidence in the users of that data, so data
capture should be reliable, timely and accurate. Data needs to be stored and processed
in a consistent and traceable manner, and it must be flexible for analysis and output.
Data should be available at the required time to facilitate decision making, not after
the event when it is too late to do anything with other than historical analysis.
Ensuring the organization is capturing the data required to produce good BI and thus
improve operational and strategic planning is a critical factor. Without the correct
base data at the lowest level, information will be scant and incomplete in subsequent
intelligence applications. This literature review will therefore focus on ensuring the
best base data is available by looking at the factors effecting ERP implementations. A
successful ERP implementation satisfying the business requirements will form a
strong foundation for a BI solution so it is worth offering some guidance on
successful ERP implementation to those embarking on projects of this nature in
advance of exploring what BI offerings are available and capable of being integrated
with the ERP system to satisfy the needs of the SME. To those organizations who
have already implemented an ERP system, a critical evaluation of the resultant system
is advised to ensure the data required to produce BI information is available and that
the processes support the organization’s business goals. A study of BI in its many
forms will be undertaken to facilitate understanding of the technologies currently
available and determine the best integration approach for SMEs.
- 27 -
2.3 ERP – Implementation Success Factors
According to Koch, (Finney & Corbett, 2007), ERP systems are designed to
address the problem of fragmentation as they integrate and streamline internal
processes by providing a suite of software modules that cover all functional areas of a
business. ERP systems may be off-the-shelf standard solutions or custom applications.
Custom applications are a very expensive option for SMEs and they carry a large risk
due to the uncertainties associated with choosing appropriate development tools, the
duration of the development life cycle and the difficult task of determining costs
(Scheer et al., 2000). Scheer at al. (2000) made a number of observations in their
study on the use of business models to achieve ERP implementation success. With
regard to ERP they have identified that major ERP vendors such as SAP, Baan and
Peoplesoft estimate that customers spend between three and seven times more on
implementation costs than the cost of the software license. Much of the cost is
associated with customizing, configuration and implementation (SAP R/3 comprises
more than 5000 different parameters). SMEs cannot afford to pay such high costs so
Scheer et al. (2000) advocate the use of modeling methods, architectures and tools to
help reduce these costs and gain better acceptance of the product by:
• Reducing the effort for creating the target concept by leveraging “best practice
case” knowledge available in reference models
• Create a requirements definition by leveraging modeling techniques to detail
the description
• Document the system requirements definition by means of conceptual
modeling methods to make the business logic more understandable.
• Leverage conceptual models as a starting point for maximum automation of
system configuration.
- 28 -
Wyderka (2001) suggests the existence of a number of ERP implementation
states.
1. A single, vanilla installation of the ERP software where data from legacy
systems has been converted and migrated to the ERP implementation.
2. A single, vanilla installation of the ERP, plus historical data sitting in idle
legacy systems. This requires data consolidation to view historical trends
3. A single, enterprise-wide ERP application with many customizations. This
requires a customized data warehousing environment.
4. Some components of the ERP system are in use, and disparate systems are
used for other functionality based on using function specific best of breed
solutions as opposed to more generalised ERP offerings
5. Multiple business units utilize multiple ERP systems to perform similar
business functions as a result of merger or acquisition
ERP implementation should involve the analysis of current business processes
and reengineer where appropriate as opposed to embedding poor processes into a new
application. Skok & Legge (2001) describe an ERP implementation as “a change
management initiative, which encompasses a review of the processes across the whole
organization, requiring careful management.” They further state “This may be
achieved via a Business Process Reengineering (BPR) exercise, which can be viewed
as the prologue to the implementation.” A number of software vendors or associated
consultancies offer reference models with built in knowledge and best practices but it
is important to ensure the system fits the business and not as previously stated the
other way around. The SAP R/3 software documentation reference model is one
example quoted by Scheer et al. (2000) which utilizes the Event-driven Process chain
method. Brown (2004) shares lessons learned from a failed ERP implementation
- 29 -
attempt which were subsequently considered and rectified in a second successful
implementation. These factors apply equally to any Information System (IS) project
of a sizeable nature such as BI:
• Create a schedule and stick to it.
• The organization must realize that the implementation in progress is the most
important thing that it is currently doing.
• Limit customizations.
• Document processes – useful both in implementation and training.
• Train all personnel.
• Do not rely solely on the IT department to develop/implement – use external
experts.
• IT and Executive (High level Sponsor) involvement is required continually.
• The makeup of the project implementation group is a critical success factor
and it must contain executive support.
• Relegating management away from the project will be detrimental to the
outcome.
• Pay attention to data quality.
• Agree the scope and ensure it includes everything the organization needs it to
do.
• Agree the cost on a fixed fee basis (agree the scope for the fee determined).
The vendor may not add or remove items without prior agreement. Beware of
feature creep.
This author’s own opinion would concur with the above. Having been on the
team of a successful ERP implementation across 3 sites, deemed to have been
implemented within budget and on-time, the critical success factors outlined above
- 30 -
were used in the implementation. In particular the project implementation was
spearheaded by a Steering Committee comprising of a group level senior executive,
the Managing Director of each site, the site IT Managers, site Finance Directors,
vendor account manager and vendor project and technical specialists. At each site the
Key User concept was utilised, involving individuals from each functional area.
Additional lessons learned by Brown (2004) include ensuring the project has
sufficient resources, which in terms of people may mean staffing up, not down, since
team members may leave and you need to be in a position to cover the loss.
Communication and change management are very important aspects of a successful
implementation and functional area leaders should be given ownership for their area
and regularly brief management on progress. They in return get the credit (or discredit
) for that progress. In essence this amounts to good project management practices.
Finney & Corbett (2007) explored the current literature base of Critical
Success Factors (CSFs) of ERP implementations in an attempt to identify previously
identified CSFs. Post an exhaustive search using key terms in association with content
analysis and inductive coding they identified 26 categories of success factors:
• Top management commitment.
• Visioning and planning - identifying clear measurable organizational goals
and objectives and linking business and IS strategies.
• Build a business Case – conduct economic and strategic justifications for the
ERP Implementation.
• Assign a Project Champion – someone with strong managerial, technical,
personal and leadership skills.
• Define implementation strategy – consider centralized or decentralized, single
or multi-site, phased or big-bang implementation approach.
- 31 -
• Vanilla ERP – implement the standard version, minimize modifications.
• Project management – use a steering committee and embrace project
management best practice.
• Prepare a change management plan for the implementation and build user
acceptance.
• Balance the team by utilising resources which span the organization needs and
skill-sets. Ensure the correct balance of IT and business users on the team and
use the organization’s best and brightest individuals.
• Define a communication plan for the project.
• Utilize empowered decision makers – make sure the team include those with
the autonomy to make the necessary decisions.
• Maintain morale and motivation during the implementation.
• Prepare and agree project costs making allowances for the unforeseen.
• Conduct Business Process Requirements analysis and reengineer if
appropriate.
• Consider legacy systems – decide on migration/conversion of data and identify
current issues to be overcome.
• Assess the IT readiness of the organization – what infrastructure is required to
support the implementation.
• Consult with the organization’s clients – this information will be useful in
determining needs as well as avoiding misconceptions.
• Select an ERP system to match the business processes.
• Consider hiring an independent ERP consultant to help with selection, but
ensure there is a transfer of knowledge from the consultant back to the
organization to minimise reliance post implementation.
- 32 -
• Include training and job redesign as part of the implementation. The system
may introduce new processes, changed processes or remove processes.
• Plan for troubleshooting and crisis management - prepare a risk mitigation
plan.
• Consider data conversation and data integrity of existing and converted data.
• Road test the implementation and perform simulation exercises.
• Perform post implementation evaluation.
Although Finney & Corbett (2007) identified quite a number of CSFs, they
indicate one of the most important findings with regard to the study is the lack of
support for stakeholder’s views of critical success factors. Some literature looks at
one CSF from a number of stakeholder’s perspectives or a number of CSFs from one
stakeholder’s perspectives but there is very little research which views the
implementation as a whole from the many stakeholders’ perspectives of success. This
is noteworthy when planning an implementation. What is the definition of success?
There will be many different answers depending on who you ask, and this should be a
consideration when defining the metrics upon which the implementation should be
measured. Skok & Legge (2001) believe the environment in which ERP software is
selected, implemented and used may be viewed as a social activity system, which
consists of a variety of stakeholders e.g. users, developers, managers, suppliers and
consultants. Like Finney & Corbett (2007), Stok & Legge (2001) recognise the
perspective of various stakeholders in determining CSFs. They used Bancroft’s nine
critical success factors as a basis to interview firms who have or were in the process
of implementing ERP systems to identify the key issues of concern with individuals
who have been involved in and managed the ERP change process. In summary the
nine CSFs were:
- 33 -
• Communicate continuously.
• Provide superior executive championship for the project.
• Understand the corporate culture and ascertain its readiness for change.
• Begin business processes changes prior to implementation.
• Use an effective project manager sufficiently skilled and empowered.
• Choose a balanced team.
• Select a good project methodology with measurements.
• Train users and provide support for job changes.
• Expect problems to arise.
Interestingly Stok & Legge (2001) found executive championship should
come from the MD as utilizing any other less senior executive may result in the
project being viewed as a cost saving exercise or just another IT project. Political
manoeuvring can sabotage the project. In general there was support for the nine CSF’s
identified by Bancroft (in Stok & Legge, 2001) with some slight variation. Of interest
was the identification of using hybrids, i.e. individuals with both business and
technical knowledge on the project to work with consultants since they will not accept
as readily the views of consultants and will challenge in the interests of the
organization and the project. They can also create some savings by requiring fewer
consultants on the team. Also having a strong leader was viewed as more important
than a good project methodology by those interviewed. So the question to be
answered is: How does one integrate BI and ERP systems in SMEs to improve
operational and strategic planning? The remainder of this paper will attempt to answer
this question
- 34 -
2.4 SME Specific Constraints
Van Everdingen et al. (2000) found that clients ranked the fit with current
business processes as the most important selection criteria for a new system, while at
the same time, organizations within the mid-market rate a low price and short
implementation time as highly important. In an attempt to address these needs some
vendors are offering accelerated implementation methods usually based on offering a
minimal fit which defeats the purpose of the number one priority of best fit (Van
Everdingen et al., 2000).
In a survey of 2,647 organizations across ten European countries van
Everdingen et al. (2000) deciphered that European midsize organizations tend to focus
on product characteristics rather than on characteristics of the supplier of the product.
Smaller budgets and restricted resources are generally cited as pressures faced by
SMEs, yet Glick (2006), suggests that a survey of 4347 IT managers and 839 finance
managers in 2005 indicates that priorities for smaller business are similar to those of
their larger counterparts. The survey (Glick, 2006) backs the second hypothesis
herein which proposes that lack of knowledge of BI tools among both IT and non-IT
decision makers contribute to its low take-up by stating that “SMEs cannot rely on IT
vendors to actively promote emerging technologies to smaller customers.”
Gartner (2006) cautioned that significant inhibitors to the successful
deployment and adoption of BI exist. They said that limited BI skills and
competencies combined with a perceived high total cost of ownership (TCO) and
difficulty in quantifying the direct business benefits of better performance and
improved decision making continue to hamper adoption. This concurs with the
present author’s opinion that SMEs aware of BI solutions do not pursue such
- 35 -
implementations due to perceived cost and lack of resources, however Robert
Anderson, Gartner’s research president for SMEs, (in Barker, 2007), said: "We expect
to see mid-market organizations increasing their adoption of BI, as vendors offer
more targeted products that are tailored for organizations with fewer IT resources and
smaller budgets." For many organizations adopting BI is challenging. McKendrick
(2008), cites poor quality data, complexity of BI tools, lack of BI skill sets within the
organization and lack of management buy in as the factors most inhibiting BI
implementation projects. The complexity of some solutions prevents organizations
from leveraging maximum business benefit from BI tools. Citing software license
costs as the main BI inhibitor, McKendrick (2008) indicates some of the alternatives
being investigated by organizations to overcome the high costs are:
• Open source software
• On-demand or Software as a Service (SaaS)
• Limit use to minimize license fees
• Subscription based software licensing (monthly or annually)
2.5 Operational and Strategic Planning
Alice: Which way should I go?
Cat: That depends on where you're going.
Alice: I don't know where I'm going!
Cat: Then it doesn't matter which way you go!
Hughes (2001) introduces the topic of strategic planning with the above quote
from Carroll (1872) which aptly positions the organization with no clear mission.
Goodstein, Nolan and Pfeiffer in Hughes (2001) define strategic planning as “The
- 36 -
process by which the guiding members of an organization envision its future and
develop the necessary procedures and operations to achieve that future”
The steps in Strategic planning are as follows (QuickMBA, n.d.):
1. Define mission objectives
2. Complete an environmental scan
3. Formulate the strategy
4. Strategy implementation
5. Evaluation and control
BI facilitates achievement of the mission objectives through providing the
required information or intelligence to the decision makers with regard to the
evaluation and control of predefined metrics. When formulating a strategy it is
important to identify the metrics which will be used to measure its effectiveness.
Within the evaluation and control step, the following actions are identified as a means
to measure the outcomes of the implementation of the strategic plan:
• Define the parameters to be measured – the metrics
• Define target values for those metrics – (standards, budget, forecast etc.)
• Perform the measurements
• Compare measured results to predefined standards
• Make necessary changes
“It is a continuous process of implementing policy and receiving how those
policies either successfully or ineffectively achieved the goals they were set and to
attain results in increased efficiencies for the organization (Saha, 2007).” According
to Mandal and Gunasekaran (in Finney & Corbett, 2003), planning should incorporate
a certain degree of risk and quality management. The Business Intelligence Guide
- 37 -
(n.d.) makes the following distinction between Strategic and operational planning
requirements from a BI system.
• Strategic decision support - analysis of large amounts of data at less frequent
periods, but requiring high processing capacity
• Tactical decision support - repeated access to only a limited amount of data,
in real time or very frequent intervals. Queries are small, requiring less
processing
Cambridge University conducted a survey of NI based SMEs in 2004 and
found that over forty per cent of the NI sample (853 respondents) does not have
monthly management accounts, only 13% have a human resources plan and less than
50% have a business plan. It would appear there is some work to do in defining the
metrics to be monitored in advance of any system selection in the SME sector.
2.6 Business Intelligence Concepts
BI once the mainstay of large corporations has moved away from core
analytics as a distinct function to operational BI, embedded into business processes
supporting automated decision making and exception management. Alchemex (2009),
identifies the ultimate goal of a good BI platform as a means for people in the
organization to “help themselves” to relevant information that they can trust. It is
critical to free up resources (usually within the financial and IT departments) that
have historically spent most of their time preparing and sending out ad-hoc
unstructured information to the rest of the business. BI means different things to
different people. The Business Intelligence Guide (n.d.) suggests for IT, BI innovation
is about a single platform for delivering information in many different ways to many
different users, depending on their needs, whilst for business users, it means finding
- 38 -
the answers they need automatically from whatever application they normally work in
every day.
The BI spectrum is very broad in terms of its tools and functionality. At its
core are the traditional capabilities of query, reporting, and analysis. This is
complemented by data quality and data integration to accurately and consistently
consolidate data from multiple sources. Dashboards and other visualization techniques
can help users quickly understand analysis results and are often considered part of the
BI spectrum, as are search capabilities to locate information and reports, and
predictive analysis to discover hidden patterns and enable what-if analysis. The
primary objective of this study to provide guidelines to the SME sector on how best to
achieve this within the constraints imposed on organizations in this sector.
2.6.1 BI Evolution
Before embarking on any BI specific selection activities it is important to
determine the meaning of BI. To do this it is necessary to explore the evolution of BI
and the many flavours of it that currently exist. Connolly & Begg (2005) suggest that
since the 1970s, organizations have mostly focused investment in new computer
systems to automate business processes, but one of the offshoots of this investment
was the mass accumulation of data stored in operational databases. The operational
systems were never designed to support utilising this data in decision making to gain
competitive advantage and many organizations had numerous operational systems
with overlapping and often contradictory definitions, such as data types, presenting a
challenge for the organization to turn its archives of data into a source of knowledge,
so that a single unified view of the organization’s data could be presented to the user
(Connolly & Begg, 2005). The original concept of a DW was proposed by IBM (then
referred to as an information warehouse) but early attempts were rejected due to
- 39 -
complexity and performance issues. Bill Inmon coined the term data warehouse circa
1990 and defined it as “A subject-oriented, integrated, time-variant, and non-volatile
collection of data in support of management’s decision-making process, (Reed, n.d.).”
An expansion of the definition explains each individual concept contained therein.
• Subject Oriented: Data that gives information about a particular subject
instead of about a company's ongoing operations.
• Integrated: Data that is gathered into the DW from a variety of sources and
merged into a coherent whole.
• Time-variant: All data in the DW is identified with a particular time period.
• Non-volatile: Data is stable in a DW. More data is added but data is never
removed. This enables management to gain a consistent picture of the
business.
These conceptual ideas of a DW have loosened somewhat today to allow data
to be volatile by removing and archiving older data and a single-subject DW is
typically referred to as a data mart, while data warehouses are generally enterprise in
scope (Reed, n.d.). Golfarelli et al. (2004) suggest that BI became an object of interest
for the academic world in the mid-90’s leading to Online Analytical Processing
(OLAP), multidimensional modeling, design methodologies, optimization and
indexing techniques which converged to define the modern architectures of data
warehousing (DW) systems. They believe however that the new requirement of
managers is to ensure that all processes are effective by continuously measuring their
performance through KPIs and score cards.
2.6.2 BI Definitions and Purpose
BI is “any information that can be of strategic use to a business, (Business
Intelligence, 2006).” It is further defined by Saha (2007) as “a business management
- 40 -
term that refers to applications and technologies used to gather, provide access to, and
analyze data and information about an organizations operations, (Saha, (2007).” On a
simpler note Business Intelligence (2007) describes it as “information that may be
useful to a business when it is planning its strategy,” while Golfarelli et al. (2004)
state “BI can be defined as the process of turning data into information and then into
knowledge.”
2.6.3 BI Trends and Good Practice
For SMEs amalgamating and consolidating vast amounts of data from various
global sites is less likely to be a concern as making sense of the day to day
operational, data, linking that with strategic data to ensure achievement of the
organization’s goals. The Business Intelligence Guide (n.d.) forecasts a number of
trends and BI best practice including:
Alert Based KPI Reporting: Every morning executives will check their latest
performance metrics before they check their e-mail but where the number of KPI’s
used is large this will be on an exception basis to highlight areas requiring attention.
Operational BI: BI solutions will include more real-time capabilities to make it
easier to push information to business users in context and in real time. This includes
fully integrated solutions and industry specific configurations which make it easier for
business users to deploy BI models in real time and from any online device supporting
a service-oriented architecture.
Educate the business: Many business users either don't have the insight or the time
to explore what is possible with real-time BI. By developing prototypes of potential
new BI systems that would manage hub operations better, users realize that
technology can help them improve the way they manage their business.
- 41 -
Plan ahead: Customer-facing programs and monitoring of critical business processes
constantly demands fresh data. Regardless of what BI tools are deployed, once users
recognize the value of reliable, consistent data they will make demands for data
latency to be reduced even further. Reaching real-time BI requires implementation of
real-time technologies.
Align decision making with business processes. Gile, K. & Teubner (2006), believe
BI software has long stood alone, taking data from various applications and
combining it to provide useful information for decision-makers, but simply joining
data from applications' data mart silos misses part of the picture; such reports lack the
context of the business process in which the data was created. By combining BI and
business process management (BPM) technology, organizations can add process
context to their reports while simultaneously reaping all benefits of using BI within
the process execution environment. “Translating the company strategy into a detailed
set of indicators that are closer to the operational tasks allows employees to better
understand the desiderata of managers. (Golfarelli et al. (2004).”
Choose the right people: BI requires more understanding of how the business works.
Building standard business value libraries and Master Data sets needs a contextual
basis. Good technical skills do not necessarily translate into good BI skills. There is
perhaps scope to use hybrids as indicated earlier, those with both business and IT
skills.
2.7 BI Solutions
BI technology may be packaged into the following broad areas (The Business
Intelligence Guide, (n.d.) :
• Standalone BI tools - such as reporting, analytics, scorecards, dashboards
• Packaged BI suites - an integrated set of BI tools
- 42 -
• Integrated with DW - such as Teradata Active DW
• Point solutions - tools designed for a specific business need
• BI Software as a Service [SaaS] – On Demand BI capability
• Cloud Computing - a platform as a service offering
• Open source BI
It is worth expanding on some of the above technology concepts particularly
those promising to be a low cost option for the SME market as an alternative to costly
BI software licensing.
2.7.1 Standalone BI Tools – Reporting, Analytics, Scorecards, Dashboards
Tools such as MRC-Productivity may be the answer to the SMEs problems
offering the ability to integrate with organization data on any platform (Windows,
Unix, DB2, Linux). Such products permit development of reports, analytics,
scorecards, dashboards and web portals in one application. Licensing is based on a per
platform basis as opposed to per user (with no limits to the number of users), so it can
be cost effective where application platforms are fairly homogenous. Where internal
IT resources are available it claims to be a simple deployment or the vendor will
deploy and create any applications using rapid development utilities. It does not
require a DW or OLAP cubes (users can create their own summaries) but it could use
them where they exist. See examples of outputs attainable below (Figure 1 and Figure
2).
- 43 -
Figure 1. Example of MRC Productivity developments including operational BI.
__________________________________________________________________
Source: MRC (n.d.)
Figure 2. MRC Example of operational BI presenting real time data
_______________________________________________________________________________
Source: MRC (n.d.)
2.7.2 Software as a Service (SAAS)
A survey of 1029 SMEs from the North of England indicated 76% of those
surveyed access the web via broadband technologies (Robertson et al., 2007) so the
possibility of using SaaS is a possibility for some SMEs. Alchemex for example,
- 44 -
announced the launch of its Software-as-a-Service (SaaS) offering in December 2008.
The product includes a customer dashboard for Sage50 users giving a graphical
overview of various critical parts of the user’s business on one worksheet. The same
workbook also contains monthly and year to date worksheets. The Website gives
Sage50 snapshots in Excel without the need for client expertise in data extraction. The
application is specifically designed for small businesses providing a secure online
reporting solution which delivers automated financial and business management
reports off a company’s own data and in a familiar Excel format, making BI
technology easy and accessible without the need for specialist IT staff. The service is
available for as little as $25 a month. Other examples of SaaS BI offerings include
Cognos Now, NetSuite Small Business, PowerApp – Cloud BI Solutions and SAS BI
on Demand for SMB
2.7.3 Open Source
McKendrick (2008) says respondents to a survey on the use of BI tools
indicates organizations are still hesitant, declaring concerns in relation to security and
skills availability, however, close to half of those surveyed already using open source
believe lack of awareness is the primary factor contributing to this thinking.
Organizations like Pentaho and JasperSoft appear to be leading the charge for the
open source BI market. Karel & Goulde (2007) believe smaller organizations are
more likely to support a homogenous IT environment with minimal data migration,
integration and transformation requirements so lower cost open source BI and Extract,
Transform and Load (ETL) tools may be more suited to this segment, however they
warn that ETL tools to connect with Enterprise applications like SAP, Oracle and
Peoplesoft for example are not free. Also connectors for non Relational Database
Management Systems (RDBMS) systems may be cost options since they may require
- 45 -
something other than the standard ODBC, JDBC type connectors. Pentaho
Corporation also differentiate between “professional open source” and “open source”
where professional open source refers to an open source project with professional
technical support and commercial backing, in contrast to a project without these
services.
2.7.4 Cloud Computing
The “Cloud" refers to the Internet and when combined with computing it
basically refers to virtual servers available over the Internet. SaaS is a form of cloud
computing and providers like Salesforce.com are offering SaaS type BI products as a
cloud computing product. Amazon, Microsoft and Google are among the leaders in
the cloud computing arena with products such as Amazon EC2 and Microsoft’s Azure
platform.
2.8 BI Approaches
This section will explore the variants of BI tools currently being marketed. In
many cases such tools may be overkill for the SME but there are overlaps between
many of them, exploration of which will enhance the repository of knowledge to
facilitate better decision making when selecting a solution.
2.8.1 Data Warehouse
A DW is an element of a reporting infrastructure common in large
organizations. A DW is a dedicated software and hardware platform for integrating
enterprise data from multiple sources. It uses scheduled routines for pulling data from
transactional systems and for cleansing data. The purpose of a DW is to establish a
comprehensive source of enterprise data. DWs are normally associated with large
organizations due to the complexity and resources required to implement and
- 46 -
maintain them. Data marts are smaller, subject oriented structures either extracted
from a DW or used to feed a DW.
2.8.2 Business Performance Management
Golfarelli et al. (2004) believe organizations have understood the importance
of enforcing achievement of the goals defined by their strategy through metrics-driven
management; however the DW process, though supporting bottom-up extraction of
information from data, fails in top-down enforcing the company strategy. They
discuss what they deem the new approach to BI, referred to as Business Performance
management (BPM). BPM includes DW but it also requires a reactive component
capable of monitoring the time-critical operational processes to allow tactical and
operational decision-makers to tune their actions according to the company strategy.
Figure 3 presents a graphical representation of a complete architecture for BPM as
proposed by Golfarelli et al. (2004). The model consists of the traditional DW
components on the left and a more reactive data flow on the right suited for
monitoring time-critical operational processes. This study will need to determine how
the SME can utilise tools such as alerts, dashboards, reports and OLAP type multi-
dimensional analysis based on the constraints in the sector.
- 47 -
Figure 3. A complete architecture for Business Performance Management (BPM).
_______________________________________________________________________________
Source: Golfarelli et al. (2004)
2.8.3 Customer Relationship Management
“Customer Relationship Management is a strategy that supports an
organization’s decision-making process to retain long-term and profitable
relationships with its customers, (Cunningham & Song, 2007).” Although not
immediately apparent applications like CRM are crossing the line with BI in terms of
monitoring customer sales information and reacting to sales trends and analysis. CRM
applications may include modules for:
- 48 -
• Sales and Marketing: Work with leads, customer contacts, account
information, campaigns, discounts, pricing and margins
• Activity Management: Monitor customer transactions and contact
information, purpose and frequency of contact etc.
• Service and Support: Log and expedite customer support cases
Also included in the mix here are areas such as customer profitability, product
profitability, market profitability, channel and campaign profitability etc. In Figure 4,
Cunningham & Song propose a taxonomy of CRM Analysis types which is useful for
designing DWs, validating data schema, and linking customer data to associated
business metrics such as KPIs.
- 49 -
Figure 4. A taxonomy of CRM analysis types.
__________________________________________________________________
Source: Cunningham & Song (2007)
- 50 -
2.8.4 Dashboards
Dashboards give you a quick overview of how your business is doing based on
some key figures using meters, dials, traffic lights as in Figure 5.
Figure 5. Example of a performance dashboard.
_______________________________________________________________________________
Source: MicroStrategy (n.d.)
2.8.5 Scorecarding
Scorecards help organizations to communicate goals, establish key
performance metrics and measure performance as may be seen in Figure 6.
- 51 -
Figure 6. Example of a scorecard
_______________________________________________________________________________
Source: IBM Cognos (n.d.)
2.8.6 Key Performance Indicators – Translating the Organization’s Strategy to
meaningful metrics
Business data analysis should be associated with KPIs which in turn should be
used to measure achievement of the operational and strategic planning objectives.
Cunningham & Song (2007), display a method of linking an analyses category to the
business question to be answered, the use of the outcome of the analysis and the
metric to be produced in terms of the associated KPI (see Figure 7). Such a
methodology may be useful in documenting the translation of the organizations
strategic and operational plans to the analysis and metrics required to be built into the
BI solution
- 52 -
A Taxonomy of CRM classes
Figure 7. Excerpt of a taxonomy of CRM analyses (S=Strategic and T=Tactical)
__________________________________________________________________
Source: Cunningham & Song (2007)
KPIs in a manufacturing environment are many and varied and cross every
functional area from finance, sales and marketing, production, warehousing, transport
and distribution, supply chain, quality, IT and more.
KPIs may include:
• Top customers
• Revenue by customer
• Margin by Customer/Product, by market,
- 53 -
Production KPIs may include:
• Machine Downtime
• Machine Efficiency
• Production quantities
• Efficiencies
• Run and stop time
• Stoppage frequencies
• Reject rates
These low level KPIs may be required:
• On demand
• Automatically
• Batch
• Shift
• Day
• Week
• Month etc.
The important task for any SME will be to identify the critical KPIs, the 20%
that tell you 80% of what you need to know to improve operational and strategic
planning. This study will look at KPIs from the perspective of how they should be
built into the BI solution for the SME.
2.9 BI Implementation Considerations
This paper has up to this point dealt with ERP and BI concepts generally,
along with operational and strategic planning concepts and their translation to the
business processes to enhance the knowledge of the broad array of BI methods
- 54 -
available having considered the constraints on the SME. The following are some basic
considerations or good advice when implementing a BI project.
• Organizations need to analyze the way they make decisions and consider the
information executives need to facilitate more confident and more rapid
decision making as well as how they would like that information presented
(Saha, 2007).
• Define the performance metrics which are most relevant to achieving the
business objectives.
• Define the expected ROI and benefits to be achieved from the implementation
and monitor continuously against this at specified intervals (Saha, 2007)
2.9.1 Data Requirements
One of the sub-problems suggested in the thesis statement was ascertaining
what data an SME requires to enable operational and strategic planning to take place,
in other words, what data need to be stored? Often those who require information are
not close to the source of the information and may have little understanding of how
the data is stored at a low level within the system. Very often the data required to
generate the operational and strategic information may not exist in the source
system(s). Alchemex (2009) concur with this need to decipher the availability of
existing data and suggest before selecting any BI solution it is important to ascertain a
number facts with regards to data availability such as:
• Does all the information required exist in the existing source data?
• If not, can it be derived from the source data?
• Is there a need to gather data from multiple sources?
• Is the information related/structured or unrelated/unstructured?
- 55 -
• Has the data been consistently captured over the time frame required for
output?
• Depending on what tools you are using, are there any relevant solution
sets/templates that can help fast track the solution?
• Who needs to get the information, how often, and how and where are they
connected and located?
Where information does not currently exist, decisions will need to be made as
to how to make it available to or within the chosen BI solution. The need to gather
information from multiple sources may add complexity to the implementation. The
location and access methods available to the end users of the information may
determine the need for additional interfaces, networking topologies, infrastructure
requirements and security features. All of these aspects need to be considered before
decisions on solutions are made. Data feeding into BI systems should be clean and
consistent in order to get benefits from BI (Saha, 2007). Pay attention to data quality.
Work with data which is relevant to attaining the objectives set out in the planning
phase. There will be much data, a lot of which is irrelevant to producing the required
reports and performance metrics. Concentrate effort on the necessary data. Saha
(2007), in support of the fourth hypothesis set forth in this document identifies
“winnowing through voluminous amounts of irrelevant data and poor data quality,” as
a typical BI implementation issue. Plan for how long data should be stored and
ensure the data storage medium is correctly sized. Real time data will require much
more storage and better performance.
- 56 -
2.9.1.1 Online Transaction Processing (OLTP) versus Online Analytical Processing
(OLAP)
It is worth noting some observations on the characteristics of OLAP structures,
often referred to as cubes, star schemas1, data marts or DWs, which are used by BI
applications compared to OLTP structures as used in ERP system design. Utley
(2008) describes the main concepts of both approaches quite succinctly. The points
relevant to the current research from Utley’s (2008) paper are summarised here:
• OLTP systems are usually normalized database structures built to maximise
speed when entering transactions. They are designed for speed of inserts,
updates, and deletes. OLTP systems minimize repeated data (normalization),
and they limit the number of indexes since indexes slow transaction
processing.
• An OLAP system consists of a relational database designed for speed of
retrieval, not transactions, and holds read-only, historical, and possibly
aggregated data. The term historical can refer to data which is minutes old but
OLAP cubes in general are loaded less frequently.
• OLAP structures are intended for read-only consolidated data. Consolidation
indicates there may be multiple data sources. In OLTP structures there is
usually a single data source. This is an important factor when deciding how to
implement a BI data repository. Generally organizations will have multiple
data sources providing information for operational and strategic planning.
1
A snowflake schema will not be considered as part of the current research. A star schema
consists of fact tables and dimension tables. Fact tables contain the quantitative or factual data and
dimension tables are usually smaller and hold descriptive data that reflects the dimensions, or attributes
of a business.
- 57 -
• Queries utilize joins across multiple tables to get all the required data. Joins
tend to be slower than reading from a single table, so minimizing the number
of tables in a query will boost performance. With a normalized structure,
developers have no choice but to query from multiple tables to get the detail
necessary for a report. De-normalized data structures can improve query
performance by minimising the number of tables.
• A primary benefit of OLAP systems is speed of data retrieval and the ability to
format that data in a way that it is easy to understand. The formatting tools
shipped with BI applications usually facilitate this later requirement.
• In general users will seek aggregated data forms as opposed to getting buried
in detail. Detail is useful to analyse why an exception occurred but as
suggested is probably only relevant to analyse exceptions. OLAP suits data
aggregation. The lower the granularity the larger the fact table of the star
schema will be.
• Hierarchies in OLTP systems are usually stored in multiple tables, whilst in
OLAP systems (star schema in particular) hierarchical dimensions are usually
stored in a single dimension table with a number of subject specific dimension
tables such as the Product Dimension, Customer Dimension or time
Dimension making up the star schema along with a fact table . This approach
minimises joins.
2.9.1.2 Data Mart Design and Implementation
There is a long running debate between Ralph Kimbell and Bill Inmon on the
best approach to implement a data repository for BI (Nishith, 2006). Kimbell proposes
a bottom up approach whilst Inmon proposes a Top down approach. Kimbell begins
with a data mart as a dimensional model for departmental data and views a DW as the
- 58 -
enterprise wide collection of data marts. Inmon begins with the DW as a single
repository that feeds subject oriented data marts. There are advantages and
disadvantages to both approaches according to Nishith (2006) who deliberates that
Kimball’s approach is easier to implement as you are dealing with smaller subject
areas to begin with, but the end result often has meta data inconsistencies and can be a
nightmare to integrate. Inmon’s approach, on the other hand does not defer the
integration and consistency issues, but takes far longer to implement (which makes it
easier for the project to fail. Nishith (2006) provides the following definitions:
“A Data Mart is a specific, subject oriented, repository of data designed to
answer specific questions for a specific set of users. So an organization could have
multiple data marts serving the needs of marketing, sales, operations, collections, etc.
A data mart usually is organized as one dimensional model as a star-schema (OLAP
cube) made of a fact table and multiple dimension tables. ”
“In contrast, a Data Warehouse (DW) is a single organizational repository of
enterprise wide data across many or all subject areas. The Data Warehouse is the
authoritative repository of all the fact and dimension data (that is also available in
the data marts) at an atomic level. ”
It is the author’s belief that for SMEs working under constrained budgets and
resources it is important to deliver early and work simply. A data mart approach may
therefore be more suitable for this sector.
2.9.1.3 Star schema design considerations:
All dimension tables should have a single-field primary key. Fact tables
usually have a composite primary key1. “Queries generally perform much better
against numeric fields than they do against text fields. Replacing a series of text fields
with a numeric field can improve performance on retrievals. Numeric fields also
- 59 -
index faster and more efficiently (Utley, 2008).” Indexes speed up analysis but they
slow down transaction processing. For the purpose of this study however, although it
is preferable to have numeric key values (for performance reasons), the key values
will contain the same information as they do in the ERP system so natural keys2 will
be maintained to permit a better comparison of retrieval methods. Other
considerations relate to granularity. Utley (2008) suggests “granularity, or frequency,
of the data is determined by the lowest level of granularity of each dimension table,
although developers often discuss just the time dimension and say a table has a daily
or monthly grain. The lower the granularity, the more records will exist in the fact
table. The granularity also determines how far users can drill down without returning
to the base, transaction-level data.” It is important to analyse the granularity of the
data available to the BI application. As an example a company may have the ability to
report actual daily sales, but the sales forecast to which it is to be compared is at a
weekly granularity. This notion of granularity is referred to by Utley (2008) as the
fact table grain.
There is no need to store derived values. For example, an individual’s age can
be derived by calculating the difference between the present date and their birth date.
An order line value can be derived by multiplying the unit price by the quantity
ordered or in the case study examples, sales tonnage is calculated by multiplying the
sales qty by the item net weight.
Size is also a consideration when designing a star schema. Each dimension
attribute added to a dimension table has a multiplier effect on the fact table size, so
consider the dimensional attributes carefully.

1
A composite primary key is a primary key consisting of more than one attribute/column.
2
A natural key is a key that is formed of attributes that already exist in the real world.
- 60 -
Some consideration should be given to what is termed Slowly Changing
Dimensions (SCDs). SCD issues occur when the value of an attribute used in a
dimension table changes such as a product previously determined as belonging to one
market segment is re-categorized to another. Historical analysis is no longer possible
since the sales will be split between two market segments. There are a number of
methods which can be considered when designing data marts for dealing with SCDs
which are outlined in Appendix A, Appendix B and Appendix C. Detailed analysis of
the methods is outside the scope of the present study, but reference is made to them
for completeness.
Utley (2008) suggests populating the fact table with more than one
aggregation level can improve performance over running SQL on the fly to aggregate
an existing level to a higher level. By storing the higher level aggregations as part of
the ETL and using an additional attribute on the fact table to identify the aggregation
level such as 0 indicates lowest level of detail, 1 next level of aggregation etc. this
could speed up retrieval noticeably, certainly on large datasets. Another alternative is
multiple fact tables at different aggregation levels.
2.9.1.4 Data mart implementation steps
Oracle (2007) suggests a structured approach to data mart design encompassing
the following steps:
• Designing:
o Gathering business technical requirements
o Identify data sources
o Select subset of data
o Design the logical and physical structure
- 61 -
• Constructing
o Create the physical database
o Create schema objects
o Determine table access structures
• Populating
o Mapping data sources to target structures
o Extract data
o Cleanse and transform data
o Load data to data mart
o Create and store metadata
• Accessing
o Set up intermediate layer for front end tool use (meaningful names on
metadata)
o Maintain business interfaces
o Set up summarized tables for speed of execution
• Managing
o Provide secure access to data
o Manage data growth
o Optimize system for performance
o Ensure high availability
The above steps provide a roadmap to data mart design and implementation.
2.9.2 End User Considerations
BI systems should accommodate different levels of access to the BI data to
accommodate junior staff, middle management, Senior Management and Executives
(Saha, 2007). Eckerson [2] (2007) suggested the importance of mapping users to tools
- 62 -
when implementing BI as a means of moving towards BI self service but he dismisses
BI self service as a myth. The concept is valid but there are some pre-conditions.
Eckerson [2] (2007) suggests creation of a limited set of standard interactive reports
geared at information consumers. These reports can eliminate multiple reports since a
well designed report focuses on a specific domain and will permit multiple users to
apply filters to get what they require. This should according to Eckerson [2] (2007),
should satisfy 80% of users. Report governance is required to ensure the standard
reports repository is controlled and does not become an ad-hoc report tool for end
users. The BI implementation team should provide procedures for requesting new
reports which include a review of existing reports for re-use and an approval process.
Once the standard reports library is created it is important to remove previous
reporting methods used and ensure a single view of the data is being used. Controlled
self service for the information consumer group is the objective. The standard report
library is likely to consist of enquires/reports, dashboards and scorecards. The self
service element comes from application of filters to a broad repository for this group.
The remaining users may be classified as information producers. Enhanced
self service makes sense for this group. Power users should be given report authoring
tools. IT and the business analysts should take responsibility for complex reporting,
OLAP, mining and visualization as indicated in Figure 51.
- 63 -
Figure 8. Mapping users to BI Tools
_________________________________________________________________
Source: Eckerson [2] (2007)
Be prepared to meet user resistance and plan to overcome it. This is evidenced
in the literature in relation to ERP implementations but it applies equally to any IS/IT
project. There would seem to be a general consensus among BI strategists that user
training is of the utmost importance. Saha (2007) and Howson (2009) suggest vendor
training for power users and in-house training for the more casual user customized to
their individual needs.
2.9.3 Development Considerations
Develop the reports and inquiries which will provide the most benefit quickly.
Don’t spend time trying to create the perfect reports initially, create useful outputs
first.
2.9.4 Business Environment Considerations
Gartner (2006) conducted a survey of 1400 CIOs and listed among their
conclusions that organizations should develop user skills and a culture in the use and
analysis of information to be an integral part of achieving business objectives and
driving transformation. They added, one of the key decisions is to move beyond a BI
- 64 -
vision that focuses almost exclusively on information dissemination and start
integrating BI into an organization's strategic planning activities.
2.10 Conclusion
The literature would seem to support the hypothesis that perceived high costs,
lack of skills, insufficient client knowledge about BI applications and lack of
resources are inhibitors to BI adoption in the SME sector. There would appear to be a
very definite move away from traditional data analytics towards more operational BI
providing real time metrics to help improve operational efficiency. There are a lot of
tools available but not all will suit the SME. Implementing traditional DWs are
complex, costly and often fail due to lack of resources, planning or poor data. This
section has looked at the alternative technology approaches which may suit the SME
and satisfy their need for lower cost options. Open Source, SaaS, and BI standalone
tools may be possible solutions for this market. The importance of having quality data
is stressed by highlighting the requirements of a successful ERP implementation to
form the foundation of a good BI solution.
- 65 -
Chapter 3 – Methodology
3.1 Introduction
This section outlines the research methods which were employed as part of the
primary research for the thesis. Each of the methods used are described in the sections
which follow.
3.2 Survey Related Data
Current survey data and market analysis research was used to ascertain the
issues facing SMEs when contemplating a BI project. A survey of manufacturing
SMEs was also conducted as part of the research to determine operational and
strategic planning practices, the level of awareness and use of BI tools among SME’s,
the approach to ERP implementation, the degree to which ERP is actually used where
it is installed, and the acceptability of non proprietary software (SaaS, open source,
cloud etc.). In the case of those who didn’t use BI the survey attempted to find out the
main reasons why. The literature review and survey sought to provide support for the
second hypothesis which stated that lack of knowledge of BI tools and their
in SMEs and also the third hypothesis which stated that SMEs aware of BI solutions
do not pursue such implementations due to perceived cost and lack of resources. The
web-based survey used a checklist and rating method to make it easier to complete
and collate the attitudes, behaviours and pre-dispositions to the use of BI in the SME
segment.
- 66 -
3.3 Case Study
A case study was used to ascertain the information requirements of a
manufacturing organization to facilitate operational and strategic decision making and
to determine the best way to integrate BI with ERP in SMEs. Analysis was performed
using key users to ascertain what information was required to enable operational and
strategic planning. At this point the case study focused on information required as
opposed to specific hardware or software systems in use or to be used. The research
methods used involved interviews with key staff as well as analysis of processes,
reports and procedures used in generating operating and strategic information. It was
useful to establish what information the key users felt was unavailable also. It was
important to define what constitutes operational and strategic information and also
identify the constraints likely to impact selection of a solution. This provided a
benchmark upon which to gauge the potential improvements to be achieved by
implementing a BI solution.
The data gathered went through the following steps as typified in case study
research by Leedy & Ormrod (2005):
1. Organization of data into functional groups – by department and job
function or role
2. Categorisation of data by function into sub groups based on data
analysis. Interpretation of the data presented
4. Identify patterns within the data
5. Synthesis and generalisations as they apply to the case study
The case study included a trial BI implementation as part of the primary
research in Company A, a manufacturing SME. The work involved in the trial
implementation is documented in Chapter 7.
- 67 -
3.4 Content Analysis
Content analysis involves tabulating the frequency of each characteristic found
in the material being studied. This was used to design a comprehensive Business
Intelligence Vendor and Application Assessment Grid which companies could use to
evaluate BI Solutions. Based on a review of literature coupled with knowledge gained
from the case study, a comprehensive list of BI features was consolidated to provide a
guide as to what features could be found in a BI solution. The resulting assessment
grid provides a good starting point for companies embarking on a BI project helping
them to align and compare BI solutions. The content analysis focused on vendor
characteristics, product features, ease of use, costs, architecture, and resource
requirements. This should help organizations focus on their individual requirements.
3.5 Vendor Interviews and Product Reviews
In order to present a more complete picture of BI solutions for the SME, the
study included reviews of lesser known BI delivery methods and platforms, in
particular Cloud Computing, SaaS and Open Source BI to heighten awareness of the
alternatives available to SMEs other than proprietary licensed software. A sample of
each is showcased.
3.6 Exploration of Business Process Modeling Tools
A search of freely available business process modeling tools facilitating WS-
BPEL code generation was undertaken and the Netbeans IDE 6.5.1 complimented by
a GlassFish V2 Server Engine was installed and trialled as a means of orchestrating
web services and automating business processes to provide real-time or operational BI
capabilities. The exploration is a light look at BPEL modelling tools.
- 68 -
3.7 Designing the Framework
A grounded theory approach was used to produce a theoretical framework for
integrating a BI solution in the SME sector. A grounded theory study uses a
prescribed set of procedures for analyzing data with the purpose of constructing a
theoretical model from the analyses (Leedy & Ormrod, 2005). Grounded theory
works through a number of overlapping phases (Dick, 2005):
• Data-collection – any data source (e.g. reading, interviews, conversation)
• Note-taking – brief notes on what is being observed
• Coding – determining categories and properties emerging
• Memoing – notes about hypothesis formed about a category or property, and
relationships between categories.
• Sorting – sort the categories based on subject and relationships
• Writing – typing the sorted categories and properties in sequence and
integrating them into a coherent argument.
Grounded theory is an emergent methodology based on labelling and
categorizing that which is observed. The grounded theory approach uses data
collected through a review of the literature read, analysis of survey and market
analysis data, documented trials relating to physical integration of BI software with
ERP software, content analysis on BI application software features, interviews with
staff at the case study company, interviews with BI vendors and reviews of BI
applications and tools. The framework provides a roadmap to facilitate successful
implementation of a BI solution in an SME sector encompassing best practice and
pitfalls to avoid.
- 69 -
Chapter 4 – Survey Results
4.1 Introduction
This section summarises the main areas of interest raised by the survey
conducted as part of the primary research. The survey return percentage was
approximately 22% of those invited from a population of 110 companies. Six surveys
from the sample were deemed spoilt and discarded due to incomplete answers. The
questionnaire may be viewed in Appendix D. A web based survey tool called Lime
Service was used to design the questionnaire. For consistency of response and speed
of completion the majority of the questions posed required radio button selection or
point and click using checkboxes and drop down lists. There were opportunities in
some instances to enter free format text to supplement survey responses. Participants
were guaranteed anonymity so no individuals or business names will be included in
this report. All responses are summarized and reported statistically.
Potential participants were entered into a web based database. The detail
entered consisted of their firstname, lastname and email address. A unique identifying
token was then generated for each entry to identify the participants and link them to
their response area. Each entry was then sent an email invitation to participate which
included a URL to the survey site encompassing their token identifier. See Appendix
E for emailed invitation content. Reminders were sent after two weeks to those who
had not completed the survey with a maximum of two reminders. See Appendix F for
reminder email content. The survey focused on a number of areas including:
• Operational and strategic planning practices
• The level of awareness and use of BI tools among SME’s
• The approach to ERP Implementation
- 70 -
• The degree to which ERP is actually used where it is installed
• The acceptability of non proprietary software (SaaS, open source, cloud etc.)
The purpose of conducting the survey was to provide evidence to support the
hypothesis stated, particularly:
The second hypothesis: Lack of knowledge of BI tools and their capabilities
among both IT and non- IT decision makers contribute to its low take-up in
SMEs.
and
The third hypothesis: SMEs aware of BI solutions do not pursue such
implementations due to perceived cost and lack of resources.
The research also sought to determine the level of detail maintained by
companies on KPIs, particularly their link to corporate goals. For those companies
using BI applications information relating to their view of the application as an IT or
end user tool and expectations on cost were also sought. Finally resource
requirements in terms of people dedicated to IT and BI support roles was also
included.
The survey was targeted at CEOs, CIOs, IT Managers and Business Analysts.
Although the sample size was small the returns do give a flavour of the attitudes
prevalent within the SME segment towards ERP and BI software. The survey
responses are presented in the following categories:
• Operational and strategic planning:
• BI technology awareness
• BI use
• ERP use
• Company details and respondent general characteristics
- 71 -
Where applicable, results are presented using graphs. Additional commentary
is included by way of reflection on the results. The main findings follow:
4.2 Operational and Strategic Planning
Does the company have a mission Does the company have a documented
statement or similar guiding principle?
business plan encompassing the goals
of the organization?
22%
No
Yes 28%
No Yes
No
78%
Yes
72%
Figure 9. Survey response to O&S planning Q1 Figure 10. Survey response to O&S planning Q2
Do KPIs in use link to specific business goals? Is there a master document listing all KPIs used
Don't know
within the company?
7%
None Do
0% Don't Know
Yes
Some Do Most Do 11%
28%
27% Some Do Yes
None Do No
Most Do Don't know Don't Know
66%
No
61%
Which of the following are used when describing It is easy to extract financial data fromcurrent
KPIs? Information Systems
Strongly Agree
0% 20% 40% 60% 80% 100%
6% 0% 17%
Descriptive Title Agree
Purpose of the Measurement
Business Goal Link Agree with some exceptions
Functional Area
Target
Formula Yes 22% Disagree with some
Frequency No exceptions
Who/How Measured
Disagree
Data Sources 55%
Who Uses
Actions Performed as a result Strongly Disagree
Notes/Comments
- 72 -
It is easy to collect/extract data to measure Decision makers can easily retrieve the data they require from
the non-financial performance of the Information Systems without IT help
company
11% 0% 17% 11% 0% 6%
17%
38%
39%
33%
28%
Strongly Agree Agree

Agree with some exceptions Disagree with some exceptions
Agree w ith some exceptions Disagree w ith some exceptions
Disagree Strongly Disagree
Decision makers rely on IT to extract data
17%
11% 17%
6%
22%
27%

Agree with some exceptions Disagree with some exceptions
Figure 17. Survey response to O&S planning Q9
Analysis and Comment:
The results in Figure 9 and Figure 10 indicate that not all companies use mission
statements and documented goal driven strategies to drive their business forward,
however most companies questioned do. In general the smallest companies with
fewer employees tended to be the ones with no goal driven business plan. There was
variation on the level of documentation maintained on KPIs. Jointly 93% of
respondents indicated that KPIs in use were linked to business goals (see Figure 11),
indicating either most do or some do. There would appear to be KPIs in use which
- 73 -
respondents do not see as directly linked to business goals. There is insufficient detail
in the survey to ascertain the reason for this. Some possible reasons may be:
1. Respondent’s lack of knowledge on all KPIs in use
2. A failure to see how low level metrics perhaps link to broader goals
3. Inappropriate or unnecessary metrics or KPIs being used
4. Imposed KPIs required by legislation, external organisations or group
companies which are not seen as directly relating to local goals.
Only 28% of respondents claimed to have a KPI master document (see Figure 12).
One company indicated this was a useful question since although companies use KPIs
a complete picture of all KPIs is not readily available. Without this it is difficult to see
how such KPIs relate to each other and link to business goals, or indeed if all KPIs
used are necessary or whether gaps exist in monitoring. The most commonly
documented KPI attributes as indicated in Figure 13 are:
Target (72%)
Descriptive title (61%)
Purpose of Measurement (50%)
Link to business Goal (44%)
Formula to calculate (39%)
It was surprising that there was not a higher percentage in relation to
documenting the formula used to calculate. One can only assume those responsible
for measuring are aware of the formula and method, but there is no general
availability of calculation method. An additional comment made by one company was
that they recorded the interdependencies between KPIs. This is important from a
business process perspective in terms of documenting the triggers and events initiated
as a result of a particular outcome or input. Other attributes stored in relation to KPIs
- 74 -
may be seen in Figure 13. At the other extreme no companies indicated they currently
recorded actions to be performed based on KPI result as part of the documentation
associated with a KPI (see Figure 13). The responses to the survey would appear to
suggest a lack of documentation detail associated with the KPIs used in SME’s.
Business Process Monitoring will be discussed in Chapter 5 with a view to helping
SMEs obtain greater visibility and understanding of the relationship between business
processes, KPIs and business goals.
There was a very positive response when questioned on ease of extraction of
financial data from current information systems with a combined total of
approximately 95% of respondents feeling it was easy to extract financial information
(albeit the majority (55%) indicated they agreed with the statement with some
exceptions) (see Figure 14). There was not such consensus in relation to non-financial
data with approximately half of respondents indicating they did not agree that non-
financial data was easy to extract without IT assistance (see Figure 14). This may
indicate the reporting functionality is stronger on financial reporting in the majority of
systems and less strong on non-financial reporting. It may also be as a result of the
non-existence of this information in business systems. The case study Company A
(see Chapter 7) for example did not implement a number of manufacturing modules in
the ERP system (MRP and capacity planning) which meant this information was
outside the system.
There was no clear consensus on the reliance of decision makers on IT
resources to extract data on their behalf (see Figure 16 and Figure 17). It varied
between companies; even those using the same systems with similar IT resource
levels, however, other questions posed on this topic in the BI section of the
questionnaire would suggest such reliance exists (see Figure 27).
- 75 -
4.3 BI Technology Awareness
Are you familiar with the following BI concepts? Which BI tools are in use?
Spreadsheets Spreadsheets
Point Solutions designed for a specific Point Solutions for specific business
Business Intelligence Packaged Solutions Business Intelligence Packaged Solutions
Real Time alerting to embedded devices Real Time alerting to embedded devices Yes
Ad-Hoc Query Tools Ad-Hoc Query Tools
Business Process Modeling Yes Business Process Modeling No
Alert based KPIs Alert based KPIs
Extract, Transform, Load (ETL) tools No Extract, Transform, Load (ETL) tools
Data Warehouse Data Warehouse
Scorecards Scorecards
Predictive Analytics Predictive Analytics
Dashboards Dashboards
Business Activity Monitoring Business Activity Monitoring
0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%
Figure 18. Survey response to BI awareness Q10 Figure 19. Survey response to BI awareness Q11
Inhibitors to using BI Tools Primary driver for BI implementation
6% 6%
43% 11% Better Information for

28% Decision Makers
22%
Cost Saving
6% 11%
67% Satisify Customer
Requirement
Cost High Maintenance
No Barriers - In use Lack of In-House Expertise
Complexity No suitable solutions
Which BI delivery methods would you consider? How much would you expect to pay for a BI
solution?
Licensed - Outsourced
Licensed on company computers Cost is not a concern

€100K+
Professional Open Source
€80K - €100K
Open Source €60K - €80K Cost Expectations
Cloud Computing €40K - €60K

€20K - €40K
SaaS
Currently using Less than €20K
Would not consider 0% 20% 40% 60% 80% 100% 0% 10% 20% 30% 40%
Would consider
- 76 -
Databases in use by respondants
120%
100%
80%
60% Use
40%
20%
0%
Pr DB
Ex L
HS ix
L
l
es
L
Ac 0
G L
ss
s
ce
ss
Q
SQ
SQ
40
rm
DB res
Po t SQ
gr
re
yS
Ex
ce
AS
Q
fo
In
re
p
og
cle
In
of
2/
os
ra
st
L
O
icr
SQ
M
Database Applications
Figure 24. Survey response to BI awareness Q16
Not surprisingly all companies indicated they were both aware of and used
spreadsheets as an analysis tool. As may be seen in Figure 18 and Figure 19,
awareness was higher than use in all other categories of BI tools. Awareness was
highest in relation to Dashboards (83%), DW (78%) and Scorecards (72%) with
Business Process Modeling and Ad-hoc query tools both recording 67% awareness
among respondents. Awareness was lower in relation to ETL (22%), Predictive
Analytics (22%) and Business Activity Monitoring (BAM) (28%). Half of all
respondents indicated use of Dashboards, Scorecards and Ad-hoc query tools. As
anticipated in earlier hypotheses cost was recorded as the primary inhibitor to BI use
(43%) with lack of in-house expertise next with 28% (see Figure 20). Companies
cited better information for decision makers (see Figure 21) as the primary driver for
BI use (67%).
Licensed software on company hardware was the most popular business
software delivery method among respondents with 61% indicating use of this method.
The results in Figure 22 would suggest some reluctance to use open source and cloud
computing with circa 44% indicating they would not consider them. Professional open
source which guarantees support and SLAs, and SaaS would appear to be slightly
- 77 -
more acceptable with just under 39% indicating they would not consider them, a
slight improvement over general open source software. There was divergence on cost
expectations in relation to BI software. There was a definite trend among companies
using SAP to have a higher cost expectation with all SAP sites believing BI would be
in excess of €60K and 60% of SAP sites expecting to pay in excess of €100K.
Companies using other ERP systems in general expected costs to be no more than
€40K (Figure 23).
As indicated previously all companies declared the use of spreadsheets. The
database systems in use by respondents (Figure 24) were Microsoft SQL, Access,
Oracle, AS400/DB2 and MySQL in order of number of installations. It is not
surprising to see the better known vendor products in the list. A report by IDC
(Kanaracus, 2008) of DBMS sales put Oracle on top capturing 44.3% of the world
DBMS sales for 2007 with IBM at 21% and Microsoft at 18.5%.
4.4 Business Intelligence Use
Spreadsheets were used by all companies as an analysis tool. Other tools used
by the companies surveyed included SAP BI (BIW), MRC’s M-Power, Qlikview,
BPW (Lawson Movex Product), Global Software’s Spreadsheet Server (Excel add-in
which integrates with all major ERP systems) and Cognos.
Perception of BI Tools
Satisfaction with BI Tools Used
0%
0% 20% 30%
Not at all
40% IT Tool
Somewhat satisfied
End User Tool
Satisified
Both
Very Satisfied 70%
40% Exceeds expectations
Figure 25. Survey response to BI use Q22 Figure 26. Survey response to BI use Q23
- 78 -
Users can easily design ow n reports
10%
True
False
90%
Figure 27. Survey response to BI use Q24
The average number of BI users per site across all respondent companies was
53 with a minimum of 15 users and a maximum of 100 users. 60 % of companies
who use BI products indicated they had dedicated onsite BI support personnel ranging
from 1 on some sites to 4 on larger sites with an average of 2.5 support personnel.
Overall satisfaction with BI tools in use was high with 80% of respondents claiming
to be either satisfied or very satisfied (see Figure 25). As shown in Figure 26
companies using BI products predominantly viewed them as both an IT and end user
tool, with 30% indicating they viewed the BI products in use as an end user tool only.
No respondent viewed BI tools as an IT only tool. The responses in Figure 27 on end
user ability to design and extract information from the BI application are surprising.
Earlier responses in relation to ease of extraction of information from current
information systems suggested 95% of the respondents felt it was easy (with some
exceptions) to extract financial information and 50 % believed it was easy to extract
non-financial information. However when asked specifically to state their views in
relation to the statement “End users and power users can easily design their own
reports and extracts from the BI Application,” a mere 10% believed this to be the
case. This would suggest that although information is readily and easily extracted via
- 79 -
the BI tools, there is the expectation and reliance on IT resources to perform such
design and extracts for end user use. This would suggest that in relation to the fifth
hypothesis stated earlier that some IT resources are required in general to design,
configure and build the initial BI architecture for end users of such systems.
4.5 ERP Use
Does the company use an ERP Howlong has the current ERP system
system? been in use?
Less than 2 years

22% 14% 21%
2 to 5 Years
Yes
7% 5 to 8 years
No
37% 8 to 11 years
78% 21%
More than 11 years
Figure 28. Survey response to ERP use Q25 Figure 29. Survey response to ERP use Q28
Drivers for implementing ERP Current ERP implementation status

21% 7% 7%
Customer requirements 14%
E-Commerce
Y2K Enforced
51%
Manage Grow th Drivers
Business Process Improvement Currently implementing
Some implemented - More to do
Cost Reduction
All required implemented - no projects planned
Improve Planning
All required implemented - improvements in progress
0.00% 10.00% 20.00% 30.00% All required implemented - improvements planned
- 80 -
ERPPricingStructure ERP users per company

Customisedsolution
Other
Licensed- outsourced 01-25
Licensed- oncompanycomputers 21% 21%
OpenSourcenocustomisation 26-50
OpenSourcewithcustomisation 7% 51-75
CloudComputing
SaaS 76-100
30%
21% 100+
0% 10% 20% 30% 40% 50% 60% 70% 80%
%of Implementations
Figure 32. Survey response to ERP use Q31 Figure 33. Survey responses to ERP use Q32
Who supports ERP system? Approximate Implementation Time

for active ERP functionality
Local Power Users
Implementing
Third Party 24-36 months
Method % 18-24 months
ERP Vendor 12-18 months
06-12 months
Company IT Dept. Less than 06 months
0% 20% 40% 60% 80% 0% 10% 20% 30%
% of Implementations
What % of total ERP functionality ERP Implementation approach

available is implemented?
adopted
Nothing yet
Implemented %
Functionality
100%
80% - 95%
60% - 80% Big Bang
40% - 60% 43%
20% - 40%
Less than 20% 57% Phased
Modular
0% 20% 40% 60%
% of respondants
- 81 -
Pre Implementation Analysis Methods Does ERP meet company

requirements?
Vendor reference models
0% 21%
Goal based metrics mapping 29%
Business Process Modeling (e.g. BPEL)
Text based business process analysis
Business process re-engineering 50%

Not at all Somewhat satisfied
0% 20% 40% 60%
Satisfied Very satisfied
Pre Implementation Analysis Methods Exceeds expectations
Does ERP Vendor supply BI Why do you not use ERP?

Solution?
25%
21%
Yes Too complex
7% No Do not require
Don't Know 75%
72%
Among the systems in use by the 78% of respondents who use ERP were SAP,
Movex M3, Navision, Infor, QAD MFG/PRO and IFS (see Figure 28). A significant
number (approximately 50% of respondents) have been using their existing ERP
system for more than 8 years (see Figure 29). This is worth noting to those thinking of
embarking on an ERP project. Although the costs up front can be prohibitive, such
systems do generally stand the test of time yielding a good return on investment over
the life of the system. The survey results would indicate a more mature
implementation base in the majority of those who responded.
- 82 -
A significant finding from the survey particularly in relation to this study was
that the top reasons for implementing ERP (see Figure 30) were business process
improvement which equalled cost reduction in popularity and secondly to improve
operational and strategic planning. Few companies (14% of respondents) felt their
ERP implementations were complete in all respects with most indicating required
functionality was in place but improvements projects were either planned or ongoing
(Figure 31). Traditional licensed pricing structures were predominant among
respondents with approximately 70% using licensed products on company hardware,
20% outsourcing licensed products and 10% using customised solutions (see Figure
32). There was no company using SaaS, Cloud or Open Source ERP products form
the respondent population. This may indicate a reluctance to use the non-proprietary
methods for business critical systems like ERP but there is more willingness to try
them for other software in use. These software delivery concepts are still relatively
new and somewhat feared. The number of employees per company using ERP varied
with as few as 01-25 in some companies to over 100 in others (see Figure 33). In
general companies used a combination of support methods with most using local IT
and ERP vendor (see Figure 34). ERP installations were supported by company IT
resource(s) in 80% of respondents with circa 65% using the ERP software vendor and
30% using third parties and or power users. Time taken to implement varied between
companies (see Figure 35). The shortest was less than 6 months and the longest was
24-36 months. The majority of companies took between 06-18 months. What is
interesting is the percentage of available functionality implemented (see Figure 36).
No company claim 100% or even anything greater than 80% of available functionality
installed. Half of the respondents indicated between 60% and 80% and just over 40%
of respondents indicated between 40% and 60% of available functionality is installed.
- 83 -
Since most of the companies indicated that required functionality is installed and
improvement projects are either planned or in progress the general assumption being
made is that shipped systems contain unnecessary functionality. Perhaps a move to
SOA modular architectures could attain some savings for companies in the SME
category. The traditional offerings sold the black box ERP system which was often
functionally rich, a lot of which was surplus to requirements. There is definitely a
case to look at business processes in advance of any ERP or BI project and try to fit
the system to the requirements using modular SOA architectures.
More companies preferred to perform a modular installation (57%) over the
big bang approach (43%) (see Figure 37) . As indicated in Figure 38 text based
business process analysis was the primary pre-implementation analysis method used
(50%) by respondents in advance of an ERP implementation followed by business
process re-engineering (43%). Few companies (15%) used formal business process
modeling such as BPEL or Vendor Reference Models (7%). The later may be due to
the unavailability or tools when projects were being initiated in the respondent group
since as indicated earlier 50% of respondents implementations where over 8 years
ago. 80% of respondents are satisfied (or very satisfied) that the ERP system in use
meets company requirements (see Figure 39).
Most of the respondents using ERP (72%) believed their current ERP vendor
supplied either optional or integrated BI solutions (see Figure 40). This is something
SMEs should explore as integration may be easier with ERP vendor supplied or
promoted BI tools, than off the shelf or third party BI tools, but this would need to be
assessed on a case by case basis. Respondents listed Cognos, Qlikview, Corvu,
MRC’s M-Power, Picks Console, SAP BIW, Microsoft Analysis Services and
Pentaho as tools they were aware integrated with existing ERP systems. The tools
- 84 -
listed were primarily those used by respondent companies. There were few additional
BI tools mentioned suggesting knowledge outside of active products was low.
Finally Of the companies not using ERP (22% of respondents – 4 companies),
the primary reason was ERP systems were too complex for the business (75%) or
ERP was not required to run the business (25%), (see Figure 41).
All companies currently using ERP listed their ERP system as their primary
financial and production planning systems. Those not using ERP did not disclose their
primary financial and production systems. Some just indicated manual suggesting
spreadsheets or similar are in use.
4.6 Company Details and Respondent General Characteristics
Total employees in company
350+
250-350 % of Respondents
Less than 250
0% 20% 40% 60% 80%
Figure 42. Survey response to company details Q44
When averaged over the entire sample, the average IT support personnel per
employee ratio was approximately 1 per 90 employees (see Figure 41). Some of the
smaller companies with less than 100 employees had no dedicated IT personnel
relying on third party support, whilst most in the median employee numbers range had
2 or 3 dedicated IT staff supporting systems. The surveys were completed by
individuals with the following titles:
- 85 -
• Managing Director / General Manager
• CIO
• Financial Controller
• Head of IT
• IT Manager
• CEO
• Accountant
4.7 Conclusion
In general financial information appears to be more readily available than non-
financial information. This may reflect the availability of more functionality in the
ERP and other business systems to facilitate more common standardised financial
reporting but a lack of common standards in non-financial information leads to
disparate systems and methods of deducing such information. This was found to be
the situation in the case study company (Company A) as may be seen in Chapter 7.
There appears to be reliance on IT to extract information for decision makers. Most
sites using BI had dedicated IT resources or third party support contracts. The amount
of detail maintained on KPIs is basic. As projected in the initial hypotheses, cost and
lack of resources are among the greatest inhibitors to SMEs instigating a BI project.
There is still reluctance to move away from traditional software delivery methods for
business critical systems so work will be required by vendors of SaaS and cloud
products particularly, to convince SMEs of their suitability going forward. This is
reflected in earlier literature research also which indicated fears about security, data
integrity, responsibility, availability and ownership of data.
- 86 -
4.8 Lessons Learned
The survey contained a total of 53 questions. Considering the audience which
consisted primarily of executives the time taken to complete may have been too time
consuming for some. This is also reflected by the fact that 6 surveys were discarded
due to incomplete answers were the respondents saved partially complete entries but
did not return to complete them before the survey deadline of 31st July 2009. A
number of companies expressed concern about disclosing details of the systems in use
and sought further verification of my credentials to ensure I was genuine in the
request. It would have been better to use perhaps college letterhead and logos with a
link to an NUI Galway email account as opposed to a generic googlemail account
when sending invitations. Personal telephone contact was required in some instances
to improve response rates.
- 87 -
Chapter 5 - Performance Management and Measurement
5.1 Introduction
This chapter seeks to introduce an understanding of the context in which BI
provides a mechanism to help organizations improve operational and strategic
planning. The concept of strategy process in manufacturing SMEs is covered. This
section highlights the context, constraints and factors influencing an SME
organization’s ability to define and implement strategy. Strategy implementation
needs to be viewed not only from the perspective of the ability to define strategy but
also from the perspective of how that strategy will be implemented. In this chapter
strategy process is discussed as a means to define strategy and business process
management as a means to implement it complimented by BI tools.
5.2 Strategy Processes in SMEs
In order to define how BI can be implemented to provide better operational
and strategic planning it is necessary to evaluate the role of strategic and operational
planning and the way in which IT infrastructure can support this. Performance
measurement is defined by Neely et al. (1995) in Marković (2007) as the process of
quantifying the efficiency and effectiveness of an action. A performance measure is
defined as a metric used to quantify the efficiency and/or effectiveness of an action.
Ates et al. (2007) sought to improve understanding of business level strategy
process and content in SMEs posing the following research questions:
• To what extent generic strategy processes take place in production SMEs?
• What are the key contextual factors influencing strategy processes in
production SMEs?
- 88 -
• What are the key barriers and constraints to adopting business strategy
processes in production SMEs?
They found that the manufacturing SMEs studied demonstrated to some extent
strategic planning capabilities however they were lacking strategy implementation
capabilities. Figure 43 presents a context in which to evaluate the organization’s
ability to implement strategy process. It identifies both internal and external
influences on the organizations which determine capability to implement end to end
business processes serving a corporate strategy.
Figure 43. The key determinants of strategic context

______________________________________________________________
Source: Ates et al. (2007)
- 89 -
Figure 44. The key constraints to strategy process in SMEs
___________________________________________________________________
Source: Ates et al. (2007).
Figure 44 identifies the key constraints faced by the manufacturing SMEs
studied by Ates et al. (2007). As expected limited resources, skills shortages and size
constraints are listed among the constraints for SMEs. These factors effect all aspects
of the business equally including strategy formulation ability and IT capability.
The Strategy Process Wheel Framework in Figure 45 (Ates et al., 2007)
provides a guide to strategy implementation. Organizations should be knowledgeable
on what influences success in achieving corporate goals. The strategy process
Formulate segment of the wheel is similar to S.W.O.T analysis (Identify Strengths,
Weaknesses, Opportunities and Threats). The role of BI is to facilitate the attainment
of corporate strategy.
- 90 -
Figure 45. Strategy process wheel framework
_____________________________________________________________________
Source: Ates et al. (2007)
The Strategy Process Wheel presents a framework around which to focus
operational and strategic process improvement. SMEs have strategy planning
capability, but they are lacking in strategy implementation capability. One question
this paper seeks to answer is – How can MIS facilitate strategy process
implementation in SMEs? Business Process Management (BPM) may provide the
answers. Using BPM an organization can facilitate the execution of strategy by
incorporating business goals into operational processes end to end. BI can play a part
in analysis and presentation of valuable feedback from operational metrics enabling
strategy monitoring and revision. Reporting on a study of SMEs, Garengo et al.
(2007) made two noteworthy proposals:
“Performance Measurement System (PMS) implementation and use promote
improvement of organizational capability. The development of organizational
capability favors an effective use and growth of PMS. Moreover, the mutual
- 91 -
relationships between PMS and organizational capability start up a dyadic relationship
between PMS and MIS. Advanced MIS is essential to create a favorable context for
implementing and using PMS; the benefit highlighted by PMS implementation and
use promotes further investment in MIS.”
Secondly, “ Mature organizations are able to recognize their organizational
needs and design effective MIS responding to PMS requirements by themselves; in
less mature organizations, an external stimulus is essential for supporting MIS
investment and PMS implementation (or improvement) to get over organizational
crisis. ” It is therefore important to consider the maturity level of the organization and
their readiness to implement performance management.
Bourne et al. (2003) quote The Business Intelligence Report (1997), a study
of latest practice in organizations which argued that those companies: “.... which
already have a sophisticated IT infrastructure and a well developed corporate
information architecture are likely to find their ability to develop and support PMSs is
greatly enhanced.” Aberdeen Group (Lock, 2009) concur with these findings
indicating best in class SMEs invest in technology solutions to automate BI processes
(see Figure 46).
Figure 46. Top strategic actions for best in class SMEs
_____________________________________________________________________
Source: Lock (2009)
- 92 -
On this basis a BI implementation should consider MIS capability and
organization maturity.
5.3 Business Process Management
Business Process Management (BPM) and goal oriented BPM in particular
provide a means to monitor performance. Business process management (BPM), both
the management practice and the software tools that facilitate it (such as business
process modeling), evolved to help organizations address constantly changing
environments. By organizing processes around goals, that is “what is to be achieved”
rather than “what is to be done,” goal-oriented BPM helps organizations achieve
needed flexibility (Tibco, 2006). Breaking down business processes into sub-goals is
critical to this flexibility. The collection of discrete sub-goals makes up the building
blocks available to a process designer. Sub-goals represent the management of the
items of interest to the business. Once identified, each of these “items of interest,” or
sub-goals, can be managed as a service, a discreet entity without dependencies, able to
be reused as required by any part of the business (Tibco, 2006). Each goal or sub-goal
then manages a single item or a set of highly cohesive related items. This results in
discrete processes that are cleaner and more likely to be reusable. Because of the
discrete nature of these “process components,” it is also possible to expose them as
“services,” with simple, clean interfaces in a Service Oriented Architecture (SOA)
environment. Neeley (1996) suggests the following when selecting metrics:
• Measures should be clearly defined, with an explicit purpose
• Measures should be relevant and easy to maintain
• Measures should be simple to understand and use
• Measures should provide fast and accurate feedback
• Measures should link operations to strategic goals
- 93 -
• Measures should stimulate continuous improvement
According to Tibco (2006) for software to effectively facilitate goal-oriented
BPM, it must provide support for the following activities.
• Organize business processes around goals to be achieved by the business:
• Determine sub-goals required to achieve the desired end goal: Identify the
required sub-goals by working back from the end goal one step at a time to the
starting point or current position.
• Allow the end goal to change part way through its fulfilment:
Goal-oriented BPM software should be time aware. This time awareness
enables it to monitor service level agreements (SLAs) associated with overall goal
achievement (end-to-end business processes) and KPIs. It is the role of BI to report on
these KPIs and provide the information necessary for decision making. They key
concept is to integrate business objectives end to end ensuring business process are
built around achieving them and using the necessary IT infrastructure to report and
monitor progress. It is within the context of goal oriented performance management
utilising business process management that BI applications should be introduced to
the organisation.
5.4 Conclusion
The survey conducted as part of this research indicated that business process
improvement was the primary reason for implementing ERP systems. BPM modeling
tools facilitate the mapping of business processes with a view to providing visibility
via monitoring and feedback thus providing organizations with opportunities to
implement improvements. The survey results also indicated that most companies only
use between 40% and 80% of available functionality in their ERP systems. This begs
the question on how well the chosen solution meets the needs of the company.
- 94 -
Companies appear to be paying for functionality they do not require. Business Process
modeling and analysis presents the opportunity to focus on the real needs of the
business and create architecture around the key business drivers. The survey results in
relation to the percentage of current ERP functionality used also suggests companies
use disparate systems to run the business. Successful data integration is important to
the success of a BI project. The Aberdeen Group (Hatch, 2009) indicates that best in
class companies are 62% more likely to use data modeling tools as when data is
integrated from multiple sources the ability to model data dimensions, relationships,
indexing and field names becomes extremely complex. They suggest data modeling
tools can help by ensuring one repeatable model is used to construct the data
structures necessary to deliver information to multiple interfaces (dashboards, reports,
embedded devices and analytic applications). BPM modeling tools can be used to
present a view of the business legible by all stakeholders without delving into the
underlying technological details. Diagrams are easily understood by non-technical
team members and IT professionals alike. These reasons coupled with the opportunity
to implement clean, autonomous services in a SOA style architecture lend weight to
the argument to consider business process management tools as part of a BI
implementation. The challenge for SMEs is resources and knowledge. The key is to
focus on key processes where most benefit can be attained and proceed when the
organisation is ready and not before. Chapter 6 focuses on the readiness of an
organisation by presenting a number of BI maturity models which provide insight to
help gauge the readiness of the organisation for BI and BPM.
- 95 -
Chapter 6 - BI Maturity Models
6.1 Introduction
This section presents a number of BI maturity models to illustrate the lifecycle
of a BI implementation. Not surprisingly the models align quite well as you move
through the stages or levels associated with each. There is a lot of commonality which
would suggest general consensus on BI Lifecycles as an organization increases in BI
maturity. By understanding the lifecycle of a BI project, organizations will be better
positioned to understand their readiness to proceed. Such models also provide a bench
mark upon which to gage the status of an active BI project. Four BI maturity models
are outlined.
6.2 BI Maturity Model Illustrations
6.2.1 BI Maturity Model 1: Deng’s BI Maturity Hierarchy
Figure 47. Deng's BI maturity hierarchy
______________________________________________________________________________
Source: Deng (2007)
- 96 -
Deng (2007) summarises the concepts of the BI Maturity Hierarchy levels in
Figure 47 by indicating data leads to information, information leads to knowledge and
knowledge leads to wisdom. A more precise definition of each level is offered by
Deng (2007) as follows:
Data Level: At this stage, the business is just collecting raw business data,
cleansing it, standardizing it, integrating it among different source systems and storing
it in a searchable format. This is the starting point of the DW and BI. If you stay at
this level, your ROI will be almost zero but it is necessary to move to the next level.
Information Level: At this level, BI is starting to leverage the integrated,
good quality data and put it in the right context, such as creating business reports and
slicing and dicing the data to show different views of data. As businesses move to the
advanced stage of this level, they could be creating business KPIs and showing them
in dashboards through the Web so that the information about business performance
and activities is clear and easy to read and understand.
Knowledge Level: At this stage, BI will work on patterns and perform
cause analysis to help businesses find root causes for some trends so that the
knowledge can be applied to business processes. The advanced level of this stage is
building an expert system to integrate all discrete knowledge together and deduct new
knowledge based on past collected knowledge.
Wisdom Level: This stage is marked by changing business processes to attain
productivity improvements. Decisions should be sound, timely and effective to
maximise competitive advantages over their competitors regarding time to deliver,
meeting product targets and services quality.
Although BI maturity models provide a guide to achieving success in BI
implementation, reaching the end state of the maturity model does not mark
- 97 -
completion. Business operates in a constantly changing environment and BI maturity
assessment needs to be constantly reappraised to ensure the company is getting the
best from their implementation. It is indeed feasible that a company may be in
different stages of maturity with various business processes as the company adopts
change and moves along the roadmap. A company may have attained Deng’s Wisdom
level on financial analysis and be at the data or information stage in relation to
production processes.
6.2.2 BI Maturity Model 2: TDWI’s Business Intelligence Maturity Model
The Data Warehousing Institute’s (TDWI’s) Business Intelligence Maturity
Model is a well recognized and used BI maturity indicator (see Figure 49). The
TDWI’s BI Maturity Model is a top down, vision oriented model which organizations
can use to develop a road map (Eckerson [1], 2007). The model comprises five graphs
representing:
• BI adoption
• Local Control versus Enterprise Standards
• BI usage
• BI insight
• Business value and ROI
Within each graph the model depicts a maturity indicator which rates BI
implementations on the following scale:
• Pre-natal
• Infant
• Child
• Teenager
• Adult
- 98 -
• Sage
The first of the graphs the BI adoption curve is shown in Figure 48. The complete
model may be seen in Figure 49.
Figure 48. TDWI's BI adoption curve
__________________________________________________________________________________
The TDWI Maturity Model depicts how organizations evolve their BI
deployments. Eckerson [1] (2007) describes the BI adoption curve in Figure 48 as
follows “The Gulf and Chasm represent major sets of challenges that afflict BI
projects and cause them to flounder; the bell-shaped curve represents the number of
enterprises in each stage; the labels above the bell curve represent the types of data
structures commonly found in each stage.”
The graphs presented in the model each appeal to different stakeholders within
the organization. While the focus of early-stage BI is on reports and analysis of
historical trends, the focus of mature BI implementations is on metrics and
performance (Eckerson [1], 2007). The early stages of BI involve readying the data
infrastructure and project and development methodologies for full exploitation by the
business. Eckerson [1] (2007) suggests as companies move through the Infant, Child,
- 99 -
and Teenager stages they increasingly consolidate analytical stores and standardize
terms and rules for defining key dimensions, facts, and metrics. The Adult and Sage
stages are marked by a rapid increase in use of the BI solution by end users, including
customers and suppliers in highly mature implementations, largely because BI
mutates from an insight delivery system to a business monitoring system to an
automated decision-making system (Eckerson [1], 2007). The model as indicated
provides a roadmap to help organizations benchmark their BI implementations and
can be used as a planning tool to progress the implementations whilst helping to
understand the pitfalls which inhibit such progression. Figure 49 presents the model.
- 100 -
Figure 49. TDWI's business intelligence maturity model
_____________________________________________________________________
Source: TDWI (n.d.). Reproduced by kind permission of the TDWI (See Appendix G for grant of
permission)
- 101 -
6.2.3 BI Maturity Model 3: Business Intelligence Maturity Model (BIMM)
Figure 50. Business Intelligence Maturity Model (BIMM)
________________________________________________________________________________
Source: Business Driven Data (n.d.)
Once again the model in Figure 50 demonstrates a progression from
paper/electronic based reporting through to analysis using slice and dice and perhaps
dashboards/scorecards through to predictive analytics and eventually business process
definition using real time embedded activity monitoring.
6.2.4 BI Maturity Model 4: IBM’s Information Lifecycle
IBM’s information lifecycle model in Figure 51 displays the transition from
data to information for competitive advantage indicating as the others do increasing
maturity and business value with progression through the lifecycle stages.
- 102 -
Figure 51. IBM's information lifecycle model
___________________________________________________________________________________
Source: IBM Corporation (2006)
6.3 Conclusion
Based on the maturity models indicated you can begin to formulate a strategy
for BI implementation by defining what the requirements are for each stage of the
model. For SME’s the projects may be heavily constrained in terms of budget and
resources so the key will be to prioritise and decide how far you want to take it by
analysing the cost benefit associated with each step. Prioritise what processes should
be included based on greatest benefit in enhancing the organizational goals. Use the
models as a benchmark to guide progress and plan next steps.
- 103 -
Chapter 7 - Case Study: Integrating BI with ERP in Company A
7.1 Introduction
This chapter documents the work undertaken in an SME to implement a trial
BI solution. The purpose of the work undertaken was to determine the best way of
integrating a BI application with an existing or proposed ERP system given the level
of skills and resource constraints inherent in SMEs. The work sought to facilitate
understanding in three areas:
• Translating corporate strategy into business metrics/KPIs to be monitored
• Aligning the project against a BI Maturity Model to help organizations
understand their BI status as a benchmark against a roadmap to BI success
• Determining the best integration strategy in terms of physically interfacing the
BI application with the ERP database for best performance and ease of use.
To attain an understanding of these areas the case study presents a business
process review of sales reporting in the case study company. The business process
review looks at the current process flows, the organization’s MIS capability, current
reports and analysis and existing corporate goals and KPIs as a means to determine
what should be measured. The TDWI’s BI maturity model (Figure 49, Chapter 6) is
used to help align the organization against a BI maturity framework to guide the
efforts of the organization in a BI project, and a comparison of integration methods is
used to suggest the best way to integrate the BI application with the ERP system. The
comparison looks at implementing a data mart versus querying the ERP files directly
and suggests the best approach based on the results obtained. The work presented
provides answers to many of the sub-problems posed in Chapter 1 and the thesis
problem statement itself.
- 104 -
7.2 Background to the Project
Company A is a process manufacturing company based in the Republic of
Ireland employing 220 staff. The case study will present the tasks involved in
implementing a trial BI solution focusing on sales related information and metrics, to
transform the data embedded in the ERP system to information providing visibility
and metrics to stakeholders with the objective of moving Company A along the BI
maturity continuum as outlined in Chapter 6 Figure 48. Previous attempts to empower
users in Company A were unsuccessful. Prior to the purchase of the BI application a
select group of power users were trained in IBM’s AS400 Query reporting tool with a
view to giving the users access to the ERP data library to create ad-hoc reports and
file extracts in the same way the IT department did. This approach failed miserably,
since although the tool itself was user friendly, the ERP file system was not. There are
currently almost 10,000 files in the main transactional library. Presenting the user
with a short list of the main files used for sales reporting was not sufficient since they
had no concept of physical files requiring joins to other files or logical views to
retrieve dimensional data descriptions. There were also performance issues with long
running queries and little or no control over storage for data extracts. There was no re-
use of previously generated data among users and file naming conventions were a free
for all. Users retreated to the familiar territory of IT support.
7.3 Project Scope
Sales data was chosen as the area for the BI trial based on an analysis of the
processes, KPIs, reports and spreadsheets in use. Based on interviews with key staff,
this is the area which was found to contain most duplication of effort in re-keying data
- 105 -
already in the ERP system and that which was used in more analytical spreadsheets
than any other. The proposal was as follows:
1. Identify the user group for the trial.
2. Work with the user group to identify a sample of sales related KPIs used in
operational and strategic planning in Company A.
3. Identify reporting dimensions / hierarchies relevant to sales related KPI
monitoring.
4. Produce summary sales information to support operational and strategic
planning.
5. Provide drill down back to lowest level of detail based on an identified
dimensional hierarchy
6. Sales reporting dimensions should have a time based variant to allow
comparisons.
7. Monitor sales related KPIs using new BI application
7.4 Business Process Review
A review of the processes involved in generating current sales data was
undertaken. This helped to establish a number factors including:
1. Information producers and consumers
2. Current process flows
3. Reports in use
4. MIS capability
5. ERP implementation type and data characteristics
6. Data sources (other than ERP)
7. Sales related KPIs
8. Dimensions and metrics for use in a data mart
- 106 -
7.4.1 Information Consumers and Producers
As indicated in the literature review in Chapter 2, Eckerson [2] (2007)
suggested the importance of mapping users to tools when implementing BI as a means
of moving towards BI self service. Figure 52 reproduces Eckerson’s model here for
convenience.
Figure 52. Mapping users to BI tools
_________________________________________________________________
Appendix H contains the user roles assigned to the information consumers and
producers grouping in Company A for the sales related trial BI project. The roles were
determined through a review of the processes responsible for generating sales data
and the reports and spreadsheets being used. Appendix I highlights the BI users for
the trial in the context of the overall organization. In an SME multiple roles may be
played by the same individual as in the case of Company A. Where there are no IT or
Business Analyst functions employed (as may be the case in some SMEs), it is
advisable to ask the vendor to be part of the BI Implementation team to help establish
the initial OLAP structures and standard reports library based on requirements agreed
and defined by the BI implementation team. Local responsibility for controlling the
- 107 -
BI can then be given to the BI implementation team preferably headed by the chief
executive.
7.4.2 Current Process Flows
Data is made available for sales analysis and reporting post completion of the
daily invoice print run. In Company A, invoices are hard copy documents, printed and
posted to customers. The invoice generation program performs a number of tasks:
1. Updates the sales ledger
2. Updates the general ledger revenue accounts
3. Updates the ERP sales statistic module – a repository of customisable data sets
which can be used to generate hard copy reports by the dimensions configured
in the sales statistics module.
4. Updates other ERP database files within the Accounts Receivable (AR) and
Customer Order Processing (COP) system (e.g. changes order status to
invoiced)
Appendix J represents the current activities in relation to sales reporting in
Company A. The issues identified relate to the amount of hardcopy and ad-hoc files
being generated. Details from paper based reports are being re-keyed to spreadsheets
to produce current operational and strategic information in the form of reports and
graphs. Data from spreadsheets is also being re-keyed back into the ERP system (e.g.
budget information) and there is much duplication with many spreadsheets containing
the same or similar information.
7.4.3 Reports in Use
As part of the business process analysis, a review of reports in use was
performed. This produced some useful findings. The ad-hoc reporting tool used in
Company A is IBM’s AS400 Query, a licensed product on the AS400 iSeries 520 on
- 108 -
which the ERP system runs. An analysis of the libraries produced the results in Table
A.
Table A
Analysis of Ad-hoc Query Reports Stored by Company A

__________________________________________________________________
Measure and variable Quantity % of Total
Queries
_____________________________ ________ _________
Total ad-hoc query reports found 970 100%
Total ad-hoc query reports not run since
year indicated
Year 2005 504 52%
Year 2006 582 60%
Year 2007 654 67%
Year 2008 700 72%
Total queries with the word sale 57 6%

included in the query name or
the query descriptive text
________________________________________________________________
The Movex 11.4 ERP software contains a report writer for creating paper
based sales reports. The utility uses datasets which are updated during the customer
invoice print run. An additional 36 reports were found to exist in this module which is
specific to customer sales data. The data in Table A highlights the extent of ad-hoc
reporting. This creates many versions of the truth and reports are often used once and
take up storage not only for the definition but in some cases the output files created
also. There is also a housekeeping and maintenance overhead to having so many
reports. Although it is possible to tell when a query report was last used, there are no
statistics available on frequency of use. This would be a useful indicator. The present
- 109 -
author recommends this feature should be included by vendors in BI and general
reporting tools where it does not currently exist.
7.4.4 MIS Capability
An analysis of the current IT infrastructure was performed to ascertain the IT
capability of the organization. The infrastructure depicted in Appendix K is
representative of the primary IT hardware architecture in use. The software in use
pertaining to the BI implementation is depicted in Appendix L. It is important to
understand MIS capability as research indicates a greater return on investment from
BI in organizations with enhanced MIS capability. The ability to web-enable reporting
for example is determined by the infrastructure available and the skills of the BI
implementation team. MIS capability covers hardware, software, communications and
human skills elements. Company A is well positioned to progress BI maturity based
on the current infrastructure. It is not so highly developed as to reach Adult/Sage
levels in the TDWIs BI maturity model (Figure 49, Chapter 6). This requires the
ability to perform real time analytics in fully integrated end to end processes. It is
however well placed to move from Prenatal/Infant to Child/Teenager as depicted by
the use of data marts, building departmental repositories one subject at a time, moving
away from spread-marts and OLTP management reporting to OLAP tools providing
multi-dimensional views. Systems are web-enabled via the addition of the m-Power
software and the hardware platforms and communications are sufficiently developed
to permit information sharing and integration with the ERP system.
7.4.5 ERP Implementation Type and Data Characteristics
The ERP implementation in Company A could be described as a homogenous
single site legacy ERP implementation. The ERP system was installed in 1998. The
front end is a green-screen user interface presented using IBM’s Client Access for
- 110 -
iSeries software which provides 5250 emulation. As a transaction processing system it
continues to serve Company A well. The issues which exist are increasing demands
from customers and other external bodies such as revenue, auditors and suppliers to
interact using electronic methods and demands for more analysis of the data buried in
the system. This functionality is not present in the current installation. The choices
faced by Company A were:
• Replace the current ERP system (written in IBM’s RPG) through migration to
the most recent version of the vendor’s product (which has been rewritten in
Java) (Cost estimate €100k-€150k)1.
• Move to a new vendor ERP product (Cost estimate €80k-€100k)1.
• Remain as is and introduce third party tools which integrate with the present
ERP system to provide enhanced functionality (Cost estimate €30K-€40K)1.
Vendor support costs are increasing annually due to the age of the system and
an end of life date for support has been set by the vendor for January 2012. Company
A pursued the third approach indicated. The m-Power tool by MRC (see Appendix M)
was chosen to provide new web-based functionality and BI tools.
7.4.6 Data Sources (other than ERP)
The survey conducted as part of this research indicated that most organizations
believed 60%-80% of available ERP functionality was in use. Company A’s
installation would concur with these findings. This inevitably leads to disparate
systems being in use. The reasons vary but can be categorised primarily as:
1. Module is too complex for organization’s needs – high maintenance.
2. Best of breed application is being used with superior functionality to
generic ERP module.
3. Project lost momentum/resources and stagnated.
- 111 -
1 Cost estimates include licensing, consultancy, training and migration where applicable.
In relation to the present trial other data sources are primarily spreadsheets
containing sales budgets and forecast information. Budget data is prepared and
maintained on a spreadsheet but is loaded to the ERP system for reporting. Forecast
data is maintained on spreadsheets only.
7.4.6.1 Integration of other data sources
The means of loading spreadsheet data to the ERP systems vary. Sales budget
data was originally manually keyed post preparation in a spreadsheet (time
consuming). Current mechanisms include:
Method 1:
1. Tabulate data in spreadsheet in preparation for upload
2. Extract spreadsheet data to .csv files
3. Design physical data files on AS400 iSeries using Data Definition
Specifications to hold uploaded data.
4. Upload .csv file to iSeries using IBM’s Client Access “Transfer from PC”
utility
5. Convert PC file to AS400/DB2 format
6. Write an RPG program to read the newly created physical file and write
data to ERP budget file
Method 2:
Use IBM Operations Navigator to run SQL scripts to populate ERP data files
directly.
Method 3:
- 112 -
The m-Power BI application contains a utility to load spreadsheet data to
AS400 iSeries tables. It is a simple cut and paste utility with the facility to define
attribute type and length, and table name. The utility generates the scripts to create
tables based on the definitions specified. Figure 53 shows the utility being used to
create a Time Dimension table for a data mart as part of the current case study.
Figure 53. m-Power's “create a new table from spreadsheet data” utility screen-shot
__________________________________________________________________
Tools such as this are really useful for SME’s who may have to load data to
the BI application but who do not have dedicated MIS support staff. The data can be
organised in a spreadsheet and populated to the BI application using this utility. A
small amount of training would suffice for the team member holding the business
analyst role from the information producers group. It helps speed up ETL tasks for
files not exceeding Excel’s (or other spreadsheets) maximum number of row
limitations (currently 65,536 in Excel). Data can be appended to existing tables.

- 113 -
A test was performed to test loading 65,536 records to a new table on the
iSeries AS400 by populating an excel spreadsheet with the maximum rows. Figure54
shows the result which took less than 1 minute.
Figure 54. Result of new table creation from a spreadsheet with 65,536 rows
_________________________________________________________________
7.4.7 Sales Related KPIs
The following artefacts were gathered and analysed to determine KPIs
currently used for operational and strategic planning in Company A.
1. Company A’s mission statement
2. The 3 Year business plan
3. Existing KPI master document
4. Existing reports and extracts used to analyse sales related data including
5. Hardcopy reports from the ERP system
COP Module – Standard Customer Order Processing Reports
ARL Module – Standard Accounts Receivable Reports
SST Module – Sales Statistics Report Writer and Datasets (including
actual sales and budget sales datasets)
RGR Module – General Ledger Report writer
BUD Module – Budget Information General Ledger
6. Sales related excel spreadsheets
7. Ad-hoc queries. IBM AS400 Queries written for output to hardcopy and
extraction files.
- 114 -
8. Data extracts - imports of ERP system data pulled directly from iSeries
databases to Excel using IBM Client Access file transfer over ODBC
A selection of sales related KPIs were picked for the trial by the users. It is
outside the scope of the current trial to implement all identified KPIs. What is
important here is the process of determining the KPIs. The starting point is the
organization’s corporate goals. The requirement is to translate the corporate goals to a
hierarchical KPI structure so attainment of the corporate goals feeds down to the
lowest levels of the operation. Each level provides metrics to the level above to
monitor attainment of the KPI appropriate to the decision making at that level (see
Figure 55)
7.4.7.1 KPIs selected for trial
Strategic Level KPI: Sales Growth of 5% per annum
Tactical KPI: 1. Sales by value in each market sector in which the
company currently operates
The Top N Customer Analysis
Operational KPI Sales by Customer and Product Group
Strategic KPIs
Tactical KPIs
Operational KPIs
Figure 55. KPI hierarchy
_______________________________________________________________
- 115 -
KPIs should be documented at a sufficient level of detail to provide analysts
and designers with the information required to integrate them into business processes.
Figure 13 from Chapter 4 has been reproduced here for convenience. It shows
the responses indicated by organizations on the level of detail stored about KPIs. In
general insufficient information is documented for KPIs. This will need to be
addressed as part of a BI project.
Which of the following are used when describing

KPIs?
0% 20% 40% 60% 80% 100%

Descriptive Title
Purpose of the Measurement
Business Goal Link
Functional Area
Target
Formula Yes
Frequency No
Who/How Measured
Data Sources
Who Uses
Actions Performed as a result
Notes/Comments
Figure 13. Information stored about KPIs by survey respondents
________________________________________________________________
Earlier research work also indicated the importance of prioritising BI projects
based on those which will bring the most benefit quickly. In selecting KPIs for
monitoring evaluate the business benefit of doing so.
7.4.8 Defining the Dimensions and Facts for use in a Data Mart.
After KPIs have been selected, data aggregation levels must be determined to
ensure reporting takes place at the correct level to facilitate operational and strategic
planning. The information for this step will come from the business process analysis
- 116 -
undertaken. Looking at current processes and reports will help determine the
dimensions and datasets required. KPI definitions themselves should be sufficiently
detailed to provide information to this step. Map operational data from each source
into subject-oriented information in the data mart and determine the relationships
between those data. The dimensional hierarchies in Figures 56, 57 and 58 were
determined for Company A’s BI trial.
Customer Group(Market Segment)
Customer
Figure 56. Customer dimensional hierarchy
_________________________________________________________________
Item Group(Size Groups)
Product Group(Material Groups)
Item Number
Figure 57. Item dimensional hierarchy
_________________________________________________________________
Accounting Year
Accounting Month
Accounting Week
Figure 58. Time dimensional hierarchy
_________________________________________________________________
- 117 -
None of the reports reviewed had a daily granularity but provision has been
made for this in the time dimension table used.
7.4.9 Data sets in use
As part of the business process review determine the datasets in use. This will
help define the time dimensions required for comparison.
• Current year actual sales
• Current year budget sales
• Current year forecast
• Last year actual
• Last year budget
7.5 BI Maturity Level Assessment Pre-implementation
Based on the TDWI’s BI Maturity Model outlined in Chapter 6, Figure 49,
Company A could be determined as being in the Infant stage of the TDWI’s BI
adoption curve as shown in Figure 59.
Figure 59. TDWI BI adoption curve
__________________________________________________________________
Source: Eckerson [1], (2007)
- 118 -
This stage is typified by static reports and what Eckerson [1] (2007) describes
as spreadmarts. Company A have invested in a BI Solution but it had not been
implemented in advance of the case study. Characteristics of projects in the Infant
stage as defined by Eckerson [1] (2007) include:
• Readying the data infrastructure
• Defining project and development methodologies
• Commencement of consolidation of analytical stores
• Standardizing terms and rules for defining key dimensions, facts and metrics
(KPIs)
The adolescent level of maturity as depicted by the Child/Teenager stage to
which Company A aspires is typified by:
• Starting to obtain business value from the investment.
• Empowering power users to perform ad-hoc reporting
• Building “briefing books” for executives (Dashboards/Scorecards)
• Providing reports for casual end-users
• Departmental data marts exist
• Spreadmarts are in retreat in favour of self service ad-hoc reporting
DWs may be used depending on organization size and complexity. All
organisations will go through these stages but as indicated in Chapter 6, organizations
can have projects at different stages. The BI maturity indicator is not a measure of the
organization’s BI maturity. It is a measure of the specific BI project’s maturity.
7.6 Integration of BI with ERP
Three scenarios were considered for integrating the BI application with the
present ERP system:
- 119 -
• Allow BI application to access the ERP database files directly.
• Build one or more data marts using a star schema (or snowflake).
• Use a combination of ERP direct access and data mart structures.
A trial was performed utilising methods one and two to decipher if one was more
beneficial over the other. The following sections detail the work performed and
decisions taken as a result.
7.6.1 Data mart design
Although data marts are not usually normalized structures Entity Relationship
(ER) modeling can still be useful in data mart design. Start by producing the
conceptual model detailing entities and their relationships. The logical model adds
attributes and key information and the physical model represents attribute
characteristics and physical naming.
• Conceptual Model
• Logical Model
• Physical Model
The semi-normalized combined conceptual and logical star schema ERD diagram
for the proposed test data mart is shown in Figure 60. The schema is simple. In reality
there should be more detail in the tables and more dimension tables. It serves only as
a test schema in the present research but simplicity is desirable.
- 120 -
Figure 60. Logical model for item sales data mart for company A
_________________________________________________________________
The star schema design in Figure 60 is basic. The fact table (FSALES) and the
item dimension table (DITEM) are almost fully normalized to Third Normal Form
(3NF) with the exception of the ItemDescription attribute which provides a
description for the ItemNumber attribute. De-normalizing is recommended to improve
performance in an OLAP schema as it limits joins by not having to retrieve
descriptive text and less joins means better performance. The trade off is disk space.
The physical model dimension and fact tables represented in Figure 61 were
created using the m-Power “create table from spreadsheet data” utility. A combination
of naming conventions has been adopted. Physical naming conventions depict the
current ERP conventions for the fact table (FSALES) and item dimension table
(DITMAS). The time dimension table (DTIME) uses more meaningful names. The
purpose of this mix of naming convention is to show physical names do not effect the
final presentation to the user as the metadata can be manipulated to present
- 121 -
meaningful names in the resultant BI reports. Date fields have been defined as
numeric for compatibility and comparison with the ERP date fields.
Figure 61. Physical implementation of the star schema for company A
____________________________________________________________________
The following scripts were run to build indexes over the physical tables
created on the AS400 iSeries database, as the m-Power utility used only creates the
physical table and populates it with data.
/* Primary Key on Time Dimension */
- 122 -
CREATE UNIQUE INDEX COMPANYA.PK_DSYCAL ON

COMPANYA.DSYCAL (TIMEID ASC );
/* Primary Key on Item Dimension */

CREATE UNIQUE INDEX COMPANYA.PK_DITMAS ON
COMPANYA.DITMAS (DIITNO ASC );
/* Primary Key on Fact Table */

CREATE UNIQUE INDEX COMPANYA.PK_FSALES ON COMPANYA.FSALES
(FTDATE ASC , FTITEM ASC );
7.6.2 Populating the data mart – ETL
The methods available to load the dimension and fact tables at Company A
include:
1. Use m-Power built in utility to load spreadsheet data
2. Write Program to load data from ERP system to newly defined tables
(ILE RPG and AS400 job scheduler)
3. Use SQL scripts
4. Extract data directly from ERP files using IBM Client Access Utility,
manipulate and load to m-Power using built in utility to load spreadsheet
data
For speed and ease options one, three and four were used for the trial. Option two
was deemed too slow. As indicated method four does not generate the indexes
documented in the logical schema model, but only creates the tables and populates
them, therefore, indexes were created separately.
The trial sought to measure performance differences between an OLTP direct
access approach and an OLAP approach. To integrate the present ERP system data
files with the m-Power application it was necessary to register the tables to the
metadata repository and define table links through the use of the synonym feature.
- 123 -
This is a simple task to perform but it requires knowledge of the OLTP/ERP file
system.
7.7 Query Testing: OLTP versus OLAP
The BI software in use for the trial is m-Power by MRC. A description of m-
Power’s architecture, platform and approximate costs are included in Appendix M.
The application is licensed on a platform basis. Company A purchased the license to
operate against the AS400 iSeries database which is used by the ERP system supplied
by Lawson, namely Movex V11.4 (RPG version). The application library resides on
the iSeries but the web applications generated reside on a Windows 2003 Server using
Apache Tomcat (version 5.0.57) as the web server. In order to protect the privacy of
Company A, data displayed will be obscured to prevent identification of products,
customers or company financial data. This may take the form of not displaying sales
item descriptions, customer names etc., so the data presented may look quite raw.
7.7.1 Test Data Specification
The following defines the data to be processed and presented.
Data Set: Current year sales
Period: 20081227-20090626 (Accounting Period Dates)
Half year results 2009.
Attributes: Sales Value in local currency (Sum)
Sales Qty in Units Sold (Sum)
Sales Tonnage (Qty sold x net weight) (Sum)
Granularity: Weekly Sales
Aggregation: Level 3: Total sales per week by Product Group
Level 2: Total sales per week by Item Group
Level 1: Total Sales per week
- 124 -
Level 0: Grand Total sales for date range entered –
no dimensional breakdown
7.7.2 Configuring the Test Environment and Report Design
In this section the work involved in preparing a test environment to compare
performance of OLTP direct access against OLAP structures is detailed.
7.7.2.1 Allow BI application to access the ERP OLTP files directly
This method involved registering the existing ERP files containing the
requested data to the m-Power metadata repository. Once the tables were registered it
was then necessary to link the files through the use of the synonyms feature present in
the m-Power software. This method has no pre-aggregation of the data so all totals
and subtotals will be calculated on the fly. The results are the best case scenario for
this method since in a live implementation there would be more tables and therefore
more joins. Descriptive fields for attributes are not used in the test. OLTP systems are
normalized and contain little redundancy. Figure 62 shows the tables which were
registered from the live Movex ERP database.
Figure 62. Movex ERP database tables registered to the data dictionary within m-Power
________________________________________________________________
1. OSBSTD: Sales statistics
2. MITMAS: Item Master
3. CSYCAL: System Calendar
- 125 -
Synonyms:
Link OSBSTD to MITMAS using Item Number
Link OSBSTD to CSYCAL using Invoice Date
Report Design was performed resulting in the selection screen in Figure 63.
Figure 63. Report selection screen for OLTP vs OLAP Test: OLTP direct test
_________________________________________________________________
The report was submitted to run with parameters specified in Figure 63. The
generated SQL for the selection is shown in Figure 64. The default number of records
for a web report is set to 10000 in m-Power. The number of records meeting the
criteria was 18043 as shown in Figure 65. The report properties were changed to
allow 20,000 records so the report could run.
- 126 -
Figure 64. SQL generated by report selection based on OLTP data structures
__________________________________________________________________
Figure 65. Result of OLTP test record selection when records exceed report limits
__________________________________________________________________
A left outer join was used. This will return all the rows that an inner join
returns plus one row for each of the other rows in the first table that did not have a
match in the second table. The resulting report may be seen in Figure 66. Data has
been obscured for privacy but aggregation levels are apparent.
Data obscured for privacy
Figure 66. Report presented by integrating BI with ERP directly
__________________________________________________________________
- 127 -
7.7.2.2 Build a data mart based on a star schema with aggregation - OLAP
Figure 53 presented an image of the m-Power “Create new Table from
Spreadsheet Data” feature. This utility was used to create the data mart as outlined in
the logical model in Figure 60. The data in the fact table was aggregated to a
granularity of daily totals by item number in the spreadsheet for convenience before
loading to the FSALES fact table (See Figure 67). Time and item dimension tables
were loaded in the same way (see Figure 68 and Figure 69 respectively).
Figure 67. Example of Fact table data before loading to data mart
_______________________________________________________________
Figure 68. Example of Time Dimension data before loading to data mart
________________________________________________________________
Figure 69. Example of Item Dimension data before loading to data mart
________________________________________________________________
As in method one, it was necessary to register the new data mart tables to the
m-Power metadata repository. Figure 70 displays the resultant entries.
- 128 -
Figure 70. m-Power metadata repository showing data mart tables registered
Report design was performed in the same way as method 1. Synonyms were
assigned as follows to link the newly registered tables:
Link FSALES to DITMAS using Item Number
Link FSALES to DTIME using Invoice Date
The selection screen presents similar to method 1 as seen in Figure 70.
Figure 71. Report selection screen OLTP vs OLAP: Data mart test
__________________________________________________________________
- 129 -
The number of records meeting the selection criteria in the newly aggregated
data mart fact table was 8605. The properties of the report were changed to allow
5000 records to display to produce the error in Figure 72.
Figure 72. REsult of record selection on method 2 where records exceed report limits
__________________________________________________________________
The result of the aggregation in the data mart has been a reduction in the
number of records meeting the selection criteria from 18,043 to 8,605 in the test
scenario. The SQL generated by the report is shown in Figure 73.
Figure 73. SQL generated by report based on OLAP data structures
_________________________________________________________________
- 130 -
Figure 74 presents the result of the OLAP test report. As in method one aggregation
levels are apparent.
Data obscured for
privacy
Figure 74. Report presented by integrating BI with the data mart
__________________________________________________________________
7.7.3 Testing and Results of OLTP vs OLAP Query Processing
The reports were run 10 times each against the underlying tables to get an
average runtime in micro seconds (µs). The reports were run against live system data
while the system was in use by the ERP system users and also on a dedicated system
with no users other than the author. This was preferable to give a true reading of how
the retrieval would behave in a live environment since timings will vary with system
activity. Large spikes in run time are attributed to contention for system resources on
the active system.
- 131 -
Table B
Query Response Times against an OLTP Structure on an Active System

_________________________________________________________________
Measure Time used Time used Total query
and Variable in DB query (µs) in other logic (µs) runtime (µs)
_________________________________________________________________
Report run via OLTP structure
1st run 103441 1016 104457
2nd run 6188 1031 7219
3rd run 6250 1016 7266
th
4 run 5844 1016 6860
th
5 run 5750 1016 6766
6th run 5704 1030 6734
7th run 6313 1031 7344
th
8 run 51096 1031 52127
th
9 run 5891 1015 6906
10th run 5860 1016 6876
_________________________________________________________________
Average run time
Over 10 runs 20234 1022 21256
_________________________________________________________________
Note: An active system is one in use by ERP and other AS400 iSeries users during the normal
course of business.
As Table B shows the average time taken to run the report against the ERP
database files directly is effected by resource contention on an active system. The
runtimes in the 1st and the 8th run have caused the average run time to increase greatly.
This is always likely to be a problem with performing retrievals directly on the OLTP
based data structures inherent in the ERP system. Such systems are built for
transactions and are not designed for speed of retrieval. The resource contention on a
live system caused by file and other resource waits need to be considered. In SMEs
- 132 -
with a small number of active users such delays may be acceptable, however larger
sites may find the retrieval times unacceptable.
Table C
Query Response Times against an OLTP Structure on a Dedicated System

_________________________________________________________________
_________________________________________________________________
1st run 6031 1016 7047
2nd run 6156 1000 7156
rd
3 run 6000 1000 7000
th
4 run 6094 1000 7094
5th run 6110 1000 7110
6th run 6110 1000 7110
th
7 run 6094 1000 7094
th
8 run 6173 1000 7173
9th run 6047 1000 7047
10th run 6000 984 6984
_________________________________________________________________
Average run time
Over 10 runs 6082 1000 7082
_________________________________________________________________
Note: A dedicated system is an AS400 iSeries in use by the author only outside normal
business
The response times on the dedicated system were much more acceptable and
predictable with an average of 7082 µs (see Table C). A dedicated system is not going
to be possible in reality. The comparison was made to highlight the contention issues
associated with running retrievals on an active transaction processing system.
- 133 -
Table D
Query Response Times against an OLAP Structure on an Active System

_________________________________________________________________
_________________________________________________________________
1st run 625 609 1234
2nd run 453 579 1032
3rd run 219 562 781
th
4 run 203 719 922
th
5 run 297 703 1000
6th run 219 686 905
7th run 187 702 889
th
8 run 218 702 920
th
9 run 265 703 968
10th run 203 703 906
_________________________________________________________________
Average run time
Over 10 runs 289 667 956
_________________________________________________________________
Note: An active system is one in use by ERP and other AS400 iSeries users during the normal
course of business.
The results in Table D against the active system for the OLAP structure were
impressive. Taking into consideration the total records been analysed is 18043 pre-
aggregation in the OLTP files and 8605 post aggregation to daily sales by item
number in the OLAP files the improvement is significant. The number of records
matching the selection criteria is small in the test in comparison to what one may
encounter in a sizeable organization. The improvement achieved will have a
multiplier effect as the database grows. For each record meeting the selection criteria
- 134 -
a match must be found by sifting through the joined tables, therefore there are
substantial performance improvements to be attained by reducing the number of
records through aggregation and reducing resource contention through using the
OLAP schema which will probably be used by fewer users than the primary ERP
system.
Table E
Query Response Times against an OLAP Structure on a Dedicated System

_________________________________________________________________
_________________________________________________________________
1st run 625 578 1203
nd
2 run 250 766 1016
rd
3 run 219 578 797
4th run 297 578 875
5th run 281 563 844
th
6 run 281 578 859
th
7 run 218 578 796
8th run 234 563 797
9th run 203 578 781
th
10 run 250 579 829
_________________________________________________________________
Average run time 286 594 880
Over 10 runs
_________________________________________________________________
Note: A dedicated system is an AS400 iSeries in use by the author only outside normal
business
A small improvement is achieved on the dedicated system for the OLAP
schema (see Table E), which you would expect but the difference is not significant.
The fact and dimension tables were not subject to wait times by requests from other
system users in the test environment.
- 135 -
Method 3 which suggested the use of a combination of OLTP and OLAP was
not tested post the results of the comparison. The problem with using OLTP files
directly is that they are likely to be in use not only by BI users but also the ERP users
and therefore this adds performance overhead. Where a table within the ERP system
is seen to be useful for static data or slowly changing dimensions it may be worth
considering copying it to the BI repository and registering the copied version. This
way there will be less contention on use. For this reason Method 3 is deemed
unsuitable.
In summary, improved performance has been achieved through using the
OLAP schema with the BI application. The concluding sections of this chapter will
present reports designed to monitor identified KPIs for the trial, final analysis on BI
maturity status post implementation and summary comments.
7.8 Reports Designed to monitor KPIs identified
An additional fact table was added to the metadata repository based on the
principles outlined in the data mart design for sales by customer at daily granularity.
The final work to complete the case study surrounded the ease or difficulty with
which a user could design reports, dash boards and enquiries. The purpose of this
section is to present the reports designed and document the author’s opinion on the
usability of the tool from an end user and power-users perspective. It is important to
determine if a BI tool can be used by properly trained end users post implementation
with minimal support in support of the fifth hypothesis stated in Chapter 1.
7.8.1 Report Design and Analysis
The following reports were designed using the m-Power tool to satisfy the
requirements outlined in the project scope in relation to presentation of the identified
- 136 -
KPIs using the BI application. The focus is on report content as opposed to
presentation.
Figure 75 presents the TOP N analysis which is a flexible report format where
N can be substituted with any numeric variable which makes sense to the business
domain for monitoring. The report permits ranking by sorting in ascending or
descending order by any of the attribute columns shown. The report in Figure 75 is
currently presenting the 10 lowest sales values (an operational level KPI). The same
report can be inverted to show the top 10 customers by value or quantity.
Figure 75. Top N analysis company A
__________________________________________________________________________
Note. The data in this report has been obscured to protect the privacy of Company A
Reports at this level would be suitable for information consumers such as
executives and managers. Once a data mart is in place this report was easily generated
without specific programming skills. Pre-defined templates facilitate report authoring
by power-users who have been trained in this task. These reports should be added to
the library of available reports for re-use to minimise ad-hoc reporting.
- 137 -
Figure 76 presents a report on sales by market segment (an operational level
KPI).
Figure 76. Sales by value in each market sector in which the company operates
____________________________________________________________________
The report in Figure 76 uses the data mart to produce this combination tabular
data with graphic presentation. The report design skills are easily within the reach of
the trained power user. No programming skills were required. Knowledge of the
metadata repository tables and relationships is useful. A report at this level is suitable
for executives and managers and one which would be added to the library.
The report in Figure 77 represents a more tactical level KPI looking at lower
level detail. The report utilizes the same data marts as defined previously to generate
the output shown. Once again the design level skill level required is power user.
- 138 -
Figure 77. Sales by customer and product group
___________________________________________________________________
The report in Figure 78 is aimed at casual end users and is symbolic of a pre-
built library report suitable for this level of user. Often end users wish to query data in
an ad-hoc fashion. The report in Figure 78 allows sorting by any of the attributes in
ascending or descending order. It also permits filters to be applied to render a
selection of records meeting the end users criteria. Figure 79 shows a filter being
applied to show only the records for customer C214 for period 200802 (Feb, 2008)
and Friday sales only. This format is very flexible.
Figure 78. Suggested library report for end users with filter capability in m-Power
_____________________________________________________________________
- 139 -
Figure 79. End user report style displaying use of filters in m-Power
_____________________________________________________________________
Reports like this should be designed by the business analyst or IT who have a
good knowledge of the metadata repository and end user needs. A well designed
report could eliminate multiple ad-hoc reports and reuse is guaranteed as the report
can be customized to show the end user what they require for a particular scenario.
At the strategic level one of the KPI’s identified for the trial was sales growth
of 5% per annum. Higher level executives do not wish to get burdened with detail.
Dashboards provide a good mechanism for them to view items of interest. Figure 80
provides a prototype for a dashboard with some very basic detail. The design skills
required in the case study to produce a dashboard were a bit more complex and would
require some specialist MIS knowledge. The dashboard depicted in Figure 80 for
example required some tweaking with the html source code to present as is. More
complex presentations would require programming skills in html. From the case study
it is felt this level design would be more suited to the IT function. Where one does not
exist the vendor may be required to help with presentation. The reports presented on
the dashboard can be easily designed by power users. The presentation on a dashboard
was a little more complex. Other applications may be stronger than m-Power in this
area so the observation is made in relation to the case study observations only.
- 140 -
Figure 80. Example of an executive dashboard for Company A displaying sales growth
_____________________________________________________________________
7.8.2 Additional benefits noted in the case study on the use of BI
One of the benefits attainable from layering a BI application over a legacy
ERP system is the ability to web enable some of the components. As indicated
previously the ERP system in use in the case study company is green-screen. Using
the m-Power tool new front end GUIs could be used to replace traditional enquiry
screens. A very simple example is shown in Figure 81 for a customer lookup.
- 141 -
Privacy screen
Figure 81. m-Power enquiry screen example
____________________________________________________________________
7.8.3 Summary Comments
This section has demonstrated report design and documented the skills
required to produce each report style. It is the author’s opinion that a BI system
layered over an existing ERP system (legacy or otherwise) can deliver improved
operational and strategic planning in resource constrained SMEs.
7.9 BI Maturity Post Implementation
The goal of the trial implementation is to move from Infant to Adolescent as depicted
by the Child and Teenager levels on the TDWI’s BI Maturity model (see Chapter 6,
Figure 49). The characteristics of this level were listed earlier in section 7.5. The
existence of data marts is indicative of this new state. Empowering users to retrieve
their own data and a reduction on the reliance of spreadsheets are also commonly
found at this stage. Business is getting some benefit from the investment. Analysis is
typified by moving from “What happened” to “Why did it happen” as indicated in the
- 142 -
Business Intelligence Maturity Model (BIMM ) (see Figure 50 in Chapter 6). In terms
of the information lifecycle model from IBM (see Figure 51, Chapter 6), data has
progressed from “data to run the business” to a more flexible information architecture
where information is used to “manage the business.” There is still some way to go to
maximise the benefit from BI. The later stages of BI maturity involve data mining and
real time analytics. Chapter 8 will introduce the topic of real time analytics and
present some tools for integrating them with business processes.
7.10 Conclusion
Based on the analysis performed in the case study, the author concludes that
integrating BI tools directly with ERP OLTP schema is not recommended. One of the
best arguments for creating a separate data mart is the fact that OLTP systems require
fewer indexes for transaction processing speed whilst OLAP systems require more
indexes to speed analysis so their designs serve different and conflicting purposes. A
key differentiator between SMEs and large organizations is that although SMEs may
be constrained by budgets and resources, they often have the benefit that their IT
infrastructures are less complex than those of larger organizations. Integration of BI
with existing systems may therefore be simpler for this group. This may be one reason
why some SMEs may opt to integrate BI tools directly with the ERP’s database
directly. Other reasons may include lack of in-house expertise in creating staging
areas for ETL and actual performance of ETL tasks. The payload for adopting this
approach is high in terms of a hit on performance, even in small data sets.
Utley (2008) makes a suggestion that where it is possible, organizations could
run a second copy of the OLTP database which is used for data analysis. The second
copy could be more de-normalized and contain more indexes. This however is
unlikely to be a solution for budget and resource constrained SMEs. The data mart
- 143 -
approach is the recommended approach. Creating data marts does require a particular
skill set to ensure good design, control and ongoing management. Data marts are
particularly suited to environments where there is more than one source for the data,
data can be classified into single subject based repositories and data needs to be pre-
summarised as volumes are large to facilitate good interactive query response and
avoid resource contention with other system users. Tools such as the “create table
from spreadsheet data” which m-Power ships make it easier for SMEs with no IT
resources to load data to the data mart without requiring knowledge of programming
languages or Database Management System’s (DBMS) Data Definition Language or
Data Manipulation Languages (DML).
Layering a BI solution over legacy ERP systems can save money on licensing
fees. Products like m-Power are licensed per platform. There are no restrictions on the
number of users. A user licence for a typical ERP system could be from €2000 -
€5000 per seat. This is a waste is you are enrolling users purely so they can perform
enquires and run reports. Although this is not an endorsement of the m-Power
application, products like this can be used to build enquiries (retrievers), to create new
output files (summaries), to create maintainers (data update forms) and design output
forms such as invoices and statements (to pdf, email, xml, .csv and html). Some
suggestions from the case study going forward to SMEs or any organization who
would like to get more mileage from legacy ERP systems follow.
The ability to output to xml and html means products like m-Power can be
used to create portals and perform data interchange in the supply chain. You can
create new front-end GUIs for users. In company A for example the ERP system is
running in character based green-screen. Designing new enquiries over the ERP
systems database permits a GUI front end without the need to upgrade or change the
- 144 -
legacy system, purchase additional products or licences thus adding new life to old
technology (See Figure 81). This comes with a performance warning based on the
present research.
The best advice is to map tools to the users as in Figure 52. Provide the
aggregated data at the correct summary level and permit power users to design reports
on the pre-defined aggregated data. In the literature review a suggestion was made
about using hybrids – individuals with both IT and business knowledge as part of the
BI implementation team. This approach works very well and reduces the reliance on
external consultants. Where hybrids exist, use them. Where they don’t, expect to pay
a little more to the consultants.
Self service BI is possible but this means different things to different user
groups. For power users, it means access to report authoring to create their own ad-
hoc reports from pre-configured data marts. For casual end users and executives it
means accessing the pre-defined reports library and utilising data content filters too
get what they need. For IT and Business Analysts it means empowering end users and
concentrating more on OLAP design and management.
In relation to the fifth hypothesis it is the author’s belief that there is an
affordable BI solution which can be used successfully post installation by properly
trained end users to attain sufficient information to facilitate improved operational and
strategic planning with minimal support. The approach is as outlined in this section.
Products like MRC meet the criteria in terms of cost, relative ease of use (with the
exception of advanced report presentation graphics) and functionality. The training
required is approximately two to three days for information producers and
approximately half a day for information consumers. This section has provided a
- 145 -
examples of integrating corporate strategy via a hierarchical KPI structure which can
then be monitored through the use of a BI application.
- 146 -
Chapter 8 - Moving BI to the Next Level
8.1 Introduction
Chapter 5 identified that SMEs have strategy planning capability, but they are
lacking in strategy implementation capability. Using BPM an organization can
facilitate the execution of strategy by incorporating business goals into operational
processes end to end. Aberdeen Group (in Lock, 2009) concurred with these findings
indicating best in class SMEs invest in technology solutions to automate BI processes.
This chapter looks at the characteristics of a mature BI Implementation to provide
evidence of the need to integrate business processes using BI tools to provide real
time access to operational data. SOA architectures are discussed as a means of
instantiating automated business processes and WS-BPEL is presented as a means to
construct business process integration backbones capable of linking with Web
services and advanced BI tools to provide real time data and process automation.
8.2 Characteristics of BI Maturity
The TDWIs BI Maturity Model introduced in Chapter 6, Figure 49 details
what is referred to as the Adult and Sage levels of BI maturity. According to Eckerson
[1], (2007) the progression to BI adulthood is marked by:
• a rapid increase in the use of the BI solution by end users, (including
customers and suppliers in highly mature implementations).
• a progression from insight delivery to business monitoring and automated
decision making.
• The introduction of time-sensitive or real-time data.
• Centralized management of the BI resource (often a separate BI team, distinct
from IT)
- 147 -
• The use of persistent staging areas as part of ETL activities which can be used
to rework data as the business changes without going back to the source
system
• Operational BI capturing data in near real time is being used to drive the
business.
• The use of predictive models
The final stage of BI maturity or Sage level is characterised by Eckerson [1], (2007)
as:
• leveraging Web and middleware services to create composite, blended
applications
• embedding predictive models into operational applications to automate
decisions
• delivering new value added services to customers and suppliers
Moving to BI maturity therefore necessitates more operational and real time
BI. The following sections will introduce some tools and methodologies to facilitate
real-time and operational BI through the integration of business processes.
8.3 Service Oriented Architectures (SOA)
Service Oriented Architecture (SOA) is an architectural style for creating and
using business processes, packaged as services, throughout their lifecycle (Fishteyn,
n.d.). SOA style architectures permit participation in business processes through
provisioning the IT infrastructure to allow data exchange. “Functions are loosely
coupled with the operating systems and programming languages underlying the
applications. SOA separates functions into distinct units, or services, which can be
distributed over a network and combined to create larger business processes and/or
workflow. Services communicate with each other by passing data from one
- 148 -
application to another, or by coordinating an activity between two or more services,
such as Web Services with varying degrees of encryption or security (Fishteyn, n.d.).”
SOA allows applications to pass data back and forth without in-depth knowledge of
recipients IT systems behind a firewall. From a BI perspective SOA is beneficial
because it allows for more effective integration of business processes leading to the
possibility of real time analytics for BI. Figure 82 displays a graphical view of the
interoperation between services in an SOA environment.
Figure 82. SOAs Find-Bind-Execute paradigm
__________________________________________________________________
Source: Mahmoud, (2005)
8.4 Web Services
Mahmoud (2005) explains the concept of Web Services as software systems
designed to support interoperable machine-to-machine interaction over a network
gained through a set of XML-based open standards, such as Web Service Definition
Language (WSDL), Simple Object Access Protocol (SOAP), and Universal
Description Discovery and Integration (UDDI), which are standards for defining,
publishing, and using Web Services. Web Services provide a means to realize SOA.
- 149 -
The W3C (2004) state a Web Service “has an interface described in a machine-
processable format (specifically WSDL). Other systems interact with the Web service
in a manner prescribed by its description using SOAP messages, typically conveyed
using HTTP with an XML serialization in conjunction with other Web-related
standards.”
8.5 Business Process Integration
Moving towards BI maturity requires the integration of business processes to
provide more automated analytics. A business process is a set of logically related
business activities that combine to deliver something of value (e.g. products, goods,
services or information) to a customer (Cousins & Stewart, 2002). Processes can vary
greatly from one industry to another but a process has a number of common
characteristics. Britton & Bye (2004) list the following attributes of a process which
serves as a useful starting point:
• A process delivers something – usually goods or a service
• A process follows a plan that defines the order of the activities
• Activities can sometimes be processed in parallel
• Activities can be conditional where process plans have path choices
• Activities can be processes in their own right
• A process can start another process
• A process may be ongoing, often involving loops
• Process plans may be prescriptive involving rigid ordered activities or more
flexible with certain defined constraints
• Process execution may not always go according to plan
• Processes may compete for resources
- 150 -
• Business processes can be sub-processes of larger business processes.
• Business processes share information
This section has provided an overview of business processes through defining their
characteristics. In a BI implementation business process review is a precursor to
implementation. SMEs may find they have little time or resources for such a large
undertaking as a complete business process review. This does not mean it should be
ruled out. The approach is always to work within the boundaries of available
resources and prioritize based on what brings the most business benefit in the shortest
time frame within those constraints. In a BI implementation consider if any processes
are ripe for data collection and automated analysis related to metrics.
The preceeding sections have outlined some of the technologies involved in
automating business processes. The remainder of this Chapter will focus on Web
Service Business Process Execution Language (WS-BPEL), a language which
integrates the components necessary for real time and operational BI.
8.6 Web Services Business Process Execution Language (WS-BPEL 2.0)
8.6.1 WS-BPEL Evolution
The Business Process Execution Language for Web Services (BPEL4WS) was
first conceived in July 2002 with the release of BPEL4WS 1.0 specification, a joint
effort by IBM, Microsoft, and BEA. The document proposed an orchestration
language inspired by previous variations, such as IBM’s Web Services Flow
Language (WSFL) and Microsoft’s XLANG specification. Version 1.1 was released a
year later in May 2003 with contributions from SAP and Siebel. The current version
WS-BPEL 2.0 was deemed complete in April 2007. Figure 83 provides a
chronological view of the emergence of the language to the present form.
- 151 -
Figure 83. Evolution of WS-BPEL 2.0
_________________________________________________________________
Numnonda & Kruawaisaywan (2009).
8.6.2 WS-BPEL Definition
A WS-BPEL process is a reusable definition that can be deployed in different
ways and in different scenarios, while maintaining a uniform application-level
behavior across all of them (Oasis, 2007). Business processes can be described in two
ways. Executable business processes model actual behavior of a participant in a
business interaction whilst abstract business processes are partially specified
processes that are not intended to be executed (Oasis, 2007). An abstract process may
hide some of the required concrete operational details. Abstract Processes serve a
descriptive role, with more than one possible use case, including observable behavior
and process template. According to Oasis (2007) Web Services alone are not
- 152 -
sufficient to implement business logic; BPEL provides a means to orchestrate the
functionality offered by Web Services in a predefined order. WS-BPEL is meant to be
used to model the behavior of both Executable and Abstract Processes thus extending
the Web Services interaction model and enabling it to support business transactions
(Oasis, 2007). The Oasis (2007) definition states, “WS-BPEL defines an interoperable
integration model that should facilitate the expansion of automated process integration
in both the intra-corporate and the business-to-business spaces.”
8.6.3 Language Specification
Oasis (2007) indicate that WS-BPEL utilizes several XML specifications:
WSDL 1.1, XML Schema 1.0, XPath 1.0 and XSLT 1.0. WSDL messages and XML
Schema type definitions provide the data model used by WS-BPEL processes. XPath
and XSLT provide support for data manipulation (declaring and manipulating
variables). All external resources and partners are represented as WSDL services.
8.6.4 WS-BPEL Application
Numnonda & Kruawaisaywan (2009) term WS-BPEL as being a Web Service
sequencing language whereby a process defines a “conversation” flowchart consisting
of WSDL described message exchanges. A process instance is a particular
conversation following the flowchart and service engines can instantiate multiple
instances concurrently. Numnonda & Kruawaisaywan (2009) further describe WS-
BPEL is a Web Service Composition language which can:
• Consume services – invoke
• Create services – receive/reply
• Aggregate fine grained services
• Create coarser grained services
- 153 -
Among the benefits of WS-BPEL are portable processes supported by an
industry wide language for business process with many process engines and IDE tools
to develop it. Design tools include Netbeans 6.5, Eclipse, Oracle JDeveloper 10g and
the IBM Websphere Studio. Service engines include GlassfishESB, Oracle BPEL
Process Manager, Microsoft Biztalk and Active BPEL Engine. Netbeans 6.5 in
conjunction with the Glassfish V2 server engine will be used by the current author to
illustrate WS-BPEL as a means to orchestrate KPI related constructs in a BI
environment. The diagram in Figure 84 displays where WS-BPEL sits in the Web
Services stack.
Figure 84. Web Services stack
____________________________________________________________________
Source: Pieczkowski (2007)
- 154 -
8.6.5 WS-BPEL Language Constructs
This section provides a brief synopsis of the main language constructs of the
WS-BPEL 2.0 specification extracted from Oasis (2007). The objective is to provide a
high level introduction to WS-BPEL 2.0 to facilitate understanding of the elements of
a WS-BPEL 2.0 process.
Process: A container where you declare relationships to external partners,
declarations for process data, handlers for various purposes and the activities
to be executed (A process may be declared as having global or local scope).
Partner Links: Instances of typed connectors which specify the WSDL port types the
process offers to and requires from a partner at the other end of the partner
link.
Variables: Hold the state of a BPEL process during runtime. Variables must be
WSDL messages, XML schema simple types, XML schema complex types or
XML schema elements.
The three definitions above constitute the structure, relationships and state of a
process. The behaviour of a process is governed by activities. The following dictate
behaviour with partners.
Receive: Receives messages from external partners
Reply: Used in conjunction with a receive activity to instantiate a request- response
operation on a partner link.
Invoke: Calls a web service provided by a partner
Control over the process logic (business logic) is governed by sequence and
conditional type activities.
Sequence Activity: Defines a collection of activities which are executed sequentially
in lexical order
- 155 -
if-else: Select a branch from a set of choices
Repetitive Activities (while, repeatUntil and forEach): permit repeated execution of
a piece of logic.
Parallel processing is catered for in WS-BPEL 2.0 by use of the flow activity.
Parallel execution can be further conditioned by making the execution of an activity
dependent on the completion of another activity and/or a certain condition being true
or false. Data manipulation of variables takes place using the Assign activity. Where
data passed to a process needs to be split XPATH 1.0 expressions can be used. This is
necessary if the data being received needs to be processed by different partners as in
the case of a payment transaction which must update a customers account and also
pass the payment for processing by a third party credit card company. Such data may
have been passed to the process in one XML complex type variable. Fault handlers
using catch and catchall statements deal with exceptions when they arise. A fault
handler can be attached to a scope, process or individual activity. Compensation
handlers are used to reverse previously committed work. WS-BPEL 2.0 defines
constructs to deal with what is termed inbound message activities.
Pick: Provides a means for selective event processing using one or more onMessage
activities and zero or more onAlarm activities (point in time or time interval check).
Event handlers provide a means to process requests which run in parallel to the
normal process flow. Message correlation is used to uniquely identify a process
instance for a particular request. Appendix X provides a diagrammatic view of the
structure of a WS-BPEL process. Appendix X provides a graphical view of the
control flow elements of a process as defined by WS-BPEL.
- 156 -
8.6.6 Sample WS-BPEL Process
Figure 85 provides a simple representation of an orchestrating process’s
relationship with partners. The instantiation of such a process will be demonstrated
through a review of a sample process generated using the Netbeans BPEL engine.
This example serves to facilitate understanding of the constructs used in a BPEL
process. The sample process is based on a template provided by Sun Microsystems
(2007) and serves as an illustration only.
Figure 85. BPEL: Relationship to partners
____________________________________________________________________
Source: Numnonda & Kruawaisaywan (2009).
A process can be either synchronous or asynchronous. A synchronous process
is where a client sends a message to a process, waits for a reply, and continues work
on receipt of the reply. An asynchronous process applies to long running
conversations in which the client does not wait for a reply before continuing its work.
The long running process will return a reply asynchronously when the request is
complete to the client. The sample in this presentation is a synchronous process. The
approach used to present the example is to show a graphical view of the design
followed by an analysis of the code generated by the design. Figure 86 presents the
- 157 -
GUI designer for a BPEL process in Netbeans 6.5.1. The designer permits click and
drag design from a palette containing three types of activities, Web Service, basic and
structured as seen in Figure 87.
Figure 86. BPEL process designer image for simple synchronous process
_____________________________________________________________________
Copyright (c) 2007, Sun Microsystems, Inc. All rights reserved.
The palette extracts in figure 87 jointly represent the constructs listed earlier in
section 8.6.5.
- 158 -
Figure 87. BPEL activities on Netbeans Pallette
____________________________________________________________________
The process indicated in Figure 86 illustrates a synchronous flow. The process
receives an input message and sends it back synchronously. A client starts the
synchronous process by invoking a request-response operation. After invoking a
synchronous process, the client is blocked until the process finishes and returns the
result. To provide an understanding of the diagrams to follow the activities involved
in the process example are as follows:
1. Client (operation1) sends a string variable to the process
2. The process checks the content of the string and performs conditional logic
based on the value received.
If the string says “Hello World” the value is returned to the client
unchanged
- 159 -
If the string variable contains anything other than “Hello World” the
process concatenates the text “Hello” to the contents of the string and returns the
new value
A BPEL Process Module comprises three file types.
.bpel - BPEL source (Stores the code behind Figure X)
.wsdl - Web Service definition language source
.xsd - XML schema definition
A BPEL Process Module is not directly deployable. You must add a BPEL
module as a JBI module to a Composite Application Project which can then be
deployed as a service assembly to the application server. This is all handled quite
easily by the Netbeans IDE.
The client in Figure 86 (operation1), passes a variable to the process and waits
for a response. In the example illustrated the variable passed is defined as an XML
schema complex type. As indicated previously variables hold the state of the process
while running. The variable types for a process are defined in an XML schema file
(.xsd) and contain content similar to that illustrated in Figure 88.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xml.netbeans.org/schema/SynchronousSample"
xmlns:tns="http://xml.netbeans.org/schema/SynchronousSample"
elementFormDefault="qualified">
<xsd:complexType name="simpleProcess">
<xsd:sequence>
<xsd:element name="paramA" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="typeA" type="tns:simpleProcess"/>

</xsd:schema>
Figure 88. Example of XML schema definition for BPEL Process Module
___________________________________________________________________
- 160 -
You can tell from the code the variable being passed is a string using a named
type of “typeA”. The XML variable definitions are represented graphically as in
Figure 89.
Figure 89. Graphical view of variable definitions for BPEL Process Module
_____________________________________________________________________
The final link in the chain is defining partner links which are stored in the
.wsdl file. Figure 90 presents a graphical view of the partner links defined in the
sample process showing the variables exchanged by the partners.
Figure 90. Partner links for the sample BPEL process
_____________________________________________________________________
- 161 -
The BPEL designer permits mapping of incoming variables to outgoing
variables (see Figure 91 and Figure 92) in the process definition. It is this facility that
allows information passing between processes. This ability makes BPEL Process
Modules suitable for SOA, Web services and in the present study business process
integration for advanced BI.
Figure 91. Mapping of input and output variables in BPEL process
______________________________________________________________________________________________________
Figure 92. Conditional logic applied to manipulate return variable in BPEL process
_______________________________________________________________________________________________________
- 162 -
8.7 Conclusions
This chapter has provided a high level overview of the use of Netbeans for
WS-BPEL 2.0 projects. WS-BPEL facilitates business process integration. It can be a
complex process and a lot of SMEs may not wish to invest the time in using it. The
reality is by automating business processes there are savings to be made and it is only
through performing activities such as end to end process integration that organizations
can reach BI maturity. For SMEs the advice would be to consider the use of WS-
BPEL as part of the business process analysis. Select processes only on the basis of
those ripe for advanced BI where a business case can be made. Possible uses for this
technology in manufacturing SMEs such as the case study company are Business
Activity Monitoring (BAM) of production activities. Real time data generating alarm
conditions and progress means decision makers can act quickly and make savings as a
result of less downtime. Scenarios such as this are when BI is driving the business.
- 163 -
Chapter 9 – Alternate BI and ERP Delivery Methods
9.1 Introduction
This chapter outlines some alternatives for SMEs to consider when embarking
on a BI or ERP project. The purpose of the chapter is to highlight alternative
strategies, as opposed to endorsing the products, organizations or platforms
showcased. There are hundreds of possible vendors and applications to choose from.
The big players in the BI market in 2008 were Business Objects (SAP), Cognos
(IBM), SAS, Hyperion (Oracle) and Microstrategy (Gartner in Whiting, 2009). The
challenge however is finding affordable ERP and BI for SMEs and using platforms
and support structures suited to industries in the SME manufacturing segment. This
chapter introduces SaaS from IBM, an open source BI product from Pentaho
Corporation and Amazon EC2 (Cloud) as examples of alternatives to traditional
proprietary licensed products. The objective is to provide sufficient information for
SMEs to explore these areas as part of any ERP / BI selection and integration process.
9.2 Showcase 1: SaaS
Fishteyn (n.d.) describes SaaS as a multi-tenant platform that uses common
resources and a single instance of both the object code of an application as well as the
underlying database to support multiple customers simultaneously. Immediately alarm
bells may ring at the thoughts of the data belonging to multiple organizations residing
within the same database outside the business boundaries.
Fishteyn (n.d.) describes some of the issues and concerns organizations have in
relation to SaaS application delivery and suggests associated remedies:
Concern: Lack of governance to ensure isolation among customers where
database and schema are shared.
- 164 -
Remedy: Separate databases per customer or shared database but separate
schemas.
Comment: There may be higher costs associated with separation and more
complex configurations to upgrade and deploy.
Concern: Lagging response times and lack of scalability.
Remedy: Load balancing across multiple servers.
Comment: Load balancing also provides failsafe in the event of failure of
individual components.
Concern: Lack of security.
Remedy: Detect and prevent intrusion, through strong encryption,
authentication, and auditing. Ensure environment is covered by a data
assurance service such as Sys-Trust and or SAS-70.
Other suggestions made by Fishteyn (n.d.) include making sure a Service
Level Agreement (SLA) is used. SLAs should contain clauses covering availability,
restores and contingency, liability, controls for performing upgrades and security
agreements. The advantages of SaaS models include less reliance on internal IT,
anywhere access to the application, pay-as-you go pricing with no up-front cost and
vendor management of the application and infrastructure (Torode, 2009).
Disadvantages of SaaS models include lack of built-in integration with the rest of an
organization's data. This can be overcome by allowing secure access through the
company’s firewall(s) using SOA style architectures as indicated in Chapter 8.
IBM (2008) describes a requirement to permit a small business to get started
without heavy up-front investment in hardware, software and IT personnel. In
conjunction with The Systems House Inc. they implemented a SaaS model in
- 165 -
Heartland Medical Supply, LLC, a sales and distribution company in Iowa City, who
started with eight employees, but at time of writing they employed 16. The solution
contained essential business and operational functions, including order entry,
invoicing, purchasing, sales, receivables, payables, reports, warehouse management
and general ledger which formed part of a package called MDS designed by The
Systems House. The SaaS version of MDS runs on an IBM System p server running
the IBM AIX® operating system at the Systems House premises. The database
functionality is provided by IBM UniVerse and IBM UniData, which together IBM
calls the U2 Data Servers. Connectivity with the customer is provided through two
different broadband Internet service providers, one supporting inbound traffic and the
other supporting outbound traffic, plus a DSL line for backup. Payment for services is
via a monthly subscription fee. The customer claimed the benefit was they needed no
major up-front investments, either in software, hardware or IT personnel.
9.3 Showcase 2: Professional Open Source
A recent survey of 530 SMBs by Aberdeen Group (Lock, 2009) indicated an
increase in the use of open source BI among this group (see Figure 93).
Figure 93. Growth in open source BI Licensing
_________________________________________________________
Source: Lock (2009)
- 166 -
Pentaho Corporation (Pentaho [1], 2009) describes themselves as the
commercial open source alternative for Business Intelligence. Pentaho BI Suite
Enterprise Edition provides reporting, OLAP analysis, dashboards, data integration,
data mining and a BI platform. Pentaho's commercial open source business model
eliminates software license fees (a primary inhibitor to BI uptake in SMEs), providing
support, services, and product enhancements via an annual subscription in what they
term professional open source as opposed to community based open source. They
claim their products have been downloaded more than three million times, with
production deployments at companies ranging from small organizations to the Global
2000. They differentiate what they call professional open source from standard
community based open source software. Appendix P contains an overview of the
features offered in the Community and Enterprise editions of the Pentaho BI Suite.
The complete Enterprise suite may be downloaded and used for a 30 day trial period
(the community edition is free). The tiered (optional) subscription charges are detailed
in Appendix Q. The components of the suite comprise:
Pentaho BI Server: An enterprise class BI platform supporting end user
reporting, analytics and dashboards with back end security, integration,
scheduling and workflow capabilities.
Pentaho Enterprise Console: A standalone thin client interface for
administering users, roles, data sources and scheduling.
Pentaho Design Studio: A collection of editors and viewers providing a
graphical environment for building and testing action sequence documents.
Pentaho Metadata Editor: Builds metadata domains and repositories.
Report Designer: Primary tool for report design and generation.
- 167 -
Pentaho Schema Workbench: Tool for designing, editing and publishing
Analysis (Mondrian) OLAP schema.
Pentaho Aggregation Designer: Utility to create aggregate tables to improve
query performance of Mondrian OLAP schema.
Pentaho Data Integration: ETL utility which utilises metadata.
The solution uses MySQL as the solution repository (reports, users, analysis
views etc.). The trial version ships with a sample database containing the data for a
fictitious company which can be used to gain familiarity with the product and it also
contains detailed installation and getting started documentation. The trial version is
not restricted to working on sample data. The application permits connection to a
companies own data by configuring a data source in the Enterprise Console (see
Figure 94) which requires a JDBC class name for the database driver, the data source
URL (server name, port number, database name) and the userid and password needed
to connect to the database. Pentaho provide common JDBC drivers but additional
JDBC drivers may be added. Those required for AS400 connectivity required by the
case study Company A were not available but were retrievable and installed enabling
a successful connection to the Movex database files (see Figure 95). Tomcat is the
Java application Server which hosts the BI Server Web application. Products like
Pentaho BI suite may be a feasible solution for SMEs with limited resources and
budgets intent on a BI project. Professional open source approaches may help to calm
the nerves and alleviate some of the fears companies have about using open source
software. It is certainly worth a look and will only cost the time to download, install
and trial. The subscription offerings (see Appendix Q) are flexible and can be tiered
based on the support level required by an individual company. Savings made on
licensing could be redeployed to training and consultancy. Trying to go it alone on the
- 168 -
community edition would require IT expertise, therefore this option is not advised to
SMEs without IT staff.
Figure 94. The Pentaho BI Enterprise Console
____________________________________________________________________
Figure 95. Configuring data sources in the Pentaho BI Enterprise console
____________________________________________________________________
- 169 -
9.4 Show Case 3: Amazon Elastic Compute Cloud (EC2)
Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides
resizable compute capacity in the cloud. Amazon EC2’s web service interface allows
users to obtain and configure capacity. Amazon EC2 claims to reduce the time
required to obtain and boot new server instances to minutes. With Amazon EC2 you
pay for the capacity you use. Amazon EC2 presents a virtual computing environment,
allowing organizations to use web service interfaces to launch instances with a variety
of operating systems, load them with a custom application environment, manage
network access permissions and run the image using as many or few systems as is
required. The following is a shortlist of steps required to use the Amazon EC2
environment (Amazon Web Services [1], 2009):
• Create an Amazon Machine Image (AMI) containing the required
applications, libraries, data and associated configuration settings. There is an
option to use pre-configured, template images also.
• Upload the AMI into Amazon S3 (See S3 features below).
• Use Amazon EC2 web service to configure security and network access.
• Choose the instance type(s) and operating system, then start, terminate, and
monitor as many instances of the AMI as needed, using the web service
APIs or a variety of provided management tools.
• Determine whether to run in multiple locations, utilize static IP endpoints,
or attach persistent block storage to instances.
- 170 -
• Pay only for the resources used such as instance-hours or data transfer.
Amazon Simple Storage System (S3) is storage for the Internet. Amazon Web
Services [1] (2009) describe the features of S3 as follows:
• Write, read, and delete objects containing from 1 byte to 5 gigabytes of data
each. The permitted number of objects one can store is unlimited.
• Each object is stored in a bucket and retrieved via a unique, developer-
assigned key.
• A bucket can be located in the United States or in Europe. All objects
within the bucket will be stored in the bucket’s location, but the objects can
be accessed from anywhere.
• Authentication mechanisms are provided to ensure data security. Objects
can be made private or public, and rights can be granted to specific users.
• Uses standards-based REST and SOAP interfaces designed to work with
any Internet-development toolkit.
• Protocol or functional layers can be added. The default download protocol
is HTTP. A BitTorrent protocol interface is provided to lower costs for
high-scale distribution. Additional interfaces will be added in the future.
• Amazon also offers a Service Level Agreement (SLA) which offers a
99.95% uptime.
Customers of Amazon EC2 may choose between S3 as described above or
Simple DB which takes data as input and expands it to create indices across multiple
- 171 -
dimensions. S3 is better for large objects or files, while smaller data elements or file
pointers (possibly to Amazon S3 objects) are best saved in Amazon SimpleDB
A host of companion products are also offered. Some of the priced options are listed
here:
1. Amazon CloudWatch is a web service that provides monitoring for AWS
cloud resources.
2. Elastic Load Balancing automatically distributes incoming application traffic
across multiple Amazon EC2 instances.
3. Elastic IP addresses allow you to mask instance or availability zone failures
by programmatically remapping your public IP addresses to any instance in
your account.
Figure 96 displays a selection of the operating systems instances which are
currently available and Figure 97 lists other software available to run on an EC2
instance including databases and web servers
Figure 96. Operating systems available on Amazon EC2
_____________________________________________________________________
- 172 -
Figure 97. Sample of software available on Amazon EC2
_____________________________________________________________________
9.4.1 Amazon EC2 Costs
Amazon Web Services [1] (2009) claim to pass on the economies of scale in
relation to the use of shared computing resources making it an inexpensive
alternative. On-demand instances permit scalability by allowing instant extensions
catering for spikes in demand. Costs as at July 2009 are shown in Appendix R
9.4.2 Who is using it?
Although the Internet has been around for some time Cloud Computing is a
relatively new concept which is particularly suited to industries that have large
fluctuations in demand for computing power. Such companies can spread the load and
pay only as needed as opposed to investing in hardware up front which may be under
utilized for a large proportion of the time. It is however worth considering. Many new
service companies are emerging to facilitate the transition from traditional to cloud
environments which should ease the path for SME’s who may benefit from the
economies of scale offered by Cloud computing. Cloud computing solutions are also
available from Microsoft (Azure) and Google among others. Software companies are
following suit declaring their applications cloud ready. IBM has agreed that customers
- 173 -
can use their own licenses on Amazon EC2 which means customers can run their own
software on an EC2 instance. IBM has agreed a PVU mapping to EC2 instance type
which controls and protects their processor based pricing structure. Apart from IBM,
Amazon have partnered with Cap Gemini, Open Solaris, Oracle, Red Hat and Sun
Microsystem’s MySql. An article by Torode (2009) lists Pentaho, Open BI and
Compiere among companies offering Cloud Based and Saas BI solutions. Information
Builders are currently trialling their BI offering on EC2, which they claim is targeted
at midsized organizations and/or those with emerging BI programs indicating it makes
sense in terms of cost savings for smaller shops and those with few IT resources.
Concerns with using Cloud based solutions surround data integration issues, security
(risk management and governance), latency and responsibility should a service-level
agreement (SLA) not deliver.
9.4.3 Configuration of EC2 for use
To use EC2 for any business critical data it is necessary to employ at least:
• an EC2 instance
• the Amazon Elastic Block Store (EBS)
• S3 storage
Figure 98. Amazon EC2 configuration for persistence
____________________________________________________________________
Source: Amazon Web Services [2], 2009
- 174 -
Figure 98 provides a graphical image of the integration of the three elements.
EC2 instances are not persistent. It is easy to set up for example a Windows 2003
Server instance, configure it for network access and launch it. You can then change
the configuration parameters and install software as you would with any Windows
Server, but should the instance fail or stop by request, all the changes made will be
lost. EC2 could be used like this for trialling software, training users on operating
systems etc. but on its own, it would not suffice for running an ERP system or a BI
application. To maintain the configuration changes made to the Windows 2003
Server environment it is possible to run a utility which allows you to Bundle an AMI
(Amazon Machine Image) by storing it in S3. This means when an instance fails or is
stopped it would be possible to load a new instance and use the bundled image to
restore your instance configuration but still there is no data persistence associated
with this. To gain data persistence you must use the Amazon EBS. EBS volumes
behave like raw unformatted external block devices. You can load a file system on top
of Amazon EBS volumes, or use them just as you would use a block device. To use
Amazon EBS, you first create a volume that can be attached to any Amazon EC2
instance within the same Availability Zone. Snapshot utilities then allow you to take
backups of your EBS volume to ensure recovery should the volume fail. These
backups are stored in S3 in the same way the Bundled AMIs are stored for recovery.
Once you have an EBS volume you can attach it to any EC2 instance. You can also
then use the snapshots (backups) of the EBS volume stored on S3 to configure other
- 175 -
EBS volumes and launch each with an EC2 instance as in Figure 99.
Figure 99. Amazon Elastic Block Store (EBS) multiple instance diagram
____________________________________________________________________
Source: Amazon Web Services [2], 2009
The BI software used in the case study company could not be loaded to EC2 in
its entirety or its present form (due to platform licensing restrictions), but elements of
it could. EC2 does not have an OS400 operating system environment (they do have
DB2 on Linux) which is the primary reason. The MRC m-power software is
distributed over the AS400 iSeries and a Windows 2003 server using Tomcat as a web
application server. Java class files, html and xml files are stored on the Windows 2003
server after an application is built and can be run independently of the AS400 iSeries
environment. The only issue is accessing the data in the data mart which resides on
the AS400. Using the scenario above it would be possible to register for the three
services outlined above (EC2, EBS and S3). The Windows 2003 AMI could be
selected and configured using AWS Console. Install and configure a Tomcat instance
(also available on EC2) on the newly configured server instance. The data mart could
- 176 -
be stored on an EBS volume and backed up nightly to S3 along with a bundled AMI
of the Windows 2003 server containing the tomcat configuration data, active directory
enrolments and other server configurations. If the data mart were created using SQL
and stored on a Windows file system on the EBS (this would require a different
platform licence from MRC and negate the need to have the AS400 iSeries licence)
you could then locate the data mart on the EBS volume. The ETL would then query
the AS400 iSeries and load to the data mart now resident on the EBS volume via
access configured through the EC2 instance. It is possible but is it feasible? To answer
this would require knowledge on data volumes and usage patterns. This is an area
recommended for further study. Table F however shows the costs associated with
running a single small instance on EC2 only as an example. From the table you can
deduce the annual cost to run a small instance (see Appendix R for specification)
running Windows 2003 server for would be $1182. To run a Linux/Unix instance you
could opt for a reserved instance and pay a fixed fee of $227.50 plus an annual usage
of $350.40 amounting to $577.90 per annum. These values assume the instance is
running 24/7 for 365 days per year.
Table F
Cost to Use a Small Standard Instance on Amazon EC2

_______________________________________________
Measure Standard Reserved
and variable Instance Instance
(Linux/Unix only)
______________________________________________
Per hour $0.135 $0.03
Per day $3.24 $0.96
Per week $22.68 $6.72
Annually $1182.60 $350.40
Fixed Annual Fee $227.50
________________________________________________
- 177 -
Table G details the cost to add storage and persistence to the instance. This
requires the use of EBS volumes and S3 to create snapshots or backups. An example
costing is for every 10GB stored on an EBS volume which is backed up to S3 the
monthly cost would be $2.90. Additional costs include the cost of data transfer in and
out of Amazon EC2 (see Table G) plus any optional services and instances required.
Table G
Storage and persistence costs to use Amazon EBS and S3
_________________________________________________________________________
Measure and Per GB Per GB/ Per 1 million Per 1000 put Per 10,000
Variable Month I/O requests requests get requests
_________________________________________________________________________
Data
Transfer in $0.10
First 10 TB $0.17
Data out
_________________________________________________________________________
EBS volume $0.11
EBS volume $0.11
_________________________________________________________________________
S3 $0.18
S3 $0.012 $0.012
S3
_________________________________________________________________________
There are some very good configuration documents to get started with EC2 at
Amazon Web Services [2], 2009. The next section will consider general advantages
and disadvantages of Cloud Computing.
9.4.3 Is Cloud Computing Feasible for SMEs?
In February 2009 Pentaho announced that Nutricia North America (a division
of the Danone Gorup) had deployed a cloud version of Pentaho BI on EC2. The
- 178 -
organization wanted a way to deliver common metrics through a web-based interface
and to automate manual data collection and integration tasks without the unnecessary
expense of traditional proprietary software licenses or the overhead of deploying the
physical hardware infrastructure typically required. They deployed the Pentaho BI
Suite to provide dashboard, data integration, and analysis capabilities. The solution
featured standardized web-based metrics and interactive OLAP analysis to allow
business users to analyze key information at any level of detail. The solution
comprised of a data mart and dashboard solution which was deployed in under six
weeks. Nutricia integrated its on-site Sage MAS90, Microsoft SQL Server data with
the cloud-based implementation of Pentaho and the MySQL database on Amazon
EC2. It is certainly possible to use Cloud Computing for ERP and BI. It is early days
for the technology and costs should reduce as the technology and market mature.
9.4.3.1 Advantages of Cloud Computing
1. Server capacity can grow and shrink on demand.
2. Cloud computing can be used to perform proof of concept with new
projects without the need to invest in hardware, software and licensing
costs by using an existing machine image for the environment you wish to
test for example Windows Server, DB2 (Linux), Unix etc.
3. Using a cloud based solution negates the need to purchase hardware,
software licences and annual hardware and software maintenance support
contracts for company owned assets.
4. Eliminate worries regarding aging hardware and asset replacement
5. Operating system software upgrades are assured within a reasonable time
frame.
6. Avoid the costs associated with environmental controls in server rooms
- 179 -
7. Reduction in bandwidth and communication service requirements to local
servers if multiple sites require access. Traffic is redirected to the Web.
8. Offsite data storage in a protected environment for contingency – perhaps
some benefits here to having ERP on-site and the data mart offsite.
9.4.3.2 Disadvantages and Concerns over Cloud Computing
1. Many companies are concerned about data security
2. Service Level Agreements (SLAs) – who is responsible if/when they don’t
deliver
3. More complex integration with the rest of the organizations data
4. Concerns exist over contention on the network and servers
5. Loss of control
The same remedies apply to Cloud Computing as was detailed for SaaS in
section 9.2. The use of any of the technology delivery platforms outlined here would
need to be considered based on individual project requirements. There is no magic
bullet. The objective as stated in the introduction was to heighten awareness of the
alternatives emerging to provide options for consideration to SMEs embarking on an
ERP or BI project.
9.5 Conclusions
Open source, SaaS and Cloud Computing offer alternative platforms to
organizations for both ERP and BI. These offerings may be cheaper than running in-
house systems with proprietary licensing. There are many variables to consider
including usage patterns, SLAs, data security policies, licensing costs, internal IT
infrastructure and communications, users, the suitability and availability of operating
systems and applications and the criticality and nature of the application. Each project
should be judged on this basis measuring the alternatives available. Alternative
- 180 -
platforms may suit some SMEs and not others. They are worth considering with a
view to benchmarking each of the alternatives against the individual project and
organizations requirements.
- 181 -
Chapter 10 - Guide to BI Selection and Integration for SMEs
10.1 Introduction
A grounded theory approach was applied to the material uncovered in the
primary and secondary research activities of this study to uncover a theoretical
framework for BI selection and integration. All the work in this paper essentially
culminates in the models presented here. They are early models and further research is
required to refine the content. This section will present a theoretical model for
integration of BI in SMEs and suggest a BI selection Framework in the form of the
Business Intelligence Vendor and Application Assessment (Request for Information)
document (see Appendix S), and The Business Intelligence Vendor and Application
Assessment (Proof of Concept) document (see Appendix T).
10.2 The BI Integration Framework
BI maturity provides the context for the models presented here. Deng (2007)
stated data leads to information, information leads to knowledge and knowledge leads
to wisdom as depicted in Figure 100..
B
Wisdom
I
Knowledge
M
a
Information t
u
Data r
i
t
y
Figure 100. Data refinement hierarchy within a BI maturity context
_____________________________________________________________________
- 182 -
The study revealed the existence of inhibitors and facilitators of BI projects
which impact on an organizations ability to attain BI maturity. Table F lists the BI
inhibitors and Table G lists the BI facilitators found in this study.
Table F
BI Inhibitors
_________________________________________________________________
Phenomena
_________________________________________________________________
Poor planning
Lack of resources (people, time, money, equipment)
Organization immaturity
Complexity (of data structures, sources, locations)
Heterogeneous data sources
Lack of skills and competencies
Lack of knowledge
Slow data retrieval - poor design
Spread-marts (Eckerson [1], (2007))
Data duplication
Data inconsistencies
Data fragmentation - no central repository
Implementation costs
Licensing costs
Ad-hoc reporting by casual users
Missing information
Unmatched granularity in datasets, (actuals weekly, budgets monthly)
Data re-keying (ERP to spreadsheet, paper report to spreadsheet)
Disparate systems
Poor business processes
Lack of strategy process in the organization
_________________________________________________________________
- 183 -
Table G
BI Facilitators
_________________________________________________________________
Phenomena
_________________________________________________________________
Differentiated user levels (Information Producers and Consumers)
Data modeling tools
Templates for quick start and reuse
Ease of Use
Speed of access to data
Data integrity
Business process analysis
Prototypes and POCs to show what can be done
Hardware, software and communications capability
Secure systems
Correctly sizing the infrastructure
Critical success factors (include when planning project)
Awareness of choices available
Libraries for casual users
Traceability/audit features
Re-engineer poor processes
Limit customisations to designs
Documented metrics
Documented processes
Data aggregation to suit decision making level (Strategic, Tactical, Operational)
Self service for all users
Ad-Hoc by Power-Users
Usage statistics on BI application to enable refinement
Visualization techniques - Dashboards better than low level detail
Business process modeling tools
Centralised information stores
Timeliness of information
Data captured at source
Job redesign - remove old ways
Master Data Management (MDM)
Embedded devices in use
Business process automation
Operational BI embedded in solution
Information in Context - Real time
Predictive analysis through data mining
_______________________________________________________________
Figure 101 presents a graphical representation of the relationships between BI
inhibitors and facilitators as they pertain to BI maturity and organizational readiness
for BI. In order to progress towards BI maturity it is necessary to reduce the BI
inhibitors (the obstacles) and increase the BI facilitators. Progressing BI maturity also
- 184 -
requires as indicated an assessment of the readiness of an organisation in terms of its
people, processes, and infrastructure at each stage.
BI Maturity Enablers
READINESS
Figure 101. Roadmap to BI Maturity
____________________________________________________________________
The lists of inhibitors and facilitators are not exhaustive but it does provide a
starting point for further research in this area. BI Maturity enablers (see Figure 102)
are seen as the helpers to shift the weight in the model from left to right thus helping
to reduce the inhibitors and increase the facilitators. The absence of a BI facilitator
will act as an inhibitor while reversal of a BI inhibitor will act as a facilitator.
Essentially what this means is if for example the presence of data inconsistencies is
seen as an inhibitor, the subsequent resolution of these inconsistencies to clean data
would be deemed a facilitator. On the other hand, if speed of access to data is seen as
a facilitator, the absence of this (slow data access) would be seen as an inhibitor.
Figure 102. presents the BI maturity enablers.
- 185 -
Figure 102. BI maturity enablers
____________________________________________________________________
The BI Maturity Enablers model in Figure 102 emerged from recurring themes
found in the literature and the case study. A synopsis of the factors to consider for
each of the elements (D-Design, B-BI Tools, M-MIS Capability and S-Strategy
Process) follows a brief discussion on project management which extends through all
activities on the model.
Project Management
Sound Project Management principles surround all other enablers throughout
the lifecycle of the BI Project and beyond. The following items emerged in relation to
BI implementation from this research.
• Employ a good project management methodology
• Assess culture and readiness for change
• Build a business case to support the project
- 186 -
• Agree scope
• Prepare a plan and stick to it
• Use a BI maturity Model to help plan steps at each stage
• Define success factors - define stakeholders perception of success
• Ensure a good balanced BI project team
o Use Hybrids
o Use project manager with sufficient autonomy
o Empowered decision makers
o Executive championship
o Use consultants (where in-house expertise is not available)
o Staff up
• Define the implementation strategy - what will be included, why, when and
how?
• Expect problems to arise
• Prepare a risk mitigation plan
• Plan for a requirement for reduced latency as you progress through the
maturity cycle - users will expect more information and faster when they start
to see the benefits
• Keep implementation times short
• Ensure adequate resources
• Select the 20% which gives 80% of the information
• Train all Staff
• Include support for job changes
• Communicate continuously
• Road test pre-install - perform a proof of concept
- 187 -
• Bed down post implementation - ensure strict change management and BI
governance via the BI implementation team.
• Include post implementation evaluation
Design Choices (D)
Design choices relates to the decisions taken about the BI implementation.
This includes as in the case study for Company A, a strong suggestion for SMEs to
use subject oriented data marts and avoid OLTP structures when integrating BI tools
for analysis and reporting. Choices must also be made with regard to delivery
platforms, licensing methods, integration and data conversion strategies. Organization
size and culture will influence the choices made. For SMEs it is important to invest in
the design to ensure simplicity and ease of use and maintenance going forward. This
paper has previously outlined good design principles for integrating a data mart with
an ERP system in an SME (see Chapter 2).
BI Tools (B)
Decisions on the BI tools to use will effect how far an SME will progress
along the BI maturity continuum. In early BI projects query, reporting and analysis is
mostly evident. Progression sees the introduction of dashboards, scorecards and alert
based KPI reporting. Maturity see complete end to end business process integration
driving the business. The TDWIs BI Maturity Model (Figure 49, Chapter 6 provides a
good reference for the tools at each stage of maturity. The organization needs to move
from a data focus to a process focus and implement the tools to enable this. SMEs will
be constrained but this does not prohibit progression of prioritised projects relevant to
the organization.
- 188 -
MIS Capability (M)
Advanced MIS is essential to create a favorable context for implementing and
using performance management systems. An assessment of MIS capability should be
undertaken as part of any BI project. This assessment should cover capability in
relation to hardware, software, communications and general infrastructure, along with
resource availability and skills assessment of local staff. This assessment will provide
critical information about the organizations readiness from a technical viewpoint to
progress a BI project.
Strategy Process (S)
The idea of an organization’s readiness for BI in terms of strategy process
capability was covered in Chapter 5 of the study. SMEs have demonstrated strategic
planning capabilities however they were lacking strategy implementation capabilities.
BPM and business process integration can be used to facilitate the execution
of strategy by incorporating business goals into operational processes providing
necessary information to monitor business performance based on predefined metrics.
Chapter 5 and Chapter 8 of this study provide guidelines on BPM and business
process integration. BI can play a part in strategy implementation through analysis,
presentation and ultimately automation. Figure 103 shows MIS at the centre of
strategy implementation. Advanced BI tools will help SMEs progress strategy process
implementation.
- 189 -
Redefine Strategy
MIS Capability
BI Tools
Compare Business Performance Metrics
Management
Business Process
Integration
Measure Targets
Figure 103. Strategy process and MIS synergy wheel
_____________________________________________________________________
10.3 The BI Selection Framework
This section presents some tools to help organizations select BI applications.
Odesia (Mendelsohn, 2006) suggest the following eight step methodology when
selecting a BI application:
1. Establish BI selection committee
2. Meet with business users
3. Define criteria for scoring
4. Establish list of BI vendors
5. Prepare RFI questions
6. Evaluate and grade
7. Establish BI demo validation session
- 190 -
8. Selection of BI vendor
Appendix S contains the BI Vendor and Application Assessment (BIVAA) –
(Request for Information) document which was assembled as part of this research
paper to help organizations in the initial BI application selection stages. The BI VAA
can be used by any company embarking on the search for a BI solution or as a means
of benchmarking their current solution against other available solutions. It provides a
good starting point for the Request for Information (RFI) questions. An organization
would rank the features outlined in Part II of the BIVAA in Appendix S by using the
Client Requirements Grid detailed in Table H in advance of inviting perspective
vendors to complete the BIVAA (the client requirements ranking in Table H would
not be supplied to vendor to avoid prejudice in answering of course).
- 191 -
Table H
Business Intelligence Vendor and Application Assessment Client Requirements
Ranking
_____________________________________________________________________
C L I E N T
_____________________________________________________________________
Not Minor Moderate Critical Future
Required Requirement Requirement Requirement Requirement
Weighting 0 1 2 3 1
___________________________________________________________________________________
Feature 1 X
Feature 2 X
Feature 3 X
Feature N X
___________________________________________________________________________________
Total Points 0 0 4 3 0
(Column Weighting X Count of Entries in Column)
Total Grade Points for Application 7
Note. An X in a column indicates the requirement is as indicated by the column heading for the feature
indicated in the row. The grading points awarded for the feature will be as indicated in the weighting
row for the selected column. The points for each feature will be the weighting value for the selected
column multiplied by 1 since each feature can only be scored in one column. The total points for a
column will be (column weighting value multiplied by count of column entries). The total grade points
accumulated for the application being assessed will be the sum of the column totals.
The BIVAA responses received from BI solution providers can then be easily
aligned on criticality of feature and other grading criteria relating to vendor and
- 192 -
product stability as outlined in Part I of the BIVAA in Appendix S. The BIVAA was
designed based on a content analysis review of literature pertaining to BI features
coupled with the present authors experience of application selection. The primary
sources used are noted in Appendix S. It is important to select a BI application to suit
the end users as opposed to one suiting highly technical users.
Appendix T contains the BIVAA Proof of Concept document to also help
organizations in the initial BI application selection stages. The BI VAA can be used
by any company embarking on the search for a BI solution or as a means of
benchmarking their current solution against other available solutions.
Conclusions
The models presented in this section are early models. They will require
refinement and further analysis to explore the relationship and affect each has on the
success or failure of BI projects. They do however provide a starting point in
identifying factors influencing BI success and maturity attainment.
- 193 -
Chapter 11 – Concluding Remarks
This final chapter presents findings from the study.
11.1 The Hypotheses
Has the study answered the research questions originally posed? The first
hypotheses stated that the primary purpose of BI applications is to facilitate
attainment of an organizations overall strategy or mission through provision of
visibility to KPIs which have been derived from an organizations strategic goals.
There is strong support for this in the literature. Finney & Corbett (2007) identified
visioning and planning as a CSF involving identifying clear measurable
organizational goals and objectives and linking business and IS strategies. Golfarelli
et al. (2004) believe organizations have understood the importance of enforcing
achievement of the goals defined by their strategy through metrics-driven
management; Jointly 93% of respondents in the survey conducted as part of this study
indicated that KPI’s in use were linked to business goals. Tibco (2006) indicated by
organizing processes around goals, that is “what is to be achieved” rather than “what
is to be done,” goal-oriented BPM helps organizations achieve needed flexibility and
Neely (2006) declared “measures should link operations to strategic goals.”
Companies also cited better information for decision makers as the primary driver for
BI use (67%) in the survey. There is a clear consensus of the need to link strategy
with business process and monitor activity through KPIs to achieve better operational
and strategic planning. This is the essence of BI.
The second hypothesis proposed that lack of knowledge of BI tools and their
- 194 -
in SMEs. Glick (2006) backs this hypothesis in a survey of 4347 IT Managers and
839 Finance Managers indicating SMEs cannot rely on vendors to promote emerging
technologies to smaller customers. In the BI awareness section of the survey
conducted as part of this research, respondents listed BI tools in use in their own
organizations, but none of the respondents listed other BI applications they were
aware of when questioned.
McKendrick (2008), cites complexity of BI tools, lack of BI skill sets within
the organization and lack of management buy in as the factors most inhibiting BI
implementation projects. Gartner (2006) cautioned that limited BI skills and
competencies continue to hamper adoption. Lack of in-house expertise was second to
cost in the survey as a primary inhibitor to BI adoption.
The third hypothesis states that SMEs aware of BI solutions do not pursue
such implementations due to perceived cost and lack of resources. According to
Gartner (2006) perceived high total cost of ownership (TCO) and difficulty in
quantifying the direct business benefits of better performance and improved decision
making continue to hinder adoption of BI among SMEs. McKendrick (2008) cites
software license costs as the main BI inhibitor, and that which is driving organizations
to look at alternative approaches. Scheer at al. (2000) identified that major ERP
vendors such as SAP, Baan and Peoplesoft estimate that customers spend between
three and seven times more on implementation costs than the cost of the software
license. Cost was recorded as the primary inhibitor to BI use (43%) in the survey
conducted.
The fourth hypothesis is a small amount of the overall data held by
organizations is used for strategic and operational planning. Efforts should therefore
- 195 -
concentrate on preparing this subsection of data for analysis in resource constrained
projects. Saha (2007) says to work with data which is relevant to attaining the
objectives set out in the planning phase indicating there will be much data, a lot of
which is irrelevant to producing the required reports and performance metrics. He
suggests concentrating effort on the necessary data as “winnowing through
voluminous amounts of irrelevant data and poor data quality,” is a typical BI
implementation issue. Support for the fourth hypothesis was also found in the case
study in Chapter 7. There was no loss of information as a result of aggregation to
dimensional hierarchy levels to produce identified KPIs for Company A. Real time
data produces a lot of low level detail which often only makes sense when aggregated
or used for exception reporting.
The fifth hypothesis proposed that there is an affordable BI solution for SMEs
which can be used successfully post installation by properly trained end users to attain
minimal support. The study found this hypothesis to be true based on the outputs from
the case study in Chapter 7 and the analysis of alternative delivery platforms in
Chapter 9. Chapter 9 highlighted costs and success stories in relation to Cloud, SaaS
and Open Source offerings. The outcome of the case study was a successful
implementation and development of a suite of reports which were segregated
according to user self service levels based on the user role as being either information
consumer or producer. The work involved no programming for most reports other
than the more complex dashboards. ETL utilities were demonstrated to show
suitability for non IT users. Data mart fact and dimension tables were loaded using
tools any power user could be trained in quite easily. It is however felt that sound
design and the ability to think globally but act locally are important when creating the
- 196 -
data marts. They may have to be integrated into higher structures. Good design
principles will help avoid issues with metadata management at a later stage. Data mart
design and maintenance procedures should be left to business analyst and IT resources
where they exist, or experts in the field where no in-house resources are available.
The tools showcased, in particular MRC’s m-Power and the Pentaho BI Suite is, in
the author’s opinion, within the reach of SME’s in the manufacturing sector from both
usability and a cost perspective. SaaS and Cloud computing may suit but they would
need to be evaluated for each individual project based on usage patterns, SLA content,
data security policies, licensing costs, internal IT infrastructure and communications,
users, the suitability and availability of operating systems and applications and the
criticality and nature of the application.
11.2 Evaluation of Contribution
This study has attempted to look at integrating BI with ERP from an SMEs
perspective. Among the contributions made is the work in Chapter 7 strongly
advocating the data mart approach over integration with OLTP structures due to
contention and performance issues? A framework for integrating BI with ERP has
been proposed in Chapter 10 encompassing an integration strategy and a BI selection
strategy. Inhibitors to BI success have been identified as well as facilitators. Good
design principles and critical success factors have been highlighted for both ERP and
BI projects.
11.3 Further Research
The study covered the very broad area which is BI. Suggestions for further
study include enhancement of the BI integration framework in Chapter 10 to analyse
- 197 -
the effects and relationships between each of the facilitators and inhibitors
documented and how they each in their own right contribute to or hinder
implementation. A number of methods for extracting and loading data were used in
the case study Company A. In order to make BI pervasive among SMEs tools need to
be built into the applications to make it easier for smaller organizations with few IT
resources to perform the tasks otherwise completed by Business Analyst type roles or
the IT function. The use of WS-BPEL and tools facilitating its use as a means to
integrate end to end processes is quite a complicated methodology requiring expert
knowledge. Further research is suggested to design generic BPEL templates for
common workflows in business that could be easily modified to work with any
environment. Web enabling the assessment grid would be useful in bringing this
selection tool to a wider audience.
In summary this has been an incredible journey and learning experience.
- 198 -
References
Alchemex (2009, January 05).Best practice report writing methodology for sound
business intelligence for SMEs. Retrieved January 6, 2009, from
http://www.accountingweb.co.uk/cgi-
bin/item.cgi?id=193003&d=1043&h=1044&f=1026&dateformat=%25o%20%2
5B%20%25Y
Amazon Web Services [1] (2009). Amazon Elastic Compute Cloud (EC2). Retrieved
July 14, 2009 from http://aws.amazon.com/ec2/#functionality
Amazon Web Services [2] (2009). Failure resilient application concepts: Amazon
Elastic Block Store. Retrieved August 26, 2009 from
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?cre
ating-an-ami-windows.html
Ates, A., Bititci, U., MacBryde, J., & Van der Meer, R. (2007). An end-to-end process
view of strategy management: A research framework. In Proceedings of the
27th International Annual Strategic Management Society Conference, San
Diego, USA, (August 2007).
Barker, C. (2007). SME director: Business Intelligence heading for the mid market?
Retrieved February 1, 2009, from
http://management.silicon.com/smedirector/0,39024679,39165653,00.htm
Bourne, M., Neely, A., Mills, J. & Platts, K. (2003). Implementing performance
measurement systems: A literature review. International Journal of Business
Performance Management, Vol. 5, No. 1, 1-24. Retrieved June 11, 2009 from
http://student.brighton.ac.uk/mod_docs/bbs/miscellaneous/lit_review/literature_r
eview%207.pdf
- 199 -
Britton, C. & Bye, P. (2007). Implementing Business Process. In IT architectures and
middleware: Strategies for building large integrated systems (Second Edition),
(pp. 39-57). USA:Addison-Wesley
Brown, W. (2004). Enterprise resource planning (ERP) implementation planning and
structure: a recipe for ERP success. In Proceedings of the 32nd Annual ACM
SIGUCCS Conference on User Services (Baltimore, MD, USA, October 10 - 13,
2004) (pp. 82-86). New York, NY: ACM. Retrieved February 1, 2009, from
http://doi.acm.org/10.1145/1027802.1027824
Business Driven Data (n.d.). Business intelligence optimize. Retrieved July 29, 2009,
from http://www.businessdrivendata.com/about/
Business Intelligence (2006). In BUSINESS: The Ultimate Resource - Dictionary of
Business and Management. London: A&C Black. Retrieved February 9, 2009,
from http://www.credoreference.com.dml.regis.edu/entry/6015203/.
Business Intelligence (2007). In Dictionary of Accounting. London: A&C Black.
Retrieved February 9, 2009, from
http://www.credoreference.com.dml.regis.edu/entry/7823737/
Connolly T., & Begg C. (2005). Data warehousing concepts. In A. D. McGettrick
(Ed.), Database Systems:A practical approach to design, implementation, and
management, 4th Edition (pp. 1149-1180). U.S.A.: Addison-Wesley.
Cosh, A., Bullock, A., Hughes, A., & Milner, I. (2005). CBR SME Benchmarking
Survey for Northern Ireland. Retrieved February 10, 2009, from
http://www.cbr.cam.ac.uk/pdf/Sme%20benchmarking%20Northern%20Ireland.
pdf
- 200 -
Cousins, J., & Stewart, T. (2002). What is business process design and why should I
care? Retrieved August 25, 2008 from
http://www.rivcom.com/resources/RivCom-WhatIsBPD-WhyShouldICare.pdf
Cunningham, C., & Song, I. (2007). A taxonomy of customer relationship
management analyses for data warehousing. In J. Grundy, S. Hartmann, A. H.
Laender, L. Maciaszek, and J. F. Roddick, (Eds.), Tutorials, Posters, Panels and
industrial Contributions at the 26th International Conference on Conceptual
Modeling, (Auckland, New Zealand, November 01 - 01, 2007), ACM
International Conference Proceeding Series, Vol. 334, 97 -102. Darlinghurst,
Australia:ACM.
Deng, R. (2007). Business intelligence maturity hierarchy. In BI Review Online,
March 5, 2007. Retrieved July 26, 2009 from http://www.information-
management.com/bnews/2600315-1.html
Dick, B. (2005). Grounded theory: a thumbnail sketch. In Research Papers in Action
Research. Retrieved Feb, 2009, from
http://www.scu.edu.au/schools/gcm/ar/arp/grounded.html
Dubray, J.J. (2002). BPEL Metamodel. Retrieved June 20, 2009 from
http://www.ebpml.org/bpel4ws.htm
Eckerson [1], W.W. (2007). Beyond the basics: Acceleration BI maturity. Retrieved
August 05, 2009, from
http://download.101com.com/pub/tdwi/Files/SAP_monograph_0407.pdf
Eckerson [2], W.W. (2007). The myth of self-service BI. In What Works, Vol 24,
2007. Retrieved May 01, 2009, from
http://www.tdwi.org/Publications/WhatWorks/display.aspx?id=8638
- 201 -
Finney, S., & Corbett, M. (2007). ERP implementation: a compilation and analysis of
critical success factors. In Business Process Management Journal, Vol. 13, 3,
329-347. Bingley, UK: Emerald Group Publishing.
Fishteyn, D. (n.d.). Deploying Software as a Service (SaaS). Retrieved August 25,
2009 from http://www.saas.com/homepage/pdf/SaaS.com_Whitepaper_PartI.pdf
Garengo, P., Nudurupati, S. & Bititci, U. (2007). Understanding the relationship
between PMS and MIS in SMEs: An organizational life cycle perspective.
Computers in Industry, Vol 58, 7, 677-686. Retrieved June 13, 2009, from
http://www.sciencedirect.com/science/article/B6V2D-4NYBM86-
1/2/ef73f67abbb1874ff965f01565cdb29d
Gartner (2006). Gartner says business intelligence software market to reach $3 billion
in 2009. Retrieved Jan 23, 2009, from
http://www.gartner.com/it/page.jsp?id=492239
Gile, K., & Teubner. C. (2006). Business Intelligence meets BPM in the information
workplace. Cambridge: Forrester Research Inc. Retrieved on February 21, 2009,
from
http://www.forrester.com/Research/Document/Excerpt/0,7211,39681,00.html
Glick, B (2006). Shared headaches. Retrieved Jan 12, 2009, from
htp://www.computing.co.uk/computing/analysis/2152536/shared- headaches
Golfarelli. M., Rizzi, S., & Cella, I. (2004). Beyond Data Warehousing: What’s next
Retrieved August 08, 2009, from
http://www.aberdeen.com/launch/report/benchmark/5873-RA-pervasive-
business-intelligence.asp
Howson, C. (2009). Four business intelligence resolutions for 2009. Retrieved
February 15, 2009, from
- 202 -
http://www.intelligententerprise.com/channels/business_intelligence/showArticl
e.jhtml;jsessionid=14AJALB5ELRDYQSNDLOSKHSCJUNN2JVN?articleID=
212902506&pgno=2
Hughes, I. (2001). Strategic planning. Retrieved February 14, 2009, from
http://www2.fhs.usyd.edu.au/arow/o/m05/stratplanning1.htm
IBM (2008). IBM and The Systems House enable a start-up to gain firm footing.
Retrieved August 25, 2008 from http://www-
304.ibm.com/jct01005c/isv/marketing/saas/systemshouse_success.pdf
IBM Cognos (n.d.). IBM Cognos 8 Business Intelligence Scorecarding. Retrieved Feb
01, 2009 from
http://www.cognos.com/products/cognos8businessintelligence/images/
lg_scorecarding1.jpg
IBM Corporation (2006). Information lifecycle management. Retrieved July 26, 2009,
from 20webinar%20charts%20a%20final.ppt#322,1,Information Lifecycle
Management
http://mediazone.brighttalk.com/comm/sitedata/f2217062e9a397a1dca429e7d70
bc6ca/download/977_Evan's%
Kanaracus, C. (2008). IDC: Oracle maintains lead in database market. Retrieved
August 05, 2009, from
http://www.pcworld.com/businesscenter/article/147684/idc_oracle_maintains_le
ad_in_database_market.html
Key Performance Indicator, (2003). In Webster's New World Finance and Investment
Dictionary. Hoboken, NJ: Wiley. Retrieved October 28, 2008, from
http://www.credoreference.com.dml.regis.edu/entry/5864626/.
- 203 -
Leedy, P.D. & Ormrod, J.E. (2005). Qualitative research methodologies: Qualitative
research. In Mary Harlan (Ed.) Practical Research: planning and design (8th
ed.)(pp.133-160). Upper Saddle River: Pearson Prentice Hall
Lock, M (2009). BI for the SMB 2009: How to slash cost and empower the business
user. Retrieved August 15, 2009, from
http://www.aberdeen.com/launch/report/benchmark/6051-RA-business-
intelligence-cost-ownership.asp
Mahmoud, Q.H. (2005). Service-Oriented Architecture (SOA) and Web services: The
Road to Enterprise Application Integration (EAI). Retrieved February 11, 2009
from http://java.sun.com/developer/technicalArticles/WebServices/soa/
Marković, N. (2007). Performance measurement and management- review of theory
and practice. In International Journal Special Edition, Vol. 35, 3.
McKendrick, J. (2008). Open source business intelligence: A 2008 progress report.
Retrieved Feb, 01, 2009, from
http://www.pentaho.com/products/demos/showNtell.php?tab=papers
Mendelsohn, C. (2006). BI tool selection and standardization. Retrieved August 05,
2009, from http://www.salonbi.com/pdf/Corey_Mendelsohn_ODESIA.pdf
Microstrategy (n.d.). Interactive dashboard demos. Retrieved February 01, 2009 from
http://www.microstrategy.com/DashboardGallery/Dashboards/RevenuePerform
anceManagementDashboard.htm
MRC (n.d.). See what you can build with m-Power. Retrieved February 19, 2009,
from
http://www.mrc-productivity.com/products/mpower_demos.html
Neely, A., Mills, J., Platts, K., Gregory, M. & Richards, H. (1996). Performance
measurement system design: Should process based approaches be adopted?
- 204 -
International Journal of Production Economics (Proceedings of the 8th
International Working Seminar on Production Economics, Dec 1996) Vol.46-
47, 423-431. Retrieved June 13, 2009, from
http://www.sciencedirect.com/science/article/B6VF8-3VWC751-
17/2/4b8d8bea9e0c983dab503fcd05e6b2f0)
Negash, S. & Gray, P. (2008). Business Intelligence. In Handbook on Decision
Support Systems 2. Berlin Heidelberg:Springer. Retrieved October 27, 2008
from
http://www.springerlink.com/content/j72701/?p=7a0c0b8e41f24039a678ab5be6
f60620&pi=0
Nishith (2006). Data mart versus data warehouse: The great debate. Retrieved
August 12, 2009, from http://opensourceanalytics.com/2006/03/14/data-mart-vs-
data-warehouse-the-great-debate/
Numnonda, T. & Kruawaisaywan, T (2009). Business process management using
BPEL. Retrieved July 13, 2009 from
http://www.slideshare.net/thananum/business-process-management-using-bpel
Oasis (2007). Web services business process execution language version 2.0: OASIS
standard. Retrieved July 10, 2009, from http://docs.oasis-
open.org/wsbpel/2.0/wsbpel-v2.0.pdf
Oracle (2007). Oracle business intelligence standard edition one tutorial
Release 10g (10.1.3.2.1). Retrieved July 12, 2009, from
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concep
ts.htm
Pentaho [1] (2009). About Pentaho Corporation. Retrieved June 29, 2009, from
http://www.pentaho.com/about/
- 205 -
Pentaho [2] (2009). Leading Global Nutrition Company Deploys Pentaho Business
Intelligence on the Amazon Cloud. Retrieved August 25, 2009, from
http://www.pentaho.com/news/releases/20090210_nutricia_uses_pentaho_on_a
mazon_cloud.php
Pieczkowski, E.R. (2007). Is BPEL positioned for the future. Retrieved July 13, 2009
from http://www.networkcomputing.com/gallery/2007/0319/0319tte.jhtml
QuickMBA (n.d.). The strategic planning process. Retrieved February 15, 2009, from
http://www.quickmba.com/strategy/strategic-planning/
Reed, M. (n.d.). A definition of data warehousing. Intranet Journal:Building the
Corporate Enterprise. Retrieved February 9, 2009, from
http://www.intranetjournal.com/features/datawarehousing.html
Resource planning (2005). In International Encyclopedia of Hospitality Management.
Oxford: Elsevier Science & Technology. Retrieved October 28, 2008, from
http://www.credoreference.com.dml.regis.edu/entry/7912881/.
Robertson, A., Brown, D., & Lockett, N. (2007). White paper: The enterprise Survey.
Retrieved January 18, 2009, from
http://redress.lancs.ac.uk/resources/Robertson_Alastair/The_Enterprise_Survey_
White_Paper/EnterpriseSurvey.pdf
Saha, G. K. (2007). Business intelligence computing issues. Ubiquity 8, 25 (Jun.
2007), 1-1. Retrieved January 5, 2009, from
http://doi.acm.org/10.1145/1286460.1286461
Scheer, A., & Habermann, F. (2000). Enterprise resource planning: making ERP a
success. Communications of the ACM 43, 4 (Apr. 2000), 57-61. Retrieved
January 15, 2009, from http://doi.acm.org/10.1145/332051.332073
- 206 -
Skok, W. & Legge, M. (2001). Evaluating enterprise resource planning (ERP)
systems using an interpretive approach. In M. Serva (Ed.), Proceedings of the
2001 ACM SIGCPR Conference on Computer Personnel Research (San Diego,
California, United States), (pp. 189-197). New York, NY:ACM. Retrieved Jan
15, 2009, from http://doi.acm.org/10.1145/371209.371234
TDWI (n.d.). TDWI's business intelligence maturity model. Retrieved July 27, 2009,
from http://www.tdwi.org/publications/display.aspx?id=7288
The Business Intelligence Guide (n.d.). BI best practices. Retrieved January 30, 2009,
from
http://www.thebusinessintelligenceguide.com/bi_strategy/BI_Best_Practices.ph
Tibco (2006).Goal-oriented business process management: Creating agile business
processes for an unpredictable environment. Retrieved Feb, 2009, from
http://forms.tibco.com/go/tibco/goal_oriented_bpm
Torode, C. (2009). BI Saas: A fit for some, not for others. Retrieved July 15, 2009
from http://searchcio-
midmarket.techtarget.com/news/article/0,289142,sid183_gci1358884,00.html
Utley, C. (2008). Designing the star schema database: Version 1.1. Retrieved August
10, 2009, from
http://www.ciobriefings.com/Publications/WhitePapers/DesigningtheStarSchem
aDatabase/tabid/101/Default.aspx
van Everdingen, Y., van Hillegersberg, J., & Waarts, E. (2000). Enterprise resource
planning: ERP adoption by European midsize organizations. Communications of
the ACM 43, 4 (Apr. 2000), 27-31. Retrieved Jan, 12, 2009 from
http://doi.acm.org/10.1145/332051.332064
- 207 -
W3C (2004). Web Services Architecture: W3C Working Group Note 11 February
2004. Retrieved August 01, 2009, from http://www.w3.org/TR/ws-arch/
Whiting, R. (2009). Recession proof? BI software sales took off in 2008. Retrieved
August 15, 2009 from
http://www.crn.com/software/217801240;jsessionid=J0GUIYWRKHMCZQE1
GHPSKH4ATMY32JVN
Wise, L (2007). BI on the fly: A guide to Web-based business intelligence. Retrieved
June 03, 2009, from
http://whitepapers.technologyevaluation.com/download/6666/How-to-Evaluate-
Web-based-BI-Solutions.html
Wyderka, K. (2001). Unlocking your ERP data: Business intelligence for ERP
systems. In Information Management Magazine, June 2001. Retrieved June 10,
2009, from http://www.information-management.com/issues/20010601/3492-
1.html
- 208 -
Appendix A
Methodology for Slowly Changing Dimensions (SCDs) Type 1
There are three primary methods (more exist) for dealing with SCDs in a data
mart or data warehouse environment. In type 1 the new information overwrites the old
information. This method is used where there is no requirement to maintain the
original value for historical analysis.
Table K1
SCD Type 1 Example
_________________________________________________________________
Measure Employee Firstname Lastname
Number (PK)
_________________________________________________________________
Record content before 1000 Josephine Bloggs
change
Record content after 1000 Josephine Smith

change
_________________________________________________________________
The example in Table K1 demonstrates a change to the employee’s surname without

any change in the primary key on the record.
- 209 -
Appendix B
In type 2 treatment of SCDs a new record is added to the table to represent the
changed data. This results in an additional record with a new key. This is used where
the old value is important for historical analysis. Data relating to this employee will
be split between old and new values making historical trend analysis more difficult.
Table L1
SCD Type 2 Example
_________________________________________________________________
Measure Employee Firstname Lastname
Number (PK)
_________________________________________________________________
Record content before 1000 Josephine Bloggs
change
_________________________________________________________________
Record content after 1000 Josephine Bloggs
change
Additional record added 1001 Josephine Smith

_________________________________________________________________
- 210 -
Appendix C
In type 3 treatment of SCDs the old value is overwritten with the new value
and additional data is added to the table to store the old value and perhaps the
effective date of the change. This is useful for maintaining one change only. After that
historical information will be lost.
Table M1
SCD Type 3 Example
_________________________________________________________________
Measure Employee Firstname Lastname Maiden Date
Number (PK) Name Effective
_________________________________________________________________
Record 1000 Josephine Bloggs
content
before
change
_________________________________________________________________
Record 1000 Josephine Smith Bloggs 10-AUG-2009

content
after
change
_________________________________________________________________
- 211 -
Appendix D
Survey on Business Intelligence (BI)
Welcome to the BI Survey
There are 53 questions in this survey
* - indicates a mandatory question
Operational and Strategic Planning
Note: A Key Performance Indicator (KPI) is defined as a metric for quantifying the efficiency and
effectiveness of an action
1. Does the company have a corporate mission statement or similar
guiding Principle? *
Please choose only one of the following:
Yes
No
2. Does the company have a documented business plan encompassing the
goals of the organisation? *
Yes
No
3. Do the Key Performance Indicators (KPIs) in use in the company link to
specific business goals? *
All do
Most do
Some do
- 212 -
None do
Don't know
4. Is there a master document listing all Key Performance Indicators
used within the company? *
Yes
No
Don't know
5. When documenting Key Performance Indicators (KPIs) which of the
following are used in relation to a description of the metric? *
Please choose all that apply:
Descriptive title
Purpose of the performance measurement
An indication of the business goal to which it relates
Functional area to which it relates
Target
Formula used to calculate
Frequency of generation
Who is responsible for measuring?
The source(s) of data used to calculate
Who acts on data?
What do they do?
Notes and comments
Other:
6. It is easy to collect/extract the data needed to measure the financial
performance of the company from our current Information Systems *
- 213 -
Strongly Agree
Agree
Agree with some exceptions
Disagree with some exceptions
Disagree
Strongly Disagree
7. It is easy to collect/extract the data needed to measure the non- financial
performance of the company *
Strongly Agree
Agree
Disagree
Strongly Disagree
8. Decision makers in the company can easily retrieve the data they
require from our current business information systems without IT
involvement *
Strongly Agree
Agree
Disagree
Strongly Disagree
- 214 -
9. Decision makers in the company rely on the IT/MIS department to
extract information from our current information systems *
Strongly Agree
Agree
Disagree
Strongly Disagree
BI Technology Use
Note: "Business Intelligence" (BI) refers to the collective resources and technologies that are used by
companies to collect, assemble and deliver analytical information to business users
10. Are you familiar with the following concepts in relation to Business
Intelligence? *
Please choose the appropriate response for each item:
Yes No
Business Activity Monitoring (BAM)
Dashboards
Predictive Analytics
Scorecards
Data Warehouse
ETL Tools (Extract, Transform, Load)
Alert based KPIs
Business Process Modelling
Ad-Hoc Query Tools
Real Time alerting to embedded devices (mobiles)
- 215 -
Business Intelligence Packaged Solution
Point Solutions designed for a specific business need
Spreadsheets
11. Please indicate which BI tools are currently in use in the company
Business Activity Monitoring (BAM)
Dashboards
Predictive Analytics
Scorecards
Data Warehouse
ETL Tools (Extract, Transform, Load)
Alert based KPIs
Business Process Modelling
Ad-Hoc Query Tools
Real Time alerting to embedded devices (mobiles)
Business Intelligence Packaged Solution
Point Solutions designed for a specific business need
Spreadsheets
Other:
12. Which of these would be the biggest inhibitor to using BI Tools?*
Cost
Lack of in-house expertise
Don't know what solutions are available
Too much ongoing maintenance of these solutions
Too complex for our company size
- 216 -
No suitable solutions available for our needs
Other
13. Which of the following would be the primary driver for implementing
a BI solution *
Customer Requirement
Cost Saving
Better Information for decision makers
Other
14. Business Applications can be delivered in many ways to end users. Please
indicate if you would consider the following methods of delivery:*
Please choose the appropriate response for each item:
Would Would Not Currently

Consider Consider Using
Software as a Service (SAAS)
Cloud Computing Delivery
Open Source Software
Professional Open Source Software
Licensed software - installed on company hardware
Licensed software - outsourced
Guidence Notes
SaaS: Hosted software that's shared by multiple customers
Cloud computing: Rent an instance on the web and all necessary space
and system utilities to run it (eg. Amazon EC2
Platform).
Open Source Software: Community Developed
- 217 -
Professional Open Source: Open Source software with support and maintenance
offered by primary developer
15. How much would you expect to spend on a Business Intelligence
solution?*
Less than €20k
€20K - €40K
€40K – €60K
€60K - €80K
€80K- €100K
€100K plus
Cost is not a concern
16. What are the primary data sources used in the company *
Oracle SQL
MySQL
SQL Express
DB2/AS400
Access
Excel
Microsoft SQL Server
PostgreSQL
Ingres
Informix
HSQLDB
Other:
- 218 -
Business Intelligence Section
17. Does the company currently use any Business Intelligence solutions? *
Yes
No
18. Which BI solutions does the company currently use? Please list all
that apply *
[Only answer this question if you answered 'Yes' to question 17 ]
Please write your answer here:
19. Approximately how many users of listed BI solutions does the company
have? *
[Only answer this question if you answered 'Yes' to question 17 ]
20. Does the company have dedicated IT staff to support your BI solution?
[Only answer this question if you answered 'Yes' to question 17]
Yes
No
21. How many IT staff provides a supportive role for BI Solutions? *
- 219 -
22. How would you rate the company’s satisfaction with the BI software in
terms of meeting the company’s original objectives? *
Not at all
Somewhat satisfied
Satisfied
Very satisfied
Exceeds expectations
23. Which of these statements best reflects the role of BI Tools within the
company? *
BI Application is an IT department tool
BI Application is an end user tool
BI Application is both an IT department and end user tool
24. End users and power users can easily design their own reports and
extracts from the BI Application *
True
False
ERP Section
- 220 -
25. Does the company currently use an Enterprise Resource Planning
(ERP) system? *
Yes
No
The purpose of this question is to establish if an ERP system is available as a data source for any
Business Intelligence solution.
26. Who is the current ERP Vendor? *
27. Which ERP Software Product and version does the company use? *
28. How long has the current ERP system been in use? *
less than 2 years
2 to 5 years
5 to 8 years
8 to 11 years
More than 11 years
Not yet using it
- 221 -
29. Which of the following business driver’s best describes the reasons for
implementing an ERP system? *
Y2K enforced
E-commerce Interoperability with customers / suppliers
Need to manage growth expectations
Cost reduction through innovation
Satisfy customer driven requirements
Business process improvement project
Improve strategic and operational planning
Other:
30. Which of the following best describes the current ERP implementation
state? *
Currently Implementing
Some modules implemented - more to do
All required functionality implemented - no projects planned
All required functionality implemented - improvement projects in
progress
All required functionality implemented - improvement projects
planned
Other
- 222 -
31. Which of these best describes the current ERP Software pricing
structure? *
Customised solution developed specifically for the company
Vendor Solution - Licensed software on company hardware
Outsourced - Licensed software with third party maintenance and
support
Software as a Service (SaaS) solution
Open Source with customisation
Open Source without customisation
Cloud Computing Delivery
Other
32. How many employees currently use the ERP system? *
01 - 25
26 - 50
51 -75
76 - 100
100+
33. Who supports (will support) the ERP system? *
Company IT Department
ERP Vendor
- 223 -
Third Party Contractor
Local Power Users
Other:
34. What was the approximate implementation time for the ERP system? *
Less than 6 months
06 - 12 months
12 - 18 months
18 -24 months
24 - 36 months
Other
35. What percentage of the total ERP functionality available is currently in
use? *
Less than 20%
20% - 40%
40% - 60%
60% - 80%
80% - 95%
100%
Nothing implemented yet
36. Which of the following best describes the company’s implementation
approach? *
- 224 -
Big Bang - All at once
Phased modular implementation
Other
37. Were any of the following used as part of the implementation strategy?
Business Process Re-Engineering
Business Process Analysis using informal text based methods
Business Process Modeling - using formal methods (eg. BPEL)
Business process to KPI/Goal based metrics mapping
Vendor Reference Models (automated parameter configuration)
38. How would you rate the company’s satisfaction with the ERP software
in terms of meeting the company’s original objectives? *
Not at all
Somewhat satisfied
Satisfied
Very satisfied
Exceeds expectations
39. Does the ERP vendor supply an optional or Integrated BI solution? *
Yes
No
- 225 -
Don't know
Not relevant to our industry
40. Are you aware of any third party BI products which integrate with the
ERP System? Please list any examples you know.
Guidence:This question is to ascertain the level of awareness in the sector of BI products
41. Which of the following best describes your reason for not using an
ERP system? *
[Only answer this question if you answered 'No' to question 25]
ERP systems are too costly
ERP systems are too complex for our needs
We do not require an ERP system
ERP systems are unsuitable for our business sector
Other
42 What is your primary Financial Information system? *
43 What is the company’s primary production planning system? *
- 226 -
Company Details
44. Please indicate the total number of employees at your site. *
45. How many IT staff work in the company at your site? *
Respondent Details
46. Please State your job title: *
47. Please indicate your department: *
- 227 -
48. Please state company name: *
49. Please state your name: (Optional). This will not be disclosed.
50. Would you like to receive an emailed copy of the completed research
document? *
Yes
No
51. Would you like to receive a copy of the donation confirmation receipt? *
Yes
No
52. If you have requested a copy of the research or donation receipt please
enter recipient email address.
- 228 -
53. Please add any additional comments you wish to make in relation to any
aspect of the Survey
Please submit by YYYY-MM-DD
Thank you for completing this survey.
- 229 -
Appendix E
Invitation to Participate in the Survey
The following is the text of the email requesting participation in the survey.
Dear {FIRSTNAME},
May I firstly apologise for the intrusion. I am pursuing a MSc. and would be deeply
grateful if you would participate in my survey relating to the relevance and
use of ERP and Business Intelligence (BI) software. In appreciation of your time I
will donate €5 per completed survey to the Irish Cancer Society. All survey
participants will be offered a copy of the completed research project and a copy of the
donation receipt. All information will be treated in strict confidence and reported in
summary form only in the report. No company names or individual names will be
disclosed. The survey will take approximately 10 minutes or less depending on
questions answered. It should ideally be answered by an individual with responsibility
for your Business Information Systems such as an IT Manager, CIO or Financial
Director/Controller etc. If you are not this person PLEASE forward this email to the
individual in your company who would be most suitable. If you have any questions
or concerns please feel free to contact me by email at
pohmasters@googlemail.com
or
Mobile: +00353 (0)879069535
Your time is very much appreciated.
To participate, please click on the link below.
Sincerely,
Paula O'Hara (pohmasters@googlemail.com)
----------------------------------------------
- 230 -
Click here to do the survey:
{SURVEYURL}
http://bisurvey.limequery.com/index.php?lang=en&sid=71747&token=czm55dwme6
yhfzu
- 231 -
Appendix F
Reminder to Participate in the Survey
Dear {FIRSTNAME},
I once again apologize for the intrusion. This is a gentle and final reminder
asking you to participate in the survey indicated below which forms part of the
research for my Masters Degree with NUI Galway which is still available until Friday
31st July.
€5 will be donated to the Irish Cancer Society for each completed survey. The survey
seeks to uncover the use and awareness of Business Intelligence tools and ERP in
manufacturing companies. I would be deeply grateful for your participation. No
company names or individual names will be used in the report. All information will
be summarized and reported statistically. You will also be offered a copy of the
completed research in appreciation of your time.
To participate, please click on the link below.
Sincerely,
Paula O'Hara (pohmasters@googlemail.com)
----------------------------------------------
Click here to do the survey:
http://bisurvey.limequery.com/index.php?lang=en&sid=71747&token=euniwwi8eka9
2fu
- 232 -
Appendix G
Request for Permission to use the TDWI’s Business Intelligence Maturity
Model Poster
Request
From: Geehan, Paula R [mailto:geeha571@regis.edu]
Sent: Sunday, August 09, 2009 9:31 AM
To: TDWI Info
Subject: Permission to use TDWI's Business Intelligence Maturity Model
To whom it may concern,
I am a Masters Student at Regis University, Denver Colorado and NUI Galway
Ireland. I am writing a thesis on implementing BI in Small and Medium-sized
Enterprises and I would like permission to include a copy of the TDWI's Business
Intelligence Maturity Model poster as a reference model example of a BI maturity
framework. The work will carry a full citation to your organisation as the owner of the
model and it will not be changed in any way.
Yours Sincerely
Paula Geehan (O'Hara)
Response
From: Jennifer Agee[SMTP:JAGEE@TDWI.ORG]
Sent: Monday, August 10, 2009 9:08:46 AM
To: Geehan, Paula R
Subject: FW: Permission to use TDWI's Business Intelligence Maturity Model
You have permission. Thanks so much for your message!
Best,
Jennifer
- 233 -
Jennifer Agee
Managing Production Editor, TDWI
---------------------------
jagee@tdwi.org
425.277.9239
425.687.2842 (fax)
- 234 -
Appendix H
Information Users and Consumers - Company A
Figure H1. Information users and consumers - Company A
- 235 -
Appendix I
Information Producers and Consumers in the Context of the Organizational Hierarchy – Company A
Figure I1. Information producers and consumers in the context of the organizational hierarchy
- 236 -
Appendix J
Current Sales Reporting Data Sources and Methods- Company A
Sales statistics are generated when the invoice run is performed; therefore the
process starts when the invoice is generated. On completion of the invoice run the
sales reporting cycle commences.
AS400 – Movex ERP
From Customer Order Processing Cycle.
Hardcopy
Invoices
General (Printed in
Ledger – duplicate – File
Revenue A copy onsite, copy
Accounts posted to
customer
(Daily)
Sales
Ledger – Invoice Run for despatched orders.
Customer (Daily)
Accounts
Movex Sales Statistics Pre-defined

Sales Module Reporting reports –
Statistics (Weekly/Monthly/ (paper)
Quarterly/Annually)
Other ERP
tables RPG Report Programs (In-
house and Movex Standard Multiple
Reporting Programs ) Reports:
(paper)
Ad-Hoc
output files Report Generation
AS400 Query Multiple Ad-hoc
(Ad-hoc Reporting) Reports: (paper)
Spreadsheet data re-

keyed to ERP
IBM Client Access File Transfer
(iSeries Access - ODBC Driver)
Report data re-keyed

to spreadsheets
File Server
End-users Power-users Executives (Shared folders)
Figure J1. Current sales reporting data sources and methods – Company A
237
Appendix K
MIS Capability - IT Hardware Infrastructure Diagram - Company A
Internet
LAN (Ethernet Connectivity) Wireless Access

Patch Panel (3)
Point WAP54G 256mb Private Circuit
Dell Power connect 5324

Managed Switch (3) Cisco 1841 Router
File and
Application Server
Domain controller
Exchange Server
IBM AS400
iSeries P05
Figure K1. MIS capability - IT hardware and infrastructure diagram – Company A
238
Appendix L
MIS Capability - Software Pertaining to the BI Project – Company A
File and Application Operating System Windows Server 2003

Server SP2
Business Intelligence m-Power by MRC
Application
BI Web Server Apache Tomcat 5.0.27
JRE J2SE Runtime
Environment 5.0 Update
6
JDK Java Development Kit 6
Update 14
AS400 iSeries 520 Operating System OS400 V5R3M0
Business Intelligence m-Power by MRC
Application Libraries
Development Kit for Java *Base and option 6 (JDK
1.4)
ERP Lawson Movex V11.4
(RPG)
Query Utilities IBM Query
Development IBM Websphere
Development Studio for
iSeries (includes RPG
Programming Language)
Exchange Server Operating System Windows Server 2003
SP2
Email Microsoft Exchange
Server 2003
Client PC Emulation and File Transfer IM Client Access (5250
Emulation and File
Transfer Software (uses
ODBC))
Office Applications Microsoft Office 2003
Figure L1. Company A software capability pertaining to BI
239
Appendix M
MRC’s m-Power Technical Specification
MRC’s m-Power application uses n-tier architecture which implies at least 3
layers consisting of an application layer, a database layer and a presentation layer.
The application components supporting this architecture comprise:
• HTML interface (with paint utility for end user to tweak the design)
• Java Servlets and Portlets (accessible, modifiable program code) + external
logic
• JDBC access to DB
• Applications run over Java application servers including WebSphere, Tomcat,
and Weblogic (Tomcat is used in Company A).
Supported Databases include:
• IBM DB2, IMS, Informix
• Microsoft SQL Server, Access, Excel
• Oracle
• Sun MySQL
Supported Operating Systems include:
• Windows XP or Windows Server 2003
• IBM OS/400
• IBM Z/OS
• Linux
• Unix
240
Supported Java application servers include:
• Apache Tomcat (pre-configured with m-Power)
• IBM Websphere
• BEA Weblogic
• Red Hat JBoss
Costs:
m-Power costs including licensing, installation and training for Company A fall
within the €20k - €40k bracket.
241
Appendix N
Structure of a WS-BPEL 1.0 Process
Figure N1. BPEL Process Definition
____________________________________________________________________
Note: The diagram was created to represent a WS-BPEL 1.0 process structure. WS-BPEL 2.0 is not
significantly different so it serves to illustrate the main components of a process.
Source: Dubray (2002)
242
Appendix O
Control Flow within WS-BPEL 1.0
Correction Noted: Should be Switch
Figure O1. BPEL Control Flow
____________________________________________________________________
Note: The diagram was created to represent WS-BPEL 1.0
Source: Dubray (2002)
243
Appendix P
Pentaho BI Suite Community and Enterprise Edition Features
Software and Services Community Enterprise

Edition Edition
Reporting Open Source Certified
Analysis Open Source Certified
Dashboards Open Source Certified
Data Integration Open Source Certified
Business Intelligence Platform Open Source Certified
Data mining Open Source Certified (Add-On)
Community Forums Interaction √ √
Community Web Development (wiki) √ √
Professional Support
Telephone support (toll-free) √
E-mail support √
Service Level Agreement √
Unlimited support cases √
Software Maintenance
Software maintenance By in-house staff By Pentaho
Engineers
Patch Releases √
Fixes included in future releases √
Enhanced Functionality
Pentaho Enterprise Console √
Single Sign-On √
Streamlined security configuration √
Application diagnostics √
Repository utilities √
Lifecycle management √
Audit reports √
Automated content expiration √
Clustering √
Performance monitoring √
Certified Software
Stabilized software √
Managed release cycle √
Optimized builds √
Product Expertise
Professional documentation √
Knowledge base √
Consultative support √
Remote assistance packages √
244
Installation/configuration packages √
Design and integration packages √
Troubleshooting and optimization √
packages
Enterprise Edition online forum √
Web based training √
Software Assurance √
Intellectual Property indemnification √
Warranty for services √
Figure P1. PentahoTM BI Suite Community and Enterprise Edition Features
___________________________________________________________________
Source: Information supplied by Pentaho Corporation direct to author
245
Appendix Q
Pentaho Enterprise Edition Pricing Guide (2009)
Step 1: Determine # of CPU's under agreement: Based on your implementation, including dev/test/production
Step 2: Decide on which Modules you need
Step 3: Decide on Plan: Silver vs. Gold vs. Platinum
Step 4: Decide on length of agreement: 1 year or 3 year
Step 5: Decide on prepay or not-prepay
1 Year 3 Year Commit 3 Year Commit

paid Net
Plan Year 1 paid Net 45 all 3 years paid Net 45 Includes
45
(1) Named Contact, up to (2) CPU's, 12 tech support calls/year, only for Analysis and
1 Module Silver €4,000 €4,000 -10%
Reporting, max. 25 users., no IP indemnification
(1) Named Contact, up to (2) CPU's, 12 tech support calls/year, max. 25 users., no IP
1 PDI Module Silver €7,500 €7,500 -10%
indemnification
1 Module Gold €11,000 -10% -20% (1+1) Named Contact, up to (4) CPU's, unlimited tech support calls, all modules
(1) Named Contact, up to (2) CPU's, 12 tech support calls/year, max. 25 users., no IP
BI Suite Silver €12,000 -20% -27%
indemnification
(1+1) Named Contact, up to (6) CPU's, unlimited tech support calls, 18h consultative
BI Suite Gold €29,000 -10% -20%
support, unlimited users
(2+1) Named Contact, up to (6) CPU's, unlimited tech support calls, 24h consultative
BI Suite Platinum €36,000 -10% -20%
support, unlimited users plus web based training and remote assistance packages incl.
Figure Q1. Pentaho Enterprise Edition pricing guide for 2009

___________________________________________________________________________________________________________
Source: Information supplied by Pentaho Corporation direct to author
246
Appendix R
Selected Pricing for the EC2 Cloud Environment
Source: Amazon Web Services (2009).
Prices listed are those current at July 2009. Prices are based on instance
types as described in Figure P1. Standard instances are suitable for most
applications. High CPU instances are suitable for compute intensive applications.
Instance pricing may be either On-Demand (by the hour) or Reserved (annual
fixed fee).
Instance Type Instance Size Category Specification

Standard Instances Small 1.7 GB of memory,
Instance 1 EC2 Compute Unit (1 virtual
core with 1 EC2 Compute Unit),
160 GB of instance storage, 32-bit
platform
Large 7.5 GB of memory, 4 EC2
Instance Compute Units (2 virtual cores
with 2 EC2 Compute Units each),
850 GB of instance storage, 64-bit
platform
Extra Large 15 GB of memory, 8 EC2
Instance Compute Units (4 virtual cores
with 2 EC2 Compute Units each),
1690 GB of instance storage, 64-
bit platform
High CPU Instances High-CPU 1.7 GB of memory, 5 EC2
Medium Compute Units (2 virtual cores
Instance with 2.5 EC2 Compute Units
each), 350 GB of instance
storage, 32-bit platform
High-CPU Extra 7 GB of memory, 20 EC2
Large Instance Compute Units (8 virtual cores
with 2.5 EC2 Compute Units
each), 1690 GB of instance
storage, 64-bit platform
Figure R1. EC2 instance types.
__________________________________________________________________
Source: Amazon Web Services (2009)
247
On-Demand Instances pay for compute capacity by the hour costs for
Europe is detailed in Figure R2.
Figure R2. EC2 On-Demand hourly cost (Europe)

__________________________________________________________________
Reserved Instances fixed fee costs for Europe are detailed in Figure R3.
Figure R3. EC2 Reserved cost (Europe)

__________________________________________________________________
248
Data transfer pricing based on data transferred "in" and "out" of Amazon
EC2 is shown in Figure R4.
Figure R4. EC2 data transfer costs

__________________________________________________________________
The costs for the Cloud Watch Monitoring service may be seen in Figure R5.
Figure R5. EC2 cloud watch costs

__________________________________________________________________
Load Balancing charges are described in Figure R6.
Figure R6. EC2 load balancing costs

______________________________________________________________
249
Elastic IP which involves remapping an organizations public IP addresses
to any instance in the organization’s account is charged as described in figure R7
Figure R7. EC2 Elastic IP Costs

____________________________________________________________
The prices listed here do not represent the comprehensive price list but are
intended as a guide to the main costs involved in using the EC2 platform. All
information in this section is supplied by Amazon Web Services LLC (2009).
250
Appendix S
Business Intelligence Vendor and Application Assessment (RFI)
Business Intelligence Vendor and Application Assessment

Request for Information
This questionnaire forms part of a selection process for Business

Intelligence applications being considered by
________________________
Company Name
Please complete all sections to be considered in the initial selection

process
Selection Process
Stage 1: Request for information

Stage 2: BI Team short-listing
Stage 3: Proof of concept demonstration
Stage 4: Final vendor ranking
Stage 5: Primary candidate(s) detailed exploration
Stage 6: BI Application selection
251
PART I: Organization and Application General Assessment Criteria in RED must be met
Desired Criteria (To be defined locally

Assessment item Internal Use Only)
Vendor Stability Assessment
Company name (N/A or Big Five etc.)

How many offices does the company have? More than 1
How many staff is employed in total? 20+
How many years has the company been in business? 5+
Last Year:
2 years ago:
Please state turnover for last three years. 3 years ago: Positive trend
Please list business partners offering sales, consultancy and Must have a local presence in this country within 2
training. hour drive
Must have a local presence in this country within 2

Who is nearest partner/reseller for this location? hour drive
Forms part of Integrated Business Application

List other solutions offered (apart from BI). suite
Product Stability
What date was the first public release? Must be on the Market for over 2 Years
252
What is the latest stable version?

Must support Windows Server 2003 , Win XP
Which operating systems and versions are supported? clients , AS400 iSeries OS400
State web browser support. Must be compatible with IE 7.0
State approximate number of installations in this country. Compare to competition
State approximate number of installations globally. Compare to competition
How many new installations in the last 12 months? Compare to competition
What is frequency of new releases? At least Annually
What is frequency of service pack releases? At least Quarterly
Tiered solution - scales with organization size. Should scale on business size/number of users
Please provide name and contact details for 3 reference sites
(Indicate industries of similar size, market segment and
geographic location)
Vendor Support Structure
Does company offer SLAs? SLA required

Number of support staff employed for this application Compare to competition
Number of development staff employed for this application Compare to competition
Primary support office location Preferably within country
Secondary support locations Preferably within the country
Nearest support office to this location Preferably within the country
Telephone support helpline available Must have
Live email support Highly desirable
Delayed email support - based on contracted response times
Access to knowledgebase Desirable
Remote assistance (remote in to customer site) Must have
Support helpline hours of operation ( 5 x 8 same time zone)
253
Average issue resolution turnaround time. (average time

taken to resolve issues from initial report to user completion
signoff) Critical - 48 hours, Medium priority – 1 week etc
Prioritized issue reporting (issues are categorized and
resolved based on pre-defined criticality assignment). Must have
Active user groups exist (independent or vendor led user
group) Highly Desirable
Training and Consultancy
State experience of trainers available to this location More than 2 years in role
Training location
On-Site Must have
Web-based Courses Highly Desirable
External facility Must have
Training external facility locations
Training Costs
Per Day <=€1000
Per User
Per Class
Other
Class Size minimum
Class Size maximum
Consultancy - cost per day <=€1000
Information consumer training available(casual end-user,
executives/managers)
Information producer training available (power-users,
business analyst, IT development) Technical staff training essential
254
Dependency on vendor post training rating (on a scale of 1 -

10 where 1 is highly dependent and 10 is self sufficient) Should score >= 7
Skills required by IT developers
Skills required by Business Analyst
Skills required by power-users
Skills required by end-users
Software Costs
State licence costs - actual Total licensing should not exceed €40k
Is licence cost platform dependent?
Is licence cost per seat
Is concurrent user licensing available
Is licence cost processor dependent
Is annual licence subscription required to get upgrades
Usage based billing available (SaaS/Cloud)
Maintenance Costs and Contents
Define support limitations (What is not included)

Includes Fixes Must
Includes New Releases Should
Includes New Modifications (vendor enhancements) Must
Do lapsed maintenance contract penalties exist? (If so how
much?)
Includes preferential rates for consultancy/development Negotiate as part of contract
Guaranteed response times Must have - Critical 4 hours, High 8 hours,
255
Medium 24 hours, Low 48 hours

Annual Maintenance Cost (State cost basis)
Hardware and Software Pre-requisites
Platforms supported - state all that apply AS400 iSeries, Windows 2008 Server
Processor specification – Client
Processor specification – Server
Ram specification - Client
Ram specification – Server
Storage specification Client
Storage specification Server
Minimum O/S required Client
Minimum O/S required Server
Internet browser specification
Other pre-requisites (hardware and software) to use
application
Documentation
User Manual Must have

Technical manual - configuration / administration Must have
Installation manual Should have
Delivery Platforms
Licensed - on company or third party hardware

Cloud
SaaS
256
Open Source - community edition

Open Source - professional editions (with vendor support
contract)
Other
Third Party Recommended Products
Please state approved third party products

Any other recommended third party products
PART II: Product Assessment:
Available Not Modification Available

(in base) available required as add-on
Administration
Automatic restart and recovery from failure
Remote restart and recovery from failure
Clear the cache mechanism
Database access logs
Audit trail reports and alert notification (email, pager, etc.) on data
acquisition failures
Provision of performance monitoring tools
Report locking / check-out
Usage monitoring / reporting
User specific customisable menus
257

Ability to schedule tasks / reports
By the second
By the Minute
Hourly
Daily
Weekly
Monthly
Annually
Every n seconds
Every n minutes
Every n hours
Every n days
Every n weeks
Every n months
Every nth
minute/second/day etc. for
n occurrences
Every MON ….
Built in backup and archive utilities
Analytics
"What-if" analysis
Ability to do ad hoc complex calculations (@ report level and cube level)
Ability to perform drill down back to the source database tables
Ability to support Ad hoc reporting (development of new reports)
Specific cost allocations and misc. adjustments functionality
Ability to support historical comparisons/trending
Add columns
258

Column sorting
Cross-drill in any view/grid (drill a result by a 2nd dimension)
Data filter prompts
Data grid and chart view
Data grid only view
Chart only view
Decision tree (process flows and information hierarchies via graphical flow
charts)
Design tool for semantic layer (end user oriented –table creation/metadata
manipulation)
Dimension member search
Dimension swapping / pivoting
Divide columns
Drag and drop dimension manipulation
End user definition of named sets
End user meta data visualization
Exception condition logic with colour coding
Forecast model support (e.g. linear regression)
Forecasting/Hypothesizing/What-if
Geo-spatial map
Graphical display of dimensional hierarchy
Heat map
Hide column
Presents Data Dimensions as tree view
Hide data based on user defined specifications
Creation of Analytic Workflows (Develop process map and link to reports)
MDX editor (Multi-Dimensional eXpressions)
Multiply columns
259

Pick list customization
Ranking of data sets - (Top N analysis)
Sensitivity analysis
Create personalized cube views (user specific OLAP views)
Server level business logic definition
Slicing/Dicing by dimensions (able to change view of existing reports)
Standard deviation
Subtotal row or column
Subtract columns
Support of modeling / scenario generation
Supports rolling-time periods
Cohort analysis e.g. view a group (products, customers, etc) along a time
series
Total row or column
T-tests
User defined pre-defined calculations (store previously defined calculations)
User defined hierarchies
Variance analysis
Wizard based query creation
Write back capabilities to OLAP cubes / data marts. If the tool provides write
back capabilities, explain security levels and administration of the cube
Zero/null cell suppression
Architecture
Pre-built cubes
Ability for an administrator to publish KPI
Ability for an administrator to publish KPI as a web enabled object
260

Ability for an end user to publish KPI to other users
Platform Independent
Ability to distribute report query over multiple CPUs concurrently
Database partitioning strategy (if vendor provides there own database
structures [i.e. Cubes])
End user wizard for fixing missing data issues when a cube changes
Exposed API for developer use
Integration with Crystal Reports
Integration with Microsoft Share Point
List of supported operating systems (include recommendation from a
performance and stability perspective)
Lotus Notes integration
Microsoft Analysis Services cubes
Microsoft Reporting Services integration
Microsoft SQL YYYY compatibility (which versions)
High availability server clustering/mirroring
Note any native database connectivity and/or database connectivity
protocols (i.e. ODBC, OLEDB, ADO, JDBC, etc.)
Open software development kit for UI customizations and plug-in
development
Report caching on server
Shared data - dimensions and facts
SMP Support
Support Microsoft IIS web server (5.0, 6.0 ?)
Other Web Server Support – (Apache Tomcat, Web Sphere etc.)
Support of Application and O/S Buffering
Support UNIX server
Supports 64-bit processing
261

Supports Windows YYYY Server (which versions)
Three tier server architecture (n-Tier architecture)
Tools scale to accommodate many simultaneous users
Client Architecture
Rich client using Active X
Windows versions 2000/XP/VISTA
Other operating systems (Please specify)
Wireless PDA
Zero-foot print web client (No Java or activeX)
.NET client implementation
Collaboration
Collaborate across groups through alert based notifications based on

triggers or identified processes
Data acquisition
Able to access and integrate multiple data sources (Relational and
multidimensional)
AS400/DB2 data acquisition
CSV
Essbase
Microsoft Excel
Off-line (local) cubes
Oracle data acquisition
Database, server, and report logging capability
Facility for metadata integration
262

Provide facility to track version releases and system migration/promotion
operations
Provide for Meta Data Extraction and Display
SAS datasets
Sybase
Terradata
XML as a data source
Update cube views with real-time data from connected data sources
Data integration tools as standard
Other known compatible sources
ERP integration ready (List products)
Data mining
Intelligent Agents
Deviation analysis (e.g. discover how a case or segment differs from others)
Prediction (e.g. predict a value for a new case (such as a new customer)
based on values for similar cases (such as existing customers))
Time series analysis (e.g. predict the future)
Association (e.g. advanced counting for correlations)
Segmentation (e.g. develop a taxonomy for grouping similar cases)
Classification (e.g. assign cases to predefined classes such as "Good" vs
"Bad")
Development
Graphical interface that avoids complex language code development (eg. C

or Java)
263

Developers can customise User Presentation via cascading style sheets
(CSS)
Web Service Integration
User Documentation generator
Process Modeling - (BPEL) capability
Professional Authoring Environment (IT development staff - work with
source code -compilers)
ETL (Extract, Transform, Load)
Data modeling tool requirements (e.g. CA Erwin )
Additional/Dedicated staging hardware resources
Facilitates Slowly Changing Dimensions (indicate Type - 0, 1, 2, 3 , 4 ,
6/Hybrid)
Atomic methodology Design
Iterative cleansing process
Source system expertise
Meta data capture methodology
Performance
Control of long-running queries
Rapid query response - defined as sub-30 seconds
Provision of a query optimizer
Provision of optimization tools and server load balancing capability
Provide performance monitoring capabilities.
Provide tuning of SQL generated from tool.
Reporting
264

Ability for users to publish ad hoc reports for mass distribution
Ability to create highly formatted canned standard reports with parameter
substation
Ability to directly access multiple data structures (Normalized, Star Schema,
Multidimensional)
Ability to download subset of data and operate in a detached mode (w/o
losing functionality)
Ability to show data from multiple sources and data structures on the same
report
Administrator level report "pushing" based on event triggers
Capacity to render a report in multiple formats including HTML, XML, PDF,
CSV, XLS and others.
Client-based as well as Web/Browser integration (both HTML and JAVA)
Currency conversion
Export functionality from browser-based solution (specifically to Excel)
Export to email
Export to PDF
Export to Power Point
Export to XML
KPI speedometers and spotlighting
Microsoft Excel OLAP add-in
Nesting of data
Push report distribution
Refresh data from within Excel
Report annotation
Reports are URL-addressable for access via any web portal / browser
Style Sheet Integration
Support Stop Light Reporting
265

Supports dashboard KPI monitoring and views
Supports development level complex filters (e.g. where clauses in SQL,
using "like", "in", and "between" functions)
User report subscription including definition of when report should be sent,
format, and delivery method
WYSIWYG
Bar charts
Chart titles
Histogram
Line chart
Pie chart
Radial plot
Scatter diagram / quadrant analysis
Supports plug-in of third party graphing tools
Three dimensional graphing
Trend lines
Export to CSV
Interactive report prompts to permit multiple selection criteria
Availability of report “wizards” or templates to assist development effort
Modifiable report templates to permit customisation by user
Supports scorecard design and views
Multi-lingual Support
Ability to embed reports within a report to allow detail drilldown
Make call to external code/object
Change graphical views in real time
Exception reporting using thresholds
User defined calculations can be used as selection parameters
Security
266

Ability to create security groups with associated filters

Ability to import security profiles from standard file formats (i.e. .txt, .csv,
etc.)
Ability to set permission levels by user and/or security groups (i.e. read only
access)
Cell/Attribute level security
Integration with Microsoft Active Directory Security
Kerberos authentication
NTLM authentication
Report level security
Role based security
Row / Column level security
___________________________________________________________________________________________________________________
Note: The Business Intelligence Vendor and Application Assessment was designed based on a review of literature pertaining to features found in BI Applications, a review of
BI software selection papers and the authors own experience in software selection. Many of the features listed in Part II Product Assessment are adapted from the Business
Intelligence Software Selection Tool (Rainmaker, 2005). Other sources include Wise (2007) and Mendelsohn (2006).
267
Appendix T
Business Intelligence Vendor and Application Assessment (Proof of
Concept)
Business Intelligence Vendor and Application Assessment
Proof of Concept Assessment

As part of the selection process for a Business Intelligence Application for
________________________
Company Name
short-listed vendors are asked to provide a Proof of Concept (PoC)

presentation. This document contains the proposed contents for the
presentation and an associated grading rubric. Potential vendors should be
given the content proposal section only in advance of arranging the
demonstration.
Process
Stage 1: Supply PoC requirements to short-listed vendors

Stage 2: Arrange demonstration with vendor and BI selection team
Stage 3: Agree pre-requisites for demonstration with vendor (data
preparation/extraction/hardware/software pre-install etc.)
Stage 4: BI team perform vendor ranking of POC
Stage 5: Make recommendation
268
Does not Meets

Better than
Task Additional Checks meet Expectations Assessment Comments
Expected
Expectations
Rating
0 1 2
Security
Create an Administrator Account Assign role to account
Create End-user account Assign security level user
Data acquisition
Create a simple schema (sample data mart)
Perform ETL of data from onsite databases (e.g.
ERP/DBMS )
Load data from spreadsheets
Reporting & Analysis
Design
Design a report with drill down to lower level of detail Time Variant
Slice and Dice
Dimension Totaling
Add sub-totals to report
Add Filters to report to restrict content displayed
Customize report to add cosmetic changes - Company
Logos, icons, background graphics
Design selection screen for report

Show date selection parameter Calendar available?
Show Value selection parameter =><between, is, is not,
range, list etc.
Show value list from underlying data only Only allow selection of
values in data
269
Does not Meets

Better than
Expected
Expectations
Rating
0 1 2
Show user defined calculation as parameter Can user defined
calculations be used as
selection parameters
Show text selection Any Validation tools
available?
Report Presentation
Show report as data grid only
Show report as data grid and graph
Show report as graph output only
Resize report elements for presentation
Enhance report content - Change Fonts, emphasis etc.
Report Output
Output Report to HTML
Output report to PDF
Output report to Email
Output report to Excel
Output report to XML
Miscellaneous
Schedule report to run Assess time variants
permitted
Display data authority functionality Can you restrict access to
field, record, table, report
Change report security - end-user accessible / inaccessible Display permission and

revocation
Skills Required – Assess
270
Does not Meets

Better than
Expected
Expectations
Rating
0 1 2
Information Producer Group
IT Report Developer
Business Analyst
Power User
Information Consumer Group
Executives/Managers
Casual Users
Customer/Suppliers - Any special requirements
Training Suggested
Information Producer Group
IT Report Developer
Business Analyst
Power User
Information Consumer Group

Executives/Managers
Casual Users
Customer/Suppliers - Any special requirements
User Functionality
Menu Navigation
Screen Clarity / data presentation
Help Documentation
Report Design Process
Look and Feel
271
Does not Meets

Better than
Expected
Expectations
Rating
0 1 2
Ease of use
Installation/Deployment
Time to deploy - Build physical environment
Data repository design tools
ETL tools
Administration
Meta-data Management Tools
Resource Requirements (Time/people/hardware/software)
Performance Tuning - Discuss requirements
General
Vendor Likeability Could you work with this
vendor?
Likes
Dislikes
Gut Feel
Total Assessment (Count of points) Total:
272
Final Assessment Comment:
273

Erp

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Erp

Uploaded by

Copyright:

Available Formats

Integrating Business Intelligence with ERP

INTEGRATING BUSINESS INTELLIGENCE WITH ERP

Integrating Business Intelligence with ERP

To Improve Operational and Strategic Planning Information in

Small and Medium-sized Enterprises

Master of Software and Information Systems

The National University of Ireland, Galway in conjunction with Regis University

School for Professional Studies, Denver, Colorado.

Department of Information Technology

Head of Department: Professor Gerard Lyons

Advisor: Dr. Owen Molloy – NUI, Galway

Final Project/Thesis Submission

MSc in Software & Information Systems

Department of Information Technology

National University of Ireland, Galway

Student Name: Paula O’Hara

Telephone: 00 353 (0)87 9069535

Date of Submission: 28th August 2009

Title of Submission: Integrating Business Intelligence with ERP to Improve

Operational and Strategic Planning Information in

Small and Medium-sized Enterprises.

Supervisor Name: Dr. Owen Molloy

of partial fulfilment of requirements for the Degree Programme.

Signed: Date: 28th August 2009

understanding and support during the last two years

To my sister Maria – for being mother number two

Thank you all for helping me to fulfil my dream.

List of Tables ............................................................................................................11

List of Figures in Appendices..................................................................................17

Chapter 1 - The Thesis Statement ..........................................................................21

1.1 The Problem Statement....................................................................................21

2.6.2 BI Definitions and Purpose.......................................................................40

2.6.3 BI Trends and Good Practice....................................................................41

2.7 BI Solutions .....................................................................................................42

2.7.2 Software as a Service (SAAS) ..................................................................44

2.7.3 Open Source..............................................................................................45

2.7.4 Cloud Computing......................................................................................46

2.8 BI Approaches .................................................................................................46

2.8.2 Business Performance Management .........................................................47

2.8.3 Customer Relationship Management........................................................48

2.8.5 Scorecarding .............................................................................................51

2.8.6 Key Performance Indicators – Translating the Organization’s Strategy to

meaningful metrics ............................................................................................52

2.9 BI Implementation Considerations ..................................................................54

2.9.1.1 Online Transaction Processing (OLTP) versus Online Analytical

2.9.3 Development Considerations ....................................................................64

2.9.4 Business Environment Considerations .....................................................64

2.10 Conclusion .....................................................................................................65

4.4 Business Intelligence Use ................................................................................78

6.2.2 BI Maturity Model 2: TDWI’s Business Intelligence Maturity Model ....98

6.2.3 BI Maturity Model 3: Business Intelligence Maturity Model (BIMM)..102

6.2.4 BI Maturity Model 4: IBM’s Information Lifecycle ..............................102

6.3 Conclusion .....................................................................................................103

7.4.2 Current Process Flows ............................................................................108

7.4.3 Reports in Use.........................................................................................108

7.4.4 MIS Capability........................................................................................110

7.4.5 ERP Implementation Type and Data Characteristics .............................110

7.4.6 Data Sources (other than ERP) ...............................................................111

7.4.6.1 Integration of other data sources........................................................112

7.4.7.1 KPIs selected for trial.........................................................................115

7.4.9 Data sets in use .......................................................................................118

7.5 BI Maturity Level Assessment Pre-implementation......................................118