Project Brief

EST109 - Estates Strategic Reporting – Space & Maintenance Mgmt

 

  1. Document Version Control

Version No

Contents

Date Created

Author

Comments

V0103

Approved Brief

13/05/2016

Chris Lawford

Original project brief approved.

V0104

Modified draft

02/08/2017

Chris Lawford

Major revision, following re-boot of project.

V0105

Modified draft

13/09/2017

Chris Lawford

Revision, following comments made by stakeholders on published draft. 

V0101

EST093 V05 copied to EST109 V01

26/09

Chris Lawford

Project code number change.

Final comments added.

 

  1. Document Sign-off

Name

Project Role

Date Signed Off

Comments?

Adamson, Karen

Sponsor  

14/09

See document revision details table. 

Brown, Kristina

Estates Data Steward  

 

 

Fiddes, Iain

Senior Supplier

 

12/09

See document revision details table. 

Finnan, Anne

 

Apps Mgmt

 

 

Granum, Geir

Apps Dev Lead

 

12/09

See document revision details table. 

Henderson, Gillian

 

Dev Tech Lead

 

 

Kraan, Wilbert

Enterprise Architecture

 

 

 

Larnach, Heather

 

Tech mgmt Lead

 

 

Manley, Rob  

Apps Dev Lead

12/09

No

Mann, Richard

Business lead, space mgmt

 

 

 

Matheson, Derrick  

Estates IS Programme Manager

08/09

No.

McFarlane, Andrew  

Service Mgmt Lead

08/09

No.

Pritchard, Colin

Business lead, Maintenance Mgmt

12/09

No.

 

 

  1. Project History

This project is a continuation of EST093 Estates Strategic Reporting. As the scope of the project is considerably clearer than it was back in April 2016, it has been decided to create a new project EST109 to cover the remaining activities.

The EST093 project brief was originally created in May 2016. The planning phase was completed and two pieces of business analysis were completed and signed-off. In December 2016 the project was put on hold for a number of reasons (resource constraints, changing business drivers, emerging EDW programme). As a different landscape emerged, the project was re-booted in June 2017.

Based upon the current situation, the brief and associated artefacts have undergone a major revision. This document supercedes all previous versions of the brief.

To refer back to the original brief, use the following link –

 https://www.projects.ed.ac.uk/project/est093  

  1. Scope

The scope of this project is to deliver a strategic reporting solution for the following:

  • Space Management. Covers the definitions and relationships between buildings, floors and rooms.
  • Maintenance Management. Covers the activities of the hard services organisation when executing the on-going planned and reactive maintenance of the University’s 550 buildings. This covers approximately 60,000 reactive maintenance tasks and 30,000 compliance tasks per annum. The initial key reporting requirements centre on workload, performance & productivity, cost, and maintenance trend analysis.

The solution in question will include:

  • A set of agreed, certified reports.
  • The provision of an ad-hoc query capability to a limited number of suitably trained users, giving them the ability to extract data and generate their own custom analysis and reports.

The solution will utilise existing BI/MI services (SAP BI Suite), but based on a new capability; the Enterprise Data Warehouse (EDW).

The creation of the space and maintenance management subject-areas will not only serve the requirements of this project, but also act as a guiding light for all future Estates Management Information, Business Intelligence and strategic reporting projects.

  1. EDW

EDW is being delivered by a dedicated programme; part of the Digital transformation initiative (DTI).

For further information refer to the following link:

https://www.projects.ed.ac.uk/programme/dtiedw

This project has a strong dependency on the overall EDW programme, and is considered to be an ‘early adopter’ of its services. This will has its advantages and disadvantages as detailed later in the document.

The foundation layer within EDW will not actually contain a segregated storage area for Estates data; All EDW data will be stored in such a way that encourages links and relationships between datasets to be made.

The eventual aim (requiring further business data acquisition projects) will be to store all the important Estates data required to drive business intelligence and decision making both within Estates and across the University.

This following diagram provide a visual representation of the BI/MI landscape that will be enabled by the EDW programme. 

 

Landscape V0101 07/04/2017 @ CJL)

 

  1. Objectives and Deliverables

O

D

Outputs / Associated Deliverables  

Prty*

Primary Responsible

Also Involved

O01

 

Business Analysis

 

 

 

 

D01

Space Mgmt Business Analysis

The analysis was initially created and signed off August 2016. This analysis will be refreshed, and will also make use of the new BI/MI analysis toolkit, being produced by project DTI019.    

Link to original document:

K:\ISAPPS\csg\projects\EST109 Strategic Reporting\25 Business Analysis\10 Space Mgmt\ EST109 Space Requirements Document V0101.doc

M

Project Services

 

 

D02

Maintenance Mgmt Business Analysis See D01 above. Link to original document:

K:\ISAPPS\csg\projects\EST109 Strategic Reporting\25 Business Analysis\20 Maintenance Mgmt\EST109 HelpDesk Requirements Document V0101.docx

M

Project Services

 

O02

 

Technical Design

 

 

 

 

 

D03

Space Mgmt Data Design Part of Application and Data Architecture (ADA) document.

M

Enterprise Arch  

 

 

D04

Maintenance Mgmt Data Design. Part of Application and Data Architecture (ADA) document.

M

Enterprise Arch  

 

 

D05

Space Mgmt SDS  

M

Apps Dev

 

 

D06

Maintenance Mgmt SDS

M

Apps Dev  

 

O03

 

EDW Foundation Layer

 

 

 

 

D07

Space Mgmt Foundation Layer  

M

Apps Dev

Enterprise Arch

 

D08

Maintenance Mgmt Foundation Layer  

M

Apps Dev

Enterprise Arch

O04

 

EDW Access Layer

 

 

 

 

D09

Space Mgmt Access layer(s)  

M

Apps Dev

Enterprise Arch

 

D10

Maintenance Mgmt Access layer(s)  

M

Apps Dev

Enterprise Arch

O05

 

Semantic Layer

 

 

 

 

D11

Space Mgmt SAP/BI suite Universe(s)  

M

Apps Dev

 

 

D12

Maintenance Mgmt SAP/BI suite Universe(s)  

M

Apps Dev

 

O06

 

Presentation Layer

 

 

 

 

D13

Certified Space Mgmt Report(s)  

M

Service Mgmt

 

 

D14

Certified Maintenance Mgmt Report(s)  

M

Service Mgmt

 

O07

 

Training

 

 

 

 

D15

SAP/BI suite Training & Access

S

Service Mgmt

 

O08

 

Organisation & Support

 

 

 

 

D16

The adaptation of the Estates organisation and processes to encompass local support for a BI/MI service(s), within the overall Service management framework.  

S

Estates

Project Services

 

D17

Service Mgmt: The inclusion of support for Estates within the overall Service mgmt BAU capability.  

S

Service Mgmt

Estates

O09

 

De-commission preparation for Existing Space Mart Solution

 

 

 

 

D18

De-commission process  

M

Apps Dev

Apps Mgmt

 

D19

Parallel run: Existing solution vs. new solution  

M

Apps Mgmt

Estates

 

  1. Out of Scope

 

What

Details

OS-01

Provision of a separate DW Infrastructure platform for Estates.  

The Estates solution will be built entirely using the EDW platform.  

OS-02

Operational Reporting

Operational reporting will be provided as part of project EST092 and other, follow-on projects. For a comparison of the differences between operational and strategic reporting, see appendix.

 

OS-03

Provision of MI Dashboards

Dashboards will not be provided as part of this project.  

OS-04

Solving data quality issues within Estates operational systems. 

The project is likely to highlight data quality issues within Archibus and other source systems. The rectification of these data quality issues is outside the scope of this project.  

OS-05

Removal of existing Estates ”Space Mart” solution

The existing Space mart solution will be de-commissioned in live as a consequence of this project but NOT as part of it. The de-commissioning work will be a small apps mgmt task and outside the scope of this project.

 

  1. Benefits

 

What

Details

BE-01

Improved business intelligence regarding hard service maintenance mgmt operations.  Improved ability to drive customer satisfaction and efficiency.  

Workload

Volumes and value of work being managed – operational (live), strategic (archived)

Performance

Number of jobs meeting or missing SLA targets

Productivity

Number of visits per craftsperson per productive period

Cost

Cost spent per work stream, e.g. fire alarm activity, or work team or member of staff

Trend Analysis

Reviewing repeated maintenance activity, per location, asset, work team.

 

BE-02

Improved business intelligence regarding space mgmt; more regular reporting available.

Improved capability for driving the efficient use of space.

    

 

BE-03

An enabler for the combination of space data with financial data so that authoritative “cost per unit area” data is readily available.

 

 

BE-04

The EST109 project establishes a precedent and repeatable process for all subsequent business data acquisition projects, both in Estates and across the University.

This will drive the creation of a set of project mgmt guidelines, a deliverable via the EDW programme.

 

 

 

More business benefits from Colin/Richard/Karen?

  1. Project milestones

Milestone

Date

Governance Milestone?

Details

1. Project re-planning complete  

04-Aug-2017

Yes

 

2. Business Analysis refresh complete  

09-Oct-2017

No

 

3. Design complete  

22-Dec-2017

No

 

4. Acceptance Sign-off review (ASOR)

19-Apr-2018

No

Dependent upon the EDW Test environment available (DTI006).  

5. Deployment DSOR

04-May-2018

Yes

Dependent upon the EDW “Production Ready” programme milestone being reached (DTI006).

6. Project Close  

28-May-2018

Yes

 

 

 

 

 

 

  1. Priority and Funding

This is a priority two project, funded by Estates.

The initial EST093 budget was 200 days, with 72 days being spent to date (to 22-09-2017). This means that 128 days have been nominally transferred to project EST109.

EST109 is estimated at 240 days. Therefore the overall provision of estates strategic reporting across both projects is estimated at 312 days.    

In addition, an estimated £20k is required for external consultancy services. This breaks down into

  • £15k for the Business Analysis refresh. We are collaborating with project DT019 “BI/MI Analysis Toolkit” in bringing an external consultancy improve our MI/BI analysis processes and outputs and at the same time refresh with existing analysis documents completed in May 2016.
  • £5k for consultancy on solution design.

See the estimating work sheet for further information

  1. Impact and Dependencies.

The project is dependent upon capability being provided by the EDW programme, in particular DTI006 “EDW Implementation”. This project will build the core infrastructure platform and service in order to achieve the “EDW production Ready” Milestone. Refer to the following link for further information (insert link)

This project will require an Extract-Transform-Load (ETL) tool in order to build the processes that populate the foundation and access layers with operational data. EDW Projects DTI004 (ETL Tool Procurement) and DTI005 (ETL Tool Implementation) are delivering this tool, but it’s not planned that the capability will be delivered in time for this projects timelines. Therefore it’s likely that the ETL processes will be built using another method.

  1. EDW Early Adoption

We have agreed that the project work for EST109 will run in parallel with the project to build EDW (DTI006) and it’s likely that EST109 will be the first live implementation and an “early adopter” of the EDW service.  

This is likely to have a number of advantages/disadvantages.

Advantages

Disadvantages

A01. Estates benefits realisation is as early as possible.   

 

D01. Heavy dependency upon the deliverables of project DTI006.

A02. Project gets more resource focus than is likely if competing against other, higher priority initiatives (student systems, service excellence, core system upgrade).    

D02. ETL processes may be developed using a tactical tool, rather than a strategic one. This may lead to future support issues and/or additional future costs in migrating to the strategic ETL platform.

    

A03. Estates have the opportunity to become ambassadors for the new BI/MI service across the University and beyond.  

 

D03. EDW environments are new, and may be subject to change / unavailability at short notice. A degree of flexibility and understanding is required from the project team.

  

 

D04. As the technology is new, there will be an inevitable learning curve within the development organisation. This will lead to longer development tasks and higher costs for early adopters. This has been built into the project plan.  

 

  1. High Level Work Breakdown Structure

 

 

Phase

Activity

Task

A

Planning 

 

 

A01

 

Project Brief 

 

A02

 

Planning Sign-off

 

B

Business Analysis

 

 

B01

 

Space Mgmt

 

B02

 

Maintenance Management

 

 

 

Analysis sign-off

 

C

Technical Design

 

 

C01

 

Space Mgmt Data Design

 

C02

 

Maintenance Mgmt Data Design

 

C03

 

Space Mgmt SDS

 

C04

 

Maintenance Mgmt SDS

 

D

Build (EDW)

 

 

D01

 

Build Space ETL

Source -> Foundation

Foundation -> Access

D02

 

Build Maint ETL

Source -> Foundation

Foundation -> Access

E

Build (BI)

 

 

E01

 

Create Space Universe

 

E02

 

Create Maintenance Universe

 

F

Build (Reports)

 

 

F01

 

Build Space Report(s)

 

F02

 

Build Maintenance Report(s)

 

G

Training

 

 

G01

 

SAP BI Suite training for Estates

 

H

Test

 

 

H01

 

Create Integration Test Plan

 

H02

 

Execute Integration Test

 

H03

 

Create UAT Test Plan

 

H04

 

Execute UAT

 

H05

 

ASOR

 

I

Organisation

 

 

I01

 

Establish Estates BI Super-user  

 

I02

 

Service Mgmt preparation

 

J

Deployment

 

 

J01

 

DSOR

 

J02

 

Go Live

 

K

De-commission Space Mart

 

 

K01

 

Create de-commission process

 

K02

 

Prove de-commission process (DEV)

 

K03

 

Parallel run existing vs. New

 

L

Close

 

 

L01

 

Project Completion Report

 

L02

 

Handover BAU support to Service Mgmt

 

L03

 

Project Close

 

(WBS will act as input into the estimating workshop).

 

 

  1. Pre-Requisites

 

What

Details

1

Estates must provide strong and clear sponsorship and business leadership.  

Due to the nature of BI / MI style projects, success requires strong collaboration between IS and the business.   

The appointed Sponsor must engaged and available to assist the business lead and project manager when issues and escalations occur.   Will act as the ultimate decision maker within Estates.   

 

2

There must be strong and detailed involvement from various subject matter experts within the Estates dept.  

Due to the nature of BI / MI style projects, success requires strong involvement from Estates subject matter experts.

 

The appointed Business leads must also be engaged and able to broker agreement and take decisions on behalf of the whole of Estates. The business leads must have a direct line to the sponsor.  

3

Delivery of Enterprise Data Warehouse infrastructure via project DTI006.

The delivery of this project is dependent upon the delivery of DTI006.

 

4

The availability of specialist skills required to successfully execute a DW / MI / BI project.

 

We are establishing the core skills and expertise as part of the EDW programme.   

 

It’s important for both Estates and EDW to allow the key resources to have sufficient time to work in both areas.

 

 

 

 

  1. Assumptions

 

 

What

Details

A01

Project will use the standard university BI/MI toolset e.g. BI Suite  

This has been confirmed. Although the new BI/MI tools modernisation programme will be initiated during 17/18, it is not expected that this will impact this project.  

The existing investment in SAP BI Suite mean that it couldn’t be replaced within a 3-5 year horizon.      

A02

Estates are permitted to access and use data not owned by Estates (e.g. finance data in held eFinancials).  

The role of the data steward has been defined.   

A03

Estates will establish a BO reporting specialist-user function to enable self-service reporting capability.   

- Likely to start with 2-3 people, covering space and maintenance.

- Responsible for support for BI across Estates – initially SAP BI-Suite but later to cover other tools.

- Responsible for ad-hoc reporting, creating and publishing “non-certified” reports for other Estates BI consumers.   

 

 

 

  1. Constraints

 

 

What

Details

C01

Data Frequency

The ETL process can be computer resource intensive and may be constrained by operational system service availability or performance considerations.   It is “usual” to extract operational data no more frequently than daily, normally during non-service hours.

 

C02

Data Latency

All reporting will be constrained by the frequency of the ETL process. For example, if the ETL process for an operational system runs daily, then any resultant reports will show data that is up to a day old. 

 

C03

Data Granularity

All reporting will be constrained by the granularity present within the extracted data.

For example, if data is extracted at a summarised level, then reporting can only be conducted at a summarised level.

 

It is therefore usual to extract operational data at the most detailed level possible. Summaries and totals can then be created within EDW.  

C04

Data Quality

The accuracy and quality of the strategic reporting provided can only be as good as that of the source operational systems. A project of this nature is likely to uncover and highlight any data quality issues with its source operational systems, or with the way data is loaded into the DW. This may require operational business processes to be adapted, or one-off data clean-up activities to be undertaken.      

 

 

 

  1. Risks

 

 

Title / Description

Probability* Impact** /

Management Approach / Mitigating actions

R01

Lack of availability of specialist BI/MI IS skills

 

There is a risk that there will be delays in the design / build process of the DW, due to the lack of  specialist BI/MI skills being made available to the project, leading to overall delays in delivery, or compromises in the design of EDW. This has been noted as a key challenge for the IS organisation.

Medium/ Moderate  

REDUCE.   

1) Work with IS resourcing to ensure the skills required are available to the project.

This is in conjunction with the EDW programme. 

R02

Lack of detailed business requirements

 

Due to the nature of MI/ BI there is always the possibility that detailed and objective requirements may be difficult to create.  

Low/ Moderate  

REDUCE. 

1) Prepare and agree the involvement of the business up front, to ensure enough thought is put in at analysis level.

2) Build the subject areas as flexibly as possible. Accommodate as many data elements as feasible within the design, even if there is no immediate requirement.

R03

Lack of Business Leadership

 

Strong business leadership is essential in any BI/MI project.  This is at both Sponsor and business lead level.

 

Medium/ Moderate

REDUCE.  

1) Prepare and agree the involvement of the business up front.

 

R04

Lack of Business Involvement

 

Estates must adequately engage with the project at the subject matter level. This will require the business experts to spend time in workshops and other project driven activities.   

Medium/ Moderate  

REDUCE.

1) A separate business resource estimate will be prepared and form part of the sign-off for the next phase.

R05

Temptation to take short cuts

 

Building a reliable, scalable and lasting Data Warehouse requires time and effort to be expended in the creation of the basic building blocks. There is always a temptation to take short cuts to speed up delivery at the expense of long term goals.  

Low/ Moderate

REDUCE. 

1) Gain buy-in to the concept of EDW.

R06

Changes to Project scope

 

Due to the difficulty in creating objective business requirements, the project may be liable to scope change. The plan needs to be flexible enough to accommodate this.  

Medium/ Moderate

REDUCE.

1) Design & Build the ETL process as flexibly as possible. To accommodate as many data elements as possible, even if they do not all get stored within the foundation layer.

2) Design & Build the foundation layer as flexibly as possible, capturing as much captured data as is reasonable.

3) Design & Build the access, semantic and presentation layers as flexibly as possible. Accommodate as many data elements as feasible within the design, even if there is no immediate requirement.

 

R07

Delivery of the EDW infrastructure platform

 

The initial EDW capability is being delivered by project DTI006 and there are numerous and substantial dependencies between the two projects.   

 

Medium/ Major

REDUCE.

R08

Strategic ETL Tool is not in place.

 

Very High/ Minor

ACCEPT

 

 

 

 

* Probability is rated Very Low/Low/Medium/High/Very High ** Impact is rated Insignificant/Minor/Moderate/Major/Severe  

(Risks will be updated on the projects website at the project brief approval stage.) 

 

 

  1. Stakeholders & Communication Plan

 

Who

Brief Sign-off Required?

Role

Communication Plan

Adamson, Karen  

Y

Sponsor

Senior Stakeholder

Berry, Dave  

N

IS Enterprise Architecture

Interested 3rd Party

Brown, Kristina

Y

Estates Data Steward

Senior Stakeholder  

Carter, Alex  

N

IS Service Mgmt

Interested 3rd Party

Fiddes, Iain  

Y

Senior Supplier

Senior Stakeholder

Finnan, Anne  

Y

Apps Mgmt Lead

Project Team

Granum, Geir  

Y

Dev Apps (BI) lead

Project Team

Henderson, Gillian  

Y

Dev Tech Lead

Project Team

Heyn, Ana

N

Apps Mgmt Lead  

Project Team? (I have asked Ana H, Anne F  to confirm if they both wish to be part of the project team).

Kraan, Wilbert

Y

Enterprise Architecture Lead  

Project Team

Lang, Mark  

N

Dev Tech manager

Interested 3rd Party

Larnach, Heather  

Y

Tech Mgmt Lead

Project Team

Lawford, Chris  

Y

Project Manager

N/A

Lee, Bill

N

Apps Dev Manager  

Interested 3rd Party

Ma, Defeng  

N

Apps Dev Manager

Interested 3rd Party

Manley, Rob  

Y

Dev Apps Lead

Project Team

Mann, Richard  

Y

Business Lead

Project Team

Matheson, Derrick  

Y

Estates Programme Manager

Senior Stakeholder

McFarlane, Andrew  

Y

Service Mgmt Lead

Project Team

McLeod, Ron

N

IS Subject matter expert for existing space mgmt solution  

Interested 3rd Party

Pritchard, Colin  

Y

Business Lead

Project Team

 

 

Communication Plan

Details

01

Senior Stakeholder

- Receives Monthly Project report

- Receives regular updates from Programme Manager  

02

Project Team  

- Attends regular team meetings

03

Interested 3rd Party  

- Receives Monthly Project report

04

Inter project dependency

- Regular catch-up meetings between PMs

(To be transferred to project website upon approval of brief)

 

 

 

  1. Appendix A: Potential Candidates for Scope

The following subject areas were considered as candidates for inclusion (May 2016). Space Mgmt and maintenance mgmt were confirmed as the two subject areas to take forward as scope for this project (June 2017). This table is therefore included for information only.  

 

Subject Area

Prty

Details

1

Space Mgmt

HIGH

Upgrade and/or re-engineer existing Space Mart solution, in support of :- 

- Estates space mgmt.

- Resource Allocation Model (RAM) in development by Governance And Strategic Planning (GASP) - Enabler for Estates Mgmt Record (EMR) process. - Potential use of timetable data for more accurate RA2018 reporting.

 

Gasp have confirmed that 2017/2018 RAM process will use the existing space model.

 

2

Maintenance Mgmt

HIGH

Create a data mart to support performance mgmt. and decision making of the new helpdesk and maintenance workflows.

 

It may be that part of this requirement will be satisfied as part of EST092 Operational reporting.  

3

Finance Mgmt  

MED

Financial data is already available as part of the enterprise DW.

For estates, summary data is extracted, and then manipulated for reporting and control purposes.

 

However, the underpinning detailed financial data is in Archibus, and there needs to be a way of cross referencing one to the other.

NB. There is a danger that 2 different (but related) flows of data could show different results e.g.

a) Summary:  Archibus -> eFin -> ESSA

b) Detail: Archibus -> ESSA?  

4

Energy Mgmt  

LOW

Monitoring & Targeting (M&T) Operational System is Optima, currently under review (May 2016).

 

Optima can provide extensive reporting (operational, strategic) out of the box.

It’s envisaged that UofE energy stakeholders will use Optima directly to access detailed reporting.

 

This will satisfy any short term requirements for

However, could be some significant benefits in bringing a summarised set of energy figures into EDW to allow energy consumption etc. to be used in conjunction with other figures to calculate e.g. energy consumption per room.

At this stage, this benefit is ‘imagined’, rather than based upon any empirical requirement. 

 

HESA (Higher Education Statistics Agency) annual reporting is currently created from Optima extracts, with manual manipulation, correlation, data cleansing and validation.

There is not a strong requirement at present to automate the production of HESA energy figures.  

5

Capital Planning  

LOW

No specific operational system in place to handle Capital planning /projects. Currently data is pulled together manually from multiple sources into one complex XLS.

 

Current audit /study underway to review how Estates manage their Capital projects, and to recommend ways of working, and suitable underpinning operational systems.  

Overall, it would seem sensible for any plans to move Capital Planning data into ESDW to wait for the outputs of the audit / study.  

 

6

Asset Mgmt

LOW

Estates are in the process of starting up a project to create an Asset Register.

One for the future.

7

Supplier Mgmt  

LOW

Estates use several different procurement systems (PECOS, Sciquest, LPM part of eFin)).

Intention is to consolidate procurement into SciQuest.

 

Issue with sheer volume of different supplier – e.g. same supplier has different billing / ship-to in different systems. Monitoring spend / buying limits is a challenge.

8

Security Mgmt

LOW

Need to know how estate will grow, to forecast growth in security assets (people / technology).

 

Operational security systems in use :-

 - Incident mgmt. – Perspective (supplier = resolver)

 Provides a level of its own mgmt. reporting. Ok for the time being.

 - Access Mgmt – C*Cure (supplier = Tyco)

 

Would be interested in stats e.g. volume of alarm calls per building / analysis of CCTV breakdowns.

9

Strategic Mgmt  

LOW

Dashboards / KPIs

Possible future development.

 

These are the KPIs produced by Estates on an annual basis. They are currently collated manually from a variety of sources.

  1. Income per square metre
  2. Investment in Buildings 5% of IRV
  3. Capital spend as a % of total University income
  4. Building condition at grades A and B
  5. Cost to upgrade to condition B is 5% of IRV
  6. Maintenance Statutory Compliance
  7. Response to Helpdesk Calls
  8. Health and Safety
  9. Cleaning Services
  10. Servitorial Services
  11. Overall Department customer satisfaction level
  12. Waste Services (landfill avoidance)
  13. Teaching Utilisation measures
  14. Absence
  15. Carbon Emissions

 

 

 

  1. Appendix B: Definition of Strategic Reporting

The table below compares the principle characteristics and differences between Strategic Reporting (this project) and Operational reporting (e.g. project EST092).

 

Strategic Reporting

Operational reporting

1

Report contains historical data, and is concerned with aggregates, trends and patterns.

Report contains current data and is typically concerned with events that happened today or yesterday.

2

The underlying data is rarely required to be close to ‘real-time’. Yesterday’s, last week’s or last month’s data is sufficient.

The underlying data needs to be up-to-date e.g. it needs to be ‘real-time’, or close to it. It should be comparable to the contents of the operational system 

3

Reports supports strategic and ad-hoc business decision making processes within an organisation.

Report supports a set of defined, regular and repeated operational processes.

4

Report is presented at an aggregated and summarised level, but frequently with drill-down access to the underlying transactional data.

Report relates primarily to some form of transactional activity, and as a result is quite granular in detail.

5

The information presented can be extracted from multiple, diverse operational systems. Reports will commonly cross departmental boundaries, and may contain information with different data owners.

The information presented is extracted from a single operational system.

6

The information presented may not correlate closely with any single source of data. E.g. the terminology, column headings etc. may be quite different.

The information presented is closely correlated to its source operational system. E.g. the terminology, columns headings etc. will match operational system.

7

Report can be presented in a tabular, matrix format, but also in a number of graphical and visually helpful ways e.g. Dashboards, Graphs etc. 

Report is normally presented in a tabular, matrix format.  

8

Reporting is commonly produced using a set of Data Warehouse (DW), Business Intelligence (BI) and Management Information (MI) tools and techniques. See below.

 

 

 

 

  1. Appendix C: Glossary of Terms

 

Term

Description  

Access Layer

A conceptual space within EDW.

 

Data is transferred from the Foundation layer, using ETL tooling.

 

It is the layer that contains the solution specific data marts and start schemas, and is designed for targeted, quick and efficient access.

 

The access layer utilises the concept of dimensional modelling.

 

It is normally considered an externally focussed space, with many users accessing data via tools such as Business objects etc.

 

BI

Business intelligence (BI) can be described as “a set of techniques and tools for the acquisition and transformation of raw data into meaningful and useful information for business analysis purposes”.

Business Objects (BO)

Part of SAP BI Suite. Toolset used to creates the semantic layer (universe) and reports.

Dashboard

In management information systems, a dashboard is “an easy to read, often single page, real-time user interface, showing a graphical presentation of the current status (snapshot) and historical trends of an organization’s or computer appliances key performance indicators to enable instantaneous and informed decisions to be made at a glance.

Data Mart

A data mart is the access layer of the data warehouse environment that is used to get data out to the users. The data mart is a subset of the data warehouse that is usually oriented to a specific business line or team. Data marts are small slices of the data warehouse. A popular form of Data Mart is a Star Schema.

Data Model

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to properties of the real world.

Data Steward

A Data Steward is responsible for a particular data set. They ensure the data is secure, authorise access, ensure it is documented and establish data quality processes.

The University’s Central Management Group has approved a recommendation to formally define this role and to assign stewards for the University’s core data sets.

 

Data Warehouse (DW)

A data warehouse (DW or DWH) is a system used for reporting and data analysis. DWs are central repositories of integrated data from one or more disparate sources. They store current and historical data and are used for creating analytical reports for knowledge workers throughout the enterprise.

Dimensional Data Mart  

See Star Schema

DW

See Data Warehouse

EDW

Enterprise Data Warehouse

Generic term for the Corporate Data Warehouse, storing data from across the University.

The Enterprise Data Warehouse service will:

  • provide a platform to store University data translated into University terminology for management information and business intelligence purposes
  • manage a service for the extraction and translation of data from source systems ensuring that data is consistent with the source system
  • provide high quality, performant, access to the data in the EDW for consumption by BI tools
  • curate data definitions and purpose for each of the EDW elements
  • advise and respond to changes required to support strategic decision making and University reporting needs
  • reduce the coupling with source systems and BI tools, thus simplifying the migration from one vendor to another  

ETL

Extract, Transform and Load (ETL) refers to a process in database usage and especially in data warehousing that:

- Extracts data from operational systems - Transforms the data for storage in a proper, long-term format - Loads it into the final target subject area.

Foundation Layer

A conceptual space within EDW.

 

Data is transferred from the Staging layer, using ETL tooling.

 

It is the layer that contains the enterprise data model, and is at the very heart of EDW.

 

The enterprise data model utilises the concept of hyper generalised modelling.

 

It is considered an internal space, with only very specialist users able to gain access.

Hyper Generalised Modelling (HG)

A technique for modelling data and its relationships.

 

This is used within the foundation layer.

 

MI

A management information system (MI or MIS) focuses on the management of information systems to provide efficiency and effectiveness of strategic decision making. The concept may include systems termed decision support system, expert system, or executive information system.  

Normalisation / De-normalisation

Database normalisation is the process of organizing the columns (attributes) and tables (relations) of a relational database to minimize data redundancy. Normalization involves decomposing a table into less redundant (and smaller) tables without losing information; defining foreign keys in the old table referencing the primary keys of the new ones. The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made in just one table and then propagated through the rest of the database using the defined foreign keys. Typically used in OLTP systems, not designed for efficient reporting. Implies that one piece of data (e.g. Building name) is only stored in 1 place.

De-normalisation is the process of attempting to optimize the read performance of a database by adding redundant data or by grouping data. This is a technique typically used in Dimensional (Star Schema) Data marts and are designed for efficient reporting. Implies that one piece of data (e.g. Building name) could be stored in many places.

OLAP

On line analytical processing, or OLAP is an approach to answering multi-dimensional analytical queries swiftly. OLAP is part of the broader category of business intelligence, which also encompasses relational database, report writing and data mining.

OLTP

On line transaction processing, or OLTP, is a class of information systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing. E.g. Archibus, eFinancials.

Semantic Layer

A semantic layer is a business representation of corporate data that helps end users access data autonomously using common business terms. It maps complex data into familiar business terms such as product, customer, or revenue to offer a unified, consolidated view of data across the organization. This is the purpose of a Business objects universe.

Slowly Changing Dimension (SCD)

Dimensions that change slowly over time, rather than changing on regular schedule, time-base.

 

A good example is the universities organisational structure. This data is relatively static, but does change from year to year. However, it is usually important to track these changes, to enable accurate historical reporting.

 

Staging Layer

A conceptual space within EDW.

 

The staging layer is used for ETL activities such as loading, validating and transforming data.

 

It is normally considered an ‘internal’ space, not accessible to users.

Star Schema

Star schema is the simplest style of data mart schema and is the approach most widely used to develop data warehouses and dimensional data marts. The star schema consists of one or more fact tables referencing any number of dimension tables. Also known as dimensional data marts.

Static Dimension

Data that is required within a data Warehouse but doesn’t change (as part of any regular update activity).

Static dimensions are not extracted from the original data source, but are created within the context of the data warehouse. A static dimension can be loaded manually — for example with status codes — or it can be generated by a procedure, such as a date or time dimension.  

Subject Area  

The foundation layer within EDW will conceptually be made up of business specific containers known as subject areas. These subject areas will be built over time, as and when business driven projects deliver data into EDW.  The subject areas can be linked together in many different ways, to provide enterprise wide information.

Universe  

A semantic layer provided by Business Objects

 

 

 

 

  1. Document Revision Details

 

Version No

Comment / Response

Date

Who

Document Updated?  In Version? When?

V0104

When you write that the scope is “better” in the preamble do you really mean, clearer perhaps?

CL: Updated.

Also I recognise the need to make sure we can drop elements of the project should we find ourselves pressed for resource or funding but are we really able to drop things like production handover and support from the project. I am slightly worried that if we make this assumption then when the time comes this is the first thing against the wall…

I would prefer that we looked again at the project objectives and decided which of those components we could prioritise in extremis. The solution of course is to flex the budget (up the way) and this is also an option I’m fine with if this is preferred.

CL: I am not aware of any pressures at present to the scope of the project. We have a funding gap, and were are working to close it. The two subjects areas in scope are closely linked together, we would if difficult to deliver one without the other.   

 

12/09

Iain Fiddes

YES

V0105

13/09

V0104

GG: Are these the ADA document (applications and data architecture) as described on: https://www.wiki.ed.ac.uk/display/insite/Project+Methodology+and+Enterprise+Architecture  ??

CL: Yes, this is a good point. I would expect this deliverable to be incorporated within the ADA. I have updated the description.

 

 

12/09

Geir Granum

YES

V0105 13/09

V0104

KA: I am very supportive of the project as you know and  I am happy to approve the brief subject to some minor amendments/ queries as follows:

Section 4 – Scope - Maintenance management.  Could we tighten up the wording of this scope (Colin to assist?) as I am not clear on what we are getting.

CL: I have tightened up the wording. 

Section 8 – Benefits – BE-02 – I would not mention resource allocation as I am uncertain about what is happening to this – I would put the full stop after space.

CL: I have removed the reference to resource allocation.

BE-03 – Slightly nervous about this as I would hate people to draw the wrong conclusions from the ‘numbers’ – Do we know what eFin information is going in?

CL: I’m not sure this is still in scope – It will be down to the detailed analysis. I will add that this work is an enabler and moves us in this direction.  

 

14/09

Karen Adamson

YES

V0105 15/09

V0104

CP: Section 4 – Maintenance Management

My reading of this section was a brief narrative to explain what Maintenance Management is, rather than a deliverable, with the second set of bullets outlining the deliverables – agreed set of reports etc.

A further wording of Maintenance Management could be – Covers hard services maintenance delivery, including 60k reactive maintenance tasks, and 15k planned and compliance maintenance tasks.  

 

 

18/09

Colin Pritchard

YES V0105 25/09

V0101

Project EST093 renamed to EST109, and references to project code changed throughout. Document changes from EST093 V0105 to EST109 V0101

 

 

 

 

 

26/09

Chris Lawford

YES V0101 26/09

V0101

Agreement to amendment, based upon feedback from Apps. Mgmt (AF).

1. I will write into the scope that Space Mart will be de-commissioned in live, as a consequence of the project but not as part of the project. 

2. The project will undertake to:

- Create a de-comm process.

- Test the de-comm process against DEV.    

3. The project will undertake to:

- Once LIVE, perform 1 parallel run Old vs. New. This will either be as part of normal schedule, or a special run, depending upon timing.

- When parallel run has completed, we would remove user access to Old DB/Reports. 

4. Post project, Apps Mgmt would undertake to execute the de-comm process in LIVE.

27/09

Anne Finnan

NO

V0101

27/09

 

AttachmentSize
File est109_-_project_brief_v0101.docx433.2 KB
Image icon capture.png378.9 KB

Project Info

Project
Estates Strategic Reporting - Space & Maintenance Mgmt
Code
EST109
Programme
Estates Systems & Technology Maintenance (EST)
Management Office
ISG PMO
Project Manager
Josephine McDonald
Project Sponsor
Karen Adamson
Current Stage
Close
Status
Closed
Project Classification
Grow
Start Date
02-Oct-2017
Planning Date
06-Oct-2017
Delivery Date
26-Jun-2020
Close Date
31-Jul-2020
Programme Priority
3
Overall Priority
Higher
Category
Discretionary