abeam consulting (uk) limited review...

Reporting Requirements and Capabilites 1.0.doc ABeam Consulting / 107

ABeam Consulting (UK) Limited

Review of

Reporting Requirements and Capabilities

Author Dave Kemp

Date 28 November 2008

Version 1.0

Status Issued.



Contents

1. Executive summary 6

1.1. Findings and Implications 6

1.2. Benefits 7

1.3. Recommendation, Roadmap and Technology, 7

1.4. About this document 9

2. Background and Method 10

2.1. Background 10

2.2. Requirements 10

2.3. Applied Method 11

2.4. Contributors and sources 12

3. Findings 13

3.1. Stakeholder Groups 13

3.2. Drivers for Change 16

3.3. Current State Issues 17

3.4. Current Activities 24

3.5. Technology Architecture 28

3.6. Future State Requirements 30

4. Implications 32

4.1. Pressures for Change 32

4.1.1. Procedural Considerations 33

4.1.2. Financial Implications 34

4.1.3. Technology Implications 36

4.1.4. Business Demands 39

4.1.5. External Demands 40

4.2. Reporting maturity 41

4.3. Strategies and Options 44

5. Recommendations 47

6. Delivering the Recommendations 65

6.1. Developing the Roadmap 65

6.2. The UCL Roadmap 66

6.2.1. Roadmap 67

6.2.2. Technology View 68

6.2.3. Timeline 72

6.2.4. Initial Activities 72

7. Selecting a technology to meet UCL requirements 77

7.1. The Maturing Marketplace 77

7.2. Selecting a BI technology 80

7.2.1. Shortlisting 80

7.2.2. Selecting 83

7.2.3. Toolset Recommendations 85

7.2.4. Recommended Toolset - Microsoft BI Suite 86

7.2.5. Pricing 88

8. Appendices 90

8.1. UCL Contributors 90

8.2. UCL Collateral 92

8.3. Supporting Documents & References 93

8.3.1. Case Study – University of Colorado* 93

8.3.2. Case Study – University of Texas* 93

8.3.3. Market analysis papers 94

8.3.4. CIO Presentations 94

8.3.5. The Knowledge Hierarchy 94

8.4. Vendors and Technologies 95

8.4.1. Oracle 95

8.4.2. Business Objects 99

8.4.3. Microsoft BI 102

8.4.4. Cognos 105

8.4.5. SAS 106

8.4.6. MicroStrategy 107



Document History

Issue Version Description Issue Date Author

Document

Framework

TOC structure agreed at start of project to

outline deliverable contents

29/08/08 Dave Kemp

Nic Crotch

Working Draft First consolidation of findings and headline

recommendations for discussion with UCL

project lead

17/10./08 Dave Kemp

Kevin Girling

Marlon Hiralal

Martin Hesse

First Draft 0.1 Issue accommodating feedback from UCL

for initial circulation

Issue for factual verification

24/10/08 Dave Kemp

Kevin Girling

Marlon Hiralal

Martin Hesse

Second draft 0.2 UCL feedback from first draft

Issue for Report Services providers

14/11/08 Dave Kemp

Kevin Girling

Final Issue 1.0 UCL feedback from second draft. 28/11/08 Dave Kemp



Glossary

Business Architecture

A Blueprint for a business’ operations and governance. It shows components of a business and how they interact. It is typically technology independent, showing “what” is done, rather than “how”

Reporting Architecture

A specific aspect of the Business Architecture showing how reporting services are deployed to and used by stakeholders. It will address how they should access information, and what they need. It will define their role in the information chain, and their interaction with each other.

Technology Architecture

A design for the technology underpinning a business’ operations. This is a blueprint that provides a backdrop for application and infrastructure design, and ensures that each component will integrate with others, and is built to common standards.

Data Warehouse

A single organizational repository of enterprise wide data across many or all data sources. The authoritative repository of fact. It may support multiple functionally specific data marts

Data Mart A specific, subject oriented repository of data designed to addresses the needs of specific communities. An organisation may have many data marts, and they may be combined into a data warehouse structure.

Data Cubes Analytical structures built on data marts and warehouses that allow quick and simple reporting to end users.

BI Business Intelligence An industry term referred to a vertical suite of business reporting capabilities, including traditional reports, portals, interactive dashboards, and alerting. Also, the label given to technologies that support these capabilities.

BO Business Objects A Business Intelligence technology toolset provided by SAP. Also, the name of the original vendor acquired by SAP.

BOP Business Objects Planner A reporting application provided by Business Objects.

CoA Chart of Accounts A chart of accounts is a general ledger listing of all accounts, complete with reference numbers or a similar type of unique account identification

CSS Corporate Support Services The Divisions of UCL providing support to academic Faculties.

D&CCO Development and Corporate Communications Office

UCL Support Services Division dealing with Alumni relations, fundraising and general communications

DAs Departmental Administrators Professional management role within faculties, focused on day to day management, rather than academic content

FMAs Faculty Management Accountants

Accountants with focus on Faculty Accounts and performance reporting

FRP Financial Reporting Project An initiative to improve the quality of Financial reporting at UCL. It is currently closely linked to the BOP technology

HEFCE Higher Education Funding Council for England

HEFCE promotes and funds high-quality, cost-effective teaching and research, meeting the diverse needs of students, the economy and society.

HESA Higher Education Statistics Agency

The central source for the collection and dissemination of statistics about publicly funded UK higher education.

I&E Income and Expenditure A general term for the UCL financial reports

IRIS Institutional Research Information Services

An application to systematize the collection, storage and dissemination of information about research activities. Delivers a rich and comprehensive institutional perspective on UCL’s research.

IS Information Systems Responsible for IS infrastructure and support services



ISD Information Services Division ISD coordinates the development and implementation of UCL’s Information Strategy, and provides (amongst other things) UCL’s central IT facilities

KPIs Key Performance Indicators Metrics used to monitor strategic performance

MS Management Systems Responsible for the development, installation, maintenance and support of corporate information systems

nUCLei New UCL Environment for Information

A strategic programme at UCL, with a vision to provide staff and students with access to information that they need, through a standard, easy to use, interface available to them at any time and from wherever they are globally.

OBIEE Oracle Business Intelligence Enterprise Edition

A Business Intelligence technology toolset provided by Oracle

OBISE Oracle Business Intelligence Standard Edition

A Business Intelligence technology toolset provided by Oracle

OFA Oracle Financial Analyser A Financials reporting application from Oracle

OLAP Online Analytical Processing A term given to a data set designed to allow fast analysis of the data

PPIs Process Performance Indicators

Metrics applied by UCL to process models (captured by nUCLei Process stream).

RAE Research Assessment Exercise

The primary purpose of the RAE 2008 is to produce quality profiles for each submission of research activity made by an institution. The higher education funding bodies to use the quality profiles to determine their grant for research

RAM Resource Allocation Module An application that allocates costs of resources across UCL activity

SLAs Service Level Agreements (Part of) a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance

UCL University College London London’s leading multidisciplinary university, with 8,000 staff and 22,000 students from over 150 countries


Executive summary


Executive summary

1. Executive summary

ABeam Consulting has conducted a Review of Reporting Requirements and Capabilities at UCL,

examining existing, planned and potential user requirements for reporting over the next five years, at all

levels from operational to strategic. This report presents the findings of this review and outlines the

recommended strategy, roadmap and technology for UCL to ensure alignment between reporting

capabilities and user requirements over the next five years.

UCL should implement a global reporting capability, through improved, end to end reporting processes, a

global reporting architecture and ethos, supported by a standard reporting technology. This will bring

significant benefits though a streamlined, coherent, UCL-wide reporting capability, delivering accurate

business information to stakeholders in a timely and integrated manner. This would be enabled by clear

reporting processes and an integrated technology environment, where an easy to use reporting interface

provides access, across all of UCL’s divisions, to information through standard or self serve capabilities

(subject to appropriate permissions).

1.1. Findings and Implications1 Corporate Support Services (CSS) need to close a gap between the management information that is

required and that which is available. This gap has driven the implementation of many separate reporting

solutions over time. Whilst this allowed divisions to meet some of their standard and ad hoc reporting

needs, there are many instances where reporting tools are used to access raw data which is then

manipulated manually and locally, generally using Microsoft Excel. This approach to reporting represents

tactical, not strategic approaches to reporting. Other observations on current practices are:

• The current infrastructure is characterised by the variety of reporting tools deployed

• Most current reports access transactional databases rather than use data repositories dedicated

to reporting.

• The current infrastructure strongly reflect divisional silos

• Support for reporting toolsets is inconsistent, and expertise frequently centres round individuals.

• Global processes and architectures were not generally considered prior to nUCLei.

• Existing procedural and organisational structures place serious constraints on UCL’s ability to

meet reporting requirements

As a result, UCL incurs unnecessary costs through

• inefficiencies

• duplicated effort

• unclear global priorities

• decisions made on sub-optimal information

• opportunity cost of committed resources

• lost procurement benefits

1 Summarised findings are reported in Section 3

Analysis of findings is given in Section 4


Executive summary


Executive summary

All of these generate a need for action. Further, external drivers add additional pressure to improve

reporting capabilities. Finally, Stakeholders at all levels are demanding ever more extensive sets of

information, with increasing immediacy and accuracy, and with more control over its presentation.

These pressures create their own momentum and there is an increasingly widely-held view that inaction –

maintaining the status quo – is untenable. There is a growing pressure to respond to the issues identified

and an inclination to meet growing requirements by any means. This strengthens the need for early

development of a coherent strategy and indeed there are activities in progress that should be reviewed

and, ideally, become integrated components of UCL’s overall reporting strategy.

Finally, the toolsets available in the marketplace today allow UCL to significantly upgrade its reporting

capabilities, with the proviso that the toolsets require corresponding improvements to reporting processes

organisational structures to release their fullest potential

1.2. Benefits The scale of benefits is potentially high. In environments comparable to UCL productivity savings have

been in excess of 60% of the costs of reporting activities. Interviews with UCL staff support the existence

of these opportunities. Therefore the scale of opportunities could be in the region of:

• Data duplication could be reduced by 75%;

• Automation and reduction of duplication could lead to a productivity saving of 55% of ‘non-value’

added activities.

Whilst these savings alone would represent significant benefits, there are further benefits that would be

delivered by a mature UCL-wide provision of Reporting Capabilities (capabilities often referred to as

Business Intelligence (BI) by vendors and analysts), including:

• Informed and timely decision making

• Reduced overhead of sourcing and validating data

• Single environment to maintain, train for and support

• Efficiencies from streamlined processes

• More efficient use of resource capacity to meet reporting needs

• Alignment of reporting alignment to Process Performance Indicators and other metrics

• Increased perception by Students and Funders of UCL as a professional, quality organisation.

1.3. Recommendation, Roadmap and Technology2, ABeam therefore recommends that UCL adopt an integrated reporting strategy that brings together end to

end views of the Departments and Divisions of UCL, and so provides a clear global picture of UCL’s

performance. This strategy is delivered through common processes, standards and technologies. These

in turn provide value through efficiencies, reduced overheads, reduced duplication, improved accuracy

and better quality decision-making.

This combination of business and technology design will require that UCL formalise

2 Business Recommendations are presented in Section 5

A Roadmap for change is presented in Section 6 A Technology Recommendation is presented in Section 7


Executive summary


Executive summary

• A Reporting Architecture. Defining how reporting services are deployed to and used by

stakeholders.

• A Technical Architecture. Bringing together data and systems to provide a common data layer

and global reporting infrastructures, providing coherent data that is reported against using a

single toolset

• Organisational support structures. Restructuring to maximise the benefits of a UCL-wide

reporting architecture, by clarifying roles, and ensuring the necessary skills and support

structures are in place. Addressing helpdesk services, training and support, it means roles and

responsibilities behind business reporting must be reviewed and redefined.

• Processes. UCL must standardise end to end processes so that it is clear what is being reported

on. Reporting processes also need to be confirmed.

• Governance. UCL will need to put in place structures to manage the organisation, process, data

and technology to provide assurance that the composite is working, and will continue to work as it

flexes over time to meet developing requirements. This will require formal reporting policies and

Service Level Agreements (SLAs) to be developed and implemented.

ABeam also recommends that UCL set up a formally managed programme of change to implement the

strategy and the recommendations. A roadmap, outlining this programme, sets out the enablers, quick

wins and projects required - activities that will collectively address architectural, organisational, procedural

and technological aspects of the changes necessary. This significant programme of work will

• confirm the full scope and phases of the programme

• coordinate enablers, quick wins and projects listed on the roadmap

• establish detailed plans for phases and activities

• formalise benefits for the programme

• coordinate with other projects already in train at UCL

• establish a formal procurement exercise for the reporting technology.

• deliver the enablers, quick wins and projects confirmed in scope on the roadmap

Finally, having reviewed the technology options available in today’s marketplace, ABeam recommends

(subject to formalising detailed requirements and due procurement process) that UCL selects the

Microsoft Business Intelligence Suite as its core reporting toolset.

This procurement process will form part of the roadmap, but it is not the first step. Organisational,

Architectural and procedural steps can be initiated in the current financial year, ahead of full budgetary

approval for technology investment. These early activities (enablers and quick wins) will be required by

UCL irrespective of the technology selection.


Executive summary


Executive summary

1.4. About this document

ABeam undertook a clear process to gather, review and analyse information, to draw conclusions

enabling us to make a recommendation.

The remainder of this document provides the detail behind that recommendation, and is structured to

support that process:

Section Content

1 – Executive Summary Headline Recommendations.

2 – Method The process agreed with UCL and used to conduct this review

3 – Findings A structured summary of the information reported to ABeam during the

interview stage of the process.

4 – Implications An assessment of the findings, and considerations of the options

available to UCL for reporting technologies and for business

strategies.

5 – Recommendation ABeam’s recommendations to UCL for a reporting strategy and

approach to technology. This reporting strategy is technology agnostic,

but raises criteria for consideration when selecting a toolset.

6 – Roadmap The high level roadmap for implementation of the recommendations.

7 – Selecting a Technology ABeam’s review of available reporting technologies, shortlisting, and

recommendation.


Background and Method



2. Background and Method

2.1. Background ISD and the Support Service Divisions it supports currently use a variety of tools to deliver reports and

management information, including:

• Oracle Reports

• Discoverer

• Oracle Financial Analyser (OFA)

• Business Objects

• Microsoft Excel and Microsoft Access

• Crystal Reports

• Business Objects Planner and Corporate Planner

These tools have been selected and implemented on a largely tactical basis and now present UCL with a

number of challenges:

• Numerous software and hardware installations that require technical support

• Numerous tools for users to understand

• Integrating data across multiple sources (cross referencing systems are often required)

• Some tools have limited capabilities and are not sustainable

• Inconsistent processes

• Data accuracy issues

• Avoidable costs

UCL is aware that the market for, and functionality of, enterprise reporting tools has matured significantly

in recent years and understands that modern technologies are able to provide database-agnostic

reporting capabilities that would be a good fit to its intended application architecture and development

strategy.

Alongside this UCL is engaged in a gradual upgrade of its development technologies to the J2EE platform

and expects to adopt a Service Oriented Architecture (SOA) approach along with a portal-type

deployment of its IT services with an accompanying metadata layer. Additionally, application

developments such as UCL’s Institutional Research Information Service (IRIS) project feature significant

new cross system reporting requirements.

2.2. Requirements UCL commissioned a feasibility and options study of its reporting capabilities.

The study examined existing, planned and potential user requirements for reporting over the next five

years, considering requirements at all levels from operational to strategic.

The scope included software licenses, hardware platforms, available staff resources and associated skill

sets and extent of non-use of functionality within the scope of services delivered by the Management

Systems department (i.e. excludes reporting against data sets for academic purposes).





UCL requires a strategy that will align its reporting capability with user demand now and in the future, but

will encompass both tactical and long term strategic cost savings. The strategy must take into account the

current and likely future product offerings in the advanced reporting and Business Intelligence (BI)

marketplace.

The deliverable is this report which outlines the recommended BI strategy and associated steps required

to be taken by UCL to ensure alignment between reporting capabilities and user requirements over the

next five years.

2.3. Applied Method

UCL review and Executive Sign off

UCL review and Executive Sign off

Develop Best Strategy, build business case, Roadmap, etc

Develop Best Strategy, build business case, Roadmap, etc

Map technologies to requirements, and determine

best strategy

Map technologies to requirements, and determine

best strategy

Wk 1 Wk 2 Wk 3 Wk 4 Wk 5 Wk 6 Wk 7 Wk 8

Capture and Map Requirements to reportoing solution options

Capture and Map Requirements to reportoing solution options

Preparation

& Planning

Preparation

& Planning

Recommendation

Mapping RequirementsKick off

OrganisationalOrganisational

BusinessBusiness

TechnicalTechnical

Consolidate Issues, Requirements into

Formal Requirements

Catalogue

Consolidate Issues, Requirements into

Formal Requirements

Catalogue

Market Review and Tools AnalysisMarket Review and Tools Analysis

The review has been conducted using ABeam’s Business Intelligence Assessment approach, which has

been tailored to ensure that it fully meets the requirements of the review. The steps we have undertaken

are outlined below:

1. Preparation and Planning

• Jointly identify key UCL stakeholders

• Plan interviews and workshops

• Confirm drivers for the review, ensuring a common understanding





2. Capture and Map Requirements

• Conduct focus interviews with agreed key stakeholders (Executive, Operations, and

Management Systems (MS) service provision) – please see Appendix A for a list of

interviewees.

• Identify reporting requirements and current issues

• Consolidate identified reporting requirements and current issues, translating into a set of

capabilities that the future reporting environment must be able to deliver.

3. Map technologies to requirements, determine best strategy

• Identify options for delivering the required capabilities and evaluate to create the basis for

the recommended strategy.

• Develop strategy

4. Develop Roadmap and Business Case

• Develop roadmap for delivery identifying all major decision points, dependencies and

impacts.

• Define business benefits and outcomes

5. Obtain UCL sign off

• Gain acceptance from agreed decision makers

• Obtain UCL sign off

2.4. Contributors and sources

ABeam is grateful to the UCL team for their valuable and constructive input in helping us to conduct this

review and compile this report. A full list of contributors is at Appendix 1. Interviewees were selected by

UCL to reflect the executive, technical and user communities that use, deploy and support reporting

processes and technologies.

Information made available by UCL was incorporated into our analysis and a list of this information is

provided at Appendix 2.


Findings


Findings

3. Findings

This section reports on UCL’s current capabilities, based on discussions with interviewees. Interview

Notes have been provided to UCL under separate cover.

This section is structured to simply summarise ABeam’s findings from interviewees’ observations as

follows:

1. Stakeholders: The constituencies within UCL that will drive or will require improved reporting

capabilities, irrespective of the underlying technology.

2. Drivers for Change: There are a growing number of pressures at UCL both internal and

external, which are creating a need for action in respect of business reporting.

3. Current State Issues: The issues identified by stakeholders are grouped into a simple People,

Process, and Technology structure. They reflect opportunities for improvement arising from

existing practices.

4. Current Activities: Current active and planned projects that will need to be factored into

recommendations and the roadmap.

5. Current Technology Architecture: A focused look at the current technologies that provide

reports to UCL. Consideration is given to the extent to which these can be built upon in the future.

6. Future State: Stakeholders also expressed requirements for future reporting needs. These are

grouped into common requirement sets for reporting, and are cross referenced to these

stakeholder groups. They are both reactions to issues, and wish lists.

3.1. Stakeholder Groups As noted in the approach, three key stakeholder groups were originally identified:

• Organisational: The Executive and Managers who manage and direct UCL and its operations.

Information is used in order to assess performance, report progress, plan the future and direct

UCL’s place in the world.

• Business: Operational users, relying on reporting outputs day to day, in order to produce status

updates for a variety of groups, both internal and external to UCL. This information is also used to

facilitate management decision making and day to day exception handling

• Technical: Those who provide reporting systems and technologies for use by the other two

groups

During the course of interviewing representatives, of these groups, a finer grained grouping has emerged:

Group UCL Roles Stakeholder Role Interviewees

Organisation UCL Management Executive groups and individuals directing UCL

across all academic and support functions

2

Corporate

Support Services

UCL management tasked with delivering support

capabilities: HR, Finance, Estates, Registry,

D&CCO, and ISD

9


Findings


Findings

Group UCL Roles Stakeholder Role Interviewees

Business End Users Any User who consumes reported output, for any

purpose

7

Faculties Academic groups who need to know information

about the costs involved in running their faculties,

and data about their performance

5

Funders

(external)

Any external entity that requires data on UCL

performance to support applications for funds

0

Students A customer of UCL’s academic services 0

Other Businesses A customer of UCL Business or UCL’s research

output

1

Audit and

Assurance

A UCL function that assures data quality and due

process

1

Technical ISD Service

Providers

Provision or core reporting stacks and underlying

technology support

16

Divisional

Information

Offices

Division based power users providing Division

specific reporting services. Also referred to as

Business Unit IT

11

Total: 52

External groups – Funders, Students, and businesses – were excluded from interview by UCL for this

review, as it was taken that the UCL stakeholders providing reporting services to these groups were

sufficiently cognisant of their requirements.

Between these groups, there is an informal “service chain” of reporting services, from Management

Systems, via the Information Offices and IT staff within the Support Services Divisions, out to the various

communities.

These services include reports provision, expertise, infrastructure, and support, although these are

informally defined in many places. Common practice and reliance on experts and contacts are as

prevalent as any defined service levels or formal responsibilities when providing services to report users.


Findings


Findings


Findings


Findings

3.2. Drivers for Change

Interviewees described a number of pressures faced by UCL that are creating a need for improved

reporting. These business drivers are creating pressures that make the status quo an increasingly

untenable position, irrespective of any perceived shortcomings with the reporting systems themselves.

These drivers are both internal and external to UCL, but they all contribute to an increasing demand for

timely, automated, and accurate reporting outputs.

External

• There is an increasingly competitive marketplace for limited funding.

o This funding is likely to be even further squeezed as the UK Government (HM Treasury

accounts for 60% of UCL revenue) seeks ways to compensate for the monies invested to

stabilise the UK banking sector in the current economic climate.

o Concern over the sustainability of current revenue streams, given the Dollar exchange

rate (many foreign students are Americans)

o Poor quality data reporting to funders can lead to financial penalties. As a minimum, it

can create overheads as funders seek to verify submissions.

• UCL increasingly needs to differentiate itself from its competitors

• There is a need to pay attention to league table positions

o Status is important in securing funds (though there are other factors3)

Internal

• There is a need to extend the range and number of sources of funding e.g. alumni, donations,

industry

o Attempts to do so are underway, and need data mining technologies to find and target

additional sources of funds

• There is a need to protect reputation and income by the provision of accurate data.

o Inaccurate data can lead to a lack of credibility with funders, and potentially clawback of

funds.

• General trend to do “more for less”.

o Being driven by Government agendas such as Gershon and the goal of putting a higher

proportion of 18 to 30-year-olds in education.

o The white paper written by the Provost addressed the need to “Make UCL More Efficient”

• The new executive team is tasked with improving the performance of UCL, and wishes to drive

best practice initiatives.

• The amalgamation of several educational facilities has brought additional overhead, duplication of

function, and complexity that cannot be sustained.

3 Times Higher Education Magazine, reported by the London Evening Standard.

http://www.thisislondon.co.uk/standard/article-23569767-details/Capital's+universities+climb+world+league+table+as+UK+slumps/article.do


Findings


Findings

3.3. Current State Issues

Interviewees also identified many issues with current operations. Although much is anecdotal, there are

clear examples of the issues. Again, details are recorded in the interview notes, but appropriate examples

are noted here too.

Overall, there is a sense of frustration with the current reporting processes, a sense of which can be

conveyed by some observations made during interviews:

“… it can take ages to get answers to questions”

“… we don’t support people in using the tools”

“… there is inertia – people are comfortable with their ways of working”

“… we have to speak to a retiree to get information on one system!”

“… getting it wrong can be expensive

“… people don’t know what’s possible”

“… we have no manuals, many systems, and many standards ….. It’s often about who you know”

“… we are run by the world’s largest spreadsheet”

“… we don’t prioritise across divisions”

Whilst recognising that much of the evidence for the issues raised in discussion is anecdotal and that

within the scope of the review it was not possible to conduct the level of analysis needed to validate all

cases, there remain a number of common threads emerging, all with potential consequences for UCL.

We have grouped these common threads and their impacts into a simple People, Process and

Technology framework:

• People: UCL organisation and Structure

• Process: Operational and Governance processes

• Technology: The tools used to produce reports

People

These issues relate primarily to UCL’s organisation and structures, its people and their roles. It also notes

organisational habits that have built up over time – the ‘rituals and routines’.

Common Issues Consequence

1. Organisational structures have led to a silo’d

approach to reporting.

2. UCL has, in the past, tended to provide

There is little coordination of activity divisions,

resulting in disparate practices (“Reporting White

Towers”). As a result global processes

incorporating best practice have not been

developed and implemented. UCL therefore

sustains unnecessary duplication of effort,

multiple methods and skill sets, and, across CSS,

does not get the most efficient use of finite

development resources.

Local and immediate solutions, though simpler, do


Findings


Findings


focused, divisionally oriented, solutions to

requirements without considering their impact

on wider UCL infrastructure.

3. There has been a tendency to consider

reporting data sets from systems once they are

implemented, rather than plan information and

reporting needs as part of the original design.

4. Structures to provide support to end users or

super users in the use of reporting

technologies are not robust. Whilst helpdesks

can provide some support, access to toolset

experts is frequently on a “who you know”

basis

5. Although UCL follows PRINCE2 as a

methodology, there is insufficient overall

programme control and benefits alignment.

6. People currently lack the skills set needed to

utilise modern reporting technologies, such as

Discoverer End User Layers. There is little

evidence that training opportunities are

capitalised upon.

7. The resource pools available for reporting

activities are (generally) static, and so

constrain what is doable. In some cases,

external resource has been utilised, but on a

project by project need.

8. There is little evidence of mechanisms to help

Divisions collectively understand what can be

made possible using reporting technologies.

Expectations are not set, and requirements are

met case by case

9. There is a perception that UCL suffers from

inertia, and change will require significant

effort.

10. People like to see paper.

not always provide the best value, and can limit

overall flexibility as they accumulate.

As well as creating unplanned reporting workload

after a system has been implemented, this habit

also leads to reporting what we can, and not

always what is really needed to support decisions,

thereby impacting the quality of decisions taken

based on the report outputs.

People will recreate problems to solutions if they

cannot find the expert. As expertise increasingly

lives in the heads of individuals, it is difficult to

readily access that expertise, and it puts UCL at

risk should these individuals become unavailable.

Projects are not prioritised globally, so finite

resources are potentially not used to greatest

effect or efficiently.

Investment in reporting tools is potentially wasted,

with functionality going unused. Unstructured

training allows people to revert to what they know

(when faced with operational pressures), and so

Excel models proliferate, exacerbating data

duplication and errors.

UCL is not always able to respond promptly to

business need.

Opportunities for new techniques or common

solutions are missed. “World class” is not aspired

to.

People need a valid reason to change the way

they do things. Without one, changes to reporting

habits may be difficult to achieve.

Paper is expensive to print and circulate, and


Findings


Findings


11. People (FMAs, for example) like their own local

copies of data. These are run in parallel to core

systems. This is a common requirement to

facilitate local data processing and

presentation

12. UCL’s capacity to deliver ad hoc reporting falls

short of the current demand.

13. Faculty and departmental managers have

historically not “owned” budgets and other

managerial information (although this is being

addressed by the roll-out of a new budgeting

and forecasting process by the Financial

Reporting Project).

14. Organisational habit is to seek to increase

income, rather than to control costs.

becomes out of date quickly. It also has an

environmental impact.

Duplicated data stores are expensive and risk

introducing errors.

UCL cannot diagnose operational problems in a

timely manner.

Without ownership of the processes, reporting

outputs are not always acted upon. But they

nevertheless represent a cost to the business in

their production, and bring risk if key indicators

are not recognised

There is insufficiently robust challenge to new

reporting requirements. As a result, new reporting

needs continue to pile up, and limited resources

are effectively prioritised against the requirements

list.

Processes

This section captures issues relating to processes, but specifically those aspects that are relevant to

reporting. For example:

• Operational processes – reporting what we do and how well we do it, using metrics such as the

Process Performance Indicators (PPIs).

• Governance – the rules, policies and standards that set out how and why reports and the

processes that produce them are managed.

Common Issues Consequences

1. Reporting processes are primarily manual, with

many reports produced by hand from tools

such as Excel. ABeam noted little evidence of

automated schedulers that might standardise

and speed up reporting and reduce the

potential for errors.

2. Time to respond to requests for report outputs

is overlong. One requirement for expenses

information has taken nearly a year to meet,

Manual responses take time, are expensive,

and error-prone.

Effort is wasted – information arrives after the

need has gone, or is out of date when it does

arrive.


Findings


Findings


and typical wait time for financial reports is 3

months

3. Time to correct errors in data is overlong. This

is one factor driving the nUCLei work.

4. Management of requests is silo driven. There

are limited views of work across the business

and associated relative priorities. There is

limited management of overall backlog and

resource loading.

5. Reporting is not tied to process.

6. Processes are not modularised. They have

evolved organically over time, and without

holistic design.

7. Current data capture and validation processes

can lead to low quality data.

8. Tendency to focus on process, not outcome or

performance (Key Performance Indicators

(KPIs) and PPIs).

9. Processes are not documented

10. Processes are often duplicated in

implementation (e.g. procurement).

11. Paper reports continue to be produced and

distributed.

12. The deployment of reporting tools in delivering

Financial Reports is identifying broken

business processes, as data required is not

found to be easily reportable

Reports continue to product inaccurate

information.

Resources are not always allocated to UCL’s

global priorities.

Some reports are not needed, and some key

information is not reported.

Modular processes allow reuse and help to

reduce development and maintenance costs.

However, they cannot easily be designed

without an architecture to specify an efficient

modular design. Modular architecture is also a

key building block for SoA developments.

There are no global rules on data structures –

so data can exist in multiple formats across

systems, or be inadequate to procedural needs.

It can be difficult to correctly identify and then

manage what is important.

Risk is incurred by overreliance on key

individuals to know how things work. There are

increased opportunities for duplicated and / or

inefficient effort and errors as report developers

readdress old challenges

Duplication is expensive.

Information becomes out of date potentially

impacting quality of decision-making.

Deploying tools in isolation does not fix things –

it merely highlights problems elsewhere. Clear

and robust processes are required to make

reports meaningful.


Findings


Findings


13. Broken processes tend to get implemented in

new systems – the requirements habit is to

automate current practice (but not always

validate it against current needs).

Consequently, workarounds are common.

14. Support Desk services are not clearly

understood by many stakeholders. There does

not appear to be a single point of contact to

help stakeholders with reporting issues.

15. Each division appears to work to its own

standards; there does not appear to be a

common standard across UCL.

16. There is no common procurement of

technologies. Procurement is silo’d, so, for

example, campus licenses are not always

exploited.

17. There is currently no common architecture

(although this is now being addressed by

nUCLei).

18. Special systems are in place to correlate data

across systems, such as the different room

codes used by FAMIS and CMIS

19. Prior to this report, there is little evidence that

external best practice had been identified and

incorporated.

20. Genuine assurance of data quality is presently

impossible.

21. Use of reporting tools is fitful and compliance is

not pursued. Standards that do exist appear to

cover divisional use at best.

22. Duplicated effort is incurred to support multiple

tools.

Future and global considerations are not

properly considered in systems design, a

tendency exacerbated by spot solutions that fix

the problem, but don’t always address the need.

Increasing numbers of workarounds leads to

rigidity and inflexibility, making future

requirements harder to satisfy.

People do their own thing, introducing

duplication, overhead, and errors.

Global views are difficult and expensive to

achieve, as integrating data sources across

divisional systems is complicated by differing

standards.

Purchasing economies are not achieved;

vendors exploit loopholes.

A coherent reporting capability cannot be

delivered without a coherent design – the

reporting architecture. This in turn, is part of the

business architecture, and needs (in part) a

technical architecture to deliver it.

Fixes are expensive and do not address the

underlying issue.

Opportunities are missed, and wheels are

reinvented.

Data errors are expensive (wasted effort,

clawbacks).

Ad hoc approaches waste effort, and do not

realise benefit from investments.

Unnecessary costs are incurred.


Findings


Findings


23. Reporting appears to be an afterthought in

projects. There is little evidence that reporting

requirements are thought through or properly

cost justified.

24. Poor quality procedures and data have led

directly to funding clawbacks

25. There has been little recognition of clear metric

structures, although some work is now

underway (bibliometrics, End to End process

metrics (PPIs), executive KPIs).

26. Many things never get fixed – this has a cost.

27. Management accounting processes are not

sufficiently robust, and the underlying Chart of

Accounts structure is becoming inflexible

Systems are designed without considering all

needs; and fixing this afterwards incurs

additional efforts and invalidates the original

cost-benefit case.

Errors are expensive, and also adversely impact

credibility.

Reporting effort is wasted effort unless it reports

relevant information.

Working with broken procedures results in

hidden costs.

Financial data can be hard to report upon. This

has lead to unnecessary bank loans, and errors

in accounts. Further, the complexity creates

further overhead for reporting activity

Technology

Technology issues relate to the reporting tools in use and the technical architectures and infrastructures

linking systems and data together.


1. There is a need to provide reporting for a wide

array of purposes, from the various

applications in place. However, there is no

strategy to coordinate how these requirements

are met; rather they are delivered by a range of

technologies and applications that have

evolved over time, that all offer reporting

capabilities. Recent work with BO across the

HR and SITS systems still lacks a backdrop

design common across UCL.

2. The current data sets within these applications

are not coherent – a common data model is

required. For example, there is no single

definition of “Student”. Data must necessarily

be managed across multiple platforms.

Multiple technologies create overheads through

the multiple skill sets required. Integrating

technologies reduces costs through common

and modular designs, fewer and shared skill

sets, and more flexibility on resource allocation.

Incoherent data creates overhead for any report

that needs to correlate data across multiple

systems.


Findings


Findings

3. Data integrity and quality is not proactively

managed.

4. Current technology options are not exploited –

there is a traditional “reporting” provision only.

For example, the Discoverer tool in use in

Finance has not been readily taken up

elsewhere (it could be of use to FMAs, for

example).

5. Existing technology platforms are either difficult

to exploit, or the requisite skill is not available

to exploit it (e.g. Discoverer). But training is

required, whatever the tools in use.

6. Many technical structures are inflexible, leading

to workarounds. Examples include the Chart of

Accounts and predefined schemas in packaged

software.

7. Data retrieval times are perceived as lengthy,

although work has recently been undertaken to

improve server performance is now being

acknowledge to be making a difference

8. There is a tendency to see tools as the

solution, without really having defined the

problem.

9. There are reports out there that are not

documented anywhere, and are not audited.

Errors are corrected, rather than prevented or

designed out, leading to unnecessary cost.

Value is not realised from technology

investments, and habits develop as users

simply ask for more traditional style reports.

Training can be expensive – this investment

must also be managed. Equally, choosing not to

invest here can destroy the value the tool

should unlock.

Workarounds, accrued over time, lead to

excessive maintenance overhead and an

inability to flex the system to changing needs.

Systems designed for transactional processing

are inefficient report engines.

Tools can provide good solutions to problems,

but only if it is clear what the problem is. It is

important to define the business reporting need

clearly before investing in tools.

UCL is carrying costs that cannot be effectively

managed, and is at risk from unauditable

outputs.


Findings


Findings

3.4. Current Activities

The following projects are in progress, and have particular relevance to this review, as they all have

strong relevance to reporting issues and requirements, , and they can (or are) moving UCL towards the

integrated environment ABeam recommends. nUCLei, in particular, is bringing to the fore common

architectures, processes and governance, and UCL has launched a Design Authority to support this.

Further, business initiatives such as the professionalisation of administrative functions, which is

delegating ownership of business performance down the management tree; and the creation of new

posts, such as Executive Deans and FMAs addresses the requirement for stronger managerial

competencies.

Technical Projects

nUCLei (New UCL Environment for Information)

This is a UCL wide review looking at Architecture, Infrastructures, and Processes. As such, it is already

attempting to remedy many of the issued noted above, considering the steps necessary to support a

global information environment. For example, end to end processes with clear metrics and a common

infrastructure. Importantly it has also established a Design Authority, and is working on a global technical

architecture and governance structures – all key components of the standard needed for a successful

global reporting capability.

IRIS

The IRIS system is bringing together disparate data on Research (projects, staffing, funding, analysis)

into a single platform. Although still in the design phase, it presents an opportunity for a data mart typical

of BI implementations.

It currently has three objectives:

• Reduce the administrative effort required to meet the changing demands of research

assessment, monitoring and audit.

• Systematise the collection, storage and disseminate the information about research activities,

including that required by and in support of individual researchers.

• Deliver a rich and comprehensive institutional perspective on UCL’s research, which does not

diverge with the view understood by individual researchers; substantial improvements in the

accessibility of research outputs, internally and externally.

Whilst these objectives clearly address the need for a reporting (rather than transactional) data service, it

is not clear how the IRIS architecture will move forward to become part of a global standard


Findings


Findings

Crystal Reports / Remedy

IS has recently acquired Crystal Reports Server to provide reporting against the Remedy helpdesk

system. This is a focused use of a best of breed application for a specific purpose, and does not appear

to require linkages to other data systems. Whilst this at first glance appears to be another spot solution, a

case can be made to justify its continuation using the following criteria:

• There is an urgent need to understand and improve helpdesk performance – an out of the box

solution achieves that business imperative.

• The solution can be ring fenced – that is;

o it needs to report against data from one system only. There is no requirement to integrate

data across multiple source systems,

o it has a very specific user constituency. Help Desk staff can reasonably be expected to

cope with the additional skill set and training,

o it has a very specific mandate. There is a clear business challenge to address.

The deployment of Crystal Reports should nevertheless be reviewed as requirements and circumstances

mature over time, to ensure these criteria still hold.

This deployment appears to be the only “specific purpose” reporting initiative that meets all these criteria.


Findings


Findings

Business activities

Faculty restructures (Life Science, BioMed)

Recent restructuring of Faculties, whether arising from Graduate School mergers or Faculty

reorganisations, has made visible duplicated processes and systems, and highlights some consequent

inefficiency. The procurement processes are frequently cited as an example.

Additionally, the increasing complexity that these mergers and restructures bring is testing the current

financial reporting systems to their limits as the Chart of Accounts is updated to accommodate new

structures.

Although this change activity is creating significant value by streamlining operations and consolidating

overheads, it is putting pressure on aging systems that struggle to accommodate these new structures.

The need for better automation, streamlined processes, and a review of the Chart of Accounts grow

stronger day by day.

Professionalisation of Administration

Part of the restructuring has included the appointment of Executive Deans, and FMAs. These roles are

responsible for improving the day to day management of Faculties, separate from Academic

responsibilities. These stakeholders have identified many of the requirements for end users and faculties.

Independent reviews of Faculties commissioned by the new Provost.

A key finding from this report is the need to improve efficiency at UCL. In addition to the restructures and

new roles already noted, there is a general trend at UCL towards common practices, and improving

efficiency and effectiveness, all of which is driven top down by the Provost.

Financial Reporting Project (FRP), Business Objects Planner (BOP) and Financial Reporting

FRP is bringing discipline to the accounting processes of UCL by:

• Implementing a standard I&E budgeting & forecasting process to consolidate across UCL

• Moving to a quarterly cycle for income and expenditure reporting and forecasting

• Supporting HEFCE reporting

This involves tracking against budgets, so is presently underpinned by the BOP project. Although some

successes are being had with BOP, there is still much to do. However, the product roadmap for BOP

becomes uncertain after 2011 (its vendor, BO has been acquired by SAP. SAP’s strategy for BO and

BOP are still being developed as this report is written). Still, addressing financial reporting needs is critical

from both a managerial perspective and a technology one.

As part of FRP, activity is also underway to delegate accountability for and ownership of budgets down

the reporting hierarchy.

In parallel, Corporate Planner is looking at cost allocation activities. This all brings increasingly disciplined

accounting processes that can in turn be reliably reported against from a potential Financial Data Mart.

Finally, “Reporting is the most important thing” according to Richard Tittle (Director of Finance Systems).

However, poor infrastructure, aging CoA design, and undocumented processes mean that getting reports


Findings


Findings

out is hard. Good processes and tools would facilitate improved reporting – flexibility, speed, electronic

mailings – all saving significant effort at reporting periods. This is necessary to allow period based

reporting to be properly implemented.

Expense Analysis

An example of the problems with reporting services provision was cited by Alison Woodhams (Finance

Director). Trying to understand UCL expenses by volume and value, a request was made for a report to

provide this information in November 07. As there is no self service facility, and report writing resources

had other priorities, work began on a report in at the end of summer 08. But when interviewed, she was of

the belief that this request had not yet been fulfilled, almost a year after it had been originally been raised.

Procurement, the University shop and paper deliveries.

There is anecdotal evidence from interviews that UCL carries out some processes simply because it has

always done so. Benefits would be achieved through standardisation and efficiency. Processes such as

procurement become duplicated as schools are merged, others are simply habits. For example, the

university shop manager does not work in the shop, stock levels are perceived as needlessly high, and

paper deliveries are thought to have been agreed to in order to meet the supplier’s needs rather than

UCL’s. Good managers can find and implement improvements. However, they can do it faster and with

more focus if they are helped by good relevant reporting, provided promptly.


Findings


Findings

3.5. Technology Architecture

UCL has provided ABeam with an overview of its systems. These have been developed over time within

operational silos, with systems providing functionality for, primarily, divisional audiences. They are almost

all transaction driven designs, intended to capture and process UCL data.

This representation of the current technical architecture draws on the System Context Diagram made

available to ABeam, which dates to August 2006. No more recent systems model appears to be available.

The model has been restructured to highlight the silo’d nature of current systems, and some updates

have been made to reflect interviewees’ commentaries on current systems, though these updates do not

materially affect the silo’d architecture. This remains the key feature of the architecture. Even where BO

universes are used, their use is mostly system specific. As a result, many current reporting

implementations continue to access the underlying systems directly.

Reporting Considerations

• Much (though not all) of UCL’s actual reporting is based on Oracle Discoverer, Oracle Reports

and Business Objects. These applications are used to report directly on the transactional data.

Additionally custom developed web applications give easy to use access to the reporting.

• There is no clear reporting strategy in place. Every division uses its preferred reporting toolkit.

• There is no supported interdepartmental reporting capability. For example, if Finance needs

access to HR data, they get restricted access directly to the HR database and build their own

reports, rather than access to a permissions controlled HR data mart. This is done on a case by


Findings


Findings

case basis, creating cross linkages between systems, rather than reused data extraction

modules.

• Where cross departmental data feeds exist, they are always for a specific requirement. Little

consideration is given to building generic reporting facilities that can be reused by other divisions.

• Many reporting applications are not used optimally because users didn’t get the training needed

to master these applications, and usage was not mandated.

• OLAP Technology is not generally deployed and used (although there are some universes in HR

and Registry, self serve “slice and dice” analytics are not generally offered to end users).


Findings


Findings

3.6. Future State Requirements

ABeam has identified several common threads in the specific requirements noted during interviews.

These have been grouped by

• Management Need – Reporting UCL business performance at executive and operational levels

• Audit – The need to be able to verify UCL performance data

• Usability – The general business requirements of ease of reporting

• The Toolset – Specific requirements of a toolset: Usability, Support, and fit with business need.

Requirements have been cross referenced to the stakeholder groups

Organisation Business Technical

Need Requirement UC

L M

an

ag

em

en

t

Div

isio

nal M

an

ag

em

en

t

En

d U

se

rs

Facu

ltie

s

Fu

nd

ers

(exte

rnal)

Stu

den

ts

Oth

er

Bu

sin

esse

s

Au

dit

an

d A

ssu

ran

ce

Div

isio

n In

form

ati

on

Off

ices

ISD

Serv

ice P

rovid

ers

Management Accounting (Executive)

Regular, high level, historical summary information to track actuals against forecast

� �

Clear, reliable performance statistics � �

“Dashboard” presentations to highlight weaknesses in business performance (Eg, traffic light displays that highlight need for action).

� � �

Trend Analysis to spot icebergs on the horizon �

Management Accounting (Operations)

Standard Management packs, produced automatically from core systems

� � � � � �

Drill down from standard reports for investigation of variances

� � � � �

Ad hoc reporting / drill down from non standard start points � � � � � � � � �

Exception reports � � � �

Audit Accurate, automated, auditable statistics for submission to Funders

� � �

Accessibility and usability of Information

Easy to navigate reporting and information interfaces that require standard business knowledge only.

� � � � � � � � � �


Findings


Findings

Organisation Business Technical

Need Requirement UC

L M

an

ag

em

en

t

Div

isio

nal M

an

ag

em

en

t

En

d U

se

rs

Facu

ltie

s

Fu

nd

ers

(exte

rnal)

Stu

den

ts

Oth

er

Bu

sin

esse

s

Au

dit

an

d A

ssu

ran

ce

Div

isio

n In

form

ati

on

Off

ices

ISD

Serv

ice P

rovid

ers

All permissible information to be available without multiple logon

� � � � � � � � � �

Providing a "single version of the truth"

� � � � � � � � � �

Underlying and mostly historical data complexity should not be exposed

� � � � � � � �

Users can access simple but relevant information sets, pulled together from potentially disparate physical data sets.

� � � � � �

Consistent, integrated, standardised data sources � � � � � � � � � �

Usability of Tool

Ability to format and shape data presentations � � �

No depreciation of currently useful functionality �

Single intuitive tools that let users get the information they need without asking

� � �

Support of Tool

Support the requirements of Division Management � �

Act as Subject Matter Experts and Power Users for their community

�

Support and training for standardised toolsets � � �

Minimise the maintenance overhead � � � � �

Standardised tools provision �

Business Alignment of Tool

Clear reporting strategy � � �

Good requirements and resource planning � � �


Implications


Implications

4. Implications

Analysis of the findings suggests there is a momentum building to take action on reporting capabilities

• The pressures exerted by issues on the ground, and by other drivers, means that inaction –

maintaining the status quo – is increasingly perceived as untenable. There is a growing sense

that UCL must take action to address the identified issues.

• There is a tension building in the gap between what is available (current state) and what is

wanted (future state). Stakeholders at all levels are demanding ever more extensive sets of

information, with increasing immediacy and accuracy, and with more control over its presentation.

They want to close the gap

• A coherent strategy is required to deliver real and lasting benefits. There is a growing pressure to

respond to the issues identified, and an inclination to meet growing requirements by any means.

Moreover, there are already activities in progress that need to be reviewed, and, ideally become

integrated components of any upgrade of UCL’s Reporting capability.

4.1. Pressures for Change

Continuing “as is” is not viable and the issues and requirements noted earlier are symptomatic of several

underlying pressures.

On the one hand, there is a push for Reporting Capabilities to improve upon their current situation (The

current situation is a “burning platform”, and is not sustainable).

• Controlling Costs: There is a need to do more for less, and a growing focus on how UCL

spends its funds. This applies to reporting as much as any other activity, and economies and

efficiencies will be required

• Technology: The increasing inflexibility of the technology architecture means it is getting harder

and taking longer to respond to business requirements.

• Processes: Pressure to improve performance requires a better view of, and control of processes.

Reporting needs to become more aligned to defined processes, as well as managed as a

process in its own right. Typical of this are processes driving external reports, where the need for

speed, accuracy, and auditability is increasing. Also, unaligned reporting processes consume

resources unnecessarily.

Equally, there is a pull on Reporting Capabilities, a desire to see a better way of doing things (and move

to a better world, a “Nirvana”).

• Business Needs: The need to drive improvements at UCL, when coupled with the views of “best

practice” held by new members of UCL’s executive (informed by experience at other

organisations) is creating an imperative to improve. Further, the general improvements required

year on year demand better and more timely information to inform the required decisions. And the

need to mine data to identify and pursue additional funding sources creates another pressure for

improved reporting.

• External Demands: Expectations of students in the Web 2.0 era, and the changing needs of

external funders, means the limits of the current capability are being felt, in response times and,


Implications


Implications

ultimately, in credibility. Responding to the needs of these stakeholder groups will be important

going forward. And failing to respond may cost UCL in student numbers and penalty payments.

These pressures bring out their respective considerations. This section discusses these considerations

and explores some of the key questions. Section 5, Recommendations, will respond to these questions,

where consideration will also be given to developments in the Reporting and BI marketplace (section 4.2),

and the strategic options available to UCL (section 4.3)

4.1.1. Procedural Considerations

Processes are the means by which UCL describes what it does. They need to be explicit if UCL is to

manage them, understand the resources they consume, and derive value from carrying them out. This is

as true of a reporting process as any other. Many of the issues described have procedural aspects.

How much effort is used to best effect?

Undocumented processes and reporting requirements that surface after systems have been implemented

mean that considerable effort is incurred that is not planned for. It also implies that many original designs

are incomplete - in other words, they were not fit for purpose. Better design typically improves the quality

of any systems, but, more importantly, tends to reduce the remedial work required later. Further, by

recognising context, a good design can help build in flexibility and future proofing.

How well are processes designed?

Anecdotal evidence suggests many of UCL’s processes have evolved organically over time. The current

nUCLei project is attempting to understand what’s out there. But there are significant efficiencies to be

gained by good, proactive process design - a principle that applies equally well to reporting processes as

to any other. And the reports themselves are clearer if the process they report upon is clearly defined and

has clear metrics. Many organisations have seen huge benefits from Lean and Six Sigma approaches to

process design, including public sector organisations such as the NHS, as well as commercial

organisations such as Toyota. And process-led designs will lead to better systems and reporting designs.

Further, good process design is a key building block for modular systems implementations, using

techniques such as SOA.

Are Priorities and the Service Chain understood?

There is an implicit reporting service chain from MS to end users, sometimes through the Divisional IOs.

However, there is no evidence of a standard service definition, and certainly no service quality definition

such as might be provided by an SLA.

As well as defining the report delivery processes better, such a chain also identifies the value received by

users at the end of the chain, and this in turn can then be used to help prioritise effort and streamline the

delivery process. If left undefined, it is impossible to assess reporting needs objectively, or address them

efficiently.

A clear service and value chain also indentifies the real sponsors of information outputs. With clear

sponsorship, priorities can be set and orphaned reports can be identified and culled.

Clear sponsorship, working with a clear value chain, can also be used to objectively assess future

requirements, keeping scarce resource focused on activities that generate the most benefit.

Finally, a clear definition of reporting services will be required if ITIL disciplines need to be extending to

the support of reporting services.


Implications


Implications

What is being reported on?

Reports are arguably only as good as the data they report upon. “Garbage In, Garbage out”, is the

principle at work. UCL’s multiple data systems, and poor data validation processes mean that the data

reported upon is inherently prone to errors and discrepancies; the resulting reports carry forward those

risks, and leading to a degradation in quality of managerial decisions and external credibility.

Good design principles make all the difference here, by requiring a global view of the data set to manage

shared (and probably duplicated) data, and by ensuring that good error handling is built in. The more this

is automated, the lower the risk.

A global data view also means that users are much clearer about what is needed when reports are

specified, and can refer to business information. Systems experts can then ensure that the right data is

pulled consistently from the right data source.

Culture and comfort

As UCL has changed, some processes and practices have gone unchallenged, and this appears

particularly true of reporting outputs. Many reports are produced simply because they always have been,

whilst the need for the information they contain is past. This creates a hidden overhead, draining system

and support resources.

However, people are comfortable with what they know, and to change to new reporting procedures (and

tools) will require guidance and help to transition from old habits to new ones.

Risk

Informal processes (and systems) mean that expertise develops in only a few individuals – those who

have worked in that area. As well as creating a constraint on the resource pool, UCL also carries a level

of risk in the event that “experts” move on

4.1.2. Financial Implications

All the issues discussed earlier results in adverse cost implications, whether through inefficiencies,

duplicated effort, decisions made on sub-optimal information, opportunity cost of committed resources, or

lost procurement benefits. Therefore there are opportunities to improve efficiency, effectiveness, and

quality of decision making. External drivers such as an increasingly competitive environment with limited

funding pools add further pressure to do so. Doing this requires relevant, accurate and timely

management information.

How much more is UCL paying for licenses bought in multiple one-off deals?

Licences are cheaper in volume. Implementing a UCL wide reporting strategy and buying in bulk will be

cheaper than buying batches of licences for specific projects.

What will it cost UCL to support BI solutions from defunct or acquired vendors?

A robust reporting strategy will consider UCL’s suppliers’ roadmap. There are costs associated with

supporting or migrating solutions from vendors that have been acquired, remained independent, or in

trying to integrate multiple systems. While there are no absolute guarantees, careful selection of product

vendors can make a big difference.


Implications


Implications

What is the opportunity cost in delaying standardisation and not capitalising now on the benefits

afforded by BI?

Businesses rolling out enterprise BI are reporting significant benefits.

How much is it costing UCL staff to learn and administer multiple BI/Reporting tools?

With a variety of Reporting tools in use, the complexities, learning costs, administration and integration

costs associated with the various technologies increases dramatically. Users also have to be trained on

multiple toolsets. In many cases, the information they need comes from disparate systems with specific

interfaces, so users need to rely on the experts to resolve the integration. This leads to unnecessary work

and frustration for both reporting service providers and end users alike.

What is the opportunity cost due to limited visibility of enterprise information?

Lacking a common Reporting framework means simple requests such as “the list of purchase orders and

support issues,” or “a breakdown of expenses by category” is difficult to obtain, especially if the

information comes from disparate systems. Requests can only be answered using technical specialists

who can get at that data but who are in short supply. These information stovepipes (in applications and

departments) result in partial or departmentalised views of the business, stop users from obtaining a full

understanding of their business activities and leads to sub-optimal decision making. Also, employee

mobility is made more difficult when users have to learn a new Reporting tool every time they move

departments and, potentially, teach their replacement the previous one.

The costs of current reporting tools are much higher than would be the case had UCL chosen an

enterprise wide reporting strategy. This is because vendors can offer site licences and volume discounts

for bulk purchases. And, UCL have a higher proportion of FTE’s currently involved in reporting that

average levels suggested by Gartner – and many continue to build standalone reports, rather than

reporting infrastructures.

Benefits of a consolidated reporting strategy

These include the ability to:

• Track course enrolments during registration each term and notify course administrators of the need

for additional sections based on pre-defined rules

• Predict course demand in advance

• Improve student recruitment to yield the highest quality students while making use of recruiting

budget

• Track purchasing patterns and direct purchasers to the best price for the equivalent product

• Analyse research funding portfolios and predict the probability of future funding based on economical

parameters and funding budgets and then direct researchers to sources where they are most likely to

get funded

Assumptions used to consider productivity savings

• Robust costing breakdowns on the support costs of systems are not available

• In-house systems are underpinned by FTEs and licensing factors

• Division Information Offices have their own FTE’s working on reports and data gathering

• Savings derive from addressing ‘non-value’ added activities within Reporting and Analysis, which are

data collection, data modification and data submission


Implications


Implications

According to a Gartner survey, in environments comparable to UCL productivity savings could be in

excess of 60% of the costs of these activities. Interviews support the existence of these opportunities.

Therefore this percentage could be applied to all the management reporting:

• Data duplication can be reduced by 75%;

• Automation and reduction of duplication could lead to a productivity saving of 55% of ‘non-value’

added activities. Costs of a Reporting Framework

UCL’s current reporting environment is localised. There is no common Reporting Framework in place.

The existing ‘patchwork’ means that users cannot obtain a full understanding of their business activities

‘based on one single version of the truth’. This in turn leads to sub-optimal decision making.

And as the variety of disparate reporting toolsets grows, the IT and business costs escalate, as they

begin to factor in (for example):

• Training and maintenance of multiple skill sets

• Inflexibility of workforce (assuming not everyone know all tools)

• Reports are recreated in multiple technologies

• Architecture is ignored and reusable components are never built.

UCL uses several reporting solutions, from very simple stand alone reports, through technically

complicated to functionally sophisticated. Without a common BI/Reporting framework, multiple versions of

the truth will occur. For example, the answer to “What is the cost of a specific department?” may vary

from one system to another, depending on how cost is defined and how clean the data is. Users will have

difficulties in trying to communicate and collaborate, as there is no common understanding of the terms

being employed.

4.1.3. Technology Implications

Technology designed for specific purposes over several years is now being asked to meet increasingly

sophisticated requirements. These have conflicting data design goals:

Current State - design of current systems

Historically information systems were designed

to process discrete transactions in order to

automate tasks such as registry, fulfilment, and

tuition. The objectives for these kinds of

transaction processing systems were fast

response times and automation of repetitive

tasks. The database design for these systems

minimises data redundancy and is intended to

access a limited number of records at one time.

Future State – design requirements for

Reporting and BI

BI-Reporting requires the ability to process a

greater number of records, perform complex

calculations, and aggregate data into

meaningful summaries. The design of a

transactional system does not meet these

needs with any degree of efficiency, as very

complex SQL statements must be programmed

and maintained to provide the summaries and

calculations common in data analysis. These

complex queries result in long response times

when run against a transaction processing

database and risk degrading the performance

of mission-critical systems.


Implications


Implications

As a result, the current technical environment is no longer fit for purpose for the reporting requirements

now being asked for.

There are currently several initiatives planned that aim to provide better information at a functional and

departmental level. These will add to the complexity of the reporting infrastructure and, if delivered as

divisional solutions, will be less cost efficient than an integrated solution. Without strong governance and

common data definitions, new reporting projects are likely to add to the inconsistency and duplication

problems already identified, making things worse rather than better.

An approach to reporting systems development whereby new requirements are met by bolting

functionality onto existing services, rather than an architecture-led one, leads to increased complexity and

increase the likelihood of further “bolt-ons” (it’s “quicker” than fitting into a design), but it never solves the

underlying architectural problem. Rather, it makes it worse. A coherent architecture, with executive

sponsorship, promoted by a Design Authority, will move UCL and its systems towards integration, and in

turn helps support the need for step changes when incremental ones have the potential to lead up blind

alleys.

The security risk of having multiple BI/Reporting tools

Multiple tools normally run multiple security infrastructures for administering users; and there is no

common, secure data governance model. This ultimately leads to a less secure and less reliable

environment since more tools results in a higher likelihood of error and security breach.

User perception of an information system that does not deliver timely, reliable answers to their

business questions

Reporting is for many users the outermost and most visible layer of the IT infrastructure (along with

transactional processing interfaces). It is this layer that is seen to deliver a significant portion of the visible

business value of IT investment. Good Reporting, therefore, reflects well on IT Service provision in

general; bad reporting service is evidenced by many of the issues noted earlier.

Currently UCL has to maintain many different reporting toolsets in different departments. Replacing these

with a single BI Toolset reduces maintenance, and presents, via a common portal, departmental data

marts underpinned by a data warehouse layer. This presents a “single version of the truth”.

A common toolset typically raises the adoption rate of the tools by users and the response time of report

oriented designs is incredibly fast. This can feed a “virtuous circle”, when people begin to appreciate the

power of the tools and its ease of use. This in turn enables better decisions based on timely, more

accurate data.

Common data and data assurance

With one logical source of data, governance becomes easier, as data needs only to be monitored when

entering the data marts and warehouse. With automatic extraction, transformation and loading, data

quality can be guaranteed (assuming it is correct in the source system).

Inappropriate use of Excel

Currently, many users pull data out of systems, load it into Excel, and then send it other people, who, in

turn, use this data as sources for their own Excel calculations. This can go on until nobody knows where

the data has originally come from. Although much work has been done with the FMAs to break this


Implications


Implications

organisational habit, there is a better option using data cubes as core data source. Here, people generate

Excel Sheets with a direct connection to the data so everybody can see where the data is originating

from. This standard avoids many sources of error, and brings everyone to using a core data set. Excel is

then used as a presentational layer, not a data layer Data Warehouses, Data Marts, and Cubes

Data Marts commonly sit at the heart of Business Intelligence Systems. They are database structures that

provide flexible and easy to use reporting from transactional data systems. They can be assembled into

Data Warehouses if needed, but let us deliver value quicker (warehouses, being bigger, have longer lead

times) 4

Data Cubes can be developed on either platform. These are multidimensional structures that allow quick

and simple reporting to be provided to end users, allowing them to look at the data from any angle.

Report Graphics

25

A simple example is shown above. It represents an Income and Expenditure data cube that enables

users to do an analysis on the research grants, costs and profit figures sorted either by time, faculty or

project leader. Analysis is often done using Excel, as most BI vendors offer an Excel-Plugin that allows

real-time analysis. Each element in the cube represents one figure. The red one for example shows Mr

Miller’s engineering projects in Quarter 1. Local analysis might look at a whole "slice" of the cube which

would then be sorted and filtered as required.

4 The alternative approach (Bill Inmon) recommends building data warehouses first. This approach can

lead to longer lead times for benefit realisation, and can put project sponsorship and success at risk as a result. The Data Mart led approach (Ralph Kimball) releases benefits sooner, and is iterative, allowing learning to be built in. It improves sponsorship and reduces risk through more focussed deliverables.


Implications


Implications

Dimensions of a cube can also contain hierarchies that enable the user summarise data at an aggregated

level, but be able to drill down to the lowest level if needed As most aggregations are calculated in

advance, the average response time to create a new view on a cube is typically very short.

Multiple dimensions and hierarchies can be mixed around as needed – a techniques referred to as slicing

and dicing.

By sharing the data marts between departments, the Divisional white towers can be dismantled piece by

piece (instead of forcing the departments to do it). The support quality will rise as the number of toolsets

is reduced (a corollary to the assertion on multiple toolsets), and support can be provided through a

centralised support desk. End users might then only have to know Excel and the Data Mart infrastructure

to provide accurate reports. It is also becomes much easier to control the whole reporting service as the

infrastructure to support it is centralised in ISD.

Most of the resources for developing reports could be reassigned to the development of data extraction

routines and data cubes. This would be much more efficient than developing specific reports for specific

users. Users who currently choose to print out reports and store data locally will begin to change their

behaviour as they develop trust in the system and the quality of the reporting. Even if they continue to

store their Excel files locally, the sheet will always have a connection to the database and contain actual

and accurate data when it is opened.

Underutilisation of Technologies

UCL currently has a number of reporting technologies deployed. However, through combinations of habit,

inadequate training and support regimes, lack of commitment, they remain underutilised. More aggressive

use of Discoverer in Finance, or development of universes in Registry, could drive better reporting

capabilities from current investment.

However, consideration still needs to be given to cross divisional data and processes.

4.1.4. Business Demands

UCL management and departments increasingly want more sophisticated and timely reporting in order to

manage UCL’s business operations.

These new requirements have been summarised above as Future State Requirements (section 3.6).

Current systems and processes are increasingly unable to meet these needs, with considerable specialist

works needed to answer specific questions about UCL’s business. For example, IRIS has been

commissioned to address deficiencies in Research Reporting, but this is a custom solution to a specific

need, and not an investment in a core capability that could support other similar needs.

There is one consideration worthy of special note. UCL cannot easily benchmark itself, partly because the

internal performance data is difficult to collate, but also because comparative external performance

cannot be robustly assessed (poor data, and poor comparative metrics). More analysis of this need is

required.

However, other universities also appear recognise this need for better information, and are addressing

their capability to provide it. Anecdotal evidence suggests other London universities have already begun


Implications


Implications

to invest in their Business Intelligence capability.5

More significantly, case studies from the US

(Universities of Colorado, and Texas – Appendix 3) suggest there are benefits to be gained by identifying

upcoming problems, improving decision making, and in making sense of all the data. These processes

have become underpinned by a clear view of the data, and anecdotal evidence has been dropped. BI has

become a core requirement of their business processes, and a key enabler to building a more agile

organisation.

And, although UCL draws flexibility from the diversity arising from its decentralised management, this

comes at the cost of differing management cultures, different priorities among divisions and departments,

and different levels of information maturity. This in turn creates multiple projects aiming to deliver a better

understanding of their performance. But addressing local priorities through divisional initiatives reinforces

reporting ‘silos’, and leads back to the increased overheads already discussed.

Addressing this cultural backdrop is perhaps the most difficult challenge in leveraging UCL’s data for

strategic value. It will require senior stakeholders’ full commitment to manage UCL in a different way, if a

global reporting programme is to unlock UCL’s full information potential. It will need to drive common

design and practices across CSS in order to address the needs of the schools/colleges and other leaders

of the University’s academic, research, and service units, who use the information to get their jobs done.

Ultimately, BI initiatives that are built on a common data infrastructure and that are transferable to other

departments and divisions pave the way for strategic BI. According to Gartner, operational reporting

accounts for up to 60% of an organization’s BI effort. Worse, getting trapped in simplistic static reporting

can take this percentage far over 60%. There is significant anecdotal evidence that UCL invests huge

effort already in producing simple, historical actuals and answering simple managerial questions. Working

at this operational level there is presently no ability to see the big picture, and consequently, limited ability

to manage for the future. Real value can be realised by having the skills, organisation, and ability to drive

positive business change based on insight. To address this Gartner recommends, and our own

experience demonstrates, the need for Business Intelligence Competence Centres. These create a

reporting centre of excellence, and help organisations move beyond the reactive reporting level by

making BI a managed, proactive and aligned part of business management.

4.1.5. External Demands

There are two major external groups: Funders, and Students

• Funders: require information about UCL performance across functional structures. HEFCE

and RAE submissions require the collation of disparate data sets. This growing demand is

currently met through manual time consuming processes

• Students: expectations about online services and information are high, set by services such as

Amazon, eBay, iTunes and online banking. Today, people expect to be able to log into a self

service portal where relevant information is pulled together.

5 Imperial College London – Organisation Intelligence Stream

http://www3.imperial.ac.uk/ict/services/businesssystems/streamsandprojects/organisationintelligencestream


Implications


Implications

Both these groups, like business users, incur unnecessary inefficiency as well as the potential for sub-

optimal decision making and frustration where there is no “single truth”. Though their costs are not

immediately incurred by UCL, they use reports produced by UCL, or access data through MyView, or on

the UCL website. Poor quality information in these areas damages trust and credibility, and can give rise

to direct financial penalties, e.g. funder clawbacks); or indirect ones, e.g. poor perceptions of UCL and

reduced student numbers.

4.2. Reporting maturity

Improving Reporting Capabilities means understanding what we do now, and what we want to be able to

do in the future. UCL needs to move quickly to a better place, and one way of looking at UCL’s current

position, and where it might change things, is through a maturity curve, which considers overall

competency in reporting capabilities. The curve allows us to benchmark UCL’s competence.

The curve also uses a backdrop of a competence against a suite of reporting capabilities. Typically, these

capabilities are collectively referred to as Business Intelligence (BI) by toolset vendors and marketplace

analysts, and encompass a suite of reporting types:

BI typically describes three core types, which are underpinned by five broad reporting techniques:

• Analysis o Advanced Analysis. Techniques such as Data Mining.

o OLAP Analysis. This is the most commonly used technology in a Business Intelligence

Environment. It allows users to “slice and dice” through the data to achieve quick and easy ad

hoc reports.

• Enterprise Reporting o This is relational reporting e.g. Discoverer. But instead of reporting directly onto the source

application, these reports should rather report on special tables in a data mart or an

enterprise data warehouse that can be filled with the appropriate data in advance

• Monitoring o Scorecards and dashboards

� Scorecards are weighted compilations of figures. A scorecard should contain hard figures

like revenue and soft figures like customer satisfaction. These are weighted to show how

well the business is running.

� Dashboards present key performance indicators and other data in a user friendly manner

using graphical design elements. They normally contain highly aggregated data that

gives the management the ability to react quickly to certain unusual events

o Alerts & Proactive Notification

� Specific groups of people are notified if certain events occur. This could be done by

sending them a report by mail, contacting them on their mobile phone or sending links to

dashboards that contain more information regarding this event.

These are sometimes referred to as the 3 Pillars of BI.

Typically, the more sophisticated an organisation is, the richer the selection from these methods is.


Implications


Implications

UCL presently uses some of these techniques in a generally limited way, and, historically, has rarely

applied them across divisional boundaries. This approach is now beginning to change, with applications

like IRIS beginning to create analytical functionality across divisional systems, and D&CCO looking to

exploit data mining opportunities, but these initiatives are relatively recent.

Requirements described by UCL stakeholders suggest they would like to take advantage of all of these

techniques, to varying degrees, assuming the requisite infrastructure were in place. And the Business

Intelligence technologies available in the marketplace offer various mixes of these methods of reporting.

But UCL’s requirements suggest a more immediate need for OLAP Analysis and Enterprise Reporting -

getting good, reliable information to be available to users.

Other requirements could be addressed within longer term timetables (for example, there are

requirements for dashboards in some communities) but these will require a solid and coherent data layer

that they can rely on as a prerequisite. If these types of sequencing considerations are not addressed,

then deploying tools such as global dashboards will only frustrate users if the underlying data remains

unreliable

We can also assess UCL’s maturity against a maturity scale that considers the business approach to

reporting and information.


Implications


Implications

UCL’s current activity is mostly centred on departmental reporting, producing printed reports with no ties

outside the immediate audience, with little executive sponsorship, and with considerable data consistency

and quality issues. This places UCL, at best, at level 2 on the curve. It is also important to note that there

are differences between departments. For example the group dealing with alumni and fundraising, believe

that, for enterprise reporting and the current demands placed upon them, they have an adequate tool

using oracle reporting. Whereas the MS team working in this area does not know what the division is

really doing with the data reporting. This indicates level 1.

However, the requirements espoused by the stakeholder groups, indicate a need for level 3 (focused on

business need, project-based reporting), although specific requirements from some stakeholders demand

level 4 (managers own budgets, and use these to drive efficiencies as part of the strategy), and level 5

(audited, automated, information from core systems is at the heart of UCL’s activities – notably funding!)

For example, the Finance department is dealing with growing requirements, and is implementing

enterprise performance management tools such as Business Objects Planner. At the same time the MS

department is gearing up to support this. As with current state, there is a disparity on aspirations between

departments. MS appears here to be moving only to level 2, but will need to place itself much further up

the curve if it is to remain at the core of reporting provision, and, through a Design Authority or Business

Intelligence Competence Centre, demonstrate credibility and assert standards to all communities. Core

groups should be aspiring to level 4 as a minimum.


Implications


Implications

Improving the maturity of approach to BI brings benefits that include:

• Informed and timely decision making

• Reduced overhead of sourcing and validating data

• Single environment to maintain, train for and support

• Better perception by Students and Funders of UCL as a professional, quality organisation.

Specifically, research undertaken by the Hackett group6 concluded that Level 1/2 companies

• have 157% more FTEs then best in class;

• 71% more cost than best in class;

• 52% more FTEs then their peer group average

• 9% more costs than their peer group average.

4.3. Strategies and Options

Whilst simply upgrading and/or consolidating UCL’s reporting technologies will provide the improved

service maturity we have described, there are several strategies that need to be considered.

Many of the issues arise from business disconnects, poor process, or lack of clear business requirement,

as much as they do from technology configurations. The requirements indicate a need for global, not

divisional information, as well as ease of use - common portals, single sign on, and data that means the

same wherever it comes from. Therefore UCL also needs to consider its Business Architecture – that is,

the business rules people use to carry out their day to day work, and the structure that sits behind them.

UCL can change:

• Its business model, and the reporting needs that derive from it,

• Its reporting technology

• Both of the above

• Neither of the above

This gives four broad scenarios as follows:

6 www.thehackettgroup.com


Implications


Implications

Report Graphics

24

NEW HABITS

New Business, Old Technologies

BRAVE NEW WORLD

New Business, New Technologies

STATUS QUO

Old Business, Old Technologies

NEW TECHNOLOGY

Old Business,New Technologies

The Status Quo (The current situation)

This is UCL today. There are large numbers of issues and the technologies cannot respond effectively to

the identified reporting needs.

New Technology (The historical default response)

Simply deploying new technologies will not work if the structural issues – connected business,

streamlined processes, and clear metrics - are not addressed. New technologies simply highlight the

broken business elements faster, and typically tend to recreate broken process in the new tool thereby

failing to deliver against many business related requirements.

This is essentially the path that UCL has followed historically and unconsciously.

New Habits (May provide some quick wins)

This option delivers benefits such as:

• Efficiencies from streamlined processes

• More efficient use of resource capacity to meet reporting needs

• Reporting alignment to PPIs and other metrics

• Professionalisation of process and managerial discipline (e.g. BOP).

Further, many of the reporting needs cited could, to some degree, be delivered by making better use of

existing technologies. For example, Discoverer is significantly under utilised.


Implications


Implications

However, such a strategy has only short to medium term benefits, and may prove costly in the medium to

long term. This is because further changes to the business needs and processes will inevitably lead to

further demands on the underlying technologies. This will lead, over time, to more workarounds, offline

systems to cater for functionality gaps, and generally further exacerbate the inefficiencies of the current

platforms. Over time, it will become too expensive and take too long to do anything.

This option provides opportunities for quick wins by addressing governance and business architecture,

but is not adequate to sustain UCL’s long term requirements.

Brave New World (The recommended strategy)

This strategy builds on the short term potential of New Habits. It brings technology architectures and

modern reporting tools to bear to allow the business to get to grips with reporting performance in tangible

ways using timely, accurate, and coherent data, delivered to users online, thereby making information

timely, relevant, and flexible.

This is the recommended strategy, bringing together holistic views of the Departments and Divisions of

UCL to provide a global picture of its performance. This is enabled through common processes,

standards and technologies, and these in turn provide value through efficiencies, reduced overheads,

reduced duplication, improved accuracy and better quality decision-making.

Further, by implementing a layered architecture, greater future proofing is provided. It:

• Insulates users from technical changes – their interaction is with a common portal

• Provides a structure that can support other technologies, such as SoA

• Provides a common user experience

• Provides integration of disparate systems and data sources in managed and modular ways -

which means aging systems can be swapped out over time

• Provides a common language as toolset, minimising maintenance overheads

• Is supported by a variety of toolset vendors, all working to this type of model

A key strength of this strategy is that it aligns technology with business needs by bringing together

business and technology architectures.

This business led, technology enabled strategy is recommended as the most appropriate way forward.


Recommendations


Recommendations

5. Recommendations

To meet stakeholders’ requirements, and address the implications of the current situation, UCL needs to

address the fractured nature of the reporting services that are offered. IT needs to move from an

approach that is silo’d, organisationally and technically, to one that incorporates integration,

standardisation, and quality assurance.

To achieve this, working practices, service chains, and technology design ethos also need to change.

Specifically, the following are required:

1. Business architecture. This will show how reporting services are deployed to and used by

stakeholders. It will address how they should access information, and what they need. It will

define their role in the information chain, and their interaction with each other. It must show how

they report on the processes the business needs to carry out.

2. Organisation support structures. These will require redefining and possibly restructuring to

maximise the benefits of a UCL-wide reporting architecture. This includes the provision of

helpdesk services, training and support, including determining how new reporting needs are met

to exploit the new architecture rather than conflict with it. Roles and responsibilities for provision

of reporting to the business community must be reviewed and redefined.

3. Technical architecture. To support an holistic business architecture, and support it with

coherent data, UCL needs to build on the work of nUCLei, and consolidate the technical

architecture, bringing together data into a common data layer, thereby providing coherent data to

report against, and must move towards a single (or minimal) toolset to be used across UCL and

accessed via common portals. At the data layer, clear and common structures are required that

reflect UCL’s current business. This means that underlying data structures, such as the Chart of

Accounts, may need to be reviewed, and will certainly need to be rationalised.

This view shows, in principle, the architectural layers required:

• Portal and presentation layer: Shown here as a portal per Function, these may be

merged down as required

• The Warehousing and Data Mart Layer: Provides abstraction of information from the

physical data sets, and brings together into a Common Data Model multiple (and

sometimes conflicted) implementations of data. This layer is optimised for bulk data

retrieval

• The physical layer: Raw data storage. Also supports transactional data processing, and

is optimised accordingly.


Recommendations


Recommendations

4. Process. UCL must standardise the processes that are reported against and which process the

data. This builds on the Process stream of nUCLei, and will need this work to conclude. The

processes identified by nUCLei will be measured using the PPIs it also defines; these will then

need to be structured to build into the KPIs presently available to the Executive stakeholders, and

linked across to the Chart of Accounts and RAM costing structures. Clear and common metrics,

against clear and common processes, will allow the definition of clear reporting outputs, on

known and understood processes.

5. Governance. UCL will need to put in place structures to manage the organisation, process, data

and technology to provide assurance that the composite is working, and will continue to work as it

flexes over time to meet developing requirements. This will require formal policies and SLAs to be

developed and implemented.

Overall, UCL needs to:

• Raise BI / Reporting standardisation to a strategic level

• Set up a task force to select the BI/Reporting standard

• Adopt a phased approach to implementation.


Recommendations


Recommendations

To deliver these components, the following specific actions are recommended:

Category Recommendation Benefits How delivered / by

who

Risk Implication if not

done

Business

Architecture

Develop a Business Intelligence

Environment - a UCL-wide view

of reporting processes,

information entities, user and

stakeholder groups, and their

interactions.

Provides clarity and a technology-

independent view of reporting – a

baseline against which the impact

of deployment of new technology,

organisation and processes can

be assessed, allowing

appropriate business change

management activities to be

planned.

ISD, working with

Support Services

Divisions IT staff /

Information Offices.

Pressures of

Business as Usual

requirements will

undermine attempts

to implement global

architectures

Impacts on reporting

stakeholders not fully

understood and not

addressed, reducing

the overall benefit of

deploying new

technology,

organisation and

process.

Organisation and

People

Promote the Vision for

Business Reporting. Stress the

value of strategically-driven

reporting & business

intelligence.

Promote the benefits cited in

against these

recommendations, and the

implications of not actioning

them.

Enables the paradigm shift from

divisional reporting perspective to

UCL perspective. Builds

understanding that a common

approach is required to solve

current issues and meet future

needs.

ISD to initiate this

activity alongside the

procurement of new

technology, as the

precursor to a business

change management

work stream.

Not all CSS Divisions

buy in to the vision

and benefits, leading

to bias towards

champions, and

warping of design,

Inadequate

sponsorship leads to

reduced scope and

investment, limiting

strategic impact.

Old habits will persist

e.g. divisional view of

reporting delivery

supported by localised

processes.

Common technology

platform will not deliver

intended benefits


Recommendations


Recommendations


who


done

Develop business change

management work stream to

understand impacts of change

and develop plans to address

them. This should include

promotion of the overall benefit

to UCL which will be derived

from adherence to reporting

standards i.e. cultural shift to a

corporate rather than divisional

/ functional view of reporting.

Enables:

• Identification of impact on all

reporting stakeholders

• Planning of business

activities that must be

undertaken to ensure

business readiness and that

benefits are delivered

• Management of stakeholder

expectations

Management Systems

to initiate this activity as

an integrated part of the

roadmap.

Failure to understand

benefits can erode

sponsorship

messages and

undermine the global

consensus required

to deliver global

infrastructures

Benefits of new

technology will be

eroded if business

change is not

managed.

Integrate reporting changes

with business change initiatives

underway within UCL

Reporting provides a view on

business performance. It is a key

enabler to letting the business

see change happen, and is a

powerful demonstration of its

capabilities

ISD should coordinate

technology projects

with business changes

Projects are rejected

as reporting

requirements

properly costed in.

Reporting will remain

behind the curve of

business need.

Predictive Reporting

may never happen.

Business cases are

subverted.

Reporting needs are

not managed


Recommendations


Recommendations


who


done

Evolve Management Systems

Architecture and Development

teams to a Business

Intelligence Competency

Centre (BICC) model,

beginning with a pilot team,

alongside migration to standard

technology platform and

processes.

Enables roles to be redefined,

staff to be trained and new

processes to be implemented in a

controlled manner that can be

used to demonstrate benefits and

refine approach to deploying and

supporting new technology and

processes.

Business and

Management Systems

to agree Support

Services Division and

MS team to form part of

pilot, based on holistic

view of least risk,

greatest readiness

(existing roles, skills)

and tangible benefits.

May be difficult to

establish if business

as usual pressures

distract the team.

Full benefits will not be

delivered unless ISD

owns the architecture

and define standards.

Deliver training targeted at

needs of specific user

communities (managers, super

users, users) to equip users

with understanding of:

• Reporting tools

• What reporting needs they

can meet themselves

• What else is possible via

the overall reporting

environment and supporting

processes.

Maximises take-up and

exploitation of investment in

technology, standardisation and

process change.

Minimises tendency to develop

alternative means of accessing

information when not able to do

so through existing tools and

processes.

Self Service options reduce

support overhead

Confident use of data facilitates

improved decision making

Training must be

delivered as part of the

overall roadmap and

must be aligned with

the business change

management work

stream to ensure that

all aspects of the new

reporting environment

are understood, not

simply the new

technology.

Dependent upon

clarification of roles

and responsibilities.

Dependent upon tool

selection.

May find some users

cannot master the

required tools.

Benefits of new

reporting technology

will not be delivered if

users do not

understand what

reporting is available,

how to use it, and what

is possible.


Recommendations


Recommendations


who


done

Implement support helpdesk for

reporting users, to cover new

reporting technology and tools.

• Provide a means to report

problems outside of normal

working hours.

• Integrate processes with

support given through

Support Service Divisions

Information Offices / IT

teams e.g. by routing ‘how

do I?’ requests to divisional

super users.

• Integrate with process for

meeting new requirements.

Ongoing exploitation of

investment through increased

confidence in support for new

reporting environment.

ISD to identify

extension of the help

desks to encompass

new reporting tools.

Defines first and

second line support

structures around

helpdesk and BICC

experts.

Poor implementation

may lead to:

• Poor take-up of

the toolset.

• Risk of reversion

to offline excel

databases.

Benefits of new

reporting technology

will be eroded over time

as users revert to

‘offline’ methods (e.g.

data dump to Excel)

when support is not

available to enable

them to use reporting

tools or when process

for meeting new

requirements is not

clear.


Recommendations


Recommendations


who


done

Technology Standardise on a single

technology architecture to meet

future UCL-wide reporting

requirements.

• Reduced complexity and

effort to integrate data from

various source applications,

addressing current issues

and meeting future needs -

standard platforms allow

reuse of common building

blocks.

• Increased efficiency of

delivery for training, support

and development, through

common skill sets and

common tools.

• Cost savings through

consolidated licensing.

• Enabler for common

processes and governance.

• Managed deployment and roll

out of the technology.

A programme of work

to be defined, with

sponsorship from both

Management Systems

and senior stakeholders

in Support Service

Divisions.

Programme will be

tasked with selecting

the appropriate product

that to fit the

architecture. Whilst the

products identified in

Section 7 have broadly

similar capabilities, cost

is clearly an important

factor. However, the

importance of users’

perception of

comparative ease of

use should also be a

significant criterion in

the selection.

Implementation is a

full programme of

work requiring

appropriate risk

management.

Failure to implement

programme

governance may

jeopardise

implementation.

Proliferation of point

solutions will continue

and, whilst some

efficiencies could be

made by standardising

processes and

governance, UCL will

become increasingly

constrained by the

challenges of

integrating between

different technologies to

provide cross-functional

reporting and ease of

use that the business

requires now and in the

future.


Recommendations


Recommendations


who


done

Implement Pilot Data Marts

(containing reusable data,

populated using common

extraction processes, initially on

a function-by-function basis, but

within a warehouse architecture

design for Global use)

Align these to a Common Data

Model.

This creates a consistent view on

the transactional data and

relieves the transactional systems

from unnecessary loads involved

in retrieving data for reporting.

Allows consistent data model to

be developed and implemented

function-by-function, ensuring that

future reporting requirements are

met with reference to this model,

but acknowledging that this is a

significant task.

Piloting the Data Mart allows skills

to be developed, architecture to

be refined, timetables to be kept

short, and lessons to be learned

for future data marts.

Short focussed Pilots also allow

confidence to be developed

among users

Project Teams will build

individual data marts as

part of a projects

deliverable set.

The Design Authority

will set out the

necessary architecture

and design to ensure

that each mart built

contributes to a larger

warehousing whole for

UCL

A division or systems

should be selected for a

pilot data mart

The Pilot Data Mart

suffers scope creep,

and overruns,

destroying

confidence in the

architecture

The pilot becomes a

divisional solution by

losing sight of its

obligations to the

architectural design.

An Enterprise Data

Warehouse led strategy

should be avoided until

intended benefits of

standardised approach

have been

demonstrated and the

case is proven for

further benefits through

consolidation of Data

Marts into an Enterprise

Data Warehouse.

Real business issues

are not addressed

Another spot solution is

built


Recommendations


Recommendations


who


done

Implement Pilot Portals to

provide common user

interfaces to reporting

functionality, secured by single

signon and clear data

permissions.

A Pilot portal allows user

interfaces to be designed and

tested.

Lessons can be learned (cf Data

Marts)

A Division or

stakeholder group

should be selected as

the focus for the portal

Risks as per Data

Marts, plus the

heightened risk of

destroying user

confidence in the

toolset.

Self Serve options are

not explored

Unser interfaces remain

unfriendly, hiding good

work behind the

scenes.

Migrate function by function

The final objective should be a

single point of access to all

reporting from within a common

portal.

Functions should be logically

sequenced, dependent on

prerequisites and relevant

milestone events.

A detailed roadmap is

developed.

Reduces overall risk and effort to

implement.

Allows benefits to be

demonstrated, and lessons

learned.

Facilitates managed transition by

Management Systems to new

support model, whereby they

provide the architecture and

standards, support and training.

Costs of implementation may be

phased and properly planned

Current Projects can be co-opted,

minimising start up time.

Smaller more focussed projects

have higher success rates

Business and

Management Systems

to agree which function

should be the pilot for

deployment of the first

Data Mart, based on

holistic view of least

risk, greatest readiness

(existing roles, skills)

and tangible benefits.

Full programme and

risk management is

required to manage

migration.

Full time architecture

teams will be

required to map the

full target

architecture, and

identify detailed

planning issues.

Inadequately

resourced

programme will

jeopardise global

objectives.

Higher risk and higher

effort involved to

implement across more

than one function

simultaneously.

Difficult to design a

“final” system without

understanding what

might be achieved


Recommendations


Recommendations


who


done

Automate and standardise

reports, minimising dependence

on manually crafted reports.

Reduced manual compilation time

and wasted effort correcting and

responding to errors.

Core reports defined as part of

clear Service Levels are delivered

at minimum cost.

Adhoc reports are delivered

through thoroughly tested data

marts

Management Systems

and Support Service

Divisions to identify all

reporting processes

that are currently

performed manually

using ‘offline’ data and

determine which can be

automated. These

reports to be used as

‘test cases’ for

development of

automated standard

reports, to deliver

immediate tangible

benefit from the new

reporting environment.

Resources may be

sidetracked if

divisions continue to

ask for more reports

whilst data marts are

being built, are

requirements are not

managed.

Quick wins not

delivered & current

issues not fixed,

benefits not realised.

Existing manual

processes will remain if

not tackled as part of

initial implementation.


Recommendations


Recommendations


who


done

Provide self service tools for

power users / analytic reporting

requirements.

‘One source of the truth’ through

providing power users simple and

effective tools to work from the

same data source as other

reports rather than export

reporting data to be processed

offline (i.e. Excel)

Programme Boards to

ensure that project

proposals give proper

consideration to

reporting requirements


will check proposals

properly consider

reporting needs, and

must ensure, either that

standard tools are

made available and

users trained, or that

reporting services

already built are co-

opted.

Training is not

adequate for power

users.

Some users may not

have the competence

to master modern

tools.

Any investment in

technology will be

wasted, as power users

continue to develop

local solutions.

Further, UCL will not

achieve global reporting

services if power users

are not properly

equipped and

supported.


Recommendations


Recommendations


who


done

Only allow access to data via

approved portal, using single

sign on, with clearly defined

permissions to ensure data is

properly accessed.

Improves user experience and

take-up - one-stop shop.

Enables more effective support to

be provided, potentially at lower

overall cost, as variation in

access methods and tools is

reduced.

Reduces overhead in managing

access permission to multiple

reporting portals or tools

The preference is to

prove, through

business change

management and

training, the benefits of

using a portal for all

reporting needs and

encourage users to use

this approach.

However, this must be

coupled with a phased

withdrawal of support

for accessing reporting

data through ‘back

door’ and non-standard

methods.

Failure to

communicate

benefits, or to ensure

portals have all

relevant data, may

lead to users

continuing to develop

and rely on offline

data sets

Reduced benefits,

particularly as a result

of cost of supporting

users who are

accessing reports

through various tools.


Recommendations


Recommendations


who


done

Review the Crystal Reports

deployment to the Remedy

helpdesk systems in 18 months

Ensure that the standalone

premise for Remedy remains

valid. If not, formalise integration

requirements

Architecture Managers

in conjunction with

Design Authority and

helpdesk management

Crystal Reports is

allowed to extend

scope beyond the

helpdesk workflow

without consideration

for wider standards.

Crystal Reports is

used as an excuse to

justify other reporting

requirements being

met by locally

selected reporting

tools

Help Desk reporting


reviewed within the

context of a maturing

reporting environment,

and potential

integration

requirements are

ignored, or are

implemented in non

standard way

Governance Establish (or extend from

nUCLei) a Design Authority to

promote and enforce

adherence to reporting

architecture.

Maximises return on investment

in new reporting technology and

processes by ensuring that all

new requirements are

incorporated into the overall

reporting architecture and that

any requirements which may

require non-standard solutions

can be properly vetted.

Overheads arising from non

standard solutions are contained

and can be managed down.

UCL Executive and

ISD, building on

principles adopted for

nUCLei but with remit

for proposed UCL-wide

reporting architecture.

That better control is

perceived as an

overhead and brake

on some requirement

sets

Full benefit of proposed

UCL-wide reporting

architecture will not be

delivered if non-

compliant solutions are

implemented and

require additional

maintenance, training

and support


Recommendations


Recommendations


who


done

Implement procedures to

prioritise demands made on

MS, manage dependencies and

mediate with business

stakeholders to manage

expectations.

Prioritisations should be based

on clearly stated benefits, and

reviewed across all CSS

requirements

Reduces duplication of effort via

top-down management of new

reporting requirements

Maximises capacity to deliver

against agreed business-wide

priorities rather than cons

Bodies that review and

prioritise projects will

add objective criteria

and a CSS wide remit

to their reviews.

Requests for new

reports or new data to

be incorporated into

Data Marts to ensure

that requests can be

justified in terms of

need and benefit, to

prioritise requests on a

UCL-wide basis, and to

moderate supply

against demand in

meeting such requests.


perceived as an

overhead and brake

on some requirement

sets.

Downgrading of

Divisional priorities in

CSS context may

lead to unilateral,

silo’d developments

‘Who shouts loudest’

will continue to drive

new developments,

with an impact on

benefits if divisions

resort to meeting their

own requirements

outside of the

standards and

architecture managed

by MS.


Recommendations


Recommendations


who


done

Only build standard reports that

link to agreed KPIs and PPIs, or

meet specific external reporting

needs.

UCL must manage what is

important, and retain managerial

focus.

Clear metrics create an outcome

led culture.

Although adhoc reports may

sometimes require non standard

metrics, care must be taken to

provide a common framework to

which all parts of UCL conform

The nUCLei project

team will deliver

defined PPIs.

UCL executive set clear

KPIs.

HEFCE and other

funders set clear

reporting criteria.

Steering committee

sets priorities, and

should, with the Design

Authority, promote

adherence to common

reporting frameworks,

and challenge reporting

requirements that seek

to report other

information

Users become

frustrated by stricter

challenge to reporting

requirements

justifications

Users fail to

understand value of

coherent metrics

structures reporting

on defined

processes, and

continue to report to

local standards on

local databases

Reporting by rote on

non critical metrics

consumes scare

resource.

Line managers manage

to the wrong criteria.

UCL becomes driven

by what is reports, not

what’s important

(process, not outcome

led)

Reports are developed

that report unnecessary

metrics


Recommendations


Recommendations


who


done

Define clear Service Levels for

different users (Executive,

Power Users, Standard Users,

external users) and various

services (e.g. new standard

reports, extension of data

model, data correction, access

permissions).

Agree how these Services are

sponsored and funded, by MS,

Divisional IO, or other

Manages expectations of

reporting users, for example, in

terms of time taken to deliver a

new standard report or to

populate a data mart with further

data.

Develop a more formal basis for a

managing the relationship

between MS, as the suppliers of

the UCL-wide architecture and

standards for reporting, and the

Support Service Divisions as

customers.

Distinguishes business as usual

services and project requirements

(which will need specific

sponsorship).

Workload can be better planned;

additional reporting requirements

are properly challenged and

planned for, new work does not

impact scarce resources

This should build on the

current work in ISD to

establish ITIL principles

for application delivery,

ideally incorporating

service levels for

reporting alongside

those for other services

Programme Boards will

be required to approve

requirements outside

agreed levels


perceived as an

overhead and a

brake on some

requirement sets

Unclear expectations

are hard to manage

from both sides. The

tendency for Support

Service Divisions to find

their own solutions to

meeting their reporting

needs within

acceptable timeframes

would be expected to

continue.

Unplanned workload

will continue to impact

scheduled work, and

requirements will be

delivered by Divisions

without proper context,

reuse or justification.

Costs will remain

unmanaged.


Recommendations


Recommendations


who


done

Standards need to be defined /

refined and applied globally,

and enforced

Reduce effort involved in meeting

new requirements from first

principles.

Reduce effort in future

maintenance / change of reports

developed on common standards

with common tools.


should be the custodian

of standards


should enforce

standards, through a

Quality Assurance role

on Project Boards


should liaise with

internal audit to provide

Data Assurance to UCL

executive and funders

Standards are

perceived as a

constraint and

subverted.

Multiple standards and

designs continue to fuel

the existing reporting

and data quality issues.

Continue the Process stream of

nUCLei to standardise

processes.

This provides a clear definition of

what is being measured Continue

work on PPIs/KPIs. This in turn

defines how things are measured,

and what measures are

important.


will assume

custodianship of the

processes delivered by

nUCLei, and should

ensure they form a

design baseline for

future projects

Process definition

work is not delivered

in time for reporting

design work.

Undocumented and

non standard

processes cannot be

reliably reported

against.


Recommendations


Recommendations


who


done

Clear documentation standards

should be established

Time taken to find out “how things

work” is reduced.

UCL risk of knowledge loss

(retirees and leavers) is reduced

Fault fixing is expedited.


will mandate for

documentation as a

project deliverable.


will provide for a library

of systems and process

documentation, to be

available to projects

and helpdesk

Documentation fails

to be properly

prioritised, and is

delivered late of

incomplete.

Effort will continue to be

wasted on rediscovery

of current practices.

UCL may lose

understanding of critical

systems, rendering

them unsupportable

(this situation is

developing with Student

Accommodation

Assignment routines

Establish a formal programme

to manage the delivery of these

recommendations

Proper governance of the

programme is established

Training and change

requirements to embed the

technology are considered,

planned for, and managed.

Reporting users are engaged in

the programme

A Business Reporting

programme board will

be set up to take

executive responsibility

for the programme.

A Programme Manager

will be tasked to

develop the roadmap

and driving ensuing

plans

Poorly implemented

management controls

allow the programme

to lose focus, and

devolve into separate

reporting projects,

undermining benefits

Global reporting is not

seen to have executive

commitment

Reporting continues as

a series of projects

addressing specific

needs.

Issues identified by this

report are not

addressed.

Business Change


appropriately

addressed


Delivering the Recommendations

Reporting Requirements and Capabilites 1.0.doc ABeam Consulting / 107 Delivering the Recommendations

6. Delivering the Recommendations

Implementing the recommendation requires a programme of work with streams addressing all categories

of work. This should therefore be thought of a holistic change programme, rather than simply a

technology implementation.

6.1. Developing the Roadmap

Both the landscape at UCL, and the extent of the recommendations, mean there are many factors to

consider when developing a roadmap. A roadmap is a route to delivering the agreed vision and

recommendations. It shows the major activities and dependencies, and will generally depict greater

certainty in the short-term activities required to initiate the programme than the longer term. The aim is to

bring together all pertinent aspects, be they organisational, process-related or technical, to show the

proposed sequence of events. It will also provide the context against which other projects, such as

tactical solutions or upgrades, can be evaluated to ensure that the benefit of these is real and will not be

made redundant as a result of work required to be delivered the roadmap.

By setting out the roadmap we can:

• See what we need to do, in what order (i.e. identify phases of work),

• Identify quick wins and enablers,

• Retain flexibility for the future by avoiding monolithic initiatives,

• Understand where decisions and investments are made and why.

• Be sure that all the work that is contributing to delivering the required outcomes and intended

benefits, and

• Understand the scope of the whole programme, and what resources we might need.

A roadmap is not a plan of work; although plans may well be associated with shorter term steps on the

roadmap. Instead, it identifies priorities, dependencies and constraints and provides a frame of reference

that will allow adjustment, if required, in response to factors outside of its scope.

In building the roadmap the following aspects are considered:

• All significant activities required to deliver the overall goal.

• Relevant current activities that must be assessed within the context of the overall goal.

• Sequencing and dependencies

• Constraints, which might include funding cycles, external events, or other factors which may constrain

both start and finish dates.

• Timelines- these are likely to become less certain over time (e.g. monthly / quarterly initially, annually

later). These show likely windows of activity.

• The major streams of work or sub-projects that are required to deliver in parallel

Fundamentally, it shows the main activities that must be initiated and managed to take the work forward.




6.2. The UCL Roadmap

Taking into account the recommendations of this report alongside projects in progress, we can identify

broad groupings of constraints and dependencies:

1. Related work already underway, which may need to be re-aligned or with which the roadmap may

need to be aligned:

• End to end process views and PPI development from nUCLei

• Design Authority initiative (part of nUCLei)

• IRIS reporting project

• HelpDesk Crystal Reports deployment

2. BOP accounting project (part of FRP)Recommended work that could be initiated within current

capabilities:

• Refocused support for existing tools.

• Change management activities to create a shared vision for the benefits of a coherent

Business Intelligence environment.

• Improved project approval and prioritisation discipline giving better use of finite

resources.

3. Recommended work that cannot begin without funding approval:

• Investment in enterprise reporting technologies.

• Organisational changes required to fully exploit new technology.

4. Finally, other constraints should be recognised:

• Product upgrade points & end of support dates

• Possible Charts of Accounts review / restructuring. The identified work streams are as follows:

Business

• Business change activities, beginning with communicating the value of a coherent

reporting environment and the required foundations in terms of governance and

standards.

• Standard best practice processes

• Leveraging the Design Authority to bring global information management into view.

• Focus resources on key activities

• Defining a sponsorship model whereby only the BI/Reporting standard is corporate-

funded and any non-standard BI is paid for by the individual department or business

unit.

Technology

• Selecting a BI/Reporting standard

• Contain non-standard tools by reference to the Design Authority

• An effective rollout - undertaken in phases, bringing in the BI/Reporting standard by

system of department, and phasing out non-standard parts in turn. Phasing allows

UCL to

o Select champion of the BI/Reporting standard internally, support them through

extensive end-user and IT training, and create a snowball effect




o Ensure careful rollout so that both IT and end-users are sufficiently prepared,

implementation is a positive experience, and issues become lessons learned,

rather than problems.

Considering these factors, ABeam proposes the following views on a roadmap to deploy an enterprise

reporting strategy.

6.2.1. Roadmap

Report Graphics

9

Recommendations identify key activities to be driven

Str

eam

s

Bu

sin

ess

Arc

hitectu

reO

rga

nis

atio

n &

Pe

op

le

Underway

Technology

Pilot Portal

Data Warehousing

Common Portals

Technical Architecture

Align Reports

Metrics

Standard Toolset

SelectedCommon

Data Model

Service Provision structures

review

Cross Departmental

process consolidation

Administration Professionalisation

Design Authority

Reports Help Desk

Training and

Support

Roles and Responsibilities for

Information provision

Reports Delivery

SLA

Resource Planning


Report Prioritisation

FY09 FY10 FY11

Pilot Data Mart

BAU

Projects

FY13

Governance and Process

Align IRIS

CoA Redesign

Embed BICC

Common Toolset

Pilot BICC

Promote Reporting

Vision

Qualify and Validate Roadmap Activities


It is important that a global activity is initiated to drive a technology independent reporting baseline,

clarifying and standardising business reporting needs and standards. This stream contextualises the

remaining streams

Technology

Supported by the Design Authority, technical reporting projects deliver reporting functionality. Lessons

learned from IRIS will help shape pilot projects, each targeted to help shape the final architecture, but

building on a technical design delivered up front. Over time, further projects will deliver into the common

architecture, building and increasingly integrated reporting infrastructure




Governance

The nUCLei process stream provides a single definition of UCL activity, and will define PPIs setting out

how this activity is measured. These documented processes, allow clear reporting needs to be identified.

A steering committee is set up to coordinate and streamline reports development activities. In addition,

service standards for report provision are implemented, and reported against. Finally, the CoA is re-

implemented, streamlining reporting provision, and unlocking automated reporting from BI toolsets.

Organisation and People

Activity already underway in the faculties to promote managerial disciplines needs to be matched with the

reporting service skills to offer the information needed to manage. Development and support roles are

clarified, responsibilities formalised, and interactions with information users made clear. Resource

planning is facilitated by clearer load planning emerging from the steering committee. As pilot projects

deliver technology infrastructure and lessons learned, the BICC is formally established as a centre of

capability excellence.

6.2.2. Technology View

Within the technology stream, a portfolio of projects needs to be scheduled to move the infrastructure

base towards the target architecture (Technology Project, p69).

This presents a more scheduled view of how the underlying systems and architectural components need

to be managed, and considers their sequencing and interdependencies.

It also represents the move from local solutions to a common portal, where a user’s sign on provides

them with personalised access to specific reports and other services. Users may be both internal and

external. To achieve this objective, the key building blocks along the way are:

• Pilot projects that test and prove the technology on specific data sets – e.g., HR Portal (bringing

together MyView and HR standard report packs), and Financial Reports (where better analytics

are urgently needed). Pilots should prove the technology, verify the architectural design, develop

confidence in all stakeholder groups, and provide lessons learned for subsequent work. They are

not standalone projects, and attempts to make them so should be blocked.

• Data Marts that consolidate data from physical transaction systems according to a Common Data

Model (CDM). E.g. IRIS

• Parallel activities in each function that will need to be coordinated – for conformity to Architecture,

and for interdependencies that the architecture will make visible.

• Key decision points:

o Choosing the technology provider

o Deciding whether to rewrite the Chart of Accounts

o Responding to the emerging product roadmap for Business Objects Planner (BOP)

o Deciding whether to maintain BO universes in Portico.

• Key conflicts:

o Ideally, IRIS should draw on a Data mart developed to support Financial Management

reporting, but as this is running, it will need to reconcile this requirement with developing

a spot solution to maintain its own timetable.




On this view, the streams show stakeholder groups: ISD, CSS Divisions, and external users. Aligned

against these streams are a series of projects that will be required to be undertaken to implement the

technology aspects of the roadmap.




Activity Description

BI Toolset Choice A process to formally gather requirements, and tender for a standard BI

technology for use across CSS.

Financial Data Mart The development of a Financial Data Mart to support I&E reporting.

BOP The Financial Reporting Project using BOP technology, delivering forecasting

and budgeting reporting, and providing structure relevant finance processes

COA rebuild? A decision point in respect of the future of UCL’s COA. Once BOP has

completed, it will become necessary to decide if a rewrite is beneficial.

BOP II A subsequent phase of the current Financial Reporting Project, the scope of

which has not yet been defined but is expected to build on the capability of

BOP to deliver further Financial Planning and Management Accounting

reporting

IRIS The IRIS project spans divisions, and may be able to deliver common

architectural components

Portico rollout The current Portico programme will continue. Consideration should be given to

the extent to which it can deliver common architectural components.

BO Y/N Once Portico is implemented, a decision will need to be taken with respect to

the viability of the standard BO universes for future reporting needs. This

decision will need to consider the selection of the “standard” reporting toolset

and the maintainability of the Portico universes.

Portico Portal Once a standard reporting toolset is selected, there is an option to develop a

registry and student specific portal using the toolset, which may supersede or

augment the portico interfaces...

HR Portal Consolidates current reporting outputs into standard “point in time” report packs

within HR portals using the chosen BI Toolset

Internal Portals Common login pages, using single signons and permissions to give access to

data and report across divisions

FAMIS/CMIS Need to be brought into a common portal, cross linking estates data to courses,

students, finance.

CRM Data mining tools need to be brought in to identify new funding sources, using

the standard BI toolset. These should be integrated over time into the Internal

portal

MyView, the UCL

website, and the

HEFCE return

These are potential portal pilots, each bringing together self serve capabilities

for external users. Ultimately they need to be brought into a single portal where

services and data are determined by login.

Architecture, Process

and Metrics

Continues the nUCLei activities, and recognises that they are required enablers

of the whole design. Although they will evolve over time, they set a backdrop for

all other work

Systems and Data

Mapping; CDM

A common data model will identify master data sets that are referenced by Data

Marts. Additionally, it must reconcile and rationalise differing data structures

across systems, and set validation and quality standards for data.

Design Authority Sets many of the standards other projects need to adhere to.

Crystal Reports An existing project implementing Crystal Reports as a fixed scope standalone

reporting suite for use on the Remedy platform used by the ISD helpdesk.




6.2.3. Timeline

Although the technology view suggests that choosing a toolset may be a sensible first step, the main

roadmap and the budgetary timing constraints, suggest otherwise. Indeed, there is preparatory work to do

prior to selecting a tool, for example, defining business and technology architectures that the tools must

work with and support, and the budgetary cycle which suggests that the tool could not be invested in until

Q3 2009. The preliminary work will also provide a robust requirements list that BI vendors can be invited

to tender against.

We can breakdown the roadmap by activity type:

• Quick Wins – activities that will generate benefit in the current financial year, or quickly remove

longstanding and painful business issues

• Enablers – ground work necessary to allow later projects to release benefits

• Pilots and other Projects – managed projects designed to deliver interim and strategic benefits

in line with the vision

Further, the timeline provides for 3 phases of work:

1. Pre budget approval - Activities prior to UCL approval for toolset investment must be done with

the existing resources.

2. Selection - A Tender activity is recommended to finalise the tool selection. In addition to the

factors discussed in section 7, this will be able to factor in usability and other factors based on

feedback from Phase 1 activities.

3. Full Reporting Implementation – fully developing the target infrastructure on the chosen

toolset, building from pilot projects and developing momentum to the global integrated design,

fully aligning the implementation of the toolset with business change activities.

6.2.4. Initial Activities

For each of the early stage roadmap activities, ABeam has set out a brief objective, benefit and cost

driver. These should form the basis for project mandates for these activities




Activity Type Description Value Cost

Qualify and Validate Roadmap

Activities

Enabler Develop a structured programme based on the

roadmap, with relevant governance structures.

This will formally manage the implementation of the

recommended Reporting Strategy, and formalise

benefits.

(Interviews have provided mostly anecdotal information,

so costs and benefits identified need to be tested

formally).

The programme will be able to

initiate specific activities within

a broad framework, allowing

costs and benefits to be

monitored.

The programme will be able to

coordinate multiple activities to

prevent spot solutions and

ensure integration deliveries

Management resource

Reporting Architecture Quick

Win &

Enabler

Coordinate a UCL wide architecture for business

reporting needs, that:

• Consolidates UCL reporting requirements

• Makes explicit the users or reports and the processes

required to access the

• Identifies reporting schedules, formats, sources data

mappings, and links to KPIS and PPIs.

Allows reuse, and modular

reporting functions

Identifies redundancies in

reporting processes

Identifies standard data

sources

Contributes to understanding

of roles and responsibilities

required

Allows the defection of clear

requirements for pilot reporting

projects

Allows identification of

sponsors for subsequent

reporting projects

Business Analysis

resource





Resource Planning Quick

Win

Implementation of a clear UCL wide process to control

the assignment of resources to requests for reports to

be developed.

The process needs to include the full requirements

process from report end user through Support Services

Divisions to ISD.

Resource is assigned to high

priority work

Similar requirements can be

consolidated

Low priority work does not

drain resource

Users expectations can be

managed

Management time to

implement

Management resource to

periodically review

workload.

Report Prioritisation Process Quick

Win

Implements a clear process to prioritise report

requirements across UCL.

The process will use clear cost / benefit cases to provide

objective criteria to manage conflicting priorities across

Divisions

Identify capacity and capability constraints, and

implement strategies to manage.

Priorities are established

globally

Workload may be reduced

Capacity is proactively

managed

Management time

Align reports Quick

Win &

Enabler

The nUCLei process review should be recognised as a

key component of the report strategy, as it provides

common definition of processes and metrics.

External reporting requirements (HEFCE, REF, etc) also

have specific reporting needs

These provide frameworks for validating current

reporting outputs, correlating the reports listing provided

by Reporting Architecture with nUCLei PPIs, KPIs and

external metrics

Redundant reports can be

discontinued.

Redundant reports will not be

redeveloped in any new

toolset.

Standard metrics improve

information quality

Standard metrics reduce risk

of inaccurate funder

submissions

Changes to requirements can

be impact assessed.

Business Analysis

resource





Design Authority Enabler Extend the Design Authority remit to address

• Business and Technology Architecture designs

• Reporting standard

• Common Data Models

Additionally, it should coordinate activity with :

• Project QA and audit to ensure compliance

Common design principles

allow report integration and

ease of development and

maintenance.

Design Authority resource

ISD Architectural resource

Project Resources

Align IRIS Project The IRIS project should be recognised for its Data Mart

component.

The design of its reporting architecture should be

aligned with the UCL Reporting Architecture.

Clarify Reporting Architecture dependencies, specifically

the potential conflict between IRIS schedules and

selection of a global reporting toolset.

Begin to lay down architectural

framework

Begin the cultural shift to

global thinking.

Avoid another silo’d solution

Early delivery against global

reporting solution

Review design of IRIS

configuration to consider

global report context.

Roles and Responsibilities Enabler Define clear roles and responsibilities for the provision

of reporting services, from ISD through the divisions, to

the end users

Define role and remit of the BICC

Define Reporting Service Specifications

Clear ownership of workload

Clear alignment of resource to

workload (underpin capacity

planning)

Alignment to ITIL requirements

Prepared for SLAs.

Business Analysis to

provide definition

Management Team to

implement new roles

Help Desk Quick

Win

Extend helpdesk services to implement Reporting

Service Specifications

Identify first and second line support through helpdesk

staff and Reporting Services and Tools Experts

Implement first line support.

Capture and document best practice.

Users have clear access to

Report Services support.

Calls and routed, resolved,

and reported more efficiently.

Consistent support services

are facilitated by lessons are

learned and developed best

practice.

Help Desk staff





Technical Architecture Enabler The nUCLei Architecture project should be recognised

as a key component of delivering an integrated

Reporting Architecture

This should be extended to address the Common Data

Model, Data Mart and Portal architectural requirements,

to provide global reporting architecture for Reporting

project implementations.

In conjunction with the Design Authority, standards for

Reporting implementations should be determined.

Reduced design time and

improves quality of impact

assessment for projects

Reduced development time

through use of standard and

reusable code and data sets

Reduced maintenance

overhead through full system

documentation.

ISD Architectural staff

Promote Reporting Vision Enabler A communication programme to promote the value of

coherent business reporting, and progressively build

understanding of the work involved.

Specific activities related to individual roadmap activities

People understand the value

of the approach and support

rather than block subsequent

activities

Allows concerns to be

captured and addressed at an

early stage.

Identify overlaps with other

UCL activity

ISD Management


Selecting a technology to meet UCL requirements

Reporting Requirements and Capabilites 1.0.doc ABeam Consulting / 107 Selecting a technology to meet UCL requirements

7. Selecting a technology to meet UCL requirements

Now we know the roadmap, we need a toolset to standardise on. This section looks at trends in the

technology marketplace, and assesses current offerings. Then, following a two step process (shortlisting

and selecting), ABeam is conditionally able to recommend that UCL deploy Microsoft’s Business

Intelligence suite.

7.1. The Maturing Marketplace

Vendor Trends

Acquisitions in the Business Intelligence market are the norm. Historically, the trend has been for smaller

vendors to develop with a focus on one of the 3 pillars of BI (Analytical Tools, Enterprise Reporting, or

Monitoring and Dashboards) to then be acquired by a larger vendor wishing to increase its presence in

terms of breadth of product offerings and market share.

Before 2003 the marketplace had seen an oligarchy of medium-sized vendors, reflecting the reality that

most businesses needed to invest in products from at up to five vendors to fully address their needs. But

driven by a need to manage vendor costs, organisations began trying to reduce the number of vendor

relationships. Vendors, almost without exception, responded by broadening their product suites through

acquisition. By 2007 the market had consolidated to four large vendors with comprehensive Business

Intelligence product suites, leaving a series of smaller specialists with niche offerings. The transition from

the best-of-breed market to an integrated suite market has caused difficulties for many vendors, and three

erstwhile major BI players, Hyperion, Business Objects and Cognos have been acquired by the 3 major

ERP vendors, Oracle, SAP and IBM.

But the market continues to develop, with Microsoft growing its footprint rapidly.

Further, SAP has always played an influential role in promoting Business Intelligence and Enterprise

Performance Management as an integrated solution to CFOs of large businesses, under straplines such

as Integrated Information Management and Financial Performance Management. But although it's nice to

have static reporting or presentation tools, the real benefit is real-time business insight, and for that you

need the ERP data to be accessible as information in a data warehouse. In fact you need cubes to not

just access the data quickly, but also to analyse that information and to create local business views of it,

without needing input from the IT department. And whilst UCL does not need to manage all of its

business in real time, some parts of its operations do. Admissions cite a need for real time updates on

applications at peak times.

For example: UCL not only want to know how many students they have, and fee income, but would also

like to know the number of female and male students, foreign students, countries or origin, applications

per faculty and course, and so on. UCL would like to know how budgets and actuals behave – by

department and by spending category across UCL. And they would like to know it a lot faster than they do

now.




This is why the role of big vendors (SAP, Oracle and IBM) came to the fore. SAP was the first to

recognise the power of a strategic approach, so invested heavily on developing their vision. As they were

not able to cope with the pace of market developments on their own, they also looked at acquisitions.

Oracle saw the real threat posed by SAP, and responded by acquiring Siebel and Hyperion, whilst IBM

always had a number of solutions, some complementary, some competing with each other. But for

Business Objects, Cognos and Hyperion, unable to keep the pace, they have been absorbed. Of the

remaining players in this market, only Microsoft has the financial power to go it alone.

Product Trends

Report Graphics

7

Pervasive Business Intelligence

CEOPresident

InformationTechnology

Finance Marketing Sales ProspectsHuman

Resources

Based on: CIO.com Webinar “Pervasive Business Intelligence”, Michael Corcoran.

Data Warehouse

Operational Data Store

Operational Data

Process/Transaction/Web Service/Documents RFID

STRATEGIC

TACTICAL

OPERATIONAL

The vendor offerings meet a real need. And, over recent years, there has been a shift in the perception of

the reporting capability of organisations, from its origins as simple, printed reports circulated on paper, to

a worldview where a sophisticated environment is deployed that is capable of delivering key bits of

information to decision makers, and deliver it in a useful format, at the right time, and with a minimum of

noise from extraneous data.

Delivering such a rich informational experience requires a coherence of structure within an organisation,

not just technologically, as the systems need to be integrated, but organisationally, as an organisation

must manage metrics structures, end to end processes, and good governance to ensure that the

information that emerges is both factually correct and meaningful.




To do this, an organisation must look at data at three levels:

1. Strategic: An organisation’s Executive and Management stakeholders must have clear data on

which performance can be tracked, and decisions can be based. This means clear and focused,

dashboards reporting on relevant KPIs (and which may have different content and different

management levels. It means management accounts that are owned by budget holders, but

which collate to give overall performance, and it means clear signals emerging from the data

about trends to that action can be taken

2. Tactical: Power Users need to be able to dig into data to diagnose warning signs that emerge at

strategic levels, and to let line managers have understand the issues they have to deal with day

to day. They need to prepare more sophisticated analysis that that afforded by strategic

dashboards, and make this available to all stakeholders that need it. This may include detailed

annual accounts, of standard reports for a variety of stakeholders. And they need to be able to

continually improves the richness of information (while keeping it relevant) and responsiveness of

service to Strategic and Operational Users

3. Operational: Operation Users consume and act on information provided. They will use self

serve, pre-prepared reports, portals onto information services, monitor day to day performance,

circulate information to others, support customers of the organisation, and a host of other

activities.

In addition, organisations must provide a technical infrastructure to support such a chain of information –

Portals, supported by Report Libraries and Data Warehouses, in turn underpinned by coherent Data

sources, populated by transactional and batch interfaces, all governed by clear rules on data quality,

permissions and other considerations.

Vendor consolidation has brought products together into suites that aim to support all aspects of this

business and technology stack. For example, Oracle has bought Siebel and Hyperion, bringing analytic

and presentation capabilities to its original data management core.

ERP mega-vendors now dominate the Business Intelligence market, with a market share of over 70%.

ERP and BI will become evermore, supporting Strategic, Tactical and Operational layers of businesses

through an integrated and robust information environment. This trend looks set to continue.

And, at present, these mega-vendors are:

o SAP/Business Objects

o Oracle/Siebel/Hyperion

o IBM/Cognos

Close behind them, Microsoft is the top challenger, rapidly building their footprint in the BI space.




7.2. Selecting a BI technology

7.2.1. Shortlisting

However, when choosing a BI standard, it is important to not only evaluate the suitability of the

BI/Reporting solution, but also the viability of the solution provider.

Gartner, an industry analyst, provides a view on BI vendors in 2008, in their standard Magic Quadrant

format, using the following evaluation criteria:

Ability to Execute

Vendors are judged on their ability and success in

making their vision a market reality.

Completeness of Vision

Vendors are rated on their understanding of how

market forces can be exploited to create value for

customers and opportunity for themselves.

• Product/Service: How competitive and

successful are the goods and services offered by

the vendor in this market?

• Overall Viability: What is the likelihood of the

vendor continuing to invest in products and

services for its customers?

• Sales Execution/Pricing: Does the vendor

provide cost-effective licensing and maintenance

options?

• Market Responsiveness and Track Record:

Can the vendor respond to changes in market

direction as customer requirements evolve?

• Market Execution: Are customers aware of the

vendor's offerings in the market?

• Customer Experience: How well does the

vendor support its customers?

• Operations: What is the ability of the

organisation to meet its goals and commitments?

• Market Understanding: Does the vendor have

the ability to understand buyers' needs, and to

translate those needs into products and

services?

• Marketing Strategy: Does the vendor have a

clear set of messages that communicate its

value and differentiation in the market?

• Sales Strategy: Does the vendor have the right

combination of direct and indirect resources to

extend its market reach?

• Product Strategy: Does the vendor's approach

to product development and delivery emphasise

differentiation and functionality as it maps to

current and future requirements?

• Business Model: How sound and logical is the

vendor's underlying business proposition? Note

that this criterion has been given no rating

because all vendors in the market have a viable

business model.

• Vertical/Industry Strategy: How well can the

vendor meet the needs of various industries

such as financial services or retail?

• Geographic Strategy: How well can the vendor

meet the needs of locations outside its native

country, either directly or through partners?




These criteria provide axes to provide Gartner’s “Magic Quadrant” assessment of the current vendors:

Gartner sections vendor performance as follows

Leaders - Vendors that are reasonably strong in the breadth and depth of their BI platform capabilities,

and can deliver on enterprise-wide implementations that support a broad BI strategy. Leaders articulate a

business proposition that resonates with buyers, supported by the viability and operational capability to

deliver on a global basis.

Challengers - Offer a good breadth of BI platform functionality and are well positioned to succeed in the

market. However, they may be limited to specific technical environments or application domains. Their

vision may be hampered by a lack of coordinated strategy across the various products in their BI platform

portfolio. Or they may lack the sales channel, geographic presence and industry-specific content offered

by the vendors in the Leaders quadrant.

Visionaries - Vendors that have a strong vision for delivering a BI platform. They are distinguished by the

openness and flexibility of their application architectures, and they offer depth of functionality in the areas

they address, but they may have gaps relating to broader functionality requirements. A visionary vendor is

a market thought-leader and innovator. However, it may have yet to achieve sufficient scale — or there

may be concerns about its ability to grow and provide consistent execution.

Niche Players - do well in a specific segment of the BI platform market — such as reporting — or that

have limited capability to innovate or outperform other vendors in the market. They may focus on a

specific domain or aspect of BI, but are likely to lack depth of functionality elsewhere. Or they may have

gaps relating to broader BI platform functionality. Alternatively, Niche Players may have a reasonably

broad BI platform, but have limited implementation and support capabilities or relatively limited customer

bases. Or they may have not yet achieved the necessary scale to solidify their market positions.




ABeam has considered Leaders from this analysis, and assessed them against key criteria for the

recommendations and roadmap. An analysis of Leading vendors is at Appendix 4

The assessment criteria are:

• Match to the functional needs of the stakeholder groups,

• Non functional criteria

o Availability of skills, resources

o Potential for quick wins

o Viability and future proofing of the roadmap

o Cost

As the Leaders quadrant also includes the vendors that are now used by UCL (Oracle, Business Objects,

Microsoft), they are assessed inclusively within this ranking. As those vendors are quite close to each

other functionally, the main differentiators non functional.

Report Graphics

15

UnacceptableNDoes not support function

Need to compromiseLPoor Fit

AcceptableMAdequate fit

Highly FavourableHGood Fit

Non functionalScoreFunctional

Microsoft

Cognos

Business Objects

Oracle

SAS

Microstrategy

meets

nee

ds o

f th

e s

take

hold

er

gro

up

s

Availa

bili

ty o

f skill

s, re

sourc

es

Pote

ntial fo

r quic

k w

ins

Via

bili

ty a

nd

futu

re p

roofing

of

the r

oadm

ap

Cost

Functional Non Functional

H M H H H

H H M H M

L

LL

L L

L L M

MH

M

H

H H

H

M

H

H M

M

This had led to a clear shortlist of vendors who have a clear capacity to provide BI technologies that meet

UCL’s functional and non functional requirements

• Oracle

• Business Objects

• Microsoft BI




7.2.2. Selecting

Looking at the shortlist in more detail to assess offerings from these vendors, allows us to identify a

preference from the shortlist, although this preference will need to be ratified by formalising requirements

sets, and securing specific costings from the vendors.

ABeam therefore recommends a formal Request For Information (RFI) process should be undertaken

before final selection.

This process should:

• Invite shortlisted vendors to give product demonstrations, to:

o Show end-users, what they can expect;

o Show how UCL requirements will be met.

o Demonstrate specific end-users reports as examples

o Involve end-users, and gain commitment to all demonstrations.

• Formalise Requirements, both functional and non-functional. For example, clarifying:

o How would you rate the ease of creating a report using the product?

o Do the possible report formats (Excel, HTML, text, etc.) meet your needs?

o Was the report information presented in terms you understand?

o Based on the demo, did the reporting interface seem easy to navigate?

o How would you rate the ease of calculating new information from the data given?

o What was the best feature of this product?

o What was the worst feature of this product?

• Confirm pricing

Nevertheless, an assertion can be made, based of information presently available, the offerings from the

short-listed vendors may be compared Criteria BO Microsoft Oracle (SE) Oracle (EE)

Price High Low Medium High Development Environment

Web Access, Crystal Reports

Visual Studio Oracle JDeveloper, Discoverer, Oracle Reports

Oracle: JDeveloper, Answers, Interactive Dashboards, Delivers, Disconnected Analysis, Publisher Hyperion: Interactive Reporting, SQR Production Reporting, Financial Reporting, Web Analysis

Ease of Use - Development Environment

Current Universe designs impair usability

Good Good Varies, depends on Environment




Criteria BO Microsoft Oracle (SE) Oracle (EE)

Speed Fair (recently improved by configuration upgrades

Good Good Good

Connectivity to source databases

Good Good Good Good

Support Bad Medium, depends largely on consultancy

“Weaker than the market”

“Weaker than the market”

Integrated Planning Module

Yes, but no connectivity between BO Enterprise and BO Planner

Performance Point Server

None Hyperion Planning

Excel Integration Via Plugin Directly Integrated into Office 2007

Via PlugIn or Excel Web Query

Via PlugIn, different for Hyperion and Oracle

Relational Reporting

Crystal Reports Reporting Services

Discoverer, Oracle Reports

Ease of use Relational Reporting

Very Good Good Medium

Web Access7 XI SharePoint,

Reporting Services

Oracle Portal, Discoverer Viewer

Oracle Interactive Dashboards, Hyperion Web Analysis

Publishing of Reports

From within Crystal Reports or BO Web Access

From within Excel or Visual Studio

From within Discoverer or Oracle Reports

From within a variety of Reporting Tools

Own OLAP Database

Universes (Is this really OLAP?)

Yes Yes Two, Oracle and Hyperion

Future development

Roadmap unclear since SAP acquisition.

Strong focus on extension of functionality. Unlikely that it will be sold to another company. Major changes to User Interface not expected.

Will most likely be replaced by Enterprise Edition components over time.

Will most likely focus on integration of the different parts.

7 All suites provide web based portal and reporting capabilities, however, compatibility with browsers is

only partially documented by vendors. For example, Microsoft guarantees full browser compatibility for Internet Explorer only as they make use of ActiveX Controls, a technology present in Internet Explorer, but does not comment on Firefox. Firefox is able to run ActiveX with an extension, but this isn’t recommended as it can have unpredictable results on browser behaviour and is a potential security risk. As UCL’s Design Authority presently support multiple browsers, UCL may either

• Limit the browser support for BI related deployments (consistent with “standardising BI tools”). • Continue to support multiple browsers for BI related developments, either by constraining

functionality offered to the lowest common denominator to allow all browsers to function, or by developing workarounds (either approach will tend to undermine the benefit of any investment)

• Use Thin clients, for example, sharing Internet Explorer via Citrix. (Design Authority notes thin client environments). This also improves security, as the instance of Internet Explorer can run behind the firewall and is only displayed on the client system - no reporting host has to be exposed to the internet. However, the technical deployment becomes more complex.

These options apply equally to all vendors, as each must deal with the current browser standards. Consequently, it does not substantively affect ABeam’s analysis at this time.




Criteria BO Microsoft Oracle (SE) Oracle (EE)

Integration Moderately integrated, but unclear future. Will most likely be integrated with SAP

High, even the acquired solutions are very well integrated into one solution

Most parts accessible via Data Warehouse Builder.

Not very integrated at this time. Integration will most likely cause strong structural changes.

Overall User Experience

Moderate Good Good Oracle Good, Hyperion Moderate

Inhouse Developers

Some None Many Some

Inhouse Development Experience

Moderate Poor Good Moderate

7.2.3. Toolset Recommendations

Subject to formal requirements specification and RFI processes, ABeam recommends:

• Business Objects be ruled out, as it is expensive, and any advantage bought in universes may

confer are offset by poor usability – custom universes are effectively warehouses, and need to be

built. Further, it is unclear how Business Objects will continue to tie their products to SAP ERP

System, and their current roadmaps do not give adequate clarity to provide assurance for a 5

year horizon

• Oracle looks favourable, and brings many advantages, building on existing skills sets. These skill

sets are, though, centred on the data engines and standard reporting. Training will be required to

fully exploit the BI offerings. But Oracle has not fully formulated a clear strategy for the future.

And as it is relatively expensive, it should only be considered if significant discounts are available.

• Microsoft’s suite is the preferred platform, as it is inexpensive and has currency with the end user

base. Properly implemented, it can still deliver the BI infrastructure required. Skill sets will need to

be developed, but, given the multitude of systems already in play, a training programme on

agreed skills will be required irrespective of technology. And UCL doesn’t have to pay for

Microsoft Client Access Licenses.

The Microsoft Business Intelligence Environment is an easy to use but very flexible toolset that meets all

requirements needed for UCL’s future BI Landscape.




7.2.4. Recommended Toolset - Microsoft BI Suite

Finally, ABeam looked more closely at Microsoft BI Suite.

Frontend

Microsoft provides two easy to use frontends: Microsoft Excel and Internet Explorer. As ease of use was

a big requirement for UCL, this carries weight, and is a major advantage over Oracle. Oracle has multiple

front ends, arising from its recent acquisitions spree. Whilst Oracle will need to change these to

consolidate its offerings, Microsoft has just recently brought in the ribbon in for Office 2007, and it is

expected that Office 14 will be an incremental step up from this. Further, Sharepoint portals can provide

interfaces that many are already familiar with

Integrated Solution

Microsoft BI Suite is integrated solution, from frontend to back. All components work smoothly together

and are based on one technology stack. The best example is Performance Point Server. For contrast,

Oracle uses Hyperion with its own data store for budgeting and Hyperion Web Analysis, Interactive

Reporting, Financial Reporting and SQR Production Reporting to access it. There is a second technology

stack, Oracle BI Server which also has its own data store that uses Oracle Answers, Interactive

Dashboards, Delivers, Disconnected Analysis, Publisher and Briefing Book as frontends. You can’t

access Hyperion with the Oracle Frontends and you can’t access Oracle BI Server with the Hyperion

Frontends. Whereas Microsoft Performance Point Server (the budgeting and Dashboarding solution) has

the same data store as the rest of the Microsoft BI solution, SQL Server and Analysis Services. While

providing the user with extended features to create interactive dashboards it is also possible to report on

the PPS cubes with the normal Excel Frontend or a web browser via Reporting Services. Even the whole

budgeting process is done from within Excel 2007, so nobody has to learn a new tool. If UCL also uses

Sharepoint 2007 as proposed, everything is accessible from one website. You can even mix reports

made in Excel, Reporting Services and Performance Point Server on one single page. The data is always

“actual” as it is pulled directly from the data store.




Report Graphics

19

Extraction, Transformation and Loading

ETL in the Microsoft BI Suite is done by the SQL Server Integration Services. This consists of two

components, a server that allows automatic execution of the extraction processes and a graphical editor

to model the data extraction.

It is possible to connect to almost any number of different source systems and types. Another big

advantage is the graphical modelling process which always provides a structured view on all extraction

and transformation processes instead of forcing users to look through code and data listings.

Development

Development is mostly done within one tool, Visual Studio. In Visual Studio you can model cubes, create

the extraction and transformation routines and even create relational reports in it that can be accessed by

the user with a simple web browser.

Like most Microsoft tools, the modelling tools of Microsoft BI are intuitive and easy to learn, so UCL will

be able to do a lot of the development on their own and using consultancies for specialist support and

guidance roles, rather than to carry out all development.

Architectural Approach

Microsoft BI aligns well to the data mart approach recommended. Prototypes can be built within weeks of

initiating projects.




Training

The familiarity of the Microsoft environment means that developers could be trained on the job by

prototyping first and then transferring the prototypes into a robust solution. This iterative approach also

allows users to collaborate on interfaces and required data sets

7.2.5. Pricing

Pricing is notoriously difficult without a full RFI and tendering process. Despite the availability of standard

price lists, discounts, volumes and incentives can impact prices significantly, as can the use of Campus

licenses. UCL, for example, presently enjoys large discounts on Oracle products, and Microsoft discounts

hugely for educational licences

That being said, ABeam proposes a budgetary cost of £1600 per user. This figure factors in several cost

components that need to be taken in account when building the BI business case, and which contribute to

the Total cost of Ownership. It should be used ahead of any specific data that may be obtained through a

tendering process. This figure includes licenses, implementation, support and consulting for a year;

subsequent annual maintenance costs should be around 20%

UCL should also consider the time invested in initiatives such as promoting the Design Authority and

BICC, and other business prerequisites

ABeam has based this budgetary figure on industry pricing and typical costs from commercial clients:

• Oracle BI Standard Edition can incur typical costs of €2000/user

• Oracle Business Intelligence Standard Edition One is cheaper, at around €1,000 per user for

deployments of 5 to 50 users (though this is just the license cost).

• Microsoft BI solutions for academically institutions are typically much less than these figures

• Business Objects Crystal Decisions Professional Edition starts from $35,000 in North America for

five concurrent users on a single Windows or Linux server. Pricing in the rest of the world varies

according to local market conditions. Midmarket products sell from tens of thousands of US$,

enterprise solutions can cost $100,000 to $150,000 for licensing alone.




Report Graphics

16

Assuming a user base of:

MS / Design Authority / BICC 10 experts Divisional IOs 20 Power Users FMAs 10 Power Users Divisions and Faculties 100 Users

Then UCL should budget for an initial investment of £221,200, with subsequent annual maintenance of

£44,240.

This figure should be seen as an upper limit, as it remains sensitive to discounting and incentives from

vendors. It may also be offset by trading up current licences, or cancelling current licence (subject to final

technology choice). It may be affected significantly by discounts available to educational institutions.

Microsoft Pricing

Microsoft BI comes at an unrivalled low price for academic institutions. ABeam believes that UCL has in

place a campus Client Access Licences for core MS Office products, so would need to add or upgrade

licences for server products only (If this is not be the case and UCL license the servers on a per

processor instead of a per user basis Microsoft has the big advantage that a processor license is really

used per processor and not per processor core like Oracle licenses).


Appendices

Reporting Requirements and Capabilites 1.0.doc ABeam Consulting / 107 Appendices

8. Appendices

8.1. UCL Contributors

ABeam is grateful to the following UCL personnel for their time and input to this report.

Name Division Title Stakeholder Group

Akinmutande, Niyi HR BU IT Information Offices

Brant, Sarah HR BU Director Division Management

Churm, Rob Registry BU IT Information Offices

Clark, Robert ISD Executive Division Management

Cooper, Andrew Academic Services BU IT Information Offices

Darmon, Maria ISD IS Operations MS Service Providers

Farrell, Simon ISD, nUCLei Senior IT MS Service Providers

Furter, Richard EFD BU Director Division Management

Gallyer, Marilyn Vice-Provost Executive UCL Management

Gay, Stephanie ISD MS, Registry MS Service Providers

Goldstein, Harry ISD nUCLei; Process MS Service Providers

Goudy, Clare Faculty Assistant to Michael Worton Faculties

Goward, Neena ISD MS, Development MS Service Providers

Grant, Kevin Faculty FMA Faculties

Grant, Malcolm UCL Provost UCL Management

Griffiths, Mike Finance End Users

Hackney, Jon Finance Information Offices Hallas, Chris Registry BU Director; Academic

Registrar Division Management

Haward, Mike ISD MS, Finance MS Service Providers

Hibbs, Caroline Finance End Users

Hogg, Valerie Finance Senior End User End Users

Kayastha, Rachna HR HRIO Information Offices

Kirby, Andy ISD MS, HR & Payroll MS Service Providers

Lewis, Kathryn ISD nUCLei MS Service Providers

Lloyd, Margaret Faculty FMA Faculties

McCarroll, Peter Internal Audit BU Director Audit and Assurance

McDonald, Anne Registry User End Users

Merrington, Suzanne ISD Licensing Details MS Service Providers

Miller, Will ISD Senior IT Division Management

Mistry, Arun Faculty FMA Faculties

Morgan, Conrad ISD MS, Technical Projects MS Service Providers

Moule, Jennie DACCO BU IT Information Offices

North, Quentin ISD Senior IT MS Service Providers

Paul, Martin EFD BU IT Information Offices

Perry, Tim Academic Services BU Director Division Management

Plumb, Julie ISD PSO MS Service Providers

Randle, Chris ISD Executive Division Management

Rickaby, Anthony ISD Senior IT MS Service Providers

Rothera, Hilary UCL Business FMA Other Businesses

Rowlinson, Kathryn Registry User End Users

Speller, Jeremy ISD Senior IT MS Service Providers


Appendices


Thompson, Jonathan Finance Project Manager for Finance's Reporting Project

MS Service Providers

Tittle, Richard Finance Director of Finance Systems Information Offices

Walker, John Finance Information Offices

Wasserman, Arthur DACCO BU Director Division Management

Watts, Sue DACCO BU IT Information Offices

Welch, Martin Registry User End Users

Wells, Lois Finance Senior End User End Users

Williams, Angela ISD MS, Estates MS Service Providers

Wills, Robert Registry BU IT Information Offices

Woodhams, Alison Finance BU Director Division Management Worton, Michael Faculty Vice Provost, Academic &

International Faculties


Appendices


8.2. UCL Collateral

ABeam is grateful to UCL for making the following information available

ID Name Modified Modified By

1 080828 Project Plan.xls 03/09/08 Nic Crotch

2 080829 UCL Workshops - NC Version.doc 03/09/08 Nic Crotch

3 10-12.ASSC-Reporting-Tools-Feb-2008-v4.doc 28/08/08 Nic Crotch

4 architecture1yronXMLv0-3.vsd 04/09/08 Nic Crotch

5 BI Questionnaire UCL MS Managers - NC Response.doc 17/09/08 Nic Crotch

6 BI Questionnaire UCL MS Managers-JAR.doc 17/09/08 Nic Crotch

7 BO Licences-May-2007.xls 04/09/08 Nic Crotch

8 Business Objects XI - HR and Portico - Stage 1 V4.mpp 04/09/08 Nic Crotch

9 BusinessObjectUsersInfo.xls 17/09/08 Nic Crotch

10 Current products covered by UCL campus licence.doc 04/09/08 Nic Crotch

11 Draft Enterprise Technology Standards.doc 21/10/08 Nic Crotch

12 Finance Reporting Project.htm 09/09/08 Nic Crotch

13 HEFCE Guide to AudC on data_assurance.doc 15/09/08 Nic Crotch

14 ImprovingInformationToSupportDecisionMaking.pdf 15/09/08 Nic Crotch

15 IRIS_UserRequirement_Analysis.doc 22/09/08 Nic Crotch

16 ISC_ASSC_3_02_07-08_Data access policy draft v9.doc 17/09/08 Nic Crotch

17 KPIs agreed at March 2006 Council Meeting.doc 04/09/08 Nic Crotch

18 licences.xls 03/10/08 Nic Crotch

19 PBOU HR Portico XI Migration Exception 1.doc 12/09/08 Nic Crotch

20 PBOU HR Portico XI Migration PID V4.doc 08/09/08 Nic Crotch

21 PBOU HR Portico XI Migration PID V5 Approved.doc 04/09/08 Nic Crotch

22 ProposalForReportingToolsJan05-V3.doc 17/09/08 Nic Crotch

23 ProposalForReportingToolsMar04-V6.doc 17/09/08 Nic Crotch

24 RE Enterprise Information Reporting Strategy.txt 15/09/08 Nic Crotch

25 Report Template 0.11.doc 04/09/08 Nic Crotch

26 UCL - Business Objects Enterprise XI Pre-upgrade Review.pdf 02/10/08 Nic Crotch

27 UCL Corporate Plan.pdf 05/10/08 Nic Crotch

28 UCL current systems context 1.1.vsd 04/09/08 Nic Crotch


Appendices


8.3. Supporting Documents & References

8.3.1. Case Study – University of Colorado*

Mary Catherine Gaisbauer, Associate Vice President and University Controller at the University of

Colorado, describes her school as a large, decentralized, complex organization—not unlike a commercial

enterprise with many small subsidiaries. She says it’s often difficult to keep abreast of the financial

performance of every college and every department. “When you are a $2 billion institution and you have

one department that falls into a $300,000 deficit, you might not notice that right away.”

In the past, Gaisbauer couldn’t be sure if officers within the school’s many departments and colleges were

even seeing core financial data. That’s because reports were delivered in hard copy to a single person in

each department with the hope that they would then be photocopied and delivered to key decision-

makers. But an internal audit couldn’t adequately determine if the information was even reaching those

people.

*Source: managing the Business of Education

8.3.2. Case Study – University of Texas*

The University of Texas at Austin knew it had to act more like a business when it realized that its

traditional sources of money, particularly state dollars, were drying up.

“The key to our future success was having better information so we could make the right decisions,” says

Fred Friedrich, Associate Vice President and Controller of Financial Affairs at the University of Texas.

The vast majority of the school’s data resides in homegrown transactional systems, which made it difficult

for faculty and employees to access it. Also, information was not integrated in any cohesive way, making

it difficult for anyone to create a clear picture and find answers and make sense of the data.

More often than not, it took people several weeks of sifting through spreadsheets and reports to find what

they wanted—whether it was the dean of liberal arts trying to figure out how many teaching assistants he

needed, or the financial dean of the law school figuring out how much free balance she had available in

multiple investment accounts.

*Source: managing the Business of Education


Appendices


8.3.3. Market analysis papers

• CIO – BI Worst Practices

• CIO – How to Buy BI Software

• DataMonitor – BI Vendor Selection

• Gartner - Magic Quadrant for BI Vendors

• Gartner – Negotiating with BI Vendors

• Information Builders – How BI should Work

8.3.4. CIO Presentations

Webinar Presentations:

• CIO.com - Pervasive BI

• CIO.com - Why BI Fails

8.3.5. The Knowledge Hierarchy

(Skyrme & Amidon, after Ackoff)

Wisdom

Knowledge with Insight

Knowledge Information with Meaning

Information Data with Context

Data Facts, Observations, Data Points


Appendices


8.4. Vendors and Technologies

8.4.1. Oracle

The Oracle BI-Suite exists in three editions.

Oracle Business Intelligence Enterprise Edition Plus (ex Siebel and Hyperion)

• Oracle BI Server: Common enterprise business model and abstraction layer. The foundation of the

suite that is highly scalable and optimized for concurrency and parallelism. It provides centralised

data access and calculation in one single source.

• Oracle BI Answers: Ad-hoc query reporting in a web environment. Users are able to create charts,

pivot tables, reports and even dashboards. These are fully interactive and drillable.

• Oracle BI Interactive Dashboards: Highly interactive dashboards for accessing business

intelligence and applications content, they provide a sophisticated environment for creating

interactive dashboards. It can aggregate content from multiple sources, including OLAP and

relational Databases, the internet, shared file servers as well as document repositories.

• Oracle BI Delivers: Proactive business activity monitoring and alerting. It includes self-service alert

creation and subscription portal as well as alert workflow creation across multiple applications.

• Oracle BI Disconnected Analytics: Full analytical functionality for mobile professionals, enabling

fully interactive dashboards and ad hoc analysis while disconnected from the corporate network.

• Oracle BI Publisher (formerly known as XML Publisher): Enterprise reporting and distribution of

"pixel-perfect" reports, a report distribution environment that allows the creation of Microsoft Word

or Adobe Acrobat Reports that can be delivered vial printer, eMail, fax, WebDav or portals.

• Oracle BI Briefing Books: Dashboard pages can be saved into a local "Briefing Book" viewable by

anyone with an Oracle BI Briefing Book reader for offline viewing

• Hyperion Interactive Reporting: Intuitive and highly interactive ad-hoc reporting. An intuitive and

interactive interface lets users design dashboards and quickly monitor and navigate relevant

information.

• Hyperion SQR Production Reporting: High volume, presentation-quality formatted report

generation

• Hyperion Financial Reporting: Formatted, book-quality financial and management reporting.

Reports that comply with regulations and external requirements. Financial Reporting features

embedded financial intelligence that supports currency translations, GAAP, IFRS, and other

financial standards. In addition, the module supports XBRL for electronic transmission and filing of

financial information.

• Hyperion Web Analysis: Out-of-the-box online analytical processing (OLAP) analysis,

presentation, and reporting, providing executives, business users, and analysts with intuitive user-

directed Web-based query and analysis capabilities accessed through context-driven, thin-client

user interface.

Oracle Business Intelligence Standard Edition (ex Oracle BI)

• Oracle BI Discoverer: An intuitive ad-hoc query, reporting, analysis, and Web-publishing tool that

enables users to gain access to information from relational and OLAP databases as well as Oracle

E-Business Suite.

• Oracle BI Spreadsheet Add-in: The Spreadsheet AddIn allows users to do adhoc reporting on

OLAP databases from within Microsoft Excel Spreadsheets.

• Oracle BI Beans: BI Beans enable Java programmers to build custom business intelligence

solutions.


Appendices


• Oracle Reports Services: Oracle Reports is an enterprise reporting tool. It consists of Oracle

Reports Developer (a component of the Oracle Developer Suite) and Oracle Application Server

Reports Services (a component of the Oracle Application Server).

Oracle Business Intelligence Standard Edition One

A special, limited license version of Oracle Business Intelligence Enterprise Edition stripped of

Hyperion Products

• Oracle BI Server

• Oracle BI Server Administrator

• Oracle BI Answers

• Oracle BI Interactive Dashboards

• Oracle BI Publisher

• Oracle Database Standard Edition One

• Oracle Warehouse Builder (core ETL)

Gartner provide the following assessment of Oracle:

Strengths (source: Gartner)

• Even prior to its acquisition of Hyperion in mid-2007, Oracle's BI vision was becoming more

compelling — its combination of BI platform and analytic applications (Oracle BI Enterprise

Edition [OBIEE] and Oracle Analytic Applications) is one of the better sets of offerings available.

With its portfolio of BI products and technology, Oracle has the potential to deliver operational

and strategic BI capabilities, either stand-alone or embedded into horizontal or vertical

applications.

• Customer feedback on OBIEE is positive overall, based on its proven usage in larger enterprise

wide deployments. Users highlight its workflow and collaboration capabilities, and sophisticated

visualization in particular, as better than the market as a whole.

• The strength of the Essbase OLAP engine and Hyperion's Microsoft Office integration capability

help improve Oracle's BI reach, while OBIEE's semantic layer, when integrated with it, will close a

major gap in Hyperion's BI platform.

• Oracle's open stance, what it calls "hot pluggable integration," means that its BI portfolio may be

attractive to non-Oracle shops, with BI the business face of its Fusion Middleware product line.

Cautions (source: Gartner)

• The integration of Oracle's multiple BI products and product line capabilities will be an ongoing

process for much of 2008, and after

• There is strong evidence that Hyperion's BI installed base is taking a wait-and-see approach and

not updating to latest versions — in fact, of all customer groups surveyed by Gartner, Hyperion BI

users had the lowest proportion running the latest major release. Oracle must be careful to

ensure it does not lose former Brio customers in particular, some of whom are unhappy with

Hyperion's plan to charge them an "enablement fee" to move to System9.

• Oracle needs to provide better BI product support. The Oracle customers surveyed as part of a

Gartner research reported weaker support than the market in general, including inadequate front-

line technical expertise.

Oracle Business Intelligence Enterprise Edition for Discoverer users (source: Mark Rittman)

UCL has some Discover deployments. Here we summarize what’s good, and what’s not so good,

about Oracle Discoverer.


Appendices


Major plus-points of the Discoverer tool:

• Easy to use, lots of wizards, familiar look-and-feel, high awareness and exposure within the

Oracle user community – many people have exposure to Discoverer through its apps integration,

bundling with Oracle Application Server and so on – the “comfort” factor if you like.

• Leveraging of Oracle’s built in calculation, analytic and PL/SQL functions – Discoverer uses the

Oracle database as the calculation engine, you get access to all the built-in SQL and PL/SQL

features including all the analytic (lag, lead, window, top N etc) functions.

• Integration with Oracle database security and E-Business Suite responsibilities, and pre-built E-

Business Suite reports and BI metadata layer.

• Integration with Oracle Warehouse Builder (although this requires the Enterprise ETL Option for

Warehouse Builder, at less then £8k a CPU on the ETL database), and integration with Oracle

Portal

• Oracle OLAP access through Discoverer for OLAP

• Lots of functionality around totals, percentages and other report add-ons

Disadvantages of Discoverer could be summarised as follow:

• Oracle database-centric; although Discoverer can connect to non-Oracle databases, this is a

fairly complicated DBA task and still requires everything to be routed through the Oracle

Database, and the End User Layer’s Oracle database dependency still means you need an

Oracle database somewhere, even if all your data is in MS SQL Server, for example

• Although Discoverer integrates with Oracle Portal, it is not an optimal solution as it’s tricky to get

all the report refreshes working properly, the reports in Portal don’t show a real-time view of the

data underneath, you can’t drill and analyse in-place, and Portal itself is a bit overkill for just a BI

portal

• It’s very hard, if not impossible, to get Discoverer reports to run lightening-fast; typically

Discoverer reports take 10, 20 seconds or more to return data, Discoverer itself adds a significant

time overhead to queries, it’s just not a fast, snappy environment to report in.

• The report authoring part of Discoverer requires a Java applet to be installed and then run in the

client PCs Web browser, which can cause security and installation issues for users not running

with admin rights, and requires a higher-spec (memory, CPU) PC to run on.

• Discoverer for OLAP, whilst very similar to regular relational Discoverer in terms of functionality,

look and feel, is however still different, has more limited capabilities (no parameters, can’t total by

attribute and so on) and has a separate report catalogue and security setup to Discoverer

relational.

• There’s (currently) no capability to create alerts (although reports can be distributed by email), or

add in-context messages to reports giving advice on how to interpret the report.

• Discoverer reports can be called via the Oracle OASIS API, but adding workflow to Discoverer

reports is not easily achieved (so that a user clicking on a report area or a link displayed along it

can trigger, say, a BPEL or Oracle Workflow process to act on insights provided by the report).

• There is also (currently) no way of displaying Discoverer-generated data in, say, a letter, or

printed labels, or in a report that contains more than one dataset.

“Currently” is mentioned in some of these issues because a few of them are being addressed by

planned integration of Discoverer with OBI EE.

In short, Discoverer’s advantages could be described as its familiarity, leveraging of Oracle database

features, support for totalling, percentages and analytic functions and integration with Warehouse

Builder and Portal, whilst the drawbacks are this very Oracle database integration, lack of alerting and


Appendices


report distribution features, lack of APIs and interconnectivity with the application development world,

limited output options, and performance, which shouldn’t be overlooked as it’s the number one

complaint at quite some Discoverer sites.

Cost

OBIEE on a per-CPU basis is more than ten times the cost of Discoverer, although on a named user

basis the cost difference is less marked and the upcoming OBI Standard Edition one is more

comparable cost-wise, but with limits on the number of server CPUs and end-users.


Appendices


8.4.2. Business Objects

Business Object has recently been acquired by SAP, and their roadmap is evolving.

In November 2008, SAP published the following view, which begins to show the integration of BO

products into the SAP landscape for SAP customers

For Business Objects Customers, the roadmap is less clear, although Business Objects are currently

offering some solution suite bundles. These include:

• Packages from SAP and Business Objects

• Enterprise Performance Management Solutions

• Information Management Solutions

• Business Intelligence Solutions for the Mid-Market

• Business Intelligence Standardization

• On-Demand Business Intelligence

It is unclear where Business Object Planner sits within these solutions

The BusinessObjects Edge Series is a simple, affordable, and proven suite of business intelligence

products for the Mid Market (small and mid-size companies). The suite is intended to provide the same

insight into business data and performance as enterprise organizations typically expect, but seeks to

provide this capability at a much lower cost. It offers:


Appendices


• Ad Hoc Reporting, Query, and Analysis for Business Professionals via the web

• "Live" Data Access within Microsoft Office for Business Analysts - access and use "live"

company data directly in familiar tools like Microsoft Office and SharePoint.

• Interactive Dashboard Viewing for Executives and Managers. Crystal Xcelsius, lets users interact

with visual sliders and gauges to easily identify new opportunities and challenges. Plus, "what if"

analysis.

• Mobile BI for end users on the go. Deliver content over any wireless device. Users can drill and

interact on reports and metrics and take immediate action

• Secure, Easy-to-Understand Data for Rapid Decisions. Presents data in standardized business

terms that are easy to understand and trust

• Rapid Deployment Options for Faster Time-to-Value. A variety of QuickStart Packs for access to

a tailored collection of templates and data connections that help you quickly apply BI to your

existing line of business applications

• Deliver Data Anywhere – Anytime. Move data volumes in real time or at any interval

• Impact Analysis. Metadata integration allows you to see the effect of changes in the source

systems to the BI reports.

• Data Lineage. See when data was updated, how it was computed, and where it came from all the

way back to the original transactional source.

• Data Quality. Centralize the discovery, correction, and prevention of data issues across the

organization, and intelligently verify data.

The series is available via QuickStart BI Packs - tailored collections of templates and data connectors

based on customer requirements and best practices, intended to allow organisations to get up and

running quickly with relevant business intelligence. They include

• prebuilt reports and dashboards for use with your industry- and department-specific applications.

• structured solutions built on best practices and customer requirements.

• optional rapid deployment services

• experience from Business Objects BI partners.

Additionally, the QuickStart Pack for Oracle E-Business Suite Applications enables companies to

immediately access their operational data stored in Oracle E-Business Suite applications, allowing

automated creation of BusinessObjects universes for Oracle EBS application.

Business Objects’ Enterprise Performance Management solution offers comprehensive functionality for:

• Strategy management - Set your goals, map your strategies, and then monitor and manage

performance from high-level objectives down to operational metrics.

• Business Planning and Consolidation - Increase accuracy in planning at every level in your

organization, while reducing budget cycles and associated costs. Accelerate and improve your

statutory and management reporting and decision making.

• Financial consolidation - Complete your financial consolidation and reporting cycles faster â€“

with complete confidence in your data.

• Profitability and cost management - Identify the causes of underperformance, and take action to

reduce costs and optimize profitability across dimensions such as product, customer, and

channel.

• Spend Analytics - Realize measurable cost savings, and align sourcing goals with corporate

goals by rationalizing and strategizing on supplier relationships.


Appendices


Gartner provide the following assessment of Business Objects:

Strengths

• As the largest of former publicly traded pure-play BI firms, Business Objects offers a broad and

complete BI platform with customers rating its core reporting and ad hoc query capabilities

particularly highly.

• Business Objects has widespread adoption as a BI standard — around 90% of the customers

Gartner contacted as part of an research considered Business Objects a BI standard in their

organisation.

• The rapid growth of its OnDemand BI offerings, for which it now has more than 70,000

customers, makes Business Objects the de facto leader in SaaS BI. This offering is bringing new

customers to the company and is also being deployed by existing Business Objects customer

alongside on-premises implementations.

Cautions

• Business Objects' vision and execution will change as it shifts from being a pure-play vendor to

being a SAP acquisition. These changes may have consequences for its product lines.

• Although Business Objects has been successful at upgrading its customers onto its XI versions,

this has proved painful in the main, with customers rating their migration experience as

challenging and costly. Several customers with large deployments have been vocal in stating the

difficulties they have had with their XI Release configurations, implementations and support.

• Business Objects have issues with migration, and customers complain heavily about support, and

customers rated its support as the least effective of any vendor, according to Garner’s Magic

Quadrant for BI Vendors Platform.

• According to the customers surveyed as part of the Gartner research, OLAP is viewed as the

functional capability where Business Objects is still least able to match its customers' needs.


Appendices


8.4.3. Microsoft BI

The Microsoft BI Solution comprises three layers.

1. The uppermost layer is the Microsoft Sharepoint Portal, integrating all reports in one easy to use web interface.

2. Next come the end user tools and report development layer. Reports are developed using

Microsoft Excel, Reporting Services Designer or the Dashboard and Scorecard Designer of

Microsoft Performance Point Server. All these Reports, even these developed by end users in

Microsoft Excel can be instantly published to the Sharepoint Portal, where they are rendered in

real time with live data every time the users accesses it with his web browser.

3. The foundation layer consists of multiple products that interact with each other in different ways.

• SQL Server Relational Database is the foundation of most tools used in the MS BI

Suite. It can store data warehouses, data marts, planning models from Microsoft

Performance Point Server and even holds all data contained in the Sharepoint Websites.

• SQL Server Integration Services are used to extract data from source systems or to

transfer data from one database to another including the load of planning data into

Performance Point Server.


Appendices


• SQL Server Analysis Services contain the multidimensional data models (cubes). They

allow fast and easy to use adhoc reporting without the need to know all the data models

the reporting relies on.

• The planning and consolidation part of Performance Point Server allows a workflow based planning or consolidation process that heavily relies on Analysis Services and SQL Server. Microsoft Excel Sheets are used to enter and manipulate data into models. These are nearly instantly transferred into Analysis Services Cubes so that the user gets a near real time feedback on the consequences of his changes. Planning models can of course also automatically filled with data via the Integration Services (e.g. for the actual data).

These layers of the Microsoft BI solution are provided through three products

• SQL Server

o SQL Server (Relational Database) - The Relational Database itself.

o Analysis Services (OLAP Database) - The OLAP Database including Business

Intelligence Development Studio, an integrated development environment to model data

cubes and mapping.

o Integration Services (ETL) - Integrated in Visual Studio this part is the ETL Tool of the

BI-Suite. It allows graphical design of extraction and transformation procedures.

o Reporting Services (static reporting and web access) - The reporting module of

Microsoft SQL Server. It allows the creation of more or less static reports based on

relational and multidimensional data sources as well as interactive dashboards. These

can be published on a web server afterwards.

o SQL Server Agent (job scheduling) - This part is used to schedule a variety of

automatic jobs, from extraction routines to database backups.

• Performance Point Server

o Planning and Budgeting - The planning component of Microsoft Performance Point

Server allows the creation of data models used for manual data entry as for example

planning solutions. The advantage of this product is that it is built strictly upon Microsoft

Analysis Services and SQL Server Relational Databases. It can therefore be

automatically loaded with data like any other database as well. The reporting can be also

be done like it would be a normal Analysis Services Cube. It also allows complete

workflow scenarios for the manual reporting process like delivery dashboards or

automatic reminders.

o Dashboarding - Performance Point Server also allows the creation of Scorecards and

advanced dashboards with an enhanced functionality over Reporting Services.

o Analysis - It also contains Pro Clarity, an advanced and very comfortable analysis tool.

• SharePoint Portal Server

Integrates reporting into a portal with a single point of access and Single SignOn.

o Dashboards from Performance Point Server

o Reports and Dashboards from Reporting Services

o Rendering of Excel Sheets with Live Data (Excel Services)

o Other Reporting Solutions with Web Parts for SharePoint (e.g. Business Objects)


Appendices


Gartner provide the following assessment of Microsoft:

Strengths

• The pricing and integration strategy of Microsoft with its Office, including its major Enterprise

Performance Management-led innovation of 2007, PerfomancePoint Server and SQL Server

products are especially attractive to organizations that have standardised on the Microsoft

information infrastructure. This bundling and pricing strategy with its BI products makes it an

economically attractive offering that will be considered by many organizations.

• Microsoft's BI products make a direct and strong link to the large community of Microsoft

application developers. Microsoft's BI platform provides developers with infrastructure,

development tools, workflow and collaboration capabilities that are easy accessible and held in

higher regard than those of most competitors.

• Microsoft is benefiting from developing its indirect sales and services channel and market

awareness of its SQL Server, Office and SharePoint Portal installed base. As a result, Microsoft

estimates that it now has around 2,000 OEM/ISV partners for its BI products. Many departmental

and business unit end users who hear the Office and SharePoint integration marketing messages

for BI will likely ask for the products and associated support from their IT departments.

• According to the customers contacted as part of Gartner’s research, Microsoft offers the best BI

software quality of all the mega-vendors, with over half of them reporting no problems with

software. This reflects Microsoft's focus on BI, the strength of its product line management team

and the fact that much of its BI technology has been internally developed rather than acquired.

Cautions

• Microsoft has joined the BI platforms market quite late and is still catching up. According to

customers, it lags behind pure-play vendors in terms of metadata management, reporting, and

dashboard and ad hoc query capabilities. However, Microsoft is in it for the long haul and Gartner

expects that it will continue to grow its BI investments in order to become a stronger competitor.

• Organizations that have heterogeneous applications, information infrastructure and development

environments will find Microsoft's BI-related marketing and announcements to be interesting but

potentially distracting, since they may not easily integrate with their existing investments in

infrastructure and applications.

• Despite its price advantage, Microsoft will face increasing competitive pressure as BI becomes a

market where strategic sourcing, of more than just BI capabilities, takes precedence over

features and functions, and as the other mega-vendors' acquisitions integrate into their product

stacks.


Appendices


8.4.4. Cognos

Gartner provide the following assessment of Cognos:

Strengths

• Cognos has an exceptionally high proportion of enterprise-standard BI platform deployments —

more than 90% of the customers Gartner contacted as part of the research consider Cognos a BI

standard in their organization.

• Cognos is now benefiting from the broad re-architecture of its BI platform, which began four years

ago with ReportNet. With the 8.2 and forthcoming 8.3 release, Cognos 8 BI is outgrowing its early

problems with support and stability. Of the companies Gartner contacted for the Magic Quadrant

report, the vast majority were running the last version of Cognos' BI platform, and reported that

their migration experience was labour intensive but straightforward.

• The completed, Cognos' acquisition by IBM will increase its access to the WebSphere and Data

Stage installed base. Moreover, it should significantly bolster Cognos' data integration and

unstructured/text analysis capabilities, which have lagged behind its main competitors.

• With the assimilation of the Applix TM1 OLAP engine, Cognos has an opportunity to take back

control of aspects of its performance which it previously ceded to database vendors by de-

emphasizing PowerPlay Enterprise Server.

Cautions

• While the integration of PowerPlay with Cognos 8.3 will help, virtually all the Cognos 8

deployments are reporting-centric. Analysis Studio has not been widely adopted. To advance

along the Vision axis, Cognos must increase the number of customers using the Cognos 8

platform for OLAP-style analysis, particularly across large relational databases, but also

competitive multidimensional OLAP (MOLAP) offerings such as Analysis Services, Essbase and

Infocubes.

• Cognos' predictive analytic and data mining capabilities are much weaker then the other BI

platform Leaders.

• There is a gap in functionality between Cognos 8 BI's Report and Query studios. Customers

could benefit from more layout and flexible reporting functionality from the Cognos ad hoc query

tool, such as the ability to create multiple blocks of information for multiple dimensions, like sales

by time and geography.

• Cognos 8 lacks robust caching; resulting in users hitting the database each time the report is

refreshed. Based on feedback from some end users, Cognos needs to look at ways to enhance

query performance.

• Cognos currently has a clear set of use cases for TM1 and PowerCubes, but has yet to clearly

state how these two distinct technologies will combine as part of its integrated BI platform.


Appendices


8.4.5. SAS

Gartner provide the following assessment of SAS::

Strengths

• SAS dominates in advanced analytic solutions. No other vendor in the Magic Quadrant has its

range of capabilities or can point to the same number of advanced analytic deployments.

• SAS has a strong packaged analytic application program, with solutions that go well beyond

reporting and key performance indicator (KPI)-centric deployments, to include more advanced

analytic applications applied to particular business problems such as fraud detection.

• SAS has a strong brand and associated support structure that spans all major geographies.

• Its Stored Services provide an effective way to embed advanced analytical functionality within

reports, dashboards and other easy-to-consume applications.

• SAS's integration of JMP with the platform provides an in-memory analytics offering with strong

visualization capabilities that could be positioned for a broader class of business analysts than

the traditional SAS user, though it would need to simplify JMP's interface.

Cautions

• SAS has a reputation for being very hard to use. In particular, many of the data manipulation and

advanced analysis tasks require the SAS programming language; this is an advantage to people

with those skills, but a significant barrier to those organizations without them.

• Despite hundreds of deployments of BI Server and Enterprise BI Server, SAS is less well known

for traditional reporting and dashboard-centric BI deployments, and has historically struggled to

make shortlists for BI selections, even inside stalwart SAS shops.

• SAS BI Server still lacks key features, including Web-authored pixel-perfect reporting, out-of-the-

box support for cascading prompts, and incremental cube updates. The 9.2 release, expected by

mid-2008, should close these gaps, with the exception of pixel-perfect reporting in the browser.

• SAS has a reputation for promoting a proprietary architecture. It publishes few application

programming interfaces (APIs) and, until recently, discouraged analytical or mixed workloads

stored outside SAS. The recent Teradata announcement is a step in the right direction.

• SAS's subscription-based pricing model could be a concern for buyers that require perpetual use

rights.


Appendices


8.4.6. MicroStrategy

Gartner provide the following assessment of MicroStrategy:

Strengths

• Rather than adopt an acquisitive strategy, MicroStrategy has built its BI platform organically, from

the ground up. This is evident in its tight platform integration, very scalable relational OLAP

architecture and complete object-oriented metadata model.

• MicroStrategy performed very well in the customer reference survey conducted for this analysis,

showing consistently strong ratings across Gartner's 12 BI platform capabilities. It is noteworthy

that MicroStrategy is strong across all three capability categories: integration, information delivery

and analysis. Taking all 12 capabilities into account, its customers rated it highest overall in terms

of functional match to their needs and in terms of their implementation experience.

• The company's BI Factory messaging, which promotes its ability to build large numbers of BI

applications from a central location with fewer resources, due to its strong enterprise metadata

model and governance capabilities, has become a very appealing marketing message;

particularly at the high end of the market.

• Customer feedback from Gartner’s reference survey indicates positive scores regarding ease of

migration and reliability of the software, especially compared to other leading BI platform vendors.

Cautions

• MicroStrategy may be vulnerable to the increasing parity within the BI platform market,

particularly the flattening effect of in-memory analysis, as it enables better performance against

large data sets — one of the areas that lies at the core of the company's differentiation.

• MicroStrategy has a reputation that its software is expensive and the vendor can be difficult to

negotiate with. However, Gartner noticed a steep reduction in complaints about MicroStrategy's

licensing and pricing practices in 2007. Historically, MicroStrategy has refused to alter contractual

terms and conditions, has charged "a la carte" for functionality such as Office integration, has

conducted usage audits, and has re-priced maintenance from previously signed contracts. This

somewhat negative customer experience is the primary factor that kept MicroStrategy out of the

Leaders quadrant until now.

• MicroStrategy focuses exclusively on the BI platform market and pays little attention to related

markets such as EPM and data integration. By doing this, it removes itself automatically from the

shortlist of those organizations that want an integrated approach to these disciplines, particularly

planning and reporting. This issue will become more prevalent given the stack-centric direction

that the market has taken following the megavendor acquisitions in the BI space.

• MicroStrategy has a direct but small sales and service presence in the Asia/Pacific region. Its

relatively small Asia/Pacific footprint has been raised by global companies concerned about

MicroStrategy's ability to support deployments worldwide.

• MicroStrategy's position on the completeness of vision axis moved to the left since last year's

Magic Quadrant. This is because of the limitations in its sales channel, geographic presence and

vertically-specific analytic applications compared to other leading BI platforms. Nevertheless, its

technology vision is sound, particularly for interactive visualization (delivered in 2007) and in-

memory analytics (expected in 2H08).