Home Featured What’s in a name?

What’s in a name?



In his most recent piece with us, frequent WhichPLM contributor Dan Hudson, President of E-Spec, shares the issues he has found with mismatched fields between systems, and the necessity in having everyone in a business ‘on the same page’ when it comes to field names.

When Names Don’t Match Up

When we first started performing system integrations, one of the main issues we faced was matching up the fields between the various systems. The first system might not use the same name for the field as the next system or, worse yet, they might actually use the same name for a different field. This exercise often revealed even more complexity; the field in the first system might refer to a data set (multiple items) while the next system might actually refer to a single instance of the data set.  For example a product system might use the name “style number” referring to a t-shirt. This style number’s related data would reflect the status of the development of this t-shirt; it’s color, fabric, fit and approval status. When you look at the ERP system, style number now refers to a particular version of this t-shirt; each color now has its own style number (and related data).

While all of these issues can be addressed, finding the issue is not always so easy. Many assumptions are made and use of the field names is contained in their respective “silos” so the subtle differences are not readily apparent.

Add a Prefix or Suffix?

One way the previous example has been addressed in the past is the use of prefix or suffix “codes”; a color code is added to the style number to distinguish between the entire data set and an individual member.  Whilst this does address the issue, it doesn’t stop the ERP users from interchanging the terminology. What it does do is introduce “intelligent numbering” into the environment. Intelligent style numbers or part numbers will open up a decades old debate, which isn’t my intent here. For now, let’s say there can be an overuse of intelligence in numbering schemes. Having too many attributes included in the scheme makes the numbers very complex and not user friendly.

The more common problem is “running out of room” – the number of variations for an attribute eventually exceeds the character combinations that can be represented with the number of characters reserved for the attribute. A color code might start out as three numbers, but when the 1000th color is used typically a letter is now used for one of the values rather than adding a fourth number. This is due to the legacy system only allowing three digits for the code; the showstopper is when the legacy system doesn’t support alphanumeric values, just numbers. Reprogramming this system isn’t usually an option so more drastic measures are required; manually tracking the use of the same code for two items.

Defining your Taxonomy for a Master Schema

The implementation of a system like PLM, which is tearing down these silos, brings these types of issues to the forefront. The use of data analytics and “big data” highlight the confusion as “garbage in – garbage out”: the result if consistency is not achieved. The top down approach of Master Data Management (MDM) makes addressing these issues a science. The terms taxonomy and structured vocabularies are now routinely used.  Taxonomy is the exercise of defining your classification system; what are the characteristics your company uses to describe its products and processes. These characteristics are also defined as hierarchical or as attributes; the hierarchical values “define” the product while the attributes “describe” it. Structured vocabularies define an agreed set of values to be used for your hierarchy and attributes; all departments agree to call everything by the same name. The structured part refers to the business rules applied: certain values are not allowed with other values; the values for “product type” are different based on the values for “gender” – no dresses are allowed as a product type if the gender equals male.

Adobe’s XMP Can Help

Many companies find the task of creating a taxonomy and structured vocabulary overwhelming, as there is no good or obvious place to start. Defining the taxonomy in one system does little to implement it in the next and to tackle all of your systems at once would bring the business to its knees.

Adobe’s XMP metadata standard is positioned as an ideal tool to start defining your taxonomy and structured vocabulary. The standard allows you to create a master list of field definitions that can then be deployed to each system in an orderly fashion. The use of custom XMP fields following the Adobe standard allows a business to capture all of its field and value definitions in a single schema. This “master” schema can then be used to create subsets for each department or system, as not all fields are relevant to all users. Deploying the subset schemas to a system that does not support XMP natively is eased by the similarity of XMP to XML; most of your current systems will support XML definitions.

Embedding XMP Bridges the Divide

XMP has a few features, which aid in this exercise. The displayed field name does not have to match the internal name in the XMP definition, so in one subset schema you can add a display name that is familiar to those users while maintaining the standard name internally in the XMP. In other subset schemas you can use the standard XMP name as the display name. This also aids in implementing XMP across multi-lingual systems.

The feature of embedding XMP metadata into files and images also aids in implementation across systems and departments. As these files are shared (between users or systems) the metadata travels with the file. This provides one method of integrating data as well as enforcing consistency. The trick to using XMP metadata to implement your enterprise taxonomy and structured vocabulary is to make the data collection as user friendly as possible and to collect the data at its origin; the first user who is aware of the value for the metadata field needs to be the one to enter it. By creating subset schemas with required fields you can ensure data is collected to drive your workflows and processes.

Now You Can Get On the Same Page

Getting everyone on the same page and calling things by the same name is essential to optimizing your systems’ integration and your business processes. Using Adobe’s XMP as a starting point allows incremental progress to be made while having a defined long-term outcome; have your internal XML resources investigate using XMP as a vehicle to improving your communications and workflows.

Lydia Mageean Lydia Mageean has been part of the WhichPLM team for eight years now. She has a creative and media background, and is responsible for maintaining and updating our website content, liaising with advertisers, working on special projects like our PLM Project Pack, or our Annual Publications, and more.Joining mid-2013 as our Online Editor, she has since become WhichPLM’s Editor. In addition to taking on writing and interviewing responsibilities, Lydia has also become the primary point of contact for news, events, features and other aspects of our ever-growing online content library and tools.