(AWE) Approval Workforce Engine Design Presentation to UCSB BPM Team March 13, 2013 Presented by Catherine Luinstra-Uster UCSB HR SME
Dec 16, 2015
(AWE) Approval Workforce Engine Design
Presentation to UCSB BPM TeamMarch 13, 2013
Presented byCatherine Luinstra-UsterUCSB HR SME
Types of People• Person of Interest/POI
– Has a relationship with the University but is not an employee and is not paid• Associate of the President/Chancellor• External Compliance/Auditor• Potential Hire• UC/OP/Affiliated Organization• Unknown
• Contingent Worker– Has an organization relationship with a department but is not an employee and is not paid – Contingent Worker Job Code
• CWR - UCB Student Facilitator• CWR - LBL/DOE Post Doc• CWR - Visiting Student Researcher• CWR - Staff Intern• CWR - Affiliated Research Institute• CWR - Independent Contractor/Consultant• CWR - Clinical Associate/Admitting Physician• CWR - Non Research Fellow• CWR - Temp Agency Staff-Health• CWR - Temp Agency Staff-Non Health• CWR - Volunteer• CWR - Traveling Nurse• CWR - Community College Instructor
• Employee– Has an employment relationship with the University
• Update employee data– Status, Termination– Pay, Stipend
2
Employee Classes in PeopleSoft
AcademicAcademic - Faculty
Professor
SOE
NSF Lecture
Visiting
Adjunct Professor
Academic - Non Faculty
Researcher
Project Scientist
Specialist
Postdoc
Academic Coordinator
Visiting
Academic - Student
Graduate Student Researcher
TA Associate
Reader
Rem Tutor
Academic - Recall
All Titles
Contingent Worker - AcademicWOS Research Visitors
Staff
Contract
Career
Limited
Per Diem
Partial Year Career
Floater
Rehired Retiree
Contingent Worker - Staff
3
Custom Forms for Entering Data with Approval Workflow Engine (AWE)
Custom Forms:
• Template Based Hire (Rehire)• Additional Pay
– Stipend– Specialty & Certification Pay– Summer Salary– BYA
• Data Change– Probation End Date
• Transfer– Transfer to another position/job
• Earning Distribution Change• Short Work Break
– Students employees on break for the summer
• Pay Rate Change– Equity Increase
• Retirement• Termination
– Voluntary– Involuntary– Layoff– Death
Draft Termination Form
4
Design of the Approval Workflow Engine (AWE) • Campuses provided feedback • The design was changed based on campus
feedback• New design will provide more flexibility for the
campuses• Each UC Business Unit (Campus/Medical Center)
will be able to select which route and final approver they wish to use for each custom form/transaction type (vary by Business Unit)
Entering HR/AP Transactions• Campuses will not be entering data directly into PeopleSoft
• Custom front-end forms and AWE solution has been developed to accommodate UC requirements and to update data in PeopleSoft, and address routing and approval issues
• Approval Workflow Engine (AWE), will allow locations to route HR/AP transactions for approval prior to submission to the UCPath Center
• AWE will allow routing by each Employee Class in PeopleSoft
HR Approver 1, Approver 2, Approver 3
AP Approver 1, Approver 2, Approver 3
Student Approver 1, Approver 2, Approver 3
HR/AP Approver 1, Approver 2. Approver 3
Career
Student
Faculty
CWR
5
Initiator Employee Class
Set up Considerations• The route and final approver for each custom form cannot vary within a single
Business Unit (Campus/Medical Center)
• Approvers do not need to be in the same department to be designated as a department Approver
• An Employee must have been given the security role (e.g. Approver 1) in PS before they can be added to the routing table
• Approvers are able to initiate transactions as well as approve
• An approver is required within the routing table at the last step
– AWE functionality will skip blank non-final levels– AWE will give an error if no approvers are found at the final approver level for the
transaction
• Comments will be required for any transactions that are pushed back or denied
6
Campus Approval Level/Final Stop Set Up for Custom Forms
• UCSB will need to determine the final stop/approver for each type of transaction
• Once the final stop/approver approves the transaction the transaction is routed to the UCPath Center for input into PeopleSoft
Pay Rate Change Approver 3
Transfer Approver 2
Data Change Approver 1
Final Stop Example
7
Roles within AWE• Levels of defined approval workflow roles include:
– Initiator– Approver 1– Approver 2– Approver 3 – SMG Approver
– Location Administrator (not an approval role)
• Each approval level can have multiple approvers designated to that level for a specific department
• Allow for defined, as well as ad-hoc Reviewers and Approvers
• Each Campus (Business Unit) will work with their departments to establish and maintain a table that defines the specific Approver(s) for each Employee Class (e.g. Career, Limited, Academic-Faculty)
8
Capabilities of Approvers• Once roles have been designated, Initiators and Approvers will be able to:
– Execute all Workflow Approval actions – Initiate and/or Approve actions for employees in the designated department/Employee
Class
• Edit transactions per the agreed upon fields– The forms will not reflect what specifically was edited or by whom, although those
items will be tracked in an audit table– Not all fields will be editable
• As determined by the Practice Board, any key fields (i.e. employee id, record number and action) and fields related to dollar amounts will not be editable
• Approve/route to the next level approver, ad-hoc reviewer or ad-hoc approver
• Push back to the Initiator– Comments are required
• Deny the transaction– Comments are required
9
Set Up for Each Department and Approvers
10
Notification SetupDuring the process of a transaction, a number of notifications will be sent to the users involved in the transaction: • When the transaction is submitted, an email notification will be sent to all approvers selected in the table at the first
level for that employee class. An email will be sent to all approvers selected who have the "Email?" flag on the Department Approver setup page turned on.
• When the transaction is approved at a non-final level, an email notification will be sent to all approvers selected at the next level. If the transaction has reached the UC Path level, no approvers will receive an email.
• When the transaction receives final approval, an email notification will be sent to the initiator. (This is the point at which the data is entered into the delivered PS tables via a CI)
• When the transaction is denied, an email notification will be sent to the initiator and any approvers who approved the transaction prior to its ultimate denial (a comment is required).
• When the transaction is pushed back, an email notification will be sent to the approver selected at the level to which the transaction has been pushed back.
• When a transaction has been waiting at any level for more than 3 days, an email notification will be sent to the initiator, the current approvers, and the Administrator list.
11
Termination
All Terminations transactions will be routed and approved the same way regardless of the reason
• Voluntary Resignations• Involuntary Terminations• Layoffs• Medical Separation• Death
12
Termination Example by Employee Class
Termination transactions can be routed based on Employee Class but can not be routed based on the termination reason
• Voluntary Resignations• Involuntary• Layoffs• Medical Separation• Death
Academic Example Dept. A, B, C, D, E, F• Initiator - Multiple support staff• Approver 1 - Business Officer• Approver 2 - Level left blank• Approver 3 - Academic Personnel Dept. Employees
Staff Example Dept. A, B, C • Initiator - Multiple support staff• Approver 1 - Business Officer • Approver 2 - Control Point• Approver 3 - Human Resources Dept. Employees
Student Example Dept. All Depts.• Initiator - Multiple support staff• Approver 1 - Level left blank• Approver 2 - Level left blank• Approver 3 - Student Dept. Employees
Example: • Approver 3 is the final approver/stop for all Employee Classes• Approver 2 is blank for Academic example• Approver 1 and 2 are blank for Student example
13
Template Based Hire (TBH)Action Description Reason Reason Description
Hire HIR Hire - No Prior UC Affiliation
Hire PRI Prior UC Employee
Rehire ACA Academic Recall
Rehire REH Rehire
Rehire RLO Rehire from Layoff - No Pref
Rehire PRF Rehire from Layoff - Pref
Rehire RET Rehired Retiree
Rehire EMR Emeritus Faculty
Rehire Rehire < or > than 120 day break
Rehire REI Reinstatement
Rehire REC Staff Recall
• Validation of no prior UC affiliation• Type of Rehire
• Retiree• Layoff• Recall• Reinstatement
14
Pay Rate ChangeAction Description Reason Reason Description
Pay Rate Change EQU Equity
Pay Rate Change MIN Bring To Minimum
Pay Rate Change STI Step Increase/Progression
Pay Rate Change ATB Across-The-Board
Pay Rate Change NAP Non-Acad Sal Grade/Step Update
Pay Rate Change DEM Demotion
Pay Rate Change JRD Job Reclass - Downward
Pay Rate Change JRL Job Reclass - Lateral
Pay Rate Change JRU Job Reclass - Upward
Pay Rate Change TRP Temporary Reduction Pay Rate
Pay Rate Change MER Merit
Pay Rate Change U18 Unit 18 Salary Increase
Pay Rate Change PRO Academic Promotion
Pay Rate Change ASA Academic Scale Adjustment
Pay Rate Change OFF Off Scale Increase
Pay Rate Change OSD Off Scale Decrease
Pay Rate Change OFF Off Scale Increase
Pay Rate Change PRP Permanent Reduction in PayRate
Pay Rate Change NEG Change in Negotiated Salary
• Centralized process for mass updates such as step increase/progression, merit
• Coordination of reclassification title changes performed on the position
15
Additional PayAdditional compensation is any cash compensation above a University employee’s regular, base compensation.
• Recurring payments that are paid over multiple, consecutive, pay periods (i.e. Stipend for 6 months) or as specified by the earn code (i.e. Summer Salary).
– Examples:• Academic Summer Salary• Stipends• Perquisites • Automobile Allowances• Housing Allowances• Certification Pay• Differentials• “Z” payments
• Compensation for certain jobs, when such compensation is non-regular, i.e. not UCRP covered compensation. These recurring payments are set up in the Additional Pay page rather than as Compensation in the job record.
– Examples: • UNEX • CME• Summer Session Instructor Pay• Academic Administrative Stipends• BYA Faculty Recall Pay
• Recurring vs. One Time Payment• Pay Periods (First, Second, Third)• Earnings Code/Reason Code
16
Data Change
• Updates that cross Multiple areas of responsibility• Academic - Reappointment• Benefits - Eligibility, Retirement Plan• Payroll - FICA Status, Tax Location• Employment - Extension, Limited to Career• Employee Relations - Probation Code
17
Transfer
• Transactions that cross multiple areas of responsibility
• Employment – Promotions• Employee Relations - Demotions
18
Short Work BreakAction Description Reason Reason Description
Return from Short Work BreakRWB Return from Short Work Break
Short Work Break FUR Furlough
Short Work Break GST Students
Short Work Break UNX Extension
Short Work Break BEN NSF - Benefits Bridge
Short Work Break U18 Unit 18 Lecturers
• Short Work Break• New process and Training
• Furlough• Students
19
Earnings Distribution
• New process and training
20
RetirementAction Description Reason Reason Description
Retirement RET Retirement
• Accurate Dates• Separation vs. Retirement Date
21
Considerations/Decisions to be Made• Final Approver Level for each type of transaction
– Approver 1– Approver 2– Approver 3
• Maintenance of Approvers in the System– Approval Process– Adding, Updating and Changing Approvers
• Workflow for each Employee Class– Identifying processes and approvers (same/different)
• Training– New Process and System (e.g. Entering Stipends)– New Action and Reason Codes– Data Quality, Auditing– Effective Dates (History, Current and Future rows of data)– UCPath Center Support (Corrections and Retroactive transactions)
• HR Transactions Impact on Other Modules– Payroll – Benefits
• Campus Business Processes vs. UCPath Business Process Maps
22