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.

  • Ross Bernheim

    Search is dependent on the data being searched. An organized part numbering system can help. But of greater assistance are consistent and thorough part naming and description fields.

    As Tom Lehrer said, “Life is like a sewer. What you get out of it depends on what you put into it!” Do you have the fields for what you want to search for and are you diligent in filling them as you enter new parts and do you go back and make sure the older parts are also fully entered?

    When things aren’t in the PLM database, we end up trying to narrow our search and that may be the best we can do. Then we have to slog through additional documentation such as data sheets or drawings.

    Better search won’t find what isn’t there.

    • Thanks for the comments as always, Ross.

      Carefully delineated numbering and part attributes help with today’s current search technologies, for purely objective questions – but we need better technologies going forward to answer the more subjective questions. Imagine Geordi LaForge conversing with the computer on ST:TNG – information assisted problem solving, if you will.

      • Ross Bernheim

        Star Trek’s computers had all knowledge at their beck and call. No matter how smart the search engine, it needs all knowledge to work well. Most PLM databases are far from complete and what data is there usually is not consistent.

        If you call a coil an inductor or a choke, sill the search engine know that they are all the same thing? How about a valve or tube?

        We have a lot of scrubbing of data and making things consistent before we can begin to think about handing the data to the artificial intelligence enhanced search engines.