Ontario Universities’ Application Centre
(Operated by C.O.U. Holding Association Inc.)
(Herein noted as “the OUAC”)
REQUEST FOR PROPOSAL
Title:
Date:
September 16, 2013
Application Management System
Contact:
Alexis Nagami, Executive Assistant
Closing Date of Proposals:
Monday, November 4, 2013
Address:
Ontario Universities’ Application Centre
170 Research Lane
Guelph ON N1G 5E2
Telephone Number:
519-823-1940, ext. 6222
Email: RFPInquiry@ouac.on.ca
Fax Number:
519-823-0584
Closing Time:
12:00 p.m. (noon) ET
Proposals must be
delivered in an
electronic format
before the closing
date and time
specified. Proposals
delivered after the
closing date and time
will not be
considered.
The OUAC is seeking a new Application Management System to replace its existing home-grown system.
The OUAC’s current automated online application and grades collection processes are achieved through
innovative technology, systems, policies and procedures, and data management activities that are
internationally regarded. These user-friendly, cost-effective and efficient data collection processes
continue to be a source of pride for the Ontario university system.
While the OUAC’s systems have continued to be enhanced and expanded upon over the last 30 years, a
recent project was completed that outlined a roadmap for the modernization of those systems. The
outcome was a multi-year transition plan that included the analysis of third party software solutions
that would meet the OUAC’s requirements; hence, the purpose of this Request for Proposal (RFP).
Basic Legal Framework Terms Applicable to This RFP and Any Contract Created From it
1) The jurisdiction for all legal matters, disputes and issues shall be the province of Ontario and all
Vendors submitting responses agree that they must and can only deal with any legal matters
involved in and through the courts of the province of Ontario.
2) Any dispute or issue shall be dealt with first by mediation with a mediator in Ontario chosen by
the OUAC and on terms agreed to in the final award contract before any party may resort to the
courts of Ontario.
3) Time shall be of the essence regarding all schedules and deadlines for this RFP and any final
award contract eventually entered into.
4) The OUAC will reserve the right to terminate any final award contract if the Vendor continues to
be in breach of its obligations pursuant to that contract after having received 10 business days
written notice of such breach from the OUAC and upon termination the Vendor shall only be
entitled to receive payment for services supplied to the date of termination and shall not be
entitled to claim any damages consequential or otherwise from the OUAC after the date of
termination.
5) All services and materials supplied will comply with the municipal and provincial laws of the
province of Ontario and the federal laws of Canada as applicable.
6) No member of the board, officer or employee of the OUAC shall be involved in or with any
Vendor responding to this RFP, directly or indirectly.
7) A Vendor responding to this RFP shall provide a warranty for its products and services to the
OUAC for one year after completion of implementation and installation and will indemnify the
OUAC from and against any and all claims made against the OUAC by any other person as a
result of the work provided to the OUAC by the Vendor.
8) The terms of any contract resulting from a final award shall constitute and be the entire
agreement between the OUAC and a Vendor and no other agreements oral or written shall
apply without the specific prior consent of the OUAC.
9) HST, as applicable, will be added to all prices determined.
10) Any information obtained by a Vendor or the OUAC during the course of this RFP that is of a
confidential nature shall be kept confidential throughout the RFP process and thereafter unless
otherwise mutually agreed.
11) Any intellectual property (including source codes) provided to the OUAC pursuant to any final
award contract shall become the property of the OUAC unless specifically indicated otherwise in
the final award contract.
12) Each Vendor submitting a response to this RFP shall agree and confirm in writing with their
proposal that its terms and provisions shall be valid and binding on them for a period of three
16 September 2013/Page 2
The Ontario Universities’ Application Centre
(3) months after delivery to the OUAC. Such terms and conditions may be extended by mutual
agreement.
13) Each Vendor submitting a response to this RFP shall agree and confirm in writing with their
proposal that they have reviewed the RFP terms and provisions in their entirety and agree and
accept them as binding, a fair and reasonable process for selecting the number one (1) ranked
Vendor and the awarding of and entering into of a final award contract. Each responding
vendor also will agree to participate in the second stage of the award process if selected by the
OUAC to do so.
14) Each Vendor submitting a response to this RFP shall agree and confirm in writing that the person
or persons signing their response has the authority to bind the Vendor to the response
proposed by that Vendor.
16 September 2013/Page 3
The Ontario Universities’ Application Centre
Preliminary Procedural Issues (see below for the substance of this RFP)
Intent to Respond
An email confirmation of the Vendor’s intent to respond to this RFP is required by Friday,
September 27, 2013, to the contact person identified on the cover page.
Inquiries
All inquiries regarding explanations and clarifications about the terms, conditions and requirements of
this RFP must be submitted in writing, by email only, to the contact person identified on the cover page
by no later than October 23, 2013. Failure to abide by this condition may result in the early
disqualification of a Vendor for this RFP. A response to any inquiry will be provided by the OUAC within
five business days of the date of an inquiry. The primary onus to interpret the RFP will remain with the
Vendor. The OUAC will not reply to any questions or requests for clarification submitted later than
October 23. Any written response from the OUAC to questions and requests for clarification will be
circulated to all Vendors to whom the RFP has been directed.
There will not be any closing date or time extensions of the RFP submission deadline for any Vendor, for
any reason.
A non-mandatory Vendor conference is scheduled to take place at the OUAC on Thursday, October 3,
2013, at 10:00 a.m. EST. If Vendors choose to take part in the conference, it may be in-person or by
telephone. Vendors must confirm their participation to the contact person identified on the cover page
no later than September 27, 2013.
Proposal Responses
Vendors must submit an electronic copy of their response with permission to make multiple copies.
Once submitted, the response material, exclusive of trademarks and logos, becomes the exclusive
property of the OUAC thereafter.
The OUAC will not reimburse Vendors for the cost of preparing a response to this RFP.
16 September 2013/Page 4
The Ontario Universities’ Application Centre
Evaluation Procedure
1) All responses must comply with all of the Mandatory Requirements. Responses that do not
comply with all of the Mandatory Requirements will be deemed non-compliant and will not
receive any further review or consideration.
2) It is understood and agreed to by all Vendors who submit a response to this RFP that
determination of the degree to which a Vendor’s response satisfies the requirements listed in
the RFP is at the sole and unfettered discretion of the OUAC.
3) Vendor responses that satisfy the Mandatory Requirements will be evaluated by the OUAC on
the following criteria, ranked in order of priority:
i.
The extent to which the product(s) meet the requirements
ii.
The financial status and stability of the Vendor’s organization
iii.
The stability and support for the Vendor’s proposed product(s)
iv.
Favourable references
v.
The cost of the product(s) proposed
Based on the above criteria, the OUAC reserves the right to eliminate any proposal that it, in its sole and
unfettered discretion, determines is not satisfactory.
It is understood and agreed to by all Vendors submitting a response to this RFP that the OUAC is under
no obligation to award any contract for this RFP.
16 September 2013/Page 5
The Ontario Universities’ Application Centre
RFP Evaluation Process Schedule
Event
Date
1. OUAC distributes RFP to Vendors
Monday, September 16, 2013
2. Deadline for Vendors to send email confirmation if they
intend to submit a bid
Friday, September 27, 2013
3. Deadline for Vendors to send email confirmation if they
intend to attend the Vendor Conference
Friday, September 27, 2013
4. Vendor Conference
Thursday, October 3, 2013
5. Deadline for Vendors to submit questions
Wednesday, October 23, 2013
6. Proposal due date and time
7. OUAC performs reference checks and Vendor follow up
8. Target date for the OUAC to complete its review of
proposals
Monday, November 4, 2013
12:00 p.m. ET
Tuesday, November 19, 2013 to
Monday, January 6, 2014
Tuesday, January 28, 2013
9. Anticipated period for the OUAC to make its decision
Wednesday, January 29, 2014 to
and select the number one (1) Vendor proposal; invitation
Monday, March 7, 2014
to participate in second stage of award process (Fit/Gap)
10. Fit/Gap process
March/April/May 2014
11. Final contract awarded
July 2014
16 September 2013/Page 6
The Ontario Universities’ Application Centre
Ontario Universities’ Application Centre
Request for Proposal
for an
Application Management System
16 September 2013/Page 7
The Ontario Universities’ Application Centre
OUAC RFP Outline
Contents
Preliminary Procedural Issues (see below for the substance of this RFP) .................................................... 4
Inquiries ....................................................................................................................................................... 4
Proposal Responses ...................................................................................................................................... 4
Evaluation Procedure .................................................................................................................................... 5
RFP Evaluation Process Schedule (to be confirmed) .................................................................................... 6
Introduction ................................................................................................................................................ 10
The Ontario Universities’ Application Centre ......................................................................................... 10
An Overview of the OUAC's Current Situation and Readiness for Change ............................................. 10
Award Process Overview ........................................................................................................................ 11
Fit/Gap Analysis Process (“FGAP”) .......................................................................................................... 11
Context diagram – Business Overview.................................................................................................... 13
Requirements Section ................................................................................................................................. 14
Evaluated Requirements – Response Format ......................................................................................... 14
Mandatory Requirements – Evaluated ....................................................................................................... 15
General Requirements – Evaluated ............................................................................................................ 16
“Master” Institution Tables – Evaluated ..................................................................................................... 18
Admission Application Requirements – Evaluated ..................................................................................... 20
Fee calculation, processing and audit requirements – Evaluated .............................................................. 22
Create Fees Structures ............................................................................................................................ 22
Calculate Application and Transcript Fees .............................................................................................. 22
Process Sponsors .................................................................................................................................... 23
Process Payments and Reconciliation..................................................................................................... 23
Process Refunds ...................................................................................................................................... 23
Fee Inquiries & Reports........................................................................................................................... 23
University Funds Distribution Calculation............................................................................................... 24
Technical Requirements – Evaluated .......................................................................................................... 25
16 September 2013/Page 8
The Ontario Universities’ Application Centre
General Technical Requirements ............................................................................................................ 25
Configurability ......................................................................................................................................... 26
Hardware ................................................................................................................................................ 26
Database ................................................................................................................................................. 26
Security ................................................................................................................................................... 27
Business Interfaces - Context .................................................................................................................. 28
Context Diagram – Business Interfaces .................................................................................................. 28
Interfaces ................................................................................................................................................ 32
Documentation ....................................................................................................................................... 33
References – Evaluated............................................................................................................................... 34
Vendor’s Corporate Information – Evaluated............................................................................................. 35
Vendor’s Support for Product – Evaluated ................................................................................................. 35
Implementation Questions – Information Only.......................................................................................... 37
Costing Details – Evaluated ......................................................................................................................... 38
Summary Table ....................................................................................................................................... 38
Costing Details – Staffing ........................................................................................................................ 39
Costing Details – Licenses ....................................................................................................................... 41
Costing Details – Product Support .......................................................................................................... 41
Costing Details – Customizations ............................................................................................................ 41
Costing Details – Training and Education ............................................................................................... 41
Costing Details – Other ........................................................................................................................... 42
Appendix A .................................................................................................................................................. 42
List of Ontario Universities served by the OUAC .................................................................................... 42
Appendix B .................................................................................................................................................. 44
Application Statistics as of July, 2013 ..................................................................................................... 44
Appendix C .................................................................................................................................................. 45
Administrative and Technical User Metrics as of July, 2013 .................................................................. 45
Appendix D .................................................................................................................................................. 47
Examples of English/French Presentation .............................................................................................. 47
16 September 2013/Page 9
The Ontario Universities’ Application Centre
Introduction
The Ontario Universities’ Application Centre
The Ontario Universities’ Application Centre (hereinafter referred to as “OUAC”) was founded
in 1971 by the Council of Ontario Universities (COU; formerly the Committee of Presidents of
the Universities of Ontario) and the Ontario Universities’ Council on Admissions.
With the encouragement and support of the provincial government and several Ontario university
organizations, coupled with the significant growth in the demand for postsecondary studies in Ontario,
there was a desire to improve a variety of enrollment management and planning activities. The OUAC
began partial operation in August 1971 and completed its first official processing cycle for first-year
undergraduate applications in the fall of 1972.
An Overview of the OUAC's Current Situation and Readiness for Change
Operating as a registered charity under the auspices of the COU, the OUAC provides application
management support services to the province’s 20 member institutions and the Royal Military College of
Canada (see Appendix A for a list of universities that the OUAC services), representing graduate,
undergraduate and professional postsecondary programs. Annually, more than 93,000 undergraduate
students apply to the Ontario universities of their choice. These students make some 418,000 program
application choices as they determine which educational path to follow. In total nearly 650,000
applications from all divisions were supported by the OUAC in 2013. See Appendix B for more
information on the number of applicants and applications serviced by the OUAC.
Universities benefit from the centralization of services provided by the OUAC through an improved
ability to control multiple acceptances of offers of admission, which helps to significantly reduce the
amount of duplication and costs in processing multiple applications for admission. Over the years, the
OUAC’s services have expanded into other areas, including: centralization of the distribution of
application materials worldwide; the electronic collection and distribution of university transcripts (the
OUAC acts as one of two “hubs” for managing electronic transcripts within the province); and the
production of various statistical reports that are used for government and university planning.
The OUAC has a Project Team in place, consisting of a Steering Committee and a Project Operations
Committee (subject matter experts representing the relevant OUAC business and technical areas). The
Steering Committee and Project Operations Committee have approved this RFP.
The OUAC's requirements have been documented under the auspices of the OUAC Project Operations
Committee, whose members have been designated to lead the implementation for their respective
business and technical areas. These requirements have been formally approved by the appropriate
subject matter experts on the Operations Project Committee. The OUAC requires a solution that will be
implemented in conjunction with the successful Vendor. To this end, Vendors are required to provide a
Preliminary Project Plan for product implementation.
16 September 2013/Page 10
The Ontario Universities’ Application Centre
Award Process Overview
The OUAC will use a two-stage award process. The first stage will involve an assessment of all qualifying
Vendor RFP responses to initially qualify and then rank the order of potential Vendors. Only those
Vendors qualified by the OUAC will go on to be rank ordered. If no Vendor is qualified there may be no
rank order created. If this situation occurs, the award process may then be terminated at the sole
discretion of the OUAC without any further obligation by the OUAC to any Vendor.
A required condition to be accepted by any Vendor before providing a response to this RFP and
participating in the Award process is that if a Vendor is selected, it agrees to fully and actively participate
in the second stage, a detailed Fit/Gap Analysis Process (herein the “FGAP”), in conjunction with OUAC
staff and in the manner and on the terms that they request. The proposed strategy, staffing, cost and
timelines for the FGAP will be negotiated with the participating Vendor and implemented in a manner
mutually agreed on by OUAC staff and the participating Vendor. The objective of the FGAP is for the
OUAC and the participating Vendor to validate and/or expand the Vendor’s Preliminary Project Plan to
arrive at a Working Project Plan. The Working Project Plan will include an agreement on the fixed cost
for implementation and a form of contract to be entered into that incorporates the Working Project
Plan terms and other standard terms and conditions for a contract (including the applicable legal
framework provisions set out above) to be signed as part of the Final Award.
The Vendor ranked by the OUAC as number one (1) will then be invited to participate in the second
stage of the award process. If the number one (1) ranked Vendor declines to participate in the second
stage, or during or after participation the OUAC determines in its sole discretion that the Vendor or its
Working Project Plan or any part of it as developed is not acceptable to the OUAC, then that Vendor will
be disqualified by the OUAC. The Vendor ranked as number two (2) will then be invited to participate in
the second stage of the award process and so on until the OUAC decides in its sole discretion to a make
a Final Award to one of the participating, rank ordered Vendors. The OUAC reserves and has the right to
decide in its sole discretion that none of the participating, rank ordered Vendors in the second stage of
the award process are acceptable and qualified for a Final Award. In that event, the OUAC may chose to
terminate the second stage of the award process without making any Final Award to any Vendor
without further or other obligation(s) by the OUAC to any Vendor.
A Final Award by the OUAC and the signing of the contract to be used for this project will only happen
when the OUAC, in its sole discretion, is satisfied that there has been a proper and satisfactory
conclusion to the FGAP. The OUAC may at any stage of the FGAP determine in its sole discretion that the
participating Vendor is not a satisfactory Vendor, disqualify that Vendor and offer participation in the
FGAP to the next ranked Vendor.
Fit/Gap Analysis Process (“FGAP”)
When and if a number one (1) ranked Vendor is identified, an Interim Services Agreement covering the
cost, strategy and timing of the FGAP exercise will be negotiated with that Vendor before commencing
the FGAP exercise.
16 September 2013/Page 11
The Ontario Universities’ Application Centre
A detailed FGAP analysis of the proposed product will be conducted by a team composed of persons
from the Vendor who are acceptable to the OUAC management team and OUAC staff. At the conclusion
of this process, the participating Vendor will be expected to confirm in writing to the OUAC that it can
provide the complete and agreed upon Working Project Plan for implementation of the proposed
solution. The participating Vendor’s Working Project Plan must confirm the project infrastructure,
including Vendor and OUAC staffing requirements, project process, timelines and milestones, project
deliverables and guaranteed implementation costs. The implementation costs set out in the Working
Project Plan will not be changed or increased in any way without prior written approval from the OUAC.
For example, any increase in implementation costs claimed by a Vendor at any time after the
commencement of the Working Project Plan that has only been discussed and authorized orally will not
be allowed or paid for by the OUAC without prior written confirmation.
16 September 2013/Page 12
The Ontario Universities’ Application Centre
Context Diagram – Business Overview
The key business functions performed at the OUAC are:
•
•
•
•
•
•
•
•
•
•
•
•
Processing applications
Managing application inquiry and changes
Processing application payments
Maintaining program fees
Collecting and presenting academic program information
Distributing and managing information (in and out)
Processing transcript
Processing grades
Communications with applicants and stakeholders
Distributing university funds
Creating statistical reports
Creating financial and management reports
16 September 2013/Page 13
The Ontario Universities’ Application Centre
Requirements Section
Evaluated Requirements – Response Format
Vendors are asked to provide a high-level, “no surprises”, fit-/gap-style response to every item in the
following requirements sections using the format illustrated below. Vendors are required to document
fit/gap responses with specific references to product documentation (hard copy, supplied DVDs, page
specific URLs, etc.) in the “Comments” section of the table (see the following example ).
Requirement
#
1
Requirement Description
Fit/Gap
Comment(s)
The system must support an online, easy
to use facility to access application
transaction audit logs (including user ID,
date and time for all transactions) that
allows users to track a change in the
information they “own” to the detailed
transaction that brought about the
change. Logs should track access to data,
as required, and there should be
configurable levels of tracking. Logs should
be accessible for ad hoc reporting.
Fit –
delivered,
configurable
functionality
See page 235 of User
Manual;
URL:
www.vendor.ca/logs/
configuration
DVD, chapter 24,
page 12
Definitions
Fit:
The requirement is met through a standard feature, which may involve configuration/setup of
the application and/or database through the use of tools/functionality included in the Vendor’s
product(s).
Gap:
The requirement cannot be met without business process revision (BPR) or customization. One
of the OUAC’s primary objectives is to acquire software that requires minimal customization.
Vendors should clearly indicate whether the proposed product(s) can meet the OUAC’s business
objective via a different process. If there is a BPR solution, then this should be indicated and
briefly described; otherwise, if customization is required, then this should be detailed as well.
Customization, in this context, implies a modification of the product’s software code as
delivered by the Vendor.
16 September 2013/Page 14
The Ontario Universities’ Application Centre
Mandatory Requirements – Evaluated
1) The system must be capable of supporting the management of multiple, independent,
admission application divisions or streams (e.g., undergrad, graduate and professional
program applications). Each division must maintain multiple universities and multiple
academic programs within those universities, including different program fees and
attributes.
2) Each division or stream must be capable of supporting multiple admission applications, from a
single institution to different institutions (i.e., University of Waterloo, University of Guelph,
University of Toronto) and multiple programs/options within each of those institutions. All
processing must be kept independent from other divisions within the same university.
3) The system must be capable of handling multiple acceptances of offers of admission based on
rules that may differ from division to division.
4) The system must be capable of allowing only one acceptance of an offer of admission per
division/stream. Further, the system must support a process in which an applicant should be
able to rescind their acceptance of an offer and accept an alternate offer within the same
division. At no time should an applicant be in a position of having two concurrent
acceptances of offers of admission within the same division or steam.
5) The system must offer services in both official languages (English and French).
6) The system must be fully capable of utilizing effective dating to allow for concurrent production
and future state set-up activities.
7) The system must provide a highly configurable, table driven, fee assessment and reporting
module to support fees assessment and allocation.
8) The system must support an online, easy to use facility to access application transaction audit
logs (including user ID, date and time for all transactions) that allows users to track a change
in the information they “own” to the detailed transaction that brought about the change.
Logs should track access to data, as required, and there should be configurable levels of
tracking. Logs should be accessible for ad hoc reporting.
9) Security must be implemented in a least privileged mode, whereby resources are protected by
default and action is required to allow access (users should only have access to the
resources they need to carry out their responsibilities).
16 September 2013/Page 15
The Ontario Universities’ Application Centre
General Requirements – Evaluated
10) The system should
i. be table driven
ii. allow database tables and fields to be modified by staff with appropriate
security
iii. allow for the creation of database tables with defined ownership and access
iv. allow algorithms and “rules-based” processing on bolt-on database tables
11) The system, as defined by users, should:
i. support fields designated as mandatory or not
ii. allow users to assign default values
iii. retain some user-defined fields for recurring entry
12) Field validation should take place at time of data entry.
13) Data should only be entered once into the system and should be accessible in all modules.
14) The system should support a facility that allows for any table entry, function or process to be
manually overridden.
15) Data should be transferable with user-defined criteria for new fiscal, academic, calendar or
other user-defined periods.
16) The system should provide for real-time updates.
17) The system should provide for remote access.
18) The system should provide a facility to apply mass changes.
19) The system should have no inherent restrictions or limits on multiple occurrences of data (e.g.,
there should be no limit to the number of addresses, telephone numbers, programs, etc.)
20) The system should be compliant with Postsecondary Electronic Standards Council (PESC)
standards or the Vendor must provide details about becoming PESC/XML compliant in their
business.
21) The system should conform to the requirements of the Accessibility for Ontarians with
Disabilities Act (AODA) or the Vendor must provide details about plans to support the AODA
requirements that come into effect in 2014 in their business plan (i.e., all new websites and
web content must conform to WCAG 2.0 level A; however, by 2021 all existing websites and
web content must conform to WCAG 2.0 level AA, excluding live captioning and audio
description. It is current OUAC policy to support level AA for all new web content).
22) The system should provide user-defined customizable fields on all pages/forms with the ability
to add attributes as required (e.g., new applicant data, new programs, etc.).
23) Data should be portable across platforms and applications and the system should be capable of
accepting information from other information systems, from other areas of the OUAC and
from administration systems at client or other institutions. The system should support a
simple facility for users to upload (e.g., program information from remote locations) and
download files in formats compatible with a variety of productivity tools.
24) The system should have a secure, comprehensive electronic communications module to
facilitate contact with external stakeholders (e.g., applicants, referees, sponsors, etc.) that
allows for the merging of data into pre-defined forms and the integration of a word
processing facility that merges form letters with database information, along with the
selection of digitized signatures, logos, etc. The system should allow for individual or mass
distribution via electronic mail or Canada Post. The system should track and record incoming
and outgoing correspondence, however generated and in whatever form, as part of an
16 September 2013/Page 16
The Ontario Universities’ Application Centre
25)
26)
27)
28)
29)
30)
31)
32)
33)
34)
35)
36)
37)
applicant’s record. Applicants and administrative users should be able to view an applicant’s
complete communication history (i.e., a “dashboard” view).
The system should support configurable triggers that allow for the automated creation of
communications listed above.
The system should support custom message areas on reports, screens and pages based on userdefined rules.
All users of the system should use the same screens to view applicant data.
i. Within similar views, a user will only see the data they have the appropriate
access to.
ii. Within similar views, a user will only see and perform actions they have security
access to.
The system should have workflow-like capabilities to support administrative users and:
i. provide multiple levels of electronic approvals such that actions requiring
further processing are routed to the appropriate individual or group, and
become part of that person’s or group’s “to-do” list.;
ii. permit broadcast messages, alerts and/or emails to be sent to individuals and
groups with notification of “to do” items;
iii. allow user-defined changes to the hierarchy and/or process maps; and
iv. support automated processing of configured application steps if the application
data meets specific criteria.
The system should have multimedia storage, retrieval and presentation capability (e.g., for
images, audio and audiovisual media).
The system should allow for presentation of selected data in a predetermined language
regardless of an applicant's language preference at the time of log in (e.g., information
about academic programs taught in French must always be in French, even if the applicant
selected the English language at login). See Appendix D.
The system should be able to generate unique IDs that may have check digit capability.
The system should have the ability to store and cross-reference multiple unique ID numbers for
an applicant (e.g., university-specific ID, Ontario Education Number, etc.).
Administrative users should have the ability to:
i. re-arrange, move, hide or show fields on any form;
ii. create a “favourites” menu for quicker navigation; and
iii. use smart pick lists of acceptable values for data entry.
The system should provide an intuitive ad hoc query and reporting capability, which can be
extended to any data field for which a user has authorized access.
The system should allow for online inquiry with the ability for administrative users to set filters
(e.g., division, applicant, period, etc.).
The system should provide online help features:
i. general application help
ii. form or screen help
iii. field help
User, administrator and configuration/customization manuals should be accessible online.
16 September 2013/Page 17
The Ontario Universities’ Application Centre
“Master” Institution Tables – Evaluated
The OUAC maintains “master” institution tables that record details of colleges, universities, CEGEPs and
other postsecondary institutions of higher learning, including the programs these institution offer. The
tables contain similar information about all Ontario secondary schools and various other Canadian
secondary schools.
38) The system should support the storage, retention and management of the following examples of
data and other requirements for postsecondary institutions (this is not an exhaustive list):
i. The name of the university
ii. The address of the university
iii. Accredited or non-accredited designation
iv. URL information
v. Various Enhanced Student Information System data elements ( see
http://www23.statcan.gc.ca/imdb-bmdi/document/5017_D2_T3_V2-eng.pdf )
vi. Support for the grouping of affiliated institutions (e.g., Western main, Western
Brescia, Western Huron, and Western King's campuses).
vii. Support for contact information, such as:
 name and email address of the Registrar
 name and email address of the Director of Graduate Studies
 name and email address of the Director of Undergraduate Programs
 name and email address of the Director of Secondary School Liaison
 names and email addresses of other faculty contacts
 names of Department/Program Directors
39) To support applications, the system should be capable of maintaining term-sensitive university
program information, such as:
i. Formal name of the program
ii. Program major
iii. Admission requirements, including, but not limited to:
 Minimum entering average
 Prerequisite courses and minimum grade requirements
 Other requisite requirements (e.g., portfolios, essays, etc.)
40) The system should support term-sensitive marketing related program information, required for
eINFO (http://www.electronicinfo.ca/en/index.php?j=1&flash=1 ), which may be different
from formal program information.
41) The system should support blocking activity associated with programs that have been deemed
inactive.
42) The system should support the storage, retention and management of the following examples of
data and other requirements for secondary schools and other non-postsecondary
institutions (this is not an exhaustive list):
i. The name and address of the school
ii. Accredited or non-accredited designation
iii. Support for the grouping of schools within their school board area or precinct
iv. School board number to which the school belongs
v. MIDENT number
vi. Whether the school is semestered
16 September 2013/Page 18
The Ontario Universities’ Application Centre
vii.
viii.
ix.



Whether the school is public or private
Whether the school offers the International Baccalaureate
Contact information such as:
name and email address of the Principal
name and email address of the Director of Guidance
names of the heads of departments
16 September 2013/Page 19
The Ontario Universities’ Application Centre
Admission Application Requirements – Evaluated
43) The system should support capturing and maintaining individual student data, including, but not
limited to:
i. Multiple student names (e.g., last or surname, first, middle and preferred
names)
ii. Multiple addresses
iii. Multiple telephone numbers (e.g., home, cell, business)
iv. Multiple email addresses
v. Date of birth
vi. Gender
vii. Immigration and citizenship status, including date of entry into Canada for nonCanadian citizens
viii. First language spoken (English, French or other)
ix. Language of correspondence
x. Aboriginal status
xi. First generation indicator
44) Other data that the system should capture as part of a student’s record includes, but is not
limited to:
i. Referee letters (created online)
ii. Essays (created online)
iii. Detailed drawings, letters of verification, etc.
iv. Test scores
v. Secondary school grades
vi. Transcript data, including, but not limited to, institution, program, major,
grades, GPA, rank, awards, etc.
vii. Immigration documents and other forms of official correspondence
viii. Emails
ix. Non-academic activities (e.g., athletics, extracurricular activity, employment,
volunteer participation, etc.)
45) The system supports capturing expressions of students’ interest in:
i. Residence housing
ii. Financial aid
46) The system supports admission processes for graduate, undergraduate, joint, collaborative,
cooperative, blended, etc. for programs that could have multiple admissions during the
same term/academic year.
47) The system should be capable of supporting rank of choice for students with multiple program
applications within the same division.
48) The system should store a wide variety of third party data/information such as LSAT, TOEFL,
IELTS, MCAT and other test scores, secondary school grades and postsecondary transcript
data. Information received must be associated with a specific applicant and admissions
period.
49) The system provides the ability to administer undergraduate, graduate and professional
applications and to:
i. limit students’ acceptance of offers of admission to one per division or stream
ii. open and close time period for admission applications by a variety of userdefined rules and variables (e.g., date, immigration status, number of
applications received or accepted, etc.)
16 September 2013/Page 20
The Ontario Universities’ Application Centre
iii. support various types of alternate program and level of admission offers (e.g.,
year one, advanced standing)
50) The system provides the ability to manually or automatically cancel or withdraw applications
based on user-defined rules.
51) The system supports the automatic production of application acknowledgements, requests for
missing data (e.g., transcripts, referee letters, etc.), notices of updates to offers of admission
to applicants via hard copy, email, web, etc. based on user-defined rules.
52) The system supports an automatic process of confirming when a student’s application is
complete and only then allows further processing of the application.
16 September 2013/Page 21
The Ontario Universities’ Application Centre
Fee Calculation, Processing and Audit Requirements – Evaluated
Create Fees Structures
53) The fees table should identify:
i. the type of transaction (e.g., base application fee, additional choice application
fee, special charge, etc.)
ii. the revenue account distributions used for allocations
iii. whether a fee is taxable and the type of tax
iv. whether a fee is tax deductible
54) The system should support a fee table that can automatically allocate fees to revenue accounts
based on user-defined date criteria.
55) The system should support global entry changes to the fee table.
Calculate Application and Transcript Fees
56) The system is able to assess fees by each of the following or a combination of:
i. per-application
ii. a group of applications for a fixed fee
iii. a specific fee per application
iv. penalty fees (prorated and non-prorated)
v. ancillary fees
vi. special charge(s) per application
vii. other user-defined rules
57) The system supports real-time (re)calculation of fees for individuals, and batch (re)calculation of
selected groups of applicants (division/stream, etc), or all applicants for a defined period.
58) The system supports the calculation of “discounts” based on user-defined criteria (e.g., multiple
applications).
59) The system supports specific overrides to charges in real-time and via batch input screens.
System overrides should not be adjusted by subsequent recalculations.
60) The system provides for fee exemptions/reductions by division/stream, fee type or other userdefined criteria.
61) The system is configurable to allow multiple program applications from within the same
division/stream that can be associated with a “base” fee.
62) The system supports charging a “base” application fee only once per application within a
division or stream.
63) The system should support charging additional fees if the maximum number of program
applications associated with a “base” fee from within the same division/stream is reached.
64) The system should track program application drop and add activity within a division or stream to
determine when to apply additional program applications fees within the following
parameters:
i. there are no charges incurred for drop and add activity within the same
university (i.e., if a choice is being added in place of a previously dropped choice
at the same university, there is no fee incurred)
ii. the drop and add provision does not apply to all divisions or streams
iii. the drop and add activity only applies to “base” and additional program
application fees
16 September 2013/Page 22
The Ontario Universities’ Application Centre
65)
66)
The system should support the tracking of a program application identifier for each drop
and add transaction.
The system should support the calculation and reconciliation of fees for transcripts ordered
by applicants and others (as authorized by the applicant).
Process Sponsors
67) The system should allow for the creation of sponsor records to enable applicant fee payment
and sponsor debiting.
Process Payments and Reconciliation
68)
69)
70)
71)
72)
73)
The system supports payment batch processing from external sources (e.g., banks, web,
third parties [sponsors] and applies these payments against accounts).
The system supports the assignment of payment item types (e.g., cheque, credit card, debit
card, etc.).
The system supports the capture of payments without valid applicant IDs into a suspense
account and the subsequent correction of these payments to the proper account.
The system supports a common end-user view for application payment balancing and
reconciliation.
The system should associate payments with the fee details that the payment applies to.
The system should support a “write-off” process.
Process Refunds
74) The system supports various refund structures and allocation account distributions for any nonrefunded portion of charges, with differential refund criteria per change or cancellation
type.
75) The system supports the issuance of refunds to third parties (e.g., estates, sponsors, banks,
scholarships). The account should record to whom the refund was paid.
Fee Inquiries and Reports
76) The system allows for drill down to financial transaction details from screens that display
summary totals.
77) The system generates summary and transaction detail reports for various types of fee charges,
payments (including over- and under-payments, credit card, etc.), refunds, etc.
78)
A fee summary view should be accessible from any page where an applicant can be
selected.
79)
The system should produce reports by division/stream, group of selected students, period,
etc.
80)
The system should support detailed and summary-style queries to satisfy audit needs.
81)
The system should support detailed and summary-style queries to satisfy financial needs.
82) The system should support detailed and summary-style queries to satisfy reconciliation of all
transcript request and payment activities.
16 September 2013/Page 23
The Ontario Universities’ Application Centre
University Funds Distribution Calculation
83) The system should support the calculation, by user-defined rules, of funds (currently $44M
annually) to be distributed to Ontario universities that take into account, but are not
necessarily limited to, a combination of:
i. Division
ii. Total paid applications
iii. Operating grant ratios
iv. Transcript fee revenue
v. Supplemental fee revenue
vi. Service charge fees (OUAC)
vii. Special service fees (e.g., GPA calculation)
viii. Credit card premiums
16 September 2013/Page 24
The Ontario Universities’ Application Centre
Technical Requirements – Evaluated
General Technical Requirements
84) The application source code should be available and customizable.
85) The system should provide a highly configurable web interface.
86) The system should include a GUI development tool to facilitate screen customizations for
Windows-based and web-based clients.
87) The GUI development tool should include the extensive ability to do custom programming.
88) The system provides the ability to easily extract data (online and/or in a format that will allow
downloads) and compile statistical reports using any field or combination of fields through
the use of supplied end user reporting tool(s) for ad hoc statistical reporting and other tools.
Reports should be generated using a standard commercial reporting package or readily
usable proprietary software. There should be flexible report parameter selection criteria in
all standard reports.
89) The application structure should allow for a multi-tiered client/server architecture with firewalls
between the tiers (i.e., presentation, application, and database servers).
90) For “batch” processes there should be some form of centralized “job” scheduling tool (e.g., the
ability to run processes at set times or in a specific sequence) and job monitoring capability.
Processes should have defined interdependencies.
91) The OUAC should be able to backup the system while online transactions are being posted.
Provide details about whether your system supports “hot” backups while supporting live
business; whether this functionality requires special software; and whether additional
software is required. Identify the required products and provide pricing for each in the
“Other” component of the Costing section. In addition, list any third party software that
your solution requires or recommends, such as an external document management
package, external workflow package and an application testing tool. Provide a list of such
products and provide pricing for each in the “Other” component of the Costing section.
92) There should be a straightforward method of tracking and managing software installations and
changes. Software changes should be easy to identify and back out.
93) All software fixes/patches should contain adequate documentation of the errors/bugs being
fixed and detailed instructions for the application of the patch. In the case that the patch
also includes additional functionality, this new functionality should also be documented.
94) Provide your recommended (not minimum) desktop computer configuration for access by a
typical:
i. administrative casual user
ii. administrative power user
iii. technical user
iv. programmer/developer
95) Provide your recommended (not minimum) browser and version for access by a typical
applicant user.
96) Identify each browser and current version supported by your application and your
process/strategy for dealing with:
i. newly released browser versions; how long after the release will new browsers
be supported by the application
16 September 2013/Page 25
The Ontario Universities’ Application Centre
ii. older browser versions; how long are older browsers typically supported (e.g.,
Internet Explorer, version 7).
97) Vendor response to problem reports is not to exceed two hours in the case where the system is
completely unusable and not to exceed 24 hours for all other problems.
98) Although extensive data conversion is not envisioned by the OUAC, tools for data import and
export should be provided. Identify and document the tools provided with the base
application. If third party tools are recommended, identify and document them as well.
Include any additional costs in the “Other” component of the Costing section.
99) Identify and document the tools provided for tuning system and application performance. If
third party tools are recommended, identify and document them as well. Include any
additional costs in the “Other” component of the Costing section.
100) The application should work with both IPv4 and IPv6 and tracking/logs, etc., required for
visibility and troubleshooting.
101) The system should provide or support connection to a third party content management
system.
Configurability
102)
103)
The system should support a high degree of configurability to reduce the need for
customization. Identify and document the extent to which your solution can be configured
to implement and maintain your solution.
Identify any specific limitations to the configurability of your solution.
Hardware
Please be aware that currently the OUAC’s data centre contains several IBM POWER servers running
the IBM i Version 7.1 operating system, several HP DL380 servers running VMware vSphere Version
5.1 in support of approximately sixty virtual machines running Red Hat Linux 5, Red Hat Linux 6,
Windows Server 2008 and Windows Server 2008 R2.
104)
105)
106)
If necessary, the OUAC will acquire hardware to support the chosen Vendor’s application.
Identify your recommendation for preferred platform and operating system, and specify
your preferred configuration (CPUs, CPU speed, memory, etc.) of the preferred hardware.
List any other recommendations that would optimize performance of your application.
Identify your top three recommendations, in descending preference, for a preferred
operating system to support your application. Include some indication of what percentage
each solution represents from within your install base.
Identify if new releases and fixes for your software are released simultaneously for all
platforms, operating systems and databases. If not, provide the expected lag time for
platforms/environments other than your preferred environments.
Database
107)
108)
109)
The OUAC will acquire database software as part of the solution to support the chosen
Vendor’s application. Identify your recommendation for preferred database solution.
Identify, in descending sequence based on preference, other database software that your
application may fully utilize. Include some indication of what percentage each solution
represents from within your install base.
Confirm if your preferred database solution may run on a different platform and operating
system.
16 September 2013/Page 26
The Ontario Universities’ Application Centre
110)
Identify and document your data retention strategy. If third party tools are necessary to
archive data, identify the product(s) required and provide pricing for each in the “Other”
component of the Costing section.
Security
111)
112)
113)
114)
115)
116)
117)
118)
119)
120)
121)
122)
123)
124)
125)
126)
127)
The system should support encryption of data traffic between servers.
The system should provide audit reports that detail:
i. which users have access to which objects; and
ii. which users accessed sensitive objects by time/date.
The system should support a one-way hash approach for passwords and challenge
questions/answers.
The system should support a mandatory sign-on that allows for a user-defined minimum
length, including a user-selected combination of numeric and upper/lower case alpha
characters.
The system should support the requirement for administrative passwords to “expire” after a
user-defined period of time (e.g., 60 to 90 days).
The system should support an account lock out based on a user-defined maximum number
of unsuccessful log-in attempts.
The system should support automatic logout with configurable timing.
The system should provide all users (applicants and administrative) with a warning prior to
automated sign-out (for AODA).
The system should support a default security profile for all online applicants.
Web applicants do not require a systems account.
The system supports the ability to define user accounts. Group profiles and functionality
required for each user and/or group is defined on an individual or group basis and access
can be controlled by function, by data entity (controlled at the user level), by field
(controlled at the division or stream levels) or by a range of field values.
All inquiry and reporting tools only make visible the data the user is allowed to see.
System query and reporting capability should access the database in a manner that ensures
user authorizations defined within the system will be enforced.
Online services or API calls should include validation of the user’s/system’s authority to use
the functionality as well as validation of acceptable data or parameters as input.
Web-based applications must support the use of SSL or equivalent.
The system should support the use of third party VPN software.
The system should support definition of ownership (entity or group) of data elements,
functions and processes.
16 September 2013/Page 27
The Ontario Universities’ Application Centre
Business Interfaces - Context
This information is provided in order to present a better contextual overview of the role and importance
that business interfaces play at the OUAC.
The OUAC is the central hub for the collection and consolidation of data for students’ applications for
admission to graduate, undergraduate and professional postsecondary programs within Ontario. To
support these applications, the OUAC utilizes many different forms of standard, third party and
proprietary interfaces with a wide variety of secondary, postsecondary, government, financial, and
professional institutions and organizations from around the world.
Once collected, data is consolidated and, in support of an application for admission, electronically
transferred via a proprietary interface to the various universities and professional programs that the
OUAC supports.
The following diagram presents a high level overview of the various interfaces between the application
submission and processing environment of the OUAC and our external parties and stakeholders. Some
of these interfaces are currently managed manually while others are automated. The objective at the
OUAC is to automate and streamline our interface processes. The following section in this document
provides a more detailed, but still high level, view of the information exchange between the application
processes and entities represented in this diagram.
Context Diagram – Business Interfaces
16 September 2013/Page 28
The Ontario Universities’ Application Centre
From Ontario University Applicants:
• Applications
• Application amendments
• Supplemental documents (e.g., personal submission)
• Application fee payments
• Transcript requests
• Responses to offers of admission
• Correspondence
To Ontario University Applicants:
• Confirmation – creation of account
• Confirmation - password changes
• Confirmation – admission application submission
• Confirmation – payment received
• Decisions on offers of admission
• Status of transcript requests
• Status of payments
• Correspondence
From Financial Institutions:
• Payment settlement amounts (credit card, Western Union Business Solutions – Global
Pay for Students)
• Payment files (Online banking)
From Payment Processors:
• Credit card real-time payment verification
• Credit card chargebacks
• Credit card payment transaction file
• Western Union payment transaction file
To Payment Processors:
• Credit card real-time payment request authorization
To Ontario Universities:
 Application details and related supplemental documents
 Grades (various sources)
 Test scores
 References
 Responses to offers of admission
 Transcripts
 University funds distribution
 Statistics and registration data
16 September 2013/Page 29
The Ontario Universities’ Application Centre
From Ontario Universities:
 Programs and program attributes
 Decision on offers of admission
 Transcripts
From the Ontario College Application Service (OCAS):
• College transcripts
• Previous secondary school grades (eTMS )
• Ontario university transcript requests
To the Ontario College Application Service (OCAS):
• College transcript requests
• Previous secondary school grades requests (eTMS)
• Ontario university transcripts
To Ontario Government
 Statistics
From Ontario Government
 Registration data
From CREPUQ

CEGEP grades

Requests for CEGEP grades
To CREPUQ
From Government of British Columbia (BC):
• Files with BC secondary school grades
To Government of British Columbia (BC)
• Requests for BC secondary school grades
From Out of Province Universities:
 Requests for Ontario secondary school grades
 Requests for transcripts
To Out of Province Universities:
 Secondary school grades
To Ontario College of Teachers
 Transcripts
16 September 2013/Page 30
The Ontario Universities’ Application Centre
From Referees:
• Reference documents
To Referees:
•
Acknowledgements
From Payment Sponsors:
• Payment agreement
• Payment files
To Payment Sponsors:
• Payment correspondence
• Request for applicant payment approval
From Educational Institutions and Education Services (e.g., LSAC/AAMC):
• LSAT/MCAT scores
From Ontario Secondary School Boards and Guidance Counsellors:
• Student demographics for potential university bound students. Note: The data is used
to create an initial applicant record. This data must not be available for viewing by any
user until the applicant has actually applied. Universities should not have access to
this data.
• Grade 11/12 academic data
To Ontario Secondary School Boards and Guidance Counsellors:
• PIN letters for students (to facilitate personalized logins) based on the initial applicant
record created.
16 September 2013/Page 31
The Ontario Universities’ Application Centre
Interfaces
128)
129)
130)
131)
132)
133)
134)
135)
136)
137)
138)
139)
140)
The system is able to utilize Canada Post approved software or services for address
verification, formatting, routing and correction.
The system should have connectivity or compatibility with RJS Document Management
software (http://www.rjssoftware.com/) to provide scanned images to various functions of
the system for input and retrieval.
The system should readily interface with Sage300 (http://na.sage.com/sage-300-erp)
accounting software.
The system should support authentication and authorization using Microsoft’s Active
Directory.
The system should support single sign-on via Microsoft Active Directory.
Any API provided by the Vendor should provide security credentials for each transaction.
Use of each API can be limited by the user ID and data that can be accessed.
The system should readily interface with Toronto Dominion Merchant Services hosted fee
payment product, “Online Mart”, for credit card verification and payment authorization. By
policy, no application at the OUAC shall store full credit card information. For verification
and identification reasons, the following may be stored electronically at the OUAC:
i. Authorization number
ii. Masked Primary Account Number
iii. Name of credit card holder
iv. Processing date
v. Type of credit card
The system should readily interface with Trusted Link, an EDI software product, to support
the OUAC’s role as the EDI “hub” for the universities in the province.
The system should readily interface with the OUAC’s “Grade Collection Module,” in which
secondary school grades are transmitted, by the various secondary school boards, to the
OUAC using a proprietary standard. Grade data is first scrubbed for data quality purposes
and then imported, stored and managed within the application. It is important to note that
this data is used to create an initial applicant record. This data must not be available for
viewing by any user until the applicant has actually submitted an application.
The system should readily interface with the OUAC’s CEGEP “Grade Collection Module,” in
which CEGEP grades are transmitted, by the various CEGEPs, to the OUAC using a
proprietary standard. Grade data is first scrubbed for data quality purposes and then
imported, stored and managed within the application.
The system should readily interface with the OUAC’s Province of British Columbia (BC)
“Grade Collection Module,” in which BC secondary school grades are transmitted by the
government of BC to the OUAC using a proprietary standard. Grade data is first scrubbed for
data quality purposes and then imported, stored and managed within the application.
The system should readily interface with the OUAC’s “out of province university secondary
school grade transfer module”, in which Ontario secondary school students who have
applied to a non-Ontario university (in addition to a university in Ontario) may authorize the
out-of-province university to request the OUAC transfer their secondary school grades,
using a proprietary standard. The out-of-province university request triggers a return
response on the part of the OUAC.
The system should readily interface with the OCAS eTMS system
(http://www.ocas.ca/services/etms.html ), in which secondary school grades of previous
16 September 2013/Page 32
The Ontario Universities’ Application Centre
141)
142)
143)
144)
145)
146)
secondary school students are transmitted from OCAS to the OUAC using a PESC/XML
standard. Grade data is first scrubbed for data quality purposes and then imported, stored
and managed within the application.
The system should readily interface with the OUAC’s “University response interface”, in
which individual university responses to admission applications are transmitted to the OUAC
using a proprietary standard. Data is first scrubbed for quality purposes and is then
imported, stored and managed within the application.
The system should provide a highly customizable web interface, including AODA compliance,
to maximize clarity and data quality. The web interface should include extensive parsing for
allowable responses and characters for the English and French languages; support
dependencies providing only allowable values or lists based on previous responses as well as
requiring/presenting different fields, dependent on the type of application; and prevents
finalization of an application or submission until dependant information is completed.
The OUAC may decide to continue to use its current web front-end. To that end, the system
should support interfacing to web pages developed in PHP; in this scenario, any proposed
solution should provide:
i. APIs or web services that leverage the applications functionality and database
ii. a workflow or similar functionality to facilitate the processing of all “steps” of
the application
Identify and document the tools provided for building/maintaining interfaces and ensuring
data integrity. If third party tools are recommended, identify and document them as well.
Include any additional costs in the “Other” component of the Costing section.
The OUAC currently uses a HP’s automated testing tool “Unified Functional Testing”
(https://hpln.hp.com/page/unified-functional-testing-add). Indicate whether this tool is
compatible with your product. If you recommend another automated testing tool include
any additional costs in the “Other” component of the Costing section.
Document the extent to which the system facilitates online services or remote procedure
calls to initiate actions on other systems as required to facilitate application or data
processing.
Documentation
147)
148)
Provide an example of your technical documentation (URL, DVD, hard copy).
Provide an example of your user documentation (URL, DVD, hard copy).
16 September 2013/Page 33
The Ontario Universities’ Application Centre
References – Evaluated
Provide both business and technical references from any other organization or institution engaged in
activities similar to the OUAC or the three most appropriate North American postsecondary reference
projects where your product has been implemented and where the client considers the system to be
fully operational.
Every Vendor consents to the OUAC contacting and obtaining any information relevant to this RFP from
these references and any others identified by the Vendor in its proposal, as well as from any other
persons, firms or agencies in which OUAC wishes to contact. Provide contact names, street and email
addresses, and phone numbers for each reference or reference project, as well as:






List of implemented modules (with text description)
How long implemented
Version originally implemented
Hardware environment
Database environment
Integration tools used
Canadian postsecondary references and Canadian organizations with similar administrative complexities
and size are preferred.
16 September 2013/Page 34
The Ontario Universities’ Application Centre
Vendor’s Corporate Information – Evaluated
149)
150)
151)
152)
Submit your firm's “Annual Accountant prepared Financial Statement(s) or Report” for the
last two fiscal years. If requested, the OUAC will sign an agreement of non-disclosure in a
form acceptable to the OUAC’s legal counsel that guarantees the confidentiality of any
submitted statements or reports.
If the following information is not contained in your annual statements or reports, please
respond to the following questions:
i. How many people do you employ worldwide and in Canada? How many of
those employees are full-time?
ii. How many employees worldwide are involved in the development and support
of the proposed product(s)?
Are there any outstanding lawsuits against your firm related to any of the products that you
propose? Are there any outstanding lawsuits that may impact your firm’s ability to conform
to all of the terms of this contract? If the answer is yes, provide the specifics as to the issues
and parties involved and the amounts claimed.
How many customers worldwide are using the proposed product(s)? How many of those
customers are based in Canada?
Vendor’s Support for Product – Evaluated
153)
154)
155)
156)
157)
158)
159)
160)
161)
162)
163)
Describe your support for internationalization and localization of your product, specifically
as it applies to Canadian installations.
Is your firm considering discontinuing or significantly revising any of the products/services
that you propose in this RFP within the next five years?
Describe how your firm provides product support.
Is there a local support organization for the products you propose?
Does your organization provide 24/7 support? If not, describe how support services are
provided to customers outside of your normal, local support hours and to what geographic
areas support may be directed.
Describe how product problems are reported, handled and resolved. Include the committed
resolution times for each severity of incident.
Describe any escalation procedures for issues not resolved in a timely manner.
What percent of first level support resources have been with your organization for more
than one year?
Describe any additional or enhanced support services made available during a “go live”
period. Are there any additional costs for such support? If yes, identify and document.
Include any additional costs in the “Other” component of the Costing section.
Provide a description of how any corrections or upgrades are delivered, applied and
controlled. Elaborate on the scope and variety of maintenance activities recommended for
ongoing maintenance and upgrades. Identify the type of upgrade, frequency of upgrade, if
the upgrade is normally done with the online application systems up or down, and the
amount of downtime that is typically incurred for such an upgrade. If some customers
commonly use specific tactics to minimize the impact on the online application system, even
though not always recommended, reference them here.
Describe and itemize how much downtime is usually required annually for the online
application system by customers using this product who are performing the recommended
upgrades and patches.
16 September 2013/Page 35
The Ontario Universities’ Application Centre
164)
165)
166)
167)
168)
169)
Describe any applicable application quality control processes for new versions and individual
or cumulated patches of your product(s).
Identify if new releases and fixes for your software are released simultaneously for all
platforms, operating systems and databases. If not, provide the expected lag time for
platforms/environments other than your preferred environments.
Describe, based on prior implementations of the proposed product suite, the average time it
takes for a new customer to become self-sufficient in supporting the product internally
without the use of Vendor or other external consulting personnel.
Describe any business process(es) that allow(s) customers to submit enhancement requests.
Describe how enhancement requests are considered, and how enhancement requests are
addressed and implemented by your product development and other associated product
developers.
Confirm that the application has undergone a detailed security assessment by an external
agency within the past two years, including details about the intent and scope of the
assessment. If several assessments have been initiated with different intents, include details
about each, and provide a summary of the results and details on any outstanding
recommendations.
16 September 2013/Page 36
The Ontario Universities’ Application Centre
Implementation Questions – Information Only
170)
171)
172)
173)
174)
In your judgment, what is the typical time required to implement your proposed solution?
If your firm does not supply employees as project implementation staff, identify, in
descending order, your recommendation of firms or organizations that are fully familiar with
your product and may supply implementation resources.
In your judgment, how many environments or instances will be required to support the
implementation effort?
Identify the use of each instance.
Provide an estimate and some high level details of the amount of lead time required to
install and certify your application and database.
16 September 2013/Page 37
The Ontario Universities’ Application Centre
Costing Details – Evaluated
Summary Table
Note: Canadian currency is the applicable currency. Indicate if quoting in USD. Insert final totals for each
area in the appropriate line and cell.
Category
License(s) - Base application
production environment
Other environments
Sub-Category
1)
2)
3)
1)
2)
3)
Cost
Taxes
Application
Tools
Database
Application
Tools
Database
License(s) - Related software
Staffing
Estimated cost of customizations
Training and education
Business users
Technical users
Product support
During implementation
After implementation
Other foreseeable costs
Other?
Other?
Other?
Total
16 September 2013/Page 38
The Ontario Universities’ Application Centre
Costing Details – Staffing
Provide your best estimate of staffing and agreement resource requirements for the duration of the
implementation project in months. Assume that the project will start upon completion of the Fit/Gap
analysis, which is intended to validate the “preferred” Vendor’s proposal.
Describe staffing requirements for implementing your product solution in terms of what you deem
appropriate as a project team with staffing from both the OUAC and your firm. If you are proposing a
multi-year implementation, please breakdown the information on an annual basis.
For all positions on the project team, identify on a year-to-year basis:
i.
ii.
iii.
iv.
v.
vi.
vii.
title and quantity of each position
brief role description
filled by OUAC or consultant
duration of job/position
percentage of their time required
per diem rate (not required for OUAC staff)
any miscellaneous fees
Example:
Position: Project Director
Role description: Manages and directs project work, issues status reports, meets with Operations
Committee regularly and Steering Committee as required.
Filled by: Vendor
Duration: 24 months
% of time required: 100%
Rate: $1850/day
Misc. fees: $1200/week for travel and expenses
Position:
Role Description:
Filled by:
Duration:
% of time required:
Rate:
Misc. fees:
Position:
Role Description:
Filled by:
Duration:
% of time required:
Rate:
Misc .fees:
16 September 2013/Page 39
The Ontario Universities’ Application Centre
Use additional pages as necessary.
16 September 2013/Page 40
The Ontario Universities’ Application Centre
Costing Details – Licenses
Base application and any related software:
For each cost item, explicitly list the type/class/tier of license proposed and any restrictions in terms of
number of users (concurrent or otherwise), seats, instances, CPUs and any other restrictions that might
require license upgrade based on increased or different type of use. If there are higher classes of
licenses that might be required in the future as the OUAC continues to grow, provide specifics.
Based on the nature of OUAC business, we have the potential for thousands of online applicants to
access their application simultaneously. Confirm if there are any implied restrictions built into this
proposal based on the concurrent users/type of licenses proposed, including at the level of database,
tools, or third party applications recommended.
Production environment:
i.
Application
ii.
Tools
iii.
Database
Other environments (e.g., development – test – QA – staging):
i.
Application
ii.
Tools
iii.
Database
Costing Details – Product Support
Provide details on the cost of your recommended product support:
1. During implementation
2. Annual or ongoing (post implementation)
Costing Details – Customizations
1. Identify any anticipated cost of customization. In this context, customization work would be
identified by the Vendor based on the Fit/Gap responses to business requirements. Assume that
the work is performed by Vendor resources.
2. Detail your methodology and process for assessing and determining the cost of customization. If
there are multiple methodologies, identify and provide details on each.
Costing Details – Training and Education
Describe and cost any recommended or proposed training/education:
1.
2.
3.
4.
5.
6.
the topic(s) of course(s)
whether technical or end-user (e.g., programmer/developer, DBA, power user, admin user, etc.)
location(s) of training (e.g., Toronto, outside Canada)
course delivery options (e.g., web-based, self-taught, instructor lead, etc.)
expected travel and accommodation needs
any incentive pricing options (e.g., volume discounts)
16 September 2013/Page 41
The Ontario Universities’ Application Centre
Costing Details – Other
Identify any other costs that may reasonably be foreseen that have not previously been identified.
Appendix A
List of Ontario Universities Served by the OUAC
Algoma University
Brock University
Carleton University
University of Guelph
University of Guelph-Humber
Lakehead University
Lakehead University – Orillia
Laurentian University / Université Laurentienne
Université de Hearst
McMaster University
Nipissing University
Nipissing University – Muskoka
OCAD University
University of Ottawa / Université d’Ottawa
Saint Paul University / Université St. Paul
Queen’s University
Ryerson University
University of Toronto
University of Toronto Mississauga (UTM)
University of Toronto Scarborough (UTSC)
Trent University
Trent University – Oshawa
University of Ontario Institute of Technology
University of Waterloo
Conrad Grebel University College
Renison University College
St. Jerome’s University
St. Paul’s University College
Western University
Brescia University College
Huron University College
King’s University College
Wilfrid Laurier University
Wilfrid Laurier University – Brantford
University of Windsor
York University
16 September 2013/Page 42
The Ontario Universities’ Application Centre
York University – Glendon Campus / Campus Glendon
16 September 2013/Page 43
The Ontario Universities’ Application Centre
Appendix B
Application Statistics as of July 2013
Division
Undergraduate Programs
Professional Programs
Secondary school **
Non-secondary school
Law programs
Medical programs
Rehabilitation Sciences
Teacher Education
Totals
# of Applicants
93,407
60,660
5,123
5,982
2,935
9,428
177,535
# of Applications
417,918
159,524
17,926
19,673
7,423
27,421
649,885
** Numbers represent fall, full-time, first year only
16 September 2013/Page 44
The Ontario Universities’ Application Centre
Appendix C
Administrative and Technical User Metrics as of July 2013
User Category
Admin Users – OUAC
Admin Users – University Community
Admin Users – Secondary school
counsellors
Technical Users – OUAC
Number
25
400
3,000+
Activities
User configuration
User configuration
Application data input
35
System updates, configuration,
maintenance, development
16 September 2013/Page 45
The Ontario Universities’ Application Centre
16 September 2013/Page 46
The Ontario Universities’ Application Centre
Appendix D
Examples of English/French Presentation
16 September 2013/Page 47
The Ontario Universities’ Application Centre