Your Data has a Life - Revive It
The Project and the Need for Data Quality
A critical objective of our project was to have a database populated with asset data of a
known and agreed quality. It was recognised that the required level of quality could not be
attained immediately and that a progressive, phased approach would be required. We began
by devising a Data Quality Strategy - a framework to enable us to achieve our goals.
Data quality was seen as a historic weakness in many of the precursor database systems use
formerly for holding asset data. For the new asset register data quality was seen as a
distinguishing feature that would enable the register to address the needs of the end users
more reliably. Confidence in the asset data held within the system was considered vital to its
long-term use. An important aspect of the challenge of providing data of the requisite quality
was ensuring that the quality was measurable and that the quality level attained was visible to
the users.
Therefore, user confidence in the data was an essential prerequisite for successful
implementation and continued success of the asset register. The end user community needed
to embrace the system enthusiastically if the disciplines necessary for data maintenance were
to be adhered to. Users would only have confidence in the register if the quality of the data
was clearly demonstrated, to a required level.
he Need For Cultural Change
It was recognised that a major change was needed in the way both Railtrack and its suppliers
approach the maintenance of data in database systems. The history of many legacy databases
was that they degenerated into disuse through lack of adequate maintenance, leading to poor
data and the need to re-collect the data. If data of the required quality was to become the
norm, a significant change in attitude and approach to the handling and use of data was
required.
In developing the strategy for data quality, factors which are specific to the register and
which significantly affect the processes for achieving data quality included: -
- The diversity of bodies and organisations involved
- External responsibilities that were defined in existing contractual relationships (could not be ignored)
- The diversity of the subject matter (e.g. 101 asset types).
- The volume of the subject matter (i.e. in excess of 50 x 106 data items).
- The need to keep the register in alignment with other systems which may have lower quality standards, or no defined standards.
Problems to Overcome with Asset Data
In general, parties other than the company that owns the assets conduct the vast majority of
changes made to the infrastructure. The physical assets can undergo change as part of a
planned or unplanned process and the data about the assets will originate from a number of
different sources and be presented in many different ways.
Originally the asset data was held both by the owning company (Railtrack) and the
companies contracted to maintain (the Contractors). Although both sides were attempting to
have dialogue about the same assets there existed some fundamental and stubborn problems
that tended to prevent a clear and comprehensive view of the assets information.
Business View vs Engineering View of Assets
The owning company needed a business view of the assets. The contractors desired an
engineering view of the assets. An engineering view determined that a larger number of
attributes be held about each asset. This was largely unnecessary for the owning company
who demanded information that would assist with the management of contracts and
investment decisions. The business desired basic information about asset presence ("what it
is" and "where it is"), asset performance and the costs incurred to achieve that performance.
The engineering view demanded more detail about the widget such as how far into the
ground it went, the clearance between the widget and the tunnel wall or the last time it was
oiled. However, they were less concerned with the widget's performance as their own.
Because their needs were so different, the data required and the use it would be put to were
also quite different.
In the past attempts had been made to build a comprehensive asset database to try to address
the business needs of all - without tangible success. The task was just too great - the elephant
was too large to eat.
Different Systems and Data Structures
In addition to the problems of different desired business objectives and benefits there were
the practical considerations of different companies using different asset definitions / labels,
different databases (electronic and paper) and different data structures. Some companies were
more IT literate, knowledgeable and advanced than others and company size seemed to have
little bearing on the IT readiness of a company - even the largest of companies used some
form of paper record to hold asset data.
The problem is further exacerbated because even within the owning company asset data is
held on a number of different systems managed and administered by different disciplines and
the same disciplines did not hold the same information about the same asset types across all
Zones.
