API 18LCM (Life Cycle Management) Report back to SC17 August 27, 2015 Review Team: Dave Wilkinson, John Strut, Smarty John, David Saul, Peter Moles.

Slides:



Advertisements
Similar presentations
Building a Cradle-to-Grave Approach with Your Design Documentation and Data Denise D. Dion, EduQuest, Inc. and Gina To, Breathe Technologies, Inc.
Advertisements

Program Management Office (PMO) Design
Roadmap for Sourcing Decision Review Board (DRB)
Internal Control–Integrated Framework
Transition from Q1- 8th to Q1- 9th edition
CIP Cyber Security – Security Management Controls
ITIL: Service Transition
Validation, Verification, Qualification : Which is right and does it really matter?
© 2011 Underwriters Laboratories Inc. Product Recall and the Supply Chain: ISO Best Practices Robert Pollock Chair, US Technical Advisory Group for ISO.
SAE AS9100 Quality Systems - Aerospace Model for Quality Assurance
UGDIE PROJECT MEETING Bled September WP6 – Assessment and Evaluation Evaluation Planning  Draft Evaluation plan.
Product Lifecycle Management
1 Subsea Reliability and Integrity Management Reliability and Integrity Management – Have very similar intent - almost the same definition – Treated separately.
External Defibrillators: Recalls, Inspections, and the Quality System Regulation Melissa Torres Office of Compliance December 15, 2010.
Cover graphic should fill and not exceed the defined grey box. June 27, 2013 Gary Devlin API Subcommittee 18 – Quality Task Group 7: Product Life Cycle.
Top Tactics for Maximizing GMP Compliance in Blue Mountain RAM Jake Jacanin, Regional Sales Manager September 18, 2013.
Cover graphic should fill and not exceed the defined grey box. June 14 th, 2012 Gary Devlin API SC 18 – Quality Product Life Cycle TG7.
“How Industry Learns” --- Proposed Project --- Karen Paulk, ConocoPhillips, Chair, Process Safety Group & Ron Chittim, API CRE Chairs & Sponsors Workshop.
Introduction to Network Defense
QUALITY MANAGEMENT SYSTEM ACCORDING TO ISO
Introduction to ISO New and modified requirements.
1 HPHT Equipment Development Process Presented by Jim Raney Based on the work from 6HP.
Standard WBS Version 1.0 WBS2-3.pptPage 1 Standard Work Breakdown Structure Legend = Decomposes to lower level WBS elements 4.0 Implementation 4.0 Implementation.
Commissioning of Fire Protection and Life Safety Systems Presented by: Charles Kilfoil Bechtel National Waste Treatment Plant Richland WA.
Cover graphic should fill and not exceed the defined grey box. API SC 18 – Quality Product Life Cycle TG7.
Visit us at E mail: Tele:
PRODUCT TRANSFER.
3.08 b Determine venture’s information technology.
Installation and Maintenance of Health IT Systems
Product Development Chapter 6. Definitions needed: Verification: The process of evaluating compliance to regulations, standards, or specifications.
Service Transition & Planning Service Validation & Testing
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
IT Requirements Management Balancing Needs and Expectations.
Software Requirements Engineering: What, Why, Who, When, and How
Product Documentation Chapter 5. Required Medical Device Documentation  Business proposal  Product specification  Design specification  Software.
Software Project Management
PwC 21 CFR Part 11 – A Risk Management Perspective Patrick D. Roche 07 March 2003, Washington D.C.
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
Integrity Management Continuous Improvement Fitness For Service and Management of Pre-Regulation Pipe Chad Zamarin Chief Operating Officer NiSource Midstream.
Hazards Identification and Risk Assessment
Project Specification part 2 BTEC National. Project boundaries or scope The boundaries or scope of a project are what the project aims to achieve. The.
PER15K Protocols for Equipment Rated Greater Than 15,000 PSI ECS Report
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
1 | 2010 Lecture 3: Project processes. Covered in this lecture Project processes Project Planning (PP) Project Assessment & Control (PAC) Risk Management.
SAAMF Roadshow Durban CSIR NML Eddie Tarnow Metrologist: Torque & Automotive 14 June 2006 ISO/TS 16949:2002 certification – Meeting the requirements of.
Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill/Irwin 7-1 Chapter Seven Auditing Internal Control over Financial Reporting.
Validation | Slide 1 of 27 August 2006 Validation Supplementary Training Modules on Good Manufacturing Practice WHO Technical Report Series, No. 937, 2006.
PPTTEST 12/26/ :41 1 IT Ron Williams Information Technology Management Project Management.
RLV Reliability Analysis Guidelines Terry Hardy AST-300/Systems Engineering and Training Division October 26, 2004.
The Implementation of BPR Pertemuan 9 Matakuliah: M0734-Business Process Reenginering Tahun: 2010.
Purchasing Forum – May The integration of the activities, plans, attitudes, policies, and efforts of the people of an organization working together.
Checking and Corrective Action EPA Regions 9 & 10 and The Federal Network for Sustainability 2005.
Operational Excellence Quality and Customer Experience Operational Excellence Quality and Customer Experience Product Lifecycle Management.
OHSAS Occupational health and safety management system.
Failure Modes, Effects and Criticality Analysis
Update of API Standards for Supply Chain Management API Standard 20J – Qualification of Distributors.
Computer Security: Principles and Practice First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Chapter 17 – IT Security.

ITIL: Service Transition
World Health Organization
Software Quality Control and Quality Assurance: Introduction
Software Quality Assurance
Software Requirements
Impact on SC 6 Documents by Kenneth Young
Chapter 13: Systems Analysis and Design
API 14H Task Group Status Proper Classification of Document
PSS verification and validation
CR-GR-HSE-302 Management of change
Management of Change GROUP HSE RULE (CR-GR-HSE-302)
Presentation transcript:

API 18LCM (Life Cycle Management) Report back to SC17 August 27, 2015 Review Team: Dave Wilkinson, John Strut, Smarty John, David Saul, Peter Moles

What is API 18LCM? Newly drafted API standard – likely to be balloted prior to YE’15 Goal : “provide a means of maintaining and demonstrating continued conformance of product to original and/or current product definition” from cradle to grave. Scope: “to address the management life cycle for products in the petroleum and natural gas industry”

How does it work? (1/2) Applied to products in the petroleum and natural gas industry It is not clear which equipment it is to be applied to or who will make this determination – user, owner, regulator, API? Unclear if use is intended to be restricted to only products manufactured in accordance with API standards & specifications; could apply to any product regardless of pedigree. Interpreted as requiring data tracking to lowest component level Requires development of LCM plans for management of data pertaining to each product – Implemented by LCM Service Provider (LCMSP) of whom these entities are is intentionally left to be defined Five levels of requirement are currently defined in the draft document – but next draft may only include three levels

How does it work? (2/2) Determination of ongoing LCM status will be by LCMSP based on: Product identification Product definition Technical specifications, verification & validation tests, acceptance criteria, assembly & testing requirements, preventative maintenance requirements Manufacturing records Traceability Usage history Repair and maintenance history

Where does it fit in? Because it defines and manages hardware compliance, it must be a higher level document: Q1 > Q2 > 18LCM > 17D > 17N > 17Q….? 18LCM > Q1 > Q2 > > 17A? If hardware is modified, the need for qualification is not identified in 18LCM; perhaps add verbage for qualification per RP 17N?

What’s missing? What are the criteria for determining what equipment should be managed per 18LCM? Related to well control/integrity? Hydrocarbon pressure containing? All API equipment? All equipment? How is the appropriate LCM level determined? HES risk based? Production loss / downtime risk based? Transition plan Deployment to be defined outside of API 18LCM Can existing equipment be “grandfathered”? Lead in time for application?

How will it impact the market? Changes to hardware offshore become very difficult – Spotlight on MOC requirements – Potentially send some modifications underground and unreported – Tend to encourage continued conformance to OEM specified parts. Implementation – Initially difficult due to incomplete documentation of systems – huge demand on manufacturers (costs) – Grandfathering would be required for existing hardware – Rolling deployment on critical new hardware to start – Monogrammable? Management – Once enacted, becomes an unstoppable train - probably put into law – Success dependant on strong documentation collection (discipline) and ongoing management (software) Silver lining – Massively improved access to data for integrity and risk assessments

Subsea Equipment Examples Tree SCMManifoldSubsea TreeTree USV (1)C/WO Riser API DocumentStd 17FRP 17PSpec 17D RP 17G (2) Monogrammable?No YesNo Hydrocarbon containing? NoYes Part of well containment envelope? No Yes Routinely retrieved to be maintained or modified? YesNo Yes Typically owned byOperator Contractor Effort required to track LCM status High (Often repaired) Low Medium (Usage history) High (Often repaired) Recommend application of 18LCM? No. Not a critical part of well containment envelope. Yes. Critical part of well containment envelope, therefore consequence of life cycle failure potentially high. (1)Including valve actuator (2)Being upgraded to Standard?

Next Steps CSOEMR – Need co-ordinated approach Across all relevant SCs Evaluate benefits versus costs Define grandfathering process and limits on initial application - to HSE critical equipment? Defer publishing until co-ordinated implementation plan in place SC17 – Define applicable hardware – Define appropriate LCM levels – Prepare detailed application examples

Take aways Potentially huge cost and operational impact on the industry – once deployed, never removed How widely deployed in industry? What really matters – qualitative cost versus benefit analysis required Need a co-ordinated and predefined application plan prior to publishing document