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.
- 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
- 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
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 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.
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:
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
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.