RFP26006231 Attachment 4 Revised.xlsx
XLSX spreadsheet 133 KB Posted
- Attached to
- URI Computerized Maintenance Management System
- Solicitation number
- RFP26006231
- Issued by
- Providence County, Rhode Island
About this file
This is a requirements matrix attachment for an Enterprise Asset Management (EAM) Request for Proposals issued by Jefferson Parish in Louisiana. The document establishes functional and technical requirements across eight primary modules: General and Technical, Asset Management, Work Orders, Facilities Maintenance, Fleet Management, Inventory Management, Interfaces, and Mobile capabilities. Vendors are required to indicate their system's capability for each requirement using standardized response categories: Native out of box, Configurable, Customizable, or Does not provide. The RFP encompasses critical requirements such as data flow integration across modules, import/export functionality in standard formats (CSV, XLSX, DOCX, PDF, XML), API support for third-party system integration, Active Directory authentication, Single Sign-On capability, role-based security with field-level controls, and comprehensive audit logging with configurable retention periods. Additional critical requirements include GIS bi-directional integration with Esri ArcGIS 11.2, mobile device functionality for both iOS and Android platforms with offline data editing capabilities, workflow automation throughout all modules, and integration with existing systems including PeopleSoft financials (eventually transitioning to Workday), Microsoft Office 365, eDocs document management system, and Active Directory. The system must support unlimited asset records, accommodate multiple preventative maintenance sets with rule-based generation, provide scheduling and dispatch functionality, enable work order management with cost tracking and overhead allocation, and include comprehensive reporting and dashboard capabilities.
The requirements matrix specifies that the EAM system must support inventory management for multiple warehouses with barcode and QR code functionality, fleet management with total cost of ownership tracking and utilization reporting, and facilities maintenance with job plan templates and condition assessment capabilities. Critical technical infrastructure requirements include production, test, and development environments with change tracking and rollback capabilities, data encryption at rest and in transit, multi-factor authentication, and 24/7 operational availability. The system must provide mobile interfaces fully responsive to various device screen sizes, support disconnected field operations with data synchronization, and enable staff to capture images with timestamp and location data. Vendor support requirements mandate that planned outages occur outside standard business hours, that support be available during and outside business hours, and that database or application changes resulting from support actions be communicated to the organization. The matrix indicates that responses marked as "Nice to have" represent lower-priority requirements, while those marked "Critical" represent essential functionality necessary for system selection, allowing vendors to differentiate on optional capabilities and implementation approaches.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFP26006231_Jan_19_26_solicitation_doc.pdf | ||
| RFQ26006234 Truck Specs.pdf | ||
| RFP26006231 Attachment 4.xlsx | XLSX spreadsheet | |
| RFP26006231 Questions and Answers.pdf | ||
| RFQ26006234 Addendum-1.pdf | ||
| RFP26006231 Attachment 5.docx | DOCX document | |
| RFP26006231 Agency Solicitation Specifications.pdf | ||
| RFP26006231 Attachment 3.docx | DOCX document | |
| RFP26006231_Jan_12_26_solicitation_doc.pdf | ||
| RFP26006231 Attachment 2.docx | DOCX document | |
| ISBE Form - RFP Appendix B - 12.01.2025.pdf | ||
| RFP26006231_Feb_9_26_solicitation_doc.pdf |
Show all 12
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
Table of Contents
| Table of Contents - URI Requirements Matrix | |
| Tab No. | Requirements |
| 1 | General and Technical |
| 2 | Asset Management |
| 3 | Work Orders |
| 4 | Facilities Maintenance |
| 5 | Fleet Management |
| 6 | Inventory Management |
| 7 | Interfaces |
| 8 | Mobile |
&G &14Jefferson Parish&"-,Bold" Enterprise Asset Management (EAM) RFP &"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: January 29, 2025
1.General & Technical
| Indicator | Definition | |
| Below is a list of General & Technical requirements. Please indicate a response for each in column D. | Please indicate a response in each line item as: | |
| Native out of box |
Bhavna Shah: Bhavna Shah:
Core, out of the box functionality Configurable Bhavna Shah: Bhavna Shah:
Can be done but requires configuration. Functionality will upgrade.
Customizable Bhavna Shah: Bhavna Shah:
Can be done with customization. Functionality will not easily upgrade.
Does not provide Bhavna Shah: Bhavna Shah:
Unable to provide or never been done before with this software.
| General and Technical | |||||
| Req | Description of Capability | Criticality | Enter Response | Vendor Comments | |
| Technical Environment | |||||
| 1 | The system shall flow all changes made in the system throughout all proposed system modules without the need for duplicate data entry. | Critical | |||
| The system shall import and export data from (or to) standard file formats including but not limited to: | |||||
| 2 | .html; | Nice to have | |||
| 3 | PDFs that are text based and searchable; | Critical | |||
| 4 | .txt; | Critical | |||
| 5 | .csv; | Critical | |||
| 6 | .xlsx (MS Excel version 2016 or later, including MS 365); | Critical | |||
| 7 | .docx (MS Word version 2016 or later, including MS 365); | Critical | |||
| 8 | .ics (MS Outlook version 2016 or later, including MS 365, for calendaring); | Nice to have | |||
| 9 | .jpeg; | Nice to have | |||
| 10 | .jpg; | Nice to have | |||
| 11 | .xml; and | Nice to have | |||
| 12 | Other URI.defined file formats. | Nice to have | |||
| 13 | The system shall support APIs (Application Programming Interface) for third.party system integration, including both data entry and extraction, as well as execute workflows or initiate processes. | Critical | |||
| 14 | The system shall provide a toolkit to create and manage APIs. | Nice to have | |||
| 15 | The system shall support scheduled data feeds for exchanging file import/exports with third.party systems. | Critical | |||
| 16 | The system shall provide a centralized data dictionary that fully describes table structure, interdependencies, and appropriate levels of metadata. | Nice to have | |||
| 17 | The system shall provide a production, test, and development environment including the ability to track software changes applied to each environment and roll back as necessary. | Critical | |||
| Document Management | |||||
| 18 | The system shall support data storage with discrete version control in accordance with defined operational standards. | Nice to have | |||
| 19 | The system shall provide the ability to link imported documents to specific records. | Critical | |||
| 20 | The system shall use "drag and drop", electronic file upload and scan document functionality to associate electronic files to transactions within the system. | Nice to have | |||
| 21 | The system shall restrict modification of attached documents based on individual or department permissions. | Nice to have | |||
| 22 | The system shall allow a user to scan documents directly into the system. | Nice to have | |||
| 23 | The system shall permit export of a file directly for document storage, for example in a third.party system or network drive. | Critical | ` | ||
| 24 | The system shall have the ability to email electronic files to an internal or external party (e.g., send a copy of a photo to another department). | Nice to have | |||
| 25 | The system shall identify records with documentation/attachments. | Critical | |||
| 26 | The system shall associate electronic files with a system record with the following types: MS Excel, MS Word, shape, PDF, .dwg, .tif, .jpg, heic, and other URI.defined file types. | Nice to have | |||
| 27 | The system shall allow URI to restrict or define allowable file types. | Critical | |||
| 28 | The system shall allow URI to set file size limitations. | Critical | |||
| 29 | The system shall integrate with third.party signature validation systems (e.g., DocuSign). | Nice to have | |||
| 30 | The system shall store and apply digital copies of signatures to documents (e.g., checks, notification letters) with appropriate security permissions. | Nice to have | |||
| 31 | The system shall support application of certificate verified internal electronic signatures providing assurance of authenticity, integrity, and non.repudiation. | Nice to have | |||
| 32 | The system shall limit the number of records generated in a query, with a notification to the user of an incomplete data set. | Nice to have | |||
| 33 | The system shall support the purging of linked electronic files, according to URI.defined schedules, allowing for differing schedules based on the document, module, and/or litigation hold. | Nice to have | |||
| 34 | The system shall provide the ability to track internal correspondence and attach to system records (e.g., service requests or work orders). | Nice to have | |||
| Security | |||||
| 35 | The system shall utilize the existing Active Directory user authentication regardless of deployment method. | Critical | |||
| 36 | The system shall inherit groups from Active Directory for application authentication. | Nice to have | |||
| 37 | The system shall support Single Sign.On (SSO). | Critical | |||
| 38 | The system shall allow for multi.factor authentication. | Critical | |||
| 39 | The system shall provide import and export capabilities with user.level security options to control access to sensitive information. | Critical | |||
| 40 | The system shall encrypt data stored in the database (data at rest). | Critical | |||
| 41 | The system shall encrypt data stored in the application. | Critical | |||
| 42 | The system shall encrypt data in.transit. | Critical | |||
| 43 | The system shall provide role.based security. | Critical | |||
| 44 | The system shall update all security roles automatically (user discretion) when a change in the "master" role is made with updates made in real time and applied to all in.progress activities. | Nice to have | |||
| 45 | The system shall provide security at the following levels: | ||||
| Department; | Nice to have | ||||
| Division; | Nice to have | ||||
| Role or group; | Critical | ||||
| User ID; | Critical | ||||
| Screen; | Nice to have | ||||
| Menu; | Critical | ||||
| Report; | Critical | ||||
| Field; | Nice to have | ||||
| Field value as defined by the URI (e.g., asset category, asset class) | Nice to have | ||||
| Element in chart of accounts; | Nice to have | ||||
| Transaction type; and | Nice to have | ||||
| Other URI.defined levels. | Nice to have | ||||
| 46 | The system shall allow URI to determine which fields are visible to which security roles. | Nice to have | |||
| 47 | The system shall track audit changes throughout the system that creates a log of all records maintained and includes: | Nice to have | |||
| Date; | Critical | ||||
| Time, to the nearest minute; | Critical | ||||
| User; | Critical | ||||
| Information prior to change; | Nice to have | ||||
| Changed information; and | Nice to have | ||||
| Other administrator.configurable information. | Nice to have | ||||
| 48 | The system shall provide configurable audit reports. | Critical | |||
| 49 | The system shall allow auditing within modules to be determined by the module, and configured by the administrator. | Nice to have | |||
| 50 | The system shall allow a URI system administrator to configure the duration in which audit logs are retained (e.g., 90 days). | Nice to have | |||
| 51 | The system shall allow authorized users to have access to a log of security activity to determine users that have signed on and off the system, as well as unsuccessful attempts to sign on to the system. | Critical | |||
| 52 | The system shall allow the URI system administrator to add and change permissions for system access. | Critical | |||
| 53 | The system shall have the ability to log users off the system after a URI system administrator.defined period of inactivity. | Critical | |||
| 54 | The system shall allow multiple levels of URI designated system administrators (e.g., IT/technical and end.user department/functional). | Nice to have | |||
| 55 | The system shall mask fields by user role | Nice to have | |||
| 56 | The system shall apply the same security permissions to system queries and reports as it does to data fields/elements, based on user/role (e.g., data fields masked on a record or transaction are similarly masked on reports run by the user). | Nice to have | |||
| 57 | The system shall be operational on a 24 x 7 scheduled basis. | Nice to have | |||
| User Interface | |||||
| 58 | The system shall provide the user with integrated application modules that offer a consistent user interface to minimize user training and administration of the system. | Critical | |||
| 59 | The system shall provide drop down boxes, or other pick list function, for data selection. | Critical | |||
| 60 | The system supports the ability for the URI to designate which non.system required fields can be "made" required to support business operations. | Critical | |||
| 61 | The system shall provide the ability for the URI to create new fields based on appropriate security permissions. | Nice to have | |||
| 62 | The system shall provide an administrative messaging system (e.g., a message to alert users of system maintenance activity). | Nice to have | |||
| 63 | The system shall provide customizable screens based on roles and permissions. | Nice to have | |||
| 64 | The system shall provide data validation on entry. | Nice to have | |||
| 65 | The system shall create error logs with detail associated with the error. | Nice to have | |||
| 66 | The system shall allow users to send error reports to the URI. | Nice to have | |||
| 67 | The system shall provide configuration options for the level of detail that is logged in error logs. | Nice to have | |||
| 68 | The system shall spell check on any field with the ability for a user to accept or ignore suggestion. | Nice to have | |||
| 69 | The system shall validate locations against address field entries to align with URI address standards. | Critical | |||
| 70 | The system shall have the ability to search by fragment or portion of a word or number. | Critical | |||
| 71 | The system has the ability for multiple windows to be open at the same time. | Critical | |||
| 72 | The system shall warn a user that they are about to execute a process and ask if they want to proceed (i.e., to warn before posting a batch of changes). | Nice to have | |||
| 73 | The system shall allow an administrator to configure which business process are prompted with a warning to proceed, with appropriate security permissions. | Nice to have | |||
| 74 | The system shall allow the system administrator to rename field labels. | Critical | |||
| 75 | The system shall display which environment the user is logged into (i.e., test vs. production). | Critical | |||
| Workflow | |||||
| 76 | The system shall provide workflow functionality in all proposed system modules. | Nice to have | |||
| 77 | The system shall initiate and track workflow and approval processes. | Nice to have | |||
| 78 | The system shall set workflow rules by: | Nice to have | |||
| Role; | |||||
| Department; | |||||
| Any string in the Chart of Accounts or Account; | |||||
| Thresholds; | |||||
| Percentage argument; | |||||
| Numerical argument; | |||||
| Record type (i.e., work order type, asset classification); | |||||
| Priority type; and | |||||
| Other URI.defined criteria. Please describe limitations in comments. | |||||
| 80 | The system shall allow temporary availability status changes of users (e.g., unavailable due to vacation time). | Nice to have | |||
| 81 | The system shall re.route workflow assignments based on availability triggered by user unavailable status. | Nice to have | |||
| 82 | The system shall re.route workflow assignments based on availability triggered by URI.defined periods of no response. | Nice to have | |||
| 83 | The system shall notify a URI.defined user of unsuccessful workflow processes. | Critical | |||
| 84 | The system shall have the ability for a user to review and approve a workflow transaction directly from within an email, without requiring the user to follow a link to the system to approve the transaction (e.g., an approver can click "approve" in the email and have the approval be recorded in the system, and trigger the next applicable workflow step). | Nice to have | |||
| Vendor Support | |||||
| 85 | The vendor will schedule planned outage times to be outside standard URI business hours. | Critical | |||
| 86 | The vendor will provide support during and outside standard URI business hours. | Critical | |||
| 87 | The vendor will notify the URI of any changes to the URI's database or applications as a result of support actions. | Critical | |||
| 88 | The system shall provide an online tutorial to assist users learning the software. | Nice to have | |||
| 89 | The system shall provide online software documentation for all software application modules. | Nice to have | |||
| GIS | |||||
| 90 | The system shall provide bi.directional integration with URI's GIS, including access to server.based and desktop GIS software, geodatabases, and other GIS data, based on appropriate security permissions. | Nice to have | |||
| 91 | The system shall provide tools for geodatabase integration based on common units of geography or key fields (e.g., address) stored in the system and the geodatabase. | Critical | |||
| 92 | The system shall provide an integrated bi.directional data search, query and map display with GIS integration. Map.based GIS searches identify records in the system and system data searches generate GIS.based map displays in office.based and mobile platforms. | Nice to have | |||
| 93 | The system shall utilize GIS tools for buffer zone or interactive "lasso" of map features to select those features and records in the system. | Nice to have | |||
| 94 | The system shall provide GIS.based map displays accessed from the system that enables full GIS functionality for pan, zoom, and other basic map display functions. | Nice to have | |||
| 95 | The system shall provide GIS.based map displays accessed from the system, maintaining all geographic reference and display parameters established in the GIS (e.g., annotation, symbology, scale thresholds, coordinate system/projection settings). | Nice to have | |||
| 96 | The system shall allow for synchronized updates of attribute data stored as fields in the GIS database (i.e., data entries or updates in the system will automatically update corresponding fields in the GIS database), based on appropriate security permissions. | Nice to have | |||
| 97 | The system shall allow a user to use GIS.based tools for interactive distance and area calculations, buffer selection, and other basic mapping functionality. | Nice to have | |||
| 98 | The system shall allow map.based mark.up..allowing "redlining" of a map display (lines, shapes, annotations) and saving that marked.up display as a separate document (e.g., PDF). | Nice to have | |||
| 99 | The system shall have the ability create a work order or inspection associated with longitude and latitude.It should also work with Indoor spaces - Unit_ID, Level_ID, Facility_ID | Nice to have | |||
| 100 | The system shall create a work order or inspection containing multiple addresses or assets. (e.g., stormwater creates a cleaning work order for multiple assets). | Nice to have | |||
| 101 | The system shall have the ability to create a work order or inspection associated with an attribute from URI GIS (e.g., street segment or intersection). | Critical | |||
| 102 | The system shall provide GIS access, map display, and data entry from mobile devices. | Nice to have | |||
| 103 | The system shall provide access to multiple basemaps (e.g., satellite imagery, vector, other URI.defined basemaps). | Nice to have | |||
| Reporting and Dashboards | |||||
| 104 | The system shall provide an operational performance dashboard. | Critical | |||
| 105 | The system shall display information on the performance dashboard in real time. | Nice to have | |||
| 106 | The system shall provide a library of standard reports (i.e., "canned" reports). | Critical | |||
| 107 | The system shall allow a user to modify existing reports, with appropriate security permissions. | Critical | |||
| 108 | The system shall provide an integrated report writer that has a consistent look and feel across all proposed system modules. | Nice to have | |||
| 109 | The system shall save a report as a new template after a user copies and modifies an existing report, with appropriate security permissions. | Nice to have | |||
| 110 | The system shall configure and save ad hoc reports by individual user, with the ability to provide access to other users with appropriate security permissions. | Nice to have | |||
| 111 | The system shall allow generated reports to be viewed on screen prior to being printed/exported. | Critical | |||
| 112 | The system shall allow reports to be generated that are searchable. | Nice to have | |||
| 113 | The system shall allow users configure automatic distribution paths for generated reports (i.e., automatically send a report to a particular user). | Nice to have | |||
| 114 | The system shall allow reports to be generated that have "drill.down" capabilities. | Nice to have | |||
| Mobile Devices | |||||
| 115 | The system shall provide a user interface that is fully accessible from mobile devices. | Critical | |||
| 116 | The system shall support full GIS functionality on mobile devices. | Nice to have | |||
| 117 | The system shall be device agnostic when run on mobile devices (e.g., the system can be run on Android, iOS, Windows). | Nice to have | |||
| 118 | The system is HTML responsive and can adjust to screen size of the mobile device being used (e.g., iPhone, iPad, laptop). | Critical | |||
| 119 | The system shall provide an iOS app for use on both iPhones and iPads. | Nice to have | |||
| 120 | The system shall provide an Android app for use on Android phones and tablets. | Nice to have | |||
| 121 | The system shall allow disconnected data editing on field device (e.g., entering work order comments). | Critical | |||
| 122 | The system shall allow the user to work off.line and sync the data when back on.line. | Critical |
&G &14Jefferson Parish&"-,Bold" Enterprise Asset Mangement (EAM) RFP &"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: January 29, 2025
2.Asset Management
| Definition | |
| Below is a list of Work Order related requirements. Please indicate a response for each in column D. | Please indicate a response in each line item as: |
| Native out of box |
Bhavna Shah: Bhavna Shah:
(Core, out of the box functionality Configurable Bhavna Shah: Bhavna Shah:
Can be done but requires configuration. Functionality will upgrade.
Customizable Bhavna Shah: Bhavna Shah:
Can be done with customization. Functionality will not easily upgrade.
Does not provide Bhavna Shah: Bhavna Shah:
Unable to provide or never been done before with this software.
| Asset Management | ||||
| Req | Description of Capability | Criticality | Enter Response | Vendor Comments |
| General Requirements | ||||
| 1 | The system shall provide an Asset Management module that is integrated with all other proposed system modules including, but not limited to work orders, fleet management, and facilities maintenance. | Nice to have | ||
| 2 | The system shall record total cost of ownership of an asset. | Nice to have | ||
| 3 | The system shall record total cost of combined assets. | Nice to have | ||
| 4 | The system shall allow for an unlimited number of assets. | Critical | ||
| 5 | The system shall support electronic identification of equipment (e.g., RFID and optical QR codes). | Nice to have | ||
| 6 | The system shall have the ability to do periodic inventories via barcode reading, barcode scanning, and/or QR codes. | Nice to have | ||
| 7 | The system shall have the ability to interface with a financial management solution for requisition/purchasing data, including invoices. | Critical | ||
| 8 | The system shall accommodate email notifications through all stages of workflow based on user-defined criteria. | Critical | ||
| 9 | System should have the ability to attach or link documents to an asset or location (example: Attach OEM Preventive Maintenance schedules to an asset record) | Critical | ||
| 10 | The system shall have the ability to export asset information for analysis or input into other systems. | Critical | ||
| Asset Entry | ||||
| 11 | The system shall have the ability to assign asset IDs from GIS and apply to assets within the system. | Critical | ||
| 12 | The system shall allow staff to manually add unique asset numbers, based on appropriate security permissions. | Critical | ||
| 13 | The system should have ability to retain detailed asset information such as state URI tag number, state fleet ID numbers, and photos of the vehicle. | Critical | ||
| 14 | The system shall link fixed asset numbers from the URIs financial system to the department's or division's unique asset number. | Nice to have | ||
| 15 | The system shall have the ability to copy an existing asset record as a starting point for the entry of a new asset. | Nice to have | ||
| 16 | The system shall set department, division, fund, type and user-defined classifications for each asset. | Nice to have | ||
| 17 | The system shall have the ability to establish URI-defined approval levels for asset entries. | Critical | ||
| 18 | The system shall have the ability to establish asset classes or asset groups. | Critical | ||
| 19 | The system shall track an asset acquired through a donation or dedication to the URI. | Nice to have | ||
| 20 | The system shall track assets that are not under URI-ownership (e.g., public-private partnership of an asset or a partially owned asset with a state entity). | Nice to have | ||
| 21 | The system shall accommodate user-defined classes within each asset category, with appropriate security permissions. | Critical | ||
| 22 | The system shall allow an administrator to configure additional asset categories and classes that allow the same functionality of other asset categories and classes, with appropriate security permissions. | Critical | ||
| 23 | The system shall maintain user-defined information for each asset by asset category and class (e.g., acquisition date, department, vendor name, unit cost), with appropriate security permissions. | Critical | ||
| 24 | The system shall link assets in parent-child relationships. | Critical | ||
| 25 | The system shall mass transfer assets from one organization/department code to another and maintain history. | Critical | ||
| 26 | The system shall transfer assets with options including fully or partially, current period or retroactively, and mass transfer. | Critical | ||
| 27 | The system shall maintain asset service records. | Critical | ||
| 28 | The system shall allow assets to be retired and archived from the EAM system. | Critical | ||
| 29 | The system shall allow for the mass archival of assets from the EAM system. | Critical | ||
| Asset Tracking | ||||
| 30 | The system shall maintain user-defined information for each asset type (e.g., unique ID, description, manufacturer, serial number, location, fund, replacement value, responsible department, etc.). | Critical | ||
| Preventative Maintenance | ||||
| 31 | The system shall have the ability to manage multiple Preventative Maintenance (PM) "sets" (e.g., Winter, Summer, Shutdown etc.) with effective dates. | Critical | ||
| 32 | The system shall have the ability to schedule preventative and predictive maintenance tasks by generating a work order and assigning staff to the work order. | Critical | ||
| 33 | The system shall have the ability to manage work on assets geospatially (e.g., identifying assets, creating and searching work orders). | Critical | ||
| 34 | The system shall allow for each PM schedule to maintain: | |||
| PM schedule description; | Critical | |||
| Start date; | Critical | |||
| End date; | Critical | |||
| Asset identification and; | Critical | |||
| User-defined fields to PMs. | Critical | |||
| 35 | The system shall support automated rule-based PM generation based on the following criteria: | |||
| Day-interval rules (monthly, weekly, semi-annually etc.); | Critical | |||
| Other-interval rules (holidays or weekends, other user-defined dates); | Critical | |||
| Run-time interval rules (e.g., 200 hours; 2,000 miles, 200 Gallons, and other user-defined intervals); | Critical | |||
| Support multiple run time rules for the same PM (e.g. every 100 hours up to 1,000 hrs.; every 50 hrs. over 1,000 hrs.); | Critical | |||
| Calculate expected next PM date based in usage rate (e.g., 100,000 gallons per day, 25 miles per day); | Critical | |||
| Allows PMs to be generated based on combination of run-time and day-interval rules; | Critical | |||
| Other URI-defined criteria. | Critical | |||
| 36 | The system shall distribute notifications to assigned staff for work orders associated to PMs. | Critical | ||
| 37 | The system shall flag maintenance activities based on usage. | Critical | ||
| Preventative Maintenance Forecast | ||||
| 38 | The system shall have the ability to forecast upcoming PM work through a user-defined date, with appropriate security permissions. | Critical | ||
| 39 | The system shall have the ability to forecast required materials for upcoming PM work through a user-defined date, with appropriate security permissions. | Nice to have | ||
| 40 | The system shall have the ability to forecast required labor for upcoming PM work through a user-defined date, with appropriate security permissions. | Nice to have | ||
| 41 | The system shall define lead times for PMs to be included in forecast (14 day lead time means a PM due in 45 days will appear in a 30 day forecast), with appropriate security permissions. | Nice to have | ||
| 42 | The system shall individually or mass release forecasted PMs, with appropriate security permissions. | Nice to have | ||
| 43 | The system shall notify appropriate parties if PM is overdue with the option to reschedule, with appropriate security permissions. | Nice to have | ||
| 44 | The system shall support "Manual" PMs (e.g., repetitive jobs that are not automatically scheduled by the system), with appropriate security permissions. | Nice to have | ||
| 45 | The system shall have the ability include/exclude manual PMs in scheduling run (useful for budgeting/forecasting), with appropriate security permissions. | Nice to have | ||
| Inspections | ||||
| 46 | The system shall provide the ability to perform an inspection of an asset to determine and update an asset's condition. | Critical | ||
| 47 | The system shall have the ability to differentiate between service requests, inspections and work orders. | Critical | ||
| 48 | The system has the ability for users to assign staff to a inspection. | Critical | ||
| 49 | The system shall have the ability to categorize inspections by department, location, asset, etc. | Critical | ||
| 50 | The system shall have the ability to support URI-defined inspection statuses. | Critical | ||
| 51 | The system shall have the ability to provide workflow functionality throughout the entire inspection process (e.g., entry, management and reporting). | Nice to have | ||
| 52 | The system shall provide user-customizable inspection forms and checklists for asset classes, subclasses, and individual assets. | Critical | ||
| 53 | The system shall have the ability to link inspections across departments,location, etc. | Critical | ||
| 54 | The system shall have the ability to retain inspection history for all assets when they are split into multiple assets and/or multiple departments. | Critical | ||
| 55 | The system shall have the ability to attach multiple files (including pictures and videos) to inspections at entry, management, or reporting stages (e.g., copy of invoice). | Critical | ||
| 56 | The system shall have the ability to convert inspections into work orders and maintain the linkage between the records throughout the lifecycle of the work order. | Nice to have | ||
| 57 | The system shall have the ability to configure certain fields as required fields within the inspection functionality. | Critical | ||
| 58 | The system shall have the ability to copy an existing inspection record as a starting point for the entry of a new inspection. | Nice to have | ||
| 59 | The system shall have the ability to provide an online calendar showing inspections scheduled by crew, area, date and time. | Nice to have | ||
| 60 | The system shall have the ability to allow emergency inspections to be placed in the front of any queues or batches or sent immediately to dispatch with appropriate security permissions. | Critical | ||
| 61 | The system shall have the ability to route the most efficient order of inspections, based upon GPS location of asset and staff. | Nice to have | ||
| 62 | The system shall have the ability to generate inspections "on the fly" in the field. | Critical | ||
| 63 | The system shall have the ability to associate an inspection to an asset. | Critical | ||
| 64 | The system shall have the ability to create a single inspection plan for multiple assets of the same type. | Critical | ||
| 65 | The system shall have the ability to establish multiple "activities or tasks" within a inspection (e.g., a preventative maintenance inspection which requires several separate tasks). | Critical | ||
| Querying and Reporting | ||||
| 66 | The system shall generate valuation reports on all assets. | Nice to have | ||
| 67 | The system shall report fixed asset expenditures against a capital budget. | Nice to have | ||
| 68 | The system shall monitor or report work orders based on assets by department, category code, or other descriptions (e.g., serial number, replacement year). | Nice to have | ||
| 69 | The system shall query information or generate reports on assets by any user-defined criteria captured by the system (e.g., general ledger account code, location, activity, asset class). | Critical | ||
| 70 | The system shall report a disposal date and value. | Critical | ||
| 71 | The system shall generate a variety of reports based on information such as asset conditions, priority, and risks. | Critical | ||
| 72 | The system shall report on assets based on funding source. | Nice to have | ||
| 73 | The system shall report transactions: period additions, transfers, disposals, and depreciation by asset, type, and general ledger account code. | Nice to have | ||
| 74 | The system shall have the ability to create depreciation reports and other types, both canned and ad-hoc. | Nice to have | ||
| 75 | The system shall have the ability to generate reports based on an asset's condition. | Critical |
&G &14Jefferson Parish&"-,Bold" Enterprise Asset Mangement (EAM) RFP &"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: January 29, 2025
3. Work Orders
| Definition | |
| Below is a list of Work Order related requirements. Please indicate a response for each in column D | Please indicate a response in each line item as: |
| Native out of box |
Bhavna Shah: Bhavna Shah:
(Core, out of the box functionality Configurable Bhavna Shah: Bhavna Shah:
Can be done but requires configuration. Functionality will upgrade.
Customizable Bhavna Shah: Bhavna Shah:
Can be done with customization. Functionality will not easily upgrade.
Does not provide Bhavna Shah: Bhavna Shah:
Unable to provide or never been done before with this software.
| Work Orders | ||||
| Req | Description of Capability | Criticality | Enter Response | Vendor Comments |
| General Requirements | ||||
| 1 | The system shall provide a Work Order module that is integrated with all other proposed system modules including (but not limited to) Service Requests, Inspections, Asset Management, Fleet Management, Facilities Maintenance, and Public Portal/311. | Critical | ||
| 2 | The system shall categorize work orders by fund, department, division, and other URI-defined categories. | Critical | ||
| 3 | The system shall accommodate email notifications through workflow based on user-defined criteria with ability to turn off or on based on user preference. | Nice to have | ||
| 4 | The system shall send customized email notifications to the initiator of a service request and it's subsequent work order. | Nice to have | ||
| 5 | The system shall accommodate dashboard notifications through all stages of workflow, internally. | Critical | ||
| 6 | The system shall automatically generate work orders based on workflow in other system modules (e.g., generating a work order based on inspection results). | Nice to have | ||
| 7 | The system shall provide workflow functionality throughout the entire work order process (e.g., entry, management, reporting). | Critical | ||
| 8 | The system shall provide canned, configurable templates for work orders, preventative maintenance schedules and tasks, work requests, inspections, material order forms, and other common documents. | Nice to have | ||
| 9 | The system shall create, modify and search work orders on the URI's GIS map. | Nice to have | ||
| 10 | The system shall integrate with the URI's email system for notifications by email. | Critical | ||
| 11 | The system shall support the outsourcing of work orders to external agencies. | Critical | ||
| 12 | The system shall link work orders across Departments or Divisions. | Critical | ||
| 13 | The system shall have the ability to configure the length of time work order information is retained by work order type, based on user-defined criteria (e.g., up to 50 years). | Critical | ||
| 14 | The system shall have the ability to retain work order history for all assets when they are split into multiple assets and/or multiple departments. | Critical | ||
| 15 | The system shall have the ability to add and tie location/address to the work order. | Critical | ||
| 16 | The system shall interface with the inventory system, post materials and cost in inventory (warehouse) to a work order, and update inventory. | Critical | ||
| 17 | The system shall use assemblies on work order, can create materials list and automatically allocate items in the inventory system. | Nice to have | ||
| 18 | The system shall "soft close" work orders to prevent charges to work order ahead of closing, with the ability to reopen the work order with appropriate security permissions. | Nice to have | ||
| 19 | The system shall have the ability attach files (including pictures) to work orders at entry, management or reporting stages (e.g., copy of invoice). | Critical | ||
| 20 | The system shall have the ability to accommodate URI-defined work order statuses. | Critical | ||
| 21 | The system shall have the ability to indicate, notify, and report on the status of work orders (e.g., manager notified of work still in progress) based on URI-defined parameters (e.g., five hours of inactivity). | Critical | ||
| 22 | The system shall have the ability for work orders to have parent child relationships. | Critical | ||
| 23 | The system shall have the ability to provide a heat map for assets and locations where multiple work orders are scheduled or have occurred to help users identify high-intensity assets or locations. | Nice to have | ||
| 24 | The system shall have the ability to capture URI-defined information on a work order. | Critical | ||
| 25 | The system shall have the ability to customize asset work order screen layouts by location or workstation (e.g., simplified layouts in the field versus back office). | Nice to have | ||
| 26 | The system shall allow configurable work order formats based on the type of work being performed (e.g., planned vs. corrective). | Nice to have | ||
| 27 | The system shall have the ability to handle both in.house (e.g., Inspections, oil changes) and outside vendor work orders (e.g.,Warranty work, major repairs)efficiently, integrating data from multiple sources to avoid duplication. | Critical | ||
| 28 | System should allow the ability to review previous work order and maintenance history on an asset or location while in a current work order | Critical | ||
| 29 | System should record and track comments and feedback from trades, ensuring a documented history of communications. | Critical | ||
| 30 | The ability to capture and roll up life cycle cost data in order to make better repair or replace decisions. | Critical | ||
| 31 | Ability to submit child work orders to relevant groups (e.g., capital projects, small projects) to keep track of assignments | Critical | ||
| 32 | Ability to attach or integrate content (such as OEM manuals, photographic records, video, etc) of equipment with the work order system | Critical | ||
| Scheduling | ||||
| 33 | The system shall provide a scheduling feature to automatically schedule regular service requests/work orders by calendar avoiding weekends, holidays, and user-defined dates. | Nice to have | ||
| 34 | The system shall provide user-defined work schedules by individuals or groups. | Nice to have | ||
| 35 | The system shall schedule service requests or work orders by crew, date and/or time. | Nice to have | ||
| 36 | The system shall provide a date and time window for scheduling a work order. | Nice to have | ||
| 37 | The system shall provide an on-line calendar showing service requests or work orders scheduled by crew, area, date and time. | Nice to have | ||
| 38 | The system shall have the ability to re-schedule service requests or work orders. | Nice to have | ||
| 39 | The system shall allow for an authorized user to place emergency service requests in the front of any queues or batches or to sent immediately to dispatch. | Critical | ||
| 40 | The system shall sort and dispatch the service requests by a user-defined sequence by service request type (e.g., route, account number, date, location address, work group). | Nice to have | ||
| 41 | The system shall associate a work order to an asset or location. | Critical | ||
| 42 | The system shall have the ability to add declared emergency designations to work orders. | Critical | ||
| 43 | The system shall add URI-defined priority levels to work orders. | Critical | ||
| 44 | The system shall have the ability to mass generate and mass close work orders based on user roles and permissions. | Nice to have | ||
| 45 | The system shall have the ability create a campaign or group of work orders for multiple assets of the same type. | Nice to have | ||
| 46 | The system shall provide a time sheet tracker for all work orders, allowing staff to track how many hours they have worked on work orders in a full day. | Nice to have | ||
| 47 | The system shall provide time stamps of work orders at all stages of progress. | Critical | ||
| 48 | The system shall capture URI-defined data on work orders. | Critical | ||
| 49 | The system shall capture work order entry information about the requestor through Active Directory. | Nice to have | ||
| 50 | The system shall assign a sequentially generated identification number to each work order. | Critical | ||
| 51 | The system has the ability for an authorized user to assign a priority to the work order being entered, based on a drop-down menu of options. | Critical | ||
| 52 | The system shall provide definitions for each priority option presented in the drop-down menu. | Critical | ||
| 53 | The system shall have the ability to generate work orders "on the fly" in the field. | Critical | ||
| 54 | The system shall allow for work order data to be entered in the field. | Critical | ||
| 55 | The system shall recognize duplicate work orders and notify requestor to confirm whether to proceed with new work order entry. | Nice to have | ||
| 56 | The system shall allow users to customize work orders, with the ability to develop templates from customized work orders for future use (e.g., require data fields for disaster declarations and templatize the disaster work order). | Critical | ||
| 57 | The system shall track all work orders through all stages of work, providing a unique work order identification | Critical | ||
| 58 | The system shall allow the establishment of "work-groups" for certain work order types, allowing work orders to be routed to multiple departments. | Nice to have | ||
| 59 | The system shall allow work order types to be modified and transferred among "work-groups." | Critical | ||
| 60 | The system shall have the ability to establish multiple "activities or tasks" within a work order (e.g., a preventative maintenance work order which requires several separate tasks). | Critical | ||
| 61 | The system shall record materials, equipment, and labor to work orders at a defined point in the workflow. | Critical | ||
| 62 | The system shall have the ability to identify inventory and materials needed to complete a work order. | Critical | ||
| 63 | The system shall identify tools and equipment needed to complete a work order. | Critical | ||
| 64 | The system shall generate "pick-lists" to pull needed inventory parts and materials prior to the work order being started. | Nice to have | ||
| 65 | The system shall allow multiple configurable work order activities based on common recurring repairs. | Nice to have | ||
| 66 | The system shall apply unit costs per task for work orders contracted with a third-party or external vendor (e.g., maintenance work done to a sign is $95 a sign for 10 signs, resulting in a $950 total for work). | Critical | ||
| 67 | The system shall integrate with the URI's GIS system to allow for automated data sharing between GIS and the EAM system. | Critical | ||
| 68 | The system shall search by work order number and drill down to associated details (e.g., expenses or revenues). | Critical | ||
| 69 | The system shall allow users to flag work orders as active or inactive, with a URI-defined reason code. | Nice to have | ||
| 70 | The system has the ability for users to assign staff to a work order. | Critical | ||
| 71 | The system has the ability for users to reassign a work order if incorrectly assigned, with appropriate security permissions. | Critical | ||
| 72 | The system shall establish and schedule recurring preventative maintenance work orders. | Critical | ||
| 73 | The system shall have the ability to flag work orders as a capital work order as compared to O&M work order, accounting for capital work orders tracked separately. | Nice to have | ||
| 74 | The system shall have the ability to calculate and apply overhead to work orders based on type of work order. | Nice to have | ||
| 75 | The system shall have the ability to support multiple overhead categories. | Nice to have | ||
| 76 | The system shall have the ability to select which overhead applies to work order type based on type. | Nice to have | ||
| 77 | The system has the ability selectively apply when specific overheads apply to a work order. | Nice to have | ||
| 78 | The system shall have the ability to configure user-defined overhead rates. | Nice to have | ||
| 79 | The system shall have the ability to configure unit rates for URI-defined work order activities. | Critical | ||
| 80 | The system shall have the ability to add contract line items to work orders, including unit costs, to automatically calculate costs (e.g., third-party maintenance costs) associated to the work order. | Critical | ||
| 81 | The system shall have the ability to maintain historical contract information, including work complete and associated work orders by line item. | Critical | ||
| 82 | The system shall have the ability to generate cost estimates based on contract line item prices (e.g., square yard of concrete pavement, linear foot of pipe installation). | Nice to have | ||
| 83 | The system shall have the ability for users to add actual contract costs to work orders, with the ability to compare actual costs to the cost estimate. | Critical | ||
| 84 | The system shall have the ability to configure required fields on work orders. | Nice to have | ||
| 85 | The system has the ability for a work order to track problem codes and failure codes for failure analysis. | Nice to have | ||
| 86 | The system shall plan budget and work based upon configurable URI-defined inputs (e.g., asset condition). | Nice to have | ||
| 87 | The system shall have the ability to provide notifications to assigned staff based on URI-defined criteria (e.g., three days to address a work order). | Nice to have | ||
| 88 | The system shall provide escalation pathways based on URI-defined criteria (e.g., minimum period of no response). | Not needed | ||
| 89 | The system shall allow a mobile, thin-computing, and offline work order interface for URI employees working in the field with a smart phone, tablet, or laptop computer. | Critical | ||
| 90 | They system shall allow for mobile entry without access to cellular service and save work until a device is connected to the internet. | Nice to have | ||
| 91 | The system has mobile routing functionality, allowing for turn-by-turn directions to each work location. | Nice to have | ||
| 92 | The system shall allow data editing on a mobile device (e.g., entering inspection comments, updating results). | Critical | ||
| 93 | The system shall save a work order or item in-progress without completing. | Critical | ||
| 94 | The system has the ability for staff to view details related to the work order on mobile device. | Critical | ||
| 95 | The system has the ability for mobile selection of addresses, parcels, assets, coordinates, and other features from GIS (e.g., select an asset from a map), allowing staff to view previous activity at the location. | Nice to have | ||
| 96 | The system shall capture time-stamp and location data on images taken on mobile device. | Nice to have | ||
| 97 | The system shall collect unlimited images in the field and attach them to the inspection record, subject to device storage limitations. | Critical | ||
| 98 | The system shall allow for staff to attach videos to the work order record, subject to device storage limitations. | Nice to have | ||
| 99 | The system shall use mobile devices for staff to access schedules. | Critical | ||
| 100 | The system shall view assigned work orders on mobile device using a map view. | Nice to have | ||
| 101 | The system shall assign work orders on mobile devices by parcel, asset, address, coordinates, staff member, and other user-defined criteria. | Nice to have | ||
| 102 | The system shall create a new work orders from the field. | Critical | ||
| 103 | The system has the ability for an authorized staff to assign or re-assign work orders while in the field. | Critical | ||
| 104 | The system has the ability for an authorized staff to cancel or reschedule work orders. | Critical | ||
| 105 | The system shall display work order notes and comments on a results report. | Critical | ||
| 106 | The system shall allow users to query on all data fields in the work order module in order to provide a user-defined query screen. | Critical | ||
| 107 | The system shall have the ability to generate a master report of all work orders submitted. | Critical | ||
| 108 | The system shall generate a variety of reports based on work orders that have been billed to internal or external parties. | Critical | ||
| 109 | The system shall have the ability to generate a variety of reports based on time spent by employees resolving work order requests. | Critical | ||
| 110 | The system shall have the ability to generate reports to identify areas of large work order volume (i.e., common problems). | Critical | ||
| 111 | The system shall have the ability to generate "heat-maps" on the system's map for areas of large work order volume. | Nice to have | ||
| 112 | The system shall have the ability to generate a report of priority/SLA exceptions. | Nice to have | ||
| 113 | The system shall have the ability to generate charts and graphs related to work order information. | Critical | ||
| 114 | The system shall have the ability to allow users build and create custom reports based on funding type, type of work, location of work, asset, date range, or other URI-defined feature. | Nice to have |
&G &14Jefferson Parish&"-,Bold" Enterprise Asset Mangement (EAM) RFP &"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: January 29, 2025
4.Facilities Maintenance
| Definition | |
| Below is a list of Facilities Maintenance related requirements based on Industry standards. | Please indicate a response in each line item as: |
| Native out of box |
Bhavna Shah: Bhavna Shah:
Core, out of the box functionality Configurable Bhavna Shah: Bhavna Shah:
Can be done but requires configuration. Functionality will upgrade.
Customizable Bhavna Shah: Bhavna Shah:
Can be done with customization. Functionality will not easily upgrade.
Does not provide Bhavna Shah: Bhavna Shah:
Unable to provide or never been done before with this software.
| Facilities Maintenance | ||||
| Req | Description of Capability | Criticality | Enter Response | Vendor Comments |
| General Requirements | ||||
| 1 | The system shall provide a facilities maintenance module that is integrated with other system modules including, but not limited to public portal/311, inventory, work orders, and asset management. | Critical | ||
| 2 | The system shall maintain a library of standard preplanned work order or job plan templates. | Critical | ||
| 3 | The system shall create and store standard job plans steps/operations. | Critical | ||
| 4 | The system shall identify leased facilities and when appropriate track work orders and/or operational costs. | Critical | ||
| 5 | The system shall identify operational activities and responsibilities. | Critical | ||
| 6 | The system shall identify maintenance programs and responsibilities. | Critical | ||
| 7 | The system shall track warranty information. | Critical | ||
| 8 | The system shall easily identify if a replacement part on a work order is under warranty. | Nice to have | ||
| 9 | The system shall have the ability to manage vertical assets according to defined levels (e.g., building, floor, suite, asset, and components). | Critical | ||
| 10 | The system shall have the ability to provide drill down to view all subassets, including all service requests, work orders, and preventative maintenance, associated with an asset. | Critical | ||
| Condition Assessment | ||||
| 11 | The system shall have the ability to assess all assets, including administrative structures, warehouses, and various support facilities. | Critical | ||
| 12 | The system shall identify and document current facility condition deficiencies and corrections to the deficiencies. | Nice to have | ||
| Querying and Reporting | ||||
| 13 | The system shall provide a graphical view of work order assignments by individual employee or work group. | Nice to have | ||
| 14 | The system shall show actual elapsed and estimated remaining time and expenses on the work order. | Nice to have | ||
| 15 | The system shall provide an employee the ability to view equipment requirements for a job. | Nice to have | ||
| 16 | The system shall have the ability to track cost of work orders for multiple business units. (e.g., Department, work order type). | Critical |
&G &14Jefferson Parish&"-,Bold" Enterprise Asset Mangement (EAM) RFP &"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: January 29, 2025
5.Fleet Management
| Definition | |
| Below is a list of Fleet Management related requirements. Please indicate a response for each in column D. | Please indicate a response in each line item as: |
| Native out of box |
Bhavna Shah: Bhavna Shah:
Core, out of the box functionality.
Configurable Bhavna Shah: Bhavna Shah:
Can be done but requires configuration. Functionality will upgrade.
Customizable Bhavna Shah: Bhavna Shah:
Can be done with customization. Functionality will not easily upgrade.
Does not provide Bhavna Shah: Bhavna Shah:
Unable to provide or never been done before with this software.
| Fleet Management | ||||
| Req | Description of Capability | Criticality | Enter Response | Vendor Comments |
| General Requirements | ||||
| 1 | The system shall provide a Fleet Management module that is integrated with all other proposed system modules including (but not limited to) asset management and work orders. | Nice to have | ||
| 2 | The system shall support electronic notifications. | Critical | ||
| 3 | The system shall provide an employee self-service portal where fleet management tasks can be performed including but not limited to requesting maintenance, viewing inspection results, updating inventory record, and requesting equipment. | Nice to have | ||
| 4 | The system shall have the ability to record total cost of ownership of a fleet-maintained asset. | Critical | ||
| 5 | The system shall have the ability to track URI-defined statuses of fleet-maintained assets (e.g., active, disposed). | Critical |
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 .