Hornbill How To: Transition to the new Service Level Agreement functionality
The new Service Level Management functionality has recently been introduced to Hornbill. This contains various new functionalities and features, providing end users with greater flexibility when configuring time based targets for the response and resolution of requests, based on your Organisation’s specific requirements.
Existing customers (those who have subscribed prior to December 2016) may well have already configured a number of Service Levels within Hornbill. Rest assured, as with any new feature that’s introduced to Hornbill, any existing set up will be retained and you can continue working without having to make any changes to your configuration.
If you would like to utilise the new features and flexibility of our revamped SLM offering, you will first need to take a few simple steps to ensure that the transition is as smooth as possible and your user base does not experience any issues. To start, Hornbill has created a video offering some best practice advice (which you can find on the right). The video demonstrates a very simple example: migrating an existing Service Level configuration so that it can be used by the new functionality. Alternatively, you may decide to completely rework your Service Levels. In both scenarios, the guidance provided will assist you in this transition. The content of the video is also summarised below.
Step 1 - Check the existing set up
Before you begin, its worth knowing what you have already got configured. This may have been set up some time back, so understanding how your Service Levels currently work is an important task in order to ensure you can either replicate or resign your Service Level structure within the latest functionality.
- Existing Service Levels
- These are configured within the User App by hovering over the Service Manager icon and selecting Services, and then the Service Levels Tab. Here you can tell if any Response and Resolution timers have been set up and the targets that have been set against them. Its also worth clicking on each of these targets to see if there are any Escalation Actions configured against them. If there are, you may want to consider if these are still valid and if they need to be migrated as well.
- In the same section as above, click the Priorities tab to see which priorities have been currently been configured and activated.
- Business Processes
- In the Admin App, navigate to . This is where Service Levels are configured to Start and Stop, so it worth reviewing every Business Process that you have in use to see how this has currently been configured - and make a note of the ones which do currently use this. Also keep an eye out for any configuration you may have where a different Response Timer is kicked off based on a decision. This may need to be amended as part of your new SLM set up.
- Working Time Calendars
- The Working Time Calendars can be found in the Admin App and navigating to . It is likely you will only have one set up right now, as the older functionality only allowed for this, but have a look and ensure if its still valid
Step 2 - Establish Requirements and plan for new set up
If you are just looking to directly replicate you existing set up, you can skip to the next step as it will simply be a case of recreating what you already have. But if you are looking to rework your Service Levels or make changes, there are some useful considerations
- Priorities: Do you need to make any changes to Priorities for example adding new ones, changing your existing ones or reducing them? If so, will this affecting any decisions in your existing Progressive Captures or Business Processes?
- Organisation Structure: Do you require different targets for different Organisational Structures? For example will you have one set of Service Levels for one Organisation, and a different set for a different Organisation?
- Service Specific Targets: Do you have any Service specific Service Levels or Targets?
- Calendars and Time Zones: When thinking about service levels, do you need to consider multiple sets of working hours and time zones which are dependent on based on call criteria? For example, will your targets be based on an American timezone if the site of the request is New York or would still be based on your default?
- Escalation Actions: Do you have any actions that need to occur as the targets get closer to breaching?
Its best consider the above points when working through your requirements, and if you want to rework what you currently do, have a look at the specific details regarding what the new functionality offers (here) and begin to map out how this will work for you.
Step 3 - Configure the Corporate Service Level Agreements
Once the requirements have been agreed upon, and you know the structure that's required, its time to begin the new configuration. To do this, use Corporate Service Level Agreementsnts - you can create Service Specific SLAs (as described here) but for this transition its not a good idea because its likely to end up in duplication of effort.
To create your Corporate Service Level Agreement(s) navigate in the User App to the
From here you can begin setting up your SLAs, Service Levels, Targets and Escalations as per your requirements. In this example, we are just replicating my existing Service Levels like this:
Once they have all been created, you will also need to create the rules that define which Service Levels are associated. As you can see from the below example, whereas previously this was defined in the Business Process, its now decided using the Rules tab within your SLA. In our example, we are going for a simple, typical set up where the Priority of the request drives which Service Level within the SLA is associated. However, various other criteria can be added to make this as complex or simple as required. Also notice the ordering functionality - the system will work through each of criteria in order and select the first Service Level it finds a match with.
If you are looking to use any new Working Time Calendars, this is the point at which to do this too.
Step 4 - Test - using a Test Service
Once you have configured your Corporate SLA(s) its time to begin testing. To do this, create a brand new Test Service specifically for this purpose:
- Give it a name to make it clear that this is purely for test usage - for example "Test Service - Please Ignore"
- Subscribe just one or two users to this - typically the people who are either configuring SLM or performing some testing. This will ensure that this test service is not made public on the portal and should also minimise analysts seeing this when raising new Incidents and Service Requests.
- Create it based on another of your services - create a catalog item where necessary and link up the relevant Progressive Captures and Business Processes. This will make it as lifelike as possible.
- The new SLM Functionality will begin to be used
- In your Business Processes, if you have specified any specific Response Timers to be used, these will be overridden - and the SLA rules will be the source of choosing the relevant Service Level to associate.
- If you remove the SLA from this tab, it will revert back to using the existing set up (this can be used if you have any issues)
Once you have set up your test service, you are now ready to test. Raise a new Incident against one of the customers you subscribed to the above test Service, and ensure to select the Test service once you get to that screen of the Progressive Capture.
Once you've logged the request and have met some of the criteria of your SLA Rules. You should see the new Service Level having been associated. You can tell as it has a different format to the older version. Also if you click the SLA (and have the relevant role), you can now change the Service Level after it has been logged - one of the new features provided.
Step 5 - Apply the Corporate SLA(s) to the relevant Services
Once you have completed your testing and are happy with it, the final thing to do is to go through your live Services and begin populating the SLAs tab with the relevant SLAs. Remember:
- As soon as you add an SLA, that Service will be using the NEW functionality and cease to use the OLD functionality.
- The new set up will only affect NEW requests that have been logged against that Service from that point onwards. Any existing requests will continue to use the older SLM set up.
- You can also add multiple SLAs to Services if required - and you will be presented with a Rules tab similar to that within the SLA configuration you performed earlier on. As a Working Time Calendar is associated to an SLA, this is where you would set your rules if you require different calendars to be used in different situations.
The final thing you want to consider are your Business Processes. If you have multiple response nodes that are selected off the back of a decision node, there should not be any issue in leaving this as is - as soon as the process reaches either node, it will ignore the named Response Target and use the Rules you have configured instead. However as this effectively makes having a decision node redundant, you may choose to clean this up by working through you Business Processes and removing the now unnecessary configuration. Using the Business Process example referenced earlier in this article, you'll see we can now remove the decision node and one of the response nodes, rename the remaining response node and set its Service Level selection to "Auto" and save/activate.
- Reporting - If you already have reports set up against Service Levels, they are unlikely to be affected by migrating to the new SLM functionality. Despite there being a number more tables in the database to contain the configuration, the key details are recorded in exactly the same way, in exactly the same place (the h_itsm_requests table):
- How long is the Response Target in seconds (h_respondby)
- How much Response Target time is remaining in seconds (h_responsesecs)
- How long it took to meet the Response Target in seconds (h_withinresponse)
- Was the Response Target met (1) or breached (0) (h_withinfix)
- How long is the Fix Target in seconds (h_fixby)
- How much Fix Target time is remaining in seconds (h_fixsecs)
- How long it took to meet the Fix Target in seconds (h_fixtime)
- Was the Fix Target met (1) or breached (0) (h_withinfix)
- There are also some new useful attributes that could come in handy for reporting:
- Name of the SLA associated to the request (h_fk_servicelevelagreementname)
- Name of the Service Level associated to the request (h_fk_servicelevelname)