Introduction to Product Data Management

1
Introduction to Product Data Management
Unit 3 Leveraging Product Data Management
Nathan W. Hartman, Ed.D. Craig L. Miller,
Ph.D. Isaac Chang, Ph.D. Computer Graphics
Technology
2
Program and Project Management
3
What is Program Management?

• Program management is the process of managing a
  portfolio of multiple ongoing inter-dependent
  projects
• Hundreds, or even thousands, of separate projects
• Program Management also reflects the emphasis on
  coordinating and prioritizing resources across
  projects, departments, and entities to insure
  that resource contention is managed from a global
  focus

4
What are programs ?

• In a general scenario, this would encompass
  development and improvement of products, service,
  quality control, customer satisfaction, etc.
• Developing a new product
• Implementation of a new PDM system
• Achieving 98 record in promptness
• Objectives may entail many projects - property
  acquisition and refurbishment, staff training, IT
  support systems and so on

5
Sample Program Management Plan

• Summary -program description and major objectives
• Assumptions constraints
• Deliverables
• Work breakdown structure
• Major milestones with associated exit criteria
• Staffing training plan
• Spending/budget profile
• Project organization
• External interfaces
• Program plans list with summary description
• Product documentation tree

6
Factors in Program Management
7
A model to keep in mind.
Information is typically driven by and generated
for the customer internal and external.
8
PDM Software Applications.

• Provide the user with the capability of managing
  life cycles and setting up programs with
  milestones to help in the design and
  implementation of a product
• Lifecycle Editor As object matures, gates
  between lifecycle phases are used as trigger
  points
• Approval
• Data Integration
• Program Editor
• Create programs with milestones
• Provide timely and accurate information so
  decisions can be made.

9
Terms and definitions

• A life cycle is a series of stages through which
  an object passes from its primary state through
  its final state.
• State defines the status of a product
• Approved
• Released
• Transition/ Gate changes a state of the product
• PDM software life cycles use a predetermined
  series of states and transitions to dictate the
  evolution of a particular object

10
Lifecycle model
PDM systems manage the data that moves between
stages in the Lifecycle model. Triggers are
established within the database that correspond
to various actions within the workflow.
11
Project Management The need

• Project management (PM) is a carefully planned
  and organized effort to accomplish a specific
  (and usually) one-time effort, for example,
  construct a building or implement a new computer
  system (From Free Management Library.)
• Most people want their projects to be on time,
  meet quality objectives, and not cost more than
  the budget.
• Still, there is a big difference between carrying
  out a very simple project involving one or two
  people and one involving a complex mix of people,
  organizations and tasks.

12
Basic Elements of a project

• Resources
• People, equipment, material
• Time
• Task durations, dependencies, critical path
• Money
• Costs, contingencies, profit
• Scope
• Project size, goals, requirements

13
Product, Part, and Configuration Management
13
14
What is Product Structure Management?

• Allows the management of structures describing
  the product and the management of product data
  needed throughout the lifecycle
• Supports the whole product development process
  from the creation of requirement structures to
  the generation of bills-of-material for
  production.
• Makes use of product variant structures and/or
  bills-of-material.

15
Definition of Product Structure

• A product structure is a division of parts into a
  hierarchy of assemblies and components. An
  assembly consists of other assemblies
  (subassemblies) and/ or components. A component
  is the lowest level of the structure.
• Enables to manage hierarchical graphs such as
  those used to define bills of material or work
  breakdown structures

16
Example of a Product Structure
17
Product Class Structure

• Product Class Root
• Highest leaf in the structure and is used to
  categorize the products
• Product Classes
• Group products with similar attributes
• Levels of classes allow you to refine granularity
• Products
• Lowest leaves of Product Structure
• A Product is a saleable item

18
Product Component / Instance Structures

• Product Component Structure
• This resides under a product
• Comprises major sub-assemblies of the product
• Different levels to define granularity
• Ex Wheel, Braking, Engine, Transmission
• Instance Structure
• Actual usage of parts, sub-assemblies or other
  objects in a product
• We can instantiate a product within a product
• Multiple instances of a part can exist

19
Example of a Product Structure
20
Product structure management includes

• Defining Product classes, assemblies,
  sub-assemblies and following the hierarchy to the
  components
• Management of the development and selection of
  product variants, Identification and control of
  product configurations
• Linking of product definition data to the
  structure
• Allowance of various domain specific views of a
  product structure, such as design and
  manufacturing views
• Transfer of product structure and other data in
  both directions between PDM and MRP or ERP systems

21
Parts Management

• This objects involved are Part, Part version,
  Part Reference and Part instance

22
Components of Part definition

• Part
• A part represents the smallest, self-contained
  object that is tracked within most PDM systems
• Various states of the object are tracked within
  most PDM systems (Part Master, Part Instance,
  Part Version and Instance) depending on the
  context in which the object is placed.
• Part Master
• Common object to all versions
• Reduce redundancy

23
Components of Part definition

• Part Version
• Version a part after a modification
• Fit, form or function should not fundamentally
  change
• Part Instance
• Actual use of a part within a product structure
• Can have many instances of the same part
• Data specific is to occurrence, position and
  relationship to other part instances
• Part Reference
• Comprises part master and part version data

24
Part Instance Structure
25
Attributes

• Part Owner
• Person responsible for a given part version
• Established during creation and can be changed
  through the lifecycle
• Part Status
• Current maturity of the part version (Ex WIP,
  Design, Approved, Released)
• To which object would you attach these attributes
  ?

26
Other related concepts

• Alternate Part
• alternate part is a part with comparable
  characteristics that can be used in place of a
  current part
• automatically applied to all other instances of
  the part
• two parts are functionally interchangeable
• Constituent Part
• Second level part reference established within an
  assembly relationship

27
Other related concepts

• Assembly Part
• elementary part that facilitates the association
  of assembly relations
• established during the creation of the part and
  is stored in the part master
• Detail Part
• Elementary part that precludes the association of
  assembly relations
• Standard Part
• Bought in large quantities
• Commonly used across many manufacturing venues.

28
Configuration Management (CM) example

• Think about buying a new computer. Go to that
  companys website. Can you buy online? What
  choices do you have?
• Did you get an idea of what is a configurable
  product?
• What advantages does this company provide over
  its competitors?
• What is the output of configuration management in
  the sales scenario?
• Engineering BOM Vs. Manufacturing BOM

29
Status and composition of a product

• Effectivity
• Effectivity denotes specific conditions of
  validity for an object or an action and can be
  established by indicating a date, range,
  specification or milestone
• Range and Date
• Milestones - Why use milestones ?
• Applicability
• Applicability defines the conditions under which
  an object should be included or excluded from a
  configuration

30
Status and composition.

• Configuration
• A configuration enables you to visualize a
  variant of your product through the application
  of a configuration filter. The configuration
  filter restricts the view of the product by
  applicability set against each part instance.
• Modification
• A modification is a formal record of a change as
  defined by an action

31
Status and composition.

• Define Products features and options
• These drive various models of the product
• These are defined using specifications
• Mandatory
• Replaceable
• Available
• Specifications define the type of assembly
• Generic
• Spin-offs
• Rules
• Inclusion rules
• Exclusion rules

32
CM from a PDM point of view.

• CM provides tools needed to effectively
  communicate with disparate workgroups and
  business partners
• Instantly communicate and control engineering
  changes
• Manage different product variants and versions
• Changes drive CM
• Across different domains within an organization
  Engineering, Production, Service etc.
• Plan and control product configurations
• Support mass CTO (Configure-to-order)
  manufacturing
• High level of customization
• Several supply sources

33
CM from a PDM point of view.

• Synchronize parallel/ concurrent / collaborative
  product development
• Multi-source and multi-site manufacturing
• Reconfigure the supply chain quickly
• Optimize maintenance of varied technical assets
• Configuration Effectivity time, revision or
  number intervals
• Attribute of the relationship

34
CM from a PDM point of view.

• Perform modifications on every variant in only
  one operation
• Manage different views of the same data without
  versioning and thus avoiding duplication

35
CM Vs. Traditional approach

• Versioning each variant of the same product
• Results in data duplication and complicated
  component reuse
• Increases administrative costs
• Impedes innovation
• Modification implies repeating the operation on
  every version

36
Benefits of CM

• Increase market size through production
  innovation Virtual Product Development
  Management
• Increased market share by being in the market
  early market size
• Improvement in the Product development and
  production processes
• Improved efficiency resulting in higher margins

37
Data, Information, and Knowledge in PDM
37
38
Defining product

• What is a product?
• An artifact that has been created by someone or
  some process (WordWeb)
• Examples
• Aerospace
• Automotive
• Shipbuilding
• Industrial machinery and equipment
• Electronics and mobile equipment
• Consumer goods
• Chemical and petroleum

39
Product lifecycle data
40
Bill of materials

• What is BOM?
• What is in BOM?
• How do we create BOM?
• When and where do we need BOM?

41
KDI management

• Russell Ackoffs definition (1989)
• Data is raw. It simply exists and has no
  significance beyond its existence.
• Information is data that has been given meaning
  by way of relational connection.
• Knowledge is the appropriate collection of
  information, such that it's intent is to be
  useful. Knowledge is a deterministic process.
• We use Knowledge to convert Data into Information
  for better decision making

42
Knowledge management

• Bellinger, G., Castro, D., and Mills, A. (2004).
  Data, Information, Knowledge, Wisdom. Retrieved
  January 5, 2006, from http//www.systems-thinking
  .org/dikw/dikw.htm.

43
KDIM in PLM
44
PDM for PLM

• What kind of data should we try to manage?
• Where are we going to record and retrieve
  product-related information?
• How do we utilize knowledge?
• Can we automate the documentation process?
• The definition of product
• The data generated in a lifecycle
• Business intelligence instead of raw data

45
Interchangeability
45
46
Engineering change

• The reason for engineering change
• Product specification
• New manufacturing techniques
• Cost reduction
• Quality improvement
• Etc.

47
Adding a part
48
Value of PDM
49
The impact

• Time (change of schedule)
• Cost (total cost)
• Resource (resource to design, execute, and
  sustain the changes)
• Scope (from a lifecycle perspective)
• Design
• Planning
• Manufacturing
• Service

50
Documentation

• Design documents
• Planning documents
• Manufacturing documents
• Service documents

51
Interchangeability

• What is interchangeability?
• Of an acceptable form (appearance) to meet all
  esthetic requirements per the Product
  Specification.
• Of a proper fit (physical) to assemble with other
  mating items per the drawing dimensions and
  tolerances.
• Of a proper function to meet the Product
  Specifications including performance, safety and
  reliability requirements.
• These criteria must be met both ways (old design
  in the new and vice versa) with no special
  adjustments, modifications, or alterations, to
  the item or related items. (Your definition might
  be different in regard to adjustments, etc.)

52
More definitions

• Non-interchangeable
• Items which meet some, but not all of the above
  criteria are not completely interchangeable and
  are, therefore, considered non-interchangeable.
• Compatible
• The old item is not interchangeable in the new,
  but the new is interchangeable in the old.

53
Interchangeable parts

• Spare parts
• For re-use
• Part number
• Tracing
• Automatic rolling

54
Effectivity and Action
54
55
Product Structure User View
56
Product Component

• The whole product can be subdivided into
  functional groups called product components.
  Product components facilitate
• Navigating the product structure subsystem.
• Maintaining a link to the component while part
  instances are added to the product.
• Linking a part instance to more than one
  component.

57
Creating Product Structure
58
Effectivity

• Is a condition applied on an object that belongs
  to the configurable object.
• Defines applicability / validity of the instance.
• Is defined on the instances.
• Is stored in the configurable view.

59
Effectivity

• Effectivity can be defined in terms of the
  following
• Date range
• Number range
• Variant / specification
• Milestone range
• Combinations of the above

60
Effectivity

• Can be applied by modifying the depth and breadth
  of applicability of the change within the PDM
  system.
• Can typically be propagated from actions within
  the PDM system.
• ECO
• Metadata modification
• Can be categorized into various domains (e.g.,
  design, manufacturing).

61
Effectivity Domains

• Effectivities can be grouped into various
  domains. A part instance may have different
  effectivities for design and manufacturing. We
  can model this by establishing Effectivity
  domains within the PDM system.

62
Assigning the Effectivity Through Modifications
63
Action Definition

• Actions are the task execution vehicles in a
  product development lifecycle .
• Actions are PDM system objects that follow a
  lifecycle and carry information necessary to
  execute a task .

64
Changes in Product Development
65
The Role of Actions in PDM

• Actions in informal change management
• Define tasks
• Assign tasks
• Mature tasks
• Track changes made
• Actions in formal change management are
• Created as deliverables of an ECO or ECR
• Centrally managed from an ECO or ECR
• Assigned to an ECO as deliverables
• Actions also act as work items in work flow
  management.
• In the future, action could be managed through
  work flow or through project management.

66
Information Carried by an Action

• The kinds of information that Actions carryto
  complete a task could be categorized into the
  following
• Attached objects
• Affected objects
• Product association
• Links
• History
• Lifecycle

67
Typical Action Attributes

• Action ID
• Action Creator
• Action Owner
• Abstract
• Action Type
• Design Type
• Manufacturing Type
• Documentation

• Priority
• Status
• Planned Dates
• Actual Dates

68
Action Effectivity

• When you associate a product with an Action, the
  action requires product effectivity information.
• The system applies effectivity to allobjects
  modified by this Action.

69
Actions/CVs/Effectivity Working Model
70
Developing Action Networks

• In a real-time scenario, the changes a user
  introduces to the PDM system are made through a
  network of interdependent Actions.
• You can define interdependencies by creating
  linked Actions.
• When you link Actions, you link indirectly
  lifecycles and related objects.
• The basic types of dependency relations include
• Oriented (hierarchical) link
• Symmetric (peer-to-peer) link

71
Action Links - Symmetric

• Symmetric links are peer-to-peer links
• The above example illustrates a Detailing Action
  and an FE Analysis Action that might have to be
  completed simultaneously.

Action for Creating details
Action for FE Analysis.
72
Action Links Oriented

• Oriented links represent hierarchical or
  parent-child relationships. In the example below,
  the parent action cannot be completed until both
  child actions are complete.

73
References (background information)

• http//www.managementhelp.org/plan_dec/project/pro
  ject.htm
• http//www.mindtools.com/pages/main/newMN_PPM.htm
• http//www.managementhelp.org/prog_mng/prog_mng.ht
  m
• http//www.npd-solutions.com/configmgt.html
• http//www.npd-solutions.com/pdm.html
• http//www.plmic.com/cm-configuration-management/c
  m-configuration-management.aspx
• http//www.cs.lth.se/pdm-scm/
• http//www.dscc.dla.mil/downloads/psmc/April05/PSM
  C_pcms.ppt
• http//www-personal.si.umich.edu/nsharma/dikw_ori
  gin.htm
• http//www.ime.usp.br/vwsetzer/data-info.html
• http//www.commonkads.uva.nl/INFO/course-slides/04
  -km-basics.ppt

74
Acknowledgments
The author wishes to acknowledge the support from
the National Science Foundation Advanced
Technology Education Program, NSF Grant 0603362
for Midwest Coalition for Comprehensive Design
Education. The author also wishes to
acknowledge Craig Miller, Ph.D. and Isaac Chang,
Ph.D. for their role in the original development
of this material.