R2R Program Update

Joint HR Advisors/Direct Service Representatives Meeting

May 18 2017

▪ Workday implementation methodology: a few notions

▪ Prototype roadmap

▪ Timeline

▪ Design approach & golden rule

▪ Process-specific guiding principles

▪ Who are the Process Owners and SMEs?

▪ Change Enablers

▪ Next steps

2

Agenda

Workday Process Breakdown

Blueprint processes mapped to the Workday processes:

Design Workshops are structured per Workday process

Blueprint process Corresponding Workday process

Organizational Master Data & Position Management

HCM

HR Master Data & Life Event Management (Employee Record Management)

HCM

Onboarding HCM

Compensation Compensation

Leaves Absence Management

Benefits Benefits

Labour Relations HCM

Payroll Management Payroll

Time & Attendance Management Time Tracking

Recruitment & Staffing Recruiting

Performance Management Performance Management

Academic Tenure & Promotion HCM – Academic Tenure & Promotion

3

Notion of Software as a Service (SaaS)

4

▪ Software that is owned, delivered & managed by the solution

provider, i.e. Workday

▪ Modules offered are the same for all clients, and some

configurations are possible to meet the specific client needs

▪ Functionality offered is based on best practices

▪ Version updates are more common and less costly than on

premise systems

▪ Data is easily accessible from a smartphone, a tablet, a laptop,

or a desktop — wherever you have an Internet connection

▪ Meets all relevant security & compliance guidelines

▪ SaaS creates a community where customers share knowledge, resources and learning

▪ Workday’s centralized data centers reduce energy consumption by using computing

resources more efficiently

Notion of Tenant

▪ A tenant is an application with its own secure

environment. Each Workday client has their

own secure production tenant that only they

can access

▪ When R2R starts making changes to Workday

through configuration, these changes will only

be reflected in McGill’s tenant and will not be

visible to other Workday customers

5

Using Software as a Service can

be compared to living in a

condominium

Over the course of the

implementation, 5 different McGill

tenants will support the project

deliverables – cf. Prototype Roadmap

Other

Workday

Customer

Other

Workday

Customer

Other

Workday

Customer

Notion of Prototype

A Prototype consists of loading McGill data into a Workday tenant.

The objective of Prototype 1 – i.e. the foundation tenant – is to help kick-start McGill’s ability to

learn and embrace the application by using actual – though imperfect – McGill data in Workday

Pre-production system

Represents the

configuration delivered at

go-live

Timing: before deployment

Configuration Prototype

A dedicated construction

specific to McGill

Timing: before testing

Initial Prototype

Sampling of

McGill data

▪PROTOTYPE 1 ▪PROTOTYPE 2 ▪GOLD

6

Notion of Workbook

▪ Document used to collect data attributes for electronic entry into Workday

▪ Includes transactional data and configuration data

▪ Considered to be the main foundation component to Prototype 1, i.e. Foundation Tenant

Configuration

Data

Transactional

Data

7

Consolidate

& streamlineConfigure

Prototype 1:Foundation Tenant: Core Team Only

Focus on Sampling of Current McGill Data:

- Core HCMWorkbook Data (basic processes configured)

-Active Employees only

- Top-of-Stack/Current State only

- Sampling of Academic-specific Data

Prototype 2:Configuration Tenant: Core Team + select audiences

Focus on broader Data Set:

- Full HCM Workbook

- Process-specific Data

- Academic-specific Data

- Data mapped to target processes

- Historical Data

Prototype 3:End to End Testing Tenant: Core Team + Change Enablers

Focus on Reloading P2 Data with any required refinements:

- Full & Complete HCM Workbook

- Full Academic-specific Data

- All process-specific Data

Prototype 4:Payroll Parallel Tenant

Focus on Reloading P3 Data with any required refinements:

- Full & Complete HCM Workbook

- Full Academic-specific Data

- All process-specific Data

GOLD Tenant:Pre-Production Tenant: University

Final Load into Tenant that will become the Production Environment:

All necessary data should be cleansed and converted:

- Full & Complete HCM Workbook

- Full Academic-specific Data

- All process-specific Data

Prototype Roadmap

The Prototype Roadmap is an iterative process

8

Timeline

9

10/29 - Go-live

Notes:

▪ Timeline for Data Archiving and Aggregated reports will be confirmed later this summer

▪ Timeline for Local Apps will be confirmed later this summer

2017 2018

Feb March April May June July Aug. Sept. Oct. Nov. Dec. Jan. Feb. Mars April May June July Aug Sept. Oct. Nov.

Project Phase PLAN/ADVISORY SERVICES ARCHITECT CONFIGURE & PROTOTYPE TESTPAYROLL PARALLEL

TESTDEPLOY

POST

PROD.

WD environment P1 P2 P3 P4 GOLD

Data Management:

ConversionP1 Data Prep P2 Data Prep P3 Data Prep P4 Data Prep GOLD Data Prep

HRMS Design/Build/Review configuration

Central IT systems

External systems

integration

Data Management: ODS

McGill

Architecture

Dis-

coveryDesign

Integrations Build &

Unit Tests

Integrations

Testing

HRMS: TestingTest strategy

Test plansTest scenario preparation End-to-End Testing Payroll Parallel Testing

Change ManagementChange

Strategy

Mobilization

(Core Team &

Change Enablers)

Detailed Impact Analysis

(Role, processes and

tools)

Informative Sessions

Training Needs Definition

Training

Development

Training

Delivery

10

▪ A focused Core Team will design the new HR solution in Workday, in line with the

best Higher-Ed practices

▪ R2R has appointed Process Owners and SMEs to cover the Staff/Admin/HR

aspects as well as the Academic/Faculty aspects of each process

o They come from central HR, the academic personnel central functions, as

well as from some Units and Faculties

o Some SMEs from Budget & Finance will help ensure critical handshakes are

covered

▪ Stakeholders from units not represented among the POs and SMEs will be kept

abreast of the decisions and impacts through a network of Change Enablers

Design approach

11

“Ask not how Workday can accommodate our as-is processes.

Ask how we can, with the guidance of our implementation partner, evolve toward

best practices”

Design golden rule

▪ WHY:

Software as a Service is based on best HR practices

Workday is a proven solution for Higher-Education institutions

While some flexibility exists, customization is not an option

▪ HOW:

Avoid the trap of over-customization

Rationalize

Standardize

Streamline

Automate

TO

MOVING FROM:

12

Some process-specific guiding principles

Blueprint process Guiding Principle / Objectives

Organizational Master Data & Position Management

o Analysis Planning and Budget (APB) will remain the owner of the McGill organizational structure (i.e. Org. Table)

HR Master Data & Life Event Management (Employee Record Management)

o Employee data will be entered as close as possible to the source using Employee Self-Service / Manager Self-Service / HR Advisors & Administrators

o Hire and termination process variations might be allowed based on employee groups but not on individual units

Compensationo HR Advisors and Academic administrators will have better

access to compensation analytics to facilitate decision making

Leaves

o Leave requests may be initiated by employees themselves using ESS

o Leave codes and policies will be consistent across the University per employee group

List not exhaustive

13

Some process-specific guiding principles (cont’d)

Blueprint process Guiding Principle / Objectives

Payroll Management

o Both current bi-weekly pay cycles will remain the same as current

o Current POPs payments will be performed through Workday including casual and ad-hoc off-cycle payments

Recruitment & Staffing / Onboarding o Focus will be on optimizing candidate and new-hire experience

Performance Management

o Will be mandatory in Workday for all M employees

o For ranked academics: mandatory in medicine. For other faculties, functionality will be activated at the request of the Dean

Academic Tenure & Promotiono The main objectives are to automate the process, and to

simplify and streamline the Committee membership selection process across faculties

List not exhaustive

14

Who are the Process Owners and SMEs?

Design sessions will be supported

by the Core Team comprising:

- The BSMs

- The Process Owners

- The SMEs

Change Management activities will

be supported by the Change

Enablers comprising, for each

Unit/Faculty:

- A Local Sponsor

- A Champion

- Some Super Users

15

Change Enablers

Objectives:

- Ensure that members are kept abreast of

WHAT, WHY and HOW things are changing

- Ensure new services work for the majority of

cases

- Harmonize new services with processes and

systems outside of R2R’s scope (e.g.

aggregate reporting)

- Help R2R evaluate overall satisfaction with

new end-to-end services

Change Enablers

Core Team

HR Central APO

IT9 Units and

Faculties

All other

Units and

Faculties

Some

Special

Interest

Groups TBD

▪ Beginning of the Architect Phase

– Compensation, Time Tracking and Absence design workshops

– Production of the corresponding Workbooks

▪ R2R Website launch

– Objective: to provide general information about the program to the wider McGill audience

▪Mobilization of the network of Change Enablers in the Units and Faculties

▪ Summer meeting schedule

16

Next steps

17