Introduction

This paper is aimed at those who would wish to implement a core set of processes within a single workflow based Information Management System (IMS) running over a relational database to support any future major project.

The aim of the paper is to provide a list of key areas for implementation within an IMS for any large projects. It covers all the core processes implemented within the Crossrail IMS and Table 1 outlines the key definitions used throughout the document:

Table1 – Key Definitions

BIM & Crossrail

A previous learning legacy paper describes the Crossrail BIM principles

The IMS was a key element supporting this strategy allowing multiple processes and organisations to operate in the same system space and for relationships and references to be developed across the data providing a common date environment.

Crossrail’s Information Management System

The Crossrail IMS provides a content and configuration management platform that enables users created within the IMS community to access information via the web. Users can perform various actions within the system such as create and review documents, issue documents via transmittal and assign works to other users. It is a tool that can be used to create and run minor reports and allows interface with other systems within the organisation. All of this was done in a secure controlled environment with relevant audit trails being logged.

The IMS was configured to support a number of core business processes across the Crossrail Project including:

• Asset Management
  • Asset Information Management System (AIMS)
• Assurance
  • Crossrail Assurance Reporting Environment (CARE)
• Central Governance
  • Crossrail Quality Management System (CMS)
  • Scope Book (SCOPE)
  • Change Management (CH)
• Compliance
  • Materials Compliance Records (MCR)
  • Snagging (PWK)
  • Project Technical Requests (PTR)
  • Mechanical, Electrical and Public Health Design Review (MEP)
  • Observation Reports (OBS)
  • Data Recording and Corrective Action System (DRACAS)
• Contract Management
  • NEC3 Contract Administration (NEC3)
  • Professional Services Contracts (PSC)
  • Rolling Stock & Depot Contracts (RSPA)
  • Central Communications (CEC)
• Document Management
  • Document Control (DC)
  • Operations and Maintenance Manuals (O&M)
  • CAD Drawings as Pdf from separate system (CAD)
• Structures including
  • Master Deliverable Lists (MDL)
  • Common Site Filing Structure (CSF)
  • Health & Safety Regulations (CDM)

The Crossrail IMS had a number of inbuilt data objects for use (‘base types’ existing as tables within the application database) which could then be expanded via additional custom attributes and attached to custom workflows to meet the needs of the above listed business processes.

Whilst other systems would have a different core set of data objects it should be possible to match the functionality with additional attributes and workflows.  The core ‘base types’ implemented in the Crossrail IMS included:

Implementation

The Crossrail IMS evolved over the life of the project as new processes were implemented and it is only at the end of the project that we have a complete list.  It would have been beneficial to start with the complete list of requirements as shown in the now fully compiled Crossrail IMS spreadsheet . The spreadsheet is broken down into separate tabs covering each of the following:

Classes

Within the IMS each base-type has a number of classes of object defined to meet the needs of the implemented business process.  Classes are then used to govern the screen layouts, security and associated workflows and effectively represent the categories which need to be created for each business process. These are assigned a class code and a class name (see  – Classes Tab)

Attributes

The core base types within the IMS have a number of pre-defined attributes:

• Code (Unique user friendly reference)
• Revision number
• Name (Short name)
• Description (Long description)
• Current revision flag
• Create date
• Effective or Start date
• End date (Events only

The Crossrail defined attributes were then used to capture the bulk of the meta-data against an object (see – Classes and Attributes Tab)

Responsibilities

As part of the object creation process and subsequent workflows each class object can have either an organisation or an individual assigned with defined responsibilities (see – Responsibilities Tab)

Relationships

At the heart of the Crossrail IMS is the ability to create relationships between objects with relationship types used to determine the nature of the relationship (see – Relationships Tab)

Workflows

Each base type can be assigned work flows which will step the object through a given set of tasks (each one allocated to a particular person grouping) with relevant attributes being completed/updated at each stage (see – Workflows Tab)

Reports

A number of key reports were listed on the home screen of the Crossrail IMS and these were split into the relevant process categories (see  – Reports Tab)

These were all the categories identified throughout the duration of the project which were implemented in the IMS.

Lessons Learned

From our experience creating and implementing this system a number of lessons were learned along the way:

Using Meta-data rather than Files

The initial usage of the Crossrail IMS was very document focused with files containing critical data and the IMS being used to manage the distribution and review. The drawback to this approach is that valuable information is lost within scanned images, attached files and spreadsheet lists where it is not straightforward to extract data for reporting or aggregation.

Later processes were implemented within the IMS as ‘Events’ where the focus was moved to the meta-data and files were not required.  This allowed for reporting and aggregation across contracts and processes.

Having a Clear Road-Map

The Crossrail IMS evolved over time as new processes were taken on and the capabilities of the platform/team were more fully understood.

Ideally there would have been a list of core processes and requirements at the outset which would have allowed for a more consistent implementation methodology.

Centralised Reports

The reports within the IMS evolved through 3 key stages:

• Data lists which were exported to Excel for subsequent manipulation
• Custom reports containing bespoke logic to interpret the business status
• Set of data providers holding the bespoke logic which in turn could be used by any report

The final stage was preferable as this re-enforced the idea of a single source of truth whereas 1 and 2 above were open to variation and interpretation depending on the individual report or spreadsheet.

Consistent Workflows and Metadata across Projects/Contracts

By enforcing common processes and metadata across contracts it was then possible to report on relative performance by users and organisations.  This helped identify areas of best practice and also where further improvement was required.

Transfer to Operating Environment

The Crossrail IMS was designed and implemented before the Rail Operator had designed, selected or implemented any systems.  This led to a number of identification, mapping and translation exercises as part of the process of populating the Operator Systems once designed.

Ideally the data captured during the Crossrail Project phase would have been transitioned into the Operating Systems to provide both the mandatory required documentation/data and also the context/background behind the end products.

Security

The Crossrail IMS was implemented from the outset with a high level of segregation which allowed contractors and Crossrail to store documents in draft which only became visible to the other party when released.  This was key to developing trust in the system.

Changing View of the Project

The Crossrail Project moved through a number of distinct phases which each required information to be gathered in a particular way.  This moved from Crossrail Central data, to Contracts which were reported on by area (East, West, Central), to deliverable type (Tunnel, Portal, Station, Shaft) and then to asset group being handed over.

Having a clear view of the end state for handover (asset group) at the outset and applying this to the initial documentation (e.g. design contracts which spanned multiple asset groups) would have saved significant effort re-analysing and re-categorising data during the handover process.

Conclusion

Over the 10 years of the Crossrail project the IMS was developed in line with the particular project stages from initial requirements and documentation through to construction and finally assurance and handover.

As each new process was implemented it made use of the lessons learned from previous processes (for example later processes were all meta-data based rather than files) and, where possible, used a consistent set of terminology.

If the majority of classes, reports and workflows had been known at the outset then it would have been possible to:

• Select a system at the outset which could meet all of the requirements (the final Crossrail IMS which met all the requirements was purchased after four previous successive systems)
• Adopt a common set of descriptions and layouts
• Adopt a consistent approach to reporting in terms of layout and reporting processes
• Identify where processes overlap or are related and ensuring that relationships are enforced in the system and common definitions are shared

Ensure that all the attributes for a particular process are captured at the outset rather than piecemeal as it evolves and then having to go back to re-work old transactions