montgomery college - office of procurement … · montgomery college - office of procurement ......

MONTGOMERY COLLEGE - OFFICE OF PROCUREMENT RFP TITLE: Hosted, Web-based Parking Management System

RFP NUMBER: 513-008 RFP OPENING DATE: September 6, 2012

2

TABLE OF CONTENTS

SECTION 1 PAGE LINE ITEM BID INFORMATION PAGE NO. 1.1 Intent 3 1.2 Pre-proposal Conference 3 1.3 Bid Due Date 3 1.4 Contact Information 3 1.5 Award 3 1.6 Price Negotiation 3 1.7 Product Demonstration 3 1.8 Term of Contract 3 1.9 Bid Evaluation 4 1.10 Rejection 4 1.11 Subcontractors 4 1.12 Required Submittal List 4 1.13 Failure to Submit 5 1.14 Tobacco Policy 5 1.15 Proposal Timelines 5 1.16 Glossary of Terms 5 5 SECTION 2 SCOPE OF WORK/SPECIFICATIONS 6-31 SECTION 3 PROPOSAL EVALUATION AND AWARD 32 SECTION 4 REQUIRED SUBMITTALS 33-35 ATTACHMENT 1 REFERENCES 36-37 ATTACHMENT 2 CONTRACTOR INFORMATION FORM 38 ATTACHMENT 3 NO BID RESPONSE FORM 39 ATTACHMENT 4 CONDITIONS AND INSTRUCTIONS 40-43 ATTACHMENT 5 WCOG RIDER CLAUSE 44 ATTACHMENT 6 REQUIREMENTS CHECKLIST 45-52 ATTACHMENT 7 QUESTIONS & ANSWERS FROM PREVIOUS HOSTED WEB-

BASED PARKING MANAGEMENT SYSTEM SOLICITATION 53-64



3

SECTION 1 BID INFORMATION

1.1 Intent

It is the intent of this Request for Proposal to provide Montgomery College with a hosted, web-based parking management system in accordance with all terms and conditions contained herein. In the event that a special condition is contradictory to a general condition, the special condition shall prevail.

1.2 Pre-Proposal Conference

A pre-proposal meeting will be held on August 28, 2012 @ 11:00am, at Montgomery College, 40 West Gude Drive, Suite 200, Room 202, Rockville, Maryland 20855. The purpose of this meeting will be to discuss the RFP and to answer any questions from vendors. Attendance is not mandatory; however, companies are highly encouraged to attend. Deadline for submitting questions prior to pre-proposal conference is August 23, 2012. Questions should be emailed to contact person listed in line item 1.4.

1.3 Bid Due Date

All responses to this Request for Bid are due in the Montgomery College Procurement Office, 900 Hungerford Drive, Room 110, Rockville, Maryland 20850 by 3:00 p.m. by September 6, 2012 and must be clearly identified and marked as pertaining to this request. No facsimile or email transmissions will be accepted. No responses will be accepted after this date and time. In the event that the College is closed on the bid opening date due to an emergency, the bid will be opened at the stated time on the next open business day, unless the Bidder is notified otherwise.

1.4 Contact Information

For purchasing or technical questions about this solicitation, please contact Patrick Johnson at [email protected] or 240 567-5288.

1.5 Award An award will be made to the highest ranked responsive, responsible Bidder who can meet the terms, conditions, and specifications of this solicitation. The evaluation for award will be made on the basis of payment to the supplier in NET 30 DAYS from the date an acceptable invoice is received by Montgomery College. Payment discounts, if offered, will be taken when appropriate, but will not be considered in the evaluation for award.

1.6 Price Negotiation BIDDERS SHALL NOT SUBMIT PRICING WITH PROPOSALS. The College will negotiate the

fees for the Scope of Work Services with the Bidder rated highest on the evaluation criteria by the College's Proposal Evaluation Committee. If the proposed fees do not exceed the fund limit for the project and it is in the best interest of the College to accept the offer, a contract may be awarded to the successful Bidder. Should the fee negotiation fail to reach an agreement acceptable to both parties, the College may enter into fee negotiations with the next highest ranked Bidder.

1.7 Product Demonstration

Finalists will be required to provide an oral and a live demonstration of their solutions at a mutually-agreed upon site, according to College requirements and specifications.

mailto:[email protected]



4

SECTION 1 BID INFORMATION -CONTINUED

1.8 Term of Contract The initial term of contract will be one year from date of award. At the sole discretion of the College, the contract may be renewed for four additional one-year periods, in compliance with the contract and with the same terms and conditions of the original contract, and as long as funds are available for this purpose.

1.9 Bid Evaluation Bids submitted in response to this solicitation will be evaluated as follows:

1.9.1 Bidder is responsible Bidder demonstrates ability to provide products and/or services that can meet or exceed requirements. The following criteria will be used to determine responsibleness: 1.9.1.1 Bidder has the equipment, ability, and experience to perform the work as stated in

the specifications listed in this bid. 1.9.1.2 Bidder is financially stable.

1.9.2 Bidder is responsive Bidder follows bid submission instructions and provides all requested materials. The following criteria will be used to determine responsiveness: 1.9.2.1 Bidder has favorable references that can confirm its ability to provide the products

and/or services as stated in the specifications listed in this bid. 1.9.2.2 Bidder has provided all documentation and samples requested in the

Specifications/Scope of Work. 1.10 Rejection

The College reserves the right to reject any or all offers received as a result of this bid. Offers may be rejected for any of the following reasons: Bidder fails to;

1.10.1 Meet the mandatory specifications and requirements.

1.10.2 Respond in a timely fashion to a request for additional information, data, etc. 1.10.3 Supply appropriate and favorable client references. 1.10.4 Sign the bid.

1.10.5 Demonstrate that it is qualified to carry out the obligations of the contract and to implement and support the work specified herein.

1.10.6 Provide samples and/or demonstration materials that are representative of the quality level sought by the College.

1.11 Subcontractors

Bidders must submit the names and addresses of all subcontractors to be retained for this project. The College reserves the right to reject.

1.12 Required submittal list

Technical Proposal Contractor Certification and Information Form References Requirements Checklist (pages 45-52)



5

SECTION 1 BID INFORMATION -CONTINUED

1.13 Tobacco Policy

Montgomery College is a tobacco free institution. Use of tobacco products is prohibited in all indoor and outdoor College-owned facilities and facilities leased and controlled by the College as well as at meeting or conferences sponsored by the College. This use prohibition extends to Contractors employees, agents, subcontractors and vendors.

1.14 Failure to submit Failure to provide any of the above items may deem a bid proposal non-responsive.

1.15 Proposal Timeline

The College anticipates that this RFP will be awarded at the November 2012 Board of Trustees meeting, and that the winning vendor will begin work in November of 2012. The expectation is that all tools (i.e., systems) and training (i.e., knowledge transfer) will be operational, functional and standalone (including import of existing data into new tools) within 60 days of award.

1.16 Glossary of Terms

CBT TRAINING (Computer Based Training) - a type of education in which the student learns by executing special training programs on a computer. CBT is especially effective for training people to use computer applications because the CBT program can be integrated with the applications so that students can practice using the application as they learn. CLIENT - A computer that is used directly by a User, for example a PC, Handheld Computer, or Workstation. The term Client is also used to mean the part of a Client-Server Application that the user directly interfaces with. For example, an email Client. CUSTOMER - This term is used to mean students, faculty, staff and administrators at Montgomery College KEY COLLEGE PERSONNEL For the purposes of this RFP, this term refers to key Facilities staff who will be managing and otherwise supporting this contract. SYSTEM - A computer System including hardware, software and applications.

http://www.webopedia.com/TERM/C/CBT.html##http://www.webopedia.com/TERM/C/execute.htmlhttp://www.webopedia.com/TERM/C/CBT.html##http://www.webopedia.com/TERM/C/program.htmlhttp://www.webopedia.com/TERM/C/computer.htmlhttp://www.webopedia.com/TERM/C/application.htmlhttp://www.webopedia.com/TERM/C/CBT.html##http://www.webopedia.com/TERM/C/integrated.htmlhttp://www.webopedia.com/TERM/C/CBT.html##



6

SECTION 2 SPECIFICATIONS/SCOPE OF WORK

2.0 BACKGROUND Montgomery College is the oldest and largest community college in Maryland, serving both Montgomery County and the region for more than 50 years. The College offers more than 200 degree and certificate programs for students seeking associate's degrees, transfer opportunities to a four-year college or university, entrance into the work force or an upgrading of career skills. The College currently enrolls more than 42,000 students annually in credit and continuing education courses and has a staff of nearly 3,000 full-time and part-time faculty, staff, administrators and student assistants.

Montgomery College has faculty, staff and students located on three campuses and five leased sites. These personnel account for over 14,000 registered vehicles. Students and employees of the College must renew their vehicle registration annually at the start of the fall semester. New employees or students may register their vehicles at the start of their employment or class. Students pay a transportation fee at a current rate of $2.00 per credit hour. This fee covers free use of Ride-On public transportation as well as granting parking privileges on all College property. Employees pay a current annual parking fee of $48 only if they wish to park a vehicle on College property.

Campus parking facilities consists of surface parking and two existing parking garages. Parking operations and management are performed by College full and part-time security staff and part-time parking lot attendants. These employees report to the campus security supervisor, who in turn reports to the campus facilities director. In addition, the campus facilities directors report to the Chief Facilities Officer. The Parking Management software will be the principal tool used by the security staff and parking lot attendants for management of parking operations.



7


By virtue of this Request for Proposal, there are six (6) main issues the College wishes to address:

1) Online Permit sales and/or delivery by a third party 2) Point of Sale for parking permits sold locally 3) The integrated system shall be web-based, and shall be hosted and maintained by the vendor 4) The integrated system must use a relational database, and must interface with the Colleges

Sungard Banner system 5) Online parking citation processing/ adjudication 6) Handheld citation writers

The goal of this Request for Proposal is to purchase and implement a Parking Management system that will provide, as example, the following:

More efficient revenue collections Reduced overall workload through automation and use of technology Identification of repeat offenders, scofflaws, and VIPs to field officers Improved communications with customers Improved and enhanced parking permit sales Reduced office traffic through customer ability to apply for and/or purchase parking permits

via the system; and reduced office traffic due to permit distribution via the automated system Reduced office traffic through customer ability to access account information and to pay and

appeal citations via the Internet Improved reporting for system analysis, problem resolution, overall efficiency, etc. Enhanced public and professional image of the College to their customers Time savings by incorporating a relational database that contains permits, properties,

citations, vehicles, and customers (i.e. permit holders, persons responsible for citations, etc.) Improved system for tracking the following: vehicles that have been booted/towed or have

been approved for boot/tow, the status/location of booted/towed vehicles, as well as the fine accrual while in impound

Integration with other parking and financial accounting systems via an open database platform (Note: the system must interface with Sungards Banner system as implemented by Montgomery College).



8


MINIMUM REQUIREMENTS

(VENDOR MUST REPLY WITH A DESCRIPTION OF HOW THEY WILL COMPLY WITH EACH REQUIREMENT)

2.1 PARKING MANAGEMENT SYSTEM OVERALL REQUIREMENTS 2.1.1. Vendor must provide a hosted, modular, and fully integrated relational database system for Parking Management that will interface with Sungards Banner system at Montgomery College. Vendor must include and fully explain as part of this proposal the identity and features of proposed system, as well as the interface and integration with Banner. If the vendor does not provide hosting services then the vendor must demonstrate that any partnerships with third party hosting services meets all specifications as stated in the RFP.

2.1.2. Vendor must provide all hosted database software and hardware upgrades and maintenance, and will securely host College data within the proposed tool. All College data housed on Vendor equipment is proprietary and will be owned by the College. 2.1.3. Vendors project manager will work with key College Facilities personnel to analyze current work flow and best business practices to plan for the implementation effort. Vendor must provide a cohesive, proven, and integrated solution.

2.1.4. Vendor must provide training at designated College training facilities on all required system modules, as well as any additional modules the College acquires (SEE TRAINING REQUIREMENTS SECTION 2.11). Estimated number of staff to be trained in system administration and usage is approximately 50. (Cost of training must be included as a separate line item in your cost proposal, not as an additional cost later.)

2.1.5. Vendor must continually upgrade/enhance hosted system as revisions merit such upgrades at no cost to the College. Vendor must consult with the College when upgrades are imminent, and will provide consultation and planning to the College as necessary to facilitate these upgrades. In the event that the winning Vendor determines that the implemented system, or one of its modules, must be replaced with a new product for whatever reason during the life of the contract, the replacement system/module(s) will be provided to the College at no charge.

2.1.6. Vendor must provide within the system multi-tiered security controls to prevent unauthorized use of the system, restrict access to the systems, and maintain process controls. In addition, the Vendor must provide security to limit availability of system screens and data elements where appropriate. System must provide user logins with varying spans of security and access control for open, browse, update, and close. In addition, the System will provide security to limit availability of system screens and data elements where appropriate.



9

SECTION 2 SPECIFICATIONS/SCOPE OF WORK -CONTINUED

2.1.7. Vendor must provide a Help Facility to provide answers to questions from representative personnel from the College, along with trained technical support staff who can assist with troubleshooting, configuration and support issues. The Vendor must provide a toll free telephone number for Help, and must provide the College with and define their options for Help availability and response time, i.e.,:

Hours of availability Response Times Resolve Times Types of College problems

Business hours

8 am to 5 pm

Mon Fri (Eastern Time)

2, 4, 6, 8 hours or 1 business day, or other options

4, 8, 2 business days, or other options

Critical System configuration/availability issues; Non-critical configuration/problems; Usage Questions

7 am to 10 pm Mon Fri

(Eastern Time)

2, 4, 6, or 8, or other options



24 x 7 2, 4, 6, or 8, or other options



2.1.8. Vendor must provide a proposal and plan for the amount of time required to implement the new system. This proposal/plan must include a Gantt chart detailing the implementation timeline as well as provide a single point of contact (project manager) to Montgomery College for ongoing contract administration and problem resolution, planning, implementation and on-going oversight for the Colleges System to include written project plans and an on going issues status list which will be updated by the Vendors project manager, at minimum, bi-weekly. Vendor must plan and attend regularly scheduled meetings with College staff to discuss, track, and resolve issues through closure, and to determine statuses throughout the life of the contract. Vendor must provide requirements analysis, system installation, training, follow-up, and change management services.

2.1.9. Vendors and or hosting partners must have at least two years of experience providing hosted, web-based Parking Management Systems to at least three customers of similar size and scope as Montgomery College, preferably educational customers. Vendor must provide written references, using this proposals template for references.

2.1.10. The proposed web-based system must provide printing capability from all screens, reports, queries, etc. System must provide print capabilities to print screen, records, list of changes, and must provide the capability to print based on flexible queries.

2.1.11. System must be web-based and securely accessible via the Internet, both within and outside of College premises (inside and outside of College firewall). Access through current and future Internet Explorer browser versions on Windows-based workstations must be supported.



10

SECTION 2 SPECIFICATIONS/SCOPE OF WORK - CONTINUED

2.1.12. System must support Import/export capability from/to Excel, Access, Word, CSV files, PDF documents, etc., and must support the ability to attach documents to any of the proposed systems.

2.1.13. System must provide comprehensive & clear Tutorial and Help Features.

2.1.14. Proposed, hosted system needs to be available as designated. The College expectation is that the system will be available 24 x 7 (except for planned maintenance during non-critical days/times).

2.1.15. Vendor must provide on-site technical assistance, as required, for unanticipated needs of the College throughout the life of the contract.

2.1.16. Vendor must demonstrate the ability to support their products throughout the life cycle of the contract, including the originally installed version.

2.1.17. System must provide audit trails for any action performed against a record (open, reopen, update, close). Audit trail, at minimum, must include user id, date and timestamp.

2.1.18. System must provide a full range of query capabilities which will provide the ability to search based on a number of different criteria and must also allow the use of wild cards. System also must provide the ability to perform Boolean searches, using, at minimum, specific terms, keywords, phrases, item numbers (or similar identification).

2.1.19. System must provide record locking to avoid multiple simultaneous updates.

2.1.20. System must allow for the identification of VIP users as designated by the College.

2.1.21. System must support all Microsoft-supported Windows versions on clients, up to and including Windows XP as well as future Windows versions. The College will be responsible for providing and maintaining client site PCs as necessary.

2.1.22. Vendor must provide a responsibility matrix detailing Vendors staffing for this contract/project plan.

2.1.23. System must provide user logins with varying span of access control for open, browse, update, close and read. 2.1.24. System must be able to archive data based on user specified timeframes or intervals.

2.1.25. Vendor must provide integration between the modules in proposed, hosted, web-based system.

2.1.26. System must provide tables behind specific fields to ensure data consistency, and must include the ability to perform keyword searches in free form fields. 2.1.27. Montgomery College maintains the right to audit the Vendor, and requires an SAS-70 report as part of the Vendor's response to this RFP. 2.1.28. Appropriate hardware devices must be included as part of bid as necessary and required by the College, i.e., handheld ticket writers, electronic cash drawers, barcode readers, receipt printers, etc.



11


2.1.29. System must provide for letter and notice generation (such as overdue invoices, permit renewals, and hearing results). Each letter must be printed and/or emailed based on customer-defined criteria such as but not limited to days past citation issuance for a given license number. The following letter types must be available in the letter and notice generation software:

Customer Statement

Citation Overdue Notice

Hearing Notification/Results Notices

Permit Renewal Letter

Definition/Creation of different types of standard letters 2.1.30. For each type of standard letter in the system, the system must allow the user to print only one such letter applicable to only one citation, vehicle, customer, or the complete batch of that type of letter for all applicable citations, vehicles or customers when certain user-defined conditions are met. 2.1.31. The system must allow the user to delineate the specific combination of conditions that must exist in order to trigger the printing of each standard letter type for a particular citation, vehicle or registered owner. Definable conditions should include but not necessarily be limited to: number of days citation has been outstanding (unpaid), number of unpaid citations, letters for a specific state license plate only. Users should be able to combine these conditions using logical operators to form more complex situations. 2.1.32. The system must allow certain defined fields in each standard letter type to be automatically filled in by accessing data in the database file at the time of printing (i.e. customer name and address, etc.). Such defined blank fields for automatic data entry should include but not necessarily be limited to: individual listing of each unpaid citation, total dollar amount due, specific details for each outstanding citation, vehicle description information, registered owner information and customer authority name and address information.

2.1.33. The system must allow letters to be printed on a standard printer that can be accessed via a local workstation.

2.1.34. The system must have the ability to roll back letters, if they were generated in error. 2.1.35. The system must have the ability to allow an unlimited number of user-defined letter headings to be selected by letter type. The user-defined letter headings should contain name, department, address, city, state, zip code, and phone number. 2.1.36. The system must have the ability to allow for the College-supplied customer unique ID number to be suppressed on letters/e-mails. 2.1.37. The system must have the ability to generate and print notification letters while maintaining an audit trail within the application. Direct access to letter history should be provided as well as storing a copy of the letter in the history. 2.1.38. The system must have the ability to e-mail notification letters while maintaining an audit trail within the application. Direct access to letter history should be provided as well as storing a copy of the e-mail in the history.



12


2.1.39. The system must allow for non-commercial, custom application development against the system. The College should be able to create custom programs and have the system execute those programs in an unattended manner according to our desired schedule. 2.2 RELATIONAL DATABASE AND WEB SERVICES REQUIREMENTS 2.2.1. This system must be based on a relational database which is modular in nature.

2.2.2. System must be user-friendly, must be relational for searches, information updates and queries, must provide advanced reporting capabilities, and must provide context-sensitive menus.

2.2.3. System must be configurable to meet College business requirements as defined by our governing bodies, and should be a basis for enforcing policies and procedures.

2.2.4. Vendor must explain user licensing model. Vendor must provide information about the number of concurrent seats required in their web-based system - the College estimates need for a minimum of 25 concurrent licenses.

2.2.5. System must possess the ability to disable fields, define fields as required, change field titles, and associate default values. 2.2.6. System must be ADA-compliant.

2.2.7. System must possess the ability to schedule tasks to run automatically, to support execution of predefined tasks (such as escalating fines, generating letters, vehicle notifications, etc.), and the ability to user-define tasks (such as report generation, data exports, etc.). 2.2.8. System must interface with Sungards Banner system as installed at Montgomery College. Vendor must fully explain the technicalities of the interface with Banner. 2.2.9. System must allow the creation of a profile for each individual user, and profiles must be revocable, replicable, and printable. 2.2.10. System must allow for the ability to use foreign authentication, to include LDAP and/or Microsoft Active Directory. Vendor must provide a list of supported LDAP programs. 2.2.11. System must offer web services to allow external programs access to features within the application. Web services must, at a minimum, specifically interface with permit sales, citation payments, and the ability to access account information. The system should allow for the creation of a web-based interface allowing secure online transactions. The system must comply with the Payment Card Industry Data Security Standard (PCIDSS).

2.2.12. Vendor must offer consulting services, if needed, to help guide the web services implementation process. 2.2.13. Web services must provide a group of procedures and views that can be called from an outside system that is logged into a parking database. 2.2.14. Web services must fully address permit sales. This includes inserting/updating customer information and inserting/updating vehicle information 2.2.15. Web services must allow a customer to find and pay all citations for which they are responsible

2.2.16. Web services must allow a customer to find personal account information. This includes citation and permit information. 2.2.17. Web services must allow a customer to edit current biographical information



13


2.2.18. Web services must allow a customer to appeal citations. 2.2.19. Web services must allow for more than one citation to be appealed on the same appeal record.

2.2.20. Web services must check apply any business rules defined in the parking database. This includes, but is not limited to, permit restrictions. 2.2.21. Web services must offer real-time interaction with the parking database.

2.2.22. Web services must be capable of operating over a secure network connection including SSL. 2.2.23. Web services must support user authentication.

2.2.24. All activities performed by a web service must be logged in the system activity and/or financial log of the system. 2.2.25. Web services must adhere to the business rules of the system so as not to compromise existing data or allow insertion of bad data. 2.2.26. Web services should include support for insert/update activities to user-defined custom data fields in the system. 2.2.27. Web Development Solutions for e-commerce and customer inquiry web sites. Vendor should offer packaged solutions and custom development options. Vendor should be able to develop a scope document outlining the work to be performed and offer a firm price. The e-commerce website must integrate with the Parking Management database system. The following solutions should be made available:

Customer Account Inquiry

Citation Payments

Permit Sales

Citation Appeals

2.3 PARKING PERMIT MODULE 2.3.1. The system must provide the capability to set up, issue, track and manage permits. Permits are designed to grant permission, authorization or certain privileges. A permit may be a card, sticker or hang tag and it may be issued to a person (or persons) or a property. When a permit is issued, a relationship should be established between a customer, a vehicle and the permit or a property, customer, vehicle and permit.

2.3.2. System must allow customers to apply for parking permits through the web-based system, and must provide a methodology for mailing of permits to customers.

2.3.3. System must have the ability to create three (3) types of permits: inventoried, noninventoried, and non-tracked permits.

2.3.4. System must have the ability to inventory and track uniquely numbered permits as they are being issued.

2.3.5. System must have the ability to return and resell a permit.

2.3.6. System must have the ability to record a permits effective issuance and expiration dates. 2.3.7. System must have the ability to track prior permits, gate cards, and space assignments.



14


2.3.8. System must have the ability to scan a permits bar code at point of sale.

2.3.9. System must have the ability to track gate cards in conjunction with a permit or as a unique permit type.

2.3.10. System must have the ability to register one or more vehicles to a permit (carpooling).

2.3.11. System must have the ability to provide payroll deduction for staff. This software feature must allow for the capture of data concerning individuals choosing to purchase parking permits through a payroll deduction option. It must also allow for the automatic creation of extensive customer defined standard reports for printing and sending to various departments and individuals such as Payroll or Auxiliary Accounting. It must allow payroll deduction through Banner and the host system must recognize such deductions.

2.3.12. System must have the ability to transfer permit balance due items to organization-wide account/billings receivable system. 2.3.13. System must have the ability to sell a permit to a customer and charge the transaction to an approved 3rd party. 2.3.14. System must have the ability to display permit account balance. 2.3.15. System must have the ability to define unlimited customer-defined permit possession status indicators including: active, lost, stolen and returned. 2.3.16. System must have the ability to download permit records to handheld ticketwriters by possession status (lost, stolen, returned, etc.), permit type and location. 2.3.17. System must have the ability to complete tracking and simplified issuance of temporary permits. 2.3.18. System must have the ability to associate multiple customers to a permit. 2.3.19. System must have the ability to make monetary adjustments to a permit. 2.3.20. System must provide direct access to financial information related to the permit. This includes payments, adjustments, additional fees, refunds, etc. 2.3.21. System must provide for population of permits for inventory management. 2.3.22. System must provide for allocation of permits that link to point of sale. 2.3.23. System must have the ability to prorate permit sales/returns and automatically calculate value based on user-defined rules (i.e. weekly, monthly, daily, etc.).

2.3.24. System must allow restriction of the number of permits a customer can purchase. 2.3.25. System must provide the ability to reset the permit fee for monthly billing.

2.3.26. System must allow searches of all permits that are associated with any type of identification field. 2.3.27. System must provide extensive notes field (including date of the note, note type, and comments). 2.3.28. System must provide the ability to print permits at the time of an on-site sale from a networked or receipt printer (includes barcodes and graphics). 2.3.29. System must provide a brief color-coded summary and direct access to all information and invoices associated with a permit on a single screen (e.g. customer, vehicles, associated properties, receipts (payments), etc.). This summary screen should make use of color schemes and readily identifiable icons to expedite user recognition as well as provide context sensitive menus. 2.3.30. System must generate and print permit renewal letters while maintaining an audit trail within the application. Direct access to letter history should be provided as well as storing a copy of the letter in the history.



15


2.3.31. System must e-mail permit renewal letters while maintaining an audit trail within the application. Direct access to letter history should be provided as well as storing a copy of the e-mail in the history. 2.3.32. System must provide the ability to reserve permits for future sale. 2.3.33. System must have the ability to define permit logic in the proposed software. The software should be able to look at the customers classification and determine, if the permit can be sold to the customer and automatically associate the correct price of the permit. 2.3.34. System must be based on a parking object model, and focus on common elements and relationships present in all parking operations, such as:

Individuals or groups that park (customers

Vehicles parked

Permissions to park and citation availability

Parking permit control by location (properties)

2.3.35. System must have the ability to link all elements and modules through financial relationships and audit trails.

2.3.36. System must have the ability to view all activity associated with a vehicle including permits, citations, handheld notifications (messages sent to the handheld), boot/tow information, and notes.

2.3.37. System must have the ability to assign VIP Status to a vehicle. 2.3.38. System must have the ability to define vehicle assignment categories, such as registered owner, driver, rental car, etc. 2.3.39. System must have the ability to prioritize drivers. 2.3.40. System must have the ability to assign a unique registration number. 2.3.41. System must have the ability to manage and process the appropriate plate type series. 2.3.42. System must have the ability to maintain Vehicle Ownership and Plate Type information. 2.4.43. System must have the ability to establish current liability for the vehicle. 2.3.44. System must have the ability to insert an unlimited amount of user-defined fields. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc. 2.3.45. System must have the ability to send custom vehicle notifications to the handhelds, notifications includes a start and end date, notification type and comments. (Examples: do not ticket or tow, VIP, boot/tow, scofflaw, etc.). 2.3.46. System must have the ability to support the attachment of scanned documentation, digital images, documents, or other electronic items to the record. 2.3.47. System must have the ability to display a visual indicator on records with attachments. 2.3.48. System must have the ability to provide a complete list of invoices (citations, permits, boot/tow, etc.) related to the vehicle and the ability to go directly to one of those listed records. 2.3.49. System must have the ability to create scofflaw files based on the citations associated with a vehicle 2.3.50. System must have the ability to provide a scofflaw flag on the vehicle record for easy identification



16


2.3.51. System must have the ability to automatically remove the active scofflaw flag if the vehicle no longer meets the scofflaw requirements. 2.3.52. System must have the ability provide a detailed audit trial of activity related to a permit record or to the vehicle. Waiting Lists 2.3.53. The software must provide the ability to compile and manage multiple wait lists based on a permit control group and/or permit control area (location/zone) or lot while linking this information with permit inventories at point of sale. 2.3.54. The capabilities of the wait list feature must provide for the complete control of the permit wait list management including:

Wait lists that can be prioritized or not prioritized (lottery) Prioritization based on an optional combination of a date field and custom fields Configuration options that either require a customer to be on a particular wait list to

purchase a permit or do not require a customer to have a valid wait list record to purchase a permit. The software must also provide an over-ride feature.

Multiple choice options Mutually exclusive wait lists Automatic update of the wait list position number when records are inserted or edited

Batch Permit Issuance and Invoicing 2.3.55. The software must have a manager that enables the user to issue a batch of permits to an individual, agency or department and bill for the amount due. Additional features must include:

Ability to view all activity associated with the batch permit including customers, permits, receipts, and notes

Ability to make monetary adjustments Ability to update permits to reflect bulk sale Direct access to financial information related to the batch permit record. This includes

payments, adjustments, additional fees, refunds, etc. Extensive notes field (including date of the note, note type, and comments) Ability to print permits (includes barcodes and graphics) Displaying bulk permit balance with payment information Brief color-coded summary and direct access to all information and invoices

associated with a batch permit record on a single screen (e.g. customer, permits, receipts (payments), etc.). This summary screen should make use of color schemes and readily identifiable icons to expedite user recognition as well as provide context sensitive menus

Assigning a unique number to each batch permit record Support attachment of scanned documentation, digital images or other electronic

items to the record A visual indicator that displays on records with attachments Ability to reserve permits for future sale.



17


Inserting an unlimited amount of user-defined fields. Field definitions include data type

(date, flag, character, etc.), field title, length of field, etc. Detailed audit trail for activity related to the permit record

Properties 2.3.56. A property is a building, structure, or address associated with a permit. A property can be associated to people/organizations and permits. The following are activities that must be available for properties:

View all activity associated with a property including customers, permits and notes

Detailed audit trail for activity related to the property record

Extensive notes field (including date of the note, note type, and comments)

A visual indicator displays on records with attachments Share properties among multiple customers Support notes on properties Support custom fields on properties

2.4 PARKING CITATIONS, APPEALS AND APPEALS HEARINGS MODULE(S) 2.4.1. System must allow customers to retrieve information regarding outstanding parking citations and to submit appeals online.

2.4.2. System must provide a module that links directly to citation and hearing records that will track the appeal hearing process.

2.4.3. System must allow the user to enter, view, and print citations by means of either an ad-hoc query or batch basis all information normally associated with a citation, such as:

Ticket number License number/Yr./State (or Province) Plate Type Meter number Date Issued Time Issued Officer Code Location Code Violation Code Vehicle ID Info. (Make, Model, Color) VIN number Miscellaneous officer or office notes.



18


2.4.4. System must provide direct access to information about the following:

Detailed violation information including fine structure (base amount, escalations, accumulations, late fees, etc.)

Extensive notes field (including date of the note, note type, and comments) Display customer name, ID Number and associated company name on the citation if there

is a customer assignment Detailed status information regarding balance due, addition of late fees and fine

increments, administrative holds, and adjustments Allow for the pre-payment of citations not currently in the system (citations paid off the

windshield) Ability to change the status of a citation including void, transfer, uncollectible, reduce to

warning, write off, etc. Ability to track all changes and adjustments made to a citation to a specific individual, date

and time Complete history of transactions associated with the citation, including monetary,

telephone and walk-in contacts Adjusting the monetary amount of a citation Display vehicle, customer, hearing, receipts, notes/attachments, and pre-paid citation data

all from the citation record Support the attachment of scanned documentation, digital images or other electronic items

A visual indicator displayed on records with attachments

Access hearing information from the citation record Access receipt (payment) information from the citation record

2.4.5. System must provide a brief summary and direct access to all information and invoices associated with a citation on a single screen (i.e., customer, vehicles, appeals, receipts, payments, etc.). 2.4.6. System must accommodate a predefined digit alphanumeric format 2.4.7. System must provide a mechanism for rapid and convenient entry of hand-written citations utilizing defaults from a previously entered citation, such as date, officer identifier, location, etc. 2.4.8. System must have the ability to restrict full data edit and delete capabilities to authorized individuals. 2.4.9. System must have the ability to reassign citations to a different customer (ex. from vehicle leasing company to vehicle leasee) 2.4.10. System must have the ability to track and define scofflaws and download scofflaw information to handheld citation units 2.4.11. System must provide direct access to customer, vehicle, citation, appeal, payment and receipt information 2.4.12. System must generate and print notification letters while maintaining an audit trail within the application. Direct access to letter history should be provided as well as storing a copy of the letter in the history 2.4.13. System must have the ability to define one violation per citation



19


2.4.14. System must have the ability to transfer citation balance due items to organization-wide account/billings receivable system 2.4.15. System must have the ability to support accumulated violations 2.4.16. System must have the ability to define whether a violation uses accumulation or escalation 2.4.17. System must include a detailed list of the history of customer association with a citation. The information should include, but not be limited to, the user who created, removed or changed the customer association 2.4.18. System must have the ability to access financial information related to the citation. This includes payments, adjustments, late/fees, appeal reductions, etc. 2.4.19. System must insert an unlimited amount of user-defined fields. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc. 2.4.20. System must have the ability to automatically assess escalations/late fees to citations meeting criteria without the user initiating the process 2.4.21. System must have the ability to automatically generate letters/e-mails for overdue citation notices without the user initiating the process 2.4.22. System must have the ability to freeze a citation from accruing late penalties and receiving notices 2.4.23. System must have the ability to generate a letter on-the-fly directly from the citation record. The letter or email generated must be recorded in the Citation and Customers Letter histories as well as a copy of the letter or email sent. 2.4.24. System must have an extensive notes field (including date of the note, note type, and comments) 2.4.25. System must have the ability to attach digital pictures, files or documents to the appeal record 2.4.26. System must allow for the adjustment of the citation's final amount due by an authorized person and keep track of all adjustments made to the record 2.4.27. System must relationally link and simultaneously update citation files 2.4.28. System must have the ability to set revised due dates 2.4.29. System must have the ability to put citations on hold (no further accumulation of late days, fees or notices) while appeal is in process 2.4.30. System must generate/print and/or e-mail appeal decisions and/or letters on demand for a single hearing or in batch for multiple hearings. This feature must allow the user to call up one of several standard customer-defined appeal response letters in the database file and have information about the citation, customer and vehicle information automatically entered on the standard letter 2.4.31. System must automatically generate letters/e-mails for hearing notification/results notices without the user initiating the process 2.4.32. System must contain a user-defined appeal note code that allows users to read why an appeal was upheld/denied as well as the ability to print this information on letters generated within the software 2.4.33. System must display a message if a citation is currently on appeal 2.4.34. System must allow for user-defined appeal types (oral, written, 2nd appeal, etc.) 2.4.35. System must have the ability to appeal multiple citations on a single hearing record 2.4.36. System must provide visual indicator displays on records with attachments



20


2.4.37. System must have the ability to insert an unlimited amount of user-defined fields. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc. 2.4.38. System must provide a brief color-coded summary and direct access to all information and invoices associated with a hearing on a single screen (e.g. customer, citations, receipts (payments), etc.). This summary screen should make use of color schemes and readily identifiable icons to expedite user recognition as well as provide context sensitive menus. 2.4.39. System must have the ability to assess a user-defined appeals fee 2.4.40. System must offer configuration options for the time limit to appeal a citation and also whether payment is required before the appeal 2.4.41. System must contain a user-defined appeal note code that allows users to read why an appeal was upheld/denied as well as the ability to print this information on letters generated within the software 2.4.42. System must include a judgment decision note field which can be incorporated in the automated hearing notification letters generated within the software. 2.4.43. System must provide an appeals hearings module which will track the appeal hearing process. 2.4.44. System must track the appeal assignment (specific hearing officer or appeal board), comments, appeal status code, appeals hearing schedule with dates and times. 2.4.45. System must track the citation appeal and hearing process. When an appeal record is created, the information relating to a citation must be automatically copied into the appeal record as the citation number is entered. 2.4.46. System must have the ability to require an appeal to have a hearing or apply the result with requiring a hearing 2.4.47. System must have the ability to enter user-defined result codes to indicate appeal outcome 2.4.48. System must provide built-in appeals hearing schedule report 2.4.49. System must have the ability to insert user-defined tables for appeals location 2.4.50. System must have the ability to define a docket (hearing date and time) 2.4.51. System must have the ability to automatically assign appeals to an available docket, based on pre-defined criteria such as number of hearings per docket, officer availability, etc. 2.4.52. The system must automatically generate letters/e-mails for overdue citation notices without the user initiating the process. 2.5 HAND-HELD TICKET WRITING MODULE 2.5.1. System must provide a hand-held ticket writing module that will allow security officers to look up vehicles, VIP, booting and towing information, and to easily and quickly enter, save, print and download citations.

2.5.2. Hand-held ticket writing module must provide drop-down lists populated from the main database when issuing citations to eliminate unnecessary data entry and to provide improved accuracy.

2.5.3. Hand-held ticket writing module must provide a feature that has the ability to track vehicles which have exceeded various parking time limits (a.k.a., a click time feature).



21


2.5.4. Module must communicate bi-directionally with the database using a Windows-based user interface that allows ticket information to be downloaded from the ticket writers, and uploaded to the database.

2.5.5. Vendor must also supply all required ticket stock, envelopes, and other miscellaneous supplies that are necessary for system operation.

Vendor must provide handheld ticket writer ticket stock for 2000 tickets.

Vendor must provide 2000 envelopes to mail tickets issued.

2.5.6. Vendor must support Motorola MC75A handheld ticket writers and ONeil OC3 field printers and provide all items and software necessary to interface to the host system. The handheld computer must utilize software that seamlessly integrates with host parking management system on the network.

2.5.7. Modularity - the system must allow for the addition of handheld ticket writers, users, locations, and modules at a later time.

2.5.8. Host and Peripheral Hardware - host hardware and software, in this case, shall refer to the proposed parking management system with which the handheld ticket writers will interface. Vendor must provide a recommendation for appropriate configuration that is state of the market and is proven to be fully functional with proposed Parking Management System. Additionally, vendor will supply any necessary peripheral equipment to interface to the host system or handheld devices such as printers, magnetic stripe, color camera, and bar code readers.

Specifications for the hardware should be equivalent to or better than the Motorola MC75A handheld and ONeil OC3 printer. Vendor must submit a clear description of any and all warranties associated with proposed hardware.

2.5.9. The vendor will deliver, install, and integrate the necessary handheld hardware and software components with the proposed parking management system to achieve a fully functional, automated parking citation management system. The vendor must also offer total system support for the handheld ticket writer hardware and software under a single comprehensive maintenance and support program. During the term of the maintenance and support program, the vendor must provide scheduled new releases of the handheld and communications software. Handheld Software Specifics

2.5.10. User Interface - Handheld software must provide a user-friendly interface for ease of use and durability.

2.5.11. User Configuration - The handheld software must be completely configurable so that the supervisor may select data entry fields and make them a required entry, an optional entry, or an unused field.

2.5.12. Password/Security - The software must require a valid logon ID and possess multi-tiered levels of security. One is to be used for system administration/configuration and the other for field personnel. The software must comply with the Payment Card Industry Data Security Standard (PCIDSS).



22


2.5.13. Master Files - The system must support entry of information such as vehicle make, model, color, style, plate type, violation, location, void, and standard comment codes. The system must also support full registered owner, scofflaw, VIP, vehicle notifications and tow request files. At no time during citation entry must the user memorize codes for data entry; all entries must be selectable from a screen. This screen must employ a simple scrolling and paging function for location of data. The system must allow the user to browse these files at any time without being in citation entry mode.

2.5.14. Citation Display and Edit The system must easily allow the user to display all citation data entered to that point and to edit or modify any field without disruption of the citation entry process.

2.5.15. Citation Browsing, Voiding, and Reprinting - The system must allow the user to view and void (optionally) any and all citations written by the user since the last upload of data to the host. A valid void code must be entered for the voiding of any completed citation and this code and the officer ID must be noted on exception report at the host. The system must also support reprinting of an issued citation.

2.5.16. Auto Tag/Permit Search - When the license plate and permit number (if applicable) are entered during citation entry, the system must automatically search the customer, vehicle, VIP, scofflaw, and tow request files for a match. If a match is found, the customer and vehicle information must be automatically entered into the proper data fields without additional keying by the officer. If a match is found in any of the VIP, scofflaw, or tow request files, the system must supply feedback to the user. If a match is found in the scofflaw file, the system must display the number of unpaid citations, and outstanding balance.

2.5.17. Chalking - The system must support monitoring of vehicles in fixed time zone parking areas. The system must maintain a file of tag numbers in fixed time parking and, at any time, display the elapsed time and previous location of the vehicle. The software must allow the user to enter the Citation Entry module directly from the Chalking module with one keystroke. The chalk tire records must also have the ability to be downloaded into the parking database for future reference.

2.5.18. Time Stamping - All transactions must be time stamped by the systems internal clock. This feature may not be modified by user.

2.5.18. Warnings - The system must support the issuance and tracking of warnings as well as actual citation issuance.

2.5.19. Location - The system must support standard location codes and descriptions, location comments, block numbers, and meter numbers.

2.5.20. Comments - The system must support both standard comment codes and free-form comments. Software must allow the user to select whether the comments are printed on the citation or hidden and uploaded to the database.

2.5.21. Fines/Violations - The system must be configurable by authorized personnel to allow field personnel to modify the standard violation. The system must support the entry of one violation per citation. The system should prompt the user if an additional citation should be issued to the vehicle. The system will prompt the user for information regarding the additional violation.



23


2.5.22. Handheld Security - The handheld must have a security option so unauthorized users cannot access the system.

2.5.23. Bar Codes - The software must support the capability to print a laser-quality bar code on the citation, reflecting the citation number, so that payment can later be easily and accurately applied to the correct citation during batch payment entry. The system should be able to put any information (up to at least 20 characters) contained within a citation into the barcode, e.g. Citation Number, Date, Fine Amount, Impound #, License #, State, Plate Type, etc.

2.5.24. User Defined Citation Print Formats - The software must allow authorized users to design an unlimited number of custom citation print formats. This includes a selection of variable fields as well as the ability to print warnings.

2.5.25. Required License Plate Double Entry - The software must allow authorized personnel to select whether the license plate must be entered twice for confirmation.

2.5.26. Multiple Citation Alarm - The software must allow authorized personnel to select whether they wish to check for multiple citations to the same vehicle in the same day and notify the officer of the previous citation.

2.5.27. Field Permit Checks - The handheld software must provide the ability to interface with a bar code laser scanner to perform validity checks on bar coded decals and hang tags.

2.5.28. Double Entry Optional feature requiring mandatory double permit entry to reduce data entry errors.

2.5.29. Screen Order The handheld should support presentation of citation data entry screens according to a user-specified order.

2.5.30. Wireless Option The software should support real-time wireless communications over a wireless LAN or cellular network (assuming sufficient hardware and wireless options are purchased).

2.5.31. Snapshots The software must provide the ability to take an unlimited number of color snapshots. The software must automatically download the snapshots and associate to the appropriate citation record.

Handheld Communications Specifics

2.5.32. Host Communications Software - The system must offer a software management component for host communications.

2.5.33. High Speed Communications - The system must offer the capability of direct host communication with multiple handheld units via high-speed data communications.

2.5.34. Real-time Wireless Communications The system must offer the capability of real-time in-the-field communications.



24


2.6 CUSTOMER CONTACTS AND COMMUNICATIONS MODULE 2.6.1. System must provide a methodology for tracking and maintaining customer contacts and communications. Name and address information should be retrievable from an existing database and allow letter generation tracking, as well as tracking and modification of existing letters.

2.6.2. System must provide the ability to view all activity associated with individuals and groups that park or are responsible for parking.

2.6.3. System must provide the ability to track contact information related to a customer including multiple addresses, phone numbers, and e-mail.

2.6.4. System must provide the ability to view a summary section with direct access to all information and invoices associated with a customer on one screen (e.g. citations, permits, vehicles, appeals, boot/tow records, properties, payments, etc.). 2.6.5. System must provide the ability to issue one unique account number per customer. 2.6.6. System must provide the ability to display balance due with convenient access to detail. 2.6.7. System must provide the ability to assign customer classification (e.g. vendor, staff, visitor, etc.). 2.6.8. System must provide the ability to assign customer sub-classification (e.g. full-time, part-time, quarterly parker, etc.). 2.6.9. System must provide the ability to turn on Do Not Accept Checks feature which works exclusively with the register. 2.6.10. System must provide the ability to view an unlimited number of addresses (physical and e-mail) per individual. 2.6.11. System must provide the ability to input user-defined address types (home, work, school, etc.) 2.6.12. System must provide the ability to prioritize multiple addresses. 2.6.13. System must provide the capacity to apply held monies to a customer account with complete audit trail. 2.6.14. System must provide the ability to define e-mail address types (work, home, etc.). 2.6.15. System must provide the ability to define drivers license number field. 2.6.16. System must provide the ability to insert an unlimited amount of user-defined fields. Field definitions include data type (date, flag, character, etc.), field title, length of field, etc. 2.6.17. System must provide the ability to send user-defined customer statements in a variety of formats to inform customer of all outstanding invoices on account (citations, permits, boot/tow, etc.). 2.6.18. System must provide the ability to provide direct access to letter history as well as the ability to store a copy of the letter in the history. 2.6.19. System must provide the ability to define an extensive notes field (including date of the note, note type, and comments). 2.6.20. System must provide the ability to define addresses as invalid. 2.6.21. System must provide the ability to identify potential duplicate customer records with option to merge the duplicate records into one. 2.6.22. System must provide the ability to provide a brief color-coded summary and direct access to all information and invoices associated with a customer on a single screen (e.g. citations, permits, vehicles,



25


appeals, boot/tow records, third party billings, receipts (payments), associated properties, etc.). This summary screen should make use of color schemes and readily identifiable icons to expedite user recognition as well as provide context sensitive menus to allow appropriate edits, additions, status changes, and payment options, etc. 2.6.23. System must provide the ability to support the attachment of scanned documentation, digital images or other electronic items to the record. 2.6.24. System must provide the ability to display a visual indicator on records with attachments. 2.6.25. System must provide the ability to create scofflaw files based on the customer and not the vehicle. 2.6.26. System must provide the ability to provide a scofflaw flag on the vehicle record for easy identification. 2.6.27. System must provide the ability to automatically remove the active scofflaw flag if the vehicle no longer meets the scofflaw requirements. 2.6.28. System must provide the ability to associate free-form financial transactions and adjustments to a customer. 2.6.29. System must provide the ability to provide direct access to receipts (payments) associated with the customer. 2.6.30. System must provide the ability to provide direct access to financial information related to the customer. This includes invoices, payments, adjustments, etc. 2.6.31. System must provide the ability to provide direct access to a customers association with a property. 2.7 CASH MANAGEMENT MODULE 2.7.1. The cash management software manager must allow a bar code reader, receipt printer and electronic cash drawer to be attached to a standard PC workstation thus creating a true, full-function cash management system. The software must allow for direct posting to the proper financial account(s) and complete convenient access to virtually any information in the system without leaving the cash management module. 2.7.2. System must have the ability to provide shopping cart functionality. 2.7.3. System must have the ability to track all transactions by cashier regardless of cash drawer used. 2.7.4. System must allow posting of payments for citations, permit invoices, NSF penalty fees, patron short bills, as well as other items such as bus tickets and pass sales. 2.7.5. System must have the ability to accept and post both payments in full and partial payments as well as apply credits from an existing customer balance. 2.7.6. System must have the ability to write off balance of citation during acceptance of payment. This function must be restricted to authorized users and the maximum authorized write-off amount must be variable based on an individual users access profile. 2.7.7. System must have the ability to enter payments before citation information has been imported from handheld ticket writers and have the information automatically updated when the citation is later uploaded from the handheld ticket writer. 2.7.8. System must be able to notify the cashier if the parking department does not accept checks from a specific customer. 2.7.9. System must be able to print a receipt as necessary that clearly identifies individual transactions and/or items purchased, including citations paid, permit receipts, bus tickets and pass receipts.



26


2.7.10. System must have the ability to print each receipt to a variety of printers in a variety of formats, including point of sale receipt printers. 2.7.11. System must be able to restrict payment methods by a customers classification. 2.7.12. System must provide user-defined payment methods (i.e. cash, check, payroll deduction, payment card (i.e., credit and debit cards) and interdepartmental check). 2.7.13. Systems that provide for payment card payments must comply with the Payment Card Industry Data Security Standard (PCIDSS). 2.7.14 System must provide a separate module for quick and easy batch application of citation mail-in payments. 2.7.15 System must provide the capability to mark NSF check receipts, add associated fees, send customer defined standard NSF check notifications and have the option to activate the Do Not Accept Checks feature in one easy process. 2.7.16 System must provide complete drawer close-out process with detailed reconciliation report. 2.7.17 System must have the ability to access and import, for purpose of sale, a permit record from populated inventory via the cash register screen with automatic calculation of the prorated (if applicable) purchase price. 2.7.18 System must have the ability to scan a bar code printed on sale items (i.e. citations, permits) into various fields to facilitate rapid data entry and lookup at point of sale. 2.7.19 System must provide extensive notes field on each register tape (e.g. to indicate why there are discrepancies between the expected balance and the actual balance). 2.7.20 System must provide transaction total given at close of cash drawer. 2.7.21 System must have the ability to facilitate third party sales (i.e. an individual purchases a permit but the bill for the permit is directed to a third party).

2.7.22 System must have the ability to restrict a permit sale until all citations are paid. 2.7.23 System must have the ability to print receipts on demand and reprint receipts. 2.7.24 System must have the ability to establish payment plans. 2.7.25 System must have the ability to endorse checks. 2.8 REPORTING AND QUERY REQUIREMENTS 2.8.1. Vendor must supply report writing capability for both recurring and ad hoc reporting requirements.

2.8.2. Query and report writing tools need to be thoroughly and demonstrably incorporated into and compatible with the base system to be provided. Tool must provide ability to save all individual queries and reports.

2.8.3. If a third party report writer is utilized by the Vendor, it will be available through a Web browser and will not require installation on College PCs nor will it produce additional cost to implement.

2.8.4. Reporting tools will support detail and summary reporting.



27


2.8.5. Reporting tools must be capable of producing pre-defined reports concerning citation activity, permit sales activity and parking citation appeals activity with a variety of sorting options such as: Date Range(s); Ticket # Range(s); Outstanding Tickets; Tickets Issued by Officer ID; Tickets Issued by Location; Tickets Issued by Violation; Tickets Issued by Time Periods. 2.8.6. Reporting tools must be capable of producing accounts receivable and write-off reports that indicate, by user-defined receivable type, the following: total dollars collected, total citations outstanding (unpaid or partially paid), and total citations disposed by disposition type over a user-defined period (e.g. monthly, annually, etc.). 2.8.7. System must utilize a reporting application the College is currently using or familiar with, such as Crystal Reports, for processing standard and ad-hoc reports. The license to this application must include a concurrent user license to run reports and a developer license to create custom reports. 2.8.8. System must integrate with reporting application so that report execution is seamless and that the user does not see the application execute, even when entering parameters for a report. 2.8.9. System must support the import of reporting applications template files (such as .rpt files) and be able to execute these reports after they have been imported. 2.8.10. System must allow grouping of reports by category so as to simplify choosing a report from a list. 2.8.11. Reporting application must provide the ability to create and export ASCII files

2.8.12. The following are samples of the types of reports that the software must produce:

A chronological listing of citations written by violation type, parking facility location and date range

A listing of all vehicle license plates and VIN #s with X or more unpaid citations

Number and percent of tickets issued by violation type during a date range

Monthly accounts receivable report of tickets unpaid during specified date range

An officer specific report containing tickets written by location, time of day and violation type during a specific time period

A listing of uncollectible tickets by license plate # with ticket #(s) and total dollar amount due

A listing of tickets by name, address and dollar amount due that have aged beyond a user-defined period that can be written off and placed in history files

A detailed report of all activity for a given cash drawer on a given day by transaction type (bus tickets, parking tickets, permits, etc.). The report must show activity for each revenue-producing transaction category.

A report that will provide aging status for unpaid invoices. The report can be broken down by past due statuses such as: Current, 30 days, 60 days, 90 days, and 180 days



28


2.8.13. System must include a query manager that can be used for query building, data export, and posting (batch update). The query manager should include the following:

Query viewing feature that includes the name of the query, description, if the query is personal or shared, and if the query is associated to a task.

Ability to maintain queries. Maintenance items include the ability to view, edit, export, import, clone, and delete queries from the query viewer.

Query building feature that allows users to create a new query. A multi-step wizard should guide the user through the query creation process.

Ability to use a query to edit data in batch form. This could include clearing a permit balance, changing a customers classification, transferring citations, etc.

2.9 HOSTING ENVIRONMENT REQUIREMENTS 2.9.1. Vendor must include, as part of their proposal, information on their disaster recovery plan, including redundancy and hot site location for the protection of the Colleges data.

2.9.2. Vendor must provide daily data backups of all College data and provide the ability to restore data from backup within six (6) hours.

2.9.3 Vendor should provide a clear process for handling outages including a process for escalations.

2.9.4. Vendor must agree to implement and maintain necessary control and security procedures and measures to ensure the protection of Data and Systems against the risk of unauthorized access, alteration, loss or destruction.

2.9.5. Vendor must participate in relevant Montgomery College business continuity plans.

2.9.6. Vendor must develop arrangements for reporting and investigating information security incidents associated with the connection to Vendors hosted site(s).

2.9.7. Vendor must participate in a Mutual Non Disclosure Agreement that explains responsibilities of the Vendor and the College, and that also explains how disclosures will be handled. (i.e., notify MC in writing) of any disclosure of sensitive data.

2.10 DATA MIGRATION REQUIREMENTS 2.10.1. Vendor must have ability to import data from existing databases, such as Access databases and Excel spreadsheets, into proposed parking management tool, according to College requirements and specifications.

2.10.2. Vendor will provide a mechanism for mapping data from existing systems to new, proposed systems, within 30 days after award of contract is made.

2.10.3. System must be capable of creating file formats (e.g. ASCII files) that readily facilitate and accommodate data import/export between all aspects of the Parking Management System and internal/external agencies or departments.



29


2.11 TRAINING REQUIREMENTS Estimated number of staff to be trained is approximately 50. 2.11.1. Vendor must provide training on all required system modules, as well as any additional modules the College acquires. Training will be conducted on College premises. Vendor must limit class size to the number of available workstations.

2.11.2. Vendor must provide any and all training materials for instructor-led and certification training for each attendees. Vendor must provide 5 additional copies of training materials and documentation to College system administrators, and will provide CDs of all materials.

2.11.3. When tool enhancements and changes are made, documentation updates will be provided to the College within three business days.

2.11.4. Vendor must provide the appropriate number and levels of user training courses for each module.

2.11.5. Vendors training staff must have demonstrated (1 year minimum) experience in providing training in assigned modules, preferably for institutions of similar size to Montgomery College. Upon request, Vendor will be prepared to supply resumes of those who will be conducting instructor-led training.

2.11.6. Vendor must provide Train the Trainer education to specified number of MC staff.

2.11.7. Vendor must provide CDs, DVDs, or web-based CBT to provide ongoing training for College staff after implementation.

2.11.8. Vendor must provide refresher training for College staff 3 to 6 months after implementation, according to College needs.



30


2.12 DESIRABLES (Vendor will be awarded additional points for the ability to provide these items) 2.12.1. Officer and Incident Log Module that tracks officer reports and incidents. This module can be used to track incidents for the Jeanne Cleary Reporting Act. Information about incidents on and off campus can be easily entered, saved, approved, and retrieved for easy reporting.

2.12.2. Parking Gates Interface Module that allows the system to interface with any parking access and/or revenue control system that may be installed in the future.

2.12.3. Waiting List Module that will notify the purchaser at the time of selection that a permit is wait listed, and asks if they wish to be added to the waiting list. It will allow the parking administrator to assign priorities for limited permits, based on person type and date requested. This module can automatically inform (within the web interface), assign and invoice when a permit becomes available. 2.12.4. Event Management Module that allows for the planning, management and tracking of scheduled events that impact parking operations and requirements for specific parking facilities. It provides flexible reporting by day, week and date range. This module tracks the allocation of resources, costs, staff, staff location, lots, tickets, permits, and third parties. It will create invoices and track financial issues associated with parking requirements for events. 2.12.5. Instant Permit Module provides an easy-to-use method to issue and print permits for special events using receipt printers. This module will track revenue and payment methods. 2.12.6. Boot and Tow Tracking Module allows the parking staff to track booting and towing from the beginning of the process, including vehicle identification, physically booting or towing the vehicle, tracking impound, and releasing the vehicle to the owner. The software should provide the following:

User-defined release codes that can also be used in standard reporting

Ability to enter all towing agencies and impound garages with associated agency fees that are automatically applied as necessary

Fields for entry of boot ID# and location

Support the attachment of scanned documentation, digital images or other electronic items to the record

A visual indicator displays on records with attachments

Provide a brief color-coded summary and direct access to all information and invoices associated with a boot/tow on a single screen (e.g. customers, receipts (payments), etc.). This summary screen should make use of color schemes and readily identifiable icons to expedite user recognition as well as provide context sensitive menus to allow appropriate edits, additions, status changes, and payment options, etc.

Extensive notes field (including date of the note, note type, and comments)



31


2.12.7. Data Warehouse implementation to store data from external systems when that data is relevant to parking operation logic. The data warehouse should enforce business rules to limit or format data. The data warehouse should support an unlimited number of user-defined fields. The data warehouse should accept updates to data using both batch and real-time integration tools (file importer, web services, etc). 2.12.8. System provides keyword search capability in every field.

2.12.9. Vendor willing to customize database based on stated College business needs.

2.12.10. System provides ability to interface with external applications.

2.12.11. System possesses the ability to provide access to a DMV retrieval service for most states (subscription service). 2.13 Value-added Features

This category will consider any features that the Vendor can offer beyond what has been listed in the RFP requirements. Any points awarded in this category will be added to the Vendors overall score.

2.14 Product Demonstration

Finalists will be required to provide an oral and a live demonstration of their solutions at a mutually-agreed upon site, according to College requirements and specifications. Awarded points will be added to the Vendors overall score. Unsatisfactory product demonstrations may result in the Vendors elimination from further consideration.



32

SECTION 3 PROPOSAL EVALUATION AND AWARD

3.1 Evaluation

3.1.1 Process All proposals submitted will first be examined for responsiveness and completeness by the College evaluation team. Those proposals which do not clearly respond to the proposal submission requirements may be rejected at the discretion of the College. Those proposals not rejected will be evaluated to determine which offer best meets the requirements in the RFP and is in the best interest of the College. Proposal information will be evaluated and scored by the College.

3.2 Evaluation Criteria

The Technical Proposal, including the interview of invited short-listed Bidders, will be valued at 100% of the total score. The maximum point value to be awarded for a Bidder's Technical Proposal is provided below: 2.1 Requirements, Section 2.1 25 (Maximum available points) 2.2 Requirements, Sections 2.2 thru 2.11 25 (Maximum available points) 2.12 Desirables 10 (Maximum available points) 2.13 Value-added Features 5 (Maximum available points)

2.14 Product Demonstration 10 (Maximum available points) 4.1 Proposal Submission 5 (Maximum available points) 4.5 Statement of Qualifications 20 (Maximum available points)

3.3 Rejection of Proposal The College reserves the following rights to be exercised at the Colleges sole discretion:

a. To make such investigation as deemed necessary to determine the qualifications of the

Bidder and to determine the ability of the Bidder to perform the desired scope of services. The Bidder shall furnish to the College all such information and data as the College may request. The College reserves the right to reject any offer if the evidence submitted by, or investigation of, such Bidder fails to satisfy the College that such Bidder is properly qualified to carry out the obligations of the contract and to complete the scope of services contemplated herein. The College reserves the rights to restrict requesting proposals to such Bidders who the College determines are qualified by experience and finances to successfully perform the scope of services. Conditional bids will not be accepted.

b. To reject any or all proposals and to make awards in the best interest of the College, in the name of the Board of Trustees. The College also reserves the right to cancel the Request for Proposals in its entirety.

c. To accept or reject any item of proposal.



33

SECTION 4 REQUIRED SUBMITTALS

4.1 Proposal Submission

A submittal consisting of the Technical Proposal and Required Submittals are required when responding to this Request for Proposal. One (1) original, four (4) hard copies and one electronic copy of the Technical Proposal to this RFP are required. Proposals shall be certified, signed and dated by a bona fide agent of the Bidder and include minority

montgomery college - office of procurement … · montgomery college - office of procurement ......

Documents