What is ITSM - ITSM vs ITIL vs DevOps?

More FAQ Pages: Atlassian FAQ → | What is PII FAQ →

What is ITSM?

ITSM stands for IT Service Management, and concerns how the IT team manage the delivery of IT services to their customers. It comprises of policies, processes and procedures, which should be proportional and appropriate. Using practices and process differentiates ITSM from simply “doing IT”.

Visit our ITSM page 

What is ITIL?

ITIL stands for the IT Infrastructure Library. This describes a set of best practices for delivering IT Services, and an approach to doing ITSM.

What is DevOps?

DevOps is a combination of Development and Operations. The concept is to improve collaboration between Development and IT Operations teams, so that organisations can build, test and release software faster and more reliably. Much of DevOps revolves around automated CI/CD pipelines, but we should remember the Ops part. The context here, is how appropriate ITSM can help the Ops part of DevOps.

Visit our DevOps Page 

How does Jira Software and Jira Service Management enable DevOps?

In short, Ops and Service management teams can use Jira Service Management to manage requests and incidents. Development teams can use Jira Software to help manage development projects. Using the two products together fosters communication between Dev and Ops teams. For example, several Incidents in the Service Desk may relate to a single Bug in the Development project. A Developer can see the incidents, and collaborate with their support colleagues, and vice versa.

Visit our Jira Service Management Page 

What are the benefits of ITSM?

It is a structured approach to delivering IT services, which leads to efficiency and productivity. Using a consistent approach makes it easier to categorise work, and manage processes. This can be contrasted with, say, a shared email box which which conceals a mixture of work items and no reporting.

ITIL v3 vs ITIL v4

ITIL shifted from recommending 26 ITSM “processes”, and instead introduced 34 ITSM “practices”. A process was a flow of activities, along with roles and metrics. Practices are now simply capabilities that can be performed by an organisation.

What is Service Request Management?

Service Request Management is the process of managing “business as usual” customer requests. Examples of Service Requests would include application access or requests for hardware items. There are often recurring requests, and it is often possible to automate tasks and provide knowledge base articles. A Service Request is a normal part of business, as opposed to an Incident, which is an unplanned event.

Helpful Links:

BDQ Blog - Supercharge your management reporting from Jira

Case Study - BDQ helps Betway increase helpdesk efficiency and provide seamless service for users

Whitepaper - The future of ITSM is Agile

What is Knowledge Management?

Knowledge Management is the process of managing the knowledge and information within an organisation, with the emphasis on creating, sharing and using it appropriately.

What is IT Asset Management?

IT Asset Management (ITAM) is the process of managing and organisation’s assets, including deployment, maintenance, upgrades and disposal. For example, an organisation would keep track of all its PCs or software licenses.

What is Incident Management?

Incident Management is the process of dealing with unplanned events, and restoring a service to a working state. Examples of incidents would be an application ceasing to function, or a network problem. Incidents can be contrasted to Service Requests which are “business as usual” customer requests.

What is Problem Management?

Problem management is the process of identifying the root cause of incidents, and finding the best way to eliminate the underlying problem. For example, a series of Incidents relating to WiFi may indicate that there is a fundamental Problem with the WiFi architecture. Identifying Problems in this way allows for better prioritisation and allocation of resources.

What is Change Management?

Change Management provides a framework for managing changes to IT infrastructure, whether these are upgrades, new systems or bug resolutions. A change management process will provide traceability, so everyone can understand what has happened, should a Change cause an Incident. Approvals workflows are often used to make this process easier to handle. It is important to be proportionate - a big system upgrade should not generally be treated the same as a minor bug.

How does Jira Service Management implement ITSM?

Jira Service Management provides a web portal, which an unlimited number of customers can use to request services. These request queues are dealt with by Agents. Service Requests, Incidents, Problems and Changes are all specific issue types with appropriate workflows, including approvals where necessary. It is therefore straightforward to categorise and prioritise work. Issue Linking is a powerful technique to connect related issues, for example many incidents may share an underlying Problem. Knowledge Management is provided by Confluence, and IT Asset Management is provided by Insight.

How does Jira Service Management implement Change Management?

Jira Service Management provides customisable workflows which have best practice change and approvals processes. These can be configured for very lightweight change processes, or very structured if the situation requires it. Approvals can be sought from the internal team, or from other staff such as managers via the Portal. After implementing Jira Service Management, one customer told us that it cut their open change requests from an average of 40+ to less than 10, and that they were no longer grappling with large numbers of emails.

Visit our Jira Service Management page 

Helpful Links:

Download - The Total Economic Impact of Atlassian ITSM report

Quiz - Are you a lean, mean ITSM machine? Take the quiz and find out!

Microsite - See what companies around the world have to say about Jira Service Management

What is an ITIL ITSM Standard Change vs Normal Change?

A “Standard Change” is something that is low risk, and pre-approved - i.e. it doesn’t need formal approval. A “Normal Change” does requires approval, usually from a CAB (Change Advisory Board).

These two change types are confusingly named! “Normal Needs Approval” can be a helpful way of remembering which is which!

What is an ITIL ITSM Standard Change?

A “Standard Change” is something that is low risk, and pre-approved. It’s common, well understood, and has documented procedures.

What is an ITIL ITSM Normal Change?

A “Normal Change” is not pre-authorised, may require special treatment, and will require approval, usually from a CAB (Change Advisory Board). The change team will usually review it themselves, before asking the CAB for final approval. Changes may be complex, require back-out plans, schedules and so forth.

What is an ITIL ITSM Emergency Change?

This is a change that must be introduced as soon as possible, usually because allowing something to continue will be more risky than fixing it without an approval. For example, implementing a security patch for a new exploit might be treated as an emergency. It has to be done as soon as possible, but we can document the fact that it has been done.

What is a CAB, or Change Advisory Board?

This is the group of people who can authorise changes. They can include people such as managers, analysts and engineers. These people should be able to understand the impact and plans of the change requests they are being asked to approve.

What is an ITIL ITSM SLA?

An SLA is a Service Level Agreement. ITIL-4 defines an SLA as a “A documented agreement between a service provider and a customer that identifies both services required and the expected level of service.”

An example might be “time to first response”. This might differ depending on the service or priority. We might want to say that a high priority request has to be responded to within 30m, a low priority, within 4hrs.

How does Jira Service Management help with SLAs?

Jira Service Management has the concept of SLAs built in, and they are flexible and easy to use. We have to consider how time will be measured, and the goal of the SLA. As issues transition between different states, the time metric can track this. For example - “Time to first response” is concerend with the time between opening, and responding to an issue.

It is possible to pause an SLA clock - for example, when an issue is with a customer.

We can also set up calendars - the SLA may only count during 9-5 working week hours.

It is straightforward to report on SLAs, SLA breaches, and to get alerts when an SLA is about to breach.