20-6009 RFI.docx

RFI #20-6009

UNIVERSITY OF WISCONSIN

MADISON, WI 53715

RFI #20-6009

UNIVERSITY OF WISCONSIN

MADISON, WI 53715

RETURN TO:

University of Wisconsin-Madison Purchasing Services 21 N Park St., Ste 6101 Madison, WI. 53715 1218 bids@bussvc.wisc.edu

INSTRUCTIONS

This original Request For Information form must be completed, signed and returned to:

Via US mail or personal delivery: Purchasing Services, 21 N Park St, Suite 6101, Madison, WI 53715-1218

Via email: bids@bussvc.wisc.edu

All correspondence must reference the RFI number 20-6009.

REQUEST FOR INFORMATION

THIS IS NOT AN ORDER

For further information contact:

RFI NUMBER: 20-6009

NO PUBLIC OPENING

ISSUE DATE: August 29, 2019

DUE DATE: September 30, 2019 2:00 PM CDT RFI MUST be date and time stamped in this office before due date and time shown.

BRAD BAUMAN

E MAIL: brad.bauman@wisc.edu

If NO RESPONSE (check here) and return.

The University of Wisconsin-Madison Purchasing Services Department (Purchasing) requests information for Enterprise Access Control Solution.

This Request for Information (RFI) is issued solely for information and planning purposes, and does not constitute a solicitation. Responses to the RFI will not be returned. Responses to this RFI are not an offer and cannot be accepted by the State to form a binding contract. The State of Wisconsin is not liable for any cost incurred by the vendor in response to this RFI.

Quotes may be requested at a later date.

Responses must be submitted in the same format as the specifications attached.

COMPANY NAME:

COMPANY ADDRESS:

SIGNATURE: DATE :

TYPE OR PRINT NAME: TITLE:

TELEPHONE NUMBER: ( ) FAX NUMBER: ( )

FEIN NUMBER: EMAIL ADDRESS:

1.0 Purpose of Request for Information:

The University of Wisconsin – Madison (UW-Madison) has provided the following Scope of Work document in order to provide each bidder with specific and relevant background information related to this Request for Information (RFI) document.

UW-Madison is requesting information to solicit feedback from access control system hardware / software manufacturers, vendors, and integrators in an effort to gather ideas and recommendations for replacing UW-Madison’s existing access control system, Schneider Electric’s Andover Continuum electronic access control system. UW-Madison is looking for a system that supports an “open architecture” for hardware such as Mercury Security hardware or comparable and also an “open architecture” software to integrate with other systems such as CCTV, Security systems, and biometric access control systems to automate door access.

We want to identify potential solutions that provide better business value, resiliency, simplified operations, management, software integrations and support. This should result in potentially lower Total Cost of Ownership (TCO), providing flexibility for growth and stability for future operations without being locked into one vendor. We are looking for a total solution provider, not just another manufacturer or vendor.

2.0 Background and Current Operation:

UW-Madison currently uses Schneider Electric’s Andover Continuum product for access control, which supports several federally regulated research facilities, as well as general campus facilities, on two separate networks. This system has been in place for over 15 years. The main system currently supports over 4700 doors, and the system continues to grow. In addition, several areas use Schlage NDE/LE standalone wireless locks programmed by smartphone or use AD400 standalone or wireless locks to Andover with security modifications to work on that system. Additionally, several departments on campus user their own standalone electronic access control systems. Our goal is to migrate these disparate campus systems into a singular new system; thus, unifying our electronic access control systems to one central electronic access control system (and if required, a second instance of the system running on a separate network to meet federally regulated research facility security requirements). Security video uses Milestone and currently does not integrate with the Andover system.

3.0 Vendor Response:

Response in General Please respond to the following sections. Limit your response to 40 pages.

Company Information Please provide information about your company or organization including:

· The scope of relevant products and services your company provides.

· Contact name(s) and information for questions UW-Madison may have regarding your company’s responses to this RFI.

· Company’s experience with university clients of a similar size or government clients of similar size and complexity, including experience working with federally regulated research spaces to meet security requirements.

Product Information Please provide information regarding your solution below. If you have other information you would like to share that pertains to your proposed solution that was not mentioned in this document, feel free to provide it in your response.

Does your system use “open architecture” hardware? If so, what manufacturers? Please provide a reference architecture.

3.1.2 Hardware Support

What generations of this manufacturer's hardware is your software written to support?

3.1.3 How Long

How long have you been supporting this manufacturer’s hardware?

3.1.4 Open Architecture Software

Does your system use “open architecture” software? If so, please explain.

3.1.5 System Compatible

Is your system compatible with all card technologies (i.e., mag strip, prox cards, smart cards and multi-technology, cards such as: HID SEOS, HID iClass SE/SR and HID Proximity, Aptiq MIFARE, Aptiq DESFIRE EV1, XceedID Prox, Identiv, Unprogrammed MIFARE, Unprogrammed DESFire EV1, and others not listed)? Please explain.

3.1.6 System Redundancy

Please describe how your system supports redundancy to ensure continued operations and data access, and if you have specific recommendations for redundancy.

3.1.7 Price Structure

Please describe your pricing model including ongoing support and maintenance, and one-time or recurring options such as implementation, training, or other professional services.

3.1.8 Scalability

Please describe the scalability of the system to grow as more electronic access control points are added including both wired and wireless electronic access control solutions.

3.1.9 Overall Architecture

Please provide a diagram of the overall architecture of the system components and data flow. Please clearly denote which components are included in the base package and which are optional add-on modules.

3.1.10 On Premise or Hosted Solution

Do you provide a hosted or SaaS option, or customer premise installation? Which do you recommend for an organization of our type and why? If hosted or SaaS is available, please provide a SOC 2 Type 2 report.

Does your company require customers to sign a software maintenance agreement? Please include a sample.

3.2.2 Software Upgrade

Describe your software upgrade program. How does it work?

3.2.3 Included

Describe what is included in your base software package.

3.2.4 Excluded

Describe what is not included in your base software package? List out all of the optional available modules or software add-ons.

3.2.5 Components

Please describe any license fees you have for readers, Cameras, DVRs, NVRs, including anything that is attached to the system.

3.2.5.1 Components

List the components that result in charges.

3.2.6 Virtual Server Environment

Does your software support a Virtual Server environment for the server software? If so, what virtual environments do you support, please list? If you license by core or CPU, how do you address subcapacity use for license compliance purposes?

3.2.7 Active Monitoring

Describe your software’s active monitoring for doors, cardholders, etc.

3.2.8 Alerts

Does your software send alerts via alarms, emails, text messages or other formats? Please describe, including what information is provided in an alert?

3.2.9 ADA, Fire Code and Building Code requirements

How does your product meet ADA, Fire Code and Building Code requirements?

3.2.10 Threat Levels

What threat levels (e.g. lockdown, zone lockdown, lockout or the ability to override schedules, etc.) does your product support?

3.2.11 Inclement Weather Day

How easily is an inclement weather day scheduled with your system? Please explain how your system handles emergent schedule changes such as an inclement weather day.

3.2.12 System Use Microsoft SQL

Describe what SQL systems your product supports. Which database(s) will your system run on? Please detail the version(s) that can be used. (MS SQL Server, Oracle, etc.)

Do you host instances of your solution for client use, or do clients supply the environment to run the solution?

3.2.13.2 Database Communication

Please explain ways clients can read data in order to interface to other systems.

3.2.13.3 Database Training Support

Please explain the level of support for clients to learn and use the database.

3.2.13.3.1 Data Dictionary

Will you provide a data dictionary?

3.2.13.3.2 Data Transfer

Do you offer a library of API functions or web services to insert/retrieve data from your solution?

3.2.14 Database Schema

Upon request, will you be able to provide a database schema so we can pull data with read access to integrate into our GIS System and Key Application? Please explain.

3.2.15 Alarms

Regarding alarms, can your system deliver them to workstation, emails, texts, or third party central management systems? Please explain.

3.2.16 Licensing - Perpetual or Subscription

Explain what kind of licensing you offer (perpetual, subscription, etc.).

Do you support OSDP security from the door controller to the reader? Please explain.

3.3.2 Support Two-Factor Authentication

Does your system support two-factor authentication for Web Client or Mobile app? Does your system support Duo? Please describe.

3.3.3 Support SAML / Shibboleth

If you support SAML / Shibboleth for authentication, please explain?

3.3.4 Certifications and Industry Standards

Is your system software certified and does it meet industry standard security requirements? Please explain. Provide a STIG (Security Technical Implementation Guide) for any standards you meet.

3.3.5 User Roles and Permission Levels

Describe the standard and customizable, if possible, user roles and permission levels in the system.

3.5.1.1 Additional Integrations

Please describe other systems (e.g. residence hall management software (Star Rez), membership software, etc.) you have the established ability to integrate.

3.5.4.1 If Yes for API

If yes for API, is it bi-directional? Please explain.

3.5.5 Blackboard

Does your software handle Blackboard – meeting & room scheduling? Please explain.

3.5.6 Download Documentation

Do you allow supported end users to download documentation, software updates, upgrades, and any other setup files? Please explain.

3.5.7 Active Directory

How does your software integrate with Active Directory for user authentication?

3.5.8 Software Integration with BACnet Protocol

How does your software integrate with the BACnet protocol?

3.6. Support:

Detail what is included: Phone, Email support, after-hours support, response for a trouble ticket response. Include standard SLA’s or support tier packages you offer.

3.6.1 Direct Support Agreement

Does your company offer a “Direct Support Agreement”? Please describe or attach a sample.

3.6.2 Technical Support

Please describe what online technical support, help desk, or knowledge base you offer.

3.6.2.1 Support Options

Provide a list what you offer for these services.

3.6.2.2 On-site Support

Do you provide on-site support on demand to resolve critical issues? Is on-site support included in your support plans or based on time and material?

3.7. Software:

3.7.1 Schedules

3.7.1.1 Schedules Previewed

Describe how your software is able to preview schedules quickly.

3.7.1.2 Schedule Holidays or Special Event

Describe your software’s ability to schedule holidays or special events.

3.7.1.3 Schedule Holidays or Special Events - Individual

Describe your software’s ability to schedule holidays or special events individually.

3.7.1.4 Schedule for Holidays or Special Events - Global

Describe your software’s ability to schedule holidays or special events globally without impacting existing schedules that would be exempt to the exception.

3.7.1.5 Schedule in Advance

For schedules, describe your software’s ability to schedule in advance for the following:

A. Weeks B. Months C. Years

3.7.1.6 Where Does Scheduling Reside

Describe where scheduling resides.

3.7.1.7 Schedule Controlled by Server or Building Controller

Please describe how the schedule is controlled by server and/or building controller.

3.7.2 Maps Function

Does your software have a maps function or customizable function to pull object(s) information such as door statuses, and the ability to create buttons to control input / outputs or open specified objects? Please explain.

3.7.3 Custom Fields: Cardholder, Cards and Doors

Please describe how your software supports custom fields for:

A. Cardholder B. Cards C. Doors

Does your software have the ability to run reports? Please explain.

3.7.4.2 Report Development and Export

Explain the interface for defining/developing reports and the available methods for exporting information.

3.7.4.3 Report Types

Describe the types of standard reports available in the system.

3.7.4.4 Run Reports Automatically

Describe the ability to schedule reports to run automatically to send to designated email addresses.

3.7.4.5 Oracle Data Objects

What ability does your product have to read native Oracle data objects?

Does your software have any analytics built in to alert for: x number of invalid attempts by an individual within a time frame globally or by designated areas that may be deemed high security? Please describe.

3.7.5.2 Analytics for Alerts

If yes, can alerts for activity or no activity detected from previous access patterns for individuals, dates, or time of day be sent? Please explain.

3.7.6 Importing and Updating

Please explain how your software allows importing and updating of cardholders?

3.7.6.1. Supported Imports

What kind of imports do you support?

3.7.7 Support Automated Door / Reader Access

Does your software support automated door / reader access by adding, replacing, or deleting based on updates from importing? Please explain.

3.7.8 Card Profile(s)

Can cardholders have more than one card attached to their profile, or are cardholders and cards separated in the system? Please explain.

3.7.9 Temporary Access

How can temporary access be granted for specific cardholders and doors?

3.7.10 Access Control Schedule

How can access be controlled by a schedule for specific days and time for cardholders?

3.7.11 Full Client Install

Does your software have a full client install? Please describe.

3.7.12 Web Client

Does your software have a web client? Please describe.

3.7.13 Operating Systems Supported

What operating systems are supported with your client?

3.7.14 Mobile App

Does your software have a mobile app? Please describe.

3.7.14.1 Mobile Operating Systems Supported

If so, what mobile operating systems are supported?

3.7.15 Customized for Full

How can the client layouts be customized for the following: Full?

3.7.16 Customized for Web

How can the client layouts be customized for the following: Web?

3.7.17 Full Client on Multiple Monitors

Does the full client support multiple monitors? Please explain.

3.7.18 Software Functionality

Describe what software functionality stands out from other solutions.

3.7.19 GIS

GIS (Geographic information System mapping technology) – can door status, schedules, and access events be viewed by GIS? Please describe.

3.7.20 Data Retention

How long is data stored in the system – if dependent on type of data, describe how long each type of data is or can be held (e.g. reports, alarms, access events, users, updates, system change documentation, etc.)

3.7.21 Data Storage

Where is the data stored (cloud, University servers, etc.)? If data is stored in the cloud, are we able to retrieve the data from the cloud if we change providers for any reason?

Does your solution have the ability to import badge layouts from EPI Suite Software?

3.7.22.2 User Design, Experience & Accessibility

Please describe how you incorporate user design, user experience, and user accessibility principles and features into your product.

3.7.22.3 Encryption

Does your solution have the ability to encrypt the ABA strip?

3.7.22.4 Barcodes

Does your solution have the ability to add a barcode to a badge layout?

Describe the solution you can provide that will support our existing door hardware or an equivalent.

3.8.2 Existing Door Hardware Support

Reference the attached PDF file (Existing University Door Hardware) and list out which electrified door hardware you can support or if you cannot.

3.8.3 Door Hardware ADA

How does your hardware follow ADA regulations?

3.8.4 Hardware Warranty

Describe the length of the hardware warranty and what is covered?

3.8.5 Trade-in or Buy Back Program

Do you provide a trade-in or buy back program for our existing building and door controller hardware? If yes, please explain.

3.8.6 Building Controllers

How many building controllers can your system support? Are there limitations with how many building controllers based on the different models?

3.8.7 Door Controllers

How many door controllers can a building controller support? Are there limitations with how many door controllers based on the different models?

3.8.8 Inputs / Outputs

How many door inputs / outputs do your door controllers support?

3.8.9 Power Requirements

Are there any special power requirements for your building and door controller components solutions? If yes, please explain.

3.8.10 Battery Backup

Does your solution provide battery backup for door/building controllers to continue working during a power outage? Please describe.

3.8.11 Battery Backup Duration

If your solution provides battery backup, what is the expected duration/number of openings during a power outage?

3.9. Implementation Progress & Status Reporting:

The University requires regular status reports on the project timeline, implementation progress, and delays from the vendor. Please provide an example of your status reporting process and supporting documentation.

3.10. Other Emerging Issues or Technology:

How do you see the future of electronic access control systems? Please illustrate how your solution will embrace what is to come in the near and medium term, and expand on how we shall prepare for future advances in technology.