Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

API Spec Q2 Design and Development Requirements for Service Providers

#1
Hi All,

Few days ago our company have been audited against API Spec Q2 standards and one of the findings was related to Design and Development:
(Design records of company services did not address planning, verification, final review and approval of service design).
So as a drilling tools rentals company the design of service was done by process mapping but this did not convince the auditor who asked a comprehensive design of rental service including planning, verification, final review and approval of service design.

Can somebody help on how a service is designed according to API Q2 requirements?

Many thanks in advance
 

Sidney Vianna

Post Responsibly
Staff member
Admin
#2
API Spec Q2 5.4.1 requires your documented procedure to define the D&D phases, etc...

What does your documented procedure say about it?
 
#3
Hi Sidney,
Thanks for Replay..
Please see below what the procedure is saying about it:

This procedure identifies the:
a) Process activity Plan(s), including plan updates, used for design development of service and use of Service Related Product;
b) Design and development stages;
c) Resources, responsibilities, authorities and their interfaces to ensure effective communication;
d) Review, verification and validation activities necessary to complete each design and development stage;
e) Requirements for a final review of the design

In the event that company outsources any aspect of the design and development process it ensures that the supplier meets the requirements of 5.6.1.6 of this manual.

5.4.2.2 Service Design and Development Inputs
The process for determining the required design and development inputs is defined in MSP 06. Inputs are identified and reviewed for adequacy, completeness and lack of conflict.
Inputs include functional and technical requirements, and the following, as applicable:

a) Customer-specified requirements (see 5.1);
b) Requirements provided from external sources, including API product specifications;
c) Requirements for Service related Product including functional and technical requirements
d) Environmental and operational conditions;
e) Methodology, assumptions and formulae documentation;
f) Historical performance and other information derived from previous similar designs;
g) Legal requirements; and
h) Results from risk assessments (see 5.3).

Inputs will be documented reviewed for adequacy to ensure that they are complete unambiguous, and not conflicting with other requirements. Records of Design and Development outputs shall be maintained.


5.4.2.3 Service Design and Development outputs
Outputs are documented to allow verification against the design and development input requirements.

Outputs:
a) Meet the input requirements for design and development;
b) Provide appropriate information for purchasing of any required SRP;
c) Provide controls for the execution of the service, including allowable variations in the service executions parameters.
d) Include or reference acceptance criteria for the completion of the service; and
e) Include identification of, or reference to, Service Related Product or components deemed critical to the design;

Records of design outputs are maintained.
Identification of criticality of service-related products and/or components can be maintained outside of the design and development process.

5.4.2.4 Service Design and Development Verification
At appropriate stages of design, design verification is performed to ensure that the design stage meets the design stage input requirements. Records of design verification are maintained.

5.4.2.5 Service Design and Development Final review and approval
Design final review is performed in accordance with planned arrangements to ensure that the resulting service design is capable of meeting the specified requirements. When possible, Final review is completed prior to the delivery of the Service or SRP.
After final review the completed process design is approved by competent individual(s) other than the person or persons who developed the design.

Records of the design final review, approval and any necessary actions are maintained (see 4.5).

5.4.2.6 Control of Service design and development change
In accordance with requirements documented in MSP 06, all design changes and modifications are identified, reviewed and verified by the management of Change process as appropriate.
 

Marc

Captain Nice
Staff member
Admin
#4
Do you have a completed planning, verification, final review and approval of a service you have designed as defined by your procedure?
 

Sidney Vianna

Post Responsibly
Staff member
Admin
#5
As Marc asked, it seems that your documented procedure covers the API Spec Q2 requirements. So, the issue becomes the availability of objective evidence and records to demonstrate that you are following your D&D process procedure. In a perfect world, this concern would have been identified by your internal auditors as well as the external auditor during a Stage 1 audit.

To ask for someone else's model of D&D process seems counterproductive to me.

For what it is worth, ISO used to have a standard, ISO 9004-2:1991 that dealt with quality assurance and quality management for service providers. It contained text about the D&D process for service organizations. If you search for ISO 9004-2:1991, you will find a copy available online. As the document has been cancelled and withdrawn by ISO, I am not sure if it would be a violation of copyright policies to access that document, or not.

Good luck.
 
#6
Hi Mark,

Actually, what we have is a master process flow chart with service sequence, inputs / outputs, personnel involved and deliverable. we did not cover planning, verification, final review and approval of a service as API Q2 required.
The problem is we have difficulties to figure out a way to put all these information together. Should it be one document for each phase? or one document where all these stages are listed?
In rental of oil tools service, the process is the same for almost all jobs (the only differences can be requirements from a customer to another, or if there is a change in the process).
Anyway, the light comes progressively, thanks for your help.
 

Marc

Captain Nice
Staff member
Admin
#8
Actually, what we have is a master process flow chart with service sequence, inputs / outputs, personnel involved and deliverable. we did not cover planning, verification, final review and approval of a service as API Q2 required.

The problem is we have difficulties to figure out a way to put all these information together. Should it be one document for each phase? or one document where all these stages are listed?

In rental of oil tools service, the process is the same for almost all jobs (the only differences can be requirements from a customer to another, or if there is a change in the process).

Anyway, the light comes progressively, thanks for your help.
Since you have a master process flow chart, I'd have a contract review form with each of the items. Whether one document or several is entirely your choice, but keep it simple.

Since most of your orders are the same, your contract review output should be acceptable for planning unless there is something "special". Then again, some years ago I had a client which did rentals. They had a "standard" agreement and process for every individual thing they rented. This included a "check-in" list for when a given item was returned. Their "planning" was a check list they used prior to releasing the equipment. Their "verification" was done when they made the "check list" for the piece of equipment. Final review and approval was their "contract review" output (the service contract signed by the customer).

That you follow the same process for almost all orders is good but you still have to consider customer/contract specific requirements.

I would think that during contract review you would assess all special requirements and add them to a basic contract review output form which would then be you basis for contract acceptance.

I'm not in the oil/gas business so my comments should be taken as general feedback thoughts. Unfortunately, not many oil/gas people visit here. Then again, Elsmar can not be all things to all people/industries.
 


Top Bottom