Loading ...
Sorry, an error occurred while loading the content.

149Re: [SearchCoP] Re: People Search

Expand Messages
  • Lee Romero
    Apr 16, 2008
    • 0 Attachment
      Hi 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
      something).

      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
      pages.

      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
      on.

      Ultimately, I see this profile page pulling data from many more
      systems than it does today, including the Skills Inventory data
      mentioned above.

      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
      consider.

      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
      identity.


      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.

      Lee Romero





      On Sat, Apr 12, 2008 at 1:39 AM, c_gandhi <c_gandhi@...> wrote:
      > Hi,
      >
      > 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
      > interests)
      > 4. Enable context selection
      >
      > regards
      > Chirag
      >
      > --- 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
      > growing
      > > quickly. We are are Autonomy shop - not that the vendor is
      > relevant
      > > 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
      > favorite
      > > 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
      > >
    • Show all 12 messages in this topic