Assessment of Workday Technical Session at CU

4/28/2010

Overall Assessment:

Technically there appears to be no showstoppers that would prevent a Workday solution.  Through various detailed discussions it was concluded that there are technical and business process solutions to mitigate any areas that would be "broken" as a result of moving Human Resources, Payroll and Benefits from Peoplesoft to Workday.

Synchronization of data

The initial synchronization assessment determined that PERSON, CAMPUS COMMUNITY, JOB and possibly LOOK UP tables must be and can be synchronized between Workday and Peoplesoft.  The synchronization of data is necessary to support:

• 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:

• 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.

Web Services are dynamic, customizable and secured.  All data used by a web service is based on data access privileges.  

• External Systems have their own IDs that register themselves as clients.
  • Workday authorizes the system and the user of the external app to:
    • allow use of the service and
    • get the right data back.
• Workday provides outbound flat file generation.  Data can be transformed from XML to CSV or custom XSLT. 
• EIB: for high volume loads...
  • SFTP the file, which is a loaded templated spreadsheet, pick up, service called to import it, or upload it manually
  • Ability to set basic error handling manually in defining the upload - # load error limits, validate only load... : errors are based on object validation
  • Error descriptions are added to each error row that failed. 
• Notifications of automated integrations:
  • VERY extensive integration completion / status reporting - content, trigger condition, recipients, groups, subject, content/body, conditions and rules, with attachments of the file, etc.
• All events and updates publish the object id, but not the employee id. Any listener of the service (e.g. at CU) has to call back using the object ID to update and/or get more info.
• Oracle SOA Suite and webMethods:
  • Use these types of tools for governance and standards.
  • Report of the service enabled reports and load the SOA suite repository so they aren't manually synced.
  • Consider calling a service in Oracle SOA suite and use CUWA and then call Workday without CUWA. This is bus to bus.
  • Use if SOA Suite would enable tracking of the use of the services of Workday. Workday doesn't provide service use info. Those usage stats could then tell us which services are actually being used so we  know what to worry about when one side or the other changes (i.e. impact analysis support).

Conversion and Mapping:

• 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.

Security

• Two data centers and a near real time 2nd site (atlanta)
• Role and hierarchy is the basis row level security. The security data could all be exported in a report.
• All updates are logged with a timestamp and a user id. All attributes - not just rows.
• They do not offer dual factor authentication
• There are no 'direct pipes / private networks.  Workday is on the internet.
• User accounts can be tied to a particular authen system - as in delegated single sign on.
• UserID generation: Workday would publish the event, CU IDMgmt would listen, pick it up, call back with the event id, and provide a Netid to Workday to store with the person as well as either a) telling Peoplesoft directly OR b) letting Workday update Peoplesoft's external system table (via web service).
• Audit logging doesn't keep the IP address.
• Workday cannot lock down by IP address.
• Timeouts for inactivity by groups and functions: They don't know and will be checking.
• Group management: it is all done in Workday. They don't know of the feasibility in using eternal groups.
• People can be in multiple functional domains.
• Row level access is based on your org structure.
• Security group management: Too much to list. It is just best to see the demo. There will have to be many management conversations about how to manage groups, grant them rights and assign people to them.
• Workday Test Environments - Cornell requires masking ("scrambling") of non-production transactional data values of SSN, credit card number, driver's license number, bank account number and patient treatment information.

Data marts

Appears that the operational reporting capability within the WorkDay application is fairly powerful.  Much of the operational reporting, against HR data only, could most likely be done in the application rather than a datamart solution.  The need for an HR datamart will be to support more managerial and analytical type reporting which requires more advanced data transformation, aggregation, and the ability to integrate with non-HR data sources such as financial data.

• Current HR/Datamarts are used for non PS HR and PS HR applications and reporting.
• Advantage of using Workday reports and analytics: 
  • current data
  • can drive in immediately and take action
• Potential problems of using Workday reports and analytics:
  • more people have datamart access than Peoplesoft access now
  • longitude data combines data with other info 
• Reports:
  • Specialized and cross-functional reports might still come from the datamart, but note that analytics are available within Workday.  Presumed that most reports would come directly from Workday.
• Non PS HR apps using the datamart now:
  • Any specialized apps that might be needed would go to Workday if possible
  • Some might not: CCTS, LARS
  • QUESTION: what apps would be left after Workday is deployed completely done?
• To do (in an analysis project): Once determined what is left (as in needed for reporting) after moving to Workday for reports and the left over-and-not-covered-by-Workday HR apps, then we know what a new HR/Payroll datamart would look like.  For those we either a) make new extracts from Workday to feed the datamart, or b) load PS HR and keep pulling from there.
• Access to WorkDay data sets would be via the UI or integration server through web service calls.  If we do not provide a comprehensive HR datamart, will there be policies in place to allow units to use web services to pull data for their HR data needs?
• Can Oracle SOA Suite help with integration to Datamart and OBIEE for a more powerful/less complicated process? 

Initial work needed to help determine scope and effort include:

1. CIT analysis of datamarts.  What PERSON and HR data is currently used in datamarts other than HRPY?
2. CIT & HRIS analysis and confirmation of which PERSON tables and attributes will be maintained "near real time" in the PeopleSoft database. Does this match our PERSON data needs for our non-HR data marts? How are these attributes defined in WorkDay as opposed to PS?  
3. HRIS analysis of HRPY, HPDM, and HRIS developed and supported applications.  What data needs may be satisfied via web service calls to WorkDay, and what data should be pulled into a datamart. 
4. Review with stakeholders outside CIT & HR of their current use of the HR datamart(s).  What functionality is needed and relied on within the existing marts? What functionality will need can be replaced by the Workday application and what functionality must be replaced in a new datamart, or remediated in the old datamart environment. 
5. Decision on whether PERSON data will be maintained "near real time" in PS.

Primary concern around availability of resources on both the HR and CIT areas.  This effort would require significant analysis and design efforts to achieve.  With heavy work load on the HRIS folks, we are already experiencing resource constraints in getting work done on the HPDM mart, the impact of Workday would be much greater than what has been requested for HPDM.

Deployment notes

Probable prerequisites:

• integration standards, SOA tools like Oracle SOA Suite or an upgraded webMethods
• clear vision on reporting and datamart goals
• prep/set up tier one support
• figure out the realistic timing with Kuali Finance
• Cornell should consider a portal to aggregate different "Inboxes" from the different systems.

Big, Early, Tentative Conclusions

• 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.
  • Call PS on demand during a student hiring process (how would they identify a student in Workday if the data isn't there?)
  • 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: 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: 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
• Determination 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.