Is Suspect Product Data the Elephant in the Search-and-Discover Room?

Are we ignoring a big problem?

“Inconsistent,” “inaccurate” and “incomplete” all describe what we call suspect product data. For decision-making that enables engineering productivity, design tool users must be able to trust product data revealed by a search-and-discover solution (SDS).

In this article, I’ll address how to resolve the suspect issue.

Enhancing the Original Concept of SDS with Findability

Let’s start with search-and-discover functions. Assume a user is searching for a part that already exists. After the user exercises a search function with a combination of keywords and Boolean logic, an SDS displays numerous alternatives. Usually, users will have to exercise filtering to narrow down the suspects to a workable number.

Starting a search. (Image courtesy of Bourke Consulting Associates.)

A user wants to narrow the options quickly to explore as few choices as possible—with full confidence and without the frustrations that could sabotage personal productivity. Users assume the data exists, but in what condition?

As I’ve emphasized before, an SDS tool with access to a company’s PLM and ERP systems will reveal product data without regard to the quality of the data.

A key criterion for an effective system is findability. We will define this as locating exactly what’s needed, not just searching and discovering multiple choices. Thus, the degree of findability is a measure of the quality of an SDS implementation.

A simple hierarchy. (Image courtesy of CIMdata.)

Findability requires a viable system for classification hierarchy, attribute creation and maintenance that allows specific parametric identifying of the needed product data.

Ranges of alternatives to develop a system are open to evaluation: manual to computer-aided. A manual approach may be feasible in some situations, but computer aids are available, including those listed at the end of this article.

For development input, numerous classification systems can be tapped, such as the United Nations Standard Products and Services Code. With computer aids, data cleansing is an inherent activity in the process of creating a classification/attribute system that meets a company’s specific requirements.

Evaluating and Implementing an SDS with Findability Capabilities

Some critical considerations arise. For would-be SDS implementers, the following should start a healthy discussion.

Overcoming reluctance to address the issues is clearly one. The causes could be:

Lacking belief in the extent of the problem;
Not realizing the value of solving the problem;
Fearing the magnitude of an effort.

Another factor to consider is whether deploying an SDS can achieve the expected benefits, fully or partially. Can a company achieve optimum or only partial results from an SDS without resolving the suspect condition of product metadata that may currently exist?

Closely related are decisions that involve which activities come first: data cleansing or implementing an SDS. One viewpoint claims that SDS first will help reveal the quality and availability of correct data, hence sharpening awareness to overcome reluctance.

Certainly, there are factors with no obvious answers. These are, in other words, situational—the classic, “it depends.”

Final Perspectives and Next Steps

An SDS coupled with findability capabilities provide opportunities to gain C-level attractive benefits:

Reducing time-to-market;
Increasing engineering productivity;
Lowering part costs and more—if the product data is trustworthy.

A findability initiative will send the annoying elephant of suspect product data out of the room.

Further Resources

IHS offers a broad range of products and services. For an overview, see Content Services.

Here are three more sources of data cleansing products and services.