Notes concerning the integration with Kronos. 

  1. Basics as is: 
    1. today there is a staging table in kronos;
      1. all staff, new hires, changed hires, changes...are included
      2. reference tables are kept by payroll staff and used for the feeds from the staging areas into Kronos
      3.  leave status drives Kronos licenses which payroll to apply -> 100s of payroll by union, students, temps, non CU people...
      4. data elements are changing because data coming in  is different from Workday
      5. a position record number is needed in Kronos  as it drives how people are paid and differentiate between different jobs.  Position numbers are not a one-to-one match to WD numbers.  
      6. The logic for employee record number and primary job NEEDS TO BE CONSISTENT LOGIC ACROSS ALL INTEGRATIONS.
    2. Purposes  of Integrations Today:
      1. Employee Data Feed
        1. From peopleSoft:  Now Extracts employee demographic data from PeopleSoft and passes it to Krono
        2. Into Kronos:  Reads employee extract and populates Kronos import table
      2. Labor Level Feed
        1. From PeopleSoft: Extracts Department data from PeopleSoft and passes it to Kronos
        2. Into Kronos:  Reads labor level extract and populates Kronos import tables
      3. New Enhancement to include supervisor to employee association (see below)
      4. FLSA Validation
        1. From Workday:  Process Overtime for Kronos Employees
      5. FLSA Report
        1. From Workday:  Report by employee id and employee rcd number all earnings affected and not affected by FLSA.
      6. Summarize Time
        1. From Workday:  We might be able to use Summarized time for Kronos employees
  2. Big business decisions to be made
    1. Payrep groups - these groups drive security and access. They exist in workday but we have to decide if we want / can use it.
    2. empl record: these are used for uniquely identifying jobs (The Multiple Job issue) in Kronos and for Kronos to be able to send updates to Workday. Rules on primary job have to understood and used by Kronos.
    3. cost center field: we need the understand the definition and use in both systems as Kronos and Workday both have this field and the definitions are different and have to be reconciled. Could kronos cost center be in Workday?  Maybe.
    4. Statler example: Management needs to know WHERE the job was worked and where the costing went on the same job.
    5. Supervisor to employee association : these are defined in Workday and are not in the existing feed from  PS so new logic may be needed to present it and put it on the employee record.  This would be an extension of the labor level interface.
    6. Role on Org in Workday: knonos needs the payrep and the supervisor. Apparently we can we have a payrep and a supervisor both defined in Workday.   Supervisor is a default role by virtue of the WD application everyone gets one.  Payrep is a role that can be assigned.  Today in Kronos we are hand entering payreps.  When they move or change there is always an issue of not keeping up with the changes.
  3. Assumptions:
    1. Workday calculated FLSA with Release 15 (Nov 2011)
    2. Colts tables are left alone (and their use by PS) until workday is deployed;
    3. Kronos will integrate directly to WD with no intermediary staging tables in PS or other systems.
    4. some CIT talent is required for Kronos/Workday subproject , such as DBAs and sys admins, to set up environments
    5. Analysis for the Remediation of Kronos for Workday is required  to answer the above questions,  and determine what enhancements and changes
    6. Kronos Corp should assess if the Workday configured integration as delivered could be used with the CU installation of Kronos.