Enterprise Asset Management Software and Implementation Services

The Vendor is required to provide Enterprise Asset Management (EAM) Software and Implementation Services.
- Act as a Systems Integrator with the capability to deliver a full end-to-end solution set and associated systems integration services.
- This includes the Core EAM Software Solution, any anticipated Third-Party Software Solution(s) needed to fully meet
- Asset Identification:
•    Allow STA to define an alternate asset ID number to identify the asset (potential uses for the alternate ID number are to cross-reference with an energy management system number, legacy number, to indicate a property tag number, etc.)
•    Maintain general asset information: asset class and subclass/type, description, asset status and disposition (sub-status), associated cost center, asset owner, asset operator, maintenance location, asset criticality, OEM, and serial numbers where applicable
•    Ability to maintain general information and maintenance records and associate directly to a specific asset
•    Ability to define and associate attributes for each asset, asset class, and/or asset type. Attributes may include, but not limited to asset manufacturer, make and model, manufacturer part number
•    Provide the capability to generate or print physical asset ID tags to affix to the asset; the physical tag will contain STA's specified data on the asset
- Asset Acquisition Data
•    Allow a designation as to how the asset was acquired (e.g., purchased new, purchased used, constructed, refurbished, donated, leased/rented, etc.) based on STA's defined categories
•    Capture the acquisition cost detail based on STA's defined categories, such as purchase cost, contractor cost, design cost, etc. and designate a total acquisition cost
•    Store the source of the asset, such as a vendor name, contractor name, etc., and provide the ability to cross-reference the source with supplier file in the procurement or contracts system of record
•    Capture the source of funds for the asset acquisition, including the ability to designate multiple grants, funds and funding sources; identify each funding source as capital or operating
•    Provide a cross reference to the primary acquisition documents, such as PO number, contract number, Building Information Model (BIM) number, project number, etc.
•    Store the estimated useful life of the asset (in years) and projected retirement/replacement date
•    Store the major milestone dates for the asset acquisition process as defined by STA, such as purchase or project completion date, acceptance date, date placed in-service, etc.
•    Store lease/rental information for any assets which are leased by STA
- Onboarding and Retirement
•    Provide the capability to obtain and upload/import assets electronically through an interface file from a contractor/provider during the facility/asset turn-over process. This may include a file from bus manufacturer with relevant bus information
•    Support the import of new asset data in accordance with industry standards for asset onboarding and interface/data exchange
•    Support batch upload of data to the system from standard spreadsheet file formats to import various types of data from vendors (e.g., configurations, parts, work orders, etc.)
•    Support batch upload of files (such as PDFs or JPGs) connected to key data records for configurations, parts, work orders, etc.
•    "The system shall support the identification and management of asset relationships, including hierarchical parent-child structures. The system must allow for:
o    Multi-level asset hierarchies linking parent and child assets.
o    Visual representation of asset relationships."
•    Provide the ability to create an asset template for use in rapidly creating a set of asset records by entering the set of unique asset identification numbers
•    Provide the capability to update asset records during "on boarding" with acceptance dates, in-service dates, warranty start dates, and other asset data; for assets initially maintained by the vendor during contracted initial service
•    Provide the ability to integrate with STA's ERP procurement and contracts functions to create new asset records based on assets purchased or received and to identify assets that are retired and/or disposed
•    Provide the ability to integrate with STA's GIS system (Esri ArcGIS Pro) to create new asset records based on assets in the GIS environment
•    Support the removal of assets from service and update the asset status based on STA's defined removal process to track the status of the asset, such as inactive, decommissioned, retired or disposed
•    Capture asset disposal information, such as reason, method of disposal, disposal date, and salvage value
•    Retain the ability to access all information and detailed history for disposed assets
•    Ability to define the contracted vendor responsible for maintaining the asset
•    Provide the ability to define asset criticality for individual assets based on a user-defined scale and provide the capability to determine criticality for asset classes, systems and subsystems based on user-defined calculation criteria. The criticality will allow STA to prioritize work of assets that have a higher criticality rating
•    Provide for recording asset lifecycle information including purchase order/contract, purchase date and cost, in-service date, projected and actual retirement dates, expected life
•    Provide links to view work/PM/inspection histories, open work including campaigns and projects, current PM/inspection schedules, asset usage/meter readings (including fluids, mileage, hours)
•    Provide links to documentation including photos, images, technical specifications, electronic parts catalogs, contractual documents
•    Provide links to warranty contracts and warranty claims for assets, major components, and parts
•    Provide multiple options to designate and search for the physical location of assets, facilities and equipment such as address, geocode (latitude/longitude/elevation), national geodetic survey standard coordinate system or an agency-defined location code
•    Provide the capability to search assets by multiple  location referencing schemes and other parameters
- Technical Requirement
•    Provide a secure system with strong authentication, configuration, user control and other features
•    The provided environment must be in compliance with ISO 27001 standards and meet ISO 27001 certification
•    Comply with the current applicable interoperability and security standards.
•    Comply with data categorization industry standards (e.g. PII, PCI)
•    Administration interfaces should require strong authentication and authorization
•    Provide for separate administrator privileges based on roles (e.g., site content developer, solution administrator)
•    Provide secure remote administration channels (e.g., SSL, VPN)
•    Provide secure configuration stores from unauthorized access and tampering
•    Configuration credentials and authentication tokens are not held in plain text in configuration files (e.g., SSH client config file with remote login id and password)
•    User accounts and service accounts used for configuration management should have only the minimum privileges required for the task
•    Store and maintain user profiles and roles (role-based access control)
•    Provide the ability for users to define and store user profile information, including but not limited to: the user’s name, user id, employee id, professional designation, etc.
•    Ability to link the user logon id to his/her employee number or contractor id number, as well as to the location or group of locations to which the user is assigned
•    Ability to identify the type of single enterprise authentication used for solution access (e.g. Azure active directory and duo security)
•    Provide the ability to define user roles and user groups and associate these with user accounts
•    Allow the creation and assignment of user roles that limit a user's privileges to their scope of practice
•    Allow the creation and assignment of user roles that define their required and allowed actions in workflows
•    Allow the assignment of multiple roles to be selected from by the user at login
•    Ability to use a single user sign-on for all modules with security configured for each module
•    Ability for security module to be maintained by an in-house administrator
•    Provide expiration dates for passwords
•    Automatically notify users and force them to change passwords on a pre-defined frequency
•    Provide an efficient, flexible way to control and administer multiple levels of user access
•    Ability to set password length and change rules per STA requirements (e.g. Passwords can be changed only once in a 2-day period, passwords should not be words in the English dictionary)
•    Provide lock-out capability after a pre-defined number of unsuccessful user sign-on attempts
•    Ability to not display passwords as clear text (password masking)
•    Provide integrated security managed in a central accounts database
•    Provide a viewable list of users logged on to system in real-time
•    Allow addition of user-defined messages to logon screen
•    Ability to integrate with a third-party identity provider (IDP) for authentication with known protocols (EG, LDAP, SAML, OAUTH) 
•    Capability of notifying the end user of account password expiration date as well as the ability to reset the password through the system's user interface
•    Perform secure and seamless logon for all third party integrated systems (offered as a part of this proposal/procurement)
•    Encrypt passwords before being stored or transmitted
•    Ability to disallow more than one active session per sign-on identification
•    Allow users to re-authenticate and remotely log out of an active user session before logging in at another location
•    Require password re-entry before user is allowed to perform functions predefined as “high security”
•    Restrict users without specific dba privileges from directly accessing the database
•    Ability to assign application access rights across entire suite of applications at a single point of entry
•    Support a pre-defined time for passwords to be changed per user’s role and access level
•    Provide administrative ability to block users’ access during pre-defined off-hours
•    Provide the option for multi-factor authentication for users with higher security access
•    Authenticate users before system access
•    All user and administrator accounts are clearly identified
•    Use least-privileged accounts
•    Ensures that minimum error information is returned in the event of authentication failure.

- Contract Period/Term: 5 years
- Pre-Proposal Conference Date: November 12, 2025
- Questions/Inquires Deadline: December 01, 2025