Emergency Notification Software Sol

Trade 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:

Brock Flemming
873-469-4653
Brock.flemming@pwgsc-tpsgc.gc.ca


EMERGENCY NOTIFICATION SOFTWARE SOLUTION (ENSS) - 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 apre-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 the closing date stated in the ACAN, the contracting officer may then proceed with the award to the pre-identified supplier.


DEFINITION OF REQUIREMENT - FOR NATURAL RESOURCES CANADA

Natural Resource Canada (NRCan) is responsible for many sites across the country and as such there is a requirement to effectively communicate with key contacts during an Emergency/BCP event. There is a risk that NRCan’s capacity to respond to catastrophic crises, including those related to natural and accidental hazards (e.g., disease, weather, etc.) may have consequences for the various sectors under NRCan’s mandate and/or to Canadians.  NRCan must implement an Emergency Notification Software Solution (ENSS) in order to broadcast notifications of such threats or events.

The ENSS provided by the Service Provider must be able to send out a mass notification to at least 5000 employees within Natural Resource Canada. The ENSS will be used within NRCan as a notification instrument for their own employees, students, contractors and for business continuity purposes.

Canada intends to enter into a sole source contract with ERMS Corporation for the purpose of procuring the ERMS Advantage Platform suite including associating maintenance and support service, training and professional services. Canada reserves the right to add additional clients to this contract at the same price, and under the same terms and conditions, as granted to NRCan.








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:


Requirements:

NRCan has a requirement for the supply of an Emergency Response Management Solution (ERMS) that will deliver, allow and support the broadcast notifications of threats or Emergency/BCP Events. The ENSS is required to providing the following requirements;

ESSENTIAL  REQUIREMENTS:

M1. The software 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 part of an existing product line with a field-proven operational history (that is, it has not simply been tested in a laboratory or experimental environment).

EXPERIENCE REQUIREMENTS:

M2. The Supplier must have delivered an ENSS as a Supplier's hosted application for at least three years. 

SERVICE ARCHITECTURE REQUIREMENTS:

M3.  Service Design: The ENSS 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.

M4. Service Design: The ENSS must include the ability to send routine messages that are clearly distinct from any emergency messages.

M5. Call Throttling: The ENSS must have the ability to control the number of calls into an organization to avoid flooding the lines during a mass notification.

M6.  Proprietorship: All hardware, software and data (apart from Client's owned systems) must be hosted at facilities owned or leased, operated and secured by the Supplier in Canada.

M7. 2.5. Requirements for Client Operation: The Client must not be required to install any hardware or software to operate any facets of the ENSS. Database capacity, data channels and phone ports are not purchased by the Client.


SECURITY REQUIREMENTS:

M8. Industrial Security Standards: The selected Supplier must have the ability to handle and secure information up to and including PROTECTED A in accordance with Public Works and Government Services Canada's Industrial Security Standards. These standards apply to all facilities and equipment used to store and process Administrator, User and Contact information and all messages.

M9. Access Privileges: The ENSS must enable 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.

M10. Password Change: The ENSS must permit each Administrator, User and Contact to change their password at any time.

M11. Password Strength: The ENSS must force eachAdministrator, User and Contact to configure a password in a predetermined manner with a minimum number of characters, including capitals, numbers and symbols.

RESILIENCY REQUIREMENTS:

M12. Recovery: Client data must be hosted in high-availabilityfacilities with zero failover time and automatic recovery.

M13. Disaster Recovery: If a Disaster, Emergency or Hazard renders the Supplier's primary data centre inoperable, Client data must be dynamically rerouted so that it functions without interruption.

M14. Back-Up Facilities and Services: The ENSS must have a multi-tier, multi-server fault tolerant architecture with full redundancy whereby the primary Contacts database server and all ENSS functions are housed in Canada and their back-up capability is housed in separate locations in Canada separated by a provincial boundary (at least 200 km) so that an Emergency that affects one facility will not affect the others.

M15. Location of Data Servers: The ENSS must ensure that the Client's database never resides outside of Canada's land boundaries.

M16. Permissions and Access Controls: The ENSS must enable and support the designation of a minimum of 10 Master Administrators with full access and Regional Administrators with limited access.


GENERAL OPERATION REQUIREMENTS:

M17. User Interfaces: The Supplier must ensure that the ENSS provides graphical user interfaces (GUIs) in both English and French for Administrators and Users.

M18. Browsers: The ENSS must be accessible to Administrators and Users on web browsers including Internet Explorer (min version 9.0), Apple Safari (min version 5.1), Google Chrome (min version 17.0) and Mozilla Firefox (min version 10.0) for Windows - and compatible with 128-bit encryption.

M19. Quick Launch: The ENSS must have a quick-launch feature that allows an Administrator to initiate a Message from a single screen after logging in to the ENSS.

M20. Practice Modes: The ENSS must have practice modes (i.e., a test environment) that allow the Administrators and Users to use any facet of the ENSS without affecting real-time content or capabilities of the ENSS and the database (i.e., the production environment).

M21.  Self-Registration: The ENSS must allow users to self-register and update their own profile information at any time.

M22. Mapping: The ENSS Application must have a “map” function that allows selection of a selected radius surrounding an event which allows notifications sent to only the selected geographic area.

OUTPUT

M23. Voice Messages: The ENSS must 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 6,000 registered Contacts within 5 minutes of being sent. 

M24. Voice Message Language: Voice messages must be delivered in French and English with voices using contemporary Canadian accents.

M25. Text-based Messages: The ENSS must send text-based SMS Messages of a minimum of 140 characters or e-mail messages ofup to 500 words to at least 6,000 registered Contacts within 5 minutes of being sent.

M26. Reliability: The ENSS 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 ENSS. In the event of a scheduled outage, the Supplier will advise the Client well in advance of the outage.

M27. Native SMS in Canada: The ENSS must use short code in order to allow for the sending of true SMS versus email-to-SMS.

DATABASE

M28. Data Recovery: The ENSS must enable Administrators to recover a Contact record that has been deleted for up to 5 days after deletion

M29. Database Backup: The ENSS must generate automatic database backups to one or more other locations in Canada at least once every 24 hours.

ADMINISTRATOR, USER AND CONTACT INFORMATION MANAGEMENT 

M30. Administrator and User Profiles: The ENSS must allow for theestablishment and maintenance of a database of Administrator and User Profiles that include the following:
(i). Full name
(ii). Position
(iii). Region
(iv). Branch
(v). An individual ID number
(vi). Primary 24 hour emergency coordinates
(vii). Secondary 24 hour emergency coordinates
(viii). Cell phone number
(ix). Business Fax number
(x). Pager number
(xi). E-mail address
(xii). Designated alternate
(xiii). Blackberry number
(xiv). Permissions assigned.
(xv). The ENSS must allow Master Administrators to have full access permissions and to perform all functions of the ENSS.

M31. Import Formats for Contact Information: The ENSS must securely import Contact information from existing databases (delivered to the Supplier in one or more electronic files) such as Microsoft Active Directory, PeopleSoft/Oracle HR, BCP Software, SQL, MS SQL Server, NetHris, HRIS database, and CSV (e.g. Excel), XML, 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 using a standards-based Service-Oriented Architecture.

M32. Contact Data Fields: The ENSS must accommodate the creation of 45 data fields per record.

M33. Data Revision: The ENSS must enable 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.

M34. Data Revision: The ENSS must enable Administrators and Users to add, modify, and delete Contacts and Contact information, directly within the ENSS, provided they have appropriate access control permissions.

M35. Log-in Data: The ENSS must automatically assign a unique user ID for each Administrator and User. The Administrator must then be allowed to set a temporary password which can later be modified by the account holder.  




CONTACT GROUPS 

M36. Creation: The ENSS must enable 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.

M37. Hierarchical Groups: The ENSS must enable 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.

M38. Number of Groups: The ENSS must allow Administrators and Users to define a Contact to be a member of up to 50 groups.

M39. Search feature: The ENSS must 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 ENSS must also have the capability to quickly create unique Groups using the results of the search function.

M40. Sort features: The ENSS must 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 ENSS must also have the capability to quickly create unique Groups using the results of the sort function.

M41. Sorting Stakeholders' by Language: The ENSS 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.

MESSAGE INITIATION

M42. Service Access: The ENSS must enable Administrators and 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). i. Computer (via the internet either through cable or WI-FI);
(ii). ii. Landline telephone;
(iii). iii. Cellular telephone;
(iv). iv. Smartphone;
(v). v. Personal digital assistant;
(vi). vi. Telecommunications device for the deaf;
(vii). vii. Voice over Internet protocol; and
(viii). viii.Satellite telephone.


M43. Message Creation: The ENSS must enable Administrators and Users to create and record voice and text-based messages in French and English for present or future use.

M44. Customizing Messages: The ENSS must enable Administrators and Usersto customize pre-recorded messages by adding introductory and/or closing statements.

M45. Message verification: The ENSS must allow Administrators and Users to hear the voice message and/or to read the text-based message before it is sent.

M46. Time Zone Recognition: The ENSS must have the capability to recognize and understand time zones.

MESSAGE TRANSMISSION

M47. Media: The ENSS must send messages to Contacts via the following media:
(i). i. Landline telephone;
(ii). ii. Cellular telephone;
(iii). iii. Smartphone, including telephone, text and e-mail communications;
(iv). iv. Personal Digital Assistant;
(v). v. SMS text message;
(vi). vi. E-mail;
(vii). vii. Facsimile;
(viii). viii.Pager;
(ix). ix. Telecommunication Device for the Deaf; and
(x). x. Satellite telephone.

M48. Safeguards: The ENSS must have an effective safeguard (such as a prompt message) that prevents routine messages from being sent out as emergency notifications and requests if the Administrators or Users has sought approval prior to sending a notification.

M49. Phone Number Types: The ENSS must have the ability to make local and long distance calls within Canada and the United States. The ENSS must also have the ability to dial international numbers and phone numbers with extensions.

M50. Order of Contact Methods: The ENSS must 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.

M51. Language of Message and Contacts: The ENSS must 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.

M52. Simultaneous Transmission: The ENSS must allow Users to send a recorded voice message and a text message in a single notification to all selected Contacts for delivery through the  media listed in 11.1.

M53. Caller ID: Either globally or on a message-by-message basis, the ENSS must allow Administrators and Users initiating a message to customize the telephone number displayed (caller ID) for voice Messages and the e-mail addresses for text-based Messages.

M54. Escalation: The ENSS must escalatemessages 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 will be redirected to an alternate point of contact if one has been designated see 11.12.

M55.  Delivery Attempts: The ENSS must allow Users and Administrators to select the number of delivery attempts through all Contact paths.

M56. E-mail Attachments: The ENSS must allow e-mails to attach multiple files (e.g. text, spreadsheet and images) and send them to an e mail device.  

M57. Message Control: The ENSS must allow an Administrator or User to stop, recall or replace a Message initiated by themor another Administrator or User with the same level of permissions at any time during the Message sending process. 

M58. Back-Up Contacts: The ENSS must 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. 

M59. First to Respond: The ENSS must have the capability to send notifications systematically until a predetermined number of affirmative responses are received.

M60. Roll Call: The ENSS 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".


MESSAGE DELIVERY FEATURES

M61. Voice Message Repeat: The ENSS must allow Contacts to listen to a voice Message as often as desired with a single key press.

M62. Acknowledgements: The ENSS must seek and receive acknowledgements of Messages through the device types identified in 11.1, with the exception of facsimile and pager and SMS transmissions.

M63. Re-send: The ENSS must allow Administrators and Users to re-send a notification to only those Contacts who did not respond to the original notification.

M64.  Voice-Mail: The ENSS must leave a Message when a voice-delivered message reaches an answering machine or voice-mail. If a message is left, the ENSS must also contact the back-up Contact if the message was left on the primary Contact's voice mail box.

M65. Electronic Voice: The electronic voice transmitter must use Canadian (English and French) accents.

M66. Custom Response: The ENSS must allow Contacts to send custom text-based messages in response to messages.

MESSAGE MANAGEMENT

M67. Recurring Messages: The ENSS must allow Administrators and Users to set up recurring Messages. 

M68. Scheduling: The ENSS must allow Administrators and Users to schedule a notification to be sent at a future date and time.

M69. Voice-Mail: The ENSS must distinguish when a live Contact is reached versus when an answering machine or voicemail has been reached on voice-delivered devices.

REPORTING

M70. Dashboard: The ENSS must 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).

M71. History: The ENSS must allow Administrators and Users to view a history of Message results for the entire period of the contract.

M72. Audit Trail: The ENSS must produce real-time Message broadcast result reports using all application data which contains, but is not limited to, all of the following information:
(i). i. Name, date and time of the Message;
(ii). ii. Name of the Administrator or User who initiated the broadcast;
(iii). iii. Number of redial attempts requested by initiator;
(iv). iv. Summary statistics, including total notified Contacts, total confirming receipt/not
(v). confirming receipt,percentage confirming receipt/not confirming receipt. If a polling Message,
(vi). a total for each response. This information must be collated for individual messages and
(vii). cumulatively; and
(viii). v. Detailed calling information, including call-result of each attempt within the broadcast, the
(ix). addresses and associated phone numbers attempted, the attempt number and the result
(x). (e.g., confirmed with date and time, busy, no answer or voicemail).

M73. Export: The ENSS must export all types of report data in CSV, XLS, HTML, or PDF formats, as defined by an Administrator or User. 

M74. Printing: The ENSS must allow Administrators and Users to print real-time reports of any data or statistics directly from the GUI.

M75. Reports: Upon request, the Service Provider must search and generate reports based on user-defined criteria and/or key words including wild card searches. In addition, the Service Provider must retain a permanent record of all reports.


APPLICABILITY OF THETRADE AGREEMENT(S) TO THE PROCUREMENT
• Agreement on Internal Trade (AIT)
• World Trade Organization - Agreement on Government Procurement (WTO-AGP)
• 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 crisissituations and incidents. ERMS Advantage supports Natural Resource Canada’s emergency notification requirements without any additional configuration to our IT infrastructure.

ERMS Advantage will allow NRCan 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 AAFC’s requirements for a Bilingual (English/French) Emergency Mass Notification System as per the criteria identified.

ERMS Advantage fully satisfies AAFC’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 supplier and 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 particularsupplier and no reasonable alternative or substitute exists.

Article XV(b) of the WTO-AGP is applicable on the basis of limited tendering due to reasons when, for works of art or for reasons connected with protection of exclusive rights, such as patents or copyrights, or in the absence of competition for technical reasons, the products 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 years that includes 9 additional 1-year options. All delivery mentioned in the requirement shall be delivered within 10 days of Contract award.


NAME AND ADDRESS OF THE PRE-IDENTIFIED SUPPLIER:

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 contactperson 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

Inquiries and statements of capabilities are to be directed to:

Brock Flemming
Procurement Officer
Public Works and Government Services Canada
Gatineau, Québec, Canada (K1A 0S5)
Brock.flemming@tpsgc-pwgsc.gc.ca
Telephone 873-469-4653
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.