University of Wisconsin - Madison

idleheadedceleryMobile - Wireless

Dec 10, 2013 (3 years and 4 months ago)

128 views


University of Wisconsin
-

Madison


REQUEST FOR PROPOSAL


THIS IS NOT AN O
R
DER



OFFICIAL SEALED


PROPOSAL

NUMBER:

13
-
5399




NO PUBLIC OPENING


ISSUE DATE:

02/21
/13



DUE DATE:


0
3
/
11
/13

2:00 PM
C
D
T



AGENT:


Carl Hubba
rd


Questions regarding this
proposal


see
Section
2
.
6


For Submittal Instructions

& Proposal Response
Format



see Section
s

2.2 and 2.3
.



Proposal

prices and terms shall be firm for sixty (60)
days from the date of
proposal

opening, unless
otherwise
specified in this Request for
Proposal

by the
UW
-
Madison Purchasing Services.


If
NO BID

(check here)


and return.

13
-
5399 / AMENDMENT #1 / INFORMATION TECHNOLOGY SERVICE MANAGEMENT TOOL


Amendment #1 issued to:

(
1
)
r
eplace questions 4.1.4
(Page 13)

and 4.5.3

(Page 15)
;
(
2
)
r
evise Pricing Instructions, Attachment B;
(Page 27);
(
3
)
r
eplace Cost Proposal Form, Attachment B

(Page 28)
;

(4
)
a
nswer written questions submitted;

and

(
5
)
e
xtend the
due date to March 11, 2013
.
We have enclosed a new return la
bel for your convenience.
Please replace the following pages
reflecting the new DUE DATE: Pages
4

and
5

of
44.



If this amendment is not returned, it shall be assumed your original proposal meets all conditions of the amendment.


All other terms and con
ditions remain the same. Please revise and submit your proposal accordingly.

In signing this proposal, we have read and fully understand and agree to all terms, conditions and specifications and acknowl
edge that the
UW
-
Madison
Purchasing Services propo
sal document on file shall be the controlling document for any resulting contract.

We certify that we have not, either directly or
indirectly, entered into any contract or participated in any collusion or otherwise taken any action in restraint of free co
mpetition; that no attempt has been made
to induce any other person or firm to submit or not to submit a proposal; that this proposal has been independently arrived a
t without collusion with any other
proposer, competitor or potential competitor; that this

proposal has not been knowingly disclosed prior to the opening of proposals to any other proposer or
competitor; that the above stated statement is accurate under penalty of perjury.
I certify that the information I have provided in this proposal is true

and I
understand that any false, misleading or missing information may disqualify the proposal.


By submitting a proposal, the proposer certifies that no relationship exists between the proposer and the University that int
erferes with fair competition or
is a
Conflict of Interest, and no relationship exists between such proposer and another person or firm that constitutes a Conflict

of Interest.
Further, proposer certifies
that no
employee of the University whose duties relate to this request for proposal
assisted the proposer in preparing the proposal in any way other than in his
or her official capacity and scope of employment.


The Proposer certifies by submission of the proposal that neither it nor its principals is presently debarred, suspended, pro
pos
ed for debarment, declared
ineligible, or voluntarily excluded from participation in this transaction by any federal department or agency.

COMPANY NAME:

COMPANY STREET ADDRESS:

COMPANY CITY, STATE & ZIP:

SIGNATURE:



DATE :

TYPE OR PRINT NAME:


TITLE:

TELEPHONE NUMBER: ( )



FAX NUMBER: ( )

EMAIL ADDRESS:

FEIN NUMBER:

DUNS #:

UNIVERSITY OF WISCONSIN






PROPOSAL NO.: 13
-
5399

MADISON, WISCONSIN 53715
-
1218

AMENDMENT #1


PAGE 4 OF 44


Section #2: Preparing and Submitting a Proposal


2.1

Applicable Dates


Date


January 31, 2013


Fe
bruary 8, 2013


March 11, 2013

--

2:00 PM


Event


Date of Issue of the RFP


Written questions due


RFP Due Date (Local Madison Time)


2
.
2

Submittal Instructions


PROPOSALS MUST BE DELIVERED TO:



Purchasing Services,
21 N. Park Street, Suite 6101, Madison
, WI 53715
-
1218.



NUMBER OF COPIES TO BE SUBMITTED:


Seven (7)

hard copies of the completed proposals, including the signed original, may be mailed, delivered by
Proposer, or by a third
-
party/courier service
in a sealed envelope or package with the RFP n
umber on the
outside. One (1) copy of the proposal must be submitted on CD
/DVD/Flash Drive
.
Proposals must be
received and date/time stamped prior to 2:00 p.m.
C
D
T

on the stated proposal due date. Proposals not so
date/time stamped shall be considered lat
e.
Late proposals shall be rejected.




If hand delivering,

c
all 608
-
262
-
1526 for assistance upon arrival.


FAXED RESPONSES WILL NOT BE ACCEPTED.


The University will accept completed proposals e
-
mailed to
bi
ds@bussvc.wisc.edu
, provided

(i) they are date/time
stamped prior to 2:00 p.m.
C
D
T

on the stated proposal due date
AND

(ii) the number of copies indicated above
are mailed or hand delivered to Purchasing Services,
21 N. Park Street, Suite 6101, Madison, W
I 53715
-
1218

by
2:00 p.m. C
D
T on the next business day following stated proposal due date.


Submitting a proposal to any other e
-
mail address than
bids@bussvc.wisc.edu

does not constitute receipt of a
valid propo
sal by Purchasing Services.


Proof of transmission doesn't constitute proof of receipt.


E
-
mail
submissions
must

be a scanned copy of the document with ACTUAL signatures and initials
(
not typed or
electronic signatures
)
, or those pages that require signatu
res and/or initials must be signed and returned via fax
(608
-
262
-
4467) and should be received prior to 2:00 p.m.
C
D
T

on the stated due date.


VENDOR NOTE: FOR THE PURPOSES OF THE RETURN ADDRESS LABEL, IF THE ADDRESS IS THE
SAME AS YOU LISTED ON THE REQUES
T FOR PROPOSAL FORM


YOU DO NOT NEED TO FILL OUT
THE RETURN ADDRESS LABEL.

UNIVERSITY OF WISCONSIN






PROPOSAL NO.: 13
-
5399

MADISON, WISCONSIN 53715
-
1218

AMENDMENT #1


PAGE 5 OF 44


RETURN ADDRESS LABEL:


Below is a label that can be taped to the outsi
de of your sealed proposal response. If returning your
proposal response by mail or in person, please fill out the information and tape to the outside of your
proposal package.


PROPOSAL

NUMBER:
13
-
5399

DUE DATE:

03/11
/13


TIME: 2:00 PM
C
D
T


SHIP FROM:


VENDOR NAME HERE: ______________________________________

ADDRESS: ________________________________________________


________________________________________________


___________________
_____________________________


SHIP TO:


UNIVERSITY OF WISCONSIN
-
MADISON

PURCHASING SERVICES

21 N PARK ST, SUITE 6101

MADISON, WI 53715
-
1218


2.3

Proposal Response Format

Proposals should be typed and submitted on 8.5 by 11 inch paper and bound securely
.

The response should be
organized and presented in the following order. Each section should be separated by tabs or otherwise clearly
marked. The contents within each tab should reference the section or attachment number assigned in the RFP.
Failure to
submit as indicated may disqualify your proposal.


Tab 1:



Request for Proposal form signed by an authorized representative of proposing company
-

Cover Page.



Vendor Information Form, Attachment A.



Client Reference List, Attachment C.


Tab 2:

Responses to
specifications in Section 4.


Specifications (Sections 4.
1



4.
16
).


Tab 3:

Cost Proposal, Attachment B.


Tab 4:

Other


RETAIN A COPY OF YOUR PROPOSAL RESPONSE FOR YOUR FILES


2.4

Incurring Costs



The State of Wisconsin is not liable for any cost incurr
ed by proposers in replying to this RFP.


2.5

Oral Presentations, Product Demonstrations and Proposer Location Site Visits

(Pre Award)


The University, at its sole discretion, may require oral presentations and/or site visits to supplement the proposals.
Failure of a proposer to conduct a presentation on the date scheduled may result in rejection of the proposal. Oral
presentations cannot be used as an opportunity to alter the proposals
. All proposers should be prepared to
accommodate this request with a
minimal amount of notice by the University. In addition, proposer may be
required to participate in a proof
-
of concept pilot before an award is finalized.

UNIVERSITY OF WISCONSIN






PROPOSAL NO.: 13
-
5399

MADISON, WISCONSIN 53715
-
1218

AMENDMENT #1


PA
GE 13 OF 44


Section #4: Requirements and
Specifications


Requirements that include the word "must" or "shall” describe a mandatory requirement.
FAILURE TO MEET A
MANDATORY REQUIREMEN
T MAY DISQUALIFY YOU
R PROPOSAL.


Proposer must: 1) indicate agreement o
n each mandatory requirement
and, if requested,

describe how the specifications
will be met and/or provide additional information, 2) complete any required form(s) and 3) provide a complete and detailed
response to any non
-
mandatory requirement that can be

fulfilled. If supplemental materials will be provided, clearly mark
all supplements with the corresponding section number.


Only proposals submitted by Proposers that meet all mandatory specifications will be considered for evaluation.


The Proposers res
ponse to this Section must clearly demonstrate the capacity to handle the needs stated in this RFP in
addition to the Proposers current workload. The University reserves the right to request supplementary information
deemed pertinent to assure Proposers co
mpetence, business organization, and financial resources are adequate to
successfully perform.




NOTE:


Failure to respond to all items in this section may be deemed as sufficient reason to reject a proposal.
Format your response to correspond numerically

with items
on the Submittal Instruction (see Section
2.2
).



INSTRUCTIONS:

Proposers should provide a detailed answer to each of the questions below. Those questions
that are identified as a MUST will be scored as pass/fail. Section 4.15 has two differ
ent sets of questions
depending on the type of licensing options offered. Proposer should answer only the questions that are relevant
to the licensing options being offered. In the event you can provide either a purchase or a hosted solution please
provi
de answers to both sections. Proposers will be given two separate scores for each option.


4.1

Product History, Roadmap and Practices

4.1.1

Provide a brief history of your organization. Describe the ownership of your organization, i.e., is it privately
o
r publicly held, is it a subsidiary of a larger firm, is a consortium, etc.? Provide an organization chart and
number of employees.


4.1.2

Is your organization the publisher of the software/software as a service associated with this solution? If
not, desc
ribe your relationship with the publisher and provide proof that you are authorized to negotiate a
license agreement.


4.1.3

Describe the history of the software or software as services associated with your solution, noting major
releases and their feature
s.


4.1.4

List the primary vertical markets related to
identity and access management (IAM)

Information
Technology Service Management Tools (ITSM)

that your organization focuses on. Provide a list of
higher
-
education institutions that use your solution.



4.1.5

For each element of your solution, provide a product roadmap that describes new features, integration, or
changes in architecture or other relevant features for the next 18 months.


4.1.6

Describe any relationships with other organizations and the
ir products that provide enhancements or pre
-
integration with your solution.


4.1.7

Provide the typical license agreement for your product and/or any typical add
-
ons or extensions to your
product.


4.2.

System User Technical Requirements

4.2.1

Describe ho
w system users using the operating systems listed below would access your system. What
functional limitations exist (if any) for users of the listed operating systems: a. Windows (XP, Vista, 7, 8);
b. Mac OS X ; c. Linux; d. Mobile (iOS, Android, Windows
).


4.2.2

Describe any third
-
party software that must be installed on a system user's computer to get full
functionality from your system.

UNIVERSITY OF WISCONSIN






PROPOSAL NO.: 13
-
5399

MADISON, WISCONSIN 53715
-
1218

AMENDMENT #1


PAGE 15 OF 44



4.4.4

Describe how the UIs associated with your system support UW
-
Madison’s recommended screen readers.
See this DoIT Help Desk Knowledge Base article for a current list:
http://kb.wisc.edu/helpdesk/
page.php?id=13805
.


4.4.5

Describe how your system ensures that a system user's or customer’s work is not lost in the case of an
abrupt loss of connection to your system.


4.4.6

Describe how system users and customers are able to search your system for
previous incidents,
requests, etc. a.. Describe what attributes and fields are available for searching. b. Describe how search
results are organized and how system users and customers can organize their results to meet their needs.
c. Describe how prev
ious searches can be quickly recalled or saved within your system.


4.5

System Administration


4.5.1

Describe your recommended model for administering your system.


4.5.2

Describe how your system allows for differing levels of administrative access. For e
xample, the email
team would like to manage their own system users, workflows, and incidents without administering for the
entire system. a. Describe how the email team could brand your system so that their system users only
see their branding.


4.5.3

Des
cribe the administrative features of your system that allows for only authorized system users and/or
groups to access certain
B35

functions and processes within the system. For example
,

restricting access
to a CI to only specific system users.


4.5.4

Desc
ribe how your system allows for groups within the system to share work with each other. For
example, the Engineering department hosts a server for the English department, and both groups need
access to the server as a CI within the system. a. In the exa
mple above, assuming your system allows
them to share the
CI;

can the rest of the departments’ operations within your system remain independent
and not shared with the other department? If so, describe how it’s done in your system. b. Assuming your
syste
m allows for a scenario in which the Engineering department and English department can share a CI
with each other but keep the rest of the operation independent, how scalable is this model? Can dozens of
departments, groups, and affiliates exist within the

tool with their own operations and choose what
information they will share and to whom they will share it to? If so, describe.


4.6.

System User and Customer Administration


4.6.1

Describe how administrators designate system users and customers within yo
ur system.


4.6.2

Describe how your system allows for bulk updates of both system users and customers. For example, a
group of 200 faculty receive contracted support and need to be added to a special support group. How
does the system allow administrator
s to update
those records

efficiently without having to open up 200
customer records and edit each one?


4.6.3

Describe how your system allows an administrator to login as a proxy of both system users and customers
to recreate reported issues.


4.6.4

Doe
s your system allow for customers and system users with similar permissions to be grouped into
assigned "roles"? a. Assuming your system supports "roles" describe what functions and features your
system allows to be defined within a "role". b. Assuming
your system supports "roles" describe the pre
-
defined "roles" delivered by your system. c. Assuming your system supports "roles" how does your
system allow for pre
-
defined "roles" to be changed or removed?


4.6.5

Describe how your system allows system use
rs that do exist in our directory structure to be added as
system users.

UNIVERSITY OF WISCONSIN






PROPOSAL NO.: 13
-
5399

MADISON, WISCONSIN 53715
-
1218

AMENDMENT #1


PAGE 27 OF 44



ATTACHMENT B


COST PROPOSAL FORM



Pricing Instructions

Provide pricin
g for the proposed Information Technology Service Management Tool for one or both of the following
options.



Option A: On
-
Premise Software and Maintenance for Five Years:


Pricing should be presented based on 130 Core Users:


Describe all component
s, licenses and products needed to acquire the software. In addition, you should include the yearly
maintenance cost for the first five years once any (if required) acceptance and warranty period has expired. Pricing for
these elements are to
be
fixed pri
ces for the entire contract term. Maintenance cost should include all updates and
upgrades to the software. It should also allow for a non
-
production copy of the software to be installed on a separate
server for testing purposes.



Vendor should provide p
ricing for the purchase of additional users for the duration of the contract. They should
also indicate pricing for different types of users if applicable to their system or solution being offered.



They should also indicate if there system requires li
censes for all users who access the system.




All pricing, both recurring and non
-
recurring, should be included and itemized in this section and should include all
costs, fees, charges and rates. Costs not identified in this section will not be considered
. Any additional costs over
stated values in identified cost areas will be accepted at the University’s sole discretion.



Option B: Vendor Hosted Software or Software as a Service option for Five Years:


Pricing should be presented based on 130 Core User
s:


Describe all components, licenses and products needed to use the software for a five year period once any (if required)
acceptance period has expired. Pricing for these elements are to
be
fixed prices for the entire contract term. Pricing
presented s
hould include all updates and upgrades to the software. It should also allow for a non
-
production usage of the
service on a separate server for testing purposes.



Vendor should provide pricing for the purchase of additional users for the duration of the c
ontract. They should
also indicate pricing for different types of users if applicable to their system or solution being offered.



They should also indicate if there system requires licenses for all users who access the system.


All pricing, both recur
ring and non
-
recurring, should be included and itemized in this section and should include all
costs, fees, charges and rates. Costs not identified in this section will not be considered. Any additional costs over
stated values in identified cost areas wi
ll be accepted at the University’s sole discretion.


Implementation and Installation Services:

Proposer should provide a price list of all Consulting and Training options that may be required to implement the system.
Consulting Services should be provided

as an hourly rate for each different type of resource. Training should be provided
as a daily rate or course rate for both on
-
site at the University and at contractor’s site. This information should include all
expenses. If there are additional travel
expenses they will be reimbursed at State of Wisconsin Travel rates. This
information is on the following web site.
http://www.uwsa.edu/fadmin/fppp/fppp36.htm



A specific Statement of Work (SOW)

will be negotiated with winning proposer before implementation services will start.

UNIVERSITY OF WISCONSIN






PROPOSAL NO.: 13
-
5399

MADISON, WISCONSIN 53715
-
1218

AMENDMENT #1


PAGE 28 OF 44



Miscellaneous Items:

Provide a discount off list for any
other related products or services that may be offered through the contract. Provide a
general description of any items. Any additional items will be accepted at the University’s sole discretion.


Costs which are not specifically identified below will no
t be compensated under any Contract awarded pursuant to this RFP.



Click here for spreadsheet.


To access
the above
spreadsheet


place your cursor over the link and
hit the CONTROL key
and wait for the
“hand” and click.




Country of Origin ___________________________________________


Shipping Point ____________________________________________


AMENDMENT #1

QUESTIONS AND ANSWERS FOR
13
-
5399

(
INFORMATION TECHNOLOGY

SERVICE MANAGEMENT TOOL
)



1

I understand the due date for response for this RFP is 02/28/2013. Has an award date/start date been
determined?



A1
:

No.


2

Section 1.1 under “SCOPE” (Page 1 of 44) there is a reference to: 800 employee accounts (up to 125
emplo
yees using the system concurrently) and in Attachment B
-

Cost Proposal Form (Page 27 of 44):
Option B: Vendor Hosted Software or Software as a Service option for Five Years: pricing should be
presented based on 130 Core Users.
Question

-

What is the maxim
um number of users that can be
logged in at the same time? Do you expect 130 core users to be logged in at the same time? We
typically for each a 3:1 or a 4:1 ratio on the number of users that are actually logged in at the same time
to the system?



A2
:


F
or the purpose of pricing the RFP a
ssume 130
Core

Users with full access to the system. Do not try to make
any assumption on the types of users to provide a lower price. Proposers should Identity all the different types
of users that are available to be p
urchased on the price sheet including the on
-
going pricing.


3

4.1.4


List the primary vertical markets related to identity and access management (IAM) that your
organization focuses on.


Provide a list of higher
-
education institutions that use your soluti
on.
Question



Do you mean Higher education institution using our identity and access management solution or the
service desk application?



A3:

This was an error


please reference the new 4.1.4 Requirement.


4

We are hesitant to respond to this RFP afte
r referencing the requirement around HIPAA compliance. Our
product is not a HIPAA compliant software, though we do have customers in the Higher Ed and
Healthcare space?


A4
:

HIPAA compliance is not mandatory. We ask due to the fact that our medical scho
ol would require HIPAA
compliance if they ever wanted to operate in the same ITSM space as us. There are no current plans to have
the medical school operate in a shared space, so this question has a lower priority than other questions.


5

Question 4.3.3


H
ow important is the integration into Oracle Identify Manager (OIM)?


A5
:

The stronger the integration with OIM, the better.


6

Question 4.3.5


How important is integration with Shibboleth/SAML from the Web Access Management
(WAM) infrastructure?


A6
:

Very i
mportant.

This is how we intend to authenticate users to the system.


7

Question 4.3.6


How important is integration with the WAM for deep linking?


A7
:


It is not so much important, as we want to know what your application does when someone attempts to d
eep link
into it.

Does it require authentication?

Give errors?

Etc.


8:

Section 3.13, Insurance


Is this a mandatory requirement? Our company does not carry commercial
general, automobile or contractor liability insurance. There is no need to carry t
his type of insurance.
Most of the work is done remotely from our headquarters.


A8
:


If no motor vehicles are owned by the company, or we can establish that none will be used in performing
service under the resulting contract, the automobile insurance req
uirement can be waived. That commercial
general liability insurance is not carried is a concern for us in regards to company stability.

-
2
-


9:

4.2.1 System Technical Requirements


is support for Mac OS X and Linux mandatory requirements?


A9:

Mac OS

X and Linux support is strongly desired.


10
:

Section 1.1
-

Which ITSM system is the University of Wisconsin
-
Madison currently using?


A10
:

VMWare Service Manager 9


11.

Section 1.1
-

125 Concurrent Users: How many of them will access via web, how many via
our Windows
client? According to which role will they use the system (end user, change user, etc.). Is it possible to
give a breakdown?


A11
:

For purposes of the RFP provide pricing for 130 Core Users of the system assuming full access. Do not try to
mak
e assumptions for different types of users. On the pricing sheets provide a price for each different type of
users including yearly cost by user. We reserve the right to have a more specific discussion once the RFP
process is completed
.
If every user req
uires a specific license please note that on your pricing proposal.


12.


Section 1.1
-

How many additional users are expected in the next five years? Which user groups?


A12
:

Unknown. It is our goal to launch a new product within our organization, and once
our processes are migrated
an
d

mature,
we may
offer the service to campus partners. If popular, there could be hundreds of new users in
the next five years. User groups would be other IT staff on campus that wants to run their own pocket of their
softwar
e for themselves, or interact with central IT in the same tool.


Proposer should identify pricing for each additional users group if they are required for your system on the price
sheet. If every user requires a specific license please note that on your p
roposal.


13.

Section 1.1
-

Do the 350,000 customers all have to be able to access the Self Service Portal? Does it
mean that we should provide it for up to 350,000 named users? How many of them will be allowed to
create new objects (tickets)? Do you know how

many of these users are expected to log in
simultaneously?


A13
:
UW
-
Madison supports several IT systems for the entire University of Wisconsin system. It is strongly desired to
have these customers be able to access a
self
-
service

portal to log tickets,
update them, get news, etc. We do
not know how many of them will need to log in simultaneously. I would say that initially, max usage might be
several hundred people. If this turns into a popular service, I could see busy days bringing 500 or more
concu
rrent users.




We have a very fluid population of users which the system needs to accommodate. According to our IPEDS
data we estimate that we have approximately 179,000 students and 32,300 faculty and staff at any point in time.
It results in approxi
mately 200,000 plus Active Users at one time but more than 350,000 plus users reside in our
current database.



Proposer should identify pricing for all the different type of users they are required for their system on the price
sheet including all yearly

costs. For the purposes of the RFP evaluation we are using 130 Core Users with full
access. However, if your
licensing
model is that ever user requires a license please note that on your price
proposal
.


14.

Section 1.1
-

How many server instances are you pl
anning?


A14
:

We don’t have any finalized plans for server instances at this time.

Proposer should

indicate any charges for
additional servers on the price sheet including any yearly costs.


15.

Section 1.1
-

Is failover/clustering required?


A15
:

A failure t
olerance solution is highly valued and will be strongly desired.

-
3
-



16.

Section 1.1
-

Do you wish a fixed
-
price quote or shall we do best effort estimation? We are planning to
make the project (customizing and implementing) from Europe, that's why it is im
portant whether you
have a remote access? The workshop will be held at your side. Is it necessary to make the customizing
services also at your side? All these questions are relevant to calculating the travel expenses.


A16
:

At this point in time for the C
onsulting and Training we do NOT expect a fixed
-
price quotation. However, for the
software option we do require a fixed pricing for the 130 Core Users regardless of the type of license we
selected (On
-
Premise or Hosted). Proposer must Identity any pricing
for other types of user along with the yearly
costs.



For the Consulting and Training, we are requesting hourly rates by resource that will help us plan and budget for
the implementation. We will negotiate a statement of work with the successful proposer
for the implementation.
Proposer can offer us both a remote or on
-
premise rate by type of consultant.



17.

Section 1.4
-

VendorNet
-

is it mandatory? Is it possible to register for taxes after getting the assignment
or should this be done at the moment of s
ending in the proposal?


A17
:

No, it is not mandatory. There is no mention of tax registration here.


18.

Section 4
-

We did not identify any criteria with the wording 'MUST', so there seem to be no blocking
criteria, is this correct?


A18
:

Correct.


19.

Questio
n 4.2.1
-

Under which of the listed operating systems will the tool run? Our software application
server runs on Windows servers; is this problem??


A19
:
Running on Windows servers is not a problem.


20.

Question 4.13.5
-

Which tool criteria come from the HI
PPA requirements?


A20
:

Only question 4.13.5 includes HIPPA requirements and criteria. No other question involves HIPPA criteria.

This is of concern because we may have data in the system that is covered by this requirement.


21.

Question 4.13.6
-

Which to
ol criteria come from the FERPA requirements?


A21
:

Only question 4.13.6 includes FERPA requirements and criteria. No other question involves FERPA criteria.

This is of concern because we may have data in the system that is covered by this requirement.


22.

Question 4.12.11
-

Do you currently use a discovery tool? If yes: which one? If no: are you planning to
buy one at this stage? Is integration with the existing or new scanning tool in or out scope for this RFP?


A22
:

We do not use a discovery tool but hav
e a desire to use on
e

in the future.


23.

Question 4.4.1
-

Which tool criteria come from the Section 508A and WCAG?


A23

Only question 4.4.1 includes 508A and WCAG requirements and criteria. No other question involves 508A and
WCAG criteria.

We need to make

every effort to insure that the tools in use by the Campus are accessible as
possible so we are asking if your tool can meet those standards.


24.

Question 4.5.3
-

Which criteria come from B35 functions?


A24
:

The B35 is a typo.
See the replacement Requi
rement.


25.


Question 4.16.9
-

How many administrators are going to visit the trainings? Is it planned for other users
group to visit external trainings?


A25
:

i
t’s likely we would train 3
-
5 people, and then train other groups on campus ourselves.

-
4
-



26.

Sec
tion 5.2
-

Where are the scoring points provided in parentheses in Section #4? Could you please
send these points?


A26
:

They are not.


27.

Attachment G, 5.0
-

Does this mean that the Statement of Work will act as specification and costs stated
there shall b
e understood as the “funding limitation”? What if we exceed these costs? Are we allowed
or not??


A27
:

The Statement of Work will state the costs and shall be understood as the “funding limitation”. You may not be
paid if you do not follow the process for

price changes defined here. Not without permission.


28.

Are you expecting our answers in the document you sent or is it possible to create separate documents
containing the answers?


A28
:

Separate documents are acceptable

but it needs to follow our format.

This is especially important in the pricing
proposal.


29.

Pricing scenario A and B both ask for pricing for '130 core users'. 1
-

How do these core users compare
to the 125 concurrent users and 800 Named Users ('employee accounts') in section 1.1? 2
-

Option
A and
B (on
-
premises versus SaaS) both ask for pricing for '130 core users', how many 'Named Users' and
how many 'Concurrent Users' are required in both scenarios? (If we were to provide a SaaS pricing this
would be based on Named Users, while on
-
premises
pricing is based on 'Concurrent Users', so
according to the info in 1.1 scenario A should be for 125 Concurrent Users and scenario B for 800
Named Users. Is this correct? )


A29
:

For purposes of the RFP provide pricing for 130 Core Users of the system assu
ming full access. Do not try to
make assumptions for different types of users. On the pricing sheets provide a price for each different type of
users including yearly cost by user. We reserve the right to have a more specific discussion once the RFP
pro
cess is completed
.
If every user requires a specific license please note that on your pricing proposal.


30.

Question 4.3.7
-

Can you please expand on what you mean by the term HTTP Proxy?


If the ITSM
solution is web based, does this essentially answer the
question?


A30:
We have a desire to display end
-
user’s incidents and requests in our student and faculty portal, My UW
-
Madison (my.wisc.edu). While we still intend to use the self
-
service portal supplied via the ITSM software we
choose, we’d like to disp
lay a portion of a customer’s data in My UW
-
Madison. This has traditionally been done
via an HTTP proxy page that pulls data from the ITSM system, and displays it in a way that My UW
-
Madison can
use. This can also be done via API integrations with My UW
-
Madison. We strongly desire a solution that can
integrate with My UW
-
Madison via HTTP proxy or API integrations.


31.

Question 4.3.8
-

Could you please expand on the type of security token that you utilize and how you use
the proxy?


Is this a security questi
on? Are you after SSL re
-
direction for a web based application?


If
the ITSM solution is web based, are you referring to encryption and will an SSL certificate answer this
question?


A31
:

We have a desire to display end
-
user’s incidents and requests in our

student and faculty portal, My UW
-
Madison
(my.wisc.edu). While we still intend to use the self
-
service portal supplied via the ITSM software we choose,
we’d like to display a portion of a customer’s data in My UW
-
Madison. This has traditionally been don
e via an
HTTP proxy page that pulls data from the ITSM system, and displays it in a way that My UW
-
Madison can use.
This can also be done via API integrations with My UW
-
Madison. We strongly desire a solution that can
integrate with My UW
-
Madison via HTT
P proxy or API integrations.



As for security tokens, the HTTP proxies typically use a shared token or basic authentication to pass information
between themselves.


32.

Question 4.5.3
-

Could you please expand on the term B35functions?


A32:
B35 is a typo.

See the corrected Requirement.

-
5
-



33.

Question 4.12.8
-

In the first part of this question, are you referring to the ability of our solution to
automatically generate a problem from other ITSM processes such as an Incident or Change?


If not,
could you pl
ease expand on your intention with this question?


A33:
Correct. How does your system allow Incident, Changes, or other ITSM functions to be turned into formal
problems to be consumed by Problem Management? For example, after multiple incidents involvin
g a router
failing, we use one or more of those incidents to create a problem until a root cause can be found. We can then
link future incidents related to that router to that problem.


34.

Attachment B
-

Can you kindly elaborate on the 130 Core Users for Lic
ensing?


If Approver and
Requester roles do not incur an additional cost with our solution, would 130 licenses still be needed?


A34:

For purposes of the RFP provide pricing for 130 Core Users of the system assuming full access. Do not try to
make assum
ptions for different types of users. On the pricing sheets provide a price for each different type of
users including yearly cost by user. We reserve the right to have a more specific discussion once the RFP
process is completed
.
If every user requires a

specific license please note that on your pricing proposal.


35.

Regarding sections 4.3.7 and 4.3.8 : Are all UW Madison users required to go through an HTTP Proxy to
access any and all sites in their browser?


A35:
No, only our student and faculty portal (
https://my.wisc.edu
) uses this feature.


36.

Regarding section 1.1 Scope
-

The RFP document scope mentions the likelihood of several other
departments using the system as their primary ITSM. Is section 4.5.4 the only sect
ion in the
Requirements and Specifications that addresses the University's requirements for use by other entities?
If not, what other sections will inform the University of this type of functionality?


A36:
Other departments contributed to the RFP process

by giving us their requirements. Rather than give a series of
questions about how department A wants to use email like this, and department B wants to use email like that,
we have instead opted to allow vendors to tell us how their software works, and ou
r evaluators will score based
on how well they can adapt their process into your system. In other words, we are open to using your solution
as you designed it, rather than using our solution in your system that may not be designed for it.


37.

Regarding secti
on 1.1 Scope
-

After implementation of the awarded system, does the University desire
expansion of the ITSM system to include any other functionality that automates and simplifies staff,
students and faculty interaction with IT, beyond incident, change, an
d configuration management? If
yes, although not in scope for this RFP, please provide a list of potential future desired functionality to
be available on the self
-
service portal beyond incident, change, and configuration management.


A37:
There is a desi
re to expand the use of the ITSM system to include other IT functions, but we don’t have any
specific functions in mind at this time.


38.

Regarding section 1.1 Scope
-

Does the University already have a "login
-
restricted (Shibboleth)
customer portal? If yes,
what services are available to users on that portal today?


A38:
The current customer portal currently only allows customers to log calls, update calls, and see closed calls.


39.

Please describe what percentage of UW Madison campus departments, or how many c
ampus
departments, currently contract with DoIT for services involving the current ITSM solution.


A39:
Four departments currently contract with us to use our ITSM solution.


40.

Regarding section 4.1.4
-

Should "identity and access management (IAM)" be repla
ced with "IT Service
Management"?


A4
0:


See the corrected Requirement. This was an error.

-
6
-



41.

Regarding section 4.14.1
-

Ideally, would the University desire or require that data generated by the new
ITSM be combined with data from other Univers
ity systems for a broader scope of reporting for review
by campus executives?


A41:
Yes.


42:

Regarding section 4.16.2
-

please clarify the second question in this section: "What is your
recommendation for consulting purchase for a new customer?"


A42:
W
e are attempting to get general information about the type and scope of consulting services that might be
required for an installation of the scope and size of an organization such as ours. We attempted to provide
some basic information under the backgro
und information scope. We know that we don’t have enough detail to
require that vendors give us a detailed Statement of Work for this project. But we want an idea of the work
required.


43:

Regarding section 5.2 Scoring Criteria and Method
-

the RFP i
ndicates that there are "points in
parentheses" representing the total possible points for each response. Where are those parenthetical
point values in the document?


A43:
See Section 5.2.2, Point Matrix.

That’s the level of detail we provide at this poi
nt in the RFP process.


44.

Regarding Attachment B
-

Cost Proposal Form
-

How does our response of a price list of all Consulting
and Training options factor into the Cost portion of the scoring criteria?


A44: It will not at this point in the process be par
t of our cost analysis but it gives us a starting point to discuss a
detailed Statement of Work once we have a better understanding of the effort required to implement your
system.


45.

Our software pricing is based on the amount of end users rather than ope
rators or technicians that will
be working on resolving the calls. We need to know the amount of staff that have the potential to log
calls with your IT services. Because you are and educational organization, the students will come for
free and should
not

be included in the calculation of the number of end users.


A45:
A13
:
.UW
-
Madison supports several IT systems for the entire University of Wisconsin system. It is strongly
desired to have these customers be able to access a
self
-
service

portal to log tic
kets, update them, get news,
etc. We do not know how many of them will need to log in simultaneously. I would say that initially, max usage
might be several hundred people. If this turns into a popular service, I could see busy days bringing 500 or more

concurrent users.





We have a very fluid population of users which the system needs to accommodate. According to our IPEDS
data we estimate that we have approximately 179,000 students and 32,300 faculty and staff at any point in time.
It results in a
pproximately 200,000 plus Active Users at one time but more than 350,000 plus users reside in our
current database.


46.

How many universities or colleges do you plan to support with your chosen service management
software?


A46:
UW
-
Madison supports several s
ervices for UW System schools. UW system is 14 four year universities. While
we don’t provide support for all of their
other
IT needs, their members may contact us for services that we
provide for their university.

-
7
-



47.

Attachment B, Cost Proposal,
Opt
ion A:


On
-
Premise Software and Maintenance for Five Years

-

Our
licensing model consists of “fixed” users and “concurrent” users. Can you tell us how many of these
130 core users would be considered “fixed” or full time users?


The balance can be consider
ed
concurrent.


A47
:
For purposes of the RFP provide pricing for 130 Core Users of the system assuming full access. Do not try to
make assumptions for different types of users. On the pricing sheets provide a price for each different type of
users includ
ing yearly cost by user. We reserve the right to have a more specific discussion once the RFP
process is completed.
If every user requires a specific license please note that on your pricing proposal.


48:

How many IT persons will access the system in
a concurrent mode? In addition, please divide this no.
into the parties that should be able to access the system


-

via Windows
-
Client,


-

via Web
-
Browser,


-

via both of it up to their choice.


A48:
Our current system allows for 130 concurrent users. It
is strongly desired that they should be able to access the
system via the operating system and browser of choice.


49:


If there is no clear indication possible about this then please answer: How many people are at the 1st
level of your service desk? Sho
uld they be able to access the system via windows
-
client, web
-
browser
and/or both?


A49:
There are approximately 80 people that provide 1st level support. It is strongly desired that they should be able
to access the system via the operating system and br
owser of choice.


50:

How many people are in back
-
end of your IT organization (2nd level, 3rd level, Change Users, …)?
Should they be able to access the system via windows
-
client, web
-
browser and/or both?


A50:

There are several hundred employees that d
o 2nd/3rd level support. These same individuals the change users
as well. It is strongly desired that they should be able to access the system via the operating system and
browser of choice.


51:

How many people will need to access the ITSM system in a

continuous permanent mode? Should they
be able to access the system via windows
-
client, web
-
browser and/or both?


A51:
Our current system allows for 130 concurrent users. It is strongly desired that they should be able to access the
system via the opera
ting system and browser of choice.


52: Should the system be able to progress incoming emails automatically, e.g. to support functions like
email
-
2
-
ticket?


A52: This is
highly desired.


53.

W
ill a CTI
-
integration between the ITSM system and your telephony b
e considered as mandatory? This
will speed
-
up the inbound and outbound calling at your Service Desk. However, this feature would just
make sense in an economical way if a high amount of callers were expected.


A53:
It is not mandatory.


54.

Will one productio
n system be considered as appropriate or will it be required to provide additional test
-
/development and/or training systems?


A54:
Our current setup has Development, Testing, QA, and Production environments. It’s likely we’d want to
maintain a similar st
ructure, but we may not need 4 environments. In addition, only a handful of employees have

access to the Development and Testing instances.


-
8
-



55.

Should the production system run in a high
-
availability mode, e.g. multi
-
servers and/or clustering?


A55:

Yes.


56.

Will University of Wisconsin support a remote
-
working approach so that our Headquarters in Europe
can participate during the implementation/customization of the ITSM system?


A56:
A remote
-
working approach can be supported.


57.

Will it be acceptable f
or you if the documents will be signed and then scanned or do you require original
signatures on the documents (the signature will have to come from Europe)?


A5
7
:

Scanned documents are acceptable.


58.

In case you require an original signature, we will have t
o print and sign the documents in Europe and
this means that the paper format will be A4, is this acceptable?


A5
8:

See the answer to the previous question.


59.

In the pricing section instructions say to price out based on 130 core users.

Can you please conf
irm if
core users means named user licenses or does this mean concurrent user licenses?


A59:
A11.
For purposes of the RFP provide pricing for 130 Core Users of the system assuming full access. Do not
try to make assumptions for different types of users.

On the pricing sheets provide a price for each different type
of users including yearly cost by user.



We reserve the right to have a more specific discussion once the RFP process is completed
.
If every user
requires a specific license please note tha
t on your pricing proposal.


60.

Please provide a timeline of when RFPs will be reviewed, demonstrations will be set,

when vendor will
be selected and implementation will start?


A60
:

We
do not have a specific timeline at this time since it will depend on how

many responses we receive to the
RFP.

Demonstrations will be set up for the top scoring responses, which will likely take 4
-
6 weeks.


61.

Question 4.1.4 says “List the primary vertical markets related to identity and access management (IAM)
that your organ
ization focuses on.” Can you clarify this request? Is this pertaining to security, i.e. are
you asking if we also have identity and access management solutions?


A61: This was an error


please reference the new 4.1.4 Requirement.


62.

Question 4.12.11 says
“Describe how your system interacts with discovery tools to populate and update
the CMDB.”


What discovery tools do you currently use or plan to use in the future?


A62:
We do not use any discovery tools, but would like to in the future. We have no spec
ific discovery tool that we
plan to use; we just want to know how your software interacts with discovery tools.


63.

Our answers will be motivated with the help of many documents, including for example an administrator
manual or the end user manual. To print a
ll of these accompanying documents 7 times would lead to a
huge amount of paper being used and shipped and we suggest not doing so. Can you provide us with
an FTP server where we can upload the accompanying documents so they become accessible for
everybody

involved? Is that an acceptable solution for you?


A63:
No, we do not have an FTP server available for this purpose
.

We recommend you submit only the essential
information necessary to evaluate your proposal. It is very unlikely we would bother reading
through such
manuals in the evaluation process.

-
9
-



64.

For providing a sample statement of work, which ITIL processes do you plan to implement?


From
reading through the RFP we noted those immediately below. Have we missed any?



Incident Management



Change
Management



Configuration Management



Service Request Management (Including Service Catalog?)


A64:
T
he processes listed in this question are the processes we intended to have implemented for launch.


65.

For training on the system, would you prefer to have you
r employees train other employees?


If so, how
many internal trainers would you like us to train?



A65: Provide us the daily rates for all the different options. We’ll make a decision as the process develops.

.

66.

When did UW
-
Madison purchase the HP SD sol
ution?


A66:
We are migrating
from
our change and configuration database from HP SD to VMWare SM9 in March.
When
we purchased the solution is not relevant to this process.


67.

RFP Question 4.1.4, can you please clarify the reference to IAM.


67: This was an

error


please reference the new 4.1.4 Requirement.


68.

What are the strengths and weaknesses of your current solution?


A68:
The information is not available at this time.


69.

What limitations exist in the current implementation that affects your strategic d
irection?


A69:
The two major restrictions are:

1.

We are currently restricted to accessing the tool on Windows computers with Internet Explorer. Users on
other platforms cannot access our system to do their work and must make difficult accommodations
to do
their work.


2.

We are unable to delegate administration to others to manage their groups, reports, and/or operations. We
can’t give someone space within the tool to run an operation without giving full administrator access. We’d
like to have a f
ew administrators with full access, and many delegated administrators that can make update
the tool for their operation without it affecting all other users in the tool.


70.

What version of HP Service desk are your currently running, and what Service Pack lev
el?


A70:
We are migrating
from our current
change and configuration database from HP SD to VMWare SM9 in March.



71: Please describe the current integration leveraged between HP Service Desk and Shibboleth/SAML.


A71:
There is no integration between

HP SD and Shibboleth/SAML.


72.


Is the current interface between Shibboleth and HP SD providing the required functionality?


A72:
Shibboleth does not interface with HP SD, but it does interface with VMWare SM 9. It provides the required
functionality in VM
Ware SM 9.


73.

Can you provide your current support costs for the HP SD environment?


A73:
We are migrating our change and configuration database from HP SD to VMWare SM9 in March.
The current
support costs are not relevant to this process

-
10
-


74: How ma
ny HP SD application servers do you currently deploy to support your HP SD environment?


A74:
We are migrating our change and configuration database from HP SD to VMWare SM9 in March. While we
could list all of the integrations with HP SD, since we won’t
be using it in the near future, we feel it’s a bit
misleading to list all of them.


75: What is your current configuration for users (named vs concurrent)?


A75:
Our current license agreements allow us to have 130 concurrent users at maximum. We have app
roximately
800 users with access to the system that could potentially use one of those licenses.


76: Do you currently use Microsoft RDP?


A76:
No.


77.

Question 4.3.12, are there technical reasons why these other groups are not using the current service
des
k environment?


A77:
Yes. The current ITSM tool does not allow for sufficient levels of delegation, nor does it allow for incidents,
changes, etc. to be easily shared between groups.


78.

Please list all of the current integrations and tools that interface w
ith the HP SD environment.


A78:

We are migrating our change and configuration database from HP SD to VMWare SM9 in March. While we
could list all of the integrations with HP SD, since we won’t be using it in the near future, we feel it’s a bit
misleading

to list all of them.


79.

Are there any tool integrations that are not supported but required?


A79:

The most critical tools are specifically mentioned in this RFP. While none of them are required, the easier it is
for your ITSM solution integrates with our
existing tools, the better.


80.

Does the current HP SD environment provide the required levels of integration in the robust knowledge
base
https://kb.wisc.edu
?


A80:

There is currently no integration with HP SD and our
KB.


81.

How would you describe UW
-
Madison’s level of process maturity?


A81:

Our operational framework has chapters for incident management and change management. We practice in all
other parts of ITSM within the organization but areas like problem managem
ent, knowledge management,
service management, etc. are done on a less formal level.


82.

Is there a need to replace the current self
-
service portal?


A82:

Yes.



83.

What reporting tools are currently leveraged and if possible would you continue to use them?


A83
:

We currently use reporting software built in to VMWare SM 9. We are in the process of switching to Hyperion
Interactive Reporting (owned by Oracle). It is possible we would continue using Hyperion Interactive Reporting.

-
11
-



84.

RFP Question 4.8.4 pleas
e elaborate/provide more details on the functions associated with ‘outage
notification’ and ‘Process change notification’.


A84:

In addition to publishing outages at
https://outages.doit.wisc.edu
, we notify
technologists and customers via
automated emails when outages are declared against their service.



As for change notifications, we have a strong desire to update customers, technologists, and stakeholders when
certain actions in a change are completed.

This could be the change starting, ending, being delayed, causing a
major incident, etc.


85.

What portions of the cost spreadsheet are included in the scoring method toward the potential 1000
COST points?


A8
5:

To be determined.

.

86.

Do you currently have a SSO

solution implemented?

a

If so, what solution do you use for Single Sign
-
On?


A86:

We use Shibboleth and have a strong desire to keep using Shibboleth.
http://shibboleth.net/


87.

Requirement 4.3.10: What Software and Hardw
are monitoring tools are currently in use?


A87:

HP OVO and Nagios. Nagios promotes alarms to OVO.


88.

Requirement 4.7.1: What is the minimum requirement for development / testing environments to be
used by other UW
-
Madison applications?


A88:

We currently h
ave 4 environments: development, test, QA, and production. It’s likely we’ll want 3
-
4
environments that fill similar roles in a new tool.


89.

Requirement 4.12.11:


What discovery tools are currently in use by UW
-
Madison that you would like to
have integrated

with the ITSM tool?


A89:

We currently do not use discovery tools, though there is a desire to use them in the future
.

.

90.

Requirements 4.15A and 4.15B:


Is there a preference of Hosted vs. On
-
Premise?


A90:

We are open to either option, and we have no pref
erence at this point.


91: It is our understanding the University of Wisconsin Medical Center had a requirement that solutions
must be SAML compliant; other authentication methods would not be entertained. Within the RFP,
there is a similar question re
garding SAML compliance, however it is not clear if this is a must have
requirement.



Can you please clarify if University of Wisconsin is willing to accept other standards such as integrated
security with Active Directory?


A91:

At this time, there is a
preference for SAML authentication. We would be open to other solutions, such as active
directory, but integration with non
-
SAML technologies would likely be more difficult and time
-
consuming.