These Aren’t the PLM Search Engines You’re Looking For…

Image courtesy JD Hancock

Image courtesy JD Hancock

One of the central axioms of Product Lifecycle Management is information re-use. Re-use prevents re-invented wheels by capitalizing on product knowledge that predates your particular problem. Provided you find what you’re looking for, of course. That’s where the trouble starts. Most of us know that PLM search is often about as fun as a late afternoon dip in a Sarlac pit. It’s never long before someone begins to lament about the Googlization (that is so not a word) of PLM search, a passing thought usually birthed in the throes of an intense thirty-minute session unearthing the latest funny cat videos from the depths of the interwebs. Why can’t uncovering part information be as easy as finding your favorite quotes from Firefly? There have been many attempts to emulate just that, but they may be missing the point. These aren’t the search engines you’re looking for.

Rahul Deshpande posed some very relevant questions in a follow-up Is Part Number Really Relevant to my GrabCAD article on the Intelligent-Part Number Debate, specifically pointing out that regardless of your allegiances in that particular thought war, the PLM search reality amounts to the same level of crapulence. Intelligent or not, most PLM searches are still overwhelming reliant on someone diligently typing out a part number. If anyone happens to remember them, that is. If we’re mostly looking for long-winded part numbers, many of us can and do give up. Rahul spells out the ultimate problem in the following passage:

“To find part of reuse, user need to remember lot of information because PLM still has a cumbersome search for part, search enforces user to enter lot of information related to part and different attributes. User finds it easy to recreate a part instead of reusing it, and that is a big loss of ROI for PLM. Imagine a scenario where Google would have asked us to type exact link name to get to specified result. What would have been life if search would have been that cumbersome? Why can’t we have a Google like search for PLM?”

There it is again. Google-like search. But let’s think about this for a little bit, shall we? Google is an imprecise search on a universally understood subject: i.e. protocol droids, irreverent PLM bloggers, pork sausage. With graphing technology, the basic capability is extended to quickly respond to concise, objective questions such as: What’s the weather in Dallas? This capability is built by systematically graphing relationships to data that people use frequently. However, stray just a little from the path of what’s been graphed and you’re squarely back in the realm of subjective results, i.e.: What’s the average rainfall in Kennebunkport? What did Katy Perry eat for Breakfast? What is the air speed velocity of an unladen European swallow?

Some variations have been tried including supplementing Google-esque contextual search to get you in the ballpark and then leveraging a progressively exhausting series of attributes to narrow your results. These attributes and their structure are based on pre-baked ontologies and classifications, painfully trying to understand how people are going to be looking for information. So you might search for a bracket in a PLM system generically, then filter on material, or use, or weight, or a bunch of other parameters. This takes absolutely forever, and still doesn’t get you the droids you are looking for. Technologies like geometric search in Geolus, or geospatial search in SOLR are interesting in of themselves and certainly a step in the right direction, but we still have a long way to go in order to solve the PLM search dilemma.

The ultimate PLM search must be contextual to the design, and that means understanding geometry, environment, and that desired solutions are likely iterative and not absolute. One of the commenters from an old, but still very relevant article by Oleg Shilovitsky Why PLM Need to Learn About Google Knowledge Graph rings true here:

“PLM needs some completely new paradigm to drive informations and knowledge in a way that makes sense for the user and not for the database expert.”

We have a model to strive for thanks to science fiction, including probably half of all Star Trek episodes, where people solve problems by carrying on a conversation with a computer.  What’s the key difference here? The “search” is not a single input, or a search with pre-defined attribute filters, but a conversation of linked searches, each in the context of the prior search and the overall context of the problem.   There is no pre-defined end path – because the problem resolution and the search are feeding each other. The interface is both iterative and conversational serving more the purpose of an assistant than a user-operated search.  We are now at the stage of technology where realizing this kind of interaction is within reach – we’re already primitively talking to our phones. So next time you lament over the primitive effectiveness of PLM search and the overreliance on part numbers – don’t think about Google. Think about the next step. You can go about your business. Move along.