experiences from implementation of a single dcs solution ... · project management, front end...

Copyright © 2004 World Batch Forum. All rights reserved.

Presented at the World Batch Forum

European Conference Mechelen, Belgium 11-13 October 2004

900 Fox Valley Drive, Suite 204 Longwood, FL 32779-2552

+1.407.774.5764 Fax: +1.407.774.6751 E-mail: [email protected]

www.wbf.org

Experiences from implementation of a single DCS solution supplied by multiple module skid vendors and utilizing the principles of S88 as a key element.

Flemming Larsen Principal Scientist

Methods & Systems NNE A/S

Gladsaxevej 372 2860 Søborg

Denmark (P) +45 44426583 (F) +45 44443777

[email protected]

KEY WORDS Project management, Front end definitions, process equipment skid vendors, process – automation planning, S 88, process modules, building modules, functional specifications, functional specification model, functional requirement analyses

ABSTRACT The world of the pharmaceutical and biotech industries is becoming more and more complex. Business- production processes must be transparent in order to react quickly and accurate when necessary.

Therefore engineering – and project execution methods for production facilities become more and more critical and demanding in order to achieve and realize safe pharmaceutical/biotechnology production.

This paper will resume experiences (by examples) from a highly automated process plant (from the perspective of DCS/ process control) with well - structured collaborative engineering executions, procurement, construction management and validation, and management methods to meet above mentioned challenges.

What seems simple or straight forward in theory (I.e. Standards and international guidelines) can become extremely difficult in reality, but for a multi vendor of process equipment project with a single DCS system it’s extremely important with precise project interpretation of standards/guidelines like S88 supported by well structured process – and automation oriented planning.


In particular special focus will appear on global testing activities and strategies based on S88 principles, organized with multiple international process equipment skid vendors coordinated via one PCS vendor.

Introduction

The pharmaceutical plant mentioned in this paper is built in a modular fashion, with multiple process equipment suppliers being responsible for delivering completely tested and documented process modules with processing equipment. These process modules contain the total system including control systems with application software.

The integrated and collaborative process automation engineering, planning and the modular approach, all together created a fast track project moving according to the costumer need.

But many manufactures of process equipment do not feel very confident with designing and taking responsibility of full automation into fully functioning process modules. That is why this paper will highlight how use of structural front-end engineering decisions and design following international standards and guidelines and in particular the S88 principles can help to achieve standard methodologies for consistent systems, provide major benefits for all involved in the project including creation of confidence in method and technology at the process-oriented equipment contractors organisation.

The customer’s approach for shorting “Time to market” of the product was another high level challenge for the project with the requirement for 18 months from project execution start to handover. This required a strategic combination of technology, methods and “customized” organisation structures (including collaboration between multidiscipline engineering team efforts at different levels). One major key issue in order to archive the time savings was the ability to validate the software before automation equipment was installed as opposed to after its installation.

A structured collaborative performed requirements analysing methodology to identify user expectation of the plant operability, is one successful key tool for engineering and design execution and project management.

This paper first deals with at the project scope, and then with at the engineering/design and execution from front-end decisions to handover and for the set-up and use of S88 Models and Structures, from initial design phase through construction to validation as well as the executed project management “set-up” for achieving the target.

Finally lessons learned will be highlighted.

This paper excludes basis of project decision i.e. owner philosophies and manufacturing strategies and following description focus on the concept of the control system contractor and one main process equipment contractor only.

The project. Realization of a fully automated 14.000 m2 full scale manufacturing facility for NovoSeven®, a haemophilia drug, which is produced by using recombinant DNA technology.

A fast track approach was taken for the project execution, in which the target “18 months from detailed design to qualification” has been met.


The project scope. (From the perspective of Control systems)

Turnkey delivery of process modules, from selected main equipment suppliers, for different process areas in the new plant covered everything, from detailed design and construction up to commissioning and qualification. The automation was done by using a distributed control system and information Management System.

The main equipment suppliers prepared all FS’s Functional Specifications and monitored together with NNE and user the software implementation and executed all tests for the automated process equipment, as well as the delivery included the preparation of all IQ and OQ protocols and the IQ/OQ qualification execution, following comprehensive requirements from the customer.

In order to fulfil the fast track requirements a model was developed for qualification.

Qualification was executed partly in parallel and as much as possible in combination with factory acceptance tests (FAT) at multiple construction sites across Europe. In particular it was mandatory to test and qualify all configuration/application SW at control system contractor test site EPM (UK).

System overview.

The installed control system is a standard Distributed Control System with information Management System based on available standard components and system.

The system handles the following functions: • Recipe Management • Batch Management • Data Collection • Batch-/Genealogy Reporting • Process Control and Supervision • Simple Warehouse functions • Manual Material Charge with raw material tracking information for logging • Instrument and equipment maintenance • Security System • System Network communication • Communication with stand alone PLC Systems • Interface with equipment Supplier control systems

These functions are implemented using built-in functionality in the control system and by configuring the system and application software to achieve the required functionality. With multiple process equipment contractors responsible for delivering completely tested and documented process modules with process equipment. These process modules contain the total system including control systems with application software. See figure 1 below.


PROCESS CONTROLLERS

BATCH SERVER HISTORY SERVER SYSTEM DBWORK STATIONSSPECIAL

APPLICATIONSSERVERS

WORK STATIONS

I/O PROCESS INTERFACE

FieldDevices

PLC SubSystems

FIELD BUS INTERFACEFIELD BUS INTERFACE

FieldDevices

PLC SubSystems

PROCESS EQUIPMENTProcess Modules (PM )supplied by multiple contractors

ProcessNetwork

PM A PM X

PM CPM B

Figure1: Principal System Structure Diagram

Front end definitions/- engineering. For large scale pharmaceutical projects it’s mandatory to plan the process - and automation engineering approach to cover all aspects of the life cycle from user requirements through implementation to validation.

By evaluation of opportunities and business risks the contractor (main equipment contractor) set-up for this project ended with 3 pre-qualified and selected main equipment contractors for process “packages” as follow:

Media preparation and fermentation (Sartorius BBI, Germany)

Purification (Millipore, France)

Stock Solutions and Solvents. (Semcon, Sweden)


One main contractor was in place for control systems (DCS and IMS) (EPM Emerson Process Management UK). Further several other constellations of contractors for utilities (process support, common process systems) and building services were in place.

NNE owned the responsible for global project management, construction management, engineering management and quality management.

Figure 2: Overall Project Execution (Details for FAT/SAT refer to the Testing section).

The above mentioned equipment contractors and control system contractor agreed and was committed for the overall project execution model (see figure 2), where special attention was taken to the testing phase as well for the split into process modules. The following section describes further decisions executed for the project.

The overall basic principles for process- and automation planning used and described in this paper are:

• Get the user involved in the functional specification /design • Don’t implement until you have designed. • Understand the process before generating the specifications /design. • Document the design. • Agree on the recipes up front.

Front end engineering definitions (decisions) comprised as example following strategically and conceptual activities and deliverables (Control system perspective):

Standards and guidelines

User Requirements Specification

Functional Specification Detail Design

Customer /NNE

Equipment Build

FAT 1 Equipment

ImplementationControl System

FAT 1 Hardware

FAT 2A Software

FAT 2B SoftwareFAT 3/4/5 Process Modules

SAT 1/2/3/4

NN

E / N

N R

eview and A

pprovals

Site Support

(NN

E project team

for each work package)

Main

Contractor


Modularisation principles

URS User Requirement Specification

The Control and Operability philosophy

Specification tasks

Contracting philosophy

Validation master plan/validation plans

Qualification tasks

Quality plan

Project life cycle activities.

Figure 3: NNE Project Activity Model with position of front-end definitions

The position of the activities during front-end definitions and engineering is illustrated at figure 3.

International Standards and guidelines used as references for this project. • GAMP Guide for validation of Automated Systems. • ISPE Baseline Pharmaceutical Engineering Guide Vol.5 Commissioning and Qualification. • S88 Batch Models and Terminology.

In order to achieve the fast track project approach it was necessary to run paralleled activities i.e. building activities at site and process equipment (divided into process module entities) - construction and testing/qualification off site. These modularized methods were based on the NNE engineering solution for modularised plant facilities and manufacturing processes. These methods breaks building and process down into Building Modules Specifications (BMS) and Process Modules Specifications (PMS) where process modules consist of process equipment (Process Unit Specifications) including the required control system for processing functionalities, qualification and documentation see figure 4.

Front-end definitions


Figure 4: Principle for Building-/Process modules

User Requirement Specifications

The URS User Requirement Specification is divided into two main categories (from the perspective of control systems).

One part of the specification related to the Controlled Process part (see figure 5) of the computerized system i.e. process equipment to be controlled and operating procedures that define the function of such equipment – and manual operations that don’t require equipment. (Control system configuration activities).

Another part See figure 5) relates to the control system i.e. hardware, system software and applications software that control the operation of the computer. (Control system).

Computerized System

Control Systems Controlled Process

Hardware

Processequipment

Vesselsinstruments

etc.

ProceduresRecipes

Applicationsoftware

SystemSoftware

Figure 5.

Definition of computerized system


An overall requirement specification (controlled process see figure 5) for plant control and operability philosophy was prepared and defining high level functionalities i.e. following: (Control system independent).

Plant Description (including: Physical Model (From top to S88 Process cell level), Batch control, equipment entities, Recipes, operational modes, operational States, Hygienic states.

• Batch control Activities • CIP/SIP Methods • Instrumentation • Alarm, Warnings, Messages. • Exception handling States • Operator Interface (HMI)

All requirements were jointly created by customer and NNE. Main contractors executed engineering activities, such as PFD, P&Id s, FS etc. for each particular package which describes detailed “solution” responses to the requirements.

Functional Specifications

When focusing on control systems as well as equipment functionality, the FS-Functional Specifications are the key documents to create common baseline for functional understanding between Customer, Engineer (NNE) and contractors. Wise management this opens up for the opportunities to reuse and uniform plant operability of aligned processing requirements between contractor packages.

Ideally the functional specification process should ensure: • Users/customer have the opportunity to input and can make sure that their requirements are

considered. • Functional Specification is carried out in a rational, practical, uniformly and documented

way. • Important design decisions are not made by programmers whilst coding.

The functional specification process (Named Functional Requirements Analysis) includes. • The decomposition of the process and recipes into the S88 physical and procedural objects, to

be represented on a set of diagrams and associated tables • The detailed design of each of these objects gives basis for programmers to provide systems

that meet the functional requirements.

The resulting design is contained in a functional specification model.

The methodology is based on the Models and Terminology defined in S88 (IEC – 61512). There are however many interpretations of S88. Different understandings of operations versus phases are common and the same applies to equipment modules versus control modules. Unless the standard is further detailed and operational analysed by company or project standards, there is still a lot of room for inconsistencies and misunderstanding.


For managing this we (NNE) issued (for the process equipment contractors) a reference model, (object database) “the functional specification model”, which clarifies the extent to which the choices that are allowed in S88 applies to the project. It also shows how Units, Equipment Modules, Phases etc. are defined. The reference model principle provides a sample of generic control mechanisms that are common to the entire process (I.e. Transfer phases, common resources and particular a set of agreed CM Control Modules (Library)), and by example it illustrates in general views how the diagrams and tables define the required Control and Operational activities (in plain process functions language), without control system influences.

This include i.e.: • Generic control requirements for both normal operation and exception handling. • The structure of the model, based on S88 • The use of diagrams • The use of matrixes (Equipment states) i.e. • The use of tables and lists of data. (Parameters) • How various control objects (items such as units, equipment modules, control modules,

common resources modules, unit procedures etc.) are defined. • HMI aspects of the model.

The used model defines two of the S88 models and the relationships between them (see figure 6) • The physical model: in terms of site, areas, process cells (With identification of

Process Modules), units, equipment modules and control modules. This includes the basic control functionality.

• The procedural model: The recipe is defined in terms of procedures, unit procedures, operations and phases.

Figure 6. S88 Physical- and Procedural model used for FS development (break down).

As mentioned earlier there is still a lot of room for inconsistencies, misunderstanding and plant wide functional uniformities. To improve this, we executed “white smoke meetings – work shops” before major activity take off (i.e. preparation of FS’s and the Commissioning and Qualification phases). At these meeting all practical issues and concepts were described, solutions decided and commented and committed to by all parties. Further monthly global meetings were held for all contractors and NNE to sort out conceptual engineering- / coordination issues, engineering status etc.

Auxiliary proceduresCIP Line

Product B Product A

NFVII

Procedural

modelPhysical

model

FERM1

Area

200 lProcess Cell

Unit

Common ressource

Control module Phase

Unit procedure

Operation

Equipment module

Procedure

Process Module


Finally the NNE project team for control systems supported the project by two highly qualified and competent engineers (system engineer and overall practical process- automation planning engineer) who coached the main contractors engineering teams for interpretation of the reference model (Toolbox), how to build the models and get uniformity between packages as well as using the standard engineering database tool (Control Draw) which was delivered by the project to all contractors and recommended to be used by all contractors. See Figure 7

With above described front end decisions and approved documents a final base lining of scope for the control system, process equipment and production recipes took place. Requirements were corrected, to reflect identified changes to achieve realistic/achievable production process functionalities etc.

Figure 7: Typical drawings with data for physical and procedural models (Database Objects)

The above defined structure was loyally used as identification of elements in the project for down stream engineering executions by the different contractors both for definition terminology, naming and communication convention internally and – externally, and to manage i.e. following issues:

• Implementation • Construction • Schedule activities. (Erection -, C&Q activities etc.) • Test off site/- on site • Process module delivery lists. • Code reviews • Module and Integration tests. • Commissioning off site/- on site • Qualification off site/- on site • Technical documents. (Document management)

Vessel

V902 221

WFI

V904

221 V905

221

CIP 1F

V912

241

CIP 1F

CST

78

V910

221

Waste

V586

221

V585

221

AC Waste

V902 V904 V905 V910 V912 V585 V586IDLE Close Close Close Close Close Close CloseBLEED Close Close Close Open Close Close OpenCIP1 Close Open Close Close Open Close CloseCIP2 Close Close Open Close Open Close CloseCIP3 Open Close Close Close Open Close CloseSIP Open Open Open Close Close Open CloseSIP1 Close Open Close Close Close Open CloseSIP2 Close Close Open Close Close Open CloseSIP3 Open Close Close Close Close Open Close

f Q

Start Permissives ok

1[PRESS]

Vessel Pressure [PT-I1] >= Setpoint <CP1>

PhaseDrain

Fermenter[DRAINFER]

StartPhase

4[READY]

END

StopLogic

2[DRAIN1]

3[DRAIN2]

Final Drain Timer <CP4> elapsed

Vessel Weight [WIT-A1] <= <CP3>

Always


Engineering execution activities. Based on the scope and modular break down and naming definition detailed above, the individual contractors mainly executed the deliveries according to own shop floor work flow and manufacturing procedures for process modules and the control system contractor managed the control system according to the same definitions. (Again the focus is the perspective for the control system)

Detailed design

With complete Functional Specifications or agreed complete split (Physical- and procedural model) the control system contractor (EPM) prepared the FDS Functional Design Specifications which detailed the required functionality from the FS for the main equipment contractors by using direct data pasted from the FS’s where applicable. Further design specifications were prepared for the control system if required for programming details.

Functional Design Specification

The Functional Design Specification (FDS) is developed from the User Requirements Specification and from the functional specifications. This document will describe how the control system should operate and how it meets the complete system requirements. The FDS contains detailed information on the interfaces between the computerised system and its operating environment. The Control system contractor produced a number of Detailed Design Specifications for more specific information detail before programming. Lead Engineers from the control system contractor were placed at the main contractor locations to implement and transform the FS required functionalities into FDS’s. To ensure traceability of functionality, one Functional Design Specification is provided for each Functional Specification.

Hardware Design Specification

The Hardware Design Specification defines the control system hardware for the system.

Test Activities.

Following overall main activities for testing (including qualification) as follow: • Process equipment tests (Physical properties of equipment) • Process control system test (Hardware, system software, applications software and network

etc.) • Recipe test (execution of recipe on the equipment).

Described below are the main testing activities associated with the Process Equipment.


The naming convention (FATx and SATy) are “ activity slicing” to identify the testing activities in a manageable and practical way and support the opportunity to create consistency across packages planning for parallel testing activities as well as allow flexibility for each Process module to be tested off site/on site to a certain level. Naming of test for “activity slicing” is according to S88 with other practical testing activities at that state of the particular module.

Process equipment testing activities.

The testing including qualification for dedicated process areas was split into several parts. The relevant parts of the testing are shown as shaded in figure 8 below. Non-Shaded parts of the testing are specific to control system software and Hardware, These test activities are detailed in the Control System Module and Integration test below.

Figure 8: Structure of testing- and qualification activities

The process equipment for different process areas was delivered to the site in complete functional process modules. This will facilitate their qualification on a modular basis with system qualification testing to be executed, where possible, at the Main contractor’s site. Integrity testing of the installed process equipment modules at site was executed at the start of the onsite qualification activities (IQ/SAT1), to verify that none of the qualification activities executed prior to site installation have been invalidated.

IQ/FAT 1 (Process Equipment)

IQ/FAT 4

IQ/FAT 3 SW/HW

OQ/FAT2

Software

IQ/FAT 1 (PCS)

Hardware

OQ/FAT 5

OQ/SAT 2

IQ/SAT 1 (Proces Equipment)

OQ/SAT 3

OQ/SAT 4

Control system contractor Offices

Main Contractors Facilities

Site

IQ/SAT 1 (PCS)

Code review

d MIT


Installation testing and Installation Qualification

IQ/FAT1 (Process Equipment) Test

The purpose of this testing is to verify and document that equipment, instruments, valves piping and other components of the system are present and installed correctly, as defined by the User Requirements Specification and Design Documentation and to ensure that the installation adheres to all prevalent regulations and standards, prior to loop checking and functional testing.

IQ/FAT4 (Process Equipment) Test

The purpose of this testing is to verify and document that all instrumentation is installed and functioning correctly, as defined by the Requirements Specification and Design Documentation and to ensure that the installation adheres to all prevalent regulations and standards, prior to functional testing of the system.

IQ/SAT1 (Process Equipment) Test

The testing will also verifies and document that the all connections to the system are present and installed correctly, as defined by the Requirements Specification and Design Documentation and to ensure that the installation adheres to all prevalent regulations and standards. This testing will also verify the integrity of the process modules after installation on site.

This testing verifies that the system is as it left the contractor shop floor and identifies any areas that may require retesting, including any retesting of control loops or re-testing of process equipment functionality.

Operational testing and Operational Qualification

Operational Qualification (OQ) of the system is documented evidence that the system operates according to the Requirements Specification and the functional specification through all anticipated ranges.

It included identification of all important operating parameters, anticipated ranges, appropriate acceptance criteria, and the tests are performed to demonstrate that the system meets the criteria’s.

The system OQ was executed in four distinct parts located in the equipment contractor shop floor and/or on site.

The OQ of the integrated system was executed according to project defined delivery plan, before delivery of the process modules to site.

The four different parts of the testing was as follows: OQ/FAT5 :

The testing of any equipment functionality (S88 Equipment Modules and S88 Phases) that can be tested without the supporting plant utilities. OQ/SAT2 : (Control system and process equipment)

Testing of supporting utilities and connections/transfers between individual Units and process modules. OQ/SAT3 : (Control system and process equipment)

Completion of all Testing of equipment functionality, incorporating all S88 equipment modules and S88 phases that could not be completed as part of OQ/FAT5.


OQ/SAT4 : (Control system and process equipment)

Testing of recipes and procedures.

OPERATIONAL TESTS TEST TYPE Ta

nk

XXX

Tank

YYY

M

ixin

g X

Rea

ctor

A

Tank

ZZZ

EQM Test Phase Test Recipe Test

Test Test 1302A 1310A 1120A 1120B 1120S

EQM OQ Pressure Control Test

EQM OQ Agitation Control Test

EQM OQ Aeration Control Test

EQM OQ Interlocks Test

EQM OQ Pressure Hold Test

PHASE OQ Full Vessel SIP Test

PHASE OQ Empty Vessel SIP Test

EQM OQ Empty Vessel SIP Test

EQM OQ SIP Test (Transfer Routes)

PHASE OQ SIP Test (Transfer Routes)

PHASE OQ Liquid Filters SIP Test

PHASE OQ Liquid Filters Integrity Test

EQM OQ WFI Flush Test (Routes)

RECIPE OQ CIP Vessel Recipe Test (Full)

RECIPE OQ CIP Vessel Recipe Test (Reduced)

RECIPE OQ CIP Line Recipe Test

RECIPE OQ CIP Filters Recipe Test Figure 9: Typical OQ test schedule applying to S88 structure as key index.

All Commissioning and OQ tests for the process equipment and the recipes apply stringent to S88 structure (naming) and the functionality tested according to the FS specification models. See split example of schedule applying to S88 terminology at figure 9.

Same methodology was applied for planning and execution of commissioning and qualification tests.


Note:

Process Units, Equipment modules are tested on all pieces of equipment on which they occur. Phases are basically only tested once on each type of equipment.

Control System Module and integration testing and Qualification.

Described below are the main testing activities associated with the Control System. (Qualification and testing part are related to figure 8)

Software Module and Integration Test Specification

The Software Module and Integration Test Specification describe the structural tests to verify that each software module meets the requirements defined in the FDS and that the modules communicate properly with each other as defined in the FDS.

Module Testing

This is the process of evaluating application software modules based on their performance against design specifications. Module testing was performed on manageable, segments of code with a level of complexity allowing exercising of all module functions.

Module testing must take into account the internal function of the software module.

Module Integration Testing

Module integration testing is the process of testing combined software modules to evaluate the interaction between them. These tests examine the transfer of data and control parameters across the module interfaces and demonstrate that the desired functionality can be supported.

Installation testing and Installation Qualification IQ

The purpose of the Installation Qualification IQ is to provide documented evidence that the delivered control system has been installed to system design specifications and drawings and functions in accordance with specifications. The testing is performed with the actual hardware and software that will be part of the installed system configuration. The testing is accomplished through either actual or simulated use of the software being tested within the environment in which it is intended to function.

The IQ will be subdivided into three distinct steps for execution. Each part will have a post execution approval, which must be completed before proceeding to the next part in the qualification of the control system.

Step1-IQ/FAT1 Test

The purpose of this testing is to ensure and document that the hardware and system software with all its components is operating correctly as defined by the Requirements Specification, Hardware Design Specification and Detailed Design Specification prior to application software testing.


Step 2-IQ/FAT 3 Test

The IQ/FAT 3 Test Specifications describe the testing to be performed at the various equipment contractors’ sites, after the completion of OQ/FAT2.

The purpose of this testing is to ensure and document that the hardware and software installed are the correct versions, and that all Hardware has been installed as per the manufacturers instructions, Requirements Specification and the drawings.

Step 3-IQ/SAT 1 Test Specification

The IQ/SAT 1 Test Specification describes the testing to be performed on the PCS hardware and software after the arrival of the equipment on site.

Operational Testing and Operational Qualification

Operational Qualification (OQ) of the automation system is documented evidence that the system operates according to the Requirements Specification and the Functional Specifications through all anticipated ranges. OQ may be performed on the integrated system or on each subsystem. It includes identification of all important operating parameters, their anticipated ranges, appropriate acceptance criteria, and the tests that will be performed to demonstrate that the system meets the criteria.

The software OQ was executed at the control system contractor office as part of the documented OQ/FAT 2. It was performed by Control System contractor and witnessed by representatives from the Main Process Contractors and/or NNE. All of the control sequences was exercised using simulated I/O. Qualification of the control system integrated with the various process modules is detailed in equipment testing and qualification, see above.

The response of the control system to both normal and abnormal test cases was recorded and evaluated against pre-determined acceptance criteria derived from the User Requirement Specification, Functional Specifications, Functional Design Specifications and Detailed Design Specifications.

All tests are based on pre-defined and documented parameters settings. Boundary test shall be performed where applicable.

OQ/FAT2:

Testing was, of project timing reasons, split into two parts FAT2A and FAT2B.

• The OQ/FAT 2A covers similar aspects to the software module and integration testing.

• FAT2B shall mainly be concerned with the higher level functionality of the overall system.

Change Control Change was controlled by Control System contractor from the start of qualification activities (FAT1).


Configuration Management Configuration Management was implemented by control system contractor from the beginning of testing activities. The control system contractor produced a Configuration Management SOP for approval. This document contained details of what items will be under control and how this control will be performed, documented and audited. This document specified how software versions were controlled during the acceptance testing at different main process equipment contractor sites, the relationship to change control procedures and how storage and delivery was managed.

Project Management. This type of project requires real challenges for the project organization (including contractor’s project team) and must be based on global project management with commitment. The innovative modularized process break down sets the project apart from conventional engineering and construction and requires thinking in systems. NNE as overall project managers must know the details and keep the entire project process in sight at all times.

Some key issues for highlighting (From control system perspective):

• Management of several project teams. • Clearly specified roles and responsibilities. • Supervisory and advisory roles for contractor packages. • Management of interface points. • Timing is difficult, seek opportunity for decoupling by re- scheduling • Clearly defined communication rules. • Contractual differences. • At figure10 the organizational relationships in the project is illustrated.

Figure 10: Contractual relationships.

Customer/User

Novo Nordisk Engineering

BBI (Germany)

Millipore (France)

Semcon(Sweden)

Utilities

Emerson(UK)


Lesson learned.

The following key issues for successful project execution:

• Always use a structured (S88) approach and break the work down into manageable,

reproducible elements and follow standards and use consistent terms starting with structuring the URS splitting, if possible.

• Make a plan and stick to it. • Time spent at the front end of a complex project for definition and agreement facilitates

easier implementation. • Get the shareholders (user) involved from the beginning. • Functional specifications structures dictates the qualification tasks - put your effort in good

specifications. • Management of such complex “distributed” project execution is the most demanding

component and brings with it a higher risk factor. • Never change “agenda” at handover.

Conclusion. The task presented at the start of this paper stated the use of S88 in the project execution for project with multiple stakeholders by use of one control system contractor.

Seek and create decoupling wherever possible. Use it proactive for parallel distributed activities and by the process module and S88 structured project execution

A staging test approach allows early testing and utilization of subcontractor’s resource more effectively. This off loads on–site activities and opens up for a more flexible schedule where limited slack and unforeseen events can be absorbed.

By use of a strategic approach for use of S88 control elements typical used at biotech- and pharmaceutical process equipment it will helps with the opportunity for move automation (control system) activities off the critical path of the project. (I.e. by using the functional specification models for database libraries of S88 modules).

experiences from implementation of a single dcs solution ... · project management, front end...

Documents