Systems_Specifications_v2_KCW_PD_REPLYv1.docx
DOCX document 29 KB Posted
- Solicitation number
- RFP- 25 - 020
- Issued by
- Pinellas County, Florida
About this file
The document is a System Specifications file for the Special Events Management System (SEMS) Bid Solicitation for the St. Petersburg Police Department in Florida, detailing comprehensive technical requirements for an off-duty job management software platform. The system must be a browser-based, web-accessible application with desktop and mobile versions, providing an integrated solution for managing police off-duty assignments, with specific functionality for job scheduling, reporting, and user management. The platform will serve City Police Department personnel, enabling them to manage off-duty jobs, create event rosters, track officer assignments, and generate custom reports across various timeframes and job types.
Key technical requirements include integration capabilities with existing city systems like Oracle and Kronos, automatic employee data import, calendar synchronization with Outlook, and robust reporting features. The system must support complex scheduling requirements, such as assigning jobs based on officer work history, allowing job posting and transfer, tracking officer skills and ranks, and providing administrative controls like user activity logging and officer suspension. Additional critical features include the ability to attach PDF documents to assignments, create custom reports with detailed job and employee information, and manage invoicing with precise pay rate and position tracking. The specification emphasizes a secure yet user-friendly platform that allows administrative control while providing flexibility for officers to manage their off-duty work assignments.
View the file
Other files
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
Title: Special Events Management System (SEMS) Bid Solicitation At a minimum, the application must meet the following capabilities and functionalities: Comment by Kaela Williamson: Once this document is finalized, I will convert this to an excel file that the vendor can check off/put comments next to each requirement.
· Platform Requirements
· User friendliness
· The application shall be browser-based (Web-based) and incorporate Geographic Information System (GIS) functionality using Internet technology for geographic area selection.
· The application package shall provide an integrated, comprehensive solution.
· The only equipment furnished by the city’s authorized users shall be Windows-based personal computers (PCs), smart devices (phones, tables, etc.), standard Internet browsers, and Internet connections in order to use the Offerors’ application.
· The system shall be Internet based/accessible.
· Desktop version and a mobile/app version.
· The system shall have a common database, accessible by several public safety/emergency management individuals.
· The system shall be secure, but simple to operate.
· Customizable platform/software if there are changes needed.
· Authorized Users
· Authorized users shall consist of City Police Department designated personnel.
· All authorized users shall have Internet access to the Offeror’s application.
· We do not want clients to be able to set up accounts through the software. Their contact needs to be directly with us. Comment by Kaela Williamson: What does this mean? Only certain users can set-up accounts? Please explain. Comment by Ryan T. Bellittera: Some of the off-duty software allows the customer to create their own account through the software and make off duty requests entirely through the software without speaking with us. We do not want this function. If the customer wants off-duty they need to contact our office and we will build it in the software.
· Integration Requirements
| · Ability to automatically import employee data from city system into off duty system. | Comment by Kaela Williamson: I’m assuming the City will have to provide some parameters as to what information will be provided in order for the offeror to import into the system? What City systems does the program need to be compatible with? | Comment by Ryan T. Bellittera: Oracle. |
| · Ability for officer’s schedule to import into their personal calendars. | Comment by Kaela Williamson: What program is used for their personal calendars? PD needs to list the systems/programs that it currently uses that the software must be able to integrate with. | Comment by Ryan T. Bellittera: Outlook |
| · Ability to automatically import PATEO codes for jobs. | Comment by Kaela Williamson: Please define | Comment by Ryan T. Bellittera: Project Number, Fund Award, Task for pay codes |
· Reporting Requirements Comment by Kaela Williamson: What types of reports is PD requesting? Payroll? Invoicing? Scheduling? Timecards. We may need to break this out along with each report types’ requirements. Comment by Ryan T. Bellittera: The ability to export the job data into an excel format for duties such as roster creation and chief’s reports. This would include export fields such as officer information, pay rates, hours worked, start times, end times etc.
· Ability to export raw data from the program to create customized reports for the purposes of presenting to command staff, fiscal and any other departments within the city that asks for information pertaining to the police departments off-duty services.
· Ability to automatically pull payroll details from the off-duty system and then automatically input it into KRONOS for payroll. Comment by Kaela Williamson: To confirm, it has to be able to work with the KRONOS software? Comment by Ryan T. Bellittera: Yes
· Ability to get custom reports specific to select jobs and select date ranges.
· Ability to export the rosters for large scale events into an excel spreadsheet.
· Ability to have an admin log to view user activity. Comment by Kaela Williamson: Is this a report or a function within the app? Comment by Ryan T. Bellittera: This is an internal report of the users interactions within the system. We are able to track when officers log in to system and what their interactions are in the system while logged in.
· Ability to create rosters for large scale events and assigning call signs to officers.
· Ability to get custom reports that include job information and employee information with payroll number, rank and hourly rate.
· Name field in reports defaults to Last Name, First Name
| · Timecards default to how shifts were built. | Comment by Kaela Williamson: What are these timecards? Is this a display option or report? Are the people being scheduled viewing this program as “timecards” when viewing their assignments/shift openings | Comment by Ryan T. Bellittera: Yes, it’s the time of the job. Some of the software makes officers clock in and clock out but the timecard created from this needs to default to what the job was built for. For example, a customer wants an officer from 3 PM to 10PM. The officer clocks in at 2:50PM but the officer does not get paid for 10 minutes. The timecard needs to default back to the 3 PM start time. |
| · Out of rank worked transfers to invoice as position worked and related billing fee. | Comment by Kaela Williamson: Is this an invoicing/payroll report requirement? Is PD asking for a billing fee field to be available? | Comment by Ryan T. Bellittera: When a sergeant works as an officer, the invoice needs to be reflected at the rate charged for an officer. |
| · Either on the job side or the invoice side, officer names are hyperlinks that when clicked take you to a summary of their jobs worked. | Comment by Kaela Williamson: IS this a reporting requirement? | Comment by Ryan T. Bellittera: Not a reporting requirement. This should be listed under Platform Requirements. |
· Staff Scheduling Requirements
· Ability to attach PDF documents to assignments that officers can access from their mobile device to read rosters and instructions for the assignment.
· Ability to automatically assign jobs to officers that have submitted interest in working such job based on the number of hours worked in the officer’s history i.e., officer with least amount of off duty hours in their 28-day history will receive the job first. Tie breaker will be department seniority.
· Ability to suspend an officer from working off-duty.
· Ability to exempt a job from counting in the officers off duty history.
· Ability to create one event with multiple check-on times. i.e., a baseball game on a particular day with K-9’s checking on at certain time, supervisors checking on at their own time and officers checking on at a different time. Comment by Kaela Williamson: Should this be check in? What does check-on mean? Comment by Ryan T. Bellittera: The times that officers check on for their shift. Some customers request officers to check on at different times for the same event.
· Ability to add “skills” or “specialties” to officers for assignments.
· Ability for admin users to make corrections to officers’ jobs that were closed incorrectly.
· Ability to show rank requirements for positions associated with a job.
· Ability to hold a “waitlist” after the initial assignment is made. If the officer “posts” the job, it would automatically reevaluate anyone that remains on the list and make the reassignment.
· Should have a delineation between jobs “out for bid” and jobs that are “first come first serve”.
· Ability to add a Pay Code to every job and the option to add a PATEO code if the job requires it.
· Ability to fill “open assignments” before replacing filled assignments.
· Ability to record hours as “ON” duty or “Off” Duty, for payroll purposes.
· User Scheduling Requirements
· Ability for users (officers, sergeants etc.) to edit their own beginning and end times after the assignment of a job to adjust for changes from the initial scheduled job due to changes that occur during the job.
· Ability to manually overlap jobs once the program prompts the user that there is a conflict, and the user agrees that the conflict is ok.
· Ability for officers to “post” their assignments for others to take if they no longer want to work.
· Ability for supervisors to view jobs of lower rank
· Ability for officers to split assignments when closing jobs with themselves or another officer.
· Additional requirement categories Comment by Kaela Williamson: Please advise what other requirements categories are needed from PD, if any more. Comment by Ryan T. Bellittera: NA
File details come from the government source that posted it. Updated .