Kenosha Joint Services
Request for Proposals #1314
Kenosha Joint Services REQUEST FOR PROPOSALS (RFP) #1314 PUBLIC SAFETY DATA SYSTEMS Direct all replies to: Carol O’Neal, Director County of Kenosha Purchasing Division 1010 – 56th Street, Second Floor Kenosha, Wisconsin 53140 Telephone: 262-653-2605 Fax: 262-653-2604
Purchasing Web Site: http://www.kenoshacounty.org/index.aspx?nid=109
Complete Proposal packages may be downloaded at the above website. Vendors are responsible for checking this website for any addenda prior to submitting a proposal. Kenosha Joint Services is not responsible for the content of any proposal package received through any 3rd party proposal service. It is the sole responsibility of the vendor to ensure the completeness of the documents received from any 3rd party.
SEALED PROPOSALS MUST BE RECEIVED NO LATER THAN: September 12, 2013 at 3:00 PM, CDT A NON-MANDATORY PRE-PROPOSAL CONFERENCE FOR ALL VENDORS SHALL BE HELD AT: Kenosha Joint services 1000 55th St, #1 KENOSHA, WISCONSIN 53140 August 15, 2013 at 10:00 AM, CDT
July 18, 2013
Page 1 of 37
Kenosha Joint Services
Request for Proposals #1314
KENOSHA JOINT SERVICES– REQUEST FOR PROPOSALS (RFP) # 1314 PUBLIC SAFETY DATA SYSTEMS
Section II: Specifications A. Introduction and Objectives: The Kenosha Joint Services (hereinafter “KJS”) is requesting proposals from interested and qualified parties (“Proposers”) to provide public safety information technology for Kenosha Joint Services (KJS), Kenosha Police Department (KPD), Kenosha Sheriff’s Department (KSD) and Kenosha Fire Department. The desired system will include a CAD and Mobile application that serves law enforcement and fire/EMS agencies, as well as an integrated Law Enforcement Records Management (RMS) and Field Reporting (AFR) System for Kenosha law enforcement agencies. KJS is also interested in procuring a Fire Records Management System (FRMS) and a Jail Management System (JMS). Vendors submitting proposals for the CAD/Mobile/RMS/AFR solution are highly encouraged to submit proposals that include the FRMS and JMS as part of an integrated solution, either from a single vendor or as a subcontracted solution. Alternatively, vendors may propose only the FRMS or only the JMS, with interfaces to the appropriate CAD and RMS systems. In short, KJS will be accepting proposals in any of the following formats:
CAD/Mobile/RMS/AFR/FRMS/JMS
CAD/Mobile/RMS/AFR/FRMS
CAD/Mobile/RMS/AFR/JMS
CAD/Mobile/RMS/AFR
FRMS
JMS Please note that vendors may also propose subcontractor(s) as part of each solution if it provides the functionality being sought by KJS. System integration is of paramount importance to KJS. During evaluation, KJS will place a premium on vendors that propose a fully integrated solution. However, in the event the FRMS and/or JMS are procured from separate proposals (subject to approval by all involved parties), the successful proposers agree to cooperatively work together to create seamless integration between the systems. Lastly, KJS strongly prefers to work with a single vendor serving as the prime contractor. B. Background and Scope of Work: Kenosha Joint Services (KJS) was established in 1982 as a standalone government agency responsible for providing public safety support services for the Kenosha City Police and Fire Departments, Kenosha County Sheriff’s Department, and other public safety agencies throughout the County. Serving 160,000 residents across 272 square miles, KJS and associated agencies (collectively “Kenosha”) use two primary information system applications: (1) CISCO Public Safety software, which provides software for Computer Aided Dispatch (CAD), Fleet Maintenance (Fleet), Records Management (RMS), Jail Management (JMS), Evidence/ID, and Fire Records Management (F RMS); and (2) Data Pursuit, which provides the Mobile data software for the Kenosha Police Department (KPD) and Kenosha Sheriff’s Department (KSD). The CISCO application is a highly customized product that has been configured to meet the evolving needs of member agencies. The Data Pursuit application does not meet federal encryption standards and must be replaced, ideally with a system providing greater integration with the CAD, RMS and Field Reporting applications. At this time, KPD and KSD do not have field reporting software, but would like to acquire this functionality through this RFP. In addition to these systems, KJS also uses complementary software products that are integral to day-to-day activities, including E9-1-1, patient care reporting software, mugshot, and fingerprint systems as well the Wisconsin TIME System (TIME), among others. For various reasons, Kenosha is seeking to replace the CISCO and Data Pursuit
July 18, 2013
Page 2 of 37
Kenosha Joint Services
Request for Proposals #1314
applications through this procurement. The following provides additional background information on the involved departments. Additional Background Information Responsibilities of KJS include the maintenance of the CISCO and Data Pursuit applications, Records and Civil Process services, Communications, Fleet maintenance, and Evidence collection and storage. The CISCO application has been highly customized over the lifetime of the application (approximately 30 years) in an attempt to meet the evolving needs of Kenosha. Due to ownership of the source code, Kenoshahas been permitted to directly make these modifications without vendor intervention. The application is installed on Dell PowerEdge servers and operates on a Linux platform. The system is not virtualized; however, Kenosha is open to exploring such an option. Regarding the Communications department, the system serves as a data repository to log incident information as well as to identify appropriate units for response. Existing interfaces allow the system to import E9-1-1 information as well as query state and federal databases (via the Wisconsin TIME system). In addition to the CISCO application, dispatchers also use third party tools to provide mapping data (currently two separate maps – AVL and 911 call data), and BOLO and messaging functionality (provided through Data Pursuit). Within CAD, dispatchers enter information into the application via dedicated data fields (as opposed to command line entry); the CAD system also has an integrated custom developed Emergency Medical Dispatching program. Through this procurement, the Communications department is seeking to increase systems integration, expand functionality, as well as acquire a system that can support the growth of Kenosha and introduce pending industry standards (e.g., NG-911). To provide dispatch information to the field, personnel use a Data Pursuit mobile client. However, this system suffers from limited integration with the CAD system and does not meet federal compliance standards regarding data encryption. The KJS Records department provides service to both KPD and KSD. Due to a lack of field reporting technology, handwritten reports from field personnel are transcribed into the RMS by Records personnel. In addition to incident reports, the RMS is used for basic case management purposes, warrant and civil data entry, as well as to log personnel and citation information. In addition to the RMS, KJS, KPD, and KSD use the following systems to provide additional functionality: Omega CrimeView (KPD) for crime mapping and analysis, LEA (KPD) for internal affairs management, Badger TraCS for citations, and Alchemy for imaging purposes. Through this project, the Records department as well as KPD and KSD hope to introduce field reporting technology to each law enforcement department, expand on functionality within the system, and reduce the number of third party systems in use. Additionally, both KSD and KPD are seeking a user-friendly system that will promote user-independence and allow for ad hoc reporting. Further, it is critical that an interface from the RMS to the Wisconsin TIME system is maintained. The Evidence/Identification department is responsible for law enforcement evidence management and analysis, as well as bookings for select individuals (non-incarcerated and juveniles) and crime scene support. Through this project the Evidence/Identification department is seeking to acquire a dynamic evidence management system that incorporates technology to reduce redundant data entry (e.g., bar coding, mobile property entry) and record the history of all evidence items. The Fleet maintenance department is responsible for the management of vehicles for both KPD and KSD as well as the management of the fueling station. The goal of Fleet maintenance is to move from a data repository to a system that will help the department proactively manage resources. In addition to the RMS, KSD also uses the CISCO JMS application. In total, KSD is responsible for managing approximately 940 total beds across two facilities. In addition to the management of local inmates, KSD is also responsible for the management of federal inmates. This application has been highly customized to meet the needs of KSD, and, through the ownership of the source code, has allowed KSD to develop custom reports and add data fields “on-the-fly.” It’s critical that a future system not only meet the current functionality of the existing system, but also expand on existing functionality and remain integrated with the RMS. To provide other required functionality, KSD also uses the following systems: Northpointe (inmate classification), LiveScan (fingerprints and identification), Swanson (commissary), Mug-o-matic (mug shots), and VINE (victim notification). Lastly, the CISCO application is also used for NFIRS reporting and to manage leave accrual for KFD. To manage other aspects of the department, KFD uses third party systems for inspections (locally developed custom system), Patient care reporting and training management (ImageTrend) as well as number of Microsoft databases. Please note that at this time, the vast majority of Fire apparatuses do not have Mobile computers.
July 18, 2013
Page 3 of 37
Kenosha Joint Services
Request for Proposals #1314
The following subsections describe the software and associated services desired as part of this procurement. Software Systems Kenosha Joint Services expects the Proposer to provide all the software necessary for the system to be fully functioning and fully integrated at the completion of implementation. Proposers are responsible for providing a System with sufficient capacity and performance capabilities to support the requested licenses and volumes noted in Appendix C. The proposed System should be sized to meet the performance standards for the projected volumes plus a margin for unexpected volume growth. The selected Proposer will assume any costs associated with increasing the System capacity as necessary to support the specified volume requirements within a five-year period after Final Acceptance. All proposed software versions must be generally available and operational in a live environment on or before the proposal deadline. The module version for each module proposed must be identified within the Proposer’s response. While KJS does not expect custom interfaces to be operational and demonstrable, it does expect that the Proposer will have experience implementing a similar interface. The following paragraphs describe the systems that are expected to be included in the Proposer’s solution: Computer Aided Dispatch (CAD) – KJS desires a Law Enforcement and Fire/EMS CAD application integrated with other System Application Components and meeting the functional and performance requirements identified in this RFP. The CAD solution should also include real-time mapping, Automated Vehicle Location (AVL), and identified interfaces, as well as integration with an EMD program. Additionally, the CAD configuration must address system redundancy factors, and incorporate backup, failover and recovery solutions. The training environment must mirror the live environment but should not interfere with it. Mobile Computing (Mobile) – KJS desires a Mobile application with real-time mobile mapping and AVL functionality. The Mobile application must be fully integrated with CAD and the proposed Field Reporting System to ensure a seamless transition from incident management to case reporting, and to allow field access to hazards and premise information for situational awareness. The application must be adaptable to either the law enforcement or the fire/EMS environment. Law Enforcement Records Management Systems (RMS) – A Law Enforcement Records Management System is requested that can provide a broad range of functionality including tracking arrests, training, personnel, civil document tracking, fleet management, and property/evidence data, amongst others. The system should have tools to assist with data integrity and accuracy, and users should be able to access multiple databases from a single query, as well as easily develop reports and analyze data. Further, as the RMS will be used by both KPD and KSD, it must support a multi-jurisdictional configuration. Field Reporting (AFR) – The Field Reporting application should allow field users to complete law enforcement reports in either a mobile or a desktop environment and submit those reports electronically to the RMS. At a minimum, the AFR software should provide for the pre-population of report forms, member agency-defined workflow for online routing of reports, supervisor receipt and review of reports, editing and re-routing of reports, case assignment and automatic report distribution. Similarly to the RMS, the AFR application will be used by both KPD and KSD and, as such, must be support a multi-jurisdictional configuration. Fire Records Management System (FRMS) – A Fire Records Management System is requested that is able to track NFIRS, training records, investigations, hazardous materials, occupancy, inspections, as well as patient care reporting (ePCR), amongst other functionality. The application needs to provide appropriate security controls to protect sensitive data, especially pertaining to investigations and medical information. The application must share information between the modules to avoid redundant data entry and comprehensive query and reporting functionality. Furthermore, the application must provide an electronic patient care reporting component. KJS invites vendors to submit proposals for one of the following options:
An integrated FRMS solution (either native or subcontracted) from the same vendor that is proposing the CAD/RMS solution
A stand-alone FRMS
In all cases, the FRMS solution should include all requested interfaces and provide for a seamless transfer of information between the FRMS and the CAD/Mobile solution.
July 18, 2013
Page 4 of 37
Kenosha Joint Services
Request for Proposals #1314
Jail Management System (JMS) – KJS desires a Jail Management System to manage bookings and inmate housing, tracking, and incidents as well as support other duties required as part of corrections operations. KJS invites vendors to submit proposals for one of the following options:
An integrated JMS solution (either native or subcontracted) from the same vendor that is proposing the CAD/RMS solution
A stand-alone JMS
In all cases, the JMS solution should include all requested interfaces and provide for a seamless transfer of information between the JMS and the law enforcement RMS/Field Reporting solution. Specifically, booking and associated information should be transferrable to the RMS while the Field Reporting application will ideally support a one-way data transfer to the JMS. In addition to the above-described applications, the Proposer will be responsible for providing interfaces to the external systems described below. Please note that should the Proposer feel a better solution can be provided (either through native functionality or a third party) for a local solution, it may also be proposed. Interfaces Wisconsin TIME System: The Wisconsin TIME System is the law enforcement message switch and network that provides criminal justice employees with information on wants and warrants, driver license and vehicle registration information, criminal histories, protection order and injunction files, sex offender and corrections information, stolen property, missing persons, and more. KJS requires an interface that will allow users to query the system from within the CAD, Mobile, RMS/AFR and JMS applications. Query returns should populate the appropriate fields in the RMS, the Field Reporting application and the booking module upon user request. From the RMS, users should have the capability to perform the following functions: enter, modify, supplement, cancel and query. Lastly, access to the TIME system must include CIB/NCIC access, including the previously listed functions for RMS users for both persons and property. E9-1-1: KJS requires an interface between the E9-1-1 system and the CAD application. Call takers should be able to import ANI/ALI data from the E9-1-1 system into CAD to pre-fill the CAD incident mask and geo-verify the location information. The interface should be Phase II Wireless Compliant such that ALI data containing latitude and longitude coordinate information is parsed and inserted into the CAD database where it is transformed into a street address and plotted on the CAD mapping application. KJS expects the interface to incorporate NG-911 functionality as it is developed. Please note that KJS will be moving to a new E9-1-1 system in 2014, with the intent that it will be an IP-based solution. Wisconsin Justice Information Sharing (WIJIS): KJS desires an interface with WIJIS for query purposes from the CAD/Mobile and RMS applications. Further, KJS should also have the ability to contribute to WIJIS via the RMS. Badger TrACS: KJS desires an interface between the CAD/Mobile and RMS systems and Badger TrACS. Information related to the call for service stored on the Mobile computer should be made transferrable to Badger TrACS for the purposes of citation writing. Further, the RMS must have the capability to import citation information from TrACS on a to-be-determined frequency. Fire Records Management System (FRMS) (if applicable): KJS desires an integrated CAD/Mobile, RMS/AFR, FRMS system, however if the CAD/Mobile and RMS/AFR applications are not integrated with the FRMS application, an interface between an FRMS and CAD/Mobile must be provided. The interface should allow call for service information to transfer to the FRMS upon initiation of a fire incident. Fire personnel should be able to initiate an NFIRS or patient care report before incident closure and populate the report with pertinent CAD data. Medical calls for service should trigger the initiation of a patient care report (if PCR functionality is provided through the FRMS). Incident header information (time, date, incident location, call type) should be sent to the Fire RMS when the report is initially opened and updated call information (status changes and information updates) should be sent to the FRMS in real time. ImageTrend: Should KFD maintain ImageTrend for electronic patient care reporting (ePCR) purposes, the CAD/Mobile system must transfer relevant call for service information in real-time.
July 18, 2013
Page 5 of 37
Kenosha Joint Services
Request for Proposals #1314
Wisconsin Pawn System: KJS requires an interface with the Pawn system used by pawnshop brokers within Wisconsin. This interface should enable automatic property searches upon entry of stolen property into the RMS. Property searches conducted within the RMS should also search data in the Pawn system. Omega CrimeView: In the event crime analysis functionality provided by the RMS is insufficient, KJS requires an interface between the RMS and Omega CrimeView application. The interface should allow for the automatic export of incident information to the Omega CrimeView application on a to-be-determined frequency. Information that is transferred to Omega CrimeView should be at the discretion of KJS. State Crime Lab: The Evidence/Identification department often utilizes the State Crime Lab for evidence analysis purposes. KJS requires a bi-directional interface with the State Crime Lab’s evidence system to transfer evidence information to the State as well as import results from the State system. Gasboy: Gasboy is the fuel management software used by the Fleet department. The RMS should import mileage and gas usage information into the Fleet module on a to-be-determined frequency. LEA Internal Affairs: In the event the Internal Affairs functionality provided by the RMS is insufficient, KJS requires an interface between the RMS and the LEA Internal Affairs application. The interface should allow for the transfer of personnel information from the RMS to the LEA system on a to-be-determined frequency. Municipal Court System: KJS requires an interface between the RMS and the Municipal Court System to import citation disposition information on a to-be determined frequency. C-CAP: KJS requires an interface between the RMS and C-CAP to import disposition information on a to-bedetermined frequency. Jail Management System (if applicable): KJS desires an integrated CAD/Mobile, RMS/AFR, JMS system, however if the CAD/Mobile and RMS/AFR applications are not integrated with the JMS application, a bi-directional interface is required between the applications. The interface should enable the pre-booking slip completed in the field reporting application to be transferred to the JMS. Arrestee and booking information should be made transferrable to the RMS as well as relevant Civil data. LiveScan: KJS requires an interface with LiveScan. The interface should allow the JMS to send booking information and photographs (mugshots and photographs of scars, marks and tattoos) to the LiveScan system and auto-populate the appropriate fields. Swanson: KJS requires an interface with the Swanson commissary system. Booking an inmate into the jail should trigger the creation of an inmate account in Swanson and inmate demographic information should be sent to Swanson. VINE: KJS requires an interface to the VINE system. The interface should allow for booking information in the JMS to be transferred to the VINE system, along with any changes in an inmate’s status. Northpointe: KJS requires an interface to the Northpointe Classification system. The interface should transfer booking, discipline and release information on a to-be-determined frequency. Further, KJS should have the capability to generate a report of all information transferred to Northpointe over a user-defined time period. Jail Scanning System: KJS requires an interface to the Jail Scanning System (from IMS/21). The interface should transfer Jail ID number and suffix, name, and date of birth over an agency-defined time period.
Hardware and System Software The Proposer will supply all necessary server hardware and system software to ensure that the application software provided by the Proposer will perform at its optimum capabilities. KJS will provide all workstation hardware, but expects the Proposer to provide, where indicated in the RFP, minimum specifications necessary for optimal application software performance. KJS expects three environments: Production, Backup, and Training/Testing. It is the expectation of KJS that the proposed pricing for all hardware and system software will be highly competitive and consistent with Wisconsin state vendor agreements. KJS considers servers and related infrastructure as commodities and typically acquires such standard devices at a significant discount. As such, KJS reserves the right to purchase hardware from sources other than the Proposer.
July 18, 2013
Page 6 of 37
Kenosha Joint Services
Request for Proposals #1314
Implementation and Support The Proposer, with appropriate involvement from County employees and any other designated implementation and support staff must perform all tasks required to implement the proposed system, including all configuration, testing, training and construction of interfaces. Site Preparation The Proposer shall provide minimum and maximum electrical requirements, as well as other permitted ranges of environmental variations, and all other site requirements necessary for satisfactory operation of the System. The successful Proposer shall be responsible for visiting County facilities to obtain information to determine what is necessary to prepare the installation site, and then presenting to KJS a set of tasks necessary to comply with the electrical and environmental requirements. Upon completion of site preparation by KJS, the successful Proposer shall inspect the premises and notify KJS in writing that KJS has complied with such requirements. The cost of any physical or environmental alteration or modification required for the successful installation, operation, and/or maintenance of the System (either by the Proposer or by KJS) that is attributable to incomplete or erroneous site specifications provided by the successful Proposer shall be borne by the successful Proposer at no cost to KJS. Project Management The contracting firm will be responsible for applying project management methodologies in the areas of project planning and implementation, including resource management, project monitoring, configuration management, quality assurance, test planning and execution, training plan, post-implementation support, and documentation. The Proposer must present a comprehensive project plan showing time and resources required to accomplish tasks. The plan should include three major phases: planning, implementation and post-implementation. The Proposer shall provide a Project Manager who will be responsible for coordinating the following:
Project plan development and implementation, project status reporting and any subcontractor work
Requested system changes and modifications to the project plan
All technical, educational, documentation and support services
During the course of the project, until final System acceptance, the contracting firm’s Project Manager will:
Attend regular status meetings
Submit regular status reports, covering such items as: Progress of work being performed Milestones attained Resources expended Problems encountered Corrective action taken
Participate in weekly project status conference calls
In the event that KJS procures applications through multiple proposals, KJS would prefer to sign a single contract with one vendor serving as the prime contractor. Change Management It is expected that the acquisition and implementation of the described system will highly alter current business practices as well as introduce new technology to end users and agencies. As such, KJS expects the Proposer to work with agency personnel to identify process changes, as well as develop training tools and materials to facilitate the transition to the new systems using new business processes.
July 18, 2013
Page 7 of 37
Kenosha Joint Services
Request for Proposals #1314
Documentation Documentation must be developed to support the software and business process pertaining to the software. Any software tools or utilities that are desirable to tune, test, maintain or support the System must be specified in the documentation. Any tailoring or configuring must be documented and delivered to KJS. The contracting firm shall provide KJS with the following:
Business process maps
User documentation
Configuration documentation
Interface documentation
System administration manuals
Application software tutorial
Data dictionaries
Database setup and maintenance
Entity relationship diagrams
System documentation
Documentation for web service/interface definitions
Help desk support call escalation process
Disaster recovery manual
Any other documentation required to implement and maintain the proposed system
All user documentation, including application and interface documentation, help documentation, and software tutorials should be available online and accessible from within the relevant application. Testing The implementation must include adequate provisions for functional, performance and reliability testing. KJS requires Proposer involvement in the development and execution of all test plans to assure that the System delivers the expected results. Satisfactory completion of a mutually agreed-upon Acceptance Test for each stage of the implementation is required, as is a Final Acceptance Test in a fully integrated environment (to ensure components work together as intended). The Acceptance Test will include a confirmation of each functional requirement identified in this RFP, in addition to required performance and reliability acceptance procedures. The Proposer will be expected to demonstrate all contracted functionality, using the product as configured for KJS, during testing. Final System Acceptance will not occur until all testing demonstrates the implemented product works as contracted in the live environment for ninety (90) days. Specific test requirements are described in Appendix E. Warranty The entire System solution as proposed in this RFP should include a first year warranty for proposer-supplied hardware and software for a minimum of twelve (12) months after the formal Final System Acceptance date. Final System Acceptance will not occur until the system has performed for ninety (90) consecutive days in a live production environment without errors. The warranty should include all software updates, enhancements and refinements, as well as all professional services and interfaces. The warranty should conform to contractually agreed specifications, and protect against any defects or damage caused by Manufacturers, Proposers, or proposed subcontractors, in the System’s equipment or software. Additionally, the Proposer will warrant its responses to the functional requirements included in this RFP and any other element of this RFP and will agree to attach its RFP response to any Contract reached with KJS.
July 18, 2013
Page 8 of 37
Kenosha Joint Services
Request for Proposals #1314
Support and Maintenance KJS expects that a five (5) year maintenance and support agreement will be offered. The support agreement should designate priority levels for system errors and include a guaranteed response time for each priority level. Furthermore, it must provide financial reimbursement for vendor failure to meet the required support obligations. Account Manager Proposer will provide KJS with an Account Manager who will be the single point of contact throughout the Proposer’s relationship with KJS. KJS reserves the right to request a change in the Account Manager if it feels the relationship is not progressing in a manner that supports the goals and requirements of the project. Training KJS recognizes that the involvement, understanding and commitment of employees are essential to the successful implementation of the proposed System. As such, County employees will assist in all key process design and configuration decisions. The Proposer is expected to provide the following types of training programs, along with appropriate documentation:
A training program for KJS’s project implementation team that includes the training necessary to understand the overall System architecture, interface configurations, data import/export capabilities, and workflow configuration options, etc.
A training program for application administrators that includes the training necessary to configure, tailor, monitor, and administer the technical and functional aspects of System.
A training solution to support the training of end-users in the functionality of the various proposed System components. To support the training of end users, KJS envisions the use of a “train-thetrainer” approach accompanied by computer-based training.
Post-implementation training for on-going end-user training of the initial System, as well as for future version releases. Again, KJS envisions the use of a “train-the-trainer” approach accompanied by computer-based training.
Multimedia presentations of training made available following actual training (e.g., PowerPoint presentations, videos, etc.).
A training program that accounts for end users on shift work and may not be available during normal training hours.
C. Proposal Response Format: This section describes the format that Proposers must use to respond to the RFP. Failure to follow the format requested in this section, or failure to use the provided forms, could result in a proposal being rejected. There are two parts to the proposal, the Functional Proposal and the Cost Proposal. Instructions for each are detailed below. Submit one (1) original and ten (10) hardcopies of the Functional Proposal. Submit one (1) original and one (1) hardcopy of the Cost Proposal. The Cost Proposal must be sealed and submitted separately from the Functional Proposal. In addition, please submit two (2) electronic copies each of both the Functional and Cost Proposals on a compact disc, flash drive or other portable electronic storage device. Include the electronic copies of the Functional Proposal with the original hard copy of the Functional Proposal and include the electronic copies of the Cost Proposal with the original hard copy of the Cost Proposal. The original proposals must include original signatures, in ink, by authorized personnel, on all documents that require an authorized signature. The following information must be clearly marked on the front of the envelope/shipping package: Name & Address of Proposer Due Date of Proposal
July 18, 2013
Page 9 of 37
Kenosha Joint Services
Request for Proposals #1314
Proposal Number & Title 1) Submit signed offers on the forms provided only. All offers must be manually signed by an authorized official of the firm. 2) Telegraphic, fax, email and on-line responses WILL NOT BE ACCEPTED. The original, signed proposal must be delivered to the address indicated. 3) By submission of a response, Proposer affirms that no alteration of any kind has been made to this solicitation. Several parts of the RFP require the use of Response Forms. The Proposer must use the Response Forms when indicated and include in the appropriate section. Unless otherwise instructed, do not retype or alter these forms. Functional Proposal KJS expects the Functional Proposal to be divided into twelve (12) clearly marked and identified sections. The proposal must follow the format prescribed below and address all requirements identified in this RFP. The objective of the prescribed format is to facilitate the review of all proposals. Failure to complete and furnish all information requested in the specified form and format may result in the rejection of the proposal. The following table describes each section. The paragraphs following the table explain the detail requested for each section as well as corresponding questions that must be answered. When submitting a proposal, all questions must be answered. KJS realizes that proposals may contain the same information in different sections. When information is requested multiple times, please copy the information into each pertinent section so that the Evaluation Committee can evaluate each section individually. The Cost Proposal must be submitted in a separate sealed envelope. Please note, if an answer regarding a question varies dependent on the product or vendor, the response should clearly indicate as such. Should only a single answer be provided, KJS will assume that the answer applies to all products and vendors that are part of the proposal package. In the event that a question is not relevant to the proposal (e.g., if you are proposing a JMS and the question is in regard to CAD), the response should state “Not applicable.” In addition to the sections described below, Proposers should submit a Letter of Transmittal. The Letter of Transmittal should be a formal letter from the proposer prepared in standard business format. It should be brief, signed by a person who is authorized to commit the proposer organization to perform the work included in the proposal, and should identify all materials and enclosures being submitted in response to the RFP. In addition to evaluating the information provided in this section, proposal responses will be evaluated for their completeness, quality and clarity. Functional Proposal Overview Proposal Section
Description
1
Letter of Transmittal/Executive Summary/Table of Contents
2
Proposer Background and Experience
3
Proposer Financial Qualifications
4
Proposer References
5
System Architecture
6
Application Software and Integration
7
System Testing and Acceptance
8
Implementation and Project Management
9
Documentation
10
Training
11
Support, Warranty and Maintenance
July 18, 2013
Page 10 of 37
Kenosha Joint Services
Request for Proposals #1314
Functional Proposal Overview Proposal Section 12
Description Contractual Terms
Proposal Section 2: Proposer Background and Experience 1.
For each Contractor and Subcontractor, fill out and include the Contractor/Sucontractor Information Form (Appendix A – Form A).
2.
If the Proposer is a corporation, formal proof of the authority of the officer signing the Proposal to bind the corporation should be submitted with the proposal. A copy of the corporate resolution or minutes can be adequate proof; a simple letter is not sufficient.
3.
Complete all required forms provided in Appendix D.
4.
For each Contractor and Subcontractor, provide background information about: a.
The Proposer’s company history and experience in the market for public safety information systems
b.
Changes in ownership and acquisitions, including reasons for ownership changes and acquisitions as well as the impact on products offered, R&D and approach to customer service
c.
If a subcontractor is proposed, provide a history on previous work completed together by the proposer and subcontractor. Include the following for each project in which the proposer and subcontractor have worked together: i. Agency ii. Project date iii. Applications installed iv. Responsibilities of each party
Proposal Section 3: Proposer Financial Qualifications 1.
For the Prime Contractor and each subcontractor, fill out and include the Vendor Financial Background Form (Appendix A – Form B).
2.
Provide a copy of the company’s latest audited financial statements.
Proposal Section 4: Proposer References 1.
Each vendor (Contractor and Subcontractor) must complete and include the Reference Form (Appendix A – Form C). Each vendor (Contractor and Subcontractor) must provide at least ten references meeting the following criteria:
At least three (3) references should be for systems installed within the last five (5) years
At least three (3) references should be for systems installed more than five (5) years ago
At least three (3) references should include installations for the same application configuration proposed for KJS
July 18, 2013
Page 11 of 37
Kenosha Joint Services
Request for Proposals #1314
At least three (3) references should reflect similar demographics data as KJS
Proposal Section 5: System Architecture System Diagram 1.
Provide a diagram of the proposed System architecture. The diagram should include an overall representation of the servers, network, peripherals, workstations, mobile data components and interface points, as well as a representation of the System environments (Production, Backup, and Training/Testing). Note: All items listed in Hardware Costs section of the Cost Proposal must be included in the diagram and vice versa.
2.
Provide justification for the proposed system architecture.
3.
Are there any recommended alternative system architecture configurations? If yes, please describe.
4.
Provide minimum and maximum electrical requirements, as well as other permitted ranges of environmental variations, and all other site requirements necessary for satisfactory operation of the System.
5.
Does the system support virtualization? Proposed Hardware Configuration
1.
Fill out and include the Server Configuration Form (Appendix A – Form D).
All servers required to implement the proposed solution must be included in the Server Configuration Form.
The total number of servers must match the total number of servers listed in the Cost Proposal.
The Proposer will be responsible for all costs related to providing any servers required to implement the proposed solutions and which are not accounted for in the Cost Proposal.
2.
How many servers are proposed?
3.
Describe the ability of the proposed servers to support the requirements and processing performance characteristics for the volumes described in Appendix C for at least five years from the date of overall Final Acceptance.
4.
Fill out and include the Recommended Workstation Hardware Form (Appendix A – Form E). Performance and Reliability
1.
Describe any impact to systems (e.g. interference to normal operations, system shutdown) that will occur during server upgrades and/or expansions.
2.
How will Proposer ensure concurrent operation of all System components without any System degradation?
3.
Describe the system response times that will be guaranteed during the lifetime of the system (both during original warranty period and lifetime support). This is specifically referring to the transaction times related to commands.
July 18, 2013
Page 12 of 37
Kenosha Joint Services
Request for Proposals #1314
4.
Describe how the Proposer will measure and ensure system performance over the lifetime of the system.
5.
KJS expects seven day, twenty-four hour operations for the CAD System. Describe how the Proposer will guarantee 99.999% System Availability both initially and during the life of any license and maintenance contract.
6.
What level of availability is recommended for the RMS, Field Reporting, FRMS and JMS applications? a.
Describe how the Proposer will guarantee this level of System Availability both initially and during the life of any license and maintenance contract.
b.
Provide pricing (Appendix A – Form P: Optional Costs) for 99.999% System Availability for each application. System Failover and Restoration
1.
Provide a detailed description of the proposed backup environment.
2.
Do operations automatically failover to the backup environment in the event of a failure in the production environment? Describe any actions that must be taken by personnel to activate the backup environment.
3.
How much time is required until operations commence in the backup environment when operations in the production environment fail?
4.
What steps, degree of user intervention and time is required to initialize the backup environment?
5.
What steps, degree of user intervention and time is required to return operations to the primary environment?
6.
Describe the proposed method of restoring data files.
7.
Describe any limited functionality with which the system will operate during the restoration process. Network Compatibility
1.
Describe how the mobile dispatching and field reporting systems (law enforcement and patient care reporting) work in an environment of intermittent mobile computer connectivity.
2.
What is the slowest wired network connection speed that is required to support the System?
3.
What is the slowest wireless network connection speed that is required to support the System? Please note that KJS currently operates over an 800 MHz network and intends to move to a 4.9 GHz network in the near future. a.
Note any difference in functionality (either in features or performance) between operating over an 800 MHz and 4.9 GHz system. Operating System
1.
Provide the name and version number of the proposed Operating System.
July 18, 2013
Page 13 of 37
Kenosha Joint Services
2.
Request for Proposals #1314
If the Proposer’s recommended Operating System incorporates any proprietary or non-standard components, provide justification for the component. System Software Applications and Utilities
1.
Fill out and include the System Software Form (Appendix A – Form F), identifying the name, company, and release level of the following applications and any other programs that the Proposer recommends above and beyond the main CAD/Mobile, RMS/AFR, FRMS and JMS Applications, as well as any other applications that are required to support the proposed solution (e.g., MS Office). System Backup
1.
Describe the Proposer’s recommended approach for System backup.
2.
How will the Proposer’s recommended System backup process affect the live operation of the System?
3.
Are all system functions (inquiry and update) available during backup? If not, explain the level of availability of System functions during backup.
4.
Will the Proposer’s recommended approach for System Backup enable a full backup of the System? a.
What is the maximum time a full backup will take?
b.
Can the full backup be performed unattended?
c.
Can full backup be scheduled to occur automatically?
5.
Can the System perform incremental backup (i.e. only data/files updated since last backup)?
6.
Are backups made on an earlier software version or hardware platform always available in the current system? Describe any limitations.
7.
What is maximum retention period for data in the production environment?
Proposal Section 6: Application Software Software License Agreement 1.
Include copies of the proposed standard software licensing agreements. Major System Components
1.
Fill out and include the Application Software Module Form (Appendix A – Form G). Identify all Application modules included in the CAD, Mobile, RMS, Field Reporting, FRMS, and JMS Applications, as well as the module in which desired functionality is located. All modules listed must be included in the Cost Proposal.
2.
Does the Proposer provide a site license option(s) for all system components proposed? If no, please identify those components for which site licensing is not an option and indicate why a site license would not be the most cost effective option.
3.
Use the Excel Workbook provided in Appendix B to indicate how Proposer can satisfy KJS’s functional requirements. The Proposer should complete the spreadsheet, but should not modify or alter the workbook format in any manner. Modification or alteration of the workbook format may result in
July 18, 2013
Page 14 of 37
Kenosha Joint Services
Request for Proposals #1314
rejection of the proposal. The Proposer should include the workbook in electronic format on a compact disk, flash drive or other portable electronic storage device in this section. a.
The Proposer should leave the workbook as an Excel file and not convert to .pdf. If the Proposer wants to provide a .pdf version of the Excel file, it should do so in a file separate from the main functional proposal document. Inclusion of .pdf files in the main functional proposal document makes the document excessively large and difficult to navigate.
b.
All detailed requirements in Appendix B are numbered in the left-hand column. These identification numbers should not be changed or omitted in the proposal.
c.
Detailed response instructions are included on the first worksheet of the workbook. Failure to follow the instructions will result in rejection of the proposal. Proposers are asked to indicate their ability to comply with the requirement using the codes described in the following paragraphs: i. “C” indicates that the requirement will be met by proposed existing software that is installed and operational at other sites and can be demonstrated to KJS. The cost of requirements receiving this Response Code is included in the cost of the standard application software. If the software required to meet this requirement is under development or in a test or beta phase, do not answer with a “C” response. Answer with an “N” response and indicate the development status in the comments column. ii. “N” indicates that the Proposer cannot comply with the requirement. If a Proposer is answering “N” because it cannot meet the requirement in its entirety, please indicate why in the "Comments" column. iii. “A” indicates that, while the Proposer cannot meet the requirement exactly the way the requirement is stated, the Proposer can meet the requirement without modification to the standard application software and without additional cost to KJS. The cost of a requirement receiving this Response Code is included in the cost of the Proposer’s standard application software pricing. For example, the requirement can be met via functionality in the Operating System software. Responses in this column must be accompanied by an explanation in the “Comments” column. Failure to provide an explanation will result in the response being counted as an “N” response. iv. “M” indicates that the Proposer can meet the requirement by modifications to existing standard software. Responses receiving this Response Code have an additional cost associated with them. All "M" responses must have supporting explanations in the "Comments" column. Additional costs for modifications must be listed in the Cost Proposal and must reference the specific functional requirement associated with the cost. v. “T” indicates that the Proposer can meet the requirement through the use of third party software. All third party software necessary to meet the listed requirements must also be listed in the Cost Proposal. Failure to do so will result in a re-coding of the response as an “N. All “T” responses must have supporting explanations in the “Comments” column, including the name of the third party provider.
Note that a blank response will indicate to the Evaluation Committee that the Proposer cannot meet the requirement. Blank responses will be counted as “N” responses. Interfaces
July 18, 2013
Page 15 of 37
Kenosha Joint Services
1.
Request for Proposals #1314
Fill out and include the Interface Identification Form (Appendix A – Form H) for each proposed interface. If an Interface Identification Form Is not provided for an interface, KJS will assume that it is not included in the proposed solution. For each interface: a.
Describe Proposer’s specific experience with the desired interface, including number of sites installed, date initially installed, operational status, direction of data exchange, and the development language or tool
b.
Described the proposed approach to developing the interface
c.
List any assumptions or constraints (e.g. communications protocol) to successfully completing the interface
d.
Describe the services being provided and any assumptions regarding working with the interfacing agency or organization to develop the interface Security Features
1.
Describe to what level of depth (field, screen, module, etc.) security and permissions may be controlled within an application.
2.
Describe how the proposed System manages unsuccessful log-on attempts. Can KJS establish the number of attempts allowed? What is the reporting or alerting mechanism used to communicate unauthorized access?
3.
Regarding the Mobile client, how does the Proposer ensure to meet CJIS wireless encryption requirements? Will the Proposer maintain CJIS security and encryption requirements over the lifetime of the system? Geofile
1.
Does the system support ESRI 10.1? If yes, will the system maintain ESRI compliance as versions are upgraded?
2.
What GIS data, at a minimum, is required for the CAD geofile?
3.
What is the maximum number of map layers supported by the geofile?
4.
Will the proposed solution use the same geofile for all applications?
5.
What utilities are provided to manage the geofile?
6.
Describe the system administration tasks required to create, update, and maintain the geofile.
7.
What is the process for synchronizing the geofile with KJS’s GIS database? Describe the GIS transfer process.
8.
Does the system support both ArcGIS and shapefiles? System Administration
1.
What periodic System management functions should be performed to maintain System performance?
2.
How much System Administrator time is needed per week?
July 18, 2013
Page 16 of 37
Kenosha Joint Services
3.
Request for Proposals #1314
Use the Post-Implementation System Staffing Form (Appendix A– Form I) to identify the resources required to provide ongoing support for the system after implementation. Source Code
1.
KJS requires that the source code be made available at least through an escrow-type arrangement. As soon as software becomes “non-supportable,” the source code must be made available. Does the Proposer supply the source code with the System?
2.
Is programming documentation provided along with the source code?
3.
Include any escrow costs in the cost proposal. General Software Functionality Questions
The following questions should be answered for all proposals. 1.
The CISCO application is a highly customized application that has been modified to meet the needs of KJS. Describe the level of configurability that exists within each application, specifically in the ability to add and modify data fields and create custom reports and forms. a.
Will the source code be provided with the system?
2.
Are modifications made in one module/application propagated throughout other modules and applications?
3.
Describe the system’s ability to provide alerting functionality. Specifically, how can alerts be created within the application and how are individuals notified of alerts?
4.
What type of licensing structure is proposed (e.g., by user, workstation, concurrent, etc.)? If concurrent is proposed, can the System notify an administrator when the concurrent user exceeds a defined license count? Further, if concurrent is proposed, how will the System account for mass incidents in which the maximum number of licenses permitted is exceeded during a period of time?
5.
Describe the System’s ability to archive data. Will the data always be available for reporting purposes?
6.
Does the system support Active Directory? Does the system support two factor log-on?
7.
KJS has a strong preference for software that incorporates federal standards that allows for easier data sharing. Describe how the system incorporates federal standards and its approach to incorporating (i.e., import and export of data) to and from third party systems.
8.
Describe each application’s capability to provide audit trail information. a.
When viewing audit trails, does the system provide the capability to visually distinguish the information that was changed? Provide screenshots if possible. CAD/Mobile Software Questions
The following questions should be answered for proposals that contain a CAD/Mobile solution. 1.
KJS is exploring the potential of CAD-to-CAD interfaces with surrounding jurisdictions. What is the Proposer’s experience in providing CAD-to-CAD interfaces? Provide references for other clients that have implemented CAD-to-CAD interfaces.
July 18, 2013
Page 17 of 37
Kenosha Joint Services
2.
Request for Proposals #1314
Describe the ability of the System to support a multi-agency, multi-jurisdiction environment. In particular, how does the System: a.
Accommodate incident numbering while also referencing the responding agency?
b.
Accommodate different response plans per member agency?
c.
How is information transferred from a single incident to multiple agencies?
d.
Provide for unique incident timers?
e.
Provide for unique call and incident types?
3.
What is the Proposer’s experience/participation in NG-911 development? Will the Proposer maintain compliance and introduce functionality that is developed as part of NG-911 advancements?
4.
What is the Proposer’s experience/participation in national committees (e.g., NENA, APCO)?
5.
The current system allows for incident numbers to be shared across agencies, but also has unique identifiers to the responding agency (e.g., the incident number is “001”; if KSD responds, their incident number is “KSD-001”, if KPD responds, their incident number is “KPD-001”). Will the proposed System accommodate a similar configuration?
6.
The Kenosha region has a number of unique address points that are critical to address and accommodate within a replacement CAD system. The following describes two such unique instances: Example 1: Overlapping Street Ranges The Kenosha County address numbering scheme starts on the east end of the county with the number 1 and continues to the western boundary where the scheme ends with 40800. North to South, the numbers start with 1 on the northern boundary and continue to 12800 on the south. Municipalities within the county are free to use either the standard Kenosha County numbering scheme or may implement their own if they are an incorporated municipality. Because of this option, there are several streets that have overlapping address ranges due to municipal numbering conventions not following the county numbering convention. The current system only recognizes the first occurrence of an address that it encounters in the geographic data table even if the same address is entered with a different geographic grid. If more than one instance exists, the system will choose the first one it encounters in the data and use it. In these cases, a workaround has been developed in which the Communications Department has created street aliases for the address ranges that overlap. This results in a single street being named numerous different ways. For example, in Kenosha is a street named 104 th Street. This street runs the entire length of the county and runs through several municipalities. One of the municipalities applies its own addressing scheme to the span of this roadway that is within their civic boundaries. This municipality uses addresses that are the same as addresses in another municipality that chooses to use the county numbering scheme. KJS has addressed this problem by naming 104 th Street 3 different ways. The correct name for the street is “104 th St”. In the municipality on the east end of our county which follows county numbering, KJS has had to create a street alias of “104 th St (east of 22 nd Ave)” and assign addresses lower than 2200 to that street. In the municipality on the west end of the county which uses its own numbering scheme, KJS has an alias of “104 th St (Twin Lakes Main St)” with the same addresses assigned to it. The user must choose from 3 different possibilities for the same street.
July 18, 2013
Page 18 of 37
Kenosha Joint Services
Request for Proposals #1314
How would the proposed System manage this issue? Example 2: Duplicate Intersection Names In the county, intersections often are not true 4 way intersections. There are many instances in the county where the roads that intersect are offset by ¼ mile or more, which requires KJS to have 2 or more intersections named the same way. The current system allows this and also allows descriptive text to be associated with each name. How would the proposed System manage this issue? 7.
What is the Proposer’s recommended best practice for managing pre-plans so that they are made available to both dispatchers and field personnel (e.g., stored within CAD, stored within Fire RMS, etc.)?
8.
Does the system take into account special skills and/or equipment when recommending units? If yes, how does the system take into account those special skills and/or equipment (e.g., are individuals required to provide this information as part of sign-on, is it linked to a personnel database, etc.)?
9.
Describe how fire response plans are developed within the application as well as what tools are made available to KJS (e.g., drawing tools).
10. Does the Proposer have any experience in accommodating MABAS into the CAD system? If so, describe the functionality offered as well as references. 11. KJS has a number of fire apparatuses that serve dual roles (essentially cross-staffing but applied to apparatuses). Describe how the system accommodates apparatuses that serve multiple purposes, particularly in regard to recommending units and accounting for that unit’s purpose during unit status views. 12. On certain law enforcement incidents, an officer responding to an incident may leave the scene to conduct a follow-up investigation. At this time, the incident is still active; however, the officer may have visited multiple locations that are not associated with the original call for service (for example, the incident occurred at 1 Main St., however the officer has visited 10 Pine St. and 5 Elm St. during the time the call is active). Does the system provide the capability to record these associated addresses? Further, would an individual be able to query an associated address to determine the original incident details (e.g., query 5 Elm St. and be notified that the original incident occurred at 1 Main St.)? 13. Does the system provide the ability to store Standard Operating Procedures (SOPs) within the application? If so, can the system be configured in such a way that when entering specific information, the relevant SOP is returned (e.g., for an incident type)? 14. How does the proposed system provide paging capabilities? Are email page notifications supported? 15. Describe the process by which the maps in the Mobile computers will be updated. There is a significant concern of KJS of the amount of data that is required to be transferred and the potential time that will be required for the updates to be completed. 16. KJS currently uses a custom developed questionnaire for EMD. As part of this project, KJS is looking to adopt a COTS EMD solution that is integrated with the CAD system. As such, should the Proposer have an existing relationship with an EMD provider, pricing of that application should be included in
July 18, 2013
Page 19 of 37
Kenosha Joint Services
Request for Proposals #1314
Appendix A – Form P: Optional Costs. With which EMD products has the Proposer successfully interfaced to? Additionally, please describe what information is stored within the CAD system and how the EMD system is launched and managed from within the CAD application (e.g., is it automatically launched and information recorded, or does the system simply transfer the user over to the third party program?). 17. Does the proposed CAD system provide for status monitors for users outside of the Communications Center? If yes, describe the functionality offered and how individuals would have access to CAD data. 18. Does the proposed system provide functionality that would allow audio files to be attached to the call for service record? If yes, please describe. 19. Does the proposed CAD system support Automated Secure Alarm Protocol (ASAP) to Public Safety Answering Point (PSAP) functionality, in which alarm information can be automatically transferred to the CAD system (see APCO/CSAA 2.101.1.2008 ANSI standard)? 20. Describe the test/training environment of the proposed CAD system. Specifically, does the user have an option of logging into the test/training environment or must it reside on a dedicated workstation? 21. Describe how AVL functionality is incorporated into the CAD/Mobile systems, specifically in regard to the functionality offered and technical requirements of the solution. Law Enforcement RMS and Field Reporting Software Questions The following questions should be answered for proposals that contain an RMS/AFR solution. 1.
Is the Proposer certified as UCR compliant within the State of Wisconsin? a.
Describe the process and steps necessary should KJS convert to NIBRS reporting following implementation (please note that it is the intention of KJS to maintain UCR reporting at this time).
b.
Is the proposed system WIBRS compliant?
2.
Has the Proposer provided an interface to the BadgerTrACS system previously? If yes, provide references and a description of how the interface operates, including the version of TrACS.
3.
KJS is concerned with losing historical values of code tables if they are modified or deactivated. Describe how the system maintains historical values for research and reporting purposes.
4.
Describe how the field reporting software identifies the responsible party for writing a report, both member agency as well as specific officer(s).
5.
Describe how the system is capable of supporting a multi-agency environment. In particular, how will each member agency be able to uniquely configure the system and separate data between both KPD and KSD as well as create unique member agency workflows? Further, will users of each system have the ability to view the other system’s records simultaneously?
6.
Will the field reporting application provide the ability for each member agency to create unique forms and reports? If so, describe that process, including at what point in the process that may occur (i.e., during or after implementation) as well as the responsible parties.
7.
Describe the process by which UCR data will be submitted to the State.
July 18, 2013
Page 20 of 37
Kenosha Joint Services
Request for Proposals #1314
8.
KJS is interested in exploring regional data sharing initiatives. Describe the Proposer’s experience in allowing customers to share law enforcement data with neighboring jurisdictions (including both those that are and are not using the same RMS vendor).
9.
Describe the system’s ability to incorporate bar coding functionality, particularly in regard to the property/evidence, fleet and inventory management modules.
10. Describe the system’s ability to support the storage of digital evidence (e.g., audio files, photos). 11. Describe the system’s ability to incorporate accounts receivable functionality. 12. In KJS’ current system, there are fourteen (14) agency codes for warrants. Regardless of the warrant agency, KJS is able to update the record when served with the appropriate KSD or KPD officer unit number. Does the system provide this capability? 13. KJS is interested in acquiring a system that can manage digital photos as part of the RMS. Describe the capabilities to manage digital images and how they are associated with specific incidents and cases. Further, describe how the system allows users to query images as well as how the Proposer envisions storing the images so as not to adversely affect system performance. Fire RMS Software Questions The following questions should be answered for proposals that contain a Fire RMS solution. 1.
Is the solution NFIRS 5.0 compliant?
2.
Is the solution NEMSIS compliant?
3.
Describe how the system assigns responsibility for NFIRS and PCR reporting.
4.
Describe the system’s ability to support both payroll and scheduling functionality.
5.
What type of mobile workstation hardware and operating system software is supported for the electronic patient care reporting portion of the system (e.g., laptops, tablets, etc.)?
6.
Describe the system’s ability to support mobile functionality regarding inspections. Does the system require constant connectivity? JMS Software Questions
The following questions should be answered for proposals that contain a JMS solution. 1.
If the Proposer is proposing a stand-alone JMS, describe the approach for integrating the JMS, RMS and Field Reporting applications. How will Master Name Files be managed between the JMS and RMS? What data will be transferred across the systems (e.g., booking data, status updates, etc.)?
2.
KJS is concerned with losing historical values of code tables if they are modified or deactivated. Describe how the system maintains historical values for research and reporting purposes.
3.
Currently the KSD has a website that allows the public to query inmate information and status. Further, KSD has the capability to restrict what information (including which inmates) is available on the website. Does the proposed software offer this type of functionality? If so, how can information be filtered by the end-user and how can KSD restrict what data is made available? Please note that both current and historical incarcerations must be made available for queries.
July 18, 2013
Page 21 of 37
Kenosha Joint Services
4.
Request for Proposals #1314
KSD has a large number of custom reports that have been developed over the lifetime of the CISCO system (approximately 300). These reports are critical to the day-to-day functions of the Department and must be made available in a future system. As such: a.
Describe the reporting capabilities of the JMS.
b.
What type of reporting tool is used by the system (e.g., Crystal, SQL, other)?
c.
Will the vendor develop all required reports? If not, how do you propose these reports are developed?
d.
Within each report, can the user specify the jail location (currently there are two facilities in Kenosha)?
5.
The current mug shot system also provides a bar code tracking system that is used for inmate identification (for inmate wristbands). The wristband not only contains an inmate’s photo, but also key identifiers (e.g., name, date of birth). How does the JMS accommodate inmate management, specifically related to inmate wristbands and bar code functionality?
6.
Does the proposed system have any character limitations (i.e., maximum number of characters allowed) for any data fields?
7.
The KSD is responsible for housing federal inmates for multiple federal agencies and, as such, is required to capture unique data fields and generate custom reports frequently. Describe the system’s ability for the agency to modify data fields (i.e., add, delete, and change) as well as generate custom reports. Further, what experience does the Proposer have in agencies that house federal inmates? Lastly, can the JMS create invoices specific to each agency for which inmates are held?
8.
The KSD generates a number of census/daily summary statistical reports that encompass various parameters, including age range, sex, race, and length of stay, among others. Describe the System’s ability to generate these types of reports, including screen shots if possible.
9.
What capabilities does the system provide in tracking inmate movement without the use of standard data entry devices (e.g., bar codes, card swipes, etc.)?
10. Currently the JMS supports two different booking forms, a “long” form which is used by KSD for standard bookings, and an “abbreviated” form used by the Evidence/Identification department that captures a subset of data of the “long” form. Does the proposed JMS system support multiple booking forms? 11. Does the JMS support modifiers (e.g., enhancements) to charges? 12. Describe the system’s ability to automatically generate and print reports on an agency-defined basis. Further are automatic email, print and fax options supported? 13. KSD would like to maintain their current booking numbers. The booking number must remain the same for an individual inmate and the suffix will reflect each booking event. Does the proposed system have the ability to enter an alphabetical character in the booking number and a suffix which identifies each booking event? Proposal Section 7: System Testing and Acceptance 1.
KJS requires a review process to verify the Proposer’s responses to all of the functional requirements and to confirm that the proposed software meets defined user requirements prior to commencing
July 18, 2013
Page 22 of 37
Kenosha Joint Services
Request for Proposals #1314
software implementation. Describe your approach to confirming requirements, determining modifications necessary to meet KJS’s specifications, and then addressing those modifications. 2.
Appendix E outlines Acceptance Test Requirements. Does the Proposer agree to the Acceptance test requirements? Clarify any exceptions. The Proposer must submit an alternative to any exceptions taken.
3.
If the System continually fails during the acceptance test procedures, what type of reimbursement will be provided to KJS?
4.
Describe the remediation process for a testing failure, specifically actions that will be taken by the Proposer (including time frames), as well as its effect on the length of the testing period (e.g., will testing be restarted, paused, etc.).
5.
Provide a comprehensive Acceptance Test Plan that incorporates the requirements listed in Appendix E. KJS will consider as non-responsive any vendor that does not provide an Acceptance Test Plan. Specifically regarding the test plan: a.
How will each of the functional specifications in the RFP will be tracked, documented and tested?
b.
How will interfaces be tested?
c.
How will System reliability be tested?
d.
How will System performance be tested?
e.
How will System integration be tested?
f.
What are the responsibilities (specific tasks) of both KJS and Proposer Personnel?
Proposal Section 8: Implementation and Project Management Project Management 1.
2.
Describe the Proposer’s approach to managing the implementation of the proposed System, addressing at a minimum the following components of project management: a.
Project communications
b.
Schedule management
c.
Issue management
d.
Scope management
e.
Risk management
f.
Quality assurance
Include in this section a Statement of Work that breaks down the System implementation by tasks and delineates Proposer and County responsibilities within each task. Tasks should include configuration, testing and interface development and deployment. Address project management services including creating and maintaining a detailed deployment plan, along with a detailed task list.
July 18, 2013
Page 23 of 37
Kenosha Joint Services
Request for Proposals #1314
3.
Include in this section an implementation project schedule that starts at contract signing. The schedule should describe tasks to be performed by KJS as well as by the Proposer.
4.
How will the Proposer help KJS agencies identify potential changes in business processes because of changes in application software? What specific tasks will be conducted regarding change management?
5.
Though KJS may procure applications from multiple proposals, it is KJS’s intention to work with a single prime contractor responsible for managing the project. Does the Proposer object to serving as either a sub-contractor or prime contractor (provided discussions occur among KJS and each vendor during negotiations)? Project Team
1.
Identify the primary individuals who will be involved in the project and include the resumes of proposed personnel.
2.
Identify a project manager who will be the primary point of contact for the duration of the project through formal project acceptance. Note that this individual must be available for oral interviews.
3.
Any personnel working on the project may be subject to a background investigation before being allowed to work with KJS on the proposed system. Is there any reason that Proposer would object to this condition of the Contract?
4.
Use the Implementation Staffing Form (Appendix A – Form J) to provide a description of County personnel required to implement the proposed system. Legacy Data Access
1.
The CISCO application stores 30+ years of data for KJS and access to this information is of critical importance. How do you propose providing access to legacy data (e.g., data conversion, query-only legacy database, etc.)?
2.
What alternatives are available to KJS? Include any associated costs in the Cost Proposal (Appendix A – Form P).
3.
Does the proposer have any experience in converting legacy data from a CISCO application?
Proposal Section 9: Documentation 1.
Will the Proposer agree to supply comprehensive hard and soft copies of all types of documentation listed in the “Documentation” section of the Scope of Services in this RFP?
2.
Identify any requested documentation that the Proposer does not provide.
3.
Will all documentation be tailored to include County-specific configuration, requirements or functionality developed during the implementation process?
4.
Will the Proposer provide authority to copy documentation for internal use as necessary? State any exceptions.
5.
Is documentation available with upgrades? If so, does the Proposer provide an entirely new set of documentation, or does the documentation reflect only the changes?
July 18, 2013
Page 24 of 37
Kenosha Joint Services
Request for Proposals #1314
Proposal Section 10: Training 1.
Provide a training plan that addresses the training requirements outlined in the “Training” section of the Scope of Services in this RFP.
2.
Use the Training Hours Form (Appendix A – Form K) to provide a description of classes, including: a.
Types of training classes that will be provided and the expected participants (e.g., roles, functional areas)
b.
Number of participants for each class
c.
Prerequisites for all participants
d.
Length of each class in hours
e.
Location (e.g., on-site/off-site) and method of delivery (e.g., classroom, online, etc.)
f.
Total number of trainer hours proposed
3.
Does the Proposer provide refresher training? If yes, describe what refresher training is available. Include the cost of refresher training in the Cost Proposal as an option.
4.
Describe any additional training that is not included but that could be made available. Include the cost of such training in the Cost Proposal as an option.
5.
What level of flexibility will KJS have in determining how to best use the proposed training hours?
Proposal Section 11: Support, Warranty and Maintenance Provisions Customer Support 1.
Describe customer support options that will be provided to KJS, including: a.
Telephone support
b.
Web-based support
c.
On-site support
2.
Are there any conditions with which KJS must comply to receive Customer Support (other than staying current on annual maintenance payments)? If so, please describe.
3.
Does the Proposer support User Groups? If so, describe the user group process as it pertains to future product enhancements. Are there any regional user groups local to the Wisconsin region?
4.
How will the Proposer compensate KJS for failures of the vendor to meet obligated response times for System errors? Warranty
1.
Provide in this section a copy of the Proposer’s standard warranty.
2.
Will the proposed System include a minimum first year warranty commencing at final System Acceptance?
July 18, 2013
Page 25 of 37
Kenosha Joint Services
Request for Proposals #1314
3.
Does the Proposer warrant that the implemented System will conform with its responses to the functional requirements in Appendix B?
4.
Will the Proposer agree to cover expenses to repairs made under warranty, including parts, software, labor, travel expenses, meals, lodging and any other costs associated with the repair?
5.
Will the Proposer cover repair costs for work it is unable to perform based upon warranty guidelines? Software Application Maintenance
1.
Include in this section of copy of the Proposer’s standard maintenance agreement.
2.
What services and products are included the Proposer’s maintenance program. Address specifically:
3.
4.
a.
Customer support provisions
b.
Upgrades, updates, enhancements and fixes
c.
Training
d.
Documentation
e.
Professional services
What is the process for delivery and installation of fixes, upgrades, and new releases? a.
How often does the Proposer provide software updates and enhancements?
b.
How are changes to software tested and documented?
c.
Will interfaces be upgraded along with the standard applications? If so, how will Contractor ensure that interfaces are not broken or compromised?
d.
If customizations are proposed, will they be upgraded along with the standard applications? If so, how will the Contractor ensure that customizations are not lost or compromised?
e.
In order to install system upgrades, fixes, or releases, is vendor involvement required?
Are updates provided to meet changes in federal and state requirements? a.
Is there an additional charge for these updates?
b.
If there additional charges, how are they determined?
5.
How long is maintenance continued for older releases?
6.
If KJS decides to transfer the software onto new hardware, will Proposer charge a fee to install the software on the new hardware?
Proposal Section 12: Contract Provisions 1.
The successful Proposer will be required to sign a contract with KJS that will incorporate the terms and conditions listed in Appendix F. Unless exceptions to KJS’s terms and conditions are noted here, the Proposer is presumed to have accepted those terms and conditions. List any terms to which the Proposer is taking exceptions, and describe the exception taken. Include suggested wording for any exception taken.
July 18, 2013
Page 26 of 37
Kenosha Joint Services
2.
Request for Proposals #1314
Provide a sample contract agreement. Cost Proposal
1.
2.
3.
Submit one (1) original and one (1) copy of the Cost Proposal, as well as two (2) copies in electronic format on a compact disc, flash drive or other portable electronic storage device. The Cost Proposal must be submitted in a separately sealed binder or folder distinctly marked as the Cost Proposal. Failure to submit a separate sealed Cost Proposal will result in disqualification of the entire proposal. Each subsection of the Cost Proposal must be clearly identified and labeled. Please note that:
Proposals must be for a fixed price solution.
All costs for every component referred to in the proposal, including options, must be included in the cost proposal.
Costs must be unbundled and separately listed. Proposals that do not detail specific costs on the provided forms will be considered non-responsive.
The Proposer shall bear the onus of any errors made in pricing the services (e.g., omitting a component of the services).
Should the Proposer have failed to either include in the price, or to deliver to KJS, any component necessary to perform the functionality or provide services as proposed in the RFP, the Proposer shall be required to provide same at the Proposer’s own expense.
The first five (5) subsections require using provided forms to present a detailed breakdown and summary costs by categories for the following proposed System components:
Hardware
System Software
Application Software
Implementation Costs
Optional Costs
The sixth subsection summarizes the total one-time costs and the seventh subsection identifies recurring system costs for five (5) years following System Acceptance. Both require the use of provided forms. Hardware Costs
1.
Using the Hardware Cost Form provided in Appendix A – Form L, list all provided hardware as requested in the “Hardware and System Software” section of the Scope of Services in this RFP.
Include total purchase costs and annual maintenance costs for each hardware item.
The “Annual Maintenance Cost” should represent the average annual maintenance cost for the first five (5) years.
Ensure that all listed hardware is included in the System Diagram. Proposer will be responsible for providing any hardware not accounted for in the Cost Proposal. System Software
July 18, 2013
Page 27 of 37
Kenosha Joint Services
1.
Request for Proposals #1314
Using the System Software Cost Form provided in Appendix A – Form M, list all System software proposed for the system as requested in the “Hardware and System Software” section of the Scope of Services in this RFP.
Include total costs and annual maintenance costs.
The “Annual Maintenance Cost” should represent the average annual maintenance cost for the first five (5) years. Application Software Costs
1.
Using the Application Software Cost Form provided in Appendix A – Form N, list all proposed Application Software. All costs required to provide the software functionality requested in this RFP must be included in these tables. The Proposer will be responsible for any costs not accounted for in these tables.
The Proposer must provide a cost for any proposed software modification required to meet functional requirements. If a cost is not provided, it will be assumed that there is not a cost for the modification. If ultimately there will be a cost, the Proposer will be responsible for that cost.
The “Annual Maintenance Cost” should represent the average annual maintenance cost for the first five (5) years.
All modules included on the Application Software Module Form must be included on the Application Software Cost Form.
All interfaces included on the Interface Identification Form must be included on the Application Software Cost Form. Note that the costs associated with interfaces include all costs associated with the development, testing and deployment of the defined interface. Implementation Costs
1.
Use the Implementation Cost Form provided in Appendix A – Form O to describe and list all other costs that would be associated with implementation of the Proposed System, including, but not limited to the following:
Installation of Hardware/Software
System Integration
Project Management
Training
Data Conversion
Travel
Any other costs (describe)
Optional Costs 1.
Use the Optional Cost Form provided in Appendix A – Form P to describe and list all optional cost items that could be associated with implementation of the System.
Any optional costs to which the Proposer refers in the Functional Proposal must be identified on the Optional Cost Form in order for that option to be considered in the evaluation process. Total One Time Costs
July 18, 2013
Page 28 of 37
Kenosha Joint Services
1.
Request for Proposals #1314
Using the Total One Time Cost Form provided in Appendix A – Form Q, present a summary of all one-time costs for the proposed System. Any subtotals carried forward to this form should agree with the corresponding detail forms. Recurring Costs Summary
1.
Provide a five-year cost schedule that presents the annual cost for maintenance and service warranty.
2.
Using the Recurring Cost Form provided in Appendix A – Form R, present a summary of all recurring costs for the proposed System. Any subtotals carried forward to this form should agree with the corresponding detail forms. Hourly Rates
1.
What hourly rates are proposed as part of this Contract? Note that these rates should be guaranteed for at least three (3) years from date of contract signing. Payment Schedule
1.
2.
KJS expects the following payment schedule outlined below. Does the Proposer accept these terms? a.
10% Upon Approval of Project Plan
b.
15% Upon Completion of Software Installation
c.
10% Upon Completion of Integration Testing
d.
20% Upon Completion of Training
e.
20% Upon Completion of Go Live
f.
25% Upon Final System Acceptance
What are the Proposer’s expected payment terms?
July 18, 2013
Page 29 of 37
Kenosha Joint Services
Request for Proposals #1314
Section III: Special Terms and Conditions A. Vendor Registration: Complete Proposal packages may be downloaded at the Kenosha County Purchasing Division website at http://www.co.kenosha.wi.us/index.aspx?nid=109. Kenosha County has implemented an on-line vendor registration process. To view and download this proposal opportunity and all related documents, vendors must register with the County and select the commodities that they would be interested in proposing. There is no fee to register. If you do not have internet access, contact this office for a hard-copy of this proposal. Once a vendor’s registration is accepted by the County, an email will be sent to the email address provided and will include a new User ID and Password for the system. When a proposal is issued for a commodity a vendor has registered for, an email announcement may be sent to the email address that was provided during the registration process. Whenever new documents are added to that proposal or RFP, another email notification may be sent. Kenosha County does not warrant or guarantee that any email notification will be sent from this system for any solicitation or received by any vendor’s email system. Certain spam filters or virus software may block email from Kenosha County to a vendor’s system. It is the vendor’s sole responsibility to check the website frequently during the proposal process to ensure they have received the most current documents and any addenda. Vendors are responsible for updating the information they provide to the County. Kenosha County is not responsible for any information provided to us by any vendor. Please read the “Terms and Conditions of Use” document when registering. The website and registration process is for the purpose of downloading and viewing proposal documents only, no electronic submission of proposals is acceptable. All proposals must be submitted in hardcopy in a sealed container and delivered as stated in the proposal document. Kenosha County does not guarantee continuous, uninterrupted or secure access to our website. From time to time, the operation of this site may be affected by numerous factors outside of our control. In the event of a County system failure that interferes with the ability of any user of this website to access or submit any proposal or proposal documents, Kenosha County may, upon being notified of such system failure, cancel the RFP or may extend the date and time for receipt of the proposal or proposal, at the sole discretion of the Kenosha County Purchasing Director. B. Third Party Proposal Services: Kenosha County is not responsible for the content of any proposal package received through any third party or proposal service. It is the sole responsibility of the vendor to ensure the completeness of the documents received through any third party source. C. Prices: Proposal prices must be in US dollars, complete and inclusive of all charges at the time of submission. Vendor is responsible for all delivery charges, freight, importing/exporting fees and services, tariff charges, licensing, or any other fees associated with this project. D. Contract: The contract for this project will consist of this Request for Proposals document (including Appendices), the specification documents and any associated exhibits, drawings, or additional documents, the contractor’s proposal response with all required forms, any addenda that may be issued, and any negotiated terms and conditions that will be included in a final contract.
E. Non-Mandatory Pre-Proposal Conference:
July 18, 2013
Page 30 of 37
Kenosha Joint Services
Request for Proposals #1314
A non-mandatory pre-proposal conference will be held at 9:00 AM on August 15, 2013. The County shall have key personnel in attendance to answer questions and discuss issues that may arise. In order for questions to be answered at the Conference, they should be submitted via email to
[email protected] by 4:00 PM local time on August 2, 2013. Questions not submitted in advance may be asked at the Conference, but may or may not be answered at the Conference itself. The County does not intend to issue minutes or notes from the Conference. However, written clarifications or addenda deemed necessary by the County will be posted on the County Website. It is the obligation and responsibility of the Proposers to acknowledge any addenda issued by the County as a result of the Conference. Proposers should note that only the County’s written answers provided after the Conference will be binding. These answers shall represent the Countys official position and will supersede any previous oral statements made during the Conference or at any time by County personnel. Following the pre-proposal conference, Proposers may submit follow-up questions until 4:00 PM local time on May 28, 2013. F. Calendar of Events: This calendar is subject to change at the sole discretion of Kenosha County. All attempts will be made to adhere to this calendar. However, due to circumstances beyond our control, it may be necessary to modify the events and/or dates and times. EVENT RFP Issued Deadline for Questions for Pre-Proposal Conference Pre-Proposal Conference Deadline for Questions or Requests for Clarification Proposals Due
DATE July 18, 2013 August 2, 2013 August 15, 2013 August 16, 2013 September 12, 2013
G. Right of Rejection: The County of Kenosha reserves the right to reject any or all proposals, any portion of a proposal and to accept the proposal considered most advantageous to the County of Kenosha following final negotiations, evaluations and review. The County of Kenosha does not warrant or guarantee that a contract will be awarded as a result of this Request for Proposals. H. Prices to be Firm: Proposer certifies that prices, terms and conditions in the proposal will be firm for acceptance for a period of 180 days from the date of opening unless otherwise stated by Kenosha County. Proposals may not be withdrawn before the expiration of (90) days. Prices shall be firm with no escalator clauses unless specified by Kenosha County. Proposals may be withdrawn after 180 days only upon written notification to Kenosha County. I.
Instructions to Vendors: 1)
Thoroughly examine the scope of work, schedule, instructions and all other solicitation documents.
2)
Make all investigations necessary to be familiar with conditions that affect the proposal, such as but not limited to, facilities for delivery of material and equipment. No pleas of ignorance by the proposer as a result of failure to investigate or examine conditions or failure to fulfill details of the contractual documents will be accepted as a basis for varying the requirements of the County or changing the compensation due.
3)
Kenosha County contracts are subject to all legal requirements of county, state or federal statutes and regulations. Laws of the State of Wisconsin apply.
July 18, 2013
Page 31 of 37
Kenosha Joint Services
J.
Request for Proposals #1314
4)
Provide all required information on the forms furnished in this document where applicable. Print or type name on proposal and manually sign all copies in the space and on the forms provided. If you obtained this solicitation electronically, your response shall not contain any alteration to the document posted other than entering required data in the spaces provided or including attachments as necessary. By submission of a response, offeror affirms that no alteration of any kind has been made to this solicitation.
5)
Provide all requested unit prices and extension prices. Where there is disagreement in the unit and extension prices, the unit price shall govern.
6)
Do not include federal taxes or State of Wisconsin taxes in proposal prices since the County of Kenosha is exempt from payment of these taxes.
7)
All proposals must be current and final at the time of opening in order to be considered responsive. No proposal will be accepted for consideration, and no award will be made, if at the time of opening anything contained therein is contingent upon, or subject to, any outstanding matter, including, but not limited to, any review, certification, or approval by any party that has not been received.
Contact Person: The County Purchasing Director (or designee) shall act as the county representative in the issuance and administration of this RFP and contract, and shall issue and receive all documents, notices, and correspondence pertaining to this RFP. Such documents, notices, and correspondence not issued by or received by the County Purchasing Director (or designee) shall be null and void. Any questions regarding this RFP process must be submitted via e-mail to: Carol J. O’Neal, Director Kenosha County Purchasing Division
[email protected] Telephone: 262-653-2605 No other employee or representative of Kenosha County is authorized to interpret any portion of this document or give information as to the requirements of this Request for Proposals in addition to that contained in or amended to this written document. Proposers are instructed not to contact any other county department, elected official or employee regarding this RFP. Any unauthorized contact regarding this RFP to any County employee or official may be cause for rejection of a proposal, at the sole discretion of the County. Questions received by the due date listed in the Calendar of Events will be answered via addendums that will be posted on the County website. Answers to questions from any proposer will be provided to all proposers on the vendor list. No verbal or written information, which is obtained other than through this Invitation to Propose or its addenda, shall be binding on the Consortium. Vendors are expected to raise any questions, exceptions, or additions they have concerning this proposal document as soon as possible during the proposal process.
K. Confidentiality/Non-Disclosure: All proposals received will remain sealed and confidential until the date/time listed for the public opening. At the public opening, only the name of the proposing firm will be released, no other information will be provided until evaluations are complete. Once the process is complete, no information submitted as a part of this RFP process shall be considered proprietary or confidential unless claimed as a trade secret on the enclosed form “Designation of Confidential and Proprietary Information” (see Appendix D). By submitting a proposal, vendors acknowledge that the County may be required under the law to make its records available for public inspection. All Vendors acknowledge and agree that the County will have no obligation or any liability to the Vendor in the event that the County must disclose these materials.
L. Errors or Omissions:
July 18, 2013
Page 32 of 37
Kenosha Joint Services
Request for Proposals #1314
If a vendor discovers any significant ambiguity, error, conflict, discrepancy, omission, or other deficiency in this proposal, the vendor should immediately notify the above named individual of such error and request modification or clarification of the RFP document. The County of Kenosha reserves the right to permit cure of, or waive as an informality, any irregularities or technicalities contained in any proposal submitted, at the sole discretion of the County of Kenosha, provided such waiver does not substantially change the offer or provide a competitive advantage to any other vendor. Contracts will be awarded in the best interests of the County of Kenosha.
M. Public Notice Regarding Ethics Compliance: Any vendor submitting a proposal to Kenosha County must sign and submit the attached Ethics Compliance Statement with their proposal (see Appendix D). Failure to submit this signed statement may be cause for rejection of an offer.
N. Addenda: Changes to this RFP will be made only by formal, written addendum issued by Kenosha County’s Purchasing Division and posted at the County’s website. Any and all addenda issued as part of this RFP shall become part of the specifications of this RFP and will be made part of the contract. It is the vendor’s responsibility to check and assure receipt of any and all addendums.
O. RFP EVALUATION CRITERIA: All proposals received will be evaluated by a selection team that consists of Consortium representatives (“Evaluation Committee”). In evaluating proposals, the Evaluation Committee will use the following criteria in making the selection:
Experience and Resources (5 – 15 points)
Contract Compliance (5 – 15 points)
Hardware Design and System Architecture Approach and Security (5 – 15 points)
Application Software and Integration (25 – 50 points)
System Testing and Acceptance (5 – 15 points)
Implementation and Project Management (5 – 15 points)
Training and Documentation (5 – 15 points)
Customer Support, Warranty and Maintenance (5 – 15 points)
Cost Proposal (15 – 50 points)
P. Selection Process Responsive proposals will be scored in each of the criteria above and ranked accordingly. The County reserves the right to conduct such investigations as the County considers appropriate with respect to the qualifications of each respondent and any information contained in the proposal. The County reserves the right to verify the information submitted in the proposals. If a Contractor knowingly and willingly submits false information or data, the County reserves the right to reject that proposal. If it is determined that a contract was awarded as a result of false statements or other data submitted in response to this RFP, the County reserves the right to terminate the contract.
July 18, 2013
Page 33 of 37
Kenosha Joint Services
Request for Proposals #1314
After the proposals are initially evaluated, the Evaluation Committee may decide to invite parties to make a formal presentation to the County and the Evaluation Committee. Additionally, the Evaluation Committee may:
Contact officials from other jurisdictions regarding the proposing party, its prior work experience and its ability to successfully complete the scope of services
Conduct site visits to verify system operations and garner additional information regarding the proposing party and its proposed system
Request clarification or additional information from a proposing party in order to assist in the evaluation process
Require changes in the scope of services, as deemed necessary by the Selection Committee, before Contract execution
Request a final meeting with finalist vendors to review proposals and clarifying outstanding issues
Once chosen, the Contractor shall then be required to negotiate the final terms and conditions of a contract and provide all documentation required. In the event the Contractor does not execute the contract as herein required, the award of the contract may then be made to another Contractor or the County may decide to call for new proposals. Any contract resulting from this RFP process may be subject to final approval by the Kenosha County Board or an appropriate committee of the Board. Immediately after the notice of award, the successful Contractor and the County’s project manager for this project shall begin planning in conjunction with the County’s staff to insure fulfillment of all obligations.
Q. Assignment and Subcontracting: The selected Contractor will not be permitted to sublet, sell, transfer, assign or otherwise dispose of the contract or any portion therein, or its right, title or interest in, to any person, firm or corporation without the written consent of Kenosha County. If Kenosha County permits the use of subcontractors, the following will apply: 1)
The contractor is the prime vendor. A prime vendor is the vendor who provides a service and receives a payment for that service. The County considers the prime vendor to be the sole point of contact with regards to contractual matters, including the performance of the services and the payment of any and all charges resulting for contractual obligations.
2)
The prime contractor will be responsible for the contract performance when subcontractors are used. However, when subcontractors are used, they must abide by all terms and conditions of the contract. If subcontractors are to be used, the contractor must clearly identify the subcontractor including length of time the subcontractor has been used by the prime contractor and other projects.
3)
The prime contractor shall provide the County with the names of any subcontractors used for the performance of any part of this contract. The existence of the subcontractor does not relieve or reduce the prime contractor of any liability to the County for any breach in the performance of the prime contractor’s duties. The prime contractor agrees that all subcontractors shall be agents of the prime contractor and the prime contractor agrees to hold harmless hereunder for any loss or damage of any kind occasioned by the acts of omissions of prime contractors, subcontracts, their agents or employees.
R. No Reimbursement for Expense of Proposals: Kenosha County will not reimburse vendors for any costs associated with the preparation and submittal of any proposal, nor for any travel and/or per diem costs if any are incurred.
July 18, 2013
Page 34 of 37
Kenosha Joint Services
S.
Request for Proposals #1314
Vendor Responsibility: A proposal may be rejected if a proposer fails to meet any one of the following qualifications: 1) Responsibility Questionnaire: To be considered a responsible vendor, a company or individual should have appropriate legal authority to do business in the State of Wisconsin, a satisfactory record of integrity, appropriate financial, organizational and operational capacity and controls, and acceptable performance on previous contracts, if any. i. Vendors submitting responses to this invitation are required to complete and submit the attached Vendor Responsibility Questionnaire (Appendix G). The completed questionnaire will be evaluated by the Consortium or its contractor and responsibility determinations will be made by the Consortium. The Consortium reserves the right to disqualify a vendor based on previous violations of Federal, state or local law and / or any other information obtained from this questionnaire. Providing false, misleading, incomplete or inaccurate information is grounds for disqualification. ii. Vendors may be required to submit additional information upon request. 2) Financial and Organizational Capacity: Factors to be considered include, but are not limited to, assets, liabilities, recent bankruptcies, equipment, facilities, personnel resources and expertise, availability in consideration of other business commitments, or existence of appropriate accounting and auditing procedures for control of property and funds. 3) Legal Authority: Factors to be considered include authority to do business in the State of Wisconsin, licensing, debarment by the State of Wisconsin or Federal Government due to a prevailing wage violation, OSHA violations, violations of other local, state or Federal law, etc. 4) Integrity: Factors to be considered include, but are not limited to, criminal indictments or convictions, civil fines and injunctions imposed by governmental agencies, anti-trust investigations, ethical violations, tax delinquencies, debarment by federal, state or local governments, or prior determinations of integrity-related non-responsibility. 5) Previous Contract Performance: Factors to be considered may include reports of less than satisfactory performance, early contract termination for cause, contract abandonment, court determinations of breach of contract, etc.
T. Indemnity and Insurance Requirements: A proposal may be rejected if a proposer fails to meet any one of the following insurance requirements: 1) Contractor agrees to indemnify, hold harmless and defend Kenosha County, its officers, agents and employees from any and all liability including claims, demands, losses, costs, damages and expenses of every kind and description or damage to persons or property arising out of or in connection with or occurring during the course of this agreement where such liability is founded upon or occurring out of the acts or omissions of the Contractor, its agents or employees. 2) Contractor agrees to protect itself and Kenosha County under the indemnity agreement set forth in the above paragraph. Contractor will at all times during the terms of this Contract keep in force and effect commercial general liability, professional liability, contractor’s environmental liability, automobile liability, excess/umbrella liability, worker's compensation, and employer’s liability insurance policies issued by a company or companies rated A- VII or better by AM Best and authorized to do business in the State of Wisconsin with the following minimum limits of coverage; a)
July 18, 2013
Commercial General Liability * i. Each Occurrence $1,000,000 ii. General Aggregate $2,000,000 iii. Products - Comp/Op Agg $2,000,000
Page 35 of 37
Kenosha Joint Services
b) Professional Liability* c)
Automobile Liability i. Combined Single Limit
d)
e) f) i. ii. iii. g)
Request for Proposals #1314
$1,000,000
$1,000,000
Excess/Umbrella Liability ii. Each Occurrence iii. Aggregate
$1,000,000 $1,000,000
Worker’s Compensation
Statutory Limits
Employer’s Liability* Each Accident Disease Each Employee Disease Policy Limit
$100,000 $100,000 $500,000
Cyber Security Liability Provide documentation of any additional first and third party cyber security liability coverage that will apply to this contract.
*Or such higher limits sufficient for these insurance policies to be scheduled under the Umbrella policy. 3) Coverage afforded shall apply as a primary with Kenosha County named as an additional insured on the commercial general, contractor’s environmental liability and excess/umbrella liability policies. Contractor shall give 30 days advance written notice of cancellation or non-renewal during the term of this Contract. 4) Contractor shall not discontinue or change liability insurance policies in effect during any part of this contract without buying “tail end” insurance to cover potential claims that may have occurred during the term of this agreement. The hold harmless, indemnity and insurance provisions of this contract shall survive the termination of this contract and shall remain operative until the time that all potential claims or potential civil actions by the parties or by third parties shall expire under existing law. 5) Prior to execution of this Contract, the Contractor shall furnish Kenosha County with a certificate of insurance showing evidence of the above requirements. Certificate must be submitted to Kenosha County within four (4) business days after notification of award. If certificate is not submitted within four (4) business days, Kenosha County, at its sole discretion, may void the contract and award to the next low, responsive and responsible bidder. 6) Contractor shall notify Kenosha County immediately upon the commencement of any litigation against Contractor where there is any possibility Kenosha County may be made a party thereto.
U. Change Orders: County shall have the right at any time during the progress of the Work to increase or decrease the Work. Promptly after being notified of a change, Contractor shall submit an itemized estimate of any cost or time increases or decreases it foresees as a result of the change. Except in an emergency endangering life or property, no addition or changes to the Work shall be made except upon written order of County, and County shall not be liable to the Contractor for any increased compensation without such written order. No officer, employee or agent of the County is authorized to direct any extra or changed work orally. A Change Order, in a format acceptable to both the County and the Contractor, shall be issued and executed promptly after an agreement is reached between Contractor and the County concerning the requested changes. All change
July 18, 2013
Page 36 of 37
Kenosha Joint Services
Request for Proposals #1314
orders shall be incorporated into the contract. Contractor shall promptly perform changes authorized by duly executed Change Orders. The Contract Amount and Contract Time shall be adjusted in the Change Order in the manner as County and Contractor shall mutually agree. V. Payments:
1) METHOD OF PAYMENT: The method of payment will be at the County's sole discretion using any of the following methods: i. By warrant (check); ii. The County's credit card – otherwise referred to as “payment card” or “P-Card”; iii. Automated Clearing House (ACH); 2) The pricing submitted by the vendor and accepted by the County is inclusive of applicable payment terms, as well as any and all fees incurred by the vendor through their financial institutions in accepting any of the above referenced payment methods. No additional fees or charges to the County shall apply, unless otherwise preapproved by the County. Additionally, unless otherwise set forth in the Contractor’s proposal, quote, submittal, and unless accepted by the County in the contract, all payments shall be made in arrears and with payment terms of "Net 30 Days" from the date that the County receives a correct and accurate invoice. An accurate invoice must, in part, reference a valid County contract/agreement or purchase order number. 3) Payments will be made along the following payment schedule: •
10% Upon Approval of Project Plan
•
15% Upon Completion of Software Installation
•
10% Upon Completion of Integration Testing
•
20% Upon Completion of Training
•
20% Upon Completion of Go Live
•
25% Upon Final System Acceptance
4) If a purchase order has been issued as a result of this RFP, the purchase order number must appear on all invoices.
July 18, 2013
Page 37 of 37
