(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