Enter It Once and Only Once!

You answer your phone and the caller on the other end of the phone is telling you to fix the spelling of his name. You carefully write down the correct spelling and login to Vista to correct the name only to find out that it is correct in Vista! Now what? You call the employee back to find out in what application the name was misspelled, then figure out who maintains the system so it can be corrected. All in all quite a bit of time is probably spent trying to fix a simple problem.

That's what we try and prevent at Fulbright & Jaworski, the unnecessary tracking down of incorrect information on any one of the firm's computer systems. It sometimes appears as if we have a new system implemented every month and with the new system comes the need for a list of names and titles at the very minimum. Then there is a need to know who is hired and terminated so the data can be kept current.

To prevent the issue of duplicate data entry the HR system (Vista) was designated as the central source of data for all personnel data. If any other systems need people data, it would have to be exported from Vista . Any data changes, new hires, or terminations would be entered in Vista and the changes would replicate throughout the other systems.

Since the HR server is tightly secured, very few people have access to the server and data. A security profile was created that has limited access to views. Using this profile, data is extracted. There is a main workflow for information into the Hub Export system. Data gets exported from Vista based on a set of table triggers, then the Script Manager program reads the list of changes and executes a set of stored procedures that updates the target systems.

For Vista, if certain fields of data are changed in empcomp, person, emprec, posrec, empuser, peraddr, pereduc, perlicen, pername, perphone, perskill or perunion a trigger is fired and a table in vista is updated (vistap.dbo.fjhubhr_hubdata). This table contains a unique id, type (table), person_id, primary key (field), operation (insert, delete, update), date updated, and an "is processing" flag.

A trigger on fjHubHR_hubData writes data out to a log table so we will have a history of all entries.

Once a minute the Script Manager executes a job that runs stored procedures for pulling data and updating the various applications. Looking at the fj_hubhr_hubdata table the stored procedure for each application runs, pulling the necessary data and updating the systems as appropriate. Each applica-tion has an individual stored procedure, but all use the fjHubHR_hubData table for determining what data changed.

The automation jobs run in serial. Anytime there are HR automation errors, the jobs stop in their tracks and nothing more gets updated until the error is corrected.

Some of the applications that are updated with personnel data from Vista are:

This is a simplified explanation of how our system integration works. There are lots of ways to interface the data, but whatever way you choose, it is well worth the effort.

Meribeth Spilger
Director of Human Resources
Fulbright & Jaworski L.L.P.
mspilger@fulbright.com