est109 - estates strategic reporting – space & maintenance ...€¦ · web viewspace mgmt....

EST109 Estates Strategic Reporting - Project Brief V0101 27/09/2017

EST109 - Estates Strategic Reporting – Space & Maintenance Mgmt

1. Document Version ControlVersionNo

Contents DateCreated

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.

2. Document Sign-offName 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.

of 26


Pritchard, Colin Business lead, Maintenance Mgmt

12/09 No.

of 26


3. Project HistoryThis 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

4. ScopeThe 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.

5. EDWEDW 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.

of 26

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


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)

of 26


6. Objectives and DeliverablesO D Outputs / Associated Deliverables Prty* Primary

ResponsibleAlsoInvolved

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 DesignPart of Application and Data Architecture (ADA) document.

M EnterpriseArch

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

of 26


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 & SupportD16 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

7. Out of ScopeWhat 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.

of 26


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.

8. BenefitsWhat Details

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

WorkloadVolumes and value of work being managed – operational (live), strategic (archived)PerformanceNumber of jobs meeting or missing SLA targetsProductivityNumber of visits per craftsperson per productive periodCostCost spent per work stream, e.g. fire alarm activity, or work team or member of staffTrend AnalysisReviewing 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?

of 26


9. Project milestonesMilestone Date Governance

Milestone?Details

1. Project re-planning complete

06-Oct-2017 Yes

2. Business Analysis refresh complete

23-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

10. Priority and FundingThis 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

11. 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)

of 26


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.

12. EDW Early AdoptionWe 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 DisadvantagesA01. 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.

13. High Level Work Breakdown Structure

Phase Activity TaskA Planning

A01 Project Brief

A02 Planning Sign-offB Business

Analysis B01 Space MgmtB02 Maintenance Management

Analysis sign-off

of 26


C Technical Design

C01 Space Mgmt Data DesignC02 Maintenance Mgmt Data DesignC03 Space Mgmt SDSC04 Maintenance Mgmt SDSD Build (EDW)D01 Build Space ETL Source -> Foundation

Foundation -> AccessD02 Build Maint ETL Source -> Foundation

Foundation -> AccessE Build (BI)E01 Create Space UniverseE02 Create Maintenance UniverseF Build (Reports)F01 Build Space Report(s)F02 Build Maintenance Report(s) G TrainingG01 SAP BI Suite training for EstatesH TestH01 Create Integration Test PlanH02 Execute Integration TestH03 Create UAT Test PlanH04 Execute UATH05 ASORI OrganisationI01 Establish Estates BI Super-user I02 Service Mgmt preparation J Deployment J01 DSOR J02 Go LiveK De-commission

Space MartK01 Create de-commission processK02 Prove de-commission process (DEV)K03 Parallel run existing vs. NewL CloseL01 Project Completion ReportL02 Handover BAU support to Service Mgmt L03 Project Close

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

14. Pre-RequisitesWhat Details

of 26


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.

of 26


15. Assumptions

What DetailsA01 Project will use the standard university

BI/MI toolset e.g. BI SuiteThis 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.

of 26


16. Constraints

What DetailsC01 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.

of 26


17. 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

Low/Moderate

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

of 26


a temptation to take short cuts to speed up delivery at the expense of long term goals.

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.)

of 26


18. 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 Interested 3rd Party

of 26


existing space mgmt solution

Pritchard, Colin Y Business Lead Project Team

Communication Plan Details01 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)

of 26


19. Appendix A: Potential Candidates for ScopeThe 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 Details1 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 -> ESSAb) 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.

of 26


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 / KPIsPossible future development.

of 26


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 metre2. Investment in Buildings 5% of IRV3. Capital spend as a % of total University income4. Building condition at grades A and B5. Cost to upgrade to condition B is 5% of IRV6. Maintenance Statutory Compliance7. Response to Helpdesk Calls8. Health and Safety9. Cleaning Services10. Servitorial Services11. Overall Department customer satisfaction level12. Waste Services (landfill avoidance)13. Teaching Utilisation measures 14. Absence15. Carbon Emissions

of 26


20. Appendix B: Definition of Strategic ReportingThe 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.

of 26


21. 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 WarehouseEDW 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

of 26


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.

of 26


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

of 26


22. Document Revision Details

VersionNo

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

YESV010513/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

YESV010513/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

YESV010515/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

YESV010525/09

of 26

https://www/

https://www/


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

YESV010126/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

NOV010127/09

of 26

est109 - estates strategic reporting – space & maintenance ...€¦ · web viewspace mgmt....

Documents