...
- single Person records (no duplicates),
- support Search/Match functionality,
- single key identifier for all People,
- single point of data retrieval for satellite systems (ie: University ID Card),
- determination of overall status and affiliation of a person within the University,
- consistency of setup table values across systems
Discussion points to be considered would be timing of synchronization (real time vs. batch), mapping/transformation of values between systems and system of record
...
B. Big, Early, Tentative Conclusions:
- PS and Workday integration: Keep the PS/HR Job and CC tables in tact in PeopleSoft and have 1 way push from Workday to push into PeopleSoft. Details of timing, field to field mapping, and transformations needs to be done in a project to plan out the details of how to. Search match, data deliver extracts, the long list of SQRs, Cobol jobs, ect. need to persist and have access to person data in PeopleSoft. Changing and sustaining the changes to those PS objects is prohibitively expensive and risky. So, we would keep a headless HR/Payroll PS system to support those SQR, data delivery, jobs, etc.
- PS Search match: HR's use of search match may need to be done in PS or called / used by Workday since Workday wouldn't have the Student and Alumni records, or would it? If manual search match needed manual intervention (based on teh value returned) the hire process would be stopped to force manual setting of the match.
- Workday needs of PeopleSoft for hiring. Workday hire process needs the following from PS:
- call PeopleSoft's search match tool (or have the search match be done manually)
- call PeopleSoft's EmplID generator
...