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.

A PLM Christmas List

In keeping with the spirit of the season, why not set out a wish list for PLM? If we sent it off to the North Pole, perhaps some of them would come to fruition.

Before we define the list, let’s set out a few objectives of PLM so that we clearly understand what we are trying to achieve before we wish for our imagined gifts. The following is an incomplete list but sometimes these objectives are lost in the daily struggle for survival lost in the technology:

1. Store data in a secure and controlled manner
2. Enable collaboration
3. Pass unambiguous and correct information to a manufacturing process

Based on the above, here is a list of PLM moves that many organizations could make with small investment and good returns:

• Free 3D viewers – In the spirit of collaborative design, it is strange how many organizations have a PLM system that only allows CAD designers to view 3D geometry. This leads to scenarios were other participants in the design process have to find a cooperative CAD designer to interrupt his current task and “pull up the geometry.” Long discussions can then ensue around design issues exposed by the geometry. Is this productive? – No. Many of the PLM vendors provide free 3D viewers that can be deployed to all participants in the design process. Some infrastructure may be required to create the correct file formats; but a for a small investment, CAD designers can focus uninterrupted on their business. Imagine the productivity gains! 

•  Ban Excel BOMS – Central to any organization that manufactures tangible goods is a Bill of Material. Without this information, nothing would leave the factory. In addition, BOM information usually feeds multiple downstream processes from procurement to service to ERP systems. So, why keep this vital information in a general software tool like Excel that is not designed to perform this function? In addition, the security and access controls that can be achieved are definitely deficient. For a modest investment, one can install a PLM system that has a robust and targeted BOM system designed to deliver correct and complete information to an organization.

• Close down FTP sites – There is no denying FTP is a very useful piece of software that has multiple applications, but it requires multiple manual interventions to be successful and can potentially be a security risk. If you drilled into any organization, there would probably be a few FTE equivalents of time spent using FTP. Modern PLM systems can offer many alternatives to this method of data transfer: collaboration servers, web portals, cache systems, or automated mailboxes are some examples. Looking for a good ROI opportunity? – close your FTP site.

• Automate PLM to ERP transfer – Typically, a BOM and related information is created in the PLM environment and then transferred to an ERP system for manufacture. Odds are that this transfer is entirely manual or, if partially automated, requires significant manual intervention. All manual interventions are prone to error and manufacturing errors are always costly. So why not put some effort into automating this crucial organizational interface?

Are there additional items that could be added to the wish list? Have a look in your organization and the list will grow.

The Version Revision Conundrum

You have a PLM system. Fundamental to this system is the concept of a version and a revision. However, it is probably the most misunderstood process in the PLM realm. Also these terms mean a wide variety of things to different people and are often used interchangeably and without consistency.

For the purposes of the rest of this piece, we will use the following definitions:

Version – represents a small incremental change in the design that would be saved in the database. Versions are not necessarily saved permanently beyond a revision.

Revision – represents a significant event in the design process and is saved permanently in the database for reference throughout the design process.

Diagrammatically, the difference is illustrated by the following diagram.

It is often confusing to talk to about this subject because the terms are used interchangeably. Also, the clear distinction between a version and a revision is not clearly understood; even to the extent that participants think that they are the same thing. Because of this, it is important that any organization with a PLM system ensure that all the participants clearly understand the definition and what the difference is.

In a collaborative PLM environment, participants are very dependent on viewing or using data generated by other participants. For example, a headlamp engineer needs the position of locating holes in the sheet metal to be able to design his locating pins (if this is the order of precedence). In this scenario, the headlamp engineer will say “I need the latest sheet metal to begin my design.” This statement is common in design and engineering teams. However, it is inherently imprecise because it begs the question: Do you need the latest version or latest revision?

Based on the definition given earlier, what is really required is the latest revision. A version is work in progress and could be incomplete or half done because the responsible author may be in the middle of a redesign or new concept. For this reason, a version should not be visible to the larger organization, only revisions should be accessible as they satisfy the definition of “best so far.” This concept is very difficult to get across to a lot of people and represents the conundrum referred to in the title. It takes some courage to work on data that will change sometime in the future but this is absolutely required in an efficient design process.

The version revision conundrum also leads to some interesting human psychology. Consider any collaborative design environment where multiple participants have to submit data into a PLM system to progress a large project. It is important in these environments that all participants follow the mantra of “publish early, publish often” or in the nomenclature of this piece: create many revisions. This is based on the principle that incomplete or slightly inaccurate data is better than no data at all.

However, process managers often put in systems that highlight inaccuracies or incomplete data, effectively punishing early publishers. So data authors hold back and only create revisions when they are certain of accuracy, late in the process. This is counterproductive.

So, pay attention to the version revision conundrum; clear definitions and policies of this simple issue can greatly improve a PLM process.

Tata Technologies PLM internet page.

Choosing PLM Technology

So your company has embarked on the PLM journey. Strategy is agreed, budget is approved, the preliminary plan for execution is in place and Return on Investment (ROI) has been computed.

The next step in the process is choosing a software suite and an associated vendor. Unfortunately, the nature of software is such that one cannot mix and match programs or modules to suit specific requirements; the major vendors design their solutions is such a way that organizations are locked into a specific monolithic offering. The choice of vendor, then, has long term ramifications, and, on the face of it appears to be a momentous decision.

So, how does one choose a PLM technology vendor? For the purposes of answering, let us submit two potential techniques:

1. Undertake a comprehensive study to evaluate the merits of each vendor's solution against requirements, conduct benchmarks and produce recommendations (The Bake Off)
2. Meet in the main boardroom of the company, ensure attendance of auditors and all interested parties and toss a coin to decide which vendor to choose (The Coin Toss)

Before debating the merits and demerits of each technique, it is instructive to outline a methodology for the bake off option. The high level steps required to conduct a study are as follows:

1. Outline business imperatives and goals (e.g. global engineering)
2. Identify the PLM processes that have to be put in place or facilitated to meet these goals (e.g. extended design reviews)
3. Create use cases to illustrate the processes (e.g. ability to load complete product into webex session and have geographically dispersed teams critique)
4. Evaluate each technology against the use case and score its capability to support the use case (e.g. how long does it take to load a product into a review session)
5. Total up all the scores and make a recommendation.

Clearly the Bake Off would be the conventional business approach. It offers the advantages of rigor, objectivity and a comprehensive approach. By following the evaluation methodology, an organization is guaranteed of having a technology that supports its needs.

So why even consider the Coin Toss? Any business person worth his salt would recoil at the thought of employing such a sloppy and unscientific method. But before dismissing this out of hand, consider a few items. Firstly, technology changes at an alarming pace and what is good today in one vendors solution will be outpaced by next year’s release. Secondly, the tough part of PLM implementations is managing organizational change and this has nothing to do with technology. Thirdly, agonizing over decisions is probably worse than making a snap decision – fortune favors the bold.

So consider the Coin Toss or a at least a compressed Bake Off; it can certainly save time and maybe allow an organization to leap ahead of its competition.