Don't miss Data Summit, May 22-23. Learn about big data, AI, machine learning, cognitive computing, blockchain, and more.

The ABCs of Search
Five Steps for Creating and Implementing a Search Strategy

This article is part of the Best Practices White Paper Search/Information Access [May 2009]
Page 1 of 2 next >>

   Bookmark and Share

"I wish I could find information to do my job better." At first it seems like a simple request. But as you begin to peel back the layers of this onion, you quickly see how difficult it is: Develop a search strategy. Determine which data needs to be searched. Figure out how to respect security schemes. Choose a search partner. Ensure that search is continually relevant for users.

By following the steps that follow, you will not only improve information access for your organization, but deliver a solution that helps users discover the information they need to do their jobs as well as share their knowledge across the organization.

Assessing the need for enterprise search. At the end of the day, search is a no-brainer, right? Any organization can benefit from search. But to really capitalize on search’s inherent value, organizations need to identify exactly what they want search to do for them.

Organizations typically have one of three reasons to look at search in the first place. The first reason is that they have no search at all in their organization. Don’t laugh. There are still a lot of groups that lack even basic search. The second reason is an organization with multiple data repositories each with its own search or none at all. In other words, information is all over the place and no one knows how to find anything. The third reason is simply poor existing search. In most organizations, people cannot find what they are looking for unless they have a very strong search solution.

After you have determined why you need search, you need to consider both your target users as well as your target content. Is the typical user going to be someone inside your organization or are you targeting visitors to your website? Or is it both? What kind of content will you be searching and where does that data reside? If you are simply searching through public Web pages, a simple appliance may be the right fit. But if you are crawling confidential files that only certain employees should have access to, then a platform built to respect your security schemas probably makes more sense.

As you answer these questions, begin drafting use cases. Why will people be using your search and what will they expect to find?

Building the case. The value of search seems pretty obvious: you can find stuff easier. But that kind of argument doesn’t often fly with CIOs or other corporate decision makers faced with escalating costs, shrinking budgets and conflicting priorities. Without a solid business justification for search—usually with some kind of return on investment—the project will likely never get off of the ground.

It’s doubtful that search, by itself, is on most CIOs’ top 10 lists. And trying to put a hard-dollar figure on the benefits of search—including increased employee efficiency and greater customer satisfaction—may not resonate to the budget-conscious executive. Instead, finding a way to tie a search initiative into a CIO’s existing priority list may be the most effective way to get search funded.

For example, fostering collaboration among employees is one of the top executive priorities these days. The right search technology can enable employees to collaborate through tagging, annotating, rating and sharing search results. By implementing search, you could end up killing two birds with one stone.

As you compose your business case, don’t forget to mention to your CIO that there are few IT solutions that can potentially affect everyone in your organization—from interns all the way up to the CEO. Again, though, it comes down to choosing the right vendor with the enabling technology.

Choosing the right search partner. The most critical step in the process is choosing the right technology partner. Even though the market has consolidated a bit recently, there are still enough options to confuse the average buyer.

The mistake that organizations most often make is to create a laundry list of features and demand that the vendor accommodate each of them. It goes back to assessing your needs and determining the link between your content and your users. Ask questions like:

  • How critical is security;
  • How critical is the user experience;
  • What repositories do you want access to; and
  • What does relevancy mean to your organization?

Once you have answered those questions, write a concise request for proposals asking vendors how they approach each of these issues. Where do you find those vendors? If you have a relationship with research firms such as Gartner or Forrester, try talking to their analysts or reading their reports on information access. You can easily identify the leaders in their reports.

After you have evaluated the RFP responses, you need to create a short list of companies. At a minimum, you’ll need to see a demonstration of their solutions as well as a list of references. Some organizations will want a full proof of concept (POC) performed using their own data. It’s a reasonable step, but keep in mind that most vendors will ask for some remuneration to offset their time and effort for the project.

Be specific in your POC. Ask potential partners specifically how they will solve your problems—make them demonstrate it for you. And make sure they let you get your hands on the product—do not allow the consultant to do all the work. Make sure you will feel comfortable administering the system when no one is onsite with you.

You may also want to discuss each vendor’s product roadmap. What new functionality will be available in the next 12 to 36 months? How often is a new release issued? How do those updates match your future—or current—needs? This could give you the opportunity to align your search strategy with your new search partner’s.

As you evaluate each vendor, remember to give more weight to the areas that are critical to your search objectives. For example, you may find that one vendor excels at search on mobile devices and the other doesn’t even offer it. But if mobile search isn’t a priority, it may not make sense to pay more for the first vendor’s solution.

At the end of the day, though, your decision may come down to intangibles. Remember, you are looking for a long-term relationship with your search partner. What kind of impression did you get from the salespeople and executives you met during the sales cycle? Were the technical people who worked on the POC easy to work with, or did they act like they knew everything and weren’t willing to compromise? Did you try calling into support? If so, were they responsive and did their answer help you? While it’s hard to quantify those qualities, they may make the difference in a successful vendor relationship.

Deploying enterprise search. Now that you have selected a vendor, the real pressure is on. It’s time to deploy the solution in a real-life environment. The key to a successful deployment is to get an initial solution up and running quickly—one that will have the greatest reach across your organization. After the selection process, many administrators face one of two pitfalls: The first is underestimating the complexity of search, resulting in promises to upper management that cannot be met. The second is trying to solve all search problems at once, instead of deploying in phases.

If you take the time to identify the key success criteria early and select a vendor that can best deliver against those sets of criteria, then you should be able to introduce a search deployment within one to two months. If you use a POC as part of your selection process, you should be able to reuse your POC work.

To deliver results quickly, you need to identify which data sources are most critical. If you are looking to deploy search on your organization’s intranet, it might be your document management system along with file shares. For others it might be email and their wiki system. For those creating a public-facing website, it could be your product catalog and database. Others might need to expose third-party information. Regardless of your specific needs, choose one to three data sources that are most critical and build the security framework you need to search those sources now—and others in the future.

Page 1 of 2 next >>

Search KMWorld


Buyers' Guide
Learn More in the Buyers' Guide!