Turning Quality Standards To Hard Currency

IADCS Final Project
Turning
quality
standards
to hard
currency
I MPLEMENTATION OF QUALITY
SERVICE PROCESS
STANDARDS FOR AN
IT
H ELPDESK
Written by Jonathan Camilleri
NCC Education Student ID: 273040
CONTENTS
1.
2.
Business scenario .............................................................................................................................. 5

1.1
Target audience ........................................................................................................................... 5
1.2
Background information ............................................................................................................... 5
1.3
Business scenario overview ......................................................................................................... 6
1.4
Background information about the IT Division .............................................................................. 7
Analysis of business areas ................................................................................................................. 9

2.1
Overview ...................................................................................................................................... 9
2.2
IT Helpdesk ................................................................................................................................ 10
2.3
IT Change Requests .................................................................................................................. 13
Business requirements ..................................................................................................................... 15

3.1
Overview .................................................................................................................................... 15
3.2
Business objectives .................................................................................................................... 16
3.3
Approach .................................................................................................................................... 17
organisationKey issues............................................................................................................................. 17
Key issues ................................................................................................................................................ 17
4
Proposed solution ............................................................................................................................. 19

4.1
Overview .................................................................................................................................... 19
4.2
IT Helpdesk ................................................................................................................................ 19
4.2.1
Objectives ......................................................................................................................... 19
4.2.2
Process description ........................................................................................................... 19
4.2.3
Dependencies and relationships ....................................................................................... 21
4.2.4
Benefits ............................................................................................................................. 22
4.2.5
Considerations .................................................................................................................. 23
4.3
Incident Management ................................................................................................................. 24
4.3.1
Overview ........................................................................................................................... 24
4.3.2
4.3.3
4.3.4
Benefits ............................................................................................................................. 25
4.3.5
Considerations .................................................................................................................. 25
4.4
Problem Management ................................................................................................................ 25
4.4.1
Overview ........................................................................................................................... 25
Page 2 of 63
4.4.2
4.4.3
4.4.4
Benefits ............................................................................................................................. 28
4.4.5
Considerations .................................................................................................................. 28
4.5
Change Management ................................................................................................................. 29
4.5.1
Overview ........................................................................................................................... 29
4.5.2
4.5.3
4.5.4
Benefits ............................................................................................................................. 30
4.5.5
Considerations .................................................................................................................. 30
4.5.6
Release Management ....................................................................................................... 31
4.5.7
Overview ........................................................................................................................... 31
4.5.8
4.5.9
Benefits ............................................................................................................................. 32
4.5.10
4.6
Configuration Management ........................................................................................................ 32
4.6.1
4.7
Availability Management ............................................................................................................ 33
4.7.1
4.8
Overview ........................................................................................................................... 32
Overview ........................................................................................................................... 33
Financial management of IT Services ........................................................................................ 33
4.8.1
Overview ........................................................................................................................... 33
4.8.2
4.8.3
4.8.4
Benefits ............................................................................................................................. 34
4.8.5
Considerations .................................................................................................................. 34
Review ..................................................................................................................................................... 35
Review ..................................................................................................................................................... 35
Appendix A Customer Survey................................................................................................................ 36
Appendix B Proposed workflow ............................................................................................................. 38
Appendix C Escalation of service requests............................................................................................ 41
Appendix D Information required for requests ....................................................................................... 45
Appendix E Relationships between service processes .......................................................................... 48
Appendix F - Reporting............................................................................................................................. 50
Page 3 of 63
Appendix G Projections .......................................................................................................................... 56

Appendix H Hierarchical authorisation for change management ........................................................... 58
Appendix I Release management .......................................................................................................... 60
References and bibliography .................................................................................................................... 63
Page 4 of 63
1. BUSINESS SCENARIO
1.1 TARGET AUDIENCE
This document is relevant to readers familiar with the management of delivery or support of IT Services
and the terminology used within IT Service Management.
1.2 BACKGROUND INFORMATION

Ghar Lapsi Bank Limited (henceforth referred to as the bank) is registered in Malta as a limited liability
company under the Companies Act, 1995.
The Bank reported a profit before tax of Lm3.2 million for the year ended 2006, realizing a return on
average shareholders funds of 15.8%. These results were achieved by striving to meet the customers
needs by offering the appropriate products and services, whilst following a well defined business strategy.
Driven by its achievements and the present challenging market conditions, the Bank is driven by
ambitious plans for 2007. Its capital expenditure is expected to exceed Lm3 million during the current
year. The target is to implement these projects whilst maintaining the strong momentum gained over the
past years in all areas of operation.
As was recently stated by the Chairman, the Bank promotes a number of financial services and, although
relatively small, seeks to expand its operations through the setup of a financial consultancy firm, as well
as by building strong business partnerships with other European partners.
In November 2006, the Bank joined the European Federation of Ethical and Alternative Banks and
Financiers FEBEA, which is based in Brussels. The primary objective of this Association is to promote
the development of ethical and solidarity finance in the European Union through the dissemination of
information, exchange of experiences and the creation of the appropriate instruments necessary to fulfil
this scope.
The Bank reinforced its commitment towards cultural, educational, sports initiatives and social causes.
The product portfolio ranges personal and banking services which include savings and current accounts
in various currencies, loans and facilities denominated in a number of currencies, investments, foreign
currency services, inter-bank facilities, forward contracts and other services. The Bank also extends its
services to a number of corporate customers, particularly focused on providing an excellent service to
select customers. 1
Information is quoted from the annual financial reports for 2006 of a company whose actual name is not being reported, due to
confidentiality. Hence, no further reference shall be made to the actual companys name and/or its employees within the Reference
and bibliography section of this document.
Page 5 of 63
It is today widely acknowledged that technology supports business processes in an ever changing world;
business growth can only be effective when growth is enabled and supported through automation,
business process re-engineering and the supporting technologies that enable and support business
growth.
Technology is only as good as the IT infrastructure and processes that lay the grounds for the various
functions carried out by the IS/IT, including, software architecture, systems and network administration,
security management, project management, and application support.
1.3 BUSINESS SCENARIO OVERVIEW

Senior management of Ghar Lapsi Bank Limited are currently reviewing increasing trends in requests for
resources within its IT Division. Following a meeting carried out with senior management, it was
observed that the demand for services from the IT Division has sharply increased since 2006.
The IT Division has been in a position to manage increasing demands from the other divisions within the
organisation given its current financial and human resources. The IT Division has catered for this by
initially establishing a formal structure for servicing requests, which is envisaged by senior management
to have further space for improvement.
From discussions held with management, it results that there has been a rapid growth in the demand for
IT Services, and, management within the IT Division has been struggling to service these demands,
whilst, at the same time, pushing for commitment and involvement of the business customers. In the
medium-term, this should enable the IT Division to establish a holistic vision of its current processes and
potentially lead to maturity of its processes, through the increasing pro-active involvement of Quality
Assurance as an important part of the feedback loop to management.
Increasing human and technical resources is ineffective, unless the underlying management and
operational processes are efficient and manageable. Establishing processes that are transparent and
accountable to the other divisions are envisaged as the first step towards meeting requests made to the
Banks IT Division. It is recommended that a structure that demonstrates maturity of the business
processes can support resource management more effectively.
Zeus Limited2, have been called upon to investigate the feasibility for improvements on the current
service processes within the IT Division.
2
Zeus Limited is registered in Malta as a limited liability company under the Companies Act, 1995. It was founded in 2003 by Neil
Young, Managing Director and Malcolm Chow, Development Director. The company has grown to employ 30 at our head office
located at the Plaza Centre in Sliema.
Page 6 of 63
1.4 BACKGROUND INFORMATION ABOUT THE IT DIVISION

The Banks IT Division supports the other divisions in the provision and support of an IT infrastructure,
provision of the required hardware, application and system software that are required by the business
operations.
Initially the IT Department consisted of two persons, and, who catered for all the technology requirements
of the Bank, however, with time, the demand for IT Services grew as the company grew in terms of
profitability, customer base, and the range of products that it offered in order to sustain its
competitiveness within Maltas financial services industry.
In January 2006, following the resignation of a previous figure of authority who led the IT Division, a new
Head of IT was appointed, who, immediately embarked on re-structuring the IT Division into five main
operational units:
Head of IT
Business Support
Unit
IT Application
Support Unit
IT Project
Support Unit
IT Operations
Unit
IT Security and
Quality
Assurance Unit
Figure 1 - ITSD Division Organisation chart (high level)
IT Operations Unit, which is responsible for the day-to-day operations. IT Operations Unit is in
charge of all IT infrastructures, namely networks (WANs and LANs), operating systems, procurement,
installation and configuration of hardware and software, SWIFT, file server technologies, data storage
technologies, helpdesk service delivery, DBMSs, batch runs and IT operational procedures. It is also
in charge of infrastructural projects aimed at continuous improvement of the IT environment. IT
Helpdesk is administered by IT Operations, and, provides first line of support to users.
IT Application Support Unit is in charge of development of small in-house systems, and the support of
all software deployed within the organisation, including large systems delivered by the IT Projects
Unit.
IT Security and Quality Assurance Unit is in charge of the creation of policies and procedures that
ensure that IT systems are properly secured against any form of security threats, be they internal or
external, as well as the systems in use adhere to pre-set quality criteria. The Unit is also directly in
charge of the Banks web site, firewalls, spam filters, and web filtering. The Unit is also expected to
carry out IT Security and QA reviews from time to time, ensuring that Security and QA are maintained
in accordance with the relevant policies.
IT Projects Unit, implements projects of a significant magnitude. The Unit manages the dynamics
and all the resources required (hardware, software, financing, time, and human) from within the Unit,
Page 7 of 63
other IT Units, or from the user community in general, with the aim of delivering high-quality systems
within the necessary timeframes and agreed budgets.
The Business Support Unit provides a medium between the business customers and the IT Division,
and their activities include system testing, business analysis and the creation of business goals and
requirements at the outset of new projects (in liaison with IT Projects Unit), creation and configuration
of application software to support new business functionalities and application level security.
The IT Division, had, achieved independence in terms of hierarchical authority for providing services to
the other divisions, which shall be referred to as business customers, within this document. Prior to the
restructuring, only the Core Banking System had a dedicated incident tracking system, whilst other
requests were dealt with through informal communication means. Requests were made to the IT
Department via e-mails, telephone, and informal means of communication. The introduction of formal
procedures, basically ruled out the option of calling up the techies and raising an informal request, which
carries inherent management risks.
The newly appointed Head of IT realized that there was a need for formal procedures for requesting
services from the IT Division and for business customers to take on responsibility and commitment for
services required by them.
Initially, the users perceived formal procedures as unnecessary, and, this brought about further conflict
between the IT Division and the business users3. Following discussions with management, the author
was given the impression that although the Bank was not prepared for the cultural change, the
implementation of the new structure, as well as the introduction of more formal procedures for requesting
products and services from IT Services Division brought about a culture shock to both business users and
IT officials. The communication of such decisions, were only dealt with by circulating instructions, and
there were no initial workshops with the business users, neither was any training done on the changes.
The introduction of an IT Helpdesk was planned to aide users report software errors, and log requests to
the IT Helpdesk. Hence, users could report issues to IT Operations Unit, concerning hardware and
software, and, these would be assigned to IT Support officials, who would seek to resolve them. This
was done by logging issues through a web-portal, and, a helpdesk administrator would route issues to the
appropriate support officials. Unfortunately the introduction of IT Helpdesk created an implied lack of
misunderstanding as to whether users should raise ITCRs4, or whether they should log cases to IT
Helpdesk, who would ensure to raise the change requests if necessary, and, this issue was never
addressed by management.
3
Within this document business users can consist of any user within the business divisions, including users within the IT Division.
The IT Division is responsible for satisfying requests raised by business users. Business customers are members of (senior)
management raising requests such as ITCRs and IRFs who are jointly responsibility with the IT Division on the delivery of a change
requested or new project. Accountability for the delivery of these requests rests with the business customers. Business customers
can be users within the IT Division with sufficient hierarchical authority to sponsor such requests.
4
IT Change Request. Further information on the following page.
Page 8 of 63
2. ANALYSIS OF BUSINESS AREAS

2.1 OVERVIEW
The majority of information within this section was attained by interviewing management, IT Support
Officers and other employees who represent customers and business users requesting services from the
IT Division.
Following is a summary of the forms used by business customers for requesting services from the IT
Division:
Table 1 - Forms used to request services from the IT Division
Form
Purpose
Business
authorisation
required
IT authorisation required
Initial Request Form

(IRF)
Form is intended to allow

users to raise requests for
major systems systems
that because of their
complex nature take months
to implement.
The form
includes sections where the
user is expected to fill in the
business justification for the
requirement.
Head
of
Division directly
in charge of the
functionality
being
requested.
Head of IT Division
IT Change Request
(ITCR)
Form is raised when a user

is making a requirement for
a change to an IT system /
IT hardware, or a new
(small) system, or for new
hardware. The requesting
user also needs to state the
business justification for the
request.
The
request
needs to be
authorised by
the
Division
Head directly in
charge of the
functionality
being
requested.
The request also needs to

be authorised by the Head
ITSD.
Page 9 of 63
(Continued from previous page)

Form
Purpose
Business
authorisation
required
IT authorisation required
IT Helpdesk Service
Request
A Helpdesk Case is raised

whenever users are
reporting anything related to
IT that is perceived as
malfunctioning.
Any business
user
A Helpdesk Support
Officer decides whether
to accept or reject each
request. On occasion,
depending
on
the
request, a case may be
escalated
to
the
Helpdesk Administrator
or to the Manager IT
Operations for a decision
on whether to accept or
reject the case.
A problem perceived within this procedure was that every ITCR required the authorisation of senior
management. Unfortunately, there is no procedure indicating the appropriate levels of authority required
from both business and IT Division, for changes, hence, this lead to requests taking longer to be
authorised, and, eventually processed. To be on the safe side, the majority of IT Support officers seek
the highest level of authority to accept requests. In practice, he/she might not be the most appropriate
authority to authorise changes. For example, the Unit Manager is usually in a position to authorise
requests for equipment to be provided for newcomers, however, the form still requires the authorisation of
a higher figure of authority, that is, the Head of Division.
IRFs are normally handled by IT Projects Unit; since project management does not fall within the scope of
this document, in the following section we shall discuss IT Helpdesk Service Requests and IT Change
Requests, because, they are the forms commonly used for requesting services from the IT Division.
2.2 IT HELPDESK
Catering for around 200 internal business users, the IT Division has up to 20 employees, each of whom
could, possibly be involved in the daily running of IT Helpdesk.
Users can report cases through a web-interface on the Banks intranet, by telephone or via e-mail.
Cases administered and monitored by the IT Helpdesk Administrator, who decides whether the case is
acceptable, acknowledges their acceptance respectively, prioritizes the incidents and initially assigns the
case to Support Officers. It is then up to the Support Officer to monitor the resolution of the cases
assigned to them; cases are escalated when deemed necessary in liaison with the IT Helpdesk
Administrator.
Page 10 of 63
When a case has been resolved, the user is asked to confirm that the solution is satisfactory, and, the
case is closed upon confirmation from the user. Exceptions in this regard are dealt with by the IT
Helpdesk Administrator, who reports to the IT Operations Unit Manager. Figure 2, on the following two
pages, illustrates the functional procedure for service requests made through IT Helpdesk.
Page 11 of 63
Escalation path to 3rd party

support can be done by IT
Helpdesk staff with the
approval of IT Operations
Unit Manager
Escalation from
1st line of
support
Resolved by 1st
line of support?
No
No
Escalation to
Application Support
(A.S.)
(2nd line of support)
Escalation to 3rd
Party Support
(3rd line of support)
Investigation and
diagnosis
Investigation and
diagnosis
No
Resolution and
recovery
Resolved?
User is asked to confirm that

the case has been resolved.
Resolution and
recovery
IT Helpdesk
informed
Yes
No
Resolved?
Case closed
Hierarchical
Escalation
(see figure 1)
Yes
Figure 2 - IT Helpdesk workflow
Page 12 of 63
IT Helpdesk provides a comprehensive range of services to the internal customers, including:
Reporting of software errors and issues

Reporting of problems with the IT infrastructure
Information on the use of system software
Information on the use of IT equipment
Problems requiring on-site support
Status information of logged requests
Requests for statistical/management reports on incidents reported
Cases are escalated to Application Support Unit when they are identified as application errors. Cases are
escalated to Administrators when they are beyond the reasonable capabilities of Support Officers, or
upon the instructions of the Manager IT Operations.
Cases are escalated to third party service providers by Application Support Unit for all externally
developed applications when resolution is beyond the reasonable capabilities of internal Application
Support Officers or upon the instructions of the Manager IT Application Support. Other cases are
escalated to external suppliers / support providers by IT Operations Administrators when they are beyond
their reasonable capabilities or upon the instructions of the Manager IT Operations.
Application Support may escalate to the Head of IT and other Heads of Division for necessary decisions
regarding any problems on applications built in-house when there are severe business repercussions or
problems for which a solution cannot be found. For all cases escalated to external suppliers and service
providers, further escalation follows a path dependant on the internal procedures of the external supplier
or service provider in question.
It is the authors impression that on one hand functional escalation described by management is efficient
and effective; however, since, hierarchical reporting lines are rigidly respected, within the Banks culture,
the IT management has to lacks support from the business customers for which it provides services. This
is a serious management issue that hinders effective and efficient decision making.
2.3 IT CHANGE REQUESTS

ITCRs can cover a range of services, for example, software modifications, and, requesting the setup of
new hardware and software (particularly if they require procurement).
An ITCR, duly raised by a user, is authorised by the Unit Manager, and the Head of Division (up the
hierarchy). The Head of IT, who administers ITCRs estimates the change in terms of the resources
available, assigns priority and assigns the request to the IT Unit Manager(s) responsible for its
implementation. The IT Unit Manager assesses technical feasibility and the change is assigned to IT
Officers. Plans for design and implementation are usually the shared responsibility of the Unit Manager
or the IT Officer(s) accountable for that change. Dynamic and ad-hoc teams are formed to complete the
change when deemed necessary. The IT Unit Manager informs the Head of IT whether the change has
been implemented successfully, reporting issues arising and progress regularly. Figure 3 illustrates the
workflow for change requests (overview):
Page 13 of 63
New change
request raised by
user
Request is
authorized by Unit
Manager
Request is
authorized by
Head of Division
Head of IT
assessment
Technical feasibility is carried out,

requirements agreed with business user
and task is assigned to IT Officer(s)
IT Unit Manager
assessment
Progress reporting
Progress reporting
Design and
implementation of
change
No
Is change
complete?
Yes
Confirms that change has been completed and

informs Head of IT on progress.
IT Unit Manager
assessment
Figure 3 - ITCR Workflow
Page 14 of 63
IT Unit Managers report progress regularly to the Head of IT and decisions are taken on whether and how
to proceed with issues arising. It is noted that there is no formal feedback loop within the established
procedures, and this indicates that the decision making policy is not transparent down the lines of the
hierarchy. Whilst logging of requests helps IT Support staff in organising work, it also adds increased
demands due to unnecessary authorisation.
3 BUSINESS REQUIREMENTS
3.1 OVERVIEW
Following a meeting carried out with IT management, and given the above described scenario, the Zeus
advisors recommend a solution on the implementation of quality standards in order for the service
processes within the IT Division to improve in terms of quality, process efficiency and effectiveness.
The current service processes in place (service desk and incident management) are intended to be
improved in order to be internally integrated, by improving communication interfaces, formalising and
standardising processes, effectively disseminating the procedures to support staff, and, disseminating
internal marketing information about the service to the business customers effectively, in order to improve
awareness of the services provided.
Other service processes shall be considered by management in the longer term, when, it is envisaged
that the Banks IT Division shall have reached a maturity where it is envisaged by business customers as
providing an effective service.
It is being suggested that a review of the service processes shall be carried out after a period of time
defined by management, to assess the quality of the service processes and this shall enable
management to devise further plans.
Page 15 of 63
3.2 BUSINESS OBJECTIVES

The solution shall delve into practical guidelines within which the business scenario can operate. In this
regard the Zeus advisors have identified specific requirements to enable the customer to focus on
measureable objectives. These are the basis of performance metrics that are being drafted within this
document in order to guide the Banks IT Division to review the service processes:
1. Establish a single point of contact for business users and enable the IT Division to
manage internal processes more effectively. Identify a structured procedure for service desk,
whereby the service processes identified for improvement for the time being are co-ordinated
through a single point of contact, the IT Helpdesk. This shall include the definition of the scope,
dependencies and interfacing of the IT service processes being proposed.
2. Improve the effectiveness of service processes. Improve incident resolution and reporting
times, through the definition of metrics for prioritization, expected resolution time and structured
procedures and guidelines that shall guide staff involved in service delivery and support to
operate.
3. Promotion of IT Services. Disseminate internal marketing information on services available
from the IT Division to business customers in order to improve the quality of information available
about the services provided, improve the quality of customer care and improve the general
perception of the IT Division as a service provider that provides a professional service to its
customers. This shall also increase awareness on the importance of following communication
channels established by IT management.
4. Achieve cost-savings through the efficiency and effectiveness of the improved processes.
Cost-benefit in the short to the medium term following the successful implementation of the
service processes is expected to improve through the effectiveness and efficiency inherent in
implementing structured service processes5.
Service desk (IT Helpdesk in the Banks terminology), incident management and change management
have been identified for improvement, whilst problem management, configuration management and
release management, are envisaged to be introduced within the implementation of the proposed solution.
Currently there is no internal charge-back procedure for IT Services within the Bank. Whilst IT Financial
Management is not envisaged within the solution for the current scenario, within this document, business
customers should be made aware of the costs involved in servicing their requests, as well as the value
added to the business upon implementing improvements.
Improvements are perceived upon the successful implementation of ITIL service processes. Reference is made to the Norwich
Union and other case studies available which summarize the attained and perceived benefits of implementation of ITIL service
processes via a software application available from Axios Systems. This information is available as marketing information within the
public domain.
Page 16 of 63
3.3 APPROACH
Taking into consideration the business requirements set out and agreed with management, the Zeus
advisors are proposing a blueprint of the IT Division that improves its current service processes, building
upon the following guidelines:
The proposed solution is set out to have the minimum impact in terms of changes to the current
IT service processes and business processes. Within the blueprint, business users should only
be aware that as from the implementation, all requests are to be routed through IT Helpdesk.
Service desk is to continue to act as a single point of contact; it shall also act as the main point of
liaison for other IT service processes within the IT Division.
Given the size of the organisation, we are considering a phased approach, whereby the current
service processes are improved, and, other functions would only be proposed in the longer term.
By improving the underlying service processes and reporting structure, the IT Division can grow through
organisational maturity.
KEY ISSUES
The scope of this study is to outline improvements in IT service processes. Whilst we shall seek to
identify improvements to be carried out within the business scenario, other issues have been identified
within the analysis that the author is recommending for follow up by IT management.
Within the current scenario, the Zeus team understands that the role of the IT Helpdesk Administrator
indicates that more resources are required to fulfil this role. The management aspects attached to this
role are expected to increase, hence, sufficient time and resources are expected to be dedicated to
administrative tasks, such as organising the workflow for incidents and changes having a high priority,
following up on the progress of incidents and controlling the workflow on a regular basis.
IT Management are expected to consistently manage the optimum availability of resources towards
achieving the objectives set out by the Board of Directors. The implementation of the proposed changes
can be complemented by carrying out a workload analysis and utilising this information to review the
resources available within the IT Division.
The implementation of a knowledge-based service process implies that common knowledge should be
made available to IT Support staff, in order to avoid duplicate work such as research. Knowledge should
be available in a central repository, such as through reports generated from the current incident-tracking
software in place. The use of modern-day reporting tools commonly support generation of management
information from a database or a data-mart.
The introduction of quality principles might be perceived negatively by some employees, since a more
rigid and structured procedure for requests is being proposed; discipline and a willingness to relinquish
control are deemed necessary towards the success of implementing changed service processes.
There may be employees within the IT Division who may be initially reluctant to abide by these
procedures. In addition to training, employees require motivation; otherwise management could face an
Page 17 of 63
increased risk of de-motivated knowledge workers. It is being suggested that ergonomics6 are applied in
a manner that leaves employees some flexibility in their modus operandi.
Whilst internal politics do not fall within the scope of this document, it has been proven that unnecessary
bureaucracy hinders decisions and leads to an ineffective decision making process. Hence, whilst
implementing known structures, management should be aware to take a reasonable and balanced point
of view when reviewing business authorisations required, particularly business requirements having strict
time frames or linked to compliancy. It is being suggested that management should not turn a blind eye
on how these issues affect productivity, and, perceive that there is always room for improvement.
Currently the IT Division uses a number of information systems in order to keep track of requests sent.
Given the current maturity of the organisation, an integrated system is not being proposed at this stage.
In the long run, IT management can consider software applications available on the market which
implements service processes that implement best-practice approach processes such as ITIL, and,
comply with recognized quality standards for IT Service Management, such as ISO/IEC 200007.
Insufficient statistical and historic information was available in order to estimate and propose a project
plan and forecast projections in terms of time-frames, costs, and performance metrics (e.g. IT Helpdesk
and ITCR statistics). In this regard, we shall propose the blueprint asserting qualitative criteria, which
provide guidelines for review after the implementation of the proposed structure and processes. A postimplementation review can be carried out by our organisation. This is suggested to be carried out within
six months to a year from the successful go-live of the new procedures.
As discussed within the analysis, it is normal practice for employees to focus upon instructions and
information emanating from the division within which they operate. Hence is recommended that
management within the IT Division should seek to disseminate information in a manner that is appealing
and preferably has an immediate visual impact e.g. demonstrations and presentations.
Given the information available at the time of carrying out the analysis, and the scope of this document, a
workflow analysis was envisaged as the most practical way of suggesting improvements to the current
scenario. It is being recommended that this is complemented by a quantitative analysis that determines
whether the expected demands on the IT Division is being met by the technical, financial and human
resources available.
The blueprint proposes improvements to the current communication channels between IT Units, as well
as between the IT Division and business users. The IT Division shall support and promote open and
objective communication, sharing of information, and teamwork within the current work processes.
Cited from Wikipedia.org, ergonomics (or human factors) is the application of scientific information concerning humans to the
design of objects, systems and environment for human use (definition adopted by the International Ergonomics Association in
2007). Ergonomics is commonly thought of as how companies design tasks and work areas to maximize the efficiency and quality of
their employees work.
7
ISO/IEC 20000 is the first international standard for IT Service Management. It is based on and is intended to supersede the
earlier British Standard, BS 15000, as stated on wikipedia.org.
Page 18 of 63
4 PROPOSED SOLUTION
4.1 OVERVIEW
Taking the objectives into account we shall describe the structure of the IT Organisation, the
interdependencies and the expected changes in terms of benefits and weaknesses brought about by
each of the service processes.8
As indicated within appendix E, one should not assume that the service processes are directly mapped to
IT Units, since; we shall endeavour to implement service processes with minimal impact on the current
roles and responsibilities within the IT Division.
4.2 IT HELPDESK
4.2.1 OBJECTIVES
Serving as an initial point of contact, IT Helpdesk reduces the workload of the IT Division, by intercepting
irrelevant queries which are easily answered. IT Helpdesk only lets calls through to second and third line
of support where this is actually necessary. As an initial point of contact it always acts professionally
when dealing with users and ensures that they do not have to search endlessly for a solution9.
4.2.2 PROCESS DESCRIPTION

All requests to the IT Division are to be logged by IT Helpdesk. The current communication channels (i.e.
telephone, e-mail and through a web-portal), are perceived to persist within this scenario. Additional
information might be required to be updated by the IT Helpdesk Administrator (see Appendix D
Checklist for requests)
The IT Helpdesk Administrator reviews the request and updates the incident-tracking system, going
through the following procedure:
1. The IT Helpdesk Administrator seeks to clarify service requests in a manner that is clearly
understandable to IT Support Staff involved in incident management, by pre-screening the request
and identifying any obvious missing information.
2. Type of request e.g. RFI, standard change, urgent change request, IRF for a project is established.
3. Non-standard change requests and RFIs are routed to the Business Support Unit (BSU) for
assessment and acceptance.
8
Appendix B illustrates the workflow being described within the following sections; Appendix E illustrates relationships between the
various service processes. They may be viewed in conjunction with the (1.X.2) process description and (1.X.3) dependencies and
relationships sub-sections (see TOC).
2007. Cited from Foundations of IT Service Management, based on ITIL. Van Haren Publishing.
Page 19 of 63
4. Standard changes and issues acceptable are IT Helpdesk Cases are allocated priority after having
reviewed the impact on the IT Infrastructure and the business, and deduces the planned time for
resolution. Table 2 on the following page provides a guideline for this calculation.
5. The user is informed that whether case has been accepted, the case reference number (for followup), the estimated resolution time and priority allocated. The users are provided with the names and
contact details of officials responsible for assessing the request; the users are informed whether the
case is not yet accepted and/or requires further information before proceeding with the acceptance of
the case.
6. The IT Helpdesk Administrator seeks to establish whether users may be guided into resolving the
issues themselves given that the users are provided with clear guidelines. It may simply be a matter
of calling up the users involved to resolve issues. Further detail in this respect is discussed within the
incident management section.
7. Establishes whether the request, or requires further clarification or information and prepares a list of
questions prompting for specific information and the person(s) from whom information can be
attained. Information can be prompted from the business user raising the request (e.g. no screenshot
is available and this is required to view the full error message) or from the incident-tracking system
(e.g. applications and hardware involved in resolving an incident). It may be required to organize a
meeting for clarification; it may also be the case that the incident is assigned for resolution pending
the receipt of information, when it is planned that information can be useful at a later stage. For
example, a malfunctioning router may be replaced, pending information from the supplier on the
terms and conditions for the delivery of the malfunctioning router to that supplier for servicing.
8. The IT Helpdesk Administrator initially establishes whether resolution of the case requires a team to
be setup, in which case, co-ordinates with the IT Unit Managers and the IT Support Officials involved
devising a plan for the resolution of that case. Case resolution is discussed in further detail within the
incident management section.
9. Other requests are allocated to a single IT Support Official who provides initial first line of support.
The IT Helpdesk Administrator follows up on cases and standard changes when they are reported as
resolved, by asking the users to confirm whether the case can be closed.
Business users within various divisions may be identified as super-users10 who act as contacts for the IT
Division; they may also be assigned responsibility and security privileges to carry out tasks or gather
information on behalf of the IT Division.
The IT Helpdesk Administrator co-ordinates and controls the resolution whilst being kept in the loop when
unresolved cases are escalated to second and subsequent levels of support; the role is also responsible
for hierarchical escalation11 (e.g. to the IT Unit Manager) where authorisation is required or a course of
action needs to be decided. The management process is envisaged to be guided by exceptional
reporting, as indicated within Appendix F.
It may be the case that ad-hoc and dynamic teams need to be organised for the resolution of complex
top-priority cases, particularly, those involving a number of technical areas of expertise. For example the
10
End-users may be provided with the tools (e.g. 4GLs or Query Builders) or canned reports (e.g. reports, scripts or applications)
that enable them to perform tasks, or gather better information on behalf of the IT Division. This is commonly known as end-user
computing; further information is available at http://en.wikipedia.org/wiki/End-user_computing.
11
Hierarchical escalation means involving a higher level of organizational authority when it appears that the current level of
authority is insufficient to ensure that the incident will be resolved in time and/or satisfactorily.
Page 20 of 63
ATM network is down due to an unknown operating system error. Such issues shall be co-ordinated by
the IT Helpdesk Administrator, with the authorisation and support of the respective IT Unit Managers, with
regards resource management and prioritization within the overall plans of the respective IT Units. The
objective of the team would be to resolve the issue at hand and attempt to identify the root cause of the
issue, for follow-up by problem management.
Table 2 Example of priority coding system with estimated expected resolution times
Impact on IT infrastructure and business processes
Business urgency
High
Medium
Low
High
Less
hour
than
Less than 8 hours
Less than 2 hours
Medium
Less than
hours
Less than 24 hours
Less than 24 hours
Low
Less than 24
hours
Less than 24 hours
Planned resolution12
4.2.3 DEPENDENCIES AND RELATIONSHIPS

This section describes the relationships and the lines of communication of IT Helpdesk with other service
processes.
IT Helpdesk identifies requests that can be classified as changes, and confirms requests for changes
raised by the business customers, forwarding the request to the Business Systems Unit.
Requests for status reports, ad-hoc reports and alerts raised by the business customers regarding the
requests are collated by IT Helpdesk and routed through the appropriate channels as indicated in
Appendix C.
It can be the case that a workaround for an incident is implemented whilst the root cause of the problem
still has to be investigated, particularly with regards urgent cases. IT Helpdesk ensures that whilst closing
the case when the user has confirmed that an issue has been resolved, a request is raised for problem
management to investigate the root cause of an issue. It is expected that trend analyses shall enable
problem management to identify common problem areas for investigation.
Problem management are also queried on known resolved and unresolved errors, which are being
investigated.
Information might be required to initially classify requests and identify the technical areas involved in
fulfilling requests, querying the Configuration Management Database (CMDB) - maintained within the
release management and configuration management processes, or the persons responsible directly to
identify missing information.
12
Planned resolution is also applicable to other service requests that are allocated to the Business Support Unit for ITCRs
and IRFs for initial assessment. Such requests are to be communicated with IT Helpdesk acting as a call centre in identifying the
request as a change or as a request for a project and passing the relevant information to the Business Support Unit.
Page 21 of 63
Business critical and non-business critical systems are monitored and reports are regularly issued for
availability management to follow-up. The incident tracking is a useful source of information for querying
this information, and this might require clarifications to enable availability management to make plans in
this regard.
Financial management shall require information on the expected and, more importantly, actual hours of
work involved, technical and management resources involved in order to estimate costs generated in
resolving incidents. Further clarifications may be required to enable financial management to estimate
the costs involved.
IT Support staff are expected to demonstrate professional skills in customer care, being front-line staff.
The IT Helpdesk Administrator seeks to aide IT Support Officers (incident management) in liaison with
business users; when complex cases involve a number of officers assigned to a case, the IT Helpdesk
Administrator is normally expected to handle queries related to cases and requests being co-ordinated by
him/her.
4.2.4 BENEFITS
The implementation of IT Helpdesk as a single point of contact and a centralised function for coordination and management of service requests made to the IT Division is the primary catalyst for the
improvements being proposed.
Centralisation of control shall enable the IT Division to have more control over the requests being made to
the IT Division and thus, guide management to improve the quality of strategic and tactical plans.
Given that sufficient resources are allocated for IT Helpdesk Administration, call pick-up rate (particularly
for urgent requests) is expected to improve.
Turnaround13 and case resolution times are expected to improve due to improved prioritization and preestimation of priority on service requests.
Communication is expected to improve, since the IT Helpdesk Administrator(s) shall co-ordinate case
resolution being handled through the various levels of support and exceptionally organize teams (with the
authorisation of the respective IT Unit Manager(s) to resolve incidents.
Reporting on various aspects of service provision, (see Appendix F - Reporting), is expected to provide
staff at all levels with quality information to manage accordingly.
So-called super-users are located near the business users themselves, hence, they are in a better
position to collate information for the IT Division, and relieve IT Helpdesk of routine tasks that may require
a two-minute job to resolve, hence, increase efficiency as well. Cost-savings and better communication
is expected from end-user computing14.
13
Turnaround time is the time for a response on a request (e.g. explanation of issue and intended plan for resolution) to be
provided to the business user(s) originating the request.
14
End-users may be provided with the tools (e.g. 4GLs or Query Builders) or canned reports (e.g. scripts or applications) that
enable them to perform preventive, maintenance tasks, or gather better information on behalf of the IT Division. This is commonly
known as end-user computing; further information is available at http://en.wikipedia.org/wiki/End-user_computing.
Page 22 of 63
4.2.5 CONSIDERATIONS
More responsibilities are now expected from the IT Helpdesk Administrator, who is required to monitor
cases rigorously, and, at the same time co-ordinate resources for the resolution of such cases. In
exceptional cases may require the input of persons appointed to assist the IT Helpdesk Administrator to
fulfil his/her responsibilities.
Rigorous procedures for establishing priorities and pre-estimating issues may not always be deemed
feasible for urgent cases. In addition to training, self-discipline, and ability to work meticulously under
pressure are seen as necessary requirements within the skill-set of the IT Helpdesk Administrator.
The IT Helpdesk Administrator is expected to have sufficient knowledge on a number of technical areas,
to be able to route cases to the appropriate resources, as well as estimate the final priority. This also
applies for staff within the Business Support Unit.
The role of the IT Helpdesk Administrator may require more than one person at the same time,
particularly when urgent issues are being co-ordinated. This implies that effective communication is
expected between the various persons holding this role, as well as communication to the other staff
involved in the daily operation of IT Helpdesk.
Best practice in service support suggests that when any new technology or process is introduced, there is
an initial enthusiasm for the new approach. However, once installed, there is a learning curve, unfamiliar
working practices, potentially parallel running and teething troubles. The initial result of this is that far
from providing an immediately deliverable benefit, there is often a negative effect where the costs and
additional workload appear to outweigh the benefits. This drop in benefit is soon matched by a fall in
enthusiasm.
As familiarity with the technology or process begins to deliver visible benefits, enthusiasm, for the change
rises too. This is known as the silver bullet lifecycle. It is essential for IT management to stick with it
and encourage their staff to persevere and work through any drop in enthusiasm.15
15
Cited from Michiel Berkhout el al 2000. Best practice for service support. The Stationery Office.
Page 23 of 63
4.3 INCIDENT MANAGEMENT

4.3.1 OVERVIEW
Incident management reduces or eliminates the effects of actual or potential disturbances in IT services,
thus ensuring that users can back to work as soon as possible. Incidents are recorded, classified and
allocated to appropriate specialists16.

Cases and standard change requests are assigned to IT Support Officers for resolution, who are aware of
the expected resolution time and priority of the case.
Initial support is provided normally checking for similar errors within the knowledge base and querying
problem management for known errors. Classification may require review after the incident has been
investigated.
Unresolved issues are escalated in order of priority to subsequent lines of support (see Appendix C),
keeping the IT Helpdesk Administrator in the loop of the progress by updating the incident management
tracking system accordingly.
The incident management tracking system is updated with the progress on each case, including failed
and successful resolutions, general progress on the case and details on the resources used to resolve
cases, particularly the hours spent working on the case.
The IT Helpdesk Administrator is informed whether the case has been resolved within the pre-established
resolution time; unresolved cases that have been escalated through all levels of support are to be
followed up by the IT Helpdesk Administrator.
Incident management attempts to avoid hierarchical escalation17, through functional escalation of
requests, based on the final priority assigned by the IT Helpdesk Administrator.

Incident management reports on the progress of each service request to the IT Helpdesk Administrator.
The configuration management system is expected to be queried regularly for example, when validating
whether the latest software is installed on a particular machine.
Problem management is usually queried for the status of known errors and workarounds to resolve them.
IT Support Officers are expected to provide a professional service to business users, and this includes
verbal and non-verbal communication with business users. In the event of complaints on business users,
these are reported to the IT Helpdesk Administrator for follow-up.
16
Cited from Jan van Bon et al 2007. Foundations of IT Service Management, based on ITIL. Van Haren Publishing.
17
Hierarchical escalation means involving a higher level of organizational authority, when it appears that the current level of
authority is insufficient to ensure that the incident will be resolved in time and/or satisfactorily. Cited from Jan van Bon et al 2007.
Foundations of IT Service Management, based on ITIL. Van Haren Publishing.
Page 24 of 63
Incident management are expected to liaise with problem management by raising requests through IT
Helpdesk that notify issues to be investigated.
4.3.4 BENEFITS
By following the procedure incidents are resolved more efficiently, whilst unresolved issues are escalated
to subsequent lines of support; thus no incidents are lost.
By having the IT Helpdesk Administrator as front-line, IT Support staff can be more productive in resolving
incidents since this reduces interruptions (i.e. phone calls and other communication that distract support
staff from working).
The availability of incident management has the potential to provide excellent service in that specific
requests and issues are dealt with by specialists in support, who endeavour to support business users in
resolving immediate issues. This service is nowadays expected within modern-day business operations.
Dealing with routine incidents and standard changes is usually assigned to first line of support staff and
junior staff. Rotating staff within these roles and giving them the opportunity to be coached by senior staff
could help them attain more expertise and meet their objectives better, besides motivating them.
IT Support staff have to be aware that whilst it may be fulfilling to support business users, it may be
counter-productive to go beyond their duties in supporting them. Business users working in modern-day
offices are expected to be at least computer literate and be provided with self-help for everyday use of
applications. Given modern-day culture in modern days organisations, minimal conflicts in this respect
are expected and may be supported by providing user education on an ad-hoc basis.
4.4 PROBLEM MANAGEMENT

4.4.1 OVERVIEW
Incident management takes action if there is an incident, and ceases activities once service has been
restored to the affected user(s); this means that the root cause of the incident is not always resolved and
the incident may recur.
Problem management investigates the infrastructure and all available information, to identify the
underlying cause of actual and potential failures in the provision of service. These investigations are
needed because the IT infrastructure is complex and distributed and the links between incidents may not
be obvious.18
18
Page 25 of 63

Incident management is expected to resolve issues within the planned resolution times; thereafter any
issues leading to the root cause are passed on to problem management for investigation. This is the
reactive process whereby investigations are carried out as a result of incurring or recurring incidents
having similar causes.
Resources involved in problem management also carry out trend analyses by querying the incident
management tracking system and other systems used for possible sources of errors. This is the proactive process whereby problems are resolved ideally before any incidents occur.
The technical background of the issue is investigated by a team of technically oriented resources who
take their time in finding the root source of problems identified and identify possible resolutions for the
problem.
Workarounds identified during the research are made available within the incident tracking system, so
that they can be queried by IT Support Staff involved in IT Helpdesk and incident management. It may
also be possible that no workaround is available for a particular issue.
Technical feasibility is expected to be carried out by problem management, whilst estimations leading to a
cost-benefit analysis can be prepared for subsequent confirmation by the Business Support Unit;
especially when a number of possible options have been identified. Figure 4 illustrates the process being
described.
Page 26 of 63
Figure 4 - Problem management workflow (high level)
Within Appendix F a weekly report on the trend analyses of major sources of technical problems and risks
on the IT Infrastructure has been identified to be generated by this service process, at the time of writing
this document.

Requests made by problem management are routed through IT Helpdesk for accountability purposes;
feasibility is confirmed by the Business Support Unit (BSU) and appropriate authorisation is attained
through the proposed channels (see Appendix B). Close liaison between BSU and problem management
is hence expected prior to the authorisation for implementing the change.
Problem management is also expected to include plans for implementation in terms of business changes,
manual procedures to be updated and communication to the affected users. BSU is expected to support
problem management by acting as point of liaison during the design and implementation phases of the
proposed changes.
Page 27 of 63
Problem management provide workarounds to IT Helpdesk and incident management (IT Support staff at
all levels excluding third parties19); and information that might lead to identifying errors that were already
investigated by problem management.
Problem management are not expected to liaise directly with business users and business customers.
The configuration management system may be queried during the process of investigation, and may
require follow-up queries to configuration management and release management. Problem management
may also be requested to provide feedback on the availability of business-critical and non-business
critical systems to availability management.
4.4.4 BENEFITS
Duplicate investigation effort is potentially avoided since problem management is contributing to a shared
pool of known errors and information whether workaround(s) exist.
Replication of incidents across various systems is avoided, reactively or proactively, since solutions are
planned to eradicate the root cause of problems.
Human resources involved in problem management are expected to have high analytical and thinking
skills; expertise required for problem management may require teams having specialists in particular
areas of technology; these are commonly available on the market as part of consultancy services. In this
sense, bringing together resources with different business backgrounds is expected to go through the
forming-storming-norming-performing stages of team development20.
19
Third party suppliers and service providers are expected to have sufficient resources to provide solutions covered by SLAs.
20
The Forming Storming Norming Performing model of team development was first proposed by Bruce Tuckman in 1965,
who maintained that these phases are all necessary and inevitable - in order for the team to grow, to face up to challenges, to tackle
problems, to find solutions, to plan work, and to deliver results. This model has become the basis for subsequent models of team
dynamics and frequently used management theory to describe the behaviour of existing teams. Further information is available at
http://en.wikipedia.org/wiki/Forming-storming-norming-performing.
Page 28 of 63
4.5 CHANGE MANAGEMENT

4.5.1 OVERVIEW
The motto of change management is: not every change is an improvement, but every improvement is a
change. Changes cover the introduction of new services and technical capabilities, corrective measures
and other changes, some of which may be carried out as standard procedures.
Change management operates like a thermostatic control between flexibility (allowing changes which
may lead to no errors) and stability (allowing changes to remedy errors). Corrective measures reduce the
number of incident, as a result of which the pressure of work will also fall.21

The process applies for requests that are currently routed as ITCRs and IRFs within the current scenario.
Appendix H is provides further information on the classification of changes and is recommended to be
viewed in conjunction with this section. The process for change management forms part of the service
desk workflow illustrated within appendix B.
The normal procedure route for implementing changes is to start off by classifying them as minor, major
or significant, and a feasibility study22 or a preliminary estimate considering resources and technical
feasibility for minor changes, is prepared by BSU. Some changes may require the contribution of more
than one members of BSU; teams can be formed on an ad-hoc basis depending on the complexity,
impact and size (in terms of resources) of the change request.
Changes that are determined to require project management are handed over to the IT Project Unit.
Since project management does not fall within the scope of this document, it is recommended that a
separate study is carried out to investigate the integration IT Project Management with service processes,
following the post-implementation review of this project.
A forward schedule of changes (FSC) is prepared including all the required information (see appendix D)
and escalated to the appropriate level of hierarchical authority for authorisation (see appendix H for a
typical structure).
When authorisation is attained, the change is duly planned, designed, prepared (or developed),
implemented and tested. A post-implementation review is carried out major and significant changes and
circulated to all stakeholders of the change.
Standard changes are verified by the IT Helpdesk Administrator and routed the appropriate IT support
staff for implementation. Planned turnaround time13 for servicing standard changes applies for standard
change requests as with planned resolution times for incidents and other requests (see table 2).
21
22
A feasibility study is a preliminary study undertaken to determine and document a project's viability. Some changes would only
require preliminary estimates rather than a full study. Further information at http://en.wikipedia.org/wiki/Feasibility_study.
Page 29 of 63
Urgent change requests, for which priority has been pre-agreed between the BSU and the business
customer, require urgent authorisation is attained from the appropriate level of authority. This can be
done via telephone or web-conference calls for example. The change is implemented and independent
testing is carried out to ensure that the change is successful. Prior to the post-implementation review,
BSU shall ensure that management reports and records within the various information systems are up-todate. A post-implementation review (PIR) is then circulated to the authorities authorizing the change,
typically the Change Advisory Board.

Change management reports on queries made on the current changes in progress, which are routed
through the IT Helpdesk. These may arise as part of investigations carried out by incident management
or general queries by interested business users (stakeholders). Prior to replying queries BSU has to
ensure not to divulge sensitive information to unauthorised users.
Availability management is informed on the impact of changes within the IT Infrastructure by a regular
report covering the impact of changes on IT Infrastructure (see appendix F).
Financial management is provided with information on the resources in terms of human, financial and
technical resources, as originally estimated within the feasibility study and the actual costs incurred that
are reviewed during the progress of the change or during the post-implementation review. A regular
report is expected to cover financial analysis of changes.
4.5.4 BENEFITS
A structured procedure for changes reduces the adverse impact of changes on the quality of IT services.
Better estimates on costs are produced and can be compared with the actual costs of changes.
A structure for implementing changes reduces errors, improves communication and lays the grounds for
better select information provided to general business users.
Productivity is improved because personnel involved in changes are not distracted from their planned
work. Urgent change requests are implemented within a controlled framework that allows for planning,
implementation and independent testing cycles to be carried out by technical resources, whilst
authorisation and business-side issues such as economic feasibility are taken care of by other
resources.
As the process matures resources involved in change management are envisaged to gain expertise in
accommodating frequent changes without disrupting the IT environment.
Management should ensure that up-to-date authorised procedures are available for implementing
standard changes.
Although a framework for controlling requests is already in place, there may be attempts to bypass the
procedures for requesting changes, particularly for urgent requests. The integrity of this structure
demands collaboration from all levels of staff working within the IT Division. All requests are routed
through IT Helpdesk, which inherently holds a copy of all change requests made to the IT Division.
Carrying out regular audits of the procedures may help in finding loopholes and uncovering room for
improvement.
Page 30 of 63
4.5.6 RELEASE MANAGEMENT

4.5.7 OVERVIEW
Release management aims to ensure the quality of the production environment by using formal
procedures and checks when implementing new versions. Release management is concerned with
implementation, unlike change management, which is concerned with the complete change process and
focuses on risk. Releases can comprise one or more authorised changes.23

Releases are required for changes to be implemented, after the go-ahead is given by change
management to proceed with the release.
The team responsible for release management builds the release including hardware, software and
documentation within a configuration. The installation is planned and implemented.
Further information on release management is found in appendix I. A separate analysis is suggested to
be carried out for the successful implementation of this service process.
23
Page 31 of 63
4.5.9
BENEFITS
Successful implementation of release management ensures that quality hardware and software is
installed.
Different software environments are available for development, testing and production, thus reducing the
risk of an incorrect release within the production environment.
Users can be involved in testing.
Planned releases can be published in advance, for example on the Intranet.
The risk of illegal software, along with the associated risks (e.g. infected software), and, risk of having
unauthorised copies of software is reduced.
4.5.10
DEPENDENCIES AND RELATIONSHIPS
Release management works closely with change management when the go-ahead for implementation is
given.
Queries can be made by IT Helpdesk, incident management and availability management regarding
hardware, software and other configurable items (CIs) in use.24
4.6 CONFIGURATION MANAGEMENT

4.6.1 OVERVIEW
IT components and the services provided with them are known as configuration items (CIs).
Configuration items can include PC hardware, all kinds of software, active and passive network
components, central processors, documentation, procedures, services and all other IT components to be
controlled by the IT Division.
Currently there is no configuration management system in place, and this is envisaged to be implemented
as part of the proposed scenario. Since no details were provided on the current information available
within the incident tracking system, it is being recommended that a separate analysis is carried out for the
procurement or installation of a configuration management system.
Whilst this is considered important, given the lack of information available within the current scenario, a
separate analysis is suggested to be carried out.
24
Configuration items or CIs form the basis of configuration management solutions. Typically a CI is a collection of objects related
to the specific functionality of a larger system. Examples of these objects may be requirements, code, documentation, models and
other files. Cited from http://en.wikipedia.org/wiki/Configuration_item.
Page 32 of 63
4.7
AVAILABILITY MANAGEMENT
4.7.1 OVERVIEW
A few hours downtime can have a serious impact on the turnover and image of a business. This implies
that nowadays IT Service is expected to be available 24 hours a day and 7 days a week, particularly
within a Bank. Availability aims to ensure that a cost-effective and defined level of availability of the IT
service enables the business to reach its objectives.25
Given the information available to the author at the time of writing this document, it is suggested that a
separate analysis is carried out to investigate the current ways that the Bank manages this service
process, prior to suggesting improvements in this regard.
4.8
FINANCIAL MANAGEMENT OF IT SERVICES
4.8.1 OVERVIEW
Financial management serves to provide cost effective stewardship of the IT assets held and the
financial resources used in providing IT Services. Although not currently within the responsibility of the IT
Division, this is being suggested as a way of informing business users and business customers of the
costs involved in servicing their requests.

IT helpdesk and change management shall report costs incurred by servicing requests
Costs are regularly classified by business customer, for example the division and distributed to the
respective Heads of Division for review.
Other costs are not envisaged to be maintained by the IT Division, since this is being carried out as a
mainly to influence business users and business customers in the formulation of requests made to the IT
Division.
Page 33 of 63

The following information shall be collected in the form of reports in order to enable the person(s)
responsible for this function to work out the costs allocated to each business division:
IT Helpdesk
Hours of work involved per case and by support official

or third party working on the case or service request
Change management
Cost of changes and economic feasibility studies
Head of IT
Budgets allocated to the IT Division
4.8.4 BENEFITS
Other benefits brought about by independent financial management of IT Services within the scope
defined:
Increased confidence in setting and managing budgets.
Accurate cost information to support IT investment.
More efficient use of IT throughout the business.
Increased awareness and professionalism within IT
Ensuring that the business provides sufficient funds to run the IT services it requires.
Recovering IT costs in a fair manner, related to usage.
Allowing comparison with alternative service Providers.
Costs are used to influence the behaviour of business customers.
Improved forecasting of costs due to historic information available.
Budgeting, accounting and charging are often new disciplines in IT and there are limited skills available.
The lack of availability of planning information both within and outside IT could cause problems and
delays.
IT staff with accountancy skills are rare, so key activities may rely on uncommitted external resources.
Senior IT and Business Managers may resent the administrative overheads of financial processes.
The financial processes are so elaborate that the cost of a system may exceed the value of the
information.
The monitoring tools providing resource usage information are inaccurate, irrelevant or too costly.
Page 34 of 63
REVIEW
Unchanged roles and responsibilities bring about a smooth transition to the new scenario. Basically what
has changed is that all requests are routed through IT Helpdesk as far as the user is concerned.
As shown in table 6, there may be an initial confusion as to who does what, since it is being envisaged
that the service processes are integrated within the current responsibilities with minimal change. It is
suggested that the procedures are followed rigorously, particularly during the initial stages, and, that
training is provided to staff at all levels involved in the daily running of IT Helpdesk.
Information regarding the performance of its service processes, and, is strongly recommended to be
analysed that allow for the assessment of the organisations maturity, in order to define further plans for
the introduction of new service processes, and, improve current service processes by via regular qualityassurance reviews and audits.
It is expected that 14 months to 16 months are required for the implementation of the improved
processes. A post-implementation review shall be then carried out 6 to 12 months after the successful
implementation of the changed structure. Further information on expected milestones is available within
Appendix G. In the long-term organisational maturity can lead the IT Division to review its service
processes, in terms of process maturity and further plans can be devised for the introduction or
improvement of other processes. These can include the integration of quality assurance, software
development, capacity management and security management within the current framework.
Page 35 of 63
APPENDIX A CUSTOMER SURVEY26

We would appreciate if you could complete the questions below as this will help us to identify areas for
individual improvement amongst our IT Support staff and in turn enable us to improve quality of service.
Confidential
Company
logo
Date and time
Request ref.
IT Helpdesk officer dealing

with your request
Dissatisfied
Very satisfied
1. How satisfied were you on that the Support official...

a. Understood your request
b. Showed knowledge of the application / hardware reported
c.
Clearly conveyed advice/information
d. Promptly informed you of the course of action to be

taken by IT Helpdesk
e. Showed professionalism and courtesy in dealing with
your request
f.
Overall performance
26
Based on a survey suggested by Hadrian J. Sammut 1998 within Establishing a regional software support centre. Institute for
the Management of Information Systems, London.
Page 36 of 63
2. If you were dissatisfied with any of the above we would appreciate if you tell us why (below):
Least important
Most
important
3
3. How important do you feel the following factors are?

a. Access to a named support officer
b. Time for support officer to reply on progress
c.
Time for support officer to resolve the problem
d. Professional customer care
4. Which major reason would increase your overall satisfaction with our
service?
a. Reduced time for resolution of incidents
b. More accurate resolutions
c.
Answering your request quicker
d. Better communication of information or solutions provided
Name
Date
Please fax it on xxx-xxx-xxx or by e-mail on helpdesk@lapsi.com.mt after completing this survey.

Thank you for your time in completing this questionnaire.
Page 37 of 63
APPENDIX B PROPOSED WORKFLOW

New request
logged by user to
IT Helpdesk
IT Helpdesk
Administrator logs
case
Requests can be made

from business users and
users (at all levels) within
the IT Division.
Incident
tracking IS
Is this request
acceptable?
No
Yes
IT Helpdesk
acknowledgement
User informed
that case is
rejected
Customer is
informed that
case is accepted
Case, ITCR or
IRF?
ITCRs and IRFs
Cases
Business Support Unit (BSU)

Business Support
Unit Assessment
Business Support Unit ensure that the ITCRs (changes) and IRFs (for IT
Projects) are duly authorized by the business customers. Whilst the IT
Helpdesk Administrator checks for authorization, follow-up is passed on to
BSU.
IT Helpdesk
Assessment
Information requests, status reports and ad-hoc enquiries on cases, requests

for documentation and other specific information are accepted as queries
(RFIs).
2
Economic feasibility of ITCRs and IRFs raised by problem management is

confirmed and authorization for implementing the change is requested from
the appropriate level of hierarchical authority.
Faults and errors are assessed and priority is assigned.

ITCRs are initially assessed and routed to change management.
IRFs are routed to the Business Support Unit for acceptance and
assessment.
IT Helpdesk
Feedback from business customer
acknowledgement
Is this request
acceptable?
No
Yes
To be confirmed
IT Helpdesk is
informed that
request is
accepted
IT Helpdesk is
informed that
request is
accepted
Customer
informed that
ITCR or IRF is
rejected
IT Helpdesk is
informed that
request is on hold
Customer is
asked for further
information or
clarification
before reassessment
IT Helpdesk reference for ITCR/

IRF and business support official
dealing with the case
communicated to the user.
Incident
tracking IS
Customer is
informed that
ITCR or IRF is
accepted
Page 38 of 63
Urgent Change Requests

Urgency is pre-agreed by the Business Support Unit and the
business customer. Authorization required depending on
impact of change:
Minor changes to be authorized by Unit Manager
Major changes and significant changes to be authorized by
Change Advisory Board (CAB) as delegated by the Board of
Directors for urgent requests.
Is this an
urgent
change?
Urgent
authorization
No
Change
implementation
Urgent testing
Feasibility Study
Estimation of effort in terms of technical,

human, and financial resources.
Is this a
standard
change?
Initial priority, deadline agreed with business

customer, who owns the change
Agreement on business and IT contact
persons for handling the change
No
Feasibility study for change included in

forward schedule of changes
Business Support Unit ensure that

management records of the change
and documentation are up-to-date
as part of the post-implementation
review (PIR)
Review
The PIR report is circulated to the

person(s) authorizing the change.
Urgent significant changes are also
distributed to the relevant members
of the Board of Directors.
Yes
Configuration
Management
Database
(CMDB)
Classification of change
Feasibility study
Prepare report of
changes
implemented for
review
No
Is this a new
project?
Yes
No
Prepare forward
schedule of
changes (FSC)
IT Project
Management
Unit Manager
authorization
Change Advisory Board (CAB) includes

the following members:
Head of IT (CAB chairman)
Business Support Unit official(s)
responsible for the feasibility study
IT Unit Manager(s) responsible for
implementing change
Business Customer representative
Yes
Referral
required?
Yes
Is this a minor
change?
CAB authorization
Yes
Is this a major
or significant
change?
Referral
required?
Plan
Design
Implementation
Testing
Review for major

and significant
changes
Review
Yes
Planning (management) and design
(analysts) can be done in parallel for inhouse software development projects.
Board of Directors
authorization
Page 39 of 63
Page 40 of 63
APPENDIX C ESCALATION OF SERVICE REQUESTS

The following table summarizes the service requests within the proposed organisation structure, which is
intended to serve as a guideline for support staff involved in the running of IT Helpdesk. It is envisaged
that the classification list used by IT Helpdesk shall provide more detail in terms of its current CIs.
Table 3 - Escalation of service requests classification
Type of
request
Current
classification
within IT
Division
First line of
support
Second line of
support
Third line of
support
Fourth line
of support
Software
modifications
and/or
requirement for
new application
software.
ITCR
IT Helpdesk
IRFs
(logging of
request)
Business support
unit
Third party
suppliers and
service
providers28
Third party
suppliers
and service
providers28
In-house
development
and/or
procurement of
new system
and/or
application
software.
ITCR and/or
IT Helpdesk
IRFs
(logging of
request)
Requests for
status and/or
information
reports on
ITCRs.
ITCR
IT Helpdesk
(status
request)
(logging of
request)
IRFs new
requests
IRFs
IT Helpdesk
(raised by
business
customer)
(new request)
(assessment and
acceptance)
IT Projects Unit
(new request)
Business support
unit
(assessment and
acceptance)
Third party
suppliers and
service
providers28
Third party
suppliers
and service
providers28
IT Projects Unit
(logging of
request)
Business support
unit
IT Projects Unit
Third party
suppliers
and service
providers28
IT Projects Unit
Third party
suppliers
and service
providers28
(responsibility)
Business support
unit
(assessment and
acceptance)
(responsibility)
Page 41 of 63
Type of
request
Current
classification
within IT
Division
First line of
support
Second line of
support
Third line of
support
Fourth line
of support
Changes to the
IT Infrastructure
ITCR
IT Helpdesk
IT Projects Unit
IRFs
(logging of
request)
Business support
unit
Third party
suppliers
and service
providers28
(raised within IT
Division)
Problems with
the IT
Infrastructure
IT Helpdesk
case
IT Helpdesk
Requests for
status and/or
information
reports on IRFs
RFI
IT Helpdesk
Requests for
user
documentation
for software
and/or
hardware
RFI
Installation
and/or
configuration of
application
and/or system
software.
IT Helpdesk
Case
IT Operations
Unit
(normally
raised within IT
Division)
(logging of
request)
IT Helpdesk
IT Operations
Unit
ITCR
IT Helpdesk
IT Operations
Unit
(responsibility)
(assessment and
acceptance)
Third party
suppliers and
service
providers28
Business support
unit
IT Projects Unit
(responsibility)
Application
Support Unit27
Third party
suppliers and
service
providers28
Application
Support Unit27
Third party
suppliers and
service
providers28
Third party
suppliers
and service
providers28
Third party
suppliers and
service
providers28
Third party
suppliers and
service
providers28
Page 42 of 63
Type
request
of
Software errors
Current
classification
within
IT
Division
First line
support
IT Helpdesk
Case
Application
Support Unit27
ITCR
Information on
the use of IT
Equipment
IT Helpdesk
Case
of
Second line of
support
Third line of
support
Fourth line of
support
Third party
suppliers and
service
providers28
Third party
suppliers and
service
providers28
IT Operations
Unit
Requests for
on-site support
on hardware
IT Helpdesk
IT Operations
Unit
Third party
suppliers and
service
providers28
Third party
suppliers and
service
providers28
Requests for
on-site support
on software
IT Helpdesk
Application
Support Unit27
Third party
suppliers and
service
providers28
Third party
suppliers and
service
providers28
Requests for
on-site support
requiring on-site
assessment
and/or
evaluation
IT Helpdesk
IT Operations
Unit
Third party
suppliers and
service
providers28
Application
Support Unit27
Page 43 of 63
Type
request
of
Current
classification
within IT Division
First line
support
Requests for
status reports
and other
reports on
cases (service
requests
assigned to IT
Helpdesk).
IT Helpdesk
IT Operations
Unit
Information on
the use of
system software
IT Operations Unit
Information on
the use of
application
software
IT Operations Unit
Application
Support Unit27
Third party
suppliers and
service
providers28
Information on
the use of
application
software
IT Operations Unit
Application
Support Unit27
Third party
suppliers and
service
providers28
of
Second line of
support
Third line
of
support
Fourth
line
of
support
Application
Support Unit27
Third party
suppliers and
service
providers28
Application
Support Unit27
Third party
suppliers and
service
providers28
27
Application Support Unit should ensure that the proper source code, user and technical documentation is available prior to
debugging software issues. Where there is lack of complete information available to resolve the issue, these incidents are
immediately escalated to third parties, informing the respective IT Unit Manager to follow-up on providing the missing information.
28
Service Level Agreements with third parties should be confirmed prior to escalation. When requests do not fall within the
agreements, the IT Operations Unit manager is consulted to make arrangements on the resolution of these issues. Liaison with the
business users and customers regarding information requests should be in terms of business urgency with the business user prior
to escalation from first line of support.
Page 44 of 63
APPENDIX D INFORMATION REQUIRED FOR REQUESTS

Table 4 - Information required for requests made to the IT Division
Request
IT Change Request (ITCR)
Business customer
IT Division
Date of request
Status of request
Description of change required

in business terms
IT Division
authorisation
Business justification (e.g.

SWOT analysis, cost-benefit
analysis of change)
Agreed final priority
Impact of change
i.e.
major/significant,
minor, standard.
Classification of
change e.g. IT
Infrastructure,
software
modifications
Business authorisation name

and confirmation of identity
(e.g. signature)
Feasibility study
(may be optional for
minor changes; not
required for
standard changes)
Business customer
representatives who may be
contacted (optional)
Planning documents
e.g. schedule,
feasibility study
Unit Manager(s)
responsible for
monitoring the
change.
IT Officials
responsible for
design and
implementation of
the change.
Business priority
Impact on other business

processes and projects and
other dependencies
Relevant external constraints

that are relevant (e.g.
compliance deadlines,
PESTLE factors) optional.
These remain the responsibility
of the business customer.
Attachments (optional) e.g.

user-prototypes for reports
Page 45 of 63
Request
Initial Request Form (IRF)
Business customer
IT Division
Date of request
Status of request
Request description
Business justification
IT Division
authorisation
Business priority
Final priority
Business impact
Feasibility study
Business authorisation name

and confirmation of identity
(e.g. signature)
Planning documents
e.g. project plan,
Project Manager(s)
responsible for
monitoring the
change.
IT Project Officers
responsible for
design and
implementation of
the change.
Relevant external constraints

that are relevant (e.g.
compliance deadlines,
PESTLEError! Bookmark not
defined. factors) optional.
These remain the responsibility
of the business customer.
Business customer
representatives who may be
contacted (optional)
Attachments (optional) e.g.

user-prototypes of software,
screenshots, research carried
out by business customer
Page 46 of 63
Request
IT Helpdesk Case
Business customer
IT Division
Date of request
Status of request
Problem description
Final priority
Business priority
Business impact
Business user raising the

request and confirmation of
identity (e.g. signature).
Classification of
request (e.g.
hardware problem,
software error, RFI)
IT Support Officer(s)
responsible for
resolving the case.
Technical
background (minianalysis) of the
problem.
Resolutions
attempted and
tested and whether
they have been
successful.
Attachments (optional)
screenshots of screens
e.g.
Page 47 of 63
IADCS Final Project
APPENDIX E RELATIONSHIPS BETWEEN SERVICE PROCESSES

Table 5 Service process communication map
IT
Helpdesk
Change
management
Incident
management
Problem
management
Release
management
Configuration
management
Availability
Management
Financial mgmt
of IT Services
IT Helpdesk
S, Q
S,I
I, Q
Q, U
Change mgmt
R, Q
R, I
Incident mgmt
S, I
S, Q
Q, S
Problem mgmt
Release mgmt
I, S
Q, U
Configuration
management
Availability
Mgmt
Q, S
I, S. Q
Financial
mgmt of
Services
IT
29
See footnote for abbreviations.
29
R Reporting line; S Request service; I - Information and feedback Q Querying source of information; U Updating source of information; X not applicable; I
Instructions and policies
IADCS Final Project
Table 6 - Service processes to IT Units mapping

Service process
IT Units involved
IT Helpdesk
IT Operations Unit
Change management
BSU Manager
Comments
IT Operations Unit (design and

implementation)
IT Application Support (design and
implementation)
Incident management
IT Operations Unit
IT Application Support Unit
Problem management
Utilizing the current resources, this

can be handled by:
IT Operations Unit
A new IT Unit is envisaged to

be dedicated to this service
process

Release management
Configuration management
IT Operations Unit
Hardware and infrastructure

CIs
Software, CIs that include

hardware and software
components. Liaison with IT
Operations Unit normally
required for complex CIs.
IT Operations Unit
Availability management
IT Operations Unit
Financial
Services
management
of
IT
BSU
IT Operations Unit
APPENDIX F - REPORTING
The following table summarizes the reports suggested to be prepared within the proposed scenario.
Table 7 - Reporting structure
Frequency
Report
Authorised and
prepared by
Reviewed by
Daily
Incidents requiring escalation

by type of request
IT Helpdesk
Administrator
IT Operations Unit
Manager
IT Application Support
Unit Manager
Weekly
Pending incidents
IT Helpdesk
Administrator
IT Helpdesk
Administrator
Requests escalated to BSU

for acceptance
IT Helpdesk
Administrator
Business Support Unit

Manager
Availability of businesscritical systems
IT Helpdesk
Administrator
IT Operations Unit
Manager
Unit Manager
Major incident areas that
occur most often;
staff spend more time

working upon;
take the longest time to

turnaround on the
business user.
IT Helpdesk
Administrator
IT Operations Unit
Manager
Unit Manager
Page 50 of 63
Frequency
Report
Authorised and
prepared by
Reviewed by
Weekly
Incidents that require

problems to be investigated
by problem management
IT Helpdesk
Administrator
IT Operations Unit
Manager
Known errors and required

changes
BSU
Manager
Problem
management
IT Operations Unit
Manager
Unit Manager
BSU Manager
Breaches in SLAs by third

party suppliers and service
providers
IT Helpdesk
Administrator
Trends and major services

affecting the business
IT Operations Unit
Manager
IT Operations Unit
Manager
Unit Manager
Head of IT
IT Application
Support Manager
Standard changes
implemented for review
IT Helpdesk
Administrator
(on request)
Forward schedule of
changes for authorisation
IT Operations Unit
Manager
Manager
BSU
See appendix H.
Page 51 of 63
Frequency
Report
Authorised and
prepared by
Reviewed by
PESTLE factors affecting the

plans of the IT Division and
the business
IT Operations Unit
Manager
Head of IT
IT Application
Support Unit
Manager
Business Support
Unit Manager
Staff workloads
IT Operations Unit
Manager
Head of IT
IT Application
Support Manager
BSU Manager
Weekly
Request pick-up rates by

type of request, time of day
and IT Helpdesk
Administrator.
IT Helpdesk
Administrator
IT Operations Unit
Manager
Case resolution turnaround

times by type of request, IT
Support allocated to resolve
cases and complexity.
Trend analyses of major
sources of technical
problems and risks on the IT
Infrastructure
IT Helpdesk
Administrator
Unit Manager
Problem
Management
Head of IT
Page 52 of 63
Frequency
Report
Authorised and
prepared by
Reviewed by
Monthly
Availability of businesscritical systems
IT Helpdesk
Administrator
IT Operations Unit
Manager
Unit Manager
Availability of non-business
critical systems
IT Helpdesk
Administrator
IT Operations Unit
Manager
Manager
Overall performance,
achievements of business
objectives and trend
analyses
IT Operations Unit
Manager
Head of IT
IT Application
Support Unit
Manager
BSU Manager
IT Security and
Quality Assurance
Manager
Customer perceptions and

levels of satisfaction
IT Security and
Quality Assurance
Manager
Head of IT
IT
Helpdesk
Administrator
Page 53 of 63
Frequency
Report
Authorised and
prepared by
Reviewed by
Monthly
Customer training and

education needs
IT Security and
Quality Assurance
Manager
Head of IT
IT Helpdesk
Administrator
Quarterly
Support staff performance
IT Operations Unit
Manager
Head of IT
IT Application
Support Unit
Manager
Business Support
Unit Manager
Third party suppliers and
providers performance
IT Helpdesk
Administrator
IT Operations Unit
Manager
Unit Manager
Performance of applications
and technology infrastructure
IT Application
Support Unit
Manager
Head of IT
IT Operations Unit
Manager
Impact of changes on IT
Infrastructure by
classification of change (i.e.
minor, significant, major)
BSU Manager
Estimated cost of changes

vs. actual costs of changes
by classification of change
(i.e. minor, significant, and
major) and business
customer.
BSU Manager
IT Operations Unit
Manager
Manager
Head of IT
Page 54 of 63
Frequency
Report
Authorised and
prepared by
Reviewed by
Quarterly
Hardware,
software and
equipment purchased for
business users, by business
user
IT
Helpdesk
Administrator
Head of IT
Top-n
users
requesting
services from the IT Division
IT
Helpdesk
Administrator
IT
Helpdesk
Administrator
Hours taken to resolve

service
requests,
by
business
user,
service
request
classification,
business priority and final
priority.
IT
Helpdesk
Administrator
IT
Helpdesk
Administrator
Head of IT
(summary)
Page 55 of 63
APPENDIX G PROJECTIONS
Table 8 - Projected (high level) milestones for the implementation of the proposed structure
Milestone
number
Milestone
Expected
duration
Authorisation by CEO to implement

the proposed structure
15 days
Workshops to gather information from

IT Support staff
7 days
Gathering and updating of CI

information for release management
30 days
30 days
30 days
7 days
7 days
Implementation of CMDB and updating

information on CIs
Updating of detailed procedures for
service processes
Procedures authorised by IT Unit
Managers and Head of IT Division
Changes in roles and responsibilities
authorised by Human Resources
4
5
6
7
Predecessors
(milestone
numbers)
Integration of processes within the

incident tracking system
90 days
Implementation of a new configuration

management system 30
180 days
Training to all IT staff at all levels
15 days31
7, 8, 9
11
Authorisation by Head of IT to start

working within proposed structure
7 days
6,7,8,9,10
12
Information on changed procedures

published on Intranet
1 day
11
10
(Continued on following page...)
30
31
Tasks 8 and 9 are envisaged as a new smaller-scale project.

Training provided 15 days prior to implementation of the new procedures.
Page 56 of 63
(...Continued from previous page)
Milestone
number
13
14
Milestone
Presentations to business users on the

changes involved (internal marketing)
Post-implementation review
Expected
duration
Predecessors
(milestone
numbers)
3 days
11
6 to 12 months
after successful
implementation
11
Page 57 of 63
APPENDIX H HIERARCHICAL AUTHORISATION FOR CHANGE

MANAGEMENT
The following table suggests hierarchical authorisation required for change management, which has been
included for explanatory purposes only, taking into consideration business knowledge attained during the
research carried out prior to the analysis.
Examples of hierarchical authorisation are included within this section because hierarchical authorisation
is not within the scope of the proposal.
Table 9 Recommended authorisations for change management
Change classification
Description
Expected
required
Minor change
Change requires little

work with minor risk of it
causing
significant
service problems32.
IT
Application
Manager OR
Change
will
require
significant efforts which
will have a substantial
impact on the services32.
Change Advisory Board

(CAB) consisting of:
Significant change
32
authorisation
Support
IT Operations Unit Manager
Head
of
(Chairman)
Business Support
Unit responsible for
the feasibility study
IT Unit Manager(s)
responsible
for
planning
the
implementation of
the change
Business Customer
or
delegated
representative with
sufficient authority
to take decisions.
Representatives of
third
parties
to
which the change is
being
outsourced
with authority to
decide.
IT
Example
Installation of a
software upgrade
to the Intranet.
Installation of a
software upgrade
on
the
Core
Banking System.
Page 58 of 63
Change classification
Description
Expected
required
authorisation
Major change
Change could impact a

major
part
of
the
Board of Directors
33
Example
Discontinuation of
ATM services
32
organisation .
Standard changes do not require prior authorisation; these are implemented and a list of changes
implemented can be retrieved by IT Unit Managers as a report (see appendix F).
Urgent changes for which there is a limited timeframe for implementation and a high priority allocated may
be required from time to time. For example, security patches need to be applied overnight on the ATM
network. In this case the urgency is pre-agreed between the business customer34 raising the request and
BSU.
33
Although rare, it may be the case that available members from the CAB may be delegated responsibility to authorize major
changes; these shall subsequently report to the board of directors following the post-implementation review of the change.
34
Business customers are members of (senior) management raising requests such as ITCRs and IRFs who are jointly
responsibility with the IT Division on the delivery of a change requested or new project. Accountability for the delivery of these
requests rests with the business customers. Business customers can be users within the IT Division with sufficient hierarchical
authority to sponsor such requests.
Page 59 of 63
APPENDIX I RELEASE MANAGEMENT

The following tables35 illustrate the classification of releases; they can be used as a guideline for the
analysis of the implementation of this service process.
Table 10 - Release classification by impact

Type of release
Definition
Major releases
Major rollouts of new hardware and software, generally with significantly

increase functionality. These releases often eliminate a number of known
errors, including workarounds and temporary fixes.
Minor software releases

and hardware upgrades
Generally include a number of minor improvements, and fixes of known

errors. Some may have been implemented as emergency fixes earlier but
they are now comprehensively dealt with in the release. Such a release also
ensures that the previously trusted state (i.e. the starting point of all tests), is
updated.
Emergency fixes
These are normally implemented as a temporary fix for a problem or known

error.
As several releases may be available, they are given unique identifiers. The release identification should
refer to the relevant CI and include a version number of two or more digits, for example:
Major releases
Internet Banking v1.1, Internet Banking v1.2 etc.
Minor releases
Banking v1.1.1, Internet Banking v1.1.2 etc.
Emergency fix
releases
Internet banking v1.1.1, Internet banking v1.1.2 etc.
Table 11 - Release environments

Environment
Description
Development environment
The development of a new version can be based on an earlier

version from the Definitive Software Library.
35
This section is cited from Jan van Bon et al 2007. Foundations of IT Service Management, based on ITIL. Van Haren
Publishing.
Page 60 of 63
Environment
Description
Test environment
The environment for testing that includes version control36. It is

common to have development environments for developers and
other test areas for users and super-users, implementation test areas
for testing installations prior to release and other test areas for useracceptance testing (UAT).
Production environment
The live environment where information systems are made available

to users.
Archive
Holds older versions of software items that are no longer used but
may be reapplied to production should a back-out be necessary.
Table 12 Sources of information

Release management relies on three important sources of information:
Source of information
Description
Definitive Software Library (DSL)
A secure repository that holds authorised versions of all software

configurable items (CIs)37. The DSL may be physically in many
locations and comprise of a number of secure media vaults and
fireproof safes. Release management covers the life cycle of
software from the time it is incorporated in the DSL. Releases are
configured with the known good software secured in the DSL.
Installation scripts are then developed and copies can be made at the
various locations where software is required. The DSL may include
several versions of the same software, including archived versions,
documentation and source code. Hence the DSL should be backed
up regularly as it not only contains the current version, but also the
back-out versions. If there are several sites with local management,
then each site will have a copy of the DSL for rolling out software.
Definitive Hardware Store (DHS)
DHS contains spares and stocks of hardware. These are spare

components and assemblies that are maintained at the same level as
their counterparts in the live environment. The hardware in the DHS
is used to replace or repair similar configurations in the IT
infrastructure. Details of the composition of these configurations
should be included in the CMDB.
36
Revision control (also known as version control, source control or (source) code management (SCM)) is the management of
multiple revisions of the same unit of information. Cited from http://en.wikipedia.org/wiki/Version_control.
37
Configuration items or CIs form the basis of configuration management solutions. Typically a CI is a collection of objects related
to the specific functionality of a larger system. Examples of these objects may be requirements, code, documentation, models and
other files. Cited from http://en.wikipedia.org/wiki/Configuration_item.
Page 61 of 63
Source of information
Description
Configuration
Management
Database (CMDB)
During all release management activities it is advisable to check

information about CIs in the CMDB. As software versions are
incorporated in the DSL and hardware versions are incorporated in
the DHS, the CMDB details are also updated. To support release
management CMDB should contain details about:
Contents of planned releases, including hardware and

software CIs with reference to the original change request
Hardware and software CIs which may be impacted by a

release
Details of the physical location of hardware covered by the

release
Page 62 of 63
REFERENCES AND BIBLIOGRAPHY

1. Jan van Bon et al 2007. Foundations of IT Service Management, based on ITIL. Van Haren
Publishing.
2. Vernon Lloyd et al 2002.
Published 2002 by TSO.
Best Practice for Planning to Implement Service Management.
3. Axios Systems. Norwich Union and Axios partner to deliver effective IT Asset Management. [last
accessed 04/08/2007]. Available from http://www.axiosssytems.com.
4. Wikipedia, the free online encyclopaedia. [last accessed on 05/08/2007].
http://en.wikipedia.org.
Available from
5. Hadrian J. Sammut 1998. Establishing A Regional Software Support Centre.

Management of Information Systems, London.
Institute for the
6. Michiel Berkhout el al 2000. Best practice for service support. The Stationery Office
Page 63 of 63

Turning Quality Standards To Hard Currency

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Turning Quality Standards To Hard Currency

Загружено:

Авторское право:

Доступные форматы

IADCS Final Project

Written by Jonathan Camilleri

NCC Education Student ID: 273040

Business scenario .............................................................................................................................. 5

Target audience ........................................................................................................................... 5

Background information ............................................................................................................... 5

Business scenario overview ......................................................................................................... 6

Background information about the IT Division .............................................................................. 7

Analysis of business areas ................................................................................................................. 9

IT Change Requests .................................................................................................................. 13

Business requirements ..................................................................................................................... 15

Business objectives .................................................................................................................... 16

Proposed solution ............................................................................................................................. 19

Process description ........................................................................................................... 19

Dependencies and relationships ....................................................................................... 21

Incident Management ................................................................................................................. 24

Process description ........................................................................................................... 24

Dependencies and relationships ....................................................................................... 24

Problem Management ................................................................................................................ 25

Process description ........................................................................................................... 26

Dependencies and relationships ....................................................................................... 27

Change Management ................................................................................................................. 29

Process description ........................................................................................................... 29

Dependencies and relationships ....................................................................................... 30

Release Management ....................................................................................................... 31

Process description ........................................................................................................... 31

Dependencies and relationships ....................................................................................... 32

Configuration Management ........................................................................................................ 32

Availability Management ............................................................................................................ 33

Financial management of IT Services ........................................................................................ 33

Process description ........................................................................................................... 33

Dependencies and relationships ....................................................................................... 34

Appendix G Projections .......................................................................................................................... 56

1.2 BACKGROUND INFORMATION

1.3 BUSINESS SCENARIO OVERVIEW

1.4 BACKGROUND INFORMATION ABOUT THE IT DIVISION

Figure 1 - ITSD Division Organisation chart (high level)

IT Change Request. Further information on the following page.

2. ANALYSIS OF BUSINESS AREAS

Initial Request Form

Form is intended to allow

Form is raised when a user

The request also needs to

(Continued from previous page)

A Helpdesk Case is raised

Escalation path to 3rd party

User is asked to confirm that

Figure 2 - IT Helpdesk workflow

IT Helpdesk provides a comprehensive range of services to the internal customers, including:

Reporting of software errors and issues

Requests for statistical/management reports on incidents reported

2.3 IT CHANGE REQUESTS

Technical feasibility is carried out,

Confirms that change has been completed and

Figure 3 - ITCR Workflow

3.2 BUSINESS OBJECTIVES

4.2.2 PROCESS DESCRIPTION

Less than 8 hours

Less than 2 hours

Less than 24 hours

Less than 24 hours

Less than 24 hours

4.2.3 DEPENDENCIES AND RELATIONSHIPS