Taking a closer look at our ITIL processes

As ANVA Service Desk, we always want to improve. Serve our customers faster, approach them more proactively and keep our own workload under control. In the coming months, our own efficiency will be the focus. To help us with that, Marc Kuijer is returning to the service desk, an old friend to us.

Service Desk and Incident Management.

The Incident Management process is focused on handling findings or disruptions within our ANVA software and the agreed upon service levels. This process is also aimed at answering service requests (help requests). During the process, customers are kept informed of the status. The main objective of this process is to make ANVA workable again as soon as possible. This way we limit the impact on your business operations. The process contributes to the continuity and correct operation of ANVA with its customers. If it appears that the reported ticket cannot be resolved from the Incident Management process by the Service Desk, a "problem of change" will be created. From the Problem of Change management process the change will be further processed. In the process, we go through the following steps:

• accept (within 24 hours we will assess whether all the information we need to process the incident or service request is present);
• handle (we actually deal with the report to find out the cause or the relevant information);
• waiting for customer (if we need additional information or want to test a solution we will be waiting for response from our customers);
• Transfer to Problem or Change management (as indicated above, we transfer incidents that cannot be resolved by the Service Desk to the Change management process);
• resolve (once a solution or answer is at hand then we resolve the ticket);
• close (as ANVA Service Desk we resolve the report, it is up to our customers to close reports, if this does not happen within 3 weeks of providing the solution then we close the report).

The Problem Management process.

The Problem management process focuses on finding the root cause of incidents and preventing future related incidents. After finding the root cause, a problem can be transferred to the Change management process. It can provide reports with a workaround or lead to a known error. The latter happens when we know what is going wrong, but we choose not to fix it (now) in our software, but accept the consequences. Such choices lead to a knowledge base card at the ANVA Service Desk so that in future incidents this becomes visible during creation. The main objective of this proactive process is to identify and resolve problems before more reports come in. Several triggers can be distinguished to move to problem management:

• with a specific customer, we find that we are resolving the same incident for a second or third time. One example might be a server filling up. We can resolve such reports quickly through Incident Management so the urgency is removed, but the cause is not found, so the problem reoccurs. We link all these incidents to a Problem and from the problem we look for the root cause. We want to prevent the same error from reoccurring with these customers.
• we receive unexplained reports from various customers about the same issue. We also link these incidents to a problem to look for the root cause. We want to prevent other customers from running into the same problem.
• when analyzing trends, we see several reports within the same component of our software. We also link these incidents or service requests to a problem, partly to find the root cause, but also to see if we can simplify the operation to avoid questions about this component or clarify documentation.

The Change Management process.

The Change management process is aimed at resolving reported changes from the Incident management process as efficiently and controlled as possible. The objective of Change management is to resolve reported changes on ANVA as quickly as possible and make final solutions available. Resolved changes are made available to ANVA users through the Incident and Release management process.

As soon as it becomes clear from the incident management process that a modification to our software is needed to resolve the incident, a Request for Change (RFC) is created. The incident in question is linked to it. The process continues from the RFC, whereby we inform customers at regular intervals via the incident. This is visualized in this video. The agreed Service Levels continue to run on the incident. The solution is then made available through our Release Management.

RFCs appear on the backlog of our product teams and are picked up in the sprints of the respective team based on priority assignment by the ANVA Service Desk. Known RFCs are displayed on support.anvabackup.wpenginepowered.com to inform other customers about them. Once the RFC is resolved, the same list shows which bug fix is available and in which ANVA release the fix will be delivered.

Release Management

The Release management process ensures that tested and authorized software is made available to ANVA users in a controlled manner via an ANVA (Major) Release, Patch or Bugfix. The process also ensures that solved changes, which are delivered as an interim patch or bugfix for reasons of urgency, are included in an ANVA (Major) Release. The Release management process is based on the general ANVA Release Policy. A description of the process can be read in our online help.