Milestone 7 - 10

Class & Module IT Systems Capstone Project

Milestone 7 - 10: IT Service Management
Name Ananda Aditya Surya

You are the business owner of XXX company, one of the leading wholesale distributor of fasteners
business with one office and sales outlet in Singapore. Internally you do not have IT Support staff and
you wish to outsource service desk support for 50 staff with 30 PC/notebook, 2 printers, Internet
connection and file sharing for your two offices.

Milestone 7: Determine SLA Contract areas to consider

A service level agreement (SLA) is a contract between a service provider (either internal or external)
and the end user that defines the level of service expected from the service provider.
The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities
of the IT Service Provider and the Customer.
Draft out a Service Level Agreement template for outsourcing your Service Desk for Milestone 1 and
Milestone 2
with the following tasks
Task 1: Ability to Meet Service Targets
two types of Service Level Targets (SLTs) in HPE Service Manager. They are process targets
(response) and service targets (availability) . You can add targets in two ways. You can select an
existing SLT Catalog template with a pre-defined target, or you can define a customized target that
meets the requirements of the individual Service Level Agreement (SLA). When you create a new
SLA, you can access the SLT catalog and select one or more existing template targets that support the
SLA. If the existing SLT templates do not meet your requirements, then you can create a customized
SLT. A service level target is a key element of a service level agreement between you as a service
provider and an end user customer. Service level targets measure your performance as a service
provider and are designed to avoid disputes between the two parties based on misunderstanding.
Service level targets are linked to service level packages, service level agreements, underpinning
contracts, and request offerings. For example, you can have general targets linked to a service level
package (such as a promise to respond to an email within 24 hours), but have specific targets linked to
a request offering (such as a promise to send a new phone within 5 days).
Task 2: Control of Customer Expectations

1. Openly discuss solutions

Businesses that have highly knowledgeable customer support teams should be well-versed in
the solutions to every potential problem and be able to speak to those possibilities quickly.
One important way businesses can manage customer service expectations is by openly
discussing possible solutions to a problem with the client. By listing off possible resolutions,
support teams empower their clients to understand the complexity of a particular problem and
engage directly with its solution. Additionally, by painting a clear picture of possible
results, service teams ensure customers don't have unrealistic expectations of how simple or
difficult the resolution will be.

With the right strategy in place, businesses can exceed customer service expectations.

2. Provide clear timelines

Glitches, errors, and bugs in B2B software can be irritating and costly to customers.
However, clients will become more angry if they look forward to their problem being solved
in a week, and instead wait a week and a half. Businesses can manage customer service
expectations by clearly stating how long any particular task will take from the moment the
client gets on a customer support call until the resolution is in progress. Teams should ensure
customers are well-informed of not only how long a phone call will take, but how much time
and work is required to get them a solution as quickly as possible.

3. Be transparent and honest

Transparency is absolutely crucial to managing B2B customer service expectations
effectively and will affect clients' ability to trust a company. Businesses can ensure clients
remain confident in their providers and have a positive experience by remaining honest in
every possible situation. This means if a customer service representative doesn't have the
right answer to a problem, he or she should be open about consulting with other members of
the team. Regardless of the situation, support teams should avoid keeping secrets at all costs.

4. Remain optimistic, but realistic

While optimism is an important part of a positive customer experience, representatives must
also remain realistic about solutions. By understanding company policies, the complexities of
certain problems and the workload of their team members, support experts can gauge how a
particular ticket will be solved and the time investment that is required. While it can be
nerve-wracking to tell a client a problem will take longer than expected to resolve, it is more
important to be realistic than set expectations that can't be met.

Project Report Install and Configure Operating System Page | 2

Managing expectations is the first step to a positive customer experience.

5. Follow up regularly
Finally, support teams can manage customer service expectations by following up after each
stage of the resolution process. As Customer Experience Insight pointed out, most customers
are not bothered by companies touching base with them. On the contrary, clients expect
businesses to follow up with them to round out their customer experience. After a customer
service agent communicates the potential solutions to a problem and offers realistic timelines,
he or she should follow up with the client through email to reiterate what was decided.
Additionally, customer support teams should always check in with clients as the resolution
progresses, and once a ticket has been closed.

There are many ways businesses can optimize their customer experience strategies. However,
the first step to delivering excellence is to manage expectations effectively from the get-go.

Task 3: Handling SLA Contract Changes

When a service level agreement is in draft or inactive status, you can change information that is on the
Service Level Agreement tab, Assets and Locations tab, and Escalation tab. When a service level
agreement is in active status, you can change information about the Related SLAs tab and KPIs tab. If
you need to change the status of a service level agreement, use the Change Status action. Change
Management enables you to select one or more Service Level Agreements (SLA) to relate to a change
record. When you open a change, you can choose one Customer SLA for the contact, the same
Customer SLA or a different one for the contact and one or more applicable Service SLAs for the
contact's subscriptions to a service, or no SLAs at all. Service SLAs only apply if the change
references a Business Service, the contact has a subscription to the service, and the subscription
references an SLA. The following list describes the system's process for relating SLAs to a change
record.

• If one SLA is associated with the change based on the contact, the Customer SLA is added to the
change.
• If the contact has an Individual Subscription for the Configuration Item (CI), the Service SLA

Project Report Install and Configure Operating System Page | 3

 from that subscription is added to the change.
• If the contact has a Department Subscription for the CI, the Service SLA from that subscription
is added to the change.
• If the contact has neither, then no Service SLA is added to the change.
The SLAs should contain all Service Level Targets (SLTs) that define the business rules for all
response and availability metrics. You can choose as many SLTs as necessary to describe your
response or availability commitment. If necessary, you can add more SLTs that meet your criteria.

When you view the new record, the SLT section lists the SLTs related to the change.
Task 4: Types of Service Targets to Be Included
Service targets Use a service target to measure specific service goals. Depending on their type, service
targets include :
• costs
• terms and conditions
• measurements
• and milestones with actions for a service goal
You can either relate service targets to SLAs, OLAs, or UCs or keep them standalone, unassociated
with any service or agreement. You can define custom goals for your service targets and give them a
display label according to your business processes and needs. These custom goals map to the internal
service target types and are configured in the Application Administration Console.

Service type components

Essential service type components Optional service type components

One set of terms and conditions or KPI definition Impact costs

One goal type One or more milestones with one or more actions

Measurement criteria Not applicable

Task 5: Resolution of Service Disputes

A dispute resolution agreement, also known as an arbitration agreement, is a legal document that
outlines the process for resolving disputes should they happen in the future. These agreements help to
avoid costly litigation by outlining a framework for how disputes will be handled before they arise.
Dispute resolution service means any process in which an impartial third party is engaged to assist in
the process of settling a case or otherwise disposing of a case without a trial, including arbitration,
mediation, case evaluation, conciliation, dispute intervention, early neutral evaluation, mini-trial A
dispute resolution agreement come in handy if there are disagreements about the terms of an
agreement or contract. If you are a business owner who has made agreements with other people or
companies, it is important that you have a written document which outlines how these disagreements
will be handled.
Task 6: Operational Level Agreements and Underpinning Contracts

Project Report Install and Configure Operating System Page | 4

An Operation Level Agreement (OLA) is an agreement between an internal service provider and an
internal customer. Operation Level Agreements define the range and quality of the covered services.
(also known as Operating Level Agreements) are internal agreements that a service provider defines
for internal users to meet SLAs. OLAs can also contain one or more objectives or service targets. The
OLAs would be used to track internal service commitments such as the following service targets:

• Response time for incidents or problems assigned to IT groups

• Availability of servers supporting various applications

An Underpinning Contract (UC) is a contract between an external provider and an internal end
customer. Underpinning Contracts define the range and scope of the covered services

Task 7: Service Targets Must Be Reportable

The Service Reporting process reports on the results achieved both operationally and strategically. It also
reports on any developments related to Service Level Agreements such as hitting various targets, like
availability.

Its goal is to make information available to the business and IT so that informed decisions may be
made. The format and style of reports should be decided upon by IT and the business to suit their
respective audiences

Milestone 8: Develop SLA Contracts Components

Task 8: Contract period
A Contract Period is any number of days, as outlined in the contract, that the contract will run for.
This is also known as Contract Time and is the length of time between the start date and specific end
date. as outlined in a contract or agreement. The period during which the “Contract” shall be executed
as agreed between the Contractor and the Purchaser in the Contract inclusive of extended contract
period for reasons beyond the control of the Contractor and /or Purchaser due to unforeseen
circumstances.
Task 9: Expected service requirements
A service-level agreement (SLA) defines the level of service you expect from a vendor, laying out the
metrics by which service is measured, as well as remedies or penalties should agreed-on service levels
not be achieved. It is a critical component of any technology contract components. Service level
requirements means the specified level of performance for a Critical Service Level. By documenting
the service requirements, the Service Level Requirement (SLR) is produced. The SLR is made in the
form of a document that will serve as the basis for the future SLA. The SLR should describe the
service, i.e., how the service should deliver what was required by the customer (defined as warranty
of the service). The result of the defined SLR will be service level targets, i.e., what must be achieved
to fulfill the SLR. This is where we go into a deeper description of the service. To describe a service
with all its parameters sounds difficult, and it is
Task 10: Service assumptions
Assumptions are beliefs based on experiences and the information available to customers. Project
assumptions are an expectations aspect of the life cycle of the project, and they add an element of
risk to the project because they may not be accurate because you just tought the procces wich mean
you didn’t do the project itself but you make expectations what are the project results. Project

Project Report Install and Configure Operating System Page | 5

assumptions that are proven to be false often become constraints and can cause significant setbacks
or limitations in a project.

Task 11: Costs

The cost of service is a term that extends the idea of the cost of sales for service companies. Most
production companies use the cost of goods sold in the income statement. However, for firms that
render services, this term will differ. Contract costs include the costs attributable to a contract for
the period from the date of securing the contract to the final completion of the contract. These firms
use the cost of service to present their direct expenses better. Essentially, the cost of service is an
extension of the cost of sales for service firm

Task 12: Contract maintenance

Contract maintenance is the maintenance of materiel performed under contract by commercial
organizations (including prime contractors) on a one-time or continuing basis, without distinction as
to the level of maintenance accomplished
A maintenance contract exists between two parties, resulting in an agreement that the service provider
party will maintain the other party's business, home, or other assets. Maintenance is typically
performed by commercial contractors under a written contract.
Task 13: Contract responsibilities
Contractual obligations are duties each party is legally responsible for acting upon in a contract
agreement. With each contract, either of the parties exchanges something of value, whether it be a
product, services, money, etc., in connection with various obligations. They are legally required to
fulfill their obligations in order to complete the exchange.

Milestone 9: Problem Management Process Flow activities

The process of problem management is all about that when an IT-based service has been disrupted,
normal functioning capabilities are re-established as quickly as possible to minimize the adverse
impact on business operations thus assuring the best possible levels of service quality and availability
as agreed in the Service Level Agreements. Create a process flow charts for problem management
which may contains the followings:
Task 14: Proactive Problem Identification
Proactive Problem Management aims to identify and solve Problems and/or provide suitable
Workarounds before (further) Incidents recur.. Proactive problem identification is about anticipating
potential problems and preventing them. It entails looking at data and incident reports to identify
trends and patterns, then putting systems into place to preclude or prevent incidents. It’s very similar
to the risk management concept of mitigating controls.
Task 15: Problem Categorization & Prioritization
Problem Categorization and Prioritization has purpose to record by making problem category based
on how severe is the issue and so we can prioritize the Problem based on the category itself with
appropriate diligence, in order to facilitate a swift and effective resolution.

Task 16: Problem Diagnosis & Resolution

Project Report Install and Configure Operating System Page | 6

Problem Diagnosis & Resolution is to identify the underlying root cause of a Problem and initiate
Problem solution. If possible, a temporary Workaround is supplied. Problem & Error Control -
constantly monitor outstanding Problems so that where necessary corrective measures may be
introduced.
Task 17: Problem Closure & Evaluation
Problem Closure and Evaluation has purpose to ensure problem solved and after a successful
Problem solution - the Problem Record contains a full historical description, and that related Known
Error Records are updated. And evaluation of the solutions.

Task 18: Major Problem Review

Major Problem review has purpose to review the resolution of a Problem in order to prevent
recurrence and learn any lessons for the future. Furthermore it is to be verified whether the Problems
marked as closed have actually been eliminated. There have been one or more incidents that had a
significant business impact. You (or your customer) expect that there may be future repeats of the
same incidents. You need to ensure that future related incidents have minimal business impact.
Task 19: Problem Management Reporting
The problem management reports show the number of problems, problem causes, and group
assignments for a selected time period. These reports also show the number of closed problems and
the time it takes to fix the problems. ITIL Problem Management Reporting aims to ensure that the
other Service Management processes as well as IT Management are informed of outstanding
Problems, their processing-status and existing Workarounds

Milestone 10: Continual Service improvement model

Continual Service Improvement (CSI) section of the IT Infrastructure Library (ITIL) provides
organizations with best practices for the improvement of services and service management processes.
Task 20: Determine the 7 steps of Continual Service improvement using Deming model of Plan, Do,
Check, Action.

• The first activity is to Identify the strategy for improvement

• Second activity is to Define what you will measure

• Third activity is to Gather the data

• Fourth activity is to Process the data

• Fifth activity is to Analyze the information and data

• Sixth activity is to Present and use the information

• Seventh activity is to Implement improvement

Project Report Install and Configure Operating System Page | 7

Task 21: Show steps of your applications in Incident Management Process.

It varied may be simple or complex based on the type of incident.

Project Report Install and Configure Operating System Page | 8

Incident logging
An incident can be logged through phone calls, emails, SMS, web forms published on the
self-service portal or via live chat messages.

Incident categorization
Incidents can be categorized and sub-categorized based on the area of IT or business that the
incident causes a disruption in like network, hardware etc.

Incident prioritization
The priority of an incident can be determined as a function of its impact and urgency using a
priority matrix. The impact of an incident denotes the degree of damage the issue will cause
to the user or business. The urgency of an incident indicates the time within which the
incident should be resolved. Based on the priority, incidents can be categorized as:

Critical
High
Medium
Low
Incident routing and assignment
Once the incident is categorized and prioritized, it gets automatically routed to a technician
with the relevant expertise.

Creating and managing tasks

Based on the complexity of the incident, it can broken down into sub-activities or tasks.
Tasks are typically created when an incident resolution requires the contribution of multiple
technicians from various departments.

SLA management and escalation

While the incident is being processed, the technician needs to ensure the SLA isn't breached.
An SLA is the acceptable time within which an incident needs response (response SLA) or
resolution (resolution SLA). SLAs can be assigned to incidents based on their parameters like
category, requester, impact, urgency etc. In cases where an SLA is about to be breached or
has already been breached, the incident can be escalated functionally or hierarcially to ensure
that it is resolved at the earliest.

Project Report Install and Configure Operating System Page | 9

Incident resolution
An incident is considered resolved when the technician has come up with a temporary
workaround or a permanent solution for the issue.

Incident closure
An incident can be closed once the issue is resolved and the user acknowledges the resolution
and is satisfied with it.

*End of Report*

Project Report Install and Configure Operating System Page | 10