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

People search within an enterprise solution

Expand Messages
  • Lee Romero
    Hi all - Sorry for the blog spam but I recently completed a series of posts on my blog about the inclusion of people search within an enterprise search
    Message 1 of 3 , Nov 5, 2008
    View Source
    • 0 Attachment
      Hi all - Sorry for the "blog spam" but I recently completed a series
      of posts on my blog about the inclusion of "people search" within an
      enterprise search solution, trying to break out the various ways of
      doing this and also (the last few posts) providing a case study
      discussion of a proof of concept I've worked on trying to address what
      I have characterized as a "fourth generation" solution.

      I'm interested in what others have done to solve this type of search
      in their enterprises. Have many of you implemented any specific
      functions (applications) to address the particular needs of supporting
      workers finding co-workers? What do you see as primary challenges in
      this area? Is this a need you've had to address at all?

      Regards
      Lee Romero

      PS - You can find my series of posts at:
      http://blog.leeromero.org/tag/people-search/ - they're presented
      bottom-up so you need to start with the last post on the page and read
      up.
    • Tim
      Lee - good blogs on People Search. People Search is my life at the moment. You goals and plan are solid. We are doing a similar pilot within our company.
      Message 2 of 3 , Nov 5, 2008
      View Source
      • 0 Attachment
        Lee - good blogs on People Search. People Search is my life at the
        moment. You goals and plan are solid. We are doing a similar pilot
        within our company. There is a lot of pockets of resistance/fear to
        social search/web 2.0 functionality. Please post a summary of your
        findings after the pilot. Your data model is good and I like the
        approach of recording the "traces of activity" - I hadn't thought of
        that approach.

        I could talk a lot about People Search so I'll try not to ramble on
        too much. I would appreciate feedback on my approach as well.

        In my research, there are two ways to gather employee data for people
        search; explicitly and implicitly.

        EXPLICIT
        * explicitly ask for profile, skills, interests, relevant work web
        sites, and to build a list of colleagues (provides a foot in the door
        for social network analysis!)
        * ask employee to maintain their information - old approaches fail
        like requiring the employee to update once per year
        * ask employee to maintain but in a new fashion - make the
        application Web 2.0-esque. In other words, make the application
        Facebook-like (fun and simple) and provide carrots such as a ego-
        centric rating (this my rating from our pilot app) that encourages
        use:

        My Network Rating: 71%
        Network Designation: Super Networker

        * Autonomy uses the user Search Agents and Search Profile to gather
        data. I'm not sold on their explicit approach.
        * I've heard stories of past explicit employee data gathering
        failures yet I'm not convinced that we should write-off that
        approach. The landscape is evolving. There are a ton of social
        media applications that are taking off; MOSS MySites, Linked In,
        Socialcast, Noodle, Jive, ConnectBeam, etc. I'm just not sure the
        early "explicit" attempts were made when the workforce was ready and
        the our knowledge and maturity were ready - Web 2.0 is changing the
        landscape.
        * down side - worry about lost productivity, possible low adoption
        (funny that these concerns are in opposition!)

        IMPLICIT
        * crawl employee email, blogs, forum posts, document authorship and
        other social media applications - using data for social network
        analysis and expertise location.
        * use structured HR data gathered by HR-type applications
        * collect activity (Lee's traces of activity concept)
        * down side - has a big brother feel that makes people nervous

        In our People Search we are:

        * Using basic structured employee data
        * Providing Facebook-like profiling, skills, interests, work-related
        links and colleagues
        * searched via Search Engine techology
        * supplemented/supported with a light-weight, strucutured data model

        Data Model looks like this:

        Employee table
        * structured HR stuff
        * Profile text
        * Concatenated list of skills
        * Concatedated list of interests

        Skills table
        * to maintain the meaning and maintenance of phrases like "object
        oriented analysis"

        Interest table
        * to maintain the meaning and maintenance of phrases like "ice
        fishing"

        Links table
        * web site name and URL

        Colleague table
        * just a list of employee IDs that the

        Our search engine crawler just hits the employee table and puts
        everything into a content field as well as separate skills and
        interests fields to get more focused results on a skill search. The
        search engine is better technology for general people search and
        skills searching because of the fuzzy nature of the search. So a
        user can search for "frank system architect california" A SQL
        database just doesn't do that well unless you construct and user
        interface and the "SQL statement from hell."

        Good topic Lee!

        Tim
      • Lee Romero
        Thanks, Tim - I ve intertwined my thoughts / comments below. Does anyone else have any experiences to share around people search within the enterprise? ...
        Message 3 of 3 , Nov 10, 2008
        View Source
        • 0 Attachment
          Thanks, Tim - I've intertwined my thoughts / comments below.

          Does anyone else have any experiences to share around people search
          within the enterprise?

          On Wed, Nov 5, 2008 at 12:54 PM, Tim <tbwendt@...> wrote:
          > Lee - good blogs on People Search. People Search is my life at the
          > moment. You goals and plan are solid. We are doing a similar pilot
          > within our company. There is a lot of pockets of resistance/fear to
          > social search/web 2.0 functionality.

          [LR] Yes - I've heard some "fear" types of comments just in the
          informal review of my approach with people. I think it can be
          attributed to a concern of "visibility" or something.

          > Please post a summary of your
          > findings after the pilot. Your data model is good and I like the
          > approach of recording the "traces of activity" - I hadn't thought of
          > that approach.

          [LR] I think it's an interesting approach if only because it requires
          the worker to have "traces". It's interesting to contrast the group
          of people who have a "full" profile with this method against those who
          have a minimal profile (basically, just the data from our corporate
          directory). I'm not sure what kinds of conclusions you can draw, but
          it seems that there really *is* a pocket of people who are effectively
          "invisible". Of course, in my approach that can be attributed in
          large part to lack of inclusion of all of the sources I'd like to use
          - if I had those, I would guess that a lot (though not all) of those
          with minimal profiles would have a fuller profile.

          In my mind - if we had a full spectrum of systems to pull activity
          from and someone still has a minimal profile, it speaks volumes about
          their impact on the organization. My opinion only, of course :-)

          >
          > I could talk a lot about People Search so I'll try not to ramble on
          > too much. I would appreciate feedback on my approach as well.
          >
          > In my research, there are two ways to gather employee data for people
          > search; explicitly and implicitly.
          >
          > EXPLICIT
          > * explicitly ask for profile, skills, interests, relevant work web
          > sites, and to build a list of colleagues (provides a foot in the door
          > for social network analysis!)
          > * ask employee to maintain their information - old approaches fail
          > like requiring the employee to update once per year

          [LR] That's been my experience as well - you might see a big push once
          (upon launch) but it's hard to instill the need/value to maintain in
          the corporate culture. That's what is needed, it seems - you need to
          answer the question, "What's in it for me?" at every level of the
          organization - the individual employee, the managers, the directors,
          etc.

          > * ask employee to maintain but in a new fashion - make the
          > application Web 2.0-esque. In other words, make the application
          > Facebook-like (fun and simple) and provide carrots such as a ego-
          > centric rating (this my rating from our pilot app) that encourages
          > use:
          >
          > My Network Rating: 71%
          > Network Designation: Super Networker

          [LR] I like this idea - it helps to answer the "What's in it for me?"
          question and also (if well executed) keeps the maintenance process
          minimal at any one point (you kind of do it all along, right? Not one
          update each quarter / year / whatever?)

          >
          > * Autonomy uses the user Search Agents and Search Profile to gather
          > data. I'm not sold on their explicit approach.
          > * I've heard stories of past explicit employee data gathering
          > failures yet I'm not convinced that we should write-off that
          > approach. The landscape is evolving. There are a ton of social
          > media applications that are taking off; MOSS MySites, Linked In,
          > Socialcast, Noodle, Jive, ConnectBeam, etc. I'm just not sure the
          > early "explicit" attempts were made when the workforce was ready and
          > the our knowledge and maturity were ready - Web 2.0 is changing the
          > landscape.

          [LR] Yes - I am not sure it's not valuable, that's for sure. However,
          my thinking is that a system that merges the self-maintained explicit
          data with the implicit (produced by actual work - i.e., the "traces of
          activity") provides a more complete picture and addresses failings of
          both.

          > * down side - worry about lost productivity, possible low adoption
          > (funny that these concerns are in opposition!)
          >
          > IMPLICIT
          > * crawl employee email, blogs, forum posts, document authorship and
          > other social media applications - using data for social network
          > analysis and expertise location.
          > * use structured HR data gathered by HR-type applications
          > * collect activity (Lee's traces of activity concept)
          > * down side - has a big brother feel that makes people nervous

          [LR] Re: "big brother feel" - that's true and one of the reasons in
          the pilot I've put together I've only used data sources for the
          activity that are already fully visible. All of the data used could
          be assembled by any employee in the company; admittedly, it would be a
          significant task to do that for an employee as it's pulling from about
          a dozen systems right now, but nothing is being "exposed". In my
          approach, though, it's the fact that everything is visible in one,
          neat package that forced me to consider "obscuring" some of the data,
          so I adopted the tag cloud as the default display unless someone
          specifically opted-in to have their details displayed.

          >
          > In our People Search we are:
          >
          > * Using basic structured employee data
          > * Providing Facebook-like profiling, skills, interests, work-related
          > links and colleagues
          > * searched via Search Engine techology
          > * supplemented/supported with a light-weight, strucutured data model

          [LR] Do employees show up as targets in your enterprise search
          solution with this approach? Or does a searcher need to explicitly
          select a domain of "people"?

          >
          > Data Model looks like this:
          >
          > Employee table
          > * structured HR stuff
          > * Profile text
          > * Concatenated list of skills
          > * Concatedated list of interests
          >
          > Skills table
          > * to maintain the meaning and maintenance of phrases like "object
          > oriented analysis"

          [LR] Is there a management process for these values or can anyone add
          to the list (just by using a new term)?

          >
          > Interest table
          > * to maintain the meaning and maintenance of phrases like "ice
          > fishing"

          [LR] Same question as above - is there any management process for these values?

          >
          > Links table
          > * web site name and URL
          >
          > Colleague table
          > * just a list of employee IDs that the
          >
          > Our search engine crawler just hits the employee table and puts
          > everything into a content field as well as separate skills and
          > interests fields to get more focused results on a skill search.

          [LR] Very similar to my approach, though I'm building "full" web pages
          (it sounds like that might not be what you're doing - apologies if I'm
          not reading that correctly).

          > The
          > search engine is better technology for general people search and
          > skills searching because of the fuzzy nature of the search. So a
          > user can search for "frank system architect california" A SQL
          > database just doesn't do that well unless you construct and user
          > interface and the "SQL statement from hell."
          >
          > Good topic Lee!
          >

          [LR] Thanks. I'd like to hear from others as well.

          Regards
          Lee Romero
        Your message has been successfully submitted and would be delivered to recipients shortly.