You are currently browsing the tag archive for the ‘Classification’ tag.

classificationIn my previous post describing the various facets of the EBOM, I mentioned several times classification as an important topic related to the PLM data model. Classification is crucial to support people to reuse information and, in addition, there are business processes that are only relevant for a particular class of information, so it is not only related to search/reuse support.

In 2008, I wrote a post about classification, you can read it here. Meanwhile, the world has moved on, and I believe more modern classification methods exist.

Why classification ?

searchFirst of all classification is used to structure information and to support retrieval of the information at a later moment, either for reuse or for reference later in the product lifecycle. Related to reuse, companies can save significant money when parts are reused. It is not only the design time or sourcing time that is reduced. Additional benefits are lower risks for errors (fewer discoveries), reduced process and approval time (human overhead), reduced stock (if applicable), and more volume discount (if applicable) and reduced End-Of-Life handling.

An interesting discussion about reuse started by Joe Barkai can also be found on LinkedIn here, including interesting comments

Classification can also be used to control access to certain information (mainly document classification), or classification can be used to make sure certain processes are followed, e.g. export control, hazardous materials, budget approvals, etc. Although I will speak mainly about part classification in this post, classification can be used for any type of information in the PLM data model.

Classification standards

din4000Depending on the industry you are working in, there are various classification standards for parts. When I worked in the German-speaking countries (the DACH-länder) the most discussed classification at that time was DIN4000 (Sachmerkmal-liste), a must have standard for many of the small and medium sized manufacturing companies. The DIN 4000 standard had a predefined part hierarchy and did not describe the necessary properties per class. I haven’t met a similar standard in other countries at that time.

Another very generic classification I have seen are the UNSPC standard, again a hierarchical classification supporting everything in the universe but no definition of attributes.

15926Other classification standards like ISO13399, RosettaNET, ISO15926 and IFC exist to support collaboration and/or the supply chain. When you want to exchange data with other disciplines or partners. The advantage of a standard definition (with attributes) is that you can exchange data with less human processing (saving labor costs and time – the benefit of a digital enterprise).

I will not go deeper into the various standards here as I am not the expert for all the standards. Every industry has its own classification standards, a hierarchical standard, and if more advanced the hierarchy is also supported by attributes related to each class. But let´s go into the data model part.

Classification and data model

clip_image002The first lesson I learned when implementing PLM was that you should not build your classification hard-coded into the PLM, data model. When working with SmarTeam is was very easy to define part classes and attributes to inherit. Some customers had more than 300 classes represented in their data model just for parts. You can imagine that it looks nice in a demo. However when it comes to reality, a hard-coded classification becomes a pain in the model. (left image, one of the bad examples from the past)

1 – First of all, classification should be dynamic, easy to extend.

2 – The second problem however with a hard-coded classification was that once a part is defined for the first time the information object has a fixed class. Later changes need a lot of work (relinking of information / approval processes for the new information).

3 – Finally, the third point against a hard-coded classification is that it is likely that parts will be classified according to different classifications at the same time. The image bellow shows such a multiple classification.

multiclass

So the best approach is to have a generic part definition in your data model and perhaps a few subtypes. Companies tend to differentiate still between hardware (mechanical / electrical) parts and software parts.

Next a part should be assigned at least to one class, and the assignment to this class would bring more attributes to the part. Most of the PLM systems that support classification have the ability to navigate through a class hierarchy and find similar parts.

When parts are relevant for ERP they might belong to a manufacturing parts class, which add particular attributes required for a smooth PLM – ERP link. Manufacturing part types can be used as templates for ERP to be completed.

This concept is also shared by Ed Lopategui as commented to my earlier post about EBOM Part types. Ed states:

Think part of the challenge moving forward is we’ve always handled these as parts under different methodologies, which requires specific data structures for each, etc. The next gen take on all this needs to be more malleable perhaps. So there are just parts. Be they service or make/buy or some combination – say a long lead functional standard part and they would acquire the properties, synchronizations, and behaviors accordingly. People have trouble picking the right bucket, and sometimes the buckets change. Let the infrastructure do the work. That would help the burden of multiple transitions, where CAD BOM to EBOM to MBOM to SBOM eventually ends up in a chain of confusion.

I fully agree with his statement and consider this as the future trend of modern PLM: Shared data that will be enriched by different usage through the lifecycle.

Why don’t we classify all data in PLM?

There are two challenges for classification in general.

  • The first one is that the value of classification only becomes visible in the long-term, and I have seen several young companies that were only focusing on engineering. No metadata in the file properties, no part-centric data management structure and several years later they face the lack of visibility what has been done in the past. Only if one of the engineers remembers a similar situation, there is a chance of reuse.
  • The second challenge is that through a merger or acquisition suddenly the company has to manage two classifications. If the data model was clean (no hard-coded subclasses) there is hope to merge the information together. Otherwise, it might become a painful activity to discover similarities.

SO THINK AHEAD EVEN IF YOU DO NOT SEE THE NEED NOW !

Modern search based applications

There are ways to improve classification and reuse by using search-based application which can index archives and try to find similarity in properties / attributes. Again if the engineers never filled the properties in the CAD model, there is little to nothing to recover as I experienced in a customer situation. My PLM US peer, Dick Bourke, wrote several articles about search-based applications and classification for engineering.com, which are interesting to read if you want to learn more: Useful Search Applications for Finding Engineering Data

So much to discuss on this topic, however I reached my 1000 words again Sad smile

Conclusion

Classification brings benefits for reuse and discovery of information although benefits are long-term. Think long-term too when you define classifications. Keep the data model simple and add attributes groups to parts based on functional classifications. This enables a data-driven PLM implementation where the power is in the attributes not longer in the part number. In the future, search-based applications will offer a quick start to classify and structure data.

 

Advertisements

This time a more theoretical post about classification in PLM. A topic that always has been around for more than a decade. Recently classification also came up in some discussions both with customers and on discussion groups on the Internet. So what I will try to do in this post, is to explain the goals of classification, the ways classification is implemented and finally how I see classification will evolve. As always feel free to comment or extend my post.

The goals

Classification is a generic understanding, so to start I want to narrow classification to item classification. Companies might use classification in various ways, for products, for knowledge, for supported functions and more. The most discussed topic in the context of PLM however is item classification. The idea of item classification is twofold: understand what you already have (designed) and promote reuse. Historically the item definition has been stored in the ERP system and reuse was mainly based on recognizing parts of the description. Sometimes the ERP system also supported a kind of classification id to group certain parts – like fasteners, frames, base materials etc.

With the introduction of electronic parts this rough classification as defined in ERP became insufficient as already the description and classification id were not enough to really understand if an item could be reused. During that same period of time more and more companies where merging or acquiring other companies and they want to understand and benefit from items already used in one of the companies.

So this brings back the challenge for the two goals mentioned:

  • How can I make sure my engineering reuse existing items in future products ?
  • How can i consolidate and understand items i have used in my company ?

Item reuse

In order to promote item reuse companies have used various classification systems in engineering to promote reuse and standardization within the company. Design catalogs with standard purchase parts, extended with company standard parts were implemented to limit the variety of choices for a designer. Companies & Products  like Trace Parts, SolidWorks Toolbox, Inventor Content Center address this need.

Additional mostly in the German speaking countries a classification standard exists, called sachmerkmahl leiste (sorry only in German) or often referred to in the context of the DIN 4000 standard. This is also a standard classification standard, less CAD design centric. Interesting to analyze why this standard does not exist in other countries.

One of the reasons might be that classifying all your engineering data takes a lot of time – specially when you haven’t done it from the start. I worked with some companies where more than a man-year was spent on classifying information. This work had to be done by someone with engineering knowledge, so you can imagine the investment for classification, beside the software was huge. Main question is, what will be the (expected) Return On Investment ?

In this area I think that a cultural difference plays a role here. Some countries invest more in their working methodology and processes than others where the focus might be only on the single result. From my global experience to be fair, i have not seen and heard the real benefits of this type of classification for reuse. I am looking forward for statements from companies that have measurable result here. Like many IT projects we have the emotional feeling that this approach should bring benefits

Item Consolidation

In the mid nineties when companies started to merge, PDM became PLM, CRM became important, also another trend became visible. The need for item classification systems, more on the inventory side, for companies to understand which items they were using around their (merged) enterprises. One of the first companies that time was Aspect Development Inc, later in 2000 merged with I2. Customer case studies learned us that in some of these enterprises a single item could exist with 100 different ID’s, all described or classified in various departments a little different, so hard to reuse. Only by classifying items within an enterprise based on their specific characteristics, people start to recognize identical items. Also in smaller mid-market companies I have seen situations where items have been named or identified just a little bit different, although they were the same.

Here benefits of item consolidation can be easier justified. I assume most companies can estimate what is the total cost of handling an item through its lifecycle and what are the purchase benefits by consolidating for example 10 different named into a single item to be purchased in a much bigger quota.

The benefits really come when you control your inventory and from this base feed the engineering department with an optimized selection of validated items for reuse. And this is to my opinion the most important goal of classification

How to implement classification ?

As described above classification is needed to promote reuse of engineering knowledge and to standardize on inventory (purchased items).

To address the first need I believe PLM offers various ways to support a classification. Some might believe DIN 4000 is a useful standard. From my experiences with companies it appears that it is important to bring rational to what you classify. Where is the ROI. Classification brings a lot of constraints and overhead to the engineering department – all parameters needs to be mandatory managed for each part, otherwise your classification looses its value. Probably you will realize that classifying metal strips does not bring the reuse value as the overhead for maintaining the classification is higher then the cost of producing a new strip. So I am not so convinced about classification for this need.

For the second need – inventory optimization – here i believe the classification brings a measurable ROI, specially when the company uses  a New Item Approval process  or Standardization Process, where every new item will be reviewed (and classified) to guarantee its unique need. Of course it depends very much on the type of industry and main business process if this approach brings value. Listed in a more relevance order: Engineering To Order / Configure To Order / Design For Manufacturing

Folksonomy versus Taxsonomy

A new trend for classification is the way search engines work on massive unstructured data. No one tries to classify all the web pages that exist (although there might be a standard for that). It is easier to perform a context search and specially with new web development you see that tagging information becomes more and more important for retrieval. For example I tagged this article with PLM, ERP, Classification, Item Reuse and Item Consolidation. These tags will be used by search engines and I do not have to worry on which level and where Item Reuse is stored. As a creator of this text part I tag my information for reuse.

This is called Folksonomy, this in contrary to Taxsonomy, the classical method for ordering information. See for more background the related wiki hyperlinks.

Conclusion

Implementing Folksonomy in a PLM environment depends on the type of PLM system you are using (in case you use a PLM system). It requires a way to tag information in an user-friendly way and to retrieve information by tags in an easy way – the ease of use of a search engine. In case it is too futuristic this approach, evaluate your engineering classification needs based on your expected ROI and goals, keeping in mind in the classical way of classification will evolve.

Do you have examples of classification with a proven ROI for engineering, let me know

sleepIn the previous post, I described that the item is the primary entity used in the connection between a PLM system and an ERP system. The initial definition comes from the engineering department, defining the main characteristics of the item, like ID (part number), Description and Classification Data for engineering usage.

Next when the item reaches a certain maturity stage, that it will be purchased or produced, the initial definition needs to be transferred to the ERP system and to be completed in ERP with logistical data. Often as part of the classification data, the engineer has already defined what type of item it will be. This information can be used in ERP to apply default data based on a certain template item or derived-from item.item_id

 
Item identification / Part Number

Most of the manufacturing companies are using so called ‘intelligent’ part numbers to identify their items. This was done for historical reasons. As there was no IT system in the company, the part number contained logic and information in order to ‘immediately’ understand its usage.

For example M210-23-4-00-A3.C tells me immediately it is a manufactured part, first time used in the milling product line (210) and it is used for hydraulic (23), not in stock (4), a preferred item for engineering (00) and its definition can be found on the drawing with the same name, size A3 revision C.

If you did not understand this directly from the number, it does not mean you are not intelligent, although it is an intelligent part number. This shows that intelligent numbers are useful when people are trained and have a good memory. For everyone else in the company (and joining the company later) the number is initially the same as a meaningless number.

For that reason is is recommended to use ‘non-intelligent’ numbers to identify parts. This creates no overhead for people to learn all kind of intelligent numbering mechanisms and it pushes everyone to look to additional information which can be understood immediately, like the description or classification data. We have now IT systems like a PLM or ERP system that allows us to display more than a number.

For backwards tractability of course beside the new meaningless part number, there can be also a place holder in the IT system to define what the origin of the part was (with the intelligent part number). Specially when companies merge this will happen. The same part exists in different numbering schemes in each company. The only way to solve this is to add a new identifier, preferred to be the ‘non-intelligent’ number.

Conclusion: For part numbers it is recommended to use non-intelligent numbers based on a sequence, avoiding the creation of legacy information (merge) or training to understand the items by number.

Now the new created part has a meaningless identifier, we have achieved two things:

  • The PLM and ERP system have unique key to share. Identifying this number with its revision (if relevant) immediately makes it clear for both the PLM and ERP system which part is meant.
  • To understand what the item really does, we need to understand additional information like its description

Note

: Not all ERP systems support revisions of items. Some work always with the actual version of the item. Where PLM systems trace and keep the exact definition of an item, often ERP systems trace the item by effectivity. You need to know what was the engineering definition, when the item was manufactured.

desc


Description / Classification

Initially when an item is defined the engineer might create a description, like HYDRAULIC CLAMP without any further details. Some years later there might be 10 or more hydraulic clamps in the system, where some of them might be identical and others differ. However the description HYDRAULIC CLAMP might be sufficient for a part list to be shipped to a customer (we do not want the customer to know the exact item characteristics in order to have him order the spare parts through us).

Often on the engineering side an additional description field is added, which is a detailed description. This description is used internally and should be standardized in order to support the engineer to select the right item.

So HYDRAULIC CLAMP could have an internal definition HYDRAULIC CLAMP 400-600 describing its usage. This detailed description should be either enforced and generated by the PLM or should be handled through a librarian or standardization role in engineering. This should be combined with a classification of the new item. The advantage of a detailed description and classification is two-fold:

  1. It supports engineers to search for existing items – so reuse is more likely. Often the description in the ERP system was not built in this way and for that reason engineers re-invent items while they might exist.
  2. The classification will alert the engineer or librarian that an item with the same classification characteristics already exists. This means it might be identical or an additional classification characteristic is needed to differentiate the two items.

The definition of a new item would go through the following steps:

  • The engineer defines the description and can work with the item in a temporary mode as he is not sure of using the new item in this way
  • The item becomes mature and he needs to generate the detailed description.
  • At this stage the librarian or a standardization committee might come in, to analyze the need for the new item. And if so to define all its classification data, knowing it is a new and unique item needed.
  • Once the engineering definition is completed, the item definition can be send to the ERP system in order to complete it with logistical data – who can manufacture it and tens of attributes more. The item still is not released
  • A hand-shake from the ERP system will confirm that the item definition is completed and as part of the release process the item can be approved for manufacturing. In case no pre-production stage exists it might be released even.

new item defintion

Conclusion: Standard Description, Detailed Description and Classification information is done on the PLM side to support reuse of items and to avoid creation of similar items with a different part number. The ERP systems uses the description definition and completes the definition with ERP required information. Data relevant for the engineering is synchronized back once the full definition is available.

The next post in this sequence will be discussing the BOM transfer to ERP

Translate

Email subscription to this blog

Advertisements
%d bloggers like this: