4 Concepts and Terms in Agile PLM Solutions

This chapter describes Agile objects and other important concepts in Agile PLM.

4.1 Introducing Agile Objects

In the Agile PLM system, you work with objects. Examples of objects are parts, documents, RFQs, and change orders.

The objects you can view and the actions you can perform are determined by the server components installed on the Agile PLM Application Server and the roles and privileges you are granted to access those components. Privileges can vary from field to field. If you have questions about your roles and privileges, contact your Agile administrator.

4.1.1 How Objects Appear

When you open an object, it appears with multiple tabs. Different types of objects have different tabs. Each tab contains fields that provide information about that object. For example, a part's Title Block tab includes Number, Part Category, and Description fields, and a change's Cover Page tab includes Originator, Status, and Reason For Change fields.

Some tabs have fields and tables where you enter data; some fields and tables are filled in automatically. Some objects and commonly found tabs are mentioned in the platform-specific discussions later in this chapter. For more information about objects and their tabs, see Chapter 5, "Working with Business Objects in Web Client" or Chapter 6, "Working with Business Objects in Java Client."

Below are a typical object page in Web Client and the same object window in Java Client.

Figure 4-1 Agile object page, Web Client

Figure 4-2 Agile object window, Java Client

4.1.2 Agile Object Types

Business objects that you create in Agile PLM are based on a framework of object types: base class, class, and subclass. The base class object type is a framework for classes; the class object type is a framework for subclasses. Each class has at least one default subclass; the subclass level is where you create specific objects. Every object created in Agile PLM (by users or administrators) is an instance of an existing subclass. (Base classes and classes are never objects themselves.)

The Agile PLM provides some three dozen default classes of business objects. The default classes of objects that your company can avail depend on which Agile products and licenses have been purchased. The Agile administrator—that is, any user who has been assigned the Administrator privilege mask or role—can create subclasses according to the needs of the enterprise; the administrator can also rename the existing (preconfigured) base classes, classes, and subclasses. You may find that even a relatively new Agile PLM installation has objects that have been created with names that are not reflected in this manual, for example, in the next three tables that describe the object types.

The classes represent either a kind of action (business process) or kind of entity (business object). Everything that a user can create in Agile PLM—object or process—is treated as an object, and, again, each object is a specific instance of a subclass. The child subclass inherits the attribute settings of the parent class; where applicable, it inherits lifecycle phase and process extension. Tabs—tab names and tab visibility—are inherited from the parent class, but only if these are set at the class level; even preconfigured subclasses with the same parent class can differ slightly from their "siblings" because of tabs that the administrator has hidden or given different names.

This table summarizes Agile's hierarchy of object types. As an Agile user, you do not need to know much about base classes and classes, but it is helpful to have an idea of the hierarchy and naming behind the subclasses you will be working with. "Items" and "changes" are examples of frequently used base class names.

Table 4-1 Hierarchy of Agile object types

Object type	This type inherits...	Rename, Create, or Delete	Installed examples	Notes
Base Class	Does not inherit; is the highest level of object type that user sees (for example, in searches).	Administrator can rename base classes, but cannot create or delete any base class.	Users base class Items base class Changes base class Suppliers base class	n/a
Class	...general properties and process extensions of its parent base class.	Administrator can rename classes, but cannot create or delete any class.	Users class Parts class and Documents class Change Orders class, Change Requests class, Site Change Orders class, and so on Suppliers class	The class object type (sometimes called main class) is the primary level of organization in Agile PLM. Each class represents a specific process or kind of entity (see "Routable and Nonroutable Objects").
Subclass	...all components (tabs), properties, and attributes of its parent class. Subclasses arrange the information & data that describes the specific object in the Agile PLM.	Administrator can create and rename subclasses, and also delete any subclasses that have not been used by Agile users.	User Part, Document ECO, ECR, SCO, and so on Broker, Distributor, Component Mfr., Contract Mfr., and Mfr. Representative	When users create a new object in Agile, they specify one of the Agile-supplied subclasses or a subclass that the administrator has created (or renamed) per your company's requirements. Subclass names cannot be used more than once within an Agile PLM system. A few classes offer multiple preconfigured subclasses.

The object type plays a part in user access and permissions. For example, you can restrict a user's privilege to the Changes base class, the Change Orders class, or the ECO subclass (or another, user-defined subclass of Change Orders class).

4.2 Installed Agile Classes, Base Classes, and Subclasses

The following tables list all the possible installed object types in Agile PLM. Classes are grouped by being routable or nonroutable, which is discussed further on. This section also discusses the following topics:

• "Discovery and Read Privileges."

• "Routable and Nonroutable Objects."

The following tables list all the possible installed object types in Agile PLM, grouped by the routable and nonroutable distinction. Your company may have purchased server licenses to a subset of this list. A class appears grayed out in the administrator's list of classes if your company has not purchased its server license.

Your Agile administrator may have created or renamed subclasses. The Agile administrator defines new objects by creating subclass objects under each object class. For example, under the Deviations class, you could see new subclasses such as "MechDev," "SWDev," and "Part Switch" in addition to the default subclass, Deviation.

Installed Routable Object Types

The following tables list all the possible installed routable object types in Agile PLM.

Routable objects – the means to direct or recommend changes to nonroutable objects; these classes have a default workflow for changes to seek approval from other users; objects from these classes can be changed without approval.

Routable object base classes are:

• Changes

• Declarations

• Packages

• Product Service Requests

• Projects

• Quality Change Requests

• Transfer Orders

Table 4-2 Changes base class routable objects

Class	Subclass	Description
Change Orders	ECO	Directives to change an item; can advance the revision ("rev") of an item
Change Requests	ECR	Requests for a change to an item
Deviations	Deviation	Directives to temporarily substitute one item for another
Manufacturer Orders	MCO	Changes to AML data, such as information about manufacturers or manufacturer part numbers
Price Change Orders	PCO	Directives to change a published price; can advance the revision of a published price
Site Change Orders	SCO	Changes to BOM and AML information for a specific site
Stop Ships	Stop Ship	Directives to stop shipping/using an item

Table 4-3 Declaration base class routable objects

Class	Subclass	Description
Substance Declarations	Substance Declaration	Seeks compliance information for each substance within the specification
Part Declarations	Part Declaration	Seeks part-level compliance information and other composition header-level information (manufacturing parameters)
JGPSSI Declarations	JGPSSI Declaration	Seeks compliance information (weights) according to the JGP standard.
Homogeneous Material Declarations	Homogeneous Material Declaration	Seeks complete breakdown of parts on the Bill Of Substances and compliance information at the homogeneous material level
Supplier Declarations of Conformance	Supplier Declaration of Conformance	Seeks compliance with specifications from customers and government agencies
IPC 1752-1 Declarations	IPC 1752-1 Declaration	A Joint Industry Guide (JIG) material composition declaration for electronic products
IPC 1752-2 Declarations	IPC 1752-2 Declaration	A homogeneous material composition declaration for electronic products

Table 4-4 Packages base class routable objects

Class	Subclass	Description
packages	Package	Packages of data to share with partners

Table 4-5 Product Service Requests base class routable objects

Class	Subclass	Description
Problem Reports	Problem Report	Quality incidents with items or products
Non-Conformance Reports	NCR	Quality conformance issues with items or products

Table 4-6 Projects base class routable objects

Class	Subclass	Description
Activities	Phase; Program; Project; Task	Components of project planning in Product Portfolio Management; activities are time-based objects to which resources can be assigned
Gates	DG1, DG2, DG3, DG4, DG5, DG6; Gate; Milestone	Project management milestones in Product Portfolio Management; gates identify cross-PLM deliverables of the product development process to enable executive reviews of projects

Table 4-7 Quality Change Requests base class routable objects

Class	Subclass	Description
Corrective and Preventive Actions	CAPA	Requests for corrective actions and preventive actions
Audits	Audit	Proactive reviews of business processes

Table 4-8 Transfer Orders base class routable objects

Class	Subclass	Description
Automated Transfer Orders	ATO	Transfer or publication of a product record that is automatically triggered by a workflow
Content Transfer Orders	CTO	Transfer or publication of a product record that is manually triggered

Installed Nonroutable Object Types

The following tables list all the possible installed nonroutable object types in Agile PLM.

Nonroutable Objects – objects in these classes are not routed to Agile PLM users with workflows; objects from some of these classes, however, are changed by a user submitting a workflow (from routable classes) for approval from other users.

Nonroutable object base classes are:

• Customers

• Discussions

• File Folders

• Items

• Manufacturers

• Manufacturers Parts

• Part Groups

• Prices

• Reports

• Requests for Quote

• RFQ Responses

• Sites

• Sourcing Projects

• Specifications

• Substances

• Suppliers

• Users

• User Groups

Table 4-9 Customers base class nonroutable objects

Class	Subclass	Description
customers	Customer	Clients of the company

Table 4-10 Discussions base class nonroutable objects

Class	Subclass	Description
discussions	Discussion	Informal, threaded dialogue

Table 4-11 File Folders base class nonroutable objects

Class	Subclass	Description
File folders	File Folder Markup	Objects that include files or URLs; this class includes all file folder objects except historical report file folders
Designs	Design	Objects that permit building design structures in the CAD environment

Table 4-12 Items base class nonroutable objects

Class	Subclass	Description
Documents	Document	Specifications, blueprints, manufacturing data, and so forth
Parts	Materials Subclass Model Option Class Part Recipe	Parts manufactured within the company, or provided by manufacturers or suppliers and given internal part numbers Note: The Materials Subclass and Recipe subclasses are NOT available until the Recipe & Material Workspace product is installed.

Table 4-13 Manufacturers base class nonroutable objects

Class	Subclass	Description
manufacturers	Manufacturer	Qualified manufacturers

Table 4-14 Manufacturer Parts base class nonroutable objects

Class	Subclass	Description
Manufacturer parts	Manufacturer Part	Parts provided by manufacturers

Table 4-15 Part Groups base class nonroutable objects

Class	Subclass	Description
Part groups	Commodity Part Family Item Group	Containers of other parts (items or manufacturer parts) that share such properties as mass or composition information. Note: This object was named "Commodities" in previous releases of Agile PLM.

Table 4-16 Prices base class nonroutble objects

Class	Subclass	Description
Quote Histories	Quote History	Organizes bid prices from RFQ responses; cannot be revised by a PCO (see grouping of Changes in preceding table)
Published Prices	Published Price; Contract	Organizes prices of the company's products; can be revised by a PCO (see grouping of Changes in preceding table)

Table 4-17 Reports base class nonroutable objects

Class	Subclass	Description
Standard Reports	Administrator Report; Standard Report	The ready-to-use reports for administrators (Administrator Reports) and users (Standard Reports include Products, Sourcing, Quality, Process, Personal, and Global reports)
Custom Reports	Custom Report	Reports created and used within company
External Reports	External Report	Reports created outside Agile PLM

Table 4-18 Request For Quote base class nonroutable objects

Class	Subclass	Description
Requests for quote	RFQ	Requests for quote, which are assembled from sourcing projects and sent to suppliers for formal bids

Table 4-19 RFQ Responses base class nonroutable objects

Class	Subclass	Description
RFQ responses	RFQ Response	Bids, that is, responses from suppliers to your company's RFQs

Table 4-20 Sites base class nonroutable objects

Class	Subclass	Description
Sites	Site	Manufacturing locations within the company, or closely partnered with the company

Table 4-21 Sourcing Projects base class nonroutable objects

Class	Subclass	Description
Sourcing projects	Sourcing Project	Work preparatory to creating RFQs and capability for analysis across multiple RFQs

Table 4-22 Specifications base class nonroutable objects

Class	Subclass	Description
Specifications	Specification	Lists of banned substances (or substances of concern) and their threshold values

Table 4-23 Substances base class nonroutable objects

Class	Subclass	Description
Substances	Substance	A single chemical element used in composition of items, manufacturer parts, and part families
Materials	Material	A compound chemical, a substance consisting of multiple substances
Subparts	Subpart	A subunit of a component, used to get to the homogeneous material level to collect compliance information
Substance Groups	Substance Group	A group of multiple substances, with a base substance that is what legislation is interested in, for example, "Lead and Lead Compounds"

Table 4-24 Suppliers base class nonroutable objects

Class	Subclass	Description
Suppliers	Broker Component Mfr Contract Mfr Distributor Mfr. Representative	Qualified suppliers of manufacturer parts; used by PCM (which uses the ready-to-use subclasses) and PG&C solutions

Table 4-25 Users base class nonroutable objects

Class	Subclass	Description
Users	User	Individuals using the Agile PLM system

Table 4-26 User Groups base class nonroutable objects

Class	Subclass	Description
User groups	User Group	Groups of people using the Agile PLM system, that is, departments, teams, site-specific groups.
Functional Teams	Functional Team	Groups of people that comprise a functional team; each member is assigned a workplace job function.

4.2.1 Discovery and Read Privileges

Together, the Discovery privilege, the Read privilege, and the Enforce Field Level Read privilege determine which Agile objects you can find and open, and which object fields you can view.

The Discovery privilege lets you discover the existence of an object in the Agile database. If you do not have Discovery privilege for an object, you cannot view the object, and you cannot find, or discover, the object in the Agile database. This includes viewing users in the address book; there may be some users that you cannot view due to lack of privileges.

Once you have the privilege to discover an object, your Read and Enforce Field Level Read privileges for that object determine whether you can open and view it, and which individual fields you can view. You may be able to read an object, but you may not have Read privilege for every field of that object. So it is possible for you to open an object and, at the same time, be unable to view specific fields of that object. For more information about the Discovery and Read privileges, see the Agile PLM Administrator Guide.

4.2.2 Routable and Nonroutable Objects

Each class represents a specific process or kind of entity:

• Routable objects are created from classes that represent processes, such as a change in the change control process, or a transfer order, or a product service request. These objects can be routed to Agile users for approval or other input through workflows (see "Workflows.").

• Nonroutable objects are created from classes that represent entities or things, such as parts, sites, RFQs, users, prices, or reports. These objects can be "flagged" for progress through lifecycle phases. Note, however, that nonroutable objects—especially parts and documents—can be changed by the process of information-gathering by using workflows, which are created through such routable objects as change orders or change requests.

Note: File folder objects have lifecycle phases and, as they represent the entity of "attachment wrapper," are not considered routable objects; however, the File Folders class has a default, non-editable workflow with a single Review status (and no other status), which provides a Routing Slip tab where approvers can sign off and comment.

4.2.2.1 Routing Managers

Any object that can be routed for approval is a routable object. The user who oversees the routing and approval process is the routing manager. The various routing managers (see the table below) are simply roles assigned to users by the administrator. Once a user has been assigned a role of, say, change analyst, his name appears on the Change Analyst List and can be selected manually by a Java Client or Web Client user with the appropriate Modify privilege. If the workflow specifies a Default Change Analyst, then the Change Analyst field is automatically populated by the workflow.

Routing managers evaluate and assign routable objects, and they receive email notifications pertaining to the objects to which they are assigned.

The following table lists routable objects and the corresponding default routing manager.

Table 4-27 Routable objects and corresponding routing managers

Routable Object (with base class)	Default Routing Manager
Changes base class: Change orders (ECOs), Change Requests (ECRs), Stop Ships, Deviations, Site Change Orders (SCOs)	Change analyst
Changes base class: Manufacturer Orders (MCOs)	Component Engineer
Changes base class: Price Change Orders (PCOs)	Price administrator
Declarations base class: Part Declarations, Substance Declarations, Homogeneous Material Declarations, JGPSSI Declarations, Supplier Declarations of Conformance	Compliance manager
Packages base class: Packages	Program manager
Product Service Requests base class (PSRs): Problem Reports and Non-Conformance Reports (NCRs)	Quality analyst
Programs base class: Activities and Gates	PE program manager
Quality Change Request base class (QCRs): Corrective and Preventive Actions (CAPAs) and Audits	Quality administrator
Transfer Orders base class: Content Transfer Orders (CTOs) and Automated Transfer Orders (ATOs)	Content manager

4.3 Other Important Concepts in Agile

Familiarity with the topics discussed in this section will help you use the full features of Agile.

4.3.1 Login Security and Passwords

Depending on how your Agile administrator has configured your password settings, you may have two separate passwords for login and approval, or you may have one password for both login and approval.

Your username and approval passwords are the same for both Java Client and Web Client.

For system security, your administrator may configure the Agile PLM system so that you are not allowed to log in after a specified number of password failures (entering the wrong password). The lockout applies to your login password only, not your approval password.

Depending on Agile PLM system settings, one of the following occurs:

• The login lockout lasts until a specified time has passed (for example, one minute).

  After the specified time has passed, a small Login dialog box appears, telling you that there have been too many login failures. Click OK and continue.

• The login lockout lasts until your Agile administrator unlocks your account by changing your password. If you are locked out, Web Client does not accept further input for the time period specified by the Agile administrator (for example, one minute), before you can attempt to log in again.

If you are having difficulty logging in to Agile PLM, or had a failed logon and the lockout is lasting too long, see your Agile administrator.

4.3.2 Object Subscriptions, Relationships, and Sharing

"Sharing," "subscriptions," and "relationships" all describe operations with objects in Agile PLM that provide better collaboration and enhanced automation as they proceed through the manufacturing process. These features are detailed in Chapter 5, "Working with Business Objects in Web Client" or Chapter 6, "Working with Business Objects in Java Client."

• Object sharing – Lets you grant one or more of your roles to another Agile user for specific objects and specific classes listed in object tabs.

• Object subscription – You can subscribe to objects so that you are notified when certain events happen to that object. For example, you can subscribe to a change to be notified whenever the change is promoted to a new status.

• Object-to-object relationships – Lets you set up communication between Agile objects, and the actions resulting from (triggered by) that communication. For example, the implementation of an ECO could trigger the close of a related ECR.

4.3.3 File Folder Objects and Attachment Files

Attachments to objects may contain information about the object or a manufacturing process. You can attach files and URLs by referencing them in a file folder object. There are two primary types of File Folders, regular File folders and Designs. The file folder holds pertinent content, or attachments. Design objects contain objects used for CAD integration.

In previous versions of Agile, files and URLs that are attached—associated—to parts or other business objects are called attachments. In this version of Agile, attachment files and URLs may be referred to generally as attachments, but it is important to remember that what is really attached to Agile business objects are file folders.

You can still view, copy, delete, and print attachment files. With appropriate roles and privileges, you can markup or redline an attachment file in the Viewer. See "Viewing and Redlining Attachment Files in the AutoVue for Agile Viewer."

The Attachments tab of an Agile object lists attached file folders. The Files tab of a file folder object lists the files and URLs that are referenced, and it is where you add and remove files and URLs in the file folder. A file folder's Where Used tab is populated automatically with any objects that have a link to the file folder. A single file folder object can be referenced from the Attachments tab of multiple objects.

For more information, see Working with Attachments. For details about searching attachment content, see "Full Text Search for Content in Attachment Files." Also see the Viewer Supplement.

4.3.4 Searching for Data

When you want to find data in the Agile PLM system, you perform a search. Agile PLM provides several types of searches:

• Simple searches find objects of all types that match the text you specify.

• Quick searches find objects that match two basic conditions: the text and the object type that you specify. They also have the ability to search attachment file content.

• Advanced object searches find all the objects with fields that match the conditions of the search. For example, you could search for parts where the Description field contains "Computer."

• Where-used searches (a specific type of advanced search) find the assemblies in which the BOM contains the items that match the search criteria.

• Relationship searches (a specific type of advanced search) find objects related to the objects that meet the search criteria. For example, you can search for the problem reports that appear on the Relationships tab of changes that meet search criteria.

• Attachment content searches find attachment objects that contain attachment files including the text specified in the search conditions.

For instructions about searching, see Chapter 8, "Finding Agile Data with Searches."

4.3.5 Agile Packages

Agile packages are sets of product information that can be created, viewed, and routed through Agile PLM to users up and down the supply chain.

For example, suppose an Electronic Manufacturer Service (EMS) provider must receive a certain set of documents to respond to a request for quotation from an Original Equipment Manufacturer (OEM). The EMS defines the required documents in Java Client or Web Client. OEM employees then log in to Web Client, where they create Agile packages and are prompted to attach the required files. The Agile packages are submitted to the program manager at the EMS.

The EMS is immediately notified when the OEM submits the packages. The EMS can review the packages and their contents. The packages pass through workflow stages in Agile PLM, where they are routed for review, accepted, or returned to the submitting partner if additional work is needed.

OEM personnel can monitor all this activity anytime they log in to Web Client for that EMS provider. The OEM can also use Agile Content Service (ACS) to automatically create and populate the Agile package in the Agile PLM system of the EMS.

4.3.6 Exporting Data

Users at Agile sites can export product definition data to a file. Export files can be comma-delimited text format (CSV) or Product Definition eXchange (PDX) format.

PDX is the Product Definition eXchange standard designed for the e-supply chain. The standard is based on XML because it provides a simple yet powerful and flexible way to encode structured data into a format that is both human- and computer-readable. The PDX standard provides a way to describe product content (BOMs, AMLs, drawings, and so on), ECRs, ECOs, and deviations in an XML format.

In a typical case, an OEM with Agile has a design to communicate to an EMS, also called contract electronics manufacturer (CEM), who builds the component or assembly. The product data might include items, BOMs, approved manufacturer lists, drawings, and so on. When a design changes, the manufacturer needs to communicate the changes to the EMS. The Export wizard can create a text file or PDX package of this information from the Agile database to be sent to the EMS.

At the receiving end, the EMS then views that data (in Agile eXpress, if the file is a PDX package) and prints it or extracts it as needed for use in spreadsheets or other applications. The EMS can use Agile Import to import the PDX package or text file into the Agile database.

Agile Import and Export are documented in the Agile PLM Import/Export Guide.

For more information about the PDX standard, visit the PDX organization website at http://webstds.ipc.org/2571/2571.htm.

4.4 Product Collaboration Process

The Agile Product Collaboration (PC) solution helps supply chain partners define, store, change, and manage product content information. The PC solution is central to Agile PLM, and most Agile users will need to be familiar with BOMs, AMLs, and the change control process.

4.4.1 Bills of Material

Bills of material (BOMs) show all the items (parts, documents) that comprise the current part or subassembly. (Documents may or may not have bills of material, depending on your Agile PLM system settings.) Items on a BOM can be a single item or an assembly of several items. The BOM for each part appears on its BOM tab.

4.4.2 Approved Manufacturer Lists

An approved manufacturers list (AML) is the list of manufacturers that have been approved to supply a particular item. The list identifies the manufacturer part for that item. The AML for a part, plus the manufacturer's part numbers and other information, appears on its Manufacturers tab.

4.4.3 Change Control Process

The change control process includes all procedures that manage changes or requests for change to any part, document, step, or instruction in your company's manufacturing process.

4.4.3.1 Objects and Change Control

Items are subject to change control, that is, modification by an approved and released change order. To modify an item's BOM or Manufacturers tab, you must create a change against the item.

The Title Block and Sites tabs of items are not under change control; this means, with the appropriate privileges, you can edit them at any time. Site objects and manufacturers are also not under change control.

4.4.3.2 Affected Items

The Affected Items tab of a change lists the items that are affected by the change. Users with sufficient privileges can use the Affected Items tab to:

• List the items affected by the change, and assign a pending revision (or rev) to the affected items of the ECO

• Open the affected items

• Work with BOM, manufacturer, and attachment redlines

4.4.3.3 Redlining BOMs, Manufacturers, and Attachment Files

When you redline a BOM, you change it in some ways. For example, you can add or delete parts and assemblies from the BOM or change quantities of existing parts. Likewise, when you redline an AML, you can change associated manufacturer parts information. When you redline an attachment file, you mark it up in the Viewer by adding new drawing lines, adding annotations, or adding measurements.

Redlining activities begin on the Affected Items tab of an ECO (for BOMs, AMLs, or attachment files), SCO (for BOMs or AMLs), or MCO (for AMLs).

4.4.3.4 Workflows

A workflow is a sequence of statuses that a routable object (such as a change) follows. Workflows automate many processes; for example, when a change is released, Agile users on the notification list receive automatic email with this information.

Agile provides default workflows for routable objects, and your Agile administrator can create workflows. For each workflow made available to Agile users, the administrator specifies workflow name, ID number, names of the statuses, and the properties that define each status.

Agile workflows are covered in detail in Chapter 9, "Routing Objects with Workflows."

4.4.3.5 Change Control Process

The change control process includes all procedures that manage changes or requests for change to any part, document, step, or instruction in your company's manufacturing process.

4.4.3.6 A Typical Change Control Process

Agile supports change control processes, including default and custom Agile workflows.

The following is an example of a typical change control process for a change using Agile workflows:

1. An Agile user creates a change (for example, an ECO or MCO), and then selects a workflow to route this change.

2. The user selects approvers (members of the change control board) and observers for the change and then submits it to the routing manager.

3. The routing manager switches the change to the next status, which routes the change to the specified approvers and observers.

4. The members of the change control board, or CCB, enter their approval or rejection on the Workflow tab of the change.

5. If all the approvers approve the change, it is automatically promoted to the next status (depending on the AutoPromote setting). If any approvers reject the change, the routing manager is notified. The routing manager may elect to do any of the following:

   • Cancel the change by switching the status to Canceled.

   • Return the change to the originator by switching the status to Pending.

   • Release the change despite the rejection.

The following figure illustrates this change control process. Agile packages and content transfer orders can follow a similar process.

Figure 4-3 Change control process diagram

4.5 Product Portfolio Management Process

Agile Product Portfolio Management (PPM) is a Web Client application for program management that lets you:

• Plan a program in terms of its schedules, resources, and deliverables

• Execute and manage multiple related programs and projects in a collaborative environment

• Associate product deliverables (such as Items, RFQs, ECOs, and CAPAs) to tasks on a project plan

• Establish project plan templates for rolling out best-practice processes

• Allocate work to users or resource pools and monitor capacity and future demand

• Establish executive dashboards for cross-program rollups and quick access to high risk activities

The program management process involves:

• Scheduling

• Task management

• Issue management

• Document management

• Phase/Gate management

• Resource management

• Deliverable management.

4.5.1 Common Terms in PPM

Listed below are some common terms used in PPM:

• Program: A set of related activities and gates that is created to monitor and manage progress on a specific project.

• Project: A set of phases, tasks, and gates that is created to monitor and manage progress of a specific planned activity.

• Phase: A segment of a program, also referred to as a stage. Phases are often used to define the activities required to create a set of deliverables.

• Gates: Indicates the completion of a set of related activities, such as a phase. A gate's status is closed until all its deliverables are complete, at which time it opens.

• Task: A segment of work that one or more resources can complete within a time period. Tasks may be embedded in programs, phases or other tasks.

• Deliverable: An Agile PLM object whose state change can trigger a state change in the program element that contains it. The statuses of deliverables control the status of gates.

• Gantt Chart: A program management tool that helps you to plan, administer, and track programs from start to finish.

• Content: Contains all program-related content including deliverables.

• Activity: A program, task or phase.

For more information on PPM, see Agile Product Portfolio Management User Guide.

4.6 Product Quality Tracking Process

The Agile Product Quality Management (PQM) solution consists of a comprehensive set of tools that allows companies to track and manage quality data across the enterprise. This includes customer complaints, field failures, product or manufacturing defects, and requests for enhancements or corrective and preventive actions. PQM unifies the company's organizations in customer service, field sales, manufacturing, and engineering, and links the organization to its customers and partners.

PQM features offer these benefits:

• Integration with external enterprise Customer Relations Management (CRM) systems – The ability to import customer complaints, manufacturing issues, and additional quality-related information from other enterprise applications streamlines the quality tracking process and offers a central repository for tracking product quality data.

• Improved product quality – Tracking defects, finding trends, and quickly determining the root causes of defects are the keys to effective defect reduction and improved product quality.

• Improved customer satisfaction – The ability to track problem reports and customer complaints lets you respond quickly to customers and resolve problems quickly.

• Lower production, repair costs, and warranty costs – Tracking and correcting defects can help reduce scrap, cycle time, and costs associated with rework and repair.

• New features enable compliance with ISO-9000, FDA, and other regulations.

The Agile PQM solution consists of Product Service Requests (PSRs) and Quality Change Request (QCRs). The two types of PSRs are Problem Reports and Non-Conformance Reports (NCRs). The two types of QCRs are Audits and Corrective and Preventive Actions (CAPAs). You can associate QCRs with problem reports.

4.6.1 Common Terms in PQM

Listed below are some common terms used in PQM:

• Product Service Request (PSR): You use a PSR to report a defect or a quality incident about a product. The PSR can be either a Problem Report or a Non-conformance Report.

  • Problem Report (PR): Contains a basic description of a problem, issue, or incident that occurred, from the customer's perspective.

  • Non-Conformance Report (NCR): Reports a basic material deviation from specifications or requirements in one or more products.

• Quality Change Request (QCR): Creates and manages quality records that aggregate problems related to products, documents, suppliers, and customers.

  • Audit: The pro-active process of verifying compliance with quality requirements.

  • Corrective and Preventive Action (CAPA): A formal process of addressing any quality problem and analyzing the root cause to implement corrective and preventive action.

• Related PSR: A list of all similar product service requests that are combined to form a single PSR.

• Affected Items: A list of items that are affected by the change in either a PSR or a QCR.

• Relationship tab: Creates a relationship with other Agile objects; the relationship is bi-directional.

• Relationship Rule: Specifying a rule for a relationship defines how the related Agile objects affect each other. Rules are optional; you can create a relationship between two objects without specifying a rule.

• Preview Pane: When you add a relationship to an object, the details of the Relationship are displayed in the Preview pane. It also displays the attributes and actions that can be performed on the relationship object.

For more information on PQM, see Agile Product Quality Management User Guide.

4.7 Product Cost Management Process

The Agile Product Cost Management (PCM) solution consists of the Product Sourcing and Price Management components. They allow you to integrate and leverage price and cost information within your company's business processes in the Agile Web Client.

A sourcing project holds the data you gather, such as items and assemblies, bills of material, and approved manufacturers lists. Using the project, multiple users can work as a team to complete sourcing and pricing activities, since the project lets multiple users view and modify the same components. Sourcing projects allow you to execute sourcing activities, including RFQs and analysis, on your Item Master content.

The Price Management solution provides you with a single controlled process for managing price and terms information that can be leveraged across organizations, business processes, and key analysis.

4.7.1 Common Terms in PCM

Listed below are some common terms used in PCM.

• Approved Manufacturer's List (AML): Lists all the preferred or alternate manufacturer parts that correspond to an internal part.

• Sourcing Projects: An entry point for sourcing and pricing. Tracks data required for sourcing and pricing, to perform analysis for effective pricing.

• Item Master: The entire collection of Items - Parts, Documents, and other user-defined subclasses of the Items class maintained under change control in the Agile PCM system.

• Project Items: Items added to a project. These can be items that exist in the Item Master, created within the project or imported into the project.

• Project Data: Information about the supplier, item, manufacturer, manufacturer part number, revision, price information, RFQ response information of a project.

• Subscriptions: Subscribing to an object sets you up to receive notification of events that happen to the object.

• Target Price: The price you quote for an item with the standard cost in mind. Standard cost is the market cost per unit of the item or the manufacturer part.

• Commodities: Lets you categorize parts for sourcing and analysis process. By associating each item with a commodity, you can distribute RFQs to suppliers based on the commodities they offer.

• Request for Quotes (RFQs): Using RFQs, you request quotes for items involved in the project and suppliers respond to the Quote. RFQs can be sent to one or more suppliers.

For more information on PCM, see Agile Product Cost Management User Guide.

4.8 Product Governance and Compliance Process

Agile Product Governance and Compliance (PG&C) is designed to help OEM manufacturers audit the amount of regulated substances used in their products, and show that they responsibly dispose of, recycle, or reuse electronics containing those substances.

PG&C helps companies address the growing number of environmental specifications and policies that affect product definition, the import and export of products, and the disposal of restricted substances. It provides a solution that manages the entire product compliance process:

1. Collection of data from vendors through a Request For Information (RFI)

2. Determination of compliance by analyzing data and comparing it to established standards

3. Documentation of compliance by running reports

The RFI process is initiated by Compliance Manager, who creates a new declaration, or modifies an existing declaration, to specify the components for a parts assembly. An RFI consists of a Material Declaration, which lists the parts in a product assembly and shows the substances and materials that comprise those parts. It is linked to specifications which may restrict how much of a particular substance that product assembly may contain.

4.8.1 Common Terms in PG&C

Listed below are some terms used in PG&C.

• Specification: Tracks the different legislations with which an assembly or part must comply. Environmental specifications are substance-based, and contain a list of banned substances or substances of concern and their threshold values. Agile uses specifications to validate declarations and assess the compliance of parts by evaluating whether a given restricted substance in the composition of a part surpasses its specified threshold value.

• Declaration: A structured way of bringing information concerning the environmental compliance of parts into Agile PLM. Each declaration is for a single supplier.

• Composition: A composition represents the total collection of information contained in a completed declaration and is not a configurable "business object" in Agile PLM.

• Substance: A substance is any chemical element or compound that is tracked within Agile PLM.

• Bill of Substance (BOS): A way to manage compliance information-gathering regarding the parts and materials used in the manufacturing process.

• Alias: Informs Agile PG&C of "substitute names" of substances. For example: When a supplier provides information about substances for a part, there is no guarantee that a substance with the same name exists in the buyer's system. Agile PG&C adds the invalid substance as an alias to the substance. Whenever the same invalid substance is imported, it automatically maps to the objects.

• Supplier: A supplier is a company that provides compliance information about parts that are used in your company's manufacturing process.

For further information about PG&C, see Agile Product Governance & Compliance User Guide.

4.9 Engineering Collaboration Process

Engineering Collaboration (EC) is an application that provides data and process integration between CAD applications and Agile PLM. It allows CAD designers and engineers to capture and control the data representing a primary source of the product record.

See also Chapter 13, "Working with Design File Change Orders (DFCOs)."