Call for Consultancy-Supply & Implementation of a SaaS Enterprise (IT) Service Management (ITSM) Tool - Médecins Sans Frontières

TERMS OF REFERENCE

Supply & Implementation of a SaaS Enterprise (IT) Service Management (ITSM) Tool

  1. Background

Médecins Sans Frontières (MSF) is an international independent medical humanitarian action-driven organization, which offers assistance to populations in distress, to victims of natural or man-made disasters and to victims of armed conflict, without discrimination and irrespective of race, religion, creed or political affiliation. 26 associations, 23 sections, and 16 branch offices make-up the international movement and work in partnership around 6 operational entities.

MSF Eastern Africa came into being in 2021, growing out of the Nairobi Branch Office (MSF Spain). The section is the regional institutional office for MSF in Eastern Africa and focuses on representation and networking, including with humanitarian organizations and authorities, recruiting and supporting staff from the region, communications and fundraising, as well as on other dossiers of importance to MSF such as Diversity, Equality and Inclusion (DEI), mutualization, trainings, medical operational support and environmental health. MSF EA has identified key transversal areas of focus in its two-year strategic plan 2022-2023. This will enable the Section to grow and provide strategic support to the operations while building its capacity for future operational ambitions. You can learn more about MSF on our website or via our digital channels – Facebook, Instagram, Twitter and LinkedIn.

  1. Project Overview

MSF EA’s current service management approach is siloed with each department/business function literally ‘figuring it out themselves’. Whereas IT and Facilities tried an automation that resulted in partial automation of their service desk, other departments’ services remained manual. The result is that Quality and speed of these services is not guaranteed, thereby affecting employee productivity.

On the other hand, our IT Assets are managed and allocated manually. IT issues them without proof of user acknowledgement. Most are not tagged, while the few that are tagged, their tag information/number has faded. Monitoring compliance with cyber security and other best practices is an uphill task. We can’t imagine the size of this problem when the number of assets doubles within the 12 months according to our projections.

Therefore, MSF EA is accepting proposals to adopt a SaaS Enterprise Service Management (ESM) or IT Service Management (ITSM) that meets our requirements.

  1. Sourcing Approach

MSF EA generally prefers a “cloud first” deployment approach where the convenience and cost containment aspects of adopting a SaaS solution for ESM are very clear to MSF EA.

Therefore, MSF EA will involve the market leader vendors (as per major market analysts’ publications) operating in the market segments of SaaS ESM and ITSM platforms.

The bidders are encouraged to submit financials for a SaaS deployment.

The shortlist of Bidders will be defined by MSF EA, at its sole and absolute discretion.

  1. Project Objectives

The strategic objective is to potentially extend the service management and tools discipline to non-IT services, in order to establish a Single Stop Shop for business support and a better and more integrated experience for both internal and external customers.

The specific objectives are to:

  1. Reach higher levels for the quality of the services offered and set the basis for a continuous improvement philosophy.
  2. Increase the level of automation and self-service provisioning in the organization, in order to minimize execution times and improve customer satisfaction.
  3. Set the foundation for a more robust and better-established service-oriented culture across the enterprise.
  4. Improve visibility and control over IT and other assets, leading to better decision-making regarding asset utilization, replacement, and retirement.
  5. Reduce manual effort and errors in asset tracking, reporting, and budgeting, leading to cost savings and increased efficiency.

We are committed to achieving these objectives and look forward to working with a qualified vendor to achieve our goals.

  1. Scope of Work

The scope of the project includes the implementation of an ITSM tool that will cover the following functions and processes:

  1. Asset Management
    1. Enterprise Asset Management
    2. Hardware Asset Management
    3. Software Assets Management
    4. Cloud Infrastructure
    5. IT Asset Offboarding
    6. SaaS License Management
    7. Asset Discovery
    8. Configuration Management Database (CMDB)
    9. Mobile App with asset tag scanning capability
    10. Vendor/Contract Management
  2. Incident Management with chat capability
  3. Change Management
  4. Problem Management
  5. Request Fulfillment
  6. Service Catalog Management
  7. Service Level Management
  8. Knowledge Management
  9. Service Portal with unlimited user access
  10. Agent Mobile App.
  11. Integration capability (with other systems e.g Azure AD (this is a MUST), Dynamics 365, SharePoint and Office 365)
  12. Reporting and Analytics
  13. Inter-departmental Workflows e.g Employee onboarding/deboarding, travel requests, etc.
  14. DevOps

The second part of the scope of this project is the services. We will need some implementation and training support from the vendor. The implementation will involve:

  • Configuration of the system and workflows for various departments.
  • Configuration of the dashboards and reports for various personas.
  • Training of the technical team

Third part of the scope is support. We need guarantee for 24hour support from the OEM. We will monitor the response and resolution timelines to ensure that we are receiving quality support.

We plan to tag all our assets using aluminium tags with bar codes. The system should support scanning of the bar codes by the mobile app.

Since all digital services are internally developed, MSF EA seeks to enhance its development processes using the latest software methodologies, such as SCRUM. We hope that this tool will provide a platform for receiving automation needs/pain points from users across the organization and enable the IT team to prioritize development/implementation of solutions while keeping users in the loop.

Since 2021, MSF EA has made an even more extensive use of cloud services, using for that matter cloud providers such as Microsoft; MSF EA believes it achieves better business resilience against disaster, and a lower TCO (Total Cost of Ownership), by using cloud services for most of the supporting services.

Security is an ongoing concern and MSF EA makes continuous reviews to its information assets platforms and to their security, designed to maintain the integrity of the assets and to ensure an environment that is free from external contamination.

Business continuity is another concern. Therefore, the ideal ITSM tool should be able to allow backup of the database to another cloud platform in an automated way.

  1. Timeline
  • Implementation plan: 2nd May 2023
  • Software and license procurement: May 4, 2023
  • Asset Inventory: 24th April – 23rd May 2023
  • Tool configuration for Assets: 2nd May – 4th May 2023
  • Asset Management training for IT & Facilities: 4th May 2023
  • Development of Service Catalog and Requirements gathering for service workflows: 5th June – 10th June 2023
  • Tool configuration and customization for other services: 5th June – 20th June 2023
  • Agent training on service and catalog management: 20th June 2023
  • Technical training on other system features: 27th June 2023
  1. Key Deliverables

The following deliverables will be provided to MSF EA as part of this project:

  1. ITSM tool software and licenses
  2. Implementation plan
  3. Configuration and customization documentation
  4. User manuals and training materials
  5. Service level agreements and performance metrics
  6. Reports and analytics
  7. Technical documentation

All deliverables will be provided to MSF EA in digital format (PDF). All reports will be delivered to MSF EA within the timeline outlined in the project plan.

The vendor will work closely with MSF EA throughout the project to ensure that all deliverables meet the requirements and expectations of MSF EA.

  1. Evaluation of Proposal and Evaluation Criteria
  2. Overview and Timing

The evaluation process will be articulated in the following main steps:

  1. RFP issuing and evaluation: Bidders will respond to the present RFP in the time and manner specified herein.
  2. Proof of Concept (PoC): after carefully evaluating all the Bidders responses, MSF EA will invite a subset of Bidders to perform a “hands on” PoC session, based on provided Use Cases. The PoC will entail majorly: customization of workflows, Asset Discovery, asset movement, handling Windows patches/updates, incident management and reports. This will be done for a maximum of 2 hours for each invited bidder. It will be the Bidder’s responsibility to make the necessary provisions in order to allow MSF EA designated personnel to experience the functionalities included in the Use Cases.
  3. Best and Final Offer (BAFO) presentation: after evaluating the PoC, MSF EA will further down-select the number of Bidders and invite the remaining to review and improve their proposals and perform an onsite BAFO presentation. The final decision and contract awarding will follow the evaluation of all the BAFO presentations.

The proposed timing for the entire evaluation process is presented here below:

Step

Start

End

RFP Issuance

17th April 2023

N/A

Submission Deadline

N/A

24th April 2023

Initial Evaluation

25th April 2023

27th April 2023

PoC

28th April 2023

28th April 2023

BAFO Meetings

2nd May 2023

2nd May 2023

  1. Instructions to Service Providers
  2. Communications

All communication with MSF EA must be directed to the Single Point of Contact (SPOC) for this project, as follows:

Nehemiah Abere

Coordinator, IT & Facilities Unit.

Email: Nehemiah.abere@nairobi.msf.org

Normal working hours are from 8:00 AM until 5:00 PM EAT, Monday to Friday.

Until the RFP process is complete, and the Bidders have been notified, unless explicitly authorized, all contacts regarding this RFP with the MSF EA personnel other than the SPOC are prohibited.

Violation of any of these conditions may be considered sufficient cause to reject a Bidder's response and/or selection, irrespective of any other consideration.

  1. Acknowledgement

All the invited Bidders must acknowledge the receipt of the RFP documents and their intention to submit a response; the acknowledgment will only be accepted in written form and via an email sent to the SPOC copying procurement@nairobi.msf.org

The acknowledgement must be received on or before 18th April 2023.

  1. Questions/Clarifications

Questions regarding the RFP document or process should be documented and sent to the SPOC via e-mail on or before 20th April 2023. The SPOC shall respond to the questions within 24 hours.

  1. Proposal Submission

All proposals should be submitted to procurement@nairobi.msf.org and cc Nehemiah.abere@nairobi.msf.org on or before 24th April 2023 at 1700hrs (East African Time) and marked as follows on the subject line:

ITSM PROPOSAL

  1. Responding to the RFP

The vendor should submit a proposal with separate annexures. The proposal should have a maximum of 5 pages/slides with the following:

  1. Cover Letter - The Bidder’s Proposal shall include a maximum 1 page long Cover Letter signed by the authorized representative(s) of the company giving a Binding Proposal based on the RFP. It should acknowledge the requirements of this ToR and the commitment to meet all that is in the scope of work.

  2. Commercials

    1. SaaS software License cost. We have about 200 laptops, 200 mobile phones, 50 network devices and 500 other assets. Up to 10 agents. However, you are required to indicate the NGO discounted cost for each agent and asset (if applicable).
    2. NGO discounted Rate card (per hour) for configuration/implementation/training. Approximately 20-30 hours.
    3. Annual support fee if applicable.
  3. Annexures

    1. Company profile
    2. Complete Solution Data Sheet
    3. Client References where the tool is used by over 1,000 end users and over 5,000 assets.
    4. Sample contract for the Product Licensing (SaaS)
    5. Proof of product Accreditations and compliance with data protection regulations.
    6. SLA commitment.
  4. Evaluation Framework

The competency, experience and background of the Bidder will be considered in making the contract award. A proposal other than the lowest priced may be selected if MSF EA determines that, at its sole and absolute discretion, its interests would be best served by doing so.

MSF EA reserves the right to withhold all information used in conducting the evaluation.

Proposals will be evaluated based on criteria including, but not limited to, the criteria listed below (note: order does not indicate importance).

In addition, and at its sole discretion, MSF EA may determine and use any other relevant criteria.

Prior to making its decision, MSF EA will conduct a thorough review of all qualified proposals. MSF EA may, at its sole discretion, seek clarification regarding any proposal information and may do so without notification to any other Bidders.

Criteria will include but not limited to:

  1. Ability to deliver Products, Solutions, Services
  2. Content and quality of the proposal
  3. Flexibility offered by the bidder
  4. Total cost of ownership
  5. Terms and Conditions

This document contains proprietary and confidential information. Recipients may use or reproduce the information detailed within this document and any other supporting information only to provide a response to this RFP. No commitment will be made to any agency/vendor unless a contract has been awarded and signed by both parties. We reserve the right to cease this exercise at any time. During the period of this activity, no contact should occur between any members of the supplier's staff and organizational staff in relation to this exercise other than through the designated contact points as detailed within this RFP

  1. Non-Disclosure and Confidentiality

The information contained within this document or subsequently made available to the vendor is deemed confidential and must not be disclosed without the prior written consent unless required by law.

  1. Independent Proposal

By submitting a proposal, the vendor warrants that the prices in the proposal have been arrived at independently, without consultation, communication, agreement or understanding for the purpose of restricting competition, as to any matter relating to such prices, with any other potential vendor or with any competitor

  1. Annexures

This is additional information that will be used in the evaluation process.

  1. RFP Data Collection Tool

To be provided as a separate excel attachment.

  1. Use Cases for PoC
  2. IT Service Management

Use Case

Checklist creation and assignment

Initial State

The user gets access to a task creation interface where it is possible to create tasks, associate them to assets, organize them into checklists and schedule the periodic execution of the checklist.

Involved data

  • IT Assets (e.g. Applications, Databases, Servers, etc.)
  • IT Operations Team
  • IT Operations Team members

Functional Requirements

  • 2.1 IT asset lifecycle management (2.1.1, 2.1.4, 2.1.8)
  • 3.1 CMDB and CI lifecycle management (3.1.2, 3.1.7)

Script

Step

Description

1

The admin creates a number of tasks related to one particular application listed in the IT assets inventory. Then organizes them into a checklist.

2

The admin assigns a periodicity to the checklist that must be performed on a daily basis between 8am and 10am.

The user sets up a notification if the checklist is not executed within this timeframe.

3

The admin gets access to the IT Ops team calendar for the next 3 months and assigns the checklist to 5 team members with a daily “round robin” policy (i.e. rotates the execution of the checklist among the team members on a daily basis).

4

The admin logs off and logs on as a one of the team members and verifies that the checklist is prompted on his task list (or equivalently, that he has received a message/email with the task assignment).

5

The admin logs back on and creates a new assignment policy, a “weekly round robin”, that will rotate a task among a list of team members on a weekly basis.

6

The admin assigns the policy to the checklist and verifies that the team members schedule has changed.

7

The admin logs off and logs on as a one of the team members and verifies that his task list has changed accordingly (or equivalently, that he has received a message/email with the modified task assignment). Then executes the checklist until the end and adds notes to it.

8

The admin logs back on and verifies that the execution of the checklist has been tracked.

Use Case

Workflow creation

Initial State

The admin gets access to a workflow design interface in order to create a new process automation instance. The initial requirement is to automate the creation of an account on a given system, triggered by a self-service request form submission and subject to the requestor’s manager approval.

Involved data

  • IT Assets (e.g. Applications, Databases, Servers, etc.)
  • IT Operations Team
  • Users (internal and external customers)

Functional Requirements

  • 1.1 Incidents lifecycle tracking and management (1.1.1, 1.5.1)
  • 2.1 IT asset lifecycle management (2.1.1, 2.1.4)
  • 4.2 Service Request Lifecycle Management (4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5)
  • 4.3 Asset provisioning/procurement (4.3.3, 4.3.4)
  • 6.3 Metrics Lifecycle Management (6.3.1, 6.3.2, 6.3.5)
  • 7.1 Process Lifecycle Management (7.1.1, 7.1.2, 7.1.3, 7.1.4)
  • 7.2 Integration with External Systems (7.2.1)

Script

Step

Description

1

The admin creates a new instance of workflow (WF) for creating a new user account on a given system (e.g. creates a record in a table on a database).

The user adds the following steps:

  1. User submits a form with his/her name, surname, email and employee ID
  2. Input is checked and, if errors are found, returns an error message to the user and ends.
  3. If all the input is fine, the WF retrieves the record of the manager of the requestor.
  4. If this cannot be retrieved, the approval is sent to an IT ops member for investigation/approval and ends.
  5. If the retrieval is successful, the WF sends an email to the manager for approval; the approval can be made either through a specific interface or by interpreting the reply email (words “OK”, “YES”, “SIM” to approve, “KO”, “NO”, “Não” to reject).
  6. Upon rejection, the system sends a message to the user and ends.
  7. Upon approval, the system attempts to creates the record on the database
  8. If the creation encounters errors, the WF opens a ticket for support and ends.
  9. If the creation is successful, the WF send a confirmation email to the user with the new credentials and ends.

2

The admin user adds metrics to the process, in order to collect information about how many times the WF ends in each of the possible states.

3

The admin performs a dry run of the workflow and checks the metrics are functioning well, then resets the counters supporting the metrics.

4

The admin user creates then a copy of the WF and changes the necessary parameters to create an identical process for a different application/system.

  1. Knowledge Base

Use Case

Modification and creation of a wiki article

Initial State

A knowledge base instance is in place, organized like a Wiki and with some articles already published in it. Articles have a reviewer assigned; this can be the same for all the articles within a specific topic area (e.g. IT help desk, back office, marketing, etc.).

Involved data

  • Users (internal and external customers)

Functional Requirements

  • 5.1 Knowledge Base & Document management (5.1.1, 5.1.2, 5.1.3, 5.1.4)
  • 5.3 Multimedia support
  • 7.1 Process Lifecycle Management (7.1.1)

Script

Step

Description

1

The user logs in and starts browsing the articles. Through specific buttons/links, s/he starts a process to modify an existing article.

2

The user submits the following alterations to the article:

  • Modifies existing text of a paragraph
  • Adds an entire new paragraph
  • Adds a hyperlink to another article within the wiki
  • Adds a video from an external source
  • Uploads a document and a picture

3

The approver of the content changes receives a request to approve the changes. All the changes are accepted except for the external video.

4

The user receives a notification about the approval/rejection and refreshes the article to acknowledge that the changes have taken place.

5

Then the user starts to create a new article and submits the new item for approval.

  1. Self Service Provisioning

Use Case

Modify self-service portal

Initial State

The system offers a simple self-service portal with few links leading forms to submit request or incidents. The system already has a populated IT asset inventory.

Involved data

  • IT Assets (e.g. Applications, Databases, Servers, etc.)
  • Users (internal and external customers)

Functional Requirements

  • 4.1 Service Catalogue Management (4.1.1, 4.1.3, 4.1.4)
  • 4.2 Service Request Lifecycle Management (4.2.1, 4.2.4, 4.2.6)
  • 4.3 Asset provisioning/procurement (4.3.3)
  • 4.4 Self-service provisioning (4.4.3, 4.4.4)
  • 6.1 Embedded Business Intelligence (6.1.1, 6.1.2)
  • 6.2 Report generation and distribution (6.2.1)
  • 6.3 Metrics Lifecycle Management (6.3.1, 6.3.2, 6.3.5)

Script

Step

Description

1

The admin gains access to the self-service portal landing page in editable mode and adds a new area for requesting access to a specific application.

2

The admin associates the area/link/button to the form that initiates the workflow (see use case “Workflow creation”).

3

The admin configures the form so that the basic details of the user (e.g. name, surname, employee ID) are pre-populated and cannot be edited.

4

The admin associates metrics to the functionalities picking from a pre-built list of metrics and creates a report specific to the new request form.

5

The admin then configures a pop-up infographic (or a flashing banner or any other similar feature) in order to inform the users about the new functionality, then configures the object in such a way that it will only be visible once per each user (or equivalently until the user ticks the “don’t show again” tick box).

6

The admin associates a flash survey to be shown upon request completion (e.g. 0 to 5 stars and comment) and makes sure that the average rating is shown in the report defined in the previous step.

7

The admin logs off and logs on as a regular user and completes a full testing cycle of the new service request just added.

How to apply

Proposal Submission

All proposals should be submitted to procurement@nairobi.msf.org and cc Nehemiah.abere@nairobi.msf.org on or before 24th April 2023 at 1700hrs (East African Time) and marked as follows on the subject line:

ITSM PROPOSAL