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

Re: People Search

Expand Messages
  • Tim
    Richard, You hit on quite a few topics. Relevancy is key but the question is how do you find a relevancy that works? The answer is that there is no one
    Message 1 of 12 , Feb 28, 2008
    • 0 Attachment
      Richard,

      You hit on quite a few topics. Relevancy is key but the question is
      how do you find a relevancy that works? The answer is that there is
      no "one" relevancy that makes any sense across a huge search index.

      We've found that relevancy fails across a large number (millions) of
      documents that has a lot of overlap. It also fails across disparate
      content types. For example, relevancy across web content and files
      (MS-Office and PDFs) at the same time is poor. Separating disparate
      content and providing a super high-level navigation may yield some
      benefits. We're still really early on in this approach so I can't
      tell you that it works yet but I do feel like it's a step in the right
      direction.

      One thing is clear, mixing people results in with the other content
      types didn't work at all. People results completely dominated the
      result set at times when the user could care less about getting people
      results.

      Now we are treating people results like Best Bets in a way. The data
      is high quality coming from a structured DB. It is also a relatively
      small set of data. This data gets crawled into a separate Autonomy
      database that has slightly different rules for people searching. The
      relevancy setting (Autonomy's way of casting a broader or narrower set
      of results) needed to be dialed down to be more forgiving - This
      allows more fuzziness in the people that were returned.

      You can't really get this fuzziness in a structured field search ala
      from a relational database. You'd better know the person's name and
      the spelling of the name in order for the people search to work. In
      my testing, using search technology instead of relational DB-type
      technology yielded some really cool results.

      From a single text input box I can type in "architecture" and get
      every architect in the company back plus people from any organization
      that might have "architecture" or "architect" in their team/org name.

      Now let the people "tag" themselves with metadata such as what skills
      do they have and what are their interests. You probably have skills
      and knowledge that your company doesn't know about but perhaps could
      be useful to the someone within the company.

      Now you'll pick up people in your people search who stated they have
      skills in "network architecture" or "n-tier architecture" or that they
      are interested in "classical Roman architecture." Now you've got some
      real power to connect people to people to acquire knowledge instead of
      people to a bunch of documents to sift through.

      We haven't rolled out our people search yet so I can't tell you if
      this will work but I think it looks very promising in a test environment.

      Thanks,

      Tim W

      --- In SearchCoP@yahoogroups.com, "Richard Wiggins"
      <richard.wiggins@...> wrote:
      >
      > Tim,
      >
      > You raise some very interesting points.
      >
      > We built a knowledge base that we call Techbase and we have the Help
      Desk
      > enter most of the items in it.
      >
      > We asked the Help Desk to code keywords for each article, mapping
      the words
      > to the articles.
      >
      > That process was a total failure. It turns out for a full-text
      corpus, you
      > need good relevancy ranking. I stumbled on the Yahoo/IBM Lucene
      mashup,
      > available for free for small corpuses, and it turns out it was the
      perfect
      > solution. I'm a huge advocate of the Best Bets approach, but it
      turns out
      > that is not the best approach when you are dealing with full text.
      You need
      > relevancy ranking.
      >
      > So if I hear you right, you are saying that people search also demands
      > context in metadata and relevancy ranking. Our impulse is to treat
      people
      > search as strict fielded search. But maybe that impulse is wrong.
      >
      > Do you analyze your people search logs?
      >
      > /rich
      >
      > On Thu, Feb 28, 2008 at 12:13 PM, Tim <tbwendt@...> wrote:
      >
      > > Good info - thanks!
      > >
      > > I won't say that we have a fool proof algorithm that allows free
      > > form searches but it works very well in my testing so far. We use
      > > Autonomy however I would guess most Enterprise Search technologies
      > > would be able to do the same.
      > >
      > > We crawl the employee directory (a web site). That information is
      > > indexed like any other web page. It is stored within a single
      > > content field into a separate Autonomy index database.
      > >
      > > The relevancy on the people search is adjusted to cast a slightly
      > > broader net than our normal default setting for other types of
      > > searchable content (web, file shares and SharePoint).
      > >
      > > This allows you to do some cool searches like:
      > >
      > > "fred in finance"
      > >
      > > Which finds all fred's and people that have "finance" in their job
      > > title. The "fred" I'm looking for ranks highly because he is both
      > > a "fred" and "finance" is in his job title. BTW, "in" is configured
      > > as an ignored word but it makes for a nice English-like search
      > > phrase.
      > >
      > > "portal"
      > >
      > > This returns everyone on the Portals and Collaboration Team along
      > > with Sam Portales <-- stemming at work
      > >
      > > Hyphens and apostrophes can be tricky but Autonomy provides some
      > > control over how they are handled (part numbers were were a small
      > > nightmare at first).
      > >
      > > Van Dyke vs. VanDyke - there is probably a way in Autonomy to split
      > > words on case changes (heaven knows there are a billion parameters
      > > and string operators available). Van might get stemmed in Autonomy,
      > > I'll have to check that out.
      > >
      > > Nickname, middle names, team name, account name, location, cost
      > > center, manager name, phone numbers, mail stops and other bits of
      > > data about the person are captured in that single content field.
      > > That provides a great deal of search-ablility without having to
      > > resort to something like a multi-column WHERE clause in a SQL query
      > > which would likely be very rigid and ineffective.
      > >
      > > Once we get results back from Autonomy, we do another search into
      > > the record of reference for structured data about the person.
      > > Probably an LDAP, Active Directory, ERP or SQL Server query for most
      > > companies. The strucutured data is then formatted nicely in the
      > > search results.
      > >
      > > Tim W
      > >
      > > --- In SearchCoP@yahoogroups.com <SearchCoP%40yahoogroups.com>,
      "Richard
      > > Wiggins"
      > > <richard.wiggins@> wrote:
      > > > 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? :-)
      > > >
      > >
      > >
      > >
      >
    • Tony Rose
      Rich, ... searches and ... VanDyke, ... please send ... You might find the following of interest: http://www.mscui.net/Samples/PSIB/PatientSearchInputBox.aspx
      Message 2 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 3 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 4 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 5 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 6 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 7 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 8 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.