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

Re: People Search

Expand Messages
  • Tony Rose
    Rich, ... searches and ... VanDyke, ... please send ... You might find the following of interest: http://www.mscui.net/Samples/PSIB/PatientSearchInputBox.aspx
    Message 1 of 12 , Mar 2, 2008
    • 0 Attachment
      Rich,

      > If you figure out a foolproof algorithm that allows free-form
      searches and
      > handles compound names, multiple middle names, Van Dyke versus
      VanDyke,
      > names with apostrophes, foreign names, and nicknames, would you
      please send
      > it along? :-)

      You might find the following of interest:

      http://www.mscui.net/Samples/PSIB/PatientSearchInputBox.aspx

      It's a .NET control for the searching of patient records, i.e. it
      accepts various demographic details in a single search box then
      parses them to do a structured lookup. Obviously the use case is
      somewhat different to the one suggested by Tim, as this control is
      aimed at searching patient records in a national database rather than
      staff records in a corporate database.

      And as you'll see, it's far from foolroof, but it nonetheless
      illustrates how far you can go with just simple regexes under the
      hood. For example, I tried it with "Dr Rich Wiggins 35 1000 lakeside
      parkway 12/01/1980" and it did a reasonable job, but you'll soon find
      the boundary cases if you vary this a little.

      The UI design guidance that accompanies this lives at:

      http://www.mscui.net/DesignGuide/PatientFindAPatient.aspx

      but note that this is heavily geared toward the requirements of
      information governance, privacy, etc. (as you'd expect with patient
      records).

      Best regards,
      Tony
    • Richard Wiggins
      Tony, Yes, indeed, I do find it interesting! I tried your sample search out and it does do an impressive job of parsing. I was able to fool it with this
      Message 2 of 12 , Mar 2, 2008
      • 0 Attachment
        Tony,
         
        Yes, indeed, I do find it interesting!  I tried your sample search out and it does do an impressive job of parsing. 
         
        I was able to fool it with this query:
         
           Dr. Oscar de la Cruz  29/2/56 48864
         
        It came up with a family name of 
         
           de
         
        and an age of 29, and it didn't parse out the postal code. 
         
        As you say, we always encounter boundaries.  :-)
         
        /rich

        On Sun, Mar 2, 2008 at 7:19 AM, Tony Rose <tgr@...> wrote:

        Rich,



        > If you figure out a foolproof algorithm that allows free-form
        searches and
        > handles compound names, multiple middle names, Van Dyke versus
        VanDyke,
        > names with apostrophes, foreign names, and nicknames, would you
        please send
        > it along? :-)

        You might find the following of interest:

        http://www.mscui.net/Samples/PSIB/PatientSearchInputBox.aspx

        It's a .NET control for the searching of patient records, i.e. it
        accepts various demographic details in a single search box then
        parses them to do a structured lookup. Obviously the use case is
        somewhat different to the one suggested by Tim, as this control is
        aimed at searching patient records in a national database rather than
        staff records in a corporate database.

        And as you'll see, it's far from foolroof, but it nonetheless
        illustrates how far you can go with just simple regexes under the
        hood. For example, I tried it with "Dr Rich Wiggins 35 1000 lakeside
        parkway 12/01/1980" and it did a reasonable job, but you'll soon find
        the boundary cases if you vary this a little.

        The UI design guidance that accompanies this lives at:

        http://www.mscui.net/DesignGuide/PatientFindAPatient.aspx

        but note that this is heavily geared toward the requirements of
        information governance, privacy, etc. (as you'd expect with patient
        records).

        Best regards,
        Tony


      • Jim
        The company I work for has about 50,000 people in our employee directory which handles our employees access to their directory services and public people
        Message 3 of 12 , Apr 9, 2008
        • 0 Attachment
          The company I work for has about 50,000 people in our employee
          directory which handles our employees access to their directory
          services and public people soft information which includes a section
          where employees can list their business attributes.

          We have our search engine indexed the key fields of the employee
          directory. If an employee enter 2 words, the search will check if
          their are any matches (or near matches ) to persons first name (or
          middle) name in first position and last name for the second position.

          We also have a name thesaurus file of a few hundred names so if you
          look for James smith you also can find Jim Smith and if you look for
          Daryl you also will look for Darrel etc.

          We display these result in an employee listing separate from the
          standard search results which displays the employees full name,
          personalized job title and email link and phone number. If you click
          on the persons name it is linked to the employees full employee
          public profile in the employee directory.

          --- 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
          > organizations are doing and what types of features are working, not
          > working and which features are providing the most value.
        • c_gandhi
          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
          Message 4 of 12 , Apr 11, 2008
          • 0 Attachment
            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
            >
          • Lee Romero
            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
            Message 5 of 12 , 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
              > >
            • Jim
              Re: People Search Lee, Well done on the response. I concur on many of the points you made. We ve done some of this and are already in the planning stages to
              Message 6 of 12 , Apr 18, 2008
              • 0 Attachment
                Re: People Search

                Lee,

                Well done on the response. I concur on many of the points you made.
                We've done some of this and are already in the planning stages to
                expand it. One of our problems is that we are a global company but we
                have to integrate newly acquired companies into our system each time.
                Easy to get the directory information very difficult to get the
                details from their employee databasse. We also have the EU
                requirements for privacy.
                We are always adding employees in to a common people-soft platform
                and in an acqusitionthat's that is a slower process.

                On the up side our people search recognizes names in the common
                search box so it looks for those names. We have a nem thesaurus so
                variations to anmes and common short names are still picked up and
                matched to the directory.

                Jim
                --- In SearchCoP@yahoogroups.com, "Lee Romero" <pekadad@...> wrote:

                > 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 :-) ).....


                > Lee Romero
                >
              • Lee Romero
                Thanks, Jim - Looks like a lot of commonality. With the work I described that s in pilot, we also need to grapple with EU privacy requirements. Not entirely
                Message 7 of 12 , Apr 18, 2008
                • 0 Attachment
                  Thanks, Jim - Looks like a lot of commonality.

                  With the work I described that's in pilot, we also need to grapple
                  with EU privacy requirements. Not entirely sure what that will do to
                  the solution.

                  We also have the acquisition challenges. We are a global company,
                  though not *that* large; our HR IS folks do seem to have a pretty good
                  process in place for handling acquisitions. Of course, with the
                  strategy I described, new hires will appear basically "empty" in their
                  profile as they will not have used any of the tools that are the
                  source for the profiles (yet).

                  Where did you acquire the name thesaurus? That would help quite a bit
                  in our solution (I have synonyms for some names but it's not very
                  complete, that's for sure).

                  Thanks again
                  Lee

                  On Fri, Apr 18, 2008 at 10:48 AM, Jim <jim.smith@...> wrote:
                  > Re: People Search
                  >
                  > Lee,
                  >
                  > Well done on the response. I concur on many of the points you made.
                  > We've done some of this and are already in the planning stages to
                  > expand it. One of our problems is that we are a global company but we
                  > have to integrate newly acquired companies into our system each time.
                  > Easy to get the directory information very difficult to get the
                  > details from their employee databasse. We also have the EU
                  > requirements for privacy.
                  > We are always adding employees in to a common people-soft platform
                  > and in an acqusitionthat's that is a slower process.
                  >
                  > On the up side our people search recognizes names in the common
                  > search box so it looks for those names. We have a nem thesaurus so
                  > variations to anmes and common short names are still picked up and
                  > matched to the directory.
                  >
                  > Jim
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.