Choosing an Organizational Search Engine
- Meirav Barsadeh
- Aug 1, 2007
- 4 min read
Recent forecasts of knowledge management trends give smart search engines a place of honor. Search products have existed in organizations for decades. Moreover, looking internally within the organization, many organizations have more than one search engine: a search engine that is part of the portal, a personal search engine that people install on their desktops, a search engine integrated with document management tools, and more.
The growing focus on search tools in general and search engines in particular is neither fashionable nor random. The number of information systems is growing; the amount of soft content repositories (documents and more) is increasing; the volume of content in both is intensifying. We users feel like we are in a vast ocean trying to keep our heads above water and not drown. Floating, swimming, and moving forward is a wishful thought in the context of using data, information, and knowledge, which is not always realistic.
Against this background, search in general and search engines in particular (which can be operated from multiple systems and repositories in combination) become a central component in knowledge management technology: a component that will allow us to cope with the flood alongside focused portals and sites, and deliver the right content to the right user in the right context.
Today's Approach to Purchasing a Search Engine
Today, it's common to purchase a search engine. It is not a closed tool that can be operated out of the box, but an engine that can be integrated into the portal and other systems and repositories and whose operation can be influenced (which will be covered in a separate review). One of the central problems in purchasing such an engine is the excess of features that numerous vendors shower upon us.
It's very easy to prepare a long shopping list of required features that address all the capabilities we've seen from various vendors. Still, such a strategy may not necessarily bring us closer to selecting the optimal engine for the organization (and, of course, at an optimal price). It's important to understand that in the search field, different families of products provide different, complementary functionality and don't necessarily compete with each other (although sometimes there is partial overlap, which makes things even more confusing).
In such an environment, our recommendation is to simplify the evaluation by focusing on it and looking at four main groups of features:
Threshold requirements;
Basic requirements;
Infrastructure requirements;
And additional requirements.
Threshold requirements are those that, if the product doesn't meet them, it is not a search engine. These include the ability to perform a search, view results, navigate between them, and focus on the details of a single result (etc.). These results should not be scored in the evaluation but only verified to exist in the proposed tools to determine if they are worthy of evaluation at all.
Basic Requirements
Basic requirements are those that turn a search engine into a "good" engine. In truth, there are only three features (everything else is derived from these): a simple, convenient, and accurate engine. This perspective greatly simplifies the actual evaluation.
Infrastructure Requirements
Infrastructure requirements stem from the engine being a software product, not necessarily a search engine: the ability to manage users, connect to information systems and content repositories (20:80), performance and upgrade capability, permission management, and architecture. As knowledge management experts, we recommend leaving this testing component to information systems professionals and not interfering with it at all, as they know their craft just as we know ours. Regarding connections to information systems and content repositories, it's highly recommended that a POC (Proof Of Concept) be performed to verify that the connection is indeed feasible in our organization.
Additional Requirements
Additional requirements are those that transform a good search engine into an "advanced" engine. Here, too, it's easy to get overwhelmed. The tools offer a wide range of capabilities, and it's our job to stand firm. Our recommendation is to decide, based on a workshop with typical users and unique users, what the three main needs are required for us and request only those. The tools may give us more, but this will be considered extra and will not affect the price or the ability to focus on the truly important needs of our organization, which we need to verify and enable. The temptation to ask for more is very great. Remember that technologies are always ahead of organizational absorption capacity, so implementing everything is not recommended.
And Regarding the Future?
Engines are constantly improving. Suppose we choose a good product from a good company (yes, we haven't forgotten about the company and service). In that case, we'll also get the rest later without diverting the current selection to sexy but not necessarily required places.
The name of the game? Simplifying the selection process.
We wish you success!
Comments