Contact us

Contact ISYS Enterprise Search Software in the United States  Americas: (800) 992-4797

ISYS Australia Intranet Search  Australia: +61 2 8078 1100

Contact ISYS UK Search Solutions  UK: +44 (0) 1244 313216

Send us a message »

Selecting an Intranet Search Engine

INTRODUCTION


An effective search tool on an intranet can make an enormous difference to its usability. In fact, usability expert Jakob Nielsen found that “Poor search was the greatest single cause of reduced
usability across intranets”1 A good search engine ensures that users find what they're looking for, first time, regardless of the format or location of the information. This means that a wide variety of
information can be effectively dispersed and made available to staff, without the need for complex navigation systems or filing conventions.


Most intranets evolve over time, and search functionality need not be a daunting task. A search tool can be implemented quickly, and then refined as the intranet grows and the needs of the
organization change. Importantly, a flexible search engine that is cost-effective and expands to suit your growing requirements can be a much better investment than a cheap product with no
ability to scale or an expensive solution where the majority of its functionality is wasted.


It is important to recognize that every intranet is different, with its own objectives, requirements and environment. This document is designed to guide you through the process of selecting an
intranet search engine, by addressing in turn a range of key variables that need to be considered. You can use the 12-step checklist at the end as a template for defining your own requirements
and evaluating vendors. The following topics are covered:

 

1. The Basics - Objectives
2. Data Sources & File Types
3. Technology Environment
4. Features
5. Installation and Maintenance
6. Pricing Structure
7. Vendor Credentials

 

1. THE BASICS - OBJECTIVES

A good start to understanding what you need from your intranet search engine is to firstly understand the role of the intranet for your organization. What is the objective of the intranet? Is it
to provide human resources information to staff? To provide information to your help desk? Or to support the sales team? Perhaps the intranet is designed to meet a number of different
objectives. Once these are clearly defined, you can begin to determine how a search engine can best add value. The functionality you require from a search engine will depend on your intranet objectives. Keeping these in mind, the following sections of this document outline some of the issues that you need to consider.

 

2. DATA SOURCES & FILE TYPES


Once you have your objectives clearly defined, you can work out what type of file formats and data sources your search engine will need to support. List out every file type used in creating the
information that you want to share on your intranet. These usually fall into one of three categories:

 

  • Unstructured formats are file formats that contain primarily text-based information. These include text files, word processor files, PDFs, emails and formats used to create most documents. There is no real structure to these file formats and few relationships exist between elements within them.
  • Semi-structured formats are file formats that contain a mixture of text-based and databased information, with a basic structure. These include file types such as HTML, spreadsheets, XML. There may be relationships between elements within these files, however they are not as rigidly defined as they are in structured formats, and there may be sections of textual information where no structure exists.
  • Structured formats are file formats where the information is contained in a well-defined structure, such as a relational database. Many enterprise systems have a structured architecture, such as ERP and CRM systems, as well as many legacy databases.


For example, you may want to start your search engine implementation by simply making available all of the HTML content on your intranet. Then you may decide to include PDF and word
documents. Eventually, you may want to provide access to your customer database or to XML data created in other systems. Your intranet search engine needs to be able to support the full
spectrum of file types that you require, even in multiple languages, if that is a concern for your organization.


In addition, you should consider how many files will be in the intranet data repository. This can affect search engine performance, and may impact the price you are ultimately charged, since
many search engines are priced according to the number of documents indexed. Be careful in such situations, as any expansion in the size of the intranet can push the search engine into the
next pricing bracket, thereby attracting additional charges from the search engine vendor.


Think about publishing scope – depending on the sources of the information you want to make available via your intranet, you may need a search engine that provides umbrella functionality
over many different data sources. Some search engines are designed for specific data types, such as structured data, or are limited to single data repositories, such as search engines within
content management systems. If you need to incorporate legacy data into your intranet, you need a search engine that can support this.


Finally, consider whether you want to incorporate external data sources into your intranet. Spidering functionality enables external websites to be integrated into your intranet data
repository. You can include the websites of suppliers or partners, for example, into your intranet search functionality, so that staff can search that content directly from the intranet.

 

3. TECHNOLOGY ENVIRONMENT


Your options will be determined by your internal technology infrastructure. List out all of the systems and software that will interact with the intranet search engine. These include the intranet
web server operating system and application software, your networking software and architecture, and your file system security environment. Think about any other systems that need
to integrate with the intranet search, such as content management systems, ERP, CMS, email servers or legacy systems.

 

4. FEATURES


For most intranets, there will be a wide spectrum of users, from very basic all the way through to highly technical power users. The search function needs to cater for all of these people, with a
simple yet powerful interface that provides options for advanced searching if required. There should be three steps to the search process, and a range of features work to streamline
each of these steps; the important ones are described below. But remember, you may have specific objectives for your intranet that require certain features rather than others and you should
keep this in mind when discussing features with vendors – which ones do you really need for your specific application?


The three steps in the search process are (1) Entering the Query, or asking the initial question, (2) Getting the Search Results, or receiving the list of found documents back from the search
engine, and (3) Finding the Right Answer, or examining and refining the search results to find the information you were looking for.

 

Step 1: Entering the Query. When a user enters their query, they should have the option to do this using a natural language approach; that is, by simply entering the question as they would ask
it. Such as “What is our returns policy on refrigerators?” There should also be the option to build queries using Boolean operators, so that users who know exactly what they want can be
extremely specific with their search. For example “returns~ within 10 words of refrigerator but not freezer”. Check the user interface to make sure it is intuitive for basic users, but also provides
powerful advanced search functionality for more experienced users.


A good search engine should enable you to group logical chunks of information together so that searches can be conducted on specific areas of interest. For example, an engineer may only be
interested in searching technical documentation and might not want to search the HR policies that are also available on the intranet. The search engine needs to be able to group information
separately to enable this to happen.


There should also be tools such as thesaurus functionality, where the search engine picks up common words with similar meanings, and synonyms, a thesaurus that can be custom-defined to
include terms relevant to your particular organization. Spelling errors should be catered for with a‘sounds like’ function, which enables users to find other words that sound similar to the one that
they are typing. This compensates not only for spelling errors when the user enters the query, but also for errors within the data itself, ensuring that such data is not lost forevermore.

 

Step 2: Getting the Search Results. If you have very specifically defined data, such as legal documents, a high degree of precision may be required to identify and return specific information.
In other situations, however, it may be better to return a wider range of documents for a given query. The accuracy you require depends on the role of the search engine and the nature of the
data.

If you want to make available a large volume of data on your intranet, providing a fast search engine is important. Otherwise users find it frustrating to wait for the search engine to bring back
the search results. With smaller amounts of data this will be less of a concern; it all depends on the volume of data that you intend to make available on the intranet.


Any good search engine should use some form of intelligent relevancy determination. This is where the search engine, based on the query entered, makes a judgement about which results
will be the most relevant, and ranks them accordingly.

 

Step 3: Finding the Right Answer. The search process doesn’t stop once the user receives the list of results. They then need to refine and manipulate the results list until they find exactly what
they were looking for. There are many features that can assist in this task, some of which include:

 

  • Document summary information – the display of useful document attributes such as file type, file size, date last changed, relevancy rating and the number of ‘hits’ (key words
    found) in the document. The display of an extract of the document, say several lines above and below the first hit, is helpful for determining the context in which the document
    has been returned.
  • Re-sorting – the ability to re-sort the results list using different criteria, such as title, number of hits, relevancy, date changed, file type or any other criteria that makes sense
    for your organization.
  • Hit-to-hit navigation – the provision of navigation buttons enabling users to go directly to the first hit in the returned document, and thereon to the next or previous hit as required.
    This means users avoid having to read through pages and pages of document before finding the relevant section, making it much more efficient.
  • Hit highlighting – a familiar concept from searching the web, hit highlighting is when the key words, or ‘hits’, in a document, are highlighted in a different colour. This feature is
    often not available in an intranet search engine, but it really should be, as combined with hit-to-hit navigation it enables users to immediately see the relevant sections of the
    document.
  • Fast preview – the ability to preview large non-HTML documents in a basic HTML format, without the need for downloading the whole document. This function enables
    users to view a few lines above and below each hit, and then to expand up or down to continue reading.
  • Search within – the ability to search within the current set of results, to further narrow them.


Although just some of the features available in intranet search engines, these are the main features required to ensure that users have the best overall experience. Others that may be
relevant to your organization might include intelligent agents that automatically advise users when relevant content appears in the data repository, or the ability to save or export search
results. If you have a specific need, you should discuss it with your potential vendor. If they don’t have a ready-made feature to solve your problem, they’ll probably have software tools to enable custom requirements to be developed.

 

5. INSTALLATION AND MAINTENANCE


The process required to install and maintain the search engine software can have an enormous impact on the overall cost and ROI of your project.

  • Does the search engine require significant data preparation and re-location, or can it index the information where it currently resides?
  • Does the system have to be customized and will it require external systems integration work to install? What will all this cost?
  • What happens if you want to modify or expand the system – can you do this in-house using staff with general IT skills or will you need to call in a specialist?
  • What ongoing maintenance of the system is required, and what type of person is required to undertake this maintenance?


All of these are important considerations when it comes to investing in search engine software, and ideally you should look for a system that minimizes both the up-front installation cost as well
as the ongoing maintenance. There are certain types of systems that legitimately require a lot of IT effort in order to maintain their usefulness, however the standard intranet search engine should
not fall into this category.

6. PRICING STRUCTURE


Pricing structures vary between vendors. Some charge according to the number of documents indexed, while others charge according to the number of end users. Consider carefully how you
think your system may expand over time, as increases in documents and/or users can incur additional charges. Some vendors use a rental type model, where the license fee paid is only
valid for a year or two years. At the end of the period the fee is payable again. Others charge a once-off fee and only charge for upgrades to new versions.


Most vendors offer some type of maintenance – make sure to ask how much this will cost, and how it will change over the life of your project.


7. VENDOR CREDENTIALS


As with all purchases, it’s critical to ensure that your vendor is reputable. Check that they have been in operation for a reasonable length of time, and find out how mature their particular offering
is. Early generations of software are likely to be less tested and less featureful than software that has been refined over many years.


Establish whether the intranet search engine product range is a priority for the vendor. If the vendor is primarily focused on web search rather than enterprise search, their methodologies are
likely to have a very different focus and their software will be geared towards web content (HTML, PDF etc) rather than enterprise content, which can span a diverse range of formats. Make sure
the product will continue to receive ongoing development and technical support. Ensure the vendor offers a help desk for technical support.


Importantly, ask the vendor to provide case studies and examples of other intranet implementations for which their product has been used. Ask for references so you can talk to other organizations that have used the software.

 

SUMMARY


In this document we have provided some guidelines for evaluating and selecting an intranet search engine. As with all software, knowing what you’re trying to achieve and talking to a number of different vendors is a good start. The massive benefits that can be obtained from getting your intranet search functionality right from the start are worth the effort of some upfront research. You can use the checklist at the end of this document to specify your requirements and compare these with different vendor offerings. Good luck!

Enterprise Search and Intranets Download Intranet and Search whitepaper here.

Contact us today to receive more information or download our software by clicking here.

 

Name:
Company:
Telephone Number:
Email Address: