...
Discussion points to be considered would be:
- Population determination:
- What employees need to exist in PS - all employees, partial load?
- What students need to exist or be available to Workday - all students, partical load?
- timing of synchronization (real time vs. batch),
- mapping/transformation of values between systems
...
- system of record
...
Excel spreadsheet of Campus Community data as used Cornell.
Architecture/Integration Considerations
...
All Workday associated hardware and data is housed and supported by Workday. Custom web service integrations are created and maintained by Cornell staff. A Cornell maintained, central integration tool (e.g. webMethods or Oracle SOA) should be utilized to facilitate web service integration.
- Workday uses object models in place of the RDBMS model. Data is stored in memory.
- Need to consider performance, persistence and fault tolerance
- Tools to access data
- Central integration tool (e.g. webMethods 8 or Oracle SOA suite).
- Avoid point to point integrations and all associated maintenance and coordination that would be associated.
- Create an Enterprise Service Bus bridge/repository to support a single view of all Workday web services where policies could be applied
- Integrations with our systems:
- Kronos if it was software as a service: no problem.
- Kuali Finance: we'd have to track down all the mapping of their CoA representation.
- Cynergy: Could we have Inbox items in Workday create notification items in Cynergy that link out to Workday for a single Inbox? This could easily be done with Events/Notifications from Workday and webMethods/SOA Suite to recognize and create a notification item in Cynergy
Reporting and Service Generation
...
Workday report generation is dynamic, scalable, customizable and secured. Workday supports the creation of dynamic, operational reports that can be scheduled, printed, converted to a web service or batch file and file transfered. Workday supports user-defined calculated fields. All report data is based on data access privileges.
...
- Determination must be made regarding how much history and what data elements must be converted. Benefit history is needed for IRS audits. There are 'set limits on historical information brought forward'
- Workday will provide a data conversion specialist to assist with converting data from PS to Workday
- Workday has basic estimates and a framework / generic plan for a conversion effort.
- Process: Cornell would put data into the Workday supplied spreadsheet templates. There is a very specific sequence to go through to load the system - set up tables and then the objects.
- Workday indicated that 1 - 2 technical resources are needed for the deployment.
...
- PS and Workday integration: Keep the PS/HR Job and Campus Community tables in tact in PeopleSoft and push data between Workday and 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, etc. 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.
- There are HR business functions that require use of Student/Faculty data. A mechanism will need to exist to allow use of this data by Workday.
- PS Search match: HR's use of search/match may need to be done manually in PS or called / used by Workday.
- 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
- User machines: Flash players would need to be upgraded periodically for all users of Workday.
Known Action items - things that need more conversations
- Student Employment process - talk through options:
- Bulk periodic upfront load of students into Workday. That adds a lot of students to the HR system that aren't employees just in case they get hired. Walk through the scenarios of the student record changing in PS and also changing in Workday.
- b. call Call PS on demand during a student hiring process (how would they identify a student in Workday if the data isn't there?)
- c. REDO SES by building a custom front end that hits both PS services AND Workday services to hire/change student employees.
- Student employees: Student employment uses a replication of job data. Workday needs PS's Student's person record when a student becomes an employee. Those Students becoming an Employee will need to come from PS and be updated by Workday, as opposed to normally employees who are created in Workday.
- WSB (Workday Service Bus) fact: is only for Workday, not for local deployment or even cloud ESB deployment - just rolled this out in the cloud too
- Use cases: We need to walk through the Identify set of major and essential use cases of people and jobs and describe responsibilities of the respective system to support the business processes.
- Diagrams: We need to diagram Diagram use cases showing specifically which data is going which direction for what events in each major BP.
- EmplID: Needs to be created uniquely once from PeopleSoft. If Workday makes people records the EmplID needs to maintain that uniqueness.
- Other systems using person data: What other systems require person data? COLTS and KRONOS and data delivery. Do you need to change them or does keeping them
- BP Impacts: Will need to push data from Workday into HR PeopleSoft CC data otherwise the guts of PeopleSoft will have to get ripped out - Assuming we turn off all business processes in HR PS that would update CC data, are there other BPs in other parts of PS that would update this data - i.e. would we have to back fill from CC data into Workday? - Workday doesn't have tables, just objects, that have to be transformed and kept in syDetermination of Peoplesoft Business Process Impacts due to data being in separate systems.
- SOA Suite and CUWA on webservices:
- We might need a waiver or change in our CUWA authentication scheme in order to use vendor supplied services (user generated or Workday supplied).
- SOA Suite or Webmethods and Workday: would we want to force all calls to Workday to go through SOA Suite or WebMethods for CUWA and better governance and of it call Workday and be in the middle? Seems to have many benefits. List them and add this to the case for SOA Suite.
Notes from Meeting with Aaron, Steve, Karel, Vicky 5/6/2010
...
- .
...
Historical data conversion - how much data needs to be converted? What is end result impact?
Population of employees in PS - all employees, partial load?
Population of students in Workday - all students, partical load?
Population of data into PS - data elements, historical?
...