Knowledge is of two kinds. We know a subject ourselves, or we know where we can find
James Boswell
information upon it”.
Effective use of the latest advances in integrated information systems can have a dramatic
effect on productivity, quality, and cost. It is no longer acceptable to cobble together an
ad hoc data management plan as the project progresses, or leave it to the contractor.
For major projects, the preparation of an Information Plan for defining Information
Management and Technology (IMandT) strategy and provisions should be made.
In a multi-project environment, such as an OU business unit, IMandT provision will be
described in an Information Plan prepared either for the individual unit or the company
as a whole.
The project IMandT plan should be prepared as part of the Project Execution Plan, with
the level of detail being continually built-up appropriate to the stage of project
development and complexity of project.
Key strategic aspects to be considered at the outset of the project should include:
• definition of the asset owner’s requirements for the delivery of information during
asset operations. This should include itemized definition of what categories of
information are required, when, and their desired (electronic) form/format;
• definition of how and by whom data is to be managed throughout the project.
This requires data ownership at the various phases of the project to be defined,
and information transfer processes and standards to be specified and agreed.
The full life cycle of the data management up to decommissioning of the asset must
be considered;
• IMandT capability should be a factor in the selection of contractors and activity resources;
• requirements on all of the above should be embodied within contracts with third parties.
The Project IMandT Plan
The project IMandT (Information Management and Technology) plan should cover the data
and document management responsibilities and processes. The use of information systems
and information technology should support data and document management for this project.
Data Types
Operating Asset Data
This is the production data that the Asset Operations Team requires from the operating
asset in electronic data assembly and data transmission form(e.g. flow rates, storage
volumes, etc.). This data requirement should be generated at a high level for inclusion in
the Basis for Design and at a more detailed level in the Project Specification. The
information requirements will affect the design of the computerised control systems and
the asset telecommunication system. Not only definition of the required information but
also the way in which the data is to be presented and the data to be retained at the asset
location and that to be transmitted to the asset management office all need to be
specified and agreed between Operations and Engineering and built into the control
system and telecommunications contracts
2
.
Project Technical data
This is the data for the facility (asset) and/or equipment that needs to be created,
modified or abandoned.
It includes, but is not limited to, basis for design, specifications, approved for
construction, as-built and plant process data. Technical data is usually captured and
stored in electronic databases such as contractor engineering and/or CAD databases and
maintenance and production support databases.
Project Activity (CTR) data
This is the data on the cost, the time and the resources required to execute the project
activities. It includes, but is not limited to, the CTR catalogue and network, project
commitment plan and schedule, work breakdown structure, budgets.
Activity data is usually captured and stored in Project Management systems (such as
Electronic Work Management System(EWMS) and finance systems (general ledger).
Project Business Process data
This includes guidelines (such as the OPMG), methods and company procedures for
managing and executing a project. Estimating guidelines and rules are also part of the
business process data, but the actual project and CTR estimates are part of the project
activity data.
Business Process data is usually contained in manuals and documents. The exception is
estimating data, which is normally stored in the tables of cost estimating systems.
Data Management and Project Information Plan
Data Management aspects and Project Information Plan requirements for technical, activity
and business process data are detailed on the next pages. The Project Information Plan
need not be a separate document, but could be an integral part of the Project Execution
Plan (PEP). If separate, the plan should be referred to and summarised in the PEP.
All information plan requirements should be considered in ORP Phase 2-Select and
finalised in Phase 3-Define. If a Project Information Plan requirement is not relevant to a
specific project, or will only become relevant at a later stage of the project, it should not
be left out completely, but included with the reference: ‘Not relevant’ or ‘To be defined
before project stage xxx starts’.
Project data model
Figure 4.7.1 represents a project life cycle view of a typical project and asset information
model. Arrows indicate information flow (electronic or hard copy). Boxes indicate functions
or teams. With the exception of the (sponsor) project team and the asset manager function,
all other functions could be contracted out to service contractors, requiring data transfers
with – and between – third-parties with differing IT infrastructures. Depending on local
OU procedures and guidelines, the complexity of the project and project organisation and of
the asset management organisation, the data (flow) model for a specific project may deviate
from the model in the Figure 4.7.1, and could be less or more complex. The actual data
model for a specific project should form the basis for the Project Information Plan.
Data Management
Operating Asset Data
The Project Information Plan should cover:
• a definition of Operating Asset Data
• who will specify the data requirements and its electronic formats
• the data to be retained locally and that to be transferred electronically to a
remote location.
• the dates by which the information is needed.
Project Technical Data
Project Technical Data is, by definition, an integral part of the facility (asset). Over the
life cycle of a facility, data will need to be exchanged between designers, constructors,
operators and maintainers several times. Standardisation is therefore a prime requirement
for technical data, to facilitate effective and efficient, preferably electronic, exchange of
data.
Typical technical data flows (Figure 4.7.1) :
• input to the design team: facility requirements, existing facility data, equipment
vendor data;
• transfer from the design team to procurement services: equipment specifications,
material requisitions 3;
• exchange of design data (drawings, specifications) between (contractor) design team
and (sponsor) project team, for checking and approval purposes;
• transfer from the design team to the construction team: approved for construction data;
• transfer from the design team to the plant operator: process data, operating parameters;
• transfer from the construction team to the plant maintenance/inspection function:
facility data and equipment vendor data;
• transfer from the construction team to the asset manager: all data relevant for future engineering work or required by law, regulatory bodies or classification societies, but
not directly relevant for operating and maintaining the facility.
Project Activity (CTR) Data
Project Activity Data is owned by the project team (the Finance and Procurement
function may have custodianship of some of the data, such as project budget data or
detailed procurement data). The prime purpose of activity data is to support management
and control of the project. On completion of the project, the detailed CTR data is
normally destroyed, although data collations will be recorded in the project debrief report
and may well find its way into the OUs cost and schedule databases. CTR data summaries
or extracts may (have to) be kept for an additional period of time for audit trail purposes
or can be used to upgrade Business Process data
(e.g. estimating tables). Typical activity data flows (Figure 4.7.1):
• project team to asset manager/management for plan approval and progress reporting
purposes;
• project team to Finance: value of work done and estimates, to update the general
ledger system;
• finance to project team: payments and bookings (time writing), to update
the Project Management system;
• project team to Procurement: ‘Required on Site’ dates;
• procurement services to project team: expected delivery date, materials ‘value of
work done’;
• design team to project team: vowd and progress data;
• construction team to project team: vowd and progress data.
For activity data, the project information plan should cover:
• procedures for reporting and updating activity data: what, how and how often
4
;
• a data flow map, including the specific data standards and (electronic) file formats
to be used for activity data and document transfer between parties involved
in the project. This should include the agreed
information carrier: network link, tape, cassette, paper, courier, public mail;
• the list of systems and databases that will be used capture and store activity data;
• special requirements for activity data required for reviews and audits by internal or
external teams or bodies during project execution, or after close-out of the project.
Project Business Process Data
This data is normally ‘owned’ by the OU engineering manager or head of the project
department and is usually maintained by dedicated staff responsible for developing and
maintaining Project Management guidelines, procedures, estimating tables and systems
Typical flow of business process data.
• The project team will have access to the relevant procedures, guidelines and
manuals (in paper or electronic form).
• ‘Lessons-learnt’ and other experience data will be fed back to the staff responsible
for maintaining and updating the business process information, either ad-hoc by
the project team, or through formal reviews and audits.
For business process data, the Project Information Plan should cover:
• the discreet list of (company) Project Management standards and procedures either
mandatory or relevant to the project (a standard, guideline or procedure not listed
is considered not to be applicable to the project);
• specific project quality and change control procedures in addition to – or deviating
from – the above listed procedures;
• special requirements for business process data required for reviews and audits by internal
or external teams or bodies during project execution, or after close-out of the project.
Data Management Systems
IMandT has been rapidly developing over the past few years, and has now reached the
stage where numerous integrated data systems are available to contractors and clients
alike. Figure 4.7.2 illustrates how EP professionals might be able to access both technical
and business data from
their work stations, assisted
by the asset and
organisation coding
structures of the EP Cost
Management System (EP/
COMS). Such an
illustration is no longer a
vision but is rapidly
becoming a reality.
However, progress is often
hampered by the lack of
common data exchange
standards, which are inhibiting the rate of system development and increasing the cost of data ownership to clients.
Much work has been done on the data exchange issues. POSC and STEP (see 4.7.1) are two
important standards, which must be applied where possible.
These data exchange standards
are important for projects and
operations where much of the
activities are carried out by
contractors, who for economic
and contractual reasons use
their own IT systems.
Developments in “intelligent”
object related databases which
form the basis of modern 2D
and 3D CAD systems also
require the ability to exchange
data between applications as
illustrated.
In planning the information
systems needed to support a
project, it can be seen from
the above that is important
that early consideration needs
to be given to the IT strategy.
Product development is
maintaining a very rapid pace
and advice from the Company’s
IT staff should be sought at an
early stage.
6
Livelink is one data
management system that is being
used by some Group Companies
for large, global Projects.
7
In determining the project requirements for systems, considerations should include:
• giving priority firstly to establishing the principles of good Project Management,
which are then underpinned by appraisal and selection of appropriate computer
systems to handle the large quantity of data and documents;
• giving preference to evaluating and adopting systems which integrate across the
organisations involved in the project, and operate on single source databases,
to common coding classifications;
• taking advantage of the advanced technologies available for inter-site
communication (e.g. voice, video, e-mail, data);
• definition of the interface with contractor’s and OU corporate systems, to permit
data to be imported/ exported. (e.g. SAP finance and procurement/logistics data,
or asset drawings and data to the OU’s long term repository).
There should be a preference for adopting tried and tested systems, unless the benefits
are considered to outweigh the risks. It is, however, likely that stepwise improvements in
information management can be made to the economic benefit of both the project and
its asset holder. New and interim solutions can be adopted for the transfer of a limited
range of data or document types without undue risk. The type of improvement which
can be undertaken will depend on the ‘starting point’, and what stage of IT development
has been reached in relevant business areas of the parent OU.
Work Management Systems
Over the past several years, data management advances have enabled much more
powerful work and resource management systems to be introduced. These commonly show
all project data and enable the engineer to see at a glance how work is progressing against
plan and to establish where the hot spots are in the resource management programme.
These systems integrate a number of previously independent data bases and provide an
underlying business transaction process that enables commitments to be made and
subsequently managed. In this respect, the systems show considerable advance on the
traditional planning systems of the past (e.g. Artemis). They also permit roll-up of
projects to a higher level of management in a multi-project environment. The essential
systems for effective work management (Schedule, Finance/Cost, Material/Services) are
integrated.
SAP/R3
SAP/R3 is a standard software package for the automation of internal company processes
and includes applications in the areas of financial administration, logistics, production,
maintenance and construction work. SAP’s strength lies in the interrelationship it
provides between the various processes. In practice, this means that when purchasing
materials or preparing an invoice the information comes from one and the same
database. This means that data is updated only in one field.
Figure 4.7.6 illustrates the way in which the work management, contracting and
procurement and finance processes influence each other and consequently benefit from
the advantages of integration of data management.
The Group has selected SAP for use as a worldwide standard and it will replace EWMS
(see below) in most, if not all, OUs as the multi-project work management system.
EWMS
The Group Common System, “Engineering Work Management System” (EWMS), was
developed specifically for the multi-project environment and has been in use in many
OUs. It provides a means of effectively managing a large number of small engineering
projects but, as its systems are generic, it can be used for projects of all types.
The key features of EWMS are:
• the engineer is the sole owner of the plan – only he/she can change it
• manager can view individual plans and roll-up plans and observe deviations
• all finance and materials data are available to the engineer within EWMS.