Your Data has a Life

Your Data has a Life - Revive It

Michael Norris
Director, Asset Information Management,SCL

Inspiration Through Privitisation
Knowledge of the company physical assets is of critical importance for the commercial and safe operation of a business. This subject has come to the forefront in the UK in a big way in recent years, following the "selling off" of public monopolies to the private sector. British Rail (BR) was "broken up" into a number of different railway companies in an effort to breathe new life, investment and competition into what was seen as deteriorating circumstances for the railways.

Almost overnight, and as if by magic, there appeared Train Operating Companies (TOCs) who transported passengers, Freight Operating Companies (FOCs) who transported freight, and the one and only company responsible for the maintenance and management of the railway infrastructure - track, signals and major stations - Railtrack.

At the time of the privitisation the UK Railways were already separated into 10 Zones (now 7). Each Zone operated with great autonomy. It possessed its own maintenance crews who were responsible for the upkeep of the track and signals within the geography managed by the Zone. The maintenance crews were to form the other "new" key players of the railways - the Infrastructure Maintenance Contractors (IMCs).

The focus of this paper is specifically about what happened next - in terms of assets and asset data. The paper relates the data quality strategy deployed in trying to acquire and maintain good quality data. In particular it relates to how a project was kicked-off to provide a comprehensive register of the infrastructure assets and the key findings of the project.

The Project
The Project was approved in April 1999 and provided a budget to do the following: -

Build a single, national physical asset and hazards register and deploy nationally
Migrate asset data out of local systems into the asset data repository
Conduct a data collection exercise to "gap-fill and verify" 10% of the asset records - to an agreed level of quality by November 1999
Develop and implement processes and procedures to address the maintenance of asset data
Develop and implement processes and procedures to support a quality management system for asset data.
Develop implementation plans for the collection (including "gap-filling and checking") of the other 90% of asset data records - to be completed by November 2000

Background - so what's the problem?
Before we look at the asset data quality as part of the Railtrack Project experience let's consider some of the problems encountered in the handling of data by way of a simple example - data held in the Address Book.

The Data in an Address Book
A typical address book can be a "minefield" of information. There is a very good chance that the data recorded will be useful since the person who is going to use it put it there. They know when they recorded it, the process by which it was acquired, the source of the data and, generally, the reliance they can put on that data. Hence,

If the user of the data is the owner and maintainer of the data the data is likely to match the requirements of the user.
The responsibility for the capture and maintenance of the data, and the process and procedures by which this is carried out, should be the responsibility of the owner / user of the data.

What Data to Record?
Perhaps two partners wish to share information about their circle of friends for the purpose of putting a single, definitive, common list of names and addresses together. Under those circumstances it would have been useful, before they had started to collect data, to have agreed what kind of data should be recorded and how it should be recorded (a rare event). Let's start with the basics - such as a person's "Name". What exactly do we need to record about "Name" - perhaps, the "Surname "and "Firstname" and a "Middle Initial"? How do we want to record it? Should it be "Surname" followed by "Firstname" or vice-versa? What other detail is normally recorded about someone? We might recommend an "Address"- data item including "Street Number" and "Street Name", and possibly "Town", "County" or "State", "Postcode" or "Zipcode", or "Country"? Telephone details might be useful such as "Home Tel No", "Fax No", "Mobile No"? "Business/Office Nos", or "Pager No"? And, today we might also want to record details such as someone's "Email Address". Some of this information may be considered "basic" and some "extra detail".

What is "basic information" and what is the "extra detail" - the latter may be defined as "nice to have" but rarely used if at all. If we are not going to use it why keep it?

Data for its own sake is an expensive commodity if maintained and if it is not maintained it becomes "unsafe" to use.

Data Storage (Where to hold our prize data?)
But where do we store all of this information? We can use handheld electronic devices (Personal Digital Assistants or PDAs) - Paper based Organisers or Diaries, PCs (with more software applications to choose from), wall calendars or web-based storage areas. And even as individuals we will use different places to record different but related data. This creates tremendous difficulties when we attempt to pull together an up-to-date list of names and addresses.

Data about the same "assets" but held in different places is usually not-sychronised. It is difficult and slow to integrate, often inconsistent in format and plainly unreliable - and, unfortunately, it tends to stays that way.

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.

Different Standards and Processes
The standards laid down with the owning company were widely interpreted within the company - meaning that there were in fact at least 7 different standards. Processes and procedures aimed at applying the standards were equally "loosely" interpreted across the Zonal organisations. That is not to say that any one interpretation was right or wrong - more that it became very difficult to compare and contrast the asset count, condition and performance on a national level.

The situation was far worse when our sights were raised to look across the railway companies.

Different definitions were being applied to ostensibly the same asset types. There was no agreed way of uniquely identifying an asset thereby and therefore there could be no certainty that information was being exchanged about the same asset. Comparing and evaluating source records across companies for the purpose of assessing the quality was the proverbial stuff of nightmares.

Rather than try to find a way of bringing many different and dispirit systems of questionable quality together in one place it seemed more logical and sensible to start with a "clean slate". However, we would not ignore the knowledge gained from the past efforts to implement an asset information system -We realised that to stand half a chance of being successful we needed to know, as a minimum: -

The overriding business goals and objectives for the asset data? (translated into "know why you want the data and what you will do with it when you get it")
The minimum "data-capture" requirements for the new asset register? (to achieve the desired goals and objectives)
The acceptable quality hurdles and performance indicators for the captured data?
The actual indicators to be used to measure the data quality?

Principles behind the Data Quality Strategy
A number of principles were adopted which underlie the developed data quality strategy and included: -

Current Processes and Procedures - reference had to be made to existing company or industry standards and methods.
Quality Control and Assurance
1. Must be exercised as near as possible to the point of obtaining the data.
2. Can help eliminate poor quality data - it can not produce high quality data.
3. Must check data received but must also check that all collected data is received.
Data Sources
1. Original data sources are better than secondary or derived data sources.
2. Track (site) is the primary source of quality data where that data can only be acquired from site.
3. The best data sources are those which are recognised and controlled.
Data Checking

It was not economic to check all items of data (e.g. attributes).
The overall quality could be determined by random checks against accurate, controlled sources only.
There would always be some poor quality data in the system.
The quality of the data would be impacted by the quality of the data sources from which it was derived and maintained.

Quality Standard

There was a need to introduce a documented and data quality standard (based on a known standard) which was discernable, practical and future proof.
Quality of data was to be expressed in quantified terms.
Minimum quality level was to be defined numerically as the acceptable quality level (AQL).
Introduction of a Target Quality Level - data quality for all data to a set AQL would be achieved over time. Targets to be set which would lay down the volume of data to have reached an AQL by a set time.

Quality indicators were to be the vehicle for assessing the data quality level. These were: -

Correctness:		indicated whether the value of the data item was correct when compared to a recognised and controlled source of data.
Presence:		indicated whether the data item held a value or had been left unfilled. Currency: indicated whether change to the infrastructure had been reflected in the register in a timely manner
Traceability:		indicated whether the source of the data can be identified in terms of the batch of which it was a part.
Completeness:		indicated the extent to which whole assets (records) were missing.
Consistency:		indicated the variability and uniformity in presentation of like data.
Context:		indicated the extent to which data items that relate to each other, in the same or different records, do so correctly.

Processes to Verify Data
- Data of the required quality levels to be achieved by implementing processes, within the Zones and Contractors to do three things: -
- As far as possible, the processes for verifying data were to be built onto existing processes to:
  1. reduce disruption
  2. minimise the cost
  3. reduce training and documentation requirements
- Traceability and Auditability In order to make corrective actions, and improvements of data or process, effective, it had to be possible to identify the source of data. For reasons of efficiency and practicality it had to be possible to group data with a common source. To achieve this:
  1. all data to be "batched" prior to its use to populate the register
  2. the origin of all data (new or changed) to be traceable at record level through a batch ID
  3. any person entering data to the register to be identifiable through a system record

The Quality Life Cycle of the Data
The data acquired by the project and entered into the new asset register went through a number of planned steps to enable it to achieve the desired data quality. These were: -

Step 1 - Data Cleansing and Migration (unknown quality)
Original data ("legacy") located in a number of different systems (electronic and paper records) was identified, cleansed as far as possible within a fixed time-window and migrated into a new asset register. The users were provided with two interim repositories for storing the "cleansed" data prior to it being uploaded into the asset register. The quality level was considered to be unknown and unmeasured.

Step 2 - Data Collection - "Gap-filling and Checking" (to desired AQL)
10 % of the asset data in the register was identified for "gap-fill and verification". An overall high level "data collection" strategy was devised and issued to the Zones and they each worked within this to check their asset records and supply any missing data. However, they had sufficient autonomy to deploy different "local" methods to acquire and check the assets data. Each Zone was commissioned to devise a plan to bring 10% of asset records in an agreed quality level - budgets were allocated against the approved plans. Some concentrated on a track-walk exercise and others conducted a desktop checking exercise to complete their records and assess their quality (using the quality indicators "presence" and "correctness". Some used specialist teams to "collect" the data, some collected using Zone only personnel and others employed a contractor (IMC). Collected data was uploaded in batches into the register and identified and traced by batch number. Batches were first checked visually for record consistency, completeness, integrity and traceability. Batch details were held outside of the repository and standard forms were issued to capture and supply such details.

Step 3 - Quality Level Measured - Independent Data Quality Checks
Extracts of data from the register were turned into "track-walk lists" and independent data quality engineers sampled the data "on-site" against the "track-walk lists" for "presence" and "correctness". "Missing Assets" were counted as errors and the error count was conducted at attribute (data item) level. The data quality engineers were able to rate the batch samples quantitatively against the set AQLs.

Data Quality Reports and Corrective Actions were produced. The Zones then reviewed these. [At the time of writing the Zones are preparing their response to the reports.]

Step 4 - Process and Procedure Audits
Independent Process Auditors were deployed into each Zone to check on the implementation of the documented business procedures (including the data quality procedures). The auditors were tasked to observe the procedures operating "end-to-end". I.e. observe batches of data representing changed assets being moved through the business and data quality check procedures, into the asset register and out again by way of reports and notifications.

Implementation / Key Findings / Recommendations
The project feasibility work commenced in the autumn of 1998. By April 1999 enough groundwork was completed to prove that what had to be done could be done. During that time the business requirements were firmed up and the necessary asset data definitions were agreed. Also, a dialogue commenced between Headquarters and the Zones and between the Zones and their suppliers. The organisation and key personnel necessary to deliver the quality data was agreed in anticipation of funding being granted. This enabled the project team to "hit the ground running". The project team had just 8 months to put the system in place, migrate the data and "gap-fill and verify" 10% of all the assets. The programme plan was worked and re-worked to improve the chances of success but even so things did not always go to plan.

At the commencement of the project 85 asset types were defined for collection - at a fairly high level. The average maximum number of attributes per asset type was about 20 but we only expected about 12 attributes per asset type in the collection phase. (A number of attributes related to the history of change to the asset - inspections and condition information for example- and would not be available except through the normal maintenance activity). In between funding being awarded and collection commencing it was agreed to store environmental and hazard type information in the same data repository and retire the current systems. There was a serious risk that making late changes to the scope of collection would cause significant delay (scope creep has a tendency to do this) - just changing the data collection forms to handle the new information would have forced a delay.

The new data items would demand different quality checks as they were not strictly physical assets. Also, after collection started, a number of additional "supplementary" attributes were added to the data dictionary. However, it was agreed, that in order to minimise the risks of project delay or compromising the quality of the data the new data requirements would be handled separately. "Environmental and Hazard" data would be migrated from the legacy systems by the business - technical support only would be provided by the project team. The project would not take any responsibility for the quality of the data content but would ensure that what was in the legacy systems was transferred intact to the new asset register.

The new supplementary attributes were not considered mandatory for data collection but if they existed and could be migrated to the new system they would be - however, they were classified as "AQL = 0" and the project / business would not be judged on the quality of this additional data. This helped to keep the collectors focus on the original data requirements. Despite this more migration effort was required than originally envisaged adding and additional month longer to the programme.

Resources that should have been focussed on data collection in July were still tied up in completing migration activity. Slippage in the end date for migration acted as an "open invitation" to the business users to find more data to migrate - unheard of sources of data came to light. The project had a difficult decision to make - migrate the data and delay collection or cut-off the migration activity, alienate the business users and pick up any "newly found" data as part of the ongoing maintenance activity. In the end a compromise was necessary.

Migration support continued for an four additional weeks but collection commenced as planned and additional resources were deployed by the core project team. Data not migrated at the end of "migration" was moved into the register as part of data collection and / or maintenance activities.

What follows is a distillation of the key issues encountered and the lessons learned, by key project activity, in carrying out this significant project..

Asset Data to Capture?

Enlist the help and support of key personnel from within the business who had the background and experience to speak on behalf of the business and who could agree a set of asset types and definitions to meet the needs of the majority. Perfection was impossible but if the enlisted business representatives could get close enough to the truth the outstanding problems could be addressed at a later date. Asset information systems had taken quite a drubbing within the company in the preceding years because they were either not delivered or were very poor when they were delivered. It was better to get on and deliver something that met the some of the needs of the majority than to procrastinate and attempt to deliver the impossible. This was a view that was widely accepted at the very start. It was also accepted that the starting point for "asset types" to collect would be the legacy asset repositories.

De-scope and keep the data requirements as simple and as straightforward possible. It is better to limit what data is really required in the first instance and improve the chances of attaining a good quality for the data that is "acquired".

Agree a well-defined and structured data dictionary, data definitions and data collection forms before commencing with data migration or collection. Changing the data dictionary during these activities is very disruptive, confusing and costly. Unfortunately, the Data Dictionary and Definitions did change during our data collection phase but we limited the damage by setting the AQL for this data to 0% and helped to keep the data collection teams focussed on the original data requirements. The new data requirements will be re-classified at a later date and "checked and corrected" under data maintenance activity. It was not possible to agree in detail all asset definitions before asset data collection commenced but it was possible to furnish additional supplementary information as questions arose from the collectors. Supportive addenda to the data dictionary were only issued if it was deemed useful to the collectors and helped establish greater uniformity in the collection process. Otherwise the data auditors would pick up inconsistencies and offer advice and guidance.

Establish a policy for the so called "Surplus data" - the data that does not migrate across from the legacy systems to the new data repository because it does not fit with the current data requirements and data dictionary. Remember that "Surplus data" cannot be left on the shelf too long before it deteriorates beyond any business value. Maintenance of surplus data outside of the central data repository is expensive, "risky" and generally unhelpful to the vast majority of data users. If it can be established that the "Surplus data" supports a business process and is therefore important to the business it can captured in the asset register and the necessary changes made to the register under change control. It is important to establish with the business that maintaining the "Surplus data" with the same rigour as all of the other data in the repository has a price and it is better not collect if it cannot be maintained.

Know your sources before you migrate and allow enough time to evaluate and prioritise the sources. It is often less costly to dump an unreliable data source and recollect than it is to "cleanse" the poor source. This will prevent the "last minute" discoveries of additional and important data "which must be carried over into the register". It is extremely helpful if the suppliers of the data can inform the project team early on with the names and types of the data sources to be used, the volumes and types of data they contain, the currency of that data and an indication of the completeness of the data records. This will enable the project to gauge the importance of the data sources, size of the migration effort and prioritise the movement of the data from the data sources.

Migrated data - tends to be of poorer quality than you hoped or wished for. It will need a lot of "gap-filling and checking". Spread the loading of the migrated data. Try to avoid moving large volumes of data at the same time. The Migrated data - should be properly "cleansed" before it is transferred into the new asset register. Poor data lowers the user confidence in the data and can remain uncleansed for a very long time. It is good practice to allow a data expert to view the migrated data to spot obvious flaws (duplicate records, assets recorded in the wrong order, orphaned records, etc.).

Collecting Data

The best results in terms of data quality is generated using dedicated, trained and competent discipline experts. Even the best amateurs will miss data or misapply data codes. Try to keep the same teams together throughout the data collection exercise - this includes any safety personnel - it aids morale and keeps productivity high.

Training and formal mobilisation of the data collection teams in a consistent manner before collection starts for real is absolutely essential to get consistent results first time. Test the collection processes and forms (electronic or paper) before too much data is collected allowing early correction. Keep forms simple and as much data on one-side of paper as is practicable to allow.

Electronic means of storing and checking the asset data in the field was adopted successfully by one of the seven Zones at the commencement of the project. All Zones were offered the electronic hand held data recorders but six decided to use the paper-based forms solution. By the end of the project 6 out of 7 of the Zones were much more interested in the hand held data recorders and suggested that they might move towards adopting them for future data collection and maintenance activities. Paper based "track walk lists" and collection forms in all weathers were used successfully but proved to be very difficult and forced additional data checks due to the recording of the same data twice - to be avoided if at all possible. With the advent of better hardware and software and the integration of GPS devices the interest in the electronic recording devices has grown significantly.

Always use the "best" sources of data - the best source is either "site based" data or controlled records - avoid data that has been derived a number of times. It is not significantly cheaper to collect data from existing paper or electronic records than it is to go back to first principles and collect the data from site.

Collect data in trackable batches - big batches of data cause problems when the batch has to be "rejected" - the good data is thrown back with the poor data. Remember to employ a system that will help record details of the batch and afford proper tracking of the data batch through its life - this information is useful to the supplier and receiver alike. Primary asset groups would appear to the only sensible batches to use for collection as the checking of batches is normally done by the discipline experts (the discipline engineers) working within a primary group. I.e. a signaler will check signals asset data and only wants to be presented with signal data.

Data Quality

Decide very early on what will be the key performance measures and acceptable levels of quality - make them as objective measures as possible - i.e. quantitative. There will need to be a mixture of quality indicators but don't have too many and don't be persuaded to only measure data volumes. You may need to phase them in! Communicate the quality processes as often and as loud as possible and encourage feedback. Users will try to ignore the inevitable as long as they can.

Conduct an initial check on the quality of data with some of the legacy data before commencing data migration and collection. This establishes a baseline against which the performance improvement can be judged. This was not considered too important when our project started when the data quality strategy involved producing absolute measures of quality but it grew in importance later on when the business wanted to measure the "cost of quality improvement".

Results were very mixed depending on the data collection method deployed. In the best case (99%) a dedicated data collection team walked the track and compared what was found on site with what was held on record. They also conducted a very rigorous data cleansing exercise on the legacy data. The worst example - relying almost exclusively on legacy data of uncertain history - returned data quality which was initially too poor to put through the full checking regime. Data had not been properly cleansed and good data had not made it across into the live register. However, the data quality checks conducted by the engineers did successfully highlight where the problems existed and the necessary corrective actions were carried out to raise the data quality level up to around 80%. It is not sufficient to request quality data under contract from a supplier. A vigorous data audit procedure must be deployed early on to enforce the data quality regime and ensure the right message about data quality is getting across. Data Maintenance on its own will not vastly improve the quality of poor legacy data (in anything like the timescales desired by most companies).

Involve anyone and everyone (by representation) in the development of any new processes and procedures. Keep the procedures as high level as possible and as flexible as possible to enable them to be adopted but insist on detailed and supportive work instructions developed by those who have to deploy the procedures. Be prepared to assist the business users in the development of the work instructions by offering advice and guidance from the center. Note and propagate the best ideas across all.

The bedding down of procedures takes months not weeks. This is particularly true of the data quality check procedures. The Zones are still coming to grips with the full implications of the procedures in terms of the required resources and the amount of time taken to produce a quantitative measurement. Do not be tempted to heap change upon change but do consult widely in the period following implementation and the next release of the procedures.

Gain the highest possible business acceptance for the new processes and procedures and utilise that support at road shows and awareness events. You will be initiating a major programme of business change and you therefore need to consult widely to win the "hearts & minds" while realising that there will be opposing forces questioning the costs and validity of the work.

In Conclusion
Did the project meet all of its declared objectives? Well, almost. We did manage to successfully delivered a populated asset register with a mapping interface. We removed a very diverse set of poorly managed data repositories and replaced them with a single system viewable by all and providing a common set of asset records. We piloted the use of electronic means of collecting and checking asset data using hand held data recorders. (cost, availability and the degree of integration with the asset register remain the outstanding issues here)

We successfully migrated the data in the legacy systems that matched the asset dictionary definitions - we actually shifted some 15% more data than was originally projected by the business and spent less than planned.

We developed an IT based means of sharing the asset data with parties outside the company (somewhat outside the original remit) and we managed to collect and verify between 7 to 8% of all assets - a little less than the targetted 10%. However, we have to remember that this was essentially a Business lead initiative and not an IT project. The business ambition was the development and implementation of business processes to enable the acquisition and maintenance of good quality data. The project had to show that this could be done and that the "mind set" of the business could be altered to ensure that it was self-perpetuating.

To this end we did provide the necessary business and quality processes to ensure that the asset data quality was attained and maintained. We trialled the data quality checking processes and procedures using our own central resources to produce quantitative results. We also devised and gained agreement - company wide - on the definition of asset types to be used within the business and with the other companies within the railway group. However, as the project comes to its natural end and the business system and processes move into the operational environment there are a number of outstanding issues still to be tackled. They are: -

Over 90% of the asset data still needed to be verified ("gap filled" and checked)
The business processes and procedures need to take firm root (used in anger) with the business users.
Desired system improvements - not possible to roll out because of a "Y2K Systems Freeze"- need to be developed and implemented (particularly in the area of "reporting" and "auditing" on asset data)

Thus, a quite separate three-month activity has been set in motion. A very small, close-knit and experienced team is now assembled to help the establishment of the asset register system and ensure the accrual of business benefits Their primary goal will be adoption of and commitment to the published business processes and procedures and data quality. They will act in a "consultative and guidance" role only - never to take away the ownership or the responsibility for the system and the data within from the business itself. A formal post implementation review of the project will be conducted around the summer of 2000 to determine if the desired business benefits are being accrued.