Home>API standards>API TR 18TR2-2017 pdf free download

API TR 18TR2-2017 pdf free download

API TR 18TR2-2017 pdf free download.Guidance to API Specification Q2.
Contingency planning is the process by which the organization identifies backup plans in the event that the risk which impacts service delivery materializes. Contingency planning does not change the probability of the event occurring, but can change its impact. Developing a contingency plan involves making decisions in advance about the management of services and SRPs, coordination and communication procedures, and awareness of a range of technical and logistical responses. Risk mitigation and contingency planning are two strategies that are used in the management of risk. Both are closely related to one another as they are sequential, complementary steps used in the risk assessment process. Every contingency plan requires a risk assessment (see section 5.5.2); however, some risks may be deemed acceptable by the organization without further mitigation or contingency planning. 5.6.1 Purchasing Control Requirements established in section 5.6.1 a)–e) are applicable to purchasing control of critical and non-critical services, and SRPs. The difference between the requirements for critical and non-critical services is that the organization performs an on-site assessment of the critical service or service-related product supplier prior to initiation of the purchase agreement. The purpose of the assessment is to verify the supplier’s ability to meet the specified scope of work, and that the supplier’s QMS meets the requirements specified by the purchasing organization. For non-critical service or service-related product suppliers, the organization has the option of performing one or more of methods identified in section 5.6.1 (i, ii, iii). It is the organization’s responsibility to determine and define what is critical, and non-critical, as it relates to SRPs or services, and the evaluation process is defined in section 5.6. The product or service being supplied and the associated risk are used to determine QMS requirements. NOTE See further clarifications in Section 1 Scope and Application.
5.6.2 Purchasing Information Requirements established in section 5.6.2 a)–e) are applicable to purchasing information for critical and non-critical services and SRPs. Each requirement is applied “where appropriate” for the type of service to be performed and/or SRP to be provided. Examples of where this information could be captured or referenced include, but are not limited to: purchase order, master service agreement, master purchasing agreement, contracts, addendums, statement of requirement, etc. 5.7.2 Service Quality Plan A Service Quality Plan (SQP) is a requirement for all services. The organization is responsible for determining how to build a SQP that will be effective, usable and compliant to all requirements listed in 5.7.2. The SQP is not intended to be a bridging document between multiple management systems. It is possible to employ one document or a combination of documents to achieve this. The SQP can be standard, job specific, service specific, or customer specific—as long as it meets the specific requirements of API Q2. “External parties” is a general term that can describe customers, regulators, suppliers, contractors, subcontractors and other parties external to the organization that impact the delivery of the service. In other parts of API Q2 where the standard mentions subcontractors and/or suppliers, there are specific requirements that are applied to those external parties. The SQP requires identification of the responsibilities of suppliers, subcontractors and other external parties. This includes the identification of the subcontractor, and the description of the controls over the subcontractor.
5.7.3 Identification and Traceability API Q2 specifies the minimum set of requirements for traceability for critical SRP, which includes rental tools designated as critical. Specific material traceability and records requirements will depend on the product and the requirements defined by the organization and the customer. Critical SRP, including legacy tools that do not meet the traceability requirements of API Q2, would be identified as nonconforming product and handled in accordance with section 5.10. The identification of the criticality of SRP (including components) is based on risk assessment, and performed during the design of the service. Identification of an assembly as critical does not, by default, make all the components in the assembly critical. It is the responsibility of the organization to communicate the criticality of SRP to applicable personnel throughout the service realization process.

Related PowerPoint Templates

Template Categories
Popular Tags