Going ITIL With Gemini

Introduction

Gemini’s ITIL Template provides a best practice, instant starting point for project teams who are working to the ITIL Service Operation (SO) standard. In addition to the Project Template, which provides a quick start on project metadata, Gemini provides a wealth of functionality around ITIL processes to manage:

Roles and Responsibility

Stakeholder identifi cation and Resource assignment

Tracking of Progress

Service Level Agreements (SLA)

Estimates and Time logging

Metrics and Reporting

Manual Progress Management

Workflow Rules, Roles and Responsibility

Status Transitions

Status Related Permissions

Dependency Workflow Management

Measurement of Progress

Charting Progress

Manual Progress Indicators

Collaboration and Reporting

Project Workspaces

Ad Hoc and Packaged Reports

Service Desk versus Help Desk

Prior to version 3 of the ITIL standard, Help Desk and Service Desk were interchangeable terms. From version 3 onwards the term Service Desk has been used to defi ne the strategic improvement of processes in an organization, aimed at reducing cost and increasing effi ciency in the interaction between users and IT. Help Desk is focused on day-to-day operational support of the end user and fulfi lment of their immediate needs.

Gemini lets you define:

Service Desk (as per the default ITIL Template)

Help Desk (using the Help Desk Template)

Combined Service Desk and Help Desk.

The last of these options is implemented by the simple process of adding an extra process - “Ticket” - to the ITIL Template and making this Ticket process the default Type that is selected in one (or more) of the projects built from the Template. It is recommended that if you combine the Service Desk with the Help Desk that you also add “Change Request” to the ITIL Template for those inbound requests that require modifi cations that cannot be instantly made. Standard fi elds and workflow for Tickets and Change Requests can be found on the default Help Desk Project Template.

How Service and Help Desk interoperate

In an ideal scenario an organization would operate with both Service Desk and Help Desk functions. Regardless of whether these are in standalone or combined form, they should be closely coupled. The reason for this tight coupling is simple - there is often a causal relation between work items. Very few manageable pieces of work are unrelated to any other.

For example, a help desk ticket may identify a problem that requires software development that in turn might necessitate a change request, and so on. One thing causes, or is related to another. The creation of multiple types of data (Ticket, Bug, Change Request etc.) in different systems allows process gaps to develop. Where there are gaps things slip through the cracks and problems appear. Process gaps occur for two reasons:

Departmental jargon, prescriptive data capture, and rigid workflows often lead teams to purchase systems for their specifi c use. In such instances you can end up with a Ticket in one system (linked to the customer) a bug in another (linked to nobody in particular) and a Change Request that does not identify the stakeholders. What happens if the developer working on the bug has a question for the end user who raised it?

Project-based systems that have no cross-project Workspaces. In this scenario you can end up with a damaging lack of insight. For example a marketing campaign might be dependent upon work of web developers. If a problem exists with web work the whole initiative could fail without anyone (especially those in Marketing) able to see the critical path in advance.

At the very least a lack of interoperability between a Help Desk, Service Desk and projects leaves an organization open to being blind-sided. A number of Gemini’s features negate this:

Per project taxonomy – let every team use their language in the same system so adoption is high, data is centralized and everyone is on the same page.

Custom fi elds, and customizable workflow - let every team track and manage their tasks their way. If they can’t, they’ll fi nd other systems to use.

Workspaces – use project level access for permissions but span projects for management and reporting where there are inter-dependencies or linkage.

Interoperability in action

Gemini lets you transform work items from one Type to another, giving you single, centralized data collection around which communication and collaboration can occur. A Help Desk Ticket can become an ITIL-managed Incident/Problem/Request by a simple point-click change. If the Help Desk and Service Desk are separate, Gemini will allow you to move items between projects. For example the Ticket in a Help Desk can be moved to an ITIL project as an ITIL Type, while retaining the full history of its provenance. In this way the origin (owner) and all communications that have taken place between all stakeholders, is traceable, auditable, accessible and actionable. You can of course move items between ANY projects as any type that the destination project supports, so you could move a Ticket into another project as a Bug or Change Request, it does not have to be Help Desk to Service Desk.

The ability to transform and move work items supports the ethos of ITIL which is all about communication and collaboration, specifi cally so that nothing slips or gets lost between customer and supplier or between departments. It results in ‘one version of the truth’, a desirable state for any organization that has to track work across multiple departments and stakeholders.

ITIL Project Template

The standard Processes defi ned on the Gemini ITIL Template map exactly onto the SO framework and are:

Event Management

Incident Management

Request Fulfillment

Problem Management

Identity Management

* You can add a 6th or 7th if you wish to combine Help Desk and Service Desk functionality by implementing additional Processes for Tickets and Change Requests.

Template Metadata

Per Process Workflow (or inherit common workflow across processes)

Service Level Agreements

Rules & Actions (if condition X then perform action Y)

Priority Levels

Severity Levels

Standard Data, including:

Comments with visibility by role

Attachments

Start, Due, Create, Revised and Closed dates

Estimates and Actual Time logs

Parent/Child Dependencies and links between items

Unlimited User-defined Data Fields

Repeating Task Schedules (esp. for Events)

Gemini Support for ITIL (SO) Functionality

Roles & Responsibility

Item Owners

Gemini automatically records the Creator of a work item in an ITIL process. In addition to the item creator, Gemini has the fi eld Reported By, for instances where the creator of an item is not the stakeholder (esp. customer) whose communication initiated the item’s creation. If the creator does not specify a different person as the reporter then Gemini automatically makes the reporter and the creator the same. However the Reported By fi eld is populated, at an individual stakeholder level this fi eld denotes the item owner.

ITIL identifi es as best practice the concept of a Single Point of Contact (SPOC). This must be a two-way connection. The single point of contact for those working inside the Service Desk is the item owner (Reported By). The point of contact for the item owner is the Gemini Service Desk itself, since multiple resources could be assigned to the work item at the outset or at various stages in the workflow. Regardless of its superior efficiency, the item owner may not want a system as his or her interface, for which reason Gemini provides dynamic, customizable email templates that deliver seemingly human responses even where communication is automatic.

Item Followers

ITIL is concerned very much with communication. Gemini has ‘Followers’, people who are informed via email of any changes to an item. Gemini’s Rules and Actions will allow you to automatically make the item owner a follower. You may also self-nominate, or nominate others to be followers of specifi c items.

Groups and Roles

Every person in Gemini is a member of at least one Group. Every fi eld and workflow transition is secured by User Group, even if the user Group is ‘Everyone’, so the logic around security is consistent. You define permissions on projects and then allocate those permissions to Groups.

Resources and Resource Assignment

Not all Gemini users are necessarily Resources. Resources are people who are set to receive auto notifi cations when they are assigned to an item. Gemini supports single or multiple resource assignment and allows for the association of user groups as resources on designated projects.

In a number of Service Desk (and Help Desk) operations, it is necessary or desirable to triage items as they come in. Gemini allows you to default one or more Resources to this task. If you don’t default named individuals it does not matter, provided you use Gemini Workspaces. All Workspaces track items that come into their scope and notify the users who work in them of the arrival of new items, and updates or comments to existing items.

Process Workflow

You can design and implement any workflow around your ITIL processes, and Gemini supports different workflows per process. The sample ITIL Project Template provides a base workflow design that is used across all processes. In it, every process goes through the following states:

Status

Conditions

Logged

New item. This is the default status. The creation of a new item by an inbound email automatically triggers the creation of an acknowledgment by email that identifi es the new item in the system by key to the user reporting the item. Manually entered items can also generate confi rmation emails.

Assigned

At least one person has been assigned to the task. The change from Logged to Assigned is triggered using Gemini’s Rules & Actions based on the Resource fi eld being populated.

In Progress

The item is being actively managed by the assigned Resource(s).

Test

Remedial action has been taken or a process improvement has been put in place and is being evaluated.

Deploy

The test has completed successfully or the process has been signed off by the stakeholder(s).

Closed

Successfully deployed to a production instance/live environment.

Controlling Status Transitions

Gemini’s workflow allows you to easily defi ne the user groups who are authorized to make transitions from one status to another.

Keeping Everyone in the Loop

The Item ID is a single point of reference for every stakeholder. There is an assumption that in using Gemini in an ITIL compliant way, auto response will be set on any mailboxes used to create work items from inbound emails and this will contain the Item ID. If, however, work items are created manually then you may use Gemini’s Rules and Actions to notify the item owner of the item’s creation and key values. You may wish to use the same Rules and Actions to mark the item owner as a follower who will receive constant updates, or do so manually.

Do you need a status of Responded?

To manage a process where items are created manually for a 3rd party, you may wish to introduce a status of “Responded”, either before or after Assigned, to indicate that the passing of the item ID as a reference to the originator has occurred. The base template does not by default contain a “Responded” status.

The primary reason why an SLA is missed is a non-timely response to the request. For many organizations it is very important to be able to measure Response Time as a Key Performance Indicator (KPI). It can be argued that Response Time is measured from when the ticket is assigned to a team or individual until it moves to In Progress state. Some may argue (validly) that Response Time is the time between ticket creation and when the ticket is In Progress. However you choose to measure this metric, if you have a Help Desk whose goal is “fi rst call resolution” then the time the help desk opens or receives a ticket to the allotted time they are given to try to resolve at their level, lies in the window from when the ticket is created through being Assigned and then In Progress. Gemini, through its Rules and Actions and SLA framework, allows you to adopt whatever view you have of this KPI, and to track and report accordingly.

Managing the DevOps handover

The ITIL Template statuses provide a means of separating effort between Development and Operations. Testing should be conducted collaboratively, with stakeholders added as resources, to ensure there has been an objective peer review to validate delivery. Successful validation passes the item into the domain of the Operations team who can coordinate a change request when deploying into Production.

The Test Status on the ITIL Project Template can be used to mark the evaluation/sign-off process between Development and Operations, provided a clear distinction is made between testing a fi nalized piece of work that will affect production and pre-implementation testing. The latter is simply a QA step that precedes the release of development work to the stakeholders for evaluation. Gemini will allow you to move the work out of the ITIL project and into a specifi c development/testing project for pre-release testing, and then to move it back when it is ready to be exposed to the broader stakeholder base.

Should you use a checklist?

Gemini contains an Open Source Checklist App (found on http://countersoft.github.io that can be downloaded and tailored to suit status transition requirements. For example the checklist can contain checks on a) the production of supporting documentation b) budget approval c) post-implementation reviews etc.

Workflow - Dependencies

Gemini supports item dependencies and from a workflow perspective ensures that parent items cannot be closed unless all of the immediate children are closed. There are no system-imposed limits on the levels of dependency nesting. Gemini gives total fl exibility, allowing dependencies of mixed types. For example, one can say that a Problem cannot be closed (marked as fi xed) until the Request that it depends upon is managed to a conclusion.

Service Desk and SLA

The Service Desk handles every one of the defined processes in the ITIL Project Template. It may also handle a number of related processes to do with business continuity, contracts, licenses, system confi guration etc. One common element running through these disparate activities is time. There are very few activities, in an organization large enough to require a Service Desk, that do not have a time-critical element. Gemini SLA is not simplistic Service Level Agreement logic as applied to contractual relationships between customers and suppliers, it can be applied to ANY Service Desk or Help Desk item. In fact, it can be applied to ANY work item – a Ticket, a Problem, an Event, a Bug Fix, a Test Case etc.

User-defined Gemini Rules start, stop or reset a clock. For example, a Rule might examine the domain of an inbound email and, based on its value, start a clock against the item that the email generates; or a user might change a Priority setting or an item status and trigger the starting, stopping or resetting of a clock. Whatever conditions start the clock, or whatever the response duration is – a week, a day, an hour, or even just a handful of minutes, the fl ow of work that is managed by the Service Desk/Help Desk is controlled and the commercial obligations are recognised.

Managing the problem of scale

The ambitions of a group to meet ITIL compliance standards can be defeated by the simple problem of scale. A list of 20 items is manageable, 200 is quite hard, and 2,000 is impossible – without help. That help is the critical factor and Gemini provides help in the form of an internal system known as Eye Candy. This mechanism not only provides visual identifi cation of critical items, it automatically orders them and places rules around their visibility, so items closest to being in breach of the SLA are always placed in front of the delivery team regardless of how they choose to order and fi lter the rest of their information.

Gemini’s many attributes support full-scale ITIL compliance. SLA and the ability to create customizable, data-driven business rules, ensure that ITIL is not just a standard, but a working, governable framework that responds to and communicates with all necessary stakeholders on a timely basis.

Download the automate all inbound and outbound communication so that every stakeholder is part of the feedback loop guide.