Vehicle_and_Operator_Scheduling_Requirements.xlsx

XLSX spreadsheet 51 KB Posted

Attached to
Fixed Route Vehicle and Operator Scheduling Software
Solicitation number
471
Issued by
Los Angeles County, San Francisco City, California

About this file

This is a Vehicle and Operator Scheduling Requirements document for the City of Santa Monica, California, establishing comprehensive software specifications for fixed route vehicle scheduling, operator workforce management, and timekeeping integration. The system must support vehicle scheduling functions including mapping capabilities with GIS integration, route definition and scheduling, blocking, run cutting, and reporting analytics. The operator scheduling component requires absence management, bidding processes, customer feedback tracking, dispatch management, labor rules enforcement, operator assignments, sign-in functionality, web portal access, timekeeping and payroll processing, and workforce management capabilities including training and incident investigation. The system must interface with existing City infrastructure including the CAD/AVL system (Clever Devices), Tyler Munis ERP system, and UKG workforce management platform, while supporting yard management with real-time vehicle tracking and status monitoring.

The requirements encompass system deployment options including local hosting, cloud hosting, or full SaaS delivery models, with pricing provided for all three approaches. The system must operate on Windows 10, Windows 11, and future Windows releases, support modern web browsers, comply with WCAG 2.1 Level AA accessibility standards, and encrypt data in transit using TLS 1.2 or higher and at rest using AES-256. The contractor must provide a minimum one-year warranty from system acceptance with optional extended warranties for up to five additional years, plus five one-year terms thereafter at the City's discretion. Implementation requirements include complete data migration from the current system, comprehensive training for all affected staff in three stages (test environment, parallel implementation, and post-implementation), on-site support at Santa Monica headquarters, technical support via toll-free number and online incident management portal, and defined response time commitments with liquidated damages provisions for non-compliance. The contractor must maintain SOC 2 Type II and ISO 27001 certifications, provide automated daily backups with 24-hour maximum data loss, achieve four-hour recovery time and 24-hour recovery point objectives, and support at least 125 concurrent users without performance degradation.

View the file

Other files

File Type Posted
Fixed_Route_Vehicle_and_Operator_Scheduling_Software.pdf PDF
Fixed_Route_Vehicle_and_Operator_Scheduling_Software.pdf PDF
Enterprise_Core_Technologies.pdf PDF
Glossary.docx DOCX document
City_of_Santa_Monica_VISA_Questionnaire_3.1.docx DOCX document
Glossary.docx DOCX document
Software_as_a_Service_Template_(11-25).docx DOCX document
Software_as_a_Service_Template_(11-25).docx DOCX document
Technology_Services_Template.docx DOCX document
Architecture_Questionnaire.pdf PDF
Enterprise_Core_Technologies.pdf PDF
Software_Maintenance_Agreement_Template.docx DOCX document
Architecture_Questionnaire.pdf PDF
Vehicle_and_Operator_Scheduling_Requirements.xlsx XLSX spreadsheet
Technology_Services_Template.docx DOCX document
City_of_Santa_Monica_VISA_Questionnaire_3.1.docx DOCX document
Software_Maintenance_Agreement_Template.docx DOCX document
Proposer_Checklist.pdf PDF
Proposer_Checklist.pdf PDF
Show all 19

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Vehicle Schd. Requirements

Requirement IDCategoryDescriptionCan Comply (Y/N) / If No (N), Identify Exception and Reason
1001User Interface and MappingThe system shall include a mapping component which has the ability to import base map data including Route_Trace_Patterns, Transit_Centers, Layover_Points, Bus_Stops, Bus_Stop_Amenities, and Timetable creation.
1002User Interface and MappingThe system's mapping component shall support point, line, and polygon Shapefiles.
1003User Interface and MappingThe system's mapping component shall provide the ability for users to create, modify, and delete shapefiles.
1004User Interface and MappingThe system shall allow users to draw or attach map images for off-street or internal facilities not shown in underlying maps.
1005User Interface and MappingWhen a new Geographic_Information_System (GIS) map street network is imported, the system's shall identify modifications to the street network and allow for the modifications to be saved.
1006User Interface and MappingThe system shall possess a user interface for generating and displaying completed Vehicle_Schedules, which can be toggled between tabular and GIS map views.
1007User Interface and MappingThe system shall provide configurable tabular views (moveable/resizable/sortable columns) for all Trip_Building, Blocking, Run_Cutting and Rostering modules.
1008User Interface and MappingThe system shall have both “copy+paste” and “cut+paste” features allowing users to copy or cut data from one Schedule to another or within the same Schedule including one or more Trips, Blocks or Runs or a combination of Trips, Blocks, and/or Runs.
1009User Interface and MappingWithin any system module, the system shall allow users to search for and filter by any associated attributes of Stops, Trips, Runs, and/or Blocks.
1010User Interface and MappingThe system shall allow users to create datasets of any Trips, Blocks, Runs, Rules, attributes, parameters, or other data from any window based on their characteristics and produce statistics by groups based on selected parameters.
1011User Interface and MappingThe system shall allow users to have two or more instances of the software or any individual schedule open at one time, preferably in a tabbed view.
1012User Interface and MappingThe system shall allow any available Schedule version to be opened and displayed on demand.
1013User Interface and MappingThe system shall record data validation or quality errors.
1014User Interface and MappingThe system shall use consistent nomenclature (icons or names or both) throughout the system’s interface at all functional levels.
1015User Interface and MappingThe system shall allow the user to create custom fields in any system module.
1016User Interface and MappingThe system shall track schedule version history and allow rollback/restore of prior versions.
1017User Interface and MappingThe system shall log all users and user actions for traceability.
1018Route Definition and SchedulingThe system shall be able to automatically assign Bus_Stops to Route_Patterns or Route_Segments between two or more Timepoints.
1019Route Definition and SchedulingThe system shall allow an unlimited number of Trip_Patterns to be defined as distinct Bus_Stop_Sequences.
1020Route Definition and SchedulingThe system shall allow users to designate selected Bus_Stops in each Trip_Pattern as schedule Timepoints.
1021Route Definition and SchedulingThe system shall allow users to manually override parameters for any Bus_Stop location, Trip, Block, or Run.
1022Route Definition and SchedulingThe system shall calculate distances of and display Route_Segments for Deadhead links, entire revenue Trip_Patterns, as well as any selected Trip_Pattern segments.
1023Route Definition and SchedulingThe system shall be able to show the distance, Planned_Travel_Time, and Segment_Speeds between sets of Bus_Stops or entire Trips
1024Route Definition and SchedulingThe system shall present a map display of all Trip_Patterns occurring within any date and time range defined by the user.
1025Route Definition and SchedulingThe system shall automatically generate turn-by-turn routing instructions for each separate Trip_Pattern to be displayed, exported, or printed on reports designated by users.
1026Route Definition and SchedulingThe system shall allow Routes to be defined as a sequence of Trips using selected Trip_Patterns during defined time periods.
1027Route Definition and SchedulingThe system shall allow users to specify the minimum and maximum Recovery_Times at specific Layover_Points.
1028Route Definition and SchedulingThe system shall allow for manual and system-proposed schedule refinements.
1029Route Definition and SchedulingAll relevant scheduling data and parameters (e.g. Stop_ID, Stop_Location, Length_On_Stops, etc) shall be merged and held in a common system database.
1030Route Definition and SchedulingThe system shall allow users to create and schedule Unique_Trips any time during a Sign-Up_Period.
1031Route Definition and SchedulingThe system shall provide suggested Running_Times based on current Block/Run data and historical Running_Time data.
1032Route Definition and SchedulingThe system shall provide predictive optimization (AI or rules-based) for running time and schedule refinement.
1033Route Definition and SchedulingThe system shall allow for system- or user-defined On_Time_Performance (OTP) parameters to be utilized for calculating and defining Running_Times.
1034Route Definition and SchedulingThe system shall be able to apply Run_Times to Trips and Trip_Segments based on the time of day the bus enters the Trip_Segment, instead of only based on the Trip start time.
1035Route Definition and SchedulingThe system shall allow users to manage any type of service, planned or unplanned.
1036Route Definition and SchedulingThe system shall allow users to create, activate, deactivate, rename, and edit Detours in a schedule.
1037Route Definition and SchedulingThe system shall allow for various types of services including, but not limited to, Revenue_Routes, Non-Revenue_Routes, Shuttles, and Special_Routes.
1038Route Definition and SchedulingThe system shall allow Route_Terminal_Point_Capacity_Limits to be configured by Line and total vehicles, and shall warn users if the capacity is exceeded when schedules are built.
1039Route Definition and SchedulingThe system shall allows users to categorize Timepoints as public and/or internal.
1040Route Definition and SchedulingThe system shall allow individual Bus_Stops to be set as active or inactive.
1041Route Definition and SchedulingThe system shall estimate bus Arrival_Times at Bus_Stops between designated Time_Points.
1042Route Definition and SchedulingThe system shall allow users to add comments to any vehicle scheduling system attribute, including, but not limited to: Time_Points, Bus_Stops, Patterns, Trips, Routes, Blocks, Operator Runs, and Rosters.
1043Route Definition and SchedulingThe system shall allow users to select any Time_Point as the build point for a route.
1044Route Definition and SchedulingThe system shall be able to display and/or modify all Trip_Path types and Segment_Speed_Factors on a GIS map or in table form.
1045Route Definition and SchedulingThe system shall allow users to export map views of modified Trip_Paths as .PDF or .jpeg file types.
1046Route Definition and SchedulingThe system shall allow for any point to be used for sorting in the schedule, even if the sort point is different from the build point.
1047BlockingThe system shall provide schedule validation engine to detect conflicts (orphan trips, unassigned blocks, inconsistent times).
1048BlockingThe system shall allow users to designate one or more yards/garages that can be attributed to specific Blocks.
1049BlockingThe system shall be capable of manual or automated Trip_Building using Route_Trip_Pattern_Sequences.
1050BlockingThe system shall allow users to modify, delete, or add trips to an existing schedule.
1051BlockingThe system shall be capable of automatically building Trips based on user-specified attributes.
1052BlockingThe system shall allow users to define one or more Exceptions to daily operating schedules.
1053BlockingThe system shall automatically assign or allow users to manually assign Trip and Block numbers.
1054BlockingThe system shall allow users to create and assign vehicle types to any Trip, Trip_Pattern, or Block
1055BlockingThe system shall allow for the application of minimum and maximum Recovery_Times as a fixed amount of time.
1056BlockingThe system shall allow for the application of minimum and maximum Recovery_Times as a percent of Running_Time.
1057BlockingThe system shall allow for the application of minimum and maximum Recovery_Times as a combination of fixed time and Running_Time.
1058BlockingWhen the system is generating Blocking solutions, it shall optimize recommended Blocking solutions based on criteria (such as Vehicle_Types, minimizing Deadhead time, minimizing Total_Vehicle_Revenue_Hours, Total_Vehicle_Revenue_Miles, Interlining at multiple locations) as defined by the user
1059BlockingThe system shall allow both automatic and manual vehicle Block development based on user-defined variables.
1060BlockingThe system shall automatically validate that all Trips have been assigned to Blocks and notify the user about any missing assignment. Provide configurable tabular views (moveable/resizable/sortable columns) for all modules.
1061BlockingThe system shall allow users to add, modify, and delete notes on Trips, Trip_Time_Points, Blocks, or a selection set of any combination of these items.
1062BlockingThe system shall be able to generate multiple alternative Vehicle_Blocking_Assignments for the purpose of comparing alternative scenarios.
1063BlockingThe system shall include a scenario evaluation mode to compare alternative Blocking scenarios.
1064BlockingThe system shall allow the user to Unblock the Line and recreate Trips after the user has made a Blocking change.
1065BlockingThe system shall allow multiple Lines to be identified, viewed, and exported based on whether the Lines have common Time_Points, End_Points, or Segments.
1066BlockingThe system shall allow Lines to be grouped to be used for Interlining purposes.
1067BlockingThe system shall allow Trips and Lines to be Interlined, with the ability to create Deadheads between Line ends or segments to allow systemwide Interlining based on, but not limited to; common start/end points, common Vehicle_Types, Trip arrival/departure times vs. Deadhead times, etc.
1068BlockingThe system shall allow users to specify operational costs for Blocking scenarios including capital costs, system overhead and maintenance costs on a per mile or per hour basis.
1069BlockingThe system shall generate cost estimates by Routes, groups of Routes, or system-wide.
1070BlockingThe system shall allow users to build a new schedule from scratch.
1071BlockingThe system shall allow users to report on any trip, block, schedule.
1072BlockingThe system shall be capable of exporting trip and block numbers to downstream systems, external system, and reports.
1073BlockingThe system shall allow users to specify allowable vehicle types for certain Trip_Patterns or Blocks.
1074BlockingAlternative Blocking scenarios shall be savable based on Sign-up_Periods.
1075BlockingPreviously saved scenarios shall be maintained such that they can be re-selected as the implementable scenario.
1076Run CuttingThe Run_Cutting module shall either be fully integrated into the overall vehicle scheduling system, or shall have a standard interface.
1077Run CuttingThe system shall allow users to create multiple custom Work_Assignment Run_Types (such as, full-time and part-time Runs, Extraboard assignments, vacation relief, etc.)
1078Run CuttingThe system shall allow for both driving and non-driving elements to be configured as part of a Work_Run.
1079Run CuttingThe system shall allow adjustments to Trip_Relief times to optimize Run_Cuts.
1080Run CuttingThe system shall be able to cut single-piece and multi-piece Work_Runs.
1081Run CuttingThe system shall allow Blocks to be split, swapped, truncated, extended, or otherwise modified as part of an automatic Run_Cutting process.
1082Run CuttingChanges made during Run_Cutting shall be automatically reapplied through Blocking and Trip_Building without requiring the user to manually restart the process.
1083Run CuttingThe system shall have the capability to optimize the development of Operator_Runs based on the completed Block_List.
1084Run CuttingThe system shall have an “undo” / “redo” feature to revert back to previous Route_Schedule, Blocking_Scenario, or Run_Cut iteration made after a system save with options to undo beyond the last save point.
1085Run CuttingThe system shall ensure each Run has the same start and finish location, except where specifically overridden by a user.
1086Run CuttingThe system shall enable users to automatically and manually assign alphanumeric Run_Numbers which shall be made available to downstream systems.
1087Run CuttingThe system shall ensure there are no duplicate Run_Numbers.
1088Run CuttingThe system shall allow a custom Blocking and Run_Cutting numbering system to be used for numbering the City's Blocks and Work_Runs.
1089Run CuttingThe system's Run_Cutting module shall allow for the inputting of Work_Rules parameters that shall restrict the ability to apply non-conforming Runs.
1090Run CuttingThe system shall notify the user when a manual or automatically generated Run_Cut violates any applicable City business rule, management rule, operating rule and/or any applicable City labor agreement provision.
1091Run CuttingThe system shall allow users to define, modify, turn off/on, soft and hard Work_Rules.
1092Run CuttingThe system shall include a scenario evaluation mode to compare alternative Run_Cutting scenarios.
1093Run CuttingThe system shall automatically or allow users to manually generate Run_Cut scenarios from Blocks to optimize alternatives to achieve operational objectives defined by the user.
1094Run CuttingThe system shall allow users to configure Hard_Rules on specific parameters, while allowing levels of cost or hourly penalties per unit violation on Soft_Rules.
1095Run CuttingThe system shall allow Run_Cuts to be created for each Service_Day.
1096Run CuttingThe system shall allow users to lock selected Trips, Blocks and Runs, such that they will not be affected by any automatic system operation, and cannot be modified by manual operation unless the lock is first removed.
1097Run CuttingThe system shall allow for Rostering of Runs.
1098Run CuttingThe system shall allow users to create and apply custom work types.
1099Run CuttingThe system shall allow users to select from any of the generated Run_Cut alternatives to compare resulting costs for each scenario.
1100Run CuttingThe system shall suggest the optimal Run_Cut scenario
1101Reporting & AnalyticsThe system shall provide user-friendly and flexible reports as outputs. All reports shall be customizable to the City’s particular needs via the inclusion of desired data field(s).
1102Reporting & AnalyticsIf any 3rd party Business Intelligence tool is leveraged by the system for satisfying the report generation requirements, a developer license for this tool shall be provided to the City.
1103Reporting & AnalyticsAll reporting tools shall be directly accessible from the Vehicle Scheduling system’s main graphical user interface even if the Contractor leverages a 3rd party Business Intelligence tool to satisfy the City’s report generation requirements.
1104Reporting & AnalyticsThe system shall support the creation of reports that incorporate Exceptions. Exception reports shall show Service_Hours and Service_Miles by day including variances in Trips running on individual days. These reports shall configurable to any selected time period (Week, Month, Shake-Up, Fiscal or Calendar Year) to distinguish what trips are operating on each individual day.
1105Reporting & AnalyticsThe standard report templates provided shall have variable attributes/parameters which can be adjusted by City users via the system’s graphical user interface and subsequently saved as new report templates which can then be run going forward.
1106Reporting & AnalyticsStandard Report templates shall be provided to aid City staff in fulfilling National_Transit_Database (NTD) reporting requirements including:
i. Annual_Service_Days by service day type.
ii. Run_Rosters (for Operator signup).
iii. Trip_Patterns for each selected Run.
iv. Trip_Patterns for each selected Block.
v. Number of Trips by user-defined time periods.
vi. Vehicle_Miles, Revenue_Miles, Deadhead_Miles.
vii. Total Vehicle_Miles and Running_Times for each selected Trip_Pattern, between each Stop.
viii. Total Vehicle_Miles and Running_Times for each selected Trip_Pattern, between each Time_Point.
ix. Selected fields from the Bus_Stop definition (e.g. location, amenities, conditions) for each selected Bus_Stop.
x. Stops for each selected Trip_Pattern.
xi. Departure times for each Stop on each selected Run.
xii. Departure times for each Stop on each selected Block.
xiii. Vehicles_Operated_In_Annual_Maximum_Service (VOMS).
xiv. Time service begins and time service ends, for Routes or system-wide, by Service_Day, AM_Peak, midday, and PM_peak.
xv. Deadhead hours
1107Reporting & AnalyticsThe system shall allow users to create vehicle schedule statistics and other statistical reports for user-specified time intervals (date range, Service_Day types, and/or day time periods or a combination of these) and user-specified days of the week or combination of specifications.
1108Reporting & AnalyticsThe system shall have the ability to access and print reports from any workstation.
1109Reporting & AnalyticsAll reports shall have the capability to be exported into common formats including .pdf, .xlsx and .docx
1110Reporting & AnalyticsThe system shall allow for the automatic generation of a peak vehicle usage report based on the information contained in the vehicle schedule for the current Shakeup period. Vehicles within the report shall be categorized by subtype (e.g. 30’ buses, several variants of 40’ buses, 60’ articulated buses and Battery Electric Buses), and the report shall return peak vehicle usage values for Weekdays, Saturday and Sundays. The output of the report shall be sortable by Line, Bus_Type, Pull_In and Pull_Out times.
1111Reporting & AnalyticsThe system shall produce printable Paddles based on any selected Run_Cuts.
1112Reporting & AnalyticsThe system shall produce a Run_Guide to assist Operators in selecting work during a bid process.

Operations Sched. Requirements

Requirement IDCategoryDescriptionCan Comply (Y/N) / If No (N), Identify Exception and Reason
1113Absence ManagementThe system shall have separate modules to track paid time off accruals and absences.
1114Absence ManagementThe system shall reconcile absence codes from FMLA rules and the City's current and future ERP systems.
1115Absence ManagementThe system shall automatically extend the end date when the Operator has not been manually removed from the Long_Term_Absence_List to ensure the Operator is not prematurely reinstated in the system as available for Work_Assignment.
1116Absence ManagementThe system shall allow Motor_Coach_Operators to enter Planned_Absences and Unplanned_Absences into the timekeeping module via a secure website or mobile application.
1117Absence ManagementThe system shall allow users to view the list of Operators that cannot be assigned due to the Operator being absent.
1118Absence ManagementThe system shall allow users to remove an Operator's Work_Assignment when a Planned_Absence is approved or when an Unplanned_Absence is registered.
1119Absence ManagementThe system shall allow authorized users to maintain the list of Operators on the Long_Term_Absence_List.
1120Absence ManagementThe system shall allow users to enter future planned non-avalibilities during defined periods, such as mandatory training or official City or union business.
1121Absence ManagementThe system shall allow a pre-configured list of users to be notified of absence requests so the requests can be approved/denied.
1122Absence ManagementThe list of absent Operators shall display the duration of and reason for the Operator's absence.
1123Absence ManagementThe system shall allow authorized users to adjust the start and end date for which the Operator was unavailable for work assignment.
1124Absence ManagementOperators on the Long_Term_Absence_List shall not be reinstated until manually reinstated by an authorized user.
1125Absence ManagementWhen an Operator's request for Worker's Comp leave is granted, the system shall open up their work for the time requested
1126BiddingThe system shall provide assignment details for all bidded Work_Assignments throught the Operator_Web_Portal.
1127BiddingIn the bidding module, the system shall provide Operator with access to Vacation, Extra_Board and Work_Assignments as well as days off.
1128BiddingThe system shall have the ability to determine which Operators will participate in the Bidding process.
1129BiddingIn the bidding module, bidding period date/time thresholds shall be configurable.
1130BiddingThe bidding cut-off time needs to be configurable, even if the Assignment process is in progress.
1131BiddingUsers need to be able to move Operators from one bidding group to another without affecting Operator_Seniority.
1132BiddingThe system shall support Cafeteria_Style_Bidding.
1133BiddingThe system shall allow users to configure Shakeup_Period and allow bidding by operators during these predefined periods.
1134BiddingThe system shall allow users to configure and perform individual bids for runs that open up during a shake up period as needed by the transit agency at no additional cost.
1135Customer Comments, Commendations, and ComplaintsThe system shall have the ability to send email notifications at various steps during investigations of customer feedback.
1136Customer Comments, Commendations, and ComplaintsCustomer feedback records shall be customizable and, at minimum, contain the following fields: date, time, Operator, Route, Vehicle ID, Bus_Stop_ID, customer name, and customer phone number.
1137Customer Comments, Commendations, and ComplaintsThe system shall allow users to track activities and actions taken in response to the customer complaint/commendation and enable faster detection of recurring problems.
1138Customer Comments, Commendations, and ComplaintsThe system shall have the ability to email notifications and complaints.
1139Customer Comments, Commendations, and ComplaintsThe system shall allow for user configurable customer feedback categories.
1140Customer Comments, Commendations, and ComplaintsThe system shall allow the user to classify customer feedback by category.
1141Customer Comments, Commendations, and ComplaintsThe system shall allow the user to specify a priority level, status, and classification code for internal tracking of a customer feedback record.
1142Customer Comments, Commendations, and ComplaintsThe system shall provide the ability to attach or reference electronic documents to a customer feedback record, including .pdf, .xlsx, .docx, .jpg, .png and a reference to a video filename from BBB’s on-board bus security system.
1143Dispatch User InterfaceThe system’s user interface and functionality shall be consistent throughout and use common UI elements.
1144Dispatch User InterfaceAll tabular views in the system shall be dynamically resizable
1145Dispatch User InterfaceThe system shall allow each screen view to be printed and/or exported in common file formats, including but not limited to .csv, .xlsx, .txt, and .xml.
1146Dispatch User InterfaceThe system shall have a backend control panel that allows designated users to manage user accounts, user groups, and user roles.
1147Dispatch User InterfaceThe system shall log all users and user actions for traceability.
1148Dispatch User InterfaceThe system shall remember a user’s window arrangement such that the next time the user logs into the system, it will present the same window layout as before.
1149Dispatch User InterfaceThe system shall allow Operators to be assigned to Work_Assignments via drag-and-drop functionality.
1150Dispatch User InterfaceThe system shall have both “copy+paste” and “cut+paste” features allowing users to copy or cut data from one Work_Assignment to another or within the same view.
1151Dispatch User InterfaceThe system shall support undo/redo functionality which allows the previous operation to be completely reversed (or reapplied) at the user’s discretion.
1152Dispatch User InterfaceThe system shall have a real-time visual output to display current Operator_Assignments and Daily_Activities on external displays in the Operator check-in area.
1153Dispatch User InterfaceThe system shall allow users to have two or more instances of the software or any individual schedule open at one time, preferably in a tabbed view.
1154Dispatch User InterfaceThe employee management display (Daily_Activity_Display) shall include a table layout and a Gantt chart layout.
1155Dispatch User InterfaceThe system shall allow users to query Work_Assignments, employee profiles, parameters, settings, rules and other data from any window containing associated information.
1156Dispatch User InterfaceDisplayed data shall be sortable.
1157Dispatch User InterfaceThe system shall allow users to create queries and save them for future use.
1158Dispatch User InterfaceThe system shall allow the following four types of user access roles to be assigned to individual users or groups of users: read-only, read/write, restrictions on specific modules, and full control.
1159Dispatch User InterfaceThe system shall allow users to selectively lock certain database tables or records.
1160Dispatch User InterfaceThe system shall allow users to create queries and store queries for future use.
1161Labor RulesThe system shall automatically verify that Bids do not violate any established Work_Rules and notify designated users of potential Work_Rule violations.
1162Labor RulesThe system shall track and report Operator work hours such that Operator Assignments will not violate Work_Rules.
1163Labor RulesThe system shall provide an interface that allows designated users to configure custom Work_Rules.
1164Operator AssignmentsThe system shall allow users to create custom types of Work_Assignments.
1165Operator AssignmentsThe system shall show which Operator is currently assigned to each Run.
1166Operator AssignmentsWithin a configurable period of time before the Scheduled_Pullout, the system shall notify the user of any runs that do not have an assigned Operator.
1167Operator AssignmentsThe system shall not allow an Operator to be assigned to multiple Runs at one time and shall notify any user who attempts to assign an Operator to multiple Runs.
1168Operator AssignmentsThe system shall allow users to enter reasons for unassigning Operators from Runs.
1169Operator AssignmentsWhen a user attempts to assign an Operator to a Run, the system shall automatically notify the user if the Assignment would violate defined City labor agreements and/or Work_Rules.
1170Operator AssignmentsThe system shall automatically display and update a list of Operators (including the Operator's contact information) available to fill unassigned Runs without violating defined Labor_Agreements and Work_Rules.
1171Operator AssignmentsThe system shall indicate when an Operator selection would result in overtime being paid, taking into account the Runs already assigned and/or completed during the current pay period.
1172Operator AssignmentsOperator preferences regarding accepting overtime shall be automatically considered by the system and visually indicated in the Operator assignments module.
1173Operator AssignmentsThe system shall allow allow configuration of time periods when Operators are not available for assignment.
1174Operator AssignmentsThe system shall allow users to assign and/or reassign an Operator to future Runs and off days.
1175Operator AssignmentsThe system shall allow users to view operator Work_Assignments and time worked for the current pay period and for individual days.
1176Operator AssignmentsThe system shall allow designated users to sign Operators into the system.
1177Operator AssignmentsIf an Operator has not signed in within a configurable time period prior to the Scheduled_Pullout for an assigned Run, the system shall automatically unassign the Operator from the Run and notify a designated group of users (e.g. MCO Supervisors)
1178Operator AssignmentsThe system shall include a comprehensive Operator work calendar.
1179Operator AssignmentsThe system shall generate customizable Operator Paddles in a printable format.
1180Operator AssignmentsThe system shall be able to assign a Standby_Operator to replace the currently assigned Operator in the field.
1181Operator AssignmentsThe system shall automatically track the rotation of volunteers based on seniority and last work shift.
1182Operator AssignmentsThe system shall allow users to create and assign Special_Work_Assignments.
1183Operator AssignmentsThe system shall allow designated users to enter exceptions for each Operator (e.g. where an Operator is not authorized to be assigned to a particular Vehicle_Type).
1184Operator AssignmentsThe system shall warn of any relevant Operator accommodations requirements (e.g. a specific vehicle type) prior to generating an applicable Operator Work_Assignment.
1185Operator AssignmentsThe system shall allow for configuration of both Driving and Non-Driving elements as part of the Operator's workday.
1186Operator AssignmentsThe system shall show which Operators are not assigned to a Run.
1187Operator AssignmentsThe system shall automatically notify users of Runs where the assigned Operator has become unavailable and a new Operator must be assigned to cover the Run.
1188Operator AssignmentsThe system shall allow users to enter Assignments for any future dates within the current Shakeup_Period.
1189Operator AssignmentsThe system shall display real-time Operator sign-in status.
1190Operator AssignmentsThe system shall allow for the Assignment of a Standby_Operator to a Block; the Standby_Operator shall automatically be converted to the Primary_Operator in a Relief scenario.
1191Operator AssignmentsThe system shall automatically log the Absence_Code and issue a Miss-Out after replacing an Operator during an unplanned Relief scenario.
1192Operator AssignmentsThe system shall track the assignment of Vehicles to Blocks.
1193Operator AssignmentsThe system shall track pull out and pull in times for each Block via integration with Clever Devices CAD/AVL.
1194Operator AssignmentsThe system shall allow for the tracking of changes to the Vehicle and Operator Assignments throughout the day via manual entry from the user, including:

i. What data items were changed and what each was changed to;

ii. Identify of the user who made each change; and

iii. The date and time of the change

1195Operator AssignmentsThe system shall allow users to define Staffing_Level_Requirements for the each day of regular or special service.
1196Operator AssignmentsThe system shall allow users to maintain a daily calendar of Schedules in production.
1197Operator AssignmentsThe system shall allow users to define holidays and associated work schedules.
1198Operator AssignmentsThe system shall allow for configuration of relief time reporting limitations (in terms of vehicles and in terms of minutes) globally, by Routestart and end locations, schedule type, time of day, by individual Lines, and by location.
1199Operator AssignmentsThe system shall analyze modes of travel (Pool_Cars, Pull_Reliefs, riding on buses currently in service, and/or a combination of these) for Operators between the facility and Relief_Locations to determine which mode is more efficient.
1200Operator AssignmentsThe system shall track pool vehicle locations and Standby_Operator in use while making Relief
1201Operator AssignmentsThe system shall track the assignment of Operators to Runs.
1202Operator AssignmentsThe system shall allow users to view and identify any calendar-specific schedules planned to operate on a given day.
1203Operator AssignmentsThe system shall have the ability to configure absence quotas for each work day.
1204Operator AssignmentsThe system shall have the ability to auto approve absence requests at limits configurable by the agency.
1205Operator Sign-inThe Operator sign-in solution shall interface with the Operator scheduling system and the vehicle scheduling system to access Work_Assignment details.
1206Operator Sign-inThe Operator sign-in solution shall allow Operators to sign in using their unique City-assigned employee ID (alphanumeric) and a unique password.
1207Operator Sign-inImmediately after an Operator signs in to their daily Work_Assignment, the sign-in solution shall visually confirm that the sign-in is complete and display the sign-in time.
1208Operator Sign-inImmediately after an Operator signs in to their daily Work_Assignment, the system shall display the day's Work_Assignment for the Operator, the vehicle number that has been assigned to the initial Block for the Run, and the vehicle's parked location either in bus yard or at Relief_Location.
1209Operator Sign-inThe system shall notify defined dispatchers when an Operator has not signed in prior to a City-configurable amount of time before the Operator's scheduled shift.
1210Operator Sign-inThe Operator sign-in solution shall log all Operator interactions with the system.
1211Operator Sign-inImmediately after an Operator signs in to their daily work, the system shall automatically print a receipt with the day's Run_Assignment for the Operator, the vehicle number that has been assigned to the initial Block for the Run, and the vehicle's parked location in the bus yard, and a customizable message for the Operator.
1212Operator Sign-inThe system shall allow Operators to "clock in" by tapping their RFID employee badge on an RFID card reader at designated sign-in workstations.
1213Operator Sign-inThe Operator sign-in solution shall be web browser-agnostic and capable of running on any modern browser.
1214Operator Sign-inThe Operator sign-in web application shall not require 3rd party plugins or tools for operation.
1215Operator User Interface PortalThe Operator web portal shall allow users to access their personal information.
1216Operator User Interface PortalThe Operator web portal shall allow users to submit absence requests and update accrual balances in real time.
1217Operator User Interface PortalThe system’s Operator_Web_Portal shall allow the City to bundle in the following supplementary content in both web based and mobile versions:

i. Online Operator training

ii. Training documentation

iii. Employee counseling

iv. Employee commendations and complaints (if applicable as per exercised Option)

vi. Medical certification and testing management

1218Operator User Interface PortalThe system shall be able to manage workers compensation absence requests via the Operator_Web_Portal with agency configurable standard forms.
1219Operator User Interface PortalWith respect to bid results, the system’s Operator_Web_Portal shall show real time updates allowing operators to:

i. View when their group’s Bids will be processed.

ii. See their ranking within the group (based on Operator_Seniority).

iii. View available Run_Numbers and sort them according to number, working or paid time, and days operated.

iv. Specify which positions they prefer and rank them in the Operator_Web_Portal accordingly.

1220Operator User Interface PortalThe Operator web portal shall allow users to select Bid_Units.
1221Operator User Interface PortalThe Operator web portal shall allow users to submit Vacation_Bids.
1222Operator User Interface PortalThe Operator web portal shall allow users to view a calendar displaying Daily_Assignments, days off, and absences.
1223Operator User Interface PortalThe Operator web portal shall allow users to view and print records such as time card and a summary of vacations/absences.
1224Operator User Interface PortalThe Operator web portal shall allow users to submit availability and preferences for overtime and on-call work.
1225Operator User Interface PortalThe Operator web portal shall allow users to view informational messages.
1226Operator User Interface PortalThe Operator web portal shall allow users to write up accident reports within the system.
1227ReportingThe system shall provide daily Pay_Hour_Exception reporting.
1228ReportingThe system shall provide the ability to do real time reporting based on Absence_Codes over customizable date ranges.
1229ReportingThe system shall have the ability to create and customize reports. Report data shall be granular to tenths of an hour. The system shall provide the capability to export reports into various data type formats. Examples of reports to be supported shall include but are not limited to:

i. Individual generic absence report with the capability to pull any combination of absence data for a specified date range.

ii. Total generic absence report with the capability to pull any combination of absence data for a specified date range.

iii. Sick or dependent care usage report with the capability to pull summary and detailed data by Operator for a specific date range.

iv. Individual accrual balance reporting with the capability to select all or a specific accrual type for a specific date range

v. Total accrual balance reporting by Operator with the capability to select all or a specific accrual type for a specific data range

vi. Total union official business hours with the capability to pull data for a specific date range

vii. Summary reporting by Operator for any timekeeping Pay_Code or Pay_Code combination for a specific date range.

viii. Detailed reporting by Operator for any timekeeping Pay_Code or Pay_Code combination for a specific date range

ix. Detailed Work_Run relief (Extra_Board, vacation relief Extra_Board and part-time) reporting for any timekeeping Pay_Code or Pay_Code combination for a specific date range

x. Detailed casual work reporting for any timekeeping Pay_Code or Pay_Code combination or a specific date range.

xi. Detailed Individual FMLA usage for a specific date range

xii. Total FMLA usage by Operator for a specific date range

1230ReportingSystem shall have the ability to run a report for each leave type to display available accrual balance.
1231ReportingThe system shall allow users to create and run customizable reports.
1232ReportingIf any 3rd party Business Intelligence tool is leveraged by the system for satisfying the report generation requirements, a developer license for this tool shall be provided to the City.
1233ReportingAll reporting tools shall be directly accessible from the Operator Scheduling system’s main graphical user interface even if the Contractor leverages a 3rd party Business Intelligence tool to satisfy the City’s report generation requirements.
1234ReportingAs part of the system design and implementation, the vendor shall coordinate with City staff to develop standard reports.
1235ReportingThe Contractor shall provide the City with a full database structure and field definitions for the system, in order to allow City users to create customized reports utilizing third-party software, at the City’s discretion.
1236ReportingThe system users shall be able to generate reports on a daily basis with data from the previous 24 hours at a minimum.
1237ReportingReports shall be filterable by user-selectable fields.
1238ReportingThe standard report templates provided shall have variable attributes/parameters which can be adjusted by City users via the system’s graphical user interface and subsequently saved as new report templates.
1239ReportingThe system shall allow a user to select a previously generated report as a template for the creation and generation of a new report.
1240ReportingThe system shall allow for a distribution list and generation schedule to be configured by the City for each generated report.
1241ReportingThe system shall be capable of exporting reports in the following standard formats: .pdf, .csv, .docx, .xml, and others as appropriate to the reports generated.
1242ReportingThe system shall provide a bi-weekly report that lists employee pay hours by pay code and by division for each day within the previous two week period.
1243ReportingThe system shall provide the capability to create, calculate and customize Timekeeping_Alerts (e.g. in-application notification, e-mail, SMS) on a daily, weekly, and bi-weekly basis. The following Timekeeping_Alerts are examples of what must be tracked and reported in both summary and detailed formats:

i. Jury duty absence alert. The system shall alert the user when operators have been on jury duty for more than 10 days.

ii. Operators not entitled to holiday accrual.

iii. Operators not entitled to Easter Holiday pay. Operators are entitled to Easter Holiday pay after one year of employment

iv. Union official business meeting hours.

v. CALSIC/Kin care usage by both full-time and part-time operators.

vi. Long term Leave of Absence of more than 30 days. The system shall also alert the training staff when an Operator that’s been off work for more than 30 days and will be returning to work.

vii. No holiday pay alert. The system shall provide a list of Operators that did not receive holiday pay. This occurs when an Operator has a chargeable absence the day before, on or after the holiday and required documentation has yet to be received.

viii. Sunday substitution alert. The system shall provide a list of Operators with Sunday off who worked on a holiday that falls on a weekday. When a Sunday schedule is substituted for a holiday that falls on a weekday, the Operator is entitled to overtime pay) for working on the holiday even though the holiday fell on his/her regular work day.

ix. Absent without pay (AWP) / sick without pay (SWP) during a week with a holiday alert. The system shall provide a list of employees that are AWP/SWP during any week with a paid holiday. Overtime hours worked on a holiday that are equal to AWP/SWP hours incurred during the holiday week shall be adjusted to a straight rate.

x. YTD fiscal year union meeting usage in hours

xi. YTD Santa Monica official business usage in hours

1244ReportingThe system shall have the ability to create and customize queries. Query data shall be granular to tenths of an hour. The system shall provide the capability to export query results into various data types.
1245ReportingPrior to go-live, the system shall work with the transit agency to generate the following reports at a minimum:

i. Operator_Assignments for each selected Run

ii. Run assignments for each selected Operator

iii. Vehicle_Assignments for each selected Block

iv. Block_Assignments for each selected vehicle

v. Vacation_Time_Assignments for a selected time period

vi. Vacation_Time_Assignments for a selected Operator

vii. Operator vacation availability for the annual Vacation_Bid

viii. FMLA departmental summary report

ix. Runs completed for the current pay period for each selected Operator (including hours worked/overtime and hours Operators have been paid for)

x. Blocks completed by each selected vehicle

xi. Vehicle circle check (Daily Vehicle Inspection Report) results summary 1246 Reporting Upon delivery of the system, the following report templates shown in Exhibit X, representing reports currently generated manually by the City, shall be pre-configured and available for running:

i. Timekeeping Queries

ii. Motor Coach Operator Absence Comparison Report

iii. Unscheduled Overtime Comparison Report

iv. Motor Coach Operator Vacation Bid (includes vacation availability, current vacation accrual balances, accrual rates)

v. Supplemental Time Card 1247 System Deployment Prospective bidders, if chosen, shall be prepared to provide the following:

i. Project Schedule.

ii. Integration plan with other City software, if applicable.

iii. Project management plan including method of communication and tracking project deliverables, status and reporting.

iv. Quality assurance plan.

v. Testing plan – Contractor shall thoroughly test the software solution for conformance with the scope of work and specifications, including integration with other City software systems prior to delivery to the City.

vi. Specifications for installation on City servers (where applicable under the non-SaaS or hosted delivery method)

vii. Training plan for each user group to include transfer of knowledge and recommended training resources.

1248System DeploymentWhere installation of system software is required on City computers, the software shall be compatible with Windows 10, Windows 11, and all future Microsoft Windows operating system releases.
1249System DeploymentFor the server side processing, the system shall have the option of being locally hosted by the City in a virtualized server environment, or cloud hosted by the Contractor, or a full SaaS model, and pricing shall be provided for moving forward with all three different delivery models.
1250System DeploymentFor a multi-tiered architecture, all tiers shall provide secure encryption throughout the network.
1251Timekeeping and Payroll ProcessingThe system shall support configurable Pay_Rules for the three types of BBB Operators: Full-time, Part-time, and Trainee and allow the ability to add different BBB Operator types as deemed necessary at no extra cost to the agency.
1252Timekeeping and Payroll ProcessingThe system shall provide the ability for users to create Casual_Work_Assignments.
1253Timekeeping and Payroll ProcessingThe system shall allow users to make timekeeping adjustments to current and previous work periods.
1254Timekeeping and Payroll ProcessingThe system shall provide users the ability to override established system parameters.
1255Timekeeping and Payroll ProcessingThe system shall allow designated users to adjust Work_Schedules on a weekly basis.
1256Timekeeping and Payroll ProcessingThe system shall calculate Pay_Hours on a weekly and bi-weekly basis.
1257Timekeeping and Payroll ProcessingThe bi-weekly employee pay hour data shall list daily, weekly and bi-weekly hours for each Operator up to 12 months as well as display total hours in hours:minutes or tenths by Payroll_Code.
1258Timekeeping and Payroll ProcessingThe system shall have the ability to create, calculate and customize Premium_Pay_Codes defined by the City such as MTI (line instructor), ART (accident report premium), SV5 (supervisor premium) and CHP (log premium), and export these back into the City’s payroll system as a flat file.
1259Timekeeping and Payroll ProcessingThe system’s FMLA module shall provide the capability to track FMLA usage rolling back 365 days, balance and certification parameters for operators and admin staff. The certification data field shall include a name, date range, relationship, leave (intermittent, continuous) and comment (for parameters) data field. The balance data fields shall include usage detail with a running balance.
1260Timekeeping and Payroll ProcessingThe system shall provide a training class module that creates multiple pieces of Pay_Premium_Codes so that Transit Safety and Training can assign the training Pay_Premium_Codes to the class attendees.
1261Timekeeping and Payroll ProcessingOverrides to established system parameters shall be logged by date, user and time change occurred.
1262Timekeeping and Payroll ProcessingWhen converting between a weekly and bi-weekly basis, the system shall automatically account for Unpaid_Absences.
1263Timekeeping and Payroll ProcessingThe system shall possess a Bid_Unit for Motor_Coach_Operator_Trainee.
1264Timekeeping and Payroll ProcessingThe system shall sync information concerning Employee_Accrual_Hours in real time from the City's enterprise resource planning system.
1265Timekeeping and Payroll ProcessingThe system shall allow designated users to edit Daily_Work_Schedules to accommodate mixed work schedules that may occur in any given week (e.g. both 10-hour and 8-hour work days in the same week)
1266Timekeeping and Payroll ProcessingThe system shall have the ability to assign Work_Orders to Pay_Hours.
1267Timekeeping and Payroll ProcessingThe system shall provide the capability for Operators to enter overtime hours through the Operator_Web_Portal when ending their shift late (e.g. arriving at the yard late due to traffic). This feature shall include an approval field so that the dispatch supervisor can approve the overtime once it’s been verified as valid.
1268Timekeeping and Payroll ProcessingThe system shall have the ability to add, create and customize paid time off accruals and absences codes.
1269Timekeeping and Payroll ProcessingThe system shall provide an adjustment module for entering previous pay period adjustments that interfaces with the City’s payroll system.
1270Timekeeping and Payroll ProcessingThe previous pay periods adjustment module shall have an approval component that automatically updates the pay hours in the timekeeping system once the adjustment is approved.

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .