(AWE) Approval Workforce Engine Design
Presentation to UCSB BPM Team
March 13, 2013
Presented by
Catherine Luinstra-Uster
UCSB HR SME
Types of People
•
Person of Interest/POI
–
Has a relationship with the University but is not an employee and is not paid
•
•
•
•
•
•
Contingent Worker
–
–
Has an organization relationship with a department but is not an employee and is not paid
Contingent Worker Job Code
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Associate of the President/Chancellor
External Compliance/Auditor
Potential Hire
UC/OP/Affiliated Organization
Unknown
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
Academic
Staff
Academic - Faculty
Professor
SOE
NSF Lecture
Visiting
Adjunct Professor
Academic - Non Faculty
Contract
Career
Limited
Per Diem
Researcher
Project Scientist
Specialist
Postdoc
Academic Coordinator
Visiting
Academic - Student
Partial Year Career
Floater
Rehired Retiree
Contingent Worker - Staff
Graduate Student Researcher
TA Associate
Reader
Rem Tutor
Academic - Recall
All Titles
Contingent Worker - Academic
WOS Research Visitors
3
Custom Forms for Entering Data with
Approval Workflow Engine (AWE)
Custom Forms:
•
•
Template Based Hire (Rehire)
Additional Pay
–
–
–
–
•
Students employees on break for the
summer
Pay Rate Change
–
•
•
Transfer to another position/job
Earning Distribution Change
Short Work Break
–
•
Probation End Date
Transfer
–
•
•
Stipend
Specialty & Certification Pay
Summer Salary
BYA
Data Change
–
•
Draft Termination Form
Equity Increase
Retirement
Termination
–
–
–
–
Voluntary
Involuntary
Layoff
Death
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)
4
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
Initiator
Employee
Class
Career
HR
Approver 1, Approver 2, Approver 3
Faculty
AP
Approver 1, Approver 2, Approver 3
Student
Student Approver 1, Approver 2, Approver 3
CWR
HR/AP
Approver 1, Approver 2. Approver 3
5
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
Final Stop Example
Data Change Approver 1
Pay Rate Change Approver 3
Transfer Approver 2
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 Setup
During 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 Change
Action 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 Pay
Additional 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 Break
Action Description
Reason
Return from Short Work RWB
Break
Reason Description
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
Retirement
Action Description Reason
Retirement
RET
Reason Description
Retirement
•
Accurate Dates
• Separation vs. Retirement Date
21
Considerations/Decisions to be Made
•
Final Approver Level for each type of transaction
–
–
–
•
Maintenance of Approvers in the System
–
–
•
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
–
–
•
Identifying processes and approvers (same/different)
Training
–
–
–
–
–
•
Approval Process
Adding, Updating and Changing Approvers
Workflow for each Employee Class
–
•
Approver 1
Approver 2
Approver 3
Payroll
Benefits
Campus Business Processes vs. UCPath Business Process Maps
22