| Excerpt |
|---|
All notes form the original April 2010 meetings in which we got our first acquaintance with the impact of Workday. |
| Children Display | ||||||
|---|---|---|---|---|---|---|
|
...
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.
- 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: Workday provides outbound flat file generation, select, transform (. Data can be transformed from 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:
- job, compensation, worker histories would normally be inserted
- benefit history: might be included under compensation. Workday will need to clarify that. Determination must be made regarding how much history and what data elements must be converted. Benefit history is needed for IRS audits. there 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 6 months needed. They have basic estimates and a framework / generic plan for a conversion effort.
- Process: we Cornell would have to put data into their the Workday supplied spreadsheet templates. They have There is a very specific sequence to go through to load the system - set up tables and then the objects.
- Resources needed: 1 or 2 tech people Workday indicated that 1 - 2 technical resources are needed for the deployment, so says Workday.
...
Security
- two Two data centers and a near real time 2nd site (atlanta)
- keys next to encrypted data but encrypted differently
- See their 'Security INtegrations' slide
- Role and hierarchy is the basis row level security. The security data could all be exported in a report.
- all 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?' no. it's . Workday is on the internet.
- user User accounts can be tied to a particular authenN authen system - as in delegated single sign on.
- userID UserID generation: Workday would publish the event, CU idmgmt IDMgmt would listen, pick it up, call back with the event id, and provide a netid Netid to Workday to store with the person as well as either a) telling peoplesoft Peoplesoft directly OR b) letting Workday update peoplesoftPeoplesoft's external system table (via web service).
- audit Audit logging doesn't keep the IP address.
- Workday cannot lock down by IP address.
- timeouts Timeouts for inactivity by groups and functions: They don't know and will be checking.
- group Group management: it is all done in Workday. They don't know of the feasibility in using eternal groups.
- people People can be in multiple functional domains.
- row Row level access is based on teh your org structure you are in.
- 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.
H. Data marts
- 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 current HR/Datamarts are used for non PS HR apps and reporting partly because access to Peoplesoft is too difficult and acceptable timing wise (a day late).and PS HR applications and reporting.
- Advantage advantage of using Workday reports and analytics: ** current data** can drive in immediately and take action
- potential Potential problems of using Workday reports and analytics:** more people have datamart access than peoplesoft Peoplesoft access now** longitude data combines data with other info
- reports: specialized Reports:** Specialized and cross-functional reports might still be come from the datamart, but note that analytics are available right in Workday and most if not all within Workday. Presumed that most reports would come directly from thereWorkday.
- Non PS HR apps using the datamart now:any ** Any specialized apps that might be needed would go to Workday if possiblesome ** Some might not: CCTS, LARS
- QUESTION: what apps would be left after Workday is deployed completely done?
- To do (in an analysis project): When we see Once determined what is really left (as in needed for reporting) after using moving to Workday for reports and the left over-and-not-covered-by-Workday HR apps, then we know what a new hrHR/payroll Payroll datamart looks would look like. For those we either a) make new extracts from Workday to feed the datamart, or b) load PS HRand 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?
I. Deployment notes
...
- 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.
Initial work needed to help determine scope and effort include:
- CIT analysis of datamarts. What PERSON and HR data is currently used in datamarts other than HRPY?
- 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?
- 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.
- 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.
- 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 CC Campus Community tables in tact in PeopleSoft and have 1 way push from Workday to push into 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, ectetc. need to persist and have access to person data in PeopleSoft. Changing and sustaining the changes to those PS objects is prohibitively 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 search/match may need to be done manually 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.
...
- 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.
...
Known Action items - things that need more conversations
...
Developer Network: Get access to the developer network \[- 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.
- 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
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?
...