PLM

UNIT 2

Dr. P.Srihari,
Associate Professor
Mechanical Engineering Dept., Aitam Tekkali
Product Importance
The product is important.
 Whether it’s a chair, a beverage, an aircraft or an anesthetic, it’s
the product, and perhaps some related services, that the customer
wants.
 The product is the source of company revenues.
 Without a product, the company doesn’t need to exist and won’t
have any customers. Without a product, there won’t be any related
services.
 The company generates revenues from an on-going stream of
innovative new and upgraded products.
 Great products make it the leader in its industry sector and lead to
great profitability.
Product Range
There’s a huge range of products.
 There are tangible products, i.e. products you can touch, products
such as a computer and a car.
 And there are intangible products such as software, insurance
policies and mortgages.
 There are products as diverse as an Airbus A380 and a dollar bill, a
book and a beverage. Products come in all sorts of shapes and sizes.
 Product packaging is often a part of the product. So is product
labelling.
 The product may include wires and plugs that connect it to the outside
world.
 The product may include product literature, such as user
documentation or regulatory documentation.
Product Instance
 “Instance” is a term very commonly used in programming where multiple objects (from a
reference asset) are created through “instancing”.
 For none IT users, you can arguably say that a copy is made.
 Once the development is completed, the data (maintenance and usage) for the product is
collected and stored (dimensions, drawings, characteristics, etc).
 The product will then go into production where an “instance” of the product is created.
 Once created, data (maintenance and usage) is collected for the produced parts (e.g. load
values, test parameters, etc).
 Since the product is followed through the value chain, the data available from the product
can be used by a customer (as they use the asset in their production process).
Example:- Suppose a machine builder uses the part which is produced earlier by the
supplier.
 During the development phase (e.g. machine design) data about the electrical motor can
be provided (e.g. CAD drawing).
 Once the motor is used in the assembly process of the machine builder and any error or
improvement is found, this can be communicated back to the company that developed and
produced the electrical motor.
Product Identifier
There are so many products and so many parts in products, that special
identifiers are needed to know exactly which “thing” is being referred to in
situations as diverse as:
 defining a product,
 assembling the product,
 controlling stock levels,
 ordering,
 billing,
 accounting, and
 handling complaints and returns.

To make things easier for themselves, the departments often used

“speaking numbers” (also referred to as “significant numbers”,
“intelligent numbers”, “meaningful numbers” and “coded numbers”)
to identify parts.
Product Identifier
These identifiers were helpful as they indicate something about the
product or part. Example:-
 L20-US-P1 could refer to a 20 inch product sold in the US in package 1.
 L20-JP-P4 could be the same product sold in Japan in package 4.
 L20-GE-P8 could be the same product sold in Germany in package 8.

Some departments use tabulated documents as identifiers.

Example:-
Instead of making 12 separate drawings, each with its own name and
identifier, of similar parts, drawing of one of the parts is made. Then, on
the same sheet of paper, a table is created showing the characteristics
that change from one part to another for all the 12 parts.
Product Requirements
Product Requirements define the product that is about to be built. It
outlines the product’s:
 purpose,
 features,
 functionalities, and
 behavior
A Product Requirements Document (PRD) is prepared and shared with
all stakeholders which includes business and technical teams who will help
build, launch or market your product. There are particular types of
requirements that product should fulfill as listed below:
• Functionality
• Quality
• Usability
• Reliability
• Safety
• Packaging
• References
Product Structure
 The product structure in many respects forms the heart of a PLM
system.
 In other words, the parts or components, service elements, documents
and assemblies are attached to the product and to each other through
the product structure.
 The product structure provides the foundation for some of the basic
functions of a PLM system.
 Product structure is a hierarchical decomposition of a product,
typically known as the Bill of Materials (BOM).
 As business becomes more responsive to unique consumer tastes and
derivative products grow to meet the unique configurations, BOM
management can become unmanageable.
 The core of the product structure is illustrated by the product
components (items) and their relationships.
Product Structure Views
 Product structure views are made upon several activity domains
within the company.
 When the Master
Structure is made out of the
several items of the product
assembly, multiple views can
be made upon this Master MASTER STRUCTURE PRODUCT DEFINITION
Structure.

 Master Structure contains

every item in detail, which is VIEW
important to the Assembly of
the product.

MANUFACTURING PURCHASING
SERVICE VIEW DESIGN VIEW SALES VIEW
VIEW VIEW
Product Structure Views
 After structuring the product with all the listed items and relationship
between them this must be combined into one Master Structure which
contains all of the details of the product.
 In case of a car, all items from engine to screw must be documented in
one MASTER STRUCTURE.
Product Structure Views
 In case of the car manufacturer multiple views can be derived from the
car assembly.
 For example a structure from a sales point of view will need more detail
about the functions and characteristics of the car rather than detailed
information about the body.
 From a purchasing view more information is needed about the mixing of
the paint instead of the general color, which is only needed for the
customer.
Product Pains throughout the
Lifecycle
Causes of Product Problems
 Lack of understanding of the target market and customer needs.
 Poor product design and quality.
 Inadequate market research and testing.
 Misaligned pricing and value.
 Difficult to understand or use.
 Poor product-market fit.
 Lack of innovation and differentiation.
 Mismanagement of risks and challenges.
 Business Process
As per ISO 9000 Introduction and Support Package:
 A process is defined as a “set of interrelated or interacting activities, which
transforms inputs into outputs”.
 A business process is an organised set of activities, with clearly defined inputs and
outputs, which creates business value.
 Business Process Management (BPM) is an overall approach to the improvement
of a company’s business processes. It includes process mapping, process modelling
and process measurement.
 Within each of the activities there are usually:
i) tasks, ii) roles, iii) responsibilities, iv) checklists, v) milestones, vi) deliverables and
metrics

These six items specify in detail the scope, nature, type, information needs,
resources, required skills and measurement of work
Business Process
 The term Process Mapping is usually used to describe the activity of
documenting an existing process. This activity is also sometimes referred
to as Business Process Mapping, or Process Charting, or Process
Flow Charting.
 The term Process Modelling, or Business Process Modelling, is usually
used to describe the activity of creating models of future processes.
 A method (also sometimes referred to as a technique or a best
practice) is a recommended way of carrying out a particular set of
activities.
There are more than a 100 methods related to products. They range from
very technical methods to broadbrush management approaches.
Examples include Activity Based Costing (ABC), Design for Assembly (DFA)
and Total Quality Management (TQM).
Business Process
 Use Case describes, from the user viewpoint, the interaction between a
user of a system and the system.
 The interaction is made up of many individual actions.
 A Use Case can be used, during system design, to show expected
behavior and to clarify requirements.

 Workflow (or application workflow) is a small set of connected actions

that are frequently carried out, and has been automated in a particular
application.
 The actions will normally have been defined in a Use Case.
Business Process
 Process approach is one of the eight principles for a company’s
quality management system (QMS) recommended in the ISO
9001:2008 Quality management systems—Requirements document
Business Process Architecture – An
Example
Top Level Business Process Layout
Documenting (Business) Processes
Reasons for documenting an organization’s processes:

Following are ingredients or types of documenting the processes:

1. Model: Models are needed to help people understand and
communicate about it. A model of the PLM environment acts as a
common basis for discussion and communication
2. Process Flow Diagram: It is a simple list of process steps for a
process wouldn’t show the interactions between tasks. It wouldn’t
show the different routes the flow may take when a decision is taken.
Interactions are easier to show in flowcharts.
Documenting (Business) Processes
Following are ingredients or types of documenting the processes:
3. Swimlanes: This approach allows information about the roles of
participants (“actors”) to be shown. It shows the flow of activities,
including the activity of taking a decision.
4. Process Description Document: One part of a company’s process
documentation usually includes a top-down description of how the
business processes fit together (the company’s Business Process
Architecture).
5. Process Steps: Process Description Document shows the main steps
in a process where as the process steps show the detailed steps of a
process.
Example: Product Complaint Process
6. Use Case or Use Case Description or Use Case Diagram: A Use
Case describes, from the user viewpoint, the interaction between a
user of a system and the system. It can be used during system design
Documenting (Business) Processes
A Use Case Diagram brings together several Use Cases. It is one of the
three Unified Modelling Language (UML) behavior diagrams. UML is a
commonly-used modelling language.

Use Case Diagram for a Use Case Diagram for a library

proposal
Documenting (Business) Processes
7. Workflow: A workflow is a small set of connected actions that are
frequently carried out to accomplish a particular goal, and have been
automated in a particular application.
 A Use Case can be used as a basis for building a workflow.
 There are clearly defined steps and roles in a workflow.
 Activities are carried out, in a pre-defined order, using pre-defined
documents, by the people in those roles working according to pre-
defined rules.
Process Reality in a Typical Company
 Generic Issues with Business Processes
 Interaction with Other Activities
 Generic Issues with Methods
 Interaction with Company Initiatives
 A Generic Vision for Business Processes in PLM
Process Reality in a Typical Company
1.GENERIC ISSUES:
There will usually be many issues with processes in the PLM
environment. The issues fall into several groups as below:

Name and Scope: One of the issues is that there are no standard, “off-
the-shelf” business processes. Each company has to develop its own
processes. It chooses its own names for these processes, and fixes their
scope. A process may even be given several names in the same company.

Many similar names and scopes

Process Reality in a Typical Company
1. GENERIC ISSUES
Process Development:
 It’s not easy to develop effective but lean business processes.
 Unless a company invests a lot of time and effort, its processes may be
poorly defined, and poorly documented.
 Many processes are cross-functional. But it’s often difficult, when
developing a process, to get away from a departmental focus.
 A process developer from one department will tend to include everything
needed by their department, and ignore the needs of other departments.
Process Change:
 As time passes, and the environment evolves, business processes will
change, resulting in several versions of the same process.
 But there may be no version management system for processes.
 As a result, confusion may arise as some people start to work with a new
version of the process, while others continue to work with the old
version.
Process Reality in a Typical Company
1.GENERIC ISSUES:
Process Management: Unless business processes are managed, they
will become less effective.
Typical issues with processes

Possible causes of the issues

Process Reality in a Typical Company
2.INTERACTION WITH OTHER ACTIVITIES:
No business process is an island isolated from the rest of the company.
Every process is related to all the other PLM components.
A change to a process can lead to changes in many other components.
Business processes shouldn’t be addressed independently of other components of
the PLM environment.
For example, to improve performance, two business processes may be merged into
one. In the future process, only one document may be needed instead of two.
Process Reality in a Typical Company
3. GENERIC ISSUES WITH METHODS
In a typical company, there will be many issues with business processes.
There will also be many issues with the methods used in the PLM
environment.
 Unclear Name and Scope
 Overlap Between Methods
 Overlap Between Methods and Applications
 Confusion Between Methods and Processes
 Duplication of Existing Activities
 Unclear Metrics
 Method Evolution and Confusion
 Interaction of Methods with Other PLM Components
 Business Process Activities in the PLM
Initiative
 A PLM Initiative takes a company from its current PLM situation to a
desired future PLM situation.
 Business Process Activities in the PLM
Initiative
 Projects Related to Business Processes
 Business Process Improvement
 Business Process Mapping and Modelling
 The ECM (Engineering Change Management) Business Process
 The NPD(New Product Development) Business Process
 The Portfolio Management Process
Some Reasons for Business Process Mapping

Guidelines for Business Process Mapping

Typical Tasks in ECM Process
 create a change request, detailing items to be changed, and
affected items
 detail the change request with a description, reason and change
category
 receive change requests every day from many sources
 screen the requests, and filter symptoms from root causes
 evaluate the requests and the consequences of the change
 decide what to do
 request the selected changes to be made by various functions
 carry out the changes
 track the changes through the process
 document all activities and the resulting consequences
 notify the changes
 manage the change process report
 change process metrics