A discussion of the FAST search engine which is now part of SharePoint Portal Server. We explore the business opportunities in both employee-facing and customer-facing scenarios and discuss the differences in the technology from the perspective of readers that are already familiar with SharePoint.
Home » What We're Thinking » FAST SharePoint Search
Your employees can't remember all of the information sources inside your company, much less keep track of the search interfaces that exist. Each of the following system likely has its own search interface: SAP for customer data, Ariba for expense data, Siebel for contracts, the E: drive for sales related information, http://www.yourintranet.com to look up product info, unless it is related to the US division, in which case you should visit http://www.us-yourintranet.com. Information about Project X is in one SharePoint site, but if you need to find out that project status, it is tracked in the EPM tool. Reports are...where are reports again?
Today's approach: make finding the right interface it the employees' problem, and pay the price through higher costs (training, back office, re-work, turnover), lower customer satisfaction. Why? Because there really hasn't been a better option until the maturity of search engines like FAST, Autonomy, and Endeca.
This is exactly how Google, Bing, and Yahoo handle it. You don't see a dropdown box of tens of thousands of options before you can type in a set search terms, do you?
Referring back to a typical Enterprise Search implementation in my previous post, let's change up the user experience to something like this:
A couple of important points:
The search implementation should use this information to narrow down the result set from potentially hundreds of millions to a much smaller, manageable set, and then it should provide an intuitive experience for the employee to help guide the engine to the information they seek. Think ‘Best Buy', but for your corporate knowledge.
What might that search results experience look like? Let's look at that in the next post.
My previous post outlined the problem with the ‘traditional’ approach to search scoping. To explore the problem and a solution that leverages Microsoft FAST search, I’ve invented a fictitious company called Canadian Financial. That gives us some context – it is a bank with multiple geographies, lines of business, languages, and products. There are dozens of internal sites up that provide a massive amount of information required to do your job more effectively, if you can find it.
As an employee at Canadian Financial, this is what you see when you click on the search option on your Intranet:
Does this look familiar? Check out your own internal search implementation. You’ll probably find the common ‘source’ dropdown box lurking. There are two problems with this concept:
The first problem should be pretty evident. How many times have you bothered to select a source? The second problem is more subtle. Sources are defined by the content’s physical location, typically by URL. That immediately assumes that all content in a particular location can be tagged with a few words. Think about your intranet, or even a portion of it. How feasible is it to define all of the locations for training content? How about all content for a particular product? Or language? Then consider combining them: all training content for Canada in English. Not possible…
Pretty primitive, really. Is that the best we can do after 10+ years of search innovation? No. Consider that this problem has been solved already, but in a slightly different way. Hit Best Buy and find all digital cameras currently on sale by Nikon in the 10-11 megapixel range that are blue. Hmm… that was easy:
The above example is driven by FAST.
Why can’t you do this inside the Enterprise? In the next post we’ll explore how Canadian Financial can address this challenge with two concepts:
It is easy to create content. Fire up a Word document and post it, or create a sub-site on your Intranet and add pages. Even creating a new web site isn’t hard anymore – most business users can go through a process to launch one quickly. The benefit: quickly converting corporate knowledge into something that can be consumed by others. The challenge: it is up to the end user to ‘know’ where to find it, and that often doesn’t happen.
There is good news. Today’s search engines make it easy to hook up new sources of content. Check out the solution you have today for internal search and hunt around for a dropdown box of options. There are probably dozens. Each time a new web site comes online internally, the search engine needs to be pointed at it. It probably includes: HR content, news, product information, service information, people directory, manuals & procedures, links to tools, potentially file shares, email, collaboration environments like SharePoint, plus perhaps a Documentum or Interwoven, and likely multiplied by geography, business units, secured content, or all of the above.
The user is faced with two options: 1) choose a source, or 2) search everything. Lets look at each in more detail.
1) Choose a Source – this option requires an employee to know what a three or four word description means, and what kind of content is likely to be included. It also assumes that it is possible to name the content, and that generally a single type is available. As that is often not possible (consider how many different types of content you have on your ‘Intranet’), the sources get redefined to be more granular. The result: many more options to choose from. Realistically end users cannot be expected to hunt through this list to find the right one, which leads to most choosing the second option.
2) Search Everything – This is often the default: search across all content under index and provide a result set. That can include hundreds of thousands of items, and as you get all of your content under index it can easily span millions of entries. This option assumes two things. First, that your search engine can bring back the top 10 relevant results every time based on a few words of input, and second that each result should be displayed in the same format (typically, title, link, preview, plus potentially a date). Do those assumptions seem reasonable?
So, what to do? More on that soon.
If you’re looking for an internal search solution you’ve probably heard the term Enterprise Search kicking around. It generally applies putting in an internal search solution that can broadly index content (file shares, email, SharePoint, etc) and provide a search interface for your employees.
It assumes a few things. First, that the solution applies to all employees. After all, don’t all employees need the ability to search through their knowledge work? Isn’t search just like email? The key flawed assumption: all employees share the same underlying search problem.
I certainly agree from a strategy perspective. An Enterprise Search Strategy can help identify the holistic approach to rolling out and implementing a search solution. That may be where the usefulness of the term ‘Enterprise’ ends.
I think it is more constructive to think of search in the way you currently think of your database platform. Don’t databases require real business applications to be useful to their end users? Would you attempt to justify the purchase of a database without the needs of a specific group of users in mind? Search solutions should be approached the same way – they have a specific set of users in mind, and the solution should be tuned to provide the best search experience possible.
Here is a clear symptom of that problematic assumption: are you having a hard time building a Enterprise Search business case? If the search solution is inexpensive, like a Google Search Appliance or Microsoft Search Server, then a business case isn’t as important and you probably are using the ‘we just need it’ argument to justify the expense. That’s valid. However, if you are spending significantly more on a platform like FAST or Autonomy, you need a solid business case. One of the best ways to accomplish that is to know specifically who the solution is for, and precisely what benefit you’ll drive by deploying it. That concept contradicts the ‘Enterprise’ assumption we often start with.
My suggestion: look for a group of users that share a common knowledge discovery challenge, and work on building a search solution and a business case around them. Look for a group that is large enough to support a business case, but not so large that their job functions diverge and therefore their search needs are too broad. Also, establish an overall Enterprise Search Strategy so this and future search solutions can fit into a cohesive plan.
A few weeks ago my colleague demonstrated a straight forward business case for the use of search technology as the means to reduce the hard costs associated with internal customer support centres in the retail banking environment.
Using ‘back of the napkin math’ and relying on a few core assumptions, Jeff illustrated a potential cost savings between $9 million and $21 million over 3 years.
Not to be outdone by an employee-facing ROI story; I feel compelled to demonstrate an equally optimistic business case for banks when considering the use of search to reduce operational costs in a customer-facing scenario.
In this case, we are looking to reduce costs associated with the external-customer call centres. Emphasis is placed on the calls that could be avoided if customers were able to locate the information they sought, and / or more sufficiently self-service by way of intuitive, guided navigation and a conversational search experience.
The business case is grounded in the following assumptions:
If we focus solely on a 10% reduction of customer support calls, we can forecast a hard cost savings of approximately $6,048,000 per year.
However, even more powerful, is the potential opportunity to reduce the call centre size by 10% as a direct consequence of the call-cutting measures. This is particularly interesting if we consider that many call centres are significantly larger than 1000 FTE’s.
The chart below illustrates the hard cost savings over 3 years based on a 10% reduction in FTE’s for call centres of varying size.
Of course, there are more factors to consider. And yes, math is not often so crisp and clean. But, isn’t this just enough to raise your curiosity? Isn’t the raw potential enough to warrant a structured Search Envisioning exercise to determine what the real opportunity looks like for your organization?
Clearly, the simple math and business case resonated well with the Bank of America. In less than 6 months following the launch of their new Fast Search driven website, customer satisfaction is up, costs are down and B of A is well on its way towards Extreme Personalization. Extreme Personalization is B of A’s strategic search objective. What’s yours?