Home Search
Consona Search vs. Enterprise Search Appliances

I am frequently asked about our search technology in Consona Knowledge Management and how it is differentiated from other competing products or categories of products in the market. Lately, in particular I’ve been asked to distinguish between our search and the search found in enterprise search appliances.  I used to try and explain intricate nuances of search algorithms and highlight some of the most differentiating protected intellectual property that we hold.  But this actually has had relatively less success then using contextual examples to explain the difference.

My latest attempts are to explain that Internet search and enterprise search are designed to find an answer to the question rather than the answer to the question.  Relatively simple concept with a lot of technological differences to the implementation of search technology.  What I am trying to imply is that that the two categories of search have a completely different goal, so their composition is completely different. 
 
Consider the example of an online car shopping experience. I could go to a search engine and type “BMW Z4 2011 Black.” I’ll receive a response including everything on the web that refers to that make, model, color and year including a car show site, YouTube videos, car dealers all over the country, etc. Or, I can go straight to AutoTrader.com put in the same information, and it will present me with a few options to choose from.  The focused search at AutoTrader can give me specific results based on my intent and further asks for other specifics such as my location and options to refine my results.

I have also been referring the following excerpt from the KCS v5 Practices Guide.*  In my opinion this explanation does probably the best job I have seen to date explaining the differences between the two.  I hope you enjoy this and with this information can more easily understand some of the differences between (good) knowledge management search and enterprise or Internet search.

“Search” for Support: What’s Different

The nature of human languages—and especially English—makes search challenging in any domain. For example, if we say “stock,” are we asking about a financial instrument, part of a gun, or a soup base? And is “running in to the bank” a common errand, or a navigational error in a kayak? Humans unconsciously disambiguate competing meanings based on context, but context is hard to program into machines.

Internet search engines like Google, Bing, and Yahoo! leverage the structure of the web itself, and the behavior of users, to increase relevance. With over 100 million websites and hundreds of millions of users searching every day, Internet search has an almost inconceivably large dataset to mine. Unfortunately, KCS knowledge bases have neither the web’s structure nor its volume of use, so Internet search approaches don’t work well for them. We often hear “can’t search work just like Google?” –because support knowledge bases do not have the volume of activity our answer is “no.”

If search is hard in general, search for support is doubly so. Users know some symptoms of their problem, and they may know something about when and where the problem occurs, but they don’t really know the answer they’re looking for. This is the basis for the Consortium’s contention that search should look first in Problem and Environment sections, at least for articles using the KCS proposed structure. The search technology also needs to support people who know something about the resolution or cause of an issue and allow them the option to search the Resolution and Cause fields.

The good news is, support domains are constrained. People will ask about anything in Internet search, but in KCS knowledge bases, they’re typically asking about exceptions that occur with a defined set of products and services. This simplifies the “stock” problem, if technology knows how to take advantage of it.

Key Considerations for Search Technology

The sophistication of search technology required for a sustainable KCS implementation varies based on the size of our knowledge base, the complexity of the domain (i.e., how subtle can the nuances be between non-duplicate content), the technical astuteness and the persistence of our users. Generally speaking, very simple technology often suffices for a knowledge base of fewer than 1000 basic articles, while collections over 100,000 articles in a deeply technical subject area strain the limits of current technology.

Here are some considerations for selecting search technology:

  • Is it important to be able to search other resources at the same time as the knowledge base? In other words, should a single search return results from documentation, community forums, or defects as well?
  • Will a simple keyword search suffice, or do we need to support synonyms, concept- based search, or does the size and complexity of our domain require even more advanced approaches to finding results?
  • How much of a burden does the search technology impose on the content developer who is capturing, structuring, and improving content? Must they enter careful metadata or keyword fields, or will search handle the content automatically? Can knowledge be captured “at the speed of conversation?
  • What reports are available to drive B-loop content development, especially to fill customer self-service gaps?
  • What options does the KCS program team, or another team, have to tune and refine the search experience? (See below.) What reports are available to help them do this?

* KCS was developed by the Consortium for Service Innovation, http://www.serviceinnovation.org. Visit their website for the entire KCS v5 Practices Guide and other KCS Resources.