Service Level Agreement

Introduction

The Quipu software related operations are divided into following functional areas:

    • Development – focused on continuous improvement of the applications and systems, bringing new applications and functionalities that supports the Client’s business Goals.
    • Implementation – focused on deploying of applications, systems and services resulted from the Development area.
    • Support – focused on maintaining existing applications and systems after the implementation process has finished.

Classifications and Definitions

For the purpose of common understanding the main terms and concepts that are in use throughout the procedure have been classified and defined below.

Request

A request is a formal message posted on the Helpdesk requiring a certain action from Quipu, such as providing information, validating a local implementation or changing an application or a system .

The Requests Types have been classified as described by the diagram below:

SLA_image1-550x276

Figure 1 – Classification of Requests

Request for Information (RFI)

A RFI is a formal inquiry for getting information on an application or system or for getting informational support for an implementation that does not result in a change being performed by Quipu.

Request for Validation (RFV)

A RFV is a formal request to check and validate a change initiated by a Client at the local level such as interfacing with another system without the need for Quipu to develop an interface, changing a system stored procedure, validating some code or application, optimizing a system, and so on.

A RFV must be first submitted at the initiation moment, documenting in a ticket the intended changes. An initial validation of the concept takes place at this time from Quipu’s side. Before the actual implementation the changes must be again submitted in their final form for the technical validation to take place.

This two-step process aims to ensure that all changes are formalized, accounted and reviewed with the clear aim of maintaining the integrity of the data and the systems handling information.

Request for Assistance (RFA)

A RFA is a request for assisting the users of the applications in troubleshooting a malfunction that may be the result of data inconsistency, infrastructure and parameters misconfiguration or any other factor than a “bug” in the application.

Request for Change (RFC)

A RFC is a formal request for altering existing functionality of the data processing environment or one of its components (including but not limiting to process, algorithm, application, interface, system, and so on).

Within the scope of this procedure changes can be:

  • any request for fixing a bug or repairing existing functionalities (BFR)
  • any request for developing new functionalities and features or changing existing ones (RFD)
  • any request for removal of existing functionalities and features

Below you can find the definitions for the categories that fall within a typical Request for Change.

Bug Fix Request (BFR)

A “bug” is an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Therefore, a Bug Fix Request is a type of request through which the remediation of a “bug” is required.

To enable timely isolation and remediation of a “bug” a BFR must be accompanied by the detailed account of the circumstances in which it manifests itself.

Some of the “bugs” are dealt by in practice by the adoption of workarounds at the operational level. These workarounds may actually deliver the desired outcome of the process and allow the Client to live with the “bug” for extended periods of time. This sub-category of “bugs” for which known workarounds are available and for which the effort of fixing them within the application may outweigh any benefit will be listed on a “know bugs list” along with their operational workarounds.

Requests for Development (RFD)

A RFD is a request to bring new functionality or change the existing one which involves development effort from Quipu.

The Requests for Development have been further classified by the effort for delivering the functionality required Requests for Development have been classified into:

 

SLA_image2

Figure 2 – Classification of Development

Small Scale Development

The change within the software is not substantial and the delivery effort is estimated at below 20 Person-days.

Large Scale Development

The change within the software is substantial and the delivery effort is estimated above 20 Person-days.

All Requests for Development are always treated on a Time and Material base estimation whereby a project is open for the development and they are priced individually.

Maintenance Updates

A Maintenance Update is a software package that contains small incremental changes designed to optimize existing functionality, introduce small improvements, enable parameterization, activate modules, etc. Typically, the Maintenance Updates contain resolutions for BUG Fix Requests and Small Scale Requests for Development.

Major Upgrades

A Major Upgrade is a software package that contains major changes including new functionality, products, processes and changes in the database structure that have not been present before.

Request Management Process

The Request Management Process is a formal process used to manage each contact and interaction of the Clients as users of the applications and solutions with Quipu as the Service Provider. It is primarily focused on aligning IT Services provided by Quipu with the Business Services of the Client.

Request Management Process Flow and Activities

The following figure shows the request lifecycle from the moment it originates to its closure following the confirmation that the issue has been addressed.

 

SLA_image3-550x142

Figure 3 – Request lifecycle

Process Flow Summary

Request Management can be graphically presented in the form of a process flow which identifies the activities that need to take place in order to insure that a request is being addressed by the correct resources within the timescales agreed with the Client.

The following figure is a process flow for Request Management.

SLA_image4

 

Figure 4 – Request Management General Process Flow

Below there is a brief outline of the main activities within Request Management grouped into sub flows for easier understanding:

  • Initiating a Request
  • Recording and Classifying the Requests
  • Continuously Updating the Request Ticket
  • Handling and Escalation of Requests
  • Providing a Resolution
  • Closing Requests

Initiating a Request

Requests arise from various sources such as:

  • the need for an information (RFI)
  • a change initiated by a Client that needs to be checked and validated by Quipu before going into production to avoid situations where such changes may impact systems adversely (RFV)
  • a business need to alter the functionality of a system by either correcting a BUG or adding additional functionality (RFC)

During this phase the Client should make sure that the description of the request is clear, complete and accurate in order to make it understandable for all parties involved. The Minimum Requirements for Requests criteria should be fulfilled as described in Annex 1.

Recording and Classifying the Request

All requests need to be recorded so that they can be tracked to resolution in order to ensure that none is lost. Recording all requests will help to reduce specific types of request or identify certain common problems or trends. It will provide the information needed to initiate changes that could be solved at the level of the development of the system.

Before starting to record a ticket on the HelpDesk the Requester should make sure that all information needed to process the ticket is available in a clear and accurate manner. Tickets that are incomplete or unclear may cause delays in the resolution or create situations when the resolution does not match the request and even operational problems upon implementation.

Proper classification of the Request is extremely important to ensure that the issue is allocated to the correct resource for resolution. The priority for the ticket and deadline for resolution are mainly determined by two fields that are filled during recording of the request: Category and Priority as outlined in the Service Agreement section

The outcome of the Recording and Classification will be a ticket posted on the HelpDesk platform.

Requests may be recorded directly by the Requesters or by the any Quipu employee upon identification of an issue that needs to be addressed. In both scenarios proper attention should be allocated to correctly identify the Owner of the Request and to describe accurately and clearly the details.

Continuously Updating the Request Ticket

Continuous Update of the Request Ticket is a parallel process that runs throughout the entire lifecycle of the Request. The goal of this sub-process is to ensure that information on the progress is clearly and transparently kept up-to-date by any of the parties involved in bringing the ticket to a closure.

The HelpDesk will always reflect transparently the person currently assigned to the ticket. The responsibility of next action lies with that particular person.

If an additional clarification, confirmation or action from the Requester’s side is needed the ticket will be put On Hold until the Requester answers the query of the Resolver. While the ticket is On Hold the responsibility of the next action lies with the Requester. The HelpDesk will reflect transparently the reason for why a ticket is On Hold as recorded by the Resolver.

Anyone interacting with the ticket and participating in the process of bringing it to a resolution must ensure that the information is accurately and transparently reflecting the current status as well as what is expected in terms of next actions.

Handling, Assignment and Escalation of the Request

The goal of this sub-process is to ensure that after the request has passed the initial Opening, Recording and Classifying stages it gets routed to the appropriate person or group that is both able and authorized to handle it and provide a resolution.

Depending on the type of request there will be different methods for handling it. Also different response times and resolution times should be expected as described in the Service Agreement section of this document. Although a request may sometimes appear to be simple and straightforward to the Requester, it may have implications which are outside the initial area of comprehension and may trigger connected changes that at the end may even surpass the initial request in scope or in development effort. All these details should be clarified during the Initial Analysis stage of Handling a Request. Should any of them change the ticket must be updated to reflect the new implications.

Full commitment on all parties involved is necessary during the handling of a request in order to bring it to resolution. Identification of these persons takes place during the initial phase of Handling a Request and must be kept up-to-date whenever escalation occurs. Throughout the lifecycle of the request clear and transparent information must be ensured by all parties in the form of answers to the questions: “Who does what and when?”

Throughout their lifecycle, requests may get assigned or escalated to other people or groups of people to ensure that they are addressed at the proper competence level. There are three assignation processes prescribed by this procedure. Two of them are functionally driven respectively directional assignment and functional escalation and one is hierarchical escalation.

Directional Assignment and Functional Escalation

Requests vary largely in complexity and teams are specialized in functional areas such as the development of an application. Due to these aspects some requests can be fully serviced by the initial point of contact while others need to be sent for resolution to other, more specialized team members, to the Development Teams or another specialized group such as Database Administrators, System Administrators, etc.

Hierarchical Escalation

Throughout the lifecycle of the request the Hierarchical Escalation is available for breaches of Service Level Agreements. In short, whenever all due-diligence and all communication channels have been exhausted Hierarchical Escalation is possible by passing the ticket to the next higher level of authority.

Hierarchical Escalation is an extraordinary measure ensuring that the process cannot get stuck or its functionality be severely affected. It refers to the functioning of the process in itself and not to the content of the request.

Providing a Resolution

The goal of this sub-process is to ensure that a proper resolution is provided for each request ticket. Once the Request has been handled and a Solution identified the Resolution should serve for documenting it.

After identifying the solution for a request and before sending it to the Client for final usage the Resolution will be provided describing:

  • A summary of the causes of the issue – for BUG Fix requests
  • A summary of the analysis performed on the request
  • A detailed account of the solution in the form of Release Notes
  • Quality assurance Reports with tested items and indications for further testing
  • Recommendations and steps for implementation within the production environment

For requests that end up being rejected details about the rejection reasons should be provided as well as indications for further escalation mechanisms if available.

After the resolution was updated the request ticket must be marked as Resolved. At this moment the responsibility for further actions is shifted towards the Requester. The Requester now has the possibility to accept the resolution and close the ticket or to challenge it by posting on the ticket the appropriate comments.

Closing a Request

The goal of this sub-process is to ensure transparent and efficient closing of a request ticket. The formal confirmation of the resolution from the Requester’s side is needed in order to close the ticket.

Once it has been marked as Resolved the ticket will be waiting for either an input from the Requester confirming the resolution or challenging it.

For operational efficiency purpose and to avoid dormant tickets if there is no input for 30 days the resolution will be considered implicitly accepted by the Requester and the ticket automatically closed.

Reopening a closed Request

All requests have a unique scope. Closed requests cannot be reopened under any circumstances.

In case that the resolution provided is deemed not to be satisfactory, the solution was addressing the issue requested only partially or at a quality level below the one expected the hierarchical escalation process should be used.

If the scope of the original ticket needs to be developed further it must be treated on separate tickets (even if it’s connected to the area of the original ticket).

Service Agreement

The following Services are covered by this Agreement:

Request based support via the HelpDesk platform

Monitored HelpDesk 9:00 A.M. to 6:00 P.M. Monday – Friday[1] – Requests received outside of office hours will be collected, however no action can be guaranteed until the next working day. The platform available to all our customers and the access to it is granted to a limited number of counterparts agreed between the Customer and Quipu.

The parameters for all requests submitted to Quipu via the HelpDesk system are as follows:

  • Automatic confirmation upon registering a ticket outlining the details posted (generated by the helpdesk platform)
  • Automatic notification in case of change of assigned person or escalation as well as for any change in the status of the ticket (generated by the system)
  • First response and assignation of a person responsible for the initial analysis of the Request based on the severity of the request
    • Trivial Severity                – 5 Business Days
    • Minor Severity                – 2 Business Days
    • Major Severity                 – 1 Business Day
    • Critical  Severity              – 2 Hours during normal business hours

Severity Levels are defined as follows:

  • Critical severity: The defect affects critical functionality or critical data. It does not have a workaround. Example: Loan repayment cannot be done.
  • Major severity: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: Wrongly calculated penalties on loans. There are options which are allowing to add penalties manually calculated or adjust accrued account. But it is inconvenient
  • Minor severity: The defect affects minor functionality or non-critical data. It has an easy workaround. Example: Option for transfer within customer’s accounts is not functional. The same can be done in the option for transfers within bank
  • Trivial severity: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Translation of prompts on the screen is not correct.

Requests for Information

An unlimited number of Requests for Information will be serviced at no additional cost. The general priority of RFIs shall be Low and a best effort approach shall be used for resolution.

Request for Assistance

The Client shall bear all costs associated with Requests for Assistance. The prioritization of RFAs shall be done on a similar approach as Requests for Development. The Scope and Implications of the request will be analyzed and the financial implications shall be agreed between Quipu and the Client on a case by case basis.

Request for Validation

An unlimited number of Requests for Validation will be serviced at no additional cost. The prioritization of RFVs shall be done on a similar approach as Requests for Development.

Bug Fix Requests

The remediation of any Software Bug as defined in the Classification and Definitions section of this document falls exclusively under the responsibility of Quipu. The Client shall not bear any additional cost associated with this process.

Bugs shall be remedied based on the criticality that should be reflected in the priority of the ticket.

Requests for Development

The Quipu Software is provided as it is with an implicit guarantee of quality. Any request for additional functionality will be considered and evaluated by Quipu. The Client will be provided with an estimation of the effort and financial implications and the decision to go ahead with the development and implementation of additional functionality will be made based on the agreement between the two parties. For large complex requests an agreement may be made to perform an analysis of the request as a basis for further elaboration of the details.

Emergency telephone support and emergency remote assistance

Emergency telephone support and remote assistance guaranteed within 2 hours during the working hours 9:00 A.M. to 6:00 P.M. Monday – Friday[2]. For incidents received outside the normal working hours best efforts will be made to answer / action the call.

On-site assistance

Planned and emergency on-site assistance can only be delivered provided that the travelling formalities (invitations, visas, etc.) have been fulfilled.

The Client shall bear all costs associated with on-site assistance unless Quipu personnel travels for the purpose of remediating incidents caused by software Bugs.

Service Management

Effective support of in-scope services is a result of maintaining consistent service levels. The following sections provide relevant details on service availability, monitoring of in-scope services and related components.

________________________________________________________________________

[1] The Business hours refer to Regional Office Business hours EET/GMT+2 for Kiev and GMT for Accra.

[2] The Business hours refer to Regional Office Business hours EET/GMT+2 for Kiev and GMT for Accra.