University of Dayton Product Design Doc WFS v2.1

Product Design Workforce Scheduler Version 6.2 University of Dayton Filename: University of Dayton Product Design Doc WFS v2.1.doc Version Date: 11/29/2011 DOCUMENT CONTROL Filename University of Dayton Product Design Doc WFS v2.0.doc Original Author(s) Scott Zeller, Application Consultant IV, Remote Scheduling Team Revision Author(s) CHANGE RECORD Version Date Author (s) Revision Notes 1.0 11/7/2011 Scott Zeller Initial draft 2.0 11/23/2011 Scott Zeller Second draft based upon needed changes discussed during 11/22/2011 meeting 2.1 11/29/2011 Scott Zeller Minor change to Section 5.23.2 to note times when full self service scheduling will be enabled APPROVALS DISTRIBUTION LIST Copy No Approver Name Title Margie Poeppelman Project Manager, Director Campus Card Services Mary Thompkins Scheduler, Catering Mary Eilbeck Scheduler, Marycrest Approval Date Copyright, 2008 Kronos Incorporated All rights reserved Information within is subject to change without notice University of Dayton Product Design Doc WFS Page of 85 TABLE OF CONTENTS INTRODUCTION 1.1 DOCUMENT PURPOSE 1.2 HOW TO REVIEW THIS DOCUMENT 7 EXECUTIVE SUMMARY 2.1 PROJECT BACKGROUND 2.2 PILOT UNITS 2.3 CUSTOMER GOALS FOR WORKFORCE SCHEDULER 2.3.1 2.3.2 2.3.3 2.3.4 OVERALL GOALS SUCCESS CRITERIA FOR WORKFORCE SCHEDULER GOALS OUTSIDE OF CURRENT PROJECT SCOPE GOALS OUTSIDE OF CURRENT PROJECT SCOPE THAT WOULD REQUIRE AN 2.4 PROJECT CONSIDERATIONS 9 9 10 10 10 RFE 11 CORE BUSINESS PROCESS ANALYSIS 12 3.1 CURRENT SCHEDULING/STAFFING PROCESSES - MARYCREST 12 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 12 12 12 13 13 13 CURRENT SCHEDULING PROCESS – BARGAINING UNIT CURRENT STAFFING PROCESS- BARGAINING UNIT RECOMMENDED WFS FEATURES – BARGAINING UNIT CURRENT SCHEDULING PROCESS – STUDENTS CURRENT STAFFING PROCESS — STUDENTS RECOMMENDED WFS FEATURES – STUDENTS 3.2 CURRENT SCHEDULING/STAFFING PROCESSES - CATERING 14 3.2.1 CURRENT SCHEDULING PROCESS 3.2.2 CURRENT STAFFING PROCESS 3.2.3 RECOMMENDED WFS FEATURES 14 15 15 3.3 RECOMMENDED SCHEDULING PROCESS WITH KRONOS 15 3.3.1 RECOMMENDED SCHEDULING PROCESS-MARYCREST 3.3.2 RECOMMENDED SCHEDULING PROCESS-CATERING 16 16 RECOMMENDED STAFFING PROCESS WITH KRONOS 3.3.3 RECOMMENDED STAFFING PROCESS-MARYCREST 17 17 WORKFORCE SCHEDULER PROCESS OVERVIEW & FEATURE MAPPING 18 FOUNDATIONAL ELEMENTS 4.1 FOUNDATIONAL ELEMENTS SOLUTION MAPPING 5.1 WORKFORCE SCHEDULER BUILDING BLOCKS 5.2 ORGANIZATIONAL MAPS University of Dayton Product Design Doc WFS 20 20 21 21 21 Page of 85 5.2.1 5.2.2 5.2.3 5.2.4 LOCATIONS TYPES ORGANIZATIONAL MAPPING TREE FOR PILOT UNITS EMPLOYEE SETUP MANAGER ACCESS SETUP 22 23 27 29 5.3 PAY CODES 30 5.3.1 CONCEPT DEFINITION 5.3.2 CONFIGURATION DESIGN 5.3.3 PROCESS MAPPING 30 30 32 5.4 SCHEDULE PERIOD 32 5.4.1 CONCEPT DEFINITION 5.4.2 CONFIGURATION DESIGN 5.4.3 PROCESS MAPPING 32 32 32 5.5 SHIFT TEMPLATES 33 5.5.1 CONCEPT DEFINITION 5.5.2 CONFIGURATION DESIGN 5.5.3 PROCESS MAPPING 33 33 35 5.6 PATTERN TEMPLATES 35 5.6.1 CONCEPT DEFINITION 5.6.2 CONFIGURATION DESIGN 5.6.3 PROCESS MAPPING 35 35 36 5.7 SCHEDULE TEMPLATES 36 5.7.1 CONCEPT DEFINITION 5.7.2 CONFIGURATION DESIGN 5.7.3 PROCESS MAPPING 36 36 36 5.8 AVAILABILITY 37 5.8.1 CONCEPT DEFINITION 5.8.2 CONFIGURATION DESIGN 5.8.3 PROCESS MAPPING 37 37 37 5.9 SKILLS & CERTIFICATIONS 38 5.9.1 CONCEPT DEFINITION 5.9.2 CONFIGURATION DESIGN 5.9.3 PROCESS MAPPING 38 38 38 5.10 WORKLOAD SETUP 39 5.10.1 CONCEPT DEFINITION 5.10.2 CONFIGURATION DESIGN 5.10.3 PROCESS MAPPING 39 39 42 5.11 COVERAGE COUNTING 42 5.11.1 CONCEPT DEFINITION 5.11.2 CONFIGURATION DESIGN 5.11.3 PROCESS MAPPING 42 42 43 5.12 EMPLOYEE RULE SETS 43 5.12.1 CONCEPT DEFINITION 5.12.2 CONFIGURATION DESIGN 5.12.3 PROCESS MAPPING 43 43 45 5.13 ORGANIZATIONAL RULE SETS 45 5.13.1 CONCEPT DEFINITION 5.13.2 CONFIGURATION DESIGN 5.13.3 PROCESS MAPPING 45 45 47 5.14 ORGANIZATIONAL SETS 48 5.14.1 CONCEPT DEFINITION 5.14.2 CONFIGURATION DESIGN 5.14.3 PROCESS MAPPING 48 48 49 5.15 GENIES 49 5.15.1 CONCEPT DEFINITION 5.15.2 CONFIGURATION DESIGN 49 49 University of Dayton Product Design Doc WFS Page of 85 5.15.3 PROCESS MAPPING 52 5.16 HYPERFINDS 53 5.16.1 CONCEPT DEFINITION 5.16.2 CONFIGURATION DESIGN 5.16.3 PROCESS MAPPING 53 53 53 5.17 SCHEDULE ASSISTANT 54 5.17.1 CONCEPT DEFINITION 5.17.2 CONFIGURATION DESIGN 5.17.3 PROCESS MAPPING 54 54 56 5.18 COMMENTS 57 5.18.1 CONCEPT DEFINITION 5.18.2 CONFIGURATION DESIGN 5.18.3 PROCESS MAPPING 57 57 57 5.19 MINOR RULES 57 5.19.1 CONCEPT DEFINITION 5.19.2 CONFIGURATION DESIGN 57 58 5.20 SCHEDULE GROUPS 58 5.20.1 CONCEPT DEFINITION 5.20.2 CONFIGURATION DESIGN 5.20.3 PROCESS MAPPING 58 58 58 5.21 CALENDARS 59 5.21.1 CONCEPT DEFINITION 5.21.2 CONFIGURATION DESIGN 5.21.3 PROCESS MAPPING 59 59 60 5.22 WORKLOAD GENERATOR 60 5.22.1 CONCEPT DEFINITION 5.22.2 CONFIGURATION DESIGN 5.22.3 PROCESS MAPPING 60 60 61 5.23 SELF SCHEDULING 61 5.23.1 CONCEPT DEFINITION 5.23.2 CONFIGURATION DESIGN – AVAILABLE FUNCTIONALITY CONFIGURATION 5.23.1 RETURNING OPEN SHIFTS 5.23.2 PROCESS MAPPING TO THE ORIGINAL EMPLOYEE AND 61 FUNCTION ACCESS PROFILE 61 63 64 5.24 SCHEDULE GENERATOR 64 5.24.1 CONCEPT DEFINITION 5.24.2 CONFIGURATION DESIGN 5.24.3 PROCESS MAPPING 64 64 65 5.25.1 CONCEPT DEFINITION 5.25.2 CONFIGURATION DESIGN 5.25.3 PROCESS MAPPING 65 66 69 5.26 METRICS 69 5.26.1 CONCEPT DEFINITION 5.26.2 CONFIGURATION DESIGN 5.26.3 PROCESS MAPPING 69 69 72 5.25 PRIORITY SCHEDULING ENGINE, CALL LIST, AND EMPLOYEE SORT 65 DATA ACCESS & SYSTEM SETTINGS 6.1 DISPLAY PROFILES 6.2 DATA ACCESS PROFILES 6.3 FUNCTIONAL ACCESS PROFILES University of Dayton Product Design Doc WFS 73 73 73 74 Page of 85 6.4 SYSTEM SETTINGS DATA EXCHANGE 74 78 7.1 INTERFACE OVERVIEW 78 7.1.1 PEOPLE IMPORT 78 REPORTING 81 8.1 PURPOSE 8.2 REQUIRED REPORTS 81 81 8.2.1 WEEK SCHEDULE REPORT 8.2.1 WEEK SCHEDULE REPORT 8.2.2 STAFFING BY ZONE REPORT 81 82 83 ACCEPTANCE – SIGN OFF University of Dayton Product Design Doc WFS 84 Page of 85 INTRODUCTION 1.1 DOCUMENT PURPOSE The Product Design Workshop was designed to enable Kronos to consult with your organization from the basis of your existing and desired business processes, referencing the key Workforce product features and configurable elements, and leading to a design which will enable the optimization of your business in line with the project goals and success criteria This document is the output of this consultation, and draws together the business requirements for University of Dayton It will detail the information required to successfully implement Workforce Scheduler including all related business and product processes, stakeholders’ goals, key configuration components and data exchange requirements The information contained in this document is based upon this Assessment which was completed on 11/1/2011 and all reviewed preparatory works (checklists and training outcomes) provided by the University of Dayton project team Any features or functionality not mentioned herein will not be included for Workforce Scheduler within the Kronos Solution Following the acceptance of the Kronos WFS Product Design, any requirements not detailed within this document will be subject to the project standard Change Control procedures 1.2 HOW TO REVIEW THIS DOCUMENT As discussed above, this document allows Kronos to successfully implement Workforce Scheduler, based on your organizations goals and success criteria It allows Kronos to transition from the analysis of your organization’s existing and proposed automated or optimized processes, to the configuration of the Product required to achieve these In reviewing this document, you will note that for each process, attention is drawn to the applicable product features, configuration elements and suggested optimization opportunities It is recommended that the detail of these items be reviewed as you review each process, to ensure that: • The impact of each feature and configuration “building block” on this process has been sufficiently defined by Kronos, • Kronos has accurately gathered information on your policies and procedures related to this process, and • That you understand the possibilities which exist to further optimize this process beyond that contained within the currently documented solution The following sections are contained within this Product Design Document: • Current goals and success criteria for Workforce Scheduler as discussed in the Product Design Workshop These are the high level goals and success criteria for this product implementation, and it is critical that both your organization and Kronos have defined these accurately Your goals and success criteria will be referred to throughout the project in University of Dayton Product Design Doc WFS of 85 Page order to develop testing and educational strategies and to measure project success at the end of the implementation • Foundational Elements of your organization, relating to Workforce Scheduler This section defines the key elements already existing within your organization’s makeup which form the basic foundation to which your organization’s policies and procedures refer, and by which the Kronos Workforce solution will operate • Current and future core business process analysis, including any opportunities for further process optimization You will note here that reference is made to the product features and the configuration building blocks which combine to deliver the solution to meet your business needs This enables you to review these components in conjunction with the process to ensure that Kronos has captured all the relevant information to finalize the solution design • Product design and configuration requirements based upon the mapping of your organization’s policies and procedures to the Workforce product functionality Each feature within the Workforce Scheduler system utilizes a combination of configuration requirements which are determined through an analysis of your organization’s structure, policies, and procedures During the Product Design Workshop, your Kronos representative consulted with your Project Team and subject matter experts to determine the best practice approach to mapping your requirements to the Product functionality to achieve the optimized solution The results of this consultation are documented in this section, and are to be reviewed in conjunction with the processes documented above • Requirements for Data Exchange within the Kronos Solution and between Kronos and any third party systems The automation and optimization solutions achieved by the Kronos Workforce suite of products rely on the exchange of workforce data between key systems in your organization This data may be historical records existing prior to the Workforce Scheduler implementation, data exchanged with Kronos products, or data which needs to enter and leave Workforce Scheduler The key systems of record for this data, and the processes and responsibilities for the data exchange are detailed within this section of the Product Design Processes defined here should be referenced to your organization’s core business processes to fully understand the lifecycle of data within your Kronos solution University of Dayton Product Design Doc WFS of 85 Page EXECUTIVE SUMMARY 2.1 PROJECT BACKGROUND Kronos and University of Dayton have just begun the process of assessment for Workforce Scheduler Workforce Timekeeper v6.2 has been live since about mid-August 2011 and the company now has the desire to roll out Workforce Scheduler to further optimize its scheduling of labor Please refer to the Workforce Scheduler product documentation for further terminology definitions if necessary 2.2 PILOT UNITS The following Pilot Units are the first units to setup their department, to be trained on WFS, and to test WFS by being the initial units going live with WFS The Schedulers and Managers from the following Pilot Units participated in the Core Business Process Analysis at the Product Design Workshop: Pilot Units Pilot Unit Participants Marycrest Mary Eilbeck, Scheduler Sue Falter, Scheduler Mike Heath, Scheduler Ted Sotphin, Scheduler Catering Mary Thompkins, Scheduler 2.3 CUSTOMER GOALS FOR WORKFORCE SCHEDULER The following are the customer goals that were captured during the Plan and Assess stages 2.3.1 OVERALL GOALS Goals Description Employee Scheduling Self Service Currently, the ability for employees to take care of their own schedule changes by trading or covering shifts is key to successful automation Automation of Automated Time Off Request (TOR) The University of Dayton wants to eliminate any manual processes for bargaining unit or regular full-time employees regarding the request of time off and will implement the TOR in Workforce Scheduler Ability to Handle Mass Changes during Certain Periods of the Year In Dining Services, during Christmas and Summer, many of the dining areas close and employees are moved to other areas A quick method is needed to change the employees default location to the new hall for this time Help with Rules Enforcement for Bargaining Unit Employees Schedulers are required to give one weekend off a month Also, overtime is to be offered by University of Dayton Product Design Doc WFS of 85 Page seniority Workforce Scheduler/Timekeeper has tools to help with both instances Technical Item: To automatically return open shifts to the original holder of the shift if they are not filled 12 or fewer hours before start of shift This will require a Workforce Integration Manager link to this, as it’s not a native function of Scheduler This is not technically in scope but will be handled as a part of this roll out and documented via a Change Order Some reports may require customization such as the Location Schedule Weekly Will need to be discussed, either UD or Kronos can take this on Further testing may reveal additional needed reports This is not technically in scope but will be handled as a part of this roll out and documented via a Change Order 2.3.2 SUCCESS CRITERIA FOR WORKFORCE SCHEDULER Below are the project’s success criteria as determined by the project team: Goals Description Employees must be able to utilize self-scheduling to perform shift trades and shift swaps This is done today, so it is key to maintain similar functionality through Workforce Scheduler Schedulers must be able to print the schedule at least a week in advance and make it available to employees This is easily done by running a report such as the “Location Schedule Weekly” or “Location Schedule Monthly” for the appropriate timeframe The scheduling process needs to be kept as simple and clear-cut as possible The design of Workforce Scheduler should be such that the scheduling/staffing process is kept as easy as possible within the WFS application 2.3.3 GOALS OUTSIDE OF CURRENT PROJECT SCOPE Below are the goals outside of the project scope: Goals Description Creation of Staffing Matrices and a Workload Generator Import for Catering As part of a second phase, UD would like to create staffing matrices that dictate needed staffing levels in Catering Likewise, they would like to import covers and breaks from EMS to drive the Workload Generator This can all be done, but is not in scope Import of availability from student class schedules UD will be taking this on, but if assistance from Kronos is required this is out of scope 2.3.4 GOALS OUTSIDE OF CURRENT PROJECT SCOPE THAT WOULD REQUIRE AN RFE Below is an overview of the major goals discussed during the Design Workshop that are not in the current project scope Unless noted otherwise, all goals listed below are not in upcoming functionality, thus, they will need to be submitted to Kronos as a request for enhancement: Goals University of Dayton Product Design Doc WFS 10 of 85 Description Page How to Group the Data Group Order Group By Zone Zone Job Zone Parameter Column Label Indicators to Display Indicator Order Indicator Summary All Days Summary Primary Job Headcount Sum Sum Metric Name DiningCatering Coverage Summary Description Shows coverage by Job job Location(s): Catering Only How to Group the Data Group Order Group By Parameter Column Label Location Sub Unit Location Job Job Indicators to Display Indicator Order Indicator Summary All Days Summary Required Relative to Timespan Sum Sum Coverage Relative to Timespan Sum Sum Variance Relative to Timespan Sum Sum All end users with access to Schedule Planner will also have access to the metrics above University of Dayton Product Design Doc WFS 71 of 85 Page 5.26.3 PROCESS MAPPING Metrics will primarily used during the following portions of the scheduling and staffing process: • Evaluate & Post Schedule • Modify & Update Schedule • Staffing Changes University of Dayton Product Design Doc WFS 72 of 85 Page DATA ACCESS & SYSTEM SETTINGS 6.1 DISPLAY PROFILES A Display Profile is the setup per Display group that determines how information is presented and which available genies and functions are available to different groups of users The following is a list of recommended Display Profiles that will be setup for Workforce Scheduler The easiest way to accomplish this is to duplicate the existing profiles and then modify them to meet the needs below Time format 12 or 24 hours? Schedule Period Workforce Genie Profile Custom URL Profile DiningCatering WFS Employee 12 Week Dining-WFS Employee N/A Workload Planner Profile DiningMarycrest WFS Employee Add Shift labels Week DiningMarycrest WFS Manager N/A Workload Planner Profile Week DiningCatering WFS Manager N/A Workload Planner Profile Display Group DiningMarycrest WFS Manager DiningCatering WFS Manager 12 12 Workload Planner Profile 6.2 DATA ACCESS PROFILES Data access profiles specify and limit the schedule groups and templates that managers can access Data access profiles exist for Pay Codes, Work Rules, Reports, Shift Templates, Pattern Templates, Schedule Groups, and Availability Templates The following is a list of recommended Data Access Profiles that will be setup for Workforce Scheduler Data Access Profile Name DiningEmployee Pay Codes Description Used for employees, should include pay Pay Codes Work Rules Reports Shift Templates Pattern Templates Schedule Groups Yes University of Dayton Product Design Doc WFS 73 of 85 Page codes which the employee can request off WFS Manager Used for all WFS Managers, includes scheduling reports DiningMarycrest Shifts Used for Managers and Employees DiningMarycrest Schedule Groups Yes Yes Used for Managers Yes 6.3 FUNCTIONAL ACCESS PROFILES Function Access Profiles determine the functions that users can perform in the Workforce Central system A Function Access Profile is assigned to Workforce Managers and Workforce Employees Function Access is composed of access control points that determine Scope (Allow or disallow user to perform a function.) and Action (Level of access (Add, Edit, Delete, View)) The following is a list of recommended Functional Access Profiles that will be setup for Workforce Scheduler with a brief description of each profile Function Access Groups Description UD-Scheduling Manager Full access granted to all WFS features, including setup/editing of volume, staffing matrices, and workload Ability to assign employees to schedule groups will also be provided Access to timekeeping functions are also granted UD-Scheduling Supervisor Access to all operational WFS features Volume and workload may be viewed, but NOT changed Super Access Full access to all WFS features, including the ability to set up all WFS functionality 6.4 SYSTEM SETTINGS The following are the recommended System Settings for Workforce Scheduler in the Global and Scheduling System Setting tabs University of Dayton Product Design Doc WFS 74 of 85 Page System Settings Name Description Default Value site.scheduling.schedulePlanner.summaryTabs.o rgPathLevelsToDisplay Sets max number of org levels to be displayed on the schedule planner summary tabs site.scheduling.minorrules.requirebirthdate true Specifies if the birth date is required for a person FALSE site.scheduling.selfscheduling.requestcategory category of process templates launched in self scheduling app ALL site.scheduling.dailycoverage.visiblebydefault true Specifies if the daily coverage area of the Schedule Planner is visible by default FALSE site.scheduling.schedulePlanner.Hours Per Volume.hoursStatistic.paidHoursPerVolume true Specifies if Hours Per Volume is paid time instead of actual time FALSE site.scheduling.schedulePlanner.Hours Per Volume.useFirstScheduleZoneForDayStart true Use a location's first Schedule Zone to determine when a day starts and ends on the Hours Per Volume tab FALSE site.scheduling.schedulePlanner.Hours Per Volume.budgetHours Per Volume.useImportedValue.locationTypes List of comma separated Location Types that import Budget Hours Per Volume rather than calculate Null site.scheduling.schedulePlanner.Hours Per Volume.budgetHours.deriveHoursFromHours Per VolumeValue.locationTypes List of comma separated Location Types that define Budget Hours as Budget Hours Per Volume times Volume Null site.scheduling.schedulePlanner.Hours Per Volume.budgetVolume.useImportedValueOnly.lo cationTypes List of comma separated Location Types that always display stored Budget Volume values Null site.scheduling.schedulePlanner.Hours Per Volume.budgetVolume.useLargestChild.locationT ypes List of comma separated Location Types that use the largest Budget Volume value of its children locations Budget Volume instead of using the sum of the values Null site.scheduling.schedulePlanner.Hours Per Volume.budgetVolume.useSumOfSelfAndChildre nValues.locationTypes List of comma separated Location Types that define Budget Volume as the sum of the Location's stored value and children location values Null site.scheduling.schedulePlanner.Hours Per Volume.scheduleVolume.useImportedValueOnly.l ocationTypes List of comma separated Location Types that always display stored Schedule Volume values Null site.scheduling.schedulePlanner.Hours Per Volume.scheduleVolume.useLargestChild.locatio nTypes List of comma separated Location Types that use the largest Schedule Volume value of its children locations Schedule Volume instead of using the sum of the values Null site.scheduling.schedulePlanner.Hours Per Volume.scheduleVolume.useSumOfSelfAndChildr enValues.locationTypes List of comma separated Location Types that define Schedule Volume as the sum of the Location's stored value and children location values Null University of Dayton Product Design Doc WFS 75 of 85 Recomme nded Value TRUE Page System Settings Name Description Default Value site.scheduling.schedulePlanner.Hours Per Volume.actualVolume.useImportedValueOnly.loc ationTypes List of comma separated Location Types that always use stored Actual Volume values Null site.scheduling.schedulePlanner.Hours Per Volume.actualVolume.useLargestChild.locationT ypes List of comma separated Location Types that use the largest Actual Volume value of its children locations Actual Volume instead of using the sum of the values Null site.scheduling.schedulePlanner.Hours Per Volume.actualVolume.useSumOfSelfAndChildren Values.locationTypes List of comma separated Location Types that define Actual Volume as the sum of the Location's stored value and children location values Null global.WtkScheduler.availability.defaultAvailType UnavailableUnknownAvailable Default Availability Unknown global.WTKScheduler.CalculateOpenShifts.thres hold The coverage threshold percentage for non-standard shifts used to calculate open shifts global.WTKScheduler.CalculateOpenShifts.UseN onStandShifts true Set to true if non-standard shifts are used to calculate open shifts FALSE global.WtkScheduler.hoursBelongTo Scheduled in dayScheduled out day Scheduled hours belong to day Day actually worked will split hours across midnight day divide Scheduled in day global.WtkScheduler.MaxDaysToMarkScheduleO utOfDate The maximum number of days in the future that schedule changes not need to be totalized 31 global.WtkScheduler.MaximumDaysInFutureToCr eateShifts This value limits how far in the future shifts will be created at any one time 270 global.WtkScheduler.MaximumInListForHyperfin d Maximum number of employees that can be returned in a Hyperfind query 600 global.WtkScheduler.MaximumNoOfRuleViolatio nsSentToClient The maximum number of Rule Violations sent to the client from the server 50 global.WtkScheduler.MinimumHoursInFutureToS wapShifts The minimum number of hours in the future employees are allowed to swap shifts 72 global.WtkScheduler.ShiftBuilderGovernor.Active 01 Activate the Shift Builder Governor (0: off 1: on) global.WtkScheduler.ShiftBuilderResultsTimeToLi ve AVAILABLE Fixed Rule 365 36 global.WtkScheduler.ShiftBuilderGovernor.Days Days to limit shift building 30 global.WTKScheduler.ShiftCoverageCounting.Re quireExactMatch true If true, coverage is restricted to count only the scheduled shifts with start and end times that FALSE University of Dayton Product Design Doc WFS 76 of 85 Recomme nded Value Page System Settings Name Description Default Value Recomme nded Value exactly match the start and end times of the planned shifts If false, coverage also counts any combination of scheduled shifts that together provide coverage for the complete planned shifts University of Dayton Product Design Doc WFS 77 of 85 Page DATA EXCHANGE 7.1 INTERFACE OVERVIEW The Workforce Central system may interact with one or more other business systems Organizations develop interfaces to automate the setup and maintenance of key information required for Workforce Scheduler, and also to ensure a secure and consistent means of providing those updates Kronos recommends the following interfaces be developed and implemented in conjunction with Workforce Scheduler Requirements and specifications of all approved interfaces will be developed through the Interface Design Workshop, and documented in the Interface Design Document Recommended Interfaces People Import Recommendation Description Update Update existing interface to populated required fields for WFS implementation See Section 7.1.1 for more information on People Record fields impacted by WFS In-Scope? No 7.1.1 PEOPLE IMPORT The People Import, also known as the Personality Import, is the most common interface used in conjunction with Workforce Central Suite of Products Prior to Workforce Scheduler implementation, many organizations have implemented an interface that updates the People Records fields with information that defines how transaction data will be process for WTK and possibly other Kronos products For those employees whose schedules will be tracked with Workforce Scheduler, modification to People record fields may be required, and additional fields will need to be populated The following table lists the fields of the People Record which can impact Workforce Scheduler Kronos recommends that the project team being discussion about the process and personnel / roles that will be responsible for building and maintaining this information in Kronos or other source systems Note: initially, these fields will be manually updated in the pilot The interfaces can be modified if the decision is made to go forward into production University of Dayton Product Design Doc WFS 78 of 85 Page Field Manual or Interface? Notes Scheduler License Interface Primary Job Reports To Schedule Group Employee Rule Set Function Access Profiles Display Profiles Pay Code View (Mgr) Work Rule Profile (Mgr) Interface Interface Manual Interface Interface Interface N/A N/A Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send In Existing Interface Required? No Yes No Yes No Yes No No No Yes No Yes No Yes No Yes No No No Yes Reports Profile (Mgr) N/A Org Group (Mgr) Manual This must be manually assigned No Yes Job Transfer Set (Mgr) Manual This must be manually assigned No Yes No Yes No Yes No Yes No Yes No Yes Schedule Group Profile (Mgr) Manual Shift Template Profile (Mgr) Manual Pattern Template Profile (Mgr) Manual Availability Pattern Profile (Mgr) Pay Code Edit Profile (Employee) Manual Interface University of Dayton Product Design Doc WFS 79 of 85 Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Current interface must be changed to send Page Shift Template Profile (Employee) Interface Job Transfer Set (Employee) Manual Scheduling Workflow Manager Interface University of Dayton Product Design Doc WFS 80 of 85 Current interface must be changed to send Must be manually assigned This is the employee to whom scheduling requests other than the Time Off Request are routed to No Yes No Yes No Yes Page REPORTING 8.1 PURPOSE Having up-to-date and accurate reports is critical to making daily staffing decisions and monitoring the effectiveness of a schedule It is vital to the success of this project that all schedule, staffing, and key management Reports are created and tested before the Pilot Go live phase 8.2 REQUIRED REPORTS The following are the reports that must be created in order to have a successful Workforce Scheduler implementation 8.2.1 WEEK SCHEDULE REPORT Purpose: The week schedule that is posted for the employees Areas Requiring Report: Marycrest Kronos Report: Location Schedule Monthly Modifications Required: None University of Dayton Product Design Doc WFS 81 of 85 Page 8.2.1 WEEK SCHEDULE REPORT Purpose: The week schedule that is posted for the employees Areas Requiring Report: Catering Kronos Report: Location Schedule Weekly Modifications Required: Yes, the report will need to be modified to show the shift label and not the shift start/end University of Dayton Product Design Doc WFS 82 of 85 Page 8.2.2 STAFFING BY ZONE REPORT Purpose: This is the daily staffing report, showing who’s scheduled to work and during which periods of the day Areas Requiring Report: All Units Kronos Report: Staffing by Zone Report Modifications Needed: To be determined in testing University of Dayton Product Design Doc WFS 83 of 85 Page ACCEPTANCE – SIGN OFF Please read this document thoroughly, as it outlines the software methodology and the product configuration of Workforce Scheduler for University of Dayton Any features or functionality not mentioned herein will not be included in the solution build Any additional requirements not mentioned within this document will be subject to standard Change Control procedures This design document supersedes any previous written or verbal description regarding the operation of the Kronos system being implemented for University of Dayton The system defined in the statement accurately describes the requirements for our implementation Any changes to these requirements will be assessed on a case-by-case basis, and may involve the use of a “Project Change Request” All Project Change Requests will be subject to joint agreement and may incur additional cost, time and other impacts to the University of Dayton project Your signature below attests that you have read, understand and agree to the implementation solution put forth within this Product Design Document and that this document constitutes the full Workforce Scheduler configuration required to be performed by Kronos for University of Dayton I understand and agree with the contents of this document as presented I have reviewed it and am satisfied it will fulfill our current requirements By signing this document I confirm I have the authority to so on behalf of University of Dayton Acceptance Certificate Customer Name University of Dayton Document Title University of Dayton Product Design Doc WFS v2.1.doc Document Revision Date 11/29/2011 For and on behalf of University of Dayton Name Position Signed Date For and on behalf of Kronos Name Position Signed Date University of Dayton Product Design Doc WFS 84 of 85 Page University of Dayton Product Design Doc WFS 85 of 85 Page ... under it University of Dayton Product Design Doc WFS Page 25 of 85 University of Dayton Product Design Doc WFS Page 26 of 85 5.2.3 EMPLOYEE SETUP Employees need the following pieces of information... Processes is used in this scheduling process University of Dayton Product Design Doc WFS 18 of 85 Page University of Dayton Product Design Doc WFS 19 of 85 Page FOUNDATIONAL ELEMENTS 4.1 FOUNDATIONAL... 5:00a University of Dayton Product Design Doc WFS 39 of 85 End Time Page … 0030-0100 0030-0100 12:30a 1:00a 23000000 2300-0000 11:00p 12:00 a University of Dayton Product Design Doc WFS 40 of 85