1

BI System

Centre for Service Research

Manchester Business School Booth Street West

Manchester, M15 6PB, UK

Sponsored by

2

Contents 1. Introduction ....................................................................................................................... 1

2. Architecture Review ........................................................................................................... 1

2.1. Data Warehouse .......................................................................................................... 2

2.2. IN-GRiD Dashboard (OLAP) ......................................................................................... 4

2.2.1. Structure and Navigation ..................................................................................... 4

2.2.2. User Interface (Page Descriptions) ...................................................................... 6

2.3. EMS System (Microsoft SharePoint 2010) ................................................................ 23

2.3.1. Structure and Navigation ................................................................................... 24

2.3.2. User Interface (Page Descriptions) .................................................................... 26

Works Cited .............................................................................................................................. 37

3

List of Figures

Figure 1. IN-GRiD data warehouse schema ............................................................................... 2

Figure 2. Physical relationship between databases in data warehouse .................................... 3

Figure 3. Deployment diagram of data warehouse ................................................................... 3

Figure 4. An overall view of CDF Dashboarding ......................................................................... 5

Figure 5. Overall structure of Dashboard .................................................................................. 6

Figure 6. IN-GRiD Dashboard main page ................................................................................... 7

Figure 7. Site & Building Summary ............................................................................................ 8

Figure 8. Inter-University Analysis ........................................................................................... 10

Figure 9. Inter-University Analysis ........................................................................................... 12

Figure 10. Geographical Analysis ............................................................................................. 14

Figure 11. Profile of a building’s electricity usage ................................................................... 15

Figure 12. Business Unit Cost Analysis ..................................................................................... 17

Figure 13. Stacked Bar Energy Profile ...................................................................................... 19

Figure 14. Daily Profile ............................................................................................................. 21

Figure 15. Microsoft SharePonit deployment diagram. .......................................................... 24

Figure 16. Data Providing Application deployment diagram. .................................................. 25

Figure 17. Overall view of EMS web application ..................................................................... 26

Figure 18. The Main Page of EMS web application ................................................................. 27

Figure 19. Condition Form snapshot ........................................................................................ 29

Figure 20. Workflow Snapshot ................................................................................................. 31

Figure 21. Task snapshot .......................................................................................................... 33

Figure 22. Data Calculation Snapshot ...................................................................................... 35

1

1. Introduction

This document provides the findings of a BI system development that take place in the

University of Manchester (UoM) as part of the IN-GRiD project funded by JISC. This

document presents the outcomes of Phase 4 of the project which summarizes the

implementation of the project. In the beginning, the integration of the buildings and utilities

data sources in the data warehouse presents. In the next step, based on the data warehouse

two main systems are developed. Firstly, Dashboard is developed by Pentaho to show not

only the energy consumption in the University but also the comparison with other

universities in the UK. Secondly, EMS process for collecting, analysing and reporting EMS

data to HESA is implemented. This web application is developed by Microsoft SharePoint

2010.

The rest of the document provides more detailed views on the implementation in phase 4.

Section 2 provides a brief description of system architecture in both software and hardware

levels; in this section, three main components of the system are described i.e. i) Data

warehouse, ii) Dashboard and iii) EMS application.

2. Architecture Review

In-GRiD project is developing a framework for improving the process of collection,

management and analysis of building profile data, building usage data, energy consumption

data, room booking data and the corresponding financial data in order to improve the

financial and environmental decision making processes of the University of Manchester. The

project consists of six phases. The summary of the first three phases are as follow:

Phase 1 concern with the data and process audit of current information

management systems used by UoM.

Phase 2 deals with the data collection and system preparation setup.

Phase 3 considers the design of a proposed business intelligence system.

Therefore, through these phases, the main data sources are identified and deep analysis

have been done on each of them. In addition, the process of collecting, analysing and

reporting EMS data to HESA is considered. The main weaknesses of the system are specified

through the user requirement for each stakeholder. The output has been already published

as “Software Architecture “report. Overall, in the implementation phase ;phase 4; three

2

main works have been done, i) integrating data sources in the data warehouse, ii)

developing Dashboard for energy consumption in the University and iii) developing an web

application for collecting, analysing and reporting EMS data to HESA.

2.1. Data Warehouse

ARCHIBUS, Coherent and Scientia are three involved databases in the current system. All

information related to building is stored in the ARCHIBUS which is an Oracle based

database. Coherent is SQL based database, in which smart metering readings are kept for

utilities consumptions. Scientia is a system used by the Central Timetabling Unit (CTU) to

manage the time tabling and booking process of centralise rooms, and from which related

values, such as, occupancy rate of rooms is collected. Data warehouse is created in oracle-

based platform in order to get advantage of existing tools in the University as well as Oracle

Discoverer tools to facilitate the queries in the data warehouse. In addition to the current

databases, a new database is created to maintain the EMS data which have been submitted

to HESA. The aim of this database is to maintain the historical EMS data submitted to HESA.

The main reason is that collected data in each year has to compare with three years

historical data in order to track any changes in the data and providing explanation for the

possible changes.

Data Warehouse

DataBase

ARCHIBUS CoherentScientia (CTU)

1

*

1

*

1

*

EMS Forms

Figure 1. IN-GRiD data warehouse schema

In order to integrate data originated from these three independent databases into a

heterogeneous system, a data warehouse is required in which updated data can be stored

3

and manage. As it is presented in Figure 1, the IN-GRiD data warehouse is designed as an

Oracle- based system and updated monthly. Every year in August the snapshot of data

warehouse will provide for EMS process and the full archive of the snapshots and data

submitted to HESA will stored in the data warehouse to provide the platform for internal

checking and analysis in dashboard as well.

Archibus System Coherent System

Scientia Syllabus Plus

Building ID

RoomID

Figure 2. Physical relationship between databases in data warehouse

In Figure 2, the physical view of data warehouse is shown. To improve the efficiency of the

designed system, all of involved databases are considered carefully and based on the

current requirement of EMS stakeholder; the association between the three databases is

established. Due to considering each database, the relationship between Archibus and

Coherent System are formed based on “Building ID” and the relationship between Archibus

and Scientia is established based on “Room ID”.

Oracle System

OLE DB Sources Audit Derived Column

Look UpAggregateMerge / Join

Basic Queries

Figure 3. Deployment diagram of data warehouse

4

The deployment diagram of data warehouse is shown in Figure 3. Main components of pre-

processing and audit include functionalities like data quality audit, derived node,

aggregation, merge-join, look up and other basic queries.

2.2. IN-GRiD Dashboard (OLAP)

In the context of Business Intelligence, a dashboard is an application which is used to

present high-level BI content to the end users. IN-GRiD dashboard is providing graphical

view of energy consumption in the University. Target users are management board, staffs,

students and external users. Users can drill down to more detailed for buildings as well as

comparing different buildings’ usage together. In addition, it is possible to have Inter-

University analysis and compare UoM with a specific university in the UK.

2.2.1. Structure and Navigation

The Community Dashboard Framework (CDF) is introduced by Pentaho Solution which is a

set of open source technologies that allows BI developers to build dynamic dashboards for

the Pentaho BI Server. CDF dashboards are essentially web pages that use AJAX technology

to dynamically combine BI components such as reports, charts, OLAP tables, and maps.

Dashboard is a set of web pages built on the base of technologies such as HTML, CSS,

JavaScript and using AJAX built on JQuery. There is a set of pre-defined documents and

content templates that are actually HTML files. Each page of dashboard contains different

HTML placeholder to display their components’ content. All CDF dashboard requests are

handled by a plugin that assembles the response from document template and content

template. CDF concepts and architecture is presented in Figure 4 (Bouman & Dongen, 2009).

Based on the Pentaho BI platform and its facilities, IN-GRiD Dashboard is developed to

highlight the energy consumption in the University and also in compare to other universities

across the UK. To facilitate comparison in between schools across the University and also in

compare with other universities; the ratio of CO2-KWH per square meter is used as a metric.

Target stakeholders are University management board, staff, student and external users.

5

Figure 4. An overall view of CDF Dashboarding

6

2.2.2. User Interface (Page Descriptions)

The overall structure of IN-GRiD dashboard is simple, as shown in the Figure 5. There are

three primary elements in the site, and each of these may be accessed directly from the

main page. The overall aim of the IN-GRiD dashboard is providing visualization frame of

utilities’ consumption in the University in three main level i.e. i) University level, ii) Inter-

Universities level and iii) Business unit details. Each section drills down to more details and

provide required comparisons in order to specify the utilities’ consumption across the

University and also in compare to other universities in the UK.

A. Main Page

B. Site & Buildings Summary

C. Inter-University Analysis C1. Comparing Specific University with UoM

D. Business Unit Detailed Report D1. Geographical Analysis

D2. Profile of a building’s Electricity Usage

D3. Business Unit Cost Analysis

D4. Stacked Bar Energy Profile

D5. Daily Profile

Figure 5. Overall structure of Dashboard

7

A. Main Page

Figure 6. IN-GRiD Dashboard main page

The main page contains three main elements and each of them is accessible directly from

the main page. After running each of them, they open in a new tab. In addition,

8

B. Site & Building Summary

Figure 7. Site & Building Summary

9

After selecting “Site & Building Summary”, this page will open in new Tab as it is shown in

Figure 7. Five main parts are included in this page as described below:

Part A: In this part, there is an option to select the comparison period. In addition, there is

drop-down list called Group which allow us to select the BU (Business Unit) which could be

“Balance”, “Central”, “”Faculties” or “Other” option.

Part B: BU (Business Unit) is shown in Part B. There is an option to choose the metric for

comparison included “Energy kg CO2 Per Sqr Meter”, “Energy KWh Per Sqr Meter” and

“Energy Per Sqr Meter”. In snapshot shown in Figure 7, Eenrgy KW per Sqr Meter is

selected. For each BU, the amount of energy consumption is shown. Moreover, by click on

pdf icon, the detailed report will be provided that can be exported in different formats.

Part C: Business Entity: In addition, after selecting BU unit, all of the schools in the Business

Unit will show in the placeholder ‘C’ with their energy consumption per defined metric. The

amount of energy consumption and horizontal bar chart will provide visualized comparison

between Business Entities.

Part D: BU Comparison: The BU Comparison component will show the comparison line

graph of selected BU units in the selected period.

Part E: Entity Comparison: Same as BU component, there is opportunity to select different

schools and present their energy consumption line graph in Entity Comparison placeholder.

10

C. Inter-University Analysis

Figure 8. Inter-University Analysis

11

Another important feature in the IN-GRiD dashboard is Inter-University comparison which is

accessible directly from main page. In this page, there are three main part described below:

A: As first step for comparison, we should select the appropriate period of comparison

which is provided as drop-down list in this section.

B: List of universities in the UK with their previous and current energy consumption is

presented as well as the variance of these two values for each university.

C: After selecting preferred universities for comparison, the compare chart will appear

below the table. For example, in Figure 8 the Inter-University analysis for year 2009-2010

has been presented. The chart in figure 8, presents comparison between the University of

Manchester, The Manchester Metropolitan University and Liverpool John Moores

University.

12

C1. Comparing Specific University to UoM

Figure 9. Inter-University Analysis

13

Another type of analysis is comparing energy consumption between UoM and another

university which can be done from Inter-University analysis page. Figure 9 shows the

comparison of energy consumption between UoM and a selected university with more

details. The comparison is shown for all categories of energy consumption such as Oil, Gas,

Electricity, Coal, Hot water and total energy consumption. For example, in Figure 9, the

comparison has been shown between UoM and The Manchester Metropolitan University. It

can be clearly seen that the Energy consumption steam in UoM is very high but the energy

consumption Oil is less than the Manchester Metropolitan University.

14

D. Business Unit Detailed Report

The analysis in this section are designed to show opportunities for more analysis of

obtained data in datawarehouse.

D1. Geographical Analysis

Figure 10. Geographical Analysis

The aim of geographical analysis is to provide an overview of buildings with their overall

utilities consumption. The colour of each building can show how green is that building. In

addition, the bar chart in right side provides floor usage for the selected building. This idea

can be develop to have the overall view of the University buildings’ total consumption, the

comparison of floor energy usage for a selected building.

15

D2. Profile of a building’s electricity usage

Figure 11. The profile of electricity usage for a building throughout a day. The profiles are averaged within months to show the effect of daylight and term time impact.

16

The analytic technique in Figure 11 shows the profile of electricity usage for a building

throughout a day. The profiles are averaged within months to show the effect of daylight

and term time impact. As a consequence of term time as well as impact of season’s weather

in energy usage, this profile can help to investigate the electricity usage for a building.

17

D3. Business Unit Cost Analysis

Figure 12. Business Unit Cost Analysis

18

Figure 12 shows the concept of electricity costs being allocated across Cost Centres. Data

Integration techniques have enabled the raw meter data to be attributed to an organisation

Hierarchy. The inclusion of Energy per Sq M highlights efficiency issues.

19

D4. Stacked Bar Energy Profile

Figure 13. Stacked Bar Energy Profile

20

Simple graphical techniques such as this 100% stacked bar chart easily show the relative

usage of electricity within Business Units.

21

D5. Daily Profile

Figure 14. Daily Profile

22

Figure 14 shows daily energy usage for selected buildings. This kind of analysis between

different business units can help to investigate energy consumption for different buildings.

This can also highlight an obvious data issue with one building.

23

2.3. EMS System (Microsoft SharePoint 2010)

One of the main processes in the University is collecting, analysing and reporting

information to HESA. The main stream of this data is student/staff counts, finance, building

area (internal and external), condition, policy, and energy data. The three major buildings,

energy and condition forms are directly worked with IN-GRiD data warehouse. After few

semi-structured interview with a director of Estate team who is responsible for this task, we

found data items related to environmental and sustainability performance were manage

locally by different stakeholders using ad hoc systems. Consequently, a significant part of

the effort of the IN-GRiD project was dedicated to the creation of corresponding SharePoint

templates and workflows that replaced the previously human-driven EMS collection

processes. Integrating the process, decreasing the manual process, increasing the process

transparency, secure future data quality and maintaining the system over time are part of

the system advantages.

A number of Microsoft SharePoint 2010 advantages are listed as follow:

Available in UoM

Compatible with other Microsoft-based applications

Less coding (from developer perspective)

Implementing Security and accessibility to the data more easily

Providing flexibility for communication between different kind of users by setting up

the workflow

Compatible with Microsoft Office applications

No direct communication with database

Easily manage documents and help ensure integrity of content

Build a collaboration environment quickly and easily

Provide a cost-effective foundation for building Web-based applications

24

2.3.1. Structure and Navigation

Microsoft SharePoint 2010 provides a convenient way for people to work together. By using

SharePoint, we set up a web application to share Information, manage documents,

integrating data collection and analysis from start to finish and publish the report to help all

stakeholders to access to more reliable data, get more accurate information and make

better decision. Figure 15 shows the Deployment diagram for the Microsoft SharePoint

module. There are two main components, namely data providing application; and

SharePoint Workflow. Both components work closely together. SharePoint Workflow will

control the process by using the necessary time stamps during the process; and data

providing application mainly designs and implements connecting links to communicate with

end users.

SharePoint

Data-Providing Application

SharePoint Workflow

Figure 15. Microsoft SharePonit deployment diagram.

Figure 16 shows Data Providing Application deployment diagram. Report component allows

end users to access to various type of report. Report can be exported as XML or EXCEL

format. The final report to be submitted to HESA is generated automatically in a specific

time. In addition, based on the end-users privilege, each stakeholder has access to the part

of the proposed system. Dashboard will be designed as a tool for analytical and monitoring

purposes which includes comparisons, history, along with high level of performance

evaluators and forecasts. Number of building categories per year and building condition

analysis per year are examples of analysis.

25

Data Providing Application

Report Data Entry Form Dash Board Analysis and Forecasting

1*

1*

1*

1

*

Export report

Providing HESA reportData Validation

1

*

Figure 16. Data Providing Application deployment diagram.

Data entry forms are fundamental for the system regarding to establishing most of users

communication with system. Data validation component is embedded in data entry form to

implement checking the quality of entered data. Utmost of the internal checking which has

been done manually now is included in data validation component.

It should be noted that Microsoft SharePoint does not support creating form initially. In

order to design the necessary forms, Microsoft InfoPath 2010 and Microsoft Visual Studio

2010 64bit are used and then the forms are deployed to the SharePoint environment which

are. In addition, Microsoft SharePoint designer 2010 is used in parallel to develop relevant

workflows.

26

2.3.2. User Interface (Page Descriptions)

The overall structure of EMS web application is simple, as shown in Figure 17. The focus is in

EMS-Estates which contain three main forms and their related workflow, assigned tasks and

other forms for data calculation. In this report, due to similarity of forms, only Condition

Form and its relevant components is described in details.

A. Main Page

B. EMS-Estates

C. Stakeholders

D.Management Board

B.1 Condition Form B.1.1 Workflow

B.2 Buildings Form

B.3 Energy Form

B.2.1 Workflow

B.3.1 Workflow

B.1.2 Tasks

B.2.2 Tasks

B.3.2 Tasks

B.1.3 Data Calculation

Figure 17. Overall view of EMS web application

In stakeholders and Management Board pages, further information, queries and analysis

related to EMS-Estates will be fulfilled.

27

A. Main Page

Figure 18. The Main Page of EMS web application

28

The main page for EMS application is presented in Figure 18. All users after login will see

same main page but they are restricted to access to all parts of application based on their

user role in the system. For instance, administrators group has access and full authority to

all part of application including assigning roles to users and set up different forms and

workflow. In the other hand, EMS stakeholders which are in normal user category just can

access to their assigned forms and task, apply specific queries and get the relevant reports.

In the main page three main menu are accessible i.e. i) EMS-Estates, ii) Stakeholders and iii)

Management Board. EMS-states page is the main part of developed system. In Stakeholder

page necessary documents related to EMS data collection will be gathered as well as the

search facility to obtain further reports based on their right to access data in the data

warehouse.

B. EMS-Estates

The main purpose of EMS web application is data collection, process, check in and preparing

required report to submit to HESA. This page contains three subpages for condition, energy

and buildings forms.

29

B.1 Condition Form

Figure 19. Condition Form snapshot

30

The EMS condition form contains 24 attributes which has to fill with 4 different

stakeholders. Form contains the name and code of attributes as well as three years

historical data. The value field and Accurate/Estimate option will fill by relevant stakeholder

later. In Stakeholder column there is a drop-down list for assigning stakeholder to each

section of form and also “Value Calculation” button which is used by stakeholders in their

calculations.

From administrator view, administrator can deploy the form to condition page in Microsoft

SharePoint 2010 environment. Then, after assigning stakeholder to each part, submit the

form (The button on top of the form). In addition, administrator can set a workflow and

tasks to each stakeholder and send the necessary documents and calculation method notes

to each of them. Workflow and tasks are described in the following sections.

In following of the process, each stakeholder can see the form but only their assigned part is

active for them. So they can enter the value and identify the accurate or estimate method of

calculation or they can click in “Value Calculation” button which will open another form(s)

for them to help them in their calculations. This form(s) is explained in section B.1.3.

31

B.1.1 Workflow

Figure 20. Workflow Snapshot

A

B

C

32

One of the administrator tasks is setting up workflow into the specific form. Workflow will

help to track the process of data collection. Administrator will assigned relevant

stakeholders to workflow and specify duration for doing the task. Workflow will finish based

on two conditions i.e. i) all stakeholders do their assigned task, submit the form and finalise

the approval process or ii) the duration finish automatically.

Figure 20 shows the sample of workflow which is assigned to Condition Form. Generally,

workflow contains workflow visualization, tasks and workflow history. In task section, it can

be clearly seen that task (workflow) is assigned to whom and track of all changes in the

process can be seen in workflow history.

Part A is showing workflow visualization. In this part all of users who assigned to the current

workflow are shown.

Part B is presenting tasks section. It can be clearly see that task(s) are assigned to whom,

their due date, status of their progress and outcome.

In Part C, the workflow history is presented. In this section, we can track all the setting from

first step of assigning task, Users attempts, and the changes in process can be seen in this

part.

33

B.1.2 Tasks

Figure 21. Task snapshot

34

After setting a workflow, there is an option to assign various tasks separately to each

stakeholder. Administrator can create tasks; attached relevant documents; define the

priority of task and task duration. Then, all users can see their assigned tasks; they can also

set a task and define different status like “not started”, “in progress”, “completed”,

“deferred” and “waiting for somebody else” and provide additional description for the

responsible person. Figure 21 displays a sample of assigned task to one the stakeholders.

35

B.1.3 Data Calculation

Figure 22. Data Calculation Snapshot

36

In user view, users can fill only their assigned part. They can enter data straightaway in value

fields they can get help from system by click on Value calculation button. In this stage,

another form will display which is designed based on the user requirement analysis and the

method of their calculation by using different sources. In this form, user can do their

calculations, and after verifying them, send the values back to the main form. The purpose

of this form is to improve the accuracy of value calculation by integrating all the process in

Microsoft SharePoint platform. Reducing manual tasks, transparency of calculation methods

and maintenance of the system over time are other advantages of the system.

37

Works Cited

Bouman, R., & Dongen, J. (2009). Business Intelligence and Data Warehousing with Pentaho

and MySQL. Wiley Publishing, Inc.