ODM stands for Operational Data Management. At NR this breaks down into a number of key areas:

• Data management for various safety and hazard registers (see specifics for more details.
• A level of image management (this is a future requirement)

Like Image management, ODM is done very much on an ad-hoc basis, often with the various registers held in a substantial number of MS Access databases floating around the company.

Some of the current issues around ODM are:

1. Substantial distributed copies of data held in a number of different formats (ie. MS Access)
2. Localisation of data storage vs. distribution to other Areas (see org chart below for info)
3. Validity / currency of data held (i.e. PB crash had out of date diagrams)
4. Data Ownership
5. Inconsistent metadata between similar applications

TBC

The ODM solution needs to be able to provide the following:

• Version management and control of all registers and data.
• Internal access by desktop, laptop and mobile device
• External access in the future (?access methods, security?)

and will need to take account of:

• Current CMS (aka CCMS) - Documentum.
• Current ODM tool - APEXs (formerly Oracle HTML DB)
  • In use for at least one of the primary registers.
• Current levels of mobile deployment (limited to Supervisory level trackside at the mo)
• Multiple delivery methods (i.e. network, MMS / SMS)

and must be:

• Easier and more efficient for the current workforce to use than the current tools in use.

TBC but may include:

• Imaging Roadmap
• Infrastructure platform definition
• Personnel skills matrix and training requirements

This section will grow as more details are available.