METRO_Current_State.pdf

CURRENT STATE

MEMORANDUM

INTELLIGENT

TRANSPORTATION

SOFTWARE

PROJECT MANAGER

METRO REGIONAL

TRANSIT

AUTHORITY

JUNE 6, 2025

PRODUCED BY:

BURGESS & NIPLE

WITH FORWARD

MOMENTUM AND

LEVERDE

METRO | Table of Contents

Current State Memorandum i

TABLE OF CONTENTS

CHAPTER 1. Introduction

CHAPTER 2. Background

CHAPTER 3. System Overview

Computer Aided Dispatch/Automated Vehicle Location (CAD/AVL) System

Finance System, Time Tracking, Payroll & Benefits Processes; and Human Resource Information System (HRIS)

Procurement

Asset Management & Maintenance System

Route Planning/Scheduling (HASTUS)

Real-Time Bus Tracking Information

Security Systems (AngelTrax with Trackit)

Infotainment System

Voice Call Management

CHAPTER 4. System Architecture

Overview

CHAPTER 5. Integrations

Key System Integration Points (and Gaps):

Summary of Integration Deficiencies

CHAPTER 6. Stakeholders

CHAPTER 7. Support Processes

Key Support Processes and Mechanisms

CHAPTER 8. Issues, Challenges, and Lessons Learned

System-Wide Needs and Gaps

CHAPTER 9. METRO Capital Programming Information For System Upgrade/Replacement

CHAPTER 10. Conclusions

METRO | Table of Contents

Current State Memorandum ii

LIST OF FIGURES

Figure 1: Current Timekeeping & Payroll Process

Figure 2: Current Fueling Process

Figure 3: Current Asset Management System

Figure 4: Current System Design

LIST OF ABBREVIATIONS

Abbreviation Definition

ADA Americans with Disabilities Act

AP Accounts Payable

APC Automated Passenger Counter

API Application Programming Interfaces

AR Accounts Receivable

CAD/AVL Computer Aided Dispatch / Automatic Vehicle Location

CAN Controller Area Network

DVR Digital Video Recorder

EEC Employee Engagement Center

ERP Enterprise Resource Planning

GPS Global Positioning System

GTFS-RT General Transit Feed Specification – Real Time

HR Human Resource

HRIS Human Resources Information System

ITS Intelligent Transportation System

IVLU Integrated Vehicle Logic Unit

MDT Mobile Data Terminal

NTD National Transit Database

PM Preventive Maintenance

PO Purchase Order

RTA Regional Transit Authority

METRO | Introduction

Current State Memorandum 1

CHAPTER 1. INTRODUCTION

This Current State Memorandum is a work-in-progress deliverable for Task 1 under the

Intelligent Transportation Systems (ITS) Project Manager engagement for the METRO Regional

Transit Authority (METRO). Commissioned by METRO, the Burgess & Niple (B&N) team is undertaking this project to assist METRO in navigating the complexities of its existing technology landscape and planning strategically for future system upgrades and replacements.

This document presents the B&N team’s initial findings regarding METRO’s operational environment, technological infrastructure, integration points (or lack thereof), user workflows, and associated stakeholder experiences. The primary systems under review in this assessment include the Computer Aided Dispatch/Automatic Vehicle Location (CAD/AVL) system (Avail), the

Finance and Payroll systems (Fleet-Net, with NeoGov primarily for HR functions), the Asset

Management and Maintenance System (primarily Fleet-Net), and related interfaces or supporting technologies.

METRO currently utilizes a suite of information technology systems critical to its daily functions.

However, as observed during initial discovery and confirmed through stakeholder interviews, many of these systems are exhibiting challenges typical of aging technology platforms within the transit industry. These challenges include, but are not limited to, limited integration capabilities between core systems, a significant reliance on manual workarounds involving paper processes or Microsoft Excel, data integrity concerns stemming from inconsistent reporting or black-box calculations (i.e. processes where the internal workings are not transparent), hardware obsolescence impacting reliability and parts availability, and user interfaces that impede efficiency.

This current assessment effort builds upon the work documented in the 2022 “Transit

Technology Review, Evaluation and Acquisition Plan” prepared by IBI Group. The B&N team’s role is to validate and significantly expand upon those earlier findings, providing a deeper, more granular understanding of the day-to-day realities, pain points, and unmet needs across

METRO’s departments to inform future procurement efforts.

The purpose of this memorandum is to provide METRO leadership and project stakeholders with a shared, accurate understanding of the existing technological baseline. This documented understanding will serve as the foundation for subsequent project phases, including the development of a future-state Concept of Operations (ConOps), the definition of detailed system requirements, and the formulation of an informed, objective procurement strategy.

Ultimately, this assessment aims to equip METRO to make strategic, data-driven decisions regarding investments in technology, ensuring that future systems directly support METRO’s

METRO | Background

Current State Memorandum 2 mission to provide efficient, safe, reliable, and accessible mobility services by enhancing operational efficiency and improving the user experience for both staff and riders.

CHAPTER 2. BACKGROUND

METRO provides essential mobility services to the community, relying on a complex ecosystem of technology systems to support its diverse operations. Recognizing the current challenges with managing aging infrastructure and the opportunities presented by modern technology, METRO has proactively initiated this project to strategically evaluate and potentially replace several core operational software systems.

In 2021-2022, an initial assessment of METRO’s technology landscape was performed which provided a valuable baseline, identifying existing systems, outlining stakeholder needs, scanning industry trends, and recommending a portfolio of potential technology projects prioritized over a multi-year horizon. Key systems identified as needing near-term attention included those supporting operations (CAD/AVL), Finance, Payroll, Maintenance, and Asset

Management.

Building upon that work, METRO selected B&N, Forward Momentum and Leverde (referred to collectively as the B&N Team) in early 2025. The B&N Team’s primary objective under this engagement is to provide comprehensive project management and procurement assistance services. Early tasks focus on developing a comprehensive project plan and timeline (with a phased approach for each module/department) for the project; outlining key milestones, timelines, deliverables, and resource requirements for the potential implementation of an ITS system (CAD/AVL), Finance, Inventory Management, and Maintenance software.

This assessment is informed by:

• Review of the 2022 IBI Group report and other provided system documentation (e.g.

system architecture diagrams, NEORide procurement documents relevant to METRO);

• Onsite interviews conducted on February 4-5th, 2025 with various departments within

METRO including executive leadership, finance, procurement, operations/dispatch, maintenance, information technology, communications, and planning;

• Ongoing bi-weekly project meetings and targeted follow-up communications with

METRO subject matter experts; and

• Follow-up onsite visit conducted May 5-6, 2025, focused on detailed process mapping, observation of specific operational workflows (dispatch, payroll, maintenance), and addressing outstanding questions compiled by the B&N Team.

Establishing this comprehensive current state understanding is a critical prerequisite for successful project execution. It ensures that subsequent project activities, including the

METRO | Background

Current State Memorandum 3 development of a ConOps, requirements definition, and the creation of robust procurement documents are grounded in METRO’s actual needs and operational context.

METRO | System Overview

Current State Memorandum 4

CHAPTER 3. SYSTEM OVERVIEW

METRO utilizes a diverse array of information technology systems to support its daily operations, planning functions, maintenance activities, financial management, and customer interactions. As is common in the transit industry, particularly with systems implemented over many years, METRO’s current technology ecosystem is quite diverse. While some systems function adequately for their core purpose, many of these systems are facing the challenges of age, including limited integration capabilities, heavy reliance on manual processes as workarounds, and issues with obtaining reliable, actionable data. These challenges, combined with evolving operational needs, prompted the initiation of this project.

This chapter provides an overview of the primary technology systems pertinent to this project and currently in place at METRO. The team has detailed the current vendors, core functionalities used by METRO, known integration points (or lack thereof), and the high-level issues and challenges identified during our initial discovery. It is important to note that two historically separate key systems, the CAD/AVL (Avail) and the Finance/Payroll/Maintenance

Enterprise Resource Planning (ERP) (Fleet-Net) are now owned by the same parent company, Avail Technologies, Inc. although their integration remains a significant concern.

Computer Aided Dispatch/Automated Vehicle Location (CAD/AVL)

System

Vendor: Avail Technologies, Inc.

Core Functions: The Avail CAD/AVL system serves as the operational backbone for tracking and managing the operational aspects of METRO’s fixed route services. Its primary functions include real-time vehicle location tracking, dispatch communications (voice and data), schedule and headway adherence monitoring, pre-trip inspection management, passenger counting via integrated Automatic Passenger Counters (APCs), and providing real-time data feeds for passenger information systems like myStop and third-party apps via General Transit Feed

Specification – Real Time (GTFS-RT). Various departments interact with the system, including

Operations (Dispatch for daily management, extra board, call-offs), Maintenance (for vehicle fault codes, work order initiation from road calls), Planning (for service analysis, runtime analysis, ridership data extraction), IT (managing user accounts, cloud environment, troubleshooting), and Customer Care (responding to customer inquiries).

System Components:

• Onboard Hardware: METRO operates a mixed fleet with at least four different generations of Avail onboard hardware. Two of these hardware generations are considered obsolete (no longer supported by Avail) with no available replacement parts.

Current State Memorandum 5

Key hardware components include an Integrated Vehicle Logic Unit (IVLU), a Mobile

Data Terminal (MDT) touchscreen interface, PA amplifier, power filtering, backup battery, and associated control modules and wiring harnesses. Integration exists with the Infodev APCs, digital headsigns (Message Point Media), the vehicle’s J1708/J1939

CAN (Controller Area Network) bus for vehicle systems monitoring, the Motorola radio system for voice communication, and fare collection equipment (GFI, Masabi – though integrations appear limited). Notably, separate GPS antennas are required for the Avail system, AngelTrax video system, and Cradlepoint routers, indicating a lack of consolidated GPS data sharing.

• Central Software: The central system provides dispatchers with interfaces for live mapping (often unreliable, leading to use of paper and/or Swiftly), vehicle status monitoring, communication tools (canned messages/radio, though text messaging is rarely used by dispatch or checked by drivers), operator timekeeping displays (view-only, as actual payroll processing is complex), attendance tracking views, and pre-trip failure reporting (which doesn't clearly show what failed and lacks prioritization).

Passengers can interact via the Avail-provided myStop mobile app (not promoted due to clunkiness/accuracy) and a text-for-next bus service (popular, but Metro gets no analytics and Avail owns the number). Avail also generates the GTFS-RT feed consumed by Swiftly and other third-party applications like the Transit app, which is crucial because Avail's own real-time data is too slow. The system’s recent migration to a cloud environment has been described by staff as problematic: it functions as a slow, laggy remote desktop connection to legacy Microsoft Access databases hosted by Avail, requiring multiple logins (one for the Remote Desktop to Avail's M365, then another for

Avail itself), using Avail-managed credentials (@availtech.com) that break OneDrive sync upon password expiration, and restricting file saving to Avail's OneDrive.

Key Issues and Challenges: The Avail CAD/AVL system presents significant challenges across multiple functional areas:

• Data Integrity and Reporting: This is a primary area of concern. Staff report pervasive issues with inaccurate and unreliable data for key metrics like ridership, on-time performance, and run times. Generating reports is difficult, often requiring manual data extraction and extensive cleanup in external tools like Excel. Different reports that should show the same data often yield different results. Avail has reportedly provided little transparency into its data calculation methodologies or database schemas, making independent validation or troubleshooting extremely difficult. The method for reporting

National Transit Database (NTD) data, particularly the averaging of APC counts for buses without functioning counters, is also a concern. Furthermore, METRO lacks access to analytics on the usage of the myStop app or the text-for-next-bus feature.

Current State Memorandum 6

• System Performance and User Interface: The user experience, particularly after the cloud migration, is frequently cited as poor. Staff describe the interface as clunky, slow, and prone to freezing. Routine tasks often require an excessive number of clicks. The dispatch interface has limitations, such as the inability to resize map and pool list views independently. The system relies on Avail’s hosted virtual desktops, introducing latency and complexity.

• Integration Deficiencies: The system suffers from poor integration with other critical

METRO systems. Its interface with the HASTUS scheduling system is problematic, hindering efficient schedule imports/exports and use of advanced scheduling modules.

Integration with Swiftly is limited by Avail’s slow (typically 15-30 seconds, sometimes longer) data refresh rate, preventing METRO from fully leveraging Swiftly’s near-real-time capabilities. It lacks direct integration with the primary payroll system (Fleet-Net, despite common ownership), and the Human Resources Information System (HRIS)

NeoGov. Pre-trip inspection failures do not automatically generate work orders in the maintenance system. Yard management functionalities are essentially unusable due to the lack of automated vehicle location within the yard, preventing automated run assignments. Detour functionality is basic and does not effectively communicate changes to drivers or passengers. Exporting reliable data to other systems remains a challenge.

• Hardware Obsolescence and Reliability: The presence of multiple hardware generations, including two obsolete versions with no parts availability, poses a significant operational risk and maintenance burden. Touchscreen durability is a known issue. Frequent failures of the J1708 interface card require time consuming swaps and repairs handled by Avail.

• Workflow Inefficiencies: Many core operational processes remain highly manual due to system limitations. Operator sign-on requires manual entry of operator and run numbers. Dispatchers manually track exceptions and build the extra board using paper and Excel. The operator bidding process is entirely paper based. Pre-trip inspections are cumbersome, lack defect prioritization, and reporting is inadequate. Vehicle assignments are largely manual due to the lack of effective yard management.

• Vendor Support: METRO staff expressed some historical frustration with Avail’s support responsiveness and effectiveness. Some examples include: Support tickets are reportedly downgraded or closed without adequate resolution; fixes are often presented as workarounds rather than permanent solutions; communication regarding system administration has been challenging; and adding new system users requires submitting a ticket to Avail.

• Functionality Gaps: The system lacks robust integrated warranty tracking for onboard components. CAD/AVLs role here should be to provide GPS/odometer readings or event

Current State Memorandum 7 counts (like door open events) to an asset management system. The system’s current ability to accurately track lost service time due to operational issues (breakdown, sick driver, etc) is limited. This information should be pushed from CAD automatically to a payroll system. Automated calculation and tracking of complex time-off accruals and payouts based on union rules are not supported by the current system. These rules, while managed in a payroll system, need to be integrated with the CAD/AVL in a bi-directional manner to prevent any union rule violation and maintain correct records in cases of overtime or shift changes, etc.

In summary, while the Avail CAD/AVL system performs basic vehicle tracking and dispatch functions, it is hampered by significant data integrity issues, poor performance, critical integration gaps, hardware obsolescence, reliance on inefficient manual workflows, and vendor support challenges. These issues collectively impact operational efficiency, reporting accuracy, and the overall user experience for staff across multiple departments.

Finance System, Time Tracking, Payroll & Benefits Processes; and

Human Resource Information System (HRIS)

METRO’s current ERP-related functions are distributed across multiple systems, leading to inefficiencies and data silos. Each section details the system and processes related to the functions.

Finance System, Time Tracking, Payroll & Benefits Processes

Vendor(s): Avail Technologies, Inc. (Fleet-Net); TimeTrak Systems Inc.

Core Functions: The Avail Fleet-Net finance and payment system features include payroll calculation, check printing processing, purchasing support, accounts payable/receivable, general ledger, and general employee HR data maintenance, primarily for payroll. However, Excel workbooks often serve as the primary format of record and then data is manually entered into Fleet-Net. This occurs as the team trust their Excel file, there is a lack of integration with their financial institutions and credit cards and generally, their data is entered manually.

Avail Technologies acquired Fleet-Net in October 2017, aiming to expand its offering to a total enterprise solution for the transit industry. The integration with Avail was supposed to create a central, unified system, designed to support the entirety of a transit agency’s operations.

METRO uses Fleet-Net to:

1) Issue paychecks and pay stubs

2) Manage vendor payments

3) Be the system of record for financial audits

4) Manage and track parts inventory (including fuel)

Current State Memorandum 8

5) Generate work orders and track labor

6) Process payroll based on employee attendance.

However, the functions above are often accomplished via multiple manual and semi-automated methods depending on employee classification.

System Components:

• Central Software: The central software provides team members with a place to generate purchase requisitions (PRs), purchase orders (POs), maintain the general ledger and input data like accounts receivable, accounts payable, deposits, the operating budget and generate reports. However, the central software is built upon an unsupported platform (i.e., Microsoft Access) and the functionality of the software is challenging and not fully used as it is not trusted.

• Accounting and Reporting: All METRO accounting functions (e.g., accounts receivable, accounts payable) are essentially performed in Excel workbooks with multiple spreadsheet tabs. The information is then transferred to Fleet-Net where the general ledger is maintained and reports can be generated.

• Reports (e.g., financial statements) from Fleet-Net often take a prolonged time to generate. It also posts transactions by entry date instead of invoice date. Additionally, there is no link to credit cards or bank accounts for deposits and expenditures, so these transactions are not automatically posted to the finance system. The finance team also has expressed concern that the same information generated by different report names from Fleet-Net is inconsistent between reports. Specifically, if a report is run one way under a specific report name, the numbers may be different than those that claim to present the same information in a different report name. Avail support has been unable to identify why different standard reports generate different information but have told

METRO which report they should use.

o Additionally, custom reports are not available, and summary reports for the METRO

Board are manually generated by the Chief Financial Officer (CFO) and her team.

• Purchase Requisition (PRs): The PR process is heavily reliant on manual processes.

Fleet-Net generates all purchase requisitions which are then printed and routed through the approval chain by passing a folder to each approver or by using TrackIt. TrackIt, a software used for other purposes in the organization, is being used as routing software for PRs. However, TrackIt does not integrate with any system including travel approval of the PR or any financials (e.g., spending) for the system. Ultimately, any purchase over

$1,000 requires Chief Executive Officer (CEO) approval. The approval chains are summarized below.

o Current Approval Chains

Current State Memorandum 9

• Under $1,000: Requester -> Department Head -> Chief Accountant (for account numbers) -> Procurement Officer (for entry into Fleet-Net).

• Over $1,000: Requester -> Department Head -> Chief Accountant (for account numbers)

-> CEO -> Procurement Officer (for entry into Fleet-Net).

▪ Again, the approval form is paper, or a PDF (TrackIt only) and Procurement

Officer manually enters it into Fleet-Net, which then converts it to a purchase.

o The PR approval process typically takes a "few days at the most," unless the PR gets lost. Approvers are pretty good at moving PRs through the process. However, as there is no system reminding people to approve their PRs, manual follow-up (e.g., an email, call or text) is required of the requester if they haven't seen their PR processed in Fleet-Net. Clearly, just as there is no visibility to approvers as to what

PRs need their approval, there's no automated tracking visibility for the requester.

• For audit and tracking purposes Chief Accountant maintains a spreadsheet listing every

PR and its status (e.g., sent to Procurement Officer, CEO, or Accounts Payable for check requests). Finally, everything is downloaded into a folder by Chief Accountant so others can look it up if needed, creating transparency but not necessarily widespread accessibility to the data.

o As a note, the checks and electronic payments (e.g., ACH transactions) are made by

METRO. It was shared that only one batch of electronic payments can be made per day and if the payments aren’t fully transacted, the file containing one person’s data for these payments can be overwritten by another person.

• Emergency Purchases and Deviations from Process: Sometimes, purchases are made before a PR is processed (e.g., "someone goes out and purchases an item for an urgent need”).

• Annual Budget Entry: Annually, a budget must be entered for all budget line items. This process is done “line by line” through manual entry as no reliable way of uploading the budget has been found even while working with Avail support. Additionally, METRO has shared that Fleet-Net can only manage one budget. This translates to the fact that

METRO enters its operating budget in Fleet-Net but does not enter or track its capital budget in Fleet-Net except as necessary line items to maintain the general ledger.

METRO also shared that budget line items can be “overrun” as there is no control to stop a PO or purchase from being entered that is over the budget line-item amount.

• Time Tracking: TimeTrak Systems Inc. is a U.S.-based company offering an integrated hardware and software time tracking solution, with physical time clock devices and comprehensive labor management tools. TimeTrak is a complementary system which

METRO intended to integrate with Fleet-Net. The maintenance team, customer care, and contracted police officers all clock in at a TimeTrak time clock or computer terminal for their time recording. Time from TimeTrak is exported into a Comma-Separated

Current State Memorandum 10

Values (CSV) file and uploaded into Fleet-Net. Operators interact with the system via an in-vehicle MDT. They clock into the MDT for their pre-trip inspection and clock out at the finish of their run. Operators are paid based on the scheduled time for that route and any deviations from the planned work schedule are changed manually. In addition to the above systems and processes, paper timesheets are used for the administrative staff.

• Paid Time Off (PTO): Generally, the METRO team relies heavily on manual processes including Excel spreadsheets and paper folders or ledgers. All tracking of PTO which is described as vacation, personal and sick time are tracked in Excel and a handwritten ledger by a single employee (the Dispatch Supervisor). These are the trusted records and audit materials for METRO.

o While METRO does a great job of maintaining records, this manual process does not allow METRO employees a self-serve option where they can login to a system and view their paystubs including their PTO accruals. Please note, not all employees accrue all types of PTO. For example, operators do not accrue sick time.

• Tracking Family Medical Leave Act (FMLA): Dispatch logs an operator’s attendance when they show up for their shift in Avail for tracking. If an operator uses FMLA, this is noted and the attendance record is manually entered into the JJ Keller System where an email goes to another METRO employee for tracking (Ernie). This is also tracked in

"SickLine Maintenance" in Fleet-Net.

• Payroll System: The payroll system process is highly manual and involves many people to collect, verify, check and enter the data into Fleet-Net so payroll can be generated.

Payroll is a compilation of TimeTrak, Excel workbooks, and manual entry into Fleet-Net.

Key Issues and Challenges: Fleet-Net, the Finance and paycheck system presents significant challenges across multiple functional areas:

• Data Integrity and Reporting: This is an area of concern. Staff report pervasive issues with unreliable data being generated from reports that claim to present the same data.

Specifically, data generated from a report under one report name doesn’t always generate the same data as another equivalent report. Avail has shared which report is correct but has not offered a reason as to why the data varies. Additionally, all data is entered manually. Due to all the manual entries, there are opportunities for errors, and the METRO team only trusts their Excel workbooks as the source of truth.

• System Performance and User Interface: Similar to the CAD/AVL, the user experience, particularly after the cloud migration, is frequently cited as poor. Staff describe the interface as clunky, slow, and prone to freezing. Routine tasks often require an excessive number of clicks to get to the correct menu. Team members cite the lack of useability and have limited confidence in Fleet-Net. Again, the Finance team members use an

Current State Memorandum 11

Excel workbook for accounting and only enter the data into Fleet-Net to maintain the general ledger.

• Integration Deficiencies:

o There are significant integration deficiencies. Fleet-Net is not integrated with

TimeTrak where maintenance team and customer care members’ time is stored, requiring a manual export of a CSV file to Fleet-Net to perform the hours by pay rate calculations that are manually verified by each department and then sent to Robin for entry in Fleet-Net for payment. A similar manual process is required for administrative staff where paper timesheets are entered into Fleet-Net and then processed for payment.

o Fleet-Net does not integrate with bank or credit cards systems so that transactions can be automated and verified as opposed to manually entered into the system.

Additionally, there is no integration with NeoGov or other supplementary systems like JJ Keller, EASE, and Embark. EASE and Embark are benefit systems from third-party providers like insurance companies for healthcare.

• Hardware Obsolescence and Reliability: Fleet-Net has no integrated hardware.

TimeTrak for time tracking is a separate system and the upload is from a manually exported CSV file.

• Workflow Inefficiencies:

o Many core operational processes remain highly manual due to system limitations.

The payroll process is highly manual and involves multiple people performing and verifying time, pay rates, time off including FMLA, garnishments, and benefits.

Additionally, the Annual Budget must be entered line by line as there is no reliable mass upload solution. Finally, only the Operations budget is entered into Fleet-Net while the Capital Budget is tracked in an Excel workbook ultimately requiring manual tracking and entry into Fleet-Net.

o The PR approval process is entirely manual due to system limitations. There are no automated notifications that someone has a PR to approve and all routing is manual or through TrackIt which is only slightly better than the manual process as it generates notifications to the next person in the approval chain that a PR is ready for their approval. The PR is still sourced from Fleet-Net as a PDF and then routed through TrackIt. Ultimately, a PO is generated after the PR receives its final signature and the Procurement Officer enters the PR into Fleet-Net with details. It is approved by the designated approver and then it becomes a PO.

• Vendor Support: METRO staff expressed frustration with Avail’s Fleet-Net support responsiveness and effectiveness. Support tickets are reportedly downgraded or closed without adequate resolution. Fixes are often presented as workarounds rather than permanent solutions. Communication regarding system administration has been

Current State Memorandum 12 challenging. Instead of a self-service model, adding new system requires submitting a ticket to Avail.

• Functionality Gaps:

o The PR/PO generation system lacks any integration with the accounting functions of the Fleet-Net system. Specifically, the PR approvals are not tracked in the system and must be manually noted in the accounting portion of the system. PR approvals can be tracked but are not currently due to a workaround that was deployed.

Payments from POs are and can be tracked.

o Generally, entering mass amounts of data (e.g., the Annual Budget) is manual and a reliable upload feature is unavailable.

o Time worked for OT is displayed in a confusing manner. Specifically, if someone worked 80 hours of straight time in a two-week period and 8 hours of OT to be paid at time and a half, it’s displayed as 88 hours of regular time and 8 hours of half time paid instead of 80 hours at the base rate and 8 hours at the OT rate. This could be confusing for auditors including those from pension and benefits systems.

o Electronic payments can only be entered by one person and run once per day.

Problematically, if another person creates an electronic payment (e.g., ACH) set for processing and someone else also creates an electronic payment set for payment before the first person processes that payment, then the first set of payments are overwritten and not paid.

o Grants are not able to be tracked in Fleet-Net. The software does not include a grant administration module that would allow the grant amount, matching funds, specific eligible expenses, to be assigned to the grant. Additionally, no reports can be run for the grant to show compliance and expenditure process.

Current State Memorandum 13

Figure 1: Current Timekeeping & Payroll Process

Current State Memorandum 14

HRIS

Vendor: NeoGov

NeoGov: NeoGov is used for Human Resources (HR) functions, it is the HRIS for METRO.

NeoGov is used for HR-related tasks, such as:

• Recruitment and Onboarding

• HR Data Management

• Performance Management

• Training

Initially, this system was intended to include payroll, but METRO opted out because it could not be configured to meet their needs. Specifically, the calculations of payroll for the various schedules, union rules and non-union employee schedules proved to be beyond the capability of NeoGov. Fleet-Net does maintain some human resources (HR) data and reporting. A combination of TimeTrak and Fleet-Net is used to process payroll.

Key Issues and Challenges: The NeoGov HRIS is a system that METRO finds acceptable. The features that it uses are somewhat user-friendly. Although this system isn’t slated for replacement, documentation of the uses and gaps in the system are included in this document in the event that a new payroll system (e.g., an ERP) also includes these features. Ultimately, the HR functions are not managed in one system and the supplementary systems (e.g., JJ Keller, TimeTrak, EASE, and Embark) are not integrated.

• Data Integrity and Reporting: This is an area of concern. The data from the supplementary systems are often entered multiple times into this system for reporting.

While the METRO team members take great care when entering the data, this does present opportunities for mistakes compromising data reporting.

• System Performance and User Interface: A reoccurring theme is that NeoGov is not intuitive. An example of this is that the system will let users proceed through processes, and errors are only caught at the final step (e.g., "you can't hire that person"), forcing users to backtrack and figure out what went wrong. Ideally, errors should be flagged throughout each form completion or step.

• METRO’s Employee Engagement Center (ECC) team reports that they often spend cumulative hours tracking down potential employees to correct forms like the I-9 because E-Verify will not work if the potential employee puts a period after their middle initial. There is not rejection of this in the system and METRO only discovers this after they “can’t hire the employee.”

o Applicants are manually moved through several "portals" or stages within NeoGov.

▪ Insight: Where initial applications reside.

Current State Memorandum 15

▪ Offer Hire & Compliance (OHC): Applicant moved here for the offer letter stage after a verbal offer and a 3-step internal approval process (EEC, Finance, CEO).

▪ Pre-Board/Onboard: After signing the offer letter, they are moved here for pre-boarding forms.

▪ HR: Assumed final stage once fully hired.

o This multi-stage process within NeoGov is manual and not seamless.

• Integration Deficiencies: The system suffers from poor integration with other critical

METRO systems. Specifically, there is no integration with JJ Keller’s FMLA tracking system, EASE, the benefits management system, or Summacare, the drug and alcohol randomization company. Additionally, there still must be a manual notification to the employee and the drug and alcohol testing company.

• Workflow Inefficiencies: Workflow inefficiencies are created due to the poor integrations with other systems as well as the lack of error notifications when potential employees are completing their information in the system. See System Performance and

User Interface for detail.

• Vendor Support: METRO team members shared that NeoGov sometimes adds new required fields or changes features without adequate prior notification leaving users to discover these changes mid-process. METRO did share that NeoGov shares "Snippets" about system enhancements pop up but often at inconvenient times when users are busy; these notifications are not easily retrievable later.

• Functionality Gaps: The biggest functionality gap in the system lacks the ability to calculate payroll based on the schedules and union rules. Again, the payroll process is extremely manual and its final step is generating payroll. Additionally, the system lacks the error notifications to the user when they (e.g., a potential bus operator) are inputting their information into the system. See the issue above with entry of a period after a middle initial. A final frustration is that the job descriptions must be completed in sections and they must individually “copy and paste” each section into a new file if they want to post it to a job board like Indeed. These functionality gaps lead to a team that likes some features of the system like training; and is frustrated by the lack of functionality with payroll and error notifications when they or potential employees are filling out forms.

Current State Memorandum 16

Procurement

METRO leverages OpenGov for managing its formal procurements that must be advertised, particularly those exceeding the $50,000 threshold. OpenGov Procurement is a cloud-based eProcurement platform designed to help governments streamline their procurement and contracting processes. It's part of the larger OpenGov suite, which provides tools for budgeting, financial transparency, performance management, and citizen engagement, specifically tailored for public sector organizations.

Vendor: OpenGov

Core Functions: OpenGov is METRO's dedicated platform for managing the formal procurement process, specifically when procurement exceeds the $50k threshold (e.g., RFPs, IFBs for capital projects, professional services). It handles solicitation development, publishing, vendor registration and communication, proposal/bid submission, evaluation workflows, and potential aspects of contract management. The Finance and Procurement teams are the primary users.

METRO staff have expressed general satisfaction with OpenGov for these intended formal solicitation purposes. The system also offers features like dashboards and analytics for procurement activities, and its database allows METRO to research similar projects and solicitations from other public agencies using the platform.

Integration: OpenGov appears to operate largely as a standalone system focused on the solicitation and award phase. It is not currently used for generating day-to-day POs or requisitions for items like parts or office supplies, which are handled within Fleet-Net and paper-based processes. While contracts might be managed or stored within OpenGov after award, the subsequent purchasing and payment processes occur outside of it (primarily in

Fleet-Net). There is no direct integration between OpenGov and Fleet-Net for PRs or for tracking against the General Ledger for budget availability.

Key Issues & Challenges:

• User Satisfaction: Staff (primarily Finance/Procurement) expressed general satisfaction with OpenGov for its intended purpose of managing formal solicitations.

• Scope Limitation: Its primary limitation in the context of METRO's overall operations is that it doesn't encompass the routine purchasing/requisition process handled via Fleet-

Net and paper, nor the subsequent accounts payable process. This creates a disconnect between the initial sourcing/award and the ongoing purchasing/payment cycle for many goods and services.

Current State Memorandum 17

Asset Management & Maintenance System

METRO's asset management and maintenance activities, particularly for its vehicle fleet, are primarily managed through the Avail Fleet-Net system. This system handles work order generation, parts inventory, preventive maintenance (PM) scheduling, and some aspects of asset tracking. It is supplemented by FLEETWATCH for fuel and mileage data acquisition and various manual or paper-based processes for specific tasks like tire tracking and parts receiving confirmation. Facility maintenance currently utilizes Fleet-Net in a very limited capacity.

Vendor(s): Avail Technologies, Inc. (Fleet-Net); FLEETWATCH; Goodyear (Tire Leasing/Tracking);

potentially Esri ArcGIS (for bus stops).

Core Functions:

• Fleet Asset Management (Fleet-Net): This is the most robustly used module. It maintains a master record for vehicles, allowing for tracking of basic asset information, PM schedules, work order history, and status. Inspections are generally assigned based on fleet type/model but tracked against individual bus numbers.

• Work Order Management (Fleet-Net): Mechanics and foremen use Fleet-Net to create, edit, assign parts to, track labor against, and finalize work orders for vehicle maintenance. While functional, the interface is described as archaic (Microsoft Access-based). It supports tracking associated parts inventory and labor time. Work orders are typically printed and handed to technicians, who mark them up physically. Road calls from dispatch generate a printed form that is then manually entered as a work order in

Fleet-Net by maintenance staff.

• Inventory Management (Fleet-Net): The system manages the parts inventory, including tracking on-hand quantities, defining static bin locations, and generating reorder points based on Min/Max logic (though the underlying algorithm for Min/Max calculation is reportedly not transparent and often manually overridden by experienced staff). Parts are charged out against specific work orders. Barcode labels are printed upon receiving, and handheld scanners (Motorola Symbol) are used, primarily by night shift mechanics, for inventory lookups or charge-outs, although staff report limitations with scanner range and barcode reading capabilities. Day shift staff often find direct data entry faster.

Cross-referencing parts from different vendors for the same component is a challenge, often leading to duplicate entries for the same effective part.

• Preventive Maintenance (Fleet-Net): PM schedules are primarily driven by mileage.

After the daily fuel/mileage data is imported from FLEETWATCH, foremen can run an inspection forecast report, which identifies vehicles due for PMs based on accumulated mileage against their schedule. Work orders are then generated from this forecast. The system can trigger inspections based on mileage or time (e.g., HVAC inspections).

Current State Memorandum 18

• Fuel & Fluids Management (FLEETWATCH & Fleet-Net): FLEETWATCH terminals automatically capture fuel dispensed and vehicle mileage during the daily servicing process. However, this data is not automatically integrated into Fleet-Net. A daily manual process occurs around 10:00 AM where a designated staff member must:

o Copy a TXT file generated by FLEETWATCH from a METRO network drive to Avail's

OneDrive environment.

o Open the TXT file (in Notepad) within the Avail remote desktop environment.

o Manually scan the file for errors (indicated by asterisks) and delete or correct the erroneous lines. This is iterative – fixing one error may reveal another upon the next import attempt. This process can take 30 minutes on a good day, longer if multiple errors or manual entries for electric buses are needed.

o Import the cleaned TXT file into Fleet-Net to update mileage and fluid consumption.

o Manually enter mileage data for electric buses, as FLEETWATCH currently fails to communicate correctly with their CAN network (data is pulled from the Vericity telematics portal).

o Generate and save several daily audit reports as PDFs to METRO's network, as Fleet-

Net does not retain historical daily transaction details (preventing reproduction of these specific reports later).

This process is manual, time-consuming, error-prone, and creates significant delays in updating inventory levels and PM triggers. Furthermore, discrepancies between fuel/fluid deliveries (especially variable amounts) and authorized PO quantities in Fleet-

Net require manual inventory adjustments or complex PO management workarounds.

Compressed natural gas (CNG), which is compressed onsite and not "received" conventionally, requires regular manual additions to Fleet-Net inventory to allow consumption tracking.

• Facility Asset Management (Fleet-Net - Limited Use): While Fleet-Net has modules for facility asset management (asset trees, inspections), METRO uses these very sparingly.

Some annual inspections (e.g., garage doors) are set up, but parts are rarely charged, and facility parts are not generally inventoried within the system. There is a desire to utilize this more comprehensively, especially with the new facility construction.

• Tire Management (Paper/Goodyear): As tires are leased from Goodyear, METRO does not track individual tire serial numbers or inventory within Fleet-Net. A paper "tire card" is filled out by mechanics when tires are changed, copied by administrative staff, and collected by Goodyear for their separate tracking system.

• Bus Stop Management (GIS/Manual): Bus stop assets (signs, benches, shelters) are managed separately, likely within Planning using ArcGIS. There is no integration enabling work orders for bus stop maintenance or moves within Fleet-Net, nor does

Current State Memorandum 19 moving a stop in GIS automatically update the CAD/AVL system stop location; this requires separate manual updates.

• Warranty Tracking (Fleet-Net - Limited Use): The system has basic warranty flags but lacks robust functionality for tracking warranty periods against parts or triggering alerts for using warrantied parts first. This results in underutilization, and METRO potentially misses opportunities for significant cost recovery (estimated tens of thousands annually) by not consistently creating warranty work orders or claiming reimbursements for in-house warranty repairs. This is identified as a key area for improvement.

Key Issues & Challenges:

• Manual Data Integration: The daily manual export/import process for FLEETWATCH fuel/mileage data is a major inefficiency and point of failure. Manual data entry is required for electric bus mileage.

• Paper Dependencies: Reliance on paper for tire tracking and, critically, for the parts receiving confirmation needed by Accounts Payable, creates risk and inefficiency. The

"one-shot" printing of paper receivers is fragile. Printed work orders are physically handled and marked up by technicians.

• Lack of Automation: Pre-trip failures or diagnostic codes from the Avail CAD/AVL system do not automatically generate work orders in Fleet-Net. Moving a bus stop requires multiple manual updates across different systems. Warranty tracking is largely manual.

Inventory adjustments for fuel/CNG are manual workarounds.

• System Silos: Maintenance activities (Fleet-Net) are disconnected from real-time vehicle diagnostics (Avail), bus stop asset management (GIS), tire management (Goodyear), and potentially broader procurement (OpenGov).

• Inefficient Workflows: The iterative error-checking process for fuel data import is time-consuming. Managing POs for consumables requires cumbersome workarounds. Lack of digital approvals for POs necessitates physical paper routing. Foremen rely on manually maintained Excel spreadsheets for tracking vehicles in the shop, parts on hold, vehicle cleaning status, and daily shop/pending work handoffs between shifts.

• Limited Functionality/Transparency: Warranty tracking is insufficient. The logic behind

Min/Max reordering is unclear and often manually adjusted based on staff experience rather than system-driven data. Historical daily transaction data for fuel and fluids is not retained electronically within the system. The archaic UI hinders ease of use. Scanner limitations impact efficiency.

• Underutilized Capabilities: Facility asset and maintenance management capabilities within Fleet-Net are largely unused.

Current State Memorandum 20

In summary, while the core work order and parts inventory functions of Fleet-Net are considered functional and reliable by the staff who use them daily, the overall asset management and maintenance process is significantly hampered by a lack of integration, heavy reliance on manual data transfer and paper processes, and specific functional limitations within the software. Modernizing this area requires addressing the critical integration gaps (especially fuel/mileage and diagnostics), digitizing paper workflows (receiving, POs), and potentially implementing a more robust system with better warranty tracking and facility management capabilities.

Current State Memorandum 21

Figure 2: Current Fueling Process

Current State Memorandum 22

Figure 3: Current Asset Management System

Current State Memorandum 23

Route Planning/Scheduling (HASTUS)

Vendor: GIRO, Inc.

Core Functions: HASTUS is METRO's dedicated software system for fixed-route service planning and scheduling. It is utilized by the Planning and Strategic Development department to perform essential functions including network design, route creation and modification, run-cutting

(determining efficient operator assignments), crew and vehicle scheduling, and generating the foundational schedule data that other systems rely upon. METRO uses core HASTUS modules including Vehicle, Crew, Geo, and Roster. While the Rider module is available, its functionality for producing operator paddles/documents is reportedly underutilized due to limitations in exporting the necessary data cleanly to the Avail CAD/AVL system.

Integration: HASTUS provides the primary schedule data (routes, trips, run assignments, stop times) that needs to be imported into the Avail CAD/AVL system for operational use and for generating the GTFS static feed for passenger information.

Key Issues and Challenges:

• Poor Avail Integration: The most significant challenge cited is the problematic integration with the Avail CAD/AVL system. Exporting schedule data from HASTUS and importing it into Avail is reportedly difficult and prone to errors.