RFP FINAL for Dispatch Software.docx

The City of Stevens Point/Stevens Point Transit

Request for Proposals (RFP)

Dispatch/Scheduling Software

RFP # 2017-3

Proposal due Date and Time:

Wednesday, May 24, 2017 by 3:00pm (central time)

STEVENS POINT/PORTAGE COUNTY

“ONE CALL”

TRANSPORTATION CENTER

PROJECT OVERVIEW

The City of Stevens Point is seeking proposals from qualified vendors for the provision, installation and support of a software system having the capability to streamline dispatch and scheduling and provide management for its City/County Transportation services. The consolidated transportation system includes the City fixed route and in-house paratransit operations as well as the Portage County Aging and Disability Resource Center transportation services.

The Proposer’s attention is called to the “Notice of Requirement for Affirmative Action to insure Equal Employment Opportunity”, contained in the bid documents, which set forth, in part, goals and timetables for the employment of women and minorities in the project area. In addition, it is the policy for this project that minority business enterprises shall have the maximum opportunity to participate in the performance of contracts financed in whole or in part with federal funds under this agreement. In addition, DBEs, including MBEs and WBEs are encouraged to submit bid proposals.

Attention of Proposer is also called to the fact that the successful Proposer must insure that employees and applicants for employment are not discriminated against because of their race, color, sex, religion or national origin. The attention of the Proposer is particularly called to the federal requirements for equal opportunity (Executive Order 11246, Segregated Facilities, Section 109, and Section 3) and the conditions of employment to be observed and minimum wage rates to be paid under the contract.

All proposals received shall be considered the property of the City of Stevens Point and shall remain valid for not less than ninety (90) days following the due date of the proposals.

The City of Stevens Point reserves the right to reject any proposals, cancel this solicitation, waive any informality associated with the proposal process, and award the bid deemed most advantageous to the City of Stevens Point.

Herein, the City of Stevens Point may be referred to as the “City”, Stevens Point Transit may be referred to as “SPT”, and Portage County may be referred to as the “County”.

INTRODUCTION

SPT is a public transit system operated by the City of Stevens Point. SPT provides fixed route and demand responsive paratransit services. In January of 2018 the City will begin to provide the Portage County Aging and Disability Resource Transportation services per agreement with Portage County. Funding for the consolidated program is provided through State and Federal funding, County and City tax levy, and subsidies from the Village of Whiting, Crossroad Commons in Plover, and the University of Wisconsin Stevens Point, in addition to fare and passenger revenues. The consolidated program is administered by Stevens Point Transit, the public transportation utility for the City of Stevens Point, WI.

PURPOSE

The purpose of this Request for Proposal is to solicit proposals for the design and installation of a fully integrated dispatch, trip scheduling and multi program management software system for the consolidated transportation program.

EXISTING ENVIRONMENT

SPT operates four (4) fixed routes Monday through Friday year round. When the University of Wisconsin Stevens Point is in full session four (4) additional fixed bus routes are added and a Campus Shopping Route and Paratransit service operate on Saturday. SPT operates an in-house paratransit service, known as Point Plus. Point Plus provides complementary paratransit service to individuals who are unable to use the fixed route bus service. Point Plus operates the same days and hours as fixed route bus, providing door to door service for clients with two (2) buses assigned during peak service hours. Stevens Point Transit employs eighteen (18) Bus Operators, one (1) full-time mechanic, one (1) part-time mechanic, three (3) Supervisors, a Travel Trainer, an Operations Supervisor, and a Transit Manager.

Beginning January 1, 2018, through an agreement with Portage County, SPT will begin providing the Portage County Aging and Disability Resource Center (ADRC) transportation services in addition to the City services to provide a “One Call” transportation center for Portage County. The County transportation services consist of Fixed Flexible Bus Routes which provide flexible bus service throughout the county using accessible vehicles for regular scheduled nutrition trips to dining sites, as well as regular scheduled grocery and commodities trips. Three (3) drivers are scheduled during peak hours of service, M-F. Taxi and Special Medical Vehicle (SMV) service is provided to County residents through contracts with two (2) local Taxi/SMV providers.

Volunteer Driver services are provided to the elderly and individuals with disabilities who can be transported in a non-accessible vehicle. Forty-eight (48) Volunteer Drivers are registered to provide rides for the volunteer programs. The service provides rides to medical appointments, nutrition dining sites, grocery shopping, employment, and essential business appointments when the individual is unable to use other transportation options.

Disabled Veteran rides are scheduled and coordinated through the County services. The DAV program provides two (2) accessible vans which are utilized for the Veteran medical transports to VA hospitals/clinics. This service will continue as part of the consolidated service.

The current County transportation service staff consists of, three (3) Bus Operators, a Supervisor, and a full-time Mobility Manager. Two (2) Dispatcher/Schedulers and one (1) full-time mechanic will be added to the consolidated service upon implementation of the program.

The Stevens Point Transit vehicle fleet consists of ten (10) 30’ low floor Gillig buses, and four (4) Supreme cutaway buses used for the paratransit services. All vehicles are accessible.

The Portage County vehicle fleet consists of three (3) cutaway buses, and one (1) Braun Entervan.

All vehicles are accessible.

The Director of Public Utilities and Transportation, the Stevens Point Transportation Commission and the Portage County Transportation Coordinating Committee will provide oversight for the consolidated program.

Stevens Point Transit currently does not have a dispatch/scheduling software program. The intent of the RFP is to provide a software program that offers a robust level of functionality to assist in efficient management of the consolidated transportation services.

The consolidated program will not operate on the following Holidays: New Year’s Day, Memorial Day, Independence Day, Labor Day, Thanksgiving and Christmas Day. There is no fixed route bus service, paratransit service, volunteer driver or County Bus service on Sunday. Contracted services provided by Taxi or Specialized Medical Vehicles may be prescheduled for Holidays or Sundays.

REASONABLE ACCOMMODATIONS

Stevens Point Transit will provide reasonable accommodations, including the provision of informational material in an alternative format, for qualified individuals with disabilities upon request. If you think you need accommodations, please contact the SPT Manager, Susan Lemke at 715-342-4823 or email slemke@stevenspoint.com

PRE-PROPOSAL CONFERENCE

A pre-proposal conference is scheduled for May 10, 2017 at the Stevens Point Transit Facility located at 2700 Week Street, Stevens Point, WI 54482. The conference will be held from 10:00am to noon.

PROPOSAL DUE DATE & SUBMISSION

All proposals should be submitted in one envelope, container or binder, which on its face bears the Proposer’s name. The proposal must be addressed to:

Stevens Point Transit Susan Lemke/Transit Manager 2700 Week Street Stevens Point, Wisconsin 54482

The following information must appear on the lower left-hand corner of the envelope, container, or binder.

Hand carried proposals may be delivered to the above address only between the hours of 8:00 a.m. to 4:00 p.m., Monday through Friday, excluding holidays observed by the City.

Proposers are responsible for informing any commercial delivery service, if used, of all delivery requirements and for ensuring that the required address information appears on the outer wrapper or envelope used by such service.

The submittal of a proposal will be considered by the City as constituting an offer by the Proposer to perform the required services at the stated prices.

Technical Proposal: All proposals must be submitted on 8 ½” x 11” paper, except for any drawings, charts, diagrams, or similar information. Proposers shall include their complete return address on the outer envelope/wrapper.

Price Proposal: One (1) original (no copies) of the price proposal must be submitted with the technical proposal, but the price proposal must be in a separate, sealed envelope. The price proposal envelope should be identified in the lower left-hand corner as such.

In order to be considered, sealed proposals in the format specified herein, are due at the address below no later than 3:00 PM Central Time on May 24, 2017 in the office of:

Stevens Point Transit Attention: Susan Lemke/Transit Manager 2700 Week Street Stevens Point WI, 54482

The proposer shall submit (5) hard copies of the proposal along with a digital copy; either disk or email.

PROJECT TIMELINE

QUESTIONS

All questions regarding this solicitation must be submitted in written form and will be answered as promptly as possible. Please submit your questions to the SPT Manager at:

slemke@stevenspoint.com or via telephone at (715) 342-4823

FEDERAL CERTIFICATIONS AND ASSURANCES

All Proposers must complete and submit the certifications and assurances in Appendix H with their proposal document. Failure to include these forms may result in your proposal being deemed ineligible.

CONTRACT PERIOD

The successful Proposer shall complete the various tasks identified herein within six (6) months after notification of Contract of Award. By mutual agreement between the two parties, the contract may be renewed up to thirty (30) days. The submitted bid price shall be valid from the date of submittal through the duration of the project.

BASIS OF PAYMENT

The Proposer will be compensated by the City of Stevens Point for deliverable/services, as specified in the contract, for work competed in a satisfactory manner.

PROPOSER’S LIST

All Proposers must fill out and attach the Proposer’s List form found in Appendix A with their proposal document. Failure to include this form may result in your proposal being deemed ineligible.

SCOPE OF WORK (SPECIFICATIONS)

Product Overview and Outlook

Proposals should describe the following proposed software components:

Customer Registration, Eligibility, and Usage Management Scheduling Dispatching Vehicle Management Driver Management Financial Management Contract Management Service Performance Evaluation Demand Response Program Ridership statistics by category Fixed Route Ridership statistics compiled by category Automatic Vehicle Location/MDT (maximum 8 vehicles) Automatic Vehicle Location only – 10 fixed route buses Volunteer Management Client management (approximately 3600 currently certified clients within combined programs)

The Proposer should also address how the product is expected to evolve over the next 3-5 years.

Users:

Seven (7) dispatch/scheduling workstations are to be established within the City/County consolidated “One Call” center. Two (2) designated Dispatch/Schedulers, four (4) Supervisors and the Operations Supervisor shall have the ability to work within the program from their designated work areas within the facility. It is anticipated that up to three (3) users may be using the system concurrently however the majority of the time only two (2) users.

Billing and Trip Verification

It is anticipated that the SPT consolidated transportation service will schedule approximately one hundred (100) demand response rides daily. Those rides will be either Paratransit, County Bus, County Volunteer Driver Program, Taxi/SMV, or DAV riders. The goal is to assign each passenger an assigned agency billing code, some passengers may have multiple billing codes. A billing interface within the program is necessary which would have the ability to:

· Designate the program used and cost of the ride

· Track account/client payments (cash fare or donation paid at time of ride, or charged)

· Generate monthly spreadsheets for invoiced accounts

· Monitor and create spreadsheets for past due accounts

· Track daily rides by category and create weekly, monthly, quarterly, semi-annual and annual reports/invoices

The City fixed route bus service provides approximately 1100 rides per day when campus is in session. The rides are categorized as Adult, Senior, Disabled, Youth, UWSP, Late Night Transit or Transfers. The program shall have the ability to gather fixed route ridership by category, fare paid, and method of payment (cash, monthly pass, E-Z pass, or transfer).

Proposers should demonstrate the software has the ability to bill individual riders and multiple agencies, at various fare rates by category.

Data Management

Data entry must be easy and efficient. All tables must be exportable in a commonly used format. Some of the current SPT customer and trip data may be entered into the system by SPT staff as part of the training and implementation process.

Basic Functionality:

The following capabilities should be described in detail and priced separately where applicable.

· Basic functionality, and how it will be impacted by SPT

· User-defined field lists, including field lists with possible user-defined additions

· Fields requiring customization for additions or changes to the default list (Provide the full default list for each field)

· Service parameter settings and how SPT and the different service requirements within the consolidated service can be accommodated in the settings

· Web-based software application and hosting provided by the proposer.

Security:

Proposals should describe the system’s security features to prevent unauthorized or accidental disclosure, alteration, or destruction of data, including the following features.

· Authenticate on-site and remote users and prevent unauthorized users from tampering with data

· Manage user group privileges and other access control features

· Monitor user access of data and maintain an audit trail

Ease of Use:

SPT will be evaluating proposals using a number of criteria including ease of use for its employees. To this end, Proposers are encouraged to discuss elements that simplify the use of their system including wizards, editing, and data integrity tools.

Data Integrity:

Data integrity means that the data values in the database are correct and consistent. Proposers should present the features of their system that prevent the input of invalid data and that minimize human errors when data is entered. Proposers should also detail the testing that will be performed to verify the correctness of every field in every record transferred to the new system.

Data Conversion and Verification:

The Proposer should present the process by which current data will be converted into the new system. SPT currently documents ridership data into an access program, the County uses the Route Coordinator program. The Proposer should also outline any participation in post- conversion data verification and clean-up efforts. Aspects of the conversion should include, but are not limited to the following.

· Audit data integrity (so fields that should contain numbers don't have text in them), and identify other data impurities within source data. Records that do not pass verification are flagged and prevented from entering the new system.

· Ensure that data has accurate Wisconsin codes and towns and the correct spelling of street names.

· Convert data to upper or lower case as required, including specifics like 'McDonald' or 'O'Reilly' and reformatting all upper case or all lower case entries.

· Abbreviation expansion, as needed.

· Removing duplicates.

Care and Maintenance of Data:

Proposals should describe the care and maintenance of the proposed system including the general requirements for updating data. Discuss in detail the type of staff people necessary for this maintenance.

Data Backup and Archives:

At a minimum, SPT would like to have seven (7) years of data regarding the service, on hand for easy reporting and querying. Proposers should present a plan for the archiving of data, the management of the archive, and the required/recommended hardware for data storage. It would be acceptable to present a plan with the most current three (3) years data provided in a production or active database and the remaining four (4) years in an archive database.

Dispatching

Describe in detail the proposed dispatching tools, including those listed below. If any of these are not part of the dispatching function, describe where and how they are handled.

Communication between dispatching and reservation/scheduling functions Dispatching effectiveness and performance evaluation reports Graphic display of individual routes with easily identifiable pick-ups, drop-offs, and breaks Ability to identify and assign open returns (will call trips) Ability to identify and adjust service for no-shows, cancellations, will calls and service interruptions Ability to identify scheduled and actual arrival times Monitor service in real time and alert the user for late trips (in MDT/AVL installation) Ability to monitor real time AVL for fixed route bus service and provide alerts when running ahead of schedule at checkpoints.

Documentation

Database design documentation should be provided that completely describes both the logical and physical structure of the system database. The documentation should define and describe the individual elements (files, tables and fields) and the relationships between them. Portions of the database developed or modified specifically for SPT’s consolidated system should be identified. Note that this requirement is for a complete and thorough description of the physical and logical database schematic. This will permit SPT staff to develop and maintain interfaces between the system database and other applications subsequent to project completion, and will facilitate the development of custom reports. Complete administrator documentation for the database management system(s) shall also be supplied.

The Proposer will provide SPT with seven (7) complete hardcopy sets and one electronic set of all documentation to support and operate the system. Electronic media must be compatible with Microsoft Office, which includes Word, Excel, and/or Adobe Acrobat PDF format.

In addition to the documentation specifically identified below, the Proposer should provide SPT with all documentation originally supplied with standard commercial equipment and software purchased from others.

Data Ownership:

All data in the databases that is supplied by SPT or generated from SPT operations shall be solely owned by SPT. The Contractor shall have no ownership rights to this SPT-supplied or SPT operations-generated data. There shall be no restrictions on SPT's rights or ability to access and use its data.

System Documents:

The Proposer should provide a system document index identifying all documents to be provided with the system. This includes all documents supplied with OEM hardware/software and the Proposer's own documents. The index should describe each document and the document's purpose, to help the user locate the appropriate document in the set of all system documentation.

Hardware Documents (if applicable):

Documentation for all supplied hardware should be provided to SPT. The Proposer should develop and maintain two hardware inventory lists:

· An inventory of all hardware, including the manufacturer, product, model number/version, serial number, name plate data, SPT identification tag number, quantity, purpose, and installed location.

· An inventory of all hardware documents, including product, version, document title, and the SPT document number.

· These should be maintained by the Proposer through final acceptance of the system and copies provided upon request of the SPT Executive Director.

· OEM-provided installation, reference, and/or maintenance manuals should be provided for all hardware. These should include descriptions, specifications, installation information, theory of operation, drawings, back panel and assembly wiring diagrams, and other electrical, electronic, and mechanical hardware data. The Proposer should include an attachment to each document outlining those portions of the document, if any, that do not apply to the SPT hardware.

· Instructions should be provided for preventive maintenance procedures. The manuals should provide guidelines for isolating the causes of hardware malfunctions and for localizing faults.

Software Documents:

Documentation for all supplied software should be provided to SPT. The Proposer should develop and maintain two software inventory lists:

An inventory of all software, including manufacturer, product, version, purpose, and installed location, and An inventory of all software documents, including product, version, document title, and the SPT document number.

These should be maintained by the Proposer through final acceptance of the system and copies provided to SPT’s Transit Manager.

Installation, user, and reference documentation for standard Proposer and third party software should be provided for SPT’s review and approval. Standard software is defined as that which fully satisfies the requirements of this RFP without the need for modification. Typical examples include operating systems, database management systems, and software diagnostic programs.

In addition, SPT requires maintenance documentation necessary to sustain the software in the future. Information included in documentation must include, but not be limited to:

· Overview/description

· Installation guides

· Maintenance documentation

· Troubleshooting guides

· Diagnostic procedures

· Inspection procedures

· Detailed warranty/support coverage

User Documents:

User documents are those that describe the system hardware and software from an end-user's point of view. SPT will be provided with seven (7) printed copies of user documentation, ideally both a User's Guide (tutorial format) and a Reference Guide.

User Manual documentation should be provided that contains detailed operating instructions to be used by SPT personnel. Information in the documentation should be presented in meaningful terms to non-technical personnel. The documentation should include a description of the operation of the system as it relates to the user’s tasks.

The User Manual should describe each function and how it is to be used. The documentation will not be written as a programmer's document. Procedures should be explained step-by-step with an explanation of how each step is performed, which parameters can be adjusted, and the effects obtained by varying each parameter. All guidance and error messages should be described, along with the steps necessary to recover from errors.

Each system function and all other functions designed for SPT use should be included in this documentation. The documentation should also include a copy of each type of display used in the system along with a description of each data field. The Proposer should supply SPT with one electronic copy of user handbooks per workstation.

Document Review and Approval Rights:

The Proposer should submit all documentation to SPT for review and approval during the implementation process.

SPT will respond with written comments to the Proposer within ten (10) working days after receipt of the documents. The Proposer must resubmit to SPT for approval documents requiring correction as soon as possible. SPT will review the resubmitted documents and record its approval or submit additional comments to the Proposer within ten (10) working days after receipt of the document. No implementation schedule relief is to be implied for documents requiring further correction and resubmission to SPT.

To help SPT manage the review and turnaround of documents during any given period, the Proposer should stagger the release of documents over the time allocated in the project schedule for document review. The number and size of documents should be factored into the release schedule.

Any purchasing, manufacturing, or programming implementation initiated prior to written SPT approval of the relevant documents or drawings should be performed at the Proposer's risk.

Review and approval by SPT should not relieve the Proposer of its overall responsibilities to satisfy system functions and features in accordance with the specification.

Custom Document Review:

The Proposer's own and some third party hardware and software may need to be customized to fully conform to the requirements of this specification. SPT should have, in addition to the limited approval rights described above, full approval over the portions of the relevant document's content and format pertaining to the modified or custom hardware, software. The following conditions must be satisfied for this approval:

Changes and modifications must be documented in a complete and clear manner in accordance with the Proposer's established documentation standards, and Features, equipment, and options pertaining to SPT must be clearly distinguished from those that do not pertain.

SPT should retain full approval rights over the work plan, test documentation, and other documents produced under this effort.

To the extent that the user interface will be customized or tailored, SPT should have full approval rights over the format and content of the user interface.

Eligibility Management:

The Proposer should discuss the system’s features for tracking customer eligibility for funding agency programs without duplicate data entry. The Proposer should discuss the system’s features that facilitate compliance with all functions required by SPT’s Regulations Regarding Eligibility for ADA Paratransit Services and County services.

County transportation service mandates individuals are:

· Residents of Portage County

· Elderly or disabled

Eligibility as defined by the ADA for the City Paratransit service are defined as:

· Persons who have a specific impairment-related condition that prevents them from getting to or from a fixed route stop.

· Persons who cannot use the fixed route system because the route(s) needed for a particular trip is/are not accessible.

· Persons who because of a disability are unable to independently board ride or disembark from an accessible fixed route vehicle.

Conditions:

Never able to use fixed route service Unable to use fixed route service under certain conditions, such as cold weather, Temporarily requires paratransit service.

The Proposer should discuss its system’s capability to manage ADA application requests, track received applications, application response, eligibility type, eligibility periods, social service program participation (Family Care, Medicaid, Medicare, IRIS, MTM etc.), current living environment (Assisted Living, Independent Living, Nursing Home etc.), emergency contact information, mobility aids, and other pertinent information. The following minimum features are required:

Tracking eligibility categories Conditional eligibility tracking and management. The Proposer should address how the system addresses these conditions in trip scheduling Advance notification of eligibility expiration, via either a report or a flag attached to the client’s file Fields for date the completed application was received, date it was processed, date of response, date of appeal, date of appeal hearing, and date of appeal determination Modifiable response form letter that is populated with approval or denial, reason for denial, approval category and conditions, and appeal process.

Equipment

The Proposer should describe and price all required hardware and other software. The Proposer should detail any changes to SPT’s existing computers and network that will be required.

Intelligent Transportation Systems:

SPT is considering making significant enhancements to services through the use of GPS/AVL and Mobile Data Terminals/Computers. Proposers should demonstrate their success in recent ITS integration with their software. Each ITS feature should be priced separately with a detailed description and equipment, license, and implementation budget. SPT may choose to accept a portion, all, or none of these ITS features at this time.

Mobile Data Terminals (MDTs):

The Proposer should describe the equipment and performance of mobile data terminals (MDTs) for as many as eight (8), agency vehicles. MDT’s are based in the RFP. The software package shall include and incorporate the use of MDTs. Tablets are the preferred form of MDTs but options may be considered. Vendors shall outline specific alternatives as well as any financial impacts.

At a minimum, the system should do the following:

· Interface with the scheduling and dispatching system to access manifests, download them to the vehicle, manage manifests on the vehicle, and capture and send data back to the system for record keeping and reporting. Time and odometer reading for each trip event should be captured.

· The exchange of data between the vehicles and scheduling and dispatching system cannot require any form of manual intervention.

· The entire manifest should be stored on the MDT in case of communication interruption, but manifest updates must be possible in real-time or near real-time.

· Audible alerts for certain messages or manifest changes should be possible.

· GPS-based vehicle location should be reported to the scheduling and dispatching system in real time, or near real time and with every data and communications request sent from the MDT. The system must have the capability of displaying this data on the system’s map display, along with other relevant data such as speed, door status, and idling.

· Vehicle operators should be able to quickly enter status updates to the manifest as they progress through their assigned run.

· The Proposer should describe features that would permit or forbid the operator from changing the order of trips on the manifest.

· The Proposer should describe standard status updates supported as well as what types of customized updates are possible.

· A means shall be provided to allow the vehicle operator to cancel and correct an incorrect trip status message or data entry.

· A means shall be provided to ensure that all manifest updates and changes acquired from the system are received by the MDT and that the system receives all trip status messages sent from the MDT.

· Fallback mode of operation that preserves normal functions to the greatest extent possible whenever the data channel or system is unavailable. The objective is to keep the vehicles operating for extended periods of time regardless of the status of data communications and with minimum need to consult hard copies of the manifests. While in fallback mode, all functions must operate normally, with the exception that manifest additions and deletions will not occur. All data communications messages, trip status messages, and GPS location messages shall be queued for later transmission. The system must be capable of buffering queued data messages for at least a full service day.

· Vehicle operator navigation aid shall be provided without requiring the manual entry of starting and ending points. Usage of the navigation aid with manually entered points, including intersections, shall also be supported. The navigation aid shall be map-based with the vehicle always centered on the display, shall continuously and accurately depict the vehicle’s current location on a map that provides street names and landmarks, and shall re-compute a route recommendation if the operator deviates from the initial recommendation. The navigation aid shall provide user-activated options for both audible and visual directions.

· A zone calculation for each trip to support NTD reporting purposes should be an option. The zones will capture City and or County service areas.

Communications:

Proposers should address both WiFi Capabilities and radio cellular options for ITS. Proposers should also discuss barriers and available options and processes for changing the protocol after the system is installed.

NOTE: SPT’s wireless provider of choice for the MDTs is US Cellular. If for some reason the proposer is incompatible with this wireless provider, please explicitly list this in the responses as well as a list of providers the proposer is compatible with. SPT will procure MDTs based on the response and recommendations of the provider and will work with the provider to procure the MDTs prior to installation and implementation.

GIS

SPT does not currently utilize GIS mapping but incorporating GIS into the software package is critical.

SPT prefers the use of Google maps in the proposed software, and, if used, requires the ability to update these maps internally with updates and with fixed route system changes that affect the ADA corridor.

The Proposer is required to support the GIS data required for the system. Annual updates and maintenance are also required. Any conversion required of the base data set to other industry standard GIS formats, is the responsibility of the selected respondent.

The application of GIS should provide the ability to optimize routes in an expedient and regular manner. The scheduling and routing program must have the ability to easily export data generated for use in other mapping applications. Explain the GIS technology that the software utilizes, and how this program aids the scheduling and routing function. Describe how SPT data will be imported and updated and how data can be exported for other uses. Please be specific. Proposers are expected to demonstrate this functionality.

GIS Display:

The GIS component must be able to display the SPT vehicle routes on the GIS map along with the regular scheduling/routing information. Trip origin and destinations must also be displayed. The system should allow geographic displays of fixed route data and information that will be easily used by operator dispatch and any future bidding including an MDT/AVL system.

Maps should include and support point source data such as a passenger’s home address, commonly visited locations and trace data, as well as polygon data such as municipal boundaries, ADA service area, and Flex zones. The system should be capable of displaying paratransit and point deviation zone information simultaneously. This GIS information/data should be available to users operating any part of the system. The user should not have to exit an application to view map information and data. In addition, the system and maps should:

· Be available from all modules

· Support the display of zip codes, municipal boundaries, landmarks, and common destinations

· Have easy-to-use information features including allowing a user to zoom in or out and pan in any direction, allowing point and click on images to get information such as speed, and indicating one-way streets

· Provide several methods to calculate distance, including straight line and street routing

· Allow for the display of SPT service zone boundaries and the ADA service area and accommodate multiple and overlapping service areas within Portage County

· Automatically create ADA service area boundaries from existing fixed routes data, and recognize day and time variations

· Provide geo-coding capabilities for a variety of locations, bus stops, point address locations, and intersections, and allow geo-coding by mouse if necessary

· Provide a comprehensive search, which displays a list of close matches when an exact street or point of interest cannot be found

· Display the approximate route of any or all vehicles based on the scheduled stops

· Enable SPT to assign latitudinal and longitudinal values to map features Implementation and Installation Each proposal should include a time schedule and transition plan setting forth the sequence of activities, events, and associated time requirements proposed to be undertaken from the point of contract award through the first full month of system operations.

Proposers should include two separate timelines. 1. A two-phase implementation plan, with the software phase completed before the installation of the MDTs, and 2. A timeline for a simultaneous roll out of all software and ITS features. Differences in pricing should be noted.

Proposers should describe the procedures for testing the system during each phase of the implementation, including the test documentation they intend to provide to SPT. The Proposer will provide on-site testing during and after the completion of the installation of the system. Reports of the testing will include a description of all tests performed, the results obtained, and any required modification required as a result of the testing.

The Proposer will provide onsite technical support during the installation process as well as during the time period that SPT will go live with the new system. The Proposer should describe the support that will be provided to SPT for the first year of operation of the system (from the date of full implementation). Proposers should describe, in detail, the installation/start-up and post-implementation support to be provided to SPT.

Performance Requirements

The following performance requirements should be described and any variables affecting performance should be explained. The product’s capability in terms of number of vehicles and trips and service type should be discussed. The proposal should include any other significant performance issues that will either need to be addressed or that are a benefit of the proposed system. As a part of the evaluation, SPT may require the Proposer to do a demonstration of its system performance.

Search and confirmation for trip availability response time with all workstations active Number of client records that can be processed without any appreciable degradation in system performance Maximum daily trips that can be scheduled Optimization time for 200 trips (Proposer should provide an estimated efficiency improvement specific to SPT) The impact on system performance of different service parameter settings

The Proposer should also include a description of the system redundancy features to ensure system availability and prevent a system shut down from a single point of failure. System availability should be at least 99.95%.

Planning Tools Proposers should describe any planning tools in their system that SPT can use to analyze data and find operational efficiencies. These types of tools would allow SPT to plan for growth and service improvements by analyzing ridership, schedule adherence, location and origin-destination patterns, demographics, and perform demand forecasting. Other information SPT would like to evaluate includes:

Scheduling optimization experiments based on ‘what if’ scenarios that do not impact the actual schedule The effect of service changes and other factors on the propensity of specific groups to travel Candidates who may benefit from fixed route travel training based on trip patterns compared to fixed route availability Historical paratransit usage for consideration in the design of new schedules, feeder service, and/or Flex zones Origin and destination patterns and studies

Proof of Performance

All materials furnished and all work performed under this specification should be inspected and tested. Should any inspections or tests indicate that specific software or documentation does not meet the specification requirements; the appropriate items should be replaced, upgraded, or added by the Proposer as necessary to correct the noted deficiencies. After correction of a deficiency, all necessary re-tests should be performed by Proposer to verify the effectiveness of the corrective action.

Test Documentation:

Test Plans and Test Procedures covering both factory and field tests should be provided by Proposer to ensure that each factory and field test is sufficiently comprehensive to verify all the features and parameters of the functions to be tested.

Together, Test Plans and Test Procedures should provide a two-step description of each factory and field test. A high-level functional summary of the methods used for verifying each feature of the requirements being tested should be provided in the Test Plan; the step-by-step activities associated with each test should be listed in the Test Procedures.

Factory Tests:

Factory tests should be conducted on all components of the system. The system components will not be released for shipment to SPT until all factory tests are completed satisfactorily or a waiver has been granted in writing by SPT.

Software Licenses and Programs:

All software licenses should reside with SPT. All software licenses should identify SPT as the licensee, and should be delivered before final acceptance. All original copies of programs provided should also be delivered before final acceptance.

Programming Hardware and Software:

The Proposer should be responsible for procuring all specialized programming hardware and software needed for developing and testing the system. The Proposer should describe what type of test environment will be provided to ensure that future upgrades can be tested by personnel before going live with the system.

System Testing and Acceptance:

The Proposer, working with SPT, should develop test plans and acceptance procedures to ensure the equipment is installed properly and accepted. This testing should encompass the full range of the functions and requirements required by this specification.

All software provided should be tested to confirm that it is compliant with the current specifications, free from defects in design, material, workmanship, and is capable of sustained performance in the operating environment.

Testing should not begin until a sign off of the test plan and procedures by SPT. Test plans should be developed to ensure that the technologies are functioning as specified and reports are generated as required.

The system acceptance test should be conducted after all equipment is installed. SPT cannot accept the technologies until it has validated that the Proposer has met all requirements stated in this RFP. The Proposer should provide all labor and supervision for the installation and testing.

At the completion of the system acceptance test and the correction of any resulting variances, the system will be deemed operational.

On-site acceptance testing will include appropriate Proposer and SPT staff, and will occur at a time agreeable to both Proposer and SPT. System acceptance tests will exercise all system components according to the test plan section of the work plan, and will be designed to simulate SPT's production environment. Toward this end, it will use SPT’s passenger and service provider vehicle and driver data, system parameters, and local maps. Acceptance tests cannot begin until data conversion and system configuration tasks are complete.

This will include the comprehensive testing of:

· Data conversion completeness and validity

· Functional requirements

· Reporting functions

· System requirements

· Software requirements

· Hardware

· Interfaces with external systems

The performance portion of the test will require the successful on-line and batch scheduling of this one week's worth of "past actual" SPT data. Proposer, and SPT staff should work together to fine-tune system parameters until both the on-line and batch scheduling approaches consistently produce schedules which are at least as efficient as those produced by the current system with the same data as measured by:

· Realistic travel times as determined by service provider representative familiar with local geography, drivers’ ability, and traffic conditions;

· Trip assignments that are as productive (measured in terms of passengers/hour); and

· Vehicle runs, miles, and hours.

Tests conducted by the Proposer may not prevent the operation of existing systems or cause system interruptions unless previously approved by SPT.

The Proposer will maintain complete records of all test results. The records should be keyed to the steps enumerated in the test procedures.

A variance report should be prepared by either SPT or Proposer personnel each time a deviation from specification requirements or the Proposer’s design is detected. Variance reports should be collected and maintained by the Proposer’s Project Manager.

The Proposer should document actions taken to correct variances. Sufficient information should be provided to enable a SPT representative to determine the need for retesting the function, for testing interaction with any previously tested function, and for updating appropriate documentation.

Reservations and Scheduling

Proposals should describe in detail the scheduling engine and features, including the following:

Real-time and/or batch scheduling Scheduling parameters, including ability to have different parameters for different services and different funding agency requirements within services Ability to schedule group runs separately from other trips and lock the trips together Schedule optimization Trip scheduling option determination such as least-cost option or preferred provider

Resource Management

The proposal should describe the system’s features to handle driver and vehicle assignments, run restrictions, and the system’s ability to support split shifts and other scheduling efficiencies. The system’s ability to keep the resources of SPT separate should also be described. The proposal should also include methods to manage deadhead time and other paid out-of-service time, such as pre-trip inspection. The proposal should also discuss any features to manage funding agency resources, such as a set monthly budget with the ability to determine the impact of an additional trip on the budget.

Reporting An element of critical importance to the successful implementation of the new software is a comprehensive and easy to use reporting system with a library of prepared reporting options for SPT’s staff to use. SPT must submit standard operating statistical reports on a monthly, quarterly, semi-annual and annual basis. SPT must have the capability to respond to requests for information from their local and state governing bodies as well as their customers.

Proposers should supply SPT with a comprehensive list of reports to be included in the system. Proposers should provide a detailed description of their reporting engine along with any report wizards. SPT is seeking a hearty library of standard reports, the ability to easily create ad hoc reports, and the Proposer’s ability to design and prepare reports according to SPT’s needs. SPT should have the ability to run summary and detailed reports, and to set parameters for reports, including individual program/s, date range, private provider service, funding agency/billing code, and zip code.

Reporting capabilities should be available and should be able to be output in print, fax, e-mail, or a form such as .pdf or Snapshot. The system should also have data import and export capabilities to standard PC software in multiple formats including Word, Excel, Access, and Text. Please describe this functionality. The system should have the ability to copy information to a clipboard for use with Word or Outlook. The system reporting tools should allow for the display of reports on-screen or printed.

The system should contain a full report generating capability to produce custom reports and should be able to perform ad hoc reporting and data reports as required. The system should include an Open Database Connectivity (ODBC) - compliant reporting tool. All standard and custom reports delivered with the system should have been built by and should be editable via the reporting tool.

The list below indicates the minimum reporting capabilities that are required under this RFP. Proposers should include their complete listing of reports. Examples should also be provided.

Proposers should also discuss the process required for SPT’s staff to prepare the reports and whether or not programming is required. Ease of use is an important element in this procurement.

Standard Reports:

Please describe your system’s standard reporting capabilities. The Proposer should include a list of standard reports included with the system in their proposal. Examples of standard reports are:

· Operating Statistics

· Driver Manifests

· Trips By Funding Source

· Trips By Route/Category

· Vehicle Productivity by Run

· Weekly, Monthly, Semi-Annual and Annual Ridership Reports including Total, by Service, and by Funding Agency

· Monthly Billing Report

· Cancellations, No Shows, Late Cancellations Reports, Will Calls

· Idle Time

· On-Time Performance

· ADA Eligibility Expiration Notifications

· Alphabetical Client Listing

· Mail Merge for Address Labels and Letter Generation

· Volunteer Driver Management

· National Transit Database

Ad Hoc Report Generation:

The system must provide tools and wizards that allow users to easily create, edit, and save reports utilizing an industry-standard reporting product.