149Re: [SearchCoP] Re: People Search
- Apr 16, 2008Hi all - Late to the discussion here, but I thought I'd share the
kinds of things we've done with finding employees in our enterprise
search. Sorry in advance for the length - that's part of what took so
long to respond as I have a lot of thoughts in this area and couldn't
get them organized (hopefully I've done that a bit below :-) ).
First - the company I work for has a product in our product line named
eGuide that provides an online directory of employees. Prior to about
2 years ago, an employee had to explicitly decide at the point of
starting a search whether he/she was looking for "content" another
employee or and had to decide to use the enterprise search function or
the eGuide search function.
In the templates under which we have implemented eGuide on our
intranet, it's a frame-based application (which causes challenges for
our crawler-based search engine as do any frame-based UIs) and the
individual "person" pages in eGuide also lacked any useful <title> or
meta tags in the page. Together, these made it infeasible to index
the eGuide pages for inclusion in our enterprise search.
Working with the team that implemented eGuide, my team and I made a
few simple changes to the template for eGuide (to include a distinct
<title> and to also include some meta tags) and also built a very
simple (but automated) index page that provides the crawler a link to
the "internal" frame within eGuide for each employee (so we have a way
to ensure we cover all employees but only the employee pages).
With this, it became simple to index the individual employee pages and
have them show up in our enterprise search results.
However, we then ran into a business requirement we hadn't
anticipated. Within our infrastructure, we have a fairly
sophisticated way to provision users for access to various components
available through our intranet. This is primarily focused on
contingent workers (not full time employees) who likely have very
restricted need for access to tools, content, etc. The net of this
was that eGuide itself was provisioned on its own so that we could
have people who had access to parts of our intranet (including our
enterprise search function) but who would not be able to do searches
for employees. The use case I heard at the time that drove this was
the situation where we had a competitor who might be working with us
in a specific way and so needed access to some parts of our intranet
infrastructure but we didn't want to allow easy trolling of the
organizational hierarchy to look for recruits.
In any event - we ended up resolving this in a fairly blunt way.
Individual employees show up as search results but only in our "Best
Bets" section of the search results. The key thing about this
approach is that the best bets section only shows titles of items and
no summary. So we were willing to live with the ability for someone
to be able to do a search that returns a person in the search results
(but all they see is a person's name) knowing that if they click on
the result to go to the individual person's details, the regular
access control will keep them from doing that.
So as of right now, it's easy to do a search using our enterprise
search function that returns a person in the results (though it only
shows in the "Best Bets") and not be forced to do it using a "fielded"
search interface (i.e., look specifically in the Last Name field or
the First Name field, etc). Just search for "lee romero" and you'll
find me, for example, as well as all of the content that happens to
mention my name (mostly things I've written).
The latest part of our endeavor here is still in an experimental
stage. Read on for more...
With our current implementation, you can find employees in our
enterprise search, but only on keywords that are in the employee's
eGuide entry - primarily administrative data like name, cost center,
location, phone number, etc.
What we're missing is the ability to find people based on anything
less direct than that - skills, interests, work, etc.
We have implemented a Skills Inventory in our HR system but so far,
that seems to be a black hole - the data can be put in by individual
employees but there's no way for anyone else to use it or see it
(excepting perhaps HR people who might use it in reports or
We also have quite a number of online systems that employees use to
collaborate, communicate and do their jobs and many of these systems
have ways to connect an employee to their "artifacts".
So our recent efforts have been to build a new "profile" of an
employee that aggregates together data from a large number of systems
that the employee might touch. Things like:
* Our employee Wiki (using the title of the wiki articles)
* Our employee blog (using the title of the blog posts)
* internal community memberships (names of the communities)
* internal mailing list subscriptions (names of the mailing lists)
* Posts to mailing lists (subject lines of the posts)
* engineering projects (names of the projects)
* consulting engagements (names of the projects along with customer name, etc)
* documents published to our document repositories (title of the document)
and so on.
The change from the perspective of the search experience for a user is
minimal - these dynamic employee profile pages replace the eGuide
The change from the perspective of what types of terms you can use to
search for employees is very significant. Suddenly, you can find
people based on what they work on, what they write about (either on
mailing lists or blog posts or in wiki pages, etc.). You can find
people based on what they work on (the projects or products). And so
Ultimately, I see this profile page pulling data from many more
systems than it does today, including the Skills Inventory data
All in a very simple application - it basically just queries a series
of databases (ultimately, it could be a small data warehouse that
pulls in data from the various systems mentioned) to generate a
person's profile page.
The other interesting facet of this approach is that if you look at
any individual person's profile, you can get a very good sense of what
that person does and is interested in - *far* better than you can get
from the administrative information available in eGuide. Another
interesting side effect - in showing this profile page to some
employees, I've unexpectedly gotten the reaction of, "This is great -
this provides me with a simple way to find all of the things I work on
in one place!" (because the application links to the items it
references - individual Wiki pages, project spaces, etc.
The only sophistication in the application itself is in how it
generates the keywords <META> tag data - and it's not all that
sophisticated. Basically, it takes all of the words mentioned in any
of the data sources it uses and pools them together into a weighted
set of terms (ignoring "stop words"). The "weight" is basically the
number of times the word is used by that person (though some data
sources have other means to weight a particular term - mailing list
names are weighted by the # of posts to the mailing list). Some
sources automatically have their words weighted by a certain amount -
eGuide, for example, has its keywords much more heavily weighted than
others by default (so a person's name might have a weight of 100 from
the fact that it's in eGuide and not because that person includes
their names in everything they write, which most people don't).
This weighted list of words is then used to generate the keywords by
just sorting in reverse weighted order and then pulling in enough
keywords to "fill up" the keywords <META> tag (though "fill up" really
just means "until the words together are about 255 characters").
So far, all of the data sources that have been used in the pilot are
ones that produce data that is not "hidden" in the company - anyone
can go find the Wiki pages anyone else has edited or the blog posts by
anyone, etc. So we're not exposing anything not already generally
visible, we're just aggregating it together. As we move forward, that
might change which likely introduces some policy questions to
The success of this approach depends on several things, including:
1. Having a good set of sources that cover each type of employees work
processes (engineering will likely use different systems/tools than
support employees, which probably be different from those used by a
marketing employee, etc.)
2. Having employees that use the tools (whatever they might be) so
that the employees "leave traces" of their activities. Basically, if
an employee doesn't use any of the tools used to generate the profile,
the only data in their profile will be the same as in eGuide. I think
this is reasonable, at least in the sense that the search for such
employees is no worse than we have today.
3. Good synonyms (which goes without saying for all search). In this
case, I've noticed that because the terms used by individual employees
can vary a lot when they're just writing prose, it's important to be
keep an eye on how the terms relate. For example, an employee might
frequently use the word "dev" but mean "development".
4. Obviously, and most critically, having online systems (that are
used) with some kind of means to connect activities to a person's
"identity" - which implies two parts: a consolidated identity for an
employee and systems that have a way to tag artifacts with the user's
This is already very long, but some interesting thought experiments
have come to mind that could be applied to the data generated in these
profiles (perhaps this starts to blend into the ONA-prac mailing list
or other topics - sorry):
A. One idea I find interesting is to provide a list of "similar
people" when you view the profile for an employee. Basically, use the
keywords (as computed above) to find employees with a lot of overlap
in their keywords. It makes me think of a ecommerce site having those
"Shoppers who bought this item frequently bought these as well",
except it becomes, "The following people are similar in work,
interests or writings with this person".
B. Taking that idea up one level - it's interesting to consider doing
some automated organizational network analysis where the links between
two people are built from the weights of their keywords. Two people
who have a lot of overlap in their keywords are linked, etc. This
could perhaps provide a way to find otherwise invisible communities.
C. Again, taking that idea up another level - aggregating together the
set of keywords across all employees and reflecting on what are the
big keywords for various levels of the organization. Do we use
terminology consistent with what we think we're about as a company?
Do we tend to write about, be interested in or work on things that
somehow don't match with what we say we are about? Perhaps a way to
identify skill sets to fill in (some insight for HR, for example)?
Perhaps the way our executives see the company doesn't match well with
how we see ourselves (some level of cultural change still underway)?
If you got this far - congratulations - I hope you found it interesting.
On Sat, Apr 12, 2008 at 1:39 AM, c_gandhi <c_gandhi@...> wrote:
> We have been doing some very interesting things with the employee
> information and ES:
> 1. Improve the relevance of the search results
> 2. Improve the reverse intelligence
> 3. Interested Party Locator (this locates employees based on
> 4. Enable context selection
> --- In SearchCoP@yahoogroups.com, "Tim" <tbwendt@...> wrote:
> > We are looking at adding a People/Employee search to our enterprise
> > search interface and I am looking for input as to what other
> > organziations are doing and what types of features are working, not
> > working and which features are providing the most value.
> > We have about 20,000 employees world wide and that number is
> > quickly. We are are Autonomy shop - not that the vendor is
> > but I've found that using search technology provides a great single-
> > box search across all kinds of employee information versus the more
> > structured SQL searches we are currently using where you are trying
> > to match individual columns in a database table.
> > Of course, we want people to be able to search basic people
> > information such as name, phone, location, title, reporting
> > structure, etc. My question is this; what other things are
> > companies doing in the people search space that can add value?
> > In particular, connecting "people to other people" versus only
> > connecting "people to content." We would like to add some social
> > networking capabilities to the people search such as to allow an
> > employee to tag themselves with content such a profile, their
> > skills, interests, project experience and perhaps a list of
> > web sites. Then a user can click on a skill tag and find other
> > people with the same skills or related skills.
> > We are envisioning moving towards a Facebook, WSS/MOSS MySite or
> > LinkedIn type of employee interface. The goals would be:
> > * connect new employees into the organization
> > * find people with related, professional interests
> > * find experts
> > * find people that need to be engaged in a project or process
> > Make sense? Is anyone on this group doing or seeing anything
> > interesting in this space that they might elaborate on?
> > Thanks
> > Tim Wendt
- << Previous post in topic Next post in topic >>