Oracle Quality

Companies today operate in global markets that demand near–zero defect quality. High quality is required not just in production, but throughout the supply chain. ISO 9000 certification is a minimum requirement. To remain competitive, companies must respond to the pressures of reducing their costs while improving quality and customer service.

To address these challenges, most companies have implemented quality programs based on the principles and methodologies developed by Drs. Deming and Juran. Such programs have likely evolved over the years starting with the implementation of statistical process control (SPC); the adoption of zero–defect and continuous improvement programs; the acceptance of the total quality control (TQC) process, and a shift to the total quality management (TQM) approach.

Many companies have widespread quality requirements and consequently may have implemented several quality systems to address these requirements. Although these systems may represent a significant investment in quality processes, training, and software, users are often dissatisfied with them for a variety of reasons.

Oracle Quality Mission
The Oracle Quality mission, simply stated, is to complement and/or replace these divergent systems with an integrated, enterprise wide, flexible solution that meets your diverse quality needs. Oracle Quality is integrated with the Oracle Applications product suite to provide unified quality data definition, data collection, and data management throughout your enterprise and across your supply and distribution networks.

Oracle Quality’s flexible architecture can support a wide variety of business models and can change as rapidly as business demands. The word complement is important here. Remember that many companies have invested quite a lot in data collection systems, automatic test equipment, statistical analysis tools, etc. Our goal is to make Oracle Quality an open system with a data repository into which you can import data from existing data collection systems and out of which you can export the quality results you have collected.

ISO 9000
Oracle Quality lets you collect your company’s quality information and procedures to make ISO certification faster, simpler and more effective. ISO 9000 is not industry specific and is not an evaluation of a specific product or service.

It’s an evaluation of the consistency in execution and maintenance of internal operation procedures that directly affect a company’s ability to produce high quality products and services. ISO 9000 requires that you fully document your business processes that ensure high quality product and service. You must then prove that you do what you’ve documented.
Oracle Quality helps you document and track product and process defects, non–conformances problems, and general quality issues. You can determine what quality data to collect, track, and report using user–definable collection plans. For example, you can collect quantitative information, such as defective quantities or measurements, or qualitative information, such as critical test results and defect cause codes. You can document what defects occurred, what you did with the nonconforming material, and what corrective action you took. In addition, you can attach your ISO 9000 documentation and standard operating procedures to your collection plans so that users can access these documents on–line while they’re collecting quality data.

Total Quality Management
By making quality data collection a part of your standard workflow, you can distribute quality assurance responsibilities throughout your enterprise.

The most effective quality management system is one in which people in each functional area are able to define the critical quality data to collect, to take responsibility for collecting this data, and to produce meaningful output to track progress towards their quality goals.

Oracle Quality is a enterprise–wide repository for gathering and storing quality information. It helps enforce quality control and maximizes your quality tracking efficiency by integrating directly with Oracle Applications data and transactions.Oracle Quality accommodates dynamic business needs by letting you control when and where to collect data in your supply chain. Oracle Quality’s flexible architecture easily adapts to support your ever–changing TQM requirements.
 

Quality Process Flow Diagram

Collection Elements

Collection elements are the basic building blocks of collection plans, which are the data structures that you use to collect Quality results.

Before you can collect Quality data, you must first create a collection plan. You begin by creating collection elements, which define the characteristics of the product or process that you want to monitor, record, and analyze. In general, collection elements:

• Identify the object that you are collecting information about; for example, a unique lot or serial number.
• Provide reference information about the quality collection; for example, the operation sequence from Oracle Bills of Material, the purchase order number, or the transaction date.
• Provide cross–reference information for analysis; for example, supplier, customer, or department.
•  Represent a quality characteristic; for example, voltage, viscosity, defect code, or symptom.

1. When you define collection elements, you are creating data fields that you can use in collection plans to collect quality results. Once you create a collection element, it becomes available as a selection on a list of values that you can choose from when you set up collection plans. You can create an unlimited number of your own collection elements (which are referred to user–defined collection elements), or you can use any of Oracle Quality’s predefined collection elements in your collection plans. You also can create collection elements by copying them from one collection plan into another.

2. Collection elements are generic until you use them in collection plans. Whenever you use collection elements in collection plans, they are associated with the plans and thereafter are referred to as “collection plan elements.” Collection plan elements can have different actions, specifications, or values that make their use specific to that collection plan.

For example, you can define a collection element called Color that has the values red, yellow, and blue, then use it in a collection plan where you assign it all of these values and also assign it additional values, such as orange, and green. The next time you use Color in a collection plan, you can choose whether to use the Color collection element that has the values red, yellow, blue, or copy in the Color collection plan element, which has the values red, yellow, blue, green and orange.

 

Collection Element Types

Collection elements are categorized by type so that they can be sorted and grouped in database searches and on reports. You assign collection element types to collection elements when you define them. Thus, you must first set up collection element types before you create collection elements.

You can create your own collection element types and add them to collection plans, or you can use any of Quality’s predefined collection element types. If you create your own collection element types, you must define them before you define collection elements.


Defining Collection Element Types
You must assign a collection element type to each collection element that you define. You can use the following procedure to create your own collection element types or you can use one of Quality’s three predefined types: attribute, variable, and reference information.

Predefined Collection Elements

To save you time and to automate data entry, Oracle Quality provides you with several predefined collection elements that are available on a list of values when you set up collection plans. If you are collecting quality data during  transactions, and your collection plan uses predefined collection elements that also are on the parent form, their values are automatically entered for you.  Otherwise, you enter their values manually.



Reference Information and Context Collection Elements
In most collection plans, it is necessary to have some collection elements that simply provide basic background or reference information for the plan, such as Department, Item, or Date. These collection elements are referred to as reference information collection elements.

When you perform transactions in Oracle Flow Manufacturing, Inventory, Purchasing, Service, or Work in Process, the values for any related reference information collection elements are automatically entered in the collection plan, if they are available on the parent form. Because the values for these collection elements are derived from within the context of the transaction, they also are considered context collection elements. All context elements are reference  information collection elements, and can be used as triggers for collecting quality data during transactions.

If you are manually entering quality results data for reference information or context collection elements (and not in the context of a transaction), you must select their values from a list of values. For example: you are performing a Move Transaction in Work in Process, and are using a collection plan that contains Job, Item, and Defect Code reference information collection elements. The Job number and Item number are also on the parent form, thus they are automatically entered as you perform the transaction. Defect Code, however, although predefined, is not on the parent form, thus you must enter it manually by selecting it from the list of values.

The following Context and Reference Information collection elements are predefined for the following Oracle Applications:

Defining Collection Elements

You can define an unlimited number of collection elements, which you can then add to collection plans to determine what quality results data will be collected and tracked. You can add, change, and delete collection elements as your requirements change. You also can customize your collection elements by:

• Defining collection element values.
• Defining specification limits.
• Defining action rules and quality actions.

 

Defining Collection Element Specification Limits

Specification limits establish the acceptable values and tolerances for collection elements. You can set specification limits for collection elements of any collection element or datatype; however, they normally are associated with variable collection elements that represent numeric measurements such as length, weight, and temperature. Specification limits include a target value (the preferred value) and three sets of upper and lower range limits, which can be changed without
restriction.

You create specification elements by adding collection elements to your specifications. Collection element specification limits are defaulted to these specification elements. For example, if you create a specification element by adding the Frequency collection element to a specification, the target value of 2000, and lower and upper user–defined, specification, and reasonable range limits — 1800–2200, 1720–2080, and 1600–2400 respectively — are defaulted to the specification element.

Attention: If you are defining specification limits for numeric collection elements, the decimal precision of the collection element controls the decimal precision of the specification limits. For example, if the decimal precision of the collection element is 3, you can define specification limits of up to 3 decimal places such as 3.999.

 

Quality Actions

When you define a collection element, you can specify that Oracle Quality initiates an action based on the quality data that you collect. You can have Quality issue alerts and electronic notifications, launch workflows created in Oracle Workflow, as well as place jobs, repetitive schedules, items, suppliers, and purchase order lines on hold. For example, if a test result on a critical component is entered as ”Failed,” you can have Oracle Quality automatically send an electronic mail notification to the responsible person(s).

The condition that you specify and the resulting action comprise what is called an Action Rule. Action rules are evaluated and executed during the quality data collection process. When an action rule is found to be true, the action associated with it is invoked. You can define the same actions and action rules for both collection elements and collection plan elements, with the exception of the Assign a Value action, which can only be defined for collection plan elements. You also can copy Actions and Action Rules to other collection plan elements.

Quality Actions are defined in the following process:

• Define the Action Rule(s) that determine when an action is invoked 
• Specify the action(s) that the Action Rule invokes when found to be true
• Define any Action Detail(s) that may be required, such as message text or operation numbers
• Specify the evaluation Sequence that must be followed to determine whether an Action is invoked

Collection Element Values

When you create collection elements, you define a list of values for them that users must select from when they enter quality results. This ensures that valid values are entered in fields (to ease data entry, enter a short code for the value when you define it).

When you use a collection element in a collection plan, however, the values are not copied into the plan, and you therefore must reassign some or all of them to the collection plan element, or create new values for it. This enables you to control how collection elements are used within collection plans.

For example: you could create a collection element called Color and define a list of values for it that includes the values red, yellow, and blue. You then have the option to use the Color collection element in a collection plan with all of its values assigned, in a second collection plan with only its red value assigned, in yet another collection plan with only its yellow and blue values assigned.

 

Defining values for collection elements ensures valid quality data entry since the user can only select a value from the list that you define. For example, if your list of values for a Pass_Fail collection element only contains the values Pass and Fail; these are the only values that appear on the list of values when users collect quality results. Thus no other results values can be collected.

Collection elements with defined values also give you greater flexibility in creating collection plans, since you can choose which values you want to assign to the collection element when it is used in a collection plan.

Quality Specifications

Specifications define the requirements to which the product must conform. You can define specifications for the key characteristics of the products that you produce or for the materials that you receive from suppliers.

You can attach illustrative or explanatory files to specifications, such as text, images, word processing documents, spreadsheets, video, and so on. Attachments can be used to document processing instructions as well as inspection and disposition procedures.



Uses of Specifications
Specifications and their specification elements make it possible to do the following:

• Prohibit the collection of data that lies outside the reasonable range of a specification element. Input that falls outside the reasonable limit range is rejected.
• Assist operators as they enter data. You can optionally display specification element specification limits as quality results are directly entered. You can choose to hide specification limits by setting the QA:Blind Entry profile option to Blind Entry On. Also, you can specify that the target value be automatically defaultedin when quality results are entered by setting the QA:Default Specification Target profile option to Yes. 
• Use specification limit values to define action rules and the actions they invoke. Action rules control when and how to react to the entry of off–specification quality results. For example, you can define an action rule that invokes an action, such as sending an electronic mail message, when a quality results value is outside the upper and lower range limits of a specification element.

Specification Types
Quality supports three types of specifications: item, supplier, or customer. The specification type that you can select is determined by your business application. For example, Item specifications can be used to define requirements for items without regard to the customer or supplier that may purchase or sell them. Conversely, customer and supplier specifications can be used to define the requirements for items sold to or purchased from specific customers or vendors respectively.

The following table presents the three supported specification types.


Specification Subtypes
Quality also supports specification subtypes. Specification subtypes are used to create more detailed specifications. For example, if a similar, yet different supplier specification is required when a supplier ships from one location to another, you can use a specification subtype to ensure that the correct specification is applied.

 

Specification Collection Elements

Specification elements are the basic components of a specification. They can be any data type, but typically, they are numeric.

You create specification elements by first defining them as collection elements in the Collection elements window, and then adding the collection elements to your specifications. Adding the collection elements to your specification causes them to become specification elements. You also can create specification elements by copying them from an existing specification into a new specification. This is useful when similar items, suppliers, or customers require the same specification elements.

As you create specification elements, any limits that have been assigned to them are defaulted from the source. Limits to specifications can include an acceptable target value as well as user–defined, reasonable, and range limits. The specification limits for a specification element can be updated as required.

Examples of specification elements and their associated limits are presented in the following table.