Getting started with the ITSM template

Let's dive into how an ITSM project is created and how you could use this project to automate and simplify a typical ITSM problem.

The ITSM template is a workflow based on three nested issue types - Incident, Problem, and Change. Together these create an end-to-end ITSM process that can be used to report on ITSM incidents, identify the underlying problems, and implement changes.

Create a new ITSM project

Let's begin by creating a new project based on the ITSM template, and include some sample data for our demonstration.

• Within Jira, the ITSM template automatically creates issue types, an issue type scheme, workflows, a workflow scheme, screens, screen schemes and an issue type screen scheme.
• In Insight, the ITSM template creates an object schema, object types with attributes, and object type references.

Since we created an ITSM template with sample data, a few Jira issues and Insight objects are also created and linked together.

Create a project using the ITSM template

To create a project from an Insight template without sample data:

1. In the top menu, click Projects > Create project.
2. Under the Business header, select the Insight IT Service Management template.
3. Review the issue types and custom fields that will be created and click Select.
4. Enter a Name, Key, and Project Lead for the project.
5. Click Submit to create the project.

To create a project from an Insight template with sample data:

1. In the top menu, click Projects > Create project.
2. At bottom, click Create sample data.
3. Under the Business header, select the Insight IT Service Management template.
4. Review the issue types and custom fields that will be created and click Select.
5. Enter a Name, Key, and Project Lead for the project.
6. Click Submit to create the project.

The 'Incident' issue type

After you've created your project, you can start working with it immediately. Let's imagine we're working as frontline support and we're reporting an incident, as you create an incident in the example.

Create your first ticket and select the Incident Issue Type. Write a Summary, and select an Affected Business Service.

If you look at the ticket you have created, you can see that the Jira issue is linked to Insight. Affected Business Service automatically appears in the Jira issue, and shows the status, business service owner, and more.

You can also see the incident issue type has a built-in workflow, with post-functions and transitions to make the process smoother. Click Confirm incident to confirm the incident and proceed through the workflow.

Moving the ticket through the Jira workflow also affects the Insight objects.

Transitioning the Jira ticket to WORK IN PROGRESS status also changes the status of the Affected Business Service to INCIDENT IN PROGRESS.

Investigating the incident

Investigate the incident further and transition to the status Hardware Failure. Select the Related Server that you suspect is the source of the incident. The current user is automatically assigned to investigate.

Now that you've identified a culprit, the Related Server from Insight is also linked to the Jira issue. Post-functions built into the template have updated the status of the Affected Business Service and Related Server.

Proceed to Investigate Failure. When enough information has been gathered, resolve the issue with Resolve, indicating that you have determined the incident's cause, or that you are unable to reproduce the failure.

For the sake of the example, let's assume you can reproduce the incident and have an idea of what's causing it. Change the issue state to Report Problem to create a new issue of issue type Problem to begin tracking the underlying cause of this incident.

The 'Problem' issue type

Typically, this is where the role of frontline support ends. A higher-level support representative might take over the new Problem issue, which has its own workflow, reporter and assignee, but includes the Insight information that it inherited from the Incident issue.

The Problem issue moves through the REVIEW and INVESTIGATION states.

During the investigation, the assignee could find a component or system that needs to be changed - for example, the problems with the exchange server might be caused by a faulty network card. The assignee would change the ticket status to REQUEST FOR CHANGE and select the faulty component.

The list of components is populated automatically by Insight based on the objects linked to that server.

You have selected the faulty component, and the status of the issue is now WAITING FOR CHANGE. The affected business service, server, and component are all linked to the issue.

The 'Change' issue type

When the problem issue reaches the WAITING FOR CHANGE state, automation creates a new Change issue.

Since this ticket requires on-site hardware changes, the support representative managing the Problem ticket might hand this ticket over to the server owner to make the changes.

The newly-created change ticket is linked to the problem ticket, which will not be resolved until the change ticket is resolved.

Like the Incident and Problem tickets, the Change ticket has its own workflow. Planning and approval states must be completed before the change can be implemented.

To progress through the change workflow, we need to select a replacement component for the malfunctioning server. If there are are any Available Server Components identified, they will appear in the drop-down list.

If there aren't any components available, we can always create one by clicking Create an object in the dialog.

After we've created the object, we select it as the Available Server Component and progress through the workflow until we reach the Implementing state. You'll notice when we are implementing the change, the Affected Server is automatically stopped.

Completing the changes

When the change is completed, automation handles the rest:

• The change ticket is Resolved,
• The Resolution is Done
• The faulty server component is changed to Decommissioned
• The Affected Server is running again
• The server component linked to the server is updated to show the new network card

The Change issue is resolved.

Similarly, the Problem ticket is automatically updated and closed when the change request is closed.

As is the Incident ticket that started the whole workflow.

Summary

The ITSM sample template is only an example of how you might want to structure your ITSM practices with Insight and Jira. Everything you see in this template has been done entirely with Jira and Insight; no other plugins or modifications are needed.

You are free to use this template, modify it, or - if you prefer - start your own from scratch. Enjoy!