Create a free account and describe your company. With the trial, CanPursue checks every opportunity against it and explains the fit.
Create free accountCreate a free account to see past contracts like this one: who won and at what price.
Create free accountTrade Agreement: NAFTA/AIT/Canada FTAs with Peru/Colombia/Panama Tendering Procedures: All interested suppliers may submit a bid Non-Competitive Procurement Strategy: Exclusive Rights Comprehensive Land Claim Agreement: No Vendor Name and Address: ERMS Solutions Limited 2916 South Sheridan Way Suite 200 Oakville Ontario Canada L6J7J8 Nature of Requirements:
Please Note, for any additional information regarding this ACAN or to obtain copy of the criteria for assessment of the statement of capabilities, please contact the following Contracting Authority:
Ivy Pui 819-956-1560 Ivy.pui@tpsgc-pwgsc.gc.ca
EMERGENCY NOTIFICATION OFF-PREMISE SOFTWARE SOLUTION (ENOSS) - ERMS ADVANTAGE PLATFORM
An ACAN is a public notice indicating to the supplier community that a department or agency intends to award a contract for goods, services or construction to a pre-identified supplier, thereby allowing other suppliers to signal their interest in bidding, by submitting a statement of capabilities. If no supplier submits a statement of capabilities that meets the requirements set out in the ACAN, on or before theclosing date stated in the ACAN, the contracting officer may then proceed with the award to the pre-identified supplier.
DEFINITION OF REQUIREMENT FOR NATIONAL RESEARCH COUNCIL OF CANADA
National Research Council of Canada (NRC) is responsible for many sites across the country and as such as the requirement to effectively communicate with key contacts during an Emergency/Business Continuity Planning (BCP) event.
There is a risk that NRC’s capacity to respond to catastrophic crises, includingthose related to natural and accidental hazards may have consequences for industry partners, collaborators and Canadians.
NRC must implement an Emergency Notification Off-Premise Software Solution (ENOSS) in order to broadcast notifications of such threats or events. The ENOSS provided by the Service Provider must deliver, support and allow the broadcast notifications of threats or Emergency/BCP Events to at least 4,800 different stakeholders.
The system will be used as a means of communicating with NRC employees, partners, students, guest workers, contractors and tenants.
NRC intends to enter into a sole source contract with ERMS Solutions Limited for the purpose of procuring the ERMS Advantage Platform suite including associated maintenance and support service, training and professional services.
CRITERIA FOR ASSESSMENT OF THE STATEMENT OF CAPABILITIES
Any interested supplier must demonstrate by way of a statement of capabilities that their product and services meet the following requirements:
M1. The ENOSS proposed to meet this requirement must be ?off-the-shelf?, meaning that each component of software is commercially available and requires no further research and development and is partof an existing product line with a field-proven operational history (that is, it has not simply been tested in a laboratory or experimental environment).
M2. The Supplier agrees to supply Canada with an Emergency Notification Off-Premise Software Solution (ENOSS); that delivers, allows and supports a secure, authenticated and trusted computing environment located in Canada at all times; and that has, all pre-production, production and post production, in Canada, in a Protected A environment; for atleast a three years period of time.
M3. The Supplier must have delivered an emergency notification system as a hosted application for at least 3 years.
M4. The ENOSS must be designed specifically for emergency notifications with the capability of broadcasting mass notifications via multiple methods either simultaneously or in a cascading sequence to multiple contacts within 5 minutes.
M5. The ENOSS must enable, supportand deliver the functionality to control the number of calls into an organization to avoid flooding lines during mass notification.
M6. The ENOSS must enable, support and deliver the functionality to send out a mass notification to at least 4,800 different stakeholders that include federal government departments, companies and individuals.
M7. The ENOSS must enable, support and deliver the functionality to send routine messages that are clearly distinct from any emergency messages.
M8. All hardware, software and data must be hosted at facilities owned or leased, operated and secured in Canada at all times in a Protected A environment.
M9. All system functionality must be operated without client having to install hardware or software. Database capacity, data channels and phone ports are not purchased by the Client.
M10. The Supplier must be able to handle and secure information up to and including Protected A in facilities and equipment to be used to store and process Administrator, User and Contact information and all messages.
M11. The ENOSS must enable and support Administrators to control access privileges, such as access requests, requests for changes to personal information, and changes to passwords, provided that they have appropriate access control permissions.
M12. The ENOSS must enable and support each Administrator, User and Contact to change their password at any time.
M13. The ENOSS must enable, support and deliver the functionality to force each Administrator, User and Contact to configure a password in a predetermined manner with a minimum number of characters, including capitals, numbers and symbols.
M14. The Supplier must be able to host client data in high availability facilities with zero failover time and automatic recovery.
M15. If a Disaster, Emergency or Hazard renders the Supplier’s primary data centre inoperable, the ENOSS must enable, support and deliver the functionality to reroute client data dynamically so that it functions without interruption.
M16. The ENOSS must have a multi-tier, multi-server fault tolerant architecture with full redundancy whereby the primary Contacts database server and all functions are housed in Canada and their backup capability is housed in separate locations in Canada separated by a provincial boundary (at least 200km) so that an Emergency that affects one facility will not affect the others.
M17. The Supplier must ensure that the Clientsdatabase never resides outside of Canada’s land boundaries.
M18. The ENOSS must enable and support the designation of a minimum of 10 Master Administrators with full access and Regional Administrators with limited access.
M19. The ENOSS must have a Graphical User Interface (GUI) available in both English and French for Administrators and Users.
M20. The ENOSS must be accessible to Administrators and Users on web browsers including Internet Explorer (min 9.0), Google Chrome and Mozilla Firefox for Windows and compatible with 128 bit encryption
M21. The ENOSS must enable, support and deliver a quick launch feature that allows an Administrator to initiate a Message from a single screen after logging in to the ENOSS.
M22. The ENOSS must enable, support and deliver practice modes (i.e. test environment) that allow the Administrators and Users to use any facet of the ENOSS without affecting real time content or capabilities of the productionenvironment.
M23. The ENOSS must enable, support and deliver the functionality to send local or long-distance voice Messages of up to 1 minute in duration (exclusive of dialing time, ringing time and voice-mail response time) to at least 4,800 Contacts including Government of Canada Contacts within 5 minutes of being sent.
M24. The ENOSS must enable and support the delivery of voice messages in French and English with voices using contemporary Canadian accents.
M25. The ENOSS must enable, support and deliver the functionality to send text-based SMS Messages of a minimum of 140 characters or e-mail messages of up to 500 words to at least 4,800 Contacts including Government of Canada Contacts within 5 minutesof being sent.
M26. The ENOSS must be fully functional and operational 24 hours a day, 7 days a week, with at least 99.99% availability throughout the Contract period. In the event of an outage, the Supplier will advise the client of the outage and the impacts on the ENOSS. In the event of a scheduled outage, the Supplier must advise the Client well in advance of the outage.
M27. The ENOSS must enable, support and deliver the functionality to use short code in order to allow for the sending of true SMS vs Email-to-SMS.
M28. The ENOSS must enable Administrators to recover a Contact record that has been deleted for up to 5 days after deletion.
M29. The ENOSS must enable, support and deliver the functionality to generate automatic database backups to one or more other locations in Canada at least once every 24 hours.
M30. The ENOSS must allow for the establishment and maintenance of a database of Administrator and User Profiles that will include:
Full name Position Region Branch An individual ID number Primary 24 hour emergency coordinates Secondary 24 hour emergency coordinates Cell phone number Business Fax number Pager number E-mail address Designated alternate Blackberry number Permissions assigned
M31. The ENOSS must allow Master Administrators to have full access permissions and to perform all functions of the ENOSS.
M32. The ENOSS must enable, support and deliver the functionality to securely import Contact information from existing databases (delivered to the vendor in one or more electronic files) such as MS Active Directory, PeopleSoft/Oracle HR, BCP Software, SQL, MS SQL Server, csv (e.g.Excel), XMS, MS Outlook and mdb files - without requiring manual (human) intervention - at intervals prescribed by the Client or as required. The client must have the ability to import Contact information manually if so desired. This process is to be delivered through a web services Application Programming Interface (API) using a standards-based Service-Oriented Architecture.
M33. The ENOSS must enable, support and deliver the functionality to accommodate the creation of 45 data fields per record.
M34. The ENOSS must enable and support Administrators, Users and Contacts to view and manually edit the information in their own profiles, directly within the ENSS, provided they have appropriate access control permissions.
M35. The ENOSS must enable and support Administrators andUsers to add, modify, and delete Contacts and Contact information, directly within the ENOSS, provided they have appropriate access control permissions.
M36. The ENOSS must enable, support and deliver the functionality to automatically assign a unique user ID to each Administrator and User. The administrator must then be allowed to set a temporary password which can later be modified by the account holder.
M37. The ENOSS must enable and support Administrators and Users to create groups of Contacts based on variables such as Mode, Group, Region or other criteria identified in the data fields of each Contact's record.
M38. The ENOSS must enable and support Administrators and Users to create hierarchical groupings so that groups include up to 50 levels of sub-groups in order to appropriately reflect an organization's structure.
M39. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to define a Contact to be a member of up to 50 groups.
M40. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to conduct a search or filter Contacts based on criteria identified in the data fields of each Contact's record. The ENOSS must also have the capability to quickly create unique Groups using the results of the search function.
M41 The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to sort Contact lists alphabetically or, using any other criteria identified in the data fields of each Contact's record. The ENOSS must also have the capability to quickly create unique Groups using the results of the sort function.
M42. The ENOSS must have the capability to list stakeholders by language of correspondence in order to allow the sending of only French messages to French speaking stakeholders and English to English speaking Stakeholders.
M43. the ENOSS must enable and support users to access the service for Contact management, message creation (voice or text-based) or message transmission purposes via the following methods and Devices: (i) Computer (via the internet either through cable or WI-FI); (ii) Landline telephone; (iii) Cellular telephone; (iv) Smartphone; (v) Personal digital assistant; (vi) Telecommunications device for the deaf; (vii) Voice over Internet protocol; and (viii) Satellite telephone.
M44. The ENOSS must enable and support Administrators and Users to create and record voice and text-based messages in French and English for present or future use.
M45. The ENOSS must enable and support Administrators and Users to customize pre-recorded messages by adding introductory and/or closing statements.
M46. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to hear the voice message and/or to read the text-based message before it is sent.
M47. The ENOSS must have the capability to recognize and understand time zones.
M48. The ENOSS must enable, support and deliver the functionality to send messages to Contacts via the following media: (i) Landline telephone; (ii) Cellular telephone; (iii) Smartphone, including telephone, text and e-mail communications; (iv) Personal Digital Assistant; (v) SMS text message; (vi) E-mail; (vii) Facsimile; (viii) Pager; (iv) Telecommunication Device for the Deaf; and (x) Satellite telephone.
M49. The ENOSS must have an effective safeguard (such as a prompt message) that prevents routine messages from being sent out as emergency notifications.
M50. The ENOSS must enable, support and deliver the functionality to make local and long distance calls within Canada and the United States, and to dial international numbers and phone numbers with extensions.
M51. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to set the default order of devices used to notify Contacts but also allow Users and Contacts to override the order if they have the appropriate permissions to do so.
M52. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to select Messages in either French or English and to automatically transmit them in the Contact's pre-selected corresponding language.
M53. The ENOSS must enable, support and deliver the functionality to allow Users to send a recorded voice message and a text message in a single notification to all selected Contacts for delivery through all types of media.
M54. Either globally or on a message-by-message basis, the ENOSS must enable, support and deliver the functionality to allow Administrators or Users Initiating a message to customize the telephone number displayed (caller ID) for voice Messages and the e-mail addresses for text-based Messages.
M55. The ENOSS must enable, support and deliver the functionality to escalate messages when the intended Contact has not confirmed receipt of the correspondence (with 3 levels of person-to-person escalation) within a given period of time. If no confirmation of receipt is received within a given period of time, then the message must be redirected to an alternate point of contact if one has been designated (see M59).
M56. The ENOSS must enable, support and deliver the functionality to allow Users and Administrators to select the number of delivery attempts through all Contact paths.
M57. The ENOSS must enable, support and deliver the functionality to allow e-mails to attach multiple files (e.g. text, spreadsheet and images) and send them to an e-mail device.
M58. The ENOSS must enable, support and deliver the functionality to allow an Administrator or User to stop, recall or replace a Message initiated by them or another Administrator or User with the same level of permissions at any time during the Message sending process.
M59. The ENOSS must enable, support and deliver the functionality to automatically send messages to a back-up Contact if a primary Contact does not acknowledge receipt of the initial message within a period of time defined by the sender.
M60. The ENOSS must have the capability to send notifications systematically until apredetermined number of affirmative responses are received.
M61. The ENOSS must have the capability to send notifications for the purpose of soliciting a positive or negative acknowledgement from the recipient, such as "are you OK", "Not OK".
M62. The ENOSS must enable, support and deliver the functionality to allow Contacts to listen to a voice Message as often as desired with a single key press.
M63. The ENOSS must enable, support and deliver thefunctionality to seek and receive acknowledgements of Messages through the device types identified, with the exception of facsimile and pager and SMS transmissions.
M64. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to re-send a notification to only those Contacts who did not respond to the original notification.
M65. The ENOSS must enable, support and deliver the functionality to leave a Message when a voice-delivered message reaches an answering machine or voice-mail. If a message is left, the ENOSS must also contact the back-up Contact if the message was left on the primary Contact's voice mail box.
M66. The electronic voice transmitter must use Canadian (English and French) accents.
M67. The ENOSS must enable, support and deliver the functionality to allow Contacts to send custom text-based messages in response to messages.
M68. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to set up recurring Messages.
M69. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to schedule a notification to be sent at a future date and time.
M70. The ENOSS must enable, support and deliver the functionality to distinguish when a live Contact is reached versus when an answering machine or voicemail has been reached on voice-delivered devices.
M71. The ENOSS must enable, support and deliver the functionality to provide a real-time dashboard for each active notification broadcast allowing Administrators and Users to view broadcast parameters (e.g. devices, start time, duration and number of cycles) and see status of broadcast results (e.g. confirmation and responses).
M72. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to view a history of Message results for the entire period of the contract.
M73. The ENOSS must enable, supportand deliver the functionality to produce real-time Message broadcast result reports using all application data which contains, but is not limited to, all of the following information: (i) Name, date and time of the Message; (ii) Name of the Administrator or User who initiated the broadcast; (iii) Number of redial attempts requested by initiator; (iv) Summary statistics, including total notified Contacts, total confirming receipt/not confirming receipt, percentage confirming receipt/not confirming receipt. If a polling Message, a total for each response. This information must be collated for individual messages and cumulatively; and (v) Detailed calling information, including call-result of each attempt within the broadcast, theaddresses and associated phone numbers attempted, the attempt number and the result (e.g., confirmed with date and time, busy, no answer or voicemail).
M74. The ENOSS must enable, support and deliver the functionality to export all types of report data in CSV, XLS, HTML, or PDF formats, as defined by an Administrator or User.
M75. The ENOSS must enable, support and deliver the functionality to allow Administrators and Users to print real-time reports of any data or statistics directly from the GUI.
M76. Upon request, the Supplier must be able to search and generate reports based on user-defined criteria and/or key words including wild card searches. In addition, the Supplier must retain a permanent record of all reports.
APPLICABILITY OF THE TRADE AGREEMENT(S) TO THE PROCUREMENT
- Agreement on Internal Trade (AIT) - North American Free Trade Agreement (NAFTA)
JUSTIFICATION FOR THE PRE-IDENTIFIED SUPPLIER
ERMS Advantage is a fully hosted, off-the-shelf, web-based emergency notification and management solution that is used by organizations for the purpose of managing their vital emergency processes, enabling effective communications and management of crisis situations and incidents. ERMS Advantage supports NRC's emergencynotification requirements without any additional configuration to their IT infrastructure.
ERMS Advantage will allow NRC to effectively manage and maintain its self-registered contact data and issue security threat notifications in fully redundant and secure hosting facilities.
ERMS Advantage fully satisfies NRC’s requirements for a Bilingual (English/French) Emergency Mass Notification System as per the criteria identified.
ERMS Advantage fully satisfies NRC’s security requirements for a hosted Protected ?A? solution.
GOVERNMENT CONTRACTS REGULATIONS EXCEPTION(S)
Section 6 of the Government Contract Regulations is being invoked in this procurement as only one person or firm is capable of performing the contract.
EXCLUSIONS AND/OR LIMITED TENDERING REASONS
Annex 4.4 article 506.12(b) of the AIT is applicable on the basis of limited tendering where there is an absence of competition for technical reasons and the goods or services can be supplied only by a particular supplierand no alternative or substitute exists, respectively.
Article 1016.2(b) of NAFTA is applicable on the basis of limited tendering due to reasons where, for works of art, or for reasons connected with the protection of patents, copyrights or other exclusive rights, or proprietary information or where there is an absence of competition for technical reasons, the goods or services can be supplied only by a particular supplier and no reasonable alternative or substitute exists.
OWNERSHIP OF INTELLECTUAL PROPERTY
Ownership of any Foreground Intellectual Property arising out of the proposed contract will vest in the Contractor.
THE PERIOD OF THE PROPOSED CONTRACT OR THE DELIVERY DATE(S)
The proposed contract is for a period of 1 year, plus 4 one-year irrevocable options. All delivery mentioned in the requirement shall be delivered within 10 days of Contract award.
ERMS Solutions Limited 2916 S Sheridan Way #300 Oakville, Ontario L6J 7J8
SUPPLIERS' RIGHT TO SUBMIT A STATEMENT OF CAPABILITIES
Suppliers who consider themselves fully qualified and available to provide the goods, services or construction services described in the ACAN, may submit a statement of capabilities in writing to the contact person identified in this notice on or before the closing date of this notice. The statement of capabilities must clearly demonstrate how the supplier meets the advertised requirements.
The conditions of the developer's shrink-wrap license are not acceptable to the Crown. This software is proprietary, and the proposed Contractor must have the authority to negotiate the terms and conditions of the contract and the related software licensing terms including, but not limited to, limitation of liability, indemnification, transferability of license, termination/refund to the Crown. Documents may be submitted in either official language of Canada
INQUIRIES AND SUBMISSION OF STATEMENTS OF CAPABILITIES
Ivy Pui Contracting Authority Public Works and Government Services Canada Gatineau, Québec, Canada (K1A 0S5) ivy.pui@tpsgc-pwgsc.gc.ca Telephone 819-956-1560 Government of Canada
Delivery Date: Above-mentioned
You are hereby notified that the government intends to negotiate with one firm only as identified above. Should you have any questions concerning this requirement, contact the contracting officer identified above.
An Advance Contract Award Notice (ACAN) allows departments and agencies to post a notice, for no less than fifteen (15) calendar days, indicating to the supplier community that it intends to award a good, service or construction contract to a pre-identified contractor. If no other supplier submits, on or before the closing date, a Statement of Capabilities that meets the requirements set out in the ACAN, the contracting authority may then proceed with the award. However, should a Statement of Capabilities be found to meet the requirements set out in the ACAN, then the contracting authority will proceed to a full tendering process.
Suppliers who consider themselves fully qualified and available to provide the services/goods described herein, may submit a statement of capabilities in writing to the contact person identified in this Notice on or before the closing date of this Notice. The statement of capabilities must clearly demonstrate how the supplier meets the advertised requirements.
The PWGSC file number, the contracting officer's name and the closing date of the ACAN must appear on the outside of the envelope in block letters or, in the case of a facsimile transmission, on the covering page.
The Crown retains the right to negotiate with suppliers on any procurement.
Documents may be submitted in either official language of Canada.
Not stated in the notice: procurement type, procurement method, selection criteria, region of delivery, region of opportunity, expected contract period, end user
No amendments observed.
No attachments listed in the open data.
No contact listed in the open data.