Q2.
SLA
This Service Level Agreement (SLA) is an
agreement made between Computacenter and Tradeteam, referred to as the client to
cover the provisions provided by Computacenter. The purpose of
this agreement is to ensure the reliability and stability of all services
covered under this SLA.
Period of agreement
This agreement will be effective from DD/MM/YY
and prepared to be valid for 12 months thereafter or until the agreement is
renegotiated following the acceptance by both parties.
Review procedure
This SLA will be reviewed for any modification
or change at any time by the request of either party in accordance with the
change management process and any changes will be agreed and made
appropriately.
Service description
The aim of this SLA is to provide a basis for
close co-operation between Computacenter
and Tradeteam, for the support
services, thereby ensuring a timely
and efficient support service is available to Tradeteam end users.
Tradeteam
IT service current goals include:
•
develop and maintaining the service catalogue;
•
develop and maintain the policies and procedures document;
•
exploit performance reports for problem management;
•
identify and implement the best integrated service management tool;
•
keep nurturing the service culture;
• keep focus on supporting the business and
its projects.
The
intended benefits for the Tradeteam
are as follows:
· Increased visibility of costs incurred through
IT suppliers
· Clear relationships between Tradeteam and its IT service provider
The service will be provided by a technically
qualified Computacenter engineers. An
incident needs to be normally resolved and closed on the first visit. Computacenter shall provide a set of
core IT services which are secure, up-to-date, and easy to use and meet the
actual and perceived needs of users.
Scope
of the agreement
Services covered by this agreement include:
·
tradeteam’s
operational services
·
Support
Desk operations
·
Application
and software support services
·
Maintenance
of server systems
Service hours
Ensure Computacenter
operates in a consolidated manner that the service desk and on call support for
critical incidents are functional 99% of the time in a 24x7x365 environment.
The Maintenance Service need to be available
between 09.00 and 17.30 Monday to Friday, excluding Public and Bank Holidays,
unless specified.
Service availability
This SLA is another step in the effort to
achieve that objective. It is Computacenter
intension to continuously apply tradeteam’s
quality standards to improve the client service in all areas whenever possible.
Computacenter should guarantee to be
available at all times. This 100% guarantee covers the availability of all
services including the service desk and, call support, software services,
maintenance and support of the AS/400s and data backup incidents.
Reliability
Actual levels of service are to be compared
with agreed target levels on a regular basis by both Tradeteam and Computacenter. In the event of a discrepancy between actual
and targeted service levels will lead to unreliable conditions of the
operations. Tradeteam and Computacenter are expected to identify
and resolve the reasons for any discrepancies in close co-operation.
Service
performance
Tradeteam
and Computacenter have a clearly
defined and mutually agreed level of service to be provided. This will provide
a strong basis for a better working relationship between the two parties. The
SLA program is designed to increase transparency and accountability.
Service performance, service level targets,
actual results and outcomes will be evaluated periodically through a monitoring
procedure including annual user satisfaction survey, internal reviews and
feedbacks and annual progress reports. The results will be processed and
analysed in order to improve the services supply.
The following Key Performances Indicators
(KPIs) will report annual service performance.
• Service availability (up-time) of key services
• Level of user satisfaction with IT services
identified by users (from annual survey)
• Internal reviews of each departments in relation to the service
performance
• Feedback from comment and feedback forms will
be monitored
Security
The Computacenter
manages the security of the database system and associated components. All
necessary precautions should have been taken to ensure access to the technical
infrastructure, both physical and through networks, are restricted to
authorized personnel only and that the system is protected from unauthorized
users, systems, agents and viruses.
In
an event of a breach of security Computacenter
should take immediate steps to protect the integrity of the systems and the
security of the data.
Contact
points and escalation
When service falls below the agreed level
targets identified under the section of ‘service scope’ and delivery of
unsatisfactory service will cause complaints by third party users and also
internal departments. In such situations joint meeting between the parties will
be used to discuss and resolve problems that resulted. The Company will use all
reasonable endeavours to ensure a satisfactory service, in the event the
services remain outstanding beyond the agreed levels. The escalation path for
related incidents or services are not resolved would be to the IT Service
Delivery Manager or IT Service Delivery team.
If the incident or problem proves to be within
the associated services, the user is responsible for contacting the appropriate
local parties to update all affected users on the investigation and resolution.
Responsibilities
The Computacenter
should provide high quality and reliable IT services which are cost-effective,
based on best practice and meet the requirements of the Tradeteam. Furthermore it is the responsibility of the Computacenter to ensure all necessary
precautions are taken to protect Tradeteam’s
information.
Appropriate meetings need to be arranged
between Tradeteam and Computacenter as necessary.
Tradeteam
will provide 1st level support to Computacenter;
such support covers any incidents with regard to the agreement.
OLA-1
This is an Operational Level Agreement between
Service Desk and the Network Support team
(2nd Line) for the provisioning of IT services required to support and sustain.
This shall remain valid for 12 months and will be reviewed annually.
The purpose
of this OLA is to ensure that correct procedures are in place to enable
supporting the service as agreed. This OLA:
·
Serves
as a reference document
·
Defines
roles and responsibilities
Support service description
The purpose of this is to ensure that the
proper elements and commitments are in place to provide consistent service in
network section.
Scope of the agreement
·
System
operations, administration and network connections
·
IT
desktop and custom services
·
Systems
Operations,
Service hours
The target availability of the service is 95
%.
Service targets
Supports the
day-to-day operations through maintenance in the areas necessary
OLA-2
This is an OLA between Service Desk and Server
Management team for the provisioning of IT services required to support and sustain.
Support service description
These services are necessary elements of the
service to function the whole operations of the company.
Scope of the agreement
·
Desktop
Support, Infrastructure
·
Server
support, and custom services
·
Application
Support, and Consulting and Procurement Services
Service hours
The target availability of the service is 95
%.
Service targets
Q3.
Change Management Process
Workflow
The broader Change
Management process shall be organized as shown in the Figure 1. Change Management Process
Workflow.
Figure 1: Change Management Process Workflow.
Composition of CAB and eCAB:
Clear definition of
the roles and the responsibilities will be highly important for the proper implementation
of the Change Management process and the pre-planned Change Models. The CAB and
eCAB will be composed of number of different members having different roles and
responsibilities such as listed below:
1. Change Administrator:
·
Supports the change manger
·
Maintains the records
·
Prepares the reports
2. Change analyst
·
Provides recommendations
·
Provides technical knowledge
·
Impact assessment
3. Change Authority
·
Authorizes the change
4. Change Manager
·
Oversees the overall Change Management process
·
Coordinates day-to-day execution of the process
·
Schedules change implementation
·
Accepts and classify the RFCs
·
Chairs the CAB and ECAB meetings
5. Requestor
·
Submits the RFCs
·
Provides the required information for the change
Operations:
The requestor collects
all the information about the change and prepares the Request for Change (RFC).
Then it is submitted to the Change Manager. Change Manager Reviews the RFC and
determine it whether to be a valid one or an invalid one. If the change
required is valid, then the change manger needs to determine whether the
required change is a normal change, a standard change or an urgent change. Then
the change implementer has to implement the change, while the change owner can
monitor the implementation. As the implementation goes on the owner of the
change can realize whether the changes has met its objectives by reviewing the
change. If so, the change owner can close the record and notify the requestor that
the change is closed.
Evaluation process can
be carried out by the external process manager where the impact, risks, cost
benefit analysis of the change will be made and an assessment will be delivered
as an output. This assessment results can be reviewed by the change owner which
can make change manager to schedule a CAB meeting or an eCABmeeting as per
necessary. Then change manager will have to do the necessary evaluations and
present the necessary documentation including the project charter, schedules
and other information relevant. Then the change authority will authorize the
change where the change manager will have to be involved in the negotiation
process in order to plan the implementation of the change.
Change Models
Three main types of requests
for change can be found: Standard, Normal and Urgent.
In this Change
Management procedure, three different change models have been presented: one
for the normal and urgent requests and the other for the standard requests.
Change Model for Normal and Urgent Change Requests
Normal change request
is followed by all the usual activities found in Change Management. However,
they include a separate procedure for handling authorization. When a normal
Change request is submitted, the RFC is subjected to a thorough assessment and
a Change Advisory Board (CAB) meeting is convened to discuss about the change
before being submitted for authorization.
Even though the Urgent
change request is similar to the normal change request, the activities involved
in the process must be executed much faster than that of a normal procedure due
to the urgency concerns. When an urgent RFC is submitted, a smaller Emergency
Change Advisory Board (ECAB) with immediate availability is to be convened.
Typically the procedures like change assessment may be allowed to include fewer
tasks than that of the normal procedure. Nevertheless, using a single Change
Model will be adequate.
Figure 2. Change Model for Normal and Urgent Change Request.
Change Model for Standard Change Request
As per ITIL definition
a standard change is a change which is pre-authorized by the Change Managementschedule.
Basically the Standard changes are with low risk, less time consuming and less expensive.
Some standard changes may do not need RFCs.
Figure 3. Change Model for Standard Change Request.
Key Performance Indicators for the Change Management process
Balanced Scorecard
This is a management tool developed by Robert
Kaplan and David Norton. This tool enables a Strategy to be broken down into
Key Performance Indicators. KPIs are important to benchmark the performance of
the company after the change is implemented, in order to evaluate and
demonstrate how well the Strategy is being achieved. A Balanced Scorecard has
four key areas under which different KPIs have been defined. These can be used
in evaluating the value being added or the extent of the success being met
through the change.
Financial perspective
Table 3.1: KPIs in the financial perspective
Information Technology (IT) expense as % of
total administrative expense
|
|
Average IT cost per customer
|
|
Cost of IT as % of company revenue
|
|
Average cost of IT per PC
|
|
Cost of IT as % of company revenue
|
Customer perspective
·
Repeat
orders
·
Number
of customer complaints
·
Returned
orders
·
On
time deliveries
·
Customer
satisfaction index
Internal business perspective
·
Increase
in capacity utilization (litres transported per one shift)
·
percentage
defective products returned
·
reduced
waste
·
efficiency
improvements
·
reduction
in unit cost (cost per one mileage)
Learning and Growth perspective
·
Extent
of employee empowerment
·
Number
of new distribution channels adopted
·
Number
of new information systems introduced
·
Percentage
of new sales achieved through new distribution channels
·
Number
of new customers
Q4. Concise
At
the end of the tutorial and specifically upon the completion of the individual
and group tasks the following unit
learning outcomes could be achieved:
Group Task:
·
Team
work experience
·
Analytical
skill development achieved through the analysis of the case study
·
Application
of ITSM theories into real world scenarios
Individual Task:
·
Knowledge
and the skills in devising Service Level agreements and the Operational level
agreements.
·
Skills
in developing a change management procedure
·
Identifying
the roles and responsibilities of the Change Advisory Board and the Emergency
Advisory Board.
·
Identifying
the key performance Indicators relevant to the change manage process
General Learning Outcomes:
Role
of the technology played within the organisation is growing very fast.
Therefore the technology adopted by an organisation has to be competitive
enough to meet the expected performance and service levels by the customers. In
catering this requirement the It departments will to demonstrate their
capability in catering the organisation with a high end value.
However in most of the cases it is
more likely than not that it will not be cost effective for an organisation to
allow funding resources and skills to meet these requirements to build a
competent IT department in house. Therefore, the It solution is most likely
will be in the form of out-sourcing. Referring to the case we used in this
tutorial exercise, the trusted IT service partner chosen by tradeteam was
Computacenter.
The appendices attached herewith this
assignment reflects the provision of guidance by the course which made this
work towards a success.
References
AXEL
KOLTHOF, Mike Pieper, Ruby Tjassing. 2008. ITIL V3 Foundation Exam: The
Study Guide. Van Haren Publishing.
Computacenter
delivers for Tradeteam. 2013. [online]. [Accessed
17 Mar 2013]. Available from World Wide Web: <http://www.computerweekly.com/feature/Computacenter-delivers-for-Tradeteam>
FAST ITIL TEMPLATES. 2012. [online].
[Accessed 17 Mar 2013]. Available from World Wide Web: <http://www.fastitiltemplates.com/service-transition/change-model.html>
ITIL – Example
emergency change management. [online]. [Accessed 17
Mar 2013]. Available from World Wide Web: <http://www.ucisa.ac.uk/~/media/Files/members/activities/ITIL/servicetransition/chanage_management/ITIL_an%20example%20emergency%20CM%20procedure%20pdf>
Office of Government Commerce, 2007. Service Operation
Book (Itil). 1st ed. The Stationery Office.
McBride,
N. (2009). Exploring Service Issues within the IT organisation: Four mini
case studies. International Journal of Information Management, 29, 237-243.
Appendix 01- ITOSM Tutorial 1
Case study analysis
Analyse the scenarios
provided to complete the following table, clarifying points with the lecturer
as necessary.
Company name
|
|
Identify the type of
IT service provision (internal, outsourced, hybrid).
|
|
Give the number of
users, sites, devices, applications, incidents, projects, IT staff.
|
|
List all IT product
and service suppliers and other relevant contractual relationships.
|
|
Identify any
standards or best practice guidance in use for project management, ITSM, EA,
interoperability or quality management. Describe the level of maturity of
adoption.
|
|
List known business priorities
for short, medium and long term.
|
|
List key
stakeholders for IT services.
|
|
Describe the IT
management and governance structures. (Draw a diagram on the reverse.)
|
|
State the capital
and revenue budgets for IT services and projects.
|
|
List the IT services
provided.
|
|
Describe any legal,
regulatory or other external constraints on IT service provision.
|
|
Assess the strengths
of the IT service provision as described.
|
|
Assess the
weaknesses of the IT service provision as described.
|
Appendix 02- ITOSM Tutorial 2
Case study analysis
Analyse the scenario provided to complete the
following table, clarifying points with the lecturer as necessary.
Identify the type of
IT service provision (internal, outsourced, hybrid).
|
|
Give the number of
users, sites, devices, applications, incidents, projects, IT staff and any
known budget parameters.
|
|
List known business
priorities for short, medium and long term.
|
|
List key
stakeholders for IT services.
|
|
Describe any legal,
regulatory or other external constraints on IT service provision.
|
|
State the business
aims that led to ITIL adoption
|
|
State the anti-ITSM
views that limited ITIL adoption
|
|
Assess the strengths
and weaknesses of the IT service provision as described.
|
|
Appendix 03- ITOSM RADM Tutorial
Appendix 04- ITOSM SLA-OLA
Tutorial
SLA/OLA Development
Work
with your coursework group to analyse the scenario provided, clarifying points
with the lecturer as necessary.
Scenario
A
pharmaceutical company plans to implement a new IT service to allow its R&D
facilities in Europe, North America and Japan to share data on drug development
progress. The company has selected its product vendor and is now selecting an
IT service provider to host and deliver the vendor’s off-the-shelf system. You
are developing the SLA for your company’s bid to host the service. The main
components of the new service will comprise:
1. A web site for data entry and routine analysis
that is accessible from standard browsers or Android devices;
2. A data import utility that allows output files
from local R&D databases to be transformed and loaded;
3. An analysis suite that allows production of
complex queries and statistical analysis;
4. A service desk to resolve basic incidents and
requests (password resets, diagnosing simple connectivity faults, creating and
disabling user accounts) and refer more complex incidents to second line
support;
5. A second line support team to advise on
complex analysis queries and deal with incidents the service desk cannot
resolve;
6. A third line support service from the product
vendor for incidents the second line support team cannot resolve;
7. A service continuity plan comprising dual
servers with resilient failover, daily full backups, hourly backups of
transaction logs, weekly recovery testing and 4-hour recovery target in the
event of total service failure;
8. The hardware and software for the website and
database platform, hosted by the IT service provider;
9. User training for existing and new company
staff and technical training for internal support teams.
What can you answer for the following
headings? Where do you need further information and who would supply it?
SLA
o
Scope,
detailed service description
o
Service
hours and availability targets
o
Responsibilities
of each party
o
Performance
targets
o
Service
continuity plans
o
Security
aspects
o
User
support and escalation routes
o
Change
management methods and targets
o
Service
report and review methods and targets
OLAs
What
internal OLAs do you need? Which team(s)? What further detail do you need to draft
the OLAs?
Appendix 05- Case Study
0 Comments