Security – Who can see your PLM data?

Fundamental to any PLM system is the idea of Access Control and data security. Only authorized personnel can access a PLM system and view or manipulate its contents. This is controlled via a login procedure that includes a user password. Personnel are added to the list of authorized users by the PLM administrator after someone has approved of their specific access rights.

Once access has been granted to users, it must then be determined what operations they can carry out on the PLM system. The simplest (and default) security model which allows all users to carry out any operation is very undesirable and could lead to actions that can destroy or leak vital data.

This scenario requires the development of a Security model which determines which user can carry out which operations. Security models are normally based on two concepts:

1. Roles

2. Organizations

A role in the database would define what the user who is assigned that role is allowed to do. Typical roles are as follows:

1. Viewer – this role would be allowed to view data but not make any alterations or modifications

2. Team Member – this role would be allowed to alter and update a limited subset of the data along with been able to carry out certain operations (e.g. initiate a workflow)

3. Team Leader – this role would be able to do everything that a Team Member could do along with the ability to operate on a larger subset of data and carry out more operations (e.g. progress a workflow, change ownership)

4. Approver – this role would be able to approve certain operations on the data (e.g. approve a release of information)

5. Database Admin – normally limited to a handful of technically qualified people.
Once roles in a database have been defined, the organizations are put in place. These normally mirror actual organizational structure although this is not a necessity. Organizations in a PLM system usually work on specific projects or programs. Once the organization is defined, users are allocated to various organizations and are assigned specific roles.

The final result can be represented in a table as follows:

		Within Organization			Outside Organization
User	Role	View	Modify	Approve	View	Modify	Approve
John Doe	Team Leader	Y	Y	Y	N	N	N
Paul Revere	Team Member	Y	Y	N	N	N	N
David Earp	Approver	Y	N	Y	Y	N	N

So how is security set up in your PLM system? Are all the security capabilities been used to ensure that no intellectual property is destroyed or leaked?

Configuring a Variant (Part 2)

In the previous post, the concept of variants and configurations was introduced. How can a PLM system help ambitious manufacturers handle the complexity of introducing multiple product variants? In a single sentence, this is achieved by conditional linkages in a BOM structure.

To explain further, consider the example from the last post of the fancy and plain spectacles. Instead of representing the two variants using two separate BOM structures, the variants can be achieved in one BOM structure as follows:

By making Condition 1 true (or visible) whilst keeping Condition 2 false (or invisible), the BOM resolves into the Plain Spectacle variant. Inverting this condition resolves the BOM into the Fancy Spectacle variant.

Clearly this is a simple example but a little imagination shows that this can be applied to far more complex situations. If setup correctly, a PLM system can very quickly generate BOM’s for multiple variants. In an organization faced with the challenge of product proliferation, this can be very efficient compared to any other method.

In setting up such structures, a few general guidelines apply:

1. The conditional links in the BOM should be applied as far down the structure as possible. This reduces common part duplication in lower levels
2. Conditional links should be set at the same indent level in the BOM hierarchy. If this is not done, BOM resovles can lead to nonsensical results, especially if there are stacked conditionals

How is your organization dealing with variants?

Configuring a Variant (Part 1)

One of the major problems facing any manufacturer of physical product is the issue of variations. Typically a manufacturer is faced with a dichotomy: customers want infinite variations in what they can buy but a manufacturing process is most efficient when it is only making on specific product. This problem is seen across many industries, especially where the production model is based on make-to-order.

As an example, consider a pickup truck. It has been estimated that by time one takes into consideration all of the exterior colors (maybe 10), interior colors (maybe 5), powertrain possibilities (maybe 3), trim levels (maybe 5), sunroof or not, premium sound system or not, towing package etc. there are over 100,000 buildable combinations. Such large numbers are the inescapable consequence of mathematics; combinations are multiplicative and grow exponentially in a way similar to the factorial function used to calculate odds.

As with a lot of PLM terminology, some confusion exists with regard to definitions and so this article will use the following definitions:

1.  A configuration is a specific grouping of parts or components that achieves a certain function within an overall product
2. A variant is a single option within an overall product family
3. A variant is a combination of specific configurations of parts or components

 Consider the following example:

In the above structure, a distinction is made between a spectacle with a fancy frame or a plain frame. However the lenses and frame arms are common across both variants.

This simple example illustrates the power of variant designs; the customer now has two choices but the manufacturer has a many common parts across the two products. 

So, how to harness these advantages in PLM system? That will be covered in the next post.

PLM on the tablet

Among technology practitioners there is no shortage of pundits offering predictions of the future and where the next big wave is going to hit. The reason for this is that the stakes are high – a correct forecast of future technology trends can literally be worth billions.
So what are the current predictions talking about? Here is a sampling of the current buzz:

1.     Big Data
2.     Social Media
3.     Crowd Sourcing
4.     Social Computing
5.     Mobile Connectivity

So how does this impact PLM? Traditionally PLM is conducted on internal infrastructure in secured environments using traditional devices. For example, an average designer concerned with the creation of a 3D CAD data would be working on a company workstation behind a firewall. Equally, an engineer creating BOM data would be using a secured client install on his company laptop. The possibility exists that the engineer may take his laptop home and interact with the PLM system via a VPN but this is probably the extent of “mobility.”

Returning to the technology buzz, consider the potential impact of two trends – mobile connectivity and social computing. Consider the following scenarios:

Your newly recruited engineer has transitioned his digital life to his tablet and no longer uses a laptop. (hence the title of this piece)

The VP of Engineering wants to query the status of his product introduction using his mobile phone
Your company wants immediate access to customer feedback on existing products so that this can be translated into requirements for new or updated designs

Given the traditional model sketched our earlier, implementing anything close to these scenarios is almost impossible. The infrastructure, mindset and processes will not support mobile connectivity from alternative devices nor allow general access to a requirements gathering front end. Also, it raises a whole lot of questions around data security, use of private devices and non-company access. While the technology to achieve these scenarios probably exists, it would require considerable financial and effort investment to make it happen.

This leads to the fundamental risk investment equation. It may be possible to construct a business case that justifies the outlay. At a high level, two possibilities exist:

1. Traditional PLM infrastructure is good enough for at least the next ten years and can be re-evaluated then
2. Changing the way business is conducted is a do or die activity and this includes PLM

 An informal survey of small to medium size companies shows that most participants have not even considered these technology trends. In part, there appears to be no business imperative and in part because there are other more attractive avenues for immediate investment.

So, do you want your engineers to be doing all their engineering work on a tablet?

BOM Management – Have you heard the ticking?

A Bill of Material (BOM) at its core is a very simple concept. It is a list of components needed to manufacture a finished product. So if one was making a pair of spectacles, the BOM may look as follows:

Finished Product	Spectacles	Quantity
Item 1	Right Lens	1
Item 2	Left Lens	1
Item 3	Frame	1
Item 4	Hinge	2

It must be said that understanding how a BOM functions is fundamental to understanding how PLM systems work as this simple list is really at the core of the system. However, simple concepts have a tendency to escalate into very complex subjects. And so it is with a BOM.

One of the complexities associated with a BOM is that an organization usually has a requirement for different types of a BOM in order to define a single product. Most manufacturing companies have at least three types:

1. EBOM (Engineering BOM) is the list of parts that engineers are responsible for and comprises all the components that require some sort of design input
   
2. MBOM (Manufacturing BOM) is the list of parts that are required to actually make the product. This is typically different from EBOM by components that engineering do not specifically design (glue strips, liquid fills etc.). It may also be plant specific.
   
3.  XBOM (Service BOM) is an as built list of parts used in a product that actually made it off the factory floor. This may be different from what was originally specified by the MBOM because of crisis during manufacture. It is important from a customer service perspective.

So the question is – how are your three BOMs authored, edited, maintained and released? Whatever the answer to this question, the outcome is always the same:

1. No BOM – No product
   
2. Wrong BOM – Factory rework or customer dissatisfaction.

An informal survey of small to medium size companies yields surprising results: Excel is the predominant BOM management tool in an engineering environment. Manufacturing BOMs are normally handled by some sort of ERP system and service BOMs are poorly tracked, if at all. This situation is fraught with potential for disaster because of all the manual processes that have to occur before an actual product gets made.

Hence the analogy in the title; BOM management may be a hidden problem that is set to explode in an organization, especially if the products been made become more complex. PLM systems can offer a single organized BOM that represents all the different types in a consistent, controlled manner. Given the potential consequences of the bomb exploding, BOM in PLM should be a priority.

Intelligent Part Numbers – Not so clever

Fundamental to any manufacturing organization, and by extension its PLM system, is the part number. This is a unique identifier for any end component used in a manufacturing process.

Anyone who has dealt with part numbers is familiar with the so called "intelligent part number". To an extent, this is a carryover from the days before sophisticated database systems and fast computers. It involves baking multiple pieces of information into single part number.

For example, consider the fictitious case of the omnipresent widget and assume that it has a Part Number built up as follows:

Initially, the structure of the number seems perfectly logical and in keeping with our concept of what part numbers should look like. However, a more detailed analysis will diagnose some (but not all) potential problems:

1. Clearly, a transition into the 21^st Century is a problem for the first two digits of the number
2. The 1001^th part will not be able to fit
3. The enterprise expands its manufacturing base offshore and wants to introduce country codes

If the intelligent part number is the key attribute in the database, the problem rapidly compounds. This is because it is extremely difficult to change the key attribute in a database once objects have been created and included in multiple relationships.
 

So what is the alternative to intelligent part numbers? The prudent alternative is to set up non-key attributes in the database that contain the information previously baked into the part number. Once this is done, the part number for objects can be a randomly allocated sequence of digits.
 

This may sound counter intuitive but, in the long run, will save a lot of heartache.