System Maintenance Plan

Company Name: <CN>

Project Name:
Document No.
Date of Release:
Document status:

Abstract: This document describes the System Maintenance and Support processes, the
roles and responsibilities, and the main metrics to be used for the Service Level
Agreements.
Table of Contents

1.0 Introduction
1.1. Purpose
1.2 Document Organization
1.3 References
1.4 Document Amendment Procedure
1.5 Terminology
2.0 Executive Summary
3.0 System Maintenance
3.1 Preventative Maintenance (Hardware and Software)
3.2 Restorative Maintenance (Hardware and Software)
3.3 Hardware Maintenance
3.4 Hardware Maintenance Services
3.4.a General Support Services
Firmware Management
Computer Performance Evaluation
Capacity Management
Incident Management
Problem Management
Configuration Management
Availability Management
Services such as Help Desk
3.4.b Support and Maintenance Services
3.4.c On Call Cover/Remote Support
3.4.d Replacement Equipment
3.4.e Software Installation
3.4.f Spare Parts Holding
3.4.g Maintaining Information
3.4.h Data Security Measures
3.4.i Antivirus
3.4.j Record Keeping
3.4.k Preventive Maintenance (PM)
3.5 System Application Maintenance
3.4.1 Call Logging
3.4.2 Monitoring and Management
3.6 Proposed Maintenance Services
4.0 Maintenance
4.1 System Releases
4.1 Incidents, Problem, Changes
 4.2 Priority Driven Development
4.3 Tracking of Change Requests/Incidents/Problems(Bug Fixes)
4.4 Organizational Chart and Roles
4.5 Documentation
4.6 Meetings
4.7 Maintenance Schedule
4.8 Service Maintenance Reports
4.9 Disaster Recovery Plan
4.10 Key Performance Indicators (KPI)
5.0 User Support
5.1 Support Model
5.2 Escalation Process
5.3 Incident Resolution
5.4 Key Performance Indicators (KPI)
5.5 Reporting and Analysis
6. Conclusions
1.0 Introduction

1.1. Purpose
The purpose of this document is to present the fundamental principles that will guide the
System Maintenance and the User Support tasks within the project

1.2 Document Organization

Besides this Introduction, the Executive Summary and the final Conclusions, the document
includes two main sections.

Section 3, describes Preventative Maintenance, Restorative Maintenance and System

Application management.

Section 4, Maintenance, introduces the approach that the CN(Company Name) project
adopts for the maintenance of the system components that will be included in the CN
distribution, with a strong focus on the preservation of the stability of what is deployed in a
production environment. The different types of releases are described and the management of
Requests for Change is explained.

Section 5, User Support, introduces the approach that the CN project, in collaboration with
MNIG, adopts for the support of users of the system components that will be included.

For both Maintenance and User Support, relevant Key Performance Indicators (KPI) are
presented, together with operative hints on how the information needed to compute them
should be collected.

1.3 References

Reference # Description

R1 Information Technology Infrastructure Library (ITIL),

[Link]

R2

R3

1.4 Document Amendment Procedure

Process of document change.

1.5 Terminology
DoW Description of Work
SLA Service Level Agreement

ITIL IT Infrastructure Library

CCB Change Control Board

RfC Request for Change

2.0 Executive Summary
This document presents the fundamental principles that will guide the System Maintenance
and the User Support tasks within the project.

The System Maintenance task is responsible to coordinate the continuous maintenance of the
system components developed within the project. System maintenance is performed to
enhance the performance, maintainability or other attributes of system software and
hardware. Extend the application beyond its original functional and non-functional
requirements. Prevent aging, make more easily corrected adapted and enhanced. Maintenance
matrices are used, MTTR – Mean Time to Repair, Number of requests for corrective
maintenance – may be injecting more than removing, Complexity matrices.

Requests for Change will be managed to adopt a priority-driven approach so that the risk to
compromise the stability of the system deployed in a production environment is minimized.
Requests for Change will also be properly monitored across the different trackers adopted by
Project Teams.

The User Support task is responsible to coordinate the support, together with MNIG, to users
of the system components developed within the project. The User Support is organized in
three levels, of which only the third one is within the CN(CN: Company Name) project and
provides the most specialized knowledge needed to investigate a reported incident.

Both the System Maintenance and the User Support tasks are monitored through Key
Performance Indicators, that are presented at the end of the respective sections.
3.0 System Maintenance
The System Maintenance task is responsible to coordinate the continuous maintenance of the
ICT Solutions developed under this project and preserving at the same time their stability in
terms of interface and behavior so that higher-level frameworks and applications can rely on
them. The system consists of applications software and hardware, and to operate within a
systems environment.

The maintenance process contains the activities and tasks necessary to modify an existing
system while preserving its integrity. These activities and tasks are the responsibility of the
Maintenance Team. As already noted, many maintenance activities are similar to those of
software development. Maintainers perform analysis, design, coding, testing, and
documentation. They must track requirements in their activities—just as is done in
development—and update documentation as baselines change.

3.1 Preventative Maintenance (Hardware and Software)

Preventive maintenance (PM) is a regular and systematic inspection, cleaning, and
replacement of worn parts, materials, and systems. Preventive maintenance helps to prevent
failure of parts, materials, and systems by ensuring that they are in good working order.

Troubleshooting is a systematic approach to locating the cause of a fault in a computer

system. A good preventive maintenance program helps minimize failures. With fewer
failures, there is less troubleshooting to do, thus saving an organization time and money.
Preventive maintenance can also include upgrading certain hardware or software such as a
hard drive that is making noise, upgrading memory that is insufficient, or installing software
updates for security or reliability.

Benefits of Preventative Maintenance

Be proactive in computer equipment maintenance and data protection. By performing regular
maintenance routines, we can reduce potential hardware and software problems. Regular
maintenance routines reduce computer downtime and repair costs.

A preventive maintenance plan is developed based on the needs of the equipment. A

computer exposed to a dusty environment, such as a construction site, needs more attention
than equipment in an office environment. High-traffic networks, such as a client’s network,
might require additional scanning and removal of malicious software or unwanted files.
Document the routine maintenance tasks that must be performed on the computer equipment
and the frequency of each task. This list of tasks can then be used to create a maintenance
program. The following are the benefits of preventive maintenance:
● Save Time
● Helps in improvement of Performance
● Increases data protection
● Extends the life of the components
● Increases equipment stability
 ● Reduces repair costs
● Reduces the number of equipment failures

Purpose of Preventative Maintenance

Preventive maintenance reduces the probability of hardware or software problems by
systematically and periodically checking hardware and software to ensure proper operation.

Hardware: Check the condition of cables, components, and peripherals. Clean components
to reduce the likelihood of overheating. Repair or replace any components that show signs of
damage or excessive wear. We use the following tasks as a guide to create a hardware
maintenance program:
● Remove dust from fan intakes.
● Remove dust from the power supply.
● Remove dust from components inside the computer.
● Clean the mouse and keyboard.
● Check and secure loose cables.

Software: Verify that installed software is current. Follow the policies of the organization
when installing security updates, operating system updates, and program updates. Many
organizations do not allow updates until extensive testing has been completed. This testing is
done to confirm that the update will not cause problems with the operating system and
software. The tasks listed to create a software maintenance schedule that fits the needs of
your computer equipment:
● Review security updates.
● Review software updates.
● Review driver updates.
● Update virus definition files.
● Scan for viruses and spyware.
● Remove unwanted programs
● Scan hard drives for errors.
● Defragment hard drives.

Scope of Preventative Maintenance

1. Helpdesk Support Services: Helpdesk will be the center point of contact for all user
related issues. The maintenance company shall monitor complaints through their
incident portal or a suitable Software:
○ Call Receiving from Users by telephone, email or any convenient methods
including text messages. Logging and issue of complaint :
i. Per User, Per PC, Per office
○ Single point of contact for all concerns during the duration of Contact.: o
i. Call Escalation, Tracking and Closure
○ Following Reports shall be e-mailed to the organizations Co-coordinator as
per below frequency: ( based on SLA)
Daily Reports
 ● Call Pending Report with details of Complaint No., Location, Date & Time
Logged in, No. of Days Pending (from higher to lower), Reasons for delay in
resolving
● Calls Resolved on the previous day with details of Complaint No., Date &
Time Logged in / Resolved, Engineer Name.
● Items sent for Repair/Replacement with relevant details
● Items received for Repair/Replacement with relevant details
● No. of Calls received and No. of Calls resolved
Weekly Reports
● Pending Complaints beyond specified Time Limits
Monthly / Quarterly Reports
● Calls delayed by No. of days beyond specified time limit( Equipment Type
wise)
● Analysis of Type of Calls

2. Desktop Maintenance: Under Desktop Maintenance, the maintenance company is

required to provide services listed below:
● Maintenance support of the existing Desktops. Maintenance includes repair of
components and replacement of un-repairable components. In case of
replacement, new (branded & genuine) components shall be used.
● Checking status of desktop based on user complaints and taking remedial
action in case of problem
● Attending virus related complaints and taking necessary action to sort out the
issues. Guarding the systems against virus infections using the latest anti-virus
tools made available by the Organization Installation and Reload support on
Desktop for OS like MS Windows VISTA/Windows 7/ Windows 8/ Linux.
● Download updates/ patches by Microsoft and upgrade all computers on the
network.

3. Server Maintenance
○ Maintenance support of the existing Servers. Maintenance includes repair of
components and replacement of un-repairable components. In case of
replacement, the replaced component must be branded and genuine.
○ Installation and Re-load support for OS like MS Windows, Linux, etc

4. Scanner/Printer Maintenance
○ Maintenance Support of the existing Scanner/Printers. Maintenance includes
repair of components and replacement of un-repairable components. In case of
replacement, the replaced component must be branded and genuine.
○ Installation of drivers/ software for its operation

5. IT/Network Infrastructure Maintenance: To provide services and support to ensure

trouble free availability of network facilities to users:-
 ○ Managing all Patch Panels, switches, Firewall, routers, storage arrays, backup
robots & tapes, cables, etc. in the Network
○ Monitoring the network to determine capacity usage and escalating as required
○ Identifying LAN faults and getting them resolved
○ Installing necessary equipment to connect computers on to the Local Area
Network (LAN).
○ Repair / Replace faulty LAN cables.

6. Other Specialized Hardware

○ Maintenance Support of the existing Personalization equipment for Cards (ID,
Permanent Residence, Citizenship, work permit), Stickes (Residence Permits,
Visitor’s Permit), ePassport (Printing Lamination), Fingerprint Scanner,
Face/Portrait Capture Devices, Passport & card readers, handwritten signature
pad, Barcode reader, Mobile Biometric authentication/verification terminal.
Maintenance includes repair of components and replacement of un-repairable
components. In case of replacement, the replaced component must be branded
and genuine through respective third party vendors.
○ Installation of drivers/ software for its operation

Our support team will keep the computers and system in full working condition. All defects
related to viruses or operating systems or drivers are also included in the scope of work. The
preventive maintenance of each PC is to be carried out on a quarterly basis. Our Manager
gives the list of preventive maintenance schedules which it intends to do on the Server, Hard
disk, PCB boards, socket chips connector, contacts, floppy drive, printer heads and monitor
along with the periodicity, procedures etc. for approval.

Deliverables:
1. Regular and thorough cleaning of the system from inside i.e. PCBs etc. by computer
grade air and computer grade liquid cleaning solution to remove dirt and dust which
hinders the cooling of PCBs during operation. The solution should be free from
moisture. Caution should be exercised to prevent the damage due to static charge.
2. Cleaning and lubrication of all connectors and contacts.
3. Carrying out the head cleaning of CD-ROM / DVD Drive and floppy disc drive by
head cleaning disk and liquid cleaner.
4. Cleaning and lubricating the door mechanism of the FDD with lubricant (Silicon
based lubricant only) lubricating the grounding strap of the HDD and head slider rails
of the printer with the same lubricant.
5. Cleaning the exterior of PCs, keyboard, mouse, mouse pad, monitor, printer and all
other accessories. Good quality cleaning liquid is to be used for such purpose.
6. Updating Antivirus software as provided by the office and keeping PCs virus free.
( Every 15 days, and this is very critical)
7. Run Disk Cleanup, Defragment if necessary. Automatic Updates, Check Full Hard
Disk Volumes and other cleanup utilities to optimize system performance.
 8. System Restore Point created after all maintenance is performed. (Windows XP and
above).
9. Check Printers.
10. Perform Internal cleaning of computer components. CPU, Heatsinks, Fans, and Vents.
Ensure Proper Cooling inside the Case. Check Fans and vents.
11. Consult with CLIENT about upgrade possibilities, advancements in technology, and
upcoming events in the computer industry.

3.2 Restorative Maintenance (Hardware and Software)

Restorative Maintenance incorporates alterations and updates done to the right or fix issues,
which are either found by the client or finished up by unexpected events. Releases will be
defined as a result of enhancements and/or fixes prioritized through the change control
process.

In consultation with customers, the modification of components of the Hardware and/or parts
of the (System) Software in order to increase their reliability, to change functions or to add
new functions and/or to solve problems with the use of these.

Our Technical Support services are available to Customers when their voice, data or video
communication system fails to work properly. These services are defined as those supplied on
a reactive basis, and are remedial/restorative in nature.

3.3 Hardware Maintenance

We will provide the first level of support to the ministry for issues related to Server,
Peripheral, Computers, laptop, Specialized Hardware (like Scanner, Printers, Fingerprint
scanner, Passport scanner, etc.) or its software. If the issue is in complex nature, we shall
resolve it with the help of third party hardware vendors.

Corrective maintenance is the remedial action performed because of failure or deficiencies

found during preventive maintenance or otherwise, to repair an item to its operating state.
Normally, corrective maintenance is an unplanned maintenance action that requires urgent
attention that must be added, integrated with, or substituted for previously scheduled work.
Corrective maintenance or repair is an important element of overall maintenance activity.

TYPES OF CORRECTIVE MAINTENANCE

Corrective maintenance may be grouped under the following five categories :
● Fail repair: This is concerned with restoring the failed item or equipment toits
operational state.
● Overhaul: This is concerned with repairing or restoring an item or equipment to its
complete serviceable state meeting requirements outlined in maintenance service
ability standards, using the “inspect and repair only as appropriate”method.
● Salvage: This is concerned with the disposal of non repairable materials and
utilization of salvaged materials from items that cannot be repaired in the overhaul,
repair, or rebuild programs.
 ● Servicing: This type of corrective maintenance may be required because of a
corrective maintenance action; for example, engine repair can result in requirements
for crankcase refill, welding on, and so on.
● Rebuild: This is concerned with restoring an item or equipment to a standard as close
as possible to its original state with respect to appearance, performance, and life
expectancy. This is accomplished through actions such as complete disassembly,
examination of all parts, replacement or repair of unserviceable or worn components
according to original specifications and tolerances, and reassembly and testing to
original production requirements

Corrective Maintenance Downtime

Corrective maintenance downtime is made up of three major components as below

Active Repair Time

Administrative
Components Delay Time
and logistic time

Active repair time is made up of six subcomponents: checkout time, preparation time, fault
correction time, fault location time, adjustment and calibration time, and spare item
obtainment time

For Customers who are using our Application Software and/or Third Party Software and/or
Third Party Hardware and who have procured and entered into a valid Support and
Maintenance Contract, CN makes the following Support and Maintenance Service
commitments with respect to its Software and/or Hardware and/or System:
● Personalized service
● Prompt and reliable response to all requests for support
● Accurate and timely troubleshooting procedures
● Central, permanent repository of relevant customer-specific information
● Knowledge Base
● Service Level Targets (SLTs) applicable to the various predefined Support and
Maintenance packages
● ITIL® compliant Global IT Service Management framework
● A well-defined escalation process
● Access to Emergency Fixes, Patch Releases, Maintenance Releases and Major
Releases as applicable
● Third Party Hardware Vendor RMA procedure in place
● Allocating Questions and Enhancement Requests that fall outside of the scope of
Support and Maintenance Services to the Customer’s or Consulting Manager.
We will accept any Service Request placed by the Customer if the Customer has purchased
our Software and/or Third Party Software and/or Third Party Hardware from us and the
Customer has purchased Support and Maintenance Services through us.

Customers must have purchased a valid license to use Third Party Software and/or Third
Party Hardware from us. This is for any Third Party Software and/or Hardware that operates
independently of/or separately from the our Software and excludes any Third Party Software
embedded in the our Software which would be included as part of the our Software.

Unless expressly agreed upon otherwise in the Support and Maintenance Contract, the
Support and Maintenance Services shall commence after delivery of the Software and/or
Hardware but not later than expiry of the Warranty Period. In some cases, the Support and
Maintenance Services may commence immediately after purchasing Third Party Software
and Third Party Hardware (e.g. SAP Software, HP Software, Cisco Hardware) but in some
cases may commence after Provisional (PAC) or Final (FAC) Acceptance (e.g. OpenCloud
Software, ). Because Support and Maintenance Services commence date may be differ and
may be changed by Vendor without prior notice, therefore will be precisely defined in
Commercial Offer, Project Scope Agreement and/or Support Contract. The maintenance
Support includes all hardware to be used and or procured for project inclusive of all
Production, Backup, Test and Data recovery sites.

Hardware Maintenance includes activities for preventing outages or degradation of service

performance by detecting potential hardware failures by periodically audit HVAC (Heating,
Ventilation and Air Conditioning) conditions of deployed hardware, deliver of hardware
component firmware revision updates and upgrades, hardware health check etc. Proactive
hardware maintenance is not a part of standard maintenance service and must be purchased
separately.

Deliverables:
● Availability of Hardware Support experts 24/7
● Periodically audit of deployed hardware
● Detailed report of findings which could cause system outages, performance issues
● A final action plan for solving all issues
● Load/reload and configure operating systems and/or any other specific system
software
● Technical Assistance for hardware, operating system, server as per SLA
● Patch management includes patches/service pack upgrades , system diagnostic test,
remedial action
● Monthly Preventative Maintenance schedule for hardware and software
● Assistance in shifting and reinstallation of hardware and equipment
● Division handling the job must be ISO 9001 certified. --- Majoka you can delete it.
● Hardware/equipment fault repairs
● Data Recovery as per SLA
● Spare parts inventory and management

On-Site Troubleshooting Service and an equipment fault that cannot be effectively rectified
through remote technical support and if the problem cannot be resolved without replacing the
Hardware, We shall assign experienced technical support engineer to Customer site within
the time period defined in the SLA to analyze, develop a solution and rectify the fault on site.
The Customer and/or our engineer will replace the Hardware and rectify the fault to restore
the system. After replacing the hardware, our engineer will take the defective equipment and
send it back to Third Party Hardware Vendor.

3.4 Hardware Maintenance Services

Hardware Maintenance Services include processing of all corrective maintenance activities.
The scope of Hardware Maintenance Services will be defined in SLA and may consist of :

3.4.a General Support Services

Firmware Management
Firmware Management automates end-to-end firmware orchestration processes for ICT
Systems.
● Leverages automation to minimize manual, error-prone processes and accelerate
updates
● Pre-configured firmware management recipes can be modified to meet business
needs, or accelerate campaigns
● Flexible campaign scheduling, including targeting specific gateways and provisioning
clusters
● Microservices design supports horizontal scaling on-demand
● Tools - Incognito / Cisco UCS Manager

Computer Performance Evaluation

System Monitoring supports monitoring of the performance evaluation of systems( includes

Computer, server, Peripherals, software/application), and it provides features to view the
performance state and to monitor thresholds by periodically collecting performance data from
the system and accumulating that data. It can use the methods of collecting performance data
provided by a monitored machine's operating system or virtualized infrastructure from the
physical machine running on Windows or Linux, or from the virtual machine server or virtual
machine running on VMware, Hyper-V, Xenserver or KVM.
The System monitor process checks the performance and availability of system components
in your environment at regular intervals. If the monitor detects a problem, it issues an alert.
Our Maintenance Team regularly monitors the system and maintains an uptime of 99.9% for
the system (Servers, Peripherals, Application). Regular monitoring reports shared with the
ministry team. Below is the screenshot of System Information for monitoring the server.

Capacity Management
Capacity management is the practice of considering future capacity requirements for the
current and yet to be implemented IT services. The purpose of capacity management is to
ensure sufficient capacity exists to support new services and solutions considering the
advances in new technology. Employing a capacity management process helps to ensure
there is adequate funding so that new capacity can be implemented when needed.

Service capacity management monitors and controls the performance of the customer’s IT
services by examining relevant data. Resource capacity management monitors the
performance of components within the IT infrastructure. The activities of service capacity
management and resource capacity management are:
1. Demand management – Demand management is the practice of transferring and
transition demand in order to prevent an infrastructure component from becoming
 overloaded. Demand management reviews capacity requirements from both a long
term and short term perspective.
2. Monitoring - Monitoring the infrastructure components is a way to measure and
assure that the agreed-upon service levels can be achieved. Examples of resources that
should be monitored are central processing unit (CPU) utilization, disk utilization,
network utilization, and the number of concurrent licenses in use.
3. Analysis - Trend analysis is utilized as a measure to forecast future utilization needs.
An analysis of current systems and components may initiate efficiency improvements
or the acquisition of additional IT components.
4. Tuning - Tuning helps better utilize system resources or improve the performance of a
particular service by identifying steps to take which will optimize the system for the
current or anticipated workload.
5. Implementation - Implementation is the process of implementing the changed or new
capacity which was identified during the monitoring, analysis, and tuning activities.

Incident Management
ITIL, refers to Incident Management as a practice, describing the key activities, inputs,
outputs, and roles. Based on this guidance, organizations are advised to design a process for
managing Incidents in line with their specific requirements. The Incident Management
process can be triggered in various ways: A user, customer or supplier may report an issue,
technical staff may notice a (potential or actual) failure or an Incident may be raised
automatically by an event monitoring system.

All Incidents should be logged as Incident Records, where their status can be tracked, and a
complete historical record maintained. Initial categorization and prioritization of Incidents is
a critical step for determining how the Incident will be handled and how much time is
available for its resolution.
If possible, Incidents should be matched to other Incidents, Problems, and Known Errors. The
complete process described in Section 3.2 Incidents, Problems, Changes.

Organizations should use automated resolution tools and provide support portals with self-
help information so users can resolve simple Incidents themselves. For other Incidents, 1st
Level Support will try to diagnose and resolve the issue, typically using information from a
knowledge base or pre-defined Incident Models.
An Incident's priority is usually determined by assessing its impact and urgency: 'Urgency' is
a measure of how quickly a resolution of the Incident is required. 'Impact' is a measure of the
extent of the Incident and of the potential damage caused by the Incident before it can be
resolved.
To determine the Incident's urgency, choose the highest relevant category:

Category Description
High (H) ● The damage caused by the Incident increases rapidly.
● Work that cannot be completed by staff is highly time-
sensitive.
● A minor incident can be prevented from becoming a
major Incident by acting immediately.
Medium (M) ● The damage caused by the Incident increases
considerably over time.
● A single user with VIP status is affected.
Low (L) ● The damage caused by the Incident only marginally
increases over time.
● Work that cannot be completed by staff is not time-
sensitive.

Incident Impact (Categories of Impact)

To determine the Incident's impact, choose the highest relevant category:
Category Description
High (H) ● A large number of staff are affected and/or not able to
do their job.
● A large number of customers are affected and/or acutely
disadvantaged in some way.
● The damage to the reputation of the business is likely to
be high.
Medium (M) ● A moderate number of staff are affected and/or not able
to do their job properly.
● A moderate number of customers are affected and/or
inconvenienced in some way.
● The damage to the reputation of the business is likely to
be moderate.
Low (L) ● A minimal number of staff are affected and/or able to
deliver an acceptable service but this requires extra
effort.
● A minimal number of customers are affected and/or
inconvenienced but not in a significant way.
● The damage to the reputation of the business is likely to
be minimal

Problem Management
Problem management is the subsequent process for incidents that require further investigation
to find the root cause. You can generate problem records directly from the incident record,
which will copy over key data.

A problem describes an undesirable situation, indicating the unknown root cause of one or
more existing or potential incidents. A known error is a problem for which the root is known
and for which a temporary workaround has been identified. A Request for Change (RFC)
proposes a change to eliminate a known error and is addressed by the Change Management
process. The Problem Management process includes Problem Control, Error Control,
Proactive Problem Management and Providing Management Reporting.

Objective: The objective of Problem Management is to resolve the underlying root cause of
incidents and consequently prevent them from recurring. Reactive Problem Management
aims to identify the root cause of past incidents and presents proposals for improvement or
rectification. Proactive Problem Management aims to prevent incidents from recurring by
identifying weaknesses in the infrastructure and making proposals to eliminate them.

Scope: The scope of the Problem Management process includes a standard set of processes,
procedures, responsibilities and metrics that are utilized by our services, applications, systems
and network support teams.

Problem Management Process Map:

Problem Management Services Metrics: Problem management requires a separate priority
matrix to Incident management. This is because problem management can require a
significant commitment of time and resources, as opposed to incident management which
uses a matrix Based on rapid resolution and is essentially looking for the fastest way to get
the customer up and running. Problem management service metrics will be collected and
calculated for each support group, unit.

Description Measures Target

Number of Measures problem management Number open and Establish baseline of

Problem workload and effectiveness in resolve problems. problem management
resolving open problems volume. Monitor
trends over time.

Average Measures effectiveness of the Number of days from Establish problems

time to close problem management process in problem creation to close to the baseline.
a problem resolving problems. Reductions problem close for Monitor trends over
indicate better processes, tools problems closed in the time.
and training are being used. current period.
Increases indicate an ineffective
process or that problem
management may be under-
resourced.

Number of Indicator of the time and re- Number of incidents Establish incidents
incidents work eliminated by managing that are closed by with Known Errors
resolved by and resolving problems. An solutions registered in baseline and monitor
Known increase in the number of the Known Errors trends over time.
Errors resolved incidents should database.
improve service levels and
customer satisfaction
Configuration Management

The configuration management system underpins all incident management activities. It not
only hosts the incident and other service management records, it contains details of the
infrastructure vital to efficient call handling. The configuration management procedures
provide the verification, validation, and audit of each step required to identify, authorize,
implement, and release the software product.

It is not sufficient to simply track modification requests or problem reports. The software
product and any changes made to it must be controlled. This control is established by
implementing and enforcing an approved software configuration management (SCM)
process. The Software Configuration Management KA provides details of SCM and discusses
the process by which software change requests are submitted, evaluated, and approved. SCM
for software maintenance is different from SCM for software development in the number of
small changes that must be controlled on operational software. The SCM process is
implemented by developing and following a software configuration management plan and
operating procedures. Maintainers participate in Configuration Control Boards to determine
the content of the next release/version.
The Configuration Management process ensures that selected components of a complete IT
service, system, or product (the Configuration Item) are identified, baselined, and maintained
and that changes to them are controlled. It provides a Configuration model of the services,
assets, and infrastructure by recording the relationships between service assets and
Configuration Items. Configuration Management may cover non-IT assets, work products
used to develop the services, and Configuration Items required to support the services that are
not formally classified as assets. Any component that requires management to deliver an IT
Service is considered part of the scope of Configuration Management.
Following are the basic activities within the scope of Configuration Management :
1. Configuration Management Planning — It includes activities that enable to plan of the
function, scope, and objectives of the Service Manager for the organization.
2. Configuration Identification — It includes activities that enable to identify and label
all of the company’s existing IT components. The information tracked includes asset
identification, contact, asset network relationship, and model or version data.
3. Configuration Control — It includes activities that enable to ensure that all
information regarding the organization's IT components is kept up to date and
accurate. Components can be added, modified, or removed only through controlling
documentation, such as an approved Request for Change (RFC).

Availability Management
Availability Management aims to define, analyze, plan, measure and improve all aspects of
the availability of IT services. It is responsible for ensuring that all IT infrastructure,
processes, tools, roles, etc are appropriate for the agreed availability targets.

The main goal of Availability Management is to: Ensure the level of service availability
meets the agreed-upon needs of the customer. Ensure the IT organization will not have an
operational failure.
An Availability Plan will ensure that existing and future Availability Requirements for
Information Technology (IT) Services can be provided using effective cost measures. The
Availability Manager is responsible for defining, analyzing, planning, measuring and
improving all aspects of the availability of IT services. He is responsible for ensuring that all
IT infrastructure, processes, tools, roles, etc. are appropriate for the agreed service level
targets for availability.

Responsibility Matrix: Availability Management

ITIL Role | Sub- Availability Service Application Technical IT

Process Manager Owner Analyst Analyst Operator

Design Services
for Availability

Availability Testing

Availability Monitoring
and Reporting

Availability Measuring and Reporting shows how availability shall be measured and
reported to check Objective.

Objective Increase service availability by means of web access

Critical Success Factor (CSF) Increase service availability
Key Performance Indicator
(KPI) Increase 10% in service availability implementing service web access
Metrics Availability in the first month (before improvement implementation)
Availability in the last months (after improvement implementation)
Measurements Availability % = (AgreedServiceTime - Downtime) /
AgreedServiceTime x 100
Frequency: Weekly
Reports Availability Report
Frequency: Monthly

Services such as Help Desk

These services are described in Section 4.0 : Call Logging and Section: 5.1: Support model.

3.4.b Support and Maintenance Services

Depending on the nature of the solution deployed, typically Support and Maintenance
Services will/may comprise the following services:
Software Services-
● Emergency Service (Remote/Onsite Support)
● Problem Resolution / CSR Handling
 ● Technical Query
● Software Updates Delivery
Advanced Software Maintenance - Optional
● Proactive SW Maintenance
Software Change Management
● Software Update Installation
● SW Change Planning & Support
● Software Change Testing
Hardware Services
● Remote Troubleshooting
● HW Repair and Replacement
○ Return For Repair Service
○ Advance Hardware Replacement
○ On-Site Hardware Replacement*
● Spare Stock Handling Pro Proactive Hardware Maintenance
● Onsite Troubleshooting
● Equipment Health Check
*Third Party Hardware Vendor Support and Maintenance

Final scope of Support and Maintenance Service and SLT will be defined within support
contract according to Customer specific needs and demands.

The service desk is the heart of IT support. It performs a critical role in the business by
ensuring the productivity of personnel across the organization and communication between
IT and the business. To enable this, IT organizations need a service desk solution that
supports ITIL best practices for IT Service Management (ITSM), consolidating the service
desk function with the processes that underpin the efficient delivery and support of services.

Service Desk is intended to provide:

● Single point of contact for Customer support, 24 hours per day, 7 days a week, 365
days per year (24×7×365)
● Prompt and reliable responses to Customer Service requests
● Accurate, timely and consistent procedures including up-to-date contact matrices and
escalation procedures

Under support, customers will provide an authorized personnel list for which an account in
Service Desk will be open. Only authorized customer personnel can open a valid Service
Request. Service Desk provides a way to consult maintenance problems, solve fault, efficient
know-how and experience to customers via telephone, email and Web. Reported problems
will be addressed on a priority basis, and will be quickly and competently responded and
resolved within a defined Service Level Agreement. We will remain in contact with
Customer until the problem has been fully resolved. The Support and Services Maintenance
describe is Section 4.1: User Support.
Definition:
"Response Time" is the time it takes to acknowledge a customer's issue in a non-automated
way. It is measured from the time an Incident record is created by the customer or by the IT
Service Desk or other support group manually creating a record, until the time that the
customer is advised their problem has been received and is being addressed. The customer
would be contacted either by phone or email and the Incident marked "In Progress".
Specifically, Response Time is measured from the time from Incident creation until the "In
Progress" status update, measured during standard business hours.

"Resolution Time" is the time it takes to resolve a customer's issue or answer their question.
It is measured from the time an Incident record is created, either by the customer or by the IT
Service Desk or other support group manually creating a record, until the time that the
customer is advised their problem has been resolved. Specifically, Resolution Time is the
time from Incident creation until the "Resolved" status update, measured during standard
business hours.

The Service Metrics definitions are an interim guideline to assist with the implementation of
Incident Management. As per customer contract define, Service Level Agreements outlining
the appropriate Service Metrics will be developed for each specific line of service.

Description Measures Target

Response Time period in which our team An incident must be Service Level is met
Time after notification of problem or acknowledged and an 95% of the time
service request starts activities incident resolution plan
to fix problem (analysis) and communicated
notify user that the work has according SLA
started

Resolution Time period in which our team, Target remedy by 90% of all incidents
Time after notification of a problem, priority according to are resolved by the
fixes a problem in a way that SLA. target remedy time.
limits its impact. We will
provide a solution, a Extensions to expected
workaround or an action plan for remedy time must be
the issue within the specified agreed with the
time frame. It can cause service customer.
delivery restrictions to the
customer.

Service The time the service is available Time to service was Average availability
Availability according to the service hours down in minutes over the measurement
specified in the service level period according to
agreement. SLA.

MTTR (Mean Time to Repair) - This is the average elapsed time between detecting an
Incident and repairing the failed component; e.g., diagnosing and replacing a failed disk.
Upon the completion of this activity, there is a functioning disk, but data has not been
restored, and the users are still unable to access or use the service. Essentially this measures
the technical response to diagnose and repair the failed component.

MTRS (Mean Time to Restore Service) - This is the average elapsed time between detecting
an Incident and fully restoring the service to the user; e.g., restoring data to the disk,
recovering and restarting interfaces to other applications, informing the users that the service
is available, and initiating user access (you may not want all of your users to log in
simultaneously upon repair of the service!). This is a measure of the quality of operational
processes, as well as system design to facilitate recovery after failure.

MTBF (Mean Time between Failures) - This is the average elapsed time between restoration
of service following an Incident and detection of the next Incident.

MTBSI (Mean Time between System Incidents) - This is the average elapsed time between
Incidents, including downtime represented by the MTTR and MTRS measurements

Support/Maintenance Response Time

Level of Support Mode of Communication Hours of Support

Level 1 On-site (Phone/Email/In- Response Time: 15 Min to 1 hour

person meeting)
Target Resolution Time: 10 hours

Level 2 Off-site (Phone/Email) Response Time: 2 hour

Target Resolution Time: 30 hours

Level 3 Offsite (Phone/Email) Response Time: 1 hour

Target Resolution Time: 48 hours

3.4.c On Call Cover/Remote Support

There are two methods of Remote Troubleshooting, phone support and remote access. If the
fault or problem cannot be handled through phone support, with Customer permission, We
shall log into the faulty equipment through a remote terminal to collect data, investigate and
effectively rectify the problem.

In critical operating situations seriously affecting system or services availability, emergency

support is available to the Customer 24 hours a day, 7 days per week. Our specialists are
available 24 hours a day, 365 days a year and answer the Customer’s emergency call as soon
as possible within the defined time frame. The main objective of this service is to keep the
Customer’s systems running and to restore the system operation as soon as possible to
minimize revenue loss.

To initiate the emergency support during and outside of regular business hours, a project-
specific communication path (e.g. ServiceDesk, mobile or fixed phone) is allocated. It is
important that when an Emergency/ Critical Error in the Software or/and Hardware is brought
to our attention by sending an email or logged via Service Desk web site, the Customer
MUST ALSO contact our Support Center by telephone and advise them that the Service
Request is logged as Critical. Failure to do so will result in the SR being treated as a High
impact priority until the Customer contacts the Support Center by telephone to confirm the
impact designation of the SR is that of Critical.

Resolution of any problem during non-business hours may be dependent upon the nature of
the problem, the availability of staff resources or service and parts from third party vendors as
per SLA. ITS will assess a reported problem and determine a reasonable resolution plan
based upon the severity of the problem and resources required. ITS will work to resolve the
problem as quickly as possible. For a problem that requires more than four hours to resolve, a
status message will be forwarded to the community; the medium will depend on the nature
and type of system failure.

IT support for individual faculty or staff computers (related to hardware, operating system,
application software including e-mail, and remote network connectivity) or for computers in
meetings & conference rooms are only available during business hours. For the planned
shutdown of any network resource, a notification will be sent to all via e-mail at least 24
hours in advance whenever possible. IT staff may also provide support as needed at special
events during non-business on a pre-scheduled basis.
After Hours Support - Call List
Telephones
● computer down
● unable to receive or make external calls
● Multiple phones down (a complete building or more than 10)
● Voicemail offline
End-User Support
● Business systems offline
● Printers down Connectivity (all or more than 3)
● Server applications down
● Users file storage - unavailable for all or few staff.
● Multiple machines down (10 or more)
Server Support
● Email, Skype for Business, Office 365, SharePoint down
● Client System Server unavailable

The problem description provided will be analyzed, evaluated, if possible reproduced and
verified. We strongly recommend to the Customers to ensure a secure and controlled Remote
Access to the relevant system for the our Support team. A remote access for the system
experts is recommended to guarantee quicker service restoration.

After the service restoration the Customer has to acknowledge that the system operation is
restored. The Emergency ticket has to be closed and the root cause analysis of the problem
shall be investigated as a Priority 2. Upon successful completion of the Emergency service
the respective fault report will be generated automatically by the Support team with a Priority
1 error message to determine the cause of the occurred incident and to ensure recovery it in
the future. After normal system operation is restored, our specialists have to send a detailed
written notification (via mail) report describing the history of the escalation, the procedure
how the system operation was restored, describe preventive measures (if necessary), state the
root cause of the incident.

We have the obligation to inform the Customer in case of independent incident detection.
Deliverables:
● Availability of our Emergency Support experts 24/7
● Provision of an Initial Response within the defined Response Time
● Provision of service restoration
● All Customer personnel and management involved are kept informed and updated
regularly until the Emergency is resolved
● A final Emergency report will be provided by our Support Team
● If local expert support is required to solve the problem, We sends the required expert
to the corresponding location.
● After restoration the Emergency Ticket has to be closed, and Problem ticket opened as
a Priority 2 (if needed)
● Submission of Software defects to the fault management process
Mean time to repair the equipment onsite and that is taken-off: Our support team will
provide onsite level one support for repairing equipment onsite and that is taken-off as per
SLA. In case of any complex problem of third party software, our support team will repair the
equipment as per our SLA.
Hardware Return for Repair Service is a service where the repaired or replacement parts will
be shipped to Customer usually within 30 days after the Third Party Hardware vendor
receives the defective parts at the designated Third Party Hardware vendor site.

The HW received from the Third Party Hardware Vendor has to be with an equal or a newer
revision than the one delivered to us, if not specifically agreed otherwise.

Three types of repairs are defined according to level of significance:

Level 1 – important system parts
Level 2 – less important system parts
Level 3 – phased-out system parts The units damaged due to improper handling by Customer
will be replaced with new units and all costs beared by the Customer

Proposed Procedure for dealing with prolonged downtime: System Downtime can be
planned or unplanned but both types require policies and procedures that address the same
considerations: how the downtime and alternate processes are communicated; how charges
are captured; how systems are brought back up; and how downtime documentation is
transferred to the client once systems are live again. As we use the Preventive/Restorative
Maintenance to reduce the Prolonged downtime of systems. Our support team scheduled the
regular maintenance of systems.

Planned Downtime
There will be times when hardware/software systems will have a planned downtime. In the
event that the system is going to be down and your staff has advanced notice, there are
several steps that can be observed before the system goes down and again once the system
becomes available for use.
● Notification of scheduled downtimes will be communicated from the IT department
or vendor via e-mail or direct phone calls if email is not available. Be sure to read
your email.
● The IT department or vendor will notify the practice via email or phone call when the
situation has been addressed and the system is back online.
● Upon notification, the scheduling department should print out schedules for those
hours (or days) that the system will be down.
● Complete other business applications that do not require the system to be up and
running.
.
Unplanned Downtime
In the event of an unplanned, unscheduled downtime, staff will need to be prepared to handle
working without computerized technology and be able to transition to a paper process until
the system is online.
● Notification of unplanned downtime will be communicated by the IT department or
vendor via direct phone call.
● If the practice has not been notified by the IT department or vendor, it should contact
a representative during regular operating hours or contact the after hours help desk at
hotline number to report the downtime.
● The IT department or vendor will notify the customer via email or phone call when
the system is back online.
● Upon notification from the IT department or vendor or upon realization the system is
down, schedulers will adopt the downtime procedure process.
● Complete other business applications that do not require the system to be up and
running.

3.4.d Replacement Equipment

Hardware/Equipment Replacement service will provide replacement units in exchange for
Faulty Units. The service may build upon a correct combination of spares owned and kept by
Customer and/or us, for mandatory requested turnaround times guaranteed.

Hardware Replacement service may be contracted in two ways:

● Customers will be responsible for packing and handing over the relevant Faulty Unit
to us on our location. Upon the reception of the Customer's Faulty Unit, a new unit
will be placed at disposal to Customer within agreed timeframes.
● We will replace the Faulty Unit with Service Unit on Customer location (On-site
Advanced replacement) within agreed timeframes.

Spare log HW are going to be at all-time owned by the us or Third Party Hardware Vendor.
We are obliged to keep these HW up to date with the same type as installed in the live
Customer premise. Location of our owned spare log HW shall be at our or Third Party
Hardware Vendor premises.

3.4.e Software Installation

The Software Installation or Update service means the delivery of software or update
packages. For the purpose of rectifying the software / firmware errors in the system we shall
provide the following services:
● preventive software updating,
● urgent software updating

If the Software, Firmware and Hardware fault will be noticed by us, the Customer will be
informed as soon as possible.

The preventive software updating means the preparation, testing and installation of the
correction packages. We shall deliver to Customer packages for preventive system updating
in accordance with our and/or Third Party Software and Hardware Vendor global SW and
FW update strategy. For a quality support of the system, We shall prepare and do a
successive delivery of preventive packages in accordance with detailed SW update time plan
that shall be made by us and/or Third Party Software and Hardware Vendor and delivered to
Customer for advancing 12 month period.

Possible changes in the functionality of single parts of the System resulting from the package
replacement will discuss with Customer, and we shall request a written consent regarding
these changes.
The Service consists of two activities:
● SW Update Delivery (as part of Software Maintenance)
● SW Update Installation (as part of SW Change Management)

We may perform regular periodical checks on the system as part of preventive update
services. The scope of the check is to confirm that the HW, FW and SW status of the system
is in accordance with the latest Third Party Software and Hardware Vendor recommendation.
Report has to be sent to Customer on a regular basis.

Software and Firmware releases are provided to the Customer on a regular basis. This applies
to software and hardware updates and correction modules (so-called patches or patch-sets)
issued by us or Third Party Software and Hardware Vendor to correct reproducible defects in
the system within a software release

For each Installation or Update, we shall provide a detailed written procedure comprising all
working steps which must be performed before, during and after each of these measures. The
procedure shall be delivered with the package. We hand over to the Customer a delta list with
all data which will be changed with the installation. The procedure shall also comprise all
necessary working steps to fall back to the previous Software and/or Hardware version.

The Customer has to approve the implementation and proposed time schedule of the
delivered update/corrections. If the Customer decides not to install the corrections, problems
that occur due to missing updates are not considered system faults.

We perform the installation and commissioning of all software, hardware and firmware
releases on-site promptly after the Customer's approval. Telephone support for the correction
installations is available 24 hours a day and 7 days a week as part of the Emergency Service

Deliverables:
● Regular delivery of Software Update packages
● Before release to Customer, the Software Update packages are tested on our test-beds.
● Optional Customer specific testing can be organized
● Release documentation for each Software Update package describing all
improvements and corrections and installation procedures in electronic format
● Agreed scope, list of planned Software corrections
 ● List of agreed prerequisites
● Software change test plan
● Specification of (Software change related) Hardware requirements
● List of needed documentation, procedures and tools
● Customized installation manual including related implementation checklists
Implementation strategy
● Acceptance criteria
● Schedule of installation
● Responsibilities matrix
● Initial resource plan
● Progress reporting plan
● Initial downtime plan
● Competence transfer plan suggestion
● Schedule and sequence of the deployment rollout, including pilot deployment /
competence transfer
● Share of responsibilities table
● Communication channels and project management structure
● Support plan including escalation plan
● Recovery and contingency plan
● Competence transfer plan
● List of the change deployment documentation and checklists
● Progress reporting
● Follow-up reporting with KPI criteria definition

System Upgrades & Frequency of Upgrades: Upgrades are the installation of new software
or hardware and all related tasks. The frequency with which various components or elements
of ministry ICT system upgraded is determined primarily by the forces that motivate the
upgrade to introduce a new feature or other software improvements, fix defects, add faster
hardware and so on. Each type of component or element in the system(hardware, third party
product, our software) has its own consideration and therefore needs to be treated separately
in the requirements.
Updates contain important changes to improve the performance, stability and security of the
applications that run on your computer. Installing them ensures that software continues to run
safely and efficiently
Advantages: -
● Software upgrades increase the performance of the system.
● To fix errors and bugs new patches are available in the market for which you need to
update the software.
● You may get some improved features by upgrading the existing software. ...
● New features make the software more attractive and consistent.

3.4.f Spare Parts Holding

Spare parts, are extra parts that are available and in proximity to a functional item, for which
they might be used for repair. Spare parts management is the process used to ensure that
the right spare part and resources are at the right place (where the broken part is) at the right
time. A spare part, or replacement part, is an interchangeable part that is kept in an inventory
and used for the repair or replacement of failed units. Spare parts are an important feature of
logistics engineering and supply chain management, often comprising dedicated spare parts
management systems.

Rules for Effective Spare Parts Management:

● Go for preventive maintenance!
● Eliminate process problems
● Segment your spare parts portfolio
● Evaluate spare parts criticality
● Spare parts management starts with good forecasting
● Use special methods for intermittent demand items
● Consider the whole life cycle of your equipment
● Implement a good information system for spare parts and maintenance inventory
management

Deliverables:
● On receipt of defective FRU (Field Replaceable Unit) at nominated support center a
replacement FRU will be dispatched to Customer according to the agreed service
level. In case of On-Site Advanced replacement service, we shall provide FRU in
advance On-Site and handover the relevant Faulty Unit from Customer.
● The return transportation of a fully functional FRU to the predefined Customer
Delivery Point
● We shall regularly report to Customer metrics on the performance of this service
including information about FRU failures following repair of the FRUs
● Warranty for repaired or replaced FRUs (covering parts and workmanship) will either
be 90 days or the remaining initial Equipment warranty period or maintenance
service, whatever is longer. The repair warranty begins from the date of arrival at the
Customer site.
● Completed T2.2GJ Stock Holding of Spare document

Time for response shall correspond to the turnaround time agreed for the Hardware Support
and maintenance Service, and not for the Problem Resolution Processing Service.

The same procedure shall apply to the replacement of faulty equipment owned by Customer
(if the affected Hardware does not exist in the dislocated spare pool).
For each delivery the handover protocol will be issued and signed on the behalf of both
parties.

Accumulation of faulty equipment should be avoided, i.e. spare log replacement and filling
up dynamics should be respected in order to replace, repair, and return faulty tags to the
respective site as soon as possible in accordance with Third Party Hardware Vendor policy.

3.4.g Maintaining Information

The Process of Maintaining Information Systems is the process of returning to the beginning
of the SDLC and repeating development steps focusing on system change until the change is
implemented. Four major activities are involved namely a) Obtaining maintenance requests
b) Transforming requests into changes c) Designing changes d) Implementing changes.

Some of the Process / Steps of Maintaining Information Systems Deliverables are:

● Development of a new version of the software and new versions of all design
documents created or modified during the maintenance effort
● Conducting System Maintenance Corrective maintenance
● Changes made to a system to repair flaws in its design, coding, or implementation
Adaptive maintenance
● Changes made to a system to evolve its functionality to changing business needs or
technologies Perfective maintenance
● Changes made to a system to add new features or to improve performance Preventive
maintenance
● Conducting System Maintenance
● Quality of system documentation
● Number of customers for a given system
● Controlling Maintenance Requests and determine type of request.

3.4.h Data Security Measures

Data Security is the process of keeping data secure and protected from not only unauthorized
access but also corrupted access. The main focus of data security is to make sure that data is
safe and away from any destructive forces. Data is stored as rows and columns in its raw
form in the databases, PCs as well as over networks. While some of this data may be not that
secretive, others might be of private value and importance. But unauthorized access to such
private information or data can cause many problems such as corruption, leakage of
confidential information and violation of privacy.

Data Security is in the form of digital privacy measures that are applied to avoid this
unauthorized access to websites, networks and databases. There are many ways of protecting
or securing data which is important and some of them include encryption, strong user
authentication, backup solutions and data erasure. There are many international laws and
standards that govern data security measures. Data Protection Acts are implemented to ensure
that personal data is accessible to those whom it may concern.

Measures to Secure Data:

1. Disk Encryption: Disk encryption is one of the most commonly opted for data
security technology or methods. This is a technology through which encryption of
data on a hard disk drive takes place. This technology takes place in two major ways –
software or hardware. In disk encryption, data is converted into unreadable codes that
cannot be accessed or deciphered by anyone who is unauthorized.
2. Software and hardware based ways to protect data: Software-based security
solutions encrypt the data to protect it from theft, on the other, hardware-based
solutions can prevent read and write access to data. Hardware based security solutions
offer very strong protection against unauthorized access and tampering. But in the
case of software-based solutions, a hacker or a malicious program can easily corrupt
the data files and make the system unusable and files unreadable.
 3. Backups: The easiest & effective way to avoid data loss or to lose important and
crucial files is by taking a backup of data regularly. There are many ways to take
backup, while external hard disks are a common way to take backup, cloud computing
too proves to be a cheap and easy way to maintain a backup of all files at a safe
location.
4. Data masking: Data masking is another data securing technology that can be brought
into use by those who wish to secure their data. Another term that is used to refer to
data masking is data obfuscation and is the process through which one can hide
original data with random characters, data or codes. This method is especially very
useful for situations where you wish to protect classified data and do not want anyone
to access it or read it. This is a good way to let the data be usable to you but not to the
unauthorized hacker or user.
5. Data erasure: Data erasure, or data wiping and data clearing is a software-based
method of overwriting information or data and aims to totally destroy all data which
may be present on a hard disk or any other media location. This method removes all
data or information but keeps the disk operable.

3.4.i Antivirus
We will manage and check that the enterprise level antivirus solution installed on all systems
and devices (e.g. servers, laptops, desktops, mobile devices). Anti-virus software should also
be deployed on the network, including internet gateway, servers and end-user systems for
protection from malicious code. The anti-virus solution should be properly maintained and
updated accordingly. Centrally managed, up-to-date anti-spam and anti-malware protection
should be implemented at information system entry/exit points of the network and on all
devices.

Scans for malicious software packages or scripts should be performed on boot and at least
every twelve (12) hours. The anti-virus solution should perform periodic scans on
electronic/optical media, files received over networks, electronic mail attachments,
downloads, and web traffic to identify and remove malicious software. Anti-virus or anti-
malware software should be installed, running, and updated on all devices to conduct periodic
scans of the system to identify and remove unauthorized software. Antivirus should be
centrally managed and can’t be disabled by the users.

Malicious code that is identified should be blocked, quarantined, and an alert is sent to the
administrators. Audit logs of the scans should be kept for future references (e.g. audit,
forensic investigation).

3.4.j Record Keeping

Maintenance records of work equipment are a key part of health and safety management,
requiring efficient storage and management. Paperwork is often kept for extended periods of
time for health and safety or compliance purposes.
Record Keeping of equipment maintenance can be improved through efficient, digital
document & records management, keeping a record of information for each asset together
with indexed data for information such as:-
● Asset number
● Maintenance dates and times
● Equipment maintenance detail
● New parts added
● Manufacturer’s recommendations for maintenance
● Amount of use
● Equipment environment conditions
● User experience and knowledge
● Risk assessment information

Equipment Maintenance Report

Type of Equipment Maintenance Maintenance Comments

Method Frequency/Date

After problem and potential risk are identified, we shall propose a solution to ensure that
Customer equipment operates safely and efficiently. After the health check is completed, we
shall submit the equipment Health Check Report to the Customer.

3.4.k Preventive Maintenance (PM)

The goal of this strategy is to extend the useful life of the system and prevent breakdowns
from occurring. Preventive maintenance, or PM, is regular, planned maintenance that is
scheduled according to usage or time-based triggers. The purpose of PM is to lessen the
likelihood of equipment breakdowns and reduce the cost to our clients. Description of
services under Preventative Maintenance describes in Section: 3.1: Preventative
Maintenance (Hardware and Support).

In PM, our System Engineer will provide you a plan of regular maintenance periodically as
per SLA’s. Our System Engineer will check the MNIG system at regular intervals (Time-
based Preventive Maintenance) to inspect critical pieces of systems that would severely
impact production in the event of a breakdown. The team will record the data and present the
report at regular intervals to the client.

The planned maintenance work can often be arranged during non-production times, and this
eliminates any need for lost production. Implementing a preventative maintenance program
will enable us to detect and prevent many problems before they become incidents by ensuring
that the individual items that comprise your system are operating as reliably as possible.
Combining the preventative maintenance program with effective system monitoring will also
provide a means of measuring the effectiveness of the maintenance activities.

Our Internal or external technical support staff carry out most of the preventative
maintenance activities in the MNIG. The team maintains the reports for planned or scheduled
maintenance (PM) and our Manager will share the same with the ministry. Our team will
provide technical training and knowledge transfer after scheduled PM.

Preventative Maintenance Implementation Plan: Our aim is to help you begin to remove
some of the unpredictability by introducing best practice processes in small steps and so
begin to realize the benefits as quickly as possible. To ensure maximum system reliability,
each of the three elements of preventative maintenance needs to be addressed:
● Design: Set up the network in such a way as to minimize the possibility of the
component or system failure. This includes ensuring that all critical equipment is
protected from failure and that the network is secure from malicious or accidental
damage.
● Maintenance: Carry out periodic maintenance tasks on network equipment to reduce
the risk of early component failure.
● Preparation: Put systems in place to minimize the impact on the network when
components do fail. This includes maintaining a stock of spare equipment, keeping
detailed documentation on network components and having a plan for remedial
action.

Preventative Maintenance - Audits on the System and Hardware: Our Auditors regularly
do the schedule audits after each system release. To be effective, preventative maintenance
program needs to be built on a strong foundation of:
● doing the job right the first time
● duplicating systems and installations whenever possible
● documenting all configurations and procedures. If you cannot get everything done
exactly right, then by duplicating your work you can simplify debugging and
upgrading. If you are unable to achieve duplication, then by documenting everything
you do, you can understand the scope of what you're dealing with before you try to
implement changes or repairs. Without documentation, it will waste much effort
during maintenance, upgrades or disaster recovery.
● Measure, over time, the results of the Incident Management process. They should see
the number of incidents fall.
● Check the output from the Problem Management process. You should see a drop in
recurring problems.

3.5 System Application Maintenance

Application or Software maintenance is generally defined as any work performed on the
application system that is operational and used by customers. The maintenance activities are
unscheduled or random events initiated mostly by customers, but also can be initiated by
maintenance human resource (engineers or managers) or even by market. Application
maintenance includes short-term activities (e.g., fixing critical problems) as well as long-term
activities (e.g., a major enhancement to an existing system that result in new version of
existing system or in completely new software system)

● Maintenance is triggered by change requests from customers or marketing

requirements
● Changes are normally batched and implemented in a new release of the system
● Programs sometimes need to be repaired without a complete process iteration but this
is dangerous as it leads to documentation and programs getting out of step

3.4.1 Call Logging

We have industry standard tools (such as Bugzilla, Quality Center, JIRA, etc.) for log/track
the helpdesk call for any incidents/problem raised through the Ministry during the system
maintenance. The organization of a Help Desk involves the following considerations: Front
line- L1 (the employees who first come into contact with a customer), second and third levels
of support. Whenever a call is initiated by the ministry, our helpdesk team follows the
process below:
● Every time a support call comes into a Help Desk, that call must be logged and
tracked in our Logging software (Bugzilla, JIRA, Quality Center) by Frontline
Support person.
● The call, itself, must be logged, but the issue's status and progress must also be
tracked throughout the entire life cycle of the issue.
● Support Executive will provide a Ticket Number/Reference number for Call and
provide the estimated time to resolve the incident/problem.
● During Office hours Support:
○ Our Service Engineer will then report to the ministry office when he/she
arrives on site. Please ensure that this arrival time and date, and correct call-
out reference number (relayed to the person reporting the service request – see
above) is logged on the service report when the call is completed.
○ If the task is completed ministry will inspect the work performed, ensure that
the system/equipment is working correctly, and sign the service report to
signify that you (as an employee authorized to do so) are satisfied that the
work is in fact complete
 ● After Office hours Support:
○ Our helpdesk will record your call and get your information like (Office/Site
Location, name of person placing call, a contact person onsite and contact
number)
○ The exact nature of the problem and requested action. Please ensure that you
get a reference number from the technician. This is your call-out number and
confirms your proof of a request for service. Without this number your call-
out cannot be followed up.
○ Our service engineer will then report to the Ministry office when he arrives on
site. Please ensure that this arrival time and date, and correct call-out reference
number (relayed to the person reporting the service request – see above) is
logged on the service report when the call is completed.
○ If the task is completed ministry official will inspect the work performed,
ensure that the equipment is working correctly, and sign the service report to
signify that you (as an employee authorized to do so) are satisfied that the
work is in fact complete.

More details of call logging software(JIRA) are mentioned in Section 5.1- Support Model.
The Monthly or Quarterly/yearly, call logging reports will be generated by the software in
tabular(excel) or graphical format and shared with respective Ministry teams. The reports will
be in below format and configurable by the user or administrator:

Tabular Reports:

Monthly Incident Report

Report Created By: Report Month : 01/xx/20xx -

30/xx/20xx

Number of Number of Number of Number of Details of Site/Office Other

Incidents Incident Incident Escalated Escalated Location Fields or
reported Resolved Pendings Calls call parameter
Status Status can be
added

3.4.2 Monitoring and Management

Application/System Performance Monitoring is more than just monitoring metrics on a
dashboard with a monitoring solution. Simply put, monitoring application performance is
about ensuring that
business applications are performing as expected, at all times, with proper tracking and
reporting of performance issues. Our goal of an application performance monitoring is to
ensure that the supply of services to end users is uninterrupted and that the quality of
delivered end user experience is supreme. Our Technical team will support to provide 99.9%
uptime of each server, PC, peripheral and specialized software like Card printer, scanner,
Passport and card reader, etc.) mentioned by the ministry.

1. Server & infrastructure: The role of IT Ops teams is to solve internal as well as
client needs by ensuring the infrastructure and operational environments supporting
application deployments are in order. Application Performance Monitoring
Management therefore becomes extremely crucial in maintaining a continuous and
smooth flow of operations. Given the size, scale, and efficiency of business
operations, App Performance Monitoring tools can offer some invaluable benefits to
manage business critical applications.

The bottom most layer of any software stack is the infrastructure layer. Monitoring
CPU usage, load, memory, server uptime, etc. are some of the primary steps involved
in infrastructure monitoring which is a part of application performance monitoring.
Consider the following cases:
a. Information about CPUs running at full capacity
b. System processes using high resources
c. Network load in the server
d. CPU, memory, Disk I/O analytics

Below is a sample dashboard of application performance management.

These are some of the key metrics that IT admins rely on to understand and optimize server
and network performance through thorough network application performance monitoring,
and plan capacity upgrading as well as resource allocation. Once the infrastructure elements
are covered, the next layer is the applications that are hosted on these servers. While some
key metrics can be retrieved with ad hoc scripts, a comprehensive application performance
monitoring software can dig deeper and wider to present more than just a few performance
counters of these business applications. If your application performance components right at
the grassroot levels are measured, it is an indication that the foundations of your app
performance monitoring principles are strong.

2. End- User Experience

Measuring end user experience is a paramount importance to meet customer expectations and
retain them in the long term. A good user experience leads to continued usage of service
which directly translates to more revenue generated.
Usually, an application monitor employs a technique record, and re-run possible end user
interactions with a given web application by executing behavioral scripts. These transaction
details present important information that can ensure your application can handle the
projected load. These synthetic transactions in any application monitor are captured with an
agent that executes these transactions and collects information for optimal web app
performance monitoring across geographies. An application monitor that enables End User
Experience monitoring, also known as digital experience monitoring, then offers the
following benefits to business organizations:
1. Test and monitor application performance before its launch
2. Become aware of performance issues before the end user does
3. Measuring impact of third party components in your application
4. Performance stats for application access across geographies

3.6 Proposed Maintenance Services

Priority/Severity level definitions: Whenever the incident/defect call is logged by our
helpdesk team, the priorities are given. The table below describes priorities which we follow
in our SLA. On each incident while call recording, a priority is assigned to the defect. The
more details about Priority driven approach is described in 3.3 Priority Driven
Development.

Incident Description Target Target

Priority Response Resolution
Time Time
Critical Emergency situation with severe business Immediate 1 Hour
impact
High Incidents that affect business and users but 10 Minutes 4 Hours
can continue with reduced functionality
Medium Incidents that affect only few user 1 Hour 8 Hours
performing standard business operations
Low Incident with low impact on the business and 4 Hours 24 Hours
only affect specific users

Other proposed Application Maintenance services: The other proposed services shows
below:
● Hours of support
● Services to be provided
● Services Levels to be delivered
● Levels of services provided for standard and non-standard hardware/software
● Communication Channels

The Proposed Application Maintenance Service described in Section 3.3 and Section 4
4.0 Maintenance

4.1 System Releases

The ICT Solution and System will be organized in periodic releases for new releases and
upgrades. ICT Solution includes all the components that are developed within the project and
that have reached the production quality.

Four Type of Releases have been identified for a given component

1. Major Release
2. Minor Release
3. Revision Release
4. Emergency Release

The type of release is reflected in the version of the corresponding package(s) and will be
described in the Software Release Plan.

System Failure and Break Down: Prepare your system for failure while proper preventative
maintenance of any sort provides the opportunity to detect and correct problems before they
become incidents, it cannot prevent all failures. However, we establish an effective
preventative maintenance program that will minimize the effects of problems when they do
occur. It will also put ministry in a position to rectify incidents with a minimum of fuss,
outlay, and disruption to the users of your system.
There are measures you can take to ensure that, when components fail, you can repair the
network in the fastest possible time. These include:
● maintaining a stock of spare equipment (in case of hardware failure)
● using Configuration Management to keep detailed documentation on software and
hardware components so that we can quickly rebuild them
● backing up critical data – and testing the back-ups
● using Service Level Management to identify who is responsible for what.

System Backup: Below is our System Backup policies

● The Backup will be maintained regularly on the space provided on the Hosted server
of the MNIG or on the storage media as per ministry policy.
 ● We keep a paper copy of the server configuration file.
● We keep the DATs or other removable media in a secure location away from the
computer.
● Always back up the data before leaving the workstation.
● For sensitive and important data offsite backup would be used.

Sandbox Functional Testing: In each release after any changes or incidents, our team
performs Sandbox functional testing. The Sandboxing protects "live" servers and their data,
vetted source code distributions, and other collections of code, data and/or content,
proprietary or public, from changes that could be damaging to a mission-critical system or
which could simply be difficult to revert, regardless of the intent of the author of those
changes. Sandboxes replicate at least the minimal functionality needed to accurately test the
programs or other code under development (e.g. usage of the same environment variables as,
or access to an identical database to that used by, the stable prior implementation intended to
be modified; there are many other possibilities, as the specific functionality needs vary
widely with the nature of the code and the application[s] for which it is intended).

The Sandboxing Testing will built-in revision control software in which technical person
"check out" a copy of the source code tree, or a branch thereof, to examine and work on. Only
after the technical person has fully tested the code changes in their own sandbox, the changes
would be checked back into and merged with the repository and thereby made available to
the system release.

Creation of New Elements: Building upon this, systems maintenance "an alteration to any
systems element necessary to eliminate a fault in that element, adapt to a change in that or
any other element, or to improve upon the performance characteristics of an element." Any
addition of new elements in the system goes through the regular change management process
and system lifecycle.

Fall back plan in case of system upgrade failure - The fallback plan is a part of the project
management plan and defines under which circumstances action has to be taken. A fallback
plan is implemented when the contingency plan fails or is not fully effective. It is a backup
for the contingency plan. The fallback plan is generally made for residual risks.
The fallback plan is a set of alternative actions as well as tasks that are available in the event
that the main plan needs to be abandoned due to some issues, risks as well as other causes. In
most cases, the main or primary plan is called the contingency plan but if it does not work,
the fallback plan serves as the backup. As if “Plan B”.
System upgrade failure happens can be classified under 4 types:
● Type 1 corresponds to simple configuration errors (typos or structural) and to
procedural errors that occur on the skill-based cognitive level. These faults break
dependencies on network addresses, file paths, or the replication degree.
● Type 2 corresponds to semantic configuration errors, which occur on the knowledge-
based cognitive level which indicate a misunderstanding of the configuration
 directives used. These faults break dependencies on the request scheduling, cached
data, or parameter constraints.
● Type 3 corresponds to broken environmental dependencies, which are procedural
errors that occur on the rule-based cognitive level. These faults break dependencies on
shared libraries, listening ports, communication protocols, or access privileges.
● Type 4 corresponds to data-access errors, which are complex procedural or
configuration errors that occur mostly on the rule- and knowledge-based cognitive
levels. These faults prevent access to the system’s persistent data, breaking
dependencies on database schemas, access privileges, the replication degree, or
storage availability.

4.1 Incidents, Problem, Changes

ITIL [R1] defines a change as the addition, modification or removal of authorized, planned or
supported service or service component and its associated documentation.

One of the main sources of RfCs is the incidents reported by users through the support
channels. ITIL defines an incident as an unplanned interruption to an IT service or a
reduction in the quality of an IT service. Failure of a component that has not yet affected
service is also an incident.

After an investigation by the different levels of support, an incident may be traced to an

actual problem in the code. ITIL defines a problem as the cause of one or more incidents.

If that is the case, the problem is recorded into an RfC tracker (e.g. RfC Tools like JIRA,
Bugzilla, RT, etc.) and further processed by the team responsible for the affected component,
usually leading to changes in the code.

Another major source of RfCs is the continuous stream of user requirements, notably from
the MNIG and similar bodies. Requirements are collected and processed by the <CN> and
addressed by the respective team. They are maintained in a dedicated tracker [R2]

Finally, RfCs, both to fix defects and to introduce improvements, can also be generated
internally in the project or even in the Product Team itself in charge of a given component.

Change Management
During the life of the contract, changes will occur that warrant special processing. Some
changes will have impacts on the scope, budget, contract and/or timeline of other
enhancements or bug fixes. The plan is the guide on how to handle these types of changes
through a controlled process. The Change Management Plan may be updated with the
agreement of both parties. The plan will identify the process, procedures, and tools utilized to
execute Change Management for software, systems, plans, procedures, and Frequency
requirements and enhancements for ministry.
The Change Management Plan will be developed by our Project Manager and shall become
effective when approved in writing by the Ministry. The Change Management Plans shall
contain, but not be limited to, the following concepts:
● Review, creation, and approval process for Enhancement Request Forms and Change
Request Forms, which shall include at a minimum, a description of the business
requirements, the technical specifications required to satisfy the request, fixed-hour
estimates, estimated timeframe and appropriate approval signatures for each
enhancement request or change request.
● Review and creation of an Enhancement Request Log and a Change Request Log,
which shall include at a minimum, the enhancement or change request number, a link
to the Enhancement Request Form or Change Request Form, a description of the
enhancement or change, the priority (high, medium, low), the status and the date of
delivery.
● Identification and coordination with the appropriate third-party vendor (e.g. Dell) for
operational versions, upgrades, new releases, and emergency fixes to hardware.
● Installation and maintenance of application upgrades in the Production, Training, QA
environments as well as the Dataguard and Disaster Recovery Box.
● The work identified in the change requests will be provided by the technical team as
agreed upon in the SLA, with adjustment to project schedules and required
timeframes and milestones as appropriate.
● All change requests are to be provided in exchange for a fixed or “not-to-exceed”
compensation. The vendor shall be solely responsible for any costs in excess of the
specified compensation.
● Procedures through which the Parties interact to propose, refine and if an agreement is
reached, execute documentation binding them to proposed changes or enhancements.
● All change requests will be represented on all project reports, clearly indicating
progress and their status.

Impact Analysis: Impact analysis describes how to conduct, cost-effectively, a complete

analysis of the impact of a change in existing software. Maintainers must possess an intimate
knowledge of the software’s structure and content. They use that knowledge to perform
impact analysis, which identifies all systems and software products affected by a software
change request and develops an estimate of the resources needed to accomplish the change.
Additionally, the risk of making the change is determined. The change request sometimes
called a modification request (MR) and often called a problem report (PR), must first be
analyzed and translated into software terms. Impact analysis is performed after a change
request enters the software configuration management process. The impact analysis tasks:
● analyze MRs/PRs;
● replicate or verify the problem;
● develop options for implementing the modification;
● document the MR/PR, the results, and the execution options;
● obtain approval for the selected modification option.

The severity of a problem is often used to decide how and when it will be fixed. The software
engineer then identifies the affected components. Several potential solutions are provided,
followed by a recommendation as to the best course of action. Software designed with
maintainability in mind greatly facilitates impact analysis. More information can be found in
Software Configuration Management.

Issue identification, conclusion, investigation, and solutions delivery: The System

Maintenance is in general responsible for corrective Maintenance (involving adaptive,
preventive and perfective) and restorative maintenance to address defects, impacts, potential
defects, minor improvements found in running services in the production environment, based
on RfC (Request for Change) in the code of ICT Solutions.

Issue Log
Project: Date:
Issue Descripti Priorit Categor Reporte Assigne Status Date Resolution/
on y y d By d To Resolved Comments
(H, M,
L)
This A High, Assign Who Who is What is What What was
should detailed Mediu to a reported the the date was the
be a descripti m or category the issue status the issue resolution
standar on of the Low . issue? assigned of the resolved? or what is
d issue. priority to? issue? being done
number . to resolve
ing the issue?
system.

4.2 Priority Driven Development

Our team addresses any maintenance, it is necessary to define how to select RfCs that qualify
as corrective or adaptive. The criterion for such classification is the priority of the RfC, where
the priority is the result of the composition of a number of factors:
 ● severity: a measure of the degradation of the quality of service of the affected
component;
● impact: a measure of the effect of the degradation of the quality of service of the
affected component;
● urgency: a measure of how long it will be until the quality of service of the affected
component is not significantly degraded;
● cost: a measure of the resources needed for the management of the change, including
the risks associated with the degradation of the quality of the affected component in
case the change is not fully successful.

The evaluation of the priority of an RfC results in one of four possible logical values. Each
level implies a very specific behavior for the management of that RfC.

Priority Levels: The four priority levels and the corresponding behaviors are:

● Immediate: The RfC needs to be addressed as soon as possible, in all affected ICT
System major releases. A release containing Immediate-priority changes can contain
only Immediate-priority changes. Multiple Immediate-priority changes can be
included in the same release, provided that any change does not delay the release
significantly. This constraint minimizes the risk of introducing new defects in the new
release of the affected component and allows the adoption of special accelerated
procedures for its release. Moreover, it will not force site administrators to deploy
lower-priority changes during an emergency update.
● High: The RfC will be addressed in the next release of the affected component, in all
affected ICT System major releases.
● Medium: The RfC will be addressed in the release of the affected component that
will be shipped with the next ICT System’s major release.
● Low: There is no target date for addressing the RfC.

Each logical value needs to be mapped to a specific value in the tracker used by each PT. The
priority of an RfC can be suggested by the proponent, but the PTB is the ultimately
responsibility for setting it.

Incident Priority Matrix

Incident Priority is derived from urgency and impact, an Urgency-Impact Matrix (also
referred to as Incident Priority Matrix) can be used to define priority classes.

Impact
H M N
Urgency H 1 2 3
M 2 3 4
L 3 4 5
Priority Code Description Target Response Target Resolution Time
Time
1 Critical Immediate 1 Hour
2 High 10 Minutes 4 Hours
3 Medium 1 Hour 8 Hours
4 Low 4 Hours 24 Hours
5 Very low 1 Day 1 Week

4.3 Tracking of Change Requests/Incidents/Problems(Bug Fixes)

Each RfC/Incident/Problem needs to be tracked with an appropriate tool. Currently used
trackers include JIRA/ Bugzilla )-- Tool. For each RfC the following information should be
available or recorded:
● a URL pointing to a description of the RfC. If the RfC concerns a security
vulnerability the URL should point to a private page. The URL acts also as a unique
identifier for the RfC;
● if applicable, one or more URLs pointing to incident tickets (or equivalent incident
reports) that have caused the opening of this RfC;
● the affected component (the list of components is included in the Technical
Development Plan);
● the ICT System major release(s) including a version of the component that is affected;
● whether the RfC is platform-specific and, if so, which are the affected platforms;
● the priority, according to the classification in Section 3.3;
● whether the RfC is to fix a defect or to introduce a new feature;
● the state of the RfC and the date the RfC has entered each state. The minimal set of
logical states is: Open (just submitted), Accepted (assessment has been done and RfC
accepted), Fixed (change committed to the VCS), Closed;
● for Closed RfC, the resolution (solved/won't fix/unreproducible/invalid/etc.);
● the detection area, that is the context in which the version of the component affected
by the change is available. Possible values are “production”, “testing” and
“development”;
● whether the change has been verified during testing. If it has been, the report for the
test should be included in the documentation that accompanies the release of the
affected component. Likewise, the lack of verification should be justified in the
documentation;
● the target system release where the change will be available;
● the target ICT System major release (or QC, JIRA, ARC, dCache, gLite or UNICORE
major releases in the transition period) where the change will be available;
● whether the RfC has already been approved.
If the same RfC is going to be applied to the different levels of releases or to different ICT
System major releases, then an RfC is created for each release. An Open RfC should be
assessed within two weeks and as a result, it should either be Accepted or Closed with a
resolution different from solved; An Accepted RfC whose priority is Immediate or High
should be immediately associated to a next release of the affected component.

The above information will be collected periodically, at least once a week, to allow the
Software Maintenance task leader to monitor the progress of the task. Any anomaly will be
brought to the attention of the leader and if necessary of the MNIG Team. Each Change
Manager is responsible to report RfC information according to the format defined by SLA.

Change Request Log and Change Request Form: We deliver a draft of the Change
Request Log and the Change Request Form as part of the Change Management Plan and shall
maintain the Change Request Log on an ongoing basis for the term of the contract. The
Change Request Form must include, at a minimum, a description of the business
requirements, the technical specifications required to satisfy the request, fixed-hour estimates,
an estimated timeframe and appropriate approval signatures for each change request.

Change Request Log

Project: Date:
Change Change Description Requestor Date Date Status Comments
No. Type of Change Submitted Approved

Each This may The change Who When was When was Is the change This section may
change be a request initiated the request the request request open, describe why the
request design, should be the change submitted? approved? closed or change request was
is scope, described in request? pending? rejected, deferred
assigne schedule detail. Has it been or provide any
d a or other approved, other useful
referenc type of denied or information.
e change. deferred?
number.

Change Request Form

System/Project: Date:
Change Requestor: Change No:
Change Category (Check all that apply):
□ Schedule □ Cost □ Scope □ Requirements/Deliverables
□ Testing/Quality □ Resources

Does this Change effect (Check all that apply):

□ Corrective Action □ Preventative Action □ Defect Repair □ Updates
□ Other
Describe the Change Being Requested:

Describe the Reason for the Change:

Describe all Alternatives Considered:

Describe any Technical Changes Required to Implement this Change:

Describe Risks to be Considered for this Change:

Estimate Resources and Costs Needed to Implement this Change:

Describe the Implications to Quality:

Disposition:
□ Approve □ Reject □ Defer
Justification of Approval, Rejection, or Deferral:

Change Board Approval:

Name Signature Date

Enhancement Request Log and Enhancement Request Form: We deliver a draft of the
Enhancement Request Log and the Enhancement Request Form as part of the Change
Management Plan and shall maintain the Enhancement Request Log on an ongoing basis for
the term of the contract. The Enhancement Request Form will include, at a minimum, a
description of the business requirements, the technical specifications required to satisfy the
request, fixed-hour estimates, an estimated timeframe and appropriate approval signatures for
each enhancement request.

4.4 Organizational Chart and Roles

The assessment and the approval of all the RfCs concerning EMI components are the
responsibility of the Change Advisory Board, formed by the MNIG members and by our
Change Management Team. The assessment includes specifically the determination of the
priority of an RfC and its association with the ICT System’s major release(s) where it will be
implemented. The MNIG can delegate decisions concerning corrective and adaptive
maintenance. No RfC can be introduced in production releases without approval. The role of
Manager Maintenance, i.e. following the process of controlling the life-cycle of approved
changes, is taken either by the Maintenance task leader or by the leader, depending on
whether that RfC is for a defect or for a new feature.

4.5 Documentation
CN team will maintain the ICT system and documentation as outlined in the following table:

Documentation Deliverable Overview

User Manual User documentation to coincide with all software

releases. We shall deliver updated documentation the
day the release is in production and will upload it to
the ICT application. The Manager shall identify the
user documentation as a deliverable on each software
release project plan.
 System Documentation Update system documentation within 20 working
days of a software release, coordinate updates that
overlap during milestones and identify the system
documentation as a deliverable on each software
release project plan.

Operations Manual Update the operations manual at least twice per year
and after each major software release.

Data dictionary/database structure Update the ICT System data dictionary and database
structure as changes are made to the system involving
the database.

4.6 Meetings
Steering Committee Meetings: The Steering Committee Meetings consisting of the
executive sponsors and key executive stakeholders. These meetings will be held as per the
Project Communication Plan at regular intervals in each quarter of the year. This committee
will oversee all aspects of the project and will ensure that their project team is executing the
project according to the plan and satisfying the expectations of MNIG/IT as an organization.
In addition, they will ensure that the team assembles all of the sponsorship and support
required to implement the system once it is complete.
Responsibilities
● Oversee all aspects of the project
● Ensure that the team assembles all of the sponsorship and support required to
implement the system once it is complete

Maintenance Meetings:
Our personnel will schedule and chair regularly scheduled status meetings (every week
throughout the duration of the contract or as determined by the Ministry). Our Project
Manager will be required to participate, which can be accomplished by teleconference call or
on-site as appropriate. Our personal shall prepare weekly status reports. These status reports
shall clearly indicate the status of each ticket and any expected changes to the time, quantity,
or quality of the fix or deliverable. The status report shall include details about the status of
tasks and project deliverables that are completed, in process, planned, delayed, or added. The
report must include any updates to the Risk Matrix, Issues Log, Project Work Plan, the
Change Request Log, the Enhancement Request Log and other documents reasonably
required by the ministry.

Team Meeting - Action Items

MM/
Department: <Client Name> Report Date: DD/
YYYY
 MM/
Project Name: <Project Name> Last Report Date: DD/
YYYY
Meeting Location: ABC Meeting Time HH:MM
Project Manager: <Client> Project Manager:
Attendees:
Decisions Agreed to in this Meeting
Specific Topic or Decision
Question

Action Items and Open Issues

Item Description Date Contac Status
t
MM/DD/YYYY
MM/DD/YYYY

4.7 Maintenance Schedule

Periodic maintenance of IT systems is mandatory and as per preventative maintenance
strategy. Here are some of the reasons why:
● Security patches
● Hardware upgrades
● Software patches and upgrades
● Software and component installations
● Re-configurations
● Server reboots
● Availability and fail-over testing
● Maintenance schedule to upgrade patches and versions and to check for errors

Duration Description of Maintenance

Weekly

Monthly

Quarterly

Yearly
4.8 Service Maintenance Reports
We will compile monthly reports detailing system availability and any problems experienced
during the month. These reports will include help desk call statistics, a problem log summary
and shared with the client manager.
● Graphical Report - line graphs, bar or pie charts,
● Tabular Report- table of incidents/bug counts in 1 or 2 dimensions table.

4.9 Disaster Recovery Plan

We have a Disaster Recovery Plan to maximize provisions for continuous availability (warm
site) or timely recovery and resumption of service during times of disaster. Our team will
work with the Ministry to submit annual updates for review and approval. We shall conduct
or participate in annual disaster recovery tests and update the Disaster Recovery Plan to
improve on identified issues. These tests may be required in conjunction with the Disaster
Recovery exercise. Our team will try to recover all systems and system databases within 24-
48 hours after a disaster occurs once the Ministry makes available the appropriate hardware
and operating system. Disaster Recovery tests would be performed once a year

4.10 Key Performance Indicators (KPI)

The KPIs mentioned in the Description of Work and relevant for the system maintenance
Task are:
● The number of Problems Number and trends of problems (defects) submitted in the
Defect Tracker(s) (in total and per category) as an absolute value and as density over.
Information on the number and categories of problems is extracted from the RfC
reports.
● The number of Urgent Changes Number of changes (defects or enhancements) with
priority Immediate. Information on the number, type, and priority of RfCs is extracted
from the RfC reports.
● Change Application Time Average time, from incident submission to release, for
applying a change (possibly per category and priority). The submission time of an
incident causing the opening of an RfC is available in the incident report (typically a
support ticket). A reference to the support ticket and the rest of the information
required to compute this metric - the time the RfC is closed, categories and priority -
are available in the RfC reports.
● Servers Uptime: This information need from CN< Client>

The KPIs are continuously collected and reported by the Change Management task on
Metrics and KPIs Definition and Reporting. They will be monitored by the Software
Maintenance task leader and any anomaly will be brought to the attention of the Change
Manager and to the MNIG.
5.0 User Support
The User Support task is responsible to coordinate the support, together with MNIG, to users
of the ICT System developed within the project and included with Hardware Support vendor.
Support activities will be regulated by Service Level Agreements with CN customers.
Although support requests can concern anything from documentation to configuration, from
receiving advice to asking for a new feature, the following description will concentrate
mainly on incidents, Software bug fixes, user management, automated server monitoring,
website usage reports, OEM patches because that is the type of request that will involve the
support task.
Our Support may include below services but is not limited to:
● Application maintenance to resolve routine bugs and fixes
● Management of scheduled upgrades and patches
● Enhancements that improve system functional capabilities
● Data governance capabilities to ensure data is entered consistently to defined data
standards
● Integration alignment that ensures timely and accurate data exchanges
● Individual user support to triage and resolve specific user issue
● System audit capabilities to ensure application compliance

5.1 Support Model

Our Support Model consists of:

● Onsite Support/Visit
● Offsite 24/7 Support
● On-Call 24/7 Support (Hotline)
Call logging: All calls for any incident/problem will be logged in our incident Management
system (QC/JIRA/Bugzilla) by our helpdesk team.

● The client may request assistance through any mode of communication

(Phone/Email/Support Portal/Chat). Our helpdesk will assist each instance and log the
call in our Incident Management system.
● When logging an incident, we ensure the Priority (Urgent/High/Normal/Low) is set
appropriately.
● Our Support Team will respond to logged support incidents in line with the
customer’s Service Level Agreement.
● Each incident will be given a Reference Number and status.
● Monthly Maintenance Reports will be shared by our manager to the ministry team
which contains a summary of incidents and related information.

Below are screenshots of call logging management using JIRA. (Reference:

[Link]

Step 1: In JIRA to create an incident or issue/problem, it would be to create an issue of

the type “Bug”.

Step 2: Incident/Defect reporting needs the following information recorded for every
issue:
● Defect ID
● Defect title
● Defect description (steps to reproduce)
● Environment information
● Screenshot(attachment)
● Severity
● Assign it to someone
● Status- All the statuses in the bug life cycle
All the options are available to be able to create a defect effectively.
Please note the fields highlighted in Red below:
The two fields that are not seeing here are:
● Defect ID
● Status
These two fields are auto-created by JIRA. All issues will have a unique ID assigned to them
by JIRA. Status of all issues is “To-Do” or “New” in JIRA by default on creating a bug.
Therefore, all the common facilities for defect reporting are available in JIRA too. In fact,
more options such as labels, linking defects, estimating efforts can be used.

Step 3: Defect Life Cycle

The Defect bug cycle can be customized by JIRA admin, but it is easy to do. For those, do
not want to bother with the customization, you can’t go wrong with the default set up as well.
Step 4: Comments and collaboration with the Technical Team
Every issue, its updates, people assignment, comments received from the Technical team –
everything is tracked in JIRA under the activity log.
This allows for better visibility and collaboration with the development teams:

Step 5: Linking the defect to a requirement to enable traceability

Link option in the JIRA issue fields lets you link a particular issue to another one. Let’s say if
Defect 2 is a duplicate of Defect 1 you can establish that relationship.

Similarly, if a defect is blocking a requirement or is related to a requirement – you can make

this aspect visible in JIRA.
The resulting links will appear in the issue details page as below:

The relationship types are self-explanatory and the usage of simple-common-everyday-

language words (such as relates to, caused by, etc.) makes it super easy and intuitive for any
JIRA user to use this right.

Step 6: Defects can be imported from a CSV file

This aids the bulk creation of issues in JIRA at once. Also, if your team is new and you don’t
want them creating issues directly into the tool, you can have them report the defects in an
excel sheet. Once they are reviewed and confirmed as valid, they can be imported all at once
into the tool using this functionality.
Whichever way you use it, this is a big plus.
Step 7: Defects can be exported into Word, XML, and printable formats

This supports better portability of your defect data, especially useful if you want to share your
defect data with people who are non-JIRA users.

Step 8: Comprehensive Issue Reports:

In addition, if you need reports go to “Project – reports” and generate all sorts of reports as
below:

5.2 Escalation Process

The escalation process is the way in which the PM communicates certain changes, with
respect to the project forecasts, at the board of directors of the company. The projects can fail
for the most disparate reasons, but probably the main one is the failure to correctly monitor
the project. An escalation plan is a set of procedures set in place to deal with potential
problems in a variety of contexts. An escalation is a process of calling upon higher levels of
project leadership or management to resolve an issue. When two parties are unable to agree
on the resolution of an issue after a good faith effort to negotiate than an escalation is pursued
to resolve the issue. There are two types of escalations: hierarchical and functional.
Escalation plan includes:
 ● Call volume management, which involves switching (either manual or computer-
controlled) to channel calls efficiently.
● Stage management, which is used to avoid escalating a crisis from a disruption to a
full-blown emergency.
● Test management, which tactically evaluates all levels of the escalation plan.

Escalation Management is to bring order, structure, focused management attention and

additional resources to those customer situations which could otherwise result in a high level
of customer dissatisfaction and/or damage to the service provider’s reputation. These are
situations that could lead to significant loss of business to the Customer or IT Service
Provider or where significant costs may be incurred by IT Service Providers to resolve the
customer situation. The criteria to trigger an escalation depend on the organization or service
provider. But it should be well defined.
The Escalation process could consist of the following activities:
● Initiate an Escalation, based on meeting specific escalation criteria,
● Assign an Escalation manager for the escalation,
● Log the Escalation and link the Escalation record to related Incident or Problem
records,
● Escalation manager assigns or appoints the escalation team. The escalation team
should include the Incident owner, Problem owner, and other subject matter experts,
as required,
● Identify appropriate Service Provider and Customer management contacts,
● Conduct a detailed situation appraisal and review, led by the Escalation manager,
● An escalation management action plan, including additional resources needed, is
developed in conjunction with the Customer. The escalation management plan is to be
executed in parallel with the detailed technical action plan (as per Incident/Problem
Management),
● The escalation management action plan is reviewed and adjusted as required,
● A Hierarchical Escalation (as per Incident Management process) is initiated, if
appropriate. Senior management and executives are alerted,
● The escalation team works to resolve the problem. At each stage, records are updated
and manage contacts and team are informed of the progress and escalation plan
reviewed and adjusted as required,
● Once resolved to the Customer’s satisfaction, the situation is monitored for an agreed
period,
● The escalation team remains on standby and available in case the problem recurs
during the monitoring period,
● Once the monitoring period is successfully completed, the escalation is closed by the
Escalation manager, after seeking agreement with the Customer,
● Once the escalation is closed, a post escalation review is conducted and input
provided to the Problem Management process. This can be done in conjunction with
the Major Problem Review which is part of Problem Management.
Escalation management is closely related to and supports the Incident Management, Request
Management, and Problem Management processes

5.3 Incident Resolution

In case an incident is reported, the goal of the user support activity is to restore normal
service operation as quickly as possible, thus ensuring that the best possible levels of service
quality and availability are maintained. What “normal service operation” means is defined in
the Service Level Agreement (SLA) established between CN and the infrastructure deploying
ICT System to MNIG. An incident may or may not be caused by a problem. If it is, a
corresponding entry shall be created by the Support Unit in the RfC tracking tool specific to
the affected software product and the two should be crosslinked. In a support ticket, this is
done using the “Related issue” field. The incident should stay open until a satisfactory (for
the user) solution is found. The solution may not necessarily require that the causing problem
is fully fixed, for example, an acceptable (according to the SLA) workaround may exist. If
the incident resolution instead does require that fix, then the ticket should stay open until the
RfC corresponding to the fix is Closed, i.e. it becomes part of a new product release.

Incident Time Measuring and Reporting shows how the time to solve incidents shall be
measured and reported to check Objective.

Objective Decrease time to solve incidents

Critical Success Factor
(CSF) Decrease time to solve incidents
Key Performance Indicator Increase percent of incidents solved within agreed times to
(KPI) 96%
Metrics Percent of incidents solved within agreed times before
improvement implementation
Percent of incidents solved within agreed times after
improvement implementation
Measurements Time to solve each incident compared to the agreed time for
each category of incidents
Frequency: Updated daily
Reports Incident Report
Frequency: Monthly

5.4 Key Performance Indicators (KPI)

The KPIs mentioned in the Description of Work and relevant for the User Support Task are:
● The number of Incidents Number and trends of incidents registered by the CN
Support Units (in total and per category). Periodic information on the number,
categories and submission time of the incidents escalated to the EMI Support Units,
including the generic Support Unit, are extracted from support tickets.
● Incident Resolution Time Average time for resolving an incident by the 3rd-level
support (possibly by category). Information on the number, categories and submission
and resolution times of the incidents escalated to the CN Support Units are extracted
from the Support Ticket Tool. The KPIs will be continuously collected and reported
by the task on Metrics and KPIs Definition and Reporting. They will be monitored by
the User Support task leader and any anomaly will be brought to the attention of the
leader and to the MNIG Team.
● Customer Satisfaction Survey: Do you have any template to add Customer
Satisfaction periodically. Our Change Manager will directly coordinate with the
ministry team to track our services.

Customer Satisfaction Measuring and Reporting shows how the time to solve incidents
shall be measured and reported to check Objectives
Objectives Improve customer satisfaction with Help Desk
Increase accuracy of service provided
Critical Success Factor
(CSF) Increase customer satisfaction with service received
Key Performance Indicators Increase customer satisfaction with how Help Desk handle
(KPI) requests to 80 %
Increase customer satisfaction with the quality of solutions to
75 %
Metrics Customer satisfaction score before improvement
implementation
Customer satisfaction score after improvement
implementation
Measurements Customer satisfaction survey with focal groups
Frequency: Monthly
Reports Incident Report
Frequency: Monthly

Services - Customer Satisfaction Report

Documen
t: Service Improvement Plan From: 1-Jan-xx
Organizat
ion: To: 1-Jun-xx
Responsi
ble: Service Level Manager

1. Objective I: Increase Service Availability by Means of Web Access

Responsi
# Action ble Start End
Acquire Web licenses of the Supply 15-
I.a Service Desk system Manager Jan-xx 30-Jan-xx
I.b Configure Web access for Applicatio 1-Feb- 1-Mar-xx
customers n xx
 Manager
Knowledg
Train users and Help Desk e 1-Feb-
I.c personnel Manager xx 28-Feb-xx
Availabili
ty 1-Jan-
1.d Monitor availability Manager xx 30-Jun-xx
Result: Service availability increased through web access
Measurement: Availability %

2. Objective II: Decrease Time to Solve Incidents

Responsi
Action ble Start End
Define and implement auto- Event 10-
II.a responses Manager Jan-xx 9-Mar-xx
Resolve defined recurrent Problem 10-
II.b incidents Manager Jan-xx 9-Mar-xx
Incident 1-Jan-
II.c Monitor incidents Manager xx 30-Jun-xx
Result: Less time to solve incidents
Measurement: Percent of incidents solved within the agreed times

3. Objective III: Improve Customer Satisfaction with Help Desk

Responsi
Action ble Start End
Increase follow-up tasks for CSI 1-Feb-
III.a the Help Desk Manager xx 7-Mar-xx
Customer
Satisfactio
Redesign surveys and how n 1-Jan-
III.b to apply them Manager xx 15-Jan-xx

III.c Monitor customer Customer 1-Jan- 30-Jun-xx

 Satisfactio
n
satisfaction Manager xx
Result: Customer satisfaction increased
Measurement: Customer satisfaction survey

4. Objective IV: Increase Accuracy of Service Provided

Responsi
Action ble Start End
Knowledg
Acquire training for all the e 17-
IV.a technical support personnel Manager Jan-xx 30-May-xx
Customer
Satisfactio
Monitor customer n 1-Jan-
IV.b satisfaction Manager xx 30-Jun-xx
Result: Customer receiving better service
Measurement: Customer satisfaction survey

5.5 Reporting and Analysis

We generate reports based on logs of interactions between the MNIG Staff and our tech
support team. Our goal is to enable strategic analyses based on the following data captured
through support reporting:
The Client’s staff member activity – identify, based on the number of submissions and/or
active interactions, which staff members are leveraging tech support the most or least

● Applications – identifying which applications generate the highest/lowest number of

submissions or cause the highest/lowest number of open, unresolved issues.
● Monitoring – combining both objective data and subjective observation by our
technical and IT staff, we will identify issues that may not be related to or limited to
specific software applications or “tech support” in the traditional sense. Broader
issues and challenges – such as staff members’ understanding of workflow or of
available tools and technologies that can yield more efficiently – can be identified by
our trend monitoring functions.
6. Conclusions
This document presents the fundamental principles that will guide the Preventative
Maintenance (hardware and software), Restorative Maintenance(Hardware and software),
Application System Maintenance and the User Support tasks within the project. The focus is
on providing users with a positive experience with the system delivered by CN, both in terms
of stability and feature evolution.

The basic principles will be expanded into practical guidelines and procedures in
collaboration with the team and in conformity to the Software Quality Assurance Plan. The
DoW defines some KPIs to measure the performance of the System Maintenance and User
Support tasks.