Search & Discover Solutions: A Google-Like Experience?
Dick Bourke posted on June 17, 2014 |
Users expect a familiar interface to their product development search tools.

Prospective Search & Discover ("SDS") users have already had their expectations set by their experiences using Google; they often say, "Give me a Google-like experience." But is that an appropriate frame of reference to begin evaluating and selecting an SDS?

In an earlier column, I identified the need to set expectations for selecting and implementing an internal SDS. That article cautioned that Google experiences don't necessarily fit the search needs for research and product development.


Search & Discover Solutions have a Different Structure than Google
Designers taking the small step to find information about an existing part rather than designing a new one can certainly achieve value.  However, the greater value is to exploit the same product data to accelerate part/product line rationalization and standardization activities internal to the company, and to use them in a company's global supply network.

To help users accomplish these goals, SDS must catalog two types of product data that I identified in an earlier column.

1. Structured – data presented in a defined data model, usually in a relational database. Structured data is ready for seamless integration into a database or well-structured file format, for example, XML, classification systems and attribute tables.

2. Unstructured – data not pre-defined, usually heavily text oriented, found in numerous documents and files, such as MS Word, email, images and, of course, CAD files.


A commonly accepted axiom is that unstructured data is more than 80% of a company's data, which should encourage analysis of its cost effects.

The sheer amount of unstructured data can be overwhelming, strongly suggesting administrative programs for improved searching, i.e., converting unstructured data to structured data. Then searching content in structured databases can be done with more precision; the time to find requested data is relatively faster.

What's needed is analytic power to merge structured and unstructured data into one view, a task Google can do. Without an SDS, a company could replicate what Google does, using the same methodology as Google – but the cost would be huge. Google, however, achieves the perception of a structured view by using complex algorithms and millions of searches to present a structured view when no predefined structured view actually exists. Besides, there is simply not enough scale in a typical company to replicate this Google-like experience.


On the other hand, fortunately, a comprehensive SDS can provide the analytic power to convert unstructured data to structured data, and at a more reasonable cost than the Google alternative. Creating a structure up front reduces costs.

And structure is the basis for developing a common language called a classification system. It assigns product data into categories to provide the context for searches on fit, form and function – regardless of usage.

A well-defined classification scheme allows finding attributes and their properties, such as geometric characteristics and performance criteria about items the company makes or buys.

Once detailed classification definitions and sufficient attributes are in place, searches are transformed into "finds." Users find / discover – exactly what they are looking for, reducing product development times, costs and risks. 


Preventing a user revolt against SDS
If a company's SDS experience is discouraging, design personnel may at times select and procure parts using Google. This action should be unnecessary – if the company's SDS allows adequate searching supported with a classification scheme for attributes that provides supplier qualification information.

To encourage use of a company's SDS, personalization of the User Interface, including contextual awareness of the user's role – a capability not found with Google – is a critical requirement when implementing an SDS.

What's more, since Google-like experiences are common, users of an SDS may revolt – unless they see speed, intuitiveness and ease of use.

Prior to selecting an SDS, though, potential users can discern "experiences" with several SDSs by participating in interactive demos. Even better is downloading trial versions for dynamic testing. This step is highly recommended, but short of that action, look at some static screen shots provided by SDS vendors for a previous column.

In striking contrast to Google, a company's SDS must identify and define specific requirements for searching and discovering product data, and using it throughout the company and its global supply network.

Many significant SDS features that provide capabilities over and beyond Google are essential, including data structure administration (a key theme in this discussion), relevancy algorithms, security, connectors and more.


Dana Nickerson, President of Plural Technology was a great help in developing the content in this article.  For more information about developing classification, attributes, and search and find, contact Dana at

Recommended For You