Workday Assessment Document

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">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 timing of synchronization (real time vs. batch), mapping/transformation of values between systems and system of record.

Excel spreadsheet of Campus Community data as used Cornell.

Architecture/Integration Considerations:">Architecture/Integration Considerations:

All Workday associated hardware is housed and supported by Workday.
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:">Reporting and Service Generation:

Report generation is dynamic, scalable, customizable and secured:

- You can define calculated fields at report time.
- Report writing lets you make reports based on the access you have. Then save, schedule, share, or make as a web service.
- Using reports - as a human or as an app - requires privileges. Data relevance is based on privileges.
Web Services are dynamic, customizable and secured:
- Using web services - as a human or as an app - requires privileges. Data relevance is based on privileges.
- Searching capabilities exist.
- 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.
EIB: outbound flat file generation, select, transform (XML to CSV, or custom XSLT), ship to an SFTP site, encrypt if you want, run or schedule
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:">Conversion and Mapping:

Determination must be made regarding how much history 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">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.

Data marts">Data marts

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.
Can Oracle SOA Suite help with integration to Datamart and OBIEE for a more powerful/less complicated process?Appears that the operational reporting capability within the WorkDay application is fairly powerful, so much of the operational reporting, against HR data only, could probably 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.

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?

Initial work needed to help determine scope and effort include:

1) CIT analysis of data marts. What person and HR data is currently used in marts 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 data mart.

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 WD application and what functionality must be replaced in a new data mart, or remediated in the old data mart environment.

5) Decision on whether person data will be maintained "near real time" in PS.

My primary concern is around available resources on both the HR and CIT areas. This effort would require significant analysis and design efforts to pull off. 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 WD would be much greater than what has been requested for HPDM.

I. Deployment notes">I. Deployment notes

data fit gap - before or after The Project starts? if we are a Strategic Partner we would be 'in the system' before hand and understand the tool, so probably this fit gap would be done during the partnership and before the project officially starts.
CU project roles defined by Workday:
- see Lyman's notes of the formal role definitions and Workday's normal support protocol
- Business analyst: power user
- Tech analyst: tech part of integration, data extraction, security
- PM
- workday administrator: administer users and roles and groups. support escalation.
ALSO, as 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

B. Big, Early, Tentative Conclusions:">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 generatorCornell should consider a portal to aggregate different "Inboxes" from the different systems.

C. Small things:">C. Small things:

EMN (Emergency Mass Notification): EMN isn't on the rough interface list. Right now it uses the UNified Directory Feed AND direct reads. (Chris Grippin knows exactly how that works.) The end result is that the EMN DB is updated nightly and the external vendor EMN systems (Hyperreach and AlertNOW) are loaded from it every morning.
User machines: Flash players would need to be upgraded periodically for all users of Workday.

J. Action items - things that need more conversations">J. Action items - things that need more conversations

Reporting - HR/Payroll DM future vision: How much of the current HR reporting needs would be done directly from Workday, and how much would be done from the HR/Payroll DM and other DMs? This would have to be figured out during analysis. It is probably not a 100% replacement, and if we are feeding PS HR/Payroll then that's ok, the warehouse continues to be loaded as it is today.
Developer Network: Get access to the developer network [http://www.Workday.com/resources/developer_network.php] : Poke around the integration services and see what questions come up. Some of them sounded immensely powerful (clear cloud services or something to that effect).
Student Employment process - talk through options:
- a. 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. we'd have to walk through the scenarios of the student record changing in PS and also changing in Workday.
- b. 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.
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

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.
Use cases: We need to walk through the 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 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 sy
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

Web Services - use Workday webservices to integrate with PS. We would orchestrate the integration using out of box Workday web service functionality. Event notification vs batch.

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?

How much linkage is there between HR datamart and "other" datamarts (student, CR etc)? This will drive the sizing of the datamart. How much transformation of data is needed?

Child pages