Mike Howell
EASA Technical Support Specialist

The theme for the current EASA administrative year and the 2018 EASA convention is “Connect to Quality.” Just as the size, organizational structure and processes of EASA member service centers can vary widely, so can their measure of quality in product or service realization. To understand why there is no cookie cutter approach to quality for service centers, it’s helpful to work through a few terms.

Since the early 1990s, the ISO 9000 standards series have in many circles been construed as overly complex. However, when implemented as intended, these standards will help organizations of any size take a common-sense approach to sound business practices with an improved bottom line. That said, the standards are a valuable resource reference, whether compliance is desired or not, and here are a few terms as defined in ISO 9000:2015.

• Quality: the degree to which a set of inherent characteristics of an object fulfils requirements
• Characteristic: distinguishing feature
• Object: entity, item, anything perceivable or conceivable; e.g. product, service, process, person, organization, system, resource
• Requirement: need or expectation that is stated, generally implied or obligatory

The term quality is often supplemented by an adjective such as poor, good or excellent. If we use the definition of quality provided above, it becomes clear that the recipe for achieving quality excellence can be quite different from one service center to another depending on differences in requirements. 

For example, the requirements for a large service center repairing a reactor coolant pump motor for a nuclear generating station may be much different than those of a small service center repairing a dough mixer motor for a bakery. Nevertheless, both service centers might provide the same level of quality to their respective customers.

For management of requirements, some straight-forward guidance can be found in ISO 9001:2015. The standard simply requires that the organization (service center) determine the requirements for the products and services they offer, review those requirements, and manage changes to the requirements. Each of these three tasks can be expanded for clarity.

Determining the requirements for products and services
When determining the requirements for products and services to be offered to customers, the service center should ensure that the requirements are defined, including applicable statutory / regulatory requirements and any requirements considered necessary by the service center. Examples of regulatory requirements encountered in the U.S. include those established by the Occupational Safety and Health Administration (OSHA), the Mine Safety and Health Administration (MSHA), the Nuclear Regulatory Commission (NRC) or the Food and Drug Administration (FDA). Examples of requirements considered necessary by the service center could include those found in EASA AR100 and/or internal best practices.

Additionally, the service center should ensure that it can meet its claims for products and services offered. For example, if the service center advertises class H stator rewinds, it should have capabilities to install a class H insulation system, which has been qualified as such by test, as opposed to a pieced together bill of materials based on individual material data sheets. 

Review of the requirements for products and services
Before committing to supply products and services (accepting an order), the service center should conduct a review to ensure it can meet all applicable requirements.

1. Requirements specified by the customer, including requirements for delivery and post-delivery activities. One example of this type of requirement is a customer spec invoking IEEE 522 and requiring a 3.5 per unit surge withstand capability. This is a requirement that should be recognized at an early stage so that it can be addressed in pricing, design, implementation and test. Other examples might be as simple as paint color or delivery time.
2. Requirements not stated by the customer, but necessary for the specified or intended use, when known. For example, if a customer sends in an inverter duty motor for rewind, the customer’s purchase order should not need to specify use of inverter duty magnet wire, insulated bearings, etc. The service center should have established methods for repairing inverter duty motors if that is within their scope of services. And, the service center should ask pertinent questions about the installation and application before proceeding to best serve the customer.
3. Requirements specified by the service center. Most service centers have standard processing requirements. The source of the requirements could stem from a variety of areas including experience, perceived industry best practices, or accreditation to a standard. Though independent from other requirements, reviews should always look for conflicting requirements from all parties. 
4. Statutory and regulatory requirements applicable to the products and services. Depending on the work performed and application of the machine, many different statutory or regulatory requirements could be applicable. Many times, the customer will pass down requirements related to the application in procurement documents. However, other times, the service center must be aware of requirements related to the scope of work. For example, a particular service job may require a confined space entry program to comply with the U.S. OSHA regulations and the customer may not be aware of this requirement. Another example might be compliance with National Electrical Code (NEC) or NFPA 70 which is regionally adoptable and this could relate to the motor feeder circuit, grounding or something like a hazardous location where the motor may be UL listed.
5. Contract or order requirements differing from those previously expressed. The service center should ensure that contract or order requirements differing from those previously expressed are resolved. An example of this is a purchase order requirement that is different from or in conflict with requirements in the original request for quote. 
   When the customer does not provide a documented statement of their requirements, have the customer confirm requirements before acceptance. Most service centers are familiar with the order where a customer calls up and just says, “come get my motor and fix it.” While this is simple in giving the service center a lot of latitude in the repair processes to be employed, there can be a significant risk for conflict at the time of delivery (and payment) due to disagreement in work scope after the fact. Simply communicating a templated repair scope before proceeding and asking for customer approval can mitigate risk.

Retain documented information on the results of the review and on any new requirements for the service center’s products and services. The extent of and level of details in these records will vary widely from service center to service center.

Changes to requirements for products and services
The service center should ensure that relevant documented information is amended and that relevant persons are made aware of the changed requirements when the requirements for products and services are changed.

Tools for managing technical requirements
There are many tools and methods out there for requirements management. Service centers with a mature quality assurance program may be very proficient at this and may have software tools, document control tools, etc. that streamline and error-proof the process. Other service centers may rarely deal with customers that supply large, cumbersome specifications and this can be a challenge, especially when a few individuals must manage several different functional areas. 

One tool that may be helpful is a “Requirements Traceability Matrix” (RTM). It’s a tool heavily used in software development and complex projects management because those projects are notorious for having lots of requirements and lots of changes. If your service center has a gap in this area or has struggled with managing requirements, a simple traceability document can be worthwhile. A sample RTM is shown below.

There is no set format that must be followed but let’s discuss briefly what the columns shown in the sample could be used for.

• ID: An ID field of some sort is usually created just to give each requirement a unique identifier. Sometimes, they are simply numbered 1,2, etc. while other times more sophisticated identifiers are used. For example, if a service center had a code associated with each department,  e.g. M for mechanical and E for electrical, requirements might be prefixed with an M or E to segregate them.
• Requirement: The Requirement field should have sufficient information such that anyone reading the document could understand it and its source. For example, if a customer’s specification for a 4000V rewind has a document number SPEC-01 Rev 3 and in section 5.2 of that document, there is a requirement that the ground insulation stress cannot exceed 65 volts/mil, then the requirement field may contain text similar to “SPEC-01 Rev 3, 5.2, ground insulation stress cannot exceed 65 volts/mil.”
• Status: A Status field, if used, might have a choice of available options such as Proposed, Approved, Rejected, Implemented, Verified or any other term that works for the organization using the document. For example, going back to the ground insulation stress, it might be that once Approved, a data sheet and Request for Quotation (RFQ) can go out to the coil manufacturer and the status could change to Verified once a build sheet is produced and a sample coil checked. In another example, many machine owners who produce bulky motor repair specifications are guilty of an umbrella statement like “repair must be in accordance with all applicable IEEE standards.” Proper handling of this requirement would be to use a Rejected status that results in an exception to the spec or request for clarification being transmitted to the customer. However, if a similar statement is required that names a specific document or section of a document, it becomes manageable. For example, if a spec requires compliance with ANSI/EASA AR100-2015, a service center may be able to quickly determine any issues based on the framework or basis of their normal practices.
• Other fields: Fields like Implemented, Tested and Verified can be used as a control mechanism to track a requirement through those stages. The information placed in the field can vary depending on the organization using it. For example, let’s say a service center is installing a motor and PLC (programmable logic controller) in a conveyor application. There could be a separate requirement to start the conveyor when a start button is pressed and stop the conveyor when a stop button is pressed. These requirements may be considered implemented when the ladder logic is written and the PLC is programmed. Then, the program may be tested in different scenarios to make sure it works before running it in the application. Last, the implementation would be verified during commissioning. Depending on the nature of the requirement, these fields may contain initials/dates or references to documents such as test plans or test records. 

Summary
At the end of the day, delivering excellent quality can be explained simply as the fulfillment of requirements. For this reason, management of those requirements is essential. Where we often get into trouble is when requirements are ambiguous, not communicated down the supply chain, overlooked or just not identified. 

Most successful organizations rank in order of importance safety, quality, delivery and cost, and each of these will have certain requirements for every order. They may look much different for two service centers that provide excellent quality but serve different customer bases. When we pause to plan our activities properly, the customer will receive a better product, most likely in a more cost effective and timely manner. 

AVAILABLE IN SPANISH

Categories: Miscellaneous

Tags: Job requirements Quality

Rate this article:

No rating

Print